自作したAIアプリを、社外に出す前に — 「使う側」から「提供する側」に回ると、何が変わるか

生成AIで、業務アプリが作れるようになった。

正確に言えば、作り始めるまでの距離が極端に短くなった。仕様書も、見積も、稟議もいらない。困っている当人が、その日のうちに動くものを手元に置ける。これ自体は前進であって、止める理由はない。当社も止めることを勧めない。

問題はその次に起きる。

最初は自分だけが使う。次に隣の席の人が使い始める。しばらくすると、部署の業務がその上で回っている。そしてある日、「これ、お客さんにも出せるんじゃないか」という話になる。

**この最後の一歩で、立場が変わる。**そしてそのことは、渡す側からはほとんど見えない。

以下、制度と文書の記述は公的資料から直接確認したものである。そこから先の読み（なぜそうなっているか、どう動くべきか）は AISolve 編集部の解釈であり、その旨を都度明示する。

その前に — 本稿が「書かないこと」

先に正直に書いておく。**「AIによって非エンジニアがアプリを作れるようになり、自作アプリの利用が広がっている」ことを直接測定した一次調査を、本稿は見つけられなかった。**官公庁・民間を通じて探したが、アプリを「誰が作っているか」を尋ねた公的調査は確認できなかった。したがって本稿は、この現象の広がりを数値では主張しない。

周辺の数値として確認できたのは次の3点である。

出典	調査実施時期	分母	数値
IPA『DX動向2026』	2026年4月中旬〜6月中旬	n=1,799	生成AIを「導入している」が2024年度 22.6% → 2025年度 44.0%
帝国データバンク『生成AIに関する企業の動向調査』	2026年3月17日〜31日	生成AI活用企業 3,560社	用途として「コード生成などのプログラミング支援」5.9%
ITR『ローコード／ノーコード開発市場規模推移および予測』	2026年2月5日発表	国内22ベンダーへの調査	2024年度市場規模 994億円（前年度比15.1%増）、2024〜2029年度CAGR 12.9%

〈3つは分母も単位も異なり、横に並べて比較できない。帝国データバンクの 5.9% の分母は有効回答 10,312 社ではなく、そのうち生成AIを活用している 3,560 社である。ITRの数値はベンダー側の売上ベースの市場規模であって、企業の実施率ではない。また『DX動向2026』の本文・データ集には「内製」「ノーコード」「市民開発」「非エンジニア」という語が一度も登場しない〉

言えるのはここまでである。生成AIの導入は急速に広がっており、その用途のひとつにコード生成があり、ノーコード市場は拡大している。「誰でも作れるようになった」はそこから先の話で、数値の裏付けを本稿は持っていない。

一本目と二本目の線は、すでに語り尽くされている

自作アプリのリスクとして語られることは、だいたい2つに集約される。

データの線 — そのアプリに何を入れてよいか。顧客情報、個人情報、契約書、人事情報。 権限の線 — そのアプリが何にアクセスできるか。読むだけか、書き換えるか、外部に送信するか。

この2点は、すでに多くの記事が扱っている。段階を分けて管理水準を変える、という発想も同様である。「原則禁止では回らないので線を引く」という立場は、2026年時点ではすでに定型句と言ってよい。本稿はここを繰り返さない。

参考までに、IPAが2026年7月に公開した『生成AIおよびAIエージェントを安全に活用するための手引書』（第1版・99ページ）は、起こりうる被害を7つに分類している。表記は原文のとおり。

	発生被害
A	情報の漏洩
B	付与権限外の操作
C	システムや内部データの改ざん
D	AIシステムのサービス停止
E	虚偽や低品質な出力の利用および出力の誤用
F	第三者への加害
G	過剰課金の発生

A が「データの線」、B・C が「権限の線」におおむね対応する。残る D〜G は、使う人数と使われ方が広がるほど効いてくる被害である。ここから先が本稿の主題になる。

〈なお、同手引書の全99ページに「中小企業」という語は一度も登場しない（「ノーコード」「内製」「自作」「非エンジニア」「市民開発」も同様に0件）。想定読者は「AI導入者」「AI管理者」「セキュリティ担当者」であり、IT担当者が一人もいない会社を名指しした文書ではない。本稿はその前提のうえで読み替えている〉

三本目の線 — 「誰が使うか」

同手引書の第5章は、対策を考える前の段階で評価すべき「固有リスク」を扱う。その冒頭に、本稿がいちばん引きたい一文がある。

