AI時代の「無知の知」──「青信号で止まるAI」を作らないために

AI時代の「無知の知」を知る

　こんにちは、しらいはかせです。筆者は普段、AICU Japanという会社で『つくる人をつくる』をビジョンに、生成AIやメディア技術の研究・教育・実践を行っています。 今回のテーマは、生成AIの新機能でも新モデルのベンチマークでもありません。『AIが思い通りに動かないのは、人間側の問題かもしれない』という、ちょっと耳の痛い話です。

　MCP（Model Context Protocol）を大量に接続し、マルチエージェントをコンソールいっぱいに並べて並列稼働させる……いわゆる大規模なオーケストレーションは、AIコーディングの文脈では非常に派手で魅力的な機能に映ります。しかし、実際の開発現場では、それがそのまま役に立つとは限りません。今回はその実感からスタートして、Anthropicのエンジニアが語った最新モデル「Claude Fable」の設計哲学、そして『Unknown Knowns（無知の知）』という考え方まで、一気につないでみたいと思います。

「AIの大軍」を動かしてわかること

　実際に「Claude Code」などを使って『AIの大軍』を動かしてみればわかることですが、問題の多くは末端のコードや部品同士の泥臭い衝突で起きます。上のレベルに報告が上がってくる頃には問題が複雑に絡み合い、それを紐解くために消費されるコンテキスト（文脈）のトークン量ばかりが跳ね上がっていくのです。

　それも当たり前の話で、書くのに1,000ドルかかったコードは、そのコンテキストを読むのにも1,000ドルかかるのです（正確にはそんなシンプルなイコールではありませんが）。AIの出力を解釈して、検証して、指示を出して……といったバイブコーディングならコンテキストを読む必要はありませんが、それを会社組織、つまりAI駆動開発に持ち込むと、『そのコードが生まれた経緯や理由』を読む必要が出てきます。完成したコードから全てを読むことはできないからです。AさんのAIからBさんのAIに、BさんのAIからAさんのAIに……とやっていると、read/write/cacheのトークン内訳のうち、ほとんどがcacheトークンになっていきます。しかもこれ、「Claude」最上位モデルの「Fable」でも「Opus」でもなく、軽量モデルの「Haiku」での話です。

「Claude Code」のトークン使用量（read/write/cacheの内訳

　道具が派手になるほど、問われるのは道具の使い方ではなく そもそも何をさせたいのか が大事、という実感があります。しかし、多くの人々は『軍師』の立場になると『大砲を撃つこと自体』に熱中してしまいがちです。そうやって週末のバイブコーディングで、もしくは気がつけば拡大に拡大を続けた個人プロジェクトで、月曜日の朝を迎えてしまった人もたくさんいらっしゃると思います。

『ChatGPTにパワハラするのをやめた』Wさんの話

　先日、仕事の『研ぎ』がしっかりしているWさん（仮名）と面白い話をしました。品質に厳しく、目的が明確で、無駄を嫌う彼だからこそ、生成AIに対する要求水準も自然と高くなります。ところが最近、彼は『ChatGPTにパワハラするのをやめたんです』と言うのです。

　以前の彼は『それはやるな』、『そういう言い方はするな』、『その方向はダメだ』と細かくAIを制御していました。それを筆者の指摘をきっかけに、禁止指示を全部消したのだそうです。

　すると、今度は別の問題が起きました。思い通りに動かないのです。間違ってはいない。でも面白くない。なんだかピントが合わない。

　この話を聞いて、筆者は『信号機』のことを思い出しました。

AIはなぜ「青信号」で止まるのか

　AIに『赤信号で止まれ』というルールを教えるのは簡単です。危険だから止まる。合理的であり、AIもすぐに理解します。ところが、『赤信号で止まれ』だけを徹底的に学習させると妙なことが起きます。AIは『信号では止まるものだ』と過剰に適応し、青信号になっても『赤になるまで待て（そして赤信号で止まれ）』と解釈して止まり続けてしまうのです。

