Claude Codeで詐欺ダメ.comの拡張機能を作ってみたら・・・やはり爆速だった

はじめに

詐欺ダメ.comを稼働させて1ヶ月半。

この間に1万件弱の偽通販ドメイン情報を公的機関に提供したが、今も音沙汰無し・・・
この詐欺ダメ.coomは「被害ありきではなく、被害を出さないという事がしたい」 という思いの元で開発しているので、3万件のブラックリストを活用出来る拡張機能を追加で開発した。

結果、実働約11時間・中2日でChrome Web Store公開まで到達。
本記事はその実録である。

公開した拡張機能: 詐欺ダメ.com 拡張版 (Chrome Web Store)

要件は最初から決まっていた

要件定義にはあまり時間をかけていない。作る前から以下が固まっていたためである。

• バッジは右上に出す — 右下はマルウェアの偽通知に見えて逆効果になる
• 大きすぎない、邪魔にならないサイズ — ユーザーの購買行動を止めない
• そもそもECサイト以外では表示しない — ニュース記事やSNSでバッジを出すのは無意味であり、EC以外のURL照会は極力省きたい（サーバ負荷の観点でも）
• 拡張から叩かれるサーバーAPIのボトルネックを極力減らす — 大量ユーザーが同時アクセスしても本体サービスを詰まらせない設計

この4点が確定していたため、Claude Codeへの指示は「この要件を満たす形で実装を検討」の一言で済んだ。

拡張機能で何ができるのか

訪問中のECサイトのURLを詐欺ダメ.comのDBと自動照合し、右上に4段階の判定バッジを表示する。

レベル	表示	意味
🔴 danger	危険	ブラックリスト該当（3万件弱）
🟡 warning	注意	踏み台記録あり（改ざん被害の疑い）
🟢 safe	正規サイト	ホワイトリスト登録済
⚪ unknown	記録なし	DB未登録

記録がないサイトについては、免責同意のうえ「このドメインをチェックする」ボタンから詳細解析を実行できる。

前提：既存資産の上に乗せた差分である

工数の話に入る前に、ひとつ大事な前提を書いておく。

「11時間で公開」には裏の前提がある。すでに以下の資産が 数ヶ月分 積み上がっていた。

• BL/踏み台DB 3万件弱 — 数ヶ月の運用資産
• SSRFガード — 既存
• レート制限フレームワーク — 既存
• 本番docker/nginx/systemd運用基盤 — 数ヶ月の熟成
• 詐欺判定シグナル 50+ 実装 — 数ヶ月の熟成

ゼロから同等のものを作る場合、中堅エンジニアで3〜6ヶ月規模である。今回の11時間はその資産の上に乗った「差分」に過ぎない。

「Claude Codeで速い」を正確に言い直すなら 「既存資産への差分を出すのが爆速」 である。ゼロイチも速いが、既存基盤があると加速度がさらに一段上がる。

実工数

git commitのタイムスタンプから、AI作業時間と人間作業時間を分けて集計した。
なお「AI作業時間」は、Claude Code との対話および出力待ち・修正依頼を含めた開発セッション時間として計測している。

工程	AI作業時間	人間作業時間	合計	人間のみ作業想定	短縮率
📋 要件定義	0h	0.3h	0.3h	1.0h	70%
🎨 設計	0.5h	0.5h	1.0h	3.0h	67%
💻 実装	4.0h	2.0h	6.0h	40.0h	85%
🧪 テスト・CWS提出	1.0h	2.5h	3.5h	15.0h	77%
合計	5.5h	5.3h	10.8h	59.0h	82%

※「人間のみ作業想定」および「短縮率」は、あくまで筆者個人の見積りである。実装者の経験・既存基盤の有無・利用ライブラリで大きく変動する。MV3 経験者や既存 EC 拡張の改修であればもっと短くなり、CWS 提出未経験ならさらに長引く可能性がある。

暦日換算では中2日（07-16 昼着手 → 07-19 公開）。約 82%の短縮、実工数比では約5倍の速度差となった。

なぜここまで差が出るのか

• MV3の学習コストがほぼゼロ — ClaudeがMV3の定石をすぐ提示できる
• 沼りやすいバグの一発解決 — HTTPキャッシュでunknown化する問題、Shadow DOMのCSS干渉、SPAでのイベント発火タイミング等、半日ぐらい溶けそうなバグを即座に切り分け
• CWS提出資料の生成が速い — 掲載文言・permissions正当化文・スクリーンショット構成をその場で提案
• イテレーションの摩擦がない — 45分で7版、20分で5版の連続リリースなど、手作業では現実的でないペースが可能

人間側の工数がボトルネックになる

表を見ると、AI作業時間（5.5h）と人間作業時間（5.3h）がほぼ同じである点に気付かれると思う。

つまり AIをどれだけ速くしても、人間側の工数がボトルネック になる。

今回は要件定義が事前に固まっていたため、そこの往復ラリーが最低限で済んだ。もし「バッジをどこに出すか」「サイズはどうするか」「どのサイトで出すか」をAIと相談しながら決めていたら、要件定義だけで数時間、設計にも影響してさらに数時間追加、と膨らんでいたはずである。

要件定義を人間側で先に固められると、Claude Codeはさらに爆速になる。

逆に言えば、少なくとも今回の開発で人間に残る最大の仕事は 「何を作るかを決めること」 である。そこを曖昧なままAIに投げると、実装が速くても全体としては早くならない。「AIに丸投げして楽をしよう」と思うほど遅くなる、というのが実感である。

コードレビューの方法

