Feature Spec Builder

「一言」を「開発級の機能要件」に変換する。

核心はドキュメント作成ではなく、システム的に一言に含まれていない情報を掘り起こし、補完すること。一句「XX機能が必要」には、通常80%の開発必須情報（役割、シナリオ、境界、能力の帰属、インターフェース、依存関係、検収条件）が欠けています。本スキルは「固定次元スキャン＋インタラクティブな逐次質問による明確化」という方法でこれらのギャップを埋め、最終的に開発レビューを通過できる機能要件を生成します。

本スキルの成果物は機能要件で止まります——インターフェース契約草案と受入基準は含みますが、タスク分割や実装計画は行わず、それらは開発チームに委ねます。

設定セクション（初回使用前に入力）

本スキルは、製品固有の座標系とチームの合意事項に依存して分類と連携を行います。プレースホルダーを実際のチーム定義に置き換えてください。テーマごとにグループ化されており、使用しないグループはデフォルトのままでも構いません。

A. 能力座標系

L1 = <例 原子能力 / 低レベル動作・認識インターフェース>
L2 = <例 組み合わせ能力 / アプリケーションレベルの開発キット>
L3 = <例 完全ソリューション / シナリオデリバリー>
五つの領域：領域1=<…> 領域2=<…> 領域3=<…> 領域4=<…> 領域5=<…>

B. インターフェース規定

API 予算 = <例 上限300メソッド>   言語/バインディング規定 = <例 C++ core + pybind11>

C. インテグレーターと形態

インテグレーター等級 = <例 Associate / Professional / Expert>   形態 = <シミュレーション / 実機 / 両方>
出力ディレクトリ = <デフォルト feature-specs/；成果物は <このディレクトリ>/<機能名>/<機能名>.md に書き出す>

D. プロダクト原則（成果物出力前のセルフチェックゲートの基準）

デフォルトの組み込み原則を使用：はい / いいえ（デフォルト＝はい、全文は references/product-principles.md 参照）
チームカスタム／補足原則：<空のままでも可；記入した場合はデフォルトとマージし、競合はチームの定義を優先>
競合優先順位：<2つのハード制約（安全デフォルト、後方互換性）は上書き不可。両者が衝突した場合は必ず人間による判断にエスカレーション。その他の原則の相対的な優先順位はここに記入。空欄の場合は、競合発生時に一律でユーザーに判断を委ね、自動ソートは行わない>
破壊的変更の承認者：<破壊的変更と判定された場合に誰の承認が必要か、例 プラットフォームアーキテクチャ責任者>

E. 実装レイヤー × 部門マッピング（ステップ4のクロスレイヤー分解でのowner割り当て用。L-Tierとは直交——L-Tierは外部抽象度の高さを管理し、実装レイヤーは内部でどの技術スタック・部門を動かすかを管理する）

実装レイヤー → 担当部門/役割 owner → クロスレイヤー承認者
  実行時レイヤー：
    二次開発SDKレイヤー            → <記入、例 SDK/プラットフォームチーム>   → <承認者>
    低レベルソフトウェア(ファームウェア・ミドルウェア)  → <記入、例 組み込み/ファームウェアチーム> → <承認者>
    アルゴリズムサービス(認識・アルゴリズム)  → <記入、例 アルゴリズムチーム>       → <承認者>
    ハードウェア(機械・電子)        → <記入、例 ハードウェア/電子チーム>   → <承認者>
  非実行時レイヤー（エコシステム/統合/ドキュメント系の機能はこちらに該当。無理にファームウェア/アルゴリズム/ハードウェアチームに割り当てない）：
    ドキュメントポータルレイヤー      → <記入、例 DevRel/ドキュメント/サイトフロントエンド> → <承認者>
    ビルド/配布基盤レイヤー        → <記入、例 SDK ビルド/DevOps>      → <承認者>
  クロス部門エスカレーションパス = <例 レイヤーowner → 部門責任者 → 部門横断アーキテクチャレビュー会 → CTO>

設定セクションが未記入の場合： 少なくともAグループ（能力階層＋五つの領域）は埋めること。この2つは分類精度を直接左右します。その他のグループの代替処理——

A/B/C未記入：分類（自動分類ステップ）時に「以下のL階層/領域/予算/バインディングは私の推定です」と明示し根拠を添える。本文でこの座標系を使用するフィールド（階層、能力領域、API予算、バインディング規定。これらは「能力の位置づけ」「影響評価・互換性・リリース戦略」「インターフェース契約草案」の各セクションに分散）には一律に [確認待ち] とマークし、推定値を確定値として決して書かない。「設定セクションの実際の値は未補完」を「未解決・確認待ち」セクションに記述する。

D未記入：デフォルトで references/product-principles.md の組み込みデフォルト10項目を適用し、「製品原則セルフチェック」セクションに「今回のセルフチェックでは組み込みデフォルトの製品原則を使用します」と注記する。製品原則セルフチェックゲートはいかなる場合でも実行し、設定セクションが空だからといって省略してはならない。

E未記入：ステップ4のクロスレイヤー分解におけるowner/部門/承認者は一律に [確認待ち・要割当] とマークし、ユーザーに補完を促す。決して部門名を捏造してはならない——推定した部門責任を誤ったチームに割り当てることは最も危険な失敗である。

F. 組織とプロセス（ローカルプライベート設定、会社全体での連携用）

各企業の「誰が何を担当するか、どのプロセスゲートを通過するか、バージョンをどうスケジュールするか」は異なり、機密情報であるため、このスキルには記述しない。会社全体での連携に使用する場合、references/org-process-config.md のテンプレートをローカルの org-process.local.md としてコピーする（または scripts/init-org-config.sh を実行して生成する）。それに基づき、自社のロールマップ/デリバリーゲート/バージョンリズムとパイプライン容量を記入する。ローカルでプライベートに管理し、コミットしない（.gitignore に含まれている）。

