どの Kiro アプリを選べばいい？

本記事は、2026 年 8 月 12 日に Massimo Re Ferre が公開した「Which Kiro app should I pick?」を翻訳したものです。

Kiro はもう、単一のプロダクトを指す名前ではなくなりました。2025 年 7 月、Kiro を AI IDE としてローンチしました。それ以来、Kiro は IDE という枠にとどまらなくなりました。今の Kiro はソフトウェアエンジニアリングエージェントであり、IDE、CLI、Web アプリ、モバイルアプリ、そして Kiro Crew として利用できます。最近 Kiro を少しでも触っていた方なら、おそらく口にした（あるいは口にしたかった）問いがあるはずです。拍子抜けするほど単純な問いです。「結局どれを選べばいいの？」

正直に答えるなら「場合によります」。ですが、もう少しお付き合いください。この逃げのような答えの裏には、れっきとした判断の枠組みがあります。それが分かれば、選ぶのはずっと楽になります。しかも、そもそも問いの立て方が少しずれていたと気づくはずです。問うべきなのは「どれを選ぶか」ではありません。ほとんどの場合、「この用途ならどれを選ぶか」です。

本題に入る前に、この問いの前提を変えた最近の変化を押さえておきます。

1 つのプロダクト、複数の玄関口

内部的には、Kiro は単一のエージェントハーネスに収束しつつあります。Kiro は、あらゆるサーフェスの裏側で動く 1 つのエージェントになりました。そのハーネスこそがプロダクトです。あらゆる機能が集まる、唯一の正式な置き場所です。実際に触れるもの、たとえば IDE や CLI、Web アプリはいずれもアプリであり、そのプロダクトを利用するための手段です。ハーネスとアプリは意図的に切り離されています。ハーネスは Kiro に何ができるかを定め、アプリはそれをどう体験するかを定めます。

ずっとこんなに整っていたわけではありません。今年の初めまでは、各アプリがそれぞれ独自のエージェントを抱えていました。IDE 版は TypeScript、CLI 版は Rust、Web 版は Python で書かれていました。これらは 3 つの独立した頭脳でした。セッションの保存方式はそれぞれ異なり、権限の表し方にも互換性がなく、新しい機能を追加するには毎回 3 通り実装しなければなりませんでした。その後、これらは単一のエージェントハーネスに統合されました。このハーネスはコードのすぐ隣で独立したプロセスとして動作し、明確に定義されたプロトコル（ACP、Agent Client Protocol）を介して各アプリと通信します。頭脳は 1 つ、顔はいくつも。メリットは 3 つあります。1 つめは、ハーネスに追加されたコア機能がすべてのサーフェスで一斉に使えるようになることです。2 つめは、どのアプリを使っても振る舞いが一貫することです。そして 3 つめは、ここがおもしろいところですが、ラップトップで始めたセッションをクラウドで動かし続け、スマートフォンから確認できることです。最初から最後まで同じエージェントが動いているからです。統合後も、個々のアプリがそのサーフェスでしか意味を持たない機能を独自に増やしていくことはできます。ただし、中核となる体験はどこへ移っても変わらず付いてきます。

そして、引き継がれるのはエージェントの機能だけではありません。手元の設定もそのまま付いてきます。スキル、ステアリングファイル、カスタムエージェント、作り込んだ環境設定。いずれも個々のアプリの内側ではなくハーネス側に設定するものです。そのため、使うアプリを変えても環境をゼロから作り直す必要はありません。現時点では特定のアプリの組み合わせに限られますが、目指しているのはどの組み合わせでも成り立つ状態です。どこで作業していても、自分の Kiro が付いてくる形にしたいと考えています。

この統合に至った詳しい経緯と、そこで下した判断（なぜ独立したプロセスにしたのか、なぜプロトコルとして ACP を選んだのか、その過程でどんなもつれを解く必要があったのか）は、Kiro エンジニアリングチームが One agent, every surface にまとめています。少し回り道になりますが、読む価値は十分あります。

これはアーキテクチャの細部の話に聞こえるかもしれませんが、「どのアプリを選ぶか」という問いにまともな答えが出せるのは、まさにこの構造のおかげです。すべてのアプリが同じエンジンを土台にしているので、どれを選ぶかは、外したら困る賭けではありません。選んでいるのは、出口のない囲い込まれた環境ではありません。玄関口を選んでいるだけです。

