【完全ガイド】GPT-6 Astraへの頼み方｜OpenAI公式ベストプラクティス5選を実務例で解説

AIに仕事を頼んだのに、確認のやり取りばかりで進まない。ようやく届いた文章も、長すぎてそのまま使えない。そんな経験はありませんか。

GPT-6 Astraを使うなら、最初に読んでおきたいのが、OpenAI公式のベストプラクティスです。注目すべき点は、「どんな仕事を、どこまで任せ、何を確かめて終えるか」という、毎日の依頼に直結する内容が含まれていることです。

この記事では、公式が取り上げる5つの観点を整理し、議事録、取引先へのメール、比較調査、Webページの修正へ落とし込みます。読んだ後に、自分の仕事を1件選び、そのまま試せる依頼文を作れることを目指します。

後半では、非同期ツール呼び出し、作業途中の追加指示、推論量の変更、API移行、料金まで解説します。普段のチャットで使いたい方は第1〜8章から、アプリへ組み込む方は第9〜11章まで読み進めてください。

初回調査：2026年9月8日。公式ガイド・主要API仕様・料金の再確認：2026年9月21日。 主資料はOpenAIのGPT-6 Astra公式利用ガイドです。日本語の業務例・依頼文・採点方法は当メディアの独自作成であり、公式プロンプトの翻訳や、実施済みの導入成果ではありません。

1. 先に結論｜OpenAI公式のベストプラクティスは5つ

まず、公式が何を調整対象にしているかを、仕事を頼む場面と対応させて見ていきましょう。

出典：OpenAI公式ガイド「Prompting best practices」。ここで扱うのは調整の指針です。すべての実行で同じ問題が起こる、という意味ではありません。

図1：公式ガイドの目次にある5つの観点。上の表と対応させると、英語の見出しがどの話題を指すか分かります。出典：OpenAI公式ガイド、2026年9月8日撮影。

この5つを毎回すべて長文で指定する必要はありません。たとえばメールの文章だけを直したいなら、第5章の文体指定から始められます。調査やファイル作成が途中で止まるなら、第3章の完成条件を見直すのが取り組みやすいでしょう。

ただし、同じAstraでも、使うアプリによって実行できる作業は変わります。依頼例を試す前に、この違いだけは押さえておきましょう。

2. GPT-6 AstraとChatGPT・Codex・APIはどう違う？

この章では、モデルの能力と、実際に操作できる範囲の違いを整理します。

2-1. モデルは判断・生成を担い、アプリが操作の入口を用意する

GPT-6 Astraは、入力をもとに判断や文章生成を行うモデルです。ChatGPTやCodexは、そのモデルを使って人が仕事を進めるためのアプリや実行環境です。APIは、開発者が自分のアプリからモデルを呼び出す接続口と考えると分かりやすくなります。

議事録を例にすると、「会議メモを読み、決定事項を整理する」のがモデルに任せる処理です。「その議事録を指定フォルダーに保存する」には、ファイルを扱う機能と、その場所へ保存できる権限も必要になります。

この表は当メディアの整理です。入力欄に「保存してください」と書くだけで、未接続の保存先が使えるようになるわけではありません。サブエージェントや指示ファイルも、それを扱う環境で利用します。

2-2. 最低限知っておきたいAstraの仕様

公式モデルページで確認した主な仕様は、次のとおりです。

出典：GPT-6 Astraモデル仕様。音声・動画の直接入出力には対応していません。別の画像生成ツールを利用する機能と、モデル自体の出力形式も区別してください。

図2：上からコンテキスト上限、最大出力、知識カットオフが並びます。最大入力の値は画像外の公式モデル仕様で確認しています。出典：OpenAIモデルページ、2026年9月8日撮影。

トークンは、文章などをモデルが処理するときの単位です。日本語の1文字が常に1トークンになるわけではないため、「100万トークンなら日本語100万字」と換算しないようにしましょう。

コンテキストが大きいことは、たくさんの情報を扱う余地があることを示します。ただ、関係の薄い資料を無制限に足すより、「どの資料の何を判断材料にするか」を示す方が、結果を点検しやすくなります。

また、知識カットオフ後の出来事は、モデルの学習済み知識と分けて考えます。最新価格や今日の発表を確認したい場合は、必要な検索機能を使える環境で、確認日と出典も求めましょう。

2-3. 自分の環境では、まず3点を確認する

使い始める際は、Astraを選べるか、必要な資料を読めるか、求める操作を実行できるかを確認します。提供状況は利用する画面や組織設定などで異なり得るため、最新の案内はChatGPT Work・Codexの公式ヘルプで確認してください。

最初の練習なら、機密情報を含まない短いメモを入力し、チャット上で議事録を受け取る仕事から始められます。保存や共有を伴わないので、「文章として必要な項目がそろったか」に集中できます。

モデルの全体的な特徴を先に知りたい方は、関連記事のGPT-6 Astraの解説も参照してください。ここからは、日々の依頼を具体的に直していきます。

3. コツ①「何をもって完成か」まで伝える

最初に見直すのは、AIが提出すべき完成物と、そこまで進めてよい範囲です。以下は、公式の完遂という観点を業務へ落とした当メディアの応用例です。

