【後編】Claude Code で1万ページ超えのメディアを27日で作成した実践解説。落とし穴と解決策を紹介

ローカルグローススタジオは、『地方企業にスタートアップのような成長を』というテーマで、コンテンツ発信と支援サービスを展開しています。この記事では、実践的なビジネスノウハウを、できるだけわかりやすくお伝えしていきます。

この記事は、『Claude Code でメディアサイトやデータプロジェクトを立ち上げるときに、私たちが 20 サイクル以上の試行錯誤の中で見つけた落とし穴と解決策』について記載しています。前編『Claude Code とは?聞いて答える AI から、実行してくれる AI への進化。15 の使い方実例』を未読の方は、先にそちらをお読みいただくと前提が共有できます。

本記事は、私たちつなぐスタジオが「グローススタジオレポート」を実際に構築した経験にもとづく記録です。技術解説書というより、同じ規模感のメディアやデータプロジェクトを Claude Code で立ち上げようとされる方が、似た落とし穴を踏まなくて済むよう、一次情報として共有することを意図しています。

開発寄りの言葉も一部出てきますが、すべてを覚える必要はありません。「こういう落とし穴がある」「こういう打ち手で乗り越えた」という流れだけ拾い読みしていただければ十分です。実際にプロジェクトを動かす段階で同じ落とし穴に当たった時に、再度開いていただいても遅くありません。

まず、何をどう作ったか(導入期)

最初に、何を作ったのかをお伝えします。グローススタジオレポートは、全国 171 エリア × 29 職種 の求人相場を、エリア・職種・年収帯ごとに見られるようにしたデータメディアです。

仕組みはシンプルです。求人ボックスの公開求人を継続的にクロール(自動収集)し、約 4,959 通りある「エリア × 職種」のそれぞれについて、求人数・年収の中央値・必要スキル・働き方(出社中心 / ハイブリッド / フルリモート)を整理します。そのデータをテンプレート(ページの型)に流し込み、合計 10,453 ページのサイトとして公開しています。

このメディアで解決したいのは、「相場感を持たないまま、仕事を選んだり、求人を出したりしている」状態です。

働く人の多くは、自分のこれまでの経験や、住んでいる地域の求人しか見えていません。けれど少し範囲を広げれば、近隣の都市へ通うハイブリッド勤務や、場所を選ばないフルリモートの仕事もあります。そうした仕事の広がりや可能性を知る機会がないまま、限られた情報だけで仕事を選んでしまう人は少なくありません。採用する企業の側も同じで、自分のエリアや近隣都市の相場を知らないまま求人を出した結果、提示する条件が市場とずれていて、なかなか採用できないというケースがあります。

求職者・採用担当・経営者という、立場の異なる3者が、同じ相場をそれぞれの視点から簡単に読み解き、次の一手のヒントを見つけられる。そういうサイトを目指して作りました。

そのうえで、相場を扱うメディアである以上、どの数字がどの集計から出ているのかを隠さず開示することを、品質の土台に置いています。出どころの分からない数字では、相場を判断する材料になりません。価値の中身は「相場感を届けること」、それを支える品質基準が「データの信憑性」、という二段構えで考えています。

この規模を人の手で作るのは、現実的ではありませんでした。約 5,000 通りの組み合わせを1つずつ収集し、年収の中央値を出し、ページに起こしていく。これを手作業で進めるのは、1人ではまず不可能です。データの自動収集だけで30万回を超えるアクセスが必要で、2日以上かかります。本来なら、エンジニアを雇って外部に開発を発注するような規模の仕事です。

それを私1人と Claude Code で回せたことが、今回のいちばん大きな点でした。データを集めるプログラムを書き、集めた求人を整理し、ページの型から1万ページを一気に生成し、毎月まるごと取り直す。この一連の工程を、私が日本語で方針を伝えるだけで、Claude Code が進めていきます。

