企業内向け Excel VBA 業務アプリ機能一覧＋ Forguncy v10 対応

01 ファイル入出力・データ取込機能 15機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
Excelファイルを読み込む機能	指定したExcelファイルやシートからデータを取り込む	他部署・他システムからのデータ受領、マスタ更新	ファイル選択UI、シート指定、レイアウト柔軟性	カスタム開発難易度：中実現手段：ファイルアップロードセル型で利用者からファイルを受領し、サーバーサイドコマンドからカスタムWeb API（.NET）でExcelを解析→内部テーブルへ登録。実装：API側はClosedXML／EPPlus等のライブラリで解析（サーバーにExcel本体は不要）。シート名・開始行・列マッピングは「取込レイアウト定義テーブル」に外部化し、レイアウト追加をデータ登録だけで済む構造にする。 ⚠ 標準コマンドにExcel直接読込はない。結合セル・可変レイアウトの「帳票型Excel」は解析が複雑化するため、取込対象を表形式シートに限定する受領ルールを先に決めるのが実務上の近道。
CSVファイルを読み込む機能	CSV形式のデータファイルを読み込み、内部データとして取り込む	基幹システム・周辺システムからのデータ連携ファイル受領	文字コード・区切り文字対応、エラー行処理	標準機能難易度：低実現手段：リストビュー／テーブルの標準インポート機能（Excel・CSV取込）で対応。定型運用はサーバーサイドコマンド化して取込ボタン一つに集約。実装：定型フォーマットは列マッピングを保存して再利用。取込前チェック（件数・必須項目・型）を条件分岐コマンドで挟み、NG時は取込中止＋理由表示。 ⚠ Shift-JIS指定・ダブルクォート内改行・エラー行スキップ等の細かい制御が必要な連携ファイルは、標準インポートで粘らずカスタムWeb API（TextFieldParser等）に寄せて共通取込基盤にする。
固定長ファイルを読み込む機能	バイト数で区切られた固定長テキストファイルを解析・取込む	レガシーシステムからのバッチ連携ファイル受領	レイアウト定義管理、文字コード変換	カスタム開発難易度：中実現手段：カスタムWeb APIで解析。レイアウト定義（項目名・開始位置・バイト長・型・埋め方式）はテーブルに外部化し、APIが定義を読んで汎用的に切り出す方式にする。実装：Shift-JISはEncoding.GetEncoding("shift_jis")でバイト単位に切り出し。数値の前ゼロ・符号表現・暗黙小数点は定義テーブルの属性として持つ。 ⚠ .NET（Core系）でShift-JISを使うには System.Text.Encoding.CodePages の参照登録が必要。全角・半角混在項目のバイト数計算は必ず実データで検証する。
タブ区切りファイルを読み込む機能	TSV形式のファイルを読み込み、内部データとして取り込む	Excelからコピーした貼付データや他ツール出力の取込	区切り文字判定、ヘッダー有無設定	標準機能難易度：低実現手段：CSVと同じ経路（標準インポート）で取り込む。実装：CSV用に作る共通取込Web APIに区切り文字パラメータ（カンマ／タブ）を持たせておけば追加コストほぼゼロで吸収できる。 ⚠ 標準インポートでのタブ区切り指定可否はv10の仕様を要確認。不可ならカスタム側で対応。
XMLファイルを読み込む機能	XML形式のデータファイルを解析し、構造化データとして取り込む	標準化された電文・マスタデータの受領	スキーマ検証、名前空間対応	カスタム開発難易度：中実現手段：カスタムWeb APIで XDocument／XmlSerializer による解析→テーブル登録。スキーマ検証はXSDで実施。実装：本体は「階層構造→リレーショナル変換」の設計。ヘッダ・明細・繰返し要素を親子テーブルに分割し、外部キーで関連付ける。名前空間はXNamespaceで明示。 ⚠ 電文仕様書のオプション項目・繰返し上限を必ず確認。想定外構造の電文は退避テーブルに保全してエラー通知する設計に。
Excelファイルに出力する機能	処理結果・帳票データをExcel形式で出力する	集計結果の配布、報告書の作成	テンプレート適用、書式・数式保持	標準機能難易度：低実現手段：「ページのExcelエクスポート」コマンド／リストビューのExcelエクスポート。帳票品位が必要なものはレポート機能のExcel出力を使う。実装：画面用ページと出力用ページを分離（エクスポート専用ページ）すると、画面都合の装飾に引きずられずレイアウト調整が容易。 ⚠ VBA時代の「数式・マクロ入りブック」の再現は不可。数式はサーバー側で計算済みの値を出力する設計へ転換する（配布ブックにロジックを残さないこと自体が統制改善になる）。
CSVファイルに出力する機能	データをCSV形式でエクスポートする	他システムへのデータ受け渡し、バックアップ	文字コード指定、ヘッダー出力制御	カスタム開発難易度：低実現手段：画面利用者向けの簡易出力は標準のExcelエクスポートで代替。他システム連携用CSVはカスタムWeb APIで生成し、ダウンロード提供または連携フォルダへ配置。実装：文字コード（Shift-JIS／UTF-8／BOM有無）・改行コード・囲み文字・ヘッダー行有無をパラメータ化した共通CSV出力APIを1本作り全業務で使い回す。 ⚠ 連携先の受入仕様（BOM、末尾改行、空文字とNULLの区別）を先に文書で確定させる。ここの曖昧さが連携障害の最頻出原因。
固定長ファイルを出力する機能	指定レイアウトに従った固定長テキストファイルを生成する	レガシーシステムへのデータ連携	パディング方式、改行コード制御	カスタム開発難易度：中実現手段：カスタムWeb APIで生成（読込と同じレイアウト定義テーブルを共用）し、連携フォルダ配置またはダウンロード提供。実装：PadLeft／PadRightでパディング後、Encoding変換してバイト長を最終検証。ヘッダ・明細・トレーラのコントロールトータル（件数・金額）生成も同一APIに含める。 ⚠ 全角=2バイト前提のレイアウトでは文字単位でなくバイト単位のパディング処理が必須。受け側システムでの受入テストを移行計画に必ず組み込む。
PDFファイルに出力する機能	帳票・承認書類をPDF形式で出力・保存する	押印不要の電子承認書類、配布用帳票	ページレイアウト固定、印刷設定保持	標準機能難易度：低実現手段：「ページのPDFエクスポート」コマンド、またはレポート機能のPDF出力（標準対応）。実装：正式書類はレポートで設計し、改ページ位置・ヘッダーフッター・ページ番号を固定。生成PDFは添付ファイルとしてテーブル保存すれば証跡と配布を兼ねられる。 ⚠ フォント埋め込み・罫線再現・改ページはPoCで実物確認。パスワード付きPDFは標準では不可のためカスタムWeb APIで対応。
複数ファイルを一括取込む機能	フォルダ内の複数ファイルをまとめて読み込み、処理する	日次・月次で大量受領するファイルの一括処理	ファイル一覧取得、処理順序制御	カスタム開発難易度：中実現手段：スケジュールタスク（定時起動）＋カスタムWeb APIで受領フォルダを走査（Directory.GetFiles）し、1ファイルずつ取込→処理済フォルダへ移動。実装：ファイル単位の成否をジョブ履歴テーブルに記録し、失敗ファイルはエラーフォルダへ隔離。ファイル名の昇順など処理順序規約を明文化する。 ⚠ Forguncyサーバーのサービス実行アカウントが対象フォルダにアクセスできる権限設計（ドメインサービスアカウント化）が前提条件。ここを最初にインフラ部門と握る。
ファイルを自動振り分ける機能	ファイル名・日付・種別に応じて保存先や処理を振り分ける	受領ファイルの自動仕分け・アーカイブ	命名規則定義、振り分けルール設定	カスタム開発難易度：低実現手段：振り分けルール（ファイル名パターン→移動先・処理種別）をテーブル化し、スケジュールタスク＋カスタムWeb APIがルールを参照して File.Move／Copy を実行。実装：ルールをデータ化しておけば、振り分け先の追加・変更は業務側のマスタメンテだけで完結する。 ⚠ 同名ファイル衝突時の規約（上書き禁止・日時サフィックス付与等）を先に決めておく。未定のまま作ると本番で必ず事故る。
ファイルの文字コードを変換する機能	読み込み・書き出し時に文字コードを変換する	Shift-JIS／UTF-8混在環境でのデータ取込	文字化け検出、変換テーブル管理	カスタム開発難易度：低実現手段：カスタムWeb API内で Encoding.Convert により変換。共通取込・出力APIのパラメータとして実装し単独機能にはしない。実装：連携仕様ごとに文字コードを固定で持つ（レイアウト定義テーブルの属性）。自動判別は誤判定リスクがあるため原則使わない。 ⚠ 機種依存文字（髙・﨑・①等）の変換方針（そのまま／置換／エラー）を業務側と合意しテスト表を作る。対象業界の顧客氏名データでは必ず踏む論点。
ファイルの存在・整合性を確認する機能	処理前にファイルの存在、サイズ、チェックサムなどを検証する	連携ファイルの到着確認、破損チェック	チェックサム検証方式、エラー時の通知方法	カスタム開発難易度：低実現手段：カスタムWeb APIで File.Exists・ファイルサイズ・SHA-256ハッシュを検証し、結果を取込前チェックテーブルに記録。実装：スケジュールタスクで「到着期限までに未到着なら担当者へメール通知」する到着監視ジョブとセットで実装すると運用が完結する。 ⚠ 転送中ファイルの掴み込み防止として「一定時間サイズ不変を確認してから処理」または「完了フラグファイル方式」を連携相手と取り決める。
ファイルをアーカイブ・移動する機能	処理済みファイルを指定フォルダへ移動・圧縮保管する	処理済みファイルの整理、監査証跡としての保管	保管期間管理、命名規則	カスタム開発難易度：低実現手段：取込処理の後段でカスタムWeb APIが YYYYMM フォルダへ移動、月次でZIP圧縮（System.IO.Compression）。保管期限経過分はスケジュールタスクで削除。実装：保管期間はポリシーテーブルで業務別に管理し、削除ジョブは削除ログを残してから実行する。 ⚠ 監査対象ファイルは自動削除ジョブの対象から除外するフラグを必ず設ける。保存年限は監査部門と確定してから実装する。
ZIPファイルを操作する機能	圧縮ファイルの解凍・圧縮を行い、内包ファイルを取り扱う	複数ファイルをまとめた連携パッケージの受領・送付	パスワード付きZIP対応、入れ子ZIP処理	カスタム開発難易度：中実現手段：カスタムWeb APIで System.IO.Compression.ZipFile による圧縮・解凍。取込基盤の前処理（解凍→個別ファイル取込）として組み込む。実装：解凍後の内包ファイル一覧をマニフェストと照合してから取込を開始する（欠落・混入検知）。 ⚠ パスワード付きZIPは標準ライブラリ非対応。OSSライブラリの行内利用審査が必要になるうえ、PPAP廃止の流れもあるため、ファイル授受方式自体の見直し（URL共有・S/MIME等）を連携先と協議する好機。

02 外部連携・通信機能 8機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
外部システムにHTTP/HTTPS通信する機能	REST APIやWebサービスに対してHTTPリクエストを送受信する	他システムのAPIを呼び出してデータ取得・更新	認証方式、タイムアウト、レスポンス解析	標準機能難易度：低実現手段：サーバーサイドの「Webサービスの呼び出し」コマンド（GET/POST、任意ヘッダー・Bearer等の認証ヘッダー設定可）。実装：レスポンスを変数に受け、JSON解析して後続コマンドでテーブルへ反映。APIキー・トークンはパラメータテーブルで管理し画面には出さない。 ⚠ リトライ・タイムアウト・レート制御など堅牢性が要る基幹連携は、標準コマンドで粘らずカスタムWeb API（HttpClient＋再試行ポリシー）側に実装して呼び出す構成が安全。
メールを送信する機能	処理結果や通知をメール（SMTP）で送信する	承認完了通知、エラー通知、帳票配信	宛先管理、添付ファイル対応、メール本文テンプレート	標準機能難易度：低実現手段：「メールを送信する」コマンド（標準）。SMTPサーバーはサーバー管理ポータルで一元設定。添付ファイル・HTML本文に対応。実装：宛先はロール／担当者マスタから動的に取得し、本文はテンプレート文字列＋差し込み変数で共通コマンド化。通知種別ごとの送信ログをテーブルに残す。 ⚠ テスト環境では宛先を強制的にテスト用アドレスへ差し替える仕組み（環境フラグ判定）を必ず入れる。誤送信は対象業界では即インシデント。
共有フォルダへファイルを連携する機能	ネットワーク上の共有フォルダにファイルを置く・取得する	他部署・他システムとのファイル受け渡し	フォルダパス管理、アクセス権確認	設計転換難易度：中実現手段：ファイル操作はすべてForguncyサーバー上で実行されるため、UNCパスへのアクセス可否はサービス実行アカウントの権限で決まる。実行アカウントをドメインのサービスアカウントにして共有フォルダへ最小権限を付与する。実装：読み書きはカスタムWeb API＋スケジュールタスクで実施。パスはパラメータテーブルで環境別管理。 ⚠ VBAとの最大の違い：クライアントPCのローカル／共有フォルダへWebアプリから直接書き込むことはできない。利用者向けは「ダウンロード提供」へ、システム間連携は「サーバー間のフォルダ連携」へ業務フローを再設計する。
FTPでファイルを転送する機能	FTP/SFTPプロトコルでファイルをサーバーに送受信する	外部機関・取引先とのファイル授受	SFTP対応、接続設定の暗号化管理	カスタム開発難易度：中実現手段：カスタムWeb APIで FluentFTP（FTPS）／SSH.NET（SFTP）等のライブラリを利用し、スケジュールタスクから定時送受信。実装：接続先・ポート・認証情報は設定テーブルで管理（パスワードは暗号化保存、可能なら鍵認証）。送受信結果はジョブ履歴テーブルへ記録し失敗時はメール通知。 ⚠ 外部機関接続はFW開放申請・行内セキュリティ標準への準拠確認が先行タスク。利用ライブラリのOSS審査も必要なため、リードタイムを移行計画に織り込む。
外部DBに接続する機能	自社内または外部の別データベースに接続してデータを取得する	基幹システム・周辺システムのデータ参照	接続先切替、認証情報管理	標準機能難易度：低実現手段：「外部データベース接続」（SQL Server／Oracle／MySQL／PostgreSQL／ODBC）でテーブルをリンクテーブルとして取り込み、内部テーブルと同様に画面へバインド（標準機能）。実装：参照系はDB側に専用ビューを作成し読取専用アカウントで接続するのが定石。画面から生テーブルへ直接つながない。 ⚠ 基幹システム・基幹DBへの直接接続は社内ルール上不可のケースが多い。情報系DWH・中間DB経由の参照構成をシステム部門と先に合意する。
Webスクレイピングでデータを取得する機能	Webページからデータを自動取得する	公開情報（レート・指標等）の自動収集	対象サイトの利用規約確認、取得間隔制御	カスタム開発難易度：高実現手段：カスタムWeb APIで HttpClient＋HtmlAgilityPack により取得・解析し、結果をテーブルへ格納。スケジュールタスクで定時実行。実装：JavaScriptレンダリングが必要なサイトはヘッドレスブラウザ（Playwright等）を別プロセス化し、Forguncyは結果テーブルを参照するだけの疎結合にする。 ⚠ サイト構造変更で必ず壊れる前提で、取得失敗の検知・通知と手動代替手順を用意する。可能なら公式API・データ配信サービスへの置き換えを優先検討（レート等は特に）。
Outlookと連携する機能	OutlookのメールボックスやカレンダーをVBAから操作する	承認メールの自動作成・送信、スケジュール連携	Outlookオブジェクトモデルへの依存、バージョン互換性	設計転換難易度：高実現手段：OutlookのCOM操作は不可。メール送信は標準「メールを送信する」コマンドで代替。メールボックス読取・予定表操作が必要な場合は Microsoft Graph API を「Webサービスの呼び出し」／カスタムWeb APIから利用する。実装：Graph利用にはAzure AD（Entra ID）アプリ登録・API権限付与・管理者同意が必要。情シス部門との調整が実装より先。 ⚠ 移行時は「Outlook操作が本当に必要か」から業務を見直すのが先。多くはワークフロー通知＋アプリ内ToDo一覧で代替でき、その方が証跡管理も改善する。
テキストメッセージ・社内チャットに通知する機能	処理完了や異常を社内チャットツール等に通知する	即時通知が必要な処理完了・エラー報告	API接続設定、通知先管理	標準機能難易度：低実現手段：「Webサービスの呼び出し」コマンドで Teams Incoming Webhook／Slack API 等へJSONをPOST。実装：通知フォーマット（タイトル・本文・対象リンク・重要度）を共通コマンド化し、通知先URLは設定テーブルで管理。エラー通知とお知らせ通知でチャネルを分ける。 ⚠ Webhook URLは漏えい＝なりすまし投稿リスク。設定テーブルへのアクセス権限を管理者ロール限定にする。行内チャット製品のAPI利用可否ポリシーも事前確認。

