「監査法人からIT統制対応を求められたので、次のシステム開発では対応済のものをお願いします」――そう伝えたのに、ベンダーからは「具体的に何を対応すればよいですか」と聞き返されて言葉に詰まった経験はないでしょうか。IPO準備・上場グループ会社・監査法人指摘への対応など、IT統制を意識せざるを得ない場面は増えていますが、発注者側で要件を具体化できないまま開発が進み、リリース後に監査で追加指摘を受けるケースは少なくありません。
IT統制が難しく感じられる理由は、「情シスが構築する仕組み」として語られることが多く、システム開発を発注する現場担当者の視点で整理された情報が少ないからです。ITGC・ITAC・J-SOXといった単語は聞いたことがあっても、要件定義書・契約書・受入テストのどこに落とし込むかまで体系的に理解している発注者は多くありません。結果として「ベンダーに丸投げしたい」と思っても、丸投げできる範囲と自社で決めるべき範囲の境目が見えないまま止まってしまいます。
本記事では、IT統制を「構築する側」ではなく「発注する側」の視点で整理し直します。IT統制の全体像（3カテゴリと4領域）を押さえたうえで、システム開発の各フェーズで何が起きるのか、要件定義書・RFP・契約書に何を書くべきか、監査対応でベンダーから何を受け取る必要があるかまで、発注者の実務で使える形で解説します。SaaS利用や外部委託時のSOC報告書の考え方、発注者が陥りやすい誤解もあわせて整理するので、読み終えたときには「次のベンダーミーティングで話す言葉」と「次に取るべきアクション」が見えている状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
IT統制とは何か 内部統制の中での位置づけ
IT統制の話に入る前に、それが「内部統制」という大きな枠組みの一部であることを押さえます。ここを飛ばすと、IT統制を単なる情シス業務の話と誤解しやすく、発注者としての当事者性を見失いやすくなります。
IT統制の定義と目的
IT統制とは、情報システムに関するリスク（不正アクセス、データ改ざん、システム障害、業務処理の誤りなど）を軽減し、財務報告の信頼性・業務プロセスの正確性を確保するための仕組みの総称です。金融庁「財務報告に係る内部統制の評価及び監査に関する実施基準」およびその実務指針でも、IT統制は財務報告に係る内部統制の中で重要な位置づけを持つとされています（金融庁 実施基準の改訂について（意見書））。
つまりIT統制の目的は「システムを止めないこと」ではなく、「システムを使って業務を行う際に、間違いや不正が起きにくく、起きたら気付ける状態を作ること」です。この目的から逆算すると、システム開発時に何を要件化すべきかが見えてきます。
内部統制の6要素のうちの「ITへの対応」がIT統制
内部統制の基本的な枠組みは、①統制環境、②リスクの評価と対応、③統制活動、④情報と伝達、⑤モニタリング、⑥ITへの対応、の6要素で構成されます（金融庁「財務報告に係る内部統制の評価及び監査の実施基準」）。IT統制はこの6要素目「ITへの対応」に該当します。
ここで重要なのは、IT統制が独立して存在するのではなく、他の5要素と連動する仕組みだという点です。たとえば「経理担当者が自分で入力・自分で承認できない」という統制活動（③）を実現するために、システム側で権限分離を実装する必要があり、これがIT統制の一部になります。発注者が「業務側の要件」と「システム側の要件」を分けて考えがちなのは自然ですが、統制の観点では両者は連続しています。
IT統制と隣接する「ITガバナンス」や情報セキュリティ側の全体像もあわせて押さえておきたい方は、ITガバナンスとは？発注者が知るべき情報セキュリティ基礎も参考にしてください。発注者視点でセキュリティとガバナンスの位置づけを整理した記事です。
対応が必要な企業と法制度
IT統制対応が明確に求められるのは、主に以下の企業です。
- 上場企業: 金融商品取引法（J-SOX）に基づき、内部統制報告書の提出が義務付けられています
- IPO準備企業: 上場申請時に内部統制の整備・運用状況を証券取引所・監査法人に評価されます
- 上場企業の連結子会社: 親会社の内部統制評価の対象範囲に含まれる場合、実質的に対応が求められます
- 上記に該当しない企業: 法定義務はないものの、業務ミス・情報漏洩リスクの軽減、取引先からの要請、監査対応などの観点から自主的に整備するケースが増えています
2023年4月には内部統制報告制度が改訂され、経営者による評価の対象範囲の見直しや、ITの利用（クラウド、SaaS、AI含む）に対する統制の考え方が明確化されました。改訂の詳細は経済産業省「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）令和6年12月25日改訂版」で示されています（経済産業省 システム管理基準 追補版）。
発注担当者にIT統制が関係する理由
「IT統制は情シスの仕事」と考えがちですが、発注担当者が無関係でいられない理由が3つあります。
第一に、システム開発の要件定義段階でIT統制の観点を織り込まなければ、後付けでの対応は極めてコストが高くつきます。第二に、外部委託した場合でも発注者の統制責任は消えません。委託先の選定・監督は発注者側の責任として残ります（この点は後述します）。第三に、監査法人が最終的に確認するのは「開発された成果物」ではなく「発注時点の意思決定と証跡」です。RFP・契約書・議事録に統制の考え方が現れていなければ、監査で説明できません。
つまりIT統制は、情シスに丸投げできる技術論ではなく、発注者が意思決定の一部として扱うべきテーマです。
IT統制の3カテゴリと4領域 発注者が押さえる論点整理
ここからは、IT統制の中身を発注者視点で整理していきます。ベンダーとの会話で「ITGCと言われてもピンと来ない」状態から、「変更管理はここ、アクセス管理はここ」と切り分けられる状態を目指します。
3カテゴリの全体像
IT統制は、金融庁の実施基準および経済産業省「システム管理基準 追補版」で3つのカテゴリに整理されています。
カテゴリ | 対象 | 発注者から見た性質 |
|---|---|---|
IT全社的統制 | 会社全体のITガバナンス（IT戦略・IT組織・情報セキュリティ方針・全社的な規程類） | 個別開発案件よりも、社内規程・ポリシー策定の話 |
IT全般統制（ITGC: IT General Controls） | 個々のシステムを横断して支える基盤的な仕組み（アクセス管理・変更管理・開発/導入管理・運用管理） | システム開発の発注で最も影響を受ける領域 |
IT業務処理統制（ITAC: IT Application Controls） | 個別の業務システムに埋め込まれる統制（入力チェック・処理の正確性・出力の完全性） | 業務ロジックの一部として要件定義に組み込む |
発注者として最も意識すべきなのはITGCです。理由は、ITGCがシステムの信頼性を支える基盤であり、監査法人が「まずここが整備されているか」を確認するためです。ITGCが不十分だと、その上に載るITACの信頼性も担保できないと判断されます。
ITGCの4領域と発注プロジェクトへの関わり
ITGCは以下の4領域で構成されるのが一般的です（LASSICの解説記事および経済産業省「システム管理基準 追補版」）。それぞれが発注案件のどの局面に関わるかを整理します。
ITGCの4領域 | 内容 | 発注プロジェクトでの関わり |
|---|---|---|
アクセス管理 | 誰が何にアクセスできるかの管理。ID発行・権限付与・棚卸し・退職者アカウント削除 | 権限マスタ設計、承認フロー、監査ログ実装 |
変更管理 | プログラム・設定変更を承認・記録する仕組み | リリース手順、開発/本番環境の分離、変更申請フロー |
開発/導入管理（システム開発・変更） | 新規開発・大規模改修時の要件定義・設計・テスト・移行の統制 | 開発プロセス全体（発注時点で最も強く関わる領域） |
運用管理 | 日次運用（ジョブ実行・バックアップ・障害対応） | 運用手順、バックアップ設計、障害エスカレーション定義 |
新規システム開発の発注時は、この4領域すべてが要件に反映されます。特に「開発/導入管理」は開発プロジェクトそのものの進め方を規定するため、発注者側の受入基準・意思決定プロセスとして早い段階で決めておく必要があります。
ITACはシステムに埋め込まれる統制
ITACは、業務システム内部の統制です。具体例を挙げると次のようなものが該当します。
- 入力データの妥当性チェック（必須項目・桁数・コード体系）
- ワークフロー承認（申請→上長承認→経理承認）
- 金額計算の正確性（消費税計算・按分ロジック）
- 権限による表示・操作の制御
- 出力データの整合性チェック（明細と合計の一致）
ITACは業務要件の一部として要件定義書に書き込みます。「IT統制対応」と一括りにせず、「経費申請の承認フロー」「請求データの入力チェック」といった業務要件の形で整理するのがコツです。
どの領域を自社で決め、どこをベンダーに任せるか
発注者が最初に迷うのが「どこまで自社で決めて、どこからベンダーに任せるか」の切り分けです。おおまかな目安は次のとおりです。
- 自社が主体的に決めるべきこと: 誰がどの権限を持つべきか（権限設計）、承認フローの階層、監査対応で必要な保存期間、業務プロセスに埋め込むチェックの内容
- ベンダーに任せる／協働で詰めるべきこと: 権限設計を実現する技術的な実装、環境分離の設計、ログ取得の技術仕様、バックアップ・リストア方式
- 自社とベンダーで合意して文書化すべきこと: 統制項目のテスト計画、監査法人向けエビデンスの提出タイミング、運用開始後の変更管理フロー
「業務判断は自社、技術実装はベンダー、その境界の設計は協働」と考えると整理しやすいでしょう。この切り分けを、次に見ていくシステム開発フェーズごとに具体化します。
IT統制がシステム開発の発注に与える影響 フェーズ別の論点
IT統制対応が必要なプロジェクトは、通常のシステム開発と比べて何が違うのか。発注者の関心はここに集中します。この章では開発フェーズごとに、追加で発生する観点と成果物を整理します。
要件定義で追加される観点
要件定義段階で、業務要件・機能要件に加えて「統制要件」を明文化します。統制要件とは、内部統制の目的（財務報告の信頼性・業務の正確性）を満たすためにシステムが備えるべき性質です。具体的には以下のような項目です。
- 権限設計（役職・職務ごとの操作権限マトリクス）
- 承認フロー（申請・承認・却下の記録と権限分離）
- 監査ログ要件（誰が・いつ・何をしたかを追跡できる項目）
- データ保存要件（証憑としての保存期間・改ざん防止）
- 環境分離要件（開発・検証・本番の分離とデータ授受のルール）
要件定義書のセクションとして「統制要件」の章を独立させると、後工程のレビュー・監査対応で参照しやすくなります。監査法人は要件定義書を「意思決定の起点」として確認するため、ここで明記されていない要件は「発注者が意識していなかった」と判定される可能性があります。
要件定義書全体の書き方や記載項目の全体像に不安がある場合は、要件定義の進め方ガイドを土台にしたうえで、その上に「統制要件」の章を追加する形で整理すると抜け漏れを防ぎやすくなります。
設計・開発で求められる証跡
設計・開発フェーズでは、成果物そのものだけでなく、それを作った過程の証跡が重要になります。ベンダーに求めるべき典型的な証跡は次のとおりです。
- 設計レビュー記録（レビュー実施日・レビュアー・指摘事項・対応結果）
- コードレビュー記録（プルリクエスト履歴、レビュアー承認記録）
- ソースコードのバージョン管理履歴
- 開発環境のアクセス権限一覧（開発者ごとの権限、退職者の削除記録）
これらの証跡は、監査法人が「変更管理が適切に運用されているか」を確認する際の根拠になります。ベンダー側が普段から実施している開発プロセスであっても、監査対応可能な形式で残されていない場合があるため、契約時に成果物として明示することが重要です。
テストで求められるIT統制関連項目
テストフェーズでは、通常の機能テスト・性能テストに加え、統制項目のテストを実施します。
- アクセス権テスト: 権限マトリクスに沿って、権限のないユーザーが操作できないことを確認する
- 業務処理統制のテスト（ITACテスト）: 入力チェック・承認フロー・計算ロジックが仕様どおり動作することを確認する
- 監査ログテスト: 想定した操作がログに正しく記録され、後から追跡できることを確認する
- 異常系のテスト: 権限外の操作、想定外の入力に対して適切にエラーが返ることを確認する
これらのテスト結果は、監査で「システムが仕様どおり動作している」ことの証跡になります。テスト計画書・テスト結果報告書として文書化し、監査対応時に提示できる形で保管します。
移行/リリースで求められる変更管理
本番リリースは、変更管理（ITGCの中でも監査法人が特に厳しく見る領域）の代表的な場面です。以下の点を発注時に決めておきます。
- 環境分離: 開発・検証・本番環境を物理的または論理的に分離し、権限も分ける
- 本番反映の承認: 誰の承認をもって本番反映を実施するか（承認者・承認方法・承認記録の保管）
- リリース記録: 何を・いつ・誰が・どの手順で反映したかの記録
- 緊急変更の扱い: 通常のリリースフローを踏めない緊急対応時のルール（事後承認・記録要件）
「開発者が直接本番環境にアクセスしてコードを差し替えられる状態」は、監査法人が最も厳しく指摘するアンチパターンです。環境分離とリリース手順は、要件定義書ではなく契約書・SLAレベルで合意することを推奨します。
運用開始後にベンダーが提供すべき統制関連の運用支援
リリース後の運用フェーズでは、以下のような統制関連の運用支援をベンダーとの契約に含めることを検討します。
- 定期的なアカウント棚卸しの支援（退職者・異動者の反映）
- 障害対応記録の提供（発生日時・原因・対応内容・再発防止策）
- バックアップ・リストア実施記録の提供
- 変更管理記録（本番反映履歴）の提供
- 監査法人からの質問対応（証跡提供・技術説明）
運用開始後にベンダーからの情報提供が滞ると、監査対応時に発注者側で情報を集められず立ち往生します。「運用支援の内容」を保守契約・SLAで具体的に定めておくことが、監査対応コストを抑える鍵になります。
発注時に決めるべきIT統制要件チェックリスト
ここまでで、IT統制の全体像と開発フェーズごとの論点を整理しました。この章はこの記事の中心的な成果物として、明日ベンダーとの打ち合わせで使えるチェックリストを提示します。ITGCの4領域それぞれで、RFP・要件定義書・契約書に含めるべき項目を具体化します。
アクセス管理に関する発注時要件
チェック項目 | 発注時に指定すべき内容 |
|---|---|
権限設計 | 役職・職務単位の権限マトリクス、権限分離の原則（申請者と承認者の分離） |
ID発行・削除フロー | 新規発行の承認者、削除タイミング（退職・異動即日）、削除記録の保管 |
パスワードポリシー | 最小桁数、複雑性要件、有効期限、多要素認証の適用範囲 |
特権ID管理 | 管理者権限の利用申請・承認、利用時のログ取得、定期的な棚卸し |
アカウント棚卸し | 実施頻度（四半期・半期）、実施主体、棚卸し記録の保管 |
監査ログ | 取得対象（ログイン・データ変更・権限変更）、保存期間、改ざん防止 |
監査法人からの指摘が最も多いのは「退職者アカウントが放置されている」「特権IDが共有されている」「棚卸しが実施されていない」の3点です。この3点は発注時に契約書レベルで明記することを推奨します（AIMコンサルティングの監査法人指摘ポイント記事も参考になります）。
変更管理に関する発注時要件
チェック項目 | 発注時に指定すべき内容 |
|---|---|
変更申請フロー | 申請者・承認者・実施者の分離、承認記録の保管方式 |
環境分離 | 開発・検証・本番環境の分離、各環境のアクセス権限 |
リリース手順 | リリース実施者、リリース記録の内容（何を・いつ・どの手順で） |
緊急変更の扱い | 事後承認のルール、記録要件、翌営業日の報告方式 |
ソースコード管理 | バージョン管理ツールの利用、リリース履歴とバージョンの紐付け |
リリース前テスト | 検証環境での動作確認、テスト結果の記録 |
「開発者が本番環境に直接アクセスできない構成にする」ことは、監査法人が変更管理を評価する際の最重要ポイントです。この点は要件定義書ではなく契約書・設計方針として明記し、運用フェーズでも維持することを合意します。
開発/導入管理に関する発注時要件
チェック項目 | 発注時に指定すべき内容 |
|---|---|
開発標準 | 適用するコーディング規約・レビュー基準、標準逸脱時の記録 |
要件・設計文書 | 要件定義書・基本設計書・詳細設計書の作成、レビュー実施記録 |
テスト計画 | 単体・結合・受入テストの範囲、統制項目のテスト計画 |
テスト結果 | テスト実施記録、不具合対応記録、再テスト実施記録 |
受入基準 | 発注者側の受入基準（統制項目の充足状況を含む）、受入判定記録 |
移行判定 | 本番移行の判定基準、判定会議の議事録 |
「開発/導入管理」は、監査法人が「新規開発時のプロセスが適切だったか」を後から評価する際の中心領域です。プロジェクト完了時点で書類が揃っていない場合、後から作り直すことは事実上不可能なため、発注時にベンダー成果物として明示することが重要です。AIMコンサルティングのシステム開発・変更に関するITGC評価解説にも、監査法人がどのような視点で評価するかが具体的にまとめられています。
運用管理に関する発注時要件
チェック項目 | 発注時に指定すべき内容 |
|---|---|
ジョブ管理 | 定期ジョブの実行スケジュール、実行結果のログ、異常時の通知 |
障害対応 | 障害対応フロー、記録要件、エスカレーション基準 |
バックアップ | バックアップ対象・頻度・保管場所、リストアテストの実施頻度 |
監視 | 監視項目、通知先、監視ログの保管期間 |
定期棚卸し | アカウント・権限の棚卸し支援、棚卸し結果の記録 |
保守運用の記録 | 保守作業ログ、変更履歴、監査法人向けの説明資料提供体制 |
運用管理は、リリース後の「継続的な統制の運用」を担保する領域です。ここが弱いと、リリース時点では統制が機能していても、時間の経過とともに実態が形骸化します。運用契約（保守契約・SLA）の中で具体的に定めることを推奨します。
契約書に盛り込むべき統制関連条項
要件定義書だけでなく契約書にも、以下の条項を含めることを検討します。
- 秘密保持義務: 開発中に発注者側の業務情報・データにアクセスする前提のため、秘密保持の範囲・違反時の措置を明記
- 再委託制限: 再委託の可否・事前承認要件・再委託先の管理責任
- 監査協力義務: 発注者の監査法人からの質問対応、証跡提供の義務
- 成果物の権利帰属: ソースコード・ドキュメント・データの権利関係
- 保守期間中の統制対応: 保守フェーズでの証跡提供、棚卸し支援
- 契約終了時のデータ引き渡し: 開発データ・ログ・設定情報の引き渡し方式
契約書は、監査法人が「委託先管理の適切性」を評価する際の直接的な証跡になります。要件定義書とは別に、契約書レベルでも統制関連条項を明記することが重要です。IT開発の基本契約書に何を盛り込むべきかの土台については、IT基本契約とはにまとめています。基本契約の一般論を押さえたうえで、上記の統制関連条項を追加していく手順を推奨します。
監査対応で必要になるベンダー提出物と証跡設計
システム開発が完了した後、監査法人からの評価・指摘に対応するフェーズが必ず来ます。ここで「ベンダーから何を受け取っていれば対応できるか」を、開発時点から逆算して設計しておくことが、監査対応コストを大きく左右します。
監査法人が求める典型的な証跡と発注時の準備
監査法人が確認する典型的な証跡と、発注時にベンダー成果物として指定すべき内容を整理します。
監査法人が確認する内容 | 必要な証跡 | 発注時の準備 |
|---|---|---|
要件定義・設計プロセスの適切性 | 要件定義書・基本設計書、レビュー記録、承認記録 | 成果物リストに明記、レビュー記録の保管方式を合意 |
テストの十分性 | テスト計画書、テスト結果報告書、不具合対応記録 | 統制項目のテストをテスト計画に含める、結果報告書のフォーマットを合意 |
本番移行の承認 | 移行判定会議議事録、リリース申請書、リリース記録 | 承認フローと記録形式を契約に明記 |
アクセス管理の運用状況 | 権限一覧、棚卸し記録、退職者アカウント削除記録 | 棚卸し支援・記録提供を運用契約に含める |
変更管理の運用状況 | 変更申請・承認記録、リリース履歴 | 変更管理ツールの選定、記録の保管期間を合意 |
障害対応の状況 | 障害対応記録、原因分析、再発防止策 | 障害対応記録のフォーマットと提出タイミングを合意 |
証跡設計で最も重要なのは「保存期間」と「改ざん防止」です。監査対応は年度をまたぐケースがあり、期末時点で提出できる状態を維持する必要があります。ベンダー側のシステムに証跡が保管されている場合、契約終了後もアクセスできる状態を確保する条項を入れておく必要があります。
監査法人からよく指摘される4つの落とし穴
監査法人が指摘する典型的な問題点として、以下の4つが挙げられます（前掲AIMコンサルティングの監査指摘ポイントも参照）。発注時にこの4点を事前に対策することで、リリース後の追加対応を大幅に減らせます。
1. アクセス管理の棚卸し漏れ 最も多い指摘です。退職者・異動者のアカウントが放置され、監査時に「削除されるべきアカウントがまだ有効」と判明するケース。運用契約に棚卸し支援を明記し、四半期ごとの実施を義務化することで防ぎます。
2. 変更管理記録の欠落 本番リリース時の承認記録・実施記録が残っていない、または承認者と実施者が同一人物のケース。変更管理ツールの選定と、承認フローの権限分離を要件定義書レベルで明記します。
3. 環境分離の曖昧さ 開発者が本番環境に直接アクセスできる、開発環境と本番環境で同じアカウントが使えるケース。環境分離の設計方針を、契約書に明記します。
4. 外部委託先の管理不備 ベンダー側の統制状況を発注者が把握していないケース。SOC報告書の取得または委託先評価を、契約条項として明記します（SOC報告書については次章で詳述します）。
これらは開発完了後に「後付けで対応する」のが最もコストが高い項目です。要件定義書・契約書のレビュー段階で、上記4点が対策されているかを必ず確認しましょう。
開発ベンダーとの間で決めておく成果物リストと保存期間
監査対応のための成果物リストを、契約締結前に合意しておくことを強く推奨します。以下は最低限含めるべき項目の例です。
成果物 | 提出タイミング | 保存期間の目安 |
|---|---|---|
要件定義書・設計書 | フェーズ完了時 | 契約終了後も引き継ぎ、少なくともシステム利用期間中 |
レビュー・承認記録 | 各フェーズ完了時 | 監査対応期間（通常5年以上） |
テスト計画書・結果報告書 | テスト完了時 | 監査対応期間（通常5年以上） |
リリース記録 | リリース都度 | 監査対応期間（通常5年以上） |
障害対応記録 | インシデント発生都度 | 監査対応期間（通常5年以上） |
アクセス権限一覧・棚卸し記録 | 定期棚卸し実施都度 | 監査対応期間（通常5年以上） |
保存期間は業種・企業ごとに異なる場合があるため、監査法人・法務部門と確認したうえで確定します。「証跡が存在しない」ではなく「発注者側でいつでも取り出せる」状態を維持することが重要です。
外部委託 SaaS利用時のIT統制 SOC報告書と受託先管理
システム開発を外部に委託する、あるいはSaaSに切り替える場合、「委託先や外部サービスのIT統制はどう確認すればよいか」という論点が発生します。ここは発注者が最も不安を感じる領域の一つですが、SOC報告書という業界標準の仕組みで対応できます。
外部委託しても残る発注者の責任
繰り返しますが、開発や運用を外部委託しても、発注者側の統制責任は消えません。金融庁「財務報告に係る内部統制の評価及び監査の実施基準」でも、「委託業務に係る統制の評価は、委託会社（発注者）の経営者が実施する責任を負う」旨が示されています（金融庁 実施基準の改訂について（意見書））。
発注者に残る責任の主なものは次のとおりです。
- 委託先の選定責任（統制状況を評価したうえで選定したか）
- 委託先の監督責任（委託中に統制状況を継続的に確認しているか）
- 委託先の変更・終了時の責任（データ引き渡し・アカウント削除の確認）
- 委託先障害時の業務継続責任（BCP・代替手段の準備）
「委託した以上、責任もベンダーに移る」わけではないという原則を、まず押さえる必要があります。
SOC1（財務報告向け）とSOC2（セキュリティ向け）の使い分け
委託先のIT統制を発注者が自ら評価するのは現実的でない場面が多く、その代替手段として広く利用されているのがSOC報告書です。SOC報告書は米国公認会計士協会（AICPA）が定めた基準に基づく監査報告書で、日本国内では日本公認会計士協会の保証業務基準に沿ったSOC報告書も利用されています。主に以下の2種類があります。
報告書 | 対象 | 発注者側の主な用途 |
|---|---|---|
SOC1 | 財務報告に関連する統制 | 委託先が財務報告に関わる場合（会計SaaS、決済代行、給与計算アウトソースなど） |
SOC2 | セキュリティ・可用性・処理の完全性・機密性・プライバシー | 顧客情報・機密情報を扱うクラウドサービス全般（SaaS、クラウドインフラ） |
さらに、報告書は「Type 1（ある時点での統制設計）」と「Type 2（一定期間の運用状況）」に分かれます。監査対応で本格的に使えるのはType 2です。ベンダー選定時に「SOC1 Type 2」または「SOC2 Type 2」の報告書提供可否を確認します。
SOC報告書と並んで、ベンダー選定時の評価軸になるのがISMS（ISO/IEC 27001）認証です。開発ベンダーがISMSを取得していることが発注者側にどのようなメリットをもたらすかは、ISMS認証取得の開発会社に発注する5つのメリットにまとめています。SOC報告書と組み合わせて、委託先の統制水準を評価する材料にしてください。
Bridge Letter とレポート取得タイミングの実務
SOC報告書の対象期間と発注者側の決算期がずれている場合、そのギャップを埋めるための文書がBridge Letter（ブリッジレター）です。「SOC報告書の対象期間終了以降、決算期末までの間に統制状況に重要な変更がない」ことを、ベンダーが記載する文書です。
実務上のポイントを整理します。
- SOC報告書の対象期間はベンダー側で決まっているため、発注者側の決算期と一致しない場合がある
- 発注者側の決算期末までのカバーが必要な場合、Bridge Letterをベンダーに発行してもらう
- Bridge Letterの発行可否・費用・タイミングを契約時に確認しておく
- 監査法人が「Bridge Letterが必要」と判断するかは、事前に監査法人と協議する
「SOC報告書があるから安心」ではなく、「発注者側の決算・監査スケジュールに整合する形で入手できるか」まで確認することが重要です。
SaaS切替時に確認する統制ポイント
オンプレシステムからSaaSへの切替、あるいは新規SaaS導入時に確認すべき統制ポイントを整理します。
- SOC報告書の取得可否: SOC1・SOC2のType 2を提供できるか、Bridge Letter発行可否
- ISMS認証（ISO/IEC 27001）: 情報セキュリティ管理体制の第三者評価
- データ所在地・データ主権: どの国のデータセンターで保管されるか、法的枠組み
- アクセス管理機能: 権限設計の柔軟性、多要素認証、監査ログの取得
- バックアップ・可用性: バックアップ頻度、リストア方式、SLA（稼働率保証）
- 契約終了時のデータ引き渡し: どの形式でデータを引き渡してもらえるか
SaaSは「導入コストが低く早く使える」反面、「発注者側でカスタマイズできない範囲」が広がるため、選定時点の統制評価が特に重要です。導入決定前に、上記項目を確認したうえで意思決定することを推奨します。
発注者が陥りやすい誤解と失敗パターン
最後に、IT統制に関する発注者側のよくある誤解を整理します。ここまで読んだ知識を実務に落とし込むための、最後の足場です。
「IT統制対応済」でベンダーに通じない理由
「次のシステム開発ではIT統制対応済でお願いします」という依頼は、ベンダー側で受け止めきれません。理由は、IT統制が3カテゴリ・4領域からなる幅広い概念であり、案件ごとに求められる対応レベルが違うからです。
たとえば「アクセス管理の権限設計をどこまで細かく定義するか」「変更管理でどこまでの承認記録を残すか」は、発注者側の業務・監査要件によって変わります。ベンダーは「発注者が何を求めているか」を仕様として受け取らなければ提案できません。
発注時は「IT統制対応済」ではなく、「アクセス管理では権限マスタを役職単位で設計し、四半期に1度の棚卸しに対応できるようにしてほしい」といった具体的な要件として伝えます。前章のチェックリストがそのまま伝達フォーマットとして使えます。
情シスに任せきりにできない業務側の役割
「IT統制は情シスの領域」という感覚は、部分的には正しいものの、業務側が関わらなければ機能しません。理由は次のとおりです。
- 権限設計は「業務上、誰がどの操作をすべきか」の判断が必要で、これは業務側でしか決められない
- 承認フローは「誰の承認をもって取引が確定するか」の業務ルールで、業務側の設計判断
- 業務処理統制（ITAC）は業務ロジックそのもので、業務要件の一部
- 監査対応時の質問は業務プロセスに及ぶため、業務側の理解と説明責任が発生する
情シスが「IT統制の仕組み」を作るとしても、「その仕組みで守るべき業務プロセス」を定義するのは業務側の責任です。両者の連携なしにIT統制は成立しません。
SaaS利用でも消えない発注者の統制責任
「SaaSを使えば統制はベンダー側で対応してくれるから、発注者は考えなくてよい」という誤解も根強く見られます。実際には次の責任が残ります。
- SaaSの選定責任(統制状況の評価、SOC報告書の確認)
- SaaS内の権限設計・運用（ユーザー登録・削除、権限付与）
- SaaSと自社業務プロセスの整合性確認
- SaaS障害時の業務継続対応
- SaaS契約終了時のデータ移行・削除確認
SaaSは「統制の一部を委託する仕組み」であって、「統制責任を移転する仕組み」ではありません。この理解のズレが、監査指摘の温床になります。
次に取るべき3つのアクション
ここまで読んだ内容を、明日から動ける形にするための3つのアクションを提案します。
アクション1: 現状把握 現在発注中または発注予定のシステム案件について、要件定義書・契約書を確認し、本記事で示したチェックリスト（アクセス管理・変更管理・開発/導入管理・運用管理）が明記されているかをレビューします。抜けがある項目を洗い出し、次工程での追加検討事項として整理します。
アクション2: RFP・要件定義書テンプレートの改訂 今後の発注に備えて、RFP・要件定義書のテンプレートに「統制要件」の章を追加します。本記事のチェックリストを社内向けに整理し、案件ごとに必要な要件を選択して明記できる形式にします。
アクション3: 監査法人・内部監査室への事前相談 新規開発を発注する前に、監査法人または内部監査室に「この案件で求められる統制水準」を事前確認します。監査法人からの後出し指摘で手戻りが発生するのを防ぐには、発注前の事前相談が最も効果的です。
IT統制は、発注者が「情シス任せ」から「発注者としての当事者性」に立ち位置を切り替えることで、ベンダーとの会話がかみ合い、監査対応がスムーズになる領域です。本記事のチェックリストが、その最初の一歩の道具として役立てば幸いです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 「IT統制対応済でお願いします」とベンダーに伝えるのがなぜNGなのか、代わりに何を伝えればよいですか？
IT統制はアクセス管理や変更管理など複数の領域にまたがる概念で、案件ごとに求められる対応レベルも異なるため、抽象的な依頼だけではベンダー側が仕様に落とし込めません。伝える際は「誰にどの権限を与えるか」「変更をどう承認・記録するか」といった論点を領域ごとに切り分け、自社の業務ルールに沿った水準（例: 人事異動の頻度に応じた権限見直しサイクルなど）まで具体化して提示すると、ベンダーは要件として受け止めやすくなります。
- 上場していない中堅企業でもIT統制対応は必要ですか？
法定義務が生じるのは上場企業・IPO準備企業とその連結子会社に限られますが、対応要否は「義務があるか」よりも「取引先や親会社からどの程度の水準を求められているか」で判断するのが実務的です。今のところ指摘がなくても、今後上場企業との取引拡大や資金調達を見込んでいるなら、権限管理や変更記録の仕組み化といった簡易的な整備を先回りで進めておくと、急な要請にも慌てず対応できます。
- SaaSを導入する場合、SOC報告書を提出できないベンダーはどう判断すればよいですか？
SOC報告書がなくても即NGではありませんが、ISMS（ISO/IEC 27001）認証の有無や、権限管理・監査ログ・データ引き渡し方式など統制ポイントを個別に確認する必要があります。財務報告に関わる委託先（SOC1対象）ほど代替手段での評価が難しくなるため、監査法人と事前に相談してください。
- IT統制対応を要件に含めると、開発の期間やコストはどの程度増えますか？
権限設計・監査ログ実装・変更管理フローの整備などが追加されるため、通常開発より工数は増えますが、具体的な増分は要件の範囲（4領域のどこまで対応するか）によって大きく変わります。要件定義段階でチェックリストを基に必要な項目を絞り込み、ベンダーに見積を依頼するのが実務的です。
- 監査法人への事前相談はどのタイミングで行うべきですか？
目安は、対象業務・想定システム・扱うデータの機微度など案件の概要が固まった、要件定義に着手する直前です。この段階で相談すれば、期待される統制水準を要件定義に反映できます。相談時は案件概要と想定スケジュールを簡単なメモにまとめて持参すると、監査法人側も具体的な回答をしやすくなります。要件定義書が完成してから相談すると、指摘内容によっては構成の作り直しが必要になるため避けましょう。
