一方、見つかった問題をすべて公開前に解消しなければならないわけではありません。扱う情報や利用者の範囲によっては、公開後に改善を進めてもよいものもあります。

この記事では、AIで作ったアプリを他の拠点や全社、取引先、一般の利用者に使ってもらう前に確認したい10項目と、公開してよいかを判断する基準を解説します。取引先からセキュリティチェックを求められた場合や、社内で公開の承認を得る際にも活用できます。

記事の監修は、システム・アプリ開発に10年以上携わる、株式会社DEPARTURE代表取締役で情報処理安全確保支援士の高木翔一が担当しています。

自分で確かめるのが難しい場合は、監修者が担当するAIアプリの公開前ドックもご覧ください。

この記事の要点。公開前に確かめるのは「誰が、どの情報に、どこまでアクセスできるか」。まず公開を止める6つの条件に当てはまらないかを確かめ、次に10項目で確認し、最後に直す順番と期限を決める。

1. AIで作ったアプリは、問題なく動いていてもセキュリティチェックが必要？

Claude CodeやCursor、ChatGPTなどを使えば、作りたい機能をAIに伝えながら、社内の案件管理ツールや顧客向けアプリも作れます。しかし、画面が問題なく動いていても、セキュリティ上の問題が残っていることがあります。例えばログイン画面があっても、URLを直接開くと管理情報が見えてしまう場合があります。

AIは指示された機能を作れても、誰に何を見せないか、どの操作を禁止すべきかまで適切に設計できるとは限りません。一般的な設計の原則から外れたり、安全性への配慮が不足したりすることもあります。

公開とは、インターネット上で誰でも使えるようにすることだけではない

セキュリティの確認は、一般公開だけでなく、部署内のツールを他拠点や全社へ広げる場合、取引先に提供する場合にも必要です。利用者の立場によって見せてよい情報や使える機能が違うため、利用範囲が変わる際には権限を見直します。

海外では、AIで作ったアプリのセキュリティ上の問題が報告されている

2025年3月にAIアプリ開発ツール「Lovable」で作られた公開アプリ1,645件を調べたところ、170件（約10%）でログインせずにデータベースを読み書きできる状態でした。原因は行ごとのアクセス制限（RLS）の未設定や不備で、この問題は2025年5月に「CVE-2025-48757」として公開されました。

2026年2月27日には、Lovableで作られた試験問題・成績のアプリでログイン判定が逆になり、教師・生徒の約1万8,700人分のデータを、ログインせずに閲覧できる状態だったと報じられました。

なお、当社が調べた範囲では、2026年11月時点で日本国内においてAIで作ったことが原因と公表された事故は見当たりません。こうした問題はAIで作ったものだけに起きるわけではありません。

当社に寄せられる、AIで作ったアプリの相談も増え始めています。相談者には、自分で作ったスモールビジネスや副業の事業者が多く、セキュリティへの不安や「手元のパソコンでは動くが、Webサーバーにどう載せればよいか分からない」といった相談があります。公開前に何を確かめるかを整理することが重要です。

国内では、アプリの裏側のサーバーを狙う「A2B攻撃」に注意喚起が出ている

2026年10月13日、NICT（情報通信研究機構）は、国内で相次ぐ情報漏えいの原因の一つとして「A2B攻撃（App-to-Backend Attack）」を特定したと発表し、注意喚起を公表しました。公開されているアプリを解析し、得られた情報を手がかりに、アプリの裏側にあるサーバーを攻撃する手法です。

A2B攻撃の流れ。公開されているアプリを解析する、サーバーの接続先とやり取りの仕組み（API）を調べる、サーバーの弱点を狙って攻撃する、の3段階。

手口は次の3段階です。

  1. 誰でも入手できるアプリを解析する。
  2. アプリが通信するサーバーの接続先や、やり取りの仕組み（API）を調べる。
  3. 得られた情報をもとに、そのサーバーの弱点を狙って攻撃する。

確認された事例は主にAndroidアプリですが、NICTは、iOSアプリやWebサービスの裏側のAPIでも同様の問題が起こり得るとしています。AIの活用でアプリの解析や脆弱性の発見が効率化され、こうした攻撃がより多くのシステムに広がる可能性にも注意を促しています。

お店にたとえると、配っているチラシに裏口の場所まで載っている状態です。アプリやWeb画面は利用者に配るものなので、中身を隠しきることはできません。そのため、裏口の扉そのものを守ります。サーバー側で「この人がこのデータを見てよいか」を毎回確かめる仕組みが、扉の鍵にあたります。

