KimiのAPIを自分のプログラムに組み込む前に：入口と鍵、OpenAI互換の呼び方、ツール呼び出し、画面なし実行、料金の見方を公式文書で確かめる

この記事は、実際に使って確かめた記録ではありません。運営者はKimiを入れていますが、使い心地はこの記事には書いていません。この記事は、2026年10月24日に公式ドキュメントを読んでまとめたものです。コードは公式ページの例を読んで写し、短くしたもので、実行していません。公式ページは要約として取得したため、読み切れていない箇所は「読めていない」と書きました。価格、上限、モデル名は変わることがあります。契約や法律の助言ではありません。

先に結論

• まず3つ決めます。 ①どの形式で呼ぶか（Chat Completions、Responses、Messages）、②鍵をどこに置き、どの範囲（プロジェクト、IPの許可リスト、1日の予算）で縛るか、③ツールを使うなら、ループの上限をいくつにするか。
• 鍵は秘密のまま、環境変数で。 公式のクイックスタートは、鍵をアプリに直接書かないよう明記しています。
• 画面のない実行ほど、上限を先に置きます。 公式の例にも、ループの最大回数（8回）、出力のトークン上限、HTTPのタイムアウトが入っています。プロジェクトの1日の予算は、反映に約10分かかることがあります。
• 料金の数字は、公式の画面で確かめます。 この記事の表は、読めた範囲だけです。

前提：用語をそろえる

• Kimi API Platform（Open Platform）：開発者がAPIで使うための別のサービス。アプリの会員（01）や、Kimi Codeの会員（04）とは、残高も鍵もつながっていません。
• OpenAI互換：OpenAIのSDKの接続先と鍵を差し替えるだけで使える作り。公式のAPI概要は、移行はベースURLとAPIキーの置き換えだけでよい、と書いています。
• Chat Completions / Responses / Messages：APIの3つの形式。前の2つはOpenAI互換、Messagesはメッセージの形がAnthropic互換です。
• ツール呼び出し（tool calls）：モデルが「この関数をこの引数で呼んでほしい」と返し、自分のプログラムが実行して結果を戻す仕組み。実行するのは自分のコードです。
• reasoning_effort：K3系の思考の強さ。low、high、maxの3段階です。
• コンテキストキャッシュ：同じ前置き（システムプロンプトなど）を再利用すると、安い単価で請求される仕組み。K3系では自動です。
• RPM / TPM / TPD / 同時接続数：分あたりのリクエスト数、分あたりのトークン数、日あたりのトークン数、同時に処理できる数。
• ヘッドレス（画面なし）：人が画面を見ない状態で、スクリプトやサーバーの中で動かすこと。この記事では、APIを呼ぶスクリプトとBatch APIを指します。

入口と鍵：platform.kimi.ai で最初にやること

公式の「Quickstart」（get-your-api-key）の手順を、画面の項目名のまま写します。

1. Kimi API Platform にサインインします。サインインの方法は、このクイックスタートのページには書かれていませんでした。変更履歴には、2026年7月に、グローバル版で「メールの確認コードでの登録とログイン」と「メール、Googleアカウントの紐づけ」を加えた、とあります。
2. 「API Keys」（platform.kimi.ai/console/api-keys）で鍵を作り、コピーします。
3. 環境変数 MOONSHOT_API_KEY に入れます。
4. モデルを選びます。クイックスタート（get-your-api-key）の推奨は kimi-k3.1-pro、同じ能力でより速い版が kimi-k3.1-pro-highspeed です。
5. 形式を選びます（Chat Completions、Responses、Messages）。
6. 前提は、Python 3.9以上またはNode.js 18以上、OpenAIのSDK 1.0.0以上です（別のQuickstartのページ overview は Python 3.8以上と書いていて、ページ間で食い違っています）。

画面のない試し場として、Playground（platform.kimi.ai/playground）が公式に挙がっています。コードを書かずにプロンプトを試せます。

Check Balance のページには、platform.kimi.ai と platform.kimi.com の鍵は独立で、別のプラットフォームのエンドポイントに使うと401になる、と書かれています。前の記事（02）の「platform.moonshot.ai から転送される」という話と合わせて、鍵を作ったサイトと、呼ぶ先のURLを揃えるのが基本です。

最初の呼び出し：curl と Python

