内部統制システム開発の完全ガイド

内部統制システムとは、業務の正確性・効率性、財務報告の信頼性、法令遵守、資産保全を継続的に確かめるための仕組みです。単なる申請・承認ツールではなく、リスク、統制、権限、証憑、評価結果をつなぎ、監査で説明できる状態をつくる基盤です。

本記事では、会社法上の内部統制システムとJ-SOXの違い、3点セットやIT全般統制の考え方、パッケージ・クラウド・スクラッチの選び方、開発・導入の進め方、費用相場、開発会社やサービスを比較する際の質問事項までを整理します。上場企業だけでなく、IPO準備企業や、紙・Excel・メール中心の承認業務を見直したい企業にも役立つように、実務で迷いやすいポイントを具体的に解説します。

内部統制システムとは何ですか？

内部統制システムは、法令に適合することだけを目的にしたソフトウェアの名称ではありません。経営者が定めた方針を、現場の業務、情報システム、記録、評価、改善へ落とし込む仕組みの総称です。まず制度上の対象を区別し、そのうえで必要な業務機能と証跡を設計することが重要です。

内部統制が目指す4つの目的

内部統制の目的は、業務の有効性と効率性、財務報告の信頼性、事業活動に関わる法令などの遵守、資産の保全の4つに整理できます。いずれか一つだけを強化すれば十分というものではありません。例えば、購買申請の承認ルートを固定すると不正防止に役立ちますが、マスタ変更の権限や支払データとの照合まで設計しなければ、財務報告の誤りを防ぐ統制としては不十分です。

金融庁が示す内部統制の基本的枠組みでは、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング、ITへの対応という6つの基本的要素で整理されています（出典：金融庁「財務報告に係る内部統制の評価及び監査の基準」、2023年）。システムはこのうちITへの対応を支えるだけでなく、権限・承認・記録・モニタリングを通じて複数の要素に関係します。

会社法上の内部統制とJ-SOXの違い

会社法上の内部統制システムは、取締役会が取締役の職務執行や企業集団の業務を適正に確保するための基本方針を決定し、運用状況を確認する枠組みです。一方、J-SOXは金融商品取引法に基づき、上場会社などが財務報告に係る内部統制の有効性を評価し、必要な報告と監査を受ける制度です。両者は重なる部分がありますが、対象資料、評価手続、報告先が完全に同じではありません。

そのため、要件定義の冒頭で「J-SOXの評価業務を管理したいのか」「会社法上の基本方針や内部監査も一元化したいのか」「申請・承認と証跡だけを電子化したいのか」を分けてください。金融庁は2023年4月に評価範囲の選定や不正リスクへの対応などを含む基準・実施基準を改訂し、2024年4月以後開始事業年度からの実務に影響しています（出典：金融庁、2023年）。制度名だけで製品を探すのではなく、自社が説明すべき対象を先に確定することが必要です。

内部統制システムの種類と主要機能

内部統制システムには、内部統制専用のGRC・評価管理、申請・承認を中心としたワークフロー、ERPや会計システムの統制機能、文書・証憑管理を組み合わせる方式などがあります。単一のシステムですべてを置き換えるとは限らず、既存の会計・販売・購買・人事システムを残しながら、統制情報と証跡を連携させる設計も一般的です。

J-SOX・GRC型で管理する情報

J-SOXやGRCの管理を主目的にする場合は、リスク、統制目的、統制活動、キーコントロール、担当者、評価頻度、証憑、例外、不備、是正計画を一つの台帳で追えることが重要です。業務記述書、業務フロー図、RCM（リスク・コントロール・マトリクス）の3点セットを登録し、どの統制がどのリスクに対応し、どの資料で実施を証明するのかを紐付けます。

この型では、評価対象の追加や変更履歴、評価者のレビュー、証憑の差し替え、監査人への提出状況も重要です。ファイルを置くだけの共有フォルダでは、最新版が分からない、担当者が変わると経緯を追えない、期限超過を発見できないという問題が起きます。版数、承認状態、適用期間、関連プロセスを記録できる仕組みが必要です。

ワークフロー・証跡管理型で押さえる機能

申請・承認を電子化する場合は、稟議、購買、経費、契約、マスタ変更などの申請フォーム、金額・組織・役職に応じた承認ルート、差戻し、代理承認、期限超過通知を確認します。単に紙をPDFにするだけではなく、申請者と承認者を分離できるか、承認後の変更を制限できるか、承認ルートの変更履歴が残るかが統制上の確認点です。

