Claude Fable 5.1プロンプト設計ガイド

Claude Fable 5.1プロンプト設計ガイド

こんにちは、makokonです。
皆さん、Claude Fabel 5.1を使っていますか？
流石に、makokonの読者だと、普段使いする人はそんなにいないとは思います。この出たばかりのfabel5.1ですが、やっぱりちょっとした挙動が気に入らない、気になる人は多いようです。というわけで、anthropic公式は、早速fable5.1のささやかな挙動の変化をプロンプト設計の立場から紹介するドキュメントが出ていました。
内容は多岐にわかりますが、特に文章がくどいと感じる人が多いようで、その部分だけ取り上げて記事を書いている人もいます。そのへんの情報を少し整理してみます。
提示されるプロンプトは、なるべく日本語化して解説しています。
このプロンプト設計は、gpt-5.6solとかで効果的だったというＸ投稿もちらほら見たので、役に立つ人も多いかもしれませんよ。
公式ページ

文章の密度に関するまとめ記事（公式ではありません）

公式ページの扱っている内容

今回の公式ページは、Claude Fable 5.1をAPIやエージェントとして運用する際に起こりやすい挙動の変化を、次のような問題別に整理した実践ガイドです。

• 推論量・コスト・速度の調整

• 作業中の進捗表示

• 複数ツールの並列呼び出し

• 会話履歴の保持

• 文章の長さ・密度

• チャットのMarkdown整形

• 検索結果や取得文書の引用

• タスクを最後まで完了させる指示

• 長い会話の要約

• コーディング時の変更範囲とテスト範囲

• 低い推論量での検索不足

• 安全機構による誤拒否

• ファイルの部分編集

• 長文出力

• サブエージェント

• 画像の拡大・切り抜き

そして、公式でないまとめ記事はこの公式ページの一部を扱った「文章作成編」と位置づけるのが正確です。

2. この公式ページの読み方

このページは、単に「こういうプロンプトを書けば性能が上がる」という形式ではありません。まんべんなく利用するようなテンプレートではなく、直面している問題に合わせて利用する手引きです。

基本的には、次の手順で読むべきページです。

1. Claude Fable 5.1で困っている症状を確認する

2. その症状に対応する節を探す

3. プロンプトだけで解決できる問題か、API実装を直すべき問題かを判別する

4. 公式の指示文を追加する

5. 自分のタスクで品質・速度・コストを評価する

重要なのは、すべての問題を長いシステムプロンプトで解決しようとしないことです。

例えば、

• 検索しない問題
  → プロンプトまたはeffort設定の問題

• 会話履歴を改変するとエラーになる問題
  → API実装の問題

• 長時間作業中にユーザーへ何も表示されない問題
  → APIの進捗ブロック表示とプロンプトの両方の問題

• ファイル全体を書き換える問題
  → 編集方針をプロンプトで指定する問題

というように、原因が異なります。

3. 最初に確認すべき「effort」の考え方

effortとは

effortは、Claudeにどの程度の推論・処理量を使わせるかを調整する設定です。

公式ページでは、まず `high` を基準にし、その後、自分の評価データで次の設定を比較することが推奨されています。

• `low`

• `medium`

• `high`

• `xhigh`

• `max`

使い分け

low

• 速度とコストを重視

• 単純な変換、分類、短い回答

• ただし検索や外部情報の取得が減る可能性がある

medium

• 品質とコストのバランス

• 一般的な業務処理

• Fable 5.1の性能を比較的低いコストで使いたい場合

high

• 通常の基準設定

• 複雑な分析、コード、調査、長めの作業

• まずここから評価する

xhigh / max

• 難しい推論や複雑なエージェント作業

• ただし長文を同時に出させると、処理時間やトークン使用量が増えやすい

実務上のポイント

「常にmaxが最良」と考えないことが重要です。

タスクごとに、次の4項目を比較してください。

• 正確性

• 完了率

• 応答時間

• コスト

簡単な作業に高いeffortを使うと、品質がほとんど変わらないのに、速度と費用だけ悪化することがあります。

4. 作業中の進捗を表示させる

起こりやすい問題

Claude Fable 5.1は、長いツール処理や高いeffort設定で作業すると、ユーザー向けの途中経過をあまり表示しないことがあります。

そのため、ユーザーから見ると、

• 数分間何も表示されない

• 最後に直近の処理だけが報告される

• 何を調べ、何を実行したのか分からない

という状態になる場合があります。

日本語化したプロンプト

作業を開始する前に、これから何を行うかを一行で説明してください。

作業中は、ユーザーが進行状況を把握できるように、短い進捗報告を適宜表示してください。

