Claude Fable 5の進捗報告をツール結果に照合させる指示文

進捗報告の捏造は、ツール結果との照合を指示すると消える

Claude Fable 5は数時間続く自律実行を任せられるモデルです。その分、人が画面を見ていない間に「テストは通りました」「3件の移行が終わりました」という報告が積み上がり、その真偽を誰も見ていない状況が生まれます。

Anthropicのプロンプティングガイドは、この対策を1つの指示文で示しています。進捗を報告する前に、各主張をこのセッションで得たツール結果と突き合わせさせる指示です。ガイドによると、捏造された状況報告を引き出すよう設計したタスクでも、この指示でほぼ消えました。

必要なのは、システムプロンプトへの数行の追加です。この記事では指示文の全文と、各文の役割、置き場所、照合が効く仕組みを作る側の工夫を順に扱います。

指示文の全文

ガイドが「Ground progress claims during long runs(長時間の実行で進捗の主張に根拠を持たせる)」の節で示す文面は次のとおりです。

Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.

3文でできています。それぞれが違う失敗を塞いでいます。

見落としやすいのは3文目の後半です。「検証済みなら、ためらわずに言い切る」まで指示に入っています。未検証を明記させるだけの指示だと、すべての報告に「おそらく」が付いて、どれが本当に終わった作業か読み分けられなくなります。確認した作業は断言させ、確認していない作業だけ明示させることで、報告の文面が検証の有無を表す信号になります。

「this session(このセッション)」という限定も効いています。以前のセッションの記憶や、モデルが推測した状態は根拠に数えません。この限定から読めるのは、前回の結果を引き継いだ主張も、今回のセッションで確かめ直すまでは根拠にならないという運用です。

システムプロンプトへの入れ方

指示文は英語のままシステムプロンプトに置けます。Messages APIでの最小の例は次のとおりです。

GROUNDING = (
    "Before reporting progress, audit each claim against a tool result "
    "from this session. Only report work you can point to evidence for; "
    "if something is not yet verified, say so explicitly. Report outcomes "
    "faithfully: if tests fail, say so with the output; if a step was "
    "skipped, say that; when something is done and verified, state it "
    "plainly without hedging."
)
 
response = client.messages.create(
    model="claude-fable-5",
    max_tokens=4096,
    system=GROUNDING,
    tools=tools,
    messages=messages,
)

ほかの指示と併用するなら、同じシステムプロンプトに段落を足します。ガイドは、チェックポイントでの停止条件や早期停止対策も、それぞれ短い文面で示しています。1つにまとめるときは、役割の違う段落を混ぜず、見出しか空行で分けておくと、あとで1つだけ外して効果を比べられます。

追加する前に、既存のプロンプトも見直します。ガイドは、旧モデル向けに作ったスキルや指示がFable 5には細かく指定しすぎで、出力の質を下げることがあると述べ、既定の挙動のほうがよければ古い指示を外すことを勧めています。報告の手順を長く書き込んだプロンプトがあるなら、3文の指示文と重複していないか確かめ、重複する部分から外していきます。

Claude Codeで使うなら、プロジェクトのCLAUDE.mdに同じ趣旨を書く方法があります。次は、上の指示文を作業環境に合わせて具体化した例です。

## 作業報告のルール
- 「通りました」「動きました」と書く前に、そのセッション内で実行した
  テストコマンドの出力を根拠にする
- 実行していないテストや、読んでいないファイルについては
  「未確認」と書く
- 失敗したテストは省略せず、失敗メッセージを添えて報告する

これはプロンプティングガイドの文面そのものではなく、趣旨を日本語の作業ルールに置き換えた例です。英語の原文と日本語化したルールのどちらが効くかは、同じタスクに2通りを当てて、報告と実際のログを読み比べると判断できます。

照合が機能したかを、ログで確かめる

指示文を入れただけでは、効いたかどうかが分かりません。ガイドの「ほぼ消えた」は、Anthropic側のテスト条件での結果です。自分のタスクで確かめるには、報告に出てきた主張とツール結果のログを突き合わせます。

最も手軽なのは、最終報告に「根拠にしたツール呼び出しのID」を書かせる運用です。Messages APIのツール呼び出しにはtool_useブロックごとにIDが付くので、ハーネス側で次のように存在確認できます。

import re
 
def cited_ids_exist(report: str, tool_use_ids: set[str]) -> list[str]:
    """報告に出てくる toolu_ 形式のIDのうち、ログに無いものを返す"""
    cited = set(re.findall(r"toolu_[A-Za-z0-9]+", report))
    return sorted(cited - tool_use_ids)

ログに存在しないIDが返れば、その主張は根拠が実在しません。この関数は、報告の文面を自作の運用ルールに沿って書かせたときに使う補助で、プロンプティングガイドが示す手法ではありません。IDの実在は確認できても、その呼び出しが主張の内容を支えているかまでは判定しないため、重要な主張は人の目か別のエージェントで読む前提で使います。

