Claude Fable 5のシステムプロンプトが示す、ハーネス時代の到来

Anthropic公式の Claudeシステムプロンプトのリリースノート は、魔法の種明かしとして読むべきものではありません。価値があるのは、そこに製品の向かう方向が表れているからです。このノートは、ClaudeのWebインターフェース（claude.ai）とiOS/Androidモバイルアプリで使われる中核プロンプトの、日付付きスナップショットを公開しています。Anthropicは境界も明確にしています。これらの更新はClaude APIには適用されません。この区別は重要です。このページをAPIプロンプトとして扱うべきではなく、非公開のプロンプト文面をコピーしたり運用に組み込んだりしてよい根拠として扱うべきでもありません。

このページが示しているのは、フロンティアモデルに期待される仕事が着実に変わっているということです。プロンプトは、チャットボットの人格設定シートというより、エージェントの運用マニュアルに近づいています。ツールの使い方、いつ確認するか、どう引用するか、ファイルをどう扱うか、安全境界の周辺でどう振る舞うか、不確実性からどう立て直すか、そして製品の操作面の中でどう働くかが書かれているのです。

操作マニュアルがエージェントのワークフローレーンへ変わっていく編集風イラスト

図1：システムプロンプトの流れは、「ユーザーに答える」から「ワークベンチ内で安全に作業する」へ移っている。

使用すべき名称は正式名称の Claude Fable 5 です。APIモデルIDは claude-fable-5 です。Anthropicは Claude Mythos 5（claude-mythos-5）にも触れていますが、この2つを安易に混同すべきではありません。Claude Fable 5は一般提供されるモデルであり、Mythos 5は利用可能性が制限されています。本稿で重要なのはモデルの宣伝文句ではありません。最新のClaudeチャットインターフェース向けプロンプトが、より広い業界変化の標識に見えることです。モデルは、ハーネスの一部として動くことを期待され始めています。

強化されたアシスタントから運用マニュアルへ

OpusからFableへの流れを読むうえで有効なのは、想定される運用環境の進化として見ることです。

この進化は控えめですが、重要です。初期のアシスタントプロンプトは、主に回答品質に関するものでした。有用であること、安全であること、正確であること、ユーザーの意図に従うこと。新しいパターンは仕事の実行に関するものです。Claudeが、ツールが存在し、ファイルが状態を持ち、履歴が意味を持ち、引用を慎重に扱う必要があり、一部の操作では拒否や承認が必要になる場所で動いていることを前提にしています。

これはAIが「会話相手」から「仕事の参加者」へ移るときに起こることです。会話相手なら、質問に答えて消えることができます。仕事の参加者には、机、記憶、カレンダー、ファイルキャビネット、許可を求める方法、成果物を残す場所、そして人間が何が起きたかを監査できる仕組みが必要です。

行動するか、確認するかのバランス変化

Opus 4.7の方向性で特に意味があるのが、行動と確認のバランスです。初期のAIワークフローの多くは、退屈な形で失敗していました。次のステップが明らかなのに、モデルが確認を求めて止まってしまうのです。ユーザーが「このメモからローンチ計画を起草して」と頼んでも、アシスタントは有用なものを出す前に、トーン、読者、タイムラインを尋ねてしまうことがありました。

確認は今でも必要です。判断によって範囲、リスク、コスト、法的な露出、外部へのアクションが変わるなら、モデルは質問すべきです。しかし欠けている情報が小さく、可逆的で、推測可能な場合、有能なエージェントは仮定を明示したうえで前へ進むべきです。

これは文章術の話に聞こえるかもしれませんが、実際にはハーネス設計の話です。適切な環境は、低リスクの段階ではモデルに進行を許し、高リスクのチェックポイントでは停止させるべきです。たとえば次のようにです。

• 計画は今すぐ起草するが、顧客に送る前に確認する。
• リポジトリは今すぐ調べるが、ファイルを編集する前に確認する。
• 公開情報源は今すぐ集めるが、公開前に不確かな主張を明示する。
• データベース移行案は今すぐ準備するが、実行前に承認を求める。

チャットウィンドウはこのポリシーを文章で表現できます。ハーネスはそれをワークフローとして強制できます。

ツール発見の変化

Opus 4.8の方向性は、もう1つのポイントを示しています。モデルは諦める前に、自分の環境を発見すべきだということです。ブラウザ、ファイルリーダー、スプレッドシートツール、PDFパーサー、コードランナー、画像アナライザーが使えるなら、会話だけが手元にあるかのように振る舞うのではなく、その操作面を使うべきです。

これにより「知能」の定義が変わります。モデルが「そのファイルにはアクセスできません」と言うのは、あるインターフェースでは正しく、別のインターフェースでは間違っているかもしれません。モデルの実用能力は今や、次の要素の総和です。

1. モデル自身の推論能力、
2. モデルに公開されたツール、
3. そのツールに与えられた権限、
4. ステップをまたいで保持される状態、
5. 結果を検査できるArtifactの操作面。

