1. ボトルネックは「書く」から「決める」へ

『ホットペッパーグルメ』開発グループでマネージャーをしている永井です。グループ内のいくつかの案件で仕様駆動開発（SDD）の試行を進めており、そのなかで、企画から仕様策定までを加速させる新しい役割 — Spec Refiner — を立てています。AI で実装は速くなりました。けれど、完了までの時間は同じ速度では縮みません。GitClear が DORA 2025 を踏まえて示した代表的なバリューストリーム例では、リードタイム 117 時間のうち能動的な作業は 24.5 時間で、残る 92.5 時間は待機（レビュー待ち・承認待ち等）で占められます（フロー効率 ~21%）¹。律速はコードを書く工程の外側、仕様を決める工程に移っています。

要件定義後・設計後の手戻りは、AI 以前から起こりがちでした。要件を一通り固めたつもりでも、設計で既存処理と突き合わせると仕様把握の漏れが見つかります。実装の細部を詰める段で予期せぬ影響範囲が判明し、レビューで前提がひっくり返り、QA でエッジケースの仕様未定義に気づく。どの段でつまずいても、共通するのは仕様の曖昧さです。

仕様の読み手が AI になってから、その曖昧さの扱われ方が質的に変わりました。仕様はもう人間どうしの伝達文書ではありません。AI エージェントが読み込んで実装を起動するコンテキストです。曖昧な仕様は、伝達ミスにとどまらず、誤実装のトリガーとして働きます。エージェントは表層の不整合は聞き返してくれますが、暗黙の前提や既存システムとの細部の整合性は素通りされ、もっともらしい実装として返ってきます。1 つ目のエージェントが要件を取り違えれば、下流のエージェントは取り違えた前提を正しい前提として受け取り、論理的に一貫した誤実装が組み上がります。

複数システムを跨ぐ改修案件で、既存資産が重い現場では、この問題は案件ごとの仕様作成だけでは解けません。仕様を磨くたびに同じ統合作業が繰り返される構造を、AI が読むコンテキスト — Living Docs / Constitution / Steering / Templates / 例示パターン — の蓄積で逓減させていく必要があります。Spec Refiner は、AI を活用するチーム内のドメインエキスパートとして、案件ごとの仕様精錬と、AI コンテキストの編集とを両輪で担う役割です。次節からは、この役割の価値を、既存職能との比較から描いていきます。

2. Refiner は何を引き受けるか

Refiner が立つ場所を、既存職能と並べて整理します。

例えば PdM が要件レビューに入ります。エンジニアから「在庫戻しのトランザクション境界が壊れる」、デザイナーから「キャンセル後の動線が不確定」、QA から「同時予約の競合シナリオが書けない」が同時に上がる。会議後、PdM は仕様文書に戻って論点を整理し、関係者へ確認に行きます。これを 1 案件あたり 3〜5 周。この工程を専業で引き受ける職能は、既存マップのどこにあるでしょうか。

近接職能を、新規 SDD / 既存資産 SDD の 2 軸で並べてみます。

この比較表で焦点になるのは、Kiro / Spec Kit が想定する起草モデル — 表中の「機能担当の開発者」の行です。AWS Kiro や GitHub Spec Kit が想定する仕様起草モデルは、機能担当の開発者が自然言語の初期入力から仕様の初稿を書く行為に最適化されています。Spec Kit の /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement という直線パイプラインに象徴されるように、機能の担当者が仕様起草から実装まで一気通貫で進めることがツール設計上の暗黙の前提です⁵。Kiro が利用者を "builder"、Spec Kit が "developer" と呼ぶように、独立した仕様起草者を切り出す発想自体がツール側にはありません。Augment Code は両者を対比して、ウォーターフォール型の "dedicated spec author"（BA / PM などの専任職）と、SDD ツールが前提とする "developer writing their own spec"（統合された役割）を区別しています⁶。Kiro / Spec Kit が想定するのは後者です。

既存資産が重く、1 機能の改修が複数システムに波及する現場では、この前提が崩れます。1 機能の仕様が複数システムの整合性に依存する場合、既存コードを読み解いて整合性を確認する工程だけで数日かかります。実装も抱える機能担当者にとっては、片手間で初稿を起こせる規模を超えます。仕様作成の主体は「書く」から「読んで突き合わせる」ほうへ移り、初稿執筆を起点に据えたツール設計はこの構成を想定していません。Refiner はこの読みと突き合わせを専業で担い、AI と過去案件で蓄積したコンテキストを足場に複数案を組み立てます。

