⚙️ Vault運用

2026-08-16_作業ログ

最終更新 2026年08月17日 ／ 90_Meta/Claude作業ログ/2026-08-16_作業ログ.md

作業ログ 2026-08-16

02:10-02:45 - 未来共創「師業・士業分科会」ページのテンプレ化

大串の依頼:「未来共創の師業・士業分科会ページをテンプレート化して他の分科会のページを作りたい」
方式は大串が選択 →「文言や画像（内容）の入れ替えだけでレイアウトやデザインはそのまま使えるようにしたい」
スコープも大串が選択 →「まずテンプレ化だけ（ページ作成は後）」
正本は ~/dev/client-miraikyousou の git log とリポ直下 CLAUDE.md。ここには git に乗らない判断・手法を残す。

やったこと

_preview/bunkakai/index.html（95KB・単一HTML）を レイアウト（テンプレ）／中身（データ） に分離した。

追加物 役割
_preview/_bunkakai_tpl/template.html レイアウトの正本。デザイン修正はここ1箇所で全分科会に効く
_preview/_bunkakai_tpl/data/<slug>.json 分科会ごとの文言・画像
_preview/_bunkakai_tpl/data/_registry.json 全分科会の一覧。「他の分科会を見る」を自分以外で自動生成
_preview/_bunkakai_tpl/icons.json アイコンSVG（データから名前で参照）
tools/build_bunkakai.py ビルド。--check で退化チェック
tools/bunkakai/render.py 最小テンプレエンジン（stdlibのみ・約120行）
tools/bunkakai/_extract_once.py 完成HTML→テンプレ＋データの機械抽出（1回きり）

コミット e78207e・preview ブランチへ push 済み。index.html に差分なし＝表示物は不変なので ver は据え置き。

学び（他ページのテンプレ化にも効く型）

  1. テンプレは手打ちせず、完成HTMLから機械抽出する。
    写経ミスによる「微妙にデザインが変わる」退化を物理的に防げる。抽出スクリプトは
    置換件数を毎回検証し、想定とズレたら即エラーで落とす（沈黙禁止）。
  2. 繰り返しブロックは「直前の改行・インデントまで含めた正規表現」で拾う。
    こうすると一致同士が連続するので、置換範囲＝一致の連なりだけになり、
    周囲のマークアップを1バイトも書き写さずに済む。空白の写し間違いが起きない。
  3. 完成の判定は「再生成物が現行HTMLとバイト一致すること」。
    今回 87,697字で一致（git diff も空）。ここが取れるまでテンプレ化は終わりではない。
    最初の試行では正規表現の \" エスケープ1箇所で3行ズレ、チェックが即検出した。
  4. このMacの制約: Python 3.9・jinja2 も pyyaml も tomllib も無い。
    データはJSON、テンプレエンジンは stdlib のみで自作した。
  5. 「見た目確認」はこのページのスクロール表示アニメのせいでブラウザペインでは
    中盤が白く写る。本物のページでも同じ挙動だったので、テンプレ由来ではないと切り分けた。
    （スクショで判断できない時は、セクションの実寸を JS で測る／タグ数の整合を数える方が速い）

大串の確認が要るもの

  • data/_registry.json の 師業・士業ぶんの紹介文（1件）は Claude が起草した文。
    元HTMLに無かったため（自分のページには自分のカードが出ないので）。
    他の分科会ページを作った時にそのページ上に表示されるので、その前に文面確認が必要。

次にやること（未着手）

  • WP側 ~/dev/client-miraikyousou-wp の build_asset_page() は師業・士業ぶんを決め打ち呼び出し。
    他分科会を本番に出す時にループ化＋CPT community の記事(slug)作成が要る。
    テンプレ名は single-community-<slug>.php（page-<slug>.php では当たらない・過去に実害あり）。
  • 分科会ページ本体の作成（マーケティング／AI活用／セキュリティ）は大串の指示待ち。

09:26 - /handoff 実行（全テーマ）

