Kiroをチームで使う前に：Specs・Steering・Hooks・MCPを分ける基準

このテーマをもう少し広げて見るなら、AGENTS.md標準化の実務影響：AIコーディング指示ファイルをチーム運用に入れる判断基準 と MCP Registryからサーバーを選ぶ前に：OAuth・tool poisoning・allowlistの安全な見方 も合わせて確認してください。KiroのSteeringやSkillsと、repo共通のAGENTS.mdをどう分けるかを考える導線になります。

3行まとめ

Specs

要求、設計、タスクを分ける。

Steering

project知識をmarkdownで残す。

Hooks

反復作業をeventで自動化。

MCP

外部toolの入口を管理する。

Kiroは、実装前の合意をfileに残すところから始めます。

• Kiroは、自然言語の依頼をrequirements、design、tasksのSpecへ分け、実装前に合意を残せる点が強みです。いきなりコード生成へ進めず、phaseごとにreview gateを置きます。
• project横断の知識はSteering files、反復作業はAgent Hooks、外部toolはMCP Servers、配布可能なbest practiceはPowersへ分けると運用しやすくなります。
• 初回導入では、1つの小さなSpec、3つのSteering docs、MCPなし、軽いHookだけに絞り、実装速度よりレビュー可能性を確認します。

本文の事実確認には、Kiro公式docs、AWS documentation overview、Kiro Powers docsを使っています。Xで見かけるKiro、spec-driven development、steering files、agent hooks、MCPへの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Phase

requirements、design、tasksを分ける。

Context

steeringに置くproject知識。

Automation

hooksで何を自動化するか。

Tools

MCPとPowersの権限を確認。

Kiroは、vibe codingをspecに変える設計で使うと価値が出ます。

• KiroのSpecs、Steering、Hooks、MCP Servers、Powersの使い分け
• requirements、design、tasksをどこでreviewするか
• Steering filesに置くproject知識と、Specに置くfeature計画の違い
• Agent Hooksで自動化してよい作業と避けたい作業
• MCP ServerやPowerを入れる前の権限確認
• 初週にどこまで導入すればよいか

AI coding agentを使う時に難しいのは、コードが出ることではなく、何を作る合意だったのか、どの設計を選んだのか、どのtaskが終わったのかを後から追えることです。Kiroは、そこをSpecとしてfileに残す設計が特徴です。

この記事では、Kiroをチームに入れる前に、仕様化、project知識、自動化、外部tool、共有bundleを分けて整理します。

前提知識

項目	内容	見方
Specs		requirements、design、tasksを生成。
Steering		project contextをmarkdownで提供。
Hooks		fileやagent eventで自動実行。
Powers		MCP、steering、hooksを束ねる。

Kiroの拡張は、仕様化と自動化を別々に見ます。

AWS documentation overviewでは、Kiroを、promptをdetailed specsへ変換し、working code、docs、testsへ進めるagentic coding serviceとして説明しています。Kiro公式docsでは、KiroはSpecs、Steering、Hooksを備えたagentic IDEとして説明されています。

First project guideでは、Steering files、Specs、Hooks、MCP serversを実際のprojectで使う流れが説明されています。Steering docsは .kiro/steering/ に保存され、product、technical stack、project structure、conventionsなどをKiroへ伝えます。Specsはrequirements、design、tasksの3phaseでfeature計画を作ります。

この記事の扱う範囲

項目	役割
Specs	featureごとのrequirements、design、tasksを管理する
Steering files	project横断の知識、規約、stack、構造を伝える
Agent Hooks	file event、prompt lifecycle、tool use、spec task eventで自動処理する
MCP Servers	docs、database、APIなど外部tool/data sourceへ接続する
Powers	MCP、steering、hooks、guidanceをbundleとして共有する
Review gates	Spec phaseごとに人間が確認する場所

2026年5月31日時点で公開されているKiro公式docsとAWS documentation overviewを確認しています。導入時には、利用中のKiro version、teamのAI tool policy、MCP接続先、Hooksで自動実行する内容を確認してください。

注意点

この記事は、Kiroに大きなfeatureを丸投げするための記事ではありません。Specを使って、要求、設計、taskを人間がreviewできる状態にするための記事です。

