Claude 4.7 にアップグレードしたなら、プロンプトもアップグレードする — Anthropic 公式ガイドから読み解く7つの書き換えルール

Anthropic Official Guide · 2026 · Claude Opus 4.7 Prompting

同じプロンプトを Claude Opus 4.7 に投げたら、なぜか以前と挙動が違う——そんな違和感を抱いたら、それは モデルだけアップグレードして、プロンプトを置き去りにしている サインです。Anthropic は Claude 4.7 のリリースに合わせて、プロンプトエンジニアリングのベストプラクティスを大幅に書き換えました^[1]。ベンチマークでは過去最高のスコアを叩き出す一方で、「指示を文字通り受け取る」「曖昧な依頼に対しては最小限しか返さない」「ツールを呼ぶより自分で考える」など、4.6 までの感覚で書いたプロンプトが空振りしやすい性格に変わっています。本記事では、Anthropic 公式ガイドと、それを精読した Ruben 氏が抽出した「7 つの書き換えルール」^[2]を突き合わせ、明日から自分のプロンプトに反映できる形で 14 章にまとめます。所要時間は約 15 分です。

user@sinyblog:~/article ❯ 01_tldr.md結論：4.7 に投げる前に、3 行だけプロンプトを書き換える

長い話に入る前に、結論から渡します。Claude 4.7 にアップグレードしたなら、自分の手元にあるプロンプトを開いて、最低でも以下の 3 点を直してください。それだけで成果物の質が体感で 2 段階上がります。

1. スコープを名指しする：「この契約をレビューして」と書いていたら、「条項ごとにリスクを 1〜5 で採点し、テーブル形式で返して。リスクが 3 以上の条項には書き換え案を 1 つずつ添えて」と置き換える。
2. 否定形を肯定形に書き換える：「専門用語を使わないで」と書いていたら、「16 歳の高校生が音読できる言葉で書いて。具体的な名詞（simple / specific / real など）を選び、抽象語を避けて」に置き換える。
3. 長さの上限を入れる：「要約して」と書いていたら、「正確に 5 つの箇条書き、各 15 語以内、各行は動詞で始める」のように、必ず数値で天井を切る。

user@sinyblog:~/article ❯ 02_origin.mdきっかけ — 31 ページのガイドと「7 つのルール」の出どころ

本記事の出発点は 2 つあります。1 つ目は、Anthropic 公式ドキュメントの Prompting best practices^[1]。Claude 4 系（Opus 4.7 / 4.6、Sonnet 4.6、Haiku 4.5）を対象に、応答の長さ・effort パラメータの使い分け・ツール呼び出し・トーン・フロントエンドデザイン・サブエージェント・思考モードまで、現行モデルの挙動に合わせて全面改訂された総合リファレンスです。印刷すると 30 ページを優に超えるボリュームで、しかも毎月のように追記が入っています。

2 つ目は、Ruben 氏の Substack 記事「Prompt 4.7」^[2]。本人が「31 ページの公式ガイドを週末かけて読み込んだので、皆さんはこれを読まなくていい」と前置きしたうえで、Claude Opus 4.7 用に プロンプトをアップデートすべき 7 つのルールを抽出してくれています。本記事はこの 2 本を突き合わせ、各ルールの背景に Anthropic 公式の根拠を当て直したものです。

You upgraded to a new Claude model. But you forgot to upgrade your prompts. I spent the weekend reading Anthropic's 31-page 4.7 prompting guide so you don't have to.

Ruben, Prompt 4.7 / [2]

「モデルだけ替えて、プロンプトはそのまま」——これは GPT-3.5 から GPT-4、Sonnet 3.5 から Opus 4 への移行のたびに繰り返されてきた、いちばん見逃されやすい落とし穴です。4.7 はその振れ幅が特に大きいので、放置すると「以前より弱くなった」という錯覚に直結します。

user@sinyblog:~/article ❯ 03_literal.md4.6 → 4.7 の決定的な変化「Literal instruction following」

章 4 以降のすべてのルールに通底する、唯一の核心がここにあります。Anthropic 公式は新セクション「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, Prompting best practices — Claude Opus 4.7 / [1]

翻訳すると、こうです。4.7 は指示を文字通りに読み、頼まれていないことは黙って補完しない。4.6 までは「たぶんこういう意図だろう」と気を利かせて穴を埋めてくれていましたが、4.7 はその気の利かせ方を抑える方向に明確にチューニングされています。

