ご無沙汰しております！
Takagi Susumuです！

今回はClaude Codeで開発した詐欺ダメ.com時のAIとの付き合い方のお話

詐欺ダメ.comってなに？

偽通販サイトの商品ページの特徴をコード解析、特徴をスコアリングして偽通販サイトかどうか教えてくれるサービスです。
また、偽通販サイトの痕跡を手掛かりに自動巡回を行い偽通販サイトのドメインを登録してくれます。

2026年6月23日現在、13,000件の偽通販サイトのドメインを記録しています。

このサイトはClaude Codeで開発しており、その時のお話です。

従来の開発とAI開発、何が違う？

流れ自体は従来と変わらないハズです。

プロジェクトの流れ

全ての作業をAIに任せたとしても、大筋は変わらないが圧倒的にスピードが違う！
例えばこの詐欺ダメ.com開発は、このツイートの翌日から始まった。

この2日後、このツイートである

この時点で、大まかな機能は既にローカルテストまで完了し、デプロイできる状態になっていた。
ここまでの主な作業時間の内訳は以下である

工程	AI作業時間	人間作業時間	合計	人間のみ作業想定	短縮率
📋 要件定義	0.3h	1.0h	1.3h	1.5h	13%
🎨 設計	1.5h	2.0h	3.5h	5.0h	30%
💻 実装	7.0h	3.5h	10.5h	40.0h	74%
🧪 テスト	2.0h	1.5h	3.5h	8.0h	56%
合計	10.8h	8.0h	18.8h	54.5h	66%

要件定義、設計は人間の作業が増えるのは仕方なし
いくらAIとはいえ、技術者の頭の中は見通せないですからね・・・

注目すべきは、実装とテスト
AIの実装時間にローカル開発環境（Docker環境の構築、DB設定など）が含まれた上での時間である事
また、テストは以下の条件をAIに課している
　・プログラムの見直し（無駄な処理や最適化を行う事）
　・テストの指標として、カバレッジ率80％をクリアする事

当然、テストプログラムはAIが作り、pytestを使用してこれら条件をカバーした上での3.5hなのである！

偽通販サイトかどうかは固有のシグナル検知で判断するが、この固有のシグナルのサイクルが想定より早く、偽通販サイトかどうかをAIに任せるとドメインなどの関連情報でハルシネーションを起こしかねないので、ルールベースで解析するしかない・・・
この手間を最短でこなせるAI開発を使わない手はない！

AIに適切な仕事をさせるコツ

AIに任せれば全部やってくれる、というのは半分嘘で、半分本当。
詐欺ダメ.comの開発事例を元に「うまく回す」と「事故る」の境目をいくつか紹介します。

① プロジェクトルールの文書化

AIを使う上で一番重要なのがこれ。
特にチームでAIを使う場合は、一定の品質を確保するためプロジェクトルールを文書化して内部で共有する必要があり、ここに漏れがあると「予期せぬ実装、品質の低下」や「ルール違反」が必ず起こる。

文書化すべき内容

コーディング規約
作業上でのルール
フロントエンド・バックエンド等のクラス構成
GitHub等のソースコード運用ルール
本番環境へのデプロイルール
そのプロジェクト固有の禁忌事項

最後の「禁忌事項」、これがクセモノで、ハマって初めて気づく類のもの。
詐欺ダメ.com の例で言うと、こんなのが文書化されている。

「docker compose down -v 禁止」(named volume が消し飛ぶ)
「偽通販ドメイン文字列はコマンドラインに直書きしない」(Windows Defenderが反応する)
「屋号や法人名で正規ECサイトかを判断しない」(屋号運営の真っ当な店を晒すリスク)

口頭で言ってもセッションが変わると忘れる。文書化が必須である。

② ハルシネーションを防ぐ

AIは「思い込みで動く」事を前提と考えておく必要がある。

例えば、不具合調査を依頼すると

「重大発見です！○○○のパターンでエラーが発生する事が分かりました！」

と報告してくる。

報告は有難いが、報告した内容を対処(内容を受け入れる、忘れろと指示する等)しないと報告した内容を前提に動き始める癖があり、これが後のハルシネーションを引き起こす。

そう、AIも「新人社員が自分の成果をアピールしたがる」ように物事に固執するのですw

実際、詐欺ダメ.com 開発でもこんな事があった

AI:「指定のサーバーを調査したら偽通販サイトは 0件でした！」
私:「本当か？じゃあ追加で深堀しろ」
AI:「(深堀)…あれ、よく見たら 5件ありました。先程の検索ロジックにバグがありました」

