出力の契約を明示する（Making the Output Contract Explicit）

依頼には中身と形がある。人は中身しか書かないので、形は既定のまま出てくる。しかも形は思考量のつまみでは動かない — 深く考えさせないことと、短く述べさせることは別の操作である。

問題

「この関数を直して」と書くとき、人は何をしてほしいかを書く。どう返してほしいかは書かない。ところが返ってくるものには必ず形がある — 何行の説明が付くか、作業中にどれだけ喋るか、書き出す文書が何ページになるか、直前の自分の発言をいつ訂正として述べるか。書かなかった以上、それらは既定で決まる。

既定が悪いわけではない。だが既定は、道具の作り手が「多くの利用者にとって無難」と考えた一点である。目の前の仕事に合わせたものではない。長い説明が要る場面もあれば、結論だけが要る場面もあるのに、出てくる形は同じである。

そこで多くの人が最初に手を伸ばすつまみが、間違っている。「返答が長い」を「考えすぎている」と読み替えて、思考量を下げるのである。ところが公式は、思考量が制御するのはどれだけ考えるかであってどれだけ述べるかではないと明記している。思考量を下げても可視の応答が確実に短くなるわけではない、とまで書いている（公式、Anthropic。出典は具体例節）。つまり、この操作は品質だけを下げて長さを残しうる。

短くしたいなら、短くしろと言うしかない。

コンテキスト

適用する条件:

• 出力を人が読む、あるいは次の工程が受け取る — 形が合っていないことに、誰かが費用を払っている
• 同じ道具を長く走らせる — 進捗の粒度が決まっていないと、介入すべき瞬間を取り逃す
• 成果物がファイルとして残る — 会話は流れるが、書き出した文書は残り、読み手の時間を毎回奪う

適用しないケース:

• 既定で困っていないとき。 形の指定も常駐物であり、書いた瞬間から家賃が発生する。困っていないなら払う理由がない
• 難所で説明を削ると壊れる作業。 「簡潔に」は、根拠を述べる余地まで削りうる。簡潔さは、判断の根拠と交換されうる
• 機械で判定できる形。 出力の書式が機械で検査できるなら、依頼文ではなくゲートに置く（「機械ゲートと意味ゲートの分離」）

隣接パターンとの境界:

• 思考深度をタスクに合わせる — どれだけ考えるかが同パターン、どれだけ述べるかが本パターン。2つが別のつまみであることを明記しているのは、確認できた範囲では Anthropic 側だけであり、GitHub 側の資料にはこの区別の記述が無い（公式 と 不在確認。確認した範囲は具体例節）
• 命令の階層化と適用範囲の限定 — 形の契約をどの層に置くかが同パターン。これは飾りの問題ではない — github.com の公式は、応答スタイルの指定を個人の層の用途として名指しする一方、同種の指定を大きく多様なリポジトリの層に置くと問題になりうると注意している（公式、github.com。出典は具体例節）
• 常駐物の棚卸し — 形の契約もまた常駐物である。増やした分の家賃を数えるのが同パターン
• ルールを拘束力で階層化する — その契約にどれだけの拘束力を与えるかが同パターン
• 成果物の差分レビューと段階的採用 — 出てきたものをどう受け取るかが同パターン、出てくる形をあらかじめ指定するのが本パターンである

解決

なぜ効くのか。形は依頼の一部でありながら、依頼文には現れないからである。 中身は書かれるので指定どおりに出る。形は書かれないので既定で出る。この非対称が問題の全部である。 手当ては単純で、書かれていない層を書く。

指定できる面は、一次資料が具体で挙げているだけで4つある — 会話の応答の長さ、作業中の進捗更新の頻度と形、ファイルとして書き出す文書の分量、そして直前の自分の発言を訂正として述べる閾値である。最後のものは見落とされやすい。訂正それ自体は善だが、利用者の判断を何も変えない訂正を逐一述べることは、出力の水増しにしかならない（公式、Anthropic。出典は具体例節）。

書き方には向きがある。禁止の列挙より、望む形の例示のほうが効きやすいと公式が述べている（公式、Anthropic。出典は具体例節）。「長く書くな」は、どこまでが長いのかを決めない。「最初の一文で結論を述べ、詳細はその後に置け」は決める。禁止は空間を狭めるだけだが、例示は座標を与える。

そしてもう一つ。形の契約は、置く層を間違えると効かないどころか害になりうる。 github.com の公式は、応答スタイルの指定を個人の層の用途として挙げる一方で、同種の指定を大きく多様なリポジトリの層に置いた場合には問題になりうると注意し、文字数の上限を課す指示を「意図した結果にならないかもしれない」例として名指ししている（公式、github.com。出典は具体例節）。筋が通っている — 「1000文字以内で答えよ」は、その人の好みとしては成立するが、リポジトリに関わる全員・全用途に対する規約としては成立しない。形の契約は、誰の好みなのかによって置き場所が変わる。

