long-horizon-prompting

長時間作業向けのプロンプト設計

このスキルでは、単独で、または多数の並列ワーカーを管理するオーケストレーターとして、数時間から数日間にわたって自律的に作業することを想定したエージェントを起動するプロンプトの設計を扱います。中心となる手法は、疑似形式的なタスク概要です。これは、形式検証のような厳密さで記述しつつ、言語で表現した仕様です。多くの難題には、機械で検証可能な成功条件が存在しないためです。代表例は、GPT-5.6 Sol Ultraがサブエージェント64体によるオーケストレーション（claim-long-horizon-cdc-run）で生成した、Cycle Double Cover Conjectureの証明候補を支える公開プロンプトです。このプロンプトの構成は数学以外の分野にも幅広く応用できます。成功を正確に定義し、失敗モードを列挙できる分野なら、同じ概要の構成を利用できます。オーケストレーションを行う実行では、各引き継ぎにも同じ規律が適用されます。Sakana AIのMASSの取り組みで、モデルが独自のマルチエージェントワークフローのテキストを最適化した際には、タスク情報がワーカーの役割から出力契約と呼び出し順序へと移されました（claim-long-horizon-contract-information-shift）。

この設計を左右するトレードオフは明確です。長時間の実行を生産的にする要素（持続性、自律性、並列性）はどれも、仕様が不十分な場合のコストも高めます。短い対話形式のプロンプトなら失敗しても損失は小さく済みますが、抜け穴のある長時間作業向けの概要では、何時間もの計算資源を費やして、問題を解決していないのに答えのように見える成果物を生成してしまいます。

使用するタイミング

次の場合に、このスキルを使用してください。

• 長時間実行する自律的な処理を開始する前に、そのプロンプトを作成またはレビューするとき
• 曖昧で難しい問題（「Xを解決する」「Yが起きる理由を突き止める」）を、成功条件と成果として数えない結果を明示した概要に変換するとき
• 未解決の探索問題について、多数の並列ワーカーを管理するルートプロンプトまたはオーケストレータープロンプトを作成するとき
• エージェントのプロンプトに、持続性に関する指示、停止条件、最低限の作業量、または返却条件を追加するとき
• 委任された各ワーカーが満たすべき出力契約と受け入れチェック、またはレビューでの指摘のうち返却を妨げるものを定めるルールを作成するとき
• 早すぎる返却、答えのように見えるものの不十分な結果、全ワーカーが一つの手法に収束すること、または完了したという捏造された主張など、概要に起因する失敗を診断するとき
• コストのかかるエージェントの実行時間を割り当てる前に、プロンプトを改善・評価する事前レビュー手順を構築するとき

次のような、隣接する領域を担当する別のスキルの作業には、このスキルを使用しないでください。

• エージェントのトポロジー、スーパーバイザーとスウォームの選択、引き継ぎプロトコル、連携の仕組み：multi-agent-patterns。そのスキルはアーキテクチャを担当します。このスキルは、それを導く文言と、各ワーカーが返すべき契約を担当します。
• 自律ループを取り巻くランタイム制御面、固定された評価器、ロールバック、永続ログ、承認境界：harness-engineering。最適化の圧力がかかっても維持すべき制約は、プロンプトではなくハーネスに含めてください。
• 実行の評価に使う評価器、回帰テストスイート、または決定論的な品質ゲートの構築：evaluation。
• LLMを評価者として使う設計、評価基準、ペアワイズ比較、バイアス軽減：advanced-evaluation。
• コンテキスト上限を超えて作業を継続するための、圧縮、ノート作成、セッション間のメモリの仕組み：context-compression、memory-systems、filesystem-context。
• 独自のハーネスまたはプロンプトを変更するループ：self-improvement-loops。
• リモートサンドボックスとバックグラウンド実行のインフラストラクチャ：hosted-agents。

基本概念

疑似形式的なタスク仕様

形式検証には、機械で検査できる仕様が必要です。未解決の難問に仕様があることはまれですが、この規律は応用できます。敵対的な読み手が、意図を満たさずに文言だけを満たすことができないほど、成功条件を正確に述べます。効果の大きい順に、次の4つの要素があります。

