【AI導入日記#5】Claude Code でコーポレートサイトを更新する──修正依頼を外注しない運用

なぜ「サイト修正の外注」をやめる判断をしたのか

AI導入日記の5回目です。今回は、当社が自分たちのコーポレートサイトを Claude Code で運用している話を書きます。先に立場を明かすと、当社は代表がWeb構築に25年携わってきた会社、つまり「サイト修正を受注する側」でした。その会社が自社サイトの修正を外注しなくなった話なので、いくらか自己批判を含みます。

「小さな修正」に、いつも数日かかっていた

きっかけは大きな不満ではなく、誰も文句を言わない程度の小さな遅さでした。たとえばこういうものです。

• サービスページの1行の言い回しを変えたい
• お知らせの日付が1日ずれていたので直したい
• 実績ページに1件だけ追加したい

作業そのものは数分です。ところが実際には、依頼を書く、相手の手が空くのを待つ、確認する、という往復が挟まります。作業時間が短いほど待ち時間の比率が高くなるという逆転が起きていました。

もっと問題だったのは、遅さを見越して「まとめて依頼しよう」と考えてしまうことです。修正が溜まると優先順位づけが必要になり、順位の低いものは着手されません。サイトに小さな古さが積もる原因は、たいていここにあります。

自社サイトを最初の実験場に選んだ理由

Claude 法人導入を進めるにあたり、最初にどの業務へ当てるかは迷いました。見積書のチェックや議事録の要約も候補でしたが、自社サイトの運用を選びました。

理由は3つあります。第一に、結果が目に見えること。文章の要約は良し悪しの判断が分かれますが、サイトは「直っているか、崩れているか」が一瞬でわかります。効果が見えない取り組みは社内で続きにくくなります。第二に、失敗しても取り返しがつくこと。自社サイトならお客様に迷惑をかけずに済みます。第三に、自分たちが売っているものだからです。当社は「机上の空論を売らない」を掲げています。実際の運用内容はWordPressとAIを活用した、日本語指示によるホームページ更新にもまとめています。

外注をゼロにしたのではなく、境界を引き直した

外注を全廃したわけではありません。やめたのは「小さな修正の都度依頼」だけです。デザインの方向性を決める、構造から作り直す、新しいサービスのページを一式起こす。こうした仕事は今も設計から人が行います。

境界の引き方は単純にしました。「何をどう直すかが日本語で言い切れるものは自社で、言い切れないものは設計から人がやる」という線です。言い切れない依頼をAIに投げると、AIは足りない部分を推測で埋めます。その推測がそのまま事故になります。

日本語の指示だけでサイトを直す──実際の流れ

当社のコーポレートサイトは WordPress で動いています。更新は管理画面を人が開いて編集するのではなく、Claude Code に日本語で指示を出して行っています（Claude Code の挙動は2026年7月時点のものです。最新の仕様は公式ドキュメントでご確認ください）。

修正依頼から公開までの6ステップ

1. 依頼を1行で書く：「サービスページの冒頭のリード文を、初めて来た人向けに短くしたい」のように、目的と対象を書きます。
2. 現状を読ませる：該当ページの現在の内容を読ませます。ここを飛ばすと、AIは記憶と推測で書き始めます。
3. 変更案を出させる：いきなり反映させず、変更後の文面や構造を先に出させます。
4. 差分を確認する：どこがどう変わるのかを、変更前と変更後で並べて確認します。
5. 反映する：問題なければ反映を指示します。ここで初めてサイトが書き換わります。
6. 実際の画面で見る：ブラウザで表示を確認します。スマートフォン幅も必ず見ます。

簡単な文言修正なら数分というのが当社の体感です。ただし重要なのは短さそのものではなく、思いついたときにその場で着手できる点でした。待ち行列に入らないので、修正が溜まりません。

指示文は「どこを・どう・どこまで」で書く

運用してすぐ分かったのは、出力の質は指示文でほぼ決まるということです。うまくいかない例は「トップページを見やすくして」です。基準が示されていないのでAIは一般論で判断し、意図していない要素まで作り替えられます。

うまくいく例は「トップページのサービス紹介の3つのカードについて、見出しを15文字以内に短くしたい。本文とレイアウトは変更しない」です。対象・変更内容・変更してはいけない範囲の3点が入っています。この3つ目が、意外と抜けます。

