AI活用全般

Claude Opus 4.7システムプロンプトリーク読解|4.6から変えるべきCLAUDE.md記述3点+書き換え変換表とBefore/After

この記事の結論

  • Claude Opus 4.7のシステムプロンプトがCL4R1T4Sリポジトリで読める状態になっており、4.6時代のCLAUDE.mdや運用プロンプトは3箇所の書き換えが必要。
  • 変更の核は「指示追従の厳格化」「effort levelsの厳守」「visual output routingのstep 0ガードレール」の3点。曖昧な緩衝語と固定長指示は削除・明示化する。
  • リポジトリはAGPL-3.0の公開資産、Anthropic自身もclaude.ai版を2024年から公式公開中。本稿は読解と変換のみで、全文転載はしない。

Claude Opus 4.7が出て2日、
私のCLAUDE.mdは3箇所を書き換えました。
4.6のプロンプトを流用したままだと、
体感で挙動がズレる。
特に低いeffort levelで動かしたときの「行間を読まなさ」が明らかに違う。

参照した一次情報は、
elder-pliniusさんのCL4R1T4Sリポジトリに収録されているANTHROPIC/Claude-Opus-4.7.txt
starlinglyさんのcommentary
それとAnthropic公式マイグレーションガイド
この3点を突き合わせると、
どこを書き換えるべきかが割と明確に見えます。

この記事は、
リーク全文の翻訳ではなく、
ガチ運用勢向けの変換表です。
左=システムプロンプト内の記述、
中=Claudeが内部でやっていること、
右=ユーザー側のCLAUDE.mdにどう落とすか。
ここまで1対1で書いた日本語記事がまだ無かったので、
私が先に出します。

そもそも今回の「リーク」は何を指すのか

用語を先に整理しておきます。
世間で「Opus 4.7 システムプロンプトがリーク」と言われているものは、
厳密には2層あります。

1層目はAnthropic自身が公式公開しているclaude.ai/モバイルアプリ版のシステムプロンプト
これは公式リリースノートページに掲載されていて、
4.7版は2026-04-16付けで公開されています。
2024年8月にClaude 3世代のプロンプトを初公開して以降、
Anthropicは定期的にこれを出し続けている(TechCrunch 2024-08-26)。
ここは「リーク」ではなく公式ドキュメント。

2層目がCL4R1T4Sなど有志リポジトリが収集している版
こちらはプロンプトインジェクションや観察から再構築された記述が含まれ、
公式版より詳細なガードレールや内部指示が読める。
CL4R1T4SはAGPL-3.0の公開リポジトリで、
スター14,700以上、
"AI SYSTEMS TRANSPARENCY FOR ALL"を掲げています。

ここで一つ、
誤解されやすい点を先に潰しておきます。
公式公開の注意書きに「These system prompt updates do not apply to the Claude API」と明記されている通り、
claude.ai版のシステムプロンプトとAPI/Claude Codeでの挙動は一部異なります。
この記事はAPI・Claude Codeでガチ運用している層を想定しているので、
claude.ai固有の記述(アーティファクト関連など)は落とし、
API経由でも効いてくる挙動差に絞って読んでいきます。

"AI SYSTEMS TRANSPARENCY FOR ALL"

