【VSCode】Amazon Q → Kiro の移行、ずっと後回しにしてたけど30分で終わった話

はじめに

Amazon Q 拡張機能のサポート終了アナウンスがでてくるようになりました。

「Kiro に移行してね」というやつです。

わかってはいたんですが、ずっと後回しにしてました。理由は4つ。

• 新しい IDE に慣れるのが面倒くさそう
• .amazonq/rules/ にファイルが溜まってて、全部書き直しになるかと思ってた
• まだ 2027 年まで時間あるからいいかな
• 拡張機能が全滅するんじゃないか

で、ぎりぎりですが 5/14 の今日、ようやく重い腰を上げてやってみたら、体感30分で終わりました。

同じ理由で後回しにしてる人に向けて書きます。

Kiro って何？（1分で理解する）

VS Code をフォークして作った AI IDE です。Cursor なんかと同じ立ち位置。

Amazon Q 拡張機能でやってたこと（インライン補完・チャット・コード生成）は全部 Kiro でもできます。
それに加えて Spec-Driven Development という機能が乗っかっています。

Vibe Coding との違い

Kiro のドキュメントにはこう書いてあります。

Developing with specs keeps the fun of vibe coding, but fixes some of its limitations

「Vibe Coding の楽しさを残しつつ、本番に出せるコードにする」というコンセプトです。

Spec セッションは requirements.md → design.md → tasks.md の3ファイルを生成して、AI が段階的に実装を進める構造化されたフロー。
Vibe セッションは従来通りの自由なチャット。

	Vibe Coding	Spec-Driven
やり方	「これ作って」と投げる	要件 → 設計 → タスクの順に構造化
向いてる場面	小さなプロトタイプ	複雑な機能、大規模コードベース
リスク	複雑なタスクで迷子になりやすい	最初の仕様作成に時間がかかる

もともと自分は Kiro は Spec セッションだけだと勘違いしてたんですが、両方使えるようです。

実際にやった移行手順

1. Kiro をインストールする

kiro.dev からIDEをダウンロードし、設定を進めていきます。

私の場合、誤って最初の起動時にプロファイルのインポートをスキップしてしまったので、公式の VS Code 移行ガイド に則り、作業を進めていきます。
（Amazon Q からの移行全般については こちら）

VSCodeからプロファイルをエクスポートしておきます。

Kiroでプロファイルをインポートし、アクティベートしてIDEを再起動します。

すると、各拡張機能がインストールされた状態になりました。

Open VSX 互換の拡張機能はそのまま使えます。
Microsoft Marketplace 専用の拡張機能は使えない場合があるので、必須の拡張機能があれば事前に確認しておくと安心です。
https://open-vsx.org

2. 使ってた拡張機能を確認する

「拡張機能が全滅するんじゃないか」というのも後回しにしてた理由のひとつでした。

ところが手順１で設定ファイルをインポートしたため Kiro を起動したら、拡張機能がインストールされています。

実際に使ってたものを確認してみた結果がこちらです。

AI

拡張機能	Open VSX	備考
Amazon Q	✅ 使えるけど不要	Kiro に AI 機能が内蔵されているので不要です。拡張機能からアンインストールしましょう。

AWS / IaC

拡張機能	Open VSX	備考
AWS CDK Snippets	✅ 使える	Open VSX に掲載あり
AWS CloudFormation Snippets	✅ 使える	Open VSX に掲載あり
CloudFormation	✅ 使える	Open VSX に掲載あり
CloudFormation Linter	✅ 使える	Open VSX に掲載あり
Draw.io Integration	✅ 使える	Open VSX に掲載あり

リモート開発

拡張機能	Open VSX	備考
Remote - SSH	❌ 使えない	Microsoft 製プロプライエタリ。SSH でリモート接続したい場合は Open Remote - SSH が互換版として Open VSX にあり
WSL	❌ 使えない	Microsoft 製プロプライエタリ。Windows から WSL 内のファイルを開きたい場合は Open Remote - WSL が互換版として Open VSX にあり

Windows 上の Kiro から WSL 内のファイルを開いて編集しているだけなら、Open Remote - WSL を入れるだけで SSH の設定は不要です。

Git / CI

拡張機能	Open VSX	備考
Git History	✅ 使える	Open VSX に掲載あり
GitHub Actions	✅ 使える	Open VSX に掲載あり

