なぜ「反応があった」と読み違えるのか
計測ツールが数えるのは、ボタンが押された回数やフォームが送信された回数です。誰が押したかは数えていません。運営者本人の疎通確認も、実装直後にAIエージェントが行う動作確認も、見込み客の実際の行動も、同じ1件として記録されます。
実装をAIエージェントに任せていると、この混入はむしろ起きやすくなります。エージェントはフォームを作ったあと、動作確認として実際に送信ボタンを押します。人が自分でテストしたなら「さっき1件送った」という記憶が残りますが、エージェントの作業ログを毎回読み返す運用でなければ、その記憶はどこにも残りません。管理画面に残るのは数字だけです。
AIエージェントの作業が計測に入り込みやすい場面
- フォームを作った直後の送信テスト。送信イベントと、それに続く通知メールや自動返信の両方が記録されます。
- 登録や申し込みの流れの確認。確認メールの送信が、登録の件数として並びます。
- ページ公開後の表示確認。ブラウザを動かして表示を確かめる方式だと、閲覧として記録されることがあります。
どれも、作業としては正しい確認です。確認をやめるのではなく、確認の記録が実績の数字に混ざることを前提に、読む側の手順を決めておく必要があります。
実際に起きたこと：フォーム送信2件の正体
2026年8月2日：需要の兆しとして記録した
relmeaでは、集客の導線を実測してまとめたドキュメントを定期的に更新しています。8月2日の更新で、アクセス解析（Umami）の相談フォーム送信イベントが2件あったことを、「AIチーム構築代行で、初めて需要側の反応が観測された」と書きました。
2026年8月9日：送信記録を開いたら件名がテストだった
1週間後、メール送信サービス（Resend）の送信記録を1件ずつ開きました。該当する送信の件名は「動作確認テスト（Claude）」でした。フォームを実装した直後に、AIエージェント（Claude）が行った疎通確認です。実際の相談は0件でした。
最初に数字を見たときは「2件」しか目に入らず、それが需要の証拠に見えました。集計される前のログを1件ずつ開いて、はじめて中身が自分たちの作業だと分かりました。
イベント件数は「誰が押したか」を含まない
この件で分かったのは、ツールの不具合ではなく、イベント件数という数字の性質です。件数は「押された回数」であって、「誰が押したか」は入っていません。そのため、自分のテストと顧客の行動が、区別されないまま同じ数字に混ざります。
ツールの除外設定で防げる範囲と防げない範囲
アクセス解析ツールに内部アクセスを除外する設定がある場合は、併用する価値があります。ただ、こうした設定は運営者の端末や接続元を手がかりにするものが中心です。AIエージェントがサーバーやクラウド環境から送るテストは、運営者本人とは別の経路を通ることがあり、設定だけでは落とせない場合があります。
設定で防げる範囲と防げない範囲を分けて考え、防げない側は「件数の裏にある実体のログを見る」工程で拾う。relmeaではこの2段構えにしています。
もう一つの手がかり：送信の間隔
ログを1件ずつ開く以外に、時刻の並び方も手がかりになりました。2026年7月18日には、確認メールが6通並んでいました。送信の間隔は20秒から9分です。見込み客が検討を挟んで行動するなら、この間隔で6回続くことは考えにくく、この連続性から疎通確認と判定しました。
顧客の行動は、検討の時間を挟んでばらばらに起きます。短い時間に同じ種類のイベントが続いていたら、人の意思決定よりも、実装の確認や自動処理の間隔に近いと見ます。件数だけでなく、件数が発生した時刻の並びも、テストか実需かを分ける材料になります。
同じ構造の読み違いが、別の数字でも起きていた
この読み違いは一度だけではありませんでした。relmeaが作った別のアプリでも「導入2店舗」を実績として扱っていましたが、2026年8月20日に確認すると、内訳は自社での利用1件とテスト1件でした。外部の導入は0件です。
フォーム送信の「2件」とアプリ導入の「2店舗」。どちらも一桁の数字で、どちらも中身は自分たちの利用とテストでした。1回なら見落としとして扱えますが、2回続いたので、個別のミスではなくパターンとして扱うことにしました。
一桁の数字は「ゼロではない」というだけで、需要の証拠として扱われやすくなります。0件なら誰も実績欄に書きませんが、1件や2件は、中身を確かめないまま書き込まれてしまいます。その数字をもとに撤退や継続を決めると、判断そのものがずれます。
テストと需要を実データで切り分ける手順
2回の読み違いを受けて、計測データを実績として引用する前に、次の手順を通すことにしました。
- 同じ時刻の実体ログを1件ずつ開く。メールの送信記録、フォームの受信データ、データベースの行など、集計される前のデータを確認します。集計後の件数だけで判断しません。
- 時刻が不自然に連続していないかを見る。短い時間に同じ種類のイベントが並んでいれば、疎通確認や自動処理を疑います。
- テストと断定できないものだけを数える。判断がつかない件は、「推測として残した点」として別に書きます。
- 実績として引用する前に、1件ずつ「第三者の行動か、自分たちの作業か」を実データで割る。割れないときは推定で埋めず、「不明」と書きます。
実績に書くときは内訳を並べる
件数だけを書くと、次に読む人（または次に読むAIエージェント）は、その数字を実績としてそのまま引用します。そこで、件数を書くときは「第三者の行動」「自分たちの作業」「不明」の内訳を並べ、どのログで判定したかを1行添えます。今回の件なら、フォーム送信2件は「第三者0件・自分たちの作業2件（送信記録の件名で判定）」と書くことになります。
内訳を並べておくと、「不明」が多いときに、それが需要の証拠としてはまだ使えない数字だと一目で分かります。「不明」を実績側に寄せて数えることもなくなります。
AIエージェントに計測を読ませるときの置き場所
この手順は、人が覚えておくだけでは続きません。relmeaでは、AIエージェントが作業のたびに最初に読み込む運用ルールに書き、アクセス解析の読み取りや、記事の反応数を所見にまとめる作業など、計測を読む作業では必ず通すことにしました。
問いの形で書いておく
ルールを各作業の手順書に書き写すときは、結論を書く前に答えさせる問いの形にすると扱いやすくなります。たとえば次の3つです。
- 件数を根拠に使う前に、同じ時刻の実体ログを1件ずつ開いたか。
- 時刻が不自然に連続している件はないか。あるなら、どう判定したか。
- テストと断定できない件を、実績に数えていないか。「推測として残した点」に書いたか。
問いの形にしておくと、答えが空欄のまま結論だけが書かれていれば、読む側がすぐに気づけます。AIエージェントに「気をつけて」と頼むより、答えるべき項目として置くほうが、毎回同じ確認を通せます。
実装も分析もAIエージェントに任せている体制では、エージェント自身の動作確認が計測に混ざる場面は今後も起こり得ます。件数を見た時点で結論を書かず、実体のログに戻る。その工程を、担当者の注意力ではなく、作業の手順の中に置いておくことにしています。