ホームページの修正を外注しない方法｜AIへの指示で4か月128回更新した記録

サイトの小さな修正、そのたびに制作会社の返事を待っていませんか？

ボタンの文言を1つ変えたいだけなのに、連絡して、見積もりを待って、反映は来週。そんな経験がある方も多いのではないでしょうか。

ムジンにも、似た場面がありました。サイトの端に出る申込バナーの閉じ方が、どうもしっくりこなかったのです。

「×で閉じたらしばらく出さない」にして、次は「閉じても小さなタブに畳む」にして、最後にそのタブを大きくしました。1日のうちに、何度も直しています。

頼んだ相手は、制作会社ではなくAIです。制作会社に頼む運用だったら、ここまで細かくは試せなかったと思います。

ムジンは自社サイト mujin.ltd を作り変えてから、修正をすべてAIへの日本語の指示で行っています。

そこで、本番に出した修正128回を全部数えました。どんな修正が多いか、どのくらいの間隔で出しているか、どこでつまずいたか。実際の記録からお話しします。

AIでサイトを直すって、エンジニアがいる会社だけの話じゃないんですか？

128回のうち117回は、1人の担当者が日本語の指示で出したものです。

本当に、制作会社には一度も頼んでいないんですか？

はい。4か月で依頼は0回でした。数え方は、このあと順にお見せします。

まずは、何を数えたのかからお話しします。

対象は、ムジンのコーポレートサイト mujin.ltd です。期間は、新しいサイトの土台を作った2026年7月11日から11月3日まで。この116日間に本番へ反映した修正を、GitHubの記録から1件ずつ数えました。GitHubは、サイトのソースを管理している場所です。

使っているのは、Anthropic社のAI「Claude」を手元のパソコンで動かす Claude Code です。直したい内容を日本語で伝えると、AIがファイルを書き換えて、確認用のページを作ってくれます。問題がなければ、そのまま本番に反映します。

なお、サイトにAIチャットを載せる話ではありません。サイトを直す作業そのものをAIに頼む、という運用の記録です。

「毎日ちょこちょこ直している」つもりでいましたが、記録を見ると違いました。次の図を見てください。

4か月で128回。そのうち10月だけで96回、全体の75.0%です。

7月は作り変えた直後で21回でした。8月と9月は6回と4回で、ぐっと落ち着いています。修正があった日も、116日のうち31日だけでした。

10月は、新しいサービスページの公開、トップページの作り直し、業種別のセミナー情報ページの立ち上げが重なった月です。

修正は毎日少しずつではなく、施策が動く月にまとめて出ていました。

この波は、制作会社に頼む運用とは相性がよくありません。普段は月に数回で済むのに、施策の月だけ何十回も直したくなる。月額の保守契約では足りず、都度の見積もりでは間に合いません。

社内でAIに頼む形にしてからは、直したい月にだけ多く直せばよくなりました。

制作会社と比べるなら、1回の単価より回数を見るのがおすすめです。過去1年に「直したかったのに我慢した修正」まで書き出すと、止まっていた施策が見えてくるはずです。

128回も直すって、そんなに直すところがあるんですか？

3割近くは、ムジン独自のページの機能追加です。残り91回が、どの会社にもある修正です。

どの会社にもある修正なら、文言の直しが一番多そうですけど。

それが違いました。文言は12回で、上位ではありません。

128回の中身を、変更に付けたタイトルから8つの種類に分けました。1件は1つの種類にだけ入れています。

結果は次の図のとおりです。

いちばん多いのは、業種別のセミナー・資料情報ページの機能追加です。37回（28.9%）でした。

これは、BtoB企業のメルマガやセミナー告知を集計して、ムジンが独自に作っているページです。絞り込みやグラフを、ひたすら足し続けました。

一般の会社のサイトにはない修正なので、ここは除いて考えます。残りの91回が、サイトの通常の修正にあたります。

▼このページのもとになった集計は、こちらの記事で詳しく書いています。

BtoBメルマガ2,447通を全件調査｜件名・配信時間・文字数・ボタンの実態

目立つのは申込導線と見た目

通常の修正でいちばん多いのは、申込導線の23回（18.0%）です。僅差で、写真・動画・レイアウトなどの見た目が22回（17.2%）と続きます。

申込導線とは、申込みにつながる部分のことです。フォームの差し替え、申込ボタンの文言と行き先、画面の端についてくる追従バナーの出し方などが入ります。

冒頭のバナーの話も、ここに入ります。

10月12日、1時間14分のあいだに閉じ方を4回直しました。直したページは2つです。

最初は「×で閉じたら14日間出さない」。次に「閉じても消さずに小さなタブに畳む」。最後に「畳んだタブを大きくする」でした。

