お問い合わせフォームをAIに作らせるとき、指示に入れたい9つのこと｜情報漏えいを防ぐ

お問い合わせフォームは、ほとんどのサイトにある、いちばん身近な「入力を受け付ける場所」です。名前・メールアドレス・電話番号・相談の中身と、個人の情報がそのまま集まります。

いまは、このフォームを AI（Claude・ChatGPT・Gemini など）に作ってもらうことも増えました。「お問い合わせフォームを作って」と頼めば、見た目も動きもそれらしいものがすぐにできます。ただ、見た目がちゃんと動いていても、守りが入っているとは限りません。 AI は、言われていないところまでは自分で気を回してくれないことがあるからです。

この記事では、お問い合わせフォームを AI に作らせるとき、情報の漏えいや不正アクセスにつながらないように、指示の中に何を書いておけばいいか を、IPA（情報処理推進機構）や OWASP（ウェブの安全を研究する国際的な団体）などの公式の資料をもとにまとめました。最後に、そのまま貼って使える指示文も載せています。

結論：指示に入れておきたい9つのこと

1. 入力のチェックは、ブラウザだけでなくサーバーでも する
2. 通知メール・自動返信メールの 宛先と件名に、入力をそのまま入れない
3. 確認画面・管理画面に出すときは、入力を無害な文字に置き換えてから 出す
4. データベースに入れるときは、決まった安全な書き方（プレースホルダ） にする
5. ロボット対策（reCAPTCHA など）は、サーバーで答え合わせ をするところまで
6. 受け取った内容は、外から見られない場所 に置き、記録（ログ）に個人の情報を残さない
7. メールのパスワードや鍵を、プログラムの中に書かない
8. エラーが起きても、中身（エラーの詳しい内容）を画面に出さない
9. 送信ボタンの前に、何のために情報を使うか（利用目的） を見せる

そして、作り終わったら「どの項目を、どう満たしたか」を AI に一覧で出させて、人が確かめます。

1. 入力のチェックは、ブラウザだけでなくサーバーでも

「メールアドレスの形になっていない」「必須の欄が空」といったチェックを、AI はよく ブラウザの中（画面の側）だけ で作ります。画面で赤い文字が出るので、ちゃんと守られているように見えます。

でも、ブラウザのチェックは、送る人が自分の手元で外せます。OWASP の「入力の確かめ方」の手引きは、よくある失敗としてこう書いています。

Validate on the server even when the browser checks the same fields. Client-side validation is bypassable

（訳：ブラウザで同じ項目を確かめていても、サーバーで確かめること。ブラウザ側の確かめは、すり抜けられる）

同じ手引きは、「悪い文字を見つけて消す」のではなく、受け付けるものを決めて、それ以外を断る やり方をすすめています。たとえば自由に書ける相談の欄でも、文字の長さの上限は決められます。

出典：Input Validation Cheat Sheet｜OWASP

AI への書き方の例

入力のチェックは、ブラウザ側だけでなく、サーバー側でも同じ内容を必ず行ってください。
各項目の「受け付ける形」と「文字数の上限」を表にしてから作ってください。

2. 通知メール・自動返信メールの宛先と件名に、入力をそのまま入れない

お問い合わせフォームは、送られた内容を お店や会社のメールに送る ことが多いです。ここに穴があると、フォームが 迷惑メールを送る道具 に使われてしまいます。IPA はこの穴を「メールヘッダ・インジェクション」と呼び、注意が必要な機能として「問い合わせページ」を名指ししています。

IPA が「根本的な解決」として挙げているのは、次のやり方です。

メールヘッダを固定値にして、外部からの入力はすべてメール本文に出力する。

「メールヘッダ」は、宛先（To）・CC・件名など、メールの本文より前にある部分のことです。件名に「お名前」を入れたいなど、どうしても入力を使うときは、言語やサーバーに用意されているメール送信の仕組みを使い、改行を受け付けないようにする、とされています。

さらに IPA は、送り先のメールアドレスを、画面の見えない欄（hidden）に書いておく作り を「論外」の例として挙げています。送る人がその欄を書き換えれば、好きな宛先にメールを送れてしまうからです。

