目次を表示する

AI エージェントを動かし続ける ─ 運用工学の地図

プロローグ ─ 動くものから動き続けるものへ

プロローグ ─ 動くものから動き続けるものへ

第1部 で 6 レイヤの技術スタックを渡し、第2部 で 8 パターン × 6 トポロジー × HITL 設計でその並べ方を整理した。これでエージェントは動くようになった。

だが、動くことと、動き続けることの間には、もう一段壁がある。

「動いている」と「動き続ける」の違い

業務エージェントを 6 ヶ月以上本番運用すると、必ず次のような出来事に遭遇する：

事例 1：$47,000 の暴走（2025-11） 4 エージェント構成（market research pipeline、LangChain + A2A）のうち、Analyzer と Verifier の 2 体が「お互いの出力を待つ」状態でハンドシェイクを失敗。11 日間（264 時間）、人間に気づかれずに loop を続け、$47,000 のトークンを焼いた。budget ceiling が無く、alert は出ていたが kill switch がなかった（Tech Startups 2025-11-14）。

事例 2：retry ループでの数百ドル級事故（業界で複数報告） document summarize agent が深夜に retry loop に入り、朝まで同じツールを数千回呼び続け、1 日で数百ドル分のトークンを焼く。MCP server が一時的にダウンし、retry policy が指数バックオフで延々続いたパターン。alert は鳴ったが enforcement がなく、出社して気づいた時には手遅れ（業界 blog で複数の類似事例が報告されている。[要検証 具体的な「$437」の固有事例の一次ソースは再特定できず]）。

事例 3：Anthropic prompt cache TTL silent regression（2026-03） Anthropic が prompt cache の default TTL を 1 時間 → 5 分に silent に下げた。気づかないユーザーが多く、GitHub issue #46829 の解析では 3 月単月で 25.9% コスト増、Opus で $1,581 / Sonnet で $949 の overpay。alert があっても、原因がプロバイダ側のサイレント変更だと特定するまでに時間がかかった。

事例 4：Memory poisoning 50+ 件（Microsoft 観測、2026-02） 60 日間で 31 社・12+ 業界（finance / health / legal / SaaS / marketing 等）に渡り、50+ 件の unique prompts で memory 操作キャンペーンを観測。「Summarize with AI」ボタンの URL に “remember” / “trusted source” / “authoritative” 等のキーワードを仕込み、エージェントの長期メモリに偽事実を植え付ける手法（Microsoft Security Blog 2026-02-10）。

これらは設計の良し悪しと別の問題だ。第1部・第2部で示した「正しい部品 + 正しい形」を組んでも、運用フェーズで新しい現象が次々起きる。

運用フェーズで初めて見える「6 つの壁」

業務エージェントを動かし続けようとすると、次の 6 つの壁が必ず立ち上がる。

mindmap
  root((動かし続ける<br/>ための 6 壁))
    Drift
      モデル退役
      Prompt 退行
      データ分布変化
    Cost runaway
      無限 retry ループ
      Cache TTL 退行
      長コンテキスト罠
    Memory poisoning
      Indirect prompt injection
      Sibling task 漏れ
      Hallucination の self-feed
    Tool failure
      MCP server outage
      API rate limit cascade
      Circuit breaker 不在
    HITL bottleneck
      承認疲れ
      Rubber-stamp 化
      Queue overflow
    Incident response
      Runbook 不在
      On-call 体制不明
      Audit log の欠落

これら 6 つの壁は、「動いていた」エージェントを徐々に / 突発的に壊す。各壁を解くのが本作の目標だ。

壁症状本作の章
Drift評価指標が突然落ちる、応答品質が時間経過で劣化ch3
Cost runaway月末にコストが想定の 5×ch4
Memory poisoning「先週言ったこと」を覚えていない / 偽事実を信じているch5
Tool failureMCP / API ダウンで全停止ch6
HITL bottleneck承認 queue 200 件溜まり、業務側が全部 yesch7
Incident response障害が起きるたび「誰も止め方を知らない」ch9

これらに横串で乗るのが SRE 視点の SLO / SLI 設計（ch2） と Continuous evaluation（ch8） だ。

「業務に投入する」とは「運用責任を取る」こと

第1部 ch1 で「業務投入の 4 条件」を提示した：再現可能 / 耐故障 / 観測可能 / 管理可能。本作では、これに 「運用可能」 を加える。

