コード生成から「環境の掃除」へ。KiroのAgent Hooksで構築する自律型FinOps

はじめに

NTT西日本 1年目社員の野村です。 AWSのさまざまなサービスに触れ広範な技術知見を深める中で、現在は「生成AIをいかに実務の煩雑な運用に溶け込ませるか」をテーマに活動しています。

一般的に、KiroやCursorといった「AI IDE（統合開発環境）」は、アプリケーションコードを書くためのツールとして認識されています。しかし、その強力なAgent Hooks、Steering、および構成要素を組み合わせれば、IDEは単なるエディタを超え、強力な「インフラ運用コンソール」へと進化します。

本稿では、Kiroの主要機能をフル活用し、検証環境のコスト削減（FinOps）を「安全に・作成者まで特定して」自動化した手法を、実践的な観点から解説します。1年目社員がどのようにしてAIを「信頼できる相棒」に育て上げたのか、その全貌をご紹介します。

「FinOps」は、Finance（財務）の「Fin」とDevOps（Development「開発」とOperations「運用」を合成したIT用語）の「Ops」を組み合わせた造語です。

実装の核：Kiroを Ops Console に変える3つの力

1. Agent Hooks（発動） 自律監査や特定の運用タスクを開始するための「起動スイッチ」です。あらかじめ定義した定型プロンプトをAIに一括投入するトリガーとなり、複雑な調査ミッションをワンクリックで発動させます。

2. Steering（行動規範） 「勝手な削除の禁止」「Mermaid図解の必須化」などの絶対ルールを規定。AIにインフラエンジニアとしてのプロフェッショナリズムと「行動規範」を植え付け、暴走を防ぎます。これは、AIを「自動化ツール」から「信頼できるエージェント」へと変えるための核心的な設定です。

3. MCP（外部連携） aws-mcp-server を介して、AWSアカウント情報のリアルタイム取得やベストプラクティスの参照、自然言語からコマンドへの変換を実現します。外部の膨大な知識とAWS環境のメタデータを接続する、まさに知恵袋としての役割を果たします。

1. 課題：エンジニアを悩ませる「検証環境の滞留リソース」問題
2. コンセプト：IDE as an Ops Console
3. アーキテクチャ：Kiroを中心とした自律監査の全体像
4. 実装の三要素：Steering / Hooks / MCP の徹底解剖
・4.1 Agent Hooks：責任の所在を明確にした監査実行の詳細
・4.2 Steering：AIの行動を縛る「絶対ルール」の内部ロジック
・4.3 MCP：aws-mcp-server による動的な知識連携とガバナンス
5. 独自実装：CloudTrail連携による「作成者特定」の自動化ロジック
6. 実践：Human-in-the-Loop による安全な削除プロセスと運用のリアル
7. まとめ：AIを「コードを書くためだけ」に使うのはもったいない！

1. 課題：エンジニアを悩ませる「検証環境の滞留リソース」問題

AWSの認定資格取得を通じ、あらゆるアーキテクチャを学ぶ過程で、私は何百ものリソースを立ち上げ、検証してきました。しかし、その裏側で常に私を悩ませていたのが、「消し忘れリソースによるサイレントな課金」です。

「このEBS、いつから detached（未アタッチ）なんだ？」
「このElastic IP、誰が何のために確保した？」
「Lambdaの古いバージョンがストレージを圧迫しているが、消して大丈夫か？」

これらは単なるコストの問題だけではありません。「誰が作ったか不明」という状態は心理的な不安を呼び、結果として「念のため残しておく」という非効率な運用または「望ましくない運用」を招きます。私はこの課題を解決するため、「IDE上でAIと対話しながら、CloudTrailを遡って作成者を特定し、安全に整理する」 仕組みを考案しました。

2. コンセプト：IDE as an Ops Console

通常、インフラのコスト管理はAWS Trusted AdvisorやAWS Cost Explorerをブラウザで確認することから始まります。しかし、そこから「作成者の特定」や「削除の実行」を行うには、複数のコンソール画面やCLIを往復しなければなりません。

本プロジェクトのコンセプトは、「情報の集約と実行のハブをIDE（Kiro）に置く」 ことです。Kiroの強力なコンテキスト理解能力を利用し、複数のAWSサービスを跨ぐ複雑な運用タスクを一つのチャットUIに統合しました。

比較：従来の運用 vs. IDE as an Ops Console

