Dev Study
← 何を作るかを言葉にする
レッスン 9 / 10·約 9 分·第21期 何を作るかを言葉にする

「やらないこと」は決定であって、禁止文ではない

リクエストがアプリケーションに届くまで
  1. ブラウザURL入力
  2. DNS名前→IP
  3. ルータ経路選択
  4. ロードバランサ振り分け
  5. Nginx受け口
  6. アプリ処理今ここ
  7. DB保存

このコースの芯は「書かなかったことは、実装が黙って決める」です。今回は、何を作るかではなく、何を作らないかという範囲の決定を見ます。

まず結論

仕様に書かなかったことは消えずに残り、実装した誰か(人でも AI でも)が黙って決めます。「どこまでやるか」も同じで、範囲の外を書かなければ、ついでに何を足すかを実装した側が決めます。

「やらないこと」を書くのは、その範囲を依頼した側が決めて書き残すことです。完成品に「〜してはならない」と課す禁止の要求とは、別の種類の文です。

? 読む前に予測

Kubernetes の提案書テンプレート(KEP)には Non-Goals という節があります。テンプレートは、この節を書く目的を何と説明しているでしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

範囲の外を書かないと、誰が範囲を決めるのか

依頼には必ず範囲があります。「このバグを直してほしい」と頼んだとき、周りのコードの整理は含むのか。ついでの設定項目の追加は含むのか。書かなければ、この判断は消えずに実装した側に残ります。人なら気を利かせて足し、AI なら頼まれていない改善を加えるかもしれません。どちらも、範囲を決めたのは依頼した側ではなく実装した側です。

範囲の内側(やること)だけを書くと、その外側は「書いていない」だけで、「やらない」とは決まっていません。やらないと決めたなら、それを書いて初めて決定として残ります。

Kubernetes の提案書テンプレート(KEP)は、### Goals のすぐ後に ### Non-Goals という節を置き、記入案内にこう書いています。

What is out of scope for this KEP? Listing non-goals helps to focus discussion and make progress.

範囲の外を並べる目的は、議論を絞って前へ進めることです。やることの一覧と同じ重さで、やらないことの一覧を求めています。

範囲の外を書いたときと、書かなかったとき
やることGoals。依頼した側が決めた
その外側
やらないと書いた事柄Non-Goals。依頼した側が決めた
何も書いていない事柄足すかどうかは実装した側が決める
  • ・書いていない事柄は「やらない」と決まったわけではない
  • ・Non-Goals を書くと、外側の一部が依頼した側の決定に変わる
具体実物

3つのテンプレートにある、範囲の外を書く場所

範囲の外を書く場所は、KEP 以外のテンプレートにもあります。ただし節の名前は同じではありません。

範囲の外を尋ねる記入案内(各テンプレートの逐語、2026-09-24 取得)表
文書               節                       記入案内(逐語)
KEP                Non-Goals                What is out of scope for this KEP?
Rust RFC           Unresolved questions     What related issues do you consider out of scope for this RFC ...
Rust RFC           Future possibilities     ... if they are out of scope for the RFC you are writing ...
PEP 12             Rejected Ideas           Why certain ideas ... were not ultimately pursued.

Rust の RFC テンプレートには Non-Goals という節はありません。範囲の外は、## Unresolved questions に並ぶ3つの問いの3つ目で尋ねられます。

What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?

## Future possibilities にも、範囲外だが関係のある案の置き場として This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. とあります。

PEP 12 の Rejected Ideas は少し向きが違い、議論に出たが採らなかった案とその理由を書く節です。

名前も位置も違いますが、3つとも**「書いていない」と「やらないと決めた」を区別できる場所**を用意しています。

✓ ここまでの確認

Rust の RFC テンプレート(0000-template.md)について、正しい説明はどれですか。

抽象原理

「やらないこと」と「〜してはならない」は別の文

「やらないこと」を書くというと、「〜してはならない」という禁止文を並べることだと思いがちです。しかし2つは別の種類の文です。以下は教材側の整理です。

  • 範囲の決定(やらないこと): 今回の作業がどこまでを扱うか。例「今回は多言語対応をしない」。後の作業で覆してよく、覆すときは決定を書き直す。
  • 禁止の要求(〜してはならない): 完成品が守るべき性質。例「パスワードをログに出力してはならない」。破れば欠陥になる。

要求の書き方については、NASA のハンドブックの点検項目 C.3 がこう求めています。

The requirement is stated positively (as opposed to negatively, i.e., “shall not”).

主語は The requirement(要求)です。範囲の決定を否定形で書くことについて述べた項目ではありません。

AI への指示でも、同じ区別が見えます。Anthropic の Prompting best practices(2026-09-24 取得)は、Output and formatting の中の Control the format of responses で、書式を制御する方法の1番目に次を挙げます。

