非機能要件定義書 (NFRD) | BizLinkPartners 社内ドキュメント

本文書は BizLP GAS Accounting の非機能要件を体系的に定義する。各要件は計測可能な基準値を持ち、GAS (Google Apps Script) 環境固有の制約を前提とする。

要件サマリー

ID	要件名	カテゴリ	現状
NFR-P01	GAS 6分タイムアウト	パフォーマンス	充足
NFR-P02	スプレッドシートセル容量	パフォーマンス	充足
NFR-P03	RPA起票スループット	パフォーマンス	充足
NFR-P04	データマート更新速度	パフォーマンス	充足
NFR-P05	API呼び出し最適化	パフォーマンス	充足
NFR-D01	SSOT原則の遵守	データ整合性	充足
NFR-D02	冪等性（二重起票防止）	データ整合性	充足
NFR-D03	トランザクション模倣	データ整合性	部分充足
NFR-D04	データ整合性チェック	データ整合性	充足
NFR-D05	マスタ参照整合性	データ整合性	充足
NFR-S01	認証（OAuth）	セキュリティ	充足
NFR-S02	データ暗号化	セキュリティ	充足
NFR-S03	ロールベースアクセス制御	セキュリティ	部分充足
NFR-S04	行レベルアクセス制御	セキュリティ	未対応
NFR-S05	入力規則・列保護	セキュリティ	充足
NFR-S06	機密データ保護	セキュリティ	部分充足
NFR-A01	GASサービス依存性	可用性	充足
NFR-A02	デプロイ手順の確立	可用性	充足
NFR-A03	ロールバック	可用性	充足
NFR-A04	バックアップ・リカバリ	可用性	充足
NFR-M01	テストカバレッジ	保守性	部分充足
NFR-M02	コードの凝集度・モジュール性	保守性	充足
NFR-M03	ドキュメント鮮度	保守性	充足
NFR-M04	DDLスキーマ管理	保守性	充足
NFR-T01	仕訳追跡（INV→TRN）	監査証跡	充足
NFR-T02	決済追跡（STL→TRN）	監査証跡	充足
NFR-T03	RPA起票元追跡	監査証跡	充足
NFR-T04	操作者追跡	監査証跡	未対応
NFR-T05	仕訳レコード不変性	監査証跡	充足
NFR-T06	操作ログ	監査証跡	未対応

パフォーマンス

NFR-P01: GAS 6分タイムアウト

項目	内容
カテゴリ	パフォーマンス
シナリオ	ユーザーがGASメニューから任意の処理（RPA起票/Action A/B/マート更新）を実行するとき
要件基準	各処理が 6分以内に完了すること
制約条件	GAS は 1 実行 6 分（360 秒）上限。超過時 `Exceeded maximum execution time` で中断
検証方法	GAS 実行ログ (`console.time` / Apps Script ダッシュボード) で計測
現状ステータス	充足 — 処理を機能単位に分離。現状 INV 数百行で約 30 秒〜2 分

緩和策:

RPA は予算タブ種別ごとに独立実行（HC/SaaS/CAPEX/Pipeline/Finance/Adhoc）
Action A/B は承認済/消込済の未処理行のみを対象とし、全量スキャンを回避
マート更新は getDataRange().getValues() による一括読み込み + インメモリ集計

NFR-P02: スプレッドシートセル容量

項目	内容
カテゴリ	パフォーマンス
シナリオ	会計年度の経過によりトランザクション行が蓄積し続けるとき
要件基準	ブック全体のセル数が 1,000万セル以下に維持されること
制約条件	Spreadsheet セル上限 10,000,000 セル / ブック
検証方法	`=SUMPRODUCT(行数×列数)` または GAS の `getMaxRows()*getMaxColumns()`
現状ステータス	充足 — 現状上限の 10% 未満。FLAG=FALSE 行を定期クリーンアップ運用想定

NFR-P03: RPA起票スループット

