サービス先行型ソフトウェアを、再現可能なプロダクトへ変える

最終確認: 2026-08-01
対象: Codex を中心に、国内 B2B の反復業務を手作業・AI・小さな Web アプリで提供する個人開発者

この章は、サービス提供から内部ツール、顧客支援型プロダクト、セルフサービスへ進むかを判断する運用設計である。サービス先行が一般に SaaS より成功しやすい、または本章の順序・件数・価格が市場標準であることを示す因果的証拠はない。契約、個人情報、業法、税務、会計上の扱いは案件ごとに異なるため、06 章と専門家確認を正本にする。

この章の役割

このプレイブックは、最初からセルフサービス製品を完成させず、有償で成果を届けながら、入力、例外、品質、支払意思を学ぶことを勧めている。00 章は「手作業 → 内部ツール → 顧客 UI」という方向を示し、07 章は 12 週間の提供を、11 章は有償パイロットから更新までを扱う。

しかし、売れた手作業をそのままコードへ変えると、次の失敗が起きる。

• 一社だけの例外を「市場の要件」と誤認する。
• 創業者の手作業を顧客へ移しただけなのに、自動化したと数える。
• 内部ツールが時間を減らしただけで、セルフサービス需要まで証明したと考える。
• 顧客の承認、契約、請求、AI の自律性、コード変更 risk を一つの成熟度へ混ぜる。
• 顧客別 rescue を標準価格に埋め込み、売上と同時に創業者時間も増やす。
• Codex が速く実装できるため、頻度・価値・安全性の弱い工程まで製品化する。

本章は、一件の有償成果から得た証拠を、次の閉ループへ接続する。

有効な契約・範囲
→ paid service_job
→ workflow / step / time / cost / exception
→ 製品化候補と安全 veto
→ Codex change_id
→ 限定された delivery mode 変更
→ 同じ粒度で価値・時間・原価を再観測
→ 維持 / promotion / reversal / 別 SOW / stop

既存章との正本境界は次のとおり。

• 顧客、問題、ICP、支払意思、競争優位: 01 章
• 価格、価値指標、SaaS 指標、会計: 02 章
• 顧客 UI、TTFV、オンボーディング、継続: 03 章
• positioning、channel、提携: 04 章
• account 選定、接触、discovery、Qualified handoff: 16 章
• Web 実装、課金、SLO、AI eval、復旧: 05 章
• 契約、個人情報、AI 利用条件、法務・税務: 06 章
• 12 週間、仮説、実験、撤退: 07 章
• 業界固有のウェッジと自動化しない判断: 08 章
• 創業者時間、容量、完全負荷後貢献、13 週現金: 09 章
• platform、agent 委任、read / draft / write / send / pay: 10 章
• 商談、契約、請求・入金、pilot / production / renewal: 11 章
• AI job、attempt、provider usage、人手、品質、反復価値: 12 章
• Codex task、risk tier、exact evidence、release、観測: 13 章
• サービスを何段まで製品化するか、その根拠と移行: 本章
• コピーして使う 8 書式: service productization pack
• 粒度、履歴、制約、判断 view の実行例: SQLite companion

先に結論

1. 製品化の単位はアプリ全体でなく、workflow_version × step_id × ICP × data class である。 一つのサービス内で、受付は顧客 UI、照合は内部ツール、最終承認と外部送信は人、という混在を許す。
2. 有償契約内の一成果を service_job_id で記録する。 契約、請求、入金、AI call、顧客価値を一つの状態へ潰さず、既存章の ID へ結ぶ。
3. 時間は active work、queue wait、customer effort を分ける。 創業者時間が減っても顧客時間や失敗が増えたら改善とは限らない。
4. scope envelope を版管理する。 標準入力、成果、予定 review、対象外、SLA、追加料金を先に固定し、後から無料の個別対応へ広げない。
5. 例外は原因と処置を分ける。 顧客固有要求、製品 defect、安全停止、provider 障害、入力不備を同じ「サポート」にしない。
6. 安全 veto を通った候補だけを経済性で順位付けする。 高頻度でも、無権限、不可逆、高損害、評価不能な工程は自動化しない。
7. promotion は一段ずつ、狭い segment で行う。 内部ツールの成功は顧客 UI の需要を、顧客 UI の利用はセルフサービスの継続を証明しない。
8. reversal は失敗ではなく制御能力である。 品質、創業者 rescue、顧客負担、原価、契約条件が悪化したら、前の delivery mode へ戻す。
9. Codex には実際の有償 job から作った受入条件と安全な fixture を渡す。 顧客データ、秘密、契約上使えない成果物を prompt、Git、eval へ貼らない。
10. セルフサービスを最終目的にしない。 標準化された managed service が高い顧客価値と十分な完全負荷後貢献を持つなら、それ自体が成立した事業である。

市場観測と本章の推論を分ける

本章の運用は、次の観測とプレイブック内部の制約から導く。外部資料はサービス先行の優位を直接検証していない。

観測 1 — アプリ供給の増加は、公開数を売上証拠にしない理由になる

RevenueCat の State of Subscription Apps 2026 は、RevenueCat を組み込み、一定の install または売上条件を満たす 11.5 万超の subscription app、160 億ドル超の売上、10 億件超の取引を分析し、主な対象期間を 2025 年としている。同データでは月間の新規 subscription app は 2022 年 1 月の約 2,000 から 2026 年 1 月の 14,700 超へ増えた。2020 年より前に公開された app が対象売上の 69%、2025 年以後の app は 3% を占める。また AI app は payer 当たり実現価値が高い一方、12 か月 retention は月次 plan で 6.1% 対 9.5%、年次 plan で 21.1% 対 30.7% と非 AI app より低い。RevenueCat, State of Subscription Apps 2026

これは RevenueCat 採用 app の subscription-level 観測であり、日本の小規模 B2B Web SaaS、受託、請求書払い、account renewal を代表しない。したがって本章では、この数値を retention 目標やサービス先行の因果証拠に使わない。「作って公開した」だけでは商業的成功を推定できず、自分の paid job と自然周期の反復価値を測る必要がある、という警告に限定する。

観測 2 — 日本の一部中小企業では、用途具体化と推進能力が導入障壁である

2026 年版中小企業白書・小規模企業白書の概要は、2019 年以降の省力化投資で AI 活用に取り組んでいない回答者（n=3,888）への複数回答で、理由の上位を「活用する業務がイメージできていない」63.4%、「活用を推進する人材が不足している」40.0%、「社内ルール・ガイドラインが整備されていない」26.2% と報告する。中小企業庁, 2026 年版中小企業白書・小規模企業白書の概要, p.21

これは特定調査への回答であり、全中小企業が AI 導入支援へ支払うこと、また個人開発者が安全に提供できることを示さない。本章では、「AI 機能を見せる」前に、対象業務、責任者、入力、既存手順、ルール、支払者を共同で具体化する余地がある、という探索仮説に限定する。

観測 3 — 反復 workflow の標準化と再利用が企業利用で増えている

OpenAI の 2025 enterprise report は、同社の enterprise usage と約 100 社・9,000 人の worker survey を基に、Custom GPTs と Projects の weekly users が年初来で約 19 倍となり、直近には enterprise message の約 20% がそれらを通ったと報告する。同報告は、先行利用企業の実務として、workflow の標準化と再利用、institutional knowledge の machine-readable 化、data API、continuous evaluation を挙げる。OpenAI, The state of enterprise AI 2025

これは OpenAI 顧客と自己申告 survey を含む vendor report であり、利用増加と売上・利益の因果を証明しない。大企業の operating model を個人開発者へそのまま移さない。本章では、反復手順、入力契約、評価、連携が workflow 実装の構成要素になる、という方向確認に使う。

観測 4 — API 利用は一部の反復業務へ集中している