この設定がある場合：成果物において、ロールマップに従ってownerを実際の責任者に割り当て、「影響評価・互換性・リリース戦略」に通過必須のゲートと成果物をリストアップし、ターゲットバージョンと工数(人日) vs パイプライン容量を記載し、要件ロック後の変更はCCB（変更管理委員会）を経由する（詳細は references/org-process-config.md 参照）ことを示す。

この設定がない場合：汎用的なロールプレースホルダーを使用する（例：[プロダクトマネージャー・未割当]）。また、ユーザーにローカル設定を生成できることを通知する。いかなる場合でも、実際の人名/内部プロセスをこのスキルに記述したり、公開されるドキュメントに出力したりしてはならない。

ワークフロー

断片的な要件を受け取った後、以下のメインパスに従って進めます。

断片受信 → 要件分割（暗黙の複数機能を特定） → 自動分類 → クロスレイヤー分解とルーティング（各レイヤーの変更・owner・依存順序を特定） → 第一層の明確化（位置づけ・粗粒度） → 第二層の明確化（機能詳細・細粒度） → 成果物ドキュメント作成（原則セルフチェックゲート通過）

ステップ1：受信と復唱

ユーザーから断片を読み込む。最初に自分の理解を一文で復唱する（「私の理解では、あなたが求めているのは…ということでよろしいでしょうか？」）。ユーザーに確認または修正を促す。このステップで最初から誤った方向に進むのを防ぐ。

ステップ2：要件分割（暗黙の複数機能を含むかどうかを特定）

断片的な要求には、複数の要件が含まれていることがよくあります——特にチャットやメールの原文をそのまま貼り付けた断片は、最も目立つ主要求だけでなく、他にも散在する要求や、会話に引きずられた質問、目標から逆推論される暗黙の能力が含まれています。最初に目立つ要求に飛びついて作業を始めるのではなく、まず分割スキャンを実行します。

断片を読み通し、独立して成立しうる要求を全てリストアップする（1つのアクション／1つの能力＝ 1つの候補機能）。特に、見落とされがちな4つのタイプに注意する：① 質問の流れに引きずられた「最初の質問」；② 主要求とは無関係で、同じ会話の中で言及された独立した要求；③ 開発チームが「未サポート／自前実装が必要」と回答した点（埋もれた隠れ需要であることが多い）；④ 顧客の最終目標から逆推論されるが、現在明示されていない組み合わせ能力。
異種成果物ヒューリスティック： 1つの要求の中に異なる成果物の形態（実行可能コード/インターフェース契約/ドキュメント内容/サイト構造/配布パッケージ）が同時に出現する場合、優先的に複数機能を疑う——異なる成果物の形態は、異なるowner、異なる検収方法、異なるメンテナンスサイクルに対応することが多く、混在して記述すると1つのmdファイル内でレビュー対象と検収基準が矛盾するためである（例：「ROSのサンプルを提供＋公式サイトにセクションを追加」＝コード機能＋ドキュメント機能であり、ownerと検収が根本的に異なる）。
単一情報源を共有する関連機能クラスター： 分割した複数の機能が単一の情報源を共有する場合（例：ドキュメントチュートリアル＝サンプルリポジトリコード＝メイン機能契約の外部投影）、それぞれ独立した文書として作成するが、各文書の「依存関係と前提条件」/関連機能において、情報源の帰属を明示的に固定し（どの文書/リポジトリが定義権を持つか、その他は投影/参照である）、クラスター内依存関係図を提供する——「レイヤー間引き渡し契約」の「定義権の帰属」パラダイムを再利用し、複数の文書間でバージョンが一致しない事態を避ける。
要求が1つだけであることが確実な場合は、「単一機能確認済み」と記録し、直接分類に進む。
複数の要求がある場合は、要求分割表（候補機能｜元の発言｜性質｜現状｜主要求との関係/依存）を作成する。その後、ユーザーに今回詳細化するものを決定させる——これはスコープの取捨選択であり、代わりに決めてはならない。選択されなかったものは、「未解決・確認待ち」セクションに「関連機能プレースホルダー」として残し、後日個別に起案できるようにする。
複数の機能を同時に進める場合、各機能に対して独立した機能要件ドキュメントをそれぞれ1つずつ作成する。複数の要件を1つの文書に混在させてはならない——それぞれ後続のステップを個別に進め、相互には「関連機能」として参照し合い、依存関係を明確にする（例：D は A+B に依存）。注意：1つの機能が複数レイヤーにまたがる場合でも、mdファイルは1つだけ作成し、内部で読み手対象別にセクションを分割する。複数ファイルに分割しない。これは「同一機能内でのレイヤー分割/読み手対象分割」であり、「複数機能のそれぞれ独立した文書化」と矛盾しない。

このステップはワークフロー全体で最もスキップされやすく、最も成果物の正確性に影響を与えるステップです。これをスキップすると、開発チームが入手する要件は顧客の要求の一部しかカバーしていなかったり、本来独立すべき複数の機能を1つにまとめてしまったりする可能性があります。

ステップ3：自動分類

要件を座標系に固定する。L1/L2/L3のどの階層に該当するか、五つの領域のうちどの領域に該当するか、領域をまたぐかどうか。分類自体が最初の問題を露呈します——きれいに分類できない場合、断片のある次元で情報が不足していることを示しており、それが後に明確化すべきギャップです。分類の不確かな点は記録しておく。

