Codexのパラメーター設定の裏技！創造的なコードと正確なコードを自在に作り分ける方法

Codexのパラメーター設定の裏技！創造的なコードと正確なコードを自在に作り分ける方法

この記事では、AIコード生成モデル「Codex」（あるいは同等のコード生成AI）を使うときに、パラメーター設定を工夫して「創造的なコード」と「正確なコード」を自在に切り替える裏技を解説します。
「とにかく動くコードを素早くたくさん試したい」「一方で、本番環境向けには堅牢で再現性の高いコードを生成したい」といったニーズに応えるための、実践的なパラメーターチューニングの考え方をまとめました。

1. Codexで調整すべき主要パラメーターと役割

Codexや類似のコード生成AIでは、次のようなパラメーターを調整することで、出力の「創造性」と「正確性」のバランスをコントロールできます。

1-1. Temperature（温度）

• 役割： 出力のランダム性・創造性を決める中核パラメーター
• 値の範囲： 一般的に 0.0 ～ 1.0（実装によっては 2.0 まで）

数値が低いほど「保守的で決まりきったコード」になり、数値が高いほど「多様で意外性のあるコード」になりやすくなります。

• 0.0～0.2： 正確性重視・再現性が高い・ドキュメント通りの実装になりやすい
• 0.3～0.6： バランス型・実務コード生成向き
• 0.7～1.0： 創造性重視・アイデア出しやオルタナティブ提案に向く

1-2. Top_p（Nucleus Sampling）

• 役割： 「確率の高い候補トークン」だけをどこまで採用するかを決める
• 値の範囲： 0.0 ～ 1.0

Top_pが低いほど、安全圏の候補だけを使うため、堅実で似通ったコードになりやすくなります。一方で、Top_pを高くすると、確率の低い意外なトークンも採用されるようになり、多様なコードが生成されます。

• 0.1～0.3： 正確性・一貫性重視
• 0.4～0.8： バランス型
• 0.9～1.0： 多様性・創造性重視

Temperature と Top_p は基本的にどちらか片方だけを調整するのがおすすめです。両方を大きく動かすと挙動が読みにくくなります。

1-3. Max tokens（生成トークン数の上限）

• 役割： 一度の呼び出しで生成されるコード（テキスト）の長さを制御する

Max tokens を短くすると「短めのスニペット」を素早く多回生成するのに向き、
長くすると「クラス定義やモジュール全体」のようなボリュームのあるコード生成にも対応できます。

• ユーティリティ関数、ワンライナー：50～150
• APIクライアント、シンプルなクラス：150～400
• 小規模アプリ、複数関数：400～800 以上

1-4. Frequency penalty / Presence penalty

• Frequency penalty： すでに出現したトークンを繰り返しにくくするペナルティ（頻度ベース）
• Presence penalty： 一度でも出たトークンが再び登場しにくくなるペナルティ（出現有無ベース）

これらを上げると、同じパターンやフレーズの繰り返しが減り、多様なコードパターンが出やすくなります。ただし、コードでは import 文や def/class などの繰り返しが必要なことも多いので、多くの場合は 0（またはごく小さい値）から調整するのが安全です。

2. 「創造的なコード」を作らせるパラメーター設定の裏技

まずは、新しいアイデア・代替実装・異なる設計パターンを試したいときの、Codexのパラメーター設定のコツを解説します。

2-1. 創造性重視の基本セット

創造的なコード生成を促す、おすすめの初期設定は次の通りです。

temperature: 0.8 ～ 1.0
top_p      : 0.9 ～ 1.0（または固定 1.0）
max_tokens : 150 ～ 400
frequency_penalty: 0.2 ～ 0.6
presence_penalty : 0.2 ～ 0.6

この設定の狙いは、

• Temperature と Top_p を高めて、多様な候補を積極的に採用させる
• Penalty を少しだけかけて、同じ構造の繰り返しを避ける
• Max tokens は長すぎない範囲で、1つの設計アイデアを表現できる程度にする

2-2. 創造的コード生成に効く「プロンプトの型」