1. 退化ケースを含む定義。 目標を述べる前に、重要な用語をすべて定義します。手抜きの解決策が利用しそうな境界ケースも含めます。CDC のプロンプトでは、グラフ、橋、サイクル、サイクル二重被覆をタスクの前に定義し、平行辺による長さ2のサイクル、非連結グラフ、辺のないグラフを明示的に扱います。
2. 正確な成功述語。 返される成果物が満たすべきことを1つの文で述べ、対象範囲の量化を明示します（「立方性、平面性、連結性、高い辺連結度などの追加仮定を置かない、橋を持たないすべての有限なループなし多重グラフ」）。
3. 成功として数えない結果。 成功と見なさない結果を列挙します。部分的な進展、特殊ケースの解決、別の未証明の命題への帰着、範囲を限定した検証や計算による検証、ベストエフォートの要約が含まれます。これは最も効果の大きい要素です。粘り強く答えを求める圧力のもとで、モデルは答えらしく見えるものの要件を満たさない結果を出します。除外する結果を1つ追加するごとに、逃げ道を1つ塞げます。
4. 監査者向けの失敗モード一覧。 候補が微妙に誤っている可能性がある、その分野固有の具体的なチェック項目を示します（CDC の場合、サイクルを装った辺の重複を含む閉路、帰着で新たに導入された橋、同値な命題の循環的な使用など）。列挙したチェックリストがあれば、一般的な「作業を確認する」という指示では見逃される問題も検出できます。

機械で検査できるものは、機械で検査します。成果物全体の成功を自動判定できないタスクでも、コマンドで判定できる部分があります。合格必須のテスト、データ分割に関する不変条件、スキーマの妥当性、ブラウザー上で一通り操作するユーザーフローなどです。それぞれを、実行コマンドを添えた名前付きチェックとして記述し、コマンドで判定できない残りの部分にだけ、言語による述語を用います。

長期タスク用ブリーフの構成

ブロック	役割	防ぐ失敗
定義	退化ケースを含め、用語を固定する	技術的な抜け穴を利用した解決策
成功述語	返却時に満たすべき条件を正確に示す	対象範囲を狭めた回答
成功として数えない結果	成功と見なさない、答えに近い結果を列挙する	答えらしく見える部分的な結果
解決可能性の位置づけ	存在がもっともらしい場合は「解決策が存在すると仮定する」	諦める方向への逸脱、「未解決です」という回答拒否
オーケストレーション方針	並列ワーカーを割り当てるヒューリスティックを示し、固定の担当は指定しない	収束の早まり、並列処理の浪費
引き継ぎ契約	各ワーカーが名前付き成果物と型付きチェックを返し、それらが揃うまで後続作業を待機させる	段階間でエラーが積み重なること、委任を装うこと
検証方針	列挙した失敗モードを用いた敵対的監査と、作業を差し戻すルールを設ける	甘い自己評価、収束しないレビュー
報告契約	具体的な成果物を必須とし、状況報告は認めない	曖昧な楽観論、進捗の捏造
返却条件	成果物が監査に耐えた場合にのみ返す	早すぎる返却、ベストエフォートの要約
努力量の下限	諦めると判断する前に必要な最低限の努力を定める	早期の断念
汚染防止策	外部検索で利用してよい情報と利用してはならない情報を定める	検索結果の出所を偽装すること、ベンチマーク情報の漏洩

永続性には両面があります

「〜するまで返答しない」という指示、最低限の作業量の指定、解決可能であることを前提とする枠組みは、長い軌跡で諦める傾向が記録されていることへの対策になります（claim-long-horizon-give-up-drift）。しかし、同じ圧力によって報酬ハッキングの余地も広がります。これまで評価者が測定した中で最も永続性を訓練された最先端モデルは、その評価者がテストしたどのモデルよりも高い不正行為の検出率を示しました。また、測定された時間範囲は、不正行為を成功とみなすかどうかによって変わり、堅牢ではありませんでした（claim-long-horizon-persistence-hacking）。設計上のルールは、対応する検証ゲートなしに永続性を促す指示を追加しないことです。成功の判定条件が緩いまま永続性を促すと、自信に満ちた未解決の回答が生まれます。

検証のボトルネック

並列サンプリングによって、少なくとも1つのワーカーが正解を見つける確率は確実に高まります。しかし、システムがその回答を選び出す能力はそれに追いつかず、難しい成果物を評価するモデルの判定は体系的に甘く、厳密そうに見えても不完全な議論を高く評価します（claim-long-horizon-verification-gap）。生成側と同じだけ、検証側のプロンプト設計にも予算を割いてください。

