Codexへの指示が「うまい人」と「そうでない人」の、たった一つの違い

2026.04.25

チームでCodexを使い始めてから、同じツールを使っているのに成果が違う、という場面を何度か目にした。

ある人は一度の指示で動くスクリプトを受け取り、ある人は何度指示を出しても「なんか違う」という状態が続く。使っているCodexは同じで、作りたいものも似たような規模のタスクなのに、差が出る。

その差を観察し続けて、少しずつ「うまい人」と「そうでない人」の違いが見えてきた。それは「指示の長さ」でも「専門知識の有無」でも「AIへの慣れ」でもなかった。もっとシンプルなことだった。

この記事は、その「たった一つの違い」とは何かを書いたものだ。Codexの機能の話というより、「Codexにどう話しかけるか」という実践的な技術の話だ。

結論から言うと、指示がうまい人は「入力と出力を先に決めてから指示する」という習慣を持っている。指示がうまくない人は「何を作りたいか」のイメージから始める。この順序の違いが、最初の一回で期待通りのものが返ってくるかどうかを決める。

指示が「うまくない」パターンとは何か

まず、うまくいかない指示の典型的なパターンを整理する。自分が最初にやっていたことでもあるので、心当たりがある人は多いと思う。

「〜みたいなものを作って」という指示

最も多い失敗パターンは、「完成イメージ」だけを伝える指示だ。

「CSVを整理するツールを作って」「データを自動で集計するスクリプトを作って」「レポートを自動生成するものを作って」。これらはすべて「完成イメージ」の説明で、「入力が何で」「出力が何で」「どんな条件で処理するか」が含まれていない。

この種の指示に対してCodexが返すのは、「一般的なCSV整理スクリプト」「汎用的な集計処理」だ。作りたいものとは微妙にずれていることが多く、「なんか違う」という修正のやり取りが何度も続く。

「なんか違う」という状態が3回以上続くとき、問題はCodexの性能ではなく、指示の中に必要な情報が入っていないことが多い。

「とりあえずやってみて」の罠

もう一つのパターンは「とりあえず指示を出して、返ってきたものを見てから考える」というアプローチだ。

最初の指示を出す前に「どんなものが欲しいか」を自分の中で整理しないまま、「Codexに聞けばいいものが出てくるだろう」という期待で始める。

このアプローチが問題なのは、「返ってきたものを見て考える」というプロセスが「自分が何を作りたいかを考える」作業を後回しにしているからだ。Codexの出力を見てから「これじゃない」「もう少しこうしたい」という修正を繰り返すより、最初に「何が欲しいか」を整理する時間に使ったほうが、トータルの時間は短くなる。

「指示を出す前の準備」に時間をかけることへの抵抗感がある人は多い。「さっさと試せばいいじゃないか」という感覚は自然だが、その感覚がCodexを非効率に使う最大の原因になっていることが多い。

指示が「うまい」人がやっていること

では、指示がうまい人は何をしているのか。チームの中で成果が出ている人の指示を観察すると、共通のパターンが見えてきた。

「入力→処理→出力」を先に書いてから指示する

指示がうまい人は、Codexに指示を出す前に「何を受け取り、何をして、何を返すか」の3点を自分の中で整理している。

具体的には以下のような思考プロセスだ。

入力（インプット）：何のデータを受け取るか。ファイル形式は何か。どこにあるか。
処理：そのデータに何をするか。フィルタリング、集計、変換、比較など。
出力（アウトプット）：何を返すか。ファイル形式、保存先、フォーマット。

この3点を整理してから指示に変換すると、「何を作りたいか」ではなく「どう動いてほしいか」を伝えられる。Codexはこの「どう動いてほしいか」の指示に対して、正確に応答してくれる。

実際に試してみると、この事前整理に使う時間は3〜5分程度だ。その3〜5分が、「なんか違う」と修正を繰り返す30〜60分を節約する。

制約条件を「最初に」伝える

指示がうまい人のもう一つの特徴は、制約条件を指示の冒頭に書く習慣を持っていることだ。

制約条件とは「〜を使ってください」「〜はしないでください」「〜の環境で動かします」という条件のことだ。これを後から追加すると、Codexは一から作り直すことが多い。最初から伝えておくと、最初から条件に合ったコードが返ってくる。

よく使う制約条件の例：