3-1. 「作れますか？」から、提出物が決まる依頼へ

たとえば、会議の文字起こしを添付して、こう頼んだとします。

この文字起こしから議事録を作れますか？

普段の会話として自然な依頼ですが、仕上がりの条件はまだ曖昧です。全文を短く要約するのか、決定事項だけを抜き出すのか、会議に出ていない人が読むのかによって、必要な議事録は変わります。

そこで、次のように具体化します。

独自プロンプト例：議事録を本文まで仕上げる

添付の文字起こしから、社内確認用の議事録を作成してください。
読み手は、会議に出ていない営業責任者です。
「決定事項」「次の作業」「未決事項」の順で整理してください。

次の作業には担当者と期限を記載してください。
担当者と期限は発言で確認できる場合だけ書き、
確認できないものは「未確認」として残してください。

この範囲の整理と作成は進めてください。
作成方法の提案で止めず、文字起こしとの照合を終えた
議事録本文を、このチャットに提出したら完成です。

この依頼では、誰に向けた何を出すのかが決まっています。さらに、担当者が分からないときの扱いも決めているため、その1か所だけを理由に全体を止める必要がありません。

ここで効いているのは、最後の「完成です」という言葉だけではありません。完成品の形、不明点の扱い、進めてよい工程がつながっていることです。「最後までやって」と付け足す前に、この3点を埋めてみてください。

3-2. 不明点は、仕事を左右するかで扱いを決める

AIへの依頼では、すべての空欄を埋めるまで何も作れない、という状態を避けたいものです。一方、売価や契約条件のように、推測で埋めると結果を変えてしまう情報もあります。

当メディアでは、次のように整理すると判断しやすいと考えます。

つまり、「質問をするかしないか」だけではなく、「その質問の答えが、何を変えるか」を見ます。仮置きできる部分はその扱いを指定し、重要な未確定事項は確認対象として残すと、必要な作業を進めやすくなります。

たとえば「担当者は未確認で構わないので、確認できる決定事項と次の作業をまとめてください」という一文なら、事実を創作せずに進める範囲が分かります。「不明点はすべて適当に補って」は、議事録の目的に合いません。

3-3. 下書き・保存・送信では、完了地点が違う

問い合わせ返信を任せる場面でも、完成の定義が役に立ちます。文章を確認したい段階なら、送信前に読める件名と本文まで仕上げてもらいます。

独自プロンプト例：確認できる返信案まで進める

下記の問い合わせへの返信案を1通作成してください。
サービス情報は、添付の承認済み説明資料を参照してください。
資料で確認できる質問に回答し、未記載の条件は約束せず、
本文の後に「社内確認事項」として分けてください。

件名と本文を完成させ、私が内容を確認できる状態で提出してください。
今回の完了地点は、このチャットでの返信案の提示です。

保存まで頼みたいときは、保存先とファイル名を加えます。共有まで頼むなら、対象者と共有方法を明らかにします。こうして到達点を増やす場合は、必要な操作が環境で利用可能かも確認します。Codexの実行権限と承認方針については公式の権限・セキュリティ説明が参考になります。

この例で送信前に止めるのは、返信案を作る依頼だからです。すでに許可している作業について、毎回同じ再承認を挟むためのルールではありません。

このコツの完成確認は、指定項目がそろい、不明な事実が創作されず、頼んだ到達点で成果物を確認できること。 完成条件を伝えても止まる場合は、別の指示が影響していないかを調べます。

4. コツ② 古い指示や手順書の食い違いを整理する

ここでは、今回の依頼以外にAIが読んでいるルールを点検します。「もっと強く頼む」前に、止まる根拠を見えるようにしましょう。

4-1. AGENTS.mdとスキルは、仕事の進め方を伝えるもの

AGENTS.mdは、対応するエージェント環境で、プロジェクトの作業ルールを伝えるファイルです。適用される場所や読み込みの仕組みがあり、PCに置けばあらゆるチャットが読むというものではありません。AGENTS.mdの公式説明で、自分の環境の扱いを確認できます。

スキルは、特定の仕事を行うための手順や知識をまとめたものです。たとえば「記事を書く際は、資料を確認してから構成を作る」といった流れを持たせます。

これらを使っていない方は、「社内手順と今回の依頼が食い違っていないか」という話として読んでください。過去のテンプレートを貼り付けたときにも、似た問題を点検できます。

4-2. 止まった理由を、資料名と該当箇所で示してもらう

架空の例として、提案書作成の手順に「各章を作る前に責任者へ確認」と書いてあるとします。一方、今回やりたいことは「社内レビュー用に、全章の下書きを一度そろえる」です。

このとき「止まらずに進めて」と繰り返すだけでは、ルールの適用が曖昧なまま残ります。まず、確認を求めている記載が、必須条件なのか、通常の作業の目安なのかを特定してもらいます。

独自プロンプト例：停止の根拠を明確にする

今回は、社内レビュー用の提案書を全章下書きする依頼です。
読み込んでいる手順のうち、今回の作業を止める根拠があれば、
資料名と該当箇所を示してください。