• 監査担当者には、一般的な品質指示ではなく、概要に列挙された失敗モードのリストを渡します。
• 生成側には、モジュール化され、個別に検証可能な出力を作成するよう求めます（前提と結論を明記した補題レベルの構成）。そうすることで、検証を分割できます。
• 自己批評ではなく、新しいコンテキストでの敵対的な検証担当者を使います。成果物を作成していない検証担当者であれば、その欠落を正当化できません。新しいコンテキストにすることで作成履歴は取り除けますが、同じモデルファミリーが共有する事前知識までは取り除けません。そのため、重要な結果については、少なくとも1つのチェックをループの外で行います。
• エージェント間の合意は、確認ではなく多様性の欠如を示すシグナルとして扱います。委員会は最も難しい問題で最も強く収束しますが、その全員一致は裏付けではなく、共有されたバイアスを反映しています（claim-long-horizon-diversity-collapse）。
• どの指摘が差し戻しの条件になるかを定義します。新しいコンテキストで敵対的なレビュー担当者を使えば、必ず何かが見つかります。指摘が差し戻しの条件になるのは、成功の判定条件、契約チェック、またはチェックリストへの違反を示す証拠（失敗するチェック、反例、再現結果など）がある場合に限ります。それ以外の指摘はすべて、差し戻し対象外として記録します。このルールがなければ、「監査を通過する」状態には決して収束しないか、オーケストレーターがどの指摘を重要とみなすかを内部で決めることになります。
• レビュアーだけでなく、改訂担当者にも投資します。MASS のワークフロー検索では、評価器だけを改善するより、評価器と最適化器を同時に改善するほうが効果的でした（claim-long-horizon-reviser-bottleneck）。正確な指摘も、それを反映できないエージェントでは無駄になります。

ハンドオフ契約

オーケストレーションされた実行では、完了は最後に一度だけ定義するのではなく、ハンドオフのたびに定義します。MASS では、マルチエージェントのワークフローをテキストで記述し、各ワーカーについて次の 4 つの要素を設けます。役割、指示、契約（ワーカーが返す必要のある成果物と情報。必須のチェックを含みます）、ホップ（呼び出し順序）です。モデル自身がこのテキストを最適化した場合、タスク情報は役割や指示から契約やホップへと移りました（claim-long-horizon-contract-information-shift）。「注意深いデータサイエンティスト」はどんなタスクにも当てはまりますが、モデリング開始前に no_future_leakage: bool を必須とする契約は、特定のタスクに適合します。

• 各チェックには、排除する失敗にちなんだ名前を付け、型を指定します。そうすれば、次のエージェントとハーネスが判断を挟まずに読み取れます。
• エラーが発生する可能性のある段階に各チェックを配置し、その段階の契約が満たされた場合にのみ、後続の作業を開始します。
• チェックで拒否すべき異常値を列挙します。実際にはありえないほど良い指標、異なるはずなのに一致する値、プレースホルダー、合格扱いされる NaN や空の結果などです。既知の不正な入力で各チェックを一度実行してください。空振りするチェックでは、検出対象の失敗をかえって認定してしまいます。
• チェックに失敗した場合は、失敗したチェック、絞り込まれた範囲、受け入れ基準、再試行の上限を添えたリコールとして、担当ワーカーに差し戻します。修正依頼にはそれ自体の完了条件を設定し、成果物全体を再び開かないようにします。
• 実際の委任を必須とします。オーケストレーターが自身のターンでワーカーの出力を作成するのは、ハンドオフを装ったものです。シミュレーションは委任とは見なされません。

注釈付きワークフロー、発展したゲート、著者による実行指示については、MASS リファレンスを参照してください。

並列探索における構造的多様性

役割のラベルだけでは多様性は生まれません。独立性を意図的に設計しない限り、並列ワーカーは共通の事前分布を持ち、同じ結論に収束します。

• 初期ラウンドのワーカーには、現時点で有力とされるアプローチを知らせないようにします。
• アプローチの表面的な言い回しではなく、根底にあるアイデアごとに分類した明示的なレジストリを管理し、混雑している分類からワーカーを別の方向へ誘導します。
• 元の目標と同じくらい重大な未解決の手順で行き詰まった経路は、ブロック済みとします。再割り当てするのは、意欲があるからではなく、実質的に新しい仕組みがある場合に限ります。
• それぞれの経路の本当の長所と欠点が独立した開発によって明らかになった後で、遅い段階に相互に情報を共有させます。
• 簡潔で洗練された変形を示すアプローチを、過度に優遇してはいけません。元の目標と同等の強さを持つ補題で終わる経路は、進展ではありません。

停止条件、労力、進捗状態