項目	内容
カテゴリ	パフォーマンス
シナリオ	HC RPA（最大12行/人/月）を全従業員分一括実行するとき
要件基準	500 行/分以上の書込スループット維持
制約条件	`setValues()` はバッチに比例。個別行 `setValue()` は桁違いに遅い
検証方法	テストランナー T1/T5/T6/T8 の実行時間を計測
現状ステータス	充足 — 一括 `setValues()` で 10 名 × 12 行 = 120 行 ≒ 15 秒

NFR-P04: データマート更新速度

項目	内容
カテゴリ	パフォーマンス
シナリオ	ユーザーがマート更新メニューを実行し、P/L・B/S・C/F・PJ損益・日次CFを全て更新するとき
要件基準	全財務諸表の更新が 3分以内に完了すること
制約条件	6分上限の半分以内を目標とし、将来のデータ増加に対するバッファを確保
検証方法	テストランナー T4 の実行時間。GAS実行ログでの所要時間確認
現状ステータス	充足 — 全諸表更新 ≒ 30 秒（インメモリ集計 `finalUnionData` + 一括出力）

NFR-P05: API呼び出し最適化

項目	内容
カテゴリ	パフォーマンス
シナリオ	任意の処理がスプレッドシートAPI（getValues/setValues/getRange 等）を呼び出すとき
要件基準	API 呼び出し回数最小化。シート毎 `getDataRange().getValues()` は 1 回のみ
制約条件	GAS↔API ラウンドトリップ約 50-100ms/回。ループ内 `getValue()` 禁止
検証方法	コードレビューで API 呼び出しパターンを確認
現状ステータス	充足 — 「一括読込 → インメモリ → 一括書込」採用。例外: Action A/B の JNL_ID 書戻のみ行単位

実装パターン:

読み込み: sheet.getDataRange().getValues()     → 1回/シート
処理:     JavaScript 配列操作                   → API呼び出しなし
書き込み: sheet.getRange(...).setValues(array)  → 1回/バッチ

データ整合性

NFR-D01: SSOT原則の遵守

項目	内容
カテゴリ	データ整合性
シナリオ	P/L・B/S・C/F・PJ損益の集計を実行するとき
要件基準	財務諸表集計は 32_wrk_invoice (INV) 起点。TRN を集計ソースに使わない
制約条件	TRN は監査証跡（ADR-0001）
検証方法	`06_datamart_*.js` レビュー + P/L 合計値 vs INV 手計算
現状ステータス	充足 — `06_datamart_ingest` は INV/STL のみ読込・TRN 不参照

NFR-D02: 冪等性（二重起票防止）

項目	内容
カテゴリ	データ整合性
シナリオ	ユーザーが同一条件で RPA 起票または Action A/B を2回連続実行するとき
要件基準	2回目以降の実行で重複レコードが生成されないこと（新規処理件数 = 0）
制約条件	GAS にはデータベーストランザクション機構がなく、処理途中での中断が起こりうる
検証方法	T7（冪等性テスト・8 サブテスト）— 2 回実行で 2 回目の処理件数 = 0 を確認
現状ステータス	充足

実装メカニズム:

処理	冪等性チェック方法	チェック列
RPA起票	`isDuplicate_()` — 摘要文字列の重複検出	32_wrk_invoice.摘要
Action A	`自動仕訳JNL_ID ≠ 空` → スキップ	32_wrk_invoice.自動仕訳JNL_ID
Action B	`自動仕訳JNL_ID ≠ 空` → スキップ	33_wrk_bank.自動仕訳JNL_ID

NFR-D03: トランザクション模倣

項目	内容
カテゴリ	データ整合性
シナリオ	Action A/B の処理中に GAS タイムアウトまたはエラーが発生し、処理が途中で中断されたとき
要件基準	再実行で未処理行のみ処理・処理済はスキップ。部分書込状態から回復可能
制約条件	GAS にロールバック機構なし。`setValues()` はアトミックでない
検証方法	中断シミュレーション + JNL_ID 書戻が行単位であることを確認
現状ステータス	部分充足 — JNL_ID チェックで整合性担保。TRN 書込～JNL_ID 書戻間の中断のみ理論リスク

緩和策:

TRN 行を一括 setValues() で書き込み（中間状態の発生を最小化）
JNL_ID を行単位で即時書き戻し（次行処理前に完了マーカーを設定）
中断後の再実行時、JNL_ID 存在チェックで処理済み行をスキップ
データ整合性チェック (03_data_validator.js) で事後検出

残存リスク: TRN一括書き込みとJNL_ID書き戻しの間の数ミリ秒間に中断が発生した場合の二重生成。発生確率は極めて低いが、発生時はメンテナンスツール（孤立TRN削除）で手動修復する。

NFR-D04: データ整合性チェック

項目	内容
カテゴリ	データ整合性
シナリオ	ユーザーがデータ整合性チェックメニューを実行するとき
要件基準	20-30 番台全タブで科目マスタ存在/金額/日付/参照をチェックしセル色+ツールチップで可視化
制約条件	10 シート以上対象のためマスタ事前ロード（O(1)）必須
検証方法	不正データ投入でエラーが検出されることを確認
現状ステータス	充足 — `03_data_validator` が 10 種検証 × 3 段階（CRITICAL/ERROR/WARNING）

バリデーション対象:

シート	主なチェック項目
21_bud_pipeline	計上開始年月、確度、売上科目のマスタ存在
22_bud_headcount	開始年月、給与額、勤務区分
23_bud_subscription	開始年月、年間費用
24_bud_capex_loan	資産種別、購入日、金額
25_bud_finance	摘要、科目マスタ存在
26_bud_adhoc	科目マスタ存在、金額
27_bud_resource	PJ名マスタ存在、HC氏名マスタ存在
31_wrk_order	発注日、取引先、科目
32_wrk_invoice	発生日必須（承認済/決済完了時）、親ORD存在、税計算精度、残高≧0
33_wrk_bank	決済日必須（消込済時）、消込対象INV存在、決済日≧INV発生日

NFR-D05: マスタ参照整合性

項目	内容
カテゴリ	データ整合性
シナリオ	RPA 起票時に予算マスタの科目名が 11_mst_account に未登録であるとき
要件基準	未登録の科目名に対してエラーを発生させること。キーワード推測による自動分類は禁止
制約条件	科目マスタの科目名は完全一致で参照。部分一致・あいまい一致は許容しない
検証方法	存在しない科目名を含む予算レコードを投入し、RPA 起票がエラーを返すことを確認
現状ステータス	充足 — CLAUDE.md の「未登録科目名はエラー・キーワード推測禁止」ルールを全 RPA で遵守

セキュリティ

NFR-S01: 認証（OAuth）

項目	内容
カテゴリ	セキュリティ
シナリオ	開発者が clasp を使用して GAS プロジェクトにコードをデプロイするとき
要件基準	OAuth 2.0 による認証が必須であること。未認証状態でのデプロイが不可能であること
制約条件	clasp OAuth トークンは定期失効（`invalid_grant` 等）。ブラウザ操作必要
検証方法	`clasp push` 認証フロー + 失効時エラーメッセージ確認
現状ステータス	充足 — clasp + OAuth2 (creds.json) 実装。GitHub Actions も同トークン使用

NFR-S02: データ暗号化

項目	内容
カテゴリ	セキュリティ
シナリオ	財務データがネットワーク上を転送される、またはストレージに保存されるとき
要件基準	転送時 TLS 暗号化、保存時 AES-256 暗号化が適用されること
制約条件	Google Cloud のインフラストラクチャに依存。カスタム暗号化レイヤーの追加は不可
検証方法	Google Cloud セキュリティホワイトペーパーによる確認
現状ステータス	充足 — Google Spreadsheet 標準のセキュリティ（保存時 AES-256、転送時 TLS）が自動適用

NFR-S03: ロールベースアクセス制御

項目	内容
カテゴリ	セキュリティ
シナリオ	経理担当者が GAS メニューから処理を実行するとき。PJ マネージャーが財務データを閲覧するとき
要件基準	ユーザーの役割に応じて、実行可能なメニュー項目とアクセス可能なシートが制限されること
制約条件	GAS にはネイティブな RBAC 機構がない。シート単位の共有権限（編集者/閲覧者）のみ利用可能
検証方法	スプレッドシートの共有設定と保護シート設定の目視確認
現状ステータス	部分充足 — シート共有レベルでの権限分離は可能だが、GAS メニューレベルのアクセス制御は未実装

