対象にする設定を業務への影響をもとに絞り込み、変更のたびに「誰が・いつ・何を・なぜ変えたか」を台帳に残します。追補版は、財務報告に重要な影響を及ぼすパラメータの変更を変更管理の対象に含めています。まず承認経路と自動仕訳ルールの変更記録から始めます。
この記事の要約
架空のA社（社員40人、経理2人）は、freee会計とバクラク請求書でバックオフィスを回しています。IPO準備の監査法人から「設定を変えた記録を見せてください」と言われ、承認経路の変更履歴を探しましたが、誰がいつ変えたのか、どこにも残っていませんでした。実は3か月前、月末の締めに間に合わせるために経理担当が承認経路を組み替え、そのまま戻していなかったことが分かりました。変更の理由も残っておらず、「なぜ承認経路が変わっているのか」に答えられません。
設定の変更は、プログラムがなくてもITGCの変更管理に残る
SaaSを使う会社では、プログラムの開発や保守はベンダーが担います。プログラムの変更管理はベンダー側のSOC1レポートで確かめる領域です（SOC1レポートの読み方の記事）。しかし、承認経路や自動仕訳ルールなどの設定は自社で変えるため、その変更管理は自社の仕事として残ります。
経済産業省の「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（2024年12月25日改訂、以下 追補版）は、変更管理の統制評価手続の例の中で、財務報告に重要な影響を及ぼすパラメータの変更を含む本番環境のすべての変更について、変更管理手続に従って管理されていることが望まれるとしています（第IV章 3.(1)③）。追補版は、パラメータの変更、すなわちSaaSの設定変更を、変更管理手続の対象に含めています。
315実務ガイダンス第1号のQ26も、重要な自動化された情報処理統制について、パラメータ設定が可能な場合は「企業の業務に適合したパラメータ値となるよう、承認、事後検証等の管理手続が取られているか」「パラメータ値を変更できる権限が、職務上必要なユーザに限定して付与されているか」の検証が重要だとしています。Q26はERPを扱う問いですが、SaaSの設定にも同じ考え方が当てはまります。
注意が必要な点があります。SaaSのベンダーが行うアップデート（新機能の追加やUIの変更）は、ベンダー側の変更管理の対象です。自社の変更管理台帳に載せるのは、自社の担当者が設定画面から変えた変更です。ただし、ベンダーのアップデートで設定の初期値や挙動が変わった場合は、その影響を確認し、必要に応じて設定を見直したことを記録します。
同じ追補版は、パッケージソフトウェアについて「購入したままの状態では十分な統制が実現できないことに注意する」とし、例に不正なデータ改ざんを防止するためのアカウント管理や権限の設定、自動仕訳の設定、仕訳の承認者の設定、他システムからのデータ連携の設定を挙げています（第IV章 3.(1)①）。設定がそもそも統制の一部なのですから、設定の変更を管理するのは当然です。ITGCの全体像はSaaSで経理を回す会社に残るITGCの記事で扱っています。
対象にする設定は、業務処理統制への影響で絞り込む
SaaSの設定画面にはたくさんの項目がありますが、すべてを変更管理の対象にする必要はありません。追補版は統制評価手続の例で、財務報告に重要な影響を及ぼすパラメータの変更を変更管理の対象に含めており（第IV章 3.(1)③）、対象を絞り込む基準は「財務報告への影響」です。
編集部の整理では、優先して対象にする設定は次の4種類です。
- 承認経路の設定: 仕訳の承認フローや経費精算の承認経路を変えると、承認が素通りするおそれがあります。SaaSで経理を回す会社に残るITGCの記事で扱ったとおり、freee会計では承認者に自分を足すと、自分の仕訳が作成時点で承認済みになります
- 自動仕訳ルール: 自動登録ルールの勘定科目や条件を変えると、仕訳の分類が変わります。追補版は変更管理の統制に関する指針で「自動仕訳の対象データや使用する勘定科目を変更する際は、分類と報告の完全性を確実にするため、変更前の適切な承認と変更後のテストを実施する」としています（第IV章 3.(1)③）
- 権限セットの変更: カスタム権限の設定を変えると、特定の操作ができる人が増えたり減ったりします。権限の棚卸は権限の棚卸の進め方の記事で扱っています
- 連携設定: バクラクからfreeeへの連携やAPI連携の設定を変えると、データの受け渡しに影響します。freeeのイベントログでも、他製品からのデータ連携は記録の対象外です（公式ヘルプ「イベントログの見方」、2026年10月16日更新）。連携の設定変更は、台帳に手で残さなければ追えません
4種類すべてを一度に始める必要はありません。A社の例では、まず承認経路と自動仕訳ルール（変更が起きたときの影響が大きい2つ）から始め、次の四半期で権限セットと連携設定に広げました。画面の配色やメール通知の設定など、財務報告に影響しないものは対象外にして構いません。監査法人と協議して、自社で使っているSaaSの設定のうち対象にするものを決めます。315実務ガイダンス第1号のQ27は、監査人が市販の簡易なパッケージを検証する際の留意点として「初期設定項目（パラメータ）の設定・維持」を挙げ、「自動採番、消費税処理、その他配賦の自動計算処理に係るパラメータの設定等」を例にしています。監査人が確認する設定項目を参考にすると、自社で管理すべき設定の洗い出しに役立ちます。
変更台帳は「申請・承認・変更内容・確認」の4列で始める
追補版は変更管理の統制目標として、起案から完了までの状況を文書管理し進捗を把握すること（3-(1)-③-ホ）、変更の結果を業務担当者と開発責任者が承認し、変更による影響を運用責任者に伝えること（3-(1)-③-ニ）を挙げています。これを最小構成にすると、変更台帳に「いつ・誰が申請し・誰が承認し・何をどう変えたか」を1行で残す形になります。
| 列 | 記録する内容 |
|---|---|
| 日付 | 変更の申請日と実施日 |
| 申請者 | 変更を申請した人 |
| 承認者 | 変更を承認した人（申請者と別の人） |
| 変更内容 | どのSaaSのどの設定を、何から何に変えたか。変更の理由 |
台帳の形式はスプレッドシートで十分です。A社の例では、経理担当が「freee会計の承認経路を、経理部長→管理部長の2段階から、経理部長の1段階に変更したい。理由は管理部長の不在が続き承認が滞るため」と申請し、管理部長が承認したうえで変更を実施し、台帳に1行残します。大事なのは、変更の前に承認を得ること、変更の内容が後から追えること、申請者と承認者を別の人にすることの3つです。追補版は「変更管理ルールと手順を定め、業務責任者並びに開発及び保守の責任者が承認すること」（3-(1)-③-イ）としています。経理責任者が設定を変える場合は、管理部長や上位者が承認者になります。
緊急の変更が生じることもあります。月末の締めに間に合わせるために、承認を待たずに設定を変えるケースです。追補版は「緊急の変更要求は文書化され、変更管理手続に従っていること」（3-(1)-③-ハ）としています。緊急で変えた場合は、台帳に「緊急」と記録し、翌営業日までに承認者が事後承認する手順を決めておきます。
freeeでは、設定変更の履歴がプランによって大きく違う
freee会計で設定変更の履歴を追えるかは、プランによって大きく変わります。2026年10月時点の公式ヘルプから、設定変更の記録に関係する機能を整理します。
| 機能 | 使えるプラン |
|---|---|
| カスタム権限 | スタンダード以上 |
| 仕訳承認フロー | アドバンス以上 |
| 仕訳承認設定の変更履歴 | エンタープライズのみ |
| 権限の変更履歴 | エンタープライズのみ |
| イベントログ（全操作ログ） | エンタープライズのみ |
| 優良電子帳簿に伴う操作履歴 | 全プラン |
エンタープライズのイベントログは、自動登録ルール・配賦ルール・テンプレート類の作成・更新・削除を記録します。承認経路や権限の変更については、イベントログとは別にエンタープライズ限定の専用画面（仕訳承認設定の変更履歴、権限の変更履歴）が用意されています。ただし、他製品からのデータ連携や連携に伴うfreee会計への反映は記録の対象外です（公式ヘルプ「イベントログの見方」、2026年10月16日更新）。
エンタープライズ以外のプランでは、設定変更の履歴が自動では残りません。優良電子帳簿に伴う操作履歴は全プランで使えますが、記録されるのは仕訳・固定資産台帳・勘定科目とタグの変更だけで、承認経路や権限の変更は含まれません（公式ヘルプ「優良電子帳簿について」、2026年6月26日更新）。「操作履歴」という名前から承認経路の変更も追えると誤解しがちですが、この機能は電子帳簿保存法の要件を満たすための仕訳の変更履歴であり、設定変更の記録は目的に含まれていません。
エンタープライズ以外のプランを使っている場合は、設定を変える前後にスクリーンショットを撮り、変更台帳と一緒に保存する方法で代替します。手間はかかりますが、変更の前と後の状態が画像で残っていれば、監査で設定変更の経緯を聞かれたときに説明できます。台帳とスクリーンショットを同じフォルダに置き、台帳の行から画像へのリンクを張っておくと、後から探しやすくなります。
バクラクシリーズでは、バクラク請求書発行に「監査ログ」機能があり、書類の作成・編集・発行・削除などの操作を記録できます（A社が使っているバクラク請求書（受領側）と別の製品です）。承認経路や権限設定の変更がこのログに残るかは、2026年10月時点の公開情報からは確認できませんでした。自社環境で設定を変えたときにログが残るか、実際に試して確かめておくことをお勧めします。バクラクはSOC1 Type2報告書を取得しており（基準期間 2024年7月〜12月）、委託先の管理の考え方はSOC1レポートの読み方の記事で扱っています。
台帳を始めたら、四半期ごとに実際の設定と突き合わせる
変更台帳は、設定を変える前に申請と承認を通すための記録です。ただし台帳だけでは、申請を通さずに変えられた設定は見つかりません。冒頭のA社の承認経路の組み替えも、台帳があったとしても、担当者が記入しなければ残らなかったはずです。そこで、四半期や期末の締めに合わせて、台帳の記録と実際の設定を突き合わせる事後の確認を手順に加えます。
追補版は変更管理の統制評価手続の例として、承認されていない不明な変更がないかを確かめることを挙げ、本番システムの変更記録を入手して、変更要請、承認、移行等を追跡し、不明なものがないか確かめる例を示しています（第IV章 3.(1)③）。315実務ガイダンス第1号のQ26も、パラメータ設定の管理手続として、承認と並べて事後検証を挙げています。事後の突き合わせは、この考え方を自社の手順に置き換えたものです。
編集部の整理では、突き合わせは次の順で進めます。
- 確認する人を決めます。台帳の承認者か、設定を変える権限を持たない人が担当し、設定を変えた本人が自分の変更を確かめる形は避けます
- 期間中に実際に起きた変更を一覧にします。エンタープライズでは、仕訳承認設定の変更履歴、権限の変更履歴、イベントログ（自動登録ルールの作成・更新・削除など）から拾います。それ以外のプランでは、承認経路と自動仕訳ルールの設定画面を開き、前回の確認時に撮ったスクリーンショットと見比べます
- 一覧の変更ごとに、台帳に申請と承認の行があるかを確かめます。反対に、台帳に載っている変更が実際の設定に反映されているかも見ます
- 台帳にない変更が見つかったら、変えた人と理由を聞き取り、承認者が事後承認するか、元の設定に戻すかを決めます。どちらにしたかと、その理由を台帳に追記します
- 確認した日、確認した人、見た画面や履歴、差異の有無を、台帳の別シートに1行残します。期間中に変更が一度もなかった場合も、確認した事実を残します
A社の例では、四半期の締めの翌週に管理部長が承認経路と自動登録ルールの設定画面を確認し、前回のスクリーンショットと台帳を並べて差異がないことを確かめ、確認の行を残す運用にしました。台帳にない変更が同じ担当者から繰り返し見つかる場合は、手順を守る呼びかけより先に、設定を変えられる権限をその人から外すことを検討します。Q26が、パラメータ値を変更できる権限を職務上必要なユーザに限ることを、承認や事後検証と並べて挙げているためです。
読み違えやすいポイント
| ポイント | 正しい扱い |
|---|---|
| 付録6の「調整可能な設定」がSaaSの設定変更管理の根拠になる | 監基報315の付録6はIT環境の変更のリスクの例に「調整可能な設定」を挙げていますが、「複雑ではない市販ソフトウェア」列の変更管理は「無（ソースコードがインストールされていないことを確認する。）」です。これはプログラム変更管理の文脈での「無」であり、設定変更の管理が不要という意味ではありません。ただし設定変更管理の直接の根拠としては、追補版の3.(1)①と3.(1)③、315実務ガイダンスQ26のほうが適切です |
| 実施基準に「パラメータ変更は変更管理の対象」と書いてある | 実施基準の本文には「パラメータ変更」の語は登場しません。パラメータ変更が変更管理に含まれることを明示しているのは追補版（第IV章 3.(1)③）と315実務ガイダンスQ26です。記事や社内の説明では出典を正確に書き分けてください |
明日からやること
- 使っているSaaSの設定画面を開き、承認経路・自動仕訳ルール・権限セット・連携設定の4種類を洗い出す
- 変更台帳（スプレッドシート）を作り、「日付・申請者・承認者・変更内容」の4列で始める
- 設定を変える前に承認を得る手順と、承認者（申請者と別の人）を決める
- 緊急の変更は「翌営業日までに事後承認」のルールを決めておく
- 四半期の締めごとに、台帳と実際の設定・変更履歴を突き合わせる担当者を決める
- freeeのプランで設定変更の履歴が残るかを確かめ、残らない場合はスクリーンショットで補う
- ベンダーのアップデートで設定の初期値や挙動が変わったときに確認するルールを決めておく
SaaSで経理を回す会社のIT統制の全体像はSaaSで経理を回す会社に残るITGCの記事で扱っています。承認フローや自動仕訳が「統制として頼れるか」は承認フローや自動仕訳をITACとして評価する記事を、権限の棚卸の進め方は権限の棚卸の進め方の記事を参照してください。
IT統制・J-SOX対応の進め方をご相談ください
使っているSaaSの洗い出し、IDと権限・設定変更の記録の始め方、SOC1レポートの読み込み、監査法人との協議に出す案づくりまで、公認会計士とエンジニアが一緒に整理します。