これらのアプリは、どれも他のアプリを置き換えるために作ったものではありません。アプリはそれぞれ異なるニーズに応えます。そして組み合わせることで、どれか 1 つでは届かない範囲までカバーできます。アプリが収束していく先は下方向、つまり共通のエンジンです。横方向、つまり互いに似ていく方向ではありません。アプリ間の重複は、躍起になって排除すべきバグではありません。1 つの土台の上に複数の体験レイヤーが載る構成なら、当然そうなる形です。IDE と Web アプリの両方でエージェントをオーケストレーションできるかもしれません。それでいいのです。ただし両者がそれを担うのは、違う相手に向けて、違う場面で、違う場所で、違う手癖や好みに沿ってなのかもしれません。

こうした判断を支える原則

アプリのラインアップをさらに詳しく見ていく前に、判断を支えている原則を整理しておきましょう。どんなアプリを作るかを決めるときに必ず立ち返るものがいくつかあります。個々のアプリの話に入る前に押さえておくと、この先が読みやすくなります。

まず、Kiro が対象にするのはソフトウェアデリバリーライフサイクルです。ソフトウェアを届ける人たちのためにアプリを作ります。まずは開発者、そしてそのすぐ隣にいる職種も対象です。プロダクトマネージャー、プロジェクトマネージャー、アーキテクト、QA リード、UX デザイナー、システムを動かし続けている運用や DevOps の人たちです。そしてこれは、肩書きだけの話ではありません。いま何をしているかの話でもあります。Slack の通知をさばいたり、メールを片付けたり、予定をやりくりしたりしている開発者も、ソフトウェアを届ける仕事をしていることに変わりはありません。ですから、そうした場面で役に立つアプリも対象に含まれます。逆に、意図して作らないと決めているのが「万人向けの汎用 AI アシスタント」です。ただし、この境界線は意図的に曖昧なままにしてあります。線引きの基準は「この人は開発者か？」でも「この作業はコーディングか？」でもありません。「これはソフトウェアを届けるという行為に役立つか？」です。

次に、ビルダーが今いる場所に合わせます。今の環境やスタイルをそのまま受け入れたうえで、そこから一歩先へ進めるよう後押しする、という考え方です。ファイルや関数の中で暮らす人（コードファースト）もいれば、エージェントをオーケストレーションしてコードは副産物と見なす人（エージェントファースト）もいます。業界の大半は今も前者です。母数が大きいのもそちらで、エンタープライズ導入の多くもそこにあります。エージェントファースト勢は今はまだ少数です。ただ、業界が向かっているのはそちらであり、いちばんはっきりした手応えを得られるのもそこです。ですから、エージェントファーストの世界に向けて作りながら、2 つの世界のあいだにシンプルで文脈に即した合流路を用意します。誰でも自分のペースで行き来できるようにするためです。

これがメンタルモデルです。収束させたアーキテクチャの方針から外れないよう気をつけていますが、変化が猛烈に速い領域でもあるので、好機が見えたときには現実的な判断も取りたいと考えています。さて、アプリそのものの話に移りましょう。「結局どれを選べばいいの？」への本当の答えは、ここから先にあります。

アプリを 1 つずつ見ていく

Kiro IDE: 開発の本拠地

IDE は、多くの人が「Kiro」と言うときに指しているものです。Code OSS ベースのエディターで、すでに GA（一般提供）になっており、実際に最も多くのコードが書かれる主要なサーフェスです。企業のチームで一般的な開発スタイルを取っているなら、ここが本拠地になります。

最近の追加でおもしろいのが Agent Focus Mode です。数週間前に、実験的機能として公開しました。IDE では今、2 つのビューを切り替えられます。Code Focus は使い慣れた、手引きのあるコード中心の編集です。Agent Focus は複数のセッションを並行して動かし、状態を管理し、ワークフローが進んでいくのを見守るビューです。どちらもエディターから一歩も出ずに行き来できます。現時点では、この 2 つのビューはまだ緩くつながっている程度です。常に改善して使う人の好みに寄せていきたいので、ぜひ声を聞かせてください。Agent Focus Mode は、先に挙げた 2 つ目の原則を実際に試してもらうための入口だと考えています。使い慣れた環境という安全な足場から、エージェントファーストの世界を覗いてみることができます。ファイルや関数に戻りたくなったら、その時点でいつでも元のビューに戻せます。

Kiro CLI: ターミナルとパイプライン

こちらも GA です。CLI が相手にしているのは、性質がまるで違う 2 つの利用者層です。しかもこの 2 つは、たまたままったく同じインターフェースを欲しがっています。

