Kiroとは｜AWSのAI IDEの使い方・料金・Spec・CLI

Kiro の Spec は、やりたいことを「要件 → 設計 → タスク」の3つのファイルに分けてから、エージェントに実装させる流れです。

flowchart TD
    A[やりたいことを書く] --> R[requirements.md<br>要件]
    R --> D[design.md<br>設計]
    D --> T[tasks.md<br>タスク一覧]
    T --> X[エージェントが実装]
    S[.kiro/ の steering<br>hooks・MCP] -.-> X

よく使う操作と置き場所を先にまとめます。

確認環境：Kiro の機能・設定ファイルの形・コマンド・料金は、kiro.dev の公式ドキュメント（Specs・Steering・Hooks・MCP・Permissions・Configuration scopes・CLI commands・Slash commands）、料金ページ、ダウンロードページ（IDE 1.3.11）、FAQ で確かめました。.kiro/ の設定ファイルはドキュメントの形で手元に作り、Ubuntu 24.04・Python 3.11.15 の検査スクリプトで確かめています。hooks から呼ぶスクリプトの終了コードと、mcp.json と同じ uvx mcp-server-fetch（uv 0.8.17・mcp-server-fetch 2026.10.10）の tools/list は実際に実行した出力です（確認日 2026年10月18日）。

Kiroとは：AWSのAI開発環境

Kiro（キロ）は、AWS が提供する AI エージェントの開発環境です。 公式は「プロトタイプから本番まで、あなたのやり方で動く AI 開発環境」と説明しています。チャットで頼んでコードを書かせるだけでなく、先に仕様書（Spec）を作り、それに沿ってタスクを1つずつ実装させるのが大きな特徴です。

IDE は Code OSS（VS Code のオープンソース版）をもとにしているため、VS Code の設定・テーマ・Open VSX 互換の拡張機能を取り込めます。FAQ には「AWS アカウントがなくても使える」とあり、GitHub・Google・AWS Builder ID・組織のアカウント（IAM Identity Center など）でサインインします。

Kiroの5つの形（IDE・CLI・Web・Mobile・Crew）

公式ドキュメントは「どの形も、同じ1つのエージェントの仕組み（unified agent harness）の入り口」と書いています。会話・ツールの実行・権限・モデルとのやり取りはこの共通の仕組みが受け持ち、プロジェクトの .kiro/ に置いた設定はどの形からも同じように使われます。

Amazon Q Developerとの関係

AWS には、以前から IDE の拡張機能として動く Amazon Q Developer があります。Kiro の公式ドキュメントには「Migrating from Q Developer」と「Upgrading from Q CLI」の移行ガイドがあり、Q Developer の拡張機能から Kiro へ移る人向けの手順が書かれています。移行ガイドによると、Kiro には Visual Studio・Eclipse 用のプラグインはなく、JetBrains の IDE からは Kiro CLI を入れて ACP（Agent Client Protocol）経由で使います。

AI に仕様を渡して開発を進める考え方の全体像は、関連記事「AI駆動開発とは？バイブコーディングとの違いと導入手順」で扱っています。

Kiroの料金（2026年10月18日時点）

Kiro はクレジット制です。 月額のプランごとに使えるクレジット数が決まっていて、AI に頼んだ作業の重さとモデルに応じてクレジットが減ります。料金ページの内容は次のとおりです（2026年10月18日時点）。

「1クレジットあたり」は月額をクレジット数で割った値です。有料プランはどれも 0.02ドルで、違いは月に使える量です。

料金ページと Billing のドキュメントに書かれている決まりです。

• 月のクレジットは繰り越されない。使い切らなかった分は翌月に持ち越せない。
• 追加クレジットは 0.04ドル／クレジット。パックは 5ドル（125クレジット）から 100ドルまでで、買ってから12か月で失効する。Free では買えない。
• 初めて有料プランにすると 20ドル分が付く（ソーシャルログインか AWS Builder ID の場合）。日割りで、例として6月15日に Pro にすると6月は10ドル分、7月の請求が10ドルになると書かれている。
• 有料プランの請求は毎月1日。日本の住所で払うと日本の消費税がかかる。
• 1つの契約は1人分。チームで使うときは1人ずつ契約する。
• クレジットは小数点以下2桁まで数える。簡単な依頼は1クレジット未満、Spec のタスク実行のような重い作業はそれ以上になることが多い。
• 使えるのは Kiro の IDE・CLI・Web・Crew・ACP 対応の IDE・CI/CD での自動実行。Kiro の外を経由する他のツールからの利用は認められていない。