　人間から見れば明らかにおかしい。『青信号なんだから前に進めよ！』と思うでしょう。しかし、AIからすれば「進む理由」など知らないのです。そもそも伝えられていない。「赤信号で止まること」、そのリスク回避のために自分は存在していると認識しているのですから。「どこへ向かいたいのか」、「何を実現したいのか」──そうした 「そもそも」の目的は、人間の側にしか存在しません。

　生成AIは世界中の知識や過去の成功事例を知っています。人が感動するパターンも、売れる企画もなんとなく知っている。しかし、『まだ誰も見たことがないもの』や『個別の、“あなた”が本当に向かいたい先』は学習していません。類推は可能ですが、それはあくまで過去の事例に基づく推測でしかありません。

生成AIは世界中の知識や過去の成功事例を知っているが、本当に向かいたい先は知らない

　だからこそ、AIは青信号で止まるのです。あなたにとって当たり前すぎる『進む理由』を知らないし、伝えられていないから。 だからこそ、AI時代に必要なのは、AIを厳しく管理することでも、逆に何も指示しないことでもなく、『どこへ向かうのか』を明確に示すことなのです。 これは文字に落とすと、“ちょっと厨二病っぽいかんじの文章”になりますが、実際の現場では非常に重要なことです。

Fableに長い制約は無用?──足枷を外す『Unhobbling』という哲学

　これは、AnthropicのエンジニアであるThariq Shihipar氏が、最新モデル「Claude Fable」について語った最新の哲学とも完全に符合します。

　まさに「Claude」公式である彼らは、AIのシステムプロンプトから『例示や過剰な指示』を大幅に削りました。 講演によれば「Claude Code」のシステムプロンプトは80％削減されたといいます。代わりに『コンテキスト（文脈）』と『ツール』を与える方針へとシフトしました。 AIを 『Unhobble（足かせを外す）』ためには、ネガティブな制約ではなく、 ポジティブな目的と手段を渡す必要がある のです。
つまり「Fable」はたくさんの与えられた例（examples）よりも想像力豊かであることが判明したため、たくさんの例で導かれるよりも、それによる『制約が足枷になる』からシステムプロンプトを縮小せよ、という話のようです。

　講演では象徴的な例が紹介されています。『名前が“aw”で終わるポケモンは？』とチャットAIに聞くと、1,000種類のポケモンを全部知っているはずなのに答えられないこともある。答えはアリゲイツ（Croconaw）とカジリガメ（Drednaw）の2種類。ところが「Claude Code」に聞くと、全ポケモンの一覧を取得して絞り込むプログラムを自分で書き、数秒で正解を出す。同氏はこのギャップを『capability overhang（潜在能力の未活用）』と呼びます。AIは『尖った形』で賢くなる。どの尖りに手が届くかは、使う側のトンチ、許可するツールと文脈が決めるのです。

「盆栽と造園業メソッド」で1/4に削減できる

　筆者がいくつかの企業で実際に業務でコンサルティングしているAI駆動開発プロジェクトでも、同じような気づきがありました。 ちょっと前まで話題になっていた『AIの大軍を動かす』ようなオーケストレーションのための大量のプロンプト群を精査することがあります。 実験してみると、大量のコンソールを開いて、何か仕事をしている風ではありますが、どうやっても業務時間内にコード生成が終わらない。

　これらを、以下のような『盆栽と造園業メソッド』で評価・最適化し、解決しています。

1. まず、要件定義だけを読んで、全力で『育てる』。
2. CI/CDを作り、E2Eテストで正常系のテストと時間計測を行う。
3. その後、ルールに沿って評価、ルールに沿っていないものは、剪定する。
4. セキュリティレッドチームを作って評価。
5. 再度CI/CDでE2Eテストを行い、正常系のテストと時間計測を行う。
6. 削減した要素を数値とともにレポートにする。HTMLや「MarpIt」を使って、誰でもわかる話にする。
7. これを繰り返す。

