会員サイト・管理画面をAIに作らせるとき、場面ごとに指示へ書くこと｜不正アクセスを防ぐ

会員サイト、予約の仕組み、社内の管理システム。ログインがあって、人の情報を預かるシステムを、AI（Claude・ChatGPT・Gemini など）に作ってもらうことが増えました。画面も動きも、それらしいものがすぐにできます。

ただ、不正アクセスや情報の漏えいにつながる穴の多くは、画面を見ているだけでは気づけない所 にあります。たとえば「ほかの人の番号を入れたら、その人の情報が見えてしまう」という穴は、自分のアカウントでふつうに使っている限り、まず気づきません。

この記事では、ログインのあるシステムを AI に作らせるときに、場面ごとに、指示の中に何を書いておけばいいか を、IPA（情報処理推進機構）や OWASP（ウェブの安全を研究する国際的な団体）の公式の資料をもとにまとめました。お問い合わせフォームについては お問い合わせフォームをAIに作らせるとき、指示に入れたい9つのこと に分けて書いています。

まず：最近の不正アクセス・情報漏えいは、何が原因で多いのか

対策を考える前に、国や公的機関がまとめている資料から、いま何が原因で被害が多いのかを見ておきます。

他人の ID・パスワードを使って入られる

警察庁・総務省・経済産業省が毎年まとめている「不正アクセス行為の発生状況」によると、2025年（令和7年）に警察が把握した不正アクセス行為は 7,190件 で、前の年より約34.2％増えました。

検挙された不正アクセス行為を手口で分けると、他人の ID・パスワードを使って入る型（識別符号窃用型）が399件で、全体の90％以上 を占めています。その ID・パスワードをどうやって手に入れたかでは、「パスワードの設定・管理の甘さにつけ込んで入手」が84件でいちばん多く、次が「フィッシングサイトから入手」の77件でした。

さらに、他人の ID・パスワードで不正に使われたサービスでは、「社員・会員用等の専用サイト」が122件でいちばん多く なっています。まさに、この記事で扱う会員サイトや社内の管理システムです。

出典：不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況（令和8年3月12日）｜警察庁・総務省・経済産業省（PDF）

直していない穴や、外とつなぐ機械から入られる

警察庁の「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」は、ランサムウェア（データを使えなくして身代金を求める攻撃）について、こう書いています。

近年は、インターネットに露出した箇所から攻撃者が遠隔操作でネットワーク内部に侵入する手口が多くを占め、標的型攻撃メール等の添付ファイルによる感染は少なくなっている。

被害にあった組織へのアンケートでは、入られた入口は VPN 機器（社外から社内につなぐための機械）が約5割 でした。攻撃する側は、直していない穴や、漏れた ID・パスワードなどを使って 入り込む、とされています。

出典：令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について｜警察庁（PDF）

頼んでいる会社・使っているサービスから広がる

IPA が毎年まとめている「情報セキュリティ10大脅威 2026」の組織向けの順位は、上位がこうなっています。

2位の「サプライチェーンや委託先」は、仕事を頼んでいる会社や、使っている外のサービス・部品を通じて被害が広がる攻撃のことです。3位に「AIの利用をめぐるサイバーリスク」が初めて入ったことも、AI でシステムを作る人にとっては見逃せません。

出典：情報セキュリティ10大脅威 2026｜IPA

だから、作る段階で入れておく

上の3つの原因は、どれもシステムを作る段階で手を打てるものです。

• 他人の ID・パスワードで入られる → ログインの守り方（1番）と、管理画面の2段階認証（3番）
• 直していない穴から入られる → 部品の古さを調べて更新する（7番）
• 頼んでいる会社・外のサービスから広がる → 外のサービスの鍵の権限を絞る（6番）。「社員・会員用等の専用サイト」が狙われているからこそ、会員ごとのデータの確かめ（2番）も欠かせません

ここからは、それぞれを AI への指示にどう書くかを、場面ごとに説明します。

結論：場面ごとに、指示に入れておきたいこと

そして、作る前に「誰が何をできるか」の表を AI に作らせ、作ったあとは「他人のデータが見えないか」を確かめるテストまで書かせます。

1. ログイン

パスワードは「元に戻せない形」で保存する

AI に会員登録を作らせると、まれにパスワードをそのまま、または元に戻せる形で保存する作りになることがあります。OWASP の「パスワードの保存」の手引きは、こう書いています。

