こんにちは。
and,aの中田です。
代理店・制作会社でWebディレクターをされている方に向けて、
今日は書きます。

4か月前から、
サイト診断という業務に、
Claude Codeを取り入れています。
取り入れてみて気づいたのは、
Claude Codeを使うこと自体より、
使うために自分の観点を書き出す作業のほうが、
業務全体に対して大きな効果があった、
ということです。

プログラミングの知識は必要ありません。


ディレクターが、サイトを見るときに見ているもの

複数のウェブサイトのキャプチャをルーペで観察するイメージ

新しいクライアントから依頼を受けたとき、
最初に手をつける仕事のひとつがサイト診断です。

ヒューリスティック評価(専門家が経験則をもとにサイトの問題点を洗い出す評価手法のことです)、
ユーザビリティ評価、
現状把握。
呼び名は会社によって違います。
やっていることは、
似ています。

クライアントのサイトを開く。
トップから順にページを下る。
フォームを試す。
スマホで開き直す。
ロード速度を測る。
競合の同種ページと並べる。
所感を書く。

一連の作業に、
半日から1日。
これを、
新規キックオフ前、
定期見直し、
コンペの前と、
機会を変えて繰り返してきました。

ここで、
ひとつ興味深いことがあります。
同じサイトを同じ時間で見ても、
ディレクターによって、
出てくる所感がまったく違う
。

新人のAD(アシスタントディレクターのことです)が書いた診断と、
ベテランが書いた診断を並べると、
内容の重なりは半分くらいしかないことが多い。
残りの半分は、
「何を見るか」という観点が、
人によって違うから起きています。

代理店という業態は、
長らくこの観点の差を、
各ディレクターの「腕前」として扱ってきました。
ベテランが新人を3年かけて育てる。
その前提でチームが組まれてきたと思います。


観点は、これまで書き出してこなかった

書きかけで止まっている白紙のノートと万年筆

ディレクターとして、
自分が診断のときに見ている観点を、
文章にして残したことはありますか。

私自身、
過去に何度かこの試みをしました。
新人に渡すために、
自分のチェックリストを書き出そうとしたのです。
けれど、
最後まで完成したことは、
一度もありませんでした。

なぜ完成しないか。
書いている途中で、
補足事項が雪だるま式に増えていくからです。
「この観点は業種によって違うな」「これは前提条件を書かないと伝わらないな」。
結局書き終わらず、
いつも通り、
隣に座って口頭で観点を伝えるやり方に戻る。

この「いつも通り」が、
業界全体で、
人が辞めると消える知識を量産してきました。
ベテランが退職する。
観点も、
まるごと消える。
次の新人を3年かけて育てる。
でも彼が抜けたら、
また3年かかる。

代理店の離職率を考えると、
これは構造的な損失です。

ここに、
Claude Codeが入る余地があります。
4か月の試行を通じて、
そう感じています。


Claude Codeとは何か ── 社外フリーランサーへの仕様書のつもりで書く

外注フリーランサー向けの整理された仕様書、書類フォルダ

Claude Codeをまだ使ったことのないディレクターの方に、
できるだけ実感に近い言葉で説明します。

社外の腕利きフリーランサーに、
初めて仕事を発注する場面を思い浮かべてください。
社内の人間なら目を見て話せば伝わる。
社外の相手には、
仕様書が必要です。

仕様書に書くのは、
こんなことです。
何が必要な情報か。
どこから先は触らないでほしいか。
出力の形式はどれか。
誰の名前を出していいか。
納品はどのフォルダに置くか。

書き上がってしまえば、
そのフリーランサーは仕様書を読んで、
ほぼ独力で仕事を進めてくれます。

Claude Codeとは、
この仕様書を読んで、
その通りに作業を進めてくれる、
社外スタッフのようなもの
です。

仕様書はMarkdown(マークダウン)という、
メモ帳と同じ感覚で書けるテキスト形式で書きます。
一度書けば、
同じ仕様で何度でも仕事を頼める。
書き加えれば、
出力の精度が上がっていきます。

ここで大事なことを1つ。
書くのは仕様書であって、
コードではありません
。
プログラミングの構文も、
開発環境も、
必要ありません。
いつもフリーランサーへの発注書に書いているような、
自然な日本語で書くだけです。


自分のレンズを、業種ごとに書き出してみる

業種別に色分けされた診断観点のドキュメント、複数のタブ

ここからが本題です。

私は現在、
サイト診断の観点を業種別に書き出しています。
それぞれを lens.md というテキストファイルにまとめています。
たとえば、
こんな粒度です。

【EC業種・トップページ診断のレンズ】

  • 1スクリーン目でブランドの世界観が伝わるか(業種柄、ファーストビューが購買意欲に直結)
  • 主力カテゴリの並び順は、購入頻度の高い順か、季節を反映しているか
  • カート遷移の動線が、トップから2クリック以内に置かれているか
  • 在庫切れ表示の出し方が、購買意欲を削いでいないか
  • 初回購入特典の見せ方が、ロード後3秒以内に視界に入るか

これをEC、
BtoB、
メディア、
人材、
不動産、
医療、
士業、
観光と、
業種ごとに20〜30個ずつ書き出しています。

書き出しながら、
何度も気づく瞬間がありました。
「ああ、
こんな観点で見ていたのか」と。
頭の中で当たり前にやっていたことを、
文字にして初めて、
それが知識だったとわかる
。

