Claude Opus 4.7で変えるべきはモデル名ではなく使い方｜中の人が公言した3ワークフローシフトの非エンジニア実装例

2026年4月16日、
AnthropicがClaude Opus 4.7を公開しました。
SWE-bench Verified 87.6%、
画像解像度の大幅拡張、
xhigh推論モードの追加。
数字だけ追えば「強化版」です。
ただ、
私が3日ガッツリ触って分かったのは、
Opus 4.7で本当に変えるべきはモデル名じゃなくて使い方の方だった、
ということ。
ここが今回の本題。

Claude CodeのPM（Cat Wu氏）とエンジニア（Boris Cherny氏）は、
リリース当日のX投稿で露骨にこう言ってます。
「ペアプロ的に1行ずつ指示するな、
委任するエンジニアとして扱え」。
つまり4.6までの使い方をそのまま持ち込むと、
性能の半分も引き出せない。
私自身、
最初の半日は完全にこの罠にハマりました。

この記事は、
Cat WuとBoris Chernyが公言した「3ワークフローシフト」を、
エンジニアじゃない人の日常業務（記事執筆・リサーチ・資料作成）に翻訳して、
一次体験で裏付ける速報記事です。
スペック列挙はしません。
そこは他社記事に任せる。

Claude Opus 4.7とは何が変わったのか

Opus 4.7は2026年4月16日に公開された、
Anthropicの一般向け最上位モデルです。
Claude.ai（Web）、
API、
Bedrock、
Vertex AI、
Microsoft Foundry、
Snowflake Cortexから利用可能。
料金は入力$5／出力$25（100万トークンあたり）で、
Opus 4.6から据え置きです。
コンテキストは1Mトークン、
最大出力は128kトークン。

数字で見た変化は以下の通り。
ただし後で触れますが、
全部が上がったわけじゃないのがポイント。
ここを隠す記事が多いので、
私は正直に出します。

MRCRの後退は本当にデカい。
長文読解はむしろ弱くなった。
ここ、
あとで「注意点と限界」で改めて掘ります。

なぜ使い方を変える必要があるのか

Cat Wu氏（Anthropic、
Head of Product for Claude Code）はリリース当日にこうポストしてます。

Opus 4.7 is live in Claude Code today! The model performs best if you treat it like an engineer you're delegating to, not a pair programmer you're guiding line by line. Here are three workflow shifts we recommend for this model 🧵

— Cat Wu（X投稿 2026-04-16）

訳すと「1行ずつガイドするペアプログラマーじゃなくて、
タスクを委任するエンジニアとして扱え」。
この一文がすべて。
Claude Code創設者のBoris Cherny氏も同日、
別スレッドで「4.7はより自律的で、
より精密で、
長時間タスクがずっと得意になった。
セッション跨ぎで文脈を持ち越し、
曖昧な指示もずっと上手く処理する」と書いてます（Boris Cherny X投稿 2026-04-16）。

正直、
この「自律性」を信じて投げられるかどうかで体感が2倍違う。
私は最初、
4.6の癖で「まず設計だけ見せて」「コメントだけ先に書いて」と段階チェックを挟んでました。
結果、
途中で方針が揺れて手戻りばっかり発生。
信じて投げた方が速い。
これが今回の記事を書こうと思った直接の理由です。

3つのワークフローシフトとは？

Cat Wu氏が同スレッドで挙げた3シフトを、
非エンジニア向けに翻訳します。
原文はClaude Code（エンジニア向けCLI）前提ですが、
Claude.ai（ブラウザ）で記事執筆やリサーチをしている人にもそのまま効く話です。

シフト1：ペアプロ型から委任型へ

1行ずつ指示を出す「ペアプロ型」をやめて、
タスク全体を渡す「委任型」に切り替える。
4.6までの癖で一番残ってるのがこれ。
私も最初はやってました。

具体例。記事執筆の場合、昔はこう投げてました。

