AIで作ったアプリのセキュリティは大丈夫？脆弱性・APIキー・認証を無料診断【2026年版】

ChatGPT、Claude、Cursorなどの生成AIを活用すれば、専門的なプログラミング知識が少なくても、Webアプリや業務システムを短期間で開発できるようになりました。

しかし、AIが生成したコードが正常に動いたとしても、安全性まで保証されているわけではありません。

AIで生成したソースコードにも、通常のソフトウェアと同じセキュリティチェックが必要です。

生成AIは開発を高速化できる一方で、認証・認可、入力値検証、APIキー管理、データベースアクセス、依存ライブラリなどに脆弱性が含まれる可能性があります。

実際に、Webアプリケーションの代表的なセキュリティリスクをまとめた「OWASP Top 10:2025」でも、アクセス制御の不備、設定ミス、ソフトウェアサプライチェーン、暗号化、インジェクション、認証などが重要なリスクとして挙げられています。

そのため、AIで開発したアプリも、本番公開前にソースコード、認証、データベース、API、クラウド環境、AI機能を含めたセキュリティ診断を行うことが重要です。

この記事では、AIで作ったアプリを公開する前に確認したい脆弱性や、具体的なセキュリティチェック項目について解説します。

AIで開発したソースコードにセキュリティチェックが必要な理由

AIでコードを生成すると、短時間でログイン機能やデータベース連携、決済機能などを実装できます。

しかし、生成されたコードは、入力した指示や参照した情報によって品質が変わります。見た目や動作に問題がなくても、外部から攻撃された場合の安全性まで考慮されているとは限りません。

AIが生成したコード＝安全なコードではない

生成AIは、学習したコードや一般的な開発パターンをもとに、確率的にコードを生成します。

そのため、次のような問題が含まれる可能性があります。

• 古い実装方法を使用している
• セキュリティ設定が不足している
• 例外処理が不十分
• 認証はあるが認可が実装されていない
• 入力値をそのままデータベースへ送信している
• APIキーや秘密情報をコードへ直接記述している
• 安全性が確認されていないライブラリを使用している

AIはコードの作成を支援できますが、そのコードが安全であることを自動的に保証するものではありません。

動作することと安全であることは別問題

アプリが正常に起動し、ログインやデータ登録ができると、「完成した」と判断してしまいがちです。

しかし、正常な操作ができることと、不正な操作を防げることは別の問題です。

例えば、通常の画面操作では問題がなくても、URL内のユーザーIDを書き換えることで他人の情報を表示できてしまう場合があります。

また、画面には表示されていない管理者用APIを、一般ユーザーが直接実行できる可能性もあります。

セキュリティ診断では、「正しく動くか」だけでなく、「想定外の操作や攻撃を受けても安全か」を確認します。

AI開発では脆弱性を見落としたまま本番公開するリスクがある

AIを活用した開発では、コードの作成速度が上がるため、設計やセキュリティ確認が追いつかないまま公開されることがあります。

特に注意が必要なのは、次のようなアプリです。

• 顧客情報や個人情報を保存する
• ログイン機能がある
• 決済機能がある
• ファイルをアップロードできる
• 管理画面がある
• 外部APIと連携している
• AIがメール送信やデータ更新を実行する
• 社内情報をRAGで検索できる

問題を見落としたまま公開すると、情報漏洩、不正利用、API料金の高額請求、データ改ざん、アカウント乗っ取りなどにつながる可能性があります。

Claude・ChatGPT・Cursorなどで開発する際に注意すべきこと

Claude、ChatGPT、Cursorなどでコードを作成する際は、生成された内容をそのまま本番環境へ反映しないことが重要です。

AIに修正を繰り返し依頼していると、似た処理が複数の場所に作成されたり、一部だけ古いコードが残ったりすることがあります。

また、エラー解決のために権限を広げすぎたり、一時的に無効化したセキュリティ設定を戻し忘れたりするケースにも注意が必要です。

AIが提案したコードは「完成品」ではなく、レビューとテストが必要な開発成果物として扱いましょう。

AI生成コードでチェックすべきセキュリティ項目

AIで作ったWebアプリでは、ソースコードだけでなく、認証、データベース、API、インフラまで確認する必要があります。

