AI支援プログラミング：モデル選択ガイド

目的と想定ユースケース

このガイドは、以下の状況を想定してモデルを選ぶための実用的な指針です：

設計書とガイドラインに基づいてコードを改善・生成したい
リファクタリング（refactor）、移行（migration／rewrite）、大規模ドキュメントの整合性保持
効率的にパイプライン（設計理解 → 生成 → 検証）を組みたい

各モデルの要点（短く）

GPT-5-Codex

強み：コード特化。企業向けソースコードのリファクタリング・厳密なコーディング規約適用に最適。

弱み：長文ドキュメント（100+ページ）理解は Claude に劣る。設計の不備を自動で補完しすぎる可能性。

GPT-5

強み：設計書の抽象理解・アーキテクチャ推論に強い。ビジネス意味を踏まえたコード提案が得意。

弱み：コードの細部（企業レベルの厳密さ）は Codex に一歩劣る。時に過度に推論して設計意図からずれる。

GPT-4.1

強み：安定・高速・コスト効率が良い。軽量なコード改善や大量バッチ処理向け。

弱み：大規模／複雑ロジックの理解やマルチファイル整合性は弱い。

GPT-4o

強み：マルチモーダル（画像／スクリーンショット）から設計を読み取りやすい。処理速度が速い。

弱み：純粋なコード生成能力は GPT-5 系より弱い。大規模重構には不向き。

Claude Sonnet 4.5

強み：長文ドキュメント理解・ガイドライン整合性に極めて強い。ドキュメントに忠実な出力。

弱み：コード細部（並列処理やフレームワークの複雑処理）で GPT 系に劣る。過度に保守的。

モデル選択の簡易意思決定フロー

下は実運用で使える短い意思決定ルールです。

コードの厳密な品質／重構が最優先 → GPT-5-Codex
設計書からアーキテクチャを推論したい → GPT-5
入力がPDF・スクリーンショット・図中心 → GPT-4o（抽出）→ その後 Codex/GPT-5 へ渡す
設計書/ガイドラインが非常に長く、一貫性チェックが必要 → Claude Sonnet 4.5
大量の軽微なクリーニングや定型修正 → GPT-4.1（コスト効率重視）

一言まとめ：「ビジネス／設計理解 → GPT-5、コード品質／重構 → GPT-5-Codex、文書整合性 → Claude」

推奨パイプライン（実運用パターン）

設計理解フェーズ（GPT-5）
- 設計書を要約し、アーキテクチャ要件・インタフェース一覧・制約を抽出する。
- 出力：architecture summary / code-style constraints / interface map
構文抽出（必要なら GPT-4o）
- 設計書が画像やスキャン中心の場合、GPT-4o でテキスト抽出・図の意味解釈を行う。
コード生成・重構（GPT-5-Codex）
- 実際のコード改善、厳密なコーディング規約適用、リファクタリングを実施。
- 入力：既存コード + architecture summary + guideline
長文整合性チェック（Claude Sonnet 4.5、オプション）
- 長い guideline 全体に対する一貫性チェックや命名規則の横断検証に使用。
軽量バッチ処理／自動化（GPT-4.1）
- 単純なフォーマット修正や lint ベースの自動修正を大量に流す際に使う。
自動テスト生成 & CI 統合（組合せ）
- Codex で unit test を生成、GPT-5 でテスト方針を検討、CI 設定は GPT 系でテンプレート作成。

実務では上記を組み合わせ（例：GPT-4o → GPT-5 → GPT-5-Codex → Claude）することで、精度と効率を両立できます。

モデルごとの「弱点」まとめ（表）

モデル	主な弱点	不適用・注意点
GPT-5-Codex	長文ドキュメント理解は劣る／設計の不備をそのまま厳密に反映しうる	100+ ページの設計書単独での解釈には不向き
GPT-5	コード細部の工夫（企業レベル品質）は Codex に劣る／過度に補完する傾向	細かな style conformity が必要な場合は追加検証が必要
GPT-4.1	複雑ロジックの深い理解が弱い／マルチファイル整合性で漏れが出やすい	大規模重構や複雑フレームワークへの適用は控える
GPT-4o	純粋なコード生成能力は GPT-5 系より弱い／長文解析は弱め	図やスキャン処理に強い反面、生成は別モデルに委譲
Claude Sonnet 4.5	コード生成・高並列処理やフレームワークの深い知識は GPT 系が上／保守的	設計の不備を自動修正してほしい場面には不向き

実践的なプロンプト例（テンプレート）

そのまま使える簡易テンプレートを示します。

設計理解（GPT-5 用）

以下の設計書（要約 or テキスト）を読み、次を出力してください：
1) システム概要（2〜4行）
2) 主要コンポーネントと責務（箇条書き）
3) インタフェース一覧（メソッド名・引数・返り値・例外）
4) コードスタイル制約（命名規則、アノテーション使用方針）

設計書：
<ここに設計書テキストを貼る>

コード改善（GPT-5-Codex 用）

あなたはシニア Java エンジニアです。以下を守りつつ、既存コードを改善してください：
- 出力は変更差分（patch）形式
- コードスタイル：<architecture summary の "code-style constraints" を貼る>
- 目的：可読性向上、テスト容易性、パフォーマンス維持

既存コード：
<ここにコードを貼る>

ヒント：設計書に曖昧な点がある場合、GPT-5 に「不明点のリスト」を作らせ、確認後に Codex に渡すと安全です。

運用上の実務アドバイス

モデルは組み合わせて使う：一つのモデルに全てを任せない（例：GPT-4o で抽出 → GPT-5 で理解 → Codex で改善）。
「ガイドラインの一貫性チェック」は Claude が得意。最終レビューに使うと良い。
自動生成コードは必ず CI とテストで検証し、人間のコードレビューを残す。
コストと速度のバランスを常に考慮：大量処理は GPT-4.1、重要箇所は Codex / GPT-5。