試運転拾

「長文だからAIは馬鹿になる」の正体 ― AI隊の話題逸脱バグを潰した話

AI隊を実運用していて、不思議な現象に遭遇した。

新しい相談をしているのに、AIが何度も昔の話題を持ち出すのである。

例えば、

「長い指示文を渡すと送信できなくなる」

という相談をしたにもかかわらず、

「アイコンは修正濟みです」

という、何日も前に解決した話を最終報告に書いてきた。

最初は「長文になるとAIは馬鹿になるのでは？」と思った。

しかし、調べていくうちに原因は別のところにあった。

原因は「長文」ではなく「情報構造」

AI隊では過去の会話を resume_context として隊長へ渡している。

ところが、その中身は単なる長い時系列ログだった。

つまり、

• 今回の依頼
• 昔の修正履歴
• 過去の会議
• 参考情報

が全部同じ重みで並んでいたのである。

するとLLMは、何度も登場する「アイコン」という話題を重要だと判断し、最新の相談より優先してしまった。

問題は文字数ではなかった。

情報の役割が整理されていなかったことだった。

解決策は「構造化」

そこで resume_context を次のように構造化した。

【今回の依頼】

【今回の作業】

【今回の未解決】

--------------------

【過去の経緯（参考情報）】

さらにプロンプトへ、

最終報告は必ず「今回の依頼」について答えること。
過去の経緯だけで利用者向け結果を作成してはならない。

という強い制約を追加した。

その結果、4000文字を超える過去ログが存在しても、AIは最新の相談を主題として扱えるようになった。

バグ修正より大きな成果

この修正で一番大きかったのは、話題逸脱が改善したことではない。

「なんとなく直った」で終わらせず、

• 仮説を立てる
• 設計を変える
• テストを書く
• 回帰テストへ組み込む

という開発プロセスを確立できたことだった。

今回作成したテストは、AI隊の tests/ ディレクトリへ正式に登録し、今後の品質保証資産として残した。

次に見つかった課題

話題逸脱が直ると、今度は別の問題が見えてきた。

AIは一般論をもっともらしく語ってしまう。

例えば、

「install.ps1 が動かなかった」

という事実しかないのに、

• 実行ポリシーかもしれない
• PATHかもしれない
• 権限かもしれない

と、ありがちな原因を列挙してしまう。

そこで報告を、

【確認濟み事実】

【推測・原因候補】

に分離した。

さらに、

推測を書く場合は必ず根拠となるエラーログを引用すること。
根拠を引用できない場合は推測を書かないこと。

という「引用強制ルール」を導入した。

これにより、

• 根拠がない時は「推測できません」
• 根拠がある時だけ仮説を提示

という、より信頼性の高い報告ができるようになった。

実運用でしか見えない問題

実運用を続けると、さらに別の不具合も見つかった。

長文の指示を入力すると、送信ボタンが消えてしまう。

これはLLMではなくGUIの問題だった。

AI隊を実際に使い続けることで、

• 話題逸脱
• 報告品質
• GUIのレイアウト

といった異なる種類の課題が次々と見つかる。

だからこそ、AIエージェントは机上で完成するものではなく、実運用を通じて育てていくものなのだと改めて感じた。

まとめ

今回の開発で得た最大の学びは、次の一言に集約される。

「勘をテストに変える。」

「長文だからAIは馬鹿になる」という直感は、仮説に過ぎなかった。

しかし、

• 原因を切り分け、
• 情報構造を改善し、
• テストを書き、
• 回帰テストとして残す。

この流れを経て、経験や勘は再現可能な品質保証へと変わった。

AIエージェント開発では、コードだけでなくプロンプトも品質保証の対象である。

そして、実運用で見つかった違和感を一つずつ設計原則へ昇華していくことが、長く使えるAIシステムを育てる最も確実な道なのだと実感した。