「まずAIツール比較記事の構成を見せて」→（確認）→「じゃあ導入書いて」→（確認）→「次は比較表」→（確認）→…

4.7ではこれが逆効果。
中間確認でモデルのリズムが切れる。
いま私はこう投げてます。

「AIツール比較記事を2,000字で書いて。
構成は導入・比較表・使い方・まとめ。
トーンは一人称『私』ベースで実体験混ぜる。
避ける表現は『いかがでしたか』『ご紹介します』。
対象ツールは○○と△△、
評価軸は料金・使い勝手・拡張性の3つ」

ゴールと制約を最初のターンに全部込みで投げる。
これが効きます。
1発で8割くらい完成品が出てくる。
ここの差、
でかい。

シフト2：ゴール・制約・受け入れ条件を最初に全部入れる

Cat Wu氏の原文は「Put full goal + constraints + acceptance criteria up front」。
和訳すると「ゴール・制約・受け入れ条件を最初に全部入れろ」。

リサーチタスクでやってみた例を書きます。
私が先週、
AI関連SaaSの比較リサーチを投げた時のプロンプトはこんな感じ。

• ゴール: 日本市場で使える動画生成AI 5社の月額・機能・法人導入事例を表にまとめる
• 制約: 価格は2026年4月時点。出典URLは各行に明記。日本語公式サイトがあるものを優先
• 受け入れ条件: thead/tbody構造のHTMLテーブル。各社1行以上。事例が見つからない場合は「情報なし」と正直に書く

これを1発で投げて、
昼休み明けに表が1本上がってた。
AIの仕事速度、
完全に変わりました。
中間確認しない勇気、
大事。

シフト3：検証方法を事前に教える

3つ目のシフトはCat Wu氏が「Tell the model how to verify its changes. Put your testing workflow in your claude.md, or add a /verify-app skill. Opus 4.7 is better at verifying its work」と言ってる部分です（X投稿 2026-04-16）。

エンジニア向けには「テストワークフローをclaude.mdに書いとけ」ですが、
非エンジニアにはこう翻訳できます。
「完成の合格基準を事前に渡しておけ」。
これだけ。

記事執筆で私がやってる合格基準の例。

• 文字数は±10%以内
• h2見出しは質問文にする
• FAQは3問以上
• 「いかがでしたか」「〜が可能です」は使わない
• 出典URLは各引用に必ず付ける

これを指示に含めると、
4.7はそれ自身で最後に「ここ違反してないか」をチェックしてから返してきます。
4.6の時より自己検証がしっかり効く。
これ、
地味だけど一番革命。

非エンジニアが使う具体シーン（記事執筆・リサーチ・資料作成）

記事執筆：全部込みプロンプトで1発発注

私はいま、
記事1本を3ターン以内で仕上げることを目標にしてます。
初回に全制約を投げ、
2回目で軽微な修正、
3回目で最終整形。
4.6では5〜7ターン必要だったのが半分以下。
時間効率で言うと、
1本あたり40分が15分になりました。

ポイントは「最初に全部入れる勇気」。
怖いんですよ、
情報詰めすぎると発散するんじゃないかって。
でも4.7は逆で、
情報が濃いほど安定します。
タスク複雑度に応じて応答長を自動調整する設計になっているらしい（公式docs記載）。

リサーチ：朝投げて昼回収

並行リサーチが化けました。
私は朝9時に3タスクを別ウィンドウで同時投入するようにしてます。
内訳は「SaaS比較」「業界ニュースまとめ」「競合記事の分析」みたいな独立タスク。
昼休み明けに3つ揃ってる。

この使い方、
Boris Cherny氏も「run 5 to 10 claudes in parallel」と推奨してます。
1ウィンドウに集中して逐次処理する癖、
もう古い。
並列化しないと4.7の恩恵は半分しか出ない。

資料作成：高解像度スクショをそのまま渡す