例えば、同じ生成 AI を利用する場合であっても、公開情報を用いた社内向けの文章作成支援と、顧客情報を参照して外部顧客へ自動応答する AI システムでは、想定される被害の大きさは大きく異なる。

（IPA 手引書 第5章、p.42）

**同じAIでも、誰に向けるかで別物になる。**同手引書はこれを評価軸として具体化しており、「AIシステムの提供範囲」を3段階に置いている（同 p.57、判断基準例は原文表記）。

レベル	判断基準例
低	特定のチーム・部門、個人（利用人数が限定的、利用者の特定管理が容易である）
中	社内全体・複数の部門
高	外部、不特定多数（例：インターネット上に AI システムを公開）

企画段階の要件定義についても、同様の記述がある。

対象利用者については、外部顧客向けか社内向けか、特定の利用者向けか不特定多数向けかによって、求められる管理水準が異なる。

（同 3.1.1、p.24）

つまり**「誰が使うか」で管理水準を変えるという考え方は、本稿の思いつきではなく、公的文書が評価軸として置いているもの**である。そしてもうひとつ重要なのは、同手引書が固有リスクの再評価タイミングとして「業務要件・利用範囲の変更時」を挙げている点である（同 p.43）。作った時点の評価は、使われ方が変わった時点で無効になる。

〈ただし、同手引書は自作アプリ・市民開発という切り口を持っていない。全文検索で確認済みである。上の3段階は、購入・調達したAIシステムを含む一般的な評価軸として書かれている〉

「外部」に踏み出すと、呼び名が変わる

社外に出す——ここで参照先が変わる。総務省・経済産業省の『AI事業者ガイドライン』第1.2版（2026年3月31日公開）は、AIに関わる事業者を3つの主体に分けている。

そのうち「AI提供者」の定義は次のとおり。

AI システムをアプリケーション、製品、既存のシステム、ビジネスプロセス等に組み込んだサービスとして AI 利用者（AI Business User）、場合によっては業務外利用者に提供する事業者

（本編 p.5）

同ページの脚注には、開発者と提供者の分担についてこう書かれている。

AI 提供者は UI/UX 設計や既存業務システムとの統合等を担う

生成AIサービスの上に自前の画面と業務ロジックを載せる、というのは、まさにこの記述に当たる作業である。そして同ガイドラインは、同一の事業者が開発者・提供者・利用者の複数を兼ねる場合があることを明記している（同 p.5）。

さらに、同ガイドラインの別添には、この状況に名前が付いている。別添6は、AIの利用・開発に関する契約を3類型に整理している。

類型	内容（別添6 p.182 の記述より）
類型1：汎用的AIサービス利用型	AI利用者が、AI提供者の提供する汎用的AIサービスを利用するケース
類型2：カスタマイズ型	他のベンダが提供する汎用的AIサービスに対して、独自に開発した付加的な機能（非AIモデル）を組み合わせ、カスタマイズサービスとして提供するケース
類型3：新規開発型	AI利用者がAI開発者・AI提供者と提携して独自のAIシステムを開発・利用するケース

**類型2が、本稿が扱っている状況である。**既存の生成AIサービスの上に自社で作った機能を載せ、それを顧客に渡す。国の文書には、すでにこの型の記述がある。

〈ここで3点、断っておく。**(1) 「外販した瞬間にAI提供者になる」という判定基準は、公的文書に存在しない。あるのは定義文と事例であって、どの時点で該当するかを判定する手続的な基準は置かれていない。(2) 同ガイドラインは自らを「非拘束的なソフトロー」と位置づけている。法令上の遵守義務の話ではない。(3) 同ガイドラインが対象とする「AIシステム」は、自律性と学習機能を要素に含むものと定義されている。**ノーコードで作った、生成AIを呼び出さない業務アプリは、そもそもこのガイドラインの射程外である可能性が高い。「自作アプリは全部これの対象」という読み方は正確ではない〉

使う側と提供する側で、求められることがどう違うか

同ガイドラインは、AI利用者（第5部）とAI提供者（第4部）で章を分け、それぞれに求められる事項を並べている。**並べて読むと、境目で何が増えるかがはっきりする。**以下は本編 p.37〜40 の項目を編集部が対照表に組み直したものである（項目名は原文の見出しによる）。

	🟦 AI利用者でいるあいだ	🟥 AI提供者に回った後
