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

ホーム
BLOG
【AI】, 【AWS】, 【Next.js】
【第3回】AIエージェントと一緒にクラウド日記アプリ開発…

【Next.js】
2026.04.15

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

　前回の投稿はコチラ：【第2回】AIエージェントと一緒にクラウド日記アプリ開発してみる：Next.jsフロントエンド構築・Cognito認証導入・画像投稿実装編【AWS Amplify Gen 2 × Cursor × Claude Code】

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

第3回の概要

前回（第2回）は、Amplify Gen 2とClaude Codeを駆使して、画像のアップロード機能とS3ストレージの構築を完了させました。AI登場前の自習なら、ここまでで十分満足してしまいそうな成果です。

今回は、さらに踏み込んでみたいと思います。AIを大いに活用しているisubの同僚からアドバイスをもらった複数AI（Codex（ChatGPT）とClaude Code）による並行レビューを実施して、レビュー指摘はGitHub Issuesに起票させ、GitHub Actionsとの連携による自動単体テストも行い品質をアップさせていきたいと思います。

使用するツール

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（継続的インテグレーション/継続的デプロイ）プラットフォーム。
GitHub Issues: プロジェクトの課題管理システム。実装すべき機能やバグ、AIへの具体的な指示内容（プロンプト）をチケット化するのに活用。
Codex（GPT-5.4をCodexデスクトップアプリで使用）: OpenAIが開発した高度なプログラミング支援AI、現在はアプリ名称。もともとCodexはモデル名称だったようですが、今は単に「Codex」というとツール名を指すのかなと考えています。ただ、モデル名にも残っているようです。単語が指すものが移り変わっているようで理解に若干苦労しました。CursorやClaude Codeの背後で働き、コードのセカンドオピニオンや実装の最適化を提案するアドバイザーとして活用。

GPT-5.4（Codexデスクトップアプリ）によるレビュー
GittHub Issuesへの起票と環境構築
Claude Codeによる修正とレビューの統合
自動テストの追加とプルリクエスト作成
マージとクローズ
Github Actionsでプッシュ時に単体テストを行う（CI）
まとめと次回

1. GPT-5.4（Codexデスクトップアプリ）によるレビュー

概要

まずは、Codexデスクトップアプリ（OpenAIモデルを利用したIDE：https://openai.com/ja-JP/index/introducing-the-codex-app/）を使用して、客観的なコードレビューを行います。

ちなみに、今回失敗した2点がありますので、以下に記載します。今後再チャレンジ予定です。

Claude Codeで利用するためのプラグイン使用するとよいと同僚からアドバイスをもらっていたのですが、すっかり忘れてデスクトップアプリからレビュー依頼していました。。（Claude Codeで完結できた方が圧倒的に効率は良いと思います）
Codexデスクトップアプリでは使用するモデル※が選べるのですが、今回はGPT-5.4で実行してしまいました。GPT-5.3-Codexのほうがレビューには向いていそうです。

※補足（Geminiに説明してもらいました）：

守備範囲と統合性（汎用 vs 特化）

GPT-5.4: 「統合モデル」として設計されており、GPT-5.3 Codexが持っていた高度なコーディング能力を標準機能として吸収しています。つまり、コードも書ける上に、スプレッドシートの分析、スライド作成、高度な推論、文書作成などもトップレベルでこなせる「フルスタック」なモデルです。

GPT-5.3 Codex: ソフトウェア開発に特化したモデルです。コードの生成、デバッグ、ターミナル操作、リポジトリ全体の管理に最適化されています。特定のプログラミングタスクにおいて非常に高い精度を誇りますが、一般的な文書作成やビジネス分析は守備範囲外（または標準的）です。

1-1. インストールと初期設定

インストール: 公式サイトからインストーラー（.exe / .msi）を取得し、ウィザードに従いセットアップします。
API設定: アプリ起動後、ChatGPT Pro/Plusなどの月額契約をしていればアカウント情報を入力します。または、OpenAIのAPI Keyを設定画面に入力します。※料金の詳細は公式サイトを参照してください。
スコープ指定: レビュー対象のディレクトリをドラッグ＆ドロップし、チャット欄で「このディレクトリ内の主要なロジックをレビューして」と依頼します。

1-2. レビュー結果の統合

