購買システムの操作ログは何を残すか——四つの目的で項目と期間を決める

「ログは全部取っておいて」では、要るものが残らない

購買部門から受発注のシステムを入れたいと相談されると、情報システム部門には必ず「操作の記録はどうなっているのか」という確認が回ってくる。監査対応のため、税務のため、あるいは何かあったときのため。理由はそれぞれ正しいが、まとめて「ログは全部取っておいてほしい」と事業者に伝えると、たいてい期待したものは手元に残らない。

理由は単純で、ログという言葉が指すものが一つではないからである。発注の数量を 100 から 80 に直した記録と、誰かが夜中に 3 回ログインに失敗した記録は、どちらもログと呼ばれるが、残す目的も、残す年数も、後で誰が読むのかもまったく違う。前者は取引の経緯そのもので、税務調査や公正取引委員会の検査で取引ごとに引き出される。後者はセキュリティの事故が起きたときに時系列で並べて読むもので、取引先ごとに引くことはまずない。

政府機関向けの基準ではあるが、内閣官房の「政府機関等の対策基準策定のためのガイドライン」は、ログについて「その特性に応じてログを取得する目的を設定した上で」、取得する対象の機器、取得する情報項目、保存期間、取扱方法を定めるよう求めている^[4]。民間企業にこの基準を守る義務はないが、考え方の順番はそのまま使える。先に目的を決め、目的ごとに項目と期間を決める。この記事はその順番で進める。

操作の記録を残す理由は四つある

理由 1：電子帳簿保存法の改ざん防止

注文書や見積書をデータでやりとりすると、そのデータは電子帳簿保存法の電子取引データとして保存しなければならない。国税庁の電子帳簿保存法一問一答は、改ざん防止の措置として、タイムスタンプが付された後の授受、速やかなタイムスタンプの付与、データの訂正削除を行った場合にその記録が残るシステム又は訂正削除ができないシステムを利用して授受及び保存を行うこと、訂正削除の防止に関する事務処理規程の策定・運用・備付けの四つを挙げ、いずれかを行うこととしている^[1]。

購買システムの操作ログが効くのは三つ目である。どういうシステムなら三つ目に当たるかについて一問一答が示している例と、型ごとの当たりの付け方は購買管理システムの比べ方で紹介した。要点は、訂正・削除そのものができないか、訂正・削除の前の内容が残って後から検索・閲覧・出力できるか、のどちらかである^[1]。

見落としやすい条件が一つある。一問一答は別の問で、この三つ目の方法による場合は電子取引データを保存するだけでなく授受も行う必要があると書いている^[1]。システムが授受に使われていない場合は、タイムスタンプか事務処理規程の方法で要件を満たす必要がある、とも続けている。つまり、取引先からメールで届いた見積書の PDF を後から購買システムに添付しても、その添付の履歴だけでは三つ目の方法にはならない。どの書類をシステム上で授受し、どの書類はシステムの外で受けているかを分けておかないと、ログの設計が要件の判断に結びつかない。電子取引データの保存全体をシステムなしで満たす方法は、電子帳簿保存法の対応——システムなしで満たす方法で整理している。

理由 2：取適法の 7 条記録

取適法（中小受託取引適正化法）の対象になる製造委託では、委託事業者は取引の経緯を記録して保存しなければならない。公正取引委員会・中小企業庁の取適法テキストは、記録を電磁的記録で作成・保存する場合に満たすべき要件として、記録事項について訂正又は削除を行った場合にこれらの事実及び内容を確認できること、映像面に表示し書面に出力できること、取引先の名称等や範囲指定した発注日で検索できること、の三つを挙げ、根拠を記録規則第 2 条第 3 項としている^[2]。

電子帳簿保存法と比べると、ここには選択肢がない。テキストに再録された記録規則の本文は、電磁的記録に記録する場合には「次に掲げる要件を満たさなければならない」として三つを並べており、一つ目の訂正・削除の確認は、事務処理規程やタイムスタンプで置き換えられる形になっていない^[2]。7 条記録を購買システムで持つ以上、訂正と削除の事実と内容が確認できることはシステムに求める条件になる。何を記録し、2 年間をいつから数えるかは取適法が求める記録——何を書いて、2 年間どう残すかに、置き場所の設計は発注の記録を 2 年どう残すかにまとめてある。この記事では、その「訂正・削除の事実と内容」をシステムの操作記録としてどう持つかだけを扱う。