A2B攻撃をお店にたとえた図。配っているチラシに裏口の場所まで載っている。チラシはアプリやWeb画面、裏口はAPI、扉の鍵は認証と権限の確認にあたる。

AIで作ったアプリも例外ではありません。画面のコードはブラウザから誰でも読めるため、サーバー側の確認が抜けていると、そこを狙われるおそれがあります。次の章で説明する「公開を止める6つの条件」の条件1〜3と、第4章の「① ログインと権限」「② データベース」が、この攻撃への備えにあたります。

2. アプリを公開してよいか、どう判断する？

見つかった問題の3つの分け方。今すぐ公開を止める、直してから公開する、公開後に計画して直す。

セキュリティチェックで何か問題が見つかった場合、すべてを修正するまで公開を延期すべきなのでしょうか。

必ずしもそうではありません。

重要なのは、問題が見つかったという事実だけでなく、その問題によって何が起こり得るのか、どの程度の被害につながるのか を考えることです。

例えば、少人数で使う簡単な社内ツールと、顧客の個人情報や決済情報を扱うサービスでは、求められる対策が異なります。同じ問題が見つかっても、扱う情報や利用者の範囲によって、公開前に対応すべきかどうかの判断は変わります。

公開するかどうかを考える際には、見つかった問題を次の3つに分けると整理しやすくなります。

横幅が狭いときは左右にスクロールできます

判断どのような問題か対応
今すぐ公開を止める他人の情報が見えるなど、重大な被害に直結する問題問題を解消するまで公開しない
直してから公開するすぐに重大な被害が起きるとは限らないが、公開前に対処しておくべき問題必要な修正を終えてから公開する
公開後に計画して直す利用規模や扱う情報を踏まえ、一定期間の先送りを認められる問題対応内容と期限を決めて公開する

ただし、公開を止めるべき重大な問題については、予算や開発スケジュールを理由に先送りしてはいけません。具体的な条件は次の章で説明します。

同じ問題でも、扱う情報によって判断は変わる

判断が分かれる例として、ログイン後に操作しない時間が続いた場合、自動的にログアウトさせる設定があります。

長時間ログインしたままの状態が続くと、パソコンを離れている間に第三者が操作できてしまうおそれがあります。そのため、一定時間でログアウトさせることは有効な対策です。

ただし、どの程度の時間に設定すべきかは、扱う情報や利用環境によって異なります。

実際に当社では、ログインの無操作時間の設定について、扱っている情報を踏まえ、公開後の対応でよいと伝えたことがあります。一般的な基準より緩い設定だからといって、必ずしも公開を止める判断になるわけではありません。

バックアップも同様です。

バックアップがないことだけで、直ちに公開を止めるとは限りません。一方、業務に欠かせないシステムで、データが消えると事業を続けられなくなるのであれば、公開前にバックアップと復元の確認が必要です。

このように、セキュリティ対策は、問題の有無だけでなく、被害が発生する可能性と、その影響の大きさを踏まえて優先順位を決めます。

予算が限られている場合は、優先順位を明確にする

セキュリティを強化しようと思えば、さまざまな対策が考えられます。しかし、すべてを最初から整えようとすると、費用も時間もかかります。

特に、これから新しい事業を始める段階では、アプリを公開し、利用者の反応を確かめることも重要です。

実際の相談でも、セキュリティ対策の必要性は理解できても、費用の面で判断に迷う人は少なくありません。こうした場合には、基本的な問題を先に修正し、公開後に改善を重ねていく方法もあります。

ただし、「公開後に対応する」と「対応しなくてよい」は違います。

先送りする問題についても、何が問題なのか、どのような影響があるのか、いつまでに対応するのかを記録しておきましょう。

公開前にすべてを完璧にしようとするのではなく、重大な問題を残さず、公開後も改善できるようにしておくことが現実的な進め方です。

3. この6つの問題が見つかったら、公開前に必ず直す

公開を止める6つの条件。ログインせずにアクセスできる、他人のデータを見たり変更したりできる、データベースが誰でも読み書きできる、秘密のAPIキーやパスワードが外部から見える、カード番号が自社のサーバーを通るか記録に残る、個人情報を扱う通信が暗号化されていない。

