こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。
Kimi Code Desktopが正式公開され、「ターミナル操作は少し身構えるけれど、画面を見ながらAIにコードを直してもらいたい」と気になっている方も多いのではないでしょうか。見た目は使いやすいデスクトップアプリですが、開くフォルダや権限の選び方を誤ると、意図しない範囲まで変更される心配があります。
この記事では、2026年9月21日に確認した公式ドキュメントをもとに、導入から最初の依頼、権限設定、差分と実行結果の確かめ方まで順番に解説します。私は今回、実機へのインストールや有料プランの契約までは行っていません。したがって、画面名や提供条件は公式情報として紹介し、実際に試したような書き方はしません。
- Kimi Code Desktopの対応OSと入手先
- ログインと作業フォルダの始め方
- Plan・Goal・Swarmの使い分け
- 権限・差分・料金で見る注意点
Kimi Code Desktopの使い方
Kimi Code Desktopは、ローカルのプロジェクトを開き、会話を通じてファイルの確認、編集、コマンド実行、結果の検証まで進める公式クライアントです。いきなり大きな開発を任せるより、配布元、アカウント、作業範囲を一つずつ確かめるほうが安心。詳しい機能は公式のDesktop利用ガイドにもまとまっています。まずは入口から見ていきましょう。
正式版の対応環境
Kimi Code Desktopは、Kimi Code CLIのAgent中核をグラフィカルな画面へ持ち込んだデスクトップクライアントです。公式のWhat’s Newでは、2026年9月17日に正式公開され、Windows、macOSのApple Silicon版、macOSのIntel版が案内されています。Macは搭載チップに合う版を選ぶ必要がある点が、最初の分かれ道です。
入手先は、検索結果に出てきた配布サイトではなく、公式Quick Startに並ぶダウンロードリンクからたどります。「Kimi Code Desktop」という名前の非公式GitHubリポジトリも存在するため、名前が同じだけで公式版と判断しないでください。公開元とURLを確かめるひと手間が、古いラッパーや別アプリを入れる事故を防ぎます。
Linux向けDesktopの配布は、今回確認した公式ページには示されていません。Linuxで使いたい場合にWindows版を無理に動かすのではなく、Kimi Code CLIや対応エディターの利用を検討するほうが自然です。ターミナル中心の別製品も比べたい方は、サイト内のClaude CodeをWindowsへ導入する手順も参考になります。
ここでの要点:対応OSだけでなく、Macのチップ種別と公式配布元まで確認してからダウンロードします。正式公開日と、手元に表示されるアプリ版番号は別の情報です。
入手前に確認する条件
インストール前に決めておきたいのは、Kimi公式モデルを使うのか、外部のモデル提供元をつなぐのか、そしてどのフォルダを開くのかです。Desktopはアプリを入れただけで、どのモデルでも無条件に使えるわけではありません。公式モデルを直接使う場合、Kimiへのログインと、アカウントに付与されたメンバーシップおよびモデル利用権が関係します。
一方、別のモデル提供元を使う場合は、その提供元のAPIキー、接続先URL、モデル情報をSettingsへ登録する流れです。この方法ではKimi側の条件だけでなく、接続先サービスの契約、料金、データ取扱いも別に確認しなければなりません。「外部モデルを選べる」ことと「追加費用なしで使える」ことは同じではありません。
もう一つ大切なのが、作業用フォルダの準備です。最初から仕事の本番リポジトリや秘密情報を含む場所を開く必要はありません。練習用の小さなフォルダを作り、公開しても困らないサンプルファイルだけを置いて、読み取り、提案、差分確認という順に慣れるのがおすすめです。
APIキーや認証情報を会話へ貼らないでください。キーは対応するSettingsの入力欄へ入れ、画面共有やスクリーンショットにも映り込ませないようにします。フォルダ内の.env、秘密鍵、顧客データも同じ扱いです。