理由 3：内部統制（IT 全般統制）

金融庁の企業会計審議会が示す財務報告に係る内部統制の基準と実施基準は、上場会社が財務報告の信頼性を確保するためのもので、上場していない会社に報告の義務はない。それでも購買システムの選定では参考になる記述がある。実施基準は、IT に係る全般統制の具体例として、システムの開発・保守に係る管理、システムの運用・管理、内外からのアクセス管理などシステムの安全性の確保、外部委託に関する契約の管理の四つを挙げ、対応の例として、システムの開発又は変更の過程等の記録を適切に保存することを示している^[3]。

操作ログにとってより直接的なのは、評価の手続を説明した部分である。実施基準は、自動化された統制であっても過信せずに無効化のリスクを完全に防ぐことは困難だという視点を持つことが重要だとしたうえで、電子記録について変更の痕跡が残り難い場合には、内部統制の無効化が生じてもその発見が遅れることがある点に留意するよう書いている^[3]。承認の手順をどれだけ整えても、承認後に誰かが値を直して跡が残らなければ、手順が破られたことに誰も気づけないということである。発注・検収・支払を誰に分けるかという職務分掌の考え方は発注する人と検収する人を分けるで扱っている。なお同じ実施基準は、IT への対応は組織に新たな IT システムの導入を要求したり既存システムの更新を強いたりするものではない、とも明記している^[3]。

理由 4：セキュリティの調査

四つ目は、不正なログインや情報の持ち出しが疑われたときの調査である。先のガイドラインは、ログを、不正侵入や不正操作などの情報セキュリティインシデントとその予兆を検知する材料であり、問題が起きた後の調査で問題を解明する材料でもあると位置づけ、仕様どおりに取得され、改ざんや消失が起こらないよう保全されなければならないとしている^[4]。クラウドサービスについても、ログはオンプレミス環境と同様に適切に取得できるよう設定し、改ざんや消失が起こらないよう保全することを運用規程に含めるよう求めている^[4]。

中小企業向けには、IPA の中小企業の情報セキュリティ対策ガイドラインが、情報機器や情報システムへの不審なアクセスを把握するため、通信ログや認証ログを取得・保管し、ログの改ざん防止を行ったうえで定期的にレビューするよう勧めている^[5]。同じガイドラインは用語の説明のなかで、ログファイルは運用期間に応じて増えていくため、一定期間（例として 1 週間、3 か月、1 年）で自動的に削除されるよう設定されているのが一般的だと書いている^[5]。調べたいときには、もう消えていることがあるということである。

四つを並べると、残す中身と年数が分かれる

四つの理由を一つの表にすると、同じ「ログ」でも二つの種類が混ざっていることが見えてくる。上の二つは取引の中身を直した履歴で、取引の記録と同じ長さで持つ必要がある。下の二つは誰がいつ何をしたかという利用の記録で、年数は自社で決める。

1 年以上という目安は、標的型攻撃について攻撃の初期段階から経緯を確認する観点から、過去の事例を踏まえて望ましいとされた値である^[4]。政府機関向けの記述なので、民間企業が同じ年数を義務として負うわけではない。ただ、事業者のログの保存期間が 3 か月だった場合、四半期をまたいだ不正には遡れないという判断材料にはなる。

二つの種類が一つの出来事に重なる場面に注意したい。たとえば、取引先マスタの振込先口座が変更された記録は、取引の中身に関わるので長く持ちたいが、変更したのがどの端末からのどのログインだったかは、利用の記録の側にしかない。利用の記録が 3 か月で消えると、2 年前の口座変更について「誰が変更したか」は分かっても「本当にその人だったか」は確かめられない。重要な変更の記録には、操作した人の識別だけでなく、どの経路から操作したかも一緒に残すよう求めておくとよい。

1 件の操作記録に持たせる項目

