社内AIツールを社外に公開する時の審査フローとチェックポイント

社内で作ったツールが評判になると、「取引先にも使ってもらえないか」「顧客向けのページに置けないか」という相談が必ず出てきます。
作った本人からすれば自然な発想ですし、実際に価値がある場合も多いです。

ただ、社内で動いているものと社外に公開するものの間には、設計と責任の面で大きな差があります。
ここを軽く見て公開すると後から止めることになりますし、止めた時点ですでに相手先へ迷惑がかかっています。
社内ツールを社外に出すときの審査フローを、ここで整理していきます。

その手前にある社内での境界線は現場が作ったツールが業務データに触り始めたら。個人利用と法人利用の境界にまとめてあります。

社内と社外では、4つの前提が変わる

社内で動いているツールを、そのまま社外に出して大丈夫でしょうか？
変わる前提は、大きく4つあります。

まず、使う人を選べなくなることです。
社内なら「この操作はしないでください」と伝えれば通じますが、社外の利用者にはそれが伝わらないので、想定外の使い方をされる前提で設計しておく必要があります。

次に、止められなくなることです。
社内なら「不具合が出たので今日は使わないでください」で済みますが、取引先が日次の業務に組み込んでしまった後では、そう簡単には止められません。

3つ目が、責任の所在が変わることです。
社内の失敗は社内で収まりますが、社外に出したものが誤った結果を出し、それを根拠に相手が判断した場合は責任の議論になります。

最後が、費用が読めなくなることです。
処理量に応じて課金される構成だと利用者数が読めない分だけ費用も読めず、想定を超える利用が来たときに止まるか請求が跳ねるかのどちらかになります。

費用側の設計はAI利用の従量課金をコスト設計する。予算とガードレールの決め方で個別に扱っています。

つまり、この4つを踏まえると確認すべき項目が決まってきます。

公開の可否は、7項目と3者承認で決める

審査では、何を確認すればよいのでしょうか？
見るべきことは、7つに絞れます。

まず「誰が使うのか」で、特定の取引先なのか不特定の一般なのかによって、特定の相手に限定できるならリスクは大きく下がります。
次に「何を入力させるのか」で、個人情報を入力させるなら扱いの根拠と保管の設計が必要になりますし、入力させないで済む設計にできないかを先に検討したほうが早いです。
渡す前の加工については個人情報を含む文章をAIに渡す前に。マスキングを標準工程にするで扱っています。

3つ目が「入力されたデータはどこに残るのか」で、残す必要がないなら残さない設計にして、残す場合は保管場所・保管期間・アクセスできる人までを決めておきます。
4つ目が「認証があるかどうか」で、誰でも開けるURLなのかログインが必要なのかによって、誰でも開ける状態にするならそこに置く機能のほうを限定します。
5つ目が、誤った結果を返した場合の影響で、参考情報として使われるのか業務判断の根拠になるのかによって、後者なら免責の表示と最終確認は人が行う旨の明示が必要になります。

6つ目が費用の上限で、想定利用数と1件あたりの処理量から試算して、上限に達したときに止まるのか待たせるのか、その動作を決めておきます。
7つ目が、止める手段と担当です。
「誰がどうやって止めるのか」「担当が不在のときはどうするのか」、ここを決めていない公開は認めないという線を引いておきます。

判断を1人に負わせないのも原則で、承認は3つの観点で見ます。
技術の観点では、認証・権限・認証情報の管理・想定外の入力への耐性を見ます。
情シスか開発が分かる人が担当する部分で、権限の設計そのものは内製環境の権限設定をどう整えるか。安全と速度を両立させるにまとめてあります。

法務の観点では、免責の表示、利用規約が必要かどうか、相手先との契約に抵触しないかを見ますし、個人情報を扱う場合はここの確認が必須になります。
情報管理の観点では、入力されたデータの保管と削除、社内の情報区分との整合を見ます。
情報区分そのものは生成AIに入れてはいけない情報とは。社内ルールを3段階で線引きするで扱っています。

3者が別部門だと調整に時間がかかるので、申請から回答までの期限を10営業日以内と決めておきます。
期限がないと申請が滞留して、現場が非公式に公開するという事態が起きます。

承認者と期限を先に決める作りは社内ルールの判断者や例外申請と同じ考え方なので、生成AIの社内ルールの作り方。ガイドラインの項目サンプルと守れる環境と並べて読むと、審査の置きどころが見えてきます。

申請シートは11項目、公開後は数値で止める