Codexが「S3の孤児オブジェクト問題」などの潜在的なバグを指摘しました。これを後ほどClaude Codeと連携させるため、Markdown形式で結果をコピーしておきます。

2. GitHub Issuesへの起票と環境構築

AIに課題を確実に修正させるため、GitHub上でチケット管理（Issue化）を行います。

2-1. GitHub Issues の初期セットアップ

有効化: リポジトリの Settings > General > Features から「Issues」をオンにします。
ラベルの整理: ai-reviewed ラベルを作成しておくと、AIが対象の課題を識別しやすくなります。

2-2. GitHub CLI (gh) の導入と認証

Claude CodeがターミナルからGitHubを操作するために、GitHub CLIをインストールします。

# Windows
winget install --id GitHub.cli
# 認証を実行
gh auth login

※ 認証プロトコルは HTTPS、ブラウザ経由のログイン（web browser）を選択し、ワンタイムコードで承認します。

2-3. スクリプトによる「Issue流し込み」の自動化

Codexのレビュー結果を、クリップボード経由でIssueへ一瞬で登録するためのユーティリティ（Pythonスクリプト）を用意しました。（この工程はちょっと回り道してしまっています。Claude CodeからCodexプラグインを利用すれば、おそらくClaude Code上で完結できるように思います。）

これを実行することで、ブラウザを開く手間なく [P1] AI並列レビュー結果の反映というIssueが作成されます。

3. Claude Codeによる修正とレビューの統合

作成したIssueをClaude Codeに読み込ませ、コードの修正と追加レビューを依頼します。

3-1. 役割の定義と追加レビュー

Claude Codeに対し、シニアエンジニアの視点で「DRY原則」「TypeScriptの厳格化」「エラーハンドリング」に注力するよう指示します。

ポイント: Codexの指摘をIssueから読み取らせるだけでなく、Claude自身にも追加レビューを命じ、両者の指摘を1つのIssueに集約（統合）させます。

3-2. mission.mdによる「完遂」の指示

確実に作業を完了させるため、以下の手順を記した mission.md をルートに作成し、Claude Codeに実行を命じます。

ブランチ作成: fix/integrated-audit-findings
一括修正: S3ロールバック、JST日付、エラーハンドリングの徹底
検証: npx tsc –noEmit による型チェック

4. 自動テストの追加とプルリクエスト作成

4-1. 5つのテストプランを自動テスト化

以下の項目を自動でテストできるように、Vitest + React Testing Libraryの構成をClaudeに構築させます。

画像付き日記削除時のS3オブジェクト消去確認
作成失敗時のS3ロールバック確認
深夜帯（23:00–01:00 JST）における日付の整合性
署名付きURLの自動リフレッシュ確認
型チェック（TSC）の通過

4-2. プルリクエスト（PR）の作成

修正とテストが完了したら、Claude Codeが gh pr create を実行し、詳細な要約とテストプランを記したPRを生成します。

5.マージとクローズ

GitHub上でPRの差分（Files changed）を確認します。特に以下の点が正しく実装されているかチェックします。

JST対応: toLocaleDateString(‘sv-SE’, { timeZone: ‘Asia/Tokyo’ })
堅牢性: try/catch による例外処理とS3ロールバック

5-1. マージの実行

内容を確認後、Confirm merge をクリックします。この瞬間、PRの説明文に含まれる Closes #1 の記述により、対応するIssueも自動的にクローズされます。

6.Github Actionsでプッシュ時に単体テストを行う（CI）

6-1.Github Actionsのセットアップ

依頼プロンプト例: 「単体テストが通るようになったので、次は GitHub Actions を設定して、GitHub に Push したりプルリクエストを作ったりした時に、自動で npm test が走るようにして。また、GitHub 上でテストがパスしないとマージできないような設定にしたいので、必要な yml ファイルの作成をお願い。」

GitHubのAPIを直接叩いて、リポジトリに以下のルールを追加しています。

required_status_checks: 「Typecheck & Unit Tests（先ほど作ったCI）」が成功（Green）していない限り、マージボタンを無効化します。
strict: true: 他の誰かが先にマージしてコードが古くなった場合、最新の状態に更新して再度テストを通すまでマージを許可しません。