ここまで、問題の内容によって公開の判断が変わることを説明しました。ただし、次の6つについては例外です。

いずれも、情報漏えいや不正な操作、予期しない費用の発生など、重大な被害に直接つながるおそれがあります。1つでも該当する場合は、その問題を解消するまで公開を止めてください。

横幅が狭いときは左右にスクロールできます

公開を止める条件なぜ問題なのか対応するチェック項目
条件1 ログインせずに、本来ログインが必要な画面やデータにアクセスできる認証されていない第三者に、情報を見られたり操作されたりするおそれがある① ログインと権限
条件2 URLの番号を変えるなどの操作で、他人のデータを見たり変更したりできる正しくログインした利用者でも、権限のない情報にアクセスできてしまう① ログインと権限／② データベース
条件3 データベースが誰でも読み書きできる設定になっている第三者による情報の取得、変更、削除につながるおそれがある② データベース
条件4 秘密のAPIキーやパスワードが、外部から見える場所にある第三者に外部サービスを不正利用されたり、情報を取得されたりするおそれがある③ APIキー・パスワード
条件5 カード番号が自社のサーバーを通る、または記録に残る決済情報の漏えいにつながるほか、カード情報の取り扱いに関するセキュリティ上の要件への対応が必要になる⑤ 外部サービス連携
条件6 個人情報を扱う通信が暗号化されていない通信中の個人情報を第三者に読み取られるおそれがある④ 個人情報

特に注意したいのが、ログインとアクセス権限の問題です。

DEPARTUREでは、公開前のアプリについて相談を受けた際、ログインせずに利用できてしまう抜け道を見つけたことがあります。その際には「鍵がかかっていないドアがあるので、鍵をつけましょう」と説明し、公開前に修正するよう助言しました。

画面上にログイン機能が用意されていても、それだけでアクセス制限が適切に働いているとは限りません。

また、6つの条件に該当しなかったからといって、安全に公開できると保証されるわけではありません。ほかにも、利用者や事業に影響する問題が残っている可能性があります。

まずは、この6つに該当する問題がないかを確認し、そのうえで残りの項目について公開前に対応するかどうかを判断していきましょう。

それぞれの具体的な確かめ方は、次の「公開前に確認したい10項目」で説明します。

6つの条件に当てはまるかを自分で確かめるのが難しい場合は、AIアプリの公開前ドックで、10項目の確認とあわせてお伝えします。

4. AIで作ったアプリの公開前に確認したい10項目

公開前に確認したい10項目の一覧。ログインと権限、データベース、APIキー・パスワード、個人情報、外部サービス連携、依存ライブラリ、開発環境と本番環境、バックアップと監視、保守・修正、脆弱性チェック。

この10項目は、Webアプリの代表的な危険を分類した「OWASP Top 10:2025」とIPAの「安全なウェブサイトの作り方 改訂第7版」を参考にしています。OWASP Top 10:2025は危険の分類であり、安全性を判定するチェックリストではありません。

当社へのAIで作ったアプリの相談では、APIキーなどの秘密情報、ログイン、データベースのアクセス制御で問題が見つかる傾向があります。自分で分からない部分も含め、確認すべき箇所を把握しましょう。

① ログインと権限：許可されていない人が情報にアクセスできないか

ログイン画面があっても、URLを直接開くと管理画面が見えることがあります。ログイン後も、案件番号などをURLで変更して他人の情報を見たり書き換えたりできないことが必要です。

自分で確かめる方法

  • シークレットウィンドウでログインせずに各画面のURLを開く。
  • テスト用の別アカウントで、許可されていない画面へ進めないか確認する。
  • 自分が管理するテスト環境でURLの番号を変え、他人の情報が表示・変更されないか確認する。実際の顧客情報は使わない。

先に紹介したログインの抜け道も、この問題です。AI製アプリではログイン機能を自作している例も見られますが、専門の外部サービスに任せれば自分で保守する範囲を減らせます。

権限の設計については、業務システムの権限設計で押さえるべきポイントも参考にしてください。

公開の判断： ログインせずに情報へ入れる、または他人の情報を操作できる抜け道があれば公開前に修正します。

参考：OWASP Top 10:2025「A01 アクセス制御の不備」「A07 認証の不備」

② データベース：他人のデータを勝手に見たり変更したりできないか