…さっきの「0件」を前提に話を進めていたら完全にハルシネーションだった。
「報告された数字は鵜呑みにせず、必ず別ロジックで再検証させる」 これが対策。

③ 「コードを書く前に確認させる」がすべての起点

AIは何か指示すると、ものの数秒でコードを書き始める。
これが最大の罠。

例えば「○○のカラム追加して」と頼んだら、関連する3つのテーブルと5つの関数を読まずに勝手にコードを書き始め、結果として存在しないカラム名・無駄な関数を量産する。

で、私が動作確認して「動かないよ」と言うと、AIが「あ、すみません」と直す。
この往復が無駄。

「書く前に影響範囲を全部読んで報告して」と最初に伝えておく。これで防げる。
ただしこの指摘を入れても「広域的に仕様を確認する」という点が極めて甘くなるので、コードの方向性は必ず人間が確認する。

④ 「ついでに直しときました」が一番怖い

AIに調査を頼むと、こういう報告が来る

「○○の調査が完了しました。なお調査中に△△にバグを発見したので、ついでに修正しておきました」

…勝手に直すな。

その修正が正しいかどうかも検証してないし、意図しないタイミングで状態が変わるから、後で「あれ、ここいつ直した？」となる。
コードレビューしたとしても、本来の依頼と無関係な diff が混ざる。

「気づいたら報告だけ。修正は指示してから」 これが正解。

⑤ 本番環境への扱いは"絶対に"明文化する

これはマジで怖い話。
AIは本番サーバーにも普通にアクセスでき、SSH も叩ければ Docker も操作できる。

しかも詐欺ダメ.com の場合、外部の偽通販サイトを自動巡回する性質上、解析対象のHTMLに 「Claude を騙すような悪意ある文字列(プロンプトインジェクション)」 が仕込まれているリスクも考えないといけない。
AIに本番権限を渡したまま外部HTMLを"読ませる"と、最悪 「解析対象に乗っ取られて本番DB破壊」 まであり得る世界である。

そこで設計段階から、以下の様なルールを設定し運用している。

本番アクセスのルール

全変更は「ローカルで動作確認 → 技術者の承認 → 本番反映」の順
本番直接の書き込み系操作は禁止
デプロイ前後でDB件数(ブラックリスト・問い合わせ)の差分チェック必須

プロンプトインジェクション対策(アーキテクチャ分離)

巡回バッチはClaude Code 本体とは独立した Python プロセスで動作
取得した外部HTMLは正規表現とCSSセレクタによるルールベース判定のみに使用し、LLMのプロンプト文脈には一切流さない
Claude Code が触るのは自社コード・自社DB・設計書だけ

つまり「LLM領域」と「外部HTML解析領域」を最初からプロセスレベルで分離することで、解析対象から AI が乗っ取られる経路を構造的に塞いでいる。

これらは全て CLAUDE.md(プロジェクト直下のAI向けルール文書)に明記 している。

特に最近は GitHub Actions でデプロイ自動化と言う所もありますからね。
そういう仕組みの中で AI が自由に動くと事故るので、明文化の重要性は増す一方 だと感じている。

⑥ 「同じ事を二度言わない仕組み」を持つ

Claude Code にはメモリ機能(プロジェクト固有の知識を永続保存する仕組み)がある。

私はここに、これまで AI が起こした失敗パターンを片っ端から放り込んでいる。
詐欺ダメ.com のメモリには現在 17件のフィードバック・ルール文書 が蓄積されている。

「グリッドのカードに h-full 忘れがち。新規実装時は必ず確認」
「git stash drop 禁止(作業変更消失の致命事故)」
「公式機関への提出書類は推測撤廃・観測事実のみ」

こういう「ハマった経験」を全部メモ化すると、次のセッションで同じ事故が起きない。
人間の技術者に「前に言ったよね？」がストレスフリーで実現するのはAIならではの強みである。

⑦ テストの合格条件は"数値"で出す(ただし数値だけは信じない)

「ちゃんとテスト書いて」と曖昧に頼むと、形式だけ整った中身のないテストが量産される。

私は 「カバレッジ80%以上」「無駄処理の見直しと最適化を含めること」 を最低条件にしている。
数値目標があると AI は本気を出す、不思議と。

今、詐欺ダメ.com のテストは 691件 PASS / カバレッジ 86% で運用しているが、セキュリティテストや高負荷テストも課しており、テスト指標としてはかなり厳しい方。
新機能を追加するたびに pytest が増え、デプロイ前に全件 PASS が走る。
正直、人間が手で書いたらこの密度は無理である。