取引の中身を直した履歴として、1 件ごとに次の項目があれば、四つの理由のどれから見ても用が足りる。

この表の上から六つは、国税庁が示している訂正削除の事務処理規程のサンプルと見比べると分かりやすい。法人用のサンプルは、訂正又は削除をする場合に「取引情報訂正・削除申請書」へ、申請日、取引伝票番号、取引件名、取引先名、訂正・削除日付、訂正・削除内容、訂正・削除理由、処理担当者名の 8 項目を記載させている^[1]。紙の申請書で残している情報を、システムが操作のたびに自動で残してくれるか。要件を書くときは、この 8 項目と自社の業務に合わせて、どの項目を必須にするかを決めるとよい。

時刻については、先のガイドラインが、時刻を設定できる構成要素は基準となる時刻に同期させ、ログに時刻情報も記録するよう求めている^[4]。購買システムが SaaS であれば自社で時刻を合わせることはできないので、事業者に時刻同期の方法を聞くことになる。総務省の ASP・SaaS の情報開示指針でも、時刻同期への対応の有無と方法は、事業者が開示すべき必須の項目に入っている^[6]。

記録に残りにくい経路を塞ぐ

画面からの操作がきちんと記録されていても、それ以外の経路から値が変わると、記録は途切れる。購買システムでは次の四つが典型である。

表計算ソフトでの手直し

一覧を書き出して表計算ソフトで単価を直し、それを取り込み直す運用は多い。このとき取り込みが「上書き」として扱われ、品目ごとに何から何へ変わったかが記録されないと、変更の痕跡はそこで消える。選定の段階で、一括取り込みで既存の値が変わったときに、画面から直したときと同じ形で 1 件ずつ記録が残るかを確かめておく。残らないのであれば、取り込みの前後のファイルを規程に沿って保存するなど、システムの外で痕跡を残す手当てが要る。

同じ理由で、システムに入る前の段階を表計算ソフトで持ち続けるのも避けたい。発注の数量を表計算ソフトで決めてから入力していると、システムに残るのは決まった後の値だけになる。正となる値をシステムの中に置き、決める作業もシステムの中で行うのが、記録を途切れさせない一番の方法である。

他のシステムとの連携による更新

会計システムや生産管理システムと連携していると、値が連携の処理によって書き換わることがある。この場合、記録の「誰が」に誰が入るのかを確認しておく。連携専用のアカウントの名前で一律に残るのか、連携を設定した担当者の名前で残るのか、そもそも記録されないのか。連携が止まったときや二重に流れたときに原因を追えるのは、この記録だけである。他のシステムとのつなぎ方は会計・生産管理・在庫のシステムと購買システムをどうつなぐかで扱う。

管理者と事業者による修正

誤って登録したデータを、自社の管理者や事業者の運用担当者が裏側から直すことがある。こうした修正が利用者の操作と同じように記録されるか、あるいは別の記録に残るかは、事業者によって違う。総務省の情報開示指針は、事業者が開示すべき必須の項目として、システム運用部門の管理者権限の登録・登録削除の手順の有無を挙げている^[6]。事業者の運用担当者が自社のデータに触れたときに、その事実が自社から確認できるのかは、選定の時点で聞いておく。

システムの入れ替え・データの移行

旧システムから新システムへデータを移すと、旧システムに残っていた訂正の履歴やタイムスタンプが引き継げないことがある。国税庁の一問一答は、システム変更時のデータ移行についても改ざん防止措置を講ずる必要があるとしたうえで、タイムスタンプを引き継ぐなどの対応ができない場合でも、データ移行時における訂正削除の防止に関する事務処理規程を制定し遵守することで要件を満たす、としている^[1]。あわせて、移行前のシステムでどのように要件を満たしていたかを説明できるよう、取扱説明書等を保存しておくことが望ましいとも書いている^[1]。入る側の移行手順は表計算や旧システムから受発注・購買のシステムへ移るときに、出る側で困らないための確認は購買の SaaS をやめる・乗り換えるときに困らないためににまとめる。

ログを誰が消せるか