03 データベース接続・データ取得機能 8機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
DBに接続する機能	ODBCやADO等を用いてデータベースに接続・切断する	Oracle、SQL Server、AccessなどのRDBMSへの接続	接続文字列管理、接続プール、タイムアウト設定	標準機能難易度：低実現手段：外部データベース接続を管理ポータル／Builderで登録し、アプリはリンクテーブル経由で利用。接続・切断・プーリングはForguncyが管理するためVBAのような接続管理コードは不要になる。実装：Accessファイル（.mdb/.accdb）は接続対象にせず、この機会にテーブルをForguncy内部DBまたはSQL Serverへ移行する。 ⚠ ODBC経由の特殊DB（DB2等）は事前PoC必須。必要なクライアントドライバはForguncyサーバーへのインストールとバージョン管理が必要。
SQLを実行してデータを取得する機能	SELECT文を実行し、結果をシートや変数に格納する	マスタデータ参照、取引明細照会	動的SQL生成、パラメータバインド、結果件数制御	標準機能難易度：中実現手段：定型参照はリンクテーブル＋リストビュー／「テーブルデータの取得」コマンドで標準対応。複雑な結合・集計はDB側でビュー化してリンクするのが保守性・性能とも最良。実装：どうしても動的SQLが必要な検索（項目可変の高度検索等）はカスタムWeb APIで実装し、必ずパラメータバインドする。 ⚠ VBAでありがちな「画面入力からSQL文字列を組み立てる」実装は移植しない（SQLインジェクションの温床）。検索条件→リストビューのクエリ条件、の標準パターンへ転換する。
SQLを実行してデータを更新する機能	INSERT/UPDATE/DELETE文を実行する	処理結果のDB登録、マスタ更新	トランザクション管理、排他制御	標準機能難易度：低実現手段：「テーブルデータの追加／更新／削除」コマンド（リンクテーブル含む）で画面連動の更新は標準完結。実装：大量一括更新（月次で数十万行等）はコマンドのループでなく、カスタムWeb APIからセットベースSQL（UPDATE … WHERE …）で実行する。 ⚠ リンクテーブルの更新可否はDB側の主キー設定・接続アカウント権限に依存。更新系リンクテーブルは対象を限定し、権限は書込可アカウントと参照専用アカウントを分離する。
ストアドプロシージャを呼び出す機能	DBに定義されたストアドプロシージャを実行する	複雑な業務ロジックをDB側で実行	パラメータ渡し、戻り値・出力パラメータ取得	カスタム開発難易度：低実現手段：カスタムWeb APIで ADO.NET（SqlCommand、CommandType.StoredProcedure）から呼び出し。出力パラメータ・戻り値も取得可能。実装：「ストアド名＋パラメータを受け取り実行して結果を返す」汎用ラッパーAPIを1本作れば、既存ストアド資産をそのまま活用できる。 ⚠ 標準コマンドからのストアド直接実行は不可の前提で計画する（v10時点、要確認）。実行権限はストアド実行専用のDBロールに限定する。
トランザクションを制御する機能	複数のDB更新処理をまとめてコミット／ロールバックする	整合性が必要な一連のデータ更新処理	エラー時のロールバック保証、二重登録防止	カスタム開発難易度：中実現手段：原子性の保証が必要な複数更新は、カスタムWeb APIに集約して SqlTransaction／TransactionScope で明示的に制御するのが確実。実装：「親登録＋明細N件＋残高更新」のような一体処理は1つのAPIエンドポイントにまとめ、Forguncy側からは1コマンドで呼ぶ設計にする。 ⚠ サーバーサイドコマンドに更新コマンドを複数並べた場合の途中失敗時の巻き戻し範囲は必ずPoCで確認し、保証されない前提で更新系はAPI集約を標準方針とするのが安全。
接続情報を安全に管理する機能	DB接続文字列や認証情報をセキュアに保管・取得する	ハードコードを避けたセキュアな接続情報管理	暗号化保存、環境別設定切替	標準機能難易度：低実現手段：外部DB接続情報はサーバー管理ポータルで集中管理され、アプリ・コードへの埋め込みが不要（標準）。環境別は各環境サーバーの設定で切り替える。実装：VBAでハードコードされていた接続文字列の棚卸しを移行前に実施し、接続アカウントを用途別（参照／更新／バッチ）に分離して発行し直す。 ⚠ カスタムWeb API内で独自にDB接続する場合は構成ファイル管理となるため、平文パスワード禁止・構成ファイルのアクセス権制限をコーディング規約に明記する。
大量データを効率的に取得する機能	ページング、カーソル制御等で大量レコードを処理する	月次集計など大量レコードを扱うバッチ処理	メモリ消費制御、処理速度最適化	設計転換難易度：中実現手段：画面はリストビューのサーバーサイドページング＋検索条件の必須化で「全件を画面に出さない」設計へ。バッチ集計はDB側（ビュー・ストアド）に寄せ、Forguncyは起動と結果表示を担う。実装：取込・更新系はチャンク分割（例：1万件単位）で処理し、進捗をジョブ履歴テーブルに記録。 ⚠ 内蔵DBは大量データ・高頻度書込みに不向き。本資料の業務規模なら外部DB（SQL Server等）前提で設計し、「全件シートに展開して処理」というVBA発想は移植しない。
複数DBをまたいだデータを取得する機能	複数のデータベースを結合・参照してデータを取得する	複数システムのデータを統合した帳票作成	リンクサーバー、フェデレーションDB対応	カスタム開発難易度：中実現手段：複数の外部DB接続を登録して画面上で並列参照。本格的な結合が必要なら、（1）DB側リンクサーバーで統合ビューを作る、（2）夜間スケジュールタスクで一方に複製（簡易ETL）してからDB内で結合、のどちらかに寄せる。実装：鮮度要件（リアルタイム要否）で方式を選定。帳票用途は夜間複製で十分なことが多い。 ⚠ リンクテーブル同士のアプリ内結合は性能をPoCで要検証。件数が多い結合はDB側で行うのが原則。

04 データ加工・変換機能 11機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
文字列を加工する機能	トリム、置換、分割、結合、パディングなど文字列操作を行う	コード変換、氏名結合、スペース除去	全角半角変換、文字コード対応	標準機能難易度：低実現手段：Excel互換の数式関数（TRIM／SUBSTITUTE／MID／LEFT／RIGHT／CONCATENATE等）を画面セル・コマンド内の数式で利用（標準）。実装：入力時の整形（前後空白除去等）は「セル値変更時」イベント＋数式で発生源対策するのが効率的。 ⚠ 全角半角変換・カナ変換等の関数の有無はv10関数リファレンスで要確認。無いものはカスタムWeb APIの共通文字列関数群に集約し、各業務でバラバラに実装しない。
日付・時刻を変換・計算する機能	日付形式変換、営業日計算、期間計算などを行う	締め日算出、期限計算、和暦変換	休日カレンダー参照、和暦変換テーブル	標準機能難易度：低実現手段：基本計算は数式（TODAY／DATE／EDATE／DATEDIF等）で標準対応。営業日計算は休日マスタテーブル＋「翌営業日取得」等の共通処理（数式またはカスタムWeb API）を部品化。実装：和暦はTEXT書式または元号変換テーブルで対応。休日マスタは年次更新の運用担当を決めておく。 ⚠ 対象業界固有の休業日（手形交換休止日・システム停止日等）を一般祝日と区別して持てるよう、休日マスタに種別列を設けておくと後で困らない。
数値を変換・丸める機能	単位変換、四捨五入・切捨・切上・偶数丸め等を行う	業務計算における端数処理、単位換算	丸め方式の業務ルール定義	標準機能難易度：低実現手段：ROUND／ROUNDDOWN／ROUNDUP等の数式で標準対応。偶数丸め（偶数丸め）は標準関数にないため、カスタムWeb APIで Math.Round(値, 桁, MidpointRounding.ToEven) を共通関数化。実装：丸め仕様（方式・桁・適用箇所）を機能別に仕様書化し、計算は可能な限りサーバー側の共通関数へ集約する。 ⚠ VBA時代の「セルごとに微妙に違う丸め」は移行時の検算不一致の主因。移行前に現行の丸め仕様の棚卸し（暗黙仕様の文書化）を必ず行う。
コード変換・名称解決する機能	コード値を名称や別コードに変換するマスタ参照処理	勘定科目コード変換、支店コード名称変換	マスタの鮮度管理、変換テーブルのメンテナンス	標準機能難易度：低実現手段：マスタをテーブル化し、テーブル間リレーション＋連結フィールド表示、またはコンボボックス型セルの「値＝コード／表示＝名称」設定で名称解決（標準）。VLOOKUP数式も利用可。実装：マスタメンテ画面（カテゴリー18参照）とセットで整備し、Excel配布のコード表を廃止する。 ⚠ 大量明細の名称変換を画面数式（VLOOKUP多用）でやると性能劣化する。一覧・帳票用途はDB側JOIN（ビュー）で変換済みデータを渡す。
データを正規化する機能	表記ゆれ・重複データを統一形式に変換する	氏名・住所・電話番号のクレンジング	正規化ルールの定義、業務ルールとの整合	カスタム開発難易度：中実現手段：カスタムWeb APIに正規化関数群（全半角統一・空白除去・カナ統一・電話番号整形等）を実装し、取込処理で必ず通す。入力画面側はセル型＋入力規則で発生源から抑止。実装：正規化ルールは業務側と合意した仕様書ベースで実装し、変換前の原本値も併せて保存する（監査・照合用）。 ⚠ 既存データのクレンジングは移行時に一括実施するのが最も安い。移行リハーサルで正規化結果のサンプル検収を業務側と行う。
条件分岐によるデータ加工をする機能	値の条件に応じて異なる加工・変換を適用する	区分に応じた計算ロジックの切替	条件分岐の複雑度管理、ルールのメンテナンス性	標準機能難易度：低実現手段：数式（IF／IFS／SWITCH）とコマンドの「条件分岐」で標準対応。実装：区分→計算方式の対応はルールマスタテーブルに外部化すると、条件追加が業務側のデータ登録で完結しノーコード運用になる。 ⚠ 条件分岐の多段ネストは可読性が急落する。3段を超えたらカスタムWeb API化（テスト可能なコードに落とす）を検討する目安とする。
データをソートする機能	複数キーによる昇順・降順でのデータ並べ替え	帳票出力前の表示順序整理	ソートキー定義、安定ソートの保証	標準機能難易度：低実現手段：リストビューの既定ソート設定・ヘッダークリックソート、「テーブルデータの取得」の並び順指定で標準対応。帳票はレポート側のソート設定。実装：複合キーの並び順が業務仕様であるもの（帳票の出力順等）は画面操作に任せず、ビュー・レポート定義側で固定する。 ⚠ 同順位の並びを安定させたい場合は最終ソートキーに主キーを追加しておく（環境により並びが揺れるのを防ぐ）。
データを結合する機能	複数データソースをキーで突き合わせて結合する	取引データとマスタの結合	結合方式（内部・外部・完全）の選択	標準機能難易度：中実現手段：テーブル間リレーション＋連結フィールドで参照系結合は標準対応。外部結合・多テーブル結合など複雑なものはDB側でビュー化してリンクテーブルとして利用。実装：「画面で結合を組み立てる」のではなく「結合済みのビューを画面に渡す」を基本パターンにすると性能・保守とも安定する。 ⚠ 内部テーブル×外部リンクテーブルをまたぐ結合は性能をPoCで要検証。遅い場合は夜間複製で同一DB内に寄せる。
データをフィルタリングする機能	条件に合致するデータだけを抽出・除外する	対象期間・対象部署のデータ絞り込み	フィルタ条件の動的指定	標準機能難易度：低実現手段：リストビューのフィルタ条件（画面の検索条件セルと連動）、「テーブルデータの取得」コマンドの条件指定で標準対応。実装：「条件セルが空なら条件を無視する」設定を活用し、空欄＝全件の動作規約を全画面で統一する。 ⚠ 権限によるデータ絞り込み（自部署のみ等）は画面フィルタでなくテーブルの行レベルアクセス制御で行う（カテゴリー12参照）。画面フィルタは統制にならない。
データ型を変換する機能	文字列・数値・日付型の相互変換を行う	取込データの型変換、出力フォーマット変換	型変換エラーの検出と処理	標準機能難易度：低実現手段：数式（TEXT／VALUE／DATEVALUE等）＋セル型の書式設定で標準対応。テーブルのフィールド型を正しく設計すれば画面上の変換は最小化できる。実装：取込時の型不正は取込API側で検出し、エラーレコードを理由付きで退避テーブルへ隔離→一覧表示・修正再取込の流れを共通化。 ⚠ VBAの暗黙型変換（"001"が1になる等）に依存した既存ロジックは移行時の差異要因。コード類は必ず文字列型で設計する。
データをマスクする機能	個人情報・機密情報の一部を伏字・マスク処理する	ログ出力、開発・テスト環境へのデータ提供	マスク対象フィールドの定義・管理	カスタム開発難易度：低実現手段：列単位の秘匿はテーブルのフィールドアクセス権限（ロール別非表示）で標準対応。部分マスク（口座番号の下4桁のみ表示等）は表示用フィールドを数式またはカスタムWeb APIで生成して表示側に使う。実装：マスク対象項目の一覧（データ分類台帳）を先に作り、画面・帳票・エクスポート・ログの4経路すべてに適用する。 ⚠ 画面はマスクしてもExcelエクスポートに生データが乗る「経路漏れ」が典型事故。出力機能側の権限・出力列設計まで含めてレビューする。

