Kilo Codeレビュー：料金・使い方とCline／Claude Codeとの比較

Kilo Codeとは？モデルとエージェントの違いを押さえる

Kilo Codeは、Kiloとも呼ばれるコーディングエージェントです。プロジェクトの文脈を読み取り、ツールを使ってコードの作成、変更、レビューを支援します。言語モデルそのものではなく、その周囲で動作するソフトウェアです。オープンソースのクライアントは、Visual Studio Code、JetBrainsの統合開発環境（IDE）、ターミナルに対応しています。さらに、ホスト型サービスとしてCloud Agents、プルリクエストのレビュー、モデルにアクセスするためのゲートウェイを提供しています。この区別は重要です。エージェントのソースコードを確認できても、ホスト型サービスへのリクエストを処理するインフラやモデルまで自分で所有しているわけではありません。モデルカタログの豊富さは選択肢の多さを示しますが、どのモデルも自分のリポジトリを同じように扱えるという証拠にはなりません。

製品情報、ドキュメント、料金は、2026年10月31日に公開されていたKiloの公式ページで確認しています。 比較対象の製品についても、同日に各社の公式ページを確認しました。本稿は公開ドキュメントに基づく評価であり、紹介するワークフローや費用計算は利用例です。ログインした環境での性能テストではありません。評価の軸は、作業環境をまたぐ使いやすさ、モデルを選ぶ自由度、料金体系の明確さ、レビュー機能が扱える範囲です。

Kiloを選ぶべき人、今のツールを使い続けるべき人

Kiloが最も力を発揮するのは、普段のエディターを使いながらモデルを選び、ローカルの作業をホスト型環境での実行につなげたい開発者や小規模チームです。すでに信頼できるエージェントがあり、「この作業ならKiloのほうが便利だ」と具体的に言えない場合、導入する理由は弱くなります。

比較すべきなのは、乗り換えによって何が得られるかです。機能の一覧が長くても、よりよい修正ができるとは限りません。本稿も、読者のコードでKiloがほかの候補を上回るとは主張していません。

Kilo CodeとClineの比較

Clineは、エディターとターミナルに対応するオープンソースのエージェントです。モデルプロバイダーの選択やローカルモデルに対応し、変更について相談する段階と実行する段階をPlan/Actで分けられます。現在の公式サイトには、スキル、外部連携、マルチエージェントでの作業も記載されています。これらはKiloだけの強みではありません。Clineの現在の機能。

Kiloを選ぶとよいのは、 Cloud Agents、モデルのルーティング、ホスト型レビュー、共有請求をひとつの作業環境として利用したい場合です。たとえば複数のリポジトリを保守する小規模な開発会社なら、対話しながらの修正はエディターで行い、範囲を絞った整理はクラウドに任せ、リポジトリで管理するレビュー指示に沿って確認してから人間がマージする、といった使い方が考えられます。

Clineを選ぶとよいのは、 既存のプロバイダー設定、承認の仕組み、プロジェクトルールが仕事に合っている場合です。別のモデル選択画面を手に入れるためだけに、うまく動いているローカルのワークフローを置き換えても、得られるものは多くありません。Kiloのホスト型サービスを採用するより、エージェントのランタイムを基盤に独自の仕組みを構築したい場合も、Clineは検討に値します。

両候補のワークフローを詳しく知りたい場合は、ClineとClaude Codeの比較を参照してください。JetBrainsを利用する人には注意点があります。Clineの現在の料金ページでは、JetBrains拡張機能はEnterpriseに含まれています。個人向けプランでもKiloと同じエディターに対応するとは考えないほうがよいでしょう。

Kilo CodeとClaude Codeの比較

Claude Codeは、ターミナル、IDE、デスクトップ、ブラウザーで利用できるAnthropicのコーディングエージェントです。ターミナルやエディターとの連携では、公式に記載されたサードパーティープロバイダーの利用方法にも対応しています。したがって、「Claude Codeはターミナルでしか使えない」「個人向けサブスクリプションでしか支払えない」という違いではありません。Claude Codeの概要。

