ChatGPT、Claude、Cursor、GitHub Copilotなどを使えば、非エンジニアでも社内ツールを短時間で作れるようになりました。問い合わせ管理、在庫集計、請求書チェック、営業リスト抽出など、これまで外注していた小さなシステムを部門内で作れるのは大きな利点です。
しかし、AIで作ったコードは「動く」ことと「本番で安全に使える」ことが分かれます。OWASPのSecure Coding with AI Cheat Sheetは、AIコーディング支援を使う場合でも、依存関係、CI/CD、送信されるコードコンテキスト、既知脆弱性のスキャンを確認する必要があると整理しています。
バイブコーディング全体のリスク類型は、既存のバイブコーディング危機 2026で詳しく整理しています。本記事はその中でも「社内ツールを本番投入する前のGo/No-Go判断」に絞ります。より技術的な検査体制は、姉妹記事のAI生成コードにレビュー・SAST・SCAを必須にする開発体制を参照してください。
本番投入前のGo/No-Go判断
| 判断 | 本番投入してよい条件 | 止めるべき条件 |
|---|---|---|
| 認証 | 会社IDやSSOで利用者を特定できる | URLを知っていれば誰でも使える |
| 権限 | 管理者、一般利用者、閲覧のみを分けている | 全員が同じデータを見られる |
| ログ | 参照、変更、削除、出力の履歴が残る | 誰が操作したか追えない |
| 復旧 | バックアップから戻せることを試験済み | バックアップがあるか不明 |
| 責任者 | 所有部署と停止担当が決まっている | 個人アカウントや退職者に依存 |
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
社内ツールで抜けやすい項目
| 項目 | 抜けると起きること |
|---|---|
| 認証 | URLを知っている人が誰でも使える |
| 認可 | 一般社員が管理者データを見られる |
| ログ | 誰が何を見たか、何を変更したか追えない |
| バックアップ | 誤削除や障害時に戻せない |
| 入力検証 | SQLインジェクションやXSSが起きる |
| 秘密情報管理 | APIキーやパスワードがコードに残る |
| 依存管理 | 古いライブラリの脆弱性を抱える |
本番投入前の最低レビュー
バイブコーディングを禁止する必要はありません。むしろ試作には有効です。ただし、社内データや顧客情報を扱うなら、本番投入前に次のレビューを入れるべきです。
- 認証・認可レビュー
- 個人情報・機密情報の取り扱い確認
- SAST、SCA、DASTなどのセキュリティスキャン
- バックアップと復旧手順の確認
- ログ保存と監査対象の確認
- 依存ライブラリとライセンス確認
- 運用責任者と停止手順の明確化
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
GXOに相談するタイミング
「AIで社内ツールを作ったが、このまま使ってよいか不安」という段階は、外部レビューを入れる最適なタイミングです。作り直しではなく、危険な箇所だけを洗い出し、優先順位を付けて改善できます。
GXOでは、AI生成コードのレビュー、脆弱性診断、業務要件の整理、保守可能な設計へのリファクタリング、正式な業務システム化まで支援します。
参考情報
- OWASP「Secure Coding with AI Cheat Sheet」：https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html
- OpenSSF「Security-Focused Guide for AI Code Assistant Instructions」：https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions
- NIST Secure Software Development Framework：https://csrc.nist.gov/projects/ssdf
AIで作った社内ツールの本番投入前レビューを行います
GXOでは、認証、権限、ログ、バックアップ、脆弱性、保守性を確認し、社内ツールを安全に業務利用できる形へ整えます。
まず自社で確認する場合は、DX成熟度診断で運用体制も整理できます。