項目	Before：従来の運用（ブラウザ中心）	After：Kiroによる運用（IDE完結）
主な画面	AWSコンソール、CloudTrail、Slack等の往復	IDE（Kiro）のチャット画面のみ
リソース調査	各サービスの画面を手動で巡回して確認	AIがAPI経由で主要なAWSサービスを横断的に調査
作成者の特定	膨大なログから目視で検索・推測	`CreateTime`からピンポイントで自動特定
依存関係把握	構成を脳内で描くか、資料を探す	その場でMermaid図解を自動生成
実行の安全化	手動操作による誤操作リスク	強制dry-runと復唱承認によるガードレール
ナレッジ参照	ブラウザの別タブで公式ドキュメントを検索	MCP経由で最新ドキュメントを自動裏取り

3. アーキテクチャ：Kiroを中心とした自律監査の全体像

本システムの全体フローを整理しました。Kiro（AI Agent）をハブとして、設定（Steering）、手足（MCP）、および実際のAWS環境がどのように連携して「安全な監査」を実現しているかを示します。

図1. 自律監査システムの全体像

この構成の肝は、AIが直接スクリプトを叩くのではなく、MCPサーバーという「標準化されたインターフェース」を介してAWS APIとリアルタイムに対話している点にあります。これにより、AIは環境の状態を構造化データとして理解し、Steeringによる高度な制御を受けることが可能になります。

4. 実装の三要素：Steering / Hooks / MCP の徹底解剖

4.1 Agent Hooks：責任の所在を明確にした監査実行の詳細

Hooksには単なるコマンドの羅列ではなく、AIが遂行すべき「ミッション」を詳細に定義しました。これにより、ボタンを押すだけでAIは自律的な「監査員」として動き出します。

.kiro/hooks.json の構成（抜粋）とミッション詳細：

{
  "hooks": [
    {
      "id": "audit-aws-resources",
      "name": "Audit AWS Resources",
      "description": "【ミッション：責任の所在を明確にしたAWSリソース監査の実行】",
      "command": "askAgent 'AWSリソースの監査を開始してください。作成者の特定とコスト削減額の算出、および依存関係の図解を含みます。'",
      "type": "terminal"
    }
  ]
}

このHooksがトリガーされると、AIは「未使用リソースの探索」「ガバナンスチェック（除外リストとの照合）」「CloudTrailによるエビデンス収集」を流れるように実行します。トリガーは下図の『▷』アイコンをクリックすることで実行されます。

図2. Agent Hooksの設定完了画面

4.2 Steering：AIの行動を縛る「絶対ルール」の内部ロジック

AIに強力な操作権限（AWS操作）を与える以上、最も重要なのは「ガードレール」です。.kiro/steering には、AIが迷わず、かつ暴走しないための「鉄の掟」を詳細に定義しました。単に「注意して」と指示するのではなく、プロトコル（手順）レベルで行動を縛っているのが本実装の最大の特徴です。

実際の `steering.md` 設定（抜粋）

AIが常に読み込む行動指針の核心部分です。

安全性に関する絶対ルール

絶対に自動削除を実行しない：すべての削除操作は dry-run モードで実行すること。

明示的承認の必須化：ユーザーが以下の形式で承認するまで、実際の削除コマンドを実行してはならない。 承認します: [リソースタイプ] [リソースID] を削除

「知識」をアップデートするステップ0：監査開始前に、必ず search_documentation を使用して最新のコスト最適化ガイドラインを検索し、判断基準を同期すること。

依存関係の可視化：削除候補の提示には、必ず Mermaid 記法による構成図を添付すること。

作成者情報の特定：タグがない場合でも CloudTrail イベント履歴を遡り、Username を特定するプロセスを遂行すること。

このSteeringがもたらす「3つの守り」

「ステップ0」による知識の最新化： AWSの料金改定や推奨事項は日々変化します。監査のたびに公式ドキュメントを「裏取り」させることで、AIの知識が陳腐化するのを防いでいます。
Mermaidによる「視覚的確約」：「消していいですか？」という問いに、EC2とEBSの紐付け図（Mermaid）を強制的に添えさせます。これにより、人間側も「あ、これは消しちゃダメなやつだ」と一目で判断できるダブルチェックが機能します。
復唱承認による誤操作防止：「はい」や「OK」では反応せず、特定のリソースIDを含むフレーズを復唱させることで、AIによる「良かれと思って」の暴走を物理的に封じ込めています。

ポイント このSteeringファイルがあることで、Kiroは単なる「チャットAI」から、「組織の運用ルールを完璧に守り、AWS公式ドキュメントをエビデンスとして提示するシニア監査員」へと昇華します。

