決算発表の 2 週間前。連結精算表のレビューをしていた経理課長が、ある数字に違和感を覚えました。貸倒引当金の繰入額が、前年より不自然に小さいのです。担当者と一緒に計算用の Excel ファイルをたどると、原因が見つかりました。今期から債権の年齢区分を 1 行増やしたのに、合計欄の SUM 関数の範囲が以前のまま。追加した行が集計から漏れていたのです。
幸い、期末の調整で数字は修正できました。しかし内部監査部門の担当者は考え込みました。このファイルは毎期使われ、財務諸表に直接つながる数字を計算しています。それなのに J-SOX の RCM（リスク・コントロール・マトリクス）には「経理課長が引当金計算をレビューする」とだけあり、ファイルそのものは誰の管理下にもありませんでした（本記事の事例はすべて架空のモデルケースです）。
表計算ソフトは、決算の現場に欠かせない道具です。そして、その便利さゆえに、統制の網からこぼれやすい存在でもあります。この記事では、スプレッドシートを中心とする EUC（エンドユーザーコンピューティング）のリスクと、J-SOX での評価の進め方を整理します。
この記事の要点
- 利用者自らが作り運用するスプレッドシートは EUC と呼ばれ、決算・財務報告プロセスでは特に評価が重要になる場合があります
- 日本公認会計士協会の内基報 1 号は、計算式等の検証、検証が不十分な場合の代替手段、アクセス制御・変更管理・バックアップの 3 点の検討を求めています
- EUC は IT 全般統制の対象システムから外れがちで、「自動計算だから正しい」という前提が成り立ちません
- まず EUC 台帳で重要なファイルを特定し、重要度に応じて統制の深さを変えるのが実務的です
- レビュー統制に頼る場合は、レビューが計算の誤りを発見できる精度を持っているかを確かめます
EUC とは何か、なぜリスクになるのか
基準での位置付け
EUC（End User Computing）とは、情報システム部門ではなく、業務の利用者自らがアプリケーションやツールを作り、運用することをいいます。典型はスプレッドシートですが、利用者が作ったデータベースソフトのファイル、マクロ、BI ツールの集計定義なども含めて考えるのが一般的です。
日本公認会計士協会の財務報告内部統制監査基準報告書第 1 号（内基報 1 号、旧・監査・保証実務委員会報告第 82 号）は、決算・財務報告プロセスでは決算処理や連結財務諸表の作成を通じて表計算ソフト（スプレッドシート）が広く利用されていると述べています。そのうえで、利用者自らが業務システムを構築し運用に直接携わる EUC の観点からのリスク評価が重要になり、その統制の有効性を評価する監査手続が特に重要になる場合があるとしています。
基準が求める 3 つの検討事項
内基報 1 号は、スプレッドシートについて次の 3 点を検討することが重要だとしています。1 つ目は、スプレッドシートを使って財務報告の基礎資料を作成している場合に、マクロや計算式等を検証していること。2 つ目は、その検証が適切になされていない場合に、手計算で確かめるなどの代替的な手段が採られていること。3 つ目は、スプレッドシートに対するアクセス制御、変更管理、バックアップ等の対応について検証していることです。
この 3 点は、監査人の立場から書かれたものですが、会社側の統制設計の骨格としてもそのまま使えます。本記事の後半では、この 3 点を軸に統制と評価手続を組み立てます。
なぜ EUC は統制からこぼれるのか
基幹システムであれば、プログラムの変更は情報システム部門の変更管理手続を通り、本番環境へのアクセスは権限で制限されます。これらは IT 全般統制（ITGC）として評価されます。ところがスプレッドシートは、誰でも作成でき、誰でも計算式を書き換えられ、変更の履歴も残らないことがあります。IT 全般統制の評価対象として登録されるのは通常、基幹システムやその基盤であり、個々のスプレッドシートは対象から外れていることが多いのです。
その結果、スプレッドシートの計算には「システムの自動計算だから正しい」という前提が成り立ちません。自動化された業務処理統制（ITAC）の評価で、IT 全般統制の有効性を前提にサンプルを減らせるのは、プログラムが勝手に変わらない保証があるからです。スプレッドシートにはその保証がありません。自動統制と IT 全般統制の関係はITACとITGCの違いで詳しく解説しています。
決算のどこに EUC が潜んでいるか
典型的な利用場面
スプレッドシートは、特に見積りや複雑な計算を伴う領域で多用されます。下の表は、決算・財務報告プロセスでよく見られる利用場面とリスクの例です。
| 利用場面 | よくある計算・処理 | 典型的なリスク |
|---|---|---|
| 連結精算表 | 個社数値の合算、連結消去、組替 | 参照先のずれ、消去仕訳の漏れ |
| 引当金の計算 | 貸倒・賞与・製品保証などの見積り | 集計範囲の漏れ、前提値の更新漏れ |
| 固定資産の減損 | 将来キャッシュ・フローの割引計算 | 割引率・成長率の入力誤り、計算式の破損 |
| 税効果会計 | 一時差異の集計、回収可能性の判定 | 税率の更新漏れ、差異の二重計上 |
| 収益認識 | 契約ごとの配分、期間按分 | 手入力の誤り、按分ロジックの誤り |
| 棚卸資産の評価 | 低価法、滞留在庫の評価減 | 基準日データとの不一致、条件式の誤り |
| 開示資料 | 注記の数値集計 | 本表との不整合 |
これらの多くは、決算・財務報告プロセス（FCRP）の中で、会計上の見積りや判断を伴う領域です。見積りの領域は虚偽記載のリスクが高く、スプレッドシートの誤りがそのまま財務諸表の誤りにつながります。
「つながり」がリスクを増幅する
スプレッドシートは単独で使われるとは限りません。基幹システムから出力したデータを加工用のファイルに貼り付け、その結果を別のファイルが参照し、最後に連結精算表に取り込む、という連鎖がよく見られます。連鎖のどこか 1 か所で誤りが起きれば、その誤りは下流のすべてに伝わります。
しかも、下流のファイルだけをレビューしても、上流の誤りは見えないことがあります。EUC のリスク評価では、個々のファイルではなく、データの流れ全体を図にして捉えることが重要です。
EUC 台帳と重要度の判定
まず台帳をつくる
評価の第一歩は、財務報告に関わるスプレッドシートを洗い出し、台帳にまとめることです。経理部門の各担当者に、決算の手順書に沿って「どのファイルを使い、どこから数字を取り込み、どこへ渡しているか」を聞き取ります。共有フォルダの一覧から探すよりも、業務の流れから探すほうが漏れを防げます。
台帳には、ファイル名、保管場所、所有者（責任者）、用途、関係する勘定科目、上流と下流のファイル、マクロの有無、更新頻度を記録します。以下は架空のモデルケースの記入例です。
| ID | ファイル名 | 所有者 | 用途 | 関係科目 | 上流 | 下流 | マクロ | 重要度 |
|---|---|---|---|---|---|---|---|---|
| E-01 | 貸倒引当金計算 | 経理課 A | 年齢区分別の引当額計算 | 貸倒引当金 | 売掛金年齢表（基幹システム出力） | 連結精算表 | なし | 高 |
| E-02 | 連結精算表 | 連結担当 B | 個社数値の合算・消去 | 全科目 | 各社報告パッケージ | 開示資料 | あり | 高 |
| E-03 | 減損判定シート | 経理課 C | 割引キャッシュ・フローの計算 | 固定資産 | 事業計画 | 注記 | なし | 高 |
| E-04 | 部門別経費集計 | 管理課 D | 管理会計用の集計 | なし（管理目的） | 会計システム | 予算資料 | なし | 対象外 |
重要度を判定する基準
すべてのスプレッドシートに同じ統制を求めるのは現実的ではありません。重要度に応じて統制の深さを変えるため、判定の基準を決めておきます。下の表は判定基準の一例です。
| 観点 | 高 | 中 | 低 |
|---|---|---|---|
| 財務諸表への影響 | 金額が重要な科目に直接反映 | 間接的に影響、金額は中程度 | 管理目的のみ |
| 計算の複雑さ | 多段の計算、マクロ、外部参照 | 単純な集計と一部の計算 | 転記・一覧のみ |
| 判断の程度 | 見積り・前提値を含む | 一部に判断を含む | 判断を含まない |
| 利用の頻度と継続性 | 毎期継続して使う | 年数回 | 一度きり |
| 他ファイルとの連鎖 | 上流・下流に複数のファイル | 一部に連鎖 | 単独 |
判定は機械的な点数化だけに頼らず、「このファイルの誤りが、発見されずに財務諸表に反映される可能性はあるか」という観点で最終判断します。重要度が「高」と判定されたファイルは、RCM 上で統制と紐づけて管理します。
統制の設計：3 つの観点で組み立てる
観点 1：計算式とマクロの検証
最初の観点は、ファイルの計算ロジックそのものが正しいことを確かめる統制です。新規作成時や計算式の変更時に、作成者以外の者が計算式を検証し、テストデータで結果を確かめ、その記録を残します。計算式が入ったセルを保護し、入力セルと計算セルを色分けしておくと、意図しない上書きを防ぎやすくなります。
冒頭のモデルケースのような「集計範囲のずれ」は、合計欄の検算（行の合計と列の合計の一致、上流データの件数や金額との一致）を組み込んでおくことで、多くを機械的に検出できます。
観点 2：代替手段としてのレビュー
計算式の検証が十分にできない場合、内基報 1 号は手計算で確かめるなどの代替的な手段を挙げています。実務では、上長や別の担当者が計算結果をレビューする統制がこれに当たります。ただし、レビュー統制には「精度」の問題があります。前期比較で大きな増減がないかを眺めるだけのレビューでは、数%の誤りは見逃されます。
レビューが統制として機能するには、何と比較し、どの程度の差異を調査の対象とし、どう解消したかを記録することが必要です。レビューで使った資料そのもの（監査の用語では「企業が作成した情報」）の正確性と網羅性も確かめる対象になります。
観点 3：アクセス制御・変更管理・バックアップ
3 つ目の観点は、ファイルという「器」の管理です。保管場所をアクセス権のある共有フォルダに限定し、編集できる者を必要最小限にします。変更の履歴が残る仕組み（版管理機能や変更記録シート）を使い、期末に使ったファイルは確定版として保存し、以後は変更できないようにします。バックアップの取得と復元の手順も決めておきます。
とくに見落とされやすいのが、個人のパソコンやメールの添付で回覧されるファイルです。共有フォルダの確定版とは別に、担当者の手元で修正された版が決算に使われると、アクセス制御も版管理も意味を失います。「決算に使ってよいのは、指定の保管場所にある確定版だけ」というルールを明文化し、レビューの際に保管場所を確認することが有効です。
これらは、基幹システムでいう IT 全般統制のアクセス管理・変更管理・運用管理を、スプレッドシートの規模に合わせて当てはめたものです。考え方の詳細は変更管理の監査手順とアクセス管理の監査手順も参考になります。
重要度別の統制の目安
| 統制 | 重要度 高 | 重要度 中 | 重要度 低 |
|---|---|---|---|
| 計算式・マクロの検証（作成・変更時） | 必須（独立した検証者） | 推奨 | 任意 |
| 計算結果のレビュー（毎期） | 必須（比較基準と差異の閾値を明記） | 必須 | 推奨 |
| 検算・突合の組み込み | 必須 | 推奨 | 任意 |
| アクセス制限 | 必須 | 必須 | 推奨 |
| 版管理・確定版の保存 | 必須 | 推奨 | 任意 |
| バックアップ | 必須 | 必須 | 推奨 |
評価手続：整備と運用をどう確かめるか
整備状況の評価
整備状況の評価では、EUC 台帳の網羅性を確かめたうえで、重要度「高」のファイルについて、統制が設計どおりに存在するかを確認します。具体的には、ファイルの保管場所とアクセス権の設定を確認し、計算式の検証記録を閲覧し、計算の一部を評価者自身が再計算します。
再計算は、ファイルの主要な計算を独立に再現できるかを確かめる手続です。すべての計算式を点検するのではなく、財務諸表に反映される最終値に至る主要な経路を選んで検算するのが効率的です。前年度からの計算式の変更点を比較ツールなどで洗い出し、変更箇所を重点的に確認する方法も有効です。
運用状況の評価
運用状況の評価では、期中に計算式の変更があったか、変更があった場合に検証が行われたかを確認します。レビュー統制については、レビューの記録（比較した資料、調査した差異、結論、日付、署名）を閲覧し、差異の調査が実際に行われたかを確かめます。
期末の決算で使うファイルは、評価の時期にも注意が必要です。決算・財務報告プロセスの統制は期末日以降に実施されるものが多く、期中のテストだけでは結論が出せません。前年度の運用状況をふまえて期中に手順を確認し、期末に実施された統制を追加で確かめる計画にしておきます。
不備が見つかったときの考え方
評価の過程で計算式の誤りが見つかった場合、まず確かめるべきは、その誤りが財務諸表の数値に影響したかどうかです。影響があれば、決算の修正の要否を経理部門と検討します。そのうえで、統制の不備として、なぜ誤りが既存の統制（検証やレビュー）で発見されなかったのかを分析します。
誤りの金額が小さくても、同じ設計のファイルが他にもあれば、潜在的な影響は大きくなりえます。不備の重要性は、実際に生じた誤りの金額だけでなく、発生しうる虚偽記載の金額と発生可能性で判断します。評価の手順は内部統制の不備の評価で解説しています。
評価のチェックリスト
- 財務報告に関わるスプレッドシートを業務の流れから洗い出し、台帳にまとめた
- 重要度の判定基準を文書化し、判定結果を記録した
- 重要度「高」のファイルが RCM 上の統制と紐づいている
- 計算式・マクロの検証記録（検証者、日付、テスト結果）がある
- 主要な計算を評価者が再計算し、結果が一致した
- レビュー統制の比較基準と差異の閾値が明記されている
- 保管場所のアクセス権が必要最小限に制限されている
- 期末の確定版が保存され、以後の変更が制限されている
- 上流データ（システム出力）の網羅性と正確性を確かめた
EUC を減らすという選択肢
統制を重ねるより、依存を減らす
重要なスプレッドシートが多いほど、統制と評価の工数は増えていきます。そこで、評価と並行して検討したいのが、EUC への依存そのものを減らすことです。定型的な計算は会計システムや連結システムの標準機能に移し、残るスプレッドシートは例外的な見積りや分析に限定する、という方向です。
システムに移した計算は、IT 全般統制の管理下に入り、自動化された統制として評価できるようになります。実施基準は、IT を利用した統制は一貫した処理を反復継続するため、IT 全般統制の有効性を前提に、手作業の統制よりも運用状況の評価作業を減らせるとしています。移行には費用がかかりますが、毎期の評価工数と誤りのリスクを長期で比較すると、見合うことが少なくありません。
置き換えの優先順位
置き換えの対象は、重要度が高く、計算が定型的で、毎期繰り返し使われるファイルから選ぶのが効率的です。反対に、年に一度の複雑な見積りで、前提が毎期変わるものは、無理にシステム化するよりスプレッドシートのまま統制を厚くするほうが現実的な場合があります。
BI ツールや RPA に置き換える場合も、それらの集計定義やロボットの設定は、利用者部門が作成・変更するなら EUC と同じリスクを抱えます。置き換え先が誰の管理下にあり、変更がどう統制されるかを確かめることを忘れないようにします。
よくある失敗と対策
失敗 1：レビューの押印だけを統制とみなす
「経理課長がレビューし押印する」統制は、押印があれば運用されたとみなされがちです。しかし、何をどう確かめたかの記録がなければ、そのレビューが誤りを発見できる精度を持っていたかは判断できません。比較の基準と差異の閾値を決め、調査の記録を残す様式に改めることが対策です。
失敗 2：上流のシステム出力を検証していない
スプレッドシートの計算がどれだけ正しくても、取り込んだデータが不完全なら結果は誤ります。基幹システムからの出力データについて、件数や合計金額を会計帳簿と突き合わせる手続を組み込みます。データの抽出と突合の方法はデータ分析監査（CAAT）入門も参考になります。
失敗 3：台帳が作りっぱなしになる
EUC 台帳は、作成した年は正確でも、担当者の交代やファイルの追加で翌年には実態と合わなくなります。毎期の決算前に、所有者に台帳の更新を依頼し、新規ファイルと廃止ファイルを確認する手順を年間計画に組み込みます。
失敗 4：属人化したマクロを放置する
作成者が退職し、中身を誰も説明できないマクロが決算に使われ続けるケースがあります。重要なマクロについては、処理内容の説明書を作成し、後任者が検証できる状態にしておきます。長期的には、システム化や標準的なツールへの置き換えを検討します。
よくある質問
スプレッドシートの計算は、自動化された統制（ITAC）として扱えますか？
スプレッドシートの計算式は自動で処理されますが、利用者が自由に変更でき、IT 全般統制の対象になっていないことが多いため、基幹システムの自動化された統制と同じ前提（IT 全般統制が有効ならサンプルを減らせる）を当てはめるのは難しいのが一般的です。ファイルの変更管理とアクセス制御が有効に機能していることを確かめたうえで、扱いを監査人と協議してください。
クラウド型の表計算サービスでも同じ考え方でよいですか？
基本的な考え方は同じです。クラウド型のサービスでは版の履歴や共有設定の管理機能が使える場合が多く、変更管理やアクセス制御の証跡を取りやすいことがあります。一方で、共有リンクの設定次第で社外からアクセスできる状態になるなど、固有のリスクもあるため、共有設定の確認を統制に含めます。
重要度の低いファイルまで統制を整える必要がありますか？
すべてのファイルに同じ統制を求める必要はありません。重要度に応じて統制の深さを変え、低いものは簡素な管理にとどめるのが実務的です。ただし、重要度の判定根拠は記録しておき、用途の変更で重要度が上がった場合に見直せるようにします。
EUC の評価は、内部監査部門と IT 部門のどちらが担当すべきですか？
決まった答えはありませんが、計算の妥当性は会計の知識、ファイルの管理は IT の知識を必要とするため、両方の視点を組み合わせるのが効果的です。実務では、J-SOX の評価チームが業務プロセスの一部として評価し、アクセス制御や版管理の設定確認に IT の専門知識を持つ評価者が加わる形がよく見られます。どちらが担当する場合も、評価者が評価対象のファイルの作成や運用に関与していないことが前提です。
生成 AI に作らせた計算式やマクロは、どう扱えばよいですか？
作成の手段が何であっても、計算式やマクロが意図どおりに動くことを作成者以外の者が検証し、記録を残すという統制の考え方は変わりません。生成された式が一見正しく見えても、集計範囲や条件の誤りを含むことがあるため、テストデータでの検算を省略しないことが大切です。
まとめ
スプレッドシートを中心とする EUC は、決算・財務報告に欠かせない一方で、IT 全般統制の網からこぼれやすいリスクを抱えています。内基報 1 号が示す計算式等の検証、代替手段、アクセス制御・変更管理・バックアップの 3 点を軸に、台帳で重要なファイルを特定し、重要度に応じて統制と評価手続を組み立てることが実務の出発点です。
次の一歩として、決算手順書に沿って EUC 台帳を作り、重要度「高」のファイルが RCM に紐づいているかを確かめてみてください。IT 統制全体の点検にはITGC（IT全般統制）とはも参考になります。
EUC 統制の整備や J-SOX 評価の見直しについてのご相談は、お問い合わせからお寄せください。
参考資料
- 日本公認会計士協会 財務報告内部統制監査基準報告書第1号「財務報告に係る内部統制の監査」（最終改正 2025年2月13日、A147項・A148項） https://jicpa.or.jp/specialized_field/20250214ige.html
- 金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（2023年4月7日） https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html
- 日本公認会計士協会 監査基準報告書500「監査証拠」
- The Institute of Internal Auditors, GTAG「Auditing User-developed Applications」
