Kiro IDEとは？使い方・料金・specの仕組みをIDE 1.4で解説

Kiro（キーロ）は、AWSが提供するAIコーディング用のIDEです。チャットで指示してその場でコードを書かせることもできますが、本領は実装の前に要件・設計・タスクを3つのMarkdownファイルに固め、そのタスクをエージェントに実行させる「spec」にあります。この記事では、2026年10月28日公開のIDE 1.4.62時点の公式ドキュメントをもとに、モードの使い分け、プロジェクトに置く設定ファイルの書き方、IDE 1.0以降に入った権限・Memory・Workflows、モデルごとのクレジット倍率と料金、導入手順を整理します。

まとめ：Kiro IDEの要点（2026年10月時点）

• 正体：AWS製のエージェント型IDE。Code OSS（VS Codeの基盤）ベースの独立アプリで、VS Codeの拡張機能ではない。提供形態はIDE・CLI・Web・モバイル・Kiro Crewの5つで、.kiro の設定を共有する。AWSアカウントは不要。
• モード：IDE 1.0でVibe／Specの選択は廃止され、会話で直接書かせるDefaultエージェント（旧Vibe）から始めて、必要なときにSpec・Quick Spec・Bug Fix・Planの組み込みワークフローへ切り替える方式になった。
• 設定：規約は .kiro/steering/、自動処理は .kiro/hooks/*.json、エージェントに許す操作は permissions.yaml に書く。
• 料金：Free（50クレジット）からPower（$200・10,000クレジット）までの5プラン。モデルごとに倍率があり、Opus 5.5はAutoの2.0倍、Haiku 5.5はリクエストが10万トークン以下なら0.06倍、超えると0.3倍。
• 向き不向き：要件を文書に残したい中規模以上の機能開発で効く。数行の修正や使い捨てスクリプトはDefaultで足り、specの承認待ちが手間になる。

Kiroの正体｜AWS製・Code OSSベースのエージェント型IDE

KiroはAWSが開発し、2025年7月にプレビュー、2025年11月17日にIDEとCLIが一般提供になりました。公式FAQは「Kiro is based on Code OSS」と明記しており、VS Codeの設定・テーマ・Open VSX互換の拡張機能を初回起動時に取り込めます。標準の拡張機能レジストリはOpen VSXで、そこに無い拡張も互換性のあるVSIXファイルなら手動で入れられます。普段使う拡張がOpen VSXにあるか、無ければ配布条件とKiroでの動作を導入前に確かめてください。

ログインはGitHub・Google・AWS Builder ID・AWS IAM Identity Centerのいずれかで、AWSアカウントは要りません。Amazon Q DeveloperのIDEプラグインからの移行先として案内されており、Q CLIはKiro CLIへ移っています（移行手順はAmazon Q CLIはKiro CLIへ：q chatからの移行手順と設定・3.0の変更点【2026年10月】、Q Developer側の契約はAmazon Q Developerの料金｜Free・Pro Tierの上限とKiro移行後の費用で扱っています）。

5つの提供形態と動作環境

インストールガイドの動作要件は次のとおりです。WebとモバイルはFAQで「paid account」が前提とされており、Freeでは使えません。

Crewだけはオープンソース（kirodotdev/KiroCrew）で、IDE本体は違います。Webの自律モードが旧「Kiro autonomous agent」を引き継いだ経緯はフロンティアエージェントとは？AWSの4製品（Kiro・Security・DevOps・FinOps）の定義と現在地【2026年10月】にまとめています。

Default・Spec・Quick Spec・Bug Fix・Planの使い分け

0.xの解説でよく見る「VibeモードとSpecモード」の二択は、IDE 1.0でなくなりました。IDE 0.xリファレンスは「The Vibe/Spec mode picker was removed」と書いています。組み込みワークフローを選ばずに始めるとVibe相当のDefaultエージェントが使われ（開始時のエージェントは変更して保存できる）、構造化した進め方が要るときは、セッション開始時の「Let’s build」画面か、チャット入力欄のエージェント選択から組み込みワークフローに切り替えます。途中で切り替えても履歴は残ります（IDEのChatドキュメント）。

Spec（Feature Spec）にはRequirements-First（要件から書く）とDesign-First（設計から書く）の2通りがあります。Quick Specは承認を省く代わりに、範囲・制約・境界条件を最初にまとめて質問してきます。Quick Specのドキュメントは、規制対象の領域や初めて扱う領域では承認ゲートのある通常のSpecを勧めています。迷ったら通常のSpecを選び、同じ種類の機能を何度も作るようになってからQuick Specに移るのが安全です。

specが作る3つのファイルとタスクの並列実行

specは1機能ごとに .kiro/specs/<機能名>/ のフォルダを作り、次の3ファイルを生成します。以下は要件を先に作るRequirements-Firstの順序で、Design-Firstでは設計が先になります（Specsのドキュメント）。

• requirements.md：ユーザーストーリーと受け入れ基準。受け入れ基準は WHEN [条件] THE SYSTEM SHALL [動作] のEARS記法で書かれる（書き方はEARS記法とは？読み方と5つの基本型の書き方を日本語例文で解説【Kiro対応】）。Bugfix Specでは現在の挙動・期待する挙動・変えてはいけない挙動を書いた bugfix.md になる。
• design.md：アーキテクチャ、シーケンス図、データの流れ、エラー処理とテストの方針。
• tasks.md：実装タスクの一覧。実行中は進行中・完了の状態がリアルタイムに付く。

全タスクを実行すると、Kiroは tasks.md の依存関係をグラフにし、依存のないタスクを「wave」にまとめて同時に動かします。wave同士は順番に、wave内は並列に進みます。依存の書き漏れがあると並列で衝突するので、tasks.mdを承認する前に順序の前提を読んでおきます。

要件の矛盾を検出するAnalyze RequirementsはIDEとCLIだけ、property-based testingで実装を検証するCorrectnessはIDEだけで、Webでは使えません。仕様駆動開発そのものの考え方と他ツールの比較は、仕様駆動開発（SDD／Spec-Driven Development）とは？TDDとの違い・3つの段階とSpec Kitで試す手順【2026年10月】と仕様駆動開発ツール比較｜Spec Kit・Kiro・cc-sdd・OpenSpecの違いと選び方【2026年10月】に譲ります。

Steering・フック・Powersによる規約設定と機能拡張

Steering：.kiro/steering の規約ファイルと読み込み条件

Steeringは、技術スタックや命名規則をMarkdownで書いておき、毎回の会話に読み込ませる仕組みです。置き場所はリポジトリの .kiro/steering/（そのワークスペースだけ）と ~/.kiro/steering/（全ワークスペース）の2つで、指示がぶつかるとワークスペース側が優先されます。IDEの「Generate Steering Docs」で product.md・tech.md・structure.md の3本を自動生成できます。

読み込むタイミングは、ファイル先頭のfront matterで決めます（Steeringのドキュメント）。既定は常に読み込む always、特定のファイルを触るときだけ読む fileMatch、チャットで #ファイル名 と書いたときだけ読む manual、依頼内容が description に合うときに読む auto の4つです。front matterの前に空行があると効きません。

---
inclusion: fileMatch
fileMatchPattern: ["src/api/**/*.ts", "**/*.test.ts"]
---
# API実装の規約
- 入力検証は zod のスキーマで行う
- エラーは { code, message } の形で返す

リポジトリ直下やサブディレクトリの AGENTS.md もSteeringとして自動で読み込まれます。ただしAGENTS.mdにはinclusionの指定が効かず、常に読み込まれます。他ツールと共用する規約はAGENTS.md、Kiroだけで条件付きにしたい規約は .kiro/steering/、と分けると管理しやすくなります。

フック：.kiro/hooks/*.json の書き方

フックは、エージェントがファイルを保存した・ツールを呼んだ・作業を終えたといったイベントで、シェルコマンドを走らせるかプロンプトを差し込む仕組みです。IDE 1.0でJSON形式（"version": "v1"）に作り直されました。次の公式例は、ESLintとTypeScript用の設定が用意されたプロジェクトを前提に、エージェントによるTypeScriptファイルの保存後にESLintを実行するものです（Hooksのドキュメント）。

保存先：.kiro/hooks/lint-on-save.json

{
  "version": "v1",
  "hooks": [{
    "name": "Lint on save",
    "trigger": "PostFileSave",
    "matcher": "\\.(ts|tsx)$",
    "action": { "type": "command", "command": "npx eslint --fix" }
  }]
}

トリガーはプロンプト送信・エージェント停止・ツール実行の前後・ファイルの作成／保存／削除・specタスクの実行前後など。ツール実行前（PreToolUse）のフックで条件を満たさない操作を止めることもでき、コマンドの既定のタイムアウトは60秒です。Webのセッションではフックが動きません（設定の保存はできるが、トリガーは実行されない）。

Powers：MCP設定と専門知識の条件付き読み込み

MCPサーバーをいくつもつなぐと、使わないツール定義まで最初から文脈に積まれます。公式は5サーバーで50,000トークン以上、文脈の40%を最初のプロンプトの前に使う例を挙げています。Powersは、MCPの設定・手順・ベストプラクティスを1つのパッケージにまとめ、会話にそのキーワードが出たときだけ読み込む仕組みです（Powersのドキュメント）。IDEとWebで使え、CLIはV3から対応しています。

IDE 1.0以降で変わったこと｜権限・Memory・Workflows

2025年の解説記事の多くはIDE 0.x時代のもので、1.0以降は設定ファイルの形式が変わっています。

権限：trustedCommandsからpermissions.yamlへ

0.xの「信頼するコマンド」の前方一致と拒否リストは、IDE 1.0で能力（capability）単位の権限に置き換わりました（Capability-based permissions）。fs_read・fs_write・shell・web_fetch・mcp などの能力ごとに deny／ask／allow を書き、優先順位はdeny＞ask＞allowです。何も設定しなければ、エージェントはワークスペースのファイル読み取りと読み取り専用のgitコマンドだけを確認なしで実行し、ほかは毎回尋ねます。

# ~/.kiro/workspace-roots/<hash>/permissions.yaml（ワークスペース単位）
rules:
  - capability: fs_write
    match: ["*.env", "*.pem", "*.key"]
    effect: deny
  - capability: shell
    match: ["rm -rf *", "sudo *"]
    effect: deny

ワークスペースの権限ファイルはリポジトリではなくホームディレクトリ側に置かれるため、cloneしたリポジトリが勝手に権限を広げることはできません。全ワークスペース共通で許可したい操作は ~/.kiro/settings/permissions.yaml に書きます。

Memory：既定はオフ

IDE 1.4.0（2026年10月19日）で入ったMemoryは、リポジトリのコマンドや規約、指摘された修正、試して駄目だった方法をセッションをまたいで覚える機能です。1.4.10で初期設定がOffに変わったため、使うにはMemoryビューの歯車から「Use and learn」「Use but don’t learn」「Use only」のいずれかを選び、新しいセッションを開始します（Memoryのドキュメント）。公式は「必ず守らせたい規則はSteeringに書く」としており、Memoryは規約の置き場所ではありません。

Workflows：複数エージェントによる多段作業のバックグラウンド実行

Workflowsは、要件定義→設計レビュー→実装→2人のレビュアー→検証のような多段の作業を、複数のエージェントの手順としてバックグラウンドで実行する機能です。手順はKiroが提案し、実行前に人が承認します。IDE・CLI・Webのどれでも明示的に有効化が必要で、IDEでは「Workspace Configuration」の「Workflows」から有効にし、新しいチャットセッションを開始します。前章のSpecなど組み込みワークフローとは別機能です。1.4.26からはチャットごとに「Only when asked（既定）」「Only for large tasks」「As much as possible」を選べます。レビューを繰り返すぶん1セッションよりトークンを多く使うと公式が明記しているので（Workflowsのドキュメント）、小さな作業まで「As much as possible」にしないことです。

対応モデルとクレジット倍率

既定のAutoは、タスクごとにモデルを振り分ける仕組みで倍率1.0倍です。モデルを指定すると、モデル一覧の倍率が掛かります。公式の例では、Autoで10クレジットの作業がOpus 5.5なら20クレジットになります。

ほかにOpus 5／4.8／4.7／4.6（2.2x）、Sonnet 5／4.6、Haiku 4.5、DeepSeek 3.2、MiniMax M2.5／M2.1、GLM-5があります。Claude Sonnet 4は2026年10月14日に提供を終了しました。同じ倍率のモデルでも、出力の長さや思考の深さ、トークナイザーの違いで1タスクあたりの消費は変わると公式は注記しています。倍率はこの数か月で何度も改定されているので、契約前にモデル一覧で確認してください。

提供状態の違いも業務利用では効きます。モデルのライフサイクル表では、上の表のうちOpus 5.5・Haiku 5.5・GPT-5.6 Sol・Kimi K3・Qwen3 Coder NextがExperimental（2026年10月31日時点）です。Experimentalのモデルを選ぶと、AWSサービス条件50.10の出力に対する補償（output indemnity）が適用されません。権利面の保証が要るコードはAutoか正式提供のモデルで書かせます。

Kiroの料金｜5プランとクレジットの減り方

料金は月額に応じてクレジットが付く方式で、Defaultでの会話もspecのタスク実行もフックの実行も、同じクレジットから引かれます（料金ページ）。

• 月のクレジットは繰り越せない。追加パック（$5＝125クレジットから$100まで）は購入から12か月有効で、翌月以降に持ち越せる。
• FreeではAuto、Claude Sonnet 4.5、一部のオープンウェイトモデルを利用でき、レート制限がある。
• ソーシャルログインかBuilder IDで初めて有料に上げると、$20分が月額に充当される（IAM Identity Centerは対象外）。
• Enterpriseは月末精算の超過課金を管理者が有効にできる（初期設定はオフ）。
• 価格は税抜きで、日本の請求先には消費税がかかる。GovCloudは約20%高くFreeがない。

Proの1,000クレジットは、Autoで1回1クレジットの依頼なら約1,000回、Opus 5.5に固定すると約500回です。specのタスク実行やWorkflowsは1回の消費が大きいので、まずFreeで小さなspecを1本最後まで回し、減り方を見てからプランを決めます。

Kiro IDEのインストールと最初のspec

1. kiro.dev からOSに合うインストーラーを入れる。Windowsは1.4.62からシステム全体へのインストーラー（x64・ARM64）も選べる。
2. GitHub・Google・AWS Builder ID・組織のIDのいずれかでサインインする。
3. 必要ならVS Codeの設定とOpen VSXの拡張機能を取り込む。
4. プロジェクトを開き、Kiroパネルの「Generate Steering Docs」で product.md・tech.md・structure.md を作る。生成結果は読んで直す。
5. チャットを開き、「Let’s build」画面かエージェント選択でSpecを選んで、作りたい機能を文章で伝える。
6. requirements.md の受け入れ基準を読んで直し、承認する。design.md、tasks.md も同様に承認する。
7. tasks.md から1タスクずつ、または全タスクを実行する。初回は書き込みやコマンド実行のたびに権限の確認が出るので、許可した操作を「always allow」で保存していく。

CLIは brew install kiro-cli（macOS）か curl -fsSL https://cli.kiro.dev/install | bash（macOS・Linux）で入り、IDEと同じ .kiro の設定を読みます。

データの扱い｜学習利用される条件とオプトアウト

同じ有料プランでも、ログイン方法でデータの扱いが変わります（データ保護のドキュメント）。

• Free、および有料でもGitHub・Google・Builder IDでログインした個人契約：オプトアウトしない限り、内容がサービス改善に使われることがある。テレメトリも既定で送られる。Freeは乱用検知のため入力を最大60日保存することがある。
• IAM Identity Centerか外部IdPでログインするEnterpriseユーザー：内容はサービス改善に使われず、テレメトリと内容の収集から自動的に外れる。

IDEでのオプトアウトは、設定の「Application」→「Telemetry and Content」で2つのチェックを外します。業務のコードを扱うなら、個人のProで済ませずEnterprise経由にするか、少なくともこの2項目を外してから使い始めてください。なお公式FAQは、OpenClawのような第三者の自動化ハーネス経由の利用を許可していません。

Kiroが向く開発・向かない開発

Kiroを選ぶ理由は「仕様がリポジトリに残ること」です。要件の合意がレビューや引き継ぎの論点になるチーム、複数画面・複数APIにまたがる機能、影響範囲を先に書き出したいレガシー改修なら、specの手間は回収できます。

向かないのは次の場面です。

• 数行の修正や1回きりのスクリプト。3ファイルの承認が実装より長くかかる。Defaultエージェントで足りる。
• 必須の拡張機能について、Open VSX経由でも互換性のあるVSIXの手動導入でも、必要な動作を確認できない。
• 月50クレジットを超える開発をFreeだけで続けたい。Freeでは追加購入ができないため、上限に達したら次の更新を待つか、有料プランへ変更する必要がある。
• 仕様をリポジトリに残したいが、Cursorなど今のIDEは変えたくない。この場合はSpec KitやOpenSpecを今のIDEに足す方が移行コストが低い。

CursorやGitHub Copilotとの料金・計画機能・フックの違いはKiroとCursor・GitHub Copilotの違いを比較｜料金・仕様駆動・フックの選び分けで比べています。社内の開発にAIエージェントを組み込む段階で、要件の書き方やレビュー体制から設計したい場合は、生成AI開発・AI受託開発で支援しています。

よくある質問

Kiroの読み方は？

「キーロ」と読みます。AWSが提供するエージェント型IDEの製品名です。

Kiroは無料で使えますか？

Freeプランで月50クレジットまで無料で使えます。使えるモデルはAuto、Claude Sonnet 4.5、一部のオープンウェイトモデルで、追加クレジットは買えません。WebとモバイルはFreeでは使えません。

KiroはVS Codeの拡張機能ですか？

違います。Code OSSをもとにした独立したIDEで、VS Codeとは別にインストールします。VS Codeの設定・テーマとOpen VSX互換の拡張機能は取り込めます。

KiroはAWSアカウントが無くても使えますか？

使えます。GitHub・Google・AWS Builder IDのいずれかでログインでき、AWSアカウントは要りません。IAM Identity Centerか外部IdPでログインする組織利用では、データの扱いがEnterpriseの条件になります。

Kiroは日本語で使えますか？

チャットは日本語で使えます。IDEのChatドキュメントは対応言語に日本語を挙げ、書いた言語を自動で判別して同じ言語で返すとしています。

関連記事

• KiroとCursor・GitHub Copilotの違いを比較｜料金・仕様駆動・フックの選び分け
• 仕様駆動開発（SDD／Spec-Driven Development）とは？TDDとの違い・3つの段階とSpec Kitで試す手順【2026年10月】
• EARS記法とは？読み方と5つの基本型の書き方を日本語例文で解説【Kiro対応】
• 仕様駆動開発ツール比較｜Spec Kit・Kiro・cc-sdd・OpenSpecの違いと選び方【2026年10月】
• Amazon Q CLIはKiro CLIへ：q chatからの移行手順と設定・3.0の変更点【2026年10月】