図3. Agent Steeringの設定完了画面

4.3 MCP：aws-mcp-server による動的な知識連携

MCP (Model Context Protocol) は、今回のアーキテクチャの心臓部です。

AWS MCP の進化：統合による8つのツール

2025年12月、AWSは従来バラバラだった複数のMCPサーバーを統合し、単一の aws-mcp-server として再構築しました。本実装では、この統合MCPサーバーが提供する8つのツールを以下のように使い分けています：

表1. AWS MCP統合サーバーのツール採用判断

ツール名	機能	種別	本プロジェクトでの採用
call_aws	AWS CLIコマンドを直接実行	AWS API Tools	✅ Enable
search_documentation	AWS公式ドキュメントを検索	AWS Knowledge Tools	✅ Enable
read_documentation	ドキュメントページを読み込み	AWS Knowledge Tools	✅ Enable
recommend	関連ドキュメントページを推薦	AWS Knowledge Tools	✅ Enable
suggest_aws_commands	自然言語からCLI提案	AWS API Tools	❌ Disable
get_regional_availability	リージョン別可用性確認	AWS Knowledge Tools	❌ Disable
list_regions	リージョンリスト取得	AWS Knowledge Tools	❌ Disable
retrieve_agent_sop	運用手順（SOP）を取得	Agent SOP Tools	❌ Disable

技術的工夫：あえて「一部ツールを無効化（Disable）」する戦略 本プロジェクトにおけるガバナンスと精度の両立において、不要な4機能を意図的に disabledTools に指定しました。これには運用上、非常に重要な2つのメリットがあります。

Kiroの判断迷いを防ぐ：ツールを絞ることで、最短経路でのAPI実行とドキュメント参照を促し、回答の安定性の向上に寄与しています。AIが「どのボタンを押すべきか」で迷う時間を論理的に排除」しました。
トークンの保持とコンテキストの最適化：不要なツール情報を削ることで、一度に保持できるコンテキスト（対話履歴やCloudTrailの検索結果）を最大限に確保し、より長く、複雑な議論を可能にしています。これは推論の質を高めるための設計上の工夫です。

実際に設定した MCP Server の JSON ファイルを以下に示します。

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "timeout": 100000,
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata",
        "AWS_REGION=ap-northeast-1"
      ],
      "autoApprove": [
        "aws___call_aws",
        "aws___search_documentation",
        "aws___read_documentation",
        "aws___recommend"
      ],
      "disabledTools": [
        "aws___get_regional_availability",
        "aws___list_regions",
        "aws___retrieve_agent_sop",
        "aws___suggest_aws_commands"
      ],
      "disabled": false
    }
  }
}

下図のように、disabledTools で指定したツールがDisabledになっていれば問題ないです。

図4. MCP Server の設定完了画面

5. 独自実装：CloudTrail連携による「作成者特定」の自動化ロジック

本実装の最もユニークな点は、「責任の所在（作成者）」をAIが自動で突き止める点にあります。通常、数ヶ月分のログを手動で精査するのは困難な作業ですが、AIには以下の動的な絞り込みロジックをSteeringで指示しています。

対象リソースの CreateTime をAPIで取得する。
その日時に限定して CloudTrail を検索し、リソースタイプごとの固有イベント（CreateVolume や AllocateAddress 等）をピンポイントで照会する。

# AIが裏側で組み立てる最適化クエリのイメージ
aws cloudtrail lookup-events --region ap-northeast-1 \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=vol-0a1b2c3d \
  --start-time "2025-10-01T00:00:00Z" --end-time "2025-10-01T23:59:59Z" \
  --query 'Events[0].[Username, EventTime, EventName]'

これにより、膨大なログの中でもスロットリングを回避しつつ、数秒で「このボリュームは3ヶ月前に野村さんが作成し、その後一度も使われていない」といったストーリーを構築できます。これは人間が手動で行うと数十分かかる作業ですが、AIであれば短時間で完了します。

IaC（Infrastructure as Code）やサービスロール経由の場合は、実行主体（Role）を作成者の代理指標として扱います

6. 実践：Human-in-the-Loop による安全な削除プロセスと運用のリアル

AIは単にリストを出すだけでなく、「依存関係の再帰的チェック」を行い、人間が判断しやすい情報を提示します。これは、安全性と効率性を両立させるための「Human-in-the-Loop（人間中心のループ）」モデルです。

監査の実行とレポート生成のリアル