公式のクイックスタートの例です。公式の例の挨拶文には人名が入っていましたが、ここでは普通の文に替えています。動かしてはいません。

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3.1-pro",
       "messages": [{"role": "user", "content": "Hi. What is 1+1?"}]}'

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

completion = client.chat.completions.create(
    model="kimi-k3.1-pro",
    messages=[{"role": "user", "content": "Introduce Kimi K3.1 Pro in one sentence."}],
)
print(completion.choices[0].message.content)

SDKのインストールは pip install --upgrade 'openai>=1.0'（Pythonの場合）、npm install openai@latest（Node.jsの場合）です。Node.jsの例も公式に載っていて、baseURL: "https://api.moonshot.ai/v1" を渡す形です。

ひっかかりやすい点。 Troubleshooting には、model_not_found の原因として「OpenAIのSDKで base_url を設定せず、リクエストがOpenAI側に行った」ことが挙がっています。環境変数の OPENAI_BASE_URL を使う場合も含め、呼び先を一度ログに出して確かめます（これは僕らの見立てです）。

思考の強さと、ストリーミング

K3系は、思考が常にオンです。公式のK3.1 Proのページは「K3.1 Pro always has thinking mode enabled.」と書き、切る方法はなく、遅さを抑えたいときは reasoning_effort を low にする、としています。

completion = client.chat.completions.create(
    model="kimi-k3.1-pro",
    reasoning_effort="max",   # low / high / max（既定は max）
    messages=[{"role": "user", "content": "Prove that the square root of 2 is irrational."}],
)

ストリーミングは stream=True で、思考の差分（reasoning_content）と、答えの差分（content）が別のフィールドで届きます。