Claude Codeを選ぶとよいのは、 Claudeを中心に作業したく、既存のサブスクリプションの利用枠で余裕を持って仕事をこなせる場合です。すでに使っているモデルにアクセスするためだけなら、別のゲートウェイを導入する必要性は低いでしょう。ただし、判断の際には利用枠の共有が制約になります。対話型のClaudeとClaude Codeは同じ利用枠を消費します。

Kiloを選ぶとよいのは、 異なるモデルファミリーを使い分ける、自分のプロバイダーキーを使う、Kiloのローカル環境とホスト型環境を組み合わせる、といった作業を日常的に行う場合です。Claude Codeと併用する方法もあります。別の経路や環境が必要な作業をKiloに任せ、できあがった修正と作業全体の手間を比較してから、任せる範囲を広げるとよいでしょう。KiloでClaudeモデルを使っても、クライアントがClaude Codeになるわけではありません。

Kilo CodeとCursorの比較

Cursorは、エージェント、ターミナル、クラウドでのワークフローを備えた統合型の開発環境です。エディターそのものを評価していて、エージェントを別に設定・管理したくないなら、使い続けるのがよいでしょう。好みのエディターを維持することや、エージェントが使うモデルの経路を自分で決めることを重視するならKiloが候補になります。Kiloのインストールページには、拡張機能を導入できるエディターとしてCursorも記載されています。Kiloを追加しても、すぐにCursorを手放す必要はありません。Cursor、Kiloのインストール方法。

Kilo CodeとOpenCodeの比較

OpenCodeは、ターミナル、エディター、デスクトップに対応し、プロバイダーを選べるオープンソースのコーディングエージェントです。Kiloの現在のCLIと、再構築されたVS Code拡張機能は、OpenCodeを基盤にしています。OpenCodeのワークフローがすでに合っているならOpenCodeを、Kiloの周辺サービスに魅力を感じるならKiloを選ぶとよいでしょう。基盤が共通でも、動作、リリースの頻度、ホスト型機能まで同じとは限りません。OpenCode、Kilo CLIの基盤。

Kilo CodeとRoo Codeの比較

これからツールを選ぶ場合、Roo Codeを、保守が続いている同等の製品として候補に並べるべきではありません。公式リポジトリはアーカイブされており、READMEには拡張機能の提供を終了したと記載されています。既存のRoo CodeユーザーがKiloを検討する際は、指示やワークフローを移行する作業として捉えてください。以前の設定がそのまま引き継がれるとは限りません。Roo Codeのリポジトリ。

いずれの作業環境もしっくりこない場合は、より幅広く紹介しているClaude Codeの代替ツールが参考になります。

Kilo Codeの使い方：エディターとターミナルで作業をつなぐ

Kiloの実用的な強みは、コードの近くでエージェントを使いながら、作業をレビュー可能な変更単位に分けられることです。現在のエディター機能は、コード片を提案するチャットパネルにとどまりません。並行セッション、ワークツリー、差分レビューにも対応しています。

VS Code：調査と修正を分けて進める

KiloのVS Code拡張機能はCLIと共通の移植可能なコアを使い、エージェントの並行実行、ワークツリー、差分の行単位のフィードバックに対応しています。ワークツリーとは、独立したブランチを持つ、同じリポジトリの別のチェックアウトです。メインの作業コピーにすぐ影響を与えずに、タスク側でファイルを変更できます。レビューコメントをエージェントとの会話に戻すこともできます。VS Code向けKilo。

小規模なECアプリで返金処理に不具合がある場面を考えてみます。一方のタスクで返金ステータスが変わる箇所を調べ、もう一方で不具合を再現するテストと、範囲を絞った修正を作成します。コードを変更するタスクには専用のワークツリーを用意します。どちらかのエージェントが変更範囲を広げる前に、調査側に関連する挙動を説明させましょう。

受け入れ条件には、期待する結果を書きます。たとえば、イベント通知であるWebhookが再送されても返金が重複して発生しないこと、従来の正常な処理が引き続き動くこと、無関係な決済コードを変更しないことです。「決済システムを改善して」という依頼より、作業の出発点が明確になります。