注意：分類で固定するのは外部抽象度（L-Tier）と能力領域であり、「この件が内部でどの実装レイヤーを動かし、どの部門に属するか」には答えません——それは次のステップ4の仕事です。L1インターフェースは二次開発レイヤーのみを動かすこともあれば、ファームウェア/アルゴリズム/ハードウェアまで動かすこともあります。

L-Tier の非実行時特性に対する N/A 出口： 特性の本質が既存能力のデリバリー/配布/インストール/ドキュメント形態である場合（新しい実行時能力ではなく、APIを公開せず、API予算を消費しない。例：オフラインインストールパッケージ/サンプルリポジトリ/公式サイトのセクション——プロトタイプH/I）、L-Tier は明示的に N/A（能力特性ではなく、実装レイヤー軸のみ該当） とマークし、五つの領域も N/A とマークして、無理にL値を割り当てない。判定シグナル：成果物が「配布パッケージ/ドキュメント/サイト構造」であり、「実行時API/動作」ではない。その重心はビルド/配布基盤レイヤーまたはドキュメントポータルレイヤー＋外部依存軸（ステップ4）に移る。

ステップ4：クロスレイヤー分解とルーティング（クロスレイヤー特性は必須）

分類は「Lのどの階層か、どの領域か」に答えるだけです。このステップではさらに**「この要件はどの実装レイヤーを動かすか、各レイヤーの担当者は誰か、順序はどうか、二次開発だけで独立してデリバリーできるか」**に答えます。多くの顧客要件は二次開発SDKレイヤーにあるように見えても、実際にはより低いレイヤー——ファームウェア/ミドルウェア、アルゴリズムサービス、さらにはハードウェア——に強く依存しており、これらのレイヤーは異なる部門に属することがよくあります。

references/cross-layer-routing.md の判定問題を使用して5つのタスクを実行します。

レイヤーごとに要変更かどうかを判定：二次開発SDKレイヤー / 低レベルソフトウェア(ファームウェア・ミドルウェア) / アルゴリズムサービスレイヤー / ハードウェアレイヤーの4つの実行時レイヤーに対して、レイヤーごとに「このレイヤーで何を変更する必要があるか」を問う。さらに、2つの非実行時レイヤーについても必ず問う（エコシステム/統合/ドキュメント系特性の重心はここにあることが多い）：ドキュメントポータルレイヤー（公式サイトのセクション、サンプルリポジトリ、ドキュメントIA——ownerはDevRel/ドキュメント/サイトであり、開発チームではない）とビルド/配布基盤レイヤー（パッケージング、マルチ環境CI、ABI/プリコンパイル——ownerはSDKビルド/DevOps）。⚠ 成果物がサンプル/パッケージング/インストール/配布/ドキュメントの場合（プロトタイプH/I）、技術的な範囲が純粋な二次開発であっても、デフォルトで二次開発SDKチームに割り当てない——設定セクションEグループに従って対応するownerにルーティングする（無理にファームウェア/アルゴリズム/ハードウェアチームに割り当てたり、デフォルトで二次開発チームに任せたりするのは、危険な誤割り当てである）。「二次開発レイヤーのみの変更で、ポータル/基盤の変更はない」と明確に答えられる場合は、「単一レイヤー特性（二次開発SDK）」と記録し、ステップ5に進む。
最下位変更レイヤー（ハードゲート）＋実現可能性の反証：変更が必要な最下位レイヤーを見つける。あるレイヤーが「サポートしない/不確か」と答えた場合、二次開発→ファームウェア→アルゴリズム→ハードウェアと順に下位レイヤーを探っていき、底に到達するまで行う（サポート可能なレイヤーを見つけるか、物理的に不可能と判定する）。レイヤー到達結論（3択） を示す：A 純粋な二次開発でデリバリー可能 / B クロスレイヤーでデリバリー可能 / C 現状のレイヤーではデリバリー不可能（下位レイヤーが未スケジュールまたは物理的制約）。最下位変更レイヤーが二次開発SDKレイヤーでない場合、本特性は二次開発レイヤーだけで独立してデリバリーできるものではない——ドキュメントの顕著な位置にマークを付ける：⚠ 二次開発レイヤーで独立デリバリー不可：本特性の最下位変更レイヤーは <レイヤー>、<owner部門> が <能力> を先にデリバリーする必要があり、その後で二次開発レイヤーがラップできる、そして「能力の位置づけ」セクションとDoRに記述する。ハードウェア/物理的制約に達した場合、二次開発レイヤーでのインターフェースシグネチャの詳細化を直ちに停止する——実現不可能な契約草案を書き続けることは、レビュー拒否の頻発原因である。
クロスレイヤー分解表の作成＋依存順序の整理＋レイヤー間引き渡し契約の策定：各レイヤーで何を変更するか、owner部門、上位レイヤーをブロックするかどうかをリストアップする。ボトムアップの依存チェーンを整理する。各クロスレイヤー依存に対して、「下位レイヤーが上位レイヤーに何を公開するか」の引き渡し契約を固定する（定義権の帰属を含む——両部門がそれぞれ異なるバージョンを作成して整合しないことを避ける）。
ownerとクロス部門の確認待ち項目の特定（各項目には帰属3要素を付与）：どのレイヤーの「変更の要否/サポート可否」が自分では判断できず、対応部門に確認する必要があるか（例：「ファームウェアはビームフォーミングをサポートするのか」）をリストアップし、クロス部門確認待ち項目とする。本スキルの使用者（通常はプロダクト/SDK側）はセッション中に下位レイヤー部門からの実際の回答を得られないため、単に [確認待ち] とマークしてリストに入れるだけでは不十分——各項目には必ず3要素を付与する：確認owner（誰がその部門と連携するか）｜どのレビューの前に回答が必要か｜期限までに回答がない場合のデフォルトの前提/フォールバック案（閾値に関する [確認待ち] の「責任者＋方法＋期限」と同じパラダイム）。これらはしばしば要件全体のクリティカルパス上のボトルネックとなる。
結論B/Cの場合の必須対応：実際の成果物をメイン記述に書き戻す（「疑似準備完了」を防ぐ）：レイヤー到達結論がBまたはCの場合、必ず「一言定義」とP1ストーリーを修正し、今回の実際のデリバリー可能な成果物のみを記述する（例：「今回のデリバリーはSDKスタブ＋シグネチャ。ビームの実際の能力はファームウェアQ4に依存」）。決して顧客の元の要求の完全な能力をP1として記述してはならない——そうしないと、開発/顧客が読む準備完了ドキュメントと実際にデリバリー可能なものが一致せず、最も危険な疑似準備完了となる。下位レイヤーが「サポートせず、スケジュールもなし」の場合、「クロスレイヤー実装と部門間連携」セクションでフォールバック/フェーズ分割案（モックスタブ / 限定的なレベル / シミュレーション先行）を提示し、単に確認待ちを付けるだけでは不十分。