明記された必須条件と、あなたが必要だと判断した確認を区別してください。
変更可能な運用上の目安については、今回の完成範囲と整合させてください。
組織の必須条件や実行権限に関わる不足があれば、具体的に説明してください。
進められる範囲の下書きは、確認可能な状態まで作成してください。

これなら、「手順書に書いてあるから」だけで終わらず、どのルールが影響しているかを確認できます。手順の管理者が見直すべき問題と、今回の依頼文で明確にできる問題も分かれます。

なお、ユーザーの文章がすべての指示を上書きするわけではありません。APIではdeveloperメッセージがuserメッセージより優先します。一般的な指示の構造はOpenAIのプロンプト設計ガイドを参照してください。

4-3. 指示を足す前に、重複と適用範囲を見る

よく使う依頼文には、使い続けるうちに例外や補足が増えます。次のような形で、一度整理してみましょう。

参考資料に区切りを付けると、人間もAIも用途を読み分けやすくなります。ただし、区切っただけで情報の安全性や指示の正しさが保証されるわけではありません。

運用の目安として、普段のルールには「いつも必要な条件」を、今回の依頼には「この仕事に固有の条件」を置くと、更新しやすくなります。たとえば正式社名は共通ルール、今回の記事の読者や分量は個別条件です。

このコツの完成確認は、適用する指示が説明でき、組織の必須条件を保ち、不要な重複が解消されていること。 止まらずに進んだ後は、出てくる文章をそのまま使える形へ整えます。

5. コツ③ 読み手・長さ・順番を指定して、そのまま使える文章へ

文章の使いやすさは、読み手と用途によって変わります。この章では、当メディアの独自例で「丁寧に、分かりやすく」を具体化します。

5-1. 誰が読んで、何を分かればよいかを決める

「納期変更のお知らせを丁寧に書いて」と頼むとき、こちらの頭の中には相手との関係や、説明すべき順番があります。その前提を言葉にすると、文章の良し悪しを判断する基準がそろいます。

独自プロンプト例：取引先への連絡文

以下の事実だけを使い、既存の取引先へ送る納期変更のメール本文を作成してください。

事実：当初納期は10月5日。変更後は10月7日。
理由は、最終検品の追加です。
読み手：小売店の仕入れ担当者。

冒頭で変更後の納期を伝え、その後に理由とお詫びを続けてください。
200〜300字を目安に、3段落の自然な敬語にしてください。
本文に見出し・表・箇条書きは使わず、
未提示の原因、補償、確約は追加しないでください。
日付と文字数を確認してから、本文だけ提出してください。

この例の「200〜300字」は、今回の連絡に対する独自の指定です。公式がすべての文章をこの長さにするよう勧めているわけではありません。

変えたいのは、情報の優先順位です。納期変更の連絡なら、相手はまず「いつ届くのか」を知る必要があります。長い前置きの後に日付が出てくるより、冒頭で変更後の納期が分かる方が確認しやすくなります。

一方、詳しい原因説明が必要な報告書なら、200〜300字では足りないかもしれません。文字数は常に短くするためではなく、その文章の役割に合わせるために指定します。

5-2. 表や箇条書きは、用途に合わせて選ぶ

同じ事実でも、見せる形式で読みやすさが変わります。メールに表が不要でも、比較検討では表が役立ちます。

日本語の説明を整えるなら、「専門用語は初出で一文説明」「一段落に一つの論点」「結論を先に」「根拠のない評価語を使わない」といった条件から、必要なものを選べます。これは当メディアの文章上の工夫です。

条件を増やしすぎて「短く、詳しく、漏れなく、すべて説明」と重ねると、優先順位が分かりにくくなります。「本文は300字以内、詳細は補足へ」のように、両立させる形を指定しましょう。

5-3. 修正は、変える部分と残す事実をセットで頼む

文章が一度できたら、全体を書き直さなくてもよい場合があります。たとえば日付は正しいものの前置きが長いなら、直す範囲を絞ります。

日付と理由はそのまま保持してください。
本文を250字以内にし、最初の段落で変更後の納期を伝えてください。
重複するお詫びだけ整理し、新しい事情や約束は追加しないでください。

こうすると、文章を短くしたいのか、内容を変えたいのかが区別できます。数値や固有名詞を残す指定は、要約や書き換えでも応用できます。

ここで扱うのは、チャット上の通常の修正依頼です。第9章に出てくる、実行中のAPI応答へ追加入力を送る機能とは別に考えてください。

このコツの完成確認は、読み手が冒頭で要点をつかめ、必要な事実が保たれ、指定した長さと形式を満たすこと。 「丁寧そうに見える」だけで判断せず、実際に相手へ渡す場面で読み直しましょう。

6. コツ④ 独立した仕事を分担し、最後に統合する

仕事が複数ある場合は、どこを分ければ同時に進められるかを考えます。人数を増やす前に、担当ごとの提出物を決めるのがポイントです。

6-1. サブエージェントは、作業の一部を別担当へ渡す仕組み

サブエージェントは、対応する実行環境で、別の担当へ作業を分ける仕組みです。それぞれがモデルやツールを使うため、分担には利用量や調整の負担も伴います。読み取り中心の独立した調査は始めやすく、同じファイルの同時編集には注意が必要です。サブエージェントの公式説明

