📖 チュートリアル ⏱ 約22分で読めます

Kimi K2.6 Agent オープンソース公開×Clash：Moonshot API 分流と Kimi Code CLI 実測（2026）

2026年4〜5月ごろ、Moonshot AIのKimi K2.6がオープンソースの Agentic Codingモデルとして話題になり、GPT-5 系やCursor／Junie／Codex系の話題と並んで検索流入が増えています。日本語圏の開発者がよく踏むのは、(1) Kimiのブラウザ会話、(2) 開発者向けMoonshot API（platform.moonshot.ai など）、(3) ターミナル向けKimi Code CLI——の三経路です。いずれもClash（多くは Mihomo コア）の分流順序やDNSのねじれで「Web だけ速い」「API だけ総タイムアウト」「CLI だけ証明書エラー」に見えがちです。本稿は热点×Clashの切り口で、ログ主導の DOMAIN ルールとターミナルプロキシの整理を日本語でまとめます。記載ホストはサービス更新で増減するため、YAML は叩き台とし、必ず自分の接続ログを正にしてください。

検索意図：Kimi K2.6 だけを「単一ドメイン」で通そうとしない

Kimi K2.6は、長いコンテキストとツール呼び出しを前提にしたコーディングエージェント向けの重み公開が話題になったモデル族です。ローカル推論やセルフホストの議論も増えますが、多くの読者は公式 WebかMoonshot API、あるいはKimi Code CLIでクラウド側の推論に乗ります。そのとき外向き HTTPS は、短い REST よりストリーミングやサンドボックス連携でホスト幅が広がり、購読テンプレの巨大な RULE-SET や GEOIP に先に吸われて意図しない DIRECTへ落ちる——という、他の Agent 系記事（OpenAI Codex×Clash、Junie CLI×Verge Rev、Cursor 3 多 Agent）と同型の失敗が起きます。

中国系 AI サービス全般の分流の考え方はDeepSeek の Web・API 分流稿と親和性がありますが、Moonshot／Kimiはドメイン集合が別です。deepseek.com のルールを流用しても platform.moonshot.ai は救えません。用語とノブの意味はチュートリアルとカスタムルールを先に押さえると、以降のログ読みが速くなります。

ステップ 1：Web・Moonshot API・Kimi Code CLI のどこが壊れているか

切り分け表を頭に置きます。(A) ブラウザの Kimi（kimi.com や kimi.moonshot.cn など）は表示できるが、開発者コンソールやAPI キー発行だけ失敗する、(B) curl や SDK からのMoonshot APIだけタイムアウトする、(C) Kimi Code CLIだけハングする、の三つに大別できます。(A) は認証・課金・静的 CDN の FQDN 漏れ、(B) は api.moonshot.cn／platform.moonshot.ai が別 policy、(C) はターミナルがシステムプロキシを読まないか NO_PROXY で迂回、が典型です。

Agentic Codingを有効にした直後だけ増えるホストは、コミュニティの固定表にまだ載っていないことがあります。検索結果の「代表ドメイン3つ」より、自分の Rule ログ一行を信頼してください。K2.6 固有の長時間セッションでは HTTP/2 のチャンク転送が続き、短いヘルスチェックだけ成功する部分的成功にも見えます。

💡 ヒント Kimi K2.6をローカル重みで動かす構成では、クラウド API とは別にモデル配布 CDNやHugging Face系ホストが増えます。クラウド API だけ直したい場合は、検証中はローカル推論を一度切ってログを単純化すると原因が追いやすくなります。HF 周りはHugging Face 分流稿も参照できます。

ステップ 2：Clash 接続ログで Moonshot／Kimi の FQDN を資産化する

分流を書く前に、Mihomo 系 GUI のコネクション一覧や Verge 系のログで、K2.6 推論中に張られた host／sni を拾います。タイムアウト行の直前に現れた名前を DOMAIN の材料にしてください。moonshot.ai や moonshot.cn のサフィックス一括は運用は速い反面、課金や社内ポリシー用ホストまで同じ出口に乗るため、まずはログで狭める運用が向きます。