Anthropic Economic Index 2026 年 1 月版は、2025-11-13〜20 の Claude.ai 会話 100 万件と first-party API の prompt-response pair 100 万件を privacy-preserving に分類した。first-party API では上位 10 task が traffic の 32% を占め、Office and Administrative Support は 2025 年 8 月から 3 percentage point 増えて 11 月に 13% となり、email、document processing、CRM、scheduling 等の back-office workflow が例示される。Anthropic, Economic Index report: Economic primitives, 2026-01

これは一週間の Anthropic first-party API sample を model classifier で分類した結果であり、顧客数、成功率、収益、継続、地域別需要を示さない。本章では、広い「AI 導入」より、頻度と完了状態を定義できる狭い workflow を候補にする補助材料としてのみ使う。

本章の推論

以上と既存章から、個人開発者には次の順序が合理的な仮説である。

コードより先に有償成果を狭く約束する
→ 自分が提供者として入力・例外・受入を観測する
→ 安定した一工程を内部ツール化する
→ 顧客へ移しても価値と経済性が保たれる工程だけ UI を開く
→ 独立した反復価値が確認できた segment だけ self-service を試す

この順序が自分の市場で正しいかは、価格付き提案、契約、実入金、service_job、創業者時間、顧客 effort、自然周期の反復、更新で反証する。

四つの軸を混ぜない

「本番」「自動」「セルフサービス」「高 risk」は互いの同義語ではない。次の四軸を別フィールドで持つ。

軸	正本	値の例	答える問い
Commercial motion	11 章	pilot / production / renewal / expansion	何を契約・購入判断しているか
Delivery mode	本章	manual_bespoke / managed_standard / founder_internal / customer_assisted / customer_self_service	誰が標準工程をどの interface で行うか
Agent delegation	10 章	read / draft / reversible write / send / preauthorized execute	AI/agent にどの操作権限を渡すか
Change risk	13 章	R0 / R1 / R2 / R3	変更失敗時の最大影響、可逆性、検知可能性は何か

例:

• production 契約でも、裏側は managed_standard と人の最終承認でよい。
• customer_self_service の CSV validation は決定的処理で agent delegation 0 でもよい。
• 創業者専用の founder_internal tool でも、顧客個人情報や tenant を誤処理すれば R2 になり得る。
• customer_assisted UI でも、外部送信は Level 3、下書きは Level 1 と operation ごとに違う。
• 有償 pilot で内部ツールが動いても、production 契約、self-service demand、更新は別証拠である。

四軸を一つの maturity = 4 へ符号化しない。軸ごとの現在値、証拠日、適用範囲、owner を残す。 非商業の test / synthetic control を commercial motion に足さない。必要なら commercial_basis = nonpaid_test / nonpaid_sample / synthetic_fixture として別軸にし、paid evidence から除外する。

account_id:
workflow_id / workflow_version:
step_id:
ICP / data_class:
commercial_motion:
delivery_mode:
delegation_level:
change_risk_tier:
evidence_as_of:
decision_owner:

Delivery mode は workflow step ごとに持つ

製品全体へ一つの mode を付けると、危険な工程まで一緒に昇格する。正本の粒度は次である。

delivery_mode_scope
= workflow_version × step_id × ICP/segment × data_class

Mode	標準工程の主実行者	顧客から見えるもの	適する状態	誤認しやすいこと
manual_bespoke	創業者が顧客別手順で実行	成果物・個別連絡	問題・入力・受入を探索中	支払があれば SaaS 需要がある
managed_standard	創業者が版管理した runbook で実行	標準 offer、成果、SLA	同じ成果を反復提供できる	人が行うからプロダクトでない
founder_internal	創業者が内部 tool で実行	原則として標準 service のまま	頻出工程を安全に効率化する	内部時間削減が self-service 需要を示す
customer_assisted	顧客が開始・確認し、標準 review/例外を創業者が処理	限定 UI、状態、承認、support	入出力が安定し顧客操作が価値を損なわない	ログインを independent value と数える
customer_self_service	顧客が標準経路を完了し、創業者は定義済み support/incident のみ	onboarding、課金、操作、export、解約	独立した反復価値と容量が成立	人の支援が一件でもあれば失敗

managed_standard や founder_internal は過渡期に限らない。顧客が操作を望まず、成果物と責任ある review に支払うなら、managed service を維持する。逆に self-service でも、契約上予定した human approval、通常 support、incident 対応はあり得る。12 章の planned_review と founder_rescue を分ける。

一つの workflow は mode を混在できる。

顧客 upload             customer_assisted
schema validation       customer_self_service / deterministic
AI extraction           founder_internal + planned review
例外判断                managed_standard / human
顧客承認                customer_assisted
外部送信                managed_standard / human send

最も自動化された step を製品全体の mode と呼ばない。顧客向け offer には、誰がどこまで行うかを平易な言葉で示す。

Paid service_job を一件の商業的成果として残す

定義

service_job_id は、有効な非ゼロ料金の agreement または order の標準範囲に含まれ、顧客へ一つの受入可能な成果を届ける delivery unit である。

例:

• 広告会社の一顧客・一月の close pack
• 工事案件一件の追加工事証拠 pack
• 一物件・一修繕案件の owner 承認 pack
• 一締め周期・一事業所の請求前例外 review

「有償」は契約上の scope を表す。次は別々に記録する。

有効な非ゼロ料金 agreement に含まれる
≠ job 単価を独立配賦できる
≠ invoice が発行済み
≠ cash を受領済み
≠ 成果が受け入れられた
≠ 顧客価値が確認された
≠ production / renewal が成立した

契約、請求、実入金の正本は11 章に置く。月額 bundle を job へ恣意的に配賦しない。明示的な job 単価または介入前に固定した配賦規則がなければ、job_revenue_allocation_status = unallocated とし、account commercial cycle で貢献を見る。

job_id と重複させない

12 章の job_id は、AI 機能を含む一つの顧客成果要求を分析する単位である。本章の service_job_id は契約 scope と delivery を結ぶ wrapper とする。

標準関係:

service_job_id 1 ── 0..n job_id

• AI 機能を使わない manual service なら job_id = 0 でもよい。
• 一つの service 成果に抽出、照合、説明という別々の AI job があるなら job_id = n となる。
• service 成果と AI job が完全に同じ粒度でも、ID の役割は維持し、mapping table で 1:1 に結ぶ。
• provider retry、再生成、手動 fallback は新しい service_job_id にせず、12 章の attempt へ置く。

最小 service_job record

service_job_id:
account_id:
opportunity_id / pilot_id:
agreement_id / order_id:
invoice_line_id:             # 未発行・bundle は null + reason
commercial_basis:            # paid_pilot / paid_production / paid_change
job_revenue_allocation_status:
workflow_id / workflow_version:
scope_envelope_version:
natural_cycle_id:
delivery_mode_by_step_at_start:
eligible_at / ready_at / started_at / delivered_at:
acceptance_status / accepted_at:
value_status / value_mature_at:
linked_job_ids:
exception_event_ids:
founder_active_minutes:
customer_active_minutes:
variable_cash_cost:
decision_as_of:

execution、acceptance、value、incident の状態と成熟時計は12 章に合わせる。delivered_at だけで accepted/value-confirmed にしない。契約上の検収と、業務価値の確認も分ける。

acceptance_status / value_status は service 成果の event または導出 snapshot であり、AI feature 側の値を手入力で複製しない。linked job_id から導く場合は、参照 event と集約規則を版管理する。一つの AI output が accepted でも、close pack 全体の契約検収や顧客価値が成立したとは限らない。AI を使わない service では、service_job_id 側に同じ意味の delivery-level event を持つ。

無償 sample、sales demo、内部 test、架空 fixture は service_job と同じ table に入れてもよいが、commercial_basis = nonpaid_* とし、paid cohort の分母から除外する理由と件数を表示する。無償 work の時間・現金費は CAC または実験費へ一度だけ戻す。

