制作会社に任せているサイトをAIで自動更新できるのか、確認すべき権限と契約は何か

公開日：2026-11-05／AnchorUp コラム

結論：制作会社に任せているサイトでも、AIによる更新は可能な場合があります。ただし、できるかどうかは、まず誰が権限を持っているかと、契約が更新や改変を認めているかで決まります。 確かめる順番は、ドメイン、サーバー、CMS（記事を管理する画面）、ソースコード、そして契約書です。

記事の下書きならCMSの投稿権限で足りることが多く、プログラムの修正になるとソースコードの権限と検査の仕組みが要ります。公開ページを読むだけの点検なら、権限がなくても始められます。

この記事では、サイトの担当を兼任している方が、自社の状況を確かめられるように順番に整理します。

自動更新には、どんな権限が必要なのか？

やりたい更新の種類で、必要な権限が変わります。 まず次の表で、自社がやりたいことの行を探してください。

表の下の行ほど、失敗した時の影響が大きくなります。最初は上の行から始めるのが安全です。点検なら、結果を見て人が直すだけなので、制作会社との取り決めを変えなくても試せます。

権限の持ち主はどこで確かめるのか？

ドメイン、サーバー、CMS、ソースコードの4つを、「契約者は誰か」「管理者の情報を自社が持っているか」で確かめます。

JPドメインを管理する JPRS は、「ドメイン名の登録者などに関する情報を誰でも参照できるサービスがWhoisです」と説明しています。自社のドメイン名を検索するだけなので、今日すぐに確かめられます。.com などは登録者が表示されないことがあるので、その時は契約先の管理画面や請求書で確かめます。

WordPressなら、どの権限をAIに渡せばいいのか？

管理者の権限は渡さず、下書きまでなら投稿者より弱い役割を使います。 WordPress の公式説明では、役割ごとにできることが分かれています。

AIには「寄稿者」の専用アカウントを作って渡すと、下書きまでは自動で進み、公開は人が行う形になります。公開の仕組みそのものが止めてくれるので、AIへの指示だけに頼るより安全です。

外部から操作する時は、アプリケーションパスワードを使います。これはユーザーの編集画面で発行でき、不要になれば取り消せます。社員のログインパスワードをそのままAIに渡す必要はありません。送信は https のサイトで行います。

ソースコードが Git にある場合は何を見るのか？

「誰が書き込めるか」と「本番に入る前に検査が通るか」を見ます。 GitHub なら、保護ブランチの設定で、承認を得てからでないと本番用のブランチへ統合できないようにできます。非公開のリポジトリで使うには有料プランが要ります。

また、「デプロイキー」と呼ばれる鍵にも注意が要ります。GitHub の説明では、秘密鍵を持つ人は、組織から外された後でも、鍵の設定に応じてリポジトリの読み取りや書き込みができるとされています。自動更新の鍵を発行する時は、誰が持っているかを記録し、担当の変更や契約の終了の時に作り直してください。

FTP でサーバーへ直接ファイルを置いている場合は、変更がそのまま本番に出ます。AIに修正させるのはおすすめしません。先に検査してから反映する環境を用意するか、点検と下書きまでに留めるのが現実的です。

契約書のどこを見ればいいのか？

著作権の帰属、改変の可否、保守の範囲の3か所です。 権限があっても、契約が認めていなければ進められません。

特に見落としやすいのは、「著作権を譲渡する」とだけ書かれた契約です。著作権法第61条第2項は、第27条または第28条の権利が譲渡の目的として特掲（特に書くこと）されていない時は、譲渡した側に留保されたものと推定すると定めています。第27条は翻案などをする権利です。文章やコードに手を加える作業がこれに当たる可能性があるので、第27条・第28条の番号か、翻案権などの権利の名前が書かれているかを確かめてください。

第20条は、著作者が意に反して変更や改変を受けない権利を定めています。譲渡とは別の権利なので、不行使の定めがあるかも見ておきます。判断が難しい条項は、この時点で弁護士に確認する価値があります。

契約書が見当たらない時は、発注書と見積書、メールでの合意を集め、制作会社に現在の取り決めを確認してください。

自動で更新すると検索で不利にならないのか？

AIを使うこと自体ではなく、読者に価値のないページを大量に作ることが問題になります。 Google は、ユーザーにとっての価値を付加することなく大量のページを生成すると、スパムポリシーに違反する可能性があると説明しています。

また、生成AIの出力には不正確な情報が含まれる可能性があるとして、公開前に手動でファクトチェックを行うことが重要だとしています。自動で公開まで進めるなら、事実の確認をどの段階で行うかを先に決めてください。

自動で反映する範囲はどう決めるのか？

失敗した時の影響が小さいものだけを、検査を通した時に限って反映します。 参考までに、AnchorUpの自社サイトでの分け方を示します。これは自社サイトと社内の仕組みの話で、お客様の案件ではありません。

• 技術ブログの記事は、定期実行のAIエージェントが作ります。本番へ直接反映せず作業用の場所（ブランチ）へ送り、公開前検査に合格した記事だけを公開します
• 公開前の機械検査では、テーマの重複、字数、リンク先、一次情報の出典と引用文などを確かめ、その後にサイトの組み立て（ビルド）とAIによるレビューを行います。1つでも落ちたら公開しません
• 保守の11本のルーティン（定期的に動く作業）のうち、人の確認なしで統合（マージ）するのは不要なコードの削除、不要なテストの削除、不安定なテストの修正の3本だけで、残りは人が確認します
• この自動の統合は、変更が150行未満で、許可されたファイルだけを変更し、ページの経路（ルート）とサイトマップの URL が減らない場合に限っています

この形は Git と検査の仕組みがある環境の話です。そのままの形でなくても、「AIの作業場所と本番を分ける」「反映の条件を先に決める」の2点は、どの環境でも使えます。

制作会社には何を聞けばいいのか？

次の7つをメールで聞くと、自社で判断する材料がそろいます。

1. ドメインとサーバーの契約者は誰か
2. 自社が持っているCMSアカウントの役割は何か
3. ソースコードはどこにあり、自社に控えを渡してもらえるか
4. 成果物の著作権の帰属はどう定められているか
5. 自動更新のツールでCMSやコードに触れてよいか
6. ツールが変更した部分に障害が起きた時、保守の対象になるか
7. 更新の前に戻せるバックアップはどの頻度で取っているか

制作会社の側にも、納品物の品質や保守の責任を守る事情があります。「誰が何に責任を持つか」を一緒に決める相談として切り出すと、話が進みやすくなります。

まとめ

• 可否は技術よりも、権限と契約で決まる
• 点検は権限なしで始められ、下書きは「寄稿者」の専用アカウントで止められる
• 「著作権を譲渡する」の一文だけでは、改変に関わる権利が残っている可能性がある
• 自動で反映する範囲は、影響が小さいものに絞り、検査の条件を先に決める

AnchorUpでは、こうした判断のご相談を受けています。相談内容を送る

参考（一次情報）

• Whois の説明（JPRS）
• Roles and Capabilities（WordPress Documentation）
• Authentication（WordPress REST API Handbook）
• Application Passwords: Integration Guide（Make WordPress Core）
• About protected branches（GitHub Docs）
• Repository roles for an organization（GitHub Docs）
• 著作権法（日本法令外国語訳データベースシステム、法務省）
• 生成 AI によるコンテンツを使用するための Google 検索のガイダンス（Google）

コラムの一覧へ／相談する