AIが書いたコードが動くことと、他人の情報や秘密を守れることは別の確認です。画面が表示され、保存や検索が成功しても、見せてはいけない相手へデータが渡らないかまでは分かりません。
初めてアプリを作ると、動いた瞬間に完成したと感じやすいものです。その達成感を出発点に、公開前には「誰に、何を許すアプリか」を確認します。コードをすべて読めなくても、確認が必要な箇所を担当者へ伝えることはできます。
AIが書いたコードが動いても安全とは限らない
たとえば、自分専用のメモアプリをAIで作ったとします。メモを保存でき、一覧にも出る。これは必要な機能が動くことの確認です。
次に、別の利用者から自分のメモが見えないかを考えます。保存できるという結果だけでは、この問いには答えられません。機能が成功する条件と、許してはいけない操作を拒否する条件は違うからです。
頼んだ保存や表示ができるか。動作確認で見る。
見せてはいけない人に、情報や操作を渡さないか。
キーや実データが、公開する場所へ出ていないか。
使う部品が分かり、公開後も修正できるか。
確認の観点を分けた図です。この四項目だけですべての安全性を証明できるわけではありません。
GitHubのAIコード支援に関する公式説明も、生成コードには誤りやセキュリティ上の問題が含まれる場合があり、確認やテストが必要だとしています。AIによるコードレビューにも、見落としや誤った指摘があり得ます。
これは、AIが作るコードはすべて危険という意味ではありません。人が書いたコードにも脆弱性は生じます。誰が書いたかだけで安全と決めず、必要な性質を実際に確かめることが重要です。
「安全に作って」と頼んだ後も確認は必要
AIへ条件を伝えることは役立ちます。ただ、「安全に」という言葉だけでは、何を守るのかが曖昧です。
「利用者は自分のメモだけ読める」「秘密のキーをブラウザへ渡さない」「入力された値をそのまま命令として使わない」など、確認できる条件に分けます。その条件を満たしたというAIの説明も、コードやテスト結果と照らし合わせます。
AI生成コードで確認する秘密情報とアクセス権
最初に見るのは、他人へ見せたくない情報が、どこに保存され、誰から見えるかです。開発中は、実在する人の情報や本番の秘密を入れず、架空のデータで確かめます。
| 確認するもの | 担当者へ渡せる問い |
|---|---|
| 利用者のデータ | ログインしていない人や、別の利用者が読んだり変更したりできないか |
| 管理機能 | 一般の利用者が、管理者向けの操作をできないか |
| 秘密のAPIキー | 公開するコード、Webページ、エラー表示、履歴に含まれていないか |
| 保存先と外部送信 | どこに保存し、どの外部サービスへ送る設計か。必要な情報だけか |
ログイン画面があるだけでは足りない
ログインは、誰が使っているかを確かめる仕組みです。その人がどのデータを操作してよいかは、別に確かめる必要があります。後者は「認可」と呼ばれます。
IPAのアクセス制御・認可制御の解説も、ログインした利用者が他人の情報を扱えないようにする必要性を説明しています。画面からボタンを隠しただけで、サーバー側の制限も完成したとは限りません。
テストは、自分が管理する環境で、架空の利用者とデータを使って行います。他人のサービスへ勝手にアクセスを試す必要はありません。どのように検証すればよいか分からない箇所は、確認担当へ渡します。
秘密のキーは、設定欄に入れた後の行き先も見る
APIを利用する秘密のキーを、設定ファイルへ入れることがあります。そのファイルの名前や置き場所だけで、安全とは判断できません。
公開されるページへ埋め込まれたり、エラーの記録へ出たりする構成なら、他の人に見られる可能性があります。作り方を相談するときも、キー全体や実データを貼らず、必要な箇所を伏せて共有します。
外部の部品を使うAI開発で配布元を確かめる
AIが作ったアプリにも、ほかの人が作ったプログラムの部品が使われることがあります。「この部品を追加すれば動きます」という提案が出ても、名前だけで導入を決めないようにします。
見る点は、何のための部品か、正規の提供元はどこか、どの版を使うか、更新を続けられるかです。名前が似ている別のものや、内容を確かめられない配布物を、接続やエラー解消のために次々と追加しないようにします。
MDNのソフトウェア供給経路の解説も、アプリの部品だけでなく、開発に使う道具を含めた管理を扱っています。
新しい部品を入れる操作では、プログラムが動く場合もあります。意味の分からないコマンドを「AIが勧めたから」という理由だけで実行する前に、何が追加され、どこへ作用するかを確認してください。
自動チェックに通ったら公開してよい？
自動チェックは、一定のルールに当てはまる問題や、既知の脆弱性を見つける助けになります。ただし、チェック対象外の問題や、「この人にはこの情報を見せない」というアプリ固有の条件まで、すべて分かるとは限りません。
「問題なし」という表示を見たら、何を検査した結果かを確認します。画面表示のテスト、コードの検査、部品の検査、権限のテストは、それぞれ役割が違います。
AIで作ったアプリの公開前に担当者へ渡す確認事項
相談するときは「安全ですか」だけでなく、アプリの使い方と、守りたい情報を伝えると確認しやすくなります。
| 渡す情報 | 記入する例 |
|---|---|
| 誰が使うか | 自分だけ、招待した数人、登録した人、不特定の人 |
| 何を扱うか | 架空のメモ、個人の連絡先、仕事の資料など。実データそのものは不要 |
| 誰に何を許すか | 本人だけ閲覧・編集、管理者だけ削除など |
| 何が未確認か | 別利用者のデータを拒否するテスト、秘密の保存方法、部品の更新など |
| 公開後の担当 | 更新を確認する人、問題時に止める人、連絡を受ける人 |
ログイン、個人情報、決済、公開投稿などを扱う機能で確認が残るなら、そこへ実データを入れたり、広く公開したりする前に、内容を理解できる担当者へ確認を依頼します。
詳しい人がまだいなければ、架空データだけで手元の試作を続け、公開範囲を広げる工程を分けられます。「今すぐ全部公開する」か「作るのをやめる」かの二択にする必要はありません。
公開後の更新までが、アプリを持つということ
公開時に確認しても、使っている部品に後から弱点が見つかることがあります。何を使っているか、更新情報をどこで見るか、問題があったらどう停止するかを残しておきます。
まずは、実データを入れる前に、誰がどの情報を読める設計なのかを一枚のメモにしてみてください。「動いた」の次に確かめることが見えると、AIで作る便利さを、使ってもらえるアプリへつなげやすくなります。