申請書には、何を書けばよいのでしょうか？
現場が書く申請書は、7項目に4つを足した11項目で構成します。

ツールの名称、目的と対象業務、作成者と保守担当、公開の範囲（特定先か一般か）、入力させる情報、データの保管、認証の有無、誤った結果の影響と免責表示、費用の試算と上限、止める手段と担当、希望する公開日の11項目です。
書けない項目は空欄で出してよいとします。
全部埋めてから出すルールにすると、そもそも着手されないからです。
空欄を埋めるのが審査側の最初の仕事になりますし、シートは3ページではなく1枚に収めます。

公開した後の運用も、申請の時点で決めておきます。
監視するのは利用件数・エラーの発生・費用の消費の3項目で、いずれも週1回見る程度で足ります。

そのうえで、停止基準を数値で決めます。
「エラー率が一定を超えたら止める」「費用が上限の8割に達したら止める」といった形です。
基準を数値にしておかないと止めるかどうかの議論に時間がかかり、その間に状況が悪化します。

止めたときの連絡先も、あらかじめ用意します。
利用している相手先に連絡する経路を公開前に決めておくということで、ここが決まっていないとそもそも止められません。

あわせて四半期に一度、公開しているものの一覧を見直し、使われていないものは公開をやめます。
公開したままのツールが増えていく状態は、管理できていないのと同じです。

審査を通しやすくする現実的な工夫として、公開範囲を特定先に限定するという手もあります。
一般公開ではなく、取引先のうち特定の相手だけがログインして使える形にするということです。
こうすると想定外の使い方の範囲が狭まりますし、誤った結果が出たときの連絡もつきますし、費用のほうも読めるようになります。

まず1社で使ってもらうという段階を置くと、公開後に見つかる問題を小さいうちに拾えます。
1社で3か月動かして問題がなければ、そこから範囲を広げます。
この段階を踏むと審査する側も判断しやすくなりますし、一般公開が目的の場合でもこの段階を経由したほうが結果的に早いことが多いです。

よくある失敗は、同じ形で繰り返される

どこでつまずくことが多いのでしょうか？
審査でつまずく場面は、だいたい決まったパターンに収まります。

まず、「社内で動いているから大丈夫」と判断してしまうことです。
使う人を選べない、止められない、責任が変わるという意味で、そもそも前提そのものが違います。

次に、止める手段を決めないまま公開することです。
問題が起きたときに止められず、被害が広がります。

3つ目が、個人情報を入力させる設計にしてから審査に出すことです。
入力させないで済む設計を先に検討したほうが、審査そのものが軽くなります。

また、申請書を3ページにすることも失敗のもとです。
書かれないまま非公式な公開が起きるので、1枚に収めます。

最後が、審査の期限を決めないことです。
滞留すると、現場が審査を通さずに公開してしまいます。

継続提供するなら、事業設計とセットで考える

そのツールを継続的に提供するべきでしょうか？
ここまでは公開の審査の話ですが、実務ではもう一段先の判断が必要になります。

社内ツールとして作ったものは、作った本人が使い方を知っている前提で成り立っています。
社外に継続提供するとなると、問い合わせ対応、不具合修正、機能追加、提供を止めるときの手続きまで必要になり、これはもう業務ではなく事業の運営です。

もちろん、同じ課題を持つ会社が他にもあるかもしれず、事業として成立する可能性はあります。
ただ、社内ツールの延長のまま始めると、本業の業務まで巻き込んで止まります。

私たちが提供しているAI新規事業支援では、事業として成立するかの見極めから、PoCやMVPとしての作り直しまでを一緒に進めています。
社内で作ったものに手応えがある場合は、考え方の参考になるかもしれません。

審査を通す近道は、まず1社に絞ることです

社内ツールと社外公開の差は、「使う人を選べない」「止められない」「責任の所在が変わる」「費用が読めない」の4点です。

審査で見るのは7項目で、誰が使うか、何を入力させるか、データがどこに残るか、認証の有無、誤った結果の影響、費用の上限、止める手段と担当を確認します。
承認は技術・法務・情報管理の3者で見て、回答期限を決めておきます。

申請シートは11項目・1枚に収め、空欄で出してよいとします。
公開後は利用件数・エラー・費用を週1回見て、停止基準を数値で決めておきます。

最も現実的な工夫は、まず特定の1社に限定して3か月動かすことです。
一般公開を目指す場合でも、この段階を経由したほうが早いはずです。

公開したいツールについて、止める手段と担当は、もう決まっているでしょうか？