モデルごとのクレジット消費（倍率）

同じ依頼でも、選んだモデルでクレジットの減り方が変わります。Available models のページ（2026年10月17日更新）に倍率が載っているものを抜き出します。

Auto は Kiro のモデルの振り分け役で、Free では Sonnet 級以上、有料プランでは Opus 級以上の品質になるよう送り先を選ぶと書かれています。Experimental のモデルには振り分けません。

Kiroのインストール（Windows・Mac・Linux）

IDEの動作環境とダウンロード

IDE は kiro.dev のダウンロードページから OS に合ったファイルを取って入れます。2026年10月18日時点の最新は 1.3.11 です。

ダウンロードページには、2026年11月9日以降は IDE 0.11.133 より前・CLI 1.28.2 より前の版が Kiro のサービスにつながらなくなる、という案内も出ています。

会社のネットワークでプロキシを通すときは、IDE・CLI とも HTTP_PROXY・HTTPS_PROXY・NO_PROXY を読みます。IDE は Settings → Proxy でも設定できます。ブラウザーでのサインインは、この設定を通らない点に注意が要ります。

Kiro CLIのインストール

Kiro CLI のページとダウンロードページには、macOS・Linux・Windows 共通として次の1行が載っています。CLI は macOS・Windows 11（PowerShell）・glibc 2.34 以降か musl の Linux で動きます。

curl -fsSL https://cli.kiro.dev/install | bash

入れたら、プロジェクトのフォルダで起動します。初回はサインインを求められます。

kiro-cli login
cd my-project
kiro-cli

起動したら /guide で CLI について質問できる Guide エージェントに切り替わり、Shift+Tab で元のエージェントに戻ります。/help でコマンドの一覧が出ます。リモートのマシンでブラウザーが開けないときは、URL と1回限りのコードを別の端末のブラウザーで入力する方式（device flow）が使えます。

アンインストール

Kiroの使い方：最初の4ステップ

IDE で最初のプロジェクトを動かすまでの流れです（Build your first project のページの順）。

1. フォルダを開き、Kiro パネルを開く。左のバーの Kiro のアイコンを押すと、Specs・Agent Hooks・Steering・MCP の欄が並んだパネルとチャット欄が出る。
2. steering を作る。パネルの「Generate Steering Docs」を押すと、Kiro がリポジトリを読んで .kiro/steering/ に決まりごとのファイルを作る。
3. Spec で機能を作る。チャットの Spec ボタンか Specs の + を押し、作りたい機能を文章で書く。Kiro が要件・設計・タスクの順に作り、tasks.md のタスクを押すと実装が始まる。
4. hooks・MCP を足す。Agent Hooks の + で自動化を文章で頼むと、設定ファイルが作られる。MCP は設定ファイルに書く。

チャット欄の # で、会話に入れる情報を選べます。#codebase・#file・#folder・#git diff・#terminal・#problems・#url・#steering・#spec・#mcp などがあります。チャットは Mac で Cmd+L、Windows・Linux で Ctrl+L で開きます。

エージェントにすべての変更を任せるか、1つずつ承認するかは、Settings → Agent → Agent Autonomy の Autopilot と Supervised で切り替えます。うまくいかなかったときは、チェックポイントでコードと会話を前の時点まで戻せます。

.kiroフォルダの全体像（設定ファイルの置き場所）

Kiro の設定は、プロジェクトの .kiro/ とホームの ~/.kiro/ の2か所に置きます。プロジェクト側をリポジトリに入れると、チームの全員と、IDE・CLI・Web のどれから開いても同じ設定が使われます。Configuration scopes のページ（2026年10月13日更新）の内容です。

両方にあるときの扱いは設定ごとに違います。steering・Skills・hooks は両方を合わせて使い、MCP は「エージェントの設定 → プロジェクト → ホーム」の順で優先、権限はどこかに deny があればその操作は止まります。

この記事で作ったサンプルのプロジェクトは、次の形です（ToDo 管理 API を作る想定）。

find . -type f | sort