Passwords should never be stored in plain text.

（訳：パスワードは、決してそのままの形で保存してはいけない）

同じ手引きは、パスワードは暗号にするのではなく、Argon2id・bcrypt・PBKDF2 などの、元に戻せない計算（ハッシュ） で守るべきだとしています。

出典：Password Storage Cheat Sheet｜OWASP

メールアドレスだけで入れるようにしない

IPA は、個人の情報を見られる機能に メールアドレスだけでログインできてしまう サイトが、穴のあるサイトとして届け出られた例を挙げています。メールアドレスは他人にも知られうる情報なので、パスワードなどの入力を求めるように作るべき、としています。

出典：安全なウェブサイトの作り方 - 1.11 アクセス制御や認可制御の欠落｜IPA

失敗が続いたら止める

IPA の「ウェブサイトの運用管理に向けての20ヶ条」は、漏れた ID やパスワードを使った不正ログインについて、利用者への呼びかけに加えて 「不正ログインを防止したり検知したりするためのシステム面の対策も有効」 としています。ログインに何回も失敗したら、しばらく受け付けないようにする、といった作りです。

出典：安全なウェブサイトの運用管理に向けての20ヶ条｜IPA

AI への書き方の例

パスワードは、フレームワーク標準のハッシュ（bcrypt または Argon2id）で保存してください。平文や、元に戻せる暗号での保存はしないでください。
ログインには必ずパスワードを求め、メールアドレスだけで本人の情報を見られる画面は作らないでください。
同じアカウント・同じIPアドレスからのログインの失敗が続いたら、一定時間受け付けないようにしてください。

2. 会員ごとのデータ（いちばん気づきにくい穴）

会員ごとに「自分の予約」「自分の注文」「自分のプロフィール」がある作りでは、ほかの人の番号を指定したら、その人のデータが見えてしまう 穴が起きることがあります。IPA は例として、URL などで渡される注文番号をそのまま使って調べる作りだと、ログインしている人なら 他人の注文の情報を見られてしまう ことがある、と説明しています。

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

認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする。

「認可」とは、ログインした人が そのデータを見てよい人か を確かめることです。IPA は、データを調べるときに、ログイン中の人の ID と一致しているかを常に確かめるか、ID を外から受け取らずにログインの情報から取るように作る、としています。

出典：安全なウェブサイトの作り方 - 1.11 アクセス制御や認可制御の欠落｜IPA

OWASP がまとめているウェブの危険の一覧「OWASP Top 10」の2025年版でも、1番目は「Broken Access Control（見てよい人の確かめが壊れている）」です。

出典：OWASP Top 10:2025

OWASP の「認可」の手引きは、確かめは すべての要求で 行うこと、そして決まりに当てはまらない操作は 断る側に倒す（deny by default） ことをすすめています。

出典：Authorization Cheat Sheet｜OWASP

AI への書き方の例

URL やフォームで渡される ID（予約番号・注文番号・会員番号など）でデータを取るときは、
必ずサーバー側で「ログイン中の本人のデータか（または見てよい権限があるか）」を確かめ、違えば 404 か 403 を返してください。
確かめは画面ごとに書くのではなく、全体で漏れなくかかる仕組み（ポリシー・ミドルウェアなど）にしてください。
許可を決めていない操作は、断る側にしてください。

3. 管理画面

管理画面は、すべての会員の情報を見たり変えたりできる場所です。ここに入られると、被害は一気に大きくなります。

OWASP の「多要素認証」の手引きは、はっきりこう書いています。

Require MFA for administrative or other high privileged users.

（訳：管理者など、強い権限を持つ人には、多要素認証を必ず使わせる）

「多要素認証（2段階認証）」は、パスワードのほかに、スマホのアプリに出る数字なども使ってログインする仕組みです。

出典：Multifactor Authentication Cheat Sheet｜OWASP

IPA の20ヶ条も、管理者の権限を持つアカウントは悪用される可能性が高い ので、推測されやすいパスワードになっていないか確かめるよう呼びかけています。

出典：安全なウェブサイトの運用管理に向けての20ヶ条｜IPA

AI への書き方の例

管理画面に入る人には、認証アプリ（TOTP）による2段階認証を必須にしてください（任意ではなく必須）。
管理者のパスワードは、短いもの・よくあるものを受け付けないようにしてください。
管理画面の操作（ログイン・設定の変更・会員データの変更）は記録に残してください。