私は知らずにClaude Codeにブランチ保護ルール作成まで依頼したのですが、GitHub の仕様により、無料プランのプライベート（非公開）リポジトリでは、「テストを通らないとマージさせない」という強制力を持った設定（Branch Protection Rules）を API や画面から設定することができないようです。

個人開発なので、無理に課金したり Public にしたりせず、「プルリクエスト画面のチェックマークを確認してからマージする」という運用ルールにしたいと思います。

運用の流れ:

コードを Push し、プルリクエストを作成。
画面下部の “Checks” セクションを見る。
“Typecheck & Unit Tests” が ✅ (Passed) になったら自分でマージボタンを押す。

6-2.簡単な変更で確認

依頼プロンプト例: 「日記投稿、削除時にトーストメッセージが表示されるように変更して。」

これは Claude Code が新しく作成した GitHub Actions（CI）の設定が、実際のローカル環境でも正しく動作するか最終確認をしようとしているステップです。

型チェック (tsc): .github/workflows/ci.yml を追加したことでプロジェクト全体の構成に矛盾が出ていないか。
単体テスト (npm test): これまで作った日記のバリデーションや S3 連携のテストがすべて正常にパスするか。

以下のように指示します。

「現在の main ブランチ（または作業中のブランチ）の変更内容を元に、GitHub プルリクエストを作成して。タイトルは feat: add toast notifications and automated CI として、説明文には今回の修正内容（トースト通知の実装、CI設定、テストの追加）を簡潔にまとめて。また、関連する Issue があればそれへのリンクも含めて。」

Claude Code がこれまでの作業内容（トースト通知、CI設定、テストコード）をまとめたプルリクエスト（PR）を GitHub 上に正式に作成しました。

GitHub Actionsを確認してみます。すると、エラーになっています。

6-3.テストエラーを解決

Claude Codeにこの結果（エラーが出ていること）を伝えて、修正させましょう。

「GitHub Actions (CI) が Failed になりました。最新の実行結果を確認して、原因を特定し、ci.yml またはコードを修正してテストが通るようにして。」

ここでは、画面が多数となるため詳細な流れは省略します。

CI パイプラインが完全に「緑（All Green）」になりました。

トースト通知の実装: OK
不整合の解消: Windows vs Linux の OS 間の壁を突破。
CI の安定化: rm -f package-lock.json という解決策の導入。

今回の「ネイティブバインディング（rolldown）」のトラブルは、簡単に言うと環境差異でした。

これで、今後コードを Push するたびに、GitHub Actionsで動作を確認できます。

結論から言うと、一番上にある以下の項目が成功していればOKということになります。

名称: feat: add toast notifications and automated CI
ステータス: 緑のチェックアイコン
詳細: CI #9: Pull request #3 synchronize by VirginiaOrlando12

Claude は最終的に、「CI 実行時に一度ロックファイルを削除してからインストールする」 という解決策を実行しました。

実行内容: rm -f package-lock.json && npm install
結果: CI サーバー（Linux）が、その場で自分に最適なバイナリと依存関係を計算し直し、すべてのテストがパスしました。

これは一応動くようにするにはアリなようですが、恒久的なベストプラクティスではないという、非常に微妙なラインの解決策だったようです。

今回のケースでは、「OS間のネイティブバイナリの不整合」という、ロックファイルの機能が逆に仇となってビルドを止めてしまう特殊な状況でした。Windowsで生成されたロックファイルが Linux に必要なバイナリ情報を「不要なもの」として削ぎ落としていたため、ロックファイルを維持する限り Linux 側では一生起動できない状態でした。

ファイルを削除するというコマンドはかなり注意を要すると個人的には考えています。実際の商用のアプリでは思いがけないファイルを削除することにも繋がりかねないので、この対策は非常に危険な内容だとも思います。学習用なので、きりのいいところまで作業するためにまずは「動く状態」を作るようにしました。

恒久対応策としては、Windows上のWSL2（Ubuntuなど）やDockerコンテナ内で npm install を実行し、ロックファイルを生成してnpm ciをそのまま使えるようにしたいと思います。この対策により、生成されたロックファイルは、最初からLinux（GitHub Actions）と互換性があるため、CI側で npm ci（ロックファイルを厳守するモード）がそのまま使えるようです。そのため、次回以降では改善したいと思います。