Moonshot API は Moonshot AI オープンプラットフォームが提供するモデルインターフェースで、Kimi の背後にある開発者プラットフォームです。トークン使用量に応じた課金で、サブスクリプションパッケージはありません。多くのチームが予算を立てるとき、二つの点で誤ります。一つはすでに提供終了した moonshot-v1 系を呼び続けていること、もう一つは入力、キャッシュ書き込み、出力、再試行を一つの平均単価に混ぜてしまうことです。本記事では 2026 年 10 月の公開ドキュメントに基づいて課金構造を分解します。具体的な価格はモデル価格と公式ドキュメントを基準としてください。

注記：Moonshot、Kimi はそれぞれの権利者の商標です。本記事は技術的な説明のみを目的とし、権利者との資本関係や代理関係を示すものではありません。モデル一覧、コンテキスト長、課金規則は調整される場合があるため、調達前に公式ページを再確認してください。

一、まず「現行モデル」と「提供終了モデル」を分ける

2026 年 10 月時点で、オープンプラットフォームのドキュメントに掲載されている主力モデルは kimi-k3、kimi-k2.6、kimi-k2.7-code、kimi-k2.7-code-highspeed です。旧 moonshot-v1 シリーズはすでに終了しています。moonshot-v1-8k、-32k、-128k、-auto および対応する視覚プレビュー版は 2026 年 8 月 31 日に提供終了し、同日に kimi-k2.5 も終了しました。さらに古い kimi-k2 プレビュー版や kimi-latest などもサービスを停止しています。

モデル コンテキスト 課金構造 状態と注意
kimi-k3 1,048,576 入力、キャッシュヒット、キャッシュ書き込み、出力 現行フラッグシップ。公式は移行先として推奨
kimi-k2.6 262,144 入力、キャッシュヒット、出力 汎用とマルチモーダル。コスト重視の場面で多用
kimi-k2.7-code 262,144 入力、キャッシュヒット、出力 コード生成、リポジトリ Q&A、Agent
kimi-k2.7-code-highspeed 262,144 入力、キャッシュヒット、出力 低遅延のコードタスク
moonshot-v1-8k/32k/128k モデル名による 旧版は長さで段階分け 2026-08-31 に提供終了

古いチュートリアルのモデル名をそのままコピーしないでください。moonshot-v1-8k の「8k」はコンテキストの段階そのもので、呼び出し失敗は Key の問題ではなく、モデル名がすでに存在しないためです。移行時はまずモデル名を変更し、それからコンテキストと課金項目を照合してください。単純な文字列置換だけで済ませないでください。

二、課金単位：一回のリクエストを四項目に分ける

現在の請求は通常、四種類のトークンで構成されます。キャッシュミスの入力、キャッシュヒットの入力、キャッシュ書き込み、出力です。K3 のキャッシュ書き込みは 5 分と 1 時間の二つの TTL で個別に課金されます。K2 シリーズの価格ページにはキャッシュ書き込みの項目が単独でありません。一回のリクエストを式にすると次のようになります。

1回のリクエストコスト =
  ミス入力トークン × ミス単価
+ キャッシュヒット入力トークン × ヒット単価
+ キャッシュ書き込みトークン × 対応TTL単価（K3のみ）
+ 出力トークン × 出力単価

公式ドキュメントには有用な換算があります。標準的な中国語テキストでは、およそ 1.5 から 2 文字が 1 トークンに対応します。文字数に単価を直接掛けると入力量を過小評価します。正式な試算では POST /v1/tokenizers/estimate-token-count の見積もりインターフェースを使うか、レスポンスの usage を直接読んでください。

Chat Completions の使用量フィールドは usage.prompt_tokens、usage.completion_tokens で、キャッシュの内訳は usage.prompt_tokens_details.cached_tokens と cache_write_tokens にあります。Messages API の input_tokens はキャッシュ部分を含まないため、総入力は input_tokens、cache_read_input_tokens、cache_creation_input_tokens を合計します。ストリーミング呼び出しでは stream_options.include_usage=true を設定してください。

三、キャッシュの課金と、ヒットしない理由