ログインとモデル接続
初回起動では、表示言語とテーマを選び、その後にKimi OAuth認証へ進めます。公式Quick Startによると、認証先は地域によって異なり、中国本土はkimi.com、それ以外の地域はkimi.aiです。アプリの案内から開いた認証画面でドメインを確認し、検索広告や似たURLからログインしないようにしましょう。
OAuthは初回にスキップし、あとからアプリ内のサインイン入口で完了することもできます。ログイン後はSettingsのアカウント領域でプラン使用量を確認でき、Composerのモデル選択欄またはSettingsのモデル領域で、現在使えるモデルと利用権を確かめます。公式モデルが見えない場合は、再インストールを繰り返す前に、ログイン先、メンバーシップ、プランごとの利用権を確認してください。
外部プロバイダーを追加する場合は、Settingsのmodel provider領域へAPIキー、base URL、モデル情報を登録します。似た名称のKimi Codeメンバーシップ向け接続先と、従量課金のKimi Open Platformは仕組みが異なるため、キーと接続先を組み合わせ違えないことが大切です。どの経路で課金されるか分からない状態なら、実行より先に契約画面を確認しましょう。
ログイン後の確認順:アカウントの地域、メンバーシップ状態、残りクレジット、利用可能モデル、選択中モデルの順で見ます。画面に出ていないモデル名を記事や古い動画だけで決め打ちしないのがコツです。
作業フォルダの選び方
新しいセッションを作ったら、Composer上部のフォルダ名から最近使った場所を選ぶか、新しい作業フォルダを追加します。Finderやエクスプローラーからサイドバーへフォルダをドロップする方法も公式に案内されています。空のセッションでは、作業フォルダを決めるまでメッセージを送れません。
ここで選ぶフォルダは、AIが読む文脈であると同時に、変更やコマンド実行の起点になります。親フォルダを広く指定すると、関係ない案件まで視界に入りやすくなります。反対に、対象ファイルだけを含むプロジェクト直下へ絞れば、指示の行き違いを減らせます。まずGitで変更履歴を追える練習用リポジトリを用意し、未保存の大事な作業がない状態から始めると安心です。
長期間の作業を一つの目標として管理する考え方は、Cursor Projectsの使い方にも共通します。ただし、各製品で保存場所、権限、セッションの扱いは同じではありません。他製品の操作名をそのまま当てはめず、Kimi Code Desktopの現在の画面で確かめてください。
業務データを扱う前には、会社の利用規程、リポジトリの権限、外部モデルへ送ってよい情報の範囲も確認が必要です。Kimi Codeのメンバーシップ特典は公式ヘルプで個人開発向けと案内されており、法人利用ではKimi Open Platformが案内されています。個人プランが表示されるからといって、会社のコードを持ち込んでよいとは限りません。
最初の依頼を出す手順
最初の依頼は、変更を伴わない読み取りから始めます。たとえば「このフォルダのREADMEを読み、起動方法を3点で説明して。ファイルは変更しないで」と伝えれば、対象、目的、禁止事項、出力形式がはっきりします。結果が合っていたら、「変更案だけ示して」「この1ファイルだけ修正して」のように一段ずつ範囲を広げます。
Composerでは通常の文章に加え、@を使ってファイルやディレクトリを参照できます。名前が似たファイルが多いときは、@で対象を明示し、「ほかのファイルは変更しない」と添えると意図が伝わりやすくなります。依頼を送った後も、処理中のツール呼び出し、考えている内容、各ターンで変更されたファイルが画面に表示され、途中で方向を狭めたり停止したりできます。
うまくいかなかったときは、同じ長い依頼をそのまま連投するより、いったん停止して現在の変更を確認します。直前の変更を戻すための/undoも案内されていますが、取り消し前にChangesで対象を見ておくほうが安全です。Gitを使っているなら、AIの画面だけでなく、Git statusやdiffでも二重に確かめましょう。
◆もっちゃんのワンポイント
初回の成功条件は、大きな機能を完成させることではありません。「指定した1ファイルだけを読み、意図どおりの説明が返り、勝手な変更がない」と確認できれば十分です。小さな成功から始めるほうが、画面の見方も権限の意味もつかみやすいですよ。
PlanとGoalの使い分け
Kimi Code Desktopには、通常の依頼に加えてPlan、Goal、Swarmという作業モードがあります。Planは、ファイルを変更する前に問題を分析し、進め方を提案してもらう場面向けです。古いコードの修正、影響範囲が読みにくい変更、複数案を比べたいときは、最初から編集させずPlanで確認すると判断しやすくなります。
Goalは、複数のターンと確認が必要な長めの目的を置くモードです。目標がComposerの上に表示され、途中で一時停止、再開、取り消しができます。「テストを追加しながら設定画面を改修する」のように、何段階かに分かれる仕事に向いています。ただし、Goalを設定しただけで完成品質が保証されるわけではありません。節目ごとに差分とテスト結果を見る必要があります。
Swarmは、独立した作業を複数のサブエージェントへ分けるためのモードです。調査対象や修正対象が本当に独立している場合には便利ですが、同じファイルを複数が触る仕事では競合や重複が起きやすくなります。初心者が最初から使う必須機能ではありません。通常の小さな依頼、Plan、Goalと順に慣れてから検討しても遅くないでしょう。
| モード | 向く場面 | 確認すること |
|---|---|---|
| 通常 | 説明、単一ファイル、小さな修正 | 対象と変更禁止範囲 |
| Plan | 実装前の分析、影響範囲の確認 | 計画を承認する前の不足 |
| Goal | 複数段階の長い目的 | 節目、停止条件、完了判定 |
| Swarm | 独立した調査や変更の並行作業 | 担当の重複とファイル競合 |
Kimi Code Desktopの使い方と注意点
導入できたあとに大切なのは、AIを速く動かすことより、どこまで任せ、何を自分で確認するかを決めることです。Desktopには承認カード、差分、ファイルプレビュー、ターミナル、内蔵ブラウザーが用意されています。これらを「見るための機能」で終わらせず、毎回の検証手順へ組み込みます。
権限モードは初回慎重に
権限モードはAlways Ask、Ask When Needed、Never Askの3種類です。Always Askは、承認が必要な操作ごとに確認を出します。Ask When Neededは、通常の変更やコマンドを自動で進めつつ、危険性の高い操作や質問、計画など必要な場面で確認します。Never Askは確認を積極的に出さず進むため、操作範囲とリスクを理解した人向けです。
公式Quick Startも、初回セッションや不慣れなプロジェクトではAlways Askを良い出発点としています。確認回数が多いと面倒に感じるかもしれません。ただ、その一枚一枚が「何を変えるのか」「どのコマンドを走らせるのか」を学ぶ教材になります。承認文を読まず連打するなら、Always Askを選ぶ意味が薄れてしまいます。
初期設定はAlways Ask、対象は練習用フォルダ、依頼は読み取りから。この3点をそろえ、どの操作が確認対象になるか分かってからAsk When Neededへ変えるのが無難です。Never Askは、誤操作が起きても戻せる履歴、明確な作業範囲、秘密情報を含まない環境がある場合に限って検討してください。