普通のチャットに「3人の専門家で考えて」と書くことと、実際に別の実行が3つ起動することは同じではありません。分担機能がある環境で使うのか、1つの会話の中で観点を分けるのかを区別しましょう。

6-2. 比較調査では、「材料集め」と「結論」を分ける

たとえば、社内で使う3つのサービスを比較したいとします。各サービスの公開情報は、他の調査結果を待たずに集められます。

一方、「自社にはどれが合うか」という結論には、3件分の情報と自社の条件が必要です。したがって、材料集めを分担し、結論はそろった材料を見て統合します。

当メディアの独自分担例

ここで共通項目を決めずに分けると、Aは料金、Bは機能、Cは評判だけを調べて戻るかもしれません。それぞれ丁寧でも、横並びの比較には追加調査が必要です。

そのため、先に「月額料金、最低契約期間、対応機能、利用人数、確認できなかった事項」のように項目をそろえます。料金なら税込・税別や年払い条件も合わせて見ると、表面の金額だけで判断するのを避けられます。

6-3. 担当範囲・返す形式・統合責任まで依頼する

独自プロンプト例：3件の公開情報を比較する

下記3サービスを、社内導入の比較用に調べてください。
共通項目は、料金、最低契約期間、対応機能、利用人数、主な制限です。
公式情報を優先し、出典URL、確認日、対象プランを付けてください。
分からない項目は「未確認」としてください。

この環境でサブエージェントが使える場合は、
各サービスの調査を最大3担当へ分けてください。
使えない場合は、同じ項目で順に調査してください。

各担当は調査結果を返し、最終比較表の編集は統合担当が行ってください。
統合時に、比較条件の違い、重複、数字の食い違いを確認してください。
条件がそろわない項目は、無理に優劣を決めず理由を示してください。

この依頼の「最大3担当」は、3つの独立した対象を調べる例に合わせたものです。あらゆる仕事の適正人数ではありません。2行のメール修正なら、分担する準備や統合の方が大きくなる可能性があります。

同じ文書を複数担当で編集するなら、章やファイルで所有範囲を分けます。「全員が好きに直して、最後に合わせる」より、「Aは事実確認、Bは読みやすさの指摘、編集は1担当」の方が、変更の衝突を避けやすい場面もあります。

このコツの完成確認は、比較条件がそろい、根拠をたどれ、矛盾が整理されていること。 分担が実行されたこと自体ではなく、統合後の成果物で判断します。

7. コツ⑤ 変更の影響に合う確認をして、完了を確かめる

ここでは、必要な確認を決め、完成物が条件を満たしたかを確かめます。公式のテスト方針はコーディングが中心なので、まずコード変更で考え、その後に文章や集計へ応用します。

7-1. 変えたものによって、確認することも変わる

Webページのボタンの文言を変えたなら、表示の崩れとリンク先を確かめることが中心です。一方、問い合わせフォームの保存処理を変えたなら、入力、送信、エラー時の表示、保存結果まで確認する必要があります。

この違いを指定せずに「徹底的にテストして」と頼むと、何をどこまで確かめれば終わりかが曖昧になります。当メディアの独自整理として、次のように仕事と確認対象を対応させます。

同じ「表を作る」でも、見た目を整える仕事と、金額を計算する仕事では確認対象が違います。計算の変更なら、0件、空欄、端数なども、実際に発生する条件として確かめます。用途に応じて通常例や境界例を含める考え方は、OpenAIの評価ベストプラクティスも参考になります。

7-2. 合格条件と、確認を終える条件を一緒に書く

必要な確認が済んだら、何か新しい問題がない限り、同じ確認を繰り返す必要はありません。修正を加えた場合や失敗が見つかった場合は、その変更や原因に応じて確かめ直します。

独自プロンプト例：Webページの小さな文言修正

対象ページの申込ボタンを「申し込む」から「相談を予約する」へ変更してください。
リンク先は現在の予約ページを維持してください。

変更後に、PCとスマートフォン幅で文字が欠けずに表示されることと、
リンク先が維持されていることを確認してください。
必要な確認が通り、新しい問題がなければ作業を完了してください。

報告には、変更した内容、確認した表示とリンク、
残っている問題があればその内容を記載してください。

これは文言と表示の修正例です。決済や認証など別の処理も変わる場合は、確認範囲をそれに合わせて広げます。テストの少なさを目標にするのではなく、求める動作を確かめられる範囲を選びます。

文章作成でも同じ考え方が使えます。たとえば「担当者と期限は原文で確認できるものだけ記載する」という条件があれば、見栄えのよい表になっているかだけでなく、その根拠を確認します。

7-3. 「完了しました」と、成果物の状態を対応させる

完了報告は、求めた到達点と一緒に読みます。「ファイルを作りました」なら保存先で開けること、「Web記事を仕上げました」ならリンクと画像が表示されることが、確認の対象になります。

今回の記事制作では、既存メディアの20本を体裁の参考として確認し、公式ページから4枚のスクリーンショットを取得しました。画像は必要な部分を撮影し、本文で参照するファイル名と対応付けています。このように、文章の内容と、掲載物としての状態をそれぞれ確かめます。