まず4つの置き場所に分ける

項目	内容	見方
Spec		featureごとの合意と作業計画。
Steering		project横断の知識と規約。
Hook		eventで起きる自動処理。
MCP		外部toolやdata source。

実装taskを増やす前に、情報の置き場所を決めます。

Kiroをチームで使う時は、情報と実行の置き場所を4つに分けます。

置き場所	向くもの	避けたいもの
Specs	feature単位の要求、設計、task	project全体の永続的な規約
Steering	project構造、stack、coding standards	1featureだけの細かいtask
Hooks	file保存時やspec task前後の反復処理	大きな設計判断
MCP Servers	外部tool、API、docs、database	手順や規約の本文

この4つを混ぜると、Kiroが何を根拠に判断したのか追いにくくなります。たとえば、feature固有のacceptance criteriaをSteeringへ置くと、別featureにも効いてしまいます。逆にproject共通の規約をSpecへ閉じ込めると、次のfeatureで再利用されません。

Specをproject規約にしない

Specはfeature計画です。project規約やteam standardはSteeringやAGENTS.mdへ置きます。Specに毎回同じ規約を書くより、Steeringで共通化した方が更新しやすくなります。

Hookを暗黙の設計判断にしない

Hookは便利ですが、自動で起きる処理です。設計判断や承認が必要なことをhookだけに入れると、team memberが気づかないまま挙動が変わります。

Specsは要求・設計・タスクの合意に使う

1. Requirements

   user storiesとacceptance criteria。

2. Design

   architectureと実装方針。

3. Tasks

   実行可能なchecklist。

4. Execute

   task単位で実装する。

Specは、AIに任せる前の合意形成のfileです。

KiroのFirst project guideでは、Specがfeature ideaをdetailed implementation planへ変換する3phaseとして説明されています。Requirements phaseではuser storiesとacceptance criteria、Design phaseではtechnical architectureとimplementation approach、Implementation phaseではdiscrete tasksが生成されます。

Specは、AIに実装を任せる前の合意fileです。特にチームでは、requirements、design、tasksをまとめてreviewするのではなく、phaseごとに止めます。

requirementsで見るもの

観点	確認すること
scope	何を作り、何を作らないか
user story	誰が何のために使うか
acceptance criteria	完了条件がtest可能か
dependency	他teamや外部APIの前提

designで見るもの

designでは、architecture、component、data model、API、security、migration、rollbackを見ます。Kiroが提案した設計が既存構成と合っているかを確認します。

tasksで見るもの

tasksは、実装のchecklistです。順序、依存関係、test、docs、rollbackを見ます。taskが大きすぎる場合は分割します。1taskが1PRでreviewできる大きさかを見ると扱いやすくなります。

Steeringはproject知識に使う

Product

目的、domain、ユーザー。

Stack

framework、library、tool。

Structure

directory責務と境界。

Standards

coding規約やworkflow。

Steeringは、featureごとのspecではなくprojectの地図です。

Kiro公式docsでは、Steering filesを、projectに関するpersistent knowledgeをmarkdown filesで提供する仕組みとして説明しています。First project guideでは、Generate Steering Docsがrepositoryを分析し、.kiro/steering/ にproject steering documentsを作る流れが説明されています。

Steeringに向いているのは、featureごとに毎回説明したくないproject知識です。

Steeringに入れるもの

種類	例
product	productの目的、ユーザー、domain用語
technical stack	framework、library、runtime、test tool
project structure	directory構成、package責務、module境界
conventions	naming、error handling、logging、review基準
workflows	release、migration、test、docs更新

Steeringを長くしすぎない

Steeringは、Kiroが作業時に参照する知識です。社内規程の全文や古い議事録を入れる場所ではありません。長い文書はリンクし、Steeringには判断に必要な要点を残します。

Hooksは反復作業の自動化に使う

項目	内容	見方
File events		created、saved、deletedで動く。
Prompt lifecycle		prompt submitやagent stopを見る。
Tool use		pre/post tool useで制御。
Spec tasks		pre/post task executionで動く。

Hookは便利ですが、何が自動で起きるかを説明できるようにします。