結論Cかつ二次開発レイヤーが今回独立してデリバリー可能なもの（スタブを含む）を何も持たない場合の早期停止出口： 反証により、本特性が現在実質的に下位レイヤー/ハードウェアの変更であり、二次開発側でスタブすら意味がないことが確認された場合、ステップ5、6の次元別明確化を続行しない（それは [確認待ち] で埋め尽くされた空のシェルを生成するだけで、対話予算を浪費し、範囲規律自体に反する）。直接、簡潔な**「クロスレイヤールーティング結論」**を生成する：レイヤー到達結論＋クロスレイヤー分解表＋クロスレイヤーブロックとエスカレーションパス＋顧客向けの説明。そして明示的に「本要件は現在、二次開発レイヤーのタスクではありません。<部門> への起案を提案します」と注記する。

成果物の形態：1つの機能＝ 1つのmdファイル（読み手対象別に分割）。単一レイヤーでもクロスレイヤーでも、1つの機能は1つの機能要件ドキュメントのみを作成する。クロスレイヤー/クロス部門の内容は複数ファイルに分割せず、同一のmdファイル内で読み手対象別にセクションを分割する（プロダクト/レビュー、二次開発SDK、ファームウェア、アルゴリズム、ハードウェア）。そしてドキュメント上部に**「読み方ガイド」**を配置し、「読み手対象 → 読むべきセクション → それぞれの責任」を明確にすることで、1つの要件ドキュメント内で全体をトレースできるようにする。読み手対象別のセクションテンプレートと読み方ガイドのテンプレートは references/cross-layer-routing.md《九》を参照。

出力は、出力テンプレートの「クロスレイヤー実装と部門間連携」セクションに記入する。

このステップの結論は、ステップ5、6で問うべき質問リストを書き換えます：例えば、顧客が set_microphone_beam_angle ビームインターフェースを要求した場合、このステップでファームウェアがまだビームフォーミングをサポートしていないことを確認できれば、ステップ5ではまず「アルゴリズム/ハードウェアへのカスケードを受け入れますか？今回のスコープはSDKプレースホルダーのみですか？」を明確にすべきであり、直接インターフェースシグネチャを尋ねるべきではありません。

なぜ独立したステップであり、位置づけの前に配置するのか： 「実はファームウェアを動かす必要がある」要件を通常の二次開発特性として処理してしまうと、「一見開発チームが着手できるように見えて、実際には下位レイヤーにその能力がない」という疑似準備完了ドキュメントが生成されます——これが最も危険な失敗モードです。このステップを前置きすることで、DoRの前にまず「疑似二次開発特性」を防ぎます。

「インタラクティブ明確化ルール」に従う： クロスレイヤー分解表において、owner、あるレイヤーの変更要否、下位レイヤーのサポート有無が推定である場合は、一律に [確認待ち] とマークし、明確化質問として1つずつユーザーに投げかける（1度に1問、選択肢付き）。決して推定した部門/owner/依存関係を確定値として表に記入してはならない——このステップは自然とowner表を一気に埋めたくなる誘因がありますが、それはユーザーに代わって「ownerは誰か、どのレイヤーを変更するか」を決定することになります。

ステップ5：第一層の明確化——位置づけ（粗粒度）

「第一層・位置づけ次元」をチェックリストとして使用し、断片と照らし合わせて答えられていない次元をリストアップする。「インタラクティブ明確化ルール」に従って1つずつ明確にする。この層では特性の形状を定める：それは何か、どの層・どの領域に属するか、境界はどこか、どのような形態か。1度に1つの質問のみ行う。

ギャップを2つに分類する：

ブロッキングギャップ：補完しなければ分類や境界の定義を続行できないもの（例：どのような役割にサービスを提供するか、中核的な振る舞いは何か）。
非ブロッキングギャップ：完全性に影響するが、大筋には影響しないもの（例：あるエッジエラーコード、ドキュメントの形式）。

ステップ6：第二層の明確化——機能詳細（細粒度）

位置づけが明確になった後、特性の形状は既知ですが、開発チームはまだ着手できません——なぜなら「具体的にどのように動作するか」がまだわからないからです。この層では「第二層・機能詳細次元」を使用して、動作仕様を深掘りします：通常のフローはどう進むか、どのような状態があるか、異常はどう処理するか、境界シナリオはどうするか、パラメータの値はいくつか。

