大模型 API 接口パラメータ完全解説：リクエストフィールドからレスポンスフィールドまで

リクエストの形式

エンドポイントは POST https://api.apidamoxing.com/v1/chat/completions、認証ヘッダーは Authorization: Bearer <key> です。リクエストボディは JSON 形式で、OpenAI のチャット補完と互換性があります。よく使われるフィールドをすべて使用した完全なリクエストを以下に示します。

复制curl https://api.apidamoxing.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [
      {"role": "system", "content": "你是一位耐心的天文科普作者。"},
      {"role": "user", "content": "为什么月亮总是同一面朝向地球？"}
    ],
    "temperature": 0.7,
    "top_p": 0.9,
    "max_tokens": 400,
    "stop": ["###"]
  }'

ここでは model に uncensored を指定する必要があります。サービスは単一モデルのみを提供しており、選択肢はありません。GET /v1/models で確認できます。以下、フィールドごとに解説します。

記事全体を読むと、これらのパラメータは 3 つのカテゴリに分類できることがわかります。「何を話すか」（messages、tools）、「どのように話すか」（temperature、top_p）、「どれだけ話すか、いつ止めるか」（max_tokens、stop、stream）です。この分類を覚えておけば、未知のフィールドに出会った際、まずカテゴリを判断することで用途の大部分を推測できます。

messages：会話の「記録帳」

messages は配列で、各要素には role と content が含まれます。これは逐次記録される議事録のページと想像してください。モデルは毎回最初から読み始め、次のページを書き出します。モデルは前回何を読んだか記憶しないため、複数回の会話では履歴をあなたが完全に付与する必要があります。

よくあるテクニックとして、モデルに特定の口調で続きを書かせる場合、アシスタントメッセージを履歴に構成して追加します。プロンプトと出力の合計は 100,000 トークンを超えてはならず、履歴が長ければ長いほど領域を消費します。

具体的な例を挙げます。カスタマーサポートアシスタントを作成したとします。system に「注文に関する質問のみ回答し、回答は 3 文以内に収める」と設定します。ユーザーが第 1 ターンで配送時間を質問し、第 2 ターンで「では返品は？」と追問します。第 2 ターンのリクエストでは、messages に system、第 1 ターンの user、第 1 ターンのモデルの assistant 回答、第 2 ターンの user を順に含める必要があります。どれが欠けても、モデルは「では」が何を指しているのかわかりません。

サンプリングパラメータ：「自由度」を調整

モデルが文字を生成する際、まず候補となるすべての文字に確率スコアを付け、その後で抽選を行います。以下の 2 つのパラメータは、この抽選ルールを調整するノブです。

両方とも「どの程度ランダムにするか」を制御しますが、アプローチが異なります。両方を同時に調整すると効果がどちらに起因するか判断しにくいため、一度に一つだけ変更することをお勧めします。これらの標準的なサンプリングパラメータはそのまま渡され、API 側で独自に書き換えられることはありません。

具体的な数字の例で説明します。モデルが次に出力する最も可能性の高い 3 文字の確率がそれぞれ 60%、30%、10% だと仮定します。temperature を下げると、60% の選択肢がより優勢になり、毎回同じ結果が出力されやすくなります。temperature を上げると確率の差が縮まり、レアな文字が選択されやすくなります。top_p を 0.9 に設定すると、累積で 90% に達する上位 2 文字のみが残り、3 番目の文字は除外されます。これらの数字は原理を説明するための仮定であり、実際の確率ではありません。

長さの制御と停止条件：max_tokens、stop、stream

max_tokens は一度に出せる料理の皿の大きさに似ています。皿が小さいと料理が完備する前に端に持っていかれ、この場合 finish_reason は length になります。stop は合図のようなもので、シェフがその合図を聞くと手を止めます。stream は内容を変えず、提供方法だけを変えます。「すべて完成してから出す」のではなく、「一口完成するごとに一口出す」ようにし、ユーザーはレスポンスがより速く感じられます。

