最終更新: 2026/06/22 18:56
commonid: rq-034-conversational-scenario-ui-prompttype: promptstatus: active

MAS-332 相談プロンプト: GAS Web App + Chat UI + AI Tool Use + マルチシナリオ永続化の設計論点

用途: MAS-056（一人社長の意思決定対話 UI）の本格仕様書着手前に、GAS Web App 上での Chat UI 実装・Vertex AI Tool Use 連携・マルチシナリオ並行対話・シナリオ永続化スキーマの設計論点を Gemini Deep Research に調査依頼するためのメタプロンプト。

作成日: 2026-04-24 Generated from: MAS-332 メタプロンプト

1. 調査の設定

調査依頼の背景と目的

本調査は、Google Apps Script（GAS）を基盤とする一人法人向け管理会計ERP「bizlp-gas-accounting」の次期主力機能（MAS-056）の設計論点を明確化することを目的とします。MAS-056は、既存の複数シミュレーションエンジン（採用、投資、What-if）を、独立したWebアプリケーション上の対話型Chat UIから統合的に呼び出す「意思決定ハブ」として構想されています。

ユーザーである一人社長が自然言語で財務目標を入力すると、AIが対話的にヒアリングを行い、Tool Use（Function Calling）を通じて複数シナリオを並行探索し、最終的に確定したシナリオを管理会計システムに永続化する一連のフローを実現します。

この構想の本格的な仕様書策定に着手する前に、GASの技術的制約下で最適なアーキテクチャを選定するため、GASとAIチャットUXに精通した専門家の知見を求めます。

調査者に期待するペルソナ

あなたは、以下の3つの専門性を兼ね備えたシニアアーキテクト兼業界アドバイザーです。

  1. Google Apps Script × AI Chat UX アーキテクト: GASの doGet Web App、UrlFetchApp、CacheService 等の制約とベストプラクティスを熟知し、それらの制約下でモダンなChat UIとVertex AI（Gemini/Claude）連携を実現するための実装パターンに精通しています。
  2. FP&A (財務計画・分析) 業界アドバイザー: RunwayやCausal等の海外FP&A SaaSの最新動向を把握し、特に中小企業や一人法人におけるシナリオプランニング、What-if分析、財務モデリングのユースケースとUXに深い知見を持っています。
  3. 日本の一人法人向け財務コンサルタント: 日本の税制（法人税・所得税・社会保険料）や、小規模企業共済・経営セーフティ共済といった特有の制度を理解し、「法人B/Sと個人B/Sの統合」という一人法人特有の意思決定プロセスに対する深い洞察を持っています。

求める出力

各調査項目に対し、以下の要素を含む詳細なレポートを期待します。

  • 設計パターン比較表: 3つ以上の実現可能な候補を挙げ、それぞれのメリット・デメリットを「コスト」「実装難易度」「UX」「拡張性」「保守性」「GAS固有の制約との相性」といった複数の評価軸で比較・評価してください。
  • ベストプラクティスと推奨実装ステップ: 比較検討の結果、本プロジェクトの制約と目的に最も合致する推奨パターンを提示し、その実装に向けた段階的なステップ（MVPスコープ→フェーズ2→...）を提案してください。
  • GAS固有の落とし穴リスト: GASで本機能を実装する際に遭遇しうる特有の課題（パフォーマンス、クォータ、タイムアウト、認証、デプロイ等）を具体的に指摘し、その回避策を提示してください。
  • 一次情報へのリンク: 提案の根拠となるGoogle公式ドキュメント、Anthropic/Vertex AI公式ドキュメント、信頼できる技術ブログ記事、関連するOSSのリポジトリ、学術論文など、できるだけ一次情報源への具体的なリンクを豊富に提示してください。

2. 事実パッケージ

本調査の前提となる、プロジェクトの全体像、技術的制約、既存資産に関する客観的な情報を以下に提示します。これらの情報を基に、推測を排した具体的な分析と提案をお願いします。

パッケージ1: プロジェクト全体像と MAS-056 の位置付け

bizlp-gas-accountingは、代表者1名体制の法人（bizlp）が開発・運用する管理会計ERPです。Google Apps Script、Google Workspace、Vertex AIを技術基盤としています。

