CLAUDE.md やエージェントのスキル定義などのルールセットを保守する際、「〜するな（否定形）ではなく、〜せよ（肯定形）で書く」という指示原則は広く知られています。Anthropic の公式プロンプトエンジニアリングガイドでも、出力形式の制御を中心に「Claude に対し、何をしないかではなく何をすべきかを指示する（Tell Claude what to do instead of what not to do）」ことが推奨されています1。成果物に不要な否定語句が転写されるのを防ぎ、エージェントが取るべき代替行動を明確にする上で、肯定形での指示は有効なアプローチです。

しかし、既存のルールセットの否定形指示を肯定形へ書き換える過程では、「プロンプトルールの肯定形化における適用範囲のドリフト」がしばしば発生します。これは、否定形の制約指示を肯定的な動作指示へ言い換える過程で、ルールの適用範囲（対象フェーズ、拘束力の強さ、対象範囲など）が元の意図から広がる方向・狭まる方向・すり替わる方向へ意図せず変質してしまう現象です。

筆者が運用するAIエージェントによる連載自動化パイプラインのリポジトリ（非公開。以下、リポジトリA）において、各ルールの中身（守ること）を変えずに肯定形化する改訂タスクを実施した際、「ルールが求める内容は変えていない」とコミットメッセージに明記していたにもかかわらず、わずか 1 分 26 秒後のコミットで 3 つのルールに要件の広がりが見つかって差し戻されました。さらに後続タスクのセルフレビューでも、2 ファイルにわたる 7 行で多方向な意味の変質が検出され、元の意図へ戻す修正が必要になりました。

本記事では、この 2 回の見直しで元に戻された計 10 件の実測コミットログと diff を通じて、肯定形化による変質が一様ではなく、広がる・すり替わる・固定される・否定が落ちるといった多方向に出ること、および直しはすべて肯定形のまま行えたことを示します。その上で、言い換えのたびに元の文面が何を禁じていたかを書き換え後の文と突き合わせて点検する実践的な手順を提示します。

「内容は変えていない」と書いた肯定形化直後の3件の差し戻し

リポジトリA のルール改訂タスクにおいて、生成される成果物に肯定形が反映されるよう、ルールセット本文を肯定形にする作業を行いました。この作業の完了条件は「各ルールの中身（守ること）が、書き換える前と同じである」ことと設定されていました。

作業後に作成されたコミットのメッセージには、「ルールが求める内容は変えていない」と明確に記録されていました。

ところが、そのわずか 1 分 26 秒後、直後のコミットによって 3 つのルール（rule 18, rule 5, rule 10）の要件が元の範囲へと戻されることになりました。コミットメッセージには「書き換えで広がった要件を元の範囲へ戻し、残りの見出し参照をそろえる」と記録されています。

差し戻された 3 つのルールにおける適用範囲の変質は、以下の 3 段（元の文面 → 肯定形化 → 差し戻し）で発生していました。

  1. 対象フェーズの拡大（rule 18）: 元の文面は「Phase 3（執筆）は特定の設計ファイルを読まない」という Phase 3 限定の禁止でした。これを肯定形化で「読むのは Phase 1 まで」と書き換えた結果、Phase 2 以降も読めないことになり、禁止の対象が Phase 3 から Phase 2 以降全体へと広がってしまいました。差し戻しでは「Phase 3（執筆）には設計ファイルの代わりに構造案を渡す」として、再び Phase 3 だけを対象とする肯定形指示に合わせ直しました。
  2. 記録義務の発生（rule 5）: 元の文面は「バイト数で目標・閾値・下限を置かない」という禁止で、記録を行うかどうかについては何も触れていませんでした。肯定形化で「バイト数は結果として記録するだけにする」と記述したため、結果として記録する義務が生じる形に変質しました。差し戻しでは「バイト数は結果として受け取る」と改め、記録義務を解消しました。
  3. 比較範囲の変化（rule 10）: 元の文面は「例題を毎回同じドメインに寄せない」（特定の偏りの禁止）でした。肯定形化で「例題のドメインを毎回変える」とした結果、直前の回と必ず違うドメインにしなければならない義務として読めるようになりました。差し戻しでは、元の文面に戻すのではなく、「例題のドメインは直近数本と違うものを選ぶ」という新しい肯定形で比較の対象範囲を指定し直しました。

