「AIに頼んでも、結局うち用に直している」——制作会社でClaudeを戦力にするための下ごしらえ

「AIに修正依頼の文面を書かせても、結局そのままでは使えないんです」

Web制作やWeb運用の現場では、そんな声を聞くことがあります。

たとえば、次のような使い方です。

• 修正依頼の文面をClaudeに下書きしてもらう
• 公開前のチェックリストを作らせてみる
• GAの数字を貼って、クライアント報告用に要約させる
• CMS更新前に、影響がありそうな箇所を洗い出させる

本来なら、作業が速くなるはずです。

けれど実際には、返ってくるのはどこにでもある一般論。

「うちのクライアントには、この言い方だと合わない」
「このCMSの制約を分かっていない」
「結局、いつもの書き方に直している」

そうして、気づけば二度手間になっている。

私たちも、Web運用の現場で同じような課題を感じてきました。

AI自体は便利です。けれど、現場でそのまま使える状態にするには、ただプロンプトを工夫するだけでは足りないことがあります。

必要なのは、AIに渡す前提を整えることです。

この記事では、制作会社のディレクターやWeb担当の方に向けて、ClaudeなどのAIを「使える同僚」に近づけるための下ごしらえを整理します。

なぜこの課題が起きるのか

AIに頼んでも一般論しか返ってこないのは、AIの性能が低いからとは限りません。

多くの場合、原因はもっとシンプルです。

AIが、あなたの現場の前提を知らないまま答えているからです。

背景1：クライアントごとに「正解」が違う

制作会社の仕事では、クライアントごとに前提が違います。

たとえば、次のようなものです。

• 表記ルール
• トンマナ
• 禁止表現
• CMSの制約
• 修正依頼の出し方
• 公開前に必ず見る項目
• 触ってはいけない設定や領域

同じ「トップページの見出し修正」でも、クライアントによって求められる伝え方は変わります。

あるクライアントでは、かなり実務的で簡潔な文面が好まれる。
別のクライアントでは、背景や意図まで丁寧に書く必要がある。
また別の案件では、CMSの構成上、触ってはいけない領域がある。

ところが、AIに何も渡さずに依頼すると、AIはその違いを判断できません。

そのため、返ってくる文章はどうしても一般的になります。

間違ってはいない。
でも、現場ではそのまま使いにくい。

そんな出力になりがちです。

背景2：毎回チャットで説明していると、属人化しやすい

AIにうまく指示できる人と、そうでない人で出力が変わる。

これも、制作会社でAIを使うときに起きやすい課題です。

毎回チャットで、

「このクライアントはこういうトーンで」
「この表現はNGで」
「修正依頼はこの型で」
「このCMSではここを触らないで」

と説明していると、使う人によって情報の渡し方がバラつきます。

あるディレクターは丁寧に前提を伝える。
別の担当者は短い指示だけで済ませる。
別の人は、重要なNGルールをうっかり入れ忘れる。

その結果、AIの出力品質が人によって変わります。

さらに、その前提が個人のメモやPCの中に閉じていると、チーム全体のAI活用にはつながりにくくなります。

だからこそ、AIに渡す前提を一度整理し、チームで使える形にしておくことが大切です。

解決するためのSTEP

ここからは、制作会社でClaudeなどのAIを実務に馴染ませるために、私たちが重要だと感じている下ごしらえをSTEPで整理します。

ポイントは、毎回プロンプトをがんばることではありません。

クライアントごとの前提を見える形にして、繰り返し使える状態にすることです。

STEP 1：現状を可視化する

まずは、案件やクライアントごとの前提を可視化します。

いきなり完璧なルール集を作る必要はありません。

最初は、CLAUDE.mdのようなプロジェクト用メモに、AIへ渡したい情報を1枚でまとめるだけでも十分です。

Web制作・Web運用の現場なら、たとえば次のような項目を整理しておくと、出力が変わりやすくなります。

表記ルール

たとえば、次のような情報です。

