業務チャットにAIを置く前に決める6項目｜見える範囲と記録

「試しに1つのチャンネルに入れてみたら、思っていたより多くのことを知っていて驚いた」「便利なのは分かったが、どこまで読んでいるのか誰も答えられない」——業務チャットにAIを常駐させた直後によく聞く声です。この2つは別々の感想に見えて、原因は同じところにあります。チャットにAIを置くのは機能を追加することではなく、会話が起きている場そのものに、読み手をもう1人増やすことだからです。この記事では、置く前に決めておく6つの項目を順にまとめます。

置いた翌週に何が起きるかは、置く前に決まっている

業務チャットにAIを入れたあと、最初の1週間で出てくる質問はだいたい決まっています。「この要約はどこの情報から作られたのか」「隣のチームのチャンネルの話がなぜ出てくるのか」「自分が聞いた内容は誰かに見られるのか」。この3つです。いずれも、置いたあとに調べ始めると答えるのに数日かかる類の質問です。

厄介なのは、答えられない期間が長引くほど使われなくなることです。禁止されたわけではないのに、何を入れてよいか分からないから触らない。結果として、契約だけが残って利用が伸びない状態になります。導入の失敗として数えられるものの多くは、精度ではなくこの説明不足から来ています。

だから決めるのは、機能の選定より先です。この記事で扱う6項目は、どれも置いたあとでは変えにくいものばかりです。見える範囲を後から狭めると、いったん出てしまった要約は戻せません。記録の残し方を後から変えても、すでに残ったものは残ります。

もう1つ、置く前に決めておく理由があります。チャットは、決めごとを共有する場所としては向いていないという点です。運用の取り決めをチャンネルに流しても、翌週には流れて見えなくなります。決めた内容は、チャットの外の1枚に置いてから、チャットに置く。この順番を守っている会社ほど、後から入った人への説明が短く済んでいます。逆に、取り決めがチャットの中にしかない状態は、決めていないのとあまり変わりません。

道具を配るのと、会話の場に置くのは別の話

対話型のAIを各自に配る形と、業務チャットの中に常駐させる形は、同じ生成AIでも性質が違います。配る形では、人が意識して開き、意識して貼り付けます。入力は自分が選んだものだけです。会話の場に置くと、すでにそこにある会話が、そのまま材料になり得る状態になります。

この差は、事故の起き方に出ます。配る形の事故は「入れてはいけないものを人が入れた」という形をとります。置く形の事故は「入れた覚えがないものが出てきた」という形になります。後者は入力の教育では防げません。防ぐ手段は、読ませる範囲の設計と権限の整理のほうです。

もう1つの差は、記録です。配る形なら、履歴は個人の画面の中にあります。会話の場に置くと、誰が何を聞いたかが業務の記録の一部として残ります。マイクロソフトの資料でも、利用者のやり取りは監査の記録として捉えられ、証拠開示の対象になると説明されています。記録が残ること自体は悪いことではありません。残ることを知らないまま使うのが問題です。

置く前に決める6項目

決める順番も含めて、先に全体像を置きます。どれか1つだけ決めても効きません。1と2で見える範囲を、3と4で過去と記録を、5と6で終わり方を決める、という組み立てです。

項目	決めること	決めないと起きること
1 置く場所	どのチャンネルに入れるか	招いた覚えのない場の話が出てくる
2 一対一の扱い	個別のやり取りを読ませるか	私的な相談の内容が材料になる
3 過去の会話	どこまで遡らせるか	退職者の古い発言が引用される
4 記録	何がどこに残り、誰が取り出せるか	後から説明できない問い合わせが来る
5 引き継ぎ	退職・異動でその会話をどうするか	止めたはずの人の記録だけが残る
6 止め方	誰がどの単位でどれくらいで止めるか	障害時に止める手順が誰も分からない

この6つは、どれも管理者の設定画面の中だけでは決まりません。置く場所は業務の割り方の話ですし、引き継ぎは人事の手続きの話です。情報システム部門だけで決めようとすると、必ず途中で止まります。

項目1：どのチャンネルに入れるかと、見える範囲の初期値

最初に決めるのは、置く場所です。ここで多いのが「まず全社のチャンネルに入れて様子を見る」という進め方ですが、これは範囲を最大にしてから狭める順番なので、後戻りが効きません。逆から始めます。1つのチームの1つのチャンネルだけに入れ、そこで何が読まれているかを確かめる。

