Tracks
オープンモデル競争は2026年7月16日、Moonshot AIがKimi K3をリリースしたことで再び動きました。Kimi K3は2.8兆パラメータ、100万トークンのコンテキストウィンドウ、そしてネイティブなビジョン機能を備えています。これはMoonshotが出荷した中で最大のオープンモデルであり、サイズ面でKimi K2を大きく上回り、同社が初めて「3兆パラメータ級」に到達したと述べるモデルです。
ローンチの経緯、アーキテクチャの詳細、ベンチマークのチャート、ClaudeやGPT、その他の中国系ラボとの比較、そしてMoonshotが公表する制約一覧が知りたい場合は、Kimi K3のブログ記事をご覧ください。本チュートリアルでは、実際の使い方に焦点を当て、アクセス方法や挙動を解説します。API経由の小さな例を4つ(実際のトークン使用量とコストを表示)と、kimi.comのWebアプリでの例を2つ取り上げます。あわせて、K3が次の点をどのように扱うかをカバーします。
- ツールの呼び出しと厳密なJSONの返却
- ツール定義のオンデマンド読み込み
- 自動キャッシュによる長文コンテキストのコスト削減
- スクリーンショットの読解とレイアウト修正
- 1つのプロンプトからインタラクティブなダッシュボードを構築
4つのAPI例は2026年7月17日に kimi-k3 モデルで実行し、コールドスタートでは約11セント、キャッシュが効いた後は数セントでした。
Kimi K3へのアクセス方法
最も手早く試すなら kimi.comです。セットアップ不要で、Webアプリとモバイルアプリが一般的なエージェント作業にKimi K3を使います。
レポートやダッシュボードのような重い作業には、デスクトップアプリのKimi Workがあります。
ターミナル中心で作業する場合は、npmから @moonshot-ai/kimi-code としてインストールできるコーディングエージェント「Kimi Code」があります。モデルは /model コマンドで選択します。Kimi CodeでK3を使うには有料メンバーシップが必要で、100万トークンのフルウィンドウには上位プランが必要です。
本チュートリアルは生のAPIとWebアプリに焦点を当てますが、必要ならターミナルエージェントも利用できます。
なお、K3が兄弟モデルを置き換えるわけではありません。以下の表は現在のラインナップの棲み分けを示します。
|
モデル |
コンテキストウィンドウ |
最適な用途 |
|
|
1,048,576トークン |
フラッグシップ用途:長尺コーディング、ビジョン、知識タスク |
|
|
262,144トークン |
コード専用。高速オプションあり |
|
|
262,144トークン |
一般的なテキスト・画像・動画のチャット |
要するに、コード、ツール、ドキュメント、画像が混在する仕事や、100万トークンのウィンドウが本当に必要な場合はK3から始めるのが良いということです。速度重視の純粋なコード生成であれば、kimi-k2.7-codeの方が理にかなっています。常に最新モデルが最適とは限りません。
Kimi K3 APIのセットアップ
APIはOpenAI SDKと互換性があるため、以前に使ったことがあるなら、ほとんど新しい点はありません。Python 3.9以降とAPIキーが必要です。
ステップ1:APIキーの発行
まずKimiプラットフォームにサインインし、コンソールのAPI Keysページを開きます。キーを作成して一度コピーし、安全な場所に保管してください。再表示はされません。呼び出しのためにアカウントに少額の残高も必要です。このチュートリアル全体でも数ドルあれば十分です。

Kimi K3のAPIキー作成。画像:筆者。
ステップ2:SDKのインストール
次に、OpenAI SDKを環境へインストールします。コマンドは1行です。
python -m pip install --upgrade "openai>=1.0"
これで以降の例で使用するクライアントライブラリが入ります。Kimi固有のインストールは不要です。
ステップ3:キーの保存とクライアント初期化
キーはコードに貼り付けるのではなく、環境変数から読む方が安全です。シェルや.env ファイルでMOONSHOT_API_KEYを設定し、クライアントのベースURLをMoonshotに向けます。
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
標準的なOpenAIセットアップと異なるのはbase_urlとモデル名(kimi-k3)の2点だけです。これで呼び出しの準備は完了です。
ステップ4:最初の呼び出し
まずは初回のリクエストです。モデルに自己紹介を1文で求めたところ、率直なやり取りになりました。
completion = client.chat.completions.create(
model="kimi-k3",
messages=[{"role": "user", "content": "Introduce Kimi K3 in one sentence."}],
max_completion_tokens=800,
)
print(completion.choices[0].message.content)
返答は推測の丁寧な拒否でした。自分自身のリリース前に訓練されたためKimi K3に関する信頼できる情報は持っていない、と述べ、代わりにMoonshotの発表を案内しました。モデルは自分自身について知っているわけではない、という有用なリマインダーです。このAPIコールのコストは約0.7セントでした。なお、本チュートリアルでは冗長な出力で費用が膨らむのを防ぐため、毎回max_completion_tokensを設定しています。

