使用ガイド
gpt-6.1-sol プロンプトレシピ：コーディング、推論、JSON、ツール呼び出し（実際の出力付き）
gpt-6.1-sol は hiapi 上の推論グレードのテキストモデルです——会話、コーディング、段階的な推論を Responses API（POST /v1/responses）経由で提供します。呼び出し方法をすでに知っているなら、このページが次のステップです。すぐにコピー＆ペーストできるプロンプトレシピ集で、実際に最もよく使われる4種類のタスク——コーディング、推論、厳密な JSON、ツール呼び出し——をカバーしています。各レシピには、この記事のために実際に実行したときに得られた正確な出力を添えています。認証、ストリーミング、SSE の解析についてはセットアップガイドから始めてください。ここではプロンプトそのものにのみ焦点を当てます。
以下の各レシピは1つのリクエストボディであり、そのセットアップにそのまま入れることができます。プロンプトは2つのフィールドで構成されます。最上位の instructions（ロール設定とフォーマット規則）と、input 配列（タスクそのもの）です。ここに理論的な内容は一切ありません——出力はすべて実際の response.completed イベントからそのまま貼り付けたものです。
gpt-6.1-sol へのプロンプトの書き方を左右する3つのレバー
レシピに入る前に、このモデルに関する3つの事実が、あなたが書くすべてのプロンプトを形作ります。これら3点はいずれも hiapi 上のモデルのライブ契約に照らして確認済みです。
temperatureもtop_pもありません。 この実行構成では両方（およびmax_output_tokens）が無効化されています。サンプリングで決定性や創造性を調整することはできません——唯一調整できるノブはinstructions、input、そしてreasoning.effortです。簡潔で決定性を感じさせる出力が欲しいなら、instructionsにそう書いてください。temperature: 0は設定できません。reasoning.effortには5つのレベルがあります：low、medium、high、xhigh、max（デフォルトはmedium）。effort を高くすると、より多くの隠れた推論トークンを消費し——これらは出力トークンとして課金されます。レシピ2では実際の曲線を示しています。- コンテキストウィンドウは約1.05Mトークン（最大出力128K）。トークン課金は段階制です。1リクエストの入力が272Kトークンを超えると、入力/出力の料率がほぼ倍になります。日常的なプロンプトではこの線には遠く及びませんが、長コンテキストのタスク（レシピ5）では知っておく価値があります。
レシピ1——コーディング：仕様から関数を生成する
エンジニアのロールと出力の形を instructions に入れ、仕様を input に入れます。形を制約すること（「1つのコードフェンスブロック、その後に一文」）こそが、推論モデルがコードを三段の前置きで包むのを防ぐ方法です。
{
"model": "gpt-6.1-sol",
"instructions": "あなたはシニア Python エンジニアです。単一の Python フェンスコードブロックを返し、その後に計算量を一文で説明してください。前置きは不要です。",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "`merge_intervals(intervals: list[list[int]]) -> list[list[int]]` を書いてください。重複する閉区間をマージし、開始点でソートして返します。空リストを処理すること。docstring を含めること。" }
] }
],
"reasoning": { "effort": "low" },
"stream": true
}
返ってきた内容（そのまま）：
def merge_intervals(intervals: list[list[int]]) -> list[list[int]]:
"""重複する閉区間をマージし、開始点でソートして返す。
入力リストおよびその中の区間は変更されない。
"""
if not intervals:
return []
ordered = sorted(intervals, key=lambda interval: interval[0])
merged = [ordered[0].copy()]
for start, end in ordered[1:]:
if start <= merged[-1][1]:
merged[-1][1] = max(merged[-1][1], end)
else:
merged.append([start, end])
return merged
時間計算量は O(n log n)、空間計算量は O(n) です。
制約がもたらしたものに注目してください。空リストを正しく処理し、各区間を変更前にコピーし（ordered[0].copy()）、呼び出し元のデータを変更せず、分析はちょうど一文だけで止めています。この種の機械的なコーディングには effort: low で十分です——推論トークンをゼロしか使わず、なおかつ正しく非破壊的なコードを生成しました。
レシピ2——推論：effort で思考予算を制御する
temperature を設定できないため、reasoning.effort が難しい問題に対処するための主要なノブになります。プロンプトは変えずに、effort だけを変えてみましょう：
{
"model": "gpt-6.1-sol",
"instructions": "段階的に考え、最後に1行 `Answer: <value>` で締めくくってください。",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "あるパン屋がクッキーを6個入りと11個入りの箱で売っています。ちょうど買えないクッキーの最大個数はいくつですか？推論過程を示してください。" }
] }
],
"reasoning": { "effort": "medium" },
"stream": true
}
同じプロンプトを5つの effort レベルすべてで実行しました。どのレベルも正解の49を返しました。変わったのは、そこに至るまでにどれだけ考えたかです：
reasoning.effort |
推論トークン | 出力トークン合計 | 概算費用* |
|---|---|---|---|
low |
76 | 305 | ≈ $0.0008 |
medium |
121 | 380 | ≈ $0.0010 |
high |
209 | 427 | ≈ $0.0011 |
xhigh |
626 | 845 | ≈ $0.0021 |
max |
622 | 813 | ≈ $0.0021 |
*基本料率（入力 $0.50 / 1M、出力 $2.50 / 1M）で計算。推論トークンは出力として課金。データは今回の実行によるもので、2026-10時点。最新の料率は料金ページをご覧ください。
実用的な教訓は最後の2行にあります。effort は low から high へなだらかに上昇し、その後プラトーに入ります——xhigh と max はどちらも約620推論トークンに落ち着きます。これはこの問題がそもそもそれ以上考える必要がないほど難しくないからです。簡単なプロンプトで effort を最大にしても、より良い答えが得られるわけではありません。同じ「49」のために約2.5倍の出力トークンを費やすだけです。effort は難易度に合わせてください。ほとんどのプロンプトは low/medium で、タスクが本当に深い探索を必要とする場合にのみ high 以上を使ってください。
以下は medium の出力です。プロンプトがどんな形を生み出したか見てみましょう：
最大の数は49枚のクッキーです。
1. 49がちょうど買えないことの証明。 49 = 6a + 11b（a、b は非負整数）と仮定します。両辺を6で割った余りを取ると 5b ≡ 1 (mod 6) となり、したがって b ≡ 5 (mod 6) です。よって b は少なくとも5ですが、11個入り5箱にはすでに55枚のクッキーが含まれます。これは不可能です。
2. 49より大きいすべての数が買えることの証明。 ……50以上のすべての整数は、6つの連続する到達可能な総数のいずれかに6の非負倍数を加えたものです。
Answer: 49
instructions の Answer: <value> の行は確かに効いています。これにより、モデルに推論過程を捨てさせることなく、最終行を簡単にパースできます（text.rsplit("Answer:", 1)[-1].strip()）。
レシピ3——schema 付きの厳密な JSON
散文で JSON を要求して祈るのはやめましょう。gpt-6.1-sol は厳密な構造化出力をサポートしています。json_schema 付きの text.format を渡すと、モデルは要件を満たす JSON の出力に制約されます——コードフェンスも、余計な散文もありません。
{
"model": "gpt-6.1-sol",
"instructions": "サポートチケットを分類してください。その JSON オブジェクトのみを返信してください。",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "チケット：'今朝から、4K アップスケールエンドポイントが呼び出しのたびに500を返しています。明日リリース予定で、これで詰まっています。'" }
] }
],
"text": {
"format": {
"type": "json_schema",
"name": "ticket",
"strict": true,
"schema": {
"type": "object",
"properties": {
"sentiment": { "type": "string", "enum": ["positive", "neutral", "negative"] },
"topics": { "type": "array", "items": { "type": "string" } },
"action_required": { "type": "boolean" }
},
"required": ["sentiment", "topics", "action_required"],
"additionalProperties": false
}
}
},
"reasoning": { "effort": "low" },
"stream": true
}
返ってきた内容（そのまま、1行）：
{"action_required":true,"sentiment":"negative","topics":["4K upscale endpoint","HTTP 500 errors","Service outage","Launch blocker","Urgent support"]}
2点を心に留めておく必要があります。第一に、strict: true は型と必須キーを保証しますが、キーの順序は保証しません——schema では最後に列挙されているのに action_required が最初に現れていることに注意してください。したがって、キーでパースし、決して位置でパースしないでください。第二に、他のレスポンスと同様に、response.output_text.delta ブロックから答えを蓄積する必要があります。schema が形作るのは内容であり、転送方式ではありません。
レシピ4——ツール呼び出しと結果の継続
gpt-6.1-sol は関数を呼び出すことができ、そして——重要なことに——結果を返した後に続行します。tools 配列を宣言します。モデルが呼び出すと決めたとき、テキストではなく function_call アイテムを発行します。
{
"model": "gpt-6.1-sol",
"instructions": "あなたはツールを呼び出せます。ユーザーがあるタスクについて尋ねたら、get_task_status を呼び出してください。",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "task_abc123 の状況を確認してもらえますか？ずっと pending のままです。" }
] }
],
"tools": [
{
"type": "function",
"name": "get_task_status",
"description": "id で非同期の画像/動画生成タスクのステータスを照会します。",
"parameters": {
"type": "object",
"properties": { "task_id": { "type": "string", "description": "タスク id（例：'task_abc123'）。" } },
"required": ["task_id"],
"additionalProperties": false
}
}
],
"reasoning": { "effort": "low" },
"stream": true
}
レスポンスにはテキストは含まれません——最終イベントで function_call アイテムとして伝達されるツール呼び出しのみです（その引数は response.function_call_arguments.delta ブロックでストリーミングされます）：
{
"type": "function_call",
"call_id": "call_e4a8a52c6db04cafb6a744f3727c456b",
"name": "get_task_status",
"arguments": "{\"task_id\":\"task_abc123\"}"
}
ここからがセットアップガイドでカバーされていない後半です。関数を実行し、結果を返却する——モデルの function_call とあなたの function_call_output（同じ call_id で関連付け）を input 配列に追加し、再度呼び出します：
{
"model": "gpt-6.1-sol",
"instructions": "あなたはツールを呼び出せます。ツールの結果をユーザーに1〜2文で要約してください。",
"input": [
{ "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "task_abc123 の状況を確認してもらえますか？ずっと pending のままです。" } ] },
{ "type": "function_call", "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b", "name": "get_task_status", "arguments": "{\"task_id\":\"task_abc123\"}" },
{ "type": "function_call_output", "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b", "output": "{\"status\":\"failed\",\"error\":\"INVALID_REQUEST: image url could not be downloaded\",\"created_at\":\"2026-10-17T06:12:00Z\"}" }
],
"tools": [ { "type": "function", "name": "get_task_status", "description": "id で非同期生成タスクのステータスを照会します。", "parameters": { "type": "object", "properties": { "task_id": { "type": "string" } }, "required": ["task_id"], "additionalProperties": false } } ],
"reasoning": { "effort": "low" },
"stream": true
}
結果を受け取ると、平易な言葉で回答します（そのまま）：
タスク
task_abc123はもう pending ではありません——画像 URL をダウンロードできなかったため、失敗しました（INVALID_REQUEST）。画像 URL が公開アクセス可能か確認してから、タスクを再送信してください。
call_id が接着剤です。あなたの function_call_output は、モデルの function_call にある正確な call_id をエコーバックする必要があります。そうでなければ、後続のターンはそれに紐付きません。
レシピ5——長コンテキスト上の根拠ある回答
1.05Mトークンのウィンドウは、実際の資料——ログ、変更履歴、仕様書——を投入し、それに基づいて質問に答えるためのものです。それを誠実に保つプロンプトパターンは instructions にあります。提供されたテキストのみに基づいて答えること、そして各事実の出典を引用することを強制します。
{
"model": "gpt-6.1-sol",
"instructions": "提供された CHANGELOG に厳密に基づいて回答してください。ある事実が存在しない場合は、'not in the changelog' と言ってください。使用した各事実の日付を引用してください。",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "<ここに CHANGELOG を貼り付け>\n質問：ある動画タスクの出力 URL は昨日は私のファイルを返しましたが、今日は404になりました。さらに、私の画像呼び出しがちょうど402を返し始めました。どの2つの変更履歴エントリがこれを説明しており、私は何を変更すべきですか？" }
] }
],
"reasoning": { "effort": "medium" },
"stream": true
}
短いプラットフォームの変更履歴を与えると、関連する2つのエントリを正確に抽出し、その日付を引用し、「何が起きたか」と「何を変更すべきか」を分けて示します（そのまま）：
2つのエントリがこれらの問題を説明しています：
1. 2026-10-02——一時的な出力 URL は有効期限が切れます。
temp.hiapi.ai上の出力 URL は7日間有効で、その後404を返します……変更点：すぐにバイトをダウンロードして自身のコピーを保存してください。ホットリンクしないでください。expireAtを使って有効期限を追跡してください。2. 2026-09-20——残高が空だと画像モデルで402が発生します。 残高が完全に空のアカウントは、現在すべての画像モデルで HTTP 402 を受信します……変更点：アカウントの残高が完全に空かどうかを確認し、そうであればチャージしてください。
「日付を引用する」という指示は安上がりな根拠付けのテクニックです。これにより幻覚が可視化され（指し示す日付がない事実は、それがでっち上げた事実です）、答えが監査可能になります。段階料金を忘れないでください——入力が272Kトークンを超えるプロンプトは、より高い長コンテキスト料率で課金されます。
今回の実行で遭遇した落とし穴：ストリームを UTF-8 にデコードする
推論モデルは長いダッシュや曲がった引用符を好みます。この記事の執筆中、最初の SSE リーダーがマルチバイト UTF-8 文字を2つのネットワークチャンクに分割し、きれいな長いダッシュ（「—」）を文字化け（「â」）に変えてしまいました。モデルの出力は問題ありませんでした。クライアントが行単位で早すぎるデコードをしていたのです。修正方法は、生のバイトをバッファリングし、改行で分割し、各完全な行を UTF-8 にデコードすることです——不完全なチャンクをデコードしないでください。gpt-6.1-sol の出力に散発的に Ã/â 文字が現れる場合、原因はここにあり、モデルではありません。
よくある質問
これは gpt-6.1-sol セットアップガイドとどう違うのですか？
セットアップガイドはモデルを呼び出す方法を扱っています——認証、なぜストリーミングが必須なのか、SSE の解析。このページはモデルにプロンプトを与える方法を扱っています——具体的なタスクのための instructions/input/effort パターンと、それらが生み出す出力です。
reasoning.effort を max に引き上げれば最良の答えが得られますか？
無料ではありませんし、しばしばより良い結果にもなりません。私たちのテスト問題では、xhigh と max はどちらも約620推論トークンでプラトーに入り、high と同じ答えを返しました。推論トークンは出力として課金されるため、簡単なプロンプトで最大にすると、同じ結果のためにより多くのお金を費やすことになります。high 以上は本当に難しい推論のために取っておいてください。
プロンプトで要求するのではなく、有効な JSON を強制するにはどうすればよいですか？
strict な json_schema 付きの text.format を渡してください（レシピ3）。モデルは schema に準拠した型と必須キーに制約されます。キー名でパースしてください。strict はキーの順序を固定しないためです。
なぜ temperature や top_p を設定できないのですか？
この実行構成では両方（および max_output_tokens）が無効化されています。代わりに instructions、input、reasoning.effort を通じて出力を形作ってください。
ツール呼び出しはチャットモデルと同じように動作しますか？
契約は少し異なります。ツールは最上位の tools 配列で宣言され、モデルは function_call アイテム（メッセージではない）で応答し、一致する call_id を持つ function_call_output を追加することで続行します（レシピ4）。
gpt-6.1-sol は gpt-5.6-sol と同じですか？ 同じ Sol ファミリーに属し、この Responses-API のストリーミング専用契約を共有していますが、gpt-6.1-sol はより新しい世代です。gpt-6 Astra と gpt-5.6 Sol の比較で各世代の対応関係をご覧ください。
ここから始める
上記のどのレシピでも、セットアップガイドのリクエストボディにコピーし、自分のタスクに置き換え、難易度に応じて reasoning.effort を調整してください。機能紹介とオンライン試用ボックスは gpt-6.1-sol モデルページに、エンドポイントと共通リクエスト形式は API ドキュメントに、トークンあたりの料率は料金ページにあります。hiapi のキー1つで gpt-6.1-sol とプラットフォーム上の他のすべてのモデルにアクセスできます。
