Moonshot、KimiをCodexとClaude Codeに開放し、AnthropicとMoonshotの対立を再構成

Moonshot AIは9月2日、モデルのトレーニングとアクセスを巡るAnthropicとMoonshotの対立が未解決のまま、Kimiを2つの競合コーディング環境に開放した。Kimi APIは現在、CodexからのOpenAI Responses APIリクエストと、Claude CodeからのAnthropic Messages APIリクエストを受け付ける。Moonshotによると、開発者はフォーマット変換器やローカルプロキシなしで接続できる。

この変更は互換性アップデートのように聞こえる。しかし、コーディングエージェントが依存するのは通常のテキスト補完だけでなく、詳細なプロトコル動作であるため、影響はより大きい。クライアントはツール定義を送信し、構造化された呼び出しを受け取り、実行結果を返し、タスクが終了するまでそのサイクルを繰り返す。

したがってMoonshotは、コーディングインターフェースをそれを作った企業から切り離そうとしている。Codexは開発者のクライアントとしてそのまま使いながら、OpenAIモデルをKimiモデルに置き換えられる。Claude Codeも使い慣れたワークフローを維持したまま、リクエストをAnthropicではなくMoonshotへ送信できる。

この戦略はOpenAIとAnthropicに別種の圧力をかける。どちらの企業もクライアントやプロトコルの所有権を失うわけではない。しかし両社は、自らが確立に寄与したワークフロー内で、互換性を武器に競争する別プロバイダーに直面することになる。

Kimi APIのCodexサポートが実務上の障壁を取り除く

Moonshotの重要な変更は、新たなコーディングインターフェースではなく、ネイティブなプロトコルサポートだ。

Moonshotの9月2日の発表によると、KimiはCodexで使用されるResponses API形式をサポートする。また、AnthropicおよびClaude Codeに関連するMessages APIもサポートする。同社はそれぞれの経路について個別の設定ガイドを公開した。

Codex向けに、Moonshotは自社のAPIベースURLとResponsesのワイヤーフォーマットを使うカスタムプロバイダーを案内している。カスタムプロバイダーは、モデルリクエストの送信先と使用するプロトコルをクライアントに指定する。その後、開発者はCodex内で作業を続けながらKimiモデルを選択できる。

Moonshotは、kimi-k3、kimi-k2.7-code-highspeed、kimi-k2.7-code、kimi-k2.6を互換性のある選択肢として挙げている。ただし利用可否は、アカウント、エンドポイント、クライアントのバージョン、現在のプラットフォーム設定に左右される場合がある。

Codex設定が注目されるのは、従来の統合でしばしば必要だった変換レイヤーを取り除くためだ。ローカルアダプターは、あるリクエスト形式を受け取り、それを別のAPI用に書き換え、ストリーミングレスポンスを再び変換することになる。

アダプターはすべて、新たな可動部分となる。ツール呼び出しを誤処理したり、イベントタイプを省いたり、認証情報を露出させたり、アップデート後にクライアントとの整合性を失ったりする可能性がある。また、障害の原因がクライアント、アダプター、ネットワーク、上流モデルのどこにあるのかを特定しにくくする。

ネイティブなResponsesサポートは、その統合面を縮小する。OpenAIがホストするモデルと同一の動作を保証するものではない。これは、Moonshotのサーバーがクライアントの期待するワイヤー契約を受け入れることを意味する。

この違いは重要だ。Codexは単にプロンプトを送り、回答を表示するだけではない。CodexエージェントループについてのOpenAIの説明では、モデル推論とツール実行の間で繰り返されるやり取りが記述されている。クライアントは、そのやり取りを通じてメッセージ、指示、ツール定義、推論関連の項目、ツール結果を運ぶ。

互換性のあるサーバーは、そのループを継続できるよう、十分な構造を保持しなければならない。テキスト生成だけでは不十分である。ストリーミングイベント、ツール呼び出し識別子、入力項目、終了時の動作はいずれも、クライアントが信頼性高く機能するかを左右する。

したがってKimi APIのCodex経路は、すでにCodexインターフェースを気に入っているが、別のモデルバックエンドを求める開発者を対象としている。また、ターミナルのワークフローを置き換えたり、周辺スクリプトを作り直したりせずに、モデルを比較する手段もチームに提供する。

