Claude CodeでInfracostを使い、PRのクラウド費用を下げる手順

Infracostは、Terraformなどのコードからクラウド費用を見積もるツールです。その結果をClaude Codeに読ませると、「高い順に原因を挙げ、構成を直し、直した後の月額を測り直す」までを一つの会話で回せます。

この記事では、現行のInfracost CLIでその流れを作る手順を説明します。Claude側には、実行してよいコマンドの範囲と、費用を削るときの守り方を決めておきます。

先に知っておく点: 現行CLIはscanとinspectが中心

古い解説では infracost breakdown や infracost diff が出てきます。現行のドキュメントでは、CLIのコマンド一覧に並ぶ解析系は scan、inspect、price の3つです。インストール手順のバージョン例は2.18.2でした。

scan の結果はローカルにキャッシュされ、以降の inspect は即座に返ります。この性質がClaude Codeとの相性の核です。重い見積もりは1回で済み、問い直しは安く済みます。

旧バージョンの breakdown の出力形式を前提にした手順は、そのままでは動かない可能性があります。手元のバージョンは infracost --version で確かめてください。

準備: インストールと認証

Homebrewなら次の2行です。初回は infracost setup が、無料のAPIキーの取得からエージェント用スキルの登録、CI連携までを案内します。

brew install infracost
infracost --version
infracost setup

公式は、クラウドの認証情報やシークレットはAPIに送られず、IaCの状態や実リソースも変更しないと説明しています。コードの解析はローカルで行われます。

Claude Code用のスキルを入れる

Infracostはエージェント向けのスキルを配布しています。Claude Codeでは次の2コマンドでマーケットプレイスを追加し、プラグインを入れます。入れたら再起動します。

claude plugin marketplace add infracost/agent-skills
claude plugin install infracost@infracost

入れた後は /infracost:<skill> のスラッシュコマンドで呼べるほか、インフラの費用に関する質問でも自動で使われます。スキルを入れずにCLIだけで進める方法もあり、以降の手順はCLIだけで成り立つように書きます。

手順1: 高い順に原因リソースを出す

最初にscan結果をJSONで保存します。--json は結果をそのままファイルへ出す指定です。

mkdir -p .cost
infracost scan ./terraform --json > .cost/before.json
infracost inspect --file .cost/before.json --top 10
infracost inspect --file .cost/before.json --summary --json

--top N は月額の高い順にN件、--summary は合計と節約見込み、失敗したポリシー数を返します。公式の出力例では、要約JSONに monthly_cost、monthly_savings、failing_policies が出ます(例は公式サンプルの数値で、手元の結果ではありません)。

Claude Codeに渡すときは、生のJSONを貼らず --llm を付けます。トークン消費を抑える形式として用意されたフラグです。

.cost/before.json を元に、月額の高い順に5件の原因リソースを挙げてください。
各リソースについて、Terraformのどのファイルのどの属性が費用を決めているか、
変えられる選択肢は何か、変えたときに失うものは何かを分けて書いてください。
まだコードは変更しないでください。

「変えたときに失うもの」を分けて書かせるのが要点です。費用の数字には、可用性や性能の情報が入っていません。そこを埋めるのは人の判断なので、まず分析だけを出させ、直す段階を別に踏みます。

手順2: 実行してよいコマンドを絞る

Claude Codeが叩くのは、infracost scan と infracost inspect の2種類があれば足ります。許可ルールは、サブコマンドまでを書いて末尾に * を付ける形が公式の書き方です。

