監査ログがない事業は自分を守れない
引き渡しから1ヶ月ほど経った頃に、売り手のもとへ一通の連絡が届く。M&Aの現場でよく繰り返されるパターンです。「顧客データの一部が消えているようです。心当たりはありませんか」。文面はあくまで丁寧なのですが、行間には明確な疑いがあります。売り手にしてみればまったく身に覚えのない話なので、当然「自分ではありません」と答えるわけですが、そこで会話は終わりません。返ってくるのは、たった一言「では、誰がやったんですか」です。
この質問に対して、5分で答えが出る事業と、永久に答えが出ない事業があります。両者を分けているのは、売り手の誠実さでも記憶力でもありません。その事業に監査ログが取得されていたかどうかという、それだけの違いです。
監査ログは、平時には1バイトの価値も生みません。売上にも、ユーザー体験にも、KPIにも、一切寄与しない。ストレージ代を静かに食うだけの、完全な死に荷物です。ところが係争になった瞬間、それは当事者が手にしうる唯一の武器に変わります。しかも厄介なことに、その武器を最初に必要とするのは、たいてい買い手ではありません。
この記事では、監査ログの不在がM&Aの何を壊すのか、なぜそれが売り手にとってこそ深刻な話になるのか、そして双方が引き渡しの前後で何を確認しておくべきかを、実務の順序で整理していきます。
監査ログは、平時には1バイトの価値も生まない
まず言葉の輪郭をはっきりさせておきます。監査ログとは、「誰が・いつ・何に対して・何をしたか」を、後から第三者が再構成できる形で残した記録のことです。エラーログでもアクセスログでもありません。
ここは実務で本当によく混同されるところで、「ログですか、ちゃんと出てますよ」と言われて見せられたものがWebサーバーのアクセスログだった、という場面は珍しくありません。3種類は、記録している対象がまったく違います。
- アクセスログ: どのIPからどのURLへリクエストが来たか。主体は基本的に匿名で、「人間の意思」までは追えない
- エラーログ: システムが何に失敗したか。うまくいった操作は原則として残らない
- 監査ログ: 特定された人間が、意思を持って何を実行したか。成功した操作こそが記録の本体になる
3つ目だけが、係争の場で意味を持ちます。そして3つのうち、自前で作らない限り絶対に存在しないのも3つ目です。
M&Aの文脈で最低限そろっていてほしい記録は、だいたい次のあたりになります。
- 管理画面での操作（ユーザーの削除、データの編集、設定変更）
- 本番データベースへの直接接続と、そこで実行されたクエリ
- データのエクスポート・一括ダウンロード
- 認証情報・APIキーの発行と失効
- 権限の付与と剥奪
- 管理者アカウントのログイン（失敗だけでなく、成功を残すことが重要）
- そして、ログそのものの削除
では、なぜこれが用意されていない事業がこれほど多いのか。答えは身も蓋もなくて、誰も要求しないからです。ユーザーは監査ログの有無で課金しませんし、監査ログがあってもコンバージョンは1件も増えません。機能開発の優先順位を素直に並べれば、永遠に最下位です。
まして個人や少人数で運営している事業なら、「触るのは自分だけなんだから、記録する意味がない」という判断は、合理的にすら見えます。実際、1人で運営し続ける限り、その判断は正しいのです。誰の行為かを区別する必要がないところで、行為の主体を記録しても仕方がありません。
その判断が破綻するのは、たった1日です。事業を誰かに渡す日です。
引き渡しの瞬間に、「触れる人」は静かに倍増する
M&Aという行為の技術的な正体を、身も蓋もなく言ってしまうと、ある事業に正当にアクセスできる人間の数を、一時的に倍にする作業です。
引き渡し前は、売り手とその周辺だけでした。引き渡し後は、買い手側のエンジニアが加わります。ここで多くの人が見落とすのが、売り手のアカウントは、その瞬間には消えていないという事実です。引き継ぎ作業があるので消せません。サポート期間の取り決めがあれば、なおさら消せません。過去に開発を委託した外注先の鍵が生きていることもあります。
つまり、その事業に触れる権限を持つ人間の数がピークに達するのは、引き渡し直後の数週間です。そしてその時期は、環境の移管、設定の書き換え、権限の付け替えといった、最も操作ミスが起きやすい作業が集中する時期と完全に重なっています。引き渡し後の事故がこの窓に集中するのは、偶然でもなんでもなく、単に人と作業が最も密集しているからです。
監査ログが最も必要とされるのが、まさにこの窓です。そして、この窓において監査ログが無い事業では、何が起きても行為者を特定する手段が原理的に存在しません。「誰がやったか」は、記録が無ければ推測にしかならず、推測は証拠になりません。
ここで、権限設計の話と混同しないでください。両者はよく似た顔をしていますが、軸がまったく違います。
- 権限設計が問うのは、「これから先、誰の手を止められるか」。未来の話です
- 監査ログが問うのは、「すでに起きたことを、誰の行為として再構成できるか」。過去の話です
権限を完璧に剥がしても、剥がす前に何が起きたのかは分かりません。逆に、記録が完璧でも、権限が生きていればこれから起きることは止められません。片方だけを持っている事業は、事故を防げないか、事故の後で誰も守れないかの、どちらかになります。両方が要るというのは、そういう意味です。
反転：監査ログは、売り手が「やっていない」と言うための保険でもある
監査ログの話は、たいてい買い手の防衛策として語られます。買い手が売り手を疑い、証拠を押さえるための仕組みだと。デューデリジェンスのチェックリストにも、そういう顔をして載っています。
これは、実務の順序としては逆です。先に困るのは、ほとんどの場合、売り手の方です。
引き渡し後に事業の数字が落ちたとき、買い手が最初に疑うのは前のオーナーです。ここには悪意すら必要ありません。運用のスキルが足りずに数字が落ちたのだとしても、人間は自分の失敗より他人の妨害を先に疑うようにできているからです（これは人間の性質であって、その買い手が特別に性格が悪いわけではありません。順番が逆なら、たぶん誰でも同じことをします）。
そして飛んでくる主張は、だいたい次のような形をしています。
- 「引き渡し後にログインされた形跡がある」
- 「顧客データが一部消えている」
- 「バックドアが仕込まれていて、外部から操作されている」
- 「以前は動いていた機能が、勝手に書き換えられている」
これに対して、監査ログの無い事業の売り手が言えることは、たった1つです。「やっていません」。以上です。それ以外に出せるものが、この世に何も存在しません。
これが、いわゆる悪魔の証明です。「何もしていないこと」は、それ単体では原理的に証明できません。証明できるとしたら、「その期間、自分のアカウントで何の操作も記録されていない」という記録を示すことを通じてだけであり、それは監査ログが存在する事業でしか成立しない芸当です。「無かったこと」を示すには、「有ったことを全部書いてある帳簿」が要る。逆説的ですが、そういう構造になっています。
記録が無ければ、売り手の主張は「やっていない」、買い手の主張は「やられた」。どちらにも証拠がありません。ここから先は純粋な水掛け論で、水掛け論は消耗戦で、消耗戦は資金と時間に余裕がある側が有利になります。そしてそれは往々にして、事業を売って手を離した個人の側ではありません。不当訴訟という形で問題が表面化する事案の多くは、この非対称性の上に成立しています。
ここが、この記事で最も伝えたい反転です。監査ログは、監視の道具の顔をして、実際には疑われた人を助ける道具であるということ。取っておいて助かるのは、やった人ではありません。やっていない人です。
立証責任は状況で動くが、記録を持っている側は交渉で強い
「立証責任はどちらにあるのか」という論点は、当然出てきます。ただ、これは契約の書き方、どういう法的構成で主張を組み立てるか、何を争点にするかによって動くもので、ここで一律の答えを書くことはできませんし、書いた瞬間に嘘になります。個別の事案は弁護士の領域です。
そのうえで、実務としてほぼ例外なく言えることが1つだけあります。記録を出せる側が、話の枠組みを決めるということです。
「ご指摘の期間の監査ログはこちらです。当該アカウントによる操作は0件です」。この1枚が出てくると、そこで話は事実上終わります。相手が主張を続けるためには、そのログが偽造されていることを立証しなければならず、難易度が一気に跳ね上がるからです。
逆に記録が無いと、話は「言った・言わない」の領域に落ちます。この領域では、声が大きく、時間があり、弁護士費用を払える側が勝ちやすい。正しさとは、あまり関係がありません。
そして忘れられがちなのは、この手の揉め事の大半は、法廷まで行かずに手前で終わるということです。手前で終わる交渉であればあるほど、証拠の有無がそのまま結論になります。法廷は最後の砦であって、日常の武器ではありません（そして法廷まで行った時点で、勝っても双方が時間とお金を失っています。勝ち負け以前に、行かないのが最善です）。
契約に「引き渡し後、本件システムへ不正にアクセスしない」といった条項を入れることはできますし、入れるべきです。ただし、その条項は違反の有無を検証する手段とセットでなければ、ただの作文です。破ったかどうかを誰も確かめられない約束は、守った人にとって何の役にも立ちません。検証手段の実体が、監査ログです。
買い手が確認すべきは、取得・改ざん耐性・保存期間の3点
ここからは検査の話です。監査ログの確認は、技術的DDの中では地味な項目に見えますが、見るべき点は3つに整理できます。
1. そもそも取得されているか
「監査ログはありますか」という質問には、残念ながら意味がありません。返ってくる答えがほぼ確実に「ありますよ」だからです。しかもこれは嘘ではありません。ログは本当にあるのです。監査ログではないだけで。
求めるべきは、直近90日分の実際のエクスポートです。そのうえで、権限変更・データエクスポート・本番DBへの接続が「行の形で」入っているかを目で見る。ここまでやって、初めて確認したことになります。
実態としてよくあるのは、アプリケーションのエラーログはある、アクセスログもある、監視の仕組みも入っている、それなのに「管理者が管理画面で何をしたか」だけが、どこにも記録されていないというパターンです。クラウドの管理コンソール側の操作は既定で記録が残るものもありますが、アプリケーション内部の操作は、自分で作らない限りこの世に存在しません。
2. 改ざん耐性があるか
最も見落とされるのがここです。監査ログが本番と同じデータベースの1テーブルに入っていて、管理者権限で書き換えられる構成になっている場合、その記録は、疑われている当人が消せます。
疑われる可能性のある人が消せる記録は、証拠として機能しません。「消されていないこと」を別途証明する必要が生じ、そこで詰みます。消しゴムで書ける契約書に、法的な意味があるかという話です。
見るべきポイントは4つです。ログの保存先が本番系と分離されているか。追記のみ（append-only）で運用されているか。書き込み権限と閲覧権限が分かれているか。そして、ログの削除そのものが記録に残るか。
3. 保存期間が、係争の発生時期をカバーするか
ここには、悪い冗談のような構造があります。
ログの保存期間は、既定値のまま数十日で消えていく設定になっているものが多い。一方で、M&Aの係争は引き渡しの翌日には起きません。買い手が運用を引き継ぎ、数字が落ち、原因を探し、前オーナーを疑うところまで到達するには、どう急いでも数ヶ月かかります。
つまり紛争が起きる頃には、その紛争を解決できるはずだったログが、期限切れで消えている。誰も悪意を持っていないのに、既定値に従っていただけで、この状態が完成します。
保存期間は、表明保証の存続期間や契約上の責任期間に合わせて決めるべきものです。責任期間が1年なら、1年分残っていなければ意味がありません。加えて、移管の際に新しい基盤へ載せ替えるとき、旧環境のログを引き継がずに捨ててしまう事故も起きます。移管作業の完了と同時に、後で必要になる証拠だけが消えるわけです。
3点すべての前提：ログの中の「誰」が特定できるか
最後に、上の3点すべての土台になる話をします。
全員が同じ管理者アカウントを共有している事業では、監査ログが完璧に取得され、改ざん不能な場所に、10年分保存されていたとしても、そこに書いてあるのは「admin が削除しました」だけです。誰なのかは、どこにも書いてありません。
これは監査ログの体裁をした、何も証明しない行の集まりです。共有アカウントは権限管理の問題として語られがちですが、同時に監査ログを丸ごと無価値にする問題でもあります。売り手・買い手・外注先が同じアカウントを使っていた事業では、記録があっても誰も守られません。ここが、権限の設計と記録の設計が交差する一点です。
売り手が引き渡しの前後でやるべきこと
ここまで読んで気が重くなった方のために、順序を整理します。難しい作業はほとんどありません。ただ、やる順番と、やる時期だけは動かせません。
1. 交渉が始まる前に、記録を「これから」作り始める
監査ログには、唯一にして最大の弱点があります。遡って作れないことです。バックアップと違って、過去は永久に取り戻せません。
だから、売却を考え始めた日が、記録を取り始められる最も早い日になります。今日ログ出力を有効にすれば、3ヶ月後の引き渡し時点では3ヶ月分の履歴になっています。「引き渡しの日から取ります」では、引き渡し前の状態を誰も証明できません。そして買い手が疑うのは、たいてい引き渡し前後の期間です。
作業としては、管理画面の主要な操作にログ出力を1行足すところから始まります。拍子抜けするほど地味な作業ですが、地味さと重要度は比例しません。
2. 「自分の権限が止まった日時」を、記録として残す
スクリーンショットでは足りません。権限を剥奪した操作そのものがログに残り、かつ買い手も同じログを見られる状態にしてください。併せて、誰がいつまでアクセス権を持っていたかの一覧を双方で確認し、日付を入れて残しておく。
ここで大事なのは、これは買い手のためではなく売り手のための作業だという点です。「◯月◯日◯時に権限を失った」という記録を持っている人は、その後に起きた出来事について、構造的に無関係でいられます。疑いを晴らすのではなく、疑いが成立しない状態を先に作っておくということです。
3. 引き渡し時点のスナップショットを、双方で確認する
「データが消えた」という主張が成立するには、「引き渡し時点では存在していた」という前提が要ります。ところが引き渡し時点の状態を誰も記録していないと、その前提自体が水掛け論になります。
主要テーブルの件数、スキーマの定義、直近の主要指標。この程度で十分です。双方が同じ画面を見て、同じ数字を、日付入りで残す。それだけで「消えた」という主張は検証可能な話に変わります。そして検証可能な話は、たいてい揉めません。揉めるのは、確かめようがない話だけです。
4. サポート期間中は、買い手が発行したアカウントで作業する
最も直感に反する項目ですが、最も効きます。
引き渡し後のサポートで、売り手が昔から使っている管理者アカウントで作業を続けるケースは本当に多い。手っ取り早いからです（というより、わざわざ新しいアカウントを作ってもらう方が面倒なので、善意でそうしているケースがほとんどです）。
ですが、これをやると売り手の操作は「旧オーナーの管理者アカウントによる操作」として記録され、他の誰かの操作と区別がつかなくなります。何かあったとき真っ先に疑われるアカウントで、自ら作業を続けていることになるわけです。
買い手が発行した個別アカウントで作業すれば、自分の操作はすべて記録されます。一見、自分の首を絞めているように見えますが、逆です。記録が残っている人だけが、記録に残っていないことについて「やっていない」と言えます。記録から逃げた人は、その資格ごと失います。
5. ログの保存期間を、契約の責任期間に合わせて書き込む
ここは契約側の話です。「本件システムの監査ログを、引き渡し日から◯年間保存する」という条項を入れておく。義務を負うのは、引き渡し後にシステムを管理する買い手です。
なぜ買い手が保存する義務を、売り手の側から要求するのか。証拠が残ることは、疑われる側にとっての利益だからです。買い手が運用の都合でログを消してしまえば、売り手は自分が無関係だったことを示す材料を、自分の手が届かない場所で失います。
加えて、事業譲渡の形で資産を個別に移す場合は、譲渡対象にログのデータそのものを含めるのか、ログを取得している仕組みだけを含めるのかも、決めておく価値があります。「システム一式」という書き方では、後から解釈を争う余地が残ります。
記録は、誰かを疑うためではなく、疑われた人を助けるためにある
監査ログの導入が後回しになるのは、コストや工数の問題だけではありません。「うちのメンバーを信用していないのか」という空気が、どこかにあるからです。記録を取ることが、不信の表明のように感じられてしまう。
実際は、まったく逆です。記録が無い場所では、誠実な人ほど損をします。嘘をつく人は、何とでも言えるからです。「消えた」「やられた」「見た」。証拠が要らない世界なら、主張はいくらでも作れます。そして、それに対抗する手段を持たないのは、本当に何もしていない人の方なのです。
監査ログは、最も疑われやすい立場の人を守る仕組みです。そしてM&Aにおいて最も疑われやすい立場は、たいてい売り手です。事業を作り、育て、正当な対価で手放した人が、そのあと何年も「あいつが何か仕込んだんじゃないか」という視線に晒され続ける。それを断ち切れるのは、誠実さの表明でも、人柄でも、これまでの信用でもありません。日付と時刻の入った、たった1行のテキストです。
事業を手放した人には、手放したあとに疑われずにいる権利があります。買った人には、何かが起きたときに原因を突き止める権利があります。この2つはよく対立するものだと思われていますが、監査ログという1点においては、完全に同じものを要求しています。どちらも、事実が残っていてほしいだけなのです。
監査ログは、平時には1バイトの価値も生みません。それでいいのです。1バイトの価値も生まないまま、何事もなく保存期間を終えて静かに消えていくのが、最良のシナリオです。ただ、そうならなかった1回のために、それは存在しています。
保険とは、そういうものです。そして保険がそうであるように、必要になってから入ることは、絶対にできません。