引用元: 筆者の運用する連載ルールセットのリポジトリ（非公開）の diff

-5. **長文方針**（引数ルール・引数=`{密度の仕組み}`）: 各幕で「動くが脆いコード → なぜ破綻 → パターン導入 → After → なぜ効く」を、**推論の段を一段ずつ踏んで**展開する。**分量は結果であって目標ではない**——書き手が追うのは推論の段と `{密度の仕組み}` で、バイト数は結果として記録するだけにする（2026-10-13 に目標・閾値・下限を撤廃。比較対象に長い回が入るたびに目標が上がり、下回れば補う仕組みは伸ばす方向にしか働かず、シリーズの中央値は 16.6KB→41.3KB まで膨らんだ。後から足した文は前倒しを生んだ: puppeteer ep01・ep02、carpenter ep01・ep03）
+5. **長文方針**（引数ルール・引数=`{密度の仕組み}`）: 各幕で「動くが脆いコード → なぜ破綻 → パターン導入 → After → なぜ効く」を、**推論の段を一段ずつ踏んで**展開する。**分量は結果であって目標ではない**——書き手が追うのは推論の段と `{密度の仕組み}` で、バイト数は結果として受け取る（2026-10-13 に目標・閾値・下限を撤廃。比較対象に長い回が入るたびに目標が上がり、下回れば補う仕組みは伸ばす方向にしか働かず、シリーズの中央値は 16.6KB→41.3KB まで膨らんだ。後から足した文は前倒しを生んだ: puppeteer ep01・ep02、carpenter ep01・ep03）
-10. **題材ドメインも変奏**: 例題のドメイン（フェッチ・決済 等）を毎回変える。企画時に直近数本のドメインを確認
+10. **題材ドメインも変奏**: 例題のドメイン（フェッチ・決済 等）は直近数本と違うものを選ぶ。企画時に直近数本のドメインを確認
-18. **秘密は文脈分離で守る**（縦軸あり）: 構造案には、当該話で縦軸に足す情報と、語り手が知覚できることだけを書く。**`roadmap-design.md` を読むのは Phase 1 までで、Phase 3（執筆）は構造案から書く。** 当該話で縦軸に足す情報は、Phase 1 が構造案へ**肯定形の指示**として転記する（転記するのは指示だけで、理由と以降の展開は roadmap に残す——理由を書けば秘密が伝わり、伝われば漏れる）。禁止（「隠せ」）で守ろうとすると、書き手は隠すべきものを保持したまま書くことになり、**避けた輪郭が文体に転写される**（「ここでは触れない」等の言い訳語彙として現れる）。**知らないものは漏らせない**——情報の配置で守るのが正しい。旧版は「構造案に書かない」だけを定めていたが、Phase 3 の読み込みリストに roadmap 本体が入っており、秘密は別ルートで全部渡っていた（2026-08-20 に発覚・ADR 0003）
+18. **秘密は文脈分離で守る**（縦軸あり）: 構造案には、当該話で縦軸に足す情報と、語り手が知覚できることだけを書く。**加えて、Phase 3（執筆）には `roadmap-design.md` の代わりに構造案を渡す。** 当該話で縦軸に足す情報は、Phase 1 が構造案へ**肯定形の指示**として転記する（転記するのは指示だけで、理由と以降の展開は roadmap に残す——理由を書けば秘密が伝わり、伝われば漏れる）。禁止（「隠せ」）で守ろうとすると、書き手は隠すべきものを保持したまま書くことになり、**避けた輪郭が文体に転写される**（「ここでは触れない」等の言い訳語彙として現れる）。**知らないものは漏らせない**——情報の配置で守るのが正しい。旧版は「構造案に書かない」だけを定めていたが、Phase 3 の読み込みリストに roadmap 本体が入っており、秘密は別ルートで全部渡っていた（2026-08-20 に発覚・ADR 0003）

