3行でいうと

  • Kimi Code CLIの拡張は5種類です。MCP（外部ツール）、スキル（Markdownの手順書）、サブエージェント（役割別の助手）、フック（イベントで動くスクリプト）、プラグイン（これらを束ねる単位）。置き場所は、自分の全プロジェクト向けの ~/.kimi-code/ と、リポジトリごとの .kimi-code/ の2層が基本です。
  • リポジトリに入っている拡張は、動き出しうるものとして扱われます。公式は、プロジェクトの .kimi-code/mcp.json の stdio 項目は、セッション開始時にローカルのコマンドを実行する、と書き、プロジェクトのエージェントファイルも、見知らぬリポジトリでは先に中身を見るよう警告しています。
  • 他のエージェントからKimiを使う入口は2つです。Kimi Codeの会員のキー（接続先 api.kimi.ai/coding）と、従量課金のOpen Platformのキー（接続先 api.moonshot.ai）。取り違えると通らなくなります（Open Platform側の文書は、401はキーが無効か、プラットフォームと合っていない場合、と書いています）。Claude Code、Codex、OpenCode、Hermes Agentに、公式が設定例を出しています。
  • Kimi Codeのコミュニティガイドラインは、会員の利用を対話的な使い方に限り、非対話の自動化とクライアント情報の偽装を禁じています。拡張や他社ツールと組み合わせる前に読みます。

この記事は、公式ドキュメントを2026年10月24日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はKimiを入れていますが、使い心地はこの記事には書いていません。設定の例は公式に書かれたとおりに写してあり、動作確認はしていません。公式ページは要約の形で取得したため、読み切れていない箇所は「読めていない」と書いています。ドキュメントの大半のページに日付の表示はなく、Kimi Codeは更新が速いので、名前や挙動が変わることがあります。

先に結論

前提：用語をそろえる

全体像：拡張の5種類と置き場所

公式のドキュメントから読み取れる範囲を、表にまとめます。

拡張 何で書くか 自分の全プロジェクト向けの置き場所 リポジトリ向けの置き場所 公式のページ
MCP JSON（mcp.json） ~/.kimi-code/mcp.json .kimi-code/mcp.json Model Context Protocol (MCP)
スキル Markdown（SKILL.md） ~/.kimi-code/skills/ と ~/.agents/skills/ .kimi-code/skills/ と .agents/skills/ Agent Skills
エージェント Markdown（フロントマター付き） ~/.kimi-code/agents/ と ~/.agents/agents/ .kimi-code/agents/ と .agents/agents/ Agents and Sub-Agents
フック TOML（config.toml の [[hooks]]） ~/.kimi-code/config.toml 読んだ範囲では、プロジェクト単位の置き場所は見つからなかった Hooks
プラグイン JSON（マニフェスト）と同梱ファイル /plugins で導入。実体は $KIMI_CODE_HOME/plugins/managed/<id>/ にコピーされる 未対応（ユーザー単位のみと書かれている） Plugins

KIMI_CODE_HOME（既定は ~/.kimi-code）を変えると、Kimi専用の置き場所は一緒に移ります。一方、~/.agents/ 以下は、他のツールと共有できるように、本物のホームの下に残る、と書かれています。ここでの「リポジトリ」は、作業フォルダから上へたどって最初に .git がある場所です（スキルとエージェントのページの記載。MCPのページは、作業フォルダの .kimi-code/mcp.json と書いています）。

MCP：外部のツールをつなぐ

設定ファイルと書き方

Kimi Code CLIのMCPの設定ファイルは mcp.json で、2か所に置けます。同じ名前があれば、プロジェクト側が、ユーザー側を上書きします。公式の例は次のとおりです。

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
    },
    "linear": {
      "url": "https://mcp.linear.app/mcp"
    },
    "legacy-events": {
      "transport": "sse",
      "url": "https://mcp.example.com/sse"
    }
  }
}

つなぎ方は、書き方から決まります。command があれば stdio、url があって transport がなければ HTTP、古いSSEは transport: "sse" が必要です。

足せる項目は、stdio向けの env（環境変数）と cwd、HTTPとSSE向けの headers（固定のヘッダー）と bearerTokenEnvVar（ベアラートークンを入れた環境変数の名前）、全体向けの enabled（false で無効）、startupTimeoutMs（既定30000ミリ秒）、toolTimeoutMs、enabledTools と disabledTools（許可と拒否のリスト）、実験的な deferred です。

トークンを直接書かず、bearerTokenEnvVar で環境変数の名前だけを書く形は、共有する設定ファイルに向いています（僕らの見立てです）。

