GPT-6の長時間タスク：エージェントを有益に前進させる方法

GPT-6 Astraは長期間のプロジェクトを進められますが、合格成果に近づいている間だけ、長時間実行に意味があります。具体的な中間目標、進捗を証明する方法、中断後に再開できる保存状態を渡します。意味のある段階を終えてから範囲を広げましょう。

Webサイト、調査資料、リポジトリ移行、複数文書の成果物で重要な考え方です。どれも核心の要求を解決せずに数時間動く可能性があります。最新の作業が最終成果を使いやすくしているかを問う必要があります。

出典: Matt Shumerのレビュー; Codex issue #43193; OpenAI公開発表。2026年9月7日確認。結果や体験は本文で各著者に帰属させています。

初期体験が示すこと

Matt ShumerのAstra評価では、細部に入り込んで大きなプロジェクトの進歩が鈍る様子が説明されています。調整役を置く構成が方向維持に役立ちましたが、長時間の自律作業は未解決だとも認めています。

Codexの調整と指示遵守に関する公開issueには、大量消費と繰り返しのプロセス失敗が記されています。個人の報告で失敗率ではありませんが、活動量を進捗と混同してはいけない例です。

前の確認地点から何が変わったかを見る習慣が有効です。どの受け入れ条件も進んでいないなら、時間やエージェントを増やす前に計画を確認します。

中断の種類を見分ける

判断が必要、ツール故障、アプリによる終了、作業の逸脱など、止まる理由はさまざまです。対処も異なります。「続けて」を繰り返しても、足りないファイルや矛盾する指示は解決しにくいものです。

OpenAIの GPT-6ガイドは、追加質問をしやすい点と、アクセスできるファイルの指示に敏感な点を挙げています。ターン途中の指示と非同期ツールもありますが、アプリの調整を助ける機能であり、任意のセッションが無期限に動く保証ではありません。

ある初期の文書レビュー相談は、チェックポイントや調整役があっても停止した経験を述べています。単独の体験ですが、保存地点は進捗を保つだけで、スケジューラーを提供したり停止環境を直したりするわけではない、という限界を示します。

実例形式：大量の文書を確認する

複数の文書から要件を比較する仕事を考えます。この例はバッチ化に適し、進行に合わせて範囲と指摘を確認できます。最終報告書をすぐ求めず、一覧作成から始めます。

段階1：存在する資料を把握する

各文書にID、版、日付、レビュー状態を付けます。読めないファイルと欠けた参照を記録します。答えるべき問いを合意し、判断に影響しない要約へ予算を使わないようにします。

段階2：代表的な一群を確認する

構造と複雑さが異なる数件を選び、ページ、節、資料ID付きの指摘を求めます。全件に展開する前に最初の一群をレビューします。欠陥のある抽出形式を数百回繰り返すと高くつきます。

段階3：バッチ間の整合性を見る

最終分析は文書間の主張、定義、要求を比べます。矛盾を記録し、どの版が優先か説明します。次のエージェントが原文でなく最初の要約を渡されたからといって、その要約を正本とみなしてはいけません。

段階4：完了を検証する

報告書を一覧と照合します。必要な文書は確認済み、理由付き対象外、または未処理のいずれかにします。完成部分が正確でも、対象漏れのある見栄えのよい報告書は未完成です。

文書ID | 版 | レビュー状態 | 指摘ファイル | 未解決事項
A-01   | 3  | 確認済み     | findings-a01 | なし
A-02   | 2  | ブロック中   | findings-a02 | 付録不足
A-03   | 1  | 待機         | -            | 未確認

これで代替セッションの開始地点が分かり、人も会話を全部再生せず対象範囲を監査できます。

保存地点に必要な情報を決める

有用なチェックポイントには仕事の状態だけでなく、その正しさの証拠も含まれます。「第2段階完了」だけでは、成果がどこにあるか分かりません。成果パス、入力版、完了した確認項目、残る差を記します。

コードなら版と試験結果、研究なら資料リンクと取得日、表計算なら入力ブックと適用変更を残します。他の人が成果を編集した場合は、古い仮定で進めないよう再開前に保存記録を更新します。

自然な区切りで保存します。1文ごとは管理負担が増え、数時間の終了時だけでは復旧が高くつきます。バッチ完了、検証済み変更、設計判断の確定などが適しています。

二重作業をせず再開する

保存された記録から現在の中間目標を再開してください。
変更前に今ある成果を確認してください。
完了した受け入れ条件を特定し、繰り返さないでください。
試行済みの外部操作は結果を確認してください。
次の未達条件から続けてください。
記録とファイルが食い違う場合、まず説明して整合させてください。