APIキー・パスワード・秘密情報がソースコードに含まれていないか

OpenAI、Anthropic、Stripe、AWSなどのAPIキーや、データベースのパスワードがコード内に直接記述されていないか確認します。

ブラウザへ配信されるJavaScriptに秘密情報が含まれている場合、利用者からキーを確認される可能性があります。

秘密情報は環境変数やシークレット管理サービスで管理し、クライアント側から直接利用できない構成にする必要があります。

ログイン・認証機能に脆弱性がないか

ログイン機能では、パスワードの保存方法、セッション管理、ログアウト処理、パスワード再設定、試行回数制限などを確認します。

パスワードは平文で保存せず、適切な方式でハッシュ化する必要があります。

管理画面や重要機能では、多要素認証の導入も検討します。

ユーザーごとのアクセス権限が正しく設定されているか

ログイン済みであっても、すべてのデータへアクセスさせてよいわけではありません。

利用者、管理者、店舗担当者、企業管理者などの役割に応じて、閲覧・登録・変更・削除できる範囲を制限します。

OWASP Top 10:2025では、アクセス制御の不備が最重要リスクとして挙げられています。

権限チェックは画面表示だけでなく、サーバー側のすべてのAPIで実施する必要があります。

SQLインジェクション対策がされているか

入力された文字列をそのままSQLへ組み込むと、データベースを不正に操作される可能性があります。

対策として、プレースホルダーやパラメータ化クエリ、適切なORMを使用します。

データベースへ接続するアカウントの権限も、必要最小限に制限することが重要です。

XSS（クロスサイトスクリプティング）対策がされているか

ユーザーが入力した文章を適切に処理せず画面へ表示すると、不正なスクリプトを実行される可能性があります。

入力内容を出力する際は、表示先に応じたエスケープ処理を行います。

HTMLを投稿できる機能がある場合は、許可するタグや属性を制限し、安全なサニタイズ処理を実装します。

CSRF対策がされているか

ログイン中の利用者を不正なリンクやページへ誘導し、本人の意図しない操作を実行させる攻撃がCSRFです。

データ変更や決済、退会、メールアドレス変更などの重要な処理では、CSRFトークンやCookieの適切な属性設定などを確認します。

入力値の検証・サニタイズが適切か

入力フォーム、URLパラメータ、HTTPヘッダー、APIリクエストなど、外部から受け取る情報は信用せずに検証します。

確認する項目には、次のようなものがあります。

• データ型
• 文字数
• 数値の範囲
• 日付形式
• メールアドレス形式
• 許可された選択肢
• 使用可能な文字
• ファイル形式
• リクエストサイズ

画面側のチェックだけでは回避される可能性があるため、サーバー側でも必ず検証します。

ファイルアップロード機能に問題がないか

画像やPDFなどのアップロード機能は、不正なファイルを保存・実行されるリスクがあります。

拡張子だけで判断せず、MIMEタイプ、実際のファイル内容、容量、保存先、ファイル名などを確認します。

アップロードされたファイルは、実行可能な場所へ保存しないことも重要です。

個人情報・顧客データが安全に保存されているか

氏名、住所、電話番号、メールアドレス、決済関連情報などを扱う場合は、保存する目的と必要性を整理します。

通信時にはTLSを使用し、重要な情報は保存時の暗号化も検討します。

また、データを閲覧できる担当者やシステムを限定し、アクセス履歴を記録します。

エラーメッセージから内部情報が漏れていないか

本番環境で詳細なエラーをそのまま表示すると、データベース名、ファイルパス、使用ライブラリ、内部APIなどが外部へ漏れる可能性があります。

利用者には一般的なエラーメッセージを表示し、詳細情報はアクセス制限されたログへ記録します。

最初に確認したい「APIキー・秘密情報」の漏洩

AIで開発したアプリの診断では、最初にAPIキーやパスワードなどの秘密情報を確認します。

秘密情報が漏洩すると、外部からAPIを不正利用されたり、クラウド環境へ侵入されたりする可能性があります。

APIキーをコードへ直接記述していないか

次のような情報がコード内に含まれていないか確認します。

• APIキー
• アクセストークン
• データベースの接続情報
• JWTの署名キー
• 暗号化キー
• Webhookの署名シークレット
• クラウドサービスの認証情報