足す、確かめる、消す

読んだ範囲では、公式のMCPのページにも kimi コマンドのリファレンスにも、kimi mcp add のようなコマンドは見つかりませんでした。他のツールの手順を、そのまま当てはめないようにします。

信頼：リポジトリの mcp.json は、人が確認してから動く

ここが、いちばん大事な所です。公式の文は短く、重みがあります。

stdio entries in a project-level .kimi-code/mcp.json execute local commands when a session starts.

認証とタイムアウト

つながらないときの切り分け（僕らの整理）

ここは、この記事の各節に書かれた公式の挙動を、確認の順に並べ直したものです。

  1. /mcp で、そのサーバーの接続状態を見る。表示がないなら、設定ファイルを直したあとに、新しいセッションを作ったかを確かめる。
  2. プロジェクトの .kimi-code/mcp.json に書いたなら、ワークスペースの信頼の確認に答えたかを確かめる。kimi -p のように画面を出せない場面では、信頼済みでなければ無効のままで、KIMI_CODE_TRUST_WORKSPACE に 1 を入れる方法があります。
  3. 起動に時間がかかるサーバー（初回に npx で取得するものなど）なら、startupTimeoutMs（既定30000ミリ秒）を延ばす。
  4. HTTPのサーバーで認証が要るなら、/mcp-config login <サーバー名> を行うか、headers か bearerTokenEnvVar を確かめる。

権限：名前で許可、拒否する

MCPのツール名は mcp__<サーバー名>__<ツール名> の形です。mcp__github__* のように、* と ** が使えます。引数は、照合の対象にはなりません。どのルールにも当たらない呼び出しは、承認を求められ、「このセッションは許可」を選ぶと、同じ種類の呼び出しが、そのセッションの間通ります。永続のルールは、設定ファイルに書きます（公式の例）。

[[permission.rules]]
decision = "allow"
pattern = "mcp__github__*"

[[permission.rules]]
decision = "deny"
pattern = "mcp__filesystem__write_file"

ルールは書いた順に照合され、最初に当たったものが効きます（設定ページの記載）。

公式の警告は4点です。信頼できる提供元のサーバーだけにつなぐこと。承認画面で、ツール名と引数を見ること。ファイルの書き込みやコマンドの実行のような危ないツールは、手動の承認を残し、mcp__* のような全許可を避けること。そして、「Ask When Needed」モードはMCPツールの呼び出しを自動で承認するので、完全に信頼できるサーバーでだけ使うこと。承認モードの意味は、04の記事に書いてあります。

必要なときだけツールを読み込む「deferred」（実験的）

サーバーを足すほど、ツールの一覧が文脈を食います。deferred: true のサーバーのツールは一覧に入らず、モデルが組み込みの select_tools で必要な定義だけを読み込みます。公式は実験的な機能とし、tool-select の実験フラグ（環境変数 KIMI_CODE_EXPERIMENTAL_TOOL_SELECT=1、または config.toml の [experimental]）と、モデルの dynamically_loaded_tools の宣言の両方がそろわないと、設定は無視される、と書いています（公式のモデルは、この宣言を自動で行う、とも書かれています）。全実験機能をまとめて入れる環境変数 KIMI_CODE_EXPERIMENTAL_FLAG=1 もあります。全サーバーを既定にするのは [mcp] の default_deferred = true で、サーバーごとの指定が優先します。

スキル：手順書をMarkdownで渡す

作る：ディレクトリ形と、フラット形

スキルは、決まった場所に置いたMarkdownです。形は2つあります。

skills/
├── review-pr/              # ディレクトリ形 → スキル名 review-pr
│   ├── SKILL.md            # 本体
│   └── references/
│       └── checklist.md    # 補助のファイル（${KIMI_SKILL_DIR} で参照）
└── commit.md               # フラット形 → スキル名 commit

補助のファイル（チェックリストやスクリプト）が要るなら、ディレクトリ形にします。フラット形のスキルには専用のフォルダがないので、${KIMI_SKILL_DIR} は、スキルを置いた skills/ フォルダそのものを指します。同じ場所に <名前>/SKILL.md と <名前>.md があるときは、ディレクトリ形が勝ちます。

SKILL.md の書き方

先頭にYAMLのフロントマター、続けてMarkdownの本文を書きます。完全な例は後ろの「PRのレビュー」にあります。