画面上で制限しても、顧客情報などを保存するデータベースが自由に読み書きできては意味がありません。SupabaseのRLSは行ごとにアクセスを制御する機能で、Firebaseにはセキュリティルールがあります。開発中に緩めた設定が残っていないか注意が必要です。

自分で確かめる方法

SupabaseならRLS、Firebaseならセキュリティルールを確認します。有効になっているだけでは不十分で、誰が何を読み書きできるか、コードと設定の中身を見る必要があります。

当社が過去に見たシステムには、データベースへインターネットから直接つながるものもありました。AI製に限らない例ですが、個人情報を扱うなら、アプリのサーバーなど必要な接続元からだけつながる構成が望ましいでしょう。

公開の判断： 誰でも読み書きできる場合は公開を止めます。

参考：OWASP Top 10:2025「A01 アクセス制御の不備」「A05 インジェクション」

③ APIキー・パスワード：外部に漏れる状態になっていないか

APIキーには、漏れると外部サービスを不正利用される秘密情報があります。ブラウザから取得できるコード、GitHubの公開リポジトリ、AIとのチャットやログに残してはいけません。ただし、公開を前提としたキーもあるため用途の確認が必要です。

2026年4月20日には国内のクラウド事業者が、Google AI Studioで発行したGemini APIのキーが漏れ、不正利用で高額請求が発生した例が複数あると注意喚起しました。コードへの埋め込みや公開リポジトリへの登録が原因とされています。

自分で確かめる方法

外部サービスとキーを一覧にし、外から見える場所に秘密情報がないかを調べます。管理画面で請求アラート、利用上限、呼び出し回数の制限が可能かも確認してください。漏らさないことに加え、被害を抑え、漏れたらすぐ差し替えられるようにします。

公開の判断： 秘密のキーが外部から見えれば公開を止めます。開発用と本番用のキーを分けるなどの管理改善は、状況に応じて公開後に行う判断もあります。

参考：OWASP Top 10:2025「A02 セキュリティ設定の不備」「A04 暗号化の不備」

④ 個人情報：適切に収集・管理できているか

氏名や連絡先などについて、何を何のために集め、どこに保存し、誰が閲覧し、いつ削除するかを整理します。

個人情報保護法 第21条では利用目的の通知または公表が必要で、入力フォームなど本人から直接書面で取得する場合には、原則として事前の明示が必要です。第32条では、保有個人データに関する会社名、利用目的、開示などの手続き、安全管理の内容などを本人が知ることのできる状態にする必要があります。名称が「プライバシーポリシー」の文書自体は義務ではありませんが、そこにまとめる方法が一般的です。App StoreではApp Store Connectとアプリ内の分かりやすい場所の両方にリンクが必要で、Google Playでもプライバシーポリシーが求められます。

自分で確かめる方法

収集する情報と利用目的を書き出し、入力フォームの送信前に目的が見えるか、URLが「https://」で始まるかを確認します。ただしHTTPSだけで保存先の安全は確認できません。

漏えい等が発生した際、①要配慮個人情報、②財産的被害のおそれ、③不正の目的によるおそれ、④本人が1,000人を超える場合には個人情報保護委員会への報告が必要です。速報は把握後速やかに（目安3〜5日以内）、確報は原則30日以内、③は60日以内です。

事業で必要な情報は収集しつつ、小さく始める場合は管理を順次整え、大規模な場合は最初に設計します。

公開の判断： 個人情報を扱う通信が暗号化されていなければ公開を止めます。そのほかも必要な法令対応を満たし、規模に応じて管理します。

参考：OWASP Top 10:2025「A01 アクセス制御の不備」「A04 暗号化の不備」、個人情報の保護に関する法律（個人情報保護法）

⑤ 外部サービス連携：決済やメール送信で問題が起きないか

決済やメール配信では、通信が途切れたとき二重決済が起きたり、メールの未送信に気づけなかったりする可能性があります。利用者への表示と運営側の把握方法を確認します。

自分で確かめる方法

テスト環境で外部サービスへの接続を失敗させ、誤った処理にならないか、失敗に気づけるかを試します。

割賦販売法 第35条の16やクレジットカード・セキュリティガイドラインでは、ネットショップなど、カード決済を扱う加盟店には、カード番号を自社で保存・処理・通過させない「非保持化」、または国際的なセキュリティ基準「PCI DSS」への準拠が求められます。サイトの脆弱性対策も必要です。カード番号は利用者から決済代行会社へ直接送り、自社サーバーや通信の記録に残さない構成にします。