第二層の質問は特性のタイプによって異なります：ツアーガイド系はパスと到着ロジックを問い、認識系は誤検出と信頼度を問い、データ系はスキーマとデータ量を問う。具体的なタイプ別質問ライブラリは references/detail-probes.md を参照——まずこの特性がどのプロトタイプに属するかを判断し、対応するプローブリストを呼び出す。

ステップ7：機能要件ドキュメントの生成（製品原則セルフチェックゲートを含む）

ブロッキングギャップを補完した後、まず製品原則セルフチェックゲートを通過し、その後「出力テンプレート」に従って生成する。

テンプレートの選択： 純粋な二次開発単一レイヤーでギャップの少ない小規模特性は簡略テンプレートを使用する（「一言定義」「ソースと背景」「能力の位置づけ」「スコープと境界」「ストーリー＋MVP」「動作仕様」「インターフェース契約」「依存関係」「影響評価」「製品原則セルフチェック（一行結論）」「決定記録」「未解決・確認待ち」を含み、「クロスレイヤー実装と部門間連携」とほとんどのオンデマンドNFRをスキップする）。クロス実装レイヤーまたは重要な特性は完全テンプレートを使用する。両者は同じ必須項目とDoRを共有する。

出力前の必須手順：製品原則セルフチェックゲート。 設定セクション「D. 製品原則」（未記入の場合は references/product-principles.md の組み込みデフォルト10項目を使用）を取り出し、本特性と1項目ずつ照らし合わせて3値結論を出す：✓ 適合 / ⚠ 違反-取捨選択あり / — 該当なし。3値判定の詳細ルール、一般的なレッドフラグリスト、競合優先順位は references/product-principles.md を参照。⚠ がある項目は必ず「製品原則セルフチェック」セクションに取捨選択を記述し、「主要決定記録」セクションに1行追加する（情報源に「製品原則の競合による取捨選択」とマークし、該当する項目番号を明記する）。全てが ✓/— の軽量特性は、セルフチェックを1行結論にまとめ、空の表を展開しなくてもよい。

ゲートはスキルが自分で承認するためのものではなく、不合格項目を明確化質問または [確認待ち] に変換してユーザーに差し戻すためのものです。取捨選択に関わるもの（互換性のためにある能力を犠牲にするか、予算超過のためどれを削るか、危険な操作に権限ゲートを追加するかどうか）は、必ず「インタラクティブ明確化ルール」に従って1度に1問、選択肢付きでユーザーに差し戻し、判断を仰がなければなりません。

DoR ハード要件：

いずれかの原則が ⚠ であり、ドキュメント内に対応する取捨選択の説明＋決定記録がない場合 → DoR 不合格、「開発チーム着手可能/レビュー待ち」とマークできない。
ステップ4のレイヤー到達結論がB/Cであり、「一言定義」またはP1が依然として下位レイヤー未準備の完全な能力を約束している場合 → DoR 不合格（最初にステップ4の第5小項目に従って実際の成果物に書き戻さなければならない）。

ゲート通過後、選択したテンプレートに従ってドキュメントを生成し、標準出力ディレクトリ feature-specs/<機能名>/<機能名>.md に書き込む（会話の中だけに貼り付けない。場所の規定は「出力テンプレート」を参照）。まだ解決されていない非ブロッキングギャップは「未解決・確認待ち」セクションに入れ、本文の該当フィールドには [確認待ち] とマークし、決して作り込まない。

なぜ2層を2つのパスに分けるのか： 1回の会話で質問が多すぎると疲労を招く（明確化ルールの総量上限を参照）。第一層（ステップ5）の質問が終わったら、まず「位置づけは確定、動作は未補完」のドラフトを出力し、第二層（ステップ6）を後続の深堀パスとして、動作仕様を補完し、開発級v1.0にアップグレードするとよい。2つの層はそれぞれ総量上限を守り、互いに占用しない。要件が非常に小さくギャップが少ない場合は、2層を一気に完了することもできる。

第一層・位置づけ次元（粗粒度）

特性の「形状」を定める。断片と照らし合わせて1項目ずつ確認し、不足しているものが明確化すべき事項である。2つのグループに分かれる。

Aグループ・要件の本質（What / Why / 境界）

役割とシナリオ：誰が使うのか？どのシナリオでトリガーされるのか？（エンドユーザー / インテグレーター開発者 / 運用…）
中核的な振る舞い：この機能は具体的にどのようなアクションを実行するのか？何を入力として、何を結果として生成するのか？
スコープと境界：何を含むか、明確に何を含まないか（この項目は最も見落とされやすく、開発チームが自分でスコープを補完するのを最も防ぎやすい）。
成功の判断基準：どのような状態を「正しくできた」とするか？どのような観測可能な指標で測定するか？

Bグループ・SDKエンジニアリングの位置づけ