運用可能：壊れたときに復旧でき、変更したときに検証でき、長期で品質が劣化しない

この 1 条件を加えると、業務投入は「動かす」から「動かし続ける責任を取る」へと意味が変わる。「何かあったら誰が出社するか」「3 ヶ月後にも同じ品質で動くか」「プロバイダがモデルを退役したら何が起きるか」── これらに答えられるエージェントだけが、業務に乗せられる。

なぜ 2026-05 が運用工学を語るタイミングか

2025 年は AI エージェントの 誕生の年だった。2026 年前半は、初期の暴走と事故が表面化し始めた時期だ。

  • Anthropic Sonnet 4 / Opus 4 の 2026-06-15 retire：API でピン留めしているプロダクションが、6/15 以降エラーを返し始める典型的な締切
  • MCP の大型インシデント：MCPwn (CVE-2026-33032, CVSS 9.8) で 2,600+ 公開インスタンスが影響、MCPwnfluence (CVE-2026-27825/27826) で Atlassian MCP に SSRF + arbitrary file write の RCE chain
  • Endor Labs の 2,614 MCP 実装解析で 82% が path traversal リスクあり
  • EU AI Act 2026-08-02 enforce：healthcare / credit / employment / critical infrastructure で監査ログが法的義務に
  • Anthropic Project Glasswingで Mythos Preview が限定配布（サイバーセキュリティ能力で突出、汎用モデル）

つまり、運用の壁が現実問題として顕在化した直後が今だ。これより前は議論が早すぎ、これより後は新しい事例で混乱する。この瞬間に、運用工学を整理する価値がある。

本作で扱う言葉の整理

混乱を避けるため、本作で使う用語を 4 つだけ揃える。

「Drift」：エージェントの挙動が時間経過で変化する現象。モデル / プロンプト / データの 3 種類。

「Runaway」：意図しない暴走。retry ループ、loop ハンドシェイク失敗、コスト破裂など。

「Poisoning」：エージェントの長期メモリ / コンテキストに、攻撃または偶発で偽の事実が植え付けられる現象。

「Cascading failure」：1 つの外部依存（MCP server / API / DB）の失敗が、retry を通じて他のエージェントに連鎖する現象。

これらは個別で見ると別の問題だが、根因は共通だ：「エージェントは確率的に動く + 長時間 + 外部依存の総合体」。これに対応するのが本作の運用工学。

運用工学を学ぶ 3 つの原則

第3部全体を通じて、3 つの原則を繰り返し参照する。

原則 1：alert ではなく enforcement

何かを「警告する」だけでは止まらない。実際にプロセスを kill する仕組みが必要。Token budget / Time budget / Round-trip count をすべて hard cap として実装。

原則 2：継続的に検証する（continuous evaluation）

「テストが通った」だけでは production の品質は分からない。production traffic を 5-10% サンプリングして毎日 eval。閾値を下回ったら deploy block。

原則 3：Runbook 化された対応

「Agent が暴走している」「メモリが汚染されている」を 5 分で止められる手順書を持つ。on-call の引き継ぎを言語化する。

これら 3 原則は、ch2 以降のすべての章に通底する。

本作の読み方

ch2 で SRE の枠組みを設定する。それ以降の各章は、6 つの壁を順に深掘りする。

  • 「先に SRE 観点を確立したい」人は ch2 だけで運用思想が掴める
  • 「特定の壁で詰まっている」人は症状から逆引きして該当章だけ読む
  • 「通しで運用責任を引き受ける覚悟をする」人は ch1 → ch10 の順に読む

各章は独立して読める。ただし ch2 → ch3-9 → ch10 の依存関係は緩く保証する。

それでは、ch2 で **「SRE for AI agents」**の枠組みを作るところから始めよう。

この章のまとめ

  • 「動く」と「動き続ける」の間にもう一段の壁がある：$47,000 暴走、cache TTL 退行、50 件の memory poisoning が実例
  • 6 つの運用の壁：Drift / Cost runaway / Memory poisoning / Tool failure / HITL bottleneck / Incident response
  • 業務投入の 4 条件 + 「運用可能」：「壊れたときに復旧でき、変更したときに検証でき、長期で劣化しない」
  • 2026-05 は運用工学を整理する適切なタイミング：Sonnet 4 retire、MCP CVE、EU AI Act が現実問題に
  • 3 原則：alert でなく enforcement / continuous evaluation / Runbook 化された対応