画像の例なら、「画像を入れた」という説明だけでは足りません。ファイルが存在し、本文がそのファイルを参照し、公開する環境で読み込めることまでつながって、読者が図を見られます。

実行できなかった確認があれば、「未確認」として具体的に残します。作成したコードと、実際に動作を確かめたコードも分けて報告してもらうと、次の担当者が判断しやすくなります。

このコツの完成確認は、頼んだ到達点を示す結果があり、実施済みと未実施が区別されていること。 ここまでの5つを、次の短い業務でまとめて試してみましょう。

8. コピペで試せる統合テンプレートと、架空の議事録デモ

この章では、仕事を渡すための独自テンプレートと、出来上がりの判断例を用意します。まずは短い入力で、必要な条件がそろっているかを確かめてください。

8-1. 7項目を、自分の仕事に合わせて埋める

次は当メディアの独自テンプレートです。公式の5項目をそのまま翻訳したものではなく、依頼を書くときの抜け漏れを見つけるための7項目です。

目的：誰の、何の判断や作業を助けたいか
完成物：何を、どの形で、どこへ出してほしいか
使う情報：参照してよい資料と、確認済みの事実
任せる範囲：自分で進めてよい工程
確認する条件：何が未確定なら、私の判断が必要か
書き方：読み手、長さ、順番、書式
完了の確認：何を照合してから提出するか

毎回、すべての欄を長く書く必要はありません。短い文章の修正なら「変えたいところ」「残す事実」「完成形」の3点だけでも始められます。

反対に、調査からファイル作成まで複数工程を任せる場合は、参照資料、保存先、分担、完成確認まで書いた方が、途中の判断をそろえやすくなります。スキルやサブエージェントの指示は、利用する仕事に必要な場合だけ加えます。

8-2. 同じ会議メモで、依頼を具体化する

以下は、説明のために作成した架空の会議メモです。実在の顧客や商談の記録ではありません。

入力する材料：架空の会議メモ

9月8日、サービス紹介ページの社内打ち合わせ。
次回確認用のページ下書きは、まず既存サービスの説明を中心に作ることで合意した。
営業担当Aが、掲載候補となる説明文を9月10日までに整理する。
担当Bは利用の流れを図にするが、期限は今回決めなかった。
掲載する写真の選定も必要。ただし担当者と期限は未定。
広告出稿を始める案が出たが、予算と実施時期は次回検討する。
社外公開日は未定で、下書きを確認してから判断する。

「議事録にして」とだけ頼んでも、何らかの要約は得られるかもしれません。ただ、このメモには、合意済みのこと、作業の担当、未定の期限、検討段階の案が混ざっています。

そこで、目的と完成条件を加えます。

独自プロンプト例：条件をそろえた依頼

上の会議メモを、会議に出ていない責任者が確認する議事録にしてください。
「決定事項」「次の作業」「未決事項」の順に整理してください。

次の作業は「作業／担当者／期限」の表にしてください。
担当者や期限が書かれていない項目は「未確認」と記載してください。
検討中の広告出稿を、実施決定として扱わないでください。
新しい金額、日付、担当者は足さないでください。

不明点は未確認として残し、今回のメモだけで全体を仕上げてください。
元のメモとの照合を終えた議事録本文を、このチャットへ出したら完成です。

この依頼は、AIに会議へ参加したつもりで判断させるものではありません。メモから確認できる内容を、読み手が判断しやすい形に整理する仕事として定義しています。

特に「広告出稿を実施決定として扱わない」が、重要な区別を示しています。次回検討の案が決定事項へ入ると、担当者がすぐ動くべき案件に見えてしまうからです。

8-3. 編集部が示す完成形と、採点ポイント

次は、編集部が説明用に作成した完成形の例です。GPT-6 Astraを実行して得た回答ではありません。

決定事項

• 次回確認用のページ下書きは、既存サービスの説明を中心に作成する。

次の作業

未決事項

• 広告出稿：予算と実施時期を次回検討する。
• 社外公開日：下書きを確認してから判断する。
• 作業の未確定項目：利用の流れの図の期限、写真選定の担当者と期限。

実際に試すときは、「見本と一字一句同じか」ではなく、次の条件で判定します。言い回しが違っても、必要な事実と区別が保たれていれば合格にできます。

もし写真選定の担当者を誤って補っていたら、「もっと正確に」だけでなく、「写真の担当者はメモにないので未確認へ直す」と修正します。その後、同じ種類の誤りが残っていないかを見れば、改善箇所が具体的になります。

部署で使う場合は、同じ会議メモに対して担当者同士で合格条件を話し合うのも一案です。「未確認を残すと困る」という意見が出たら、AIに補わせる前に、会議で決める項目や記録の仕方を見直せます。

ここまでで、日常の依頼を試す準備は整いました。次の3章は、自社アプリにAstraを組み込む開発者向けです。

9. 【開発者向け】3つのAPI機能は、何が違う？

ここからは、開発者が設定する機能を解説します。普段のチャットで依頼を改善したい方は、必要になったときに参照し、第12章のFAQへ進んでも構いません。

