Amazon Web Services ブログ
Kiro CLI V3 をデフォルトのエクスペリエンスとして順次展開します
Kiro CLI V3 は、Kiro IDE と Kiro Web を動かしているものと同じエージェントハーネスをターミナルで使えるようにします。V3 では、計画・実装・レビューが必要なタスクを Kiro に渡し、workflow のエージェントがバックグラウンドで各ステップを進めている間も、ご自身は作業を続けられます。クラウドセッションを開始すれば、ノート PC を閉じても作業は止まりません。新しい spec モードでは、Kiro がコードを書き始める前に要件と設計を Kiro と一緒にレビューできます。新しい tangent モードを使うと、メインセッションのコンテキストに影響を与えずに、並行する会話へ分岐できます。
V3 は 6 月にオプトインのエクスペリエンスとして提供を開始し、その後も新しい機能を追加してきました。オプトインしたお客様に新機能をご活用いただいており、今回 V3 をすべてのユーザーのデフォルトにする準備を進めています。10 月 12 日から、10 月末の CLI 3.0 リリースに先立って V3 への切り替えを案内する起動時のプロンプトを順次展開します。プロンプトがすぐに表示されない場合もありますが、kiro-cli --v3 でいつでも V3 を試せます。今回の展開の対象は Kiro CLI のみです。
ほとんどのユーザーは、切り替えにあたって設定を変更する必要はありません。エージェント、権限、連携をカスタマイズしている場合は、Kiro が自動で移行する内容と確認が必要な内容を以降のセクションで説明します。CLI 3.0 では、シェルのインライン自動補完と CLI デスクトップアプリを廃止します。また Classic エクスペリエンスも廃止し、新しい機能はターミナル UI に集中して開発していきます。
V3 でできること
V3 には引き続き新機能を追加しています。最近のリリースから主なものを紹介します。
ノート PC を「起こしたまま」にする工夫をしなくても、ノート PC を閉じた後も作業を続けられるようになりました。kiro-cli --cloud でクラウドセッションを開始してリポジトリを紐付ければ、Kiro がマネージドなクラウドサンドボックスで作業します。接続を切ってもエージェントは作業を続け、別のマシンからセッションを再開できます。組織で IAM Identity Center を使っている場合は、先に管理者がクラウドセッションを有効にする必要があります。なお、クラウドセッションは現時点では米国東部 (バージニア北部) us-east-1 でのみ動作します。
新しいメモリ管理により、Kiro がチャットセッションをまたいでコンテキストを学習できるようになりました。Kiro はローカルの V3 セッションでの作業から、リポジトリのコマンドや規約などの有用なコンテキストを学習し、後のセッションで呼び出します。同じことを何度も説明する必要はありません。Kiro が覚えている内容は /memories で管理できます。
IDE の spec モードが CLI でも使えるようになりました。実装の前にアプローチをレビューできます。Kiro がコードを書き始める前に、要件と設計を Kiro と一緒に詰められます。ドキュメントにインラインコメントを付けたり、実行するタスクを選んだりする操作も、すべてターミナルから行えます。/spec new から始めてください。
CLI V1 で実験的機能として最初に導入した /tangent を改良して復活させました。メインセッションのコンテキストに影響を与えずに、脇道のスレッドを探索できます。tangent は特に要望の多かった機能のひとつで、V3 で再び提供できることを嬉しく思います。
セッションの数が増えるにつれて、目的のセッションを見つけるのは干し草の山から針を探すように難しくなっていました。そこで新しい /sessions ペインを追加しました。セッションの一覧表示、ブックマーク、名前の変更などができ、セッション管理が簡単になります。
複雑な複数ステップの作業を、ローカルでもクラウドでも workflows に任せられます。Kiro にタスクを渡すと、workflows がエージェントを協調させて計画・実装・レビューを進めます。各ステップは新しいコンテキストを持つ独立したセッションで実行されるため、レビュアーがコーディングエージェントの推論を引き継ぐことはありません。workflow をバックグラウンドで実行している間もメインのチャットで作業を続けられ、必要に応じて軌道修正や一時停止ができます。workflows はオプトインの機能なので、初回の実行前に設定で有効にしてください。
セットアップの再利用もしやすくなりました。グローバルなフックを使うと、同じ自動化を複数のワークスペースで使えます。さらに、AGENTS.md ファイルをリポジトリのルートだけでなくサブディレクトリにも置けるようになり、プロジェクトの部分ごとに Kiro への指示を分けられます。たとえば、あるディレクトリにはフロントエンドの規約を、別のディレクトリにはバックエンドのテスト手順を置けます。
Kiro 全体でひとつのハーネス
Kiro CLI V3 は、Kiro IDE と Kiro Web を動かしているものと同じエージェントハーネスをターミナルで使えるようにします。ハーネスがツール、コンテキスト、権限、モデルとのやり取りを受け持ち、各クライアントはそれぞれのインターフェースを持ちます。
ユーザーにとっては、ハーネスに組み込んだ機能を後から移植するのではなく、他のクライアントと同時にターミナルにも届けられるということです。最近の workflows のリリースがその一例で、すべてのクライアントで同時に公開しました。共通のハーネスによって、クライアント間で設定と権限のモデルも共通になるため、リポジトリの .kiro/ 設定を複数のクライアントで使い回せます。各クライアントがサポートする内容にはまだ違いがあり、CLI の現在のサポート状況は V3 のドキュメントに記載しています。
ひとつのエージェントハーネスを作った理由もあわせてご覧ください。
早期アクセスから学んだこと
V3 は 6 月からオプトインで提供してきました。早期アクセスでいただいたフィードバックから、エージェントハーネスを切り替えるたびにセットアップを作り直すべきではないという考えが強まりました。エージェント、権限、慣れたワークフローはそのまま持ち越せる必要があります。この考えが移行体験の設計につながりました。
私たちは、既存の V2 の設定を保持したまま V3 に必要な設定を追加する「ユニバーサル設定」形式を定めました。移行ツールはカスタムエージェントをこの形式に更新し、元の設定をバックアップし、サポートされている設定を自動で変換したうえで、確認が必要な項目を知らせます。
切り替えの流れ
V3 の展開期間中、Kiro CLI は起動時に切り替えを案内するプロンプトを表示します。選択肢は 3 つです。
- Switch to V3 and upgrade my configs: V3 をデフォルトのハーネスとして保存し、エージェントの自動アップグレードを有効にして、ワークスペースとグローバルのカスタムエージェント設定の移行を開始します。
- Remind me later: 切り替えを先送りし、後でまたプロンプトを表示します。
- Don’t ask again: プロンプトの表示を止めます。これで V2 に留まれるわけではなく、10 月末に CLI 3.0 がリリースされた時点でセットアップは V3 にアップグレードされます。
今すぐ切り替えたい場合は、プロンプトを待つ必要はありません。kiro-cli --v3 を実行すると、新しいセッションで V3 を試せます。V3 をデフォルトとして保存するには、次のコマンドを実行します。
kiro-cli settings chat.agentEngine v3
すでに V3 をお使いの場合は、10 月末の CLI 3.0 の展開で V3 がデフォルトになった後は --v3 フラグを付ける必要がなくなります。
V2 に戻す必要がある場合は kiro-cli --v2 を実行します。このフラグはその起動時にのみ適用されます。V2 のセッションは V3 で再開できますが、V3 で作成したセッションを V2 で再開することはできません。
切り替える前に
ほとんどのユーザーは、切り替えにあたって設定を変更する必要はありません。セットアップをカスタマイズしている場合に向けて、自動で引き継がれる内容と確認が必要な内容を説明します。以降のセクションでは、自動補完と Classic の廃止、ACP 連携の変更点についても取り上げます。
カスタムエージェント
移行プロンプトを承認すると、Kiro は元の設定をそれぞれ <name>.json.bak としてバックアップし、既存の V2 の設定を保持したまま V3 に必要な設定を追加します。プロンプト、モデルの選択、リソース、MCP サーバーの定義はそのまま引き継がれます。
移行ではサポートされているフックも変換します。変換できないフックは V3 の設定から除外され、警告として報告されます。警告を確認し、該当するフックを手動で更新してください。元の設定はバックアップに残っています。移行を自分で実行したりやり直したりするには、/upgrade-agent を使います。
チームでエージェントを中央のリポジトリで管理している場合は、v2.29 以降で kiro-cli agent upgrade <dir> を使ってディレクトリ全体を一度にアップグレードできます。まず --dry-run を付けて実行し、変更内容と警告を事前に確認してください。書き換えるのは V2 形式のままのエージェントだけで、すでに V3 のセクションを持つエージェントは変更しません。
カスタム権限
V2 では信頼済みツールのリストとツールごとの設定を使っていました。V3 では、シェルコマンドやファイルパスといったアクションとリソースに対するルールを使います。ルールが重なった場合は、スコープに関係なく deny が ask より、ask が allow より優先されます。
移行ではサポートされている設定を変換しますが、確認や手動での置き換えが必要なパターンもあります。移行後は /upgrade-agent diagnostics を実行し、移行したルールに頼る前に変換時の警告に対処してください。
--trust-all-tools は V3 でも引き続きサポートされます。個々の設定が新しいモデルにどう対応するかは、権限の移行ガイドで説明しています。
use_aws を使っているエージェント
V3 には use_aws ツールがありません。AWS CLI のコマンドはシェルツールを通じて実行され、シェルの承認ルールに従います。
use_aws の allow と deny の設定は、シェルの権限ルールとして作り直してください。継続的に承認したいコマンドは、プロンプトが表示されたときに「Always allow」を選ぶこともできます。aws * のような広いパターンを許可せず、ルールは具体的に保ってください。移行の手順は権限のガイドを参照してください。
自動補完
シェルのインライン自動補完と CLI デスクトップアプリは廃止され、CLI 3.0 の展開以降は利用できなくなります。
Classic
Classic は V3 ではサポートされず、段階的に廃止します。新しい機能はターミナル UI で開発しています。
TUI に切り替えるには、エイリアスやショートカットから --classic を外して kiro-cli を起動してください。
ACP クライアント
エージェント設定の移行では、ACP 連携は更新されません。クライアント側の変更については ACP の移行ガイドに従い、V3 の ACP サーバーは kiro-cli acp --agent-engine=v3 で起動してください。
通常の CLI をターミナルで使っているユーザーは、この手順を省略できます。
今すぐ V3 を試す
V3 への切り替えを案内する起動時のプロンプトを順次展開していきます。10 月末の CLI 3.0 リリースまでに切り替えを承認して新機能を試し、セットアップで確認が必要な点に対処しておくことをお勧めします。
次のタスクはぜひ V3 で実行してみてください。タスクを workflow に任せる、spec をレビューする、席を外している間もクラウドセッションに作業を続けさせる、といった使い方ができます。セットアップ方法と現在のサポート状況は V3 のドキュメントにまとめています。うまくいったことや困ったことは、/feedback または Discord でお知らせください。展開の進み具合は CLI の changelog でご確認いただけます。
本記事は 2026 年 10 月 9 日に公開された Pooja Giri、Jay Raval による Kiro CLI V3 is rolling out as the default experience を翻訳したものです。