実際にAgent Hooksを起点に動作を開始すると、Steeringの定義に従い、まずは月間コスト上位10サービスと、その詳細な利用状況を出力します。AIがリソースの利用状況を深掘りしていく様子は、非常に頼もしいものです。

図5. コスト上位10サービスを教えてくれる画面

依存関係の可視化と承認プロセス

AIは削除候補の提示に際し、Mermaid記法を用いて依存関係を可視化します。

graph TD
    A[EC2: i-0abc123 (Stopped)] --- B[EBS: vol-01234 (Available)]
    C[Elastic IP: 1.2.3.4] --- D[None]
    style B fill:#ffcccc,stroke:#ff0000
    style D fill:#ffcccc,stroke:#ff0000

さらに、不要と判断されたリソースの削除推奨とその際の削減額を提示してくれます。解放コマンドと承認フォーマットも提示されるため、人が調査して不要だと判断したら、提示されたテキストをコピペするだけで済みます。これにより、操作ミスを劇的に減らすことができます。

図6. 不要と判断されたリソースを教えてくれる画面

Kiro: 「野村さん、上記リソースはガイドラインに抵触しています。以前は Project-Alpha で使用されていましたが、現在は孤立しています。削除を承認される場合は、『承認します: EBS vol-01234 を削除』と入力してください。」

このように、「AIが詳細な調査を行い、人間が最終的な意思決定を下す」 という理想的な分業がIDEの中で完結します。

実際に動かして見えた「気づき」

CloudTrailの保持期間の壁：CloudTrailのイベント履歴（Event history）はデフォルトで90日間参照可能です。そのため、タグが付いておらず、かつ長期間放置されているリソースは、作成者を遡って判断することが物理的に不可能です。
ポリシー定義の重要性：不要 or 必要リソースの判断基準（例：「何日間アクセスがなければ削除候補とするか」）に各企業のガバナンスポリシーをSteeringに組み込むことで、より実運用に即したものにカスタマイズすることができます。

7. まとめ：AIを「コードを書くためだけ」に使うのはもったいない！

ここまで読んでいただき、ありがとうございます。正直なところ、これまでのAI IDEは「いかに速く・正確にコードを書くか」ばかりが注目されていた気がします。しかし、私がAWSの多くのサービスを検証する中で、実際に現場で直面した一番の課題は、コードを書くことではなく「立ち上げた後のリソースをどう管理し続けるか」という煩雑な運用の方でした。

運用業務こそ、AIの「意志」と「制約」が輝く場所

今回紹介したSteeringによる行動制御は、コード生成よりも、むしろ「一歩間違えると危ない運用操作」でこそ本領を発揮します。AIに勝手な削除を許さず、最新のドキュメントを裏取りさせ、Mermaid図で人間に「これでいいですよね？」と確認させる。このプロセスを組み上げることで、経験年数に依らず、一定の精度を担保できるようになりました。

これは単に楽をするための自動化ではありません。「このリソース、誰が何のために作ったんだっけ……」というインフラエンジニア特有のモヤモヤをAIと一緒に解消し、「確信を持って削除ボタンを押せる」ようにするための、安全なインフラ管理の新しい形です。

最後に：AIという相棒と、攻めの運用を。

KiroやMCPを使いこなすスキルは、これからのクラウドエンジニアにとって、IaCを書くスキルと同じくらい……もしかしたらそれ以上に強力な武器になると感じています。

これまで「よくわからないから放置」されていたリソースに、AIという頼もしい相棒と二人三脚で立ち向かう。そうすることで、運用は「ただの繰り返し作業」から、環境をどんどん最適化していく「クリエイティブな仕事」に変わります。

AIをプログラミングの助手だけで終わらせるのは、本当にもったいないです。 AIの力を運用（Ops）へ解放して、地道な仕事をスマートに変えていく。そんな安全性を前提とした「攻めの運用」を、皆さんも自分の環境から始めてみませんか？

執筆者

野村稜武
NTT西日本サービス開発担当。新卒入社1年目。
クラウドインフラの自動化と生成AIの実用化に情熱を注いでいます。
現在は現場への技術還元を加速させるべく、「Kiro」や「MCP」のアウトプットに日々尽力しています。

参考資料

aws.amazon.com aws.amazon.com

商標

「Amazon」「Amazon Web Services」「AWS」および「Kiro」は、Amazon.com, Inc. またはその関連会社の商標です。

免責事項

本記事は筆者個人の見解であり、所属組織の公式見解を示すものではありません。