./.kiro/hooks/guard-shell.json
./.kiro/hooks/lint-on-save.json
./.kiro/settings/mcp.json
./.kiro/specs/todo-api/design.md
./.kiro/specs/todo-api/requirements.md
./.kiro/specs/todo-api/tasks.md
./.kiro/steering/api-design.md
./.kiro/steering/product.md
./.kiro/steering/release.md
./.kiro/steering/tech.md
./.kiro/steering/testing.md
./AGENTS.md
./scripts/guard_shell.py
./scripts/kiro_lint.py
./scripts/mcp_list_tools.py

仕様駆動開発（Spec）：requirements・design・tasks

Spec は、機能の追加やバグの修正を、3つのファイルに分けて形にする仕組みです。 頭の中の「こういうものが欲しい」を、確かめられる要件・設計・タスクに変えてから実装に入ります。

Specの種類（Feature・Bugfix・Quick Spec）

各段階で、浮いている Review ボタンから Markdown Review を開くと、文章の特定の箇所にコメントを付けて、まとめて Kiro に返せます。CLI V3 では /spec new 名前 で Spec を始めます。

要件はEARS記法で書く

requirements.md の受け入れ条件は、EARS 記法（「WHEN 条件 THE SYSTEM SHALL 振る舞い」の形）で書かれます。ドキュメントの例は次のとおりです。

WHEN a user submits a form with invalid data
THE SYSTEM SHALL display validation errors next to the relevant fields

「いつ」と「システムが何をするか」を1文ずつに分けるので、テストに落としやすくなります。サンプルのプロジェクトでは、次のように手で書いてみました（Kiro が作るファイルの書式そのものではなく、要件の形の例です）。

### Requirement 1
**User Story:** As a チームメンバー, I want ToDo を登録したい, so that やることを忘れない。

#### Acceptance Criteria
1. WHEN 利用者が title を付けて POST /todos を送る THE SYSTEM SHALL 201 と作成した ToDo を返す
2. WHEN title が空文字のまま送られる THE SYSTEM SHALL 400 と error.code "TITLE_REQUIRED" を返す

タスクの実行とウェーブ

Kiro は tasks.md の各タスクの状態（実行中・完了）をその場で表示します。タスクは1つずつでも、まとめてでも実行できます。まとめて実行すると、Kiro はタスクの依存関係を調べ、互いに関係のないタスクを「ウェーブ」にまとめます。 ウェーブは順番に、ウェーブの中のタスクは同時に実行されます。タスクの実行は IDE・CLI・Web のどれでもできます。

Spec の考え方そのもの（仕様書に何を書くか）は、関連記事「仕様駆動開発（SDD）とは？AIに渡す仕様書テンプレートと進め方」で扱っています。

steeringの書き方（.kiro/steering）

steering は、プロジェクトの決まりごとを Markdown で書いておき、エージェントに読ませる仕組みです。 「回答は日本語で」「テストは Vitest」「URL は複数形の名詞」といった、毎回伝えたいことを書きます。

• プロジェクト用：.kiro/steering/。そのプロジェクトだけに効く
• 全体用：~/.kiro/steering/。すべてのプロジェクトに効く。食い違うときはプロジェクト用が優先

「Generate Steering Docs」で作られる基本の3ファイルは、product.md（目的・利用者・機能）、tech.md（フレームワーク・ライブラリ・制約）、structure.md（フォルダ構成・名前の付け方・設計）です。

いつ読み込むか（inclusion）

ファイルの先頭の front matter（--- で囲んだ YAML）で、いつ読み込むかを決めます。

サンプルの fileMatch の例です。fileMatchPattern は1つなら文字列、複数なら配列で書けます。#[[file:パス]] で別のファイルを参照でき、パスはワークスペースのルートから数えます。

---
inclusion: fileMatch
fileMatchPattern: ["src/routes/**/*.ts", "src/schemas/**/*.ts"]
---
# API の決まり
- URL は複数形の名詞（/todos）。動詞を入れない。
- エラーは {"error": {"code": "...", "message": "..."}} の形で返す。
- 仕様の正本：#[[file:docs/openapi.yaml]]

auto は name と description の両方が必要です。

---
inclusion: auto
name: testing
description: Vitest のテストを書く・直すときの決まり。テストの追加や失敗の調査で使う。
---
# テストの決まり
- 1つのテストで確かめることは1つ。

AGENTS.mdも読まれる

