決算の担当者が異動する。引き継ぎ資料を見た後任が、二週間後に言いにいく。「この作業、途中でExcelが勝手に動くんですが、中身が分かりません」。 開いてみると、マクロが別のフォルダのCSVを読みに行き、そこには前任者が自分で書いたPythonのスクリプトが吐いたファイルが置かれている。そのスクリプトは、前任者のPCのタスクスケジューラで毎月動いていた。 情報システム部は存在を知らない。しかも、そのツールが吐いた数字は、去年の有価証券報告書の注記の一部になっている。 禁止か黙認かで止まりがちなこの問題を、会社が引き受ける範囲の線、届出の条件、台帳の出口の順に整理する。
禁止しても黙認しても、行き着く先は同じである
対応の初手は、たいてい二つに割れる。情報システム部門は禁止を提案し、経理部門は黙認を続ける。そして両方とも、同じ場所に着地する。
禁止の帰結は単純で、可視性が消える。業務は減らないので、ツールは作られ続ける。ただし個人のPCの中と、共有フォルダの奥に潜る。 ファイル名から「ツール」という語が消え、拡張子が変わり、実行はスケジューラから手動に戻る。禁止して減るのは、把握できるツールの数だけである。
黙認の帰結は時間差で来る。作った本人がいる間は何も起きない。問題は、その人が異動するか辞めるか、あるいは長期の休みに入った月に、決算が止まることである。 そのとき初めて、経理部門は自分たちがどれだけそのツールに依存していたかを知る。依存の量は、依存していた人がいなくなるまで測定されない。
二つが同じ場所に着地するのは、どちらも「作ってよいか」という問いに答えているからである。 作ってよいかは、実は決着している。作られる。決めなければならないのは、作られたものをどこまで会社が引き受けるか、である。
線は「誰が作ったか」ではなく「出力がどこへ行くか」
引き受ける範囲を決める線を、多くの会社は間違った軸で引く。よくあるのが、作成者の所属で引く線と、ツールの種類で引く線である。
作成者で引くと、情報システム部門が作ったものは統制の対象、業務部門が作ったものは対象外、という区分になる。これは統制の目的から外れている。財務報告の信頼性に効くかどうかは、誰が作ったかとは関係がない。 種類で引く線も同じで、Excelのマクロは対象、RPAは対象外、生成AIに書かせたスクリプトはどちらか不明、という不毛な分類が始まる。技術の種類は毎年増えるので、この線は毎年引き直しになる。
引くべき線は一本である。そのツールの出力が、財務報告の数字か、その証跡に入るか。 入るなら会社が引き受ける。入らないなら引き受けない。この線なら、技術が何であっても、誰が作っても、同じ判定になる。
具体的には、こう分かれる。引き受ける側に入るのは、仕訳データを作るもの、決算数値を計算するもの、開示に使う集計表を作るもの、そして監査で証跡として提出するものである。 入らない側は、自分の作業メモを整形するもの、依頼メールの下書きを作るもの、社内の連絡を自動化するもの。判定に迷ったら、一つだけ聞けばいい。それが出した数字は、誰かの承認を経て会社の外に出るか。
引き受ける側の条件は、ガイダンスがすでに書いている
引き受けると決めたツールに何を課すか。ここは自社で発明する必要がない。同じ追補版が、スプレッドシート等について七つの統制目標を並べているからである。
追補版は、スプレッドシート等について 「実務担当者等が自ら利用することが可能であり、ＩＴ全般統制等で定められている開発の手順や記録を残さずに利用することが可能である」 とし、「そのため、スプレッドシート等の利用が財務報告の作成に関わる場合は、その信頼性に関するリスクについて検討する必要がある」 と書く。そして対策として、作成者と利用者を区分するか第三者が検証する体制、内容の文書化、定期的なバックアップ、担当者以外がデータを変更できない体制、再計算等による検証の五つを挙げる。
統制目標のほうはさらに具体的で、職務権限と利用権限が定められていること、利用が承認されていること、完全性・正確性・正当性に関する方針と手続があり遵守されていること、文書化されていること、バックアップを行い安全に保管すること、利用者が数式やマクロ等を改ざんできないようにしていること、検証できる仕組みが組み込まれているか他の方法で検証すること、の七項目が並ぶ。
この七項目は、そのまま届出の様式になる。 ツール名、作成者、いま動かしている人、入力元、出力先、出力が使われる決算工程、数式やロジックの説明、検証の方法、バックアップの場所。届出を出した時点でこの九項目が埋まっていなければ受け付けない、という運用にすれば、届出そのものが最低限のドキュメント化になる。
そして一つ、明示的に押さえておくべき事実がある。追補版はこの項に「（注：システム管理基準では、スプレッドシート等を独立した項目として扱っていない。）」と付している。 つまり、この論点は一般的なシステム管理の基準からは落ちる。財務報告の側から見たときにだけ、独立した項目として立ち上がる。情報システム部門の標準に任せておいても、この穴は埋まらない。
使い捨て側に付ける制約は、一つでいい
二層に割ったとき、多くの会社が失敗するのは引き受けない側の扱いである。「対象外」とだけ書くと、現場は自由に作り、そして自由に決算へ持ち込む。
引き受けない側に必要な制約は一つである。その出力を、決算の数値にも証跡にも入れないこと。 作るのは自由、使うのも自由、ただし出したものを決算に持ち込んだ瞬間に届出の義務が発生する。この一文を、経理部門の業務規程ではなく、決算の作業手順の側に書く。
なぜ手順の側かというと、持ち込みは意思ではなく流れで起きるからである。 誰も規程に逆らおうとして持ち込むのではない。締切が近く、手元に数字があり、貼り付ければ終わる、という状況で持ち込まれる。 だから止める場所は、貼り付ける直前の手順書でなければならない。
同じ構造は、Excelで作られた二次加工の集計表でも起きている。システムから出した数字が一度Excelに落ち、加工され、そちらが実質的な正本になる。この経路を塞がないまま届出制だけを作っても、抜け道が残る（SAPから出したExcelが正本になっていないか、加工した集計表をどこまで許すか）。そして生成AIが入ったことで、この経路は速くなった。 スクリプトを書ける人が増えたのではなく、書けなかった人が書けるようになった。リスクの総量が増えたというより、リスクの発生源が広がっている（経理財務チームの生成AI利用ルール、公表前の数字をどこまで入力してよいか）。
退職と異動の手続に、ツールの棚卸しを結ぶ
届出制は入口の制度である。出口を作らなければ、二年で台帳は実態と乖離する。
出口は二つ置く。一つ目は、人が動くときである。 退職と異動の手続に、届出済みツールの引き継ぎ確認を一行入れる。その人が運用者として登録されているツールを一覧で出し、後任を書くか、廃止するかを、離任の承認条件にする。 貸与品の返却と同じ扱いにすれば、忘れられない。
二つ目は、決算のたびである。 各決算で、届出済みのツールのうち実際に使ったものに印を付ける。二期連続で使われなかったツールは、届出から落とす。 これをやらないと、台帳は増える一方になり、増えた台帳は誰も読まなくなる。読まれない台帳は、無いのと同じどころか、監査の場で「管理していることになっているのに実態と違う」という指摘の材料になる。
そして、この作業に主体が要る。経理の中に、業務システムのオーナーを役割として置いている会社では、この棚卸しが定着する。置いていない会社は、情報システム部門と経理部門の間で押し付け合いになって止まる（経理に業務システムのオーナーを置くべき理由と、担う四つの職務）。届出制の設計より、誰がこの台帳を持つかを決めるほうが先である。
売上高680億円の食品メーカーで、経理課長が三か月かけて決算工程の棚卸しをした。きっかけは、連結担当者の退職である。 引き継ぎの過程で、子会社12社の連結パッケージを取り込んで様式を揃えるツールが、その担当者の個人的な作りものだったことが分かった。Excelのマクロと、共有フォルダに置かれたバッチファイルの組み合わせで、動かすときは決まった順番でファイルを置く必要があった。 手順書はなく、口頭で伝えられていた。この一件を受けて経理課長が調べたのは、他に同じものがどれだけあるかである。 決算に関わる部署へ聞き取りをしたところ、自作のツールとして名前が挙がったのは47件だった。内訳は、Excelのマクロが31件、RPAが9件、スクリプトが7件である。 そのうち、出力が仕訳データ・決算数値・開示用の集計表・監査提出資料のいずれかに入っているものは14件だった。残る33件は、依頼書の下書き、データの見た目の整形、社内メールの自動送信といった、決算の数字に触れないものである。 当初、情報システム部門からは全47件を管理対象にする案が出ていた。経理課長が反対した理由は、更新が続かないと見たからである。 前年に別の目的で作った台帳が、半年で更新されなくなっていた実績があった。そこで対象を14件に絞り、届出の様式を九項目に固定した。 ツール名、作成者、現在の運用者、入力元、出力先、使われる決算工程、ロジックの説明、検証の方法、バックアップの場所。この九項目が埋まらない届出は受け付けないことにしたところ、14件のうち4件は届出の段階で廃止になった。 理由は、書こうとしたら誰も出力先を説明できなかったからである。残る10件には、二つの手当てを入れた。作成者と検証者を分けること、そして数式とマクロにパスワードをかけて利用者が書き換えられないようにすることである。 33件のほうは、対象外として自由に作ってよいことを明示したうえで、制約を一つだけ付けた。出力を決算の数値や証跡に入れないこと、入れる場合は届出が必要になること。この一文を、経理部の規程ではなく決算の作業手順書の各工程に入れている。 台帳の出口も二つ置いた。退職と異動の申請書に、届出済みツールの後任記入欄を追加し、離任の承認条件にした。 そして各四半期の決算後に、使われたツールへ印を付け、二期連続で印の付かないものを台帳から落とす運用にしている。運用開始から一年で、台帳は10件から13件になった。 増えた3件はすべて新規の届出で、落ちたものはない。経理課長が経営会議で報告したのは、件数ではなかった。退職者のツールが連結の様式変換を担っていたこと、そしてその出力が前年度の有価証券報告書のセグメント情報に入っていたことのほうである。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
現場の自動化ツールに対して決めておく三つのこと
第一に、線を「その出力が財務報告の数字か証跡に入るか」の一本で引く。 作成者の所属やツールの技術では切らない。作成者で切ると統制の目的から外れ、技術で切ると毎年線を引き直すことになる。 出力の行き先で切れば、Excelのマクロでも、RPAでも、生成AIに書かせたスクリプトでも、同じ判定になる。迷ったときの一問は、それが出した数字は誰かの承認を経て会社の外に出るか、である。
第二に、引き受けると決めたツールには、追補版が挙げる七つの統制目標をそのまま条件として課す。 職務権限と利用権限、利用の承認、完全性・正確性・正当性に関する方針と手続、文書化、バックアップ、利用者が数式やマクロを改ざんできない状態、そして検証できる仕組みの組み込みまたは他の方法での検証。これを届出の九項目に落とし、埋まらない届出は受け付けないことにすれば、届出そのものが最低限のドキュメント化になる。 引き受けない側には制約を一つだけ付ける。出力を決算の数値にも証跡にも入れないこと。この一文は、規程ではなく決算の作業手順書の側に書く。持ち込みは意思ではなく流れで起きるからである。
第三に、入口だけでなく出口を作り、台帳の持ち主を決める。 退職と異動の手続に届出済みツールの引き継ぎ確認を入れ、後任を書くか廃止するかを離任の承認条件にする。決算のたびに使ったツールへ印を付け、二期連続で印が付かないものを台帳から落とす。 そして、この台帳を持つ役割を経理の中に置く。届出制の設計より、誰が持つかを決めるほうが先である。持ち主のいない台帳は、二年で監査の指摘材料に変わる。