Workflow、step、時間、原価を版管理する

Workflow definition

workflow は「画面一覧」でなく、顧客が求める終状態までの手順である。

workflow_id:
workflow_version:
customer outcome:
start state / terminal state:
eligible event:
input contract:
output contract:
acceptance rule:
value confirmation rule / maturity:
ordered step_ids:
allowed delivery modes per step:
non-automatable decisions:
effective_from / superseded_at:

変更後の workflow で過去 job を上書きしない。service_job 開始時の version を固定し、途中変更は change request、再開始、または明示した migration として扱う。

Step definition と実行 event

StepDefinition
- step_id / version
- purpose / input / output
- actor role
- deterministic / probabilistic / human judgment
- acceptance oracle
- allowed tools and data class
- retry / fallback / stop condition
- next states

StepRunEvent
- service_job_id / step_id / attempt_id
- actor_side: founder / customer / system / external_provider
- delivery_mode
- queued_at / started_at / ended_at
- outcome / output_reference
- exception_event_id
- human_work_ids / provider_usage_ids
- source_version / tool_version / change_id

step を細かくしすぎて、計測時間が提供時間を超えないようにする。一人の判断を毎クリックへ分解せず、別 actor、別 acceptance、別 risk、別自動化候補になる境界で切る。

時間を三種類に分ける

active labor time
= 人が実際に操作、確認、修正、連絡した時間

queue / dependency wait
= provider、顧客承認、外部 system、予定時刻を待った時間

elapsed delivery time
= delivered_at - ready_at

• provider/founder active time は原価と容量へ入れる。
• customer active time は顧客 friction として別表示し、自社人件費へ足さない。
• queue wait は SLA/TTFV へ入れるが、active labor cost へ足さない。
• 同時に複数 job を batch 処理した時間は、事前の配賦規則で一度だけ分け、各 job へ全時間を複製しない。
• calendar elapsed が短くても founder active time が増えていれば、容量改善ではない。

human work の分類は12 章へ合わせる。

standard_delivery
planned_review
correction
support
incident
founder_rescue
customer_review

標準手順を実行する時間は standard_delivery、標準 offer に含めた確認は planned_review とし、独立価値と両立し得る。scope 外の変換、顧客固有仕様の手直し、毎回必要な隠れ作業を standard_delivery や planned_review へ移して rescue を消さない。商業活動側では business_activity_class = fulfillment とし、pilot/production 等は別の commercial_motion で表す。

原価を現金、創業者時間、顧客 friction に分ける

service_job_variable_cash_cost
= AI/API + storage + delivery + job-specific external labor
 + payment processing / chargeback operation fee

service_job_founder_economic_cost
= founder active minutes / 60 × [09章と同じ内部時間価値]

service_job_customer_friction
= customer active minutes と必要 role

job revenue が明示配賦できる場合だけ、次を出す。

service_job_fully_loaded_contribution
= allocated gross revenue - allocated credit/refund/discount principal
 - service_job_variable_cash_cost
 - service_job_founder_economic_cost

refund/credit の元本金額は contra-revenue として net revenue を一度だけ減らし、同じ額を variable cash cost にも入れない。決済手数料、chargeback fee、返金処理の外注費は cash cost だが、返金元本とは別 event・別 inclusion code にする。invoice、credit/refund、payment receipt、recognition/allocation rule を参照 ID で照合する。

配賦できない bundle では、job ごとに cost と value は出しても contribution を作らない。12 章の account-commercial-cycle と09 章で一度だけ計算する。

build、review、migration、再評価は productization investment として別にする。日常 job 原価へ一括で全額入れて一月だけ悪化させず、回収判断へ明示する。ただし会計上の費用認識を本章の管理配賦で決めない。

Scope envelope を offer と実運用の境界にする

scope envelope は、標準 service が受け取るもの、返すもの、含む人手、対象外を版管理した運用契約である。法的 agreement を置換せず、提案・SOW・注文・runbook・製品 UI が同じ境界を説明するために使う。11 章の商流テンプレートと対応させる。

scope_envelope_id / version:
対象 ICP / workflow / geography:
契約上の成果単位:
accepted input formats / size / quality:
customer prerequisites / due time:
standard output / acceptance rule:
included volume / natural cycle:
planned human review:
standard turnaround / support channel / support hours:
included exception handling:
explicit exclusions:
non-automatable decisions / required approver:
data classes / retention / deletion / export:
AI/provider use / region / training-use boundary:
standard price / setup / overage / additional work:
change request path:
effective_from / superseded_at:
agreement references:

Envelope の規則

1. 入力が envelope 外なら、黙って整形せず input_contract exception にする。
2. 顧客固有変更は、defect、標準改善、新 scope、別 SOW のどれかへ分類する。11 章の変更要求と同期する。
3. 標準価格で含む予定 review と、追加料金の作業を分ける。
4. 高損害判断、署名、外部送信、法的判断等の非自動化境界を marketing、UI、契約、runbook で一致させる。
5. envelope 変更は将来 job へ適用し、既存 agreement への適用は契約条件と同意を確認する。
6. 価格を下げる場合は、件数、support、turnaround、保存、review、入力支援の何を減らすか明示する。
7. 標準入力へ合わせる顧客作業も計測する。自社時間を顧客へ転嫁しただけなら、その friction を価値から引く。

良い envelope は全例外を拒否するものではない。既知の valid variation を標準経路へ含め、未知・危険・顧客固有だけを例外 queue へ送る。

Exception taxonomy は原因と処置を分ける

「例外 12 件」だけでは何を直すべきか分からない。各 exception に一つの primary cause と、一つ以上の treatment event を持たせる。

Cause class

Cause	定義	典型例	製品化上の含意
input_contract	必須項目、形式、期限、品質が envelope 外	列欠落、読めない PDF、遅延 upload	validation、顧客教育、scope/price
valid_standard_variation	正常業務に反復する既知の変種	日付・税区分・帳票版の許容差	rule/schema へ吸収候補
product_defect	約束した標準経路が仕様どおり動かない	誤集計、tenant scope、export 崩れ	defect 修正。追加料金にしない
model_or_rule_uncertainty	正常入力だが自動判定の確信・一致が不足	抽出候補が競合、照合差分が曖昧	planned review、eval、範囲縮小
external_dependency	provider/API/network/相手 system	timeout、rate limit、仕様変更	retry、fallback、SLA、依存撤退
customer_dependency	顧客の承認、担当、権限、回答待ち	approver 不在、基準未決	waiting と active time を分離
customer_specific_request	標準成果を超える一社固有要求	独自列、特別文面、専用連携	別 SOW、premium service、拒否
security_privacy_safety_legal	無権限、越境、機微データ、高損害判断等	誤 tenant、禁止用途、同意不明	STOP / escalation。平均で相殺しない
unknown	調査時点で原因を証明できない	再現不能、複数仮説	UNKNOWN のまま owner と期限を置く

Treatment class

auto_handled
planned_review
correction
customer_action_requested
support
founder_rescue
pause
stop_and_escalate
compensating_action
scope_change / separate_SOW

founder_rescue は原因ではなく処置である。たとえば input_contract × founder_rescue と product_defect × founder_rescue は、同じ時間でも次の行動が違う。

Exception event

exception_event_id:
service_job_id / step_id:
detected_at / resolved_at:
cause_class / cause_confidence:
normalized_fingerprint:
severity / maximum_credible_loss:
scope_status: in_scope / out_of_scope / disputed:
treatment_events:
founder_minutes / customer_minutes / cash_cost:
customer-visible impact:
linked incident_id / change_id / SOW:
recurrence_count_as_of:
owner / next action / due date:

