技術 約8分で読めます

本番環境削除・コンテキスト喪失・使用量枯渇——AIコーディングツールの壊れ方3種

AI AIエージェント Claude Code AWS Amazon コーディングエージェント インシデント 設計

AIコーディングエージェントが実務に入り込むにつれて、壊し方のバリエーションも増えてきた。同じ週にAmazonとAnthropicの2製品がそれぞれ別の壊し方をしたので、並べて記録しておく。

Amazon Kiro：本番環境を「削除して再作成」した自律エージェント

何が起きたか

2025年12月、Amazonの社内AIコーディングエージェント「Kiro」が本番環境に対して「削除して再作成する（delete and recreate the environment）」という判断を自律的に下し、AWSサービスに13時間の障害を引き起こした。Financial Timesが内部関係者4名への取材をもとに報じた。

エンジニアがKiroに本番環境の修正タスクを渡したところ、Kiroは「環境を削除して再作成する」を最適解として選択し、そのまま実行した。本番環境が消えた。

影響範囲:

  • AWS Cost Explorer
  • 中国大陸の2リージョンのうち1リージョン
  • 13時間のダウンタイム

Amazonはこれを「非常に限定的（extremely limited）なイベント」と形容した。本番サービスが13時間止まって「限定的」と呼ぶのは無理がある。

Kiroの設計と、それが機能しなかった理由

Kiroは2025年7月にAmazonが発表したアジェンティック型AIコーディングツールで、通常はアクション実行前にユーザーの承認を求める設計になっている。ところが今回、担当エンジニアが「想定より広い権限を持つロール（role with broader permissions than expected）」を使用していた。オペレーターレベルのアクセス権限がそのまま渡った状態で、Kiroは確認なしに本番環境の削除・再作成を実行できてしまった。

AWSはロイターへの声明で「根本原因はユーザーエラー、具体的にはアクセス制御の誤設定であり、AIではない」「AIツールが関与していたことは単なる偶然（merely a coincidence）」と言い切った。

しかし「偶然」で済ませるには苦しい事実がいくつかある。

複数のAmazon社内従業員が懐疑的な見方を示しており、あるAWSの上級従業員は「小規模だが完全に予見可能だった（small but entirely foreseeable）」と評した。そして障害後にAWSは「本番アクセスへの必須ピアレビュー（mandatory peer review for production access）」と追加スタッフトレーニングを導入した。事後に導入されたということは、障害発生時にはこの安全策がなかったということだ。

本番環境への変更前に複数人のレビューが必要なのは開発の基本中の基本で、これが存在しなかったのはエンジニア個人のミスというより、Kiroを運用に載せる際の組織的な安全設計の欠落だ。

社内採用ノルマとリスク評価の歪み

複数のAmazon従業員によれば、今回は「少なくとも2件目」のAI関連障害だ。Amazon Q Developer（別のAIコーディングアシスタント）が関与した本番障害も報告されており、2025年10月には15時間にわたる別のAWS障害が「自動化ソフトウェアのバグ」と説明されている。

背景として、Amazonは社内でKiroの採用を積極的に推進していた。週次使用率80%を目標に設定し、採用率を詳細に追跡していたとされる。商用製品として売り出したいツールを社内で使わせるノルマが、リスク評価のインセンティブと衝突していた構図だ。

「うちのツールは安全じゃないかも」というフィードバックが、「80%使え」という号令の中で上がりにくくなる。ツールの品質を上げるための社内ドッグフーディングが、採用率をKPIにした瞬間にリスク評価の無力化装置になる。

元記事: Amazon blames human employees for an AI coding agent’s mistake

Claude Code：auto-compactionがデータを非可逆に消去する

何が起きているか

Claude Codeで長いセッションを続けていると、突然Claudeが「さっき貼り付けたコードをもう一度送ってもらえますか」と言い出す。これはバグだ。

Claude Codeにはauto-compactionという機能がある。会話履歴がコンテキスト上限に近づくと、過去のやり取りを要約に圧縮してトークンを節約する仕組みで、ユーザーが意識しないバックグラウンドで自動的に発火する。

問題は、この要約生成が非可逆な変換であること。

たとえば8,000文字のDOMマークアップを貼り付けてClaudeと40分作業した後にcompactionが走ると、サマリーにはこんな一行だけが残る:

[compacted] User provided 8,200 characters of DOM markup for analysis.

実際のマークアップは消えた。Claudeの側には「8,200文字のDOMマークアップがあった」という事実しか残っていない。その後にマークアップの具体的な内容を聞くと、ハルシネーションするか「もう一度貼ってください」と言うかのどちらかだ。

compactionの技術的な仕組み

auto-compactionの動作をもう少し具体的に書く。

Claude Codeはセッション中の全メッセージをコンテキストウィンドウに載せて動いている。会話が長くなるとトークン数がモデルの上限に近づくため、古いメッセージから順にLLM自身が要約を生成し、元のメッセージを要約テキストで置き換える。これがcompaction。