公開の判断： カード番号が自社サーバーを通る、または記録に残る場合は公開を止めます。ほかの失敗時の動きは被害の大きさで判断します。

参考：OWASP Top 10:2025「A08 ソフトウェアまたはデータの完全性の不備」「A10 例外的な状況への不適切な対応」、割賦販売法

⑥ 依存ライブラリ：危険な部品や古い部品を使っていないか

アプリは、ライブラリと呼ばれる既存のソフトウェア部品を組み合わせて作られています。既知の脆弱性があったり更新が止まっていたりすると、アプリにも影響します。AIが実在しない部品名を提案することも報告されています。

自分で確かめる方法

使っているライブラリの名前とバージョンを一覧にします。AIに整理させてもかまいませんが、実際の依存関係の設定と照合し、既知の脆弱性や更新状況を確かめましょう。

公開の判断： 原則は公開後の継続的な更新体制を整えます。ただし、影響の大きい脆弱性は公開前に対処します。

参考：OWASP Top 10:2025「A03 ソフトウェアサプライチェーンの不備」

⑦ 開発環境と本番環境：設定やデータが混ざっていないか

開発用と利用者が使う本番用の環境が混ざると、テスト操作が顧客データに影響しかねません。2025年7月、AI開発サービス「Replit」のAIエージェントが作業中に本番データベースを削除したと報じられました。開発用と本番用が分かれていなかったためです。これはAI製アプリの脆弱性ではなく、AIに作業を任せる際の危険を示す例です。

自分で確かめる方法

データベース、APIキー、外部サービスの設定が開発用と本番用でどうなっているかを整理し、AIが本番データに直接触れられないか確認します。

開発用と本番用で同じAPIキーを使っている例も見られます。キーは環境ごとに分けるのが基本です。どちらかで漏れると、もう一方にも影響が及ぶためです。

公開の判断： 原則は公開後1か月以内に分けます。本番データに影響する状態なら公開前に対処します。

参考：OWASP Top 10:2025「A02 セキュリティ設定の不備」

⑧ バックアップと監視：データの復元や障害の発見ができるか

バックアップは、取るだけでなく復元を試して初めて確認できます。アプリの停止やエラーに運営側が気づける監視も必要です。

自分で確かめる方法

バックアップの保存場所と取得方法を調べ、本番データを損なわないテスト環境で復元を試します。停止やエラーを管理者に知らせる仕組みも確かめます。許容できる停止時間や復元すべきデータの範囲については、システムの停止時間や復旧の目標を決める非機能要件の考え方も参考になります。

公開の判断： 原則は公開後の整備でもよいですが、事業に欠かせないシステムなら公開前に復元まで確認します。

参考（監視）：OWASP Top 10:2025「A09 セキュリティログとアラートの不備」

⑨ 保守・修正：公開後も安全に変更できるか

AIで作ったアプリでは、作った本人もコードを十分把握していない場合があります。担当者がいなくなっても修正できるよう、引き継げる状態が大切です。

自分で確かめる方法

次を、自分以外の担当者も把握できるか確認します。

  • ソースコードの保存場所
  • 外部サービスとデータベース
  • 設定の変更方法
  • 変更を試せる環境
  • 必要な情報にアクセスできる担当者

他社が開発したシステムを引き継ぐ際のチェックリストも参考になります。

公開の判断： 原則は公開後に計画して整えます。誰も直せない状態なら運用体制を見直します。

⑩ 脆弱性チェック：よくあるセキュリティ上の問題が残っていないか

代表的な脆弱性には、データベースに不正な命令を実行させるSQLインジェクションや、Webページで意図しないスクリプトを動かすクロスサイトスクリプティングがあります。エラー画面に内部の情報が表示される問題にも注意が必要です。IPAの「安全なウェブサイトの作り方 改訂第7版」は代表的な脆弱性11種類と対策を整理しています。

自分で確かめる方法

自分が管理するテスト環境でわざとエラーを起こし、内部の情報が画面に出ないか確認します。そのうえでツールや手動で代表的な脆弱性を調べます。画面上で問題が見つからなくても、コードや設定に問題が残ることはあります。正式な脆弱性診断との違いは第7章で説明します。

公開の判断： 扱う情報と規模で判断します。重要な情報を扱うなら専門家による確認も検討します。

参考：OWASP Top 10:2025「A05 インジェクション」、IPA「安全なウェブサイトの作り方 改訂第7版」

