現場が作ったツールが業務データに触り始めたら。個人利用と法人利用の境界

現場が業務ツールを自分で作れるようになると、最初は手元の作業の効率化から始まります。
テキストの整形、表記の統一、ファイルの変換といったところで、ここは自由にやってもらって問題ありません。
問題が生まれるのは、便利さが伝わって次の段階に手が伸びたときです。

「せっかく作ったなら、結果を共有シートに書き込むようにしよう」「他の部署にも使ってもらおう」。
この瞬間に、社内ツールが業務データに触り始めてリスクの性質が変わります。

ということで、この境界をどこに置いてどう運用するかを整理していきます。
内製化そのものの全体像は社内AIツールの内製化。現場が自分で作れる組織にするまでにまとめてあります。

便利さがリスクに変わる境目は、書き込むかどうか

そのツール、いま「読むだけ」でしょうか、それとも「書き込む」でしょうか？
ここが最初の分岐点です。

何が変わるのかを整理しておきます。
手元で完結しているツールは、データが外に出ません。
作った本人が自分のファイルを処理しているだけなので、失敗しても影響はその人の作業に留まります。

社内データに書き込むツールになると、性質が変わります。
書き込み先を間違えれば他人のデータが壊れますし、処理の条件を間違えれば誤ったデータが蓄積します。
誰が書いたのか分からない状態になると、原因を追えなくなります。

さらに他の部署に配ったツールになると、作った本人の想定していない使い方が発生します。
想定外のデータを入れられて誤った結果が出る、あるいは業務判断の根拠として使われる、といったことです。

また、最も注意が必要なのが認証情報を持つツールです。
外部サービスと連携するために鍵を持たせると、その鍵が有効な範囲でできることが全部できてしまいます。
つまり境界は「作ったかどうか」ではなく、扱う情報とデータの流れで引くのが正確だと考えています。

線を引く場所として、実務でいちばん機能するのは「読むだけか、書き込むか」という基準です。

読むだけのツールは失敗してもデータが壊れませんし、誤った結果が出ても作った本人が気づいて直せます。
だから読む範囲の権限が本人の業務範囲に収まっていれば、自由にやってもらって構いません。

書き込むツールは別です。
一度書き込まれたデータは、元に戻すのに手間がかかります。
しかも壊れたことに気づくのが数週間後、というケースが起きます。

だから分岐点は「書き込みを始めたら一声かける」と決めます。
この基準は現場にも分かりやすく、判断で迷いません。

扱う情報で3分類し、第3階層は5項目で見る

いま作っているツール、3つの階層のどこに位置するか答えられるでしょうか？
読み書きの基準に加えて、扱う情報の性質でも分けます。
管理レベルを3つに整理します。

まず第1階層が、自分の手元のデータだけを扱うものです。
テキストの整形、表記の統一、ファイル形式の変換、差分の比較といったもので、データが自分の端末から出ないので自由に作ってよい範囲になります。

第2階層が、社内データを読むものです。
共有シートを集計する、社内文書を参照する、台帳から一覧を作る。
ここからは参照範囲と権限の確認が必要になるので、作る前に一声かけるルールにします。

第3階層が、社内データを書き換えるもの、または外部と連携するものです。
台帳を更新する、外部サービスに送信する、他部署に配る、認証情報を持つ。
影響が自分の手元で終わらないので、ここは推進チームか情シスのレビューを通す形にします。
作ったものを他部署へ配る段になると権限の設計が要りますし（現場が作ったAIツールを埋もれさせない。社内配布と権限の設計）、社外に出す場合は別の審査が必要になります（社内AIツールを社外に公開する時の審査フローとチェックポイント）。

この3分類を1枚にして配ると、現場は自分がいまどこにいるかが分かるようになります。
分からないから萎縮する、あるいは分からないから無自覚に第3階層に入る。
この両方の問題が減るからです。

第3階層でレビューする側が見る項目も決めておきます。
毎回同じ観点で見ると、判断が速くなります。

まず、どのデータを読み書きするかです。
対象の範囲と、個人情報や人事情報が含まれるかを見ます。

次が、認証情報をどこに置いているかで、ここが最も見落とされます。
コードに直接書かれている、共有フォルダのファイルに置かれている、という状態は後から追えません。

もう一つが誰が使えるかで、使える人の範囲がそのデータの閲覧範囲と一致しているかを見ます。
ここがずれると、権限管理を迂回する経路になってしまいます。
権限の設計そのものは内製環境の権限設定をどう整えるか。安全と速度を両立させるで個別に扱っています。

残る2項目が、失敗したときに戻せるかどうかと、止める手段があるかどうかです。
書き込む前のデータが残るか、記録が残るか。
想定外の動きをしたときに、誰がどう止めるかを決めておきます。
5項目に絞るのがコツで、10項目のレビューシートにすると申請する側もレビューする側も回りません。

申請・レビュー・棚卸しを回し、作り手を萎縮させない

「危ないから止めて」。
この一言で、内製化は止まります。

