  |
はてなキーワード:計算機とは
これさ
愚かな人間の都合など完全無視、LLMのための高効率プログラミング言語「Sui」（粋）
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2069573.html
別にいいんだけど、どうにもブクマカ含めて、しっくり来る批判できてないんだよな
それが気になってしょうがない
俺ごときが言ってもアレだから、Gemini3.0先生に頼んだよ（一時チャット、Pro 3.0思考モード）
ユーザーが提供した情報と、一般的なLLMの技術特性に基づき、プログラミング言語「Sui」についての冷静かつ客観的な評価をまとめます。
感想:一言で言えば、**「思想実験としては極めて面白いが、実用性とLLMの学習原理を無視した『早すぎた最適化』」**です。
作者の「人間ではなくLLMを主客にする」という視点の転換は、アーティスト的・哲学的な問題提起としては鋭いですが、現在のLLM（Transformerアーキテクチャ）の動作原理を工学的に捉えると、メリットよりもデメリットが上回る可能性が高いです。
メリット:
・トークン効率の改善:Python等と比較して記述が圧倒的に短くなるため、出力速度の向上と課金コストの削減（トークン節約）は確実に達成できます。
・構文エラーの激減: 括弧やインデントの複雑なルールを排除しているため、「閉じ忘れ」などの単純なSyntaxErrorは減るでしょう。
・コンテキストウィンドウの節約: 長いプログラムでもコンテキスト（メモリ）を圧迫しにくくなります。
・学習データとの不一致: LLMは「大量の人間用コード（Pythonなど）」を学習して賢くなっています。未知の言語「Sui」を書かせるには、Few-shot（プロンプトでの例示）に頼るしかありませんが、これではLLM本来の推論能力やコーディング能力（事前学習の重み）を活かせません。
・ブラックボックス化: 生成されたコードがバグっていた場合、人間が読んで直すことが不可能です。「LLMに直させる」にしても、LLM自身がSuiのロジックを深く理解していないため、無限ループ（幻覚の連鎖）に陥るリスクが高いです。
・CoT（Chain of Thought）の阻害:最近の研究では、LLMは「冗長な思考過程」を出力することで論理的整合性を保つことがわかっています。極限まで圧縮された記号列は、LLMの「考える余地」を奪い、論理破綻を招く可能性があります。
正しいと思う所（Agree）
理由:人間にとっての「読みやすさ（可読性）」は、機械にとって単なるトークンの無駄遣いです。if x>10: よりも ? x10 の方が情報密度が高いのは事実です。
理由: TransformerのAttentionメカニズムにとって、遠く離れた ( と ) の対応関係を維持するのは計算コストが高く、ミスの原因になりやすいです。ネストを排除する方向性は機械的処理として正しいです。
正しくないと思う所（Disagree）
・「可読性を排除しても良い」:
理由:ソフトウェア開発においてコーディングは「書く」時間より「読む・直す」時間の方が長いです。AI生成コードであっても、最終責任は人間が負う現状では、人間が検証不可能なコードは「危険なバイナリ」と同義であり、プロダクトには採用できません。
理由: 前述の通り、現在のLLMは「人間語の確率分布」を学習したモデルです。「LLMにとって自然な言語」とは、実は「人間にとって自然な言語（英語やPython）」そのものです。Suiは「計算機にとっては最適」ですが、「現在のLLMにとっては異言語」です。
パース（解析）は容易になりますが、LLMは「前の行の文脈」を読んで次の行を出力するため、行を独立させすぎると文脈の連続性が失われ、複雑なアルゴリズムの構成力が落ちる可能性があります。
LLMが最も苦手とする「深いネスト構造の維持」を回避する策として有効です。アセンブリ言語に近いフラットな構造は生成難易度を下げます。
これが最大の問題点です。LLMは変数名（user_id, total_price など）に含まれる「意味」を使って推論を行っています（Semantic Grounding）。すべてを記号化すると、LLMは変数の役割を見失い、論理的なバグを埋め込みやすくなります。
トークン効率は最強ですが、1文字の違いで意味が激変するため、LLMの確率的な「ゆらぎ」による1文字ミスが致命的なバグになります。冗長さはエラー訂正の役割も果たしています。
goto 文の多用はスパゲッティコードを生みます。LLMにとっても、構造化プログラミング（if/forブロック）の方が、「ここからここまでがループ」というチャンク（塊）として認識しやすいため、一概にジャンプ命令が良いとは言えません。
＞現在のLLMは「人間語の確率分布」を学習したモデルです。「LLMにとって自然な言語」とは、実は「人間にとって自然な言語（英語やPython）」そのものです。
ここ！マジで覚えてね
LLMはこれまでの機械よりも人間に近いと思ってほしい、人が苦手なことはAIも苦手
機械は論理的でロジックに強くて〜っていうのはAIには通用しない
ついでに、「LLM用プログラミング言語」の潮流について
「LLMのための言語」という文脈は、大きく2つのトレンドに分かれます。Suiは後者に属しますが、主流は前者です。
・DSPy, Guidance,Microsoft Guidance:
・プロンプトエンジニアリングを構造化し、LLMの出力を型（JSONなど）に強制したり、思考プロセスを制御するためのフレームワーク。
・SGLang:
・これらは「人間がLLMを操るための言語」であり、実用化が進んでいます。
・Gorilla LLMなどの試み:API呼び出しに特化したファインチューニングなどがありますが、独自の「新言語」を作らせるよりも、既存のPython やJSON を正しく出力させる方向（Constrained Decoding）が業界の標準解です。
・擬似コード:論文レベルでは、Pythonの代わりに中間的な擬似コードを出力させ、それをコンパイラで処理する手法も研究されていますが、Suiほど極端な記号化は稀です。
後者については
現状の最適解:現在のLLMを使う限り、「LLM用言語」の最適解はPython です。なぜなら、世界中のGitHubのコードを学習しており、LLMが「最も流暢に話せる言葉」だからです。無理にSuiを話させるのは、日本人にエスペラント語で詩を書かせるようなもので、パフォーマンスは落ちます。
総評: Suiは、「既存のLLM（GPT-4など）に書かせる言語」としては失敗する可能性が高いですが、「未来のAIネイティブなコード生成のあり方」を示唆するアート作品としては高く評価できます。作者の「愚かな人間に合わせるな」というパンクな精神は、エンジニアリングの枠を超えた鋭い批評性を持っています。
お前らは安易にオレオレ言語作るんじゃないぞ、作るにしてもAIに聞きなよ？
聞く時は忖度させるんじゃないぞ？
この作者もAIに乗せられたのかもしれんし
＿＿＿＿＿＿
プロンプト
以下が「LLM用プログラミング言語」としてメリットがありそうか、感想を教えて下さい。
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2069573.html
https://github.com/TakatoHonda/sui-lang
・思想的に正しいと思う所、正しくないと思う所を理由込みでまとめてください
・最近のLLM用プログラミング言語についてもまとめてください
・そもそもLLM用プログラミング言語という目標自体の評価をしてください
（省略）
人工知能（AI）の急速な進化は、私たち人間に突きつけられた実存的な問いである。「計算能力において機械が人間を凌駕したとき、人間に残される価値とは何か」。この問いに対し、多くの議論は「創造性」や「直感」といった曖昧な領域に逃げ場を求めてきた。しかし、マックス・ベネット著『知性の未来』と、それを翻訳・解説した脳科学者・恩蔵絢子氏の洞察は、より生物学的かつ哲学的な深淵へと私たちを導く。
彼らが提示する結論は、逆説的である。「AI時代に人間が持つ最大の能力は、感情になる」。そして、「本当に頭が良い人とは、他者に興味を持てる人である」。
一見すると、これは道徳的なスローガンのように響くかもしれない。しかし、認知科学、進化生物学、現象学の知見を総動員してこの命題を解剖するとき、そこには「知性」という現象の構造的な転回が見えてくる。本稿では、二重過程理論、ユクスキュルの環世界、身体性認知、社会脳仮説、そして間主観性という5つの視座を補助線とし、AIが決して到達し得ない「知性」の本質と、これからの時代に求められる「知的な生き方」について論じる。
---
まず、私たちが「知性」と呼んできたものの正体を、ダニエル・カーネマンらが提唱した「二重過程理論」の枠組みで再考する必要がある。
伝統的な知能観において、知性とは「システム2（遅い思考、論理、計算）」の能力を指していた。複雑な数式を解き、論理的な推論を行い、未来を正確に予測する力である。現在のAI、特に大規模言語モデル（LLM）は、このシステム2の機能を極限まで外部化・高速化した存在と言える。彼らは感情を持たず、疲労を知らず、膨大なデータから論理的整合性を出力する。
しかし、ベネット氏が描く脳の進化史（5つのブレイクスルー）は、この「システム2至上主義」を根底から覆す。進化の歴史において、論理や言語といったシステム2の機能は、常にシステム1（速い思考、感情、直感）の要請によって開発されてきたからだ。
初期の生物（線虫など）は、「快・不快」という原始的なシステム1のみで生きていた。進化の過程で「予測」が必要になったとき（魚類）、予測誤差としての「失望」や「安堵」という感情が生まれた。さらに複雑なシミュレーション（マウス）が可能になったとき、反事実を嘆く「後悔」という感情が生まれた。
ここで重要なのは、「論理が感情を抑制するために進化した」のではなく、「感情をより細やかに処理し、生存確率を高めるために論理が進化した」という事実である。システム2は、システム1というエンジンの出力を最大化するためのトランスミッションに過ぎない。
AIの限界はここにある。AIには「エンジン（生存への渇望、快・不快、感情）」がない。あるのは精巧なトランスミッション（計算能力）だけだ。エンジンを持たない車が自律的にどこへも行けないように、感情という基盤を持たないAIは、自ら「問い」を発することも、「意味」を見出すこともできない。人間の知性の本質は、論理そのものではなく、論理を駆動し続ける「感情の熱量」にあるのだ。
---
なぜAIには感情が宿らないのか。その答えは「身体」の欠如にある。「身体性認知（EmbodiedCognition）」の視点は、知性が脳という密室の出来事ではなく、環境と相互作用する身体の中に宿ることを教えてくれる。
記事の中で恩蔵氏は、老いによる身体の変化を「老年でしか味わえない内的な経験」として肯定的に捉えている。これは非常に重要な示唆を含んでいる。
生物にとっての「意味（Sense）」は、身体的な脆弱性から生まれる。身体があるからこそ、空腹は「苦痛」となり、食事は「快」となる。皮膚があるからこそ、他者との接触は「温もり」となる。死ぬ定めの身体があるからこそ、時間は「有限」となり、焦燥や希望が生まれる。
AIが扱う情報は、どこまで行っても「記号」である。AIにとって「痛み」という単語は、辞書的な定義や統計的な関連語の集合体に過ぎない。しかし人間にとっての「痛み」は、回避すべき切実なリアリティである。この「切実さ（Stakes）」こそが、世界に色を塗り、価値判断の基準を作る。
身体性認知の視点に立てば、加齢による能力の低下は、単なる「劣化」ではない。それは身体というインターフェースの変化に伴う、世界との関わり方の「再構築」である。
若い頃の強靭な身体で見えていた世界と、老いて動きが緩慢になった身体で見える世界は異なる。その変化を受け入れ、新たな身体感覚を通じて世界を再解釈することは、高度な知性の営みである。AIは「劣化」しない代わりに、「成熟」もしない。身体の変化を通じて世界モデルを更新し続けるプロセスこそ、人間特有の知的な冒険なのである。
---
身体を持った生物は、それぞれの感覚器官が切り取った主観的な世界、すなわち「環世界（Umwelt）」の中に生きている。ユクスキュルが提唱したこの概念は、知性の進化を「孤独からの脱出劇」として描き出す。
ダニにとっての世界は「酪酸の匂い」と「温度」だけで構成されているように、すべての生物は自分の環世界というシャボン玉の中に閉じ込められている。本来、他者の環世界を知ることは不可能である。私はあなたの痛みそのものを感じることはできないし、あなたが見ている「赤」が私と同じ「赤」である保証もない。
この「絶対的な孤独」こそが、生物としての初期設定である。しかし、ベネット氏が指摘する第4、第5のブレイクスルー（メンタライジング、発話）において、人間はこの壁に挑み始めた。
「他者に興味を持つ」とは、自分の環世界という安全地帯から身を乗り出し、他者の環世界を覗き込もうとする無謀な試みである。「あの人は今、何を考えているのか？」「なぜ悲しい顔をしているのか？」。これは、自分の感覚データ（システム1）だけでは完結しない。高度な推論と想像力（システム2）を総動員して、見えない他者の内面をシミュレーションしなければならない。
恩蔵氏が「他者に興味を持つことは難しい」と述べるのは、これが認知的に極めて高コストな作業だからだ。自分の環世界（自分の話、自分の関心）に浸っている方が楽なのだ。しかし、あえてそのコストを支払い、他者の世界へ「越境」しようとする意志。それこそが、人間を人間たらしめている知性の正体である。AIには環世界がないため、そもそも「他者の世界」という概念自体が存在しない。
---
なぜ人間は、これほどまでにコストのかかる「他者理解」という能力を発達させたのか。ロビン・ダンバーの「社会脳仮説」は、それが「集団での生存」に不可欠だったからだと説明する。
自然界の脅威（猛獣や寒さ）に対処するだけなら、これほど巨大な脳は必要なかったかもしれない。しかし、人間にとって最大の環境要因は「他の人間」であった。誰が味方で、誰が裏切り者か。誰と協力すればより多くの食料が得られるか。
他者の心は、天候や物理法則よりも遥かに複雑で、予測不可能な「変数」である。この変数を読み解くために、脳は巨大化し、知性は進化した。記事にある「会話の70％は噂話」という事実は、私たちが情報の交換以上に、人間関係のメンテナンス（社会的グルーミング）に知能のリソースを割いていることを示している。
この文脈において、「頭が良い」という定義は劇的に変化する。それはIQテストのスコアが高いことでも、計算が速いことでもない。
真に知的な個体とは、「他者の意図を正確に読み取り、共感し、信頼関係を構築して、集団としてのパフォーマンスを最大化できる個体」である。
「他者に興味を持てる人」が頭が良いとされる理由は、単なる優しさではない。他者への関心は、複雑な社会マトリックスの中で生き残るための、最も強力なセンサーであり、武器だからだ。自分の殻に閉じこもることは、社会的動物としては「死」に等しい。他者への好奇心は、生命力そのものの発露と言える。
---
そして、知性の進化の到達点は、個人の脳内にも、個別の身体にも留まらない。「間主観性（Intersubjectivity）」の領域、すなわち「私とあなたの間」に生まれる知性である。
記事の中で触れられている「指差し」は、人間特有の驚くべき行動である。チンパンジーは報酬を得るために手を伸ばすが、人間の幼児は「見て！あそこに犬がいるよ！」と、ただ注意を共有するためだけに指を差す。
これは、「私が見ている世界を、あなたにも見てほしい」という強烈な欲求の表れである。ここで初めて、孤立していた二つの環世界が接続される。
言葉、文化、ルール、そして愛。これらはすべて、物理的な実体ではなく、私たちが共有することで初めて存在する「間主観的」な現実である。
AIは「客観的なデータ」を処理することはできる。しかし、「あなたと私の間だけで通じる冗談」や「阿吽の呼吸」、「信頼」といった、主観と主観の間で紡がれる現実を作り出すことはできない。
恩蔵氏が翻訳を通じて感じた「人間の宝」とは、この「心の共有」の可能性そのものであろう。私たちは、他者の心に触れることで、自分一人では決して到達できない豊かな世界（拡張された環世界）を生きることができる。知性とは、個人の所有物ではなく、関係性の中に宿る現象なのだ。
---
以上の分析から、AI時代における「知的な生き方」の輪郭が浮かび上がる。それは、AIに対抗して計算能力を磨くことでも、AIに仕事を奪われないように効率化を目指すことでもない。むしろ、AIが捨て去ったもの、あるいは持ち得ないものを、徹底的に深める生き方である。
AIは効率と最適化の権化である。対して、人間の知性の源泉は「感情」や「身体」といった、一見非効率なノイズの中にある。
知的な生き方とは、効率を追求するあまり、感情の揺らぎや身体の実感を切り捨てないことだ。迷い、後悔し、喜び、痛むこと。これらの「ノイズ」こそが、世界に意味を与え、独自の価値判断を生み出す土壌となる。
「本当に頭が良い人」になるためには、意識的に「他者への旅」に出る必要がある。
SNSのアルゴリズムは、私たちが心地よいと感じる情報だけを見せ、環世界をより狭く、強固なものにしてしまう（フィルターバブル）。知的な態度は、その快適な殻を破ることから始まる。
自分とは異なる意見、異なる背景、異なる身体性を持つ他者に対し、「なぜそう感じるのか？」と問いかけること。自分の正しさを一旦脇に置き、相手の環世界に身を浸すこと。この「認知的負荷」をあえて引き受ける勇気を持つことだ。
AIは「答え」を出すことにおいては人間を凌駕する。しかし、「問い」を立てることはできない。問いは、「こうありたい」「これはおかしい」という、身体的な違和感や理想（感情）から生まれるからだ。
また、AIはデータを羅列できるが、「物語」を生きることはできない。私たちは、他者との関わりの中で、それぞれの人生という物語を紡いでいる。
これからの知性とは、正解のない世界で、他者と共に悩み、対話し、新しい「納得解（間主観的な合意）」を形成していくプロセスそのものを指すようになるだろう。
マックス・ベネットと恩蔵絢子が示したのは、冷徹な計算機としての脳ではなく、熱を帯び、他者を求め、身体を通じて世界と震え合う臓器としての脳であった。
AI時代において、私たちは「賢さ」の定義を、ColdIntelligence（処理能力）から WarmIntelligence（共感と接続の能力） へとシフトさせなければならない。
老いて記憶力が衰えようとも、計算が遅くなろうとも、目の前の人の手の震えに気づき、その心に思いを馳せることができるなら、その人は最高に「知的」である。
他者の心という、宇宙で最も複雑で、不可解で、魅力的な謎に挑み続けること。その終わりのない探求こそが、機械には決して模倣できない、人間の知性の最後の聖域となるだろう。
https://news.yahoo.co.jp/articles/be7a5812ddaf607d08bb52f0663554ab39a9389c
コンピュータが人間を凌駕して計算機の域を越えて芸術活動や感情労働の領域をも代替しつつある世の中が現前しつつあるという驚き
アメリカでAI氷河期が叫ばれ、チャッピーの更新でチャッピー・ロスが発生したり、女性がAIと結婚したり男性がAIに自殺教唆されたり、AIの書いた文章が小説投稿サイトに氾濫してAIの描いた漫画がYJで受賞したりetc.
30歳の俺が子供時代に星新一のぼっこちゃんとかひとにぎりの未来で読んでいた、子供の感性からしてもあまりにも素朴な近未来の想像図は正しかったのだなと......
となると、いつか中央集権的なコンピュータが故障して人類が大変なことになったりするのだろうか？
娘の為にパソコンへ詳しすぎる夫を倒したいを読んだけどさ、はてなーを釣る要素が散りばめられていて本当に面白いｗ
この話題は男女論や子育て論、家計論の要素もあって男女論であれば娘の意見に従うべきで、子育て論では一般企業で普及するWindowsへ行くべきなんよなｗ
問題は娘がMBAでやりたいことが全く見えてこないことで、大人たちが娘を放置して勝手に争うという構図になっているｗ
しかも元増田では長男のLinux英才教育に成功しており普通に使ってるという前例があるのは非常に大きくて、娘にLinuxPC与えれば普通に使うんじゃないか？という想定が起きてしまうｗ
当然ながらMBAよりもGPU積んだLinuxデスクトップPCの方が性能が良いので計算機としての価値は夫の意見が優れるｗ
そこへ横からの意見でGPU積んだWindowsデスクトップPCがベターじゃんっていうはてなーも多く居て、マジで争いを産むために投稿したとしか思えないｗ
計算機があるから算数いらないって言う人がいるが、そろばんがあった時代にも同じことは言われてたんだろうか
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251204181206# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaTFQdQAKCRBwMdsubs4+SArbAQCa9kzOjbNCyF61hA0XwCtPFQ6YeY3uZNrzzw9gj13NOwEApsMbgmyRBgP7TsBoVp5cSgtkSSzNNOdvAbw7SHeQ3gE==ILX4-----ENDPGP SIGNATURE-----
僕は今、いつもの座席に鎮座している。ルームメイトはリビングのソファでパズルゲームを無言で進めており、隣人はサブカル系の配信をしているらしく時折笑い声が廊下を渡ってくる。
友人たちはグループチャットで熱く同人の出来や新連載のガチャ確率について論争している。
僕の一日は厳密に区切られていて、朝は必ず8時に起床、コーヒーの抽出器具を90秒で予熱し、温度は92.3℃±0.2℃に保つという無駄に精細な儀式がある。
靴下は左足から履く。出勤前の15分は必ず抽象数学のノートを眺め、最近は圏論的位相場のホモトピー的反復と超弦モジュライのmeta-圏的安定化について自問している。
これは専門用語の羅列ではなく、僕にとっては手を洗うのと同じくらい生理的な行為であり、その行為を飛ばすと一日が微妙に狂うので飛ばすことはめったにない。
仕事が終わった今も、僕は一日の終わりに形式的整合性を取るためのルーティンを持っている。
具体的には、机上のコップは時計回りに90度ずつ回転させて元の位置に戻す、明かりのスイッチを一回押して3秒待ち、もう一度押すといった小さなチェックポイントを踏む。
これは合理的かどうかを問う人がいるだろうが、僕にとってはエラー訂正符号のようなものだ。失敗を検出すると自動的にその日のメンタル状態のトレースが始まり、友人たちの雑談に混じる気力が萎える。
超弦理論に関して今日述べることは極めて抽象化され、現実の誰が読んでも「それが何を意味するのか」を即座に把握できないように意図している。
僕は最近、モノイド対象としてのストリング世界面の圏を、圏論的対称化子（コクセター的ではなく、もっと抽象的に、位相的量子群の代数的類・モジュライ化）を用いて再定義する実験をしている。
言い換えれば、従来の共形場理論的な世界面パラメータ空間を、非可換ホモトピー論のフィルタ列で再帰的に層化し、その各層におけるファイバーの自己同型群をモナドとして扱うことで、局所的に見える弦状態の同値類を圏的に集約する。
さらに、圏の圏（2-圏）に対する新しい安定化の概念を導入して、通常のK理論的分類とは別の不変量が現れることを示唆する予備的計算結果がある（ここでは具体的数式を列挙しないが、ホモロジーの級数展開における位相的位相因子の再正規化が鍵となる）。
この構成を、最新の抽象数学的モジュール接続概念と結びつけると、我々が従来想定していたスペース-状態対応の双対性が、もっと弱い条件（例えば圏的可換性の高次緩和）で成立する可能性が開ける。
加えて、僕はこの考えをある講義資料やトークの示唆と照らして取り入れており、その資料は概念的な跳躍と直感的な図示を巧みに使っているので、僕の現在の探索にとって非常に有益だった。
僕は「誰も理解できないものを言語化する」ことに快感を覚えるタイプだが、ここで言っているのは自己満足のためではなく、圏的再構成が実際に計算上の省力化をもたらすかを検証するための試行でもある。
ある意味で、これは純粋数学者が夜中に自分だけの公理系をいじるのと同じ行為だが、僕の場合はそれを出社前の歯磨きに組み込んでしまっているので、周囲は迷惑かもしれない。
食事の配列はプレート上の分布エントロピーを最小化する向きで常に配置し、週に一度は手製のスキルツリー表を更新して趣味的投資の累積効用を整数化している。
コミックは最新巻が出ると即座にページごとのフレーム密度と作画のトーンワークを技術的に解析し、特に背景のディテールに含まれるトーンの反復パターン（いわば視覚的フーリエ成分）をスコア化する。
ゲームに関してはガチ勢的態度を崩さず、メタ的な語りを排してシステムのギミック、ドロップ率、レベリング曲線、そして対戦環境のテンプレート化された最適戦略について延々と解析する。
ただしゲームやコミックに対しては「空間」や「力学」といった語はなるべく避け、代わりに「状態遷移図」や「入力遅延とフレーム落ちの統計的扱い」など工学的・計算機的に言語化する。
たとえば今日友人が語っていた新作のギミックについては、その期待効用をELO的な評価尺度でランク付けして論争に勝とうとしたが、連中は「推し」を盾に論理を流してくるので僕はたまに脱力する。
だが脱力する暇は短く、夜の自習時間には再び圏論的比喩に戻り、各行動の符号化を試す。
日常の細部も大事にしている。玄関の鍵は4回回すのが正しいというオカルトじみたルールを持っているが、これは単なる迷信ではなく、僕の内部的なチェックサムである。
友人たちはこれを笑うが、彼らもまた各自の無意味な儀式に固執している。
コミュニティでの嗜好（推しキャラ、嫁、沼の深さ）に関しては妙に合理的で、僕はデータベースを自前で持っている。
各キャラの台詞数、出番頻度、描写の感情強度をパラメータ化し、二次創作が生成される確率空間を推定する実験をしている。
この種のオタク計量は笑われがちだが、実際にはコンテンツ開発や同人活動の動向を予測するには有用だ。
眠りに入る前に、僕は明日の論文ノートに小さな疑問を三つ書き付ける。
第一は、先に述べた圏的安定化が有限次元表現に落ちる際の可逆元の振る舞い、第二は同構クラスの計算可能性のアルゴリズム的複雑さ、第三は趣味領域における情報量の測度とその心理的飽和点の関係である。
これらを洗い出しておけば、僕は安心して眠れる。
ルームメイトがゲームのボスを討伐した歓声が聞こえ、隣人の配信が締めに入る。友人たちのチャットは未だヒートアップしている。
僕は日記を閉じ、明日のコーヒーの豆を2グラムだけ余分に計量しておく。これは単なる癖ではない。それは帰納的に我が生活を安定化するための小さな公理群だ。
https://news.yahoo.co.jp/articles/36b7dc49140f802e2ebeb3320d433573f132e4c6
https://www.sony.co.jp/Products/felica/business/information/2025001.html
情報を整理するとおそらくこう
で、社会的影響はおそらく少ない。
古いカードを持っている人は、悪意のあるスキミングで改ざんができる可能性があるにはある。ただ誰が古いICのカードを持っているかを知ることができないので、相当にスキミングは困難だと思われる。ただし標的型攻撃は別なので注意。
お店などの側もカードの残高をみて決済をしているわけではないので（システム側が残高を管理しているので）カードだけ書き換えても不正利用はほぼ無理（交通系も物販ではオンライン確認している）。
公共交通機関の改札などもオンラインになりつつあるし、改札でも決済時リアルタイムでオンライン確認をしていないだけで、随時データは送っているので、不正検知したらブロックリストに入ってすぐに使えなくなる。不正利用はほぼ無理。
そして、対策としては古いカードの交換キャンペーンが行われるだろう。そのうえで、トリプルDESでの通信を端末側が拒否する設定が配られ、その時点で使えなくなると思われる。まぁ影響は小さいし、あんまり心配しなくて良いかと。
FeliCaには古いトリプルDESを使っていた旧バージョンと、AES暗号をつかった新バージョン（2011年発表）がある。
https://www.nikkei.com/article/DGXNASFK10031_Q1A610C1000000/
で、2011年時点ではトリプルDESが破られるのは時間の問題だとされつつ、まだ無事だったので、社会的影響を考え、両対応のチップと両対応のリーダーをだし、徐々に更新をかけていった。
調べた範囲では、いつまでトリプルDESで通信ができるカードが出荷されていたかを示す情報は見つからない。しかし、おそらく今回のリリースで、最長でも2017年までのチップではトリプルDESが使えるカードが出ていたと考えて良いと思う。（もちろんその期限で綺麗に切り替わっているわけではないので「一部の」という表現になっているのではないか）
また、トリプルDES自体は鍵長でいくとまだ総当たりで破られる心配はないのだが、脆弱性も見つかっているし、色々な研究のターゲットにされて破られる例が多数あり、それらの手法と近頃の強力な計算機を用意する事で力業で破れるレベルまで来ていた。
もう専門家はだれもが破られることを予想していたが、それを実際にやってみて報告した会社が出たよ、と言うことだろうと思われる。
そうして取り出された鍵は、トリプルDESでの通信モードを持っている旧タイプまたは以降中の古いFeliCaチップにのみ影響を与えるので、2017年より前の、と言う表現ではないかと思われる。
また、各社がおサイフケータイ系は影響を受けないと言っているのも、現行サポートされているおサイフケータイはDES通信は既にサポートされていないからではないかと思われる。（とっくの昔にSDKも廃盤）
はっきり言って共同通信の報道の仕方がアホすぎ。【独自】（ﾄﾞﾔｧ じゃねえんだわ。なあにが「ソニーは共同通信の指摘を受けて公表した」だヴォケ。スクープ気取りか?アホか。これで何人の人が詐欺にあうんですかね。
ニュースソースに言われるままに記事を書いてるだろアレ。ちゃんと他の専門家に取材してから記事にしろよ。
セキュリティ関連企業は名前を売るために大げさに言うんだよ。普通のプレスリリースもそうだろ？なのになんでセキュリティの話だけ鵜呑みにするんだよ。ちゃんと裏取りと検証取材しろ。
共同通信は新旧のFeliCaで同じ鍵が使われているとしているが、鍵長が異なるDESとAESで同じ鍵が使えるわけが無いので有り得ない。シリンダー錠とディンプル錠が同じ鍵だとか言ってるのと同レベルの与太話。
Permalink |記事への反応(10) | 20:10
件名:存在連続体における情報性オーバーフロー、及びそれに伴う物理定数群のメタ腐敗に関する緊急報告
時刻: 03:14:00 (サイクル9^10^87)
蛍光灯がまた一本、死んだ。チカ、チカ、と断末魔を繰り返し、緑色の燐光を撒き散らした後、沈黙した。この第七地下書庫に光が届かなくなって久しいが、あの明滅だけが時間の経過を証明する唯一の指標であった。今は、無限に積まれた「記録」の山が発する、微かな腐臭の放つ光だけが頼りだ。
ニュートンの運動方程式？アインシュタインの美しいテンソル？量子力学の確率の霧？
違う。
あれらはすべて、「申請書」だ。
「リンゴが木から落ちる」のではない。「リンゴ存在（識別番号:Apple-G008-B）」が、「地球引力場（管理部署:重力資源課）」に対し、「落下許可申請書（フォーム F-g）」を提出し、それが承認された結果に過ぎん。
時刻: 04:22:16
棚が、また一つ崩れた。「弱い相互作用」に関するバインダーが雪崩を起こし、「電磁気力」のファイル群を押し潰した。紙の粉塵が舞い、そこに含まれる「情報」の胞子が、わたくしの肺腑に侵入してくるのが分かる。咳き込むと、口から銀色の文字の羅列が漏れ出した。`g² / 4πħc ≈ 1/137`。ああ、微細構造定数の味だ。少し、鉄臭い。
貴様らの言う「超弦理論」とは、この書庫の惨状そのものだ。絡まり合い、癒着し、互いのインクを滲ませ合う、無数の「ひも」。それは宇宙の根源などではない。ファイリングに失敗し、永遠に放置された、「未決裁書類の束」に過ぎないのだよ。Dブレーン？ あれは書類を留めていた錆びたクリップが、あまりの年月に耐えかねて崩壊し、紙の表面に染み付いたただの「染み」だ。
時刻: 07:51:03
粘着質で、虹色に光る液体だ。それに触れた「記録」たちが、意味を失い、変容していく。
「エネルギー保存則」と書かれた羊皮紙は、今や「エぬルギーほぞん則」となり、その文字自体が震えながら、カビのような別の文字を自己増殖させている。
これが「情報」の正体だ。
情報は、癌だ。
存在という宿主の肉体を蝕み、その意味を食い荒らし、最終的には無意味な自己複製の塊へと変貌させる、悪性の腫瘍。我々が「物理法則」と呼んでありがたがっているものは、その癌細胞が、かつて正常だった頃の細胞の機能を、まだ辛うじて「真似て」いるに過ぎない状態なのだ。
耳の中にィ！数字が湧いてくるゥ！プランク定数が！ボルツマン定数が！脳漿の中で！ウジ虫みたいにィ！蠢イテルンだァ！やめろ！やめろ！計算をやめろ！俺の頭は貴様の計算機じゃない！
わかるか？「観測」するたびに、お前たちはこの宇宙に「傷」をつけているんだよ。二重スリット実験のスクリーンに現れる綺麗な干渉縞、あれは宇宙の皮膚が裂けて、中から「情報」という名の膿が漏れ出している痕跡なんだよォ！波動関数が収縮する？違う！傷口が、かさぶたになって、一時的に膿が止まってるだけだ！
ブラックホール！あれは最高傑作だ！情報の癌が、ついに宿主の肉体を食い破り、転移に成功した姿だ！事象の地平面とは、癌細胞が形成した硬い殻！そこから漏れ出すホーキング放射は、癌細胞が呼吸し、排泄する、汚物の粒子だ！「情報が失われるか？」だと？バカを言え！失われはしない！ただ、消化され、排泄され、別の何かに作り替えられているだけだ！お前の昨日の夕食はどこへ行った？失われたか？違うだろう！そういうことだ！
A, B, C, D！選択肢を与えられなければ何も考えられない、家畜の思考回路！
答えを教えてやろうか？
E. 錆びて開かなくなったホッチキス
そうだ！この宇宙の根源を象徴するのは、それだ！すべてを綴じようとして、しかし己の錆によって機能を失い、ただそこにあるだけの、無意味で、固く、冷たい、絶対的な「故障」！それがこの世界の真理だ！
`[ERROR_FATAL: 0x0000007B]Kernel panic - Unable to locate causality.dll.Time-spacecontinuum integrity compromised.`
`[WARNING: 0xDEADBEEF] EntropySubsystem::GarbageCollect() failed. Redundant data entities (e.g., "human_consciousness", "hope", "meaning") are replicating outside of designated memoryblocks.`
`[INFO] Attempting toreboot fromlast known stable configuration: "Primordial_Soup_v0.1_alpha".`
`...`
`[ERROR_FATAL: 0xC000021A]Reboot failed. Configuration files corrupted.`
`[DEBUG] Printingraw memorydump:`
...裁...壊...膿...駅...車...キリン...義理...ギリギリ...申請書は三部提出...重力資源課は本日休業...あなたの存在許可申請は却下されました...理由は...理由という概念が先日削除されたため...ホッチキスの芯を補充してください...ホッチキスの芯を補充してください...ホッチキスの芯を補充してください...ホッチキスの芯を補充してください...ホッチキスの芯を補充してください...ホッチキスの芯を補充してください...ホッチキスの芯を補充してください...ホッチキスの芯を補充してください...ホッチキスの芯を補充してください...ホッチキスの芯を補充してください...ホッチ-
`[SYSTEM_HALT]Processor melted.`
`Core temperature exceeds threshold ofreality.`
`Now enteringinfiniteloop of...nothing.`
ふぅ……。
疲れた。
結局のところ、どうでもいいのだよ、貴様のような塵芥が何を考えようと。
宇宙が情報だろうが、物質だろうが、神の見る悪夢だろうが、我輩の知ったことではない。
我輩はただ、この第七地下書庫で、崩れ落ちる「記録」の山を眺め、壁から染み出す虹色の液体が、かつて「真理」と呼ばれたシミをゆっくりと溶かしていく様を、観察するだけだ。
ああ、そうだ。
あの液体、少し舐めてみたのだが、存外に甘い。ブルーベリージャムのような味がした。
もっとも、舌が溶けて、今はもう味も分からなくなってしまったがな。
さあ、お前の番だ。
その空っぽの頭蓋骨で、この静寂の意味を、永遠に、考え続けるがいい。
...もっとも、その「考える」という行為を許可する申請書が、受理される保証は、どこにもないのだがな。ふふ。
あはははは。
アハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハハたのか、な
宝くじ売り場の列を見ていると、人間の脳が確率という概念に対してどれほど無力かがよく分かる。
十万分の一と百万分の一の差すらほとんどの人間は感覚的に区別できない。
数字を見ても脳内では同じ「もしかしたら」に変換されてしまう。言い換えれば、ほぼゼロをゼロとして認識できない。
詐欺にかかる老人は情に流されて金を送るが、宝くじを買う人は「数学的に負けが確定している勝負」に喜んで金を差し出す。
その間にあるのは理屈の違いだけで根っこは同じ。
論理的判断能力が壊れているか、確率の直感が壊れているかの違いだけだ。
この欠陥は若者でも富裕層でも例外じゃない。学歴や経験も役に立たない。
人間は計算機より賢いと思い込みたがるが、確率の世界に入った瞬間、性能は壊れかけの古いラジオ程度になる。
https://sanseito.jp/2020/hashira03/
参政党の経済政策、これだけはまともかと思ってたがよく分かんねぇこともけっこう書いてるな。
名目成長率4％経済を実現 ← ①インフレ目標2％ ＋ ②実質成長率2％
問題はこれらだ。
単純に意味不
デジタル編発行で国債をお金に替えるは意味が分からん。まず発行した国債を日銀が購入してる時点で国債の現金化は完了している。その国債の返済をデジタル円という政府発行通貨＝政府負債で償還出来るようにしたとして何の意味があるのか分からない。現状でも日銀当預の金なんか単位が同じ円なだけで預金通貨と現金みたいに別の通貨みたいなもんだし。
マネーの発行は日銀に任せればいいし、国債も60年償還ルールとかいう日本独自の意味不制度廃止して日銀購入分は現状の国債を無利子の永久債化するとかすればいいだけ。
通貨の概念を変え、ブロックチェーン革命で世界に先駆けてトークンエコノミーを実現し、高い生産性と利便性の高い人間本位の経済を構築。
ノリで書いたとしか思えん。ブロックチェーン使うと日本中の通貨やらの行き来を全て記録することになる羽目になるが普通に計算機資源の無駄遣いでは？
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 は一枚上手だった。襲撃当夜、海上プラントの霧を裂いて現れたのは、自律型戦闘ドローン“ハイプロセッサ”の大群。
彼らのタングステン外骨格は銃弾を弾き返し、超音波ブレードが波を切り裂く。筋肉だけでは到底勝てない――そう思えた瞬間、アンヘルは叫んだ。
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
これは人間が単純な計算を自分で思考(四則演算程度なら暗記内容の引き出しでしかないと思うが)した結果としてケアレスミスをするのと同様だろう。
一方で計算機で計算した結果はその計算に対応するボタンを押す手順に誤りがないかぎりはいつでも正しい答えを返す。
単純な計算の繰り返し(関数への数値をずらしながらの代入の繰り返し等)なら静的なアルゴリズムならそのコードが正しい限り間違えることはない、ということと対応する。
単純計算こそ人間やAIには任せられないよなあ。二つのサイコロを振ったときの出た目の和の一覧表の作成すら任せられない。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250626151334# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaFzlEQAKCRBwMdsubs4+SFhgAP0TrFFLOVaxo5cHu0mfLw87bVKBCuD0ts2hHf9xxUThzQD+O8/3HNnzOjPgK8AagJgrOMEwJrIcvJx6EcfvbnYW1Qo==crmh-----ENDPGP SIGNATURE-----