stop の実用的な使い方の一つ：モデルに「質問：……答え：……###」という固定形式で出力させ、### を stop に設定すると、区切り文字に到達した時点で自動的に停止します。これによりトークンを節約でき、その後に無駄な発言をするのを防げます。stop が発動した場合、finish_reason も stop になる点に注意してください。区別する必要がある場合は、コンテンツを自分で確認する必要があります。

tools と tool_choice：モデルに「電話」で問い合わせる

モデル自体はリアルタイムデータにアクセスできません。function calling の手法は、まずモデルに利用可能な関数を伝え、モデルが必要と判断した際に直接回答するのではなく、「〇〇関数を呼び出し、パラメータは……」と返し、あなたのプログラムが実行後に結果を渡すと、モデルがそれに基づいて回答を構成します。形式は OpenAI と一致します。

复制import json
import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])

tools = [{
    "type": "function",
    "function": {
        "name": "get_tide_time",
        "description": "查询某港口今天的高潮时刻",
        "parameters": {
            "type": "object",
            "properties": {"port": {"type": "string", "description": "港口名称"}},
            "required": ["port"],
        },
    },
}]

messages = [{"role": "user", "content": "青岛今天几点涨潮？"}]
first = client.chat.completions.create(
    model="uncensored", messages=messages, tools=tools, tool_choice="auto"
)
msg = first.choices[0].message

if msg.tool_calls:
    call = msg.tool_calls[0]
    args = json.loads(call.function.arguments)
    result = {"port": args["port"], "high_tide": "14:20"}   # 这里换成你自己的查询
    messages.append(msg)
    messages.append({"role": "tool", "tool_call_id": call.id, "content": json.dumps(result, ensure_ascii=False)})
    final = client.chat.completions.create(model="uncensored", messages=messages, tools=tools)
    print(final.choices[0].message.content)
else:
    print(msg.content)

プロセスは2段階です：第1ラウンドで tool_calls を取得し、第2ラウンドで role が tool の結果を追加して再度リクエストします。description が具体的であればあるほど、モデルはいつ呼び出すべきか正確に理解します。パラメータは JSON 文字列なので、必ず json.loads で解析し検証し、安易に信頼しないでください。

応答フィールド：返された「レシート」を読む

成功した応答は概ね以下のようになります。フィールドは固定です：

复制{
  "id": "chatcmpl-xxxx",
  "object": "chat.completion",
  "model": "uncensored",
  "choices": [
    {
      "index": 0,
      "message": {"role": "assistant", "content": "因为潮汐锁定……"},
      "finish_reason": "stop"
    }
  ],
  "usage": {"prompt_tokens": 38, "completion_tokens": 212, "total_tokens": 250}
}

コードではまず finish_reason を確認します：length ならユーザーに内容が切り捨てられたことを伝え、または自動で続きを書かせます；tool_calls なら関数実行の分岐に進みます。usage の役割については、トークンと請求の記事でより詳細な予算方法が説明されています。

よくあるパラメータの誤解

• max_tokens を「入力上限」と誤解する。これは出力のみを制御し、入力はユーザー側で制御します。
• モデルが前回のリクエストを覚えていると誤解する。各リクエストは独立しており、履歴は自分で管理します。
• temperature を 0 に設定すると毎回全く同じ結果が得られると誤解する。より安定しますが、文字通り完全に一致すると仮定すべきではありません。
• ストリーミングモードで直接 choices[0].message を読み取る。ストリーミングのチャンクには delta フィールドが含まれるため、自分で連結する必要があります。
• tool 呼び出し後、tool_calls を含む assistant メッセージを追加し忘れるため、第 2 段階でエラーが発生する。

エラーコードの意味とリトライ戦略はドキュメントで確認できます。これらのパラメータを繋げた完全な例を見るには、チャットボットの構築の記事を参照してください。