stream = client.chat.completions.create(
    model="kimi-k3.1-pro",
    messages=[{"role": "user", "content": "Explain why the sky is blue."}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta
    reasoning = getattr(delta, "reasoning_content", None)
    if reasoning:
        print(reasoning, end="", flush=True)
    if delta.content:
        print(delta.content, end="", flush=True)

Chat Completions のリファレンスによると、ストリームの最後に使用量（usage）のチャンクを受け取るには stream_options.include_usage を true にします。通信が途中で切れると、最後の使用量のチャンクが届かないことがある、とも書かれています。請求の突き合わせをするなら、この点を覚えておきます。

画面なしで動かすときのログの取り方の一例を、この記事の整理として示します（公式の例ではなく、この記事では動作を確かめていません）。stream_options の書き方はリファレンスの項目名に合わせ、最後のチャンクに choices がない場合に備えて確かめています。request_id をSDKのどこから取るかは、読めていません。

stream = client.chat.completions.create(
    model="kimi-k3.1-pro",
    messages=messages,
    stream=True,
    stream_options={"include_usage": True},
)
usage, finish_reason = None, None
for chunk in stream:
    if chunk.choices:
        finish_reason = chunk.choices[0].finish_reason or finish_reason
        # delta の処理は上の例と同じ
    if getattr(chunk, "usage", None):
        usage = chunk.usage
# 通信が途中で切れると usage が届かないことがある（None のままになる）
print({"model": "kimi-k3.1-pro", "finish_reason": finish_reason, "usage": usage})

K3系のAPI上の約束事（公式の表より）

Chat Completions のリファレンスと、K3.1 Pro のクイックスタートから、守るべき点を表にまとめます。

OpenAI互換の入口では、thinking のような独自の項目は SDK の extra_body に入れ、partial は assistant のメッセージのフィールドとして入れる、とAPI概要に書かれています。

出力が途中で切れる問題について、Troubleshooting は、finish_reason が length なら max_completion_tokens に当たったということ、max_completion_tokens は上限であって「この長さで書く」という指示ではない、と説明しています。使用量の欄では、completion_tokens は思考と答えの合計と書かれています。僕らの見立てですが、思考が常にオンのモデルで出力の上限を小さくしすぎると、答えが出る前に打ち切られる場合があります。公式の例（後述のエージェント）は、上限を8192に置き、length で止まったら失敗にしています。

3つの形式を比べる

API Overview と各リファレンスから、違いを並べます。

Messages のページには、読めた範囲ではSDKのコード例が見つからず、Anthropic SDKを使うときはベースURLを https://api.moonshot.ai/anthropic に向ければよい、という説明がありました。公式のJSONの断片は次のとおりです。

{
    "model": "kimi-k3.1-pro",
    "cache_control": { "type": "ephemeral", "ttl": "1h" },
    "messages": [{"role": "user", "content": "Hello"}]
}

Anthropic SDKで認証をどう渡すか（鍵をどのヘッダーに入れるか）は、読んだページでは確かめられていません。Claude Code向けの案内（前の記事02）では、ANTHROPIC_AUTH_TOKEN にKimiの鍵を入れる形でした。Messages を使うなら、最初にこの1点（ヘッダー）を公式で確かめるのが、次の確認課題です。

Responses の最小の呼び出しは、公式のページに次の形で載っています（必須の項目は model と input で、input は文字列でもよく、1つのユーザーメッセージとして扱われます。動かしてはいません）。

curl https://api.moonshot.ai/v1/responses \
    --header "Content-Type: application/json" \
    --header "Authorization: Bearer $MOONSHOT_API_KEY" \
    --data '{
        "model": "kimi-k3.1-pro",
        "input": "Explain context caching in one sentence."
    }'

Pythonでは、Chat Completions と同じ OpenAI(api_key=..., base_url="https://api.moonshot.ai/v1") のクライアントで client.responses.create(model="kimi-k3.1-pro", input="...") を呼び、response.output_text を読む形です。

ツール呼び出し：ループの書き方

公式の「Use Kimi API for Tool Calls」の流れは、6段階です。ツールをJSONスキーマで定義し、tools に渡し、モデルが呼ぶかどうかを決め、引数をJSONで返し、自分のプログラムが実行して結果を戻し、モデルが最終の返答を書きます。

ツールの定義は、次の固定の形です。

{
  "type": "function",
  "function": {
    "name": "NAME",
    "description": "DESCRIPTION",
    "parameters": {
      "type": "object",
      "properties": {}
    }
  }
}

Chat Completions のリファレンスでは、name は ^[a-zA-Z_][a-zA-Z0-9-_]{0,127}$ に合う必要があり、parameters は必須で、「MFJS」という形式に従う、と書かれています。MFJS の中身は、読んだ範囲では説明が見つかりませんでした。strict の既定は true です。

ループは、公式の例を短くすると次のとおりです（モデル名は例の kimi-k3.1-pro。実行はしていません）。

import json, os
from openai import OpenAI

client = OpenAI(api_key=os.environ["MOONSHOT_API_KEY"],
                base_url="https://api.moonshot.ai/v1")

tools = [{"type": "function", "function": {
    "name": "search",
    "description": "Search the internet. Use when your knowledge cannot answer.",
    "parameters": {"type": "object", "required": ["query"],
        "properties": {"query": {"type": "string", "description": "What to search for."}}}}}]

def search(args):                      # 実際の実装に置き換える
    return {"result": f"search results for {args['query']}"}
tool_map = {"search": search}

messages = [{"role": "user", "content": "Search online for Context Caching and tell me what it is."}]
finish_reason = None
while finish_reason is None or finish_reason == "tool_calls":
    completion = client.chat.completions.create(
        model="kimi-k3.1-pro", messages=messages, tools=tools)
    choice = completion.choices[0]
    finish_reason = choice.finish_reason
    if finish_reason == "tool_calls":
        messages.append(choice.message)            # 返ってきたまま足す
        for tc in choice.message.tool_calls:
            args = json.loads(tc.function.arguments)
            result = tool_map[tc.function.name](args)
            messages.append({"role": "tool", "tool_call_id": tc.id,
                             "name": tc.function.name, "content": json.dumps(result)})
print(choice.message.content)

公式のこの例にはループの最大回数がありません。画面なしで動かすなら、後の節のように上限を足します（これは僕らの見立てで、公式の別のガイドの例には上限があります）。

公式が書いている、守る点。

• finish_reason が tool_calls のときは、その応答を利用者に答えとして見せません。stop なら最終の返答です。
• 1つの tool_call に、role: "tool" のメッセージがちょうど1つ必要です。数が合わない、tool_call_id が合わない、とエラーになります。
• 「tool_call_id not found」は、assistant のメッセージを messages に足し忘れたときに起きやすい、と書かれています。choice.message を、変えずにそのまま足します。
• ツールの定義もトークンに数えられます。tools と messages を合わせて、コンテキストに収めます。
• 1回の応答で複数の呼び出しが返ることがあります（別のツール、または同じツールで引数違い）。全部に結果を返します。
• 古い function_call と functions は非推奨で、もうサポートされません。tool_calls を使います。
• ストリーミングでは、最初のチャンクにだけ id と関数名があり、あとは引数の断片です。index で呼び出しを区別して、引数を順につなぎます。

tool_choice。 値は auto（既定）、none、required、特定の関数の指定です。公式のTool Choiceのページには、特定の関数を強制するのは思考とは両立せず、思考が有効だと400になる、とあります。Model Parameter Reference では、kimi-k3 が auto、none、required に対応し、kimi-k2.7-code と kimi-k2.6 は required に非対応です。tool_choice を変えても、プレフィックスのキャッシュは無効になりません。

公式ツール（Formula）とWeb検索：読めた範囲と、期限のある話

公式ツール（Formula）。 公式の「How to Use Official Tools」によると、convert、web-search、rethink、random-choice、mew、memory、excel、date、base64、fetch が挙がっています。URIは moonshot/<name>:latest の形で、名前空間は今は moonshot だけです。手順は、GET /v1/formulas/{uri}/tools で定義を取り、Chat Completions の tools に渡し、返ってきた呼び出しの name と arguments をそのまま POST /v1/formulas/{uri}/fibers に送って実行し、結果を role: "tool" で戻す、です。課金が発生するのは、この fibers の実行の段階です。1回の中で function.name が重複すると400になります。

料金は、「web-search を除き、公式ツールは期間限定で無料」と書かれています（日付の表示なし）。

Web検索。 K3系のクイックスタートは、Web検索は更新中で、近いうちの本番利用は勧めない、と書いています。K3.1 Pro で検索をしたいときは、Formula の公式ツールの経路を使う、とも書かれています。別に、REST形式の検索API（/v1/tools/search、/v1/tools/search_pro、/v1/tools/fetch）が、2026年9月の変更履歴で「開始」と書かれています。

古い組み込みの $web_search（builtin_function）について、Web検索の料金ページは、2026年10月20日に廃止される見込み、と書き、新しい連携にはRESTのエンドポイントか web-search の公式ツールを勧めています。今日（10月24日）時点で止まったかどうかは、確認できていません。古い例を写しているコードがあれば、動くかどうかを先に確かめます。

画面なしで動かす

スクリプトとして

公式の「Build an Agent with Kimi K3」は、調査エージェントを、画面のない1本のPythonスクリプトとして示しています。保存して python3 agent.py で動かし、結果は標準出力に出ます。Python 3.9以上、openai と httpx が必要です。ここから、画面なしで動かすときの上限の置き方が読めます。

公式は、content と tool_calls だけを写すと reasoning_content が落ち、後のツール呼び出しが壊れる、と書いています。ループは再帰ではなく繰り返しで書く、ツールの説明が重なると上限に当たりやすい、引数の制約は説明文ではなくスキーマに書く、という注意もあります。

長い待ちと、切れる通信

Common Error Codes には、504は「900秒以内にサーバーの応答がない」ときで、ゲートウェイがHTMLのタイムアウトページを返す、とあります。長い非ストリームのリクエストでは、stream: true を使うよう勧めています。499は、サーバーが答える前にクライアントが切ったときで、KeepAliveやタイムアウトの設定、途中のプロキシがストリームを切っていないかを見る、とあります。

なお、Main Concepts のページは、1リクエストのタイムアウトを「一般に2時間」と書いていて、900秒という数字と食い違います（前の記事02は2時間と書いていました）。どちらが現行かは、読んだ範囲では分かりません。短いほうに合わせて、ストリーミングを使うのが安全です（これは僕らの見立てです）。

Batch API

大量の仕事で、急がないものには、Batch APIがあります。公式のガイドによると、リアルタイムの呼び出しより40%安く、/v1/chat/completions だけに対応し、対応モデルは kimi-k2.7-code と kimi-k2.6 で、kimi-k3 は非対応です。1つのバッチの中は、同じモデルにします。流れは次のとおりです。

1. 1行1リクエストの .jsonl を作る（100MB以下、空でない、各行に custom_id、method、url、body。custom_id はファイル内で重複させない）。body に temperature、top_p、n、presence_penalty、frequency_penalty は入れません。
2. Files APIに purpose="batch" で上げる。
3. completion_window（例は "24h"。大きいデータでは 3d や 7d）を付けてバッチを作る。
4. 10〜60秒おきに状態を確認する。
5. output_file_id から結果を取る。失敗した分は error_file_id に出ます。

f = client.files.create(file=open("batch.jsonl", "rb"), purpose="batch")
b = client.batches.create(input_file_id=f.id, endpoint="/v1/chat/completions", completion_window="24h")
# client.batches.retrieve(b.id) で completed になるまで確認
out = client.files.content(b.output_file_id)

状態は validating、failed、in_progress、finalizing、completed、expired、cancelling、cancelled で、取り消せるのは validating、in_progress、finalizing の間だけです。バッチ向けの料金ページ（pricing/batch）は、今回は読んでいません。記事（03）に書いたとおり、公式のZDRの説明（What is Zero Data Retention (ZDR)?）は、バッチAPIにはZDRが対応しない、と書いています。

Kimi Code CLI の -p

人のいない場所でコーディング用のCLIを動かす kimi -p と、承認モードの注意は、記事（04）に書きました。そこにある、公式の2つのページで -p と --yolo の併用の説明が食い違う点は、今回は読み直していません。

料金の見方

読めたのは、ここまでです（2026年10月24日）。

モデル別の料金ページ（pricing/chat）の表は、K3系もK2系も、読めた範囲では見出しの行だけでした。数字は、ブラウザで表示した公式の画面で確かめます。

請求の細かい点。

• 入力のうち、キャッシュヒット、キャッシュ書き込み、ミスの合計が prompt_tokens になります。cached_tokens などを足し直さない、とリファレンスに明記されています。
• キャッシュは自動で、既定は5分です。リクエストの間隔が5分を超えるなら、prompt_cache_options.ttl を 1h にします。公式の例では、100万トークンの前置きで、1時間は5分より書き込みが3.00ドル高い一方、ヒットのたびに2.70ドル安くなり、2回のヒットで差し引き2.40ドルの得、です。TTLは最初の書き込みで決まります。
• キャッシュを効かせるには、固定の内容（システムプロンプト、ツール定義、長い資料）を先頭に、毎回変わる内容を後ろに置き、時刻やランダムなIDを前置きに入れません。
• 429で中断されたリクエストは課金されない、とTroubleshootingにあります。
• 2026年9月の変更履歴に、使用額を現金50%と、クーポン（voucher）50%から引くよう変えた（契約の顧客は対象外）、とあります。
• 実際の請求の突き合わせは、コンソールの使用量、請求の明細、クライアントのログを、時間、プロジェクト、モデル、request_id で照らす、と公式が案内しています。
• 事前の見積もりに、POST /v1/tokenizers/estimate-token-count（入力のトークン数）があります。このエンドポイント自体が課金されるかは、そのページに書かれていませんでした。

残高は、次のコマンドで確かめられます。available_balance が0以下だと、推論の呼び出しが止まり、exceeded_current_quota_error になります。cash_balance はマイナスになることがあり、その間は available_balance が voucher_balance と同じになります。

curl https://api.moonshot.ai/v1/users/me/balance \
  -H "Authorization: Bearer $MOONSHOT_API_KEY"

制限とエラー：429の中身を見分ける

制限は、同時接続数、RPM、TPM、TPDの4つで、どれか1つが先に満ちたところで当たります。ユーザー単位で、鍵ごとではなく、全モデルで共有されます。Main Concepts のページによると、ゲートウェイの確認では、1つのリクエストを「入力トークン＋max_completion_tokens（省略すれば既定値）」で数え、実際に出力したトークン数は確認に使われない、と書かれています。課金は、入力と、実際に生成した分です。

段階の数字（累計の入金額ごとの同時接続数、RPM、TPM、TPD）の表は、読めた範囲では空でした。そのほかの記載は、最初の入金が最低1ドル、累計が5ドルに達すると5ドルのクーポンが付く（クーポンは累計に数えない）、Web検索のQPSは別枠、クラスターが混むと一時的に調整される、異常が検知されるとリスク管理の制限がかかり、いったんかかると解除できない、でした。

Common Error Codes の429を、見分け方の表にします。

その他は、400（content_filter、不正なリクエスト、入力がコンテキストを超える）、401（鍵が不正、またはない）、403（APIが開いていない、IPが許可リストにない）、404（モデルがない、またはそのアカウントに権限がない）、499、500、503、504です。

自動の再試行に注意。 Troubleshooting は、OpenAIのSDKが既定で2回再試行する（合計3回のリクエスト）こと、最も低い段階では、1回の失敗でRPMの枠を使い切ることがある、と書いています。SDK側で max_retries を明示するかどうかを決めておきます。

設定の形は、Kimiの文書ではなく、OpenAI公式のPython SDKのREADME（2026年10月24日に確認）に載っています。READMEは、接続エラー、408、409、429、500以上のエラーを、既定で2回、短い指数バックオフで再試行すると書き、次の2つの設定を示しています。0 で再試行を止められ、0以上の整数だけが使えます。

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
    max_retries=0,   # 既定は2。0で自動の再試行を止める
)
# リクエスト単位なら
client.with_options(max_retries=5).chat.completions.create(...)

