現場の社員がAIで業務アプリを作るときの注意点｜情報管理と運用のルール

AIに文章で指示するだけで、簡単な業務アプリの画面やプログラムを作れるようになってきました。プログラミングの専門知識がない現場の社員でも、日報の集計や在庫の管理表のような小さなアプリを自分で作れる場合があります。業務をよく知る人が自分で必要な道具を作れることは、大きな利点です。

一方で、情報システムの担当者が知らないところでアプリが増えると、情報の扱いや保守の面で問題が起きることがあります。この記事では、現場の社員がAIで業務アプリを作るときに注意したい点と、会社として決めておきたいルールを説明します。

現場でアプリを作れるようになった背景

これまで業務アプリを作るには、プログラミングの知識が必要でした。最近では、作りたいアプリの内容を文章で伝えると、AIが画面やプログラムの案を作る仕組みが使えるようになっています。画面の部品を並べるだけでアプリを作れるノーコードツールに、AIの機能が加わったサービスもあります。

こうした仕組みを使えば、表計算ソフトで管理していた作業を、短い時間で簡単なアプリに置き換えられる場合もあるでしょう。ただし、動くアプリを作れることと、業務で安全に使い続けられることは別の問題です。作る前に、どのような問題が起こりうるかを知っておきましょう。

起こりやすい問題

現場で作ったアプリで起こりやすい問題の一つは、秘密の情報の扱いです。たとえば、社内システムに接続するためのパスワードや鍵を、プログラムの中にそのまま書き込んでしまう場合があります。アプリを共有したときに、その情報も一緒に広がってしまうおそれがあります。

二つ目は、権限の設定がないアプリです。作った本人だけが使うつもりのアプリを部署内で共有するうちに、本来は見られない人が顧客情報を閲覧できる状態になることがあります。

三つ目は、作った人しか中身が分からない状態です。作った社員が異動や退職をすると、不具合が起きても直せる人がいなくなります。業務がそのアプリに依存していると、業務そのものが止まりかねません。

四つ目は、計算や処理の誤りに気づきにくいことです。AIが作ったプログラムには、誤りが含まれることがあります。見た目は正しく動いていても、特定の条件で集計を間違えるといった問題が残るかもしれません。

アプリの使われ方で管理の度合いを分ける

すべてのアプリに同じ厳しさのルールを当てはめると、現場で作る利点が失われます。アプリの使われ方と扱うデータによって、管理の度合いを分けるとよいでしょう。目安を表にまとめました。

個人用のアプリでも、顧客の個人情報や機密情報を扱う場合は、部署内や全社向けと同じ扱いにします。区分は、利用者の範囲と扱うデータのうち、より厳しいほうに合わせることが大切です。

作るときに守りたいルール

現場でアプリを作る社員に向けて、会社としていくつかのルールを決めておきましょう。

まず、パスワードや鍵などの秘密の情報は、プログラムの中に書かないことです。会社が用意した安全な保管場所から読み込む方法を使います。AIに指示を出すときも、本物のパスワードや顧客のデータを指示文に貼り付けないようにしてください。秘密情報の扱いはAIでコードを書くときの秘密情報の扱い方でも説明しています。

次に、アプリを作ったら、管理者と用途を一覧に登録することです。作った人と用途、扱うデータが分かれば、問題が起きたときに対応できます。作った社員が異動するときは、管理者を引き継ぐ手順も決めておきます。

最後に、アプリの使い方と仕組みを簡単な文書に残すことです。AIに作らせたプログラムでも、アプリの目的やデータの読み込み元を書いておけば、別の人が引き継ぎやすくなります。

使うAIのサービスも、会社が認めたものに限るのが安全です。社員が個人で契約したサービスに業務のデータを入力すると、情報の扱いを会社として把握できなくなります。会社として使ってよいサービスと、その中で扱ってよい情報の範囲を示しておきましょう。

公開前の確認と、公開後の運用