証跡は、誰が、いつ、どの端末や経路から、何を申請・承認・変更したかを追える状態にします。添付資料、操作ログ、設定定義、差戻し理由、例外処理、バックアップからの復旧履歴までを必要な期間保管し、監査向けに検索・出力できることが望ましいです。会計や購買のデータと連携するなら、連携失敗時の通知、再送、重複登録防止も要件に含めてください。

IT全般統制とIT業務処理統制

IT全般統制は、システム全体を安定・安全に管理する統制です。アクセス権限、職務分掌、プログラム変更、障害対応、バックアップ、委託先管理、運用手順などが該当します。IT業務処理統制は、個別の業務処理に組み込まれた入力チェック、承認、計算、照合、エラー処理などを指します。

例えば、経費申請で金額の上限を超えたら上位者へ回す機能は業務処理統制ですが、その承認者マスタを誰が変更できるか、変更がテスト・承認されているか、退職者のアカウントが停止されているかはIT全般統制の論点です。機能一覧だけでなく、統制目的と管理責任の対応表を作ることで、抜け漏れを発見しやすくなります。

内部統制システム開発・導入の進め方

内部統制システムは、製品を契約して終わるものではありません。現状の業務と統制の差分を確かめ、対象範囲を絞り、重要業務で小さく試し、証跡が残ることまで確認してから展開します。監査対応を後付けにすると、稼働後に帳票やログを作り直すことになるため、評価・監査の手続を初期設計へ含めてください。

▶ 詳細はこちら：内部統制システム開発の進め方/やり方/流れや方法/手法/工程/手順

目的・対象範囲と現状業務を整理する

最初に、対象会社、部門、業務、勘定科目、データ、評価対象、キーコントロールを一覧化します。J-SOXの財務報告だけを扱うのか、会社法上の基本方針、内部監査、コンプライアンス、情報セキュリティまで含めるのかで、必要な機能と導入期間が変わります。経営企画、経理、内部監査、情報システム、現場部門から責任者を出し、意思決定の場を早めに設けることが重要です。

次に、紙、Excel、メール、共有フォルダ、既存のERPや会計システムのどこで申請、承認、記録、照合、レビューが行われているかを棚卸しします。業務記述書やフロー図があっても、実際の運用が異なることがあります。現場で使われる帳票、例外処理、承認者の代理、月末の手作業まで確認し、MUSTとWANTを分けてください。

方式を比較し、重要業務でPoCを行う

選択肢は、標準ワークフローやGRCのパッケージ、SaaS、既存ERPの追加機能、個別開発の4つに大別できます。業務を標準機能へ合わせる範囲と、既存ルールをカスタマイズする範囲を先に決めてください。比較では、機能数の多さよりも、統制情報と実際の証跡が一つの流れでつながるか、変更時の影響を追えるかを重視します。

候補を絞ったら、購買・支払、経費、契約、マスタ変更など、重要度が高く異なる業務を1〜2つ選び、PoCを行います。申請から承認、会計連携、証憑保管、ログ検索、監査向け出力までを実データに近い条件で通し、現場の操作負担と管理者の確認負担を測定します。PoCの目的は画面の使いやすさだけでなく、例外時にも統制が崩れないことを確かめることです。

設計・構築・移行・受入テストを行う

設計では、RBACによる役割権限、職務分掌、承認ルート、代理承認、ログ保存期間、バックアップ、API連携、データの所有権、障害時の代替運用を定義します。人事異動や組織改編が起きたときに、誰がどの権限をいつ変更し、承認者が不在のときにどの手続を使うかまで決めることが必要です。

移行では、既存のユーザー、組織、帳票、3点セット、証憑、過去の評価結果を対象に、移行対象・保管対象・廃棄対象を分けます。テストは機能テストだけでなく、アクセス権レビュー、異常系、連携失敗、ログ出力、バックアップ復旧、監査向け資料の作成まで実施します。利用部門によるUATで、通常業務と月次・四半期・年度の評価業務が回ることを確認してください。

稼働後の評価と改善を定着させる

稼働後は、申請の滞留時間、差戻し率、未承認の期限超過、権限レビューの完了率、証憑の登録漏れ、不備の再発率などをKPIとして追います。導入直後に申請件数だけを見ると、入力負荷が高くて現場が迂回している状態を見落とす可能性があります。現場が使い続けられるかと、監査で必要な証拠が揃うかを同時に評価してください。