運用としては3つを回します。
まず申請で、第2階層は一声、第3階層はフォーム1枚です。
フォームの項目は先ほどの5つに、作る目的と対象業務を足した7項目にします。

あわせて返答期限を3営業日と決めて公表します。
ここが止まると、次から申請されなくなります。

次にレビューを、技術面と情報管理の2つの観点で見ます。
とはいえ全部を情シスに投げると詰まるので、推進チームが一次を見て、判断が難しいものだけ情シスに上げる構成が現実的です。

最後に棚卸しを四半期に一度行い、稼働しているツールの一覧を見直します。
見る項目は、何をするツールか・扱う情報の階層・保守担当・最終確認日の4つです。

使われていないものは止めます。
動いていることを誰も把握していないツールが、いちばん危険だからです。
この棚卸しが実質的な安全弁になります。

そして伝え方が、この施策の成否を分けます。
やってはいけないのが「危ないから止めて」という伝え方です。
これをやると作る人がいなくなるか、報告せずに作るかのどちらかになります。
後者のほうが危険です。

効く伝え方は3つあります。
一つが、第1階層を明確に「自由」と言うことです。
制約の話から入ると全部が制約に見えるので、「ここまでは自由に作ってください」を先に言います。
入口の作り方は現場が業務ツールを自分で作れる組織になる。内製化の入口設計にまとめてあります。

次が、第2・第3階層を「相談」と表現することです。
「申請」「承認」という言葉は重く聞こえるので、実務上は同じことでも「一声かけてください」「一緒に見ましょう」という言い方にします。

もう一つが、レビューを助けとして設計することです。
権限の設定、認証情報の置き場所、失敗時の戻し方は、作り手が知りたいことでもあるので、指摘ではなく、より安全に作るための支援として渡すと、次から自分で相談に来るようになります。

あわせて、過去に作ったものを咎めないと明言します。
「これまでに作ったものがあれば、内容は問わないので一覧に載せてください」と言う。
ここを言わないと、既にあるものが出てきません。

情シスとの関係設計

この領域は、情シスとの合意なしには進みません。
「勝手に作られると困る」という懸念は正当なものです。
うまくいく構図は、情シスを審査役ではなく環境の提供者に置くことです。

第1階層で自由に作れる環境を情シスが用意し、第2・第3階層に来たものだけレビューする形です。
この形にすると、情シスの負荷はむしろ下がります。
これまで「作ってほしい」という依頼を全部引き受けていたものが、「見てほしい」という相談だけになるからです。
依頼の総量が減るぶん、情シスにとっても悪い話ではありません。

推進担当が最初にやるべきは、この構図を情シスと合意することです。
ここが握れていないと、現場が作ったものが後から止められて、二度と作られなくなります。

よくある失敗

まず、全面禁止にする失敗です。
内製化が止まり、AI活用が個人の作業効率化のところで頭打ちになります。

次が、線を引かずに自由にさせる失敗です。
第3階層に無自覚に入り、認証情報の管理が甘い状態のまま全社に広がってしまいます。

もう一つが、申請フォームを重くする失敗です。
20項目のフォームは提出されないので、7項目に絞ります。

残る2つが、棚卸しをしない失敗と、情シスに相談しないまま進める失敗です。
誰も把握していないツールが動き続けて止まっても気づかれませんし、後から止められて現場の信頼を失います。

ルールと環境は、同時に整えて初めて機能する

ここまで書いてきたとおり、この領域はルールだけでも環境だけでも成立しません。
第1階層を自由にすると決めても、データが外に出ない環境が用意されていなければ現場は判断できません。
逆に環境を整えても、3分類が配られていなければどこまでやってよいか分からず萎縮します。

両方を同時に整えるには、情シス・法務・現場・推進担当の合意が必要です。
ここを社内だけで進めると、それぞれの立場から出てくる懸念の調整に時間がかかり、その間ずっと無管理の状態が続くことになります。

ルールの側を誰が書き、どの段階で法務が確認するかという進め方は、生成AIの社内ルールの作り方。ガイドラインの項目サンプルと守れる環境で順に追っています。

私たちが提供しているAI活用支援では、ルールの策定と内製環境の整備を並行して進める形をとっています。
現場は動き始めているのに管理の設計が追いついていない、という場合は、進め方の参考になります。

分岐点は「読むだけか、書き込むか」に尽きる

現場が作ったツールのリスクは、作ったかどうかではなく扱う情報とデータの流れで決まります。
実務で機能する分岐点は「読むだけか、書き込むか」です。

管理は3階層で、第1階層（手元のデータのみ）は自由、第2階層（社内データを読む）は一声、第3階層（書き換える・外部連携・他部署配布・認証情報を持つ）はレビュー。
レビューの観点は5項目に絞ります。

伝え方も成否を分けます。
第1階層を先に「自由」と言い、第2・第3階層は「相談」と表現して、レビューは支援として渡します。
過去に作ったものは咎めないとも明言します。

3分類を1枚にまとめて配り、すでに作られているツールを洗い出すところから着手します。