現在のロールマッピング:

ロール	GAS メニュー権限	シート保護	備考
Admin (代表)	全メニュー実行可	全シート編集可	現在の唯一の運用者
経理担当 (将来)	RPA/消込/マート更新	20-30番台入力可、10s/40s以降は読取専用	将来の組織拡大時に設定
PJマネージャー	メニュー実行不可	79タブ等の閲覧のみ	—

将来対応: GAS の onOpen トリガーで Session.getActiveUser() を取得し、ユーザーに応じてメニュー項目を動的に切り替える仕組みを検討。

NFR-S04: 行レベルアクセス制御

項目	内容
カテゴリ	セキュリティ
シナリオ	PJマネージャーが自分の担当PJ以外の財務データにアクセスしようとするとき
要件基準	ユーザーの担当PJに応じて、閲覧可能な行を動的にフィルタリングすること
制約条件	Google Spreadsheet には行レベルのアクセス制御機構がない
検証方法	—
現状ステータス	未対応 — 少人数運用のためスコープ外。10 名超 + PJ 間機密化が必要になった時点で対応

NFR-S05: 入力規則・列保護

項目	内容
カテゴリ	セキュリティ
シナリオ	ユーザーがスプレッドシート上で直接データを入力・編集するとき
要件基準	入力列にプルダウン/数値制約/TRUE・FALSE 規則。自動計算列は上書き不可
制約条件	入力規則は DDL (`setupAllSchemas`) で一括設定。手動個別設定禁止
検証方法	DDL 実行後、各シートの入力規則が正しく設定されていることを確認
現状ステータス	充足 — 入力=薄青/自動=薄灰で色分け。プルダウンは `15_mst_dict` 参照。稼働率は 0〜1 制約

NFR-S06: 機密データ保護

項目	内容
カテゴリ	セキュリティ
シナリオ	給与データ（22_bud_headcount）やマイナンバー等の機密情報がシステムに含まれるとき
要件基準	機密度の高いデータへのアクセスが必要最小限のユーザーに制限されること
制約条件	スプレッドシート全体の共有設定は一律。シート単位の保護は可能だが、列・行単位の保護は不可
検証方法	シート保護設定の確認。機密シート（22_bud_headcount 等）のアクセスログ確認
現状ステータス	部分充足 — 22_bud_headcount 保護設定可。単一ユーザー運用で未設定。マイナンバーはシステム外管理

可用性

NFR-A01: GASサービス依存性

項目	内容
カテゴリ	可用性
シナリオ	Google のインフラストラクチャに障害が発生し、GAS または Spreadsheet が利用不可になるとき
要件基準	Google Cloud の SLA (99.9%) に準拠すること。独自の冗長化は不要
制約条件	GAS は Google Cloud に完全依存。オンプレミスやマルチクラウドの冗長化は現実的でない
検証方法	Google Workspace Status Dashboard の監視
現状ステータス	充足 — Google Cloud の SLA に依存。過去に重大な障害なし

NFR-A02: デプロイ手順の確立

項目	内容
カテゴリ	可用性
シナリオ	コード変更を本番環境にデプロイするとき
要件基準	`git commit` → `clasp push` → GAS 確認 → `git push` を厳守
制約条件	GitHub Actions は master/dev push で自動 `clasp push`（`docs/**` は対象外）
検証方法	デプロイ手順書確認 + GitHub Actions ログ確認
現状ステータス	充足 — CLAUDE.md にフロー明文化。自動デプロイ稼働

NFR-A03: ロールバック

項目	内容
カテゴリ	可用性
シナリオ	デプロイ後にバグが発見され、前バージョンに戻す必要があるとき
要件基準	コード: `git revert` + `clasp push` で即時反映。データ: Spreadsheet 版歴から復元可
制約条件	GAS にはネイティブなバージョニング機構がない。Git + clasp の組み合わせで代替
検証方法	ロールバック手順のリハーサル
現状ステータス	充足 — Git の履歴管理 + Spreadsheet の版歴で、コード・データの両方をロールバック可能