秘密情報は環境変数やシークレット管理サービスへ移し、アプリから安全に参照します。

GitHubに秘密情報をコミットしていないか

現在のコードからAPIキーを削除しても、過去のコミット履歴に残っている可能性があります。

公開リポジトリだけでなく、非公開リポジトリでも、招待されたメンバーや連携サービスから参照される可能性があるため注意が必要です。

Gitの履歴、ブランチ、プルリクエスト、Issue、ログなども確認します。

.envファイルが公開されていないか

.envファイルには、APIキーやデータベース接続情報が保存されていることがあります。

次の点を確認します。

• .gitignoreへ登録されている
• GitHubの履歴に含まれていない
• Webサーバーから直接取得できない
• ビルド成果物へ混入していない
• チャットや共有ストレージで不用意に共有されていない

OpenAI・Anthropic・StripeなどのAPIキー管理

外部サービスのAPIキーは、サービスごとに分けて管理します。

開発環境と本番環境で同じキーを使い回さず、利用できる機能や送信元、利用金額などを可能な範囲で制限します。

また、異常な利用を早期に発見するため、使用量の通知や上限設定も行います。

漏洩した可能性がある場合に行うべき対応

APIキーが漏洩した可能性がある場合は、コードから削除するだけでは不十分です。

次の順番で対応します。

1. 該当するキーを直ちに無効化する
2. 新しいキーを発行する
3. アプリやサーバーの設定を更新する
4. 不正利用の履歴を確認する
5. Gitの履歴やログから秘密情報を削除する
6. 同じ秘密情報を使用している別環境も確認する
7. 漏洩した原因を特定して再発を防止する

漏洩した可能性があるキーは、削除ではなく「失効・再発行」が必要です。

認証と「認可」は別物｜AI開発で見落としやすいアクセス制御

認証と認可は似ていますが、役割が異なります。

認証は「誰であるか」を確認する仕組みです。認可は「その人が何を実行できるか」を判断する仕組みです。

ログインできるだけでは安全ではない

ログイン機能が正しく動いていても、ログイン後にすべての情報へアクセスできてしまえば安全ではありません。

一般ユーザー、管理者、企業管理者、閲覧専用ユーザーなど、役割ごとの権限設計が必要です。

他人のユーザー情報へアクセスできないか

APIへユーザーIDを送信する設計では、そのIDを書き換えたときに他人の情報を取得できないか確認します。

サーバー側では、リクエストされたデータが、現在ログインしているユーザーに許可されたものかを毎回判定します。

管理者機能を一般ユーザーが実行できないか

管理者向けボタンを画面から非表示にするだけでは、管理者機能を保護できません。

一般ユーザーが管理者用のURLやAPIを直接呼び出した場合でも、サーバー側で拒否される必要があります。

URLやIDを書き換えて他人のデータを取得できないか

/users/100を/users/101へ変更しただけで別の利用者の情報が表示される場合、アクセス制御に問題があります。

推測しにくいIDを使うだけでなく、リクエストごとに所有者と権限を確認することが重要です。

組織・企業ごとのデータを正しく分離できているか

複数企業が利用するSaaSでは、組織ごとにデータを分離する必要があります。

検索、一覧表示、ファイル出力、通知、AI検索など、すべての処理で組織IDによる制限が適用されているか確認します。

特にRAGでは、検索前の段階で権限を適用し、別企業の文書が検索対象へ入らないようにします。

AIで作ったWebアプリのデータベースをチェックする

データベースには、顧客情報、契約情報、決済情報、社内データなどが保存されます。

一度情報が漏洩すると影響が大きいため、アプリケーションとデータベースの両方を確認します。

SQLインジェクション対策

ユーザー入力をSQL文字列へ直接連結していないか確認します。

パラメータ化クエリや適切なORMを使用し、入力値検証と組み合わせて対策します。

データベースへの直接アクセス制御

データベースがインターネットへ直接公開されていないか確認します。

接続元をアプリケーションサーバーや管理用ネットワークへ限定し、管理画面や開発ツールへのアクセスにも認証を設定します。

個人情報・機密情報の暗号化

重要な情報は、通信時だけでなく保存時の暗号化も検討します。

