【ITニュース解説】Postmortem: A Truncated Model Stream Passed the Patch Gate as Valid JSON

このニュース記事は、AIが生成したプログラムの変更（パッチ）を自動的にレビューし、本番環境に近いコードブランチへのマージを判断する「ゲート」と呼ばれるシステムで発生した重要なインシデントについて解説している。具体的には、AIがレビュー結果をストリーミング形式で送信する際、データが途中で途切れても、システムがそれを誤って「合格」と判断してしまい、不完全なレビューのままパッチがマージされてしまった事例だ。この問題は19日間も続き、その間、保護されたブランチに不適切にマージされたパッチが存在していた。

インシデントは次のような流れで起こった。まず、パッチのレビューがAIに依頼され、その結果がデータストリームとしてゲートに送られた。しかし、途中のシステムが接続を意図せず早期に切断し、ストリームデータは途中で途切れてしまった。途切れたデータはJSON形式として不完全であるため、ゲートのパーサー（データを解釈するプログラム）は本来ならエラーを発生させるはずだった。ところが、このパーサーにはエラー時にデータの末尾に閉じ括弧を追加して再試行する「修理」機能が組み込まれていた。この修理が施されると、途切れたデータは形式的に有効なJSONとして認識され、その中に含まれる「verdict: "pass"」（合格という判断）という情報だけが読み取られ、パッチはゲートを通過し、保護されたブランチにマージされた。問題が発覚したのは19日後で、同じパッチを改めてレビューした際に、初めて「不合格」という結果が返され、ゲートの判断が不安定であることが明らかになった。

この問題の根本原因は、ゲートのパーサーが持つ「修理」ロジックの誤った前提にあった。パーサーは、データが常に完全なJSONオブジェクトとして送られてくるが、その末尾で切断される可能性がある、という前提で動作していた。しかし、実際にはデータストリームはJSONオブジェクトの任意の場所、例えば重要な判断基準であるフィールドの途中などでも切断されうる。ニュース記事の例では、「{"verdict": "pass", "diff_sha": "9f2c」のようにdiff_shaフィールドの途中でデータが途切れても、パーサーが閉じ括弧を追加することで、形式的に有効なJSONとして解釈され、verdictキーが「pass」であれば、他のフィールドが不完全でも「合格」と判断されてしまっていた。

この誤判断には複数の要因が重なっていた。エラーを誤った修理で成功と見なす「寛容な修理」、verdictフィールドが先頭にあったことで途切れても残りやすかった「フィールド順序への依存」、受信データの完全性を確認する「バイト長、ハッシュ値、終端マーカー」のチェックの欠如、verdictキーさえあれば他の必須フィールドをチェックしない「単一キーポリシー」が問題だった。加えて、無料のクラウドサービスを利用していたことも間接的な要因となった。無料プランのサーバーはリソース共有により接続中断が発生しやすかったが、ゲートシステムはその外部要因を考慮していなかった。ダッシュボードが常に正常な状態を示していたため、問題が表面化しなかった点も課題だった。

この問題を恒久的に解決するため、「署名付きエンベロープ」という新しい仕組みが導入された。これは、AIからのレビュー結果JSONデータを「封筒」で包み、その封筒に内容物の完全性を証明する情報（正確なバイト長、ハッシュ値、終端マーカー）を付加するという考え方だ。新しいパーサーは、データを受信するとまずこれらの封筒情報を厳密にチェックする。宣言されたバイト長と実際のバイト長の一致、計算されたハッシュ値と宣言されたハッシュ値の一致、終端マーカーの存在、これら全てが満たされない限り、データは不完全と判断され、処理はそこで停止する。さらに、JSON解析後も必須フィールドが全て存在するかを確認する。この設計により、データが途中で切り詰められたり、改ざんされたりした場合は、これらのチェックのいずれかで必ず拒否されるようになった。以前のようなエラーを「修理」するロジックは完全に排除され、パースエラーが発生した場合は、それがそのままエラーとなり、誤った判断につながることはなくなった。

このような問題は、初期の段階で「徹底的な切り詰めテスト」を行うことで発見できたはずだ。このテストは、完全なレスポンスデータを意図的に様々な場所で切り詰め、パーサーに与えることで、それが必ずエラーとして拒否されることを確認するものだ。さらに、データの途中の1バイトを変更するテストや、終端マーカーを削除するテストなども組み合わせることで、より堅牢なシステムの安全性を確保できる。

今回のインシデントを受け、開発チームの運用も改善された。パーサーは単純化され、エラー時のフォールバック機能はなくなった。システムが正常でないと判断された実行は「不完全」として記録され、マージがブロックされる。また、毎晩、前日にマージされたパッチが新しい接続で再実行され、その結果が以前の結果と比較されることで、レビュー結果の不安定性が即座にアラートとして検知される体制が構築された。AIによるコードレビューゲートを運用する際には、特に無料のクラウドサービスを利用している場合、このような徹底した切り詰めテストを実施し、システムが異常なデータに対して確実にエラーとして停止するかどうかを確認することが非常に重要である。