Kiroの仕様書は発注や要件定義に使える？AWSのAI開発ツール「Spec」を発注者目線で解説

2026年9月24日2026年10月4日

「開発会社がKiro（キロ）というAIツールで仕様書を作っているらしい」「AIが作った要件定義書を、そのまま発注に使えないだろうか」。AI開発ツールの話題が増えるなかで、発注者の方からこうした相談を受けることが増えてきました。

「Kiroが作る仕様書を、発注や要件定義にそのまま使えるのでしょうか？」

先に結論をお伝えします。Kiroが作る要件の文書（requirements.md）は、発注の「下書き」や受入条件の「たたき台」としては十分に役立ちます。ただし、業務上の判断（何を優先するか、例外をどう扱うか）はAIには決められず、契約書の代わりにもなりません。発注者が業務の言葉で確認・修正したうえで、開発会社とすり合わせる材料として使うのが現実的です。

この記事では、Kiroの仕様駆動開発の仕組み、試し方、要件定義やRFP（＝開発会社に提案を依頼するための要望書）への活かし方、注意点を発注者向けに解説します。製品情報は執筆時点（2026年9月）のものです。

Kiroとは？「先に仕様書を作ってからAIに作らせる」AI開発ツール

Kiroは、AWS（アマゾンウェブサービス）が開発・運営するAI開発ツールです。2025年7月にプレビュー版として公開され、2025年11月17日に一般提供（GA）が始まりました。公式サイトでも「AWSが構築・運営している」と説明されています。

📰 出典：Kiro公式サイト

📰 出典：Kiro公式ブログ「Kiro is generally available」（2025年11月17日）

公式ブログでは、Kiroの特徴として「仕様駆動開発（spec-driven development）」が挙げられています。これは、AIにいきなりプログラムを書かせるのではなく、まず要件・設計・作業計画を文書にし、人が確認してから実装に進む進め方です。

📰 出典：Kiro公式ブログ「Introducing Kiro」（2025年7月14日）

執筆時点では、パソコンにインストールして使うエディタ（IDE）のほか、ターミナルで使うCLI、ブラウザで使う「Kiro Web」などが用意されています。Kiro Webは2026年9月1日に一般提供が始まりました。

📰 出典：Kiro Changelog「Kiro Web is now generally available」（2026年9月1日）

KiroのSpec（仕様書）で作られる3つの文書

Kiroでは、機能ごとの仕様書を「Spec（スペック）」と呼びます。1つのSpecは、次の3つのファイルで構成されます。

📰 出典：Kiro Docs「Specs」

ファイル	中身	発注者にとっての意味
requirements.md（要件）	ユーザーストーリー（＝「誰が・何のために・何をしたいか」）と受入条件	要件定義書・受入条件のたたき台
design.md（設計）	技術的な構成、処理の流れの図、実装上の考慮点	開発会社の設計の考え方を知る資料
tasks.md（作業計画）	要件と設計から分解した実装作業の一覧と進み具合	進捗や作業範囲の確認材料

作り方には、要件から始めて設計・作業へ進む「要件ファースト」と、技術的な設計から始めて要件を導く「設計ファースト」の2種類があります。発注者が関わりやすいのは、業務でやりたいことから書き始める要件ファーストです。

各段階では、人が内容を確認して承認してから次へ進みます。要件ができた段階で、矛盾・あいまいさ・抜けをKiroに分析させる機能（Analyze Requirements）も用意されています。なお、承認を挟まず3段階を一気に作る「Quick Spec」もありますが、発注の材料にするなら段階ごとに確認するほうが安心です。

📰 出典：Kiro Docs「Feature Specs」

EARS記法の受入条件の読み方

requirements.mdの受入条件は、EARS（イアーズ、Easy Approach to Requirements Syntax）という書き方で書かれます。公式ドキュメントでは、次の型が示されています。

WHEN［条件・きっかけ］ THE SYSTEM SHALL［システムがすべき動き］
意味：「〜のとき、システムは〜しなければならない」

「いつ（どんな条件で）」と「システムが何をするか」を1文ずつに分けるので、あいまいさが減り、1つの条件をそのまま1つのテスト項目にしやすいのが利点です。

たとえば、受注管理システムの要件なら、次のような形になります（筆者が作成した説明用の例で、Kiroの実際の出力ではありません）。

WHEN 担当者が必須項目の空欄のまま受注を登録しようとしたとき THE SYSTEM SHALL 空欄の項目名を画面に表示し、登録しない
WHEN 受注金額が100万円以上のとき THE SYSTEM SHALL 上長の承認が済むまで出荷指示を出さない
WHEN 月末締め処理が完了したとき THE SYSTEM SHALL その月の受注データを変更できないようにする

発注者が読むときのポイントは3つです。

条件（WHEN）が自社の業務と合っているか：「100万円以上」の基準は本当に正しいか
例外が抜けていないか：締め処理後に訂正が必要になったら誰がどうするのか
「SHALL」の後ろが確認できる形か：「使いやすくする」のように測れない表現になっていないか

こうした業務のルールは、AIが推測で書いた部分が混ざりやすいところです。1行ずつ「うちの業務では本当にこうか」を確かめることが、発注者の一番大事な役割です。

Kiroを試す手順（要件の下書きを作ってみる）

自社で要件の下書きを作ってみたい場合の、おおまかな流れです（執筆時点・2026年9月）。

📰 出典：Kiro Docs「Installation」

