HiAPI で gpt-6.1 Sol を呼び出す方法：curl、Python、ストリーミングの実測（日本語チュートリアル）

本文の目標と前提

この記事を読み終えると、1 本の HTTP リクエストで gpt-6.1 Sol を動かせるようになります。これは HiAPI 上の GPT-6.1 Sol ファミリーの中で、複雑なプログラミング、ドキュメント分析、多段階推論を主眼とするテキストモデルで、ストリーミングで返されるテキストを取得できます。そのままコピーできる curl と Python のサンプル、そして最もつまずきやすい 3 つのポイント——エンドポイントは /v1/responses（/v1/chat/completions ではない）、ストリーミング必須、input は配列でなければならない——を押さえられます。

前提： HiAPI の API キーが 1 つ。 API キーのページで作成して大切に保管し、毎回のリクエストで Authorization: Bearer sk-<你的 key> として送信します。

gpt-6.1 Sol は純粋なテキストモデル（対話 / 推論 / プログラミング）で、画像は生成しません。機能の説明とオンライン試用は gpt-6.1 Sol モデルページをご覧ください。

最小の動作サンプル

Sol ファミリーは Responses API を使います：POST /v1/responses。厳守すべきルールが 2 つあり、1 つでも欠けると 400 になります：

1. "stream": true —— モデルはストリーミングのみ対応で、stream:false は拒否されます。
2. input はメッセージオブジェクトの配列 —— ストリーミングを有効にした状態で生の文字列を渡すと input: has incorrect type になります。

curl

curl -N https://api.hiapi.ai/v1/responses \
  -H "Authorization: Bearer sk-<你的 key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "input": [
      {
        "type": "message",
        "role": "user",
        "content": [
          { "type": "input_text", "text": "用一句话解释什么是 API 速率限制。" }
        ]
      }
    ],
    "stream": true
  }'

-N は curl の出力バッファリングを無効にするので、Server-Sent Events（SSE）が 1 件ずつ返ってくるのをリアルタイムで確認できます。ストリームは event: / data: 行の連なりで、目的の本文は response.output_text.delta の断片に現れ、最終状態の response.completed イベントで全体がもう一度繰り返されます。

簡略形 "input": [{"role":"user","content":"……"}] でも動作します。上記の type/input_text の正規の書き方は、マルチモーダルやマルチターンを組み立てる際に安定するため、デフォルトでこれを使うことをおすすめします。

Python

SDK は不要です。HiAPI は普通の HTTP なので、requests で stream=True を有効にするだけです：

import json
import requests

API_KEY = "sk-<你的 key>"

payload = {
    "model": "gpt-6.1-sol",
    "input": [
        {
            "type": "message",
            "role": "user",
            "content": [
                {"type": "input_text", "text": "用一句话解释什么是 API 速率限制。"}
            ],
        }
    ],
    "stream": True,
}

with requests.post(
    "https://api.hiapi.ai/v1/responses",
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    },
    json=payload,
    stream=True,
    timeout=120,
) as resp:
    resp.raise_for_status()

    text = ""
    for line in resp.iter_lines(decode_unicode=True):
        if not line or not line.startswith("data:"):
            continue
        event = json.loads(line[len("data:"):].strip())
        etype = event.get("type")
        if etype == "response.output_text.delta":
            text += event["delta"]
        elif etype == "response.completed":
            usage = event["response"]["usage"]
            print(f"\n[tokens: in={usage['input_tokens']} "
                  f"out={usage['output_tokens']} total={usage['total_tokens']}]")

print(text)

JSON に含まれる type フィールドで分岐する（event: の行を解析するのではなく）方が安定します：各 SSE フレームは 2 行——event: <type> と data: <json>——で、data: 行だけをフィルタし、event["type"] を読めば十分です。

本番環境の要点

• モードはストリーミングのみ。 非ストリーミングの変種はなく、stream:false は即 400 です。クライアントは最初から SSE を前提に設計しましょう：読み取りタイムアウトを設け、切断後は再接続 / リトライを実装します。
• max_output_tokens は渡さないでください。 この実行プロファイルはこのパラメータを受け付けません（not supported by this execution profile が返ります）。長さを制御したい場合は prompt やシステム指示の中で制約してください。モデルは 1 回あたり最大約 12.8 万 token を出力できますが、この上限はパラメータでは設定できません。
• システムプロンプトはトップレベルの instructions（文字列）に置く——ある message に詰め込むのではなく：