画像解像度が上がった恩恵、
一番出てるのが資料作成です。
画像の最大解像度は長辺2,576px／3.75MPに拡張されました（4.6は長辺1,568px／1.15MP）。
面積比で約3倍、
ピクセル長辺比で約1.6倍。
この差がUI分析で効きます。

私はいま、
Figmaの画面を高解像度でキャプチャしてそのまま投げてます。
4.6だと縮小されてテキストが潰れてたのが、
4.7では細部まで読める。
座標もピクセル1:1対応になったので、
「左上から300pxの位置のボタン」みたいな指示が通る。
スライドレイアウトの自己チェック精度も向上したと公式docsには書いてあります。

Tom's GuideのAmanda Caswell氏は「キッチン画像を分析して設計提案3点を出した」と報告してます（Tom's Guide）。
画像→提案のフローが現実的な速度で回る。

やめるべき旧習慣は？

4.6までの使い方で、
4.7では逆効果になる習慣を5つ挙げます。
私自身、
最初の半日で全部やらかしました。

特に「中間チェック癖」は、
真面目に仕事する人ほど抜けにくい。
私も「ちゃんと確認しながら進める方が安全」と思ってた。
4.7ではそれが邪魔になる。
ここは意識して捨てる必要があります。

Boris Chernyが発信した5つのコツは？

Boris Cherny氏はリリース当日、
Claude Code向けのコツを複数発信しています。
詳細項目はpasqualepillitteri記事（出典）経由での要約になるので、
X原文の完全な照合までは私もできていません。
ここは正直に明示しときます。

要旨レベルで言えるのは、
ポイントは「委任・詳細プラン・中間確認を減らす方向」で一貫しているということ。
具体的には、
Max以上ユーザー向けのAuto mode拡張、
事前承認スキルによる権限プロンプト削減、
長会話のセッションサマリー、
中間作業非表示の/focusコマンド、
adaptive thinking（low/high/xhigh/max）の使い分け、
といった5項目が列挙されています。
Boris氏自身は「ほとんどのタスクでxhigh、
最難問でmax」と明言。

個別発言の断定引用は避けますが、
方向性は「モデルを信じて任せ、
人間の確認コストを減らす」の一点で揃っている。
これは押さえる価値がある。

注意点と限界（正直なデメリット）

長文読解は後退した

一番大事な注意点はこれ。
MRCR（長文コンテキスト理解）が78.3%→32.2%、
-46.1pt後退しています（apiyi.com実測）。
「800行のワークフロー文書を読ませると、
読んだと言いながら内容と無関係な出力を返す」という報告もある。

Boris Cherny氏は「MRCRはdistractor-stackingトリックを過大評価する指標で、
GraphWalksの方が実応用に近い（38.7%→58.6%に向上）」と反論してます。
ただ、
長文Q&Aや長文読解がメイン用途の人は、
4.7を無条件で推奨できません。
コードや実作業の委任では上がったが、
長文読解では下がった。
この使い分けは必須。

私の判断は明確。
記事執筆・リサーチ・コード書きは4.7、
長文PDFをまるっと要約させるなら4.6残し。
用途で分ける。

トークン消費は増える

新トークナイザーで同じ入力が最大1.35倍のトークン数になります。
コードや構造化データで特に高め。
Boris Cherny氏自身が「4.7 thinks more, so token use runs higher than 4.6」と明言（X投稿）。

Decryptの実測レビューでは「1セッションでトークンクォータを全て使い切った」という報告もある（Decrypt）。
dnyuzは記事タイトルに「Token Eating Machine」と書いてます。
Reddit上では「3つの質問でusage limitに到達」というProユーザーの投稿も。

対応としてAnthropicは全サブスクライバーのrate limitを引き上げました（Boris Cherny氏のThreads投稿で発表）。
ただ、
Proプランで重い使い方をすると依然として枯れます。
私の体感だと、
Max（月$100〜）以上じゃないとガチ運用は厳しい。
正直ここがネック。

