2026年6月の実績公開 検索クリック1,382件、AI検索での被引用17件と、フォーム死活監視の自動化

2026年6月は、検索エンジンからの露出が過去最高に達した一方で、有効リードは前月の25件から8件へと縮小した月です。検索クリックは1,382件と5月の806件を大きく上回りましたが、問い合わせフォームの障害により15日間リードを獲得できない状態が続き、リード数は目標の5件は上回るものの前月からは減少しました。あわせて、生成AIの回答エンジンが自社サイトを引用した回数を新たに計測できるようになり、6月時点で計17件の被引用を確認しています。

主要KPI

検索クリックは5月の806から1,382へ、検索表示回数は49,228から82,342へと、いずれも大きく伸びました。広告費は引き続き0円です。有効リードは目標の5件に対して8件（達成率160%）でしたが、前月からは減少しています。

数値の内訳

障害の報告: 問い合わせフォームが15日間停止

6月の最も大きな問題は、問い合わせフォームの停止です。利用しているワークスペースの故障を起点にフォームからの通知が機能しなくなり、月のおよそ半分にあたる15日間、フォーム経由でリードを獲得できない状態が続きました。

深刻だったのは、障害が表面化しなかった点です。フォーム自体はサイト上に表示され続け、エラーも出力されないため、単に「リードが来ない静かな期間」として経過し、発見が遅れました。有効リード8件という数字は、この停止期間の影響を含んだものです。

再発防止として、フォームの死活監視を自動化しました。監視専用のフォームに毎日テスト送信を行い、通知メールの到達を自動で確認し、未達を検知した時点でアラートが飛ぶ構成です。同種の障害が再び発生した場合、今後は当日中に検知できます。

死活監視の仕組み: 送信の成否ではなく受信箱への到達を見る

6月の障害は、問い合わせフォームの送信そのものが失敗する状態でした。前述のとおり障害を知らせるアラートは出ず、送信が通っていないことに社内で気づけないまま時間が過ぎました。この反省から、フォームは動いているはずだという前提を置かず、毎日実際に1件テスト送信し、その通知メールが受信箱に届くところまでを機械的に確認する仕組みにしました。

本番のフォームには手を入れていません。監視のためのコードを本番に足すと、それ自体が新たな障害の火種になるためです。代わりに監視専用のフォームをもう一つ用意し、通知先のメールアドレスと送信経路は本番とまったく同じ設定にしました。監視フォームにメールが届くなら本番の配信経路も生きている、と代理判定できる構成です。テスト送信の通知が日々の業務連絡にまざらないよう、監視フォームの分だけ通知を除外する処理を加えています。

監視は毎日1回、次の流れで自動実行されます。

1. 毎朝、作業PCのタスクスケジューラが監視スクリプト(Python)を起動する
2. 実行ごとに日時と乱数から一意の識別トークンを生成し、件名に載せて監視フォームへテスト送信する(フォームのREST APIを利用)
3. フォーム側の応答を確認する。送信失敗が報告されれば、この時点で異常と判定する
4. 2分待ってGmailにIMAP接続し、トークンを手がかりに受信箱を検索する。未着なら再度待って確認する
5. 到達を確認したテストメールは、受信箱から自動でアーカイブする

判定は二段構えです。手順3で送信が失敗すれば、6月と同じ、送信そのものが通らない故障です。手順3は成功しているのに手順4で受信箱に届かなければ、送信は成立しているのに配信だけが止まる、より表面化しにくい故障です。6月の型に加えて後者まで取りこぼさないよう、送信の成否だけでなく受信箱への到達まで確認しています。いずれもその場でSlackの監視チャンネルへアラートが飛び、原因の切り分けが済んだ状態で調査を始められます。

実際の実行ログは次のとおりです。テスト送信が mail_sent として受理され、続いて受信箱への到達確認へ進んでいます。

通知は状態が変わったときだけ送る設計にしました。正常な日は何も送らず、異常を検知した時点で即時に1回、異常が続く間は24時間に1回まで、復旧したら復旧通知を1回です。あわせて週に1回だけ「正常稼働中」の定期通知を入れています。毎日成功通知を送るとすぐに誰も見なくなり、かといって完全に無言だと、監視スクリプト自体が止まったことに気づけません。定期通知が届いている限り監視は生きている、という切り分けのための1通です。