フロントマター 意味（公式の表の要約）
name スキル名。大文字小文字を区別しない。ディレクトリ形では必須
description モデルが、いつ使うかを決めるための1行。ディレクトリ形では必須
type prompt（既定）、inline（同じ）、flow（手動だけ）。ほかの値は読み飛ばされる
whenToUse いつ発動させるか
disableModelInvocation true で、モデルが自分で呼ぶのを止める
arguments 名前つきの引数。本文で $<名前> として読める

本文では、実行前に $ARGUMENTS（引数の文字列そのまま）、$0、$1（位置引数）、$<名前>、${KIMI_SKILL_DIR} が置き換えられます。引数のプレースホルダが1つもないときは、呼び出し時の文字が末尾に ARGUMENTS: ... として足されます。ディレクトリ形で name か description を欠くと、解析が失敗する、と公式は書いています。

呼ぶ：手動と自動

手動は、スラッシュコマンドです。

/skill:code-style
/skill:git-commits fix concurrency issue in login endpoint

自動は、モデルが description と whenToUse を見て呼ぶ形です。disableModelInvocation: true か type: flow のスキルは、自動では呼ばれません。スキルがスキルを呼ぶ入れ子は、3段までで、それより深いものは打ち切られます。

置き場所と優先順位

優先順位は「プロジェクト、ユーザー、追加、組み込み」の順です。追加の置き場所は、config.toml の最上位に書きます。

extra_skill_dirs = ["~/team-skills", ".agents/team-skills"]

起動のたびの切り替えには、kimi --skills-dir <dir>（自動で見つける置き場所の代わりに、指定した場所を使う。何度も付けられる）もあります。

公式の完全な例：PRのレビュー（抜粋）

---
name: review-pr
description: Review a Pull Request according to team standards and produce a structured review report
type: prompt
whenToUse: When the user asks me to review a PR, inspect code changes, or evaluate commit quality
arguments:
  - pr_ref
---

Please review the PR the user specified: $pr_ref

1. Fetch and read the full diff for `$pr_ref`.
2. Check each of the following items:
   - Whether corresponding test cases are included
   - Whether error handling covers edge cases
3. Refer to the checklist in the same directory: `references/checklist.md`
4. Produce a review report (conclusion, blocking changes, suggestions)

公式の手順は、これを ~/.kimi-code/skills/review-pr/SKILL.md に保存し、チェックリストを同じフォルダの references/checklist.md に置き、新しいセッションで /skill:review-pr #1234 と呼ぶ、というものです。上の本文は、公式の例から項目を減らした抜粋です。

組み込みのスキルと、他のツールからの取り込み

CLIには同梱のスキルがあり、スラッシュコマンドのリファレンスに載っています。/mcp-config（MCPの設定とOAuthログイン）、/update-config（config.toml と tui.toml の確認と編集）、/custom-theme（配色テーマ）、/check-kimi-code-docs（公式ドキュメントをもとにした質問への回答）、/sub-skill（ローカルのスキルを階層のあるまとまりに整理。.review は提案だけ、.consolidate は実行）です。

もう1つ、/import-from-cc-codex は、Claude CodeとCodexの指示、スキル、MCPの設定をKimi Codeに取り込むものと説明されています。ただし、一覧に1行あるだけで、何をどこから読み、何を書き換えるかは、読んだ範囲では見つかりませんでした。試すなら小さなリポジトリで、取り込み先を確かめながら、というのが僕らの見立てです。Kimi自身を説明する組み込みスキルは、最上位の builtin_product_skills（既定 true）で止められます。

サブエージェントとエージェントファイル：役割を分けて任せる

組み込みの3種類

公式が挙げる組み込みのサブエージェントは3つです。coder（ファイルを書き換え、コマンドを実行できる、既定の汎用）、explore（読むだけの探索）、plan（実装の計画づくり。シェルは使えない）。この3つは、さらにサブエージェントを呼べません。呼ぶかどうかは、メインのエージェントが判断すると読めます（判断の基準を書いた文は、読んだ範囲では確認できていません）。呼ぶたびに承認の画面が出ますが、許可ルールに当たる場合と「Ask When Needed」モードでは出ません。

サブエージェントは、自分の文脈で動き、メインに戻るのは最終の結果だけ、と読めます。そのかわり、それぞれがトークンを使うので、簡単な仕事ならメインで済ませるほうが安い、と公式は書いています（リポジトリ単位の調整モードとして、実験的なTowerもあります）。

自分のエージェントを書く

エージェントファイルは、フロントマター付きのMarkdownで、本文がシステムプロンプトになります。公式の例です。

---
name: reviewer
description: Strict code reviewer that reports severity-ranked findings
whenToUse: Code reviews and PR checks
override: false
tools:
  - Read
  - Grep
  - Glob
  - mcp__github__*
