Kimi APIがCodexとClaude Codeにネイティブ対応

Moonshot AIは9月2日、Kimi APIがOpenAIのResponses API形式とAnthropicのMessages API形式への正式対応を開始したと発表した。CodexおよびClaude Codeの利用者は、形式変換やローカルプロキシを介さずに、カスタムモデルプロバイダ経由でKimiのモデル群へ直接接続できるようになる。コーディングエージェントの選択肢を広げる相互運用の動きとして注目される。

钛媒体 の 钛媒体官方账号 の報道では、今回の対応の狙いについて次のように伝えている。

Kimi APIがOpenAIのResponses API形式に正式対応したほか、AnthropicのMessages API形式にも対応した。CodexまたはClaude Codeのユーザーは、形式変換やローカルプロキシを経由することなく、カスタムmodel providerを通じて直接接続できる

対象モデルにはkimi-k3、kimi-k2.7-code-highspeed、kimi-k2.7-code、kimi-k2.6などが含まれる。開発者は既存のエージェント設定を変更するだけで、Kimi系モデルを呼び出せる。

発表の概要と対象モデル

今回の発表は、CodexやClaude CodeでKimi APIを利用したいという開発者からの要望に応えたものだ。Moonshot AIは9月2日、2つの主要なAPI仕様への互換対応を同時に公開した。

一つがOpenAIのResponses API形式への対応である。もう一つがAnthropicのMessages API形式への対応である。いずれもエージェント型コーディングツールで広く採用されているインターフェースだ。

接続可能なモデルとして、kimi-k3、kimi-k2.7-code-highspeed、kimi-k2.7-code、kimi-k2.6が挙げられている。フラグシップからコード生成に特化した高速モデルまで、用途に応じた選択が可能だ。

従来は、異なるプロバイダのモデルをCodexやClaude Codeで利用する場合、リクエスト形式の変換層やローカルでのプロキシサーバを自前で用意する必要があった。今回のネイティブ対応により、その迂回処理が不要になる。

Moonshot AIの対応は、モデルプロバイダ側がエージェント側のインターフェースに歩み寄る形だ。開発者にとっては導入障壁の低下につながる。

技術的互換の詳細

Responses APIは、OpenAIがCodexを含むエージェント製品で採用する入出力形式だ。ツール呼び出しや逐次的な推論過程を構造化して扱う設計が特徴である。

Messages APIは、AnthropicがClaude Codeで用いる会話形式のAPIだ。システムプロンプト、ユーザーメッセージ、ツール実行結果を明確に分離して管理する。

Kimi APIが両形式をネイティブに解釈することで、クライアント側はエンドポイントと認証情報を差し替えるだけで利用できる。カスタムモデルプロバイダの指定欄にKimi APIの情報を入力する運用が想定されている。

形式変換を挟まないことは、レイテンシの削減やエラーの抑制にも寄与する。変換層で発生しがちなパラメータの欠落や型不一致を回避できる。

また、ローカルプロキシを常駐させる必要がなくなるため、開発環境の複雑さが軽減される。CI環境やコンテナ内での実行時にも設定が簡素化される利点がある。

コード生成に特化したkimi-k2.7-code-highspeedのようなモデルは、エージェントの反復的な編集・実行ループとの相性が問われる。ネイティブ対応は、そうした高速な試行錯誤を前提としたワークフローでの採用を後押しする。

開発者体験への影響

CodexとClaude Codeは、いずれもローカル環境で動作し、ファイル編集やコマンド実行を自律的に行うコーディングエージェントだ。ターミナルやエディタと密接に連携し、複数ステップにわたる開発タスクを処理する。

これらのエージェントで利用できるモデルが増えることは、開発者にとって選択肢の拡大を意味する。特定の言語やフレームワークへの適性、応答速度、コストなどを比較してモデルを選べるようになる。

特に、Kimiシリーズは中国語と英語の両方での長文脈処理やコード生成で評価されてきた経緯がある。国内の開発環境やドキュメントを扱う場面での活用が期待される。

カスタムプロバイダ経由の直接接続は、既存のワークフローを維持したままモデルを差し替える運用を可能にする。プロンプトやツール定義を再構築する必要がない。

一方で、モデルを切り替える際には、出力の安定性やツール呼び出しの精度を検証する必要がある。エージェントの挙動は基盤モデルに大きく依存するため、移行時の評価は欠かせない。

今回の対応は、エージェント側のエコシステムがモデルプロバイダ間の競争を促進する構図を示している。インターフェースの共通化が、モデルの差別化をより直接的に問う環境を作り出している。

同時公開された周辺動向

同じ9月2日には、国内でエージェント関連の発表が相次いだ。TencentのWorkBuddyは開放プラットフォームopen.WorkBuddy.cnを正式にローンチし、100社超のエコシステムパートナーとともにスマートハードウェアや業界向けアプリケーションへAgent機能を開放した。Plaud、Rokid、Insta360、iFlytek、Anker、マムート、JD.com京造などが初期パートナーに名を連ね、金融や法律、医療、教育など20以上の分野で30以上のアプリケーションが接続している。

