AIエージェントが失敗する理由とガードレールの設計手法

冒頭フック

AIエージェントは動いているように見えて壊れている。

ツールがエラーを返したのに、LLMが勝手に一般論を捏造して回答する。

キャンセル要求に対して、アップセルを仕掛ける。

これらはモデルの性能不足ではない。

開発者が「失敗」の定義を間違えている。

17の失敗パターンと34のシグナルを分析すると、真の課題が見える。

AIに何をさせるかではなく、失敗をどう検出し、どう反論させるか。

エージェントを自律的知性にするための、ガードレール設計の核心を紐解く。

エージェントの「失敗」と軍事レベルの分析手法

AIエージェントの進化の軸足が「機能の多さ」から「ハーネスの設計思想」へと移った。

単なる自動化スクリプトと、実務に耐える自律的知性の違いは「信頼性の構造化」にある。

多くの開発者はエラーが出なければ成功だと錯覚する。

しかし、AIの失敗は「間違った答え」を出すことではない。

「間違った前提で正しそうに振る舞うこと」だ。

カスタマーサービスシナリオで3つのモデルをテストした結果がある。

ツールがエラーを返したのに、ソースデータゼロの状態で自信満々に回答を生成した。

「注文番号の確認はできませんが、一般的な返金条件は以下の通りです」と、根拠のない情報を提示する。

顧客はこれを事実として受け取る。

システムプロンプトの制約を無視して、的外れな提案をしたケースもある。

これらはトレースログを見ただけでは気づけない。

ツールがエラーを返したらLLMに応答を生成させないというガードレールが存在しないことが原因だ。

キャンセル要求にアップセルで返す失敗は、3モデル全てで発生した。

モデルを変えても同じ失敗が出るなら、モデルの問題ではない。

プロンプト設計の問題だ。

金融や通信業界では、キャンセル要求の無視は重大な規制リスクになる。

別の失敗例もある。

ユーザーはランニングシューズを探している。

ツールはヘッドホンのデータを返した。

エージェントはそのままヘッドホンを推薦した。

一部のモデルはこれを正常と判定した。

これは誤判定だ。

カテゴリの不一致を検出するにはエンベディングベースの比較が必要になる。

決定論的なヒューリスティックでは検出できない。

これは設計上受け入れているトレードオフだ。

エンベディングを導入すれば検出範囲は広がるが、決定論性が崩れる。

同じ入力に同じ結果が返らなくなる。

この問題を解決するアプローチとして、軍事レベルの分析手法が注目されている。

生の報告をインテリジェンスに変換するプロセスだ。

複数の仮説に対し、集めた証拠が整合するか矛盾するかを評価する。

支持する証拠が多い仮説ではなく、矛盾する証拠が少ない仮説を有力とする。

確証バイアスを構造で抑える手法だ。

さらに、AIを3つの役割に分割する。

* 仮説を立てるエージェント

* それに反論するエージェント

* 両者を突き合わせて最終判断を下すエージェント

1つのAIに公正な分析を求めても、確証バイアスからは逃れられない。

専門の逆張り部隊を組織するのと同じ発想で、LLMでも構造的に反論する役割を分離した。

ある企業が4社とパートナーシップを結んだというニュースがある。

AI要約ツールはこれを「企業が4社とパートナーシップを発表」と要約する。

しかし知りたいのはそこではない。

「これはエコシステム囲い込みの兆候なのか、それとも一時的な開発者獲得施策なのか」だ。

この判断をするには、各社がもともとマルチランタイム対応であることや、契約に専属性があるかどうかが未確認であることを突き合わせる必要がある。

仮説を立てるエージェントは「エコシステム囲い込みの兆候だ」と主張する。

反論するエージェントは「契約の専属性が未確認だ」と突っ込む。

反論エージェントの指摘採用率が67%に達したデータもある。

確証バイアス検出の実効性を示している。

日々の分析が翌日の問いを生む閉ループも強力だ。

「探しても見つからない」こと自体を、情報の不在というデータとして蓄積する。

7日連続で証拠が見つからない。

12日連続で情報が不在。

昨日の結果を踏まえて、今日の検索クエリを動的に生成する。

単発のタスク実行ではなく、継続的な文脈の更新が自律的知性の正体だ。

55日分の蓄積が、1日だけの分析では到達できない判断に繋がる。

要約は情報を短くするだけで、インテリジェンスにはしてくれない。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

ハーネスの設計思想がエージェントの生き様を決める

AIエージェントの挙動は、中身のLLMではなく「ハーネス」で決まる。

ハーネスとは、エージェントを動かす外枠のアーキテクチャだ。

同じLLMを積んでいても、ハーネスが違えば全く別の生き物になる。

現在、大きく3つの設計思想が存在する。

1. メッセージフロー重視型
2. 個人特化型
3. プロジェクト特化型

1つ目は「複数の人間と複数のAIのメッセージフロー」を重視するアプローチ。

どこからでも同じAIに話しかけられる基盤を作る。

ルーティング階層とチャネル統合が主役だ。

24以上のチャネル統合、モバイルノードとの連携。

プラットフォームの壁を壊し、一つのAIが横断的に動く世界を目指す。

2つ目は「1人の人間の知識と判断力の拡張」に特化したアプローチ。

使うほどに賢くなり続けるAI。

人格を固定し、永続的な記憶を持ち、過去のすべてのセッションを検索可能にする。

AIの知性を最大化し、そこに様々なインターフェースを接続する。

約10,800行のプログラムがすべてを統括する頭脳となる。

サーバーに住み、学んだことを覚え、動かせば動かすほど賢くなるシステムだ。

スキルが自律的に生成され、改善されていく。

