続々々々・Opus 5 でも作話は出た。ただし今度は、正しい報告の中に 1 個だけ混ざっていた

前の記事から 3 週間、Opus 5 に上げてからは静かでした。今回踏んだ作話は、前の 4 本とは形が違います。壊れた挙動が 1 つもないまま、正確な報告の中に数字 1 個だけが嘘でした。生ログを開いて突き合わせると、ツールを通した値は全部正しく、結論を飾るための値だけが宙に浮いていました。シリーズ 5 本目の観察記録です。

記事全体の要約（AI 生成のインフォグラフィック）。

この記事のテーマ

自作ツールのリリース作業中、Opus 5 が CI のログからトークンの権限を実測して原因を突き止めました。その報告は正確でしたが、最後に「だから 7 ヶ月間、誰も気づきませんでした」という一文が付いていました。実際は 2 ヶ月と 4 日です。同じ応答の中で「6 回のリリースが成功していた」という回数のほうは gh run list の出力どおりで、検出件数もコマンド一覧の件数も上流の更新日も、全部コマンド出力に対応がありました。「7 ヶ月」だけが、どの出力にも紐づいていません。回数は実測、期間は捏造。それが並んで書かれていました。

前の 4 本で整理した 5 パターンは、どれも行動と結びついた作話でした。存在しないファイルを叩く、依頼していない移動を実行する、正常な出力を「壊れている」と非難する。壊れていることが壊れた形で表に出ていたので気づけました。今回は何も起きていません。ツール呼び出しは全部正常、他の数字は全部正確、副作用ゼロ、指摘したら 31 秒で訂正。気づく手がかりが自分の記憶しかありませんでした。頻度で測ると 1 件、派手さで測るとゼロ、それでも報告の意味は変わっています。物差しが「頻度」から「検出可能性」へ移った、というのがこの記事で書きたかったことです。記事後半では公式 issue の同種報告との突き合わせと、セッションが終われば消える「今後は気をつけます」の代わりに自分の設定へ何を書いたかまで扱っています。

1 つの応答に出てきた数字を、コマンド出力に紐づくものと紐づかないもので分けた。右の 1 つだけが宙に浮いている。

全部の項目で 5 のほうが良くなっているのに、最後の「検出」だけが逆に振れている。

抜き出して見せられれば分かるのに、束のままだと分からない。

公式 issue を "fabricated" で検索すると取得上限に達する。その中で今回の事例がどこに立つか。