GPT-6 Astraのプロンプト設計｜長時間タスクを完了させる依頼例

GPT-6 Astraのプロンプトは長さより完了の定義が重要

GPT-6 Astraは、調査、アプリ操作、コーディング、文書や表の作成など、複数工程をまたぐ仕事を想定したモデルです。OpenAIは、曖昧さが結果を変えない場合は文脈から補い、重大な判断が必要な場合は焦点を絞って質問する性質を説明しています。また、追加要件や方向転換を受けても大きな目的を保持するよう改善したとしています（2026年9月時点、出典: openai.com）。

この性質を活かすには、作業方法を一手ずつ命令するより、次の4点を先に固定します。

最終的に受け取りたい成果物
守る必要がある制約と触ってよい範囲
人の判断が必要になったときの停止条件
完了を判定する検証項目と提示する証拠

例えば「競合を調べてレポートを作って」では、対象企業、期間、一次情報の優先、出典形式、ファイル形式が未定です。「公式料金ページを含む一次情報を優先して3社を比較し、更新日付きの表と推奨案をMarkdownで作る。料金を確認できない項目は推測せず不明と書く」とすれば、完成像と判断基準が共有されます。

関連記事：AIプロンプトとは？回答精度を高める書き方のコツと業務で使える例文集

長時間タスクのプロンプトに入れる6つの要素

長時間タスクの依頼を構成する6要素を、同じ重要度の部品として一覧できる図にする。

長時間タスクでは、目的だけでなく「範囲、権限、途中判断、検証」を同じ依頼に含めます。次の6要素を順番に埋めると、タスクの種類が変わっても再利用できます。

GiftXの2026年調査では、生成AI利用者のうち「毎回の指示・調整に手間がかかり、プロンプトが難しい」と答えた人が26.5%、「チャット相談止まりで自動化に進めない」と答えた人が25.7%でした（複数回答）。依頼を一度だけ巧みに書くのではなく、再利用できる項目へ分解することが実務上の課題です。

詳細な調査データは「ビジネス職生成AI活用実態調査（2026年版）」にてご覧ください。

要素	書く内容	短い例
1. 目的	なぜ行うか、誰が使うか	営業会議の判断を早くする
2. 成果物	形式、保存先、必要項目	比較表と推奨案をMarkdownで作る
3. 入力と範囲	参照元、対象期間、触る場所	指定URLと直近6か月の一次情報を使う
4. 権限境界	読取、変更、外部送信の可否	ファイル編集は可、公開と送信は不可
5. チェックポイント	いつ報告し、何を確認するか	構成確定後に一度進捗を示す
6. 完了条件	テスト、根拠、未解決事項	リンク確認と差分提示まで終えたら完了

1｜目的は成果物を使う場面まで書く

「市場調査をする」だけでは、網羅性を優先するのか、すぐ決められる短い結論を優先するのか判断できません。「来週の企画会議で採否を決めるため」のように利用場面を書くと、必要な粒度を選びやすくなります。

目的には背景を詰め込みすぎず、誰が何を決めるための仕事かを1〜2文で示します。経緯の記録が必要なら、本文ではなく参照資料として分けます。

2｜成果物は名前、形式、構成を指定する

成果物は「レポート」だけで終わらせず、ファイル形式と必須項目を示します。例えば「Markdown 1ファイル。要約、比較表、推奨案、出典一覧の順」と指定すれば、完成後の整形作業を減らせます。

既存テンプレートがある場合は、文章で説明し直すより、そのファイルを参照対象に含めます。OpenAIはAstraについて、既存テンプレートや文体に沿った成果物作成を強みの一つに挙げています（2026年9月時点、出典: openai.com）。

3｜入力と作業範囲を分けて示す

入力は「参照してよい情報」、作業範囲は「変更してよい対象」です。両者を混ぜると、資料として渡したファイルまで編集対象と解釈される可能性があります。