Doubaoワークも同日、複数Agentsの並列実行とMacでのコンピュータ操作に対応する新機能を発表した。統括するメインAgentがタスクを分解し、専門化したサブAgentに分配する並列処理と、MCPやAPI、プラグイン、CLIが存在しない環境でも画面理解を通じてGUI操作を実行する機能である。

これらの動きは、エージェントを単一のチャットインターフェースから、ハードウェアやOS操作を含む実行環境へ拡張する流れを示している。Kimi APIの相互運用対応も、エージェントが多様なモデルを前提に動作する基盤整備の一環と位置付けられる。

海外では、CrowdStrikeがOpenAIとの協業を拡大し、エンタープライズ向けセキュリティ保護機能をCodexエージェントへ拡張するとともに、GPT-5.6 CyberをFalconプラットフォームに導入すると発表した。コーディングエージェントの企業導入において、セキュリティ統合が不可欠な要素になっていることを示す事例だ。

相互運用が進む背景

大規模言語モデルのAPIは、当初は各社が独自仕様を提示していた。しかし、エージェントや開発ツールの普及に伴い、OpenAI互換やAnthropic互換のインターフェースが事実上の標準として機能し始めている。

モデルプロバイダにとって、主要なエージェントが採用するAPI形式への対応は、導入拡大の近道になる。開発者は既存のツールチェーンを維持したまま、新たなモデルを試せるからだ。

Moonshot AIの今回の対応も、その流れに沿ったものだ。Responses APIとMessages APIという二大形式の双方に対応することで、Codex派とClaude Code派のいずれの開発者にも門戸を開く。

この相互運用の進展は、モデルの性能競争をより透明にする。同一のエージェント、同一のタスクで異なるモデルを比較できるため、ベンチマークの再現性が高まる。

同時に、APIの互換層を誰が維持するかという責任分担も明確になる。従来はコミュニティによる非公式な変換アダプタに依存する場面が多かったが、公式対応により保守性と信頼性が向上する。

今後は、他のモデルプロバイダでも同様のネイティブ対応が広がる可能性がある。エージェント側のインターフェースが安定すれば、モデル側の対応は差別化ではなく前提条件になると見られる。

今後の展望と留意点

Kimi APIのネイティブ対応は、コーディングエージェントの利用を検討する開発者にとって、導入時の技術的摩擦を下げる効果を持つ。特に、既にCodexやClaude Codeを運用しているチームでは、追加のインフラを用意せずに評価を開始できる。

ただし、API形式の互換と、実際のエージェント性能の互換は別問題である。ツール呼び出しの成功率や長文脈での指示追従性などは、モデル固有の特性に左右される。公式対応後も、個別のタスクでの検証は必要だ。

また、エージェントの実行にはモデルの推論コストに加え、ツール実行や反復ループに伴うトークン消費が伴う。コスト管理やレート制限の設計は、運用段階での重要な検討事項になる。

セキュリティ面では、エージェントがローカルファイルやコマンド実行へアクセスする特性上、モデルプロバイダへのデータ送信範囲を把握しておく必要がある。企業環境では、データ保持ポリシーやログの取り扱いを確認することが求められる。

Moonshot AIが提示したモデルラインアップは、汎用モデルとコード特化型、高速版を使い分ける構成だ。エージェントの用途に応じてモデルを選択する運用が、今後の標準になると考えられる。

編集部の見解

短期的には、CodexやClaude Codeを既に導入している開発チームでのKimiモデルの試用が加速すると見る。形式変換やプロキシが不要になることで、評価コストが大幅に下がるからだ。3〜6ヶ月の間に、コード補完やリファクタリング、テスト生成といった定型タスクでの比較検証が活発化する可能性がある。コミュニティによる非公式アダプタの役割は縮小し、公式互換を前提としたベンチマーク共有が進むと評価する。 長期的には、API形式の相互運用がモデル選択の流動性を高め、エージェントとモデルの分離を促進すると見る。1〜3年のスパンでは、特定のエージェントに特定のモデルが紐付く垂直統合よりも、エージェントはインターフェースを、モデルは性能とコストで競争する水平分業が強まる可能性がある。開発者にとっては選択肢が増える一方で、モデルごとの挙動差異を吸収する評価手法やガバナンスの整備が新たな課題になると考えられる。 残る問いは、互換対応がどこまで完全かという点だ。Responses APIやMessages APIのどのバージョン、どのパラメータまでを忠実に再現しているのか。

参考

• 「【钛晨报】央行行长潘功胜出席G20财长和央行行长会议，强调继续实施好适度宽松的货币政策；CrowdStrike与OpenAI扩大合作；港股通买入Minimax规模超越阿里巴巴和腾讯」, by 钛媒体官方账号 — 钛媒体, 2026-09-02T23:20:00.000Z (ARR)
• 元記事URL: https://www.tmtpost.com/8126299.html