{
  "model": "gpt-6.1-sol",
  "instructions": "你是一个简洁的助手，只用一句话回答。",
  "input": [
    { "type": "message", "role": "user",
      "content": [{ "type": "input_text", "text": "什么是 webhook？" }] }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

• reasoning.effort で推論の深さとコストを両立させる。 gpt-6.1 Sol は推論型モデルで、reasoning.effort は low / medium / high / xhigh / max の 5 段階に対応し、デフォルトは medium です。段階が低いほど消費する推論 token は少なくなります——そして推論 token は出力として課金されるため、最終状態イベントの usage.output_tokens_details.reasoning_tokens に現れます。低い段階で済むタスクでは高い段階を有効にしないようにしましょう。
• 構造化出力が必要なときは text.format を使う。 このモデルは JSON Schema の strict モードをサポートしており、prompt でフォーマットを祈るのではなく、解析可能な JSON を安定して出力させるのに適しています。
• ツール呼び出し（function calling）をサポート。 トップレベルの tools + tool_choice が使用でき、ツールの結果を会話に戻して推論を続けられるため、agent のシナリオに適しています。
• マルチターン対話：以前の user と assistant のメッセージを順番に input 配列へ追加し、次のリクエストを送るだけです。
• 認証失敗は 401。 key が誤っているか失効している場合は 401、code permission_denied（"This API key is invalid."）が返ります。これは即座に例外を投げてリトライしないでください——リトライでは誤った key は直りません。レスポンスボディの request_id をテクニカルサポートの調査に使います。
• 課金は token 単位。 input と output は別々に課金され、output の単価は input より明らかに高くなります。キャッシュヒットした入力 token はより安くなります。推論 token は output に含めて一緒に課金されます（つまり reasoning.effort を下げることは直接のコスト削減になります）。1 回の入力が約 27.2 万 token を超えると、より高いロングコンテキストの価格帯に入ります。具体的な数値は 料金ページのリアルタイムの値を基準にし、コードに価格をハードコードしないでください。

実測記録：実際に成功した 1 回のリクエスト

本文のサンプルはドキュメントの丸写しではありません——上記の curl で実際に /v1/responses を 1 回呼び出し（reasoning.effort: low、プロンプトは「用一句话解释什么是 API 速率限制」）、以下を観察しました：

• 最終状態の response.completed イベントの usage：input_tokens=31、output_tokens=28、total_tokens=59、うち output_tokens_details.reasoning_tokens=0——低い段階 + 簡単な質問では推論 token は 0 になり得て、コストはほぼ可視出力の部分だけです。
• テキストはストリーム中で response.output_text.delta として増分で到着し、最終状態では response.output[0].content[0].text から完全な結果を一度に取得できます。どちらの取得方法でも構いません。
• レスポンスボディには reasoning.effort のエコー、service_tier、prompt_cache_retention などのフィールドが含まれ、effort とキャッシュが実際に有効であることを確認できました。

いくつかのよくあるエラーも実際に発生させてみたので、照合してトラブルシュートに役立ててください（いずれも実際のレスポンスです）：

何を間違えたか	HTTP	code	message
/v1/chat/completions に送った	400	unsupported_protocol	Model does not support this protocol
stream:false を渡した	400	invalid_parameter	stream: must be true
max_output_tokens を渡した	400	invalid_parameter	max_output_tokens: is not supported by this execution profile
input を文字列で渡した	400	invalid_parameter	input: has incorrect type
key が無効	401	permission_denied	This API key is invalid.（request_id 付き）

一言でいうトラブルシュートの心得：400 が出たらまずこの 3 つを確認——エンドポイントは /v1/responses か、stream は true か、input は配列か。 「つながらない」のほとんどはこの 3 つのうちのどれかです。

関連リンク

• gpt-6.1 Sol モデルページ——機能、パラメータ、オンライン試用
• HiAPI ドキュメント——API 概要とその他のモデル
• 料金ページ——従量課金のリアルタイム単価
• まだ選定中ですか？ GPT-6 Astra vs GPT-5.6 Sol の選び方、そして同じく Responses API を使う GPT-6 Astra モデルページをご覧ください

よくある質問

OpenAI 公式 SDK で直接接続できますか？ gpt-6.1 Sol は Responses API プロトコルを使い、API の形状はそれと互換性がありますが、本文のサンプルは最も軽量な生の HTTP（requests + stream=True）を使っており、SDK に依存しないため、そのままコピーして動かせます。ポイントは base URL を https://api.hiapi.ai に向け、HiAPI の key を付けることです。

stream:false を渡すとずっと 400 になるのはなぜですか？ これは仕様であり、バグではありません。Sol ファミリーはストリーミングのみ対応で、stream は true でなければならず、そうでなければ invalid_parameter（stream: must be true）が返ります。クライアントを SSE を読むように変更してください。

出力の長さを制御するには？ max_output_tokens は使えないのですか？ 使えません。渡すと 400 になります。instructions に長さの要件（例：「只用一句话回答」）を明記するか、prompt で制約してください。

コストを下げるには？ まず reasoning.effort を下げましょう（推論 token は出力として課金されるため、低い段階は直接の節約になります）。システムプロンプトを再利用して入力のキャッシュヒットを狙うとより安くなります。超長いコンテキストを一度に詰め込んで高い価格帯に入ることを避けましょう。リアルタイムの単価は料金ページをご覧ください。