Kiro は AGENTS.md にも対応しています。ワークスペースのルートか ~/.kiro/steering/ に置き、サブフォルダの AGENTS.md も見つけて読み込みます。AGENTS.md には inclusion の指定が効かず、常に読み込まれます。 他の AI ツールと決まりを共有したいときは AGENTS.md に書く、という分け方ができます。書き方は関連記事「AGENTS.mdの書き方テンプレ｜copilot-instructions比較」で扱っています。

front matterの書き間違いを検査する

ドキュメントには「front matter はファイルの最初の内容でなければならず、前に空行を入れない」とあります。空行が1行あるだけで、inclusion の指定は効きません。見た目では気づきにくいので、ドキュメントの決まり（先頭の位置・inclusion の値・必要な項目）を確かめる Python のスクリプトを書きました。hooks と mcp.json もあわせて見ます。

""".kiro/ の設定ファイルを、Kiro のドキュメントに書かれた決まりで確かめる"""
import json, pathlib, re, sys

root = pathlib.Path(sys.argv[1] if len(sys.argv) > 1 else ".") / ".kiro"
problems = 0

def ng(path, msg):
    global problems
    problems += 1
    print(f"NG  {path}: {msg}")

# 1. steering：front matter はファイルの先頭（前に空行なし）
for f in sorted((root / "steering").glob("*.md")):
    text = f.read_text(encoding="utf-8")
    rel = f.relative_to(root.parent)
    if not text.startswith("---\n"):
        if re.match(r"\s+---\n", text):
            ng(rel, "front matter の前に空行がある（inclusion が効かない）")
        else:
            print(f"OK  {rel}: front matter なし（always 扱い）")
        continue
    fm = dict(re.findall(r"^(\w+):\s*(.+)$", text.split("---\n")[1], re.M))
    mode = fm.get("inclusion", "always")
    if mode not in ("always", "fileMatch", "manual", "auto"):
        ng(rel, f"inclusion の値が不正: {mode}"); continue
    if mode == "fileMatch" and "fileMatchPattern" not in fm:
        ng(rel, "fileMatch なのに fileMatchPattern がない"); continue
    if mode == "auto" and not ("name" in fm and "description" in fm):
        ng(rel, "auto には name と description の両方が要る"); continue
    print(f"OK  {rel}: inclusion={mode}")

# 2. hooks：version v1・hooks 配列・name/trigger/action
for f in sorted((root / "hooks").glob("*.json")):
    rel = f.relative_to(root.parent)
    try:
        d = json.loads(f.read_text(encoding="utf-8"))
    except json.JSONDecodeError as e:
        ng(rel, f"JSON の書き方の誤り: {e}"); continue
    if d.get("version") != "v1":
        ng(rel, 'version が "v1" でない'); continue
    for h in d.get("hooks", []):
        a = h.get("action", {})
        if not all(k in h for k in ("name", "trigger", "action")):
            ng(rel, "name・trigger・action のどれかがない")
        elif a.get("type") == "command" and "command" not in a:
            ng(rel, "type=command なのに command がない")
        elif a.get("type") == "agent" and "prompt" not in a:
            ng(rel, "type=agent なのに prompt がない")
        else:
            print(f"OK  {rel}: {h['name']} ({h['trigger']} → {a.get('type')})")

# 3. MCP：command か url のどちらか。${VAR} は承認が要る
mcp = root / "settings" / "mcp.json"
if mcp.exists():
    d = json.loads(mcp.read_text(encoding="utf-8"))
    for name, s in d.get("mcpServers", {}).items():
        kind = "local" if "command" in s else "remote" if "url" in s else None
        if kind is None:
            ng(mcp.relative_to(root.parent), f"{name}: command も url もない"); continue
        envs = sorted(set(re.findall(r"\$\{(\w+)\}", json.dumps(s))))
        state = "disabled" if s.get("disabled") else "enabled"
        extra = f" 承認が要る環境変数={envs}" if envs else ""
        print(f"OK  {mcp.relative_to(root.parent)}: {name} ({kind}, {state}){extra}")

print(f"\n問題 {problems} 件")
sys.exit(1 if problems else 0)

先頭に空行を入れた bad-example.md を混ぜて実行した結果です。

python3 scripts/kiro_lint.py .

