自社が運用する2体のAIキャラクターのうち、片方の応答は複数の言語モデルを使い分ける構成になっている。見張る仕組みは「健全」と報告し続けていたが、実際には数日間ほぼ全リクエストが失敗していた。この記事はその経緯と直し方をまとめる。
この記事で分かること
- 疎通確認が「健全」を返し続けていたのに、なぜ実際のやり取りは全滅していたか
- 見張る側の質問と本番の会話が、なぜ別の量として扱われるべきか
- 送信直前に会話の形式を整える直し方
この記事で分からないこと(正直に書く)
- 失敗が始まった正確な時刻までは特定していない
- 同種の形式制約がほかの呼び出し先にもあるかは、横断で洗い直していない
疎通は健全なのに、実際のやり取りは全滅していた
自社が運用する2体のAIキャラクターのうち、片方の応答は複数の言語モデルを使い分ける構成になっている。2026-09、切り替えを本格稼働させたところ、実際には4日間にわたり、そのモデルへのリクエストがほぼ常時失敗し、毎回もう一方のモデルへ自動的に振り替わっていた。1日あたり13,962件という規模で振り替えが発生していた(出所: 自社の運用記録、確認日2026-09-06)。
原因は「相手の形式」を満たしていなかったこと
呼び出し先のモデルは会話の形式に3つの制約を課していた。ユーザー役の発言が1件も無いと拒否する、途中に指示役の発言があると拒否する、扱える文章量に上限がある、というものである。自律的に発話を作る仕組みが組み立てる会話は、ユーザー役の発言が無く途中にも指示役の発言が挟まり、長さも上限を超えることがあった。もう一方のモデルはこれらをすべて受け入れる作りだったため、そちらだけで動いていた間は表面化していなかった(出所: 自社の運用記録、確認日2026-09-06)。
なぜ気づけなかったか
稼働状況を見張る仕組みは、正しい形式の質問を定期的に送って200が返るかを確認しており、この確認は毎回成功して「健全」と報告し続けていた。壊れていたのは呼び出し先の健康状態ではなく、こちら側が組み立てて送る会話の形だった。見張る側の質問は毎回同じ決まった形をしているのに対し、本番の会話は毎ターン内容が変わるため、疎通確認では原理的に再現できない種類の不具合だった(出所: 自社の運用記録、確認日2026-09-06)。
どう直したか
2026-09に、送信直前に会話の形式を整える処理を追加した。先頭以外の指示役の発言はユーザー役に置き換え、末尾がユーザー役でなければ補い、文章量が上限を超える分は古い履歴から削って収める、という3つである。あわせて見張る仕組みに、運用ログから振り替え件数を数える確認を追加し、一定件数を超えたら別経路で警報を出すようにした(出所: 自社の運用記録、確認日2026-09-06)。
検査に何を書けば次は見つかるか
相手が疎通できることと、自分が組み立てて送る内容が受け入れられることは別の量として扱う必要がある。疎通確認は決まった形の質問しか送れず、本番の会話特有の崩れを検出できない。実際の失敗を見つけるには、本番のログに残る振り替えや失敗の件数そのものを数えるしかない。
同じ「見張る側は健全だと言い続けていた」型の事故は、書き込みが静かに消えた記事や、5xx監視の「ゼロ件」の記事でも扱っている。
自社のAIキャラクターの応答基盤・監視設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 何が起きていたのか
自社が運用する2体のAIキャラクターのうち片方が呼び出す言語モデルへのリクエストが、4日間にわたりほぼ常時失敗し、毎回もう一方のモデルへ自動的に振り替わっていた。1日あたり13,962件の規模だった。
Q2. なぜリクエストが失敗していたのか
呼び出し先のモデルは、ユーザー役の発言が1件も無い、途中に指示役の発言がある、文章量が上限を超える、という3つの形式を受け付けない作りだったが、自律的に組み立てる会話がこれに当てはまっていた。
Q3. なぜ見張る仕組みは異常に気づかなかったのか
見張る仕組みは決まった正しい形の質問を送って200が返るかを確認していたため、常に成功していた。壊れていたのは相手の健康状態ではなく、こちらが送る会話の形だったため、疎通確認では検出できなかった。
Q4. どう直したのか
送信直前に会話の形式を整える処理を追加し、指示役の発言をユーザー役に置き換え、末尾をユーザー役の発言で終わらせ、上限超過分は古い履歴から削るようにした。あわせて振り替え件数を数えて警報を出す仕組みも追加した。