10月末にKiro CLI V3がデフォルトに — V2セッションの行方と、新しい記憶機能の学習ソース（2026年）

V3は新しいものではありません。Kiroのブログ記事には「6月にオプトイン体験としてV3を導入した」とあり、現在は「すべての人に対してV3をデフォルトにする準備を進めている」と述べられています。プロンプトの表示は「10月末のCLI 3.0リリースの前に」10月12日から開始されました。また、同記事では「この展開はKiro CLIにのみ適用されます」と付け加えられています。

プロンプトでは以下の3つの選択肢が提示されます：

• Switch to V3 and upgrade my configs（V3に切り替えて設定をアップグレードする）: 「V3をデフォルトのハーネスとして保存し、エージェントの自動アップグレードを有効にし、ワークスペースおよびグローバルなカスタムエージェント設定の移行を開始します。」
• Remind me later（後で通知する）: ドキュメントによると、これは「このセッションをV2のまま維持し、約7日後に再度オファーを表示します」。
• Don't ask again（今後表示しない）: ブログでは、この選択肢を選んでもオプトアウトにはならないことが明記されています。これは「V2のまま維持されるわけではなく、10月末にCLI 3.0がリリースされた時点で、セットアップはV3にアップグレードされます。」

V2フラグを使用すれば、1回限りの起動でV2に戻すことができますが、「このフラグはその起動にのみ適用されます。」

CLI 3.0では、いくつかの機能も廃止されます。「CLI 3.0に伴い、インラインシェルの自動補完とCLIデスクトップアプリを廃止します。また、Classic体験も廃止し、新しい機能はターミナルUIに集中させます。」ドキュメントには、知っておくべきもう一つの違いが記載されています。「実験的な /checkpoint 機能はClassic限定のままです。V3では会話の分岐用に /rewind を提供します。」

Kiro CLIはすべてのセッションを自動的に保存します。セッションに関するドキュメントには、「会話のターンごとに行われるすべてのチャットセッションを自動的に保存する」とあり、セッションはディレクトリごとに保存されるため、プロジェクトごとに独自の履歴が存在します。

V3では、セッションが異なる場所に保存されます。移行ガイドには直接このように書かれています。「V3はV2とは異なるセッションストアを使用します。V3を試しても、既存のV2セッションが変換されたり削除されたりすることはありません。」また、それらに戻る方法も説明されています。「V2セッションに戻る必要がある場合」は、V2フラグとレジュームピッカーを指定してチャットコマンドを実行します。

逆方向の移行はできません。V3の概要には「保存されているセッション形式が異なるため、V2でV3セッションを開くことはできません。これはバージョン間の移行境界であり、V3のレジューム機能が欠けているわけではありません」とあります。破壊的変更の表では、セッション形式の変更が「影響度：高」とマークされています。

ここで、Kiroの情報源によって記述が異なっています。ローンチ時のブログ記事には「V3でV2セッションを再開できますが、V3で作成されたセッションをV2で再開することはできません」と書かれています。一方、移行ガイドでは、V2セッションは変換されず、それらに戻るにはV2フラグを使用するように案内されています。どちらも、V3セッションをV2に戻すことはできないという点では一致していますが、V2からV3への方向については説明が異なります。

これらは必ずしも矛盾しているわけではありません。V3専用のセッションダッシュボードでは、過去の作業を検索できます。「3文字以上のクエリでは、ローカルのV2およびV3のトランスクリプトからインデックス化されたセッションコンテンツも検索されます。」V3からV2セッションを見つけることと、それをV3で継続することは同じではない可能性があり、ドキュメントではブログがどちらを意味していたのか明記されていません。安全な解釈としては、移行ガイドの記述に従うことです。つまり、V2セッションはその場に留まり、V2を通じて読み取り可能であり、重要なセッションについては実際に試してみるまでV3で継続できると過信しないことです。

失うわけにはいかない会話について、移行ガイドは具体的なアドバイスを提供しています。「重要な会話の外部記録が必要な場合は、それを作成したハーネスで開き、/chat save <path> を実行してください。ターゲットのハーネスがそれをロードできることを確認するまでは、エクスポートされたファイルをアーカイブとして扱ってください。」

