何から始めますか。発注前に名義を自社にすると決めます
最初に決めるのは、ドメイン、サーバ、解析ツールの契約名義をすべて自社にするという方針です。提案を受ける前に決めておくと、後の交渉になりません。
理由は単純です。発注後に「名義を自社に変えたい」と伝えると、手続きの手間と費用の話から始まります。発注前に条件として示せば、それを前提に提案が来ます。
名義を自社にすべき4つの対象
対象は次の4つです。
| 対象 |
名義人が持つもの |
| ドメイン |
登録者情報と、更新や移管を行う権利 |
| サーバ（レンタルサーバやクラウド） |
契約と支払、および管理画面への最上位の権限 |
| Googleアナリティクスなどの解析ツール |
蓄積された計測データと、権限を配る権利 |
| Google Search Console |
検索での表示データと、所有権の確認 |
4つのうち、ドメインとサーバは契約そのものです。解析ツールとSearch Consoleはアカウントの所有権です。性質が違うため、取り決め方も分けて考えます。
見落としやすいのは、メールです。会社のメールアドレスをドメインと同じ設定で使っている場合、ドメインの名義はメールの継続にも関わります。
制作会社に運用を任せることと、名義を渡すことは別
名義を自社にすることは、自分で運用するという意味ではありません。運用は任せたまま、名義だけ自社に置けます。
分け方は次のとおりです。
- 契約と支払は自社が行います。クレジットカードの登録も自社です。
- 管理画面の権限は、自社が最上位の権限を持ち、制作会社を運用担当として招待します。
- 日々の作業は制作会社が行います。ここは変わりません。
- 解約や移管の判断は自社が行います。
この形にしておけば、運用の手間は増えません。増えるのは、最初の申し込みを自社で行う手間だけです。目安として、ドメインとサーバの申し込みは合わせて1時間から2時間です。
つまずきやすい点は、制作会社が「まとめて用意します」と提案してくる場合です。悪意があるとは限りません。手続きを代行したほうが早いという判断で、通常の進め方としてそうしている会社もあります。その場合は、名義だけ自社にしてほしいと伝えてください。断られる理由は、ほとんどありません。
なぜ発注前に決める必要があるのか、名義が制作会社側だと具体的に何が起きるのかは、次のセクションで扱います。
名義が制作会社側だと、後で何が困りますか
困るのは、取引を終えるときと、緊急時に手を動かすときです。名義人でなければ、変更の手続きも解約もできません。平常時は問題が表に出ないため、困ったときに初めて気づきます。
取引を終えるときに起きること
制作会社を変える場合、または自社で運用に切り替える場合に、次のことが起きます。
- ドメインの移管手続きを、名義人である制作会社に依頼することになります。応じる義務は契約次第です。
- 移管に手数料を請求される場合があります。金額の根拠は契約書に書かれていなければ交渉になります。
- 連絡が取れなくなった場合、手続きが進みません。廃業や担当者の退職で起きます。
- ドメインの更新を止められると、サイトとメールが同時に止まります。
最後の1つは影響が大きいところです。会社のメールアドレスがそのドメインなら、取引先からのメールが届かなくなります。名刺とパンフレットの記載も使えなくなります。
同じ構造は解析ツールでも起きます。制作会社のアカウントで計測していた場合、過去のデータは制作会社側に残ります。新しいアカウントを作り直すと、過去との比較ができません。
障害や情報漏えいが起きたときに起きること
緊急時は、名義の影響がさらに直接的に出ます。
- サイトが改ざんされた場合、公開を止める判断を自社でできません。サーバの管理画面に入れないためです。
- 問い合わせフォームから個人情報が漏れた場合、影響範囲の調査にはサーバのログが必要です。ログの取得を制作会社に依頼する形になります。
- 深夜や休日に起きた場合、制作会社の対応時間を待つことになります。
2点目は、個人情報の取り扱いに関わるため特に重要です。何が漏れたかを自社で確認できない状態では、報告や通知の範囲を決められません。
実装側の目線で補足します。緊急時に自社で操作するとは、実際には「制作会社に指示を出しつつ、必要なら自社で止められる状態を持つ」という意味です。自社で全部を操作する想定は現実的ではありません。止める操作と、ログを取り出す操作の2つができれば足ります。この2つに必要な権限を、名義とあわせて確保してください。
なお、名義が制作会社側になっているケースは、悪意より手続きの都合で生じることが多いところです。前のセクションで触れたとおり、代行したほうが早いという判断で行われます。すでにそうなっている場合の移し方は、記事末のよくあるご質問で触れます。
具体的に何を取り決めるかは、次のセクションで扱います。
ドメインとサーバの名義は、どう取り決めますか
取り決めるのは、名義人、支払者、管理画面の権限、そして解約と移管の手順の4点です。名義人だけを決めても、管理画面に入れなければ実質は動かせません。
4点をドメインとサーバでそれぞれ決めます。同じ会社に任せる場合でも、契約は別のサービスになるため個別に確認してください。
ドメインで決める4点
ドメインは登録の情報がそのまま権利になります。次の4点を書面にします。
| 決める項目 |
自社が持つべき状態 |
| 登録者（名義人） |
自社の法人名で登録します |
| 支払と更新 |
自社のカードまたは請求書払いにします |
| 登録事業者の管理画面 |
自社がログインできる状態にします |
| 移管と解約の手順 |
手続きに必要なものと担当を明記します |
手順は次のとおりです。
- 自社でドメイン登録サービスのアカウントを作ります（目安30分）。つまずきやすい点は、担当者個人のメールアドレスで作ってしまうことです。退職すると連絡が届きません。部署の共有アドレスを使ってください。
- 希望のドメイン名を自社で取得します（目安15分）。制作会社に候補を挙げてもらい、取得は自社で行う形が確実です。
- 管理画面のログイン情報を、自社で保管します（目安15分）。制作会社へは必要な範囲の権限を渡します。
- 更新日をカレンダーに登録します（目安5分）。自動更新にしていても、カードの期限切れで止まることがあります。
サーバとメールで決める4点
サーバも同じ4点ですが、権限の考え方が少し違います。
- 契約者は自社にします。
- 支払は自社にします。
- 管理画面は、自社が最上位の権限を持ちます。制作会社には作業に必要な権限を別に発行します。
- 解約の手順と、データの取り出し方を決めます。
メールを同じサーバで使う場合は、次も確認してください。メールアカウントの作成と削除を誰が行うか、過去のメールデータをどう取り出せるか、の2点です。サイトを別のサーバへ移すときに、メールだけ残す構成にできるかも聞いておくと後が楽です。
実装側の注意点を1つ挙げます。サーバの管理画面には、契約を管理する画面と、ファイルやデータベースを操作する画面の2種類があります。前者だけ持っていても、改ざん時にサイトを止められません。両方にアクセスできる状態を確認してください。
制作会社の共有サーバを使う場合の扱い
制作会社が自社で用意したサーバに、複数の顧客のサイトを載せている場合があります。この構成では、契約名義を自社にすることが仕組みとしてできません。
その場合は、次の3点を書面で確認します。
- 将来サイトを別のサーバへ移す際に、ファイルとデータベースを一式渡してもらえるか。
- 渡す形式と、渡すまでの日数。
- その作業に費用が発生するか。発生する場合の金額。
構成そのものが不適切とは限りません。運用がまとまって速いという利点もあります。確認すべきは、出るときに出られるかどうかです。
解析ツールとSearch Consoleの権限は性質が違うため、次のセクションで扱います。
解析ツールと検索コンソールの権限は、どう決めますか
自社のアカウントで所有者となり、制作会社を編集者や管理者として招待する形にします。逆にすると、データも権限も持っていかれます。
ドメインやサーバと違い、ここは契約ではなくアカウントの所有権の話です。費用がかからないため軽く扱われがちですが、蓄積するデータの持ち主が決まる部分です。
自社アカウントを先に作る手順
順序が重要です。制作会社が計測を設定する前に、自社側のアカウントを用意します。
- 会社の共有メールアドレスでGoogleアカウントを作ります（目安15分）。担当者個人のアカウントは避けてください。退職時にアクセスできなくなります。
- そのアカウントでGoogleアナリティクスのプロパティを作ります（目安30分）。作った人が所有者になります。
- 同じアカウントでGoogle Search Consoleにサイトを登録します（目安15分）。所有権の確認はドメインの設定か、サイトのファイル設置で行います。ドメインの管理画面に自社で入れる状態なら、ここも自社で完了します。
- 制作会社を、必要な権限で招待します（目安10分）。アナリティクスは編集者、Search Consoleは権限のある使用者から始めて、足りなければ上げます。
- 招待した相手と権限の一覧を記録します（目安10分）。取引が終わったときに、この一覧を見て削除します。
つまずきやすいのは3点目です。Search Consoleの所有権の確認は、ドメイン単位で行う方法とURL単位で行う方法があります。ドメイン単位のほうが後の管理が楽ですが、ドメインの管理画面での設定が必要です。前のセクションのとおり自社で入れる状態にしてあれば、迷いません。
データの引き継ぎができない場合がある点
すでに制作会社のアカウントで計測している場合、そのまま自社へ移せるかはサービスによって変わります。
- Googleアナリティクスは、プロパティの所有者を変える操作ではなく、アカウントへの権限追加で対応することが一般的です。制作会社のアカウント配下に残る形になります。
- 過去のデータを別のプロパティへ移す標準の手段はありません。新しく作ったプロパティには、作成後のデータだけが溜まります。
- Search Consoleの過去データも同じです。所有権を追加すれば見られますが、制作会社が所有権を外すと見られなくなります。
つまり、計測の初期設定を誰のアカウントで行うかは、後から修正しにくい判断です。これから発注する御社は、ここを最初に自社で押さえてください。
すでに制作会社のアカウントで計測している場合の対応は、記事末のよくあるご質問で触れます。
RFPと契約書のどこに書くかは、次のセクションで扱います。
RFPと契約書のどこに書きますか
RFPでは前提条件の章に、契約書では成果物と役割分担の条項に書きます。提案を受ける前のRFPに書くことが重要です。後から出すと、見積もりの前提が変わったという話になります。
RFPとは、発注者がベンダに対してシステムやサービスの提案を求めるために交付する公式文書です。IPAの学習教材「調達計画・実施」では、RFI（情報提供依頼書）による市場調査を経たあと、実際の調達フェーズで作成するものと位置づけられています（出典: IPA学習教材「調達計画・実施 RFI、RFPなど」）。複数の実務解説資料に共通する標準の記載項目は、背景と目的、現状の課題、目標とKPI、機能要件、非機能要件、納期、予算規模、選定基準、提案書の提出条件、問い合わせ窓口の10項目です。
名義と権限は、このうち非機能要件または前提条件に当たります。項目として独立していないため、書き漏らしやすい箇所です。
RFPに書く文面の例
次のように、事実として1行ずつ書きます。交渉の余地を残す書き方にしないほうが、提案が揃います。
【前提条件：契約名義と権限】
- ドメインは当社名義で当社が取得し、当社が支払います。
- サーバは当社名義で契約し、当社が支払います。
- サーバの管理画面は、当社が最上位の権限を保持します。
貴社には運用に必要な権限を当社から発行します。
- Googleアナリティクスおよびサーチコンソールは、
当社のアカウントを所有者とします。
- 上記が困難な構成を提案される場合は、その理由と、
将来サイトを移す際の手順・所要日数・費用を提案書に記載してください。
最後の1文が効きます。制作会社が自社のサーバでまとめて運用する構成を持っている場合、それを頭から排除せずに条件を出させられます。
RFPの作成では、要件を細かく書きすぎると特定のベンダの仕様に寄り、抽象的すぎると見積もりがばらつくという指摘があります。機能要件は何を実現したいかを中心に書き、実現手段はベンダの提案に委ねる形が推奨されています。ただし名義と権限は実現手段ではなく前提条件です。ここは具体的に書いて構いません。
契約書に書く文面の例
契約書では、次の3か所に分けて書きます。
| 書く場所 |
書く内容 |
| 成果物の条項 |
納品物にドメインとサーバの設定情報、権限の一覧を含めること |
| 役割分担の条項 |
契約者と支払者、管理画面の権限の割り当て |
| 契約終了時の条項 |
権限の返還、データの引き渡し形式と期限、費用の有無 |
文面の例は次のとおりです。
（契約終了時の取扱い）
本契約が終了した場合、乙は甲に対し、
甲のサイトに係るファイル一式およびデータベースを、
終了日から10営業日以内に電子データで引き渡すものとする。
また乙は、甲のサーバおよび各種アカウントに対して
保有する権限を、終了日をもって返還するものとする。
本項に定める作業に係る費用は、別途見積もりによる。
日数と費用の扱いを書いておくのが要点です。「速やかに」と書くと、終わるときに解釈が分かれます。
つまずきやすい点は、契約書の雛形が制作会社から提示される場合です。名義に関する条項が入っていないことは珍しくありません。入っていなければ、追記を依頼してください。RFPに書いてあれば、追記の根拠になります。
名義とあわせて決めておくと後が楽な項目は何ですか
セキュリティ要件と、公開後の脆弱性への対応範囲です。どちらも名義と同じく、発注前に書面にしておかないと後から交渉になります。名義の取り決めと同じRFPの前提条件に並べて書けます。
なぜこの2つかというと、緊急時に必要な権限と重なるためです。前のセクションで触れた「止める操作とログを取り出す操作」は、セキュリティの対応範囲を決めないと誰がやるのか決まりません。
発注時に参照できる公的な基準
自社で基準を作る必要はありません。IPAが公開している資料を参照先として指定できます。
| 資料 |
使い方 |
| IPA「情報システム・モデル取引・契約書（第二版）」 |
契約書の条項の書き方の参照先にします |
| IPA「安全なウェブサイトの作り方」 |
実装で対策すべき脆弱性の一覧として指定します |
| IPA「中小企業の情報セキュリティ対策ガイドライン」 |
社内の体制と運用の確認に使います |
IPA「情報システム・モデル取引・契約書」第二版と、セキュリティ仕様策定プロセスは2020年12月22日に公開されています（出典: IPA「情報システム・モデル取引・契約書（第二版）」）。「中小企業の情報セキュリティ対策ガイドライン」第4.0版には、付録が8件用意されています（出典: IPA「中小企業の情報セキュリティ対策ガイドライン」）。そのまま様式として使えるため、自作より早く進みます。
ウェブサイトが対象になる脆弱性は、実際に多く届出があります。IPAの届出状況によると、2004年7月8日の受付開始から2026年6月末までの累計届出件数は20,315件で、うちウェブサイトに関する届出が13,599件、ソフトウェア製品に関する届出が6,716件でした。累計の約7割がウェブサイトに関する届出です（出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況[2026年第2四半期]」）。
直近の四半期でも届出は続いています。2026年第1四半期（1月から3月）の届出は合計208件で、内訳はソフトウェア製品が139件、ウェブサイトが69件でした（出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況[2026年第1四半期]」）。
内容の傾向も公開されています。クロスサイト・スクリプティングは、届出の受付開始から2014年第4四半期までのウェブサイトの届出件数に対して約5割を占めていました（出典: IPA「安全なウェブサイトの作り方 1.5 クロスサイト・スクリプティング」）。RFPでは「安全なウェブサイトの作り方に挙げられた脆弱性への対策を実装すること」と書けば、個別に列挙する必要がありません。
公開後の対応範囲の決め方
公開後に脆弱性が見つかった場合、誰が何をどこまで行うかを決めます。次の4点です。
- 誰が見つけるかです。定期的な確認を行うのか、指摘があってから動くのかを決めます。
- 対応の期限です。重大なものは何時間以内、それ以外は何営業日以内という形で分けます。
- 費用の扱いです。実装の不備が原因の場合と、使用しているソフトウェアの更新が原因の場合で分けるのが実務的です。
- 緊急時に自社が行える操作です。サイトの公開停止と、ログの取り出しの2つを指定します。
4点目は名義の取り決めと直結します。サーバの管理画面に自社が入れる状態にしてあれば、この2つは自社でできます。名義を自社にする意味が、ここで具体的な操作として現れます。
つまずきやすいのは3点目です。原因の切り分けは後から見ると曖昧になりがちです。「制作会社が実装したコードに起因する場合」と「利用しているCMSやライブラリの提供元が公表した脆弱性に起因する場合」のように、原因の種類で分けて書いてください。
ホームページ制作の発注条件の整理からご相談いただけます
当社は名義と権限の取り決めを含めて、発注条件の整理からお手伝いできます。制作を受注する立場ですが、条件の整理だけのご相談も承っています。
名義の話が後回しになるのは、発注の前に確認する項目としてどこにも書かれていないためです。費用、納期、デザインは見積書に並びますが、ドメインの名義人は並びません。並ばない項目は、決めないまま進みます。
決めないまま進んだ結果が表に出るのは、数年後に制作会社を変えるときです。そのときには、名義の変更に手続きと交渉が必要になります。最初に1時間かけておけば済んだことに、数週間かかります。
当社が制作を承る場合も、ドメインとサーバはお客様名義での契約をお願いしています。管理画面の最上位の権限もお客様にお持ちいただき、当社は運用に必要な権限をいただく形です。解約時に引き渡すものと期限は、契約書に書きます。
対応できる範囲は次のとおりです。
- RFPの前提条件の章の作成（名義、権限、セキュリティ要件、公開後の対応範囲）
- 制作会社から提示された契約書の、名義と契約終了時の条項の確認
- ドメインとサーバの申し込みの同席、および権限設計の設定支援
- 解析ツールとサーチコンソールの自社アカウントの初期設定
- すでに制作会社名義になっている場合の、移管の段取りの整理
費用と期間は、対象の範囲によって変わるため案件ごとのお見積りになります。RFPの前提条件の作成だけであれば短期間で終わります。
これから発注する段階で何を決めておくべきか整理したい場合は、無料診断で現状を伺い、RFPに書く項目をまとめてお返しします。制作費用に補助金を使えるかは補助金のご案内をご覧ください。
よくあるご質問
この記事に関して多い質問と回答をまとめます。
ドメインを制作会社の名義で取得されてしまいました。自社に移せますか
移せる場合が多いところですが、相手の協力が必要です。ドメインの移管は、現在の登録者側で手続きを進めてもらう流れになります。まず制作会社に、移管に応じてもらえるか、費用が発生するか、所要日数はどのくらいかを書面で確認してください。移管の作業中はメールの設定にも影響が出るため、切り替えのタイミングも併せて決めます。
サーバの契約も自社名義にしたほうがよいのですか
そのほうが後が楽です。サイトの公開を止める判断とログの取り出しを自社でできるためです。ただし制作会社が自社のサーバでまとめて運用する構成の場合、名義を自社にすることが仕組みとしてできません。その場合は、将来サイトを移す際にファイル一式とデータベースを渡してもらえるか、形式と日数、費用を書面で確認してください。
制作会社に管理を任せるのに、名義だけ自社にするのは失礼ではありませんか
失礼には当たりません。名義を自社にすることと、運用を任せることは別の話です。契約と支払を自社が行い、日々の作業は制作会社が行う形は一般的です。当社も制作を承る場合、お客様名義での契約をお願いしています。断られる場合は、理由を確認してから判断してください。
Googleアナリティクスのデータは、制作会社から引き継げますか
見られるようにすることはできますが、自社のプロパティへ移すことは難しいところです。制作会社のアカウント配下に置かれたまま、自社に権限を追加してもらう形になります。制作会社が権限を外すと見られなくなります。新しく自社のプロパティを作る場合、溜まるのは作成後のデータだけです。これから発注する段階なら、計測の設定前に自社アカウントを用意してください。
名義を自社にすると、障害対応が遅くなりませんか
権限の設計を先に決めておけば遅くなりません。自社が最上位の権限を持ち、制作会社には運用に必要な権限を渡す形にすれば、日々の作業は従来どおりです。遅くなるのは、制作会社に何の権限も渡していない場合です。誰にどの権限を渡すかの一覧を作り、発注時に共有してください。
契約書の雛形に名義の条項がありません。追記を頼んでよいのですか
頼んで構いません。名義に関する条項が入っていない雛形は珍しくありません。RFPの前提条件に書いてあれば、それを根拠に追記を依頼できます。追記を求める箇所は、成果物の条項、役割分担の条項、契約終了時の条項の3か所です。契約終了時の引き渡しは、日数と費用の扱いまで書いてもらってください。
関連リンク