パラメーター設定と同じくらい重要なのがプロンプトの書き方です。創造性を引き出すには、あえて解の余地を残す指示を与えます。

例：

次の要件を満たす Python の関数を、できるだけ創造的な方法で3パターン提案してください。
- 二分木を走査して合計値を計算する
- 再帰・反復・ジェネレータなど、異なるアプローチを使う
- パフォーマンスと可読性のトレードオフもコード内コメントで説明する

このように、

• 「3パターン」「複数のアプローチ」など、バリエーションを明示的に要求する
• 「創造的」「新しい方法」「ユニークな設計」などのキーワードを入れる
• コメントで意図やトレードオフも書かせることで、発想の幅を広げる

といった工夫をすることで、同じパラメーター設定でも、より多様で参考になるコードが得られます。

2-3. ランダム性を活かした「コードブレインストーミング」

創造性重視モードの裏技として、同じプロンプトを複数回叩いて、パターンを集める方法があります。

1. Temperature を 0.9 〜 1.0 に設定
2. 同じプロンプトを 5〜10 回程度、短めの Max tokens で実行
3. 出てきたコードの「良い部分」だけを人間がマージして最終案を作る

これにより、ひとつの完璧なコードを一発で当てに行くのではなく、複数のアイデアの中からベストを選び取るというワークフローが実現できます。特に、

• 新しいフレームワークの使い方を模索しているとき
• アーキテクチャやデザインパターンの候補を洗い出したいとき
• 競合アルゴリズムの比較検証を行いたいとき

に有効なテクニックです。

3. 「正確なコード」を作らせるパラメーター設定の裏技

次に、本番運用やレビュー通過を前提とした正確で安定したコードを生成したいときのパラメーター設定です。

3-1. 正確性重視の基本セット

正確なコードを優先する場合の推奨初期設定は次の通りです。

temperature: 0.0 ～ 0.2
top_p      : 0.1 ～ 0.4（または固定 0.3）
max_tokens : 100 ～ 300（用途に応じて調整）
frequency_penalty: 0.0
presence_penalty : 0.0

この設定では、

• Temperature を下げて、より「決まりきった」安全なトークンを選択させる
• Top_p を絞り、確率の高い候補の中で最良のものを選ばせる
• Penalty をゼロにして、import や return などの必要な繰り返しを妨げない

ことにより、ドキュメントや一般的な実装に近い、無難で扱いやすいコードが出やすくなります。

3-2. 正確性重視モードでのプロンプト設計

正確なコードを生成させるには、プロンプトでも仕様をできるだけ具体的に書くことが重要です。

例：

次の仕様を満たす TypeScript の関数を1つだけ実装してください。
- Node.js v20 で動作すること
- axios を使って外部APIに GET リクエストを送る
- タイムアウトは 5000ms に設定する
- エラー発生時は例外を投げるのではなく、Result 型のエラーとして返す
- JSDoc コメントを付与する

ポイントは、

• 「1つだけ実装」「この仕様に厳密に従う」など、ぶれを許さない言い回しを入れる
• バージョン・ライブラリ・エラーハンドリング方針などを明確にする
• コメント形式や型システムの利用有無も指定しておく

これにより、Temperature が低い状態でも、明確な目的にフォーカスしたコードが出やすくなります。

3-3. 「検証コード」込みで生成させる裏技

正確なコードを得たいときに有効なのが、テストコードや検証コードも一緒に生成させる方法です。

例：

次の仕様を満たす関数と、その関数の動作を検証する簡単なテストコード（unittest）を Python で実装してください。
- 関数: validate_email(email: str) -> bool
- 有効なメールアドレス形式なら True, それ以外は False
- 正常系と異常系のテストケースをそれぞれ3つ以上用意する

このようにすると、モデルは自ら書いたコードをテストケースに合わせようとするため、一貫性の高いコードを生成しやすくなります。さらに人間側でも、生成直後にすぐテストを実行できるため、バグの早期発見にもつながります。

4. 「創造的モード」と「正確モード」を素早く切り替える実務ワークフロー

ここまでの内容を踏まえて、現場で使いやすい二段階ワークフローを紹介します。