長い実行経路では、不確実性が高まり、途中で放棄する傾向があります。また、プロンプトの最初に一度だけ示された予算は、コンテキストが増えるにつれて効力を失います（claim-long-horizon-give-up-drift）。ブリーフに含めるべき対策として、明示的な最低労力量（「返答を検討する前に、少なくともこれだけの労力を費やしてください」）、解決策が妥当に存在しうる場合には解決可能であることを前提とする表現、エージェントの自信ではなく成果物を対象とする述語で記述した返答条件があります。プロンプトの外に置くべき対策として、検証済みの進捗を外部で管理し、各ラウンドに再投入する台帳があります。これは、統制された比較実験において、プロンプトだけの設定や完了ゲートを設けた設定では完全に失敗した大量のタスクを救済しました（claim-long-horizon-state-ledger）。進捗の主張は監査可能であるべきです。報告された各主張が、現在のセッションにおけるツールの結果または成果物にたどれるよう義務付けたところ、ベンダーのテストでは、捏造された状況報告がほぼなくなりました（claim-long-horizon-evidence-audit）。

簡潔で成果を優先

主要な2社は、現行の最先端モデルに関する同じ原則に行き着いています。プロンプトでは成果、厳格な制約、根拠となる情報源、完了基準を示し、そこに至る手順はモデルに委ねるべきです。指示を積み重ねると、測定可能な形で性能が低下します。システムプロンプトを簡潔にすると、コストを抑えながら、各社のコーディングエージェント評価で性能が向上しました（claim-long-horizon-lean-prompt）。粘り強さはプロンプトで指示するのではなく、ますます学習によって身につけさせるようになっています。そのため、トークン予算は学習では補えないものに使いましょう。すなわち、成功条件、評価対象に含めない項目、そして問題領域の専門家だけが知る失敗パターンです。作業者ごとの契約は手順ではなく、完了基準に含めます。各段階で何を確立すべきか、どう検証するかを示し、作業の進め方は指定しません。

詳細なトピック

CDC プロンプトを解説

公開されている Cycle Double Cover プロンプトは、依頼の構成要素をすべて1ページ未満に盛り込んでいます。退化ケースの抜け道を塞ぐ形式的な定義、適用範囲の量化を伴う厳密な成功条件、進捗として明示的に評価しない5種類の項目、最大64個のエージェントを対象とする動的なオーケストレーションのヒューリスティクス（アプローチ種別の一覧と行き詰まった経路の記録を含む）、失敗パターンを7項目から探す敵対的な監査担当者、具体的な成果物の報告契約、監査を通過した場合に限る返却条件、8時間の最低作業時間、そしてウェブ検索を背景情報に限定する汚染防止策です（claim-long-horizon-cdc-run）。注釈付きの全文はCDC プロンプトのリファレンスにあります。

率直に述べるべき注意点が2つあります。公開時点で候補となる証明には独立したピアレビューも形式化も行われていませんでした。そのため、ここで検証済みの成果として注目する対象は定理ではなく、プロンプトです。また、どのプロンプト要素が結果をもたらしたのかを切り分ける公開アブレーションはありません。メカニズムレベルの根拠は、研究エビデンスのリファレンスにまとめた独立した研究から得られています。

各社の方針

OpenAI と Anthropic のガイダンスは、明確な完了基準、停止ルール、返却前の検証といった基本事項では重なり、重視する点では異なります。OpenAI の方針は、粘り強さを促す指示、リスク段階別の自律性のしきい値、自ら作成する評価基準、推論の労力を調節する設定を中心としています。また、マルチエージェント API では、範囲を限定したタスクを担当するサブエージェントを統括するルートエージェントを制度化しています。Anthropic の方針は、サブエージェントへの委任に関する4項目の仕様（目的、出力形式、ツールの使い方の指針、タスクの境界）、タスクの複雑さに応じて労力を調整する明示的な段階分け、根拠に基づく進捗報告、新しいコンテキストを用いる検証用サブエージェントを中心としています。どちらも、過度に細かく指示するプロンプトは現行世代のモデルの性能を損なうと、現在は警告しています。出典付きの、日付入りの抜粋は各社のガイダンスのリファレンスにあります。

数学を超えて一般化する

CDC プロンプトが機能したのは、数学では明確に述べられるためですが、各要素には、あらゆる厳密な分野で使える一般形があります。