この変更は副作用ではなく、設計上の選択です。API ユースケース・構造化抽出・パイプライン処理では、毎回ほぼ同じ動きをしてくれた方が下流の処理が安定するから。一方で、対話的にざっくり「これいい感じにして」と頼んでいたユーザーは、急に Claude が冷たくなったように感じます。実際は冷たくなったのではなく、「いい感じ」の中身を自分で書き出していなかったのがバレただけです。

ここから先の 7 つのルールは、すべて「気を利かせてくれない 4.7 に、頼みたいことを言葉で書き切る」ための具体策と読んでください。

user@sinyblog:~/article ❯ 04_scope.mdルール1：スコープを名指しする —「レビューして」では何も返ってこない

「この契約をレビューして」「このコードを直して」「この企画書を改善して」——4.6 までは、これだけ書けばそれっぽい返事が返ってきました。4.7 では 「レビュー」「直す」「改善する」の中身が指定されていないので、最小限の動作しか行わない傾向が出ます。

この契約をレビューして。

この契約をレビューして。

- 条項ごとにリスクを抽出する
- 重要度を 1〜5 で採点する（5 が最重要）
- リスクが 3 以上の条項には書き換え案を 1 つずつ添える
- 出力は Markdown のテーブル（列：条項番号 / リスク / 重要度 / 書き換え案）

スコープ外: 文法・体裁の修正は不要。条項の追加・削除も不要。

Anthropic 公式の言葉を借りるなら「state the scope explicitly（スコープを明示的に書け）」^[1]。スコープ＝「何をやるか／どんな形で返すか／何はやらないか」を 3 点セットで書き出すと、4.7 は驚くほど忠実にそれだけを返します。

user@sinyblog:~/article ❯ 05_positive.mdルール2：否定形ではなく、期待する動作を書く

「専門用語を使わないで」「バズワードを避けて」「マーケっぽくしないで」——これらの 3 連発、4.7 にはほぼ届きません。理由は単純で、4.7 は「使わない」「避ける」を文字通り処理しようとして、参照すべき対象（＝何が「使ってはいけない」のか）を毎回新しく推論する必要があるからです。結果、最初のうちは効くものの、長文の途中から徐々に違反が混じり始める、という挙動が出ます。

公式ドキュメントもこの点で明示的です。

Tell Claude what to do instead of what not to do. Instead of: "Do not use markdown in your response" — Try: "Your response should be composed of smoothly flowing prose paragraphs."

Anthropic, Control the format of responses / [1]

専門用語を使わないで。
バズワードを使わないで。
マーケっぽい言い回しはやめて。

16 歳の高校生が音読できる言葉で書いて。
具体的で短い名詞（simple / specific / real など）を選ぶ。
「leverage」は「use」に、「scalable」は「works at any size」に置き換える。

user@sinyblog:~/article ❯ 06_length.mdルール3：長さの上限を必ず指定する

「これを要約して」と頼むと、4.7 は タスクの複雑さに応じて応答長を自動でキャリブレートするようになりました^[1]。短い質問には短く、開放的な分析には長く——その判断は基本的に正しいのですが、SNS 投稿の下書きのように「短い答えが欲しい」用途では、頼んでもいないのに 8 段落の総括が返ってくる、ということが普通に起きます。

解決策は単純で、毎回、上限を数値で切ること。Anthropic は公式ガイドの中で「short, focused responses が必要なら明示せよ」と何度も繰り返しています。

このレポートを要約して。

このレポートを要約して。

- 正確に 5 つの箇条書き
- 各箇条書きは 15 語以内
- 各行は動詞で始める（Identify / Compare / Recommend 等）
- 前置きと結びの段落は不要

「正確に N 個」「最大 N 語」「N 段落以内」のような数字を入れると、4.7 はそれを上限として律儀に守ります。逆に「簡潔に」「短く」だけだと、解釈の余地が大きすぎて毎回ブレるので、数字に落とすのが最も歩留まりがいい打ち手です。

user@sinyblog:~/article ❯ 07_imperative.mdルール4：質問ではなく、行動動詞で指示する

意外と多いのが、「〜できますか？」「〜してくれる？」と質問形で頼むパターンです。4.6 までは「はい、やります」と勝手に動いてくれましたが、4.7 では 提案だけで止まることが増えました。Anthropic 公式も同じ問題を取り上げています。

If you say "can you suggest some changes," Claude will sometimes provide suggestions rather than implementing them, even if making changes might be what you intended. For Claude to take action, be more explicit.

Anthropic, Tool usage / [1]