4-1. ステップ1：創造的モードで「候補」を一気に出す

1. Temperature 0.8～1.0, Top_p 0.9～1.0 に設定
2. 要件を広めに書き、設計やアルゴリズムの「バリエーション」を要求
3. 同じプロンプトを複数回実行し、良さそうな案を3〜5個ピックアップ

このステップでは、品質よりも発想の広さを優先します。「どう実装するか」の可能性を網羅的に洗い出すイメージです。

4-2. ステップ2：正確モードで「本命コード」を仕上げる

1. Temperature 0.0～0.2, Top_p 0.1～0.4 に切り替える
2. ステップ1で選んだ案をベースに、仕様を細かく書き起こす
3. 「テストコードも一緒に」「例外処理を明示的に」など、堅牢性を高める指示を追加

創造モードで得たアイデアをもとに、本番向けの実装を丁寧に固めていく流れです。必要に応じて、人間が中間レビューを行いながら段階的に精度を上げていきます。

4-3. プロジェクト単位で「プリセット」を用意する

毎回パラメーターを手動で変えるのは手間がかかるため、ツール側で次のようなプリセットを用意しておくと便利です。

• creative.json：
  • temperature: 0.9
  • top_p: 0.95
  • max_tokens: 300
  • frequency_penalty: 0.4
  • presence_penalty: 0.4
• precise.json：
  • temperature: 0.1
  • top_p: 0.3
  • max_tokens: 300
  • frequency_penalty: 0.0
  • presence_penalty: 0.0

CLI ツールやエディタ拡張（VS Code 拡張機能など）から、
--profile creative / --profile precise のように呼び分けられるようにしておくと、モード切り替えがワンタッチになります。

5. よくある失敗パターンと対策

5-1. Temperature と Top_p の両方を上げすぎてカオスになる

創造性を求めるあまり、Temperature も Top_p も最大近くまで上げると、コードの一貫性が失われやすくなります。

対策：

• 基本的にはどちらか片方をメインで調整する
• もう片方は 0.8 固定などにして、微調整は1軸に絞る

5-2. Max tokens が短すぎてコードが途中で切れる

Max tokens をケチりすぎると、関数やクラスが途中で終わってしまい、実行できないコードになりがちです。

対策：

• 途中で切れていそうな場合は、そのコードをプロンプトに貼り戻し、
  「このコードの続きから書いてください」と指示する
• 「必ずコンパイル可能な形で完結させてください」と明記する
• よく使うタスクごとに、必要な Max tokens の目安をメモしておく

5-3. Penalty を上げすぎて必要な繰り返しまで抑制してしまう

Frequency penalty / Presence penalty を大きくしすぎると、
必要なキーワード（例：for, if, return など）まで出にくくなり、奇妙な構造のコードになることがあります。

対策：

• コード生成では基本 0.0 ～ 0.5 の範囲に収める
• 長文ドキュメント生成とは設定を分ける

6. まとめ：Codexのパラメーター裏技で、創造性と正確性を自由自在に

Codex のパラメーター設定を理解し、状況に応じて使い分けることで、

• 創造的なコード： アイデア出し・設計検討・複数案の比較
• 正確なコード： 本番実装・レビュー用コード・テスト付きコード

を自在に作り分けることができます。

最後に、要点を再掲します。

• 創造性を上げたいときは Temperature 高め、Top_p 高め、Penalty やや高め
• 正確性を上げたいときは Temperature 低め、Top_p 低め、Penalty は 0
• 創造モードで候補を集め、正確モードで本命コードを仕上げる二段階ワークフローが効率的
• プロジェクトやチームで 「creative プリセット」「precise プリセット」を共有しておくと便利

これらのコツを押さえておけば、Codex を「なんとなく使う」状態から一歩進んで、
開発プロセス全体を加速するための、本格的なコード生成アシスタントとして活用できるようになります。

さらに詳しい解説や具体的なデモコードについては、こちらの動画も参考にしてください。
https://youtu.be/MDKJA5lqELo?si=bX5t8NNeb_ErYWPN