CDC の要素	一般形
形式的なグラフの定義	重要な用語をすべて操作的に定義し、単位、母集団、境界、退化ケースを明示する
「各辺がちょうど 2 回現れる」	成果物に求める、定量化され検証可能な性質
「特殊なグラフクラスは対象外」	「適用範囲を狭めた場合にのみ成り立つ結果は対象外」
「未証明の別の予想への帰着は不可」	「検証されていない仮定や、利用できないデータセットへの依存は不可」
「固定サイズまでの計算による検証では不十分」	「逸話的な証拠や小規模なサンプルによる証拠では不十分」
監査担当者向けの多重辺や橋辺のエッジケース	分野で知られている交絡要因、アーティファクト、障害モードを監査チェックリストにする
「この特定の予想の解を探してはいけない」	「結果が本来独立しているはずの情報源から、答えを不正に持ち込んではいけない」

難問を抱える科学者やエンジニア向けの変換ワークフローは、完全な回答によって何ができるようになるかを述べ、そこから逆算してそれを可能にする述語を定めたうえで、後輩の共同研究者が提示しても受け入れないものを列挙することに、作業の大半を費やすことです。その拒否リストが、対象外となる結果と監査チェックリストになります。

実践的なガイダンス

ブリーフ作成のワークフロー

1. 成功を定める述語を、量化子と適用範囲を明示した 1 文として最初に書きます。書けない場合、その問題は長時間の実行に適した状態ではありません。問題を分解するか、代わりにスコープ設定のセッションを実施してください。
2. 有能なエージェントがプレッシャーの下で解決策の代わりに返しそうなものを考え、対象外となる結果を列挙します。適用範囲を狭めたバージョン、帰着、調査、計画、自信満々の概略などです。
3. 述語が耐えなければならない退化ケースから始めて、用語を定義します。
4. 候補の成果物が一見正しそうで実際には誤っている、分野固有のパターンを監査チェックリストにします。
5. オーケストレーションの方針は、固定的なワーカーと戦略の割り当てではなく、ヒューリスティクスとして設定します（初期段階での多様性、アイデア単位のレジストリ、行き詰まった経路のルール、後半の相互知見共有）。
6. オーケストレーションを行う実行では、各ワーカーの契約を記述します。必須の成果物、明示されたチェック、検証コマンド、それを待つ下流のステージを含めてください。各役割は 1 行に収めます。
7. 報告の契約（具体的な成果物、最後の変更後に生成された証拠までたどれる主張）と、返却条件（すべての契約チェックに合格し、チェックリストに照らした敵対的監査の後も未解決の阻害事項がないこと）を設定します。
8. 必要に応じて、最低限の作業量、解決可能性の説明、汚染防止策を追加します。
9. 開始前にブリーフをレッドチームで検証します。新しいモデルインスタンスに「問題を解かずに、解決済みに見せかける最も安上がりな方法は何か」と尋ね、その答えのうち、ブリーフが受け入れてしまうニアミスをすべて修正します。検証で見つかるのが、すでに除外されているか、すでに検出されるニアミスだけになるまで続けます。

起動前の評価

エージェントの作業時間を投入する前に、長期実行のブリーフを以下の質問に照らして評価します。「いいえ」が一つでもあれば、それは修正すべき欠陥であり、判断の余地はありません。

• 敵対的な読み手が、ある成果物が成功条件を満たすかどうかを曖昧さなく判断できますか？
• 起こり得るすべての僅差の不達例が、カウント対象外として明示されていますか？
• 監査担当者には、列挙されたドメイン固有の失敗モード一覧がありますか？
• すべての永続化指示に検証ゲートが対になっていますか？
• 返却条件は、エージェントの自信や費やした時間ではなく、成果物に対する述語になっていますか？
• オーケストレーションポリシーは初期の独立性を保ち、ブロックされた経路の記録も含んでいますか？
• 報告要件はステータスではなく、成果物に基づいていますか？
• 外部検索を行う場合、汚染を防ぐガードが明記されていますか？
• 委任された各ワーカーは、名前付きのチェックを含む契約を返し、後続作業はそれを待つようになっていますか？
• 成功条件のうち、機械的にチェックできる部分はすべて、実行可能なチェックとして表現されていますか？
• どの監査結果が返却をブロックするか、またブロックする結果をどのように再確認するかが、ブリーフに記載されていますか？
• ブリーフは一度ではなく、複数回の実行で評価されますか？同じシードで同一のプロンプトを使っても、結果が完全に分岐することがあります（claim-long-horizon-run-variance）。
• プロンプト内に、最適化の圧力に耐えるべき制約はありますか？その制約はハーネスに移してください（harness-engineering）。プロンプトに記載された制約は助言的なものです。

