amazon-q-developer-cli は保守終了、Kiro CLI へ移行すべきかの判断材料
✨ Agentic chat experience in your terminal. Build applications using natural language.
ひと目でわかる
- これは何？
- AWS のターミナル向けエージェント CLI を、いま新規導入すべきか。README が明示する保守終了の告知と、Kiro CLI への移行という事実を軸に、採用判断の境界を整理する。
- 誰に向いている？
- 新規に採用する理由はほぼない。README が「no longer being actively maintained」と明記し、critical security fixes 以外は受け取らないとしているため、これからターミナル型エージェントを評価するなら Kiro CLI 側の条件を先に確認すべきである。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 22 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
README の先頭に置かれた保守終了の告知
このリポジトリを評価するとき、最初に読むべきは機能一覧ではなく README 冒頭の警告ブロックである。そこには、このオープンソースプロジェクトが「no longer being actively maintained」であり、受け取るのは critical security fixes のみだと書かれている。同時に、Amazon Q Developer CLI は Kiro CLI として提供されており、そちらは closed-source product であること、最新機能と更新は Kiro CLI を使うべきこと、Kiro CLI の問題は別のリポジトリへ報告すべきことが示されている。
つまりこれは、機能が未完成だから止まったプロジェクトではない。後継製品へ役割を移して、オープンソース側の開発を畳んだという性格の停止である。Rust で書かれた CLI のコードは残り、ライセンスも有効なままだが、上流が新機能を入れる意思を持っていない。採用検討の出発点はここに固定される。
誰のためのツールだったのか、ターミナルで自然言語からアプリを組む
説明文は「Agentic chat experience in your terminal」とうたっている。狙いは、エディタやブラウザを開かず、シェルの中だけで自然言語による指示からアプリケーションを組み立てる作業を完結させることにある。トピックとして agent、llm、mcp、shell、terminal が並んでおり、MCP（Model Context Protocol）経由で外部ツールをエージェントに渡す使い方を想定していたことが読み取れる。
対象は、SSH 先のマシンや CI のコンテナなど、GUI を持ち込めない環境で作業する開発者である。macOS と Linux のビルドが案内され、Windows 向けの記述は README には見当たらない。デスクトップアプリとしての配布（DMG、Homebrew cask、AppImage）と、crates 以下の Rust クレートという二つの入口が用意されている点も、単なる CLI ではなくターミナル統合を意識した作りだと言える。
chat_cli クレートと crates 分割という構成
リポジトリの構成は README の Project Layout に列挙されている。chat_cli クレートが q コマンド本体で、Amazon Q Developer をコマンドラインから操作する入口になる。scripts には運用とビルド用のスクリプト、crates には Rust クレート群、docs には技術ドキュメントが置かれている。
機能が単一バイナリに詰め込まれているのではなく、クレートに分割されている点は、この種のツールとしては素直な設計である。エージェントの会話ループ、シェル統合、MCP の扱いをそれぞれ別クレートに切れば、テストも差し替えも効く。ただし README は各クレートの責務までは説明していない。どのクレートを読めば MCP の実装に到達できるかは、docs ディレクトリの中身を自分で確認する必要がある。ここは documentation が薄い部分だと正直に言っておく。
ソースから動かすまでの手順
README が示す開発手順は明快である。まずリポジトリを取得する。
git clone https://github.com/aws/amazon-q-developer-cli.git
次に Rust ツールチェーンを Rustup で入れる。
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh rustup default stable rustup toolchain install nightly cargo install typos-cli
ビルドと実行は cargo run --bin chat_cli、テストは cargo test、lint は cargo clippy、整形は cargo +nightly fmt である。nightly を要求するのは整形のみで、ビルド自体は stable で通る想定になっている。ログインはサブコマンドとして渡す。
cargo run --bin chat_cli -- login
macOS で開発する場合の前提として Xcode 13 以降と Brew が挙げられている。Linux のビルドは Ubuntu/Debian、AppImage、その他の alternative builds へのリンクという形で、手順そのものは README ではなく AWS のドキュメント側に置かれている。設定ファイルのパスや環境変数の一覧は README には載っていないため、認証や MCP サーバーの登録方法は docs と AWS ドキュメントを当たることになる。
保守終了が意味する実務上のコスト
停止したプロジェクトを動かし続けるコストは、バグ修正の不在だけではない。依存する Rust クレートの更新が止まるため、cargo update をかけたときに壊れる箇所を自分で直す前提になる。cargo clippy や cargo +nightly fmt が要求するツールチェーンの版が上がれば、古いコードが新しい lint に引っかかる可能性もある。
セキュリティ面では、critical security fixes は受け取れると README が明言している。ただしそれは「脆弱性が報告され、上流が critical と判断したものだけが直る」という意味であり、機能追加も非クリティカルな修正も来ない。新しく見つかった不具合を自分で直して pull request を送っても、取り込まれる保証はない。フォークして自前で保守する道は残るが、それはもうこのリポジトリを使っているとは言えない。
ライセンスは MIT と Apache 2.0 のデュアルライセンスで、LICENSE.MIT と LICENSE.APACHE の両方が置かれている。フォークして改変、再配布する余地はライセンス上確保されている。ただし AWS の商標に関する記述があり、ロゴやサービス名を自前の製品名に使うことは許されない。ここは法務判断の領域なので、実際の利用条件は自組織の法務に確認してほしい。
Kiro CLI という後継と、移行時に確かめるべき差分
現実的な代替は Kiro CLI である。README 自身がそう案内しており、Amazon Q Developer CLI は Kiro CLI として提供されていると書かれている。両者の違いは機能の多寡ではなく、公開のされ方にある。amazon-q-developer-cli は Rust のソースが公開され、ビルド手順もテスト手順も README に載っている。Kiro CLI は closed-source product であり、ソースを読むことも自分でビルドすることもできない。
この差は、内部の挙動を検証したいチームにとって決定的である。エージェントがどの順序でツールを呼び、どのファイルを読んだかをコードレベルで追いたいなら、公開リポジトリの方が都合がよい。逆に、検証より継続的な更新を優先するなら、閉源でも Kiro CLI を選ぶ理由がある。README は Kiro CLI の設定形式や MCP 対応の互換性については何も述べていない。同じ MCP サーバー定義がそのまま動くのか、認証のやり直しが要るのかは、この材料からは判断できない。
それでも q を残す判断が成り立つ場合
すべてのチームが即座に移るべきだという結論にはならない。すでに q を日常のワークフローに組み込み、MCP サーバーの定義やプロファイルを ~/.aws/amazonq 配下に蓄積しているなら、その設定は動く資産である。README の手順どおりに cargo run --bin chat_cli -- login で認証が通り、cargo test が通る環境が手元にあるなら、明日動かなくなるわけではない。
残す判断が成り立つのは、次の条件を満たす場合だ。ターミナル内で完結するエージェント作業が中心で、上流の新機能を必要としていない。依存クレートの更新を自分で面倒を見る余力がある。そして、Kiro CLI への移行を検討した結果として、設定の持ち込みが難しい、あるいは閉源では検証要件を満たせないという理由で見送っている。逆に、これから新しくエージェント CLI を評価する段階なら、停止済みのリポジトリを選ぶ理由は見当たらない。Kiro CLI のドキュメントを先に読む方が早い。
移行するにせよ残すにせよ、最初にやることは同じである。手元の MCP 設定とプロファイルを書き出し、Kiro CLI 側で同じキーが受け付けられるかを突き合わせる。その結果が出るまで、q の上に新しい自動化を積み増さないこと。積み増した分だけ、後で移す荷物が増える。
編集部の結論
新規に採用する理由はほぼない。README が「no longer being actively maintained」と明記し、critical security fixes 以外は受け取らないとしているため、これからターミナル型エージェントを評価するなら Kiro CLI 側の条件を先に確認すべきである。逆に、既に q を業務フローに組み込み、MCP 設定やプロファイルを資産として持っているチームは、すぐに捨てる必要はない。判断の分かれ目は、その設定ファイルを Kiro CLI にそのまま持ち込めるかどうかで、これは README からは確認できない。まず手元の ~/.aws/amazonq 配下の設定と MCP サーバー定義を書き出し、Kiro CLI のドキュメントで同じキーが受け付けられるかを突き合わせる。突き合わせが終わるまでは、新しい自動化を q の上に積まないこと。
コミュニティノート