この関数のパフォーマンスを改善する変更を提案してくれる?

この関数を編集して、パフォーマンスを改善せよ。
変更後のコード全体を、変更点コメント付きで返す。

ポイントは 2 つあります。第一に、命令形（〜せよ / 〜して）にすること。第二に、欲しいアウトプットの形を具体的に書くこと（「変更後のコード全体」「変更点コメント付き」）。両方そろえば、4.7 は提案で止まらずに編集まで進みます。

Anthropic はこの挙動をシステムプロンプトでスイッチする方法も提供しています。「提案だけにしてほしい」「いきなり編集するな」という逆の場合は、以下のスニペットをシステムプロンプトに入れると、4.7 は確認をはさんでから動きます^[1]。

<do_not_act_before_instructions>
Do not jump into implementation or change files unless clearly instructed
to make changes. When the user's intent is ambiguous, default to providing
information, doing research, and providing recommendations rather than
taking action. Only proceed with edits, modifications, or implementations
when the user explicitly requests them.
</do_not_act_before_instructions>

user@sinyblog:~/article ❯ 08_tool_use.mdルール5：ツールを呼ぶ頻度が下がったことに気づく

地味ですが影響範囲が大きい変化です。4.6 までの Claude は、検索ツールやファイル読み取りツールを積極的に呼びに行っていました。4.7 は意図的にこの傾向を抑えています。

Claude Opus 4.7 has a tendency to use tools less often than Claude Opus 4.6 and to use reasoning more. This produces better results in most cases.

Anthropic, Tool use triggering / [1]

つまり、4.7 は 「ツールを呼ぶより、まず自分の頭で考える」に倒れています。ほとんどのケースでは品質が上がるので問題ありませんが、エージェント用途で「ちゃんと検索してから答えてほしい」「全ファイルを読んでから答えてほしい」という意図がある場合は、明示的に呼ばせに行く必要があります。

「並列で複数ツールを呼ぶ」挙動は 4.7 の得意分野で、明示的にスイッチを入れると成功率が約 100% まで上がると公式は書いています^[1]。Claude Code を多用する人にとっては地味に効くチューニングです。

user@sinyblog:~/article ❯ 09_tone.mdルール6：トーンが直接的になり、絵文字が減った

「いい質問ですね！」「素晴らしい着眼点です！」のような、共感ファーストの前置きが、4.7 では明確に減りました。絵文字もほぼ消えています。Anthropic はこのトーン変化を意図的なものとして以下のように説明しています。

Claude Opus 4.7 is more direct and opinionated, with less validation-forward phrasing and fewer emoji than Claude Opus 4.6's warmer style. If your product relies on a specific voice, re-evaluate style prompts against the new baseline.

Anthropic, Tone and writing style / [1]

カスタマーサポート Bot、コーチング系プロダクト、学習サービスなど「あえて温かい声が必要」なユースケースでは、明示的にトーンを再定義する必要があります。公式が提示するスニペットは短くて使いやすいです。

Use a warm, collaborative tone. Acknowledge the user's framing
before answering.

逆に、4.6 のトーンが「過剰に丁寧で疲れる」と感じていた人にとっては、4.7 のデフォルトはむしろ歓迎すべき変化です。とくに技術的な相談や、進捗報告系のタスクでは、無駄な前置きが消えるぶん 1 ターンあたりの情報密度が上がります。

user@sinyblog:~/article ❯ 10_go_beyond.mdルール7：クリエイティブには「Go beyond the basics」を添える

これは Anthropic 公式ドキュメントが、Claude 4 系全体に対して繰り返し勧めている「マジックフレーズ」です。具体例を引用します。

Less effective: "Create an analytics dashboard". More effective: "Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation."

Anthropic, Be clear and direct / Migration considerations / [1]

4.7 はランディングページ・ダッシュボード・プレゼン資料・ドキュメント創作などの 開放的（open-ended）なタスクで、何も言わないと「動くけど最低限」のコードを返してきます。これは過剰エンジニアリングを避けようとする方向のチューニング（章 12 参照）の副作用でもあります。

そこに「Go beyond the basics」を 1 行足すと、Claude は「基本ライン」を一段上に引き直してくれます。「クライアントへの最終納品物として磨いて」「実プロダクト品質で」のような言い回しでも同じ効果が出ます。

AI コンサルティングの LP を 1 ファイルの HTML で作って。

セクション:
- ヒーロー（強いコピー 1 文 + サブコピー 1 段落 + CTA）
- 3 つの提供価値カード
- ケーススタディ 2 件
- FAQ 5 項目
- フッター CTA