もう一段効くのが判断基準を渡すことです。「短くしたい」ではなく「スマートフォンで2行に収まる長さに」と書くと、AIは自分で検証できます。当社では共通の判断基準を設定ファイルに書き出し、常時読ませています。

反映の前に必ず差分を見る

いちばん効いているルールがこれです。反映前に必ず変更前後を並べて確認します。理由は単純で、AIは頼まれていないことも「ついでに」直すことがあるからです。文言の修正を頼んだのに、周辺の余白の指定まで整えてくれることがあります。善意の改善ですが、こちらの意図と違えば事故です。

逆に言えば、差分を見ない運用は危険です。「AIに任せているので中身は見ていません」は、外注に丸投げしていた頃と何も変わりません。むしろ反映が速いぶん、事故の伝播も速くなります。

事故を起こさないための運用ルール

今回いちばん書きたかった部分です。速く直せることより、壊さないことのほうがはるかに重要でした。

本番に触る前に通す3つのゲート

1. 差分を人が読んだか：読んでいない変更は反映しません。
2. 戻せる状態か：バックアップがあるか、直前の状態に戻す手順が明確か。
3. 確認する人が決まっているか：「あとで誰かが見る」は決まっていないのと同じです。

形式的に見えますが、事故はだいたいこのどれかを飛ばしたときに起きています。特に3つ目が抜けがちでした。速く反映できるので、確認を後回しにしても平気な気がしてしまうのです。

バックアップと切り戻しを先に決める

Claude 法人導入をWeb運用に当てるなら、最初にやるべきはバックアップ体制の確認です。修正を始める前に、次を決めておきます。

• データベースとファイルのバックアップが、いつ・どこに・何世代残るかを把握する
• 大きな変更の前は、その場で手動バックアップを取る
• 「戻す」判断を誰が出せるかを決めておく（迷ったら戻す、を基本方針にする）
• 戻す手順を実際に一度試しておく（試していない手順は、いざというときに使えないことがあります）
• 変更した日時（JST）と内容を1行で記録に残す

4つ目は特に大事でした。手順書があることと、その手順で実際に戻せることは別物です。当社では運用開始前に一度だけ、意図的に戻す練習をしました。

触ってよい範囲・触らせない範囲の線引き

何でも直せる状態は便利ですが、便利さと危うさは同じものです。当社では次のように分けています。

• 触ってよい：本文の文言、お知らせ・記事の追加、既存の型に沿ったページの中身、内部リンクの追加
• 相談してから触る：ページ全体の構造、共通のレイアウト、ナビゲーションの項目
• 触らせない：決済まわり、フォームの送信先、会員情報を扱う部分、テーマ本体のファイル、サーバー設定
• そもそも入力しない：顧客の個人情報、未公開の契約情報、パスワードや接続情報

最後の項目は本シリーズ第3回で詳しく扱っています。Web運用でも例外ではなく、「実績ページに追加したいので契約書をそのまま読ませる」といったことはしません。公開してよい情報だけを渡します。

外注・内製・AI内製を同じ物差しで比べる

社内で説明するとき、感覚的な話だけでは通りません。3つの体制を同じ観点で並べました。内容は当社の体感であり、業種や制作会社との契約形態によって変わります。

3つの体制の比較

効くのは「速さ」より「取りかかるまでの時間」

表を作って気づいたのは、比較すべきは作業時間ではないということです。作業自体は慣れた人が手で直しても数分です。差がついていたのは、思いついてから着手するまでの時間でした。

依頼という工程が入ると、そこに待ちが生まれます。待ちがあると人は「まとめてからにしよう」と考え、優先順位が要り、順位の低いものは実行されません。着手までの時間が短くなるほど、この連鎖は起きにくくなります。

向く作業・向かない作業

向いているのは、繰り返しがあって判断基準を言葉にできる作業です。記事の追加、既存の型に沿ったページ更新、文言の統一、内部リンクの整理、表記ゆれの点検。人がやると単調で漏れやすく、AIがやると安定します。

向いていないのは、感覚で決める部分と、正解が社外にある部分です。ブランドの印象を左右する配色や、ページ全体の骨格の設計は人が決め、AIには決めた内容を正確に実装させるほうが結果が良いというのが実感です。AI×WEB戦略コンサルティングのような、方針そのものを詰める仕事も同じです。