見える範囲を考えるとき、鍵になるのは「置いた場所」と「読める範囲」が同じではないという点です。マイクロソフトの資料では、AIが利用者に返すのは、その利用者が少なくとも閲覧の権限を持つ範囲に限られると説明されています。つまり置いた場所ではなく、呼び出した人の権限が範囲を決める。権限が広い人が呼べば、返ってくる範囲も広くなります。

チャンネルに常駐させる形では、さらに注意点が加わります。同じ資料には、チャンネルのエージェントは要求した本人の権限は確認するものの、チャンネルにいる全員分の権限は確認されないため、一部の参加者が開けない資料の内容を要約してしまうことがある、と明記されています。要求した本人には注意が表示され、管理者はこの機能を止められる、とも書かれています。置く前に読んでおくべき記述です。

この挙動が意味するのは、チャンネルの参加者の顔ぶれが、そのまま設計の一部になるということです。権限の広い人と狭い人が同じチャンネルにいて、広い人が要約を頼めば、狭い人の画面にその内容が並びます。人が手で貼り付けたときと結果は同じですが、貼り付けた自覚がないぶん、誰も止めません。置く場所を選ぶときは、資料の重さではなく参加者の権限がどれくらいばらついているかを先に見ます。ばらつきが大きいチャンネルは、最初の1つに選ばないのが安全です。

項目2：一対一のやり取りを読ませるか

次に決めるのは、公開されているチャンネルと、一対一のやり取りを分けるかどうかです。実務上、この線引きがいちばん揉めます。個別のやり取りには、業務の相談と個人的な事情が混ざっているからです。体調、人事、評価、転職。これらが要約の材料になり得ると分かった時点で、利用は止まります。

設計としての選択肢は3つあります。個別のやり取りは対象から外す。本人が明示的に呼んだときだけ対象にする。全部対象にして、記録の扱いを厳格にする。最初は1つ目から始めるのが無難です。狭いところから広げるのは説明できますが、広いところから狭めるのは「何かあったのか」と受け取られます。

なお、製品によっては、エージェントが読める範囲を呼び出した本人の見られる範囲に合わせる設計が採られています。ただし範囲の初期値と、管理側でどの単位まで絞れるかは製品ごとに差があります。使う製品の管理者向け資料で、初期値を必ず自分の目で確かめる。人づてに聞いた設定の話は、版が変わると合わなくなります。

項目3：過去の会話をどこまで遡らせるか

3つ目は、過去の会話の扱いです。チャットは、入れた瞬間から数年分の履歴がその場にあります。人が新しく参加したときは、遡って読むかどうかは本人の手間に左右されますが、AIには手間の制約がありません。置いた瞬間に、全期間が等しく手の届く場所になると考えたほうが実態に近い。

ここで確かめておきたいのが、過去の会話が学習に使われるかどうかです。マイクロソフトの資料では、プロンプトと回答、そして参照したデータは基盤となる大規模言語モデルの学習には使われない、と明記されています。学習に使われないことと、検索の対象になることは別です。学習されなくても、要約の材料としては読まれます。

実務上の落としどころは、期間ではなく用途で切ることが多くなります。議事の要点出しは直近の会話だけを対象にする、資料の在りか探しは期間を切らない、といった形です。期間で一律に切ると、探しものの精度が落ちて使われなくなります。

過去の会話をめぐって現場から出やすいのが、「昔の発言を引用されたくない」という声です。数年前の検討中の案や、途中で撤回した見解が、当時の文脈なしに引かれてくると受け取りが悪い。対処としては、引用のときに必ず日付を添えさせる形が扱いやすい。日付が見えていれば、読む側が古い話だと分かります。遡らせないのではなく、いつの話かを必ず添えさせる。この一手だけで、抵抗感はかなり下がります。

項目4：やり取りの記録は、事実と中身で残り方が違う

4つ目は記録です。ここは思い込みが多いところで、実際の仕組みを知っておくと説明が一気に楽になります。マイクロソフトの資料によると、利用者のプロンプトと回答はその利用者のメールボックス内の隠しフォルダーに保存され、証拠開示の道具で検索できる状態になります。画面の履歴を消しても、この保存先の状態が変わるとは限りません。

