前回の投稿はコチラ：【第3回】AIエージェントと一緒にクラウド日記アプリ開発してみる：AIによるコードレビュー・テスト自動化/Claude CodeとCodexで品質向上編

　なお、この記事はAI・AWSを活用したプログラミング初心者以上を対象としており、AWSアカウント作成や基本的なPC操作については解説を省略している箇所もあることをご了承ください。もし実際にご自身のPC・クラウド環境で構築される場合は、AWS利用での思わぬ課金や、公開（デプロイ）による外部からの攻撃リスクについて十分ご注意ください。

第4回の概要

1. ドキュメント（仕様書）作成

1-1. 全体像を把握させる：README.md作成プロンプト

まずはプロジェクトの玄関口を作らせます。

プロンプト例： 「このプロジェクトの全ファイルをスキャンし、開発者向けの README.md を作成してください。特に以下の構成を含めてください。

1. プロジェクト概要と主要な技術スタック（Next.js, Amplify Gen 2, Tailwind CSS等）
2. セットアップ手順（WSL2環境を推奨する旨を含める）
3. 現在実装済みの主要機能（日記投稿、画像アップロード、トースト通知、削除機能等）
4. テストの実行方法（npm test および Playwright）
5. CI/CDパイプライン（GitHub Actions）の概要

制約: 実装されていない機能は書かず、現在のソースコードから読み取れる事実のみを記載してください。」

未実装の処理についてもプロンプトに含まれてしまっていたのですが、きちんと現状に合わせてREADME.mdを作成してくれました。

1-2. 仕様を明文化する：機能仕様・アーキテクチャ図案プロンプト

「どう動いているか」をエンジニア向けにまとめさせます。

プロンプト例： 「src/ 内のコンポーネントと amplify/ 内のデータモデルを解析し、主要なデータの流れ（データフロー）を説明するドキュメントを作成してください。 特に、『日記の削除プロセス（S3オブジェクトの削除→DBレコードの削除→UIのState更新）』のシーケンスを Mermaid ¹記法を用いて図解してください。 これにより、後から参画したエンジニアが、なぜ現在の削除フローが『リロード不要』で動いているのかを理解できるようにしてください。」

ドキュメント作成してくれました。

AIでのドキュメント作成の際、どのように指示すればよいかはGeminiに相談しました。どのような点に注意すればいいかについて、参考になった内容を残しておきたいと思います。

1-3. テスト計画・結果報告プロンプト

テストについてのドキュメントも作成させてみたいと思います。

プロンプト例： 「現在実装されている単体テスト（Vitest）と E2Eテスト（Playwright）のテストケースを一覧化し、それぞれのテストが『どのような不具合を防ぐために存在しているか』を解説する TESTING.md を作成してください。 」

こちらもGeminiでのプロンプト生成時に事実とやりたいことが混在しており、現状はE2Eテスト（Playwright）がプロジェクトには存在していませんが、そこも踏まえてドキュメント作成してくれました。

2. E2Eテスト実装

2-1.E2Eテストシナリオ実装

以下のプロンプトを Claude Code のターミナルで実行します。

「プロジェクトに E2E テスト環境として Playwright を導入し、主要機能のテストを作成してください。以下のステップで進めてください：

1. 環境構築: npm init playwright@latest を実行して必要な依存関係と設定ファイルを導入してください。ブラウザは Chromium のみで構いません。
2. テストシナリオの実装: tests/diary-app.spec.ts を作成し、以下のユーザー操作を検証するテストを記述してください：
   • ログイン後、新しい日記（テキスト＋画像）を投稿できること。
   • 投稿した日記が一覧に表示されていること。
   • 日記を削除した際、一覧から消え、トースト通知が表示されること。
3. 環境変数の考慮: Amplify のローカル開発環境（npx ampx sandbox）が動作している localhost:3000（または現在の起動URL）をベースURLとして設定してください。
4. CI連携: GitHub Actions（.github/workflows/ci.yml）に Playwright のテスト実行ステップを追加し、Push 時に自動で E2E テストが走るように修正してください。

制約:

現時点でコードに不足がある場合は指摘してください。

• セレクタは data-testid またはアクセシビリティに基づいたロール（getByRole）を優先して使用してください。
• 現時点でコードに不足がある場合は指摘してください。」

2-2.テスト用Cognitoユーザーの作成手順

テスト用Cognitoユーザーの作成は、AWSマネジメントコンソールで行います。以下、同じようなことをしたい方向けに手順をご説明します。