出典：安全なウェブサイトの作り方 - 1.8 メールヘッダ・インジェクション｜IPA

自動返信メール（「お問い合わせを受け付けました」という、送った人に届くメール）は、入力されたメールアドレスに送るものです。だからこそ、宛先以外の部分に入力が混ざらないようにしておくことが大切です。

AI への書き方の例

メールの宛先・CC・BCC・差出人・件名は、プログラムの中で決めた値にしてください。
送り先のアドレスを、画面の hidden の欄など、送る人が書き換えられる所に置かないでください。
入力された内容はメールの本文にだけ入れ、件名に入力を使う場合は改行を受け付けない処理を入れてください。

3. 確認画面・管理画面に出すときは、入力を無害な文字に置き換える

入力した内容を確かめる「確認画面」や、届いたお問い合わせを一覧で見る「管理画面」では、送られた文字をそのまま画面に出す と、そこに仕込まれたプログラムが動いてしまうことがあります。IPA はこれを「クロスサイト・スクリプティング」と呼び、この穴が生じやすい画面の例として「入力内容を確認させる表示画面」を挙げています。

IPA の「根本的な解決」は、こうです。

ウェブページに出力する全ての要素に対して、エスケープ処理を施す。

「エスケープ処理」とは、< や > のように画面の作りに使われる記号を、ただの文字として表示されるものに置き換えることです。IPA は、入力された文字だけでなく、データベースから読み込んだ文字にもこの処理が要る としています。届いたお問い合わせを管理画面で表示するのも、ここに入ります。

出典：安全なウェブサイトの作り方 - 1.5 クロスサイト・スクリプティング｜IPA

AI への書き方の例

確認画面・完了画面・管理画面・通知メールのHTML版など、入力を表示するすべての場所で、
表示する前にエスケープ処理をしてください。データベースから読み込んだ値も同じです。
使っているフレームワークの自動エスケープを外す書き方（生のHTMLを出す書き方）は使わないでください。

4. データベースに入れるときは、プレースホルダで

お問い合わせを データベースに保存する 作りにするなら、保存の命令の組み立て方にも決まりがあります。入力をそのまま命令文につなげると、データベースの中身を抜き出されることがあります（IPA は「SQLインジェクション」と呼んでいます）。

SQL文の組み立ては全てプレースホルダで実装する。

「プレースホルダ」は、命令文の中に「ここに値が入る」という印だけを置き、値はあとから機械的にはめ込むやり方です。IPA は、データベースにつなぐときの権限を 必要な分だけ にすることもすすめています。

出典：安全なウェブサイトの作り方 - 1.1 SQLインジェクション｜IPA

AI への書き方の例

データベースへの保存・検索は、すべてプレースホルダ（パラメータを分けて渡す方式）で書いてください。
入力を文字列としてつないでSQLを作る書き方はしないでください。

5. ロボット対策は「サーバーで答え合わせ」まで

フォームに迷惑な書き込みが大量に来るのを防ぐために、Google の reCAPTCHA や Cloudflare の Turnstile を入れることがあります。ここでよくある抜けは、画面に「私はロボットではありません」の枠を出すだけで、サーバーで答え合わせをしていない ことです。

Cloudflare は Turnstile の説明で、はっきりこう書いています。

The client-side widget alone does not protect your forms.

（訳：画面に出る部品だけでは、フォームは守られない）

サーバーから確認の窓口（Siteverify）を呼んで、送られてきた「合格の印」が本物かを確かめる必要があります。Google の reCAPTCHA も同じで、受け取った印は 2分以内に、秘密の鍵を付けて reCAPTCHA の窓口に確かめる 作りになっています。

出典：Server-side validation｜Cloudflare Turnstile／Verifying the user's response｜Google reCAPTCHA

あわせて、同じところから短い時間に何回も送れないようにする（回数の上限） も入れておくと安心です。reCAPTCHA の設定のしかたは、カツプロの reCAPTCHAの設定方法【2026年版】 にまとめています。

AI への書き方の例

reCAPTCHA（または Turnstile）は、画面に出すだけでなく、サーバー側で検証APIを呼んで結果を確かめ、
合格しなかったときは送信を受け付けないでください。秘密鍵は画面側のコードに入れないでください。
同じIPアドレスからの送信には、回数の上限を付けてください。

