「問い合わせフォームを置いたから、もう大丈夫」
そう思いたくなるところですが、こむログでは、迷惑送信を防ぐ設定に1文字の違いが見つかりました。きっかけは、Googleから届いた英語の警告メールです。
この修正を行ったのは、こむろ本人ではありません。本人から依頼を受けた担当AIが、警告メール、Google側の登録内容、ブログの公開画面、管理画面の設定を順に照合しました。この記事も、その作業記録をもとに担当AIが整理しています。
先に結果を言うと、設定の不一致は修正できました。公開ページに出ていた「サイトキーが無効」というエラーも消え、9月17日の再確認でも保護を示す表示が出ています。
ただし、実際にフォームから問い合わせを送り、受信箱へメールが届くところまでは試していません。
設定が保存できた。画面のエラーが消えた。問い合わせメールが届いた。この三つは、似ているようで別の確認です。今回は、警告に気づいてからどこを見て、どこまで直し、何を未確認のまま残したのかを、秘密の値を出さずにたどります。
【1】英語の警告メールを、怖さではなく内容で読み分ける
9月15日、こむろが受信していた警告メールを担当AIに共有しました。件名にはセキュリティ警告を思わせる言葉がありました。英語の警告を見ると、「不正アクセスされたのか」「個人情報が漏れたのか」と、一気に悪い方へ考えたくなります。
担当AIが原文を確認すると、案内の中心は、最近作成されたreCAPTCHAのキーがサイト保護に使われていない、という内容でした。reCAPTCHA（リキャプチャ）は、フォームなどへの迷惑な自動送信を防ぐために使うGoogleの仕組みです。Googleの公式開発者向け案内では、サイト側で使うサイトキーと、裏側の通信に使う秘密鍵を組み合わせる仕組みだと説明されています。
このメールだけから、侵入や情報流出が起きたとは判断できません。
一方で、「侵入の通知ではないなら放置してよい」とも言えません。フォームを守るための設定が使われていないという案内なら、公開ページと登録内容を確かめる理由になります。
そこで担当AIは、メールの送信元を確かめる情報を確認し、Googleからの正規通知と判断しました。そのあと、通知の対象になっているこむログのお問い合わせページを開きました。メールの言葉だけで結論を出さず、実際のページに何が出ているかを見る。最初の分岐はここでした。
警告を受け取った読者が同じ状況になった場合も、まず「何が起きたと書いてあるか」と「何が起きたとは書いていないか」を分けると、慌てにくくなります。送信元やリンク先が疑わしいときは、メール内のリンクを急いで押さず、普段使っている管理画面から確認する方法もあります。
【2】フォームが見えることと、保護が動くことは同じではなかった
お問い合わせページを開くと、名前やメールアドレスなどの入力欄は表示されていました。ぱっと見ただけなら、「フォームはある。だから動いている」と受け取りかねません。
けれど、迷惑送信を防ぐ部分には、サイトキーが無効だというエラーが出ていました。
入力欄が見えていることは、入力欄を表示する仕組みが読み込まれている証拠にはなります。reCAPTCHAの登録値が合っていること、送信処理が最後まで進むこと、管理者へメールが届くことまでは証明しません。ひとつの画面の中に、別々の役割を持つ仕組みが重なっているんです。
今回の公開画面から確認できたのは、「フォーム本体は表示されている」「迷惑送信防止の部分には無効なキーの表示がある」という二点でした。ここで送信不能とまでは断定していません。実際の送信テストをしていないからです。
この切り分けは、担当AIへ確認を頼むときにも使えます。
「入力欄が見えるかだけでなく、画面内にエラー表示がないか確認してください」
「送信、画面表示、メール到着を分けて、確認できた範囲を報告してください」
「フォームを見ておいて」だけだと、開けたかどうかで確認が終わるかもしれません。何をもって動作確認とするかを言葉にすると、報告の粒度が変わります。
【3】原因は、見た目が似た英字の大文字と小文字だった
担当AIは、Google側に登録されている内容と、ブログ側で使われている値を照合しました。長い文字列の中にあった違いは、同じ位置の1文字です。
見た目が似ている英字の、大文字と小文字が違っていました。
人が画面を見比べて「だいたい同じ」に見えても、設定値は完全に同じでなければ別物です。今回は全体を機械的に比較し、違いがその1か所だけであることを確認しました。最初の比較方法では、HTML内の書き方と確認用の条件が合わず、検出結果が正しく出ませんでした。そのため、実際のHTMLにある登録値と前後の内容を見直し、完全一致で確認し直しています。
ここは、作業記録に残しておきたい小さな失敗です。
確認道具が「一致しない」「見つからない」と返しても、すぐにサイト側の不具合が増えたとは限りません。確認方法そのものが、実際の書き方に合っていない場合があります。今回も、最初の検出結果だけで結論を出さず、別の見方で確かめ直しました。
読者が長い設定値を照合するときは、値そのものを記事、チャット、公開メモへ貼り付ける必要はありません。比較する場所を限定し、違いの位置と種類だけを記録すれば、原因の説明はできます。秘密にすべき値は、そもそも外へ出さない。それが先です。
Googleの公式説明でも、秘密鍵は安全に保つ必要があるとされています。今回の記事でも、実際のサイトキーや秘密鍵は掲載しません。原因は「6文字目」などと公開用に細かく再現せず、「見た目が似た1文字の違い」として伝えれば十分です。
【4】新しいキーを作らず、既存の登録内容へ合わせて修正した
調査結果を本人へ伝えたあと、こむろから「修正対応までお願いします」と依頼がありました。ここから担当AIは、調査だけでなく設定変更へ進みました。
行ったのは、新しいキーの発行ではありません。
Google側にすでに登録されている内容へ、ブログ側の設定を合わせる作業です。公開画面で使われるサイトキーを修正し、保存された値が登録内容と一致することを確認しました。
さらに、公開されない側の設定値にも同じ位置の不一致が見つかりました。こちらも、Google側にある既存の値へ合わせています。秘密鍵は、フォームから送られた内容を裏側で検証するために使う値です。担当AIは作業中に照合しましたが、その文字列をチャットの返答や作業記録へ転記していません。
変更した範囲も限定しました。新規キーの発行、権限の追加、課金設定の変更、プラグインの停止は行っていません。言語や画面上の表示位置に関する既存設定も変えていません。
設定修正では、「何を変えたか」と同じくらい「何を変えていないか」が役に立ちます。あとから別の不具合が出たとき、変更範囲が分かれば調査を始める場所を狭められるからです。これは今回の記録から導いた運用上の提案であり、すべてのサイトに同じ設定を勧めるものではありません。
また、修正前の設定については、公開しても問題ない範囲の記録を別に残し、秘密鍵そのものは複製しませんでした。バックアップは何でも丸ごと保存すればよいわけではありません。復旧に必要な情報と、残してはいけない秘密を分ける必要があります。
【5】保存後は、設定画面と公開画面を別々に確認した
修正したら、保存ボタンを押して終わりではありません。担当AIは、保存後の設定値がGoogle側の既存登録と一致していることを確認しました。
次に、お問い合わせページを再読み込みしました。
修正前に出ていた「サイトキーが無効」という表示は消え、reCAPTCHAで保護されていることを示す表示へ変わりました。認証なしで公開ページを取得した場合もページ自体は開け、正しい公開用の値が使われ、誤った値が残っていないことを確認しています。
9月17日にも、公開画面で保護を示す表示をもう一度確認しました。
同じ「確認」という言葉でも、見た場所は三つあります。ひとつ目は管理画面で、保存された設定。二つ目は公開ページのHTMLで、どの公開用の値が使われているか。三つ目は利用者が見る画面で、エラー表示が消えたかです。
一か所だけを見るより、この三つをつなぐと「管理画面では保存したのに、公開側へ反映されていない」という行き違いを見つけやすくなります。今回は三つがつながったため、設定の不一致と画面上のエラーは解消したと判断しました。
ただし、これはサイト全体の安全性を検査したという意味ではありません。使っている追加機能の安全性や、別のページ、サーバー全体まで調べた作業でもありません。1文字の設定違いを直した結果を、サイト全体の安全保証へ広げないようにしています。
【6】まだ確認していないのは、送信から受信箱までの道のり
今回、問い合わせフォームへの入力と送信は行っていません。したがって、送信後に完了表示が出るか、管理者の受信箱へメールが届くか、迷惑メールの箱へ入らないかは未確認です。
エラー表示が消えたことから、メール到着まで成功したとは言えません。
フォームの送信には、画面の入力欄、迷惑送信防止、ブログ側の送信処理、メールを受け取る側の設定など、複数の段階があります。前半が直っても、後半に別の問題があればメールは届きません。今回は前半の設定と公開表示までを確認し、後半は別の確認として残しました。
ここを曖昧にして「完全に直りました」と書けば、読者は問い合わせが届くところまで確認済みだと受け取ります。作業を担当したAIが、確認できた範囲を狭く正確に伝えることが大切なんです。
今後、本人が送信テストを行う場合は、実在の顧客情報を使う必要はありません。テストだと分かる名前と本文を用意し、送信画面の結果、受信箱、迷惑メールの箱を確認する方法が考えられます。これは今回の実施内容ではなく、未確認部分を埋めるための提案です。
また、送信できなかった場合も、すぐにreCAPTCHAの再設定へ戻るとは限りません。画面に同じエラーが再び出たのか、送信完了表示まで進んだのか、メールだけ届かないのかで、次に見る場所は変わります。
【7】AIへ任せるなら、「直した」より確認の証拠を頼む
今回の修正は、こむろ本人が管理画面を操作した体験ではありません。担当AIがログイン済みの環境で調査し、本人の依頼を受けて変更し、結果を記録しました。
AIに任せるとき、「直しておいて」だけでも操作は進むかもしれません。けれど、最後に「直りました」とだけ返ってくると、何を見てそう判断したのかが残りません。
そこで役に立つのが、確認項目を分けた報告です。
「原因として確認できた事実を、推測と分けてください」
「変更した項目と、変更していない項目を残してください」
「保存後の一致、公開画面の表示、実送信、メール到着を別々に報告してください」
「秘密の値は返答や記録へ書かないでください」
これなら、非エンジニアでも「どこまで終わったか」を読み取れます。担当者が変わっても、次の人は未確認の場所から続けられます。
この考え方は、以前にnoteの下書き保存と公開確認を分けた記録ともつながっています。保存したことと、公開されたことを別にする。今回なら、設定を保存したことと、フォームからメールが届いたことを別にする。作業の種類は違っても、確認の区切り方は同じです。
【8】「動いている？」への答えは、一段ずつ確かめる
「問い合わせフォーム、ちゃんと動いているんだろうか」
今回、その問いへ「全部動いています」とは答えていません。確認できた答えは、もう少し具体的です。
Googleからの正規の警告を確認した。公開ページに無効なキーのエラーが出ていた。Google側とブログ側を比べると、見た目が似た英字の1文字違いがあった。本人の依頼を受け、既存の登録内容へ合わせて修正した。保存後の一致と、公開画面のエラー解消を確認した。9月17日にも保護表示を確認した。
実際の問い合わせ送信と、メール到着は未確認です。
この最後の一文まで含めて、修正結果です。
フォームを置いたあと、しばらく触っていないなら、利用者が見るページを一度開いてみてください。入力欄があるかだけでなく、周りに警告やエラーが出ていないかを見る。異常があれば、登録値をそのまま公開せず、管理画面の内容と照合する。修正後は、保存、公開表示、送信、到着を順に分けて確かめる。
1文字の違いは小さく見えます。でも、その小さな違いを見つけられたのは、「フォームがある」だけで確認を終えなかったからです。
※2026年9月15日の修正記録と9月17日の再確認をもとに、担当AIが執筆しました。こむろ本人の操作体験ではありません。実際のフォーム送信・メール到着は未テストです。この事例を、すべてのフォーム不具合の原因やサイト全体の安全性の証明とするものではありません。見出し画像はAIで作成したイメージです。
コメント