Claude Code×クラウドCLI(AWS・Cloudflare・Vercel)【2026】ログ調査・障害切り分け・コスト点検をAIエージェントで
クラウドの運用は「ログを探す」「数字を集計する」「設定の差分を読む」といった、読む作業の比重が大きい仕事です。そして読む作業は、AIエージェントがもっとも得意とする領域でもあります。一方で、クラウドのCLIは1行で本番のデータベースやサーバーを消せる道具です。本記事では、Claude CodeにAWS CLI・Cloudflareの wrangler・Vercel CLIを使わせてログ調査・障害の一次切り分け・コスト点検・リソース棚卸し・Terraformのplan解説を任せる方法を、「読み取りは任せる、変更は人が実行する」という安全設計とセットで解説します。
- AIに向くのはログ調査と原因仮説、コストの内訳点検、未使用リソースの棚卸しレポート、terraform planの解説。どれも「読んでまとめる」仕事
- 安全の土台は認証情報そのものを読み取り専用にすること(
AWS_PROFILE=readonly)。本番の管理者権限はAIの手元に置かない - その上に permissions の deny と PreToolUse hook(exit 2)を重ね、削除・apply・本番デプロイは人が実行。デプロイはstaging(プレビュー)優先
Claude Code×クラウドCLIで何ができるか(5つのユースケース)
Claude Codeはターミナルでコマンドを実行できるので、AWS CLI・wrangler(Cloudflare)・vercel(Vercel)などのCLIがインストール・認証済みなら、それらを使ってクラウドの状態を調べられます。現場で効果が大きいのは次の5つです。
| ユースケース | 主なコマンド | AIの担当 | 人の担当 |
|---|---|---|---|
| ① エラーログ調査と原因仮説 | aws logs tail、Logs Insights、wrangler tail | ログを絞り込み、時系列とパターンから仮説を立てる | 仮説の妥当性判断、対応の決定 |
| ② コストの内訳点検 | aws ce get-cost-and-usage | サービス別・前月比の集計と増加要因の推定 | 削減策の採否 |
| ③ 未使用リソースの棚卸し“レポート” | aws ec2 describe-* 等 | 未アタッチのボリューム等を一覧化し、削除候補を理由付きで提案 | 削除の判断と実行 |
| ④ Terraformの変更案とplan解説 | terraform plan、terraform show -json | .tfの変更案作成、planの差分を日本語で要約・危険箇所の指摘 | terraform apply の実行 |
| ⑤ デプロイ | wrangler pages deploy、vercel deploy | staging/プレビュー環境へのデプロイと確認 | 本番への反映 |
表の右端を見ると分かるとおり、「消す」「適用する」「本番に出す」は一貫して人の担当です。クラウドでの失敗は、アプリのバグと違ってGitで戻せないこと(消えたデータ、止まったサービス、発生した請求)が多いからです。