立ち上げは、思っていたより速く進みました。進め方はシンプルで、まず1ページを作り込み、その型を全組み合わせに展開します。1つのエリア × 職種のページを納得いくまで仕上げ、その型をエリア・職種のマスタデータに当てはめて、全件を一気に生成します。この手順だったため、着手から数日で全体の8割ほどの形になりました(初コミットが5月9日、4,000 ページ超の展開が5月12日です)。

大変だったのは、ここから先です。残りの2割、つまり「読み心地」「数字の整合」「スマホでの見え方」「本番サイトへの反映」を詰めていく工程で、何度も落とし穴にはまりました。最終ローンチの6月5日まで、着手からは 27日間(1か月かかっていません)。その大半は、この最後の2割を上げきるための試行錯誤に費やしました。

この試行錯誤を、私は「サイクル」という単位で回しました。観点ごとに役割を分けた複数のレビュー役(校閲・デザイン・事実確認・情報設計など)を同時に動かし、出てきた指摘を集約して、まとめて修正に反映する。この一巡を1セットと数えたものが「サイクル」で、これを 20 回以上繰り返しました。仕組みの詳しい中身は、ポイント4でご説明します。

ここから紹介する6つは、その過程で踏んだ落とし穴と、抜け出すために見つけた打ち手です。

目次から興味のあるポイントだけ拾い読みいただいても、内容が成立する作りにしています。

ポイント1:一時メモが矛盾と重複を生む

最初の落とし穴は、Claude Code の特徴の一つから生まれます。Claude Code は、指示を出すたびに、作業の経緯を Markdown ファイル(文章をまとめるのに広く使われる形式のファイル)として残します。「今日の進捗」「設計の判断メモ」「次回への引き継ぎ」といった具合です。これが半月もすると、現役のドキュメントフォルダの中に、数十本の日付付きメモとして溜まっていきます。

ここで起きるのが、矛盾と重複です。古いメモの内容と現在の仕様が食い違い、次の作業で Claude Code が古いメモを参照してしまう。その結果、すでに直したはずの設計を蒸し返す、という事故が起こります。

そこで取った解決策は、「置き場所を物理的に分ける」というシンプルなルールでした。難しい仕組みは使っていません。「今この瞬間に正しい最新版」と「過去の作業メモ」を、別々の場所にしまうと決めただけです。

• 今の最新版(現在有効な仕様や設計)は、専用のフォルダにまとめ、そこには日付のないファイルだけを置く
• 過去の作業メモは、作った時点から「メモ専用の置き場」に移し、最新版のフォルダには混ぜない
• いつ何を決めたかの記録は1つのファイルにまとめ、似たような履歴ファイルをあちこちに作らない
• 点検レポートも専用の置き場にまとめ、最新版のフォルダを汚さない

イメージとしては、「最新版だけが並んだ、きれいな棚」を1つ用意し、それ以外は全部、別の棚へ追いやる感覚です。この置き場所の分離をルールにしてから、古いメモを参照して、すでに直した設計を蒸し返す事故は起きにくくなりました。最初に「過去メモは過去メモ置き場へ」と決めておくことが、メディアづくりのような長期のプロジェクトでは効いてきます。

ポイント2:指示書(CLAUDE.md)は「全体 → プロジェクト → 個別フォルダ」と階層に分けた

Claude Code には、プロジェクト共通の指示を CLAUDE.md という1枚のファイルに書いておくと、作業のたびに自動で読み込んでくれる仕組みがあります。いわば「毎回いちばん最初に読む、共通の指示書」です。最初はここに全部を書いていましたが、量が増えるにつれて、すぐに「読みにくい」「どこに何を書けばいいか分からない」状態になりました。

そこで取り入れたのが、指示書に『階層』を作るという考え方です。会社の就業規則をイメージすると分かりやすいかもしれません。全社共通の規則があり、その下に部署ごとのルールがあり、さらにチーム固有の決まりがある。上の階層ほど「どこでも効く大原則」を、下の階層ほど「その場所だけの細かい決まり」を書く、という入れ子の構造です。AI への指示書も同じように、「どこでも効く共通ルール」と「この場所だけのルール」を、階層に分けて持たせます。具体的には、フォルダごとに、その場所用の指示書を1枚ずつ置いていきます。