セッションは 2026-08-15 夕方〜08-16 朝。SCALE LIST 一本。
コンサルティング大業界に着手し、途中で環境起因の不具合と
撮影のやり方そのものの作り直しが入った。
状態の正本は ~/dev/scale-list の git log と リポ直下 CLAUDE.md。
ここには git に乗らない決定・FB・落とし穴を残す。

このセッションで扱ったテーマ（全部）

  1. 経営コンサルの取り込み — システム作業 — 8,608社 完了（全中業界2位の規模）
  2. python3 の行き先が変わって段2が全滅 — システム作業 — 根治済み
  3. 撮影のやり方を作り直し（auto_shot.sh） — システム作業 — 新設・音だけで進む
  4. ズームを引いて1枚あたりの社数を3倍に — システム作業 — OCRの読み崩れ2種を根治
  5. 中業界サブを残せるように — システム作業 — マスタ照合で読み崩れを落として保存
  6. ブラウザ自動操縦をやるか — 調査・意思決定 — やらないと決めた

テーマ別の詳細

1. 経営コンサル 8,608社（コンサルティング大業界の1本目）

項目 社数 充足率
企業HP 6,884 80.0%
従業員数 6,805 79.1%
売上規模 6,334 73.6%
代表電話 6,069 70.5%
代表者 1,827 21.2%
設立年月 1,716 19.9%
SNS 1,644 19.1%
問い合わせフォーム 1,247 14.5%
部署 298 3.5%

達成率 100.1%（取りこぼしゼロ）／退化チェック全パス。

気づき: Facebook 1,050社がXを上回った（eコマース以来2例目）。
コンサルは経営者同士のつながりが商売なので実名のFacebookが機能している。
DMならFacebook経由が有効かもしれない。

撮影中に3回流してしまい、そのたび流し直した（71枚→142枚→659枚）。
「撮り終わってから1回」の鉄則を破ると必ず手戻りになる。
大串に「撮り終わってから声をかけてほしい」と伝えた。

2. python3 の行き先が変わって段2が全滅していた

経営コンサルを流したら段2の全スクリプトが
ModuleNotFoundError: No module named 'requests' で 0秒で失敗。
前回まで /Library/Developer/CommandLineTools/usr/bin/python3（requests あり）
この日 /opt/homebrew/opt/python@3.14/bin/python3.14（requests 無し）

Homebrew の python@3.14 が入って PATH の先頭が変わったのが原因。
shot_to_data.sh が素の python3 を呼び、research_fill.py の PY は
sys.executable なので連鎖して全部そこへ行く。

気づきにくい形で壊れる。 段1（取り込み）は requests を使わないので
成功してDBに会社が入り、達成率まで出る。壊れているのは段2だけ。

→ shot_to_data.sh の先頭で requests が import できる python を選ぶ
（pick_python()）。以後 Homebrew・pyenv 等で入れ替わっても壊れない。

学び — 「失敗が0秒で返る」は環境の問題を疑う合図。
ネットワークを見に行くスクリプトが0秒で終わるなら、処理する前に落ちている。

3. 撮影のやり方を作り直し（scripts/auto_shot.sh 新設）

大串「スクショやっぱり大変だな〜」「極力ターミナル押したくない」。

大串はスクロールするだけ。撮影はMacが自動。音だけで進行が分かる。

音 意味
コッ（Tink） 1秒後に撮る。手を止める
ポン（Glass） 撮った。1画面ぶんスクロール
ブーン（Funk） このページ終わり。次のページへ

bash scripts/auto_shot.sh "土木コンサル" # 4秒ごと・1ページ3枚
bash scripts/auto_shot.sh "土木コンサル" 6 # 6秒ごと

休憩は Ctrl+C、再開は同じコマンド（続きから足される）。
止めると「今回枚数・合計・推定社数・次に叩くコマンド」が出る。

画面には何も出さない。 通知やオーバーレイは
スクショに写り込んでOCRのノイズになる（過去に写り込んだ日付を電話番号として
読んだ事故がある）。合図は音だけ、が正解。

4. ズームを引いて1枚あたりの社数を3倍に

大串がSalesNowのズームを引き、1画面16行 → 41行が読めるようになった
（8,606社なら538枚→210枚前後）。ただし新しい読み崩れが2種類出たので根治した。

