４日間でClaudeにドキュメントを8件書かせて、全てCodeXにレビューさせる開発フローをやって得られた効果と失敗
はじめに
「AIにドキュメントを書かせて、別のAIにレビューさせる」
そんな開発フローを4日間試してみたところ、毎回のように鋭い指摘が入ることがわかりました。本記事では、私が業務中に行ったClaude（ドキュメント作成）× CodeX（レビュー）の組み合わせで得られた実践知見を共有します。
なぜドキュメントを作成するのか
AIを活用した開発では、いきなりコードを書かせるのではなく、事前にドキュメントを作成することが重要です。
ドキュメント作成の重要性についてはこちらの記事で詳しく解説していますので、ご覧ください。
作成するドキュメントの種類
開発プロセスで以下の2種類のドキュメントを作成しています。
| ドキュメント | 目的 |
|---|---|
| 影響範囲調査書 | 変更が及ぼす範囲を事前に洗い出す |
| 実装計画書 | 具体的な実装手順とテスト方針を定める |
使用するモデル
ドキュメント作成
- Claude
- 執筆当時はOpus 4.5（高い文章生成能力を活用）を使用
- 最近Opusの割引期間が終わり、GitHub Copilotの場合通常の３倍トークンを消費するため、余裕がある時だけOpusを使用
- 通常は Sonnet 4.5で作成するように切り替えた
レビュー
- CodeX（GPT-5.1ベース）
- トークン節約時はCodeX-miniを使用（通常の約1/3のコスト）
- miniでも巨大なドキュメントでなければ精度は十分
この役割分担には理由があります。
まず、Claude Opus 4.5は人間の目から見てとても読みやすい文章を作成するモデルで、主にこれで作成します。しかし、時折作成するドキュメントの中でミスがある時があります。
そこでレビューにはCodeXを使用します。CodeXはソースコードの理解・実装に強いモデルです。ドキュメントのレビュー時に実際のソースコードを確認して整合性を調査しています。
ソースコードには強いモデルですが、文章を作成させると人間の目には理解に時間がかかるものを出してくるのがネックです。
そのため、CodeXにはレビューに回ってもらい、Claudeがそのレビューを理解して修正するという流れを構築しました。
ドキュメント作成の流れ
- Claudeでドキュメントを作成する
- CodeXにレビューさせる
- レビュー指摘を元にClaudeで修正する
- 指摘がなくなるまで繰り返す(トークンに余裕がある時)
- ドキュメント類が完成したら実装を開始する
レビュー実績
12月頭からレビューを開始し、調査書4件、実装計画書4件、合計8件のドキュメントをレビュー済み。
すべての指摘を採用してドキュメントを修正しています。
| 項目 | 数値 |
|---|---|
| レビュー件数 | 8件 |
| 平均指摘件数 | 3件/ドキュメント |
| 総指摘件数 | 約24件 |
| レビュー時間 | 1〜2分/回 |
AIレビュー指摘の傾向分析
調査書・計画書をAIレビューにかけた結果、指摘は大きく5つのカテゴリに分類できました。
| カテゴリ | 発生頻度 | 主な内容 |
|---|---|---|
| フロー・前提の誤認識 | 🔴 高 | データフローの方向性、処理の前提条件の誤り |
| 技術的制約の未記載 | 🔴 高 | ライフサイクル、スコープ、プラットフォーム制約 |
| テスト影響の考慮漏れ | 🟡 中 | テストコードへの依存追加、テストケース不足 |
| DI・アーキテクチャの不整合 | 🟡 中 | 依存注入方式の誤り、設計パターンの不一致 |
| 仕様詳細の記載不足 | 🟡 中 | 境界条件、パラメータ受け渡し方法 |
具体的な指摘事例
影響範囲調査書での指摘
ここからは、私が担当しているAndroidアプリ開発プロジェクトで受けた指摘を例としています。
1. データフローの方向性を誤認
当初の記述
画面Aと画面Bでデータを双方向にやりとりする
CodeXからの指摘
「実際のコードを確認すると片方向フローになっている。画面AからBへのデータ受け渡しのみで、戻り値を受け取っていない。」
修正結果
Claudeが改めてCallbackコードなどを確認し、片方向フローの記述に修正しました。
2. データモデルの存在確認不足
当初の記述
既存のユーザ情報オブジェクトを利用して画面表示を行う
CodeXからの指摘
「該当のデータモデルに必要なフィールドがありません。APIレスポンスを確認すると、このデータはサーバから取得されていません。」
修正結果
データクラスの構造とAPIリクエストボディを改めて確認し、フィールドの新設が必要と修正しました。
3. 技術的制約の記載漏れ
当初の記述
ViewModelで状態を保持して画面間で共有する
CodeXからの指摘
「Activity間ではViewModelのスコープが共有されていません。また、onSaveInstanceStateが未実装のため、プロセス終了時のデータ復元ができません。」
修正結果
putExtraでActivity間のデータ復元をする選択をとりました。
実装計画書での指摘
1. テストコードの影響漏れ
当初の記述
実装手順にテスト修正が入っていない
CodeXからの指摘
「PresenterTestに対象クラスの依存が必要です。モック設定とテストケース追加のフェーズを追記してください。」
修正結果
改めてロジックコードを確認し、必要なテストコード修正の項目を計画書に追加。新規依存のモック化も手順に含めました。
2. DI（依存性注入）方式の不整合
当初の記述
val repository = Repository.getInstance()
CodeXからの指摘
「このプロジェクトはHiltを使用しています。@Injectによるフィールドインジェクションを使用してください。」
修正結果
@Inject
lateinit var repository: Repository
3. 境界条件・エッジケースの考慮不足
当初の記述
ユーザを追加するときに上限チェックを行う
CodeXからの指摘
「上限到達時に削除操作ができなくなる問題があります。isAlreadySelected判定を先に行い、選択済みユーザの削除は常に許可する必要があります。」
修正結果
追加だけでなく削除のケースも考慮した計画書に修正。上限値付近の振る舞いを詳細に記載し、状態遷移を網羅的に記述しました。
レビューを挟んだ効果
AIレビューを導入したことで、以下のような効果がありました。
✅ ポジティブな効果
- 人間が手直しするコードが大幅に減少
- 疲れていると見落としがちなテストケースの欠如を発見できる
- 実装手順をより正確に追えるようになった
- 意外にも、人間もドキュメントをしっかり読む意識が芽生えた
- どんな箇所に抜け漏れがあるのか視覚化され、ドキュメントの品質が安定した
💡 運用上の工夫
- 1次はAIレビュー、最終は人間レビューというハイブリッド運用
- 限られたトークンをどう温存するかの計画が必要
失敗した例
- 新しいファイルを作成してレビューしてと指示していなくて、CodeXが調査書を書き換えてしまった
- 対策: 「新しいファイルを作ること」を必ず明記する
- レビューはしたものの、本来はデフォルトがONになっていないといけないスイッチがOFFになっていた
- 対策: 結局は最後のチェックを人間が時間をかけて行う必要がある
- 添付資料を範囲選択し、「ここを修正したい」と言ったら、実装を開始してしまった
- 対策: 「調査書のここの記述を修正して」と目的語を入れる
AIレビューを効率化するコツ
AIレビューの精度を上げるためのプロンプトの書き方を紹介します。
実際に使用しているレビュープロンプト
ドキュメントを読み、修正が必要な箇所を新しいファイルを作成して記述してください。
シンプルなプロンプトですが、CodeXがコードベースを参照しながらドキュメントの整合性をチェックしてくれます。
1. 具体的なコードパスを記載する
| Before ❌ | After ✅ |
|---|---|
| 設定画面から変更する |
SettingFragment → SettingViewModel → SettingRepository
|
2. 前提条件を明示する
| Before ❌ | After ✅ |
|---|---|
| ユーザ情報を修正する | 前提条件: ログイン済み、APIからユーザ情報取得済み、キャッシュに保存済み |
3. 影響範囲を列挙する
| Before ❌ | After ✅ |
|---|---|
| 関連画面を修正する | チャットに添付資料として修正予定のコードファイルを指定する |
よくある質問（FAQ）
Q1. CodeXを使うにはどうすればいいですか？
CodeX のプラグインをIDEにインストールしたり、CLIをインストールしたりすれば使用できるようになります。
また、iOSアプリ限定にはなりますが ChatGPTのスマホアプリからでも使用可能です。
なお、有料プランに入ることが必要なためご注意ください。
サードパーティを使うものの一例を挙げておくと、GitHub Copilotを契約すると使えるようになります。
Q2. 他のAIモデル（Gemini等）でも代替できますか？
レビュー自体はできます。ただし、モデルによって精度はかなり変わるのでご注意ください。
Q3. 機密情報を含むドキュメントでも使えますか？
企業が契約した「学習に使用しない」と明記されたプランであれば使えます。
無料プランのものは学習される可能性があるため、厳禁です。
まとめ
本記事では、Claude × CodeXによるドキュメントレビューの実践例を紹介しました。
得られた知見
- AIが作成したドキュメントでも、別のAIにレビューさせると必ず指摘が入る
- 特に「フロー・前提の誤認識」「技術的制約の未記載」は発生頻度が高い
- 具体的なコードパスや前提条件を明示することで、レビュー精度が向上する
AIを複数組み合わせた開発フローは、まだ発展途上ですが、確実に開発効率の向上に寄与しています。ぜひ皆さんのプロジェクトでも試してみてください。
関連記事
ドキュメント作成プロセスの詳細。調査書・計画書の標準フォーマットとプロンプト例。
CodeXの多様な活用方法。スマホからの操作やPR作成など。
Copilotを業務で使って得た教訓。AIと開発する上での注意点。
Discussion