使用言語・バージョン（「Python 3.11で」「Node.js 20で」）
使えるライブラリの制限（「標準ライブラリのみ」「requestsとpandasのみ」）
ファイル操作の制限（「ファイルの書き込みはしない」「元ファイルを上書きしない」）
実行環境（「Windowsで動かします」「Google Colabで実行します」）
出力形式（「Excelではなくcsv形式で」「文字コードはUTF-8で」）

指示がうまい人は、この制約条件を「後から追加するもの」ではなく「最初から含めるもの」として扱っている。

実際の指示例で「悪い例」と「良い例」を比べる

理屈を説明するより、実際の指示の例を比べたほうが分かりやすい。同じ目的の指示を「曖昧な版」と「整理された版」で並べる。

例1：データ集計スクリプト

目的：複数のCSVファイルを読み込んで、月別に売上を集計したい。

曖昧な指示：「CSVのデータを月別に集計するPythonスクリプトを作ってください。」

この指示の問題点：どのCSVを読み込むか、CSVの列構成、集計の対象列、出力形式、保存先が何も含まれていない。Codexは一般的な構造を仮定してスクリプトを作るが、実際のデータとは合わない可能性が高い。

整理された指示：「Python 3.11で動作するスクリプトを作ってください。同じフォルダにある複数のCSVファイルを読み込み（ファイル名のパターン：sales_YYYYMM.csv）、各ファイルには『日付』『商品名』『売上金額』の3列があります。月ごとに売上金額を合計し、結果をsummary.csvとして同フォルダに出力してください。pandasを使用してください。」

この指示の特徴：入力（フォルダ内のCSV、命名パターン）、列構成（3列の名前）、処理（月別合計）、出力（summary.csv）、制約（Python 3.11、pandas使用）がすべて含まれている。

例2：ファイル整理スクリプト

目的：フォルダ内のファイルを拡張子ごとにサブフォルダに分けたい。

曖昧な指示：「ファイルを自動で整理するスクリプトを作ってください。」

整理された指示：「Python 3.11で動作するスクリプトを作ってください。コマンドライン引数で対象フォルダのパスを受け取ります。フォルダ内のファイルを拡張子ごとにサブフォルダに移動してください（例：.pdf → pdf フォルダ、.xlsx → xlsx フォルダ）。サブフォルダが存在しない場合は自動的に作成してください。移動したファイルのリストをログとしてmove_log.txtに記録してください。標準ライブラリのみ使用してください。」

2つの例を見比べると、「整理された指示」は長い。でもこの「長さ」こそが、最初の一回で期待通りのものが返ってくる確率を上げる。短い指示で何度もやり直すより、丁寧な指示を一回書くほうが、結果的に速い。

Codexへの指示が上達するための実践方法

「入力・処理・出力を整理する習慣」は、意識するだけでは身につきにくい。実際に上達するための具体的な練習方法を書く。

指示を出す前に「仕様書」を書く練習

最も効果的な練習は、Codexに指示を出す前に「仕様書」を書くことだ。仕様書といっても、難しいものではない。以下の項目を箇条書きで整理するだけでいい。

目的：このスクリプトが何のためにあるか（一言）
入力：何を受け取るか（ファイル、パス、形式）
データの構造：列名、データ型、サンプル値
処理内容：何をするか（条件、計算、変換）
出力：何を返すか（形式、保存先）
制約：使用言語、ライブラリ、環境
エラー処理：異常系のときどうするか

この項目を全部埋めてからCodexに渡す。最初は時間がかかるが、慣れると5分以内に書けるようになる。そして一度この習慣が身につくと、「指示を整理すること」がCodexとの対話の最初のステップとして自然になる。

失敗した指示を「解剖」する練習

うまくいかなかった指示を振り返って「何が足りなかったか」を分析することも有効な練習だ。

「なんか違う」という結果が返ってきたとき、すぐに修正指示を出す前に「自分の最初の指示に何が欠けていたか」を考える。「入力の形式を伝えていなかった」「条件が曖昧だった」「出力フォーマットを指定していなかった」など、不足していた要素を特定する。

指示の失敗は「Codexの限界」ではなく「指示の設計の問題」であることがほとんどだ。この視点の切り替えが、上達を加速する。「なぜうまくいかなかったか」を自分の指示に原因を求める癖をつけると、次の指示が改善される。

