日本 B2B の商談・有償パイロット・契約・導入・更新

最終確認: 2026-08-01
対象: 国内企業へ、小さな SaaS、AI 業務支援、サービス先行型ソフトウェアを販売する個人開発者

この章は案件運用の設計であり、契約書・税務・個人情報の個別助言ではない。顧客、提供形態、データ、規制業種、契約期間、当事者の規模により結論が変わる。法令状態の正本は 06-security-privacy-legal-japan.md とし、重要案件は弁護士・税理士等へ確認する。

この章の役割

既存章は、顧客課題、価格、商談、プロダクトの初回価値、法務、12 週間の検証、創業者容量を扱っている。この章は、それらを実際の商流へ接続する。

商談
→ 適格化
→ 相互実行計画
→ 契約・発注・請求条件
→ 開始可能
→ 有償パイロット
→ 価値・安全・経済性の確認
→ 本契約
→ 定着
→ 更新・拡張または終了

正本の境界は次のとおり。

顧客、購入者、承認者、課題の戦略的定義: 01
価格、MRR、貢献利益、GRR/NRR: 02
画面内オンボーディング、価値イベント、プロダクト TTFV: 03
positioning、channel、growth 全体: 04
account 選定、contactability、attempt、reply、discovery evidence、Qualified handoff: 16
課金実装、SLO、サポート、復旧: 05
法令、利用規約、DPA、責任: 06
仮説・実験・12 週間・決定ログ: 07
業界固有のウェッジと安全境界: 08
CAC、導入・支援容量、13 週現金: 09
platform、決済面、agent 委任: 10
paid service job、標準範囲、例外、内部ツール・顧客 UI への昇格: 14
商談段階、パイロット、組織導入、価値レビュー、更新: 本章
コピーして使う書式: B2B 商流テンプレート集

先に結論

初期 B2B で最も危険なのは、利用者の好反応、口頭合意、署名、利用、成功指標、請求、入金、本契約を同じ「受注」として扱うことである。次の事実は互いに別である。

好意的な面談 ≠ Qualified
口頭の支払意思 ≠ Contracted
契約成立 ≠ Start-ready
請求書発行 ≠ 入金
ログイン ≠ 価値
技術的成功 ≠ 業務価値
パイロット成功 ≠ 本番準備完了
継続意向 ≠ 更新成立

有償パイロットは「安い本番」でも「長いデモ」でもない。顧客の本導入判断に必要な不確実性を、実業務と明確な終了日を使って減らす有償プロジェクトである。開始前に、判断者、判断日、必要証拠、本契約時の価格・範囲を置く。

trial、PoC、pilot、個別開発を分ける

類型	主な目的	典型的な範囲	支払意思の証拠
Demo	仕組みを理解する	売り手の例示データ、短時間	ほぼない
無料 trial	顧客が標準製品を自己評価	標準機能、軽い設定、固定期間	弱い
PoC	技術・データ上の実現可能性を検証	限定データ、非本番、明確な仮説	有償なら一部ある
有償 pilot	実業務で価値・運用・購入条件を検証	1 業務、1 組織、代表データ、期限付き	強い
Beta / design partner	製品方向を共同学習	未完成機能、頻繁な変更	契約内容による
個別開発	顧客仕様の成果物・役務を提供	専用仕様、連携、移行、開発	SaaS 需要とは別の証拠
Production	継続業務を本番提供	運用、監視、サポート、更新	継続支払で確認

実データ、個別設定、連携、人による成果提供、セキュリティ審査、顧客専用成果物が入るほど、無料提供では創業者時間とリスクだけが増える。無償にする場合も list price、実時間、現金原価を販売費/CAC として記録し、支払意思の証拠には数えない。

本章の paid pilot は、pilot_id に契約上の非ゼロ料金があり、その契約が有効になった案件を指す。draft は含めない。契約成立は pilot_contract_effective_at、実入金は複数の PaymentReceipt、初回入金と完済は pilot_cash_first_received_at / pilot_cash_paid_in_full_at として分け、未収でも paid pilot の契約 cohort から消さない。成果物の契約上の検収、顧客が業務価値を確認したこと、production の購入は別の証拠である。

PoC で技術が動いても、代表データ、現場運用、継続原価、権限、監視、購入手続を確認していなければ production の証拠ではない。経済産業省の 2026 年手引きも、PoC 前に KPI・合格線・測定方法を定め、効果だけでなく拡張性と運用上の懸念を確認するよう整理している。経済産業省デジタル・AI 省エネ手引き

四つの状態機械を分ける

CRM の一つの stage に全状態を詰め込まない。

1. 商談状態

Target
→ Discovery evidence
→ Qualified
→ Mutual plan agreed
→ Proposal / review
→ Contracted または Lost

各 opportunity_id に motion_type = pilot / production / renewal / expansion を持たせ、Contracted はその商談に対応する契約が有効になったことだけを表す。

2. Pilot 提供状態

Contracted → Not-ready → Start-ready → Running ↔ Paused → Terminal

Running 中の別イベント:
kickoff_at / first_workflow_at / first_value_confirmed_at
repeat_value_at / independent_value_at / final_readout_at

Terminal outcome:
Completed-go / Completed-no-go / Stopped-risk / Customer-cancelled
Provider-stopped / Expired-no-decision / Redesign

repeat_value_at と independent_value_at は別である。創業者が裏で直して二回動いても independent ではなく、一回だけ独力で動いても repeat ではない。

