【408ランの実験で判明】AIエージェントの数え間違いはツールで直る

AIエージェントに「この中から条件に合うものを数えて」と頼んだことはありませんか？

私は、返ってきた数字をそのまま信じていました。数えるくらいできるだろう、と。

なので330件のIDリストを渡して数えさせ、その過程を全部記録しました。

3つのフレームワーク、同じモデル、同じ記録プロキシを通した408ランです。

結果は3つとも92.3%でした。ただし中身は同じではありませんでした。

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

何を試したか：行を返すツールと、数を返すツール

変えたのは、ツールの返し方だけです。

IDの一覧をそのまま返すツールと、件数を計算して返すツールを用意しました。

  設計A: ツールが行を返す         設計B: ツールが数を返す
  ┌──────────────────────┐      ┌──────────────────────┐
  │ ツール → [3, 7, 11,  │      │ ツール → {count:322, │
  │         … 330件]     │      │         min, max}    │
  └──────────┬───────────┘      └──────────┬───────────┘
             ▼ モデルが数える               ▼ モデルは読むだけ
         答「321」（実際は322）          答「322」（そのまま）

リストの長さは11件・110件・330件の3段階、聞き方は7通り、各3回です。

合計408ランになりました。

330件では数字が3つとも92.3%、ただし理由は2種類

まず押さえておきたいのは、モード名は「ツールに何を頼んだか」でしかないことです。

「フレームワークがモデルに何を渡したか」は別の話で、そちらは記録から数えました。

  330件で「id >= 9 は何件か」
  ┌────────────┬──────────────┬──────────────┐
  │            │ 行を返すとき  │ 数を返すとき  │
  ├────────────┼──────────────┼──────────────┤
  │ CrewAI     │   92.3%      │    100%      │
  │ LangGraph  │   92.3%      │    100%      │
  │ Strands    │   92.3%      │    100%      │
  └────────────┴──────────────┴──────────────┘
  （各26ランのうち24ラン正解＝92.3%）

92.3%という数字は3つとも同じですが、失敗の中身は2種類に分かれます。

CrewAIとStrandsは、2ランずつ「1〜2ずれた答え」を返しました。

LangGraphの2ランは、そもそも答えを出さずに終わっています。

同じ数字でも、同じ失敗ではありません。

11件と110件では、ほぼすべてが100%でした。

例外は1件だけで、CrewAIが数を返すモードの110件で107件を「106」と答えました。

間違い方も2種類あった

間違えた5件を、記録されたIDリストから数え直しました。

  Strands  322件と数えるべきところを「321」（境界の読み違い）
  Strands  同じく「321」（境界の読み違い）
  CrewAI   323件のところを「322」（境界の読み違い）
  CrewAI   321件のところを「320」（集計のズレ）
  CrewAI   107件のところを「106」（集計のズレ）

「境界の読み違い」は、>= 9 を > 9 と読んだものです。

リストには9がちょうど1件あるので、答えがその分だけずれます。

驚いたのは、5件すべてがツールを呼んでいたことです。

しかも5件すべて、正しいリストがその場（最終プロンプト）にありました。

私が最初に書いた「3件はツール未使用」は、計測側のバグでした。

CrewAIのツール名を数え損ねていて、呼び出しが0回に見えていたのです。

証拠はツール境界にある、と言いながら、私の集計コードが境界を見ていませんでした。

数を届けられた2つだけ、コストが下がった

同じ「数を返す」モードでも、モデルに届いたかどうかは3つで違いました。

  1問あたりのトークン（330件・回答が出たランの平均）
  LangGraph  8,574 → 143     （60分の1）
  Strands   11,528 → 1,418   （8分の1）
  CrewAI    14,600 → 12,565  （1.2倍。ほぼ変わらず）

CrewAIでは、数を返すモードでも分析役に届いたのはIDリストでした。

だからモードを変えても「自分で数える」工程が残り、コストもほぼ変わりません。

数を実際に受け取った2つは、答えが100%になり、コストが下がりました。

同じ「ツールに数えさせる」設計でも、届かなければ何も変わりません。

フレームワークの差が出なかったことの見方

今回いちばん驚いたのは、3つの差が出なかったことです。

LangGraphはツール呼び出しがコードの中にあり、CrewAIとStrandsはモデル駆動です。

構造が違うのに、330件では3つとも同じ数字に着地しました。

この条件の範囲では、フレームワークの層では防げませんでした。

防ぐ場所は、ツールの返し方か、モデルの外側の集計です。

  モデル → ツール → モデル → 答え
      ↑ ここで数えさせると負ける
                 ↑ ここ（ツール側）で数えれば、届く限り消える

どう防ぐか：ツールの返し方を変える

数を扱うツールを書くとき、私は次のようにしています。

• 数える対象が数百件を超えるなら、件数をツール側で計算して返す

• そのうえで、数が最終プロンプトに実際に載ったかを確認する

• 答えを受け取ったら、ツールを呼んだかを確認する（0回を許さない）

• 数字を下流に渡す前に、ツールの記録と突き合わせる

2つ目が今回いちばん効きました。設計しただけでは、届きません。

正直な限界

• 各セル21〜26ランです。統計的主張ではなく方向性です

• モデルは全ラン同一。別のモデルなら間違い方も変わります

• 途中、記録先のレート制限で落ちたランがあります（170ラベル）

• それらは再実行で埋め、採用したのは成功した方の記録だけです

• 2ランは答えを出さずに終わりました（1回の呼び出しで上限まで生成）

• そのうち1本のトレースには、上限張り付きの記録が2回分残っています

• 採用した集計からは除外しています

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