社内の誰かがAIコーディング支援で作った業務ツールが、本人の退職後も動き続けているという状況に心当たりはないでしょうか。
この記事は、フロントエンド開発を担当していて、社内向けの小さなWebツールやダッシュボードのレビュー・引き受け役になることがあるエンジニアに向けて書きます。低コード的にAIが生成したアプリの「持ち主が消えたあと」のリスクと、技術的な確認手順を整理しました。
何が起きるか：デプロイ後に消える「持ち主」
AIコード生成ツールの進化で、非エンジニアでもプロンプト（AIへの指示文）から本番相当のWebアプリを作れるようになりました。認証はOktaなどのSSO（シングルサインオンの仕組み）に接続され、DNSでドメインも割り振られ、デプロイ時には自動セキュリティスキャンも走ります。
一見、企業のガバナンス（統制の仕組み）はきちんと機能しているように見えます。ところが、これらの仕組みが保証しているのは「デプロイした瞬間」の安全性だけです。
実際に起きるのは、こうした流れです。担当者が退職し、IT部門がオフボーディング（退職時のアカウント削除作業）を完璧に実行します。アカウントは削除、PCは返却、SSOも失効。手続き上は何も問題がありません。
ところが数週間後、その人が作った社内ツールが誤った数値を返し始めます。リポジトリ（コードの保管場所）がどこにあるか誰も知らず、運用手順書もなく、担当チーム名もシステム上に記録されていません。バウンディア合同会社forva AIの解説記事として整理すると、これは「デプロイ後の運用責任者が最初から不在」という構造的な問題です。
なぜ起きるか：Day 1の解決とDay 2の空白
原因を分解すると、3段階に分かれます。
1段目は、業務部門でのアプリ開発が急増していることです。Gartnerの2022年調査では、従業員の41%がIT部門の外でテクノロジーを構築する「ビジネステクノロジスト」に該当するとされています。AIコード生成が普及する前の数字であるため、現在はこれより多いと見るのが自然です。
2段目は、それらのツールが「シャドーAI」として本番稼働していることです。Saviynt社の調査（2026年）によれば、CISO（最高情報セキュリティ責任者）の75%が、許可なく本番稼働しているAIツールを既に発見していると回答し、さらに16%は「発見できているか分からない」と答えています。認識すらできていないケースが一定数存在するということです。
3段目が本質的な問題で、デプロイのハードルが下がったことと、運用のハードルが下がったことは同じではないという点です。SSO連携、DNS割り当て、自動セキュリティスキャンは、いずれも「一度だけ答えを出す質問」です。セキュリティスキャンが確認するのは、公開した瞬間の安全性であり、18か月後にAIモデルが廃止されたり、トークン（APIの認証情報）が失効したり、連携先APIのレスポンス形式が変わったりした場合の挙動は保証しません。
フロントエンドの文脈で言い換えると、これはNext.jsやNuxtで作ったアプリをvercel deployやnpm run buildで公開した瞬間はCI（継続的インテグレーション）が通っていても、依存パッケージが半年後にセキュリティ警告を出すようになるのと同じ構造です。CI/CDパイプラインの「グリーン」は継続的な健全性の証明ではなく、その時点のスナップショットに過ぎません。
自分のプロジェクトが該当するか確認する方法
所属組織にこの種のリスクがあるかどうかは、以下の観点で確認できます。
- 社内向けWebアプリの一覧を管理する台帳（インベントリ）が存在し、各アプリに担当チーム名が紐づいているか
- SSO管理画面（Okta等の管理コンソール）で、過去90日ログインがないのに有効な連携アプリが残っていないか
- DNSレコードの一覧に、社内ドメイン配下で用途不明のサブドメインがないか（例:
report-tool.internal.example.comのような名称） - リポジトリ管理サービス（GitHub Organization等）で、コミット履歴が半年以上更新されず、かつCODEOWNERSファイルが存在しないリポジトリがないか
CODEOWNERSファイルは、GitHubでファイル単位の責任者を指定する設定ファイルです。git log --since="6 months ago" --onelineのようなコマンドで、対象リポジトリの更新頻度を素早く確認できます。更新がなく、かつオーナー不明のリポジトリが見つかった場合、それが「野良化した本番アプリ」の候補です。
フロントエンド観点では、依存関係の鮮度も重要な指標です。npm outdatedやnpx npm-check-updatesを実行し、メジャーバージョンが2つ以上遅れているパッケージが多いアプリは、長期間メンテナンスされていない可能性が高いと判断できます。
対策の手順
すでに稼働している「野良AIアプリ」への対処は、以下の順序で進めると実行しやすくなります。
1. まず社内Webアプリの棚卸しを行い、SSO連携済みアプリの一覧とDNSレコード一覧を突き合わせます。両方に登場するが担当チームが不明なものを最優先で調査対象にします。
2. 次に、対象アプリのフロントエンド構成を確認します。使用しているフレームワーク（React、Vue、Svelte等）とビルド設定（package.jsonのscripts、vite.config.tsやnext.config.js）を読み、どのAPIキーや外部サービスに依存しているかを洗い出します。
3. 依存している外部APIやAIモデルのAPIについて、提供元のバージョン廃止（デプリケーション）予定を確認します。OpenAIやAnthropicのAPIは、モデルのdeprecation日程を公式ドキュメントで告知しているため、該当モデルが期限内かどうかを必ず確認します。
4. 責任者が不明なアプリには、暫定でもチーム名をCODEOWNERSやREADMEに記載し、Slack等の通知先を1つ決めます。「誰が見るか分からない状態」を最初に解消するのが優先です。
5. 最後に、可能であればCI/CDパイプラインに依存関係の自動チェック（DependabotやRenovate）を追加し、放置による陳腐化を継続的に検知できる状態にします。
まとめ
AIによるコード生成は、社内ツールの立ち上げを劇的に速くしました。それ自体は歓迎すべき変化です。
ただし、SSO連携やセキュリティスキャンが保証するのは公開した瞬間の状態だけで、その後の依存関係の陳腐化やAPI廃止には対応しません。
まず自分の組織で、SSO連携済みアプリとDNSレコードとリポジトリのCODEOWNERSを突き合わせる棚卸しから始めてみてください。担当者不明のアプリが見つかったら、npm outdatedで依存関係の鮮度を確認し、暫定の通知先を1つ決めるところから対応を進められます。