1. AWSマネジメントコンソールにログインし、「Cognito」サービスを開きます。
2. 「ユーザープール」一覧から、今回の日記アプリで使用しているプールを選択します。
   • 名前は amplify-xxxx-userPool-xxxx のような形式になっています。
3. 左メニューの 「ユーザー」 を選択し、「ユーザーを作成」 ボタンをクリックします。
4. 以下の内容で作成します：
   • ユーザー名/Eメール: ダミーでOK（CIの E2E_EMAIL に設定するもの）。
   • パスワード設定: 「パスワードを生成する」のチェックを外し、手動で強いパスワードを設定します（CIの E2E_PASSWORD に設定するもの）。
   • E メールアドレスを検証済みとしてマークする: 必ずチェックを入れてください。 これを忘れると、テスト実行時に「メール認証待ち」状態で止まってしまいます。
5. 作成後、ステータスが 「CONFIRMED（確認済み）」 になっていることを確認してください。

一覧の「確認ステータス」列に、緑で「パスワードを強制的に変更」と表示されるはずです。そのままではテストが失敗するので、対策が必要です。

2-3.AWS CLIで「パスワードを確定」させる

E2Eテストは「ログイン画面でメアドとパスワードを入れてボタンを押す」という動作を自動化していますが、ログイン直後に「パスワード変更画面」が出てしまうと、テストコードが想定していない画面に遭遇して止まってしまいます。

以下の手順で解消しました。

WSL2のターミナルから以下のコマンドを叩くことで、管理者権限でパスワードを「本設定」として上書きし、強制変更のステータスを解除（CONFIRMEDに）できます。

aws cognito-idp admin-set-user-password \

  --user-pool-id <あなたのユーザープールID> \

  --username <テスト用メールアドレス> \

  --password <設定したいパスワード> \

  --permanent

• –permanent: これを付けることで、「パスワード変更完了」の状態になります。
• ユーザープールIDの調べ方: AWSコンソールのCognito画面のトップに ap-northeast-1_xxxxxx のような形式で表示されています。

2-4.なぜテスト専用ユーザーが必要なのか？

E2Eテストでは、実際にサインイン処理を行います。以下の理由から、本番や個人で使っているアカウントとは分けるのが鉄則です。

• 認証情報の秘匿: GitHub ActionsのSecretsにパスワードを登録するため、万が一の漏洩リスクを最小限にします。
• 多要素認証（MFA）の回避: 本番アカウントでMFAを有効にしている場合、自動テストが突破できなくなります。テスト用ユーザーはMFAオフの状態で運用するのが一般的です。

2-5.CI（GitHub Actions）を動かすための次のステップ

CIでE2Eを成功させるには「環境情報（amplify_outputs.json）」をGitHubに教える必要があります。

1. Base64エンコードの取得: WSL2のターミナルで以下を実行し、表示された長い文字列をコピーします。

base64 -w 0 amplify_outputs.json

2. GitHub Secretsへの登録: GitHubのリポジトリ画面から Settings > Secrets and variables > Actions へ進み、Claudeのリストにある3つの値を登録します。

これで、Pushするたびに「ログイン → 投稿 → 削除 → トースト確認」という一連のユーザー行動を、AWSの実環境に対して自動検証するCIパイプラインが完成します。

以下の通りClaude Codeに指示します。

「テスト専用のCognitoユーザー作成（ステータス：CONFIRMED）と、GitHub Secrets（E2E_EMAIL, E2E_PASSWORD, AMPLIFY_OUTPUTS_BASE64）およびVariables（E2E_ENABLED）の登録が完了しました。

現在のブランチ fix/integrated-audit-findings にある変更内容（Playwright導入、CI設定、ドキュメント更新）を最終確認し、問題なければGitHubへPushしてください。Push後、GitHub ActionsでE2Eテストが正常に起動することを確認したいです。」

テストの仕様書も作成しておきます。

「今回実装し、CIで成功したPlaywrightのテスト内容を、「E2Eテスト仕様書」として Markdown形式で docs/e2e-test-spec.md にまとめて出力してください。

以下の項目を含めて整理してください：

1. テスト目的: このテストで何を保証しようとしているか
2. テスト前提条件: ログインユーザーや環境設定について
3. テストケース一覧:
   • 各テスト名
   • 操作手順（Step by Step）
   • 期待値（何を確認しているか）
4. 使用セレクター: どのような属性（Label, Roleなど）を使って要素を特定しているか（アクセシビリティへの配慮も含めて）」

3. OpenAI APIを活用した自動レビュー

3-1. ワークフロー作成

GitHub Actions を利用して、「プッシュ」というイベントをトリガーに AI レビューを実行する設定を追加することで実現できます。