— CL4R1T4Sリポジトリ スローガン(出典

倫理論点は後段で1セクション取りますが、
先に結論だけ。
リポジトリは既に公開資産、
Anthropicも過去版を自ら公開している、
私は読解のみで生成には一切関わっていない。
三段で立てます。
リーク礼賛はしません。

4.6から4.7で何がどう変わったのか(差分3点)

CL4R1T4Sの4.7版と、
asgeirtjリポジトリのClaude Opus 4.6版
それとstarlingly commentaryを突き合わせて、
ユーザー側プロンプトに影響する差分だけを3点に絞りました。
これ以外にも絵文字制限や語彙制限("genuinely"禁止など)の新規追加はあるんですが、
運用プロンプトの書き換えにはほぼ影響しないので割愛。

差分1: More Literal Instruction Following(指示追従の厳格化)

公式マイグレーションガイドに明記されている最重要変更。

"Claude Opus 4.7 interprets prompts more literally and explicitly than Claude Opus 4.6, particularly at lower effort levels. It will not silently generalize an instruction from one item to another, and it will not infer requests you didn't make."

Anthropic公式マイグレーションガイド

要するに、
4.6までは「1項目に指示を書けば他の類似項目にも自動展開」していた挙動が、
4.7では止まります。
特にloweffortで顕著。
これ地味にきつい。

私のCLAUDE.mdにも「必要に応じて」「可能なら」という曖昧な緩衝語があちこち残っていたので、
4.7切り替え後に指示が素通りするケースが実際に出ました。
具体例は後段のBefore/Afterで出します。

差分2: Effort Levelsの厳守とxhigh新設

4.7ではeffort levelsがlow / medium / high / xhigh / maxの5段階になり、
budget_tokensパラメータが完全廃止。
thinking: {type: "enabled", budget_tokens: N}は400エラーになります(公式What's New)。

"Claude Opus 4.7 respects effort levels strictly, especially at the low end. At `low` and `medium`, the model scopes its work to what was asked rather than going above and beyond."

公式マイグレーションガイド

「必要最低限しかやらない」が明文化された。
コーディング・エージェント用途はAnthropic自身がxhigh推奨、
知識作業は最低highと公式が言っている。
逆に単純な書類整形とかはmediumlowに下げないとコストが跳ねる。
この使い分けを雑に扱うと4.6以上に損します。

なお、
effort levelsはAPI・Claude Code側の概念であり、
claude.ai(Webチャット)では直接設定できません

この記事の想定読者はAPI層なので問題ないですが、
Web版しか使っていない人が同じ文脈で読むと混乱するポイント。

差分3: Visual Output Routing(step 0ガードレール)

4.7で新設された視覚出力の判定ロジック。
starlingly commentaryから引用します。

"The prompt implements 'step 0' as a guardrail: 'Most requests are conversational and fully answered by text.' This prevents over-production of visuals when users didn't explicitly request them."

starlingly commentary

4.6では頼んでもいないのに図解やMermaidが湧いてくることがあったんですが、
4.7では「明示的に要求されない限り散文で返す」が原則になった。
加えて"Claude does not narrate routing"、
つまりどの出力手段を選んだかを説明しない。

図解やインライン可視化が欲しい場面では、
こちらから「インライン図として可視化してください」と明示的に指示する必要があります。
これが地味に効く変更。

一次情報×ユーザー運用の1対1変換表

ここが本記事のコアです。
システムプロンプトに書かれている記述を読んで、
それを私のCLAUDE.mdやユーザープロンプトにどう反映するか。
左=プロンプト内記述、
中=Claudeが内部でやっていること、
右=こちら側の書き換え文例。

システムプロンプト内の記述(4.7)Claudeが内部でやっていることユーザー側(CLAUDE.md/プロンプト)への落とし込み
"interprets prompts more literally … will not silently generalize"書かれた通りにしか動かない。1項目の指示を他項目に暗黙展開しない。「このルールはすべての回答に適用する」を明示。「必要に応じて」「可能なら」「try to」は削除。
effort levels: low=省コスト / xhigh=コーディング推奨推論深度を段階指定で計算。lowでは表面的処理のみ、追加作業を自発的にやらない。Claude CodeのCLAUDE.mdにeffort: xhighを明記。単純なバッチ処理はmediumに下げてコスト管理。
budget_tokens廃止、thinking: adaptive only固定トークン上限ではなく、タスク難易度に応じてthinkingを自動ON/OFF。thinking: {type: "adaptive"}output_config: {effort: "high"}をペアで設定。旧budget_tokens指定は400エラーで落ちる。
新tokenizer(約1.0〜1.35倍化)同じ入力でもトークン数が最大35%増える(コンテンツ種別で差がある)。max_tokensを1.35倍程度に上方修正。JSON・コード中心のプロンプトは特に余裕を。プロンプトキャッシュの閾値も再設定。
"Most requests are conversational and fully answered by text."visual出力は明示的要求がないと生成しない。step 0でガード。図解・Mermaid・コードブロックを出させたいときは「インライン図として可視化してください」と明示。
"Claude does not narrate routing"MCPツール選択・ファイル生成などのルーティング判断を説明しない。どの処理経路で回答したかを知りたい場合は「使ったツールと判断理由を末尾に列挙してください」と明示。
Response length calibrates to task complexity簡単な質問は短く、複雑な分析は長く、自動でキャリブレートする。固定長(「300字以内」等)は簡単な質問では不要。逆に短くなりがちな質問で詳述が欲しいときは「根拠と手順も含めて詳細に」と明示。
"Once Claude refuses … all subsequent requests must be approached with extreme caution"一度リフューズされた会話は、以降の全発言に警戒フラグが立つ(cascading restriction)。長いエージェントセッションでリフューズが起きたら、会話を切って新規セッションで再投入。同一文脈での粘り続けは逆効果。
"long_conversation_reminder" が存在長い会話でも指示を維持するリマインダーが自動挿入される。CLAUDE.mdの重要ルールは冒頭に集中配置。リマインダーで再注入される前提で優先度の高い指示を上に積む。

この9行分を私のプロンプトに反映したところ、
体感で指示追従の精度が戻りました。
特に差分1の緩衝語削除は効く。
これは本当にやった方がいい。

Before/After実例:私のCLAUDE.mdから抜粋

抽象論で止めない、
が今回の記事の主旨なので、
実際に私が書き換えた2例を出します。
Aisola LabプロジェクトのCLAUDE.mdと、
tool-writeコマンド用のwriterプロンプトからの抜粋。

実例1: writerエージェントの文体ルール(指示追従の厳格化対応)

Before(4.6時代)

## 文体ルール
- 一人称は「私」で統一(可能なら「自分」も避ける)
- 語尾は必要に応じて混ぜる
- 同じ語尾の3連続はなるべく避ける
- 「〜することができます」は使わないようにする

4.6ならこれで動いていました。
「可能なら」「必要に応じて」「なるべく」「〜しないようにする」の緩衝語を全部拾って適切に動いてくれた。
ただこれ、
4.7のloweffortで流すと、
語尾チェックが素通りして3連続が普通に出てきます。
私、
最初これで記事3本分くらい時間を溶かしました。

After(4.7対応)

## 文体ルール(このルールは全出力に例外なく適用)
- 一人称は「私」。
「自分」は使用しない。 - 語尾は「です」「ですね」「ます」「と思います」から最低3種を混在させる。 - 同じ語尾の3連続は禁止。
検知したら書き直す。 - 「〜することができます」「〜が可能です」は使用禁止。
「〜できます」に置換する。

「可能なら」を全削除、
「なるべく」を「禁止」に置換、
スコープを「全出力に例外なく適用」で明示。
これでeffort: high以上なら安定、
mediumでも崩れにくくなりました。
ビフォーアフターで出すとたいしたことないように見えるかもしれませんが、
差は体感で結構デカい。

実例2: researcherエージェントの出力形式(visual routing対応)

Before(4.6時代)

## 出力
調査結果をまとめて出力してください。
必要であれば表や図解で整理してもOKです。

4.6はここから勝手に表を組んで出してくれていた。
4.7は違う。
step 0ガードレールが効いて「会話として文章で返す」方向に全振りするので、
テーブル出力がほぼ出なくなります。

After(4.7対応)

## 出力フォーマット(すべて必須)
1. 冒頭に3行サマリー(散文)
2. 3列マークダウンテーブル(左=記述/中=挙動/右=落とし込み)を最低8行
3. 出典URL一覧を末尾に列挙
図解・テーブルは「インライン可視化」として出力すること。

「必要であれば」を消して「必須」に、
フォーマットを番号付きで全部明示、
最後に「インライン可視化として出力」をダメ押し。
これで4.7でも安定して構造化出力が返ってきます。
正直、
ここまで書くのは最初しんどいと思った。
でもやると楽になる。

性能変化の数字と、それがプロンプト設計に与える影響

ベンチマークも補助線として置いておきます。
数字は設計判断の根拠にしかならないので、
必要最低限。

項目4.64.7出典
SWE-bench Verified80.8%87.6%(+6.8pt)Vellum AI
CursorBench58%70%(+12pt)Vellum AI
MRCR(長文コンテキスト)78.3%32.2%(-46.1pt)Apiyi調査(三次情報)
BrowseComp(ウェブ検索)83.7%79.3%(-4.4pt)Vellum AI
CharXiv推論(ツール無)69.1%(推定)82.1%(+13pt)Anthropic公式
料金(Input/Output)$5 / $25 per MTok$5 / $25 per MTok(据え置き)公式

コーディング・視覚処理は素直に強い。
問題はMRCRの急落です。
78.3→32.2はApiyi調査が出した数値(出典リンク)で、
公式ベンチマークには直接同じ数字の掲載は私が確認した範囲では見つかっていません。
つまり三次情報です。
ここは慎重に扱う必要があります。

ただ、
現場の開発者報告では「800行のワークフロー文書を送ると、
読んだと主張するが出力が内容と無関係」という症状が複数報告されており、
数字の水準はともかく長文での指示保持が4.6より弱くなっている傾向自体は、
実際にCLAUDE.mdが巨大化しているプロジェクトで私も体感しました。
仮説ベースの対処ではあるものの、
しておいた方が安全です。

私の対応策は3つ。
①CLAUDE.mdの重要ルールを冒頭200行以内に圧縮、
②サブエージェントに渡す情報は毎回明示的にリピート、
③長文セッションでは定期的に「これまでのルールを1行でリスト化してから続行」と挟む。
これだけでかなり戻ります。

倫理の立て付け:なぜこの記事を書いていいと判断したか

リーク系の題材は、
避けて通ると「扱ってないようで実は扱っている」みたいな曖昧な文章になって逆に燃える。
1段落で正面から書きます。

判断の三段。
①CL4R1T4SリポジトリはAGPL-3.0の公開資産で、
スター14,700以上の既に誰でもアクセスできる状態

②Anthropic自身も2024年8月から自社のシステムプロンプトを公式公開しており、
2026-04-16付けで4.7版も出している
公式)。
「With these new system prompt changelogs — the first of their kind from a major AI vendor — Anthropic is exerting pressure on competitors to publish the same.」とTechCrunchが報じている通り、
透明性の方向は公式の方針。
③私は全文転載をせず、
読解と変換表の作成のみに留めている

生成や派生プロンプトの配布はしていません。

三段揃えた上で、
「リーク礼賛」ではなく「公開資産の読解から運用を改善する」角度で書いています。
ここは私の中で一本線を引いた。

FAQ

Q1. CL4R1T4Sリポジトリを見に行くのは合法ですか?

リポジトリ自体はAGPL-3.0で公開されており、
閲覧自体に問題はないと私は判断しています。
ただし転載・再配布時はライセンス条項の順守が必要です。
そして最終判断は各自で。
本記事は閲覧と分析のみを想定しています。

Q2. effort levelsはClaude.aiのWebチャットでも設定できますか?

できません。
effort levelsはAPI・Claude Code側のパラメータです。
Webチャット利用者の場合は、
プロンプト本文に「詳細に思考してから回答してください」「最小限の処理で答えてください」といった自然言語での指示に置き換える必要があります。

Q3. CLAUDE.mdの緩衝語を全削除したら、柔軟性が落ちませんか?

落ちます。
ただし4.7では「柔軟に対応してくれる」方向の期待がそもそも外れるようになったので、
柔軟性を保つならケースごとに明示的な分岐を書く方向に切り替えるのが現実的です。
「ケースAの場合はX、
ケースBの場合はY」と書く方が、
「必要に応じて」より確実に動きます。

Q4. MRCRの-46.1ptは本当ですか?

Apiyi調査(第三者計測)が出している数字で、
公式ベンチマークで同じ数値が直接確認されたわけではありません。
ただし長文コンテキストでの指示保持が弱くなっている傾向自体は複数の開発者報告と、
私自身の使用でも一致しています。
数字そのものより「対策はしておく」方が実利があります。

Q5. トークナイザー変更で料金はどう変わりますか?

単価は$5/$25 per MTokで据え置き(4.6と同額)ですが、
トークナイザーが新しくなり同じ入力でも約1.0〜1.35倍のトークンを消費するため、
実質的な請求額は最大1.35倍まで増え得るのが現実です。
JSON・コード中心のワークロードは特に影響を受けやすいので、
コスト試算はやり直しておいた方が安全。

Q6. budget_tokensが使えなくなって困っています。代替は?

thinking: {type: "adaptive"}output_config: {effort: "high"}のペア設定が公式の推奨パスです。
thinking: {type: "enabled", budget_tokens: N}は400エラーで落ちるので、
公式マイグレーションガイドに従って書き換えてください。

関連リンク

本記事で参照した一次・準一次情報をまとめておきます。

公式

リポジトリ・commentary

倫理・透明性

性能・ベンチマーク

4.6時代のプロンプトを4.7でそのまま使い続けると、
挙動がじわじわズレていきます。
曖昧な緩衝語の削除と、
effort levelsの明示、
そして図解出力の明示要求。
この3点を潰すだけで体感が戻ります。
私は週末の2時間で主要CLAUDE.mdを全部書き換えて、
今はかなり安定運用中。

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。

-AI活用全般
-, ,

← 戻る