内部統制システムの発注は、対象業務とリスクを決めるところから始まります。証跡と責任分界を設計し、PoCと受入テストを経て導入すると、監査で説明できる業務基盤になります。発注形態の選択から導入後の運用まで、段階ごとに決めることを順に押さえます。
▼全体ガイドの記事
・内部統制システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
内部統制システムの発注・外注前に押さえる全体像
発注の成否は、依頼先の知名度よりも、統制対象や証拠、委託範囲を先に決められるかで決まります。
内部統制システムの定義と発注範囲
内部統制システムは製品名ではなく、業務を正しく効率的に続け、監査で説明できる状態をつくる仕組みの総称です。発注範囲は、対象領域と必要な証跡から整理します。
- 対象領域：J-SOXのほか、会社法、コンプライアンス、情報セキュリティ、内部監査を含む場合があります。
- 文書と証憑：業務記述書、業務フロー図、RCM（リスク・コントロール・マトリクス）、申請・承認・変更・照合の証憑が手元にあるかを洗い出します。
- 機能範囲：ワークフロー中心の製品では、統制目的やリスク、評価結果を扱えず、全体の改善につながりにくい場合があります。
上場企業やIPO準備企業では、「内部統制」という言葉が財務報告に係る内部統制、いわゆるJ-SOXを指すことが多くあります。
発注で目指す成果の定義
発注側は、システム導入そのものではなく業務結果で目的を表し、実現してほしい業務上の変化を具体的に書き出します。
- 承認漏れの防止：購買申請で承認が抜けない状態をつくります。
- 権限の停止：退職者の権限を速やかに止められること。
- 証跡の確認：RCMと実際の証憑を同じ画面で見比べられること。
- 購買承認の電子化：紙、Excel、メールに分散した購買承認を電子化すること。
- 購買記録の検索：申請前の見積書、承認者と日時、発注後の検収、支払データを一連の証跡として検索できること。
金融庁は2023年4月の改訂で、評価範囲の選定にリスクアプローチを求めました。金融庁は、不正リスクへの対応と開示の充実も重視しています（出典：金融庁「財務報告に係る内部統制の評価及び監査の基準・実施基準の改訂について」、2023年）。
改訂基準は2024年4月1日以後に開始する事業年度から適用されています。
発注要件では、全社を同じ粒度で電子化するより、重要な業務・拠点・勘定科目を特定し、リスクに応じて証跡を残す形で定めます。
内部統制システムの発注形態と外注パターン
発注形態は、SaaS・パッケージ、既存ERPなどの拡張、独自要件の開発に大別できます。まず、統制上譲れない要件と、業務を変えてもよい部分を分けて比べます。
SaaS・パッケージを導入するケース
標準機能で内部統制を早く整えたい企業は、SaaSやパッケージの特徴を確認するとよいでしょう。
- 標準機能：申請・承認、権限、操作ログ、文書管理を備えた製品が候補になります。
- 導入と更新：開発期間と初期投資を抑えやすく、法改正やセキュリティ更新も受けやすい方法です。
- 保証範囲：「J-SOX対応」と書かれた製品でも、法令適合や監査人の受入れが保証されるわけではありません。
- 自社での設計：評価範囲、キーコントロール、証憑の保存期間、例外処理を自社で決め、足りない部分を運用や連携で補います。
既存ERP・会計システムを拡張するケース
既存システムを活かす場合は、追加する機能と連携条件をセットで検討します。
- 既存資産の活用：ERP、会計、販売、購買、人事のマスタや取引データを使い、ワークフロー、権限、ログ、証憑管理を追加できます。
- 業務データの連携：二重入力を抑え、承認済みの購買情報を仕訳、検収、支払いへつなげやすくなります。
- 定義の不整合：システム間でユーザーや組織の定義が異なると、連携後に不整合が起きます。
- 連携条件：RFPで正とするシステム、API・CSVの選択、連携失敗時の再処理担当者を決めます。
スクラッチ開発・個別連携を選ぶケース
標準製品では対応しにくい独自要件がある場合、スクラッチ開発や個別連携が候補になります。
- 個別要件：独自の承認規程、多言語・多通貨、証券・製造プロセスなどに対応できます。
- 業務への適合：専用の画面や評価ロジックを作り、複雑な統制を一つの基盤にまとめられます。
- 保守責任：法改正、監査論点、OS・ブラウザ更新への対応を、自社と開発会社のどちらが担うかの取り決め。
- 契約条件：ソースコードの権利、設計書の納品、脆弱性対応、担当者退職時の引き継ぎを盛り込みます。
- 終了時の対応：契約終了後のデータ移行方法も決めます。
RFP・要件整理の進め方と発注前の準備
RFP（提案依頼書）は、自社の業務課題と評価基準を候補会社へ同じ条件で伝える資料です。
要件が曖昧なまま相見積もりを取ると、各社の前提がずれたまま見積もられるため、金額だけでは正しく判断できません。
RFPに書くべき対象範囲と現状課題
見積もりの前提をそろえるため、対象範囲と現状課題を具体的に書き出します。
- 対象範囲：会社・部門、業務、利用者数、希望稼働時期、既存システム、監査課題を記載します。
- 対象業務：購買、支払、経費、売上、契約、マスタ変更ごとに、今回の範囲と将来の拡張を分けて示します。
- 現状課題：承認者不在による停滞、旧様式の利用、証憑の版不明、権限レビューの負荷などを挙げます。
- 添付資料：組織図、業務フロー、3点セット、申請書、監査指摘、権限一覧を揃えると、候補会社が工数を見積もりやすくなります。
統制目的と証跡から逆算する機能要件
機能要件は、利用者、操作条件、残す証拠、保存期間を基準に整理します。そのうえで、主な機能と条件を洗い出します。
- 申請処理：申請・承認、代理承認、差戻しを扱います。
- 統制管理：権限・職務分掌、ログ、証憑、文書版管理、評価・不備管理を整理します。
- 情報活用：通知、検索・出力、ERP連携を要件に含めます。
- 承認ルート：金額と組織に応じて分岐させ、申請者と承認者を分離します。
- 代理承認：理由と期間を記録し、監査向けにCSVまたは画面で出力します。
非機能要件では、MFA・SSOで認証を、IP制限で接続元を確かめます。
暗号化とバックアップ、ログ保存期間と可用性も確認します。加えて、障害時の代替運用と、データの返却・削除も定めます。
PoCと受入テストの条件設定
候補を絞る前に、重要度の高い1〜2業務でPoCを行い、提案書だけでは分からない運用負荷を確かめます。
- 購買・支払・経費・マスタ変更などから、重要度の高い1〜2業務を選びます。
- 申請、承認、証憑添付、連携、ログ検索、監査向け出力を一つのシナリオで試します。現場担当者と内部監査担当者が実際に操作します。
- 受入テストで統制の証拠を確認し、承認者の異動、代理承認、連携失敗、規程改定、退職者の無効化も試します。
- 合格条件、再テスト期限、未解決課題の扱いをRFPと契約書に記載します。
内部統制システムの契約形態と責任分界
まず、開発会社に任せる範囲と、利用企業が負う最終責任を分けます。
開発会社は、製品設定、画面・連携開発、移行、テスト支援を担えます。
利用企業は、どの業務を重要と評価するか、どの統制をキーコントロールにするか、実際に承認を行うかを決めます。
請負契約の完成物と検収条件
要件と完成物が固まり、期限と予算を管理したい場合は請負契約が候補です。契約で定める項目を揃えると、完成の認識がずれにくくなります。
- 開発範囲：対象機能、画面・帳票、連携仕様、移行データを明確にします。
- 検収条件：テスト計画、納品物、検収基準を定めます。
- 契約上の扱い：瑕疵対応と遅延時の扱いを決めます。
J-SOXでは現場ヒアリングの後に要件が変わることがあります。
変更が多い状態で機能を固定すると、追加費用や納期延長が起きやすくなります。
利用企業は、要件定義・基本設計を準委任で行い、確定後の開発を請負にする段階契約も検討します。
要件定義・伴走支援に向く準委任契約
準委任契約は、専門家が一定の業務を行う契約です。要件定義や伴走支援では、業務内容と成果物を明確にします。
- 対象業務：現状分析、RFP作成支援、統制設計、製品選定、進行管理、運用改善が候補です。
- 遂行条件：作業時間、会議体、報告頻度、担当者のスキルを明記し、進捗を月次で確認します。
- 成果物：要件定義書、業務フロー、RCM、設定一覧、テスト結果、課題管理表の受領と承認者を決めます。
成果物の完成責任や稼働保証は、請負と同じ形では約束されないことがあります。そこで、各フェーズの成果物を確認し、次の契約へ移る判断基準を設けます。
SaaS利用契約の委託先統制
SaaSでは利用規約、SLA、セキュリティ資料を確認し、責任分界表に委託先統制を記載します。
- サービス管理：データ所在、バックアップ、復旧目標、障害・事故通知、再委託先、アクセス権、ログ保管を確認します。
- 契約終了：データ返却・削除と、サービス終了時の移行方法を明記します。
SCSKのERP「PROACTIVE」は2026年4月にSOC1保証報告書（Type2）を受領しました。公表資料（出典：SCSK「PROACTIVEがSOC1保証報告書（Type2）を受領」、2026年）では、対象は財務報告に係る内部統制の運用有効性とされています。
第三者保証は、委託先を比べるときの材料になります。ただし、監査人が報告書を利用できる範囲と、自社が行う補完統制を確かめたうえで採用します。
内部統制システムの費用相場とコストの内訳
費用は製品料金だけでなく、統制設計や設定・開発、帳票・証憑移行などの作業で構成されます。ERP連携、テスト、教育、稼働後支援も、費用の内訳になります。
専用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億円超の場合もあります。
金額は要件と対象範囲による推定レンジです。特定の金額を保証するものではありません。
ライセンス費用と導入費用の内訳
公開価格がある製品でも、ライセンス料がシステム全体の費用になるわけではありません。そのため、費用を比べるときは次の項目に分けて見ます。
- ライセンス：X-point Cloudは初期費用0円、1ユーザー月額500円（税抜）からです。
- 追加作業：100ユーザーなら月5万円、年60万円です。フォーム移行、承認ルート、API、SSO、教育、監査帳票は別料金の場合があります。
- 導入費：製品・ライセンス、初期設定、統制設計・文書化、移行、連携、テスト、教育、保守を分けます。
- 3年間のTCO：初期費用と36か月分の利用料に、追加ユーザー、ストレージ、API、保守、規程改定・評価支援を加えます。
この公開価格は株式会社エイトレッドの公表情報に基づきます（出典：株式会社エイトレッド「X-point Cloud」、2026年確認）。
2026年の補助金の活用可能性
中小企業・小規模事業者であれば、デジタル化・AI導入補助金2026の通常枠も候補になります。申請前に、対象経費と要件を確かめます。
- 対象経費：ソフトウェア購入費、クラウド利用料最大2年分、導入コンサル、設定、研修、保守サポートなどが対象になり得ます。
- 補助額・率：補助額は5万円以上450万円以下です。補助率は枠や事業者区分により1/2以内または2/3以内です。
- 申請要件：登録ITツール、登録支援事業者、申請時期、対象経費、交付決定前の契約・発注の有無を公募要領で確認します。
申請枠ごとの補助額は、1プロセス以上で5万円以上150万円未満、4プロセス以上で150万円以上450万円以下です（出典：中小企業基盤整備機構「デジタル化・AI導入補助金2026 通常枠」、2026年）。
内部統制機能があっても、自動的に補助対象になるわけではありません。そのため、採択されなかった場合に備えて、予算と契約解除・延期の扱いも社内で決めておきます。
委託先選定と見積比較のポイント
委託先は、内部統制の知識、システム実装力、進行管理力、運用支援力を分けて評価します。
大手SIer、ワークフロー製品の開発元、GRC専業、内部統制コンサルでは、得意領域が異なります。
会社の規模や実績だけでなく、自社の課題に対してどこまでの役割分担を担えるかも比べます。
統制課題の近さで見る実績
実績を見るときは、「上場企業への導入実績」よりも、自社に近い統制課題を扱った事例と支援内容を確認します。
- 事例の近さ：同じ業務、組織規模、ERP、監査論点の導入前課題、対象範囲、期間、体制を確認します。
- 定着効果：稼働後の定着状況や、申請率、承認リードタイム、権限レビュー時間、監査資料作成時間の変化を聞きます。
- 監査支援：説明資料の作成、自社の判断事項、監査指摘後の追加対応を分けて提案してもらいます。
監査人との論点整理も、あわせて確かめます。ただし、開発会社が監査人の承認を保証することはできません。
前提条件をそろえた見積の比較
合計額を比べる前に、作業範囲と前提条件をそろえます。そのうえで、確認したい項目を見積書と照らし合わせます。
- 比較条件：対象部門、ユーザー・帳票・連携・移行件数、テスト数、教育回数、支援期間、保守時間をそろえます。
- 別料金の作業：要件定義、データ整理、旧帳票移行、権限マスタ、監査出力、APIエラー処理、現場研修を確認します。
- 追加時の条件：前提変更時の単価、追加要件の見積方法、自社で担う場合の人員を質問します。
見積もりが安く見えるときほど、後から追加される可能性のある作業を洗い出します。
セキュリティと稼働後の運用体制の評価
クラウドでは、セキュリティと稼働後の支援体制を確認し、自社に残る統制も把握します。
- 提供者の管理：ISO 27001、SOC 1・SOC 2、脆弱性対応、MFA・SSO、暗号化、バックアップを確認します。
- 委託先情報：データセンターの所在、再委託先、事故通知、ログ保存期間を押さえます。
- 運用支援：月次の問い合わせ、半期・年度のアクセス権レビュー支援、監査資料出力、障害訓練、設定変更レビュー、ユーザー教育を保守に含めるかを決めます。
ID管理、権限の付与・剥奪、入力データの正確性などは、SOC報告書があっても利用企業側に残る場合があります。
稼働後は、規程改定や組織変更に合わせて承認ルートと権限を更新します。保守に複数の支援をまとめて含めておくと、担当者への負荷が集中しにくくなります。
発注後の導入・開発を失敗させない進行管理
内部統制システムは、IT部門だけでは完成しません。経理、購買、営業などの業務部門が関わります。さらに、人事、内部監査、情報システム、経営層も加わります。
発注側は、意思決定者と業務責任者を決め、現場が使えるルールに落とし込みます。
意思決定者・業務責任者・運用担当の役割分担
関係者の役割を分けておくと、意思決定と日々の運用をそれぞれ進めやすくなります。
- 意思決定者：経営層やCFOなどが対象範囲、予算、リスク許容度を決めます。
- 業務責任者：申請・承認・照合の手順と例外を判断します。
- 情報システム：認証、連携、権限、運用を担当します。
- 内部監査：証跡の十分性と評価方法を確認します。
役割はRACIや責任分界表にまとめ、課題ごとの期限と決裁者を管理します。質問をベンダーに丸投げすると、規程と設定の不一致が残ることがあります。
週次の課題会議と月次の経営報告を設け、未決定事項が残ったままにならない仕組みをつくります。
移行・教育・定着の開発工程への組み込み
移行・教育・定着は開発工程に含めておき、不要なデータは移さずに、利用者の業務を準備します。
- データ確認：帳票を棚卸しし、重複・欠損・版違いと保存期間を確認します。
- 移行承認：移行・廃棄対象を承認し、移行後にサンプルを照合します。
- 利用者教育：申請者、承認者、代理承認者、内部監査担当者の業務を再現します。
- 稼働支援：マニュアル、FAQ、問い合わせ窓口、障害時の代替手順を用意し、最初の評価サイクルまで伴走します。
伴走支援を確保しておくと、現場の反発や、メール承認への逆戻りを抑えられます。
稼働後KPIによる改善の継続
導入効果は、稼働したかどうかだけでなく、業務と統制のKPIで判定します。
- 申請・承認：電子申請率、承認リードタイム、差戻し率、期限超過件数を追います。
- 権限管理：退職者権限の停止時間とアクセス権レビュー完了率を見ます。
- 証跡と監査：証憑の検索時間と監査資料の作成時間を測ります。
数値が悪化したときは、システム以外の原因も確かめます。たとえば、承認ルートが複雑、規程と画面が異なる、入力項目が多い、通知が届かないといった要因があります。
四半期ごとに、KPI、不備、例外をレビューします。設定変更を承認ログに残しておくと、継続的な改善の基盤になります。
よくある質問
発注時には、外注範囲、ワークフローの適否、監査対応について疑問が出やすいものです。よく寄せられる質問に答えます。
内部統制システムはどこまで外注できますか？
現状分析、RFP作成、製品選定は外注できます。統制文書の整理、画面設定、連携開発も任せられます。データ移行、テスト、教育、稼働後支援まで含めて外注できます。
ただし、評価範囲や統制目的の最終判断、実際の承認、運用責任、経営者による評価は、利用企業に残ります。そのため、責任分界を契約と運用設計の両方に明記します。
ワークフローだけでJ-SOX対応できますか？
ワークフローは申請・承認、ログ、証憑管理に有効ですが、J-SOXの全範囲をワークフローだけで担うのは難しいです。
3点セットや、リスク・統制・評価を扱う必要があるなら、GRCや文書管理と組み合わせます。不備・是正、IT全般統制、会計やERP連携まで要るなら、既存業務システムとの連携も検討します。
クラウドの内部統制システムでも監査に対応できますか？
クラウドでも監査対応はできます。ただし、利用企業側の確認も必要です。提供者のSOC 1・SOC 2、ISO 27001、バックアップ、ログ、事故対応を確かめます。
自社側でも、ユーザー管理、権限レビュー、入力データの正確性、補完統制を整えます。受入れ可否は、最終的に監査人へ事前に確かめます。
少人数の会社はどこから発注するとよいですか？
全社のGRCを最初から構築するより、重要な1〜2業務でPoCを行う方法が現実的です。購買、支払、経費、マスタ変更などが候補になります。
監査証跡の出力まで確かめ、利用者の反応と運用負荷を測ったうえで、対象部門や評価・不備管理へ広げます。
少人数の内部監査室では、導入後の権限レビューや証憑出力を何人で回せるかも、見積条件に含めます。
まとめ
発注では、製品名や見積総額より先に、対象業務、リスク、統制、担当者、証憑、評価結果を整理します。
SaaS・パッケージ、既存ERPの拡張、スクラッチ開発は、標準機能に合わせる範囲と個別開発の範囲で比べます。
発注前に確認する五つの項目
発注前に確認する項目は、次の五つです。
- 対象範囲：J-SOX、会社法、内部監査、情報セキュリティの範囲を決めます。
- 現状資料：業務フロー、3点セット、証憑、権限、監査指摘を洗い出します。
- RFP：機能・非機能、連携、移行、テスト、運用の条件をそろえます。
- 契約：請負、準委任、SaaSの責任分界と検収条件を明確にします。
- 費用：ライセンス、設定、移行、連携、教育、保守を分け、3年間のTCOで比べます。
小さく検証してから全社へ広げる進め方
発注後は重要業務でPoCを行い、申請から監査証跡の出力まで確かめます。稼働後は各KPIを追い、規程改定や組織変更をシステムに反映します。
監査人、現場、情報システム、委託先が責任分界を共有すれば、内部統制システムは監査対応に加え、業務品質と意思決定の基盤になります。
▼全体ガイドの記事
・内部統制システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。