事業計画書：零細アナログ企業向けAI業務改善支援事業

作成日：2026-08-11 本書はPhase 0（意思決定アジェンダ整理）、Phase 1（リサーチ）、Phase 2（設計）の成果物を統合して作成した。新しい事実・数字を新規に作り出すことはせず、decisions/・research/・design/配下の各文書に既に記録された内容を、事業計画書として読みやすい形に再構成している。

記法ルール：本書全体を通じて、以下のラベルを維持する。

【事実】出典があり検証済み（URLと確認日は元文書を参照）

【推定】事実からの推論。根拠を明示

【仮説】未検証。検証方法とセットで記載

【要確認】依頼者への確認が必要、または未決事項

未決事項について：決まっていないことは「未決」と明記し、埋めるための作文はしていない。特に3年収支（第9章）と撤退基準（第12章）は、依頼者の最終決定を要する事項として扱う。

参照した元文書：fde-ai-jigyo-brief.md（依頼書）、decisions/00-agenda.md（Phase 0確定事項）、research/配下（R1〜R5、D7、interview-guide）、design/配下（S1〜S6、いずれも2026-08-11付で依頼者確認を経た最新版）

エグゼクティブサマリー
事業概要とポジショニング
市場と顧客（ターゲット業種の定義と根拠）
提供価値とサービス設計（3ステップの具体化）
価格・契約設計
顧客獲得戦略（チャネル別）
デリバリー体制とオペレーション設計
技術アーキテクチャと横展開設計
収支計画（3年）とKPI
リスクと対応方針
M&A構想との統合シナリオ
マイルストーンと撤退基準

1. エグゼクティブサマリー

本章は以下のファイルを参照して作成した：decisions/00-agenda.md、research/R1-competitors.md、research/R2-industries.md、design/S1-service.md、design/S2-pricing.md、design/S3-financials.md

1.1 事業の概要

本事業は、日本の零細アナログ企業（紙・Excel・LINEで業務が完結している、ITリテラシーの低い小規模事業者）を対象に、「業務棚卸し」→「情報整理」→「アプリケーション構築」の3ステップを一気通貫で提供する業務改善支援事業である。

提供モデルは、Palantir社のForward Deployed Engineer（FDE）的アプローチ、すなわち「プロダクトを売るのではなく人が客先に入り込み、その場で作る」という発想を出発点としているが、Phase 0の意思決定検討を経て、対面同席観察（初回・業務棚卸し時）とリモートPC作業ログ観察・改善（契約後の継続支援時）を組み合わせたハイブリッドモデルに修正されている（転換の経緯は第2章で詳述する）。

1.2 誰に提供するか

対象は東京・大阪の2拠点を日帰り圏内とする零細アナログ企業である。ブリーフ記載の5業種（賃貸管理会社・税理士社労士事務所・建設設備下請け・運送軽貨物・製造下請け）と、依頼者が実務経験を持つ5業種（商社系・代理店系・Web制作系・出版系・イベント系）の計10業種を横並びで調査した結果、現時点で最も有力な候補として税理士・社労士事務所とイベント系が浮上している（詳細は第3章）。前者は承継ニーズの密度・アナログ度の一次データが最も充実しており、後者は依頼者の実務経験が直接活きる唯一の業種である。

1.3 いくらで提供するか

価格は単一プラン（初期費用50万円＋月額10万円）である。稼働上限は契約上月8時間（社内の実行目標は7時間）とし、超過分は自社の基本単価と同一の時間単価（約12,500円/時）で追加請求する。最低契約期間は6ヶ月。契約終了時には成果物の所有権を顧客に譲渡し、自社の保守義務は終了（凍結）する（詳細は第5章）。

1.4 なぜ勝てるか

競合18社を対象にしたR-1のポジショニングマップ調査によれば、「業務棚卸し→アプリ構築」までを月10万円台という低〜中価格帯で一気通貫提供する事業者は、確認できた範囲では事実上存在しない。市場の多くの事業者は「価格が上がるほど提供の濃度（アドバイザリ寄り⇔実装・常駐寄り）も上がる」という比例関係にあるのに対し、本事業が狙うポジション（低価格×高濃度）はこの比例関係から外れた空白地帯にある。これは差別化の機会であると同時に、「なぜ他社より安く濃いサービスが可能なのか」という原価構造の説明責任を伴うものであり、本書全体でその設計を具体化する。

加えて、D-7の顧客課題深堀り調査では、複数の独立した公的統計（IPA「DX動向2024」、東京商工会議所調査）が「知識・情報不足」「旗振り役の不在」を予算不足以上に支配的な非着手理由として示しており、外部の伴走者が「代理の推進役」として入り込む本事業のモデルは、この構造的課題に直接対応する可能性が高い（第3章）。

1.5 事業の位置づけ

本事業はdecisions/00-agenda.mdのD-1決定に基づき、(a) 単体で成立させるストック型の支援事業として位置づけられる。事業構想の当初案にあったM&A（事業承継）構想との統合は、依頼者の明示的な判断により今回のスコープ外とされ、統合設計は行わない。この位置づけにより、業種の絞り込みや技術スタックの標準化といった横展開設計が事業の成否を直接左右する構造になっている。

1.6 実施体制

依頼者含め3名体制（東京拠点：依頼者、大阪拠点：既に常駐する共同事業者、他1名）で稼働する。3名は「全員営業兼作業者」として同一役割を担う想定である。ただし収支計画は、役割未定の人員をキャパシティに単純加算しない方針のもと、依頼者1名・週30時間（月120時間）をベースケースとして設計されており、3名同一役割モデルによる拡張シナリオは【仮説】として別枠で扱われている（詳細は第7章）。

1.7 収支の見通し（重要な留保）

保守シナリオでは、12ヶ月累計の単純差引が約50〜130万円にとどまり、依頼者の労働時間（週30時間×12ヶ月）に対する実質時給換算では非常に低い水準になる可能性が高い。依頼者は「生活費は他事業の収入で当面カバーできる」と回答しており、本事業単体の収益不足が直ちに生活を脅かすものではないことは確認済みである。一方で「事業の黒字化は必須」との回答もあり、「生活費は他事業でカバーしつつ、本事業自体は独立採算の黒字化を中期目標とする」という位置づけで整理している（詳細は第9章）。

また、契約社数が月1社ペースで安定的に伸びる「強気シナリオ」は、依頼者1人体制での同時並行対応上限（WIP上限2社）と数学的に矛盾しており、事業として現実的な成長曲線ではないことが判明している。事業を成長させるには、3名体制の実質稼働化が早期の課題になる（第7章・第9章）。

1.8 未決事項（詳細は各章末尾）

事業計画の骨格は固まっているが、以下は本書執筆時点で未決のまま残っている。詳細は該当章に記載する。

稼働上限8時間（バッファ込み）の妥当性は実運用開始後に最終確認する（第5章）
契約終了時の移設作業・顧客独自環境構築代行のオプション料金は方向性のみ確定し、具体額は未確定（第5章）
1社あたり工数（初期40時間・継続7時間/月）はあくまで仮置きであり、最初の2〜3社を工数実測のパイロットと位置づけている（第4章・第7章・第9章）
WIP上限2社を超える引き合いへの具体的な断り方・待たせ方の運用は方向性のみ確定し、細部は営業実務の中で調整する（第6章）
2名（特に大阪拠点の共同事業者）の具体的な稼働開始タイミング、報酬体系の固定分・歩合分の比率（第7章）
撤退基準（何ヶ月で何社取れなければ撤退するか、資金基準、撤退の定義）は依頼者の最終決定が必要な未決事項として残る（第12章）

2. 事業概要とポジショニング

本章は以下のファイルを参照して作成した：fde-ai-jigyo-brief.md、decisions/00-agenda.md、research/R1-competitors.md、research/R5-fde-cases.md

2.1 3ステップモデルの全体像

本事業が提供する価値は、以下の3ステップに整理される。

業務棚卸し：現場の業務を可視化・構造化する
改善のための社内情報整理：散在した情報を使える形に集約する
アプリケーション層の作成：業務改善ツールを構築する

この3ステップは、低ITリテラシー層の経営者・担当者が自分の業務を言語化できないという前提（ブリーフ1.6節）に立ち、ヒアリングだけに頼らず同席観察によって業務実態を把握する設計になっている。最初に構築するアプリの選定基準は「毎日発生する」「特定の1人が明確に苦しんでいる」「今は紙・Excel・LINEで完結している」の3条件であり、単なるシステム導入ではなく、社内に「自走できる担当者（社内チャンピオン）」を1人作ることを初回構築の真のゴールとしている。

2.2 ハイブリッド提供モデルへの転換

2.2.1 当初の前提とその修正

事業構想の当初案は、Palantir FDEモデルに範を取った「人が客先に常駐に近い形で入り込み、その場で作る」という対面常駐型モデルであった。しかし、decisions/00-agenda.mdの追加ヒアリングを経て、この前提は明確に修正されている。

【事実】Phase 0の追加ヒアリングにおいて、依頼者から「現場に入り切らず、PC作業ログを取得して外部からアドバイス・改善する」というモデル案をむしろ主軸にしたいとの回答を得た。出典：decisions/00-agenda.md「追加ヒアリングでの確認事項（確定）」2.、確認日2026-08-11。

2.2.2 転換の理由

この転換には、以下の複数の制約条件が整合的に作用している。

稼働量の制約：投下できる稼働は週30時間程度であり、依頼者含め3名体制という限られたリソースの中で、1人が常駐に近い形で複数社に張り付くよりも、稼働効率を上げる方向に合理性がある
地理的制約：対象地域は東京・大阪の2拠点、日帰り圏内という制約があり、頻繁な現場滞在を前提にするとカバーできる社数が限られる
既存の論点との緊張関係：一方で、ブリーフ1.6節が指摘する「零細に外部の人間を毎週入れてもらうのは心理的ハードルが高い」という論点、および「低リテラシー企業は自分の業務を説明できないため、ヒアリングより同席観察の方が実態を取れる」という知見は、対面接触そのものの価値を否定するものではない

この緊張関係を解消するために採用されたのが、対面同席観察（初回・業務棚卸し時）とリモートログ観察（契約後の継続支援時）を併用するハイブリッド設計である。初回の業務棚卸しは全面的に対面で行い、紙・電話・対人でのやり取りなどPC上に現れない業務実態を捉える。契約後の継続支援は、納品したアプリの利用ログを中心としたリモート観察に切り替え、稼働効率を確保する。

【事実】この設計判断はFDEモデルの原型（対面常駐）からの明確な修正であり、decisions/00-agenda.mdのPhase 0確定事項サマリーに「FDE（対面常駐）ではなく、対面同席観察（初回・棚卸し時）＋リモートログ観察・改善（継続支援時）のハイブリッドに変更。ブリーフの前提を修正」と明記されている。確認日2026-08-11。

【参考】この転換の背景として、Palantir FDEモデル自体の成功要因を分析したR-5の調査では、FDEの本質は「エンジニアを客先に置くこと」そのものではなく、そこで築かれる信頼関係を通じて自社プロダクトの継続契約につなげる点にあり、プロダクトを持たない企業が働き方だけを模倣すると「高単価のSES（客先常駐人材派遣）」に退化するリスクが指摘されている。この指摘を踏まえ、本事業では常駐そのものを目的化せず、限られた対面稼働を業務棚卸しという最も対面の価値が高い工程に集中させる設計を取っている（このリスクは第10章R-11で継続的に管理する）。

2.3 競合とポジショニング

2.3.1 調査の概要

R-1では、「社外CIO」「社外情シス」「IT顧問」「DX顧問」「AI顧問」等を名乗る、実在する国内サービス18社を対象に、価格帯・提供内容・稼働量を調査した（確認日はすべて2026-08-11）。

2.3.2 価格帯分布

【推定】確認できた11社の料金データから、市場の中心的な価格帯は月額8万〜20万円と見られる。ただしこの価格帯はほぼ「月1回程度の定例相談・診断＋随時のメール/チャット相談」という相談・アドバイザリ中心の構成であり、継続的な手を動かす作業（アプリ構築・システム運用代行）を伴うサービスは月20万円以上に偏る傾向が確認された。

価格帯（月額）	内容の傾向
〜10万円	月1回程度の相談・面談＋メール/チャット対応中心
10万〜20万円	月8〜15時間程度の実作業を含む
20万〜35万円	実運用の代行・保守が中心、伴走頻度が週次に近い
35万円〜	セキュリティ設計・戦略策定・事業改善まで踏み込む

2.3.3 ポジショニングマップ

縦軸を提供の濃度（アドバイザリ寄り⇔実装・常駐寄り）、横軸を価格帯（低⇔高）とすると、本事業が想定するポジション（初期50万円／月10万円で棚卸し・アプリ構築・現場同席まで提供）は、低価格×高濃度という象限に位置する。

