customer_direct_statement顧客本人の直接発言商談・メール等で本人が述べた内容。役割と決定権も併記する。
POSITIONING
Wikiは背景と判断理由を人間へ伝えます。Agent Interfaceは、資料から主張を抽出し、根拠を分類し、多軸評価から次回ヒアリングと提案タイプを導く順序を固定します。
概念、理由、実務上の読み方を理解する。
固定手順、列挙値、JSON Schemaで再現する。
モデルを変えても、判断差を検証できる。
MACHINE-READABLE RESOURCES
Agentにはまず /llms.txt を渡します。そこから完全仕様、JSON Schema、正解例へ到達できます。
Agentが最初に読む入口。完全仕様、スキーマ、正解例のURLを列挙します。
↗TEXTllms-full.txt判断原則、固定語彙、実行手順、診断・提案ルーティングを一度に読める正本です。
↗JSON SCHEMAschema.json案件評価、未確認情報、次回ヒアリング、推奨提案の出力形式を固定します。
↗GOLDEN JSONai-estimation.jsonAI仮説先行案件の期待出力。モデル変更時の回帰判定に使います。
↗https://proposal-playbook.color4pen.chatgpt.site/llms.txtEXECUTION PROTOCOL
extract_claims主張を原文単位で抽出する事実、原因、解決案、予算、期限を一文にまとめず、検証可能な最小単位へ分ける。
label_evidence情報源・主張・確認状態を付ける具体的な記述でも、出所と確認状態を根拠なく昇格させない。
assess_areas判断領域を独立評価する価値、業務、解決、実現性、実行条件、意思決定、顧客準備を平均せず評価する。
identify_blockers提案を止める未判断を特定する不足情報を列挙するだけでなく、どの約束を止めているか示す。
route_diagnostics必要な診断だけを選ぶ業務原因が曖昧ならボトルネック、AI案がある場合だけAI・データ実現性を選ぶ。
design_hearing次回ヒアリングを設計する目的、優先質問、扱わない・決めないこと、参加者、資料、終了条件を導く。
select_proposal提案タイプを一つ選ぶ現時点で約束可能な成果を選び、まだ約束できない範囲と次段階条件を明記する。
self_check禁止規則で自己検証する入力にない事実を補っていないか、解決仮説に引っ張られていないかを最終確認する。
FIXED VOCABULARY
表示名は日本語のまま保ち、Agent出力では英語IDを使います。ページ追加時も、この語彙をプレイブックのスキーマとして維持します。
customer_direct_statement顧客本人の直接発言商談・メール等で本人が述べた内容。役割と決定権も併記する。
operator_direct_statement現場担当者の直接発言実務の事実や例外に近いが、組織決定とは限らない。
intermediary_summary仲介者による要約紹介会社や別部署が編集した情報。原文・話者・文脈を再確認する。
document文書・既存資料報告書、仕様書、規程、議事録。作成者と更新日を残す。
actual_data実データ件数、時間、ログ、見積、BOM、原価など。抽出条件も残す。
work_observation業務観察現場同席や操作観察で確認した内容。観察範囲と例外性に注意する。
proposal_team提案側受託側の分析・解釈・推測。顧客情報と混ぜず、仮説として扱う。
business_fact業務事実誰が、何を、どの頻度・時間・条件で行っているか。
problem_perception課題認識何を問題と感じ、誰にどの影響があると捉えているか。
cause_hypothesis解釈・原因仮説なぜ起きているかについての説明。事実とは分ける。
solution_hypothesis解決仮説AI化、連携、自動化など、問題を解くための案。
request要望欲しい機能・状態。背景や優先度が未確認でも存在する。
formal_requirement正式要件決定権者が対象・優先度・制約を含めて合意した条件。
constraint制約法令、期限、予算、既存契約、技術、運用上の動かせない条件。
unverified未確認出所は分かるが、内容・背景・根拠をまだ確かめていない。
speaker_confirmed本人確認済み話者本人へ意味と文脈を確認した。
evidence_confirmed根拠確認済み資料、実データ、観察など裏付けを確認した。
multi_stakeholder_confirmed複数関係者確認済み異なる役割の関係者間で認識の一致・差分を確認した。
customer_agreed顧客合意済み提案や意思決定に使う条件として、顧客側で合意された。
value価値なぜ取り組むのか
business業務誰のどの業務を変えるのか
solution解決何をどこまで実現するのか
feasibility実現性技術・データ・運用上成立するか
execution_conditions実行条件予算・期限・体制が成立するか
decision_making意思決定誰が何を基準に決めるのか
client_readiness顧客準備関係者ごとに、業務とシステムをどの粒度で判断できるか
discovery調査・構想整理価値や対象業務をまだ説明できない。成果:現状理解、論点整理、次の意思決定材料
bottleneck_diagnosis業務ボトルネック診断課題や長いリードタイムは見えるが、時間の内訳と原因を確認できていない。成果:実作業・待ち・判断・手戻りの構造、改善対象
ai_data_diagnosisAI・データ実現性診断AI案はあるが、タスク・データ・評価・運用条件が未確認。成果:AI適用仮説、データ棚卸し、評価設計、PoC可否
requirements_definition業務整理・要件定義価値は見えるが、業務・利用者・対象範囲が固まっていない。成果:業務フロー、要求、優先順位、対象範囲
pocPoC・技術検証価値仮説があり、検証データ・評価方法・合否基準を説明できる。成果:成立条件、精度、連携可否、残存リスク
prototypeプロトタイプ画面・操作を見ないと利用者が要求を判断できない。成果:利用イメージ、操作仮説、要求の具体化
mvpMVP開発価値仮説、利用者、ユースケース、検証方法を説明できる。成果:価値検証に必要な最小範囲と評価方法
full_development本開発対象範囲、実現性、実行条件、意思決定条件が確認されている。成果:確定範囲、計画、責任分界、見積り
hold_or_decline提案保留・見送り重大な前提が未確認、または予算・期限・期待値が成立しない。成果:不足条件、再開条件、見送る理由
長い、遅い、属人化している等の課題はあるが、時間の内訳と原因が未確認
実作業 / 探索 / 判断 / 転記 / 他部署待ち / 承認待ち / 手戻り / 例外AIが解決仮説に含まれ、タスク・データ・評価・運用条件のいずれかが未確認
対象タスク / 入力データ / 正解・評価方法 / 人の確認と運用 / 機密・責任・フォールバックOUTPUT CONTRACT
analysisGOLDEN CASE
正解例は文章の完全一致を求めるものではありません。判断上の不変条件が守られているかを確認します。
AI前提へ引っ張られないAI部品判断を未確認の解決仮説として維持する。
本開発へ飛ばない原因・データ・評価・組織合意が未確認なら診断を選ぶ。
待ち時間を落とさない1週間を実作業だけでなく待ち・承認・手戻りへ分解する。
予算感を昇格させない承認者と上限が不明なら承認済み予算として扱わない。