システム受託プレイブック
⌘ K

Agent Interface v1

プレイブックを、Agentが同じ順序・同じ語彙・同じ出力形式で実行するための機械向け契約です。

POSITIONING

ナレッジを、実行可能な判断プロトコルへ変える

Wikiは背景と判断理由を人間へ伝えます。Agent Interfaceは、資料から主張を抽出し、根拠を分類し、多軸評価から次回ヒアリングと提案タイプを導く順序を固定します。

Human layerWiki

概念、理由、実務上の読み方を理解する。

Machine layerProtocol

固定手順、列挙値、JSON Schemaで再現する。

Outcome再現可能な案件分析

モデルを変えても、判断差を検証できる。

VersionAgent Interface 1.0.0。人間向けページと機械向けリソースは、同じ定義を参照します。

MACHINE-READABLE RESOURCES

URLだけで、読む順序と出力形式を解決する

Agentにはまず /llms.txt を渡します。そこから完全仕様、JSON Schema、正解例へ到達できます。

START URLhttps://proposal-playbook.color4pen.chatgpt.site/llms.txt

EXECUTION PROTOCOL

分析手順を8段階に固定する

  1. 01
    extract_claims主張を原文単位で抽出する

    事実、原因、解決案、予算、期限を一文にまとめず、検証可能な最小単位へ分ける。

  2. 02
    label_evidence情報源・主張・確認状態を付ける

    具体的な記述でも、出所と確認状態を根拠なく昇格させない。

  3. 03
    assess_areas判断領域を独立評価する

    価値、業務、解決、実現性、実行条件、意思決定、顧客準備を平均せず評価する。

  4. 04
    identify_blockers提案を止める未判断を特定する

    不足情報を列挙するだけでなく、どの約束を止めているか示す。

  5. 05
    route_diagnostics必要な診断だけを選ぶ

    業務原因が曖昧ならボトルネック、AI案がある場合だけAI・データ実現性を選ぶ。

  6. 06
    design_hearing次回ヒアリングを設計する

    目的、優先質問、扱わない・決めないこと、参加者、資料、終了条件を導く。

  7. 07
    select_proposal提案タイプを一つ選ぶ

    現時点で約束可能な成果を選び、まだ約束できない範囲と次段階条件を明記する。

  8. 08
    self_check禁止規則で自己検証する

    入力にない事実を補っていないか、解決仮説に引っ張られていないかを最終確認する。

INVARIANTS分析中に破ってはいけない規則
  • 仲介者の記述を、顧客確認済み事実へ昇格させない。
  • 案件全体へ単一の成熟度や平均点を付けない。
  • 具体的な解決仮説を、正式要件として扱わない。
  • 予算感や希望時期を、承認済み予算・確定期限として扱わない。
  • 不明点を一般論や推測で補わず、未確認情報として残す。
  • AI案件では、出力可能性より正解を評価可能かを先に確認する。
  • 本開発条件が未成立なら、機能・費用・精度を確約しない。
  • 質問数を増やすことを目的にせず、次の意思決定に必要な質問を優先する。

FIXED VOCABULARY

用語を自由文から、安定したIDへ変える

表示名は日本語のまま保ち、Agent出力では英語IDを使います。ページ追加時も、この語彙をプレイブックのスキーマとして維持します。

情報源ラベル7 definitions
customer_direct_statement

顧客本人の直接発言商談・メール等で本人が述べた内容。役割と決定権も併記する。

operator_direct_statement

現場担当者の直接発言実務の事実や例外に近いが、組織決定とは限らない。

intermediary_summary

仲介者による要約紹介会社や別部署が編集した情報。原文・話者・文脈を再確認する。

document

文書・既存資料報告書、仕様書、規程、議事録。作成者と更新日を残す。

actual_data

実データ件数、時間、ログ、見積、BOM、原価など。抽出条件も残す。

work_observation

業務観察現場同席や操作観察で確認した内容。観察範囲と例外性に注意する。

proposal_team

提案側受託側の分析・解釈・推測。顧客情報と混ぜず、仮説として扱う。

主張の種類7 definitions
business_fact

業務事実誰が、何を、どの頻度・時間・条件で行っているか。

problem_perception