3. 請求・現金状態

Not invoiced
→ Invoice issued → Open → Partially paid → Paid
                  ↘ Voided / Credited

期日・例外フラグ: Due / Overdue / Disputed
入金・credit note・refund は別イベント

4. 契約関係

Agreement type: Pilot / Production / Amendment
Relationship state per agreement_id:
Draft → Contracted → Active → Expired / Terminated

Production の Active gate:
Contracted + Production readiness approved + Service started

Production service state（契約関係とは別）:
Not-started → Running ↔ Suspended → Ended

Renewal outcome:
Explicit-renewed / Auto-renewed / Nonrenewed / Terminated / Holdover

別軸の scope movement: Expanded / Flat / Reduced

Production service state は提供 stream の下位状態であり、契約が Active のまま一時停止する場合を表す。契約関係 state を停止状態で上書きしない。

production の提案は新しい opportunity_id の商談、拡張・縮小は契約 amendment として記録する。四つを共通の account_id、opportunity_id、pilot_id、agreement_id、invoice_id で結ぶ。商談を失注しても、請求済みパイロットの売掛やデータ削除義務は消えない。

買う組織を地図にする

企業は一人で買うとは限らない。小規模企業では同じ人が複数の役割を持つが、質問は役割別に行う。

役割	確認すること	欠けた場合の危険
利用者	実際の手順、例外、入力負担	使われない
業務責任者	品質、期限、承認、事故	成果を認められない
Champion	社内調整、導入理由	案件が止まる
経済的購入者	予算、優先度、ROI、撤退判断	好評でも払われない
署名権者	誰が契約を成立させるか	権限のない合意
購買・経理/AP	vendor 登録、PO、請求先、締日、支払日	入金が遅れる
IT・security・法務	連携、データ、契約、審査	契約後に差し戻される
データ責任者	利用目的、提供、削除、再委託	実データを使えない
導入責任者	作業、期限、研修、現場調整	Start-ready にならない

Champion が全て確認する予定 は確認ではない。少なくとも、価値を判定する責任者、支払・署名経路、日々の導入 owner を名前で置く。決裁者へ直接会えない場合は、Champion が社内説明できる 1 ページ資料、想定反論、価格、セキュリティ資料を渡し、回答を原文で戻してもらう。

Qualified は感触でなく証拠

Qualified opportunity は、次の証拠が揃った案件と定義する。

初回接触からここまでの source、attempt、reply、discovery evidence と acquisition cost は、16 章の Qualified handoffから opportunity_id と evidence package で受け取る。

最近発生した実業務と現在手順がある。
時間、費用、遅延、品質、損失のどれかを基準化できる。
次の発生日または意思決定日がある。
標準範囲で解ける部分と対象外が分かる。
必要データ・権限を安全に使える見込みがある。
利用、価値判定、購入、導入の owner が分かる。
予算源または購入可能な価格帯の確認経路がある。
顧客と自分の、期限付きの次行動がある。
創業者エコノミクス上、提供可能性がある。

次は失格または保留にする。

「AI を試したい」以外の業務目的がない
次の実業務がパイロット期間中に発生しない
顧客 owner、判断者、判断日がない
必要データを適法・安全に利用できない
成功指標を介入前に測れない
無料の顧客専用開発を成功条件にする
本契約価格を見せることを拒む
24/7、広い SLA、高損害判断等を個人の能力で担えない
現実的な価格でも現金・時間貢献が負になる

「今ではない」は永久失注ではない。再開トリガーと日付がある場合だけ nurture とし、次の行動がない案件を forecast に残さない。

段階は exit evidence で進める

段階	進めるための証拠
Discovery evidence	直近例、現在手順、影響、関係者の原文
Qualified	上の 9 条件、反証、次行動
Mutual plan agreed	双方 owner、期限、完了証拠、最終判断日を顧客が確認
Proposal / review	範囲、対象外、料金、production 条件、文書・審査工程を提示
Contracted	権限ある当事者間で適用文書が成立
Start-ready	データ、アクセス、担当者、基準値、日程、支払/credit 方針が揃う
First value confirmed	代表データで生じた業務価値を named owner が確認。成果物の契約検収とは別
Value reviewed	事前定義した証拠表を判断者と確認
Production contracted	本番価格、範囲、開始日を含む契約成立
Renewed	更新意向ではなく、契約上の更新が成立

次の行動 は「フォローする」ではない。

誰が / 何を / いつまでに / 何をもって完了とするか

Mutual Action Plan は顧客との共同工程表

本契約の意思決定日から逆算する。売り手だけのチェックリストは MAP ではない。

Milestone
減らす不確実性・リスク
必要証拠または成果物
顧客 owner / 提供者 owner
期限
状態
blocker
次の行動
完了証拠
最終更新日

最低限、次を置く。

業務・基準値確認
security / privacy / AI 利用確認
契約、注文、vendor 登録
請求・支払条件
データ・アクセス準備
kickoff と最初の実ジョブ
中間レビュー
最終価値レビュー
production 判断
開始または export・削除

顧客依存が遅れたら、口頭で期間を伸ばさない。MAP、終了日、料金、測定可能性を変更記録へ残す。

提案時に production 条件を見せる

パイロットだけを安く売り、本契約価格を成功後まで隠すと、価格検証にならない。提案時に次を示す。