前作（詐欺ダメ.com 本体）では、「AIが組んだコードは見ず、設計書と目視テスト・本番動作確認だけで判断する」というスタンスを取っていた。自分のサーバー内で完結するサービスであり、万一問題があっても影響が自分に閉じるためである。

しかし今回の拡張機能は ユーザーのブラウザ上で動作する。バグや意図しないDOM改変があれば、そのままユーザー側に被害が出る。よって今回はコードそのものを人間の目で確認する方針に切り替えた。以下、その具体的な進め方である。

1. 段階的レビュー：小さく作らせて小さく確認

一度に大きな機能を投げると、生成コードの量が増え、レビュー負荷が跳ね上がる。今回は以下のように機能を細切れにして進めた。

• サーバAPI 2本 → 単体で動作確認 → git commit
• 拡張の骨組み → ローカルで読み込み確認 → commit
• Shadow DOM化 → 表示確認 → commit
• 各機能追加ごとに版を切って commit

1 commit = 1 変更単位にすることで、git diff の読める分量に自然と収まる。v0.3.0〜v0.4.6 で 12 版を切っているのはこの結果である。

2. git diff を必ず自分の目で読む

Claude Codeは差分を自動で表示するが、それを流し見せず、以下の観点で必ず読む。

• 意図しないファイルに手が入っていないか — 頼んでいないファイルが変更されていたら要確認
• 既存関数のシグネチャが変わっていないか — 呼び出し側との整合性チェック
• エラーハンドリングが妥当か — try/catchで握りつぶしていないか
• セキュリティ観点 — 特にサーバ側は認証・レート制限・SSRFガードを毎回確認

3. Jest によるテストカバレッジ 80%以上を維持

拡張のロジック層（lib.js）にはJestで単体テストを書かせ、カバレッジ 80%以上を目安に維持している。今回の実測は以下の通り：

指標	実測値
Statements	96.42%
Branches	88.67%
Functions	100%
Lines	97.77%

「AIが書いたコードだからテストは書かなくていい」ではなく、AIが書いたコードだからこそテストで挙動を固定する、というスタンスである。仕様変更時にAIが意図しない副作用を入れても、テストが赤くなれば即座に気付ける。

4. 実サイトでの動作確認は必ず人間の目で

拡張の場合、複数の実ECサイト（Amazon、楽天、独自EC、SPA系、非EC系）を実際にブラウザで開いてバッジ表示を確認した。

ユニットテストが通ることと、実サイトで期待通り動くことは別問題である。特にDOM操作系はJestだけでは絶対に検知できない挙動が出る。

5. 本番反映は commit → 承認 → デプロイの順を厳守

• ローカルで動作確認
• git commit（署名付き）
• 内容を再確認して承認
• 本番反映

一気通貫で commit → push → deploy を回すと、後から「なぜこの変更が入っているか」を追いにくくなる。commit粒度を保つことがレビュー可能性の担保になる。

/code-review スキルが最近アツい

コードレビュー方法の中で /code-review スキルに軽く触れたが、これはもう少し丁寧に紹介したい。X上でも本体アカウントが取り上げており、今少し注目されている機能である。

/code-review は、Claude Code に用意されている「変更差分を別インスタンスに読ませて指摘を得る」スキルである。実装した本人（人間 + AI）とは別視点から差分をレビューするため、以下のようなセルフレビューでは気付きにくい欠陥を拾ってくれる。

• 未使用変数・冗長な条件分岐
• リソースリーク・awaitし忘れ
• エラー握りつぶし
• 既存ヘルパーの再発明
• 意図しない副作用

2026年7月に導入された「労力レベル (effort level)」

2026-07-17、Claude Devs 公式（@ClaudeDevs）より、/code-review に 労力レベル が導入されたことが告知された。

• 低労力 (low) — わずかなトークンコストで、他のコードレビューツールを発見件数で上回る
• 高労力 (high) — より深く掘り下げたい時に、大幅に高いリコールを届ける

トレードオフを開発者側が選べるようになった。

私の使い分け

場面	労力レベル
日常の commit 前チェック	low
リリース前・大きな設計変更	high
セキュリティ観点の重点レビュー	high

拡張機能のv0.3.0（Shadow DOM 化）とv0.4.0（クローク URL 対応）は設計影響が大きかったため high で流し、それ以外の細かい修正は low で回している。

人間が指示するのか、Claudeが自動で走らせるのか

/code-review は Claude Code のスキルとして提供されており、基本的には人間側が /code-review とコマンドを打って起動する。CIやhooksで自動発火させる設定も可能だが、標準では人間トリガーである。

今回の拡張機能開発で私が叩いたタイミングは以下：

• feature ブランチで PR を切る前
• 「機能実装が一段落したのでレビュー通して」と指示
• リリース候補の最終確認

「機械レビューがあるから人間レビューを省ける」ではなく、「機械レビューが自分の見落としを補ってくれる」 というスタンスが実感に近い。人間レビューの前段階で機械レビューを噛ませることで、人間側は「機械が指摘しない粒度」（設計意図・命名・全体の一貫性）に集中できる。

まとめ

• 拡張機能を 実働約11時間 / 中2日 でChrome Web Store公開まで到達
• 手作業想定は約59時間、短縮率82%
• 既存資産があるプロジェクトの機能追加では、Claude Codeの加速度は特に大きい
• 人間側の要件定義の質が、AI時代の律速段階になる
• 前提の再確認 — 「AIさえ使えば2日で拡張が作れる」ではない。数ヶ月分の既存資産と、事前に固まった要件があってこそのこの数字である

ここまでお読みいただきありがとうございました。

詐欺ダメ.com 拡張版