6. 受け取った内容の置き場所と、記録の残し方

お問い合わせの中身は、個人の情報そのものです。会社には、扱う個人の情報が漏れないように 必要で適切な守りをする義務 があります（個人情報保護法 第23条「安全管理措置」）。

出典：個人情報の保護に関する法律についてのガイドライン（通則編）3-4-2 安全管理措置｜個人情報保護委員会

AI に作らせると、送られた内容を ファイルに書き出して、公開しているフォルダの中に置いてしまう ことがあります。そこはURLを知っていれば誰でも開ける場所です。また、動きを確かめるための記録（ログ）に、送られた中身を丸ごと残す作りになることもあります。

OWASP の「記録の残し方」の手引きは、記録にそのまま残さず、消す・隠す・暗号にするなどすべきものとして、パスワード、アクセスのための鍵（トークン）、取り扱いに注意が必要な個人の情報などを挙げています。

出典：Logging Cheat Sheet｜OWASP

AI への書き方の例

受け取った内容をファイルに保存する場合は、公開フォルダ（ブラウザから開ける場所）の外に置いてください。
動作の記録（ログ）には、氏名・メールアドレス・電話番号・本文を残さないでください。
保存するデータと、保存しないデータを先に一覧にしてください。

7. メールのパスワードや鍵を、プログラムの中に書かない

フォームからメールを送るには、メールサーバーのパスワードが要ります。reCAPTCHA などにも秘密の鍵があります。AI は、動かすことを優先して、これらを プログラムの中にそのまま書いてしまう ことがあります。

OWASP の「秘密の管理」の手引きは、多くの組織が、APIの鍵やデータベースのパスワードなどを プログラムの中に平文のまま書いている ことを、問題として挙げています。プログラムを共有したり公開したりしたときに、一緒に漏れるからです。Cloudflare も、Turnstile の秘密の鍵を画面側のコードに入れると、確認をすり抜けられてしまうと説明しています。

出典：Secrets Management Cheat Sheet｜OWASP／Server-side validation｜Cloudflare Turnstile

AI への書き方の例

メールサーバーのパスワード・reCAPTCHAの秘密鍵などは、プログラムに直接書かず、
.env など公開されない設定ファイルから読み込む形にしてください。その設定ファイルは公開フォルダの外に置き、
Git などに上げない設定もしてください。

8. エラーの中身を画面に出さない

作っている途中は、エラーが起きると詳しい中身が画面に出る設定になっていることがあります。そのまま公開すると、使っているデータベースの種類や、命令文がそのまま見えてしまいます。IPA は、データベースに関わるエラーメッセージは 利用者のブラウザに表示させない ことをすすめています。

出典：安全なウェブサイトの作り方 - 1.1 SQLインジェクション｜IPA

AI への書き方の例

本番では、エラーの詳しい内容を画面に出さず、「送信できませんでした」のような短い案内だけにしてください。
詳しい内容はサーバーの記録にだけ残し、そのとき個人の情報は記録しないでください。
開発用の表示設定（デバッグ表示）は、本番では必ず切る形にしてください。

9. 送信ボタンの前に、利用目的を見せる

これは守りの作りというより、決まりの話です。フォームのように、本人が画面に打ち込んだ個人の情報を受け取るときは、あらかじめ本人に利用目的をはっきり示す ことになっています（個人情報保護法 第21条第2項）。個人情報保護委員会のガイドラインは、例として「自社のホームページの入力画面に入力した個人情報」を挙げています。

さらにガイドラインは、送信ボタンを押す前に利用目的が 本人の目に留まるよう、配置に気を付けることが望ましいとしています。利用目的の書かれた画面へ、1回ほどの操作で移れるリンクやボタンでもかまいません。

出典：個人情報の保護に関する法律についてのガイドライン（通則編）3-3-4 直接書面等による取得｜個人情報保護委員会

AI への書き方の例

送信ボタンの近く（押す前に目に入る位置）に、「入力いただいた情報は、お問い合わせへの回答のために使います」
のような利用目的の文と、プライバシーポリシーへのリンクを置いてください。