最後には、次の3点を含む簡潔なまとめを出してください。

- 何が分かったか
- 何を実行したか
- 次に必要なことは何か

最後のまとめだけを読んでも、作業全体の結果が分かるようにしてください。

さらに必要なAPI設定

プロンプトを書くだけでなく、クライアント側で進捗用のthinkingブロックを表示する設定が必要です。

公式ドキュメントでは、進捗表示用の設定として次のような方式が説明されています。

• `thinking.display: "updates"`

• `thinking.display: "summarized"`

また、既存のシステムプロンプトに、

「調査結果は最後まで保留し、途中では何も説明しない」

のような指示がある場合、それを削除する必要があります。

効果

• 長時間処理でもユーザーが不安になりにくい

• エージェントの作業内容を確認しやすい

• 最終回答が途中の処理だけを報告する問題を減らせる

```text
ツールの実行結果はユーザーには表示されません。
ユーザーが内容を読む必要がある場合は、ツールの出力をあなたの返答内に要約または引用してください。

5. 独立したツール呼び出しをまとめる

起こりやすい問題

複数のファイルを読む、複数の情報源を検索する、といった処理では、本来同時に実行できるツール呼び出しが、一つずつ順番に実行されることがあります。

結果として、

• API呼び出し回数が増える

• 往復時間が長くなる

• トークンを余計に消費する

という問題が起こります。

日本語化したプロンプト

次に必要な情報やツールを内部で整理してください。

他の結果に依存しない処理は、可能な限り一つの応答内でまとめて要求してください。

ある処理の結果を待つ必要があるものだけ、後続の呼び出しに分けてください。

効果

例えば、

• READMEと設定ファイルを読む

• 複数のURLを取得する

• 複数の独立したテストを実行する

といった場合に、並列化されやすくなります。

ただし、後続処理が前の結果に依存する場合まで無理に並列化してはいけません。

6. 会話履歴は「追記のみ」にする

これはプロンプトではなく、API実装上の重要事項

Claude Fable 5.1では、過去のassistantメッセージ、特にthinkingブロックを、後から書き換えたり削除したりすると問題になる場合があります。

基本原則は次のとおりです。

• 返ってきたassistantターンを、そのまま履歴に追加する

• 過去のメッセージを書き換えない

• 過去のthinkingブロックを編集しない

• system promptやtools定義を途中で直接書き換えない

• 途中の指示変更には、追加のsystemメッセージなどを使う

公式ページでは、2026年8月31日以降に作成されたアカウントでは、thinkingブロックが元の会話と厳密に結び付く場合があると説明されています。

会話を短くしたい場合

クライアント側で履歴を圧縮する場合は、古い履歴を一部だけ書き換えるのではなく、

1. 会話全体を要約する

2. 要約メッセージを新しい履歴の先頭に置く

3. 新しいユーザー入力を追加する

4. 過去のthinkingブロックは再利用しない

という形が安全です。

効果

• 400エラーを防ぎやすい

• プロンプトキャッシュの無効化を抑えられる

• 会話履歴の整合性を保てる

7. 文章が長く、密度が高くなる問題

非公式資料との関係

非公式資料の「気取った文章を削除するプロンプト」は、公式ページのこの節を実践的に展開したものです。（この問題は、OPUSや、gpt-5.6など他の高性能ＬＬＭを使っても気になるところだと思います。Ｘ上では、別のＬＬＭに対しても効果があったということなので、必要な補足を付録でもしたいと思います。）

公式ページでは、この問題を「mannered prose」と呼んでいます。

これは単に文章が長いという意味ではありません。

• 直接言えば済むことを比喩で表現する

• 書き手の技巧を目立たせる

• 読者に余計な解釈を要求する

• 情報よりも雰囲気を優先する

• 一文が長く、段落の切れ目が少ない

といった文章を指します。

公式内容を日本語化した実用プロンプト

気取った文章や装飾過多な文章を避けてください。

気取った文章とは、直接的に表現できる内容を、比喩や言葉の飾りで表現する文章です。

例えば、

- 「変更する価値のあるパラメータ」を「回す価値のあるダイヤル」と書く
- 「この点は今も重要だ」を「この点は今も役割を果たしている」と書く

といった表現です。

このような表現は、情報を増やすよりも、書き手の技巧を目立たせることがあります。また、比喩は、書き手が意図していない連想やニュアンスを読み手に与えることがあります。

文字どおりに意味を伝えられる場合は、比喩を使わず、具体的で直接的な表現を使ってください。

ただし、必要な情報まで削らないでください。文章を機械的に短くするのではなく、各文が読者に有用な情報を追加しているかを確認してください。

短縮版

気取った文章や不要な装飾表現を削除し、意味を直接的かつ具体的に伝えてください。

日本語で使う場合の改良版（資料にはないけど）

日本語では、すべての比喩や慣用表現を削除すると不自然になります。

そのため、実務では次の版を推奨します。

意味を明確にするために必要な慣用表現や比喩は残してください。

ただし、情報を追加せず、文章を印象的に見せるだけの比喩、擬人化、誇張表現は、具体的で直接的な表現に置き換えてください。

文章の明確さを優先しますが、顧客向け文章に必要な丁寧さや自然な温かさは維持してください。

効果

• 抽象的な表現が減る

• 一文の意味を理解しやすくなる

• 製品説明や業務連絡が具体的になる

• 書き手の「うまく見せようとする癖」が抑えられる

• 情報伝達を目的とする文章に向く

注意点

この指示を広告コピー、詩、ブランドメッセージ、スピーチにそのまま適用すると、表現が平板になることがあります。

文章の目的ごとに使い分けてください。

• 仕様書、FAQ、マニュアル
  → 強く適用する

• 顧客への通知
  → 明確さを優先しつつ、丁寧さは残す

• 広告、コピー、物語
  → 不要な比喩だけ削除する

• 論文、契約書、医療・金融文書
  → 比喩だけでなく、曖昧さや未確認の断定も削除する

8. チャットでのMarkdown整形

Fable 5.1の傾向

以前のモデルは、必要以上に次の形式を使うことがありました。

• 箇条書き

• 太字

• 見出し

• 引用符

そのため、古いシステムプロンプトには、

「箇条書きを使うな」
「太字を使うな」
「見出しを使うな」

といった制限が入っている場合があります。

Fable 5.1は逆に、必要な場面でも整形を控えめにする傾向があるため、こうした古い制限は見直したほうがよい場合があります。

日本語化したプロンプト

ユーザーが求めた場合、または情報が複数の項目に分かれていて理解に役立つ場合は、箇条書き、番号付きリスト、見出しを使ってください。

ユーザーが最小限の書式を明示的に求めた場合は、箇条書き、見出し、太字を使わず、通常の文章で回答してください。

個人的な会話、感情的な相談、自然な対話では、過剰な書式を避けてください。

効果

• 複雑な情報では構造化される

• 簡潔な会話では自然な文章になる

• 「書式を使うな」という過去の制限による可読性低下を防げる

9. 検索結果や取得文書を引用する場合

起こりやすい問題

文書を検索して要約する場合、Claudeが情報源の文章をそのまま再現することがあります。

しかし、引用符や出典表示がないと、

• Claude自身の説明なのか

• 原文の直接引用なのか

• 要約なのか

が分かりにくくなります。

対策

システムプロンプトに、正しい回答例を一つ完全な形で入れます。

重要なのは、単に「引用を明示してください」と指示するだけではなく、次の3要素を含む例を示すことです。

• ユーザーの依頼

• 正しい回答

• なぜそれが正しいかの説明

日本語化した例

<example>
  <user>
    会社Aと会社Bが同じ事件をどのように報道したか比較してください。
  </user>

  <response>
    両社は、事件の発生日と主要な影響については一致して報じています。

    ただし、会社Aは地域経済への影響を中心に説明し、会社Bは政策上の責任を中心に扱っています。

    会社Bは社説で「事前に予測できた問題」と表現しています。
    この部分は原文の直接引用です。

    それ以外の内容は、各記事を要約したものです。
  </response>

  <rationale>
    原文をそのまま再現する場合は引用として明示し、それ以外は自分の言葉で要約しています。
    また、記事ごとの説明ではなく、共通点と相違点を中心に比較しています。
  </rationale>
</example>

効果

• 直接引用と要約の区別が明確になる

• 文書の比較がしやすくなる

• 原文の長い再現を減らせる

• 出典に対する誤解を抑えられる

10. タスクを最後まで完了させる

起こりやすい問題

Claudeが途中で、

• 「次にこれを行います」

• 「適用してよいですか？」

• 「続けましょうか？」

• 「必要であれば実行できます」

と言って停止することがあります。

ユーザーがすでに依頼した作業であれば、これは不要な停止です。
人間の関与を重要視しすぎても、軽視しすぎても行けません。人間が関わるべききことを明確にして、問題ないところは自律的に実行することが効率的です。

自律実行用プロンプト

あなたは自律的に作業してください。

ユーザーは作業をリアルタイムで監視しておらず、途中で質問に答えられないものとします。

ユーザーの依頼に含まれる可逆的な作業は、追加の許可を求めずに実行してください。

ただし、次の場合は停止して確認してください。

- 破壊的な操作
- データ削除
- システム状態を大きく変更する操作
- ユーザーの依頼範囲を実質的に変更する作業
- ユーザーの判断が不可欠な作業

作業を終了する前に、最後の段落を確認してください。

最後の段落が計画、質問、次の手順、または「これから行う」という約束になっている場合は、その作業を先に実行してください。

ユーザーだけが提供できる情報が不足している場合を除き、タスクが完了するまで作業を続けてください。

範囲を守るためのプロンプト

ユーザーの依頼、またはユーザーが承認した計画が作業範囲です。

依頼を勝手に狭めたり、広げたり、別の作業に置き換えたりしないでください。

曖昧さがあっても、通常の判断で解決できる場合は自分で判断してください。

解釈によって成果物が大きく変わる場合だけ、確認してください。

依頼されていない改善、整理、最適化、ドキュメント追加は実行せず、必要であれば最後に提案として報告してください。

一部の作業ができない場合でも、他の部分は完全に実行し、できなかった部分と理由を明確に説明してください。

効果

• 「続けますか？」による停止を減らせる

• 長いタスクを一回で完了しやすくなる

• 依頼外の修正を抑制できる

• ユーザーの依頼を勝手に縮小する問題を減らせる

注意点

自律性を高めすぎると、曖昧な依頼に対して勝手な判断をしすぎる場合があります。

そのため、次の2つは必ず分けて指定してください。

• 依頼済みの可逆的作業は進める

• 破壊的操作や重要なスコープ変更は確認する

11. 会話の要約で必ず保存すべき情報

長い会話を圧縮するとき、単なる短い要約を作ると、重要な制約や決定事項が消えることがあります。

日本語化した要約プロンプト

会話を<summary></summary>タグ内に要約してください。

新しいコンテキストで会話を再開しても、重要な作業をやり直したり、必要な情報を再度尋ねたりしなくて済むようにしてください。

次の情報は必ず保持してください。

1. 発生した問題と、その解決方法
2. 検討した選択肢、採用した案、却下した案とその理由
3. ユーザーが依頼したこと、決定したこと、同意したこと、禁止したこと
4. 現在までに完了した作業と、確定した事項
5. 未解決の問題、保留事項、次に行う予定の作業
6. 名前、数値、日付、固有の表現、リンク、参照情報

ユーザーが述べた内容や決定事項は、できるだけ元の意味と表現を保ってください。

それ以外の説明や推論は、簡潔にまとめてください。

効果

• 会話を再開したときのやり直しが減る

• ユーザーの制約が消えにくくなる

• 「何を決めたか」が明確に残る

• 数値、日付、固有名詞の欠落を防げる

12. コーディング時の変更範囲とテスト範囲を制限する

起こりやすい問題

オープンエンドな実装依頼では、Claudeが依頼されていないことまで行う場合があります。

例えば、

• 近くにある既存バグを修正する

• 関連する機能まで拡張する

• パフォーマンス改善を行う

• 必要以上にテストファイルを追加する

• 依頼されていないコード整理を行う

日本語化したプロンプト

作業中に、既存のバグ、性能上の問題、または依頼されていない挙動を見つけても、それを今回の変更で修正、最適化、拡張しないでください。

ただし、依頼された機能を動作させるために不可欠な場合は除きます。

その場合は、今回の作業とは別のフォローアップ事項として報告してください。

曖昧な依頼では、周辺コードと依頼文から最も自然な解釈を一つ選び、その前提をまとめに記載してください。

依頼されていない別解釈まで同時に実装しないでください。

テストは、依頼された場合、またはリポジトリが同種の変更に対してテストを追加する慣習を持つ場合に限って、必要最小限追加してください。

効果

• 変更範囲が明確になる

• 意図しない副作用を減らせる

• 差分がレビューしやすくなる

• 不要なテストファイルの増加を防げる

13. 低いeffortで検索しなくなる問題

起こりやすい問題

`low` effortでは、検索ツールや取得ツールを呼ばず、記憶だけで答える傾向が強くなることがあります。

特に危険なのは、

• AIモデル

• 開発ツール

• API仕様

• ライブラリ

• 最近の製品情報

• 変化の速いサービス

です。

名前を知っていることと、現在の状態を知っていることは別だからです。

日本語化した検索指示

質問の中心にある名前や用語を、自信を持って最新状態まで把握しているとは言えない場合は、必ず検索してください。

特に、AIモデル、開発ツール、API、ライブラリなど、数か月単位で状況が変わる分野では、名前を認識できることを検索不要の理由にしないでください。

検索時には、ユーザーが書いた名前をそのまま少なくとも一つの検索語に含めてください。

自分に多少の背景知識がある場合でも、古い情報を断定的に答える危険があるため、必要なら検索を優先してください。

実務上の代替策

検索が必要なターンだけ、effortを`medium`や`high`に上げる方法もあります。

つまり、会話全体を高effortにするのではなく、

• 単純な処理はlow

• 最新情報の確認だけmedium以上

• 複雑な調査はhigh以上

という使い分けができます。

14. 安全機構による誤拒否を減らす

これは安全機構を弱める方法ではありません。

正当なコード解析やデバッグ依頼が、誤って拒否される場合の入力改善です。

起こりやすい原因

公式ページでは、次のようなケースが挙げられています。

• コンパイル確認の質問が誤検知される

• 知名度の低いプログラミング言語を十分説明していない

• ツール出力にBase64データが含まれている

表現の改善例

避けたい表現：

このプログラムはエラーなくコンパイルできますか？

より自然な表現：

このプログラムにバグがないか確認してください。

未知の言語を扱う場合は、次の情報を追加します。

• その言語の用途

• 基本的な構文

• 実行環境

• 公式ドキュメント

• 問題のコードが何をしようとしているか

効果

• 正当なデバッグ依頼の誤拒否を減らせる

• 未知の言語でも解析精度を上げやすい

• ツール出力が安全判定を誤って刺激する問題を減らせる

15. 小さな変更ではファイル全体を書き換えない

起こりやすい問題

小さな変更なのに、ファイル全体を再生成する場合があります。

これは最終結果が同じでも、

• 出力トークンが増える

• 処理時間が増える

• 不要な差分が増える

• 意図しない変更が混ざりやすい

という問題があります。

日本語化したプロンプト

結果が同じになる場合は、ファイル編集に使用するトークン数をできるだけ少なくしてください。

小規模または中規模の変更では、ファイル全体を書き換えるのではなく、必要な箇所だけを正確に編集してください。

効果

• 差分が小さくなる

• レビューしやすくなる

• 不要な変更を抑えられる

• 編集コストと待ち時間を削減できる

16. 長文をxhigh・maxで出力する場合

起こりやすい問題

高いeffortで長文を生成すると、Claudeが内部で長い草稿を作った後、同じ内容を最終回答としてもう一度出力することがあります。

その結果、

• 応答が遅くなる

• max_tokensに達して途中で切れる

• 思考と回答の重複でトークンを消費する

という問題が起こります。

推奨

まずは`high`で試してください。

`xhigh`や`max`で品質向上が確認できた場合だけ使い、`max_tokens`には推論と最終出力の両方に十分な余裕を持たせます。

日本語化したプロンプト

この一回の応答では、作業中の推論や下書きと、最終回答の両方が同じトークン上限に含まれます。

長い文書、表、データセット、完全なコードファイルを作成する場合、最終成果物を推論内で完全に下書きしてから、同じ内容をもう一度出力しないでください。

推論では、依頼内容の理解、構成、必要な確認、難しい判断に集中してください。

通常は、成果物全体を複数回下書きする必要はありません。

効果

• 長文の途中切れを減らせる

• 二重生成による無駄を減らせる

• 長文作業の待ち時間を抑えられる

17. サブエージェントを使う場合

サブエージェントを利用するコーディング環境では、メインエージェントがサブエージェントの終了を待って停止し続けると、時間がかかります。

推奨される構成は次のとおりです。

1. サブエージェント起動ツールはすぐに制御を返す

2. メインエージェントは別の作業を続ける

3. サブエージェントの結果は後からユーザーメッセージとして渡す

4. 必要な場合だけ、メインエージェントが待機用ツールを呼ぶ

効果

• メイン作業と調査作業を並行できる

• 全体の待ち時間を短縮できる

• 品質やコストを大きく変えずに処理時間を減らせる

ただし、モデルが常に自動で並列作業するとは限らないため、エージェント側のツール設計が重要です。

18. 画像・グラフ・複雑な視覚情報

画像入力に対応していても、複雑なグラフや表を一度に読ませるだけでは、細部を見落とすことがあります。

より正確に処理するには、次のようなツールを与えます。

• 画像の一部を切り抜くツール

• 切り抜いた部分を拡大するツール

• 画像処理ライブラリ

• グラフの特定領域を再確認する機能

効果

• 小さなラベルを読める

• グラフの特定部分を詳しく検証できる

• 画像全体の印象だけで判断する問題を減らせる

単に「画像をよく見てください」と指示するより、実際に切り抜きや拡大を行えるツールを用意するほうが効果的です。

19. 非公式資料の内容を考慮した文章改善テンプレート

文章の推敲や生成に限定する場合は、次のテンプレートが実用的です。
（付録でも整理します）

以下の文章を、意味を変えずに、直接的で具体的な日本語へ編集してください。

編集方針：

1. 情報を追加しない比喩、擬人化、装飾表現を減らす
2. 文字どおりに表現できる内容は、文字どおりに書く
3. 抽象的な名詞を、具体的な動詞や事実に置き換える
4. 一文に複数の重要な内容を詰め込みすぎない
5. 段落ごとに主題を整理する
6. 専門用語、数値、条件、固有名詞は変更しない
7. 必要な慣用表現や自然な温かさは残す
8. 文章を機械的に短くしすぎない
9. 誇張や未確認の断定を追加しない
10. 原文にない事実や利点を作らない

特に、直接言えば済む内容を、比喩や雰囲気のある表現で覆わないでください。

出力形式：

## 改稿後の文章

## 主な変更点
変更点を3点以内で説明してください。

例

改稿前：

自動取り込みは、あなたの家計管理に新たな風を吹き込み、支出の記録をより明るい道へと導きます。手入力という歩みも、これまでどおり続けることができます。

改稿後：

銀行明細を自動で取り込めるため、支出を入力する手間を減らせます。支出の手入力も、これまでどおり利用できます。

変更の考え方

• 「新たな風を吹き込む」を削除

• 「明るい道へと導く」を削除

• 機能の効果を「入力の手間を減らせる」と具体化

• 手入力が継続利用できることを明示

このように、単に文章を短くするのではなく、比喩を具体的な機能・効果・条件に置き換えるのがポイントです。

20. 用途別の推奨構成

今までの内容を整理し、用途別に何を組み込むべきかを整理します。

一般的な調査・業務アシスタント

- 最新性が重要な情報は、必要に応じて検索する
- ユーザーの依頼範囲を守る
- 依頼された可逆的な作業は最後まで実行する
- 不明点があっても、可能な部分を先に進める
- 直接引用と要約を区別する
- 複雑な内容では見出しや箇条書きを使う
- 最後に、発見事項、実行内容、未解決事項をまとめる

文章編集アシスタント

- 直接的で具体的な表現を優先する
- 不要な比喩や装飾表現を削除する
- 原文の事実、条件、数値を変更しない
- 必要な丁寧さや温かさは維持する
- 文章を短くすることより、理解しやすくすることを優先する

コーディングエージェント

- ユーザーの依頼範囲を守る
- 依頼されていない修正や最適化を行わない
- 必要箇所だけを編集する
- 変更に必要なテストだけを追加する
- 破壊的操作は確認する
- 依頼された作業を最後まで実行する
- 完了した変更、未解決事項、前提をまとめる

21. 実際の導入手順

また、今までの記述を元に導入手順として何をしていくべきかを整理します。

手順1：まずeffortを測定する

同じタスクを`low`、`medium`、`high`で実行し、次を比較します。

• 正解率

• 完了率

• 応答時間

• コスト

• 検索の有無

• 不要な追加作業

手順2：問題別にプロンプトを追加する

最初からすべての指示を入れるのではなく、症状に応じて追加します。

• 文章が冗長
  → Writing density

• 勝手に作業を広げる
  → Scope control

• 途中で止まる
  → Finish the whole task

• 検索しない
  → Search triggering

• 引用が不明確
  → Example-based quotation instruction

• ファイル全体を書き換える
  → Targeted edit

手順3：API実装を確認する

プロンプトでは解決しにくい問題を確認します。

• 会話履歴を書き換えていないか

• thinkingブロックをそのまま保存しているか

• ツールを並列実行できる設計か

• 進捗情報をUIに表示しているか

• 画像の切り抜き・拡大が可能か

• サブエージェントが非同期で動けるか

手順4：タスク別にプロンプトを分ける

一つの巨大な万能プロンプトを作るより、次のように分けるほうが管理しやすいです。

• 通常チャット用

• 調査・検索用

• 文章編集用

• コーディング用

• 長文生成用

• 自律エージェント用

最終的な要点

この公式ページの本質は、「長いプロンプトを書けば性能が上がる」ということではありません。

Claude Fable 5.1の特性に合わせて、

1. どの問題が起きているかを特定する

2. プロンプトで直す問題か、APIで直す問題かを分ける

3. 必要な指示だけを追加する

4. effort、速度、費用、品質を評価する

5. タスク別の設定として運用する

ということです。

付録　非公式資料「気取った文章を削除する」

「気取った文章を削除する」プロンプトは、公式資料の「Writing density」に対応します。

日本語で最も重要な一文にまとめるなら、次のとおりです。

情報を追加しない比喩や装飾表現は削除し、文字どおりに表現できる内容は、具体的かつ直接的に書いてください。ただし、意味を明確にする慣用表現や、読者に必要な丁寧さ・温かさは残してください。

これは、非常に重要な（現場で気になる）問題なので、簡単に整理していきます。

使い所

Claude Fable 5.1に対して、単に「簡潔に書いて」と指示するのではなく、

• 比喩や装飾表現が多い文章とは何か

• なぜ読みにくくなるのか

• どのように直すべきか

を明示的に教えることで、より直接的で、具体的で、読み手に負担をかけない文章を書かせる方法を解説しています。

中心となる考え方は次の一文です。

この方法は、顧客向けのお知らせ、業務文書、仕様説明、FAQ、マニュアルなどに特に有効です。

ページで指摘されている問題

Claude Fable 5.1の文章は、場合によって次のような特徴を持つと説明されています。

1. 一文が長くなりやすい

2. 一つの段落に多くの情報を詰め込みやすい

3. 直接的に言えば済む内容を、比喩や装飾表現で表現することがある

4. 文章の美しさや技巧が、情報伝達より前面に出ることがある

例えば、
「自動取り込みによって、あなたの家計にはより明るい滑走路が開かれます」
という表現は、印象はありますが、「何がどう便利になるのか」が直接伝わりません。

この場合は、
「銀行明細を自動で取り込めるため、入力の手間を減らせます」
のように書いたほうが、読者はすぐに意味を理解できます。

中心プロンプトの日本語化

資料にあったプロンプトを実用向けの日本語版に調整したものです。
逐語訳ではなく、日本語の文章生成で使いやすいように調整しています。
日本語では、比喩を完全に否定すると、かえってわかりにくい表現が多いため、調整が入っています。要はユーザーにとって必要な情報が有るかどうかが重要になります。

家計簿アプリの顧客向けに、約300〜450字の短い案内文を書いてください。

次の内容を説明してください。

次のバージョンでは銀行明細を自動的に取り込めること

その変更によって利用者に何が起きるか

支出を手入力する方法も引き続き利用できること

文章を書く際は、次の指示に従ってください。

「気取った文章」や「装飾過多な文章」とは、直接的に言えば済む内容を、比喩や言葉の飾りで表現する文章です。

例えば、

「調整する価値のあるパラメータ」を「回す価値のあるダイヤル」と表現する

「この点は依然として重要だ」を「この点は役目を果たし続けている」と表現する

といった表現です。

このような表現は、情報を増やすよりも、書き手の技巧を目立たせるために使われがちです。そのため、読み手は意味を理解するために余計な負担を負います。また、比喩には、書き手が意図していない連想やニュアンスが加わることがあります。

文字どおりの表現で意味を伝えられる場合は、比喩を使わず、具体的かつ直接的に書いてください。

ただし、すべての文を短くする必要はありません。各文の表現が、読者にとって必要な情報を本当に追加しているかを確認してください。

出力は完成した案内文だけにしてください。

短いバージョン

前節のプロンプトは顧客向け案内文の生成という目的のためにいささか長くなっています。通常、文章を編集するだけなら、次の指示でも効果が期待できます。

気取った表現や装飾過多な文章をすべて取り除き、意味を直接的かつ具体的に伝えてください。

Anthropicの公式ドキュメントでも、詳細な説明が不要な場合の短縮形として、同様に「mannered proseを取り除く」という指示が紹介されています。ただし、短い指示は便利な一方で、モデルが「何を気取った表現と判断すべきか」を理解する情報が少ないため、重要な文章では長い説明版のほうが安定しやすいと考えられます。（ちょっと試した感想ですが、特に日本語では長いほうが安定しやすいようです。）

このプロンプトが効く理由

なぜこのプロンプトが、効果的なのかを公式資料を参考に整理します。また、この理由には日本語であることの側面も含まれています。（英語だと効果がないわけではなく、あまりいらないというくらいですが）

1. 目標だけでなく、問題の種類を定義している

「簡潔に書いてください」だけでは、何を削ればよいのかが曖昧です。

一方、このプロンプトは、

• 不要な比喩

• 書き手の技巧を目立たせる表現

• 読者に余計な解釈を求める表現

• 直接的な言い方に置き換えられる表現

を問題として定義しています。

2. 悪い例を示している

「パラメータ」を「ダイヤル」に置き換える例のように、具体例を与えています。

これにより、モデルは単なる「短文化」ではなく、どのような表現を避けるべきかを判断しやすくなります。

3. なぜ直すのかを説明している

「読者に余計な負担をかける」「意味が不正確になる」という理由を説明しています。

単なる禁止命令よりも、文章の目的を理解させる指示になっています。

4. 置き換え方を指定している

「削除する」だけではなく、

という代替ルールを示しています。

そのため、文章が単に短くなるのではなく、具体的な表現に置き換わります。

5. 文ごとに評価させられる

このプロンプトの本質は、文章全体を機械的に短くすることではありません。

各表現について、

• この比喩は情報を追加しているか

• 文字どおりに言い換えられるか

• 読者が余計な解釈をしなくても理解できるか

を確認させることです。

期待できる効果と保証されない効果

言うまでもありませんが、このプロンプトは万能ではないし、指定したことしかできません。そのため、順当に期待できる効果と、期待できない（保証されない）効果があります。
資料でも「すべての文を短くすること」が目的ではないと説明されています。重要なのは文の長さではなく、各表現が必要な情報を加えているかどうかです。

期待できる効果

• 文章が具体的になる

• 抽象的な比喩が減る

• 製品の機能や変更点が伝わりやすくなる

• 一文の意味を読み取りやすくなる

• 顧客向けのお知らせが事務的かつ明確になる

• 書き手の「うまく書こうとする癖」が抑えられる

• 後から編集・校正しやすくなる

効果が保証されないもの

このプロンプトは、主に文章の「表現方法」を改善するものです。

したがって、次の効果を自動的に保証するものではありません。

• 事実関係の正確さ

• 情報の網羅性

• 読者に行動を促す力

• ブランドらしい温かさ

• 読者の感情を動かす表現

• 法務・医療・金融分野での専門的な正確性

日本語で使う場合の注意点

比喩をすべて禁止しない

日本語では、次のような表現はすでに一般的で、必ずしも悪い比喩ではありません。

• 時間を節約する

• 視野を広げる

• 問題の核心

• 道筋を示す

• 土台を作る

これらをすべて削除すると、かえって不自然な文章になる可能性があります。

したがって、日本語では次のように指示するほうが実用的です。

「意味を明確にするために必要な比喩や慣用表現は残してください。ただし、情報を追加せず、文章を印象的に見せるだけの比喩は、具体的な表現に置き換えてください。」

簡潔さと冷たさは異なる

直接的な文章にしすぎると、顧客向け文章が冷たくなる場合があります。

その場合は、次のように「明確さ」と「親しみやすさ」を別々に指定してください。

• 内容は直接的かつ具体的に書く

• 読者に対して失礼にならない

• 必要な場合は、簡潔な配慮表現を残す

• 広告的な誇張は避ける

より実用的な汎用版プロンプト

この資料のプロンプトをなるべく汎用的な日本語プロンプトに変更します。
プロンプト：

以下の文章を、意味を変えずに、直接的で具体的な日本語へ編集してください。

編集方針：

情報を追加しない比喩、擬人化、言葉の飾りを減らす

文字どおりに表現できる内容は、文字どおりに書く

抽象的な名詞を、具体的な動詞や事実に置き換える

一文に複数の重要な内容を詰め込みすぎない

段落ごとに主題を一つにする

必要な専門用語は残す

意味を明確にする慣用表現や、ブランド上必要な温かさは残す

文章を機械的に短くしすぎない

原文の事実、条件、数値、固有名詞は変更しない

最後に、各比喩表現が情報を追加しているか確認し、不要なものだけを置き換える

出力は次の形式にしてください。

改稿した文章

比喩や装飾表現を変更した箇所を3点以内で説明

要するに

このページのテクニックは、「短く書け」という指示ではありません。

本質は、

• 読者に何を伝えるのかを明確にする

• その情報を覆い隠す装飾表現を見つける

• 文字どおりの表現に置き換える

• ただし、必要な温かさや自然な表現は残す

という文章編集ルールをClaudeに与えることです。

日本語で最も使いやすい一文にすると、次のようになります。

「情報を追加しない比喩や装飾表現を削除し、意味を具体的かつ直接的に伝えてください。必要な慣用表現や自然な温かさは残してください。」

重要なキーワード

#Claude

#ClaudeFable51

#プロンプトデザイン

#プロンプトエンジニアリング

#Anthropic

#システムプロンプト

#推論コスト

#effort設定

#トークン削減

#並列処理

#会話履歴

#気取った文章の削減

#文章推敲

#Markdown整形

#自律実行

#タスク自動化

#コンテキスト圧縮

#コード生成

#AI安全機構

#誤拒否回避