Tell Claude what to do instead of what not to do

見本は「markdown を使うな」の代わりに「滑らかな散文の段落で書け」です。欲しい出力の姿がある書式の指示では、肯定形で書けば済みます。

具体実物

同じ文書が、範囲の見本では否定形も使っている

同じ文書の Agentic systems の Overeagerness 節は、Claude Opus 4.5 and Claude Opus 4.6 have a tendency to overengineer と書いたうえで、次の見本プロンプトを載せています(抜粋。改行位置は原文のまま)。

Sample prompt to minimize overengineering(抜粋、2026-09-24 取得)設定ファイル
Avoid over-engineering. Only make changes that are directly requested or clearly
necessary. Keep solutions simple and focused:
 
- Scope: Don't add features, refactor code, or make "improvements" beyond what was
asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need
extra configurability.
 
- Abstractions: Don't create helpers, utilities, or abstractions for one-time
operations. Don't design for hypothetical future requirements. The right amount of
complexity is the minimum needed for the current task.

Scope: の行は Don't で始まり、beyond what was asked(頼まれた範囲の外)を切っています。一方、冒頭の Only make changes that are directly requested or clearly necessary. は肯定形で範囲を示しています。見本全体では、肯定形と否定形が併用されています(省いた項目にも Only add comments where Only validate at system boundaries という肯定形があります)。

ですから、この文書を「否定形を避けよ」の根拠にはできません。書式の指示では肯定形を勧めていますが、範囲の見本では否定形も使っています。「〜してはいけないより〜してください」と教えるクイズ(prompt-engineering-10)は、望ましい出力を示すという書式の側の話として、原文と一致します。どちらかを誤りとする必要はありません。

なお、過剰な作り込みの傾向は特定の2モデルについて書かれたもので、AI 全般の性質としては書かれていません。

✓ ここまでの確認

Anthropic の Prompting best practices(2026-09-24 取得)における肯定形と否定形の扱いとして、正しいのはどれですか。

⇄ 2つを見比べる
具体例 A

KEP の Non-Goals(人が読む提案書)

Goals の直後に Non-Goals の節を置き、範囲の外を並べさせます。目的は議論を絞って前へ進めることと書かれ、実装者への禁止としては書かれていません。

KEP テンプレートの節(逐語・抜粋)設定ファイル
### Goals
List the specific goals of the KEP. What is it trying to achieve?
### Non-Goals
What is out of scope for this KEP?
具体例 B

Overeagerness の見本(AI への指示)

頼まれた範囲の外を Don't で切ります。冒頭の Only make changes ... は肯定形で、範囲の見本は両方の形を併用しています。書式の指示で肯定形を勧める同じ文書が、範囲では否定形も使っています。

見本プロンプトの1項目(逐語)設定ファイル
- Scope: Don't add features, refactor code, or make "improvements" beyond what was
asked.

人が読む提案書と、AI に渡す指示。読み手は違いますが、2つに共通する構造は何でしょうか。

「その文が無かったら、足すかどうかを誰が決めることになるか」を両方で考えてみてください。

この章のまとめ

  • 範囲の外を書かなければ、足すかどうかは実装した側が決める。「書いていない」は「やらない」ではない。
  • KEP は Goals の隣に Non-Goals を置き、目的を議論を絞って前進させることと書く。
  • Rust の RFC テンプレートに Non-Goals 節は無い。範囲外は Unresolved questions の3つ目の問いと Future possibilities で扱う。
  • 範囲の決定(やらないこと)と 禁止の要求(〜してはならない)は別物。NASA C.3 の肯定形の項目は要求文についての点検。
  • Anthropic の文書は、書式では肯定形を勧め、範囲の見本では否定形も使う(冒頭の Only make changes… は肯定形)。否定形を避ける根拠にはならず、どちらも誤りではない。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

NASA のシステム工学ハンドブック(SP-2016-6105 Rev2)付録C の C.3 にある「肯定形で書く」という点検項目は、何についての項目ですか。

用語集(4語)
非目標 (Non-Goals)
その提案や作業では扱わないと決めた事柄の一覧。KEP テンプレートは Goals の隣に節を置き、議論を絞って前進させるためと説明する。
範囲の決定
今回の作業がどこまでを扱うかの取り決め。教材側の用語。後の作業で覆せる決定で、完成品の性質を定める要求とは種類が違う。
禁止の要求
完成品が「〜してはならない」とする要求。教材側の用語。破れば欠陥になる。NASA 付録C C.3 は要求文を肯定形で書くよう点検項目に挙げる。
過剰な作り込み (overeagerness)
頼まれていない機能・抽象・柔軟性を足してしまうこと。Anthropic の文書は Claude Opus 4.5 と 4.6 の傾向として挙げる(2026-09-24 取得時点)。

出典(一次ソース)