注目すべき言葉は「アーカイブとして」です。エクスポートされたセッションは、発言された内容を保存します。それ自体が自動的にそのコンテキストをエージェントの前に戻すわけではありません。

V3ではCLIに記憶（memory）機能が追加されます。Kiroの記憶に関するページでは、次のように簡潔に説明されています。「記憶機能により、Kiroはあるチャットセッションから次のセッションへと有用なコンテキストを引き継ぐことができます。」記憶できる内容には、「リポジトリのコマンドや規約、修正、デバッグの洞察、すでに除外されたアプローチ、および好みの作業方法」などがあります。

学習のソースを決定づける2つの条件があります。

V3が必要であること。 「Kiro CLIでの記憶機能にはV3が必要です。」ローンチ時のブログ記事では、「ローカルのV3セッションでの作業から」学習すると説明されています。ドキュメントにはV2セッションから学習するという記述はないため、そこでKiroに教えた内容は、自分で持ち込まない限り、それらのセッション内に留まります。

許可が必要であること。 memories コマンドを使用して、アクセスレベル（読み書き、読み取り専用、またはオフ）を選択します。「読み書き」のみがKiroによる変更を許可します。また、「記憶へのアクセス変更は、新しいKiro CLIセッションを開始したときに適用されます。」自動更新のオプションもあり、そのヘルプテキストには「セッション終了後を含め、記憶を自動的に作成および洗練する」とあります。ワークスペースの信頼（trust）による制限もあります。「read & write（読み書き）であっても、信頼していないワークスペースでは、Kiroは記憶を追加、変更、または削除することはできません。読み取りは可能です。」

保持されている内容を確認できます。記憶リストには各記憶のタイプ、スコープ、更新時間が表示されますが、「リストは読み取り専用です。記憶を修正または削除するには、チャットでKiroに依頼してください。」

記憶はルールに代わるものではありません。ドキュメントには「記憶は学習されたコンテキストを追加するものであり、現在の会話、Steering（ステアリング）、または参照資料に代わるものではありません」とあり、明確な指示が与えられています。「ルールを一貫して適用する必要がある場合は、Steeringに記述してください。」

もう一つの境界線として、記憶機能は現在のところCLIおよびWebの機能です。IDEについては、Kiroの記憶ページに「記憶機能のサポートは近日公開予定」と記載されています。

セッションと記憶は目に見える変更点です。それ以外にも、セッション開始時にエージェントが目にする内容を変える、いくつかの静かな変更があります。

Steeringのインクルージョンモードが完全に適用されるようになります。 KiroのSteeringページによると、「Kiro CLI V3は、always、fileMatch、manual、auto の4つのインクルージョンモードすべてをサポートしています。V1/V2では、always とマークされたファイルが自動的にロードされます。fileMatch または manual とマークされたファイルは自動ロードから除外されます。」切り替え後は、特定のパスにスコープしたSteeringファイルが、そのパスで作業するときにロードされるようになり、auto とマークされたファイルは、リクエストがその説明と一致したときにロードされます。このページの以前のバージョンでは、CLIのインクルージョンモードの説明が異なっており、IDEとCLIの間でSteeringファイルを分割するための以前のガイドはそのバージョンに基づいて書かれていました。現在の挙動に合わせて、Steeringのフロントマターを再確認してください。

AGENTS.mdの適用範囲が深くなります。 ローンチ時のブログ記事では、「AGENTS.mdファイルをリポジトリのルートだけでなく、サブディレクトリにも配置できる」と述べられており、Steeringページでも「ワークスペース全体のサブディレクトリで検出される」と確認されています。AGENTS.mdファイルはインクルージョンモードをサポートしておらず、常にインクルードされます。

カスタムエージェントはコンテキストフィールドを維持します。 アップグレードのドキュメントには、「その他のすべてのフィールド（name、description、model、prompt、resources、mcpServers、welcomeMessage）は変更されずに引き継がれます」とあります。Kiro'sのSteeringドキュメントには、関連するポイントが追加されています。「カスタムエージェントを使用する場合、Steeringファイルは自動的にはインクルードされません。Steeringコンテキストをロードするには、エージェントの resources 設定に明示的に追加する必要があります。」このルールはアップグレード後も適用されます。