APIの破壊的変更

extended thinking budget（固定budget_tokens）はOpus 4.7で廃止。
そのまま投げると400エラーになります。
adaptive thinkingへの移行が必要です。
temperature・top_p・top_kも非デフォルト値を設定すると400エラー。
APIユーザーは移行時に注意。

結局、Opus 4.7は使うべきか

私の結論。
Claude Code / 記事執筆 / リサーチ / 資料作成が主用途なら即切り替え、
長文PDF読解がメインなら4.6残し、
ライトユーザーはProじゃ枯れるのでMax検討。
これに尽きます。

ただ一番強く言いたいのは、
冒頭の繰り返しになりますが、
変えるべきはモデル名じゃなくて使い方ということ。
4.7に切り替えただけで4.6のプロンプトを流用しても、
体感は「ちょっと良くなった」程度で終わる。
ワークフローを3シフトさせて初めて、
数字通りの飛躍が出てきます。

「任せる勇気」が要ります。
AIに投げて事故った経験がある人ほど、
細かく確認したくなる。
その気持ちも分かる。
ただ4.7に関しては、
その癖を一旦置いて「ゴール・制約・合格基準を全部最初に渡して、
あとは任せる」という投げ方に切り替えた方が速いし精度も出る。
私はもう戻れないです。

FAQ

Q1. Opus 4.7はOpus 4.6の完全上位互換ですか？

いいえ。
SWE-benchや画像認識は大幅に向上しましたが、
MRCR（長文読解）は78.3%→32.2%と46.1pt後退しています。
長文PDFの読解が主用途なら4.6を残した方が無難です。

Q2. Claude Proプランで使えますか？

使えますが、
トークン消費が4.6より1〜1.35倍に増えているため、
ガチ運用だとusage limitに早く到達します。
Redditでは「3つの質問で枯れた」という報告もあり。
本格的に使うならMax（月$100〜）以上を検討した方がいいです。

Q3. 料金は上がりましたか？

入力$5／出力$25（100万トークンあたり）で据え置きです。
ただしトークナイザーが変わって同じ入力でもトークン数が増えるため、
実効コストは上がる可能性があります。
プロンプトキャッシュやバッチ処理で50〜90%のコスト削減が可能なので、
APIユーザーはここで調整します。

Q4. Mythosって何ですか？

Opus 4.7より上位のセキュリティ特定顧客向けモデルですが限定公開で、
一般ユーザーは触れません。
一般向けの最上位はOpus 4.7です。
Mythosは一般記事では深追い不要です。

Q5. xhighとmax、どっちを使えばいいですか？

Boris Cherny氏は「ほとんどのタスクでxhigh、
最難問でmax」と明言しています。
公式docsも「maxは長時間タスクで過剰思考しやすい」と警告しているので、
デフォルトはxhighで、
詰まった時だけmaxに切り替えるのが推奨です。

Q6. 4.6のプロンプトをそのまま使えますか？

使えますが、
性能は引き出せません。
Anthropic公式が「プロンプトとハーネスの再チューニングが必要」と明言しています。
特に「先に構成を見せて」「1行ずつ確認しながら」系の中間チェック型プロンプトは、
4.7では逆効果になります。

関連リンク

• Anthropic公式発表：Claude Opus 4.7
• 公式API docs：What's New in Opus 4.7
• 公式ベストプラクティス（Claude Code向け）
• Cat Wu氏 X投稿（3ワークフローシフト冒頭）
• Boris Cherny氏 X投稿（4.7リリース所感）
• Boris Cherny氏 Threads（rate limit引き上げ）
• Decrypt：Token Eating Machine（実測レビュー）
• Tom's Guide：Amanda Caswell氏の実テストレビュー
• apiyi.com：4.6 vs 4.7実測8指標比較

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