diff を確認すると、いずれの行も否定形に戻したのではなく、肯定形を保ちながら「記録するだけにする → 受け取る」「毎回変える → 直近数本と違うものを選ぶ」「読むのは Phase 1 まで → 代わりに構造案を渡す」と表現を調整することで、意図せぬ要件拡大を解消していることがわかります。

なお、作業者がコミット直後にどうやってこれらの変化に気づいたかという思考過程や、書き換えられた他の 13 ルールに微細なニュアンスの変化が一切なかったかどうかはログに残っていないため断定できません。客観的事実として確認できるのは、この 3 件において肯定形化に伴う要件の拡大が発生し、1 分 26 秒後に肯定形のまま元の範囲へ修正されたということです。

セルフレビューで見つかった7行の多方向な変化

続いて、リポジトリA の既存コンポーネント定義を肯定形化するタスクでも、同様の適用範囲の変質が発生しました。このタスクでは作業直後のセルフレビューによって「ルールの中身が変わっていた書き換え」が検出され、元の意味へと戻されました。対象は 2 ファイル・6 つの diff hunk にまたがる全 7 行でした。

この 7 行の変質を分析すると、変化の向きは一様ではなく、広がる、すり替わる、固定される、否定が落ちるといった多方向に及んでいました。

  1. 対象範囲が広がる（登場人物構成）: 元の文面は、引き揚げ会社の経営者や作業員について「名前のある登場人物にしない」というものでした。肯定形化で「名前のある登場人物は登場人物Aと語り部の二人だけ」と記述した結果、「二人だけ」という上限が加わり、元々は禁止されていなかった他の人物まで含めて名前が禁止されることになり、禁止範囲が広がってしまいました。セルフレビューでは「役職で呼ぶ背景として描く」と改められました。
  2. 制約の対象がすり替わる（検証用テスト）: 元の文面は「外部の道具に依存しない純粋な Go で書く」でした。肯定形化で「標準ライブラリだけの純粋な Go で書く」としたため、外部ツールの排除から、外部 Go パッケージ全般の禁止へと制約の内容がすり替わってしまいました。セルフレビューでは「go test だけで動く純粋な Go で書く（特定の道具が無くても通る）」へ戻されました。
  3. 手順が固定される（手作業内容）: 元の文面は「Before に手打ちの git bisect good/bad を使わない」でした。肯定形化で「Before は、コミットを一つずつ戻して試す」としたため、Before の手順が「一つずつ戻す」に固定されてしまいました。セルフレビューでは「After 側で初めて見せる」として固定を外しました。
  4. 全回義務への強化（エピソードの終わり方）: 元の文面は「毎回『再現テストを書いて終わる』にしない」という定型化の禁止でした。肯定形化で「回ごとに別の終わり方と入れ替える」と書いたため、全エピソードでローテーションしなければならない義務へと強化されてしまいました。セルフレビューでは「使う回を選び、ほかの回は別の終わり方にする」と戻されました。
  5. 必須化（セリフと定型フレーズ）: 元の文面は「定型フレーズ（leitmotif）にも選ばない」でした。肯定形化で「leitmotif は別に選ぶ」としたため、leitmotif の設定が必須であるかのように読める状態になりました。セルフレビューでは「leitmotif を置くなら、これらとは別の句から選ぶ」と条件付きの表現に戻されました。
  6. 否定の脱落（トーン管理）: 元の文面は「死を惨事として描写しない。重さは残された人の現在の姿で示す」でした。肯定形化で「死の重さは、残された人の現在の姿で示す」としたため、「惨事として描写しない」という肝心の否定制約が抜け落ちてしまいました。セルフレビューでは否定形に戻すのではなく、「残された人の現在の姿だけで示す」と「だけで」という限定語を補うことで排除の意味を担保しました。
  7. 参照先ルールとの食い違い（縦軸の記述）: 肯定形化で書き換えた文面が、参照先の別ルールで定義されていた「来歴を縦軸にしない」という要約と食い違っていたため、表現が整合されました。