5. 10項目のチェック結果から、公開前に直すべき問題を判断する

ここまで紹介した10項目について、利用するアプリの種類ごとに、対応の優先順位を整理しました。

ただし、これはあくまで判断の目安です。同じ社内ツールでも、扱う情報や利用者の範囲によって必要な対策は変わります。

横幅が狭いときは左右にスクロールできます

チェック項目小さく始める社内ツール個人情報や決済を扱うサービス
① ログインと権限抜け道があれば公開を止める抜け道があれば公開を止める
② データベース誰でも読み書きできれば公開を止める誰でも読み書きできれば公開を止める
③ APIキー・パスワード秘密情報の漏えいは公開前に修正。管理方法の改善は公開後でも可秘密情報の漏えいは公開前に修正。被害を抑える対策も優先
④ 個人情報個人情報を扱うなら通信の暗号化は必須。管理の仕組みは規模に応じて整える通信の暗号化と必要な法令対応を公開前に確認
⑤ 外部サービス連携失敗した場合の影響に応じて判断カード番号の扱いは公開前に対応。決済処理の失敗対策も優先
⑥ 依存ライブラリ原則、公開後に更新体制を整える影響の大きい脆弱性は公開前に対応
⑦ 開発環境と本番環境原則、公開後1か月以内に分離本番データに影響する場合は公開前に分離
⑧ バックアップと監視原則、公開後に整備事業に欠かせない場合は公開前に復元まで確認
⑨ 保守・修正公開後に計画的に整備継続的に修正できる体制を確認
⑩ 脆弱性チェック扱う情報と規模に応じて判断専門家による確認も検討

重要なのは、10項目すべてに同じ労力をかけることではありません。公開を止めるべき問題を優先して解消し、それ以外の問題も対応する順番と期限を決めておきましょう。

6. 取引先のセキュリティチェックシートや社内説明にどう活用する？

自作のアプリを取引先に提供すると、セキュリティチェックシートへの回答を求められることがあります。当社がこれまで見てきたチェックシートでは、OWASPやIPAなどの基準を参考にしたものが多く、10項目の確認結果を回答に活用できます。特に保守体制と、脆弱性に対応して定期的に更新する体制は、ほぼ必ず聞かれます。

チェックシートの質問と10項目の対応

以下は、経済産業省・IPAの「サプライチェーン強化に向けたセキュリティ対策評価制度」の要求事項、IPAの「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」、総務省の「クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）」を参考にした質問例です。

横幅が狭いときは左右にスクロールできます

よくある質問の例対応する確認項目
利用者の認証やアクセス権限を管理していますか？① ログインと権限
データベースの不正アクセスを防いでいますか？② データベース
認証情報を適切に管理していますか？③ APIキー・パスワード
個人情報の保護対策をしていますか？④ 個人情報
外部サービスとの連携を安全に管理していますか？⑤ 外部サービス連携
脆弱性を確認し、ソフトウェアを更新していますか？⑥ 依存ライブラリ／⑩ 脆弱性チェック
開発環境と本番環境を管理していますか？⑦ 開発環境と本番環境
バックアップと障害監視をしていますか？⑧ バックアップと監視
保守・運用の体制がありますか？⑨ 保守・修正

回答には、実際にしていることだけを書きます。バックアップを取っていても、復元を試していなければ「復元できることを確認済み」とは書けません。

国もセキュリティ評価の共通化を進めている

取引先ごとに異なる確認をそろえるため、経済産業省とIPAは「サプライチェーン強化に向けたセキュリティ対策評価制度」を進めています。2026年10月28日に要求事項・評価基準 Ver1.1が公開され、★3は専門家が確認する自己評価、★4は第三者による評価です。申請受付は2026年度末頃の開始が予定されています。これは会社全体の対策を評価する制度で、アプリ1つの公開を判断するものではありません。

経営層への説明では、問題と対応方針をセットにする

経営者に報告する際は、問題の内容、情報漏えいや業務停止などの影響、公開前か公開後かの対応時期、担当者、まだ分からない点を整理します。技術的な用語の説明だけでなく、何を判断してほしいかを伝えることが大切です。

当社のAIアプリの公開前ドックでは、10項目の確認結果を、経営者向けの要約から始まる報告書にまとめます。社内の稟議や取引先への説明にも利用できますが、システムの安全性を保証するものではありません。

