Kimi 3 API の検索は増えていますが、公式のモデル名は Kimi K3 です。この命名の違いは、ドキュメントを探すとき、SDK を設定するとき、あるいはモデル識別子を選ぶときに重要です。API のモデル ID は kimi-k3 であり、kimi-3 ではありません。
2026年7月23日時点で、Moonshot AI は Kimi API Platform を通じて Kimi K3 を利用可能にしています。公式ドキュメントでは、ネイティブな視覚理解機能と 1,048,576 トークンのコンテキストウィンドウを備えた 2.8 兆パラメータの旗艦モデルとして説明されています。OpenAI 互換のインターフェース経由で呼び出すことができ、Moonshot はフルモデルの重みを 2026年7月27日までに公開すると述べています。
このガイドでは、確認済みの内容と、なお監視が必要な内容を分けて整理し、Kimi K3 API の基本的なセットアップ方法を示し、さらに Kimi K3 と今後の高速なモデル公開に向けて、統合をそのたびに作り直さずにアプリケーションを準備する方法を説明します。
Kimi 3 か Kimi K3 か:正しい名称はどれですか?
公式名称は Kimi K3 です。「Kimi 3」は自然な検索語ですが、Moonshot AI の लॉन्चページ、API プラットフォーム、ドキュメント、モデル ID のいずれも Kimi K3 を使用しています。
以下の用途では、それぞれ適切な用語を使ってください:
- 検索と学習用の説明文: “Kimi 3 API (Kimi K3)” と表記すると、一般的な検索語と公式製品名を結び付けやすくなります。
- API リクエスト:
modelフィールドにはkimi-k3を使用します。 - 技術ドキュメント: 命名の違いを一度説明したうえで、以後は “Kimi K3” を優先してください。
これにより、公開直後によくある問題、つまり非公式のモデル名をコードにコピーしてしまい、出てきたエラーを API が利用できないことの意味だと誤解する事態を避けられます。
Kimi K3 API について確認済みの内容は何ですか?
以下の詳細は、2026年7月23日に Moonshot AI の公式資料で確認されています:
| 項目 | 確認済みの情報 |
|---|---|
| 公式モデル名 | Kimi K3 |
| API モデル ID | kimi-k3 |
| 公式 API ベース URL | https://api.moonshot.ai/v1 |
| API 形式 | OpenAI API 形式と互換 |
| チャットエンドポイント | /chat/completions |
| コンテキストウィンドウ | 1,048,576 トークン |
| モダリティ | テキスト、画像、動画入力がドキュメント化されています |
| 推論 | 常時有効。reasoning_effort は low、high、max をサポート |
| API への直接アクセス | K3 のロックを解除するには、少なくとも 1 ドルのチャージ成功が必要 |
| フルモデルの重み | 2026年7月27日までに公開予定 |
Moonshot の公式 Kimi K3 料金ページでは、現在、100 万トークンあたり キャッシュヒット入力 $0.30、キャッシュミス入力 $3.00、出力 $15.00(適用される税金を除く)と記載されています。これらは時間依存の数値として扱い、予算策定や固定比較を公開する前に、公式の料金ページを改めて確認してください。
公式の発表資料には、ベンチマークとアーキテクチャに関する主張も含まれています。これらは評価の出発点としては有用ですが、チームは公開時のチャートを本番導入の判断材料として扱うのではなく、自社のプロンプト、ツール、レイテンシ要件、出力レビュー基準でテストを再現すべきです。
Kimi K3 API に直接アクセスする方法
Moonshot は OpenAI 互換のセットアップを文書化しているため、すでに OpenAI SDK を使っている開発者は、API キーとベース URL を変更するだけでクライアントを初期化できます。
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
response = client.chat.completions.create(
model="kimi-k3",
messages=[
{
"role": "user",
"content": "Summarize the main risks in this migration plan.",
}
],
reasoning_effort="low",
)
print(response.choices[0].message.content)
OpenAI 互換であることは、すべてのモデルが同一の挙動をすることを意味しません。Kimi K3 にはモデル固有のルールがあります。現在のドキュメントによると、思考モードは常に有効で、いくつかのサンプリングパラメータは固定されており、視覚入力に対する公開画像 URL はサポートされていません。既存の本番ワークロードをそのまま移行する前に、K3 のパラメータ制限を確認してください。
OpenAI 互換 API が役立つ理由——ただし戦略のすべてではない
OpenAI 互換 API は、統合作業の手間を減らしてくれます。アプリケーションは、ベース URL、API キー、モデル名を変更するだけで、同じクライアントライブラリとリクエスト構造を保てることがよくあります。
しかし、転送層で互換性があるからといって、モデル間の運用上の違いがなくなるわけではありません。
- サポートされるリクエストパラメータは異なる場合があります;
- 構造化出力の挙動は回帰テストが必要です;
- ツール呼び出しのスキーマとツール選択ルールは異なることがあります;
- 推論はレイテンシとトークン消費を変える可能性があります;
- コンテキスト制限が同じ長文パフォーマンスを保証するわけではありません;
- レート制限と可用性はアカウント階層によって変わる場合があります;
- マルチモーダル入力要件はプロバイダー固有である可能性があります。
長期的に有効なアプローチは、製品コードをプロバイダー固有のアクセスから切り離すことです。アプリケーションは安定したモデルアクセス層を呼び出し、ルーティングポリシー、プロバイダー認証情報、フェイルオーバー、クォータ、利用状況レポートはコア機能の外側で設定可能にしておくべきです。
Kimi K3 と次のモデル公開に向けてアプリを準備する
高速なモデル公開は、評価 と 移行 という 2 つの異なる作業を生みます。これらを 1 回の緊急コード変更にまとめると、どちらも難しくなります。
1. API サーフェスを安定させる
コードベース全体にプロバイダー SDK の初期化を散在させるのではなく、アプリケーション内で 1 つの OpenAI 互換クライアント境界を使いましょう。安定したベース URL があれば、すべての機能を書き換えることなく、サポート対象モデルの追加や置き換えが容易になります。
Flatkey は、対応モデル向けに 1 つの API キーと OpenAI 互換のベース URL https://router.flatkey.ai/v1 を提供します。2026 年 7 月 23 日に確認した時点では、公開ライブカタログに kimi-k3 が利用可能として掲載されていました。
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["FLATKEY_API_KEY"],
base_url="https://router.flatkey.ai/v1",
)
response = client.chat.completions.create(
model="kimi-k3",
messages=[
{"role": "user", "content": "この実装計画をレビューしてください。"}
],
)
導入前には、必ず現在のモデルカタログとパラメータ対応状況を確認してください。提供状況、ルート設定、価格はリリース後に変更される可能性があります。
2. モデルの話題性ではなく、ワークロードでルーティングする
新しくリリースされたモデルに初日からすべてのトラフィックを送らないでください。次のような評価クラスを定義します。
- リポジトリ規模のコーディング;
- 文書分析;
- ツール使用エージェント;
- 構造化データ抽出;
- 画像または動画の理解;
- 低遅延のカスタマーチャット。
そのうえで、各クラスについて品質、レイテンシ、トークン消費、失敗時の挙動をテストします。モデルは長期的なコーディングでは優れていても、短い分類呼び出しには不要である場合があります。
3. 本番トラフィックの前にモデルのフォールバックを定義する
モデルのフォールバックポリシーは、「Kimi K3 が停止した場合に何を実行するか?」以上のことに答える必要があります。具体的には、次を定義します。
- どのバックアップモデルが同じ入力モダリティをサポートするか;
- どのリクエストパラメータを削除または変換する必要があるか;
- バックアップが構造化出力とツール呼び出しを維持するか;
- 許容可能な最大コストとレイテンシ;
- 信頼度の低い回答を返すのではなく、明示的に失敗させるべきタイミング。
Flatkey のルーティングと自動切り替え機能により、チームは 1 つの統合の背後で対応する上流ルートを管理できます。モデルの可用性が変化しても、アプリケーションは安定した API 境界を維持しながら、ルーティングポリシーを進化させられます。
4. 使用量を追跡し、クォータを中央で適用する
新しいモデルは、平均トークン消費量と出力長の両方を変える可能性があります。使用量を一元的に追跡することで、エンジニアリングと財務の両方が、実験が製品改善につながっているのか、それとも単に支出を増やしているだけなのかを把握できます。
Flatkey は、使用状況の可視化、統合請求、API キー管理、クォータ制御を 1 つのダッシュボードにまとめています。これは、複数のチームが GPT、Claude、Gemini、DeepSeek、Qwen、またはその他の対応モデルと並行して Kimi K3 をテストしている場合に特に有用です。
直接の Kimi API か、マルチモデル AI ゲートウェイか?
どちらのアプローチも有効です。
直接の Kimi AI API を選ぶのは、Moonshot 固有の機能へ最短で到達したい場合、別のプロバイダーアカウントを管理することに抵抗がなく、Kimi の現在の API 挙動に合わせて細かく最適化する予定がある場合です。
マルチモデル AI ゲートウェイ を選ぶのは、アプリケーションでモデル比較が必要な場合、広範なコード変更なしでルートを切り替えたい場合、フォールバックを設定したい場合、使用状況レポートを統合したい場合、またはプロバイダーをまたいでチームのクォータを管理したい場合です。
この選択は必ずしも恒久的なものではありません。OpenAI互換のクリーンな境界があれば、アプリケーション層を比較的安定させたまま、チームは直接接続ルートとゲートウェイルートをテストできます。
実装の詳細については、FlatkeyのOpenAI互換APIゲートウェイ移行チェックリストを読み、その後で、より広範なAI APIゲートウェイアーキテクチャガイドを確認してください。
Kimi K3評価チェックリスト
Kimi K3に本番トラフィックを振り分ける前に、以下を確認してください。
- 正確なモデルIDとルートが利用可能であること。
- 現在の入力、出力、キャッシュの価格。
- アカウント階層ごとのレート制限と同時実行数。
- 必要な
reasoning_effortの動作。 - ツール呼び出しと構造化出力の互換性。
- マルチモーダルのファイルおよびURL制限。
- 現実的なコンテキストサイズでのレイテンシー。
- レート制限またはプロバイダーエラー時のフォールバック動作。
- 使用状況、請求、クォータの可視性。
- 自社の受け入れ基準セットでの出力品質。
100万トークンのコンテキストウィンドウは重要な機能ですが、ワークロード固有のテスト、可観測性、コスト管理の代わりにはなりません。
FAQ
Kimi 3はKimi K3と同じですか?
「Kimi 3」は一般的な検索フレーズであり、Kimi K3が正式なモデル名です。APIのモデルIDとしてはkimi-k3を使用してください。
Kimi K3 APIは現在利用できますか?
はい。2026年7月23日時点で、Kimi K3は公式のKimi API Platformで文書化され、利用可能です。Flatkeyの公開ライブモデルカタログでも、その日にkimi-k3が利用可能として掲載されていました。
Kimi K3 APIはOpenAI互換ですか?
Moonshotは、Kimi APIがOpenAI互換形式を使用していると述べています。開発者はMoonshotのベースURLとAPIキーを使ってOpenAI SDKを利用できますが、K3固有のパラメータ規則には注意する必要があります。
Kimi K3のコンテキストウィンドウはどのくらいですか?
公式ドキュメントでは、1,048,576トークンのコンテキストウィンドウが示されており、一般には100万トークンと表現されます。
Kimi K3で推論を無効にできますか?
いいえ。現在のドキュメントでは、Kimi K3は常に思考が有効であると記載されています。reasoning_effortはlow、high、maxに調整できます。
Kimi K3にAI APIゲートウェイを使うのはなぜですか?
AI APIゲートウェイは、対応モデルへのアクセス、ルーティング、フォールバック、使用状況追跡、請求、クォータ制御を一元化しつつ、アプリケーションから見えるAPI境界を1つに保てます。これにより、モデルや可用性が急速に変化しても運用負荷を抑えられます。
1つのモデルだけでなく、モデルの変化に備えて構築する
Kimi K3は、長文コンテキスト、マルチモーダル、コーディング、ナレッジワークのワークロードを評価する開発者にとって、重要な新しい選択肢です。より大きなアーキテクチャ上の教訓は、モデルへのアクセスは今後も変化し続けるということです。
Flatkeyは、ルーティング、利用状況、請求、クォータ管理のために、1つのAPIキー、1つのOpenAI互換ベースURL、1つのダッシュボードを通じて、対応モデルへチームがアクセスできるようにします。次のモデル評価の前に、現在のモデルカタログと価格を確認してください。