認知負荷の観点でも、同じ結論に行き着きます。John Sweller の枠組みでは、人の負荷は本質的・外部的・学習的の 3 種に分かれます。AI でコード量が増えていく現場では、レビュー待ち、重複コードの解読、整合性確認といった外部的負荷がチームに溜まります。「既存職能に AI スキルを上乗せ」では、その総量がさらに増えるだけです。Refiner の機能は、開発者が本質的負荷（ビジネスロジック構築）に集中できるよう、外部的負荷を組織的に引き受けること。さらに案件をまたいで AI コンテキストを蓄積することで、同じ統合作業が繰り返される構造そのものを逓減させていきます。

Refiner と隣接する潮流も整理しておきます。SDD ツール側では、Augment Code が複数リポジトリの依存解析、Tessl が仕様を唯一のソースとする運用、GitHub Spec Kit がブランチ単位の使い捨て仕様を、それぞれ追求しています。いずれも「AI が読むコンテキストをどう設計・維持するか」という問いに、ツール側から答えようとしているものです。Refiner は、これらの潮流の隣に立つ職能です。

3. Refiner は AI を活用するドメインエキスパート

3.1 仕様 = AI コンテキストへの変質

仕様の読み手が AI になったことで、仕様品質の決定要因も変わります。

伝統的に、仕様の品質は書き手の整理能力と読み手の解釈能力の組み合わせで決まりました。AI が読み手になると、人間の解釈能力の余白が消えます。AI に渡されるコンテキスト — 個別案件の仕様、Constitution、Steering、Templates、例示パターンを束ねたもの — の質が、AI の出力品質を決めるようになります。

学術・実務でも名前が付き始めています。Tessl は仕様を executable contract（実行可能な契約）と呼び、AI が消費する前提の契約として位置づけます。decision artifact（意思決定の人工物）という呼称も、判断の結晶という側面を捉えています。本記事ではこれらを総合して、仕様を AI が読むコンテキストと扱います。

Refiner の中核責務は、この束ねられたコンテキスト全体の質を担保することです。

3.2 AI を鵜呑みにせず、仕様の質を担保する

Refiner の第一の責務は、AI が生成した仕様書をそのまま受け入れないことです。自ら仕様を読み、既存コードを読み、関係者に確認に行く。その上で、AI の出力を正しい仕様に修正します。

放置したときに何が起きるかは、エージェントを直列に繋いだときの挙動に表れます。要件抽出 → API 契約生成 → 実装 → テスト生成、と 4 段に並べると、各段の成功確率を独立に 95% と仮定する素朴な概算でも、全体の信頼度は 0.95⁴ ≈ 81% に落ちます。独立性の仮定は粗いので、この数字は上限のオーダー感としてだけ受け取ってください。本当の問題は乗算ではなく、1 つ目のエージェントが微妙な誤認をしたときに起こります。例えば最初のエージェントが、キャンセル期限を「予約日の前日 23:59 まで」と読み取ったとします。実際の仕様は「来店時刻の 24 時間前まで」でした。下流のエージェントは、誤った期限を正しい前提として、キャンセル料計算・通知タイミング・在庫戻しの実装を組み上げます。それぞれは内部で論理的に整合しているので、レビューでも違和感なく通り抜けます。最終成果物は美しく整えられ、レビューを素通りして本番に届きます。

実測値も揃ってきています。LLM が生成したコードサンプルの 45% が OWASP Top 10 該当の脆弱性を含み²、コミット速度が 3〜4 倍に上がった現場で月間セキュリティ問題が 10 倍に増えた³。さらに AI 補助下では、コード複雑度に対して概念理解が追いつかない乖離（Explainability Gap）が観察されています⁴。

Refiner は、AI が読み込んだ対象を検証し、判断の足場になる箇所は既存コードを自分の目で確かめ、関係者と一往復対話したうえで、AI の出力を実態に合わせて修正します。コードを全部読む役ではなく、AI に広く読ませた上で判断を支える箇所を選んで確かめる役です。仕様の質を最終的に担保するのは人間で、その人間の役割を専業で引き受けるのが Refiner です。

3.3 案件を跨いで AI コンテキストを編集する

もう一つの責務は、案件ごとの精錬で得た知見を、AI が次の案件で読むコンテキストへ書き戻すことです。Living Docs、Constitution、Steering、Templates、例示パターン — これらの AI コンテキストを案件をまたいで編集していきます。

この編集作業には、もう一段の効用が乗ります。「実装着手前に仕様を決め切る」発想は、本来トヨタ自動車が発祥といわれるリーン製品開発で確立された Set-Based Concurrent Engineering と衝突します。SBCE は「複数の選択肢を並行して維持し、情報が揃うまで決定を遅らせよ」と説くからです。