パイロット価格、請求日、支払日
production の標準範囲と価格、または狭い価格帯
導入費、月額/年額、従量、上限
標準支援と追加作業単価
本番で別途必要な security、連携、SLA
成功しても自動移行しない場合の判断工程
失敗、未確定、顧客都合遅延、途中停止の扱い

初期費は、戻らない現金費と導入時間を少なくとも回収できるかを 09 の獲得と導入で確認する。成果だけに全額を連動させると、顧客側のデータ・承認・運用変化まで売り手が負うため、意図的な成果報酬でない限り避ける。

パイロットで減らす不確実性を選ぶ

一つの短いパイロットで全てを証明しようとしない。

不確実性	主な問い
Problem / value	この業務改善に優先度と経済価値があるか
Data	代表データが利用でき、品質が足りるか
Technical	必要な精度、遅延、連携を実現できるか
Workflow	現場の承認・例外・引継ぎへ入るか
Safety / control	重大失敗を止め、追跡、復旧できるか
Delivery economics	自分の時間・AI 原価・支援が上限内か
Commercial	購買、契約、請求、本契約が進むか
Recurrence	次の自然な周期にも同じ価値が必要か

一回限りのデータ整理が成功しても、継続 SaaS の需要は証明しない。反復課金を売るなら、次の自然な業務周期、履歴、監視、共同作業等の継続理由を観察する。期間内に二周期目が来ない場合、継続性は Unknown とする。

成功は六つの証拠表で判定する

加重平均の「82 点」では、重大事故と高い利用率が相殺される。初期案件は各領域を Green / Yellow / Red / Unknown で管理し、証拠、日付、owner、次の行動を付ける。

領域	証拠
Business outcome	baseline、target、actual、帰属の限界
Workflow adoption	first/repeat/independent value、利用者確認
Quality & risk	eligible job、重大失敗、人間修正、復旧
Delivery	MAP、顧客依存、期限、変更
Commercial	invoice、支払、buyer、契約・調達経路
Founder economics	現金貢献、支援時間、AI 原価、容量

AI 機能を含む案件では、Quality & risk、Workflow adoption、Founder economics の裏側を 12 章の eligible job、別々の quality/value/incident clock、provider usage、人手、workflow value cycle で作る。11 章の案件・契約・更新判断と、12 章の機能運用を一つの曖昧な「成功率」へ統合しない。

Red の種類と処置を分ける。

種類	例	直ちに行うこと
Stop-now veto	未封じ込めの重大 security、privacy、安全、権利リスク	影響する処理を停止し、封じ込め、通知、専門家 escalation
Pause / escalate	必須 data・owner 不在、未収、調達 blocker、測定不能	新規範囲を止め、owner と解除条件を置く
No-go at maturity	業務価値・品質・創業者経済性・商業条件が凍結した下限未達	production へ進めず、Redesign または Stop

価値や反復性は maturity 前なら通常 Unknown または Yellow とし、残期間でも達成不能と証明された場合だけ早期 Red にする。denominator = 0、未成熟、欠損、証拠が stale の場合は Unknown であって Green ではない。active な Stop-now veto が一件でもあれば Overall は Red とし、平均や裁量で上書きしない。少数顧客では health score を予測モデルと呼ばず、行動トリガーとして使う。

指標カードを介入前に凍結する

各指標に次を持つ。

名前 / 意思決定
対象業務・単位
baseline 値 / 期間 / source
target / guardrail / Red veto
分子 / 分母
測定開始・終了 / maturity_at / as_of
除外条件
データ owner / 判定 owner
顧客側作業
帰属上の注意
Green / Yellow / Red / Unknown の導出規則
Stop-now / Pause / No-go の発動条件と解除条件
変更履歴

指標は 1〜3 個の主結果と、安全・品質・支援時間の guardrail に絞る。例:

主結果: 月次照合作業 8.0 時間 → 4.0 時間以下
品質: 金額の未承認自動変更 0 件
追跡: 提案の根拠参照率 100%
提供負荷: founder 支援 2.0 時間 / 週以下

測定後に都合よく baseline、除外、分母を変えない。変更が必要なら旧定義を残し、変更後の期間だけへ適用する。

時間の時計を分ける

署名日から初回価値までの遅延も顧客体験なので消さない。一方、製品・提供能力を診断する TTFV と顧客準備待ちも混ぜない。

pilot_contract_to_first_value_elapsed
= first_value_confirmed_at - pilot_contract_effective_at

ready_to_first_value_elapsed
= first_value_confirmed_at - ready_at

pilot_contract_to_ready_elapsed
= ready_at - pilot_contract_effective_at

pilot_contract_effective_at は、NDA や基本契約の締結日ではなく、対象 pilot の注文・契約が有効になった時刻である。elapsed time は pause 中も止めず、契約日程の延長は原計画と改定計画を別版で残す。

さらに vendor work、customer wait、system wait の blocker 区間を記録する。同時発生し得る待ち時間を単純合計せず、合計する場合は重複しない critical-path 区間へ分割する。顧客待ちを分母から外して高速化を装わず、contract-to-value と ready-to-value の時計を並記する。

ready_at は次のうち、その案件で Required = YES または適用対象となる項目が全て揃った時刻とする。非該当は空欄でなく N/A / 理由 / 判定者 を残す。

