AIで作ったアプリにもセキュリティ設計が必要
AI駆動開発（AIDD）は、AIにコードを書かせることだけではありません。要件の整理、実装、テスト、レビュー、修正をAIと人が分担し、短いサイクルで開発する方法です。AIは実装速度を上げられますが、業務要件、公開範囲、許容できるリスク、最終的な動作確認は人が判断します。
特に本番環境では、認証、権限、ネットワーク、バックアップ、監視といった、画面からは見えにくい仕組みが必要です。AIで作ったアプリだから特別に危険ということではありませんが、短期間で実装できる分、確認が不十分なまま公開しないことが重要です。これらを完成後に考えると作り直しが増えるため、最初から前提として設計します。
開発を始める前の準備
目的と利用者を一文で決める
「誰が、何のために、何をするアプリか」を一文で書きます。最初から多くの機能を詰め込まず、最初の利用者が一つの作業を完了できる範囲へ絞ります。
完成条件を具体的にする
画面の見た目だけでなく、入力項目、権限、エラー時の動作、保存するデータ、不要になったデータの削除方法まで決めます。AIへ依頼するときは、一度に全体を作らせず、確認可能な単位に分けます。
Gitリポジトリ
変更履歴を残し、問題が起きた変更を特定・復元できる状態にします。mainブランチへ直接すべてを反映する運用は避けます。
開発環境
言語、ランタイム、パッケージ管理方法とバージョンを固定します。本番がLinuxなら、開発環境もLinuxまたはWSLへ近づけます。
README
目的、起動方法、必要な環境変数、テスト方法を記録します。AIにも最初に読ませる前提資料になります。
課題管理
実装する機能、不具合、保留事項を文章で残します。チャット履歴だけを仕様書代わりにしません。
開発中に決めておくこと
データをどこへ保存するか
データベース、アップロードファイル、ログを同じものとして扱わないことが重要です。業務データはPostgreSQLやMySQL、画像や添付ファイルはオブジェクトストレージなど、用途に合う保存先を決めます。
認証と権限を分けて考える
ログインできることが認証、ログインした人が何を操作できるかが権限です。一般利用者、管理者、閲覧専用などの役割を決め、画面を隠すだけでなくサーバー側でも権限を検証します。
テストを同時に作る
金額計算、入力検証、権限判定など、間違えると影響が大きい処理にはユニットテストを用意します。主要な操作にはE2Eテストを加え、型チェック、Lint、依存パッケージの脆弱性検査も継続して実行します。
秘密情報と権限をコードから分離する
APIキー、DBパスワード、秘密鍵をソースコードやAIとの会話へ貼り付けてはいけません。ローカルでは環境変数を使い、.envをGitの管理対象から外します。本番ではクラウドのシークレット管理機能またはアクセス権を制限した環境変数として渡します。
- 秘密情報をGitへコミットしない
- 開発環境と本番環境で認証情報を分ける
- アプリへ管理者権限を与えない
- 漏えい時にキーを失効・再発行できるようにする
- 外部サービスのトークンへ必要最小限の権限と有効期限を設定する
一度Gitへ入れた秘密情報は、後からファイルを削除しただけでは履歴に残ります。誤って登録した場合は、履歴の処理より先に認証情報を失効させてください。
本番環境は開発用PCの延長にしない
本番では公開Web、社内限定アプリ、管理経路、データベースを分けて考えます。インターネットから到達できる範囲を最小限にし、DB、SSH、管理画面は原則として直接公開しません。
HTTPS
独自ドメインとTLS証明書を設定し、HTTPからHTTPSへ転送します。Cookieには用途に応じてSecure、HttpOnly、SameSite属性を設定します。
ネットワーク
受信通信は原則拒否し、必要なポートだけを許可します。社内向け機能はZTNAまたはサイト間VPNの内側へ置きます。
管理アクセス
SSHは鍵認証とし、rootの直接ログインとパスワード認証を無効化します。管理者には多要素認証を設定します。
データベース
アプリと同じプライベートネットワークから接続し、外部へ公開しません。接続元とDBユーザーの権限を必要最小限にします。
デプロイと切り戻し
誰がどの成果物をいつ反映したかを追跡できるようにします。テスト済みのコミットやコンテナイメージを配置し、問題が起きた場合に一つ前の状態へ戻せる手順を用意します。DBの変更はマイグレーションとして管理し、本番だけを手作業で変更し続けないようにします。
公開前に運用と復旧を準備する
公開した瞬間から、容量不足、証明書期限、アプリ停止、バックアップ失敗などが起こり得ます。担当者が画面を見続けるのではなく、自動監視と通知を用意します。
- サーバーの死活、CPU、メモリ、ディスク、inode
- WebアプリのHTTP応答
- データベースの容量と接続状況
- 最終バックアップ日時
- 監視基盤自体の死活
- クラウド利用額と請求アラート
バックアップは「取得設定がある」だけでは不十分です。保存先、保存期間、暗号化、削除権限を確認し、実際に復元できるかを試します。ランサムウェアや管理者アカウントの侵害に備える場合は、本番環境とは独立した保存先と、保存期間中に削除・上書きできない保管方式を検討します。
本番公開前チェックリスト
コードと秘密情報
- □ 本番へ反映するコミットと変更内容を確認した
- □ 型チェック、Lint、自動テストが成功している
- □ APIキー、パスワード、秘密鍵がGit履歴に含まれていない
- □ 開発用のデバッグ機能とテストアカウントを無効化した
- □ 依存パッケージの既知の脆弱性を確認した
認証と公開範囲
- □ 管理者アカウントに多要素認証を設定した
- □ 一般利用者と管理者の権限をサーバー側で分離した
- □ HTTPSを設定し、HTTPから転送される
- □ 不要なポートを公開していない
- □ DB、SSH、管理画面をインターネットへ直接公開していない
データと運用
- □ 自動バックアップの保存先と保存期間を確認した
- □ バックアップから復元する手順を確認した
- □ 死活、CPU、メモリ、ディスク、HTTP応答を監視している
- □ 異常通知を受け取れることを試した
- □ 障害時の連絡先、調査担当、復旧判断者を決めた
- □ クラウドの請求アラートを設定した
開発できたアプリを、安全に本番へ。
レーダーワークス合同会社は、AI駆動開発（AIDD）で作られたWebアプリ向けに、クラウド構築、セキュリティ設定、監視、バックアップ、セキュアな管理経路を提供します。開発そのものではなく、公開後に安全に動かすための基盤を担当します。
マネージドクラウドを見る