【実装・常駐寄り】
情シス365フル(60万円) 情シスSAMURAI(常駐型)
IT顧問情シス君・事業改善(50万円)
スキルシステムズ プレミアム(30万円)
────────────────────────────→ 高価格
低価格
kintone導入支援(10万円)    ★本事業の想定ポジション
（棚卸し＋アプリ構築まで   （初期50万／月10万〜で
 踏み込む唯一の例）         棚卸し＋アプリ構築＋
DX顧問(5〜12万円)           現場同席まで）
Giving First(10万円)       →直接競合する事業者は未確認
ちょこっと情シス(3〜5万円)
【アドバイザリ寄り】

【推定】この象限に直接一致する競合は、R-1の調査範囲内では確認できなかった。18社中、「業務棚卸し」を明示的な工程として謳う事業者は2社のみ、そのうち棚卸しからアプリ構築までを一気通貫で提供すると明示しているのはkintone導入支援サービス（サクマキャピタル、月10万円）1社のみであった。ただしこのサービスは「kintoneというツールへの実装」に限定されており、依頼者が構想するより広い「業務改善アプリ全般」を扱う低価格事業者は見当たらなかった。

2.3.4 差別化点：「棚卸し→アプリ構築」の一気通貫提供

【推定・重要】依頼者が構想する「業務棚卸し→情報整理→アプリ構築」を一気通貫で、かつ低価格帯（月10万円台）で提供する事業者は、R-1で確認できた18社の中には見当たらなかった。加えて、「現場同席観察」を明示的な調査手法として掲げる事業者も確認できなかった。大半の事業者は「ヒアリング」「相談」「診断」という受動的な情報収集を前提としている。

一方で、この価格設定には両方向のリスクがある。【仮説：安すぎる可能性】現場滞在時間が市場の時間単価（8千〜2万円/時間）換算で月8時間の枠を超える場合、月10万円では採算割れするリスクがある。【仮説：高すぎる可能性】月3〜8万円台、あるいは国の中小企業デジタル化応援隊事業経由で実質500円/時間という極端な低価格帯のプレイヤーも既に存在するため、「安さ」だけでは差別化にならない。したがって本事業の競争力は、価格そのものではなく「棚卸し→アプリ構築という濃度」を、稼働上限の明文化（第5章）によって持続可能な形で提供できるかにかかっている。

2.3.5 空白地帯の考察

R-1が指摘する空白地帯は以下の4点に整理される。

現場同席観察を明示的な調査手法として掲げる事業者が見当たらない
棚卸し→アプリ構築を月10万円台の低価格で一気通貫提供する事業者がほぼ存在しない
零細（従業員数名〜数十名）に特化した事業者は少なく、多くは実質的に従業員数十〜数百名規模を想定している気配がある
依頼者が検討している業種に特化したFDE型サービスは確認できなかった

【要確認】これらの「空白」が真の空白なのか、検索エンジンに露出しない零細・地場のプレイヤー（商工会議所経由の個人コンサル等）が既に埋めているのかは、机上調査だけでは判別できない。この点はヒアリング（research/interview-guide.md）で補完する必要がある未決事項として残る。

3. 市場と顧客（ターゲット業種の定義と根拠）

本章は以下のファイルを参照して作成した：research/R2-industries.md、research/D7-customer-pain-deepdive.md、decisions/00-agenda.md

3.1 業種選定の評価軸

Phase 0での検討を経て、対象業種の絞り込みは以下の3軸で行うことが確定している。

承継ニーズの密度：後継者不在・高齢経営者比率が高い業種か
アナログ度（業務改善の伸びしろ）：情報が紙・Excel・LINEに散在し、棚卸し〜アプリ化の価値が大きいか
既存4事業（Web/編集コンサル、ファッションリサーチ、AI画像生成SaaS、テックカンファレンス運営）との距離：依頼者の実務経験が実際に接続し、初動の信頼構築を後押しするか

この3軸に基づき、ブリーフが当初挙げた5業種（賃貸管理会社・税理士社労士事務所・建設設備下請け・運送軽貨物・製造下請け）と、依頼者が実務経験を持つ5業種（商社系・代理店系・Web制作系・出版系・イベント系）の計10業種を横並びで調査した。

3.2 10業種の3軸スコア一覧

業種	承継ニーズ密度	アナログ度	既存4事業との距離	合計
税理士・社労士事務所	5/5	4/5	3/5	12
イベント系	3/5	4/5	5/5	12
商社系	3/5	4/5	4/5	11
建設・設備の下請け	4/5	4/5	3/5	11
製造下請け（板金・金型等）	4/5	5/5	2/5	11
賃貸管理会社	3/5	4/5	3/5	10
運送・軽貨物	3/5	4/5	2/5	9
代理店系	3/5	4/5	2/5*	9
出版系	2/5	4/5	2/5	8
Web制作系	2/5	3/5	1/5*	6

*代理店系・Web制作系は「既存事業と近すぎることによる利益相反・競合認定リスク」を減点要素として反映している。業務理解の深さだけで見れば本来より高スコアだが、営業上のデメリットを織り込んで評価した。

3.3 税理士・社労士事務所が有力候補である根拠

【事実】全国社会保険労務士会連合会「2024年度社労士実態調査」によれば、社労士の電子申請利用率は「利用していない」が32.8%（1人事務所では46.2%まで悪化）に達する。IT-BCPを「策定していない」事業所は95.4%、事務所が「居宅内にある」割合は49.1%（1人事務所では65.0%）に上る。出典：research/R2-industries.md、確認日2026-08-11。

【事実】同調査によれば、開業社労士の平均年齢は57.9歳、40〜69歳が全体の80.6%を占める。1人事務所比率は56.4%と過半数に達する。出典：同上。

ブリーフのD-5には、当初「税理士・社労士事務所は顧客自身のITリテラシーが低くないのではないか（ターゲット像とのズレ）」という懸念が挙げられていたが、上記の電子申請未利用率32.8%、居宅内事務所49.1%という一次データにより、この懸念は調査の結果として明確に否定された。承継ニーズの密度（平均年齢57.9歳、1人事務所56.4%という構造）と、アナログ度（電子申請未利用32.8%）の両方が高水準で確認された上、紹介チャネルとしての戦略的価値（ブリーフが当初から指摘していた「顧客にすると紹介チャネルが自動で開く構造」）も併せ持つため、支援対象としての適格性と紹介チャネルとしての価値が両立する数少ない業種と評価できる。

3.4 イベント系が有力候補である根拠

イベント系は、承継ニーズ密度（3/5）・アナログ度（4/5）自体は他業種と比べ突出しているわけではないが、既存4事業との距離が5/5という、10業種中唯一の評価を得ている。【事実ベースの推定】依頼者はテックカンファレンス運営の実務経験を持ち、企画〜精算までの業務フロー全体を自ら経験しているため、業務棚卸しの解像度を他業種より高くできるという決定的な強みがある。日本青年会議所（JC）等、依頼者の既存人脈との接続可能性も高い。出典：research/R2-industries.md、確認日2026-08-11。

ただし、【要確認】イベント系は「展示会（見本市を含む）の企画・運営業」として独立した産業分類コードを持たず経済センサス上の単独捕捉が困難であり、業界統計そのものが薄い。定量評価の確度は税理士・社労士事務所ほど高くない点には留意が必要である。

3.5 D-7：「必要性を感じていない層」というボリュームゾーンの発見

D-7の顧客課題深堀り調査は、依頼者から「特に手厚めに」との要望があった項目であり、事業構想にとって都合の悪いデータも含めて正直に記載されている。その中でも最も重要な発見は、AI/IT非導入企業の最大セグメントが「導入方法が分からない」層ではなく、「そもそも必要性を感じていない」層であるという点である。

【事実】民間調査会社（ラグザス株式会社、2026年4月3日〜6日、ビジネスパーソン3,000名対象）の調査によれば、中小企業（従業員1〜300名）のAI導入率は23.7%にとどまり、中小企業の59.0%が「AI導入予定なし」と回答している。出典：https://prtimes.jp/main/html/rd/p/000000354.000072123.html、確認日2026-08-11。※TDB等の公的統計ではなく民間企業単独調査であり、対象が企業単位の悉皆調査ではない可能性がある点に留意。

【事実】同関連調査報道によれば、AIを使わない理由の最多は「必要性を感じない」55.8%であり、「使いこなせる自信がない」20.0%、「使い方がわからない」13.7%を大きく上回る。さらに、代表・役員がAIを「全く使っていない」企業の85.7%は「AI活用の方針も推進体制もない」状態であった。出典：research/D7-customer-pain-deepdive.md、確認日2026-08-11。

この結果の事業への含意は重い。「使い方支援」「操作研修」といった障壁除去型のアプローチが有効な層は一部にとどまり、最大のボリュームゾーンは動機形成・啓蒙のフェーズにある。しかも「必要性を感じない」という認識を持つのは現場の担当者ではなく、多くの場合意思決定権者である経営層自身である。

一方で、この否定的な発見と対をなす形で、「知識・情報不足」「旗振り役の不在」が予算不足を上回る非着手理由であるという、支援サービスにとって有利なデータも複数の独立調査から確認されている。

【事実】IPA「DX動向2024」調査（2024年2月〜5月実施、一次資料）によれば、従業員100人以下の企業がDXに取り組まない理由として「戦略のための知識や情報が不足している」59.0%が最多であり、「取り組むための予算が不足している」34.2%を大きく上回る。出典：IPA調査分析ディスカッション・ペーパー2024-02、確認日2026-08-11。

【事実】東京商工会議所「中小企業のデジタルシフト・DX実態調査」（2023年5〜6月実施、東京23区内会員企業対象、回答1,336社）によれば、デジタル化推進の課題として「旗振り役が務まるような人材がいない」33.8%が「コストが負担できない」27.0%を上回った。出典：research/D7-customer-pain-deepdive.md、確認日2026-08-11。

これらを総合すると、本事業のターゲティングにおける含意は次の2点に整理できる。第一に、「必要性を感じない」層に対しては障壁除去型のメッセージ（使いやすさ・低コスト）は効かず、別の動機形成アプローチ（成功事例の提示、無償簡易デモによる体感等）が必要になる。第二に、「知識・情報不足」「旗振り役不在」という、複数の独立調査が一致して示す課題構造は、外部の伴走者が「代理の推進役」として入り込む本事業のモデルと直接対応しており、この層に対しては訴求の理屈が立つ。

3.6 ターゲット地域：東京＋大阪、日帰り圏内という制約

【事実】decisions/00-agenda.mdの回答シートによれば、対象地域は「関東圏内、特に東京」に加え、大阪にも共同で事業を行う人材がいるため大阪周辺も拠点になり得るとされている。現場訪問の頻度は「一旦日帰り圏内」という制約が明示されている。確認日2026-08-11。

この地域選定は、ブリーフ当初の「関東」という想定（M&A検討時の想定を引き継いだもので、要再検討とされていた）を、事業単体で成立させる前提のもとで再検討した結果である。制約の実質は「依頼者（および大阪拠点の共同事業者）が定期的に現場へ通える範囲」であり、対面同席観察を前提とする第1ステップ（業務棚卸し）の実行可能性を直接左右するため、日帰り圏内という制約は第2章のハイブリッドモデル設計、および第6章の供給制約（WIP上限）とも密接に関連している。

4. 提供価値とサービス設計（3ステップの具体化）

本章は以下のファイルを参照して作成した：design/S1-service.md、design/S3-financials.md、research/interview-guide.md、research/R5-fde-cases.md

4.1 全体フロー

本事業の提供フローは、契約前の無償簡易デモを起点に、以下の順序で構成される。

無償簡易デモ（契約前）
  → 初期50万円の契約
  → ステップ1：対面同席観察・業務棚卸し
  → ステップ2：情報整理・要件定義
  → ステップ3：初期アプリ1本構築
  → ステップ4：導入・社内チャンピオン育成
  → 継続支援フェーズ（月額10万円、リモートログ観察＋月次改善）

この全体フローに対応する工数は、S-3（収支計画）とS-1（サービス設計）の間で整合が取られており、初期構築フェーズの総作業時間は標準45時間（保守シナリオ69時間）、うち初期費用50万円の対価となるのは契約後の40時間（保守61時間）である。無償デモの5時間（保守8時間）は契約前の営業活動枠として別枠計上されており、初期構築フェーズの対価とは分離されている。継続支援フェーズは標準7時間/月（保守13時間/月）である。この工数モデルは、最初の2〜3社を「工数実測のパイロット」と位置づけ、実測データに基づき更新することが前提とされている。

4.2 ステップ0：無償簡易デモ（契約前・5時間）