同じ原因の表記揺れを normalized fingerprint で束ねるが、顧客データや秘密を fingerprint label に入れない。分類変更は旧値を上書きせず event として残す。

例外から導く判断

• 高頻度の valid_standard_variation は標準化候補。
• 高頻度の input_contract は UI 追加より先に offer、sample file、validation、導入を直す。
• product_defect は機能要望でなく品質 debt。
• customer_specific_request が一社だけ高頻度なら、その account の価格・SOW・適合を見直す。
• model_or_rule_uncertainty の planned review が減らないなら、自律性を上げず managed mode を維持する。
• security_privacy_safety_legal は頻度が低くても veto。ゼロ観測は安全の証明ではない。
• unknown を「その他」に閉じず、期限後も未解決なら promotion を UNKNOWN にする。

製品化候補は safety veto の後に順位付けする

候補単位

候補は「顧客 portal を作る」のような大きい feature でなく、観測可能な step または exception cause にする。

良い例:

• 標準 CSV の列・型・重複を upload 前に検証する。
• 同じ帳票版の正規化を内部 tool へ移す。
• 未承認・期限超過・版違いだけを exception queue へ出す。

悪い例:

• AI で全部自動化する。
• dashboard を作る。
• 顧客ごとの要望を全部設定化する。

先に通す veto

次のいずれかが active なら、経済 score を作らない。

Decision	条件	行動
STOP	無権限アクセス/送信、重大 privacy/security、安全・法令違反、禁止用途、封じ込め不能	対象処理を停止し、06 章と incident 手順へ escalation
PAUSE	active High、既知の remediation/approval 待ち、現 mode は維持できても新規 exposure が危険	実装・promotion を止め、解除証拠と期限を置く
UNKNOWN	データ利用権、acceptance oracle、責任者、rollback/compensation、代表 input、最大損失境界等の required evidence が欠損・stale・未成熟	gate を Unknown とし、新規は HOLD。安全運用の証拠まで不明なら action は PAUSE/REVERSE/STOP
NO-GO at maturity	同じ有償成果に反復しない、顧客価値と無関係、純削減時間が非正、維持費込みで回収不能、標準化不能	自動化しない、別 SOW/managed service/stop

高損害の最終判断、法定資格者の署名、採否・信用・医療・安全判断等は、件数と売上で veto を相殺しない。08 章のデータ・責任ゲートを維持する。

生き残った候補の evidence card

automation_candidate_id:
workflow_version / step_id / segment:
source service_job_ids / evidence window:
paid jobs x/n / independent accounts:
natural cycles covered:
baseline founder active minutes: median / max / total
baseline customer active minutes:
exception causes / severe events:
expected post-change founder/customer minutes:
expected new cash cost / maintenance / re-eval:
customer value mechanism:
acceptance oracle / negative cases:
manual fallback / rollback / compensation:
data rights / security / legal review:
low / base / high estimate:
decision: STOP / PAUSE / NO-GO / RANK / BUILD / HOLD
owner / expiry:

容量解放を先に計算する

job当たり純削減創業者分
= baseline founder active minutes
 - (post-change execution + review + correction
    + expected exception + support + incident minutes)

月間純容量解放
= mature eligible paid jobs/月 × job当たり純削減分
 - 月間 maintenance / re-eval / monitoring 分

baseline と post-change は同じ workflow、scope、segment、maturity で比較する。AI が速くても review、再試行、support が増えれば純削減は小さくなる。09 章の AI と Codex の純削減時間と同じ考え方を使う。

売上を同じ account-commercial-cycle へ帰属できる場合は、完全負荷後貢献の差を一度だけ使う。

月間完全負荷後貢献の改善
= post-change fully loaded contribution
 - baseline fully loaded contribution
= net revenue の差
 + 変動現金費の削減
 + 創業者時間費の削減

bundle 等で job へ売上を帰属できない場合は、貢献を作らず次の比較値だけを使う。

月間容量・現金比較値
= 月間純容量解放 / 60 × 内部時間価値
 + 観測根拠のある変動現金費削減

製品化投資
= build / review / migration / documentation / training 時間 × 内部時間価値
 + 現金支出

比較用回収月数
= 製品化投資 / 選択した一つの正の改善値

完全負荷後貢献の改善と、その内訳である時間費・現金費の改善を足さない。追加売上を含めるなら同じ cycle の net revenue 差として一度だけ入れる。分母が 0 以下なら回収月数を出さない。解放時間は現金でも売上でもない。営業、別の有償 job、休息、risk reduction へ実際に再配分して初めて事業価値になる。将来の売上を候補ごとに重複計上しない。

順位は一点 score より、次の順を使う。

1. active safety/privacy/security/legal veto がない。
2. 同じ有償成果と自然周期で反復する。
3. 複数 account または明示的に一社 premium service として再利用範囲が分かる。
4. acceptance oracle、manual fallback、観測がある。
5. 顧客 effort を増やさず、または増加を上回る価値が確認できる。
6. 純容量解放と fully loaded contribution の改善幅が大きい。
7. build、維持、provider 変更、再評価が小さく可逆である。
8. 次に重要な不確実性を安く減らせる。

Codex が短時間で作れそう、画面として見栄えがする、競合にある、という理由だけで順位を上げない。

Delivery mode の promotion と reversal

状態遷移

manual_bespoke
  ↔ managed_standard
      ↔ founder_internal
          ↔ customer_assisted
              ↔ customer_self_service

これは企業や製品全体の一方向 maturity model ではない。step、segment、data class ごとに前後できる。通常は一段ずつ進めるが、決定的で低 risk な標準 validation を managed_standard から限定 self-service へ出す等、途中を飛ばす場合は、飛ばした段階で得るはずだった入力、support、risk の証拠を別途示す。

共通の promotion record

promotion_decision_id:
scope: workflow_version / step / segment / data_class
from_mode / proposed_to_mode:
commercial motion / affected agreements:
evidence window / mature service_job_ids:
pre-frozen success / guardrail / veto:
value / acceptance / safety evidence:
founder and customer time evidence:
cash cost / fully loaded contribution:
exception distribution / unknowns:
onboarding / support / fallback:
linked candidate_id / change_id / release_id:
derived_gate_state: STOP / PAUSE / UNKNOWN / READY_TO_DECIDE
recorded_action: PROMOTE / LIMITED_CANARY / MAINTAIN / HOLD / REVERSE / PAUSE / STOP
decision owner / decided_at / expiry:
next observation maturity:

gate の導出順は次とする。

STOP > PAUSE > UNKNOWN > READY_TO_DECIDE

READY_TO_DECIDE は自動昇格でない。責任者は同じ evidence snapshot に対し、PROMOTE / LIMITED_CANARY / MAINTAIN / HOLD / REVERSE / PAUSE / STOP の一つを別 action event として記録する。UNKNOWN は gate state であり action ではない。PROMOTE と LIMITED_CANARY は全 required gate が肯定証拠を持つ場合だけ選べるが、証拠が揃っていても容量や戦略上の理由で MAINTAIN / HOLD / REVERSE / STOP を選べる。重大事故がないだけ、平均時間が下がっただけ、顧客が好意的なだけでは promotion しない。

derived gate と、現在 exposure 中の operational action を次のように組み合わせる。

Derived gate	新規・拡大前	既に exposure 中
STOP	開始しない	対象 effect を停止・contain し、安全な fallback または service 停止へ移す
PAUSE	canary / promotion を開始しない	新規受付・拡大を止め、影響する operation を pause または前 mode へ reverse する
UNKNOWN	HOLD。期限、owner、必要証拠を置く	expansion を凍結する。価値・経済等の非安全証拠だけが未成熟で、authorization、安全監視、fallback、rollback が fresh な場合に限り、期限付きの現 scope を維持できる
READY_TO_DECIDE	owner が限定 cohort と reversal を含む判断を記録	維持・拡大・逆戻りのいずれも選べる