衝突を解くのは、AI による検証コストの低下です。AI で複数の仕様案・実装計画を並列に生成し、不整合を実装前に炙り出せるようになりました。決定自体は早まりますが、早め方の質が変わります。思いついた一案で早く確定させるのではなく、選択肢を広げたまま帰結を比べてから絞り込む — 「探索空間のシフトレフト」と呼べる手筋です。GitHub Spec Kit の /speckit.plan /speckit.tasks の並行実行、Tessl の Registry を用いた複数 Spec の同時検証が、その実装モデルにあたります。

この並列生成の足場になるのが、案件をまたいで編集してきた AI コンテキストです。案件を重ねるほどコンテキストが厚くなり、同じ統合作業を繰り返す総量が減っていきます。PdM・デザイナー・エンジニア・QA がそれぞれの専門軸を持つのと同じく、AI で既存コードと業務制約を判断材料に変換する専門軸を Refiner が担う、という分業です。

4. Refiner が担うこと、担わないこと

4.1 定義

Spec Refiner（仕様精錬者）: 複数システムを跨ぐ既存資産の重い SDD において、AI を活用して仕様の質を担保するチーム内ドメインエキスパート。案件ごとに、既存コードと業務制約を AI で読み解いて関係者と擦り合わせ、PdM・デザイナー・エンジニア・QA の判断材料を組み立てる。同時に、案件で得た知見をもとに Constitution / Steering / Templates / 例示パターンを編集し、次の案件で AI が読むコンテキストを最新の前提に保つ。最終判断は各専門職が下し、Refiner は判断の精度と流速を上げる側に立つ。

4.2 任用要件（MUST / WANT / NG）

MUST は職能として外せない最低線、WANT は精度が一段上がる加点要素、NG は適性として向かない傾向です。

MUST（必須要件）

1. AI とコードを読み解く力と、メタ認知を較正する力
   • Claude Code / Cursor で既存コードを読み解き、業務ロジックと実装の対応関係を追える
   • スタックトレース・SQL・API スキーマ・設定ファイルを横断して読める
   • AI の出力を盲信せず、自分の理解と AI の確率的出力の整合を常にチェックできる
2. 曖昧さを発見して業務側に問い直す対話力
   • 「これは既存処理と矛盾しないか」を見つけたら忖度せず問い直せる
   • 業務側の用語と技術側の用語を翻訳できる
3. 判断材料を 4 領域（PdM / デザイナー / エンジニア / QA）分の形式で組み立てる力
   • 仕様 Markdown、UI ワイヤー素案、QA 観点リスト、Constitution / Steering ファイル素案を使い分けて出せる
   • スコープ・前提・除外の境界を明示できる
4. AI コンテキストの設計・維持力
   • Constitution / Steering / Templates / バリデーションゲートを整備し、AI エージェントの自律駆動を制御する
   • 今日の案件で得た知見を、明日チームが使える AI コンテキストに昇華する習慣を持つ
5. ドメイン知識を取りに行く意欲
   • 担当領域のビジネスルール、ユーザー導線、KPI を自分から学べる

WANT（加点要素）

1. 設計論への素養（DDD / Clean Architecture / Hexagonal）— 技術論点の抽出が深くなる
2. 実装経験 — AI コンテキストの設計到達点が高くなる
3. コンテキストウィンドウ運用の勘所 — どの情報をどの順で載せるか設計できる
4. ファシリテーション力 — 業務側の認識合わせを短時間で構造化できる
5. 運用・障害対応への理解 — 異常系の仕様まで設計できる

NG（向かない傾向）

1. 実装を優先しがち — 精錬・コンテキスト編集の両輪が後回しになると Refiner の価値が出ません
2. 関係者の言葉をそのまま仕様にする — 不純物が残ったまま下流に流れます
3. AI の出力を検証せず採用する — 仕様の質を担保する責任が形骸化します
4. 案件の中だけで完結させがち — AI コンテキストへ書き戻さないと、同じ統合作業を案件ごとに繰り返すループから抜けられません

4.3 ある日のワークフロー

1 日の動きを時系列で描きます。業務側から Slack に 1 行依頼が来た想定で、案件規模により実際は数日に分散しますが、ここでは理想化したスケッチとして 1 日に圧縮しています。Refiner は 4 専門職にまたがり、それぞれの判断材料を組み立てます。

最後の 16:30 が、両輪のもう一方を回す工程です。今日の案件で得た知見を Constitution / Steering / Templates に書き戻し、次の案件で同じ統合作業を繰り返さなくて済む状態へ近づけます。