Kiroを用意する：公式サイトからIDEをダウンロードしてインストールします（macOS・Windows・Linuxに対応）。有料プランならKiro Webをブラウザで使う方法もあります
サインインする：Google、GitHub、AWS Builder ID、または組織のアカウント（AWS IAM Identity Centerや外部の認証サービス）から選びます。会社で使うなら、どの方法でサインインするかを先に決めてください（データの扱いが変わるため。後述）
空のフォルダを開き、背景を伝える：作りたいシステムの目的や業務の流れを、チャットで文章で伝えます。開発会社への伝え方（発注メモ）の内容がそのまま材料になります
Specを要件ファーストで作る：requirements.mdができたら、Analyze Requirementsで矛盾や抜けを洗い出します
業務の言葉に直して確認する：社内の担当者と一緒に読み、条件や数値を修正します

顧客名や取引金額などの実データは入力せず、架空の値に置き換えて試すのが安全です。

ステアリングとフックは「プロジェクトのルール」と「自動化」

Kiroには、Spec以外にも発注者が名前を聞く機会の多い機能があります。

ステアリング（Steering）は、プロジェクトの前提をMarkdown（＝簡単な記号で書く文章形式）のファイルに書いておき、AIに毎回読ませる仕組みです。標準では、製品の目的（product.md）、使う技術（tech.md）、ファイル構成（structure.md）の3つが作られます。いわば「このプロジェクトのルールブック」です。

📰 出典：Kiro Docs「Steering」

フック（Hooks）は、「ファイルが保存されたら」「AIが作業を終えたら」などのきっかけで、決めた処理を自動実行する仕組みです。書式チェックやテストの実行、関連文書の更新などに使われます。

📰 出典：Kiro Docs「Hooks」

発注者にとっては、「品質のルールをツールに組み込んでいるか」を開発会社に尋ねる手がかりになります。

発注者・経営者として決めること（プランとデータの扱い）

会社でKiroを使う場合、費用よりも先にデータの扱いを確認してください。

📰 出典：Kiro Docs「Data protection」

利用形態	入力内容のサービス改善への利用
無料プラン（Free）	利用されうる（設定でオプトアウト可能）
個人の有料契約（Google・GitHub・AWS Builder IDでサインイン）	利用されうる（設定でオプトアウト可能）
企業向け（組織のアカウントで管理）	利用されない

公式ドキュメントでは、サービス改善にはモデルの学習も含まれうると説明されています。社内の業務情報を扱うなら、組織アカウントでの契約を検討するか、少なくとも設定で「Content Collection for Service Improvement」をオフにしておきましょう。

料金は、無料プラン（月50クレジット）から、Pro（月20ドル）、Pro+（月40ドル）、Pro Max（月100ドル）、Power（月200ドル）、個別見積もりのEnterpriseまであります（執筆時点・2026年9月）。クレジット（＝AIを使った分だけ減る利用枠）制で、上限を超えた分は追加購入や超過課金になります。Kiro WebはPro以上のプランが対象です。

📰 出典：Kiro Pricing

📰 出典：Kiro Docs「Kiro Web」

仕様書をRFPや受入条件の下書きに使う方法

筆者の見解として、Kiroの仕様書は次のように使うと発注に役立ちます。

RFPの「機能要件」の下書きにする：requirements.mdのユーザーストーリーを、業務の言葉に直してRFPに載せます。ただし目的・予算・期限・体制はRFPに自分で書き足す必要があります
受入条件のたたき台にする：EARSの1行が、そのまま「完成したか」を確かめる検査項目の候補になります。最終的な受入基準は、開発会社と合意して契約書類に反映します
「決まっていないこと」を見つける：AIが推測で埋めた部分や、Analyze Requirementsで指摘された点は、社内で決めるべき論点の一覧になります

design.mdやtasks.mdは、使う技術や作業の分け方を開発会社が決める部分です。発注者が作った設計を「この通りに作って」と渡すと、開発会社の提案の幅を狭めてしまうことがあります。発注者が主に使うのはrequirements.mdだと考えるとよいでしょう。

開発会社がKiroを使っている場合に確認すること

開発会社がKiroを使っているなら、Specを共有してもらうと進み具合や認識のずれを確認しやすくなります。公式ドキュメントでも、Specはソースコードと一緒にリポジトリ（＝ソースコードの保管場所）で管理し、チームで共有する使い方が案内されています。

📰 出典：Kiro Docs「Specs best practices」

一方で、発注者から預けた情報をどのプラン・どのサインイン方法のKiroに入力しているかは、情報管理の観点で確認しておきたい点です。また、途中で要件が変わったときにSpecをどう更新し、費用や納期にどう反映するかも決めておきましょう（関連：仕様変更はどこまで許される？判断の考え方）。

Kiroの仕様書の注意点・限界

業務の判断はAIにはできない：優先順位、例外の扱い、承認ルートなどは、AIがもっともらしく推測して書くことがあります
契約書の代わりにはならない：作業範囲・検収・責任分担は、契約書や合意した仕様書で定めます。契約の個別判断は専門家にご相談ください
正しさの保証ではない：Kiroには、プログラムがSpecどおりに動くかを多数のテストで確かめる機能（プロパティベーステスト）がありますが、公式ブログでも「検証や証明ではない」と説明されています。人による確認と受入テストは引き続き必要です
機能や料金は変わりやすい：執筆時点（2026年9月）の情報です。導入前に公式ドキュメントで最新情報を確認してください