05 データ集計・分析機能 8機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
合計・件数を集計する機能	指定条件でのSUM・COUNT・AVG等の集計値を算出する	日次・月次の取引件数・金額集計	集計条件の動的変更、大量データ対応	標準機能難易度：低実現手段：数式（SUM／COUNT／AVERAGE、SUMIF系）とリストビューの集計行（合計・件数・平均）で標準対応。実装：数十万行規模の集計はDB側の集計ビュー（GROUP BY済み）をリンクし、画面は結果を表示するだけにする。 ⚠ 「明細全件を画面に読み込んでから集計」はWebでは成立しない。集計はサーバー／DB側で行うのが大原則。
クロス集計する機能	行・列の2軸でデータを集計し、マトリクス形式で出力する	部署別・月別の費用集計表作成	集計軸の柔軟な定義、小計・総計の自動追加	標準機能難易度：中実現手段：ピボットテーブル型セルで行×列のクロス集計を標準実現（小計・総計・集計方法の切替に対応）。実装：元データが大量の場合はDB側で事前集計した中間テーブルをピボットのソースにして応答性を確保。 ⚠ Excelピボットとの操作感・機能差（計算フィールド、手動レイアウト調整等）はPoCで利用部門に実物を触ってもらい確認する。定型帳票化できるものはレポートのマトリクス表に落とす方が安定。
期間比較・前年比を計算する機能	今期と前期など期間を比較した増減・比率を算出する	月次業績レポートの前月・前年比較	基準期間の定義、比率算出の端数処理	標準機能難易度：低実現手段：期間別集計をDB側ビュー（当期・前期を列持ち）で用意し、増減・比率は画面数式またはビュー内で算出。レポート機能で帳票化。実装：基準期間（会計年度・暦年・移動12ヶ月）の定義を期間マスタとして持ち、画面から選択させる。 ⚠ 比率の端数処理と分母ゼロ時の表示規約（「-」表示等）を全帳票で統一。VBA帳票ごとにバラバラだった箇所の標準化チャンス。
ランキング・順位付けする機能	数値の大小に基づくランキングを算出する	取引量・残高の上位行一覧作成	同順位の処理、順位変動表示	標準機能難易度：低実現手段：RANK数式、またはリストビューの降順ソート＋表示件数制限で上位N件表示（標準）。実装：同順位規約（RANK／DENSE_RANK相当）が業務仕様なら、DB側ウィンドウ関数で順位列を付与したビューを使うのが確実。 ⚠ 前回順位との変動表示が必要な場合は順位スナップショットテーブル（期別保存）を設計に含める。
移動平均・累計を計算する機能	時系列データの移動平均や累計値を算出する	トレンド分析、月次累計推移の可視化	算出期間の定義、欠損データの扱い	カスタム開発難易度：中実現手段：外部DBのウィンドウ関数（AVG/SUM OVER）でビュー化するのが最短・最速。内蔵DBのみの構成ならカスタムWeb APIで算出して結果テーブルへ書き戻す。実装：算出結果はグラフ型セルにバインドしてトレンド表示。日次バッチで前日分までを更新する運用に。 ⚠ 欠損期間（取引ゼロの月）の扱い（0埋め／除外）で数字が変わる。仕様として明文化してから実装する。
条件付き集計をする機能	SUMIF・COUNTIFに相当する条件付き集計を行う	特定区分・コード別の集計	複合条件への対応	標準機能難易度：低実現手段：SUMIF／COUNTIF／SUMIFS／COUNTIFS等の数式で標準対応。実装：ダッシュボード的な複数集計値の表示は、集計専用ビュー1本＋画面セル参照の構成にすると保守しやすい。 ⚠ 集計対象が大量の場合の数式再計算コストに注意。画面表示のたびに全件走査になっていないかPoCで応答時間を確認。
ピボット集計する機能	ピボットテーブルを動的に生成・更新する	経営管理用の多次元分析表作成	ピボット定義の保存、データ更新連動	標準機能難易度：中実現手段：ピボットテーブル型セル＋グラフ型セルの連動で、Excelピボットで行っていた定型分析業務を移行（標準機能）。実装：「定型の切り口」はピボット定義済みページとして提供し、利用者は期間・部署などのパラメータだけ選ぶ構成が実用的。 ⚠ 「利用者が自由に軸を組み替えて探索する」高度分析はBIツール（Power BI等）の守備範囲。ForguncyのDBをBIから参照する役割分担を移行方針として先に決めると迷走しない。
集計結果をグラフ化する機能	集計データを棒グラフ・折れ線グラフ等で可視化する	報告用資料への図表埋め込み	グラフ種別・書式の統一管理	標準機能難易度：低実現手段：グラフ型セル（棒・折線・円・複合等）でダッシュボードページを構成（標準機能）。データはテーブル／集計ビューに連動し自動更新。実装：配色・凡例・単位表記の標準をデザインガイドとして1ページ作り、全画面で統一する。 ⚠ 印刷・配布資料に入れるグラフはレポート機能側で出力する（画面キャプチャ運用にしない）。グラフ種別の対応範囲はレポートと画面で異なる場合があるためPoCで確認。

06 データ照合・検証機能 10機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
二データソースを突き合わせる機能	2つのデータセットを同一キーで照合し、一致・不一致を判定する	基幹システムデータと管理部門データの照合	照合キーの定義、許容誤差の設定	カスタム開発難易度：中実現手段：カスタムWeb APIで両テーブルを取得しキー照合（Dictionary突合）→結果（一致／片側のみ／金額不一致）を照合結果テーブルへ書き込み。大量件数は SQL（FULL OUTER JOIN／EXCEPT）でDB側照合。実装：照合キー・比較項目・許容誤差を照合定義テーブルにパラメータ化した「汎用照合エンジン」を1本作れば、複数の照合業務で使い回せる。 ⚠ 許容誤差（円未満・件数ズレ）の扱いは業務仕様として文書化。照合元データのスナップショット（いつ時点のデータ同士か）も結果に記録しないと監査で説明できない。
差異を抽出する機能	照合結果から不一致レコードのみを抽出・一覧化する	差異原因の調査・報告書作成	差異区分（追加・削除・変更）の分類	カスタム開発難易度：低実現手段：上記の照合結果テーブルに差異区分（新規／削除／変更、変更時は項目別の旧新値）を持たせ、リストビュー＋区分フィルタで一覧表示。Excelエクスポートで報告書化。実装：差異への対処状況（調査中／解消／許容）の管理列を付ければ、差異管理台帳がそのままアプリ化できる。 ⚠ 差異ゼロ件の場合も「照合を実施しゼロ件だった」証跡（実行ログ）を残すこと。監査上は「実施した事実」の記録が必須。
チェックデジットを検証する機能	口座番号・コード等のチェックデジットの正当性を確認する	取込データの番号妥当性チェック	アルゴリズム種別（MOD11等）対応	カスタム開発難易度：低実現手段：MOD10／MOD11等のアルゴリズムをカスタムWeb APIの共通関数として実装し、入力時（セル値変更イベントから呼出）と取込時（取込API内）の両方で同じ関数を通す。実装：コード体系別のアルゴリズム・重み付けは検証定義テーブルで管理し、コード体系追加に実装変更なしで対応。 ⚠ 行内の採番仕様書と突き合わせてアルゴリズムを確定する。VBA内の実装が仕様書と食い違っている（独自修正されている）ケースが棚卸しで見つかりがち。
データの重複を検出する機能	同一キーの重複レコードを検出・除外する	二重登録防止、データクレンジング	重複判定キーの定義、重複時の優先ルール	標準機能難易度：低実現手段：登録時の防止はテーブルの一意制約＋登録前の「テーブルデータの取得」件数チェック（標準）。既存データの重複洗い出しは SQL の GROUP BY～HAVING COUNT>1 をビュー化して一覧表示。実装：重複時の優先ルール（最新優先・手入力優先等）は業務仕様化し、マージ処理はカスタムWeb APIで実装。 ⚠ 「防止（制約）」と「検出（洗い出し）」は別機能として設計する。制約だけ入れると取込バッチが重複データで全件エラーになる事故があるため、取込側は事前検出→退避の流れに。
入力値の範囲・形式を検証する機能	数値範囲・日付形式・文字数等の入力バリデーションを行う	帳票入力データの業務ルール検証	バリデーションルールの外部定義・変更容易性	標準機能難易度：低実現手段：セル型の「入力規則」（数値範囲・日付・文字数・正規表現等）で入力時に標準対応。送信前の横断チェックはコマンドの条件分岐で実施。実装：エラー表示の方式（セル横メッセージ・色）と文言テンプレートを全画面で統一する。 ⚠ データの入口は「画面」と「ファイル取込」の2つ。画面の入力規則だけでは取込データを守れないため、同じ検証を取込API側にも実装する（検証ロジックの二重管理を避けるならAPI側に寄せて画面からも呼ぶ）。
必須入力を検証する機能	必須フィールドの入力有無を確認する	申請書・登録データの完全性確認	必須条件の動的変更対応	標準機能難易度：低実現手段：テーブルの必須フィールド設定＋セル型の入力規則（必須）で標準対応。実装：「区分Aのときだけ項目Bが必須」のような条件付き必須は、送信ボタンのコマンド冒頭に条件分岐チェックを共通パターンとして実装。 ⚠ 必須エラー時に「どの項目が未入力か」を明示する（先頭項目へのフォーカス移動・色付け）。ここのUX品質が現場の移行受容度を大きく左右する。
参照整合性を検証する機能	コード値がマスタに存在するか確認する	取込データのコード妥当性確認	マスタ参照タイミング、存在しない場合の処理	標準機能難易度：低実現手段：画面入力はコンボボックス型（マスタバインド）にして不正コードを構造的に入力不能にするのが第一。取込データはAPI／コマンドでマスタ照合し、不一致レコードを理由付きで退避テーブルへ。実装：廃止コード（有効期限切れマスタ）の扱いを設計に含める（参照は許可・新規入力は不可、等）。 ⚠ マスタ更新と取込のタイミング競合（取込中にマスタ変更）に注意。日次バッチはマスタ更新後に実行する順序をジョブ設計で保証する。
金額の合計を検証する機能	明細合計と合計行・トータル行の一致を確認する	帳票・ファイルのバランスチェック	許容誤差（円未満端数）の設定	標準機能難易度：低実現手段：SUM数式で明細計を算出し、コマンドの条件分岐で合計値と比較（ABS(差)≦許容値）。NG時は登録をブロックしメッセージ表示（標準の組み合わせ）。実装：バランスチェックの結果（OK/NG・差額）を検証ログに残し、NG時の承認付き強行登録（理由必須）を業務要件に応じて用意。 ⚠ 許容誤差の値と根拠（円未満端数・消費税差異等）を業務側と文書で合意する。「なんとなく1円まで許容」は監査指摘の対象。
件数と金額の整合性を検証する機能	ファイル内のレコード件数・金額合計とヘッダー情報を突き合わせる	連携ファイルのコントロールトータル確認	ヘッダー・トレーラーレコードの解析	カスタム開発難易度：中実現手段：ファイル取込API（カテゴリー01）の中でヘッダ／トレーラのコントロールトータルと明細集計を照合し、NG時は取込全体を破棄（部分取込を残さない）してジョブ履歴に理由を記録。実装：CT検証は取込基盤の必須ステップとして共通化し、業務別にスキップ可否を設定できるようにする。 ⚠ 「明細は取り込めたがCTが合わない」状態を中途半端に残すと二次被害になる。オールオアナッシングをトランザクションで保証する。
前回処理との差分を検証する機能	前回取込データと今回データの変化点を検出する	増分更新処理前の変更箇所特定	比較基準の保存方式、変更履歴の保持	カスタム開発難易度：中実現手段：取込ごとにスナップショットを世代管理テーブル（取込ID付き）へ保存し、SQL EXCEPT またはカスタムWeb APIで前回世代と比較→差分のみ後続処理へ渡す。実装：差分検出結果（追加・変更・削除件数）をジョブ履歴に記録し、想定外の大量差分（前回比N倍等）は処理を保留して人の確認を挟む安全弁を付ける。 ⚠ 世代の保持数×データ量でストレージが膨らむ。保持世代数と圧縮・アーカイブ方針を設計時に決める。

07 画面・入力フォーム機能 8機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
入力フォームを表示する機能	ユーザーが値を入力するためのユーザーフォームを表示する	検索条件入力、申請書の入力	UI部品の種類・数、バリデーションとの連動	標準機能難易度：低実現手段：ページ上にセル型（テキスト・コンボ・日付・数値等）を配置してフォームを設計（標準）。Excelライクなグリッド設計のため、VBAユーザーフォームより自由度は高い。実装：「入力→確認→完了」のページ遷移、ラベル位置・必須マーク・ボタン配置などのフォーム標準パターンを最初の1本で確立し、以降の画面で複製する。 ⚠ 現行VBAフォームの再現ではなく、Web標準のUX（Tabオーダー・Enter動作・エラー表示）で再設計する。キーボード操作中心の熟練者向け画面はTabオーダー設計を丁寧に。
コンボボックス・リストで選択する機能	選択肢リストから値を選ばせる	区分・コード・対象期間の選択	マスタ連動リスト、動的絞り込み	標準機能難易度：低実現手段：コンボボックス型セル（テーブルバインド、値と表示の分離、親子連動絞り込み）で標準対応。実装：部店→課、勘定科目大分類→中分類のような連動絞り込みは標準設定で実現。選択肢の表示順・廃止コードの除外はバインド元をビュー化して制御。 ⚠ 選択肢が数百件を超える場合は検索型（入力による絞り込み）の設定を検討。全件ドロップダウンは実用にならない。
チェックボックスで選択する機能	複数選択肢を任意にON/OFFで選択させる	出力項目の選択、対象条件の指定	全選択・全解除ボタン	標準機能難易度：低実現手段：チェックボックス型セル／チェックボックスリストで標準対応。実装：全選択・全解除はボタンのコマンド（対象セルへ一括値設定）で実装。選択状態を検索条件やエクスポート列制御に連動させる。 ⚠ 特になし。標準機能の範囲で完結する。
カレンダーで日付を入力する機能	カレンダーUIで日付を選択・入力させる	検索対象期間、処理基準日の入力	営業日のみ選択制御、前後関係バリデーション	標準機能難易度：低実現手段：日付型セルのカレンダーピッカーで標準対応。実装：営業日制御は「選択後に休日マスタと照合し、休日なら警告＋翌営業日を提案」する検証方式が保守的で確実（ピッカー自体の選択制限はJSカスタマイズになるため）。期間の前後関係（From≦To）は入力規則＋条件分岐で検証。 ⚠ 基準日の既定値（当日／前営業日）は業務ごとに規約化し、営業日計算の共通処理（カテゴリー04）を必ず経由させる。
ダイアログで確認を求める機能	処理実行前にユーザーに確認を求めるダイアログを表示する	データ更新・削除前の誤操作防止	キャンセル処理との連動	標準機能難易度：低実現手段：「メッセージを表示する」コマンド（OK／キャンセルの分岐）で標準対応。実装：破壊的操作の確認文言には対象件数・対象名を差し込む（「〇〇支店の12件を削除します」）。削除は論理削除を基本とし、物理削除は管理者機能に限定する。 ⚠ 確認ダイアログの多用は形骸化を招く。「取り消せる操作は確認なし・取り消せない操作のみ確認」の原則で設計する。
入力値をリアルタイム検証する機能	入力中または入力完了時に即時バリデーションする	入力ミスの早期発見	エラー表示方式、フォーカス制御	標準機能難易度：低実現手段：セル型の入力規則（即時チェック）＋「セル値変更時」イベントのコマンドで業務チェック（マスタ照合・関連項目整合）を実行（標準の組み合わせ）。実装：エラーはメッセージセル・色替えで当該項目の近くに表示。重い検証（DB照合）は変更時イベント、軽い形式チェックは入力規則、と役割分担する。 ⚠ 変更時イベントにDB照会を多用すると入力のたびに待ちが発生する。体感応答をPoCで確認し、必要なら送信時一括検証に寄せる。
進捗を表示する機能	処理中の進捗状況をプログレスバー等で表示する	時間のかかるバッチ処理の進行確認	処理中のキャンセル対応	カスタム開発難易度：中実現手段：標準は「読み込み中の表示」（スピナー）まで。％進捗が必要なら、処理側がジョブ進捗テーブルを更新し、画面側が定期再読込またはJavaScriptで進捗率を表示する構成。実装：キャンセルは中断フラグをテーブルに立て、処理側がチャンク境界で参照して安全に停止する方式に。 ⚠ そもそも数分かかる処理を画面で待たせる設計にしない。「実行受付→バックグラウンド処理→完了通知（メール／画面の処理状況一覧）」への転換がWebアプリの正道で、利用者の体感も改善する。
画面の表示・非表示を制御する機能	権限や処理状態に応じて画面要素を動的に切替える	権限別に操作可能な項目を制御する	表示ロジックと権限管理の連動	標準機能難易度：低実現手段：「セルプロパティの設定」コマンド（表示／非表示・活性／非活性・読取専用）＋ロール判定の条件分岐、ページ単位はロール別表示権限で標準対応。実装：状態（申請中は編集不可等）による制御はステータス値を条件にした共通パターンをテンプレ化する。 ⚠ ボタン非表示はあくまでUI制御。サーバー側の権限（テーブル・コマンドの実行権限）を併せて設定しないと、画面迂回でのアクセスを防げない（カテゴリー12参照）。

