Tracks
開発者向けアソシエイトAIエンジニア
26時間
GPT-6 Astra APIとは？
GPT-6 Astra APIは、2026年9月3日にリリースされたOpenAIの新たなフラッグシップモデルへ、Responses API経由でアクセスする方法です。本チュートリアルで重要なのはインターフェースです。gpt-6-astra はOpenAIのResponses APIでテキストと画像入力を受け付けます。推論努力は lowからmaxまでで、none はありません。
本チュートリアルの例では client.responses.create を使用し、client.chat.completions.create は使いません。移行時はリクエスト、出力、ツール結果の形式も変更が必要です。さらに temperature、top_p、ログ確率の設定はAstraが非対応のため削除してください。最初の呼び出しの前に、価格を確認しておきましょう。
GPT-6 Astraの料金はいくら？
入力トークンが最大272,000までのリクエストでは、標準料金は通常の入力トークン100万あたり$10、出力トークン100万あたり$50です。キャッシュ済み入力は100万あたり$1、キャッシュ書き込みは100万あたり$12.50です。
しきい値を超えると、OpenAIは入力とキャッシュ関連に2倍、出力に1.5倍の係数を適用します。高いレートは超過分だけでなく、リクエスト全体に適用されます。本チュートリアルの実行はいずれもしきい値に達しませんでした。
GPT-6 Astra APIで何を作る？
ステージングアプリは小さなFlask製のタスクボードです：ホームページ、タスク追加フォーム、完了ボタン、そして /health エンドポイント。完全なコード（ステージングアプリを含む）はGitHubリポジトリにあります。
テスト前に3件のシード済みタスクが表示されます。画像：著者作成。
アプリには意図的な不具合が1つあります。エージェントには3つのチェックがありますが、それらを検出できるよう設計されているのはテストスイートだけです。
なぜアプリは空のタスクタイトルを受け入れるのか？
タスク作成エンドポイントは空タイトルを拒否しません。プロンプトで明かさずに、既知の失敗をエージェントが見つけられるよう、この挙動を残してあります。
エージェントはどのリリースチェックを実行できる？
エージェントは3つのツールを呼び出せます：
-
run_test_suiteはpytestを実行し、約250件のHTTPリクエストを含む一括インポートテストも含みます。 -
check_ui_flowはPlaywrightでタスクを追加し、表示を確認します。 -
check_staging_healthは/healthにGETリクエストを送信します。
いずれもモックなしでステージングを相手に実行します。ブラウザチェックは固定コードで、モデル作成のコンピュータ利用デモは後半で扱います。
PythonでGPT-6 Astra APIをセットアップする方法
gpt-6-astraにアクセス可能なOpenAI APIキーが必要です。platform.openai.com/api-keysでキーを作成し、プロジェクトでgpt-6-astra が有効になっていることを確認してください。エンタープライズワークスペースでは、リリース時点でAstraがデフォルト無効です。
以下のコマンドはWindows PowerShellを使用し、本チュートリアルに必要なパッケージをすべてインストールします。ステアリングのデモ用にOpenAIのrealtimeも含みます。
python -m venv .venv
.venv\Scripts\Activate.ps1
Copy-Item .env.example .env
pip install "openai[realtime]" flask pytest playwright pydantic matplotlib python-dotenv streamlit
playwright install chromiummacOSやLinuxでは、アクティベーションをsource .venv/bin/activate 、コピーをcp .env.example .envに置き換えてください。
次にAPIキーを新しい.envに追加します。コピーした.env を開き、OPENAI_API_KEY=sk-...を追記します。これはpython-dotenvが読み込み、SDKが自動的に認識するため、コード内でキーを渡す必要はありません。
プロジェクト固有の依存や.envファイルに不慣れな場合は、当社の仮想環境および環境変数ガイドをご覧ください。キーが機能することを確認してから先へ進んでください。
すでにResponses APIでAPIキーが動いている場合は、次の小節を飛ばし、同期ツールループから始めてください。最初のリクエストはセットアップ確認のみです。
最初のGPT-6 Astra API呼び出しを行う
キーを用意したら、dotenvで読み込みます。その後、OpenAIクライアントを作成し、client.responses.create()で最初のリクエストを送信できます。最小のリクエストは次のとおりです。
from dotenv import load_dotenv
from openai import OpenAI
load_dotenv()
client = OpenAI()
response = client.responses.create(
model="gpt-6-astra",
reasoning={"effort": "low"},
input="In one sentence, what is a staging environment used for?",
)
print(response.output_text)レスポンスのusage フィールドには、後ほどコスト計算に必要なトークン数が記載されています。
同期のGPT-6 Astraツールループを構築する
以下のスニペットは抜粋です。実行可能な版は付随のGitHubリポジトリにあります。
まず非同期には手を付けず、通常版を構築しました：
-
モデルを呼び出す
-
function_call項目の有無を確認 -
該当ツールを実行
-
previous_response_idで結果を送り返す -
モデルがツール要求をやめるまで繰り返す
このブロッキングループが、非同期比較のベースラインです。
for turn in range(max_turns):
response = client.responses.create(
model="gpt-6-astra",
reasoning={"effort": "low"},
tools=TOOLS,
input=next_input,
previous_response_id=previous_response_id,
)
calls = [item for item in response.output if item.type == "function_call"]
if not calls:
final_text = response.output_text
break
outputs = [
{"type": "function_call_output", "call_id": call.call_id, "output": run_tool(call)}
for call in calls
]
next_input, previous_response_id = outputs, response.idベースライン実行での発見
ベースライン実行では、モデルは各ツールを順に呼び出しました。既知のバリデーション失敗を検出し、no-goの判断を返しました。3回の実行で、総ウォールクロック時間は平均23.40秒でした。この平均はツール個別ではなく、全体の実行時間です。
GPT-6 Astraの非同期ツール呼び出しはどう動く？
ツールのスキーマに"async": true を付けると、アプリはその結果を後回しにでき、その間にモデルは作業を続行するか待機します。ツールの実行とバックグラウンドジョブの管理は引き続きアプリ側の責務です。
独立したチェックを同時実行する方法
私は run_test_suite と check_ui_flow を非同期にし、このデモでは保留中の作業バッチが常に1つのみであるため、引数なしのアプリ定義wait_for_tasks ツールを追加しました。引数なしのwaitにより、例を小さく保てます。
本番ランナーでは、ジョブをタスクハンドルで識別し、各ハンドルを元のcall_id に紐づけ、次のステップが保留中の結果に依存するときのみ待機します。
各完了済み結果は元の call_id に対して返し、その後にwaitツール自身のcall_id で待機状態を返します。
TOOLS = [
{"type": "function", "name": "run_test_suite", "async": True, ...},
{"type": "function", "name": "check_ui_flow", "async": True, ...},
{"type": "function", "name": "check_staging_health", ...},
{"type": "function", "name": "wait_for_tasks", ...},
]この実行では、アプリは各マーク済み呼び出しをスレッドプールに投入しました。バックグラウンドチェックを実行している間に、速い同期ヘルスチェックを実施し、その後wait_for_tasks で保留中チェックの完了までブロックしました。
非同期ツール呼び出しでウォールクロック時間は短縮する？
3回の実行で、非同期は平均ウォールクロック時間を23.40秒から18.94秒へと19.1%短縮しました。平均だけ見ると単純に見えますが、実行ごとのばらつきは大きく、以下のグラフのとおりです。3回では本事例を示すには十分ですが、本番レイテンシを予測するには不十分です。
両モードで実行時間にばらつきがありました。画像：著者作成。
なぜ並行チェックでレースコンディションが起きた？
ブラウザチェックと一括インポートテストを同時に実行すると、双方が同じインメモリのタスクリストを変更するため、一括インポートのアサーションが失敗することがありました。テストが排他的アクセスを前提にしていたためです。ランナーかテストのどちらかでデータを分離すれば、レースは回避できます。
UIテスト向けの制限付きGPT-6 Astraコンピュータ利用
コンピュータ利用について、GPT-6 Astraのドキュメントはコード実行を推奨し、代替として構造化されたcomputer ツールも引き続きサポートしています。コード実行では1回の呼び出しで複数の操作、ループ、条件分岐を組み合わせられます。一方、computer ツールは構造化されたマウスやキーボード操作を1件ずつ返し、アプリ側で翻訳・再生します。
コンピュータ利用ランナーを制限する方法
クラス名をBrowserSandboxにしましたが、名前ほど強固ではありません。モデル作成のコードにPlaywrightのpage、log() 関数、expect_text() ヘルパーを与えます。Pythonは exec() に組み込みを注入でき、ページは他オリジンにも移動可能です。
sandbox_globals = {"page": self.page, "log": log, "expect_text": expect_text}
exec(code, sandbox_globals)これはセキュリティ境界ではなく、あくまでデモ用ランナーとして扱ってください。モデル作成のコードには、ファイルシステム、プロセス、ネットワーク、オリジンに制限を設けた分離プロセスまたはコンテナが必要です。
UIチェックでは何が起きた？
境界を設けるにはハードストップが必要なため、ループを8ターンに制限しました。モデルはページを確認し、フォーム入力を見つけ、「UI flow check, cobalt otter 73921」というタイトルを作成・送信し、表示を確認しました。所要は13秒でした。詳細例は、Astraの前身モデルを使ったGPT-5.4のコンピュータ利用チュートリアルをご覧ください。
GPT-6 Astraのターン途中ステアリングはどう動く？
ターン途中のステアリングは、gpt-6-astra でのみ利用可能で、WebSocket接続が必要です。
接続を開いてレスポンスを作成し、生成中に新しい指示を含むresponse.steer イベントを送信します。response.steer.accepted は、更新が適用待ちであることを意味します。自動継続を作成する前に、サーバーは現在の出力アイテムと、すでに走っているホスト側ツール作業を完了させます。
クライアントのツール結果や承認がまだ必要な場合は、response.steer.pending が不足している入力を示します。
async with client.responses.connect() as connection:
await connection.response.create(model="gpt-6-astra", input=TASK)
async for event in connection:
if event.type == "response.created" and initial_response_id is None:
initial_response_id = event.response.id
await asyncio.sleep(1.0)
await connection.response.steer(
previous_response_id=initial_response_id,
input="Also add a rollback plan, but skip mobile.",
)1秒の遅延は実験コードに合わせ、最初のレスポンスの開始時間を確保するためのものです。これがないと、レスポンスライフサイクルの別段階をテストすることになります。
ターン途中ステアリングで変わらないものは？
ステアリングは元のレスポンスを書き換えません。更新で中断された場合、そのレスポンスはstatus: "incomplete" とincomplete_details.reason: "steered" で終了します。続いて、後継のレスポンスが新しい指示で継続します。
最初のレスポンスが更新適用前に完了した場合は、そのまま完了のままです。ステアリングは、すでに開始されたクライアント側のアクションを元に戻したりキャンセルしたりしません。そこの制御はアプリケーション側にあります。キューイングされたステアリングは現在のWebSocket接続にのみ存在するため、再接続前に更新内容を記録してください。
比較パスでは、最初のレスポンスを完了させた後、結合した指示で新しいリクエストを送信します。2回の実行で、ステアリングは平均26.91秒、完了→再開パスは50.02秒でした。この比較は、キャンセル→再開ポリシーを含まず、最終テキストの正確性も評価していません。
時間とコストの2回平均。画像：著者作成。
再開パスは同様の要求を含む2つの完全なレスポンスを生成します。その構成が時間差の一因であり、この2回の結果をステアリングの一般的なベンチマークとみなすべきではありません。
会話途中でGPT-6 Astraの推論努力を変更する方法
gpt-6-astra はlow から max までの推論努力をサポートします。努力を上げると推論トークンの使用は増え得ますが、必ず異なる答えになるとは限りません。configuration_update は、次回以降のレスポンスを変更し、新たな更新で上書きされるまで有効です。リクエストレベルの設定自体は変わりません。
このパイプラインではレポートが会話を終えるため、更新は最終ステップのみに影響します。
response = client.responses.create(
model="gpt-6-astra",
previous_response_id=previous_id,
reasoning={"effort": "low"}, # default remains low
input=[
{"type": "configuration_update", "reasoning": {"effort": "high"}},
{"role": "user", "content": "Diagnose the root cause and recommend a fix."},
],
)同じ失敗トレースを両方の努力レベルで使い、診断とトークン使用を比較しました。
注意点が1つ：レスポンスのreasoning.effort フィールドは、configuration_update で選ばれた努力ではなく、あくまでリクエストレベルの設定を報告します。適用確認にこのフィールドを使わないでください。
高い推論努力で診断は変わった？
統合実行全体では、引き上げたステップで108個の推論トークンを使用しました。その他のlow のステップはゼロでした。より長い失敗トレースを使った以前の単独テストでも、lowはゼロ、高は318でした。どちらもバリデーションバグを特定できたため、努力を上げるとトークン使用は変わるが、診断は変わらない場合があると言えます。
構成更新は標準の単一エージェントリクエストでのみ機能します。更新を連続させるとAPIは拒否し、自動圧縮や自動切り詰めと併用はできません。
GPT-6 Astraの構造化出力を使う方法
パイプラインの最終ステップでは、client.responses.parseを呼び出して、自由記述テキストを検証済みのPydanticモデルに置き換えます。
class GoNoGoReport(BaseModel):
decision: str
summary: str
checks_completed: list[str]
failures: list[str]
risks: list[str]
follow_up_actions: list[str]
confidence: float
response = client.responses.parse(
model="gpt-6-astra",
previous_response_id=previous_id,
text_format=GoNoGoReport,
input=[...],
)Pydanticはここで宣言したフィールド型を検証します。レポートが証拠と一致することまでは保証せず、この版ではdecision を2値に、confidence を範囲に制限していません。
go/no-goレポートは何を捉えた？
レポートはdecision: "no_go"を返し、前述のバリデーション失敗をfailuresに、並行性の問題をrisksに分類しました。後者については「共有ステージングデータに対する同時UIチェックからの干渉の可能性」と記載しました。プロンプトはそのリスク名を挙げていません。
レイテンシとコストはこのスキーマの外で扱い、コードで計算してください。モデルはツールからの証拠をもとにレポートのフィールドを埋めます。
Streamlitインターフェースはコマンドラインランナーと同じジェネレーターを利用します。ツールイベントを到着順にレンダリングし、その後、解析済みレポートをReport タブとJSON タブに表示します。