操作の記録は、残っていることと同じくらい、勝手に消せないことが大事である。先のガイドラインは、取得したログに対する不正な消去、改ざん及びアクセスを防止するため、適切なアクセス制御を含む保全方法を定めるよう求め、その例として、ログ収集サーバの管理者を他のサーバの管理者と異なる者にすること、ログを外部の記録媒体に書き出して切り離して保管すること、書き換えのできない媒体に書き出して保管することを挙げている^[4]。

SaaS の購買システムでこの考え方を当てはめると、確認することは二つになる。一つは、自社の管理者権限を持つ人が、操作の記録を消したり書き換えたりできるかどうか。できるのであれば、発注を担当する人に管理者権限を持たせない設計が必要になる。誰にどの権限を渡すかは購買システムの権限をどう設計するかで、権限を持つ人のアカウントを入社・異動・退職のたびにどう管理するかは購買システムのアカウントをどう回すかで扱う。もう一つは、記録を自社の手元に定期的に書き出せるかどうか。事業者側の保存期間が自社の必要とする年数より短い場合、書き出して自社で保管するしかない。

取引の記録と操作の記録が結びついている点にも気をつけたい。発注そのものを削除したとき、その発注に付いていた変更の履歴が一緒に消える作りになっていないかを確かめておく。そうした作りであれば、取引の記録を削除できる人を絞るか、削除ではなく取消や保管に回す運用にしておかないと、履歴は「削除」という一つの操作でまとめて失われる。

見ないログは、残していないのと変わらない

先のガイドラインは、取得したログを定期的に点検又は分析する機能を設け、不正侵入や不正操作の有無を点検・分析することを遵守事項としている^[4]。IPA のガイドラインも、ログは定期的にレビューすることを勧めている^[5]。とはいえ、購買システムの全操作を毎月読む体制を作れる会社は少ない。購買の業務で見る価値が高いのは、次のような変化である。

1. 取引先マスタの振込先・連絡先の変更
支払先のすり替えは、ここが入口になる。変更した人と承認した人が同じでないかを見る。

2. 承認が済んだ後の発注の変更
承認の後で数量や単価が変わっていれば、承認の意味が失われている。変更の理由が残っているかを見る。

3. 単価の改定
改定の件数が特定の担当者・特定の取引先に偏っていないか。改定の理由が空欄のものがないか。

4. 業務時間外の操作と、大量の書き出し
深夜や休日のログイン、取引先一覧や単価の一括書き出しは、持ち出しの兆候になりうる。

5. ログインの失敗の連続
同じアカウントへの連続した失敗は、パスワードの総当たりの兆候である。

この五つは、四つの理由のうち内部統制とセキュリティの調査に当たる部分で、電子帳簿保存法と取適法は記録が残って取り出せることを求めているだけで、定期的に読むことまでは求めていない。どの変化を誰が月に一度見るかを決め、見たこと自体を記録に残しておくと、内部監査で説明しやすくなる。

選定のときに事業者へ聞くこと

ここまでを、事業者に送る質問の形にまとめる。総務省の情報開示指針は、利用者の利用状況の記録（ログ等）の取得の状況とその保存期間及び利用者への提供可否、システム運用に関するログの取得の有無と保存期間、ログの改ざん防止措置の有無を、事業者が開示すべき必須の項目としている^[6]。開示資料があればまずそれを読み、足りない点を質問で埋める。

1. 発注・単価・品目・取引先の変更は、変更前と変更後の値、変更した人、日時が 1 件ずつ記録されるか。理由は残せるか
2. 一括取り込み・連携・管理者による修正でも、同じ形で記録されるか。誰の操作として残るか
3. 取引の記録を削除したとき、変更の履歴はどうなるか
4. ログイン・ログインの失敗・書き出しの記録は何日残るか。自社の管理画面から見られるか
5. 自社の管理者は、操作の記録を消したり書き換えたりできるか
6. 記録を自社に書き出せるか。どの形式で、どの範囲まで書き出せるか
7. 事業者の運用担当者が自社のデータに触れたとき、その事実は記録され、自社から確認できるか
8. 時刻はどの方法で同期しているか。記録の時刻はどの時間帯で表示されるか

