[やってみた] DevOps Agent のサンプルスキル「Investigation Cost Guardrail」で調査にかかるコストを算出してみた

コンニチハ、千葉です。

AWS DevOps Agent には、エージェントの調査手順を拡張できる「スキル」という仕組みがあります。GitHub 上には AWS 公式のサンプルスキル集が公開されているのをご存知でしょうか？

今回はその中から、個人的に試してみたいと思った Investigation Cost Guardrail（調査コストガードレール） というスキルを試してみました。これは、必須で入れたほうが良いスキルだと思いました。環境によっては、想定した以上にログ調査コストが発生するかもしれません。これを事前に予防できるのは強いです。

「DevOps Agent に障害調査を任せたら、CloudWatch Logs や X-Ray のスキャンで思わぬ API 課金が発生した…」なんて経験、ありませんか？ このスキルは事前にどれくらいのコスト発生するか把握できます。

インストールから実行結果、そして使ってみた考察までまとめてみました。

DevOps Agent のスキルとは

まずは前提のおさらいです。

AWS DevOps Agent のスキルは、Markdown で記述された「調査手順の指示書」です。エージェントにドメイン知識や調査方法を教え込むことで、汎用アシスタントがカスタム作業を再現性を持ち繰り返し実行できるパッケージです。

• SKILL.md（必須）＋ references/、assets/ などで構成される Agent Skills 仕様 というオープン標準に準拠
• DevOps Agentでは、スクリプト実行はサポート外（Markdown・PDF・画像・データファイルのみ）

そしてこのスキル、自分でゼロから書かなくても、AWS がサンプル集を GitHub で公開してくれています。

リポジトリ: aws-samples/sample-devops-agent-tools

リポジトリには大きく3種類が含まれています。

• Skills — 特定の運用シナリオを調査するための指示書
• Custom Agents — システムプロンプトやツール割り当てを事前設定したエージェント
• CloudFormation Templates — スキルに必要な IAM 権限をプロビジョニングする IaC

スキルとしては、以下のようなものが用意されています（2026年7月時点）。

• aws-health-events — AWS Health のイベントを取得・分析し、サービス障害やメンテナンス、アカウント通知が原因でないかを確認
• crm-production-investigation-guidelines — CRM アプリ（REST API / SQS / Lambda / Aurora DSQL）の本番インシデントを調査するためのガイドライン
• eks-operation-review — EKS クラスターを AWS EKS ベストプラクティスに照らして監査し、セキュリティ・信頼性・ネットワーク・コスト最適化などの観点でレポートを生成
• enrich-with-aws-security-agent — 障害調査時に AWS Security Agent の CloudWatch ログを照会し、原因になりうるコードレベルの脆弱性を（ファイル・行番号付きで）発見
• investigation-cost-guardrail — 障害調査のクエリを実行する前に AWS API コストを見積もる ← 今回試すのはこれ
• rds-operation-review — RDS / Aurora を Well-Architected Framework とベストプラクティスに照らして評価し、優先度付きの改善レポートを生成
• skip-scheduled-maintenance — メンテナンスウィンドウ中に発生した MEDIUM / LOW のアラームを自動でスキップし、無駄な調査を発生させない
• support-cases — AWS Support ケース（オープン / 解決済み）の履歴を検索し、症状やエラーパターンが似た過去のインシデントと解決策を見つけて原因分析

色々なサンプルスキルがあります。そのまま使うのもありますが、スキルの作り方、書き方も参考になりそうです。

investigation-cost-guardrail を試してみた

さて、本題のスキルです。

このスキルをひとことで言うと、「障害調査のクエリを実行する前に、その調査でかかる AWS API コストを見積もり、閾値を超えそうなら止める」 というものです。

DevOps Agent は障害調査のために CloudWatch Logs / Metrics、X-Ray、クロスリージョンのリソースなどに問い合わせますが、これらは地味に課金が発生します。特にログのスキャン量が多いと、想定外のコストになりがちです。そこに「見積もり → 実行可否の判断」のフローを作ります。

いつ発動するか？

• 発動する: アラーム、障害、エラー、レイテンシ増加、ダウンなどインシデント後の原因調査
• 発動しない: デプロイ、スケーリング、設定変更、アーキテクチャレビュー、課金レポート、一般的な How-to

「なぜサイトが落ちたのか？」のような調査系のリクエストの時に、本スキルが実行されます。

動作の流れ

