配布資料 41事例 #01: ツール呼び出し書式ミスで AI の作業が停止し続けた

AI が同じ失敗を何度もします。しかも本人（AI）は失敗した自覚がありません。 性能の問題だと思って諦めかけた事故ですが、調べたら再現条件がありました。

何が起きたか

AI コーディングエージェントが、ツール呼び出しの開始マークアップのプレフィックスを落としました。さらに先頭へ無意味な短い英単語が混入することもありました。

実行環境はこれを「解析不能」として拒否します。呼び出しは完全な no-op になります。 ところがAI は「呼んだつもり」のままなので、そこで作業が止まります。

あるセッションでは、同じ書式ミスが1日に6回再発しました。

データ破壊はゼロです。拒否は無害だからです。 実害はリトライの手間と、「同じ失敗を直せないのか」という信頼の毀損のほうでした。

なぜ起きたのか

表面的には、出力の冒頭数トークンでの書式崩れです。

しかしログを調べると、失敗は例外なく「散文を書いた直後にツール呼び出しへ遷移したとき」に起きていました。メッセージをツール呼び出しから直接始めた場合は毎回成功しています。

モデルのデコーダは変更できません。 ならばトリガー条件そのものを規律で排除するしかありません。

そこから生まれたルール

「ツール呼び出しはメッセージの冒頭に単独で置く。説明はツールの後ろに回す。書式エラー警告を受けたら、謝罪や前置きを書かずにツール単体を即再送する」

出力規律として独立の文書にしました。

どう機械に守らせたか

三層にしました。

①セッション開始時に規律バナーを自動注入する ②毎プロンプトで2行のリマインドを再注入する ③ターン終了時に未パースの markup の痕跡を検知したら、終了自体をブロックして正書式での再送を指示する

③には仕掛けが要ります。検知メッセージ自体が再検知に引っかからない設計にして、無限ループ防止の循環ブレーカも付けました。

持ち帰るなら

AI の反復する失敗を「性能の問題」で片付けないでください。

バグ調査と同じ手順で再現条件を特定します。 条件が分かれば、モデルを変えられなくても運用規律とフックで発生をゼロに近づけられます。