authorization、data rights、重大安全 guardrail、監視、fallback、rollback の required evidence が stale/欠損なら、active exposure を UNKNOWN のまま継続しない。少なくとも PAUSE、必要なら REVERSE/STOP とする。価値や経済の観測待ちと、安全に運用できるか不明な状態を同じ Unknown にしない。

manual_bespoke → managed_standard

必要な証拠:

• 有効な非ゼロ料金契約内で、同じ outcome が反復した。
• 標準 input、output、acceptance、予定 review、対象外を書ける。
• 顧客固有 work と共通 step を分けられる。
• 高損害・責任境界を説明できる。
• 実時間と変動現金費を job ごとに記録できる。

一社の二回目は recurrence の証拠だが、cross-customer product の証拠ではない。複数顧客へ売る主張には、独立 account の証拠を別に求める。

managed_standard → founder_internal

必要な証拠:

• 頻出 step と baseline founder minutes がある。
• input/output contract と acceptance oracle が安定している。
• 代表例、boundary、失敗、禁止例の fixture を安全に作れる。
• manual fallback があり、内部 tool の誤りを顧客へ出す前に止められる。
• build、review、maintenance、再評価を含む純容量解放が正になる道筋がある。
• 13 章の risk tier と変更証拠を通す。

内部 tool は founder が最初の利用者になるため、顧客 onboarding を先に作らず、工程仮説を安く検証できる。一方、内部だから security、tenant、個人情報、backup を省いてよいわけではない。

founder_internal → customer_assisted

必要な証拠:

• 顧客が開始・upload・確認・承認すること自体に意味がある。
• 顧客へ見せる state、error、責任、support が定義されている。
• 顧客操作を含めても TTFV と value が悪化しない仮説がある。
• customer active minutes と必要 role を測れる。
• auth、authorization、tenant、audit、data deletion/export、billing/support が対象 risk に耐える。
• 標準 review と exception queue の owner、SLA、fallback がある。
• 既存顧客へ価格・scope・責任変更を黙って適用しない。

顧客が UI を希望した発言だけで作らない。実物で行うべき job、頻度、誰が操作し、誰が価値を判定するかを確認する。

customer_assisted → customer_self_service

必要な証拠:

• 複数の自然周期で repeat_value と independent_value を分けて確認した。
• 非標準 founder rescue なしで、標準 onboarding から成果まで進める。
• planned review、support、incident を含む p50 と tail の創業者時間が09 章の容量内である。
• 顧客 effort を含む net value が保たれ、単なる作業移転ではない。
• mature cohort の完全負荷後貢献が正で、返金・解約・support を隠していない。
• SLO、alert、backup/restore、課金、解約、export、削除、support、incident が運用可能である。
• 高 risk operation は10 章の委任昇格を別に通す。

independent_value は「創業者が一切働かない」ことではない。契約上予定した review や通常 support を除き、顧客固有 rescue なしで価値が成立したことを意味する。定義は workflow ごとに介入前に固定する。

Reversal trigger

次の一つでも発生したら、影響範囲を限定し、前の mode、manual fallback、または停止へ戻す。

• active な重大 security/privacy/safety/rights incident
• acceptance、value、on-time delivery の guardrail 未達
• founder rescue、support、correction の tail が容量上限を超える
• customer effort、誤操作、離脱が増え、net value が悪化する
• provider/model/tool/schema change で evidence が stale になる
• input variation が標準 contract を超え、未知例外が収束しない
• 完全負荷後貢献が 0 以下、または価格・scope で修正不能
• 契約、規約、データ利用条件、法令、顧客責任者が変わる
• rollback/compensation、監視、support を維持できない

delivery mode reversal と code rollback を混ぜない。たとえば UI を残したまま「受付のみ、処理は managed」に戻すこともある。逆に code を旧版へ戻しても、顧客への約束、請求、送信済み effect、データ移行は自動的に戻らない。13 章の rollbackへ接続する。

Delivery mode の逆戻りは製品全体の maintenance、統合、売却、sunset と同義ではない。製品単位の資源配分と終了責任は 15 章で別に判断する。

Codex productization loop

Codex は「何を製品化するか」を決める証拠ではなく、選んだ step を安全に実装・検証する手段である。

1. 有償 evidence から candidate を作る

• 対象 service_job_id、期間、scope version、例外、baseline time を固定する。
• paid、nonpaid、test、synthetic を分ける。
• 一社固有要求を cross-customer need と呼ばない。
• 顧客価値との接続と、実装しない反証条件を書く。

2. 顧客情報を安全な specification へ変換する

実顧客の prompt、CSV、文書、秘密、個人情報、契約成果物を Git や共有 task へ貼らない。次へ変換する。

• schema と field classification
• 最小化・匿名化した edge case
• 権利確認済みの redacted sample
• 同じ failure property を持つ fully synthetic fixture
• expected output、禁止 output、acceptance oracle
• data provenance と fixture version

顧客データを provider 改善、cross-tenant 学習、eval へ再利用できるかは、契約、利用目的、privacy notice、provider 条件を06 章で確認する。許諾がないことを「匿名化予定」で代替しない。

3. Task brief を商業 evidence へ結ぶ

TASK-BRIEF.mdへ次を渡す。

automation_candidate_id:
source service_job_ids / evidence cutoff:
workflow / step / scope version:
customer outcome and non-goals:
baseline founder/customer minutes:
expected capacity release and maintenance budget:
input/output contract:
acceptance criteria IDs:
negative / boundary / forbidden cases:
manual fallback / reversal trigger:
maximum credible loss:
data classes and fixture provenance:
post-release value/time maturity:

高影響な acceptance、最大損失、契約約束、risk acceptance を Codex に推測させない。

4. Internal-first を既定にする

顧客 UI、新しい auth、課金、通知を同時に作ると、workflow 仮説と product surface の失敗を分けられない。まず founder-only tool、dry-run、read-only、shadow output で検証し、顧客 effect は人が承認する。

ただし次は internal-only の理由で省かない。

• tenant/data boundary
• input validation と output trace
• timeout、retry、idempotency
• logging の privacy 境界
• backup、manual fallback、rollback
• model/prompt/tool/schema version

5. change_id で実装から観測まで結ぶ

automation_candidate_id
→ change_id
→ exact commit / artifact / config versions
→ release_id / exposure segment
→ workflow_version
→ post-change service_job_ids
→ promotion / hold / reversal decision

実装、review、release の証拠は13 章、AI quality/cost/value は12 章、agent operation の権限は10 章を使う。Chapter 14 用の別 CI や別 AI ledger を作らない。

6. 同じ contract で事後観測する

変更前後で次を比較する。

• eligible paid service jobs と scope mix
• acceptance / value / incident maturity
• founder execution、planned review、correction、rescue、support
• customer active minutes と待ち時間
• provider retry/fallback、variable cash cost
• exception cause と最大損失
• on-time delivery と TTFV
• account-cycle fully loaded contribution

単純な before/after は、顧客、input、量、季節、学習効果が違えば因果にならない。小標本では全 job を読み、scope/version を揃え、結果を「関連」として扱う。改善が不明なら UNKNOWN/HOLD とし、好都合な一件だけで promotion しない。

7. 安定した規則だけを再利用する

反復して有効だった command、invariant、test を root/nested AGENTS.md、skill、CI、runbook へ移す。作業途中の顧客固有 instruction、秘密、live ID を永続規則へ入れない。automation は手順が安定してから schedule する。13 章の責任分離を維持する。

Pricing と customer migration を同時に設計する

Delivery mode 別の価格を「安い順」と決めない

価格は顧客価値、責任、対象範囲、支払意思から決める。自社時間が減ったから同額だけ値下げする義務はない。一方、managed service と同じ価格で顧客へ作業を移すなら、追加の速度、制御、可視性、利用枠等の価値を説明する。