さらに細かい点として、同じ資料には、監査の記録には検索したという活動は残るが、実際のプロンプトと回答そのものは残らない、と書かれています。中身を見るには証拠開示の仕組みか、AIの活動を見る画面を使う、という整理です。つまり「誰が使ったか」と「何を聞いたか」は、取り出す道具が違う。社内に説明するときは、この2つを分けて話したほうが誤解が減ります。

チャットの議事に関わる注意もあります。同じ資料には、会議の文字起こしを止めている場合、チャットのAIについて監査・証拠開示・保持の機能が働かない、という趣旨の記載があります。記録を残す前提で運用を組むなら、何を止めると記録も止まるのかを先に確かめておく必要があります。

記録の使い道も、先に決めておくと揉めません。監査のために残すのか、事故が起きたときに追うために残すのか、利用状況を測るために残すのか。同じ資料には、監査の記録はデータの保護と法令順守のために設計されたものであり、利用状況の報告の土台として使うことは想定されていないという注意書きがあります。使う人数や回数を知りたいのであれば、管理画面の利用状況の報告のほうを見る、という切り分けです。ここを混ぜると、部門ごとの数字が合わないという不毛なやり取りが始まります。

項目5：退職・異動でその会話はどうなるか

5つ目は、人が抜けたあとの扱いです。ここは後から気づくと手を打てません。マイクロソフトの資料には、利用者が組織を離れて情報の管理単位が削除された場合、その人のAIとのやり取りは無効化されたメールボックスに保存され、以前から適用されていた保持の方針が引き続き適用され、証拠開示の検索の対象として残る、と書かれています。

この挙動は、2つの意味で実務に効きます。ひとつは、退職者が聞いた内容を後から調べられるということ。もうひとつは、退職者の記録が意図せず残り続けるということです。前者は監査の観点で必要ですが、後者は保持の方針を決めていないと、何年分が残っているのか誰も答えられなくなります。

決めておくのは3点です。退職の手続きのどの段階でAIの利用を止めるか。その人のやり取りをどれだけの期間残すか。異動のときに、前の部署の会話を引き続き参照させるかどうか。この3点目は見落とされがちですが、異動者が前の部署の会話を材料に回答を得られる状態は、権限を戻し忘れているのと同じです。

項目6：止め方を先に決める

6つ目は止め方です。使い始める前に決めておくべき理由ははっきりしていて、止めたい場面は必ず急ぐ場面だからです。誤った要約が出回った、社外に出してはいけない内容が引用された、大きな組織変更で権限が一時的に崩れている。どれも、その日のうちに手を打つ必要があります。

止め方には段階があります。特定のチャンネルから外す、特定の部署の利用を止める、組織全体で止める。マイクロソフトの資料では、管理者が組織で許可するエージェントを選べること、利用者は管理者が許可したものしか使えないこと、そしてチャンネルのエージェントを管理者が止められることが説明されています。どの段階を誰が実行できるかを、名前で決めておくのがこの項目の中身です。

同じ資料には、管理の画面でエージェントが要求する権限とデータへのアクセスの範囲、利用の条件や取り扱いに関する記述を管理者が確認できる、という説明もあります。つまり止め方を決める作業は、入れるときの審査の裏返しでもあります。入れるときに見た項目を1枚に控えておけば、止めるかどうかを判断するときにそのまま材料になります。入れる審査と止める判断を、同じ1枚で扱う。別々の書類にすると、片方だけが更新されて食い違います。

• 止める操作を、導入の初週に一度だけ実際に試しておく
• 止めたあと、すでに出た回答は戻らないことを関係者に共有しておく
• 止める判断ができる人を、部門ごとに2人以上置く（1人だと不在時に止まらない）
• 止めた事実と理由を1行で残す場所を決めておく

最初の2週間で踏む工程

6項目を机上で決め切ろうとすると、決まらないまま時間が過ぎます。範囲を1つに絞って動かしながら決めるほうが早い。次の5工程が、実務で回りやすい順番です。

この5工程は、合わせて2週間あれば終わります。3番目の工程を飛ばすと、権限の穴は本番の会話の中で見つかります。試す段階で見つけるか、業務の中で見つけるかの違いしかありません。

マーケ業務のどこに置くと効くか