Kimi K3の初回API呼び出し出力。画像:筆者。
例1:推論のストリーミングと最終回答
K3は常に推論を行い、APIは回答とは別のチャンネルで推論を返します。ストリーミングでは、各チャンクがreasoning_contentや最終的なcontent、あるいはその両方を含み得るため、思考過程と答えを分けて配置できます。
stream = client.chat.completions.create(
model="kimi-k3",
messages=[{"role": "user", "content": "A bat and a ball cost $1.10 together. The bat costs $1.00 more than the ball. How much is the ball?"}],
max_completion_tokens=1200,
stream=True,
stream_options={"include_usage": True},
)
for chunk in stream:
if not chunk.choices:
continue
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)
モデルはまず作業過程をストリーミングしました。バットとボールの問題をCognitive Reflection Testの古典と認識し、直感的な誤答である$0.10を指摘し、代数でボールが$0.05であることを導き、$1.05と$0.05で$1.10になることを確認しました。重要なのは分離です。実アプリではユーザーにはcontentを表示し、reasoning_contentはログに残すのが現実的です。生の推論を本番で見せるのは稀にしか望ましくありません。この呼び出しは出力トークン488で、コストは1セント未満でした。

推論のストリーミングと最終回答。画像:筆者。
例2:構造化出力を伴うツールコール
Kimi K3はラインナップの中でtool_choice="required"をサポートし、少なくとも1回のツール呼び出しを強制できます。これは、モデルに当て推量させずに、回答前にデータ取得を行わせたいときに有用です。ここでは価格照会と在庫確認の2つのモックツールを用意し、ツールコールを強制してローカルで実行し、response_formatで厳密なJSONとして結果を求めました。
first = client.chat.completions.create(
model="kimi-k3",
messages=messages,
tools=TOOLS,
tool_choice="required",
max_completion_tokens=2500,
)
assistant_message = first.choices[0].message
messages.append(assistant_message)
for tool_call in assistant_message.tool_calls or []:
args = json.loads(tool_call.function.arguments)
messages.append({"role": "tool", "tool_call_id": tool_call.id, "content": run_tool(tool_call.function.name, args)})
モデルは両方のツールを正しい商品コードで呼び出し、その後、5台のメカニカルキーボード(1台$89)、合計$445、在庫フラグtrueという、きれいな注文サマリーをJSONで返しました。実用上のポイントは2つ。ツール結果を追加する前に、該当のアシスタントメッセージ全体を必ず会話へ戻すこと。そしてJSONのパースはcontentのみに対して行い、推論フィールドは決してパースしないことです。2回の呼び出しの合計コストは1セント未満でした。

ツールコールと構造化JSON出力。画像:筆者。
例3:ツールの動的読み込み
ツールが数十個もある場合、毎回すべての定義を送るのはトークンの無駄で、プロンプトも散らかります。Kimi K3では、contentを持たないsystemメッセージにtoolsフィールドを載せて、会話の途中でツール定義を注入できます。その時点からツールが利用可能になり、実際に必要になるまで大きなツールカタログをキャッシュ済みのプレフィックスから外しておけます。
messages = [
{"role": "user", "content": "Convert 100 US dollars to euros at a rate of 0.92."},
{"role": "system", "tools": [{
"type": "function",
"function": {
"name": "convert_currency",
"description": "Convert an amount from one currency to another",
"parameters": {
"type": "object",
"properties": {"amount": {"type": "number"}, "rate": {"type": "number"}},
"required": ["amount", "rate"],
},
},
}]},
]
completion = client.chat.completions.create(model="kimi-k3", messages=messages)
print(completion.choices[0].message.tool_calls)
K3は読み込んだばかりのツールを検出し、convert_currencyを金額100、レート0.92で呼び出しました。意図通りです。1つ覚えておくべきは、サーバーがこの定義を保持してくれるわけではない点です。ツールを使い続けたい場合は、後続のリクエストでも同じsystemメッセージを再送してください。これはセット中で最も安価な呼び出しで、約0.2セントでした。