ただし「カバレッジ率は絶対指標ではない」事は強調しておく。

AI製テストは下手すると 「assertion がスカスカで何も検証していないテスト」 を量産してカバレッジだけ稼ぐ。
そこで詐欺ダメ.com では、最初から以下の二段構えで品質を担保している。

実在の偽通販URLをfixtureに組み込み、実機判定を含める
正規ECサイトも検証対象に入れ、誤検知ゼロを確認
本番のブラックリスト判定精度(真陽性率 84% 維持)を実運用KPIとして観測

カバレッジは「最低ライン」として使い、最終品質は実機データで担保している。

⑧ AIに任せていい範囲を見極める

要件定義と設計に人間時間が多めなのは仕方ない。
「URL貼って判定するツールを作りたい」「広告なしで」「個人事業主を誤検知してはいけない」みたいな理念や判断は人間がやるしかない。

逆に、設計が固まった後の 実装・テスト・デプロイ手順構築 はAIに任せた方が圧倒的に早い。

私の場合、設計段階で

2ステップパイプライン(ホワイトリスト足切り → フルスキャン)の構造
シグナル配点の方針(配点表は AI 草案 → 人間レビュー)
個人事業主誤検知の絶対回避

…ここだけ死守して、あとは流し込み。
偽通販サイトのルール判定プログラム(数千行)は、ほぼ全部 AI 製である。

「数千行のAI製ルールコードってスパゲティ化して誤判定追えなくなるんじゃ?」という疑問は当然出てくる。
これは設計段階で「コードを読まずに運用できる構造」を作って解決している。

各検知ルールにはシグナル名を付与
判定結果に 「どのシグナルが反応したか」の配列を必ず含める
管理画面でその配列が一覧表示され、誤判定時はどのルールが原因か即追跡可能
誤判定報告にはホワイトリスト追加 + シグナル調整で対応

つまり「人間がコードを読まなくても、運用時に何が起きてるか分かる」状態を最初から作り込んでいる。

AIが組んだプログラムを人間が確認する必要があるか？

これは最近のホットな話題。
今回の詐欺ダメ.com は個人で作った物なので自由にやっており、AIが組んだ内容は一切見ていない。
その代わり、プログラム設計書・クラス図・DBのER図などを作成させ確認している。

結局、人間が確認したいのは「プログラム」というより最終的な責任の担保が大きいのでは?

特にチームプロジェクトでは、プログラムが原因で重大な事故や損失が起きたとき、「AIが悪いんです!」と責任を取らす事は出来ないので、システムを世に出す以上、人間が責任を持って品質を保証する必要がある。

ちなみに私のスタンスは

個人開発: 設計書・目視テスト、報告されたテスト内容・本番動作だけ確認。コードは見ない
チーム/受託: 設計書 + コードレビュー必須。責任の所在を明確化

「コード見ないと将来チーム化や引き継ぎで困るのでは?」と聞かれそうだが、そこも織り込み済みである。

設計書・ER図・クラス図はAI作成で常に最新化 → 引き継ぎ資料は揃っている
シグナル命名と signals 配列で 「コードを読まずに挙動を追える」構造を維持
コード内部の細かいロジックは未読 → 引き継ぎ時のコードレビュー工数は発生する

つまり「個人で爆速開発する代償として、将来のリファクタリング・引き継ぎコスト」を後払いしている。
個人サービスとして爆速で世に出す価値の方が大きいと判断したからこの方針にしているが、最初からチーム/受託前提なら、コードレビューを工程に組み込む方が後々得である。

まとめ

ざっくり言うと、AIに正しく仕事をさせるコツは

プロジェクトルールを文書化する(口頭指示は忘れる前提)
ハルシネーションを警戒する(報告は別ロジックで再検証)
書く前に影響範囲を確認させる(承認 → 実装の順)
勝手に直させない(調査と修正を分離)
本番環境のルールは特に厳格に(重大事故防止 + プロンプトインジェクション対策)
失敗パターンをメモに残す(同じ事故を二度起こさない)
テスト条件は数値で出す(ただし数値を絶対視せず実機データで担保)
理念と判断は人間。実装はAI(分業の線引き + 引き継ぎ可能な構造設計)

これさえ守れば、AI は驚くほど従順で優秀な同僚になる。
逆に守らないと、やる気はあるけど暴走する新人に化ける。

…と偉そうに書いたが、これでも私、相当な回数AIに 「こら！勝手に直すな！」 と怒っている(笑)

その**「AIに怒った10の事件」**は、また次の記事で。

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