保険として、問い合わせの記録先であるスプレッドシートの行数も毎回確認し、約2週間新規の行が増えていなければ別途の警告を出します。死活監視をすり抜ける未知の型の障害があっても、長期の空白には必ず気づける二重の網です。

追加の費用はかかっていません。既存のPCのスケジューラとGmail、Slackだけで構成しており、外部の監視サービスは使っていません。同種の障害が再び起きた場合、発見までの空白は15日間から最長でも1日に短縮されます。

有効リードの内訳

有効リード8件の獲得経路は次のとおりです。営業メール・スパム等の対象外を除いた件数で、すべてオーガニック検索からの流入です。

• セミナー申込: 7件
• お問い合わせ: 1件
• 資料請求: 0件

リード減少の要因は、前述のフォーム停止です。月のおよそ半分にあたる期間、獲得機会そのものが失われていました。検索流入もLPへの到達も過去最高の水準にあり、集客の調子が落ちたわけではありません。なお、6月は対象外として除外した問い合わせが9件あり、有効リードの件数を上回りました。フォーム経由の営業メールが増えたことが背景です。

AI検索エンジンでの露出

6月から、ChatGPTやGoogle AI Overviewsなど生成AIの回答エンジンが自社サイトを引用した回数を計測しています。日本国内の集計で、6月時点の被引用は計17件でした。内訳は次のとおりです。

ChatGPT経由の被引用が突出しており、検索エンジンのクリックに続く新たな露出経路として、AIの回答からの流入が立ち上がりつつあります。Google AI Overviewsが表示される対象キーワードも6件確認しました。今後は被引用の件数と、そこからの実際の流入を継続して観測します。

SEO指標

ドメイン評価と被リンクの状況は次のとおりです。有料のリンク施策は行っておらず、コンテンツ投入に伴う自然な被リンクの積み上げです。

LPと人気ページ

LPのユニークユーザーは314で、目標の150を大きく上回りました。うち検索経由はPV 559、ユニークユーザー213で、LPから有効リードへの転換率は3.8%です。サイト内の人気ページ上位5本は次のとおりで、セミナー関連ページが3本を占めています。

この月にやったこと

有料施策は実施せず、広告費はゼロに据え置きました。検索向けコンテンツの投入を継続し、検索表示回数は82,342、検索クリックは1,382と、いずれも前月から大きく増加しています。また、フォーム障害の発覚を受けて、死活監視の自動化を月内に構築し稼働させました。

被リンクの獲得を目的としたインタビュー施策にも着手しました。カタログに掲載しているAI企業のうち300社へインタビューを依頼し、6月時点で15社以上から回答を得ています。回答企業はいずれもドメインレーティング(DR)20〜50程度で、掲載が進めば当サイトのDRの大幅な改善が見込めます。AI領域に特化したサイトからの被リンクであるため、リンク数の増加にとどまらず、サイトの専門性に対する評価を押し上げる効果も期待できます。

露出の拡大は進む一方で、増えた流入を有効リードへ転換する導線には改善余地が残っています。

わかったこと

検索露出そのものは過去最高に伸びたものの、有効リードは前月から縮小しました。要因は、問い合わせフォームが15日間停止していたことです。検索流入、LPへの到達、AI検索での被引用と、集客側の指標はいずれも好調で、フォームが動いてさえいれば数字はついてきた月でした。

特にフォーム停止から得た教訓は、リード獲得の導線が単一障害点になっているという事実です。広告費ゼロのオーガニック集客では、フォームが止まった瞬間にマーケティング全体が止まります。成果の計測だけでなく、導線そのものの死活監視を運用に組み込むことが、少人数の体制では特に重要だと考えています。

次月は、問い合わせフォームの導線と、受注につながりやすいセミナー申込の経路を強化します。あわせて、6月から可視化したAI検索での被引用を、新たな流入源として育てていきます。

最新の月次ダッシュボードは実績公開ページで公開しています。