特に、トークン、本人確認情報、契約情報などは、漏洩時の影響を考えて保護方法を決めます。

不要なデータを保存していないか

データは多く保存するほど便利になる一方、漏洩時の影響も大きくなります。

利用目的のないデータや、保存期限を過ぎたデータを残していないか確認します。

取得しない、保存しない、保存期間を短くすることも重要なセキュリティ対策です。

バックアップにも同じセキュリティ対策が必要

本番データベースを保護していても、バックアップが誰でも取得できる状態では意味がありません。

バックアップにも、暗号化、アクセス制限、保存期限、削除ルール、復元テストを設定します。

AIで作ったAPIのセキュリティチェック

Webアプリでは、画面よりもAPIに重要な処理が集まっています。

画面上でボタンを隠していても、APIが保護されていなければ不正に実行される可能性があります。

認証なしでAPIを実行できないか

ログインが必要なAPIを、認証情報なしで実行できないか確認します。

認証トークンが無効、期限切れ、改ざん済みの場合に、確実に拒否されることも確認します。

ユーザーが実行できるAPIを制限しているか

認証済みのユーザーであっても、管理者専用APIや他組織向けAPIは実行できないようにします。

APIごとに、利用者の役割、所属組織、対象データとの関係を確認します。

大量リクエストへの対策

短時間に大量のリクエストを送られると、サーバー停止やAPI利用料金の増加につながります。

IPアドレス、ユーザー、APIキーなどを基準にレート制限を設け、異常なアクセスを監視します。

特に生成AI APIは、1回あたりの処理コストが高くなりやすいため、利用回数や入力・出力量の制限が重要です。

APIレスポンスに不要な情報が含まれていないか

画面には表示していなくても、APIレスポンスにメールアドレス、内部ID、権限情報、削除済みデータなどが含まれている場合があります。

必要な項目だけを返すように設計し、内部のデータ構造をそのまま返さないようにします。

外部APIとの通信・認証情報は安全か

外部APIとの通信では、TLSを使用し、接続先や証明書を適切に確認します。

APIキーはサーバー側で管理し、ブラウザへ送信しない構成にします。

Webhookを受け取る場合は、署名検証や再送対策も必要です。

GitHub・CI/CD・クラウド環境もセキュリティチェックする

ここは非常に重要です。

ソースコードだけが安全でも、GitHub、CI/CD、クラウド環境から侵入されたら意味がありません。

GitHubリポジトリの公開範囲

非公開にすべきコードが公開リポジトリになっていないか、外部ユーザーが招待されたままになっていないか確認します。

ブランチ保護、プルリクエストの承認ルール、秘密情報の検出なども設定します。

GitHub ActionsなどCI/CDの権限

GitHub ActionsなどのCI/CDには、本番環境へのデプロイ権限やクラウドの認証情報が設定されることがあります。

ワークフローごとの権限を必要最小限にし、外部から変更されたコードが無条件で本番へ反映されないようにします。

AWS・GCP・AzureのIAM権限

クラウドのIAM権限は、役割ごとに必要最小限へ制限します。

管理者権限を共有せず、開発、運用、閲覧、デプロイなどの用途に応じて権限を分けます。

本番環境へのアクセス権限

本番サーバー、データベース、管理画面へアクセスできる人物を限定します。

共有アカウントは避け、誰がいつアクセスしたか確認できるようにします。

退職者・外部エンジニアの権限が残っていないか

開発終了後も、外部エンジニアや退職者のGitHub、クラウド、管理画面への権限が残っている場合があります。

定期的にアカウントと権限を棚卸しし、不要になった権限を削除します。

AI機能を搭載したアプリ特有のセキュリティリスク

AIを使って開発しただけでなく、アプリ自体に生成AI機能がある場合は、通常のWebセキュリティに加えてAI特有の対策が必要です。

OWASPの生成AI向けリスクでは、プロンプトインジェクション、機密情報の開示、サプライチェーン、過剰な権限などが重要な問題として挙げられています。

プロンプトインジェクション

プロンプトインジェクションとは、入力文や読み込ませた文書によって、AIの本来の指示や制限を無視させようとする攻撃です。

ユーザーの入力だけでなく、Webページ、PDF、メール、RAGへ登録された文書などに不正な指示が含まれる場合もあります。

