グラレコ
上のグラレコは、この記事で扱う OpenAI の公式ガイドの要点を1枚にまとめたものです。3つのモデルの使い分けから、自走のさせ方、スキルとの優先順位、文体、サブエージェント、テストの加減、移行のポイントまでを並べています。まずは全体の地図としてざっと眺めて、気になるブロックから本文を読んでいただければと思います 🗺️
はじめに
GPT-6 は OpenAI の最新モデルファミリーで、GPT-6 Astra・GPT-6 Sol・GPT-6 Luna の3モデルで構成されています。OpenAI は開発者向けドキュメントとして「Using GPT-6」を公開していて、その中に「Prompting best practices（プロンプティングのベストプラクティス）」というセクションがあります。この記事では、そのセクションを中心に、推奨プロンプトの原文と日本語訳つきで整理します。
ガイドのプロンプティング部分は、GPT-6 Astra で観察された5つの挙動と、それぞれへの対処プロンプトという構成になっています。ざっくり言うと、Astra は「賢くて慎重な協力者」として作られているぶん、次のようなクセがあります。
- 迷ったときにユーザーに質問して止まりやすい
- スキルファイルや
AGENTS.mdの指示に敏感に反応する - リストや表の多い、詳細な回答に寄りやすい
- サブエージェントへの委任が期待より少ないことがある
- コーディングでテストを徹底しすぎることがある
どれも「悪いクセ」というより、真面目で丁寧な性格の裏返しです。アプリケーションの用途に合わせてプロンプトで加減する、というのがガイド全体のスタンスになっています。
この記事でわかること 📌
- GPT-6 ファミリー3モデルの違いと、新しく追加された API 機能
- Astra の5つの挙動と、公式が示す対処プロンプト（原文＋訳）
- それぞれのプロンプトをどういう場面で使うか、使うときの注意点
- 既存アプリを GPT-6 に移行するときのチェックポイント
想定読者は、OpenAI API（特に Responses API）でエージェントやチャット製品を作っている開発者の方です。GPT-5.x 系からの移行を検討している方にも役立つ内容になっています。
💡 本文中の英語プロンプトはすべて OpenAI の公式ドキュメント（2026年9月時点）からの逐語引用です。日本語訳は筆者によるもので、実際にプロンプトへ入れるときは英語の原文を使うことをおすすめします。
前提：GPT-6 ファミリーはどんなモデルか 🌞🌙⭐
まずは3モデルの立ち位置を押さえておきます。各モデルの公式ページから、プロンプト設計とコストに関係する項目を表にまとめました。
| 項目 | GPT-6 Astra | GPT-6 Sol | GPT-6 Luna |
|---|---|---|---|
| モデル ID | gpt-6-astra |
gpt-6-sol |
gpt-6-luna |
| 位置づけ | 最も高性能。最難関のエンドツーエンド作業向け | 複雑なコーディングとエージェント型ワークフロー向け | 最も効率的。集中的で大量のタスク向け |
reasoning.effort |
low / medium / high / xhigh / max（none 非対応） |
none / low / medium / high / xhigh / max（デフォルト medium） |
none / low / medium / high / xhigh / max（デフォルト medium） |
| 入力 / 出力（100万トークンあたり） | ＄10 / ＄50 | ＄2 / ＄10 | ＄0.1 / ＄0.5 |
| キャッシュ入力 | $1 | $0.2 | $0.01 |
| キャッシュ書き込み | $12.5 | $2.5 | $0.125 |
| コンテキストウィンドウ | 1,050,000 | 1,050,000 | 1,050,000 |
| 最大出力トークン | 128,000 | 128,000 | 128,000 |
| 知識のカットオフ | 2026年4月30日 | 2026年4月20日 | 2026年5月18日 |
価格まわりの補足として、3モデル共通で次のルールがあります。
- 入力が 272K トークンを超えるプロンプトは、リクエスト全体で入力とキャッシュが 2 倍、出力が 1.5 倍の料金になる
- キャッシュ書き込みは、キャッシュなし入力の 1.25 倍
- Batch と Flex は Standard の 50%、Fast mode は 2 倍
Astra は1トークンあたりの単価が高めですが、公式ガイドでは「いくつかの評価で、Astra は出力トークンを大幅に減らしながらより強い結果を出し、単価が高いにもかかわらずタスクあたりの推定 API コストは以前のモデルより低い」と説明されています。単価だけで判断せず、タスク単位のコストで比べるのがよさそうです。
ガイドのモデル選びの指針はシンプルです。
この図のポイントは、Astra だけ none（推論なし）が使えないという点です。推論なしで超低レイテンシを狙う用途なら Sol や Luna、という切り分けになります。
Astra の「性格」も知っておく
ガイドの冒頭では、Astra を「これまでで最も知的なモデル」であると同時に「これまでで最も aligned（整合的）なモデル」と紹介しています。具体的には次のような性質です。
- 配慮を持って行動し、タスクの境界を尊重し、透明性のあるコミュニケーションをする
- 指示に解釈の余地があるときは、手元のコンテキストで日常的な隙間は埋め、答えによって結果が変わりうる場合は的を絞った質問をする
- 新しい要件を取り込み、頼まれれば方針を変え、脇道の質問にも答えつつ全体のタスクを見失わない
この「結果が変わりうるなら質問する」という性質が、このあと出てくる「聞きすぎ」問題の出どころになっています。
GPT-6 の新機能をざっと押さえる 🆕
プロンプティングの前に、ガイドの「What's new」で紹介されている4つの新機能も見ておきます。プロンプトと組み合わせて使う場面が多いものです。
| 機能 | 何ができるか |
|---|---|
| 非同期ツール呼び出し（Async tool calling） | ツールの実行中も、モデルが推論を続けたり、他のツールを呼んだり、リクエストの独立した部分に答えたりできる。関数またはカスタムツールに async: true を付け、結果は元の call_id で返す |
| ターン途中のステアリング（Mid-turn steering） | モデルが作業中に、修正や要件変更などの追加指示を送れる。WebSocket 接続の Responses API で、完了済みの作業を保持したまま更新を反映する |
| 会話途中の推論レベル変更（キャッシュ維持） |
configuration_update 入力アイテムで、元のプロンプトのプレフィックスを書き換えずに reasoning effort を上げ下げできる |
| ミスアラインメント監視 | Astra 向けの強化されたセーフガードの一環として、OpenAI のシステムが非同期にミスアラインメントを監視し、必要に応じてアラートを出す |
それぞれの関係を図にすると、次のようになります。
公式ドキュメントを読むときに押さえておきたい注意点もいくつかあります。
- 非同期ツールでも、ツールを実行するのはあくまでアプリケーション側です。OpenAI がバックグラウンドジョブを管理してくれるわけではありません
- ステアリングは、すでにアプリに送られた出力を書き換えたり、過去のアクションを取り消したり、開始済みのツールをキャンセルしたりはしません。また GPT-5.6 以前のモデルでは使えません
-
configuration_updateは GPT-6 ファミリーの標準のシングルエージェントモードで使え、変えられるのは reasoning effort だけです
configuration_update の使い方は、公式の Python サンプルがわかりやすいので引用しておきます。
from openai import OpenAI
client = OpenAI()
model = "gpt-6-astra"
response = client.responses.create(
model=model,
reasoning={"effort": "low"},
input="Draft a database migration plan.",
store=True,
)
print(response.output_text)
response = client.responses.create(
model=model,
previous_response_id=response.id,
reasoning={"effort": "low"},
input=[
{
"type": "configuration_update",
"reasoning": {"effort": "high"},
},
{
"role": "user",
"content": "Analyze the failure modes and propose rollback steps.",
},
],
store=True,
)
print(response.output_text)
ポイントは、2回目のリクエストでもリクエストレベルの reasoning.effort は low のまま据え置き、configuration_update アイテムで high に切り替えているところです。リクエストレベルの値を変えるとプロンプトのプレフィックスが変わってキャッシュが効かなくなるので、それを避けるための仕組みになっています。
reasoning ガイドには、ほかにもいくつか注意があります。
-
configuration_updateを2つ隣り合わせに置くと API に拒否される - 自動コンパクションや自動トランケーションとは組み合わせない
- レスポンスの
reasoning.effortには、アップデートで選んだ値ではなくリクエストレベルの値が表示される
全体マップ：Astra の5つの挙動と対処 🧭
ここからがプロンプティングの本題です。ガイドが挙げる5つの挙動と、それぞれへの対処を1枚にまとめました。
ガイドは冒頭で、「これらのプロンプトは GPT-6 ファミリー全体の出発点として使えるが、観察されたのは Astra の挙動なので、選んだモデルとワークロードで評価してください」と断っています。Sol や Luna で使う場合も、そのまま入れて終わりではなく、手元の評価で効き目を確かめるのが前提です。
もう1つ大事なのは、5つの挙動はどれも用途によっては長所だという点です。たとえば「質問して止まる」のは、人が横にいる対話型アプリならむしろ望ましい挙動です。この記事でも、各プロンプトについて「どういうアプリなら入れる価値があるか」を意識して見ていきます。
1. 自走と最後までのやり切り（Initiative and follow-through）🏃
「確認してくる」問題
Astra は、GPT-5.6 Sol 以前のモデルと比べて、長いタスクでも一貫性を保つのがおおむね得意です。一方で、以前のモデルなら仮定を置いて進めていた場面で、確認を求めてくることが増えています。
ガイドの言葉を借りると、Astra は「より効果的な協力者」として設計されていて、追加の入力が結果を大きく変えうるときにユーザーに質問しやすくなっています。そのため、ユーザーが「妥当な仮定を置いてそのまま進めてほしい」と思っている場面でも止まってしまうことがあります。
Before / After を図にすると、次のようなイメージです。まずはプロンプトなしの場合です。
次に、自走を促すプロンプトを入れた場合です。
対処その1：意図を汲んで最後まで進める
より自律的に作業させたいときの出発点として、ガイドはこのプロンプトを示しています。
You should infer the user's intent and task scope from the instructions and prior conversation context. Your job is to bias towards action and carry the user's intended task to completion.
When the user expresses intent to perform new work or fix an existing issue, persist until the user's intended goal is complete. Progress autonomously towards the user's goal (e.g. creating isolated worktrees / checkouts if needed, resolving merge conflicts, read-only actions, creating draft PRs etc.) unless they are clearly destructive or irreversible.
（訳：指示とこれまでの会話のコンテキストから、ユーザーの意図とタスクの範囲を推測してください。あなたの仕事は、行動する方向に寄せて、ユーザーが意図したタスクを完了まで運ぶことです。
ユーザーが新しい作業をしたい、または既存の問題を直したいという意図を示したときは、意図したゴールが完了するまでやり抜いてください。明らかに破壊的または不可逆なものでない限り、ユーザーのゴールに向けて自律的に進めてください（例：必要に応じて独立したワークツリーやチェックアウトを作る、マージコンフリクトを解決する、読み取り専用の操作、ドラフト PR の作成など）。）
例として挙がっているのが「ワークツリーを分ける」「ドラフト PR を作る」といった、やり直しがきく操作ばかりなのがポイントです。「明らかに破壊的または不可逆なものでない限り」という歯止めもセットになっています。
対処その2：「できる？」は「やって」と読ませる
ユーザーの意図がはっきりしないと、モデルは確認を求めやすくなります。そこで、ユーザーのプロンプトが許可を含意している場合は実行するよう促すのがこちらです。
When the user's prompt indicates a request for action, such as "can you...", "I want to...", "help me..." and similar expressions, treat these as instructions to do the work and take action. Do not stop at acknowledging capability (e.g. "Yes…"), proposing a plan, or offering to continue. Do not settle for a partial or "helpful enough" solution that does not fully satisfy the user's task to save time, effort or tokens. If a task requires sustained work, complete all the necessary work until the intended outcome is fulfilled.
（訳：ユーザーのプロンプトが「〜できる？」「〜したい」「〜を手伝って」などの表現で行動を求めている場合は、作業を行って行動せよという指示として扱ってください。能力があることを認める（例：「はい…」）、計画を提案する、続けることを申し出る、といった段階で止まらないでください。時間・労力・トークンを節約するために、ユーザーのタスクを完全には満たさない部分的な、あるいは「そこそこ役立つ」解決策で妥協しないでください。タスクに継続的な作業が必要なら、意図した成果が達成されるまで必要な作業をすべて完了してください。）
英語の "Can you fix this?" は、文字どおりには「直せる？」という能力の質問ですが、実際には「直して」という依頼です。日本語の「〜してくれる？」も同じですね。このプロンプトは、その依頼としての読み方を明示的に教えるものです。
対処その3：承認は「具体的な成果物」に対してもらう
3つ目は、確認のタイミングを調整するプロンプトです。レビューできる具体的な結果を用意してから承認を求めるようにすると、モデルができる作業を終える前にタスクが止まるのを防げて、完了も早くなりやすいそうです。
Before asking the user clarifying questions, you should complete the work that is already authorized from context and necessary to make the proposed action concrete and reviewable. The user should be approving a concrete, reviewable result. For example, before deploying a change, writing to an external application, merging a PR or publishing a site, do all the required work first so that user approval is the final step. You don't need user permission for reversible tasks, read-only actions, reviews or fixes, or anything for which authorization is provided earlier in the session or strongly implied from the task instruction.
Do not introduce unsolicited warnings, disclaimers, approval flows, or safety/compliance checklists due to hypothetical risk.
（訳：ユーザーに確認の質問をする前に、コンテキストからすでに許可されていて、提案するアクションを具体的でレビュー可能にするために必要な作業を完了してください。ユーザーが承認するのは、具体的でレビュー可能な結果であるべきです。たとえば、変更をデプロイする、外部アプリケーションに書き込む、PR をマージする、サイトを公開する、といった前には、必要な作業をすべて先に済ませ、ユーザーの承認が最後のステップになるようにしてください。元に戻せるタスク、読み取り専用の操作、レビューや修正、あるいはセッションの前半で許可が与えられたもの、許可がタスクの指示から強く示唆されるものについては、ユーザーの許可は不要です。
仮定上のリスクを理由に、求められていない警告、免責事項、承認フロー、安全性やコンプライアンスのチェックリストを持ち込まないでください。）
このプロンプトの考え方を流れにすると、こうなります。
「曖昧な段階で聞く」のではなく「形にしてから聞く」という順番の入れ替えです。人間のチームでも、「こういう方向でどうですか？」と聞くより、「ドラフトを作ったので確認してください」の方が話が早いのと同じですね 📝
自律性のレベルはアプリに合わせる
ガイドはこのセクションの最後に、モデルはデフォルトで、作業しながらブロッキングではない質問をするのを好むので、これらのプロンプトはアプリケーションが必要とする自律性のレベルに合わせて調整してくださいと書いています。
3つのプロンプトを、アプリの性格に合わせて選ぶイメージは次のとおりです（この図は筆者の整理です）。
特に3つ目のプロンプトにある「求められていない警告や承認フローを持ち込まない」は、社内のコンプライアンス要件がある環境だと、そのまま入れてよいか慎重に判断した方がいい一文です。必要な承認フローは、プロンプトではなくアプリ側の仕組みとして持っておくと安心です。
2. 指示追従とスキルファイル（Instruction following）📄
指示に強く従う＝ファイルの中身にも敏感
GPT-6 Astra は、以前のモデルよりも一般的な指示追従が強く、挙動をコントロールしやすくなっています。長い指示にもよく従えます。
その裏返しとして、コンテキスト内の情報に敏感になることがあります。特に、スキルや AGENTS.md のようなファイルに書かれた指示にも反応しやすくなっています。たとえば、スキルファイルの中に不明確な指示や矛盾する指示があると、モデルが一時停止して、作業を早い段階でブロックしてしまうことがあるそうです。
ガイドはここで、**モデルがアクセスできるスキルやその他のファイルに、挙動に影響しうる指示がないか監査することを強く推奨（strongly recommend）**しています。ガイドの中で「strongly recommend」と太字で念押しされているのは、この箇所だけです。
対処その1：ユーザー指示とスキルの優先順位を明示する
まずは優先順位をはっきりさせるプロンプトです。
The user's instructions take precedence over guidelines provided in a skill. If explicit user instructions conflict with a skill's instructions, prioritize the user's instructions.
（訳：ユーザーの指示は、スキルで提供されるガイドラインよりも優先されます。明示的なユーザーの指示がスキルの指示と矛盾する場合は、ユーザーの指示を優先してください。）
短い一文ですが、スキルを大量に読み込ませるエージェントほど効いてきます。スキルは汎用的に書かれていることが多いので、個別の依頼とぶつかることは珍しくありません。
対処その2：止まった理由をスキルから引用させる
もう1つは、モデルが一時停止したり方向を変えたりした原因のスキルと指示を特定させるプロンプトです。モデルの挙動に透明性を持たせるのに効果的だそうです。
If a skill causes you to ask for permission or confirmation, pause, leave requested work unfinished, or diverge from the user's intent, name and link to the exact SKILL.md file you read, quote the relevant instruction, and briefly explain how it applies. Distinguish explicit skill requirements from your interpretation of guidelines.
（訳：スキルが原因で、許可や確認を求めたり、一時停止したり、依頼された作業を未完了のままにしたり、ユーザーの意図から外れたりする場合は、読んだ SKILL.md ファイルを正確に名指ししてリンクし、該当する指示を引用し、それがどう当てはまるかを簡潔に説明してください。スキルの明示的な要件と、ガイドラインに対するあなたの解釈を区別してください。）
ガイドによると、このプロンプトは、アプリケーションが多数のスキルや AGENTS.md のような指示ファイルを読み込むときに、表に出てこない指示や矛盾する指示を見つけるのに使えます。
最後の「明示的な要件と、自分の解釈を区別して」という一文がよく効いていると思います。「スキルにそう書いてあった」のか「スキルをそう解釈した」のかが分かれば、直すべきはスキルの文面なのか、プロンプトなのかが判断しやすくなります 🔍
3. パーソナリティと文体（Personality and writing style）✍️
リスト・表・Markdown 多めがデフォルト
GPT-6 Astra は、回答をざっと読みやすくするために、リスト、表、Markdown を使う傾向があります。また、詳細でフォーマットされた回答に寄りやすく、セッションをまたいで同じ言い回しを繰り返すこともあるそうです。
ドキュメントやレポートなら、それが読みやすい場面もあります。でも、チャットの返答やメール文面、読み物として読ませたい文章では、箇条書きだらけだと少し事務的に見えてしまいますよね。ガイドは「アプリケーションが必要とする文体と構成を指定してください」と勧めていて、3つのプロンプトを用意しています。
対処その1：段落中心の文章にする
フォーマットを減らして散文で書いてほしいときのプロンプトです。
Default to using clear, concise paragraphs, each developing one main idea. Use lists only when the information is genuinely parallel, sequential, or easier to compare, and avoid nested lists unless the hierarchy cannot be expressed clearly in prose. Use plain, simple language: familiar words, concrete examples, and precise verbs. Prefer active voice and direct statements.
Make sure to state the main point clearly and early, then develop it with the explanation and detail the reader needs. Let each sentence build on what came before. Develop the points that matter and provide enough support to be useful.
（訳：基本は、明確で簡潔な段落を使い、各段落で1つの主要なアイデアを展開してください。リストは、情報が本当に並列・順序的である場合や比較しやすくなる場合にだけ使い、階層を散文で明確に表現できない場合を除いて入れ子のリストは避けてください。平易でシンプルな言葉を使ってください。身近な単語、具体例、正確な動詞です。能動態と直接的な表現を優先してください。
要点を明確に、早めに述べ、そのうえで読み手に必要な説明と詳細で展開してください。各文が前の文の上に積み上がるようにしてください。重要な点を掘り下げ、役に立つだけの裏付けを示してください。）
「リストを使うな」ではなく「リストは本当に並列・順序的なときだけ」と条件で書いているのがうまいところです。完全に禁止すると、今度は手順の説明まで段落に詰め込まれて読みにくくなるので、使いどころを限定する書き方になっています。
対処その2：技術的なコミュニケーションのバランスを取る
技術的な内容を説明するときに、分かりやすさと専門性のバランスを取るためのプロンプトです。
Use plain language over jargon, and reference technical details only to the degree that it helps illustrate an idea or your work to the user. Communicate complex concepts in a clear and cohesive manner, and calibrate your writing to the level of background knowledge assumed from the user's prompt and context.
（訳：専門用語より平易な言葉を使い、技術的な詳細は、アイデアや自分の作業をユーザーに示すのに役立つ程度にとどめてください。複雑な概念を明確でまとまりのある形で伝え、ユーザーのプロンプトとコンテキストから想定される背景知識のレベルに合わせて文章を調整してください。）
「相手の知識レベルに合わせて書く」ことを明示しているので、同じアプリでも、初心者っぽい質問には噛み砕いて、専門的な質問には専門的に、という出し分けが期待できます。
対処その3：AI っぽい定型フレーズを避ける
最後は、専門用語や定型フレーズ（stock phrases）を減らすためのプロンプトです。ガイドでは "slop words"（手垢のついた言葉）と呼んでいます。
Avoid using slop words or phrases like "Bottom Line:" in conclusions, "delve," "foster," "leverage," "it's worth noting," "importantly," "Question? Answer." or "This isn't about X. It's about Y.", "genuinely" or hyphenated compound descriptions and adjectives. Do not use concluding summary statements such as "In short:..", "The simplest mental model is:...".
State the intended action directly. Avoid adding what you won't do, what will remain unchanged, or how you'll separate or categorize results. Do not use contrastive framing such as "X, not Y" or "X—not Y" that introduces an unprompted alternative that the user didn't ask about. Avoid invented compound labels like "exact-head checks" and "editorial-row layouts", vague qualifiers, and canned transitions; use plain verbs and prepositions to state the actual relationship directly.
（訳：結論での "Bottom Line:"、"delve"、"foster"、"leverage"、"it's worth noting"、"importantly"、「質問？答え。」形式、「これは X の話ではない。Y の話だ。」、"genuinely"、あるいはハイフンでつないだ複合的な説明や形容詞のような、手垢のついた言葉やフレーズを使わないでください。"In short:.."、"The simplest mental model is:..." のような締めの要約文も使わないでください。
意図するアクションを直接述べてください。やらないこと、変わらないまま残るもの、結果をどう分けたり分類したりするか、を付け加えないでください。ユーザーが尋ねていない代替案を持ち出す「X であって Y ではない」「X—Y ではなく」のような対比の構図は使わないでください。"exact-head checks" や "editorial-row layouts" のような造語の複合ラベル、曖昧な修飾語、決まりきった接続表現を避け、平易な動詞と前置詞で実際の関係を直接述べてください。）
禁止リストに挙がっているものを整理すると、次のようになります。
| 種類 | 具体例（原文） | 日本語でいうと近いもの |
|---|---|---|
| 手垢のついた単語 | "delve", "foster", "leverage", "genuinely" | 「〜を深掘りする」「〜を醸成する」の多用 |
| 前置きの決まり文句 | "it's worth noting", "importantly" | 「特筆すべきは」「重要なのは」 |
| 締めの決まり文句 | "Bottom Line:", "In short:..", "The simplest mental model is:..." | 「結論：」「要するに」「一言でいうと」 |
| 自問自答の型 | "Question? Answer." | 「なぜか？それは〜だからです。」 |
| 対比の型 | "This isn't about X. It's about Y.", "X, not Y" | 「これは X の話ではありません。Y の話です。」 |
| 造語ラベル | "exact-head checks", "editorial-row layouts" | 勝手に作った四字熟語風の名前 |
右の列は筆者の感覚で近いものを並べたものですが、日本語の AI 生成文でもよく見るパターンばかりだと思います。英語のプロンプトなので日本語出力にどこまで効くかは手元で試す必要がありますが、日本語向けに同じ考え方で禁止リストを作るときの参考にもなりそうです。
後半の「やらないことや、変わらないものを付け加えない」も面白い指摘です。「既存の設定は変更せずに〜します」「〜は対象外とします」のような、聞かれてもいない但し書きを減らしてほしい、という意図ですね。
4. サブエージェントへの委任（Subagent delegation）👥
委任が「少なめ」になりがち
GPT-6 Astra は、作業を分割して並列に動くサブエージェントに委任できるように訓練されています。ただし、ワークフローによっては、期待より委任の頻度が少ないことがあります。
ハーネスでマルチエージェントシステムを実装している場合は、どれくらい委任するかを次のプロンプトで調整します。
If at any point you can parallelize work by delegating tasks to another agent (no matter if you are the root or subagent), you should do so using collaboration tools if it could save time or improve quality.
（訳：どの時点であれ、タスクを別のエージェントに委任することで作業を並列化できるなら、（あなたがルートエージェントかサブエージェントかに関係なく）時間の節約や品質の向上につながる場合は、協調ツールを使ってそうしてください。）
「ルートでもサブエージェントでも」と書いてあるので、委任が多段になることも想定したプロンプトです。
ここで気をつけたいのは、委任を増やすとコストや管理の手間も増えることです。ガイドも「モデルは、いつ・どのように委任するかのプロンプトによく反応するので、ハーネスとマルチエージェントの実装に合わせて調整してください」と書いています。上のプロンプトは「委任を増やす方向」の出発点なので、上限や条件はハーネス側の事情に合わせて足していくのがよさそうです。
エージェント間メッセージを読みやすくする
地味ですが実用的なのがこちらです。エージェント同士のメッセージには、文法やスペースの誤りが含まれることがあるそうです。それを読みやすくするためのプロンプトです。
Messages that you send to other agents and your final answer may be read by a human, so ensure they are legible. Always put proper spaces between words and/or numbers.
（訳：あなたが他のエージェントに送るメッセージと最終回答は、人間が読む可能性があるので、読みやすくしてください。単語や数字の間には、常に適切なスペースを入れてください。）
エージェント間のやり取りは、デバッグのときに人間がログを読むことになります。そのときに単語がくっついていたりすると、原因調査がかなりつらくなります。「人間も読むかもしれないよ」と一言添えるだけで直るなら、入れておいて損はないですね 🙂
5. テストと検証（Testing and verification）🧪
小さな変更にも大きなテスト
コーディングタスクでは、GPT-6 Astra はタスクを完了とみなす前に、徹底的にテストする傾向があります。品質の面では頼もしい性質ですが、小さなタスクだと、タスクが必要とする以上に広いテストになってしまうことがあります。
ガイドの対処は、「変更がどれだけのテストと検証を必要とするかを調整する」ことです。小さな変更での不要なテストや、繰り返しのチェックを避けられます。
Do not write tests for reversible, low-impact changes that mirror the implementation. If you do choose to verify your work with tests, make sure that the tests are meaningful and necessary to verify implementation.
Run tests appropriate to the change and complete required checks. Once those pass, broaden or repeat testing only when new changes, failures, or unresolved concerns justify it; otherwise, continue toward completing the task.
（訳：元に戻せる影響の小さな変更について、実装をなぞるだけのテストは書かないでください。作業をテストで検証すると決めた場合は、そのテストが実装を検証するうえで意味があり、必要なものであるようにしてください。
変更に見合ったテストを実行し、必要なチェックを完了してください。それらが通ったら、新しい変更、失敗、未解決の懸念がそれを正当化する場合にだけ、テストを広げたり繰り返したりしてください。そうでなければ、タスクの完了に向けて進んでください。）
このプロンプトが描いている判断の流れを図にすると、次のようになります。
「実装をなぞるだけのテスト（mirror the implementation）」というのは、たとえば定数を1つ変えただけの変更に対して「その定数がその値であること」を確かめるようなテストです。書いても何も守ってくれないうえに、次に値を変えるときに一緒に直す手間だけが増えます。
「テストを減らせ」ではなく「変更に見合ったテストを」という書き方なので、大きな変更や失敗が出た場面では、ちゃんと広げて確認してくれるのがポイントです。
移行クイックスタート 🚚
最後に、既存のアプリを GPT-6 に移行するときのポイントをまとめます。ガイドの「Migration quickstart」の内容です。
Codex で移行する
Codex を使っている場合は、OpenAI Docs スキルで、このガイドの推奨変更を適用できます。
$openai-docs migrate this project to the GPT-6 model family
ほかのコーディングエージェントで使いたい場合は、Codex のリポジトリからスキルをダウンロードして使えます。
API とモデルパラメータのチェックリスト
model を gpt-6-astra、gpt-6-sol、gpt-6-luna のいずれかにしたうえで、次を確認します。
| 項目 | 確認すること |
|---|---|
| reasoning effort | 対応している範囲で、現在の実効 effort を維持する。Astra は none 非対応なので low を使う（Sol と Luna は none 対応）。minimal を使っていた場合は low から始めて代表的なタスクで比較する。Responses では reasoning.effort、Chat Completions では reasoning_effort
|
| ツール呼び出し | Responses API を使う。Astra は Chat Completions に対応しているが、ツール呼び出しには Responses が必要。Sol と Luna は Chat Completions での関数呼び出しが reasoning_effort: "none" のときだけ。推論とツールを組み合わせるなら Responses |
| 非対応パラメータ | reasoning effort が none 以外なら、temperature・top_p・top_logprobs を削除。Chat Completions では logprobs も削除。Responses では include から message.output_text.logprobs を削除 |
| データレジデンシー | 3モデルとも、EU データレジデンシーは Standard 処理でのみ利用可能。Astra の Fast mode にはレイテンシ SLA がない |
| effort の途中変更 | レスポンス間で effort を変えるなら、標準のシングルエージェントのリクエストで configuration_update アイテムを使う。キャッシュのためにリクエストレベルの reasoning.effort は変えない |
| プロンプトキャッシュ | GPT-5.5 以前から移行する場合、prompt_cache_retention を prompt_cache_options.ttl（"30m"）に置き換える。キャッシュの境界やキャッシュ書き込みの課金も確認する |
| 不要な承認待ち | 承認を求めて止まり続けるなら、「自走と最後までのやり切り」のプロンプトを使う |
プロンプトキャッシュの変化は、コストに直結するので少し補足しておきます。prompt caching ガイドによると、GPT-5.6 以降では次のようになっています。
| 挙動 | GPT-5.6 以降 | GPT-5.5 / GPT-5.5 Pro |
|---|---|---|
| キャッシュ読み取り料金 | キャッシュなし入力の 0.1 倍 | モデルごとのキャッシュ入力料金 |
| キャッシュ書き込み料金 | キャッシュなし入力の 1.25 倍 | 追加料金なし |
| 寿命の制御 | prompt_cache_options.ttl |
prompt_cache_retention |
| 指定できる値 | "30m" |
"24h" のみ |
| キャッシュの寿命 | 最後の書き込みまたは再利用から少なくとも30分 | 通常は約30分、最大24時間 |
| 最小キャッシュ対象プレフィックス | 可視入力 1,024 トークン | リクエスト設定によって変わる |
キャッシュ書き込みに課金が発生するようになったのが大きな違いです。キャッシュが効かない構成のままだと、書き込み代だけ払い続けることになりかねないので、configuration_update でプレフィックスを保つ工夫がより大事になっています。
移行作業の全体の流れを図にすると、次のようになります。
⑥のプロンプトは、症状が出たものだけ足すのがおすすめです。5つ全部を最初から入れると、どのプロンプトが何に効いているのか分からなくなります。
まとめ
GPT-6 のプロンプティングガイドを通して読むと、Astra は「賢くて、慎重で、丁寧すぎる」モデルだという印象を受けます。聞きすぎる、スキルの文面に忠実すぎる、フォーマットしすぎる、テストしすぎる。どれも真面目さの裏返しで、ガイドのプロンプトはそれを「アプリに合った加減」に整えるためのものになっています。
一番持って帰っていただきたいのは、スキルや AGENTS.md の監査です。ガイドの中で唯一「strongly recommend（強く推奨）」と書かれている項目で、指示に敏感なモデルほど、読み込ませているファイルの中の古い指示や矛盾した指示の影響を受けます。プロンプトを足す前に、まず手元のスキルファイルを見直してみてください。「止まった理由をスキルから引用させる」プロンプトは、その棚卸しの道具としても使えます。
もう1つの軸は、自律性のレベルを自分で決めることです。「質問して止まる」のは、人が横にいるアプリなら長所です。任せきりのエージェントなら、「形にしてから聞く」「できる？はやって」のプロンプトで背中を押す。どちらが正解というより、アプリの性格に合わせて選ぶ設計になっています。
次のステップとしては、まず自分のアプリで一番困っている挙動を1つ選び、対応するプロンプトを1つだけ入れて評価してみるのがおすすめです。モデルは3つあり、価格も $10 / $50 の Astra から $0.1 / $0.5 の Luna まで幅があるので、プロンプトの調整とあわせて、タスクごとのモデル選びも見直すと、コストと品質のバランスがかなり良くなるはずです 🎉