AIの時代は、セキュリティの時代でもある

1. AIを組み込むほど、ユーザー入力の扱いは慎重になる AIをアプリケーションに組み込みやすくなるほど、セキュリティに対する考え方はますます重要になります。 これまでのWebアプリケーションでも、ユーザー入力を安全に扱うことは非常に重要でした。フォーム、検索ボックス、コメント欄、問い合わせページ、ログイン画面、管理画面など、ユーザーが入力できる場所には常にリスクがあります。 しかし、AIを組み込んだアプリケーションでは、このリスクがさらに広がります。 なぜなら、AIアプリケーションでは、ユーザー入力が単なる文字列として保存・表示されるだけではなく、AIモデルへのプロンプト、外部APIへのリクエスト、データベース検索、メール生成、要約処理、レコメンド処理などに使われることがあるからです。 つまり、ユーザーが入力した内容が、アプリケーション内部のさまざまな処理に影響を与える可能性があります。 たとえば、問い合わせフォームに入力された文章をAIで分類する。 レビュー内容をAIで要約する。 ユーザーの事業情報をもとに改善提案を生成する。 チャット形式でAIに質問できるようにする。 アップロードされた文章をAIで分析する。 こうした機能は非常に便利です。しかし同時に、ユーザー入力をどこまで信用してよいのか、どの段階で検証するのか、どの情報をAIに渡してよいのかを慎重に考える必要があります。 ここで重要になるのが、バリデーションです。 バリデーションは、単に「入力欄が空ではないか」を確認するだけのものではありません。文字数制限、形式チェック、想定外の文字列の排除、不正なHTMLやスクリプトの混入防止、送信頻度の制御、必要以上に長い入力の拒否など、アプリケーションを守るための最初の防衛線になります。 特にAI機能では、長すぎる入力や意図的に細工された入力が、コスト増加、処理遅延、意図しない出力、プロンプトインジェクションのような問題につながる可能性があります。 そのため、AIを使う場合でも、まずは通常のWebセキュリティと同じように、入力値を信用しないことが基本になります。 ユーザーが入力したものを、そのまま使わない。 必要な形式に整える。 危険な値は弾く。 サーバー側でも必ず検証する。 AIに渡す前に、渡してよい情報か確認する。 こうした基本を丁寧に積み重ねることが、AI時代のアプリケーション開発ではより重要になります。 AIは、強力な機能を比較的簡単に追加できる一方で、入力された情報をどう解釈し、どう処理するかが複雑になりやすい技術でもあります。だからこそ、AIを組み込むほど、入力値の扱い、検証、制限、ログ、エラー時の挙動を設計段階から考える必要があります。 セキュリティは、完成後に少し追加するチェック項目ではありません。 ユーザー入力を受け取る時点から始まる、アプリケーション設計そのものです。

2. XSS、CSRF、レート制限、APIキー管理はプロダクト設計の一部 セキュリティ対策というと、後から追加する細かな実装のように見えることがあります。 しかし、実際にはそうではありません。バリデーション、XSS対策、CSRF対策、レート制限、APIキー管理、認証、権限管理、ログ管理、プライバシー保護は、アプリケーションの土台に関わる重要な設計要素です。 特にWebアプリケーションでは、XSS対策が非常に重要になります。 XSSは、ユーザーが入力したスクリプトや危険なHTMLが、別のユーザーのブラウザ上で実行されてしまう問題です。たとえば、ブログのコメント欄、プロフィール欄、問い合わせ内容、Markdown表示、リッチテキストエディタなどで、入力内容をそのままHTMLとして表示してしまうと危険です。 Reactは標準では文字列をエスケープしてくれるため、比較的安全に扱いやすい仕組みになっています。しかし、dangerouslySetInnerHTML のようにHTMLを直接挿入する処理や、外部から取得したコンテンツをレンダリングする場合には注意が必要です。 ブログやポートフォリオのようなサイトでも、記事本文、画像URL、外部リンク、埋め込みコンテンツ、問い合わせフォームなど、入力や外部データを扱う場面はあります。そのため、「個人サイトだから大丈夫」と考えるのではなく、公開されるWebアプリケーションとして最低限の防御を入れることが大切です。 CSRF対策も重要です。 CSRFは、ユーザーがログインしている状態を悪用して、意図しないリクエストを送信させる攻撃です。特に、投稿、更新、削除、メール送信、設定変更など、状態を変更する処理では注意が必要になります。 最近のフレームワークや認証サービスでは、CSRF対策がある程度組み込まれている場合もあります。しかし、それに頼りきるのではなく、自分のアプリケーションでどの処理が状態変更を伴うのか、どのエンドポイントが外部から叩かれる可能性があるのかを把握しておく必要があります。 また、AIアプリケーションではレート制限も重要になります。 AI APIは便利ですが、呼び出しにはコストがかかります。もし制限なしでAPIを呼び出せる状態にしてしまうと、悪意ある連続リクエストやボットによって、短時間で大量のAPIコールが発生する可能性があります。 これは単なるセキュリティの問題だけではありません。コスト、可用性、ユーザー体験にも直結します。 たとえば、問い合わせフォームにAI分類を入れる。 ユーザー入力からAIで提案文を生成する。 チャット機能を提供する。 こうした機能では、1ユーザーあたりのリクエスト回数、IP単位の制限、認証済みユーザーかどうか、入力文字数、失敗回数などを考慮する必要があります。 APIキー管理も非常に重要です。 OpenAI API、Supabase、Resend、Stripe、Cloudflareなどの外部サービスを使う場合、APIキーやシークレットキーの扱いを間違えると大きなリスクになります。 クライアント側に秘密鍵を埋め込まない。 .env で管理する。 GitHubに誤ってコミットしない。 公開してよいキーと、サーバー側だけで扱うべきキーを区別する。 必要最小限の権限だけを持たせる。 漏洩した場合はすぐにローテーションできるようにする。 こうした管理は、アプリケーションの規模に関係なく必要です。 特にNext.jsのように、クライアント側とサーバー側のコードが同じプロジェクト内に存在する場合、環境変数の扱いには注意が必要です。NEXT_PUBLIC_ が付いた環境変数はブラウザ側に公開されるため、秘密情報を入れてはいけません。 サーバー側だけで扱うべきキーは、Server Actions、Route Handlers、server-only なモジュールなどに閉じ込める必要があります。 セキュリティは、単体の機能ではありません。 フォームを作るなら、バリデーションが必要です。 データを表示するなら、XSS対策が必要です。 状態を変更するなら、CSRF対策や認証・権限管理を考える必要があります。 外部APIを使うなら、APIキー管理が必要です。 AIを使うなら、レート制限、入力制御、プライバシー設計が必要です。 つまり、セキュリティはプロダクトの周辺にあるものではなく、プロダクト設計の中心にあるものです。