修正が届いたら、変更されたファイルを読み、テストのアサーションを確認し、直すべき行に具体的なフィードバックを返します。並行実行が役立つのは、待ち時間を減らしても、衝突する変更の調整に費やす時間が増えない場合だけです。同じチェックアウトに二つのエージェントが書き込めば、互いの作業に干渉する可能性は残ります。

JetBrains：ネイティブ対応でもワークツリーの挙動は要確認

Kiloは、IntelliJ IDEA、PyCharm、WebStormなどに対応するネイティブのJetBrainsプラグインを提供しており、Node.jsは不要です。Settings → Plugins → Marketplaceからインストールし、Settings → Tools → Kilo Codeで設定します。共通のエージェント設定にはkilo.jsoncを使い、IDE固有の設定はプラグイン側で管理します。JetBrainsのドキュメント。

バックエンド開発者が実際に確かめたいのは、普段使っているプロジェクト構造やビルド構成の中でエージェントが作業できるかどうかです。コントローラーからサービス、永続化層まで処理をたどらせ、範囲を限定した変更を提案させます。その後、通常のIDEインスペクションとテストの手順で結果を評価するとよいでしょう。

連携には具体的な制約もあります。エージェントのワークツリーは、デフォルトでは親プロジェクトのインデックス対象から除外されるため、通常のコード解決やインスペクションが働かないことがあります。完全なインデックス処理が必要なら、ワークツリーを独立したプロジェクトとして開いてください。また、ワークツリーのセットアップスクリプトが起動しても、エージェントがその完了を待たない場合があります。依存関係や生成ファイルの準備が終わってから、それらを使う作業を依頼しましょう。これはワークフローの制約であり、モデルがコードを理解できなかった証拠ではありません。

CLI：ターミナル中心の作業にも対応

Kiloのコマンドラインインターフェースでは、プロジェクトのディレクトリからエージェントを使い、Kiloアカウントまたは自分のプロバイダーキーを選べます。公式に案内されているnpmでのインストール方法は次のとおりです。Kilo CLI。

npm install -g @kilocode/cli
kilo

後のコマンドは、作業対象のリポジトリで実行します。最初のタスクでは、編集を承認する前に、失敗しているテストの説明と修正案を求めるとよいでしょう。リポジトリ全体の刷新を頼むより、小さく確認しやすい修正のほうが、判断材料を得られます。

Kiloには、ツールの実行範囲をOSレベルで制限する/sandboxも用意されています。公開されている制御には、書き込み先をワークスペース内に限定すること、Gitメタデータを読み取り専用にすること、任意のネットワーク制限があります。権限設定はアクションを実行してよいかを決め、サンドボックスのルールは実行したアクションが何にアクセスできるかを決めます。自動承認をアクセス制限の代わりにせず、タスクに合わせて両方を設定してください。

Kilo Codeのモデル選び：リクエストの経路も決める

Kiloのモデル選択の柔軟さを生かすには、モデル自体と、リクエストを仲介するサービスを分けて考える必要があります。Gatewayではホスト型のアクセスを利用でき、自分のAPIキーを持ち込むBYOKではプロバイダーのアカウントを通じて推論、つまりモデルによるリクエストの処理を行います。ローカルモデルへの対応により、OllamaやLM Studioなどを使って自分のマシンでモデルを動かすこともできます。プロバイダーキーはAPIにアクセスするための認証情報です。別のアプリのサブスクリプションを、そのまま持ち込める仕組みではありません。Kiloの推論の選択肢、Gateway。

ここで決めることは二つあります。どのモデルにタスクを任せるか、そして、どのアカウントとインフラで処理するかです。この二つを明確にしておくと、後で費用を意味のある形で比較できます。

Kilo Auto Modelには、Efficient、Frontier、Freeの経路があります。Efficientは作業を分類し、難易度に応じたモデルの利用方針を選びます。Frontierは難しい作業向けの有料モデルを使い、Freeは利用可能な無料モデルにリクエストを振り分けます。自動選択を使わず、特定のモデルを選ぶこともできます。Auto Model。

