AIで作った社内ツール、本番導入前チェックリスト12項目—公開してよいかを判断する

Claude CodeやChatGPTを使って、エンジニアではない社員が業務ツールを作る。少し前まで数十万円の見積もりが出ていたものが、数時間で動く。これは実際に起きていることで、悪いことでもない。なお、チャット型のAIと違って手元のファイルやコマンドまで触れるツールは注意点が変わるので、そこはClaude Codeで業務ツールを作るときの注意点に分けて書いた。問題はその次にある。作ったツールを、部署に配って、顧客情報を入れて、日常業務に組み込んでよいのか。この判断を、作った本人が1人で背負っているケースが増えている。この記事では、本番で使い始める前に確認する12項目と、その結果をどう判断に変えるかを整理する。

「動いている」は、判断材料にならない

システムの不具合は、たいてい自己申告してくれる。エラーが出る、画面が真っ白になる、データが表示されない。誰かが気づいて、報告が上がる。

一方、この記事で扱うリスクはそうならない。APIキーがコードに直接書かれていても、ツールは正常に動く。閲覧権限の設定が緩くても、使っている本人の画面には何も起きない。入力した情報が外部サービスに送られていても、業務は滞りなく進む。

不具合と違って「動いてしまう」ため、事故が起きるまで社内の誰も気づけない。これが、AI内製ツール特有の難しさになる。だから「しばらく使ってみて問題なければ本番へ」という進め方が機能しない。使っている期間の長さは、安全性の証明にならない。そもそも社内で回すのと外に公開するのでは求められる水準が違うので、その境目の引き方は社内利用と本番公開の境目はどこかで整理している。

そもそも確認が必要なのはどんなツールか

全部のツールを厳密にチェックする必要はない。自分だけが使い、顧客情報も個人情報も扱わず、壊れても手作業に戻せるものなら、そのまま使って構わない。確認が必要になるのは、次のどれかに当てはまるときだ。

• 顧客情報・従業員の個人情報・取引条件など、外に出てはいけない情報を扱う
• 作った本人以外が使う（部署に配る、他部門と共有する）
• 社外の人が触る（取引先が入力する、URLを知っていれば開ける）
• 止まると業務が止まる（受発注・請求・勤怠など、代替手段がない）

このいずれかに該当したら、以下の12項目を確認する。逆に言えば、該当しないツールに時間をかける必要はない。なお1つ目については、患者情報のように法律上「要配慮個人情報」として別扱いになるものもある。医療・介護の現場で線引きを考える場合は、クリニック・介護施設がAIに患者情報を入れる前にのほうが実態に近い。

チェックリスト12項目

観点1｜情報がどこに置かれているか

1. APIキー・パスワード・接続情報が、コードに直接書かれていないか。環境変数や設定ファイルに分離され、そのファイルが共有・公開の対象から外れているかまで見る。AIに「環境変数から読む設計にして」と指示していても、動作確認のために一時的に直書きしたものが残っていることがある。探し方と、見つけてしまったときの手当てはAPIキーの直書きは何が危ないのかにまとめた。
2. データの保存先がどこか、説明できるか。自社の管理下か、外部サービスか。外部なら、どの事業者の、どの国のサーバーか。無料枠のサービスは、提供者が変わったり終了したりする前提で見る。
3. 入力した情報が、AIサービス側の学習に使われない設定になっているか。法人向けプランでは学習に使わない設定が可能なサービスが多いが、個人アカウントの無料プランのままだと既定で使われる場合がある。契約形態と設定の両方を確認する。ただ、「学習に使われない」設定にしても残るリスクが3つあるので、この項目だけで安心しないほうがいい。

観点2｜誰が見られるか

4. URLを知っていれば誰でも開ける状態になっていないか。社内向けのつもりでも、認証をかけていなければ外部から到達できる。検索エンジンに拾われるケースもある。
5. 閲覧できる範囲が、業務上必要な人だけに絞られているか。作りやすさを優先して全員に権限を配ったまま運用が始まると、本来見えてはいけない情報が全社員に見える。人事情報や取引条件が入っている場合は特に確認する。よく出てくる崩れ方は3パターンに絞れるので、棚卸しの手順とあわせて社内ツールの権限設定、顧客情報が全社員に見えていませんかで扱った。
6. 退職者・異動者のアクセスを止める手順が決まっているか。誰が権限を外すのか、どのタイミングで、何を見れば残っている権限が分かるのか。この3つが決まっていないと、実際には止められない。