書き出したファイルを、
Claude Codeにサイト診断を依頼するときに参照させます。
すると、
私が普段見ているのと同じ観点で、
初稿の所感が返ってきます。

完璧ではありません。
業界トレンドを踏まえた判断や、
サイト側の意図を汲んだ柔軟な評価は、
まだ私が手を入れる必要があります。
ただ、
「見落としチェックの一周目」は、
ほぼ私の代わりに回るようになりました。


ADが、私の観点で診断を書いてくる

1つのドキュメントから複数の経路に矢印が伸びる、再利用の図解

これが、
思っていた以上の副次効果を生んでいます。

新人のADにサイト診断の初稿を任せるとき、
渡すのが lens.md です。
Claude Codeに渡すのと、
同じファイルです。

ADはそのファイルを読み、
自分でサイトを開いて、
診断を書きます。
すると、
診断の中に私の観点が混ざってくるようになります。
「ロード後3秒以内に視界に入っているか」「カート遷移は2クリック以内か」。
私が長く使ってきた問いが、
彼らの所感の中に出てくる。

これはClaude Codeを使っているわけではありません。lens.md というドキュメントを、
AD向けの読み物としても使っているだけです。

Claude Codeのために書き出した観点が、
同時に新人教育の教材にもなっている
。

書く対象がClaude Codeだったからこそ、
最後まで書き切ることができた、
というのが正直なところです。
新人向けに書こうとすると、
いつまでも完成しない。
Claude Codeへの仕様書として書くと、
書き切れる。
書き始める動機の置き方が、
思った以上に大事でした。


クライアントへの説明の構造が変わる

配布資料とプロジェクター画面が用意された、無人の会議室

サイト診断のアウトプットをクライアントに渡すとき、
「なぜそう判断したか」を添えます。

これまで、
その根拠はディレクターの経験則という、
見えにくい権威の上に乗っていました。
「ベテランの私がそう見たから」。
これで通る場合もある。
通らないクライアントもいます。

lens.md を持っていると、
説明の構造が変わります。

「EC業種では、
トップ1スクリーン目でブランド世界観を伝えることが購買意欲に直結する。
この観点を、
私たちは標準で持っています。
御社のトップは、
その観点から見るとこうです」。
説明の頭に、
業種共通の観点が立つようになります。

判断の根拠が、
属人的なものから、
明文化された組織の知識へと移っていきます。

クライアントがこれに反応することもあります。
「では、
その観点リストを見せてください」と返ってくることがある。
観点を共有すること自体が、
提案の信頼性を底上げする
。

ここまで来ると、
ディレクターとしての価値の置き場が、
少しずつ変わってきます。
「経験のある人」への対価が、
「観点を持っていて、
それを言葉にできる人」への対価になる。
同じ金額でも、
性質は違います。


米国の代理店・コンテンツ事業者は、いまどうしているか

米国のクリエイティブな仕事場、窓辺から見える街並み

参考として、
米国の動向をいくつか書き留めておきます。

米国のあるコンテンツマーケターは、
自身のレビュー観点を memory.md というファイルに毎週書き加えています。
書き加えた観点が次回以降のレビューに反映され、
観点そのものが時間をかけて成長していく、
という運用です。
3か月、
半年と続けた結果、
最初は浅かった指摘が、
業界の標準的なレビュー観点を網羅するレベルに育ったと本人が記録しています。

別のクリエイターは、
記事の編集プロセスを3段階に分け、
それぞれでClaude Codeに異なる役割を担わせています。
1段階目は事実確認。
2段階目は構成の妥当性。
3段階目は文体の統一。
各段階で、
自分が承認しないと次に進めないゲートを設けている
点が印象的です。
全部を任せるのではなく、
自分の判断を挟む場所をあらかじめ設計しています。

組織レベルでは、
ある米国企業が社内各部門の暗黙知をテキストに書き出し、
社内で共有する仕組みを構築しています。
書くのは経営層ではなく、
現場のテクニカルリーダー本人。
書く本人にしか書けない知識を、
書く本人が書く
体制が成立しているのが特徴です。

日本では、
代理店業界の公開事例がまだほとんど見当たりません。


観点を、書き出して、外に置く

机の上に整然と並べられた観点のカード、書き出されたメモ

サイト診断を通じて、
自分の観点を書き出す。
書き出した観点は、
転用できます。
Claude Codeへの指示にも。
新人ADへの教材にも。
クライアントへの説明にも。

書き出すという1つの行為が、
業務全体に何重にも効いてくる。
これが、
4か月の試行で私がいちばん意外に思った結論です。

代理店という業態は、
これまでディレクター個人の経験と勘の上に乗ってきました。
それは強みでもあり、
脆さでもありました。
担当者が抜ければ観点も抜ける。
新人が育つには3年かかる。

観点を文字にして、
外に置く。
これは業務効率化というより、
代理店の働き方の構造そのものを書き換える動きだと思っています。

劇的な変化を期待しているわけでも、
誇張するつもりもありません。
書き出せる時期が来ている。
その手応えだけ、
書き留めておきたいと思いました。

やってみると、
思ったより書き切れます。
大丈夫です。


代理店・制作会社における観点の言語化、
サイト診断の標準化、
Claude Codeを使った業務知の整理についてのご相談は、
and,aまでお寄せください。
相談だけなら無料です。

Free Consultation

生成AIの活用やWeb解析についてお悩みがあれば、お気軽にご相談ください。初回無料です。

無料相談はこちら →