内部統制システム開発の発注/外注/依頼/委託方法について

内部統制システムの発注・外注では、製品を買うだけでなく、リスク・統制・担当者・証憑・評価結果がつながる業務基盤を設計することが結論です。J-SOX対応だけを目的にせず、現場で承認が実行され、監査で説明できる証跡が残る範囲までを委託内容に含めることが重要です。

しかし、内部統制システムには、ワークフロー、GRC、ERPの追加機能、スクラッチ開発など複数の選択肢があります。この記事では、発注形態の選び方、RFPと要件整理、契約形態、2026年時点の費用目安、委託先選定、見積比較、稼働後の運用まで、外注前に決めるべき事項を順番に解説します。

▼全体ガイドの記事
・内部統制システム開発の完全ガイド

内部統制システムの発注・外注前に押さえる全体像

発注の成否は、依頼先の知名度よりも、何を統制対象にし、誰がどの証拠を残し、どこまでを委託先が担うかを先に決められるかで左右されます。最初に内部統制システムの意味と、発注で得たい成果を整理します。

内部統制システムは、特定の製品名ではなく、業務を正しく、効率的に、継続的に運用し、監査で説明できる状態をつくる仕組みの総称です。上場企業やIPO準備企業では、財務報告に係る内部統制、いわゆるJ-SOXを指すことが多いですが、会社法上の内部統制システム、コンプライアンス、情報セキュリティ、内部監査まで含む場合もあります。

外注時には、少なくとも業務記述書、業務フロー図、RCM（リスク・コントロール・マトリクス）の3点セットと、申請・承認・変更・照合を裏付ける証憑を対象に含めるか確認します。ワークフローだけを導入しても、統制目的やリスク、評価結果が管理できなければ、内部統制全体の改善にはつながりにくいです。

目的は「J-SOX対応システムを入れる」ではなく、「購買申請の承認漏れを防ぐ」「退職者の権限を速やかに停止する」「RCMと実際の証憑を同じ画面で確認する」のように業務結果で表します。たとえば、紙・Excel・メールに分散している購買承認を電子化するなら、申請前の見積書、承認者、承認日時、発注後の検収、支払データまでを一連の証跡として検索できることが成果になります。

金融庁は2023年4月の改訂で、評価範囲の選定にリスクアプローチを求め、不正リスクへの対応や開示の充実を重視しました。改訂基準は2024年4月1日以後に開始する事業年度から適用されています（出典：金融庁「財務報告に係る内部統制の評価及び監査の基準・実施基準の改訂について」、2023年）。したがって、発注要件にも「全社を同じ粒度で電子化する」より、重要な業務・拠点・勘定科目を特定し、リスクに応じて証跡を残す考え方を反映させます。

発注形態はどれを選ぶ？内部統制システムの外注パターン

発注形態は、標準機能に業務を合わせるSaaS・パッケージ導入、既存ERPや会計システムを拡張する方法、独自要件を開発する方法に大別できます。最初からスクラッチ開発に決めるのではなく、統制上譲れない要件と、業務を変えてもよい部分を分けて比較することが大切です。

申請・承認、権限、操作ログ、文書管理などを早期に整えたい企業には、SaaSやパッケージが適しています。標準機能を使うため、開発期間と初期投資を抑えやすく、法改正やセキュリティ更新をサービス提供者から受けやすい点も利点です。

一方で、製品が「J-SOX対応」と表現されていても、法令適合や監査人の受入れが自動的に保証されるわけではありません。評価範囲、キーコントロール、証憑の保存期間、例外処理を自社で設計し、製品で足りない部分は運用や連携で補う必要があります。

すでにERP、会計、販売、購買、人事システムを運用している場合は、既存のマスタや取引データを活用し、ワークフロー、権限、ログ、証憑管理を追加する方法が候補になります。データを二重入力しにくく、承認済みの購買情報と仕訳、検収、支払いをつなげやすいことが強みです。

ただし、ERP側と新システム側でユーザー、組織、勘定科目、取引先の定義が異なると、連携後に不整合が起きます。RFPでは、どのシステムを正とするか、APIとCSVのどちらで連携するか、連携失敗時に誰が再処理するかまで確認します。

グループ会社ごとに異なる承認規程、多言語・多通貨、独自の証券・製造プロセスなど、標準製品では対応しにくい要件がある場合は、スクラッチ開発や個別連携を検討します。業務に合わせた画面や評価ロジックを作れるため、複雑な統制を一つの基盤に統合しやすい方法です。

