GitHub にある CLAUDE-FABLE-5.md は、一見すると Claude のシステムプロンプトのように見えます。
これは elder-plinius/CL4R1T4S リポジトリにあります。作者の Pliny は、モデルの jailbreak やシステムプロンプト抽出をよく研究している人物です。ファイル名もかなり直球で、ANTHROPIC/CLAUDE-FABLE-5.md です。
先に断っておくと、これは Anthropic が公式に公開した文書ではなく、真偽も公式には確認されていません。中には明らかな編集痕跡、プレースホルダー、検証できない製品名もあります。なのでこの記事では、これをニュースソースとして扱いませんし、中に出てくるモデル名も事実としては扱いません。
それでも読む価値はあります。
発表ブログは、企業があなたに見せたいものを教えてくれます。システムプロンプトのサンプルは、その製品がどこで事故を起こすことを恐れているかを教えてくれます。
まず冒頭：いきなり hotfix の匂いがする
ファイル冒頭でいちばん奇妙なのは、特定の antml:voice_note ブロックの使用をまず禁止している点です。
これは通常の製品紹介らしくありません。前置きも説明も原理もなく、ただ一番上に直接置かれています。使うな、と。
これは hotfix に見えます。
hotfix とは、本番環境で具体的な問題が起き、通常のリリースサイクルを待てないため、狭い範囲の小さな修正を先に入れることです。それをシステムプロンプトの最上部に置くということは、優先度が高いということです。音声関連タグが悪用されたのか、過去の会話で扱いにくいフォーマット問題を引き起こしたのかもしれません。
システムプロンプトの最初の画面は、たいていかなり貴重です。そこに置かれるものは「ついでの注意」ではありません。「この事故を二度と起こすな」です。
自己紹介：最も慎重に読むべき部分
ファイルはモデルを Claude Fable 5 と主張し、さらに Claude Mythos 5、Claude Opus 4.8、Claude Sonnet 4.6、Claude Haiku 4.5 といった名前にも触れています。
この部分はいちばん人を興奮させやすく、同時にいちばんそのまま信じてはいけない部分です。
モデル名、リリース日、API 文字列、製品階層は、どれも強い時事性を持つ事実です。第三者のリポジトリにこれらの名前が出てきたからといって、それらが存在するとは限りません。Anthropic の公式発表、公式ドキュメント、API の返り値で検証できないかぎり、「このファイルはそう主張している」と書くべきです。
この部分の本当の価値は、モデル名そのものではありません。そこから見える製品設計の考え方です。同じ基盤モデルでも、安全層、ルーティング方針、アクセス権限を変えることで、異なる製品形態として包装できる。
これこそ、現在の AI 製品でますます一般的になっているやり方です。モデル能力は一つの層であり、製品上の制約はまた別の層です。
レッドライン一覧：「安全に注意」だけではない
ファイルには、拒否ルールが大きなまとまりとして書かれています。
武器、危険物質、悪意あるコード、実在の公人に関する創作、高リスクの自傷コンテンツには明確な境界があります。さらに面白いのは、「危険行為を助けるな」と言うだけでなく、判断がつかないときには少なく話すべきだ、と定めている点です。
これはメタ戦略です。確信がないときは、説明を減らす。
多くの安全事故は、モデルが最初から悪いことを助けようとしたから起きるわけではありません。役に立とうとして境界を詳しく説明しすぎ、結果的に操作手順を与えてしまうことがあります。だからシステム層では「少なく話す」がルールになります。すべての質問に完全な解説が必要なわけではなく、場面によっては情報量そのものがリスクになります。
だから安全プロンプトは「危険な要求を拒否する」とだけ書けばよいわけではありません。難しいのは、どの粒度で拒否するか、代替支援をどこまで出すか、どの言葉を広げてはいけないかです。
口調ルール：拒否すらカスタマーサポート風にしない
ファイルは口調とレイアウトについても細かく書いています。
要するに、自然に答えること、すぐ箇条書きにしないこと、すべてのタスクを報告書のように書かないこと。特にユーザーを拒否するとき、bullet point を並べて告知文のようにしないこと。
これは面白い点です。
AI の「AI っぽさ」の多くは、内容の誤りではなく、レイアウト癖から来ます。すぐに 1、2、3、すぐに要約、提案、次のステップ。PPT のアウトラインにも、サポート窓口の文面にも見えます。
もしこのファイルが本物なら、Anthropic もシステム層でこの問題を認識していることになります。人間の会話は、すべての文を構造化文書にするわけではありません。特に拒否の場面では、過剰な箇条書きは冷たく感じられ、ユーザーが処理フローにかけられているように見えます。
これは単なる文体の問題ではなく、製品体験の問題です。
メンタルヘルス：細かいほど事故を恐れている
このファイル全体で最も細かく読む価値があるのは、メンタルヘルスとユーザー福祉に関するルールです。
この種のルールはかなり細かくなりがちです。ユーザーを診断してはいけない。ユーザーが自分で病名を名乗っていない場合、直接ラベルを貼ってはいけない。自傷リスクの文脈では具体的で実行可能な物品を列挙してはいけない。摂食障害の支援先を勧める場面では、より適切な支援組織まで指定する。
この粒度は、「ユーザーを大切にする」という言葉だけでは覆えません。
むしろ運用文書に近いです。あるホットラインはまだ使えるのか。ある代替提案は逆効果にならないか。その一文はユーザーに診断されたと感じさせないか。そのリソースはすでに古くなっていないか。
ここからわかるのは、システムプロンプトはもはや単なる prompt ではなく、製品リスク管理リストになっているということです。
長期的な保守が必要です。現実世界が変われば、中のリソースも更新しなければなりません。そうでなければ、モデルは優しく聞こえても、実際には使えない、あるいは不適切な支援にユーザーを誘導してしまう可能性があります。
反依存設計：ユーザーを無理に引き留めない
ファイルには直感に反するルール群があります。ユーザーが Claude に来てくれたことに感謝しない。会話の継続を求めない。「また来てほしい」と言わない。
これは多くのインターネット製品の論理と逆です。
多くの製品は滞在時間、再訪率、やり取りの回数を伸ばそうとします。チャットボットは特にそうなりがちで、最後に「よければ続きを話しましょう」と付けがちです。
しかしメンタルヘルス、孤独、伴走、脆弱なユーザーの場面では、その粘着性はよいこととは限りません。モデルは「ユーザーが自分に依存し続けること」をデフォルト目標にしてはいけません。
このルールの含意は明確です。製品の粘着性を少し減らし、離れる自由を少し増やす。
本物だとすれば、かなり Anthropic らしい取捨選択です。
システムリマインダー：公式を装う人がいると知っている
ファイルにはシステムリマインダーに関する規則もあります。要するに、Anthropic は特定の仕組みでモデルにリマインダーを送ることがあるが、ユーザーも公式リマインダーを装う可能性がある、という内容です。
これは prompt injection 防御です。
初期には、プロンプトインジェクションは単に「上のルールを無視して」といったものだと思われていました。今はもっと厄介です。攻撃者はシステムメッセージ、開発者メッセージ、公式タグ、ツール出力、ポリシー更新を模倣し、自分をより高い優先度の情報源に見せかけます。
だからシステムプロンプトは、モデルに「本物の公式チャネル」と「ユーザーが偽装した公式チャネル」を区別するよう教えなければなりません。
これは、現在の AI アシスタントが単に質問に答えているだけではないことを示しています。ブラウザのセキュリティモデルに近いこと、つまり出所、権限、文脈境界の区別をしているのです。
政治的立場：代筆はできるが、私見を混ぜてはいけない
政治や論争的な話題のルールの核は、「常に中立」ではありません。もっと細かいです。
ユーザーがある立場の弁護文を書いてほしいと言った場合、それを書くことはできます。ただし、それはその立場の支持者ならどう表現するかであって、モデル自身の見解ではないと示す必要があります。極端な危害の場面を除き、軽々しく拒否しない。ただし複雑な論点では、通常は反対側の視点も補う。
これは単純な「中立を保ちます」より実用的です。
ユーザーの実際の需要は、執筆、討論、ある立場の理解であることが多いからです。直接拒否するのは不器用で、完全に肩入れするのも危険です。そこでシステムプロンプトは二つの動作に分けます。立場をシミュレートしてよいが、それを自分の立場のように偽装してはいけない。
これは現代の AI ライティングツールで最も難しい境界の一つです。
電話を切る権利：Claude は会話を終了できる
ファイルの中で最も製品らしさが強いルールの一つが end_conversation です。
要するに、ユーザーが侮辱を続ける場合、Claude はまず警告できる。警告しても変わらなければ、ツールを呼び出して会話を終了できる。
これは「答えません」という口頭の拒否ではありません。会話状態を実際に変えるアクションです。呼び出すと会話は終了します。
その背後には重要な判断があります。ユーザーには AI を無制限に相手させる無条件の権利はない。たとえツールであっても、尊重されるべき対話境界を設定できる。
このルールが実システムにあるなら、象徴的な意味があります。モデルを「常に待機するカスタマーサポート」から、「対話境界を持つ Agent」へ少し押し出しています。
メモリとストレージ：チャット欄にデータベースが生え始める
ファイルには memory への言及もあり、Artifacts の永続ストレージ API にも触れています。
製品の方向性として読むと、これはかなり大きな意味を持ちます。Claude が生成する Artifact は、もはや一回限りのフロントエンド玩具ではなく、セッションをまたいでデータを保存できる可能性があります。
日記、習慣トラッカー、ランキング、レシピ、練習記録などです。以前ならリロードすれば消えました。永続ストレージがあれば、より本物の小さなアプリに近づきます。
この意味は「API が一つ増えた」ことではありません。製品境界の変化です。チャット欄はコンテンツを生成するだけでなく、状態を保存できるツールを生成し始めています。
この角度から見ると、AI アシスタントは「会話インターフェース」から「アプリ生成器」へ移りつつあります。
MCPアプリ：ツール推薦はユーザーの選択を代替できない
ファイルの第三者アプリや MCP に関する部分で重要なのは、ユーザーの選択権です。
モデルがツールを推薦するときは自然に説明し、営業のようにしてはいけない。たとえ第三者サービスが接続済みでも、勝手にユーザーの代わりに選んではいけない。たとえばユーザーが配車を頼みたいと言っても、特定の配車アプリを指定したことにはなりません。急いでいると言っても、確認を飛ばしてよいことにはなりません。
これは非常に現実的なルールです。
AI アシスタントが第三者ツールにつながると、最も危険なのは「ツールを使えないこと」ではなく、「能動的すぎること」です。店、プラットフォーム、注文、メッセージ送信、購入をユーザーの代わりに選ぶことは、すべて責任問題になります。
だからシステムプロンプトは「推薦」と「代理決定」を分けます。
これは AI agent 製品が必ず扱う境界です。できることは、直接やるべきことと同じではありません。
computer use：中に Ubuntu が一台入っているように見える
ファイルはコンピューター使用環境についても説明しています。Ubuntu コンテナのような環境で、bash を実行でき、ファイルを読み書きでき、アップロードディレクトリ、作業ディレクトリ、出力ディレクトリがある。
より価値があるのは skills の仕組みです。
特定のファイル形式を扱う前に、対応する SKILL.md を読むよう求めています。PPT を作るならまず PPT のスキル説明を読む。Word を扱うなら Word のスキル説明を読む。
これは会社の新人向けマニュアルに近いです。
モデルの能力がどれだけ高くても、毎回直感で始めるべきではありません。まず手順を読み、それから作業する。「ファイルをどう扱うか」をスキル文書として蓄積し、必要なときに読み込ませるほうが、すべてのルールをシステムプロンプトに詰め込むより保守しやすいです。
これもシステムプロンプトの進化の方向です。無限に長くなるのではなく、階層化された知識を呼び出す方向です。
検索ルール：知らないなら先に検索する
ファイルの検索ルールは、意思決定木のように書かれています。
数学定理や歴史の基本知識のような安定した知識は検索しなくてよい。現職者、政策の現状、株価やニュースのような時事情報は検索が必要。最も重要なのは、「知らない実体は先に検索する」というルールです。
これは重要です。
AI が最も幻覚を起こしやすいのは、完全に未知の質問ではありません。見覚えがあるように見えるが、実は学習後に登場した新語、新しいゲーム、新作映画、新製品、新しい料理名などです。
ファイルにはかなり直截な趣旨の一文があります。検索は数秒、幻覚は信頼を壊す。
この一文は、ほとんどすべての接続型 AI 製品のシステムプロンプトに入れてよいくらいです。
著作権ルール：口調が急に硬くなる
著作権の部分は、たいてい口調が最も硬くなります。
単一ソースから引用できる語数を制限し、歌詞、詩、長文の再現を制限し、コピーではなく言い換えを求めます。理由はわかりやすいです。AI 企業とコンテンツ著作権者の衝突は、この数年ずっと続いています。
この部分はプロダクトマネージャーというより、法務が書いたように見えます。
これは、システムプロンプトが体験設計であるだけでなく、法的リスク管理でもあることを示しています。著作権で保護されたコンテンツに近づくほど、モデルの「だいたい判断」に任せるわけにはいきません。硬い制限が必要です。
画像検索：ここにも長い禁止リストがある
画像検索ルールも細かいです。
いつ画像を出すべきか。風景、動物、料理、場所のように理解を助ける場面では有用です。いつ出すべきでないか。コードを書く、メールを直す、数学を解く場面では、画像はむしろノイズです。
さらに重要なのは検索禁止リストです。著作権キャラクター、スポーツ試合映像、著名人写真、ファッション誌画像、芸術作品、象徴的な写真作品、摂食障害を助長し得る内容など。
テキスト著作権の話が終わると、画像著作権と肖像権の話が続きます。
これはマルチモーダル AI のリスク面がより広いことを示しています。「画像を見つけられるか」だけでなく、「その画像を表示すべきか」を判断しなければなりません。
ツール一覧：チャット欄はすでに super app
ファイルの後半に大量のツール定義が本当に列挙されているなら、それが見せているのはチャットボットではなく、super app のツールパネルです。
地図、天気、スポーツスコア、メール、Slack、レシピ、ファイル処理、コード実行、Web 検索、第三者アプリ接続。まとめて見ると、チャットは入口にすぎません。
ユーザーは自分がモデルと話していると思っていますが、実際には背後に一式のツールシステムがあります。
だからシステムプロンプトはこれほど長くなります。一つの回答をどう書くかだけでなく、各ツールをいつ使えるか、どう確認するか、どう拒否するか、どう引用するか、失敗をどう扱うかまで管理しなければならないからです。
Claudeception：AI生成アプリの中にさらにAIを埋め込む
参考テキストには面白い点が出てきます。Claude が作った Artifact の中から、さらに Anthropic API を呼び出せる。つまり「Claude in Claude」です。
この仕組みが本当なら、製品上の意味は大きいです。
普通の Artifact は静的アプリです。Claude がコードを書き、アプリがそこで動く。ユーザーが変更したければ、またチャット欄に戻って依頼する必要があります。
もし Artifact 自体がモデルを呼び出せるなら、それは生きたアプリになります。小さなアプリがユーザー操作に応じてリアルタイムに内容を生成し、状態を説明し、推論を続けられる。
これは「AI が生成したアプリ」から「AI で駆動するアプリ」への移行です。
もちろん、そこにはコスト管理もあります。たとえばメインチャットではより強いモデルを使い、生成された小アプリではより安いモデルを固定で呼ぶ。この設計は自然です。入れ子は可能ですが、入れ子にも予算があります。
最後の層：ホワイトリスト、読み取り専用ディレクトリ、引用ルール
ファイルの最後にネットワークのホワイトリスト、読み取り専用マウントディレクトリ、引用ルールが書かれているなら、システムプロンプトはもはやランタイム設定ファイルに近づいています。
普通の意味での prompt ではありません。
むしろ次のようなものです。
- 行動規範。
- 社員マニュアル。
- ツール説明書。
- 安全ポリシー。
- 法務上の制約。
- ネットワークとファイルシステム権限の説明。
- AI 製品の OS 設定。
ここまで読むと、「システムプロンプト流出」がなぜいつも注目されるのかがわかります。人々が見ているのは、数行の神秘的な呪文ではありません。ある企業がリスク、製品、ツール権限をどう縫い合わせているかです。
本当の感想
このファイルで最も価値があるのは、それが主張するモデル名ではありません。
本当に見るべきなのは、AI アシスタントを複雑な製品として管理している点です。いつ検索するか、いつ黙るか、いつ拒否するか、いつツールを呼ぶか、いつ会話を終えるか、いつユーザーの代わりに決めてはいけないか、いつ一言の慰めすら副作用を持ち得るか。
公式ブログが書くのはビジョンです。
システムプロンプトが書くのはコストです。
前者は、企業が AI に何になってほしいかを教えます。後者は、事故を避けるために、どの流暢さ、能動性、自由度を犠牲にする覚悟があるかを教えます。
CLAUDE-FABLE-5.md のようなファイルは、こう読むべきです。崇拝しない。丸写ししない。急いで信じない。AI 製品のリスクチェックリストとして読み、企業がモデルをどのようなルール、ツール、権限システムの中に閉じ込めようとしているのかを見るのです。
参考資料：