置く場所を業務から考えると、効きどころは4つに絞られます。1つ目は依頼の受け付けです。制作物の依頼がチャットで飛んでくる部署では、必要な情報が揃っているかを最初に確かめさせるだけで、往復が減ります。締切、対象、掲載先、既存資料の有無といった項目を、依頼の直後に問い返させる形です。

2つ目は資料の在りかを探すこと。3つ目は打ち合わせの要点出し。4つ目は、承認に回す前の下書きの点検です。この4つに共通するのは、成果物を作らせているのではなく、次に進むための材料を揃えさせている点です。判断そのものは人が持ったままなので、間違っていても被害が小さい。

逆に、置いてもあまり効かないのが、社外に出る文面をチャットの中で仕上げようとする使い方です。文面は推敲の往復が長く、チャットの流れでは版が管理できません。チャットに置くAIは、作る場所ではなく、探す・確かめる・整える場所に向いています。ここを取り違えると、便利さより混乱が勝ちます。

4つの使いどころのうち、最初に効果が出やすいのは資料の在りか探しです。理由は単純で、間違っても被害が出ず、当たれば時間がそのまま浮くからです。依頼の受け付けは効果が大きい反面、問い返す項目を決める作業が要るので、2番目に置きます。議事の要点出しは、記録の残り方を確かめてからにします。承認前の下書きの点検は、確認する人が決まっていないと機能しないので、最後に回します。

この順番で置くと、部署ごとに違う使い方をしていても、比べられる形が残ります。何を探させたか、何回で見つかったかを1行ずつ残すだけで十分です。マイクロソフトの資料でも、機微な情報の種類や学習済みの分類器を使って、やり取りの中の機微なデータを見つけられると説明されています。使い方を測る仕組みと、危ない使い方を見つける仕組みは、別々に用意しておくと運用が楽になります。

権限の穴は、置いた日に見える形で出てくる

業務チャットにAIを置いた会社でよく起きるのが、「共有しすぎていた」ことが表面化する現象です。誰でも入れるチャンネルに置かれた資料、退職者が作ったまま権限が広いままの文書、部署をまたいで共有されたフォルダー。人の目では誰も見に行かなかったものが、要約の材料として出てきます。

この現象は、AIが新しく穴を開けたわけではありません。もともと開いていた穴が、初めて使われただけです。だから対処も、AIの設定ではなく権限の側になります。置く前に、対象のチャンネルとその配下の資料について、誰が見られるかを1度確かめておくのが最短の回り道です。

関連して、マイクロソフトの資料には、チームやサイトに付けた区分の表示は中の項目に引き継がれないため、社外秘として扱われている場の会話を要約しても、その表示が付かない場合がある、という趣旨の記載があります。また、情報の遮断の仕組みがチャンネルのエージェントでは未対応で、遮断をまたいだ情報が返る可能性にも触れられています。表示が付かないことと、扱いが軽いことは別だと、使う人に伝えておく必要があります。

外部のAIとの境目をどこに引くか

業務チャットにAIを置くと、必ず並行して起きるのが「別のAIに貼り付ける」動きです。チャットの中のAIでは物足りないとき、人はブラウザーで外部のサービスを開いて貼り付けます。ここを塞がないままチャットの中だけ整えても、抜け道が残ったままになります。マイクロソフトの資料では、端末側の情報漏えい対策として、ブラウザー経由で外部の生成AIのサイトへ機微な情報を共有しようとする動きを警告したり遮断したりできると説明されています。

もう1つの境目は、扱いの重い文書の側にあります。同じ資料には、閲覧の権限はあるが取り出しの権限がない内容について、AIは要約せずリンクとして示すだけになる、という説明があります。さらに、最も機微な情報のために用意された二重の鍵による暗号化がされているものは、AIから参照できないとも書かれています。いちばん守りたいものは、権限の設計だけで自動的に対象から外れるようにできる、ということです。

ただし、チャンネルに置くエージェントには制約が残ります。同じ資料では、情報漏えい対策の方針で識別された文書について、チャンネルのエージェントには要約を止める手段がないこと、回答を利用者がコピーするのを防げないことが挙げられています。止められる場所と止められない場所が、同じ製品の中で分かれている。どちらに当たるかを置く前に確かめ、止められない側については運用の取り決めで補う、という二段構えにしておきます。

消したつもりが消えていないことがある