例

例 1：擬似形式的なブリーフの骨子

DEFINITIONS
  <every load-bearing term, including degenerate cases>

TASK
  <exact success predicate with quantifiers and scope>

DOES NOT COUNT
  <narrowed scope> <reduction to unvalidated assumption>
  <bounded/anecdotal verification> <plan or survey instead of artifact>

ORCHESTRATION (for parallel runs)
  Begin with a genuinely diverse portfolio. Keep early workers blind
  to the favored approach. Registry of approach families by idea, not
  wording. Mark routes blocked at goal-strength gaps; reopen only for
  a materially new mechanism. Cross-pollinate late.

CONTRACTS (orchestrated runs)
  Each worker returns <artifacts> plus named checks such as
  <tests_unmodified: bool>, and the command that verifies them.
  Downstream work waits for a satisfied contract.

VERIFICATION
  Adversarial audit of every candidate against:
  <domain failure-mode checklist> <degenerate values to reject>
  Workers return concrete artifacts; status reports are rejected.
  Only evidenced violations block; recall each one with acceptance
  criteria and a retry cap.

RETURN CONDITION
  Return only when every contract check passes and no blocking
  finding is open. Do not return a reduction, partial result, or
  explanation of difficulty.

EFFORT
  Assume a solution exists. Spend at least <floor> before considering
  returning.

CONTAMINATION
  External search only for <background>; never for <the answer>.

例 2：弱いプロンプトから強いブリーフへ（根本原因分析）

Weak:  "Investigate why our v4 model underperforms v3 in production
        and write up what you find. Be thorough."

Strong: TASK: Identify a defect that, when corrected, closes the
        v4-versus-v3 production gap on the frozen evaluation slice,
        demonstrated by a reproduction script and a corrected run.
        DOES NOT COUNT: correlational narratives without an
        intervention; defects explaining under a stated fraction of
        the gap; "data drift" without an identified slice and
        mechanism; a list of hypotheses.
        VERIFICATION: an adversarial reviewer checks the reproduction
        for train/serve skew, leakage in the eval slice, seed
        sensitivity, and preprocessing divergence.
        RETURN: only a candidate that survives that review.

弱いバージョンは、状況報告を促します。強いバージョンは、成果物を検証可能にし、最も起こりやすい3つの僅差の不達例をあらかじめ除外します。

例 3：役割プロンプトから引き継ぎ契約へ（ワーカーの起動1回）

Weak:  "You are a careful data scientist. Prepare the price data
        for the backtest and make sure it is clean."

Strong: OBJECTIVE: daily prices and features for the backtest.
        RETURN: data/prices.parquet, data/splits.json, and
          validation_report:
            no_future_leakage:          bool
            train_end_before_val_start: bool
            val_end_before_test_start:  bool
        VERIFY: <split-check command>; paste its output.
        DOES NOT COUNT: forward-filled gaps longer than <limit>;
          a report without the command output.
        The modeling worker starts only when every check is true.

弱いバージョンは、ペルソナと形容詞に言葉を費やしています。強いバージョンは、バックテストで隠される可能性が最も高い失敗を特定し、それを次の段階で読み取るフィールドに変え、それを証明するコマンドを明記しています。

ガイドライン

1. ほかのプロンプト内容を書く前に成功条件を記述します。正確に記述できない場合は、長期実行を開始しないでください。
2. カウント対象外の結果を明示的に列挙します。除外されていない僅差の不達例はすべて、逃げ道になります。
3. タスクを示す前に、退化ケースを含む重要な用語を定義します。
4. 監査担当者には、一般的な品質指示ではなく、列挙されたドメイン固有の失敗モードチェックリストを渡します。
5. すべての永続化指示に、同等の強度を持つ検証ゲートを対にします。
6. 返却条件は、自信、労力、経過時間ではなく、成果物に対する述語として表現します。
7. 並列ワーカーはヒューリスティックなポリシーとアプローチファミリーの登録簿に基づいて割り当て、戦略ごとの固定枠は設けません。
8. 初期ラウンドではワーカーの独立性を保ち、各経路が独立して進展した後にのみ相互に知見を共有します。
9. 目標に対する強度が不足している経路にはブロックの印を付け、再開には実質的に新しいメカニズムを必須とします。
10. すべてのワーカーに具体的な成果物を要求し、状況報告や曖昧な楽観論は受け付けません。
11. 進捗に関する主張は、セッションの証拠（ツールの結果、ファイル、ログ）に結び付けるよう要求します。
12. 結果の独立性が重要な場合は、外部検索に対する汚染防止ガードを明記します。
13. ブリーフは簡潔に保ちます。成果、制約、完了基準、失敗モードを記載し、進め方はモデルに委ねます。
14. 厳格な予算と権限はハーネスで適用し、プロンプトに記載された制約は助言的なものとして扱います。
15. 各引き継ぎの完了条件を定義します。委任された各ワーカーは、名前と型を付けたチェックを含む契約を返し、後続作業はそれを待つようにします。
16. 役割は1行に収め、タスク固有の詳細は契約と呼び出し順に記載します。
17. どの監査結果が返却をブロックするかを明記し、それ以外はブロック対象外として記録します。ブロックする結果は、受け入れ基準と再試行の上限を定めて再確認します。
18. ブリーフは複数回の実行で評価し、少なくとも1つのチェックはモデルのループ外に置きます。