承認は安全保証ではありません。表示されたコマンドが何をするか分からない場合は承認せず、目的、対象パス、変更内容を説明してもらいます。削除、外部送信、依存関係の追加、公開操作は特に慎重に確認してください。
Browserで画面を確認
Webプロジェクトでは、右側パネルに内蔵ブラウザーを開き、セッションとページ文脈を共有しながら表示結果を確かめられます。画面を別アプリへ切り替えずに済むため、レイアウト修正やエラー確認の往復が減るのが利点です。表示中のページについて、要素を指定してAgentへ伝えるannotation機能も案内されています。
ただし、内蔵ブラウザーで見えたからといって、公開環境でも同じとは限りません。ローカル開発画面、ログイン後の画面、一般公開ページでは、権限、キャッシュ、画面幅、データが異なります。どのURLを、どの状態で、何px程度の幅で見たのかを明確にし、PC表示とスマートフォン幅の両方を確かめましょう。
フォーム送信、削除、購入、メール送信など外部へ影響する操作は、見た目の確認とは別物です。ブラウザーを開けることを送信許可と考えず、実行前に内容と対象を確認します。ログインが必要なサービスでは、CAPTCHAや本人認証を回避せず、必要な部分だけ自分で操作する姿勢が大切です。
画面上の修正を長期タスクとして管理したい場合は、先ほど触れたGoalを使い、「PCと390px幅で横あふれがない」「エラー表示がない」と完了条件を言葉にします。曖昧な「きれいにして」より、何を見れば合格かが明らかになります。
差分とターミナルで検証
変更後は、右側のChangesを開き、まずファイル一覧を見ます。依頼していないファイルが増えていないかを確認し、その次に各ファイルの差分へ進みます。赤は削除、緑は追加として表示されることが多いものの、色だけで良し悪しを決められません。設定値、条件分岐、削除された例外処理など、意味が変わる行を読みます。
File PreviewではMarkdown、JSON、HTML、PDF、CSV、画像、コードやテキストを確認できます。記事、設定、画像を同じ目線で見られるのは便利ですが、プレビューが開いたことと内容が正しいことは別です。JSONなら構文、HTMLなら見出し階層とリンク、画像なら文字と余白というように、形式ごとの確認項目を持ちましょう。
コマンド実行が必要なときは、セッション上部から下側のターミナルパネルを開き、実行コマンド、現在の作業フォルダ、出力を確認します。テストが通っても、対象外のテストが実行されただけということがあります。コマンド名と対象を見て、必要ならGit status、差分、ビルド、表示確認を組み合わせます。
AIの「完了しました」という文章は、完了の証拠ではありません。ファイルの差分、コマンドの終了結果、実際の画面がそろって、はじめて判断できます。予想外の変更があれば、その内容をセッションで説明してもらうか、直前の変更を戻して小さな単位でやり直します。