コンテキストキャッシュはプレフィックス単位で照合し、会話全体で照合するわけではありません。プレフィックスのどこか一箇所が変わると、その位置より後の内容は再利用できません。プレフィックスを壊すよくある行為には、system prompt へのタイムスタンプやランダム ID の挿入、毎回のツール定義の並べ替え、ナレッジベース断片の動的な結合、TTL 段階の切り替えがあります。キャッシュは組織単位で分離され、組織をまたいで共有されません。

K3 のキャッシュ書き込みは初回書き込み時に課金され、TTL は 5 分または 1 時間に固定され、書き込み後に途中で段階を変更できません。ヒット時は元の TTL で無料で更新され、書き込み費は再度かかりません。二つの TTL のキャッシュは相互に通じません。プレフィックス末尾が一つの完全なキャッシュブロックに満たない場合、その部分は通常ミスとして扱われます。

キャッシュは「有効にすれば節約できる」スイッチではなく、プレフィックスの設計です。system prompt、ツール定義、固定例、ナレッジベースの共通部分を先頭に置き、変数を最後に置き、cached_tokens でヒット率を検証してください。

四、長コンテキストのコスト：高くつくのは繰り返し転送

K3 は 1,048,576 トークンのコンテキストに対応し、K2 シリーズは 262,144 トークンです。K3 は統一された従量課金を採用し、旧 moonshot-v1 のように 8k、32k、128k で長さ段階を分けていません。そのため旧版の段階価格表で K3 を推算することはできません。

長コンテキスト自体は問題ではありません。問題は、同じ資料を毎ターン再送することです。20 万トークンの文書 Q&A で、十回連続して質問し、毎回全文を付けると、入力コストはターン数とともに急速に積み上がります。ツールログ、Web ページ本文、コード結果も履歴に残り、課金され続けます。より一般的な方法は、まず関連する断片を検索してからモデルに読ませる、複数ターンの会話はローリング要約にする、安定した部分をキャッシュプレフィックスにする、原文を保持すべき部分だけ長コンテキストを使う、というものです。

長コンテキストは遅延と失敗率も増幅します。非ストリーミングの長いリクエストはゲートウェイタイムアウトに遭いやすく、再試行が新たな入力使用量を生みます。長いタスクではストリーミング出力を優先し、適切な読み取りタイムアウトを設定してください。

五、再試行と失敗リクエストの扱い

公式のエラーコードは 429 を三種類に分けています。rate_limit_reached_error は組織レベルの同時実行、RPM、TPM、TPD の上限到達、exceeded_current_quota_error は残高または枠の不足、engine_overloaded_error はサーバー側の容量過負荷です。残高系の問題だけがチャージで解決でき、容量過負荷はチャージしても直接解消しません。500、503 は通常、後で再試行することが推奨されます。長いリクエストのゲートウェイタイムアウトは、そのまま再送するよりストリーミングに変更するほうが適しています。

失敗リクエストが課金されるかについて、公式ドキュメントは「失敗は無料」という約束をしていません。安全な方法は、再試行にコストがないと仮定せず、リクエストログと usage で照合し、再試行回数を別に集計することです。再試行戦略は次の順序で実装できます。

  1. まずエラーコードで分類する。滞納、パラメータエラー、内容審査失敗は再試行しない。
  2. 429 のレート制限、500、503、ネットワーク中断に限り、回数を制限して再試行する。
  3. 指数バックオフとランダムジッターを使い、Retry-After を尊重する。
  4. 再試行に上限と総時間を設け、同時実行を占有し続けない。
  5. ツール呼び出しには冪等キーまたは重複排除テーブルを使い、二重注文や二重送信を防ぐ。
  6. request_id、モデル名、トークン使用量、再試行回数を記録し、照合しやすくする。

六、予算の見積もり：トークンから月間上限へ

予算は「100 万トークンあたりいくらか」から逆算するのではなく、実際のタスクから逆算してください。代表的なタスクを 20 から 50 件選び、簡単、中程度、複雑の三段階をカバーし、検収基準を明記します。次に見積もりインターフェースで入力を測り、実際の呼び出しの usage を読み、「合格するタスク一つを完成させる総コスト」でモデルを比較します。

import os
import requests

