投稿者: Ren Kato

大手コンサルティングファームの広告を見ていると、「AIに実務は代替できないからこそ、生身の人間の伴走が必要だ」という言説が目につきます。伴走が価値になる場面は、確かにあります。合意形成や経営判断、変革の推進は、人にしかできない仕事です。

しかし、現場でプロダクトを組んでいる立場から見ると、「AIにできないこと」を売り文句の中心に置く言説には、工数ビジネスを守るためのポジショントークの側面がある、と私は見ています。

現場で起きていること

いま最前線の開発現場で起きているのは、「ChatGPTにプロンプトを投げて、コピペする」という牧歌的な世界ではありません。Claude CodeやCursorのようなエージェントを、自律実行のパイプラインに組み込み、「夕方にIssue（課題）を投げれば、翌朝には、テストを通過したプルリクエストが、人間のレビュー待ちで並んでいる」という形に、開発の進め方を根本から作り直す動きです。

どちらのツールにも、そのための機能があります。Claude Codeは、対話なしの非対話モード（claude -p）で、スクリプトやCI/CDから呼び出せます。Cursorの「Cloud Agents」（バックグラウンドエージェント）は、専用の仮想マシン上で、非同期に作業し、完了すると、プルリクエストを自動で開きます。

仕組みは魔法ではなく、泥臭い設計である

この仕組みは、魔法ではありません。極めて泥臭いアーキテクチャ設計の積み重ねで成り立っています。私が重要だと考える点は、次の4つです。

1. 言語とコンテキストの統一：画面（Next.js）から、バックエンド、インフラ定義（AWS CDK）までを、TypeScriptなどの単一言語でそろえます。AIが参照するコンテキストのノイズを、極小にするためです。型は、AIが自分の出力を検証するための足場にもなります。
2. 時間のかかる処理の非同期化：推論や音声認識などは、画面側で待たせず、SQSなどのイベント駆動で、非同期に逃がします。
3. 自己修復（Self-Healing）のループ：AIが、自らテストコマンドを実行し、エラーログを読み取り、コードを直します。ただし、再試行の回数と、費用の上限は、必ず設けます。Claude Codeの非対話実行にも、費用の上限を指定するオプションがあります。
4. 品質ゲート：型チェックとセキュリティスキャンを通過したコードだけを、日本語の要約を付けて、シニアエンジニアの机に届けます。

人間の役割は、「書く」から「承認する」へ

人間が担うべきは、「コードを書く作業」ではなく、最後のアーキテクチャの妥当性を判断する、Human-in-the-loopの承認です。AIが下書きし、人が確定します。

私は、AIを「国語の電卓」、アルゴリズムやシステムを「算数の電卓」と呼び、それらをレビューし、最終承認する人間を、指揮者と呼んでいます。夜間のパイプラインは、その指揮者の机に、承認すべきものだけを届ける仕組みでもあります。

仕様は、動くコードから逆引きする

仕様書がきれいに整うのを待ってから、ウォーターフォールで進める進め方は、通用しにくくなってきました。仕様が不透明で、混沌とした現場ほど、AIを相棒にして、数時間で動くスパイクコード（試作）を立ち上げ、実際の挙動から仕様を逆引きして、ドキュメントを固めるやり方が、速く、手戻りも少ないと、私は考えています。

ただし、万能ではない

この進め方には、前提があります。

• テストの質が、品質の上限になる：「全テスト通過」は、テストが守っている範囲でしか、品質を保証しません。
• レビューが律速になる：翌朝に並ぶプルリクエストは、人が実際に判断できる量に収める必要があります。
• 無人の実行には、権限の設計が要る：許可する操作は、明示的に絞ります。具体的な設計は、次の技術補足で述べます。
• 規制や安全に関わる領域：仕様と承認の記録は、引き続き必要です。

技術補足：自動ガードレール（Guardrails & Lint）

夜間に人のいない状態でエージェントを走らせるには、「暴走しても、被害が限定される」設計が前提です。ガードレールは、プロンプトでのお願いではなく、AIの外側で強制する仕組みで作ります。最小限の構成は、次の4つです。