NFR-A04: バックアップ・リカバリ

項目	内容
カテゴリ	可用性
シナリオ	誤操作によりスプレッドシートのデータが破損または削除されたとき
要件基準	任意の過去時点の状態に復元可能であること
制約条件	Google Spreadsheet の版歴は自動保存。独自のバックアップ機構は不要
検証方法	版歴からの復元テスト
現状ステータス	充足

バックアップ層:

レイヤー	方法	対象
データ	Google Spreadsheet 版歴（自動）	全スプレッドシートデータ
コード	GitHub (dev/master ブランチ)	全 .js ファイル
仕様書	GitHub docs/ ディレクトリ	全 .md ファイル
インフラ	Google Cloud 冗長化（自動）	GAS ランタイム + Spreadsheet ストレージ

保守性

NFR-M01: テストカバレッジ

項目	内容
カテゴリ	保守性
シナリオ	コード変更後にリグレッションの有無を確認するとき
要件基準	主要フロー（RPA → Action A/B → マート更新）の統合テスト + 結果自動記録
制約条件	GAS には標準テストフレームワーク無し。`10_test_runner.js` で独自実装
検証方法	テスト実行後 `90_test_results` の PASS/FAIL 確認
現状ステータス	部分充足 — 8 スイート T1-T8 / 50+ サブテスト。未カバー: マート個別出力 / エラーパス / 境界値

テストスイート一覧:

ID	テスト名	サブテスト数	カバー範囲
T1	HC RPA	16	給与INV生成、源泉税、社保、法定福利費
T2	Action A	10	INV→TRN転記、ORD残高減算、STL自動作成
T3	Action B	8	STL→TRN決済仕訳、INV残高更新
T4	Datamart	—	全諸表の集計検証
T5	SaaS RPA	—	SaaS INV生成
T6	CAPEX RPA	—	設備投資INV生成（6イベント）
T7	冪等性	8	RPA/Action A/B の二重実行防止
T8	Pipeline RPA	3	パイプラインINV生成

NFR-M02: コードの凝集度・モジュール性

項目	内容
カテゴリ	保守性
シナリオ	新しい RPA 種別や財務諸表を追加するとき
要件基準	機能毎にファイル分離。依存は共有ヘルパー (`00_constants` / `02_helpers`) 経由
制約条件	GAS は読込順序依存。ファイル名の数字プレフィックスで制御
検証方法	ファイル構成レビュー + 依存グラフ確認
現状ステータス	充足 — 21 ファイル / 約 11,400 行。機能別分離（00-03/04/05/06/08/10）

NFR-M03: ドキュメント鮮度

項目	内容
カテゴリ	保守性
シナリオ	コード変更後に関連仕様書が最新の実装を反映していないとき
要件基準	コード変更と同時に関連仕様書を更新すること。CLAUDE.md の「変更時の動作確認テスト」テーブルに準拠
制約条件	ドキュメントはコードと同一リポジトリ (docs/) で管理
検証方法	PR レビュー時にドキュメント更新の有無を確認
現状ステータス	充足 — 37ドキュメント/約7,000行の仕様書群がコードと同一リポジトリで管理

NFR-M04: DDLスキーマ管理

項目	内容
カテゴリ	保守性
シナリオ	新しい列を追加する、または既存列のヘッダー名を変更するとき
要件基準	`setupAllSchemas` で全タブスキーマ一括同期。列の追加/並替が安全に実行可能
制約条件	動的タブ（03/75-78/91-92/90）は DDL 対象外。`28_bud_allocation` D 列以降はクリアの可能性あり
検証方法	DDL 実行後の全タブ目視 + RENAME_MAP フォールバック動作確認
現状ステータス	充足 — setupAllSchemas がスキーマ同期、入力規則、色分け、書式設定、フィルターを一括管理

監査証跡

NFR-T01: 仕訳追跡（INV→TRN）

