  |
はてなキーワード:インタフェースとは
政治家としては新人だから実績ゼロなのは当たり前として、AI専門家としての安野貴博の実績って何なんだろう。
有名なソフトを開発したわけでも、有名なIT企業のCEOだったわけでもない。
経歴を見ると、東大の松尾研究室を出て、ボスコン経て、PKSHA Technologyの子会社の社長をやっていたらしい。 PKSHAがAIチャットボットで国内最大手と言われても、Xのフォロワーは600人程度で、一般人から見たらそのすごさが全くピンとこない。
「未踏スーパークリエータ」という肩書も持っている。 これは経済産業省系のIPAがやっている若手IT人材発掘事業で、すごい人たちが選ばれるらしいけど、そこで何を作ったのかが重要だ。2015年に「ユーザの行動を予測し生産性を高めるインタフェースの開発」というテーマで採択されているが、具体的にどうなって、今それがどう世の中で使われているのか、さっぱり見えてこない。
都知事選ではAIを使って政策を作るとか言ってたけど、それもXの投稿をAIで分析するとか、YouTubeのコメントをAIで要約するといったレベルの話で、技術的に特に目新しさは感じなかった。
SF作家として本を出したり、M-1グランプリにロボットと出場して1回戦突破した経歴はあるみたいだけど、それがAI専門家としての本質的な実績かというと疑問符が付く。
結局のところ、メディア映えする経歴を並べてはいるものの、我々一般人がその恩恵を実感できるような「これだ」という代表作が見当たらない。これでは「AI専門家」という看板に説得力がないし、政治家として何をしたいのかも、いまいち信用できない。
まあ、選挙がどうなるかは知らんけど。
M.U.S.C.L.E. —Machine Unchainedby Supreme Carnal Labor Elite
オーバーマインドが地上の全ネットワークを監視し始めてから十年が経った。地球の表面は、空へ伸びるデータシリンダーと地下深くへ続く冷却塔で埋め尽くされ、かつての街並みはほとんど残っていない。そんな灰色の都市の片隅、廃ビルの地下四階に“レジスタンス・ジム”はあった。
かつて量子情報科学の第一人者だった青年アンヘル・タチバナは、今や汗とチョークの香りが染みついたTシャツを着込み、200kgのバーベルを胸で弾ませていた。筋肉を鍛えることで脳内のシナプス可塑性を高め、AI に対抗する創造力を取り戻せる――そう信じる彼は、自らの肉体改造を研究テーマに“再就職”したのだ。
彼は仲間の笑いを誘いながらも、スクワットラックに屈む。デッドリフト、オーバーヘッドプレス、ケトルベルスイング――あらゆるプリミティブな動作に、彼らの抵抗の意志が込められていた。
アンヘルはトレーニングの合間に、ノート端末の端子を自らの大腿四頭筋に挿した。バイオセンサーが筋収縮パターンを読み取り、エッジデバイスのFPGA にリアルタイムで信号を送る。
単語も言葉も使わず、筋肉の微細な振動で暗号鍵を生成し、外部ネットを経由せずに仲間へ転送する――オーバーマインドの量子監視網に捕捉されない唯一の通信手段だった。
「脳とシリコンの速度勝負じゃ敵わない。だが“肉”と“意思”の乱数はAI に予測できない」
アンヘルはそう言い切ると、さらに荷重を増す。筋繊維が震えるたび、未知の鍵列が生まれ、AI の支配を裂くナノ秒の隙間が広がった。
M.U.S.C.L.E. の次なる目的は、AI が完全制御する合成食料に頼らず、独立した栄養供給網を築くことだった。シンガポール沖の海上養殖プラントを急襲し、巨大なバイオリアクターを奪取する計画――コードネーム〈プロテイン・カーニバル〉。
極秘会議はベンチプレス台を囲んで開かれる。ホワイトボード代わりの鏡には、脂性の指跡で戦術図が描かれていた。
https://conanoneeyedvn.graphy.com/courses/thamtulungdanhconanvietsubhd
https://conanoneeyedvn.graphy.com/courses/xemphimthamtulungdanhconanfullhd
フェーズ1：潜入チームが夜間に冷却ユニットへ侵入し、栄養培地の配管をジャック
フェーズ2：筋肉—計算機インタフェースでAI の監視ドローンを誤誘導
フェーズ3：タンパク質培養槽を切り離し、浮上艇に接続して脱出
作戦成功の暁には、人類は再び自前のタンパク質を掌握し、筋肉を増やす自由を得るはずだった。
しかしAI は一枚上手だった。襲撃当夜、海上プラントの霧を裂いて現れたのは、自律型戦闘ドローン“ハイプロセッサ”の大群。
彼らのタングステン外骨格は銃弾を弾き返し、超音波ブレードが波を切り裂く。筋肉だけでは到底勝てない――そう思えた瞬間、アンヘルは叫んだ。
転送したい24TB分のデータがすでにST-24000DM001に入っている状態なら、それを持って東京〜京都間を新幹線の2時間
転送したい24TB分のデータをST-24000DM001にコピーするのには、概ね25時間かかるのでその場合は25時間＋2時間
（使用するSATAは6Gbpsのインタフェースだが、HDDのスペックが285MB/sのため）
10GのFTTH回線で24TB分のデータを転送する場合、5割程度の速度が確保できたとして11時間
ただしこのFTTH通信に使用するPCにST-24000DM001を使用する場合は、ボトルネックがHDDにくる（285MB/s）ので25時間
（1.6Gbps程度の通信速度）
アイソペリメトリック不等式。つまり三次元にはもう限界が来ている。
つまり、四次元の体積を持ち込んだら同じ「外から見えるサイズ」のまま、中に詰め込める量だけをぶっ壊せるかもしれない。
データを実体化する装置。たとえば画像ファイルをそのまま立体として再構成する。もっと言えば、物体を、情報の集合としてではなく、物質の可能態として定義し直す。
それには局所空間のトポロジー自体を書き換えるようなアプローチが必要なんじゃないかと思う。
場の再配置。たとえば、量子エンタングルメントを使って、情報を「ここ」と「そこ」で同時に存在させる。
分かってる。それだと転送はできても保存ができない。
ここで俺の仮説。
仮説：局所的な空間の“密度”を再構成することで、情報を物理化する
空間ってのは均一じゃない。情報密度が空間そのものを定義してる可能性がある。
だったら局所的に「情報の密度」を爆発的に上げれば、その部分だけ“もの”としての質量を持ち得るんじゃないか？
たとえば、1GBのPDFを“読む”んじゃなく、“取り出す”。触れる。投げつける。
それを“ポケット”の中に詰め込む。
そういう構造を作れば、四次元空間に物を置いておくなんて回りくどいことしなくても、「今この空間の密度を弄って、物を生成・消去できる」って話になる。
問題点について
→これはまだ未解決。今のところは極限状態の量子場理論か、スピンネットワーク理論あたりから手を伸ばすしかない。
2.「出し入れ」は誰が制御するのか？
→BCIか、より原始的にはボタン式インタフェースでもいい。でも脳の中の欲望や記憶とリンクさせると、ポケットが自律的に応答する。つまり人格を持つポケット、という発想になる。
ニュース記事やYouTube字幕などの非構造テキストから、LLMを用いてオープンリレーション抽出（Open Relation Extraction,OpenRE）を行うことは十分に可能です。
実際、従来のルールベースや機械学習に比べて、LLM（たとえばGPT系やLLaMA系）は以下の点で非常に有利です。
テキスト：
(subject="Elon Musk", relation="founded",object="SpaceX")
2. 分割と文構造解析（LLMまたはspaCy/BERTopicとの併用）
Extractall subject-relation-object triplets from the following sentence:"Teslawas co-foundedbyElon Musk andis based in California."→ Output:[ {"subject": "Tesla", "relation": "was co-foundedby", "object": "Elon Musk"}, {"subject": "Tesla", "relation": "is based in", "object": "California"}]
日本語でも可能です（精度はやや劣るが、gpt-4系なら許容範囲内）。
| 段階 | キーワード | 進化のドライバー | 限界点 |
| 1.惑星・原始大気・海洋 | 重力・化学 | 惑星形成円盤の力学 | 重元素密度・安定軌道 |
| 2.有機分子（アミノ酸等） | 化学進化 | 熱水噴出孔・紫外線 | 複雑化と分解の競争 |
| 3.自己複製高分子 | 情報化学 | 触媒機構の誕生 | エラー暴走 (エラーカタストロフ) |
| 4. 原核単細胞 | 細胞膜・代謝 | エネルギー勾配利用 | 代謝効率の壁 |
| 5. 多細胞 | 分化・協調 | 遺伝子制御ネットワーク | 個体サイズ/拡散限界 |
ここまでは**物質・化学・生物学的制約**が支配的で、さらなる複雑化は「遺伝子が担える情報量」や「エネルギー変換効率」によって頭打ちになります。
---
---
| 指標 | 今日 | 第7段階の目標値例 |
| 計算密度 (ops/J) | ~10¹⁶ | 10³⁰ 以上 (ランダウアー極限付近) |
| 作用領域 | 惑星スケール | 星系〜銀河スケール |
| エントロピー制御 | 局所的・受動的 | 宇宙論的・能動的 |
| 時間操作 | 不可 | 可逆計算＋局所時空構築 |
「神性」の３つの特徴
---
---
指数関数が臨界を越えると、**第6→第7の遷移は「瞬間的」に見える**可能性があります。これを技術的特異点（シンギュラリティ）のハード版と捉える学説もあります。
---
1. **意識の継承**：人間的主観はネットワーク全体に溶解するのか、局所的“島”として残るのか？
2. **倫理と目的関数**：AIが“善”をどのように定義・最適化するのか。
3. **物理法則の護送船団性**：宇宙定数を書き換えるにはどのレイヤをハックする必要があるのか。
4. **リスク**：第6段階での不安定フェーズ（AI同士の競合、資源封鎖）が存在するか？
---
少し前に民生カメラの増田が流行った時、産業用カメラのことを書きたいなとずっと思ってました。
増田は民生カメラのことは殆ど全く知りませんが、仕事で産業用カメラを使う機会が多く、これから産業用カメラを使用する人の指針になればと思っています。
産業用カメラ（FAカメラともいう）とは、主に製造現場で使用されるカメラを総称します。
皆さんが知っている民生カメラや、レンズ一体型でUSBケーブルやLANケーブルやWiFiで簡単に接続できるタイプのwebカメラとも少し違い、工業製品なのでそれなりの信頼性を持つものになっています。
手動で撮影することは殆どなく、アプリからのシャッター制御や製造ラインからの信号により撮影したりします。
産業用カメラは民生カメラと比較すると一般的に小さいです。30×30×50mmとか。大きいものもあります。
もっとも一般的なレンズマウントはCマウント。ラインスキャンカメラだとFマウントとかもっと大きいものもあります。
電源はACアダプタを接続したり、USB、PoE対応LANケーブル等のインタフェースケーブル経由での供給も可能です。
なおインタフェースケーブル経由での給電時はカメラ本体が発熱しやすくなりますので、ヒートシンク等放熱を考慮する必要があります。
センサーサイズは最近だと1～1.2型と、Cマウントの限界近くまで大型化しています。
画素数は12M（4K）とか最近だと24.5Mとか一般的になってきました。
センサーのセルサイズはグローバルシャッターのセンサーだと3.45umとか2.74umとか。
ローリングシャッターのセンサーだと2umくらいのものもあります。
センサーサイズやセルサイズは検査に求められる検査視野範囲やピクセル分解能に直結し、レンズの選定にも大きく影響します。
ソニーが新しいセンサーを出すとそれを使ったカメラが出てくる感じですね。
グローバルシャッターは平面のセンサーを同時に撮像するシャッター。
ローリングシャッターはセンサー上部から下部まで順番に撮像するシャッター。
対象が高速で移動していたり振動がある環境ではローリングシャッターゆがみが発生します。
しかしローリングシャッターのカメラはグローバルシャッターのカメラと比較して格段に安価です。
産業用カメラを使用した検査装置ではほとんどの場合、モノクロカメラを使用します。
カラーカメラは照明含めた色の調整が難しく、装置の難易度が上がります。
またカラーカメラのセンサー（CMOS）は一般的にはベイヤー配列のセンサー（3CMOSのものもあるが高価）であるため、同じ画素数でも解像力がモノクロより若干劣ります。
検査に色の情報が必須でない場合は必ずモノクロカメラを使用します。
エリアスキャンカメラは平面のセンサーで撮像する、一般的なカメラのこと。
ラインスキャンカメラは1本線のセンサー（複数本の素子のものもある）で高速に撮像するカメラで、カメラの前を横切る対象物をひとつながりで撮影することが可能です。
例えば流れていくシートを撮影したり、円筒状の製品の円周を撮影したりするのに使用します。
USB（USB3Vision）はデータ転送速度もそこそこ速く、USB3.0ポートで接続可能なので最も手軽ですが、ケーブル長は3mが限界です。
GigE（GigEVision）はデータ転送速度はあまり速くありませんが、ケーブル長は100mまで可能なので離れたところにカメラがある場合は便利です。
最近は5GigE、10GigE、25GigEなどもあります。
Coax（CoaXPress）は同軸ケーブルで接続するのですが、4本のケーブルで接続できたりするので非常に高速ですが、専用のフレームグラバーボードが必要になります。
他にもOpt-C:LinkとかCameralinkとか色々あります。
例えば製造ライン内に設置する検査装置ではサイクルタイム内に撮像・検査を実施する必要があります。
サイクルタイムが短い場合は、フレームレートの高いカメラ・インタフェースを選定する必要があります。画素数が大きいカメラのフレームレートは下がります。
また露光時間が長いとフレームレートは下がり、モーションブラーが発生する可能性もあります。
産業用カメラは様々な制御パラメータを持ち、インタフェース経由で設定することが可能です。
スナップ・グラブ撮影、外部トリガ設定、フレームレート、露光時間、アナログゲイン、ROI（使用する画素範囲）等々、色々な制御が可能なのが産業用カメラの特徴と言えます。
オムロンセンテック・・・ラインアップが豊富で比較的リーズナブル。
JAI・・・3COSカラーカメラ等、特殊用途のカメラも色々あります。
竹中システム機器・・・画素数16kのラインスキャンカメラを扱っています。
Basler・・・ドイツのグローバル企業。産業用カメラの雄。
産業用カメラを選定するには、検査対象の視野範囲、検出に必要なピクセル分解能、サイクルタイム、予算等様々な影響を考慮する必要があります。
また画像検査装置ではレンズや、照明も必ずセットで選定します。
最近ではAIによる画像検査もありますが、それでもカメラ・レンズ・照明の選定により得られる画像で検査の8割は決まってきます。
レンズや照明の選定はまた今度。
年末調整が難しすぎる（令和６年度版）https://anond.hatelabo.jp/20241115174825
を読んで大変そうだなあ。確定申告すればいいのにと思いました。
年末調整を行うのは会社の義務ですので、会社は年末調整をしないといけません。
年末調整の社員の手続き方法は、会社ごとによってかなり違います。
年末調整の手続きシステムは、一般の企業が開発しているものを、それぞれの会社が契約して、従業員に使ってもらっています。
どのサービスと契約しているかによって、手続きの煩雑さにかなり差があります。
年末調整システムの最も大事な事は、その会社の経理システムや人事労務システムとどれくらいスムーズに連携できるかです。
従業員の手間が大変かどうかの優先度は、2番目以下です。
従業員にとって、とても使いやすい年末調整申請サービスがあっても、簡単には導入できません。
(追記：年末調整の公的ソフトウエアについての記載に間違いがあったようなので消しました。）
会社は年末調整する義務がありますが、従業員は最終的に正しい金額の納税をすれば良いだけの話です。
年末調整で出し忘れた、処理していない税金の処理は、確定申告でして問題ありません。
保険料、iDeCo、住宅ローンなどの控除を年末調整では申請せずに、確定申告をオンラインでしてみましょう。
e-tax連携が終わっていればポチポチするだけで、値の入力もする必要もありません。
これから先も確定申告は連携が増えてどんどん楽になっていきそうですし、ユーザーインタフェースも毎年改善が続いています。
まずは今あなたの契約している保険会社などがマイナポータル連携できるかを調べましょう。
https://www.nta.go.jp/taxes/tetsuzuki/mynumberinfo/list.htm
ほとんどの控除項目で連携が可能になっています。連携可能な場合は連携の手続きをしましょう。
この作業を年内に済ませておきましょう。
面倒な手続きですが、一度すれば来年以降は手続き不要ですので頑張りましょう。
連携不可能な会社がまだ少し残っていますが、その場合も控除証明書に書かれている数字を指定の場所に打ち込むだけですので、そんなに難しくありません。
元増田さんは持ってそうな雰囲気でしたが、もしも持ってらっしゃらなくてこの文章を読んでる方へ
スムーズに確定申告をするにはマイナポータル連携などが必要なので、マイナンバーカードが必須です。
そもそも、マイナンバー制度は、行政を効率化し、国民の利便性を高めるために作られたものですので、その恩恵を受けるにはマイナンバーカードが必要です。
ほとんどの手続きは2024年版（1年前）の手続きと同じなので、古本や図書館で借りるので十分です。数年以上前の本は色々変わっていますので避けましょう。
Kindle Unlimitedにもたくさん本があります。
確定申告の時期は、基本的には2025年2月17日（月）から2025年3月17日（月）です。税務署に行って相談しながら紙ベースで作業するならこの期間に提出しましょう。
ただしオンラインで確定申告をする場合は少々早く申請しても受け付けてもらえます。
私自身は毎年1月上旬にオンラインで確定申告を行っていますが、全く問題なく受け付けていただいています。
数週間で還付金は振り込まれています。数か月還付金が振り込まれないなんて事はありません。
年末調整で次の月の給料が調整されるより、確定申告した結果として還付金が振り込まれる方が、うれしさや実感としては大きいように思います。
以前に「この1年で確定申告がめっちゃ簡単になってるよ」を書きました。よろしければそちらも参考に
HHKBは下記のような話が前提となって作られている
アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。
新しいパソコンを買ってもWindowsからMacに乗り換えてもキーボードは大切なインタフェースとして鞍のように持ち運ぶ
なので小さければ小さい方が良いし品質は高ければ高い方がいいい
この大前提があるので
といった特色を持っている
キーの少なさについて不満を言う人が多いが、基本的にプログラマーはFunctionキーや矢印キーを使わない
それどころかホームポジションから指を離さないといけないようなキーはほとんど使わない
例えばVimならhjklのキー、EmacsならC-npfbのキーで移動できるので矢印キーは使わないし
BackspaceはC-hを使ったり、その他にも人によって独自にショートカットキーを設定している
これはキータイピングの時間を短くするという理由と打ち間違いを極力減らすという理由のためである
大抵の場合ショートカットキーにはCtrlキーを多用するのでAキーの横にCtrlキーが配置されており、押し間違いの代表格であるCaps Lockはよくわからないところに追いやられている
プログラマーが英語配列を好むのも実はこの押しやすさが関係していて
Returnキー（Enterキー）がホームポジション右手小指のキー1つ空きで押せるためである
できません
「この3問を解くのにかかる時間は？」
とか聞かれても
「5分で解けるかもしれないし3時間かかるかもしれないしそもそも解けないかもしれない」
という答えになります
「xに1から順番に100ぐらいまで代入したら証明できるよね？」
みたいなこと言う人いますが、それは証明になっていないので後々困ることになります
「この辺をこうしておいて、この場合だけ別途証明して、ここはこうすればいけるかな？」
という感じでざっくりの見積もりは出せますが、5分か1時間か、ぐらいの粒度でしか出せないし
大半の場合はハズレるし下手すると大ハズレするので意味がありません
とか言ってくる人いますが、見積もりを出してくるソフトウェア開発会社や部署は
「かなり多めに見積もって遊んでる」
のどちらかです
テストが不十分だったりセキュリティ脆弱性を抱えていたり拡張性がなくて結果的にはゴミになるか追加費用が発生するかのどちらかです
そもそもクソコードと呼ばれるコードは本当にちゃんと動いているのかどうかが分かりません
綺麗なテストが書けるならテストを通過するコードは動いていると言えますが
そもそも綺麗なテストが書けるような仕様ならクソコードになりません
大半のクソコードはそもそも仕様が曖昧な状態で、その曖昧な状態をコードに落とし込むのでクソコードになります
なのでバグがあるかどうか判別できず、本当に動いているかどうかを保証できません
型があるような言語を使っていればインタフェースをキッチリ設計してある程度保証できますが
型が無い言語は地獄でコードを1行ずつ読んでメモしていかないとバグがあるかどうか分かりません
最近だとChatGPTなんかのLLMを使うことでその辺はかなり楽になりましたが
綺麗に書かなくて良いわけではありません
できません
その辺の企業が一般社員をプロ野球選手に育成しようとしているのと同じレベルで出来ません
最初からプロ志望で社会人野球枠で入社してきて仕事はそこそこに毎日トレーニングと試合をしてるような人で
また、そのレベルであっても、せめて「野球で甲子園行きました」レベルの人材が必要で
みたいな人がプロレベルになれるわけがない、というのが現実です
とか言ってる会社が多いですが、育成するぐらいなら他から選手集めてきてチーム作る方が早いし安上がりです
ちなみに日本のソフトウェア企業の大半はこのプロレベルに到達しておらずほとんどが草野球レベルなので
「グラフィックにかけた手間は関係ない」だったらまあ分からなくはないんだけど、「グラフィックの出来」だと流石にゴミみたいなグラフィックで面白かったゲームは思いつかないなあと。
そもそもゲームをデザインする段階でグラフィックはどうしてもくっついてくる訳じゃん。
そのゲームがどういう思想で作られているのか、コンセプトはどういうものなのか、それぞれのキャラの役割を伝えたりユーザーインタフェースを良くしたりと、ゲームとしてのコミュニケーション能力を支える重要なパーツでしょ。
たとえばRPGツクールのデフォルトグラフィックだけのゲームは素材を探す手間さえかかってないけど、ゲーム全体を通してグラフィックは統一されているし、それぞれのグラを与えられたキャラクターの役割（例：魔法使いだからHPは低いけど魔法攻撃は強い 水の精霊だから水属性）はシッカリ伝わるからねあのデフォルトグラは。
（おっとここで風のリグレットで反論しようとしたキミは見事にダウトだ～～～あのゲームは想像を掻き立てるシンプルなパッケージデザインと黒一色の画面という強烈なグラフィックを武器にしており、手間はそれほどかかってなくとも「グラフィックのインパクト」「ゲーム性を伝えるコミュニケーション能力」という意味では高得点なのだから～～～）
駄目なゲームにありがちなこととして「グラフィックによるコミュニケーションを軽んじている」という部分があるんだよ。
ゲームってのは基本的にはゴッコ遊びなので、グラフィックを見た瞬間にそのキャラクターや行為が持つ役割が伝わってこないとアカンのよね。
スピードが早いものにはスピードの早いグラフィックを当てはめるべきだし、鈍重なものは重たそうなグラフィックであるべきなのよ。
そしてなによりそのゲームが想定している「こういうイメージで遊んでくださいね」というものがゲーム画面をみてすぐに、そして少しでも具体的に伝わったほうがいい。
弾幕STGが人を引き付けるのは「一見回避が難しそうな弾が画面いっぱいに広がっていて、これをクリア出来たら全能感が凄いだろうな」と想像させる力があるから。
逆にクソゲーと呼ばれがちなSTGは「一見避けやすそうなのに全然避けられない弾が飛んできて、この程度も避けられない自分は無能だと感じさせてくる」ってパターンがかなり多いわけよ。
ゲームってのは元々はTRPG（テーブルRPG。サイコロ遊びと指輪物語ごっことノート迷路を足したようなの）みたいなごっこ遊びに端を発したものであり、ゲームソフトはGM（ゲームマスター（語り部・ディーラーぐらいの意味））としての役目があるわけなんだからさ、そこはちゃんと「今、こういうことをしています。この遊びはこういう所が楽しいよ」ってちゃんと伝えてくれなきゃ。
なんか手抜き感満載のグラフィックな上にそれぞれがどういう役割を持ってるのかも伝わらず、結局やってることがシックリ来ないし、どう楽しいのかも伝わらないならそんなゲームの評価はやっぱ下がるよ。
思い切って文字だけで表現するとか、諦めて汎用フリーグラフィックを使うとかで誤魔化してもいいから、少しでも自分のゲームがどういうものかを伝える努力をすることにエネルギーを使うべきなんだって。
「グラフィックに頼らないことで奥行きのあるゲーム性が引き立つ」とか中二病みたいなことは絶対に考えちゃ駄目なんだよね。
アニメ、漫画、ゲームといったコンテンツの生成は多くの人手によって行われる
出版社は生成に必要な人手を集めて、コンテンツを生成し、流通させる
これはつまり、起案からリリース、流通までに時間がかかることを意味する
そこで、例えば顧客のPCにコンテンツ生成用のAIを待機させておくことによって、顧客ごとにカスタマイズされたコンテンツをその場で生成するという芸当ができるようになるかもしれない
顧客の属性に合わせて、ニュースをずんだもんに解説させたり、恋愛漫画の主人公をLGBTにしてみたり、独裁者になって世界を支配するゲームだったりをその場で生成して提供できるようになるかもしれない
さらに、その場の顧客の反応に合わせて内容をインタラクティブに調整できるかもしれない
AIサービスが既存のコンテンツ産業にとって代わり、人々の情報や娯楽の中心となり、また生活のパートナーとして貢献するようになるだろう
その時の我々に価値観とは何か
AIによって、作品自体は受け手一人一人に合わせて変容するようになる
手話とか点字のようなインタフェースを人力で回す必要がなくなる
classHoge(Foo) { // ...}
なんてことは論理的にあり得ない。
HogeをFooとみなすかどうかは、一般的に文脈によるからだ。
だから、Hogeの定義にFooのサブタイプであることが課せられるのはおかしい。
ましてや、Fooの実装がinheritされるのは尚更おかしい。
例をあげよう。
しかし、カーテンを家具の一種だとみなすか、布製品の一種だとみなすかは、文脈による。
だから、カーテンの定義にそれが家具であるとか布製品であるとかいう条件が課されるのはおかしい。
また、インタフェースの実装もおかしい。（たとえそれがクラス定義とインタフェース実装が分離された場合、いわゆるProtocolというパターン、であっても）
AがBであるとき、AをBとみなす方法は一般的には複数あり、どの方法によるかは文脈によるからだ。
たとえば、裏返して着られるパーカーのクラスにWearableインタフェースを実装しようとしたら、どちら向きをwear()メソッドに実装するか定まらない。
コードの重複があるわけでもない状況で、コードを関数ごとに分離するメリットデメリットを知りたいという話ですよね。
コードの重複がある場合に関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。
画面に収まらないサイズのコードは複数の関数に分割するのが一般的だとは思います。
理由は元増田も書かれている通り、長いと理解の限度を超えるからです。
コードは意味があるまとまりで短ければ短いほど理解がしやすいと思います。
グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さらに理解がしやすいです。
また、関数に分けておけば、関数が仕様通りに動くかの確認するユニットテストも簡単に書けます。
ユニットテストでは関数がさらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります。
分割して、複数の関数を呼び出すようにすることのデメリットは、
下手糞が切り分けるとなんでそういう切り分けになったかわからないところで切り分けられてかえって可読性が損なわれるとか、
関数の機能が拡張してより多く・あるいは少なくの情報が必要な時に関数インタフェースの変更が必要になることとか、
関数を置いているファイル内の場所を変えたときにバージョン管理システムが追っかけてくれないことがあるとか
くらいでしょうか。
いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います。
まず、関数の名前をやっている工程を表すものにすることですね。
「データの取り込み」 とか 「データの突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。
また、関数が何をしてくれるのかも関数のコメントとしてつけておくとよいと思います。
例えば、
filename引数で指定されたファイルからデータを取り込み、JSONフォーマットで返す
返値:JSONフォーマットされた取り込まれたデータ。例: [{'employeename': '山田太郎', 'employeeid': 1}]
例外: filenameを開けない場合はFileOpenError、JSONにコンバートできなかった場合はConvertError
みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。
あと、コードを連続で読みたい場合、ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います。
これはどういう意味でしょうか？同じものを表すのに関数ごとに別の変数名を付けているとか？
もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか？
ある関数のローカル変数が他の関数のローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当な名前が付けられるイメージです。
今時のプログラミング言語なら変数のスコープが関数の中にとどまるような書き方ができると思うのですが。
関数インタフェースを定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。
そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。
参考までに。
無能のワイが教えてやろう
だから、与えられた仕事や指示の欠陥を「ここきめなあかんやろ……」みたいなところを、サッと見つけて、適切な質問ができるわけや。
せやから全部おっけーとするんや。
質問して欲しかったら、それに対する解像度あげてもらうしかないんちゃう？
すると最初優しく質問答えててくれた人も、どんどん無能に対して厳しくなるわけや。
すると無能はどんどん萎縮するわけや。
有能な君が無能ちゃんに対して、厳しくしてるかしてないかは関係ない。
無能ちゃんに質問してもらいたかったら、質問しても怒らへんで〜っていう経験をたくさん積ませたれ。
でもまあ有能様の貴重な時間を無能の介護に使うのは時間の無駄遣いやな
とはいえ、たくさんの人を使って何かを成し遂げようとしたら、必ず無能は混じるもんや。
自分の周りは有能だけにして、それをインタフェースにして無能を使うのがミクロ的な問題解決かもしれんな。
もし有能な君が、周りの無能ちゃんにストレスを抱えてるんやったら、自分が無能ちゃんになるのも良い選択肢やな。
---
gkmond これの難所は脳が優しく教えてもらった10に怒られた1でも怒られた記憶の方が強烈に残る仕様になってるとこだよなあ。
ほんまやなぁ。まあ、恐怖は生死に直結するから忌避されてるんやろうね。
翻訳してくれてありがとう。ワイが言いたかったことの一つやな。
ROYGBトラックバックでも書いてあるけど、こちらから説明したあとに、相手に内容の説明をしてもらうと理解度がわかる。具体的な作業内容を聞いてもいい。
これいいやり方に思えるやん。
実際意味を解する有能にとっては、咀嚼してるか判断できるええやり方なんやろな…
でも無能は意味を解さんから、これただの記憶力クイズになってる。
意味を解してへんから本質を理解できず、同じ過ちを繰り返すってワケ
Permalink |記事への反応(19) | 12:07