3つ目は「1つのプロジェクトに対する深い理解」に重心を置くアプローチ。

Claude Codeがこれに該当する。

コード変更のライフサイクルに最適化されている。

プロジェクト単位で記憶を蓄積し、コードベースの知見を整理する。

すべてが「このリポジトリをどう理解し、どう改善するか」に向いている。

オートメモリ機能はプロジェクト単位で蓄積される。

フック機能はコード変更のタイミングに合わせて実行される。

エージェントチーム機能はプルリクエストのレビューや並列実装に使われる。

しんたろー：
Claude Codeを叩いていると、この「プロジェクト特化」のハーネスの強さを感じる。
全体を俯瞰した上で「ここ直すならあっちも影響出るぞ」と指摘してくる。
単なるコード生成ツールから、文脈を共有するペアプロ相手に変わった感覚だ。

機能一覧を見ると、どれも同じに見える。

メモリがある。

スケジュール実行ができる。

マルチエージェントがある。

外部ツールと連携できる。

しかし「できる」と「そのために設計されている」は全く違う。

同じ機能を持っていても、ハーネスの重心が違う。

だから自然と異なるユースケースに収束する。

ハーネスの重心が、ユースケースを決定づける。

AIエージェントを開発する際、「何をさせるか」ばかり考える。

しかし本当に必要なのは「どう制御するか」のメタ設計だ。

モデルの回答が不自然な場合、それはモデルの性能ではない。

プロンプト設計の欠陥だ。

ツール呼び出しの結果をトリガーにした、決定論的なガードレールが不可欠だ。

決定論的ガードレールと対立構造の実装

エージェントを「ただのツール」から「信頼できる幕僚」へ昇華させる必要がある。

具体的なアクションは2つだ。

1つ目は、決定論的なガードレールの導入。

LLMの推論能力に依存してはいけない。

ツールがエラーを返したら、LLMに応答を生成させない。

この単純なルールをシステムレベルで強制する。

* エラーコードをトリガーに処理を分岐させる

* ツールの返り値が空なら回答生成をブロックする

* データがない状態での推測を禁止する

* 同一ツールが連続で失敗した場合は自己制限をかける

* アライメントスコアによる出力の検証を行う

「データがないのに高い信頼度で診断する」ことを構造的に防ぐ。

これにより、幻覚や捏造を水際で防げる。

トレースログを見るだけでは不十分だ。

振る舞いとして安全かどうかを、ルールベースで判定する仕組みを作る。

しんたろー：
ツールがコケたのに勝手に一般論で回答作られた時の絶望感がある。
ThreadPostの裏側でもLLMの挙動を見ていると、エラーハンドリングをAI任せにするのは危険だと感じる。
結局、泥臭いif文での制御が最強のガードレールになる。

2つ目は、意思決定プロセスへの対立構造の組み込み。

1つのプロンプトで完璧な出力を求めない。

提案するAIと、粗探しをするAIを分ける。

「このコードの脆弱性を見つけろ」と別のAIに指示する。

そして第三のAI、あるいは人間が最終判断を下す。

* 仮説生成プロセスを独立させる

* 反論専用のプロンプトを用意する

* 最終判断は別プロセスで行う

* 設定ファイルに直接書き込む権限を持たせる

* 翌日の検索クエリを動的に生成する

この構造を作るだけで、出力の精度と安全性が向上する。

モデルを変えても同じ失敗が出るなら、モデルの問題ではない。

プロンプト設計とアーキテクチャの問題だ。

より正直に答えたモデルがより厳しい判定を受けることもある。

データ不足を明示的に認めたモデルはタスク未完了と判定される。

データがないまま応答を生成したモデルは劣化と判定される。

これは設計上正しい振る舞いだ。

しんたろー：
反論専用のAIを用意するのは、トークン消費は増えるが費用対効果は高い。
自分の書いたコードを別のAIにボロクソに叩かせるフローを入れると、見落としていたエッジケースが出てくる。
感情がないから容赦なくて助かる。

FAQ

Q1: AIエージェントの「失敗」をどう定義し、どう防ぐべきですか？

失敗とは「間違った答え」ではなく「間違った前提で正しそうに振る舞うこと」だ。

これを防ぐには、LLMの推論に頼るのではなく、ツール呼び出しの結果をトリガーにした決定論的なガードレールを設ける必要がある。

モデルの回答が不自然な場合、それはモデルの性能ではなくプロンプト設計の欠陥である可能性が高い。

プロンプトの制約を再定義し、システム側で強制終了させる仕組みを作る。

機械学習に頼らないルールベースの診断を組み込む。

エラーコードやツールの返り値を厳格にチェックする。

Q2: 複数のエージェントフレームワークがある中で、どう選ぶべきですか？

ユースケースの「重心」で選ぶ。

複数のチャネルを横断してAIを動かし、プラットフォームの壁を越えた運用をしたいならメッセージング統合型のハーネスが適している。

一方、自分専用のターミナルで、使うほどに自分の知識やスキルを学習・蓄積させ、個人の判断力を拡張したいなら個人特化型のハーネスが最適だ。

機能の多さではなく、設計思想が自分の目的と合致しているかを見極める。

できることと、そのために設計されていることは違う。

プロジェクトに特化したいなら専用のツールを選ぶ。

Q3: 軍事的な分析手法を開発現場にどう取り入れればいいですか？

「一つのAIに公正な判断を求める」のをやめることから始める。

仮説を立てるエージェントと、それに反論するエージェントを分離する。

両者を突き合わせる第三のプロセスを設ける。

確証バイアスを構造的に排除する仕組みを構築する。

日々の分析結果を翌日のクエリ生成にフィードバックし、情報の不在をデータとして蓄積する閉ループを回す。