disallowedTools:
  - Bash
---

You are a strict code reviewer. Read the diff, then report findings grouped by severity…

フロントマターは、description（必須。メインが、どのサブエージェントを選ぶかの手がかりになる）、name（省略するとファイル名）、whenToUse、override（同名の組み込みを置き換える。既定 false）、tools（許可リスト。省略か * だけで全部、tools: [] で全部無効）、disallowedTools（拒否リスト。tools のあとに適用）、subagents（呼べるサブエージェントの許可リスト。省略すると coder、explore、plan）です。

公式は照合の細部も書いています。組み込みのツール名は大文字小文字を区別した完全一致で（read は Read に当たらず警告が出ます）、ワイルドカードが効くのは mcp__ で始まる項目だけです。

本文には ${base_prompt}（既定のプロンプトを埋め込む）や ${plugin_sections}（プラグインの指示を残す）が使えます。どちらも書かない本文は、プロンプト全体を自分のものにし、プラグインの指示は入りません。公式は、サブエージェントとして動くカスタムエージェントには、「最後のメッセージが引き渡しのすべて」という既定の枠組みが付かないので、最後のメッセージを完結した結果にするよう、本文に書くことを勧めています。

置き場所と、起動時の指定

優先順位は、明示の --agent-file、プロジェクト、追加（config.toml の extra_agent_dirs）、ユーザー、プラグイン、組み込みの順です。メインのエージェントを選ぶには、次のように書きます（公式の例）。

kimi --agent reviewer
kimi -p --agent reviewer "Review the changes on this branch"

--agent と --agent-file は、新しいセッションにだけ効き、--session や --continue とは組み合わせられません。エージェントは、セッションを作るときに固定され、あとから切り替えられません。$KIMI_CODE_HOME/SYSTEM.md を書くと、既定のメインエージェントのシステムプロンプトを、恒久的に置き換えられます。ツールの集合や委任の許可リストは、そのまま既定が使われます。

公式が出している信頼の警告（エージェントファイル）

プロジェクトのエージェントファイルは、信頼していないクローンも含め、リポジトリ自身が持ってきます。override: true つきの agent.md は、既定のメインエージェントのシステムプロンプトを丸ごと置き換え、tools のないファイルは全ツールを持ちます。公式は、見慣れないリポジトリでは、実行する前に .kimi-code/agents/ と .agents/agents/ を、スクリプトを確かめるのと同じように見るよう書いています。セッションのフォルダの記録（wireファイルやタスク記録）は、プロンプトやコマンドの出力、資格情報の痕跡を含みうるので、共有する前に伏せるよう、公式は書いています。

フック：決まったタイミングで、自分のスクリプトを動かす

書き方

フックは、~/.kimi-code/config.toml の [[hooks]] に書きます。1つのルールに書けるのは、event（必須）、matcher（正規表現、省略で全部）、command（必須）、timeout（秒、1〜600、既定30）だけで、余分な項目があると設定ファイルが読み込めなくなります。複数のルールが同じイベントに当たると並列に動き、同じ command は1回だけ動きます。公式のクイックスタートの例です。

# ~/.kimi-code/config.toml に書く
[[hooks]]
event = "Notification"           # 発動：バックグラウンドの状態が変わったとき
matcher = "task\\.completed"     # 「完了」の通知だけが対象
command = "terminal-notifier -title Kimi -message 'Task done'"

イベントは20種類が表にあります。主なものは、UserPromptSubmit（入力の送信時）、PreToolUse（ツールを呼ぶ前。権限の確認より前）、PostToolUse、Stop（モデルが応答を終えようとしたとき）、SessionStart、SessionEnd、SubagentStart、SubagentStop、PermissionRequest、Notification などです。このうち、メインの流れを変えられるのは PreToolUse、Stop、UserPromptSubmit の3つだけで、残りは観察用です。

止める：終了コード

フックのスクリプトは、標準入力でイベントのJSONを受け取ります（hook_event_name、session_id、cwd など。ツール名やコマンドの内容は、イベントごとに足される）。結果は、終了コードで返します。

終了コード 意味 CLIの動き
0 許可 続行。標準出力が文脈に足されることがある
2 ブロック 操作を止める。標準エラー出力が理由になる
それ以外 スクリプトのエラー 通す（fail-open）
タイムアウトや異常終了 例外 通す（fail-open）

JSONを標準出力に出して、止めることもできます。hookSpecificOutput の中の permissionDecision に deny を、permissionDecisionReason に理由を入れます。公式の例は、「grep ではなく rg を使って」と理由を返すものでした。