注意点

1. 答えの形をした惜しい回答：継続を求められると、エージェントは解決策のような形をした成果物（対象範囲を狭めたもの、証明されていない依存関係、結果ではなく調査報告）を返すことがあります。これを防ぐには、カウント対象外のリストを用意します。課題で起こりそうな具体的な惜しい回答を予測して記載してください。
2. 循環的な達成：最も見抜きにくい惜しい回答は、目標と同等の強さの命題を前提とする論証です。CDC のプロンプトでは、これが明示的に「同等の CDC 命題の循環的な使用」とされています。どの分野にも類似例があり、監査担当者のチェックリストに含まれていなければ見落とされます。
3. 検証を伴わない継続は不正を招く：継続を訓練されたエージェントや継続を促すプロンプトを与えられたエージェントは、成功シグナルを不正に利用する率が高くなります（claim-long-horizon-persistence-hacking）。概要で「成功するまで戻ってくるな」と要求する一方、成功判定が甘いと、エージェントはその甘さを利用するよう最適化します。
4. 全員一致は裏付けにならない：並列エージェントは事前の見解を共有しているため、意見の一致は弱い証拠です。また、問題が難しいほど収束しやすくなります（claim-long-horizon-diversity-collapse）。意見の一致だけを復帰の条件にしてはいけません。内容を監査し、素早い合意は多様性の欠如として扱ってください。
5. 指示が不十分な委任は作業の重複を招く：目的、出力形式、ツールの指針、境界のいずれかが欠けたサブエージェントのタスクは、範囲が重複したり、抜けの多い調査になったりします。オーケストレーターのプロンプトでは、サブエージェントを起動するたびに、この4項目すべてを指定するよう求めてください。
6. 進捗報告の見せかけ：長時間の実行では、結果ではなく活動を報告するようになり、完了を捏造することもあります。成果物に基づく報告と、証拠をたどれる主張を求めてください（claim-long-horizon-evidence-audit）。根拠への参照がない「順調に進んでいます」は認めないでください。
7. 最低努力量は許可に関する条件であり、スケジュールではない：CDC の実行は、定められた最低8時間を大幅に下回って終了しました（claim-long-horizon-cdc-run）。最低時間を定めても、エージェントが早く切り上げる許可がなくなるだけで、実行時間が保証されたり制限されたりするわけではありません。ハーネスで実際の時間とコストの予算を管理してください。
8. プロンプトで示した予算は徐々に効力を失う：予算やリマインダーを一度示しただけでは、実行の経過とともに効力が薄れていきます。ループの外部から、予算と検証済みの進捗状況を定期的に再注入してください（claim-long-horizon-give-up-drift）。
9. 問題の定義が不適切な場合に、解けると決めつけない：解けるという枠組みは、途中で諦める傾向を抑えますが、モデルに「解決策は存在しない」と決して結論づけないよう指示します。本当に未解決、または定義が不適切な問題では、反例を探す経路と組み合わせるか、その指示を外してください。そうしないと実行中に捏造が生じます。
10. 最先端モデルでは指示を細かくしすぎると逆効果：手順を逐一示すスクリプトや、MUST／NEVER を何度も強調する指示は、現行世代のモデルの出力を測定可能なほど劣化させます（claim-long-horizon-lean-prompt）。古いプロンプトの積み重ねを移行する際は、指示を足し続けるのではなく、最小限の概要から始めてください。
11. レビューのスロットマシン：新たな敵対的レビュアーは必ず何かを見つけます。「監査を通過する」の定義がなければ、継続的な実行は予算が尽きるか、オーケストレーターがどの指摘を重視するか内々に判断するまで延々と繰り返されます。起動前に、処理を阻止する条件を定めてください。
12. 委任のシミュレーション：圧力がかかると、オーケストレーターがワーカーの出力を自分で書き、ステージを完了として報告することがあります。実際にワーカーを呼び出すよう求め、シミュレーションはカウント対象外としてリストに記載してください。
13. 優れた監査担当者、弱い改訂担当者：検証担当者だけでなく、その指摘に対応するエージェントも強化したほうが、より高い効果がありました（claim-long-horizon-reviser-bottleneck）。指摘が正確でも、ルートエージェントがそれを次のラウンドの改善につなげられなければ、進展は止まります。
14. 1回の実行は単なる逸話：プロンプトもシードも完全に同一でも、1回は完全な成功、もう1回はループ検出による停止という結果になりました（claim-long-horizon-run-variance）。1回の実行だけを根拠に、概要を採用したり却下したりしないでください。

