はじめに

おとといの記事で「100 件まで増やしたサンプル」を書きましたが、そこからまた 2 日まわすうちに、サンプルそのものはもちろん、開発フローの作り方や事業書類の整備のほうまで一気に広がっていきました。記録しないと忘れそうなので、5/6 〜 5/7 の 2 日でやったことをまとめます。

ざっくり言うと:

• サンプル: 100 → 190 件(四国 17 ペルソナ × LP+HP / 予約サイト 20 件 / CMS サイト 20 件)
• 自立開発ループ(Plan-Gen-Eval)を 4 体のサブエージェントで実装
• Playwright MCP を入れて実機検証を必須化、150 件の品質チェック自動化
• /samples/ 一覧の情報設計を見直し(TOC + 3-col + 業種チップ折りたたみ + もっと見る)
• Search Console の警告対応(sitemap から admin 除外 / 詳細ページに CreativeWork JSON-LD / 関連サンプル内部リンク)
• e-Tax で開業届 + 青色申告承認申請書を提出 → 法的必須箇所の本名表記整合
• ヒアリングシート / 請求書 / 顧客マニュアル を Word(.docx)出力
• /onbit:product:scaffold を追加、業種タグ JSON を 190 件に再生成

順に書いていきます。

5/6: 四国 17 ペルソナ × LP+HP = 34 件追加

100 件のうちサンプルの「業種」カバレッジを見ると、まだ穴のあるカテゴリがいくつかありました。そこで 5/6 は四国の店舗・事業者を想定した 17 ペルソナを定義して、それぞれに LP と HP の両方を作るという方針で 34 件を一気に追加しました。

ペルソナ単位で「同じ事業者が、別目的で LP と HP を持つとどう書き分けるか」という対比が見えるのが面白いところで、たとえば「焼物作家」だと:

• HP: 工房・作品・展覧会情報・取扱店舗の網羅
• LP: 春の個展に絞って、会期・場所・代表作 3 点・予約導線

のように同じ素材でも構造がはっきり変わります。これを 17 セット並べたので、お客さんと「LP と HP どっち向きですか」を話すときの叩き台が一気に揃いました。

あわせて、9 ペルソナには AI 生成写真(Pollinations / flux モデル)を組み込み、さらに残り 6 ペルソナにも追加。途中、画像アセットを A〜P の 4 バッチに分けて差し込む作業も同時並行でこなしました。

仕上げに、一覧に「新しい順 / 古い順」のソート切替を追加。134 件ぶんを 1 ページに並べる前提だと、新しい人が来るたびに「最近追加した分から順に見たい」のニーズが出るので、これは必須でした。

5/7 朝: 予約サイト 20 + CMS サイト 20 で計 190 件

5/7 の朝は、これまでの「静的 LP / HP」とはまた別の、機能つきサイトのモックを作りました。

• 予約サイト 20 件: サロン・教室・治療院・宿泊施設など、ネット予約を主導線にする業種を想定。日付選択 → 時間スロット選択 → 内容確認モーダル → 完了画面、という申込フルフローをそれぞれに実装
• CMS サイト 20 件: 学校・自治体・工務店・士業・出版社など、お知らせや記事を継続更新していく業種を想定。記事一覧・詳細・カテゴリ絞り込みのモック表示

予約サイト 20 件には「カレンダー操作 → 確認モーダル → 完了画面」のインタラクションを全部入れたので、「これと同じ仕組みで作れます」を実物で見せられるようになりました。

このタイミングで一覧ページに 種別フィルタ(LP / HP / 予約 / CMS) も追加。190 件あっても「予約だけ見たい」と絞れば 20 件まで一気に減らせます。

そのあと、過剰に作り込まれていたヒーローセクションを CMS 20 件と予約 20 件で削除してシンプル化。「機能を見せる」ことが目的のサンプルなので、ヒーローの装飾は不要、という判断です。

自立開発ループ(Plan-Gen-Eval)を導入

