 本記事は 夏休みクラウド自由研究2026 8/16付の記事です。 |
こんにちは！SCSK猿橋です。
最近AWSの請求画面を見るたびに、頭の中で「おい乃木！無駄なインスタンスを残すな！破産するぞ！」と、もう一人の自分（F）がブチ切れてきます。（by VIVANT）
クラウドのコスト管理って、油断すると本当に命取りになりますよね。（なんか以前にもトラウマが。。。
そこで今回は、私のような一般エンジニアでも、別班並みの鋭さでコストに関するアドバイスをくれる「AWS FinOps Agent」を使ってみたいと思います。
はじめに
新しいAWSサービスが発表されるとすぐに触ってみたくなるのがエンジニアの性です。しかし、そのワクワク感の裏で常に付きまとうのが「利用料金への不安」です。
特に学習用の個人アカウントや検証環境では想定外のコストが発生することがあります（過去のトラウマ）
そんなトラウマ事例を発生させないよう、AIで事前にコスト相談をしてみたく、AWS FinOps Agentを使ってみました。
AWS FinOps Agentとは
FinOps（フィンオプス）とは
「FinOps（financial operations の略）は、財務・エンジニアリング・ビジネスの各チームを結びつけ、財務上の責任を共有し、コスト・スピード・品質の間でデータに基づくトレードオフを行うことを通じて、クラウド投資のビジネス価値を最大化するもの」とAWSブログに記載されています。
AWS FinOps Agentの概要
クラウドコストの異常検知・根本原因分析、自然言語によるコスト照会、最適化推奨の提示、定期レポート自動生成などを行うエージェント型AIソリューションです。エンジニアが普段使っている Slack や Jira と連携し、コスト異常の調査結果の通知やチケット作成を自動化します。AWS Cost Explorer・Cost Anomaly Detection・Cost Optimization Hub・Compute Optimizer を活用しており、2026/8現在は 米国東部（バージニア北部）リージョン にて追加料金なしで利用可能です。（「追加料金なし」はプレビュー期間中料金とのことです）
Cost Explorerとの違い
これまでもAWS Cost Explorerを使えば詳細な分析は可能でしたが、適切なフィルタリングやグラフの読み解きには慣れが必要でした。AWS FinOps Agentの特徴は、「今月、なぜ料金が上がったの？」とチャットで聞くだけで、複雑なデータを多角的に分析して回答してくれる点にあります。
セットアップ
以下の手順でセットアップしていきます。
１．AWS FinOps Agentにアクセスします
２．Region Unsupportedが表示されたら、米国（バージア北部）を選択します
３．Get startedをクリックして初期セットアップを開始します
４．エージェントの名前を設定し、以降はデフォルトでセットアップします
５．セットアップが完了したら、Open agentをクリックして作成したエージェントにアクセスします
６．AWS FinOps Agentのコンソールです。デフォルトは黒背景、右上の半月アイコンをクリックすると白背景に変更できます
実際に使ってみる
学習用AWSアカウントの状況
今回AWS FinOps Agentを動かす学習用AWSアカウントの利用状況です。普段それほど利用頻度は高くないアカウントです。
- 利用サービス：Amazon EC2、AWS Lambda、Amazon RDS、Amazon S3、Amazon Bedrock、Amazon SageMaker、Kiroなど
- コスト規模：月間数十ドル～100ドル未満
ユースケース①基本的な質問
Kiroが8.04ドルで最も支出額が高く、次いでAWS CodeCommit（2.00ドル）、Amazon RDS（1.49ドル）となっています。全体の支出額はかなり低く、今月の累計は約16.30ドルです（月途中までの概算）。
基本的な受け答えは英語のようです。
従量課金分はどれもそれほど高くはないですが、Kiroの金額は月中の契約開始だったので日割り計算でのコストのようです。
お客様のアカウントでは、いずれのレコメンデーションサービスもまだ有効になっていません。現在の状況と、今後の対応についてご説明します。
推奨事項が表示されない理由
コスト最適化の推奨事項を生成する2つのAWSサービスが、現在有効化されていません。
サービス | ステータス | 提供内容
— | — | —
Cost Optimization Hub | 未有効化 | 全サービスを対象とした、リソースの適正化（ライトサイジング）、アイドルリソースの特定、SP/RI購入の推奨
AWS Compute Optimizer | 非アクティブ | 実際の使用状況メトリクスに基づくEC2、RDS、Lambda、EBSのリソース適正化（ライトサイジング）の推奨
有効化の手順
1. Cost Optimization Hub → Cost Managementコンソール → Cost Optimization Hub：有効化（オプトイン）して推奨事項の受け取りを開始します。過去の使用状況を分析し、EC2、RDS、Lambda、EBSなどにおけるコスト削減の機会を提示します。
2. AWS Compute Optimizer → Compute Optimizerコンソール：サービスをアクティブ化します。14日間にわたるCloudWatchメトリクスを分析し、リソース適正化（ライトサイジング）の推奨事項を生成します。
支出データから読み取れること
すでに取得したコストデータに基づき、いくつか注目すべき点があります。
Kiro（月額8.04ドル）— 7月に開始された新しいサービスです。意図的な利用であるか確認することをお勧めします。
AWS CodeCommit（月額2.00ドル）— AWSはCodeCommitの提供を終了する予定です。代替サービス（GitHub、CodeCatalystなど）へ移行することで、このコストを削減できる可能性があります。
AWS Secrets Manager（月額1.18ドル）— 利用状況は比較的安定しており、支出データだけを見る限り、明らかな無駄は見受けられません。
Amazon RDS（月額1.49ドル）— Aurora Serverless v2の利用量はすでに少なく、適切なサイズで運用されていると考えられます。
Cost Optimization HubとCompute Optimizerを有効にしていただければ、リソースの適正化（ライツサイジング）やコスト削減に関する詳細な推奨事項を提示できます。それまでの間、何かお手伝いできることはありますか？
Cost Optimization Hubは有効化しておいた方が良さそうなので、別途有効化しておきます。
AWS CodeCommitはサービス終了するので代替サービスへ移行したら、、、とありますが、確か方針転換して、AWS CodeCommitはサービス継続にはなったのではないでしょうか。その点再確認してみます。
一生懸命AWSのドキュメントを探してくれているようです
AWS CodeCommitサービス終了の誤りに気付いてくれました。生成AIでは最新情報が把握できてなかったり誤回答がありうる（ハルシネーション）ので、別の情報源を検索したり、一次情報にあたったりするなど、真偽は確認するようにしてください。
※それにしても急に日本語で答えてくれたのはなんでや。。。
ユースケース②新サービスを試す前の相談
※回答が長かったのでスクショは途中省略
Amazon Bedrockの利用を開始する際、特に注意すべきコスト要因は以下の通りです。—
## Amazon Bedrock — 主なコスト要因
### 1. モデル推論（最大のコスト要因）
Bedrockでは、入力および出力の**トークン**単位で課金されます。通常、出力トークンの単価は入力トークンよりも高く設定されています。
– **オンデマンド**: トークン単位の従量課金（コミットメント不要）。実験や試行に最適です。
– **バッチ処理**: 対応モデル（Anthropic、Meta、Mistral、Amazon）において、オンデマンドより約50%安価です。オフラインのワークロードに適しています。
– **プロビジョニングされたスループット**: 専用キャパシティに対する時間単位のコミットメント。安定して大量の処理を行う場合はコスト効率が良いですが、利用量に急激な変動（スパイク）がある場合は無駄が生じます。
**注意点**: 長いシステムプロンプトや大きなコンテキストウィンドウを使用すると、リクエストごとに（再送されるため）入力トークン数が増加し、コストが膨らみます。
—
### 2. プロンプトキャッシング
プロンプトキャッシングを使用する場合：
– **キャッシュ書き込みトークン**の単価は、通常の入力トークンより**高く**設定されています。
– **キャッシュ読み取りトークン**の単価は、通常の入力トークンより**安く**設定されています。
コスト削減効果が得られるのは、キャッシュされたコンテンツが何度も再利用される場合のみです。キャッシュヒット率が低いと、かえってコストが増加する可能性があります。
—
### 3. リージョン間推論
リージョン間推論（Cross-Region Inference）を介してリクエストをルーティングすると、追加料金が発生します。CUR（コスト・使用状況レポート）の使用タイプで `*-mantle-input-tokens-*` というパターンがないか確認してください。これらはリージョン間ルーティングが行われていることを示します。
—
### 4. Bedrockエージェントとナレッジベース
エージェントを1回呼び出すと、複数のモデル呼び出し（オーケストレーションのステップ）が発生します。ユーザーからの単一のクエリによって、内部で3〜5回以上のLLM呼び出しが行われることがあり、トークンコストが増大します。また、ナレッジベースの検索を行うと、埋め込み（Embedding）モデルのコストも別途発生します。
—
### 5. ガードレール
処理されるテキスト単位（400文字）ごとに課金されます。大規模な利用（例：1日8,000リクエスト）では、コンテンツフィルタ、拒否トピック、PII（個人を特定できる情報）検出の各機能により、それぞれ1日あたり約14ドルのコストが加算される可能性があります。
—
### 6. レイテンシ最適化推論
応答速度を速める場合、トークンあたりの単価が高くなります。レイテンシの低さが厳格な要件である場合にのみ検討すべき選択肢です。
—
## 実験を行う際のヒント
| ヒント | 理由 |
|—–|—–|
| オンデマンドから始める | テスト段階でのコスト負担リスクを回避 |
| 開発・テストには小規模かつ安価なモデル（例：HaikuとSonnetの比較）を使用 | モデルのグレード間で価格差が大きい |
| トークン数を早期に監視 | 大規模な運用では、長いプロンプトが急速にコストを増大させる |
| リアルタイム性が不要な処理にはバッチモードを使用 | 約50%のコスト削減が可能 |
| BedrockでCost Explorerのタグ機能を有効化 | 初日からアプリケーションやチームごとの利用料を追跡・把握 |
特定のモデルの最新価格をお調べしたり、お客様のアカウントにおけるこれまでのBedrock利用料を確認したりしましょうか？
なるほど、最後にまとめてくれているのもあり、ポイントがわかりやすいです。生成AIをシステム開発などに活用している方は日々消費クレジットににらめっこしていることもあるでしょうから、確かに！と思うことも多い内容ですが、まだ触り始めの方はそういった勘所もないでしょうから、大変参考になるでしょう。
続いてトラウマ事件を起こしてしまったAmazon SageMakerも聞いておきましょう。
※回答が長かったのでスクショは途中省略
公式の料金ページに基づく、SageMaker Canvasの主なコスト要因は以下の通りです。
—
## SageMaker Canvas — 主なコスト項目
### 1. ワークスペースインスタンス（セッション時間） — **1時間あたり1.90ドル**
実際に作業しているか、単にブラウザのタブを開いているかに関わらず、**ログインしている間ずっと**課金対象となります。これが、予期せぬ請求が発生する最も一般的な原因です。
– **無料利用枠:** 最初の2ヶ月間は月160時間まで無料
– **無料利用枠終了後:** 4人のチームで各ユーザーが月40時間ログインした場合 = セッション料金だけで**月額304ドル**
– **ヒント:** 作業終了後は必ずログアウトしてください。管理者はAWSコンソールから自動シャットダウンをスケジュール設定することも可能です。
—
### 2. モデルのトレーニング — データサイズに応じて変動
**表形式データ / 時系列データモデル:**
| データサイズ | 推定トレーニングコスト |
|———–|————————|
| 100 MB未満 | 2.30ドル – 9.20ドル |
| 100 MB – 1 GB | 9.20ドル – 13.80ドル |
| 1 – 5 GB | 13.80ドル – 18.80ドル |
| 5 – 100 GB | 240ドル – 303.50ドル *(EMR Serverlessが使用されます)* |
| 100 – 500 GB | 295ドル – 415ドル |
| 500 GB – 1 TB | 406ドル – 525ドル |
**5 GBでの大幅なコスト増:** 5 GBを超えるデータセットでは、前処理にAmazon EMR Serverlessが使用されるため、トレーニングコストに200ドル以上が加算されます。実験段階では、データセットを5 GB未満に抑えることをお勧めします。
**CV（コンピュータビジョン）/ NLP（自然言語処理）モデル:** トレーニング時間に応じて課金され、料金は1時間あたり2.03ドル～4.89ドルです（ml.g4dn.12xlargeなどのGPUインスタンスを使用）。 **基盤モデルのファインチューニング:** 大規模なGPUインスタンス（ml.g5.8xlarge～ml.g5.48xlarge）を使用するため、長時間のトレーニングでは高額になる可能性があります。
—
### 3. データ処理 — 5 GBまで無料
| データサイズ | 推定コスト |
|———–|—————|
| 5 GB未満 | **$0** |
| 5 – 100 GB | $0.09 – $1.50 |
| 100 – 500 GB | $2.00 – $3.80 |
| 500 GB – 1 TB | $4.00 – $12.00 |
—
### 4. 推論 / 予測
– **表形式データのバッチ予測（5 GB以下）:** **無料**
– **リアルタイムエンドポイント:** SageMakerホスティングインスタンスの稼働時間単位で課金 — 削除するまでエンドポイントは稼働し続け、課金も継続されます
– **時系列データの単一予測:** 1回のクエリでも最低2時間分の料金が発生（$0.41–$0.53/時間）
– **大規模バッチ予測（5 GB超）:** EMR Serverless + Batch Transformを使用、1 TBあたり最大$363
—
### 5. すぐに使えるモデル — 基盤となるサービス単位で課金
| 機能 | 課金対象サービス |
|———|———–|
| コンテンツ生成 / 要約 | Amazon Bedrock（トークン単位） |
| 画像内の物体 / テキスト検出 | Amazon Rekognition（画像単位） |
| 感情分析 / エンティティ抽出 | Amazon Comprehend（100文字単位） |
| ドキュメント / 経費分析 | Amazon Textract（1,000ページ単位） |
| JumpStart基盤モデル | SageMakerホスティングインスタンスの稼働時間 |
—
## 利用開始時の実践的なヒント
| リスク | 対策 |
|——|———–|
| ログアウトのし忘れ | 管理コンソールで自動シャットダウンのスケジュールを設定する |
| 大規模データセットによるEMR起動 | 実験中はトレーニングデータを5 GB未満に抑える |
| リアルタイムエンドポイントの稼働放置 | テスト終了後、直ちにエンドポイントを削除する |
| 時系列データの単一予測 | バッチモードを使用して、最低2時間分の課金を回避する |
| 複数ユーザーの同時ログイン | 各ユーザーのセッションごとに$1.90/時間の料金が発生する | **無料枠について:** 最初の2ヶ月間は、月間160セッション時間まで無料でご利用いただけます。課金が始まる前に、いろいろと試してみるのに適した期間です。
お客様のアカウントにおける現在のSageMaker利用料金を確認したり、特定のユースケースでのコストを試算したりしましょうか？
やはりリスク第一位はログアウトのし忘れでしたね。$1.9/hはなかなかの課金額になります。
でもね、、前回やらかした時もそうなんですが、「『ログアウトする』…そんな言葉は使う必要がねーんだ。『ログアウトした』なら使ってもいいッッ！」ということで（？）、ログアウト忘れ対策も知りたいところです。
朗報です。AWSはまさにこの問題に対する具体的な解決策を提供しています。以下に、実施可能な対策をご紹介します。
—
## SageMaker Canvasにおけるセッションコストの増大（暴走）を防ぐ方法
### オプション1：アイドル時の自動シャットダウン（推奨 — ご要望のシナリオに最適）
SageMaker Canvasは、**`TimeSinceLastActive`** というCloudWatchメトリクスを出力します。AWSでは、設定した閾値（例：2時間）を超えてユーザーがアイドル状態（操作が行われない状態）になった際に、Canvasアプリを自動的に削除するCloudFormationテンプレートを提供しています。
**アーキテクチャ:**
- **CloudWatchアラーム** が `TimeSinceLastActive` を監視 — アイドル時間が閾値を超えるとアラームが発報
- **EventBridgeルール** がアラームの状態変化を検知
- **Lambda関数** が `DeleteApp` APIを呼び出し、アイドル状態のCanvasアプリをシャットダウン
**3つの制御レベルが利用可能です:**
| テンプレート | 適用範囲 |
|———-|——-|
| `all-domains-all-users` | リージョン内の全ドメインの全ユーザー |
| `one-domain-all-users` | 特定の1つのドメイン内の全ユーザー |
| `one-domain-one-user` | 単一のユーザープロファイル |
CloudFormationテンプレートはGitHubで入手可能です: [aws-samples/sagemaker-canvas-auto-shutdown-on-idle](https://github.com/aws-samples/sagemaker-canvas-auto-shutdown-on-idle)
> **注:** AWSでは、設定ミスなどに備えてメトリクスの「欠落（missing）」を検知するCloudWatchアラームも追加することを推奨しています。これにより、アイドル検知機能自体が動作しなくなった場合でも通知を受け取ることができます。
—
### オプション 2: ドメイン/ユーザープロファイル設定によるアイドル時のシャットダウン
SageMaker ドメインまたはユーザープロファイルで `IdleSettings` を直接設定できます。
– **`lifecycleManagement`**: アイドル時のシャットダウン機能の有効化/無効化
– **`idleTimeoutInMinutes`**: アイドル状態になってからシャットダウンするまでの待機時間
– **`minIdleTimeoutInMinutes` / `maxIdleTimeoutInMinutes`**: ユーザーが設定できる時間の範囲（管理者による制限）
これらは、SageMaker ドメインの設定時に CloudFormation、CDK、または AWS コンソールから設定可能です。
—
### オプション 3: スケジュールによるシャットダウン（時間指定）
チームの勤務時間が決まっている場合、管理者が Lambda 関数を設定し、特定の時刻（例：毎日午後 8 時）に `DeleteApp` を呼び出すようにスケジュールできます。これはアイドル検知よりも単純な仕組みですが、精度はやや劣ります。
—
### オプション 4: AWS Budgets によるアラート
SageMaker 専用の予算を設定し、利用料がしきい値を超えた際にメールや SNS で通知を受け取るようにします。これにより課金自体を防ぐことはできませんが、早期に警告を受け取り、対策を講じることが可能になります。
—
## 推奨される組み合わせ
| レイヤー | 対策 | 効果 |
|——-|———|——–|
| **防止** | アイドル時の自動シャットダウン (CloudFormation テンプレート) | 約 2 時間のアイドル後に自動的に課金を停止 |
| **検知** | メトリクス欠落時の CloudWatch アラーム | アイドル検知機能が動作しなくなった場合に通知 |
| **通知** | SageMaker 利用料に関する AWS Budget | 予期せぬコスト急増を捕捉 |
アイドル時の自動シャットダウンは、「ログアウト忘れ」という状況に対する最も直接的な解決策であり、ユーザーの行動に関わらずセーフティネットとして機能します。まずは手始めに、SageMaker 用の AWS Budget アラートの設定をお手伝いしましょうか？
これはまさに私にとっては朗報でした。Amazon CloudWatchのTimeSinceLastActiveというメトリクスでアイドル中のCanvasがチェックできる、ということですね。次回使う際はこのメトリクスを使ってアラートを仕掛けておきたいと思います。
ユースケース③停止・削除漏れの確認
お客様のアカウントで検出された、アイドル状態または未使用のリソースは以下の通りです。
—
### アイドル状態のリソース — 1件の推奨事項
| リソース | タイプ | リージョン | アクション | 推定月間削減額 | 作業負荷 | 推奨事項 ID |
|—|—|—|—|—|—|—|
| `simple-weather-news-table` | DynamoDB テーブル | ap-northeast-1 | 削除 | $0.65 | 低 | `fc0e5af8a47c2568` |
—
**詳細:**
– **リソース:** DynamoDB テーブル `simple-weather-news-table` (ap-northeast-1)
– **検出内容:** 過去14日間にアクティビティが検出されませんでした — テーブルはアイドル状態であると見受けられます
– **現在の月間コスト:** $0.65
– **削除時の削減額:** 月額 $0.65 (100% 削減)
– **実装の作業負荷:** 低 — DynamoDB コンソールから直接削除可能
**対応手順:** [DynamoDB コンソール (ap-northeast-1)](https://ap-northeast-1.console.aws.amazon.com/dynamodbv2/home?region=ap-northeast-1#tables) にアクセスし、削除前にそのテーブルが不要であることを確認してください。アプリケーションから参照されていないことも併せてご確認ください。
—
この DynamoDB テーブル以外に、アイドル状態の EC2 インスタンス、EBS ボリューム、その他の停止中または削除可能なリソースは検出されませんでした。削減可能な総額は少額（月額 $0.65）ですが、このテーブルが現在も使用されているかどうかを確認することをお勧めします。
なるほど、コストが低いのでチェックできていませんでしたが、確かに直近ではAmazon DynamoDBは未使用なので不要なリソースのようです。別途利用者に確認して削除しようと思います。
実は、ここでAmazon SageMaker Canvasのインスタンスログアウト漏れを検知してもらおうと、しばらくCanvasを起動したままにしていましたが、チェックされませんでした。もしや、検知対象外。。。？
なるほど、Amazon SageMaker Canvasはアイドル検出非対応とのことでした（どうりで検知しないはずだ。。。今回も無駄なコストをかけてしまいました。。。！
検知対象は追加されていくようなので、将来的には検知対象になるよう期待したいと思います。
Amazon QとAWS FinOps Agent比較
生成AIというところでは、Amazon Qとどちらを使うかも気になるところです。
なるほど、コスト質問に関する深い分析、Cost Optimaization Hubなどとの連携、SlackやJiraへの通知連携機能なども期待したいところです。
おわりに
AWS FinOps Agentでコストに対する事前調査、利用分析などに活用できることがわかりました。監視・通知機能は今後活用してみたいと思います。
最後に気になる質問を。
私の回答は英語のみ対応しています。『VIVANT』の乃木さんのようにバイリンガルではありませんから！😄
ご質問への回答ですが、私は二重人格というわけではありません。どのような言語でメッセージをいただいても、英語で返信するよう設定されています。もし以前に日本語での回答を目にされたことがあるとすれば、それは別の設定やセッションでのことだったのかもしれません。
日本語で何でもお気軽に聞いてくださいね。回答は常に英語になりますが。今日はAWSのコストに関して、何かお手伝いできることはありますか？