一部のフックは移行されません。 ブログには「変換できないフックはV3設定から除外され、警告として報告されます」とあります。フックの移行ページによると、コンバーターは「V3で表現できないフックをドロップし、無効なプロファイルを作成する代わりに警告を報告します。」エージェント起動時にプロジェクトのコンテキストを注入するためにフックを使用していた場合は、それが SessionStart フックとして引き継がれているか確認してください。ドロップされたコンテキストフックがあってもKiroの動作は停止しませんが、そのコンテキストは存在しなくなります。

手動での編集が上書きされる可能性があります。 これは、慎重なユーザーが最も陥りやすい罠です。「生成されたV3フィールドを手動で編集すると、Kiroはそれらの自動更新を停止します。」その後、エージェントは同期ズレとして表示され、「そのグループを選択すると、V2設定からV3が再構築され、手動で行ったV3の編集が上書きされます。」Kiroは実行時にバックアップを保持しますが、チューニングを始める前に知っておく価値があります。

「Don't ask again」を選べばV2のまま維持されるという誤解。 プロンプトは停止しますが、CLI 3.0ではいずれにせよセットアップがアップグレードされます。

V3がV2の続きから始まると想定すること。 新しいセッションは、Steering、AGENTS.mdファイル、およびV3が学習した記憶（これはV3での作業から始まります）から開始されます。

エクスポートされたセッションがコンテキストを復元するという誤解。 Kiroは、ターゲットがロードできることを確認するまでは、それをアーカイブとして扱うよう求めています。

記憶がSteeringに代わるという誤解。 Kiroは、一貫して適用する必要があるルールはSteeringに属するとしています。

アップグレードですべてのフックが引き継がれるという誤解。 変換できないフックは警告とともに対象外となります。

ステップ 1: 引き続き依存しているV2セッションをクローズする

プロジェクトごとに最近のV2セッションをリストアップし、未完了の作業や、再構築が困難な決定事項が含まれるセッションを選択します。可能であれば、それらをV2で完了させてください。残りのセッションについては、移行ガイドの推奨に従い、V2から chat save コマンドを使用して外部コピーを保存し、切り替える前にKiroのホームディレクトリのコピーを保管しておきます。Kiroの権限ページでは、デフォルトのセッションストアとして ~/.kiro/sessions/、記憶データベースとして ~/.kiro/memories/ が指定されています。

そして、それらのセッションから結論（決定事項、除外したアプローチ、合意した規約）を抽出します。これらは、Kiroのドキュメントにおいて、V3の記憶がV2から引き継ぐとは記載されていない部分です。

ステップ 2: ドライランでエージェントをアップグレードし、すべての警告を確認する

チームでリポジトリ内にエージェントを管理している場合は、まずディレクトリのアップグレードをプレビューします。Kiroの記事によると、dry-run オプションを付けて実行することを推奨しており、アップグレードページには、ドライランは「何が変更されるかを報告し、変換の警告を含める」とあります。その後、各ファイルをバックアップするアップグレードを実行し、診断を開きます。

特に、ドロップされたフックや、Steeringまたはナレッジファイルを指す resources エントリがないか確認してください。V3では fileMatch や auto ファイルの挙動が変わるため、Steeringファイルのインクルージョンモードを確認します。同期ズレによる再構築を理解するまでは、生成されたフィールドを手動で編集することは避けてください。コーディングエージェントが起動時にどのファイルを読み込むかについて詳しく知りたい場合は、コーディングエージェントが実際に読み込むものに関するガイドを参照してください。

ステップ 3: 記憶機能を意図的に有効にし、ルールはSteeringに維持する

設定されている値をそのまま受け入れるのではなく、記憶のアクセスレベルを自分で選択してください。「読み書き」はKiroに学習を許可し、「読み取り専用」は変更を加えることなく既存の記憶を使用できるようにします。記憶を蓄積させたいワークスペースを信頼（trust）してください。