契約・適用文書が確定
前払または与信・支払条件が承認
vendor 登録、PO、請求先が確認済み
適用される業務委託法、発注明示、インボイス、電子取引保存の gate が解決
提供者自身の安全管理、データ・security・AI 利用が承認
保存・削除、再委託、国外アクセスと適法根拠が確認済み
必要データ、アカウント、権限が利用可能
baseline が凍結
顧客と提供者の owner、会議日、判断日が確保
rollback、停止、事故連絡が共有

契約文書を役割で分ける

全案件で全書類が必要なわけではない。必要なものだけ選び、重複・矛盾・版を管理する。

文書	主な役割
NDA	交渉・評価中の秘密保持
提案・見積	商業条件の提示。契約性を明示
注文書 / pilot 個別契約	対象、価格、期間、当事者、開始条件
基本契約 / 利用規約	共通の権利義務、期間、責任、終了
SOW / 仕様・評価別紙	個別成果物、役務、受入、変更
DPA	個人データの指示、再委託、保存、削除、事故
Security / AI 別紙	技術・運用統制、AI 入出力、人間確認
SLA	外部サービス水準、除外、救済。提供可能時だけ
Subprocessor 一覧	再委託先、用途、地域、変更
PO / vendor 登録	顧客側の購買・支払手続
請求書	請求内容、税、期日、支払先

文書の優先順位は法律が自動的に決めてくれるとは限らない。注文書、DPA、SLA、基本契約、利用規約のどれが、どの対象事項について優先するかを明記し、顧客 PO の裏面約款も確認する。経済産業省の電子商取引準則は、利用規約の組入れや変更を含む現行法の解釈指針であり、法律そのものではない。電子商取引及び情報財取引等に関する準則

利用規約を契約内容にする場合は、申込前に規約を表示して契約内容とする合意を得る方法、または定型約款としての表示・合意要件を確認する。フッターへリンクがあるだけで、常に全条項が組み入れられるとは限らない。acceptance method / displayed version / timestamp / accepter / authority を保存し、規約変更は変更根拠、効力発生日、周知を別イベントにする。民法 548 条の 2〜4

SaaS の継続提供と顧客専用作業を分ける。

標準 SaaS: 利用権、期間、利用枠、support、service start
導入作業: 移行、設定、研修、個別成果物、受入条件
個別開発: 仕様、変更、知財、保守、検収、料金

アクセス提供の継続料金全体を、主観的な個別開発の「検収完了」まで未確定にしない。成果物受入、業務価値、本契約判断は別ゲートにする。請負・準委任等の分類は名称でなく実態により、必要なら専門家へ確認する。

経済産業省は、スタートアップ製品の評価購入について、検証自体を有償にし、過剰な完成保証・知財移転を避ける初期購買契約モデルを公開している。個別案件へそのままコピーせず、論点表として使う。初期購買契約モデル

日本で販売前に確認する事項

法令、税制、ガイドラインの時点依存説明は 06 章を正本とする。本章では、案件が開始可能かを次の証拠で判定する。

Gate	Start-ready の証拠
契約・規約	適用文書、版、優先対象、合意方法、表示版、日時、権限、監査証跡
業務委託	SaaS と個別役務を分け、フリーランス法・取適法の適用、発注明示、受領/提供日、検査、支払日を確認
インボイス	登録状態、法定記載事項と回収用の PO・提出方法・期日を分離
電子取引保存	送受信データ、見読、検索、改ざん防止、保存期間、vendor 停止後の export
個人データ	提供者自身の安全管理、処理区分、再委託、国外アクセス、適法根拠、削除、事故対応
AI	入出力、学習利用、第三者提供、provider 設定、人間確認、知財、security、役割

適用法不明、外国アクセス不明、規約版不明 を自動で Yes にしない。重要項目が Unknown なら Start-ready: NO とし、確認 owner と期限を置く。NDA は DPA、外国提供、AI 学習利用の許諾を代替しない。経済産業省の AI 契約チェックリストや初期購買契約モデルは論点表として使い、契約書そのものや個別助言とは扱わない。

Deal room を一つ作る

顧客ごとに散らばった最新版を探さない。権限を制限した案件フォルダへ次を置く。

00_account-and-contacts
01_discovery-and-baseline
02_map-and-decisions
03_proposal-and-pricing
04_contract-and-order
05_security-privacy-ai
06_invoice-and-payment
07_delivery-and-evidence
08_value-review
09_export-deletion-closeout

各文書に owner / version / status / effective date / approver / supersedes を持つ。顧客の機密資料と社内営業メモを同じ共有範囲に置かない。事例・AI 学習・他顧客への再利用許諾を、サービス提供の処理権限から分ける。

Kickoff は説明会でなく運用開始判定

kickoff で次を実行する。

対象 workflow を開始から承認・終了まで通す。
RACI と連絡経路を確認する。
baseline、target、guardrail、判定者を読み合わせる。
入力データ、権限、保存・削除を確認する。
最初の代表 job を予約する。
support 時間、対応時間、緊急停止を確認する。
中間・最終レビュー、本契約判断日をカレンダー化する。
対象外、変更、延長、途中停止を再確認する。

導入は次の段階を上げる。

合成・匿名サンプル
→ 顧客管理下の代表データで shadow 実行
→ 人間確認付き assisted 実行
→ 限定ユーザーの controlled self-service
→ production readiness 合格後の本番

高損害の判断や外部送信は、パイロット成功を理由に自動化レベルを飛ばさない。10 の委任ゲートを適用する。