【事実】decisions/00-agenda.mdの回答シートにより、初回接触〜契約の流れは「契約前に無償に近い簡易デモ（短時間・極小スコープ）を見せ、そこから初期50万の契約に進む」形に確定している。確認日2026-08-11。

デモの目的は、「この会社は自分たちの業務を理解した上で、実際に手を動かせる」ことを契約前に低コストで証明することにある。具体的には、電話・オンラインでの15〜20分版ヒアリング（0.5時間）で対象業務を特定し、最も再現しやすい1業務を選定（0.5時間）した上で、極小スコープのデモアプリを構築（3時間）し、提示・反応観察・次のステップの打診（1時間）を行う、計5時間の構成である。成果物は使い捨て前提のデモアプリ1点とヒアリング記録であり、初回接触からデモ提示まで目安1〜2週間以内に収める。

【仮説】5時間で実現できる範囲は「単一の定型作業（1つのExcelシート、1つのLINEグループのやり取り等）を対象にした、見た目の変化が分かりやすい最小限の自動化・可視化」に限定される。複数業務にまたがる連携や既存システムとの接続はできない。この線引きの妥当性は未検証であり、最初の3〜5社のデモで実工数を実測して検証する。

4.3 ステップ1：対面同席観察・業務棚卸し（対面・10時間＝2回訪問＋準備）

初期費用50万円の対価となる40時間のうち、最初の工程である。低ITリテラシー層は自分の業務を言語化できないという前提に立ち、ヒアリングではなく観察によって業務実態を構造化する。

事前準備（1時間）でデモ時の記録と観察対象業務の仮説を整理した後、訪問1回目（4時間、移動含む）で60分版ヒアリングスクリプトを用いた質問と同席観察を並行実施する。観察では、作業の中断回数、紙からExcel等への転記の連鎖、「あの人に聞いてくる」という属人的確認行動の頻度、ツールのバージョンの古さ、経営者・担当者の自嘲的発言（改善余地への自覚のシグナル）を記録する。訪問2回目（4時間）では業務プロセスの再現性を確認し、社内チャンピオン候補を見極め、「毎日発生する」「特定の1人が明確に苦しんでいる」「紙・Excel・LINEで完結している」の3条件チェックを確定させる。記録整理（1時間）を経て、業務棚卸しシートと業務プロセス流れ図を成果物とする。

このステップは全面的に対面で行う。零細企業の業務はPC上で完結しない部分が多く、対面でなければ紙・電話・対人のやり取りは観察できないためである（詳細は4.7節）。観察の許可取得にあたっては、「業務改善のご提案のために、実際の作業の様子を1〜2時間ほど拝見させてください」という形で、評価・監視ではなく提案準備目的であることを明確に伝え、機密情報の扱いについて事前に合意を取る。

4.4 ステップ2：情報整理・要件定義（主に社内作業・10時間）

同席観察で得た散在情報（紙・Excel・LINE・観察メモ）を、アプリ構築可能な形の要件に変換する工程である。観察記録・ヒアリング記録の構造化（3時間）、3条件を満たす業務の中から初期アプリの対象業務を1つ確定（2時間）、要件定義書の作成（4時間）、顧客への簡易確認（1時間）から構成される。成果物である要件定義書は1〜2枚程度に抑え、過剰な文書化を避け、零細企業の意思決定者が読める分量とする。

4.5 ステップ3：初期アプリ1本構築（主に社内作業・15時間）

3条件を満たす業務を1つ選び、それを改善する最初のアプリケーションを構築・納品する。標準スタックを用いたアプリ本体の構築（10時間）、顧客の既存ツール（Excel/LINE等）との接続・データ移行（3時間）、動作確認・簡易テスト（2時間）から成る。成果物は稼働するアプリケーション1本と、画面キャプチャ中心の簡易操作マニュアル（1〜2枚、低ITリテラシー層向け）である。構築の途中経過を1回程度、対面またはオンラインで顧客（特にチャンピオン候補）に見せ、認識のズレを早期に潰すことを推奨するが、この中間確認の時間は15時間の枠内で吸収する運用であり、時間超過のリスクは4.8節で扱う。

4.6 ステップ4：導入・社内チャンピオン育成（対面中心・5時間）

「導入が失敗する主因は品質ではなく使う人がいないこと」というブリーフの論点を踏まえ、アプリの納品にとどまらず、社内に自走できる担当者を1人作ることを目的とする工程である。

選定基準は、（1）「特定の1人が明確に苦しんでいる」と観察で特定された本人であること、（2）観察中の自嘲的発言等、変化を歓迎するシグナルがあること、（3）経営者本人ではなく日常業務を回している担当者であること（ただし極小規模企業では経営者＝担当者のケースも多い）、（4）「その担当者が急に使えなくなったら明日どうなるか」という質問への反応から、属人化の問題を自覚しているか、の4点である。

育成の埋め込み方：工数枠が5時間と短いため、チャンピオン育成は独立した工程として最後にまとめて行うのではなく、初期構築フェーズ全体に薄く埋め込む設計とする。ステップ1（対面観察）では観察対象として自然に関与させ（追加コストなし）、ステップ3（アプリ構築中間確認）では中間確認の場に同席させて認識合わせを行い（同上）、ステップ4（導入研修）で操作研修と「困ったときの連絡ルート」の合意という主要部分（5時間の大半）を実施する。この設計により、独立した「育成タスク」に割ける純粋な時間はごくわずかであり、動機づけ・関係構築に十分な時間を割けないという制約があることは正直に認識しておく必要がある。

契約終了後も自走できる状態を作るため、操作マニュアルの手渡し、よくあるトラブルの事前共有、連絡ルートの明確化、リモートログ観察の同意取得を「引き継ぎ」の一部として位置づける。

4.7 リモートログ観察の具体的な仕組み

継続支援フェーズ（月額10万円対応）の中核である「リモートログ観察・分析（3時間/月）」について、取得する範囲と取得しない範囲を明確に線引きする。

取得する	取得しない
納品したアプリ自体の利用ログ（起動回数、機能別利用頻度、入力データ量の推移）	個人のメール内容
対象業務に関連する特定フォルダ・ファイルの更新頻度	ブラウザ全体の閲覧履歴
（顧客の同意がある場合のみ）対象業務で使用する特定アプリの起動・使用時間	対象業務と無関係なアプリ・ファイルの操作
	キーロガー・画面録画等のリアルタイム監視

この線引きの背景には、PC操作ログ監視の法的・心理的リスクに関する知見がある。R-5の調査によれば、裁判例では「調査の必要性を欠く場合や、調査の態様が社会的に許容し得る限度を超えている場合には違法となることがある」と判断されており、取得対象を「納品したアプリと、その対象業務に直結するファイル」に限定し、業務外の領域には一切踏み込まない設計としている（技術的な実現方法は第8章参照）。

【仮説・要検証】零細企業の業務の多くは電話・対面・紙・LINE（私用端末）で発生しており、これらはPC作業ログとして捕捉できない。そのため、リモートログ観察だけで得られる改善材料は「納品したアプリの利用状況」という狭い範囲に限定される可能性が高い。この限界を踏まえ、継続支援フェーズの設計は「ログ分析のみ」に依存させず、月次ミーティング（社内チャンピオンとの対話）を改善提案の主たる情報源として位置づけ、ログはあくまで会話の起点・裏付けとして扱う。

対面観察からリモートログ観察への移行時には、「見えなくなる不安」から顧客が離脱するリスクがある。この対応として、（1）移行を儀式化し社内チャンピオンを通じて周知する、（2）「個人評価のためではなく、アプリが役に立っているかを見るためのログ」であることを同意書と口頭説明の両方で明示する、（3）取得範囲を同意書に明記し対象業務以外には一切アクセスしないことを保証する、という3点を設計に織り込んでいる。

4.8 この設計が機能しない条件・リスク

本設計に同意するだけでなく、機能しない可能性のある条件を明示する。

チャンピオン候補が見つからない場合：極小規模企業（1〜2人）で全員が経営者本人に近い立場の場合、継続的に使い続ける1人を特定できない可能性がある。この場合は経営者本人をチャンピオンとし、アプリの操作自体を極力単純化する設計を前提とする。それでも2回の訪問を通じて候補が定まらない場合、対象業務の選定自体が3条件を満たしていない可能性が高く、契約前であれば対象業務の変更、契約後であれば深追いしない対応にとどめる判断が必要になる。
リモートログ観察が効かない業務のリスク：業務の多くが対面・電話・紙中心の顧客では、継続支援フェーズの改善提案の材料が薄くなるリスクがある。
対面からリモートへの移行時の離脱リスク：離脱の予兆（アプリ利用頻度の急減、月次ミーティングの日程調整の停滞等）を早期に検知する具体的な運用フローは、本書執筆時点では未設計であり、今後の検討課題として残る。
チャンピオン育成の工数不足：5時間という枠は、実質的に操作研修と同意取得・スケジュール確認にほぼ費やされ、動機づけ・関係構築に十分な時間を割けない制約がある。

これらはいずれも、最初の2〜3社のパイロット実施を通じて優先的に検証することが予定されている。

5. 価格・契約設計

本章は以下のファイルを参照して作成した：design/S2-pricing.md、design/S3-financials.md、research/R1-competitors.md、research/R3-public-programs.md

5.1 単一プランとその理由

本事業は単一プラン（初期費用50万円＋月額10万円）を基本とし、稼働範囲を超える要望は有償オプションで個別対応する構成を採る。この構成は依頼者により確定済みである。

単一プランを選択する理由は3点ある。第一に、決裁者が「30〜40代の後継ぎ世代である可能性が高い」という仮説（ブリーフ1.2節）を踏まえると、経験の浅い決裁者ほど選択肢が多いと比較検討に時間がかかり決裁が遅れるリスクがある。第二に、初期構築フェーズのWIP上限が2社という供給制約下では、プランごとに異なる工数設計・進捗管理を並行運用する管理コストは、依頼者1人体制（管理業務は月120時間中12時間のみ）の稼働に見合わない。第三に、R-1の発見の通り、業務棚卸し→アプリ構築の一気通貫を月10万円台で提供する競合が市場にほぼ存在しないため、顧客が価格を比較検討できる直接競合が存在せず、「松竹梅で選ばせる」ことの意味自体が薄い。

一方で、単一プランには将来の値上げ・差別化の余地を封じるリスク、価格帯の合わない顧客層を最初から取りこぼすリスクがあることも認識されている。この対応として、最初の3〜5社は単一プランで運用して実測工数データを集め、その後実測データをもとに上位プランを追加検討するという段階的なアプローチを取る。下位プラン（より安く軽い関与）は原則作らない方針であり、その理由は超低価格帯（月3〜8万円台、あるいは国の中小企業デジタル化応援隊事業経由で実質500円/時間）が既にレッドオーシャンであるためである。

5.2 稼働上限と超過時の扱い

【事実】S-3で確定した継続支援フェーズの標準工数は7時間/月（リモートログ観察分析3時間＋月次改善提案・軽微な機能追加4時間）である。

契約書上の稼働上限は月8時間とすることが確定している。社内の実行目標（7時間）と、顧客に約束する契約上の数字（8時間）を意図的に分離することで、通常運用の中で発生する軽微な変動を毎回「超過」として扱う摩擦をなくす狙いがある。ただし、この1時間のバッファが常態化して実工数が8時間に張り付く場合、S-3が想定する継続支援フェーズの同時保有可能社数（標準シナリオで3〜4社、月24時間÷7時間の計算）が崩れるため、「8時間バッファは例外的な変動の吸収であって新しい標準時間ではない」ことを社内ルールとして明文化する必要がある。

切り分けの単位は「時間ベース＋対応範囲の明文化」の組み合わせとする。本数ベース（機能の大小で不公平感が出る）や対応範囲ベース単体（範囲内であれば無制限に工数を投入できるように読め、「代理のAI人材」を名乗ることで要求が青天井になるリスクに対応できない）の弱点を踏まえた選択である。時間ベースの弱点（顧客にとってブラックボックス化しやすい、工数管理の実務負担）を緩和するため、契約書・顧客向け説明資料には「月8時間で何ができるか」の具体例を併記する。

超過分の課金単価は、自社の基本単価（月額10万円÷8時間＝約12,500円/時）と同一単価とすることが依頼者により確定している。割増単価も選択肢として検討されたが、価格体系が途中で変わらない安心感を顧客に与えるシンプルさを優先し、同一単価が選択された。単発の軽微な超過は時間単価での追加請求、恒常的な超過は上位プランへの誘導という2段構えで運用する。翌月繰越は工数管理負担の増大とキャパシティ計算との整合性の問題から採用しない。

5.3 成果物の所有権