最終的に、以下の6階層に落ち着きました。

• 第1層:自分のすべての仕事に共通(パソコン全体に効く):作業の進め方、報告の仕方、どの仕事でも変わらない基本の作法
• 第2層:会社全体:会社のビジョン、文化、3つの事業の定義、社内でよく使う基本情報
• 第3層:このメディアのプロジェクト全体:メディアとして外せない3つの原則、公開予定日、編集長としての責任範囲
• 第4層:ドキュメントの置き場ルール:ポイント1で決めた、現役と過去メモの分け方
• 第5層:データを処理するプログラムの置き場ルール:データ収集の手順、時間のかかる処理で気をつけること
• 第6層:データ本体やテンプレートの置き場:データの形式や、その場所だけで使う細かい編集ルール

下の階層は、上の階層のルールを引き継いだうえで、その場所固有の決まりを足していきます。「会社全体の話は第2層」「このメディア固有の話は第3層」「特定のフォルダだけの話は第4層以降」と書く場所を決めておくと、直したいルールがどこにあるかを、人も AI も迷わなくなります。

ここで一つ実感したのは、Claude Code は、今どの場所(フォルダ)で作業しているかに応じて、その場所に効く指示書を上から順に読み込むということです。プロジェクト全体のフォルダで作業しているときは第3層まで、その下の細かいフォルダに入って作業しているときは、第4層以降も追加で読み込みます。だからこそ、下の階層の指示書には「上位のルールも参照する」という一言を必ず残しておきます。どの場所から作業を始めても、大もとのルールにたどり着けるようにしておくことが大切です。

ポイント3:一番怖い落とし穴は「書いてあるのに、実際には動いていない」というズレ

20 サイクルの中で一番ヒヤッとしたのが、ドキュメント(計画書や説明ページ)には「この機能はもう作った」と書いてあるのに、実際のプログラムには、その処理がまったく存在しなかった、というケースです。

例えば、このメディアでは初期に「国の賃金統計と組み合わせた相場感を出す」と、仕様書や説明ページの合わせて8箇所で宣言していました。ところが、ある日の点検で、全ファイルをまとめて検索して確かめてみると、実際の処理は100%が求人ボックスのデータだけで、国の統計を組み合わせる処理は、どこにも存在していませんでした。

なぜ、こんなことが起こるのでしょうか。Claude Code との作業は、一度きりではなく、何日にもわたって、何回ものセッション(作業のまとまり)に分かれて進みます。あるセッションでは「こういう機能を作ろう」と計画書に書き、別の日のセッションでは実際のプログラムを書く。本来この2つは連動しているべきですが、作業のタイミングが分かれているために、片方だけを直して、もう片方を直し忘れる、ということが起こります。

たとえば、ある日に「この統計データも組み込もう」と計画書に書いたものの、その後の実装が後回しになり、計画書だけが「組み込み済み」のように残ってしまう。人間でいえば、会議の議事録には「来週やる」と書いたのに、実際のやることリストには反映されていない、という状態に近いです。書いた本人ですら気づきにくいまま、計画書と実態が静かにずれていきます。このズレは見た目では分からず静かに進むため、一番警戒しました。

対策として、以下の自己点検をルールにしました。

• 新しく「作った」「対応した」「組み込んだ」と書いた直後に、必ず全ファイルを検索して、その処理が本当に存在するかを確認する
• もし処理がまだ無ければ、計画書側を「未実装、これから作る予定」と正直に書き換えるか、その場ですぐ作りに取りかかる
• 公開の直前にも、決めた5つの観点について、全ファイルをまとめて検索する機械的なチェックを通す

相場を扱うメディアにとって、数字の正確さは生命線です。書いてある内容と実際の動きがずれていると、それだけで読者の信頼が崩れてしまいます。「書いてあるのに、実際には無い」というズレを残さない。この1点に、最も神経を使いました。