動的に読み込んだ通貨ツールを呼び出し。画像:筆者。
例4:キャッシュで長文コンテキストのコストを削減
この例は、100万トークンウィンドウの実用面です。コンテキストキャッシュは自動で、キャッシュIDやTTLの管理は不要です。大きなプレフィックスを送り、後続のリクエストでバイト単位で同一のままにしておくと、繰り返し部分はキャッシュミスではなくキャッシュヒットのレートで課金されます。違いが分かるよう、約33,000トークンのナレッジベースを用意し、それに関する質問をしました。
knowledge = Path("knowledge_base.md").read_text(encoding="utf-8")
completion = client.chat.completions.create(
model="kimi-k3",
messages=[
{"role": "system", "content": knowledge},
{"role": "user", "content": "What is the rated payload of the Atlas robot?"},
],
max_completion_tokens=600,
)
プレフィックスを初めて送ったときはキャッシュがなく、約33,000の入力トークンで約9.9セントかかりました。プレフィックスが認識された後、同じリクエストでは32,512トークンのプレフィックスがすべてキャッシュヒットとなり、約1.1セントまで下がりました。約9倍の低下です。理由は価格差で、キャッシュ済み入力は100万トークンあたり$0.30、未キャッシュは$3.00です。1つのクセとして、キャッシュ書き込みは非同期のため、直後の連続呼び出しではヒットが出ません。後のリクエストで反映されるので、スクリプトを1分ほど間を空けて2回走らせると、最初はミス、次にヒットが確認できます。

キャッシュミスとキャッシュヒットのコスト比較。画像:筆者。
例5:スクリーンショットからのレイアウト不具合の特定
K3はビジョン機能をネイティブ搭載しており、APIでもすっきり扱えますが、公開画像URLは受け付けません。画像はbase64のデータURLで送り、メッセージのcontentはオブジェクトの配列にします。画像用とテキスト用の2要素です。いくつか意図的にレイアウト不具合を含む小さなダッシュボードを描画してスクリーンショットを取り、K3に問題点を尋ねました。

意図的なレイアウト不具合を含むダッシュボード。画像:筆者。
import base64
from pathlib import Path
image_data = base64.b64encode(Path("broken_dashboard.png").read_bytes()).decode()
completion = client.chat.completions.create(
model="kimi-k3",
messages=[{
"role": "user",
"content": [
{"type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_data}"}},
{"type": "text", "text": "List the layout and alignment problems you can see, and give a short CSS fix for each."},
],
}],
max_completion_tokens=3500,
)
print(completion.choices[0].message.content)
K3は画像をよく読めました。列より低く配置され隣と重なるカード、数値の上に乗ったバッジ(隠れた3,910を5,910と誤読したのは、まさに不具合の証拠)、最後のカード前の不均一な余白、上のカードに食い込むバー、バーの上に重なるツールチップを指摘し、各項目に短いCSS修正(カードを1つのグリッドにまとめる等)を示しました。一方で、ほとんど見えない低コントラストのサブタイトルは見逃しました。視覚は、薄い細部よりも目立つ要素を捉えやすいということです。コストは約2セントでした。
Kimi K3の制約
APIの例はうまく動きましたが、驚かないで済むように、いくつかの荒削りな点を挙げておきます。ほとんどは実際に遭遇しました。
-
現状は
reasoning_effort="max"のみ利用可能で、思考量を絞って節約することはまだできません。 -
サンプリング設定は固定です。
temperatureやtop_p、各種ペナルティはロックされているので、調整せずリクエストから省きます。 -
出力が長く高コストになりがちです。
max_completion_tokensで上限を設け(本例の通り)、エージェントループは検証してください。 -
API経由では公開画像URLをサポートしていないため、ビジョン機能ではbase64またはアップロードファイルを想定してください。
どれも致命的ではありませんが、モデルの使い方に影響します。特に出力コストには注意を払いたいところです。
まとめ
試した範囲で際立ったのは2点です。ツールコールと構造化出力はリトライ不要で動作し、キャッシュは想像以上に効きました。同じ長いプレフィックスを再利用することで、大きなリクエストを安価に再送できたからです。したがって、リポジトリ規模の分析、長文コンテキストの反復呼び出し、あるいはマルチモーダルなエンジニアリングではK3が無難なデフォルトになりえます。一方、低コストの素早いチャットやサンプリング制御の精密さが必要なら、小型モデルの方が扱いやすいでしょう。前述のオープンウエイトやライセンスの詳細は、7月27日のリリース後に明確になるはずです。
これらの例が用いるパターンの背景については、Developing AI Systems with the OpenAI APIのコースで、Pythonによる関数呼び出しと外部ツール連携を解説しています。