【事実】ブリーフ3章D-3は「契約終了後、納品したアプリの所有権・保守はどうなるか。ここを決めていないと必ず揉める」と明記している。

依頼者の回答（「運用の中にその保守はいれつつ、運用しなくなったら相手に所有権を渡して凍結でOK」）を踏まえ、以下の3段階の扱いが確定している。

契約継続中：アプリの保守・運用は自社が担う。著作権・実装コードは自社に帰属し、顧客には利用権を許諾する
契約終了時：顧客に対しアプリの所有権（実装コード・設定一式）を譲渡する
譲渡後：譲渡と同時に自社側の保守義務は終了し「凍結」（動作保証・更新対応は行わない）。以降の保守は顧客の自由とする

契約終了時のデータの持ち出し（顧客が入力・蓄積した業務データそのもの）は、アプリの実装とは別物として扱い、CSV等の一定形式でエクスポートして引き渡すことを明記する。契約終了後に顧客が「アプリは自分たちが作らせたものだから当然自分のものだ」と主張し、依頼者側の想定と食い違うことが最も揉めやすいシナリオとして想定されており、契約締結時の書面明示が必須とされている。

5.4 最低契約期間

最低契約期間は6ヶ月とすることが確定している。初期構築フェーズの工数（契約後40〜61時間）は初期費用50万円だけではペイしない可能性がS-3で示唆されており、月額継続収益で回収する前提があるためである。最低契約期間6ヶ月により、月額10万円×6ヶ月＝60万円の継続収益が最低保証される計算になり、初期構築の原価（工数ベースで概算20〜30万円相当）を十分に回収できる設計になっている。競合の参考値（IT顧問情シス君：最低3ヶ月、DXBoot：最低6ヶ月）と照らしても、中間〜上位の水準である。

5.5 オプションサービス

標準スコープに含まれない作業は、有償オプションとして切り出す。

オプション項目	内容	想定タイミング
契約終了時の環境移設	自社ホスト上のアプリを顧客側の環境へ移設・引き渡す作業	契約終了時
顧客独自の環境構築代行	顧客が自社サーバー・独自クラウド環境等を希望する場合の構築代行	契約開始時・契約中いずれも可

このオプション化により、標準プランの稼働上限を守りながら範囲外の要望に応える受け皿を用意でき、「無償では対応しないが有償なら対応できる」という形で青天井要求への線引きと収益機会を両立できる。特に「顧客独自の環境構築代行」は、自社ホストを標準とする設計思想を崩さずに、データを外部に置きたくないというセキュリティ懸念の強い顧客を取りこぼさないための受け皿として位置づけられる。

【未決】オプション料金の具体的な金額は、移設作業・環境構築代行の実工数を最初の数社の実績から見積もった上で確定する予定であり、本書執筆時点では未確定である。出典のない数字は記載しないというルールに従い、具体額の記載は保留する。

5.6 補助金の扱い：現時点では前面に出さない

【事実】R-3の調査によれば、IT導入支援事業者登録（デジタル化・AI導入補助金2026）の2026年度分登録受付は2026年3月30日に開始済みであり、これから登録しようとしても間に合わない可能性が高い。次の登録機会は2027年度（例年3月頃開始と推定されるが確定情報ではない）になる見込みである。確認日2026-08-11。

登録の前提条件である決算1期以上経過については、依頼者への確認により満たしていることが確認されている。ただし、決算要件以外の登録要件（実務経験年数等）を満たすかは、R-3の調査範囲では確認できておらず、未決事項として残る。

以上を踏まえ、現時点（本書執筆時点）では初期費用50万円の提示に補助金活用を前面に出さない方針とする。初期50万円・月額10万円の提示は補助金を使わない前提の実額として設計し、S-3の収支計画も補助金を織り込んでいない。顧客への説明では「将来的にIT導入補助金等の対象ツールとして登録できる可能性を検討中」という表現にとどめ、確約や「今回の契約から使える」という誤解を招く言い方は避ける。

2027年度のIT導入支援事業者登録は、決算要件を満たしていることから具体的な検討候補として位置づける。登録できれば自社の業務改善アプリを補助金対象ツールとして登録し、顧客の初期費用負担を圧縮できる可能性があるが、対象ツールの要件（ノーコードで構築したアプリが対象になり得るか等）は別途確認が必要である。また、大阪府DX推進パートナーズ（公募制で「ソリューションを提案できる事業者」という比較的緩やかな要件だが次回公募時期は未確定）も、価格提示に直接つながる制度ではないものの、信頼性・チャネルの補強として将来的な検討候補に位置づける。いずれも【仮説】段階の将来オプションであり、現時点の価格提示・事業計画の前提としては用いない。

6. 顧客獲得戦略（チャネル別）

本章は以下のファイルを参照して作成した：research/R4-channels.md、design/S2-pricing.md、design/S3-financials.md

6.1 チャネル検証の背景

ブリーフ1.6節は「零細に外部の人間を毎週入れてもらうのは心理的ハードルが高い。『紹介されている』か『すでに助けを求めている』かの2択でしか入れない。飛び込み・Web集客は原理的に効きにくい」という仮説を提示していた。R-4は、この仮説を検証するため8つのチャネルの到達可能性・確度・リードタイム・コスト・障壁を調査した（M&Aプラットフォーム経由のチャネルはD-1決定によりスコープ外のため参考情報にとどめる）。

【要確認】本調査では「飛び込み・Web集客が効かない」ことを直接反証する一次情報（Web広告・飛び込み営業経由での成功事例・統計）は発見できなかったが、これはWebSearchの呼び出し回数上限に到達したことによる調査の限界であり、仮説の反証が存在しないことの証明ではない。追加のセッションでの反証探索が推奨事項として残っている。

6.2 優先順位付きチャネル一覧

R-4の調査結果に基づく優先順位は以下の通りである。

順位	チャネル	一言理由
1	士業（税理士・社労士）経由の紹介	「信頼できる筋からの紹介」に最も直接合致し、依頼者自身の人脈から今すぐ着手可能。ただし信頼構築の時間は要する
2	自治体のDX伴走支援事業（特に大阪府DX推進パートナーズ）	行政が企業側の課題ヒアリングまで代行してくれる制度設計。ただし参画要件・次回募集時期の確認が先決
3	地銀・信金のビジネスマッチング	士業紹介と同様に「信頼できる筋」に該当するが、取引実績が前提になる可能性が高い
4	補助金の採択者リスト	「IT投資に前向き」という質の高い母集団に低コストでリーチできるが、直接アプローチの適否や公開範囲に未確認事項が残る
5	認定経営革新等支援機関	検索経由の直接集客効果は期待薄。士業連携を補強する信頼の裏付けとして並行取得する価値はある
6	青年会議所・商工会議所青年部	人脈形成の土壌としては有望だが、年会費10万円超のコストに対して案件化の実例が確認できず、投資対効果が不透明
7	ハローワークの長期掲載求人	利用規約上の営利目的利用禁止が明記されており、組織的な営業リスト化はコンプライアンスリスクが高い
8	M&Aプラットフォームの売り案件	D-1決定によりスコープ外。匿名性・規約上の直接接触禁止により実務上の実行可能性も低い

第1位：士業経由の紹介について、法的な留意点を明記する。【事実】社会保険労務士法第23条の2（非社労士との提携の禁止）により、非社労士が社労士と顧客との間に立って契約成立の便宜を図り、謝礼その他実質的な利益の授受がある行為は禁止されており、違反は1年以下の懲役または100万円以下の罰金という刑事罰の対象になる。出典：research/R4-channels.md、確認日2026-08-11。したがって、士業に紹介料という形で金銭的インセンティブを渡すスキームは、特に社労士に対しては明確な違法リスクがあり、金銭を介さない信頼関係構築型の紹介（相互に信頼関係を築いた上での無償の口コミ紹介、業務提携としての相互送客）が現実的な形態になる。この点は、税理士・社労士事務所を有力ターゲット業種としつつ、同時に紹介チャネルとしても位置づける本事業（第3章）にとって、遵守すべき重要な制約である。

第2位：自治体のDX伴走支援事業について、東京都・大阪府ともに「行政が企業側の課題を先に拾い上げてから事業者に取り次ぐ」設計であり、ブリーフの仮説（紹介または助けを求めている状態が必要）と整合的な有望なチャネルと評価されている。ただし東京都のDX推進トータルサポート事業は2026年度募集が既に終了しており次回公募は2027年度以降と見込まれ、大阪府DX推進パートナーズは次回募集時期自体が未確定という点で、双方とも即効性には欠ける。

6.3 供給制約を踏まえた営業ペースの調整

チャネル戦略は、第4章・第5章で確定した供給制約と一体で運用する必要がある。

【事実】S-3より、初期構築フェーズのWIP上限（同時並行可能な新規契約数）は2社である。標準シナリオでは月54時間÷40時間≈月1.35社の新規着手能力があるが、WIP上限2社の制約により、実際には「着手中2社を並行しながら、1社完了ごとに1社着手」というペースになる。保守シナリオでは1社の初期構築に平均6〜8週間かかり、新規着手ペースは事実上2ヶ月に1〜1.5社程度に低下する。

この供給制約を無視して営業活動を展開すると、「契約したのに着手が数ヶ月先」という状態が生まれ、顧客の不満・信頼毀損につながるリスクがある。この対応として、S-2では以下の運用方針が確定している。

契約開始日の予約制：契約自体は締結するが、着手日（同席観察の初回訪問日）を「◯月◯週から」という形で予約制にし、契約書上にも着手予定日を明記する。ウェイティングリスト方式（契約前の宙ぶらりん状態を作る）は機会損失が大きいため採用しない
無償デモの供給制限との連動：着手可能時期が2ヶ月以上先になる見込みの場合は、無償デモの実施自体を一旦保留し、WIP上限に空きが出る見込みの時期が近づいたタイミングで改めてデモを実施する。デモをやってから長期間待たせると熱量が冷めるため、デモのタイミング自体を供給状況に合わせて後ろ倒しする

顧客への伝え方は、「断る」ではなく「順番を明示する」というフレーミングを取る。R-4が確認した「紹介されているか、既に助けを求めているかの2択でしか入れない」というチャネル特性を踏まえると、単純な「今は対応できません」という拒否は、一度断られた顧客の再アプローチを困難にするリスクがあるためである。基本フレームは「今、丁寧に対応させていただいている会社様が2社ございまして、次にお受けできるのが◯月頃からになります。その分、今関わらせていただいている会社様には全力で対応できている、とご理解いただければと思います」というものであり、WIP上限2社という制約を「手が回らない」という弱みではなく「1社1社に深く関与する」という提供価値の裏付けとして伝える設計である。紹介経由の見込み客については、紹介元との関係維持のため、順番を明示した上で個別の相談には応じる余地を残すが、WIP上限自体は動かさない。

【未決】この文言は営業資料のトークスクリプトに転記して使うことを想定した「方向性」であり、実際の言葉遣いの調整、および新規契約の受付ペースと第4章のサービス設計・営業プロセスとの具体的な擦り合わせは、引き続き未確定の実務課題として残る。同様に、WIP上限2社を超える引き合いが来た場合の断り方・ウェイティングの伝え方についても、顧客体験として摩擦が少ない言い回しの設計は今後の検討課題である。

7. デリバリー体制とオペレーション設計

参照元：design/S3-financials.md 6章（拡張シナリオ）・3章（キャパシティ・WIP上限）、design/S1-service.md（実施体制・3ステップの工数配分、社内チャンピオン育成手順の概要）

7.1 体制の基本構造：ベースケースと拡張シナリオを分ける

decisions/00-agenda.mdのPhase 0確定事項として、チーム体制は「依頼者含め3名で稼働（既に動ける2名あり、うち1名は大阪拠点）」と確定している。しかしdesign/S3-financials.md 1.1節は、他2名の役割・稼働量が当初未定であったことを踏まえ、役割未定の人員をキャパシティに単純加算することは危険（FDEモデルは棚卸し・設計が属人的で時間は代替不可）という設計方針を取り、収支計画・体制設計の双方を以下の2層構造で扱っている。本計画書も同じ構造を踏襲する。

ベースケース：依頼者1名・週30時間（月120時間）のみで成立する体制。事業の生死を分ける「1人で何社回せるか」を最も厳しく検証する基準。
拡張シナリオ：3名（依頼者＋既に動ける2名）が同一役割で稼働する場合の体制。【仮説】として扱い、実測データが揃うまでは参考値に留める。

7.2 ベースケースの実施体制（依頼者1名・週30時間）

design/S1-service.mdは、design/S3-financials.mdが確定させた工数モデル（下表）を唯一の数値基準として、その中で「何を・どういう順番で・誰が見極めながら実行するか」を手順化したものである。

初期構築フェーズ（初期費用50万円に対応）