反面、法改正、監査論点、OSやブラウザの更新に追随する保守責任が自社または開発会社に残ります。発注時には、要件定義書だけでなく、ソースコードの権利、設計書の納品、脆弱性対応、担当者退職時の引き継ぎ、契約終了後のデータ移行までを契約に含めます。

RFP・要件整理の進め方と発注前の準備

RFP（提案依頼書）は、製品カタログを集めるための資料ではなく、自社の業務課題と評価基準を候補会社に同じ条件で伝える資料です。要件が曖昧なまま相見積もりを取ると、各社が異なる前提で提案するため、金額だけを比べても正しい判断ができません。

RFPの冒頭では、対象会社、対象部門、業務プロセス、利用者数、希望稼働時期、既存システム、監査上の課題を記載します。対象業務は購買、支払、経費、売上、契約、マスタ変更などに分け、どの業務を今回の範囲にするか、将来拡張とするかを明示します。

現状課題は「紙が多い」だけで終わらせず、承認者の不在時に処理が止まる、規程改定後も旧様式が使われる、証憑の版が分からない、権限レビューに時間がかかる、といった事象に落とし込みます。組織図、業務フロー、3点セット、代表的な申請書、監査指摘、既存の権限一覧を添付すると、候補会社が必要な工数を見積もりやすくなります。

機能要件は、申請・承認、代理承認、差戻し、権限・職務分掌、監査ログ、証憑添付、文書版管理、評価・不備管理、通知、検索・出力、ERP連携に分けて整理します。それぞれについて、誰が、どの条件で、何を操作し、どの証拠を、どれだけの期間保存するかを書きます。

たとえば「承認機能があること」ではなく、「金額と組織に応じて承認ルートが自動分岐し、申請者と承認者を分離し、代理承認の理由と期間を記録し、監査向けにCSVまたは画面で出力できること」と定義します。非機能要件では、MFA・SSO、IP制限、暗号化、バックアップ、ログ保存期間、可用性、障害時の代替運用、データ返却・削除を確認します。

候補を絞る前に、購買・支払・経費・マスタ変更など重要度の高い1〜2業務でPoCを実施すると、提案書だけでは分からない運用負荷を確認できます。申請から承認、証憑添付、連携、ログ検索、監査向け出力までを一つのシナリオで通し、現場担当者と内部監査担当者の両方に操作してもらいます。

受入テストは「画面が表示されること」ではなく、統制が機能した証拠を確認するテストにします。承認者が異動した場合、代理承認を使った場合、連携が失敗した場合、規程を改定した場合、退職者を無効化した場合などの例外シナリオも準備し、合格条件、再テスト期限、未解決課題の扱いをRFPと契約書に記載します。

内部統制システムの契約形態と責任分界

内部統制システムでは、開発会社に任せる範囲と、利用企業が負う最終責任を混同しないことが重要です。開発会社は製品設定、画面・連携開発、移行、テスト支援を担えても、どの業務を重要と評価するか、どの統制をキーコントロールにするか、実際に承認を行うかは利用企業が決める必要があります。

要件と完成物が固まっており、期限と予算を管理したい場合は請負契約が候補になります。対象機能、画面・帳票一覧、連携仕様、移行データ、テスト計画、納品物、検収基準、瑕疵対応、遅延時の扱いを具体化しておくと、完成の認識がずれにくくなります。

ただし、J-SOXの運用では、現場ヒアリングの結果で要件が変わることがあります。変更多発が予想される状態で機能を固定すると、追加費用や納期延長が発生しやすいため、要件定義・基本設計を準委任で行い、確定後の開発を請負にする段階契約も検討します。

準委任契約は、専門家が一定の業務を遂行する契約で、現状分析、RFP作成支援、統制設計、製品選定、プロジェクト管理、運用改善などに向いています。業務部門や監査法人との調整を含む場合、作業時間、成果物、会議体、報告頻度、担当者のスキルを明示し、作業の進捗を月次で確認します。

準委任では、成果物の完成責任や稼働保証が請負と同じ形で約束されるとは限りません。そのため、要件定義書、業務フロー、RCM、設定一覧、テスト結果、課題管理表など、各フェーズで受け取る成果物と承認者を決め、次の契約へ移る判断基準を設けます。

SaaSを利用する場合は、開発委託契約だけでなくサービス利用規約とSLA、セキュリティ資料を確認します。データの所在、バックアップ、復旧目標、障害・インシデント通知、再委託先、アクセス権、ログの保管、データ返却・削除、サービス終了時の移行方法を責任分界表に落とし込みます。