そして、常に維持すべきルールはSteeringまたはAGENTS.mdに移動します。記憶はKiroが学習するためのものであり、Steeringはあなたが決定するためのものです。以前にルールが無視されたことがある場合は、エージェントが指示ファイルを無視する理由に関するガイドで一般的な原因を解説しています。

バージョンの変更は、プロジェクトのコンテキストがどれほど1つのツールのセッションストアに依存していたかに気づく良い機会です。MemoryLakeは、作業の背景にある決定事項を1つの管理リストに保持し、Kiroや他の使用しているアシスタントから利用できるようにする記憶レイヤーです。

エントリーは、あなた自身の言葉で自分で記述します。Kiroのセッション、Kiroの記憶データベース、Steeringファイル、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。会社のコードで作業する場合は、プロジェクトの詳細を他の場所にコピーする前に、組織のポリシーを確認してください。

ステップ 1: APIキーを作成する

サインインし、ダッシュボードからキーを生成します。このキーはMemoryLakeワークスペースに属し、KiroやAWSのアカウントとは異なります。

ステップ 2: 最初の記憶をアップロードする

ステップ1でV2セッションから抽出した決定事項、除外したアプローチ、規約から始めます。1つのエントリーにつき1つの項目を、日付と理由を添えて登録します。

ステップ 3: AIとエージェントを接続する

Kiroや、その他に使用しているアシスタントを接続します。これにより、V3の記憶機能が再学習するのを待つことなく、最初のセッションからV3や他のツールで同じ決定事項を利用できるようになります。

第一の違いは、切り替えがギャンブルではなくなることです。どのセッションに戻ることができるか、その方法、およびどのセッションをすでに要約したかを把握できます。

第二に、V3での最初の1週間がよりスムーズになります。記憶が蓄積されるまでの間、Steering、AGENTS.md、および独自のメモがV3セッションの開始点を提供します。他のツールでも、バージョンアップデートで同様の静かなコンテキストの変更が行われてきました。Clineのサイレントコンテキスト修正に関する考察はその一例です。

第三に、アップグレード自体による予期せぬトラブルが減少します。ドロップされたフックや変更されたインクルージョンモードは、実際の作業中ではなく、ドライラン中に発見されます。

第四に、ポータビリティ（移植性）です。後で一部の作業を別のエージェントに移行する場合（KiroからClaude Codeへの移行ガイドで解説しています）、決定事項はどちらのツールのセッション形式にも依存しません。

「Don't ask again」を過信しないこと。 いずれにせよCLI 3.0でアップグレードが実行されます。

事前にKiroのホームディレクトリをバックアップすること。 セッションと記憶はそこに保存されています。

重要なV2セッションはV2で完了させること。 その後、それらを要約します。

エージェントのアップグレードはドライランを行うこと。 適用する前にすべての警告を確認してください。

Steeringのフロントマターを再確認すること。 V3ではインクルージョンモードが完全に適用されます。

記憶のアクセス権を意図的に設定すること。 そして、意図したワークスペースのみを信頼してください。

ルールはSteeringに維持すること。 SteeringとPowerがどのようにコンテキストを分割するかについては、KiroのPowerとSteeringの間でコンテキストをルーティングするためのガイドを参照してください。

Kiro CLI V3は、2026年10月末のCLI 3.0リリースに伴いデフォルトになります。「Don't ask again」を選択してもV2のまま維持されるわけではありません。V3は新しいセッションストアを使用します。V3セッションをV2で開くことはできません。KiroのブログではV2セッションをV3で再開できるとされている一方、移行ガイドではそれらは変換されず、開くにはV2に戻るよう案内されているため、どちらの解釈を信頼するかは、重要なセッションで実際にテストして確認してください。

また、V3ではCLIに記憶機能が導入されます。Kiroは、これがローカルのV3セッションから学習し、アクセス権はユーザーが制御するものと説明しており、ドキュメントにはV2から学習するとは記載されていません。

期限が来る前に、依存しているV2セッションをクローズし、警告を確認しながらエージェントをアップグレードし、残しておきたい決定事項はバージョンの変更によって失われない場所に書き留めておきましょう。