作業	標準	保守（1.5倍）
無償簡易デモ（契約前・営業活動枠）	5時間	8時間
対面同席観察・業務棚卸し	10時間（2回訪問＋準備）	15時間
情報整理・要件定義	10時間	15時間
初期アプリ1本構築	15時間	23時間
導入・社内チャンピオン育成	5時間	8時間
総作業時間（デモ含む）	45時間	69時間
うち初期50万円の対価（契約後のみ）	40時間	61時間

【事実】無償デモ5時間（保守8時間）は、当初S1側の指摘を受けてS3側の稼働配分（「新規開拓・営業活動」枠、月30時間）に計上する整理に修正済みであり、初期構築フェーズの対価は契約後40時間（保守61時間）としてS1・S3間で数値が統一されている（2026-08-11更新）。

継続支援フェーズ（月額10万円に対応、1社あたり月次）

作業	標準	保守
リモートログ観察・分析	3時間	5時間
月次改善提案・軽微な機能追加	4時間	8時間
合計	7時間/月	13時間/月

依頼者1名・月120時間の稼働配分は以下の通り。

用途	配分比率	月間時間
新規開拓・営業活動（デモ含む）	25%	30時間
初期構築フェーズ（既存の契約中案件）	45%	54時間
継続支援フェーズ（既存の月額顧客）	20%	24時間
管理・バックオフィス	10%	12時間
合計	100%	120時間

7.3 WIP（同時並行数）上限：1人あたり2社

design/S3-financials.md 2.3節は、初期構築フェーズについて「文脈スイッチのコストが重いため、時間が余っていても同時に初期構築を進められるのは2社が上限」と仮置きしている。これは時間（工数）だけでは表現できない制約として、キャパシティ計算に別枠で組み込まれている。

標準シナリオ：月54時間÷40時間≈月1.35社を新規着手可能だが、WIP上限2社の制約により、実際には「着手中2社を並行しながら、1社完了ごとに1社着手」というペースになる。継続支援は月24時間÷7時間≈同時3〜4社を継続保守可能。
保守シナリオ：月54時間÷61時間≈0.89社/月。WIP上限2社を維持するには1社の初期構築に平均6〜8週間かかる計算になり、新規着手ペースは事実上2ヶ月に1〜1.5社程度に低下する。継続支援は月24時間÷13時間≈同時1.8社、実質2社が上限。

7.4 拡張シナリオ：3名同一役割モデル【仮説】

decisions/00-agenda.mdの追加ヒアリングにより、3名（依頼者含む）は「全員営業兼作業者として同じ役割」であることが確認されている（依頼者確認済み・2026-08-11）。この回答を踏まえ、design/S3-financials.md 6章は拡張シナリオを以下のように整理している。このモデル全体は【仮説】であり、実測による検証が前提である。

単純倍化は採用しない：3名が同じ役割で稼働する場合、最も単純なモデルは「依頼者1名分のキャパシティを3倍する」ことだが、S3はこれを採用していない。理由は以下の2点。

WIP上限は「事業全体」ではなく「1人あたり」に紐づく制約である可能性が高い：初期構築フェーズの文脈スイッチコストは個人の認知負荷に起因するため、3人いれば「1人あたり同時2社」が積み上がり、事業全体でのWIP上限は理論上6社まで拡張できると推定される。ただしこれは【仮説】であり、実際には顧客対応の窓口一本化（同じ顧客に複数人が入れ替わり立ち替わり対応すると信頼構築を損なうリスク）を考慮すると、1社を1人が最初から最後まで担当する「顧客専属制」が現実的な運用と考えられる。
属人化リスクとの整合：3名同一役割によって、design/S6-risks.mdが指摘する属人化リスク（依頼者が動けなくなったら止まる）が部分的に緩和される。

3名体制でのキャパシティ試算（標準シナリオ、仮置き）：各自が7.2節と同じ配分（週30時間、月120時間）で稼働すると仮定した場合、事業全体の月間キャパシティは360時間（120時間×3名）、事業全体のWIP上限は同時6社（2社×3名、顧客専属制を前提）、継続支援の同時保有上限は約9〜12社（3〜4社×3名）となる。

この試算は「3名が依頼者と同じ稼働時間・生産性で動ける」という強い仮定に立っている。大阪拠点の共同事業者は稼働時間・立ち上がりの早さが未検証であり、S3は「最初の数ヶ月は依頼者1名分のキャパシティ（ベースケース）を基準に計画し、他2名の実際の稼働実績が確認でき次第、この試算を更新する」運用を推奨している。

投入タイミング：3名とも同一役割で「いつでも動ける」体制が確認できたため、事業開始当初から3名体制でスタートする選択肢もあるが、保守シナリオでは初月〜3ヶ月は獲得0社という営業基盤構築期間が存在するため、開始当初から3名がフル稼働しても営業リード自体が不足すれば工数は余る可能性がある。実務的には「開始当初は依頼者が主導して営業・初回案件を進め、2〜3社目以降、他2名を順次本格投入する」という漸進的な立ち上げが推奨されている（【仮説】、依頼者判断を優先）。

地理的な役割分担（依頼者確認済み・2026-08-11）：大阪に既に常駐する共同事業者がいることが確認できており、「顧客専属制」を自然に地理的な担当分けと一致させられる（東京圏の顧客は東京拠点の依頼者、大阪圏の顧客は大阪常駐者が対応）。これにより東京・大阪間の出張移動は発生しない設計となり、移動コスト・移動時間の両面で効率化が見込める。ただし、大阪拠点での新規開拓ペースは大阪常駐者の実際の稼働開始タイミング・立ち上がりの早さに強く依存するという留保が付く。事業開始当初は東京拠点（依頼者）を主軸に据え、大阪拠点は大阪常駐者の稼働実績を見ながら並行して立ち上げる、という二正面での漸進的展開が推奨されている。

報酬体系（依頼者確認済み・2026-08-11、詳細未確定）：2名の報酬体系について、依頼者から「3人で（収益を）割るが、ある程度は歩合」との回答を得ている。役割未定の人員をベースケースにキャパシティとして単純加算しない方針に加え、報酬自体が固定給ではなく歩合制であるため、人件費は「収益に連動する変動費」として扱う方が正確なモデルとされる。固定分と歩合分の具体的な比率、歩合の算定方法（成約件数ベースか、担当顧客の売上ベースか等）は本計画書時点で未確定であり、第9章の損益計算は「事業全体の収益・費用」として示し、依頼者個人の手取りへの配分は別途、依頼者側で確定した配分ルールに基づいて計算する運用とする。

7.5 社内チャンピオン育成の手順（概要）

design/S1-service.md 4章は、ブリーフの核心課題（「導入が失敗する主因は品質ではなく使う人がいないこと。初回構築の真のゴールは社内チャンピオンを1人作ること」）を、初期構築フェーズの「導入・社内チャンピオン育成：5時間（標準）／8時間（保守）」という限られた工数枠の中で実現するための手順として、以下を定義している（詳細は第4章4.6節）。

選定基準：対象業務との近さ、変化への態度（自嘲的発言はシグナル）、社内での影響力・継続性、定着への意志
選定タイミング：訪問1回目で候補を仮リストとして観察記録に残し、訪問2回目で経営者・現場双方に確認する。経営者の推薦と現場の実態がズレる場合は現場の実態を優先する【仮説・要検証】
巻き込み方：独立工程として最後にまとめて行うのではなく、初期構築フェーズ全体に薄く埋め込む設計。関係構築や動機づけに割ける時間はごくわずかという制約がある【仮説・要確認】
引き継ぎ手順：操作マニュアルの手渡し、トラブル共有、連絡ルートの明確化、リモートログ観察の同意取得

design/S1-service.md 6章は、この工数枠の妥当性そのものを未検証事項として扱っており、最初の2〜3社のパイロットでチャンピオンの定着度を継続支援フェーズのログで確認することを推奨している。

7.6 実施体制のまとめ

項目	ベースケース	拡張シナリオ（3名同一役割）
稼働人員	依頼者1名・週30時間	依頼者＋2名（東京・大阪）、各週30時間【仮説】
事業全体のWIP上限（初期構築）	2社	理論上6社（顧客専属制前提）【仮説】
継続支援の同時保有上限	標準3〜4社／保守1.8〜2社	標準約9〜12社【仮説】
報酬体系	―	収益按分＋歩合、配分比率は未確定
検証状況	S3・S1の設計基準	大阪拠点の稼働実績は未検証。実測を待って更新

8. 技術アーキテクチャと横展開設計

参照元：design/S4-architecture.md 全体

8.1 全体方針

design/S4-architecture.mdは、D-4（技術スタックの固定）の暫定推奨（2〜3本の型、自社ホスト、ノーコードフル活用）を実装レベルの標準スタックとして固定したものである。要点は以下の通り。

論点	結論
スタック本数	3本の型（型A/B/C）に固定。案件ごとの都度選定は行わない
ホスト先	全型とも自社契約のクラウド上にホスト。顧客側には何もインストールさせない
開発方式	ノーコード・ローコード中心。フルスクラッチ開発は行わない
リモート観察	汎用PC監視ツールは不採用。業務アプリ自体の利用ログのみ取得する限定範囲設計
顧客への説明	「銀行の貸金庫」比喩を用いた定型スクリプトで統一する

8.2 型A/B/Cの定義

新規案件で最初に行うのは「技術選定」ではなく「どの型に当てはまるかの判定」である。

型	対象業務の性質	中核ツール
型A：データ集約・可視化系	散在するデータを1箇所に集め、状態を一覧で見えるようにしたい業務	kintone または Googleスプレッドシート＋Looker Studio、UI層にGlide/Softr
型B：定型帳票の自動生成系	請求書・日報・発注書等、決まった様式の書類を毎日・毎週作っている業務	Google Workspace（ドキュメント/スプレッドシート）＋Zapier/Make.com
型C：チャットベースの問い合わせ対応系	社内マニュアル・ルールを都度誰かに聞いている、または特定の人しか答えられない問い合わせ対応業務	Dify（セルフホスト）＋Claude API

選定基準（同席観察時のチェックリスト）：「今どこに何があるか分からない」が主訴なら型A、「同じ書類を毎回一から作っている」が主訴なら型B、「いつも同じことを聞かれる」「担当者しか答えられない」が主訴なら型C。

【推定】型A・Bは初回の「毎日発生する・特定の1人が明確に苦しんでいる」課題に該当しやすく、型Cは業務棚卸しが進み社内ルールが言語化された後段で導入する方が成立しやすいと考えられる（根拠：型Cは「答えの根拠となるルールブック」が既に構造化されていることを前提とするため）。1社の中で型A→型Cへと段階的に拡張する順序を標準の型展開パターンとする。初回契約では初期構築フェーズの工数（15時間）に収める都合上、1型に絞り込むことを原則とする。

主な価格帯【推定】（複数の二次情報記事に基づく概算、確認日：2026-08-11）：kintoneスタンダードコース1ユーザー月額1,980円（税込、最小契約10ユーザーから）、Glide月額$19〜、Softr月額$49〜、Zapier Professional月額$29.99〜、Make.com Core月額$10.59〜（年払い）、Dify OSS版は無料（サーバー代とAPI従量課金のみ）。いずれも一次情報での確認を推奨。

8.3 4層モデル（L1〜L4）：横展開の骨格

横展開を成立させるには、「何を固定し、何を可変にするか」をレイヤーごとに線引きする必要がある。

レイヤー	内容	固定/可変
L1: データモデルの骨格	エンティティ構造（顧客・案件・在庫等の基本オブジェクトとその関係）	固定。型A/B/Cごとに標準スキーマを持つ
L2: ワークフロー分岐	承認フロー、ステータス遷移、通知条件	半固定。標準パターンを3〜5種用意し、その中から選択
L3: UI文言・帳票フォーマット	画面上のラベル、帳票の見た目・自社ロゴ・項目の並び順	可変。顧客ごとに差し替える前提の層
L4: 業界固有の付加項目	業種特有の管理項目（例：賃貸管理なら物件番号、建設なら工程区分）	可変。L1の骨格に追加フィールドとして載せる

L1（固定）とL2（半固定）は選択・当てはめの作業であり新規設計ではないため、初期構築フェーズのアプリ構築工数（15時間）の中で実際に時間を消費するのは主にL3（UI文言・帳票の調整）とL4（業界固有項目の追加）である。この設計により「何を作るか」を毎回考える時間をなくし、「何を当てはめ、何を調整するか」の判断作業に工数を集約させることが、S3の工数枠に収める前提条件になっている。