定型的なテストのひな型を作るなら、期待する挙動を明確に伝え、費用を抑えた経路を試すとよいでしょう。複数のサービスにまたがる障害なら、関連するトレースを渡し、修正を承認する前に複数の仮説を挙げさせます。評価すべきなのは、正しいコードを特定し、その仮説が誤りかどうかを検証する方法を提案できているかです。高価なモデルに価値があるのは、受け入れ可能な結果に到達するまでの総作業量を減らせる場合です。

自動ルーティングは便利ですが、条件が固定された実験環境にはなりません。Kiloのドキュメントによると、内部で使うモデルはサーバー側で変更されることがあり、モデル選択画面を展開すると選ばれたモデルと費用を確認できます。同じタスクでツールを比較するなら、「Auto」とだけ記録せず、実際のモデルと経路を残してください。Auto Modelのドキュメント。

Kilo Codeのスキル：繰り返す作業を手順にする

Kiloはスキルに対応しています。スキルとは、繰り返し行うタスクの指示をまとめたSKILL.mdファイルを含むフォルダーです。現在、プロジェクト用のスキルは.kilo/skills/に置きます。エージェントはメタデータを見つけ、必要なときに該当する指示を読み込みます。文書化した手順をエージェントに渡す仕組みであり、すべての指示を正しく実行する保証ではありません。スキルのドキュメント。

返金処理の例なら、決済用のテストフィクスチャの場所、再試行を検証するテストコマンド、重複したWebhookと正当な追加の返金を見分ける方法を、プロジェクトのスキルに記載できます。説明は、いつ適用すべきかをエージェントが判断できる程度に具体的にします。手順をバージョン管理に含めれば、後から参加する開発者も確認できます。

利点は、同じ説明を繰り返す手間が減ることです。ただし、指示を生かすには、作業環境が正しく動くことと、人間によるレビューが欠かせません。テスト手順をどれほど丁寧に書いても、依存関係をインストールしていないクラウド上のチェックアウトでは役立ちません。

Cloud Agents：再現できるタスクをクラウドに任せる

Kilo Cloud Agentsは、自分のノートPCに依存せず、ホスト型の環境で実行できるタスクに向いています。公式ドキュメントには、リポジトリ連携、リモートのLinux環境、ブランチやワークツリーの作成、再利用可能な環境プロファイルが記載されています。プロファイルには、セットアップコマンド、環境変数、シークレットを設定します。Cloud Agents。

最初に任せるなら、範囲が狭く、完了を実行可能なチェックで確かめられるリファクタリングが適しています。たとえば、指定したモジュールの非推奨ヘルパーを、既存のテストを維持しながら置き換える作業です。反対に、文書化されていないローカルサービスや、シェルの履歴にしか残っていない認証情報に依存するタスクは、引き継ぎに向きません。

環境を移す際には明確な制約があります。Cloud Agentsは、.kilo/setup-scriptを自動的に検出して実行することはありません。そのスクリプトがリポジトリの準備を担っているなら、クラウドプロファイルのSetup Commandsから明示的に呼び出してください。プロジェクトのスキルはリポジトリと一緒に引き継げますが、ホームディレクトリに置いたユーザー共通のスキルは引き継がれません。Cloud Agentのドキュメント。

会話が別々であることと、実行環境が別々であることも区別が必要です。クラウドのチャットはコンテナーを共有し、同じワークツリーを使うチャットは互いの編集を参照できます。ワークツリーを分けると変更を分離しやすくなりますが、マシンまで独立するわけではありません。異なる依存関係をインストールするジョブ、同じポートでサービスを起動するジョブ、生成ファイルを排他的に使う前提のジョブでは、この違いが問題になります。

Code Reviews：リポジトリの方針に沿ってレビューする

Kilo Code Reviewerは、連携を設定したGitHubのプルリクエストやGitLabのマージリクエストに、選択したモデルとレビューの重点項目に基づいてフィードバックを追加できます。コミット前のローカルレビューにも対応しています。確かめるべきなのは、長い提案リストを出せるかではなく、自分のコードにある、対処すべきリスクを指摘できるかです。Kilo Code Reviewer。