AIの出力をそのまま信用せず、実行前に権限確認や入力・出力の検証を行います。

AIに社内情報・個人情報を送信するリスク

AI APIへ送信する情報に、個人情報、契約情報、社内機密、認証情報などが含まれていないか確認します。

利用するサービスのデータ保存、学習利用、保存期間、利用地域などの条件も確認が必要です。

RAG・社内ナレッジから権限外の情報が表示される問題

RAGへ社内文書を登録する場合、利用者が閲覧できる文書だけを検索対象にする必要があります。

回答を生成した後に隠すのではなく、検索時点でアクセス権限を適用します。

AIエージェントに必要以上の権限を与えるリスク

AIエージェントがメール送信、ファイル削除、顧客情報の更新、決済、クラウド操作などを実行できる場合、誤操作や攻撃の影響が大きくなります。

AIには、業務を実行できる最大限の権限ではなく、目的を達成するために必要な最小限の権限だけを与えます。

AIが実行できる外部ツール・APIの制限

AIが利用できるツール、送信先、処理回数、金額、対象データなどを制限します。

重要な操作では、AIだけで完結させず、人間による確認・承認を設けます。

AIにソースコードをチェックさせるだけで十分？

結論として、AIによるコードレビューだけでは十分ではありません。

AIは短時間で多くのコードを確認できますが、実際の環境、権限構成、通信、クラウド設定、業務上の影響までは正確に判断できない場合があります。

AIコードレビューで発見しやすい問題

AIは、次のような問題の一次確認に向いています。

• APIキーの直接記述
• 入力値検証の不足
• 危険なSQLの組み立て
• エスケープ処理の不足
• 認証確認の欠落
• 古い実装パターン
• 不適切なエラー処理
• セキュリティ上問題のある設定

ただし、AIの指摘には誤検知や見落としが含まれる可能性があります。

AIだけでは発見しにくい脆弱性

次のような問題は、コードの一部分をAIへ渡すだけでは発見しにくい傾向があります。

• 複数画面やAPIを組み合わせた権限の不備
• 本番環境だけで発生する設定ミス
• クラウドやネットワークの公開設定
• 業務ルールを悪用した不正操作
• 外部サービスとの連携部分
• 実際の攻撃手順を使わないと確認できない問題
• 競合状態や複雑なセッション管理
• RAGやAIエージェントを組み合わせた権限逸脱

静的解析・動的診断・人間によるレビューの違い

静的解析は、ソースコードや依存ライブラリを解析して問題を探します。

動的診断は、実際に動作しているWebアプリやAPIへテストを行い、外部から攻撃可能な問題がないか確認します。

人間によるレビューでは、システムの設計、権限、業務フロー、データの重要性などを含めて判断します。

NISTのSecure Software Development Frameworkでも、コードや設定のレビュー、分析、テストを組み合わせ、脆弱性を確認する考え方が示されています。

重要なシステムほど複数のチェックを組み合わせる

顧客情報、決済、医療・健康情報、企業の機密情報などを扱うシステムでは、一つの診断方法だけに依存しないことが重要です。

AIレビュー、静的解析、依存ライブラリの検査、動的診断、設定確認、人間によるレビューを組み合わせることで、見落としを減らせます。

セキュリティチェックで問題が見つかったらどうする？

セキュリティ診断では、問題を見つけるだけでなく、優先順位を決めて修正し、再度確認するところまでが重要です。

脆弱性を「緊急・高・中・低」に分類する

発見した問題を、攻撃のしやすさ、漏洩する情報、影響を受ける利用者、復旧の難しさなどから分類します。

例えば、公開中のAPIキーや、認証なしで個人情報を取得できる問題は、緊急度が高いと判断される可能性があります。

本番公開前に修正すべき問題を特定する

すべての問題を同じ順番で修正するのではなく、外部から悪用される可能性が高い問題から対応します。

重大な問題が残っている場合は、本番公開を延期する判断も必要です。

修正方法を決める

脆弱性が見つかった箇所だけを修正しても、別の場所に同じ問題が残る可能性があります。

原因を確認し、共通処理、設計、権限、運用ルールを含めた修正方法を決めます。

ソースコードを修正する