【推定】この4層モデルが機能しない場合（顧客ごとにL1・L2まで作り変える必要が生じる場合）、初期構築工数は保守シナリオの69時間すら超過するリスクがある（L1・L2の再設計はゼロベースの要件定義に近く、S3が計上する「情報整理・要件定義10時間」の枠を大きく超える作業になりうるため）。したがって型の選定基準を厳格に運用し、L1が合わない業務には無理に型を当てはめないことを運用ルールとする（このリスクは第10章R-4×R-11で継続的に管理する）。

8.4 テンプレート再利用の仕組み（1社目→2社目の具体的手順）

型A：kintoneアプリを「アプリのコピー作成」機能でテンプレート化し、テンプレート用スペースに保管。2社目着手時は複製してL3・L4のみ調整する。スプレッドシート版はGoogleドライブ上のマスターテンプレートフォルダから複製する。Glide/Softrは「アプリの複製」機能でUI構成ごとコピーし、データソース接続先のみ差し替える。
型B：帳票テンプレートを型別（請求書型・日報集計型・発注書型）に共有ドライブへライブラリ化する。Make.comは「シナリオのテンプレート化（Blueprint）」または「シナリオの複製」、Zapierは「Zapの共有・複製」機能で再利用する。日付フォーマット変換・消費税計算等の共通部品は「サブシナリオ」やGoogle Apps Scriptの共通関数として切り出し、複数顧客から呼び出す構成にする。
型C：Difyの「アプリの複製（DSLファイルのエクスポート/インポート）」でチャットフロー全体を2社目に複製し、RAGのナレッジベースのみ顧客固有のものに差し替える。VPSは1台で複数顧客アプリを同居させられるため、2社目以降はVPSの追加セットアップが不要になり、これが「2社目以降は5時間以下に圧縮できる」根拠となる。

自社の共有ドライブ内にtemplate/フォルダを設け、型ごとのマスターテンプレートを1箇所に集約する運用を標準とする。【仮説】この運用が機能するかは、実際に3社目・4社目を獲得した段階で検証が必要であり、1社目・2社目の時点では差分の傾向がまだ見えないため、テンプレート更新の判断は保留し、まず記録を蓄積することを優先する。

8.5 データの持ち方・セキュリティ・顧客説明（貸金庫の比喩）

D-4確定事項の通り、型A/B/Cすべてを自社契約のクラウド上にホストし、顧客側には何もインストールさせない。顧客はブラウザまたはLINE/Slack等のUIからアクセスするのみ。

低ITリテラシー層への説明において、「クラウド」「サーバー」「セキュリティ」という言葉自体が不安を喚起しやすいため、以下の定型スクリプト（「銀行の貸金庫」比喩）を標準の説明材料とする。

「皆さんの大事な情報（お客様の名簿や日々の記録）は、私たちが契約している専用の金庫（サーバー）にしっかり保管します。銀行の貸金庫と同じイメージです。金庫は銀行（＝私たち）が管理していますが、中身は完全に皆さんのものです。皆さんは鍵（IDとパスワード）を持っていて、いつでも自分のパソコンやスマホから中身を見たり出し入れしたりできます。ただし、その金庫の中身が外部の他の会社に見られたり渡ったりすることは一切ありません。もし契約が終わるときは、金庫の中身を全部まとめてお返しします。」

アクセス権限は顧客側「閲覧のみ／入力可／管理者」の3段階、自社側は顧客ごとに論理的に分離されたアクセス権を基本とする。契約終了時は型ごとに定めたエクスポート形式でデータを返却し（型A：CSV/Excelまたは環境移管、型B：Googleドライブ成果物一式の移管、型C：ナレッジベース原本・会話ログの提供、チャットフロー自体は自社資産として非対象）、第5章5.3節で確定した「契約終了時に所有権を譲渡し凍結」の運用と、第5章5.5節の有償オプション（環境移設・独自環境構築代行）を実務的に実行する構成になっている。自社側の顧客専用領域は一定期間（例：3ヶ月）保持後に削除する。【要確認】Claude APIのデータ取り扱いポリシー（学習利用の有無、保持期間）は契約時点の最新の公式情報を都度確認する必要があり、本書では確定情報として扱わない。バックアップ・障害対応のSLAは月額稼働上限との整合を取る必要があり、契約書上は「ベストエフォート」を基本とする【要確認】。

8.6 リモートログ観察の技術的実現方法

汎用PC操作監視ツール（キーロガー・画面録画・全アプリ使用状況の常時監視）は採用しない。代わりに、型A/B/Cとして自社が構築した業務アプリ自体の利用ログに限定して取得する、という限定範囲設計を取る（第4章4.7節の取得範囲と対応）。

取得する	取得しない
型A/B/Cアプリへのログイン日時・ログインユーザー	PC全体の操作ログ（キーロガー、画面録画）
アプリ内でどの機能を使ったか	アプリ外のブラウザ閲覧履歴、他アプリの利用状況
アプリ内でのエラー発生箇所・エラー内容	業務時間外・アプリ未使用時のPC状態全般
アプリに入力されたデータの傾向	個人所有デバイス・私的LINEアカウント等
型Cのチャット質問文そのもの（回答改善のため）	型C以外のチャット・メール・電話等の私的コミュニケーション内容

技術的な実現手段は、各ツールが標準搭載するログ機能の活用にとどめる（型A：kintoneの操作履歴・Glide/Softrのアナリティクス、型B：Make.com/Zapierの実行履歴・Googleドキュメントの編集履歴、型C：Difyの会話ログ・利用状況ダッシュボード）。別途キーロガーや画面監視ソフトを追加導入する設計にはしない。

プライバシー配慮の運用手順として、(1) 移行の儀式化（対面観察の最終回に、業務アプリの中の使われ方だけを見ること・パソコン全体やメール、LINEは見ないことを対面・口頭で明示し、社内チャンピオンを通じて他の従業員にも周知する）、(2) 就業規則・同意取得のひな形提供（取得範囲・利用目的・保管期間・第三者提供の有無を明記した1〜2ページの同意書兼周知文をテンプレート化）、(3) 個人評価に使わない旨の明文化（月次改善提案は個人名でなくプロセス・機能を主語にした報告フォーマットに統一）、(4) 取得データの技術的限界の事前説明（「見えるのはパソコンの中でアプリを使った部分だけ」と契約時点で明示）、の4点を標準運用とする。

【事実】個人情報保護委員会は、モニタリングにあたり重要事項を定める際は労働組合等に通知・協議することが望ましいとしている（出典：https://www.ppc.go.jp/all_faq_index/faq1-q5-7/ 、確認日：2026-08-11）。【事実】従業員のPC操作ログ監視について、裁判例では「調査の必要性を欠く場合や、調査の態様が社会的に許容し得る限度を超えている場合には違法となることがある」と判断されている（出典：https://unitis.jp/articles/2692/ 、確認日：2026-08-11）。本設計は取得対象を業務アプリ内の利用ログに限定し、私的領域・全PC監視を明確に除外することで、これらのリスクを抑える設計意図を持つ（このリスクは第10章R-10で継続的に管理する）。

9. 収支計画（3年）とKPI

参照元：design/S3-financials.md 全体、design/S2-pricing.md（単価根拠）

9.1 この章の位置づけと前提となる制約

design/S3-financials.mdは12ヶ月の計画までしか作成されていない。本計画書は3年収支を求められているが、S3にない新しい数値を作文することはブリーフの禁則事項（「都合のいい前提で収支を作らない」「保守シナリオを必ず先に作る」）に反するため行わない。したがって本章は以下の構成を取る。

1年目（9.2〜9.5節）：design/S3-financials.mdの保守・標準・強気の3シナリオをそのまま整理する。数字は変更しない。
2〜3年目（9.6節）：「1年目の実測に基づき検証する」ことを明記した上で、S3が既に示す構造（WIP上限、拡張シナリオの仮定、報酬体系未確定等）を踏まえた参考レンジのみを示す。断定的な新規数値は作らない。
KPI（9.7節）：S3・S2で示された指標を整理する。

design/S3-financials.md冒頭の設計思想（「この事業の初年度の生死を分けるのは『工数精度』ではなく『獲得ペース×初期構築の同時並行数（WIP）上限』である。保守シナリオはこの2点を最も厳しく振る」）を本章全体の前提として維持する。

9.2 1社あたり工数モデル（仮置き・要実測更新）

初期構築フェーズ（初期費用50万円に対応）：契約後40時間（保守61時間）。継続支援フェーズ（月額10万円に対応）：標準7時間/月（保守13時間/月）。詳細は第7章7.2節の表を参照。

同時並行数（WIP）の上限：初期構築フェーズは同時2社が上限（第7章7.3節）。

保守シナリオでは継続フェーズの工数が7→13時間に膨らみ、月額10万円の時間単価は約14,300円/時から約7,700円/時に低下する。初期費用の時間単価根拠は50万円÷40時間＝12,500円/時であり、超過時間の課金単価もこれと同一単価（約12,500円/時）に確定している（第5章5.2節）。

9.3 12ヶ月時点での保有社数（3シナリオ）

保守シナリオを先に示す。

シナリオ	前提	12ヶ月時点の継続契約社数（見立て）
保守	獲得ペース：初月〜3ヶ月は0社（営業基盤構築期間）、4ヶ月目以降1.5〜2ヶ月に1社ペース。工数は保守シナリオ（69h/13h）。解約率：年間で1社離脱を仮定	3〜4社
標準	獲得ペース：初月〜2ヶ月は0社、3ヶ月目以降1ヶ月に1社弱ペース。工数は標準シナリオ（45h/7h）。解約率：年間で1社離脱を仮定	6〜7社
強気	獲得ペース：初月から月1社ペースで安定獲得。工数は標準シナリオ。解約なし	10〜11社（参考値。下記参照）

強気シナリオの非現実性について（必ず明記）：強気シナリオは、初期構築フェーズのWIP上限（同時2社までしか進められない）と数学的に矛盾する。月1社ペースでの新規獲得を12ヶ月続けるには、依頼者1人体制では物理的に不可能である。design/S3-financials.mdはこれを「強気シナリオの非現実性を示す参考値として記載」と明記し、意思決定の根拠として使うべきではないとしている。この矛盾自体が「強気シナリオは1人体制では成立しない」という発見であり、拡張シナリオ（3名体制）を検討すべき閾値の目安になる。

9.4 12ヶ月累計収益（3シナリオ）

保守シナリオ（3〜4社、獲得は4ヶ月目以降ゆっくり）

初期費用収入：3社×50万円＝150万円（獲得タイミングがバラつくため単純合算）
月額収入：契約期間の積み上げ（1社目5ヶ月目〜、2社目7ヶ月目〜、3社目9ヶ月目〜、と仮定）×10万円≈累計60〜80万円程度
12ヶ月累計収益：約210〜230万円

標準シナリオ（6〜7社）

初期費用収入：6社×50万円＝300万円
月額収入：獲得タイミングの積み上げで累計150〜200万円程度
12ヶ月累計収益：約450〜500万円

強気シナリオ（参考値・非現実的）

参考値として、初期費用500〜550万円＋月額収入300万円程度で12ヶ月累計800万円超となるが、この前提自体が1人体制では成立しないため、意思決定の根拠として使うべきではない。

9.5 固定費・単純損益（1年目）

【要確認】依頼者からの詳細情報が必要な項目を含む仮置き数値。

項目	月額（仮置き）	備考
自社ホストのランニングコスト（SaaS利用料、AI API利用料）	3〜5万円	依頼者はAI利用コストと内部稼働費用程度と許容度を回答済み
通信・移動費（域内移動のみ）	1〜2万円	大阪常駐者がいるため東京・大阪間の出張移動は発生しない前提
その他販管費（会計・法務・保険等）	3万円	概算
月額固定費合計（仮置き）	7〜10万円

12ヶ月累計固定費：約100〜160万円

シナリオ	12ヶ月累計収益	12ヶ月累計固定費	単純差引
保守	210〜230万円	100〜160万円	約50〜130万円
標準	450〜500万円	100〜160万円	約290〜400万円

この差引は依頼者自身の報酬（生活費相当分）を含まない。 依頼者の時間（週30時間×12ヶ月）に対する実質時給換算をすると、保守シナリオでは時給換算1,000円台〜という非常に低い水準になる可能性が高い。

依頼者からは「生活費については他事業の収入で当面はカバーできる」との回答を得ている一方、「事業の黒字化は必須」との回答もある。この2つの回答を踏まえ、「生活費は他事業でカバーできるが、この事業自体は独立採算で黒字化を目指す。本事業の独立採算化が中期的な目標」という位置づけとして整理する。保守シナリオの水準（12ヶ月で50〜130万円の単純差引）が「事業として許容できる最低ライン」かどうかは、他事業とのリソース配分判断も絡むため本計画書では断定しない。

9.6 2〜3年目：1年目の実測に基づき検証する外挿シナリオ

