検索と判断の分離──AIは予測ではなく、意思決定のために設計する

🎥 YouTubeでも公開しています

AI Coordinationとは何か ― マルチエージェント時代の協調工学と5つの協調障害を解説

Books: AI Coordination Engineering 実践ガイド: マルチエージェント時代の協調・自律性・信頼を設計する

生成AIの導入では、しばしば「どのモデルが最も賢いか」が中心の問いになる。より大きなモデル、より長いコンテキスト、より高いベンチマークスコアを選び、検索から回答、ツール実行まで一つのAIに任せる。

しかし、組織の業務で本当に問われるのは、予測や生成の巧さだけではない。

どの根拠に基づき、どの条件で、誰の責任において、この判断をしてよいのか。

この問いに向き合うなら、AIシステムは「一つの賢いモデル」に寄せるのではなく、検索と判断を分離する方向で設計する必要がある。

軽量モデルやルールエンジンは、広い情報空間を探索し、候補を絞り、構造化する。強いモデルは、限られた Evidence Pack を統合し、説明し、比較し、設計案を作る。そして最終的な意思決定と実行は、承認・権限・ポリシーによって別途統制する。

この分離は、単なるコスト最適化ではない。精度、監査性、責任分離を同時に改善するためのアーキテクチャである。

「AI is not prediction. It is decision.」とは何か

AIの出力は、分類、予測、要約、生成など、さまざまな形を取る。しかし業務で価値を持つのは、出力そのものではなく、それが次の行為につながることである。

• どの顧客を優先するか
• どの規程を適用するか
• どの設計案を採るか
• どの例外を認めるか
• どの変更を本番へ出すか
• どの外部ツール実行を許可するか

つまり、AIの出力は意思決定の材料であり、ときには意思決定そのものの一部になる。

「AI is not prediction. It is decision.」という言葉は、AIの評価軸を変える。モデルがそれらしい答えを返したかではなく、根拠、制約、選択肢、責任、実行結果を含む意思決定の連鎖を、適切に作れているかを問うのである。

この視点に立つと、検索と判断を同じモデル・同じプロンプトに混在させることの問題が見えてくる。

一つの強いモデルに全てを任せると起きること

強いモデルに「必要な情報を探し、読んで、判断し、回答し、実行して」と頼めば、短いデモでは印象的に動くことがある。

しかし、実運用では四つの問題が起きやすい。

1. コストが探索量に比例して膨らむ

多くの問い合わせは、最終判断の前に大量の候補探索を必要とする。文書、表、コード、ログ、過去の判断、規程、チケット。これらを毎回強いモデルの長いコンテキストに入れれば、コストと応答時間は急速に増える。

しかも、候補の大半は最終判断に不要である。高価な推論能力を、単なる重複排除やフィルタリング、定型的な分類に使うのは合理的ではない。

2. 誤りの場所が分からなくなる

回答が誤っていたとき、原因はどこにあるのか。

• 検索対象が不足していたのか
• 候補の順位付けを誤ったのか
• 古い版を採用したのか
• 根拠間の矛盾を見落としたのか
• 推論・統合の段階で誤ったのか

すべてを一つのモデルに任せると、失敗の原因がブラックボックス化する。改善も「プロンプトを変える」「より大きなモデルにする」という曖昧な対処になりやすい。

3. 根拠と判断の責任が混ざる

検索は、本来「候補を広く、漏れなく、制約に従って集める」活動である。判断は、「競合する根拠や制約を比較し、目的に照らして選択する」活動である。

この二つには異なる失敗モードと責任がある。検索では、アクセス権、版、適用範囲、鮮度が重要になる。判断では、トレードオフ、例外、承認、影響範囲が重要になる。

混ぜてしまうと、「何を見たか」と「なぜそれを選んだか」が区別できなくなる。

4. 不要な自律性が生まれる

探索の途中で見つけた指示文や外部コンテンツを、モデルが実行すべき命令として扱う危険がある。特にエージェントがツールを使う場合、検索と実行の境界が曖昧だと、プロンプトインジェクションや目的外利用のリスクが高まる。

軽量層は「探索」と「選別」を担う

検索・候補絞り込みの層には、必ずしも最も強い生成モデルは必要ない。むしろ、ルール、メタデータ、全文検索、ベクトル検索、軽量分類器、小型モデルを組み合わせる方が、速く、安く、制御しやすい。

この層が担当する仕事は、たとえば次の通りである。

ここでは、説明可能性と再現性を優先する。なぜ候補が選ばれたのか、なぜ除外されたのかを、モデルの雰囲気ではなく、検索条件、スコア、版、適用範囲、ポリシーとして示せるようにする。

軽量層の出力は、単なる検索結果一覧ではない。最終判断に渡す候補を、来歴と制約を付けてまとめた Evidence Pack である。

強いモデルは「統合判断・説明・設計」に集中する