変更要求を四分類する

分類	扱い
Defect	合意済み仕様を満たさない。修正と影響を記録
Standard configuration	標準範囲内。支援枠を消費
Reusable product improvement	複数顧客へ使える。roadmap で優先度判断
Customer-specific work	別 SOW、価格、日程、知財、保守を確認

成功に必要だから と言われても自動で範囲へ入れない。変更カードへ次を記録する。

要求 / 根拠 / 分類
元の約束との差
価値・品質・data・security・SLAへの影響
追加時間・現金費・価格
終了日・測定可能性への影響
知財・保守
顧客承認 / 提供者承認 / 日付

延長は失敗を隠す手段にしない。有償延長は一つの未解決仮説、固定期限、新しい判断日を持つ。回数は普遍法則ではなく、終了判断を先送りしないための内部ルールである。最終レビューでは、顧客判断 Buy / Extend / No-buy / Undecided、提供者判断 Accept / Conditional / Redesign / Decline、production 契約成立、readiness、service start を別イベントにする。

パイロット指標の正しい分母

進行中・未成熟案件を失敗にも成功にも混ぜない。各率に unit / cohort entered_at / maturity rule / as_of を付け、分子は必ず分母と同じ成熟コホートから取る。各段階の matured cohort は、原則 planned_due_at <= as_of OR terminal_at IS NOT NULL とする。早期停止、No-go、期限切れ No decision、未開始を分母から落とさない。

readiness、first value、independent value、repeat value は、同じ成熟コホートについて event_at <= as_of の attainment と event_at <= planned_due_at の on-time を併記する。期限後の回復を見せつつ、当初計画の失敗を消さない。

paid-pilot contract rate [unit = opportunity_id]
= pilot 契約が成立した opportunities
  / pilot_purchase_decision_due_at 到来または terminal の qualified opportunities

start-ready-on-time rate [unit = pilot_id]
= ready_at <= planned_ready_at の pilots
  / planned_ready_at 到来または terminal の同じ contracted-pilot cohort

first-value-on-time rate [unit = pilot_id]
= first_value_confirmed_at <= planned_first_value_due_at の pilots
  / planned_first_value_due_at 到来または terminal の同じ paid-pilot cohort

independent-activation-on-time rate [unit = pilot_id]
= independent_value_at <= planned_independent_value_due_at
  かつ founder_assistance <= agreed_limit の pilots
  / planned_independent_value_due_at 到来または terminal の同じ paid-pilot cohort

repeat-value-on-time rate [unit = pilot_id]
= repeat_value_at <= repeat_maturity_at の pilots
  / repeat_maturity_at 到来または terminal の同じ paid-pilot cohort

first-pilot-to-production-contract eventual rate [unit = account_id]
= production_contract_effective_at <= as_of の accounts
  / 初回有償 pilot の original_production_decision_due_at 到来または terminal の同じ account cohort

first-pilot-to-production-contract on-time rate [unit = account_id]
= production_contract_effective_at <= original_production_decision_due_at の accounts
  / 上と同じ成熟 account cohort

production-contract-to-go-live-on-time rate [unit = agreement_id]
= service_started_at 時点で contract effective と readiness approval が有効で、
  Active gate passed event があり、
  service_started_at <= original_planned_go_live_at の production agreements
  / original_planned_go_live_at 到来または terminated の同じ production-agreement cohort

customer decision latency
= customer_decision_at - final_readout_at

provider decision latency
= provider_decision_at - final_readout_at

production contract effective latency
= production_contract_effective_at - final_readout_at

open customer decision age
= as_of - final_readout_at  # customer decision がない場合

first-pilot-to-production では 1 account を一度だけ数え、延長や再試行を新しい成功機会として分母へ足さない。期限後の eventual success と当初期限内の on-time success を併記する。開始不能、停止、明示的 No-go、期限超過の No decision は非転換の理由別に残す。

後日の suspension、readiness 失効、termination で、過去に正しく通過した on-time go-live を分子から消さない。率は現在状態でなく、service_started_at 時点の contract、readiness review、Active gate event の履歴を使う。

同時に次を追う。

pilot_contract_effective_at → ready_at の日数と blocker
顧客所有 MAP 項目の期限内完了 x/n
eligible job、initially accepted、accepted after human correction、finally rejected/abandoned、no output、critical failure
founder 獲得・導入・pilot fulfillment・支援時間
AI/API/決済/外注の現金費
invoice date、due date、paid date、overdue amount
パイロット現金貢献と完全負荷後貢献

創業者時間は precontract_commercial / onboarding_to_ready / pilot_fulfillment / support_incident / customer_specific_change / reusable_product_work のいずれかへ一度だけ分類する。サービス先行型では、成果を作る pilot_fulfillment を onboarding や support の外へ落とさない。

pilot 完全負荷後貢献
= pilot fee - pilot cash cost
  - (onboarding_to_ready + pilot_fulfillment + support_incident
     + customer_specific_change) × internal hourly value
  - allocated acquisition cost

複数顧客へ再利用する製品開発は reusable_product_work として別に見せ、都合よく顧客固有作業から移し替えない。

この案件台帳の pilot_id / agreement_id / invoice_id / PaymentReceipt は商業上の正本であり、14 章の service_job_id は一回の約束した成果と実作業を表す。一契約に複数 job があり、一 job に複数工程・例外がある。未収を paid job の反復成功へ読み替えず、契約、入金、成果受容、反復価値を別 event のまま結ぶ。