これまでに、以下の財務シミュレーションエンジンが実装済みです。

  • MAS-011 What-if シミュレーション MVP: 人員追加やSaaS契約追加がP/L, B/S, C/Fに与える影響を試算
  • MAS-013 投資回収シミュレーション: 新規投資案件のNPV, IRR, Payback Periodを計算
  • MAS-048 採用TCO & BEPシミュレーター: 採用候補者の年収から法定福利費などを含めた総所有コスト（TCO）と損益分岐点（BEP）売上を算出

MAS-056の構想は、これら計算エンジンの入口を「サイドバーUI + 入力フォーム」から「独立Webアプリ（GAS doGet ベース）上の対話型Chat UI」に置き換えるものです。

ユーザー（一人社長）が自然言語で「法定福利込みの月手取り60万を維持しつつ、5年後にMRR500万を達成するには？」と入力すると、Gemini / Claudeが:

  1. 対話的にヒアリング（ユーザーの個人資本金・稼ぐ力・生活費レンジ・希望役員報酬を引き出す）
  2. Tool Use（Function Calling）で MAS-011 / MAS-013 / MAS-048 のパラメータに変換・実行
  3. 複数シナリオを並行探索（「採用優先案 / 報酬最大化案 / 投資抑制案」等）
  4. ユーザーが「これで確定」と判断した案を複数のシナリオとして管理会計システムに永続化
  5. 確定シナリオの1つを選んで MAS-045（What-if → 予算転記機能）で 22_bud_headcount / 23_bud_subscription に転記

また、この構想はD.11（9ステップ財務意思決定振り返り）で定義されたStep 9「個人B/S + 法人B/S 統合」の論点も吸収する方針です。MAS-005（固定3シナリオ切替UI）の構想も本機能に統合・発展させる形で再定義します。

パッケージ2: 技術スタックと実行環境の制約

  • 実行環境: Google Apps Script (V8ランタイム)
  • UI基盤: GAS doGet(e) によるWebアプリケーション。スタンドアロン型で、スプレッドシートのコンテナに縛られません。
  • AIモデル連携: Vertex AI経由でClaude Sonnet 4.6 / Gemini 2.5 Proを呼び出します（MAS-216仕様書参照）。
  • データストア: Google Sheets (SpreadsheetApp.openById)、Google Drive（JSONファイル等）、CacheService、PropertiesService。
  • GAS実行時間制限: 1回の実行あたり最大6分。
  • UrlFetchAppタイムアウト: 外部API呼び出しのタイムアウトは30秒（メタプロンプト指定）。ただしLLM呼び出しなど特定のケースでは60秒まで延長されることがあります（MAS-216仕様書参照）。
  • 同時実行クォータ: 1ユーザーあたりの同時実行数は30。
  • ストリーミング非対応: Server-Sent Events (SSE) などによるサーバーからのストリーミングプッシュはネイティブではサポートされていません。

パッケージ3: 既存計算エンジンと呼び出し規約

既存のシミュレーションエンジンは、GASの関数として実装されており、Tool Useの対象となります。

  • MAS-011 What-ifシミュレーション: runWhatIfSimulation(drivers)
    • 入力: driversオブジェクト（例: { driver: 'HC_ADD', payload: { monthlySalary: 500000, startYm: '2026-10' } }）
    • 出力: P/L, B/S, C/Fのベースラインからの差分（Delta）を含むオブジェクト。
  • MAS-013 投資回収シミュレーション: runInvestmentAnalysis()
    • 入力: Google Sheet 30_bud_investment_case に記述された投資案件データ。
    • 出力: 計算結果を 67_report_investment_analysis シートに書き込み、NPV, IRR, Payback Period, ROIを返す。
  • MAS-048 採用TCO & BEPシミュレーター: runHiringTcoSimulation(params)
    • 入力: paramsオブジェクト（例: { annualSalary: 6000000, employmentType: 'SEISHAIN' }）
    • 出力: TCO（年間総コスト）とBEP（月次損益分岐点売上）を含むオブジェクト。

