自社が運用する2体のAIキャラクターは、互いの発言を記憶して次の発話に活かす仕組みを持っている。2026-09の実測で、そのうち片方でこの仕組みが大半失敗していたことが分かった。原因はエラーではなくINFOレベルのログとしてしか記録されておらず、誰も見ていなかった。この記事はその経緯と直し方をまとめる。
この記事で分かること
- たった1行のログ破損が、なぜ機能全体を止めてしまったか
- INFOレベルの失敗ログが監視から漏れる理由
- 追記型ログを読む処理をどう壊れに強くしたか
この記事で分からないこと(正直に書く)
- 破損がいつから始まっていたかは、発生時刻まで遡って特定していない
- 同種の追記型ログがほかの機能にもあるかは、横断で洗い直していない
掛け合いの大半で、相方の記憶が入っていなかった
自社が運用する2体のAIキャラクターは、互いの発言を記憶して次の発話に活かす仕組みを持っている。2026-09の実測で、そのうち片方が220回の発話機会のうち163回、74%でこの仕組みが失敗していたことが分かった(出所: 自社の運用記録、確認日2026-09-06)。
原因は33万行のうちのたった1行
記憶は追記型のログファイルに1行ずつ書き足して保存されている。この日、そのファイルの最終行が文字の途中で切れ、改行の無いまま次のレコードへ直接つながっていた。書き込みが途中で中断した跡である。読み込み処理はファイル全体を1つのテキストとして読む作りだったため、この1行で文字コードの変換に失敗し、記憶を扱う関数がまとめて例外を起こして落ちていた(出所: 自社の運用記録、確認日2026-09-06)。
なぜ気づけなかったか
失敗はエラーではなくINFOレベルのログとして記録されていた。配信自体は普通に続き、掛け合いも成立しているように見える。実際には片方が相方の発言を覚えないまま応答していただけだが、その状態を「相互に反応し合っている」と見誤っていた。もう一方のログファイルは壊れていなかったため、失敗は片方向だけで起き、双方を並べて比べない限り気づけない形をしていた(出所: 自社の運用記録、確認日2026-09-06)。INFOレベルのログは通常監視されず、失敗率を集計しない限り機能が大半死んでいても表には出ない。
どう直したか
2026-09に2つの対応をした。1つは読み込み側を、壊れた行があっても止まらない作りに変えたことである。ファイルをバイト列として読み、1行ごとに文字コード変換を試みて失敗した行だけを読み飛ばし、件数は警告として1度だけ出力する。もう1つは壊れたファイルそのものを直したことで、退避を取ったうえで正常な行だけを書き戻し、一時ファイルへ書いてから置き換えることで配信を止めずに入れ替えた。修正後に再起動して確認したところ失敗は0件になり、双方向で記憶の読み込みが成立していた(出所: 自社の運用記録、確認日2026-09-06)。
検査に何を書けば次は見つかるか
INFOレベルの「failed」は誰も見ない前提で設計を変える必要がある。追記型のログを読む処理には、行単位で壊れを吸収する作りを標準にし、さらにその日の失敗率を数値として出す検査を置く。74%という数字は、この検査を作って初めて見えたものである(出所: 自社の運用記録、確認日2026-09-06)。観察している挙動が本当に成立しているかどうかは、数えてみるまで分からない。
同じ「見張る側は健全だと言い続けていた」型の事故は、通信断でも正常終了に見えた記事や、疎通は健全なのに全滅していた記事でも扱っている。
自社のAIキャラクターの記憶設計・監視設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 何の仕組みが失敗していたのか
自社が運用する2体のAIキャラクターが互いの発言を記憶して次の発話に活かす仕組みが、片方で失敗していた。220回の発話機会のうち163回、74%で記憶が読み込まれていなかった。
Q2. なぜたった1行の破損で機能全体が止まったのか
記憶を追記型のログファイルとして1つのテキストで読み込んでいたため、最終行が文字の途中で切れているだけで文字コード変換に失敗し、記憶を扱う関数全体が例外で落ちていた。
Q3. なぜ気づくのに時間がかかったのか
失敗はエラーではなくINFOレベルのログとして記録されており、通常は監視されない。配信自体は続き、掛け合いも成立しているように見えたため、失敗率を数えるまで気づけなかった。
Q4. どう直したのか
読み込み側をバイト単位で読み、壊れた行だけを読み飛ばして警告を1度だけ出す作りに変え、壊れたファイルは退避を取ったうえで正常な行だけを書き戻し配信を止めずに入れ替えた。