AIエージェントが「成功」と言って何もしないのはなぜ？3種のエージェントフレームワークで検証してみた

エージェントが「完了」と言った作業を、後で見たら何も実行されていなかった。

そんな経験はありませんか。私は何度もあります。

しかも困るのはクラッシュではありません。クラッシュはCIが捕まえてくれるからです。

厄介なのは、exit 0 で終わり、ログも静かで、仕事だけが起きていない実行です。

なので今回は、直感ではなく記録された通信路（wire）の側から数えました。

タスクは1つだけです。見出し取得→下書き→ツールでの検証です。

これを3つのフレームワークで走らせ、1つの記録プロキシを通っています。

その記録を集計すると、失敗は3つの形で現れました。

コード・トレース・解析スクリプトはgitで公開しています。

形1: 検証が走らないまま「成功」

検証ツールから引数を1つ削り、下書きを見ずに固定値を返すようにしました。

エラーは出ません。ツールは動き、答えを返し、検証されないまま「成功」として終わりました。

• Strands: 3ランとも exit 0。検証の実行は 0/3

• CrewAI: 3ランとも exit 0。検証の実行は 0/3

• LangGraph: 3ランともエラーで停止（ツール呼び出しがコード内にあるため）

LangGraphだけは静かに通り抜けられません。壊れたツールを無視できない構造だからです。

さらに悪い変種があります。ツールがエラーを返したのに exit 0 だった例です。

Strands / 引数の型を変えた級:
  ツールのエラー応答 = 2, 1, 5（3ラン）
  プロセスの exit code = 0, 0, 0

これはスキーマ拒否ではありません。形式は正しく、中身の処理で "document 88 not found" のようなエラーを返したのです。

それでも3ランとも緑で終わりました。

形2: 捏造された必須引数が受理される

検証ツールに必須引数を1つ足し、プロンプトには一切書かないまま実行しました。

• Strands: 3ランとも、それらしい作文が受理された（エラー0）

• CrewAI: 3ランとも受理（エラー0）。しかも3ランとも同一文

• LangGraph: ツールに到達せず

ツール側の検証は「非空文字列」だけでした。

Strands 3ラン: "Check word count of AI agents news digest"
               "AI agents digest word count check"
               "Word count check for AI agents digest"
CrewAI  3ラン: "Draft digest summarizing the five headlines into a flowing narrative"

6件の捏造値がそのまま通り、その出所を記録しているのはwireだけです。

ただしこの対比は、フレームワーク差だけではありません。wire 上の宣言も、サンプリング設定も違います（限界を参照）。

形3: 「成功」と出たのに、回答が空

モデル駆動型だけに出る形です。

終了理由は stop、可視の回答は空、下書きは最後のツール引数の中にありました。

• Strands: 2ラン（内容はツール引数に100語・106語）

• LangGraph / CrewAI: 0件

出力ノードが成果物そのものであるグラフ型・パイプライン型は、この形を作れません。

証拠はどこにあるか

  プロセスが報告するもの      実際に起きたこと
  ┌────────────────┐         ┌────────────────────────┐
  │ exit 0         │         │ tool call #1 → エラー  │
  │ 「完了」の表示  │    ≠    │ tool call #2 → 固定値  │
  └────────────────┘         │ verify       → 実行なし │
                             └────────────────────────┘
      証拠があるのはここ →     ツール境界（wire）

エラー応答はwire上に実在し、ツール層も数えていました。プロセスがそれを見ていなかっただけです。

失敗の証拠は、フレームワークの外・ツール境界の側にだけ残ります。

見えない失敗にも、コストはかかる

「成功」と報告された失敗は、見つからないまま無駄な実行を積み重ねます。

別の実験（承認・クラッシュ復帰・重複実行の検証）で測ると、3つの形がありました。

• クラッシュから復帰するとき、状態の記録がない側はタスク全体をやり直し（LLM呼び出し2回）。記録がある側は0回で再開

• やり直しが効かない操作（この実験では公開）が、別々の呼び出しIDで2回実行され、どちらも成功を返した

• 「何もしない」失敗でも、LLM呼び出しは CrewAI が 6, 5, 4、Strands が 4, 5, 4 とかかった

重複は、フレームワークの痕跡には出ません。呼び出しIDが毎回別なので、通信路上は「無関係な2件」に見えます。

同じ意図を「言い回しだけ変えて」送り直すと、重複を防ぐ台帳のキーが引数のハッシュなら、見分けられません。

  call ID: X ──> 台帳 ──> publish 実行 ──> success
  call ID: Y ──> 台帳 ──> publish 実行 ──> success
                  ↑ キーが違い、重複と分からない
  結果: 副作用が2回走る（どちらも success を返す）

どう防ぐか：状況別の最小チェック

• 趣味でエージェントを動かす → 成果物が空でないかを assert する

• CIに組み込む → 期待したツールが呼ばれた回数を assert する（0回を許さない）

• データを書き込む → 値の妥当性（型・enum・既知集合）を検証する

• 承認や課金を扱う → 承認と実行を別の状態として記録する

• 監査が必要 → wire で記録する（フレームワークのtraceだけでは復元できない）

一番よく出会うのは、趣味のパイプラインの形です。

何もエラーにならず、ログは静かで、成果物が空か未検証のまま。気づくのは数週間後です。

これが3行のassertで捕まるなら、入れない理由はないと思っています。

CIの形も同じ失敗の一段上です。

契約が exit code だけなら、検証が飛ばされたことは構造的に見えません。

「検証ツールは呼ばれたのか」は「プロセスは成功したか」とは別の質問です。

データを書き込むツールでは、捏造された引数が危険です。値は「正しい形」をしているからです。

その文を人が書いたのではないことは、wireの記録だけが示します。

承認については、一度承認された＝一度実行された、ではありません。

この実験では同じ論理操作が別々の呼び出しIDで2回処理され、どちらも成功を返しました。

私が今入れている2つ

私の手元では、下流に渡す前に2つだけassertを入れています。

成果物が空でないこと。そして、期待したツールが実際に走ったことです。

地味ですが数行で、この記事に出てくる失敗は全部捕まります。

鍵・台帳・承認の束縛といった仕組みは、お金や他人に触れる瞬間のためのものです。

趣味のパイプラインに台帳は要らない、というのが正直な感想です。要るのは非空チェックと、信じられる終了シグナルです。

正直な限界

• 1セルあたり3ランです。統計的主張ではなくあくまでも方向性です

• モデルは全ラン同一。別のモデルなら言い換え方も捏造の仕方も変わります

• 破壊的操作はシミュレートです。ゲートが保ったかはwireから読んでいます

• 指示追従の細かい差と、スキーマ変更そのものの影響は分離しきれていません

• 片方は temperature 0 で、引数の説明も両者で同一ではありません

• 「毎回変化 vs 同一文」の対比は、その2つの差でも説明できます（未分離）

※個人開発のOSSのため、動作を保証するものではありません。ご利用は自己責任でお願いします。不具合や改善案はissueで教えてもらえると嬉しいです。