> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 第3章 · エージェント型インフラ運用とは何か

> 定義は重要だ。「エージェント」はエンタープライズソフトウェアで最も乱用されている言葉だから。実務的な定義、L0〜L4の自律スペクトラム、5つのベンダーテスト、そして今日実際にスコープに入るものを示す。

*定義は重要だ。なぜなら「エージェント」はエンタープライズソフトウェアで最も乱用されている言葉だからだ。*

## 3.1 実務的な定義

<Info>
  **定義**

  エージェント型インフラ運用（AgenticOps）とは、自律 AI エージェントが運用作業のコアループ — 状態の検出、原因の分析、問題の解決、アウトカムの検証 — を明示的な人間定義のポリシーのもとでクラウドおよびオンプレミスのインフラ全体にわたって実行し、人間がループの中で実行する代わりにループの上で監督する運用モデルである。
</Info>

定義を紐解くと、この意味でのエージェントはランブックを持つチャットボットではなく、LLM をボルトオンしたスクリプトでもない。真の運用エージェントには5つの特性がある。

1. **ゴール指向。** ステップバイステップの指示ではなく、アウトカムを与えられる（「チェックアウトレイテンシを300ms以下に保つ」「月次クラウド支出を予算内に保つ」）。

2. **知覚的。** プロンプトを待つのではなく、継続的にテレメトリー — メトリクス、ログ、トレース、イベント、設定状態、コストデータ — を消費する。

3. **推論的。** 因果仮説を形成してテストし、代替の修復方法を比較検討し、エンジニアが監査できる言語でその思考を説明する。

4. **ツール使用可能。** エンジニアが使う同じインターフェース — クラウド API、kubectl、Terraform、SQL、CI/CD — を通じて、スコープが限定された監査可能なクレデンシャルで行動する。

5. **自己検証型。** 行動した後、意図したアウトカムが達成されたかを確認し、達成されなかった場合はエスカレーションまたはロールバックする。

## 3.2 自律スペクトラム

自律性は二値ではない。成熟したエージェントプラットフォームは、通常アクションクラスと環境ごとに、ポリシーダイヤルとして自律性を公開する。

| レベル | 名称      | エージェントの動作                       | 人間の役割               |
| :-- | :------ | :------------------------------ | :------------------ |
| L0  | 観察      | 監視して報告する。行動しない                  | すべてを実行する            |
| L1  | 助言      | 証拠とともに調査して推奨する                  | 判断して実行する            |
| L2  | 承認付き行動  | 完全な修復を準備して承認を待つ                 | ワンクリックで承認/拒否        |
| L3  | 通知付き行動  | 事前承認されたアクションクラスを実行して人間に通知する     | 事後にレビューする           |
| L4  | ドメイン内自律 | ポリシー内でバウンドされたドメインをエンドツーエンドで所有する | ポリシーを設定し、アウトカムを監査する |

実際には、組織は異なるレベルを同時に実行する。可逆的で爆発半径の小さいアクション（ポッドの再起動、キャッシュのクリア、レプリカセットのスケール、クレデンシャルのローテーション）には L3〜L4、重大な変更（スキーママイグレーション、セキュリティグループの変更、フェイルオーバー）には L2、新規の事項には L1。エージェント運用の技術は、証拠が積み重なるにつれてアクションクラスをラダーの上に移動させることだ — 決して速すぎることなく。

<Info>
  **ビッグテックの実践：スペクトラムは今や製品の現実**

  L0〜L4 スペクトラムは理論的な構成概念ではない。ハイパースケーラーが出荷する方法だ。Google の Gemini Cloud Assist プロアクティブ調査は、明示的な設計によって L1 で実行される（すべてを調査し、何も変更しない）。AWS 自身の DevOps エージェントの採用ガイダンスは、推奨のみのモードで開始し、アクションを付与する前に数週間計測することだ。Azure SRE エージェントはダイヤルを直接公開する。すべてのアクションが「承認」クリックを待つ Review モードと、ツールごとにガバナンスされた事前承認済みアクションクラスのための特権モード。3つのクラウドが独立して同じ段階的自律ポスチャーに収束する場合、それはエージェントが最初にどれだけの信頼から始まるかについての業界の集合的な答えだ。ゼロから始め、信頼を勝ち取る。
</Info>

> *図3 — 自律ダイヤル：アクションクラスは環境ごとに証拠に基づいて L0 から L4 へと進む。*

## 3.3 エージェント運用ではないもの

「エージェントウォッシング」は今や Gartner が名前を付けるほど一般的になった。ベンダーがアシスタント、チャットボット、RPA を意味あるエージェント機能なしに「エージェント」としてリブランドしている。2025年半ばに Gartner は、エージェント型 AI を主張するベンダー数千社のうち、本物はわずか約130社だと推定した。正確な否定的定義が、したがって購買者の最善の防御だ。

1. **ダッシュボード上のチャットボットではない。** テレメトリーへの会話型アクセスは機能であって、モデルではない。人間が答えを読んで作業に行く必要があるなら、あなたはまだ第3世代にいる — マーケティングが何を言おうとも。

2. **無人運用ではない。** 信頼できる実務家は誰も人間を排除することを主張しない。目標は人間のレバレッジだ。かつてチームを必要としていた作業を1人のエンジニアが監督する。

3. **エンジニアリング規律の代替ではない。** エージェントは与えられた環境を増幅する。弱いオブザーバビリティ、IaC の不在、ドキュメントのないシステムは弱いエージェントを生む。コンテキストがゴミなら、自律性もゴミだ。

4. **すべてをこなす1つの巨大なモデルではない。** 次の章が示すように、本番システムはモノリシックなスーパーモデルではなく、オーケストレートされたスペシャリストチームに収束している。

<Warning>
  **5つのベンダーテスト**

  「エージェント型」ベンダーに質問すること：

  1. システムは修復をエンドツーエンドで実行できるか、推奨だけか？
  2. 自らのアウトカムを検証し、失敗時にロールバックするか？
  3. アクションクラスと環境ごとに自律性を設定できるか？
  4. すべてのアクションに完全かつ改ざん不可能な推論トレイルがあるか？
  5. 直近3回の本番デプロイでのロールバック率と介入率はどれくらいか？

  本物のプラットフォームはすべての5問に証拠をもって答える。エージェントウォッシングは2問目で失敗する。
</Warning>

## 3.4 エージェントが今日所有できる運用作業のスコープ

| ドメイン                   | 代表的なエージェントタスク                                 | 典型的な自律性（2026年） |
| :--------------------- | :-------------------------------------------- | :------------- |
| インシデント対応               | トリアージ、相関、根本原因分析、修復、インシデント後レポート                | L1〜L3          |
| クラウドコスト（FinOps）        | ライトサイジング、アイドルリソースのクリーンアップ、コミットメント計画、異常検出      | L2〜L4          |
| Kubernetes 運用          | ポッド/ノードのヘルス、リソースチューニング、アップグレード支援、キャパシティプランニング | L2〜L3          |
| データベース運用               | スロークエリ分析、インデックスアドバイス、レプリケーションヘルス、ストレージ予測      | L1〜L3          |
| セキュリティ運用               | 設定ミスの検出、CVE トリアージ、IAM 衛生管理、コンプライアンス証拠         | L1〜L2          |
| 変更・リリース                | デプロイ前リスク分析、カナリア監視、自動ロールバック                    | L2〜L3          |
| Infrastructure as Code | ドリフト検出、モジュール生成、プランレビュー、状態管理                   | L1〜L3          |
