「Claudeでできないって、結局どこまで本当なんだろう？」
「CloudTrailのログ調査を、いちいちマネコン開いてポチポチするのがつらい…」
そんなモヤモヤを抱えながら、なんとなくClaudeを「チャットでコードを書いてもらうだけのツール」として使っていないでしょうか。
実は、Claude単体では「できない」ことでも、AWS MCP ServerやClaude Codeと組み合わせることで、CloudTrailのログ検索やインシデント調査をかなりの部分まで自動化・半自動化できます。
一方で、本当に「Claudeでは絶対にできない領域」や、セキュリティ的にやらせるべきでない作業も存在します。
この記事では、Route53レコード削除の調査という具体例をベースにしつつ、
「Claudeでできない」と検索する人の本当の悩み ClaudeとAWS MCP Serverを組み合わせるとどこまでできるのか 逆に、設計思想的にClaudeに任せるべきではないこと
を整理し、CloudTrailログ調査をClaudeで“ほぼ自動化”する実践ステップまで一気に解説します。
なぜ人は「Claudeでできない」と感じてしまうのか
AIのイメージ
まずは、なぜ多くの人が「Claudeでできない」という結論にたどり着きがちなのかを整理しておきます。ここを誤解したままだと、本当はできることまで諦めてしまいます。
よくあるパターンは次のようなものです。
- Claudeにお願いした操作が、権限不足や外部ツール未設定によって失敗してしまい、「Claudeにはできない」と思い込んでしまうパターンが存在します。
- Claudeの設計思想上、セキュアにするために制限されている部分を「性能の限界」だと誤解してしまうパターンが存在します。
- プロンプトで前提条件や欲しいアウトプットを具体的に伝えきれておらず、「思った通りに動かない＝できない」と感じてしまうパターンが存在します。
特にAWSのような本番環境を扱う場面では、権限モデルとツール連携の設計がきちんとしていないと、Claudeがいくら優秀でも「やれること」はごく限られます。
裏を返せば、正しく権限とツールを設計してあげれば、かなりの部分をClaudeに任せられるとも言えます。
ClaudeとAWSをつなぐ鍵「AWS MCP Server」とは
ClaudeがCloudTrailのログを直接読めるわけではありません。ポイントは、AWS MCP Serverという“仲介役”を挟むことです。
AWS MCP Serverの役割イメージ
AWS MCP Serverは、ざっくり言うと「ClaudeからAWSリソースに安全にアクセスさせるための中間サーバ」です。
Claudeは自然言語で指示を受け取り、MCP Serverを通じてAWS SDKやCLIのような操作を行います。ユーザーから見ると、
「CloudTrailから、○○のイベントだけを検索して」
「Route53のこのレコードがいつ消えたのか調べて」
とプロンプトでお願いすると、MCP Serverが裏でAWS APIを叩き、その結果をClaudeが解釈・要約して返してくれる、という流れになります。
Claude Codeとの組み合わせで何が変わるか
Claude Codeをターミナルから起動し、そこにAWS MCP Serverを接続すると、普段の開発環境の延長でCloudTrail調査ができるようになります。
マネジメントコンソールでの作業と比べると、次のような違いがあります。
| 観点 | マネジメントコンソールのみ | Claude+AWS MCP Server |
|---|---|---|
| 調査の手間 | 画面遷移やフィルタ設定を毎回手作業で行う必要があります。 | 一度プロンプトを用意すれば、似た調査は再利用可能です。 |
| 再現性 | 「どんな条件で検索したか」が人に依存しやすいです。 | プロンプトとして残るため、手順をチームで共有しやすいです。 |
| 分析の深さ | 「ログを見る」までが主で、解釈は人間側に任されます。 | ログを取ってきた後の要約・時系列整理までClaudeが支援します。 |
最小構成で押さえておきたい準備のポイント
元の文章では細かなコマンドまでは書かれていませんでしたが、初心者がつまずきやすいポイントはだいたい決まっています。
押さえておきたいポイントは以下のようなものです。
- ローカル環境にAWS MCP Serverをインストールし、Claude Codeから認識されるように設定する必要があります。
- .mcp.jsonでリージョンや使用するAWSプロファイルを正しく指定しておく必要があります。
- CloudTrailやRoute53など、調査対象のサービスにアクセスできるIAMロールとポリシーを準備する必要があります。
このあたりを疎かにすると、Claudeは「よくわからないエラーメッセージを返してくるだけの存在」になってしまい、「Claudeでできない」という印象だけが残ります。
ClaudeでCloudTrailログが検索できるまでの具体的な流れ
ここからは、実際にあったRoute53のAレコードが意図せず削除されたインシデントを例に、CloudTrailログをClaude経由で調べていく流れを、初心者向けに噛み砕いて整理します。
全体の5ステップ
大まかな流れは次のような5ステップに分解できます。
- ローカル環境にAWS MCP Serverをインストールし、.mcp.jsonでリージョンとAWSプロファイルを設定します。
- AWS側でMCP用のIAMロールを作成し、必要最小限のポリシー（CloudTrail読み取り、対象サービスの読み取りなど）を付与します。
- 作成したIAMロールを、ローカルのAWSプロファイルから利用できるように設定します。
- ターミナルからClaude Codeを起動し、MCP Serverが読み込まれていることを確認します。
- CloudTrail調査用のプロンプトを投げ、権限不足があればポリシーを見直しつつ、目的のイベントにたどり着きます。
この5ステップを一度経験しておくと、次からは別のインシデントでも同じパターンを応用できます。
「権限が足りません」をどう扱うかが腕の見せどころ
元の文章でも触れられていたように、最初の実行では権限不足エラーが出ることがよくあります。ここで「やっぱりClaudeでできないじゃん」と諦めるのではなく、Claudeから出てきた提案をもとにポリシーを育てていくのがポイントです。
典型的には、Claudeが次のような提案を返してきます。
「CloudTrailのログを検索するには、○○というアクションが許可されたポリシーが必要です」
この提案を手掛かりにIAMポリシーを更新し、再度Claudeに「権限を追加したから、もう一度試して」と伝える。すると、今度はCloudTrailから該当イベントを取得し、例えば次のような情報をまとめてくれます。
・Aレコードが削除された日時
・どのユーザーまたはロールが操作したか
・どのAPIコール（例ChangeResourceRecordSets）が実行されたか
・その後いつ復旧したのか
人間がCloudTrailの画面をポチポチしながら辿るのに比べると、かなりの時短になります。
CloudTrailの生ログにたどり着くまで
要約だけではなく、実際のCloudTrailイベントのJSONを確認したい場面も多いはずです。その場合も、Claudeに対して
「さっきの削除イベントのCloudTrailレコードの生JSONを見たい」
と伝えれば、必要に応じてS3上のログやCloudTrailのイベントURLなど、生データへのアクセス手段を教えてくれます。
最終的には、自分の目で原本を確認することで、「本当にその操作が行われたのか」をシビアに検証できます。
Claudeでできないに関する疑問解決
ここからは、「Claudeでできない」というキーワードに紐づく、よくある疑問を一段深く整理していきます。大事なのは、「本当にできない領域」と「設定さえ整えれば実はできる領域」を切り分けることです。
Claudeが本当にできないこと
まずは、Claudeの設計思想上できない／させるべきではないことを押さえておきましょう。
| カテゴリ | 具体例 |
|---|---|
| モデルの設計上できない | 勝手にインターネット上の任意サイトへアクセスしてデータをスクレイピングすることや、ユーザーが許可していないクラウドアカウントに侵入することなどはできません。 |
| セキュリティ的にNG | 本番環境の全削除や、大量ユーザーへの一斉メール送信などは、AI任せにせず人間による最終確認を挟むべきです。 |
| 責任の所在が曖昧になる操作 | 「誰が承認したかわからないままインフラを変更する」といった、監査ログや責任範囲がぼやける運用は避けるべきです。 |
これらは、どれだけツールをつないでも「やらせてはいけない」領域です。 Claudeはあくまで強力なアシスタントであって、最終的な意思決定者ではないという前提を忘れないようにしましょう。
設定次第で「できる」に変わること
一方で、今回のCloudTrail調査のように、「今はできないけど、権限とツールを整えればできるようになること」も多く存在します。
例えば、次のようなケースです。
・CloudTrailから特定リソースに関するイベントだけを抽出する
・Route53やEC2など特定サービスの構成変更履歴を時系列に整理する
・過去のインシデント調査プロンプトをテンプレート化し、別環境でも再利用する
これらは、AWS MCP Serverと適切なIAMポリシーがあれば実現可能です。「Claudeでできない」というより「まだClaudeに仕事をさせる準備が整っていないだけ」という認識に近いです。
安全に使うための考え方
「できること」が増えるほど、同時にセキュリティとガバナンスも意識する必要があります。
特におすすめなのは、次のような考え方です。
・最初は読み取り専用権限だけで始める
・CloudTrailやConfigなど、監査系サービスから利用を始める
・Claudeに何を任せるかをチームで言語化し、ポリシーとして共有する
こうすることで、「怖いから何もさせない」という状態から一歩抜け出しつつ、「やりすぎてしまうリスク」も避けることができます。
トラブル調査を加速するプロンプト設計のコツ
同じ「Claude+AWS MCP Server」構成でも、プロンプトの書き方によって成果は大きく変わります。ここでは、CloudTrail調査プロンプトの考え方を紹介します。
時間・対象・目的の三点セットを伝える
インシデント調査では、最低限次の三点を明確に伝えると、Claudeの動きが一気に良くなります。
・いつ頃起きた問題なのか（例2024年5月1日〜5月10日の間）
・どのリソース／サービスの問題なのか（例開発環境のRoute53ゾーンexample.com）
・知りたいことは何か（例Aレコードが削除された日時と実行した主体）
元の文章でも、具体的な時刻やレコード名を変えつつも、この三点を含んだプロンプトを投げていたと考えられます。 「CloudTrailから原因を調べて」だけではなく、「何を知りたいのか」をはっきり書くことがポイントです。
Claudeに調査の「方針」も考えさせる
もう一つのコツは、いきなり結果だけを要求しないことです。
例えば、次のように聞いてみると、Claudeの真価が発揮されます。
「この情報を前提に、CloudTrailを使って原因を特定するための手順案をまず出して。それから、実際に実行できるものはMCP経由で実行していってほしい」
こうお願いすると、Claudeは
・どのイベント名をターゲットにするか
・どのフィルタ条件を使うか
・どの順番で絞り込んでいくか
といった調査方針をまず言語化してくれます。その上で、実行部分だけをMCPに任せるので、人間側も「何をやっているのか」を把握しやすくなります。
よくある質問
Q1: Claudeに全部任せるのは危なくないですか？
結論から言うと、「何を任せるか次第」です。
今回のようなCloudTrailログの検索や要約、Route53の変更履歴の整理といった読み取り中心の作業であれば、読み取り専用ロールを用意することで、リスクをかなり抑えつつ活用できます。
一方で、本番リソースの削除や料金に大きな影響を与える操作などは、Claudeに直接やらせず、人間による最終確認を必ず挟む運用にしておくのが無難です。
「Claudeでできないように意図的に制限しておく」ことも、立派なセキュリティ設計です。
Q2: 「Claudeでできない」ときは、何から疑うべきですか？
おすすめは、次の順番で確認していくことです。
1つ目に、プロンプトが曖昧すぎないかを見直してください。
2つ目に、MCPや外部ツールが正しく設定されているかを確認してください。
3つ目に、それでもダメな場合は、そもそも設計上許可されていない操作なのかを考えてください。
この三段階で切り分けることで、「本当にClaudeの限界なのか」「設定や権限の問題なのか」がだんだん見えてきます。
闇雲に「Claudeでできない」と決めつける前に、このプロセスを一度踏むだけでも、日々の生産性は大きく変わります。
【警告】このままでは、AI時代に取り残されます。
あなたの市場価値は一瞬で陳腐化する危機に瀕しています。
今、あなたがClaude.aiの表面的な使い方に満足している間に、ライバルたちはAIを「戦略的武器」に変え、圧倒的な差をつけています。数年後、あなたの仕事やキャリアは、AIを本質的に理解している人材によって「奪われる側」になっていませんか？
未来への漠然とした不安を、確かな自信と市場価値に変える時です。
当サイトでは、ChatGPTをはじめとする生成AIの「なぜそう動くのか」という原理と、「どう活用すれば勝てるのか」という全体戦略を徹底的に解説している記事を多く掲載しています。
単なる操作方法ではなく、AIを指揮するリーダーになるための思考と知識を、網羅的に提供します。
取り残される恐怖を、未来を掴む確固たる自信に変えるための戦略図。あなたのキャリアを成功に導く決定的な一歩を、当サイトの記事を読んで踏み出してください！ 読んだ瞬間から、あなたはAIの波に乗る側になります。
他の記事は下記のリンクからご覧いただけます。
まとめ
「Claudeでできない」という検索キーワードの裏側には、
・AIにもっとインフラ運用を手伝ってほしい
・CloudTrailやRoute53の調査を、マネコンからの手作業だけに頼りたくない
・けれど、セキュリティ的にどこまで任せていいのかが不安
といった、エンジニアやSREのリアルな悩みがあります。
本記事では、Route53レコード削除の調査という具体例を通じて、
・Claude単体ではできないことと、MCP連携で「できる」に変わることの違い
・AWS MCP ServerとClaude Codeを組み合わせてCloudTrailログを調査する5ステップ
・「本当にClaudeに任せてはいけない領域」と、「安全に任せられる情報収集・分析」の線引き
を整理しました。
大事なのは、「Claudeでできない」と一言で片付けないことです。
正しく権限とツールを設計し、プロンプトを工夫すれば、「今はできない」と思い込んでいたAWS上の調査や分析の多くを、Claudeにサポートさせることができます。
今日できる一歩としては、まずは読み取り専用のIAMロール＋AWS MCP Server＋CloudTrail調査プロンプトという、リスクの低い組み合わせから始めてみてください。
そこから少しずつ、自分たちの組織にとっての「Claudeに任せる範囲」と「人間が担うべき範囲」を言語化していけば、「Claudeでできない」は、やがて「Claudeに任せた方が早い」という新しい当たり前に変わっていくはずです。
コメント