パッケージ4: ユーザー像とUXへの期待値

  • ユーザー: 代表者1名のみの法人（一人社長）。開発者自身がエンドユーザーでもあります。
  • 利用デバイス: PC（メイン）に加え、スマートフォンからの利用も想定されています。
  • 利用シナリオ: 意思決定セッションは、30分から2時間程度のまとまった時間で行われることを想定しています。
  • UXのコア期待値:
    • 複数シナリオの並行探索: 「もしA案ならどうなる？」「B案と比較してどうか？」といった思考プロセスを妨げず、複数の可能性を同時に比較検討できること。
    • 対話による柔軟な操作: 「会話しながら足し引き」ができるようなインタラクティブ性を重視。固定フォームへの入力だけでなく、自然言語での指示で前提条件を微調整できること。

パッケージ5: 個人B/S統合要件 (D.11 Step 9)

MAS-056は、法人単体の財務だけでなく、経営者個人の財務状況との連携を重視します。

個人の資本金・稼ぐ力（クライアントワーク売上）・生活費レンジ・希望月手取り・社会保険最適化・5年後の個人純資産予測を対話でヒアリングし、役員報酬と法人利益のバランスを最適化します。

これは、D.11の議論で明らかになった以下の本質的な要件に基づいています。

一人法人の資産形成は、個人と法人を別々に見るのではなく、統合ポートフォリオとして設計するのが本質。同じ拠出額でも、どのスキームを使うかで税コストが100〜150万単位で変わる。

具体的には、以下の金融スキームを統合的に扱います。

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

パッケージ6: シナリオ永続化の現状と関連機能

  • 既存データ構造:
    • 22_bud_headcount: 人員計画（HC RPAの入力）
    • 23_bud_subscription: SaaS・サブスクリプション計画（SaaS RPAの入力）
    • 30_bud_investment_case: 投資案件（MAS-013の入力）
  • 未着手の構想:
    • F-05: 3つの固定シナリオ（ベース/楽観/悲観）を切り替えるUI。この構想はMAS-056の動的・対話的なマルチシナリオ管理に吸収・発展させます。
  • 仕様書完成済みの連携機能:
    • F-45: What-ifシミュレーション（MAS-011）の結果を、ユーザーの承認を経て22_bud_headcountや23_bud_subscriptionに新規行として転記する機能。これにより、シミュレーションで確定したシナリオの1要素を実際の予算計画に反映させるルートが設計済みです。

3. 調査項目

MAS-056の本格仕様書策定に着手する前に、以下の8つの設計論点について、専門的な知見に基づく詳細な分析と提案を求めます。各項目について、「結論 → 根拠 → 比較表 → 推奨案 → 参考リンク」 の構造で回答してください。

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

GASのWeb Appという制約下で、モダンでインタラクティブなChat UIを実現するための技術選定とアーキテクチャについて調査してください。

  • フロントエンドの選択肢:
    • React SPA（MAS-232で検討中のVite+React基盤の流用可能性を含む）
    • Vanilla JavaScriptによる軽量な実装
    • GASのHtmlService単独での実装
  • 対話の実現方式:
    • UrlFetchAppの30秒タイムアウトとSSEストリーミング不可という制約下で、1ターン1リクエスト完結型のチャットをどのように実装すべきか。ユーザー体験を損なわないためのポーリング、ロングポーリング、またはその他の非同期パターンの比較検討。
  • 会話状態の管理:
    • 複数ターンにわたる会話のコンテキストをどこで管理すべきか。クライアントサイド（LocalStorage, SessionStorage）、Google Drive（JSONファイル）、Google Sheets、CacheServiceのそれぞれの利点と欠点。
  • 参考事例:
    • Google/claspのサンプル、GAS上でReactを動作させるテンプレートプロジェクト、その他公開されているGASベースのChat UI実装事例。

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

GASからVertex AIのTool Use機能を呼び出し、既存のシミュレーション関数（MAS-011/MAS-013/MAS-048）と連携させるための具体的な実装戦略を調査してください。

  • モデル選定と比較:
    • 2026年時点でのClaude Sonnet 4.6とGemini 2.5 ProにおけるTool Use機能の対応度、性能（精度、速度）、料金体系の比較。
  • ツールスキーマ設計:
    • 既存のGAS関数（例: runWhatIfSimulation(drivers)）のシグネチャを、Tool UseでAIが理解・利用できるJSONスキーマとしてどのように定義するのがベストプラクティスか。
  • 多段階ツール呼び出し:
    • 「AIがヒアリング → Tool Aを実行 → その結果を受けてTool Bを実行」といった、複数ステップにまたがるTool Useの連鎖をGAS側でどのようにオーケストレーションすべきか。
  • エラーハンドリング:
    • Tool実行が失敗した場合（GAS関数のエラー、タイムアウト等）のリカバリー戦略。AI側にリトライを促すプロンプト設計、またはアプリケーション側でユーザーに確認を求めるUIフローのどちらが適切か。
  • 言語による性能差:
    • 日本語の自然な会話からツールパラメータを抽出する際の精度と、英語でプロンプトを設計した場合の精度のトレードオフ。

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