OK  .kiro/steering/api-design.md: inclusion=fileMatch
NG  .kiro/steering/bad-example.md: front matter の前に空行がある（inclusion が効かない）
OK  .kiro/steering/product.md: inclusion=always
OK  .kiro/steering/release.md: inclusion=manual
OK  .kiro/steering/tech.md: inclusion=always
OK  .kiro/hooks/guard-shell.json: Block risky shell (PreToolUse → command)
OK  .kiro/hooks/lint-on-save.json: Lint on save (PostFileSave → command)
OK  .kiro/settings/mcp.json: fetch (local, enabled)
OK  .kiro/settings/mcp.json: api-server (remote, disabled) 承認が要る環境変数=['API_TOKEN']

問題 1 件

空行を消すと、今度は inclusion: auto に name が無いことが分かりました。

NG  .kiro/steering/bad-example.md: auto には name と description の両方が要る

name を足して testing.md にすると、問題は0件になり、終了コードも0になりました。CI に入れれば、壊れた設定を push する前に止められます。

OK  .kiro/steering/testing.md: inclusion=auto
（中略）
問題 0 件
exit=0

hooksの書き方（.kiro/hooks）

hooks は、エージェントの動きやファイルの保存をきっかけに、コマンドやプロンプトを自動で実行する仕組みです。 プロジェクト用は .kiro/hooks/ に JSON で置きます（CLI V3 は ~/.kiro/hooks/ も読みます）。ファイル名は自由で、lint-on-save.json のようなケバブケースが勧められています。セッションの開始時に自動で有効になります。

ドキュメントの最初の例です。TypeScript のファイルを保存したら ESLint で直します。

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

ほかに enabled・confirm（実行前に確認の選択肢を出す）・description も書けます。IDE では Agent Hooks の + から「Ask Kiro to create a hook」を選び、やりたいことを文章で書くと、Kiro がこの JSON を作って保存します。IDE 0.x の .hook 形式は v1 の JSON に移り、移行前のファイルは移行するまで動きません。

hooksのきっかけ（トリガー）一覧

表の名前は画面の表記です。JSON の trigger には PostFileSave・PreToolUse・PostToolUse・Stop のような PascalCase の名前を書きます。Web のセッションではどの hooks も動きません。

commandとagentの違い（クレジットと終了コード）

Pre Tool Use の command が0以外で終わると、そのツールの呼び出しは止まります。 Prompt Submit で0以外なら、プロンプトの送信が止まります。この仕組みで「危ないコマンドを止める見張り役」を作れます。

危ないシェルを止めるhooksを作って試す

PreToolUse で、matcher にツールの種類 shell を指定します（ツールの種類は read・write・shell・web・spec）。

{
  "version": "v1",
  "hooks": [{
    "name": "Block risky shell",
    "trigger": "PreToolUse",
    "matcher": "shell",
    "timeout": 10,
    "action": { "type": "command", "command": "python3 scripts/guard_shell.py" }
  }]
}

呼ばれるスクリプトです。STDIN の JSON（ドキュメントの例では hook_event_name・cwd・session_id・tool_name・tool_input を含む）を読み、tool_input に決めた形があれば終了コード1で止めます。

"""PreToolUse フックから呼ぶ。STDIN の JSON を読み、危ないコマンドなら止める"""
import json, re, sys

event = json.load(sys.stdin)
text = json.dumps(event.get("tool_input", {}), ensure_ascii=False)

BLOCK = [
    (r"\brm\s+-[a-zA-Z]*r[a-zA-Z]*f|\brm\s+-[a-zA-Z]*f[a-zA-Z]*r", "rm -rf は使わない"),
    (r"\bgit\s+push\b.*(--force|-f\b)", "force push は人が行う"),
    (r"\.env\b", ".env には触れない"),
]
for pattern, reason in BLOCK:
    if re.search(pattern, text):
        print(f"blocked by guard_shell.py: {reason}", file=sys.stderr)
        sys.exit(1)   # 0 以外で、Kiro はこのツール呼び出しを止める

print("guard_shell.py: ok")
sys.exit(0)

フックに届く JSON と同じ形の入力を4通り作り、スクリプトだけを実行した結果です。

for cmd in 'npm test' 'rm -rf dist' 'git push origin main --force' 'cat .env'; do
  echo "(tool_input.command = $cmd)"
  printf '{"hook_event_name":"PreToolUse","cwd":"/home/user/todo-app","session_id":"demo","tool_name":"shell","tool_input":{"command":"%s"}}\n' "$cmd" \
    | python3 scripts/guard_shell.py
  echo "exit=$?"