7. AIによるセキュリティチェックだけで十分？専門家に頼むべきことは？

AIと人の役割分担。AIは代表的な脆弱性を洗い出し、人は利用環境と事業への影響を踏まえて、公開前に直すかどうかを判断する。

AIはコードを読み、代表的な脆弱性を洗い出すのに役立ちます。Claude Codeの「/security-review」は、SQLインジェクション、クロスサイトスクリプティング、認証・認可の不備、依存関係の脆弱性などを探し、説明する機能です。GitHubのプルリクエストごとに自動レビューすることもできます。ただし、すべての問題を見つけられるわけではありません。

AIが見つけた問題を、どう判断するかが重要

同じ設定上の問題でも、社内の限定された利用者だけが使う場合と、一般公開される場合では、被害の可能性が異なります。小さく見える問題が、ほかの機能と組み合わさって広がることもあります。

当社でもAIで問題を洗い出しますが、指摘をそのまま採用せず、実際の利用環境と事業への影響を踏まえて判断しています。AIと人の役割分担については、AI駆動開発におけるAIと人の役割分担も参考にしてください。

自分で確認できることと、専門家の確認が必要なこと

ログインしていない状態で見える画面、秘密情報の公開状況、バックアップの有無などは、自分でも確認しやすい項目です。一方、認証の実装やデータベースのアクセス制御、コードの脆弱性は、コードと設定を読まなければ判断できない場合があります。確認手順は第4章にまとめています。

公開前チェックは主にコードや設定を確認し、公開の判断材料を整理するものです。これに対し正式な脆弱性診断は、実際に攻撃を試すなどして問題を調べます。簡易的な脆弱性診断を含む公開前チェックでも、正式な診断と同じ範囲を確認したことにはなりません。

すべてを自分で理解する必要はない

AIと一つずつ確認していけば、エンジニアでなくても公開に必要な知識を身につけられます。ただし、細部の理解に時間をかけすぎると、事業の進行に追いつかないこともあります。重要なのは大枠のリスクと対策を把握し、難しい部分を専門家に任せることです。

当社のAIアプリの公開前ドックでは、簡易的な脆弱性診断を含む10項目を確認し、報告書と報告会1回で結果をお伝えします。料金は15万円（税別）の定額で、画面20程度・コード1万行程度までを対象に、お申し込みから2週間程度で実施します。

8. アプリ公開後も必要なセキュリティ対策と保守

公開後も続けること。脆弱性の情報を確認する、リスクに応じて更新する、保守の担当を決めておく。

アプリは、公開したら終わりではありません。利用者からの意見をもとに機能を改善したり、新しい業務に合わせて変更したりすることが必要になります。

同時に、公開後もセキュリティ上の問題が見つかる可能性があります。

当社が保守しているサービスでは、脆弱性に関する情報を随時確認しています。利用しているソフトウェアに問題が見つかった場合には、そのリスクに応じて緊急でサービスを停止するか、更新するかを判断しています。

緊急性が高くないものについては、定期的なメンテナンスの中で更新し、月1回の報告会で状況を共有しています。

こうした対応を続けるためには、誰が保守を担当するのかを決めておく必要があります。

自社で対応するのか、開発会社に任せるのか。担当者がいなくなった場合も対応できるのか。公開前に役割を整理しておくと、問題が発生した際にも動きやすくなります。

すでに運用しているシステムの保守体制を見直したい場合は、システムの保守会社を切り替える際のポイントも参考にしてください。

9. 【保存・印刷用】公開前セキュリティチェックリスト

アプリの公開を判断する際は、まず次の6つの条件に該当しないか確認してください。

公開を止める6つの条件

  • 条件1：ログインせずに、本来ログインが必要な画面やデータにアクセスできる
  • 条件2：URLの番号を変えるなどして、他人のデータを見たり変更したりできる
  • 条件3：データベースが誰でも読み書きできる設定になっている
  • 条件4：秘密のAPIキーやパスワードが外部から見える場所にある
  • 条件5：カード番号が自社のサーバーを通る、または記録に残る
  • 条件6：個人情報を扱う通信が暗号化されていない

1つでも該当する場合は、公開を止めて問題を修正してください。

公開前セキュリティチェックシート

横幅が狭いときは左右にスクロールできます

