外部委託先管理とは、業務やシステム開発を外部に任せるときに、委託先の仕事が適切に行われていることを委託元が確かめ、その記録を残す取り組みです。
IT全般統制の監査では、委託先が何をしているかだけでなく、委託元がそれをどう確かめたかが見られます。委託先に任せていても、監査人に説明するのは委託元です。
この記事では、SOC1レポートがない委託先、特にシステム開発を任せている委託先を中心に、外部委託先管理で委託元が残す記録を、選定から稼働後まで整理します。
この記事を読んでわかること
- 外部委託先管理とは何か、開発を任せても責任が委託元に残る理由
- SOC1レポートの有無で変わる、IT全般統制での確かめ方
- システム開発の外部委託で委託元が決めておく3つのこと
- 稼働後に委託元が持つ記録と、残す証跡の一覧
外部委託先管理とは何か。開発を任せても責任が委託元に残る理由
「委託先管理」は、情報漏えいを防ぐセキュリティの文脈で使われることが多い言葉です。個人情報や機密情報を預ける相手のリスクを、質問票や評価シートで確かめる取り組みがこれにあたります。
一方、IT全般統制で問われる外部委託管理は、確かめる対象が少し違います。こちらでは、財務報告に使うシステムや処理を任せている委託先について、その仕事が正しく行われていることを委託元が確かめているかどうかが問われます。
外部委託先の責任の所在について、内部統制基準の実施基準は次のように書いています。
委託業務に関しては、委託者が責任を有しており、委託業務に係る内部統制についても評価の範囲に含まれる。
委託先は、契約の範囲で作業を引き受けている立場です。システムが業務の要件を満たしているか、会計のデータを正しく扱っているかを最終的に説明するのは本来は委託元です。そのため、監査で変更管理やアクセス管理の不備が見つかったときに「委託先がやっていたので分かりません」とするのでは説明にはなりません。自社できちんと外部委託先の成果を検証する必要があります。
IT全般統制の外部委託先管理は、SOC1レポートの有無で確かめ方が変わる
実施基準は、ITに係る全般統制の具体例の一つに「外部委託に関する契約の管理」を挙げています。IT全般統制を変更管理・運用管理・アクセス管理・外部委託管理の4つの領域で整理したときの、最後の領域にあたります。全体像は「IT全般統制(ITGC)とは?4つの領域・実務対応・監査対策」で解説しています。
外部委託先管理の最初の作業は、財務報告に関わる委託先を書き出すことです。会計や給与のクラウドサービス、サーバーの保守業者、システムの受託開発会社などが対象になります。書き出してみると、確かめ方は委託先によって大きく2つに分かれます。