done

(tool_input.command = npm test)
guard_shell.py: ok
exit=0
(tool_input.command = rm -rf dist)
blocked by guard_shell.py: rm -rf は使わない
exit=1
(tool_input.command = git push origin main --force)
blocked by guard_shell.py: force push は人が行う
exit=1
(tool_input.command = cat .env)
blocked by guard_shell.py: .env には触れない
exit=1

tool_input の中身の形はツールによって違うため、スクリプトは JSON 全体を文字列にして調べています。決まった操作を確実に止めたいときは、hooks に加えて次の節の permissions.yaml の deny も使うと、二重に守れます。

権限（permissions.yaml）で許可・拒否を決める

エージェントが何をしてよいかは、permissions.yaml の rules: に並べます。capability（shell・fs_read・fs_write・web_fetch・web_search など）と effect（allow・ask・deny）が必須で、match・exclude にグロブの形を書けます。ホーム全体用は ~/.kiro/settings/permissions.yaml です。ドキュメントに出てくる規則を組み合わせると次の形になります。

rules:
  - capability: shell
    match: ["git *", "npm *", "npx *"]
    effect: allow
  - capability: shell
    match: ["rm -rf *", "sudo *"]
    effect: deny
  - capability: fs_read
    match: ["**/.env", "**/*.pem"]
    effect: deny

チャットで承認を求められたときは、その1回だけの Allow・Deny か、規則として残す Always allow・Always deny を選べます。つないだコマンドは1つずつ承認を求められます。

MCPの設定（.kiro/settings/mcp.json）

MCP（Model Context Protocol）は、AI のツールに外部のデータや機能をつなぐための共通の決まりです。 Kiro では JSON の設定ファイルに MCP サーバーを書きます。

両方あるときは合わせて使い、同じ名前のサーバーはワークスペース側が優先されます。IDE ではコマンドパレットの「Kiro: Open workspace MCP config (JSON)」「Kiro: Open user MCP config (JSON)」で開けます。保存すると自動でつなぎ直します。

リモートのサーバーには oauth・oauthScopes もあります。値に ${API_TOKEN} のように環境変数を書けますが、Kiro が展開するのは、利用者が承認した変数だけです。IDE の設定で「Mcp Approved Env Vars」を探し、変数名を足します。承認していない変数には警告が出ます。

サンプルの mcp.json です。fetch はドキュメントの例と同じ形で、api-server はリモートの書き方の例として止めてあります。

{
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"],
      "disabled": false
    },
    "api-server": {
      "url": "https://api.example.com/mcp",
      "headers": { "Authorization": "Bearer ${API_TOKEN}" },
      "disabled": true
    }
  }
}

mcp.jsonのサーバーが出すツールを確かめる

MCP の設定で多いつまずきは「サーバーが起動しない」「思ったツールが出てこない」です。Kiro につなぐ前に、mcp.json に書いたのと同じコマンドでサーバーを起動し、MCP の initialize と tools/list を送って確かめられます。そのための小さな Python のクライアントです。

"""mcp.json の "fetch" と同じコマンドで MCP サーバーを起動し、tools/list を聞く"""
import json, subprocess, sys

conf = json.load(open(".kiro/settings/mcp.json"))["mcpServers"]["fetch"]
p = subprocess.Popen([conf["command"], *conf["args"]], stdin=subprocess.PIPE,
                     stdout=subprocess.PIPE, text=True)

def send(msg):
    p.stdin.write(json.dumps(msg) + "\n"); p.stdin.flush()

def recv():
    return json.loads(p.stdout.readline())

send({"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {
    "protocolVersion": "2025-06-18", "capabilities": {},
    "clientInfo": {"name": "demo-client", "version": "0.1"}}})
init = recv()["result"]
print("server:", init["serverInfo"]["name"], init["serverInfo"]["version"])
print("protocolVersion:", init["protocolVersion"])
send({"jsonrpc": "2.0", "method": "notifications/initialized"})
send({"jsonrpc": "2.0", "id": 2, "method": "tools/list"})
for t in recv()["result"]["tools"]:
    print("tool:", t["name"])
    print("  description:", t["description"].splitlines()[0][:90])
    print("  params:", ", ".join(f'{k}{"*" if k in t["inputSchema"].get("required", []) else ""}'
                                 for k in t["inputSchema"]["properties"]))