並行して、ブラウザ拡張・別 VPN・社内 PAC が同じマシンで別ポートを指していないか確認します。HTTP(S)_PROXY と Clash のシステムプロキシ注入が二重だと、「ルールは正しいのにブラウザだけ別穴」が起きやすいです。NO_PROXY に広域ドメインを詰め込むと、Moonshot APIだけ意図せず直叩きに逸れ、TLS が途中でぶら下がって総タイムアウトに見えることもあります。

ステップ 3：Moonshot API／Kimi Web 向け DOMAIN ルール（叩き台）

購読テンプレに大きな RULE-SET がある場合、上から先にマッチした行が勝つため、以下のような狭い行をリスト上位へ寄せます。Moonshot_Kimi は安定した proxy-groups 名に置き換え、ログに出ていない行は削る／足す前提で使ってください。

rules:
  # Replace Moonshot_Kimi with your stable outbound group — extend from YOUR logs only
  - DOMAIN,platform.moonshot.ai,Moonshot_Kimi
  - DOMAIN-SUFFIX,api.moonshot.cn,Moonshot_Kimi
  - DOMAIN-SUFFIX,moonshot.ai,Moonshot_Kimi
  - DOMAIN-SUFFIX,moonshot.cn,Moonshot_Kimi
  - DOMAIN-SUFFIX,kimi.com,Moonshot_Kimi
  - DOMAIN-SUFFIX,kimi.moonshot.cn,Moonshot_Kimi
  # Kimi Code CLI / console / CDN — add only what YOUR connections panel shows

platform.moonshot.aiは開発者がAPI キーや利用枠を触る入口として検索されやすく、ここが DIRECT のままだと「キーは作れたのに curl だけ死ぬ」に見えます。一方 api.moonshot.cn は OpenAI 互換の /v1 呼び出しでよくヒットします。ドキュメント閲覧用の platform.moonshot.cn や静的配信の別 FQDN がログに現れたら、同じ Moonshot_Kimi に揃えるか、課金だけ別グループに分けるかを運用方針で決めます。

GitHub や npm レジストリを同時に開いていると、別ホストが同じ遅い出口に乗り、Kimi だけが遅いように錯覚することもあります。切り分け時はタブとバックグラウンドの更新を減らし、Cursor／GitHub 分流との干渉も意識してください。

ステップ 4：Kimi Code CLI のターミナルプロキシを揃える

Kimi Code CLIは、IDE 内蔵エージェントではなくシェル上の実行ファイルとして動くため、Claude Code CLI のタイムアウト稿と同じく環境変数経路の確認が中心になります。親ターミナルに export HTTPS_PROXY=http://127.0.0.1:7890（ポートは自分の mixed-port に合わせる）を入れ、HTTP_PROXY も揃えます。ALL_PROXY を socks5 にする構成では、CLI 側が socks を解釈しないビルドもあるため、まず HTTP プロキシでベースラインを取るのが無難です。

mise／asdf／コンテナツールチェーン経由で CLI を起動すると、子プロセスが親の環境を引き継がないことがあります。IDE の統合ターミナルと外付けターミナルで結果が違う場合は、echo $HTTPS_PROXY の差を先に潰してください。WSL や Dev Container ではホストとゲストで名前解決が分岐しやすいので、WSL2 と Windows ホストの Clash 共有のレイヤ分離も併せて見ます。

プロキシ変数が効かない実行ファイルには、TUN でコア側にトラフィックを寄せる逃がし経路があります。副作用はTUN モード解説を読んでから試してください。企業プロキシの HTTPS インスペクション下では、ブラウザにだけ信頼 CA が配られ、CLI だけ証明書検証失敗になることもあり、これはルール以前の問題です。

⚠️ 注意 職場や学校で外部推論 API の利用自体が制限されている場合、技術的に分流が通っても規程と衝突し得ます。許可境界とログ保全方針を先に確認してください。

ステップ 5：DNS（fake-ip／nameserver-policy）を単一変数で振る

