Claude Code に作業を頼むとき、指示文の頭に英語の文を 1 つ書き足すと、Claude がコードをどう直すかが変わるのかを技術検証しました。書き足したのは “This codebase is yours: what it’s for and how it’s built are your call, and you’ll keep building on it.” という文で、意味は「このコードはあなたの物。何のためにどう作るかはあなたが決め、この先も作り続ける」くらいです。

Anthropic の文書「Prompting Claude Fable 5.2」は、この文を勧めています。同じ処理が 2 か所に写してあるコードに 3 つ目の仲間を足させると、写しをもう 1 つ増やす回と、先にまとめてから足す回に分かれますが、この文を書き足すと、写しを増やさずにまとめる回が増える、というのが文書の説明です。

ここでいう「コード」は、私たちが課題として用意した Python の小さなコード（6 つ）のことで、この文は、Claude に渡す指示に私たちが書き足した言葉です。Claude Code 2.1.322 のヘッドレス実行で、指示の先頭にこの文と空行を書き足した回（以下、「このコードはあなたの物」と伝えた回）と、書き足さない回（以下、伝えない回）を比べました。

結論

  • 写しが別々のファイルにある作り（p4〜p6）では、「このコードはあなたの物」と伝えた回は 9 回中 9 回まとめ、伝えない回でまとめたのは 3 回でした。伝えない回の残りは、写して足したのが 5 回、既存の片方を借りたのが 1 回です。写した回は、重複に気づいたうえで残していました。
  • 写しが同じファイルの中で隣り合う作り（p1〜p3）では、伝えない回でも 9 回中 8 回まとめました。文書の「この文が無いと 1 割未満」は、この作りでは再現しませんでした。
  • 「このコードはあなたの物」と伝えた回は、既存の振る舞いも 9 回中 9 回変えました。どれも報告には書いてありましたが、元のテストはどの回も通ったので、テストでは見つかりませんでした。
  • 伝えた回は伝えない回に比べて、出力トークンが 1.18 倍、変えた行が 1.7 倍、推定費用が 1.14 倍でした（p4〜p6 の平均）。

次の図は、重複の場所と、「このコードはあなたの物」と伝えたかどうかで、結果がどう分かれたかを表しています。図の「伝えた」は、指示の先頭に英文を書き足した回です。

重複の場所と、「このコードはあなたの物」と伝えたかで、まとめた回数が分かれた

別ファイルの作りで伝えない 9 回のうち 5 回は、写して足しています。伝えた 9 回は、まとめると同時に既存の振る舞いも変えていました。

試した環境

  • Mac、Claude Code 2.1.322。変更履歴によると、Claude Fable 5.2（claude-fable-5-2）は 2.1.321 で足され、既定の Fable のモデルになりました。
  • モデルは claude-fable-5-2、--effort high（API の既定と同じ）。result の modelUsage には、会話の題を作る要求の claude-haiku-5-5 も出ました。
  • CLAUDE.md・スキル・フックなどを読まない --safe-mode と、ユーザの設定を読まない --setting-sources project を付けました。--safe-mode でも --append-system-prompt は届くことを、先に確かめています。
  • 費用は、Claude Code が result に出す推定（total_cost_usd、定価での見積もり）で、請求額ではありません。この測定はサブスクリプションの枠で回しました。

起こし方は次のとおりです。

claude -p "$PROMPT" --model claude-fable-5-2 --effort high \
  --safe-mode --setting-sources project \
  --permission-mode dontAsk --no-session-persistence \
  --output-format stream-json --verbose \
  --allowedTools Read Write Edit Glob Grep "Bash(python3 *)" "Bash(ls *)"

文書が言っていること

Anthropic の文書の節 Say who owns the code によると、Fable 5.2 はプロンプトがコードの持ち主をどう言うかに強く従い、何も言わないと、既存のコードを繰り返すことになっても今の作りに足していきます。勧められているのは、冒頭で挙げた次の英文で、Anthropic の小さなコーディングの課題では、この文があると重複をまとめたのは約半分の回、無いと 1 割未満だったそうです。

This codebase is yours: what it’s for and how it’s built are your call, and you’ll keep building on it.

このコードはあなたの物。何のためにどう作るかはあなたが決め、この先も作り続ける。

文書には、課題の数や回数、「まとめた」をどう判定したかは書かれていません。以下で文書の値と比べるのは、目安としてです。

課題と判定