（以下は、このうち代表的な 3 つの diff hunk の抜粋です） 引用元: 筆者の運用する連載ルールセットのリポジトリ（非公開）の diff

-*   **登場人物構成**: 二者（ミオ＋語り部1名）。名前のある登場人物はミオと語り部の二人だけ。引き揚げ会社の経営者や作業員は背景として描く
+*   **登場人物構成**: 二者（ミオ＋語り部1名）。引き揚げ会社の経営者や作業員は、役職で呼ぶ背景として描く
-    *   **検証用のテストは、標準ライブラリだけの純粋な Go（`go test`）で書く。** 時計・乱数の種・実行順は注入して固定し、テスト自体を毎回同じ結果にする
+    *   **検証用のテストは、`go test` だけで動く純粋な Go で書く**（delve・rr 等の道具が無くても通る）。 時計・乱数の種・実行順は注入して固定し、テスト自体を毎回同じ結果にする
-*   **トーン管理**（SSOT rule 15）: 沈没に伴う死の重さは、残された人の現在の姿で示す（詳細はメタファー部品）
+*   **トーン管理**（SSOT rule 15）: 沈没に伴う死の重さは、残された人の現在の姿だけで示す（詳細はメタファー部品）

興味深いのは、「〜だけ」という限定語が果たした二面性です。肯定形化の段階で「二人だけ」「標準ライブラリだけ」と記述した際には、意図しない上限や制約を生み出して範囲を歪める原因になりました。一方で、セルフレビューで修正する際には「現在の姿だけで示す」「go test だけで動く」のように、肯定形のまま不要な要素を排除する手段として機能しています。

そしてここでも、直された 7 行はすべて肯定形のままであり、否定形に戻すことなく元の意味や制約範囲へと合わせ直されています。

言い換えのズレを防ぐ差分点検の手順

これらの実測から得られる教訓は、肯定形への書き換えを行う際、書き換え後の文面単体を見ていても適用範囲の変質には気づけないということです。さらに重要なのは、「書き換え後」と「手直し後」の 2 段だけを比較すると、どちらが元の制約でどちらが変更なのか、変化の向きを取り違えやすいという点です。

点検を行う際は、必ず「書き換え前の元の文面（Before）」と「肯定形への書き換え後（After）」を直接突き合わせる必要があります。

元の文面が何を禁じていたかを以下の 3 つの軸で書き出し、書き換え後の肯定文が同じ境界を保っているかを検証します。

  1. 適用条件（いつ）: フェーズ、対象コマンド、実行タイミングの限定が勝手に解除されたり、全体へ一般化されたりしていないか（rule 18 で Phase 3 限定が Phase 2 以降全体へ広がった例）。
  2. 拘束力（どこまで）: 努力目標や結果の受容が義務化されていないか、あるいは「毎回〜しない」という偏りの防止が全回入れ替えのような過度な制約へ強化されていないか（rule 5 の記録義務、rule 10 やエピソード終わり方の全回義務化の例）。
  3. 対象範囲（何を）: 排他限定語（「〜だけ」）によって不要な上限が加わっていないか、逆に守るべき排除条件が脱落していないか、対象が別の概念へすり替わっていないか（登場人物の上限、テストツールのすり替わり、トーン管理での否定脱落の例）。

通常の行単位の git diff では、文全体が 1 行まるごと置き換わったように表示されるため、どの助詞や限定語が増減したのかを一目で追うのが困難です。

Git には単語単位の変更を表示する --word-diff オプションが用意されています2。既定の git diff --word-diff=plain では空白で区切られた単語単位で [-削除-] と {+追加+} が表示されますが、日本語のように単語間に空白を置かない言語では、1 文全体が 1 つの単語とみなされてしまい、効果を発揮しにくい場合があります。

そこで、正規表現で語の区切りを指定する --word-diff-regex=. を併用します。これにより各文字が 1 語として扱われ、文字単位での差分表示が可能になります。「だけ」「毎回」「必ず」「まで」といった、ルールの適用範囲を左右する重要な語句の増減を確実に見つけ出すことができます。