能力階層の帰属：L1 / L2 / L3 のどの層に該当するか？
五領域の位置づけ：どの能力領域に属するか？領域をまたぐか？またぐ場合、誰を動かすか？
インターフェースの影響範囲：新規追加/変更が必要なインターフェースは？API予算の上限に影響するか？
低レベル依存関係：どの既存能力に依存するか？まだ存在せず、先に構築する必要があるものは？
適用形態：シミュレーション、実機、または両方？両方の場合、検収基準が異なる可能性がある。
インテグレーターの可用性：どのレベルのインテグレーターが対象か？対応するラッピング/ドキュメントの複雑さが異なる。
後方互換性：既存のインターフェース契約を破壊するか？バージョン管理や移行パスが必要か？破壊的変更と判定された場合、影響を受ける既存インテグレーター/バージョン範囲と許容可能な非推奨期間も併せて明確にする必要があり、単に「破壊的変更かどうか」だけを記録してはならない。
ドキュメントと認証への影響：新しい開発者ドキュメントが必要か？インテグレーター認証の評価範囲に入るか？
セキュリティと権限（物理的な改造を含む）：この能力はどのレベルのインテグレーター/役割に開放されるか？危険または高権限のアクションを含むか？セキュリティリスクには2つのタイプがあり、両方を必ず1回は質問し、デフォルトで許可してはならない——
- 危険なソフトウェア呼び出し：速度/トルク上限の解除、緊急停止の解除、直接的なシャーシ/ジョイント制御、安全フェンスの越え——「誰が呼び出す権限を持つか、再確認/監査/権限ゲートが必要か」を問う。
- 危険な物理的改造（ハードウェアエンドエフェクター/改造系特性、プロトタイプJ）：顧客が自作ハードウェアを、動き、人を傷つける可能性のあるロボットに接続する場合——耐荷重/トルク/電力のレッドラインと超過時の結果、改造禁止領域（どのインターフェースを触ると緊急停止/安全機構が無効になるか）、エンドエフェクター改造後の負荷再較正の要否、改造の承認/資格要件、保証と責任の境界、免責とコンプライアンス声明、資料の公開範囲（役割別ゲート制御）を問う。物理的なレッドラインの数値を1つ誤ると、人身安全＋法的責任につながる。

第二層・機能詳細次元（細粒度）

特性が「具体的にどのように動作するか」を定める。これは要件を真に開発レベルに到達させるための鍵である——以下の各項目が明確に定まっていなければ、開発チームは作業開始時に自分で判断せざるを得なくなる。これらは汎用次元であり、特性タイプに応じて references/detail-probes.md からタイプ別プローブを取得して具体的に質問する。

通常フローのステップ分解：中核的な振る舞いを順序のあるステップに分解し、各ステップの入力、出力、前提条件をそれぞれ定義する。
状態とライフサイクル：どのような状態があるか？ステートマシンはどのように遷移するか？start / pause / resume / stop / cancel それぞれのセマンティクス、各状態で許可される操作。
トリガーと前提条件：どのような条件下で起動できるか？システム/リソースに対する前提条件は？繰り返しトリガー、並行トリガーはどう処理するか？
異常と失敗処理：各ステップで考えられる失敗点をリストアップし、それぞれに対策を定める——リトライ / フォールバック / 中止 / レポート、そして誰が後処理を行うか、状態をどのように終了するか。
境界とエッジシナリオ：空入力、極値、途中中断、リソース不足（バッテリー/計算能力）、外部条件の急変時の振る舞い。
パラメータ詳細：各設定可能項目の単位、値の範囲、デフォルト値、不正な値の検証方法。
タイミングと性能制約：応答時間、タイムアウト閾値、スループット、リアルタイム要件。
並行性とリエントラント性：複数インスタンスの並行動作は可能か？呼び出し元が同じインターフェースを複数回呼び出す場合はどうなるか？
可観測性：呼び出し元が特性の実行状況を認識するために必要な状態問い合わせ、イベント/コールバック、ログ、またはメトリクス。可観測性は2つの層で両方とも問う必要がある——呼び出し元向け（状態問い合わせ/イベントコールバック/位置特定可能なログ。インテグレーターが実行状態を認識するために使用）とプラットフォーム運用向け（リリース後、どのメトリクス/イベントでこの特性の健全性、採用率、失敗分布を判断するか。トラブルシューティングと意思決定のため。後者は見落とされることが多い）。

9項目すべてを質問し終える必要はない。この特性にとって重要なものを判断する（異常処理は長時間タスクではほとんどの場合重要、パラメータ詳細は純粋なクエリ系では軽い可能性がある）。重要なものを尋ね、残りは合理的にデフォルトのままにするか [確認待ち] とマークする。

3つの直交する軸を組み合わせて使用する： 上記9次元 + detail-probes の「特性プロトタイプA～J」は特性タイプで区切る1つの軸（H = エコシステム統合/リファレンス実装/ドキュメント系；I = パッケージング/配布/オフラインインストール/デプロイ系；J = ハードウェアエンドエフェクター/物理インターフェース仕様と改造資料系。外部契約は機械的/電気的物理インターフェース）。また、ある特性をクロス実装レイヤーで分解する必要があるかどうか（二次開発レイヤー以外のレイヤーを動かす場合。「ドキュメントポータルレイヤー / ビルド・配布基盤レイヤー」という2つの非実行時レイヤー、および外部依存/EOL軸を含む）は2番目の軸であり、ステップ4と references/cross-layer-routing.md を参照。どの非機能要件(NFR)と製品原則を通過させる必要があるかは3番目の軸であり、references/product-principles.md を参照。3つの軸は互いに代替せず、該当するものがあれば組み合わせて使用する。

インタラクティブ明確化ルール

これは「シンプル」を「完全」に変えるエンジンであり、必ず遵守すること：

