AIで作った社内システムのセキュリティ診断ガイド【2026年版】

「動いているから大丈夫」は危険──AIで作ったシステムが抱えるリスク

ChatGPTやClaudeに「Pythonで社員管理ツールを作って」と頼んだら、数分でそれなりに動くシステムが完成した──。2025〜2026年にかけて、こうしたAIコーディング（vibe coding）による社内システム自作が急速に普及しています。

開発コストが劇的に下がった一方で、見落とされがちなのがセキュリティです。「動いているから大丈夫」と思いがちですが、AIが生成したコードには人間の熟練エンジニアが書いたコードと同様、あるいはそれ以上に深刻なセキュリティ上の欠陥が潜んでいることがあります。

実際、OWASP（Open Web Application Security Project）は2024年のレポートで「LLM生成コードの脆弱性はレビュー不足のまま本番導入されるリスクが高い」と警告しています。本記事では、AI生成システムに特有のセキュリティリスクと、その診断方法を情シス担当者・経営者向けにわかりやすく解説します。

なぜAI生成コードにセキュリティリスクがあるのか

AI（LLM）がコードを生成するとき、その仕組み上、いくつかの限界があります。

1. 学習データに「古い」コードが混ざっている

ChatGPTやClaudeは大量のコードを学習して生成能力を身につけていますが、その学習データには数年前のコードやセキュリティ上の問題が修正される前の書き方が含まれています。モデルのカットオフ日以降に発見された脆弱性（CVE）は学習されておらず、脆弱なパターンをそのまま出力してしまうケースがあります。

2. コンテキストが限られている

AIは「今このウィンドウに見えているコード」しか把握できません。実際の業務システムは複数ファイルにまたがり、認証ロジック・データベース接続・APIキー管理などが複雑に絡み合っています。全体像を把握しないままコードを継ぎ足すと、部分的には正しく見えても全体として穴だらけになるリスクがあります。

3. セキュリティよりも「動くこと」を優先する

AIへの指示（プロンプト）に「セキュリティを考慮して」と明示しない限り、LLMは動作するコードを素早く生成することに最適化します。入力バリデーション、エラーハンドリング、認証処理などは省略・簡略化されやすい部分です。

4. レビュー・テストなしで本番稼働するケースが多い

従来の開発では、コードレビューやセキュリティテストを経てから本番に出すのが一般的でした。しかし「AIが書いたから大丈夫」という心理的バイアスが働き、ノーレビューで本番運用されているシステムが少なくありません。

AI生成コードに潜む典型的な脆弱性10選

具体的にどのような脆弱性が生まれやすいのか、代表的な10パターンを解説します。

脆弱性① 認証バイパス

# AIが生成しがちな危険なコード例
@app.route('/admin')
def admin_page():
    user_id = request.args.get('user_id')
    if user_id == 'admin':  # クエリパラメータだけで認証している
        return render_template('admin.html')
    return "Access denied"

URLに ?user_id=admin を付けるだけで管理画面にアクセスできてしまいます。AIは「動く認証」を作るものの、セッション管理・トークン検証・多要素認証といった堅牢な仕組みを省略しがちです。

典型的な問題例:

URLパラメータやCookieの値だけで認証を判断
セッションIDの有効期限・無効化処理がない
パスワードをMD5などの弱いハッシュで保存

脆弱性② SQLインジェクション（SQLi）

# 危険なコード例（文字列を直接結合）
query = "SELECT * FROM users WHERE name = '" + username + "'"
cursor.execute(query)

ユーザー入力をそのままSQLに組み込むコードは、AIが生成する際に頻出するパターンです。' OR '1'='1 のような入力で全データを取得されたり、DROP TABLE で全データが削除されたりします。

対策: プレースホルダー（パラメータ化クエリ）を使う

# 安全なコード例
cursor.execute("SELECT * FROM users WHERE name = %s", (username,))

脆弱性③ クロスサイトスクリプティング（XSS）

ユーザーが入力したデータをそのままHTMLに出力すると、悪意あるJavaScriptが実行されます。社員が利用する社内ツールでも、フィッシングや情報窃取に悪用されます。

AIが省略しがちな処理: HTMLエスケープ処理、Content Security Policy（CSP）ヘッダの設定

脆弱性④ IDOR（Insecure Direct Object Reference）

# 危険なURLパターン
https://社内ツール.example.com/document?id=1234

URLの数字を変えるだけで他のユーザーのデータにアクセスできてしまうのがIDORです。AIは「idでデータを取得するAPI」を作る際、そのidが本当にリクエストしたユーザーのものかを確認する処理（認可チェック）を省略しがちです。

脆弱性⑤ APIキーのハードコーディング

# 危険なコード例（ソースコードにAPIキーを直書き）
OPENAI_API_KEY = "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
SLACK_WEBHOOK_URL = "https://hooks.slack.com/services/xxx/yyy/zzz"

AIはサンプルコードとして動かしやすい形でAPIキーをハードコードします。このコードをGitHubなどに誤ってプッシュすると、APIキーが漏洩します。実際、GitHubでは毎日数千件のシークレット漏洩が検出されています（GitHub Secret Scanning 2024 Report）。