2026年4月には、SCSKのERP「PROACTIVE」が財務報告に係る内部統制の運用有効性を対象にした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円（税抜）からと公表されています（出典：株式会社エイトレッド「X-point Cloud」、2026年確認）。100ユーザーならライセンスだけで月5万円、年60万円の計算ですが、フォーム移行、複雑な承認ルート、API連携、SSO、教育、監査向け帳票作成は別途費用になる可能性があります。

見積書では、製品・ライセンス、初期設定、統制設計・文書化、データ移行、連携開発、テスト、教育、保守・サポートを別行にしてもらいます。3年間のTCOを比べる場合は、初期費用に36か月分の利用料、追加ユーザー、ストレージ、APIオプション、保守、規程改定や評価支援の費用を加え、同じ範囲で比較します。

中小企業・小規模事業者は、デジタル化・AI導入補助金2026の通常枠も候補になります。公式案内では、ソフトウェア購入費、クラウド利用料最大2年分、導入コンサルティング、設定、研修、保守サポートなどが対象経費になり得て、補助額は1プロセス以上で5万円以上150万円未満、4プロセス以上で150万円以上450万円以下、補助率は枠や事業者区分により1/2以内または2/3以内です（出典：中小企業基盤整備機構「デジタル化・AI導入補助金2026 通常枠」、2026年）。

ただし、内部統制機能があれば自動的に補助対象になるわけではありません。登録ITツール、登録支援事業者、申請時期、対象経費、交付決定前に契約や発注をしていないことなどを公募要領で確認します。補助金を前提に発注日を決めるのではなく、採択されなかった場合の予算と契約解除・延期の扱いも社内で決めておきます。

委託先選定と見積比較のポイント

委託先は、内部統制の知識、システム実装力、プロジェクト管理力、運用支援力を分けて評価します。大手SIer、ワークフロー製品の開発元、GRC専業、内部統制コンサルティング会社では得意領域が異なるため、会社規模や実績だけでなく、自社の課題に対する役割分担を比較します。

「上場企業への導入実績がある」という説明だけでは不十分です。自社と同じ業務、組織規模、ERP、監査論点を扱った事例を確認し、導入前の課題、対象範囲、期間、体制、稼働後の定着状況まで聞きます。可能であれば、同じ製品を使った企業から、申請率、承認リードタイム、権限レビュー時間、監査資料の作成時間がどう変わったかを確認します。

また、監査人との論点整理を誰が支援するかを確認します。開発会社が監査人の承認を保証することはできないため、監査法人へ説明する資料の作成支援、自社で判断すべき事項、監査指摘が出た場合の追加対応を分けて提案してもらいます。

見積比較では、合計額の安さよりも、含まれる作業と含まれない作業を確認します。比較表には、対象部門・ユーザー数・帳票数・連携本数・移行件数・テストケース数・教育回数・稼働後の支援期間・保守時間を並べ、同じ条件に換算します。

特に注意したいのは、要件定義、データクレンジング、旧帳票の移行、権限マスタの整理、監査向け出力の追加、APIのエラー処理、現場研修が別途になっている見積です。安い見積もりほど、後から追加される可能性のある作業を洗い出し、「前提が変わった場合の単価」「追加要件の見積方法」「作業を自社で担う場合の必要人員」を質問します。

クラウドを選ぶ場合は、ISO 27001、SOC 1・SOC 2、脆弱性対応、MFA・SSO、暗号化、バックアップ、データセンターの所在、再委託先、インシデント通知、ログの保存期間を確認します。SOC報告書があっても、自社のID管理、権限付与・剥奪、入力データの正確性など、利用企業側に残る統制があります。

稼働後は、規程改定や組織変更のたびに承認ルートと権限を更新します。保守契約に、月次の問い合わせ対応だけでなく、半期・年度のアクセス権レビュー支援、監査資料の出力、障害訓練、設定変更のレビュー、ユーザー教育を含めるかを確認すると、導入後に担当者へ負荷が集中しにくいです。

発注後の導入・開発を失敗させない進行管理

内部統制システムは、IT部門だけでは完成しません。経理、購買、営業、人事、内部監査、情報システム、経営層が関わるため、意思決定者と業務責任者を最初に決め、現場が使えるルールへ落とし込む必要があります。

経営層やCFOなどの意思決定者は、対象範囲、予算、リスク許容度を決めます。業務責任者は、申請・承認・照合の正しい業務手順と例外を判断します。情報システム部門は認証、連携、権限、運用を担当し、内部監査は証跡の十分性と評価方法を確認します。