つまずいた4つの失敗と、その対処

ここまで読むと順調に見えるかもしれませんが、実際にはいくつも失敗しています。同じところでつまずく方が減るように、正直に書きます。

レイアウトが崩れた──元のHTMLを持ってこなかった

既存ページと同じ見た目で新しいページを作りたかったのに、出来上がりが微妙に違っていました。原因は、既存ページのHTMLとCSSを実際に読ませず「既存ページと同じ雰囲気で」と指示したことです。AIは指示どおり雰囲気で作ります。お手本にするページの実物を必ず読ませてから作らせるようにしました。以降、この種の崩れはほぼ起きていません。

文言だけのつもりが、構造まで変わっていた

「この段落の言い回しを柔らかく」と頼んだところ、段落が2つに分割され見出しが1つ増えて返ってきました。文章としては読みやすく、危うくそのまま反映するところでした。気づけたのは差分を見ていたからです。以降は「構造は変えないでください」と明示しています。変えてほしくないことは、書かないと伝わりません。

公開日時が意図とずれた

予約公開の日時を指定したところ、意図した時刻と表示がずれました。原因は、指示文に「10時」とだけ書き、どのタイムゾーンかを書いていなかったことです。以降は日時を扱う指示にすべて「JST」を付け、AIに現在時刻を推測させず実際に取得した値を使わせています。地味ですが、公開日が1日ずれると信頼に関わります。

「AIに任せた」つもりで、誰も確認していなかった

いちばん反省した点です。反映が速いので確認が形骸化しかけました。指示した本人は「AIがやったから大丈夫だろう」と思い、周囲は「担当者が見ているだろう」と思います。誰も見ていない状態が生まれます。対処として、更新したら反映後の画面を1度は開くことを固定の手順にしました。数十秒を惜しむと、後から数時間を失います。

これから始める会社が、最初の2週間でやること

ここまでの経験を、これから始める会社向けの手順に落とします。

1週目：読むだけ・書かない

最初の1週間はサイトを更新しません。読ませるだけです。物足りなく感じますが、この期間を置くかどうかで、その後の事故の起きやすさが変わると感じています。

• 自社サイトの主要ページを読ませ、要約させてみる
• 「このページの構成を説明して」と頼み、返答の精度を見る
• 表記ゆれや古い記述を洗い出させる（直させず、一覧にするだけ）
• バックアップの取得方法と、元に戻す手順を確認する
• 触らせない範囲を書き出して、社内で合意する

この段階でAIの返答の癖が分かります。読ませて要約させるだけでも自社サイトの棚卸しができる、という副産物もありました。

2週目：本番の1ページを更新してみる

2週目に実際の更新を1件だけやります。いきなり全ページに広げないのが要点です。対象は影響範囲が小さく、間違っても戻しやすいページを選びます。会社概要の一文や、お知らせの1本が適しています。手順は前述の6ステップをそのまま使い、1件終わったら必ず振り返ります。指示文のどこが足りなかったか、差分で何に気づいたかを書き残すと、次から精度が上がります。

続けるための小さな仕掛け

• 更新のたびに1行だけ記録を残す：日時（JST）、対象、変更内容
• うまくいった指示文を保存する：同じ種類の修正が来たとき使い回せます
• ルールを1か所にまとめる：触らせない範囲や表記の決まりを設定ファイルに書き、毎回読ませます

3つとも数分の作業です。それでも省くと、同じ説明を毎回やり直すことになります。AIに毎回同じことを説明している時間は、積み重なると無視できない損失になります。

自社で進めるか、伴走してもらうか

ここまでの手順は、意欲のある担当者が1人いれば自社でも進められます。ただし「触らせない範囲の線引き」と「バックアップ・切り戻し」の2点は、経験がないと判断に迷いやすい部分です。

当社では Claude 法人導入の支援として、こうした運用設計から実際のサイト更新の立ち上げまでを伴走するメニューをご用意しています。内容はClaude 法人導入支援のサービスページにまとめました。何から始めるべきかを整理したい場合は、無料相談（オンライン・全国対応・所要60分）をご利用ください。売り込みではなく、まず現状の棚卸しからご一緒します。