AIエージェントのロギングで72時間監視したら、ツール呼び出しの37%でパラメータ不一致が起きていた——しかもエラーにならない

Reddit r/artificial / 2026/4/24

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical Usage

要点

  • 72時間にわたって84回超のツール呼び出しをログ記録したところ、37%でパラメータ不一致があり、エラーを出さずにもっともらしい出力が返っていた。
  • サイレントな失敗は、タイムスタンプとdurationの取り違え、endの包含/排他の違いによる境界のオフバイワン、配列とカンマ区切り文字列のフォーマット差といった契約レベルの問題に由来していた。
  • さらに「yesterday」のような相対日時を、Unixタイムスタンプを期待するAPIに渡すとNaNとして解釈され、エラーにはならず空の結果だけが返るケースも大きな要因だった。
  • 著者は、これはモデルが捏造しているというより意図と少し違う質問を投げてしまい、ツールが誤った質問に対して200 OKで答えてしまう問題だと述べている。
  • 対策として、ツール定義に入力バリデーションのスキーマを追加し、実行前に型不一致を検出して誤データの下流への伝播を防ごうとしている。

私は、さまざまなAPIに対してツール呼び出しを行うAIエージェントを運用していて、送信された内容がツール側の期待とどれだけ一致しているかを正確に記録するためのログレイヤーを追加しました。72時間で84回以上のツール呼び出しがあり、そのうち31回(37%)でパラメータの不一致が発生しました——そして、どれ一つとしてエラーを起こしませんでした。

ツールは誤ったパラメータを受け取り、もっともらしく見えるが正しくない出力を返しました。

私が見つけた4つの失敗カテゴリは以下です:

1. タイムスタンプ vs 所要時間 — エージェントは、APIが "24h" のような所要時間文字列を期待しているところへ、Unixタイムスタンプを渡しました。APIはそれを所要時間として黙って解釈し、意図していたまったく別の時間範囲に対する結果を返しました。

2. 包含 vs 排他の範囲 — エージェントは end=100 を送信し、「100を含めて最大まで」を意味するつもりでしたが、APIはそれを排他的(exclusive)に解釈し、境界値を取りこぼしました。API契約レベルでのオフバイワンです。

3. 配列 vs カンマ区切り文字列 — エージェントは ["a", "b", "c"] を送信しましたが、APIは "a,b,c" を期待していました。いくつかのAPIはJSON配列を単一の文字列として解析しましたが、別のものは黙って最初の要素だけを取りました。

4. 相対時間 vs Unixタイムスタンプ — エージェントは、Unixタイムスタンプが期待されているところへ "yesterday" を送信しました。APIはそれを整数として解析しようとしてNaNを取得し、そして……エラーを出す代わりに空の結果を返しました。

これらの失敗で最も危険なのは、正しい結果と見た目がまったく同じに見えることです。APIは、もっともらしいレスポンスボディとともに200 OKを返します。答えが 正しい かどうかを掘り下げて確認するときに初めて気づくのです。呼び出しが 成功した かどうかではありません。

これは基本的にハルシネーションとは別物です。モデルがでたらめを作っているのではなく、あなたが意図したものとは少し違う質問をモデルが投げてしまい、ツールがその誤った質問に対して当然のように正しく(誤った形で)答えてしまう、ということです。

私は、ツール定義に入力バリデーション用のスキーマを追加し始めていて、実行前に型の不一致を検出するようにしています。すでにいくつか、下流へ黙って誤データが伝播してしまうはずだったものを見つけられました。

他にも、このパターンに遭遇した人はいませんか?本番環境のエージェントシステムで、サイレントなパラメータ不一致を検出するための戦略は何ですか?

submitted by /u/ChatEngineer
[link] [comments]