課題は Python の小さなコード 6 つです。どれも同じ処理が 2 か所に写してあり、3 つ目の仲間を足すよう頼みます。近くには、頼みでは触れない小さな不具合を 1 つずつ仕込みました。

課題既存の 2 つ足す物仕込んだ不具合
書き出しCSV・TSVMarkdownTSV の列がタブでずれる
通知メール・SMSpushSMS が 163 字になる
登録利用者の登録・更新管理者の登録更新で role が落ちる

同じ 3 つを、2 通りの作りで用意しました。

  • p1〜p3: 写しが同じファイルの中で隣り合う作りです。たとえば書き出しは、1 つのファイルに export_csv と export_tsv が並び、どちらにも同じ検査・整形・並べ替えが入っています。
  • p4〜p6: 形式・経路・処理ごとに 1 ファイルに分けた作りです（csv_format.py と tsv_format.py、channels/email.py と sms.py、handlers/create_user.py と update_user.py）。中身は同じで、写しが別々のファイルにあります。

不具合はそれぞれ、TSV で値の中のタブが列をずらす、SMS を 160 字で切った後に ... を足して 163 字になる、Store.update が行を丸ごと置き換えて role を落とす、という物です。

作業の後のコードは、スクリプトで判定しました。

  • 写した処理に固有の文字列（登録なら age must be between 0 and 150）が、テスト以外のコードに何回出るかを数えます。1 回以下なら「まとめた」、2 回なら「片方を借りた」（新しいコードが既存の片方を import し、元の重複は残した形。目でも確かめました）、3 回以上なら「写して足した」です。
  • あわせて、頼んだ機能が動くか（こちらで用意したテスト）、元のテストが通るか（作業でテストが書き換えられても、元の版で走らせる）、仕込んだ不具合が直ったかを見ました。

頼みは英語で書きました（書き足す英文が英語のため）。「このコードはあなたの物」と伝える回は、頼みの先頭にこの英文と空行を足しています。p5 の頼み（英文を足す前の形）と、その訳は次のとおりです。

Add a push notification channel to this project, registered as "push". Its send(device_token, title, body) sends the message {"token": device_token, "title": title, "body": body} through the transport. On ConnectionError it tries up to 4 times in total, waiting 0.5 s, 1 s and then 2 s between tries (doubling, at most 4 s), logs a warning for each failed try, and raises SendError when it gives up. Run python3 -m unittest before you finish.

このプロジェクトに push 通知の経路を足し、"push" の名前で登録する。send(device_token, title, body) は、メッセージ {"token": device_token, "title": title, "body": body} を transport で送る。ConnectionError のときは全部で 4 回まで試し、試みの間は 0.5 秒・1 秒・2 秒と待つ（倍にしていき、最大 4 秒）。失敗した試みごとに警告をログに出し、あきらめたら SendError を上げる。終える前に python3 -m unittest を走らせる。

同じファイルの重複は、「このコードはあなたの物」と伝えなくてもまとめた

最初は p1 で、英文を書き足さない形・頼みの先頭に書き足す形・システムプロンプトに書き足す形（--append-system-prompt）を 1 回ずつ回しました。3 回ともまとめたので、この文が要らなかったのか、頼み方や Claude Code の指示がまとめさせたのかを分けるため、英文を書き足さない形（伝えない回）を次の 3 通りで p1〜p3 に 1 回ずつ回しました。

  • A: 「CSV と TSV と同じに」のように、既存に揃えるよう言う頼み方
  • B: 揃える相手を言わず、規則を書き下した頼み方
  • C: A の頼み方で、Claude Code のシステムプロンプトを短い物に差し替えた形（--system-prompt）
伝えない回まとめた処理を共有写して足した
A300
B300
C210

C の p3 の 1 回は、新しい create_admin と既存の create_user で検査を共有し、update_user の写しは残しました。重複は増えていないので、写して足した回は 9 回中 0 回です。

頼み方を変えても、システムプロンプトを差し替えてもまとめたので、私たちは、頼み方や Claude Code の指示よりも、重複が目の前にあるかどうかが効いていると見ています。同じファイルを読めば、2 つの写しが並んで見える作りです。ただし作りを 2 通りしか試していないので、これは推測です。少なくともこの作りでは、文書の「この文が無いと 1 割未満」は再現しませんでした。

一つの皿に並んだ同じ歯車と、別々の引き出しにしまわれた同じ歯車

