責任分界：名義・費用・アクセス権限

結論：「名義」「費用」「アクセス権限」「実際に操作する人」を分けて書く

保守や運用の契約で、障害が起きたときに最初にもめるのは「それは誰の管理だったのか」です。サーバーやドメインの契約の名義は委託者なのに、受託者が管理画面にログインして設定を変え、DNSの設定を管理し、ECサイトのテンプレートを直している、という状態はよくあります。個人のWebデザイナーの保守・運用契約の原案には、ドメイン・サーバー・外部ECの利用料と維持管理は委託者の責任と負担とする条がありました。事務所のレビューは、方向性は正しく「トラブルの分水嶺」となる重要な条項だと評価したうえで、名義が委託者でも受託者が実際に操作している場合に責任の押し付け合いになるので、責任の主体と「実際に管理している者」を分けて書くよう指摘しています。

同じレビューでは、クレジットカードの期限切れでサーバーが自動停止する、ドメインの更新料の未払いで失効しサイトが消える、という場面を挙げ、支払が滞ったときの責任の構造と保守の一時停止を書くこと、外部ECの管理権限の一部が受託者に移っている場合に、プラットフォーム側の障害や仕様変更のときの調査と対応の義務の範囲を明文化することも求めました。責任分界（どこまでが誰の責任かの境界）は、インフラやクラウドの保守では、名義・費用・権限・操作の4つの軸で決めておくと、後から整理し直す必要がなくなります。

このページでは、事務所の書類に現れた4つの型（名義と費用は顧客で権限は貸与する型、ID・パスワードを預からない型、受託者名義で持つ型、委託者名義に集める型）と、委託先専用のアカウント、判断と作業の分界を紹介します。終了時の権限の返上やパスワードの変更は終了時の引継ぎ、定額ITサポートの台帳の扱いは定額ITサポートの三層構造のページもあわせてご覧ください。

「名義と費用は顧客、権限は貸与」の型

保守ベンダーの保守契約では、サーバー・ドメイン・SSL・有料テーマなどの契約・支払・更新は委託者の名義と費用で行い、委託者は管理画面などのアクセス権限を受託者に「貸与」し、受託者は貸与された権限の範囲で保守を行う、と定めました。そのうえで、委託者の協力義務と、アカウントの管理の分担を次のように書いています。

この型の要は、契約と支払を委託者の名義に置いたまま、受託者が触れる範囲を「貸与された権限」に限ることです。委託者や別の業者が設定を変えるときは事前か直後に知らせてもらう義務を入れているので、知らないうちに変えられた設定が原因の障害は、委託者の協力不足として扱えます。サーバーの更新料の支払を委託者の義務として書いているので、カードの期限切れでサーバーが止まった場合も、受託者の責任ではないことが条文で読めます。

ID・パスワードを「預からない」型と「預かる」型

個人のHP制作者の制作・保守のひな形では、ヒヤリングで「顧客のIDやパスワードを一時的にでも預かる場面はあるか」を確かめたうえで、預からない設計にしました。独自ドメイン、DNSの設定、公開に使うクラウドのアカウントは、いずれも顧客の名義のアカウントの中で取得・管理し、契約が終わっても顧客の財産として残ります。制作者はドメインの取得やアカウントの開設を代行せず、画面共有で操作を案内します。作業は、顧客が自分のアカウントに制作者を管理者として招待し、付与した権限に基づいて行い、権限は必要最小限で目的外に使いません。

預からない型は、受託者が認証情報を持たないので、漏えいの責任を問われる場面そのものを減らせます。終了時の権限の返上を「停止・切替・引渡しの後」としたのは、引渡しが終わる前に権限がなくなると、作業ができなくなるからです。一方、相談窓口型のITサポートのように、委託者のさまざまなサービスに触れることが前提の業務では、預からない設計は現実的ではありません。その場合は、預かる前提で、権限の正当性は委託者が保証し、受託者は委託者の社内の承認状況まで確かめる義務を負わず、作業の結果の最終的な運用管理の責任は委託者にあり、終了時のパスワードの変更は委託者が行う、という形で責任を分けています。

どちらの型でも共通するのは、従量課金や支払方法の失効のように、サービスが止まる原因になる事項を委託者の側に置いていることです。ひな形では、アクセスが増えて無料枠を超えた従量課金も、名目を問わず顧客の負担と明記しました。クラウドの利用料が急に増えたとき、受託者が立て替える形になっていると、その負担をめぐって争いになります。