部署内や全社で使うアプリは、公開する前に確認を受ける仕組みにしましょう。確認する人は情報システムの担当者が理想ですが、社内にいない場合は外部の専門家に相談する方法もあります。確認したいのは、権限の設定や秘密の情報の扱い、扱うデータの範囲と処理の正しさです。

処理の正しさは、実際のデータに近いテスト用のデータで確かめます。手作業で計算した結果とアプリの結果を比べると、誤りに気づきやすくなります。

公開したあとも、使われ方を定期的に確認することが必要です。使われなくなったアプリは停止し、扱っていたデータを整理しておくと、情報が放置されることを防げます。会社として社内のAI環境を整える場合は、現場で作るアプリもその中で管理できる形にしておくと、権限や記録をまとめて扱えます。

備品貸出アプリを試作する例

架空の会社で、総務担当者が表計算で管理していた備品の貸出をアプリにする場面を考えます。AIに画面を作らせる前に、「備品名」「借りる人」「貸出日」「返却予定日」「返却済みか」を管理する、と対象を決めます。社員の評価や住所など、貸出管理に不要な情報は持たせません。

最初は架空の社員名と備品で試します。試作品のURLを知っている人だけが利用する状態でも、本人確認や閲覧制限があるとは限りません。実際の社員情報を入れる前に、誰が画面とデータへアクセスできるかを確認します。

画面を操作して一件登録できたことだけでは、公開の確認は終わりません。誤操作、権限の異なる利用者、通信が切れた場合も試します。データの取扱いが複雑なら、早い段階で開発担当者に確認を依頼したほうが、完成後の作り直しを減らせます。

試作品から実務用へ移す順番

まず、業務担当者が実際の手順と画面を照合します。貸出中の備品をどう扱うか、返却日が過ぎたら誰が連絡するかなど、日常の例外を整理します。次に、管理者がログイン、閲覧範囲、保存先、バックアップを確認します。

その後、小さな利用範囲で並行して試し、記録が正しく残ることを確認します。並行運用する場合は、表計算とアプリのどちらを正式な記録とするかを決めます。双方に異なる更新が入ると、何が正しいか分からなくなるためです。

利用を切り替える際は、既存の貸出データを移す担当者と、件数や状態を確認する担当者を決めます。表示がきれいになっても、貸出中の備品が移行から漏れていれば業務では使えません。

作成者以外が運用できる台帳を残す

アプリごとに、目的、利用部署、管理者、データの保存先、利用する外部サービス、支払い担当、停止方法を記録します。接続キーそのものを台帳へ貼るのではなく、会社が管理する保管場所と更新担当を記載します。

引き継ぎでは、作成者の説明を聞くだけでなく、別の担当者が利用者の追加、データの出力、停止の操作を試します。作成者の個人アカウントでしか変更できない箇所があれば、会社として管理できる状態へ直します。秘密情報の扱いはAIコーディングでの秘密情報管理も参考になります。

運用を止めて見直す条件

権限のない人が情報を見られる、保存したはずのデータが欠ける、同じ備品が重複して貸し出されるといった問題が見つかった場合は、対象の操作を止めて原因を確認します。業務を続けるための一時的な管理方法も、あらかじめ決めておきます。

利用されなくなったアプリも、放置せず整理します。必要な記録を会社の保存先へ移し、外部連携と利用権限、継続する費用を確認してから停止します。作る段階で終了時の扱いまで決めておくと、小さなアプリが管理されないまま増えることを防ぎやすくなります。

まとめ

現場の社員がAIで業務アプリを作れるようになったことは、業務を改善するうえで大きな利点です。その一方で、秘密情報の扱いや権限の設定、作った人しか分からない状態といった問題が起こりえます。アプリの使われ方と扱うデータで管理の度合いを分け、作るときのルールと公開前の確認を決めておきましょう。

e-Grantsでは、社員がブラウザで使えるAIワークスペースや、権限・承認の仕組みを含めた社内インフラの構築を支援しています。現場でのAI活用を会社として管理できる形に整えたい場合は、AIを使える社内インフラの構築をご覧ください。