08 検索・抽出・フィルタ機能 7機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
条件指定で検索する機能	複数条件を組み合わせてデータを検索し、結果を表示する	取引照会、顧客情報検索	条件の組み合わせ方（AND/OR）、空条件の扱い	標準機能難易度：低実現手段：検索条件セル＋リストビューのクエリ条件連動（AND／OR複合条件）で標準対応。実装：「条件セルが空なら当該条件を無視」の設定で空欄＝全件の動作を統一。検索実行はボタン起動（自動検索にしない）で大量データでも安全に。 ⚠ 無条件検索（全件表示）を許すかは業務・性能要件で決め、許さない画面は「最低1条件必須」のチェックを送信前に入れる。
前方一致・部分一致で検索する機能	文字列の前方一致・含む検索を行う	名称・摘要等テキスト項目での絞り込み	ワイルドカード対応、全角半角の統一	標準機能難易度：低実現手段：リストビューの検索条件演算子「を含む」「で始まる」で標準対応。実装：全角半角・カナ・大文字小文字の同一視が必要な検索（氏名・企業名）は、正規化済みの検索用列（カナ統一・半角統一）をテーブルに追加して、その列を検索対象にするのが実務解。 ⚠ 部分一致検索はインデックスが効かない（先頭ワイルドカード）。大量テーブルでの中間一致は応答性をPoCで確認し、必要ならDB側の全文検索を検討。
範囲指定で絞り込む機能	数値・日付の上限下限を指定してデータを絞り込む	期間内の取引抽出、金額帯での絞り込み	範囲境界値（以上・超過）の定義	標準機能難易度：低実現手段：リストビューのフィルタ条件「以上・以下・範囲」で標準対応。実装：境界の含む／含まないは画面ラベルで明示（「〇日以降（当日含む）」）。期間指定はFrom≦Toの入力検証をセットで。 ⚠ 日付範囲の終端は「≦2026/06/30」でなく「＜2026/07/01」で持つと時刻付きデータの取りこぼしを防げる（日時型フィールドの場合の定石）。
複数値で絞り込む機能	リスト形式で複数の値を指定して一括絞り込みする	複数支店・複数勘定科目の同時指定	大量コードリストへの対応	カスタム開発難易度：中実現手段：選択肢が少数固定ならチェックボックスリスト＋OR条件で標準対応。任意個数のコード指定（Excelから支店コードを貼り付けて検索等）は、テキストエリア入力→カスタムWeb APIでIN検索→結果テーブル表示の構成。実装：選択済みコードを一時テーブルに展開してJOINで絞り込む方式なら標準コマンドの範囲でも構成可能。 ⚠ 貼り付け入力は区切り（改行・カンマ・タブ）の揺れと不正コードの扱い（無視／エラー）を仕様化してから実装する。
並べ替え条件を指定する機能	ユーザーが任意のソートキー・順序を指定する	帳票の表示順変更、優先順位の変更	複数キーの優先順位、安定ソート	標準機能難易度：低実現手段：リストビューのヘッダークリックソート＋既定ソート設定で標準対応。実装：複数キーソートが定型業務なら「並び順」選択コンボ（定義済みパターン）を用意する方が、利用者が毎回組み立てるより実用的。 ⚠ 特になし。標準機能の範囲で完結する。
検索結果をエクスポートする機能	検索結果をExcel・CSVで出力する	検索結果の配布・二次利用	出力列の選択、件数上限設定	標準機能難易度：低実現手段：リストビューのExcelエクスポート（絞り込み結果が対象）で標準対応。実装：出力列を画面と変えたい場合はエクスポート専用ページ（列構成を出力用に調整）を分離。出力操作は必ずログに記録する（カテゴリー14参照）。 ⚠ 個人情報・機密データを含む一覧のエクスポート権限はロールで制限し、「閲覧はできるが出力はできない」役割分離を権限設計に含める。
検索条件を保存・呼び出す機能	よく使う検索条件をテンプレートとして保存・再利用する	定型業務の繰り返し検索作業の効率化	条件テンプレートの管理・共有方法	カスタム開発難易度：低実現手段：標準UIはないため、検索条件テーブル（ユーザーID・条件名・各条件値）＋「保存」「呼出」ボタンのコマンドで自作する。実装：呼出時は保存値を各検索条件セルへ一括セットして検索実行。共有フラグを付ければ部署共通の定型条件も配布できる。 ⚠ 検索画面の条件項目を将来追加した場合の互換性（保存済み条件に無い項目の既定値）を最初に決めておく。

09 帳票・レポート出力機能 8機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
テンプレートに差し込んで帳票を作成する機能	定型Excelテンプレートに値を差し込んで帳票を生成する	報告書・承認書類の定型帳票作成	テンプレート管理、差し込み位置の保守性	標準機能難易度：中実現手段：レポート機能でテンプレートを再設計し、テーブル／ビューをデータバインドして出力（標準）。既存Excelテンプレートの「完全再現」が必須の帳票のみカスタムWeb API＋Excelライブラリで差し込み。実装：帳票棚卸しで「様式改訂可」「レイアウト厳守（当局提出等）」に分類し、前者はレポートで作り直す方が総コストが安い。 ⚠ 「Excel様式の完全踏襲」を全帳票に適用すると工数が跳ね上がる。様式簡素化の合意形成を移行プロジェクトの初期タスクに入れるのが実務上の最重要ポイント。
明細と合計を含む帳票を作成する機能	明細行と小計・総計を自動生成した帳票を出力する	費用明細書、残高一覧表の作成	グルーピングロジック、小計行の挿入	標準機能難易度：低実現手段：レポート機能のグループ化＋グループフッター（小計）・レポートフッター（総計）で標準対応。実装：グループキー（部署→科目等）の階層はビュー側で整えてからバインドすると、レポート定義がシンプルに保てる。 ⚠ 小計値はレポートの集計機能で算出し、データ側の「小計行レコード」混在方式（VBAでありがち）は移植しない。データと表現の分離が保守性の要。
複数シートにわたる帳票を作成する機能	シート別にデータを分割・生成する帳票を出力する	部署別・月別に分かれた集計資料	シート命名規則、シート間リンク	カスタム開発難易度：中実現手段：カスタムWeb API＋Excelライブラリ（ClosedXML等）で部署別・月別にシート分割したブックを生成し、ダウンロード提供またはフォルダ配置。実装：シート名規約・目次シート・シート間リンクも生成ロジックに含める。生成条件（対象期間・部署）は画面から受け取る。 ⚠ 「シート分割が本当に必要か」を再考する価値あり。閲覧目的なら部署選択コンボ付きの照会ページの方が便利で、配布物だけシート分割にする等の整理ができる。
ページ設定・印刷設定を制御する機能	用紙サイズ・向き・余白・ヘッダーフッターを設定する	A4縦・横など形式を統一した帳票印刷	印刷プレビュー、印刷範囲の自動設定	標準機能難易度：低実現手段：レポート機能で用紙サイズ・向き・余白・ヘッダーフッター（ページ番号・出力日時・出力者）を設定（標準）。実装：行内標準の帳票ヘッダーフッター（機密区分表示を含む）をテンプレート化し全帳票へ適用する。 ⚠ 印刷はブラウザ経由でなくPDF出力→PDFから印刷の運用に統一すると、環境差による印刷ズレを排除できる。
帳票に画像・ロゴを挿入する機能	会社ロゴや印影画像を帳票に挿入する	正式書類としての体裁整備	画像パス管理、サイズ・位置の固定	標準機能難易度：低実現手段：レポートに画像リソースを配置（標準）。ページ出力でも画像セルで対応可能。実装：ロゴ等の共通画像はリソースとして一元管理し、差し替えが1箇所で済むようにする。 ⚠ 印影画像は「誰の印影をいつ誰が出力したか」の統制が必要。印影付き帳票は承認済みステータスのデータからのみ出力可とし、出力ログを必須化する。電子承認への移行（印影廃止）も併せて検討価値あり。
条件付き書式を適用する機能	値の条件に応じてセルの色・フォントを動的に変更する	差異・超過値のハイライト表示	書式ルールの定義・管理	標準機能難易度：低実現手段：画面はセルの条件付き書式設定、帳票はレポート側の式による書式制御で標準対応。実装：強調ルール（超過＝赤、警告＝黄等）の配色標準を決めて全画面・全帳票で統一する。 ⚠ 白黒印刷される帳票では色だけに頼らず記号（▲・※）併用の表現規約にする。
帳票をPDF変換する機能	出力したExcel帳票をPDF形式に変換する	電子申請・配布用の帳票ファイル作成	変換品質、パスワード設定対応	標準機能難易度：低実現手段：レポート機能から直接PDF出力（標準）。「Excelで作ってからPDF変換」という2段階自体が不要になる。実装：生成したPDFは添付ファイルフィールドに保存して出力履歴と紐づけると、再出力・監査対応が容易。 ⚠ パスワード付きPDF・電子署名付きPDFが要件の場合はカスタムWeb API（PDFライブラリ）で対応。要件の有無を帳票棚卸しで先に確認する。
帳票を一括出力する機能	複数条件・複数対象の帳票をまとめて出力する	月次で全部署分の帳票を一括生成	出力件数・処理時間の管理	カスタム開発難易度：中実現手段：スケジュールタスク＋繰り返し処理で対象（全部署等）ごとにレポート生成→サーバー保存またはZIP化してダウンロード提供／メール配信。実装：1部あたりの生成時間×部数を試算し、月次一括は夜間ジョブ化。生成結果の成否一覧をジョブ履歴で確認できるようにする。 ⚠ 生成中の部分失敗（1部署だけデータ不備等）の扱いを決める：全体中断か、スキップして失敗一覧報告か。業務ごとに要件が異なるためパラメータ化推奨。

10 Excel操作・ワークシート制御機能 9機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
シートを動的に追加・削除する機能	処理内容に応じてワークシートを動的に生成・削除する	月別・部門別シートの自動生成	シート名の命名規則、上限数管理	設計転換難易度：中考え方の転換：「シート＝データの切り口（年月・部門）」はテーブルの列として持ち、画面はフィルタ（年月選択コンボ等）で切り替える設計に置き換える。ページを動的に増やす発想は捨てる。実装：配布物としてシート分割Excelが必要な場合のみ、出力時にカスタムWeb APIで生成する（カテゴリー09参照）。 ⚠ この転換はデータ正規化（横持ち→縦持ち）を伴うため、移行時のデータ変換設計とセットで計画する。正規化により年度切替時の「シート増設作業」自体が消滅するメリットが大きい。
セルの値・数式を操作する機能	プログラムからセル値の読み書き、数式の設定を行う	集計値の書込、参照数式の自動設定	相対・絶対参照の管理	設計転換難易度：低考え方の転換：画面セルの値は「セルプロパティの設定」コマンド・数式（設計時定義）で対応。一方、VBAのRangeループによる一括データ処理はテーブル操作（コマンド／SQL）に置き換える。実装：「データはテーブル、画面は表示」の分離を徹底すると、数式の参照崩れ（行挿入でズレる等）というVBA保守の悩みが構造的に消える。 ⚠ 数式を実行時に動的に書き換える処理が現行にある場合は、その業務要件（何を切り替えたいのか）に立ち返って条件分岐・パラメータテーブルで再設計する。
セルの書式を操作する機能	フォント・色・罫線・表示形式をプログラムから設定する	帳票の自動整形、強調表示の設定	書式テンプレートの再利用	標準機能難易度：低実現手段：静的な書式はページ設計時に設定、動的な強調は条件付き書式＋「セルプロパティの設定」コマンドで標準対応。実装：VBAで書式設定コードだった部分の大半は「設計時の設定」に置き換わり、コード自体が不要になる。 ⚠ 特になし。テーマ・スタイルの統一管理はむしろVBAより容易になる。
行・列を挿入・削除する機能	データ件数に応じて行・列を動的に増減する	明細行の自動挿入、不要列の削除	数式・書式の引き継ぎ制御	設計転換難易度：低考え方の転換：明細行の増減はリストビュー（行の追加・削除は標準機能、書式・数式は自動で行に追従）が担う。「列を動的に増やす」要件はデータを縦持ちに正規化して解決する。実装：行追加時の初期値・入力規則はリストビューのテンプレート行設定で制御。 ⚠ 「月が増えるたびに列を足す」型の現行シートは移行の要注意ポイント。縦持ち化＋ピボット表示（カテゴリー05）への変換設計を個別に行う。
名前付き範囲を操作する機能	名前付きセル範囲を利用して処理の汎用性を高める	テンプレートの差し込み先管理	名前定義のメンテナンス	標準機能難易度：低実現手段：セルの名前定義（標準）＋数式・コマンドからの名前参照で対応。帳票の差し込み先管理はレポートのデータバインドがその役割を担う。実装：コマンドから参照するセルは必ず名前を付ける規約にすると、レイアウト変更でコマンドが壊れない。 ⚠ 特になし。命名規約（用途がわかる名前）だけ最初に決めておく。
別ブックのデータを参照する機能	外部ブックのデータをプログラムで参照・取得する	マスタブックや共有ファイルの参照	外部リンクの更新制御、ファイルパス管理	設計転換難易度：中考え方の転換：「共有フォルダのマスタブック」運用自体を廃止し、マスタをForguncyテーブル（またはSQL Server）へ移行してリレーション参照するのが本筋。実装：他部署管理でブック廃止できないものは、過渡期対応としてスケジュールタスク＋カスタムWeb APIで定期取込（ブック→テーブル複製）し、アプリからはテーブルだけを見る。 ⚠ ブック直接参照を残すと「開かれていて読めない」「行がズレた」等のVBA時代の障害を持ち越す。移行対象ブックの所管部署との調整を計画初期に開始する。
ブックを保護・ロックする機能	シート・ブックへの保護設定で誤操作を防ぐ	帳票の誤変更防止、配布ファイルの保護	保護パスワードの管理、保護対象範囲の定義	標準機能難易度：低実現手段：ブック保護の目的（誤変更防止・閲覧制限）は、ロール別のページ表示権限・セルの読取専用設定・テーブル権限で実現（標準）。実装：「シート保護パスワード」という共有秘密の運用が、ユーザー個人単位の権限管理に置き換わる。統制レベルはVBA時代より確実に向上する。 ⚠ 配布したExcelファイル自体の保護が必要な場合のみカスタム対応（カテゴリー13参照）。そもそも「配布せず画面で見せる」への転換を優先検討。
ブックを自動保存する機能	一定間隔や処理節目にブックを自動保存する	処理中断時のデータ保全	保存タイミング、ファイル名の連番管理	標準機能難易度：低考え方の転換：データはコマンド実行（登録・更新ボタン）の時点で即座にDBへ保存されるため、「ブック保存」という概念自体が消滅する（標準動作）。実装：長文入力・大量明細入力の画面では、ブラウザクラッシュ対策として「下書き保存」ボタン＋ドラフトテーブルを用意すると親切。 ⚠ 逆に「保存せずに閉じれば元に戻る」というExcelの取り消し文化は使えなくなる。確定前データはドラフト状態で持つ設計（ステータス管理）でカバーする。
マクロの実行を制御する機能	マクロの自動実行トリガー（Open/Close等）を設定・管理する	ファイルオープン時の自動処理実行	イベントの連鎖防止、無限ループ対策	標準機能難易度：低実現手段：Workbook_Open→「ページロード時」イベント、Worksheet_Change→「セル値変更時」イベント、Auto実行→スケジュールタスク（時刻起動）にそれぞれ対応（標準）。実装：イベント→コマンドセットの対応表を移行設計書のフォーマットにすると、VBAイベントプロシージャの棚卸しがそのまま移行仕様になる。 ⚠ 値変更イベントから別セルを更新して再びイベントが発火する連鎖はForguncyでも起こり得る。イベント設計のレビュー観点として引き継ぐ。