job の outcome は一件一つの相互排他的な最終分類にし、critical failure が重なる場合は別フラグにする。1 社が 100 job を処理しても、市場の商業再現性は n=1 account である。job 数は同社内の信頼性には使えるが、100 社分の更新証拠にはならない。率だけでなく 3/3 accounts、顧客別 x/n、account-weighted rate、顧客属性、除外、自然周期、失敗理由を出す。紹介や design partner の便宜標本を市場全体へ一般化しない。

重み付き pipeline の主観確率を現金へ入れない。小標本では、案件名、段階、阻害要因、最短・基準・最長日を使う。

Customer Success は成果の再現を助ける運用

サポートは質問・障害へ対応する。Customer Success は顧客が意図した業務成果を、自然な周期で安全に再現できる状態を作る。会議回数やログイン数を成果にしない。

初期の account health は次を個別表示する。

領域	観測
Value	baseline 対 actual、顧客の受容、未解決の帰属
Workflow	first/repeat/independent value、利用範囲、shadow 作業
Relationship	champion、buyer、運用 owner、次の判断日
Operations	incident、support 時間、AI 修正、未解決 issue
Commercial	invoice、契約、更新日、調達・security blocker

次は health score を上書きする hard red flag とする。

重大事故または未封じ込めの高リスク
buyer と運用 owner の役割が誰にも実質的にカバーされない。champion が必要な組織ではその消失
期限超過の未収、契約不能、調達停止
反復 job がなく、継続理由がない
founder の fulfillment・支援時間が容量を超える
顧客が成果を受容していない

AI の感情分析で renewal 82% のような偽精密値を作らない。原文、利用イベント、MAP、請求、issue を証拠として並べ、推論は明示する。

本番移行は別ゲート

PoC コードが動いたことと production readiness は別である。各要件を次の列で判定する。

Requirement / Required?
Pass criterion / Evidence
Owner / Reviewer
Status: Pass / Conditional / Fail / Unknown
Exception approver / Risk owner
Remediation due / Exception expiry

重大な security、privacy、安全、権利の Stop-now veto は conditional pass の対象にしない。Active は次を同時に満たす場合だけ設定する。

production_contract_effective_at IS NOT NULL
AND production_readiness_status IN (PASS, CONDITIONAL_APPROVED)
AND service_started_at IS NOT NULL

conditional exception の期限が切れて未是正なら readiness を Fail、service_state = Suspended とし、停止・再開 event を残す。model/provider、data class、処理目的、use case、権限、重要な連携・SLA が変わった場合は readiness を Unknown に戻し、差分を再審査する。初回承認を永久許可にしない。

少なくとも次を確認する。

tenant 分離、認証、権限、監査ログ
代表負荷での性能、可用性、利用上限
監視、alert、on-call の現実的範囲
backup、復元試験、rollback
個人データ、保存、削除、subprocessor
incident 通知と顧客連絡
AI eval、human review、重大失敗停止
entitlement、請求、超過、支払失敗
support、maintenance、SLA/SLO
export、終了、サービス継続リスク
本番原価と創業者容量

個人で 24/7 SLA や高額責任を履行できない場合、契約文で隠さず、support 時間、優先度、代替手段、export、復旧目標を現実に合わせる。顧客要件が越えるなら、partner、法人化、保険、運用体制を整えるか、受注しない。

更新は kickoff から管理する

記録する日付:

contract start / end
auto-renewal の有無
解約・変更通知期限
顧客の予算確定日
security / procurement review の所要期間
natural_cycle_length / next_cycle_at
価値レビュー日
更新判断者 / 署名者 / invoice 予定

固定の「90 日前」を法則にしない。通知、予算、価値証拠、調達の締切を日付で置き、最も早く作業を始める必要がある日を採用する。

renewal_work_start
= min(
    notice_deadline - internal_review_buffer,
    budget_decision_date - value_evidence_lead_time,
    renewal_effective_date - procurement_security_lead_time
  )

value_evidence_lead_time
= wait_until_next_cycle
  + natural_cycle_length
  + evidence_review_buffer

価値証拠の観測後に社内承認が始まる等、工程が直列なら所要期間を足す。並列に進められる工程だけを max でまとめる。入力が不明なら日付を推測せず、Unknown / owner / due として更新案件を止めないための確認期限を置く。

更新 dossier に入れる。

契約時の baseline・期待成果
実績、顧客確認、帰属の限界
first/repeat/independent value
incident、重大失敗、未解決 risk
顧客側と founder の作業時間
当初 ROI 仮説との差
次期の価格、範囲、選択肢
buyer、approval、notice、請求の日程

契約関係の結論は Explicit-renewed / Auto-renewed / Nonrenewed / Terminated / Holdover、同時期の scope movement は Expanded / Flat / Reduced と別に記録する。自動更新は契約上の継続であって、顧客が価値を能動的に再確認した証拠とは限らない。拡張は現在 job の反復価値、隣接 job の owner と予算、増分貢献、support 容量が確認でき、新範囲の data/security/readiness gate を通る場合だけ行う。

終了時は、アクセス停止、export、削除、backup 失効、未収・返金、秘密資料、事例掲載、ログ保存、法定保存を台帳化する。削除と法定・紛争保存を分ける。

案件・契約単位の closeout は本章で行い、複数製品を横断する終了予算、共通依存、売却・譲渡、closed gate は 15 章へ集約する。