カスタムプロバイダーが利用できる場合、同じロジックはデスクトップ体験にも当てはまる。Moonshotのドキュメントによれば、設定済みのバックエンドがKimiであっても、モデルセレクターには一般的なカスタムラベルが表示される場合がある。このインターフェース上の制約は、検証の重要性を高める。

開発者は、設定、リクエストログ、統制されたテストを通じて、実際に有効なプロバイダーを確認すべきだ。回答が正常に返っただけでは、どのバックエンドがリクエストを処理したかは確定しない。

Moonshotはさらに、Responses実装がテキストと画像の入力を受け付ける一方、現時点では動画入力をサポートしていないとも説明している。この制約は、ネイティブサポートの意味を限定する。プロトコル互換性は、考え得るあらゆる入力やプラットフォーム機能を網羅せずとも、コーディング作業には十分広範であり得る。

当面の利点はなお明確だ。開発者は、文書化された経路のためにローカルのプロトコルブリッジを維持する必要がなくなる。これによりセットアップ作業が減り、Moonshotは確立されたエージェントワークフローへより直接的に進出できる。

KimiのClaude Codeサポートがクライアントを配布チャネルに変える

Claude Codeの設定可能なAPI経路により、Moonshotは同じく馴染み深いクライアントを構築せずに推論処理で競争できる。

KimiのClaude Code設定は、MoonshotのAnthropic互換エンドポイントを使用する。Claude CodeがMessages APIリクエストを送信し、選択されたKimiモデルが推論を生成する。クライアントは引き続き、ファイル、ツール、権限、対話型ワークフローを管理する。

MoonshotのClaude Codeガイドは、必要なエンドポイントと認証情報を説明している。これにより、リクエスト形式の変換だけを目的としたローカルリレーをインストールする従来のパターンに代わる。

AnthropicのMessages APIは、会話、コンテンツブロック、ツール利用のための構造化インターフェースだ。その形式をサポートすることで、別のプロバイダーはその契約を前提に設計されたソフトウェアからリクエストを受け取れるようになる。これはKimiモデルをClaudeに変えるものでも、Anthropicのモデル動作を移転するものでもない。

この区別は明確にしておくべきだ。Claude Codeはエージェントクライアントである。ClaudeはAnthropicのモデルファミリーだ。ユーザーは互換性のある外部エンドポイントに対してクライアントを実行できるが、得られる出力は設定されたプロバイダーから生じる。

Anthropic自身のゲートウェイに関するドキュメントは、サポートされるAPI形式によってClaude Codeをゲートウェイに接続できることを認めている。同時に、Anthropicは第三者製ゲートウェイ製品を推奨、保守、監査していないとも述べる。さらに直接的には、ゲートウェイを介してClaude CodeをClaude以外のモデルへルーティングすることはサポートしないとしている。

Moonshotは、AnthropicがKimiをサポートしていると主張しているわけではない。クライアントが期待するリクエスト形式を実装しているのだ。この違いは、技術的相互運用性と商業提携を分ける。

この設定は、開発者に実用的なユースケースを提供する。チームは1つのコーディングクライアントを維持し、テスト環境をKimiに向け、同じリポジトリタスクを別のバックエンドで実行できる。馴染みのある操作を使って、パッチの品質、ツールの信頼性、レイテンシ、障害回復を比較できる。

このワークフローは、切り替えコストも下げる。従来、別モデルの評価には専用クライアントの採用やプロキシの維持が必要になる場合があった。ネイティブ互換性は、この判断を設定変更に近いものにする。

これはモデルプロバイダーに圧力を生む。ユーザーのロイヤルティは、基盤となるモデルではなくエージェントシェルに結び付く可能性があるためだ。開発者は、コードレビュー、リポジトリ探索、画像支援デバッグ、長時間に及ぶ編集で異なるモデルを選びながら、単一のインターフェースを好むかもしれない。

結果として、プロトコルは配布チャネルになる。クライアントがカスタムエンドポイントを受け入れると、十分に互換性のあるすべてのプロバイダーが、そのユーザーへアクセスを求められるようになる。元のベンダーは依然としてクライアントの進化を制御するが、すべての推論リクエストを制御するわけではなくなる。

限界もある。Claude Codeは時間とともに機能を追加しており、外部実装はそれらの機能が必要とするリクエストおよびレスポンスのフィールドに追随しなければならない。Anthropicは、ゲートウェイが新しい動作を転送できなければ機能が損なわれる可能性があると警告している。