5. なぜ Refiner と呼ぶか

Author は新規執筆を職務の中心に置く語です。既存資産を読み解き、矛盾を発見し、判断材料を組み立て直す工程は、Author の職務記述から取りこぼされます。仕様作成の核心は既存システムの境界の再決定にあり、Author だと発見・対話・精錬の工程が抜けます。

Refine の語源は、ラテン語の re- + finis（境界、限界）です。Define（de- + finis = 境界を定める）と語源を共有します。Refiner は語源的に「再決定する人」 — 曖昧な要件を受け取り、コードベースという現実と照合しながら、仕様の境界を再び精密に定め直す職能を指します。

当初は「ナビ・エンジニア」（実装側を「ドライブ・エンジニア」）と呼んでいました。ペアプロ用語で仕様精錬と実装の役割分担を対比させる案です。ただ「エンジニア」を職能名に組み込むと、企画職などエンジニア以外からの経路を塞いでしまいます。実装スキルを必須要件にしないという意思決定の結果、Refiner に切り替えました。

結果として、Refiner は Engineer と並べたときの対称性も担保しています。「リファイナーとエンジニアで進めます」というフレーズで自然に並び、どちらも精密さの文脈にいる専門職です。ナビゲーター / ドライバーといったペアプロ用語との衝突もありません。

候補から却下したものを表で並べておきます。

新職能の歴史を眺めると、命名の良さよりも機能設計の方向性が定着の幅を決めてきました。

広がりを得た職能はいずれも、案件代行に閉じず、組織の仕組みに転換することで定着しました。Refiner も両輪のうちコンテキスト編集まで担うことで、その系譜に並びます。

6. Refiner への経路

Refiner に至る経路はひとつではありません。

企画職やエンジニアが、自分の専門性を保ったまま、AI で Requirements Engineering スキルを獲得する。

企画職が Refiner 機能を担える根拠は、コードを書く力が不要だからではありません。自分の専門性を保ったまま、AI で RE スキルを後付けで積めるからです。

• 企画職 → Refiner: 業務知識と顧客理解に、AI 駆動の仕様精錬を加算する
• エンジニア → Refiner: 実装ではなく、仕様精錬とコンテキスト編集に専門軸を切り替える

専門性なしでも担えるという話ではありません。専門性に AI を掛け合わせて RE 能力を後付けする経路を提案しています。

経路を機能させる前提条件は、AI 出力と自分の理解を厳密に突き合わせるメタ認知の較正です。AI でコードを読み解く体験は、ユーザーに「自分の能力が上がった」感覚を残します⁴。補助下で「理解している」と感じる感覚と補助なしでの実際の理解度は別物として扱う必要があり、これを欠けば、感覚と理解度のギャップに気づけないまま判断を進めることになります。

シニアの企画職やプロダクトマネージャーはすでに仕様の意思決定責任を持っているので、Refiner を兼ねるケースは「経路」というより、AI コンテキスト編集というツールキットの獲得に近い位置づけです。

組織設計上は、1 人集約のアンチパターンに注意が要ります。Refiner を 1 人に固定すると、その人物が新たなボトルネックに化けます。Refiner を PdM・デザイナー・エンジニア・QA の隣に並ぶ専門軸として、チームの中に複数人で埋め込む設計が安全です。

7. 動詞は浸透、名詞は空白

動詞としての refine は SDD コミュニティで標準語彙です。Closed-Loop Development の文脈でも、UAT 結果を受けて仕様を磨き直す工程を spec refinement と呼びます。一方、役職名としての Spec Refiner は、2026 年現在、まだ見当たりません。

本記事では、その空白に仮の名前として Spec Refiner を置いてみました。

脚注

1. Google DORA 2025 Research（GitClear 集計 + AI 開発者生産性の縦断的研究）: https://www.gitclear.com/recent_ai_developer_productivity_code_quality_research
2. Veracode "GenAI Code Security Report"（2025 年 8 月、CSA Research Note 経由）: https://www.veracode.com/blog/genai-code-security-report/
3. Apiiro "4x Velocity, 10x Vulnerabilities"（2025 年 9 月）: https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/
4. "The Vibe-Check Protocol: Quantifying Cognitive Offloading in AI Programming"（arxiv 2601.02410, 2026 年 1 月）: https://arxiv.org/abs/2601.02410
5. GitHub Spec Kit: https://github.com/github/spec-kit
6. Augment Code "Spec-Driven Development vs Waterfall": https://www.augmentcode.com/guides/spec-driven-development-vs-waterfall