トレードオフ

利点

• 品質を落とさずに出力を絞れる。 長さの不満を思考量の低下で買わずに済む。この2つが別のつまみであることは公式が明記している（公式、Anthropic。出典は具体例節）
• 進捗の粒度を決めると、介入点が決まる。 どこで報告が来るかが決まっていれば、人間はそこで止められる。決まっていなければ、報告は多すぎるか、遅すぎるかのどちらかになる
• 後から棚卸しできる。 形の指定は具体なので、要らなくなったときに削除を判断できる

代償

• 契約も常駐物である。 書いた瞬間から毎ターンの家賃が発生する。形の指定を4面ぶん積めば、その分だけ他の命令が薄まる。「常駐物の棚卸し」と正面から緊張する
• 遵守は保証されない。 github.com の公式は、AI の非決定性ゆえにカスタム命令が毎回まったく同じように守られるとは限らないと明記している（公式、github.com。出典は具体例節）。形を契約と呼ぶのは比喩であり、履行の強制力は無い
• ⚠ 置く層を誤ると、公式が注意している領域に入る。 応答スタイルや詳細度の指定を、大きく多様なリポジトリの層に置くと問題になりうると公式が名指ししている（公式、github.com。出典は具体例節）。本パターンは「常にどこかに書け」ではない。 誰の好みなのかを決めてから置く
• 簡潔さは、根拠と交換されうる。 「短く」は説明の圧縮であって、判断の質の向上ではない。難所で根拠まで削られると、レビューする側が損をする

GitHub Copilot での具体例

4つの面のうち、GitHub 側に公式の対応物を確認できたのは1つだけである。 残る3つ（進捗更新・書き出す文書の分量・訂正の閾値）は、確認した範囲では Anthropic 側にしか記述が無い。この差を潰さずに示す。

github.com — 応答スタイルは、個人の層の用途として名指しされている

出典: About customizing Copilot responses（取得日: 2026-07-26、全文取得のうえ検索）公式:

Personal instructions apply to all conversations you have with Copilot Chat across the GitHub website. They allow you to specify your individual preferences, such as preferred language or response style, ensuring that the responses are tailored to your personal needs.

〔訳〕個人向けの指示は、GitHub のウェブサイト上で Copilot Chat と行うすべての会話に適用される。これにより、好みの言語や応答スタイルといった個人的な選好を指定でき、応答が自分のニーズに合わせて調整されるようにできる。

射程に注意すること — 原文が扱っているのは github.com の Copilot Chat であり、しかも personal instructions の説明としてこれを書いている。応答スタイルの指定が公式に名指しされているのは、この層である。

github.com — ただし同じ指定をリポジトリの層に置くときは、公式が注意している

同じページの後段 公式:

You should also consider the size and complexity of your repository. The following types of instructions may work for a small repository with only a few contributors, but for a large and diverse repository, these may cause problems:

• Requests to refer to external resources when formulating a response
• Instructions to answer in a particular style
• Requests to always respond with a certain level of detail

〔訳〕リポジトリの規模と複雑さも考慮すべきである。以下の種類の指示は、貢献者が数人の小さなリポジトリでは機能するかもしれないが、大きく多様なリポジトリでは問題を引き起こしうる — 応答を作る際に外部リソースを参照するよう求める指示、特定のスタイルで答えるよう求める指示、常に一定の詳細度で応答するよう求める指示。

続けて、意図した結果にならないかもしれない例として、次の指示が挙げられている 公式:

Answer all questions in less than 1000 characters, and words of no more than 12 characters.

〔訳〕すべての質問に1000文字未満で、かつ12文字を超えない単語で答えよ。

本パターンにとって重要なのは、この2つが矛盾していないことである。 前者は個人の層の話、後者はリポジトリの層の話であり、同じ指定が層によって是にも非にもなる。「命令の階層化と適用範囲の限定」との交点はここにある。

同ページは遵守そのものについても明記している 公式:

Due to the non-deterministic nature of AI, Copilot may not always follow your custom instructions in exactly the same way every time they are used.

〔訳〕AI は非決定的であるため、Copilot がカスタム命令を毎回まったく同じように守るとは限らない。

VS Code — 思考量のつまみは、思考量のつまみとしてのみ書かれている

出典: Language models（取得日: 2026-07-26、全文取得のうえ検索）公式:

Some models support configurable thinking effort, which controls how much reasoning the model applies to each request.

〔訳〕一部のモデルは設定可能な thinking effort をサポートしており、これがモデルが各リクエストに適用する推論の量を制御する。