だからこそ agent harness という言葉が重要になります。ハーネスは飾りではありません。モデルに目、手、記憶、境界、出力チャネルを与えるシステムです。それがなければ、強いモデルでさえ、小さなチャットボックスに乗った、やけに雄弁な乗客になってしまいます。

チャットアシスタントの振る舞いから完全なエージェント運用マニュアルへ向かう手描きタイムライン

図2：プロンプトの進化は、より豊かな支援から構造化された運用へ向かっている。行動し、ツールを発見し、状態を保ち、Artifactを生み出す流れである。

なぜハーネス時代は「よりよいチャット」ではないのか

重要な業界変化は、モデルが長い回答を書けるようになったことではありません。モデルが、より長い仕事のループに参加することを期待されるようになったことです。実際のループには状態とリスクがあります。

コーディングタスクを考えてみましょう。ユーザーが必要としているのは、バグを直したと主張する段落ではありません。必要なのはパッチ、テスト出力、変更ファイルの要約、レビュー用メモです。市場ブリーフィングならどうでしょう。ユーザーが必要としているのは、追跡不能な自信満々の総合ではありません。日付付きの情報源、引用、前回レポートとの差分、そして来週も更新できる場所が必要です。ブラウザベースの操作なら、レポートをダウンロードしたという約束では足りません。ファイル、フォルダ、例外リスト、そしてどの手順が自動化され、どの手順が手動で処理されたかの記録が必要です。

単一のチャットUIは、仕事に必要なものをいくつも欠いているため、この領域が苦手です。

• 外部状態： 何がすでに読まれ、変更され、ダウンロードされ、決定されたのか。
• 段階チェックポイント： 承認や方向転換のために、作業はどこで止まるべきか。
• 権限境界： どの操作が読み取り専用で、可逆で、外部向けで、破壊的で、高コストなのか。
• 復旧： タスクが途中で失敗したとき、最初から盲目的にやり直さず再開できるか。
• Artifactライフサイクル： チャットが流れ去ったあと、最終成果物はどこに残るのか。
• 並列分離： 調査、執筆、テスト、レビューを互いに汚染せず別々のワークストリームで進められるか。
• 可観測性： 人間が情報源、操作、コスト、失敗、仮定を確認できるか。

これらはプロンプトエンジニアリングの細部ではありません。運用面の細部です。

MCPlatoがこの流れをどう受け止めるか

MCPlatoは、単なる別の回答ボックスではなく、AIワークスペースでありエージェントの運用面として理解するのが自然です。その製品語彙は、Claudeの新しいシステムプロンプトが示唆する方向とよく対応しています。

Sprite は調整役です。タスクに複数の段階や専門家が必要な場合、Spriteは作業を分解し、セッションへ委任し、進捗を追跡し、成果を再びまとめます。長いタスクが、途切れない1本の思考の鎖に収まることはめったにないからです。

Wand は状態を持つパッケージ化されたワークフローです。同じ手順を毎回AIに即興で再現させるのではなく、Wandは段階、ゲート、スコープ化されたリソース、期待されるArtifactを定義できます。その結果は、プロンプトテンプレートよりも、繰り返し使える作業アプリに近くなります。

Artifact は永続的な終着点です。出力はチャット本文の壁の中に閉じ込められるべきではありません。レポート、パッチ、デッキ、スプレッドシート、フォルダ、意思決定メモ、QA記録、その他の検査可能なオブジェクトになるべきです。

Skill と Distill Skill はノウハウを保持します。うまく機能したワークフローがあれば、再利用できる部分は再び呼び出せるようにするべきです。チームはこうして、孤立したヒーロー的プロンプトから共有された運用実践へ移っていきます。

ClawMode と Scheduled Tasks は、作業を時間をまたいで拡張します。価値あるタスクの中には、即時でないものがあります。週次の調査ブリーフ、夜間のリポジトリスキャン、定期的なコンテンツパイプライン、新しい情報が出た後のフォローアップなどです。

権限と承認ゲート は、自律性に境界を与えます。MCPlatoは盲目的な自動化として語るべきではありません。よりよい原則は、制御された自律性です。低リスクの操作ではAIに進ませ、ファイル変更、メッセージ送信、外部システムへの接触、ビジネスリスクを伴う操作では人間の承認を求めます。

Channels と IM bridges は、やり取りを非同期にします。ユーザーはチームチャットからタスクを委任し、進捗更新を受け取り、前面のチャットウィンドウに張り付かずに最終Artifactを確認できるべきです。

ローカルファーストのワークスペース状態 は、資料、状態、出力をユーザーの仕事の近くに保ちます。これですべてのプライバシーやセキュリティ懸念が消えるわけではありませんが、姿勢は変わります。ワークスペースは、コンテキストを整理し、レビューし、統制する場所になります。

要するに、MCPlatoは、最新の運用指示がますます前提にしつつある環境をモデルに与えます。ツール、ファイル、メモリ、権限、段階、Artifact、人間のチェックポイントです。

