はじめに

2026年7月、Claudeのラインナップが大きく進化しました。
7/20にClaude Fable 5が有料プラン「Max」「Team Premium」の標準機能になり、7/24にはOpusが4.8から5へアップデートされました。

Fable 5とOpus 5が標準的に使えるようになったことで、私たちはこの強力なモデルの「正しい扱い方」を改めて考える必要が出てきました。
そのヒントを探す中で、Anthropic社員によるカンファレンス講演（AIE2026）と、公式ドキュメントのモデル別プロンプティングページにたどり着きました。

講演と2つのドキュメントには、一貫したメッセージがありました。
それは 「プロンプトは書き足すものではなく、削るものになった」 ということです。

これまで私たちは、「回答を再確認して」「検証ステップを含めて」「〜はしないで」のようにモデルの間違いを防ぐために指示を追加してきました。
しかしClaude 5世代では、これらの指示の多くが公式に「削除せよ」と明記されるようになりました。
そのため旧モデル向けに育ててきたプロンプトが、そのまま逆効果になるケースがあります。

本記事ではこのメッセージを「なぜ削るのか（思想）→ 何を削るのか → 削った代わりに何を書くのか」の順で整理していきます。

対象の読者

  • 旧モデル（Opus 4.8以前やSonnetなど）向けに作ったプロンプト・スキルを持っている方
  • Claude Fable 5とOpus 5をどう使い分けるか知りたい方

結論

  1. 制約・Few-shot・検証指示を「削る」ことが公式推奨になった
    モデルが自発的にやることを指示で重複させると、品質は上がらずコストだけ増えます
  2. 代わりに書くのは「背景（Why）」「境界」「Unknownの穴埋め」
    細かい振る舞いの列挙から、判断材料と判断の境界線を渡す方向へシフトします
  3. Fable 5とOpus 5とで調整方向が逆の項目すらある
    代表例がサブエージェント委任。Fable 5は「活かす」設計が、Opus5は「抑える」指示が必要です

なぜ削るのか

Thariqは、モデルには今までのプロンプトではまだ引き出せていない能力の余剰＝ Capability Overhang があると言っています。
そしてFable 5では、この余剰をどう見極めるかが課題になるとしています。

講演では「名前が “AW” で終わるポケモンは？」という例が挙げられました。
以前のチャットモデルに聞くと、全ポケモンを知識として持っているのに失敗していました。
しかしClaude Codeに聞くと、スクリプトを書いてリストを取得・フィルタし、数秒で正解を出すことができました。
プロンプトを磨くのではなく手足（ツール）を与えたことで、眠っていた能力が引き出された例です。

他にも2026年4月、AnthropicはFableの姉妹モデルであるMythos Previewが、OpenBSDに1998年から27年間潜んでいた脆弱性を発見したと報告しました。(※1)
その時与えたのはプロンプト1行だけで、作り込んだのはプロンプトではなく、隔離環境とツールの側でした。

講演でThariqはこう語っています。

What contains them is us. The harness we put them in and the way we prompt them is basically a function of our understanding of Claude.

（モデルを閉じ込めているのは私たち自身です。与えるハーネスもプロンプトの書き方も、結局は私たちがClaudeをどれだけ理解しているかの関数に過ぎません。）

つまりハーネスや指示・制約は、書いた人のClaude理解の写しでしかなく、その枠組みの内側にしか性能は出てこないということです。
そのため細かい指示や制約は、モデルの能力を狭めてしまう可能性があります。

この考え方は、Anthropic自身のプロンプト設計にも表れています。
Claude Codeのシステムプロンプトは、世代ごとに真逆の方向へ振れてきました。

  • Sonnet 3.5世代: システムプロンプト小・ツール少・出力例多
  • Opus 4世代: システムプロンプト大・ツール多・指示をどんどん追加
  • Fable世代: システムプロンプトを80%削減。出力例はモデルの想像力を制約するため撤去

「賢くなったモデルには、より多くの指示を」という直感は、Fable 5以降で逆転しました。

何を削るのか

講演と公式ドキュメントによると削るべきものは、Fable 5とOpus 5で異なります。

Fable 5: 規範的すぎるスキル・Few-shot・禁止事項

Fable 5のドキュメントでは、旧モデル向けに開発したスキルの見直しが推奨されています。

以前のモデル向けに開発されたスキルは、Claude Fable 5にとって規範的すぎることが多く、出力品質を低下させる可能性があります。
デフォルトのパフォーマンスの方が優れている場合は、古い指示を見直し、削除を検討してください。

講演でも、Few-shot（出力例）と「〜するな」という禁止事項のリストは、Claude Codeのシステムプロンプト削減の際に撤去されたと語られています。
出力例はモデルの想像力を制約し、禁止事項の列挙は旧モデルにこそ必要だったものだからです。

Opus 5: 検証・再確認の指示

公式のプロンプトページによると、Opus5は指示されなくても自身の作業を検証します。

