Codexの消費量は短文で減る？ 迷わせない依頼文の作り方

Codexの消費量は短文で減る？ 迷わせない依頼文の作り方

公開日 読了7分

Codexの消費量が気になると、「できるだけ短く頼んだほうが軽いのでは」と考えがちです。
私も最初はそう考えていました。

ただ、実際には短文でも重くなる依頼があります。
逆に、少し長くても軽く進む依頼もあります。

結論から言うと、ポイントは文の短さではありません。
Codexが迷わず動けるように、条件をはっきり渡すことです。

この記事では、OpenAI公式の考え方を土台にしながら、Codexの無駄を減らしやすい依頼文の作り方をやさしく整理します。

Codexの消費量は「文章の長さ」だけでは決まらない

いまのCodexは、依頼を読んで終わりではありません。
ファイルを読み、必要なら編集し、ツールやコマンドを使いながら進みます。

この流れでは、最初の依頼があいまいだと探索範囲が広がります。
探索範囲とは、「どのファイルを見て、どこまで直すか」の範囲です。

範囲が広いほど、確認も往復も増えます。
その結果、消費量も上がりやすくなります。

つまり、重くなりやすい原因は「長文」そのものではなく、「判断に迷うこと」です。

短文でも重くなる依頼と、長めでも軽くなる依頼

短い依頼でも、次のような形だと重くなりやすいです。

  • 全体を見て、いい感じに改善して
  • バグを直して
  • 必要そうなところを全部見て

これらは短いですが、目的も対象も終わり方も不明です。
Codexは広く探す必要が出ます。

一方で、次のような依頼は少し長くても動きやすいです。

  • `src/auth/login.ts` と `src/ui/LoginForm.tsx` だけ確認する
  • ログイン失敗時にエラーメッセージが出ない不具合だけ直す
  • API仕様は変更しない
  • `npm test — login` が通れば完了

この形なら、見る場所とやること、やらないこと、終わり方が最初から決まっています。
そのぶん無駄な探索が減ります。

OpenAI公式の考え方でも、重要なのは明確な文脈と完了条件

OpenAIのCodex向け資料でも、明確な文脈と完了条件が重要だと案内されています。
これは難しい話ではありません。

要するに、次の2つを先に決めるということです。

  1. 何をやるのか
  2. どこまでできたら終わりか

この2つが弱いと、Codexは途中で判断を増やしやすくなります。
判断が増えると、確認回数も修正回数も増えます。

だから、消費量を抑えたいときは「短く書く」より「迷わせない」が先です。

Codexが重くなりやすい依頼文の特徴

次の依頼は、実務では特に重くなりやすいです。

「いい感じに」が入っている

「いい感じに」は便利な言葉ですが、条件としては弱いです。
見た目なのか、速度なのか、保守性なのかがわかりません。

対象ファイルが決まっていない

対象がないと、どこまで読むべきかが広がります。
たった一言でも、裏では大きな探索になります。

調査と実装を一度に頼んでいる

「原因を調べて、設計を見直して、必要なら直して」は一見効率的です。
ただ、判断の段階が多く、途中で広がりやすい依頼でもあります。

まず調査、次に実装、と分けたほうが安定します。

完了条件が書かれていない

完了条件がないと、「どこまでやれば終わりか」が人にもAIにもわかりません。
その状態は、作業が長引きやすいです。

Codexを動かしやすくする依頼文の4要素

依頼文は、次の4つがあるだけでかなり整理されます。

1. 目的

何を直すか、何を作るかを1文で書きます。

例: ログイン失敗時にエラーメッセージが表示されない不具合を直す。

2. 対象

見る場所を指定します。

例: `src/auth/login.ts` と `src/ui/LoginForm.tsx` のみ確認する。

3. 制約

やってほしくないことを先に書きます。

例: APIは変更しない。デザインは触らない。最小修正にする。

4. 完了条件

どこまでできたら終わりかを書きます。

例: エラー文言が表示される。既存テストが落ちない。追加テスト1件が通る。

この4つがそろうと、依頼はかなり安定します。

そのまま使える依頼文テンプレート

最初は、次の型をそのまま使えば十分です。

目的:

対象:

制約:

完了条件:

たとえば、こう書けます。

目的: ログイン失敗時の表示不具合を直す

対象: `src/auth/login.ts` と `src/ui/LoginForm.tsx`

制約: APIは変更しない。最小修正にする

完了条件: エラーメッセージが正しく表示され、`npm test — login` が通る

これだけでも、かなり迷いが減ります。

毎回同じ指示はAGENTS.mdにまとめる

毎回同じことを書くなら、`AGENTS.md` に寄せるほうが効率的です。
OpenAIのガイドでも、Codexは作業前に `AGENTS.md` を読む前提で案内されています。

たとえば、次のような内容は `AGENTS.md` と相性がいいです。

  • テスト実行コマンド
  • 変更してはいけないディレクトリ
  • コーディング規約
  • レビュー時に重視する観点

共通ルールを `AGENTS.md` に出しておけば、毎回の依頼文は短くできます。
しかも、必要な条件は落ちにくくなります。

結論。Codexの消費量が気になるなら、短くするより迷わせない

Codexの消費量を抑えたいなら、まず見直すべきは文字数ではありません。
依頼の設計です。

大事なのは次の3つです。

  1. 曖昧な言い方を減らす
  2. 目的・対象・制約・完了条件を書く
  3. 共通ルールは `AGENTS.md` にまとめる

この3つを実践すると、無駄な探索と手戻りが減ります。
結果として、Codexは軽く、安定して動きやすくなります。

「短くする」より「枠を決める」。
まずはここから始めるのが実務では効きます。

FAQ

Q1. Codexは短文で依頼したほうがいいですか？

短文であること自体は最優先ではありません。
短くても曖昧なら、むしろ重くなりやすいです。

Q2. 最低限どこまで書けばいいですか？

まずは4つです。
目的、対象、制約、完了条件。
この4点があるだけで、依頼はかなり安定します。

Q3. AGENTS.mdは必須ですか？

必須ではありません。
ただし、毎回同じルールを書くなら分けたほうが楽です。

Q4. 調査と実装は分けたほうがいいですか？

分けるほうが安定しやすいです。
一度に頼む内容が多いほど、判断範囲が広がるからです。

参考

attrip

attrip

考えたことを、記事・AI・音楽に変えて発信しています。

盆栽、音楽、ブログ運営、日々の試行錯誤について書いています。

2010年から発信中

コメントを残す