最終更新: 2026/06/22 18:56
30. 調査依頼管理（Research Questions / RQ）
開発仕様書の「人間が検討すべき事項」のうち、外部情報のリサーチが必要な事項を一元管理。Gemini Deep Research 等への調査依頼候補としても活用する。
📊 1. 実装状況サマリー（2026-05-29 時点）
| ステータス | 件数 |
|---|---|
| 🔍 未着手（調査依頼前） | 30 |
| 📝 メタプロンプト作成済 | 2 |
| ⏳ Deep Research 投入準備完了 | 1 |
| ✅ 調査完了・仕様書反映待ち/済 | 5 |
🔥 2. 優先度ガイド
| 優先度 | 定義 |
|---|---|
| 🔴 P1 | 該当案件の実装着手前にリサーチ完了が必須（誤った仮定で実装すると手戻り大） |
| 🟡 P2 | 該当案件の運用開始前にリサーチ推奨（実装は仮値で進められる） |
| 🟢 P3 | 改善・最適化のための情報収集（実装は不要） |
🔍 3. 調査依頼マスタテーブル
3.1 法制度・税務（13 件）
主な情報源: 国税庁 / e-Gov 法令検索 / 中小企業会計指針 / 顧問税理士
| ID | 関連案件 | 質問・調査依頼 | 想定情報源 | 優先度 | ステータス | 調査結果サマリ |
|---|---|---|---|---|---|---|
| MAS-299 | MAS-073 / MAS-137 | 確定申告後の 法人税・住民税・事業税の標準的な仕訳パターン（一括計上 vs 内訳分離、国税/地方税の分割粒度、中間納付・予定納税の要否判定基準）。設立初年度（9ヶ月決算等の変則）の取扱い | 国税庁、税理士慣行調査 | 🔴 P1 | ⏳ Deep Research 投入準備完了 | RQ-001_prompt.md |
| MAS-300 | MAS-081 | 長期請負契約（6ヶ月超）の工事進行基準の強制適用範囲。中小企業会計指針および法人税法 22 条に基づく完了基準の許容条件 | 中小企業会計指針、法人税法 | 🔴 P1 | 🔍 未着手 | — |
| MAS-301 | MAS-084 | 貸倒引当金繰入額の戻入時の会計処理。「収支区分=支出（マイナス）」のまま記録 vs 「貸倒引当金戻入益（収入科目）」で別計上のどちらが中小企業会計指針上適切か | 中小企業会計指針、税理士確認 | 🟡 P2 | 🔍 未着手 | — |
| MAS-302 | MAS-088 | 中小企業会計指針 第52項「賞与引当金」の最新版。月次按分の標準計算方法、確定前の見積額と確定後の清算処理の実務パターン | 日本公認会計士協会 中小企業会計指針 | 🟡 P2 | 🔍 未着手 | — |
| MAS-303 | MAS-088 | 賞与引当金繰入額の税務上の損金算入要件（別表四調整）。期末未払確定債務の判定基準と、損金不算入のケース | 国税庁・税理士確認 | 🟡 P2 | 🔍 未着手 | — |
| MAS-304 | MAS-089 | 中小企業会計指針 第24項「消費税の会計処理」最新版。税抜方式の運用パターン、仮受/仮払消費税から未払消費税等への決算整理ルール、還付ケース（仮払 > 仮受）の勘定処理 → メタプロンプト / Deep Research プロンプト / ✅ 結果 | 日本公認会計士協会、e-Gov | 🔴 P1 | ✅ 完了・dev_S-17 反映済 | 還付=未収消費税等で確定 / インボイス端数=ヘッダレベル集計 / 経過措置=取引日ベース動的 / 控除不可分=元経費に加算 / 税理士向け 4 パラメータ設定 |
| MAS-305 | MAS-089 / MAS-161 | 消費税インボイス制度の対応要件。適格請求書発行事業者登録番号（T番号）の管理方法・桁数チェック、軽減税率（8%）の判定ロジック、輸出/免税取引との区別 → メタプロンプト / Deep Research プロンプト / ✅ 結果 | e-Gov インボイス制度ガイド、国税庁 | 🔴 P1 | ✅ 完了・dev_S-17/MAS-161 反映済 | T番号バリデーション仕様確定 / 令和8年度税制改正で経過措置は70%→50%→0%に延長 / 取引区分4段階フロー / 簡易インボイス差分 / 税理士向け2パラメータ追加 |
| MAS-306 | MAS-089 | 還付時の勘定科目選定。「未収消費税」を新設する vs 「未払消費税等」をマイナス表示する、のどちらが中小企業会計指針および税務実務上望ましいか | 中小企業会計指針、税理士確認 | 🟡 P2 | 🔍 未着手 | — |
| MAS-307 | MAS-090 | 受取利息の源泉所得税の相手勘定。「仮払法人税等」「法人税、住民税及び事業税」「租税公課」の使い分け基準。法人規模・還付発生可能性別の推奨パターン | 中小企業会計指針、税理士確認 | 🔴 P1 | 🔍 未着手 | — |
| MAS-308 | MAS-090 | 国税（所得税15.315%）と地方税（利子割5%）の分離処理要件。「仮払法人税等」一括 vs 「仮払都道府県民税利子割」分離の税務実務上の基準 | 国税庁、税理士確認 | 🟡 P2 | 🔍 未着手 | — |
| MAS-309 | MAS-024 | 準変動費の固変分類基準。通信費、水道光熱費等の科目を固定費 vs 変動費どちらに分類するかの会計実務上の基準 | 日本公認会計士協会、管理会計実務 | 🟢 P3 | 🔍 未着手 | — |
| RQ-061 | MAS-152 / MAS-114 / MAS-100 / MAS-304 / MAS-305 | 日本の中小法人向け会計システムが取り込み・保存・管理すべき帳票の網羅的洗い出し。取引フロー（受注→請求→入金→決算→申告）の各段階で必要となる帳票（証憑・伝票・明細）約50種を3LLM並列で洗い出し、電帳法3区分・インボイス制度・保存年限の3軸で分類。bizlp-gas-accounting の現行実装とのカバレッジ突合を実施 → ✅ Gemini 結果 / ✅ Claude 結果 / ✅ GPT 結果 / ✅ Synthesis | 国税庁タックスアンサー / 電帳法一問一答 / 消費税法§30 / 法人税法施行規則§59 / 会社法§432・§435 / 中小企業会計指針 | 🔴 P1 | ✅ Synthesis 完成 | 帳票総数50種 / 実装済み18種(36%) / 仕様書完了6種(12%) / 未着手26種(52%) / 最大ギャップ=税務申告基礎データ(消費税集計・内訳明細書・別表十六) / 隠れた高優先度=インボイス経過措置80%→50%(2026年10月) |
| MAS-333 | MAS-067 (A7) / MAS-013 / changelog | 少額減価償却資産特例の取得価額閾値の最新値検証 (2026/4 改正)。措置法 §67-5「中小企業者等の少額減価償却資産の取得価額の損金算入の特例」の 1 個あたり閾値が 2026/4 から 30 万円未満 → 40 万円未満 に改正されたかをユーザーが指摘 (2026-04-30 セッション)。2026 年度税制改正大綱・国税庁公式情報での確定要否を検証。①閾値の確定: 1 個 30 万 → 40 万 への引上げの正式根拠条文・施行日・対象法人区分。②年 300 万円枠の継続性: 改正で年 300 万円の合計上限は据置か変更か。③適用期限: 旧法では 2 年ごと延長で「令和 8 年 3 月 31 日まで」だった条件の延長有無。④取得価額の付随費用扱い: 同時締結の保証契約費用 (例: 設備 39 万 + 10 年保証 2 万 = 41 万のケース) の取扱い・分離可否の実務判定基準。⑤波及更新: 確定後 (a) dev_mas-067_multiyear_planning_workspace.md Line 231 「1 個 30 万円未満を即時償却」→ 40 万円未満 / (b) changelog.md 「30 万円超過」記述 / (c) Constants.TAX_RATES または新規閾値定数の追加要否を判定 | 国税庁 (措置法 §67-5・通達)、財務省 令和 8 年度税制改正大綱、e-Gov 法令検索、税理士確認 | 🟡 P2 | 🔍 未着手 | — |
3.2 会計基準・監査（5 件）
主な情報源: IFRS / 日本公認会計士協会 / J-SOX 関連ガイドライン
| ID | 関連案件 | 質問・調査依頼 | 想定情報源 | 優先度 | ステータス | 調査結果サマリ |
|---|---|---|---|---|---|---|
| MAS-310 | MAS-089 | IFRS（国際財務報告基準）の消費税処理との比較。日本での税抜方式移行に伴う IFRS 準拠可能性、将来の上場準備への影響 | IFRS Official Publications | 🟢 P3 | 🔍 未着手 | — |
| MAS-311 | MAS-137 | 決算仕訳の標準パターン。期末一括計上 vs 中間申告半額計上の選択基準、税理士間の運用差 | 中小企業会計指針、税理士アンケート | 🟡 P2 | 🔍 未着手 | — |
| MAS-312 | MAS-137 | 事業税の特別法人事業税との分離仕訳要件。地方法人特別税・特別法人事業税 の独立科目化要否 | 国税庁、税理士確認 | 🟢 P3 | 🔍 未着手 | — |
| MAS-313 | MAS-179 / MAS-201 | 監査証跡・バックアップの法定保持期間。中小企業（非上場）における会計帳簿関連データの法定保存期間（7年）、税務調査対応の最低水準 | 法人税法、e-文書法 | 🟡 P2 | 🔍 未着手 | — |
| MAS-314 | MAS-179 | 個人情報保護法における Email アドレス等のログ平文保存。会計システムの監査ログに業務利用者 Email を記録する場合の社内規程整合性、匿名化（ハッシュ化）の業界ベストプラクティス | 個人情報保護委員会、JIS Q 15001 | 🟡 P2 | 🔍 未着手 | — |
3.3 外部 SaaS API・連携仕様（9 件）
主な情報源: freee API ドキュメント / MF API / Google Cloud Gemini API / Microsoft Graph API
| ID | 関連案件 | 質問・調査依頼 | 想定情報源 | 優先度 | ステータス | 調査結果サマリ |
|---|---|---|---|---|---|---|
| MAS-315 | MAS-158 | freee 人事労務 API 仕様。月次給与確定データ取込 API のエンドポイント、レスポンス JSON 構造（基本給・各種手当・控除・社保会社負担/従業員負担の対応列）、OAuth2 認証フロー、レート制限 | freee 公式 API ドキュメント | 🟡 P2 | 🔍 未着手 | — |
| MAS-316 | MAS-158 | MFクラウド給与 API 仕様。同上の項目を MF 側で取得する場合のエンドポイント・データ構造・認証フロー | MFクラウド公式 API ドキュメント | 🟡 P2 | 🔍 未着手 | — |
| MAS-317 | MAS-158 | 給与計算 SaaS の月次確定日の業界慣例。月末日 / 特定日（例: 25日）/ 翌月初 5 日 など、複数社契約時のタイミング差異への対応パターン | 給与システム業界レポート、労務管理ベストプラクティス | 🟢 P3 | 🔍 未着手 | — |
| MAS-318 | MAS-147 | Gemini Document AI / Gemini API のマルチモーダル抽出精度。請求書/領収書の docType 自動判定精度、paymentDate vs 発行日の判別ロジック、複数ページ PDF の統合パターン | Google Cloud Gemini API ドキュメント、実運用ベンチマーク | 🟡 P2 | 🔍 未着手 | — |
| MAS-319 | MAS-147 / MAS-157 | Gemini API の手書き帳票・低品質画像の文字認識限界。日本語・英語・数字混在時の精度、推奨前処理（解像度・コントラスト等） | Google Cloud Gemini multimodal capability docs | 🟡 P2 | 🔍 未着手 | — |
| MAS-320 | MAS-157 | HEIC（iPhone 標準形式）の Google Drive 自動変換挙動。GAS の Blob.getContentType() で取得できる MIME タイプ、JPEG への自動変換可否、Workspace プラン別差異 | Google Workspace ドキュメント | 🟢 P3 | 🔍 未着手 | — |
| MAS-321 | MAS-157 | 電子帳簿保存法スキャナ保存の解像度要件。200dpi 相当のピクセル数算出基準（A4・レシート別）、カラー要件、JIIMA 認証要件 | 国税庁・JIIMA、電帳法ガイドブック | 🔴 P1 | 🔍 未着手 | — |
| MAS-322 | MAS-157 / MAS-152 | 電子帳簿保存法のタイムスタンプ要件。Google Drive 更新日時で代替可能か、別途タイムスタンプサービス（JIIMA 認定）が必要か | 国税庁・JIIMA、電帳法ガイドブック | 🔴 P1 | 🔍 未着手 | — |
| MAS-323 | MAS-159 | 銀行・クレカ CSV 取込時の重複検知ハッシュ実装。取引日 + 金額 + 摘要の正規化＋ハッシュ化のベストプラクティス、衝突確率 | 業界実装事例、freee/MF の OSS 実装 | 🟢 P3 | 🔍 未着手 | — |
3.4 セキュリティ・規格（5 件）
主な情報源: FISC / J-SOX / PCI DSS / SOC 2 公式ドキュメント
| ID | 関連案件 | 質問・調査依頼 | 想定情報源 | 優先度 | ステータス | 調査結果サマリ |
|---|---|---|---|---|---|---|
| MAS-324 | MAS-188 | FISC 安全対策基準（金融機関）の中小企業適用範囲。GAS+スプレッドシート構成での実装可能項目と対象外項目の切り分け | FISC 公式ガイドブック | 🟢 P3 | 🔍 未着手 | — |
| MAS-325 | MAS-188 | J-SOX IT 統制の最小要件（IPO 準備時に必須となる項目）。職務分掌、アクセス権管理、変更管理、ログ監査の最低水準 | 金融庁 IT 統制ガイド、IPO 実務書 | 🟢 P3 | 🔍 未着手 | — |
| MAS-326 | MAS-205 / MAS-206 | Google Workspace のセキュリティ機能比較。Business Standard / Plus / Enterprise の MFA 強制・外部共有制限・監査ログ機能の差異 | Google Workspace 公式比較表 | 🟡 P2 | 🔍 未着手 | — |
| MAS-327 | MAS-208〜MAS-210 | GCP セキュリティ設計のリファレンスアーキテクチャ。VPC-SC / Cloud KMS（CMEK）/ Security Command Center の中小 SaaS 適用パターン、月次コスト目安 | Google Cloud アーキテクチャセンター | 🟢 P3 | 🔍 未着手 | — |
| RQ-085 | ADR-0095（予定）/ infra 運用 | Cloudflare Workers + GAS(clasp) + GitHub Actions CI + ローカル macOS を横断する認証・秘密情報の統合管理ベストプラクティス。① 静的シークレット単一ソース化ツール選定（Doppler / Infisical / Google Secret Manager / Cloudflare Secrets Store のトレードオフ）② OAuth refresh token の失効撲滅（OAuth 同意画面 Production/内部アプリ化、サービスアカウント化）③ CI の keyless 化（GitHub OIDC + Workload Identity Federation）④ Decision Pipeline の Basic 認証 → Cloudflare Access Service Token 置換 ⑤ 認証失効の事前検知（カナリア/通知）。ADR-0095「認証・秘密情報管理の全体方針」起案の根拠収集が目的（旧 ADR-0088 予定 → 0088 は cost-estimation で確定済のため繰り上げ）→ 調査プロンプト | Cloudflare / Google Cloud / GitHub 公式、Doppler / Infisical / 1Password docs、OWASP Secrets Management Cheat Sheet | 🔴 P1 | 📝 メタプロンプト作成済 | — |
3.5 業界ベンチマーク・指標（3 件）
主な情報源: CB Insights / Gartner / Y Combinator / 経済産業省統計
| ID | 関連案件 | 質問・調査依頼 | 想定情報源 | 優先度 | ステータス | 調査結果サマリ |
|---|---|---|---|---|---|---|
| MAS-328 | MAS-003 / MAS-008 | 経営 KPI の業界標準値。ランウェイの危険水準（6ヶ月 vs 12ヶ月の境界）、CF バーンレート算出方法の標準（過去 N ヶ月の平均月数の VC 標準）、月次固定支出中央値 | CB Insights、Gartner CFO Report、Y Combinator Startup Metrics | 🟡 P2 | 🔍 未着手 | — |
| MAS-329 | MAS-003 | SMB 向け FP&A 機能の標準 KPI セット。売上総利益率、営業利益率、労働分配率、ARR/MRR の業界別ベンチマーク値（IT/SaaS、コンサル、小売） | 業界レポート、経済産業省中小企業白書 | 🟢 P3 | 🔍 未着手 | — |
| MAS-330 | MAS-029 / MAS-033 | ユニットエコノミクス（LTV/CAC）と Rule of 40 の SaaS 業界標準値。Land & Expand 戦略の典型的な拡張倍率、健全性閾値 | SaaStr、Bessemer Venture Partners レポート | 🟢 P3 | 🔍 未着手 | — |
| MAS-331 | MAS-230 / MAS-223 / MAS-228 | 開発を 1 名に委任する場合の最適人材像・採用戦略・契約形態。bizlp-gas-accounting の独特な技術スタック（GAS + Spreadsheet + Vertex AI + Claude Code AI 支援）と会計ロジック複雑度を前提に、人材プロファイル 3 候補・契約形態・引き継ぎ戦略・1 人 vs 分業・代替プランを Gemini 2.5 Pro に相談 → メタプロンプト / Gemini プロンプト / ✅ 結果 | Gemini 2.5 Pro（SaaS アーキテクト + CTO 採用アドバイザー ペルソナ） | 🔴 P1 | ✅ 完了・MAS-230 反映待ち | プロファイル A（AI-Native TS エンジニア、業務委託 40-60 万/月、会計知識不問）圧倒的推奨（★5）/ 段階的契約（業務委託 3-6 ヶ月 → Phase 3 で正社員化 + RSU）/ R&D 税制優遇は業務委託費 = 委託研究費計上可 / 手放す領域順序 = インフラ → 外部 API → フロント、会計ロジック要件定義とデータモデル設計は代表者が死守 / 採用難航時は Phase 5 延期 + 独力 AI 運用（★5）で無理しない防衛策 |
3.6 プラットフォーム・アーキテクチャ（1 件）
主な情報源: Google Cloud 公式ドキュメント / Anthropic 公式 / GAS コミュニティ / FP&A SaaS 公開記事
| ID | 関連案件 | 質問・調査依頼 | 想定情報源 | 優先度 | ステータス | 調査結果サマリ |
|---|---|---|---|---|---|---|
| MAS-332 | MAS-056 / MAS-245 / MAS-216 | GAS Web App 上の Chat UI + Vertex AI Tool Use + マルチシナリオ永続化の設計論点。doGet(e) Web App 上での Chat UI 実装パターン、Flash vs Sonnet vs Pro の Tool Use 比較、MAS-011/MAS-013/MAS-048 計算エンジンの Tool 化、マルチシナリオ並行対話の UX、永続化スキーマ、個人 B/S 統合モデル（D.11 Step 9 吸収）、GAS 制約下のコスト設計、FP&A SaaS 競合事例、MVP スコープと実装ロードマップを Gemini 2.5 Pro Deep Research に相談 → メタプロンプト / Gemini プロンプト / ✅ 結果（更新版） | Gemini 2.5 Pro（GAS × AI Chat UX アーキテクト + 日本の一人法人向け FP&A アドバイザー ペルソナ） | 🟡 P2 | ✅ 完了・MAS-056 仕様書反映待ち | Chat UI: Vite + React (TS) + vite-plugin-singlefile + doGet / 通信: google.script.run + クライアント側ポーリング（時間差トリガーで重処理を逃がし、30/60 秒タイムアウト完全回避）/ AI: ハイブリッド（対話=Gemini 2.5 Flash $0.03-0.30/$1.50 per 1M、複雑抽出=Claude 3.7 Sonnet $3/$15 or Gemini 2.5 Pro $1.25-2.50/$10-15）/ オーケストレーション: 「AI → React → GAS → React → AI」クライアント主導連鎖 / UX: カード並列型 UI（モバイル横スワイプカルーセル、LLM には差分のみ注入） / 永続化: 40_scenario_registry（親、空き確認済）+ 44_scenario_drivers（子、41 衝突回避で 44 に修正、履歴本体は Drive JSON） / 個人 B/S: calculateOptimalCompensation() で総当たり探索（福井県料率 健保 9.71% / 介護 1.62% / 子ども子育て支援金 0.23% + 軽減税率 15% + インボイス経過措置 70%控除）/ 機密情報: PropertiesService 保存の AES 暗号化キーで暗号化 / キャッシュ: CacheService（100KB/key・6h TTL） / コスト試算: 月額 1,000 円未満 / ロードマップ: 4 フェーズ・計 4 ヶ月（MVP 1.0 + マルチ 1.5 + 統合 1.0 + 最適化 0.5 ヶ月）/ 確定すべき 10 項目 + Claude 追記 9 点（41 衝突・MAS-232 先行・MAS-005 吸収・MAS-045 順序・ポーリング周期・ルーティング閾値・MAS-200 アクセス制御・フォールバック UI・トリガー結果保存先） |
3.7 AI システム開発・LLMOps・ドキュメント管理（3 件）
主な情報源: 学術論文 (arXiv / IEEE / ACM) / LangChain / Anthropic / Microsoft / Google のベストプラクティス / OSS ツール事例
| ID | 関連案件 | 質問・調査依頼 | 想定情報源 | 優先度 | ステータス | 調査結果サマリ |
|---|---|---|---|---|---|---|
| RQ-044 | ADR（予定） | LLM プロンプトのライフサイクル管理・ベストプラクティス調査。プロンプトを「コード資産」として管理するための：①状態遷移モデル（Draft / Stable / Deprecated 等）の学術的・業界的定義、②バージョニング戦略（Semantic Versioning 適用可否・Git タグ vs 専用ツール）、③テスト・評価手法（unit eval / regression / A/B）、④Monorepo vs 専用リポジトリの選択基準、⑤CI/CD パイプラインへの統合パターン。既存ツール（LangSmith / Braintrust / PromptLayer / Azure PromptFlow / Weights & Biases Prompts）のアーキテクチャ比較を含む。ADR 化のための根拠収集が目的 → 調査プロンプト / ✅ Claude 結果 / ✅ Gemini 結果 / ✅ GPT 結果 | arXiv (LLMOps / PromptEng / SE4LLM) / LangChain Hub / Anthropic / ACM / IEEE Software | 🟡 P2 | ⏳ Claude / Gemini / GPT 結果取得済・Synthesis 完了・ADR 起草待ち | 同一リポ + prompts/ ディレクトリ推奨 / Type 1 のみ SemVer 厳格 / Promptfoo (OSS) + GHA の最小構成 |
| RQ-046 | ADR-0046（予定） | ドキュメントインベントリ管理・カバレッジ追跡のベストプラクティス。「どこに何があるかわからない」（発見可能性）と「書いたつもりで書いていない」（カバレッジギャップ）の2問題を解決するための仕組み。①インベントリ管理パターン（インデックスファイル / nav 定義兼用 / frontmatter 活用）、②カバレッジギャップ検出手法（スタブ慣習 / チェックリスト / イベントトリガー CI）、③status フィールド値域の設計（planned / draft / stable / deprecated / archived の最小セット）、④AI エージェント（Claude Code）が「未着手ドキュメント」を認識できるようにするパターン → 調査プロンプト / ✅ Claude 結果 / ✅ GPT 結果 / ✅ Gemini 結果 / ✅ Synthesis | Diátaxis / GitBook / Docusaurus / Obsidian / GitHub Actions CI 事例 / DORA ドキュメント管理事例 | 🟡 P2 | ✅ Synthesis 完成・ADR-0046 起草済み | _config.json nav SSOT + status 5値（planned/draft/active/deprecated/superseded）+ archived 不採用（Git 履歴 + 物理分離で代替）+ COVERAGE_GAPS.md（Backlogパターン） + 30日スタブ検出 |
| RQ-045 | ADR-0043（予定） | ソフトウェアプロジェクトにおける「内部運用ドキュメント」の組織化ベストプラクティス。docs/_internal/ 相当のワークフローガイド・調査記録・AI エージェントテンプレート・Decision Pipeline 設計書・トラッキング資料が混在するディレクトリをどう整理すべきか。①業界標準の組織化パターン（隠しディレクトリ方式 / 機能別分離 / arc42 統合）、②AI エージェント（Claude Code）向けナビゲーション最適化、③arc42 operations/ への統合 vs _internal/ 独立維持の判断基準、④調査記録（RQ-NNN）のアーカイブ戦略、⑤小規模チームに適したフラット構造。ADR 起草前の根拠収集 → 調査プロンプト / ✅ Claude 結果 / ✅ Gemini 結果 / ✅ GPT 結果 / ✅ Synthesis | arc42 公式ドキュメント / Diátaxis / DORA ランブック事例 / GitHub.com オープンソースプロジェクト事例 / Cloudflare / Shopify ドキュメント設計ブログ / CLAUDE.md / AGENTS.md 設計ガイドライン | 🟡 P2 | ✅ Synthesis 完成・ADR-0043 起草待ち | _internal/ 維持 ＋ how-to/ runbooks/ research/ agents/ の4サブディレクトリ / YAML frontmatter 必須（type/status/audience）/ AGENTS.md 〜60行ナビゲーションハブ / 実行プロンプトは .claude/skills/ へ分離 / RQ ライフサイクル: open→active→synthesized→archived |
| RQ-050 | ADR-0049（予定） | ADR / 意思決定の Scope (影響範囲) 軸の業界ベストプラクティス調査。現状 48 件の ADR は ADR-0020 で確立した Tier (Light/Standard/Critical) でのみ分類されており、Scope 軸 (Corporate / Platform / Product / Ops の 4 段階等) が未整備。ADR-0022 で「プラットフォーム / テナント」2 層分離は確立済みだが、4 段階への拡張は未調査。①ADR を Scope 軸で多階層分類する業界事例 (TOGAF / C4 Model / AWS WAR / Azure CAF / GCP AF) の網羅、②MADR v3+ / ThoughtWorks / Spotify / GitLab / Zimmermann の実装事例、③1 人法人スケールでの適用可能性、④Tier × Scope の 2 軸運用の業界実装、⑤bizlp 提案 4 段階 (Corporate/Platform/Product/Ops) の妥当性検証、⑥ADR-0022 からの拡張経路 (Supersede vs Implements/Extends)。ADR-0049 (Standard 想定) 起案のための根拠収集 → メタプロンプト / 調査プロンプト / ✅ Claude 結果 / ✅ Gemini 結果 / ✅ GPT 結果 / ✅ Synthesis | TOGAF v10 / C4 Model (Brown) 公式 / AWS Well-Architected / Azure Cloud Adoption Framework / Google Cloud Architecture Framework / MADR v3+ / ThoughtWorks Technology Radar / Spotify Engineering Blog / GitLab Handbook / Olaf Zimmermann Decision Capture | 🟡 P2 | ✅ Synthesis 完成・ADR-0049 起案待ち | 4段階 (Corporate/Platform/Product/Ops) 採用で 3 モデル合意 / MADR frontmatter scope: 列挙型必須化 / ADR-0022 は Refines (Supersede 不要) / 既存 48 件は Phased Backfill 3 段階で遡及 (Critical 優先) / Tier × Scope 直交 2 軸運用、Corporate × Critical のみ Bezos Type 1 review 必須 / sventorben/decider CodeOps 統合は将来オプション |
| RQ-051 | ADR 起案保留（暫定ドキュメント案 Z 既起案） | Lint 規約ドキュメント (Rule Reference) のベストプラクティス調査。scripts/adr-lint.mjs の 11 ルールが 7 ADR (ADR-0023/0030/0032/0036/0038/0039/0049) に分散しており、規約ドキュメント (docs/_internal/05_how-to/adr-lint_rules.md) を 1 か所に集約したいが、業界の Lint Rule Reference (ESLint / Stylelint / markdownlint / Pylint / RuboCop / Biome / Ruff / adr-kit / Vale 等) の標準構造を未調査で PR #811 を起案・Close した。本 RQ で①必須項目 (rationale / examples / fixable / config / deprecation 等) の業界共通項、②章立てパターン、③1 人法人スケールでの MVP 必須項目、④AI Agent 解釈性 (Anthropic Skill 500 行制約等)、⑤bizlp 11 ルールへの推奨章立て案 を 3 モデル並列で調査。Rule Reference 再起案のための根拠収集 → メタプロンプト / 調査プロンプト / ✅ Gemini 結果 / ✅ Claude 結果 / ✅ GPT 結果 / ✅ Synthesis (ADR-0050 第一適用例) | ESLint / Stylelint / markdownlint / Pylint / RuboCop / Prettier / Biome / Ruff / golangci-lint / adr-kit / Vale / textlint / MISRA C / CERT Coding Standards / Anthropic Skill authoring | 🟢 P3 | 🟡 Synthesis 完了 (ADR-0050 第一適用例) → adr-lint_rules.md 実装段階へ | 採択: Claude 10 節構造を基礎 + Gemini Progressive Disclosure 思想で補強した bizlp informed synthesis。正規化加重和 Claude 0.983 (首位) + 両 Must (#maintainable / #suitable) 完全通過。10 節構造: Purpose / Severity / Category Legend / Summary Table (Discovery) / 4 カテゴリ別 Rule Details (Activation) / Legacy / Changelog。各 rule に YAML frontmatter 8 フィールド (id/severity/category/since/status/fixable/description/related_adrs) + Rationale (Ruff 3 文形式) + ❌ FAIL → ✅ PASS。次工程: adr-lint_rules.md 実装 (1 週間以内) |
| RQ-052 | RQ-051 / RQ-050 Synthesis 再起案の前提（ADR 起案保留） | アーキテクチャ意思決定における多基準評価 (MCDA / AHP / Decision Matrix) のベストプラクティス調査。RQ-050 / RQ-051 Synthesis で 3 モデル相違点を bizlp 採用方針に集約する際、評価軸（「MVP 即時実装可能性」「将来の拡張性」「AI Agent 解釈性」「既存 ADR 整合性」等）が業界フレームワーク未照合の独自合成だった (PR #811 / #814 close 経緯)。本 RQ で①MCDA 主要フレームワーク (AHP / TOPSIS / PROMETHEE / WSM / ELECTRE / MAUT) の網羅、②SAAM / ATAM / CBAM 等のソフトウェアアーキ特化事例、③DACI / RACI / CBA / Wardley Mapping / Cynefin 軽量フレームワーク比較、④LLM-as-Judge / Multi-Agent Debate / Ensemble Decision 等 LLM 出力突合の先行研究、⑤評価軸の重み付け手法とアンチパターン、⑥1 人法人スケールでの MVP / 省略可能項目、⑦RQ-050 / RQ-051 Synthesis 遡及適用案、⑧bizlp Synthesis 標準テンプレート を 3 モデル並列で調査 → メタプロンプト / 調査プロンプト / ✅ Gemini 結果 / ✅ Claude 結果 / ✅ GPT 結果 / ✅ 段階 3 着手前 議論メモ / 📝 Synthesis 草案 | Saaty AHP / Kazman SAAM/ATAM (SEI Carnegie Mellon) / Zimmermann ADMentor SOAD / Atlassian DACI / Jim Suhr CBA / Simon Wardley Mapping / Dave Snowden Cynefin / Anthropic LLM-as-a-Judge / G-Eval / MT-Bench / LangGraph / AutoGen / Wang et al. ICLR 2024 | 🟢 P3 | 🟡 段階 3 Synthesis 草案完成 → ADR-0050 起案段階へ | 採択: 案 C ハイブリッド (MADR + arc42 Q42 完全固定 + WSM + CBA K.O. + Triage×Scope 統合)。bizlp informed extension として #reliable を事業継続性に拡張、ADR-0019/0020/0049 を実運用化。長期方針: 案 B (純粋 CBA) への移行視野、トリガーは組織成熟度 (経営層 3 人以上が CBA で判定可能)。次工程: 段階 4 で ADR-0050 (規約) + Synthesis テンプレ + 教育ドキュメント 4 ファイル (Diátaxis 分離) / 段階 5 RQ-051 Synthesis 再起案 / 段階 6 RQ-050 遡及検証 / 段階 7 LangGraph Critic agent 実装 |
| RQ-053 | ADR（予定） | マルチ-package リポジトリの monorepo 化トポロジー設計のベストプラクティス調査。現状「準 monorepo」(4 projects: root GAS / webapp_client / drp / docs-search-worker、3 deploy targets、npm/pnpm 混在、pnpm-workspace.yaml プレースホルダ放置) を「正式 monorepo」に昇格させるか / そのままにするかの判断軸を 3 モデル並列で調査。①monorepo vs polyrepo の判断基準 (個人開発 + AI エージェント主体という特殊条件含む)、②tooling 選択 (pnpm/npm/Yarn workspaces × Turborepo/Nx/Bazel/Rush) の本リポ制約への適合性、③npm/pnpm 並存と各 subproject 独立 lock の統合戦略、④build/CI 統合 (affected detection / sync-engines.mjs / build:spa orchestrator の monorepo dependency graph 化)、⑤段階的移行戦略 (root 包含可否を IF 構造で提示・broken pnpm-workspace.yaml の扱い・後戻り可能性・6 ヶ月後の KPI) を調査 → 調査プロンプト / ✅ Claude 結果 / ✅ Gemini 結果 / ✅ GPT 結果 / ✅ Synthesis | Google モノレポ論文 / Microsoft Rush / pnpm 公式 / Turborepo / Nx / Bazel / Babel・Jest・React monorepo 採用事例 / Yarn Workspaces / Bun workspaces / Anthropic / GitHub / Cursor 等 AI 主体リポ事例 | 🟡 P2 | ✅ Synthesis 完成・ADR-NNNN 起案待ち | 採択: 案 C (GPT 段階的) — pnpm workspaces + Turborepo + Catalogs、Phase 1 root 除外 → Phase 2 lock 統合 → Phase 3 共有 packaging で root 包含可否を再判断。MCDA 加重和 0.927 で 3 案首位 (Claude 同梱 0.836 / Gemini 分離 0.673)。git subtree 不採用、broken pnpm-workspace.yaml は Phase 1 で削除 + 正規化 |
| RQ-054 | 実装検討 | Knowledge Capture Pipeline のアーキテクチャ全体像調査。bizlp 内で Knowledge Capture Pipeline 実装を検討するにあたり、実装着手前の意思決定地図を得るための 3 モデル並列調査。①Knowledge Capture Pipeline と ETL/ELT/データレイク等の従来概念との差異、②パイプラインの標準的 5 段分解（Ingestion/Extraction/Transformation/Storage/Retrieval）と各段の複雑性集中点、③6 アーキテクチャパターン（Naive RAG / Advanced RAG / Modular RAG / Agentic RAG / GraphRAG / Stream-Incremental）の動作・適用条件・失敗パターン、④横断的設計論点（チャンキング戦略・索引戦略・更新モデル・トレーサビリティ・権限境界）、⑤2025-2026 年の最新潮流（Late Chunking / Contextual Retrieval / ColChunk / Agentic×GraphRAG 融合）、⑥ケース別推奨パターン早見表 → ✅ Claude 結果 / ✅ Gemini 結果 / ✅ GPT 結果 / ✅ Synthesis | Gao et al. 2024 (arXiv:2312.10997) / Edge et al. 2024 (arXiv:2404.16130) / Anthropic Contextual Retrieval / Jina AI Late Chunking / Microsoft GraphRAG / LlamaIndex / Pinecone / Informatica / IBM / NVIDIA | 🔴 P1 | ✅ Synthesis 完成・RQ-060 で bizlp fit/misfit 判定完了 | 3 モデル完全合意: 5 段パイプライン / 6 パターン / ハイブリッド検索+Reranking 標準 / 潮流は「拡張」で「置換」ではない。Claude 定量メトリクス最充実（Anthropic 67%削減、GraphRAG 勝率 p<0.01）/ Gemini セキュリティ設計最深（SpiceDB/ReBAC Pre-Filter）/ GPT 網羅性最高（Mermaid 図・日本語ソース）。次フェーズ: RQ10 bizlp fit/misfit 判定 (P1) |
| RQ-060 | 実装検討 | Knowledge Capture Pipeline — bizlp fit/misfit 判定。RQ-054（一般論 6 パターン）を bizlp の 4 制約（GAS 6 分制限・Cloudflare Workers・監査要件・単独開発）に当てはめ、採用パターンを判定。ADR-0069 Phase R1（Advanced RAG）の妥当性検証と、R2/R3 拡張パスの策定 → ✅ Synthesis | RQ-054 Synthesis / ADR-0069 / docs-search-worker 実装 / drp 実装 | 🔴 P1 | ✅ 判定完了 | ADR-0069 Phase R1（Advanced RAG）は 4 制約と完全適合。Agentic RAG は監査要件・単独開発制約から不採用。拡張パス: R2 Modular RAG 化（2026-08 判定）→ R3 GraphRAG 簡易版補完（2027 以降）。次判断ポイント: 2026-08-25 の 3 ヶ月レビュー |
| RQ-087 | DPJ-001 / 将来 decision-pipeline UI/IA ADR | Decision Pipeline の意思決定確定・記録 UI/IA のベストプラクティス調査（詳細）。JTBD DPJ-001 のゴール「ADR が Accepted 確定し記録された」を支える UI が現 /chat（起案〜審査のみ）に欠落。主眼 = ①確定（Accept/sign-off）UI ②記録の一覧・想起（ADR カタログ）UI。P1=Decide+Corpus の必須要素と先行事例（Log4brains/adr-tools/Backstage/Linear/Notion の確定・カタログ・停滞検知、n=1 認知負荷最小の MVP 線引き）/ P2=Compose→Review→Decide→Corpus の 4 画面 IA・状態モデル・想起入口（関連/矛盾 ADR 提示）/ P3=HITL・過剰審査(goalpost)の可視化と迂回 Accept UX（Cross-Val fix の Part2 escalate 着地点）。RQ-086(landscape) の next layer。3 モデル並列 → Synthesis → UI/IA ADR 起案が目的 → メタプロンプト / 調査プロンプト / ✅ Claude 結果 / ✅ Gemini 結果 / ✅ GPT 結果 / ✅ Synthesis | Log4brains / adr-tools / adr-kit / Backstage / MADR / ThoughtWorks / Linear / Notion / GitHub Projects / Graphite / CodeRabbit / Nielsen Norman / Diátaxis / RQ-086 synthesis / DPJ-001 | 🟡 P2 | ✅ Synthesis 完成・UI/IA ADR 起案待ち | 4画面(Compose/Review/Decide/Corpus)。専用Accept画面は既製品に無く status+git/PR が sign-off / MADR 4.0 Confirmation を監査スロット化 + Accept後 body 編集ブロック(監査必須) / Corpus は保存ビュー4本(Proposed/Accepted/Stuck/All)+ Linear time-in-status で Proposed 滞留(過剰審査)検知 / 矛盾検出は当面 supersede 手動・semantic類似は near-term Should / multi-approver・RAG矛盾pipeline は n=1 過剰。3モデル~$5.39 |
🔄 4. 運用フロー
4.1 調査依頼の起こし方
- 開発仕様書を作成・レビューする際、「人間が検討すべき事項」のうち 外部情報リサーチが必要なもの を本ページに RQ-NNN として追加
- 関連案件 ID と、できるだけ具体的な情報源候補を併記
- 優先度を 🔴 P1（実装前必須）/ 🟡 P2（運用開始前推奨）/ 🟢 P3（改善用）で分類
4.2 Gemini Deep Research 等への依頼
- 本ページから優先度の高い未着手 RQ を抽出
- プロンプト例: 「以下の質問について、日本の中小企業（非上場）の実務水準で調査してください。情報源は信頼できる一次資料を優先：[RQ 本文]」
- 結果を「調査結果サマリ」列に簡潔に記載（詳細は別ファイルに保存）
4.3 調査結果の仕様書反映
- 調査結果が確定したら、該当する開発仕様書の「人間が検討すべき事項」セクションに調査結果を追記し、項目末尾に
✅ RQ-NNN にて調査済と明記 - 本ページのステータスを「✅ 調査完了・仕様書反映済」に更新
- 関連 PR で「RQ-NNN 調査結果反映」コミットを切る
4.4 ステータス遷移
🔍 未着手 → ⏳ 調査中（Gemini 等にリクエスト中）
→ ✅ 調査完了・仕様書反映済（仕様書側の更新まで完了）
→ ⏸ 保留（調査困難、他案件と並行で再検討）
🎯 5. Gemini Deep Research 推奨優先度 TOP 10
実装ロードマップ Phase 1〜2 の前に確定したい順:
| 順位 | RQ | 関連案件 | 概要 |
|---|---|---|---|
| 1 | MAS-304 | MAS-089 | 中小企業会計指針 第24項 消費税会計処理 |
| 2 | MAS-305 | MAS-089 / MAS-161 | インボイス制度の対応要件 |
| 3 | MAS-299 | MAS-073 / MAS-137 | 確定申告後の法人税仕訳パターン |
| 4 | MAS-307 | MAS-090 | 受取利息の源泉所得税の相手勘定 |
| 5 | MAS-300 | MAS-081 | 長期請負の工事進行基準強制適用範囲 |
| 6 | MAS-321 | MAS-157 | 電帳法スキャナ保存の解像度要件 |
| 7 | MAS-322 | MAS-157 / MAS-152 | 電帳法タイムスタンプ要件 |
| 8 | MAS-315 | MAS-158 | freee 人事労務 API 仕様 |
| 9 | MAS-318 | MAS-147 | Gemini Document AI 抽出精度 |
| 10 | MAS-328 | MAS-003 / MAS-008 | 経営 KPI の業界標準値 |
📁 関連ドキュメント
- 29. 追加開発案件 (TODO) — 実装計画の SSoT
- 調査用プロンプト管理 (research_prompts/) — Gemini Deep Research に投げる前段階のメタプロンプト集
- docs/dev/ 配下 — 各案件の詳細仕様書
- PRD プロダクトポリシー — 設計方針
変更履歴
| 日付 | 変更内容 |
|---|---|
| 2026-04-19 | 初版作成。全仕様書 60+ 本から外部リサーチ必須項目 32 件を抽出して登録 |