ポイント4:レビュー役は6人から11人に増えていった

Claude Code には、エージェント(指示を与えると自分で作業を進める、AI の作業役)を、複数同時に動かす機能があります。メディアの品質を一定以上に保つために、観点ごとに専門のレビュー役を割り当て、同時に走らせる「並列レビュー」を取り入れました。

スタート時点では6観点でした。

• 校閲(誤字脱字、一文の長さ、主語と述語のねじれ、トーン)
• 編集方針・読み手の体験(ビジョンが一貫しているか、話の順序に無理がないか)
• デザイン(色づかい、文字の見やすさ、スマホ対応)
• 事実確認(外部の事実、自社の主張、リンク切れがないか)
• 情報設計(メニュー、現在地の表示、画面の流れ)
• 業界知識(職種の分類、専門用語の使い方が妥当か)

ところが16サイクル目で、「6人のレビュー役が全員 OK を出した直後に、私が3件の問題を指摘して差し戻す」ということが起きました。指摘の中身は、共有ボタンの色がそろっていない、重要な数字が枠からはみ出している、スマホで文字が小さすぎる、といった、実物を見れば一目で分かるものばかりでした。

ここで分かったのが、AI が自分で「できています」と申告するだけでは拾えない品質があるということです。文字や数字の正しさは検索で確認できても、「見た目の窮屈さ」や「実際のスマホでの読みやすさ」は、表示された画面を見ないと分かりません。そこで、レビュー役を段階的に増やしていきました。

• 18サイクル目:全体を最後にまとめる「統括役」と、「宣言と実装のズレ専門」のレビュー役を新設
• 統括役は、私が最終確認するより前に必ず通す、最後の関所。本番に近い表示環境で実物を測り、過去に私が指摘したパターンと照らし合わせる
• もう1つは、「やる」と宣言した内容と、実際に処理されているデータがそろっているかを確認する役(ポイント3のズレを見つける担当)
• 19サイクル目:「スマホでの使いやすさ」「サイトの技術的な健全性」「文章の構造」「過去の指摘の再発チェック」の4つの役を新設
• スマホ担当は、実際のスマホに近い画面で表示を測る
• 技術担当は、サイトが正しく組み上がっているか、検索エンジン向けの情報(サイトマップや構造化データなど、検索結果に正しく表示されるための情報)が整っているかを確認する
• 文章担当は、段落の長さ、一文の長さ、読点の数、章の長さを機械的に測る
• 再発チェック担当は、過去に私が出した指摘を一覧にしておき、同じ問題がぶり返していないかを自動で見つける

結果として、レビュー役は6人から11人に増え、さらにその上に全体をまとめる「統括役」が乗る構造になりました。大事なのは、レビュー役を増やすこと自体が目的ではない、という点です。狙いはあくまで、「最後に私が指摘するレベルの問題を、私のところに届く前に、AI の側で見つけきる」ことにあります。新しい指摘が出るたびに一覧へ追加し、その観点を既存のレビュー役に足すか、統括役に組み込むかを決めていく。これが今の運用です。

ポイント5:「自分のパソコンで完成 = 公開サイトに反映済み」ではない(公開後の実物確認を最終チェックに組み込んだ)

これは19サイクル目の最後に発覚し、20サイクル目で仕組みそのものを作り直した、もう一つの大きな落とし穴です。

11人の並列レビューが全員 OK を出し、自分のパソコンの中では修正が完璧に反映されている。完了を自動で確認するチェックも、すべて問題なしと出ていました。ここで私は「完了」と判断し、最終確認に進もうとしました。

ところが、たまたまその直後に、実際に公開されている本番サイト(report.lgstudio.jp)を開いてみると、修正がまったく反映されていません。おかしいと思って、サイトを公開する仕組み(Cloudflare というサービスを使っています)の管理画面を見たら、直近11回の更新が、メモリ不足によって公開処理に失敗し続けていて、公開サイトは8時間前のままでした。

