AIエージェント時代におけるAWS運用代行の価値とは?責任の所在の在り方を再考する

![]() |
こんにちは、白鳥です。 |
|---|
先月はMCPのビジネス利用に関するお話をしましたが、今回は技術のお話です。プログラミングやソフトウェア開発だけではなく、AWS環境の構築や運用においても、AIエージェントを使う作業が増えてきました。KiroなどのコーディングエージェントにCloudFormationやTerraformなどのIaCテンプレートの作成を任せたり、障害調査を行い次のアクションを決めたりすることができます。一方で、そんなAIエージェントの時代にAWS環境の運用代行の価値とはどのようなものがあるか、現在のAIエージェントの在り方を踏まえて解説してみたいと思います。
想定する読者
- AWS環境の運用設計を検討している方
- AIエージェントを使ってAWS環境の運用を効率化させようと考えている方
AIエージェントによる運用の半自動化・実行の現在地
AIエージェントによる対応が可能な領域は日進月歩で進んでおり、AWS環境の開発・運用においても例外ではありません。AWS純正の運用AIエージェントである、AWS DevOps Agentは許可したAWSアカウントの範囲において、障害の検知、調査、原因特定、対処案の提示を行ってくれます。2026年8月には「Directed Actions(日本語ではエージェントアクション)」という機能により、対処の実行までをDevOps Agentが担ってくれるようになりました。
Directed Actionsはデフォルトでは無効で、エージェントスペースでの有効化、専用のIAMロールの付与、および個々のアクションへの承認を行うことでAWSアカウントの操作実行が可能となります。また、AWS CloudTrailにより実行の証跡を残すことができます。
一方、AWS純正ではない汎用のAIエージェントであるClaude Codeでも調査やコマンド実行の提案を行うことができます。デフォルトでは読み取り関係の操作は承認不要ですが、シェルコマンドの実行やファイルの編集・書き込みには承認が必要です。すべての承認を不要とする「bypassPermissions」というモードも用意されていますが、これも「Only use this mode in isolated environments like containers or VMs where Claude Code can’t cause damage.」(訳:このモードはコンテナやVMのようなClaude Codeが損害を与えることのない独立した環境でのみ使用してください)とあるように、リスクの伴う設定として記述されています。(https://code.claude.com/docs/en/permissions)
このように、今日の多くのAIエージェントは「診断・提案は自動化するが、実際の変更は人間の承認を前提とする」という設計思想を採っています。

(AWS DevOps Agentのアラーム調査結果の例)
AIによる操作実行における責任の所在
では、AIによる操作実行の責任の所在はどこにあるのでしょうか?総務省・経済産業省のAI事業者ガイドライン(https://www.soumu.go.jp/main_content/001064279.pdf)によると、このような項目が書かれています。
- データの出所、AI システム・サービスの開発・提供・利用中に行われた意思決定等について、技術的に可能かつ合理的な範囲で追跡・遡求が可能な状態を確保する
- 各主体においてアカウンタビリティを果たす責任者を設定する
この2点からAIエージェントが実行した行為については、責任者たる人間が説明責任を果たす必要があるということになります。
また、AWSやMicrosoftといった大手のIT企業においても、説明責任についてこのような原則を持っております。
AWS:AI システムの動作をモニタリングおよび制御するメカニズムを備える
(参照:https://aws.amazon.com/jp/ai/responsible-ai/)
Microsoft:人は AI システムに対して責任を負うべきです
(参照:https://www.microsoft.com/ja-jp/ai/responsible-ai)
したがって、AIにAWSの運用を任せたとしても、最終承認・実行責任は人間のままになります。「AIがこう言ったから/推奨したから」ということを鵜呑みにせず、人間が説明可能な範囲に限って承認をしたり、不明点はAIに意図を確認したり、AIが意図しない動作を行った際の是正の仕組みを人間側で整えたりする必要があります。
仮に将来さらにAIによる自動化が進んでも、その機能を有効化するか・どの範囲まで任せるかを決める判断も引き続き行っていくようになり、そうなった場合人間が行う運用作業はAWSの運用からAIエージェントの運用に変わってきます。
実際に前項で挙げたDevOps AgentのDirected Actionsも、操作ごとの承認や権限の付与、証跡の記録を必須にしており「その操作が正しいか」という判断を都度行う必要があります。

※Directed Actions(エージェントアクション)を有効にしようとすると注意書きが出る
AWS環境の運用における経験値の重要性
仮にAIエージェントにアラームの原因調査を依頼しても、その正しさ、複数の選択肢からの判断は人間側で行う必要があり、それにはシステムごとの構成や、過去の障害傾向・業務における承認ルールが必要となります。いわゆる「コンテキスト」という経験に基づく文脈の理解です。汎用のAIエージェントはこのコンテキストを持たず、もし汎用のAIエージェントを使っていく場合は、コンテキストの補強を行っていく必要があります。AIに対する教育コストをかけることになります。AWSの運用からAIエージェントの運用に変わった場合は、こうしたAIエージェントの教育方法に稼働がシフトしますが、その場合はAWSの基盤運用について人間側が熟知している必要があります。
AWSの運用ノウハウから内製でコンテキストをゼロから獲得するには、さまざまな障害事例に対する調査コストを要した経験が必要となり、いわゆるIT企業でない企業・団体では本業以外の部分にコストと時間を割くことになります。情報システムを安定的に利用したいだけなのに、AWSの詳細な知識獲得や、他社の障害事例や、障害の切り分け手順といった「差別化にならない労働」に時間を割くことは本質的ではありません。こうした共通的な部分は他社事例も含めた経験値を持つAWSの運用代行事業者に任せてしまうのも一つの選択肢となります。当社のようなAWSを使ったシステム構築を行う事業者においても、なるべくマネージドサービスを活用してインフラを意識せずに価値提供に集中するようにしており、AWSとお客さまの間を取り持てるようなサービスを意識して運用代行サービスを提供しております。
運用作業における”速さ”と”正確さ”の両立
AIエージェントに調査を依頼すると非常に大量の情報を瞬時に調査し、場合によっては人間の熟練したオペレーターより早く解決案を提示してくれます。繰り返しになりますが、調査結果の正確さは人間が判断することになりますが、経験が浅い場合AIの提案に対しての判断や事実関係の再調査に迷うことで、むしろ対応完了までの時間が長くなるリスクを秘めております。
一方で経験豊富な運用代行チームであれば、過去の経験値やナレッジから予測を行い、AIからの提案を正しく評価し、実行までを行うことが可能です。また、「なぜその判断を行ったか」という点においても、AIへのコンテキスト追加を必要とせずに説明することも可能です。「速さ」と「正確さ」を両立できるのは、システムの状態を正しく検証し、責任を持って承認できる経験と体制があってこそ、となります。この経験と体制をいかにして効率的に整えるかという観点で、AWSの運用代行を検討されるのが良いかと思います。
まとめ
AIエージェントの活用が進んだとしても、システム運用における責任と最終判断は人間に残ります。
また、AIによって調査や実行の効率が向上したとしても、その結果を適切に評価し、安定運用につなげるためには経験に裏付けられた知見と運用体制が不可欠です。
AI時代において求められるのは、AIを適切に活用しながら責任ある運用を実現することではないでしょうか。
NTT東日本では、AWSの構築保守・運用代行だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供を行っております。
AI活用を見据えたAWS運用体制の構築をご検討中の方は、ぜひお気軽にご相談ください!
本コラムに記載されてる会社名、サービス名、商品名は、各社の商標または登録商標です。
RECOMMEND
その他のコラム
相談無料!プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。