脆弱性⑥ SSRF（サーバーサイドリクエストフォージェリ）

「URLを入力するとコンテンツを取得してくれる機能」を実装する際、入力値を検証せずにサーバーが任意のURLへリクエストを送る脆弱性です。攻撃者は http://169.254.169.254/ （AWSのメタデータエンドポイント）などを指定して、クラウドの認証情報を盗み取ることができます。

脆弱性⑦ 不適切な権限設計

「とりあえず動かす」ためにデータベース接続ユーザーに管理者権限を付与したり、すべての社員に全データへのアクセスを許可したりするケースです。最小権限の原則（Principle of Least Privilege）が守られていないと、1つのアカウントが侵害されただけで全データが危険にさらされます。

脆弱性⑧ ログ・監査証跡の欠如

「誰が・いつ・何を操作したか」を記録する監査ログがないシステムは、インシデント発生時の原因特定が困難になります。AIはログ出力を省略することが多く、個人情報を扱うシステムでは法的なコンプライアンス問題にもなります。

脆弱性⑨ 暗号化の誤り

# 危険な例：弱いアルゴリズムの使用
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()  # MD5は解読済み

# 安全な例：bcryptを使用
import bcrypt
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

MD5やSHA-1はすでに解読されており、パスワードの保存には使うべきではありません。AIが古いコード例を参考に生成すると、こうした脆弱な暗号化を採用してしまうケースがあります。

脆弱性⑩ 依存パッケージの脆弱性

AIが生成するコードは多くの外部ライブラリ（パッケージ）に依存します。それらのパッケージ自体に既知の脆弱性（CVE）が含まれているケースがあり、放置すると攻撃の踏み台になります。

言語	脆弱性スキャンコマンド
Python	`pip-audit` または `safety check`
Node.js	`npm audit` または `yarn audit`
Ruby	`bundle audit`
Go	`govulncheck ./...`

自社でできる簡易セキュリティチェック

専門家に依頼する前に、自社で実施できる基本的なチェックを紹介します。

チェックリスト：AI生成システムの初期診断

#	確認項目	チェック
1	ソースコードにAPIキー・パスワードが直書きされていない	□
2	ソースコードがGitHubなどに誤って公開されていない	□
3	SQLクエリにパラメータ化クエリが使われている	□
4	ユーザー入力値がHTMLに出力される前にエスケープされている	□
5	認証・認可チェックがすべてのエンドポイントに実装されている	□
6	パスワードがbcrypt・Argon2等の安全なアルゴリズムで保存されている	□
7	HTTPSが強制されている（HTTP→HTTPSリダイレクト）	□
8	セッションの有効期限・無効化処理が実装されている	□
9	エラーメッセージに詳細な内部情報（スタックトレース等）が含まれない	□
10	依存パッケージに既知の脆弱性がない（pip-audit/npm audit実施済み）	□
11	操作ログ・アクセスログが記録されている	□
12	本番環境のデータベースへの直接アクセスが制限されている	□

ツールを使った自動スキャン

1. シークレットスキャン（APIキー漏洩の検出）

# gitleaksのインストールと実行
brew install gitleaks          # macOS
gitleaks detect --source .     # 現在のディレクトリをスキャン

# または truffleHog
pip install trufflehog
trufflehog filesystem .

2. Pythonの依存パッケージ脆弱性スキャン

pip install pip-audit
pip-audit

# 出力例
Name        Version  ID              Fix Versions
---------- -------- --------------- ------------
cryptography 3.4.8   CVE-2023-49083  41.0.6

3. Node.jsの依存パッケージ脆弱性スキャン

npm audit
npm audit fix   # 自動修正可能なものを修正

4. OWASP ZAP（無料のWebアプリスキャナー）

OWASP ZAP は無料で使えるWebアプリの自動脆弱性スキャナーです。社内ネットワーク内のシステムのURLを指定するだけで、XSS・SQLi・認証バイパスなどを自動的に検出します。

専門家によるセキュリティ診断が必要なケース

自社でのチェックには限界があります。以下に該当する場合は専門家による診断を強く推奨します。

専門家診断が必要な判断基準

状況	リスクレベル	推奨アクション
個人情報（氏名・住所・マイナンバー等）を扱う	高	Webアプリ脆弱性診断 + コードレビュー
インターネットからアクセス可能（外部公開）	高	ペネトレーションテスト
金融データ・決済機能がある	最高	ペネトレーションテスト + PCI DSS準拠確認
医療・健康情報を扱う	最高	ペネトレーションテスト + 医療情報安全管理ガイドライン対応
取引先との契約でセキュリティ診断が要件になっている	高	診断 + 報告書発行
社員50名以上が利用する基幹システム	中〜高	Webアプリ脆弱性診断
過去にインシデント・不審なアクセスがあった	緊急	インシデント調査 + 診断

個人情報保護法・セキュリティ基準との関係

2022年の個人情報保護法改正により、個人情報漏洩時の報告義務・本人通知義務が強化されました。社内ツールであっても個人情報を扱う場合は「安全管理措置」の実施が義務付けられており、脆弱性を放置したままの運用は法的リスクにもなります。