リポジトリ作業なら、対象ディレクトリ、変更禁止ファイル、既存テストを変更してよいかを明示します。調査なら、対象企業、期間、一次情報を優先する条件、確認できない情報の扱いを書きます。

4｜権限境界は操作の種類で区切る

「慎重に作業して」では、何を止めるべきか決まりません。読取、ローカル変更、外部送信、公開、削除、購入や課金を分けて書きます。


許可する操作:

- 指定フォルダ内の読取と編集
- テストとビルドの実行

実行前に確認が必要:

- 新しい依存関係の追加
- 外部サービスへのデータ送信

実行しない操作:

- ファイル削除
- 本番公開
- 顧客へのメール送信

OpenAIは、Astraが許可された範囲を尊重し、CodexのAuto-Reviewによる拒否を回避しようとしなかった内部評価を公表しています。ただし、モデル側の性質だけに頼らず、実行環境の権限とプロンプトの両方で境界を固定します（2026年9月時点、出典: openai.com）。

5｜チェックポイントは人の判断が必要な場所に置く

毎工程で報告を求めると作業が細切れになり、逆に最後まで無確認だと手戻りが大きくなります。構成の確定、破壊的操作の直前、想定外の前提が見つかった時など、判断が結果を変える場所だけを確認点にします。

「30分ごとに報告」より、「調査対象が確定した時」「実装方針が2案に分かれた時」のように状態で指定するほうが実務に合います。返答を待たなくても進められる作業がある場合は、その部分だけ継続してよいと書きます。

6｜完了条件は検証結果と証拠で閉じる

「完成したら教えて」ではなく、成果物の存在、テスト結果、リンク確認、差分、未解決事項を完了条件にします。検証に失敗した場合の再試行回数と、直らない時の報告形式も決めます。


完了条件:

- 指定した成果物が保存されている
- 必須項目に欠落がない
- テストとビルドが成功している
- 変更ファイル一覧と検証結果を報告している
- 未解決事項があれば、推測で埋めず影響と次の判断を示している

コピペで使えるGPT-6 Astraのプロンプト例

ここからは、6要素を実際の依頼文へまとめた例を紹介します。角括弧の部分を自社の条件へ置き換えて使えます。

調査から比較レポートまで任せる例


目的:

[対象サービス]の採用可否を来週の企画会議で判断します。

成果物:

Markdownで、要約、3社比較表、推奨案、出典一覧を作成してください。

各社の料金、主要機能、導入条件、情報更新日を含めます。

入力と範囲:

公式サイト、公式ドキュメント、官公庁資料を優先してください。

対象期間は直近6か月です。確認できない項目は推測せず「不明」と記載してください。

権限境界:

Web閲覧とローカルファイル作成は許可します。

ログイン、問い合わせ送信、購入、外部共有は実行しないでください。

途中確認:

比較軸が確定した時点で、軸と対象3社を一度示してください。

重大な条件が不明なら質問し、それ以外の調査は続けてください。

完了条件:

すべての事実主張に参照URLがあり、リンク切れがなく、推奨理由と不確実性が分かる状態です。

最後に使用した情報源、未確認事項、判断が必要な点を報告してください。

実装からテストまで任せる例


目的:

[機能名]を追加し、既存利用者の操作を変えずに[課題]を解消します。

成果物:

実装コード、必要なテスト、変更理由の要約を作成してください。

入力と範囲:

[対象ディレクトリ]だけを変更対象にします。

既存の命名、型、コンポーネント、テストのパターンを先に確認してください。

[変更禁止ファイル]は変更しないでください。

権限境界:

対象ファイルの編集と既存コマンドの実行は許可します。

依存関係の追加、データ削除、外部送信、デプロイは実行前に確認してください。

途中確認:

影響範囲を調査した後、実装方針と変更予定ファイルを示してください。

仕様を変える必要がある場合は作業を止めて質問してください。

完了条件:

新規テストと既存テストが成功し、ビルドが通り、依頼範囲外の差分がありません。

失敗した検証は最大2回まで原因を修正し、解消しない場合はログと推奨対応を報告してください。

資料作成とレビューまで任せる例


目的:

[対象者]が[会議名]で[判断]できる説明資料を作ります。

成果物:

既存テンプレートを使い、[枚数]枚以内のスライドを作成してください。

結論、根拠、比較、次のアクションを含めます。

入力と範囲:

[指定資料]だけを事実の根拠にしてください。

数値は出典と基準日を記載し、資料にない数値は作らないでください。

権限境界:

資料ファイルの作成と編集は許可します。

外部公開、メール送信、元資料の上書きは実行しないでください。

途中確認:

最初に構成案を作り、論点の不足があれば質問してください。

構成承認を待つ間は、出典整理と図表候補の準備を進めてください。

完了条件:

全ページに1つの主メッセージがあり、数値と引用を元資料で再確認し、文字切れや重なりを目視確認した状態です。

最後に確認済み項目と要レビュー箇所を一覧で示してください。

AIエージェントの作り方

AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。

無料ダウンロード →

作業中の質問と方向修正をプロンプトに組み込む

OpenAIはAstraについて、結果を左右する不足情報があるときは焦点を絞って質問し、Codexでは返答に依存しない作業を進めながら非同期に質問できると説明しています。また、作業途中の追加指示を大目的へ統合するよう改善したとしています（2026年9月時点、出典: openai.com）。

この機能を活かすには「不明点があれば質問して」だけでなく、質問する条件と待っている間の扱いを決めます。

質問する条件を重大度で分ける

次のような条件は、結果や外部への影響が変わるため質問対象にします。

成果物の対象者や用途が2通りに解釈できる
依頼範囲外のファイル変更が必要になる
外部送信、公開、削除、課金を伴う
根拠資料どうしが矛盾している
検証が失敗し、仕様変更が必要になる

一方、命名や並び順など、既存パターンから安全に補える項目は仮定して進められます。仮定した内容は最終報告へ残すよう指示します。

途中指示では変える点と維持する点を書く

作業中に方向を変えるときは、新しい要望だけでなく、維持する条件も一緒に伝えます。


方向修正:

比較対象へ[サービス名]を追加してください。

成果物の形式、一次情報優先、外部送信禁止、完了条件は維持します。

追加によって比較軸が変わる場合だけ質問し、それ以外は続行してください。

これにより、追加指示が元の目的を上書きするのか、一部だけ更新するのかを区別できます。APIのmid-turn steeringでも、完了済みの作業を保持した継続へ新しい指示を取り込む設計が案内されています（2026年9月時点、出典: developers.openai.com）。

中断と再開に必要な状態を残す

長時間タスクは、利用枠、ネットワーク、承認待ち、外部サービスの障害で中断することがあります。再開時に最初からやり直さないよう、確認時点で次の情報を残します。

完了した工程と成果物の保存先
実行中の工程と次の一手
採用した前提と却下した案
実行済みの検証と結果
未解決事項と必要な判断

CodexのAstraでは、長いセッションでコンテキストが埋まった後もメモと過去の情報を検索して要件やテスト結果を保持する仕組みが案内されています。ただし、再開に必要な状態は成果物や進捗報告にも残し、モデル内部の記憶だけに依存しません（2026年9月時点、出典: openai.com）。

GPT-6 Astraの検証と最終監査をプロンプトに含める

長時間タスクでは、成果物が存在することと、要件を満たすことは別です。最後に「何を検証し、どの証拠を返すか」を指定します。

工程ごとに検証方法を対応させる

検証はタスクに合わせて選びます。

工程	検証例	完了の証拠
調査	一次情報の照合、リンク確認	出典URL、基準日、不明項目
データ処理	件数、欠損、重複、集計値の確認	入出力件数、検査結果
コード変更	テスト、型チェック、ビルド	実行コマンドと結果
画面制作	主要幅での表示、操作、アクセシビリティ	スクリーンショット、確認項目
文書作成	必須項目、数値、表記、レイアウト	チェックリスト、要レビュー箇所