症状 実測 対処
電話の頭に余分な 0 03-3668-0451 → 003-3668-0451 行頭の受話器アイコンを0と読んでいた。11桁になり桁チェックで弾かれ電話が丸ごと入らない。頭の0を1つ落とす
「億」が別の字に 1,010**種**3,800万円 / 331**個**9,628万円 字の形が近いものだけ戻す（数字は触らない）
桁崩れ 246億1,623万円 → 24601623万1 2,460億 として区分6（1,000億円以上）に化けていた（正: 区分4）。単位の前が4桁超なら金額ごと捨てる

一段引きすぎると壊滅する。 最初の試し撮り（もっと縮小）は
50行中2行しか読めなかった。1行13px・文字7〜8pxでOCRの下限を割る。
いまのズーム率が上限。これ以上引かないこと。

5. 中業界サブを読めたぶんだけ残す

大串「中業界サブも一応今回のズーム設定で取れるようになったからとってる。
これもデータで残しておいてあげるといいけど」。

そのまま入れると危険だった。 実測で
列川工事、内郎工事・床道工事（正: 河川工事…）、隣の従業員数を拾った 2,950人。

→ カンマで割って1つずつ業界マスタに当て、完全一致だけ残す。
1つも残らなければ空にする。結果 Webアプリ・サービス運営,その他コンサル,受託開発
のように正式名だけが入るようになった。

見出しの判定も直した。clean_label が括弧を落とすので「中業界（サブ）」は
中業界サブ になり、中業界 にも前方一致して曖昧判定で捨てられていた。
OCRが「中業界（サ」と途中で切ることもあるため、中業界の次の1文字（サ/メ）で
決着させる。切れた見出しをメインと誤判定するとサブの列をメインとして取り込む。

小業界は受け口を作らない（マスタを持たず照合できない＝読み崩れをそのまま
入れることになるため）。

画面には出さない。 2026-08-13 の「サブは土台にしない」判断は変えない
（全社には入らない項目なので、持っている会社と持っていない会社で結果が不揃いになる）。
将来使いたくなったときに材料がある状態にしておく、という位置づけ。

6. ブラウザ自動操縦 — やらないと決めた

大串「Chrome入ってもらって代わりにSalesnowスクショか動画とってデータ収集を
自動でやってくれたりしない？」「バレるリスクある？ ないよね？」

「ある」と答えた。 理由:

経路 中身
アクセスの規則性 自動操縦は間隔が一定。人間のスクロールは必ずばらつく
1セッションのページ数 9,300社＝93ページ連続は通常利用で出ない
自動化フラグ navigator.webdriver などの痕跡がJSで検出できる
総量 何万社ぶん閲覧したかは向こうのログに残る

SalesNowが全件CSVを disabled にしているのは大量取得を警戒している証拠。
警戒している会社はログも見る。止められると失うのは9,300社ではなく
データ供給源そのもの（SCALE LIST の業界データは SalesNow のスクショが唯一の源）。

→ 大串スクロール＋Mac自動撮影（テーマ3）に落ち着いた。
SalesNow側から見えるのは「普通に画面を見ている人」で、検出リスクがない。

auto_shot.sh を自動操縦に書き換えてはいけない。 ここは判断の結果。

このセッション全体の大串FB（重要なやつ全部）

  • 「スクショやっぱり大変だな〜」 — 手作業の負荷が限界。自動化を求めた
  • 「俺は極力ターミナル押したくない」 — 進行は音で分かるようにした
  • 「タイマーないと早めに次のページいったりいかなかったりでごっちゃになりそう」
    → カウントダウン＋予告音を入れた（撮影とスクロールがぶつからないように）
  • 「①使えない」（CSVダウンロード）— 月次上限で使えない。スクショが唯一の道
  • 「有料はなし」 — 企業説明文のAI生成（Haiku 4.5＋バッチで$21と算出）は却下
  • 「企業説明文をスクショで取るのもなしだな」 — SalesNowの説明文列を撮る案も却下
  • 「小業界・サブ業界は今後各企業に入れないものって認識」 — テンプレの土台にしない
  • 「各企業に入れている項目を含めて文章作るがいいんじゃないかな？」
    → 説明文の作れる範囲を26.7万社→250万社超に広げる根拠になった（8/13）
  • 「中業界サブも一応取れるようになったからとってる。データで残しておいて」
  • 「その推奨のやり方でよろしく〜」 — 提案した順序をそのまま任せてもらえた