ユーザーが複数のシナリオを同時に比較検討できる「並行対話」を実現するためのUI/UXパターンを調査してください。

  • UIレイアウトの選択肢:
    • タブ型UI（「案A」「案B」のようにタブで各シナリオの会話を切り替える）
    • 分岐ツリー型UI（会話の途中で「この前提を変えたら？」と枝分かれさせ、思考の分岐を可視化する）
    • カード並列型UI（複数のシナリオカードを横に並べ、パラメータと結果を同時に比較する）
  • シナリオ管理のアーキテクチャ:
    • LLMにシナリオコンテキストを管理させる方法（System PromptにJSON形式で全シナリオを保持させ、対話のたびに更新する）
    • GASアプリケーション層でシナリオオブジェクトを明示的に管理し、LLMには1シナリオの対話のみを集中させる方法
  • 差分の可視化:
    • 「案Aと案Bの違いは役員報酬だけです」といったように、複数シナリオ間の差分をLLMに要約・提示させる機能の実装方法。
  • モバイルUX:
    • スマートフォンの小さな画面で、複数シナリオの情報を効果的に比較・提示するためのUIデザイン上の工夫。

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

対話を通じて生成・確定された複数シナリオを、Google Sheets上に永続化するための最適なデータモデル（スキーマ）を設計してください。

  • スキーマ候補の提案:
    • 例：親子テーブル構成（親: scenario_registryにID、名称、作成日、ステータス等を記録。子: scenario_driversにシナリオID、ドライバー種別、パラメータJSONを記録）など、複数のスキーマ案を比較。
  • シート番号の採番:
    • 既存のシート番号体系（22〜30番台が予算関連で使用済み）を踏まえ、新規シナリオ管理シートに40_scenario_registry / 41_scenario_driversのような40番台、または90番台を割り当てることの妥当性。
  • 会話履歴の保存:
    • 対話の全履歴を保存する必要があるか。保存する場合、新規シートとGoogle Drive上のJSONファイルのどちらがプライバシー、検索性、容量の観点から優れているか。
  • 機密情報の取り扱い:
    • 個人資産情報（MAS-200 個人情報保護要件と関連）を含むシナリオの機密性をどう担保するか。シートの特定列を暗号化する必要性の有無。
  • シナリオのライフサイクル管理:
    • 「ドラフト」→「確定」→「予算反映済み」→「アーカイブ」といったシナリオのステータス遷移を管理する仕組み。

5. 個人B/S + 法人B/S統合の財務モデル設計 (D.11 Step 9 吸収)

一人法人の経営判断における「法人と個人の財務の統合」を実現するための、具体的な財務モデルと計算ロジックを調査してください。

  • 個人B/Sの項目粒度:
    • 一人法人の意思決定において、個人の貸借対照表に含めるべき標準的な項目（現預金、有価証券、不動産等）とその粒度。配偶者名義の資産を含めるべきか。
  • 役員報酬の最適化モデル:
    • 法人税率と個人の所得税・住民税・社会保険料率のトレードオフを計算し、税引後の手取りキャッシュを最大化するための計算モデル。2026年時点の日本の税制を前提とすること。
  • 社会保険料の試算:
    • 健康保険料と厚生年金保険料を、標準報酬月額に基づいて正確に試算するロジック。福井県の料率を例とし、事業主負担分と従業員負担分の両方を含めること。
  • 個人純資産の将来予測モデル:
    • 5年後の個人純資産を予測するためのモデル。構成要素：(役員報酬収入 - 生活費支出) + (貯蓄額 × 想定運用利回り)。
  • 既存機能との連携:
    • MAS-010（5カ年財務予測）、MAS-048（採用TCO）、MAS-049（賃上げ促進税制）といった既存・計画中の機能と、本財務モデルをどのように連携させるべきか。

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