11 業務処理・ワークフロー機能 10機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
申請書を作成する機能	業務申請書のデータ入力・作成を行う	稟議書・各種届出書の作成	入力フォームとの連動、申請番号の自動採番	標準機能難易度：低実現手段：入力ページ＋「テーブルデータの追加」コマンドで申請データを登録（標準）。連番は自動インクリメントフィールド、業務書式の申請番号（例：A2026-0001）はコマンドで生成。実装：申請テーブルは「申請ヘッダ＋明細」の親子構造を基本形にし、添付書類は添付ファイル型フィールドで一緒に保存する。 ⚠ 下書き保存（ドラフトステータス）を最初から設計に含める。申請途中で消えるのは現場の最大の不満要因になる。
申請を回付する機能	申請データや書類を次のステップ担当者へ送付・通知する	承認フローでの回覧・差し戻し	担当者リスト管理、回付状態の管理	標準機能難易度：中実現手段：標準のワークフロー機能で状態遷移・各ステップの担当（ユーザー／ロール／組織）・遷移時のメール通知を定義。実装：担当者は個人でなくロール・組織に割り当て、人事異動はユーザー管理側の変更だけで済むようにする。「自分の未処理一覧」ページをトップに置くのが定番構成。 ⚠ 金額による承認経路の分岐・代理承認・並列承認（合議）など複雑なフロー要件は、v10ワークフローの表現力をPoCで必ず検証。表現できない部分はステータス列＋コマンドでの自前制御になり工数が変わる。
承認・否認を記録する機能	承認者の承認・否認の結果・日時・コメントを記録する	多段階承認の履歴管理	承認者権限の確認、電子署名との連動	標準機能難易度：低実現手段：ワークフロー機能がステップごとの実行者・日時・アクション・コメントを自動記録（標準）。実装：承認履歴の照会ページ（申請詳細に履歴一覧を併設）を用意し、監査時に画面で追えるようにする。承認時コメントの必須／任意はステップ別に設計。 ⚠ 「承認済みデータの事後変更」を許すかが統制上の論点。承認後は読取専用とし、変更は取消申請→再申請のフローに乗せるのが原則。
処理状態を管理する機能	業務処理の進行状態（未処理・処理中・完了等）を追跡する	大量処理の進捗管理、差戻案件の再処理	状態遷移ルールの定義、状態変更のログ記録	標準機能難易度：低実現手段：承認系はワークフローの状態管理をそのまま利用。承認を伴わない処理状態（取込済／集計済等）はステータスフィールド＋更新コマンドで管理（標準の組み合わせ）。実装：ステータス別タブ（未処理／処理中／完了）のリストビュー構成が定番。状態遷移図を設計書として残し、遷移はコマンド経由に限定（直接編集で状態を書き換えさせない）。 ⚠ 状態変更のログ（誰がいつどの状態へ）は自動では残らない部分があるため、状態更新コマンドに履歴書込をセットで組み込む規約にする。
期限・催促を管理する機能	処理期限の管理と期限超過の通知・催促を行う	承認期限管理、提出期限の督促	期限計算（営業日）、通知方法の設定	カスタム開発難易度：低実現手段：スケジュールタスク（日次）で期限超過・期限間近の案件を抽出し、「メールを送信する」コマンドで担当者へ催促通知。実装：期限は営業日計算の共通処理（カテゴリー04）で算出。督促の段階制（期限前リマインド→超過通知→上長エスカレーション）を閾値テーブルで設定可能にする。 ⚠ 通知の重複送信防止（同一案件への通知履歴管理）を忘れずに。毎日同じ督促が届く仕組みは即座に無視されるようになる。
業務カレンダーを参照する機能	営業日・休業日を管理するカレンダーを参照する	締め日計算、バッチスケジュール管理	祝日・特別休業日の登録・更新	カスタム開発難易度：低実現手段：休日マスタテーブル（日付・種別・名称）＋管理画面を整備し、営業日判定・翌営業日算出を共通処理（数式またはカスタムWeb API）として全業務から参照。実装：年次の祝日登録は内閣府CSV等からの取込ジョブで半自動化し、行独自休業日は手入力で追加する運用に。 ⚠ 「翌年分のカレンダー未登録」が年末年始バッチ障害の定番原因。未来N ヶ月分の登録有無を監視するチェックジョブを仕込んでおく。
採番する機能	申請番号・管理番号等のシーケンス番号を採番する	書類番号・トランザクションIDの生成	採番方式、重複防止、ルール定義	カスタム開発難易度：中実現手段：内部IDは自動インクリメントフィールドで標準対応。年度別・部署別リセットなど業務採番は採番管理テーブル＋サーバーサイドコマンドで実装。実装：「内部ID（自動連番・欠番許容）」と「表示用番号（業務書式）」を分離するのが定石。表示用番号は登録確定時に採番し、下書きには振らない。 ⚠ 同時申請時の採番重複はPoCで負荷確認。確実性が必要ならカスタムWeb APIでDBの行ロック（UPDLOCK等）を使った採番にする。「欠番を許容するか」は監査要件として先に確認。
業務ルールをチェックする機能	業務固有のビジネスルールに基づく整合性チェックを行う	限度額チェック、期間整合チェック	ルール定義の外部化・メンテナンス性	カスタム開発難易度：中実現手段：単純ルールはコマンドの条件分岐＋ルールマスタ（限度額等のパラメータテーブル）参照で対応。複合ルール（複数テーブル横断の整合性）はカスタムWeb APIに検証ロジックを集約。実装：チェック結果は「エラー（登録不可）」と「警告（理由入力で続行可）」の2レベル設計にすると現場運用に耐える。 ⚠ 限度額などの閾値をロジックに埋め込まない（必ずパラメータテーブル化）。閾値改定のたびにリリースが必要な作りはVBA時代の負債の再生産になる。
差戻・再申請を処理する機能	否認・差戻された申請の修正・再申請を処理する	承認差戻し後の修正再申請フロー	修正履歴の保持、差戻し理由の記録	標準機能難易度：低実現手段：ワークフローの差戻し遷移で標準対応。差戻し理由はコメント必須設定で記録。実装：差戻し後の修正内容を追跡したい場合は、再申請時に変更前値を履歴テーブルへ保存（カテゴリー14の変更履歴と共通化）。差戻し案件は申請者の未処理一覧に目立つ形で表示する。 ⚠ 「差戻し」と「否認（終了）」の使い分け、差戻し時に承認済みステップを維持するか最初からやり直すかは、業務部門と規約を先に決める。
完了処理と後続処理を実行する機能	承認完了後にDB更新やファイル生成などの後続処理を自動実行する	承認完了をトリガーとしたシステム更新	後続処理の冪等性確保、部分失敗時の対処	標準機能難易度：中実現手段：ワークフローの最終承認遷移時にサーバーサイドコマンドを実行し、本テーブル反映・帳票生成・通知を自動化（標準の組み合わせ）。実装：後続処理の実行結果を処理結果テーブルに記録し、失敗時は承認は維持したまま後続のみ再実行できる管理機能（管理者用リトライボタン）を用意する。 ⚠ 再実行時の二重反映防止（処理済みフラグの事前チェック＝冪等性）を必ず実装。「承認は済んだが反映が失敗」した案件を検知する日次監視ジョブもセットで。

12 認証・認可・権限管理機能 9機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
ログイン認証する機能	ユーザーIDとパスワードで本人認証を行う	アプリ起動時の本人確認	パスワードポリシー、ロックアウト制御	標準機能難易度：低実現手段：フォーム認証（標準）。ユーザー管理・パスワードポリシー・ロックアウトはサーバー管理ポータルのセキュリティ設定で構成。実装：VBAアプリでありがちな「Excelシートにユーザー表」「共通パスワード」運用を、個人アカウント＋認証基盤へ全面置換する。この置換自体が移行の統制上の最大成果になる。 ⚠ 行内のパスワード基準（複雑性・履歴世代・変更周期）を設定項目でどこまで満たせるか先に確認。満たせない場合はAD認証（次項）へ寄せて行内ポリシーに従属させるのが早い。
Active Directoryと連携する機能	Windows AD認証を利用してシングルサインオンを実現する	行内SSOによるパスワード管理集約	AD接続設定、グループポリシーとの整合	標準機能難易度：中実現手段：Windows認証（ADドメイン連携）で行内SSOを実現、ADユーザー・グループのインポート・同期に対応（標準）。実装：ADグループ→Forguncyロールの対応表を設計し、人事異動・入退行をAD側の運用に一本化する。アプリ側で個別にユーザー管理しない。 ⚠ 内部向けアプリなら Windows認証が第一候補。SAML／OpenID Connect等のSSO方式が必要な場合は対応可否・エディション条件を要確認。認証方式は全アプリ共通の基盤決定なので最初に確定させる。
ロールベースのアクセス制御をする機能	ユーザーのロール（役割）に応じてアクセス可能な機能を制限する	一般行員・管理者・審査担当など役割別の機能制限	ロール定義・付与の管理画面	標準機能難易度：低実現手段：ロール管理（標準）。ページ・テーブル・フィールド単位でロール別権限を設定。実装：ロールは「職務」単位（申請者・承認者・照会者・マスタ管理者・システム管理者）で設計し、部署はユーザー属性で表現する（ロール×部署のマトリクス爆発を防ぐ）。 ⚠ ロール設計は最初のアプリで全社共通の雛形を作る。アプリごとにバラバラなロール体系にすると、後の棚卸し（アクセス権レビュー）が破綻する。
機能・画面単位でのアクセス制御をする機能	特定の画面・ボタン・機能の利用可否をユーザー単位で制御する	特定帳票の閲覧・出力権限管理	権限マスタのメンテナンス	標準機能難易度：低実現手段：ページのロール別表示権限（標準）＋ボタン等のセル別表示・活性制御（ロール条件のコマンド／数式）。実装：ナビゲーションメニューもロール別に出し分け、「見えないページには入れない」を基本にする。 ⚠ UI非表示だけではURL直接アクセスを防げない。ページ権限（サーバー側）と表示制御（UI側）は必ず両方設定する。これを移行時のセキュリティチェックリスト項目にする。
データアクセス範囲を制限する機能	ユーザーが参照・操作できるデータ範囲（部署・勘定等）を制限する	部署データの他部署からの参照不可制御	データ行レベルのアクセス制御	標準機能難易度：中実現手段：テーブルの行レベルアクセス制御（レコード単位の権限条件。CURRENTUSER等のログインユーザー情報・ユーザー属性を条件式に使用）で対応。実装：ユーザーに部店コード属性を持たせ、「データの部店＝自分の部店」を条件式にするのが基本形。兼務・本部横断閲覧は例外ロールで設計。 ⚠ ユーザー属性（カスタムプロパティ）の持ち方と条件式の表現力（上位部署を含む階層判定等）はPoCで要検証。画面フィルタでの絞り込みは統制にならない点に注意（カテゴリー04参照）。
権限分離を実現する機能	入力者・承認者・閲覧者の役割を分離し、兼任を防ぐ	内部統制要件に基づく職務分離	権限の競合チェック、兼任防止ロジック	カスタム開発難易度：中実現手段：静的な分離はロール設計（申請ロールと承認ロールを分ける）で標準対応。動的な分離（自分の申請は自分で承認不可）はワークフロー承認時の条件チェック（申請者＝承認者ならエラー）で実装。実装：ロールの兼任状況を定期出力する「権限マトリクスレポート」を作り、アクセス権レビューの証跡にする。 ⚠ 少人数部署での「やむを得ない兼任」の代替統制（事後レビュー等）は内部統制部門と協議し、システム外の統制も含めて設計する。
セッションを管理する機能	ログイン状態の維持・タイムアウトによる自動ログアウトを管理する	長時間放置による不正利用防止	タイムアウト時間設定、再認証要求	標準機能難易度：低実現手段：サーバー管理ポータルのタイムアウト（自動ログアウト）設定で標準対応。実装：タイムアウト値は行内のセキュリティ基準に合わせて設定し、長時間の入力作業が想定される画面には下書き保存（カテゴリー11）を併設して入力消失を防ぐ。 ⚠ タイムアウト時の未保存データの扱いを利用者に周知する。共有端末運用がある場合はブラウザのパスワード保存禁止等の端末側ポリシーも併せて整備。
パスワードを管理する機能	パスワードの変更・有効期限管理・強度チェックを行う	定期パスワード変更の強制	パスワード履歴管理、変更通知	標準機能難易度：低実現手段：ユーザー自身のパスワード変更・管理者リセット・強度ポリシーはユーザー管理機能で対応（標準）。実装：AD認証（Windows認証）を採用すればパスワード管理は行内AD基盤側に完全移譲でき、アプリ側の管理は不要になる。これが推奨構成。 ⚠ フォーム認証を使う場合、有効期限・履歴世代等の細かなポリシー設定の対応範囲を要確認。要件を満たせなければAD認証への一本化で解決する。
管理者権限を管理する機能	システム管理者権限を持つユーザーの登録・変更・削除を管理する	権限管理の集中管理、内部統制対応	管理者権限付与の承認フロー	標準機能難易度：低実現手段：サーバー管理ポータルで管理者アカウントを管理（標準）。実装：管理者権限の付与・剥奪は申請ワークフロー（このアプリ自身で構築）を経由する運用にし、付与操作の記録と定期的な棚卸し（管理者一覧の年次レビュー）を制度化する。 ⚠ 管理者アカウントの共用は禁止（個人アカウント＋管理者ロール付与で運用）。Builder（開発環境）を触れる開発者権限の管理も本番管理者と分離して設計する。

