依頼文は中央値 19 字から 71 字へ ── 増えたのは定義と順番── 伸びた分は言葉数ではなく、AI が自分では知り得ない完成の定義と工程の順であり、送る前にその二つを書けばよい

01依頼文が伸びたのは、AI が知り得ない完成の定義と工程の順が書き足されたからである

記録に残る 2026 年 2 月以降の Claude とのやり取りで、依頼文の長さの中央値は月ごとに変わった。2 月 19 字、3 月 25 字、4 月 35 字、7 月 18 字、9 月 71 字である。集計では、長いほうから 1 割の依頼は 275 字に達していた。

数字だけを見ると、依頼が丁寧になった、あるいは饒舌になったと読める。しかし 9 月の長い依頼を読むと、増えた中身ははっきりしている。何を完成とみなすかの定義、設計、プログラムの実装という工程が、一つの依頼の中にこの順で書かれるようになった。

この回の結論は次のとおりである。依頼文を長くすること自体に価値はない。AI が会話の外にあって見られない情報、つまり完成の条件と作業の順番を書いた分だけ、依頼は AI が動ける形に近づく。読者が明日からすべきことは、送る前に依頼文にその二つが入っているかを確かめることである。

02短い命令は作業を一つ指し、長い依頼は仕事の始まりから終わりまでを指す

記録の 3 月には、別の AI に渡す作業を「以下を実行して」と一行で頼み、中身は貼り付けた文に任せる依頼があった。命令は動詞だけで、何が済めば終わりかは書かれていない。

9 月の長い依頼は形が違う。ある日の依頼は、毎朝決まった時刻に、合わせて 3 本の記事を日本語版と英語版で公開する仕組みを頼むものだった。まず過去の記事の書き方の決まりを書き手役の AI に記録させ、次に配信の仕組みを組み、最後に自動で公開させる。完成の姿、前提として決めること、作る順番が一続きの文に入っていた。

7 月の中央値は 18 字に下がった。記録に残る 7 月の依頼には、進めている作業の中で順番だけを指示する短い文が多い。前提がすでに会話の中にあれば、短い文で足りる。長さは、AI に新しく渡すべき情報の量で決まる。

03書かれなかった条件は AI の推測で埋まり、その分だけ直しが一往復増える

AI は、依頼に書かれていない条件を自分で補って作業を始める。Anthropic のプロンプトの指針は、Claude を「優秀だが、職場の決まりや進め方の文脈を知らない新しい社員」として扱うよう勧めている。望むことを正確に説明するほど結果がよくなる、とも書いている。

同じ指針は、確かめ方も一つ示している。依頼文を、その仕事の事情をほとんど知らない同僚に見せ、そのとおりに動けるかを考える。同僚が迷うなら、AI も迷う。

Claude Code の使い方の指針は、直しの手間との関係をもっと具体的に書いている。対象のファイルを名指しし、症状を書き、「直った」とはどういう状態かを最初に言えば、後の修正が一往復減ることが多い。また Claude は依頼を控えめに読み、条件を満たす最小のものを作りがちだという。使う人がどこまで望んでいるかが、AI からは見えないからである。

短い命令が悪いのではない。条件の決定を、依頼を書く時点から結果を見た後へ先送りしているのである。先送りした分は、作り直しという形で戻ってくる。

04依頼に入るべきものは目的・完成の定義・工程の順・柵の四つで、長さは結果にすぎない

9 月の長い依頼に書き足されていたものを分けると、次の四つになる。

他社の指針も、ほぼ同じ要素を挙げている。Microsoft の Copilot の入門記事は、依頼に入れられる部分として目的・背景・使う情報・期待する返し方の四つを示す。そのうえで、欠かせないのは明確な目的だけで、残りは具体性を足すものだと書いている。Google の Gemini の設計指針は、明確で具体的な指示、問題を解くのに要る情報、守るべき制約を入れるよう勧めている。

境界も引いておく。長いほど良いわけではない。275 字に達する依頼にも、要素が欠けていれば推測は残る。逆に、何かを探っている段階では、ぼんやりした依頼で構わないと Claude Code の指針は書いている。その代わり、途中で直す回数が増えることを受け入れる。四つの要素が要るのは、結果を一度で使いたいときである。

なお、この集計が貼り付けた資料を字数にどう含めたかは、集計の記述からは分からない。中央値は、使う人が自分で打った依頼の姿を大まかに示すものとして読むのがよい。

05資材審査では、AI に一次の見直しを頼むときに「何を指摘とするか」の定義が要る

製薬企業の資材審査やメディカルの現場でも、AI に資材の下読みをさせる場面が増えている。ここで「この資材を審査して」と一行で頼むと、AI は一般的な文章の校正に近いことを返しやすい。誤字や読みにくい文は拾えても、承認された効能・効果の範囲との照合や、比較の示し方の偏りといった、審査で本当に要る観点が抜ける恐れがある。

右の列の依頼は、日本語で 200 字前後になる。記録の 9 月の中央値の 3 倍近いが、どの文も審査の担当者しか知らない条件である。AI はこれを読めば、何を返せば済むかを推測しなくてよい。

もう一つの利点は、結果の確かめ方が依頼の中に書かれていることである。完成の定義に表の列を指定しておけば、返ってきた表に根拠の欄が空いている行は、それだけで読み直す対象になる。最後に判断して責任を負うのは、これまでどおり審査の担当者である。

06頼む単位が大きくなるほど、AI が決められないことが増え、依頼に書く量が増える

依頼文が伸びた背景には、頼む単位の変化がある。一つのエラーを直す依頼なら、決めることは少ない。直ったかどうかは見れば分かる。毎日の記事配信の仕組みを丸ごと頼むなら、記事の書き方、本数、言語、公開の時刻、作る順番など、決めることが一気に増える。

増えた決めごとのうち、AI が手元の情報から正しく決められるものは少ない。サイトの読者が誰か、記事の決まりがどこにあるか、どの言語を先に出すかは、使う人の頭の中にしかない。書かれていなければ、AI は控えめな推測で埋めるか、もっともらしい既定の形を選ぶ。

9 月の依頼で、定義 → 設計 → 実装の順が書かれるようになったのはこのためである。最初に決まりを定めておけば、設計も実装もその決まりを材料にできる。順を書かなければ、AI は実装から始めることがあり、後で決まりと合わない部分を作り直すことになる。

つまり、依頼文の長さは、AI に任せる仕事の大きさに合わせて伸びる。任せる単位を大きくしたのに依頼文を短いままにすると、その差は AI の推測で埋まる。

07明日からは、送る前に依頼文を四つの要素で読み直し、欠けた分を書き足す

使う人が明日からできることは四つある。

1. 目的を一文で書く。何をするかではなく、何のためにするかを書く。
2. 完成の定義を書く。出来上がりの数・形・時刻・従う決まりを並べる。表で返させるなら列の名前まで書く。
3. 工程の順を書く。決まりを定める、設計する、実装する、の順に並べ、前の工程の結果を次に使うよう指定する。
4. 送る前に、事情を知らない同僚の目で読む。その人がこの文だけで動けるかを考え、迷いそうな箇所を書き足す。

完成の定義が自分でも書けないときは、無理に書かなくてよい。Claude Code の指針は、仕様を書けるまで AI に質問させ、答えがそろったら仕様として書き出させる方法を紹介している。定義を AI と一緒に作り、その定義を次の依頼の頭に置けばよい。