同じREADMEは、リクエストのタイムアウトの既定が10分で、timeout=20.0 のように変えられ、タイムアウトしたリクエストも既定で2回再試行される、とも書いています。上の504（900秒）の話と合わせると、画面なしの処理では、timeout を明示し、stream: true を使うのが無難です（これは僕らの見立てです）。

自動の再試行を止めたときの、429の受け方の骨組みを、僕らの整理として示します。公式の対処（Retry-After に従い、並列を減らし、指数バックオフ）を写したもので、公式のコード例ではなく、この記事では動作を確かめていません。exceeded_current_quota_error（残高不足）は待っても直らないので、再試行の対象に入れません。

import time, random
from openai import RateLimitError

def call_with_backoff(make_request, max_attempts=5):
    for attempt in range(max_attempts):
        try:
            return make_request()
        except RateLimitError as e:
            body = getattr(e, "body", None) or {}
            err = body.get("error", body) if isinstance(body, dict) else {}
            if err.get("type") == "exceeded_current_quota_error":
                raise                      # 入金や請求の確認が先
            retry_after = getattr(e, "response", None) and e.response.headers.get("retry-after")
            wait = float(retry_after) if retry_after else min(60, 2 ** attempt) + random.random()
            time.sleep(wait)
    raise RuntimeError("429 が続いたので止めます")