つまり、Claude Code の中で「完了」とされた状態と、本番サイトに実際に表示されている内容が、8時間ぶんずれていたのです。Claude Code のレビューは、自分のパソコンの中で組み上がった完成データだけを見ていて、実際に公開されているサイトそのものは、誰も見ていませんでした。

そこで20サイクル目で、「完了」の定義そのものを、次の9段階に厳しくし直しました。

1. 自分のパソコンの中で、サイトが正しく組み上がる
2. 組み上がった主要ページに、期待した修正内容がきちんと入っている
3. データの整合性チェックで、重大な不整合がゼロ
4. 公開前の5つの観点チェックが、すべて合格
5. 「データ集計中」「未定」「(仮)」やリンク切れなど、未完成の痕跡が1つも残っていない
6. 修正内容を、公開用のサーバーに送信する
7. 公開処理が成功している(管理画面で、最新の更新が成功と表示されている)
8. 公開後のサイトを自動で確認し、修正内容が本当に反映されている(反映されるまで最大10分待って確かめる)
9. AI のレビューも、自分のパソコンの中ではなく、実際に公開されているサイトを見て行う(パソコンの中だけでは、公開への反映までは保証できない)

特に効いたのが、公開後のサイトを自動で確認する仕組みを新しく作ったことです。やることはシンプルです。自分のパソコンで直したはずの十数か所の「修正の目印」を一覧にしておき、実際に公開されているサイトの中身を自動で取ってきて、その目印が本当に出てくるかを1つずつ照合します。最大10分待っても反映されていなければ、「公開に失敗している」と判定して、その場で止まります。

この最終チェックを足したことで、「自分では直したつもりだったのに、公開処理が落ちていて反映されていなかった」という事故は、私のところに届く前に止まるようになりました。

これは特定のサービスに限った話ではありません。「更新を送ると、自動で公開作業が走る」タイプのサービス全般に当てはまります。「更新を送った = 公開サイトに反映された」ではない。これを必ず前提に置く必要があります。メモリの上限、料金プランの制限、時間切れなど、原因が何であれ、公開処理が途中で失敗すれば、公開サイトは古いまま残ってしまいます。

20サイクル目のこの作り直しは、結果として「レビューの観点を増やすこと」と同じくらいの重さで効きました。AI のレビュー役をいくら増やしても、見ている対象が自分のパソコンの中だけなら、本番サイトの問題はいつまでも見つかりません。「AI に何を見せるか」自体が、レビュー設計の肝になると痛感した出来事でした。

ポイント6:20サイクル回して、直せたこと・直りにくかったこと

20 サイクル以上を回して、明確に直せた領域と、最後まで直りにくかった領域があります。

直せたこと

• 設計の判断基準を「3つの原則(誰にどんな便益を届けるか/数字をどう集計するか/打ち手の本質は何か)」に統一し、どの判断もこの3つに紐づける形にそろえたこと
• 「書いてある」のに「実際には無い」というズレを、全ファイルをまとめて検索する自己点検で、原則ゼロにできたこと
• 現役の最新版と過去メモの置き場所を物理的に分けたことで、古いメモを参照して、すでに直した設計をぶり返す事故が起きなくなったこと
• 重要な数字の枠はみ出しや、スマホでの文字の見えづらさなど、過去に私が指摘した類の問題を、新しいレビュー役(スマホ担当・再発チェック担当)が、次のサイクル以降は事前に捕まえられるようになったこと
• 「自分のパソコンで完成 = 公開完了」と勘違いするタイプの公開事故を、公開後のサイトまで必ず確認する仕組みでゼロにできたこと

直りにくかったこと

