本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ最終記事（第11弾）として、クラウドのコスト管理（FinOps）について解説する記事です。
クラウドの従量課金は判断ひとつで月10万にも月1000万にもなります。本記事では請求が膨張する原因、FinOps（クラウドコスト運用の継続最適化）の3フェーズ、料金モデル・タグ戦略・規模別の管理レベル、そしてLLM時代の新しいコスト論点まで解説します。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
この記事の結論
- タグ規約を最初に決める（後からは付けられない）
- 設計段階で料金モデルを織り込む
- 開発環境は自動停止の仕組みで守る（気合では守れない）
- LLM API利用にはユーザー単位の上限を必ず設ける
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもFinOps（コスト管理）とは何か
FinOpsとは、ざっくり言えば「クラウドの利用料を継続的に見える化し、無駄なく使い続ける活動」です。
水道料金を想像してください。蛇口を開けっぱなしにすれば請求は膨れ上がり、使っていない部屋の水道も止めなければ無駄に流れ続けます。クラウドも従量課金なので、インスタンスの起動しっぱなし・ログの出しすぎ・不要なリソースの放置で、見積もりの3〜10倍の請求が来る事故は珍しくありません。FinOpsは単なる節約ではなく、「必要なところに払い、無駄を削る」投資の最適化です。
なぜ設計段階でコストを考えるのか
理由は3つあります。第一に、想定の3〜10倍になる事故が頻発するからです。よくある原因は驚くほど同じパターンで、開発環境の止め忘れ（夜間・休日も24時間課金）、ログの大量出力（CloudWatch Logs料金が本番運用費を超える）、NATゲートウェイ経由の通信、「念のため大きめ」のDBスペック、S3の古いオブジェクト放置、そして最も見落としやすいegress（クラウドから出ていく通信）料金です。全てに「設計段階で気づけたのに」という共通点があります。
第二に、コスト最適化のためのアーキテクチャ組み直しはOne-way Doorに近く、後から直すコストが巨大だからです。サーバーレスかコンテナかの選択だけでも、リクエストパターン次第で2倍以上の差が出ます。
第三に、コストは経営の決裁領域だからです。月10万までは現場判断、月100万は経営承認といった「支出のガバナンス」を設計段階で合意しておかないと、請求書が届いた月末に経営と現場で揉めます。
FinOpsの3フェーズ
FinOpsは「Inform（見える化）→ Optimize（最適化）→ Operate（運用化）」の3段階で回します。
| フェーズ | 内容 | 代表ツール |
|---|---|---|
| Inform | 誰が・何に・いくら使っているかを可視化 | Cost Explorer・Billing Reports |
| Optimize | 不要リソース削除・サイジング・割引活用 | Compute Optimizer・Trusted Advisor |
| Operate | ガバナンス・予算上限・継続改善の組織化 | Budgets・タグ規約・週次レビュー |
多くの企業は「見える化」すら不十分なまま、いきなり節約策に走って効果が出ないパターンにはまります。特にOperate（組織として回し続ける仕組み）が抜けると、1回削減して終わりの単発イベントになります。
主要な料金モデル
クラウドの料金は従量課金が基本ですが、長期コミットで大幅に割引される仕組みもあります。使い方次第でコストが半分以下になるため、モデルの理解は必須です。
| モデル | 内容 | 割引 |
|---|---|---|
| オンデマンド | 使った分だけ | 基準(定価） |
| リザーブド（RI）/ Savings Plans | 1〜3年の利用コミット | 最大70%オフ |
| スポット | 中断OK・余剰リソース | 最大90%オフ |
定常負荷の本番ワークロードにはRI / Savings Plans、バッチ処理にはスポットを使うのが定石です。ただしRIは使わなければ損失が確定するので、カバレッジと使用率を監視する運用が前提になります。
可視化の基本 ― タグ戦略
コストを可視化する前提は「全リソースへのタグ付け規約」です。タグ無しのリソースは請求書上「不明コスト」として集計され、誰が・何のために使っているか分からなくなります。必須タグの定番はEnvironment（prod / staging / dev）・Project・Owner・CostCenter（部門コード）・Serviceの5つです。
タグ未設定のリソースを自動検知・停止する仕組みをIaCと組み合わせるのが現代の標準です。タグを「あとで付けよう」にすると永遠に付きません。運用開始後の後付けは地獄です。
どう選べばいいのか ― 規模別の3シナリオ
個人開発・スタートアップなら ― 予算アラート+固定費ゼロ
AWS Budgetsで月額上限アラートを初日に設定してしまいましょう。タグはEnvironmentとOwnerの2つだけで十分です。サーバーレス（Lambda・Vercel・Cloud Run）で固定費ゼロを基本にして、DBはSupabaseやNeonの無料枠を活用するのが合理的だと思います。MVP段階での過度な最適化は時間の無駄ですので、「上限アラート+止め忘れ防止」だけ守って前に進んでください。
中小SaaSなら ― 週次レビューと自動停止
月50万を超えたあたりから、コストレビューを週次で回す価値が出ます。タグ5項目を必須化し、RI / Savings Plansで30〜50%削減、CloudWatch Logsの保持期間短縮、開発環境の夜間自動停止を仕組み化します。この規模は手動運用の限界で、自動化スクリプトを書く投資が回収できるフェーズです。
大企業なら ― 専任FinOpsと自動最適化
専任のFinOpsチームを置き、AWS Organizationsで部門別アカウントを分離、タグ未設定リソースは自動検知・停止します。Compute Optimizerの推奨を月次で適用し、RIカバレッジを80%以上に維持します。マルチクラウド管理ツール（CloudHealth等）の導入も視野に入ります。
なおデータ基盤を持つ場合は別枠の注意が要ります。BigQueryはクエリ量課金で「SELECT * が致命傷」になり、SELECT列指定・パーティション・クエリキャッシュの活用が効果大です。
AI判断軸 ― LLMコストが新しいFinOpsの中核になる
AI活用が前提になると、コスト管理は「人間が最適化する」から「AIが常時提案・自動適用する」フェーズへ移行します。同時に、AI自身の利用コストが新しい管理対象になります。
LLM APIコストの管理
2026年現在、LLM APIの利用コストはインフラコストと同等以上に膨らむケースが増えています。大型モデルは入力100万トークンあたり数ドル〜15ドル、出力はその3〜5倍の単価です。ユーザー1リクエストあたりのコストが数円になるため、トラフィック増加時のコスト予測が従来のコンピュート課金とは異なる計算になります。対策の柱は3つ、プロンプトキャッシュ（入力コストを最大10分の1に）、モデルの使い分け（簡単な処理は小型モデル、複雑な処理だけ大型モデル、で10倍差）、ユーザー単位の利用上限設定です。
AIによるコスト最適化の自動提案
AWS Cost Anomaly Detection・Compute Optimizer・Trusted Advisorは既にAIベースの推奨を提供しており、「このEC2はCPU使用率5%未満なのでダウンサイズすべき」のような提案が自動で届きます。IaCでインフラを管理していれば、これらの提案をTerraformの変更PRとして自動生成する仕組みも構築可能で、「異常検知 → 原因特定 → 修正PR生成 → 人間の承認」を一気通貫で処理する運用が標準化しつつあります。GUIの手動プロビジョニングでは、この流れに乗れません。
やってはいけないこと
コストは「やらないと気付いたら月額が倍」の領域で、最初に守る運用ルールで9割が決まります。特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| タグ規約をリソース作成後に決める | 後付けは永遠に終わらず不明コストが半数を超える → 設計初期に規約を決める |
| 開発環境を24時間稼働させる | 開発・検証環境の合計が本番を超える現象が頻発 → タグ+自動停止スクリプトで夜間・週末に強制停止する |
| RIをカバレッジ監視なしに大量購入 | 使わず期限を迎える「死に買い」で損失確定 → 使用率を監視してから積み増す |
| 本番でDEBUGログを出力 | ログ請求が月100万円超の事例多数 → INFO以上+保持期間短縮 |
| コスト異常を月末請求書で初めて知る | 1ヶ月分の損失が確定してから気づいても手遅れ → Cost Anomaly Detectionを設定する |
| LLM APIをユーザー上限なしで提供 | プロンプトループで一晩で月100万円に到達する事例がある → ユーザー単位の上限とレート制限を必須にする |
アーキテクチャ選定そのものがコストを決めることも忘れてはいけません。AmazonのPrime Videoチームは2023年にマイクロサービスからモノリスに戻してコストを90%削減した事例を公開しています。
筆者メモ ― 年末年始を挟んだ請求書
ある開発チームが年末のリリース対応で慌ただしく働き、動作確認用に立てた数台のGPUインスタンスを「後で止めよう」と思いながら年末年始の休暇に突入した──年始に出社してコスト画面を開いた瞬間、通常の月の10倍超の請求が出ていた、という事例があります。検証用のr5.2xlargeを土日に止め忘れて数万円溶かした、という個人開発者のエピソードもよく聞きます。
教訓は、「『後で止めよう』は人間の意思に依存していて、ほぼ必ず破綻する」ということです。止め忘れを叱るより、止まる仕組みに倒します。コストは気合ではなく、設計で守るものです。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- タグ規約（Environment・Project・Owner・CostCenter）
- 予算上限とアラート（月額・週次）
- 料金モデル選定（オンデマンド / RI / Savings Plans）
- 開発環境の自動停止ポリシー
- ログ保持期間とデータ削除ポリシー
- コストレビューの頻度（週次 / 月次）
- LLM・AIサービス利用の上限設計
言語化した答えはADRとして残します。書き方の具体例は以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事はクラウドコスト管理（FinOps）について、請求膨張のパターン・3フェーズ運用・タグ戦略・規模別の管理レベル・LLM時代の論点まで解説しました。如何だったでしょうか。
タグ規約を最初に決め、設計段階で料金モデルを織り込み、規模に応じて運用化する。この順序で進めれば、請求書を開いて青くなる事故は防げます。
これで「システムアーキテクチャ」カテゴリ全11記事が完結しました。次回からは「ソフトウェアアーキテクチャ」カテゴリに入り、モノリス vs マイクロサービス、言語選定、API設計といったソフトウェアの内部構造の選定軸を解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS コスト管理 も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（22/95）