13 セキュリティ・情報保護機能 10機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
個人情報・機密データをマスクする機能	表示・出力時に個人情報等の機密データを自動マスクする	テスト環境への提供データのマスク、画面表示の制限	マスク対象フィールドの定義・管理、マスク方式	カスタム開発難易度：低実現手段：列単位の秘匿はフィールドアクセス権限（標準）、部分マスクは表示用フィールド生成（カテゴリー04参照）。テスト環境提供用は本番データ復元後にマスク一括実行のカスタムWeb APIを用意。実装：データ分類台帳（項目×機密区分×マスク方式）を作成し、マスクジョブはその台帳定義を読んで動く汎用実装にする。 ⚠ マスク後も突合テストができるよう、同一値→同一マスク値の一貫性（決定的マスキング）が必要か要件確認する。
データを暗号化する機能	保存・転送するデータを暗号化して情報漏えいを防ぐ	ファイル保存時の暗号化、転送データの保護	暗号化アルゴリズム、鍵管理方式	設計転換難易度：中実現手段：転送はHTTPS（標準設定）で担保。保存の暗号化はレイヤーで分担する：DBレベル＝TDE対応の外部DB（SQL Server等）、ディスクレベル＝BitLocker、項目レベル＝カスタムWeb APIでAES暗号化。実装：項目レベル暗号化は検索・集計不能になる副作用があるため、対象は真に必要な項目（マイナンバー等）に限定する。 ⚠ 内蔵DBに透過的暗号化は期待しない前提で計画（要確認）。機密度の高いデータを扱うアプリは外部DB構成を最初から選ぶ。鍵管理（保管場所・ローテーション・担当）は行内基準に従い文書化必須。
Excelファイルをパスワード保護する機能	配布・保存するExcelファイルにパスワードを設定する	帳票配布時の情報漏えい対策	パスワード管理方法、受取人への安全な通知	カスタム開発難易度：低実現手段：標準エクスポートにパスワード設定はないため、カスタムWeb APIでExcel生成時に暗号化保存（対応ライブラリを利用）する。実装：パスワードは受渡し規約（別経路通知）とセットで運用設計する。 ⚠ そもそも「パスワード付きファイルをメール送付」（PPAP）は廃止方向。ファイル配布をやめ、権限管理された照会ページ＋アクセスログで代替するのがWebアプリ化の本来の効果であり、まずそちらを提案すべき。
画面のコピー・印刷を制限する機能	機密情報画面のスクリーンショット・印刷を制限する	表示データの外部持ち出し防止	制限の技術的実現方式、運用での補完	設計転換難易度：高実現手段：Web技術では完全な制限は不可能（スクリーンショットはOS機能）。抑止策として：印刷用CSSでの印刷抑止、画面へのユーザーID・日時の透かし表示（JavaScript）、エクスポート権限の制限＋出力ログ。実装：根本対策は端末側（VDI・DLP製品・スクリーンショット禁止ポリシー）との組み合わせで、システムと運用の役割分担を明確にする。 ⚠ 「技術で完全に防げる」と誤解されたまま要件化されるのが最も危険。できること・できないことをリスク管理部門と合意し、残余リスクを文書化する。
ファイルへのアクセス権を制御する機能	ファイルの読み書き権限をOS・共有フォルダレベルで制御する	連携ファイルの不正読み取り・改ざん防止	アクセス権設計、権限変更の申請フロー	設計転換難易度：低実現手段：サーバー上の連携フォルダはOS・ファイルサーバーのACLで制御し、Forguncyのサービスアカウントに最小権限のみ付与。アプリ内の添付ファイルはテーブル権限（ロール・行レベル）に従う。実装：ファイルの置き場を「アプリ内（添付ファイル型）」に寄せるほど、権限管理はForguncyの統制範囲に一元化できる。 ⚠ VBA時代の「共有フォルダに帳票を置いて全員が見る」運用を持ち込むと権限管理が二重化する。ファイル置き場の棚卸しと集約方針を移行計画に含める。
接続元を制限する機能	特定のPCやIPアドレスからのみ接続を許可する	外部からの不正アクセス防止	接続元リストの管理・更新	設計転換難易度：低実現手段：ネットワークレイヤーで制御する：IIS（またはリバースプロキシ）のIP制限、FWのセグメント制御。行内LANからのみ到達可能な配置にするのが基本。実装：サーバー管理ポータル・Builder接続（開発者用ポート）は業務利用者以上に厳格に制限する。 ⚠ Forguncyアプリ本体だけでなく、管理ポータルへの接続制限を忘れないこと。ここが甘いと権限管理全体が無意味になる。
不正アクセスを検出する機能	通常と異なる操作パターンや不正なアクセスを検出・通知する	セキュリティ異常の早期発見	検出ルールの定義、アラート通知方法	設計転換難易度：中実現手段：本格的な検知は行内SIEM・セキュリティ監視基盤への連携（サーバーログ・アクセスログの転送）が本筋。アプリ内の簡易検知として、操作ログを日次スケジュールタスクで分析（深夜アクセス・大量エクスポート・連続ログイン失敗）→管理者へメール通知。実装：検知ルールと閾値はパラメータテーブル化し、誤検知のチューニングを運用で回せるようにする。 ⚠ 検知の前提は「ログが取れていること」。カテゴリー14のログ設計を先に固めないと、この機能は成立しない。
データを安全に削除する機能	不要になったデータやファイルを復元不可な形で削除する	保存期限切れファイルの廃棄、テストデータの削除	削除証跡の記録、削除方式の定義	カスタム開発難易度：低実現手段：業務データは「論理削除→保持期限経過後にスケジュールタスクで物理削除」の2段階とし、削除証跡（何を・いつ・どのポリシーで）を削除ログテーブルに記録。実装：物理削除ジョブは削除前に対象をアーカイブエクスポートしてから実行する安全設計に。 ⚠ ディスク上の完全消去（復元不可能化）はアプリ層では保証できない。媒体廃棄・ストレージ暗号化などインフラ運用と役割分担する。バックアップ内に残る旧データの扱いも保存年限設計に含める。
通信を暗号化する機能	外部通信にTLS/SSLを適用してデータの盗聴を防ぐ	外部APIへの送受信データの保護	証明書管理、プロトコルバージョン管理	標準機能難易度：低実現手段：ForguncyサーバーへのSSL証明書適用（HTTPS化）はサーバー設定で標準対応。外部API呼び出しもHTTPS接続で実施。実装：行内CA発行の証明書運用に載せ、証明書更新の年次スケジュールを運用カレンダーに登録（期限切れは全ユーザー影響の障害になる）。 ⚠ HTTP接続の禁止（HTTPSリダイレクト強制）とTLSバージョン・暗号スイートのOSレベル設定（TLS1.2以上）をサーバー構築手順書に明記する。
脆弱性リスクを低減する機能	SQLインジェクション等の攻撃リスクを低減する実装をする	ユーザー入力値のサニタイズ、パラメータバインド	脆弱性診断結果への対応	標準機能難易度：中実現手段：標準機能のデータアクセスはプラットフォーム側でパラメータ化されており、アプリ開発者が個別対策する必要はない。リスクが残るのはカスタムWeb API・カスタムJavaScriptの自作部分。実装：カスタムコードのコーディング規約（SQL必ずバインド・入力検証・出力エスケープ・例外情報の非表示）とコードレビューを義務化。リリース前に行内標準の脆弱性診断を通す。 ⚠ Forguncy本体の脆弱性対応（セキュリティパッチ）はベンダー通知の購読と適用手順の整備で対応。バージョンアップ計画（カテゴリー20）とセットで運用設計する。

14 監査・証跡・ログ管理機能 9機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
操作ログを記録する機能	誰がいつどの操作をしたかを自動記録する	不正操作の追跡、操作履歴の監査	記録項目の定義（ユーザー・日時・操作種別・対象）	カスタム開発難易度：中実現手段：共通の「操作ログ書込」コマンド部品（ユーザー＝CURRENTUSER・日時・画面名・操作種別・対象キー）を作り、すべての更新系ボタンのコマンド列に組み込む開発規約で担保する。実装：ログ項目定義（5W1H）を監査部門と合意してから共通部品を設計。サーバーのアクセスログ（HTTPレベル）は補完材料として併用。 ⚠ 「全画面操作の自動記録」機能は期待せず、規約×共通部品×実装レビューで網羅する方式が現実的（標準の監査ログ機能の粒度はv10で要確認）。規約漏れを防ぐため、リリース前チェックリストに「更新コマンドにログ書込あり」を入れる。
データ変更履歴を記録する機能	データの更新前後の値を履歴として保存する	マスタ変更履歴の追跡、データ改ざんの検証	変更前後値の保存、変更者・日時の記録	カスタム開発難易度：中実現手段：更新コマンドの直前に現行値を取得して履歴テーブルへ保存（全列コピー、または変更列のみのJSON形式）。テーブル標準の作成者・更新者・更新日時フィールドも併用。実装：外部DB（SQL Server）ならDB側トリガー／CDC（変更データキャプチャ）で取る方式が、アプリ実装漏れの影響を受けず監査上は最も堅い。重要マスタはこちらを推奨。 ⚠ アプリ実装方式は「履歴書込を忘れた更新経路」が弱点。重要テーブルへの更新経路を設計書で一覧化し、経路数を絞る（更新は専用コマンド経由のみ）ことが品質の前提になる。
ログイン・ログアウト履歴を記録する機能	ユーザーのログイン・ログアウトの日時・端末を記録する	不正ログインの調査、利用状況の把握	ログ保存場所、保存期間	標準機能難易度：低実現手段：サーバーのアクセスログ・ユーザーアクセス情報（管理ポータルで確認）を一次ソースとし、アプリ側でもトップページの「ページロード時」イベントで利用記録テーブルに記録して補完。実装：ログイン失敗（ロックアウト）の記録・通知要件がある場合はサーバーログの出力内容を確認して監視設計に含める。 ⚠ 標準ログの出力粒度・保存期間・エクスポート可否はv10で要確認。監査要件（保存年限）を満たさない場合は定期エクスポート→アーカイブのジョブを組む。
帳票出力履歴を記録する機能	誰がいつどの帳票を出力したかを記録する	機密帳票の持ち出し追跡、監査対応	出力条件・ファイル名・宛先の記録	カスタム開発難易度：低実現手段：出力ボタンのコマンド列の先頭に出力ログ書込（帳票ID・出力条件・件数・ユーザー・日時）を必ず挿入する共通パターンで実装。実装：エクスポート系（Excel・PDF・CSV）すべてに適用し、機密区分の高い帳票は出力理由の入力を必須にする。 ⚠ 「出力ログのない出力ボタン」を作れないよう、出力機能は共通のテンプレートコマンドから複製する開発ルールにする。リリース前チェックリストにも項目化。
エラーログを記録する機能	システムエラー・処理例外の詳細を自動記録する	障害発生時の原因調査、再発防止対応	ログレベル定義、スタックトレースの記録	カスタム開発難易度：低実現手段：コマンドのエラー処理分岐からエラーログテーブルへ記録。カスタムWeb APIの例外はcatch節で同じテーブル＋サーバーログへ二重記録（スタックトレース含む）。実装：エラーIDを採番して画面メッセージに表示し、問い合わせ時にエラーIDでログを即引きできる運用にする。 ⚠ エラーログに個人情報・機密データ（入力値そのもの）を安易に書かない。記録する入力値はマスク方針をログ設計に含める。
処理実行ログを記録する機能	バッチ処理等の開始・終了・処理件数を記録する	夜間バッチの実行確認、処理結果の検証	ログ出力先の管理、処理識別子	カスタム開発難易度：低実現手段：ジョブ履歴テーブル（ジョブID・開始・終了・処理件数・結果・エラー内容）への記録を、全スケジュールタスクの冒頭・末尾に置く「標準ジョブフレーム」として部品化。実装：ジョブ履歴は運用ダッシュボード（カテゴリー18）と朝の運用確認メールの共通データソースになる。最初に作る共通基盤として最優先で整備。 ⚠ 「開始レコードだけあって終了がない」状態＝異常終了の検知に使えるよう、タイムアウト判定付きの監視ジョブとセットで設計する。
ログを安全に保管する機能	記録したログを改ざん・削除不能な状態で保管する	内部統制・監査要件への対応	ログ保管場所、アクセス権の制限	設計転換難易度：中実現手段：アプリ内対策：ログテーブルの権限を「全ロール追加のみ可・参照は監査ロール限定・更新/削除は誰も不可」に設定。改ざん耐性の要件が高い場合は、日次でログを外部保管（別サーバー・WORM相当ストレージ・ログ基盤）へ転送。実装：転送済みログとの件数照合（欠落検知）も転送ジョブに含める。 ⚠ システム管理者・DB管理者による改変可能性は、アプリ内権限だけでは排除できない。外部転送＋職務分離（ログ管理者を別置）で対応するのが監査対応の定石。
ログを検索・照会する機能	蓄積したログを条件指定で検索・抽出する	監査時のログ調査、インシデント対応	検索項目・期間指定、大量ログへの対応	標準機能難易度：低実現手段：ログ照会ページ（期間・ユーザー・画面・操作種別のフィルタ付きリストビュー）＋Excelエクスポートで標準構成（監査ロール限定公開）。実装：ログテーブルの日時・ユーザー列にインデックスを設計し、大量化しても照会に耐える構造にする。 ⚠ ログ照会・エクスポート自体もログ対象（誰がログを見たか）。監査対応の実務では必ず求められる。
ログの保存期間を管理する機能	ログの保存期限を設定し、期限超過ログを自動削除・アーカイブする	ストレージ管理、コンプライアンス対応	法的保存要件との整合、アーカイブ方法	カスタム開発難易度：低実現手段：ログ種別ごとの保持年限をポリシーテーブルで管理し、月次スケジュールタスクで「アーカイブエクスポート→物理削除」を自動実行。実装：アーカイブ先・形式（CSV＋圧縮等）・リストア手順まで含めて運用手順書化。削除実行は削除ログ（メタ記録）を残す。 ⚠ 保存年限は監査・コンプライアンス部門と合意した年数を正とする（推測で設定しない）。ログ種別ごとに年限が異なるのが普通なので、ポリシーテーブル方式が効く。

15 エラー処理・例外処理機能 7機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
実行時エラーをハンドリングする機能	VBA実行中のランタイムエラーを捕捉し、処理を中断せず適切に対処する	ファイル読み込みエラー、DB接続エラーの回収	エラーコード別の処理分岐、ユーザーへの通知方法	カスタム開発難易度：中実現手段：On Error方式の移植ではなく、（1）エラーになり得る条件を事前チェック（条件分岐）で潰す、（2）複雑なエラー制御が必要な処理はカスタムWeb API（try-catch）へ寄せて結果コードを返す、の2本立てで設計。実装：APIの戻り値（成功／エラー種別／メッセージ）の標準形式を決め、呼び出し側コマンドの後処理を共通パターン化する。 ⚠ 標準コマンドが実行時エラーになった場合の挙動（中断範囲・後続コマンドの扱い）は必ずPoCで確認し、その前提で設計する。VBAのResume Next的な「エラーを握り潰して続行」は移植しない（それ自体が現行の潜在バグ）。
エラー内容をユーザーに通知する機能	エラー発生時にユーザーへわかりやすいメッセージを表示する	処理失敗時の原因説明と対処方法の案内	メッセージの多言語対応、技術情報の隠蔽	標準機能難易度：低実現手段：「メッセージを表示する」コマンドで標準対応。実装：メッセージは「何が起きたか＋利用者が次にすべきこと」をセットで表示し、技術詳細（スタックトレース等）は画面に出さずエラーID経由でログ参照（カテゴリー14）。メッセージ文言はテーブル管理にすると文言統一・修正が容易。 ⚠ カスタムWeb APIの例外メッセージをそのまま画面に出さない（内部情報漏えい＋利用者に無意味）。APIの標準戻り形式で業務メッセージに変換する。
エラーをログに記録する機能	エラー発生時の詳細情報をログファイルやDBに記録する	障害調査、再現手順の特定	ログ記録自体が失敗した場合の対処	カスタム開発難易度：低実現手段：カテゴリー14のエラーログ基盤を利用（エラー処理分岐→ログテーブル書込）。実装：ログテーブル書込自体が失敗するケース（DB障害）に備え、カスタムWeb API側ではサーバーのファイルログにもフォールバック記録する二重化を実装。 ⚠ DB障害時はアプリ内ログは機能しない前提で、サーバーレベルのログ・監視（イベントログ、死活監視）と役割分担しておく。
処理を安全にロールバックする機能	エラー発生時に中途半端な状態を残さず処理をロールバックする	DB更新処理のエラー時にデータ整合性を保つ	トランザクション管理との連動	カスタム開発難易度：中実現手段：整合性が必要な複数更新はカスタムWeb APIに集約し、SqlTransaction／TransactionScopeで全体を原子化（カテゴリー03参照）。実装：Forguncy側からは「1ボタン＝1 API呼出＝1トランザクション」の対応にすると、途中失敗の心配自体がなくなる。 ⚠ 標準コマンド列の途中失敗時の巻き戻しは保証されない前提で設計する（PoCで挙動確認）。ファイル出力＋DB更新のような「DBトランザクション外の処理」を含む場合は、実行順序（DB確定→ファイル出力）と失敗時の補償処理を設計する。
エラー後に処理を継続する機能	一部レコードのエラーで全体を停止させず、エラー行をスキップして継続する	大量ファイル取込でのエラーレコードのスキップ処理	スキップ件数の記録、後続対処の案内	カスタム開発難易度：低実現手段：大量件数の行単位スキップはカスタムWeb API内のループ（try-catch per 行）で実装し、エラー行を理由付きでエラー明細テーブルへ退避。少量ならサーバーサイドコマンドの繰り返し＋条件分岐でも可。実装：処理結果は「正常N件・スキップM件」をジョブ履歴に記録し、スキップ一覧の修正→再取込の画面フローまで用意して業務を完結させる。 ⚠ スキップを許す業務か、1件でもNGなら全体停止（CTチェック型）かは業務ごとに要件が異なる。取込基盤のパラメータとして両対応にしておく。
エラーを分類・集約する機能	複数のエラーを種別・件数で集約し、まとめて報告する	一括処理後のエラーサマリーレポート作成	エラー分類基準、集約レポートの形式	標準機能難易度：低実現手段：エラー明細テーブルにエラーコード体系（分類マスタ）を持たせ、リストビュー・ピボット・グラフで集計表示（標準の組み合わせ）。完了通知メールに種別別件数のサマリーを差し込む。実装：エラーコード体系（入力起因／マスタ起因／システム起因）を最初に設計する。対処担当の振り分けに直結する。 ⚠ 特になし。カテゴリー14のログ基盤が整っていれば標準機能の範囲で構成できる。
タイムアウトを検知する機能	長時間処理やDB接続のタイムアウトを検知して適切に処理する	DB接続タイムアウト、ファイル処理の長時間化検知	タイムアウト時間の設定、再試行との連動	カスタム開発難易度：中実現手段：カスタムWeb API側で CommandTimeout（DB）・HttpClient.Timeout（外部API）を業務要件に合わせ明示設定し、タイムアウトを例外として捕捉→ログ・通知。長時間化の検知はジョブ履歴の実行時間を監視ジョブで判定。実装：再試行（リトライ回数・間隔）は冪等性が確保された処理にのみ適用する。 ⚠ ブラウザ→IIS→Forguncy→DBと多段のタイムアウト値が存在するため、整合を取らないと「画面はエラー、裏では処理継続」という事故になる。長時間処理はジョブ化（非同期）が根本対策。