error.type の取り出し方（e.body の形）は、SDKの標準の使い方を前提にした僕らの想定で、Kimiのレスポンスで確かめていません。

組織・プロジェクト・鍵：どこで縛るか

公式の「Manage Your Organization, Projects, and API Keys」によると、構造は、組織（残高とレート制限を共有）、プロジェクト（使用額を分けて見る単位）、鍵（プロジェクトの中の認証情報）です。

公式のおすすめの分け方は、本番とテストを別のプロジェクト（別の鍵）にし、テストの日次予算を低くして、暴走したテストのスクリプトを抑える、です。鍵は共有せず、メンバーごとに作ります。

最初の10分でやること（公式に書かれている範囲）

1. platform.kimi.ai にサインインし、「API Keys」（platform.kimi.ai/console/api-keys）で鍵を作る。環境変数 MOONSHOT_API_KEY に入れ、リポジトリやログに出さない。
2. 先にPlaygroundでプロンプトを試す（公式のQuickstartが、コードを書かずに試せる場として挙げています。入金前でも使えるかは、読んだ範囲では書かれていませんでした）。MoonPalaceは、コードを書いてデバッグするときの別ツールです。
3. 動かすなら、最低1ドルを入金する。K3.1 Proは入金後に使えるようになる。
4. 上のcurlで1回呼ぶ。model_not_found や401が出たら、鍵を作ったサイトとベースURL、モデル名を確かめる。
5. GET /v1/models で、自分のアカウントで使えるモデルを確かめる（401や404の確認手順に、公式が挙げている）。
6. 「Project Settings」でテスト用プロジェクトの日次予算を低く決め、残高の通知を確かめる。
7. ツールを使うなら、ループの最大回数、出力のトークン上限、HTTPのタイムアウトを、コードに入れてから動かす。