直接接続の第三者エンドポイントも、同じ互換性の負担を負う。Claude Codeが別のツールスキーマ、ヘッダー、コンテンツブロック、ストリーミングイベントを導入すれば、Moonshotはそれを正しく実装しなければならない。「ネイティブ」は現在の統合経路を表すものであり、永続的な機能同等性を意味するものではない。

認証も信頼境界を変える。Moonshotに送信されるリクエストは、Moonshotのサービス、データ処理、保持ルール、地域別の提供状況に従う。画面上にClaude Codeが残っているからといって、Anthropicアカウントの下で処理されるわけではない。

チームはプロバイダー選択をインフラストラクチャ上の判断として扱うべきだ。ソースコード、プロンプト、ツール出力、リポジトリのコンテキストは、設定されたエンドポイントを通過する可能性がある。セキュリティレビューは、その情報を受け取るバックエンドに従って行う必要がある。

したがってKimiのClaude Code経路は、通常のプラグインよりも単純でありながら、より大きな意味を持つ。Moonshotは競合他社と結び付いたワークフローに入り込みつつ、その下層のモデルサービスに責任を負うことになる。

AnthropicとMoonshotの対立は互換性ではなく制御を巡るものだ

中心的な緊張関係は、技術的な開放性が商業上の不信と共存し得ることにある。

主要キーワードであるanthropic moonshotは、協力関係ではなく敵対的な関係を指している。MoonshotのMessages互換性を、Anthropicとの合意と誤解すべきではない。

2026年2月23日、AnthropicはMoonshot、DeepSeek、MiniMaxが、同社の言う産業規模の蒸留キャンペーンを行ったと公に非難した。蒸留とは、別のモデルが生成した出力を使ってモデルを訓練する手法だが、アクセスと許可が認められている場合には正当な方法になり得る。

Anthropicは、3社が合計で約24,000の不正アカウントを通じて1,600万件を超えるClaudeとのやり取りを生成したと主張した。Moonshotに起因するやり取りは340万件超とし、その活動はコーディング、ツール利用、推論、データ分析、コンピューター利用、ビジョンを標的にしていたと述べた。

これらは、本記事で確認した資料において独立に立証された事実ではなく、Anthropicの主張である。Moonshotが新たに発表したAPI互換性は、それらを裏付けるものでも解決するものでもない。Anthropicのメッセージ形式をサポートしていることだけから、Kimiのトレーニングに関する推論を導くべきではない。

それでも、この経緯は今回の発表の受け止め方を変える。Anthropicは、モデル出力とアクセス制限にはより厳格な保護が必要だと主張している。一方Moonshotは、Anthropicに関連付けられたインターフェースを競合モデルで使いやすくしている。

したがってAnthropicとMoonshotの対立は、2つの層で展開している。一つは、誰がどの条件でモデル機能にアクセスできるかという問題だ。もう一つは、クライアントプロトコルが広く実装されるインターフェースとして機能し得るかという問題である。

Anthropicの蒸留に関する主張は前者を強調している。Moonshotの互換性リリースは後者を強調している。両者は制御を争っているが、対象はテクノロジースタックの異なる部分だ。

プロトコルそのものには、モデルの完全な動作は含まれない。プロトコルは、リクエスト、コンテンツ、ツール、レスポンスがクライアントとサーバーの間をどのように移動するかを定義する。複数のプロバイダーが類似したインターフェースを実装しても、異なる結果を生み出し得る。

この分離は、他のコンピューティング市場でも馴染み深い。アプリケーションは、同じデータベースエンジンを使わずに共有のデータベースプロトコルで通信できる。クラウドサービスは、すべての運用上の詳細まで一致させずに、互換性のあるオブジェクトストレージインターフェースを公開できる。

AIエージェントは、モデルの振る舞いがクライアントループに影響するため、この分離をより難しくします。コーディングエージェントは、モデルがツールを選択し、結果を解釈し、有効な編集を行い、エラー後に復旧することを期待しています。正式なAPI互換性は必要ですが、体験が実用的なまま保たれるかを決めるのは行動面での互換性です。

開発者がCodexとClaude Codeを中立的なシェルと見なすなら、Moonshotにとって有利です。ユーザーがそれぞれのクライアントを、そのクライアント向けに特別に最適化されたモデルと結び付けるなら、OpenAIとAnthropicにとって有利です。競争上の問いは、どちらの見方が主流になるかです。