プロンプトに明示的な検証指示（「自明でないタスクには最終検証ステップを含める」「サブエージェントを使用して検証する」）が含まれている場合は、削除してください。

「答えを再確認して」「応答前に再検証して」も同様に、モデル自身の動作と重複してコストを増やすだけなので、これも削除の対象です。

代わりに何を書くのか

背景（Why）を伝える

制約ではなく、背景を伝える。
これが代わりに書くものの中で、最も意識すべき点です。

Fable 5は、リクエストの背後にある意図を理解しているときに、より良いパフォーマンスを発揮する傾向があります。
背景がなければ、Fable 5は指定されなかった箇所の意図を独自に推測して進めますが、
背景があれば、推測の代わりにタスクを関連情報へ結び付けて判断できます。
禁止事項が「してはいけないこと」を狭く塞ぐだけなのに対し、背景は無数の細かい判断のベクトルをそろえるものとして作用します。

公式が挙げるテンプレートは次の形です。

I'm working on [the larger task] for [who it's for]. They need [what the output enables]. With that in mind: [request].
（私は現在、[誰・ターゲット層] のために [プロジェクトや業務の全体像] に取り組んでいます。
彼らは [このアウトプットによって何ができるようになるか・どのような目的を果たすか] を必要としています。）
その点を踏まえた上で、以下の対応をお願いします：[具体的な依頼内容]。

たとえば「CSVエクスポート機能を追加して」とだけ頼む代わりに、「経理チームが月次で会計ソフトに取り込むためのCSVエクスポート機能を追加して」と書きます。
誰が何のために使うかが伝われば、文字コードや列の並びといった指定しなかった細部まで、用途に合わせて判断してくれます。

ユーザー自身の「未知の領域」を見つける

Fable 5の最大の特徴は自律性です。
つまりプロンプトで指定しなかった箇所で、Fable 5自身が意思決定を行う場面が劇的に増えます。
そのため私たち自身が「自分の分かっていないこと」を把握し、プロンプトで穴を埋める必要があります。

講演では、その「未知の領域(=Unknown)」を以下のマトリクスで整理することが推奨されています。

Known（自覚あり） Unknown（自覚なし）
Known
（知っている）		 Known Knowns
プロンプトに書くもの		 Known Unknowns
まだ未解決と知ってるもの
Unknown
（知らない）		 Unknown Knowns
言葉にしてない暗黙知や好み		 Unknown Unknowns
考慮してない、プロンプトの前提を変える要素

そして未知の発見にも、Fable 5自身を使って探します。
講演で語られた「未知の領域」の整理をするテクニックのいくつかを抜粋します。

  1. 死角のチェック（Blind spot pass） → Unknown Unknowns
    新しい技術を触る際などに「私が考慮できていない未知の未知を洗い出して」と依頼する
  2. AIにインタビューさせる → Known Unknowns
    「この実装にあたり、私が決めておくべきことを逆質問して」と頼み、対話形式で仕様を詰める
    「アーキテクチャを変えるような質問を優先して」と添えるとより効果的です
  3. プロトタイプの生成 → Unknown Knowns
    デザインの好みなど言葉にしづらい暗黙知を引き出すため、「全く違う4パターンのUIを作って」と頼み、自分の反応から正解を導く

Fable 5とOpus 5の違い

同じClaude 5世代でも、2つのドキュメントを比較すると調整方向が異なります。

Fable 5のガイドは長期自律実行のための環境を与える、「活かす」方向の調整で、
Opus 5のガイドは過剰な行動を抑える、「抑える」方向の調整が中心となっています。

特に検証とサブエージェントの扱いが逆方向となっており、
Fableでは使用を推奨していますが、Opusでは検証指示は削除、サブエージェントは上限の設定を勧めています。

観点 Fable 5 Opus 5
検証 長時間タスクでは独立した検証サブエージェントを明示的に指示 指示なしで自己検証する。検証指示は削除
サブエージェント 並列ディスパッチが強み。非同期で活かす 委任が積極的すぎる。上限を設ける
既存プロンプト資産の調整 従来のskillだと指示が細かい場合あり 従来のプロンプトと互換性あり
応答の長さ 高effortで過剰に詳述しがち。簡潔さ＋読みやすさの指示で制御 デフォルトで長い。簡潔さの指示で制御

おわりに

講演の後半でThariqは、コーディングが簡単になったことへの喪失感（Grief）はあるが、それでも「通り抜ける（Through）」しかないことを語っています。
そして最後は「品質・コスト・デリバリーのトレードオフを疑い、非合理（Unreasonable）になれ」というマインドセットで講演を締めくくります。
AIによってQCDのトレードオフを打破でき、より大きな価値を生み出すことができるというメッセージでした。
プロンプトを削るという技術論の先にあるのは、モデルを信頼して、これまで諦めていた規模の仕事に挑むという話なのだと思います。

興味のある方はぜひ講演全編を視聴してみてください。

参考

※1 Assessing Claude Mythos Preview’s cybersecurity capabilities（Anthropic公式）