Artifact、スケジュール、承認、セッションレーンを備えたワークスペースハーネスのフラットな編集風イラスト

図3：ハーネスはモデル能力を、観測可能で、権限を持ち、Artifact中心の仕事のループへ変える。

4つの具体例

1. コーディングissueからパッチ、そしてQA Artifactへ

ユーザーがGitHub issueをMCPlatoに渡し、修正を依頼したとします。チャットだけの流れでは、アシスタントはいきなり提案に飛ぶかもしれません。ハーネスの流れでは、タスクは段階化された仕事になります。

1. issueとリポジトリの文脈を読む。
2. スコープを限定した計画を起草する。
3. 変更がリスクを伴うなら、編集前に確認する。
4. パッチを作成する。
5. 合意済みのチェックを実行する。
6. 変更ファイル、テスト出力、未解決リスク、レビュー用メモを含むQA Artifactを作る。

Claudeの行動と確認のバランスは、この流れによく合います。エージェントはissueを読む前に不要な質問をすべきではありませんが、広範または破壊的な変更の前には止まるべきです。

2. 引用付きの定期調査ブリーフィング

週次の調査ブリーフィングは、1回限りの回答ではありません。承認済みソースを集め、重複を除き、先週と比較し、変化を要約し、具体的な主張すべてに引用を付け、レポートを届ける反復ループです。MCPlatoのScheduled TasksとArtifactsは出力を永続化し、channelsは配信を非同期にし、Skillsは形式を再利用可能にします。

ソースリストとブリーフィングArtifactをワークスペースが一緒に保持できるとき、情報源を引用せよというプロンプトレベルの指示は、より価値を持ちます。

3. ブラウザと文書のワークフロー

ある財務チームが、Webポータルからレポートをダウンロードし、スプレッドシートと結合して月次サマリーを作る必要があるとします。良いエージェントは、あらゆるWebサイトへ万能にアクセスできると主張すべきではありません。ログイン境界を尊重し、MFAはユーザーに処理してもらい、エクスポートやAPIが存在するかを調べ、承認済みで再現可能な手順だけを自動化し、ファイル数を検証し、例外レポートを作るべきです。

これが「AIがブラウザを使える」と「AIが制御されたブラウザ／文書ループの中で運用できる」の違いです。

4. リスクの高い操作の承認

エージェントが顧客向けメールを起草したり、本番データを変更するコマンドを準備したり、フォルダ削除を提案したりするとします。モデルは指示を理解しているかもしれませんが、理解は権限ではありません。ハーネスはそのステップを承認チェックポイントに変えるべきです。意図する操作、予想される影響、ロールバック計画、証拠を示し、そこで待つのです。

ここでは、安全性と生産性が互いに補強し合います。ユーザーは読み取り専用の各ステップで速度を落とす必要はありません。一方で、不可逆または外部向けの操作の前には、明確なゲートが必要です。

ビルダーにとっての意味

AIプロダクトのビルダーにとって、Claudeシステムプロンプトのリリースノートは有用な設計シグナルです。「どのモデルが最も賢いか」だけを問うべきではありません。次の問いも必要です。

• モデルは自分がどの環境で動いていると考えているのか。
• プロダクトは、権限を曖昧にせずにツールを公開できるか。
• ワークフローは状態を失わず、時間をまたいで継続できるか。
• ユーザーは何が起きたかを検査できるか。
• 最終結果はトランスクリプトではなくArtifactとして残せるか。
• システムは、質問しすぎたり自由に動きすぎたりせず、適切な瞬間に停止できるか。

答えは、より長いシステムプロンプトだけからは出てきません。プロンプトは振る舞いを記述できます。しかし、その振る舞いを信頼できるものにする操作面は、プロダクトが提供しなければなりません。

これがハーネス時代です。モデルはより有能になります。しかし能力は、状態、ツール、復旧、承認、Artifactに囲まれて初めて実用的になります。

結論

Claude Fable 5のシステムプロンプトのスナップショットが興味深いのは、それがモデル能力の先を指しているからです。現代のモデルが、どのような環境に住む準備をされているのかを示しています。フロンティアはもはや「よりよいチャット」だけではありません。状態を持ち、ツールを理解し、権限で制御され、引用に注意を払い、復旧可能で、Artifact中心のエージェント作業です。

MCPlatoはその方向に向けて作られています。Spriteによる調整、Wands、Artifacts、再利用可能なSkills、スケジュールされた作業、channels、ローカルファーストのワークスペース状態、承認ゲートは、モデルの周囲に置かれた飾りではありません。強いモデルを、実際の仕事で役に立つ参加者にするための運用面です。

モデルは今もエンジンです。ハーネスは、そのエンジンを人が操縦し、点検し、修理し、信頼できる乗り物に変えるものです。

参考文献

1. Anthropic docs, System Prompts release notes.
2. Anthropic docs, Introducing Claude Fable 5 and Claude Mythos 5.