シェルが独立すれば、モデルルーティングは容易になります。企業はプロバイダーへのアクセスを交渉し、地域ごとに異なるポリシーを適用し、特定のワークロードにモデルを割り当てられます。開発者は推論プロバイダーを変えても、使い慣れた操作感を維持できます。

モデルとクライアントの深いチューニングが勝つなら、互換性のある競合製品は二次的な存在にとどまるかもしれません。ツール呼び出し、コンテキスト管理、キャッシュ、推論コントロール、エラー復旧における微妙な違いは、共有エンドポイントの利便性を上回り得ます。

だからこそ、9月2日の変更は単なるAPI対応項目の追加ではありません。コーディングエージェントの流通を、モデル所有権から切り離せるかを試すものです。

ネイティブ形式でもネイティブな性能は保証されない

接続が正常に開始しても、エージェント実行で負荷の高い局面では失敗する可能性があります。

Moonshotの発表は、文書化された経路を確立したものです。列挙されたKimiモデル全体で、CodexまたはClaude Codeのすべての機能が同一に動作するという独立した証拠を示しているわけではありません。

最初の不確実性は、プロトコルの網羅性です。ResponsesとMessagesは単一のテキストフィールドではありません。ストリーミング、マルチモーダルコンテンツ、ツールスキーマ、ツール結果、メタデータ、使用量レポート、エラー構造を含みます。

プロバイダーは主要なリクエストを受け付けても、エッジケースを異なる方法で処理する場合があります。並列ツール呼び出しが別の順序で届くこともあります。ストリームがクライアントの期待するイベントを省くこともあります。長時間のコマンド実行中に、キャンセルの挙動が異なることもあります。

2つ目の不確実性は、行動面での適合性です。コーディングクライアントは、モデルが専門的な指示に従い、ツールを慎重に操作することに依存しています。コーディングベンチマークで高得点のモデルでも、特定のクライアントのプロンプトやリポジトリワークフローでは苦戦する可能性があります。

したがって、有用な評価では接続の成功ではなく、タスクの完了を測るべきです。チームは、モデルが正しいファイルを編集するか、プロジェクトの指示を守るか、コマンド出力を解釈するか、承認が必要な場合に停止するかをテストする必要があります。

3つ目の不確実性は、クライアントの変化です。OpenAIとAnthropicは、新機能の登場に合わせてクライアントを変更できます。外部プロバイダーは、そのタイミングを制御できないまま、こうした変更に追随しなければなりません。

OpenAIによるCodexの説明は、エージェントループがどれほど詳細になっているかを示しています。ツール呼び出しの出力は後続のリクエストに追加され、会話コンテキストは繰り返しのターンをまたいで拡張されます。エンドポイントが/responsesのままであっても、これらのオブジェクトの変更は互換性に影響する可能性があります。

Anthropicも、ゲートウェイ運用者に対して同様の警告をしています。同社のドキュメントでは、ゲートウェイが新しいClaude Code機能を転送しなければ、それらの機能は失敗する可能性があるとされています。形式を直接実装するプロバイダーも、同様の保守リスクを負います。

4つ目の不確実性は、データガバナンスです。バックエンドを置き換えると、コードとコンテキストが移動する先も変わります。組織は、OpenAIまたはAnthropicのアカウントに紐付く管理策が、そのままMoonshotへのリクエストにも適用されるとは考えられません。

セキュリティレビューでは、認証情報の保存、保持、ログ、地理的な処理、インシデント対応、アクセス制御を確認すべきです。また、実際の本番タスクを送信する前に、エージェントが読み取れるリポジトリファイルを特定する必要があります。

5つ目の不確実性は、可観測性です。汎用的なモデルラベルでは、実際に使われているバックエンドが分かりにくくなる可能性があります。組織には、各リクエストをプロバイダー、モデル識別子、開発者、リポジトリ、ポリシーに結び付けるログが必要です。

ここで、社内のエンジニアリングナレッジベースが役立ちます。チームは、個人の記憶に頼ることなく、承認済み設定、評価結果、既知の非互換性、ロールバック手順を記録できます。

これらの懸念は、リリースの有効性を否定するものではありません。実務上、「ネイティブサポート」が何を意味すべきかを定義するものです。それは、プロバイダーが必要だった変換コンポーネントを取り除いたことを意味し、すべてのクライアント機能が恒久的な同等性を達成したことを意味するわけではありません。

