念を押さない技術

CC BY 4.0

一番強く書いた節が、一番機構が薄かった

私の手元の本番プロジェクト——typingtube という、YouTube の音楽動画でタイピング練習ができる Web サービスです——の指示ファイルは 102 行、空行と見出しを除くと 69 行です。強調を含むのは 7 行でした。

数える前は、強調は自分が本当に大事だと思ったところに付いているつもりでした。実際には、そうではありませんでした。7 行のうち 5 行は、機構が同じことを守っています。 機構というのは、hook や自動テストのように、読まれなくても動く仕組みのことです。

• 翻訳ファイルの構文チェック（pre-commit hook で走る）
• デザインのラチェット（pre-commit hook で落ちる）
• サブエージェントの起動ガード 2 行（用途カタログに無ければ起動しない）
• テストの並走ガード（並列実行の 2 本目は走らない）

破っても、強調のおかげで止まるわけではありません。hook が止めます。

残る 2 行が、この指示ファイルで唯一「最重要」を名乗っている節です。ホスト上で Ruby や Node のコマンドを直接実行しない、すべてコンテナ経由で、という決まりごと。ここには機構がありません。 テスト実行だけは入口を塞いでありますが、bundle も npm も rake も、止めるものは何も置いていません。

つまり——一番強く書いた節が、一番機構が薄い。

効いているかどうかは、測れません

正直に書きます。この節は破られていません。 私はコンテナ経由で実行していますし、AI もそうしています。

だからといって「強調が効いた」とは言えません。前作の第 6 回で、こう書きました——あなたの指示ファイルで一番大事な禁止事項を 1 つ選び、それが先月何回破られたか答えられますか。答えられないのが普通で、理由は、破られても何も起きないからです。

強調も同じです。効いたから破られなかったのか、そもそも破る場面が来なかったのか、区別が付きません。そして区別が付かないものは、増やしても減らしても違いが見えない。見えないから、増えます。

増えた結果がどうなるかは、前作の序論に書いたとおりです。ルールを整理し、優先順位を付け、大事なものを太字で先頭へ。80 行。AI はもっと守らなくなる。 強調は相対的なもので、全部が強調されている文書に、強い行は 1 行もありません。

Anthropic のプロンプト指針も、いまは逆を向いています。以前のモデルで反応が足りなかったものは今は適切に反応するので、過剰な指示を消せ、「迷ったら〜せよ」の類は過剰な反応を招く、と。徹底を促す言葉を足していたなら、弱めよ、とまで書かれています。念を押す文は、まさにその「徹底を促す言葉」です。

理解したことは一文にできます。

強調は、機構の無いところに生える。そして効いたかどうかは測れない。だから効き目ではなく、増え方だけを見る。

仕組み: 効き目を測らず、件数をラチェットにする

置くのは自動テスト 1 本です。強調を含む行を数えて、基準値を超えたら落とすだけ。ラチェット——一方向にしか動かない歯止めのことです。

# test/reference/claude_md_emphasis_ratchet_test.rb（実物からの簡約版）
EMPHASIS = /\*\*|⚠️|最重要|絶対|必ず/
BASELINE = 7          # 2026-09-04 の実測。7 行のうち 5 行は機構あり

test "emphasis in the instruction file does not grow past the baseline" do
  lines = File.readlines(Rails.root.join("CLAUDE.md"))

  # ⚠️ 対象 0 件で緑にしない。読み先が壊れたらここで落ちる
  assert_operator lines.count { |l| l.strip.present? }, :>=, 50

  emphasized = lines.each_with_index
                    .select { |line, _| line.match?(EMPHASIS) }
                    .map { |line, i| "CLAUDE.md:#{i + 1}: #{line.strip}" }

  assert_operator emphasized.size, :<=, BASELINE,
                  "emphasis went past the baseline. before adding one, see whether the line " \
                  "can be guarded by a check instead. if it cannot, raise BASELINE and " \
                  "write down why\n#{emphasized.join("\n")}"
end

前作の第 6 回で「全部を今すぐ直せないルールはラチェットにする」と書いた、あの形です。効き目は測っていません。 測れないものを測ったふりをすると、そこから先が全部嘘になります。この自動テストが言うのは 1 つだけ——増やす前に、機構で守れないか見ろ。

逃げ道もそのままにしてあります。基準値を上げれば通ります。それでいいのです。上げるときに一度立ち止まって、「この行は自動テストにできないか」を考える。そこが本体で、数字はそのきっかけにすぎません。

CC BY 4.0 はここまで

CC BY 4.0

注意: 効き目は測れず、語形しか見ていません

一つ、この自動テストは効き目を測っていません。 強調が減れば守られるようになる、とは言えません。言えるのは「機構で守れる行が強調のまま残っていないか」を、増やすたびに一度見る、というところまでです。

二つ、語形しか見ていません。 太字と ⚠️ と 3 語だけです。「とても重要」を「きわめて重要」に書き換えれば抜けます（第 1 回と同じ構造です）。

三つ、この記事にも ⚠️ が並んでいます。 数えると、私が指示ファイルに置いた数よりずっと多い。強調が悪いのではありません。悪いのは、機構で守れるものを強調で守ろうとすることと、強調が増え続けることの 2 つだけです。

検証手順: 増やして、落ちることを確かめる

前提

• 強調を含む行を数える自動テストを 1 本置き、今の件数を基準値としてファイルに記録し終えていること
• その自動テストが、今は通っていること

所要時間: 10 分

手順

1. あなたが、指示ファイルに太字か ⚠️ を含む行を 1 行足します。中身は何でも構いません（基準値を超えさせるのが目的です）
2. あなたが、その自動テストを走らせます
3. あなたが、失敗のメッセージに並んだ行を 1 行ずつ見て、そのうち何行が機構で守られているかを数えます。機構とは、hook や自動テストのように、読まれなくても動く仕組みのことです

合格条件（すべて満たすこと）

• 自動テストが落ちる
• 失敗のメッセージに、現在の強調行が全部並ぶ

合格しなかったとき

• 「件数が基準値を超えました」だけで、行が並ばない —— 手順 3 ができません。行の一覧を出す形に直してから、やり直します
• 落ちない —— 基準値のファイルが、今の件数より大きい値になっています

⚠️ 手順 3 がこの検証の本体です。 落とすことが目的ではなく、落ちたときに一覧が目の前に出ることが目的の自動テストです。強調のまま残っている行のうち、機械へ移せるものが何行あるかが、ここで分かります（この記事の例では 7 行中 5 行がそれでした）。

後始末

• 手順 1 で足した行を消し、自動テストが合格に戻ることを確かめます

CC BY 4.0 はここまで