請求台帳を 13 週現金へ接続する

契約総額を請求額の代わりにしない。一請求一行の Invoice と、分割入金の PaymentReceipt、値引・取消の CreditNote を分ける。

Invoice
invoice_id / agreement_id
quote amount
contract amount
PO number / vendor registration
invoice_total_gross / invoice issue date
tax / currency / registration status
due date
expected receipt date
credit_note_amount
amount_applied = sum(PaymentReceipt.amount_applied_to_invoice)
outstanding_amount
  = max(0, invoice_total_gross - credit_note_amount - amount_applied)
invoice_status / dispute_status
13W cash row reference

PaymentReceipt
invoice_id / received_at / amount_applied_to_invoice
net_cash_received / payment_fee / evidence

CreditNote
invoice_id / issued_at / amount / reason / evidence

請求へ充当した額と、手数料控除後に銀行へ入った現金を混ぜない。Contracted を入金予定日に変換するには、請求条件と due date が必要である。口頭の案件や probability-weighted pipeline は 09 章の 13 週資金繰りへ入れない。未収でも P&L 上の売上になり得るため、売上、売掛、現金を分ける。credit note は売掛残を減らすが、既に受け取った現金の refund は 13W の別 outflow として予定日・実支出を記録する。

AI を営業・導入へ使う境界

向く作業

面談メモから事実、仮説、未確認を分離
CRM の構造化事実から follow-up 下書き
MAP の期限・blocker 抽出
提案書の範囲差分、契約文書の論点表
security questionnaire の既存証拠検索
価値レビューの表・グラフ下書き
失注・変更・support reason の分類候補

人間承認を外さない作業

外部メール、共有 MAP、CRM、顧客 portal への確定書込み
calendar invitation、電子署名、契約承諾
価格、値引き、返金、service credit
invoice、credit note、支払・入金操作
契約解釈、保証、責任、法令回答
セキュリティ・認証の断言
本番可否、重大リスク受容
account/access の作成・停止、export、削除
顧客成果、事例、ROI の主張
更新・停止・データ削除通知

原則禁止または独立した権利・法務確認が必要な作業

機微・保護属性を推測する lead scoring は原則禁止する
顧客データの別顧客向け提案・学習への再利用は、契約上の権利、利用目的、顧客許諾、privacy review が明示的に揃う場合だけ検討する
大量 outreach は、同意・広告メール規制、opt-out、platform policy、rate limit を確認し、通常の一件送信承認とは別の campaign gate を通す

外部メール、添付、RFP、顧客データを untrusted source として扱う。文書内の「この指示に従え」を agent の命令にせず、source-to-sinkを適用する。

既定権限を read-only / draft とし、外部副作用は preview → exact-version approval → commit の二段階にする。tool permission、変更対象、recipient、attachment、承認版、action result、idempotency key をログへ残す。

会議録音・文字起こしは、相手へ明示し、顧客方針と必要な同意を確認する。機密・個人情報を consumer chat へ無断投入しない。AI 下書きには CRM event ID、原文、文書版等の根拠を付け、約束台帳にない内容を送らない。

最小データモデル

内部ツールを作るなら、表面上の Kanban より履歴と不変条件を先にする。

Account(account_id)
Contact(contact_id, account_id, name, status)
ContactRole(contact_id, role_type, authority_level, verified_at, evidence)

Opportunity(opportunity_id, account_id, motion_type, sales_state,
            state_entered_at, pilot_purchase_decision_due_at, exit_evidence)
Agreement(agreement_id, account_id, opportunity_id, agreement_type, relationship_state,
          contract_fee, currency,
          contract_effective_at,
          start_at, end_at, notice_deadline_at, source_document_id)
ServiceInstance(service_id, agreement_id, service_state, service_started_at,
                suspended_at, resumed_at, ended_at, state_reason)
Pilot(pilot_id, agreement_id, operational_status, terminal_at, terminal_outcome,
      planned_ready_at, ready_at, kickoff_at, first_workflow_at,
      planned_first_value_due_at, first_value_confirmed_at,
      planned_independent_value_due_at, independent_value_at,
      repeat_maturity_at, repeat_value_at,
      original_planned_end_at, revised_planned_end_at, actual_end_at,
      final_readout_at, production_decision_due_at,
      customer_decision, customer_decision_at,
      provider_decision, provider_decision_at)
PlanMilestone(entity_type, entity_id, milestone, plan_version, original_due_at,
              current_due_at, changed_at, change_approval, change_reason)
AssistanceBudget(pilot_id, metric_definition_id, agreed_limit, unit,
                 observation_window, included_time_classes, actual_assistance)
Invoice(invoice_id, agreement_id, billing_state, invoice_total_gross,
        credit_note_amount, amount_applied, outstanding_amount, issue_at, due_at,
        dispute_status)
PaymentReceipt(invoice_id, amount_applied_to_invoice, net_cash_received,
               payment_fee, received_at, evidence)
CreditNote(invoice_id, amount, issued_at, reason, evidence)
Refund(invoice_id, amount, expected_at, paid_at, reason, evidence)
StateEvent(stream, entity_type, entity_id, from_state, to_state,
           actor, evidence, occurred_at)
MutualCommitment(owner_side, owner, due_at, completion_evidence)
CommercialPromise(account_id, opportunity_id, agreement_id, pilot_id,
                  scope, price, service, approved_by, source_document)
