KiroとGitHub Copilotのいちばんの違いは「進め方」です。
Kiroは、仕様書・設計書を作ってから開発する流れが最初から組み込まれた開発環境。
GitHub Copilotは、いつものエディタやGitHubの上で、書いているコードを手伝ってくれるAIアシスタント。
私の使い分けは、ゼロから作るときはKiro、GitHubで管理しているコードを直すときはGitHub Copilotです。
こんにちは、オロポンです。
私はPoC（試作・検証）から始めることが多いR&Dの仕事で、Kiroを第一候補にしています。この記事では、2つの違いと、私がKiroを選んでいる理由、GitHub Copilotを使い始めて感じたことをまとめます。
- KiroとGitHub Copilotの違い（表で比較）
- PoC中心の仕事でKiroを第一候補にしている理由
- Kiroでつまずいた「仕様書の置き去り」と、公式ドキュメントにある対処
- 2つの料金と、どちらが向いているか
先にお伝えしたい、私の経験の範囲
両方を同じくらい使い込んだうえでの比較ではありません。
使い方の差が大きいので、先に正直に書いておきます。
- Kiro：ゼロからのPoC開発やアジャイル開発で、第一候補として使っています。使い始めて3か月目です。
- GitHub Copilot：とあるプロジェクトにて、GitHubでソースコードを管理し始めてから使い始めたばかりです。今のところ、リファクタリングと機能の追加でしか使っていません
なので、GitHub Copilotについては「使い始めた段階で感じたこと」として読んでください。
ちなみに私は、新米ITエンジニアです（プロフィール）。
KiroとGitHub Copilotの違いを表で比較
まずは違いを表で整理します。
| 比べるところ | Kiro | GitHub Copilot |
|---|---|---|
| どんなツールか | 仕様駆動開発が組み込まれたAI開発環境 | エディタやGitHubで使うAIアシスタント |
| 使う場所 | Kiro専用のIDEのほか、CLI・Web版など | VS Code、Visual Studio、JetBrains IDE、Eclipse、Xcode、GitHub.com、CLIなど |
| 進め方 | 要件→設計→タスクを文書にしてから実装 | 書いているコードに、補完やチャットで手を貸す |
| プロジェクトのルールの伝え方 | Steering（ルールを書いたファイル） | 指示（instructions）や再利用できるプロンプト |
| 外部ツールとの連携（MCP） | 対応 | 対応 |
| 無料プラン | あり（月50クレジット） | あり（補完は月2,000回までなど上限あり） |
| 個人の有料プラン | 月20ドルから | 月10ドルから |
※機能と料金は2026年11月1日時点の公式情報です。
Kiroは「何を・どう作るか」を先に文書にする開発環境
Kiroの中心は「Specs（スペック）」という機能です。
作りたいものをAIに伝えると、次の3つのファイルを順番に作ってくれます。
- requirements.md（要件）：何ができればいいか。「〇〇のとき、システムは△△する」という決まった書き方で並びます
- design.md（設計）：どういう仕組みで作るか。構成や処理の流れなど
- tasks.md（タスク）：実装の作業リスト。進むと「完了」に変わっていきます
これが「仕様駆動開発」です。
噛み砕くと、「作る前に、AIと一緒に何を・どう作るかを文書にしてから進めるやり方」です。要件から始める流れのほか、設計から始める流れも選べます。
ほかにも、プロジェクトのルールを覚えさせる「Steering」や、ファイルの変更などをきっかけに処理を自動で動かす「Hooks」があります。
GitHub Copilotは「いつもの場所で手伝ってくれる」AIアシスタント
GitHub Copilotは、今使っているエディタやGitHubに入って手伝ってくれるツールです。
主にできることは次のとおりです。
- 入力中のコードの続きを提案する（補完）
- コードについての質問に答える（チャット）
- 目標を伝えると、複数の手順を進めてファイルを編集する（エージェントモード）
- プルリクエストのレビューや、プルリクエストを作るところまで任せる（Freeでは対象外か制限あり）
エディタを乗り換えなくてよいのが、大きな特徴だと思います。
機能はほぼ同じ。違いは「進め方」
機能の表だけを見ると、差は小さく見えるかもしれません。
違いが出るのは、どこから始めるかです。
Kiroは「まだ何もないところで、作るものを文書で固める」のが得意です。
GitHub Copilotは「すでにあるコードを直したり、機能を追加していく」のに向いているツールだと感じています。
実際、私も「ゼロから作るときはKiro」「GitHubでコードを管理し始めてからはCopilot」と、開発のフェーズで使い分けています。
PoC中心のR&DでKiroを第一候補にしている理由
私の仕事は、PoCから始めることが多いです。
そんな中でKiroを選んでいる理由は、大きく3つです。
理由1：仕様駆動開発の流れが最初から組み込まれている
Kiroは、要件→設計→タスクの流れが最初から用意されています。
自分でテンプレートや手順を用意しなくても、Kiroの流れに乗るだけで「仕様を固めてから開発する」形になります。
理由2：機能を足すときの影響を、仕様書・設計書から読み取ってくれる
PoCでは、機能を追加しながら開発のサイクルを回していきます。
Kiroは、機能を追加するときに、その影響を仕様書や設計書から読み取り、影響が大きい順に変更案を出してくれます。
そのおかげで、「この機能を足したら、今ある機能が壊れないか」と過度に怯えずに、サイクルを回していけます。
理由3：「なぜそうしたか」が仕様書に残り、後から振り返りやすい
Kiroでは、チャットでやり取りしながら要件を固めていきます。
そのため、仕様書に「なぜそうしたのか」という設計の考え方が残ります。
後から振り返るときに、決めた理由をたどりやすいのも助かっています。
ドキュメントが足りないまま進んだPoCの「後追い」にも使える
もう1つの使い方が、ドキュメントを後から作ることです。
PoCでは、仕様書・設計書を十分に作らないまま開発の段階に入ってしまうことがあります。そんなときも、Kiroでドキュメントを作るのに使っています。
Kiroは、要求仕様書や設計書のベースを作ってくれます。
ベースがあるだけで、ドキュメント作業の負担が減りました。AIを使って楽になったと感じているのが、まさにここです。
Kiroでつまずいたこと：Vibeで機能を変えると、仕様書が置き去りになる
便利なKiroですが、つまずいたこともあります。
それが「コードとドキュメントのずれ」です。
起きたこと：Specで作ったあと、Vibeで直すと文書が古いままになった
Kiroには、仕様駆動で進める「Spec」と、仕様を使わずにチャットで頼む進め方があります。この記事では、仕様を使わない進め方を、私の呼び方で「Vibe」と書きます。
なお、公式ドキュメントによると、旧版（IDE 0.x）には「Vibe mode」「Spec mode」を最初に選ぶ形がありました。今の版（IDE 1.x）は会話から始まり、途中で「Build with spec」を押すと仕様駆動に切り替わります。
最初にSpecで仕様書・設計書を作って開発しました。
そのあと、一部の機能をVibeで変えると、コードは変わるのに設計書や仕様書は前のままになることがありました。ドキュメントだけが過去に取り残される形です (T . T)
置き去りになった仕様書をどうしたか
そのときは、もう一度Specで進める形に戻し、Kiroにコードを読ませて、仕様書と設計書に反映させました。
公式ドキュメントに書かれている、仕様書を最新に保つ方法
ここからは、私が試した方法ではありません。
Kiroの公式ドキュメント（ベストプラクティスのページ）で確認できた内容です。
- 要件を変えるとき：requirements.md を直接書き換えるか、Specの会話でKiroに追加を頼む
- 設計を変えるとき：Specの会話で design.md の更新を頼むと、新しい要件に合わせて直してくれる
- タスクを合わせるとき：tasks.md の「Sync Files」で、新しい要件に合ったタスクを作れる。Specの外で実装した分も、完了の印を付けてくれる
- チャットから直すとき：チャットで「#spec」を付けると、仕様書の全ファイルを会話に含めて変更を頼める
- Vibeの会話から仕様を作るとき：Vibeの会話のあとに「Generate spec」と伝えると、その会話の内容から要件を作ってくれる
注意したいのは、Sync Files が「コードの変更を設計書に自動で書き戻す」機能とは書かれていない点です。
公式の手順を見る限り、機能を変えるときは、先に仕様書側を直してから実装に進むのがよさそうです。
GitHub Copilotを使い始めて感じたこと
ここからは、使い始めたばかりのGitHub Copilotの話です。
使った場面が2つだけなので、感想もその範囲にとどめます。
今はリファクタリングと機能の追加で使っている
GitHubでコードを管理し始めてから、リファクタリング（動きを変えずにコードを整理すること）と、機能の追加で使っています。
AIの出力は、そのまま使わずに確認する
Kiroにも言えることですが、AIが出したコードや文書は、自分で確認してから使うのが前提だと考えています。
また、仕事でAIツールを使うときは、コードや情報の扱いを会社のルールに合わせることが大前提です。
料金とプランの違い（2026年11月1日時点）
料金は変わりやすいので、ポイントだけまとめます。
金額はどちらもドル建てです。Kiroの表示価格には税が含まれていません。
Kiroの料金
- Free：0ドル。月50クレジット
- Pro：月20ドル。月1,000クレジット
- 上位に、Pro+（40ドル）、Pro Max（100ドル）、Power（200ドル）
クレジットは、使った量に応じて減るポイントのようなものです。
毎月のクレジットは翌月に繰り越されません。有料プランなら追加購入もできます。日本の住所で請求する場合は、消費税がかかると書かれています。
GitHub Copilotの料金
- Free：0ドル。補完は月2,000回までなど、上限あり
- Pro：月10ドル
- 上位に、Pro+（39ドル）、Max（100ドル）
- 会社向けに、Business（1人あたり月19ドル）、Enterprise（1人あたり月39ドル）
コードレビューや、プルリクエストを作るエージェントは、Freeでは対象外か制限があり、Pro以上で使えます。
認証された学生向けの無料プランもあるようです。
どっちを選ぶ？ 向いている人・向いていない人
Kiroが向いている人
- ゼロから何かを作る、PoCや新しい機能の開発が多い人
- 仕様書・設計書を残しながら進めたい人
- 機能を足しながら、開発のサイクルを回していく人
- 作る前に、何を作るかをはっきりさせたい人
反対に、今のエディタを変えたくない人には、乗り換えの手間が気になるかもしれません。
GitHub Copilotが向いている人
- 今使っているエディタのまま、AIに手伝ってほしい人
- GitHubで管理しているコードを、直したり整理したりすることが多い人
- プルリクエストのレビューまで、GitHubの上で済ませたい人
反対に、仕様書づくりから任せたい人には、Kiroのほうが流れに合うと思います。
迷ったら、両方の無料プランで試す
どちらも無料プランがあるので、まずは触ってみるのが確実です。
私のように「最初はKiro、GitHubで管理し始めたらCopilot」と、開発の段階で分ける使い方もできます。
私自身も未経験からこの仕事に移った身なので、偉そうなことは言えません。それでも、私が最初に触るならKiroをおすすめします。
まとめ：ゼロから仕様を固めるならKiro、GitHubで育てたコードを直すならCopilot
- KiroとGitHub Copilotの違いは、機能よりも「進め方」
- Kiroは仕様駆動開発が組み込まれていて、機能追加の影響や「なぜそうしたか」も仕様書で追えるので、PoCから始める仕事と相性がよい
- Kiroで機能を変えるときは、仕様書の置き去りに注意
- GitHub Copilotは、GitHubで管理しているコードの整理（リファクタリング）や機能の追加で使っている
AIへの指示の出し方で迷っている方は、AIへのプロンプトの書き方もどうぞ。
開発の流れ（要件・設計など）をまず知りたい方には、システム開発の入門書の記事も参考になると思います。
【プロンプトで激変する】AIへの「お願いの仕方」で結果が全然変わった話
【システム開発初心者へ向けた一冊】概要が分かるだけでも全然違います
ご参考までに、以上！
※アイキャッチ画像は、AIで作ったイメージ画像です。実際の製品画面ではありません。