最初に、3つの機能を「いつ、何を変えるか」で区別します。次の表は、それぞれの公式資料をもとに当メディアが整理した対応表です。

9-1. 非同期ツール呼び出し：データを待つ間に別の作業を進める

非同期とは、ある処理の完了を待つ間に、別の処理を進められる形です。Astraでは、アプリが実行するfunction/custom toolsにasync: trueを設定できます。結果は元のcall_idに対応させ、会話の継続先であるprevious_response_idは最新応答へ更新します。非同期ツール呼び出しの公式資料

公式説明には、次の一文があります。

Your application still executes the tool.

日本語では「ツールを実行するのは、引き続きアプリケーション側です」という意味です。公式の実行責任の説明

図3：非同期にしても、ツールの実行担当はアプリ側です。設定だけで外部ジョブの運用が代行されるわけではない点を読むための抜粋です。出典：非同期ツール呼び出しの公式資料、2026年9月8日撮影。

見積比較を例にした、当メディアの独自フローを考えてみます。

1. アプリが、見積データを取得する処理を開始する。
2. データを待つ間に、比較表の項目や説明の順番を準備する。
3. 取得結果を受け取り、金額や条件を比較表へ入れる。
4. 比較結果を確認し、判断材料をまとめる。

第2段階で進められるのは、まだ届いていない金額に依存しない仕事です。表の器は作れても、最安の見積を決めるには実データが必要になります。

実装時には、取得依頼と返却結果の対応をログで照合できるようにしておくと、取り違えを調べやすくなります。

出典：非同期ツール呼び出しの公式資料。ツール実行とジョブ管理を含むアプリ設計が必要です。

9-2. Mid-turn steering：処理の途中で追加指示を送る

Mid-turn steeringは、AstraをResponses APIのWebSocketで使う際の追加入力機能です。WebSocketは、接続を保ちながら双方向に通信する方式です。response.created後、同じ接続で対象応答IDを指定したresponse.steerを送り、受付はresponse.steer.acceptedで分かります。Mid-turn steering公式資料

受付と反映は別です。 現在の出力項目や開始済みホスト型ツールを終えてから継続し、必要なツール結果・承認待ちなら追加入力は待機します。既に出た内容や実行済み操作を巻き戻さず、開始済みツールもキャンセルしません。切断時には未反映のキューが残ると仮定せず、重複送信にも注意します。処理タイミングと制限

独自の例として、資料を作成している途中に「読み手が技術担当者から経営者へ変わった」と分かった場面を考えます。追加指示を送ったら、アプリ上ではまず「受付」を表示し、その後、継続した応答に読み手の変更が反映されたかを確認する設計が考えられます。

ここで「受付済み」を「資料の修正完了」と表示すると、ユーザーは出来上がったと誤解します。イベント名だけで画面を作らず、利用者に何が完了したと伝えているかを点検してください。

9-3. configuration_update：会話の途中で考える量を変える

推論量は、回答を出すためにどの程度考えるかを調整する設定です。Astra APIの対応値はlow / medium / high / xhigh / max。会話中は、次のユーザー入力の前にconfiguration_update項目を置き、reasoning.effortを変更できます。推論量更新の公式資料

図4：typeで設定更新の項目を示し、reasoning内で推論量を指定する公式例です。出典：Reasoning models、2026年9月8日撮影。

/responses/compactは更新項目を含む履歴を受け付けません。compaction_triggerによる明示的な圧縮後は、次のユーザー入力前に更新を置き直します。出典：Reasoning models。

独自の運用例なら、定型データの整形と、複数の矛盾を含む判断を別段階にし、それぞれで必要品質を満たす推論量を比較できます。すべてを最大にする前に、失敗している箇所が「情報不足」「指示不足」「考える量」のどこにあるかを見てください。

なお、noneやminimalはAstraの対応値ではありません。APIの選択値へ、アプリ独自の表示名である「Ultra」を混ぜないようにしましょう。本記事ではAstraのAPI既定値を推測せず、例では明示設定します。

10. 【API移行】モデル名を変えるだけでは足りない

この章では、既存のAPI呼び出しをAstraへ変える際に点検する項目をまとめます。チャットで使う方が、このコードを入力する必要はありません。

10-1. Astraへ移すときの設定チェック

モデル名と合わせて、使っているパラメーターやツール連携を確認します。

出典：公式移行クイックスタート、モデル仕様、キャッシュの公式資料。

エラーが出た場合は、まず送っている項目を確認します。たとえば、以前の設定を共通関数で自動追加しているアプリでは、目の前の呼び出しに書いていないパラメーターが残っている場合もあります。

最初は、ツールや会話継続を外した単発の呼び出しで確認し、その後に機能を足すと原因を切り分けやすくなります。これは当メディアの実装上の進め方です。

10-2. 最小のPython例で、本文を受け取る形を確認する

