記事公開日
Slackでコストレポート配信してみた
この記事のポイント
本記事では、AWSのAgentCore Runtime（ARM64 Docker）とClaude Sonnet 4を活用し、毎週火曜08:00にSlackへ週次コストレポートを自動配信する仕組みについて解説します。前回のMCP ReadOnlyを利用した構成から発展し、@メンションによる対話形式でのEC2台帳や作成者情報の取得など、より実践的で便利なFinOps環境の構築手法を紹介しています。
- Tool Useループによる自律的なデータ収集と処理時間：
AIが自ら必要なAPI（Cost Explorer APIやEC2 DescribeInstancesなど）を判断し、15〜20回のTool Useループを実行してデータを収集します。この処理には3〜5分かかりますが、AgentCore Runtimeに分離することでLambdaの制限を回避し、安定した稼働を実現しています。 - ARM64アーキテクチャと最新のAWS動向への対応：
AgentCoreはARM64で動作するため、Dockerビルド時に--platform linux/arm64の指定が必須となります。また、2026年6月にプレビュー公開された公式の「AWS FinOps Agent」についても触れ、今後のソリューションの使い分けや展開についても言及しています。 - 独自の検証環境で直面したエラーとトラブルシューティング：
筆者が実際に構築する中で遭遇した「AgentCoreコンテナの120秒初期化タイムアウト制限による起動失敗」や「Sonnet 4.6のタイムアウト」といった問題に対し、start.pyでの遅延importやSonnet 4（apac推論プロファイル）への変更という具体的なノウハウを一次情報として提供しています。
はじめに
こんにちは。DXソリューション営業本部の岡田です。
前回のブログでは、Kiro上でAWS MCPサーバーをReadOnlyモードで連携し、EC2インスタンスの作成者を可視化する仕組みを紹介しました。
今回はその仕組みを発展させて、毎週火曜08:00にSlackへ週次コストレポートを自動配信する仕組みを構築しました。
また、Slackで@メンションすれば対話もでき、「EC2一覧を教えて」と聞けばEC2台帳や作成者情報も返してくれる構成にしました。
全体構成
↓
Trigger Lambda
↓
Bedrock AgentCore Runtime (ARM64 Docker)
↓ agent.py (FastAPI)
↓ boto3 Converse API → Claude Sonnet 4 ※最新のSonnet 4.6ではなくSonnet 4を採用した理由は後述
↓ Tool Use ループ（15〜20回）
↓ ├─ Cost Explorer API
↓ ├─ EC2 DescribeInstances (AssumeRole)
↓ ├─ Cloud9 / CloudTrail（作成者特定）
↓ └─ レポート生成
↓
Trigger Lambda → Slack に投稿
この仕組みは、3つのパーツで構成されています。
1.EventBridge — 「毎週火曜08:00に起動する」をスケジューリング
2.Trigger Lambda — EventBridgeから起動され、AgentCore Runtimeに「週次コストレポートを生成して」と投げて、返ってきたマークダウンをSlackに投稿
3.AgentCore Runtime — コストデータを集めてレポートを書くAIエージェント
EventBridge
毎週火曜08:00にTrigger Lambdaを起動し、実行してくれます。
Trigger Lambda
EventBridgeから呼ばれるLambda関数です。
- AgentCore Runtimeに「週次コストレポートを作って」と依頼する
- 返ってきたレポート（マークダウン文字列）をSlackに投稿する
AgentCore Runtime
AWSが提供する「AIエージェントをDockerコンテナとしてホストするサービス」です。自分で書いたPythonコードをコンテナに入れてデプロイすると、APIエンドポイントとして常時待機してくれ、安定して応答できます。
ARM64のDockerコンテナとしてAWS上で常時待機しています。
CPUアーキテクチャの種類です。AgentCoreはARM64でコンテナを動かします。
Dockerビルド時に
--platform linux/arm64を指定する必要があります。Tool Useループについて
AIが「自分で考えて、必要なデータを取りに行く」仕組みです。AIが自分でAWS APIを呼びます。
- Claudeに「週次コストレポートを作って」と依頼する
- Claudeが「今週のコストデータが必要」と判断し、
get_cost_and_usageツールの呼び出しを返す - agent.pyがそのツールを実際に実行（Cost Explorer APIを呼ぶ）して、結果をClaudeに返す
- Claudeが「次はアカウント別も欲しい」と判断し、次のツール呼び出しを返す
- これを15〜20回繰り返して全データが揃ったら、Claudeが最終レポートを生成する
Tool Useは、AIが「何のデータが必要か」を自分で判断してAPIを叩きます。
この「Claudeに聞く→ツール実行→結果を返す」のループはPythonのfor文で回しています。（AWSが提供しているのは「ツール呼び出しを返す」仕組みで、ループ自体は自前実装です）
Claudeに渡しているツール定義
Claudeに渡しているツールは下記です。
これらはagent.py内に書いたPython関数で、中身はboto3（AWS SDK）でAWS APIを叩くコードです。
Claudeには「こんな関数が使えるよ」とJSON形式で定義を渡しています。
| ツール名 | 何をするか | 具体例 |
|---|---|---|
| get_cost_and_usage | コストデータ取得 | 「今週のサービス別コスト」「前週のアカウント別コスト」など |
| get_cost_and_usage_with_resources | リソース単位のコスト取得 | 「EC2インスタンスごとの日額コスト」 |
| get_cost_forecast | 月末着地予測 | 「今月末にいくらになりそうか」をAWSが予測 |
| describe_ec2_instances | EC2台帳取得 | 「どんなインスタンスが動いているか」一覧 |
| get_instance_creators | EC2作成者特定 | 「誰がこのインスタンスを作ったか」をCloud9（ownerArn）やCloudTrail/Athenaで調査 |
| get_credit_details | クレジット適用状況 | 「今月いくらクレジットが適用されているか」サービス別・アカウント別 |
対話モード
定期配信だけでなく、Slackで@cost-botにメンションすると対話もできます。構成は
SlackのEvents APIは3秒以内にHTTP 200を返す必要があるため、Dialog Lambdaは即座に200 OKを返した後、非同期でAgentCore Runtimeを呼び出し、処理完了後にSlackスレッドへ結果を投稿しています。
同じAgentCore Runtimeが答えるので、コストの質問もEC2台帳も何でも聞けます。
下記のように「EC2一覧を教えて」と@メンションをして聞いてみると。。。
詳細にEC2一覧について答えてくれます！
※上記はブログ用のためマスキングし一部情報省略
せっかくなので、Slack配信してくれるbotに親しみやすい名前とアイコンを設定しました。
ちなみにチームメンバーからは不評です。
なぜこの構成なのか
Strands AgentsがARM64非対応
AgentCoreはARM64コンテナで動作する必要がありますが、Strands Agents（AWSのエージェントフレームワーク）はARM64に対応していませんでした。
そのため、boto3のbedrock-runtimeクライアントでconverse()を直接呼び、Tool Useループを自前で実装しています。
長時間処理によるLambdaの制限を避け、AgentCoreで安定化
ツール呼び出しを15〜20回繰り返すと3〜5分かかります。Lambda単体でも15分制限内に収まりますが、AgentCoreに分離することでコンテナが安定します。
主要コンポーネント
AgentCore Runtime（agent.py）
FastAPIでHTTPサーバーを立て、/invocationsエンドポイントでリクエストを受け付けます。Converse APIでClaude Sonnet 4にシステムプロンプトとツール定義を渡し、
Claudeが「次にどのツールを呼ぶか」を判断するTool Useループを回します。
Trigger Lambda
EventBridgeから起動され、AgentCore Runtimeに「週次コストレポートを生成して」と投げて、返ってきたマークダウンをSlackに投稿するだけのシンプルな実装です。
Dialog Lambda
Slackの@メンションを受けて、Slack署名検証後にAgentCore Runtimeへ質問を投げ、回答をスレッドに返信します。定期配信と同じAgentCoreを使うので、EC2台帳や作成者情報も対話で聞けます。
実際に配信されるレポートの例
毎週火曜08:00にSlackに届くレポートのイメージです。（金額・アカウント情報はマスキングしています）
### 今週のサマリー
| 項目 | 今週 | 前週 | 前週比 | 月末着地予測 |
| 合計コスト | $XX.XX ($XX.XX) | $XX.XX ($XX.XX) | -$XX.XX (-XX.X%) | $X,XXX.XX |
### サービス別コストTOP10（前週比）
| # | サービス名 | 今週 | 前週 | 増減額 | 増減率 | 注意 |
| 1 | Amazon Virtual Private Cloud | $XX.XX | $XX.XX | -$X.XX | -X.X% | 固定費 |
| 2 | Kiro | $XX.XX | $XX.XX | +$X.XX | +XX.X% | |
| 3 | AWS CloudTrail | $XX.XX | $XX.XX | +$X.XX | +X.X% | |
| ... | | | | | | |
### アカウント別コスト（前週比）
| アカウントID | 名前 | 今週（実請求） | 前週（実請求） | 増減額 | 増減率 |
| xxxxxxxxxxxx | アカウントA | $XX.XX ($X.XX) | $XX.XX ($XX.XX) | -$XX.XX | -XX.X% |
| xxxxxxxxxxxx | アカウントB | $XX.XX ($X.XX) | $XX.XX ($X.XX) | +$X.XX | +XX.X% |
| ... | | | | | |
### コスト増減要因分析
| # | アカウント | サービス | 前週 | 今週 | 増加額 | 推定要因 |
| 1 | アカウントA | Kiro | $XX.XX | $XX.XX | +$X.XX | 利用量増加 |
| ... | | | | | | |
### 月末コスト着地予測
| 区分 | 今月実績 | 着地予測 | 算出方法 |
| 月額固定費 | $XXX.XX | $XXX.XX | 月1回課金のためそのまま |
| 従量課金 | $XXX.XX | $X,XXX.XX | 日割り予測 |
| クレジット | -$XXX.XX | -$XXX.XX | 当月適用済み |
| 合計着地予測 | | $X,XXX.XX | |
### EC2インスタンス台帳
| Name | インスタンスID | タイプ | 状態 | 作成者 | 作成日 |
| instance-*** | i-***XXX | t3.micro | 🔴 stopped | 山田太郎 | 2024-XX-XX |
| ... | | | | | |
### クレジット適用状況（当月）
当月クレジット合計額: -$XXX.XX
| サービス名 | 適用額 |
| AWS Support (Business) | -$XXX.XX |
| Amazon VPC | -$XXX.XX |
| ... | |
### 削減提案
| # | 対象 | 内容 | 推定削減額/週 |
| 1 | 停止中EC2 | EBS削除 | $XX.XX |
| 2 | 未使用予約 | Capacity Reservation削除 | $X.XX |
| ... | | | |
追加質問は @cost-bot にメンションしてください
※上記レポート内の金額、アカウント情報などはすべて検証用のダミーです。
このレポートには上記のように以下の情報が含まれます。
- 今週/前週の合計コスト（クレジット適用前・後の両方）
- サービス別コストTOP10と前週比
- 全アカウントのコスト一覧
- コスト増減の要因分析（どのアカウントのどのサービスが増減したか）
- 月末着地予測（月額固定費と従量課金を分離した現実的な予測）
- EC2インスタンス台帳（作成者情報付き）
- クレジット適用状況（サービス別・アカウント別）
- 具体的な削減提案
ハマったところ
| 問題 | 原因 | 対策 |
|---|---|---|
| AgentCoreコンテナが起動しない | 120秒初期化タイムアウト制限 | start.pyで遅延import |
| Claude Sonnet 4.6がタイムアウト | AgentCore環境からのアクセス制限（調査中） | Sonnet 4（apac推論プロファイル）を使用 |
| EventBridgeルールが発火しない | cron式のUTCからJSTへの変換ミス | 曜日・時刻のダブルチェック |
| マネコンとレポートの金額が違う | Tax/Credit/Refundのフィルタ差 | レポートに注記を追加 |
前回（MCP ReadOnly）との比較
| 項目 | 前回 | 今回 |
|---|---|---|
| 実行環境 | Kiro（ローカル） | AgentCore（AWS上） |
| 起動方法 | 手動（チャットで依頼） | 自動（EventBridge） |
| 配信先 | Kiroのチャット画面 | Slack |
| EC2作成者特定 | MCP ReadOnly経由 | boto3直接（AssumeRole） |
| 対話 | Kiroチャット | Slack @メンション |
| 定期配信 | なし | 毎週火曜08:00 |
今後の展望
- AWS FinOps Agent（Preview）との比較検証 2026年6月にAWSマネージドのFinOps Agentがプレビュー公開されました。
Slack連携もあるので次回のブログで実装していきます！
- MCP連携 AgentCore内でMCPサーバーを起動して任意のAWS APIを呼べるように今後改良したいと思います。
まとめ
今回はこれまで手動で行っていたコストレポートをBedrock AgentCoreに載せてSlack自動配信する構築をしました。
週次コストレポートの自動配信は、チームのコスト意識を高めるのに効果的です。Slackで@メンションすれば追加の質問にも答えてくれるので、これまで手動で行っていたコスト確認が「Slackで質問する」形に変わり、コスト確認のハードルが大幅に下がりました。
次回のブログでは、FinOps Agentを試してみたいと思います！
もし「このサービスについて知りたい」「AWS環境の構築、移行」などのリクエストがございましたら、弊社お問い合わせフォームまでお気軽にご連絡ください。 複雑な内容に関するお問い合わせの場合には直接営業からご連絡を差し上げます。 また、よろしければ以下のリンクもご覧ください！
＜QES関連ソリューション/ブログ＞
※Amazon Web Services、"Powered by Amazon Web Services"ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
※このブログで参照されている、Claude、Claude Code、Claude Fable、Claude Opus、Anthropic は、Anthropic, PBC の米国およびその他の国における商標または登録商標です。
