ADR-0009 環境分離戦略 — Gemini コンサルテーション結果

投入プロンプト: ADR-0009_separation_consultation_prompt.md 投入日: 2026-04-20 使用モデル: Gemini Pro 回答範囲: 5 論点すべてに回答あり

主要な結論サマリ (5 論点)

元の想定からの重要な方針転換

1. 稟議書テンプレの R&D 欄追加は不要 (非推奨) — 代表 1 名体制で自分に稟議する行為は「仮装行為と見透かされる」
2. 経費規程の R&D 費区分ルールは不要 — 同上。形式的ペーパーワークにリソースを割くべきでない
3. タイムトラッキングを今すぐ導入 — 研究開発税制の役員報酬按分の最強の証拠になる
4. コードベースは最初から「1 リポジトリ → フリート管理デプロイ」で設計 — bizlp を「テナント T-001」として扱う抽象化を今から徹底

Gemini Pro 回答全文

以下、回答の逐語記録。将来の参照・監査のためそのまま保管する。

株式会社ビズリンクパートナーズ 代表様

SaaSプロダクトアーキテクト 兼 税務・ガバナンスアドバイザーの視点から、ADR-0009の骨子に対する見解を申し上げます。

代表1名体制という強み（意思決定の速さ）と弱み（リソースの枯渇リスク）を正確に把握した上で、「自社業務をテストベッドとしてドッグフーディングし、そこからSaaSへ昇華させる」というロードマップは、BtoB SaaSスタートアップにおける最強の生存戦略であり、極めて高く評価できます。

ご提示いただいた5つの論点について、日本の法規・実務慣行およびSaaSアーキテクチャの定石を踏まえ、以下の通り推奨案と懸念点をまとめました。

1. 4フェーズ構造の妥当性

【推奨】 現在の「Phase 1〜4」の段階的アプローチは、小規模法人のリソース配分として極めて妥当であり、そのまま推進されることを強く推奨します。初期からマルチテナント化やSOC2水準のインフラ分離を目指す「オーバーエンジニアリング」は、PMF（Product-Market Fit）前のスタートアップにとって致命傷になります。まずは自社の課題解決に集中するアプローチは正解です。

【懸念点】 最も警戒すべきは、Phase 1〜2の期間において、システムが「bizlp社固有の業務ルール」に過剰適合（密結合）してしまうリスクです。将来の商用化を見据え、現時点から「bizlp社もシステムを利用するテナントの1つ（例: テナントID T-001）に過ぎない」という抽象化を意識し、スプレッドシートIDや固有の判定条件をコード内にハードコードせず、設定ファイル（定数・環境変数）に外出しする設計規律を徹底してください。

【先行事例・根拠】 freeeやSmartHRなど、国内の成功した業務系SaaSの多くは、創業者自身の強烈なバックオフィス課題を解決するプロトタイプ（社内ツール）からスタートしています。最初から完璧な分離基盤を作るのではなく、「動くものを素早く作り、自社の実データでエッジケースのバグ出しをする」というLeanな思想は、日本のSaaS開発における定石です。

2. Phase 3 のコードベース戦略

【推奨】 現時点での方針としては、コードベースを1つに保つ**「α. モノリス共有」を維持しつつ、設計思想としては「γ. マルチテナント化」を志向する**ことを強く推奨します。代表1名体制で複数のコードベースを保守することは不可能なため、ソースコードは絶対に「単一のGitHubリポジトリ（Single Source of Truth）」で管理してください。

【A派 / B派の見解と、GAS特有の現実解】

• A派（β. fork分離容認派 / SIer的思考）: 初期顧客（PoC）ごとの個別要望に素早く応えるため、顧客ごとにリポジトリを分岐させる手法。初期売上は立ちやすいですが、バグ修正の「ダブルメンテ」が発生し、1名体制では半年以内に技術的負債が爆発し破綻します。
• B派（γ. 真のマルチテナント派 / SaaS的思考）: 1つの巨大なDBとコードで全顧客を処理するSaaSの王道。しかし、GAS＋スプレッドシートの構成でこれをやると、実行時間制限（6分）やセル数上限、GASの実行権限（誰のGoogleアカウントで動くか）の壁に早期に衝突します。
• 【現実解（フリート管理型）】: 日本のGAS系SaaSにおける現実解は、**「コードリポジトリは1つ（モノリス）に保ち、CI/CDツール（claspやGitHub Actions）を用いて、顧客ごとに用意した独立したGASプロジェクトとスプレッドシートへ、同じコードを一斉デプロイする」**方式です。これにより、マルチテナントの保守性とシングルテナントの堅牢性・制限回避を両立できます。

3. Phase 1 で今やるべきこと

【推奨】 ご提示の4候補のうち、「1. R&D活動の位置付けを明文化（事業計画書やADR）」 と 「4. git log / 仕様書をR&D活動証跡として扱う運用ルール」 の2点を最優先で実施してください。税務調査や将来の技術デューデリジェンスにおいて最も信頼されるのは、形骸化していない「エンジニアリングの生の実態（ログ）」です。

【追加で今すぐやるべきこと】 **「代表者のタイムトラッキング（工数管理）」を今すぐ導入してください。Toggl Track等のツールを用い、「C/D（R&D・コーディング）」に何時間、「A/B（経理・一般管理）」に何時間費やしたかを客観的に記録することが、後述する研究開発税制を適用する際の最強の証拠（エビデンス）**となります。

【やらなくてよいこと（オーバーエンジニアリング回避）】 「2. 稟議書テンプレへの追加」および「3. 経費規程のルール追加」は**現時点では不要（非推奨）**です。代表1名の会社で、自分自身に稟議を上げて承認するプロセスは、税務調査官から見ても「租税回避のための実態のない形式的な仮装行為（お手盛り）」と見透かされます。ペーパーワークを作る時間はすべてコードの執筆とADRの記録に充ててください。

4. 日本の研究開発税制（試験研究費の税額控除）の観点

【推奨】 自社業務をテストケースとしていても、最終目的が「他社へSaaSとして提供するための新技術・新サービスの開発」であることを事業計画やADRで明記していれば、研究開発税制の対象として十分に主張可能です。API利用料や開発ツール代は、会計上も「試験研究費」という独立した勘定科目で集計し、通常の販管費と明確に分離する実務を今から定着させてください。

【A派 / B派の見解：役員報酬の按分という最大の壁】 代表1名体制における最大の税務リスクは、「自身の人件費（役員報酬）を試験研究費に算入できるか」です。税法上、対象となるのは「専ら試験研究に従事する者」に限定されます。

• A派（積極・算入派）: 前述のタイムトラッキング記録を用い、「月間労働時間の大部分（例: 80%）をコーディングと設計に費やしている」客観的証拠を提示し、役員報酬の該当割合を試験研究費として堂々と計上する。要件を満たせば数百万単位の税額控除を生む絶大なリターンがあります。
• B派（保守・除外派）: 代表取締役は経営・営業全般を担うため「専従要件」の証明は税務署の否認リスクが高すぎると判断し、人件費は諦める。代わりにAPI代やクラウド代などの「直接経費」のみを確実に申告する。
• 【戦略的判断】: 資本金300万円は「中小企業技術基盤強化税制」の対象です。初年度売上1,500万円の場合、試験研究費が売上の10%（150万円）を超えれば「高水準要件」を満たし、控除率が上乗せ（最大17%等）されます。API代だけではこの水準に届きませんが、役員報酬を按分（A派）できれば容易に到達します。初年度は客観的記録を徹底的に蓄積し、決算期に顧問税理士と「証拠の強さ」を協議してAかBかを最終判断するアプローチを推奨します。

5. ガバナンス・監査の観点

【推奨：代替的統制への全振り】 代表1名体制では、入力者と承認者を分ける「予防的統制（職務分離：Segregation of Duties）」は物理的に不可能です。税務署や将来の監査法人に対してはこれを正面から認めた上で、**「発見的統制（代替的コントロール）」**でガバナンスを効かせていると主張してください。「職務分離はできないが、GASの実行ログ、Gitのコミット履歴、スプレッドシートの変更履歴がクラウド上に改ざん不可能な状態で100%残っており、事後的な追跡可能性を完全に担保している」という論理が現実解です。

【A派 / B派の見解：個人契約AIの法人利用について】 Claude Code Max等の個人契約を法人カードで決済し業務利用している件について。

• A派（税務・実態重視）: 税務上は「法人の事業遂行上、直接かつ通常必要な費用」であれば損金算入されます。実態として100%プロダクト開発（R&D）に使用しており、立替精算やカード明細で証明できれば、名義が個人でも経費化は全く問題ありません。
• B派（コンプライアンス・将来リスク重視）: 将来のSOC2監査や、商用SaaSとして顧客データを扱う段階において、Consumer向け規約のAIを利用することは「シャドーIT」および「データ漏洩リスク（AI学習利用の懸念）」として重大なインシデントと見なされます。
• 【現実解】: Phase 1〜2（自社データのみのR&D）の段階では現在の運用（A派）で許容されますが、Phase 3（他社データの処理）を開始する直前のデッドラインにて、ADR-0008で決定済みの「GCP Vertex AI（データ学習オプトアウト保証・法人契約）」への完全移行が必須要件となります。

【初PoC契約時点で整備すべき書類】 内部向けの重厚な規程類（経費規程など）は、従業員を雇用するまで不要です。商用化（Phase 3）の初期顧客をオンボーディングする直前に整備すべき対外ドキュメントは以下の3点のみです。

1. 利用規約 (ToS): GASの仕様上避けられないダウンタイムの免責や、SaaSとしての損害賠償上限の限定条項。
2. プライバシーポリシー: AIに顧客データを読み込ませる際のオプトイン取得や、R&D（システム改善）目的でのデータ利用の同意。
3. 情報セキュリティ基本方針: 顧客の情シス部門向けに、「自社は1名だが、GCP/Workspaceのエンタープライズ基盤により堅牢に守られている」と説明する1ページのホワイトペーパー。

ADR-0009 本文への反映方針 (草案)

採用する方針

1. 4 フェーズ構造 (Phase 1-4) はそのまま採用
2. コードベース戦略: 現時点は α モノリス維持 + γ マルチテナント思想 を明記。Phase 3 の具体方式は「フリート管理型 (clasp + GitHub Actions で顧客別 GAS/Sheets に一斉デプロイ)」を最有力候補として記録
3. テナント抽象化の設計規律: bizlp も T-001 的なテナントと扱い、スプレッドシート ID・固有判定条件をコードからマジックナンバーで埋めないルールを今から徹底
4. Phase 1 の実アクション (今やること):
   • R&D 活動の位置付けを明文化 (ADR-0009 本文自体がこれを兼ねる)
   • git log / 仕様書 / ADR を R&D 活動証跡とする運用ルール明示
   • タイムトラッキング (Toggl 等) 導入 ← 新規追加
5. Phase 1 でやらないこと:
   • 稟議書テンプレへの R&D 欄追加 → 不要
   • 経費規程への R&D 費区分ルール → 不要
6. ガバナンス方針: 「予防的統制 (職務分離) は不可能、発見的統制 (git / 実行ログ / Sheets 履歴) で代替」と明記
7. Phase 3 デッドライン要件:
   • 商用化前に必ず Vertex AI への完全移行を完了 (ADR-0008 と整合)
   • 利用規約 / プライバシーポリシー / 情報セキュリティ基本方針の 3 点を整備

フォローアップ案件候補 (ADR-0009 本文からリンク)