4. ログインの状態（セッション）

ログインしたあと、システムは「この人はログイン済み」という印（セッションID）を持たせて、ページを移っても本人だと分かるようにしています。この印を盗まれたり、あらかじめ用意された印を使わされたりすると、本人になりすまされます。

IPA は「根本的な解決」として、印を推測しにくくする、URL に入れない、通信の暗号化（HTTPS）で使う Cookie に secure という設定を付ける、ログインに成功したら新しく印を作り直す、などを挙げています。

出典：安全なウェブサイトの作り方 - 1.4 セッション管理の不備｜IPA

こうした作りは、多くのフレームワーク（Laravel など）にもともと入っています。AI が「独自のログインの仕組み」を一から書き始めたら、止めてフレームワークの仕組みを使わせるほうが安全です。

AI への書き方の例

ログインとログインの状態の管理は、フレームワーク標準の仕組みを使い、独自に作らないでください。
ログインに成功したらセッションIDを作り直し、セッションIDを URL に入れないでください。
Cookie には Secure・HttpOnly・SameSite を付けてください。

5. ファイルの受け取り（写真・書類など）

プロフィールの写真や、書類の提出を受け付ける作りでは、危ないファイルを送り込まれる ことがあります。OWASP の「ファイルのアップロード」の手引きは、守るべきこととして次を挙げています（一部）。

• 受け付ける拡張子（ファイルの種類）を決めて、それだけを許す
• ファイル名は、システムが付け直す
• ファイルの大きさに上限を設ける
• アップロードできるのは、許された人だけにする
• 置き場所は、公開フォルダの外（webroot の外）にする

出典：File Upload Cheat Sheet｜OWASP

AI への書き方の例

アップロードは、受け付ける種類を決めた許可リスト（例：jpg・png・pdf）にし、拡張子だけでなく中身でも種類を確かめてください。
ファイル名はシステムで付け直し、大きさの上限を付けてください。
保存は公開フォルダの外にし、表示やダウンロードは、見てよい人かを確かめる処理を通して返してください。

6. 外のサービスの鍵（決済・メール・AI など）

決済やメール送信、AI の呼び出しなど、外のサービスを使うには「鍵」（APIキー）が要ります。AI は動かすことを優先して、何でもできる鍵 をそのまま使う作りにしがちです。

OWASP の「認可」の手引きは、仕事に必要な最小限の権限だけを与える（最小権限） 考え方をすすめています。外のサービスの鍵も同じで、多くのサービスでは「この操作だけできる鍵」を作れます。鍵をプログラムの中に書かないことは、お問い合わせフォームの記事 の7番に書いたとおりです。

出典：Authorization Cheat Sheet｜OWASP

AI への書き方の例

外部サービスの APIキーは、使う操作だけに権限を絞った鍵を前提にしてください。必要な権限の一覧を先に出してください。
鍵はプログラムに書かず、公開されない設定ファイルから読み込んでください。

7. 公開するとき・公開したあと

試しのページ・アカウント・ファイルを残さない

AI と作っていると、動作確認用のページ、試しのアカウント、データの書き出しファイルなどがたくさんできます。IPA の20ヶ条は、次のような点を確かめるよう呼びかけています。

• 設定ファイルや個人情報を入れたファイルを、インターネットから見られる場所に置いていないか
• 不要になったページやサイトを公開したままにしていないか
• 不要なアカウント、特に 開発やテストで使ったアカウント が残っていないか
• エラーの画面に、余計な情報を出していないか

出典：安全なウェブサイトの運用管理に向けての20ヶ条｜IPA

部品の古さを、定期的に調べる

いまのシステムは、たくさんの部品（ライブラリ・フレームワーク）の組み合わせでできています。IPA の20ヶ条は、自分のサイトが どんな部品で作られているかを把握して、穴が見つかったら更新するなどの対策をとる必要がある、としています。OWASP Top 10 の2025年版でも、3番目に「Software Supply Chain Failures（部品のつながりの弱さ）」が入っています。

PHP なら composer audit、JavaScript なら npm audit という命令で、使っている部品に知られた穴がないかを調べられます。

出典：安全なウェブサイトの運用管理に向けての20ヶ条｜IPA／OWASP Top 10:2025／Command-line interface（audit）｜Composer／npm-audit｜npm Docs

外の人に診てもらう