p.terminate()

実行結果です。uvx が初回に44個のパッケージを入れてから、サーバーが応答しました。* は必須の引数です。

server: mcp-fetch 2026.10.10
protocolVersion: 2025-06-18
tool: fetch
  description: Fetches a URL from the internet and optionally extracts its contents as markdown.
  params: url*, max_length, start_index, raw

ここに出た fetch が、Kiro パネルの MCP servers の欄に並ぶツールです。MCP のツールの内部の ID は mcp_サーバー名_ツール名 の形になり、hooks の matcher では @fetch や @fetch/fetch と指定できます。

MCP の仕組み（サーバーとクライアントの役割）は、関連記事「MCPとは？サーバーとクライアントの仕組みと設定例を図解」で扱っています。

Kiro CLIの使い方（kiro-cli）

Kiro CLI は、ターミナルで Kiro のエージェントを使うためのコマンドです。2026年4月の CLI 2.0 で、画面を持たずに動かすヘッドレスモードと Windows への対応が入りました。今は V3 の早期版も出ていて、kiro-cli --v3 で V3、--v2 で V2 のセッションを始めます。V3 で入った主なものは、Spec エージェント（/spec new 名前）、権限の分類ごとの許可、.kiro/hooks/*.json の hooks、/tangent による脇道の会話などです。

kiro-cliのサブコマンド一覧

CLI commands のページ（2026年10月13日更新）に載っている17個です。サブコマンドを付けずに kiro-cli と打つと chat になります。

どのコマンドにも付けられるのは --version（-V）・--help（-h）・--help-all（全サブコマンドのヘルプ）・--verbose（-v、重ねると詳しくなる）・--agent・--v3・--v2 です。

よく使うslashコマンド

対話の中では / で始まるコマンドを使います。50個以上あるうち、よく使うものです。

CI/CDで動かす（ヘッドレスモード）

画面を使わずに動かすときは、KIRO_API_KEY 環境変数に API キーを入れ、--no-interactive を付けます。API キーを作れるのは Pro・Pro+・Pro Max・Power の契約者です。

# 指示を引数で渡す
kiro-cli chat --no-interactive "your prompt here"

# V3 で、指定したツールだけ自動で許可する
kiro-cli chat --v3 --no-interactive --trust-tools=read_file,grep_search "Find all TODO comments in src/"

--trust-all-tools を付けると、そのセッションのすべてのツール呼び出しと hooks の確認が自動で許可されます。CI で使うときは、使い捨ての環境か、許可するツールを --trust-tools で絞る形が安全です。

Claude Code・Cursor・Clineとの違い（事実の比較）

各製品の公式ドキュメントの記載を並べます（2026年10月18日時点）。どれも MCP に対応し、プロジェクトの決まりをファイルで渡せます。違いは、決まりや自動化を置く場所と、計画を立てる仕組みです。

Kiro は「要件・設計・タスク」をファイルとしてリポジトリに残し、タスクの実行状態までその上で追う点が特徴です。Claude Code の使い方は、関連記事「Claude Code 使い方完全ガイド｜導入・コマンド一覧・エラー対処」で扱っています。Cline の使い方は、関連記事「Clineとは｜VS Codeでの使い方・Plan/Act・MCP・料金」で扱っています。

Kiroでよくあるエラーと直し方

IDE の Troubleshooting のページに載っているものと、設定ファイルの書き間違いをまとめます。

CLI で困ったときは、まず kiro-cli doctor を実行します。認証のエラーなら kiro-cli login でサインインし直します。

よくある質問

Q. Kiroとは何ですか？ A. AWS が提供する AI エージェントの開発環境です。要件・設計・タスクの仕様書（Spec）を先に作り、それに沿ってエージェントに実装させるのが特徴です。5つの形の違いは「Kiroとは：AWSのAI開発環境」の節にあります。

Q. Kiro IDEは無料で使えますか？ A. Kiro Free は月0ドルで、毎月50クレジット使えます（2026年10月18日時点）。使えるモデルはオープンウェイトのモデルと Claude Sonnet 4.5 で、回数の制限があります。

Q. Kiroを使うのにAWSアカウントは要りますか？ A. FAQ に「AWS アカウントがなくても使える」とあります。GitHub・Google・AWS Builder ID・組織のアカウントでサインインします。

Q. Kiro IDEとVS Codeの関係は？ A. Kiro の IDE は Code OSS をもとにしているため、VS Code の設定・テーマ・Open VSX 互換の拡張機能を取り込めます。

Q. Kiro CLIのインストール方法は？ A. 公式の案内は curl -fsSL https://cli.kiro.dev/install | bash です。入れたら kiro-cli login でサインインし、プロジェクトのフォルダで kiro-cli と打ちます。

Q. Kiroの返事を日本語にするには？ A. .kiro/steering/ のファイル（inclusion: always）に「回答は日本語で書く」と書いておくと、毎回の会話に読み込まれます。

まとめ

• Kiro は AWS の AI エージェントの開発環境。IDE・CLI・Web・Mobile・Crew が同じ仕組みと .kiro/ の設定を使う。
• 料金は Free（50クレジット）から Power（200ドル・10,000クレジット）まで。有料プランの1クレジット単価はどれも0.02ドル、追加は0.04ドル（2026年10月18日時点）。
• Spec は requirements・design・tasks の3ファイル。要件は EARS 記法で、タスクはまとめて実行するとウェーブに分けて進む。
• steering は front matter の inclusion で読み込む時を決める。前に空行があると効かない。
• hooks は .kiro/hooks/*.json。command はクレジットを使わず、Pre Tool Use で0以外を返すとツールを止められる。
• MCP は .kiro/settings/mcp.json。つなぐ前に同じコマンドで tools/list を確かめると、原因を切り分けやすい。

参考・出典

確認日はいずれも 2026年10月18日です。

• Kiro Documentation：https://kiro.dev/docs/
• Kiro「Pricing」：https://kiro.dev/pricing/
• Kiro「Downloads」：https://kiro.dev/downloads/
• Kiro「FAQ」：https://kiro.dev/faq/
• Kiro Docs「How Kiro works」：https://kiro.dev/docs/how-kiro-works/
• Kiro Docs「Installation」：https://kiro.dev/docs/getting-started/installation/
• Kiro Docs「Authentication」：https://kiro.dev/docs/getting-started/authentication/
• Kiro Docs「Build your first project」：https://kiro.dev/docs/getting-started/first-project/
• Kiro Docs「Specs」：https://kiro.dev/docs/specs/
• Kiro Docs「Feature Specs」：https://kiro.dev/docs/specs/feature-specs/
• Kiro Docs「Steering」：https://kiro.dev/docs/steering/
• Kiro Docs「Hooks」：https://kiro.dev/docs/hooks/
• Kiro Docs「Hook triggers」：https://kiro.dev/docs/hooks/types/
• Kiro Docs「Hook actions」：https://kiro.dev/docs/hooks/actions/
• Kiro Docs「MCP configuration」：https://kiro.dev/docs/mcp/configuration/
• Kiro Docs「Permissions」：https://kiro.dev/docs/permissions/
• Kiro Docs「Configuration scopes」：https://kiro.dev/docs/configuration/
• Kiro Docs「Available models」：https://kiro.dev/docs/models/available-models/
• Kiro Docs「Billing」：https://kiro.dev/docs/billing/
• Kiro Docs「CLI commands」：https://kiro.dev/docs/reference/cli-commands/
• Kiro Docs「Slash commands」：https://kiro.dev/docs/reference/slash-commands/
• Kiro Docs「What's new in V3」：https://kiro.dev/docs/cli/v3/
• Kiro Docs「Headless mode」：https://kiro.dev/docs/cli/headless/
• Kiro Docs「IDE Troubleshooting」：https://kiro.dev/docs/ide/troubleshooting/
• Kiro Docs「Migrating from Q Developer」：https://kiro.dev/docs/upgrade-guides/migrating-from-q-developer/
• Kiro Blog「Kiro CLI 2.0」：https://kiro.dev/blog/cli-2-0/
• Kiro（GitHub・README）：https://github.com/kirodotdev/Kiro
• Claude Code Docs「Overview」：https://code.claude.com/docs/en/overview
• Cursor Docs「Rules」：https://cursor.com/docs/context/rules
• Cursor Docs「MCP」：https://cursor.com/docs/mcp
• Cursor Docs「Hooks」：https://cursor.com/docs/hooks
• Cursor Docs「Modes」：https://cursor.com/docs/agent/modes
• mcp-server-fetch（PyPI）：https://pypi.org/project/mcp-server-fetch/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。