16 リカバリ・再実行・データ保全機能 8機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
処理の途中状態を保存する機能	長時間処理でチェックポイントを設けて中断時の再開を可能にする	夜間バッチの中断・再開対応	チェックポイントの保存方式、再開時の整合性確認	カスタム開発難易度：中実現手段：処理をチャンク（例：支店単位・1万件単位）に分割し、チャンクごとの完了をジョブ管理テーブルに記録。再開時は未完了チャンクのみ処理する設計をカスタムWeb API／ジョブフレームに組み込む。実装：チャンク単位でトランザクションを完結させ、「チャンク完了記録とデータ更新」を同一トランザクションにすることで再開時の整合性を保証する。 ⚠ チェックポイント方式は冪等性（同一チャンクの再実行で二重反映しない）とセットで初めて成立する。ジョブ設計の標準フレームとして最初に確立し、全バッチで使い回す。
処理を再実行する機能	失敗した処理を同一条件で再実行できるようにする	エラー後の再バッチ実行、差し戻し後の再処理	冪等性（二重実行の防止）の確保	標準機能難易度：低実現手段：スケジュールタスクの手動実行（管理ポータルから起動）で再実行自体は標準対応。処理パラメータ（対象日付等）を実行時の現在日付から計算せず、パラメータテーブルから読む設計にして「同一条件での再実行」を保証する。実装：再実行前に前回結果（処理済みデータ）をクリアするか、処理済み判定でスキップするかをジョブごとに設計書へ明記。 ⚠ 「翌日に前日分を再実行したら対象日がずれた」はバッチ移行の定番事故。基準日はジョブ起動時に自動確定させず、運用者が確認できるパラメータとして持つ。
データをバックアップする機能	処理前のデータをバックアップし、復元可能な状態にする	大量更新前のデータ保全、誤更新への備え	バックアップ先・タイミング・保存期間の定義	標準機能難易度：低実現手段：サーバー管理ポータルのバックアップ機能（アプリ＋内蔵DB）を定期取得（標準）。外部DBはDB側の運用（フルバックアップ＋トランザクションログ）に載せる。実装：大量更新バッチの直前スナップショット（対象テーブルのコピー保存）はジョブ内の前処理として実装し、バックアップ先はサーバー本体と別のストレージにする。 ⚠ 「バックアップの取得成功」を監視対象にする（取れているつもりで取れていないのが最悪パターン）。RPO（許容データ損失時間）を業務部門と合意して取得頻度を決める。
データを復元する機能	バックアップからデータを指定時点の状態に戻す	誤処理・誤操作後のデータ復旧	復元手順、復元確認プロセス	標準機能難易度：中実現手段：サーバー管理ポータルの復元機能（標準）。外部DBはDB側のリストア。実装：全体復元は「全業務がその時点に巻き戻る」劇薬のため、誤更新対応の第一手段は変更履歴テーブルからの部分戻しコマンド（カテゴリー14の履歴を利用した業務側リカバリ機能）として用意しておく。 ⚠ 部分復元（特定テーブルのみ）は標準機能では不可の前提で設計する。年1回の復元リハーサル（手順書どおりに戻せるかの訓練）を運用計画に含めること。
二重実行を防止する機能	同一処理が重複して実行されないようにロック・制御する	バッチの多重起動防止、二重登録防止	ロック方式（ファイルロック・DBロック）の選定	カスタム開発難易度：低実現手段：実行中フラグテーブル（ジョブID・実行中・開始日時）を用意し、ジョブ冒頭で「実行中なら即終了」、末尾（エラー時含む）でフラグ解除するパターンを標準ジョブフレームに組み込む。実装：画面側の二重送信はボタンの実行中非活性化＋登録前の重複チェック（同一キー存在確認）の二段構えで防ぐ。 ⚠ 異常終了でフラグが残留すると翌日以降のジョブが全て止まる。「開始からN時間超過したフラグは自動解除＋警告通知」の救済ロジックを必ず入れる。
処理結果を確認する機能	処理後に期待通りの結果となったか検証する	バッチ完了後の件数・金額整合確認	確認項目の定義、確認結果の記録	カスタム開発難易度：低実現手段：ジョブ末尾に検証ステップ（入力件数＝処理件数＋エラー件数、金額合計の一致等）を組み込み、結果を検証結果テーブルに記録。NG時はメール通知＋後続ジョブの起動抑止。実装：検証項目と期待値の定義をジョブ別の検証定義テーブルに外部化すると、検証ロジック自体は共通実装で済む。 ⚠ 「処理は正常終了したが結果が間違っている」を検知するのがこの機能の目的。正常終了コードだけ見て安心する運用にしないよう、朝の運用確認は検証結果まで見る手順にする。
データ保全ポリシーを管理する機能	データ保存期間・削除・アーカイブのルールを管理する	コンプライアンス要件に基づくデータ管理	保存期間の業務別定義、定期削除の自動化	カスタム開発難易度：低実現手段：保全ポリシーテーブル（データ種別・保持年限・アーカイブ方式・根拠規程）＋月次スケジュールタスクで「アーカイブ→削除」を自動実行（カテゴリー14のログ保存期間管理と同一基盤）。実装：ポリシーの変更は管理画面経由とし、変更履歴を残す。削除実行のレポートを月次で保全担当者へ自動送付する。 ⚠ 保持年限の根拠（社内規程・法令）をポリシーテーブルの属性として持たせておくと、監査時の説明がデータだけで完結する。
ファイルの世代管理をする機能	同名ファイルの複数バージョンを世代番号や日付で管理する	帳票・マスタファイルの版管理	世代数の上限、旧バージョンの削除ルール	カスタム開発難易度：低実現手段：生成ファイルはファイル名規約（業務名_YYYYMMDD_連番）で保存し、世代情報（版数・作成者・作成日時）をファイル管理テーブルで持つ。旧世代の削除はポリシーテーブル駆動のジョブで自動化。実装：アプリ内で完結させるなら添付ファイル型フィールド＋版管理テーブル（同一文書IDに版レコードを積む）で「最新版表示＋履歴一覧」を構成できる。 ⚠ 文書の版管理・共同編集が本題なら、SharePoint等の文書管理基盤との役割分担を先に決める（何でもForguncyに寄せない）。

17 バッチ処理・スケジュール実行機能 7機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
タスクスケジューラで定時実行する機能	Windowsタスクスケジューラ等でマクロを定時自動実行する	日次・月次の定時バッチ処理	実行ユーザー・権限の設定、実行ログの取得	標準機能難易度：低実現手段：「スケジュールタスク」機能（標準）でサーバーサイドコマンドを日次・週次・月次・時刻指定で自動実行。VBA時代の「実行専用PC＋タスクスケジューラ＋開きっぱなしExcel」という脆弱な構成が丸ごと不要になる。実装：全タスクに標準ジョブフレーム（実行ログ・二重起動防止・結果通知）を適用する。 ⚠ タスク失敗時の自動通知・リトライ設定の有無はv10仕様を要確認。標準になければジョブ履歴テーブル＋監視ジョブ（未実行・異常検知→メール）で補完する。
処理対象を一括処理する機能	大量レコードや複数ファイルをまとめてループ処理する	月次全支店分のデータ一括集計	処理件数の管理、メモリ効率化	標準機能難易度：中実現手段：サーバーサイドコマンドの繰り返し（ループ）処理で標準対応。ただし対象が数万件を超える場合はループでの逐次更新は使わず、カスタムWeb APIからセットベースSQL（一括UPDATE／INSERT SELECT）で処理する。実装：「支店ごとにループ」のような粗い単位のループは標準コマンド、「明細行ごと」の細かい処理はSQL・API側、と粒度で使い分ける。 ⚠ VBAのForループをそのまま「繰り返しコマンド」に移植するのが最頻出のアンチパターン。件数×1件あたり処理時間を必ず試算し、分単位を超えるならSQL集合演算へ設計変更する。
処理の依存関係を制御する機能	先行処理が完了してから後続処理を実行する順序制御	データ取込→集計→帳票出力の順序管理	先行処理の完了確認方法	カスタム開発難易度：中実現手段：直列依存は1つのスケジュールタスク内にコマンドを順次配置するのが最も確実（取込→検証→集計→帳票を1本に）。タスクを分けざるを得ない場合は、後続タスク冒頭で先行ジョブの完了ステータス（ジョブ履歴テーブル）を確認し、未完了なら終了・通知。実装：ジョブ間の依存関係図（ジョブネット図）を設計書として整備する。 ⚠ 行内に既存のジョブ管理基盤（JP1等）がある場合は、そこからForguncyのジョブをHTTP経由で起動する統合構成も検討価値あり（起動エンドポイントの認証方式は要確認）。全社のジョブ運用を二重化しない判断が重要。
処理結果を集計・報告する機能	バッチ処理の実行結果（件数・金額・エラー数）をまとめて報告する	夜間バッチの結果を翌朝担当者に報告	報告先・報告方法（メール・ファイル）	標準機能難易度：低実現手段：ジョブ末尾で「メールを送信する」コマンドにより結果（処理件数・金額・エラー件数・検証結果）を本文差し込みで送信（標準）。実装：正常時は要約1通（全ジョブ分をまとめた朝会レポート形式）、異常時は即時個別通知、と通知レベルを分ける。件名の規約（【正常】【警告】【異常】）で振り分け・見落とし防止。 ⚠ 「毎朝大量の正常メール」は必ず読まれなくなる。異常時のみ目立たせる設計と、ジョブ履歴ダッシュボード（画面で一覧確認）の併用が実用的。
バッチを一時停止・再開する機能	緊急時にバッチ処理を安全に停止・再開できるようにする	異常検知時の緊急停止、復旧後の再開	停止タイミングの制御、再開時のデータ整合性	カスタム開発難易度：中実現手段：スケジュール起動の停止（タスクの無効化）は管理ポータルで標準対応。実行中ジョブの安全な中断は、停止フラグテーブル＋チャンク境界でのフラグ参照（立っていたら現チャンク完了後に終了）で実装。実装：再開はチェックポイント方式（本カテゴリー1行目）と同一の仕組みで未処理分から継続する。 ⚠ 実行中プロセスの強制終了（kill）は中途半端なデータを残す最終手段であり、運用手順としては設計しない。「止められる作りにしておく」ことが設計段階の責務。
月次・年次の締め処理を実行する機能	月次・年次の締め作業に伴う一連の処理を順次実行する	月末締めの残高確定・帳票生成・アーカイブ	締め後の修正制御、締め解除手順	カスタム開発難易度：中実現手段：締め状態テーブル（年月・締め区分・実行者・日時）を中心に設計。締めバッチはスケジュールタスクの直列コマンドで実行し、締め済み期間の入力画面は締め状態を条件式に読取専用化（セルプロパティ・行レベル制御）。実装：締め解除は権限者限定ページ＋理由必須＋操作ログ必須で実装。締め前チェックリスト（未承認案件の有無等）を画面化すると締め作業自体が標準化される。 ⚠ 締めと締め解除の統制（誰が・どの承認で）は監査上の重要論点。システム化と同時に事務規程側の改訂も必要になるため、業務部門を早期に巻き込む。
処理の並行実行を制御する機能	複数処理の並行実行と排他制御を管理する	独立した複数業務の同時バッチ実行	共有リソースへのアクセス競合防止	カスタム開発難易度：中実現手段：独立した業務のタスクは並行実行で問題なし。同一テーブルを大量更新するジョブ同士は、実行時間帯の分離（ジョブスケジュール設計）＋排他フラグ（リソース単位のロックテーブル）で直列化する。実装：ジョブ一覧に「使用リソース（テーブル）」列を持たせ、競合の有無を設計段階で機械的に洗い出せるようにする。 ⚠ 夜間バッチ時間帯とオンライン利用（残業中の画面操作）の競合も考慮する。大量更新ジョブの実行時間帯は業務部門と合意し、周知する。

18 運用・保守機能 7機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
設定ファイルで動作を切り替える機能	外部設定ファイルで接続先・パラメータをコードを変更せず切り替える	本番・テスト環境の切替、パラメータ変更	設定ファイルのフォーマット管理、変更履歴	標準機能難易度：低実現手段：インフラ系設定（外部DB接続・SMTP）は各環境のサーバー管理ポータルで管理（標準）。業務パラメータ（閾値・パス・フラグ）はアプリ内のパラメータテーブル＋管理者用メンテ画面で持つ。実装：パラメータテーブルには説明・変更者・変更日時の列を持たせ、変更履歴を残す。環境判定フラグ（本番／検証）もパラメータ化し、テスト環境ではメール宛先差替等に利用（カテゴリー02参照）。 ⚠ VBAの「設定シート」「iniファイル」文化からの移行先を「サーバー設定」と「パラメータテーブル」のどちらにするか、項目分類表を作って整理してから移すと迷いがない。
マスタデータを管理する機能	業務マスタの登録・更新・削除をアプリから行う	コード変換テーブル・業務パラメータの更新	マスタ更新の承認フロー、変更履歴管理	標準機能難易度：低実現手段：マスタメンテページ（リストビュー＋CRUDコマンド）＋更新権限ロールで標準構成。重要マスタは変更履歴（カテゴリー14）と更新承認ワークフロー（カテゴリー11）を組み合わせる。実装：マスタには有効期間（適用開始日・終了日）を持たせ、物理削除でなく失効で運用するのが業務系の定石。 ⚠ 「Excelでマスタ表を配布・各自コピー」の現行運用が一元DB化されること自体が移行の大きな効果。マスタ所管部署と更新権限の割当を移行時に明文化する。
バージョン情報を管理する機能	アプリのバージョン番号・改版履歴を管理する	リリース管理、問い合わせ対応時のバージョン確認	バージョン表示場所、変更履歴ドキュメントの連動	カスタム開発難易度：低実現手段：発行（リリース）時にバージョン番号をパラメータテーブルへ更新し、全ページ共通フッターに表示。リリース内容は改版履歴テーブル＋お知らせページで利用者に周知。実装：発行手順書に「バージョン番号更新」「改版履歴登録」をチェック項目として組み込み、リリース作業と一体化する。 ⚠ Forguncyのプロジェクトファイルはバイナリ形式のためGitでの差分管理に不向き。日付付きプロジェクトファイルの世代保管＋変更管理台帳の運用ルールを開発初日から決めておくこと（後から整備するのは困難）。
処理状況をモニタリングする機能	稼働中の処理の実行状況をリアルタイムで監視する	バッチ処理の進捗確認、処理遅延の検知	監視項目・閾値の定義、アラート通知	標準機能難易度：低実現手段：ジョブ履歴テーブルを運用ダッシュボードページ（当日ジョブの状態一覧・実行時間グラフ）で可視化（標準の組み合わせ）。タスクの実行状況・サーバーログは管理ポータルでも確認。実装：遅延検知（想定終了時刻超過）・未実行検知は監視ジョブ＋メール通知で自動化。サーバー自体の死活監視は行内の監視基盤（Zabbix等）に載せる。 ⚠ アプリ内監視はForguncyサーバーが生きている前提でしか機能しない。サーバーレベルの監視（サービス稼働・ディスク・証明書期限）との二層構成を運用設計書に明記する。
ヘルプ・操作マニュアルを表示する機能	アプリ内からヘルプや操作手順を参照できるようにする	利用者の操作サポート、問い合わせ削減	ドキュメント管理方法、更新運用	標準機能難易度：低実現手段：各ページにヘルプリンク・入力項目のツールチップ（ヒント表示）を設置し、マニュアル本体はヘルプページ（画像・PDF添付）として同一アプリ内に置く（標準）。実装：「よくある問い合わせ」をFAQテーブル化して検索可能にすると、問い合わせ削減効果が高い。更新はページ・データの差し替えのみで、配布作業が不要になる。 ⚠ マニュアルの所管（システムか業務か）と更新タイミング（リリースと同時）を運用ルール化する。画面とマニュアルの乖離は問い合わせ増加の主因。
テスト・本番環境を切り替える機能	接続先DBやファイルパスを環境別に切り替える	開発・テスト・本番の環境分離	環境設定の誤切替防止、切替確認ダイアログ	標準機能難易度：低実現手段：開発（Builder）→検証サーバー→本番サーバーの3環境を分離し、環境依存設定（DB接続・SMTP・パス）は各サーバーのポータル設定で切替（標準）。アプリ本体は同一プロジェクトを発行先だけ変えて配置。実装：発行フロー（検証環境での受入確認→承認→本番発行）を変更管理手順として文書化し、本番発行の実施者・承認者を分離する。 ⚠ 本番発行時の既存データ保持・スキーマ変更（列追加等）の反映挙動はPoCで必ず確認。画面に環境名バナー（検証環境は目立つ色）を表示して誤操作を防ぐのが定番の工夫。
移行・初期データを投入する機能	新規稼働時や移行時に初期データをセットアップする	新システム稼働時のマスタ・初期値設定	初期化処理の冪等性、本番データとの分離	標準機能難易度：中実現手段：設計時はBuilderのExcelインポート（Excelからテーブル作成・データ投入）、稼働後の大量投入は取込基盤（カテゴリー01）またはカスタムWeb APIを利用。実装：移行データは「変換→投入→件数・金額検証→業務側サンプル検収」の4ステップを移行リハーサルとして本番前に最低2回実施する。検証結果は移行判定会議のエビデンスにする。 ⚠ VBAブック内に散在する現行データの抽出・クレンジング（カテゴリー04の正規化）が移行工数の本体になりがち。データ移行を「開発の付録」ではなく独立したワークストリームとして計画する。