基本の立ち位置	提供者が定めた利用上の留意点を遵守し、設計において想定した範囲内で利用する	開発者が意図している範囲で実装し、正常稼働及び適正な運用を継続する
入力するもの	個人情報・機密情報を不適切に入力しない	—
出す前に	—	リスク対策／適正利用に資する提供／バイアスへの配慮／プライバシー・バイ・デザイン／セキュリティ・バイ・デザイン／システムアーキテクチャ等の文書化
出した後に続くこと	—	適切な目的で利用されているかを定期的に検証／プライバシー侵害への対策／脆弱性への対応／ステークホルダーへの情報提供／サービス規約等の文書化

利用者の側にいるあいだ、義務はおおむね「決められた範囲の中で使う」に収まる。範囲を決めているのは他人である。

提供する側に回った瞬間、**その範囲を決めるのが自分になる。**文書化し、規約を作り、脆弱性に対応し、更新内容とその理由を伝え、適切に使われているかを定期的に検証する——これらは、渡した後もずっと続く。

〈同ガイドラインが挙げる「情報提供」の中身には、AIを利用しているという事実、予見可能なリスクとその緩和策、出力やプログラムが変化する可能性、不具合の原因と対応状況、更新を行った場合の更新内容とその理由などが含まれる（本編 p.38〜39）。作った本人だけが分かっている状態では、この説明ができない〉

**一番効くのは、たぶん「文書化」と「定期的な検証」である。**自作アプリは、作った当人の頭の中に仕様がある状態で動き出す。社内で使っているうちは、その人に聞けば済む。社外に出した後は、聞ける相手がいなくなった時点で説明できなくなる。

契約を結べば安心、とはならない

では契約書を作ればよいのか。ここについて、国の文書は率直である。

別添6は、AIのバリューチェーンが複雑化したことを述べたうえで、こう書いている。

現状、事故発生時にどの主体がどのような責任を負うかについて明確な基準はなく

（別添6、p.184）

そして、契約の限界について、本稿で最も重い一文が続く。

契約で定めることができるのは、契約の当事者限りでの責任の分担に限定される。

（同 p.184）

同じ段落は、契約の当事者以外から責任を追及された場合、AIのバリューチェーンに連なる者はすべて、一定の説明を求められる立場に立つ可能性があるとしている。

〈**これは「契約を作っても無駄」という意味ではない。**当事者間のリスク分配は契約でしか決められない。そのうえで、契約の外にいる人——たとえば顧客の、そのまた先にいる人——からの問いには、契約が答えてくれない、という話である〉

別添6は、事故発生リスクとの関係で契約上留意しておくと有益な事項として3点を挙げている。要約すると、①考えうるリスクを洗い出して誰がどの責任を負うかを定めておくこと、②事故時に各当事者が自分の関与を合理的に説明できるようにしておくこと、③その説明を裏づける客観的な根拠を契約の前後で整理しておくこと——である。同時に、ログ等の開示はセキュリティや競争力とのトレードオフになりうる点にも触れている。

リスク移転の選択肢として、損害保険の活用にも言及がある（別添6 p.185、およびIPA手引書 2.4.5節）。

〈契約の実務面については、経済産業省が2025年2月に『AIの利用・開発に関する契約チェックリスト』を公開しており、別添6もこちらを参照するよう指示している。2019年の『AI・データの利用に関する契約ガイドライン 1.1版』は生成AI登場以前の文書であり、そのまま最新の指針として読むと誤る。なお、受託したソフトウェアの不具合についての責任（契約不適合責任）は、AI固有の話ではなく民法の一般則である。中小機構のJ-Net21に公的な解説がある〉

では、IT担当者のいない会社はどうするか

ここまでを読むと、社外に出すのをやめたくなるかもしれない。それは本稿の意図ではない。

IPAの手引書は、背景の章でこう書いている。

予算・リソース・ビジネススピードの制約が大きい企業にとって、大規模なガイドラインをそのまま適用することは現実的ではない。

（IPA 手引書 1.1、p.6）

そして対策の章には、「全部やる」か「やめる」かの二択ではない第三の道が書かれている。リスク評価が中程度であれば、**自社のリソース制約を踏まえて優先度の高い対策を選び、講じられない対策については「残存リスクとして明示・管理する」**という扱いである（同 p.59）。評価が低ければ、最低限の人的統制のうえで受容することも合理的な選択だとされている。

**ここがいちばん実務的な結論だと当社は考えている。**やらないことを、やらないと決めて、書いて残す。何も決めずに放置するのとは、事故が起きた後の立場がまったく違う。前節の「合理的な説明」につながるのは、この記録である。

