Claude Code でコスト削減 ── AI の主戦場は「実装」より「課題発見」だった

Claude Code のような AI コーディングエージェントは、つい「コードを書かせる道具」として見てしまいます。
でも SRE 業務でコスト削減に取り組んでみて気づいたのは、AI の費用対効果が一番高いのは「課題発見」フェーズだということでした。

「どこにコスト削減の余地があるか」を網羅的に探させる ── ここに AI を当てると、
これまで人手では割に合わず放置されていた領域が、一気に着手可能になります。

従来のコスト削減はなぜ進まないのか

手作業でのコスト削減調査は、だいたいこういう流れになります。

1. Cost Explorer を開いてサービス別コストを目視確認
2. 気になるサービスを 1 つずつ深掘り（Usage Type 別の内訳を手動確認）
3. メトリクスツールで使用率を確認（別タブでダッシュボードを見比べ）
4. Terraform コードを読む（該当リポジトリを clone して設定確認）
5. 調査結果をまとめて Issue を手書き

これを 1 アカウントやるのに半日〜1 日。アカウントが数十あれば、全アカウントの網羅調査は事実上不可能です。

結果、何が起きるか。
「月数十ドル程度の最適化」は、調査コストの方が高くついて放置されるんですね。
費用対効果に見合わないので、誰も手を出さない領域が積み上がっていきます。

AI を「課題発見器」として使う

そこで、コスト調査を Claude Code のカスタムコマンドに落としました。
アカウントを指定すると、以下を自動で回します。

① 対象サービス情報の読み込み
② Cost Explorer API で 3 段階の深掘り
     Level 1: サービス別コスト    → 何が高いか
     Level 2: Usage Type 別コスト → コストの構成要素は何か
     Level 3: 根本原因の特定       → なぜ高いか / どう減らすか
③ メトリクス（Datadog 等）でリソース使用率の実態確認
④ Terraform コードを読み、現在の設定と突き合わせ
⑤ 既存 Issue（却下済み含む）との重複チェック
⑥ コスト削減提案の一覧を提示
⑦ 人間が承認したものだけ Issue 化

3 段階深掘りが重要なのは、Level 1 だけでは「何が高いか」しか分からないからです。
Usage Type（Level 2）まで割って、根本原因（Level 3）まで辿って、初めて具体的なアクションになります。

これにより、1 アカウントの調査が半日〜1 日 → 15〜30 分になりました。

項目	従来（手作業）	Claude Code 活用後
1 アカウントの調査時間	半日〜1 日	15〜30 分
調査の深さ	サービス別 + 1〜2 個の深掘り	全サービス → 全 Usage Type → 根本原因
成果物	メモ or なし	構造化された Issue
対象アカウント数	主要数件のみ	全主要アカウント

今まで放置されていた小規模な最適化に、初めて手が届くようになったのが一番の変化でした。
月数十ドルの施策でも、数分で分析〜起票まで終わるなら、やった方が得です。

Issue をハブにする ── 却下理由も残す

このワークフローのもう一つの肝は、調査結果を Issue として構造化して残すことです。

各 Issue には「現状コスト・提案内容・削減予想額・副作用/リスク」を網羅的に書かせます。
そして大事なのが、却下した場合も理由を Issue に残すこと。

コスト削減は一度きりの活動ではなく、四半期ごとに回します。
却下理由が残っていれば、次回の調査で同じ提案を繰り返さずに済む。
「なぜこの変更をしたのか / なぜやらなかったのか」が、コードと同じ場所に蓄積されていきます。

人間はどこにいたか

ここを誤解されたくないのですが、全部を AI に丸投げできたわけではありません。
むしろ、人間（SRE）の判断が不可欠な場面は多く残りました。

人間がジャッジした部分	例
Go / No Go 判断	冗長構成を 1 つに減らせるか？（可用性リスク vs コスト）
副作用の許容判断	メモリを半分に減らして OOM が起きないか？
組織的な意思決定	あるサービスの撤廃 → 利用者への事前確認
優先度付け	多数の Issue のうち、どれから着手するか
却下判断	技術的には正しいが、運用上やらない

なぜ人間が必要かというと、AI には見えない文脈があるからです。

• インフラ全体の文脈：「この冗長構成は実は DR の一部」といった暗黙知
• 過去の障害履歴：「以前ここのメモリを削ったら OOM が頻発した」という経験則
• ビジネス影響：「このサービスは来月大規模キャンペーンを控えている」

体感としては、AI が調査・分析・実装の 8 割を担い、人間は判断・意思決定の 2 割に集中する。
この分業が一番効率的でした。
逆に言えば、インフラ全体を分かっている人間がジャッジ役として高速に捌けるからこそ、AI の調査速度が活きます。

学んだこと

ワークフロー全体を振り返ると、AI が活きたのは実装だけではありませんでした。

1. 課題発見:  AI がコストデータを網羅分析 → 削減余地を特定   ★ここが一番効いた
2. 調査・深掘り: AI が多段階分析 → 根本原因を特定
3. 提案作成:  AI が Issue として構造化 → 判断材料を整理
4. 判断:     人間が Go / No Go を決定
5. 実装:     AI が Terraform を修正 → PR を作成
6. 横断展開:  AI が複数リポジトリへ一斉適用

実装（5）は全体の一部にすぎません。
課題発見・調査こそ、AI 活用のインパクトが最も大きい領域でした。

そしてもう一つ。カスタムコマンドの設計が成否を分けます。
3 段階の深掘り、既存 Issue との重複チェック、人間の承認フロー ── この設計があってこそ、出力が使える品質になりました。
コマンドを設計できる人間がいなければ、この成果は出なかったと思います。

まとめ

• AI コーディングエージェントの主戦場は「実装」だけではなく、「課題発見」にこそ価値がある
• 費用対効果に見合わず放置されていた小規模最適化が、AI の調査速度で着手可能になる
• コスト分析は 3 段階深掘りでアクションに落とし、Issue に却下理由まで残す
• AI は 8 割（調査・分析・実装）、人間は 2 割（判断・意思決定）の分業が効率的
• 成否を分けるのは カスタムコマンドの設計

「AI にコードを書かせる」の一歩手前、「AI に課題を見つけさせる」に視点をずらすと、SRE 業務での活用範囲はまだまだ広がります。