1 つ目は、ターミナルを好んで使う開発者です。シェルの中で暮らし、フラグとパイプで考え、グラフィカルな画面は助けになるどころか、むしろ邪魔だと感じる人たちです。こうした開発者が CLI セッションを 4〜6 本並べて動かしているのを見かけるのも、珍しくありません。しばしば（あるいは時折）コードを覗きますが、1 行ずつレビューすることはあまりなく、テストを（かなり）頼りにしています。2 つ目は自動化です。こちらには人がまったく介在しません。シェルスクリプトに包まれた Kiro、GitHub や GitLab の CI/CD パイプラインの 1 ステップとして組み込まれた Kiro、誰かのラップトップ上の会話ではなくジョブとして走る Kiro です。この 2 つ目が成り立つのは、エンジンが体験から切り離されているからにほかなりません。UI を一切持たない Kiro です。

CLI からは、予想していなかったことも学びました。誰もが、もっと多機能なアプリへと「卒業」していくわけではないということです。私たちはつい、この話全体を一方向の進歩として語ってしまいます。ビルダーはシンプルなツールから凝ったツールへ移っていく、という語り方です。しかし、フル機能の TUI（Terminal User Interface）を出したあと、lite モードを追加せざるをえなくなりました。かなりの割合のユーザーにとって、TUI はすでに過剰だったからです。あえてゆったり構えていて、機能や画面はもっと少なくてよい、増やさなくてよいと考えている人もいます。サーフェスが増えれば便利になるとは限らない。ここは覚えておきたいところです。

Kiro on the web: クラウドファーストのサーフェス

Kiro on the web は、現時点では Preview です。クラウドファーストのサーフェスであり、共同作業をする場、作業を立ち上げる場、そしてバックグラウンドのエージェントを見守る場です。エージェントは、つきっきりで面倒を見なくても裏で黙々と作業を続けます。そして最近は、そちらが本当の役割になりつつあります。つまり、クラウドセッションのコントロールプレーンです。IDE や CLI からクラウドエージェントを直接起動できるようになった今、問いは「どうやって 1 つ起動するか」ではなく、「走り出したエージェント全部をどこで見守り、どこから舵を取るか」に変わりました。Web は、セッションがどこで始まったかを問わず、その「一箇所」に急速になりつつあります。向いているのは、フロンティア開発者やチーム、それに PM やリードといった開発の周辺にいる職種の人たちです。一日中エディターに張りついてはいたくないけれど、ソフトウェアを届ける過程には関わりたい人たちです。

Kiro on the web を見ると、この切り離しが理論ではなく実際のものだとよく分かります。統合ハーネスの上で動いているので、機能が生まれたアプリの中に閉じ込められることがなくなります。その効果が最初にはっきり出たのが Web でした。いちばん分かりやすいのが spec-driven development（仕様駆動開発）です。以前は IDE でしか使えませんでしたが、spec ワークフローがハーネス側に移ったとたん、Web 向けに作り直すこともなく Web に現れました。機能をエンジンの中で一度だけ作っておくことの見返りは、まさにここに出ます。できることが、たまたま最初に使ったエディターに縛られず、サーフェスをまたいで持ち歩けるようになります。

Kiro Mobile: 出先で使う Kiro

Kiro Mobile も Preview です。正直なところ、これは議論の余地がありません。あって当たり前のものです。エージェントをクラウドで実行できる開発ツールなら、スマートフォン向けのサーフェスは避けて通れません。いま力を発揮するのは、離れた場所から行う操作です。バックグラウンドエージェントの監視、結果のレビュー、アクションの承認、長く走っているタスクをひと押しして先に進めること。要するに、机に向かっていなくてもできることすべてです。一方、スマートフォンから手元のラップトップのローカルセッションにつなぐほうは、もっと難しく、まだ手つかずです。まずは見通しの立っているところから着手して、残りは進みながら解いていきます。

Kiro Crew: 外側のハーネス

Kiro Crew は、永続メモリ、スケジュールジョブ、非同期バックグラウンドエージェントといった機能をまとめたものです。いずれも「エージェントを動かす」の先、「スケジュールに沿って、自分が寝ている間にエージェントのクルーをまるごと動かす」という領域に踏み込んだ機能です。しかも、Kiro としては初のオープンソースアプリです。それでも、GA プロダクトに期待されるのと同じ品質・サポートの水準で扱っています。