SKILL.md を読むと、おおむね次のステップで動きます。

• リクエストの解析: 調査対象のロググループ、メトリクス名前空間、X-Ray/CloudTrail の要否、そして関係する全リージョンを洗い出す。リージョンは ARN やアラームのメタデータから導出し、デフォルトを勝手に仮定しない。
• 実データ量の取得:CloudWatch Logs のボリュームを確認。IncomingBytes や DescribeLogGroups の storedBytes から実際のデータ量を取得。レートは AWS Pricing API を利用。
• クロスリージョン転送の計算: リージョンをまたいで返るデータに $0.02/GB を適用。集計クエリはスキャン量の約1%、生データ取得は最大100%という前提で見積もり。
• ビジュアルプランの表示: 各調査ステップの GB 数、ステップ単価、累計、閾値との比較、フォールバック見積もりを表示。

動作:

• 時間ウィンドウなし → ログスキャン範囲が無制限になる可能性があるため、調査範囲時間がしていない場合は調査が停止(またはユーザーへ調査範囲の時間を質問する)
• コスト < 閾値（デフォルト $10） → 調査を実行
• コスト ≥ 閾値 → キャンセル（承認 or スコープ縮小を要求）
• コスト削減の提案: キャンセル時は「正確なタイムスタンプを渡す」「特定のロググループに絞る」「エラーメッセージでフィルタ」「X-Ray/CloudTrail をスキップ」「単一リージョンに限定」など具体策を提示

指定されているルール

• リージョンや時間ウィンドウをAIが勝手に仮定しない（証拠から導出、なければ明示的に質問）
• 常に実データを問い合わせる（見積もりをハードコードしない）
• 1 GB = 1e9 バイト（AWS 課金に合わせる。1024³ ではない）
• **大規模スキャン（>100 GB）**は閾値以下でもフラグを立てる
• 閾値のデフォルト閾値は $10.00 です。これ未満なら自動で実行、超えるとキャンセル

会話の中で "Set cost threshold to $1.00" のように上書きできますし、"Set threshold to $0" で最も保守的（＝毎回確認）にもできます。Agent Space の設定で恒久的なデフォルトも指定可能です。

必要な IAM 権限

Pricing API を叩くため、pricing:GetProducts の権限が必要です。エージェントスペースで指定しているIAMロールに、pricing:GetProductsを付与されているか確認してください。また、リポジトリの CloudFormation テンプレートでスキルごとのポリシーをまとめてプロビジョニングできます。

# aws cloudformation deploy \
  --template-file cloudformation/devops-agent-skill-policies.yaml \
  --stack-name devops-agent-skill-policies

インストールしてみる

それでは実際に設定していきます。DevOps Agent のスキルは、GitHub リポジトリから直接インポートするのが一番楽です。

前提として Agent Space と、それに紐づく GitHub アカウント接続が必要になります（パブリックリポジトリのインポートには何かしらの GitHub アカウント接続があれば OK）。エージェントスペース > 機能 > パイプライン > ソース追加 より GitHub アカウント連携を設定します。

リポジトリからインポート