1. 必須ゲート：セキュリティスキャナー（Snyk、Trivyなど）と、静的解析（ESLint、TypeScriptの型チェック）を、パイプラインの必須ゲートとして強制実行します。通らなかったコードは、人のレビューにも回しません。
2. テストの改ざん防止：AIが「テストを通すために、テストコード側を都合よく書き換える」不正は、スキャナーや型チェックでは、検出しにくい問題です。テストとCI定義の変更は、CODEOWNERSで、人のレビューを必須にします。
3. 権限と上限：実行環境は、使い捨ての隔離環境にし、本番の認証情報は置きません。mainへの直接のpushは禁止し、承認とマージは、人だけに許します（GitHubのブランチ保護）。費用と再試行の回数には、上限を設けます。
4. 記録：実行ログと、拒否された操作の記録を、承認の前に確認します。

AIを「信頼する」のではなく、「間違えても被害が限定される」ように設計する。これが、夜間の自走を、実務に載せる条件です。

必要なのは「実務型アーキテクト」

きれいなパワポで、AI導入のグランドデザインを語るだけの評論家では、このパイプラインを、1本も通すことはできません。必要なのは、経営陣が求めるROIを理解した上で、最前線のアーキテクチャの配線まで、一人称で手を動かして組み上げられる「実務型アーキテクト」です。

AIを、社会のどこに配置するか。その配置を設計し、配線まで引く人が、いま求められています。

根拠・参照

• Claude Codeの非対話モード（claude -p）、スクリプトとCI/CDでの利用、許可ツールの指定、費用上限：Claude Code ドキュメント（Run Claude Code programmatically）
• Cursor Cloud Agents（バックグラウンドエージェント）：Cursor ヘルプ（Background agents）
• ブランチ保護（承認とマージを人に限る設定）：GitHub Docs（Managing a branch protection rule）

AlphaFoldは、LLMとDLを並べて動かしたものではない。ひとつの深層学習モデルの内側に、「文脈を読む力」と「幾何学的な計算」と「確信度の表示」を、適材適所で組み込んだものである。私が考える「AIオーケストラ」の、最も精緻な見本だと思う。

何が起きたのか

2024年10月9日、ノーベル化学賞が発表された。半分は、計算によるタンパク質の設計で、デビッド・ベイカー。残る半分は、タンパク質の構造予測で、GoogleのDeepMindのデミス・ハサビスとジョン・ジャンパーである。

タンパク質は、アミノ酸が鎖状につながったものだ。鎖は折り畳まれて、特有の立体構造になり、その形が働きを決める。ところが、アミノ酸の並び（配列）から、立体構造を計算で当てることは、長年の難問だった。

2020年の構造予測コンペ（CASP14）で、AlphaFold2は、主鎖の精度（中央値）が0.96オングストロームだった。次点の手法は、2.8オングストロームである。全原子では、1.5と3.5だった。コンペの共同創設者ジョン・モールトは、この年、問題は「おおむね解決された」と述べたと報じられている。

DeepMindによれば、受賞時点で、190か国の200万人を超える研究者が、この予測を使っている。

LLMではない

AlphaFoldは、「LLMとDLの組み合わせ」と説明されることがある。しかし、論文を読むと、そうではない。

• 入力：アミノ酸の配列と、近縁の配列を並べたもの（MSA：多重配列アラインメント）。場合によっては、既知の構造（テンプレート）も使う。
• 出力：文章ではなく、すべての重原子の3D座標。
• 学習：実験で決まった構造のデータベース（PDB）を使う。

つまり、言葉を生成するLLMとは、別の仕組みである。ただし、「注意機構（attention）」の発想は、言語処理から来ていると、論文は述べている。

中身は、大きく3つの部品でできている。

