こんにちは。エンジニア兼代表の木村です。
システム開発プロジェクトを立ち上げる際、多くの企業は「無事にシステムが完成し、ビジネスが成功すること」を夢見ます 。しかし、IT業界の厳しい現実として、システム開発が当初の計画通り、無事に納品されて成功する可能性は決して高くありません 。 多くのプロジェクトが、要件定義の齟齬、納期の遅延、そして予期せぬシステムトラブルやデータの喪失といった泥沼の紛争に巻き込まれています。
もし、開発業者（ベンダ）の誤操作や不適切な設定によって自社に甚大な損害が出たとしたら、あなたならどうしますか？「当然、損害賠償を請求する」と考えるでしょう 。
しかし、AWS（Amazon Web Services）上に構築されたシステムで、ある一つの設定を怠っていたがために、数千万円の損害を出しながらも裁判で100%負け、完全な「泣き寝入り」に追い込まれたクライアント（発注者）の実例が存在します 。
弊社に相談する場合はこちら（無料）
どんな事でもご相談に乗ります。＊見積もり無料
今回は、インフラの操作ログを記録する「AWS CloudTrail」の重要性と、トラブル発生時に「正式な証明（エビデンス）」としてログを機能させるための依頼・運用方法について解説します。
1. 開発成功率は3割以下。「責任問題」を見据えてスタートせよ
一般的な統計データ（日経コンピュータ等の調査）でも、システム開発プロジェクトの「成功率（納期・予算・クオリティをすべて満たす割合）」は3割程度と言われています 。つまり、「最初から高い確率で揉める可能性がある」という前提でスタートするのが、大人のビジネスにおけるリスクマネジメントです 。
特にAWSのようなクラウド環境での開発では、ベンダ側がボタン一つでサーバーを削除したり、セキュリティ設定を書き換えたりできてしまいます 。 トラブルが起きたとき、ベンダは自己防衛のためにこう主張するでしょう 。
- 「私たちはそんな操作はしていません」
- 「御社の担当者様がマネジメントコンソールから触られたのではないですか？」
- 「原因不明のシステムエラーです」
このように「言った・言わない」「やった・やっていない」の泥沼に陥ったとき、客観的な証拠がなければ、発注者側は一歩も前に進めなくなります 。
2. 【実例】ログが取れず損害賠償請求で「敗訴」した恐怖のケース
実際にあった、クラウド環境におけるトラブルとIT訴訟の典型的な失敗事例を紹介します 。
### 【事例】設定ミスによるデータ消失と、証拠不足による敗訴 ある中堅EC企業（クライアント）が、外部のIT開発業者に依頼してAWS上への新システム構築を進めていました 。本番稼働の直前、AWS上のデータベース（RDS）およびストレージ（S3）内の重要データが、何者かの操作によって忽然と消去されるという致命的なトラブルが発生 。これまでの開発データや移行用データが失われ、プロジェクトは頓挫、企業は数千万円規模の損害（機会損失および再開発費用）を被りました 。
クライアントは「開発業者が環境のクリーンアップを行う際、本番用の環境を誤って削除したに違いない」と確信し、ベンダの過失を理由に損害賠償請求の裁判を起こしました 。
しかし、結果はクライアント側の「完全敗訴」でした 。
原因は、AWS環境において**「AWS CloudTrail」による長期的な操作ログの取得（証跡の設定）が行われていなかったことです 。IT訴訟における大原則は「不法行為や契約違反を主張する側（＝原告・クライアント）が、相手の過失を証明（立証責任）しなければならない」**という点です 。
裁判所は、「データが消去された事実は認められるものの、インフラの操作ログが存在しない以上、それが開発業者のアカウントによる誤操作（過失）によるものか、あるいは第三者による不正アクセスやクライアント側の誤操作によるものかを特定する客観적証拠がない」と判断 。ベンダ側の責任を認めるに足りないとされ、クライアントの請求は一蹴されました 。
この企業は、数千万円のシステム投資とデータを失っただけでなく、多額の裁判費用を支払い、完全に泣き寝入りすることになったのです 。
3. なぜ「AWS CloudTrail」が命綱になるのか？
AWS CloudTrailは、AWSアカウント内で行われたすべてのアクション（APIコール）を記録するサービスです 。「誰が」「いつ」「どこのIPアドレスから」「どのリソースに対して」「何をしたか（作成、変更、削除など）」がすべて克明に残ります 。
これさえ有効になっていれば、上記の事例でも言い逃れのできない「一発退場の証拠（エビデンス）」を掴むことができました 。
◆ 実際にCloudTrailで確認できるログ（イベント）の例
CloudTrailを有効にしていれば、トラブル発生時に以下のような明確な事実をログから突き止めることが可能です。
- 実行されたアクション:
TerminateInstances（サーバーの強制停止・削除） - 実行日時:
2025-10-31T03:48:40 UTC - リクエスト送信元IPアドレス:
xx.xxx.xxx.xx - 実行したIAMユーザー:
arn:aws:iam::xxxxxxxxx:user/XXXXX
これだけの情報が揃っていれば、「2025年10月31日に、開発業者側の担当者（ユーザー名）が利用しているIPアドレスから、本番環境のサーバーを削除する命令が下された」ということが客観的な事実として証明されます。ベンダ側も「やっていない」という言い逃れは一切できなくなります。
AWSにはデフォルトで90日間のイベント履歴を表示する機能がありますが、これだけでは不十分です 。なぜなら、開発中のトラブルから裁判に発展するまでには数ヶ月〜数年かかるのがザラであり、90日を過ぎたログは消えてしまうからです 。また、デフォルトの履歴は「正式な証明」として提出するには心もとない部分があります 。
4. 業者に「正式な証明（エビデンス）」としてログを依頼・保管する方法
プロジェクト開始時に、開発業者に対して「有事の際に法的・正式な証明として使える形でログを残すこと」を義務付ける必要があります 。RFP（提案依頼書）や基本契約の特記仕様書に、以下の要件を必ず盛り込んでください 。
① 「CloudTrailの証跡（Trail）作成」と「S3への永久（長期）保存」の指定
デフォルトの90日履歴ではなく、個別に「証跡」を作成し、ログファイルをAmazon S3バケットにエクスポートして長期（プロジェクト終了、または法定期間内）保存するよう仕様に明記させます 。
② 「ログファイルの検証（Log File Integrity）」の有効化を義務付ける
ここが最も重要です 。裁判などでログを証拠として提出する際、相手から「そのログは発注者側が後から改ざんしたのではないか」と反論されるリスクがあります 。 CloudTrailの機能である「ログファイルの検証（Log File Integrity）」を有効化するよう依頼してください 。これにより、AWSが暗号学的ハッシュ（SHA-256）とデジタル署名（RSA）を用いて、ログファイルがS3に保存されてから一切改ざんされていないことを数学的に証明（整合性検査）できるようになります 。これこそが、裁判に耐えうる「正式な証明」となります 。
③ ログ保存先S3バケットの「削除禁止」および「アクセス権制限」
ログが保存されるS3バケットは、開発業者自身が勝手に削除・変更できないように権限（IAMポリシー）を制限するか、クライアント側が管理する別アカウントのS3バケットに集約（クロスアカウントロギング）させるのが理想です 。
5. まとめ：信頼と「エビデンス」は別物。最悪を想定してスタートしよう
開発業者と良好な関係を築くことは大切ですが、ビジネスにおいて「信頼しているからログは不要」という理屈は通用しません 。前述の通り、システム開発が無事に成功する確率は決して高くありません 。 プロジェクトをスタートさせるその初日に、「いつか責任問題になったときの武器（エビデンス）」をシステム的に仕込んでおくこと 。 これが、最終的に自社の資産を守り、また開発業者側にとっても「見られている」という適度な緊張感を生み、プロジェクトの品質向上に繋がります 。
今すぐ、自社のAWS環境、あるいは外注している開発環境の「CloudTrail」と「ログファイル検証」が有効になっているか、確認してください 。