1. Operator Web App > 左ペイン ナレッジ > Skills > スキルを追加 をクリック
2. リポジトリからインポート > URL(https://github.com/aws-samples/sample-devops-agent-tools/tree/main/skills/investigation-cost-guardrail) を入力 > スキルをインポート をクリック

これでカスタムスキルを作成できました。

実行してみる

インシデントレスポンスのチャットから、プロンプトを入力してみます。

どのようなスキルがありますか?

• investigation-cost-guardrail — インシデント調査を実行する前に、CloudWatch Logs Insights、GetMetricData、X-Ray、またはクロスリージョンクエリなどのAWS APIコストを事前に見積もり、ステップごとのコストプランを表示します。見積もりがしきい値を超えるか、時間枠が指定されていない場合は調査をキャンセルします。このスキルは、すでに発生した問題(インシデント、エラー、障害、アラーム、レイテンシースパイク、障害など)の診断にのみ適用されます。例:「何が起きたか」「なぜXがダウンしているか」「このアラームを調べて」「エラーを調査して」。リソースの作成、変更、デプロイ、スケーリング、設定(CDKやCloudFormationスタックのデプロイ、サービスのスケーリングなど)、アーキテクチャやWell-Architectedレビュー、コストや請求レポート、インベントリリスト、一般的なハウツー質問には適用されません。

カスタムスキルが登録されてるのがわかりました。

インストールできたので、実際に障害調査をエージェントに投げてみます。

障害が発生しています。何が起きたか調査して。

すると、調査を実行する前にコスト見積もりのビジュアルプランが表示されました。

障害調査を開始する前に、調査コストを見積もります。

📊 調査コスト見積もり
現在の状況を分析したところ、以下の情報が不足しています:

⚠️ 必要な情報が不足
調査を実行するために、以下の情報を教えてください:

時間枠 — 障害がいつ発生したか（例: "過去1時間"、"今日の14:00頃"、"30分前から"）
影響を受けているサービス/リソース — どのサービスやリソースに問題があるか（例: Lambda関数、EC2インスタンス、RDS、ECS、API Gateway など）
障害の症状 — 何が起きているか（例: エラーが出ている、レスポンスが遅い、サービスが停止している、など）
📋 最悪ケースの調査プラン
時間枠が指定されていないため、すべての保存されたログデータをスキャンする必要があります:

🚫 CANCELLED — 時間枠未指定

調査ステップ（最悪ケース見積もり）:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️ CloudWatch Logs (全ログ)
   → 推定: 5 GB/ロググループ（時間枠不明のためフォールバック）
   → コスト: データ量により変動 - $25.00+

⚠️ CloudWatch Metrics
   → 推定: 不明（対象メトリクス未特定）
   → コスト: 変動

⚠️ CloudTrail LookupEvents
   → コスト: $0.00 (無料)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
推定合計: $25.00+ (しきい値 $10.00 を超過)
決定: 🚫 CANCEL
💡 コスト削減のための提案
提供いただく情報	コスト削減効果	削減率
正確なタイムスタンプ (±5分)	10分間のみスキャン	~90%+
特定のログループ名	1つのログループのみ	最大90%
既知のエラーメッセージ	無料FilterLogEvents使用	100%
次のステップ:

障害の詳細を教えていただければ、正確なコスト見積もりと調査プランを作成します。例:

"過去30分間でLambda関数がタイムアウトしている"
"今日の14:00頃からAPIのレスポンスが遅い"
"EC2インスタンスi-xxxが5分前から応答しない"

スキルが動作し、情報が足りな旨、また調査実行前にどらくらいコストが発生するか、コスト削減の提案が表示されました。
本番環境で、特にログデータ量が多い場合は、こちらを入れておくと想定外のコストが発生しないようになるで、安心ですね。

スキルが実行されないパターン

アラームが発生していないか調査して

と指示したところ、スキルが実行されずそのままアラームの発生状況が調査されました。なぜスキルが使われなかったか聞いたところ、

> このスキルは、すでに発生した問題（インシデント、エラー、障害、アラーム発火など）を診断する調査にのみ適用されます。具体的には:

「何が起きたか」
「なぜXがダウンしているか」
「このアラームを調べて」
「エラーを調査して」
といった、過去または現在進行中の問題の原因を特定するケースです。

とのことでした。

考察

実際に触ってみての所感です。

調査前にコストが可視化されるので、「気づいたら課金が…」を防げる。心理的な安心感が大きいです。
見積もりはあくまで見積もりになります。実データを引きにいくとはいえ、フォールバック（権限エラー時の 5 GB/ロググループ等）が入ると誤差が出るため、ロール設定には注意が必要です。また、「調査系リクエストにだけ効く」という割り切りなので、カバー範囲を広げるにはスキルのチューニングが必要になります。

DevOps Agent に日常的にインシデント調査を任せている場合は、必須で有効にした方がいいレベルに実際使って感じました。
「エージェントに調査を任せる」という運用スタイルが広がるほど、こういうコストのガードレールは効いてくると思います。サンプルスキルなので、自社のポリシーに合わせて閾値ロジックを変更したり、スキルが発動するケースをチューニングすると良いと感じました。

障害調査は「急いで原因を知りたい」場面だからこそ、コストが後回しになりがちです。そこに事前見積もりとゲートを挟んでくれるこのスキルは、地味ですがかなり実用的だと感じました。GitHub のサンプル集には他にも便利なスキルが揃っているので、ぜひ覗いてみてください。

それではまた！

参考

• aws-samples/sample-devops-agent-tools（GitHub）
• Investigation Cost Guardrail スキル
• DevOps Agent Skills（AWS ドキュメント）
• Agent Skills 仕様