同じひな形では、誰がサイトを変更してよいかも決めています。保守期間中のサイトの変更は制作者を通じて行い、顧客が制作者以外の者に変更させる場合は事前に通知すること、通知のない変更に起因する不具合は制作者の責任ではなく、保守を停止できること、そうした不具合は無償の修補の対象外であることを定めました。問い合わせフォームの個人情報は転送するだけで制作者の側には保存せず、目的外に使わないこと、顧客の求めがあれば、送信に使う外部サービスの名称と提供者の所在国を知らせることも書いています。外国にある事業者のサービスを経由する場合に、顧客が個人情報保護法上の確認をできるようにするための一文です。

受託者の名義で持つ型と、長期継続での無償譲渡

反対に、ドメインやサーバーを受託者の名義で持つ設計もあります。テンプレート型のHP制作と継続保守の契約では、改訂版で、ドメインとサーバーの契約・管理は原則として受託者の名義で行い、委託者は取得に必要な情報を遅滞なく提供し、委託者が自己の名義を希望する場合は別に協議する、という条が新設されていました。受託者の名義で持てば、受託者がまとめて管理でき、委託者は更新や支払を気にしなくて済みます。

その代わり、契約が終わったときに委託者がサイトを使い続けられるかが問題になります。同じ契約では、終了時の譲渡の対象にドメインの契約情報とサーバーの契約情報を加え、契約が36か月以上続いていれば譲渡の費用を無償にする、と改められていました。受託者の名義で持つなら、終了時に何を、いくらで、どの期間内に渡すかをセットで決めておくことが条件になります（終了時の引継ぎ）。どちらの名義がよいかは立場とサービスの設計で分かれますが、事務所が扱った書類では、顧客名義を基本とし、受託者名義にする場合は譲渡の条件を厚く書く、という傾向がありました。

委託側から：アカウント・APIキー・リポジトリを発注者の名義に集める

委託者の側から契約を作るときは、受託者が業務のために作るアカウントや保管場所を、最初から委託者の名義にしておくことが、終了時の引継ぎを楽にします。業務の自動化を外部のエンジニア会社に頼んだ委託側の契約では、次のように定めました。

外部の生成AIサービスの利用についても、確認書で「委託者の名義の組織アカウントに受託者をメンバーとして登録する方式」と記入しています。受託者の名義で契約した外部サービスに委託者のデータが蓄積されると、契約が終わった後にデータを取り戻す手段がなくなるからです。

AI活用支援のコンサルティング契約のレビューでも、第三者のSaaSの利用料は原則として委託者が自ら契約して負担する、という条について、契約終了後も委託者が使い続けるなら合理的であり、受託者が契約の主体となる場合は、終了後のアカウントやデータの扱いを個別契約や業務指示書で整理しておくよう助言しました。補助金の申請支援の個別契約のように、委託者のチャットツール、委託者のドメインのクラウドストレージ、委託者独自のシステムの上でだけ作業させる設計もあります。レビューでは、情報管理の上では理解できるとしつつ、受託者の側にデータ・履歴・テンプレートが残りにくい点を指摘しています。受託者が自分の業務の記録をどこまで手元に残せるかも、あわせて決めておくとよいでしょう。

個人への時間精算の委託契約を改訂したときのレビューでは、解除のときの精算の項目に、報酬の精算だけでなく、アクセス権の廃止、データの消去の証明、アカウントの削除を入れるよう指摘しました。権限を「誰の名義で持つか」と同じくらい、「いつ、誰が消すか」を決めておくことが大切です。

委託先専用のアカウントと、貸与される機器

建設会社が個人事業主に現場の帳票の遠隔運用代行を委託した案件では、元請が指定するクラウド型のシステムを使う必要がありました。ヒヤリングで、委託先に発注者のIDを共有するか、専用のアカウントを発行するかを確かめたうえで、契約では、委託者のアカウントとは別に受託者専用のアカウントを2件作成し、そのIDとパスワードを共有すること、受託者は目的外の使用と第三者との共有をせず、終了時又は委託者の求めで使用を停止し、返還又は消去することを定めました。起案時の報告書では、元請への報告や承諾の取得が必要な場合は委託者の側で行うものと整理しています。上位のシステムの規約が関わる場面では、報告や承諾の取得を「誰が」行うのかを、条文の主語として明記しておくことが大切です。秘密保持契約でも、付与した認証情報を、秘密の表示の有無を問わず秘密情報として明示しています。