2〜3年目の断定的な数値は作成しない。 design/S3-financials.mdは12ヶ月の計画までしか作成しておらず、2〜3年目について新たな獲得ペース・保有社数を新規に仮定することはブリーフの原則（既存文書の統合であり新しい数字を作らない）に反する。したがって、2〜3年目は以下の位置づけとする。

位置づけ：1年目（保守・標準いずれのシナリオに実際に着地するか）の実測データをもって、2〜3年目の計画を検証・確定する。特に「1社あたり工数（40〜61時間、継続7〜13時間/月）」はS3自身が「仮置き・要実測更新」と明記しており、2〜3年目の計画はこの実測更新を経て初めて意味を持つ。

参考レンジとして示せる構造（S3が既に示している範囲内）：1年目の着地点から、WIP拡張（第7章で述べた3名体制の本格稼働）が実現した場合、事業規模がどの構造で拡張しうるかは、design/S3-financials.md 6章がすでに示している。ここでは新しい仮定を追加せず、6章の構造をそのまま参考情報として引用する。

WIP上限の構造：1人あたり初期構築フェーズの同時並行上限は2社。3名が同一役割・同一稼働時間で動けるという強い仮定に立てば、事業全体のWIP上限は理論上6社まで拡張できると推定される（【仮説】）。
継続支援の同時保有上限（3名体制・標準シナリオ）：約9〜12社（3〜4社×3名）という試算が示されている。ただし「3名が依頼者と同じ稼働時間・生産性で動ける」という強い仮定であり、大阪拠点の共同事業者の稼働実績は未検証である。
留保事項：顧客専属制（1社を1人が最初から最後まで担当する運用）が現実的な前提とされている。地理的役割分担（東京・大阪）による効率化も、大阪常駐者の稼働開始タイミング次第という留保が付く。報酬体系（3人で収益を割るが歩合も含む）の具体的配分比率は未確定であり、依頼者個人の手取りへの配分は本計画書では計算していない。

この構造から導ける参考レンジの示し方：上記の理論上のWIP上限（1人2社→3名で6社、継続支援9〜12社）が仮に2〜3年目にかけて段階的に実現していく場合、1年目の標準シナリオ（12ヶ月で6〜7社）を上回る規模に拡張する余地があること自体はS3の構造から読み取れる。しかし、具体的に「2年目は何社・何円」という数値は、S3に存在しないため本計画書でも作成しない。2〜3年目の数値計画は、1年目の実測（特に3社目までのパイロットで得られる工数実測値・大阪拠点の稼働実績・報酬体系の確定）を踏まえて、別途策定する必要がある。

不確実性として必ず併記すべき事項

大阪拠点の稼働実績が未検証であること（3名同一役割モデルの前提そのものが検証途上）
報酬体系（歩合の配分比率）が未確定であり、3名体制の経済合理性が確定していないこと
1社あたり工数（40〜61時間、7〜13時間/月）自体が「仮置き」であり、1年目のパイロット3〜5社で更新される可能性があること
強気シナリオがWIP制約と矛盾するのと同様、3名体制の理論上の拡張（6社・9〜12社）も、顧客専属制・地理分担が実際に機能するかどうかで大きく変動しうること

9.7 KPI

KPI	定義・算出根拠
同時保有社数（初期構築）	WIP上限2社（1人あたり）。事業全体は拡張シナリオで理論上6社【仮説】
同時保有社数（継続支援）	標準3〜4社、保守1.8〜2社（1人あたり）
獲得ペース	保守：4ヶ月目以降1.5〜2ヶ月に1社／標準：3ヶ月目以降1ヶ月弱に1社／強気：初月から月1社（非現実的参考値）
年間解約率	保守・標準ともに年間1社離脱を仮定
初期費用の時間単価	50万円÷40時間＝12,500円/時
継続支援の時間単価	標準：約14,300円/時（7時間/月）→保守：約7,700円/時（13時間/月）に低下
超過時間の課金単価	自社基本単価と同一単価（約12,500円/時）
稼働上限（契約書上）	月8時間（社内実行目標は7時間、バッファ1時間）
最低契約期間	6ヶ月
12ヶ月累計固定費	約100〜160万円

9.8 感度分析の前提一覧

パラメータ	保守	標準	強気（参考・非現実的）
初期構築工数/社	69時間	45時間	45時間
継続支援工数/社・月	13時間	7時間	7時間
獲得開始までの営業基盤構築期間	3ヶ月	2ヶ月	0ヶ月
獲得ペース（基盤構築後）	1.5〜2ヶ月に1社	1ヶ月弱に1社	1ヶ月に1社
年間解約	1社	1社	0社
WIP上限との整合性	整合	整合（ギリギリ）	矛盾（非現実的）

【事実】単価（初期50万・月額10万）は保守シナリオでも下げていない。値下げは不確実性ではなく意思決定であるため、工数・獲得ペース・解約という「コントロールできない変数」と混ぜていない。

9.9 未決事項

2名（特に大阪拠点の共同事業者）の具体的な稼働開始タイミング【要確認】
大阪拠点への訪問頻度（通信・移動費の見積もり精度に影響）【要確認】
1社あたり工数（40時間/61時間という仮置き数値）は、最初の2〜3社の実測データで必ず更新すること【要確認】
2名の報酬体系（固定分と歩合分の具体的比率、歩合の算定基準）【要確認】

10. リスクと対応方針

参照元：design/S6-risks.md 全体（R-1〜R-12、リスク間の連動関係）

design/S6-risks.mdは、ブリーフが指定する7項目に加え、D7課題深堀り・R5 FDE事例調査・R2業種プロファイリングで洗い出された追加リスクを統合した12項目のリスク登録簿である。発生確率・影響度は「高／中／低」の主観評価であり、依頼者の構想を守るための希望的観測を排し、率直な深刻度評価を行う方針を取っている。

10.1 リスク一覧

No.	リスク名	発生確率	影響度	分類
R-1	月10万で青天井の要求が来る	高	高	契約・稼働設計
R-2	属人化（依頼者が動けなくなったら止まる）	高	高	体制
R-3	1社目が取れない	中	高	営業・獲得
R-4	業種を絞りきれず横展開が効かない	中	高	事業設計
R-5	既存4事業との時間衝突	高	中	体制
R-6	顧客の廃業・承継による契約消滅	中	中	外部環境
R-7	生成AIの進化により「代理のAI人材」の価値が陳腐化	中	高	事業モデル
R-8	保守シナリオで生活費を賄えない	高	高	収益性
R-9	強気の成長シナリオがWIP制約と数学的に矛盾する	高（確定した構造的事実）	高	成長設計
R-10	リモートPC作業ログ観察が「監視されている」心理的抵抗を招く	中〜高	中〜高	サービス設計・信頼
R-11	高単価SESへの退化（プロダクト・型を持たないまま個別対応を続ける）	高	高	事業モデル
R-12	ターゲット層の多くが「そもそも必要性を感じていない」層で営業効率が悪化	高	高	営業・獲得

10.2 重要リスクの詳細

R-8：保守シナリオで生活費を賄えない可能性

第9章9.5節に明記した通り、保守シナリオでの12ヶ月累計の単純差引は約50〜130万円であり、依頼者自身の報酬を含まない。週30時間×12ヶ月の労働に対するリターンとして時給換算すると非常に低い水準（時給換算1,000円台〜）になる可能性が高い。依頼者は「この事業の黒字化必須度」を「必須」と回答しており、保守シナリオの帰結と正面から緊張関係にある。

対応策：(1) 依頼者自身の「生活費として必要な最低月額」を数値で確定させる、(2) 既存事業（インフォバーン業務委託等）でどこまで補填できるかを試算し、本事業を独立採算とするか併走型とするかを依頼者に明示的に選択してもらう、(3) 最初の2〜3社を工数実測のパイロットと位置づけ、実測が保守シナリオに近い場合は即座に価格・契約設計の見直し検討に入る、(4) 200万円という追加投資上限が保守シナリオの初期赤字を吸収しきれるかを月次で突き合わせる。design/S6-risks.mdは「6ヶ月時点で資金残高が上限の50%を切った場合は事業継続の可否を撤退基準（D-6、未確定）に照らして再検討する」という対応策を示しているが、これは撤退基準そのものの依頼者最終決定ではなく、S6が示す考え方の例示である（詳細は第12章）。

R-9：強気の成長シナリオがWIP制約と数学的に矛盾する

強気シナリオ（月1社ペースで安定獲得）は、初期構築フェーズのWIP上限（同時2社まで）と数学的に矛盾する。これは不確実性ではなく確定した算数上の矛盾であり、design/S3-financials.md自身が「非現実性を示す参考値」と明記している。この矛盾を認識しないまま融資申請等の前提に強気シナリオの数字を使うと、実現不可能な計画に基づく意思決定をしてしまう。

対応策：(1) 融資申請・事業計画書では強気シナリオの数字を主要な前提として使わず、保守・標準シナリオのみを意思決定の根拠とする、(2) 継続契約社数が5〜6社に達し新規の初期構築を受けられない状態が続いた時点を拡張トリガーとして契約管理表に組み込む、(3) WIP上限2社を超える新規契約は無理に受注せず「次の空き枠まで◯ヶ月待ち」という運用ルールを明文化する、(4) 2名の役割・稼働開始タイミング・報酬体系を早期に確定させる。

R-4×R-11：業種絞り込み不足とSES化（表裏一体のリスク）

R-4（業種を絞りきれず横展開が効かないリスク）とR-11（高単価SESへの退化リスク）は表裏一体の関係にある。R-11の根拠は、design/S6-risks.mdが引用するresearch/R5-fde-cases.mdの指摘（「Palantirの成功の本質はエンジニアを客先に置くことではなく、そこで構築される信頼関係を通じて自社プロダクトの契約拡大につなげる点にある」「プロダクトを持たない企業がFDEの働き方だけを真似ると、高単価を狙ったSES（客先常駐の人材派遣）に退化するリスクがある」）であり、これは依頼者の現在の事業構想（再利用可能な自社プロダクトを持たない受託構築に近い形態）に直接当てはまる。R-4が現実化した場合、R-11はほぼ確実に顕在化する。

予兆シグナル：顧客ごとに使う技術スタック・実装方法が毎回異なり第8章の「2〜3本の型」に収まらない案件が半数を超える／案件が増えるほど初期構築工数が短縮されるどころか横ばい・増加する／顧客から見て提供物が明確な製品・パッケージではなく「あの人（依頼者）が来てやってくれること」としてしか認識されない。

対応策：(1) 業種を早期に2〜3業種へ絞り込み、第8章の「型」を業種内での再利用性を優先して設計する、(2) 案件ごとの工数実績を記録し、3社目以降で初期構築工数が短縮されているかを定量的に確認する、(3) 案件受注時に「今回はどの型の何を再利用し、何を新規に作るか」を明示的に切り分けて記録する、(4) 単価設定を「稼働時間の切り売り」ではなく「型・テンプレートの提供＋個別カスタマイズ」という価値構造として顧客に説明できるよう契約設計・提案資料に明記する。

10.3 リスク間の連動関係

個別リスクとして独立に管理するのではなく、以下の連動を意識して優先対応すべき組み合わせがある。

R-8（生活費不足）×R-9（WIP矛盾）：両者ともS3が示す確定的な数値矛盾であり、希望的観測で緩和できない。事業の存続可否そのものに関わるため、他の全リスクに先立って依頼者に率直に共有すべき。
R-4（業種絞り込み不足）×R-11（SES退化）：一方が発生すればもう一方もほぼ確実に発生する表裏一体のリスク。業種絞り込みの意思決定を先送りするほど、SES化の予兆が後から発覚し手戻りが大きくなる。
R-1（青天井要求）×R-7（AI陳腐化）：短期的には要求が青天井になりやすく（R-1）、中長期的には顧客が自力でできるようになり価値提案が縮小する（R-7）。矛盾するようだが、いずれも「サービスの範囲・価値の輪郭が曖昧である」という同一の根本原因（プロダクト化不足）から生じている。
R-3（1社目が取れない）×R-12（必要性を感じない層）：R-12はR-3の主要な構造的原因の一つ。1社目が取れない場合、営業努力の量ではなくターゲット層の性質に原因がある可能性を先に疑うべき。
R-2（属人化）×R-5（既存事業との時間衝突）×R-9（WIP矛盾）：いずれも「依頼者1人に依存した設計」という同じ構造的脆弱性の別の現れ。3名体制の実質稼働開始（役割確定）が、この3リスクすべてに共通する最有力の緩和策になる。

10.4 その他のリスク（概要）