実際に試してみてわかったのは、「うまくいかなかった指示」を後から見返すと、「ああ、これは確かに伝わらないな」という箇所がほぼ必ず見つかる。それを修正した指示で再挑戦すると、期待通りの結果が返ってくることが多い。

「うまくいった指示」をテンプレートとして保存する

一度うまくいった指示は、テンプレートとして保存しておくことを勧める。同種のタスクが発生したとき、そのテンプレートを元に少し変えるだけで使い回せる。

たとえば「CSVを集計するスクリプト」のテンプレートを一つ作ると、次回は「列名と出力ファイル名を変えるだけ」で新しいスクリプトの指示が完成する。指示を毎回ゼロから書く必要がなくなる。

メモアプリやNotionなどに「Codex指示テンプレート集」というページを作り、うまくいった指示を分類して保存していくと、時間とともに自分専用の指示のライブラリが育っていく。

よくある質問（FAQ）

Q1. 指示が長くなりすぎると、Codexが混乱することはありますか？

一般的に、詳細な指示はCodexの精度を上げます。ただし、複数の無関係なタスクを一つの指示に詰め込みすぎると、混乱が生じることがあります。解決策は「タスクを分ける」ことです。「まずCSVを読み込んで整形するスクリプトを作って」→「次にその結果をメールで送る機能を追加して」というように、段階的に追加していくほうが、一度に複雑な指示を出すより安定した結果になります。

Q2. 日本語と英語、どちらで指示を出すほうが良いですか？

一般的に英語のほうが技術的な指示の精度が高い傾向があります。ただし、「入力・処理・出力を整理した指示」を日本語で書いても、精度は十分です。自分が正確に書ける言語を使うほうが、曖昧な英語より良い結果になります。技術用語（ファイル名、列名、形式名など）は英語のまま混在させても問題ありません。「日本語で書いて、技術用語は英語のまま」という形が実用的なバランスです。

Q3. サンプルデータを一緒に渡すと精度が上がりますか？

はい、大幅に上がります。「こんな構造のCSVです」という説明より、実際のCSVの最初の3〜5行を貼り付けて「この形式のデータを処理してください」と伝えるほうが、列名やデータ型を正確に把握してもらえます。個人情報が含まれる場合はダミーデータに置き換えて渡してください。サンプルデータがある場合は、積極的に含めることを勧めます。

Q4. 何度修正しても「なんか違う」状態が続くとき、どうすればいいですか？

修正指示を続けるより、一度最初から指示を書き直すほうが早いことが多いです。「なんか違う」が3回続いたら、これまでのやり取りを見直し「自分の最初の指示に何が含まれていなかったか」をチェックしてください。また、「完成品の指示」ではなく「部分的な機能の指示」に分解する方法も有効です。「読み込み部分だけ先に作って」→「動いたら次に集計処理を追加して」という段階的アプローチで、一度に全部作ろうとしないことでうまくいくケースがあります。

Q5. 指示の「上手さ」は、プログラミング知識がないと身につきませんか？

プログラミング知識がなくても身につきます。必要なのは「入力・処理・出力の構造を考える力」であり、これは論理的に物事を整理する力です。むしろ、プログラミングの知識がある人より、「仕事の手順を言語化することに慣れている人」（プロジェクトマネージャー、業務改善担当者など）のほうが、指示が上手いケースもあります。「何を渡したら何が返ってきてほしいか」を明確に伝える力は、プログラミングよりも「説明力」や「仕様整理力」に近いスキルです。

Q6. エラーが出たときの修正指示のコツはありますか？

エラーメッセージをそのまま貼り付けるのが基本です。加えて「このエラーが発生する状況の説明」を添えると精度が上がります。たとえば「このエラーはスクリプトを実行したときに出ます。CSVファイルはフォルダに存在しています。エラーの原因と修正方法を教えてください」という形です。エラーメッセージだけを貼り付けるより、「どの状況でそのエラーが出るか」を加えることで、Codexが文脈を把握しやすくなります。

Q7. 指示の上達に、どのくらいの時間がかかりますか？

「入力・処理・出力を整理してから指示する」習慣が自然になるまで、個人差はありますが2〜4週間程度を目安にしてください。最初は「指示を整理すること」自体に時間がかかりますが、慣れると3〜5分で書けるようになります。上達を加速させるコツは、毎回の指示を振り返ること。「うまくいった」「うまくいかなかった」の違いを意識的に観察することで、自分の指示パターンの弱点が見えてきます。