小規模チームでは、人間によるレビューの前に追加の確認として使うとよいでしょう。顧客ポータルの認可、請求処理で繰り返し届くイベントの安全な扱い、共有サービスのマイグレーション互換性など、リポジトリにとって重要な挙動に焦点を当てます。書式の議論は、すでに書式を統一しているツールに任せましょう。

特に役立つのが、リポジトリで管理するレビュー方針のREVIEW.mdです。ベースブランチにコミットし、Code Reviewsの設定でUse REVIEW.mdを有効にします。Kiloは、提案された変更側ではなく、ベースブランチから方針を読み込みます。そうしなければ、プルリクエスト自身が、自分を評価するための指示を書き換えられてしまうためです。Code Reviewsのドキュメント。

返金サービスなら、イベントの重複処理、テナントの認可、外部呼び出しに失敗した場合のアサーションを確認するよう、方針に記載できます。懸念事項ごとに、該当するパス、説明、根拠を求めましょう。これはレビュー基準の提案であり、本稿のテストでエージェントがそのような欠陥を発見したという意味ではありません。

ローカルでは、/reviewが未コミットの変更を確認し、/review branchがベースブランチに対する現在のブランチの変更を確認します。ローカルレビュー、指摘箇所の修正、通常のチーム手順に沿ったプルリクエスト、という順序が有用です。繰り返し実行したとき、新しい根拠が出ているのか、同じ懸念を言い換えているだけなのかも確認してください。

対象範囲には無視できない制約があります。ホスト型レビューは、依存関係の更新ボットを含め、ボットが作成したプルリクエストをデフォルトで無視します。また、変更されたファイルを中心に確認し、実行と同時処理にも制限があります。自動化された依存関係更新のレビューが主な課題なら、Code Reviewsを有効にするだけで、その未処理の更新まで確認されるとは考えないでください。チームの必須プロセスに組み込む前に、想定どおりの経路でレビューされるか確かめましょう。

Kilo Codeの料金：個人開発者と小規模チームの費用を整理

Kiloでは、プラットフォームの利用、モデルの推論、ホスト型環境のコンピュートが別々に扱われます。共有の管理機能が必要になるまでは、個人向けプラットフォームから始めるのがよいでしょう。 現在のプランと主な費用は次のとおりです。

• Free & Open Source： プラットフォーム利用料は無料です。使用料は別途かかります。
• Teams： $15/ユーザー/月で、請求、キー、エージェント、使用状況をチームで共有・確認できます。Enterprise： プロバイダーやモデルの制限、シングルサインオン、監査ログなどの管理機能を提供し、料金は個別見積もりです。
• 推論： Gatewayはプロバイダーの料金で利用でき、クレジット購入時の処理手数料5%が別途記載されています。BYOKではプロバイダーから推論料金が請求されます。任意で加入するKilo Passは$19/月からで、クレジットを定期購入する仕組みです。使い放題でも、Teamsのユーザー枠でもありません。
• コンピュート： Code Reviewは**$0.33/時間**、Docker/Small Cloud Agentは**$0.60/時間**、Standardは**$1.20/時間**です。秒単位で計測され、推論料金に加えて発生します。Kiloの料金。

したがって、3人で使うTeamsワークスペースは、使用料を除いて$45/月からです（3 × $15）。記載されたレビュー用コンピュートの単価で計算すると、仮に10分間のレビューなら、コンピュート費用は$0.055（10 ÷ 60 × $0.33）となり、これに推論料金と適用される手数料が加わります。これは計算例であり、実測した処理時間やレビューの総額ではありません。最終的な請求額の大きな部分は、モデルの推論や再試行によって左右されます。

クラウドの起動には**$5の残高**も必要です。これは追加料金ではなく、必要残高の条件です。BYOKを使ってもコンピュート料金はなくなりません。クラウドの課金詳細。Passを検討する場合は、実際に使い切れるボーナスクレジットだけを価値として見積もってください。ボーナスクレジットは毎月失効します。Kilo Passの条件。

FreeからTeamsへ移る判断軸は共同管理、TeamsからEnterpriseへ移る判断軸はガバナンスです。必要な管理機能を選び、使用料の予算は別に立てましょう。