技術的な学び（同じ道を二度歩かないため）

  • 「失敗が0秒で返る」は環境の問題（ネットワークを見に行くのに0秒＝処理前に落ちている）
  • 段1が成功して段2だけ壊れると気づけない（DBに入って達成率まで出る）
  • 画面に何か出すとスクショに写り込む（通知・オーバーレイ禁止。合図は音）
  • ズームは引きすぎると壊滅（50行中2行）。41行/枚が上限
  • OCRの読み崩れは「捨てる」が正解（桁崩れの売上は区分1つ違いに化ける）
  • file:/path?mode=ro はスラッシュ1つだと開けない（URI解釈。素のパスを使う）

09:45 - テーマ7 追記 — 「41行が上限」は誤りだった（真因は自動リサイズ）

大串「1ページに50社写るスクショで完璧に読み込んでくれたら最高。これなんとかしてもできない？」
→ できた。行数の問題ではなかった。

com.scale.auto-resize-screenshots（Claude に画像を送るとき用の縮小・
「画像は2000px以下」ルールのために作った別目的の常駐）が、~/Pictures/Screenshots 直下の
PNGを 3456x2234 → 1800px＝画素数27% に縮めていた。ログに 6,181件。
経営コンサルの659枚も全部これを通っており、OCR は一度も素の解像度を読んでいなかった。

上の「#4 ズームは引きすぎると壊滅・41行が上限」は誤り。 引いて小さくなった文字を
さらに27%に縮めて下限を割っていただけ。上限だと思っていた線は自分たちで引いていた。

条件 文字の高さ 結果
41行・1800px（縮小後） 16px 読めていた
50行・1800px（縮小後） 13px 崩れる
50行・3456px（素のまま） 25px 成功例の1.5倍・読める

後から拡大しても戻らない（1800px→3456px に引き伸ばして再読み取り＝法人番号 32件→32件）。
入口を直すしかない。

直したこと（commit eccd8dc・push済み）

  • import_screenshots.py … 位置の許容幅を文字の高さから決める（px_scale()）。
    1800px 決め打ちのままだと解像度を上げた瞬間に1行が2行に割れて全滅するところだった
  • auto_shot.sh … 1枚目で幅を測り2000px未満なら撮影を中止（黙って戻ると誰も気づけない）
  • auto_resize_screenshots.sh … -maxdepth 1 を外すなという警告を明記

auto_shot.sh はサブフォルダに貯めるので縮小の対象外。実測で 3456x2234 のまま保存を確認。
既存スクショ12枚で取り込み結果が1文字も変わらないことも確認（退化なし）。

もう1つ分かったこと

経営コンサルは 1枚16〜18行しか取れていなかった（659枚で8,608社）。
作業ログの「41行」はまだ一度も実運用されていない。土木コンサルが初。
50行で撮れれば 8,606社が172枚前後（経営コンサルの1/4の手間）。

次にやること

土木コンサル 8,606社の撮影から。手順は:

  1. SalesNowで中業界を「土木コンサル」に絞る（サブ・小業界の列は外す／大業界も不要）
  2. ズームは 50行のままでOK（引いて構わない。上限だった 41行の制約は消えた）
  3. cd ~/dev/scale-list && bash scripts/auto_shot.sh "土木コンサル" 4 2（50行なら1ページ2枚）
  4. 音を聞きながらスクロール。撮り終わってから取り込みコマンドを叩く

最初の数枚を撮ったところで1回だけ読み取りを検算する（50行が本当に全部読めるか）。
そこから先は撮り切ってから流す。

コンサルティング大業界は中業界19本。経営コンサル（8,608社）が1本目。