resp = requests.post(
    "https://api.moonshot.cn/v1/tokenizers/estimate-token-count",
    headers={"Authorization": f"Bearer {os.environ['MOONSHOT_API_KEY']}"},
    json={
        "model": "kimi-k3",
        "messages": [{"role": "user", "content": "この契約を JSON に抽出してください：……"}],
    },
    timeout=30,
)
print(resp.json()["data"]["total_tokens"])

一回分の入力を見積もったら、さらに四つを加えます。履歴メッセージ、ツールの戻り値、キャッシュミスの比率、再試行による追加呼び出しです。オフラインバッチ処理では Batch API を評価できます。公式ドキュメントによると同期呼び出しより約四割安いものの、現在対応するのは kimi-k2.7-code と kimi-k2.6 で、kimi-k3 は未対応です。

予算管理は三層に分けることをおすすめします。プロジェクトごとに日次予算と月次予算を設定し、コンソールが上限に達するとそのプロジェクトのリクエストを拒否しますが、反映には約十分の遅延があります。Key またはメンバー単位で分割し、一つの業務が組織全体の枠を使い切らないようにします。モデルと場面ごとに週次照合を行い、最も速く伸びている呼び出しを見つけます。残高アラートは突然の供給停止を防ぐだけで、予算の代替にはなりません。

七、コスト削減の順序と照合の習慣

コスト削減の順序を逆にしないでください。まずキャッシュと入力のガバナンス、次に出力の制限、最後にモデル変更を検討します。逆にすると、誤った回答を安く作るだけになります。

  1. system prompt、ツール定義、ナレッジベースのプレフィックスを固定し、cached_tokens を検証する。
  2. 検索と要約で毎回送る原文を減らし、履歴メッセージはローリング要約にする。
  3. max_completion_tokens を設定し、JSON または固定フィールドを求め、開放的な長文出力を減らす。
  4. タスクごとにモデルをルーティングする。汎用タスクは kimi-k2.6、コードタスクは K2.7 コード版、超長文は K3 に回す。
  5. 長いリクエストはストリーミングに変更し、タイムアウトと切断による再試行を減らす。
  6. オフライン処理は Batch API、リアルタイム処理は同期インターフェースを維持する。
  7. 毎月、プロジェクト、モデル、場面の三次元で照合し、キャッシュヒット率、再試行回数、平均出力長を別に記録する。

照合表には少なくとも次を含めます。呼び出し時刻、プロジェクト、モデル、入力トークン、キャッシュヒットトークン、キャッシュ書き込みトークン、出力トークン、再試行回数、request_id。これらの項目がないと、請求に差異が出たときに推測するしかありません。

よくある質問

moonshot-v1-8k はまだ呼び出せますか？

いいえ。moonshot-v1 全系は 2026 年 8 月 31 日に提供終了し、公式は kimi-k3 への移行を推奨しています。移行時はモデル名だけでなく、コンテキスト長、課金項目、出力パラメータも再確認してください。

キャッシュヒットが有効にならないのはなぜですか？

まずプレフィックスがタイムスタンプ、ランダム ID、動的な並べ替え、ツールの再配置で壊れていないか確認します。次にリクエスト間隔が TTL を超えていないか、キャッシュの書き込みと読み取りが同じ組織、同じ TTL 段階か確認します。cached_tokens で判断し、感覚に頼らないでください。

長コンテキストは必ず高くつきますか？

いいえ。ただし長い資料を繰り返し送ると通常は高くつきます。コストは入力が繰り返される回数、キャッシュヒット率、出力長に依存します。まず検索で範囲を絞り、それから百万トークン級のコンテキストを使うか決めてください。

失敗したリクエストは課金されますか？

公式ドキュメントは失敗無料を約束していません。再試行がゼロコストだと仮定せず、リクエストログと usage で照合し、再試行回数をタスク単価に含めてください。

最新の価格はどこで確認できますか？

モデル価格と Moonshot/Kimi の公式ドキュメントを基準とします。価格、モデル一覧、キャッシュ規則は変更される場合があるため、古いスクリーンショットを流用しないでください。

次のステップ

まずZSQH AI Gatewayでテスト用 Key を作成し、kimi-k2.6 と kimi-k3 でそれぞれ実際のタスクを一批実行し、入力、出力、キャッシュヒット、再試行を記録してから、主力モデルと月間予算を決めてください。具体的な価格と利用可能なモデルはモデル価格を基準とします。

関連記事：