僕らの見立て

• 最初の接続は Chat Completions、kimi-k3.1-pro、reasoning_effort は low から。 公式の既定は max で、遅く、トークンも多く使いやすいと読めます。必要になってから上げます。
• max_completion_tokens を明示します。 省略しても動きますが、レート制限の確認は、省略時は既定値（K3系は131072）で数えられる、と読めます。短い質問の画面なしの処理では、段階が低いうちは、これが先に枠を食う可能性があります（段階の数字は読めていないので、確かなことは言えません）。
• メッセージは、加工せずに丸ごと戻す関数を1つ作ります。 ツール呼び出しの失敗の大半は、公式の説明を読むかぎり、ここに集まっています。
• 画面なしの処理は、ログに request_id、usage、finish_reason を残します。 請求の突き合わせに、公式がこれらを挙げています。
• 2つの価格の読み方を分けます。 kimi-k3 の数字は、キャッシュのページに出ていたものです。kimi-k3.1-pro に同じ数字が当てはまるとは、書かれていません。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。運営者はKimiを入れていますが、使い心地はこの記事には書いていません。コードは公式ページの例の短縮版です。公式ページは要約として取得したので、原文の細部は未確認です。
• モデル名が変わっています。 2026年10月24日に読んだ範囲では、モデル一覧（Model List）とクイックスタート（get-your-api-key）の推奨は kimi-k3.1-pro で、kimi-k3 は「前の世代のフラッグシップ」と書かれています。一方、もう1つのクイックスタート（overview）は kimi-k3 から始めるよう書き、Model Parameter Reference とキャッシュの料金の例、Estimate Tokens は、まだ kimi-k3 を使っています。ページによって更新の時期が違うように見えます。
• K2系の終了の予告があります。 新規ユーザーは10月31日から使えず、12月末までに全部終了予定、と書かれています（Model List には「kimi-k2 シリーズは2026年5月25日に正式終了」という記載もあり、同じ公式内で終了の時期の書き方が食い違っています）。kimi-k2.6 を前提にした設計は、期限を確かめます。また、kimi-k2.5 と moonshot-v1 の系列は、2026年8月に終了して、呼ぶと404になる、と変更履歴にあります。
• 料金表が読めていません。 出力の単価、kimi-k3.1-pro の単価、レート制限の段階の数字は、読めた範囲にはありませんでした。
• 個人の入金方法が読めていません。 Account and Billing のページは、個人の入金を、WeChat PayかAlipayのQRコードでの支払い、と書いています。ほかの支払い方法（カードなど）は、読んだ範囲では見つかりませんでした。地域によって違うかもしれません。
• アカウントの削除は、プラットフォームでは今のところ非対応と、同じページにあります。アプリ（01）の削除の手順とは別です。
• データの扱いは、記事（03）と、APIの利用規約を読んでください。 学習への利用の制限には、企業向けの契約が必要、と02に書きました。
• ツールの結果は、信用できる入力とは限りません。 Web検索や取得の結果を、そのままモデルに渡すと、中の文章に従ってしまうことがあります。この点について、読んだKimiの文書に専用の注意書きは、見つかりませんでした（僕らの見立ての注意です）。
• 日付の表示がない公式ページが多く、変更履歴（2026年9月、8月、7月など）にある日付だけを日付として書きました。