ただし、SOC1レポートは入手すれば足りる書類ではありません。SOC1レポートが保証しているのは、委託先の内部統制のうち、レポートの範囲に入った部分だけです。そのため、中身を読んで、カバーできていることとできていないことを分ける必要があります。たとえば、次のような部分はSOC1レポートではカバーできません。
- 自社の担当者が行っている統制(会計システムのユーザーIDの発行・削除・権限変更を自社で管理している場合など)
- 委託先が委託元側で行うと想定している統制(IDの変更作業は委託先が行っても、依頼が正当かどうかを自社で確認している場合など)
- レポートの対象外のサービスや機能(自社向けにカスタマイズした部分など)
- レポートの対象期間の外(対象期間が12月末までで自社が3月決算なら、1月から3月まで)
レポートに例外事項が記載されている場合は、自社の評価にどの程度影響するかも確かめます。
SOC1レポートがある委託先の見方は「SOC1レポートとは?SOC2との違いと、IT全般統制で見るSOCレポートの見方」で解説しています。難しいのは、SOC1レポートがない委託先です。第三者からの報告書がないので、委託元がどのように評価をしたのかを説明する必要があります。
委託先の数が多い会社は、1社1行の一覧にしておくと、外部委託先管理のチェックシートとして整理しやすくなります。
システム開発の外部委託で、委託元が決めておく3つのこと
SOC1レポートがない委託先の例として、システム開発を委託している開発会社が挙げられます。実施基準は、委託業務の例として「情報システムの開発・運用・保守などITに関する業務を外部の専門会社に委託する場合」を挙げています。監査人が確認する点には、システムの開発や調達について事前に所定の承認を得ていること、その過程が適切に記録及び保存されていることなどが含まれます。そこで、委託元が決めておくことを3つに分けて整理します。
なお、開発の外部委託の留意点は、日本公認会計士協会東京会テクノロジー委員会の研究報告書「公認会計士のためのQAで学ぶテクノロジー」(2024年6月)でも整理されています。
委託先を比較して、選んだ理由を残す
委託先の選定では、過去の実績や技術的な能力を確かめたうえで、複数の候補を比べます。委託元がやっておきたいのは、次の4つです。
- 候補先の比較リストを作り、選んだ理由を残す
- 具体的な成果を確認する日(マイルストーン)をあらかじめ決める
- システム化計画やプロジェクトの体制図で、委託元と委託先それぞれの役割と責任を明らかにする
- RFP(提案依頼書)を作り、候補先に同じ条件で提案してもらう
比較リストと選定理由を残しておくと、なぜこの委託先を選んだのかを後から説明できます。あわせて、委託の範囲と作業の範囲を具体的に定め、文書に残します。
会計に関わる要件は経理が確認をする
要件定義では、システムに求める機能や情報を明らかにし、ユーザーや利害関係者の承認を踏まえて確定します。受入れでは、要件定義で決めた機能や情報を満たしているかを検証し、利害関係者が承認します。実施基準も、監査人が留意する点として次のことを挙げています。
新たなシステム、ソフトウェアの導入に当たり十分な試験が行われ、その結果が当該システム、ソフトウェアを利用する部門の適切な管理者及びIT部門の適切な管理者により承認されていること
財務報告に関わるシステムであれば、経理も利用する部門として確認に加わる必要があります。受入れの確認が足りないと何が起きるかは、2025年に開示された2社の例が参考になります。開示資料は委託先との関係には触れていませんが、どちらも新しい基幹システムを導入した場面の話です。
キーコーヒーは、2025年1月に導入した基幹システムで、自社倉庫間を移動した商品・製品が入庫済みなのに積送中在庫としても計上され、在庫金額が過大になりました。受入検証は行っていましたが、入荷側の帳簿在庫の動きを確認する一方で、出荷側の積送中在庫の減少の確認が漏れていました。同社は要因として、確認する項目をシステム開発担当者(IT部門)が決めており、ユーザー部門(物流部門)とのダブルチェック体制がなかったこと、財務会計への反映状況を網羅的に検証できていなかったことを挙げています。
ツインバードは、2024年12月に導入した基幹システムで、導入前のシステムテストにおける原価計算と関連データの連携機能の検証手続が不十分でした。本番稼働後に原価計算の結果に一部不整合が発生し、システムの外で原価計算を行う暫定的な対応を取った結果、決算作業が遅延しました。あわせて、情報システム部門と財務経理部門で開発要件を理解した重要な担当者が退職し、適切な引継ぎがされなかったことも開示しています。
2社の開示からは、システムが動くかどうかだけでなく、会計の数字に正しく反映されるかまで確かめる必要があることを学べます。要件定義と受入れの承認は、開発の過程の記録として残します。事例の詳細は「内部統制報告書とは|システム要因の『有効でない』と判断される本当の理由」で解説しています。
委託先の設計書を社内でレビューする
開発上位者や品質管理担当のレビューで、委託先が作成した設計が適切かどうかを検証する体制を作ります。あわせて、開発の定例会議などで定期的にやり取りしながら、委託先の品質を確保します。レビューの結果も、開発の過程の記録として残します。
稼働後に委託先を管理するために、委託元が持つべき記録
外部委託先管理は、システムが稼働して終わりではありません。実施基準が挙げるITに係る全般統制には、システムの保守やアクセス管理も含まれます。保守や運用を同じ委託先に任せ続ける場合、委託元が押さえておきたいのは次の4つです。
変更の申請と承認の記録
保守を委託先が担う場合でも、システムの変更について事前に適切な管理者の承認を得ていること、その過程が適切に記録及び保存されていることが確認の対象になります。変更の申請と承認は委託元が行い、委託先の作業記録(チケットやプルリクエスト、リリースの記録)を委託元が見られるようにしておきます。進め方は「IT全般統制の変更管理|GitHubのプルリクエストが監査証跡になる仕組み」で解説しています。
委託先アカウントの棚卸
実施基準は、システムの安全性の確保として、適切なアクセス管理等の方針を定めているかの確認を挙げています。委託先の担当者が本番環境や会計システムにアクセスできる場合は、委託元もそのアカウントの一覧と権限を把握し、定期的に棚卸しします。棚卸しの手順は「アカウント棚卸とは?監査に通るやり方と証跡の残し方」にまとめています。
委託業務の結果の検証
委託業務が企業の重要な業務プロセスの一部を構成している場合、経営者は受託会社の内部統制の有効性を評価しなければなりません。実施基準は、評価の方法の例として次の2つを挙げています。
- 委託業務の結果の報告書と基礎資料の整合性を検証し、一部の項目を自社でも実施して検証する(例:給与計算で、委託した対象人数と受領した計算データの件数を比べ、無作為に抽出した一部を検算する)
- 受託会社から内部統制の評価結果を記載した報告書等を入手する(SOC1レポートはこの例にあたります)。その際、報告書等が十分な証拠を提供しているかを検討する
外部委託に関する契約の管理
監査人は、企業がITに係る業務を外部委託している場合、適切に外部委託に関する契約の管理を行っているかを検討します。実施基準は、契約に何を書くかまでは定めていません。実務上は、作業結果の報告や再委託の扱い、監査への協力など、委託先の作業を確かめるために必要な事項を契約で確認しておくとよいでしょう。
外部委託先管理で残す証跡の一覧
ここまでの内容を、確かめることと証跡の形でまとめます。「実施基準」の行は実施基準に挙げられている項目、「実務上の推奨」の行は基準に明記はないものの、残しておきたい記録です。自社の外部委託先管理に、どの記録が足りないかを確かめるときに使ってください。
受入れとリリースの段階は、自社開発の場合と同じです。詳しくは「リリース判定とは|本番移行の前に決めておく判定基準と、監査で見られる記録」で解説しています。
表のすべてを最初からそろえる必要はありません。まずは財務報告に関わる委託先を書き出し、1社ずつ「確かめた記録があるか」を見ていくところから始めるのが現実的です。
まとめ
外部委託先管理で問われるのは、委託先の優秀さではなく、委託元が確かめた記録です。SOC1レポートがない委託先では、選定の理由と委託の範囲、要件定義と受入れの承認、設計のレビューを形にしておきます。稼働後も、変更の記録、委託先アカウント、委託業務の結果の検証、契約の管理を委託元が押さえておくことで、自社で確かめた内容を監査人に説明できるようになります。
委託先を含めたIT全般統制の整え方に迷っているという方は、オントロジーへ気軽にご相談ください。
参考資料
- 「財務報告に係る内部統制の評価及び監査の基準」「財務報告に係る内部統制の評価及び監査に関する実施基準」(企業会計審議会)
- 研究報告書「公認会計士のためのQAで学ぶテクノロジー」(日本公認会計士協会東京会テクノロジー委員会、2024年6月)
- キーコーヒー株式会社「内部統制報告書の訂正報告書」(第73期)
- 株式会社ツインバード「財務報告に係る内部統制の開示すべき重要な不備に関するお知らせ」(2025年5月29日)