監査のたびに、経理が証跡をかき集めて承認印の押し漏れを目視で探し、規程と実態のズレを言い訳する。多くの会社で「内部統制」とは、この期末の手作業のことになってしまっている。だが本来、統制は人が頑張って守るものではなく、システムが勝手に効いている状態が理想だ。S/4HANAは、その「自動で効く統制」を組める基盤を持っている。鍵は、統制を分厚い規程文書で縛る発想から、証跡・承認ワークフロー・例外検知という仕組みに置き換えることだ。本稿は、その設計思想と現場での動かし方を具体的に示す。
なぜ「規程で守る統制」は監査で消耗するのか
内部統制報告制度（J-SOX。上場企業に財務報告の信頼性を担保する仕組みの整備・評価を求める制度）は、約15年ぶりに実施基準が改訂され、2024年4月1日以後に開始する事業年度の評価・監査から新基準が適用されている。改訂ではクラウドや外部委託先の統制評価に関する指針が加わり、評価範囲と証拠の整備負担はむしろ増えた（金融庁・PwC解説）。つまり「証跡をどう確保するか」は、これまで以上に重い論点になっている。
ここで多くの会社がつまずくのは、統制の実体を規程やマニュアルという文書に置いていることだ。文書は人が読んで人が守る前提なので、運用が形骸化する。承認は事後の押印で済まされ、職務分掌は「兼務はしないことになっている」という建前で回り、期末になって初めて、評価のために大量の証跡を手作業で集める。これは統制が「効いている」のではなく、「効いていたことを後から証明している」状態にすぎない。
J-SOXのIT統制は、IT全般統制（ITGC。システム全体を適切に運用管理する土台の統制）とIT業務処理統制（ITAC。個々の業務プロセスに組み込まれた統制）の2層で考える（IPO Compass）。発想の転換とは、このITACを「規程で人に守らせる」のではなく、システムの設定そのものとして埋め込み、ITGCで「その設定が勝手に変えられないこと」を担保することにほかならない。S/4HANAは、まさにこの2層をシステム機能で実装できる。
第一の柱――証跡を「集める」から「自動で残る」へ
統制の出発点は、誰が・いつ・何を・どう変えたかが、本人の意思と無関係に必ず記録されることだ。S/4HANAは会計伝票を原則として削除・上書きできない設計で、訂正は必ず逆仕訳という新たな記録として残る。マスタや設定値の変更も変更履歴（チェンジドキュメント）として誰が何を変えたかが保持され、設定の移送は変更プロジェクトとして全変更が追跡される（SAP Help Portal）。
ここで設計者が意識すべきは、「証跡は後で集めるもの」という前提を捨てることだ。証跡は業務が動いた瞬間に副産物として残るべきもので、経理が期末に取りに行くものではない。
具体的には次を最初の設計で決め切る。全項目を無差別に記録するとノイズで監査が読めなくなるため、財務数値に「効く項目」を絞るのが実務の勘所だ。
- 削除・修正の封じ込め：仕訳の物理削除や直接上書きを、権限とトランザクション設計で「そもそもできない」状態にする。逆仕訳と訂正理由の記録を唯一の訂正経路にする
- 変更履歴の有効化対象を先に決める：勘定科目マスタ・取引先マスタ・支払条件・為替レートなど、財務数値に効く項目の変更ログを確実にオンにする
- 証跡の保存期間と改ざん不能性：ログ自体を管理者が消せては意味がない。ITGCとして、ログの保持と特権アクセスの制限をセットで設計する
この段階で「規程に書いてあるから守る」ではなく「システム上できないから守られる」に置き換わる。
第二の柱――承認ワークフローで「事後の押印」を消す
統制が形骸化する最大の温床が、事後承認だ。支払や仕訳が先に走り、承認は後から帳尻を合わせる。これを断つには、承認をシステムのワークフローに組み込み、承認が下りるまで次工程に進めない状態を作る。S/4HANAは購買、支払、仕訳起票などの基幹プロセスに承認ステップを差し込み、金額や勘定の条件に応じて承認者を自動で振り分けられる。
設計の要点は、承認を「人の良心」ではなく「経路と条件」で縛ることだ。金額閾値で承認階層を変え（少額は一次承認のみ、高額は部門長・経理・役員と段階を増やす）、起票者が承認者を選べないようにする。自分が起票した伝票を自分で承認できない経路にすれば、これは後述の職務分掌と直結する。承認・却下・差し戻しのすべてが時刻付きで残るので、「誰が止めたか」「なぜ通したか」が後から再現できる。
ここで強調したいのは、ワークフロー化の本当の狙いは承認の厳格化そのものではなく、承認という統制行為が証跡として自動的に積み上がることだ。紙の稟議書を探す作業が消え、承認の事実がデータとして検証可能になる。J-SOX改訂で重みを増した「証拠の整備」に、最も素直に効く打ち手がこれだ。
第三の柱――職務分掌と例外検知をシステムに見張らせる
人手の統制で最も破られやすいのが職務分掌（一人が相反する権限を併せ持たない原則）だ。発注と検収、支払と承認を同一人物が握れば不正の余地が生まれる。これを規程の「兼務禁止」で守ろうとしても、繁忙期の応援や退職時の権限引き継ぎで簡単に崩れる。S/4HANAでは、SAP GRC（ガバナンス・リスク・コンプライアンスの統合製品群）のAccess Controlで、相反する権限の組み合わせ（SoDリスク）を定義し、付与時にシステムがブロック・警告する。カスタム開発なしに職務分掌違反を機械的に検知できる。
さらに踏み込むのが、SAP Process Control（内部統制の標準化・自動監視を担う製品）による継続的統制モニタリング（CCM）だ。これは自動化されたルールが連携システムの実データを走査し、例外をほぼリアルタイムで検知する仕組みである。ルールに違反する取引が起きるとProcess Controlに例外レポートが送られ、重大度が自動で付与され、課題として所有者に通知・割り当てされる（SAP-PRESS、SAP Help）。
これが設計思想の核心だ。統制は「全件を人が点検する」のではなく、「正常から外れたものだけを機械が拾い、人はそこにだけ判断を投じる」形に置き換わる。たとえば、承認上限を超えた支払、休眠取引先への突然の発注、職務分掌に反する権限付与――こうした例外を月次の事後発見ではなく発生時点で捕まえ、対応の進捗まで追跡できる。
なお、これらをいつ整備するかは経営判断と直結する。SAPは少なくとも1つのS/4HANAリリースを2040年まで保守すると表明する一方、現行のSAP ERP 6.0（ECC、EHP6〜8）のメインストリーム保守は2027年12月31日で終了し、延長保守（追加費用が標準保守料の9%）でも2030年が上限だ（SAP公式）。
ECCに統制を継ぎ足し続けるより、S/4HANA移行のタイミングで統制を「文書から仕組みへ」設計し直すほうが、結果的に監査の手作業もコストも小さくなる。
まとめ――統制設計の問いを「誰が守るか」から「何が止めるか」へ
自動で効く統制とは、性善説でも性悪説でもなく、「人の善意に依存しない設計」だ。証跡は業務の瞬間に自動で残し、承認はワークフローで前工程に組み込み、職務分掌違反と異常取引はシステムが発生時に検知する。S/4HANA移行を単なるシステム更改で終わらせず、内部統制の作り直しの好機と捉えれば、毎年の監査でかき集めていた証跡と言い訳の山を、検証可能なデータの流れに置き換えられる。
問うべきは「この統制を誰が守るか」ではなく「この逸脱を何が止めるか」だ。
- 内部統制の実体を規程文書からシステムの設定へ移す。土台はITAC（業務処理統制）を設定として埋め込み、ITGC（IT全般統制）で勝手に変えさせない2層構造。
- 証跡は「期末に集める」から「業務の瞬間に自動で残る」へ。削除の封じ込め・変更履歴・改ざん不能性を最初の設計で決め切る。
- 承認はワークフローで前工程に組み込み、承認が下りるまで次工程に進ませない。承認という統制行為が証跡として自動で積み上がる。
- 職務分掌違反（SoD）と異常取引は、SAP GRC／Process Controlが発生時に検知し、重大度を付けて是正まで追跡する。
- 整備はS/4HANA移行（ECC標準保守は2027年末、延長でも2030年が上限）の好機に合わせる。問いは「誰が守るか」でなく「何が止めるか」。