照合の対象は、報告の「完了」という語に絞ると運用しやすくなります。失敗を完了と書いていないか、実行していないテストを通ったと書いていないかの2点です。ログの読み方の一例は、長時間の計算を任せる運用を扱った長時間の科学計算を任せる記事にあります。照合先のテストを先に決めておく考え方が、そのまま使えます。

検証の担当を分ける場合との違い

ガイドは長時間実行の足場として、自己検証の明示も勧めています。別の、新しいコンテキストで動く検証用サブエージェントのほうが、自己批評より成績がよい傾向があるとされています。例として、一定の間隔で作業を仕様に照らして検証する指示が挙がっています。

この2つは役割が違います。

• 照合の指示(この記事の主題): 報告の文面を、モデル自身が持つツール結果に結びつける。追加のエージェントは要らない
• 検証サブエージェント: 作業の中身が仕様を満たすかを、作業した本人とは別のコンテキストで確かめる

照合の指示は、報告の誠実さを上げます。成果物の正しさを保証するものではありません。テストが通ったと正しく報告されても、テスト自体が仕様を満たしていなければ、仕様違反は残ります。報告の真偽と成果物の正しさを分けて考えると、どちらの対策を足すか迷いません。

照合の指示と並べて入れる、隣の指示文

同じガイドには、報告の質に間接的に効く指示文がほかにもあります。照合の指示と役割が重ならないものだけ挙げます。

境界を決める指示(State the boundaries)は、頼まれていない行動を減らします。ガイドは、頼まれていないメールの下書きや、念のためのgitブランチのバックアップを例に挙げています。問題の相談や考え事の段階では見立てを報告して止まること、状態を変えるコマンドの前に、その操作を裏づける証拠があるか確かめることが文面に入っています。照合の指示は起きたことを正確に報告させ、境界の指示は余計なことが起きる回数を減らします。

依頼の目的を先に書く型もあります(Give the reason)。ガイドは「何のために、誰のために、出力で何が可能になるか」を書くと、複数の作業が並ぶ長時間のエージェントで成績がよくなると説明しています。報告を誰がどう使うかを書き添えておくと、どこまで検証してから報告するかの目安がモデルに伝わりやすくなります。

委譲を多用する構成では、サブエージェントから返る報告も、親のエージェントが受け取る進捗報告のひとつです。ガイドの並列サブエージェントの指示は、独立した作業を任せつつ、方向がずれたら介入させる内容です。親だけでなくサブエージェント側のプロンプトにも、根拠を示す書き方を求める選択肢があります。

ハーネスが残りトークンの数をモデルに見せると、新しいセッションを勧めたり作業を畳もうとしたりすることがある、とガイドは述べています(context-budget concern)。報告の中身とは別の問題ですが、報告の質には響きます。畳む途中の報告で未完了の作業が完了扱いにならないよう、数の表示を避けるか、十分な余裕があると伝える一文を足します。

最後に、見落としやすい注意点があります。ガイドは、推論の内容を応答に書き出させる指示が拒否カテゴリreasoning_extractionに当たりうるとして、移行時にシステムプロンプトを見直すよう促しています。照合の指示が求めているのはツール結果という証拠の提示で、推論の書き出しではありません。ただ、「根拠を説明させる」ために文面を足していくときは、考えた過程の再現を求める言い回しになっていないか読み返してください。推論の中身を見たいときは、構造化されたthinkingブロックを読む方法がガイドで示されています。

ほかのFable 5向け指示との位置づけ

同じガイドには、長時間実行に関わる指示文が複数あります。症状から選ぶ早見表にすると次のとおりです。

最後の読みやすさの指示は、照合とは逆向きの課題です。照合の指示で報告が正確になっても、読み手が前提を知らなければ伝わりません。ガイドは、最終報告を「作業中の続き」ではなく、結果から始める読み直しの文章として書くよう促しています。

Fable 5.1とOpus 5へ移るとき

Fable 5.1のプロンプティングガイドは、Fable 5の既存プロンプトは変更なしでも十分動くはずだとしています。このガイドには、進捗の主張を照合させる節は載っていません。Fable 5で入れていた照合の指示は、外す理由が示されていないので、残したまま移行できます。外すかどうかは、移行後の報告ログで判断します。

Opus 5のガイドは、検証についての明示指示(「非自明な作業には最終検証の手順を入れる」「サブエージェントで検証する」など)は取り除くよう勧めています。過剰な検証が起き、トークンを無駄にするためです。照合の指示は検証の手順ではなく報告の規則なので同じ扱いになるかは、ガイドの文面からは決まりません。Opus 5へ移すときは、照合の指示を残した場合と外した場合で報告のログを比べ、未検証の項目がきちんと明示されているほうを選びます。

まとめ

進捗報告の虚偽は、モデルが悪意を持つ問題ではなく、確認していない作業を完了と書いてしまう癖の問題です。3文の指示文で、報告を「ツール結果で裏づけた主張」と「未検証」に分けさせられます。

導入後にやることは2つです。報告の主張を実行ログと突き合わせて、効果を自分のタスクで確かめること。そして、成果物の正しさは別の仕組み(検証サブエージェントやテスト)で守ることです。報告が正確になっても、成果物が正しいとは限りません。