セキュリティ入門 05｜あなたのサイトは誰が管理しているか：三つの委託関係、責任範囲はそれぞれ違う

サイトが開かない、あるいはセキュリティ公告の通知が届いた——その瞬間に受話器を取って誰かを探すとき、いちばん聞きたくないのはこの一言です。そこは弊社の担当ではありません、サーバーのハードウェアだけです。

会社は毎月決まった額を払っているのに、なぜ事故のときに誰も自分の仕事だと思わないのか。サイトの世界では、置き場所を借りることと、サイトを見てもらうことは、まったく別の二つだからです。セキュリティ入門の第 5 回です。セキュリティ入門 01｜公告が出た日：自分のシステムが該当するかどう見分けるかでバージョンを確認したのに続き、本稿はもっとも誤解されやすい線を引き直します。あなたのサイトは今どの委託関係にあるのか。事故のとき、誰が先に動くべきなのか。

サーバー代を払ってもセキュリティを見てもらえるわけではない理由

サーバーは借りた店舗だと考えてください。建物を建て、電気と水を止めず、正面に警備を置くのは大家の仕事です。しかし店のレジに鍵がかかっているか、従業員が退勤時に窓を閉めたか、棚の商品が期限切れでないか——大家が入ってきて見てくれることはありません。

クラウドサーバーも同じ理屈です。世界的なクラウド事業者 Amazon Web Services（AWS）が公開している責任共有モデル（Shared Responsibility Model）では、公式文書が責任をきれいに二つに分けています。事業者が負うのはクラウド自体のセキュリティ（Security of the Cloud）、つまりデータセンターの物理的な安全、ハードウェア、基盤の仮想化です。顧客が負わなければならないのはクラウド内部のセキュリティ（Security in the Cloud）で、OS の更新とセキュリティ修正、アプリケーション、ファイアウォールの設定が含まれます。

言い換えれば、カードを切ってクラウドサーバーを借りただけなら、アプリケーションに脆弱性があっても、データベースにバックアップがなくても、事業者にはあなたのシステムに入って直す義務も権限もありません。御社の AI 製品にバックアップはありますか：データベースとファイルの最低基準に書いたとおりです。事業者が負うのは機械が生きていることで、あなたのデータが無事であることではありません。

第一の関係：自分でクラウドサーバーを借りる（AI で自作して公開した場合も含む）

会社がカードでクラウドサーバーやデプロイ用のプラットフォームを借り、自分か社内のエンジニアがコードを置いて動かしている。あるいはCursor、Claude Code、Lovableで作ったプロジェクトをエンジニアに渡す前に準備すべきことで触れたように、オンラインのツールを数回押してプロダクトを公開した。この関係では：

• 相手の責任はどこまでか：データセンターの電源が落ちない、ネットワークがつながる、ハードウェアが壊れたら交換する。
• サイトとセキュリティの責任は誰か：すべてあなた自身（または社内のそのエンジニア）です。OS を上げるか、セキュリティ更新を実際にやったか、落ちたとき誰が見るか、データベースを毎日別の場所に取っているか——プラットフォームは何も代わりにやりません。
• いちばん踏みやすい落とし穴：サーバーを立てたエンジニアは辞め、カードは毎月自動で引き落とされ、サイトもまだ動いている。だから誰かが見ていると思い込む。実際にはその機械は、彼が去った日から更新も監視もない裸のままです。

第二の関係：管理型ホスティングまたはサイト構築プラットフォーム

素のサーバーより少し高い額を払い、基盤環境を整えてくれる管理型サービスか、既成のネットショップ・サイト構築プラットフォームを使っている。この関係では：

