← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 18:56
commonid: adr-0009type: adrstatus: accepted
pagemode: Critical (内容から推定・旧 README 一覧より移設)kruchten: Executivescope: corporateimplementation_status: Partial (Phase 1-2 実装済、活動領域分離は段階的)business: corp
型付き辺: 出 3 / 入 1
関連: ADR-0007 ADR-0019 ADR-0008 細分化された: ADR-0013全体は INDEX →

ADR-0009: 活動領域 (R&D / 自社運営 / プロダクト開発 / 商用運用) の段階的分離戦略

  • Status: Accepted (旧形式「## ステータス: 採用済み」より転記)
  • Mode: Critical (内容から推定・旧 README 一覧より移設)
  • Kruchten Type: Executive
  • Scope: corporate
  • Implementation Status: Partial (Phase 1-2 実装済、活動領域分離は段階的)

Kruchten Type は ADR-0031 (2026-05-13) で遡及追加。分類根拠は ADR-0031 §決定セクションおよび docs/adr/README.md の Kruchten 3 分類ガイドを参照。 Status / Mode / Scope は 2026-06-11 に遡及追加 (ADR-0031 corrigendum パターン)。出典: Status = 旧形式「## ステータス」節の機械転記 / Mode = 旧 README §既存 ADR 一覧の推定値 (git 履歴) / Scope = ADR-0049 4 層分類の遡及付与 (PR レビューで確定)。

ステータス: 採用済み (2026-04-20)

コンテキスト

bizlp-gas-accounting プロジェクトは、株式会社ビズリンクパートナーズ (bizlp) の社内管理会計ツールとして開発されてきたが、3〜12 ヶ月以内に SaaS 型プロダクトとして商用展開する計画がある。

bizlp の収益構造 (重要な前提)

bizlp は代表 1 名体制・資本金 300 万円・設立初年度。初年度売上 1,500 万円は 100% がクライアントワーク (受託業務) で発生しており、bizlp-gas-accounting プロジェクト自体は現時点で売上ゼロの R&D 投資として位置付けられている。

  • 代表者の労働時間は、メインがクライアントワーク (顧客貸与 PC で実施、bizlp アカウントではログインしない) で、空き時間で bizlp-gas-accounting を R&D している構造
  • bizlp-gas-accounting は将来の SaaS プロダクト化を見据えた自己投資的な試験研究活動
  • 消費税は設立初年度特例により免税事業者 (2 年目以降は売上規模により課税事業者移行の可能性)

活動領域 (6 領域)

現状、以下の領域のうち A〜D が単一の環境 (dev スプレッドシート + 単一 GitHub リポジトリ + 単一 GCP プロジェクト) で混在している。F は別環境 (顧客貸与 PC・bizlp アカウント外) で完全分離済み。

  • A: 法人運営 (bizlp 社内業務の実データ)
  • B: 自社会計システムの運用 (A をシステム化したもの)
  • C: プロダクト開発 (コード・仕様書)
  • D: R&D (新機能・新技術の実験)
  • E: (将来) 商用プロダクト運用 (顧客データ処理)
  • F: クライアントワーク (顧客貸与 PC での受託業務。bizlp の主力収益事業、R&D ではない)

今後の展望として、自社運用 (A/B) と商用化 (E) は並行で永続的に継続する (γ パターン)。bizlp は長期的に自社システムを使い続けつつ、他社向けに SaaS として提供する。F (クライアントワーク) も当面は主力収益として継続する前提。

この状況下で、(1) 混在状態に伴うガバナンスリスクの解消、(2) 日本の研究開発税制 (試験研究費の税額控除) の活用、(3) 商用化時の顧客データ隔離、を同時に満たす環境分離戦略を定める必要が出てきた。

本 ADR の執筆前に、Gemini Pro に第三者意見を求めた。相談プロンプトと回答は docs/_internal/biz/ADR-0009_separation_consultation_prompt.md / _result.md に保管してある。

決定

1. 4 フェーズ構造

活動領域の分離は物理分離ではなく段階的アプローチで進める。

フェーズ期間主な状態分離レベル
Phase 1現在 (2026-04〜)D (R&D) 主、A/B はテストケース、99% dev 利用物理分離なし、運用規律と文書化のみ
Phase 2bizlp 自社本格運用開始B 本格稼働、dev → prod 移行現行の dev/prod 分離で対応
Phase 3初 PoC / 商用化時E 並行開始、商用テナント新設別 GCP プロジェクト or 分離組織、顧客データ物理分離
Phase 4成熟期 (IPO 準備 / SOC2 取得等)フル分離R&D サンドボックス分離、ゼロトラスト構成

2. コードベース戦略

現時点では 「α. モノリス共有」を維持し、設計思想としては 「γ. マルチテナント化」を志向する。代表 1 名体制で複数コードベースを保守することは不可能。

Phase 3 の商用展開方式 は、フリート管理型 (clasp + GitHub Actions で 1 コードベースを顧客別 GAS/Sheets に一斉デプロイ) を最有力候補として採用する。これにより、マルチテナントの保守性とシングルテナントの堅牢性 (GAS 6 分制限・セル数上限・実行権限の壁を回避) を両立する。

3. テナント抽象化の設計規律 (Phase 1 から実施)

bizlp 本体も「テナント T-001」に過ぎないという抽象化を今から徹底する。

  • スプレッドシート ID・bizlp 固有判定条件・固有マスタをコードにハードコードしない
  • 設定値は Env モジュール / 03_sys_params / 環境変数に外出しする
  • 既存コードの中で bizlp 固有に密結合している箇所は、順次リファクタリングでテナント抽象化する

4. Phase 1 で今実施する「運用規律」

物理分離は行わないが、以下を今から実施する。

  1. R&D 活動の位置付けを ADR-0009 (本文) で明文化 — 税務調査・監査時の主張根拠
  2. git log / 仕様書 / ADR を R&D 活動証跡として扱う運用ルール — 「エンジニアリングの生の実態」そのものが証跡
  3. タイムトラッキング (Toggl Track 等) の導入 — 代表者の C/D (R&D・コーディング) / A/B (経理・一般管理) / F (クライアントワーク) の時間配分を客観記録。bizlp の売上 100% がクライアントワーク (F) である以上、F 時間の正確な記録なくして R&D 比率・役員報酬按分は主張できない。研究開発税制の役員報酬按分における唯一かつ必須のエビデンス
  4. 試験研究費の勘定科目分離 — API 利用料 / 開発ツール代は会計上「試験研究費」として独立集計し、通常の販管費と明確に分離

5. Phase 1 で実施しないこと

Gemini コンサルテーションにより、以下は現段階では非推奨と確認された。オーバーエンジニアリング回避のため実施しない。

  • 稟議書テンプレに R&D 位置付け欄を追加しない — 代表 1 名で自身に稟議する行為は、税務調査時「実態のない仮装行為 (お手盛り)」と見透かされる
  • SaaS・AI 経費規程に R&D 費区分ルールを詳細追加しない — 形式的ペーパーワークにリソースを割くべきでない。勘定科目統一ルール (上記 #4) で十分
  • 重厚な内部規程類 (経費規程・情報セキュリティ基本方針等) の早期整備 — 従業員雇用 / 初 PoC 契約 (Phase 3) まで不要

6. ガバナンス方針: 発見的統制への全振り

代表 1 名体制では、予防的統制 (職務分離: Segregation of Duties) は物理的に不可能。これを正面から認め、発見的統制 (代替的コントロール) でガバナンスを効かせる。

主張ロジック:

  • 職務分離は不可能だが、GAS 実行ログ / Git コミット履歴 / スプレッドシートの変更履歴 / 監査ログ (98_audit_log) がクラウド上に改ざん不可能な状態で 100% 残る
  • 事後的な追跡可能性で完全にカバーされる
  • MAS-213 (監査ログ保護) + MAS-205 (MFA・特権アカウント分離) の実装で改ざん耐性を強化

7. Phase 3 のデッドライン要件

商用化 (E) 開始前に必ず完了すべき事項:

  1. Vertex AI への完全移行 (ADR-0008 と整合、TODO: MAS-216)
  2. 利用規約 (ToS) — ダウンタイム免責、損害賠償上限の限定条項
  3. プライバシーポリシー — AI への顧客データ送信のオプトイン取得、R&D 目的のデータ利用同意
  4. 情報セキュリティ基本方針 — 顧客情シス部門向け 1 ページホワイトペーパー (「1 名だが GCP/Workspace エンタープライズ基盤で堅牢」)
  5. GCP プロジェクト分離 (TODO: MAS-215)
  6. 顧客別 GAS プロジェクト / スプレッドシート環境 + フリート管理デプロイ基盤

理由

  1. 小規模法人のリソース配分として段階的アプローチが適切 — PMF 前から完璧な分離基盤を作ることはスタートアップにとって致命傷。まず自社課題解決に集中
  2. 研究開発税制の最大活用 — 試験研究費が売上の 10% (150 万円) を超えれば「高水準要件」で中小企業技術基盤強化税制 (最大 17% 控除 + 上乗せ) が適用可能。bizlp の売上は 100% クライアントワーク (F) で発生しており、R&D 費は役員報酬按分 × タイムトラッキングで計上する構造のため、クライアントワーク時間と R&D 時間を分離記録することが税制適用の絶対条件。「専ら試験研究に従事」要件は代表者がクライアントワークで食いつないでいる構造上満たせないため、時間按分による積極算入 (Gemini コンサルテーションの A 派) が実質唯一の現実解となる
  3. ドッグフーディング戦略の価値保持 — 自社業務 (A/B) を R&D (D) のテストベッドにする現在の運用は BtoB SaaS 最強の生存戦略。これを壊さない
  4. 商用化時の切り出しコスト最小化 — テナント抽象化を今から徹底することで、Phase 3 での切り出し作業を最小化
  5. 発見的統制の現実性 — 予防的統制が不可能でも、Git/GAS のネイティブログだけで税務・監査耐性を確保できる
  6. オーバーエンジニアリング回避 — 稟議書 R&D 欄・重厚な規程類などの形式的ペーパーワークは、代表 1 名体制では「仮装行為」と見られるリスクがあり、実効性もない
  7. 外部専門家の意見を取り入れた意思決定 — Gemini コンサルテーション (bizlp の具体的な会社情報を踏まえた第三者視点) を経た結論

結果・影響

ポジティブ

  • 物理分離なしで Phase 1 を運用できるため、代表 1 名体制のリソース枯渇リスクが最小
  • タイムトラッキング + 試験研究費の勘定科目分離により、決算期に顧問税理士と 役員報酬按分の A 派 / B 派 (積極算入 / 保守除外) を協議する材料が揃う
  • テナント抽象化の設計規律により、Phase 3 でのフリート管理デプロイへのリアーキがスムーズ
  • Phase 3 デッドライン要件を明文化したため、商用化準備の漏れが発生しない

ネガティブ

  • Phase 2 / Phase 3 / Phase 4 の具体設計はこの ADR では未確定。各フェーズ突入時に別 ADR で再判断が必要
  • タイムトラッキング運用は「続けられるか」が課題。代表自身の規律に依存
  • bizlp 固有のハードコードが既に存在する場合、それを見つけてリファクタリングする案件が新たに発生する

技術的負債

  • 既存コードベースに bizlp 固有に密結合した箇所 (スプレッドシート ID、PDF フォルダ ID、特定マスタキー等) は、順次テナント抽象化リファクタリングが必要
  • Env.spreadsheetId() は既に抽象化済みだが、他にも同様のパターンが散在している可能性あり (MAS-218 で調査)

実装方針 / 今やるアクション

Phase 1 で今すぐ実施する具体アクションを TODO_future.md に起票する。

TODO案件名優先度ゲート
MAS-218タイムトラッキング (Toggl Track 等) 導入 + R&D 時間配分の記録ルール整備P2 ★★今すぐ着手
MAS-219既存コードの bizlp 固有ハードコード箇所の洗い出し + テナント抽象化リファクタリングP2 ★★MAS-192 Repository 分割完了後、継続実施
MAS-220フリート管理型デプロイ基盤の設計調査 (clasp + GitHub Actions で 1 コード → N 顧客環境)P3 ★Phase 2 後半 〜 Phase 3 着手時
Phase 3 着手時利用規約 / プライバシーポリシー / 情報セキュリティ基本方針 (3 点セット) 整備P1 相当初 PoC 契約確定時

会計処理の変更:

  • 今月以降の Claude Code / Gemini API / GCP 利用料の仕訳勘定科目を**「試験研究費」で統一**する (それまで「通信費」「ソフトウェア利用料」等で計上していた場合も、今期決算に向けて整理)
  • タイムトラッキングの記録は月末に CSV エクスポートして Drive に保管

非スコープ

以下は本 ADR の射程外として別の場で扱う。

  • 役員報酬の試験研究費按分可否 (A 派 / B 派の最終判断) — 決算期に顧問税理士と「証拠の強さ」を協議して決定
  • Phase 2 の dev → prod 移行手順の詳細 — Phase 2 突入時に別 ADR で設計
  • Phase 3 のコードベース移行の具体手順 (フリート管理デプロイの CI/CD 詳細) — MAS-220 で調査、Phase 3 着手時に別 ADR で確定
  • SOC2 / ISO27001 取得判断 (Phase 4) — IPO 準備段階で別 ADR
  • 商用化時のテナント料金プラン設計 — ビジネス側の判断で別途
  • R&D サンドボックス環境の物理分離 (Phase 4) — 成熟期に別 ADR
  • F (クライアントワーク) の環境分離 — F は顧客貸与 PC・bizlp アカウント外で既に完全分離済みであり、本 ADR の分離対象ではない。F の収益管理・案件別原価計算・人件費按分ルールは別途 (経理実務として) 扱う

関連

Confirmation (準拠確認 / Fitness Function)

本セクションは ADR-0036 (Accepted 2026-05-14) で遡及追加された。ADR-0031 パターン (業界標準準拠メタデータ後付け = 誤字修正範疇) に準拠する遡及で本文の意思決定内容は不変。

  • 検証手段: N/A — 要マッピング更新 (ADR-0036 遡及時点で未定義、月次レビューで確定)
  • 実行頻度: —
  • 違反時の対応: —