Kiro公式docsでは、Agent Hooksを、file created/saved/deleted、manual trigger、file pattern変更などに応じてpredefined agent actionsを実行する仕組みとして説明しています。First project guideでは、file events、prompt and agent lifecycle events、pre/post tool use、spec task eventsなどのevent typeが示されています。

Hookに向くのは、繰り返し発生し、判断より手順が中心の作業です。

Hookに向く作業

trigger	例
file saved	React component保存時にtest stubを更新
file created	新規API route作成時にdocs雛形を作る
spec task	task実行後にchecklistやtestを更新
manual trigger	release note draftを生成する

Hookに向かない作業

設計承認、security exception、production deploy、secret更新、database migrationの本番実行はhookへ入れません。自動化するほど便利ですが、人間の判断が必要なものはreview gateを残します。

MCP Serversは外部toolの入口にする

項目	内容	見方
Docs		外部docsやknowledge source。
Database		schemaやqueryを扱う。
API		GitHubや社内APIに接続。
Security		secretとwrite権限を確認。

MCP追加は、Kiroへ新しい操作能力を渡す判断です。

Kiro docsでは、MCP Serversをexternal tools and data sourcesへ接続する機能として説明しています。Kiroのsiteでも、docs、databases、APIsなどへnative MCP supportで接続できると説明されています。

MCP Server追加は、Kiroに新しい操作能力を渡す判断です。SpecやSteeringは文脈ですが、MCPはtoolです。database、GitHub、observability、docs、internal APIへ接続する場合、read-onlyかwrite可能か、secretはどこにあるか、tool callを監査できるかを確認します。

MCP追加前の確認

観点	確認すること
接続先	docs、database、GitHub、社内API
権限	read-onlyかwrite可能か
secret	tokenやAPI keyの置き場所
scope	projectだけか、globalか
audit	tool callや外部接続の記録

MCPの更新や認可の確認は、MCP更新で壊さないための確認手順でも整理しています。KiroにMCPを追加する時も、server名、tool一覧、権限、失敗時の戻し方を確認します。

Powersは配布可能なbest practiceにする

POWER.md

activationとguidanceを持つ。

mcp.json

optionalなMCP設定。

Steering

domain知識を同梱。

Hooks

validationやworkflowを含める。

Powerは便利なbundleですが、公開・共有前に権限をreviewします。

Kiro Powers docsでは、Powerをbest practices from dev tool providers and domain expertsをencapsulateする仕組みとして説明しています。Powerには POWER.md、optionalな mcp.json、steering、hooksなどを含められます。

Powerは便利なbundleです。ただし、MCP、Steering、Hooksをまとめられるということは、文脈、tool権限、自動化をまとめて配るということでもあります。

Powerに向くもの

種類	例
documentation-only	framework patternsやcomponent rules
single-tool	1つのMCP serverと使い方
domain pack	database setup、API integration、deploy手順
validation pack	hooksでlint/test/docs確認を補助

共有前に見るもの

Powerをteamへ配る前に、含まれるMCP server、hook、steeringの内容をreviewします。公開GitHub repositoryからinstallする場合は、配布元、更新頻度、権限、secretの扱いも確認します。

Spec phaseごとにreview gateを置く

項目	内容	見方
Requirements		目的、scope、acceptanceを確認。
Design		architectureと影響範囲を確認。
Tasks		順序、test、rollbackを確認。
Implementation		diff、tests、risksを確認。

全部できてからreviewせず、phaseごとに止めます。

Kiroをチームで使う時の肝は、実装後にまとめてreviewするのではなく、Spec phaseごとにreviewすることです。

phase	reviewすること	NG例
Requirements	scope、acceptance criteria、非対象範囲	完了条件が曖昧
Design	architecture、data、API、security	既存構成と違う設計
Tasks	task粒度、順序、test、rollback	1taskが大きすぎる
Implementation	diff、tests、risks、not run	specとdiffがずれる

reviewを軽くするコツ

requirementsはPM/EMも見られる言葉にします。designは実装者とreviewerが見る技術文書にします。tasksはPR単位へ落とします。roleごとに見るfileを分けると、reviewが軽くなります。

最小構成の始め方

