BeeX 事業開発部の榊原です。記事タイトルが何やら怪しいですね。ここ最近AI関連のニュースを見ない日はないくらい、世の中は盛り上がっています。「CLAUDE.mdはこう書くのがお勧め！」「skillsやエージェントはこう作れ！」「エンジニアじゃないけどAIを使ってバリバリ結果だしてます！」等話題に尽きません。
その一方で、まだまだ「今更触り始めてもなあ」「忙しくて時間取れないなあ」「使わなくても仕事は回るしなあ」「そもそも私はエンジニアじゃないし」という声も見かけます。今回はそんな方向けの記事です。
私自身はClaude Codeを使い慣れている人から見たら、おそらく効率が悪かったり古い使い方をしていると思います。しかし、あえて遠回りをして泥臭く触り続けたことで得られたものがありました。本記事ではその体験を共有します。
今回の環境
各設定手順は省略しますので、気になる方は公式ドキュメントをご参照ください。
- WSL2環境（Ubuntu）
- Claude Code on Amazon Bedrock（学習には使われないと明記されている）
Amazon Bedrock では、プロンプトおよび AI のレスポンスを保存またはログに記録することはありません。Amazon Bedrock は、プロンプトと完了を使用して AWS モデルをトレーニングせず、サードパーティーに配布しません。
【お題】Claude Codeを用いてAWSのインフラを組む
今回は試しに業務で何度か構築してきた、AWSのネットワークアウトバウンド環境をコンソール操作やコードを書かず、全てClaude Codeを利用して構築しました。 構成図はすぐ後の項目で掲載します。
構成:
- VPC x 3（プライベートサブネットのEC2用 x 2、アウトバウンド用 x 1）
- Transit Gateway（TGW）
- Network Firewall（NFW）
- NAT Gateway（NATGW）
- Internet Gateway
今回は上の構成をまずplanモードで音声入力であれこれ喋って要件を伝え、 何回か質問に答えた後でClaude CodeにCloudFormation用のYAMLを生成させました。 修正の指示やデバッグの度に再作成を繰り返し、デプロイまでやってもらいました。
Claude Codeと自分の頭で認識が違った部分
実際にClaude Codeが生成したYAMLを確認したり、振り返りをしたところ、いくつか自分のイメージと食い違っていたところがありました。 初期にClaude Codeが作成した構成と、自分の頭の中で想像していた構成は以下の通りです。 最終的に何度か壁打ちして自分の頭の中の構成に寄せました。
1. 利用してほしかった去年のアップデートが適用されていない
2025年夏ごろのアップデートで、Network FirewallはTransit Gatewayとネイティブに統合できるようになりました。これにより、NFW専用のVPCを自前で用意する必要がなくなっています。個人的には積極的に利用したい機能です。しかし、Claude Codeが生成した構成は旧来のアーキテクチャでした。あとは去年末リリースされたRegional NAT Gatewayが使われていないのも気になりました。
2. TGWアタッチメント用の専用サブネットがない
AWSの公式ドキュメントでは、Transit Gatewayアタッチメントを利用する際は専用のサブネットを用意することが推奨されています。
各 Transit Gateway VPC アタッチメントに個別のサブネットを使用します。各サブネットに対して、小さな CIDR (/28 など) を使用して、EC2 リソースのアドレスが増えるようにします。別のサブネットを使用する場合は、次の項目を設定できます: Transit Gateway サブネットに関連付けられたインバウンドおよびアウトバウンド NACL を開いたままにします。 トラフィックフローに応じて、ワークロードサブネットに NACL を適用できます。
しかし、Claude Codeが生成した構成ではこのベストプラクティスが反映されていませんでした。動作はしますが、リソースの無駄が減ったり、NACLを用いた制御もできるので専用サブネットを用意する方が好ましいです。
3. ルートテーブルの設定ミス
通信経路の戻りのルートテーブルの設定が間違っており、一発で疎通テストを完了させることができませんでした。自分でルートテーブルを確認し、修正して初めて通信が通りました。ルートテーブルについてはIaC用コードのみで判断しようとすると、どうしても抜け漏れが発生しやすいので、別途見やすい形で出力してもらった方が良いでしょう。
4. IaC検証用のMCPサーバーが使われなかった
これは構成図からは読み取れない部分ですが、私の環境にはCloudFormationテンプレートを検証してくれるMCPサーバー（aws-iac-mcp-server）が接続されていました。しかし、Claude CodeはこのMCPサーバーを使わずコードの検証を実施していました。その結果、デプロイの過程で表記方法やルートテーブルの表記不足で何度もエラーと手戻りが発生して時間がかかってしまいました。せっかくMCPサーバーを用意しても、明示的に指示しないと使ってもらえないことがあります。
以上の問題は、当然私の指示の出し方や技量、準備が不完全だったことにも起因する部分もあります。経験がある方からすれば簡単に防止できたかもしれません。しかし、これらの問題に直面したからこそ、Claude Codeが持つ機能のありがたさに気づけたとも言えます。もし今回の検証をせず、最初から慣れている方の方法に乗っかっていたら、学びは減っていたかもしれません。
時間をとって触って分かったこと
時間を確保して自分で考えながら使ってみて初めて、色々な気づきが得られました。
- 「この設定は確かに便利、必要だ」：CLAUDE.mdの書き方の重要性やなぜskillsという機能があるか、自身の経験を通して腹落ちした
- 「知識のない分野で使うのはリスクがある」：自分が正解を知っている分野だったからこそ、AIの出力のどこが間違っているか判断できた
- 「自分の想像通りに動かすのは意外と難しい」：AIへの指示の出し方にもコツがあると実感
- 「アーキテクチャの構成は完成形のイメージがあるかが重要」：planモードである程度アウトプットのイメージを固めることで、AIが生成したものと自分の頭の中のものとのズレに気づきやすくなる
以上の気づきは、書籍等を読んだりして単なる知識として知っていたものもありましたが、自分の中にストンと落とし込めたのは触ったからこそでした。 勉強会に参加する。ブログを読む。SNSで情報を追う。知っている人の使い方を見る。どれも重要です。 しかし、それらで得た知識・内容をきちんと消化するには、結局自分で触ることが必要だなと強く感じました。 某ジャンプ漫画のセリフを借りると「言葉」でなく「心」で理解できた！という感じです。（最近5部のアニメを見終えました）
まとめ
私はまだClaude Codeを使いこなせているとは正直とても言えません。しかし今回、自分が比較的なじみのあるネットワーク構成の分野をお題にして泥臭く触り続けたこと で、CLAUDE.mdやskills、MCPサーバーといった機能が「なぜ存在するか」を今回の体験を通して理解できました。ドキュメントやブログを読んだだけでは得られない、「 ああ、そういうことか」を感じられました。
そしてもう一つ実感したのは、触ることで初めて「AIを使って自分は何ができるか」のイメージが具体的になっていくということです。
「もっとこう指示すればうまくいくはず」
「この機能を活かせばここが改善できる」
そういった欲求が自然と芽生え、それを解決するためにドキュメントを読み、試し、また改善する。こ
のサイクルを回すことでしか身につかない力があると感じています。この部分は触れば触るほど練度が上がり、より良い使い方ができる予感がしているので、
引き続き自分の方で触り続けてナレッジ共有やお客様の価値提供につなげられたらと考えています。
AIをめぐる変化のスピードは加速しています。「投資対効果は?」「自分の業務に必要か?」と立ち止まる気持ちは理解できるものの、目の前の業務に固執し続けると、逆に今の変化のスピードに乗り遅れてしまうかもしれません。
効率の良い学び方や触らない理由を探すよりも、まず実際に触ってみる。 遠回りに見えるその一歩が、結局は一番の近道かなと思いました。 今回は以上です。ここまでお読みいただきありがとうございました。
この記事のアイキャッチ画像は、Google Geminiによって生成されました。