Windowsで別のAI coding agentも比べたい方は、CodexをWindowsにインストールする方法も確認できます。Kimi Code Desktopは画面中心、CLI製品はターミナル中心という違いがありますが、どちらでも変更履歴と実行結果を人が確かめる原則は変わりません。
料金とクレジットの確認
公式ヘルプでは、Kimi CodeはKimiメンバーシッププランに含まれるサービスで、CLI、VS Code、サードパーティツールからの利用も同じクレジットを消費すると説明されています。クレジットは契約開始日を起点に7日周期で更新され、未使用分は次の周期へ持ち越されません。プランによって含まれる量は異なります。
一方、公式ページには、Kimiメンバーシップ特典とKimi Code特典を将来分ける予定という案内もあります。つまり、今日の契約条件を固定情報として覚えておくのは危険です。この記事では日本向けの価格やプラン別クレジット数を断定しません。契約前に、アプリのSettingsにあるaccount領域と、公式のKimi Code特典ページを同じ日に確認してください。
クレジットを使い切った後に続けるExtra Usageも案内されていますが、これは残高から従量で消費される仕組みです。自動的な支出を望まないなら、むやみに有効化しないほうが安心。外部プロバイダーを接続した場合は、Kimiのクレジットとは別に接続先の請求が発生する可能性があります。
契約前の確認項目:現在の地域、契約プラン、利用可能モデル、7日周期の残量、Extra Usageの有効・無効、外部プロバイダーの請求先を見ます。価格のスクリーンショットだけでなく、更新日と通貨も確認しましょう。
不具合を切り分ける
うまく動かないときは、症状を「アプリが起動しない」「OAuthが完了しない」「モデルが出ない」「処理表示が終わらない」「変更はあるが画面へ反映されない」のように分けます。すべてを再インストールで解決しようとすると、原因が分からないまま設定やセッションだけ失うかもしれません。
ログインできない場合は、地域に合う認証先、アカウント状態、ネットワークを確認します。モデルが出ない場合は、メンバーシップ、プランの利用権、選択中プロバイダーを見ます。処理表示が続く場合は、Changes、ターミナル、Git statusで実作業が終わっているかを先に確認し、必要なら現在のターンを停止します。
Kimi Forumには、2026年9月17日、特定のWindows 10環境とDesktop 3.2.10で、ターン完了後もspinnerが残り、別クライアントでは結果が見えたという利用者報告があります。これは一つの環境での第三者報告であり、全利用者に起きる現行仕様ではありません。似た症状でも、OS、アプリ版、モデル、作業内容、再現手順を分けて考える必要があります。
公式へ報告するときは、秘密情報を消したうえで、OS、アプリ版、発生時刻、再現手順、期待した結果、実際の結果を添えます。セッションのexportにはコード、コマンド出力、ファイルパスが含まれる場合があるため、そのまま共有せず中身を確認してください。公開Issueやフォーラムへ顧客名、鍵、社内パスを貼らないことも忘れずに。
切り分けの順番:画面表示だけの問題か、実際の処理も止まっているか、認証か、モデル権限か、作業フォルダかを分けます。原因を一つずつ確かめると、不要な再インストールを減らせます。
Kimi Code DesktopのFAQ
Q1. Kimi Code Desktopは無料で使えますか?
A. 公式KimiモデルをDesktopから直接使うには、利用可能なKimiメンバーシップとプランごとのモデル利用権が必要です。無料で使えるとは断定せず、アプリのSettingsにあるaccountとmembershipの表示を確認してください。外部プロバイダーを接続する場合は、そのサービス側の契約や料金が別にかかることがあります。
Q2. WindowsとMacのどちらに対応していますか?
A. 公式Docsでは、Windows、macOSのApple Silicon版、macOSのIntel版が案内されています。配布リンクは公式Quick Startから選び、非公式のDesktop版と混同しないようにしましょう。
Q3. 最初の権限モードはどれが安全ですか?
A. 公式Quick Startは、初回や不慣れなプロジェクトではAlways Askを良い出発点としています。操作内容を確認しながら進め、必要性を理解してからAsk When Neededへ変えるのが無難です。Never Askはリスクを理解している場合だけ使います。
Q4. DesktopとCLIは何が違いますか?
A. Desktopは作業フォルダ、セッション、変更差分、プレビュー、ターミナル確認を一つの画面で扱いやすい構成です。CLIはターミナル中心の作業やスクリプト化に向きます。同じPCへ併用でき、一部のローカル設定を共有すると公式Docsに説明されています。
Q5. 処理中の表示が消えない時はどうしますか?
A. まずChanges、ターミナル、Git status、別セッションの状態を確認し、実際に処理が終わっているかを切り分けます。公式の障害案内がない段階では、単一の利用者報告を全利用者の現象として扱わず、アプリ版、OS、再現手順を添えて公式窓口へ報告します。
Kimi Code Desktopの使い方まとめ
Kimi Code Desktopは、WindowsとMacで使える公式のデスクトップ型AI coding agentです。ローカルの作業フォルダを開き、会話からファイル確認、編集、コマンド実行、内蔵ブラウザーでの表示確認、差分レビューまで進められます。ターミナルだけの操作に不安がある方にとって、作業の途中経過を画面で追いやすい選択肢です。
始め方は難しくありません。公式Quick StartからOSに合う版を入手し、OAuthまたは利用するモデル提供元を設定し、練習用の作業フォルダを開きます。最初の依頼は読み取りだけにして、対象ファイルと変更禁止範囲を明示。その後にPlanで進め方を確認し、小さな修正へ進む流れが安心です。
権限はAlways Askから始め、承認カードの内容を読みます。変更後はAIの完了報告だけで終わらせず、Changes、File Preview、ターミナル、Git status、実際の画面を確認してください。GoalやSwarmは便利ですが、長い仕事や独立した作業へ使う機能であり、初日から全部使う必要はありません。
料金面では、公式モデルの利用権とクレジットがメンバーシップに連動し、今後は制度変更も予告されています。外部プロバイダーには別契約が関わる場合もあります。契約前と実行前に、その日のSettingsと公式特典ページを確認することが大切です。
まずは公開しても困らない小さなフォルダで、Always Askのまま「READMEを読んで説明して」と頼んでみてください。何を読んだか、どんな操作が承認対象になるか、Changesに何が表示されるか。この3点を自分の目で確かめられたら、次の一歩へ進めます。