• 「Web」は大文字始まりにする
• 社名・サービス名は正式表記に合わせる
• ですます調／である調を統一する
• 使ってはいけない言葉を入れる
• 英数字や記号の表記ルールをそろえる

トンマナ

たとえば、次のような指定です。

• 制作会社のディレクター向けに書く
• 煽らない
• 実務寄りに書く
• カジュアルにしすぎない
• 成果を大きく見せすぎない

公開前チェックの必須項目

たとえば、次のような項目です。

• 価格
• 掲載期間
• リンクの飛び先
• 画像のalt
• 404
• スマホ表示
• フォームの送信確認

修正依頼の型

たとえば、修正依頼では「どこ・どう・なぜ」をセットで伝える、というルールです。

「トップの見出しを直してください」だけでは、相手が判断しにくいことがあります。

どの箇所を、どう変えたいのか。
なぜその修正が必要なのか。

ここまでセットにすると、修正する側も動きやすくなります。

使用している技術と触ってはいけない場所

たとえば、次のような情報です。

• WordPressを使っている
• 特定のテンプレートは変更しない
• この設定は変更禁止
• このブロックはクライアント側で更新する
• この領域は別部署の確認が必要

絶対NG

たとえば、次のようなルールです。

• 効果を断定しない
• 誇張しない
• 存在しない仕様を書かない
• 未確認の数値を使わない
• クライアントが承認していない表現を入れない

ここで重要なのは、「AIに毎回説明していること」を洗い出すことです。

毎回口頭やチャットで補足している内容ほど、前提ファイルに入れておく価値があります。

一度まとめておけば、次回からはAIに「この前提に沿って」と渡しやすくなります。

STEP 2：月次運用として記録・一覧化する

次に、その前提を個人のメモで終わらせず、チームで使える形にしていきます。

一人のディレクターが育てたCLAUDE.mdや公開前チェックの型が、その人のPCの中だけにあると、AI活用は属人化します。

同じクライアントの案件でも、担当者によってAIへの渡し方が変わり、出力の質もバラつきます。

そこで、案件ごとのルール、チェックリスト、確認履歴を一覧で見られる状態にしておくことが大切です。

たとえば、次のようなものを共有できる状態にします。

• クライアント別の表記ルール
• 公開前チェックリスト
• 修正依頼の型
• 過去の確認履歴
• 運用上の注意点
• 触ってはいけない箇所
• 過去に差し戻しになった表現

こうした情報が残っていれば、次回以降は「この前提に沿って」とAIに渡しやすくなります。

私たちがMONJI+で大切にしているのも、まさにこの「現場の前提を残す」という考え方です。

チェックリストの型、運用のルール、確認の履歴をチームで共有できる状態にしておくことで、AIに渡す前提も、人が引き継ぐ前提も、同じ場所からそろえやすくなります。

STEP 3：数カ月分の実績をもとに提案・改善に使う

AI活用は、単に作業を速くするためだけではありません。

前提を整理し、運用の記録を残していくと、クライアントへの説明や提案にも使いやすくなります。

たとえば、公開前チェックの項目、修正依頼の内容、GAの数字をもとにした報告の型などが蓄積されていれば、次のような場面で役立ちます。

• クライアント報告用に、GAの数字を「先週との差」と「考えられる要因」で要約する
• CMS更新前に、影響が出そうな箇所を洗い出す
• リンク切れや誤字の一次洗い出しを行う
• アクセシビリティの観点として、コントラスト、alt、見出し階層を確認する
• 過去の修正履歴をもとに、次回の改善案を整理する

ただし、ここで大切なのは、AIにすべてを任せきらないことです。

AIは、見落としを減らす一次チェックや、叩き台づくりに向いています。

一方で、最終的にどう判断するかは人が握る必要があります。

たとえば、AIがGAの数字を「先週との差」と「考えられる要因」で整理することはできます。

しかし、そこからどの施策を提案するのか。
クライアントにどう伝えるのか。
数字の変化をどう受け止めるのか。