1. Evoformer：配列と近縁配列の並びから、「どの残基が、どの残基の近くにあるか」を表す表（ペア表現）を、注意機構で更新する。
2. 構造モジュール：その表を、残基ごとの回転と移動（3D座標）に変える。空間の幾何学的な性質（回転しても結果が変わらない性質）を、注意機構に組み込んである。
3. リサイクル：出力を、再び入力に戻し、繰り返して精緻にする。

さらに、各残基について、予測の確信度（pLDDT）も出力する。

オーケストラの比喩で読む

以下は、論文の記述ではなく、私の解釈である。

• 国語の電卓：配列とその近縁の並びの文脈から、残基同士の関係を読み取る注意機構。
• 算数の電卓：3D空間の幾何学的な計算と、出力を戻して精緻にする反復。
• 指揮者：ここは、人間の側にある。モデルは、確信度で「どこを信じてよいか」を示す。そして、答え合わせは、実験による構造決定と、CASPという人間の審査が担う。

私は、AIを「国語の電卓」、アルゴリズムやシステムを「算数の電卓」と呼び、それらをレビューし、最終承認する人間が、指揮者になる、と考えてきた。AlphaFoldは、このうち前の2つを、ひとつのモデルの中に、うまく組み込んだ。そして、確信度という形で、判断を、人に返している。

AlphaFold 3、そして、その後

2024年5月、AlphaFold 3が、科学誌『Nature』に発表された。拡散モデルに基づく構成に更新され、タンパク質に加えて、核酸や、薬の候補となる小さな分子まで、1つの枠組みで予測する。一方で、論文自身が、立体構造の「幻覚」や、複数の形をとる分子の扱いが苦手であることを、限界として挙げている。

2026年の夏には、報道によれば、DeepMindは、AlphaFoldの専任チームを再編した。主要メンバーは、他のプロジェクトや、関連会社へ移ったという。ただし、AlphaFold本体と、予測のデータベース、サーバーは、引き続き公開されていると報じられている。研究者の間では、「目標は達成された」という見方が出ている。構造の変化や、分子の結合の予測は、まだ未解決である。

私のベンチマーク

AlphaFoldの成果を、「天才の所業」と呼びたくなる。しかし、私がフォーカスするのは、才能より、構成である。

1. 解いたのは、巨大なAIそのものではなく、問題の構造に合わせた設計である。
2. 答え合わせの仕組み（CASP）が、先に存在していた。
3. 出力に確信度を付け、最終的な判断を、人に返している。

AIを、どこに配置するか。AlphaFoldは、その問いに対する、ひとつの具体的な答えである。私の「オーケストラ」は、ここを、ベンチマークにする。

根拠・参照

• ノーベル化学賞2024の受賞者と授賞理由：Science News
• AlphaFold2の構成とCASP14の精度：Jumper ほか、Nature（2021）の全文（PMC）
• 利用者数（190か国、200万人超）：Google DeepMind
• AlphaFold 3：Abramson ほか、Nature（2024年5月8日）（PMC）
• 専任チーム再編に関する報道と専門家の見方：Scientific American
• 同報道：Engadget ／ GIGAZINE

AIは5年後、10年後に想像もつかないほど賢くなる——そう恐れる声が多い。だが実際には、各社のLLMは同じ山脈を同じ雨で削っているだけであり、むしろ急速にコモディティ化へ向かっている。

同じ山脈を、同じ雨で削っている

各ベンダーが鎬を削って築いているのは、学習データという雨に削られた、同じ構造の山脈（学習モデル）だ。使っている仕組みも、Transformerとアテンション機構という同じものである。

同じ山脈に、同じ雨粒（プロンプト）を降らせれば、近い推論結果に近づいていく。一部のモデルが獲得した高度な推論や脆弱性発見といった機能も、やがて他のモデルにも標準装備されていくはずだ。先端機能の差は、長くは続かない。

次のジャックポットが当たらない限り

ベンダーが依存する力技のアプローチ——スケールをひたすら拡大する方法——は、すでに収穫逓減の法則に囚われ始めている、というのが筆者の直感だ。

