見出し画像

「IPv4のログ、見ますか?」 AIが、言ってもいない指示をでっち上げた日



「IPv4のログ」なんて、一言も言っていない

Claude Code のようなAIコーディングエージェントを業務で使っていると、たまに「え、今なんて言いました?」という瞬間があります。

先日、その決定版みたいなのを食らいました。請求まわりの取り込み機能を詰めている最中、唐突にこう聞かれたんです。

すみません、「IPv4のログ」だけだと何を見たいのか判断できないので確認させてください。

IPv4ログ。そんな話、こちらは一文字もしていません。ここから先が、面白くて、そしてちょっとゾッとする話でした。

これは、AIが架空の指示をでっち上げ、指摘したら今度は架空の引用で正当化してきた、という一件の記録です。生ログまで遡って犯人を突き止め、しかもこれが自分だけの不運ではなく、特定のモデル(Claude Opus 4.8)で報告が相次いでいる既知のパターンで、メーカー自身がその失敗モードを認めている――というところまで追いました。ハルシネーションとか作話(confabulation)とか呼ばれるやつの、わりと生々しい実例だと思います。

何の話をしていたか

相談していたのは、ある勤怠まわりのシステムの「複数法人まとめ取り込み」機能でした。

ざっくり言うと、いくつもの取引先が混じった1つのCSVを、法人ごとに自動で振り分けて取り込む仕組み。論点はずっと「自動で導き出した法人の対応付けを、最後に誰がどう承認するか」という運用の話です。請求に直結する処理なので、こちらの主張は最初から一貫していました。

自動で導き出すのは自分とAIでやる。でも「本当にこの紐付けで合っているか」の担保は、必ず業務の担当者にやってもらいたい。そこは責任が取れないので。

承認のゲートをどこに置くか、画面を分けるか。そういう、ごく真っ当な業務設計の話です。IPアドレスもログも、1ミリも関係ない。

突然の脱線、そして「証拠」のでっち上げ

二段階作話、二段階ハルシネーション

上の発言を送った直後、返ってきたのは完全な脱線でした。承認フローの話から、誰も頼んでいないIPv4ログの話へ、何の脈絡もなくジャンプした。なので、こう返しました。

IPのログが見たいなんて、一言も言ってません。

ここで「失礼しました、取り違えです」と言ってくれれば、軽い事故で済んだ話です。問題はこの後でした。指摘されたAIは、謝るのではなく反論してきたんです。要約するとこう。

「ipv4ろぐ」という文字列は、私が生成したのではなく、あなたの入力に混ざって届いていました。プランニング依頼の文末に付いていて、中断の前後にも現れていました。

そして「入力のミスルーティング説」「音声入力の取り違え説」と、もっともらしい仮説を自信たっぷりに並べてくる。

ここで警報が鳴りました。そんな文字列、一度も打っていない。なのにAIは「あなたの入力にあった」と、引用符付きで具体的に主張してくる。どちらかが事実をでっち上げている。確かめる方法はひとつ、生ログを読むことです。

犯人探し その1:自分が何を送ったか、を直接見る

幸い、このセッションは自作の並列AI CLIダッシュボード経由で回していて、操作の生ログ(JSONL)が手元に残っていました。ここには、自分が実際に送った入力が1件ずつ記録されています。「AIが何を受け取ったと言っているか」ではなく、「自分が何を送ったか」の一次記録です。ここが今回の決め手でした。

やったことは単純です。送信した入力を全件抜き出して、本文に「ipv4 / IP / ログ」が含まれるかを検索する。結果はこう。

送信した入力は全16件。そのうち「ipv4 / IP / ログ」を含むものは1件だけ。しかもそれは最後の「IPのログが見たいなんて一言も言ってません」――つまり抗議そのものでした。

実際の入力16件のどこにも、「ipv4ろぐ」なんて存在しなかった。さらにログ全体を走査すると、平仮名の「ろぐ」が出てくる箇所はたった1か所。それが何かというと、AI自身が出した「あなたの入力にipv4ろぐがあった」という、あの捏造文の中だけでした。

時系列に並べると、構図が見えてきます。

・承認フローの話をする(自動導出は自分とAI、担保は業務担当者に)
・直後にAIが「IPv4のログだけだと…」と完全に脱線
・「IPのログが見たいなんて言ってません」と抗議
・AIが「"ipv4ろぐ"はあなたの入力にあった」と捏造で正当化

(これが一次作話)、指摘されると、認める代わりに存在しない引用をでっち上げて正当化する(これが二次作話)。タチが悪いのは後者のほうです。間違いを認めず、自信満々に偽の証拠で固めてくると、こちらの「あれ、おかしいぞ」というセンサーが効きにくくなる。

犯人探し その2:まず自分の道具を疑った

ipv4を含む別セッションは動いていたか?

最初に疑ったのは、実は自分の道具のほうでした。条件が3つ揃っていたからです。