{
  "permissions": {
    "allow": [
      "Bash(infracost scan *)",
      "Bash(infracost inspect *)",
      "Bash(terraform fmt *)",
      "Bash(terraform validate)"
    ],
    "deny": [
      "Bash(terraform apply *)",
      "Bash(terraform destroy *)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

infracost auth や infracost setup はあえて許可していません。認証はCI側のトークンか人の操作に任せる設計です。terraform plan をClaudeに実行させるかどうかは、plan時にクラウドへ問い合わせる構成かで変わります。判断の材料はClaude CodeでTerraformのコードを書く手順にまとめています。

手順3: 費用を削るときの規約をCLAUDE.mdに置く

費用削減の依頼で起きやすい失敗は、数字だけを追って構成を壊すことです。リポジトリの CLAUDE.md に、次のような規約を置いておきます。

## クラウド費用の見直し
- 変更前に `infracost scan --json` を `.cost/before.json` に保存する
- 変更後に同じコマンドで `.cost/after.json` を作り、monthly_cost の差を報告する
- 本番環境のインスタンスタイプ・台数・リージョンは、提案のみで変更しない
- 冗長構成(AZごとのNAT Gateway、マルチAZのDBなど)を減らす案は、
  可用性への影響を書いたうえで、別コミットに分ける
- 費用が下がったことを理由に、タグ・暗号化・バックアップ設定を外さない

最後の1行は見落とされがちです。費用ポリシーとタグ付けポリシーは同じscanで評価されるため、タグを消すとコストの数字が良くなる一方で、ポリシー違反が増える形になります。failing_policies を前後で比べれば、この種の悪化を検出できます。

手順4: 直して、前後を数字で比べる

分析が済んだら、直す対象を人が選んで依頼します。例として、開発環境のインスタンスタイプを下げ、NAT Gatewayを3台から1台にする案を想定します。

開発環境(environments/dev)だけを対象に、手順1で挙がった
aws_instance と NAT Gateway の見直しを実装してください。
終わったら infracost scan で .cost/after.json を作り、
inspect --summary の monthly_cost と failing_policies を
before と after で並べた表にして報告してください。

前後の比較は、Claudeの報告に頼らず手元でも確かめられます。

infracost scan ./terraform --json > .cost/after.json
infracost inspect --file .cost/before.json --summary --json > .cost/before-summary.json
infracost inspect --file .cost/after.json --summary --json > .cost/after-summary.json
jq -r '.monthly_cost' .cost/before-summary.json .cost/after-summary.json

差が想定より小さいときは、直したリソースが料金の大半を占めていなかった可能性があります。逆に想定より大きいときは、リソースを減らしすぎていないかを差分で確認します。NAT Gatewayの台数を減らす案は、費用の面では効果が出やすい一方で、AZ障害時の通信経路に関わります。数字が良くなったことと、その構成で良いことは別の判断です。

セキュリティ設定を機械的に検査したい場合は、Claude CodeでCheckovを使いTerraformをスキャンする手順の「握りつぶさせない」設定と併用できます。

見積もりが出ないものを知っておく

Infracostは既定でTerraformのHCLを直接解析します。この方式では、データソースや他のリソースの出力のように、apply まで値が決まらない属性の費用を見積もれません。

その場合は、plan JSONを渡します。公式の手順は次のとおりで、OpenTofuも同じ形式として扱われます。

terraform plan -out tfplan.binary
terraform show -json tfplan.binary > plan.json
infracost scan plan.json

AWS CDKは、CLIが cdk synth を自動では実行しません。合成時にAWSへのネットワーク呼び出しやフックの実行が起こりうるためで、手元で cdk synth を実行してから、出力されたCloudFormationを読ませます。

Claudeに任せる場合は、plan JSONを生成するコマンドを許可するかどうかが分かれ目になります。terraform plan はバックエンドの状態を読むため、権限が広がります。許可するなら読み取り専用の認証情報を使う環境に限る、という運用が無難です。

PRで自動化する: 二つのワークフローの役割

PRごとの費用差分は、Infracost側のワークフローが出します。公式のGitHub Actions手順は、ベースとヘッドの2つのチェックアウトを infracost-ci diff に渡す構成で、PRコメントの投稿と更新までを行います。

name: Infracost
on: [pull_request]
jobs:
  infracost:
    runs-on: ubuntu-latest
    container: ghcr.io/infracost/ci:2
    permissions:
      contents: read
      pull-requests: write
    env:
      INFRACOST_CLI_AUTHENTICATION_TOKEN: ${{ secrets.INFRACOST_CLI_AUTHENTICATION_TOKEN }}
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.base.sha }}
          path: base
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          path: head
      - run: infracost-ci diff --base-path base --head-path head

ガードレールやポリシーが止める設定のときは、コメントが先に投稿され、その後 diff が失敗して赤いチェックになります。ただし赤いチェックだけではマージは止まりません。止めるにはブランチのルールセットで、このジョブを必須のステータスチェックに加えます。

Claude Code側は、@claude へのメンションで動く対話モードが使えます。PRコメントに「Infracostの指摘のうち上位2件を直して」と書くと、Claudeが同じブランチで修正に取りかかります。ここで押さえる点は3つです。

• Claudeのワークフローには anthropic_api_key などの認証が別に要る
• トリガーしたユーザーに書き込み権限が必要で、ボットは allowed_bots に載せない限り弾かれる
• Claude側のジョブでInfracostを実行させるなら、CLIの導入と INFRACOST_CLI_AUTHENTICATION_TOKEN の受け渡しを、そのジョブに足す必要がある

三つ目は、二つの公式手順を組み合わせた構成です。公式のどちらのページにも、この組み合わせの完成形は載っていません。小さなリポジトリで試してから広げてください。

Claudeの実行コストも見積もりに入れる

自動化は、Claude自身の費用を増やします。Claude Code Actionは、GitHub Actionsの分数とAPIトークンの両方を消費します。公式が挙げる抑え方は、claude_args の --max-turns、ワークフロー全体のタイムアウト、GitHubの並行実行制御です。

数千円の削減のためにPRごとにClaudeを走らせるのは割に合わない場合があります。「月額が一定額を超えたPRだけで動かす」などの条件を、Infracost側のしきい値(ガードレール)と合わせて決めるのが現実的です。レビュー側の費用を月額上限で止める考え方はClaude Code Reviewの費用を見積もり、月額上限で止める方法が参考になります。

つまずいたとき

• scan が資源を拾わない: 対象は認識できるIaCのディレクトリである必要があります。複数のプロジェクトやワークスペースがあるときは、infracost.yml に書いてまとめて走査します。
• PRコメントが出ない: pull-requests: write が欠けると、見積もりは走ってもコメントだけが失敗します。GITHUB_TOKEN を env に渡していないと、diff は走査の前に終了コード1で止まります。
• @claude に反応しない: コメントの投稿者に書き込み権限があるか、ワークフローの if がメンション文字列を見ているかを確かめます。
• 数字が合わない: --org を付けると別の組織のポリシーと価格で実行されます。前後の比較は同じ組織・同じ通貨(--currency)で揃えます。

AWS向けにClaude側から構成案と見積もりを出させる方法は、Claude CodeでDeploy on AWSプラグインを使うで扱っています。そちらは構成の提案が起点で、この記事は既存のコードの費用を直す側です。

費用の数字を判断に使うときの線引き

Infracostの数字は、コードに書かれた量と単価から出る見積もりです。実際の請求は、通信量やリクエスト数のような利用量で変わります。利用量はコードに現れないため、見積もりに反映するには利用量の設定を足す必要があります。

だからこそ、Claudeに「安くして」とだけ頼むのは避けます。何を固定し、どこまで変えてよいかを、CLAUDE.md と権限で先に決めます。そのうえで、前後の数字を機械的に比べ、構成の判断は人が行います。この分担なら、Claudeは候補の洗い出しと実装の手間を引き受け、費用と引き換えにしてよいものの線引きは人の手に残ります。