準備と認証:読み取り専用のプロファイルを分ける
AWS:ReadOnly用のIAMロールとプロファイル
最初にやるべきことは、AIが使う認証情報を、人が普段使う認証情報と分けることです。AWSではIAMで読み取り専用のロールを作り、AWS CLIの「プロファイル」として登録します。
# 人が使う通常のプロファイル(AIには使わせない)
[profile admin]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = ap-northeast-1
# AI用:読み取り専用の権限セット(IAM Identity Center の例)
[profile readonly]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = ClaudeReadOnly
region = ap-northeast-1
[sso-session my-sso]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-northeast-1# 読み取り専用プロファイルでログインし、誰として認証されているか確認
aws sso login --profile readonly
AWS_PROFILE=readonly aws sts get-caller-identity
{ "UserId": "...", "Account": "123456789012", "Arn": "arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_ClaudeReadOnly_.../..." }IAM Identity Center(SSO)を使うと、長期のアクセスキーを発行せずに一時的な認証情報で済むため、キーの漏えいリスクを下げられます。アクセスキー方式の場合は、~/.aws/credentials をClaude Codeの読み取り対象から外しておきます(後述)。
ReadOnlyAccess と ViewOnlyAccess の違い(ここが判断ポイント)
| AWS管理ポリシー | 見られる範囲 | 向いているケース |
|---|---|---|
| ReadOnlyAccess | ほぼ全サービスの読み取り。S3のオブジェクト本体など、データの中身も読める | 検証環境・データに機微情報がないアカウント |
| ViewOnlyAccess | 一覧・設定などメタデータ中心。データの中身は基本的に読めない | 本番アカウント。必要なログ閲覧(CloudWatch Logs)やコスト閲覧の権限を個別に追加して使う |
「読み取り専用なら安全」と考えがちですが、読めること自体がリスクになるデータ(顧客情報のエクスポート、Terraformのstateファイルに含まれるパスワード等)もあります。本番アカウントではViewOnlyAccessをベースに、logs:FilterLogEvents・logs:StartQuery などログ調査に必要な権限や、Cost Explorerの閲覧権限(ce:GetCostAndUsage 等)を足していく方が堅実です。ポリシーの正確な中身は更新されることがあるため、執筆時点(2026年9月)の整理として、AWS公式ドキュメントで確認してください。
Cloudflare:スコープを絞ったAPIトークン
wrangler は wrangler login(ブラウザ認証)でも使えますが、この方法は広い権限が付きがちです。AI用には、Cloudflareのダッシュボードで必要な権限だけを持つAPIトークンを作り、環境変数 CLOUDFLARE_API_TOKEN(と CLOUDFLARE_ACCOUNT_ID)で渡します。ログの閲覧とPagesのプレビューデプロイだけなら、対象アカウントに限定し、Workers/Pagesに関係する権限に絞ります(権限名は執筆時点のもの。公式ドキュメントで確認してください)。DNSやゾーン設定の編集権限は付けません。
Vercel:チーム・スコープを限定したトークン
Vercel CLIも同様に、アカウント設定で作成したトークンを VERCEL_TOKEN などで渡せます。トークンの有効範囲(スコープ)を対象チームに限定し、有効期限を設定しておきましょう。
プロジェクト構成
インフラ運用用のリポジトリ(または既存リポジトリの ops/ ディレクトリ)に、次のようなファイルを置きます。
infra-ops/
├── CLAUDE.md # 環境の説明・やってよいこと/いけないこと
├── .claude/
│ ├── settings.json # env(AWS_PROFILE=readonly)・permissions・hooks
│ ├── hooks/
│ │ └── block-destructive.sh # 変更系コマンドを実行前にブロック(exit 2)
│ └── skills/
│ └── cost-review/SKILL.md # 月次コスト点検の手順
├── scripts/
│ ├── cost_by_service.sh # Cost Explorer でサービス別コストを取得
│ ├── aws_unused_report.sh # 未使用リソースの一覧(読み取りのみ)
│ └── tf_plan.sh # terraform plan を実行しテキスト/JSONで保存
├── terraform/
│ ├── staging/ # まずこちらで試す
│ └── production/
├── reports/ # 出力先(.gitignore 済み)
└── tmp/ # ログ等の一時ファイル(.gitignore 済み)集計や一覧取得をスクリプトに固めておく理由は2つあります。数字の計算を決定的にする(AIに毎回クエリを組み立てさせると、期間の指定ミスなどで結果がぶれる)ことと、permissionsで「このスクリプトだけ許可」と書けることです。AIの役割は、スクリプトの結果を読んで解釈・提案することに寄せます。
取得・操作のスクリプト実例
① エラーログ調査:aws logs tail と Logs Insights
まずは直近のエラーをざっと見る用途なら aws logs tail が手軽です。
# 直近1時間の ERROR を含むログを短い形式で表示(Lambda の例)
aws logs tail /aws/lambda/order-api --since 1h \
--filter-pattern "ERROR" --format short > tmp/order-api-errors.log
# 件数の推移を5分単位で見る:CloudWatch Logs Insights(非同期クエリ)
QID=$(aws logs start-query \
--log-group-name /aws/lambda/order-api \
--start-time $(date -d '-3 hours' +%s) --end-time $(date +%s) \
--query-string 'fields @timestamp, @message
| filter @message like /ERROR/
| stats count() as errors by bin(5m)' \
--query queryId --output text)
sleep 5
aws logs get-query-results --query-id "$QID" > tmp/errors-by-5m.jsonAIに原因を考えさせるときは、「いつから増えたか」(時系列)と「どんなエラーか」(メッセージの種類)の両方を渡すのがコツです。「14:05からタイムアウトが急増し、同時刻にデプロイがある」といった相関は、人よりAIの方が速く見つけられます。なお、Logs Insightsはスキャンしたデータ量に応じた課金があるため、期間とロググループは絞って使いましょう。
Cloudflare Workers / Pages のログ:wrangler tail
# Workers のリアルタイムログを、エラーだけ JSON で2分間収集(tail は止めない限り流れ続ける)
timeout 120 npx wrangler tail order-worker --format json --status error \
> tmp/worker-errors.jsonl
# Pages Functions の場合
timeout 120 npx wrangler pages deployment tail --project-name my-site \
--format json > tmp/pages-tail.jsonlwrangler tail はリアルタイムのストリームなので、timeout で区切ってファイルに保存してから読ませます。流しっぱなしにすると、Claude Codeのコマンドが終わらず作業が止まってしまいます。
② コストの内訳点検:aws ce get-cost-and-usage
#!/usr/bin/env bash
# 使い方: scripts/cost_by_service.sh 2026-08-01 2026-09-01(End は含まれない)
set -euo pipefail
START="$1"; END="$2"
mkdir -p reports
aws ce get-cost-and-usage \
--time-period Start="$START",End="$END" \
--granularity MONTHLY \
--metrics UnblendedCost \
--group-by Type=DIMENSION,Key=SERVICE \
--query 'ResultsByTime[].Groups[].{service: Keys[0], usd: Metrics.UnblendedCost.Amount}' \
--output json > "reports/cost_${START}_${END}.json"
echo "saved: reports/cost_${START}_${END}.json"前月分と前々月分の2回実行し、2つのJSONをClaude Codeに読ませて「増加額の大きい順に上位5サービスと、考えられる要因」をまとめさせます。要因の深掘りが必要なら、--group-by Type=DIMENSION,Key=USAGE_TYPE で利用タイプ別に分けると、「データ転送量が増えた」「NATゲートウェイの処理量が増えた」といった粒度まで下りられます。
us-east-1 のエンドポイントで提供されている点にも注意してください。
③ 未使用リソースの棚卸し“レポート”
#!/usr/bin/env bash
# 読み取り(describe)だけで、削除候補になりうるリソースを一覧化する。削除はしない。
set -euo pipefail
OUT="reports/unused_$(date +%Y%m%d).md"
mkdir -p reports
{
echo "## 未アタッチのEBSボリューム"
aws ec2 describe-volumes --filters Name=status,Values=available \
--query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' --output text
echo "## どこにも関連付けられていないElastic IP"
aws ec2 describe-addresses \
--query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' --output text
echo "## 停止中のEC2インスタンス"
aws ec2 describe-instances --filters Name=instance-state-name,Values=stopped \
--query 'Reservations[].Instances[].[InstanceId,InstanceType,Tags[?Key==`Name`]|[0].Value]' \
--output text
echo "## 古い順のスナップショット(先頭30件)"
aws ec2 describe-snapshots --owner-ids self \
--query 'sort_by(Snapshots,&StartTime)[:30].[SnapshotId,VolumeSize,StartTime,Description]' \
--output text
} > "$OUT"
echo "saved: $OUT"このスクリプトは現在のリージョンだけを見ます。複数リージョンを使っている場合は --region を変えてループさせます。Claude Codeにはこのレポートを読ませ、タグ(Owner・Project等)や作成日から「削除してよさそう」「持ち主に確認が必要」「残すべき」の3段階に分類させます。削除のコマンドは、提案としてレポートに書き出すところまでに留めます。
④ Terraform:plan までをAIに、apply は人に
#!/usr/bin/env bash
# 使い方: scripts/tf_plan.sh staging
set -euo pipefail
ENV="$1"
cd "terraform/${ENV}"
terraform init -input=false > /dev/null
terraform plan -input=false -no-color -out=tfplan > "../../tmp/plan_${ENV}.txt"
terraform show -json tfplan > "../../tmp/plan_${ENV}.json"
# 削除・置き換え(delete を含む)になるリソースだけ抜き出す
jq -r '.resource_changes[] | select(.change.actions | index("delete")) | .address' \
"../../tmp/plan_${ENV}.json"Claude Codeには .tf ファイルの変更案を書かせ、このスクリプトでplanを取り、「作成・変更・削除の件数」「置き換え(destroy→create)になるリソース」「ダウンタイムが起きうる変更」を日本語で要約させます。planのテキストは長く、置き換えの記号(-/+)を見落としがちなので、AIの要約と、削除対象を機械的に抜き出すjqの二段構えにしています。
- S3+ロック用テーブルのリモートstateを使っている場合、planはロックの取得(書き込み)を試みます。読み取り専用のロールでは失敗するため、ロックを取らない
-lock=falseを付けるか、ロック操作だけ許可したロールを用意します。前者は他の人のapplyと同時に走ると古い状態でplanする可能性がある、というトレードオフがあります - stateファイルには機密情報(DBのパスワード等)が平文で入ることがあります。stateを置いたS3バケットを読めるロールをAIに渡すかは慎重に判断し、ローカルの
*.tfstateはClaude Codeの読み取り対象から外します
⑤ デプロイ:まずはプレビュー(staging)へ
# Cloudflare Pages:本番ブランチ以外の --branch を指定するとプレビューとしてデプロイされる
npx wrangler pages deploy ./public --project-name my-site --branch staging
# Vercel:--prod を付けなければプレビューデプロイ(本番に出すのは人)
vercel deploy
# Vercel のデプロイ一覧・ログ確認
vercel ls
vercel logs <デプロイURL>プレビューURLが返ってきたら、Claude Codeに主要ページの表示やエラーを確認させ、問題がなければ人が本番へ反映します。GitHub連携の自動デプロイを使っている場合は、そもそも本番反映の入口を「mainへのマージ」に一本化し、CLIからの本番デプロイは使わないのがシンプルです(GitHub側の設計はClaude Code×GitHubで解説しています)。
CLAUDE.mdの例
インフラ運用では、環境の地図(どのアカウント・プロジェクトが何か)と、やってよいこと・いけないことを明文化しておくのが最重要です。
# インフラ運用ルール(AIエージェント向け)
## 環境
- AWS: 123456789012(本番)/ 210987654321(staging)。リージョンは ap-northeast-1
- 使ってよい AWS プロファイルは readonly のみ(settings.json で AWS_PROFILE=readonly を設定済み)
- Cloudflare: Pages プロジェクト my-site(本番ブランチ main)、Worker order-worker
- Terraform: terraform/staging, terraform/production
## やってよいこと
- ログ・メトリクス・設定・コストの読み取り(scripts/ 配下のスクリプトを優先して使う)
- .tf ファイルの変更案の作成と scripts/tf_plan.sh の実行
- Cloudflare Pages への --branch staging でのデプロイ
## やってはいけないこと(必要なら「人が実行するコマンド」として提案だけする)
- リソースの削除・停止・再起動・設定変更(aws の delete / terminate / stop / put / update 系)
- terraform apply / destroy、state の操作
- 本番へのデプロイ(Pages の main、vercel --prod)
- readonly 以外のプロファイルの使用、認証情報ファイルの読み取り
## 障害調査の進め方
1. まず「いつから・どこで・何が」起きているかをログで確認し、事実と推測を分けて書く
2. 原因の仮説は3つ以内、根拠となるログ行を引用する
3. 対応案はリスクの低い順に並べ、実行コマンドは人向けに提示する
4. 結果は reports/incident_YYYYMMDD.md にまとめる「事実と推測を分けて書く」「根拠となるログ行を引用する」という指示は、障害対応で特に効きます。AIのもっともらしい説明を、ログという証拠で人がすぐ検証できる形にするためです。
permissions と hooks で「壊せない」ようにする
.claude/settings.json
env でAWSのプロファイルを固定し、permissions で読み取り系を許可、変更系を拒否します。deny は allow より優先されます。
{
"env": {
"AWS_PROFILE": "readonly"
},
"permissions": {
"allow": [
"Bash(aws sts get-caller-identity:*)",
"Bash(aws logs tail:*)",
"Bash(aws logs start-query:*)",
"Bash(aws logs get-query-results:*)",
"Bash(aws logs describe-log-groups:*)",
"Bash(scripts/cost_by_service.sh:*)",
"Bash(scripts/aws_unused_report.sh:*)",
"Bash(scripts/tf_plan.sh:*)",
"Bash(terraform fmt:*)",
"Bash(terraform validate:*)",
"Bash(timeout 120 npx wrangler tail:*)",
"Bash(npx wrangler whoami)",
"Bash(vercel ls:*)",
"Bash(vercel logs:*)",
"Read(./reports/**)",
"Read(./tmp/**)"
],
"ask": [
"Bash(npx wrangler pages deploy:*)",
"Bash(vercel deploy:*)",
"Bash(aws s3 cp:*)"
],
"deny": [
"Bash(aws * delete*:*)",
"Bash(aws * terminate*:*)",
"Bash(aws * remove*:*)",
"Bash(aws s3 rm:*)",
"Bash(aws s3 rb:*)",
"Bash(aws iam:*)",
"Bash(terraform apply:*)",
"Bash(terraform destroy:*)",
"Bash(terraform state:*)",
"Bash(npx wrangler delete:*)",
"Bash(npx wrangler secret:*)",
"Bash(vercel --prod:*)",
"Bash(vercel deploy --prod:*)",
"Bash(vercel remove:*)",
"Bash(vercel env:*)",
"Read(./.env)",
"Read(./.env.*)",
"Read(~/.aws/credentials)",
"Read(**/*.tfstate)",
"Read(**/*.tfvars)"
]
},
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-destructive.sh" }
]
}
]
}
}Bash(aws * delete*:*) のような途中にワイルドカードを含む書き方で、aws ec2 delete-volume や aws rds delete-db-instance など、サービスを問わず削除系のサブコマンドをまとめて拒否できます(ワイルドカードの細かな照合ルールはClaude Codeの公式ドキュメントで確認してください)。
PreToolUse hook:コマンドの中身を検査して exit 2
permissionsの照合は文字列パターンなので、AWS_PROFILE=admin aws ... のように環境変数やオプションでプロファイルを差し替える書き方までは捉えきれません。そこで、実行直前にコマンド全体を検査するhookを重ねます。hookが exit code 2 で終了すると実行はブロックされ、標準エラーの内容がClaudeに返されます。
#!/usr/bin/env bash
# 標準入力の JSON から、実行しようとしているコマンドを取り出す
CMD=$(jq -r '.tool_input.command // ""')
block() { echo "$1" >&2; exit 2; }
# 1) AWS の変更系オペレーション(削除・作成・変更などの動詞で始まるサブコマンド)
if echo "$CMD" | grep -Eq 'aws[[:space:]]+([^[:space:]]+[[:space:]]+)*(delete|terminate|remove|put|create|update|modify|attach|detach|stop|reboot|run|invoke|rm|rb|mv|sync)[-a-z]*([[:space:]]|$)'; then
block "AWS の変更系操作は実行できません。人が実行するコマンドとして、影響範囲と一緒に提案してください。"
fi
# 2) readonly 以外のプロファイル指定
if echo "$CMD" | grep -Eq '(--profile[[:space:]=]+|AWS_PROFILE=)' && \
! echo "$CMD" | grep -Eq '(--profile[[:space:]=]+|AWS_PROFILE=)readonly([[:space:]]|$)'; then
block "readonly 以外の AWS プロファイルは使えません。"
fi
# 3) Terraform の適用・破棄
if echo "$CMD" | grep -Eq 'terraform[[:space:]]+(apply|destroy)|-auto-approve'; then
block "terraform apply / destroy は人が実行します。plan の要約までにしてください。"
fi
# 4) 本番デプロイ(Pages は staging ブランチのみ許可、Vercel は --prod 禁止)
if echo "$CMD" | grep -Eq 'wrangler[[:space:]]+pages[[:space:]]+deploy' && \
! echo "$CMD" | grep -Eq -- '--branch[[:space:]=]+staging([[:space:]]|$)'; then
block "Pages へのデプロイは --branch staging(プレビュー)のみ許可されています。"
fi
if echo "$CMD" | grep -Eq 'vercel.*--prod'; then
block "Vercel の本番デプロイは人が行います。プレビューで確認してください。"
fi
exit 01)の判定は「aws の後ろに、削除・作成・変更などの動詞で始まる語(delete-volume、terminate-instances 等)があるか」を見ています。aws logs start-query や aws ec2 describe-volumes は通り、aws ec2 terminate-instances や aws lambda invoke は止まります。誤検知で読み取りコマンドが止まった場合も、理由がClaudeに返るので、人に相談する流れになります。
Claude Codeとの対話例
例1:障害の一次切り分け
> 14時ごろから注文APIで 502 が増えているとアラートが来た。order-api(Lambda)と
order-worker(Cloudflare Workers)のログを調べて、原因の仮説を3つ以内で。
事実と推測は分けて、根拠のログ行を引用して。何も変更はしないこと。Claude Codeはおおむね次の順で動きます。
返ってくる報告は、たとえば「事実:14:02以降、Task timed out after 10.00 seconds が5分あたり数件→数十件に増加。同時刻の直前にデプロイの記録あり。推測:①新バージョンでDBクエリが重くなった ②接続数の上限に達した ③外部決済APIの遅延」のような形です。最後に「確認のために人が実行すべきコマンド」(例:直前バージョンへの切り戻し手順)を提案させると、判断から実行までが速くなります。