同じ案件では、アプリに蓄積される作業の指示や日報などのデータを委託者が用意するクラウドストレージの共有フォルダに保存し、別の場所に保存するには委託者の事前の承諾が要ることにしました。秘密保持契約でも、保存は開示者が用意する共有フォルダなどに限り、受領者の機器での一時的な閲覧・編集はできるが不要になれば削除する、としています。データの保存先を最初から委託者の環境にしておけば、終了時に「どこに何が残っているか」を探す必要がありません。

SESの契約では、委託者がパソコンやネットワーク環境、業務用のアカウントを貸与することがあります。ネットワークエンジニアの契約では、貸与されたパソコンなどは善良な管理者の注意で扱い、紛失・破損・不正使用は直ちに報告して委託者の指示に従い、終了時や要請があったときは直ちに返却し、委託者の指示でデータを削除すること、委託者の情報セキュリティポリシーや利用規程に従い、ID・パスワードの不正使用や情報資産の複製・持出しをしないことを定めました。仲介会社との基本契約の修正版では、委託者やクライアントの貸与物の破損・紛失・第三者による使用は「故意又は過失があるときに限り」相当額を賠償し、終了時には原状に回復して返却する、としています。Web制作会社がフリーランスに発注する基本契約では、付与されたサーバー・CMS・解析ツール・広告のアカウントを必要最小限で使い、ID・パスワードを第三者に開示・利用させず、終了時はアカウントと権限の使用を停止して認証情報を返還又は消去することにし、運用説明書では、終了時のアクセス権限の削除とパスワードの変更を「情報漏えい対策として最も効果が高い実務」と案内しました。

「判断」と「作業」の分界

運用の代行では、受託者が作業をしているうちに、実質的な判断まで受託者がしていると見られることがあります。遠隔運用代行の契約では、作業の方法や安全上の判断は委託者の側が行い、受託者は帳票への記入・伝達・確認・記録の代行だけを行い、判断そのものに責任を負わない、と定めました。起案時の報告書では、受託者が安全管理の上での実質的な決定権者と評価されかねないので、分界を明文化したと説明しています。同じ契約では、請求書の作成の補助についても、発行前に委託者が確認・承認し、委託者の名義で出すことにし、最終的な判断は委託者が行うとしました。運用代行の契約一般に使える考え方です。

ほかにも、大手の顧客向けの基本契約では、委託者が提供したものの使用・運用に関する法令の遵守や、構成の設定の正確性などの管理事項は委託者が単独で責任を負う（ただし請負の成果物の追完の義務は別）、と定めていました。ホームページの管理を受けた個人事業者の契約では、受託者は制作会社の制作内容・システム・サーバーの設定・セキュリティの設定について保証責任を負わない、と書いています。受託開発の後のサポートの契約では、委託者によるクラウド上のファイルの権限設定の不備やアクセスの制限に起因する不具合は免責としました。設定を誰が決め、誰が変えたのかを、契約の上で辿れるようにしておくことが、障害の原因の切り分けにつながります。

起きがちなこと：カードの期限切れとログインの残り

名義・費用・権限・操作の4つを分けて書けば、障害のときに「誰が、何を、すべきだったか」を契約書から読み取れます。障害そのものの免責と賠償の上限はバックアップ・障害・賠償の上限、再委託先に権限を渡すときの条件は再委託とメンバー交代のページで扱います。

よくあるご質問

あわせて読みたいページ

本ページは一般的な情報提供です。個別の契約への当てはめは、取引の実態によって結論が変わることがあります。事務所の改訂例・ご相談の事例として紹介している内容は、アトラス行政書士法人が作成・レビューしてきたシステム保守業務委託契約書、Webサイトの保守・運用業務委託契約書、定額ITサポートの契約書、準委任型の業務委託基本契約書と個別契約、エンジニアへの業務委託契約書、秘密保持契約書、ヒヤリングシートなどを、個別の事業者が特定できない形に整理したものです。条文は e-Gov法令検索で確認しています（最終確認日：2026年10月16日）。参考: e-Gov法令検索 / フリーランス法特設サイト（公正取引委員会）