AIが作ったコード・設定・文章を安全に使う

このレッスンのゴール

• AIの出力を実行・公開・送信する前に、検証すべき点を列挙できる
• 秘密情報、公開設定、入力値、依存関係、認証・認可を確認できる
• 「動いた」ではなく、テスト環境と差分で安全性を確認できる

AIの出力は信頼境界を越える前に検証する

AIが書いたコード、設定、SQL、シェルコマンド、メール文面は、提案です。動作したことは安全であることの証明ではありません。特に、AIが作った出力を別のシステムがそのまま実行すると、入力値や権限の欠陥が次のシステムへ伝わります。OWASPはこの種のリスクを不安全な出力処理、過剰な権限、機密情報の開示などに分けて整理しています。

実行前には、少なくとも次の順で確認します。

1. 秘密：APIキー、パスワード、秘密鍵、トークンをコード・ログ・画面に置いていないか
2. 公開範囲：リポジトリ、ストレージ、データベース、管理画面が意図せず公開されていないか
3. 入力：利用者や外部データを、そのままSQL・HTML・コマンド・パスとして扱っていないか
4. 認証・認可：ログインしているかだけでなく、その操作をしてよい人か確認しているか
5. 変更：本番へ直行せず、差分・テスト・バックアップ・ロールバックを用意したか
6. 依存関係：知らないライブラリ、MCP、Skill、拡張機能、スクリプトを無条件で追加していないか

まず安全な作業場所を用意する

実在の顧客データや本番の認証情報を使わず、テスト用のプロジェクトと合成データで動かします。Gitでは、差分を読む、秘密ファイルを追跡対象から外す、公開範囲を確認する、という順に確認します。ただし、除外設定は「既にコミットした秘密を消す」機能ではありません。公開済みの秘密は失効・交換が必要です。

外部サービスと接続する場合は、読み取り専用のテストアカウント、低い利用上限、対象を絞った権限を使います。AIが「エラーを直すため」と言って認証や公開設定を広げた場合も、その変更は別のリスクを生むため、理由と差分を確認します。

出力の検証テンプレート

AIに次のような確認項目を出させることは補助になりますが、最終判断をAIだけに任せません。

この変更について、次を表にしてください。
・読み書きするデータと権限
・外部通信先と送信内容
・秘密情報を扱う箇所
・未検証の入力が入る箇所
・失敗時の影響とロールバック方法
・テスト環境で確認する項目
表を作った後、変更は実行せず、確認待ちで止めてください。

このテンプレートは安全を保証しません。テスト、コードレビュー、アクセスログ、監視、バックアップを組み合わせて、事故が起きても発見・停止・復旧できるようにします。

まとめ

AIの出力は、信頼できる環境へ渡す前に検証します。秘密・公開範囲・入力・認証認可・変更・依存関係を確認し、合成データとテスト環境から始めます。最終的な安全性は、プロンプトではなく、技術的な境界と運用で作ります。

Q1. 「AIが作ったコードが動いた」だけでは安全の証明にならない理由はどれですか。

• 動作していても、秘密の露出、公開設定、入力処理、権限の欠陥が残る可能性がある
• AIはコードを一切実行できないから
• テストは必ず無意味だから

Q2. APIキーをGitの公開リポジトリへコミットした疑いがある場合、適切な対応はどれですか。

• ファイルを削除して、同じキーを使い続ける
• キーを失効・交換し、履歴・利用状況・公開範囲を確認する
• .gitignoreを追加すれば過去の公開も自動的に無効になる

Q3. AIに本番データベースの公開設定変更を頼む場合、適切な進め方はどれですか。

• AIが必要だと言ったら即時に変更する
• テスト環境、最小権限、差分確認、承認、ロールバックを用意する
• エラーが消えれば公開設定は確認しなくてよい

振り返り

AIにコードや設定を作らせる作業を一つ選び、実行前チェックの六項目でレビューしてください。秘密や本番データが必要になる場合は、合成データを使う手順に置き換えます。

参考資料

• OWASP「Top 10 for Large Language Model Applications」（2026年8月9日確認）
• IPA「製品開発者向け・製品利用者向けガイド」（2026年8月9日確認）
• IPA「AIセキュリティ」（2026年8月9日確認）

※本レッスンの例は一般化したものです。実際のリポジトリ、認証情報、顧客データ、社内ホスト名は教材や演習へ持ち込まないでください。