Kimi K3をエージェント開発で使うには、OpenAI互換のエンドポイントhttps://api.moonshot.ai/v1にモデルIDkimi-k3を指定するだけで始められます。既存のOpenAI SDKベースのエージェントコードは、base_urlとAPIキーの差し替えでほぼそのまま動きます。押さえるべきポイントは次の4つです。
- OpenAI互換API：Chat Completions形式・ツールコール・ストリーミング・マルチモーダル入力に対応
- 100万トークンコンテキスト：1,048,576トークン。リポジトリ全体や長時間のエージェントセッションを1コンテキストで保持
- コスト：入力$3/100万トークン（キャッシュヒット時$0.30）、出力$15/100万トークン
- 重みオープン化：2026年7月27日までにフルウェイト公開予定。将来的なセルフホスト移行パスがある
「2.8兆パラメータのオープンモデルが出たらしいけど、実際エージェントに組み込めるの？」
2026年7月16日（米国時間）にMoonshot AIが発表したKimi K3は、発表直後からエンジニア界隈で大きな話題になりました。検証環境で実際にAPIを叩いてみると、既存のOpenAI SDKベースのエージェントループがbase_urlの変更だけで動作し、移行コストの低さに驚かされます。一方で、100万トークンという巨大なコンテキストと$15/100万トークンという出力単価は、エージェント設計の考え方そのものを変える要素でもあります。
この記事では、Kimi K3 APIをエージェントワークフローに組み込む具体的な実装を、セットアップからツールコールループ、コスト設計、セルフホスト展望まで、コピペ可能なコード付きで解説します。
Kimi K3とは：2.8兆パラメータMoEの何が新しいのか
Kimi K3は、Moonshot AI（月之暗面）が発表した2.8兆パラメータのMixture-of-Experts（MoE、専門家混合）モデルです。896個のエキスパートのうちトークンごとに16個だけを活性化するスパース構成で、総パラメータの約1.8%だけを使って推論します。
アーキテクチャ面の目玉は2つあります。1つはKimi Delta Attention（KDA）で、Moonshot AIは100万トークンコンテキストにおいて最大6.3倍高速なデコードを実現すると説明しています。もう1つはAttention Residuals（AttnRes）で、モデルの深さ方向の情報伝達を改善する仕組みです。長いエージェントセッションで序盤の判断を忘れにくい、という実用上の効きどころに直結する設計です。
| 項目 | 内容 |
|---|---|
| 総パラメータ | 約2.8兆（MoE） |
| アクティブエキスパート | 896個中16個／トークン（約1.8%） |
| コンテキストウィンドウ | 1,048,576トークン（100万トークン） |
| マルチモーダル | ネイティブビジョン対応（画像・動画入力） |
| API形式 | OpenAI互換 Chat Completions |
| モデルID | kimi-k3 |
| 重み公開 | 2026年7月27日までに公開予定（K2系はModified MITライセンスの実績） |
性能面では、総合力ではClaude Fable 5やGPT 5.6といった最上位プロプライエタリモデルにまだ及ばないと報じられていますが、ArenaのFrontend Code評価では1,679ポイントで1位を獲得したことがTom’s Hardwareなどで報じられています（参照日: 2026-07-20）。「フロントエンドコード生成に限れば最上位クラス、総合ではやや下」という位置づけを理解した上で、タスクに応じて使い分けるのが現実的です。
5分で動かす：OpenAI互換APIのセットアップ
まず最小構成で動かしてみましょう。Moonshot AIのAPIはOpenAI SDKと互換なので、追加のSDKは不要です。
動作環境: Python 3.11+, openai>=1.30.0
APIキーはKimi Open Platformで発行し、環境変数に設定します。コードへのハードコードは避けてください。
pip install openai
export MOONSHOT_API_KEY="sk-..." # 発行したAPIキー
次のコードは、Kimi K3に最初のリクエストを送る最小サンプルです。
import os
from openai import OpenAI
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1", # OpenAI互換エンドポイント
)
response = client.chat.completions.create(
model="kimi-k3",
messages=[
{"role": "system", "content": "あなたはコードレビューを行うアシスタントです。"},
{"role": "user", "content": "PythonでリトライつきHTTPクライアントの実装方針を3行で。"},
],
temperature=0.3,
)
print(response.choices[0].message.content)
ポイント：
- 変更点は
base_urlとmodelの2箇所だけ。LangChainやOpenAI Agents SDKなどOpenAI互換レイヤーを持つフレームワークからも同じ要領で接続できます - ストリーミングは
stream=TrueでSSE（Server-Sent Events）形式に対応 - マルチモーダル入力は
content配列内のimage_url／video_urlタイプで渡せます
エージェント実装：ツールコールループを組む
エージェント開発の中核はツールコール（Function Calling）のループです。Kimi K3はOpenAI形式のtoolsパラメータ（JSON Schema定義）をサポートしているため、既存のエージェントループがそのまま流用できます。
次のコードは、ファイル検索ツールを持つ最小のエージェントループです。
import os
import json
import subprocess
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_files",
"description": "リポジトリ内をキーワード検索し、該当ファイルと行を返す",
"parameters": {
"type": "object",
"properties": {
"keyword": {"type": "string", "description": "検索キーワード"}
},
"required": ["keyword"],
},
},
}]
def search_files(keyword: str) -> str:
# 実運用ではサンドボックス内で実行し、パス・引数を必ず検証すること
result = subprocess.run(
["grep", "-rn", "--include=*.py", keyword, "./src"],
capture_output=True, text=True, timeout=30,
)
return result.stdout[:8000] or "該当なし"
def run_agent(user_task: str, max_turns: int = 10) -> str:
messages = [
{"role": "system", "content": "あなたはコードベースを調査するエージェントです。"},
{"role": "user", "content": user_task},
]
for _ in range(max_turns): # 無限ループ防止のターン上限
resp = client.chat.completions.create(
model="kimi-k3",
messages=messages,
tools=TOOLS,
temperature=0.2,
)
msg = resp.choices[0].message
if not msg.tool_calls:
return msg.content # ツール要求がなければ最終回答
messages.append(msg)
for tc in msg.tool_calls:
args = json.loads(tc.function.arguments)
output = search_files(**args)
messages.append({
"role": "tool",
"tool_call_id": tc.id,
"content": output,
})
return "ターン上限に到達しました"
print(run_agent("認証処理を実装しているファイルを特定して概要をまとめて"))
ポイント：
max_turnsで必ずループ上限を設ける。長コンテキストモデルは「まだ続けられてしまう」ため、上限なしだとコストが青天井になります- ツール実行結果は無制限に返さず、この例のように文字数を切り詰める。100万トークン入るからといって全部入れると、キャッシュミス分の入力課金が膨らみます
- ツールの実行はサンドボックス化し、モデルが生成した引数をそのままシェルに渡さない設計にする（プロンプトインジェクション対策）
100万トークンコンテキストの活かし方と落とし穴
Kimi K3の1,048,576トークンというコンテキストは、エージェント設計の前提を変えます。検証してみて効果的だったのは次の使い方です。
リポジトリ全体を1コンテキストに載せる
中規模リポジトリ（数十万トークン程度）なら、RAGで分割検索する代わりにコード全体をシステムプロンプト側へ載せ、その後の質問をすべてキャッシュヒットで処理する構成が組めます。横断的なリファクタリング調査のように「どこに何があるか全体を見ないと答えられない」タスクで特に有効です。
長時間エージェントセッションの履歴を圧縮しない
従来の128K〜200Kクラスのモデルでは、数十ターンを超えるエージェントセッションで履歴の要約・圧縮が必須でした。100万トークンあれば数百回のツールコール履歴を生のまま保持でき、「序盤に決めた方針をエージェントが忘れる」問題を構造的に減らせます。
落とし穴：入れられる＝入れるべき、ではない
正直にお伝えすると、100万トークンは万能ではありません。
- コンテキストが長くなるほどレイテンシは伸びる（KDAで緩和されるとはいえゼロにはならない）
- キャッシュが効かない動的な長文入力は、1リクエストあたりのコストが跳ね上がる
- 関係ない情報を大量に入れると、かえって回答精度が下がるケースは長コンテキストモデル共通の課題
「静的な大きい塊はキャッシュ前提で先頭に、動的な情報は末尾に最小限」が基本方針です。
コスト設計：キャッシュ$0.30をどう効かせるか
Kimi K3のAPI料金は次の通りです（Kimi Open Platform公式ドキュメント、参照日: 2026-07-20）。
| 区分 | 料金（100万トークンあたり） |
|---|---|
| 入力（キャッシュヒット） | $0.30 |
| 入力（キャッシュミス） | $3.00 |
| 出力 | $15.00 |
注目すべきはキャッシュヒット時の入力単価がキャッシュミスの10分の1という点です。エージェントは「同じ長いコンテキスト＋少しずつ増える履歴」を毎ターン送り直すワークロードなので、キャッシュ効率がそのままコストを決めます。
試算してみましょう。20万トークンのリポジトリコンテキストを載せて50ターンのエージェントセッションを回す場合：
- 初回ターン（キャッシュミス）: 0.2M × $3.00 = 約$0.60
- 2ターン目以降（キャッシュヒット）: 0.2M × $0.30 = 約$0.06／ターン × 49ターン = 約$2.94
- 出力が各ターン2,000トークンなら: 0.1M × $15.00 = 約$1.50
- 合計: 約$5.04（全ターンがキャッシュミスだと入力だけで$30.00になる計算）
キャッシュを効かせる実装の基本は「プレフィックスを固定する」ことです。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# キャッシュが効く構成: 固定部分を先頭に、可変部分を末尾に置く
STATIC_CONTEXT = load_repo_snapshot() # 固定: リポジトリのスナップショット
def build_messages(history: list, new_input: str) -> list:
return [
# 1. システムプロンプト + 大きな固定コンテキスト（毎回同一 = キャッシュヒット）
{"role": "system", "content": SYSTEM_PROMPT + "nn" + STATIC_CONTEXT},
# 2. 会話履歴は追記のみ。過去分を書き換えるとプレフィックスが変わりキャッシュが無効化される
*history,
# 3. 新しい入力は必ず末尾
{"role": "user", "content": new_input},
]
ポイント：
- タイムスタンプや乱数をシステムプロンプトに埋め込まない（毎回内容が変わりキャッシュミスになる典型パターン）
- 履歴の途中要約・編集はプレフィックスを破壊するので、やるなら「どこまでをキャッシュ対象にするか」の境界を意識して設計する
- 複数モデルを併用する場合は、OpenRouterのようなLLMゲートウェイ経由でKimi K3を呼ぶ選択肢もあります。ルーティングと料金管理を一元化できる一方、プロバイダ固有のキャッシュ挙動は変わり得るため、コスト検証は自環境で行ってください
7月27日の重みオープン化とセルフホスト展望
Moonshot AIはKimi K3のフルウェイトを2026年7月27日までに公開する予定と報じられています。K2ファミリーがModified MITライセンスで公開されてきた経緯を踏まえると、K3も同系統のオープンウェイト路線が濃厚です。
ただし現実的な話をすると、2.8兆パラメータ（アクティブは一部とはいえ）のモデルを自前でサービングするのは相当なGPUリソースを要求します。セルフホストを検討する場合の現実的なシナリオは次の3段階です。
| 段階 | 構成 | 向いているケース |
|---|---|---|
| 1. API利用 | api.moonshot.ai/v1 を直接利用 | まず試す・トラフィックが読めない段階 |
| 2. ホスティング事業者経由 | OpenRouter等の推論プロバイダー経由でオープンウェイト版を利用 | ベンダー分散・フォールバック構成を組みたい |
| 3. 自社サービング | vLLM等でのマルチノードGPUクラスタ運用 | データを外に出せない・大規模トラフィックで単価を下げたい |
段階3を見据えるなら、vLLMによるセルフホストLLM推論の本番運用ガイドが参考になります。また、中国系オープンモデルのセルフホスト比較はGLM-5.2のセルフホスト・コーディングエージェント比較でも扱っています。
もう1つ重要なのは、オープンウェイト化は「ロックイン回避の保険」として機能する点です。API版で本番運用しつつ、価格改定や提供終了リスクに備えてセルフホストへの移行パスを確保できるのは、プロプライエタリモデルにはない利点です。モデル切り替えを前提とした設計はモデル非依存エージェントのフォールバック設計で詳しく解説しています。
【要注意】よくある失敗パターンと回避策
失敗1：100万トークンに甘えてコンテキストを整理しない
❌ ツール実行結果もログも全部そのまま履歴に積む
⭕ ツール結果は上限文字数で切り詰め、静的コンテキストと動的履歴を分離する
なぜこれが重要か：入るからといって全部入れると、キャッシュミス時の入力課金と応答レイテンシが膨らみます。長コンテキストは「圧縮しなくてよい自由」であって「整理しなくてよい免罪符」ではありません。
失敗2：キャッシュを破壊するプロンプト構造
❌ システムプロンプトに現在時刻を埋め込む、履歴の途中を毎ターン書き換える
⭕ 固定部分を先頭に置き、可変情報は末尾のユーザーメッセージに寄せる
なぜこれが重要か：入力単価が$3.00と$0.30で10倍違うため、キャッシュ効率の差がそのまま月額コストの差になります。上の試算例では、キャッシュが全滅すると同じセッションが約6倍のコストになりました。
失敗3：ベンチマーク1位の領域だけ見てモデル選定する
❌ 「Frontend Codeで1位だから全部Kimi K3に寄せる」
⭕ タスク別に評価セットを作り、自分のワークロードで比較してから本番に載せる
なぜこれが重要か：総合性能では最上位プロプライエタリモデルに及ばないと報じられている以上、得意領域（フロントエンドコード、長コンテキスト保持）とそれ以外を切り分けたルーティングが現実解です。エージェントの評価基盤を先に作っておくと、この判断が数字でできるようになります。
よくある質問
Kimi K3のAPIはOpenAI SDKからそのまま使えますか？
使えます。base_urlをhttps://api.moonshot.ai/v1に、モデルIDをkimi-k3に変更するだけで、Chat Completions・ツールコール・ストリーミング・画像入力が動作します。
Kimi K3の料金はいくらですか？
100万トークンあたり入力$3.00（コンテキストキャッシュヒット時は$0.30）、出力$15.00です（2026年7月20日時点の公式ドキュメント記載）。為替や税は別途かかります。
セルフホストはいつからできますか？
フルウェイトは2026年7月27日までに公開予定と報じられています。ただし2.8兆パラメータ級のサービングには大規模なGPUクラスタが必要なため、まずはAPIか推論プロバイダー経由での利用が現実的です。
参考・出典
- Kimi Open Platform – Chat Pricing（kimi-k3: 入力$3.00／キャッシュ$0.30／出力$15.00） — Moonshot AI公式（参照日: 2026-07-20）
- Kimi Open Platform – Chat API Reference（base_url・ツールコール・マルチモーダル仕様） — Moonshot AI公式（参照日: 2026-07-20）
- Moonshot Unveils Kimi K3 AI Model, Narrowing Gap With US Rivals — Bloomberg（参照日: 2026-07-20）
- China’s 2.8-trillion-parameter Kimi K3 beats Claude Fable 5 in Frontend Code Arena benchmark — Tom’s Hardware（参照日: 2026-07-20）
- Kimi K3, and what we can still learn from the pelican benchmark — Simon Willison（参照日: 2026-07-20）
まとめ：今日から始める3つのアクション
- 今日やること：Kimi Open PlatformでAPIキーを発行し、本記事の最小サンプルで
kimi-k3への接続を確認する - 今週中：既存エージェントのbase_urlを差し替えてツールコールループを検証し、キャッシュヒット率とコストを実測する
- 今月中：7月27日の重み公開を確認した上で、API継続かセルフホスト移行かの判断材料（トラフィック・データ要件・GPUコスト）を整理する
あわせて読みたい：
- OpenRouterでLLMゲートウェイを構築｜マルチモデル運用とコスト最適化 — 複数モデルのルーティング・フォールバック構成の実装
- vLLMセルフホストLLM推論の本番運用ガイド — 重み公開後のセルフホストを見据えた推論基盤の作り方
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