Claude Code に以下のように指示を出して、設定ファイルを作成・コミット・プッシュさせます。※openai/codex-plugin-ccというプラグインは、現在はアーカイブされているようです。

「GitHub Actions を使用して、プッシュ時に openai/codex-plugin-cc（または同様の AI レビュー機能）でコードレビューを自動実行するワークフローを作成してください。

1. .github/workflows/ai-review.yml を新規作成する。
2. on: push および on: pull_request をトリガーにする。
3. プラグインの実行に必要なシークレット（例: OPENAI_API_KEY）を使用する構成にする（※シークレットの登録は後で人間が行います）。
4. この新しいワークフローをコミットして、リモートにプッシュしてください。」

無料範囲（または月額契約の範囲）でどうにかできないかなと考えていたのですが、従量課金APIを使用する形が一番きれいにできそうに見えたので、仮に使用しました。ただ、工夫によっては余計な費用はかけずにレビューさせることもできそうに思います。今回はトークン消費量も大したことが無いと思いますので、APIの勉強がてら使ってみました。

3-2.APIをCLIから利用するために人間がやってあげるべきこと

AI レビューを実行するには、OpenAI の API キーなどが必要です。GitHub Secrets に追加の設定を行います。

1. GitHub リポジトリ > Settings > Secrets and variables > Actions を開く。
2. OPENAI_API_KEY を登録する（OpenAI の管理画面から取得した API キー）。

まとめと次回

今回の開発では、生成AI（AIエージェント）が単なるコーディングをするツールではなく、総合的にプロジェクトを俯瞰して設計、品質改善していける非常に強力な存在だということが分かりました。まとめると、今回は簡単なアプリだったものの、以下のことが一人で、しかも短期間でできてしまいました。

1. ワークフローの自動化

「AIレビュー → 課題の起票 → テストコード生成 → マージ → 環境のクリーンアップ」という一連のサイクルをAIエージェント（Claude Code）が自律的に実行しました。人間が手を動かすとどうしても時間がかかってしまう作業をAIに委ねる形が完成しました。

2. E2Eテストによる品質の可視化

ユーザーの操作を模倣するPlaywrightを活用することで、E2Eテストを自動化しました。実環境（AWS sandbox）に対して「ログイン・投稿・削除・通知確認」という一連の行動を自動検証する仕組みを構築し、リグレッションテストも容易に行えるようになりました。

3. ドキュメントの資産化

README、機能仕様書、テスト仕様書をMarkdown形式で整備しました。特にMermaid.jsを用いた図解により、複雑な削除フロー（S3とDBの同期）を「見える化」したことで、人間が見てもプロジェクトの見通しが良くなるようにして、将来の自分がメンテナンスしやすい環境を整えました。

4. AIの相乗効果

Gemini：技術選定の相談やプロンプトの壁打ち（伴走者）。

Codex：コードの静的解析。

Claude Code：対話による挙動修正とワークフローの実行。

※モデルの精度などにより異なるトークン消費量、課金状況を考えつつ、今回はこれらを活用しました。ほかにも多数の生成AIがありますし、コストパフォーマンスがよいものや、精度、向き不向き、いろいろ可能性がありそうです。

言うまでもなくAIは非常に強力ですが、ところどころ思ったのと違う方向へエージェントが進んでいったり、間違った回答をする場面もありました。危険な操作に対して、ルール（「ガードレール」（監視・制限する安全装置））を作成して品質・安全を担保（「ハーネス」（馬具・安全帯）」のような制御）する必要性もあると思います。また、セキュリティ面（情報漏洩など）での懸念は、AIエージェントが高性能になるほど人間がルールや運用を考え、対策しなければならないと感じます。

余談ですが、AIエージェント（今回はClaude Code）にコーディングなどを任せると、特段設定していない限り「○○していいですか？」というダイアログが頻繁に表示されます。これは、とにかく作業を終えてほしい場面ではとにかく「Yes」を押したくなるのが人情ですが、やってはいけないコマンド・操作が含まれていた場合致命的な結果となりえると感じます。面倒くさがらず、確認したいと思います。（自戒も込めて）

生成AIにまだまだ勉強の余地はありそうです。これからも学習を続けていきたいと思います。

次回はコチラ【第5回】AIエージェントと一緒にクラウド日記アプリ開発してみる：リファクタリング、ガードレール、フック設計と実装編

1. Mermaid.js: GitHubで標準サポートされている作図ツール。GitHub Mermaid Documentation ↩︎

投稿者プロフィール

NodaYukiko

最新の投稿

• 【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】