記録の話でもう1つ押さえておきたいのが、削除の実際です。マイクロソフトの資料には、保持の方針で1日で消す設定にしても、証拠開示の検索に出なくなるまでに16日ほどかかる場合があるという具体例が示されています。画面から消えることと、検索の対象から外れることは同じではありません。

同じ資料には、保持の方針によってやり取りが削除されたことは利用者に通知されない、という記載もあります。つまり、利用者から見ればいつの間にか消えているし、管理者から見れば消したつもりでもしばらく残っている。この非対称を知らないまま「消しました」と社内に説明すると、後で食い違いが出ます。

• 画面の履歴を消して対応完了とする：保存先の状態は変わっていない可能性がある
• 保持の期間を決めずに使い始める：何年分が残るのか誰も答えられなくなる
• 退職者の分だけ手作業で消そうとする：保持の方針が優先され、思ったとおりに消えない
• 止めれば記録も消えると考える：利用を止めても、それまでの記録は残る

人が確認する範囲を先に決める

ここまでの6項目は、どれも「範囲を決める」話でした。最後に必要なのが、出てきた答えを人がどこまで確かめるかの線引きです。チャットに置くと回答が会話の流れに混ざるため、確かめる工程が省かれやすい。人の発言と同じ見た目で並ぶからです。

決めておく線は2本です。1本目は、そのまま社外に出してよいものは何もないという線。要約も、下書きも、探してきた資料の説明も、人が1度見てから外へ出します。2本目は、根拠を示せない回答は使わないという線です。どの文書のどこから作ったかを併記させ、示せないときは答えさせない運用にします。

この2本を守るために効くのが、回答の見た目を人の発言と変えることです。引用元の一覧を必ず付ける、確認前であることが分かる書き出しにする、といった工夫で、確かめる工程が飛びにくくなります。AIに判断させないのではなく、判断したように見せない。運用ではこの差が効きます。

加えて、AIに任せない工程を名指しで書いておきます。社外への回答の可否、金額と納期の確定、人に関する評価、契約の解釈。この4つは、下書きを作らせることはあっても、そのまま送信できる状態にはしないと決めておきます。チャットは送信までの距離が短い場所なので、下書きと確定の境目が曖昧になりやすいからです。境目を曖昧にしないために、確定の操作だけは別の場所で行う、という決め方をしている会社もあります。

なお、外部の事業者のモデルが使われる場合には、追加の条件が適用されることがあります。マイクロソフトの資料では、他社のモデルを自社の体験に使うかどうかを管理者が選べること、モデルによっては欧州のデータの境界の対象から外れる場合があることが説明されています。どのモデルで動いているかは、契約と設定で変わります。海外の顧客や従業員の情報を扱う部署でチャットのAIを使うなら、置く前に確かめておく項目に加えておきます。

実務仕様（権限・記録・停止・引き継ぎ）

最後に、決めた内容を1枚に落とす形を示します。この4区分で書いておくと、後任への引き継ぎと、監査への説明の両方に使えます。

区分	決めること	書いておく形
権限	置く場所と、読める範囲の初期値	チャンネル名と、確認した日付・確認者
記録	何がどこに残り、誰が取り出せるか	取り出す道具の名前と、実際に試した記録
停止	誰がどの単位で止められるか	担当者2名の氏名と、試した日付
引き継ぎ	退職・異動時の扱いと保持の期間	人事の手続きのどの段階と連動するか

この表で大事なのは、すべての欄に日付と氏名が入ることです。設定の内容だけを書いた文書は、版が変わると誰も信じなくなります。確かめた日と確かめた人が書いてあれば、いつ確かめ直すべきかが分かります。半年に1度、同じ表を上から確かめ直す運用にしておけば、製品側の変更にも追いつけます。

まとめ

業務チャットにAIを常駐させることは、機能を1つ足すことではなく、会話が起きている場に読み手を1人増やすことです。だから決めるべきは精度でも料金でもなく、置く場所、一対一のやり取りの扱い、過去の会話の範囲、記録の残り方、退職や異動での扱い、そして止め方の6つになります。どれも置いたあとでは変えにくく、変えても出てしまったものは戻りません。1つのチャンネルから始め、権限の外の質問をわざと試し、記録を1件取り出し、止める操作を確かめてから広げる。順番をこう置き換えるだけで、置いた翌週に出る3つの質問には、その場で答えられるようになります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。