強いモデルの価値は、何百万件もの候補を無差別に読むことではない。限られた根拠集合を前にして、異なる概念を統合し、矛盾を見つけ、選択肢を比較し、説明や設計案に変換することにある。

強いモデルには、次のような仕事を任せる。

• 複数の根拠を統合した状況説明
• ルール・制約・例外の矛盾の整理
• 複数案の比較とトレードオフの提示
• 業務プロセスやソフトウェア設計の提案
• 人間向けの説明、レビュー材料、意思決定メモの作成
• 根拠不足や追加確認事項の明示

重要なのは、強いモデルが「何でも決める」存在にならないことだ。入力として渡す Evidence Pack、目的、許容される選択肢、禁止事項、必要な承認条件を、外部から明示する。

モデルはその枠の中で考え、提案する。枠そのものを勝手に書き換えたり、根拠のない行動を実行したりしてはならない。

精度は、モデル単体ではなくパイプラインで測る

検索と判断を分けると、精度の評価も分解できる。

この分解によって、たとえば「回答が間違った」場合にも、改善点を特定できる。

必要な規程が検索に入っていなかったなら、検索・インデックス・メタデータを直す。根拠は入っていたが古い版を採用したなら、版管理と選別ルールを直す。Evidence Packは正しかったが説明が誤っていたなら、統合判断モデルやプロンプトを改善する。

すべてをモデルの知能不足として扱わないことが、継続的な改善につながる。

コストは「高性能モデルを使う回数」で設計する

AIシステムのコストは、モデル単価だけでは決まらない。高性能モデルに渡すトークン量、呼び出し回数、再試行、長いコンテキスト、ツール実行の連鎖によって決まる。

検索と判断の分離は、コスト構造を明確にする。

• 大量の候補探索は、インデックス、検索エンジン、ルール、小型モデルで処理する
• 高性能モデルは、少数の高価値な判断点にだけ使う
• 同一のEvidence Packはキャッシュし、再利用する
• 定型処理はDSLやルールエンジンへ移す
• 高リスク・高不確実性のケースだけ、人間レビューと強いモデルへエスカレーションする

これは「安いモデルで我慢する」という発想ではない。能力に応じた適材適所である。高性能モデルを、最も価値の高い統合・説明・設計へ集中させることで、全体の品質も上がる。

責任を分離する──誰が何を保証するのか

AIの責任分離は、最終的に人間が責任を負うという一般論だけでは足りない。システムの各層が、何を保証し、何を保証しないかを明確にする必要がある。

この分離があれば、強いモデルが「決定者の代わり」を演じる必要はなくなる。モデルは、根拠に基づく判断支援を担い、最終決定・承認・実行の責任は、役割と権限に応じて配置できる。

ReceiptとDecision Traceで、分離を記録する

設計上の分離は、ログ上でも分離されていなければ意味がない。

Retrieval Receipt には、何を検索し、何を候補として採用・除外し、どの Evidence Pack を作ったかを残す。

Decision Trace には、Evidence Packを受けて、どの選択肢を比較し、どの判断・承認が行われたかを残す。

Pipelock Receipt には、判断と承認に基づき、どの外部通信・ツール実行が許可または拒否されたかを残す。

この三つをつなげると、次の連鎖を検証できる。

検索・選別 → Evidence Pack → 統合判断 → 承認 → 実行

後から見れば、判断結果だけでなく、「何を見たか」「何を見なかったか」「どの条件で実行に移されたか」まで確認できる。

実装は、重要な一つの判断フローから始める

最初から全社の検索基盤を作り替える必要はない。まずは、一つの重要な判断フローを選ぶ。

たとえば、顧客への特典付与、契約例外の承認、保全手順の提案、障害対応の優先順位付けなどである。

初期実装では、次の流れを作ればよい。

1. 業務ルール、仕様、過去判断、関連データに版と適用範囲を付ける。
2. 検索・選別を、ルールと軽量モデルで構成する。
3. 強いモデルへ渡すEvidence Packを固定する。
4. 判断・承認・例外をDecision Traceとして残す。
5. 実行前に、ポリシーと承認を実行境界で確認する。

この形であれば、性能、コスト、監査性、運用負荷を実測しながら、対象範囲を広げられる。

AIを「賢い答え」から「責任ある判断」へ

AIに任せる範囲を広げるほど、問題はモデルの能力だけではなくなる。何を検索させるか。どの根拠を採用させるか。どの判断を人へ渡すか。どの実行を止めるか。

検索と判断を分離することは、この複雑さを減らすための設計原理である。

軽量モデルとルールは、広く探し、速く絞り、制約を守る。強いモデルは、限られた根拠を統合し、説明し、設計する。人間とポリシーは、重要な選択と実行を統制する。

AI is not prediction. It is decision.

だからこそ、AIシステムは予測器としてではなく、根拠・判断・承認・実行を分離しながらつなぐ Decision Runtime として設計されるべきである。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance