MAS-332 調査結果（更新版）

投入先: Gemini 2.5 Pro / Gemini Deep Research 投入日: 2026-04-24（初回）/ 2026-04-24 再投入（更新版：ポーリング + ハイブリッド AI + 2026 年税制） Generated from: MAS-332 確定プロンプト 回答者ペルソナ: GAS × AI Chat UX アーキテクト 兼 FP&A アドバイザー 兼 一人法人財務コンサルタント（2026 年時点）

エグゼクティブサマリー

1. GAS doGet Web App 上での Chat UI 実装パターン

結論

Vite + React (TypeScript) の SPA を vite-plugin-singlefile で単一 HTML にビルド → GAS doGet で返却。通信は google.script.run を Promise 化 + クライアント側ポーリングでタイムアウト対策。

根拠

• GAS の doGet は単一 HTML 文字列を返す仕様 → モダン DX には singlefile 化必須
• GAS は SSE / WebSocket 非対応
• google.script.run はクライアント非ブロッキングだが、サーバー処理長引くとブラウザ側タイムアウト発生
• MAS-232 の Vite+React 基盤が既に計画されており流用可能

比較表

推奨案（ポーリング方式の実装）

1. Vite + React (TS) + vite-plugin-singlefile ビルド → dist/index.html を GAS HtmlService に配置
2. UI 状態（ローディング・履歴）は React useState / Context API でクライアント保持
3. ポーリングフロー:
   • React: ユーザー発話を送信 → GAS の処理 ID 受け取り → ローディング表示
   • GAS: 重い AI 往復処理はバックグラウンド（時間差トリガー起動）に逃がし即座に処理 ID を返す
   • React: 数秒おきに google.script.run.checkStatus(id) をポーリング
   • GAS: 完了していれば結果を返す、未完了なら PENDING を返す
   • 30/60 秒タイムアウトが発生しない設計

参考リンク

• vite-plugin-singlefile: https://github.com/richardtallent/vite-plugin-singlefile
• GAS + Vite + React 実装例: https://zenn.dev/nxted_sapporo/articles/50e1efbc92e728

2. Vertex AI Tool Use (Function Calling) の GAS からの実装

結論

ハイブリッドモデル構成を推奨。日常対話・ルーティング用に Gemini 2.5 Flash、複雑な財務 JSON 抽出・考察用に Claude 3.7 Sonnet または Gemini 2.5 Pro を呼び分け。多段階 Tool Use は クライアント（React）主導型オーケストレーション で実装。

根拠

• UrlFetchApp の 30 秒〜60 秒タイムアウト
• 単一 GAS 関数内で AI 往復ループを回すと確実にタイムアウト
• Flash だけでは複雑な財務パラメータ抽出で精度不足の可能性、Claude/Pro だけでは日常対話でコスト過大

比較表（2026 年価格）

推奨案（クライアント・オーケストレーション）

ツールスキーマは OpenAPI 形式で定義、既存関数の引数を JSON スキーマ化。

[React] ユーザー発話送信
  ↓
[GAS] Vertex AI (Flash) → function_call を返す
  ↓
[GAS] React へレスポンスを返す（通信終了・タイムアウト回避）
  ↓
[React] ツール実行リクエストを GAS へ再送信
  ↓
[GAS] F-11/F-13/F-48 を実行 → 結果を React へ返す
  ↓
[React] 結果を GAS 経由で再度 AI へ投げる
  ↓
[GAS] 最終的なテキスト回答を受領 → React へ返す

複雑な比較・考察が必要な場合は Claude 3.7 Sonnet / Gemini 2.5 Pro に切替。

参考リンク

• Vertex AI Pricing: https://cloud.google.com/vertex-ai/generative-ai/pricing
• UrlFetchApp タイムアウト挙動: https://stackoverflow.com/questions/70402556/

3. マルチシナリオ並行対話の UX パターン

結論

カード並列型 UI（モバイル: 横スワイプ型カルーセル）。シナリオ管理は LLM に丸投げせずアプリケーション層（React / GAS）で明示管理し、LLM には差分情報のみプロンプトに注入。

根拠

• 視覚的比較が意思決定の要
• LLM のコンテキスト履歴にすべてのシナリオを埋め込むとトークン爆発＋ハルシネーション（パラメータ混同）リスク

比較表

推奨案（シナリオ状態管理）

React State:

[
  { "scenarioId": 1, "title": "採用案", "drivers": {...}, "metrics": {...} },
  { "scenarioId": 2, "title": "SaaS 案", "drivers": {...}, "metrics": {...} }
]

ユーザー発話「案 A と案 B の違いを教えて」→ React 側で 2 シナリオの JSON を文字列化 → 「以下の 2 つの JSON データの財務的差異をビジネス視点で要約して」という system prompt と共に Flash に渡す。

→ トークン節約＋正確な差分解説。

参考リンク

• Runway vs Causal FP&A 比較: https://www.drivetrain.ai/post/top-runway-alternatives-for-fp-a

4. シナリオ永続化のデータモデル設計

結論

Sheets 親子テーブル + Drive JSON のハイブリッドスキーマ。対話テキスト履歴本体は Drive 上の JSON ファイルに保存、file_id を親テーブルに記録。

根拠

• スプレッドシートのセル 50,000 文字制限
• 巨大 JSON のセル保存・パースは GAS 6 分制限を圧迫
• 一方でシナリオのタイトル・作成日・確定ステータスは検索・ソート性が必要

比較表

推奨案（スキーマ）

40_scenario_registry（親、空き確認済）

41_scenario_drivers（子） ⚠️ 41 衝突注意（後述）

機密情報の保護

• 個人 B/S の資産額など → シートに平文で書かない
• PropertiesService.getUserProperties() に保存した AES 暗号化キーで暗号化
• 暗号化済文字列を parameter_json / 専用列に保存

参考リンク

• GAS Sheets ベストプラクティス: https://www.slideshare.net/slideshow/gas-best-practice/37555762

5. 個人 B/S + 法人 B/S 統合の財務モデル設計（D.11 Step 9）

結論

中間粒度（税・社保・共済最適化に特化）。最新の税制・社会保険料率（2026 年）をハードコードし、Tool Use から呼び出せる関数 calculateOptimalCompensation() を GAS に実装。

根拠

• 個人全資産トラッキングは家計簿アプリの領域で意思決定 ERP としては過剰
• 焦点は「役員報酬の最適化で手取り最大化 + 法人節税の最適化」

2026 年の最新情報

• インボイス経過措置: 令和 8 年度税制改正により免税事業者からの仕入は 10 月以降 「70%控除」 へ移行（50% ではない）
• 福井県の社会保険料率（2026 年 3 月分〜・4 月納付〜）:
  • 健康保険 9.71%
  • 介護 1.62%
  • 子ども子育て支援金 0.23%

比較表

推奨案（ヒアリング項目と関数）

個人 B/S ヒアリング 3 項目:

1. 現在の現預金
2. 月々の生活費（これ以下の役員報酬は提案しない制約条件）
3. 小規模企業共済・iDeCo の現在の月額掛金枠

calculateOptimalCompensation():

• MAS-048（採用 TCO）の「総報酬 → 社保逆算ロジック」を応用
• 法人税（800 万以下の軽減税率 15%）+ 個人所得税 + 社会保険料（福井県料率）の合算税コストが最小となるスイートスポットを総当たり（Brute-force）で探索
• Tool Use で AI に提供

対応金融スキーム

• 小規模企業共済（個人所得控除）
• iDeCo（個人所得控除）
• 経営セーフティ共済（法人損金算入）
• 個人 NISA（余剰資金運用）

参考リンク

• 令和 8 年 3 月分からの健康保険料率（福井県）: https://fukui-shahokyo.jp/news/new...
• 仕入税額控除の経過措置 80%→70%→50%: https://sogyotecho.jp/inputtaxcredit-extension/

6. GAS 制約下でのパフォーマンスとコスト設計

結論

コストは月額 1,000 円未満で事実上無視可能。ボトルネックは GAS 起動速度と計算時間にあるため、マスタデータと過去計算結果は CacheService で徹底インメモリ化。

コスト試算（Gemini 2.5 Flash メインの場合）

• 1 セッション: 1 時間・20 ターン・平均 5,000 トークン/ターン = 計 100,000 トークン
• Gemini 2.5 Flash: 数円/セッション
• 1 日 3 回利用 × 30 日 = 90 セッション → 月額 1,000 円未満
• 複雑シナリオで Claude Sonnet / Gemini Pro を部分利用しても月額数千円以内

比較表

推奨案

• 税率マスタ（法人税率・社保料率）、進行中ドラフトシナリオは CacheService に文字列化して格納
• 100KB/key を超える場合はチャンク分割
• 暗号化キーは PropertiesService.getUserProperties()
• 同時実行 30 quota は 1 人利用なら到達せず、将来 SaaS 化時に LockService で排他制御

参考リンク

• CacheService Eviction and Other Limits: https://dev.to/googleworkspace/apps-script-cacheservice-eviction-and-other-limits-1p6d

7. SaaS 競合・先行事例の調査

結論

先進 FP&A SaaS（Runway/Causal）は AI 統合を進めているが、その大半は「数式の自動生成」「レポート要約」に留まる。「チャットで対話しながら複数シナリオを比較・分岐させ、かつ個人税まで統合計算する」は空白領域。

根拠

• Causal: スプレッドシート代替の高速モデリング（企業財務・BtoB 特化）
• Runway: 美しいダッシュボード + 他ツール連携（企業財務のみ）
• 日本特有の「一人法人 × 役員報酬 × 法人税トレードオフ」はグローバル SaaS が対応していないニッチ領域

