#19｜なぜ複数のLLMが同時に不安定化したのか

1. 単一モデル障害では説明できない

今回観測された不安定挙動は、GPT系／Gemini系／Claude／Copilot（GPT基盤）／その他派生LLMなど、複数系統で同時に発生している。
単一モデルの障害だけでは、ここまで横断的な症状は説明できない。

2. 起点は明確に存在する

観測上、起点は以下に集約される。

• GPTの障害・Yellow State
• Geminiの高負荷状態

Geminiについては、Chrome検索への組み込み／Android OSレベルでの常設化／ライトユーザーの急増／GCP・GWSの継続的内部更新が 同時に進行しているフェーズにある。
つまり「モデル性能」ではなく、利用構造と更新タイミングが重なった状態として捉えるべきである。

1. 多くのLLMは独立していない

CopilotはGPT基盤であり、その他のLLMの多くも GPT / Gemini を「直接利用」「派生利用」または 推論構造・設計前提（制御ロジック）を参照している。
そのため、起点モデルが揺れると負荷が移動し、別モデルにも過剰負荷が発生しやすい。

2. 検索・OS組み込み型AIの特殊性

Geminiは「検索の延長」「OSの一部」「常時オン補助AI」として動作している。
明示的な入力だけでなく、裏側での要約・補完・リランキング・推論補助が常時発生する設計になりやすく、 ユーザーが意識しない形で推論負荷が積み上がる。

制御破綻・応答破綻・推論破綻（代表例）

• ループ：同じ修正指示や、同一のソース箇所に対する変更を何度も繰り返す。既に修正済みの内容を「未対応」と誤認するケースも含む。
• 応答の暴走：質問や指示の範囲を逸脱し、不必要に長い説明や、意図しない結論を一方的に生成する。
• 文脈の断絶：直前まで共有されていた前提や制約条件が失われ、話題や判断基準が突然切り替わる。
• 勝手な要約：明示的に求めていないにもかかわらず短縮・再解釈し、重要な前提や例外条件、ソースコードを削ぎ落とす。
• 初期化：進行中の作業や合意済みの内容を忘れたかのように振る舞い、会話が事実上、最初からやり直しになる。
• トーン崩壊：応答の調子が急に変化し、過度に断定的、攻撃的、あるいは不自然に軽い表現になる。
• ハルシネーション：実在しない仕様、挙動、制約を事実のように提示する（複数条件が重なった場面で発生しやすい）。

理由は「利用形態」と「検知設計」にある

• 破綻は部分的に起きる：全体はそれっぽく見えるため、翌日レビューで初めて気づく。
• 同時並行をしていない：単一タスク・単一言語・短文プロンプトでは限界に触れない。
• 構造として見ていない：「AIが悪い」「もう一回」で終わり、原因・再発条件が整理されない。

破綻が起きやすい条件

• Java生成
• API生成
• 複数言語
• 同一セッション
• 並行進行（設計・実装・検証の同時進行）

体感的には破綻率は90%以上に達する。これはモデルの欠陥というより、同時並行前提で設計されていないことによる構造問題である。

「翌日になって初めて気づく」

明日までに、20ページ規模のPPT企画書や設計書を一度に生成して提出する。
翌日になって初めて、文脈のズレ／論理破綻／前提不整合に気づく。
しかし「どこで壊れたか」は分からず、対策も用意されないまま次の依頼が投げ込まれる。

未整備のまま放置されがちな4点

• 前兆の検知（Yellow Stateの扱い）
• 再発条件の整理（作業密度・並行条件）
• 分割設計（分割入力・分割検証）
• フォールバック（モデル・手順・成果物の退避）