責任ある試行は、代表的なリポジトリと限定的な権限から始めます。ファイル検索、複数ファイルの編集、テスト実行、コマンド失敗、画像入力、長いツールシーケンスを含むタスクを用意します。

チームは最終パッチだけでなく、それが作られた過程も比較すべきです。不必要なファイルアクセスや、失敗するコマンドの繰り返しを経て正しい結果に到達した場合でも、運用上のリスクを示します。

最良の証拠は、クライアント更新をまたぐ継続的な利用から得られます。Moonshotは導入を容易にしました。次は、最初のプロンプトが成功した後も互換性が信頼できる状態を保つことを示さなければなりません。

9月2日以降に開発者が注視すべきこと

このリリースがモデル競争を変えるのか、それとも便利な統合オプションにとどまるのかは、3つのシグナルで決まります。

最初のシグナルは、クライアント更新にまたがる機能同等性です。開発者は、CodexとClaude Codeの新機能がMoonshotのエンドポイント経由で速やかに動作するかを注視すべきです。

これには、新しいコンテンツタイプ、ツール定義、ストリーミングイベント、推論コントロール、認証挙動が含まれます。迅速な対応は、Moonshotが第一級のプロバイダーとして機能できるという主張を強めます。繰り返される不具合は、その主張を弱めます。

公開ドキュメントは早期の指標になります。明確な互換性マトリクス、バージョン要件、既知の制限、日付付きの更新は、包括的なサポート表明よりも重要です。

2つ目のシグナルは、検証済みのワークロード性能です。独立したテストでは、個別のコーディング質問ではなく、完全なリポジトリタスクを検証すべきです。有用な指標には、成功したパッチ、テスト合格率、不必要なツール呼び出し、レイテンシ、コマンドエラーからの復旧、人間による修正時間が含まれます。

重要な比較は、チャットウィンドウ内でのKimiとClaudeまたはOpenAIモデルの単純な比較ではありません。開発者が使用する予定の、まさにそのクライアントループ内でのKimiです。

異なるモデルは、異なるワークロードで優位に立つ可能性があります。高速なモデルは、リポジトリ検索や定型的な変換に適しています。より慎重なモデルは、アーキテクチャ変更や難しいデバッグでより良い性能を発揮するかもしれません。ネイティブ互換性はこうした比較を容易にしますが、その結果を決めるものではありません。

3つ目のシグナルは、OpenAIとAnthropicがプロバイダーのポータビリティにどう対応するかです。両社は、モデルとクライアントの最適化を深め、サポート対象プロバイダーのポリシーを厳格化し、エンタープライズ向けルーティングを改善し、公式クラウドの選択肢をより魅力的にできます。

Anthropicはすでに、同社が文書化するゲートウェイと、サポートしない非Claudeモデルとの間に境界線を引いています。未解決のanthropic moonshot論争は、その境界がより厳しくなるかを注視する理由をさらに加えます。

OpenAIは、CodexのResponsesエンドポイントが設定可能であると明示的に説明しています。このアーキテクチャ上の選択はポータビリティを支えますが、実装の詳細やサポートされる構成は変わる可能性があります。Moonshotのリリースは、開発者がこの柔軟性をどこまで活用するかを試しています。

個人開発者にとって、直近の行動は明快です。Kimiを、単なるアイデンティティ置換ではなく、評価すべき別のバックエンドとして扱ってください。使い捨てのブランチから始め、稼働中のモデルを確認し、認証情報を制限し、すべてのパッチを確認してください。

エンジニアリングリーダーにとって、より大きな問いは依存関係に関するものです。組織は単一の統合ベンダーを望むのか、それとも複数のプロバイダー間でルーティングできるクライアント層を望むのか。互換性は後者のアプローチをより実用的にしますが、テストとガバナンスの作業も顧客側に移します。

短い評価記録をパーソナルナレッジベースに残してください。クライアントのバージョン、選択したモデル、リポジトリの種類、タスク、観測された失敗、最終的な人間レビューを記録します。更新後に同じテストを繰り返せば、互換性が改善しているかどうかが分かります。

Moonshotは、Kimi、Codex、Claude Codeの間にあった目に見える障壁の一つを取り除きました。次に必要なのは、繰り返されるエージェント実行を通じて得られる信頼です。クライアントが変化し、タスクが長くなり、anthropic moonshotを巡る対立がアクセスと制御への疑問を意識させ続ける中で、ネイティブプロトコルのサポートは信頼性を維持できるのでしょうか？