3. アプリケーションが強力になるほど、安全なアーキテクチャが重要になる アプリケーションが強力になればなるほど、扱う情報も増えていきます。 ユーザー入力。 外部API。 個人データ。 問い合わせ内容。 メールアドレス。 ログ。 画像。 データベース。 AIに渡すプロンプト。 AIから返ってくる生成結果。 こうした情報を扱う場合、単に「機能が動くこと」だけを目指すのではなく、障害が起きた場合や悪用された場合のことまで考える必要があります。 特にAIを組み込んだアプリケーションでは、入力、処理、出力の境界が曖昧になりやすいです。 ユーザーが入力した情報をAIに渡す。 AIが文章を生成する。 生成された文章を画面に表示する。 場合によっては、メール文面や提案内容として利用する。 外部サービスの情報を取得して、AIに渡す。 データベースの情報を参照して、AIの出力に反映する。 このような流れでは、どこでデータを検証するのか、どこまでAIに渡すのか、AIの出力をそのまま信用してよいのかを設計する必要があります。 AIの出力は便利ですが、常に正しいとは限りません。誤った情報を含むこともあります。過度に断定的な文章になることもあります。ユーザーに見せるべきではない内容が含まれる可能性もあります。 そのため、AIの出力もまた、検証や整形の対象として扱うべきです。 特に、AIが生成した文章をそのままメール送信するような設計には慎重になる必要があります。 人間が確認するフローを入れる。 送信前に編集できるようにする。 生成内容をログとして残す。 禁止ワードや危険な表現をチェックする。 送信先や対象データを明確にする。 このような安全設計が重要になります。 また、プライバシーの観点も欠かせません。 AIに渡す情報には、ユーザーの個人情報や機密性の高い内容が含まれる可能性があります。そのため、必要以上の情報をAIに送らないことが大切です。 たとえば、ユーザーの名前、メールアドレス、住所、問い合わせ内容、業務情報、顧客情報などを扱う場合、本当にその情報をAIに渡す必要があるのかを考える必要があります。 必要な情報だけを渡す。 個人情報をマスキングする。 ログに残す情報を制限する。 外部APIに送信するデータを最小化する。 保存期間を考える。 削除できる設計にする。 こうした考え方は、AIアプリケーションでは特に重要です。 安全なアーキテクチャとは、単にセキュリティライブラリを入れることではありません。データの流れを理解し、信頼できない入力を前提にし、権限を最小化し、障害時にも被害が広がらないように設計することです。 たとえば、公開サイトから直接データベースへ自由な書き込みを許可しない。 サーバー側で必要なチェックを行う。 公開してよいデータだけを取得する。 管理用の処理は一般ユーザーから切り離す。 APIキーはサーバー側に閉じ込める。 外部サービスとの連携は必要最小限にする。 異常なリクエストには制限をかける。 こうした設計が、アプリケーション全体の安全性を支えます。 今回のポートフォリオ制作でも、セキュリティは重要なテーマでした。 ブログコンテンツはSupabaseで管理し、公開サイトからは published の記事だけを読み取る。 一般ユーザーには書き込み権限を与えない。 問い合わせフォームでは入力値を検証する。 メール送信処理はサーバー側で行う。 APIキーはクライアントに露出させない。 将来的にAI機能を組み込む場合でも、自動送信ではなく、人間が確認する設計を前提にする。 このように、機能を作る段階から安全性を考えておくことで、後から無理にセキュリティを継ぎ足す必要が少なくなります。 AI時代のアプリケーションは、これまで以上に強力になります。 文章を生成できる。 情報を要約できる。 外部データを分析できる。 ユーザーごとに提案を作れる。 業務の一部を自動化できる。 しかし、アプリケーションが強力になるほど、設計者の責任も大きくなります。 何を自動化するのか。 どこで人間の確認を入れるのか。 どのデータを扱うのか。 どの情報を保存するのか。 どの処理をサーバー側に置くのか。 どこに制限をかけるのか。 これらを考えることが、AI時代のセキュリティ設計だと思います。 セキュリティは、開発の最後にチェックリストとして確認するものではありません。アプリケーションの設計、データの流れ、ユーザー体験、運用、外部サービス連携のすべてに関わるものです。 AIをアプリケーションに組み込む時代だからこそ、セキュリティはより重要になります。 強力な機能を安全に提供するためには、バリデーション、XSS対策、CSRF対策、レート制限、APIキー管理、プライバシー保護、そして安全なアーキテクチャを、最初からプロダクト設計の一部として考える必要があります。