OpenAIのモデルガイドも、変更内容に合った必須チェックを実行し、新しい変更、失敗、未解決の懸念がある場合に再検証する考え方を示しています。意味のない再実行を繰り返すのではなく、失敗原因を直してから対象の検証を再度行います（2026年9月時点、出典: developers.openai.com）。

再試行上限と停止条件を決める

「成功するまで続けて」では、同じ失敗を繰り返す可能性があります。再試行は原因を変えられる場合に限定し、上限を設定します。


検証に失敗した場合は原因を特定し、修正後に最大2回まで再実行してください。

同じ原因が続く、権限が不足する、仕様変更が必要になる場合は停止してください。

停止時は、成立済みの工程、失敗した検証、試した対応、次に必要な判断を報告してください。

最終報告の形式を固定する

最後の報告は「完了しました」だけでなく、現在地を監査できる形式にします。


最終報告には次を含めてください。

1. 作成・変更した成果物
1. 実行した検証と結果
1. 採用した前提
1. 未解決事項と影響
1. 次に必要な人の判断または「なし」

この形式は、途中で別の担当者へ引き継ぐ場合にも役立ちます。結果だけでなく、なぜその状態になったかを追えるため、再作業と確認漏れを減らせます。

GPT-6 Astraの長時間タスクで陥りがちな3つの落とし穴

高性能なモデルでも、対象を広げるほど、依頼、権限、検証の不備が同時に増えます。長時間タスクは、まず再現できる一つの業務で型を作ってから広げます。

落とし穴1｜いきなり全ての工程を任せる

調査、判断、編集、公開までを初回から一括で任せると、問題が起きたときに原因を切り分けられません。最初は外部公開を含まない一つの成果物に絞り、目的、権限、完了条件が機能するかを確認します。

GiftXでは、承認、支払い、配送など複数の処理が絡む機能について、AIへ要件と既存コードを渡し、条件、境界、状態遷移を整理させています。そのうえで考え方の異なる3案を設計・試作し、人が方向性を決めます。複雑な仕事ほど、いきなり本実装へ進まず判断可能な単位へ分ける方法が有効です。

落とし穴2｜壮大なAI戦略から考えて手が止まる

全社共通の完全な依頼体系を先に作ろうとすると、設計対象が増えて運用を試せません。代表的な一つのタスクで6要素を埋め、実行後の失敗や確認事項をテンプレートへ戻します。

GiftXの支援事例では、個人メモに散在していたプロンプトと定型フローをスキル集として共有し、改善のたびに書き戻す運用へ変えました。誰が実行しても同じ流れを使えるようになり、新メンバーの立ち上げ期間は概算で約50%短縮しています。最初から万能なプロンプトを目指すより、実行結果から小さく更新する仕組みが定着につながります。

落とし穴3｜既製のチャットだけで自社業務を完結させる

毎回のチャットへ同じ規約、権限、検証手順を書き直す運用では、担当者ごとに品質が変わります。繰り返す条件はプロジェクト指示、テンプレート、スキルへ移し、個別プロンプトには今回の目的と差分だけを書きます。

自社のファイル、業務システム、承認フローへ組み込む段階では、既製画面の便利さだけで選ばず、アクセス範囲、監査ログ、人の承認を設計できる実行環境を使います。

まず1業務をスモールスタートで自動化する

最初に選ぶのは、入力と成果物が明確で、失敗してもやり直せる一つの業務です。6要素をテンプレートにし、実行結果から不足した権限境界や検証項目を書き戻します。安定してから同じ型を隣の工程へ広げると、モデルの性能を自社の運用能力へ変えられます。設計から運用まで伴走が必要な場合は、GiftX AIエージェント構築支援でご相談いただけます。