〈ここから先は編集部の整理である。IPA・総務省・経産省の文書を、10〜50名・IT担当者なしの会社が実行できる粒度に落としたものであり、公的文書にこの形で書かれているわけではない〉

出す前に決めておく5つ

1. これは誰のものか。 作った個人のものではなく会社のものである、という確認。退職・異動で説明できる人がいなくなる前に決める
2. 何を入れてよくて、何を入れてはいけないか。 顧客の個人情報を通すかどうかで、必要なものが変わる
3. 止め方を決めておく。 IPAは初動措置として、ロールバック、停止（キルスイッチ）、ネットワークからの遮断を挙げている（別添5、p.178）。「どうやって止めるか」を、止めたくなる前に決めておく
4. 誰が直すか。 作った本人が不在のときに誰が対応するか。外に出す前に、答えが「いない」ではいけない
5. 相手にどう伝えるか。 AIを使っていること、出力が変わりうること、どこまでを保証しないか。規約という形でなくとも、書いたものが要る

出した後に続く3つ

1. 使われ方が変わったら、評価をやり直す。 提供範囲が「中」から「高」に動いた時点で、必要な水準が変わる
2. 変更の履歴を残す。 何をいつ変えたか、なぜ変えたか。事故が起きてから思い出すのは無理である
3. やらないと決めたことを、書いて残す。 残存リスクの明示。これが前節の「合理的な説明」の材料になる

補足 — シャドーAIの議論と、どこが違うか

「勝手に使う」問題については、W32号で扱った。参考として、角川アスキー総合研究所が2026年8月に公開した『AI白書2026』の独自調査では、会社公式でないAIツールの業務利用経験が管理職 46.5%、全社共通ガイドラインを整備済みの企業に勤める回答者でも 46.9% という結果が出ている。

〈この調査の対象は上場企業または従業員300人以上の非上場企業に勤務する人（調査実施 2026年4月24〜25日、n=310、スクリーニング n=10,000 から抽出）。10〜50名の会社に直接あてはめることはできない。サブグループごとの分母は発表本体に記載がなく、n=310 を複数軸で分割した値である点にも留意が必要である。本稿はこれを「ルールを整備した大企業でもこの水準」という下限の目安としてのみ用いる。なお、中小企業を対象にシャドーAIを直接測定した2026年の一次調査は、本稿の調査範囲では見つけられなかった〉

そのうえで、当社は**「勝手に使う」と「勝手に作る」は別の問題だ**と考えている。〈以下は編集部の見解である〉

	勝手に使う	勝手に作る
対象	既製のサービス	自分で組み上げたもの
責任を負う相手	提供しているベンダーがいる	いない（または、自分になる）
気づき方	課金や通信で表に出ることがある	表に出にくい
やめるとき	契約を切れば終わる	業務がその上に乗っている

使うのをやめるのは難しくない。**作ったものをやめるのは難しい。**すでに業務の一部になっているからである。だからこそ、作る前・出す前に線を引く意味がある。

まとめ

• 「データの線」「権限の線」はすでに語られている。残っているのは三本目、「誰が使うか」の線
• IPAは提供範囲を「特定のチーム・個人／社内全体／外部・不特定多数」の3段階で評価する軸を置いている（ただし自作アプリ・市民開発という切り口は持っていない）
• 社外に出すと、AI事業者ガイドラインの用語では「AI利用者」から「AI提供者」の側に移りうる。別添6の類型2（カスタマイズ型）が、この状況に名前を与えている。ただし該当性を判定する基準は公的文書に存在しない
• 提供する側に回ると、文書化・規約・脆弱性対応・情報提供・定期検証が自分の側で発生する。しかもそれは渡した後もずっと続く
• 契約で定められるのは当事者間の分担までである。それは国自身が別添6に書いている
• リソースが足りない会社の現実的な落とし所は、全部やることでも諦めることでもなく、やらないと決めたことを「残存リスク」として明示して残すこと
• 「入れていない状態」と同じく、「出してしまった後」も、測っておかないと説明できない

---

社内で動いているものを外に出すべきかどうか、その線引きも含めてご相談いただけます。

→ お問い合わせ

自社の現状をご自身で確認したい場合は、簡易診断もご利用いただけます。

→ AX / DX 簡易診断

AI導入の相談先そのものについては、「中小企業のAI導入は、どこに相談すればいいのか」で6類型に整理しています。