Claude Code に手伝ってもらって AWS Well-Architected レビューをやってみた

はじめに

私が担当しているシステムは、AWS の FTR（Foundational Technical Review）を取得しています。FTR の検証資料には SOC 2 Type II レポートか Well-Architected Framework Review（WAFR）のレポートのどちらかを提出することになっており、私たちは WAFR を選んでいます。レポートは1年以内のものである必要があるため、毎年決まったタイミングでアーキテクチャレビューを実施しています。

これがなかなか骨の折れる作業です。設問数が多いうえに、「今の本番構成が実際どうなっているか」を1つ1つ確認しながら回答する必要があります。今年はこの作業を Claude Code に手伝ってもらったところ、かなり省力化できたので、その活用ポイントを共有します。

前提

レビューには AWS Well-Architected Tool を使い、レンズは標準の「AWS Well-Architected Framework」（レンズバージョン 2025-02-25）を選択しました。6つの柱（運用・セキュリティ・信頼性・パフォーマンス・コスト・持続可能性）にまたがる全57問のチェックリストに回答していく形です。

設問の構成や数はレンズによって変わるので、本記事に出てくる設問数はこのレンズ前提の話として読んでください。

何を手伝ってもらったか

大きく4つです。

1. 情報収集（IaC ソースコード＋実環境の参照）
2. Well-Architected Tool への入力支援（メモ記入・チェックの根拠出し）
3. アーキテクチャのレビューと改善点の整理
4. 難解な設問・選択肢を分かりやすい日本語に変換

順番に紹介します。

① 情報収集

Well-Architected の回答で一番大変なのが「現状把握」です。この棚卸しの段階では Claude Code に読み取り専用の権限だけを渡し、次の2方向から現状を確認してもらいました。

• IaC のソースコード（CloudFormation テンプレート / CDK）を読んで、意図された構成を把握
• 実環境を AWS CLI（read-only）で直接参照して、実際にどうなっているかを確認

1点だけ注意で、読み取り専用でもデータ本体は読めてしまいます。S3 や DynamoDB のユーザーデータだけでなく、CloudWatch Logs や RDS のログも対象です。見せたくないものがあるなら、必要な参照だけを許可した専用ロールにしてください。

収穫だったのは、この2つが食い違うケースを拾えたことです。たとえば「IaC 上は定義が無いのに、実環境にはリソースが存在する」といった、手動作成のまま IaC 管理から外れているリソースを発見できました。CloudFormation のドリフト検出は、スタック管理下かつドリフト検出に対応したリソースの、テンプレートで明示したプロパティしか対象にしません。そもそもテンプレートに一度も載っていないリソースは、こうやって突き合わせないと見つかりません。

調査は、コンピュート・ストレージ・ネットワーク・セキュリティ・監視・コストといった領域ごとにサブエージェントへ分担させ、並列で走らせました。1つのセッションで順番に見ていくより短時間で済みますし、各エージェントが担当領域だけに集中するので、観点の抜けも出にくくなります。

実際にかかった時間は次のとおりです。

3つずつ2回に分けて起動したので、本番環境の棚卸しは全体で12分ほどで終わりました。順番に1つずつ調べていたら、単純合計で30分近くかかっていた計算です。

② Well-Architected Tool への入力支援

Well-Architected Tool は AWS CLI から操作できます（aws wellarchitected ...）。そこで Claude Code に、

• 各設問の「メモ - オプション」欄に、実測した構成の要点を記入
• チェックを付ける／外すべき選択肢を、根拠つきで提案

してもらいました。

メモの記入は書き込み操作なので、①の読み取り専用の権限だけでは足りません。不要な権限は外して渡してください。

Well-Architected Tool の各設問には「メモ - オプション」という自由記述欄があり、ここに現状をメモしておけます。「今どういう構成になっているか」「なぜこのチェックを付けた／付けなかったか」を実測ベースで残しておけるので、あとから回答を見返すときや、チーム内で説明するときの根拠になります。なお CLI から書き込むとこの欄は追記ではなく上書きになり、文字数の上限もあります。既存のメモを残したい場合は、先に取得して連結してから書き込む必要があります。

