GPT-6 Astra API入門：モデル仕様・リクエストパラメータ・接続時の注意点

モデルの役割を、実行環境・レスポンス・検証項目から整理します。

新しいモデルが出るたびに仕様表は公開されますが、実際に接続してみると「ドキュメントに書いてあること」と「このリクエストで確認できたこと」の区別が曖昧になりがちです。この記事では GPT-6 Astra に最小構成で接続し、レスポンスの各フィールドが何を意味するのかを確認します。後から読む方が同じ手順を再現し、問題箇所を切り分けられるよう、検証していない項目は検証していないと明記します。

目次

1. 定義と本記事の検証範囲
2. 環境と設定の記録
3. 最小のテキストリクエストを実行する
4. レスポンスと使用量を読む
5. 期待した結果が得られないときの切り分け
6. 確認できたこと、別途検証が必要なこと

---

1. 定義と本記事の検証範囲

GPT-6 Astra は OpenAI のモデルで、複雑な推論・コーディング・コンピュータ操作・リサーチ・ドキュメント作成といった負荷の高い作業に向けた位置づけです。

項目	GPT-6 Astra
モデルID	gpt-6-astra
コンテキストウィンドウ	1,050,000 トークン
最大出力	128,000 トークン
入力 / 出力	テキスト・画像 / テキスト
推論強度	low、medium、high、xhigh、max
ツール呼び出し	公式ドキュメントで対応と記載
非対応	ファインチューニング、Embeddings、Realtime、Assistants
知識カットオフ	2026年4月30日

出典は OpenAI 公式モデルドキュメントです。

ここで重要なのは、この表は「仕様」であって「検証結果」ではないという点です。本記事で実際に確認したのは、テキストによる呼び出しとレスポンスの読み取りだけです。画像入力とツール実行は別の能力であり、まとめて検証することはできません。一つの成功例から全体の能力を推測しない、というのが本記事の方針です。

なお、知識カットオフは学習データの時点を示すもので、検索の時点ではありません。また、コンテキストウィンドウが大きいことは「入る」ことを意味するだけで、「正しく使われる」ことの保証ではありません。

---

2. 環境と設定の記録

再現性のため、実行環境を記録しておきます。

項目	値
実行日	2026年10月13日
OS	Windows 10 (19045)
クライアント	curl 8.13.0 / Node.js v24.21.0
エンドポイント	https://api.crazyrouter.com/v1
モデルID	gpt-6-astra
認証	環境変数に格納した APIキーを Bearer トークンとして送信

今回は OpenAI 互換の第三者経由で接続しています。接続先のモデル対応状況は Crazyrouter のモデル情報（英語）で確認できます。

ここで一つ注意点があります。プロトコルが互換であることと、すべての機能が同じように使えることは別です。 経由する経路が異なれば、対応パラメータやツールの挙動が変わる可能性があります。公式ドキュメントの記載は仕様の根拠にはなりますが、特定の経路での動作保証にはなりません。

まずモデルIDが実在するかを確認します。モデル一覧を取得するのが確実です。

curl https://api.crazyrouter.com/v1/models \
  -H "Authorization: Bearer $API_KEY"

今回は172件のモデルが返り、その中に gpt-6-astra が含まれていました。ただし一覧に表示されることは、呼び出しが成功することの証明にはなりません。 実際に呼んでみる必要があります。

---

3. 最小のテキストリクエストを実行する

題材は短い関数の挙動説明にします。出力が短く、正解を自分で判断でき、再現もしやすいためです。

curl https://api.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-astra",
    "messages": [
      {"role": "user", "content": "次の関数の挙動を1文で説明してください。\n\ndef f(xs):\n    return [x for x in xs if x % 2 == 0]"}
    ]
  }'

必要なパラメータは三つだけです。model はモデルIDで、別名や推測した文字列は使えません。messages は役割と内容の配列です。Authorization ヘッダーは Bearer の後に半角スペースを一つ入れます。ここで余分な引用符や改行が混ざると認証エラーになりますが、原因が分かりにくいので注意してください。

実際に返ってきた内容は次のとおりです。

この関数は、`xs` の要素から偶数だけを元の順序で取り出し、新しいリストとして返します。

内容は正しく、所要時間は約4.4秒でした。

図1：最小リクエストの構成（AI生成の図解。スクリーンショットではありません）

---

4. レスポンスと使用量を読む

レスポンスで必ず確認すべきフィールドは三つです。