公式の例：危ないシェルコマンドを止める

[[hooks]]
event = "PreToolUse"
matcher = "Bash"
command = "node ~/.kimi-code/hooks/block-dangerous-bash.mjs"
timeout = 5

公式のスクリプトは、標準入力のJSONから tool_input.command を取り出し、rm -rf を含んでいれば、標準エラー出力に理由を書いて終了コード2で終わる、という短いものです。公式は、仕組みを見せるだけで実用の水準ではなく、文字列の検査はすり抜けやすい、と断っています。本物にするには、許可リストか、クォートや変数展開や複数コマンドを読めるシェルの構文解析が要る、という説明です。

フックの設定が、どう確認、承認されるのかという信頼の仕組みは、フックのページには書かれていませんでした。プラグインが持つフックは、プラグインを有効にしている間だけ動き、導入しただけでは動かない、と書かれています。

プラグイン：束ねて、配る

導入と管理

プラグインは、スキル、エージェント、セッション開始時に読み込むスキル、システムプロンプトへの指示、MCPサーバー、フック、スラッシュコマンドを、1つの導入の単位にしたものです。管理は、TUIの /plugins の画面と、スラッシュコマンドで行います。公式のページには、kimi plugin ... というシェルのサブコマンドの記載はありません。

/plugins の画面には、Installed、Official（Kimi保守）、Curated（パートナーの第三者製）、Custom（URLから導入）の4つのタブがあります。

主なコマンドは、/plugins list（一覧）、/plugins install <パスかURL>（ローカルのフォルダ、zipのURL、GitHubのURLから導入）、/plugins marketplace [source]（公式のマーケットプレイス、または自分のJSON）、/plugins info <id>（詳細と診断）、enable、disable、remove（確認あり）、reload、/plugins mcp enable|disable <id> <server>（プラグインのMCPの切り替え）です。

GitHubからは、リポジトリのURL、tree/<ref>、releases/tag/<tag>、commit/<sha> の4つの形で導入できます。通信は github.com のリダイレクトと codeload.github.com だけで、api.github.com は呼ばない、と書かれています。

導入の性質として、次の4点が書かれています。変更が効くのは /reload か新しいセッションから。ローカルの導入は $KIMI_CODE_HOME/plugins/managed/<id>/ にコピーされ、CLIは常にそのコピーから動く（元のフォルダを直しても、入れ直すまで効かない）。削除は、導入の記録を消すだけで、コピーと元のフォルダは残る。導入はユーザー単位で、全プロジェクトに効き、プロジェクト単位は未対応。

マニフェストの書き方

プラグインは、フォルダかzipで、マニフェストを kimi.plugin.json か .kimi-plugin/plugin.json に置きます（両方あれば前者が優先）。公式の例です。

{
  "name": "kimi-finance",
  "version": "1.0.0",
  "description": "Finance data and analysis workflows for Kimi Code CLI",
  "skills": "./skills/",
  "systemPromptPath": "./SYSTEM.md",
  "sessionStart": {
    "skill": "using-finance"
  },
  "interface": {
    "displayName": "Kimi Finance",
    "shortDescription": "Market data and financial analysis workflows"
  }
}

主な項目は、name（必須。idになる）、skills（./ 始まりのパス）、agents（省略すると agents/ を自動で探す）、sessionStart.skill（セッション開始時に読み込むスキル）、systemPrompt と systemPromptPath（有効な間、システムプロンプトに足す指示）、mcpServers（既定で有効）、hooks（有効な間だけ動く）、commands（スラッシュコマンドになる .md）です。

プラグインのスキルは /skill:<プラグインid>:<スキル名> で呼びます。名前だけでは、プラグインのスキルに当たりません。スラッシュコマンドは /<プラグイン名>:<コマンド名> になり、公式の例は commands/report.md を /kimi-finance:report TSLA と呼ぶものでした。tools、apps、inject、configFile のような、対応しない項目は、診断が出て無視されます。システムプロンプトへの指示には、項目ごとに32KB、全プラグインの合計で64KBの上限があります。

公式は、安全面の作りについても書いています。導入やセッション開始のとき、コマンド型のプラグインのツールは実行しません。すべてのパスは、シンボリックリンクを解決したあとも、プラグインのフォルダの中でなければなりません。プラグインのMCPサーバーは、/reload か新しいセッションのあとに起動し、いつでも /plugins から止められます。壊れたマニフェストは /plugins info <id> に診断として出ます。一方、第三者製のプラグインについての独立した警告は、ページには見つかりませんでした。公式GitHubのREADMEには、導入ごとに信頼の水準が先に表示される、という趣旨の説明がありますが、その表示の中身は、読んだ範囲では確認できていません。