観点3｜壊れたときどうするか

7. データのバックアップがあり、戻せることを実際に試したか。「バックアップを取っている」だけでは足りない。戻す手順を一度通してみて、戻ることを確認する。「取っている」と「戻せる」は別物で、どこまで戻るかを一度試す手順を書いている。
8. 誤操作でデータが消えたとき、どこまで戻るかが分かっているか。1日前か、1週間前か。その間の業務データが失われることを受け入れられるかで、必要な対策が変わる。
9. 止まったときの代替手段があるか。手作業に戻せるのか、戻せないのか。戻せないなら、それは基幹業務であり、内製ツールで持つべきかの判断からやり直す必要がある。

観点4｜作った人がいなくなったらどうするか

10. 何をするツールで、どう動いているかを書いた資料があるか。長い設計書は要らない。目的・使う人・データの流れ・外部サービスとの接続先、この4つがA4一枚にあれば十分機能する。
11. 作った本人以外が、変更や再起動をできるか。アカウント・パスワード・デプロイ手順が個人に紐づいていないか。個人のGoogleアカウントで動いているツールは、その人が抜けた瞬間に触れなくなる。この状態に向かっているかは事前に兆候が出るので、引き継げなくなる5つの兆候と照らし合わせてみてほしい。
12. ツールが増えたとき、誰が管理するかが決まっているか。1つ目は本人が管理できる。5つを超えたあたりで、誰も全体を把握していない状態になる。増える前に決めておく。すでに数が分からなくなっている場合は、内製ツールの棚卸し手順のほうから先に着手したほうが早い。

結果をどう判断に変えるか

12項目すべてに「はい」が付くまで公開しない、という運用は現実的ではない。中小企業でそれをやると、いつまでも公開できない。判断の基準はもっと単純でいい。

重要なのは、リスクをゼロにすることではない。残っているリスクを言語化して、それを受け入れると決められる状態にすること。決められれば、それは判断として成立している。決められないまま公開するのが、いちばん危ない。

社内で判断できないときの現実的な進め方

社内にエンジニアがいない会社で、この12項目を1人で判断するのは無理がある。とはいえ、全部を監査してもらう必要もない。順番はこうなる。

1. 作った本人以外がチェックする。技術が分からなくても、12項目を読み上げて答えてもらうだけで、答えられない項目が浮かび上がる
2. 「わからない」が残った項目だけを特定する。たいてい2〜3項目に収まる
3. その項目だけを外部の経験者に見てもらう。全体のコードレビューではなく、範囲を指定して確認してもらう

この進め方なら、確認の範囲が限定されるのでコストも時間も抑えられる。逆に「一式まとめて見てください」と丸ごと渡すと、時間も費用も膨らむわりに、判断に必要な答えが返ってこないことが多い。

よくある質問

Q. 社内だけで使うツールでも確認は必要ですか？

扱う情報によります。顧客情報や個人情報を含まず、止まっても手作業に戻せるなら、細かい確認は不要です。ただし「社内だけ」のつもりが、URLを知っていれば外から開ける状態になっているケースは多いので、観点2の4番だけは確認しておくことをおすすめします。

Q. チェックにどれくらい時間がかかりますか？

作った本人が答えるだけなら30分程度です。答えられない項目を調べるところから始めると、内容によって数時間から数日かかります。時間がかかりそうな項目こそ、外部に投げる候補になります。

Q. すでに本番で使い始めています。今からでも間に合いますか？

間に合います。優先順位は、観点1（情報の置き場所）→ 観点2（閲覧権限）→ 観点4（引き継ぎ）→ 観点3（復旧）の順。観点1と2は、問題があった場合に過去にさかのぼって影響が出るため、先に確認してください。