はじめに
新機能の実装は、ソフトウェア開発において最もクリエイティブでやりがいのある作業ですが、同時に最も時間を要するプロセスでもあります。要件の理解、設計、実装、テスト、レビュー、デプロイと、多くのステップを経る必要があります。
OpenAI Codexは、この機能開発プロセスを根本から変革できます。機能仕様を与えれば、Codexがスキャフォールディングを生成し、実装を進め、テストを追加し、PRを作成するところまで自律的に実行します。さらに、複数の機能開発タスクを並列で実行できるため、開発サイクルを大幅に短縮できます。
本記事では、新機能の実装をCodexに効果的に委任し、開発サイクルを高速化する方法を解説します。
前提条件
本記事の内容を実践するには、以下の準備が必要です。
| 要件 | 詳細 |
|---|---|
| ChatGPTプラン | Plus、Pro、Business、Edu、Enterpriseのいずれか |
| GitHub連携 | Codexとの接続設定が完了していること |
| 環境設定 | 対象リポジトリの環境が作成済みであること |
| AGENTS.md | プロジェクトの規約が記述されていること（推奨） |
基本操作やAGENTS.mdの設定については、シリーズの前回までの記事を参照してください。
機能開発における非同期委任の考え方
従来の開発では、エンジニアが機能実装のすべてのステップを順番に実行していました。Codexを活用すると、このワークフローを「設計・判断」と「実装・検証」に分離し、後者を非同期で委任できます。
flowchart TD
subgraph "人間の作業（設計・判断）"
A[機能要件の定義] --> B[タスク分解と優先度付け]
B --> C[技術的な設計判断]
C --> D[最終レビューと承認]
end
subgraph "Codexへの委任（実装・検証）"
E[スキャフォールディング生成] --> F[ビジネスロジック実装]
F --> G[テストコード作成]
G --> H[リファクタリング]
H --> I[PR作成]
end
B --> E
I --> Dこのアプローチの最大の利点は、エンジニアが設計判断やコードレビューといった高付加価値の作業に集中できる点です。実装作業がバックグラウンドで進行するため、複数の機能を並行して進められます。
機能仕様からタスクを作成する
効果的な機能仕様の書き方
Codexに機能実装を依頼する際、仕様の書き方が成果を大きく左右します。以下の要素を含めると、精度の高い実装が得られます。
機能仕様テンプレート
|
|
Codex Webからのタスク作成
Codexダッシュボードから機能実装タスクを作成する方法です。
手順
- Codexダッシュボード（https://chatgpt.com/codex）にアクセス
- 対象リポジトリの環境を選択
- 「コード」タブで機能仕様を入力
- タスクを送信
プロンプト例
以下の機能仕様に基づいて、お気に入り機能を実装してください。
## 機能概要
ユーザーが商品をお気に入りリストに追加・削除できる機能
## 実装要件
1. FavoritesServiceクラスを新規作成
- addFavorite(userId, productId): Promise<void>
- removeFavorite(userId, productId): Promise<void>
- getFavorites(userId): Promise<Product[]>
2. APIエンドポイントの実装
- POST /api/v1/favorites - お気に入り追加
- DELETE /api/v1/favorites/:productId - お気に入り削除
- GET /api/v1/favorites - お気に入り一覧取得
3. フロントエンドコンポーネント
- FavoriteButton: 商品カードに配置するトグルボタン
- FavoritesPage: お気に入り一覧ページ
## 制約
- 既存のコーディング規約に従う
- 各機能にユニットテストを追加
- TypeScriptの型定義を適切に行う
まずサービス層から実装を開始し、テストが通ることを確認してからAPIとフロントエンドに進んでください。
IDE拡張機能からのクラウド委任
VS Code、Cursor、WindsurfなどのIDE拡張機能を使用すると、ローカルでの計画立案からクラウドへの委任までシームレスに行えます。
ローカルでの計画立案
$plan
お気に入り機能を実装する計画を立ててください。
要件:
- バックエンド: NestJS
- フロントエンド: React + TanStack Query
- データベース: PostgreSQL（Prisma ORM）
以下を含めてください:
- 実装するファイルの一覧
- 依存関係を考慮した実装順序
- 各ステップの見積もり工数
- リスクと対策
Codexが計画を提示したら、内容を確認し、必要に応じて調整を依頼します。
クラウドへの委任
計画が固まったら、IDE拡張機能のクラウドアイコンをクリックし、クラウド環境を選択します。次のプロンプトを入力すると、Codexがクラウドで実装を開始します。
計画のステップ1を実装してください。完了したらテストを実行し、結果を報告してください。
スキャフォールディングの自動生成
スキャフォールディングとは
スキャフォールディングとは、アプリケーションの骨格となるコード構造を自動生成することです。ディレクトリ構造、基本的なファイル、ボイラープレートコードなどが含まれます。
Codexは、プロジェクトの既存構造を分析し、一貫性のあるスキャフォールディングを生成できます。
効果的なスキャフォールディング依頼
プロンプト例：新規モジュールの作成
新しい「notifications」モジュールのスキャフォールディングを生成してください。
参考にすべき既存モジュール: src/modules/users
生成するファイル:
- notifications.module.ts
- notifications.controller.ts
- notifications.service.ts
- dto/create-notification.dto.ts
- dto/update-notification.dto.ts
- entities/notification.entity.ts
- notifications.repository.ts
- tests/notifications.service.spec.ts
- tests/notifications.controller.spec.ts
既存の命名規則、インポートパターン、エラーハンドリングパターンを踏襲してください。
AGENTS.mdによるスキャフォールディングルールの定義
プロジェクト固有のスキャフォールディングルールをAGENTS.mdに記述しておくと、Codexが一貫したコード構造を生成します。
AGENTS.mdの記述例
|
|
実装の段階的な依頼
マイルストーン方式の採用
大きな機能を一度に実装させるより、マイルストーンに分割して段階的に依頼する方が成功率が高くなります。
flowchart LR
M1[マイルストーン1<br/>データ層] --> M2[マイルストーン2<br/>サービス層]
M2 --> M3[マイルストーン3<br/>API層]
M3 --> M4[マイルストーン4<br/>UI層]
M4 --> M5[マイルストーン5<br/>統合テスト]マイルストーン1：データ層の実装
マイルストーン1: データ層を実装してください。
実装内容:
1. Notification エンティティの定義
- id: UUID
- userId: string
- type: enum (INFO, WARNING, ERROR)
- title: string
- message: string
- isRead: boolean
- createdAt: DateTime
- readAt: DateTime | null
2. Prismaスキーマの更新
3. NotificationsRepositoryの実装
- create(data: CreateNotificationDto): Promise<Notification>
- findByUserId(userId: string): Promise<Notification[]>
- markAsRead(id: string): Promise<Notification>
- deleteByUserId(userId: string): Promise<void>
4. リポジトリのユニットテスト
完了後、マイグレーションを実行し、テストがパスすることを確認してください。
マイルストーン2：サービス層の実装
マイルストーン2: サービス層を実装してください。
前提: マイルストーン1で作成したリポジトリを使用
実装内容:
1. NotificationsServiceの実装
- createNotification(userId, data): 通知作成
- getUserNotifications(userId, options): 通知一覧取得（ページネーション対応）
- markAsRead(notificationId): 既読にする
- markAllAsRead(userId): 全件既読
- getUnreadCount(userId): 未読件数取得
2. ビジネスロジックの実装
- 同一ユーザーへの重複通知は5分間抑制
- 通知は90日後に自動削除（soft delete）
3. サービス層のユニットテスト（モック使用）
テストカバレッジ80%以上を目標としてください。
並列実装の活用
依存関係のない部分は並列で実装を進められます。Codexのクラウド環境では複数のタスクを同時に実行できるため、この特性を活かします。
flowchart TD
A[機能仕様の確定] --> B[タスク1: バックエンドAPI]
A --> C[タスク2: フロントエンドUI]
A --> D[タスク3: E2Eテスト準備]
B --> E[統合]
C --> E
D --> E
E --> F[統合テスト実行]並列タスクの起動方法
- Codex Webで最初のタスク（バックエンドAPI）を送信
- 別のタブを開き、2つ目のタスク（フロントエンドUI）を送信
- 必要に応じて3つ目のタスク（E2Eテスト準備）を送信
各タスクは独立したサンドボックス環境で実行されるため、互いに干渉しません。
コードレビューとフィードバックループ
Codexの作業結果を確認する
Codexがタスクを完了すると、以下の情報が提供されます。
- 変更されたファイルのdiff
- 実行されたコマンドのログ
- テスト結果の引用
- 作業内容の要約
確認すべきポイント
| 観点 | 確認内容 |
|---|---|
| 機能要件 | 仕様どおりに実装されているか |
| コード品質 | 既存のコーディング規約に従っているか |
| テスト | 十分なテストカバレッジがあるか |
| セキュリティ | 脆弱性を含んでいないか |
| パフォーマンス | N+1問題などがないか |
フィードバックの伝え方
Codexの出力に修正が必要な場合、具体的なフィードバックを与えることで改善を依頼できます。
効果的なフィードバックの例
以下の点を修正してください。
1. NotificationsService.createNotification()
- トランザクション処理が不足しています
- ユーザー存在確認を追加してください
2. notification.entity.ts
- createdAtにデフォルト値が設定されていません
- インデックスが不足しています（userIdとcreatedAtの複合インデックス）
3. テスト
- 異常系のテストケースが不足しています
- 特に、存在しないユーザーIDを指定した場合のテストを追加してください
修正後、再度テストを実行して結果を報告してください。
GitHubでのコードレビュー連携
Codexが作成したPRに対して、GitHub上で@codexをメンションすることでレビューやフォローアップを依頼できます。
PRコメントでのフィードバック
|
|
Codexはコメントを読み取り、指摘された問題を修正し、同じPRを更新します。
本番環境へのデプロイ
デプロイ前の最終確認
機能実装が完了し、PRがマージ可能な状態になったら、デプロイ前の最終確認を行います。
確認チェックリスト
|
|
CI/CDパイプラインとの連携
Codex GitHub Actionを使用すると、CI/CDパイプラインにCodexを組み込めます。
GitHub Actions設定例
|
|
この設定により、PRが作成または更新されるたびに、Codexが自動的にコードレビューを実行します。
フィーチャーフラグを活用したリリース
新機能のリリースリスクを軽減するために、フィーチャーフラグの実装をCodexに依頼することもできます。
プロンプト例
通知機能にフィーチャーフラグを実装してください。
要件:
- 環境変数 FEATURE_NOTIFICATIONS_ENABLED で制御
- フラグがfalseの場合、APIは503を返す
- フロントエンドはフラグに応じてUIを非表示にする
- 管理画面から動的に切り替え可能にする（将来対応のための設計のみ）
既存のFeatureFlagServiceを拡張して実装してください。
実践的なワークフロー例
ケーススタディ：通知機能の完全実装
ここまでの内容を踏まえ、通知機能の実装を例に、実際のワークフローを見ていきます。
Day 1: 設計と計画
$plan
通知機能を実装する計画を立ててください。
機能要件:
- プッシュ通知、メール通知、アプリ内通知の3種類
- ユーザーごとの通知設定（種類別のオン/オフ）
- 通知履歴の保存と一覧表示
- 未読件数のバッジ表示
技術スタック:
- バックエンド: NestJS + PostgreSQL
- フロントエンド: Next.js + TanStack Query
- プッシュ通知: Firebase Cloud Messaging
制約:
- 既存の認証システムと統合
- 1日あたり100万件の通知を処理可能な設計
- マイクロサービスへの移行を見据えた疎結合な設計
5つのマイルストーンに分割し、各マイルストーンの依存関係と所要時間を示してください。
Day 2-3: マイルストーン1-2の並列実行
# タスク1（クラウド）
マイルストーン1を実装してください。
- データベーススキーマ
- エンティティ定義
- リポジトリ層
# タスク2（クラウド）
マイルストーン2を実装してください。
- 通知サービスの基本実装
- 通知設定サービス
- ユニットテスト
Day 4: 統合とAPI実装
マイルストーン1と2の成果物をマージしました。
マイルストーン3を実装してください。
- REST APIエンドポイント
- WebSocket接続（リアルタイム通知用）
- Swaggerドキュメント
- E2Eテスト
Day 5: フロントエンド実装
マイルストーン4を実装してください。
- 通知ベルコンポーネント
- 通知一覧ページ
- 通知設定ページ
- React Queryのカスタムフック
- コンポーネントテスト
Day 6: 統合テストとデプロイ準備
マイルストーン5を実行してください。
- 全体の統合テスト
- パフォーマンステスト
- ドキュメントの最終更新
- デプロイスクリプトの準備
効率化のためのTips
- テンプレートの活用: よく使う機能仕様のテンプレートをAGENTS.mdに含めておく
- スキルの活用:
$planや$skill-creatorなどの組み込みスキルを活用する - 並列実行の最大化: 依存関係を分析し、可能な限り並列でタスクを実行する
- 早期フィードバック: 小さな単位で確認し、問題を早期に発見する
- 自動化の推進: CI/CDパイプラインにCodexを組み込み、レビューを自動化する
まとめ
本記事では、OpenAI Codexを活用した新機能実装の非同期委任について解説しました。
機能開発をCodexに委任する際のポイントは以下のとおりです。
- 機能仕様を明確かつ詳細に記述する
- マイルストーンに分割して段階的に依頼する
- AGENTS.mdでプロジェクト固有のルールを定義する
- フィードバックループを回して品質を向上させる
- CI/CDパイプラインと連携してデプロイまで自動化する
Codexを活用することで、エンジニアは設計判断やコードレビューといった高付加価値の作業に集中できます。実装作業をバックグラウンドで進行させながら、複数の機能を並行して開発することで、開発サイクルを大幅に短縮できます。
次回の記事では、Codex CLIを使ったローカル環境でのAIコーディングエージェント活用について解説します。