1度に1つの質問。 1つ質問し、停止し、ユーザーの回答を待ってから、次の質問に進む。一度に複数の質問を投げかけてはならない。
ブロッキング優先。 まずブロッキングギャップ（役割、中核的な振る舞い、スコープと境界、能力の帰属）を尋ね、その後で非ブロッキングのものを尋ねる。
各質問には「なぜ尋ねるのか」と候補回答を添える。 形式：「この機能は主にどの役割にサービスを提供しますか？（これにより、どの層にカプセル化すべきかが決まります）A. エンドユーザーが直接使用 B. インテグレーターが二次開発に使用 C. 内部テスト用」。候補回答を提供することで回答のコストを大幅に削減でき、ユーザーは「上記のどれでもない」を選択して補足することもできる。
総量をコントロールし、疲労を防ぐ。 各層の1回のセッションでは、質問を7～8個以下に抑えるようにする（2層はそれぞれ独立してカウントし、互いに占用しない）。ギャップが多すぎる場合は、ブロッキングのものを補完し、残りは [確認待ち] とマークして、「残りはマークしておきますので、後で補完できます」とユーザーに伝える。第二層の詳細質問は特に超過しやすいので、この特性にとって重要なものを選んで尋ねる。
回答後は復唱して確認。 ユーザーが回答したら、自分の理解を一文で復唱してから続行し、誤解がないことを確認する。
決してユーザーに代わって決定しない。 取捨選択に関する質問（ある境界を設けるかどうか、どの形態を使うか、誰がownerか、どのレイヤーを変更するか）は必ず尋ね、デフォルトにしてはならない。「まだ確認されていないもの」は明示的に [確認待ち] とマークし、こっそりと妥当に見える値を記入してはならない。

文章表現と可読性（成果物は必ず達成すること）

要件ドキュメントは人が読み、レビューを通過するためのものであり、思いついた点をただ並べるものではない。出力前に以下の3点を確認すること：

わかりやすい言葉で、論理的に一貫していること。 文章は流暢で、段落には明確なメインテーマがあること。思いつくままに断片を並べないこと。最初に登場する用語/略語は、その場で一言説明するか、「用語解説」に収めること。読者が知らない単語でつまずかないようにする。専門用語よりも、むしろ平易な説明を1つ加える方が良い。
全体背景＋役割別セクション＋用語解説の3段構成。 1つのドキュメント＝ ① 全体背景（全員が最初に読む：これは何か、なぜか、誰のためか、何を提供するか＝「一言定義」＋「ソースと背景」＋「用語解説」）＋ ② 役割別セクション（「読み方ガイド」で後続の各セクションを読み手対象別に分割し、各役割は自分に関係する部分だけを読めばよく、あるチームが自分に関係のない詳細に埋もれないようにする）＋ ③ 「用語解説」（用語を個別に明確に説明し、理解できない人を対象とする）。
外部デリバリー形態に限定し、内部技術詳細は開放すること。 要件は**「外部に何を提供するか」を固定する**——インターフェースシグネチャ、プロダクト形態、成果物の形式、サポートするプラットフォーム/環境、検収基準。しかし、「内部でどのように実装するか」は過度に規定しない——どのライブラリを使うか、どのアーキテクチャにするか、どのパッケージング/コンパイルツールを使うかは開発チームに委ねる。書くたびに自問する：「これは外部契約か、それとも内部実装か？」。内部実装であれば、「開発チームが決定」に変更するか、「推奨（強制ではない）」に格下げし、要件を設計書にしない。
平易な言葉は理解しやすさのためであり、曖昧さのためではない——外部契約は厳密でなければならない。 文章は平易な言葉で記述するが、外部出力基準に関わるもの——インターフェース定義（シグネチャ/パラメータ/戻り値/エラー）、メッセージとデータ形式、サポートするプラットフォームのマトリックスはセルごとに完全に列挙する、成果物の形式、検収基準——は、正確で、曖昧さがなく、検収可能でなければならず、シグネチャが必要な場合はシグネチャを提供し、マトリックスが必要な場合はセルごとに完全に列挙する。平易であっても、契約は緩めてはならない。 役割別に章を分ける場合、これらの厳密な契約は「外部契約」系の章に集中させ、開発/テストチームがそれに従って実装および検証できるようにする。

出力テンプレート

ブロッキングギャップを補完し（かつステップ7の製品原則セルフチェックゲートを通過した後）、厳密にこのテンプレートに従って出力する。テンプレートにはDefinition of Readyが組み込まれており、すべてのセクションが埋められている（または明示的に [確認待ち] とマークされている）場合にのみ、この要件は「開発チームが着手可能」と見なされる。

規定：

セクションにはハード番号を付けない。セクション名で統一して参照し、セクション番号がずれるのを防ぐ。
簡略テンプレート＝「クロスレイヤー実装と部門間連携」とオンデマンドNFR次元を削除した、同一のセクションセット。純粋な二次開発単一レイヤーの小規模特性用。完全テンプレートはクロスレイヤーまたは重要な特性用。
インターフェース/パラメータ命名は全体を通して以下に従う：すべて小文字のスネークケース（snake_case）、意味が完全で正確、略語禁止（例：mic→microphone、cfg→config、num→count）、および同一ドメインの既存インターフェースと一貫性を保つ。
1つのドキュメントは1つの機能のみを扱い、1つの機能に対して1つのmdファイルのみを作成する。複数の機能はそれぞれ独立した文書として作成する（決して混在させない）。ただし、1つの機能が複数レイヤーにまたがる場合でも、複数ファイルに分割しない。クロスレイヤー/クロス部門の内容は、同一のmdファイル内で読み手対象別にセクションを分割する。
成果物の配置場所（標準出力ディレクトリ、必ず遵守）：成果物はファイルに書き込む（会話の中だけに貼り付けない）——出力ディレクトリ feature-specs/<機能名>/<機能名>.md に書き込む（カレント作業ディレクトリ/リポジトリルートからの相対パス。デフォルトルートは feature-specs/、チームは設定セクションで変更可能）。1機能1サブディレクトリ（添付画像や副産物を配置しやすい）。ファイル名＝機能名。複数の機能はそれぞれ独立したサブディレクトリ。関連機能間では相対リンクで相互参照する。
クロスレイヤー（結論B/C）特性の場合：本テンプレートの上部に**「読み方ガイド（読み手対象別）」を追加し、「クロスレイヤー実装と部門間連携」セクションで各レイヤーの内容を【読み手対象：Xグループ】ごとにセクションに分割して記載する（テンプレートは references/cross-layer-routing.md《九》を参照）——すべてこの1つのmdファイル**内に収め、別ファイルに分割しない。

