はじめに——「AIシステムを作った。でもセキュリティは大丈夫？」
ChatGPTやClaude、GeminiなどのAPIを使ったチャットボット、RAGによる社内ナレッジ検索、画像認識による外観検査、OllamaでローカルLLMを動かす社内文書要約システム——中小企業がAIを活用したシステムを自社で構築するケースが急速に増えています。
しかし、多くの場合、構築時の関心は「正しく動くか」「精度は十分か」に集中し、セキュリティは後回しになりがちです。AIを使って開発すればなおさらで、生成されたコードのセキュリティレビューまで手が回らないのが実情でしょう。
2026年1月、IPAが発表した「情報セキュリティ10大脅威 2026」では、「AIの利用をめぐるサイバーリスク」が第3位に初選出されました。AIシステム特有のセキュリティリスクは、もはや大企業だけの問題ではありません。
この記事では、中小企業がAIシステムを構築・運用する際に社員自ら確認できるセキュリティチェックリストを、以下の切り口で整理して提供します。
- パターン別：外部API利用 と ローカルLLM構築 の2パターン
- フェーズ別：構築前 → 構築後 → 運用時 の3フェーズ
さらに、チェックリストの実践を助けるオープンソースのAIセキュリティツールも3つ紹介します。
中小企業のAIシステムに潜むセキュリティリスクとは
中小企業がAIシステムを導入する際、代表的な構築パターンは大きく2つに分かれます。
パターン1：外部API利用型
OpenAI、Anthropic、Google等のAPIを呼び出してAI機能を実現するパターンです。チャットボット、文書要約、コード生成支援など多くの社内ツールがこの方式で構築されています。開発が容易な反面、APIキーの漏洩、送信データの管理、利用料金の暴走といったリスクがあります。
パターン2：ローカルLLM構築型
Ollama、vLLM等を使い、自社サーバーでLLMを稼働させるパターンです。データが外部に出ないため機密性は高いものの、サーバーの物理セキュリティ、ネットワーク構成、モデルのサプライチェーン攻撃（悪意あるコードが埋め込まれたモデルのリスク）など、インフラ面の課題が加わります。
いずれのパターンにも共通するリスクとして、プロンプトインジェクション（悪意ある入力によるAIの操作）、個人情報の意図しない漏洩、依存ライブラリの脆弱性、AI生成コードに含まれるセキュリティホールなどがあります。
以下のチェックリストは、これらのリスクに対してセキュリティの専門家がいない環境でも、最低限確認すべき項目を網羅したものです。
チェックリスト① 構築前（企画・設計フェーズ）
AIシステムの構築を始める前に確認すべき項目です。この段階でセキュリティ方針を決めておくことで、構築後の手戻りを大幅に減らせます。
凡例
- ○ = 該当する（確認が必要）
- △ = 状況により該当
- — = 該当しない
1. 要件定義・設計段階のセキュリティ
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 1 | 取り扱うデータの機密レベルを分類したか（公開/社内限定/機密/個人情報） | ○ | ○ | データ一覧表を作成し分類する |
| 2 | AIに送信・学習させるデータに個人情報が含まれるか確認したか | ○ | ○ | 個人情報保護法との整合性を確認 |
| 3 | 個人情報を含む場合、匿名化・マスキングの方針を決めたか | ○ | ○ | 氏名・住所・電話番号等の処理方法 |
| 4 | AI利用についてプライバシーポリシーの更新が必要か検討したか | ○ | ○ | 顧客向け・従業員向け両方を確認 |
| 5 | 利用するAIサービスの利用規約を確認したか（データの取り扱い条項） | ○ | — | データの学習利用有無、保持期間等 |
| 6 | 社内のセキュリティポリシーとAIシステムの整合性を確認したか | ○ | ○ | 情報セキュリティ管理規程との照合 |
2. APIサービス選定時の確認
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 7 | APIプロバイダーのセキュリティ認証（SOC2等）を確認したか | ○ | — | OpenAI, Anthropic等の公開情報を確認 |
| 8 | データの保存・学習ポリシーを確認したか（オプトアウト可否） | ○ | — | API経由の場合の学習利用有無 |
| 9 | データ送信先のリージョン（国・地域）を確認したか | ○ | — | GDPR等の越境データ規制への対応 |
| 10 | SLAや障害時の対応方針を確認したか | ○ | — | サービス停止時の業務継続計画 |
| 11 | API利用料金の上限設定方法を確認したか | ○ | — | 想定外の高額請求を防止 |
3. ローカルLLM環境の設計
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 12 | サーバーの設置場所・物理セキュリティを検討したか | — | ○ | 施錠管理、入退室記録等 |
| 13 | GPU/メモリ等のハードウェア要件を満たしているか | — | ○ | モデルサイズに応じたスペック確認 |
| 14 | ネットワーク構成（外部公開の有無）を設計したか | — | ○ | ファイアウォール、VPN等の設計 |
| 15 | モデルのライセンス条件を確認したか（商用利用可否） | — | ○ | Llama, Mistral等のライセンス確認 |
| 16 | バックアップ・災害復旧の方針を決めたか | — | ○ | モデルデータ、設定ファイルの保全 |
4. 開発体制・プロセス
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 17 | セキュリティレビューの担当者・実施タイミングを決めたか | ○ | ○ | 開発完了時、リリース前等 |
| 18 | AIを使ってコードを生成する場合のレビュー方針を決めたか | ○ | ○ | AI生成コードの脆弱性チェック方法 |
| 19 | テスト環境と本番環境の分離方針を決めたか | ○ | ○ | テストデータに本番データを使わない |
| 20 | インシデント発生時の対応フロー（連絡先・手順）を準備したか | ○ | ○ | 誰が何をするかを明文化 |
チェックリスト② 構築後（リリース前チェック）
AIシステムが完成した後、社内展開や公開前に確認すべき項目です。「動いた！」で終わらせず、このチェックを通してからリリースすることが重要です。
1. 認証・アクセス制御
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 1 | 管理画面・ダッシュボードに適切な認証が設定されているか | ○ | ○ | パスワード強度、MFA対応を確認 |
| 2 | ユーザーごとのアクセス権限が最小権限の原則で設定されているか | ○ | ○ | 不要な管理者権限がないか |
| 3 | 退職者・異動者のアカウントが無効化されているか | ○ | ○ | 定期的な棚卸しの実施 |
| 4 | 外部に公開不要なエンドポイントが公開されていないか | ○ | ○ | ポートスキャン等で確認 |
| 5 | RLS（Row Level Security）等のデータアクセス制御が有効か | ○ | △ | Supabase等のBaaS利用時は必須 |
2. APIキー・シークレット管理
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 6 | APIキーがソースコード内にハードコードされていないか | ○ | △ | GitHubの公開リポジトリ要注意 |
| 7 | APIキーが環境変数またはシークレットマネージャーで管理されているか | ○ | △ | .envファイル、Vercel環境変数等 |
| 8 | .envファイルが.gitignoreに含まれているか | ○ | △ | Git履歴にも含まれていないか確認 |
| 9 | APIキーに最小限の権限のみ付与されているか | ○ | △ | 読み取り専用で足りる場合は書き込み不可に |
| 10 | API利用料金の上限・アラートが設定されているか | ○ | — | 月額上限、異常検知アラート |
3. 入出力の安全性
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 11 | ユーザー入力がプロンプトにそのまま挿入される構造になっていないか | ○ | ○ | プロンプトインジェクション対策 |
| 12 | システムプロンプトに機密情報（社内情報等）が含まれていないか | ○ | ○ | プロンプトリーク時のリスク評価 |
| 13 | AIの出力がそのままDB操作やコマンド実行に使われていないか | ○ | ○ | サニタイズ・バリデーション必須 |
| 14 | 出力内容に個人情報や機密情報が混入しないかテストしたか | ○ | ○ | 意図しない情報漏洩の防止 |
| 15 | 出力のフィルタリング（有害コンテンツ等）が実装されているか | ○ | ○ | 用途に応じた出力制御 |
4. 通信・インフラ
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 16 | すべての通信がHTTPSで暗号化されているか | ○ | ○ | HTTP通信が残っていないか確認 |
| 17 | デプロイ先の環境変数・セキュリティ設定が適切か | ○ | △ | Vercel, AWS等の設定レビュー |
| 18 | デフォルトパスワードや初期設定が変更されているか | ○ | ○ | 管理画面、DB、サーバー等 |
| 19 | 不要なポートが開放されていないか | △ | ○ | ファイアウォール設定の確認 |
| 20 | SSL/TLS証明書が有効で期限切れでないか | ○ | ○ | 自動更新設定の確認 |
5. データ保護
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 21 | データベースのバックアップが定期的に取得されているか | ○ | ○ | 自動バックアップの設定確認 |
| 22 | バックアップデータが暗号化されているか | ○ | ○ | 保管時・転送時の暗号化 |
| 23 | ログに個人情報や機密データが記録されていないか | ○ | ○ | デバッグログ、アクセスログの確認 |
| 24 | データの保持期間と削除ポリシーが定められているか | ○ | ○ | 不要データの定期削除 |
| 25 | ローカルLLMの学習データが適切に保護されているか | — | ○ | ファイルパーミッション、暗号化 |
6. 依存関係・ライブラリ
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 26 | 使用パッケージに既知の脆弱性がないか確認したか | ○ | ○ | npm audit / pip audit の実行 |
| 27 | 不要なパッケージが削除されているか | ○ | ○ | 攻撃対象面の最小化 |
| 28 | パッケージのバージョンが著しく古くないか | ○ | ○ | セキュリティパッチの適用状況 |
| 29 | サプライチェーン攻撃のリスクを考慮しているか | ○ | ○ | パッケージの信頼性確認 |
7. 法令・規約
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 30 | 個人情報保護法への対応が完了しているか | ○ | ○ | 利用目的の特定・通知・同意 |
| 31 | AIサービスの利用規約に違反する使い方をしていないか | ○ | — | 禁止用途の確認 |
| 32 | AI利用について顧客・ユーザーへの開示がされているか | ○ | ○ | AI利用の明示義務の確認 |
| 33 | AI生成コンテンツの著作権リスクを把握しているか | ○ | ○ | 商用利用時の権利関係 |
| 34 | 業界固有の規制（医療、金融等）への対応を確認したか | ○ | ○ | 該当する場合のみ |
チェックリスト③ 運用時（保守・変更管理）
AIシステムは「作って終わり」ではありません。モデルのバージョンアップ、機能追加、ハードウェア変更など、変更が入るたびにセキュリティの再確認が必要です。
1. 定期セキュリティ確認（月次）
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 1 | APIキーのローテーション（定期変更）を実施したか | ○ | △ | 90日ごと等のポリシーに従う |
| 2 | 未使用のAPIキー・アカウントを棚卸ししたか | ○ | ○ | 不要なキーの無効化・削除 |
| 3 | アクセスログに不審なアクセスがないか確認したか | ○ | ○ | 異常なIPアドレス、時間帯等 |
| 4 | API利用量・コストに異常がないか確認したか | ○ | — | 急増の原因調査 |
| 5 | 依存パッケージの脆弱性スキャンを実施したか | ○ | ○ | npm audit / pip audit / Dependabot |
| 6 | SSL/TLS証明書の有効期限を確認したか | ○ | ○ | 期限切れ前に更新 |
| 7 | バックアップの復元テストを実施したか | ○ | ○ | 四半期に1回程度 |
2. バージョンアップ時
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 8 | AIモデルのバージョン変更による出力品質への影響をテストしたか | ○ | ○ | 回帰テストの実施 |
| 9 | APIの仕様変更（破壊的変更）を確認したか | ○ | — | Change Log / Release Notesの確認 |
| 10 | 新バージョンで追加されたセキュリティ機能を確認したか | ○ | ○ | セキュリティ強化の活用 |
| 11 | プロンプトの互換性に問題がないか確認したか | ○ | ○ | モデル変更時の出力差異 |
| 12 | 依存ライブラリの互換性を確認したか | ○ | ○ | バージョン競合の有無 |
| 13 | ステージング環境での十分なテストを行ったか | ○ | ○ | 本番反映前の検証 |
3. 実装変更時（機能追加・修正）
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 14 | 新機能に関するセキュリティレビューを実施したか | ○ | ○ | コードレビュー、脆弱性チェック |
| 15 | 新たなデータ入力経路にバリデーションが追加されているか | ○ | ○ | SQLインジェクション、XSS対策 |
| 16 | 新しいAPIエンドポイントに認証・認可が設定されているか | ○ | ○ | 未認証アクセスの防止 |
| 17 | 新たに取り扱うデータの機密レベルを分類したか | ○ | ○ | 構築前チェックリストを再確認 |
| 18 | 変更内容が既存のセキュリティ対策に影響しないか確認したか | ○ | ○ | RLS、認証ロジック等への影響 |
| 19 | ロールバック手順を準備したか | ○ | ○ | 問題発生時の即時切り戻し |
4. ハードウェア・インフラ変更時
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 20 | サーバー移行後のセキュリティ設定（FW、ポート等）を確認したか | △ | ○ | 新環境での設定再適用 |
| 21 | 移行先でのデータ暗号化設定を確認したか | △ | ○ | 保管時・転送時の暗号化 |
| 22 | 旧サーバーのデータ完全消去を行ったか | △ | ○ | データの残留防止 |
| 23 | GPU/メモリ変更後のモデル動作を検証したか | — | ○ | 性能・出力品質の確認 |
| 24 | ネットワーク構成の変更による影響を確認したか | △ | ○ | VPN、セグメント分離等 |
| 25 | 物理セキュリティ（設置場所、施錠等）を確認したか | — | ○ | サーバールームの管理 |
5. インシデント対応・監視
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 26 | AIの応答品質の劣化がないか定期確認しているか | ○ | ○ | 週次/月次でサンプルチェック |
| 27 | 異常なAPI呼び出しパターンを検知する仕組みがあるか | ○ | △ | アラート設定、ダッシュボード |
| 28 | インシデント発生時の対応手順が最新化されているか | ○ | ○ | 連絡先、エスカレーション先の確認 |
| 29 | セキュリティインシデントの記録・振り返りを行っているか | ○ | ○ | 再発防止策の策定 |
| 30 | AIの出力に関するユーザーからの報告窓口があるか | ○ | ○ | 不適切出力のフィードバック収集 |
6. コンプライアンス・継続的改善
| No. | チェック項目 | API利用 | ローカルLLM | 備考・確認方法 |
|---|---|---|---|---|
| 31 | AIサービスの利用規約の変更を定期的に確認しているか | ○ | — | 四半期ごとに確認 |
| 32 | 個人情報保護法等の法改正への対応を確認しているか | ○ | ○ | 法務担当との連携 |
| 33 | AI倫理ガイドラインの社内整備・更新をしているか | ○ | ○ | 利用ルールの見直し |
| 34 | 従業員へのAIセキュリティ教育を定期的に実施しているか | ○ | ○ | 年1回以上の研修実施 |
| 35 | チェックリスト自体の見直し・更新を実施したか | ○ | ○ | 半年〜1年ごとの見直し |
チェックリストを支える——注目のオープンソースAIセキュリティツール3選
チェックリストの各項目を実践する際に活用できる、オープンソースのAIセキュリティツールを3つ紹介します。いずれも無料で利用でき、中小企業でも導入しやすいものです。
1. Garak（ガラック）——LLMの脆弱性スキャナー
開発元：NVIDIA
GitHub：https://github.com/NVIDIA/garak
対応チェック項目：構築後チェックリストの「入出力の安全性」全般
Garakは、LLMに対するペネトレーションテスト（侵入テスト）ツールです。ネットワークセキュリティにおけるnmapやMetasploitのような位置づけで、LLMの脆弱性を体系的にスキャンします。
プロンプトインジェクション、ジェイルブレイク（安全機能の迂回）、データ漏洩、有害コンテンツの生成、ハルシネーション（事実と異なる情報の生成）など、LLM特有の脆弱性を自動的にテストできます。OpenAI、Hugging Face、Ollama等の主要なプラットフォームに対応しており、API経由のモデルもローカルモデルもスキャン可能です。
中小企業での活用場面としては、自社で構築したチャットボットやRAGシステムをリリースする前に、プロンプトインジェクションに対する耐性や、意図しない情報漏洩がないかを自動テストする用途が考えられます。
2. LLM Guard——LLMの入出力をリアルタイムで防御
開発元：Protect AI
GitHub：https://github.com/protectai/llm-guard
ライセンス：MIT（商用利用可）
対応チェック項目：構築後チェックリストの「入出力の安全性」、運用時チェックリストの「インシデント対応・監視」
LLM Guardは、LLMアプリケーションの入力（プロンプト）と出力（レスポンス）をリアルタイムでスキャンし、セキュリティリスクを検知・ブロックするツールキットです。15種類の入力スキャナーと20種類の出力スキャナーを備えており、プロンプトインジェクションの検出、個人情報（PII）の自動マスキング、有害コンテンツのフィルタリング、機密データの漏洩防止などの機能を提供します。
Garakが「テスト時」のスキャンツールであるのに対し、LLM Guardは「運用時」にリアルタイムで動作するガードレールです。Python環境で動作し、GPT、Llama、Mistral等の主要なLLMに対応しています。
3. ModelScan——AIモデルのマルウェアスキャナー
開発元：Protect AI
GitHub：https://github.com/protectai/modelscan
対応チェック項目：構築前チェックリストの「ローカルLLM環境の設計」、構築後チェックリストの「依存関係・ライブラリ」
ModelScanは、AIモデルファイルに悪意あるコードが埋め込まれていないかをスキャンするツールです。Hugging Face等からダウンロードしたモデルをローカル環境で使う前に、マルウェアやシリアライゼーション攻撃（モデルの保存・読み込みプロセスを悪用した攻撃）の有無を検査できます。
H5、Pickle、SavedModel等の主要なモデル形式に対応しており、PyTorch、TensorFlow、Keras、Sklearn、XGBoostで作成されたモデルをスキャンできます。ファイルをバイト単位で読み取って危険なコードの痕跡を検出する仕組みのため、悪意あるコードを実行することなく安全にスキャンできます。
ローカルLLMを構築する中小企業にとって、外部からダウンロードしたモデルの安全性を確認するための必須ツールといえます。Hugging Face上の100万以上のモデルのうち、実際に悪意あるコードが含まれていた事例が400件以上報告されており、モデルのスキャンは「やるべき」ではなく「やらなければならない」対策です。
チェックリストExcelファイルのダウンロード
本記事で紹介した全チェック項目を、そのまま社内で使えるExcelファイルとして用意しました。「構築前」「構築後」「運用時」の3シート構成で、各項目に「担当者」「確認日」の記入欄を設けています。
【ダウンロード】AIシステム セキュリティチェックリスト（Excel形式）
使い方
- 「API利用」「ローカルLLM」の列で、自社のパターンに該当する項目（○）を確認する
- 各項目について「備考・確認方法」を参考に確認を実施する
- 「担当者」「確認日」を記入して記録を残す
- △の項目は自社の状況に応じて該当するか判断する
- 定期的（月次・四半期等）に運用時チェックリストを再確認する
まとめ——「動く」の次は「安全に動く」を確認しよう
AIを使ったシステム開発は、これまで以上にスピーディーになりました。しかし、スピードと引き換えにセキュリティが見落とされるケースが増えています。
本記事のチェックリストは、セキュリティの専門家がいない中小企業でも、社員自ら確認できるレベルで設計しています。すべての項目を一度にクリアする必要はありません。まずは自社のAIシステムに該当する項目から始めて、段階的にセキュリティレベルを上げていくことが現実的なアプローチです。
今すぐできる3つのアクション：
- APIキーの棚卸し——ソースコードにハードコードされていないか、不要なキーが残っていないか確認する
- 入出力のテスト——自社のAIシステムに対して、意図的に個人情報や不正な指示を入力し、どう応答するか確認する
- 依存パッケージの脆弱性チェック——
npm auditやpip auditを実行して、既知の脆弱性がないか確認する
AIシステムのセキュリティは、一度やれば終わりではなく、継続的に取り組むべきテーマです。本記事のチェックリストとオープンソースツールを活用して、「動く」だけでなく「安全に動く」AIシステムを目指しましょう。
コメント