前回の投稿はコチラ：【第4回】AIエージェントと一緒にクラウド日記アプリ開発してみる：E2Eテスト・OpenAI APIによるコードレビュー自動化、ドキュメント整備で品質向上編
なお、この記事はAI・AWSを活用したプログラミング初心者以上を対象としており、AWSアカウント作成や基本的なPC操作については解説を省略している箇所もあることをご了承ください。もし実際にご自身のPC・クラウド環境で構築される場合は、AWS利用での思わぬ課金や、公開（デプロイ）による外部からの攻撃リスクについて十分ご注意ください。
第5回の概要
前回（第4回）は、E2Eテストとコードレビュー、ドキュメント整備を実装しました。今回は、おまけ的な内容になりますが、Windows環境からWSL2（Ubuntu）への移行と、ガードレール・フック設計・実装を行ってより安全にAIエージェントを動かせる環境を作り、品質をアップさせていきたいと思います。
使用するツール
- AWS Amplify Gen 2: TypeScriptでバックエンドインフラを定義できるフレームワーク。今回AWSは新規登録者向けの無料利用枠を利用して開発を進めていきます。
- Cursor: AIによるコード補完・編集機能がネイティブ統合された、VS Codeベースのエディタ。
- Claude Code: 2025年に公開された、ターミナル上で動作するAIエージェント。コードの記述、テスト、デバッグを実行できる。今回Claude Pro（有料版）を年額契約しています。年額契約は月額契約より若干お得なのでおすすめです。（2026年4月現在）
- GitHub: AI（CursorやClaude Code）が生成したコードのバージョン管理（履歴保存）や、バックエンド（AWS Amplify）への自動デプロイの起点として活用。
- Gemini: Googleが提供するAI。Cursor/Claude Codeが生成したコードのセカンドオピニオン、「伴走型アドバイザー」として活用。
- GitHub Actions: CI/CD（継続的インテグレーション/継続的デプロイ）プラットフォーム。
- Playwright: Microsoftが開発した、モダンなWebアプリ向けのE2E（エンドツーエンド）テストフレームワーク。ブラウザ上のユーザー操作を自動化し、新機能を追加しても既存機能が壊れていないか（リグレッション）を高速にチェックします。今回はAIエージェントにテストコードを全自動で生成させました。
1. Opus 4.7 xhigh にWSL2への移行プランを立てさせる→コスパのいいSonnetで実装やテストを進める
1-1. モデルを切り替える：Opusで設計
まずは、より高性能なモデルである Opus に切り替えて、プロジェクトの全貌を把握させ、WSL2 への移行に伴う課題確認やガードレールを設計させます。
/model opus-4.7-xhigh1-2.設計（プランニング）を指示する
以下のプロンプトを Claude Code のターミナルで実行します。
「現在 Windows 側にあるプロジェクトを WSL2 ネイティブ領域に移行した。今のソースコードと環境設定をスキャンし、WSL2 の特性（Linux 権限、パスの違い、I/O速度）を最大限活かすためのリファクタリング計画を立てて。特に、AIエージェントが暴走しないためのガードレール（CLAUDE.md の更新など）を含めた詳細な手順書を作成して。Sonnet がこの後コーディングを行う際、絶対に破壊してはいけないディレクトリや、Amplify の本番リソースに影響を与えないための『安全ルール』を CLAUDE.md に定義して。Sonnet がそのルールを逸脱しようとしたら、エラーを出すように設定してほしい。」
まずはOpusに設計段階をしてもらいました。（WSL環境に合わせるところはやってくれていますね）
2. E2Eテストエラー：Amplify sandboxの作り直し
2-1.SandboxがWindows→WSL2の場合流用できなかった
現状のままだとE2Eテストが一部失敗しています。
Claude Codeに原因を見てもらうと以下の原因を挙げています。
Windows側に置いていた時は動いていたはずなので、よく調べてもらいました。
ちなみにE2Eテストまで成功していたのは以下のプッシュ段階までのようです。
この時点ではWindowsで作業していました。
cognitoのユーザー作成は第4回「2-2.テスト用Cognitoユーザーの作成手順」で記述した通りの方法で行い、あとは「CIを再実施して」等と指示すればOKです。
3. 移行結果
3-1. E2Eテストまで成功
無事、WSL2環境でE2Eテストまで成功しました。
結果としてはSandboxを再作成する必要があった、ということなのですが、Sandboxが増えていくのはなるべく避けたいと考えて、SandboxをUbuntuでも流用できないのかについて、Geminiに質問してみたのですが、以下の理由で難しいようです。
・なぜ「もとの環境」を使い続けるのが難しいのか？
Amplify Gen2のSandboxは、「開発者の名前（識別子）」に紐づいています。
- 移行前: Windows上のユーザー名で Sandbox が作られていた。
- 移行後: WSL2（Ubuntu）上のユーザー名でデプロイしようとした。
AWS側から見ると、「別の人間が新しい環境を作ろうとしている」と判断され、新しい User Pool ID が発行されました。これを無理やり統合しようとすると、既存のデータを壊したり、認証の不整合でさらに深い迷宮に入り込むリスクがあります。
・「使い捨て」がクラウドネイティブの強み
今回のように環境が変わった際に、サッと新しいバックエンドを建てて、テストユーザーをスクリプトで自動作成することができるのが強みです。
- もとの環境: ネットワーク設定や権限エラーのデバッグに数時間かかる。
- 新しい環境: 数分でクリーンな状態が手に入り、CIも確実に通る。
sandbox作り直しについて人間が調べたり試行錯誤するのに若干時間を要しましたが、ユーザープール作成し直すという方針を決めてからは、ひたすらClaude Codeの問いを確認してYesと答えることで実装が完了しました。
まとめと次回
ルール（「ガードレール」（監視・制限する安全装置））を作成して品質・安全を担保（「ハーネス」（馬具・安全帯）」のような制御）する作業を今回行いました。
ガードレールの具体的内容においても、主にGeminiに相談・質問しながら作成しましたが、「言われてみればこんなこともAIエージェントできてしまうなぁ」と感じ、便利さと危険性が表裏一体であることを改めて感じました。
私が本格的にAIを使用して学習を始めたのはここ1か月ですが、モデルの性能が上がったり新たなツールが出来たりと、信じられない速さで技術が進歩していると感じます。自分自身の知識が古くならないよう、キャッチアップを行い、これからも学習を続けていきたいと思います。
投稿者プロフィール
最新の投稿
【AI】2026年4月30日【第5回】AIエージェントと一緒にクラウド日記アプリ開発してみる：リファクタリング、ガードレール、フック設計と実装編
【AI】2026年4月21日【第4回】AIエージェントと一緒にクラウド日記アプリ開発してみる：E2Eテスト・OpenAI APIによるコードレビュー自動化、ドキュメント整備で品質向上編
【AI】2026年4月15日【第3回】AIエージェントと一緒にクラウド日記アプリ開発してみる：AIによるコードレビュー・テスト自動化/Claude CodeとCodexで品質向上編
【AI】2026年4月8日【第2回】AIエージェントと一緒にクラウド日記アプリ開発してみる：Next.jsフロントエンド構築・Cognito認証導入・画像投稿実装編【AWS Amplify Gen 2 × Cursor × Claude Code】