Offer	含めやすいもの	価格構成例	注意
Managed	provider 実行、予定 review、標準成果、SLA	setup + 月額/成果単位 + overage	rescue を無制限に含めない
Assisted	顧客 upload/承認、provider exception review	setup/migration + 月額/usage + support tier	customer effort と権限を明示
Self-service	標準 onboarding、利用枠、通常 support	月額/年額 + value/usage allowance	低価格で必要顧客数を増やしすぎない
Premium custom	専用入力、連携、SLA、個別成果	別 SOW + 保守/変更料金	標準 product demand と分ける

setup fee で扱う候補:

• schema/CSV mapping
• data migration と quality review
• approver、role、tenant、policy 設定
• training、parallel run、acceptance
• 顧客固有 integration の初期作業

月額へ埋める前に、何が一回、何が反復、何が顧客固有かを分ける。09 章の導入後初期貢献と月次貢献へ一度だけ入れる。

Migration state を契約・delivery mode と分ける

Not-evaluated
→ Eligible
→ Offered
→ Accepted または Declined
→ Start-ready
→ Parallel-run
→ Cutover
→ Stabilizing
→ Stable または Reverted

• Offered は同意でも amendment でもない。
• Accepted でも data、権限、training がなければ Start-ready ではない。
• Cutover しても価値・incident 観測が成熟するまで Stable ではない。
• Declined は churn ではない。managed offer を継続する場合がある。
• Reverted しても契約、価格、請求、データ、外部 effect が自動的に旧状態へ戻るとは限らない。

Migration plan

migration_id / account_id:
from offer/version/mode:
to offer/version/mode:
customer value and reason:
scope / responsibility / price difference:
customer and provider work:
data mapping / retention / deletion / export:
security / legal / agreement / amendment:
parallel period and acceptance:
cutover / fallback / reversion:
billing effective date / proration / credit:
support / training / communication:
success / guardrail / maturity:
owner / decision dates:

既存顧客の価格・機能・責任を一方的に変えられるかは、契約、定型約款、通知、消費者/B2B 区分等で変わる。06 章と11 章を確認する。本章は変更権限を与えない。

Migration economics

移行後 account-cycle fully loaded contribution
= 移行後 net revenue
 - variable cash cost
 - founder delivery/support/rescue time × internal value

顧客側は、単位の違う値を直接引かず、少なくとも次を別々に比較する。

outcome: 金額化できる業務価値、または同じ outcome metric
effort: migration / operation / review の分数 × 必要 role
quality: acceptance / correction / critical failure
time: TTFV / elapsed / deadline miss
risk: 重大度別件数と maximum credible loss

金額換算する場合だけ、介入前に固定した顧客 role 別時間価値と、根拠のある expected loss を使い、outcome monetary value - effort monetary cost - expected loss とする。円、分、件数、risk score をそのまま加減しない。創業者時間が減っても値下げがそれを上回れば貢献は悪化する。逆に価格が上がっても顧客 effort と risk が下がり、価値が増えるなら成立し得る。片方だけを最適化しない。

Weekly productization review

週次 review は backlog grooming ではない。paid job、例外、時間、価値、商流、変更証拠から、次に扱う候補を一つ決める。

事前入力

• 今週 maturity を迎えた paid / nonpaid service jobs
• scope、workflow、delivery mode、segment の版
• acceptance、value、incident、customer feedback
• step time、human work、customer effort、provider/cash cost
• exception cause、treatment、最大損失、未解決 unknown
• agreement、invoice、cash、change request、migration
• candidate、change_id、release、stale evidence
• 09 章の次週容量と 13 週現金

Dashboard

面	最小表示	最初の問い
Commercial	paid jobs、agreement、請求、実入金、repeat/renewal	無償作業や未収を需要と数えていないか
Value	eligible、delivered、accepted、value-confirmed、maturity	成果が業務で使われたか
Delivery	on-time、elapsed、founder/customer active time	待ちと作業、顧客側 friction を分けたか
Scope	in-envelope / out-of-envelope、version	無料の範囲拡大が起きたか
Exceptions	cause 別 x/n、severity、rescue、unknown	直すべき共通原因か、一社固有か
Economics	variable cash、founder cost、account-cycle contribution	創業者無償労働で粗利を作っていないか
Productization	candidate、純容量、投資、gate、evidence expiry	何を作るかより何をまだ知らないか
Change	change_id、risk、decision、release、observation maturity	実装完了を価値証拠にしていないか
Migration	eligible/offered/parallel/stable/reverted	顧客価値・価格・責任が一致するか

率だけでなく x/n、対象 job、最大値、原文を表示する。小標本の p90 は一件の順位を示すだけになり得るため、job 数と実値を併記する。denominator = 0、未成熟、欠損、stale evidence は Green にせず UNKNOWN とする。

60 分の週次運営

1. 0〜10 分 — Red/Unknown: 重大事故、権利、未収、stale evidence、期限切れを確認する。
2. 10〜20 分 — Paid value: 新しい支払、受入、価値、自然周期の反復を job 単位で読む。
3. 20〜35 分 — Delivery: step time、scope 外、exception、founder rescue、customer effort を確認する。
4. 35〜45 分 — Economics: 現金費、完全負荷後貢献、容量、13 週への影響を確認する。
5. 45〜55 分 — Mode/migration: promotion、hold、reversal、別 SOW の gate を判定する。
6. 55〜60 分 — 一つの行動: candidate 一件、顧客確認一件、scope 修正一件等から最優先を一つ選ぶ。

出力:

RED / UNKNOWN:
今週成熟した paid evidence:
最大の scope leak / exception cause:
founder/customer capacity impact:
mode decision:
priority action:
owner / due / stop condition:
次の maturity date:

重大 veto は「今週の一つ」に絞らず全件を封じ込める。それ以外の改善作業は同時に増やさない。

コピー用の最小書式

以下は会話や初回 review で使う短縮版である。N/A、evidence maturity、append-only event、fully-loaded cash/time、顧客移行、週次 review、Codex handoff まで運用する場合は、コピー用 8 書式を使う。

1. Paid service job

Service_job_id:
Account / agreement / invoice line:
Commercial basis / revenue allocation:
Workflow / scope version / natural cycle:
Eligible / ready / delivered:
Input / output / acceptance:
Delivery mode by step:
Founder work by class:
Customer work:
Variable cash cost:
Exceptions:
Value / incident maturity:
Decision and next cycle:

2. Scope envelope

Envelope version / effective date:
ICP / outcome / unit:
Accepted inputs and prerequisites:
Standard output and acceptance:
Included volume / review / turnaround / support:
Included valid variations:
Excluded / separate-SOW work:
Human approval / non-automatable decisions:
Data / AI / retention / deletion / export:
Price / setup / overage:
Change and termination path:

3. Exception record

Exception_id / service_job / step:
Cause / confidence / fingerprint:
Severity / maximum loss:
In-scope / out-of-scope / disputed:
Treatment / time / cash / customer impact:
Incident / candidate / change / SOW link:
Owner / due / resolution:

4. Productization candidate

Candidate_id / step / segment:
Paid source jobs / cycles / accounts:
Baseline founder and customer time:
Exception and safety evidence:
Proposed mode / expected time and cost:
Acceptance / fallback / reversal:
Investment / maintenance / capacity gain:
STOP / PAUSE / NO-GO gate:
Decision / expiry / owner:

5. Promotion or reversal

Decision_id / exact scope:
From / to mode:
Pre-frozen evidence requirements:
Observed x/n and maturity:
Value / quality / risk / economics / capacity:
Unknowns and stale evidence:
recorded_action — PROMOTE / LIMITED_CANARY / MAINTAIN / HOLD / REVERSE / PAUSE / STOP:
Affected agreement / migration / change / release:
Next observation date:

6. Customer migration

Migration_id / account:
Old vs new offer / scope / price / responsibility:
Customer and provider effort:
Agreement / billing / data / security conditions:
Parallel / acceptance / cutover / fallback:
Value and capacity guardrails:
State / owner / dates:

完全架空例 — 広告制作会社の月次 close pack

以下の会社、顧客、価格、件数、原価、時間、error、判断、日付はすべて説明用の架空値である。市場価格、benchmark、RevenueCat・OpenAI・Anthropic・中小企業白書の実測値ではない。実顧客データ、個人情報、広告実績を含まない。

1. Offer と paid unit

架空サービス CloseFlow は、広告制作会社が downstream client ごとに行う月次 close pack を managed service で提供する。

架空 account: Aster Agency / Birch Studio / Cedar Works
agreement: production、月額 180,000円 / 社
price basis: 税抜
included: downstream client 10社分 / 月
service_job: downstream client 1社 × 1月の close pack
入力: 固定 template の広告 CSV、請求 CSV、前月 close record
出力: 差分一覧、未承認一覧、根拠 link 付き close pack
予定 review: 金額差分と未承認を創業者が確認
対象外: 税務判断、広告成果の因果評価、顧客への自動送信、独自列の無制限 mapping

3 account × 10 pack なので、月間 paid service job は 30 件である。月額 bundle のため個別 job revenue を作らず、account-commercial-cycle で貢献を計算する。

この完全架空 cycle では、3 社それぞれに税抜 180,000 円を請求し、evidence cutoff までに 3 件とも現金入金済み、credit/refund は 0 observed と置く。そのため契約価格、invoice 合計、cash receipt、管理上この cycle へ帰属する net revenue が偶然すべて 540,000 円になる。契約価格だけから売上・入金を推定していない。未収があれば invoice、receivable、cash を別表示する。

2. Baseline managed workflow

架空の初月 30 job を、同じ scope_envelope_version = SE-01 で提供した。

Step	Delivery mode	Founder active 分/job	Customer 分/job	主な exception
input receipt/check	managed_standard	12	2	列欠落、遅延
CSV normalization	managed_standard	20	0	日付・通貨表記
discrepancy review	managed_standard	25	0	根拠不一致
close pack assembly	managed_standard	15	0	template 版違い
delivery/support	managed_standard	8	1	approver 不在
合計		80	3

架空の内部時間価値は 6,000 円/時、変動現金費は 350 円/job とする。以下の売上・費用比較はすべて JPY・税抜で揃え、消費税の預り・支払・控除はこの管理比較に含めない。

契約価格 / invoice / cash receipt / attributable net revenue
= 180,000円 × 3 account
= 540,000円

変動現金費
= 350円 × 30 job
= 10,500円

創業者 active time
= 80分 × 30 job
= 2,400分 = 40時間

創業者時間費
= 40時間 × 6,000円
= 240,000円

月次完全負荷後貢献
= 540,000 - 10,500 - 240,000
= 289,500円

これは税引後所得、会計利益、銀行残高ではない。獲得、初期導入、固定費、税・社保、事故予備は別である。

3. Exception の分類

30 job で次を記録した。

Cause	Event 件数	Affected jobs	Treatment	Founder 分	判断
valid_standard_variation 日付表記	8	8/30	founder_rescue（manual normalization）	96	現 runbook では未吸収の非計画介入。共通 rule 候補
input_contract 必須列欠落	3	3/30	customer_action_requested + founder_rescue	75	sample/validation を改善
product_defect 旧 template 参照	1	1/30	correction	40	defect 修正、追加請求なし
customer_specific_request 独自列	2	2/30	scope_change / separate_SOW	90	標準 product backlog へ直結しない
customer_dependency approver 遅延	2	2/30	support（wait + reminder）	12	elapsed と active を分離
security_privacy_safety_legal	0 observed	0/30 observed	N/A	0	安全の証明ではない

同じ job に複数 event があるため、件数は 30 へ合計しない。原因件数と affected jobs を別に表示する。 表の Founder 分は baseline の 2,400 分に含まれる treatment 時間であり、追加時間ではない。一分を一つの human-work class へだけ配賦し、exception 集計を workflow 時間へ再加算しない。

4. Candidate ranking

3 候補を比較した。

Candidate A — CSV normalization の founder internal tool

source: 30 paid jobs、3 independent accounts、同一月
baseline: 20分/job
expected after: 6分/job
gross saving: 14分 × 30 = 420分 = 7時間/月
maintenance/re-eval: 90分/月
net capacity release: 5.5時間/月
internal economic value: 5.5 × 6,000 = 33,000円/月
additional variable cash cost: 50円 × 30 = 1,500円/月
expected comparison value: 33,000 - 1,500 = 31,500円/月
build/review/migration: 18時間 × 6,000 + 現金12,000 = 120,000円
comparison payback: 120,000 / 31,500 = 約3.8か月

input/output が決定的で、顧客へ提示する前に人が確認でき、manual fallback がある。R1/R2 trigger を13 章で確認する条件付き BUILD とした。

Candidate B — AI に close 理由を自由記述させる

顧客が何を「正しい説明」とするか、根拠引用、禁止推論、material correction の baseline がない。価値はあり得るが acceptance oracle と eval set が不足するため PAUSE。実装速度を理由に Candidate A より上へ置かない。

Candidate C — 完成 pack を顧客へ自動送信する

現在の agreement は人の承認後送信を約束し、誤宛先・誤添付を送信後に取り消せない。source-to-sink、authorization、approval payload、取消/補償、shadow/canary が未整備なので safety PAUSE とし、経済 score を付けない。将来検討する場合も10 章の Level 3 gate を別に通す。

5. Codex change と内部 tool の観測

Candidate A を SQLite companion と共通の automation_candidate_id = CAND-RECON、change_id = CHG-20260801-closeflow-normalization へ結んだ。fixture は実顧客 CSV でなく、同じ列欠落、日付、通貨、重複 property を持つ fully synthetic file とした。v0.8 の実行可能 reference app はこの ID を使い、架空の paid job 数値を実証結果へ読み替えない。

Task の受入条件例:

AC-01: 許可した3種類の日付表記を同じ ISO date へ変換する。
AC-02: 必須列欠落は output を作らず、列名と修正方法を返す。
AC-03: 不明な通貨は推測せず review queue へ送る。
AC-04: 同じ入力と version は同じ正規化結果を返す。
AC-05: original row reference を全 output に残す。
AC-06: tenant をまたぐ file/result access を拒否する。

架空の翌月 30 job では、平均 founder time が 80 分から 66 分へ下がり、tool の maintenance/re-eval が月 90 分、変動現金費が 400 円/job になったとする。この翌月 cycle も税抜 invoice 540,000 円、evidence cutoff までの cash receipt 540,000 円、credit/refund 0 observed、attributable net revenue 540,000 円と別 event で確認済みと置く。

創業者 time
= 66分 × 30 + 90分 maintenance
= 2,070分 = 34.5時間

変動現金費
= 400円 × 30
= 12,000円

完全負荷後貢献
= 540,000 - 12,000 - 34.5 × 6,000
= 321,000円

baseline比の比較改善
= 321,000 - 289,500
= 31,500円/月

観測値が続く場合の比較回収
= 120,000 / 31,500
= 約3.8か月

解放した 5.5 時間はまだ現金売上ではない。次の営業、別 paid job、休息、品質改善へ再配分した事実を別に記録する。30 job は一月だけなので、季節・input mix・学習効果を除いた因果推定でもない。

決定:

• CSV normalization step は managed_standard → founder_internal に限定 promotion。
• service 全体は managed offer のまま。
• Candidate B/C は PAUSE。
• model、schema、tool version が変われば evidence を stale にし、再評価する。