セキュリティ診断の費用目安【2026年版】

AI生成システムのセキュリティ診断には、主に以下の3種類があります。

Webアプリケーション脆弱性診断

自動スキャナーと手動確認を組み合わせてWebアプリの脆弱性を洗い出します。

診断規模	費用目安	期間	向いているケース
小規模（画面10〜20ページ程度）	30万〜80万円	3〜5営業日	AI生成の社内ツール・管理画面
中規模（画面20〜50ページ程度）	80万〜200万円	1〜2週間	社員向けポータル・顧客管理システム
大規模（50ページ以上・API多数）	200万円〜	2〜4週間	ECサイト・外部公開サービス

ソースコードレビュー（コード診断）

ソースコードそのものを専門家が確認し、脆弱なロジックを発見します。AI生成コードの診断に特に効果的です。

診断規模	費用目安	期間
小規模（〜5,000行）	20万〜60万円	2〜5営業日
中規模（5,000〜30,000行）	60万〜200万円	1〜2週間
大規模（30,000行以上）	200万円〜	2〜4週間

コードレビューが特に有効なケース:

AIが生成したコードを丸ごと本番運用している
開発者がセキュリティの専門知識を持っていない
認証・認可・暗号化など複雑なロジックが含まれる

ペネトレーションテスト（侵入試験）

実際の攻撃者と同じ手法を用いて、システムへの侵入を試みます。脆弱性診断より踏み込んだ評価が得られます。

対象	費用目安	期間
Webアプリペンテスト	150万〜500万円	2〜4週間
ネットワーク + Webアプリ複合	300万〜800万円	3〜6週間
フルスコープ（社内システム一式）	500万円〜	1〜2ヶ月

AI生成コードのセキュリティを高めるための開発ルール

システムをAIで作り続ける場合、以下のルールを社内で定めることで、リスクを大幅に下げることができます。

開発時のセキュリティチェックポイント

プロンプトに必ず盛り込む文言:

以下の要件でコードを書いてください：
- 入力値は必ずバリデーション・サニタイズを行うこと
- SQLはパラメータ化クエリを使うこと
- APIキー・パスワードは環境変数から読み込むこと（ハードコードしない）
- エラーメッセージに内部情報を含めないこと
- 認証・認可チェックをすべてのエンドポイントに実装すること

本番稼働前の必須チェック（最低限）:

gitleaks または trufflehog でシークレットスキャンを実施
pip-audit / npm audit で依存パッケージをスキャン
OWASP ZAPで自動スキャンを実施
チェックリスト（上記12項目）を手動確認

環境変数を使ったAPIキー管理（.envファイル）:

# .env ファイルにシークレットを記載
OPENAI_API_KEY=sk-xxxxxxxxxxxx
DATABASE_URL=postgresql://user:password@localhost/mydb

# .gitignore に .env を追加（必須）
echo ".env" >> .gitignore

# コードでは環境変数から読み込む
import os
from dotenv import load_dotenv

load_dotenv()
api_key = os.getenv("OPENAI_API_KEY")

よくある質問

Q. 社内のみで使うシステムでも診断は必要ですか？

A. 社内システムであっても、従業員データ・顧客情報・財務情報などを扱う場合は診断を推奨します。内部犯行や、VPN・社内ネットワークへの不正侵入（標的型攻撃）によって社内システムが攻撃されるケースも増えています。また、インターネットに直接接続していない「社内専用」システムでも、マルウェアに感染した端末経由で攻撃される可能性があります。

Q. AI生成コードの診断と通常のWebアプリ診断は何が違いますか？

A. 診断手法自体は同じですが、AI生成コードの場合はコードレビューを組み合わせることを特に推奨しています。AIが生成したコードは論理的な不備（IDORや不適切な権限設計など）が多く、動的スキャンだけでは検出が難しい脆弱性が潜んでいることがあるためです。

Q. 診断後にコードの修正も依頼できますか？

A. 弊社では診断後の修正支援も対応しています。特にAI生成コードの場合、修正方法の提案から実装確認（修正検証）まで一貫してサポートすることが可能です。まずはご相談ください。

Q. 診断にはどんな情報が必要ですか？

A. Webアプリ診断の場合、システムのURL・テスト用アカウント・機能一覧があればスタートできます。コードレビューの場合はソースコードへのアクセス（GitHubリポジトリの招待など）が必要です。詳細はお問い合わせください。

まとめ

AI（ChatGPT・Claude）で作った社内システムは、開発スピードと手軽さの反面、セキュリティリスクが見えにくい点に注意が必要です。

ポイント	まとめ
AI生成コードのリスク	認証バイパス・SQLi・XSS・APIキー漏洩など10種類の典型的脆弱性が存在
自社でできること	シークレットスキャン・pip-audit/npm audit・OWASP ZAPによる自動スキャン
専門家が必要なケース	個人情報取扱・外部公開・金融データ・取引先要件がある場合
費用目安	脆弱性診断30万円〜 / コードレビュー20万円〜 / ペンテスト150万円〜