項目	内容	見方
One spec		小さなfeatureでspecを作る。
Three steering		product、tech、structureを作る。
No MCP		初回はtool追加を避ける。
One hook		docsやtest補助だけ試す。

初回はspecとsteeringを先に整え、tool権限は後から足します。

最初は、MCPやPowerを入れず、SpecとSteeringだけで始めます。

最初の構成

.kiro/
  steering/
    product.md
    tech.md
    structure.md
  specs/
    small-feature/
      requirements.md
      design.md
      tasks.md

product.md にはproductの目的、tech.md にはframeworkやtest tool、structure.md にはdirectory責務を書きます。Specは小さなfeatureに限定し、requirements、design、tasksを人間がreviewします。

初回に入れないもの

• write可能なMCP server
• production databaseへの接続
• deploy hook
• 複雑なPower
• 大きなfeatureの一括実装

最初は、Kiroがspecを作り、それをteamがreviewできるかを見るのが目的です。

導入初週の進め方

1. 1日目

   Generate Steering Docsを試す。

2. 2日目

   小さなSpecを作る。

3. 3日目

   requirementsとdesignをreview。

4. 5日目

   task単位で実装を進める。

5. 7日目

   hooksとMCP候補をreview。

初週は実装速度より、specがreviewできるかを優先します。

導入初週は、コード量を増やす週ではありません。Specが合意fileとして機能するかを確かめる週です。

日	やること	完了条件
1日目	Generate Steering Docsを試す	product、tech、structureが分かれる
2日目	小さなSpecを作る	requirementsがtest可能に書ける
3日目	requirementsとdesignをreview	scopeとarchitectureに合意できる
5日目	tasksを小さく分ける	1taskがreview可能な粒度になる
7日目	hooksとMCP候補をreview	自動化とtool権限を説明できる

拡大する条件

• requirementsが曖昧なまま実装へ進んでいない
• designに既存構成との関係が書かれている
• tasksがtestと結びついている
• Hooksで何が自動実行されるか説明できる
• MCP Serverの権限を説明できる

この条件を満たしてから、対象featureやteamを増やします。

FAQ

Spec or chat?

合意が必要ならSpecにする。

Steering or Spec?

project知識かfeature計画かで分ける。

Hook?

反復作業だけ自動化する。

MCP?

外部toolの権限として扱う。

迷ったら、実装前に誰がreviewする情報かを見ます。

Specと普通のchatはどう分けますか

調査や軽い修正はchatで十分です。要求、設計、taskを残してreviewしたいfeatureはSpecにします。複数人が関わる変更ほどSpecに向いています。

SteeringとSpecはどう分けますか

Steeringはproject横断の知識です。Specはfeature固有の計画です。coding規約やdirectory構成はSteeringへ、featureのacceptance criteriaやtaskはSpecへ置きます。

Hookは最初から入れるべきですか

最初は1つだけにします。docs更新やtest stub生成のような軽いものから始め、production deployやsecret操作はhookに入れません。

MCP Serverはいつ追加しますか

SpecとSteeringだけでは足りない外部toolが明確になってから追加します。database、GitHub、observabilityなどへ接続する場合は、read-onlyかwrite可能かを先に確認します。

他のagent導入にも使えますか

使えます。KiroのSpec phase reviewは、Codex、Claude Code、Cursorなどで大きなtaskを扱う時にも応用できます。repo共通の基準は、チーム向けAGENTS.mdテンプレートと組み合わせると管理しやすくなります。

---

次に読むなら

参照した主な情報源

• AWS Documentation Overview: Kiro

https://aws.amazon.com/documentation-overview/kiro/

• Kiro Docs: Get started

https://kiro.dev/docs/

• Kiro Docs: Your first project

https://kiro.dev/docs/getting-started/first-project/

• Kiro: Bring engineering rigor to agentic development

https://kiro.dev/

• Kiro Docs: Create powers

https://kiro.dev/docs/powers/create/

次に読むなら

更新履歴

1. 2026年5月31日

   Kiro公式docsとAWS documentation overviewを確認して初版を作成しました。

導入時には公式docsと利用中のKiro versionを確認してください。

• 2026年5月31日: Kiro公式docsとAWS documentation overviewを確認し、初版を作成しました。