出典

• Quickstart / get-your-api-key（Kimi API Platform、Moonshot AI、日付の表示なし、2026-10-24確認）
• Quickstart（Kimi API Platform、Moonshot AI、日付の表示なし、2026-10-24確認）
• Documentation index llms.txt（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Main Concepts（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Model List（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Kimi K3.1 Pro quickstart（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Kimi K3 quickstart（Kimi API Platform、Moonshot AI、2026-10-24確認）
• API Overview（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Model Parameter Reference（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Chat Completions API（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Responses API（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Messages API（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Common Error Codes（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Check Balance（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Estimate Tokens（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Use Kimi API for Tool Calls（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Tool Choice（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Kimi K3 API Tool Calling Best Practices（Kimi API Platform、Moonshot AI、2026-10-24確認）
• How to Fix Repeated Tool Calls（Kimi API Platform、Moonshot AI、2026-10-24確認）
• How to Use Official Tools in Kimi API（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Build an Agent with Kimi K3（Kimi API Platform、Moonshot AI、2026-10-24確認）
• What is Zero Data Retention (ZDR)?（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Using Batch API for Bulk Processing（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Best Practices for context caching（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Troubleshooting（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Manage Your Organization, Projects, and API Keys（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Account and Billing（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Model Inference Pricing Explanation（Kimi API Platform、Moonshot AI、2026-10-24確認。価格表は読めず）
• WebSearch Pricing（Kimi API Platform、Moonshot AI、2026-10-24確認）
• Recharge and Rate Limiting（Kimi API Platform、Moonshot AI、2026-10-24確認。段階の表は読めず）
• openai-python README（OpenAI、GitHub、日付の表示なし、2026-10-24確認。再試行とタイムアウトの設定の確認用）
• Platform Changelog（Kimi API Platform、Moonshot AI、2026年9月までの記載、2026-10-24確認）