規程改定、組織変更、法令や監査方針の変更があれば、業務フロー、RCM、承認ルート、マニュアルを更新します。内部統制は一度作って終わる仕組みではなく、リスクの変化に応じて見直すプロセスです。生成AIなどを補助的に使う場合も、出力のレビュー、利用ログ、機密データの入力制限、最終判断者を明確にし、AIの提案だけを証跡にしない運用が必要です。

内部統制システムの費用相場とコスト内訳

内部統制システムの費用は、申請・承認の範囲、利用者数、既存システムとの連携、3点セットや評価調書の移行、監査対応の支援範囲によって大きく変わります。専用GRCは個別見積が多いため、以下はワークフロー、文書管理、GRC、連携開発を組み合わせる場合の実務上の目安です。ライセンス費だけでなく、設定、移行、教育、運用支援を分けて見積もることが重要です。

▶ 詳細はこちら：内部統制システム開発の見積相場や費用/コスト/値段について

導入パターン別の費用目安

申請・承認ワークフローを1〜2部門で導入する場合は、初期費用50万〜300万円程度、期間1〜3か月が一つの目安です。全社ワークフローに帳票移行、権限・SSO、会計連携を加える場合は、初期費用300万〜1,000万円程度、期間3〜6か月が目安になります。実際の金額は帳票数や承認分岐、既存データの状態によって変わります。

J-SOX・GRCの台帳、3点セット、評価・不備管理まで含める場合は、初期費用500万〜1,500万円程度、期間4〜9か月が目安です。ERP・会計・購買・人事を横断する基盤刷新では1,500万〜4,000万円以上、期間6〜18か月程度になることがあります。大規模グループ、多言語、複雑な権限、スクラッチGRCを含めると、3,000万円〜1億円超、12〜24か月以上の計画も想定してください。

見積書で分けるべき費用項目

見積書は、製品・ライセンス、導入設定、帳票やユーザーのデータ移行、API・CSV・SSO連携、統制設計・文書化、テスト、教育、稼働後の保守・評価支援に分けてもらいます。要件定義・設計・実装・テスト・移行・教育が一つの一式になっていると、追加費用の条件が分かりません。各項目に対象範囲、数量、単価、前提条件、除外条件、変更時の精算方法を記載してもらってください。

公開価格の例として、クラウド型ワークフローには初期費用0円、1ユーザー月額500円から提供される料金体系があります。100ユーザーなら基本利用料だけで月5万円、年60万円と計算できますが、基本料金、セキュリティオプション、フォーム移行、複雑な承認ルート、連携、教育などは別に確認が必要です。安いライセンスを内部統制システム全体の費用と扱わないようにしてください（出典：クラウド型ワークフロー提供事業者の公式料金表、2026年確認）。

3年間の総保有コストで比較する

比較では初期費用だけでなく、3年間の総保有コストを算出します。ライセンスやクラウド利用料に、連携の追加費用、ユーザー・組織変更の設定、問い合わせ対応、教育、監査向け資料作成、バックアップやログ保管の拡張を加えます。オンプレミスやスクラッチの場合は、サーバー、監視、パッチ、障害対応、担当者の教育・交代に伴う費用も含めてください。

2026年のデジタル化・AI導入補助金は、通常枠でソフトウェア購入費、クラウド利用料の最大2年分、導入設定、研修、保守などが対象になり得ます。通常枠の補助額は1プロセス以上で5万円以上150万円未満、4プロセス以上で150万円以上450万円以下、補助率は原則1/2以内または条件により2/3以内です（出典：中小企業向けデジタル化・AI導入補助金2026通常枠、2026年）。対象ITツールと登録支援事業者の要件があるため、交付決定前に契約・発注しないことや、公募要領の最新条件を確認することが必要です。

内部統制システムの開発会社・ベンダー・サービスの選び方

開発会社やサービスは、知名度や機能数だけでなく、自社の統制設計を理解し、導入後に運用を支えられるかで選びます。特に「J-SOX対応」という表現は、製品だけで法令適合や監査通過が保証されるという意味ではありません。企業側が決めるリスク、統制、権限、証憑、評価手続を、システムへ正しく反映する責任は残ります。

自社の課題と導入実績が合っているか確認する

