Claude Code で構築するインフラ
手元の Claude Code に伴走させ、AWS 上の Claude Code に「喋って」Supabase を建てさせた
コード補完としての AI エージェントは日常になりました。では インフラ構築 はどうか。 今回は少し変わった構成を試しました —— 手元 PC の Claude Code を“伴走役”にしつつ、 AWS EC2 の上にもう一つ Claude Code を導入し、そちらへプロンプトで指示して、 セルフホスト版 Supabase を一式立ち上げるという二段構えです。結論、想像以上に実用でした。
EC2(Ubuntu) に Claude Code を入れ、サブスク認証のうえ「Supabase を Docker で構築して」と指示するだけで、 11 コンテナが healthy な Supabase 環境が立ち上がった。 認証キーの整合など“ハマりどころ”はエージェント側が検証まで実施。 人間の役割は方針判断・権限設計・詰まった時の交通整理に寄り、 手を動かす部分は大きく圧縮された。
なぜ「AI にインフラを建てさせる」を試したのか
アプリのコードを AI に書かせるのはもう普通です。一方でサーバ構築やミドルウェアの立ち上げは、 手順書を見ながら人間がコマンドを叩く作業が今も多く残っています。 ここに Claude Code のようなエージェントを持ち込めるなら、 「手順書を読む → 実行する → 詰まったら調べる」の大半を任せられるのでは、という仮説を検証したくなりました。
題材には Supabase のセルフホスト（OSS 版）を選びました。 Postgres・認証・自動 API・ストレージ・管理 UI などを Docker Compose で束ねる構成で、 設定項目が多く “いい塩梅の難易度” だったためです。
構成 ── Claude Code を二層に分ける
今回の肝は、Claude Code を「伴走」と「実行」の二役に分けた点です。 手元 PC 側は相談相手・司令塔として、EC2 側は実際に手を動かす作業者として動かしました。 作業環境も、手元は VSCode の拡張機能、EC2 側は VSCode のターミナルから SSH 接続と、 同じエディタの中で二つの Claude Code を並行して動かしています。
伴走する Claude Code
「どう作るか」を一緒に設計し、EC2 側でのエラーを貼れば解読して次の一手を返す司令塔。人間の思考の速度を上げる役。
実行する Claude Code
サーバ上で実際に git / docker / スクリプトを走らせる作業者。プロンプト一つで一連の構築を回す実働部隊。
やったこと ── 6 ステップ
実際の流れはシンプルでした。番号順に、どちらの Claude Code が動いたかも添えます。
- EC2 を起動するPC 伴走 OS は枯れて情報の多い Ubuntu 24.04 LTS を選択。インスタンスサイズや OS の選定は伴走 Claude と相談して決定。
- EC2 に Docker と Claude Code を入れるEC2 実行 SSH で入り、Docker と Claude Code 本体を導入。ネイティブインストーラで数分。
- Claude Code をサブスクで認証EC2 実行 サーバ上で Claude Code を起動し、表示されたログイン URL をブラウザに貼り付けて認証。既存のサブスクをそのまま利用できる。
- プロンプトで Supabase を構築EC2 実行 「Supabase を Docker で構築して」と指示。clone → 設定生成 → 起動 → 状態確認までを自走。11/11 healthy。
- SSM 経由の鍵レス運用へPC 伴走 最小権限の IAM ロールを付与し、SSH 鍵に依存しないセッション接続へ移行。運用の入口を締める。
- シークレットを SSM へ退避EC2 実行 生成された各シークレットを暗号化パラメータとして AWS SSM Parameter Store に保存。値は画面に出さず設定ファイルから直接転記。
実際に投げたプロンプト（抜粋・一般化）
この指示プロンプト自体も、手元（伴走役）の Claude Code に作ってもらいました。“ハマりどころ”である認証キーの整合を、伴走役が先回りしてプロンプトに盛り込んでくれています。
# EC2 上の Claude Code へ
このディレクトリに Supabase セルフホスト(Docker版)を構築して。
1. 公式の docker 構成を取得し、設定ファイルを用意
2. パスワード・署名鍵などのシークレットを安全なランダム値で生成
3. 公開鍵/秘密鍵に相当する API キーは、署名鍵と整合する形で正しく生成すること
4. コンテナを起動し、全て healthy か確認
制約:
- シークレットの値は画面に出さず、設定ファイルにのみ書き込む
- 署名鍵を変えたら関連キーを必ず作り直し、三者を一致させるエージェントは指示通り、キー生成スクリプトを書くだけでなく、 稼働中のスタックに対して実際にリクエストを投げ、署名が一致していることを検証してから完了報告を返しました。 ここまで自分で確かめてくれるのは頼もしい挙動でした。
つまずいた 2 か所（と、その抜け方）
もちろん一直線ではありませんでした。詰まった箇所は、エラーを伴走 Claude に貼って原因を切り分ける、という流れで解消しています。
docker コマンドが権限エラーユーザーを docker グループに追加した直後は、現在のセッションにその変更が反映されず permission denied に。
対処：一度ログアウトして入り直す（またはグループを再読込）だけ。“追加したのに効かない”定番の落とし穴。
鍵レス運用のために管理エージェント経由の接続へ移行しようとしたところ、権限ロールを付けたのに接続不可。ロールが無い状態で一度登録に失敗し、その状態のままだったのが原因。
対処：ロール付与後にエージェントを再起動して登録し直させると、数分でオンラインに。“いつ権限が付いたか”をエージェントは自動では拾い直さない、という学び。
セキュリティ ── 「速い」と「雑」は違う
AI に任せると雑になりそう、という懸念は当然あります。今回はむしろ逆で、 締めるべき所を明示すれば、エージェントはそれを守り、確認まで返してきました。実践したのは次の 4 点です。
| 観点 | やったこと |
|---|---|
| 権限を絞る | 実行を許可するツール・コマンドを事前に限定し、無制限の“全許可”では走らせない。 |
| 秘密は出さない | シークレットは画面に表示させず、設定ファイルにだけ書かせる。誤表示が起きた分は即ローテーション。 |
| 退避と暗号化 | 全シークレットを SSM Parameter Store に暗号化保存。復旧可能な状態を確保。 |
| 入口を締める | IAM は最小権限、管理コンソールは外部公開せず、接続は鍵レスの管理エージェント経由へ。 |
実際、構築中に管理画面の資格情報が一度だけ画面に出てしまった場面がありました。 これをエージェント自身が検知し、即座に該当情報をローテーションして作り直すという是正まで行いました。 “出さない”という制約が、事故時の自己修復にもつながった形です。
やってみて分かったこと
一番の収穫は、Claude Code を「伴走」と「実行」に分けた二層構成が想像以上に噛み合ったことです。 手元の Claude と対話して方針を固め、その方針を EC2 の Claude に実行させる。 エラーが出たら手元の Claude に貼って解読させる。 この往復で、人間は判断と交通整理に集中でき、単純作業から解放されました。
持ち帰りポイント
- インフラ構築でも AI エージェントは実戦投入できる。「手順を読んで実行して詰まったら調べる」の大半を任せられた。
- 人間の仕事は上流に移る。OS 選定・権限設計・セキュリティ方針など、判断の部分が主戦場になる。
- 締めどころは明示する。権限・秘密の扱い・整合性を言語化して渡せば、エージェントは守り、検証まで返す。
- “伴走 + 実行”の二層は効く。相談役と作業者を分けると、詰まりの解消が速い。
もちろん、これはあくまで検証環境での話であり、本番運用にはバックアップ・監視・TLS・可用性など別の作り込みが要ります。 それでも、「サーバに AI を置いて、喋って環境を建てる」が現実の選択肢になっていることは、十分に体感できました。 次はこの構成で、実際の社内ツール基盤を一つ立ち上げてみるつもりです。