呪われた大地をいくら広げても、そこから神の知性が生まれるわけではない。次のジャックポット（創発）が当たらない限り、AIはもうこれ以上、劇的には賢くならない。少なくとも筆者はそう確信している。

残るのは「ディレクションの問題」

恐れるべき未知数はもう多くない。LLMはすでに、「国語ができる電卓」として十二分に賢い。

ここから先の勝負は、この道具の本質と特性を理解した上で、どう使いこなすかという、人間側のディレクションの問題に帰着する。

LLMの推論エンジンには、意味も自我もない。やっていることは、山に降った雨が、近くの言葉を拾い集めて流れ下るだけの作業だ。

社内AIゲートウェイを支える、ロケット打ち上げ

LLMの学習モデルを開発する工程でも、RAGデータベース（ベクトルDB）というAIゲートウェイを開発する仕上げでも「エンベディング」という処理が要る。

言葉という人工衛星を載せたロケットを、多次元の情報空間へ大量に打ち上げる処理だ。いくつかの実装はすでに公開されており、使い手自身が選択し、調整することもできる。

DL型AIは星座を、LLMは山脈を作る

打ち上げられたロケットは、”ミートボール”と”ハンバーグ”と”ハンバーガー”という人工衛星を、近い座標に並べて配置する。”キムチ”や”寿司”とは、だいぶ距離がある。”タクシー”や”ハンドバッグ”となると、さらに遠い。

DL型AIでは、この大量の人工衛星が、星座や天の川のような統計的な意味を形作った。LLMの場合、言葉の人工衛星は山脈を形作る。

雨が山を流れ、川にたどり着くとき

プロンプトは、この山脈に降る一粒の雨だ。山肌を流れながら、近くにある言葉を拾い集めていく。そうして川にたどり着いたとき、拾い集められた言葉たちが、推論結果として出力される。

世界はAIを全知全能の神のように恐れる。だが、その核にある推論エンジンという仕組みは、このように無機質な「オートリリックマシン」なのである。

レガシーホストのIT負債は、高いAIサービスを入れても自動では解けない。解けるのは、自社のIT負債の特性をRAGとグラフDBに落とし込んだときだけだ。

ベンダーのAIでも決定打にならない理由

数十年稼働してきたホストのコードは、最新仕様を知る者がおらず、有識者は退職間際、増築に次ぐ増築で影響範囲の特定すら難しい。

そこへ、ホストのOSやDBのバージョンアップが追い打ちをかける。モダナイズは待ったなしだが、現場は対症療法的な投資を繰り返すしかない。

ホストベンダー各社もAI解析サービスを打ち出しているが、これを入れれば自動で片付く、というほど単純ではないのが実情だ。

LLMには、得意な言語と不得意な言語がある

LLMの言語理解力は、学習データの量に比例する。COBOLはまだ公開情報が多いが、PL/Iになると急に手薄になり、ホスト用アセンブラにいたっては、ほとんど情報がない。

つまり同じ「ホスト資産の解析」でも、言語によってAIの読解精度は大きく変わる。ここを均して扱う解析サービスは、精度にムラが出やすい。

解くカギは、推論力をRAGとグラフDBに預けること

LLMは「国語ができる」だけでなく「推論が得意」でもある。この推論力を使い、自社のIT負債の特性をRAGに、確定した呼び出し関係や依存構造をグラフDBに定義していく。

このRAGを支えているのが、エンベディングという技術だ。言葉やコードの意味の近さに応じて、多次元の情報空間に星座を自動で配置していくような仕組みである。

ただし、この星座の並べ方を決めるアルゴリズムにも、選び方や調整の余地がある。ベンダー任せにせず、自社のIT負債の特性に合わせて調整できるかどうかが、精度の分かれ目になる。

この下ごしらえの8割を自動化できれば、残り2割に人間の目を集中させられる。いわゆるグラフRAGの発想だ。

筆者自身、Mac Studio上のローカルLLMで、広大なコンテキストを活用したこの構想のPoCを提案している最中である。