スタイル:
- editorial、serif の見出し + sans-serif の本文
- 余白を広く取る
- スクロール時に控えめなアニメーション
- 紫グラデーションは使わない

Go beyond the basics. Polish like it's a real client deliverable.

user@sinyblog:~/article ❯ 11_effort.mdeffort パラメータと adaptive thinking — 公式の隠し玉

ここからは、API 経由で 4.7 を使う人向けの追加テクニックです。Anthropic は 4.7 のリリースに合わせて、API パラメータも整理しました。中心にあるのが effort と adaptive thinking の組み合わせです。

effort は low / medium / high / xhigh / max の 5 段階。4.7 のとくに重要な特徴は、「低い effort では本当に最低限しかやらない」こと。公式の言葉を引きます。

At low and medium, the model scopes its work to what was asked rather than going above and beyond. This is good for latency and cost, but on moderately complex tasks running at low effort there is some risk of under-thinking.

Anthropic, Calibrating effort and thinking depth / [1]

もうひとつの隠し玉が adaptive thinking。これは「考えるべきときだけ深く考える」モードで、thinking: {type: "adaptive"} と指定するだけで有効になります。従来の budget_tokens ベースの extended thinking は非推奨になりました^[1]。

client.messages.create(
    model="claude-opus-4-7",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "xhigh"},
    messages=[{"role": "user", "content": "..."}],
)

user@sinyblog:~/article ❯ 12_minimal.md過剰エンジニアリングを止める「最小限の原則」

4.7 は「気を利かせない」とはいえ、コーディング用途では逆に 頼んでいない抽象化・防御的コード・将来拡張用の余地を勝手に作る癖が残っています。Anthropic 公式はこれを overeagerness（やりすぎ）と呼び、抑止する system prompt を例示しています。本記事のように Claude Code を運用するなら、必ず Stub として持っておきたいスニペットです。

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.

- Documentation: Don't add docstrings, comments, or type annotations
  to code you didn't change. Only add comments where the logic isn't
  self-evident.

- Defensive coding: Don't add error handling, fallbacks, or validation
  for scenarios that can't happen. Trust internal code and framework
  guarantees. Only validate at system boundaries (user input, external
  APIs).

- 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.

これを CLAUDE.md やシステムプロンプトに常設しておくと、「バグ修正だけ頼んだのに、関係ない部分まで“ついでに”書き直されていた」という事故が激減します。とくに既存コードベースに対する保守的な編集を任せたい場合、効果は段違いです。

user@sinyblog:~/article ❯ 13_checklist.md4.6 → 4.7 移行チェックリスト（DO / DON'T）

本記事で扱った内容を、日々のプロンプト見直しに使える形に圧縮しておきます。手元のプロンプトを 1 つずつ通して、ボトルネックを潰すための運用用チェックリストです。

user@sinyblog:~/article ❯ 14_summary.mdまとめ：プロンプト品質 ≠ プロンプト長

本記事を通して伝えたかったのは、Ruben 氏が記事の末尾に書いた 1 行に集約されます。

The goal is precision — not verbosity. A short, precise prompt outperforms a long, vague one every time.

Ruben, Prompt 4.7 / [2]

4.7 用のプロンプトを書き直すと、最初は「指示が増えて長くなった」と感じます。しかし、よく見ると 長くなったのではなく、もともと書くべきだったことを言葉に落としているだけです。スコープ・長さ・形式・スコープ外条件——これらはいつも頭の中にあったのに、4.6 までは Claude が読み取ってくれていただけでした。4.7 はその仕事を肩代わりしてくれなくなった代わりに、書いたことを文字通り正確に返してくれます。

最後に、本記事の要点を 3 行に圧縮します。

1. 4.7 は指示を文字通り読む。書いていないことは推測しない。だから「スコープ・長さ・形式・スコープ外」を必ず言葉にする。
2. 禁止より期待を書く。「使うな」を「こう書け」に置き換える。否定形は背景説明とセットでのみ効く。
3. effort と adaptive thinking を使う。プロンプトで頑張る前に、まず API パラメータ側で深さを揃える。

同じプロンプトを Claude 4.7 に投げて「以前より弱くなった」と感じたら、それは Claude のせいではなく、自分のプロンプトが 4.6 用の文法のまま止まっているだけ——というのが本記事の結論です。週末を 1 回投資して、よく使うテンプレートだけでも上書きしておくと、来週からの作業効率は明確に上がります。