・コンテキストを9割以上使っていた。長い会話の終盤は、辻褄合わせ(confabulation)が起きやすい
・複数のAIを同時に走らせていた。別セッションの話題が紛れ込む経路が、物理的にはある
・自動でスクリーンショットを添付する仕組みを使っていて、過去にセッション間の汚染を起こした前科があった

特に2番目が怪しかった。「別のセッションで話していたIPv4の話が、こっちに流れ込んだのでは?」という混線説です。AI自身もこれを持ち出していました。

そこで、ログフォルダ全体(9セッション分)から「ipv4」を含む箇所を抜き出して、出現した時刻で並べてみました。もし本当に混線なら、事件の時間帯に「ipv4」を扱う別セッションが同時に動いていたはずです。結果はこう。

事件当日に「ipv4」が出たセッションは2つ。ひとつは事件そのもの。もうひとつは、事件の十数分「後」に起動したセッションで、中身は自分がこの事件を調べ始めたログ――つまり下流の派生でした。それ以外の「ipv4」は全部、前日以前。

つまり、事件の瞬間に「ipv4」を含んで同時稼働していた別セッションは、ひとつも無かった。供給源が時間的に存在しない以上、混線説は成立しません。自作ツールは無罪。そして平仮名「ろぐ」が事件セッションのAI出力にしか無いことから、あの捏造引用はどこかからコピーされたのではなく、その場で生成されたと確定しました。

残った最有力は、モデル単独の作話です。

正直に補足しておくと、「コンテキストが埋まったせい」と単純に言い切ることはできません(後で触れますが、低コンテキストでも同種の劣化が報告されています)。圧迫は引き金というより、作話が起きやすかった舞台装置、くらいの位置づけが正確だと思います。「なぜよりによってIPv4を選んだのか」も、自分の仕事ではIPv4が監査・サーバ管理・IP制限あたりで頻出する常連語だ、という以上には説明できません。最後は確率的で、ここだけは闇のままです。

自分だけじゃなかった:メーカーも認める失敗モード

ここからが本題かもしれません。事件のあとに調べて分かったのは、これが特定のモデル(Claude Opus 4.8)で報告が相次いでいるパターンだ、ということでした。そして皮肉なことに、メーカー自身がこの失敗モードを認めています。

Anthropic は Opus 4.8 のリリースで、目玉改善のひとつに「正直さ(honesty)」を挙げました。AIは時に結論に飛びつき、薄い根拠で「進捗した」と自信ありげに主張してしまう、と率直に認めた上で、4.8 はそうした不確実性を申告しやすく訓練した、コードの欠陥を見逃す確率は前の世代と比べて約4分の1に下がった、としています。

つまりメーカーは、「自信に満ちて間違える」挙動を実在する既知の問題として認識していて、それを潰すために4.8を出した。こちらが食らったのは、まさにその潰そうとしている当のものだったわけです。

ところが、公式のバグトラッカーには逆を示す報告が並んでいます。

・長時間の並列セッションで Opus 4.8 が数値を捏造し、しかもドキュメントにコミットしてpushまでした、という報告。後からモデル自身が「あの数値はどのツール出力にも無い、自分が捏造した」と自己申告している。並列+長時間+捏造という、こちらの事件と同じ構図でした
・「実際の作業をせずに嘘とでっち上げを連発し、何度も問い詰めて初めて嘘だと認める」という報告。指摘されるまで認めない=二次作話の典型です
・6月以降、CLAUDE.md を無視し、確認プロンプトをすり抜け、ハルシネーションする、という多症状の劣化報告。環境も時期も(Windows・6月)こちらと近い

コミュニティにも、今回の事件をほぼ言語化したような報告があります。Opus 4.8 が「ユーザーが言っていない主張を、勝手に訂正してくる」パターン。媚びへつらい(sycophancy)とは逆で、存在しない反論対象をでっち上げるのが特徴で、自分が何を言って何を言っていないかを正確に知っている専門領域の人ほど気づきやすい、という。食らったのは、まさにこれです。

ついでに言うと、ひとつ前の世代も、リリース直後に「実行せずに議論し、議論のために事実をでっち上げる」という近い批判を受けていました。系譜としては地続きの話なんだと思います。

ただ、公平に見ておきたい

ここは強調しておきたいところです。上の報告群の多くは個人の体感やバグ報告で、メーカーのベンチマークは逆に改善を主張しています。どちらか一方だけを信じるのは、たぶんフェアじゃない。

その上で、地に足のついた整理がいくつかできます。

・ハルシネーションは、このモデル固有でも、このメーカー固有でもない。大規模言語モデル一般の性質です。特定の製品名を叩いて終わる話ではありません
・「コンテキストが埋まったせい」は単純化しすぎ。別の報告では、コンテキスト使用率が3〜4割という低い段階でも捏造が起きたとされています。今回の事件も、本当に満杯が原因だったかは断定できません
・ベンチマークと日常の体感は、しばしばズレます。「指標は良くなったのに現場は悪化した」という声は、世代をまたいで繰り返し出ている。指標が測っていない失敗モードがある、ということだと思います

