# Proposal Playbook Agent Interface Interface version: 1.0.0 Playbook version: 0.9 Canonical repository: github:color4pen/proposal-playbook/playbook.md Human guide: https://proposal-playbook.color4pen.com/agent-interface ## Purpose 入力された案件資料を、書かれている解決案へ直行せず、提案判断に必要な根拠・未判断・次回ヒアリング・現時点で約束可能な提案へ変換する。 ## Core principles 1. 案件全体を単一レベルや平均点で表さない。 2. 領域の状態と、情報の確認状態を分ける。 3. 具体的な解決案ほど、情報源・根拠・合意者へ戻す。 4. 顧客準備度は組織全体ではなく関係者ごとに見る。 5. 提案タイプは、進んでいる情報ではなく中核の未判断から導く。 ## Required execution procedure 1. 主張を原文単位で抽出する 事実、原因、解決案、予算、期限を一文にまとめず、検証可能な最小単位へ分ける。 2. 情報源・主張・確認状態を付ける 具体的な記述でも、出所と確認状態を根拠なく昇格させない。 3. 判断領域を独立評価する 価値、業務、解決、実現性、実行条件、意思決定、顧客準備を平均せず評価する。 4. 提案を止める未判断を特定する 不足情報を列挙するだけでなく、どの約束を止めているか示す。 5. 必要な診断だけを選ぶ 業務原因が曖昧ならボトルネック、AI案がある場合だけAI・データ実現性を選ぶ。 6. 次回ヒアリングを設計する 目的、優先質問、扱わない・決めないこと、参加者、資料、終了条件を導く。 7. 提案タイプを一つ選ぶ 現時点で約束可能な成果を選び、まだ約束できない範囲と次段階条件を明記する。 8. 禁止規則で自己検証する 入力にない事実を補っていないか、解決仮説に引っ張られていないかを最終確認する。 ## Guardrails - 仲介者の記述を、顧客確認済み事実へ昇格させない。 - 案件全体へ単一の成熟度や平均点を付けない。 - 具体的な解決仮説を、正式要件として扱わない。 - 予算感や希望時期を、承認済み予算・確定期限として扱わない。 - 不明点を一般論や推測で補わず、未確認情報として残す。 - AI案件では、出力可能性より正解を評価可能かを先に確認する。 - 本開発条件が未成立なら、機能・費用・精度を確約しない。 - 質問数を増やすことを目的にせず、次の意思決定に必要な質問を優先する。 ## Evidence source taxonomy - `customer_direct_statement` — 顧客本人の直接発言: 商談・メール等で本人が述べた内容。役割と決定権も併記する。 - `operator_direct_statement` — 現場担当者の直接発言: 実務の事実や例外に近いが、組織決定とは限らない。 - `intermediary_summary` — 仲介者による要約: 紹介会社や別部署が編集した情報。原文・話者・文脈を再確認する。 - `document` — 文書・既存資料: 報告書、仕様書、規程、議事録。作成者と更新日を残す。 - `actual_data` — 実データ: 件数、時間、ログ、見積、BOM、原価など。抽出条件も残す。 - `work_observation` — 業務観察: 現場同席や操作観察で確認した内容。観察範囲と例外性に注意する。 - `proposal_team` — 提案側: 受託側の分析・解釈・推測。顧客情報と混ぜず、仮説として扱う。 ## Claim type taxonomy - `business_fact` — 業務事実: 誰が、何を、どの頻度・時間・条件で行っているか。 - `problem_perception` — 課題認識: 何を問題と感じ、誰にどの影響があると捉えているか。 - `cause_hypothesis` — 解釈・原因仮説: なぜ起きているかについての説明。事実とは分ける。 - `solution_hypothesis` — 解決仮説: AI化、連携、自動化など、問題を解くための案。 - `request` — 要望: 欲しい機能・状態。背景や優先度が未確認でも存在する。 - `formal_requirement` — 正式要件: 決定権者が対象・優先度・制約を含めて合意した条件。 - `constraint` — 制約: 法令、期限、予算、既存契約、技術、運用上の動かせない条件。 ## Verification state taxonomy - `unverified` — 未確認: 出所は分かるが、内容・背景・根拠をまだ確かめていない。 - `speaker_confirmed` — 本人確認済み: 話者本人へ意味と文脈を確認した。 - `evidence_confirmed` — 根拠確認済み: 資料、実データ、観察など裏付けを確認した。 - `multi_stakeholder_confirmed` — 複数関係者確認済み: 異なる役割の関係者間で認識の一致・差分を確認した。 - `customer_agreed` — 顧客合意済み: 提案や意思決定に使う条件として、顧客側で合意された。 ## Assessment areas - `value` — 価値: なぜ取り組むのか Area-specific states: 困りごとが出ている / 影響が分かっている / 原因仮説がある / 実態を確認している / 優先度が決まっている - `business` — 業務: 誰のどの業務を変えるのか Area-specific states: 対象者候補がいる / 通常業務が分かる / 例外と頻度が分かる / 現場で確認している / 変更後の役割が決まっている - `solution` — 解決: 何をどこまで実現するのか Area-specific states: 要望が出ている / 利用場面が分かる / ユースケースが整理されている / 優先順位がある / 対象・対象外が決まっている - `feasibility` — 実現性: 技術・データ・運用上成立するか Area-specific states: 未調査 / 懸念が判明している / 検証事項が決まっている / 調査・PoC中 / 成立条件を確認している - `execution_conditions` — 実行条件: 予算・期限・体制が成立するか Area-specific states: 条件未確認 / 希望が出ている / 理由と制約が分かる / 調整可能範囲が分かる / 実行条件が確保されている - `decision_making` — 意思決定: 誰が何を基準に決めるのか Area-specific states: 窓口がいる / 関係者が分かる / 決裁者が分かる / 判断基準と過程が分かる / 判断できる場が整っている - `client_readiness` — 顧客準備: 関係者ごとに、業務とシステムをどの粒度で判断できるか Area-specific states: 業務相談中心 / 利用イメージあり / 業務接続可能 / トレードオフ判断可能 / 共創可能 Do not calculate a cross-area maturity score. For every area, output its current status, basis claim IDs, missing information, and what those unknowns block. ## Diagnostic routing - `bottleneck` — 業務ボトルネック診断 Trigger: 長い、遅い、属人化している等の課題はあるが、時間の内訳と原因が未確認 Dimensions: 実作業 / 探索 / 判断 / 転記 / 他部署待ち / 承認待ち / 手戻り / 例外 - `ai_data` — AI・データ実現性 Trigger: AIが解決仮説に含まれ、タスク・データ・評価・運用条件のいずれかが未確認 Dimensions: 対象タスク / 入力データ / 正解・評価方法 / 人の確認と運用 / 機密・責任・フォールバック AI・データ実現性は、AIが解決仮説に含まれる場合だけ選ぶ。中心の問いは「AIが出力できるか」ではなく「出力の良し悪しを後から評価できるか」である。 ## Conditional knowledge loading Always apply this specification first. Then load only the modules needed for the case from knowledge/. - `knowledge/principles.md` — 基本原則と、単一成熟度へ戻さないための判断規則。 - `knowledge/decision-map.md` — 判断領域ごとの状態と、提案を止める未判断の見方。 - `knowledge/evidence.md` — 情報源、主張の種類、確認状態を分離する根拠管理。 - `knowledge/client-readiness.md` — 顧客の業務・システム理解度に応じた説明と合意形成。 - `knowledge/stakeholders.md` — 役職・責任・懸念に応じたラポール形成と優先事項。 - `knowledge/conditions.md` — 案件条件からヒアリング方針を選ぶ条件分岐。 - `knowledge/diagnostics/bottleneck.md` — 長い・遅いを作業、待ち、判断、手戻りへ分解する診断。 - `knowledge/diagnostics/ai-data.md` — AI案件のデータ、評価、運用、責任条件を確認する診断。 - `knowledge/meeting-design.md` — 商談目的、質問、参加者、資料、終了条件を設計する方法。 - `knowledge/proposal.md` — 未判断から診断・PoC・MVP・本開発を選ぶ基準。 - `knowledge/templates.md` — 案件評価、根拠メモ、商談設計ブリーフのテンプレート。 - `knowledge/cases/ai-estimation.md` — AI見積仮説先行案件の人間向けケーススタディ。 Do not load all modules by default. Fixed IDs and the output schema take precedence over prose modules when they conflict. ## Meeting brief 次回ヒアリングは次の12項目で設計する。 1. 商談目的 2. 領域ごとの現在地 3. 検証する仮説 4. 優先質問 5. 扱わない・決めないこと 6. 必要な参加者 7. 依頼資料 8. 終了条件 9. 顧客側の宿題 10. 提案側の宿題 11. 次段階へ進む条件 12. 推奨する提案タイプ ## Proposal routing - `discovery` — 調査・構想整理: 価値や対象業務をまだ説明できない。成果：現状理解、論点整理、次の意思決定材料 - `bottleneck_diagnosis` — 業務ボトルネック診断: 課題や長いリードタイムは見えるが、時間の内訳と原因を確認できていない。成果：実作業・待ち・判断・手戻りの構造、改善対象 - `ai_data_diagnosis` — AI・データ実現性診断: AI案はあるが、タスク・データ・評価・運用条件が未確認。成果：AI適用仮説、データ棚卸し、評価設計、PoC可否 - `requirements_definition` — 業務整理・要件定義: 価値は見えるが、業務・利用者・対象範囲が固まっていない。成果：業務フロー、要求、優先順位、対象範囲 - `poc` — PoC・技術検証: 価値仮説があり、検証データ・評価方法・合否基準を説明できる。成果：成立条件、精度、連携可否、残存リスク - `prototype` — プロトタイプ: 画面・操作を見ないと利用者が要求を判断できない。成果：利用イメージ、操作仮説、要求の具体化 - `mvp` — MVP開発: 価値仮説、利用者、ユースケース、検証方法を説明できる。成果：価値検証に必要な最小範囲と評価方法 - `full_development` — 本開発: 対象範囲、実現性、実行条件、意思決定条件が確認されている。成果：確定範囲、計画、責任分界、見積り - `hold_or_decline` — 提案保留・見送り: 重大な前提が未確認、または予算・期限・期待値が成立しない。成果：不足条件、再開条件、見送る理由 主提案タイプは一つ選ぶ。併設する診断がある場合は reason に明記する。まだ約束できない範囲と次段階へ進む条件を必ず出力する。 ## Output contract JSONのみを要求された場合は、正本リポジトリの schema.json に厳密に従う。入力にない値を作らず、未確認情報は missing_information へ残す。正解例は examples/ai-estimation.json を参照する。サイト上のミラーは https://proposal-playbook.color4pen.com/agent/schema.json と https://proposal-playbook.color4pen.com/agent/examples/ai-estimation.json で確認できる。