修正時には、既存機能へ影響を与えないようにテストを行います。

認証や権限に関する修正では、一般ユーザー、管理者、別組織のユーザーなど、複数のアカウントで確認します。

修正後に再診断する

修正が完了したら、同じ攻撃ができなくなったことを再診断します。

また、修正によって別の脆弱性や不具合が発生していないかも確認します。

「修正したつもり」で終わらせず、再診断によって安全性を確認することが重要です。

AI開発したアプリを公開する前のセキュリティチェックリスト

AIで開発したアプリを公開する前に、最低限、次の項目を確認しましょう。

ソースコード

• APIキーやパスワードが含まれていない
• Gitの履歴にも秘密情報が残っていない
• 不要なデバッグコードが残っていない
• 入力値検証が実装されている
• SQLインジェクション対策が行われている
• XSS・CSRF対策が行われている
• ファイルアップロードが制限されている
• エラーメッセージから機密情報が漏れない
• 依存ライブラリに既知の脆弱性がない

認証・権限

• ログイン認証が適切に実装されている
• パスワードが安全に保存されている
• セッションやトークンの有効期限が設定されている
• 他ユーザーのデータへアクセスできない
• 別組織のデータへアクセスできない
• 管理者権限が保護されている
• URLやIDを書き換えても権限を回避できない
• 重要な操作に再認証や承認が設定されている

インフラ・クラウド

• データベースが外部へ直接公開されていない
• IAM権限が必要最小限に設定されている
• 本番環境へのアクセスが制限されている
• GitHubやクラウドの不要なアカウントが削除されている
• CI/CDの権限が制限されている
• バックアップが暗号化されている
• ログと監視が設定されている
• 異常なアクセスや料金増加を検知できる

AI

• プロンプトインジェクションへの対策がある
• AIへ送信する個人情報を制限している
• 利用するAIサービスのデータ取り扱いを確認している
• RAGの検索時にアクセス権限を適用している
• AIエージェントの実行権限を制限している
• 外部ツールやAPIの実行回数を制限している
• 重要な操作には人間の承認がある
• AIの出力をそのまま実行しない仕組みがある

一つでも判断できない項目がある場合は、本番公開前に専門家へ確認することをおすすめします。

AIで開発したソースコードを無料でセキュリティチェック

AIで開発したアプリ、本当にそのまま公開して大丈夫ですか？

ChatGPT、Claude、CursorなどのAIを活用して開発したWebシステム・アプリケーションを対象に、ソースコードや設定を確認する無料セキュリティ診断を実施しています。

まずは無料診断でリスクを確認

現在の開発状況やシステム構成を確認し、重大なセキュリティリスクがないかを診断します。

まだ開発途中の場合や、本番公開前の確認にも対応可能です。

ソースコード・GitHub・Webアプリを確認

ご相談内容に応じて、次のような項目を確認します。

• AIで生成したソースコード
• GitHubリポジトリ
• 公開前または公開中のWebアプリ
• APIと認証機能
• データベースへのアクセス方法
• APIキーや秘密情報の管理
• クラウドやデプロイ環境の設定
• AI・RAG・AIエージェント機能

診断に必要な権限や共有方法は、事前に確認したうえでご案内します。

発見した問題とリスクをレポート

問題が見つかった場合は、脆弱性の内容だけでなく、想定される影響や対応の優先順位を整理してご案内します。

専門用語だけを並べるのではなく、「何が問題なのか」「放置するとどうなるのか」「何を修正すればよいのか」を分かりやすくまとめます。

改善方法・修正方法をご提案

脆弱性ごとに、改善の方向性や修正方法をご提案します。

公開を止めるべき重大な問題と、今後段階的に改善できる問題を分け、優先順位を明確にします。

必要な場合のみセキュリティ改善・コード修正を依頼可能

無料診断後に、必ず修正作業をご依頼いただく必要はありません。

診断結果をご確認いただき、セキュリティ改善やコード修正、認証・権限の再設計、クラウド設定の見直しなどが必要な場合のみ、別途お見積もりいたします。

AIで作ったアプリを安全に公開するためには、正常に動くかだけでなく、不正な操作や攻撃を防げるかを確認することが重要です。

まずは無料で、現在のセキュリティリスクをご確認ください。