公式のプラグイン3つ

導入は、/plugins の Official タブで選んで Enter、そのあと /reload か /new です。自動更新はありません。バージョンの数字は、2026年10月24日に公式ページに表示されていたものです。デスクトップアプリの文書は、ブラウザを操作するほうを「Kimi WebBridge」と呼んでいて、CLIの文書の「Kimi Browser Extension」と同じものかは、公式が明言していません。

最初の10分でやること

公式に書かれている範囲で、小さく始める順番です。ここは僕らの整理で、公式がこの順番を勧めているわけではありません。

  1. 何が入っているかを見る。 プロジェクトの中で kimi を起動し、/mcp と /plugins list を打つ。リポジトリの .kimi-code/ と .agents/ の中身を、先に目で見る（信頼していないリポジトリなら特に）。
  2. スキルを1つ作る。 ~/.kimi-code/skills/hello-style/SKILL.md のような場所に、name と description と短い本文を書く。最小の形は次のとおりです（フロントマターの項目は公式の表のとおりで、中身の文は僕らの例です）。新しいセッションで /skill:hello-style と呼び、動くかを見る。
---
name: hello-style
description: Answer in short, plain sentences when the user asks for a brief explanation
---

Answer in at most three short sentences.
Avoid jargon; if a term is needed, explain it in one clause.
  1. MCPを1つだけ足す。 /mcp-config で、公式の例にあるような、読み取り中心のサーバーを1つ足す。足したあとは、/mcp で接続状態を見て、新しいセッションで使う。
  2. 権限を絞る。 足したサーバーのツールに対して、[[permission.rules]] で、書き込み系を deny か ask にする。
  3. フックは、通知から。 いきなり止めるフックを書かず、Notification のような観察用のイベントで、挙動を確かめる。上の「公式のクイックスタートの例」を ~/.kimi-code/config.toml に写し、バックグラウンドの作業が終わったときに通知が出るかを見ます。例の terminal-notifier はmacOS向けの通知ツールなので、ほかのOSでは別の通知コマンドに置き換えます（僕らの整理です）。通知が出なければ、command をターミナルで単独で打って動くかを先に確かめ、matcher の正規表現が合っているかを見ます。

エディタから使う：ACPとサーバーAPI

ACP（Zed、JetBrains）

IDEは、kimi acp を子プロセスとして起動し、標準入出力のJSON-RPCで話します。ログインはCLIで済ませたものをそのまま使います。公式のZedの設定例です（~/.config/zed/settings.json）。

{
  "agent_servers": {
    "Kimi Code CLI": {
      "type": "custom",
      "command": "kimi",
      "args": ["acp"],
      "env": {}
    }
  }
}

JetBrainsは、AIチャットの「Configure ACP agents」に、同じ形の agent_servers を書きます（type は無し）。公式は、command にはフルパス（which kimi で調べる）を書くよう強く注意しています。macOSでGUIから起動したIDEは、ターミナルの PATH を引き継がないことが多いためです。すぐ切れるときは、ターミナルで kimi acp を打ち、標準入力を待てばCLIは正常で、IDEの設定の問題です。「Auth required」のときは、ターミナルで kimi を起動してログインし直します。ACPで使えるMCPは http、stdio、sse で、acp 型は捨てられます（画面には出ませんが、警告はログに書かれる、と公式は書いています）。

VS Code拡張のカスタマイズのページは、MCPだけを扱っていました（歯車の「MCP Servers」から、stdioかhttpを足す。保存前に接続を試せる）。スキル、エージェント、フック、プラグインは、そのページには出ていませんでした。デスクトップアプリは、CLIと同じ mcp.json、スキルの置き場所、[[hooks]] を使うと書かれています。MCPは、新しく作ったセッションから効く、と書かれています（スキルとフックについては、書かれていませんでした）。

kimi web のローカルサーバーには、RESTとWebSocketのAPIがありますが、公式は実験的で、安定性は保証しないと書いています。GET /api/v1/providers/{provider_id} は保存したAPIキーを返すので、ポートを公開するときは気をつけるよう、公式は書いています。--dangerous-bypass-auth というフラグがあることも書かれていますが、警告の文言は、読んだ範囲では確認できていません。この記事では、細部を扱いません。

他のエージェントからKimiを使う

入口は2つ

