先日、2026年3月7日に開催された JAWS DAYS 2026 にて、登壇させていただきました。本記事ではその内容の振り返りと、当日話しきれなかった実装の裏側、そして初めての外部登壇を終えた感想をお伝えします。
スライド公開
当日使用したスライドはこちらです。
CCoEはAI指揮官へ 〜Bedrock×MCPで構築するコスト・セキュリティ自律運用基盤〜
セッション概要
「CCoEはAI指揮官へ Bedrock × MCPで構築するコスト・セキュリティ自律運用基盤」
クラウド運用の現場では、コストの異常検知やセキュリティの通知を自動化している組織は多いと思います。しかし、通知が届いたあとの 「判断」と「一次対応」 はどうでしょうか？
「結局、詳しい人がログを読み解いて判断している」「通知が多すぎて現場が疲弊し、オオカミ少年化している」
そんな課題を解決するために、私たちは Amazon Bedrock と MCP（Model Context Protocol） を活用し、AIが判断を自律的にサポートする運用基盤を構築しました。
背景：なぜ「3層構造」の設計に至ったのか
開発初期、私は「LLMに全てのログを渡せば、判断まで丸投げできる」という過信をしていました。しかし、PoCで直面したのは、AIの精度以前の「設計上の欠陥」でした。
- 数値の揺らぎ： 同じデータを入れても、LLMのトークン計算や推論の癖で合計金額が微妙に変わる。
- 再現性の欠如： 運用の基盤として「さっきは正解したのに今回は間違える」状態は致命的。
- ハルシネーション： 存在しないAWSの仕様や改善案をもっともらしく回答する。
これらの失敗から学んだのは、「AIにどこまで任せるか」という責任境界の設計 が最も重要であるということです。そこで、思考プロセスを以下の3つのレイヤーに分解しました。
- 事実層（数値・ログ）： 揺るがない確定データ。ここはコード（Lambda/Athena等）が担う。
- 判断層（ルール）： 再現性のある判定ロジック。固定のビジネスルールが担う。
- 知識層（最新仕様）： 変わり続けるAWS仕様。ここをAI（Bedrock）が担う。
AIを「魔法の箱」として扱うのではなく、確定した事実を渡し、膨大な知識ベースに基づいた 「構造化」と「説明」 を担わせる。この役割分担こそが、自律運用の鍵となります。
本編で話しきれなかった補足情報：自律運用を実現する「専門家集団」の実装
セッション内では時間の都合上、詳細な実装には触れられませんでしたが、現在の運用基盤にいたるまでにはAWSナレッジ特化チャットアプリ「くもなび」というツールの進化がありました。
「くもなび」の誕生と直面した壁
2025年11月、私たちはAWSナレッジ特化チャットアプリ「くもなび」をリリースしました。先行トライアルでは開発部の約4割に日常的に利用され、「便利だね」と声をかけてもらえるまでになりました。
しかし、旧構成（Amazon Bedrock の Converse API と Streamlit）では、現場の「急所」に手が届かない課題もありました。
- 「惜しい」レビュー： 構成図を投げても、「EC2がパブリックサブネットにある」といったクリティカルなミスを見逃すことがありました。
- コスト計算のカオス： 数万行の価格表をAIに読ませると、どうしてもハルシネーションが混じります。
- 運用のタフさ： 全社でガシガシ使い倒すには、Next.js + Fargate のような強固な基盤が必要でした。
（参考）
新しい「Core」：4人の専門家によるプロの仕事
旧構成において精度が伸び悩んだ最大の原因は、
画像解析、コスト計算、最新仕様の検索といった性質の異なるタスクを、すべて1つのLLMに「丸投げ」していたことにありました。
LLMは汎用的な推論には強い一方で、インフラ設計のように 異なる種類の専門知識を正確に扱うタスクでは限界があります。
インフラの世界の厳密さを、1つの「汎用的な脳」だけで担保するのは難しいのです。
そこで新しい「くもなび Core」では、 1つのLLMにすべてを任せる構成から、「専門家チーム」で問題を解く構成へと発想を転換しました。
それぞれのエージェントが、次のような専門領域を担当します。
図）くもなび Coreのアーキテクチャ図
画像分析エージェント
構成図を読み取り、AWSリソース構成を構造化データとして抽出するAWSナレッジエージェント
AWS公式ドキュメントを参照し、ベストプラクティスや制約条件を確認する見積エージェント
構成に基づいて概算コストを算出し、コスト観点での指摘を行うオーケストレーターエージェント
各エージェントの結果を統合し、最終的なレビュー結果を生成する
このように、役割を分担した複数のエージェントが連携することで、
単一のLLMでは難しかった「精度」と「説明可能性」を両立させています。
なぜ汎用AI（Gemini等）ではなく「くもなび」なのか？
社内では Gemini などの汎用AIも活用されています。
ただし、AWS構成のレビューのように 「公式ベストプラクティスとの整合性」が重要な場面では、情報ソースが明確なツールが必要になります。
「くもなび」の特徴は、回答の根拠となる情報ソースを AWS公式ドキュメントに限定していることです。
これにより、一般的なAIのような広範な知識ではなく、AWSのベストプラクティスに基づいた判断を支援することができます。
用途としては、次のような使い分けになります。
汎用AI（Geminiなど）
- アイデア出し
- コード生成
- 一般的な技術相談
くもなび
- AWS構成レビュー
- AWSベストプラクティス確認
- 公式ドキュメントベースの判断
実際に、AWS構成図を入力として セキュリティ観点のレビュー を依頼してみます。
① 構成図を添付してレビューを依頼
② セキュリティレビュー結果が生成される
おわりに
実は、今回が私にとって 初めての社外登壇 でした。 これまでは一人の参加者としてJAWS-UGに参加し、諸先輩方の話を聞いては「明日からの仕事のエンジン」となるような活力と刺激をいただいてばかりでした。
今回、今度は自分が登壇する側となり、私のセッションを聞いてくださった方々に、何か一つでも日々の運用に活用できるものをお渡しできていたら嬉しいです。 今後も自らの経験をコミュニティの皆さんに還元できるよう、精一杯頑張りたいと思います。
最後まで読んでいただき、ありがとうございました。