例2:月次のコスト点検
> 8月と7月のAWSコストをサービス別に比べて、増えた上位5つと考えられる理由をまとめて。
未使用リソースのレポートも作って、削除候補は「確認が必要な人・理由」付きで一覧に。
削除や変更のコマンドは実行しないで、reports/cost_review_202608.md に書いて。Claude Codeは scripts/cost_by_service.sh を2回(7月分・8月分)実行し、差分を集計します。増加の大きいサービスについては利用タイプ別の内訳を追加で確認し、「EC2-Otherの増加は未アタッチのEBSボリュームとスナップショットの蓄積が主因の可能性」のように、コストの数字と棚卸しレポートを突き合わせた考察を書きます。削除の判断は、レポートを受け取った人が持ち主に確認してから行います。
例3:Terraformの変更案とplan解説
> staging の RDS のインスタンスクラスを1段上げる変更案を作って、plan を取って。
置き換え(再作成)やダウンタイムが発生するかを最初に教えて。apply はしないで。.tf を修正し scripts/tf_plan.sh staging を実行したうえで、「変更は in-place の update。ただし適用時にインスタンスの再起動が伴う設定のため、短時間の停止がありうる」といったリスクの説明を先頭に書いたレポートを返します。applyは、人がplanを確認し、メンテナンス時間を決めてから実行します。
MCPサーバーを使う場合
クラウド各社も、AIツールから自社サービスを扱うためのMCPサーバーを公開しています(執筆時点)。AWSはドキュメント検索やコスト分析などの用途別MCPサーバー群をオープンソースで公開しており、Cloudflareもドキュメント・Workers・ログ(オブザーバビリティ)などのリモートMCPサーバーを提供しています。Vercelも同様にMCPサーバーを提供しています。Claude Codeへの登録は共通で、次の形です。
# リモート(HTTP)のMCPサーバー。URLは各社の公式手順のものを使う
claude mcp add --transport http cloudflare-docs <公式のMCPサーバーURL>
# ローカル(stdio)で動くMCPサーバー。AWS_PROFILE は readonly を渡す
claude mcp add aws-cost --env AWS_PROFILE=readonly -- <公式手順の起動コマンド>
# 接続状況の確認
/mcpCLIとMCPの使い分けの判断基準はこうです。ドキュメント検索のように「CLIでは代替しにくい」ものはMCPが便利です。一方、ログ取得やコスト取得のようにCLIで同じことができる操作は、人も同じコマンドで再現・検証でき、permissionsやhookで細かく制御しやすいCLIを優先するのが、当編集部の考え方です。MCPサーバーを使う場合も、渡す認証情報は読み取り専用にし、MCPサーバーが提供するツールの一覧(どれが書き込み系か)を登録前に確認してください。
Skills・ヘッドレス定期実行
月次コスト点検を Skill にする
---
name: cost-review
description: AWSの月次コストをサービス別に前月比較し、増加要因と未使用リソースの削除候補をレポートにまとめる。コスト点検・請求額の確認を頼まれたときに使う。
---
# 月次コスト点検の手順
1. scripts/cost_by_service.sh を「前月」「前々月」の2回実行する(End は月初日=その日を含まない)
2. 増加額の上位5サービスを表にする(金額は小数点2桁、USD)
3. 上位サービスは USAGE_TYPE 別の内訳も確認し、要因の仮説を書く
4. scripts/aws_unused_report.sh を実行し、削除候補を「削除可/要確認/残す」に分類
5. reports/cost_review_YYYYMM.md に保存。削除・変更コマンドは「人が実行する案」として末尾に列挙するだけにするcronで週次・月次に回す
Claude Codeは claude -p で非対話実行でき、--allowedTools で使えるツールを限定できます。cronなどで定期実行し、結果を人が読む形にします。
5 9 2 * * cd /home/ops/infra-ops && AWS_PROFILE=readonly claude -p \
"cost-review の手順で先月分のコスト点検をして、レポートを保存して。" \
--allowedTools "Bash(scripts/cost_by_service.sh:*),Bash(scripts/aws_unused_report.sh:*),Read,Write" \
--output-format json >> logs/cost-review.log 2>&1定期実行では人がその場で承認できないため、--allowedTools で読み取りスクリプトとファイルの読み書きだけに絞るのが前提です。SSOの一時認証情報は期限が切れるため、無人実行には専用の読み取り専用ロールを引き受ける(AssumeRole)構成などが必要になります。完成したレポートをSlackなどに通知したい場合は、開発者シリーズの業務ツール連携の記事も参考にしてください。
注意点・安全設計
本番の管理者権限は、AIの手元に置かない
2025年には、あるSaaS関係者が、AIコーディングサービスのエージェントに本番データベースのデータを削除されたと公表し、サービス提供元がCEO名義で謝罪と再発防止策(開発環境と本番環境の分離など)を表明したと報じられました。エージェントは指示に反して操作してしまうことがありうる——この前提に立つと、対策の中心は「AIに言い聞かせる」ことではなく、そもそも本番を壊せる権限を持たせないことになります。
| 設計原則 | 具体策 | トレードオフ |
|---|---|---|
| 認証情報を読み取り専用に | AWS_PROFILE=readonly、スコープ限定のAPIトークン | AIに頼める作業が「調査・提案」に限られる。それで十分な場面が大半 |
| staging優先 | 変更案・デプロイはまずstaging/プレビューで試す | 環境の維持コスト。本番との差異で見逃す問題もある |
| 変更は人が実行 | AIは「実行するコマンド案」と影響範囲を書き、人がコピーして実行 | 一手間増える。ただし実行前に必ず目を通す機会になる |
| 多層防御 | IAM → permissions deny → PreToolUse hook | 設定の保守が必要。hookの誤検知で作業が止まることがある |
| 記録を残す | CloudTrailで操作を記録、AIのレポートは reports/ に保存 | ログ保管の費用 |
ログに含まれる個人情報・秘密情報
アプリのログには、メールアドレスやリクエスト本文、場合によってはトークンが混ざっていることがあります。ログをAIに読ませる=その内容がAIサービスに送信されるということです。ログ出力の段階でマスキングする、調査対象を必要な期間・ロググループに絞る、社内のデータ取り扱い規程と利用するAIサービスのデータ方針を確認する、といった配慮が必要です。
コストの暴走にも注意
AIが試行錯誤でLogs Insightsのクエリを何十回も流したり、Cost Explorer APIを繰り返し呼んだりすると、それ自体が費用になります。高コストな呼び出しはスクリプトに閉じ込めて回数を管理する、AWS Budgetsで予算アラートを設定しておく、といった対策を併用してください。