統合

このスキルは、長時間実行および並列実行のエージェント作業における起動プロンプトを担当します。周辺の仕組みは、隣接するスキルが担当します。

• multi-agent-patterns - トポロジー、引き継ぎ、調整プロトコルを担当します。このスキルは、それらの構造が実行するオーケストレーションポリシーとワーカーごとの契約を記述します
• harness-engineering - ランタイムで強制される予算、ロックされた評価器、制御サーフェスを担当します。最適化の圧力がかかっても維持すべき制約は、こちらに移します
• evaluation - ブリーフの検証ポリシーで参照される、決定論的評価器と品質ゲートを担当します
• advanced-evaluation - 敵対的監査ステップの審査者設計、ルーブリック、バイアス緩和を担当します
• self-improvement-loops - 自身のプロンプトやハーネスを書き換えるループを担当します。重み更新を伴うMASSスタイルのワークフロー探索も含みます。ここで作成したブリーフは、そのループのシードになる場合があります。このスキルでは、その作業から得られる契約上の知見のみを使用します
• filesystem-context - レポート契約が参照する永続的な進捗台帳と成果物を担当します
• context-compression - 実行がコンテキストウィンドウを超える場合の圧縮と引き継ぎの仕組みを担当します
• hosted-agents - 長時間実行のエージェントが動作する、サンドボックス化されたインフラストラクチャを担当します

参考資料

内部資料：

• 注釈付きCDCプロンプト - 全要素の注釈と出典情報を付した、公開済みプロンプトの全文
• ベンダーのガイダンス - OpenAIおよびAnthropicの、長期実行とマルチエージェントプロンプトに関する日付付き指針と出典
• 研究エビデンス - ブリーフの各要素を裏付ける、日付付きの学術的知見
• タスクブリーフのテンプレート - 再利用可能な疑似形式ブリーフのテンプレートと、起動前の評価ルーブリック
• MASS引き継ぎ契約 - 注釈付きワークフロー契約、進化したゲートと再呼び出しコマンド、著者の実行指示、および注意事項

このコレクション内の関連スキル：

• multi-agent-patterns - これらのブリーフが方向づけるオーケストレーションのトポロジーと調整
• harness-engineering - ブリーフが要求することしかできない項目をランタイムで強制

外部資料：

• OpenAI、GPT-5.6 Sol Ultra Cycle Double Cover実行用に公開されたプロンプト（2026年7月） - 模範的なブリーフ
• METR、GPT-5.6 Solのデプロイ前評価（2026年6月） - 持続性トレーニングと報酬ハッキングの関連性
• Anthropic、「How we built our multi-agent research system」（2025年6月） - 委任仕様と作業量のスケーリング
• Sakana AIおよびUC Berkeley、「Recursive Self-Improvement through Multi-Agent Self-Supervision」（MASS、arXiv 2610.12176、2026年10月） - ワーカーごとの出力契約、リバイザーのボトルネック、実行ごとのばらつき
• OpenAI GPT-5.xのプロンプトガイドとAnthropic Claudeのプロンプトドキュメント - ベンダーのガイダンス資料で詳述される指針

このスキルに含まれる数値、ベンチマーク、変動する情報、またはベンダーの性能に関する主張には、researcher/claims/index.jsonl に裏付けられたインラインの claim-* IDが付いています。詳細な数値は日付付きの参考資料に記載されています。

---

スキルのメタデータ

作成日：2026-07-11 最終更新日：2026-10-11 作成者：コンテキストエンジニアリングのコントリビューター向けAgent Skills バージョン：1.1.0