Markdown

拡張機能	Open VSX	備考
Markdown All in One	✅ 使える	Open VSX に掲載あり
Paste Image	✅ 使える	Open VSX に掲載あり

エディタ / 表示

拡張機能	Open VSX	備考
Error Lens	✅ 使える	Open VSX に掲載あり
indent-rainbow	✅ 使える	Open VSX に掲載あり

言語サポート

拡張機能	Open VSX	備考
PowerShell	✅ 使える	Open VSX に掲載あり（Microsoft 製とは別の互換版）

「全滅」ではありませんでした。
特に痛いのは Remote - SSH / WSL で、VSCode用の拡張機能のため Open VSX に出てきません。
ただしどちらも Open VSX に互換版があるので代替できます。

2-1. WSL を使っている場合の追加設定

Windows 上の Kiro から WSL 内のファイルを開きたい場合、Open Remote - WSL を入れるだけでは動きません。argv.json に設定を追加する必要があります。

コマンドパレット（Ctrl+Shift+P）で Preferences: Configure Runtime Arguments を実行して argv.json を開き、以下を追加します。

{
    "enable-proposed-api": [
        "jeanp413.open-remote-wsl"
    ]
}

既存の項目の末尾にカンマを忘れると JSON のパースエラーになります。
前段の行末に , があることを確認してください。

追加後に Kiro を再起動すると、コマンドパレットから Connect to WSL が動くようになります。

拡張機能をWSLにインストールするのを忘れないようにしましょう。

3. .amazonq/ ディレクトリを移行する

ここが一番の懸念点でした。.amazonq/rules/ にルールファイルが溜まっていたので、全部書き直しになるかと思っていたんですが、コピーするだけでした。

Kiro では .amazonq/rules/ に相当する機能が Steering という名前になり、.kiro/steering/ に置きます。

mkdir -p .kiro/steering
cp -r .amazonq/rules/. .kiro/steering/

以上です。サブディレクトリがある場合も -r で一括コピーできます。

Kiro CLI（ターミナル版）であれば .amazonq/ をそのまま検出して読み続けるため、コピー不要です。
IDE 版（Kiro IDE）は .kiro/steering/ への移行が必要です。

4. Steering ファイルの適用タイミングを設定する

Amazon Q の rules/ はすべてのチャットに自動適用されていましたが、Kiro の Steering には4種類の適用モードがあります。

モード	フロントマター	動作
Always	inclusion: always	デフォルト設定。毎回自動で AI に渡される
Auto	inclusion: auto + description:	description の内容に合致するリクエストのとき自動で渡される
fileMatch	inclusion: fileMatch + fileMatchPattern:	glob パターンに一致するファイルを編集しているときだけ渡される
Manual	inclusion: manual	#ファイル名 で明示的に参照したときだけ渡される

デフォルト設定で、Amazon Q の rules/ と同じ挙動になるため、自分は特に変更せずそのままにしましたが、用途に応じて使い分けるとコンテキスト量を節約できます。

# TypeScript ファイルを編集するときだけ渡す
---
inclusion: fileMatch
fileMatchPattern: "**/*.ts"
---

# API 設計の話題のときだけ自動で渡す
---
inclusion: auto
name: api-design
description: REST API の設計・実装に関するリクエストのとき
---

まとめ

30分かかったとはいえ、内訳はこうです。

作業	時間の目安
Kiro インストール + VSCode プロファイルインポート	5分
拡張機能の互換性確認	15分
WSL の追加設定（argv.json 編集 + 動作確認）	10分

.amazonq/rules/ の移行は cp 一発なので時間にカウントするまでもありません。

WSL を使っていない人なら実質15〜20分で終わります。拡張機能の調査も、この記事の表を参考にすれば省略できます。

後回しにしてる人はさっさとやってしまいましょう。

参考

• Migrating from Amazon Q Developer - Kiro Docs
• Migrating from VSCode - Kiro Docs
• Steering - Kiro Docs
• Vibe vs Spec sessions - Kiro Docs
• Amazon Q Developer end-of-support announcement

---

移行してみて、Spec-Driven Development がどこまで実用的か気になっています。
Vibe Coding との使い分けも含めて、実際に使いながら試していこうと思います。