# 機能要件：[機能名称]

> 状態：草案 / レビュー待ち / 確定済み　｜　提案元：[顧客/パートナー]　｜　日付：YYYY-MM-DD　｜　テンプレート：完全 / 簡略

## 読み方ガイド（読み手対象別）
> **読み方**：最初に**全体背景**を読む（「一言定義」「ソースと背景」「用語解説」、全員が読む）。残りの各セクションは以下の表に従って**各読み手が自分の担当分のみ**を読めばよく、全文を読む必要はない。クロスレイヤー/クロス部門特性の場合、この表を必ず記入する。純粋な単一レイヤーの小規模特性では表を簡略化できるが、全体背景と「用語解説」は必須。
| 読み手対象 | 重点的に読むセクション | 担当内容 |
| --- | --- | --- |
| プロダクト / レビュー担当者 | 一言定義、ソース背景、能力の位置づけ、スコープと境界、ストーリー＋検収、影響評価、製品原則セルフチェック、決定記録、未解決・確認待ち | スコープ/優先順位/取捨選択の確認 |
| 二次開発SDKチーム | インターフェース契約、動作仕様、「クロスレイヤー実装と部門間連携」・二次開発セクション | 外部ラッピングとインターフェース契約 |
| ファームウェアチーム | 「クロスレイヤー実装と部門間連携」・ファームウェアセクション、レイヤー間引き渡し契約 | 下位レイヤー能力インターフェースの確認/開放 |
| アルゴリズムチーム | 「クロスレイヤー実装と部門間連携」・アルゴリズムセクション | アルゴリズム能力の準備/適応 |
| ハードウェアチーム | 「クロスレイヤー実装と部門間連携」・ハードウェアセクション | ハードウェア形態/物理的境界 |
| テスト / QA | 検収基準、外部契約（インターフェース/メッセージ/プラットフォームマトリックス）、確認待ち | 検収基準と契約に従ってテストを設計し、全プラットフォームマトリックスをカバー |
（役割は**特性タイプに応じて選択**：実行時特性＝各実装レイヤー；デリバリー/統合/インストール系＝パッケージング・DevOps／ドキュメント／テストなど。**テスト/QAは常に1つの役割として含める**——検収をどうテストするか、どのプラットフォームをカバーするか、外部契約がテスト可能かを重視する。該当しない役割の行はそのまま削除する。**本文はできるだけ役割別に章立てし**、各役割が自分の担当部分をまとめて読めるようにする。）

## 一言定義
[What —— この特性が何をするのか、一言で明確に。⚠ ステップ4のレイヤー到達結論がB/Cの場合、ここには今回の実際のデリバリー可能な成果物のみを記述し、下位レイヤー未準備の完全な能力は記述しない]

## ソースと背景（Why）
- 元の要求：[顧客/パートナーの最初の言葉を原文の意図通りに保持]
- ビジネスシナリオ：[誰が、どのシナリオで、どのような問題を解決するのか]
- 価値：[なぜやる価値があるのか]

## 用語解説
> ドキュメント内で使用される、この分野に詳しくない読者が理解できない可能性のある用語/略語を、1語1文で平易に説明する（異なる役割を対象とし、誰もが理解していることを前提としない）。専門用語がない場合は「なし」と記述。
| 用語 | 一言説明 |
| --- | --- |
| … | … |

## 能力の位置づけ
- 階層：L1 / L2 / L3　[設定セクションAグループ未記入の場合は [確認待ち] とマーク；**デリバリー/配布/インストール/ドキュメント系の非実行時特性の場合は `N/A（能力特性ではなく、実装レイヤー軸のみ該当）` とマーク**]
- 能力領域：[五領域のいずれか、または「クロスドメイン：X + Y」、または N/A]
- クロスドメインの影響：[どの他の領域/チームを動かすか]
- クロスレイヤー結論（ステップ4）：単一レイヤー特性（二次開発SDK） / ⚠ 二次開発レイヤーで独立デリバリー不可：最下位変更レイヤーは <レイヤー>、<部門> が <能力> を先にデリバリーする必要があり、その後で二次開発レイヤーがラップできる

## スコープと境界
- 含む（In Scope）：
  - …
- 明確に含まない（Out of Scope）：   ← 必須。開発チームが誤って範囲を拡大するのを防ぐ
  - …
- 関連機能プレースホルダー（要件分割から、今回は実施しないもの）：
  - …

## クロスレイヤー実装と部門間連携
> ステップ4で本特性がクロス実装レイヤー（二次開発SDKレイヤー以外のレイヤーを動かす）と判定された場合のみ必須。純粋な二次開発単一レイヤーの場合は「単一レイヤー特性（二次開発SDK）、クロスレイヤー連携なし」と記述し、本セクションをスキップする（簡略テンプレートでは本セクションは含まれない）。
> **成果物の形態：** 1つの機能に対して1つのmdファイルのみ。本セクションは

…

[truncated for translation, remaining sections follow the same pattern]

…

（テンプレートの残りのセクション「動作仕様」「インターフェース契約草案」「依存関係と前提条件」「影響評価・互換性・リリース戦略」「製品原則セルフチェック」「主要決定記録」「未解決・確認待ち」「付録・補足」も同様に翻訳されますが、ここでは紙面の都合で省略しています。）

Auromix/feature-spec-builder

feature-spec-builder とは？

お気に入りのAIに質問する

ドキュメント