この判断は、人が行うべき部分です。

「AIに任せる所」と「人が握る所」を分けておくことで、速さと安心の両方を保ちやすくなります。

実際に起きた変化

同じAIでも、渡す前提によって出力は大きく変わります。

たとえば、前提を渡さずに「トップの見出しを直す修正依頼を書いて」と頼むと、次のような返答になりがちです。

トップページの見出しを、より魅力的な表現に変更してください。

間違ってはいません。

ただ、これだけでは相手が動きにくいこともあります。

どこを変えるのか。
どう変えるのか。
なぜ変えるのか。

この情報が足りないからです。

一方で、修正依頼は「どこ・どう・なぜ」をセットにする、トンマナは実務寄りにする、という前提を渡しておくと、出力は次のように変わります。

トップの見出し（現：〇〇）を、△△に変更したいです。理由は、ターゲットのWeb担当者に一言で価値が伝わるようにするためです。トーンは煽らず、実務寄りでお願いします。

同じAI、同じような依頼でも、下ごしらえ次第で「そのまま使えるか」「結局書き直すか」が変わります。

プロンプトを毎回工夫する前に、まずは現場の前提を1枚にまとめておく。

それだけでも、AIの出力は自社やクライアントの運用に馴染みやすくなります。

注意点・限界

もちろん、前提を渡せばすべての出力が完璧になるわけではありません。

AIは、公開前チェックの一次洗い出しや、報告文の叩き台づくりには役立ちます。

しかし、次のような判断は人が確認する必要があります。

• その表現がクライアントの意図に合っているか
• 数字の解釈が正しいか
• CMS上で実際に問題が起きないか
• 掲載してよい情報か
• 効果を断定しすぎていないか
• 存在しない仕様や根拠のない表現が含まれていないか
• 公開前に関係部署の確認が必要ではないか

AIは、見落としを減らすための一次チェックには強いです。

一方で、最終判断まで任せると、現場の責任範囲が曖昧になることがあります。

だからこそ、AIを「自動で正解を出す存在」としてではなく、「前提を渡せば、かなり使える叩き台を出してくれる同僚」として扱うのが現実的です。

任せるところは任せる。
ただし、判断は人が持つ。

この線引きがあると、AIを現場に取り入れやすくなります。

現場から生まれたWeb運用プラットフォーム【MONJI+】

AIを実務で使える状態にするには、プロンプトの工夫だけでなく、日々の運用ルールや確認履歴を残しておくことが大切です。

私たちが現場で感じてきた課題を解決するために生まれたのが、Webサイト運用支援プラットフォームMONJI+です。

最初から完成されたものを目指すのではなく、現場のリアルな声と向き合いながら、一つひとつ育ててきました。

MONJI+では、Webサイトの確認や運用に必要な情報を、チームで共有しやすい形に残していくことを目指しています。

AIに渡す前提も、人が引き継ぐ前提も、同じ一か所からそろえられる状態をつくることで、Web運用の属人化を減らしやすくなります。

▼MONJI+について
https://monji.tech/ja/plus/

▼まずは無料ではじめる
30日間の無料トライアルで全機能を試せます。ずっと無料のフリープランもあります。
https://monji.tech/ja/plus/trial/

▼あなたの声もお待ちしています
https://monji.tech/ja/plus/co-creation/

まとめ

ClaudeなどのAIに頼んでも一般論しか返ってこないとき、原因はAIの性能ではなく、現場の前提を渡せていないことかもしれません。

制作会社のWeb運用では、クライアントごとに表記ルール、トンマナ、公開前チェック、修正依頼の型、CMS制約、NG表現が異なります。

それらを1枚の前提ファイルとして整理しておくことで、AIの出力は現場に馴染みやすくなります。

大切なのは、AIにすべてを任せることではありません。

AIは見落としを減らす一次チェックや叩き台づくりに使い、最終判断は人が握る。

その線引きをしたうえで、前提をチームの共有物として残していくことが、制作会社でAIを戦力にするための第一歩になります。