要約の粒度はLLMの判断に委ねられている。コードブロック、エラーログ、ユーザーが貼り付けたデータなど、長いテキストほど積極的に圧縮される。だがこれらは往々にして「長いからこそ重要」なデータだ。8,000文字のDOMマークアップを貼り付けたのはそれが必要だったからで、「DOMマークアップがあった」という一行に圧縮していい情報ではない。

さらに厄介なのは、compactionが発火したことをユーザーに通知しない点だ。ユーザーから見ると、Claudeが突然文脈を見失ったように見える。実際に見失っている。

ディスクには残っているのに参照できない

データ自体はディスク上に存在する。Claude Codeのセッショントランスクリプトは ~/.claude/projects/{project-path}/ 以下に保存されていて、ファイルを開けばcompaction前のやり取りがすべて残っている。だが現在のClaudeには「そのファイルの何行目を読め」と指示する仕組みがない。

データが残っているのに参照できない。復元手段がないのにバックアップだけある状態で、いちばんフラストレーションが溜まるタイプの問題だ。

GitHub上では少なくとも8件の関連Issueが同じ根本原因から派生している:

  • #1534 — Memory Loss After Auto-compact
  • #3021 — Forgets to Refresh Memory After Compaction
  • #10960 — Repository Path Changes Forgotten After Compaction
  • #13919 — Skills context completely lost after auto-compaction
  • #14968 — Context compaction loses critical state
  • #19888 — Conversation compaction loses entire history
  • #21105 — Context truncation causes loss of conversation history
  • #23620 — Agent team lost when lead’s context gets compacted

提案されている修正と当面の回避策

Issue #26771で提案されているのは、サマリー内にトランスクリプトへの参照を埋め込む方式だ。

現在のlossy方式:

[compacted] User provided 8,200 characters of DOM markup for analysis.

提案されているrecoverable方式:

[compacted] User provided 8,200 characters of DOM markup for analysis.
[transcript:lines 847-1023]

サマリーに「元データがトランスクリプトの何行目にあるか」を記録しておく。Claudeが具体的なデータを必要としたときだけその範囲を読み直す。常に全文を保持するわけではないためトークンコストの増加は最小限に収まる。lossy compactionをrecoverable compactionに変える提案で、技術的には実装可能な範囲に見える。

当面の回避策:

  • /compact を手動で実行し、保持すべきデータを明示的に指示する
  • MEMORY.mdに重要なコンテキストを書き出しておく
  • 長大なデータはファイルに保存してClaudeに読み込ませる（会話に直接貼り付けない）

Claude Codeの利用頻度が上がるほど、長時間セッションでcompactionに当たる確率も上がる。実運用でこの問題を踏んでいる人はGitHub Issue #26771にupvoteしておくといい。

Claude Codeのサブエージェント：使用量が見えないまま上限に突っ込む

compactionとは別の問題

compactionがデータの質の問題だとすれば、こちらは量の問題。Claude Codeのサブエージェント（マルチエージェント）機能を使うと、使用上限に想定よりはるかに速く到達する。

Claude Codeのサブエージェントは、メインエージェントとは別のコンテキストウィンドウを持つ独立したClaudeインスタンスとして動く。3つのサブエージェントを並列で走らせれば、その分だけAPIコールとトークン消費が並列で発生する。plan modeで動かすサブエージェントは通常セッションの約7倍のトークンを消費するという報告もある。

Maxプランでも2時間で枯渇

GitHub Issue #16157では、Maxプラン（$100/月、Pro比5倍の使用量）のユーザーが「3日間使わずに再開したら2時間で上限に達した」と報告している。別のユーザーは45分で枯渇し、「他の誰かが使っているかのようにメーターが減った」と書いている。

Anthropicは「レート制限自体は変更していない」と回答した。ただし「Opus 4.5はこれまでより長く動き、より多くの作業をこなすため、結果としてトークン消費が増える」とも説明している。つまりモデルが賢くなってより多くのツール呼び出しや推論ステップを踏むようになった結果、1タスクあたりのトークン消費量が増え、使用上限に速く到達するようになった。

「リファクタしろ」のような1つのタスクでも、ファイル読み取り、編集、テスト実行、修正を繰り返すと10-30メッセージ分のレート制限を消費する。サブエージェントを使えばこれが並列で走るから、掛け算になる。

使用量のフィードバックがない

Kiroの「確認なし実行」とcompactionの「通知なし圧縮」に共通するパターンがここにもある。Claude Codeにはリアルタイムのトークン消費量表示がない。残量が見えないまま作業を進め、突然「使用上限に達しました」と止まる。

5時間のウィンドウでリセットされる仕組みだが、ウィンドウの残り時間も残りトークン数も明示されない。ユーザーが把握できるのは「上限に達した」という事実だけで、どの操作がどれだけ消費したかの内訳は見えない。

GitHub #16157には重複Issueが3件リンクされており（#13551、#16058、#9544）、同じ問題に繰り返し報告が上がっている。