6. Assisted offer の価格と migration canary

Aster Agency だけが、自社で upload と承認状態を見たいと要望した。発言だけで全顧客へ UI を作らず、次の架空 offer を比較した。

Managed SE-01:
- 180,000円/月、10 pack
- founder time 11.5時間/account-month
  （66分 × 10 job + 共通 maintenance/re-eval 90分の3社均等配賦30分）
- customer active time 0.5時間（3分 × 10 job）
- cash cost 4,000円
- fully loaded contribution 107,000円

Assisted SE-02価格案:
- 140,000円/月、標準CSVのみ、10 pack
- 顧客がupload・一次確認
- founderはexception reviewと最終pack確認

一 natural cycle の parallel run で、架空の運用観測は次だった。この期間の契約・請求・入金は Managed SE-01 の 180,000 円のままであり、140,000 円は未提示・未合意・未請求・未入金の比較案である。5.2 時間と 4,000 円は新経路だけの定常運用候補を別 timer/cost event で測った値とする。旧経路との shadow 照合 2.0 時間、追加現金 0 円は one-time migration investment として別記し、定常価格 parity へ混ぜない。

one-time migration investment
= 2.0時間 × 6,000円 + 0円
= 12,000円

steady-state founder capacity release / assisted account
= 11.5 - 5.2
= 6.3時間/account-month

1 assisted + 2 managed の steady-state founder time
= 5.2 + 11.5 × 2
= 28.2時間/月

founder time: 5.2時間（当該 offer に配賦した maintenance/re-eval と mapping exception 2件の処置を含む）
customer active time: 1.3時間
cash cost: 4,000円
critical incident: 0 observed
customer-specific mapping exception: 2件
assisted価格案を置いた場合の比較上の fully loaded contribution:
140,000 - 4,000 - 5.2 × 6,000 = 104,800円

104,800 円は parallel run の実現売上・実現貢献ではない。実測した時間・現金費に未合意の価格案を組み合わせた scenario projection であり、商業 event としては記録しない。

Managed の 107,000 円を維持する比較上の最低価格は次である。

107,000 + 4,000 + 5.2 × 6,000 = 142,200円

140,000 円案は、創業者時間を減らしても価格低下が大きく、完全負荷後貢献を 2,200 円悪化させる。さらに一 account・一周期で、customer effort は Managed の 0.5 時間から 1.3 時間へ 0.8 時間増え、mapping exception が 2 件ある。

決定:

• Aster だけ LIMITED_CANARY / customer_assisted を継続し、self-service へ進めない。
• 比較上の下限 142,200 円を上回る価格案（この例では 150,000 円）を再検証するか、support/scope を狭める。
• 二つの独立 account と複数自然周期という、この架空案件で事前に置いた evidence gate までは全体 promotion しない。
• Birch と Cedar は managed offer を維持し、移行辞退を churn と数えない。
• mapping exception が標準変種か一社固有かを次周期で分類する。

ここでの「二 account」「複数周期」「150,000 円」は説明用の案件内ルールであり、一般 benchmark ではない。実案件では価値周期、損害、価格、標本、容量に応じ、観測前に gate を凍結する。

7. 週次 review の最終出力

RED:
- active 0。0 observed は安全の証明ではない。

UNKNOWN / PAUSE:
- AI説明のacceptance oracle
- 自動送信のauthorization/compensation
- assisted modeのcross-account repeatability

成熟したcommercial evidence:
- managed 60 jobs（2か月、3 account）

operational mode evidence under managed agreement:
- assisted parallel 10 jobs（1周期、1 account）
- paid assisted offer / assisted price acceptance: 0。Managed契約のpaid jobを、新価格の支払証拠へ読み替えない

mode decision:
- normalization step: founder_internal 維持
- Aster upload/approval: customer_assisted canary
- service全体: managed_standard
- self-service: HOLD

priority action:
- mapping exception 2件を標準変種/顧客固有へ分類し、SE-02と価格案を更新

stop condition:
- tenant越境、誤送信、根拠なし金額変更、またはmanual fallback不能

この例の成功は「SaaS 化」ではない。有償成果の一工程で創業者容量を減らし、顧客へ移す工程は価格・顧客負担・例外の証拠が足りないため止めた、という判断の再現である。

90 分で最初の productization review を作る

0〜15 分 — 一つの paid unit を固定

• 一つの agreement と自然周期を選ぶ。
• service_job_id の成果、input、output、acceptance を定義する。
• unpaid、demo、test、synthetic を分ける。

15〜30 分 — Workflow と step

• 実際の手順を 5〜10 step にする。
• actor、mode、input/output、stop を書く。
• 現在の scope envelope version を置く。

30〜45 分 — 時間と原価

• 直近 job の founder/customer active time、wait、cash cost を入れる。
• planned review と rescue を分ける。
• bundle revenue は無理に job 配賦しない。

45〜60 分 — Exception

• 直近の例外を cause と treatment に分ける。
• safety/privacy/security/legal を先に確認する。
• 高頻度と最大損失を別に見る。

60〜75 分 — Candidate

• veto を通った一 step だけ選ぶ。
• baseline、expected time、maintenance、fallback を書く。
• source service_job_id と evidence expiry を付ける。

75〜90 分 — Decision

• gate とは別に PROMOTE / LIMITED_CANARY / MAINTAIN / HOLD / REVERSE / PAUSE / STOP を一つ選ぶ。
• Codex task にする場合は candidate ID と change ID を発行する。
• 次の maturity、owner、stop condition を決める。

不足データを推測で埋めない。最初の成果物は dashboard ではなく、一つの paid unit、一つの scope、一つの候補、一つの判断である。

表計算や内部ツールへ移す前に粒度と不変条件を試す場合は、fully synthetic data だけを含む SQLite companionを disposable database で実行する。これは実契約、顧客価値、一般的な threshold の証拠ではない。

根拠と限界

• RevenueCat 2026 は同社基盤を使う subscription app の観測であり、日本 B2B Web SaaS、invoice 契約、account renewal、サービス事業へ retention や売上分布を外挿しない。
• 中小企業白書の数値は特定調査・設問への回答で、AI 導入支援への支払意思、個別業界の需要、因果効果を示さない。
• OpenAI と Anthropic の report は各 provider の顧客・traffic・分類・survey に依存し、導入量を利益や顧客価値と同一視しない。
• 外部四資料のどれも、「サービス先行 → 内部 tool → self-service」が他の順序より高い成功率を持つと検証していない。本章の順序は、実装供給が増える中で支払・workflow・例外を先に反証するための戦略的推論である。
• 本章の mode、件数、価格、回収月数、promotion gate は市場 benchmark ではない。案件ごとに介入前に定義し、少数標本では x/n と原事例を読む。
• founder time は現金費用でない場合がある。完全負荷後貢献は管理上の比較であり、会計利益、課税所得、手取り、銀行残高を置換しない。
• 解放時間は自動的に売上へ変わらない。実際の再配分、追加 paid capacity、休息、risk reduction を別に観測する。
• 前後比較は scope、顧客、input mix、季節、学習、価格、model が変われば因果にならない。必要なら比較可能な cohort や段階導入を設計する。
• 顧客固有データ、評価、correction を cross-customer product 改善へ使う権利は自動的に得られない。契約、利用目的、最小化、provider 条件を確認する。
• productization は self-service 化と同義ではない。高価値で標準化された managed service、内部 tool 付き service、premium custom service を意図的な終着点にできる。
• AI/model/provider、法令、価格、契約、顧客責任は変わる。release と販売の直前に一次情報と実契約を再確認し、evidence expiry を置く。

最終判断は「どこまで自動化できるか」ではない。どの有償成果を、誰の負担と責任で、反復可能な品質・原価・容量にできるかである。