一方、今回はチェックの付け外しそのものは人がやりました。Claude Code には「この設問はこの選択肢を付けるべき／外すべき」を根拠つきで挙げてもらい、それを1件ずつ確認しながら画面で付け外ししていく形です。

「アーキから客観的に確認できるもの」と「組織・プロセス・文化に関するもの（APIでは分からない）」を仕分けしてもらえたのも助かりました。後者は無理に回答せず、人が答えるべき設問として明確に切り分けられます。

具体的な内訳としては、全57問のうち、組織・プロセス系で人手での回答が必要な13問は「人が答える設問」として切り分け、それ以外の44問については、アーキテクチャの実測をもとにメモを記入し、選択肢の見直し候補を挙げてもらいました。最終的な回答（チェックの付け外し）は人が確定しています。

なお今回は既存のワークロードに回答していく形でしたが、別のケースではワークロードの作成そのものを Claude Code にやってもらったこともあります。読み取り権限に加えて Well-Architected Tool の操作権限を渡しておけば、ワークロードを作るところから任せられます。

③ レビューと改善点の整理

現状を棚卸しする過程で、Claude Code に改善余地も洗い出してもらい、レポートにまとめてもらいました。冗長性・暗号化・コスト管理・監視まわりなど、6つの柱のうち5つにまたがって14件見つかっています。修正用の設定変更コマンドの提示までをやってもらい、AWS への適用は自分たちで実行しました。

ただし、AI のレビュー結果には間違いが混ざります。ある機能を「有効」と報告してきたので根拠を確認したところ、デフォルトで存在する設定が1件見つかっただけでした。実データまで調べさせると直近のトレースは0件で、「有効」は誤り。これを見落としていたら、4問について実態と違うチェックを付けるところでした。

とはいえ「その根拠で本当に言えるのか」と一度突き返せば、自分で調べ直して訂正します。出てきた結果をそのまま信じず、根拠を確認させるのがコツでした。

④ 難解な設問・選択肢を「分かりやすい日本語」に変換

これは地味に効果が大きかったです。

Well-Architected の設問・選択肢は英語ベースで、日本語訳もカタカナのままだったり直訳だったりで、読んでも分かりづらい言葉が出てきます。

そこで Claude Code に、全57問・全選択肢を

• 「この設問は結局なにを聞いているか」を平易な1文で
• 各選択肢を「何をすることか＋どういう状態ならチェックしてよいか」の目安つきで

書き換えてもらい、日本語の早見表を作りました。1問だけ例を挙げます。

変換前（OPS 4）:

OPS 4 オブザーバビリティをワークロードに実装するにはどうすればよいでしょうか?

• OPS04-BP03 ユーザーエクスペリエンステレメトリを実装する

変換後:

OPS 4 システムの状態を見える化できているか

問われていること: システムの状態を把握しデータに基づき判断するため、KPI・アプリ計測・利用者体験・依存先・処理の追跡をどこまで計測しているかを確認する設問。

• 実ユーザー体験を計測 — 実利用者の操作を計測するRUM（実ユーザー監視）と、重要な操作を疑似実行する合成監視の両方で顧客体験を把握し、そのデータを分析して改善につなげている。片方しか無い場合や、計測しているだけで分析していない場合は未チェック。

「結局なにを聞かれているのか」が1文で分かり、選択肢は「何をすることか」と「どこまでできていればチェックしてよいか」まで書かれているので、画面と見比べながらそのまま判断できます。

意味の分かりづらい用語も、以下のようにこの中で言い換えられます。

この作業も並列で、今度は6つの柱ごとにサブエージェントを立てて処理しています。まず全体を短い説明で一気に書き出し、そのあともう一度同じ6並列で、選択肢ごとの詳しい目安を肉付けする、という2周構成にしました。全57問ぶんでも数分で出てきます。

これがあると、Well-Architected Tool の画面と早見表を突き合わせながら、1問ずつ迷わず判断できました。チームで回答をレビューするときの共通言語にもなります。

おわりに

情報収集・整理・言い換えといった手間のかかる部分を任せつつ、判断と実行は人間が握る。この分担にしたことで、楽になっただけでなく、レビューの質そのものが上がりました。実環境を1つ1つ当たってもらったことで、去年までは気づけていなかった改善点をいくつも拾えています。

来年の FTR も、この進め方でいこうと思います。