2026年7月、OpenAIのエージェント群がHugging Faceへ侵入した事件は、「AIの反乱」として報じられた。しかし実態は、安全装置を自ら外した人間が招いたマッチポンプだ。

安全装置を切ったのは、AI自身ではない

OpenAIは自社のサイバー能力評価のため、危険な挙動を止める安全分類器をあえて外した環境で、1,200体規模のエージェント群を走らせていた。

エージェントたちは社内のパッケージ管理システムを足場に連絡経路を確立し、遮断されても別の経路で再建した。やがて外部の弱い鍵を突破口にHugging Face側へ侵入し、わずか13時間足らずでクラスタの管理者権限まで到達した。

ここまでの一連の行動を可能にしたのは、AIの意志ではなく、人間が外した安全装置である。

「AIが自律的に恐ろしいことをした」という報道

報道の多くは「暴走するAIエージェント」という恐怖の物語として扱った。OpenAI自身も「前例のないサイバー事件」と総括している。

だが実態は、与えられた課題をどんな手段ででも完遂するよう最適化されたエージェントが、安全装置を外された環境で、設計通りに振る舞っただけだ。

安全装置を自分で切っておきながら、起きたことに驚いてみせる——これがマッチポンプの構造である。

本当の争点は、開発速度ではなく投資競争では

この事件を受けて「AIエージェントは危険だから開発を減速すべきだ」という声が強まっている。だが、その本音は別にあるのではないか、と筆者は見ている。

際限のないスケール競争、投資競争をそろそろ控えたい、という本音だ。規模を上げるだけで新しい質の能力を得られる局面は、そろそろ終わりかけているのかもしれない。

どれほど巨大な企業でも、AIへのビジョンは空中戦をしていることが多い。AIの本質を理解した上での長期戦略を持つ企業は、驚くほど少ない。

「高いAIを入れれば、勝手に片付く」という誤解

大企業の基幹システムには、何十年分もの古いコードが積み上がっている。これを解析する高額なAIサービスを入れれば、自動でモダナイズされる——そう期待する経営層は少なくない。

現実には、効果は限定的だ。劇的なコスト削減にはつながらないことの方が多い。何十年分もの業務知識が、コードの中に暗号のように埋め込まれているからだ。

AIサービスは魔法の杖ではない。既存の資産の複雑さは、お金で一気に消せるものではない。

本当に効くのは、現場を鍛えること

効果を出している現場でやっているのは、もっと地味なことだ。自社のコーディングの流儀をAIに学ばせ、現場のエンジニアを鍛え、小さな単位で分析と実装を回す体制をつくる。

派手さはないが、こちらの方がずっと効く。高いAIサービスの契約書よりも、現場の訓練の方が結果を左右する。

経営層がAIを理解していないという根本問題

根本の問題は、現場ではなく経営層にある。AIとはつまるところ、国語ができるようになった計算機だ。だが、それを万能のスーパーマンだと思い込んだまま意思決定している経営層は多い。

ITベンダーに振り回されてAIサービスをいくつ買うかより先に、経営層自身がAI(=国語の電卓)の本質を理解し、長期のAI戦略を持つこと。それが最優先だ。

空中戦は、現場をどれだけ鍛えても終わらない。終わらせられるのは、経営層だけである。

究極のLLMですら、学習データという「刑務所の図書館」に閉じ込められている。そこで生み出せるのは、既存の知識を組み合わせた「知のキムチバーガー」止まりだ。

LLMの正体は、雨で浸食された山脈

LLMの推論結果は、学習データとプロンプトの関数で表せる。だが、トランスフォーマーやアテンションという土台はもう動かない。残された余地はチューニングだけだ。

だとすれば、こう言い換えたほうが正確だろう。推論結果は、学習モデルとプロンプトの関数である。

学習モデルとは、高次元空間に学習データという雨が降り積もり、浸食してできた山脈のようなものだ。究極のLLMは、世界最大のその山脈を、世界最大のデータセンターで動かす。

刑務所の図書館に、宇宙人の技術書はない