• 相手の責任はどこまでか：ハードウェアに加えて、基盤の OS かプラットフォーム共通の標準機能まで見てくれ、機械全体の定期スナップショットを提供するところもあります。
• サイトとセキュリティの責任は誰か：半分ずつです。自分で入れた拡張機能、人に頼んで書いてもらった独自のコード、従業員や取引先に開けた管理画面のアカウント権限、外に繋いだ決済と SMS の鍵——これらは依然としてあなたの側です。
• いちばん踏みやすい落とし穴：管理型サービスなら安全だと思い込み、管理者パスワードをごく単純なものにしたり、何年も更新されていない第三者製の拡張機能を山ほど入れたりする。相手は基盤のサーバーを守りましたが、攻撃者はあなたの管理画面や拡張機能の穴から堂々と入ってきます。

第三の関係：開発・保守業者に丸ごと委託する

サイトを外部の技術会社に渡し、契約を結んだ。ただしここは注意が必要です。同じ委託という言葉でも、責任の線がどこに引かれているかで中身がまったく違います：

• 開発と保証期間の契約だけの場合：公開後も、私たちはここにいます：Helper CTOの責任線はどこまで延びるかに書いたとおり、プロジェクト型の本質は「つくって終わり」です。保証期間が切れれば、点検もバックアップも脆弱性修正も契約上の義務はありません。事故のたびに見積もり直し、スケジュール取り直しになります。
• 長期保守契約はあるが「システム保守サービスを提供する」としか書いていない場合：保守契約書には何を書くべきか：対応時間、更新頻度、解約条件、ドキュメントの帰属と月額費用に「含む」と「含まない」：保守プランの読み方で分解したように、安いプランは事故のとき電話に出る人がいるという意味しかないことがあります。障害調査、セキュリティ更新、遠隔地バックアップはすべて別見積もりです。
• 本当に最後まで責任を持つ運用関係：サーバーは見られていて、異常があれば言われる前に動き、セキュリティ更新は定期的に行われ、バックアップと復旧の訓練も固定の月額に含まれている。そしてアカウント、ドメイン、ソースコードの所有権はすべて自社の名義にあります。

一枚の表で見る：三つの委託関係、四つの要点を誰がやるのか

自分のサイトがどれなのか分からない場合は、毎月払っている請求書と契約書を出して、下の表と照らし合わせてください。命綱になるこの四つが、今は誰の名前の下にあるのかを見るためです：

線が引けたら、この四問で確認する

どの関係にあっても、危ないのはどれを選んだかではありません。あなたは相手がやっていると思い、相手はあなたがやると思っている——そこが危ないのです。保守契約書には何を書くべきか：対応時間、更新頻度、解約条件、ドキュメントの帰属の原則に沿って、今あなたから費用を受け取っている相手にこの四問を出せます：

• 深夜にサイトが落ちたら、誰が最初に通知を受け、どれくらいで着手するか：応答時間が明記されていなければ、その日は顧客からの電話で知ることになります。
• 公告が出たとき、誰がバージョンを確認して更新を実行するか：それが今の費用に含まれて定期的に行われるのか、誰も言わなければ永遠に動かないのかを確認します。
• データベースとファイルのバックアップはどこにあり、誰が復旧を試すか：事業者がスナップショットを取っているという説明で済ませないこと。バックアップが独立して別の場所にあるか、前回いつ復旧を試したかを訊きます。
• 来月やめることになったら、サーバー、ドメイン、コードは誰の名義か：所有権が最初から最後まで自社にあることを確認してこそ、管理してもらうために身代を他人に預ける形にならずに済みます。

恩梯科技（Nerd Technic）はカスタム開発出身のシステムソフトウェア会社で、今やっているのは AI システムの長期保守です。長期保守で見るべきは、事故からどれくらいで応答があるか、セキュリティ更新をどの頻度で行うか、ドキュメントと所有権は誰のものか——どれも契約に書かれるべきことです。はっきり書くプランもあれば、システム保守サービスを提供するの一行で済ませるものもあります。今あるシステムを本当に誰かが見ているのか、どの責任が宙に浮いているのか分からない場合は、システム健康診断から始められます。見るのはコード、データベース、デプロイ、セキュリティの四つで、システム健診では何を見ているのか：コード、データベース、デプロイ、セキュリティの 4 領域に全項目を書いています。システム健康診断を予約する