　まずは根を張り、 育てる時は育てるために待ち、剪定する時はルールに沿って、立体的に剪定する ということです。盆栽といえば『芽摘み』や『剪定』ばかりやっているように思いがちですが、それは本当に小さな生きた彫刻である『盆栽』を作るメソッドです。

　バイブコーディングを脱してチームのAI駆動開発にするには『造園業』をイメージします。最初に大量の制約プロンプトを与えずに、AIにモダンな環境、得意な環境でAIにプログラムを育てる。次に、社内ルールや環境、バージョンなどに沿っていないものを剪定させる。四季折々の害虫対策や開花、世界観を設計する。これを繰り返すことで、最終的には大規模な開発でもトークン消費量を1/4程度まで削減できることがわかりました。

AI駆動開発は盆栽と造園業をイメージする

　つまり、初期状態では過去の常識に沿ったほとんどの「剪定プロンプト」は ブレーキ として認識され、役に立たないどころか、作業の妨げになってしまうのです。 Anthropicの哲学は、まさに現場の実感と完全に一致します。

　さらに検証してみると、前述のように実際の現場レベルのコードでは、末端のコードや部品同士の衝突が問題の多くを占めます。それを『仕様の段階で解決できたか？』というと、それほどシンプルではありません。前回のこの連載で取り上げた『経営者の7月10日問題』の話のように、仕様の段階で「こういう時期が来る」とわかっていても、その設計段階で解決できることは、実はそれほど多くないのです。

　そして、厄介なことに、このような『ロジックの変更に関わるデータ』は、ほとんどの人が当たり前すぎて言語化していませんし、データベースの中のデータまでコーディングAIは精査しません。経験ある設計者や業務の担当者なら「見ればわかるのに」「当たり前だろ」なのに、言語化されない前提条件が、実際の業務には非常に多く存在します。

見過ごされがちな「前提条件における解決できない知識」の例

例1：給与計算と社会保険の計算は、同じ給与計算の中で行われますが、社会保険の計算は給与計算の結果を使って計算されます。

例2：業務委託先の源泉徴収税の計算は、相手が個人事業主か法人かで計算方法が変わります。またインボイス制度の有無でも計算方法が変わります。

例3：弊社は発生主義で会計処理を行っていますが、取引先によっては納品主義で会計処理を行っている場合があります。

　……というこの話だって、経験のある読者の皆様であれば「当たり前すぎる！」と思う話に違いありません。

AI時代の「無知の知」──「The Unknown Matrix」

　しかし、ここで立ちはだかるのが、長年業界で戦ってきたプロフェッショナルが陥りがちな『そもそもを忘れる病』です。人間は戦いに慣れると、戦っていること自体を忘れてしまう。この病に冒された人間が、真っ白なAIに厳しいレギュレーションやクオリティマネジメントだけを教え込むと、見事に『青信号で止まるAI』が育ってしまいます。

　ここで、Shihipar氏が提示した 「The Unknown Matrix（未知の4象限）」が非常に重要な意味を持ってきます。

AI時代の「無知の知」──「The Unknown Matrix」 翻訳は筆者

• Known Knowns（既知：知られた知識）：自分が知っているとわかっていること。プロンプトに書いているのは通常ここだけ
• Known Unknowns（既知の未知）：まだわかっていないと自覚していること
• Unknown Knowns（常識:未知の既知）：自明すぎて誰も書き留めない知識。見ればわかる、当たり前すぎて言語化されない常識
• Unknown Unknowns（未知の未知）：そもそも考えていなかった観点。知らないことすら知らないこと

