生成AIの社内利用ルールというと、これまでは「機密情報を入力しない」「個人情報を不用意に入力しない」「AIの回答をそのまま利用しない」といった内容が中心でした。しかし、AIエージェント(人が一つひとつ操作しなくても、目的や条件に応じて処理を進めるAI)や、プログラムを書かずに作れるAI自動化が広がると、情シスが考えなければならない範囲も変わります。これから重要になるのは、生成AIを「使う」管理だけでなく、生成AIが「動く」ことを管理する視点です。
2026年8月17日、GoogleはWorkspace Studioについて、企業向けのセキュリティ管理機能の追加を発表しました。Workspace Studio自体はすでに提供されています。今回、情シスとして特に注目したいのは、作られた処理を管理・監査・停止するための仕組みが強化されたことです。あわせて、社外とのやり取りを含む処理の対応範囲も広がっています。
社員自身がAIを使った処理を簡単に作れるようになると、Excelマクロ、Access、RPAで繰り返されてきた「作った本人しか分からない」という問題が、より大きな規模で起こる可能性があります。そこで本記事では、AIエージェントを全面禁止するのではなく、情シスが最低限把握しておきたい「作った人・権限・止め方」という3つの視点から管理方法を考えます。
これまでの生成AIとAIエージェントは何が違うのか
ChatGPTやGeminiなどの生成AIを利用するときは、基本的に人が質問や指示を入力し、それに対してAIが文章を作成したり、情報を整理したりします。例えば「このメールを要約して」「会議メモからToDoを抽出して」と依頼し、その結果を人が確認して次の作業へ進むイメージです。
一方、AIエージェントやAIを組み込んだ自動処理では、大きな違いの一つとして、人が一つひとつ操作しなくても、条件に応じて複数の処理を進められる点があります。例えば、問い合わせフォームへの回答を受け取った後にAIが内容を分類・要約し、その結果をスプレッドシートへ登録して担当者へ通知する、といった処理です。人が起動してから後の工程だけを任せる使い方もありますが、情シスにとって重要なのは、人が見ていない時間帯に動くものがあることです。
この違いは情シスにとって重要です。AIが回答を表示するだけであれば、最終的な操作は人が行います。しかし、自動処理としてメール送信やファイル操作まで行うようになると、処理が実行されるたびに人が内容を確認するとは限りません。つまり、AIの回答品質だけでなく、AIがどのデータへアクセスし、どの操作を実行できるのかまで管理対象になります。
生成AIの導入初期は「どのAIサービスを利用してよいか」というサービス単位の管理が中心でした。今後はそれに加えて、承認済みサービスの中で社員が作成した自動処理についても把握する必要があります。
便利になる一方で「誰が作った処理なのか」が問題になる
AIによる自動化をプログラムなしで作れるようになること自体は、業務改善にとって大きなメリットです。毎日届く問い合わせメールの分類、定型的な報告書の作成、会議内容の整理、申請情報の転記などを業務部門自身で改善できれば、情シスがすべての自動化案件を開発する必要はありません。
一方で、作れる人が増えるほど管理対象も増えます。特に注意したいのが、処理そのものが担当者個人の業務知識やアカウントに依存しているケースです。
- 誰が作成した処理なのか分からない
- どのアカウントや権限で動いているか分からない
- どのファイルや顧客情報を参照しているか分からない
- どの宛先へメールやデータを送信しているか分からない
- 作成者が異動・退職した後も処理が残る
- 問題が発生したとき、情シスがすぐ停止できない
例えば営業担当者が、顧客から届いたメールをAIで要約して共有シートへ記録する自動処理を作ったとします。作成した本人には業務内容が分かっているため便利に使えます。しかし、半年後に担当者が異動すると、なぜその処理が必要なのか、どのデータを読んでいるのか、停止して問題ないのかを説明できる人がいなくなるかもしれません。
さらに、AIエージェントが外部へのメール送信やファイル共有まで行う場合、誤動作がそのまま情報漏えいや誤送信につながる可能性があります。だからこそ、AIエージェントの管理では「利用を許可したAI製品の一覧」だけでは不十分で、その中で何が作られ、何をしているのかまで見える状態が必要です。
ExcelマクロやRPAで起きたことの再来かもしれない
この問題は、AIによって突然生まれたものではありません。情シス担当者であれば、Excelマクロ、Access、RPAなどで似た課題を経験したことがあるのではないでしょうか。現場の担当者が便利な仕組みを作り、それがいつの間にか部門の重要業務を支えるようになります。
ところが、作成者が異動すると「このExcelは誰が作ったのか」「マクロの修正方法が分からない」「自動処理が止まったが、どのシステムにログインしているのか分からない」といった問題が発生します。便利な仕組みほど業務に定着するため、停止することも簡単ではありません。
AIエージェントも基本的には同じ構造を持っています。ただし、大きな違いが2つあります。1つは、プログラミングやマクロの知識がなくても自動処理を作れる人が増えること。これまでVBAやRPAのシナリオを作れる社員が一部だった会社でも、日本語での指示や画面操作だけで作れるなら、作成者の数は一気に増えるかもしれません。もう1つは、動いた記録が残っていないと、間違いに誰も気づけないことです。
そのため、今後のAI管理では「どの製品を許可するか」という入口の管理に加え、「製品の中で誰が何を作ったか」という運用段階の管理が必要です。
Google Workspaceでは「AIを管理する」仕組みが強化されている
この変化を具体的に示しているのが、冒頭で触れたGoogle Workspace Studioの発表です。繰り返しになりますが、作る機能そのものは以前から提供されています。今回強化されたのは、作られた処理を会社として管理・監査・停止するための仕組みです。管理コンソール向けの設定は2026年8月17日から表示が始まり、利用者向けの機能は8月20日以降、契約している設定によって順に反映され、おおむね9月中旬までには行き渡る見込みとされています。
今回のポイントは、AIを使った処理を作れることではなく、作られた処理を会社として管理できるようにする点にあります。理解の助けになるのが、「AIに社員証を持たせる」という考え方です。正確には、処理ごとに識別できる情報を持たせ、所有者とひも付けて追跡できるようにするイメージです。何をしたかを記録に残し、権限を絞り、必要なら止められるようにする。追加されたのは、おおむね次のような仕組みです。
| 追加された仕組み | 情シスから見た意味 |
|---|---|
| AIに固有のIDを持たせる | 社員証のようなもの。どの処理が動いたのか、所有者は誰かを追いやすくなる |
| 触れる範囲を管理する | 処理を停止したり、「この処理にはファイル保管庫を触らせない」といった許可を個別に取り消したりできる |
| 動きが記録に残る | いつ、誰の、どの処理が何をしたかを後から確認できる |
| 人の承認を挟める | 社外へデータを出すときなど、重要な処理の前に利用者の確認を必須にできる |
| 動いている最中の歯止め | 社外に出してはいけないデータが出ていくのを止める仕組みを、処理の実行時に効かせる |
例えば管理者は、すべての処理を一括で停止したり、特定の処理についてファイル保管庫などへの許可だけを取り消したりできます。また、記録には処理を識別する情報や所有者の情報を含められるため、「このメール送信を実行したのは誰のどの処理か」を追いやすくなります。
- 契約プランによって使える機能が異なります。特に、社外に出してはいけないデータの流出を止める仕組みは上位プラン限定です。「どのプランでも同じことができる」とは考えないでください。自社の契約で何が使えるかは、管理画面で確認が必要です。
- すべての機能が、既存の処理へすぐ適用されるわけではありません。一部は新しく作成された処理から順に適用され、既に動いている処理への対応は今後とされています。管理機能が追加されたからといって、社内の自動処理が自動的に全部管理下に入るわけではありません。
なお、管理画面上の日本語の項目名は環境や時期によって表記が異なる場合があります。本記事の名称は内容を説明するためのものですので、実際の設定時はご自身の管理画面の表示でご確認ください。
Microsoft 365を使っている会社も、同じ準備が必要です
ここまでGoogleの例を挙げましたが、これは特定のベンダーの話ではありません。Microsoftも、AIエージェントに人間のアカウントやアプリとは区別されるIDを持たせ、その動きを記録・管理していく方向で仕組みを用意しています。考え方はGoogleとほぼ同じで、「AIに社員証を持たせて、記録が残るようにする」というものです。
ただし、提供状況や必要なライセンスは機能ごとに異なり、今後も変わる可能性があります。Microsoft 365をお使いの場合は、自社の契約で何が使えるのかを公式のドキュメントと管理画面で確認してください。本記事で製品ごとの詳細を比較しても、読んだ頃には状況が変わっている可能性があります。
押さえておきたいのは、どの業務スイートを使っていても、遅かれ早かれ同じ話が来るということです。「社員が作った自動処理を、誰の権限で動かし、誰が管理するのか」という問いは、製品を選ぶ話ではなく、社内の運用を決める話です。
情シスが最低限把握したいのは「作った人・権限・止め方」
AIエージェントの管理項目を細かく決め始めると、利用目的、モデル、指示の内容、接続先、記録の保管、データ分類など確認したい項目が増えていきます。しかし、最初から複雑な申請制度を作ると、利用者が申請を避け、かえって情シスから見えなくなる可能性があります。
最初のルールとして覚えやすいのが、「作った人・権限・止め方」の3点です。
1.作った人
誰が作成し、現在誰が業務上の責任を持っているかを記録します。個人名だけでなく所属部署や業務の責任者も残しておくと、異動時に引き継ぎやすくなります。
2.権限
メール、ファイル保管庫、カレンダー、顧客情報、社内データベースなど、何を読み、何を書き換え、どこへ送信できるのかを把握します。
3.止め方
誤動作、情報漏えい、担当者の退職などが発生したとき、誰がどこから停止できるのかを決めます。
例えば「問い合わせメールをAIで分類する処理」であれば、作成者は営業企画部のAさん、使う権限は共有メールボックスの読み取りと集計シートへの書き込み、停止方法は管理画面からの無効化、といった形です。
この3点だけでも台帳に残っていれば、事故発生時の初動は大きく変わります。逆に、どれだけ高度なAIガイドラインがあっても、「誰が作ったか分からず停止方法も分からない」状態では運用できません。AIエージェントの管理は、AI技術の専門知識よりも、従来のアカウント管理やシステム管理に近い部分から始める方が現実的です。
異動・退職時にはAIエージェントも棚卸し対象にする
特に見落としやすいのが、人事異動や退職時の扱いです。現在の情シス運用では、退職者についてアカウントの停止、ライセンスの回収、PCの返却、共有ファイルの引き継ぎなどをチェックリスト化している企業も多いでしょう。
今後は、このチェックリストに「本人が作成・所有している自動処理がないか」という確認項目を追加する必要があります。アカウントを停止したことで処理も止まるなら、業務が突然止まる可能性があります。一方、所有者が退職しても何らかの形で動き続けるのであれば、管理者不在の処理が残ることになります。どちらの場合も、事前に把握していなければ問題になります。
例えば、毎朝8時に前日の売上データを集計して部長へメールする処理を営業担当者が作っていたとします。その担当者が退職した翌日に処理が止まると、利用部門から「昨日まで届いていたメールが来ない」と情シスへ問い合わせが入るかもしれません。しかし台帳がなければ、そのメールがAIによる自動処理だったことを調べるところから始めることになります。
そこで、退職・異動の際には、対象者が所有する処理を一覧で確認し、「廃止」「後任へ引き継ぎ」「組織として管理する仕組みへ移行」といった判断を行う運用が必要です。また、重要業務で使う自動処理ほど個人所有を避ける、複数人が内容を把握する、設計内容を簡単に文書化するといった対策も有効です。
AIエージェントが増えるほど、従来の「アカウントを消して終了」という退職処理では不十分になります。人と一緒に、その人が作ったデジタルな業務プロセスも引き継ぐという考え方が必要です。
全面禁止より「使われているものを把握する」
管理できないAIエージェントが増えることを考えると、「業務部門が勝手に作ることを禁止すればよい」と考えるかもしれません。しかし、こうした自動化が業務ツールの標準機能として組み込まれていくと、全面禁止を続けることは次第に難しくなります。
また、禁止には副作用があります。会社が用意した環境で作れなくなった社員は、個人アカウントや会社が把握していない外部サービスで同じことを試すかもしれません。そうなると、記録も残らず、停止することもできません。禁止した結果、いっそう見えなくなるのが最悪の状態です。
Excelマクロや個人で作った業務ツールも、禁止しただけでなくなるものではありませんでした。業務上便利であれば、利用者は必要性を感じて使います。実態を見えなくするより、「業務で自動処理を作ったら登録する」という運用の方が、情シスにとって管理しやすい場合があります。
登録制度を作る場合も、最初から詳細な審査をすべての処理へ要求する必要はありません。社内データだけを使った個人向けの簡単な整理処理は登録のみとし、顧客情報を扱うもの、外部へメールやファイルを送信するもの、複数ユーザーが依存するものについては情シスやセキュリティ担当の確認を必要とするなど、リスクに応じて段階を分ける方法があります。
- 低リスク:本人だけが使い、社内情報の整理のみ → 登録
- 中リスク:部門内で共有、複数サービスと連携 → 登録+責任者確認
- 高リスク:顧客情報、外部送信、データ更新を伴う → 情シス・セキュリティ確認
この方法であれば、便利なAI活用を止めずに、重要な自動処理ほど管理を強くできます。管理者が処理を確認・停止したり、権限を制御したりできる機能が整えば、禁止ではなく「管理下で使う」という選択肢も取りやすくなります。
生成AI利用ルールにも「自動処理」の項目を追加する
あわせて見直しておきたいのが、現在の生成AI利用ルールです。既存のガイドラインがChatGPTなどとの対話だけを想定している場合、AIエージェントや自動処理に関する記載がない可能性があります。
従来のルールでは、「機密情報を入力しない」「個人情報を入力しない」「生成結果を人が確認する」といった内容が中心でした。しかし、AIが自動的にファイルを読み、データを書き込み、メールを送信するようになると、「入力してよい情報」だけでは管理できません。
AIを利用した自動処理を業務で利用する場合は、作成者、業務上の責任者、利用するデータ・サービス、付与する権限、外部送信の有無、停止方法を記録し、会社が指定する方法で登録する。
ルールの改訂は関係部署との調整が必要で、すぐには終わりません。だからこそ、ルールが整うのを待たずに手を打てることを先に済ませておく必要があります。
今月中にやること3つ
最後に、この記事を読んだあとに着手できることを3つに絞ります。ルールの整備より先に、この3つです。
- 管理画面を開いて、自社の現状を見る
AIによる自動処理に関する設定が、自社でどうなっているかを確認します。社員がすでに作れる状態なのか、実際に作られているものがあるのかを、まず自分の目で見てください。 - 可能な環境では、社外にデータを出す処理に人の承認を挟む
すべてを止める必要はありません。社外へデータが出る処理と、社外へメールを送る処理の2つに絞って、実行前に人が確認する形にします。特に事故時の影響が大きくなりやすいのが、この2つです。ただし、こうした承認を強制できるかどうかは契約プランや機能の反映状況によって異なります。自社の管理画面で設定できる範囲を確認してください。 - 誰の、どの自動処理なのか追跡できるか確認する
記録から、処理を識別するIDと所有者を確認できる状態になっているかを見ます。記録が残っていなければ、何かあったときに「どの処理が実行したのか」を追えません。逆に言えば、追跡できる状態が整っていれば、台帳の整備は後からでも進めやすくなります。
作った人・権限・止め方。まずこの3点を把握できる状態を作るだけでも、AIエージェントが新しいシャドーITになるリスクを大きく減らせます。全面禁止から始めるのではなく、「業務で使っている自動処理を情シスが把握できる状態」を目指すのが現実的です。
生成AIの管理は、「社員がAIへ何を入力するか」だけを見る段階から、「AIが何を読み、何を実行し、その処理を誰が管理しているか」を見る段階へ移りつつあります。まずは今月中に管理画面を開き、社外へデータやメールが出る処理について、承認を挟めるかどうかを確認してください。社内ルールの改訂は、その次で間に合います。


コメント