原文が結び付けているのは thinking effort → 推論の量であり、可視の応答の長さではない。

不在確認 — 確認した範囲を明示する。Language models（109,455 バイト）と Optimize agent usage（62,889 バイト）、および上記 About customizing Copilot responses（892,478 バイト）の全文を 2026-07-26 に取得し、タグを除去した本文に対して visible response / response length / how much it says / verbosity / progress update / conciseness を検索した。いずれも0件である（thinking effort は Language models に9件ヒットしており、検索そのものは機能している）。

つまり GitHub 側は、思考量を下げても可視の応答が確実には短くならない、という区別を書いていない。これは「公式が否定している」ではなく「記述が無い」である。区別を明記しているのは次節の Anthropic 側だけであり、本カタログはそれを一方の 公式 として扱う。

Anthropic — 4つの面を名指ししている側

出典: Prompting Claude Opus 5（取得日: 2026-07-26、raw markdown を取得のうえ検索）公式。原文が名指ししているのは Claude Opus 5 であり、全モデル・全道具の一般則ではない。

思考量と述べる量の区別 — Response length and verbosity 節:

lowering effort can reduce thinking volume without reliably shortening the visible response. To control response length, prompt for it explicitly.

〔訳〕effort を下げると思考の量は減りうるが、可視の応答が確実に短くなるわけではない。応答の長さを制御したいなら、そのように明示的に指示すること。

進捗更新の書き方 — User-facing progress updates 節:

Positive examples of the communication style you want tend to be more effective than instructions about what not to do.

〔訳〕望む伝え方の肯定的な例を示すほうが、してはならないことを述べる指示より効果的である傾向がある。

書き出す文書の分量 — Written deliverable length 節。原文はそのまま指示文として使える形で書かれている:

Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.

〔訳〕書き出す文書の長さを、そのタスクに必要な分量に合わせよ。中身は網羅せよ、ただし埋め草の節・重複した要約・定型文で水増しするな。

訂正を述べる閾値 — Self-correction 節:

Only correct an earlier statement when the error would change the user's code, conclusions, or decisions.

〔訳〕以前の発言を訂正するのは、その誤りが利用者のコード・結論・判断を変える場合に限れ。

面と出所の対応

出力の面	GitHub 側	Anthropic 側
応答の長さ・スタイル	公式 github.com（個人の層で名指し／リポジトリの層では注意）	公式
進捗更新の頻度と形	不在確認（検索語と範囲は上記）	公式
書き出す文書の分量	不在確認（同上）	公式
訂正を述べる閾値	不在確認（同上）	公式
思考量と応答長が別であること	不在確認（同上）	公式

この表の読み方: 空欄ではなく 不在確認 と書いているのは、探した範囲を明示する義務があるからである。「GitHub にはこの機能が無い」ではない — 確認した資料の範囲で記述を見つけられなかった、という意味しか持たない。

別名

呼称	出典
Response style / custom instructions	一次 — ただしこれは機構の呼称であり、本パターンの呼称ではない（出典は具体例節）
Conciseness instruction	一次 — Anthropic 側が応答の簡潔さの指示をこう呼ぶ。4面のうち1面の呼称にとどまる
出力の契約を明示する / Making the Output Contract Explicit	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

一次資料が名前を与えているのは、入れ物（custom instructions）と、個々の面（response style、conciseness）までである。「出力の形は依頼の一部であり、指定しなければ既定が出る」というまとまりには、確認できた範囲で確立した呼称が無い。面ごとの呼称をパターン名に使うと、残る3面が視界から落ちる。面ではなく、面をまとめている構造の側に名前を与えた。

関連

• 思考深度をタスクに合わせる — 隣にある別のつまみ。どれだけ考えるかが同パターン、どれだけ述べるかが本パターンであり、一方を回しても他方は確実には動かない。長さの不満を思考量で買おうとしたときに、最初に読むべきページである
• 命令の階層化と適用範囲の限定 — 形の契約をどの層に置くか。公式が個人の層とリポジトリの層で別のことを言っている以上、置き場所は本パターンの一部である
• 常駐物の棚卸し — 形の契約も家賃を払う。4面ぶん積む前に、いま何が常駐しているかを数える
• ルールを拘束力で階層化する — その契約が「守れ」なのか「できれば」なのかを決める
• 成果物の差分レビューと段階的採用 — 出てきたものの受け取り方。本パターンは、受け取る前に形を決める側である
• 由来を分けて記録する — 出力の形を決めても、その内容が事実・出典・推論のどれかは別に残さなければならない。同パターンは内容の帰属を扱う
• まず次に読むなら 思考深度をタスクに合わせる — 2つのつまみの区別が付いていなければ、どちらを回しても外す