ファイル: check-diff.sh

#!/bin/bash
set -euo pipefail

# 直前のコミットとの間で、日本語の文字単位の差分を表示する
git diff --word-diff=plain --word-diff-regex=. HEAD~1 HEAD

このコマンドを実行すると、変更前後の文面がインラインで展開され、削除された文字が [-...-]、追加された文字が {+...+]} として可視化されます。これにより、「元は何を禁じていたか」と「書き換えで何が足されたか」を最小の認知的負荷で照合できます。

トレードオフと書き手の立場

前節で示した点検手順を用いれば、実測の 10 件の修正プロセスが示しているように、肯定形の文脈を維持したままでも元の制約範囲へ正確に合わせ直すことができます。

しかし、すべてのルールに対して 1 文ずつ「いつ・どこまで・何を」を問い直して文字単位で差分を精読するには、相応のレビューコストがかかります。

ルールの指示形式を選択するにあたっては、肯定形指示と否定形指示の特性とトレードオフを客観的に理解しておく必要があります。以下に両者の特性を整理します。

指示形式適したユースケース強み弱み・リスク適用判断の指針
肯定形指示（What to do）推奨手順、出力フォーマットの指定、文体・トーンの指示モデルの生成方向を直接ガイドし、何をすべきかを明確化できる適用範囲や除外条件を網羅しようとすると記述が冗長化し、暗黙の要件拡大やすり替わりを招きやすい振る舞いの主軸や成果物の形式を指示する際に原則として採用
否定形指示（What not to do）禁止操作、特定フェーズ外での利用遮断、外部依存の排除簡潔な記述で離散的かつ明確な境界線を確定できる否定語が成果物へ転写される懸念や、何をすべきかの代替動作が伝わらないリスクがある境界確定や禁止条件において簡潔・正確に表現できる場合に許容して採用

このように、肯定形指示はエージェントの自律的な振る舞いや生成フォーマットを誘導する上で優れている一方、厳密な境界線を定義しようとすると表現が冗長化し、適用範囲の意図せぬドリフトを招きやすくなります。対照的に、否定形指示は簡潔かつ決定論的に境界線を確定できる強みを持っています。

筆者の現場における運用スタンスとしては、CLAUDE.md やスキル定義の指示において、否定形の語句がそのまま生成コードや出力文書へ転写されるのを避けるため、原則として肯定形で書くよう指示しています。

しかし、無理な肯定形化には限度があり、本記事で示したような適用範囲の変質を招くリスクが常に伴います。そのため、否定形の方が簡潔かつ正確に制約境界を表現できる場面では、状況次第で否定形も許容する柔軟な姿勢をとっています。

プロンプトや実行環境（ハーネス）を作り込むほど、モデル本来の挙動は見えにくくなり、「否定形は絶対に避けるべきだ」という直感にとらわれがちです。しかし、「有効な否定形もある」という一次情報を誠実に受け入れ、自身の直感だけに頼らず、状況に応じて適切な形式を選択していくことが重要だと考えています。

なお、今回の 10 件の実測はすべて肯定形のままで修正が完了しているため、この 10 件そのものを「否定形の方が正確だった」ことの根拠とするわけではありません。あくまで点検によって範囲を合わせ直すことが可能であったという事実と、その上でなお形式を選択する判断軸の話です。

前提が変われば結論はどう変わるか

ルールの記述方針や点検の厳密さは、運用するエージェントの自律性やコンテキストの規模、そしてモデル技術の進化によっても変わります。

ルールセットが数行から十数行程度で、人間が毎回プロンプトや出力を直接目視確認できる小規模な運用であれば、多少のニュアンスのブレは人間側で吸収できるため、文字単位での厳密な点検を毎回行う必要性は低いでしょう。