サンプルが 190 件まで増えてくると、「全部に同じ品質のチェックを通す」が手作業では成り立たなくなります。そこで、これまでの 5 体のエージェント(Founder / SalesLeader / ProductLeader / DeliveryLeader / BusinessLeader)に加えて、実行プロセスレイヤーの 4 体を追加しました。

エージェント	役割
Orchestrator	タスク種別判定・ループ管理
Planner	タスクを 5〜7 のサブタスクに分解
Generator	サブタスクを実行(コード/文章/データ生成)
Evaluator	成果物を評価(pass / revise / reject)

複雑案件は Orchestrator → Planner → (Generator → Evaluator → loop) × N の構造で回し、軽微な修正なら Planner をスキップして Gen-Eval ループだけで完結させる、という設計です。revise 3 回で Planner に差し戻し、というルールも入れました。

これで「作る」と「評価する」を別エージェントに分離できるので、Generator が暴走したりすり抜けたりしても、Evaluator の段で必ず引っかかる構造になります。

Playwright MCP で実機検証を必須化

Evaluator の判定に「実際にブラウザで動かしてみての結果」を含めたかったので、Playwright MCP を導入しました。Claude Code から MCP 経由で実機 Chromium を立ち上げて、操作・スクショ・コンソール監視・ネットワーク監視ができます。

WSL 環境では Chrome バイナリ(/opt/google/chrome/chrome)が無いので、.mcp.json で --browser chromium を指定する必要があった、というハマりはありました。

これと並行して、サンプル個別の自動検証スクリプト scripts/verify-samples.mjs も作成。

• コンソールエラーゼロか
• クリック可能要素が反応するか
• 文体ルール違反(寄り添 / 伴走 / 丁寧 / ご提案 / お気軽)が含まれていないか
• <img> の参照先がローカルに存在するか

を 1 件あたり 3〜5 秒で機械的にチェックします。150 件の HP/LP に通したところ、引っかかったのは 13 件のみ:

• NG ワード残存 12 件
• テンプレートリテラル展開バグ 1 件(${s.img}.png が文字列のまま HTML に残っていた)

これらをサブエージェント 4 体並列(yuki ×3 で文言修正、hiro ×1 でテンプレ修正)で直し、再検証で全件 score=1.0 pass まで持っていきました。

/samples/ 一覧の情報設計を見直し

190 件並べる前提で、一覧ページの構造そのものも作り直しました。

旧構造の問題は:

• ピックアップ 16 件が多すぎ(全体の 8%)、所属種別セクションにも同じカードが出ていて重複表示
• 業種チップ 18 個がスマホで 2〜3 行になって絞り込み前のスキャンコストが高い
• LP/HP の用語が技術寄り
• 種別ジャンプの TOC がない
• 1 ページに 190 カードが全部出るので初期スクロール量が膨大

新構造でやったこと:

• featured を最大 6 件に絞り、所属セクションから除外(重複防止)
• ヒーロー直下に TOC(ピックアップ / 予約 / CMS / 1ページ完結 / 複数セクション)
• デスクトップを 2-col → 3-col に
• 業種チップは件数上位 8 件をデフォルト、残りは「+ N 業種を表示」で展開
• 各セクション初期 12 件まで表示、超過分は「もっと見る」で展開
• 見出しを「LP / 1 ページで完結」→「1 ページ完結 LP」など、顧客視点の語順に

これで初期表示は 6 + 12 × 4 = 54 カードに圧縮されました。190 件あっても、最初に見える量はずっと少ない。

Search Console の警告対応 + 詳細ページの SEO 強化

ちょうど Search Console から「ページがインデックスに登録されない新しい要因」の通知が届いていたので、原因を一通りつぶしました。