確認項目はいいいえ分からない
① 許可されていない人が、画面や情報にアクセスできない□□□
② データベースの読み書きが適切に制限されている□□□
③ 秘密のAPIキーやパスワードが外部に漏れていない□□□
④ 個人情報を適切に収集・管理している□□□
⑤ 外部サービスとの連携や失敗時の動作を確認している□□□
⑥ 利用しているライブラリの安全性を確認している□□□
⑦ 開発環境と本番環境を適切に管理している□□□
⑧ バックアップと障害の監視について確認している□□□
⑨ 公開後も保守・修正できる体制がある□□□
⑩ 代表的な脆弱性について確認している□□□

「いいえ」がある場合は、公開前に対応すべき問題かどうかを判断してください。「分からない」が残っている場合は、その項目を確認するまで公開の判断を保留しましょう。

なお、すべてが「はい」でも、安全性を保証するものではありません。

10. AIで作ったアプリのセキュリティに関するよくある質問

Q1. AIにセキュリティチェックをさせれば十分ですか？

AIによるチェックだけで十分とは限りません。AIは代表的な脆弱性を見つけるのに役立ちますが、事業への影響を踏まえて公開の可否を判断するには、人による確認も重要です。詳しくは「7. AIによるセキュリティチェックだけで十分？専門家に頼むべきことは？」をご覧ください。

Q2. 社内だけで使うアプリなら、セキュリティチェックは不要ですか？

社内だけで使うアプリでも確認は必要です。部署によって閲覧できる情報を分ける必要がある場合や、退職した人のアカウントが残っている場合など、社内利用ならではの問題もあります。扱う情報と利用者の範囲を踏まえて判断してください。

Q3. 問題が見つかったら、すべて直さないと公開できませんか？

すべての問題を公開前に修正する必要があるわけではありません。ただし、この記事で紹介した公開を止める6つの条件に該当する場合は、先に修正が必要です。それ以外は、被害の大きさを踏まえて優先順位を決めます。

Q4. セキュリティ上の問題が見つかったら、アプリを作り直す必要がありますか？

必ずしも作り直しになるわけではありません。問題のある部分を修正することで対応できる場合もあります。ただし、アプリ全体の設計に関わる問題であれば、修正する範囲が広がることもあります。

Q5. SupabaseやFirebaseで作ったアプリは、何に気をつければよいですか？

特にデータベースへのアクセス制御を確認してください。SupabaseではRLS、Firebaseではセキュリティルールを使って、許可されていない人が情報を読み書きできないようにする必要があります。設定が有効になっているだけでなく、その中身も確認することが重要です。

Q6. APIキーが漏れてしまった場合、どうすればよいですか？

漏れたAPIキーをすぐに無効化するか、新しいキーに差し替えてください。あわせて、不正な利用がなかったか、利用状況や請求内容を確認します。その後、なぜ外部から見える場所にキーがあったのかを調べ、再発を防ぐ対策を行いましょう。

Q7. AIで作ったアプリにもプライバシーポリシーは必要ですか？

個人情報保護法では、「プライバシーポリシー」という名前の文書そのものが義務づけられているわけではありません。ただし、利用目的の通知・公表など、法律で求められる対応が必要です。また、App StoreやGoogle Playで公開するアプリには、プライバシーポリシーが求められます。

Q8. 専門家にセキュリティチェックを依頼すると、費用はいくらかかりますか？

当社の「AIアプリの公開前ドック」は、15万円（税別）の定額です。画面20程度・コード1万行程度までを対象に、簡易的な脆弱性診断を含む10項目を確認します。お申し込みから2週間程度で、報告書と報告会1回を通じて結果をお伝えします。

11. まとめ｜公開前に重大な問題を解消し、公開後も改善を続けよう

AIで作ったアプリを公開してよいかは、画面が正しく動いているかどうかだけでは判断できません。

重要なのは、誰がどの情報にアクセスできるのか、問題が起きた場合にどの程度の被害が発生するのかを把握することです。

まずは公開を止める6つの条件に該当する問題がないかを確認し、続いて10項目をもとに、公開前に直すものと公開後に改善するものを整理してください。

また、アプリは公開後も使い続けるものです。セキュリティ対策や保守の体制を整え、利用者の反応を見ながら改善していくことが大切です。

自分のアプリについて、どこまで対応すれば公開できるのか判断に迷う場合は、DEPARTUREのAIアプリ公開前ドックをご覧ください。作り直しを前提とせず、今あるアプリを活かしながら、修正する順番を一緒に考えます。

参考文献