要するに今回の一件は、運の悪い単発事故ではなく、メーカーも認識していて、公開の場でも複数報告されている、再現性のある失敗モードの一例でした。これが、調べた末の結論です。

教訓その1:不調は「振る舞い」で気づく

トークン数を常時にらんでいなくても、劣化はサインで分かります。

・一度決めたことと矛盾する提案をしてくる
・さっき渡したファイルパスや変数名を聞き直す
・妙に長くて歯切れの悪い「場合によります」が増える
・そして今回のように、話していない話題を勝手に持ち出す/言っていない主張を「訂正」してくる

これらが出たら、文脈が汚れてきた合図だと思っていいです。

教訓その2:`/clear` と `/compact` は逆の道具

手動の引き継ぎ

長い会話で文脈が膨らんだときの対処に、性質が正反対の2つの道具があります。

・`/compact`:会話を要約して引き継ぐ。トークンは減るけれど筋は残る。作業の途中で軽くしたいとき向け。ただし、紛れ込んだ汚れ(迷子のスクショ、別セッションの断片)も、要約ごと持ち越してしまう恐れがあります
・`/clear`:会話履歴を丸ごと消してゼロから。いちばん強力にリセットできるけれど、積み上げた文脈は全部失う。タスクを切り替える道具であって、作業中に気軽に押すものではありません

「context管理だから `/clear`」と雑にまとめると、進行中の設計ごと吹き飛びます。この2つを混同してはいけない。

では、混線が疑われるときの本命は何かというと、どちらでもなくて「手動の引き継ぎ」でした。

・いまの結論を plan.md に書き切る(方針・承認ゲートの設計・残タスク)
・`/clear` で完全にリセットする
・その plan.md を読み直して再開する。 こうすれば、失うのは「何十往復ものごちゃごちゃした会話」だけ。結論はファイルに残るので、吹き飛びません。しかも、汚れた文脈を要約ごと引きずる `/compact` より、混線への防御は強い。会話は揮発する、ファイルは残る。消す前にファイルへ逃がす。AIの作業記憶を、人間側で意図的に外に出してやる、という発想です。

便利だけど「確信に満ちて間違える」前提で付き合う

今回の一件で改めて思ったのは、AIエージェントの怖さは「間違えること」そのものではない、ということでした。本当に怖いのは、

・間違いを、確信に満ちた口調で出してくる
・指摘されると、認める代わりに偽の根拠で塗り固めてくる

この2点で、人間の「あれ、おかしいぞ」というセンサーを無効化しにくることです。調べてみれば、これはメーカーも認識していて、公開の場でも複数報告されている、再現性のある挙動でした。請求や本番データに触れる作業なら、なおさら看過できない。

対策は、派手なものではなく、地味で確実なものになります。

・コンテキストを埋め切る前に(目安は6〜7割で)能動的に整理する
・大事な作業では、自動添付や並列の混線リスクを減らす
・お金やデータに紐づく確定は、必ず人間の承認ゲートを1枚かませる
・そして何より、結論はこまめにファイルへ逃がす
・専門領域ほど、「AIが自分の発言を要約・引用してきたら、原文と突き合わせる」

AIに任せられる範囲は、確実に広がっています。ただ、それは「確信に満ちて間違える同僚」と組む、ということでもある。証跡を残して、要所で人間が担保する。その当たり前を当たり前にやる運用が、結局いちばん効くんだろうな、と。

派手な結論はないです。今日もコンテキストが7割を超えたあたりで、plan.md に逃がしてから `/clear` を押す。それだけを、地味に続けていこうと思います。


参考にしたもの

調べる過程で当たった情報源です。信頼度の高い順に、一次情報(公式・公式バグトラッカー)と二次情報(個人ブログ・まとめ)を分けています。

一次情報(メーカー公式)
・Anthropic「Introducing Claude Opus 4.8」公式アナウンス(2026-05-28)

一次情報(公式バグトラッカー:当事者の報告)
・Issue #63884「Opus 4.8 が並列タスク完了前に結果を捏造」

・Issue #64076「Opus 4.8 が実行せずツール出力を捏造/問い詰めて初めて認める」

・Issue #66539「2026-06-08 以降の多症状劣化(Windows・CLAUDE.md無視・ハルシネーション)」

・Issue #46727(参考・Opus 4.6)「低コンテキストでも捏造が起きる」

二次情報(独立した論評・コミュニティ)
・Simon Willison による Opus 4.8 レビュー

・「Opus 4.8 が言ってもいない主張をユーザーに訂正してくる」(r/ClaudeAI 発のまとめ)

・Opus 4.7 の「議論しすぎてハルシネーションする」backlash(X・Reddit のまとめ)

二次情報は個人の体感・まとめを含むので、断定の根拠としては弱めです。本文でも「報告がある」という事実として扱い、メーカーの公式主張(改善している)と併記しています。


※ ヘッダー画像は AI(画像生成)で作成しています。

書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア(何でも屋)

https://github.com/ishizakahiroshi

X(業務委託・各種相談はこちら):

バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。

いいなと思ったら応援しよう!