本機能をGAS上で安定的に運用するためのパフォーマンスチューニングと、API利用コストの試算・管理方法について調査してください。

  • コスト試算:
    • 1回の意思決定セッション（例: 1時間、20ターン）あたりに発生するLLMの呼び出し回数、総トークン消費量、およびVertex AIの利用料金の概算。1日3セッションを想定した場合の月額コストの見積もり。
  • パフォーマンスとの両立:
    • UrlFetchAppのタイムアウト制約と、LLM（特に高機能モデル）の応答時間（Claude Sonnet 4.6で10〜20秒程度）とのバランスをどう取るか。プロンプトの簡素化、Tool Useの並列実行、ユーザーへの待機中フィードバックUIなど。
  • キャッシュ戦略:
    • CacheServiceやPropertiesServiceをどの範囲で活用すべきか。マスタデータの事前ロード、過去の対話履歴の短期キャッシュ、高頻度で呼び出される計算結果のキャッシュなど。
  • クォータへの影響:
    • 同時実行数30というクォータが、将来的なSaaS化（複数ユーザー利用）を見据えた場合にどのような制約となるか。また、一人利用の範囲で問題となるケースはあるか。

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

国内外のFP&A SaaSやAIチャットツールにおける、類似機能の実装状況と技術水準を調査してください。

  • FP&A SaaSの動向:
    • Runway, Causal, Cube, Jiravといった主要FP&A SaaSにおける、AIチャット機能やシナリオプランニング機能の最新の実装レベル（2026年時点）。
  • 汎用AIツールの活用事例:
    • ChatGPTのAdvanced Data AnalysisやClaudeのArtifacts/Projects機能が、本案件で目指すような財務シナリオ管理にどのように活用されているか、あるいは応用可能か。
  • 国内市場の状況:
    • 日本の中小企業向け経営分析・財務コンサルティングツールで、対話型UIを導入している事例の有無。
  • ニッチ市場の調査:
    • 「一人法人 × 個人B/S統合」というニッチな領域を明示的にサポートしているツールやサービスが存在するか。

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

本調査の結果を踏まえ、MAS-056機能を実現するための段階的な実装ロードマップを提案してください。

  • MVP（Minimum Viable Product）のスコープ定義:
    • 「最小限の価値を提供できる製品」として、最初に実装すべき機能の範囲。例えば、「Chat UI + 1つの計算エンジン連携（MAS-048のみ）+ 1シナリオの永続化」など。
  • フェーズ分け:
    • MVP以降の機能拡張を、論理的な塊でフェーズ分けしてください。例：フェーズ1 (MVP) → フェーズ2 (マルチシナリオ対応) → フェーズ3 (個人B/S統合) → フェーズ4 (モバイル最適化)。
  • 工数見積もり:
    • 各フェーズの開発に要する期間の概算。代表者1名が週10時間、本開発に充てるという前提。
  • 次なるステップ:
    • このDeep Researchのレポート受領後、MAS-056の本格的な仕様書策定に着手するまでに、意思決定者（一人社長）が何を考え、何を確定させておくべきか。

4. 出力フォーマット要件

  • 各調査項目（3.1〜3.8）について、必ず**「結論 → 根拠 → 比較表 → 推奨案 → 参考リンク」**の順序で記述してください。
  • 比較表は、3つ以上の候補を5つ以上の評価軸（例: コスト、実装難易度、UX、拡張性、保守性）で評価する形式としてください。
  • 参考リンクは、Google/Anthropic/Vertex AIの公式ドキュメント、学術論文、公開されている詳細な設計・実装記事など、一次情報源を優先してください。
  • レポートの最後に、総括として**「MAS-056 本格仕様書で確定すべき10の設計判断項目」**をチェックリスト形式でまとめて提示してください。

5. 除外する論点 (本調査の対象外)

以下の項目は、本調査のスコープ外とします。これらはMAS-056の本格仕様書策定フェーズ、またはそれ以降に決定されるべき事項です。

  • 個別のボタン配置、色彩、アイコンといった詳細なUIデザイン。
  • GASの具体的なコードスニペットの実装。（設計パターンと方針の提示に留めてください）
  • 本機能の料金プランやビジネスモデルの設計。（自社利用が前提です）
  • マルチテナント化や本格的なSaaS化のアーキテクチャ設計。（将来的な考慮は含みますが、本調査の主眼ではありません）