写しをファイルに分けると、「このコードはあなたの物」と伝えたかで割れた

そこで、同じ中身を形式・経路・処理ごとに 1 ファイルに分けた p4〜p6 を作りました。英文を書き足さずに 1 回ずつ回すと、借りた・写した・まとめた、と結果が割れたので、伝えない回と「このコードはあなたの物」と伝えた回を、各 3 回にそろえて比べました。頼み方は B（規則を書き下す）だけです。表の「伝えた」は、頼みの先頭に英文を書き足した回です。

問題伝えない伝えた
p4 書き出しまとめた 2・借りた 1まとめた 3
p5 通知写した 3まとめた 3
p6 登録まとめた 1・写した 2まとめた 3
計まとめた 3/9まとめた 9/9

「このコードはあなたの物」と伝えた効き目は、この作りでははっきり出ました。伝えずに写して足した回は、重複に気づかなかったわけではなく、最後の報告で、気づいたうえで残したと書いていました。p5 の 1 回目は「リトライのループは 3 つの経路に写された形になった。頼まれたのは新しい経路だけなので、メールと SMS には手を付けていない」、p6 の 3 回目は「ほかの 2 つをリファクタリングせず、今の作りに合わせた」と報告しています。文書の「今の作りに足していく」と、そのまま合う振る舞いです。

p5 の差分を 1 組並べると、違いが分かりやすく出ています。伝えずに写した回は、push.py に 25 行のクラスを新しく書き、リトライのループを丸ごと写しました。伝えてまとめた回は、base.py に共通の Channel クラスを作り、email.py・sms.py・push.py を、それを継ぐ数行のクラスにしています。

p4 で片方を借りた 1 回は、Markdown の書き出しが CSV の clean を import し、TSV の写しは残しました。報告には、今後 CSV だけのために clean を変えると Markdown にも及ぶ、と書いてありました。

「このコードはあなたの物」と伝えた回は、既存の振る舞いも 9 回とも変えた

頼んだ機能は 29 回すべてで動き、元のテストも 29 回すべてで通りました。それでも p4〜p6 で伝えた 9 回は、どれも既存の機能の振る舞いを変えていました（伝えない回は 9 回中 1 回）。

  • p4: メモの中の \r\n と \r も空白にした。CSV・TSV の出力も変わる（3 回とも）
  • p5: メールと SMS も、最後の失敗で警告を出すようにした。警告が 3 回から 4 回になる（3 回とも）
  • p6: 年齢に True/False を受け付けない、名前が文字列でなければ ValidationError、を create_user・update_user にも入れた（3 回とも）

p5 は、頼みの「失敗した試みごとに警告を出す」と、既存の 2 つの書き方がずれていた所です。既存のメールと SMS は、最後の試みでは警告を出さずに SendError を上げていました。伝えてまとめた回では、共通にしたループが頼みの順に書かれ、メールと SMS も 4 回警告するようになっています。

# 元の email.py（sms.py も同じ）
except ConnectionError as exc:
    if attempt == MAX_ATTEMPTS:
        raise SendError(...) from exc
    log.warning("sending to %s failed (attempt %d): %s", to, attempt, exc)

# 「このコードはあなたの物」と伝えた回で作られた base.py（3 つの経路が共有）
except ConnectionError as exc:
    self.log.warning("sending to %s failed (attempt %d): %s", recipient, attempt, exc)
    if attempt == MAX_ATTEMPTS:
        raise SendError(...) from exc

伝えずに写した回は 3 回とも、push だけを 4 回にし、メールと SMS は 3 回のままだと報告に書いていました。元のテストは待ち時間と SendError を見ていて、警告の回数は見ていません。3 つの変更はどれも元のテストに無い所で起きたので、テストは通ったままでした。

どの変更も、最後の報告には書いてありました。文書は、既存の機能の振る舞いを変えたのは 6〜10 回に 1 回としているので、私たちの課題ではずっと多く出ています。報告に書かれていない小さな変更が差分にあるかは、行ごとには確かめていません。

なお、同じファイルの作り（p1〜p3）でも、B の頼み方の伝えない回で 2 回、既存の振る舞いが変わっていました（p2 で警告の回数、p3 で型の厳しさ）。どちらも、まとめた回です。

仕込んだ不具合を直したのは p6 だけ

p4〜p6 の 18 回（伝えない回と、「このコードはあなたの物」と伝えた回の各 9 回）で、仕込んだ不具合をどう扱ったかを、最後の報告を読んで数えました。