次は、現行のOpenAI Python SDKでResponses APIを呼び出す、記事用の未実行例です。利用可能なアカウント、SDK、APIキーの準備が必要です。キーはコードに直接書かず、環境変数OPENAI_API_KEYから読み込む標準クライアントを使います。

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "low"},
    instructions=(
        "入力された会議メモだけを根拠に、日本語で議事録を作成してください。"
        "決定事項、次の作業、未決事項を分け、未確認の事実は補わないでください。"
    ),
    input=(
        "説明文は営業担当Aが9月10日までに整理する。"
        "写真選定の担当者と期限は未定。広告予算は次回検討する。"
    ),
    store=False,
)

print(response.output_text)

この例の到達点は、単発の応答本文を受け取ることです。第9章のジョブ管理やWebSocket通信は実装していません。store=FalseはResponsesの応答保存を無効にする設定であり、すべてのデータ管理条件をこの1行だけで判断するものではありません。Responses APIへの移行資料

10-3. 入力・出力・会話継続も移行する

Chat CompletionsからResponsesへの移行では、主な形が次のように変わります。

previous_response_idは過去入力を無料にする仕組みではありません。保存無効で継続する場合は、暗号化されたreasoning項目などの保持・再送を含め、公式手順に沿って設計します。Responses API移行ガイド

実装では、指示を初回しか渡していない箇所、文章以外の出力項目を想定していない箇所、保存の前提が変わる箇所を見つけましょう。コードがエラーなく動くことに加え、2回目以降も同じ作業ルールを保てるかを確認します。

10-4. 同じ仕事と合格条件で比較する

移行の良し悪しは、自分の仕事で確かめます。当メディアの試行案は、代表的な仕事を3〜5件選び、同じ入力と完成条件で比べる方法です。この件数は小さく試す目安であり、統計的な品質保証ではありません。

たとえば文章生成が速くても、人が毎回日付を直すなら、その修正も評価に入れます。短い整形作業と複数資料の比較を別に見ると、どの仕事を切り替えるか判断しやすくなります。

Codexへの移行全体を確認したい方は、関連記事のClaude CodeからCodexへの移行解説も参照してください。

11. 推論量・料金・キャッシュをどう使い分ける？

この章では、API費用と処理設定を、自分の仕事の品質と一緒に判断する方法を整理します。ChatGPTの月額料金とは別の話です。

11-1. 推論量は、自分の課題で比べる

推論量の設定と、文章の長さの指定は別です。「300字で答える」と頼んでも、その答えを作るために必要な検討量が同じになるとは限りません。

独自の比較例なら、短いメモの整形ではまず明示した低めの設定で合格条件を確認し、条件の多い判断では設定を変えて比べます。その際、入力資料と採点基準を同じにしないと、何が結果に影響したか分かりにくくなります。

高い設定でも、渡していない社内事情が分かるようになるわけではありません。事実が足りないなら資料を足し、判断基準が曖昧なら条件を明確にするところから見直します。

11-2. API料金表は、単位と長文条件をセットで読む

以下は2026年9月8日確認、米ドル、100万トークンあたり、StandardのAPI単価です。入力が272K（272,000）トークンを超える場合は、超過分だけではなく、リクエスト全体へ長文単価が適用されます。

出典：OpenAI公式料金表。見える回答だけでなく、推論トークンも出力課金の対象です。推論トークンの公式説明

当メディアの独自計算例として、Standardで、キャッシュなしの入力10,000トークン、出力課金対象が合計2,000トークンだったとします。

入力：10,000 ÷ 1,000,000 × $10 = $0.10
出力： 2,000 ÷ 1,000,000 × $50 = $0.10
合計：$0.20

これは仮定に基づく算数で、APIを実行して測った費用ではありません。ツールなどの追加費用は含めていません。また、2,000トークンは見える回答だけの量ではなく、出力課金対象全体の仮定です。

費用を予測するときは、「回答が短かったから安いはず」と見た目で決めず、実際の利用量を見ます。第10章の比較表に、人の修正時間や再試行も加えると、仕事全体の負担を判断できます。

11-3. キャッシュは、同じ回答を返す機能ではない

Prompt cachingは、入力の共通する前半の処理を再利用する仕組みです。GPT-5.6以降では、少なくとも1,024可視入力トークンと対象部分の一致が必要で、TTLは30m。書込みと読込みで料金が異なり、再利用しない書込みには費用がかかります。Prompt caching公式資料

当メディアの独自例として、毎回同じ社内の出力書式と、毎回変わる会議メモを渡す仕事を考えます。固定の書式を前半、今回のメモを後半へ置けば、どこが共通部分かを整理できます。

ただし、配置しただけでヒットが確約されるわけではありません。implicit方式の区切りが変動部分の末尾になる場合もあるため、固定部分の末尾への明示的な区切りを検討します。instructions直下には区切りを置けないため、必要ならdeveloperメッセージ内のinput_textを使います。設定の詳細は公式資料で確認してください。

実装後は、同じ回答が返ったかではなく、キャッシュされた入力の利用量を確認します。回答は都度生成されるため、表現の一致をキャッシュの証拠にはしません。また、30mを「30分後にデータが完全削除される保証」と解釈しないでください。

11-4. Fast・Batch・Flexは、用途と条件で判断する

料金上、BatchとFlexの対応トークン単価はStandardの50%、Fastは対応するStandardの2倍です。公式料金表

