ページの先頭です

ページ内を移動するためのリンク
本文(c)へ

ここから本文です。

Kiroとは?AWSのAI開発プラットフォームの特徴・使い方・Amazon Q Developerからの移行について解説

Kiroとは?AWSのAI開発プラットフォームの特徴・使い方・Amazon Q Developerからの移行について解説

Kiroは、AI 統合開発環境(Agentic AI IDE) をはじめとする、AWS提供のAI開発プラットフォームです。Kiro IDE、Kiro CLI、プレビュー提供中のKiro Webを通じて、要件や設計を仕様として整理し、タスク単位で実装へつなげられる点に特徴があります。

生成AIを使えば、コードを書く速度は上がります。一方で、要件が曖昧なまま実装が進む、設計意図が残らない、生成コードの保守性をどう確保するかといった課題もあります。Kiroは、SpecやHookなどの機能によって、AI開発をその場限りのコード生成ではなく、仕様を起点に進める開発プロセスへ組み込みます。

この記事では、Kiroの概要、主な機能、使い方、料金、Amazon Q DeveloperからKiroへの移行背景、CursorやClaude Codeなど他のAI開発ツールとの違い、導入前に確認すべきポイントを整理します。

目次 [表示]

    Kiroとは

    Kiroは、AWSが提供するAI開発プラットフォームです。Kiro IDE、Kiro CLI、プレビュー提供中のKiro Webを通じて、AIエージェントと対話しながらコード生成、修正、仕様整理、タスク実行を支援します。

    一般的なAIコーディングツールは、開発者の指示に応じてコード案や修正案を返す使い方が中心です。一方、Kiroは仕様を起点に、要件、設計、実装タスクの流れを整理します。コード生成だけでなく、AIを開発プロセスに組み込むための開発支援環境です。

    仕様駆動開発を支援するAWS発のAI開発プラットフォーム

    生成AIを使えば、短時間でコードを作れます。しかし、要件の前提や設計上の判断が曖昧なまま実装が進むと、コードだけが増え、後から実装の背景や判断根拠を確認しにくくなります。

    Kiroは、仕様駆動開発の考え方を開発支援環境に取り入れています。Specで仕様を整理し、その内容に沿ってAIエージェントと実装を進めます。何を作るのか、どの設計で進めるのか、どの順番で実装するのかを明確にしてから、コード生成に入れる点が特徴です。

    そのためKiroは、AIにコードを書かせるだけのツールではありません。要件定義、設計、実装、品質確認の流れを整理し、仕様と実装の関係を残しながら開発するためのAI開発プラットフォームです。

    Amazon Q DeveloperからKiroへ移行が進む背景

    Amazon Q Developerは、AWS環境での開発や運用を支援するAIアシスタントです。コード生成、コード説明、エラー調査、AWSサービスに関する質問、セキュリティ確認など、既存の開発作業を補助してきました。

    一方で、AWSは2026年4月30日、Amazon Q DeveloperのIDEプラグインと有料サブスクリプションを2027年4月30日にサポート終了すると発表しました。今後は、Kiroへの移行を前提に、開発支援の位置づけを見直す必要があります。

    Kiroは、コード生成や作業補助に閉じず、仕様を起点に開発プロセスを組み立てるAI開発プラットフォームです。Amazon Q Developerが担ってきた日常的な開発支援を引き継ぎながら、Spec、Hook、Steeringなどを通じて、要件整理、設計、実装、品質確認までを開発フローに組み込みます。

    Amazon Q DeveloperのIDEプラグインと有料サブスクリプションはサポート終了予定

    AWSは、Amazon Q DeveloperのIDEプラグインと有料サブスクリプションについて、2027年4月30日にサポートを終了すると発表しています。発表時点から12か月の移行期間が設けられており、既存利用者は、Kiroへの移行を前提に準備を進めます。

    2026年5月15日以降、新規のAmazon Q Developerアカウントや新規サブスクリプションの作成は停止されています。ただし、既存サブスクリプションへのユーザー追加は継続できます。

    今回のサポート終了は、Amazon Q Developer全体を対象とするものではありません。AWS マネジメントコンソール、AWS ドキュメントサイト、AWS Console Mobile App、SlackやMicrosoft Teams向けのAmazon Q Developerは引き続き利用できます。

    これからIDE上で使うAI開発支援ツールを検討する場合、Amazon Q Developerを新規導入候補として比較するよりも、Kiroを前提に検討するほうが実務に合います。既存利用者は、利用中のIDE拡張、有料サブスクリプション、社内利用ルールを確認しながら、Kiroへの移行方針を整理します。

    Amazon Q Developer CLIはKiro CLIへリブランドされている

    Amazon Q Developer CLIは、Kiro CLIへリブランドされています。CLIを利用していた場合は、単純なサービス終了ではなく、Kiro CLIへの移行として整理します。

    既存のAmazon Q Developer CLIやIDE拡張を利用している場合は、AWS公式の移行手順に沿ってKiroへアップグレードする流れになります。

    Kiroは開発支援をプロセス全体へ広げる

    Amazon Q Developerは、既存環境の中でコード生成、コード説明、AWSサービスに関する質問などを支援してきました。Kiroはその役割を引き継ぎつつ、仕様を起点に開発を進める点に特徴があります。

    Specで要件や設計を整理し、Hookでテスト実行や品質チェックなどの定型作業を開発フローに組み込み、Steeringでプロジェクトの前提やルールをAIに共有します。コード生成だけでなく、要件整理、設計、実装、品質確認までを含めてAIを活用できる点が、Kiroの大きな違いです。

    Kiroが解決するAI開発の課題

    AIコーディングツールは、コード生成や修正の速度を上げます。ただし、開発で問題になるのはコードを書く工程だけではありません。要件整理、設計判断、タスク分解、レビュー、保守まで含めると、AIが出力したコードを積み上げるだけでは、開発全体が不安定になります。

    Kiroは、こうした課題に対して、仕様を起点に開発を進める考え方を取ります。

    要件が曖昧なままコードだけが増える

    生成AIは、曖昧な指示にもそれらしいコードを返します。そのため、要件が整理される前に実装が進むことがあります。

    たとえば、「ログイン機能を作って」と指示すれば、AIは画面、認証処理、エラーハンドリングらしきコードを出力できます。しかし、認証方式、権限管理、パスワードリセット、監査ログ、セッション管理、既存システムとの連携条件が決まっていなければ、本番利用に耐える設計とは限りません。

    要件が曖昧なままコードだけが増えると、後から仕様との差分を確認する負担が増えます。修正のたびに前提を確認し直すことになり、AIで速く作ったはずのコードが手戻りの原因になります。

    AIへの指示が属人化し、出力の再現性が下がる

    AI開発では、プロンプトの書き方によって出力品質が変わります。前提条件や制約を細かく伝えられる場合もあれば、短い指示だけで実装が進む場合もあります。プロジェクト固有のルールが伝わっていなければ、チーム内で出力の粒度や品質がばらつきます。

    この状態では、AI活用が個人のスキルに依存します。似た機能でも実装方針が分かれ、コードベースの一貫性が崩れます。結果として、レビューや手戻りの負担が増えます。

    AIへの指示が属人化すると、品質が「誰がどう指示したか」に左右されます。その結果、同じ機能でも出力の粒度や実装方針がばらつきます。

    仕様・設計・実装のつながりを後から追いにくい

    AIでコード生成を繰り返すと、実装は進んでいるのに、なぜその設計にしたのか、どの要件を満たすコードなのかが確認しづらくなります。短期的には動くコードが増えても、後から修正や引き継ぎを行う段階で、判断の根拠を確認できません。

    チーム開発では、コードだけでなく、設計意図や変更理由も共有対象になります。仕様と実装の関係が曖昧なままだと、レビューで確認すべき観点が定まりません。保守フェーズでも、どの仕様に基づく処理なのかを調べる時間が増えます。

    Kiroの主要機能と実務での使いどころ

    Kiroは、仕様駆動開発に強いagentic IDEです。AIへの指示や前提を開発プロセスに組み込み、要件、設計、実装、品質確認をつなげる点が中核です。

    中心になるのは、Spec、Hook、Steeringです。Specは仕様の整理、Hookは定型作業の自動化、Steeringはプロジェクトルールの共有を担います。単発のプロンプトではなく、チームで扱える開発フローを作るための機能です。

    Spec:要件・設計・タスクを構造化する

    Specは、Kiroの中核となる機能です。作りたい機能や改善内容をもとに、要件、設計、実装タスクを整理し、AIエージェントが仕様に沿って作業できる状態にします。

    AIコーディングでは、いきなり「この機能を作って」と依頼すると、要件の抜けや設計上の前提が曖昧なままコードが生成されることがあります。Specを使えば、実装前に、どの要件を満たすのか、どの設計方針で進めるのか、どのタスクに分けるのかを明確にできます。

    Specの価値は、仕様と実装の関係を残せる点にもあります。要件が変わっても、コードだけが先行する状態を避けられます。複数人で開発する場合は、Specが共通認識になります。

    Hook:テストや品質チェックを自動化する

    Hookは、ファイルの保存、作成、変更などをきっかけに、AIエージェントへ特定の作業を実行させる機能です。テスト、Lint、ドキュメント更新、品質チェックなど、繰り返し発生する作業の自動化に使えます。

    AI開発では、コード生成の速度が上がる一方で、確認作業が追いつかないことがあります。コードは増えても、テストが未実行のまま残る、命名ルールが崩れる、ドキュメントが更新されない、といった問題が起きます。

    Hookを使えば、こうした定型チェックを開発フローに組み込めます。たとえば、特定のファイル変更時に関連テストを実行する、保存時にコード品質を確認する、仕様変更に合わせてドキュメント更新を促す、といった使い方です。

    Hookは、人間のレビューを置き換える機能ではありません。機械的に確認できる項目を先に処理し、人間が設計判断や仕様との整合性に集中するための機能です。

    Steering:プロジェクトの前提やルールをAIに共有する

    Steeringは、プロジェクト固有の前提や開発ルールをAIに伝える仕組みです。アーキテクチャ方針、命名規則、コーディング規約、利用するライブラリ、避けるべき実装方針などを共有できます。

    AIは、指示された内容に沿ってコードを生成できます。ただし、既存の設計思想、チーム内のルール、過去の判断理由までは自動で理解できません。前提が伝わっていなければ、プロジェクトの方針と合わないコードを提案することがあります。

    Steeringに前提をまとめておけば、毎回のプロンプトで同じ説明を繰り返さずに済みます。チームでKiroを使う場合も、開発者ごとにAIへの伝え方がばらつきにくくなります。

    ただし、Steeringにルールを書けば品質が保証されるわけではありません。前提が古くなれば、AIの出力も古いルールに引っ張られます。プロジェクトの変化に合わせて更新します。

    CLIやMCP連携などの拡張機能

    Kiroは、IDE上での利用だけでなく、CLIやMCP連携にも対応しています。CLIを使えばターミナルからKiroの機能を利用でき、MCP連携では外部ツールや情報源とAIエージェントを接続できます。AWS文脈では、MCPサーバーやKiroを組み合わせたモダナイゼーション支援の活用例も紹介されています。

    ただし、Kiroを理解する段階では、CLIやMCP連携を深く追う必要はありません。まずはSpec、Hook、Steeringによって、仕様、定型作業、プロジェクトルールをどう扱うかを押さえるほうが実務上の優先度は高くなります。

    Kiroの使い方

    Kiroの強みは、SpecやHookを開発フローに組み込む使い方にあります。単発のプロンプトでコードを書かせるのではなく、要件を整理し、設計に落とし込み、タスク単位で実装を進めます。

    最初から大規模なプロジェクトに適用する必要はありません。小さな機能追加や既存機能の改善を題材にして、SpecとHookの使い方を確認します。

    基本的な利用手順

    Kiroを使う基本的な流れは、インストール後に対象のプロジェクトを開き、AIエージェントへ実装したい内容を伝えるところから始まります。既存コードベースを読み込ませれば、プロジェクトの構造を踏まえてコード生成、修正、説明を支援します。

    ただし、通常のAIコード補完ツールのように使うだけでは、Kiroの特徴は活きません。実装に入る前に、何を作るのか、どの設計で進めるのか、どの順番で実装するのかを整理します。

    Specで要件・設計・タスクを整理する流れ

    Specを使う場合は、作りたい機能や解決したい課題をKiroに伝えます。たとえば、「管理画面にユーザー検索機能を追加したい」「既存の注文処理をリファクタリングしたい」といった単位です。

    Kiroは、その内容をもとに要件、設計、実装タスクを整理します。要件では満たすべき条件やユーザー操作を明確にし、設計では変更が必要なコンポーネント、API、データ構造を整理します。タスクでは、実装作業を小さな単位に分けます。

    Kiroが作成したSpecは、内容を確認したうえで採用します。要件の抜け、既存方針との整合性、タスク分解の妥当性は開発者が確認します。Specの段階で認識違いを修正できれば、実装後の手戻りを減らせます。

    チーム開発では、生成されたコードだけでなく、その前提となるSpecを確認することで、実装の背景を追えます。

    Hookで定型作業を自動化する流れ

    Hookは、ファイルの保存や変更などをきっかけに、特定の作業を自動実行する機能です。テスト、Lint、フォーマット確認、ドキュメント更新の通知など、開発中に繰り返し発生する確認作業に使います。

    たとえば、特定のコードを変更したときに関連テストを実行する、保存時にLintやフォーマットを確認する、仕様変更に合わせてドキュメント更新を促す、といった使い方です。

    ただし、Hookは何でも自動化すればよいわけではありません。保存のたびに重い処理を走らせると、開発作業のテンポが落ちます。最初は、テスト実行、Lint、フォーマット確認など、負荷が小さく効果を検証しやすい作業から設定します。

    Kiroの料金

    Kiroは無料プランから利用できます。料金は、利用できるクレジット量や超過利用の可否によって変わります。公式料金ページでは、個人向けにKiro Free、Kiro Pro、Kiro Pro+、Kiro Powerの4プランが案内されています。

    料金は、月額だけで判断できません。Kiroはコード補完だけでなく、Specによる仕様整理やHookによる自動化も含めて使うツールです。個人で試すのか、日常的に使うのか、チームの開発フローに組み込むのかによって、必要なクレジット量は変わります。

    無料で試せる範囲

    Kiro Freeには50クレジットが含まれます。無料プランではオープンウェイトモデルやClaude Sonnet 4.6へのアクセスも提供されますが、利用量には制限があります。Freeでは超過利用ができず、上限に達した場合は次のリセットを待つ必要があります。

    無料プランは、Kiroの操作感を確認する用途に適しています。既存プロジェクトでコードの説明を受ける、小さな機能追加でSpecを作る、Hookの考え方を試すといった検証に使えます。

    ただし、複数のSpecを作成したり、既存コードベースに対して継続的にAIエージェントを使ったりする場合、無料枠だけでは不足します。実務利用を想定するなら、早い段階でクレジット消費を確認します。

    有料プランで利用できる機能

    有料プランは、Pro、Pro+、Powerの3種類です。公式ドキュメントでは、Proが1,000クレジット、Pro+が2,000クレジット、Powerが10,000クレジットとされています。有料プランでは超過利用を有効化でき、超過分は追加クレジットとして課金されます。

    有料プランを選ぶ基準は、無料枠を超えるかどうかだけではありません。Kiroをコード生成中心で使うのか、Specで要件や設計まで整理するのか、Hookでテストや品質チェックを組み込むのかによって、消費量は変わります。

    個人で試す場合は、まずFreeで操作感とクレジット消費を確認し、不足する場合にProやPro+を検討します。大きなコードベースで継続利用する場合や、上位モデルを多く使う場合は、公式のモデル情報とクレジット消費を確認したうえでプランを選びます。

    チーム・企業利用で確認したいポイント

    チームや企業でKiroを使う場合は、料金だけでなく、管理・セキュリティ・運用面を確認します。誰がどのプロジェクトで使うのか、AIに参照させるコードやドキュメントの範囲をどう管理するのか、生成コードのレビュー責任をどこに置くのかを事前に決めます。

    確認すべきなのは、利用量、権限管理、セキュリティ要件、社内ルールとの整合性です。KiroはSpecやSteeringを通じてプロジェクトの前提をAIに共有するため、AIに参照させるコード、ドキュメント、機密情報の範囲を事前に整理します。

    チーム利用では、要件整理、設計レビュー前のタスク分解、実装支援、テストやドキュメント更新の補助など、Kiroを使う工程を先に決めます。利用場面が明確であれば、必要なプランやクレジット量も判断できます。

    Kiroと他のAI開発ツールの違い

    Kiroは、Cursor、Claude Code、Windsurfなどと同じく、AIを使って開発を支援します。ただし、Kiroはコード補完や単発の修正だけでなく、仕様を起点に要件、設計、タスク、実装をつなげる点に特徴があります。

    Amazon Q Developerについては、他社ツールとの比較と分けて整理します。Amazon Q Developerは、Kiroや他社ツールと横並びで新規比較する対象ではなく、既存利用者がKiroへ移行する際に確認すべき対象として整理します。

    Amazon Q DeveloperはKiroへの移行前提で考える

    Amazon Q Developerは、AWS環境での開発や運用を支援するAIアシスタントとして提供されてきました。コード生成、コード説明、エラー調査、AWSサービスに関する質問、セキュリティ確認など、既存の開発作業を補助する役割を担っていました。

    一方で、Amazon Q DeveloperのIDEプラグインと有料サブスクリプションはサポート終了予定であり、Amazon Q Developer CLIもKiro CLIへリブランドされています。そのため、今後はKiroとの使い分けを考えるよりも、Kiroへ移行する際に何を確認するかを整理するほうが実務的です。

    既存利用者は、IDE拡張、有料サブスクリプション、CLI、社内利用ルールを確認したうえで、Kiro IDE、Kiro CLI、Kiro Webのどこへ移行するかを検討します。

    Cursor・Claude Code・Windsurfとの違い

    Cursorは、AI補助付きのコードエディタです。既存コードを見ながら関数を追加する、エラーを直す、小規模な修正を進めるといった日常的な実装に向いています。

    Claude Codeは、ターミナルを起点にコードベースを横断して調査・修正するツールです。複数ファイルにまたがる変更、既存プロジェクトの理解、リファクタリングで使いやすい設計です。

    Windsurfは、AIエージェント型IDEとして、エディタ内でAIと連携しながら開発を進めます。ファイル横断の作業や、AIを開発環境に組み込む点ではKiroと近い部分があります。

    Kiroの違いは、Specを中心に仕様、設計、タスクを整理する考え方が前面にあることです。短いコード修正や個人の試作ならCursorやClaude Codeが合う場面があります。一方、要件が曖昧な機能開発や、設計意図を残しながら進める開発では、Kiroが選択肢になります。

    開発フェーズ別の使い分け

    AI開発ツールは、機能一覧だけで比較するより、どの開発フェーズで使うかを基準にしたほうが判断できます。

    目的 向いているツール 判断軸
    仕様起点の新機能開発 Kiro 要件・設計・タスクを整理して進める
    AWS環境を含む開発支援 Kiro IDE、CLI、Webを通じてAWS関連開発やモダナイゼーション支援に使う
    Amazon Q Developer既存利用からの移行 Kiro IDE拡張、有料サブスクリプション、CLIの扱いを確認する
    日常的なコード補完 Cursor エディタ上で小さな修正を進める
    既存コードの横断的な調査・修正 Claude Code ターミナル起点で複数ファイルを扱う
    AIエージェント型IDEでの実装支援 Windsurf エディタ内でAIと連携して開発する

    Kiroは、他ツールの上位互換ではありません。仕様を起点に開発を進めるAI開発プラットフォームとして、用途を分けて判断します。

    Kiroを使うべき人・使わなくてもよい人

    Kiroの強みは、コード生成そのものではなく、仕様、設計、タスク、実装の流れを整理できる点にあります。短いコード修正や個人の試作では、より軽量なAIコーディングツールが合う場合がありますが、要件が曖昧な機能開発、複数人での開発、保守性を重視するプロジェクトでは効果を発揮します。

    Kiroが向いている人・チーム

    Kiroが向いているのは、AIを開発プロセスに組み込みたい人やチームです。要件定義、設計、実装、レビューの流れを整理しながら開発する場面に適しています。

    新機能を追加する前に要件や設計方針を整理したいチームでは、Kiroが候補になります。仕様や設計意図を残したいプロジェクトで価値が出ます。

    チームでAI開発の進め方をそろえたい場合にも有効です。開発者ごとにプロンプトやAIへの指示がばらつくと、実装方針やコード品質にも差が出ます。Kiroでは、SpecやSteeringでプロジェクトの前提を共有し、指示や実装方針のばらつきを抑えられます。

    既存コードの改善やリファクタリングでも、現在の構造、変更の目的、影響範囲、実装タスクを整理しながら進められます。場当たり的にコードを直すのではなく、変更の根拠を残しながら改善したい場合に向いています。

    Kiroをコード支援に使う場合と開発プロセスに組み込む場合 

    Kiroは、小さなコード修正、短いスクリプト作成、単発のコード補完にも利用できます。Kiro IDEの対話型の開発支援やKiro CLIを使えば、既存コードの確認、簡単な修正、ターミナル上での開発支援にも対応できます。

    ただし、Kiroの主な価値は、単発のコード支援だけではありません。Specで仕様を整理し、Hookで定型作業を開発フローに組み込み、Steeringでプロジェクトの前提を共有できる点にあります。

    すでに使い慣れたIDEやAIコーディングツールで作業フローが固まっている場合は、まずKiroを部分的に試す進め方もあります。小さな修正やアイデア検証で操作感を確認し、要件や設計を整理する必要が出てきた段階で、SpecやHookを含めた本格利用を検討します。

    Kiroの強みを十分に活かすには、仕様作成、出力確認、生成コードのレビューを開発フローに組み込む必要があります。単発の支援で使うのか、仕様駆動開発の基盤として使うのかを分けて判断します。

    導入前に確認すべきポイント

    Kiroを導入する前に、どの工程で使うのかを決めます。要件整理、設計、実装、レビュー、テスト、ドキュメント更新のうち、どこに組み込むのかが曖昧なままでは、導入後の使い方が個人任せになります。

    Specを要件整理に使うのか、Hookを品質チェックに使うのか、Steeringでプロジェクトルールを共有するのかによって、整えるべき運用は変わります。利用場面と責任範囲は事前に決めます。

    セキュリティや権限管理も確認します。Kiroにどのコードやドキュメントを参照させるのか、機密情報を含むプロジェクトで使えるのか、チーム内で利用範囲をどう制限するのかを整理します。

    生成コードのレビュー体制も必要です。SpecやHookを使っても、AIの出力が常に正しいわけではありません。設計意図との整合性、セキュリティ、パフォーマンス、既存コードとの一貫性は、人間が確認する前提で運用します。

    Kiroは、仕様を書く手間を避けるためのツールではありません。その手間をかけてでも、開発の再現性や保守性を高めたい場合に導入価値があります。

    まとめ

    Kiroは、仕様を起点に開発を整理するためのAI開発プラットフォームです。Kiro IDE、Kiro CLI、Kiro Webを通じて、要件、設計、タスク、実装を整理しながら開発を進められます。

    小規模な修正や単発のコード補完では、CursorやClaude Codeなどが適する場面もあります。一方で、要件が曖昧な機能開発、複数人での開発、保守性を重視するプロジェクトでは、Kiroの強みが出ます。

    Amazon Q Developerを利用している場合は、Kiroへの移行を前提に、IDE拡張、有料サブスクリプション、CLIの扱いを確認します。Kiroを導入する際は、仕様を書く運用、生成コードの確認体制、自社の開発フローへの組み込み方を先に設計します。



    Page Top