JSOXのIT統制対応を任された経理担当者から、最初によく聞かれる質問があります。「結局、システムを点検すればいいんですよね?」というものです。この理解のまま進めると、たいてい途中で手が止まります。IT統制対応が止まる会社の多くは、システムの技術的な不備が原因ではありません。会計側とIT側の間で「何を・なぜ求められているか」の認識がずれたまま、誰も対応をリードできていないことが原因です。この記事では、JSOXとIT統制の制度的なつながりを整理したうえで、現場でよく見る「止まり方」のパターンと、そこから抜け出すための最初の一歩を、私自身がIPO支援やITGC構築支援で見てきた実務の目線でお伝えします。
この記事を読んでわかること
- 財務報告に係る内部統制(JSOX)の中で、IT統制がどこに位置づけられるのか
- IT統制対応が止まる会社に共通する、会計側とIT側のすれ違いパターン
- 罰則よりも先に効いてくる、監査対応コストという実務上の負担
- 4カテゴリの統制にいきなり着手せず、最初にやるべきこと
財務報告に係る内部統制(JSOX)の中でIT統制はどこに位置するか
JSOXとは、財務報告に係る内部統制の評価・監査制度のことを指します。内部統制が達成すべき目的は、一般的に以下の4つに整理されます。
- 業務の有効性および効率性
- 財務報告の信頼性
- 事業活動に関わる法令等の遵守
- 資産の保全
上場企業(および重要な連結子会社)に対して、この範囲の内部統制の有効性を経営者自身が評価し、外部に報告することが求められています。また、IPOを目指す会社であれば、上場後を見据えて準備段階から同じ枠組みに沿った体制づくりが必要になります。
IT統制は、内部統制を支える一部として位置づけられています。現代において、会計業務はほぼ電子化・自動化されている状況にあり、財務報告の数字はシステムを経由して作られています。そのため、システムの運用が信頼できる状態になっているかどうかが、そのままJSOXの評価対象に入ってくる、という構造となります。IT統制はさらに「IT全社的統制」「IT全般統制」「IT業務処理統制」の3階層に分かれますが、この分類の詳細はIT全般統制の全体像と4カテゴリで扱っているので、ここでは位置関係だけを押さえておきます。
この位置づけを図解つきでさらに詳しく整理したものは、IT統制構築支援のページにもまとめています。
ここで実務上よく混同されるのが「内部監査」と「JSOX」の違いです。内部監査は業務全般の適切性を幅広くチェックする活動ですが、JSOXが対象にしているのは、あくまで報告の信頼性に関わる範囲に絞った内部統制です。
| 内部監査業務全般の適切性を幅広くチェックする活動。対象範囲は財務報告に限定されない | / | JSOX(財務報告に係る内部統制)財務報告の信頼性に関わる範囲に絞って、経営者が評価・報告する制度 |
もう一つよく聞かれるのが「うちのシステムは財務に関係しないから対象外ですよね」という質問ですが、これも実務上は要注意です。人事システムや在庫管理システムであっても、そこで作られたデータが最終的に財務諸表の数字につながっているなら、JSOXの評価範囲に入る可能性があります。
つまりJSOXが求めているのは、システムそのものの技術的な健全性を点検することではなく、「財務報告の信頼性」という範囲の中で、財務報告の数字が正しく作られる仕組みになっているかを経営者が説明できる状態を作ることです。この前提を取り違えると、IT担当者は「うちのシステムに脆弱性はないか」という技術監査の話だと思い込み、会計担当者との間で最初からすれ違いが生じます。内部統制そのものの目的については、内部統制の目的でも整理していますので、あわせて参照してください。
IT統制がJSOXに組み込まれている理由
この位置づけを、もう少し実務目線で見てみます。手作業で伝票を起こしていた時代なら、担当者の目視確認やダブルチェックで不正やミスを防ぐことができました。しかし今は、販売管理システムが自動で仕訳データを作り、会計システムに連携し、そのまま決算数値へとつながっていきます。この一連の流れのどこかでシステムが不正確な処理をしていれば、それがそのまま財務報告の誤りになります。だからこそJSOXは、会計処理そのものだけでなく、その処理を支えるIT統制(IT全般統制・IT業務処理統制)を評価対象に組み込んでいます。
たとえば、販売管理システムの単価マスタが誤って更新されたまま気づかれなければ、売上高はそのまま誤った金額で計上されてしまいます。これは経理担当者の入力ミスではなく、マスタを更新する権限が適切な人に限られていたか、更新時に承認のプロセスを踏んでいたかという、IT統制側の問題です。会計処理の入口をいくら丁寧にチェックしても、その手前のシステム側が崩れていれば意味がないというのが、この結びつきの実務的な姿です。
なお、2023年4月には金融庁が内部統制基準を改訂し、2024年4月以後に始まる事業年度から適用されています。この改訂では「ITへの対応」や「情報システムに関するセキュリティの確保」の重要性が、以前よりも明確に打ち出されました。クラウドサービスの利用や外部委託が広がったことを踏まえた改訂で、IT統制がJSOXの中で軽視できない領域になってきていることの裏付けとも言えます。
システムが信頼できないと判断された場合、監査人はシステムが出したデータをそのまま信用せず、手作業でのサンプルテストを増やして裏付けを取ろうとします。この「監査人が手を動かして確認する量が増える」という結末については、後ほど改めて触れます。
現場でJSOXのIT統制対応が止まる典型パターン
ここが今回、一番お伝えしたい部分です。私がIPO支援やITGC構築支援の現場で見てきた限り、対応が止まる会社に共通しているのは、システムの不備そのものよりも「担当のねじれ」です。
JSOXの財務報告に関わる部分は、たいてい内部監査室や管理部が中心になって進めます。ところがIT統制のパートに入った途端、担当者同士がお互いに持て余す状態になりがちです。管理部側は「ITのことはよく分からない」と感じ、IT部門側は「内部統制の視点で何を求められているのか分からない」と感じます。どちらも悪気があるわけではなく、単純に評価する枠組みが共有されていないだけなのですが、この状態のまま進めると、体制図の上では担当が決まっていても、実際には誰も評価の中身に踏み込めません。
会計担当者側の困りごとをもう少し具体的にすると、「何の基準で、何を評価しているのか」という土台そのものが整理できていないケースが目立ちます。一方でエンジニア側からは、「なぜソースコードそのものを見ないのか」「なぜ仕様書の中身より、承認の記録の有無を聞かれるのか」といった疑問が出ます。
| 会計担当者の視点「何の基準で、何を評価すればいいのか分からない」 | / | エンジニアの視点「なぜソースコードを見ないのか分からない」 |
JSOXが見ているのは技術的な正しさではなく、業務として適切に統制された記録が残っているかどうかです。この視点の違いを埋めないまま進めると、双方が「相手は分かっていない」と感じたまま平行線になります。会計担当者とエンジニアのすれ違いがなぜ起きるのかは、IT統制がわかりにくい本当の理由でさらに掘り下げています。
私自身、会計とITの両方の言葉がある程度分かる立場で現場に入ることが多いのですが、それでも「相手が何につまずいているのか」を最初から正確に言い当てられるわけではありません。両方の言葉が分かることと、その間をうまく翻訳できることは、必ずしもイコールではないというのが正直な実感です。だからこそ、最初のヒアリングで時間をかけて「お互い、何が分からないのか」をすり合わせる工程を省略しないようにしています。
このすれ違いは、実際の監査対応の場面でより具体的な形で表れます。エンジニアは技術には詳しくても、内部監査室や監査法人が何を求めているのかが分からず、コミュニケーションに苦労することが少なくありません。一方で、内部監査室や監査法人の側もITの知識に明るいとは限らず、エンジニアの説明をうまく理解できないまま、誤った判断をしてしまうことがあります。この行き違いが積み重なると、エンジニア側は本来不要な作業まで「監査だから」と押し付けられてしまい、監査人側は本当に確認すべきリスクを見落としたまま監査を終えてしまうという、双方にとって不幸な結果につながります。こうした監査対応そのもののすれ違いについては、システム監査のページでも扱っています。
IT統制の不備による監査対応コスト
JSOX対応というと、「指摘されたらどうなるのか」という罰則面の不安が先に立つ方が多いのですが、私の実務感覚では、実際に先に効いてくるのはそこではありません。
IT全般統制に不備があると判断されると、監査人はシステムが出す数字をそのまま信頼できないため、手作業でのサンプルテストの件数を増やして裏付けを取らざるを得なくなります。これは監査対応の工数がそのまま増えることを意味します。指摘を受けた年だけの話ではなく、統制が改善されるまで毎年続く負担です。「一度指摘される怖さ」よりも「毎年の監査対応工数が膨らみ続ける怖さ」のほうが、実務上のダメージとしては大きいというのが、複数の現場を見てきた実感です。
さらに近年は、M&Aが活発化したことで、これまで評価対象から外れていたグループ子会社の内部統制まで見られる機会が増えている実感があります。2023年の基準改正も、今まで踏み込まれていなかった子会社やITの領域をより深く見る方向のものです。ただ実務の現場を見ていると、この改正にきちんと追いついている上場企業はまだ多くありません。JSOX対応が毎年「前年の焼き直し」のまま止まっていて、制度が始まった2006〜2008年頃の作り込みからほとんど更新されていないケースにもよく出会います。クラウド中心・自社開発が増えたことで、自社開発におけるITGCをきちんと検証できる人材が現場に少ないとも感じています。「うちの子会社は小さいから対象外」という感覚のままでいると、範囲と深さの両方が広がる改正に対応しきれなくなるリスクがあります。
システム刷新の場面で、この構造がそのまま表面化した実例もあります。キーコーヒーは2025年1月に基幹システムを移行した際、新システムの不具合で在庫データが二重計上され、有価証券報告書の訂正にまで至りました。開示資料では、在庫管理に関わる内部統制に重要な不備があったと説明されています。ツインバードも2024年11月にERPを新規導入した直後に原価計算の誤りが発生し、決算短信の訂正と「内部統制は有効でない」という開示に至っています。同社の開示では、新基幹システムの開発要件を理解していた担当者が退職し、引き継ぎが不十分だったことが根本原因として挙げられていました。どちらも上場企業にはなりますが、「システム導入や統制の作り込みを誤ると、決算そのものが締められなくなる」という帰結は、規模を問わず起こり得ます。
何から手をつければいいか
対象になる統制は、一般的に「変更管理」「IT業務管理」「アクセス管理」「外部委託管理」の4カテゴリに整理されます。ただ、いきなりこの4つを個別に潰しにいこうとすると、たいてい途中で迷子になります。私が現場で最初にお勧めしているのは、4カテゴリに手をつける前に「システム構成と業務プロセスの理解」から始めることです。
| ①棚卸どのシステムがどの業務に関わるかを整理する | → | ②データの流れ財務数値にどうつながるかを追う | → | ③リスクの仮説どこに不備が潜みそうかを洗い出す | → | ④4カテゴリへ割り振り変更管理・IT業務管理・アクセス管理・外部委託管理に整理する |
順番を飛ばして4カテゴリから入ると、システムごとの重要度も分からないまま作業が広がってしまうので、遠回りに見えてこの順番のほうが早く進みます。
IPO準備企業であれば、この理解を始める時期も意識しておく必要があります。上場申請の直前から動き出すと間に合わないことが多く、N-2期(上場申請の2期前)あたりから、システムと業務プロセスの棚卸に着手しておくのが実務上の目安です。着手の優先順位やスケジュールの立て方は、「IT全般統制とJSOX」(公開後にリンクを追加します)でさらに詳しく扱う予定です。
ここまで見てきたように、対応が止まる原因の多くは技術ではなく、会計側とIT側の間の「共通言語のなさ」にあります。だとすれば、必要なのは片方だけで頑張ることではなく、両方の言語が分かる橋渡し役です。社内に適任者がいない場合は、外部の力を借りることも含めて検討する価値があると思います。
IT統制構築支援をご検討の方へ
会計とITの橋渡し役として、JSOXのIT統制整備を第三者目線でご支援します。「何から手をつければいいか分からない」という段階からご相談いただけます。
サービス詳細を見る 無料相談・お問い合わせまとめ
JSOXのIT統制対応が止まるのは、たいていシステムの技術的な問題ではなく、会計側とIT側の間にある認識のズレが原因です。そして実務上は、罰則そのものよりも、監査対応工数が毎年膨らみ続けるコストのほうが先に効いてきます。
まずは4カテゴリに手をつける前に、自社が今どの基準(監基報315やJSOX実施基準など)で内部統制を評価しているのかを確認するところから始めてみてください。全体像が見えてくると、次にどこから手をつければいいかも自然と見えてきます。
関連記事
- IT統制がわかりにくい本当の理由
- IT全般統制の全体像と4カテゴリ
- 内部統制の目的
- IT全般統制とJSOX(着手優先度・スケジュール)(← 未公開記事:公開後にURLを差し替え)
- IT統制構築支援(サービスページ)
- システム監査(サービスページ)
参考資料
- 日本公認会計士協会「JSOX(内部統制報告制度)」(https://jicpa.or.jp/cpainfo/introduction/keyword/soxjsox.html)
- EY Japan「内部統制報告制度の改訂 第1回:内部統制報告制度の改訂概要」(https://www.ey.com/ja_jp/insights/assurance/info-sensor-2023-12-01-special-program)2023年改訂の適用時期・IT統制関連の改訂内容について
- 日経クロステック「システム刷新が『内部統制・無効』を招く、相次ぐ決算訂正が示す構造的問題」(https://xtech.nikkei.com/atcl/nxt/column/18/00989/091100187/)キーコーヒー・ツインバードの事例について