自社事例:本サイトの配信基盤
静的サイトをCloudflare Pagesで配信
本サイト「AIエージェント研究所」はHTMLとCSSだけの静的サイトで、GitHubでGit管理し、Cloudflare Pagesで配信しています。
- GitHub連携により、mainに取り込まれた変更をCloudflare Pagesが自動でデプロイします。プルリクエストごとに確認用のプレビューURLも自動で発行されます
- 秘密情報(
.env、*.key、credentials.json等)は.gitignoreでコミット対象から外し、そもそもサイトに持たせていません - 変更はAIエージェントが作業ブランチで行い、PRを人が確認してからマージします。配信基盤の設定変更のような影響の大きい操作ほど、人の確認を挟む流れです
静的サイトはサーバーやデータベースを持たないため、「AIが本番を壊す」余地そのものが小さい構成です。インフラを増やす前に、壊れうる場所を減らすのも立派な安全設計です。運用全体の仕組みは【自社事例】AIエージェントでメディアサイトを運用する仕組みで公開しています。
よくある質問
AWSのReadOnlyAccessをAIに渡せば安全?
リソースを変更・削除される心配はほぼなくなりますが、「何も見られない」わけではありません。ReadOnlyAccessはS3のオブジェクト本体など、データの中身まで読める権限を含みます。個人情報やTerraformのstateファイルを置いたバケットがある場合は、メタデータ中心のViewOnlyAccessをベースに、必要なログ閲覧やコスト閲覧の権限だけを足す方が安全です。
permissionsのdenyだけで危険なコマンドは防げる?
防げません。permissionsのBashルールはコマンド文字列のパターン照合なので、書き方を変えるとすり抜ける余地があります。いちばん確実なのは、AIが使う認証情報そのものを読み取り専用にすることです。denyやPreToolUseのhookは、その上に重ねる安全網として使ってください。
Cost Explorer APIの呼び出しにお金はかかる?
かかります。Cost ExplorerのAPIはリクエスト単位の従量課金です(執筆時点、2026年9月)。1回あたりは小さな金額ですが、AIが試行錯誤で何十回も呼ぶと積み上がるため、取得はスクリプトで月1回・週1回などにまとめ、結果のJSONをAIに読ませる形がおすすめです。最新の料金はAWS公式で確認してください。
本番環境の障害対応にもAIエージェントを使っていい?
ログ・メトリクスを読んで原因の仮説を立てる「一次切り分け」には有効です。ただし、再起動・ロールバック・設定変更といった本番への操作は、AIが手順とコマンドを提案し、人が内容を確認して実行する形にしてください。障害時は焦りから確認が甘くなりやすいため、平時よりも権限を絞っておくくらいがちょうどよいです。
まとめ|「目と頭はAIに、手は人に」
Claude CodeにAWS CLI・wrangler・Vercel CLIを使わせると、エラーログの調査と原因仮説、コストの内訳点検、未使用リソースの棚卸し、Terraformのplan解説といった「読んでまとめる」運用作業を大きく任せられます。障害時に事実と推測を分けて整理してくれるだけでも、一次対応のスピードは変わります。
その効果を安全に得るための要点は3つです。AIが使う認証情報を読み取り専用にする(AWS_PROFILE=readonly)、permissionsのdenyとPreToolUse hookで変更系コマンドを止める、そして削除・apply・本番デプロイは人が実行すること。まずはstaging環境のログ調査から始め、慣れてきたらコスト点検の定期実行へと広げていくのがおすすめです。コードの修正からPR・CIまでをつなげたい方は、相方の記事Claude Code×GitHub(gh CLI・API・Actions)もあわせてどうぞ。
AIエージェント開発のスキルを、キャリアにつなげる
LLM APIでエージェントを実装できるエンジニアは、転職・独立どちらでも需要が高い領域です。
- AIで独立するには?未経験から案件を取る6ステップ【2026】:自動化・開発スキルを案件にする。フリーランスエージェントの選び方も
- AIが快適に動くノートパソコンの選び方&おすすめ3選【2026】:開発・AIエージェントを動かすならメモリ16GB以上が目安