• AI 自身の自己申告の精度。同じ問題でも、サイクルが変わると別の言葉で表現してしまうため、「前回と同じ問題が残っているのか、新しい問題なのか」を機械的に判定しきるのは、最後まで難しいまま残りました
• スマホでの、細かな見た目の詰め。実際のスマホに近い画面を AI に測らせる役を入れて補強しましたが、それでも最後は人間の目で見て判断する余地が残りました
• 「圧迫感」「読み心地」のような感性的な品質。AI で点数化はできますが、最終判定は人間が行う、という運用に落ち着きました
• 長時間の作業が途中で止まってしまう問題。あるレビューを夜中に動かしたら、ノートパソコンが省電力で眠ってしまい、8時間ぶん無駄にした事故がありました。処理を裏で動かし続ける設定と、定期的に様子を見にいく仕組みを組み合わせて、再発を防ぎました

つまり、AI で完結できることと、最終的に人間が判断すべきことは、明確に線が引けます。AI 側に寄せられる部分はどんどん寄せて、人間は最後の判断と感性に集中する、という分業が、メディアサイト運営での最適解でした。

まとめ:1万ページ超のメディアを Claude Code で立ち上げて分かった、6つの解決策

後編の要点を整理します。1 万ページ超のメディアサイトを、着手から27日間(1か月かからず)で立ち上げる過程で確立した、6つの解決策です。

• 一時メモは、矛盾と重複の温床になる。最初に「現役の最新版」と「過去の履歴」の置き場所を物理的に分けるルールを作る
• 指示書(CLAUDE.md)は階層に分ける。会社全体・プロジェクト・個別フォルダで役割を分ける(私たちは最終的に6階層に)
• 「書いてあるのに、実際には無い」というズレが最も怖い。全ファイルをまとめて検索して、その処理が本当に存在するか確認する自己点検を習慣にする
• レビュー役は、観点ごとに分けて同時に動かす。当初6人から、最終的に11人 +「全体をまとめる統括役」へ
• 「自分のパソコンで成功 = 公開サイトに反映、ではない」。公開後のサイトそのものを確認するチェックを、最終チェックに必ず入れる
• AI で寄せられる部分は寄せ、最終判定と感性的品質は人間が握る。この分業がメディア運営の最適解

私たち自身、グローススタジオレポート(10,453 ページ)を公開するまでの27日間で、ここに書いた落とし穴のほぼ全てを実体験しました。最初は誰でも、メモの矛盾や重複、「書いてあるのに無い」ズレ、公開処理の失敗に振り回されます。ただ、ルールを1つずつ積み上げていけば、「実行してくれる AI」として、手元で安定して動かせるようになります。

最初から完璧な運用ルールを用意する必要はありません。まずは指示書(CLAUDE.md)を1枚置き、「現役の最新版」と「過去の履歴」を分けるところから始めれば十分です。これから Claude Code でメディア事業を立ち上げる方にとって、本記事の6つの解決策が、最初の試行錯誤を少しでも短くする材料になれば幸いです。

---

ダッシュボード構築代行 / Claude Code 設定支援のご案内

つなぐスタジオでは、地方企業の経営者の方や、メディア事業・データプロジェクトを立ち上げたい方向けに、以下の2つのサービスを提供しています。

• ダッシュボード構築代行:GA4 / GSC / 広告 / CRM データを統合し、毎週自動更新のダッシュボードを構築。経営判断の起点となる数字を、毎週決まった曜日の朝に揃った状態で見られる体制を整えます。
• Claude Code 設定支援:指示書(CLAUDE.md)の階層設計、フォルダ構成の初期設計、最初の業務用プログラムの設計、並列レビュー(全体をまとめる統括役 + 観点別のレビュー役)の導入支援、公開後の反映確認の仕組みづくりまで、Claude Code を業務に組み込む初期セットアップを伴走します。

「メディアサイトを立ち上げたい」「自社の事業領域で、データの収集や分析を始めたいが、どこから手を付ければいいか分からない」「エンジニアを雇わずに、データを活かした事業や仕組みを社内に立ち上げたい」という段階からのご相談を歓迎します。

『ビジネス知の機会格差をなくす』という私たちのミッションに向けて、これからも実践的で価値ある情報を発信していきます。この記事の内容について、さらに詳しく知りたい方は、ぜひご連絡ください。

まずは無料相談する

---

著者プロフィール