AI への頼み方のコツ

基準の名前まで書く

「安全に作って」とだけ書くと、AI は思いついた範囲しか見てくれないことがあります。「IPA の『安全なウェブサイトの作り方』に沿って」のように、基準の名前まで書く と、確かめる範囲がはっきりします。カツプロ自身の会員サイトで、基準の名前と項目の数まで決めて頼み直したら、見落としが大きく減った話を 「セキュリティ対策して」とAIに頼むだけでは、穴だらけだった話 に書いています。

「できました」を、そのまま信じない

AI が「対策しました」と言っても、本当に入っているかは別です。どの項目を、どのファイルのどこで満たしたかを一覧で出してもらい、人が確かめる ようにします。

AI でプログラムを書く道具の一つ、Claude Code を出している Anthropic も、公式の説明で次のように書いています。

You’re responsible for reviewing proposed code and commands for safety before approval.

（訳：提案されたプログラムや命令が安全かどうかを、許可する前に確かめるのは、使う人の責任です）

出典：Security｜Claude Code Docs

試すときは、自分のテスト用の環境で

「本当に穴がないか」を確かめるために、公開中のサイトにわざと変な文字を送ったりはしないでください。確かめは、自分で用意したテスト用の環境で行います。外から見える設定（通信の暗号化や、ブラウザへの守りの指示など）は、カツプロの セキュリティ診断 でも確かめられます。ただしこの診断は、フォームのサーバー側の作りは見ていません。上の9つは、作るときの指示と、作ったあとの確かめで押さえてください。

そのまま使える指示文

最後に、上の9つをまとめた指示文です。使っている言語やフレームワーク（PHP・Laravel・WordPress など）を最初の行に足して使ってください。

お問い合わせフォームを作ってください。IPA「安全なウェブサイトの作り方」と OWASP の手引きに沿って、次を必ず守ってください。

1. 入力のチェックは、ブラウザ側だけでなくサーバー側でも必ず行う。各項目の受け付ける形と文字数の上限を、作る前に表にする
2. メールの宛先・CC・BCC・差出人・件名はプログラムで決めた値にする。送り先のアドレスを hidden の欄など送る人が書き換えられる所に置かない。入力はメール本文にだけ入れ、件名に使うなら改行を受け付けない
3. 確認画面・完了画面・管理画面など、入力やデータベースの値を表示するすべての場所でエスケープ処理をする。自動エスケープを外す書き方は使わない
4. データベースへの保存・検索は、すべてプレースホルダで書く
5. reCAPTCHA（または Turnstile）は、サーバー側で検証APIを呼んで確かめる。秘密鍵は画面側に置かない。同じIPアドレスからの送信に回数の上限を付ける
6. 受け取った内容を保存するなら公開フォルダの外に置く。ログに氏名・メールアドレス・電話番号・本文を残さない
7. パスワードや秘密鍵はプログラムに直接書かず、公開されない設定ファイルから読む。その設定ファイルは Git に上げない
8. 本番ではエラーの詳しい内容を画面に出さない。デバッグ表示は本番で切る
9. 送信ボタンの前に、利用目的の文とプライバシーポリシーへのリンクを置く

作り終わったら、1〜9のそれぞれについて「どのファイルのどこで、どう満たしたか」を一覧にしてください。満たせなかった項目があれば、満たせなかったと書いてください。

まとめ

• お問い合わせフォームは、個人の情報が集まる入口 です。見た目がちゃんと動いていても、守りが入っているとは限りません
• AI に作らせるときは、守ってほしいことを指示に書く のがいちばん確実です。特に「サーバーでも確かめる」「メールの宛先と件名を固定する」「表示する前に無害な文字に置き換える」の3つは、フォームならではの抜けやすい所です
• 作ったあとは、どの項目をどう満たしたかを一覧で出させて、人が確かめる。基準の名前まで書いて頼むと、見落としが減ります

ログインのある会員サイトや管理画面を作るときに、場面ごとに指示へ書くことは 会員サイト・管理画面をAIに作らせるとき、場面ごとに指示へ書くこと にまとめています。