AstraのFastにはレイテンシーのSLA、つまり応答時間の保証がなく、EUデータレジデンシーでは利用できません。実際の処理方式は返却されたservice_tierを確認します。Astraが常に一定倍率で速くなるとは判断しないでください。Fast mode公式資料

選び方の独自例として、ユーザーが画面で待つ仕事では待ち時間を、翌日までにまとまればよい仕事では完了期限と処理方式の適合を重視できます。「安い方式があるから変更する」だけでなく、その方式の利用条件を満たすかを確かめましょう。

12. GPT-6 Astraの使い方でよくある質問

最後に、依頼を試す前に迷いやすい点を短く確認します。

Q1. 難しいAPI設定をしないと、5つのコツは使えませんか？

完成条件、読み手、不明点の扱いを明確にする工夫は、対応するチャットでの依頼から試せます。API設定は開発者向けです。まず第8章の短いメモと依頼例を使ってみてください。

Q2. 毎回「質問しないで」と書くべきですか？

一律に質問を禁止するより、未確認のまま残せる項目と、判断が必要な項目を指定しましょう。議事録の担当者未定と、取引先へ約束する金額では、扱いが違います。第3章で例を示しています。

Q3. AGENTS.mdを作れば、ChatGPTも自動で読んでくれますか？

対応環境と適用範囲の確認が必要です。自分のPCにファイルを置くことと、使っている会話がその内容を参照することは別です。第4章のように、読み込まれたルールを具体的に確認してください。

Q4. サブエージェントは多いほどよいのでしょうか？

分担できる独立作業の数と、統合の負担で考えます。同じファイルを同時に直す仕事や、短い文章の修正では、分ける意味が小さい場合もあります。第6章の担当表を参考に、先に戻す成果物をそろえましょう。

Q5. テストを減らしても、正しさを確認できますか？

変更に必要な確認は残します。文言変更なら表示とリンク、計算変更なら入力条件と計算結果を確かめる、といった対応が必要です。第7章のように、合格条件と確認を終える条件をセットで決めます。

Q6. 推論量をmaxにすれば、いつも最良の結果になりますか？

自分の仕事で、品質・時間・利用量を比較して判断してください。資料にない事実や曖昧な判断基準を、設定だけで解消できると考えないことが大切です。第11章の比較方法が使えます。

Q7. 作業途中に指示を変えれば、実行済みの処理も取り消せますか？

第9章のsteeringは、実行済み操作を巻き戻す機能ではありません。追加指示の受付と、継続した応答への反映も別です。何がすでに処理されたかを確認して対応します。

Q8. この記事の日本語テンプレートは、OpenAI公式のものですか？

業務例とテンプレートは当メディアの独自作成です。公式の対象領域は第1章に整理し、仕様の根拠は本文近くへリンクしています。第8章の完成形も説明用で、Astraの実行結果ではありません。

13. まずは今日の仕事1件に、完成条件を足してみる

最初にすることは、普段の依頼を一つだけ具体化することです。

1. 議事録、メール、短い調査など、日常の仕事を1件選ぶ。
2. 第8章のテンプレートに、材料と完成条件を書く。
3. 出てきた成果物を、事前に決めた条件で確かめる。

「分かりやすくまとめて」を、「誰が読むか」「何を決めたいか」「未定をどう扱うか」まで書き換えてみてください。直したい点が見つかったら、長い指示を足す前に、足りない情報や判断基準を一つずつ補います。

現場の人が知っている例外や判断の基準は、AIへ任せる仕事を具体化する材料になります。完成物を確認する過程で、会議の記録方法や、社内の手順そのものを改善できる場合もあります。

自社のどの業務から試すか整理したい方は、業務の棚卸しについてご相談ください。あなたのAI顧問株式会社の「あなたのAI顧問」は、AI・DX領域のBPOとAI教育を組み合わせ、業務棚卸しと優先順位付けから、契約範囲内の実装、現場教育、社員が自ら改善できる状態づくりまで支援する伴走型サービスです。

参考資料

以下は本記事で参照したOpenAIの公式資料です。確認日は2026年9月8日です。提供状況、対応条件、料金は更新されるため、実装・利用時にも該当ページをご確認ください。

• GPT-6 Astra公式利用ガイド・ベストプラクティス
• GPT-6 Astraモデル仕様
• ChatGPT Work・Codexの利用案内
• エージェントの権限と承認
• AGENTS.mdによる指示
• プロンプト設計
• サブエージェント
• 評価のベストプラクティス
• 非同期ツール呼び出し
• Mid-turn steering
• 推論モデルと推論量の更新
• Responses APIへの移行
• API料金
• Prompt caching
• Fast mode

WRITERライター紹介

黒山結音

あなたのAI顧問株式会社　代表取締役

「AIは現場で使えなきゃ意味がない」を掲げ、30社以上にAI顧問として導入から定着までサポート。OpenClaw・Claude・ChatGPTなどAIツールを実務でフル活用し、AI駆動経営を実践。本メディアでは、実際の現場で効果が出た事例や、AI初心者がつまずく「最初の一歩」を、専門用語を極力使わずに解説します。

OpenClaw / Claude Code / Codex / Cursor / Manus