制作会社に頼んでいたら、こうした調整は1回の依頼にまとめて出していたはずです。ただ、まとめて出すと、どの変更が効いたのか分かりません。

1つずつ出して、1つずつ確かめられる。これが社内で回す一番の利点です。

文言の修正は意外と少なかった

文言の修正は12回（9.4%）で、思ったより少ない結果でした。

中心は、見出しの言い換えやページの呼び名の変更です。たとえば「お役立ち情報」を「インタビュー」に変えました。

数は少なくても、1回の重みは大きい修正でした。

でも、AIに頼むと1回ごとに時間がかかりそうです。

続けて出した修正の間隔は、中央値で約10分でした。

10分？それ、ちゃんと確かめているんですか？

1回の変更が小さいので、確かめる量も少なくて済みます。

1回の修正は、どのくらいの大きさなのか。続けて直すとき、どのくらいの間隔で本番に出ているのか。

まずは大きさです。1回の修正で変えたファイルの数を数えました。次の図を見てください。

いちばん多いのは、ファイル1つだけの修正で45回です。中央値は2つでした。

128回中73回（57.0%）が、2ファイル以下の変更です。

サイト全体を作り直すような変更は、まれでした。ほとんどは「この見出しを変える」「このボタンの色を変える」くらいの小さな修正です。

続けて出すと、間隔は約10分

次は間隔です。3時間以内に続けて本番に出た91組について、前の修正からの時間を数えました。

中央値は約10分です。4分の1は約4分以内に、4分の3は約31分以内に、次の修正が出ています。

なお、これは本番に出た時刻の間隔です。1回の作業時間そのものを測ったわけではありません。それでも、見積もり待ちで1週間空くのとは桁が違います。

分かりやすいのが7月22日です。次の図を見てください。

朝3時台から、導入事例への導線を一時的に隠し、メニューの並びを変え、お問い合わせフォームを差し替えました。

さらに申込完了ページを作り、予約カレンダーを埋め込むところまで。11回を、1時間47分で出しています。

11回のうち9回は、変えたファイルが2つ以下でした。

逆に、見た目を決めながらの修正は時間がかかります。10月3日にはトップページの写真を3回差し替えました。最初から最後まで、3時間ほどです。

小さく出すから、気軽に捨てられる

小さく分けて出すのには、理由があります。変更が小さければ、確かめるのも、うまくいかなかったときに戻すのも簡単だからです。

実際、AIが作った変更のうち6件は、本番に出さずに取りやめました。

追従バナーの中身を一度別の案内に差し替えて、3日後に元のバナーを位置を変えて戻したこともあります。

小さく試して、合わなければ捨てる。この往復が気軽にできるのは、1回の修正が小さいからです。

とはいえ、AIが変なコードを書いて壊したりしませんでした？

4か月のつまずきは5つです。どれもAIのコードの誤りではありませんでした。

じゃあ、何でつまずいたんですか？

「直ったと思ったのに、直っていなかった」場面です。

4か月の運用で起きたつまずきを、5つ挙げます。

実は、どれも「AIが間違ったコードを書いた」話ではありません。人とAIのあいだの確認が抜けた話です。

修正が本番に届くまでの流れのどこで起きたかを、次の図にまとめました。

5つのうち3つは、AIが書き換えたあと、本番に反映するところから先で起きています。「直ったと思ったのに、直っていなかった」場面です。1つずつ見ていきます。

本番の更新が、静かに失敗していた

10月3日のことです。確認用のページでは正しく表示されていたのに、本番の組み立てだけが失敗していました。

サイト自体は動いていたので、誰も気づきません。3日前の内容が、そのまま出続けていました。

いまは、反映したあとに本番のページを開くところまでを1回の修正にしています。直した文言や画像そのものを、自分の目で確かめます。

Notionを直しても、サイトが変わらない

mujin.ltd は、記事や導入事例の原稿をNotionで管理しています。

ただ、ページが作られるのは公開の操作をしたときです。Notionを直しただけでは、サイトは変わりません。

そこで、原稿を直したら公開の操作までを、ひと続きの手順にしました。

画像が、一部の画面幅だけ古かった

サイトは画面の幅に合わせて、大きさの違う画像を出し分けています。差し替えたはずなのに、その一部だけが古いまま残っていました。

1つの画面幅だけで「直った」と判断すると、こうした古い画像を見落とします。画像を替えたときは、パソコンとスマートフォンの両方で確かめます。

指示があいまいで、別のページを直した

mujin.ltd には追従バナーが3種類あり、ページごとに別のものが出ています。

あるページのバナーを頼んだところ、AIは別のページのバナーを直して、本番に出してしまいました。