では、実際には何をしてくれるのでしょうか。Crew は、自分でハンドルを握るのではなく、任せるための場所です。チケットキューを渡せば、トリアージして振り分けます。複数のリポジトリに散らばったインシデントを割り当てれば、こちらが修正に集中している間に調査を進めます。マイグレーションを走らせれば、会議中でも寝ている間でも、チェックポイントとリトライを挟みながら黙々と最後まで進めます。複数のエージェントを同時に動かし、好みや過去の修正をセッションをまたいで引き継ぐので、毎回ゼロから始めることにはなりません。同じ作業には、デスクトップアプリ、Web ダッシュボード、TUI、Slack のいずれからでもアクセスできます。

コードを書く場所が IDE、それをスクリプトにする場所が CLI だとすれば、Crew は、席を外している間もエージェントのクルーが作業を前に進めておいてくれる場所です。だからこそ向いているのは、エージェントを 1 つずつ手で操るよりも、問題に向けてエージェントの一団をまとめて差し向けたいパワーユーザーやフロンティア開発者です。ここで少し歴史の話を。Kiro Crew は、最初からこの名前だったわけではありません。何か月ものあいだ、社内では MeshClaw という名前で動いていました。チーム内で毎日徹底的に使い込まれた期間があったからこそ、そのまま社外に出すことができました。半年もしないうちに、Amazon のビルダー 39,000 人以上が使うようになり、そのうち 500 人近くが開発に参加しました（更新 597 件、週 143 コミット前後のペースです）。その頃にはもう実験の段階を抜けて、多くの人が仕事を進めるために頼る存在になっていました。

ここで、アーキテクチャについて正直に注記を 1 つ加えておきます。Kiro Crew を「アプリ」と呼ぶのは、少し雑な言い方です。実際には、Kiro エンジンを中核に据えた本格的なシステム拡張であり、それ自体が独自のアプリを備えています。Web アプリ、Slack、デスクトップアプリです。Crew の便利さを支えている部分の多くは、統合ハーネスの側ではなく Crew 自身に実装されています。常時稼働の自動化、マルチエージェントのオーケストレーション、セッションをまたいで残るメモリなどです。中には、ハーネスが別のやり方ですでに実現している機能と重なっているものもあります。話としてきれいにまとまる筋書きではありません。リリースの時期が来たとき、誰も触れないまま何か月もかけてすべてをハーネスへ分解し直すのではなく、アーキテクチャの原則からあえて外れて前に進めることを選びました。意図的な判断です。とはいえ、Kiro Crew を共通のアーキテクチャに寄せていく予定です。

結局、どれを選べばいい？

はい、知りたいのはそこですよね。実際にやろうとしていることを基準に、早見表をまとめました。

ここで、1 つ注目してほしいことがあります。どの答えも、やろうとしている作業を指しているだけで、「自分は何派か」という肩書きではありません。そして、ここが肝心なところです。特定のツールに愛着を持って落ち着く人が多いことは、私たちも分かっています。ですが、必ずしも 1 つに決めなければならないわけではありません。土台のエンジンは同じ、という話でしたね。デスクでは IDE を、パイプラインでは CLI を、電車の中では Mobile を、動かしっぱなしにしたい作業では Crew を使ってください。どれも同じハーネスを土台にしているので、全部を同時に使っても構いません。本当の問いは、そもそも「どのアプリを一生使うか」ではありませんでした。「この作業、この瞬間、この気分に、どのアプリか」です。

そして、私のように図で見たほうが分かりやすいという方は、こちらもどうぞ。ここまでの概念を 1 枚の図にまとめてみました。

各アプリと Kiro Crew は、1 つの共有ハーネスへと統合され、そのハーネスはさらにその下にあるプラットフォームサービス上に構築されています。

ですから、これさえあれば済む 1 つのアプリを探しに来た方には申し訳ないのですが、私たちが作ろうとしているのはそういう世界ではありません。作っているのは、できることが増えていく 1 つのエンジンに通じる、いくつもの玄関口です。それぞれの玄関口は違う人、違う場面に合わせて形を変えていて、どれも他を置き換えようとはしていません。（Kiro Crew は玄関口というより、家 1 軒に近い存在です。それでも、開いた先にあるのは同じエンジンです。）今日やろうとしていることに合う玄関口を選んでください。明日は別の玄関口を通るかもしれません。というより、それこそが狙いなのです。

いずれにしても、わくわくする時代です。

翻訳は Solutions Architect の吉村が担当いたしました。