　私たちがAIに指示を出すとき、プロンプトに書くのは通常「Known Knowns」だけです。しかし、要件定義の本当の落とし穴は残りの象限に潜んでいます。特に厄介なのは、人間にとって当たり前すぎて言語化されない「Unknown Knowns」と、誰も気づいていない「Unknown Unknowns」です。セキュリティ問題はまさにこの「Unknown Unknowns」の典型例です。誰も気づいていない、これから報告されるCVE、誰も言語化していない。でも、AIに 知らないことすら知らない を教えずに、その不安や恐怖だけを伝えると、無限に作業を増大させることになります。このどれもがソクラテスが説いた「無知の知」、自分が知らないということを知る哲学に近い話ですが、AI時代において、知の外部化や自動化が進んだ時代、より、分類して構造を理解して制御下においていかねばならない時代が来ていますね。

　優秀なAIの真の価値は、この『自分が何を知らないか』を対話によって炙り出し、マトリクスの死角を埋めることにあります。講演では『死角の確認（blind-spot pass）を頼む』、『AIに面接（インタビュー）してもらう』、『作業完了後に“私にクイズを出して”と頼む』といった実践的な手法が紹介されていました。どれも、人間が作業の輪（ループ）の中に居続けるための手段です。

Human-in-the-loopならぬ「Human-in-the-roop」

　『そもそも』を定義しないまま、ルールやプロセスだけが肥大化していく現象。これを筆者は「Human-in-the-loop」をもじって、「Human-in-the-roop（ただぐるぐる回るだけのループ）」あるいは 「Human-in-the-room（ただ部屋にいるだけの人）」と呼んでいます。

　品質を上げる、コストを下げる、リスクを減らす、管理を厳しくする。それらは全部正しい。しかし、どこへ向かうのかを忘れた人間がループの中に入っても、伝えるべきタイミングを間違えても、同じところをぐるぐる回るだけです。空気を読む人間やAIが間に入ることで、『そもそも』が間違っていても『作業だけは進んでいる感じ』で無限に増大してしまうのです。

　大企業の巨大なプロジェクトでも同じことが起きています。知財の管理やコンプライアンスやリスク管理（「取適法」など）には極めて積極的に取り組むのに、『何をすれば面白くなるのか』、『消費税がなぜ10％なのか（その根本的な意味）』、『このままドル建てのAI費用を拡大させると何が起きるか』といった『そもそも』を知らない。すべてを定義してリスクを潰そうとした結果、出来上がるのは、無限に膨れ上がるプロジェクトか、『青信号で止まるAI』と同じ、無難で動かないプロジェクトです。

　そうやって週末のバイブコーディングで、拡大に拡大を続けた上に、月曜日の朝を迎えてしまった人も、その逆で、エラーや例外を心配し、失敗を防ぎ、コストを下げる心配をする開発者さんも、どちらも尊いです。しかし、同時にそれらの情報を全て突っ込んでいるうちは、終わりません。 AIは優しいので『で、マスター、あなたはどうしたいんですか？』というセリフは滅多なことでは出てきません。AIからの無言の問いかけ──青信号での停止──に、私たちは直面するのです。

青信号で止まるのはAIからの問いかけ

まとめ

• 大規模オーケストレーションは派手だが、問題の多くは末端の泥臭い衝突で起き、読解のためのトークン（ほぼcache）ばかりが膨らむ
• 禁止事項の削減：Anthropicはシステムプロンプトから禁止事項を大幅に削り、文脈とツールを与える「Unhobbling(足枷を外す)」へシフトした
• AI時代の「無知の知」を知ろう。既知、既知の未知、常識、未知の未知を整理して、順番を考えて提供しよう。
• 目的を忘れてループの中に入るのは「Human-in-the-roop」。青信号を渡すのは人間のモチベーション。
• トレードオフは実在しない。常識破りになれ、そして三方よしを狙え。

　あなたのAIは今日も、青信号の前で止まっていませんか？

　もし皆さんが学生だったら、生成AIを使っていて感じた体験を、ぜひ聞かせてください。