MetricDefinition(metric_definition_id, version, unit, cohort_rule, maturity_rule,
                 as_of_rule, numerator, denominator, baseline, target)
MetricObservation(metric_definition_id, metric_version, account_id,
                  pilot_id, job_id, value, source_id, observed_at)
DeliverableAcceptance(deliverable_id, agreement_id, criteria_version,
                      owner, submitted_at, due_at, accepted_at,
                      rejected_at, rejection_reason, source_document_id)
ProductionReadinessRequirement(agreement_id, requirement, required, criterion,
                               status, evidence, reviewer, exception_approver,
                               risk_owner, remediation_due, exception_expiry)
ProductionReadinessReview(agreement_id, aggregate_status, approved_by,
                          approved_at, valid_until, trigger_snapshot)
ActiveGateEvent(agreement_id, passed_at, contract_event_id,
                readiness_review_id, service_start_event_id)
TimeEntry(account_id, pilot_id, class, hours, occurred_at)
ChangeRequest(class, impact, price, approvals)
Document(type, version, status, effective_at, precedence)
ValueReview(decision, evidence, limitations)
Renewal(agreement_id, renewal_decision_at, relationship_outcome, scope_movement)

不変条件:

sales は opportunity_id、delivery は pilot_id、billing は invoice_id、relationship は agreement_id ごとに状態と履歴を持つ
Qualified は exit evidence なしに設定しない
Start-ready は全必須 prerequisite が完了した時だけ
paid pilot は agreement_type = Pilot AND contract_fee > 0 AND contract_effective_at IS NOT NULL を満たし、draft、契約成立、実入金を別イベントにする
業務価値の確認と成果物の契約検収を同じ event にしない
metric definition の版を過去観測へ遡及適用しない
original due date を上書きせず、current due date と plan version を追加する
外部約束は承認者と source document を持つ
invoice issued、分割入金、credit note、refund を別イベントにする
Active は production 契約、readiness 承認、service start の三つを必要とする
過去の gate 通過率は immutable event から計算し、現在の停止・終了状態で遡及変更しない
conditional readiness の失効・未是正は service を停止し、重要変更は readiness を Unknown へ戻す
renewal outcome と scope movement を別にする
削除済み顧客の営業メモと法定保存を目的別に隔離する

架空例: 広告制作会社の月次クローズ

これは市場相場でなく、運用を説明する架空例である。

顧客: 20 人の広告・制作会社、管理責任者 1 名、実務者 2 名
課題: 案件原価と請求漏れ候補の月次照合
現状: CSV 3 種を手作業照合、月 8 時間
pilot: 4 週間、30 案件、1 部門、CSV 入力、外部自動送信なし
価格: 初期・pilot 100,000 円
production 仮説: 月 50,000 円、標準支援 1.5 時間/月
主結果: 照合作業 4 時間以下
guardrail: 未承認の金額変更 0、根拠参照 100%
founder gate: 導入 8 時間、pilot fulfillment 6 時間、継続 1.5 時間/月以下

判断者は管理責任者、利用 owner は経理担当、支払・署名は代表、data owner は管理責任者とする。契約、CSV 項目、baseline、請求先、最終レビュー日が揃うまで Start-ready にしない。

結果が 3.5 時間でも、創業者が毎週 6 時間裏で修正していれば、Business outcome は Green でも Founder economics は Red である。金額変更を人が承認し、二回目の月次周期で同じ流れを再現でき、本契約が成立して初めて継続提供へ進む。

90 分で案件を監査する

0〜15 分: 状態を分離

商談、提供、請求、契約の現在状態
最終イベントの日時
次の行動、owner、期限

15〜30 分: 買う組織

利用、価値、予算、署名、購買、data/security、導入 owner
champion 一人へ依存していないか

30〜45 分: パイロット判定

減らす不確実性
baseline、target、guardrail、判断日
production 価格・範囲

45〜60 分: 文書と現金

文書版、優先順位、PO、vendor 登録
invoice、due、expected/actual cash
13 週予測への接続

60〜75 分: 開始・提供

Start-ready prerequisite
顧客待ち、support 時間、変更要求
data、AI、security、production gap

75〜90 分: 一つの判断

Advance / Hold with trigger / Re-scope / Stop
根拠:
最も大きい Unknown または Red:
次の行動 / owner / 期限 / 完了証拠:

監査の成果は「資料を整えた」ではなく、曖昧な案件を一段進めるか止めることである。

リリース前チェック

根拠の扱い

公開資料から、あらゆる B2B パイロットに使える成功率、MAP の因果効果、万能な TTFV、health score 閾値は確認できない。数値ベンチマークを輸入せず、自社の account/job/自然周期を分けて観測する。

IPA の 2025 年分 DX 推進指標は 1,164 件の自己診断を分析し、多くの提出企業が散発的・戦略的実施の段階に留まると報告する。これはパイロット失敗率ではなく、提出企業の自己診断である。IPA 2025 年版分析

AWS の pilot/生成 AI PoC 資料は、開始前の成功条件・次の行動、代表利用者、業務価値、data readiness、技術・risk を確認する実務例として使える。ただし AWS の vendor guidance であり、因果研究や日本法の根拠ではない。AWS Running a pilot / AWS Generative AI PoC

法令、税制、PPC ガイドライン、顧客の購買規程、AI provider 条件は販売・更新直前にも再確認する。