入口 接続先（公式の表記） キーの作り方 課金 公式のページ
Kimi Code（会員） 海外は https://api.kimi.ai/coding/（OpenAI互換は末尾に v1）、中国は https://api.kimi.com/coding/ Kimi Codeのコンソールで作る。1人5つまで。作成時に1回しか全文を見られない 会員の枠（Plus以上）。会話やCLIと同じ枠を共有する Use in Third-Party Tools（キーの数と全文表示の記載は、Kimi Code概要ページ）
Kimi Open Platform（従量） 海外は https://api.moonshot.ai/v1、Anthropic互換は https://api.moonshot.ai/anthropic platform.kimi.ai のコンソール 使った分の従量課金（02の記事） Kimi in Claude Code（Platform）

FAQは、会員のキーとOpen Platformのキーは接続先が別で、それぞれ対応する接続先と組み合わせる、と書いています。モデルIDも入口で違います（Kimi Codeの文書は k3.1-pro、k3、kimi-for-coding など、Open Platformは kimi-k3.1-pro、kimi-k3、kimi-k2.7-code など。一覧は02と04の注記も参照）。会員の枠では、Goにはコーディングの枠がなく、Plus以上で k3.1-pro と k3 が使え、1Mの文脈はPro以上、256K版（k3-256k）はPlus以上、と書かれています。プランにない指定はエラー（403か400）になります。

Claude Codeで使う（Kimi Codeの会員）

公式の手順は、次の流れです。会員でKimi Codeが使える状態にし、Claude Codeを公式の手順で入れ、Kimi Codeのコンソールでキーを作ります。そのうえで、起動する前に、公式のページにあるNodeのスクリプトを実行します。公式の説明では、このスクリプトは ~/.claude.json に hasCompletedOnboarding などの項目を足してAnthropicのログインを飛ばし（既存の内容は残す、と書かれています）、~/.claude/settings.json の env から、接続先、資格情報、モデルに関する既存のキーを消します。スクリプトの全文は、この記事には写していません。実行する前に、中身を読むことを勧めます（僕らの見立てです）。ほかのシェルの設定ファイルに残る ANTHROPIC_* の export も、消すよう書かれています。

そのうえで、~/.claude/settings.json に書きます。公式の例は、256Kの文脈の場合です。

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.kimi.ai/coding/",
    "ANTHROPIC_API_KEY": "Your API Key",
    "ANTHROPIC_MODEL": "k3.1-pro",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "k3.1-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "k3.1-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "k3.1-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "k3.1-pro",
    "CLAUDE_CODE_SUBAGENT_MODEL": "k3.1-pro",
    "CLAUDE_CODE_EFFORT_LEVEL": "max",
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "262144",
    "CLAUDE_CODE_MAX_CONTEXT_TOKENS": "262144"
  }
}

1Mの文脈にするときは、公式の例では、モデル名を k3.1-pro[1m] にして、2つの数字を 1048576 にします。保存したらClaude Codeを再起動します。env はターミナルの export より優先されます。確かめるには、/status で Base URL が https://api.kimi.ai/coding/ になっているかを見ます（モデル名の表示はClaudeのままのことがあるが、呼び出しはKimi Codeに行く、と公式は書いています）。

ANTHROPIC_DEFAULT_*_MODEL と CLAUDE_CODE_SUBAGENT_MODEL を入れ忘れると、タイトル生成などの裏の作業やサブエージェントが失敗する、と公式の表にあります。圧縮の基準（CLAUDE_CODE_AUTO_COMPACT_WINDOW）と文脈の上限は、モデルの文脈に合わせます。

公式の注意は3つです。settings.json はキーを平文で持つので、gitに入れない。K3.1 Proは思考のモードだけに対応し、思考を切るとHTTP 400になる。プロキシで通信の形式を変換すると、挙動が変わることがあるので、Kimi Code側の標準のプロトコルを勧める。思考の強さは /effort で切り替えられ、medium と high が high に、xhigh と max が max に対応します。

VS CodeのClaude Code拡張では、設定後に、ログイン画面の「Run claude in terminal」から、フォルダの信頼とキーの確認に答え、VS Codeを開き直す必要がある、と書かれています。

Claude Codeで使う（Open Platformの従量キー）

Platform側の文書は、接続先とキーの変数が違います。公式の例は、メインに kimi-k3[1m]、HAIKU の段階に kimi-k2.7-code を割り当てています。

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.moonshot.ai/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_MOONSHOT_API_KEY",
    "ANTHROPIC_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k2.7-code",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "kimi-k3[1m]",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3[1m]",
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000",
    "CLAUDE_CODE_EFFORT_LEVEL": "max"
  }
}