いまは「どのページの、どの部分か」を指示に必ず書きます。迷ったら手を付ける前に聞き返すよう、AIにも決めてあります。

新しいページが、転送設定に巻き込まれた

作り変えのとき、古いアドレスを新しいページへ自動で転送する設定を入れました。

この設定が、新しく足したページまで別のページへ飛ばしてしまうことがあります。ページを足すときに必ず確かめる項目として、作業メモに書いてあります。

失敗のたびに、その対策をAIが毎回読む作業メモに書き足しています。同じつまずきを2回しないための仕組みです。

いちばん怖かったのは、AIの間違いより「反映されたつもり」でした。

社内でAIに頼む運用を始めるなら、ムジンが4か月でたどり着いた手順を使ってみてください。

どこまで社内でやるか

全部を社内で済ませるわけではありません。ムジンがサイトのAI化実装支援で案内している線引きは、次のとおりです。

文章の直し、画像の差し替え、ページの追加、申込ボタンの調整。こうした日常の更新は、社内でAIに頼みます。

デザインを大きく作り替える場合や、予約機能・会員機能のような仕組みを新しく足す場合は、人が設計します。

作り変えたあとに残る費用は、サイトを公開しておくためのサーバー代と、AIの利用料です。

mujin.ltd の128回も、半分以上は2ファイル以下の小さな修正でした。日常の更新の多くは、社内でAIに頼む範囲に収まります。

始める前のチェック手順

1. 過去1年に出した修正と、我慢した修正を書き出して回数を数える
2. 修正を「文言」「見た目」「申込導線」「ページ追加」に分け、多いものを見る
3. 月ごとの波を見て、施策が動く月に何回直したかったかを確かめる
4. 1回の依頼には、1つの変更だけを書く
5. 指示には「どのページの、どの部分を、どう変えるか」を書く
6. 反映したら本番のページを開き、直した箇所そのものを目で確かめる
7. 画像を替えたら、パソコンとスマートフォンの両方で確かめる
8. Notionなどで原稿を直したら、公開の操作まで続けて行う
9. 失敗したら、その対策をAIが毎回読む作業メモに書き足す

AIを使うとホームページの修正費用はいくら？

ムジンでは、制作会社への修正費用は4か月で0円でした。128回の修正を、すべて社内で行ったためです。残る費用はサーバー代とAIの利用料で、どちらも使った分に応じた金額です。サイトの規模と更新の量によって変わります。

社内にエンジニアがいなくても回せますか？

mujin.ltd の128回のうち117回は、1人の担当者が日本語の指示で出しました。手を動かしたのは、社内の4人だけです。必要なのはコードの知識より、どこをどう直したいかを言葉にできることです。

今のサイトのアドレスや検索順位はどうなりますか？

ムジンでは、変わるアドレスを古いアドレスから自動で転送する設定を入れて作り変えました。ただ、この設定は新しく足したページにも影響することがあります。ページを足すたびに確かめています。

今回いちばんの発見は、修正が「毎日少しずつ」ではなく、施策が動く月にまとめて出ていたことです。10月だけで96回。この波に合わせて直せたのは、1回ずつの修正が小さく、社内で約10分おきに出せたからでした。

最後に、要点をもう一度だけ並べます。

• 修正は施策の月にまとめて出ます。4か月で128回、10月だけで96回でした。
• 1回の修正は小さく、続けて出したときの間隔は約10分です。
• つまずいたのはAIより、「反映されたつもり」の確認でした。

まずは、過去1年に「直したかったのに我慢した修正」を書き出してみてください。単価の比較では見えなかった、止まっていた施策の数が見えてくるはずです。

ムジンの旧サイトは、制作ツールのSTUDIOで作っていました。見た目をそのまま再現したうえで、AIが扱える形に作り変えています。他社が制作したサイトや、WordPressなどで作ったサイトでも同じ形にできます。

今のサイトの見た目はそのままに、日本語の指示だけで直せる状態へ作り変える支援を行っています。ページのURLを送るだけで、自社のページ1枚をAIで直せるお試しページを無料でお作りします。サイトのAI化実装支援からお申し込みください。

調査の方法

• 対象は、ムジン株式会社のコーポレートサイト mujin.ltd です。期間は、2026年7月11日から11月3日までの116日間です。
• GitHub上で本番に取り込まれた変更（プルリクエスト）を1件＝修正1回とし、128件を数えました。ファイルの数は、各変更で書き換えたファイルの数です。
• 修正の種類は、変更のタイトルを読んで8つに分けました。複数にまたがる変更は、主な1つに入れています。
• 修正の間隔は、3時間以内に続いて本番に取り込まれた91組の、取り込み時刻の差です。
• 失敗と対策は、運用中に社内で残した作業メモから拾いました。