使用ガイド
hiapi API 経由で gpt-6-astra を使ってEコマース向け商品画像を生成する
写真は生成できない——しかし商品リスティングのその他すべてのコンテンツを執筆できる。
GPT-6 Astra は画像を生成しない——Eコマースの技術スタックで真に活躍する場面はここだ
もしここに来たのが GPT-6 Astra で商品写真を描かせたいという理由なら、それはできない——このモデルは純粋なテキストと推論のモデルであり、/v1/responses エンドポイントを通じてアクセスし、画像・音声・動画を一切出力しない。しかし Eコマースチームにとって、これは行き止まりではない。すべての商品画像はあるページ上に存在し、そのページには説明文、alt テキスト、カスタマーサポートの回答、そして同じ訴求ポイントを3つの広告チャネル向けに展開したバージョンも必要になる——そして GPT-6 Astra はまさにこのレイヤーのために生まれた。本ガイドでは商品画像ワークフローにおけるテキスト部分を扱う。バッチ説明文生成、商品リスティング向けの構造化データ抽出、顧客 Q&A をカバーし、Responses API への実際のリクエスト例も添える。写真そのものが必要なら、GPT Image 2 のような画像モデルと組み合わせ、写真の周囲にあるすべてのテキストを GPT-6 Astra に担当させよう。
なぜ Chat Completions ではなく Responses API なのか
GPT-6 Astra は POST /v1/responses のみで公開されている——OpenAI が新しい推論モデル向けに使っているエンドポイントファミリーと同じであり、従来の Chat Completions 形式ではない。商品パイプラインに組み込むなら、重要な違いが3つある：
messagesではなくinputを使う。 渡すのは入力アイテムの配列であり、messagesリストではない。Chat Completions クライアントをそのまま流用するのではなく、リクエスト構築コードを改修する必要がある。- 実用上は
stream=trueが既定で、状態管理にはstore=falseを使う。 モデルはテキストが届くたびにresponse.output_text.deltaイベントをストリーミングで発行し、構造化アイテムが完了するとresponse.output_item.doneを発行する。store=falseの場合、呼び出し間でサーバー側には何も保持されない——複数ターンのカスタマーサポート対話を実行しているなら、次のinput配列で以前のユーザー／アシスタントのターンを自分で再送する必要がある。 temperatureではなくreasoning.effortを使う。 この統合にはtemperature、top_p、max_output_tokensの調整項目はない。出力の品質／レイテンシはreasoning.effortで制御し、値はlow、medium、high、xhigh、maxのいずれか（noneは存在しない——推論は無効化できない）。説明文生成のような短く決定的なタスクにはlowかmediumで通常は十分。判断力を要する場面、たとえばポリシーに敏感な問題を含むサポート返信の下書きなどにはhigh以上を残しておこう。
ベース URL は https://api.hiapi.ai/v1 で、キーは他の hiapi モデルと同じものを使う。
ユースケース 1：構造化出力で商品説明を一括生成する
最も直接的な Eコマースとの接点は、仕様表を大規模にブランドトーンに沿った商品リスティング文案へ変換することだ。モデルが返す自由テキストを解析するのではなく、text.format.type=json_schema を使えば、各レスポンスが CMS にそのまま取り込める形——タイトル、短い説明、長い説明、箇条書き——で1回の呼び出しで返ってくる。
import json
import requests
resp = requests.post(
"https://api.hiapi.ai/v1/responses",
headers={
"Authorization": f"Bearer {HIAPI_KEY}",
"Content-Type": "application/json",
},
json={
"model": "gpt-6-astra",
"store": False,
"reasoning": {"effort": "low"},
"input": [
{
"role": "system",
"content": "You write concise, factual e-commerce listing copy. "
"Never invent specs that aren't in the input.",
},
{
"role": "user",
"content": "Product: ceramic pour-over coffee dripper, 400ml, "
"matte white, dishwasher safe, fits standard filters. "
"Write listing copy for this product.",
},
],
"text": {
"format": {
"type": "json_schema",
"name": "listing_copy",
"schema": {
"type": "object",
"properties": {
"title": {"type": "string"},
"short_description": {"type": "string"},
"long_description": {"type": "string"},
"bullet_points": {
"type": "array",
"items": {"type": "string"},
},
},
"required": [
"title",
"short_description",
"long_description",
"bullet_points",
],
"additionalProperties": False,
},
}
},
},
stream=False,
)
data = resp.json()
このコードを商品データベースの SKU ごとに実行すれば、チャットウィンドウからコピペした散文ではなく、一貫性がありスキーマ検証済みの文案が得られる。システムプロンプトで仕様の捏造を厳しく禁止しておこう——放っておくとモデルは、こちらが与えていない機能についても生き生きと書き立ててくれる。
ユースケース 2：自社ドキュメントに基づくカスタマーサポート Q&A
サポートアシスタントでは、store=false の再送ループが鍵となるパターンだ。各ターンで、現在の会話とツール結果を input に入れて送り返す。送らなかった内容はモデルは一切覚えていない。これは意図的なトレードオフで、入力トークンの再送分だけコストは少し増えるが、会話状態がベンダーではなく自社アプリに帰属する（自社 DB から会話をマスキングしたり、分岐・復元したりする必要がある場合に有用だ）。
history = [
{"role": "system", "content": "Answer only from the provided product FAQ context. "
"If the answer isn't in context, say so and offer to escalate."},
]
def ask(user_message: str, faq_context: str) -> str:
history.append({"role": "user", "content": f"Context:\n{faq_context}\n\nQuestion: {user_message}"})
resp = requests.post(
"https://api.hiapi.ai/v1/responses",
headers={"Authorization": f"Bearer {HIAPI_KEY}", "Content-Type": "application/json"},
json={
"model": "gpt-6-astra",
"store": False,
"reasoning": {"effort": "medium"},
"input": history,
},
)
answer = resp.json()["output"][-1]["content"][0]["text"]
history.append({"role": "assistant", "content": answer})
return answer
注文状況の照会や返品処理のトリガーなどが必要な操作では、tools 内で関数として宣言しよう——モデルは function_call を返し、バックエンドがそれを実行し、モデルが続行する前に function_call_output で結果を同じ call_id を付けて返す。これによりモデルが注文データベースに直接触れることは決してなくなる。
ユースケース 3：チャネル別のマーケティング文案バリエーション
同じ商品事実でも、商品ページ、メールの件名、30 文字の広告見出しでは異なる言い回しが必要だ。GPT-6 Astra は response.output_text.delta イベントをストリーミングで発行するため、複数のチャネル向けバリエーションを1回の呼び出しで生成し、完全なレスポンスを待たずにコンテンツが届くそばから即座にレンダリングできる——社内ツールのリアルタイムプレビューに使うなら便利だ。ここでも reasoning.effort は low に保とう。短いコピーのトーンマッチングに強い推論は不要であり、マーケターがリアルタイムで反復する際のレイテンシを低く保てる。
料金はどのように計算されるか
GPT-6 Astra はトークン課金で、段階的な加算ではなくハードな価格ティアの断崖がある——大規模な商品カタログを1回のリクエストでバッチ処理する前に、これを理解しておく価値がある：
| ティア | 入力 | 出力 | キャッシュ入力 | キャッシュ書き込み |
|---|---|---|---|---|
| 標準（≤272,000 入力トークン/リクエスト） | $2.50 / 100 万トークン | $12.50 / 100 万トークン | $0.25 / 100 万トークン | $3.125 / 100 万トークン |
| 長コンテキスト（>272,000 入力トークン/リクエスト） | $5.00 / 100 万トークン | $18.75 / 100 万トークン | $0.50 / 100 万トークン | $6.25 / 100 万トークン |
このしきい値はリクエストの総入力に対して検査される——キャッシュの読み取りと書き込みを含む——そして一度超えると、リクエスト全体が長コンテキスト料金で課金され、272,000 を超えた分のトークンだけではない。上記のユースケース（単品の説明文生成、1ターンのサポート対話、1つの文案バリエーション）ではこの線には程遠い。主に影響するのは、カタログ全体や長いドキュメントを1回の呼び出しに詰め込む場合だ。バッチ処理を約束する前に、hiapi.ai/pricing で現在の料金を確認しよう。これらの料金は利用量に基づき、変更される可能性がある。
これは技術スタックの残りの部分とどう連携するか
上記のいずれも本物の画像モデルの代わりにはならない——GPT-6 Astra には /v1/tasks へのアクセス権がなく、視覚的な出力も生成できない。ワークフローでこれらの文案に合わせた商品写真やライフスタイル画像が必要なら、GPT Image 2 のような画像モデルを別途呼び出す必要があり、両者のリクエスト形式とエンドポイントは互換性がない。モデル ID や正確なリクエスト形状を含む完全な設定詳細は、GPT-6 Astra API ガイドとモデルページを参照。
よくある質問
GPT-6 Astra は商品画像を生成できますか？
いいえ。これは /v1/responses 経由でアクセスする純テキストモデルで、画像・音声・動画を出力しません。商品リスティングのビジュアル部分には画像モデルを組み合わせてください。
input は Chat Completions で使っていた messages 配列とどう違うのですか？
input は Responses API が会話ターンとコンテンツに使うリクエストフィールドであり、messages の直接の代替品ではない。そのため Chat Completions クライアントコードは、フィールド名を変えるだけでなく改修が必要だ。
説明文生成のような単純なタスクでは推論をオフにする必要がありますか？
オフにはできない——reasoning.effort=none は存在しない。短くリスクの低い生成タスクには low を使おう。5段階の中で最速かつ最安だ。
store=false だと会話履歴が失われるのですか？
いいえ。プラットフォームが代わりに保存しないという意味だ。アプリケーションは必要なターンを次の input 配列で再送する。これによりどのコンテキストを含めるかを制御でき（会話のマスキングや分岐も可能になる）、その代わりにこれらのトークンを再び入力として支払うことになる。
多くの商品説明呼び出しで同じシステムプロンプトを繰り返すと、キャッシュ割引は受けられますか？
保証はされない。キャッシュヒットは文字通りの繰り返しだけでなく、サーバー側のポリシーとタイミングに依存する——割引が必ず適用されると仮定せず、レスポンスの usage オブジェクトにある cached_tokens を確認しよう。
カタログ全体を1回のリクエストにバッチで詰め込むとどうなりますか？ 総入力トークン（キャッシュ内容を含む）が 272,000 を超えると、リクエスト全体——入力、出力、キャッシュ利用分——が長コンテキスト料金で課金され、しきい値を超えた部分だけではない。ほとんどの単品や単発対話の呼び出しでは該当しないが、大規模なカタログを1回の呼び出しに詰め込む前にトークン数を確認しておく価値がある。
