生成AIで作った社内ツールのリスク7選｜シャドウAI・漏えい・コスト暴走を防ぐ公開前チェックリスト
「生成AIに頼んだら、半日で業務ツールが動いてしまった」
「便利だから、と社内チャットでURLを配ってしまった」
「気づいたら、部署ごとに”自作AIアプリ”が乱立している」
——中小企業のDX支援と社内AI活用ガバナンスの現場で、こうした相談を数多く受けてきました。
作れることと安全に使い続けられることのあいだには、見落としやすい落とし穴があります。
本記事では、その落とし穴を7つの観点に整理し、公開前に使えるチェックリストとしてまとめました。
本記事のターゲット
- 生成AIで社内ツールを作り始めたが、何を確認すればいいか分からない情報システム・DX推進担当
- 現場が勝手にAIアプリを作り出し、シャドウAIをどう管理すればいいか悩んでいる管理職・部門長
- 個人開発で公開したアプリのセキュリティや、API料金の暴走が不安なエンジニア・個人事業主
3つの立場で困りごとは違いますが、確認すべきポイントは共通です。
まず全体像を掴んでから、自分に関係する観点を深掘りすることをお勧めします。
公開前に必ず確認する3つ
詳しく読む前に、まずここだけ押さえてください。個人開発でも社内展開でも、この3つを外すと金銭事故や情報漏えいに直結します。
- 認証を付ける — 誰でもURLを知っていれば使えない状態にする
- APIキーをサーバ側に隠す — ブラウザやソースコードに鍵を出さない
- 使用量の上限とアラートを設定する — 想定外の請求に気づけるようにする
この3つは観点5・6で詳しく説明します。まずは「公開前の最低ライン」として覚えておいてください。
なぜ今、リスク管理が急務なのか
総務省の「令和6年版 情報通信白書」（企業向けアンケート）によると、生成AIを「積極的に／領域を限定して活用する方針」と答えた日本企業は42.7%。
一方で、約70%の企業が「社内情報の漏えいなどセキュリティリスクが拡大する」「著作権等の権利を侵害する可能性がある」と懸念を示しています。
つまり多くの企業は「使いたい」と「怖い」の両方を感じています。
懸念を放置したまま展開するか、チェックリストで越えていくか
——その差が、これからの社内AI活用の成否を分けます。
逆に言えば、リスクを型で押さえてから展開できれば、自炊（内製）ウェブアプリは外注より速く、業務にフィットした強力な武器になります。
全体像：7つのリスク観点を3層で整理する
リスクはバラバラに存在するのではありません。
「誰に届けるか」→「どう作るのか」→「誰が保守するか」
の3層で整理すると、抜け漏れなく点検できます。
| 層 | 観点 | 一言でいうと |
|---|---|---|
| 誰に届けるか | ① 提供先 | 落ちたら・間違えたら誰が困るか |
| 何を扱うか | ② 情報漏えい | 入力したデータがどこに渡るか |
| ③ シャドウAI | 会社が把握・許可しているツールか | |
| ④ 内製アプリの乱立 | 台帳で一覧管理できているか | |
| ⑤ 技術リスク | 生成されたコードは安全か | |
| 誰が保守するか | ⑥ コスト暴走 | 誰でも叩けてしまわないか |
| ⑦ 保守と撤退 | 作った人がいなくなっても回るか |
観点1：「誰に届けるか」で必要な品質は変わる
最初に問うべきは、機能でも技術でもなく「そのアプリを誰に届けるのか」です。
ここでリスクの大きさがほぼ決まります。
同じアプリでも、社内だけで使うのか顧客に出すのかで、必要な作り込みが大きく変わることもあります。
| 提供先 | 求められる品質 | 主なリスク |
|---|---|---|
| 顧客（B2C） | 非常に高い | 障害＝顧客影響、保守の継続義務 |
| 顧客の顧客（B2B2C） | 最も高い | 不具合が”その先”まで波及、責任が連鎖 |
| 社内 | 中程度 | 多少の停止は許容できるが、情報漏えいは同等 |
| 個人 | 低い（可用性のみ） | 停止は許容、ただしセキュリティは別問題 |
よくある落とし穴として、社内向けのつもりで作った請求書要約ツールが、いつの間にか顧客対応メールの下書きに使われていた、という事例があります。「社内用だから」と品質を落としていたため、誤要約がそのまま顧客に届く一歩手前だったのです。
サービスレベルを”下げてよい”のは可用性（多少落ちてもよい）だけです。情報漏えいのリスクは、社内でも個人でも同じ重さで付きまといます（観点2）。
観点2：どこに情報が渡るか——漏えいは提供先を問わない
便利さの裏で「入れてはいけない情報」が入力される瞬間が、最も危険です。
| 入力されがちな情報 | 起きうること |
|---|---|
| 顧客リスト | 個人情報保護法違反、信用失墜 |
| 契約書・見積・仕様書 | 秘密保持義務（NDA）違反 |
| 人事・評価・健康情報 | 要配慮個人情報の目的外利用 |
| ソースコード・鍵情報 | 知的財産・認証情報の流出 |
エルテスの実態調査（2026年1月）では、会社に無断で個人の生成AIアカウント等を利用した人のうち、6.8%が顧客リストをはじめとした個人情報や機密性の高い情報を入力していたと報告されています。「自社内のデータだけ」という油断が、最も多い漏えいの入口です。
「この欄に何を入れてはいけないか」を、入力欄のすぐそばに書く。 個人情報保護委員会の個人情報の取扱いルールを、現場の言葉で落とし込むことが第一歩です。
観点3：シャドウAI——管理職が最初に押さえるべき論点
シャドウAIとは、会社が正式に許可していない生成AIツールを、社員が個人の判断で使ってしまう現象です。
情報システム部門の管理外で使われることによる問題は以下のようなものがあがります。
| 何が起きるか | 具体例 |
|---|---|
| 情報漏えい | 学習に使われ得るサービスへ機密を投入 |
| 突然使えなくなる | 個人契約のサービスが停止・仕様変更 |
| 責任が個人に降りかかる | 規約違反・損害が会社だけでなく個人に |
| 監査不能 | 誰が何を入れたか会社が追跡できない |
ガートナー系の調査では、シャドウAIを「把握し有効な対策を取れている」企業は24%にとどまり、合計73%が事実上の無防備状態にあると報じられています（日経クロステック）。
管理職・DX担当向け：対策の定石は2つ
- 使ってよいツールの一覧（ホワイトリスト）をガイドラインで明文化する
- 「これを使いたい」が生まれたときの相談窓口を設ける
禁止一辺倒にすると、かえってシャドウAIが増えやすいです。
「使いたい気持ちを受け止める仕組み」が、結果的にリスクを下げるのです。
観点4：内製アプリの乱立——”公式のはず”が新しいシャドウAIになる
生成AIで作ったアプリは、当然ガイドラインの管理対象です。
しかし作れる手軽さゆえに数が増え、台帳で追えなくなることが問題も発生しやすいです。
| 乱立の兆候 | 具体例 |
|---|---|
| 重複ツールの並立 | 似た要約ツールが部署ごとに3つ |
| 出所不明アプリの常用 | 「誰が作ったか分からないが皆使う」 |
| 更新・停止の判断不能 | 直せる人も止める人もいない |
| セキュリティの穴の放置 | 古いAPIキーが生きたまま |
正式なはずの内製アプリが、放置されるともう一つのシャドウAIになりかねません。
内製アプリごとに、最低限これを台帳に書く：用途・提供先・保守担当・使用モデル・最終更新日。付属テンプレート集のガイドライン台帳シートを使えば、すぐ始められます。
年に1回の棚卸しと統廃合のサイクルを回すのが、乱立を防ぐ上で重要です。
観点5：生成AIが書いたコードに潜む技術リスク
動くことと、安全なことはイコールではありません。
生成AIは”それらしく動く”コードを驚くほど速く出しますが、意図せずセキュリティの定石を外してしまうことがあります。
特に開発初心者であると以下の観点に目配せできていないケースも多いです。
| 技術リスク | 何が危ないか |
|---|---|
| APIキーのむき出し | フロントに鍵が露出し、他人にAPIを使われる |
| 認証の欠如 | 誰でもアクセス・実行できてしまう |
| 入力の無検証 | SQLインジェクション・XSSの温床 |
| プロンプトインジェクション | 入力文でAIの指示を乗っ取られる |
| 依存・出力のライセンス | OSSや生成物の権利関係が未確認 |
とくに致命的なのがAPIキーの露出です。
ChatGPTやClaudeのAPIキーがフロント側やコードに埋め込まれたまま公開されると、第三者があなたのキーで自由にAPIを叩けるようになります。
最低限の定石
- 鍵は必ずサーバ側の環境変数に置き、フロントに出さない
- 生成コードは、IPAの「情報セキュリティ10大脅威 2025」などのチェックリストを一度”疑って”読む
観点6：コストが暴走する仕組みと、最低限の防御
環境変数に鍵を隠しても、まだ安心できません。アプリ自体が利用のたびに生成AIに関わるAPIによるリクエストが発生する可能性があります。
アプリの裏でAPIが動く以上、利用された回数だけ課金されます。特にその課金が個人に降りかかった場合に負担が大きいことにもなりかねない為回避しましょう。
| 暴走の経路 | 結果 |
|---|---|
| 認証なしで公開 | 誰でも無制限にAPIを消費 |
| レート制限なし | ボットや連打で短時間に大量課金 |
| 利用上限の未設定 | 上限アラートがなく気づけない |
| 想定外の拡散 | SNS等で共有され突発的にアクセス集中 |
公開前の最低ライン（チェックボックス）
- ログイン認証／ベーシック認証をアプリ自体に付ける
- IPアドレス制限で社内や自分だけに絞る
- APIプロバイダ側の使用量上限（usage cap）とアラートを設定する
- レート制限で1人あたりの実行回数を抑える
これらは高度な作り込みではなく、公開前の”チェックボックス”です。付属テンプレートのセキュリティ設定シートで、1つずつ潰してから公開してください。
観点7：誰が保守するのか——属人化と撤退計画
「作れる」と「運用し続けられる」はまったく別物です。
作った本人しか中身を分からないまま動き続けると、その人が異動・退職した瞬間、直せず止められない”ブラックボックス”が残ります。
| 保守で問われること | 用意しておくもの |
|---|---|
| 誰が直せるか | 保守担当と代替担当の明記 |
| 何で動いているか | 使用モデル・APIキー・依存の一覧 |
| いつ見直すか | 定期棚卸しの日付ルール |
| どう畳むか | 撤退（サンセット）条件と手順 |
見落とされがちなのが撤退計画（サンセット）です。
「使われなくなったアプリをどう畳むか」を先に決めておかないと、放置されたアプリが古い鍵や個人情報を抱えたまま生き続けます。作る前に”やめ方”まで決めるのが、総保有コスト（TCO）を抑える鍵です。
公開前リスクアセスメントの型
7つの観点は、公開前に一度で点検できます。提供先のレベルに応じて、必須項目を変えるのがコツです。
| 確認項目 | 個人 | 社内 | 顧客向け |
|---|---|---|---|
| 認証（ログイン／ベーシック）を付けた | ◯ | ◎ | ◎ |
| APIキーをサーバ側環境変数に隔離した | ◎ | ◎ | ◎ |
| 使用量上限・レート制限を設定した | ◎ | ◎ | ◎ |
| 入力してよい情報の範囲を明示した | ◯ | ◎ | ◎ |
| ガイドライン台帳に登録した | － | ◎ | ◎ |
| 保守担当と撤退条件を決めた | ◯ | ◎ | ◎ |
| 障害時の連絡・復旧手順を用意した | － | ◯ | ◎ |
◎＝必須、◯＝推奨、－＝任意。
個人開発でも、認証・鍵の隔離・使用量上限の3点だけは”◎”
——ここを外すと、事故に直結してしまいます。
まとめ：安全に「自炊」するための5要点
01 提供先で決まる
何を作るかより、誰に届けるかが先。顧客・社内・個人で必要な品質は変わりますが、情報漏えいだけは全員一律のリスクです。
02 情報の行き先を見る
便利さの裏で、機密情報がアプリの外へ流れていないか。「どこにデータが渡るか」を、具体管理します。
03 シャドウAIを表に出す
禁止ではなく、ホワイトリストと相談窓口で。内製アプリの乱立も、放置すれば新しいシャドウAIになるため、台帳で管理下に置きましょう。
04 生成コードを疑う
動くことと安全なことは別。APIキー露出・認証欠如・脆弱性を、IPA等のチェックリストで一度疑って読みます。
05 最低ラインと”やめ方”
認証・IP制限・使用量上限の3点を公開前に。そして作る前に、保守担当と撤退条件まで決めておくのが総保有コストを抑える近道です。
生成AIによる内製アプリは、リスクを型で押さえてしまえば、外注より速く現場にフィットする現実的な武器になります。総務省調査でも約70%の企業がセキュリティ・権利侵害を懸念する一方、42.7%が活用へ舵を切りました。
まずは、いま動いているアプリを1つ、本記事の公開前チェックリストで棚卸しすることから始めてみてください。
よくある質問
最初に「誰に届けるか」を決めることです。顧客向け・B2B2C・社内・個人では、求められるサービスレベル（可用性・保守義務・責任範囲）がまったく違い、必要な作り込みが変わります。ただし可用性は提供先で調整できても、情報漏えいリスクだけは提供先を問わず一律です。提供先を特定してから、認証・APIキーの隔離・使用量上限という最低ラインを引くのが順番です。
可用性（多少停止してよいか）の要求は下げられますが、情報漏えいのリスクは顧客向けと同等です。配慮すべき個人情報や契約書、未公開の経営情報をアプリに入力した時点で、社外へ流出する経路が生まれます。エルテスの2026年1月の調査でも、無断でAIを使った人の23.1%が顧客リストや契約書などの機密を入力していました。「自社内のデータだけ」という油断が最も多い漏えいの入口です。
会社がホワイトリスト（正式に許可した生成AIツールの一覧）で認めていないAIを、社員が自らの判断で使ってしまう現象です。情報システム部門の管理外で使われるため、情報漏えい、保守運用の断絶、そして責任が個人に降りかかるリスクを生みます。個人契約の無料版で「学習に利用する」設定のまま機密を入れても会社は監視できず、事故時の責任が個人にかかる構図が典型です。ガートナー系調査では合計73%の企業が事実上の無防備状態と報じられています。
禁止一辺倒はかえって地下に潜らせるため逆効果です。定石は2つで、第一に生成AIの分類と使ってよいツールをガイドラインで明文化すること、第二に「これを使いたい」が生まれたときの相談窓口を設けることです。正規のルートで導入判断ができれば、無断利用に走る動機が減ります。禁止ではなく、ホワイトリストと相談窓口で表に出すのが基本方針です。
なります。内製アプリもガイドラインの管理対象で、用途・提供先・保守担当・使用モデルを台帳に登録する必要があります。作れる手軽さゆえに数が増え、「どれを使えばいいか分からない」「台帳で追えない」状態になると、正規のはずの内製アプリがもう一つのシャドウAIに化けます。登録→棚卸し→統廃合のサイクルを回し、出所不明アプリの常用を防ぐことが重要です。
いいえ、動くことと安全なことは別です。生成AIは”それらしく動く”コードを速く出しますが、APIキーのむき出し、認証の欠如、入力の無検証（SQLインジェクションやXSS）、プロンプトインジェクションといった穴を含むことがあります。動いてしまうため気づかないのが「Vibe coding」の盲点です。IPAの情報セキュリティ10大脅威2025や、OWASP Top 10 for LLM Applicationsのチェックリストで一度疑って読むのが鉄則です。
ChatGPTやClaudeのAPIキーがフロント側やコードに埋め込まれたまま公開されると、第三者があなたのキーで自由にAPIを叩けるようになり、身に覚えのない請求が積み上がります。対策の基本は、鍵を必ずサーバ側の環境変数に置き、フロントに出さないことです。ただし環境変数に隠しても、アプリの裏でAPIが動く以上、叩かれた回数だけ課金される点は残るため、次の利用制限が必要になります。
誰でも見られる場所に利用制限なしで公開すると、不意の訪問者が何度も叩き、青天井の請求が発生します。企業ならまだしも個人には膨大な金額になりかねません。最低ラインは、①ログイン認証／ベーシック認証をアプリに付ける、②IPアドレス制限で範囲を絞る、③APIプロバイダ側の使用量上限（usage cap）とアラートを設定する、④レート制限で1人あたりの実行回数を抑える、の4点です。高度な作り込みではなく公開前のチェックボックスです。
「作れる」と「運用し続けられる」は別物です。作った本人しか中身を分からないと、異動・退職で直せず止められないブラックボックスが残ります（属人化）。保守担当と代替担当、使用モデルや依存の一覧、定期棚卸しの日付ルールを用意しましょう。特に見落とされるのが撤退計画（サンセット）で、やめ方を先に決めておかないと放置アプリが古い鍵や個人情報を抱えたまま生き続けます。作る前に畳み方まで決めるのが総保有コストを抑える鍵です。