この質問は、購買部門の要望を選定の要件に書き直すときの非機能要件の一部になる。要件全体の書き方と、事業者の回答を比べる評価表への落とし方は購買部門の要望を、選定に使える要件にどう書き直すかで扱う。

よくある質問

クラウドの購買システムを使っていれば、電子帳簿保存法の改ざん防止は満たしたことになりますか

自動的には満たさない。国税庁の一問一答は、利用者側で訂正削除できない、又は訂正削除の履歴が全て残るクラウドシステムであれば通常は要件を満たすとしているが、その方法による場合は保存だけでなく授受もそのシステムで行う必要がある、としている^[1]。取引先とのやりとりの一部をメールで行っているなら、その分はタイムスタンプか事務処理規程で手当てする必要がある。

上場していないので、内部統制のためのログは要りませんか

報告の義務はないが、承認の手順を置いている会社であれば、承認の後で値が変わったことに気づける記録は要る。実施基準が、変更の痕跡が残りにくいと無効化の発見が遅れることがあると書いているのは、上場会社に限った事情ではない^[3]。それとは別に、取適法の対象になる取引があれば、上場の有無に関係なく 7 条記録の義務がかかり、電磁的記録で持つなら訂正・削除の事実と内容を確認できることが求められる^[2]。

ログは長く残すほど安全ですか

長く残すほど調べられる範囲は広がるが、保存の費用と、記録そのものを守る手間も増える。先のガイドラインは、直近のログはすぐに調べられる媒体に置き、それ以降は長期保存に適した媒体に移す方法も挙げている^[4]。取引の中身の履歴は取引の記録と同じ年数、利用の記録は自社が遡って調べたい期間、と分けて決めると過不足が出にくい。

事業者がログを開示してくれない場合はどうしますか

何が記録されているかが分からないシステムでは、四つの理由のどれについても説明ができない。少なくとも、取引の中身の変更履歴が画面か書き出しで確認できることは、選定の必須条件に置くべきである。利用の記録の開示が限られる場合は、事故が起きたときに事業者が調査に協力する範囲と期限を、契約やサービスの説明資料で確かめておく。

まとめ

購買システムの操作ログは、電子帳簿保存法、取適法、内部統制、セキュリティの調査という四つの理由で残す。前の二つは取引の中身を直した履歴で、取引の記録と同じ年数だけ持ち、取引先や発注日で引けることが求められる。後の二つは利用の記録で、年数は自社で決めるが、事業者が何日で自動的に消すかを先に確かめないと、調べたいときには消えている。そのうえで、表計算での手直し（一括取り込みを含む）、連携、管理者や事業者による修正、システムの入れ替えという記録の途切れやすい四つの経路を一つずつ塞ぎ、記録を消せる人を絞る。選定のときに事業者に聞くべきなのは、ログがあるかどうかではなく、何が、誰の操作として、何年、誰にも消せない形で残るかである。

出典・参考資料

1. 電子帳簿保存法一問一答【電子取引関係】（国税庁／令和 7 年 6 月）
2. 中小受託取引適正化法テキスト「下請法」から「取適法」へ（公正取引委員会・中小企業庁／令和 7 年 11 月）
3. 財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準（金融庁 企業会計審議会／令和 5 年 4 月 7 日改訂）
4. 政府機関等の対策基準策定のためのガイドライン（令和 7 年度版） 第 3 部～付録（内閣官房 国家サイバー統括室／令和 7 年 7 月 1 日・令和 8 年 10 月 1 日一部改定）
5. 中小企業の情報セキュリティ対策ガイドライン 第 4.0 版（独立行政法人情報処理推進機構／2026 年 3 月）
6. ASP・SaaS の安全・信頼性に係る情報開示指針（ASP・SaaS 編）第 3 版（総務省／令和 4 年 10 月）

WHITE PAPER

この記事の理解を深める
無料ホワイトペーパーをプレゼント

製造業の現場で使える実務資料（PDF）を無料でお届けします。"こんな資料が届きます" ↓ 下のボタンからどうぞ。

🔒 全文は無料ダウンロードで