19 テスト・検証・品質管理に関する機能 6機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
テストデータを生成する機能	テスト用のサンプルデータを生成・準備する	単体テスト・結合テスト用データの準備	本番データのマスク、テストデータのバリエーション確保	カスタム開発難易度：低実現手段：本番相当データが必要な結合テストは「本番バックアップ→検証環境へ復元→マスクジョブ実行（カテゴリー13）」の手順を標準化。単体テスト用の少量データはExcelからのインポートで投入。実装：境界値・異常値のバリエーションデータはテストデータ定義Excelとして整備し、繰り返し投入できるようにしておく。 ⚠ マスクなしの本番データを検証環境へ置くことは社内ルール上ほぼ不可。マスクジョブの整備をテスト計画の前提タスクとして先行させる。
処理結果を自動検証する機能	処理後の結果を期待値と自動比較する	バッチ処理後の件数・金額の自動確認	検証項目・許容誤差の定義	カスタム開発難易度：低実現手段：期待値テーブル（テストケースID・検証SQL相当の条件・期待件数／金額）＋検証実行コマンドで実績と自動比較し、結果一覧をリストビューで確認。運用後はカテゴリー16の「処理結果確認」と同一基盤に統合。実装：新旧比較（VBAの出力とForguncyの出力の突合）は移行テストの中核。カテゴリー06の汎用照合エンジンを新旧比較にもそのまま使う。 ⚠ 新旧比較で差異が出た場合、「旧VBAのバグだった」ケースが相当数出る。差異の裁定ルール（どちらを正とするか誰が決めるか）を移行計画で先に決めておく。
デバッグ情報を出力する機能	開発・テスト時に変数値や処理経路をログ出力する	バグ発生時の原因調査	デバッグモードの切替、本番時の出力無効化	標準機能難易度：低実現手段：Forguncy Builderのプレビュー実行・デバッグ機能でコマンドの動作・変数値を確認（標準）。実行経路のトレースが必要な場合はログテーブルへのデバッグ書込（パラメータテーブルのデバッグフラグでON/OFF）を併用。実装：カスタムWeb API側はVisual Studioの通常のデバッグ・単体テストが使える。ロジックをAPI側に寄せるほどテスト容易性が上がる。 ⚠ VBEのステップ実行・ウォッチに相当する開発体験の差はPoCで開発担当者が実際に体感して評価する（開発生産性の見積りに直結）。本番環境ではデバッグフラグOFFを発行チェックリストで担保。
回帰テストを実行する機能	改修後に既存機能が壊れていないか確認するテストを実行する	改修リリース前の影響確認	テストケースの管理・バージョン管理との連動	設計転換難易度：中実現手段：Webアプリ化により Playwright／Selenium 等のブラウザ自動化ツールでE2E回帰テストが組める（VBA時代には事実上不可能だった品質保証手段）。主要業務シナリオ（申請→承認→帳票出力等）を自動化し、リリース前・Forguncyバージョンアップ時に流す。実装：データ検証系の回帰は期待値テーブル方式（本カテゴリー2行目）で自動化し、画面E2Eは主要動線に絞るのが費用対効果の良い配分。 ⚠ E2E自動化はセル型のDOM構造に依存するため、Forguncyバージョンアップで壊れる可能性を織り込み、メンテナンス担当を決めてから導入する。まずは手動回帰テスト表の整備から始めても良い。
処理件数・金額の整合性を検証する機能	取込件数・処理件数・出力件数の一致を検証する	バッチ処理のコントロールトータル確認	検証ポイントの定義、不一致時の対処手順	カスタム開発難易度：低実現手段：ジョブの各工程（取込・変換・出力）で件数・金額をジョブ履歴テーブルへ記録し、末尾の検証ステップで工程間の一致を自動判定（カテゴリー16の結果確認と同一基盤）。実装：不一致時は後続ジョブを止め、不一致内容（どの工程間で何件差）を明示した異常通知を送る。対処手順（調査→再実行）を運用手順書に紐づける。 ⚠ 検証ポイントは「データが形を変える箇所」（ファイル→テーブル、テーブル→帳票）ごとに置くのが原則。工程を跨いだ合計だけ見ると原因特定に時間がかかる。
エラー率・品質指標を測定する機能	処理エラー率や品質指標を記録・集計する	業務品質の継続的モニタリング	指標定義、閾値超過のアラート	標準機能難易度：低実現手段：エラーログ・ジョブ履歴（カテゴリー14）を月次集計し、グラフ型セル・ピボットで品質ダッシュボードを構成（標準の組み合わせ）。閾値超過は日次スケジュールタスクで判定しメール通知。実装：指標定義（取込エラー率・差戻し率・処理遅延回数等）と閾値をパラメータテーブルで管理し、指標の追加を実装なしで行えるようにする。 ⚠ 指標は「改善アクションにつながるもの」に絞る。ログ基盤（カテゴリー14）が整っていれば、この機能はほぼ集計ページの追加だけで実現できる。

20 非機能要件に関係する機能 8機能

機能名	概要	主な利用場面	将来Forguncy対比時の観点	Forguncyでの対応方針（v10・実装ガイド）
処理性能を最適化する機能	大量データ処理時の処理時間・メモリ使用量を最適化する	月次大量バッチの処理時間短縮	処理件数と時間の測定、ボトルネック分析	設計転換難易度：中実現手段：性能の基本方針：（1）データ量の多い業務は外部DB（SQL Server等）構成、（2）重い集計・変換はDB側（ビュー・ストアド・セットベースSQL）へ、（3）画面はサーバーサイドページング＋検索条件必須化、（4）バッチはチャンク処理。実装：インデックスは検索条件・結合キーに合わせてDB設計時に定義し、月次で実行時間の推移（ジョブ履歴）を確認して劣化を早期検知する。 ⚠ 移行前に現行VBAの処理件数・処理時間を実測して性能要件として文書化し、PoCで同等データ量の性能試験を必ず実施する。「動くが遅い」は移行プロジェクトの主要な失敗パターン。
処理時間を計測する機能	処理の開始・終了・所要時間を計測・記録する	SLA管理、パフォーマンス問題の特定	計測粒度の定義、履歴による傾向分析	カスタム開発難易度：低実現手段：バッチはジョブ履歴テーブルの開始・終了日時（カテゴリー14の標準ジョブフレームで自動記録）から所要時間を算出し、推移をグラフ化。画面応答はサーバーログ・ブラウザ開発者ツールで必要時に測定。実装：SLA対象処理（〇時までに完了必須のバッチ等）を定義し、閾値超過を監視ジョブで自動検知・通知する。 ⚠ 処理時間は「データ量とセット」で記録する（件数が倍なら時間も伸びて当然）。1件あたり処理時間の推移を見るのが劣化検知の正しい指標。
可用性・継続性を確保する機能	障害時にも業務が継続できるよう代替手順・バックアップ処理を備える	緊急時の手動代替処理、フォールバック	RTO/RPO要件の定義、代替手順のドキュメント化	設計転換難易度：中実現手段：アプリ層はバックアップ・復元（カテゴリー16）＋復旧手順書＋定期リハーサル。サーバー冗長化・DR構成はインフラ設計の領域として、行内のサーバー基盤標準（仮想化基盤のHA等）に載せる。実装：業務別のRTO／RPOを業務部門と合意し、システム停止時の代替手順（紙・Excelでの一時運用と復旧後のデータ追入力）をBCP文書として整備する。 ⚠ VBA時代は「個人PCで動くからサーバー障害と無縁」だったが、集中化によりサーバー障害＝全員停止になる。この構造変化を業務部門に説明し、可用性投資の判断材料にすること。Forguncyの負荷分散・冗長構成の対応可否とライセンス条件は要確認。
スケーラビリティを確保する機能	データ量・ユーザー数の増加に対応できる設計にする	処理件数増加への対応、利用者増加への対応	限界値テスト、段階的な負荷試験	設計転換難易度：中実現手段：データ増は外部DB側のスケール（ストレージ・スペック）で吸収する構成を最初から選択。ユーザー増はForguncyサーバーのスペックアップ＋ライセンス（同時接続／ユーザー数）の追加で対応。実装：全社展開を見据える場合は、初年度に利用者数計画（部署別・時期別）を作りライセンス体系と照合しておく。 ⚠ ライセンス体系（ユーザー数・同時接続数・サーバー数）はアーキテクチャ選択そのもの。アプリを増やす前に全体計画とコスト試算をベンダーと確認する。想定ピーク（月末月初の同時利用）での負荷試験もPoC項目に含める。
保守性を確保する機能	ソースコードの可読性・変更容易性を確保する	改修時の影響範囲の明確化、ドキュメントの整備	コーディング規約、モジュール分割方針	標準機能難易度：低実現手段：命名規約（ページ・テーブル・コマンド・変数）、共通処理の部品化（ログ書込・採番・営業日計算等の共通コマンド／共通Web API）、ロジックのパラメータテーブル外部化、を開発標準として最初のアプリで確立する。実装：設計書はテーブル定義・ページ一覧・コマンドフロー・ジョブネット図の4点セットを標準フォーマット化。 ⚠ VBA属人化の解消こそ移行の主目的。規約なしでForguncy開発を始めると「ノーコード版の属人化」が再生産される。開発標準の制定を最初のPoCの成果物に含めること。
互換性を確保する機能	Officeバージョン・OS・DBのアップグレードに対応する	Office 365移行、Windows OSアップグレード対応	依存バージョンの明示、互換テスト手順	標準機能難易度：低実現手段：Webアプリ化によりOffice・クライアントOSのバージョン依存から解放される（Excel更新のたびの動作確認が不要になる）。残る依存はブラウザ（Edge／Chrome）とForguncy本体・サーバーOS・.NETランタイム。実装：Forguncyの年次バージョンアップ検証プロセス（検証環境で回帰テスト→本番適用）を運用計画に組み込み、サポート期限（EOL）を追跡する担当を決める。 ⚠ カスタムWeb API・カスタムJavaScriptはバージョンアップ時の互換性確認対象。カスタムコードの一覧（どのアプリの何に使っているか）を台帳管理しておくと検証範囲が即座に決まる。
同時実行・排他制御を行う機能	複数ユーザーが同時操作する際のデータ競合を防ぐ	共有マスタの同時更新防止	楽観ロック・悲観ロックの選択基準	標準機能難易度：中実現手段：Forguncyは多人数同時利用前提のWebアプリ基盤であり、「ブックが開かれていて編集できない」というVBA時代の問題自体が解消される。同一レコードの同時更新は、更新日時チェック（楽観ロック）を更新コマンドの条件に組み込んで検知する。実装：重要マスタ・長時間編集する画面は「編集中フラグ」（誰がいつから編集中か）による悲観ロック方式を実装し、放置フラグの自動解除も併せて設計。 ⚠ 同時更新が競合した場合の標準動作（後勝ち／エラー）はPoCで確認し、業務上「後勝ちで消えてはいけない」テーブルには必ず楽観ロックを明示実装する。
応答性・操作性を確保する機能	ユーザーが快適に操作できるUI応答速度を確保する	大量データ検索時の待ち時間短縮	非同期処理の活用、進捗表示との連動	標準機能難易度：低実現手段：リストビューのページング・初期表示の絞り込み（全件表示させない）・画面あたりの数式やセル数の抑制で応答性を確保。重い処理はサーバーサイド化し「読み込み中」表示、さらに長い処理はジョブ化＋完了通知へ（カテゴリー07参照）。実装：応答性の目標値（検索3秒以内等）を非機能要件として定義し、PoC・受入テストの合否基準にする。 ⚠ 「Excelはセルをすぐ動かせたのにWebは遅い」という体感差への不満は必ず出る。高頻度入力画面はキーボード操作（Tab移動・Enter確定）の作り込みで操作テンポを確保するのが受容度向上の鍵。

21 機能一覧を作成した後の整理方法（Forguncy対比表への展開観点） 10項目

整理観点	内容	活用場面
Excel VBAでの実現方法	VBAでどのような仕組み・処理方式（ADO接続、ユーザーフォーム、API呼出等）で実現していたかを整理する	移行前の現状把握の基礎となる
Forguncyでの対応機能	Forguncy上で対応できる機能・設定・仕組みを記載する（本表の「実現手段」欄が転記元になる）	製品ドキュメント・検証結果をもとに記入
標準機能で対応可能か	標準機能のみで実現できるか（○／△／×）を判定する（本表の対応区分バッジ：標準機能＝○、カスタム開発＝△、設計転換＝×が初期値）	追加開発コスト見積の前提情報
プラグインや外部連携が必要か	追加プラグイン、外部ツール、カスタムコードが必要か確認する	ライセンス・コスト・調達リードタイムに影響
代替設計が必要か	VBAと同じ実装思想では実現困難なため、別方式への置き換えが必要かを判定する（本表の「設計転換」バッジ項目が該当候補）	設計工数・リスクに直結する重要観点
難易度	移行・再設計の技術的な難しさ（高／中／低）を評価する（本表の難易度欄が初期値。個別業務の複雑さで補正する）	プロジェクト計画・要員計画の根拠
業務重要度	企業内業務上の重要性（高／中／低）を評価する	移行優先度・リスク評価の根拠
優先度	先に検討・学習・PoC実施すべき機能かを判定する（高／中／低）。本表の⚠印（要実機検証）項目はPoC優先度が高い	フェーズ計画・PoC計画の策定に活用
リスク	セキュリティ、監査対応、障害、データ不整合等のリスクを記載する	リスク管理表・移行判断の材料
検証観点	移行後に重点的にテストすべきポイントを記載する（本表の「注意」欄の⚠事項がテスト観点の種になる）	テスト計画・受入基準の策定に活用