まず、内部統制専用のリスク・評価管理を得意とするサービスか、ワークフロー・証跡を得意とするサービスか、ERP・会計・購買などの連携を得意とするSI型かを見分けます。財務報告の評価を管理したい企業と、紙の承認を電子化したい企業では、優先機能が異なります。自社と近い業種、利用者数、拠点数、グループ構成、既存システム、導入期間の事例を確認してください。

実績を聞くときは「内部統制に強いですか」と抽象的に尋ねるのではなく、業務記述書・フロー図・RCMの整理を誰が担当したか、監査人との論点整理をどこまで支援したか、権限レビューや不備管理を稼働後にどう回したかを質問します。導入社数だけでなく、導入前後の課題、期間、追加開発の範囲、利用企業側の担当人数まで確認すると、再現性を判断しやすくなります。

セキュリティと監査証跡を質問する

クラウドを選ぶ場合は、データの所在、暗号化、MFAやSSO、IP制限、権限管理、ログの取得・保管、バックアップ、復旧目標、脆弱性対応、インシデント通知、データ返却・削除、サービス終了時の移行方法を確認します。委託先管理では、SOC 1やSOC 2、ISO 27001などの報告書・認証の有無だけでなく、自社の監査人がどの範囲を利用できるか、追加で自社が実施すべき手続は何かを確認してください。

経済産業省は、システム監査基準・システム管理基準を整備し、財務報告に係るIT統制ガイダンスの追補版を2024年12月に改訂しています（出典：経済産業省「システム監査制度について」、2026年6月更新）。このような基準やガイダンスを踏まえ、アクセス管理、変更管理、運用管理、委託先管理を説明できる資料が提供されるかを確認します。認証マークだけで判断せず、証跡の粒度と責任分界を契約前に明文化することが必要です。

RFPと契約で比較条件をそろえる

RFPには、組織図、対象業務、利用者数、申請・承認帳票数、既存ERPや会計システム、3点セットの有無、監査上の指摘、希望稼働時期、保存年数、連携方式を記載します。候補先には、標準機能で対応する部分、設定で対応する部分、個別開発が必要な部分、運用で補う部分を分けて回答してもらいます。デモでは自社の申請から証跡出力までを実演してもらうと、カタログ上の機能との差が分かります。

契約では、納品物、受入基準、データ移行の責任、障害時の対応時間、サービスレベル、ログやバックアップの保管、再委託、個人情報・機密情報の扱い、データ返却、解約時の移行支援、追加開発の単価を明確にします。監査人から追加資料を求められたときに、誰がどこまで対応するかも記載してください。価格だけでなく、将来の組織変更や法令対応を含めた変更容易性で比較することが大切です。

▶ 詳細はこちら：内部統制システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：内部統制システム開発の発注/外注/依頼/委託方法について

内部統制システム導入でよくある失敗と対策

内部統制のシステム化では、機能を追加するほど安心できるとは限りません。対象範囲、責任者、例外時の手続、運用負担を決めないまま導入すると、現場が使わず、監査資料も揃わない状態になります。代表的な失敗を先に確認して、導入計画へ対策を組み込んでください。

既存業務をそのまま再現し、複雑化する

紙の帳票やExcelの項目をすべて移行し、例外的な承認ルートまで個別開発すると、初期費用だけでなく変更費用も増えます。業務上必要な統制と、単に慣れているだけの手順を分け、標準機能へ合わせる業務、簡素化する業務、個別対応する業務を決めてください。個別開発を選ぶ場合は、法令・監査方針・組織変更による改修を誰が何日で対応するか確認します。

ツール導入だけで監査に通ると考える

システムにログや承認機能があっても、リスク評価が不十分、権限分掌が決まっていない、証憑の内容が統制目的に合っていない、評価者のレビューがないという状態では、内部統制は有効に運用できません。製品の「対応」表示は、利用企業の設計・設定・運用を代替するものではありません。監査人へ確認したい論点を整理し、設計書、設定一覧、テスト結果、運用記録を残してください。

導入後の責任者と更新手順がない

導入時にプロジェクトチームが頑張っても、稼働後の権限申請、異動処理、規程改定、証憑の期限管理、不備の是正を担う人が決まっていなければ、数か月で情報が古くなります。業務部門、経理・内部監査、情報システム、外部委託先の責任分界をRACIなどで明示し、月次・四半期・年度の作業カレンダーを作成してください。

また、稼働後の問い合わせ窓口、設定変更の申請、緊急時の承認、ログの定期レビューを決めておきます。運用KPIを月次で確認し、差戻しが多い帳票や期限超過が多い部門を改善対象にすると、現場の負担を減らしながら統制の実効性を高められます。

