上場準備に入って最初の監査法人との打ち合わせで、管理部長は情報システムに関する質問票を渡されました。会計はfreee、経費精算と請求書の受け取りはバクラクで回していて、社内にサーバーは1台もなく、自社で書いたプログラムもありません。最初の欄の「IT全般統制の評価単位」に「該当なし」と書きかけたところで、次の質問が目に入ります。会計システムの管理者権限を持つ人の一覧、承認経路や自動仕訳の設定を変えた記録、委託先の保証報告書を入手しているかどうか、の3つです。
調べてみると、freeeの管理者権限を持つ人は5人いて、そのうち1人は半年前に退職した経理担当でした。バクラクの承認経路は先月、経理担当が自分の判断で組み替えていて、誰も承認していません。管理部長は、保証報告書という言葉を質問票で初めて目にしました。数字は説明のための仮のものですが、SaaSだけで経理を回している会社では珍しくない場面です。
この記事は、「自社でサーバーもプログラムも持っていないのに、ITGC（IT全般統制）で何を整えればいいのか」という問いに答えます。先に結論を書くと、ITGCは要らなくなるのではなく、中身が入れ替わります。以下では、基準がITGCをどう定義しているか、監査人がどこを見るか、ベンダーと自社で何を分け持つかを順に追い、最後に明日から始めることを並べます。システムに組み込まれた統制（ITAC）の評価の方法は承認フローや自動仕訳をITACとして評価する記事で、SOC1レポートの読み方はSOC1レポートの読み方の記事で、それぞれ詳しく扱います。
SaaSで経理を回していても、ITGCは要らなくなりません。プログラムの開発と変更、サーバーやデータベースの管理はベンダーの側に移りますが、誰にどのIDと権限を渡すかというアクセス管理、承認経路や自動仕訳のルールといった設定の変更管理、連携エラーやデータの退避を見る運用管理、そしてベンダー自体を評価する委託先の管理が自社に残ります。日本公認会計士協会の実務ガイダンスでも、クラウドサービスは委託業務に該当するとされ、リスクを考えずに簡易な市販ソフトとして評価しないよう注意されています。記録は始めた日からしか残らないため、文書を整えるより先に、IDと権限の一覧づくりと設定変更の申請を動かし始めることを勧めます。
この記事の要約
要点を1枚にまとめると、次の図のとおりです。
SaaSを使ってもITGCは残り、中身が入れ替わる
ITGCは、財務報告に係る内部統制の基準では「ITに係る全般統制」と呼ばれます。システムに組み込まれた個々のチェック（承認が終わらないと次へ進まない、金額を自動で集計するなど）が、勝手に変えられたり止まったりせずに動き続けるための土台の管理を指します。自社でプログラムを書かない会社でも、この土台は必要です。SaaSの承認機能や自動仕訳のルールも、誰かが設定を変えれば挙動が変わるからです。
オンプレミス（自社でサーバーを持つ形）とSaaSを比べると、ITGCの対象は消えるのではなく、自社とベンダーの間で分かれ直します。プログラムの開発や変更、サーバーやデータベースの管理、データセンターへの入館管理は、ベンダーの側に移ります。一方で、利用者のIDをいつ誰に発行し、退職したらいつ止めるか、承認経路や自動登録ルールを誰が変えてよいか、といった判断はベンダーには代わってもらえません。契約しているのは自社で、誰が経理担当かを知っているのも自社だけです。
次の表は、実施基準が挙げる4つの具体例に沿って、筆者がオンプレミスとSaaSを並べて整理したものです。どちらの列にも、自社の欄が空になる行はありません。
| ITGCの具体例（実施基準） | 自社でサーバーとプログラムを持つ場合 | SaaSで回す場合に自社に残るもの |
|---|---|---|
| システムの開発・保守（変更管理） | プログラムの変更、テスト、本番への反映の管理 | 承認経路、自動登録ルール、権限セット、連携の設定を変えるときの申請・承認・記録。自社で書いた連携スクリプトがあればその変更管理 |
| システムの運用・管理 | ジョブの実行、バックアップ、障害対応 | 連携エラーの監視と再送、データとログの定期的な退避、障害時の業務手順 |
| アクセス管理などの安全性の確保 | OS、データベース、ネットワーク、アプリケーションのすべての層 | アプリケーションの利用者ID、権限、管理者の数、二要素認証やSSOの設定、APIキー |
| 外部委託に関する契約の管理 | 保守ベンダーとの契約 | SaaSベンダーの契約と保証報告書（SOC1レポート）の入手と評価 |
表の右の列は、基準のどこから出てくるのでしょうか。次の節から、根拠を1つずつ見ていきます。
実施基準はITGCを定義し、4つの具体例を挙げている
金融庁が公表している「財務報告に係る内部統制の評価及び監査に関する実施基準」（以下、実施基準。直近の改訂は2023年4月7日）は、ITGCを「業務処理統制が有効に機能する環境を保証するための統制活動」で、「通常、複数の業務処理統制に関係する方針と手続」と定義しています（実施基準 I.2(6)②ロa）。業務処理統制（実務でいうITAC）は、承認された取引がすべて正確に処理・記録されるように業務の流れへ組み込まれた統制です。ITGCは、その業務処理統制を下から支える関係にあります。
実施基準は同じ箇所で、ITGCの具体例として次の4つを挙げています。
- システムの開発、保守に係る管理
- システムの運用・管理
- 内外からのアクセス管理などシステムの安全性の確保
- 外部委託に関する契約の管理
4つ目の「外部委託に関する契約の管理」が、SaaSの会社にとっては大きな意味を持ちます。2023年の改訂では、基準と実施基準の「ITへの対応」に、ITの委託業務に係る統制の重要性が増していること、サイバーリスクの高まりなどを踏まえて情報システムのセキュリティの確保が重要であることが書き加えられました（意見書 二(1)②）。実施基準の本文には、クラウドやリモートアクセスなどの技術を使うにあたってセキュリティの確保が重要だと明記されています。委託先の統制とセキュリティの確保という2点は、SaaSだけで経理を回す会社にとってそのまま自社の話です。
市販のソフトを買って使う会社でもITGCの評価単位があることは、実施基準自身が例で示しています。自社開発の販売・購買・物流のシステムをシステム部が管理し、会計システムは経理部が市販のパッケージ・ソフトウェアを導入・管理している場合、評価単位を「システム部」と「経理部」の2つとして識別する、という例です（実施基準 II.3(3)⑤ハ）。経理部が自分でソフトを入れて管理しているなら、経理部がITGCの単位になります。SaaSを経理部や管理部が契約して設定している場合も、同じように考えるのが自然だと筆者は見ています。
監査人向けの箇所には、さらに踏み込んだ一文があります。販売されているパッケージ・ソフトウェアをそのまま利用するような比較的簡易なシステムの企業では、「ＩＴに係る全般統制に重点を置く必要があることに留意する」とされています（実施基準 III.4(2)②ロ）。システムが簡単だからITGCを軽く見てよい、とは書かれていません。
監査人は「4つの層」と「3つのプロセス」でITGCを見る
経営者の評価とは別に、財務諸表の監査をする監査人は、日本公認会計士協会の監査基準報告書315「重要な虚偽表示リスクの識別と評価」に沿ってITGCを見ます。315はITGCを「ＩＴ環境の継続的かつ適切な運用を支援する企業のＩＴプロセスに係る内部統制」と定義し、ITプロセスを、アクセスの管理、プログラムやIT環境の変更の管理、IT業務の管理の3つとしています（第11項）。上場準備のショートレビューや財務諸表監査で渡されるITの質問票も、筆者がこれまで見てきたものの多くは、この3つのプロセスに沿って作られています。
315の付録6は、ITGCを層とプロセスの2つの軸で整理しています。
| 軸 | 中身（付録6を筆者が要約） | SaaSの場合に主に担う側（筆者の整理） |
|---|---|---|
| 層 アプリケーション | アプリケーションの機能と、技術上許されたアクセス経路に応じたもの | 自社（設定と利用者の管理）とベンダー（プログラム） |
| 層 データベース | 直接アクセスやスクリプトによる、データの未承認の更新 | ベンダー |
| 層 オペレーティング・システム | 管理者権限でのアクセス | ベンダー |
| 層 ネットワーク | ネットワークの分割、リモートアクセス、認証 | ベンダー（自社の端末と回線は自社） |
| プロセス アクセス管理 | 認証、権限の付与、プロビジョニング（新規付与と変更の承認）、デプロビジョニング（退職・異動時の削除）、特権アクセス、利用者アクセスレビュー、セキュリティの環境設定、物理的アクセス | 利用者の部分は自社 |
| プロセス 変更管理 | 変更管理、本番環境への移行に関する職務の分離、システムの開発・取得・導入、データコンバージョン | プログラムはベンダー、設定と導入時のデータ移行は自社 |
| プロセス IT業務の管理 | ジョブのスケジューリングと監視、バックアップと復旧、侵入の検出 | 主にベンダー、連携の監視は自社 |
中身の列は付録6の記述を筆者が短くしたもので、右の列は筆者の整理です。付録6そのものには、自社とベンダーの分担は書かれていません。読み取ってほしいのは、SaaSを使うと下の層（データベース、OS、ネットワーク）の管理はほぼベンダーの側に移り、自社が直接手を入れられるのはアプリケーションの層、とくにアクセス管理と設定だという点です。315の付録5は、ITアプリケーションとデータベースに関連するITGCのほうが、OSやネットワークに関連するものよりも多く識別される可能性が高いとしています。SaaSではデータベースの管理もベンダーの側にあるため、その部分はベンダーの保証報告書で確かめることになります。自社とベンダーの両方にかかわる点として、付録5は、監査人がエンドユーザーと企業のIT担当者またはITサービスプロバイダの双方の活動に対する統制を考慮すると書いています（付録5 第22項）。
付録6の後半には、アプリケーションの複雑さごとにどのITGCが当てはまるかを示した例の表があります。「複雑ではない市販ソフトウェア」の列を見ると、アプリケーションのプログラム変更は「無」とされ、ソースコードがインストールされていないことを確かめる程度で済む扱いです。一方で、利用者アクセスの新規追加と変更の承認、退職・異動した利用者のアクセスの削除、アクセス権の定期的なレビュー、管理者権限の制限、利用者ごとのIDとパスワードによる認証は、どの列でも「有」です。ただし複雑ではない市販ソフトの列では、新規付与・削除の承認と定期的なレビューは互いに代替できるとされ、管理者権限の制限はアプリケーションの層だけ、認証もパスワードのみで足りる扱いです。後で見るとおり、SaaSを簡易な市販ソフトと同じように扱ってよいわけではありません。それでも、プログラムを持たない会社でもアクセス管理は外れない、という点はこの表から読み取れます。
同じ表は、アプリケーションの変更のリスクの例として、プログラムだけでなく「調整可能な設定、自動アルゴリズム、自動計算及び自動データ抽出」への不適切な変更も挙げています。複雑ではない市販ソフトの列ではこの行は「無」とされていますが、SaaSの承認経路や自動登録ルールのように設定で統制の挙動が変わる場合に、設定の変更を管理の対象にする考え方は、後の節で見る経済産業省の追補版や315実務ガイダンスQ27に示されています。
クラウドも委託業務にあたり、リスクを見ずに簡易なソフトとして評価しない
SaaSの会社にとって最も直接の根拠になるのが、日本公認会計士協会の監査基準報告書315実務ガイダンス第1号です。IT委員会実務指針第6号やIT委員会研究報告第46号・第53号は2022年10月13日付で廃止されていて、いまITの監査上の扱いを確かめるときに参照するのはこのガイダンスです。古い解説記事はまだ旧指針を引いていることが多いので、読むときは日付を確かめてください。
ガイダンスのQ30は、委託業務に関する内部統制を評価するときの留意点として、「クラウド会計システム等のクラウドサービスも委託業務に該当します」と書いています。続けて、自社保有との違いとそれによるリスクを考えずに「市販の簡易なパッケージ・ソフトウェア」として評価することがないよう、クラウドサービス利用のリスクを検討することが重要だとしています。例として挙がっているのは、システムの管理者権限をクラウド業者が持つ場合に、不適切なアクセスのリスクに対するITGCをどう理解し評価するか、そしてデータのバックアップ体制が契約の内容で十分にリスク対応されているか、の2点です。
Q30は、財務諸表の監査人が監査基準報告書402に沿って評価するという文脈で書かれています。経営者の評価については、実施基準が、委託業務に関しては委託者が責任を有しており、委託業務が企業の重要な業務プロセスの一部を構成している場合には、受託会社の業務に関する内部統制の有効性を評価しなければならないとしています（実施基準 II.2(1)②）。会計や経費精算のSaaSをこの委託業務として評価するか、ITGCの「外部委託に関する契約の管理」の中で扱うかは、使い方と重要性によって変わり、監査法人と協議して決める論点です。その場合の評価の方法としては、委託業務の結果の一部を自社で検証するサンプリングと、受託会社から内部統制の評価結果を記載した報告書を入手して利用する方法の2つが挙がっています。SaaSの場合、ベンダーのサーバーに出向いて確かめることは現実的ではありません。ガイダンスのQ30も、クラウド業者への往査は他の利用者への守秘義務の関係で制限されることが多いとして、タイプ2の報告書（期間を通じた運用状況まで保証したもの。実務ではSOC1 Type2レポートと呼ばれることが多い）の入手を挙げています。
ここで押さえておきたいのが、報告書を入手すれば終わりではない、という点です。監査基準報告書402は、ベンダー（基準上は「受託会社」）がサービスを設計するときに、利用会社（基準上は「委託会社」）の側で整備されると想定している統制を「委託会社の相補的な内部統制」と呼んでいます（第7項）。実務でCUECと呼ばれるものです。監査人は、報告書に書かれた相補的な内部統制が自社に当てはまるかを判断し、当てはまるなら自社がそれを設計して運用しているかを確かめます（第13項・第16項）。ベンダーの報告書は、自社側の統制が動いていることを前提にして初めて使えます。
ベンダー側と自社側の分担を図にすると、次のようになります。
報告書のどこを読み、対象期間のずれや対象外のサービスをどう扱うかは、SOC1レポートの読み方の記事で詳しく扱います。この記事では、委託先の管理が自社のITGCの一部として残る、という点だけ持ち帰ってください。
4つの具体例に沿って、ベンダーと自社で分け持つ
ここまでの根拠を、実施基準の4つの具体例に沿って整理し直します。次の表は、freeeやバクラクのような会計・経費・請求のSaaSを使う会社を想定した、筆者の整理です。基準がこの分け方を定めているわけではありません。実際の範囲は、使っている機能と監査法人との協議で決まります。
| 領域 | ベンダーの側（保証報告書で確かめる） | 自社に残るもの |
|---|---|---|
| アクセス管理 | データセンター、OS、データベースへのアクセス、ベンダー社員の特権アクセス | 利用者IDの発行・変更・削除、権限セットの設計、管理者権限を持つ人の絞り込み、定期的な棚卸、二要素認証・SSO・IPアドレス制限の設定、APIキーと連携用ユーザーの管理 |
| 設定の変更管理 | プログラムそのものの変更、リリース前のテスト | 承認経路、自動登録ルール、勘定科目や税区分の対応づけ、連携設定、権限セット、締めの解除を変えるときの申請・承認・記録 |
| 運用管理 | サーバーの運用、バックアップ、障害対応 | 連携エラーの監視と再送、データとログの定期的な退避、障害時に手作業へ切り替える手順、ベンダーのリリース情報の確認 |
| 委託先管理 | 受託業務の統制を保証報告書にまとめて提供 | 契約と利用規約の確認、保証報告書の入手と評価、相補的な内部統制への対応 |
筆者の見るところ、4つの領域のうち自社の負担が最も大きいのはアクセス管理です。SaaSは誰でもすぐに招待でき、権限もボタン1つで変えられます。その手軽さが、統制の上では弱点になります。経理担当が管理者権限を持っていれば、自分の権限を広げ、承認経路を外し、締めた月を開け直すことが1人でできてしまいます。
運用管理は、オンプレミスと比べて自社の範囲が比較的小さくなる領域です。ただし、SaaS同士やSaaSと銀行をつなぐ連携は、自社の側の運用です。連携が止まったことに誰も気づかなければ、計上漏れが月末まで見つかりません。また、SaaSの操作ログの保存期間や取り出し方はサービスとプランによって違うため、必要なログを自社で定期的に退避しておく運用も残ります。
プログラム変更管理の代わりに、設定の変更管理と委託先管理が主役になる
自社でシステムを開発する会社では、ITGCの中心はプログラムの変更管理です。変更を申請し、テストし、作った人とは別の人が本番に反映します。この手続きがあるから、システムに組み込んだチェックが勝手に変わっていないと言えます。SaaSでは、この役割をベンダーが担います。代わりに自社の側で主役になるのが、設定の変更管理と委託先の管理です。
経済産業省の「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（2024年12月25日改訂、以下 追補版）は、この点をはっきり書いています。オンプレミスにせよクラウドサービスを利用するにせよ、パッケージソフトウェアを調達する場合には「購入したままの状態では十分な統制が実現できないことに注意する」としたうえで、例として、不正なデータ改ざんを防ぐためのアカウント管理や権限の設定、自動で起票される自動仕訳の設定、仕訳の承認者の設定、セグメント別開示に関わる組織の設定、他システムからのデータ連携の設定を挙げています（第IV章 3.(1)①）。ソフトウェアに正しい設定を行わなければ、十分な統制が存在することにならない、という書き方です。追補版は、変更管理の評価手続の例でも、財務報告に重要な影響を及ぼすパラメータ（設定値）の変更を含む本番環境のすべての変更を、変更管理の手続に従って管理することが望まれるとしています。
315実務ガイダンスのQ27も、市販の簡易なパッケージ・ソフトウェアを使う会社について、監査人はソフトが統制機能を持っているかだけでなく、企業がその機能を実際に使っているか、初期設定項目（パラメータ）の設定・維持などに必要な統制を整備して運用しているかに留意する、と書いています。ソフトの側が、経理の経験が乏しい担当者の「使い勝手をよくする」ために統制機能を省いていたり、動作を止めていたりすることがある、という指摘もあります。SaaSも、機能があることと、それを使っていることは別です。
freeeの例で、設定がそのまま統制になる箇所を1つ見ておきます。freee会計の仕訳承認フロー（アドバンス以上で利用可能。2026年10月時点の公式ヘルプ）では、仕訳を作った人が申請経路の承認者に入っていると、その仕訳は作成時点で「承認済み」になります。これを「申請中」で止める自己承認の設定は、エンタープライズにしかありません。freeeのAPIで取引を直接作る連携サービスでも、連携の利用を許可した人が承認者なら「承認済み」、承認者でなければ「申請中」で入ります。また、管理者権限のメンバーは、申請経路に入っていなくても代理で承認できます。誰を承認者にし、誰に管理者権限を渡し、どのユーザーで連携を許可するかという設定1つで、承認の仕組みが素通りになりえます。こうした設定が、いつ、誰の承認で変わったかを残すのが、SaaSでの変更管理です。設定に組み込まれた統制そのものをどう評価するかは、承認フローや自動仕訳をITACとして評価する記事で扱います。
委託先の管理が主役になるのは、プログラムの変更管理をベンダーに任せたからです。任せた以上、ベンダーがそれをきちんと行っているかを、自社は報告書で確かめるしかありません。追補版も、特定の業務を多数の企業から請け負うクラウドサービスでは、委託先の内部統制が「ブラックボックス」になりやすく、監査権の獲得か保証報告書の入手によって内部統制の状況を確認することが重要だとしています（第IV章 3.(4)）。
ITGCの中心がどう入れ替わるかを、図と表で並べます。
| 自社で開発する会社のITGCの中心 | SaaSで回す会社のITGCの中心 |
|---|---|
| プログラム変更の申請、テスト、本番反映の職務分離 | 設定変更の申請、承認、変更前後の記録 |
| サーバーやデータベースの特権IDの管理 | SaaSの管理者権限と連携用ユーザーの管理 |
| データセンターの運用 | ベンダーの保証報告書の入手と評価、相補的な内部統制への対応 |
現場でよく指摘される6つのこと
基準の話を、現場で起きていることに置き換えます。次の6つは、SaaSで経理を回している会社で筆者がよく目にする状態です。どれも、監査法人のショートレビューや質問票で問われやすい箇所です。件数や頻度を示す統計があるわけではなく、実務での相場観として読んでください。
| よくある状態 | なぜ問題になるか | 手当ての例 |
|---|---|---|
| 1つのIDを複数人で使っている | 誰が操作したかを特定できません。315実務ガイダンスQ27も、共有アカウントではユーザーが特定できない場合があると注意しています | 1人1IDにします。人数で費用が増えるなら、閲覧だけの人や申請だけの人に安い権限を当てます |
| 退職者のIDが残っている。異動後も前の権限が残っている | 退職者や異動者が、権限のないまま操作できる状態になります。追補版は、退職者のサンプルを取ってアクセス権がすぐに削除されたかを確かめる手続を例示しています | 人事の退職連絡を起点に、全SaaSのIDを止める手順と記録を作ります |
| 経理担当が管理者権限も持っている | 自分の権限を広げる、承認経路を外す、締めを解除するといったことを1人でできてしまいます | 管理者は最少の人数にし、日々の経理実務を担う人とは分けます。分けられないなら、権限変更の記録を別の人が定期的に見ます |
| 承認経路や自動仕訳のルールを、記録なく変えている | 承認や自動仕訳が、いつから意図どおりに動いていないかを後から説明できません | 変更は申請と承認を経て行い、変更前後の画面を保存します |
| SOC1レポートを入手していない。入手しても読んでいない | ベンダーの側の統制について、経営者も監査人も根拠を持てません | 使っているSaaSごとに報告書の有無と入手窓口を確かめ、年に1回入手して読みます |
| 社内のエンジニアが、連携スクリプトを1人で作って1人で本番に入れている | 自社で書いたプログラムには、ベンダーの保証が及びません。変更の職務分離がない状態になります | ソースコードをバージョン管理し、変更のレビューと本番反映を別の人が担います |
6つ目は見落とされやすい項目です。会計そのものはSaaSでも、SaaS同士をつなぐスクリプトや、銀行のデータを加工して取り込むプログラムを社内で書いていれば、その部分は自社開発です。付録6の言う変更管理のプロセスが、そのまま自社に戻ってきます。最近は、AIエージェントにSaaSのAPIを触らせて起票や照合を任せる会社も出てきました。AIが使うIDや指示文の変更も、同じ考え方で管理の対象に入れておく必要があります。AIエージェントの権限と承認の設計は、AIエージェントの権限・承認・停止・記録の記事にまとめています。
4つ目の「記録なく変えている」は、悪意がない場合がほとんどです。たとえば、月末に承認が滞って急ぎで承認者を差し替えた、新しい取引先が増えたので自動登録ルールを1本足した、といった変更です。どれも業務を回すための判断ですが、後から「この3か月、なぜこの仕訳は承認を経ずに入っているのか」と聞かれたとき、答えられる記録がありません。設定を変えること自体を止める必要はなく、変えたことが残っていればよい、と考えると始めやすくなります。
入社から退職まで、アクセス管理を1本の流れにする
アクセス管理は、人の入社から退職までの流れに沿って決めごとを置くと漏れが減ります。315の付録6が挙げる、プロビジョニング（新規付与と変更の承認）、デプロビジョニング（退職・異動時の削除）、特権アクセス、利用者アクセスレビューは、この流れの上にそのまま並びます。
| 場面 | 決めておくこと | 残す記録 |
|---|---|---|
| 入社 | 誰が申請し誰が承認するか。権限セットは職務分掌から決めます | 申請と承認の記録、付与した権限 |
| 異動 | 新しい権限を足すだけでなく、前の権限を外します | 変更の申請と承認の記録 |
| 定期的な棚卸 | 全SaaSのIDと権限の一覧を出し、上長が要否を確かめます。頻度は四半期に1回を筆者は勧めます | 一覧と確認した人・日付、直した内容 |
| 退職 | 人事の退職連絡を起点に、最終出社日までにIDを止めます | 停止した日と、退職日との差 |
| 管理者権限 | 管理者を最少の人数にし、付与と変更を別に承認します | 管理者の一覧と付与理由 |
| 連携用ユーザー・APIキー | 誰の名前で連携を許可しているか、有効期限、権限の範囲 | 連携とキーの台帳 |
SaaSならではの注意点もあります。freee会計では、メンバーを削除する前に、そのメンバーが申請者になっている差し戻し中のワークフローを片づけておく必要があります。2026年10月時点の公式ヘルプによると、申請者が削除されると、差し戻し中の経費精算や支払依頼などは他のメンバーが修正・再申請できなくなるためです。退職の手順に「IDを止める前に、本人の申請中・差し戻し中の案件を引き継ぐ」を1行入れておくと、止めるのをためらって退職者のIDが残る、という状態を避けられます。
SSO（1つのIDで複数のSaaSにログインする仕組み）を入れている会社では、認証と退職時の無効化をSSOの側でまとめて管理できます。それでも、各SaaSの中でどの権限を渡しているかの付与と棚卸は、サービスごとに残ります。SSOを通らない直接ログインやAPIキーが残っていないかも、棚卸のたびに確かめてください。権限の一覧を作るときの考え方は、データの扱いを決める記事の権限とログの項目、権限表の書き方は引き継ぎの記事も参考になります。
freeeのプランで、使える統制機能が変わる（2026年10月時点）
SaaSの統制機能は、契約プランで決まります。統制の設計を始める前に、まず自社のプランを確かめてください。freee会計の法人向けプランは、ひとり法人、スターター、スタンダード、アドバンス、エンタープライズの5つです（2024年7月以降の新プラン）。次の表は、2026年10月時点の公式ヘルプ（プラン別機能表は2026年9月29日更新）から、ITGCに関係する機能を抜き出したものです。
| 機能 | 使えるプラン（法人・新プラン） |
|---|---|
| カスタム権限（権限セットの中身を変える） | スタンダード以上 |
| 本締め（全員が締めた期間を編集できなくなる） | スタンダード以上 |
| 仮締め（管理者と月締めの権限者以外が編集できなくなる） | アドバンス以上 |
| 仕訳承認フロー、承認済みの仕訳の編集可否の設定 | アドバンス以上 |
| プラン限定アプリ（高度なワークフロー、高度な消込、受取請求書管理、高度な法人カード連携などの連携アプリ） | アドバンス以上 |
| 二要素認証の設定 | 全プラン |
| 二要素認証の必須化、IPアドレス制限 | エンタープライズのみ |
| 自己承認の可否の設定 | エンタープライズのみ |
| イベントログ、仕訳の承認・変更履歴、ユーザーの権限の変更履歴、ユーザー情報の更新履歴 | エンタープライズのみ |
| 優良電子帳簿に伴う操作履歴 | 全プラン（優良電子帳簿の設定を「使用する」にした時点から記録） |
| ログイン履歴 | エンタープライズ以外は最新20件のみ閲覧 |
| SOC対応 | プラン別機能表では、エンタープライズの「IPO・IPO準備企業向け機能」に掲載 |
この表から言えることは2つあります。1つ目は、アクセス管理と変更管理の証跡になる機能、つまりユーザーの権限の変更履歴、仕訳の承認と変更の履歴を確認する画面、イベントログが、エンタープライズに集まっていることです。優良電子帳簿に伴う操作履歴は全プランで使えますが、優良電子帳簿の設定を「使用する」にした時点からしか記録されず、遡っては残らないため、期首に設定を入れておく必要があります。また、アドバンス以下では誰がいつ権限を変えたかを機能表上の履歴として出せないため、申請書と棚卸の記録で代わりに示すことになります。
2つ目は、高度な連携を行うプラン限定アプリがアドバンス以上でしか使えないことです。freeeのヘルプのプラン限定アプリ一覧（2025年6月現在）には「バクラク債権・債務管理 × freee連携アプリ」が載っており、法人カード連携は明細の同期だけならプランを問わず使えるという例外もあります。LayerXは2024年3月の発表で、スタンダード以下のプランではバクラクの連携アプリが使えなくなるとし、CSV連携機能を用意する方針を示しました。いまどのサービスがどのプランで連携できるかは、両社の最新のヘルプで確かめてください。CSVで連携するなら、出力と取り込みの件数・金額を突き合わせる手順を統制として置く必要が出てきます。
なお、freeeのSOC1報告書は、公式ヘルプでは担当営業かプロダクト内のサポートに依頼して入手する案内になっています。2019年にfreee会計のSOC1 Type2報告書の受領を公表した際は、報告書を利用できる対象として「エンタープライズプランユーザー」が挙げられていました。エンタープライズ以外のプランを使っている場合は、報告書を入手できるか、報告書が自社の利用環境を対象にしているかを担当営業に確かめてください。バクラクは、公式のセキュリティページで二要素認証、シングルサインオン、IPアドレス制限を利用者向けの機能として挙げ、SOC1 Type2報告書を取得していると公表しています（2026年10月時点）。発表によると、2025年3月27日発行の報告書（基準期間は2024年7月1日から12月31日）は、バクラク勤怠とバクラク債権管理を対象から除いています。報告書の種類や準拠した基準は、入手した報告書そのもので確かめる必要があります（SOC1レポートの読み方の記事）。どのサービスが最新の報告書の対象に入っているかも、毎年見直してください。
プランを上げるかどうかは、費用と、手作業でどこまで代わりを組めるかの比較で決まります。証跡の機能がエンタープライズに集まっているため、上場準備に入るとエンタープライズを検討する会社が多いと筆者は見ています。ただし、プランを上げれば監査が通るわけではありません。どの機能で何のリスクを抑えるかを決め、監査法人と協議したうえで判断してください。
筆者たちが最初に読み違えていたこと
この記事は、書き上げたあとに一次資料を取り直し、誤りがある前提で読み直しています。そこで直した点のうち、読者がつまずきそうなものを5つ残します。
前の「現場でよく指摘される6つのこと」が会社の状態の話だとすると、こちらは基準と製品仕様の読み方の話です。左の列は直す前の筆者たちの理解で、右の列は原文で確かめ直した内容です。
| 筆者たちが最初に考えていたこと | 実際は | 根拠 |
|---|---|---|
| 「クラウドは委託業務だと基準に書いてあり、経営者の評価でもそのまま委託業務になる」 | そう書いているのは監査人向けの実務ガイダンスで、基準ではありません。経営者が受託会社の統制まで評価しなければならないのは、委託業務が重要な業務プロセスの一部を構成している場合です。SaaSをこの委託業務として扱うかは監査法人と協議します | 315実務ガイダンス第1号 Q30、実施基準 II.2(1)②イ |
| 「実施基準の4項目が、ITGCの定義であり、漏れのない区分になっている」 | 定義は「業務処理統制が有効に機能する環境を保証するための統制活動」で、4項目は具体例です | 実施基準 I.2(6)②〔ITの統制〕ロa |
| 「315付録6の表では、簡易な市販ソフトでもアクセス管理の各項目がすべて必須で、同じ表のアプリケーションの変更の行が、SaaSの設定の変更管理の根拠になる」 | 「複雑ではない市販ソフトウェア」の列では、付与・削除の承認と定期的なレビューは互いに代替でき、アプリケーションの変更の行は「無」です。設定の変更管理の根拠は、追補版とQ27に置きます | 監査基準報告書315 付録6、追補版 第IV章3.(1)①、315実務ガイダンス第1号 Q27 |
| 「エンタープライズにすれば、承認者が起票した仕訳も申請中で止まる」 | エンタープライズでも、作成者が承認者なら承認済みになるのが原則です。自己承認機能を「使用しない」に設定すると、申請中で止まります | freeeヘルプ「仕訳承認フロー」（2026年7月27日更新）の本文と※2 |
| 「仕訳の変更の証跡になる機能は、エンタープライズに集まっている」とだけ書き、アドバンス以下の履歴を見落としていた | 仕訳の承認・変更履歴の確認画面はエンタープライズのみですが、優良電子帳簿に伴う操作履歴は全プランで使えます。ただし優良電子帳簿の設定を「使用する」にした時点からしか記録されず、遡っては残りません | freeeヘルプ プラン別機能表（2026年9月29日更新）、同「優良電子帳簿について」（2026年6月26日更新） |
基準なら誰に向けた文書か、条件が付いていないか。製品なら既定の挙動か、設定してはじめてそうなるのか。この2点を確かめるだけで、表のような読み違いの多くは防げます。監査法人との協議の前に、自社の資料の根拠欄を一度原文に当て直しておくことを勧めます。
明日からやること
ITGCの整備でいちばん取り返しがつかないのは、記録の空白です。統制がきちんと動いていたかを示すには、評価の対象になる期間の記録が要ります。規程や業務記述書は後からでも書けますが、半年前にIDを誰の承認で発行したかは、そのとき残していなければ後から作れません。だから、文書を整えるより先に、記録が残る仕組みを動かし始めることを勧めます。
経理業務をSaaSとAIで組み替える進め方は、経理業務をFDE方式で本番化した記事に書きました。そこで作った仕組みにITGCを重ねるときも、最初の一歩は同じです。明日から始められることを、手間の小さい順に並べます。
- 使っているSaaSを、会計に関係するものからすべて書き出します。会計、経費精算、請求書の受け取りと発行、法人カード、銀行、給与、売上の出発点になるシステム、連携スクリプトまで含め、それぞれの契約プランとSOC1レポートの有無を書き添えます
- SaaSごとに、IDと権限の一覧を出します。管理者権限を持つ人、退職者や異動者のID、共有されているID、連携に使っているユーザーとAPIキーに印を付けます。見つかった退職者のIDは、その日に止めて、止めた日を記録します
- 管理者権限を持つ人を減らします。日々の経理実務を担う人と、権限や設定を変える人を分けます。小さな組織で分けられないなら、権限と設定の変更を別の人が月に1回見ることにします
- 承認経路、自動登録ルール、権限セット、連携設定を変えるときの申請を始めます。最初は共有の表に「日付、何を、なぜ、誰が承認したか、変更前後の画面」を1行ずつ残すだけで構いません
- 使っているSaaSのベンダーに、SOC1レポートの入手方法と最新の対象期間を問い合わせます
5つを1枚にまとめると、次のとおりです。
どれも、新しいツールや大きな予算を必要としません。監査法人との協議で評価の範囲や方法が固まってから手を付けたくなりますが、範囲が決まったときに、評価の対象期間の記録がなければ説明できません。上場準備のどの期の記録が評価に使われるかは、IPO準備のJ-SOXロードマップの記事で扱います。範囲がどう決まっても無駄にならない、IDと権限、設定変更の記録から始めてください。
はてなベースには公認会計士とエンジニアがいて、freeeなどの会計SaaSの導入支援を行っています。自社の環境で何が残るのかを整理したいときは、ご相談ください。
IT統制・J-SOX対応の進め方をご相談ください
使っているSaaSの洗い出し、IDと権限・設定変更の記録の始め方、SOC1レポートの読み込み、監査法人との協議に出す案づくりまで、公認会計士とエンジニアが一緒に整理します。