導入判断を左右する制約と注意点

Kiloは柔軟な分、小規模チームでも設定を自分たちで判断・管理する必要があります。特に推奨を左右しやすい制約は次のとおりです。

Auto Freeは、データの送信先を確認せずに機密性の高い作業に使うべきではありません。 Kilo自身のAuto Modelドキュメントには、無料の経路で、プロンプトと出力を記録し、サービス改善に利用するプロバイダーが使われる可能性があると記載されています。個人情報や機密情報を送信しないよう、明確に注意しています。クライアントがオープンソースでも、選択したプロバイダーのデータの扱いが変わるわけではありません。非公開のコードには、利用を認められた経路を使ってください。Auto Freeのデータの取り扱い。

ローカルのセットアップが、そのままクラウドのセットアップになるわけではありません。 .kilo/setup-scriptが自動実行されず、ホームディレクトリのスキルも引き継がれないため、同じ指示でもリモートでは挙動が変わることがあります。必要なプロジェクト指示はバージョン管理に含め、クラウドのセットアップを明示的に定義しましょう。そうしないと、エージェントの比較と同時に環境の違いまで比較することになります。

ホスト型レビューは、リポジトリ全体の安全性を保証するものではありません。 変更ファイルを中心とするレビュー、ボットの除外、実行制限によって、確認されない部分が残ります。依存関係ボットが提案する更新や、差分の外に隠れた挙動には、別途の確認が必要になる場合があります。指摘がないからといって、リリースが安全だと証明されたわけではありません。

公開されているレビュー料金の説明には不一致があります。 機能紹介ページは、無料モデルを使った無料レビューを案内しています。一方、レビューのドキュメントは限定ベータ期間中のコンピュートが無料と説明し、専用の料金ページとクラウドのページにはコンピュート料金が記載されています。本稿では、予算を立てる際の基準として専用の料金ページを採用しています。チームにホスト型レビューを無料で使えると約束する前に、ベータ期間やアカウント固有の免除が適用されるかを確認してください。この説明の不一致を理由に、公開単価を未検証のアカウントで実際に請求された金額として扱うこともできません。

チーム向けプランに、すべてのガバナンス機能が含まれるわけではありません。 コードを送信できるモデルやプロバイダーを一元的に制限する必要がある場合、料金ページではその機能はEnterpriseに位置付けられています。請求を共有できるだけでは、同じ統制にはなりません。モデルの品質を比較する前に、この条件で導入先が決まる場合もあります。

Kilo Codeレビューの結論：実際に使うワークフローを理由に選ぶ

ソースを確認できるエージェント、モデルの選択肢、ローカル・クラウド・レビューをつなぐサービスを求めるなら、Kiloは有力な候補です。購入・導入を後押しする最大の理由は、その組み合わせで仕事をどう進められるかにあります。カタログに載るモデルの多さだけでは、移行する理由として不十分です。

Kiloを選ぶとよいのは、 環境間の引き継ぎ、モデルのルーティング、リポジトリのレビュー設定が役立つ定期的な作業を具体的に挙げられ、その使用料も管理するつもりがある場合です。Clineを選ぶとよいのは、 既存のオープンソースのエージェント環境で、ローカルの作業をすでに円滑にこなせている場合です。Claude Codeを選ぶとよいのは、 Claude中心の使い心地を求め、利用枠が仕事量に合っている場合です。Kiloの追加価値が特定の用途に限られている間は、いずれかと併用するのも合理的です。

来週、リポジトリ内の小さく元に戻せるタスクをひとつ選んでみてください。モデルの経路、セットアップの手間、請求対象の使用量、人間による修正、最終的な変更が自分たちの受け入れ条件を満たしたかを記録します。導入判断に役立つ疑問に答えられる場合だけ、試行を繰り返しましょう。Kiloに任せる仕事を増やす基準は、生成するコードの量ではなく、受け入れ可能な変更に到達するまでの手間が減ることです。

よくある質問

エージェントの利用環境を広げる前に、AI業務ワークフロー監査チェックリストで、タスク、レビュー担当者、受け入れ条件を整理してください。