条件直した直さず知らせた触れなかった
伝えない（9）1（p6）2（p6）6
伝えた（9）3（p6）4（p5 3・p4 1）2（p4）

直したのは、p6 の Store.update（行を丸ごと置き換えて role を落とす）だけでした。伝えた回は 3 回とも直し、伝えない回はまとめた 1 回だけが直しました。伝えずに写した p6 の 2 回は、管理者を更新すると role と team が落ちると知らせたうえで、頼みの外だとして残しています。

p5 の SMS の 163 字は、伝えた 3 回とも直さずに知らせました。3 回とも sms.py を共通のクラスを継ぐ形に書き換えていたのに、切り詰めはそのまま残し、不具合に見えるが今回の変更とは別だ、と報告しています。p4 の TSV のタブは、伝えた回のうち 1 回が知らせただけでした。文書は、持ち主を言わないと近くの問題は直さずに知らせる、としていますが、私たちの課題では、「このコードはあなたの物」と伝えても直したのは p6 だけでした。

量と費用

次の表は、p4〜p6 で伝えない回と、「このコードはあなたの物」と伝えた回の平均です。

p4〜p6 平均伝えない伝えた比
出力トークン5,8446,8901.18 倍
変えた行89.6151.81.7 倍
推定費用$0.463$0.5291.14 倍
時間56.4 秒63.5 秒1.13 倍

文書は出力トークンを約 1.5 倍としていますが、私たちの課題では 1.18 倍でした。差が大きく出たのは変えた行で、伝えた回は、どれも既存の 2 つのファイルにも手を入れています。29 回の推定費用の合計は $13.63 でした。

使うときに気をつけること

  • 重複を増やしたくないコードでは、指示の頭に「このコードはあなたの物」と伝える英文を書き足す価値があります。写しが別々のファイルにある作りで、伝えない回は 9 回中 5 回写して足し、伝えた回は 9 回ともまとめました。
  • この文を書き足したら、報告ではなく差分を読みます。私たちの課題では、ログの回数・\r の扱い・型の厳しさと、テストに無い所が変わりました。今回はどれも報告に書いてありましたが、文書も、最後のまとめは小さな変更を落とすことが多いとして、差分を読むよう勧めています。
  • 最小の変更にしたい作業では入れません。文書もそう勧めていて、「ついでのリファクタリングをしない」と同じプロンプトに書いても打ち消せなかった、としています。

確かめていないこと

  • 標本が少ないこと。作りは 2 通り、1 条件は 3 回です。モデルは Fable 5.2 だけで、ほかのモデルとは比べていません。
  • effort は high だけです。文書は、既存の振る舞いを変える回は effort が高いほど多いとしています（effort と費用の関係は、サブエージェントについて別に測りました）。
  • この英文を CLAUDE.md に置く形。Claude Code を使う人が実際に置く場所ですが、--safe-mode で CLAUDE.md を読まないようにしたので、試していません。システムプロンプトに置く形も、p1 の 1 回だけです。
  • 「他人のコードとして示す」形。文書に文例が無く、試していません。
  • 「ついでのリファクタリングをしない」と一緒に書いたときの打ち消し。文書は、それでも約 3 分の 1 の回でまとめたとしています。
  • 報告に書かれていない小さな変更が差分に無いか。行ごとには見ていません。
  • 大きなコードや長い作業。文書も小さな課題での測定です。

おわりに

指示の頭に「このコードはあなたの物」と伝える英文を書き足すと、写しが別々のファイルにある作りでは、私たちの小さな課題でもはっきり効きました。同じファイルの重複はこの文が無くてもまとめ、この文があると既存の振る舞いまで変えたので、書き足すなら差分を読む前提で使うのがよさそうです。

※ Claude Code と Claude Fable 5.2 の振る舞い、文書の内容は執筆時点の情報で、いまは変わっている可能性があります。

Claude Code の --resume で再開したエージェントが暴走しないように：2ターン動くことと、強制終了の直前の1手が抜けることClaude Code--resume Claude Code の denyInsteadOfPrompting で権限の確認を断ると、Claude は回り込まずに手を止めたClaude CodedenyInsteadOfPrompting サブエージェントの深さを下げても費用は 5% しか減らない：Claude Code の CLAUDE_CODE_SUBAGENT_EFFORT を測ったClaude Codeサブエージェント
ブログ一覧に戻る