「試した」と「終えた」は異なります。ツールは記録を作成してからタイムアウトする場合があります。再試行前に宛先を読み、何が起きたか確かめます。ローカル成果なら、上書きせず途中成果を完成できないか見ます。

有用な進展に予算を結び付ける

限定的な試行で必要作業量を把握します。文書では確認済み資料と修正済み指摘、コードでは合格動作を追います。人の確認時間も含めます。大量出力に数時間の修正が必要なら、生産的とは限りません。

予算終盤の行動を指定します。成果を保存し、記録を更新し、次の判断を提示させます。トークン上限は追加支出を防ぎますが、有用な引き継ぎまでは保証しません。それもタスクの契約に含める必要があります。

複数の確認地点で改善が見えなくなったら、拡大を止めて原因を調べます。資料不足、より小さい目標、別ツール、人の判断が必要かもしれません。推論量を増やすのは選択肢の1つにすぎません。

最初の到達点を定める

「製品を全部作る」では暗黙の判断が多すぎます。動く経路1つ、検証済み分析、移行済み部品など、確認できる部分から始めます。モデルが仕事を理解したか分かる程度の実用性が必要です。

開始前に目標を決めます。中間結果のたびに変えると、修正と範囲拡大の区別が難しくなります。

Matt Shumerのレビュー準備の進捗画面です。チェック数は進行記録であり、独立した検証ではありません。

簡潔な作業記録を保つ

現在の目的、判断、ファイル、失敗案、未実施検証が必要です。長い会話はそれを取り出す最適な場所とは限りません。点検・修正できる短い記録を維持します。

現在の中間目標：
受け入れ基準：
成果と資料の場所：
確定した判断：
却下した方法と理由：
検証済み結果：
未解決問題：
次の操作：

意味のある成果や大きな方向変更の後に更新します。全ツール操作の物語にせず、次の判断を楽にするために使います。

停滞の3つの形を見分ける

失敗した方法を繰り返す

次の試行を正当化する新しい証拠を尋ねます。一時的なツール故障後の再試行は合理的でも、新情報なしの同じ思考は期待できません。失敗記録を保存し、次の会話で再発見させないようにします。

本筋が未完成なのに磨き込む

中心の経路が壊れたまま、言葉や見た目を磨くことがあります。受け入れ基準に戻り、最重要の未達要件を指定します。それを終えるまで装飾は後回しにします。

曖昧さを規模拡大で解消しようとする

不明確な依頼では、必要な選択を決めずに基盤を増やす場合があります。設計を変える最小の不確定事項を言わせ、広い書き換えを許す前に解決します。

中断からの復旧を用意する

OpenAIの Astra発表では、保護機能が正常な仕事を止めることもあると説明されています。通信、クラッシュ、要求変更でも止まります。途中の有用な成果を保存し、再開前に状態を確かめます。

再開時には実ファイルと作業記録を読み、終えた部分を特定し、次の条件へ進みます。外部操作が実施された可能性があるなら、繰り返す前に結果を調べます。

長いタスクのプロンプト

この中間目標を完成させてください：[具体的な成果]。
受け入れ条件：[観測可能な検証]。
材料とツール：[範囲]。
判断と確認済み進捗を短い記録に残してください。
細部の調整より未完成の必須要件を優先してください。
止まった場合は障害と必要な証拠を説明してください。
予算上限では使える成果と次の操作を返してください。

どのプロジェクトにも複数エージェントが必要なわけではありません。独立してレビューできる別成果がある役割だけ追加します。同じ成果を編集する場合など、調整自体が仕事になります。

進捗と費用を同時に測る

達成条件、人の修正、所要時間、総使用量を追います。「3経路の2つは合格、残りは再現する不具合、パッチはレビュー可能」のような記録なら判断できます。「まだ作業中」だけでは追加の1時間に価値があるか分かりません。

依頼、資料、草稿、レビュー判断を Ottermind でまとめます。小さな始め方はGPT-6の利用ガイド、統合側の予算管理は APIガイドを使ってください。

よくある質問

1つのプロンプトで完成しますか？

そうして始まった実例はありますが、環境、ツール、事前設定、後のレビューは重要です。具体的な中間目標から始めます。

どのくらい動かすべきですか？

仕事に合う予算を決め、意味のある地点で進捗を確認します。万能な実行時間はありません。

細部の改善ばかり続いたら？

最重要の未達条件を言い直し、それが終わるまで任意の仕上げを延期します。

遅くなったらエージェントを増やすべきですか？

先に原因を見ます。要件不足や誤った方針には、並列化より明確化・修正が必要です。

止まった実行は何を返すべきですか？

使える成果、確認済み結果、未解決点、具体的な次の操作です。完了手順を重複せずに再開できます。