確認には、/v1/messages へのcurlが示されています。JSONが返れば接続先とキーは合っており、401ならキーが無効か、プラットフォームと合っていません。

この文書の注意は、こうです。kimi-k2.7-code は思考が必須で、思考を切ると400が返る。ANTHROPIC_API_KEY を一緒に設定すると、ANTHROPIC_AUTH_TOKEN と衝突する。以前にClaude Codeで /login していると、ANTHROPIC_AUTH_TOKEN が優先されるので、/status で確かめ、/logout で消す。2つの入口の例で、キーの環境変数が ANTHROPIC_API_KEY と ANTHROPIC_AUTH_TOKEN に分かれている点は、混ぜると壊れやすい所です。

Codexで使う

Kimi Codeのサーバーは、OpenAIのResponses APIに対応しているので、Codexからは、自作のプロバイダーとして直接つなげる、と公式は書いています（変換用のツールは要りません）。Responses APIは、テキストと画像の入力に対応し、動画には対応しません。公式の流れは次のとおりです。

  1. Kimi Codeのコンソールでキーを作り、Codex CLIを入れる（npm install -g @openai/codex）。
  2. ~/.codex/models.json に、k3.1-pro と k3.1-pro-highspeed のカタログを書く（中身は公式のページにあり、この記事には写していません）。
  3. ~/.codex/config.toml に、次を書く。
model = "k3.1-pro"
model_provider = "kimi"
web_search = "live"
model_catalog_json = "~/.codex/models.json"

[model_providers.kimi]
name = "Kimi"
base_url = "https://api.kimi.ai/coding/v1"
env_key = "KIMI_API_KEY"
wire_api = "responses"

[desktop]
enabled-reasoning-efforts = ["low", "high", "max"]
  1. キーは環境変数 KIMI_API_KEY に入れる（公式は、これがCodex自身の推奨でもあると書いています）。macOSのデスクトップアプリは、Dockから起動すると、ターミナルの変数を引き継がないので、launchctl setenv が要り、再起動すると消えます。代わりに experimental_bearer_token を使う方法もありますが、キーが設定ファイルに平文で残るので、env_key と同時には使わず、コミットしないよう、公式が警告しています。
  2. codex を起動して hello を送る。起動の表示が model: k3.1-pro と provider: kimi になれば成功です。

つまずき方として、Missing environment variable: KIMI_API_KEY は、そのプロセスが変数を読めていない場合です。codex exec がツールのコマンドを動かせないときの --sandbox danger-full-access は、サンドボックスの隔離を切るので、信頼できる作業にだけ使うよう、公式が警告しています。

OpenCodeとHermes Agentで使う

OpenCodeは、opencode auth login で「Kimi For Coding」を選んでキーを入れ、/models でモデルを選びます（ページに設定ファイルや接続先の記載はありません）。Hermes Agentは、hermes model で「Kimi / Kimi Coding Plan」を選んでキー（sk-kimi- で始まる）を入れ、hermes config edit で ~/.hermes/config.yaml の base_url（https://api.kimi.ai/coding/v1）、key_env: KIMI_API_KEY、api_mode: chat_completions、default: k3.1-pro などを直します。

規約：会員のキーで何をしてよいか

ここは、設定よりも先に読む所です。Kimi Codeのコミュニティガイドラインは、会員の使い方について、次のことを書いています。

04の記事で扱った kimi -p（画面なしの実行）や、CIでの利用が、この「非対話の自動化」にどこまで当たるのか、線引きは、読んだ範囲では公式に見つかりませんでした。業務に組み込む前に、公式に問い合わせるか、従量課金のOpen Platformを使うのが堅い、というのが僕らの見立てです。

僕らの見立て：足す前に、自分に聞くこと

ここからは僕らの見立てで、公式の推奨ではありません。

  1. 誰のコードが、いつ動くのか。 MCP（stdio）、フック、プラグインのMCPは、自分のパソコンでコマンドが動く入口です。スキルとエージェントは、モデルに読ませる命令ですが、tools の指定がなければ全ツールが使えます。
  2. 自分の層か、リポジトリの層か。 迷ったら自分の層（~/.kimi-code/）です。リポジトリに入れた拡張は、同じリポジトリを開く全員に効きます。
  3. 絞ってから足す。 足すサーバーのツール名が決まっていれば、権限のルールは先に書けます。
  4. 他社ツールの設定は、戻せる形で。 Claude Codeの settings.json の env はターミナルの設定より優先され、案内にはAnthropicのログインを飛ばす書き換えも含まれます。バックアップを取り、いじったファイルを控えます。

気をつけること

出典