はじめに
こんにちは！ ContractSでSREをしている福嶌(id:s-fukushima29)です。2023年4月に入社してはや3年目になりました。
自分の経歴としてはプログラマーとしてキャリアをスタートしました。その後、ContractSに入社する前はMSP（マネージドサービスプロバイダ）事業に携わり、日々お客様のAmazon Web Services (AWS)、Google Cloud、Microsoft Azureといったクラウド環境と向き合ってきました。
そこでは、1円のコストがビジネスにどれだけ影響するかを肌で感じていて、「スポンサーが石油王でもない限り、予算は有限だ」という現実を常に意識していました。そのため、「クラウド費用の内訳を分析して把握し、お客様に説明責任を果たすこと」は、お客様の事業成長を支える重要な責務だと考えています。
この考えは、自社サービスにおいても同様に重要です。コストの内訳を説明できなければ、事業環境の変化によるコスト削減の波が来たときに、その価値を正しく示すことが難しくなり削減の対象となってしまうからです。
ContractSに入社して感じたのは、プロダクト開発のスピードが最優先される文化の中で、インフラを見るSREである我々の"コストに対する意識が薄い"ということでした。
もちろん、それは成長するSaaS企業にとって健全な姿の一面でもありますが、MSP出身の自分には、それが「大きな改善のチャンス」であり、チームとして「伸ばすべき能力」だと感じられました。
この記事では、そんな「コスト意識が薄い」状態から、チームでコスト分析と最適化を当たり前にするようになり、Amazon Q Developerという強力なアシスタントを得て分析業務を劇的に効率化した道のりとこれからについてご紹介します。 同じような課題を抱えるSREや開発チームの皆さんにとって、少しでもヒントになれば嬉しいです。
コスト分析の「泥臭い現実」
SaaSサービスにとって、クラウドインフラの費用は当然かかる経費です。でも、当時の自分たちは「この費用って、本当に"正常"なの？」と聞かれても、自信を持って「はい！」とは言えない状態でした。
コストの内訳はよく把握できておらず、まるで"闇鍋状態"でした。これでは、急なコスト増の原因を探ったり、新しい機能が将来のコストにどう影響するかを予測したりすることができません。
この"ぼんやりと"した状態をなんとかしようと、手動での現状分析から始めました。
チームで週次でレポートを書く習慣があったので、まずはそこにコスト分析の結果を載せて、確認するようにしました。これだけで、急なコスト増には気づけるようにはなりました。
一方、月次のコスト分析は時間をかけ、AWS Cost Explorerの画面を見ながら、毎月スプレッドシートに数値を貼り変化の大きい項目をチェックし分析するという泥臭い作業でした。目的は、日々変わるインフラコストが健全な状態かを判断して、先行きを予測することです。しかしこれに毎月2〜3時間もかかっていて、まさに「トイル*1」であると感じました。また作成した資料やシートもあまり見られることがなく「この作業や資料は本当に意味があるのか？」と自問自答することもありました。
この泥臭い作業があったからこそ、「ツールに頼ろう...」とAmazon Q Developerに向かう大きなきっかけとなりました。
Amazon Q Developerによるコスト分析革命
月次のコスト分析はすっかり「トイル」になっていて、半分意地で続けているような状態。もっと楽にしたいなと感じていました。そこで、分析プロセスを自動化できないか検討し始めました。
導入のきっかけ
ContractSの開発部では今年の4月にAmazon Q Developerが正式に使えるようになりました。
ContractSではクラウドにAWSをメインで使っているので、これは大きなことでした。早速、自分はAmazon Q CLIを導入して日々の運用業務のアシスタントとしてQを使い始めました。感覚としては運用作業やAWSリソースの調査で非常に親和性が高いと感じました。自社の環境について質問を投げかけると、まるで専属のAWSサポートエンジニアのように、的確な答えを返してくれます。この「AWSに関する知識の深さ」は、他のAIサービスにはない大きな魅力でした。
使っていくうちに手作業の分析に効率化を求めていたので、Amazon Q Developerは「求めていた答え」でした。「この能力、コスト分析に絶対使える」と確信して、初めはコスト分析のアシスタントとして使い、その中でさらに手応えを感じチームでAI利用実績として良い機会だと思い本格的なツール開発に乗り出しました。
分析プロセスの全体像
そこで、思い切って自作のCLIツール開発に踏み切りました。技術スタックには、AWS Cost Explorer APIを叩くための公式SDK（AWS SDK for Go）が充実しており、かつシングルバイナリを生成できて配布もしやすいGo言語を選択。ここでもAmazon Q Developerと対話しながら実装を進めました。
こうして完成したのが、コスト分析からレポート生成までを行うCLIツールです。Amazon Q Developerには、その心臓部である「分析エンジン」として活躍してもらっています。
Cost Explorerから取得したデータをツールで適切に整形して、Amazon Q Developerに分析を依頼してレポートを作成します。社内でのドキュメントツールはNotionなので、チームの週次レポートにサクッとインポートできるHTML形式での出力もできるようにしました。（Markdownもあるという突っ込みもございますが、出力したMarkdownでインポートがうまくいかなかったのでHTML形式にしています。）
AI分析の心臓部：プロンプトエンジニアリング
コアとなる部分はAmazon Q Developerに渡すプロンプトです。AIと何度も対話しながら試行錯誤した結果、以下のようなプロンプトに落ち着きました。
【プロンプト例】
あなたは優秀なAWSコスト分析の専門家です。以下のAWSコストデータを分析し、日本語で詳細なレポートを作成してください。
## 分析の観点
1. **コスト傾向の分析**
- 前期間との比較（該当する場合）
- 増減の要因分析
- 異常値の検出
2. **サービス別分析**
- 高コストサービスの特定
- 使用パターンの分析
- 最適化の余地
3. **予測分析**
- 月末予測（週次分析の場合）
- トレンド分析
4. **推奨事項**
- 具体的なコスト削減案
- リソース最適化の提案
- 予算管理の改善点
## 出力形式
以下の構造で出力してください：
### 📊 総コスト変化分析:
- コスト変化の概要
- 日本円での影響額
### 🔍 サービス別変化分析:
- 主要な変化があったサービス
- 変化の要因
### 💡 主要コスト要因:
- 高コストサービスの分析
- コスト構成の特徴
### 🎯 推奨事項:
- 具体的なアクションプラン
- 優先順位付きの改善提案
## 重要な指示
- 簡潔で分かりやすい日本語で記述
- 数値は提供されたデータを正確に使用
- 具体的で実行可能な推奨事項を提供
- ビジネスインパクトを考慮した分析
## データ分析対象
{COST_DATA} # AWS Cost Explorer APIで取得して整形したデータ
上記データを基に、包括的なコスト分析レポートを作成してください。
このプロンプトのポイントは、テンプレートとして容易に修正できるようにし、さらに使い回せるようにしつつ、「役割」「ルール」「出力フォーマット」をきっちり指定してあげることです。こうすることで、Amazon Q Developerは毎回安定したレポートを出力してくれるようになりました。
月次分析が「3時間」から「10分」へ
そして、このAmazon Q Developerを使ったレポート作成が本格的に稼働し始めたのは、この記事を書いている今月（2025年8月）からです。
結果は、使い始めた初月から劇的に効果を感じました。 これまで時間がかかっていた週次と月次のコスト分析とレポート作成が、コマンド一つで数分で完了するようになりました。
実際の分析結果
以下は、実際にツールを実行した結果です（機密情報は秘匿済み）：
時間が短縮できたのはもちろんですが、それ以上に価値があったのは、これまで以上にAmazon Q Developerによって分析がしっかりできているという印象でした。
AI導入前の地道な取り組み
もちろん、ツールを導入して終わりというわけでもなく、そこに至るまでにはチームの意識を変えるための取り組みと挫折がありました。
第一歩：まずは「見える化」と「小さな成功体験」
- 現状分析の開始: 誰が見ても「これ使ってないよね？」というAWSアカウントなど、分かりやすいところから手をつけて、影響がないことを確認してサクッと削除しました。小さな一歩でしたが、目に見えてコストが減ったのは、チームのモチベーションアップに繋がりました。
- 週次でのコストの確認: 2023年の8月頃から、週次でチーム全員でコストを見る時間を設けました。コストを「自分たちのこと」として捉える文化を作り始めました。
第二歩：地道な最適化と、見えてきた「文化の壁」
週次資料の読み合わせを行い地道なコスト最適化をコツコツと積み重ねていきました。
ここで大事だったのが、自分たちの目的意識です。チームには施策をやった後にそれっきりでその後の効果測定をあまりしない、という悪いクセがありました。なので、今回は「ただコストを削減する」ことを目的にしない、と強く意識しました。
自分たちが目指したのは、必要なリソースに必要なだけのコストがかけられている「健全な状態」を作ることです。
この考え方をベースに、一つひとつのリソースに対して、「削る」のではなく、「これって、ビジネス価値に見合ってるんだっけ？」と問いかけながら、見直しを進めました。
- インスタンスタイプの見直し: EC2インスタンスや開発環境のECSインスタンスなど、明らかにオーバースペックなリソースのサイズを小さくしました。
- ログの保存期間の変更: 本番環境外のログの保存期間の見直しを行いました。
- リザーブドインスタンスの購入: Amazon AuroraやElastiCacheなど、使い続けるサービスはRIを購入しコストを抑えました。
- リソースの最適化: 各環境のリソース使用状況を分析して、CPUやメモリの割り当て、インスタンスの台数などを最適化しました。
こうした活動を通じて、チームのコストに対する意識は確実に上がっていきました。ただ文化として根付かせ醸成することの難しさという壁にもぶつかりました。
週次のコスト確認会は、結局自分が一人で分析して報告することが多く、半ば意地で続けている状態でした。他のメンバーからすると、なかなか「自分ごと」として捉えにくい状況でした。
自分自身、プログラマーの美徳である怠惰と短気、そしてそこそこの好奇心で仕事をしているエンジニアなので、この状況に「やり方を変えよう！」とサクッと決心しました。
「全員でコスト分析のプロになる」という理想を追いかけるのはやめて、「AIに分析させて、誰でも簡単・スピーディにコスト状況を把握できる仕組み」を自動化で作る方が、よっぽど現実的だと考えました。もちろんメインはAWSのコスト分析なので、Amazon Q Developerが適任です。
人の意識を変えることの難しさ、その限界を認めたからこそ、AIという強力なパートナーに舵を切る決断ができたのだと思います。
今後の展望
Amazon Q Developerを使ってコスト分析を行うことはできました。またこの利用の勢いをそのままに、アラートの分析やSRE向けのコードレビューなども作成しています。 ただ、コスト分析でもそうですがまだ運用作業での「トイル」は多く自動化できていないという課題は残っています。それらを含めて今後の展望になります。
n8nやActivepiecesによるワークフローの完全自動化とAIOpsへの発展
現在は手動でCLIツールを実行していますが、将来的にはn8nのようなワークフローエンジンを使って、レポート生成から通知までを全て自動化したいと考えています。SREとしてより一層トイルを減らしていきたいです。さらに、今回のコスト分析自動化は、より大きなAIOpsの取り組みの一部として自分の中では位置づけています。コスト分析に加えて、異常検知の自動化、インシデント対応の支援、キャパシティプランニングなど、AIを活用した運用自動化を段階的に拡大していく予定です。これにより、従来の「人が判断してツールが実行する」運用から、「AIが分析・提案してワークフローが自動実行する」次世代の運用スタイルへの移行を目指しています。
NewRelicとAIエージェントを組み合わせたサービスレベルを考慮した最適化
ContractSでは2025年Q1末にNewRelicを導入して観測性が向上しました。これにより、CPU使用率、メモリ使用量、レスポンス時間、エラー率などの詳細なメトリクスが取得できるようになりました。これらのデータをAIエージェントに分析させて、サービスレベルを維持しながらリソース最適化の提案を受ける仕組みを検討しています。例えば「このインスタンス・タスクサイズは過去30日間のCPU使用率が平均15%だが、レスポンス時間のP99が目標の200ms以内を維持できているため、より小さなインスタンスタイプに変更可能」といった、サービス品質とコストのバランスを考慮した最適化提案をAIに生成してもらい、真のデータドリブンな運用を実現したいと考えています。
まとめ
この記事では、「コスト意識が薄い」状態だったSREチームが、文化づくりでは解決できなかった課題を、Amazon Q Developerを活用したツール化によって克服し、コスト分析を継続可能にした道のりを紹介しました。
大事なのは、チームの文化づくりと効率的なツールの活用、この両方をうまく組み合わせることなのだと実感しています。
またAIエージェントの進歩によって頭の中で浮かんだものをすぐにプロトタイプが作れるようになったことはとても大きいです。自分たちのチームでは「課題設定・分析から仮説検証までを自律的に行える状態」を目標に掲げています。AIエージェントに的確な指示を出すためにも、この能力は今後ますます重要になると個人的に感じています。
この記事が、同じようなことで悩んでいる誰かの助けになれば嬉しいです。ここまで読んでいただきありがとうございました。
参考にした資料や書籍
- サイト信頼性エンジニアリングとAmazon Web Services / SRE and AWS
- コスト最適化の柱 - AWS Well-Architected フレームワーク
- システム運用アンチパターン
他社のコスト削減の取り組みの記事を多々(感謝！)
*1:「トイル」とは、繰り返し発生する、自動化できるはずの「面倒な手作業」 のこと