DNSは「短い GET は成功するのに、K2.6 の長いストリームだけ失敗」タイプを生みやすい層です。enhanced-mode の fake-ip と OS の resolver、macOS のネーム解決順、ブラウザの Secure DNS が噛み合わないと、表示と実コネクションの宛先が食い違います。検証は一度に一つの項目だけ変えます。(1) fake-ip と redir-host の切替、(2) nameserver-policy で moonshot.ai／moonshot.cn 系だけ別 resolver、(3) IPv6 優先の ON/OFF、の順が追いやすいです。

Public DNS と DoH を同時に二系統足すと、どちらが効いたかログから読みにくくなるため、まずは nameserver を単純化してから policy を足す構成を推奨します。Linux では systemd-resolved との競合が典型で、Linux の Clash DNS トラブルとMeta／Mihomo の sniff と DNSを参照しつつ、Kimi 実行中のログ差分を正にしてください。

ステップ 6：Cursor／Codex／Junie 記事との棲み分け（重複検索を避ける）

2026 年の热点は Agent 系が並立しますが、ドメインは共有されません。Cursorは cursor.sh 系、OpenAI Codexは chatgpt.com／openai.com 系、Junieは jetbrains.com 系が中心です。Kimi K2.6を触るなら Moonshot／Kimi の FQDN セットを別ファイルで管理し、購読 YAML に無秩序に足さない方が長期運用に向きます。Mixin で断片だけ追記する手順はClash Verge Rev の Mixin 稿（macOS でも発想は共通化可能）が参考になります。

オープンウェイトをローカルで試す読者は、推論 API とは別に大容量ダウンロードが走ります。帯域とルールの両方を見る必要がある場合は、検証を「クラウド API のみ」と「ローカル重みのみ」に分け、ログを混ぜない運用が安全です。

よくある質問

Kimi の Web は開くのに Moonshot API だけタイムアウトするのはなぜ？

チャット UI と API 基盤でホスト集合が分かれ、api.moonshot.cn や platform.moonshot.ai が別 proxy-groups や DNS 経路に落ちていることが多いです。API 行の FQDN と採用ルール名をログで揃えてください。

platform.moonshot.ai だけ通せば Kimi K2.6 は足りる？

単一行だけで済む環境もありますが、静的 CDN・課金 UI・Kimi Code CLI の追加ホストがログに現れるビルドは普通です。Agentic Coding実行中だけ増えるサブドメインも追補が必要です。

Kimi Code CLI はブラウザと同じプロキシ設定で動く？

ターミナルはシステムプロキシを読まない場合が多く、HTTP_PROXY／HTTPS_PROXY で明示するか TUN で一本化する必要があります。IDE 起動の子プロセスが親と別経路になることもあります。

まとめ

Kimi K2.6のようなオープンソース Agentic Codingの話題は、実務ではKimi Web・Moonshot API（platform.moonshot.ai など）・Kimi Code CLIの三経路に分解して考えると、Clash 分流とDNSの設計ミスが「一部だけタイムアウト」として顕在化しやすくなります。利用形態の分類→ログで FQDN と policy を取得→狭い DOMAIN をリスト上位へ→CLI のターミナルプロキシを一本化→DNS を単一変数で検証→他 Agent 热点記事とドメイン集合を分離管理の順に進めると、再現性が上がります。

従来型の単機能プロキシや、ブラウザ拡張だけの簡易切替では、API と CLI と Webを別々の経路で追いかけつつ、長いストリームと短い REST を同一ログ画面で比較する運用までを一気通貫で持ち上げにくいものもあります。一方 Clash／Mihomo 系はルール順と接続ビューを軸に微調整でき、ホストが増え続けるコーディングエージェントとも相性がよいです。入手経路を一本化したい場合はダウンロードページから確認し、VPN との設計差はClash と VPN の比較も参考にしてください。

→ Clash を公式の入手先からダウンロードし、Kimi K2.6 利用中の接続ログで Moonshot／Kimi 向け分流を整える