> ## 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. # 第5章 · エージェントチーム：役割と責任 > エージェント組織の設計は組織設計そのものです。メンバー構成、作業の流れ、エージェントと人間のインターフェース、そして4つのプロダクション事例研究。 *エージェント組織の設計は組織設計そのものです。同じ問いが適用されます：誰が何を担い、誰が誰に報告し、どのように作業を引き継ぐか。* ## 5.1 コアメンバー構成 ほとんどのプロダクション環境は、小規模な名前付きエージェントチームに収束します。名前付けは聞こえる以上に重要です：安定したアイデンティティを持つ名前付きエージェントは、人間のチームメイトと同様に信頼、コンテキスト、説明責任を蓄積します — そして永続的なエージェントアイデンティティ自体が、この時期のプラットフォームトレンドの定義的な要素の1つです。代表的なメンバー構成： | 役割 | スコープ | 担当業務例 | | :--------------------- | :--------------------------- | :----------------------------------------------------- | | オーケストレーター / SuperAgent | 横断的 | ゴール分解、タスクルーティング、マルチドメインインシデント、人間へのエスカレーション、レポーティング | | クラウドエンジニアリングエージェント | AWS / Azure / GCP / ローカルクラウド | プロビジョニング問題、ネットワーキング、スケーリング、サービスクォータ、コスト異常、IaC drift | | セキュリティエージェント | AppSec + CloudSec | 設定ミス、OWASPクラスのアプリケーションリスク、CVEトリアージ、IAMの衛生管理、コンプライアンス証拠 | | データベースエージェント | データ層 | 遅いクエリ、ロック、レプリケーション遅延、インデックス戦略、ストレージ予測、バックアップ検証 | | Kubernetesエージェント | コンテナプラットフォーム | Podクラッシュループ、OOMキル、ノードプレッシャー、HPAチューニング、アップグレード準備 | コアメンバー構成に加えて、組織は特定のビジネスユニットのコスト最適化、主力アプリケーションのパフォーマンス、プラットフォームチームの生産性ワークフローなど、自社のニーズと目標に合わせたカスタムエージェントを追加します。カスタムエージェントはオーケストレーター主導のチームを拡張するものであり、モデルの代替ではなく、上位に追加するものです。 ## 5.2 作業がチームを流れる流れ方 02:40のプロダクションインシデントを例に考えましょう：チェックアウトのレイテンシーがSLOを超過しました。 1. **Detect。** センシングレイヤーが、レイテンシーアラート、データベース接続エラーのスパイク、22分前にデプロイされたリリースを1つのインシデントに関連付け、41件のダウンストリームアラートを抑制します。 2. **Analyze。** オーケストレーターがデータベースとKubernetesスペシャリストを並行して起動します。データベースエージェントは新しいN+1クエリパターンによって引き起こされたコネクションプール枯渇を発見し、Kubernetesエージェントはポッドが正常であることを確認してインフラを除外します。オーケストレーターは両方の結果を統合して証拠付きの根本原因仮説を作成します：新しいデプロイがクエリパターンを導入した。 3. **Resolve。** ポリシーにより、SLO違反時に60分未満のデプロイを自動ロールバックすることが許可されています。オーケストレーターはロールバック（L3事前承認済みアクション）を実行し、完全な推論チェーンをインシデントチャンネルに投稿し、誰にも通知しません。 4. **Validate。** レイテンシーは4分以内にベースラインに戻り、エラーレートがクリアになります。システムはSLO回復を確認し、特定されたクエリを含む問題チケットをエンジニアリングチームに作成し、インシデント後レポートを下書きし、パターンをメモリに保存します。 経過時間：10分未満、人間の対応ゼロ。翌朝、エンジニアがレポートを確認し、クエリを修正し、再デプロイを承認します。この分業 — 機械が02:40の機械的な処理を担い、人間が09:00に工学的な判断を担う — が、モデルが意図通りに機能している姿です。 > *図5 — 同じインシデント、2つの運用モデル：数時間に及ぶ人間の対応と10分未満のクローズドループの比較。* ## 5.3 エージェントと人間のインターフェース エージェントはエンジニアが生活している場所に存在します。支配的なインターフェースパターンは「会話＋証拠」です：エージェントはSlackやTeamsに、完全な推論チェーン、証拠へのリンク、ワンクリックの承認/却下アクションとともに、調査結果、計画、承認要求を投稿します。ダッシュボードはトレンドと監査のために使われ、運用上の会話はチャットで行われます。2つのインターフェースルールが特に重要です： 1. **作業過程を示す。** すべての結論は、検討されたデータ、考慮された仮説、代替案が却下された理由とともに提供されます。透明な推論は、エンジニアの信頼を最も大きく高める要素であり、AIOpsを沈没させたブラックボックスの失敗への解毒剤です。 2. **承認を容易に、却下を情報豊かに。** 承認はフルコンテキストでのワンクリックであるべきです。却下は理由を記録すべきです。なぜなら、すべての却下がポリシーチューニングのためのトレーニングシグナルになるからです。 ## 5.4 証拠：壁にぶつかった4つのチーム この章に登場するすべてのチームが同じ壁にぶつかりました：インフラは成長し続け、オペレーターは増え続け、あらゆるインシデントの時計は動かなかった。そのうちの4つが対策を講じました。マルチアカウントAWSに溺れる貸金業者。1秒のダウンタイムも許せない決済プラットフォーム。3つのコンプライアンス体制に同時に向き合うグローバルSaaS。数千のクラスターを手動で運用する国内大手通信会社。規模は異なれど、同じ物語 — そしてそれぞれで、エージェント運用が結末を変えました。自分たちに似たチームを探してください。顧客は匿名化されています。数字は実際のものであり、すべて出発点との比較で測定されています — 約束ではなく、実績です。 ### 1. ベトナムの大手消費者金融貸金業者 800以上の支店と数百万の顧客を持つ貸金業者を想像してください。AWSの資産が非常に多くのアカウントにわたって成長したため、全体像を一度に把握できる人間がいませんでした。急成長が運用担当者のキャパシティを超えていました。コストとインシデント管理は手動で、可視性はアカウントをまたいで断片化しており、融資に不可欠なアプリが不調をきたした際には、原因特定に数時間のクロスアカウント調査が必要でした — その間、融資は実行できません。チームには多くのダッシュボードは必要ありませんでした。既存のダッシュボードが示していることに対応できるものが必要だったのです。4週間の測定ベースライン期間中、エージェントチームはL1から開始し、すべてのアカウントをまたいで調査し、根本原因分析をオペレーターと照合して検証しました。分析が信頼を得るにつれ、L2へと昇格 — コストと衛生管理のアクションに対してワンクリック承認用の完全な修正を準備 — しながら、コアとなる融資パスは全期間を通じてアドバイザリーに留まりました。3ヶ月以内に結果は明確でした：手動の運用作業が約80%減少し、根本原因の特定が数時間から数分に短縮され、最適化可能なAWS支出の約30%が回収され、重要なアプリが24時間365日監視されるようになりました。チームが得た教訓は、この本が繰り返し立ち返るものと同じです：勝利は最もリスクの高いパスへの自律性からではなく、希少なエンジニアから大量かつリスクの低い雑務を取り除くことで、彼らが本当に重要なことを監督できるようになったことから生まれました。 ### 2. ベトナムの急成長デジタル決済プラットフォーム シリーズAの決済会社は、プラットフォームチームを眠れなくさせる問題に直面していました：3つのプロダクションKubernetesクラスターのバージョンアップグレードが必要でした。決済においてダウンタイムは許容できません — 1分の障害は1件の未決済トランザクションを意味します。加えてRDSレプリカのコストが増加しており、決済に不可欠なアプリへの監視はリスクに見合わないほど薄い状況でした。エージェントチームには、アクションが可逆的で十分に理解されている場面 — KubernetesライフサイクルとライトサイジングにおけるL2-L3、事前承認済みアクションクラスでのセルフヒーリングとレプリカスケーリング — でより高いレベルの自律性が付与され、移行の不可逆的なステップは人間の承認を維持しました。アップグレードは3つのすべてのクラスターでカスタマーに見えるダウンタイムゼロで完了しました。3ヶ月以内にレプリカコストが約半分に削減され、月次の実行コストの約30%が最適化され、すべて継続的なモニタリング下で実現しました。チームが得た教訓は、自律性がどこに属すかについての指摘でした：エージェントはアクションが取り消しおよび検証可能な場所でこそ最も速く動き、「不可能」と思われた1ヶ月のアップグレードが、リスクの高い不可逆なアクションを人間がゲートしたからこそルーティンになりました。 ### 3. グローバルAI / SaaSプラットフォーム（米国・EU・APAC） あるグローバルAIプラットフォームは、コンプライアンス問題の形をしたデッドライン問題を抱えていました。投資家はSOC 2とHIPAAの準備を求め、フットプリントはGDPRのもとで3地域にまたがり、運用オーバーヘッドは爆発し、99.9%の可用性目標がすべてに覆い被さっていました — 通常、監査準備だけでシニアエンジニアの時間の四半期を消費するような多方面からのプレッシャーです。ここではエージェントをコンプライアンス負担そのものに向けました：コンプライアンスガードレールのL2自動化と、コストおよび運用のKeepersを通じたL2-L3の運用改善、そして事後の再構築ではなく実際の作業が行われる際にリアルタイムでコンプライアンス関連のすべてのステップをログ記録。グローバル3地域のデプロイメントが4週間で整い、SOC 2、HIPAA、GDPRの準備が3週間で完了し、運用タスクの負荷が約80%減少し、99.9%の稼働率が達成・検証されました。チームのための教訓はコンプライアンスを再定義しました：作業を行うシステムによって証拠の証跡が継続的に生成される場合、監査準備は定期的な慌ただしい作業ではなく、インフラの運用方法の一特性となります。 ### 4. ベトナムのTier-1テレコムクラウドプロバイダー（メガスケール） 今度は問題全体を国のレベルにスケールアップしましょう。Tier-1のテレコムクラウドオペレーターは、複数のデータセンターにわたって数千規模のコンピュートクラスターを運用しており、そのスケールに対応する方法は1つしかありませんでした：人手です。数百人のオペレーターが、ルーティンの健全性チェックを実行し、構成やパッチのドリフトを追いかけ、規制を受ける国家インフラプロバイダーの監査証拠を作成することで日々の運用を手作業で行っていました — それでもツール数と人員が増えるにつれて平均修復時間は横ばいのままでした。これは第1章の調整コストが国家スケールで書かれたものです：瓶頸はキャパシティではなかったため、人手を増やしても数字は動きませんでした。エンゲージメントは、異質なOpenStackとVMwareの資産にわたって意図的に自律性を段階的に導入しています。まず構成管理と監査/コンプライアンス自動化を中心に。エージェントチームはフリート全体でのL1調査から開始し、ルーティンのクラスターヘルスとドリフトアクションに対してL2承認済み修正へと昇格し、次にクラスター再起動、容量調整、証明書ローテーションなど最も安全で最も繰り返されるクラスでL3通知後実行へ — ただし規制を受けるコントロールパスは全期間を通じて人間が承認し、すべてのアクションに国家インフラ監査に対応するサイズの不変の証跡を付与。4週間以上の測定ウィンドウで現在積極的に構築・測定中のこのエンゲージメントの目標は、L1/L2の定型的なオペレーター作業の大部分を吸収して希少なオペレーターを実行から監督へ移行させ、定期的な手動監査準備を継続的なマシン収集証拠に置き換え、最終的にMTTRをフリートサイズから切り離すことです。本書自身のエビデンスルールに従い、数字は測定ウィンドウが終了した後に公開されます — この事例はそれが答えている問題の形のためにここに含まれています：頭数でオペレーションをスケールすることが単純に機能しなくなる時点。 本書の対象読者への正直な注意事項。これら4つのいずれも、中央銀行の監督体制のもとでコアバンキングシステムを運用するTier-1商業銀行ではありません。そのような機関の読者は、これらを消費者金融、決済、規制されたグローバルSaaS、国家テレコムクラウドインフラという強力な隣接証拠として読むべきです — コアバンキングの直接的な参照としてではありません。この特定のギャップを埋めることは、規制された銀行の視点から書かれた、まだ開発中の別の規制銀行版の主題です。実際の前後ベースラインを持つ規制銀行の事例をここに公開できるまで、本書はそれを主張しません。 **大手テクノロジー企業の実践：コンソールではなくチームメイトとしてのエージェント** 3つのクラウドすべてが、新しいダッシュボードではなく、チームメイトモデルを実装しました。AWS DevOps AgentはSlackとServiceNow内で動作し、CloudWatchまたはPagerDutyアラームから自動的に調査を起動し、重複チケットを関連付けてノイズをソースで抑制し、チームが独自のランブックを再利用可能な「スキル」としてエンコードできるようにします。Azure SRE Agentはカスタムサブエージェントをサポートしており、組織は独自のスペシャリストでコアチームを拡張でき、ServiceNow、PagerDuty、GitHubへの組み込みおよびカスタムMCPサーバーを通じて外部接続します。あらゆるデプロイメントのための共通の教訓：エンジニアがすでに使っているツールで対応し、すべての調査結果に完全な推論を示し、ランブック、慣行、障害パターンなどの組織的知識をエージェントが自動的に適用するファーストクラスの入力とすること。