• 新規 TODO: タイムトラッキング導入 — Toggl Track 等の選定・導入手順。Phase 1 の今すぐアクション
• 新規 TODO: コード内のテナント抽象化 — スプレッドシート ID・固有判定条件を Env 変数 / 設定ファイルに外出しするリファクタリング案件 (既存 MAS-192 Repository 分割と連動)
• 新規 TODO: フリート管理デプロイ基盤 (Phase 2-3 向け) — 1 コードベース → 複数 GAS プロジェクトへの一斉デプロイ CI/CD 設計
• Phase 3 起票予定: 利用規約 / プライバシーポリシー / 情報セキュリティ基本方針 (初 PoC 契約直前)

ADR-0009 で「スコープ外」として明記する論点

• 役員報酬の R&D 按分可否判断 — 決算期に顧問税理士と協議 (ADR-0009 の範疇外)
• SOC2 / ISO27001 取得判断 — Phase 4 での検討 (別 ADR 候補)

後日判明情報 (重要補記)

Gemini コンサルテーション実施時点では会社の収益構造を明示していなかった。後日判明した以下の情報は、Gemini の回答解釈に重大な影響を与える。

bizlp の収益構造 (2026-04-20 時点で確認)

• 売上 1,500 万円は 100% クライアントワーク (受託業務) で発生
• bizlp-gas-accounting プロジェクトは現時点で売上ゼロ
• クライアントワークは 4 ヶ月継続中、今後も継続予定 (主力事業)
• 代表者は顧客貸与 PC でクライアントワークを実施 (bizlp アカウントではログインしない)
• bizlp-gas-accounting はクライアントワークの空き時間で実施する R&D 投資という位置付け

Gemini 回答の解釈への影響

論点 4 (研究開発税制) の A 派 / B 派判断が明確化

Gemini は回答で「A 派 (積極・算入) vs B 派 (保守・除外) を決算期に顧問税理士と協議せよ」と提示していたが、収益構造を踏まえると B 派は実質選択肢になり得ない:

• B 派 (人件費除外・API 代のみ計上) で試験研究費を構成すると、API 代 + インフラ代では年間 20〜30 万円程度にしか達しない
• 高水準要件 (試験研究費 / 売上 ≥ 10% = 150 万円以上) をクリアするには役員報酬按分が不可避
• したがって A 派 (時間按分による積極算入) が実質唯一の現実解

論点 3 (Phase 1 で今やること) のタイムトラッキングが最重要案件化

Gemini は「タイムトラッキング導入」を追加アクションとして推奨していたが、収益構造を踏まえるとこれは税制適用の絶対条件に格上げされる:

• 代表者の「専ら試験研究に従事」要件は、クライアントワークで食いつないでいる構造上満たせない
• 代わりに「時間按分」で R&D 相当分の役員報酬を試験研究費に計上する戦略を取らざるを得ない
• クライアントワーク時間と R&D 時間を分離した客観記録がなければ、この按分率を主張できない
• TODO_future.md の MAS-218 は P2 → P1 ★★★ に格上げ

論点 1 (4 フェーズ構造の妥当性) の前提補強

Gemini は「自社業務をテストベッドとしてドッグフーディング」する戦略を高評価したが、現実は更に健全:

• bizlp-gas-accounting は売上ゼロの試験研究活動 → 試験研究費として計上する論理が極めて明瞭
• 売上 (100% クライアントワーク) と R&D 費 (100% bizlp-gas-accounting) が完全に分離している
• 税務上「売上を生まない研究開発」という定義にそのまま合致

F 領域 (クライアントワーク) の追加

当初の活動領域 A〜E に加え、F: クライアントワーク (顧客貸与 PC での受託業務) を追加。F は環境としては既に完全分離済み (別 PC、別アカウント) のため ADR-0009 の分離対象外だが、時間記録の対象としては必須。

変更履歴