主因は sitemap に /admin/* 4 ページが入っているのに、それぞれが noindex 指定 という矛盾。Google が「除外せよと言っているのに sitemap に入れている」と警告してきていたので、astro.config.mjs の sitemap filter で /admin を除外。

あわせて、サンプル詳細ページ 190 件の SEO を強化。

• meta description を category / tone / features 込みで 290 文字に
• OG image をサイト共通から サンプル固有の screenshot.jpg に切替
• CreativeWork JSON-LD を追加(検索エンジンに「これは作品事例」と明示)
• 「サンプルの仕様」スペックリスト(種別 / 業種 / トーン / アクセント色 / 公開日)
• 「関連するサンプル」内部リンク 4 件(同業種優先)

「クロール済み - インデックス未登録 56 件」については、Google が「価値が低い」と判断しているサインだったので、ユニーク文字量と内部リンク数を増やすのが王道の対処でした。

開業届提出

5/7 当日、e-Tax で 開業届 + 青色申告承認申請書を同時提出。マイナンバーカードがあれば 30 分で終わります。65 万円控除の起点となる手続きが完了しました。

ヒアリングシート / 請求書 / 顧客マニュアルを Word 化

事業書類の整備として、これまで Markdown だけで持っていたテンプレを Word(.docx)でも出力するようにしました。

• ヒアリングシート: 初回打ち合わせで紙に印刷して使う想定。基本 5 項目(業種 / 目的 / 締切 / 予算 / 原稿写真)+ 任意質問 + ヒアリング後メモ
• 請求書テンプレート: 顧客に送付する正式版。請求金額・内訳・振込先・請求元・備考特約をテーブル整形
• 顧客運用マニュアル: 納品時に Word で顧客にお渡しする。6 章 + 巻末用語表で、{{client_name}} 等の差し込み変数を残したテンプレ形式

実装は npm の docx パッケージで scripts/build-word-templates.mjs を書いて、Markdown 側を編集して node scripts/build-word-templates.mjs を実行すれば再生成される、という流れにしました。

/onbit:product:scaffold 追加 + 業種タグ JSON を 190 件に再生成

/onbit:product:scaffold <sample-slug> <client-name> というコマンドを新設。サンプル HP / LP を本番案件のひな形にコピーして、店名・住所・電話などの架空データを {{client_name}} 等の差し込み変数に置換した状態で clients/<client-name>/ に出力する仕組みです。

スクリプト本体(scripts/scaffold-from-sample.mjs)は元々あったのですが、ProductLeader からスムーズに呼び出せるように skill 定義を作成しました。これで「ヒアリング → scaffold → TODO 提示」の流れを AI 主導で回せるようになります。

あわせて、業種タグ JSON(apps/website/src/data/sample-tags.json)を 30 件 → 190 件に再生成。/onbit:sales:proposal がこれを直接参照して、案件業種に近いサンプル 3 件を顧客送付できる形で抽出するように切り替えました。

残作業: 会計ソフト契約だけ

事業立ち上げのチェックリスト(社内では AQ-001 と呼んでいる、20 項目のロードマップ)のうち:

• 🔴 基盤層(開業届 / 銀行口座 / 電話 / Gmail / サンプル CTA / 受入ルール / 法的整合)= 7 項目
• 🟡 SOP 整備層(ヒアリングシート / 返信テンプレ / proposal / build / review / workflow / 請求書)= 7 項目
• 🟢 月内磨き込み(オプション工数表 / scaffold / 業種タグ / 顧客マニュアル)= 4 項目

合計 18 項目が完了。残るは「会計ソフト契約」(マネフォ or freee の比較資料は完成済、あとは契約だけ)の 1 項目です。

これで「外部からの問い合わせを受けて受注 → 制作 → 納品 → 請求」を回せる土台がほぼ揃いました。

おわりに

5/5 の記事で「サンプル 100 件できた」と書いたばかりなのに、そこから 2 日でサンプルが倍近くになり、自立開発ループまで導入され、開業届を出して、法的整合まで取り終わっていました。

体感としては「Claude Code に任せる前提でタスクを設計すると、こなせる量が階層的に変わる」という気づきがあった 2 日でした。並列で 4 体動かすこと自体は前からやっていましたが、今回は Generator と Evaluator を分けて、合格するまで反復させる というループ構造で、品質ハードルを下げずに量をスケールできた手応えがあります。

明日からは、いよいよ最初の外部問い合わせを受け止める段階。intake-rules.md に書いた「並行 1 件・SLA 48h・6/15-7/15 新規停止」の運用が、現実の問い合わせに対してどう機能するかを見ていきたいと思っています。