この役割をRACIや責任分界表にし、課題の期限と決裁者を管理します。ベンダーに質問を丸投げすると、規程とシステム設定の不一致が残りやすいため、週次の課題会議と月次の経営報告を設け、未決定事項を放置しない仕組みにします。

既存のExcel、紙帳票、共有フォルダを移行する場合は、不要なデータをそのまま取り込まないことが大切です。現行帳票の棚卸し、重複・欠損・版違いの確認、保存期間の判断、移行対象と廃棄対象の承認、移行後のサンプル照合を工程に入れます。

教育では、機能説明よりも、申請者、承認者、代理承認者、内部監査担当者それぞれの一日の業務を再現します。稼働前に操作マニュアル、FAQ、問い合わせ窓口、障害時の代替手順を用意し、最初の評価サイクルが終わるまで伴走支援を確保すると、現場の反発やメール承認への逆戻りを抑えられます。

導入効果は、稼働したかどうかだけで判定しません。電子申請率、承認リードタイム、差戻し率、期限超過件数、退職者権限の停止時間、証憑検索時間、アクセス権レビューの完了率、監査資料の作成時間などをKPIにします。

数値が悪化した場合は、システムの問題だけでなく、承認ルートが複雑すぎる、規程と画面が違う、入力項目が多い、通知が届かないなどの原因を確認します。四半期ごとにKPIと不備・例外をレビューし、設定変更を承認ログに残すことで、内部統制システムを一度きりの開発案件から継続的な改善基盤へ変えられます。

よくある質問

内部統制システムの発注では、「どこまで外注できるか」「ワークフローだけで足りるか」「監査に通るのか」という疑問が多くあります。ここでは、発注前に特に確認されやすい質問へ直接回答します。

現状分析、RFP作成、製品選定、統制文書の整理、画面設定、連携開発、データ移行、テスト、教育、稼働後支援まで外注できます。ただし、評価範囲や統制目的の最終判断、実際の承認、運用責任、経営者による評価は利用企業側に残るため、責任分界を契約と運用設計に明記します。

ワークフローだけでJ-SOXの全範囲に対応することは難しいです。申請・承認・ログ・証憑管理には有効ですが、3点セット、リスク・統制・評価、不備・是正、IT全般統制、会計やERPとの連携まで必要な場合は、GRCや文書管理、既存業務システムと組み合わせます。

クラウドでも監査対応は可能ですが、クラウドを使うだけで対応できるわけではありません。サービス提供者のSOC 1・SOC 2、ISO 27001、バックアップ、ログ、インシデント対応などを確認し、自社側のユーザー管理、権限レビュー、入力データの正確性、補完統制を整備します。最終的な受入れ可否は監査人へ事前に確認します。

最初から全社のGRCを構築せず、購買・支払・経費・マスタ変更など重要な1〜2業務でPoCを行う方法が現実的です。監査証跡の出力までを確認し、利用者の反応と運用負荷を測ってから、対象部門や評価・不備管理へ拡張します。少人数の内部監査室では、導入後の権限レビューや証憑出力を何人で回せるかも見積条件に含めます。

まとめ

内部統制システムの発注・外注では、製品名や見積総額から入るのではなく、対象業務、リスク、統制、担当者、証憑、評価結果を一つの業務設計として整理します。SaaS・パッケージ、既存ERPの拡張、スクラッチ開発を、標準機能へ合わせる範囲と個別開発する範囲で比較します。

第一に、J-SOX、会社法、内部監査、情報セキュリティのどこまでを対象にするかを決めます。第二に、現状の業務フロー、3点セット、証憑、権限、監査指摘を棚卸しします。第三に、RFPで機能・非機能・連携・移行・テスト・運用の条件をそろえます。第四に、請負、準委任、SaaS利用の責任分界と検収条件を明確にします。第五に、ライセンス、導入設定、移行、連携、教育、保守を分け、3年間のTCOで見積を比較します。

発注後は、重要な業務でPoCを実施し、申請から監査証跡の出力までを通しで確認します。稼働後も、電子申請率、承認時間、権限レビュー、証憑検索時間、不備・例外の推移をKPIで追い、規程改定や組織変更をシステムへ反映します。監査人、現場、情報システム、委託先が同じ責任分界を共有できれば、内部統制システムは監査対応だけでなく、業務品質と意思決定の基盤になります。

▼全体ガイドの記事
・内部統制システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。