内部統制システムについてよくある質問（FAQ）

ここでは、内部統制システムを検討する企業からよく寄せられる質問に回答します。制度上の義務、ワークフローだけで対応できるか、クラウドやExcelからの移行、補助金、監査法人との関係を順に確認してください。

内部統制システムの導入は義務ですか？

すべての企業が同じ製品を導入する義務があるわけではありません。ただし、上場会社などでは財務報告に係る内部統制の評価・報告・監査が関係し、会社法上も取締役会が内部統制システムの基本方針を決定する場面があります。対象範囲と必要な手続は会社規模、上場状況、事業内容で異なるため、法務・経理・内部監査と確認してください。

ワークフローだけでJ-SOXに対応できますか？

ワークフローは申請・承認・証跡を電子化する重要な部品ですが、それだけでJ-SOX全体に対応できるとは限りません。リスク評価、3点セット、権限管理、変更管理、IT全般統制、評価・不備管理、監査資料の提出まで必要な場合は、追加の台帳や連携、運用手続を組み合わせます。まず重要業務を一つ選び、統制目的と必要証拠を整理してから範囲を決めてください。

クラウド型でも監査に対応できますか？

クラウド型でも監査対応は可能ですが、クラウドだから自動的に適合するわけではありません。アクセス権、変更管理、ログ、バックアップ、委託先管理、サービス障害時の代替手続、データ返却を確認し、サービス提供者の報告書を自社の監査手続で利用できるかを監査人へ相談します。利用企業が行う設定・権限レビュー・運用記録も必要です。

中小企業やIPO準備企業にも必要ですか？

中小企業でも、上場準備、取引先からの統制説明、拠点や従業員の増加、経理・購買の属人化がある場合は、早めに整備する価値があります。最初から全社GRCを導入する必要はなく、購買・支払、経費、契約、権限管理など重要な1〜2業務から始め、監査で説明できる記録を残す方法もあります。将来の利用者数や子会社展開を見据え、後から拡張できる方式を選んでください。

Excelや紙の資料から移行できますか？

移行できますが、すべてをそのまま取り込むのではなく、現行資料を最新版、履歴として保管する資料、廃棄候補に分類します。業務記述書、フロー図、RCM、評価調書、証憑、ユーザー・組織情報を移行対象にし、版数や適用期間を付与してください。移行後はサンプル照合、件数確認、権限確認、検索・出力テストを行い、原本の保存要否も法務・監査担当と確認します。

補助金を使えるか、監査法人の承認を得られますか？

補助金は対象ITツール、申請枠、事業者区分、申請時期、対象経費によって決まるため、内部統制機能があるだけで対象になるわけではありません。2026年の制度では、通常枠でソフトウェアやクラウド利用料、導入関連費などが対象になり得ますが、公募要領と登録状況を確認してください。監査法人の承認についても、製品導入の承認ではなく、自社のリスク評価、統制設計、証拠、評価手続が妥当かを相談するものです。導入前の段階から論点を共有してください。

まとめ：内部統制システムは証跡と運用まで設計することが重要です

内部統制システムは、会社法上の基本方針、J-SOX、内部監査、情報セキュリティ、申請・承認、証憑管理などを、自社の目的に合わせて組み合わせる仕組みです。最初に対象範囲を分け、3点セットや実際の業務を棚卸しし、リスク・統制・権限・証跡・評価を一つの流れで設計してください。

導入前に確認する5つのポイント

導入前は、対象制度と業務の範囲、現状の証跡と不備、必要な権限・承認ルール、連携・セキュリティ要件、稼働後の責任者を確認します。費用は初期構築だけでなく、移行、教育、保守、監査対応、組織変更を含む3年間の総保有コストで比較してください。重要業務でPoCを行い、申請から監査向け出力まで通せることを確かめると、導入後の手戻りを抑えられます。

まずは対象業務と必要な証拠を一覧化する

いきなり製品や開発会社を決めるのではなく、対象業務、リスク、統制活動、担当者、証憑、評価頻度、現在の課題を一覧にします。その一覧をRFPや比較表の基準にし、標準機能、設定、個別開発、運用のどこで対応するかを候補先に示してもらってください。制度や認証、補助金の条件は更新されるため、公開前後に最新資料を確認し、必要に応じて監査人や専門家へ相談することが大切です。