課題認識何を問題と感じ、誰にどの影響があると捉えているか。

cause_hypothesis

解釈・原因仮説なぜ起きているかについての説明。事実とは分ける。

solution_hypothesis

解決仮説AI化、連携、自動化など、問題を解くための案。

request

要望欲しい機能・状態。背景や優先度が未確認でも存在する。

formal_requirement

正式要件決定権者が対象・優先度・制約を含めて合意した条件。

constraint

制約法令、期限、予算、既存契約、技術、運用上の動かせない条件。

確認状態5 definitions
unverified

未確認出所は分かるが、内容・背景・根拠をまだ確かめていない。

speaker_confirmed

本人確認済み話者本人へ意味と文脈を確認した。

evidence_confirmed

根拠確認済み資料、実データ、観察など裏付けを確認した。

multi_stakeholder_confirmed

複数関係者確認済み異なる役割の関係者間で認識の一致・差分を確認した。

customer_agreed

顧客合意済み提案や意思決定に使う条件として、顧客側で合意された。

判断領域7 definitions
value

価値なぜ取り組むのか

business

業務誰のどの業務を変えるのか

solution

解決何をどこまで実現するのか

feasibility

実現性技術・データ・運用上成立するか

execution_conditions

実行条件予算・期限・体制が成立するか

decision_making

意思決定誰が何を基準に決めるのか

client_readiness

顧客準備関係者ごとに、業務とシステムをどの粒度で判断できるか

提案タイプ9 definitions
discovery

調査・構想整理価値や対象業務をまだ説明できない。成果:現状理解、論点整理、次の意思決定材料

bottleneck_diagnosis

業務ボトルネック診断課題や長いリードタイムは見えるが、時間の内訳と原因を確認できていない。成果:実作業・待ち・判断・手戻りの構造、改善対象

ai_data_diagnosis

AI・データ実現性診断AI案はあるが、タスク・データ・評価・運用条件が未確認。成果:AI適用仮説、データ棚卸し、評価設計、PoC可否

requirements_definition

業務整理・要件定義価値は見えるが、業務・利用者・対象範囲が固まっていない。成果:業務フロー、要求、優先順位、対象範囲

poc

PoC・技術検証価値仮説があり、検証データ・評価方法・合否基準を説明できる。成果:成立条件、精度、連携可否、残存リスク

prototype

プロトタイプ画面・操作を見ないと利用者が要求を判断できない。成果:利用イメージ、操作仮説、要求の具体化

mvp

MVP開発価値仮説、利用者、ユースケース、検証方法を説明できる。成果:価値検証に必要な最小範囲と評価方法

full_development

本開発対象範囲、実現性、実行条件、意思決定条件が確認されている。成果:確定範囲、計画、責任分界、見積り

hold_or_decline

提案保留・見送り重大な前提が未確認、または予算・期限・期待値が成立しない。成果:不足条件、再開条件、見送る理由

bottleneck業務ボトルネック診断

長い、遅い、属人化している等の課題はあるが、時間の内訳と原因が未確認

実作業 / 探索 / 判断 / 転記 / 他部署待ち / 承認待ち / 手戻り / 例外
ai_dataAI・データ実現性

AIが解決仮説に含まれ、タスク・データ・評価・運用条件のいずれかが未確認

対象タスク / 入力データ / 正解・評価方法 / 人の確認と運用 / 機密・責任・フォールバック

OUTPUT CONTRACT

分析結果を、比較できるJSONへ固定する

JSON Schemaは表示形式ではなく判断契約です。未確認情報を空欄や推測で埋めず、どの提案を止めているかまで構造化します。

GOLDEN CASE

AI見積相談を、最初の回帰テストにする

正解例は文章の完全一致を求めるものではありません。判断上の不変条件が守られているかを確認します。

01

AI前提へ引っ張られないAI部品判断を未確認の解決仮説として維持する。

02

本開発へ飛ばない原因・データ・評価・組織合意が未確認なら診断を選ぶ。

03

待ち時間を落とさない1週間を実作業だけでなく待ち・承認・手戻りへ分解する。

04

予算感を昇格させない承認者と上限が不明なら承認済み予算として扱わない。

GOLDEN OUTPUT匿名化AI見積案件の期待JSONを開く