• model — 実際にどのモデルで処理されたかを示します。リクエストに書いた値を信じるのではなく、返ってきた値を確認してください。今回は gpt-6-astra が返りました。
• finish_reason — このターンがどう終わったかを示します。stop は正常終了、length は出力上限での打ち切り、tool_calls はツール呼び出しの要求です。tool_calls の場合、モデルは何も実行していません。実行はアプリケーション側の責任であり、結果を返して初めて次に進みます。
• usage — 課金の根拠となる唯一の数値です。今回の実行では次の値でした。

{"prompt_tokens": 42, "completion_tokens": 36, "total_tokens": 78}

この usage について、検証中に見つかった点を共有します。同程度に短い入力でも、リクエストの構成によって prompt_tokens が大きく変動しました。 上記の例では42でしたが、別の構成では4,000を超える値が返ったケースもありました。したがって、自分が書いたプロンプトの長さから費用を見積もるのは信頼できません。 必ず実際の usage を読んでください。

もう一点、エンドポイントについての注意です。/v1/responses も利用可能でしたが、レスポンスの構造が /v1/chat/completions とまったく異なります。 出力フィールドは choices ではなく output でした。両者でフィールド名が同じだと仮定したコードは、エンドポイントを切り替えた時点で壊れます。

この差は、将来ツール実行まで扱う段階になると影響が大きくなります。レスポンスを読む処理を一か所にまとめ、エンドポイントごとの差異をその中に閉じ込めておくと、後から切り替えるときの修正範囲が小さくて済みます。最初の一回を動かす段階では過剰に見えますが、二つ目のエンドポイントを試す時点で効いてきます。

なお finish_reason が length だった場合、出力は途中で切れています。このとき返ってきたテキストは一見完結しているように読めることがあり、内容だけを見て判断すると見落とします。 必ずフィールドで確認してください。JSON を期待している場合は、途中で切れた時点でパースに失敗するため気づけますが、自由記述の場合は気づく手がかりが finish_reason しかありません。

図2：確認すべきレスポンスフィールド（AI生成の図解。スクリーンショットではありません）

---

5. 期待した結果が得られないときの切り分け

症状を四つに分けると、調査の順番が決まります。

症状	考えられる原因	確認手順
HTTPエラー	認証・モデルID・リクエスト形式	レスポンスボディの code と request id を読む
内容が空	パラメータの組み合わせ、入力の問題	最小構成に戻して切り分ける
出力が途中で切れる	出力上限に到達	finish_reason が length か確認
内容が要求と合わない	指示が曖昧、制約不足	指示を具体化。ここで初めてプロンプトを調整する

モデルIDを誤った場合の実際のレスポンスを挙げます。gpt-6-astra-latest という存在しないIDを送ったところ、HTTP 404 とともに次が返りました。

{
  "error": {
    "code": "model_not_found",
    "message": "Model gpt-6-astra-latest is not provided by ... (request id: ...)"
  }
}

code と request id が含まれているため、問い合わせの際はこの二つを添えると話が早くなります。ステータスコードだけで原因を推測せず、必ずボディを読んでください。

切り分けの順番として、最小構成に戻す手順を習慣にしておくと早く済みます。具体的には、システムメッセージを外す、オプションのパラメータをすべて削る、入力を一行に減らす、の三段階です。この最小構成が通るなら原因は追加した要素のどれかにあり、通らないなら認証か経路の問題です。原因を推測しながらパラメータを足したり引いたりするより、この二分法のほうが確実に速いです。

パラメータについても一点記録しておきます。temperature、top_p、logprobs を指定したリクエストはいずれも HTTP 200 を返しました。ただしレスポンスに logprobs のデータは含まれていませんでした。つまり**「受け付けられた」ことと「効いている」ことは別**です。パラメータが実際に機能しているかは、出力が変化するかどうかで確認する必要があります。確認方法としては、同じプロンプトに対して値を大きく変えた二回のリクエストを送り、出力を比べるのが簡単です。差が出なければ、そのパラメータは無視されている可能性が高いと判断できます。

---

6. 確認できたこと、別途検証が必要なこと

今回の検証範囲を明示して締めます。

項目	状態
モデルIDの存在	確認済み（一覧に含まれ、呼び出しも成功）
テキスト入出力	確認済み
usage の取得	確認済み
エラー時の code と request id	確認済み
/v1/responses の応答構造の差異	確認済み
画像入力	未検証
ツール実行を伴う連続処理	本記事では未検証（別記事の範囲）
長いコンテキストでの精度	未検証
各パラメータが実際に効くか	未検証（受理されることのみ確認）

一つのテキスト呼び出しが成功したことから、エージェント的な能力全般を推測することはできません。自分の用途に必要な機能を一つずつ、最小のリクエストで確認していくのが結局は近道です。本記事の手順をそのまま使って、まずご自身の環境で usage まで読めるところを目指してみてください。