Amazon Kiro IDE 完全ガイド 2026 — Claude Codeユーザーが乗り換えるべき？フリーランスエンジニア視点
Amazon Kiro IDEをフリーランスエンジニア目線で徹底検証。Claude Codeとの料金・機能比較、steering filesとCLAUDE.mdの違い、移行コスト、AWS案件あり/なし別の乗り換え判断フロー。実際に触れてわかった正直な結論。
エンジニアのゆとです。
KiroがGAになった時、正直「またAI IDEが増えた」と思った。CursorとClaude Codeを使い分けているフリーランスとして、ツールの乗り換えコストは地味にきつい。
でも調べていくうちに、Kiroの設計思想が他のAI IDEと根本的に違うことに気づいた。「補完が賢くなったエディタ」でもなく「CLIで丸投げできるエージェント」でもない。開発プロセスの構造そのものを変えようとしているツールだ。
この記事では、Claude Codeユーザーとして「Kiroに乗り換えるべきか」を判断軸ごとに正直に整理する。料金比較、機能の深掘り、移行コストの試算まで含めて書く。
Amazon Kiroとは — 2026年5月に何が変わったか
Kiroは2025年夏のプレビュー後、2026年5月に一般提供（GA）が開始されたAWS製のAgentic IDE。ベースはVS Codeで、見た目や操作感はほぼVS Codeと同じだ。
2026年7月時点では、Pro Maxプラン（$100/月）の追加、Kiro CLI（ターミナル単体で使えるCLIツール）、チェックポイント機能（エージェントの実行履歴をロールバック）、マルチルートワークスペース対応など、機能が矢継ぎ早に追加されている。
Claude CodeやCursorとの位置づけ比較
3ツールの立ち位置を整理するとこうなる。
| ツール | カテゴリ | 主なアプローチ |
|---|---|---|
| Claude Code | CLI型AIエージェント | 自然言語で丸投げ |
| Cursor | エディタ型AI補完 | 書きながらAIサポート |
| Kiro | Agentic IDE | 仕様から実装まで一貫管理 |
Cursorは「コードを書く手を速くする」ツール。Claude Codeは「やることを伝えたら全部やってもらう」ツール。Kiroは「書く前に仕様を固めて、そこからコードを生成する」ツールだ。
Cursor vs Claude Codeの比較記事でも書いたが、Claude Codeの強みは「コードベースの文脈を理解した上で、自律的にタスクを完了する能力」にある。Kiroはそこに「実装前の仕様定義フロー」を組み込んだ設計になっている。
「spec-driven development」とは何か
Kiroの核心は、コードを書く前に「仕様を定義する」フローを強制する点にある。
通常のAI IDEなら「こういう機能を作って」と伝えたらいきなりコードが出てくる。Kiroの場合、こういう順番になる。
- プロンプトで要件を伝える
- KiroがRequirements Document（要件定義書）を生成、承認を求める
- 承認後、Design Document（設計書）を生成
- 承認後、Task List（実装タスク一覧）を生成
- タスク一覧を承認したら実装開始
一見手間に見えるが、「作ってみたら全然違うものだった」という問題を事前に潰せる。規模が大きい機能になればなるほど、このフローの費用対効果が上がる。
Kiro IDEの主要機能を全部使った
steering files（.kiro/steering/*.md）— CLAUDE.mdとの違い
Claude Codeを使っていると、CLAUDE.mdの設定が開発体験に大きく影響する。Kiroにも同じ概念がある。それがsteering filesだ。
場所は .kiro/steering/ ディレクトリ。複数のMarkdownファイルを置ける。CLAUDE.mdとの最大の違いは「いつ読み込むか」を制御できる点だ。
各ファイルのYAMLフロントマターで4種類のinclusionモードを指定する。
# 常に読み込む（プロジェクト全体のコーディングルール）
---
inclusion: always
---
# 特定ファイルを編集する時だけ読み込む
---
inclusion: fileMatch
fileMatchPattern: "components/**/*.tsx"
---
# 手動で参照する時だけ（チャットで #ファイル名 で呼び出す）
---
inclusion: manual
---
# Kiroが文脈を見て自動判断して読み込む
---
inclusion: auto
name: api-design
description: REST API設計パターンとエンドポイント命名規則
---CLAUDE.mdは基本的に1ファイルに全部書く（インポートで分割は可能だが、自動の読み込み制御はない）。steering filesは役割ごとにファイルを分けて、適切なタイミングでのみ読み込む設計だ。
例えば「フロントエンドのコーディング規約」ファイルをfileMatchで components/**/*.tsx にバインドしておくと、バックエンド作業中には読み込まれない。コンテキストウィンドウを効率よく使える。
グローバルsteering（~/.kiro/steering/）も設定でき、全プロジェクト共通のルールを一元管理できる。CLAUDE.mdとCLAUDE.local.mdの関係に似ているが、ファイル分割の粒度がはるかに細かい。
specs機能 — 要件定義からタスク分解まで自動化
specs機能は、Kiroのアイデンティティとも言える機能だ。.kiro/specs/ ディレクトリに機能ごとのspecファイルが生成される。中身はrequirements.md、design.md、tasks.mdの3点セット。
「複雑な機能を一発で実装して」と投げると、大抵途中で迷子になる。それを防ぐのがspecsの役割で、実装前に設計のすり合わせが強制的に起きる。
チーム開発なら、このspecsファイルが仕様書として機能する。変更履歴もgit管理できるので、「なぜこの設計にしたのか」が後から追える。ソロ開発だと「分かってるからいい」と飛ばしたくなるが、後から振り返る時に役立つ。
Agent Hooksとautomationsの使い所
Agent Hooksは「イベントをトリガーにエージェントを自動実行する」機能だ。
例えばファイルを保存するたびにユニットテストを自動生成させたり、コミット前にドキュメントを更新させたりできる。Claude Codeのhooksと似た発想だが、KiroはIDEとしてイベント検知の粒度が細かい。
ただ正直、使いすぎると「何が裏で動いてるか分からない」状態になりやすい。目的を絞った使い方が正解だと感じた。
コスト比較: Kiro vs Claude Code、どっちが安い？
Preview無料期間とGA後の見通し
プレビュー期間中はProに相当する機能が無料で使えていた。GA後に課金が始まり、現在は以下の料金体系になっている。
| プラン | 月額 | クレジット |
|---|---|---|
| Free | $0 | 50 credits |
| Pro | $20 | 1,000 credits |
| Pro+ | $40 | 2,000 credits |
| Pro Max | $100 | 5,000 credits |
| Power | $200 | 10,000 credits |
追加クレジットは$0.04/クレジット。
クレジット消費量はモデルとタスクの複雑さ次第で大きく変わる。Claude Opus 4.8（最高性能）を使うと重いタスクで一気に減る。オープンウェイトの軽量モデルなら消費が抑えられる。
「月1,000クレジットでどれくらい動くか」は、実際に使ってみないと分からない部分がある。プレビュー期間にガシガシ使っていた人は、Proプランで足りなくなる可能性がある。
フリーランスが月$20を2枚使う価値があるか
Claude Code Pro（$20/月）とKiro Pro（$20/月）を両方使うと月$40になる。
この$40が合理的かどうかは案件の種類次第だ。Claude Codeは月額で「5時間ウィンドウ内のSonnet使い放題」という使い勝手の良さがある。Kiroはクレジット制なので「いくら使ったか」を意識しながら使う必要がある。
タスクごとのコスト感が見えやすいのはKiro、「とにかく気にせず動かしたい」ならClaude Codeの方が性質に合っている。
フリーランスエンジニアが「Kiroに乗り換えるべき」条件
AWS案件メインならKiro一択に近い理由
AWS CDK / SAM / Lambda案件では、Kiroのステアリングファイルにサービスのパターンを書いておくことで、提案の精度がかなり上がる。KiroとAWSサービスの統合は、他社クラウドとの組み合わせより明らかに深い。
さらにKiro CLIをCI/CDパイプラインに組み込むと、仕様変更を起点にコードが自動更新されるフローも作れる。IaC管理をしているAWS案件では、ここが強い。
ソロ開発 vs チーム開発で変わる判断
ソロ開発でKiroのspecsをフルに活用するのは、コスパが微妙だ。
specsで要件定義書を作っても、承認するのは自分。設計書を丁寧に書いても、レビューするのも自分。この「儀式」に時間を使うくらいなら、Claude Codeで丸投げして後から調整する方が速い場面が多い。
チームでKiroを使う場合は話が変わる。steering filesを共有リポジトリで管理して、全員が同じコンテキストを持てる。specsが設計のすり合わせツールとして機能する。コードレビューの前段階として、specsでの仕様確認が自然に入ってくる。
フリーランスで「クライアントのチームに入って開発する」スタイルなら、相手チームがKiroを使っているかどうかが判断の分岐点になる。
Claude Code + Kiro 併用という選択肢
実際に両方使ってみた感想として、「用途を明確に分けると共存できる」と感じた。
- 大きな機能の初期設計 → KiroのspecsでRequirementsとDesignを固める
- 実装の細かい部分の自律実行 → Claude Code
- プロジェクトルール管理 → Kiroのsteering（チーム共通）/ CLAUDE.md（個人設定）
この使い分けが今のところ一番効率よかった。ただし月$40になるので、収益がしっかり出ている状態でないと続けにくい。
Claude Codeユーザーが移行する際の実際のコスト
CLAUDE.mdをステアリングファイルに変換する手間
CLAUDE.mdをKiroのsteering filesに移行すること自体は、技術的には難しくない。Markdownをコピーして、YAMLフロントマターにinclusionモードを指定するだけだ。
ただ、CLAUDE.mdはプロジェクト全体に対して1枚で書くことが多い。それをsteering filesの「何を、どのタイミングで読み込むか」という設計に落とし込むには、少し考え直しが必要になる。
目安として、CLAUDE.mdがシンプルなもの（1,000字以内）なら数時間で移行できる。複雑な条件分岐やプロジェクト固有の設定が積み上がっている場合は、半日〜1日は見た方がいい。
既存スキル・フローの再構築工数
Claude Codeで自作しているスキルファイル（.claude/commands/*.md）は、KiroのAgent Hooksで代替できる場合が多い。でも1対1で移植できるわけじゃない。
Claude Codeのサブエージェント構成やカスタムコマンドをしっかり作り込んでいる場合、その再構築に1〜2週間は見た方がいい。「引っ越しのコスト」として最初から計算に入れておく必要がある。
移行コストを考えると、「いきなり全移行」より「新規プロジェクトからKiroを試す」の方が現実的な進め方だと思う。
結論: ゆとの判断
正直に言うと、今すぐ全移行はしない。
理由は3つある。
第一に、Claude Codeで積み上げてきたCLAUDE.mdとカスタムスキルの資産がある。これを一気に捨てるのは合理的じゃない。
第二に、今の案件がAWS案件メインじゃない。KiroのAWS統合の旨みを活かせる案件構成になってから本格移行を検討する。
第三に、Kiroはまだ進化の途中だ。2026年6月にPro Maxプランが追加されたように、料金体系も機能もどんどん変わっている。半年後に「あの時待って正解だった」となる可能性がある。
一方で、Kiroの仕様駆動フローは本物だと感じた。specsによる「作る前に設計を固める」プロセスは、Claude Codeにはないアプローチだ。チームで大きいものを作る案件が入ったタイミングで、本格的に使ってみるつもりだ。
フリーランスとしての現時点の判断:
- AWS案件あり / チーム開発が多い → Kiroを試す価値が高い
- AWS案件なし / ソロ開発がメイン → Claude Codeのまま継続
- どちらか迷う → まずKiro Freeで1週間触れてから判断する
「Kiro vs Claude Code」の答えはスペック表の比較じゃなく、自分の案件種別に照らし合わせると見えてくる。