IPA の20ヶ条は、内部で対策を確かめたうえで、外部の組織による検査（診断） を受けることが、対策の漏れを洗い出すのに効果的としています。個人の情報を預かるシステムなら、公開の前に一度は検討する価値があります。

出典：安全なウェブサイトの運用管理に向けての20ヶ条｜IPA

AI への書き方の例

公開の前に、動作確認用のページ・試しのアカウント・書き出したファイル・使っていないプログラムを一覧にして、消してください。
使っている部品の一覧を出し、composer audit（または npm audit）の結果を見せてください。

AI への頼み方のコツ

作る前に「誰が何をできるか」の表を作らせる

いちばん効くのは、作り始める前に、役割（会員・スタッフ・管理者など）ごとに、できること・見られるデータを表にしてもらう ことです。表があれば、2の「他人のデータが見える」穴を、表と見比べて確かめられます。

「他人のデータが見えないか」のテストまで書かせる

AI に「テストも書いて」と頼むと、ふつうは「正しく動くか」のテストになります。「別の会員の番号を指定したら見えないこと」「ログインしていなければ入れないこと」のような、断る側のテスト も、はっきり頼みます。

基準の名前まで書き、できたかを一覧で出させる

「安全に作って」だけでは、AI は思いついた範囲しか見ないことがあります。基準の名前まで書いて頼み直したら見落としが大きく減った話は、「セキュリティ対策して」とAIに頼むだけでは、穴だらけだった話 に書いています。そして、最後は人が確かめます。Claude Code を出している Anthropic も、提案されたプログラムが安全かを許可の前に確かめるのは使う人の責任だ、と公式の説明に書いています。

出典：Security｜Claude Code Docs

そのまま使える指示文

上の7つの場面をまとめた指示文です。最初の行に、作るもの（会員サイト・予約システムなど）と、使う言語・フレームワークを足して使ってください。

ログインのあるシステムを作ります。IPA「安全なウェブサイトの作り方」と OWASP の手引きに沿って、次を必ず守ってください。

0. 作り始める前に、役割ごとに「できること・見られるデータ」の表を作り、私に確認してください
1. ログイン：パスワードはフレームワーク標準のハッシュ（bcrypt または Argon2id）で保存する。メールアドレスだけで本人の情報を見られる画面は作らない。ログインの失敗が続いたら一定時間止める
2. 会員ごとのデータ：ID でデータを取るときは、必ずサーバー側で本人のデータか（見てよい権限か）を確かめ、違えば 404 か 403 を返す。確かめは全体にかかる仕組みにし、許可を決めていない操作は断る
3. 管理画面：管理者は認証アプリ（TOTP）の2段階認証を必須にする。短い・よくあるパスワードを受け付けない。管理画面の操作を記録に残す
4. ログインの状態：フレームワーク標準の仕組みを使い、独自に作らない。ログイン成功でセッションIDを作り直す。セッションIDを URL に入れない。Cookie に Secure・HttpOnly・SameSite を付ける
5. ファイル：受け付ける種類の許可リスト・中身での種類の確認・名前の付け直し・大きさの上限。保存は公開フォルダの外、返すときは見てよい人かを確かめる
6. 外部サービスの鍵：権限を絞った鍵を前提にし、必要な権限の一覧を出す。鍵はプログラムに書かず、公開されない設定ファイルから読む
7. 公開の前：動作確認用のページ・試しのアカウント・書き出したファイル・使っていないプログラムを消す。部品の一覧と composer audit（または npm audit）の結果を出す。本番ではエラーの詳しい内容を出さない

テストには、正しく動くことに加えて「別の会員の ID では見えない」「ログインしていなければ入れない」「権限のない役割では操作できない」を必ず入れてください。
作り終わったら、0〜7のそれぞれについて「どのファイルのどこで、どう満たしたか」を一覧にし、満たせなかった項目はそのまま書いてください。

まとめ

• ログインのあるシステムの穴は、画面を見ているだけでは気づけない所 に多くあります。特に「他人のデータが見えてしまう」穴は、OWASP Top 10 の2025年版で1番目に挙がっている種類です
• AI に作らせるときは、場面ごとに守ってほしいことを指示に書き、作る前に「誰が何をできるか」の表を作らせます
• 作ったあとは、断る側のテスト と「どの項目をどう満たしたか」の一覧で確かめます。個人の情報を預かるなら、公開の前に外の診断も検討します