項目	内容
カテゴリ	監査証跡
シナリオ	監査担当者が特定の仕訳 (TRN) がどの請求 (INV) から生成されたかを追跡するとき
要件基準	INV の `自動仕訳JNL_ID` 列に TRN_ID が記録され、双方向のトレーサビリティが確保されていること
制約条件	—
検証方法	任意の TRN_ID で INV を検索し、元の請求情報が特定可能であることを確認
現状ステータス	充足 — Action A で INV.JNL_ID に TRN_ID 書戻 + TRN.管理 ID に INV_ID

NFR-T02: 決済追跡（STL→TRN）

項目	内容
カテゴリ	監査証跡
シナリオ	決済仕訳がどの入出金明細から生成されたかを追跡するとき
要件基準	STL の `自動仕訳JNL_ID` 列に TRN_ID が記録されていること
制約条件	—
検証方法	任意の決済 TRN_ID で STL を検索し、元の入出金情報が特定可能であることを確認
現状ステータス	充足 — Action B で STL.自動仕訳JNL_ID に TRN_ID を書き戻し

NFR-T03: RPA起票元追跡

項目	内容
カテゴリ	監査証跡
シナリオ	INV がどの予算マスタ行から自動生成されたかを特定するとき
要件基準	INV 摘要に RPA 種別タグ（`【RPA:HC】`/`【RPA:SaaS】` 等）+ 元データ識別情報を含める
制約条件	—
検証方法	INV の摘要を読み取り、元の予算マスタ行が特定可能であることを確認
現状ステータス	充足 — 全 RPA で摘要にタグ + 識別情報を自動挿入。ORD_ID による紐づけも併用

NFR-T04: 操作者追跡

項目	内容
カテゴリ	監査証跡
シナリオ	誰がいつ Action A/B を実行したかを事後的に確認するとき
要件基準	操作者のメールアドレス、操作日時、操作種別が記録されること
制約条件	GAS の `Session.getActiveUser().getEmail()` で取得可能だが、現在未実装
検証方法	—
現状ステータス	未対応 — MAS-008「監査証跡強化」で計画中。Action A/B 実行者の記録は未実装

将来計画 (MAS-008):

Session.getActiveUser().getEmail() を Action A/B に組み込み
操作ログタブの新設（操作日時、操作者、操作種別、対象件数を記録）

NFR-T05: 仕訳レコード不変性

項目	内容
カテゴリ	監査証跡
シナリオ	Action A/B で生成された TRN レコードが事後的に改ざんされるリスクがあるとき
要件基準	42_trn_journal のレコードは作成後の更新・削除を禁止すること（決済日_実績の更新を除く）
制約条件	Spreadsheet のシート保護で列単位の書き込み禁止は可能。ただし管理者は回避可能
検証方法	TRN シート保護設定 + コードレビュー（決済日更新は Action B のみ）
現状ステータス	充足 — TRN 書込は Action A（新規）/ Action B（決済日更新）のみ。孤立 TRN 削除は管理者のみ

NFR-T06: 操作ログ

項目	内容
カテゴリ	監査証跡
シナリオ	システム上で実行された全操作の履歴を時系列で確認するとき
要件基準	主要操作（RPA / Action A/B / マート更新 / DDL）の実行日時・操作者・件数を記録
制約条件	`console.log` は Apps Script ダッシュボードで閲覧可・保持期間制限あり
検証方法	—
現状ステータス	未対応 — `console.log/error` のみ。構造化ログタブは MAS-008 / MAS-010 で対応予定

ドキュメント	関連する要件
ADR-0001: SSOTとしてのINV	NFR-D01
ADR-0005: SpreadsheetをDBとして使用	NFR-P01, NFR-P02, NFR-P05, NFR-S04
ADR-0008: スタースキーマ型データモデル	NFR-D05, NFR-P05
spec_engine — 仕訳エンジン	NFR-D02, NFR-D03, NFR-T01, NFR-T02, NFR-T05
spec_data_validation — データ整合性チェック	NFR-D04
spec_nfr — 非機能要件（旧版）	全要件の旧版
TODO_future — 追加開発案件	NFR-T04 (MAS-008), NFR-T06 (MAS-008, MAS-010)