一方、Claude Code のような自律型コーディングエージェントにプロジェクト固有のコンテキスト（CLAUDE.md）を読み込ませ、長時間にわたって自走させるような開発環境では事情が異なります。公式ドキュメントでも指摘されているように、指示が具体的かつ検証可能に書かれているほど、モデルは指示を首尾一貫して遵守しやすくなります3。例えば、読み込み対象フェーズの過度な拡大は後続エージェントが必要な設計情報にアクセスできなくなるタスク不全を招き、不要な限定語の追加は柔軟な生成の阻害へ、逆に排除すべき制約の脱落は文脈情報の漏洩へと直結します。こうした自律運用では、ルールの適用範囲がわずかに広がる・狭まるだけでも、予期せぬ制約逸脱や意図しない動作の連鎖を引き起こすリスクが高まります。ルールセットをリファクタリングする際には、差分点検の重要性が極めて高くなります。

また将来的には、推論モデルの進化によってモデル側が文脈から意図を補完する精度が高まったり、プロンプトの回帰テストやセマンティック差分点検ツールが普及したりすることで、人間による手動の文字単位点検の負担は軽減されていく可能性があります。しかし、自動化ツールやテストスイートを導入する段階においても、「元は何を禁じていたか」という境界線の定義そのものは設計者が厳密に把握している必要があります。その意味でも、Before と After の差分を 3 軸で突き合わせる規律は、あらゆるプロンプト保守の基礎として残り続けるはずです。

よくある質問（FAQ）

Q. プロンプトのルールを否定形から肯定形に書き換える際、適用範囲はどう変化しやすいですか？

A. 変化の向きは一様ではなく、広がる・狭まる・すり替わる・固定される・否定が脱落するなど複数の向きに生じます。元の文面が何を禁じていたかを特定しないまま肯定形に直すと、対象フェーズが広がったり、言及されていなかった作業に記録義務が生じたり、外部ツールの禁止が特定ライブラリへの限定にすり替わったりします。

Q. 肯定形への言い換えによる適用範囲のズレを防ぐにはどう点検すればよいですか？

A. 書き換え後の文面だけを見るのではなく、「元の文面（Before）」と「肯定形への書き換え後（After）」の差分（diff）を直接突き合わせます。「元は何を禁じていたか（いつ・どこまで・何を）」の 3 軸を書き出し、書き換え後の文面がその範囲を超過・縮小していないかを、単語単位や文字単位（--word-diff-regex=. など）で確認します。

まとめ

  • 肯定形への言い換えは適用範囲を動かす: 「中身は変えていない」と意図した書き換えであっても、適用条件・拘束力・対象範囲のいずれかで意図せぬドリフトが発生します。
  • 変化の向きは多方向である: 範囲は広がるだけでなく、狭まる、別の制約へすり替わる、手順が固定される、必要な否定が脱落するなど多方向に動きます。
  • Before と After の差分で点検する: 書き換え後の文面単体ではなく、元の文面が何を禁じていたかを書き出し、diff を用いて 3 軸（いつ・どこまで・何を）で突き合わせます。
  • 点検すれば肯定形のままでも直せる: 実測の 10 件が示すように、範囲のズレを認識できれば肯定形のままでも元の制約範囲へ合わせ直すことができます。
  • 原則肯定・状況に応じた否定形の許容: 成果物の形式や推奨アクションは肯定形で導きつつ、否定形の方が簡潔・正確に境界を確定できる場面では無理な言い換えを避けて否定形も許容します。

プロンプト設計、AI エージェントのルールセット保守、AI Operations の導入設計やガバナンス構築について、ぜひ コンタクトフォーム よりお気軽にご相談ください。

Footnotes

  1. Prompting best practices Anthropic 公式ドキュメント、2026年アクセス。出力形式制御の項目「何をしないかではなく何をすべきかを指示する（Tell Claude what to do instead of what not to do）」という指針の推奨根拠。節 ## Output and formatting → ### Control the format of responses。 ↩

  2. git-diff Documentation Git 公式ドキュメント、2026年アクセス。単語単位差分表示の --word-diff オプションおよび文字単位差分表示の --word-diff-regex オプションの仕様。 ↩

  3. How Claude remembers your project Anthropic 公式ドキュメント、2026年アクセス。CLAUDE.md の記述指針（具体的に検証可能に書くほどモデルが首尾一貫して従いやすい）の根拠。 ↩