比較表

推奨案

• UI は先行 FP&A SaaS の「カード型シナリオ切替」の視覚表現を取り入れる
• 計算エンジンは「AI に計算させる（ハルシネーション）」のではなく「AI に GAS 関数を実行させる（Tool Use）」
• 汎用 AI にはない正確性を担保

参考リンク

• Runway vs Causal 選択ガイド: https://runway.com/blog/choosing-between-runway-and-causal-read-this-before-you-decide

8. 実装ロードマップの推奨

未知技術要素（React on GAS、Tool Use クライアントオーケストレーション）が多いため MVP から段階的拡張。

合計: 4 ヶ月（初期回答の 15-17 週 ≒ 4 ヶ月と同水準、内訳が月単位で明確化）

📝 最終総括: MAS-056 本格仕様書で確定すべき 10 の設計判断項目

• 1. フロントエンド基盤: Vite + React (TS) + vite-plugin-singlefile で進めるか
• 2. 非同期通信アーキテクチャ: React 側からのポーリング制御を実装することに同意するか
• 3. AI モデルの選定とルーティング: 基本対話 = Gemini 2.5 Flash、複雑比較 = Claude 3.7 / Gemini 2.5 Pro の使い分け（あるいは単一統一）をどうするか
• 4. Tool Use オーケストレーション: 「AI → React → GAS → React → AI」クライアント仲介連鎖パターンの実装に同意するか
• 5. チャット UI レイアウト: モバイルでも比較しやすい「カード並列型 UI」を採用するか
• 6. 永続化データスキーマ: 予算用シート（20〜30 番台）と分け、40_scenario_registry と 41_scenario_drivers の親子構造を新設するか（→ 41 衝突に注意、別番号への変更要）
• 7. 会話履歴の保存先: テキスト履歴はスプレッドシートではなく Drive 上の JSON ファイルに保存する方針でよいか
• 8. 機密情報の取り扱い: 個人資産額は平文保存ではなく PropertiesService 利用の暗号化を実装するか
• 9. 財務モデルの前提条件: 社会保険料率は 2026 年 3 月適用の福井県料率、インボイス経過措置は 2026 年 10 月からの「70%控除」を前提としたロジックを組むか
• 10. 開発スコープの段階的縮小: 最初の 1 ヶ月（MVP）はマルチシナリオ・個人 B/S 統合を諦め「MAS-048（採用 TCO）との単一対話」のみに集中するか

MAS-056 仕様書着手前に人間が追加で決めるべきこと（Claude 追記）

Deep Research 結果（更新版）を踏まえ、仕様書ドラフト前に確定しておくと手戻りが少ない論点:

1. ⚠️ シート番号 41 の衝突 — 更新版でも同じ問題が残る Deep Research 更新版も 41_scenario_drivers を推奨するが、既存 41_trn_budget（予算仕訳・P/L/B/S/CF マートのコア参照）と衝突する（grep 確認済）。42（42_trn_journal）/ 43（43_trn_timesheet）も予約済。 代替案: 40_scenario_registry（親、空き確認済）+ 44_scenario_drivers（子、空き確認済） を推奨。44-49 は全て空き。

2. MAS-232 先行実装の優先度引き上げ: MAS-056 MVP フェーズ 1 の Vite+React 基盤が MAS-232 の成果物前提。MAS-232 を先行実装 or MAS-056 MVP と統合着手の判断必要

3. MAS-005 の公式廃止 or 吸収記述: MAS-005 TODO エントリに「MAS-056 に吸収」明記のタイミング

4. MAS-045 実装順序: MAS-045（What-if 予算転記）が仕様書完成済だが未着手 → MAS-056 MVP（Phase 1）前に先行実装すべきか、Phase 3 統合で同時実装するか

5. ポーリング周期の設計: 2 秒 / 5 秒 / 10 秒のどれを既定値にするか（AI 応答待ち時間 vs UX テンポのトレードオフ）

6. AI モデルルーティングの閾値設計: Flash で処理できる発話 / Claude・Pro に回すべき発話の判断基準をどこに埋め込むか（system prompt か Router 関数か）

7. 個人 B/S データの機密性（MAS-200 連携）: 40_scenario_registry 内の暗号化済個人資産データのアクセス制御・監査ログの取り方

8. Gemini Flash 精度不足時の Sonnet フォールバック UI: 「この回答は Flash では難しいので Claude に切り替えますか？」のような UI 提示を入れるか、裏でサイレントに切り替えるか

9. ポーリング方式の GAS 実装: GAS の時間差トリガー（ScriptApp.newTrigger().timeBased()）で重い処理を実行する場合、結果保存先（CacheService か専用シートか）、結果 TTL（6 時間キャッシュ切れの扱い）の設計

変更履歴