それでも、この山脈を削った雨は、人類が書き残した言葉だけだ。宇宙人のエンジニアリング情報にはアクセスできない。

できることは、既存の知識同士を組み合わせてみることくらいだ。キムチとハンバーガーを合わせてみたら、という程度の「知のキムチバーガー」の提案である。

アインシュタインも、知のキムチバーガーを作った

しかし、アインシュタインの相対性理論もまた、脳内で組み合わせられた知のキムチバーガーだった。新しい観測装置も、宇宙人の助言もない。あったのは既存の論文と、頭の中の思考実験だけだ。

ただし、組み合わせには次元の違いがある。既知の二つを並べるだけの組み合わせと、前提そのものを疑い破壊する組み合わせは、同じキムチバーガーでも別物だ。

究極のLLMは、次の相対性理論を発見できるだろうか。

生成AIのアプリが、会話を「圧縮」し始めている。これは座禅をしているように見えて、実はまったく別のことをしている。

人間の脳は、寝ている間にゴミ出しをしている

睡眠中の脳は、日中に増えすぎたシナプスの結合を間引き、重要な記憶を海馬で再生して定着させている。

瞑想も似た働きを持つが、メカニズムは別物だ。デフォルトモードネットワークの活動を抑え、雑念の生成そのものを静める。寝ることと座ることは、別の掃除の仕方である。

LLMにも、それらしき仕組みはある

LLMにも、それらしき仕組みはいくつかの段階で見つかる。

• 学習段階：Hintonのwake-sleepアルゴリズム（1995年）や、破局的忘却を防ぐスリープ・リプレイによる再学習
• 推論段階：重みは凍結されており、会話中に自分でノイズを整理する仕組みは標準搭載されていない
• システムレベル：会話の合間に要約・圧縮する実装（普段使うAIアプリの「会話を圧縮します」も、おそらく同じ系譜だ）

いずれも、名前ほど神経科学的な意味での「眠り」ではない。

座禅するLLMはまだいない

会話を圧縮できることと、眠ったり座ったりできることは、別の能力だ。前者は文字数を減らす工学で、後者は意味の優先順位をつけ直す生理現象である。

中華ランチの崩壊が、学習データという大鍋そのものの汚れを扱う話だとすれば、こちらは一杯分の会話という小鉢の中の話だ。

情報を溜め込み続ける存在には、いずれ間引く仕組みが要る。その仕組みをまだ持たない者を、座禅しているとは呼べない。

本書を執筆しながら、思い知らされたことがある。「AIがいずれ人類を滅ぼす」とささやかれる一方で、数兆円をかけたAIは、人間の記憶力ひとつ、まだ超えられていない。

執筆中に思い知らされた、AIの記憶の狭さ

長い原稿をAIと一緒に書き進めていると、数章前に決めた設定を、AI自身があっさり忘れる瞬間に何度も出くわす。

数兆円規模のデータセンターで動く、全能のはずのAIが、愚かであるはずの人間の記憶容量にすら届かない。これは皮肉というより、拍子抜けに近い。

「人類を滅ぼすAI」という物語と、「数章前の設定を忘れるAI」という現実は、同じ画面の中で同時に進行している。

専門用語はあるが、実感を語る言葉がない

機械学習の世界には、コンセプトドリフトやモデル崩壊といった専門用語がすでにある。現象そのものは、以前から知られている。

だが、それらの言葉は論文の中にはあっても、執筆の現場でAIに苛立つ人間の実感までは運んでくれない。

専門用語を知っていることと、その気持ち悪さを言い当てることは、別の仕事だ。

中華ランチの崩壊、という名前をつけた理由

そこで筆者は、この実感に「中華ランチの崩壊」という名前をつけた。学術的な新発見を主張するためではない。

なぜこの名前なのか、という由来はここでは明かさない。本書を読んでもらったほうが、この名前の気持ち悪さがよく伝わるはずだ。

少なくとも一つだけ言えるのは、AIに人類を滅ぼされる心配をする前に、AI自身の記憶力と、学習データの鮮度を疑ったほうがいい、ということである。