Busabase × AWS KiroKiroのナレッジベース
Kiroはアイデアを要件、設計、実行可能なタスクへ変換します。Busabaseは、そのSpecを取り巻くステークホルダー判断を、チームやリポジトリを越えてレビュー・所有・追跡できる状態にします。
3つのSpec成果物
Kiroは実装を構造化する。その成果物はリポジトリに置く。
Kiro Feature Specはrequirements.md、design.md、tasks.mdを生成します。要件はuser storyとacceptance criteria、設計はアーキテクチャ、タスクは実装を管理します。KiroはSpecを対象コードと一緒にバージョン管理することを推奨しています。
requirements.md振る舞い
User story、制約、受け入れ基準
design.md方法
アーキテクチャ、データフロー、エラー、テスト戦略
tasks.md実行
個別作業、依存関係、完了状態
別の所有レイヤー
プロダクトの約束は、1つのリポジトリSpecより広い。
技術成果物はリポジトリが所有します。同じ要件がプロダクト計画、顧客との約束、コンプライアンス、サポート準備、複数リポジトリへ影響するとき、Busabaseが正式な業務判断を扱います。Specをリンクし、編集可能な複製を作りません。
| 情報 | 保存先 | 正式な所有者 |
|---|---|---|
| コーディング標準・プロジェクト文脈 | .kiro/steering/ または AGENTS.md | リポジトリ |
| 機能要件、設計、タスク | .kiro/specs// | リポジトリ |
| コード変更とテスト | Commit / Pull Request | Gitプロバイダー |
| チーム横断の要件と受け入れ判断 | 構造化記録 + Change Request | Busabase |
追跡チェーン
最初の要求を、出荷を証明する証拠までつなぐ。
このチェーンは継続的な修正に耐える必要があります。Kiroが設計を変更し、要件変更後にタスクを同期しても、業務記録は承認された要件バージョン、実装証拠、最終責任者を示します。
変更の影響
Specが動いたら、他に誰が判断すべきかを示す。
Kiroは要件を洗練し、設計やタスクを再生成できます。しかしリポジトリ外への影響は自動解決されません。小さな影響マトリクスでSpec変更を明確なレビューキューへ変えます。
受け入れ台帳
Specを取り巻く判断を、次のフローが検索できるフィールドにする。
記録はKiroファイルとGit証拠を参照し、競合しません。次のフィールドで、何を、どのバージョンで、誰が、どの条件で受け入れたか答えられます。
| フィールド | 用途 |
|---|---|
| requirement_id | Kiro Specと共有する安定した識別子 |
| spec_url | 要件、設計、タスクへのバージョン付きリンク |
| accepted_behavior | 維持すべき業務レベルの結果 |
| implementation_ref | Pull Request、commit、build、deployment |
| verification | テスト結果と実行時証拠 |
| decision | 提案、受け入れ、条件付き、拒否、置換 |
| owner | 受け入れ判断に責任を持つ人 |
| effective_at | 依存チームが判断を使える時点 |
自動化の役割は限定的
Hookはチェックを強制できる。ステークホルダーの受け入れは代行できない。
Kiro Hooksはライフサイクルイベントでshell commandやagent promptを実行します。PreToolUseとPreTaskExecutionはブロックでき、PostFileSaveやAgent Stopは結果を集められます。証拠生成や提案開始に使い、業務判断は別にレビューします。
PostFileSave証拠Lint、型チェック、対象テストを実行
PreTaskExecution実行ゲート必要入力がなければ作業を停止
Agent Stop + confirm提案トリガーsession結果を提出するか確認
Busabaseレビュー正式判断範囲、証拠、責任者、影響を確認
履歴を失わずに修正
Specは1か所で変更し、受け入れリンクは意図的に更新する。
Kiro Specsは継続的なrefinementとタスク同期を支援します。正式記録が動くブランチ内容を曖昧に指さないよう、バージョン付きGit参照を使います。承認済み要件が大きく変わる場合は、履歴を上書きせず後継判断を提案します。
接続の境界
ナレッジページは所有関係を、接続ページはMCPを説明する。
KiroはIDE、CLI、Web、Mobileで共通のAgent harnessと.kiro設定を使い、各作業面に固有の挙動があります。Workspaceまたはuser MCP設定からBusabaseへ接続できます。endpoint、OAuth、scope優先順位、検証手順は保守される接続ページを使います。
Spec駆動チームの質問
KiroナレッジベースのFAQ
BusabaseはKiro Specsの代わりですか？
いいえ。requirements.md、design.md、tasks.mdはコードの隣でバージョン管理します。Busabaseはより広いsystem of recordが必要なチーム横断要件、受け入れ判断、責任者、運用状態を管理します。
すべてのSpecにBusabase記録が必要ですか？
いいえ。他チーム、他リポジトリ、顧客との約束、統制、リリース工程が結果に依存するときに作ります。ローカル実装だけの詳細はSpecとGit履歴に残せます。
Kiro Hookは要件を自動承認できますか？
Hookはチェック、アクション停止、提案開始ができます。しかしステークホルダーが業務上の影響を受け入れたことは確定できません。判断は明示された責任者に残します。
システム間の安定したリンクは何ですか？
requirement_idと、バージョン付きspec_urlまたはcommit SHAを使います。後のレビューで受け入れた内容を確定できないため、可変ブランチだけをリンクしません。
Quick Specでも同じフローを使えますか？
使えます。ただしKiroはQuick Specを、標準の段階レビューなしで全成果物を生成する方式と説明しています。影響の大きい作業では、正式範囲とする前に要件分析と受け入れレビューを加えます。
次の受け入れポイントから始める
1つのKiro Specに、リポジトリ外の責任者を置く。
チームをまたぐ機能を選び、現在のSpecと証拠をリンクし、依存作業が進む前に最初の受け入れ判断をレビューします。