No.	リスク	対応策の要旨
R-1	月10万で青天井要求	契約書に時間上限・除外リストを明文化。月次稼働時間を顧客に開示。超過時は定型フレーズで即答せず別見積もり
R-2	属人化	ヒアリング記録の標準テンプレート化。他2名の役割を実装作業に固定し依頼者不在でも引き継げる分業構造を確立
R-3	1社目が取れない	紹介・既に助けを求めている先の2ルートに絞る。3ヶ月経過時点で有効商談0件なら機械的にレビュー
R-5	既存4事業との時間衝突	週次で実稼働時間を記録。既存事業の繁忙期と初期構築フェーズの重複を回避
R-6	顧客の廃業・承継	初回棚卸し時に後継者の有無・経営者年齢を必ずヒアリング。承継リスク高の顧客は最低契約期間や価格設計で対応
R-7	AI陳腐化	提供価値を「業務棚卸し・情報整理という零細企業が自力ではできない工程」に軸足を置く。年1回、代替可能性を棚卸し
R-10	リモート監視への心理的抵抗	第8章8.6節の同意書・儀式化・個人評価に使わない旨の明文化を徹底
R-12	必要性を感じていない層	「すでに助けを求めている」層に絞り、動機形成・啓蒙に工数を割かない

10.5 この文書の運用方針

design/S6-risks.mdは静的な一覧で終わらせず、価格・契約設計、収支計画、技術アーキテクチャの各設計文書と一体で運用する必要があるとしている（特にR-1・R-8・R-9は第9章の収支計画と、R-10は第7章・第8章のサービス設計と直接連動する）。「予兆となるシグナル」は契約社数が増えるにつれて実測データで検証・更新すべき仮説であり、最初の2〜3社のパイロット期間中にシグナル定義自体が正しかったかを見直すことが推奨されている。

11. M&A構想との統合シナリオ

参照元：design/S5-ma-integration.md 全体

本章は簡略版である。 decisions/00-agenda.mdのPhase 0確定事項として、D-1（事業の位置づけ）は「(a) 単体で自走するストック型事業」に確定しており、依頼者から明確に「M&Aは一旦考えない」との回答を得ている。したがって、ブリーフが当初想定していたM&A統合の詳細設計（支援先を買収候補として見るときの評価項目、支援→買収に移行する条件とタイミング、利益相反の扱い、買収先に支援モデルを適用する場合の設計）は、Phase 2では行っていない。

11.1 なぜ簡略版とするか

M&A構想が具体的に動いている場合に必要な詳細設計に工数をかけることは、Phase 0での依頼者の意思決定（M&Aを一旦考えない）と矛盾する。一方で、Phase 0でのFableとの壁打ちで得られた洞察（「(a)単体事業と(b)M&A前工程は対立する選択肢ではなく、支援活動を通じて信頼と内部情報を獲得するという同一ファネルを共有する」）は、将来M&A構想が再浮上した場合に備えて事業設計の中に"痕跡"を残しておく価値を示唆している。本章はその最小限の備えのみを記述する。

11.2 現時点での運用ルール（最小限）

支援活動とM&A検討の分離：今回の事業（AI業務改善支援）は、依頼者が別途検討している事業承継・スモールM&A構想とは完全に独立した意思決定・営業プロセスとして運営する。支援先企業に対して、営業活動中や契約期間中に買収を持ちかけることは、今回の設計では想定しない。

「痕跡」として残す設計判断（追加コストほぼゼロ）

業務棚卸しの記録様式（第4章のサービス設計）を、財務・組織構造の概況が自然と記録される形にしておく（将来M&AのDD初期段階で使える情報になりうる）
ヒアリング記録の構造化フォーマットに含まれる「後継者の有無」等の質問項目は、支援目的の範囲内で自然に聞ける内容に留め、M&A目的で深掘りしない

利益相反の予防線（最小限）：支援契約書の機密保持条項において、「取得した情報を、本契約の目的（業務改善支援）以外に利用しない」旨を明記することを推奨する。これは将来M&A構想が再燃した際に、既存の支援先に対して透明性のある形で改めて相談・開示するプロセスを取るための予防線である。

11.3 将来、M&A構想を再検討する場合のトリガー（参考情報）

以下のような状況になった場合は、M&A構想の統合設計を改めてPhase 2相当の作業として行うことが推奨される。

支援先企業から、経営者側が自発的に事業承継・売却の相談を持ちかけてきた場合
依頼者側でM&A構想が「12ヶ月以内に本気で買う」という具体的な時間軸に入った場合（この場合、業種の絞り込み自体をやり直す必要がある）

この場合、Phase 0のD-1で整理した「利益相反の扱い（隠すのではなく二枚看板を開示する）」の運用ルールを、具体的な契約書・トークスクリプトのレベルまで落とし込む作業が改めて必要になる。

11.4 未決事項

【要確認】依頼者のM&A構想の現在の進捗（Phase 0時点では「一旦考えない」だったが、事業計画書の最終化までに変化がないか確認が必要）。

12. マイルストーンと撤退基準

参照元：decisions/00-agenda.md D-6・末尾「Phase 0確定事項サマリー」、design/S3-financials.md（シナリオ整理）、design/S6-risks.md R-8・R-9

12.1 撤退基準：未決（依頼者の最終決定が必要）

D-6（撤退基準）は、Phase 0の時点で未確定のまま残っている。 decisions/00-agenda.mdの回答シートにおける依頼者の回答は以下の通りである。

D-6（撤退の時間軸・資金基準の粗い感覚）：稼働に対してのコスト感の問題 D-6（撤退の定義）：撤退の方向。詳細は未確定

decisions/00-agenda.md末尾の「Phase 0で未確定のまま残る項目」欄でも、D-6は「撤退の具体的な時間軸・金額基準」として明記されている。以下は未決であり、本計画書ではこれらを埋める作文を行わない。

何ヶ月以内に何社契約できなければ撤退するか（時間軸基準）
投下現金がいくらに達したら撤退するか（資金基準）
「撤退」の定義（完全停止か、稼働を大幅縮小して細々続けるか）
撤退した場合、蓄積した資産（テンプレ、顧客関係、業界知見）を何に転用するか

decisions/00-agenda.mdは、D-1の選択（単体ストック型事業に確定）によって撤退基準の意味が変わりうること、および「基準を『契約社数』と『資金』の両方で設定し、どちらか一方が先に達した時点で撤退検討に入る、という構造自体」は推奨するが、具体的な数値基準は依頼者の資金余力・時間軸に強く依存するため、Claude Codeからの一方的な提案は避けるとしている。この方針を本計画書でも維持する。

12.2 参考情報：S3シナリオに対応させた時系列マイルストーン案

以下は撤退基準そのものの決定ではなく、design/S3-financials.mdが既に示す数値を時系列に並べ直したものである。新規の断定的な数値は含まない。

時点	保守シナリオ	標準シナリオ	強気シナリオ（参考・非現実的）
3ヶ月時点	営業基盤構築期間中（契約0社の想定）	営業基盤構築期間中（契約0社の想定、2ヶ月で終了見込み）	月1社ペースで既に3社契約（WIP上限2社と矛盾）
6ヶ月時点	4ヶ月目以降1.5〜2ヶ月に1社ペースで獲得開始、1〜2社程度の見込み	3ヶ月目以降1ヶ月弱に1社ペースで獲得、3〜4社程度の見込み	6社契約想定（WIP矛盾のため非現実的）
12ヶ月時点	3〜4社（12ヶ月累計収益約210〜230万円）	6〜7社（12ヶ月累計収益約450〜500万円）	10〜11社（参考値。WIP上限2社と数学的に矛盾するため意思決定に使用しない）

上表は第9章で整理した数値の時系列整理であり、design/S3-financials.md「初月〜3ヶ月は0社」「4ヶ月目以降1.5〜2ヶ月に1社ペース」等の記述をそのまま時点別に配置したものである。この表自体は撤退基準ではなく、各シナリオが「いま何ヶ月目でどの水準にいるはずか」を判断するための参考の物差しに過ぎない。

12.3 参考情報：判断の目安となりうる要素（依頼者の最終決定ではない）

以下は、S3の分析・S6のリスク評価から導かれる「判断の目安」であり、撤退基準そのものの代わりにはならない。依頼者が今後D-6を確定する際の検討材料として位置づける。

(1) WIP制約との整合性

強気シナリオ（月1社ペースでの安定獲得）はWIP上限2社と数学的に矛盾する、という確定した構造的事実がある。仮に契約社数の伸びがこの強気シナリオの水準に近づいた場合、それは「順調」なのではなく「WIP上限を超えて無理な受注をしている」可能性を示すシグナルとして扱うべきである。逆に契約社数が保守シナリオの水準（12ヶ月で3〜4社）を大きく下回り続ける場合は、第9章で整理した保守・標準シナリオの前提（獲得ペース、営業基盤構築期間）自体が崩れている可能性がある。

(2) 生活費への依存度

依頼者は「生活費は他事業でカバー可能」と回答済みであり、本事業の収益不足が直ちに生活を脅かすものではないと確認されている。ただし「本事業の独立採算化が中期目標」という位置づけが同時に存在するため、保守シナリオの水準（12ヶ月で単純差引50〜130万円、依頼者報酬を含まない）が続く場合、それが「まだ立ち上げ期として許容範囲」なのか「独立採算化という中期目標から乖離している」のかの判断が、依頼者自身に委ねられている。

(3) design/S6-risks.md R-8対応策の位置づけについて（重要な区別）

design/S6-risks.mdのR-8（保守シナリオで生活費を賄えない）の対応策に、以下の記述がある。

「200万円という追加投資上限（Phase 0確定）が保守シナリオの初期赤字を吸収しきれるかを毎月のキャッシュフロー実績と突き合わせ、6ヶ月時点で資金残高が上限の50%を切った場合は事業継続の可否を撤退基準（D-6、未確定）に照らして再検討する。」

この記述は、依頼者が最終決定した撤退基準ではない。 S6が対応策の一例として示した考え方であり、D-6自体が「未確定」であることを同じ文の中で明示している。本計画書ではこれを参考情報として引用するに留め、確定した基準として扱わない。依頼者がD-6を確定させる際の検討材料の一つとして位置づける。

12.4 未決事項と参考情報の区別（総括）

区分	内容
未決（依頼者の最終決定が必要）	撤退の時間軸基準（何ヶ月で何社）、資金基準（いくらで撤退）、撤退の定義（完全停止か縮小継続か）、撤退時の資産転用先
参考情報（S3・S6の分析から導ける目安）	12.2節の時系列マイルストーン案（S3数値の時系列整理）、12.3節のWIP整合性・生活費依存度という判断軸、S6 R-8対応策の「6ヶ月時点で資金残高50%切り」という考え方の例示

D-6の確定には、design/S3-financials.md・design/S6-risks.mdがともに指摘する通り、まず1年目（特に最初の2〜3社のパイロット期間）の実測データが必要である。本計画書は、撤退基準を埋めるための作文を行わず、「未決」であることを明記した上で、判断材料となる参考情報を区別して提示するに留める。

付録：Phase 0〜3の成果物一覧

本計画書の根拠となった全成果物は以下に格納されている。

/Users/rxzibit/Desktop/me/18_fde/
├── fde-ai-jigyo-brief.md          # 依頼書
├── decisions/
│   └── 00-agenda.md                # Phase 0 意思決定ログ（確定事項サマリー含む）
├── research/
│   ├── R1-competitors.md           # 競合・相場調査
│   ├── R2-industries.md            # 10業種プロファイリング
│   ├── R3-public-programs.md       # 公的制度・登録要件調査
│   ├── R4-channels.md              # リード獲得チャネル検証
│   ├── R5-fde-cases.md             # FDEモデル参照事例調査
│   ├── D7-customer-pain-deepdive.md # 顧客課題深堀り
│   └── interview-guide.md          # ヒアリング設計（未実施・依頼者実行待ち）
├── design/
│   ├── S1-service.md               # サービス設計
│   ├── S2-pricing.md               # 価格・契約設計
│   ├── S3-financials.md            # 収支計画
│   ├── S4-architecture.md          # 技術アーキテクチャ
│   ├── S5-ma-integration.md        # M&A統合設計（簡略版）
│   └── S6-risks.md                 # リスク登録簿
└── deliverables/
    └── 事業計画書.md                # 本書

特筆すべき点：research/interview-guide.mdで設計されたヒアリング・同席観察は、本書執筆時点ではまだ実施されていない。本書の第3章（市場と顧客）・第4章（サービス設計）の一部仮説は、実地ヒアリングの結果を経て検証・更新される必要がある未検証部分を含む。特に「デモ→棚卸しフェーズへの移行が実際に起きるか」（interview-guide.md 仮説1）は、本事業の収益構造の心臓部に関わる最重要検証事項であり、Phase 3以降、最優先で着手することが推奨される。