AI議事録のセキュリティ｜社外秘を扱う会議の注意点と線引き

AI議事録のセキュリティは「ツールを選ぶ前」に決めることがある

AI議事録のセキュリティについて調べると、たいてい同じ注意点に行き当たります。入力したデータがAIの学習に再利用されない設定になっているかを確認する、データの保管場所と暗号化を確かめる、第三者認証を取得しているサービスを選ぶ、社内ガイドラインを整備してアクセス権限を最小化する。どれも間違っていません。ただ、これらを全部やり終えても、来週の経営会議でAI議事録を回してよいのかという目の前の問いには答えが出ないはずです。ツールが安全かどうかと、その会議で使ってよいかどうかは、別の問題だからです。

この記事は順番を変えます。最初に「社外秘」と呼んでいるものを分解して、自分の判断だけで決められる秘密と、相手方の承諾がなければ決められない秘密を切り分けます。次に、その会議で録音を回してよいかを決める問いを用意します。そのうえで、会議中に想定していなかった機密が飛び出したときの処置と、すでに入れてしまった情報が回収できるのかを扱います。ツールの選定と権限管理は、その後です。判断の枠組みが先にあってこそ、選定チェックリストは意味を持ちます。読み終えたときに、自社の具体的な会議に当てはめられる線引きが手元に残る構成にしています。

まず仕組み：会議の音声はどこへ行き、どこまで残るのか

判断の前提として、会議の音声がどこを通り、どこに残るのかを共有しておきます。ここは多くの解説記事が詳しく扱っている領域なので、本記事では以降の判断に使う地図として最小限にまとめます。押さえておきたいのは、AI議事録が「録音して文字にする」だけの仕組みではないという点です。音声は多くの場合いったん自社の外へ出て、文字起こしと要約という複数の処理を経て、最後に社内の閲覧者へ配られます。段階ごとに触れる相手が変わり、漏れ方も変わります。次の表は、その流れと、それぞれの段階で情報が外に出る経路を一つにまとめたものです。

段階	データの状態	触れうる相手	ここで生じる漏れの経路
録音・収集	会議中の生の音声	参加者、会議に入り込んだ外部ボット	招待されていないアカウントやボットが会議に同席したまま記録されます
送信・処理	自社の外部にある処理基盤上の音声	AI議事録の提供事業者、基盤となる大規模言語モデルの提供元	自社の管理外へ送信され、保管される国や地域の法制度の影響を受けます
文字起こし・要約	テキスト化された発言と生成された要約	提供事業者、連携している外部サービス	入力内容がモデルの学習に再利用される設定になっている場合があります
保存・共有	完成した議事録とその中間生成物	社内の閲覧者、共有リンクの受け取り手	権限設定の誤り、共有範囲の広すぎる初期設定、外部連携による転送が起こります

この表の四つの経路のうち、送信と学習再利用はツールの設定と契約で対処できます。一方で、権限設定と共有範囲は自社の運用の問題です。そして最初の段階、つまり何を録音してしまうかは、ツールの設定でも運用ルールでも防ぎきれません。その理由は後の章で扱います。

「社外秘」を4つに分ける——自分で決められる秘密と、決められない秘密

社外秘の会議でAI議事録を使ってよいかが決められない最大の理由は、「機密情報」という一語で全部を括っているからです。括ったままでは、使ってよいのか悪いのかという二択にしかならず、二択にすると現場は使ってしまいます。分ける基準は情報の重要度ではありません。「使ってよいかを誰が決められるか」です。この基準で分けると、社外秘は四つになります。

一つめは自社の社外秘です。未公表の売上や原価、値付けの根拠、中期の戦略といった、自社が自社のために秘密にしている情報がこれにあたります。二つめは取引先から預かった秘密です。守秘義務契約のもとで開示された仕様、価格、体制、開発中の計画などが該当します。三つめは個人情報です。人事評価、健康状態、採用選考の内容といった、本人に帰属する情報を含みます。四つめは未公表の重要事実です。合併や買収の検討、決算発表前の業績情報など、公表前に外部へ伝わればインサイダー取引規制に触れうる情報がこれにあたります。

一つめ、三つめ、四つめは、扱いのルールこそ厳しいものの、判断の主体は自社です。取り扱いの水準を決めるのも、外部サービスに預けるかを決めるのも、自社の責任と権限の範囲に収まります。ところが二つめだけは違います。その情報の持ち主は自社ではないので、AI議事録という外部サービスに通してよいかを、自社の判断だけでは決められません。ここが線引きの中心です。

いちばん危ないのは「取引先から預かった秘密」——NDAとAIベンダー

守秘義務契約には、ほぼ例外なく「開示された秘密情報を第三者に開示または漏洩してはならない」という条項が入っています。問題は、AI議事録の提供事業者がここでいう第三者にあたるのかという点が、多くの契約で想定されていないことです。契約が結ばれた時点で想定されていたのは、人が読んで人に渡す状況でした。音声をそのまま外部の処理基盤に送り、さらにその先の言語モデル提供元まで到達しうるという経路は、条文の文言に書かれていないことのほうが多いはずです。

確認すべき条項はいくつかあります。第三者開示の禁止に例外規定があるか、受託先や履行補助者への開示が認められているか、認められている場合に同等の義務を課すことが条件になっているか、再委託の可否がどう書かれているか。そして、秘密情報の複製や保管場所について制限がないか。AI議事録の利用は、実質的には秘密情報を複製して自社の管理外に置く行為なので、複製制限の条項に触れる場合があります。

書かれていない場合は、書かれていないから使ってよいのではなく、書かれていないから自社では決められない、と読むのが安全です。実務上は、先方に利用の可否を確認して記録に残すのが唯一の解決策になります。確認が取れない相手との会議では、その会議だけAI議事録を回さないという運用に倒してください。自社の秘密であれば漏れても自社の損で済みますが、預かった秘密が漏れれば失うのは取引そのものです。

4分類 × 使ってよいか の判定表

分類ができたら、それぞれをどう扱うかを表にして社内で共有します。判定は「そのまま回してよい」「条件付きで回してよい」「回さない」の三段階で十分です。重要なのは、条件付きに分類したものについて、条件の中身を具体的に書いておくことです。条件が曖昧なままだと、現場は条件を満たしたかどうかを判断できず、結局そのまま回すか、まったく使わないかのどちらかに寄ります。次の表は判断の骨格です。自社の業種や契約慣行に合わせて条件の欄を書き換えて使ってください。

分類	使ってよいかを決められるのは	原則の扱い	条件の中身
自社の社外秘	自社	条件付きで回してよい	学習への再利用が無効化されていること、閲覧範囲を会議参加者に限定できること
取引先から預かった秘密	相手方	相手方の確認が取れるまで回さない	先方の利用承諾を得て記録に残すこと、守秘義務契約の第三者開示・再委託・複製の条項と矛盾しないこと
個人情報	自社（ただし本人への説明義務あり）	条件付きで回してよい	取得目的の範囲内であること、評価や健康に関わる内容は閲覧権限を人事担当に限定できること
未公表の重要事実	自社（ただし法令の制約下）	回さない	公表後に扱いを解除する。公表前は録音そのものを行わない

この表を作る作業自体が線引きです。表の空欄を埋められない会議があるなら、その会議は録音を回す前に判断が終わっていないという意味になります。

AI議事録の落とし穴：入れる情報を事前に選べない

情報を守るという営みは、長いあいだ「渡すものを選ぶ」という前提の上に組み立てられてきました。持ち出す書類を選ぶ、送る宛先を選ぶ、貼り付ける文章を選ぶ。守るための技術はこの数十年で何度も入れ替わりましたが、選ぶ主体が人間の側にあるという前提だけは、ほとんど疑われないまま残っています。裏を返せば、これまで安全でいられたのは、対策が優れていたからというより、選ぶ機会がたまたま手元に残っていたからなのかもしれません。

そう考えると、問うべきなのは対策の精度ではなく、選別の機会が経路のどこに置かれているか、という構造のほうです。関所は道の上にしか設けられません。荷が通り過ぎたあとの地点にどれだけ厳重な関所を築いても、通ってしまったものは戻ってきません。道具が新しくなるとき、本当に変わるのは危険の大きさではなく、関所を置ける場所のほうだと言えそうです。

ルールが古びるのは、書かれている内容が間違っているからとは限りません。そのルールが前提にしていた「選べる場所」のほうが、道具の交代とともに消えてしまうからです。ここから扱うのは、その消え方です。

生成AIの情報漏洩対策として広く紹介されている手順は、入力する前に機密を取り除くというものです。個人名や社名をマスキングしてから貼り付ける、入力してはいけない情報のリストを作って周知する、といった対策がその典型です。これらはチャット形式の生成AIを前提にすれば有効です。利用者は自分の手元にあるテキストを見て、どこまでを渡すかを選んでから貼り付けるからです。選別は入力の前に、利用者の意思で行われます。

AI議事録では、この前提が成り立ちません。録音ボタンを押したあとに何が話されるかを決めるのは、操作した本人ではなく、その場にいる話者だからです。入力してはいけない情報のリストをどれだけ精密に作っても、他の参加者が口にした瞬間にそれは入力されています。つまり、入力前フィルタという発想が原理的に効かない領域です。

だから注意点の重心が移ります。「何を入れないか」ではなく「どの会議で回すか」です。単位が情報から会議に変わります。この転換ができていない組織は、機密情報の入力を禁止するというルールを掲げながら、実態としては制御できていない状態に置かれます。ルールがあるのに守れない状態は、ルールがない状態より危険です。守っているつもりになるからです。

「入力禁止リスト」がチャットでは効いて議事録では効かない理由

二つの違いを並べると、なぜ同じ対策が通用しないのかがはっきりします。入力の主体、選別が行われるタイミング、そして取り消せるかどうかの三点です。

観点	チャット形式の生成AI	AI議事録
入力の主体	利用者本人が貼り付けます	その場の話者全員の発言が入ります
選別のタイミング	入力の直前に、内容を見てから選べます	録音開始後に、内容が分からないまま入ります
取り消しの可否	送信前なら消せます	発せられた時点で記録されており、事後の削除しか手段がありません

この表が示すのは、AI議事録における選別の機会が、録音開始より前にしか存在しないという事実です。開始後は、記録を止めるか、記録されたものを削るかという事後処理しか残りません。したがって対策の設計も、入力の前ではなく録音の前という時点に移動させる必要があります。入力禁止リストを捨てる必要はありませんが、それは会議の可否を判断したあとの補助にすぎない、という位置づけに変わります。

録音を回す前の3つの問い（会議単位で可否を決める）

会議単位で可否を決めるための問いを三つに絞ります。会議の招集を受けた時点、遅くとも開始直前に、招集した側か記録を担当する側が確認します。

第一に、この会議に自社以外の秘密が出るかどうかです。取引先から預かった秘密や個人情報が議題に含まれるなら、前章の判定表に照らして条件を満たしているかを確かめます。第二に、機密が出たときに記録を止められる立場に自分がいるかどうかです。自分より上位の役職者や社外の参加者が中心の会議では、話の途中で録音を止めると言い出せないことがあります。止められないなら、そもそも回さないという判断になります。第三に、この議事録を後から見る人の範囲を、いま決められるかどうかです。共有先が決まらないまま作られた議事録は、既定の共有設定に従って広がります。

三つのうち一つでも答えが否であれば、その会議は回さないか、条件を付けたうえで回してください。条件とは、参加者に録音を告知して機密の話題は口頭にとどめる合意を取る、記録の範囲を議題の一部に限る、生成された議事録の共有先を事前に確定させる、といった具体的な制限を指します。三つとも肯定できる会議であれば、迷う必要はありません。この問いの価値は、止める会議を増やすことではなく、回してよい会議を自信を持って回せるようにすることにあります。

会議中に想定外の社外秘が出たときの処置

前章の三つの問いを通しても、想定外は必ず起こります。通常の定例会議のつもりで始めたところ、途中から未公表の組織変更の話に移った、進捗確認の場で取引先の価格条件が具体的に読み上げられた、といったことは日常的に起こります。予測できるものはすべて事前に排除したうえで、なお残るのが想定外です。だからこそ、起きてから考えるのではなく、起きたときにどう動くかを先に決めておく必要があります。

処置は大きく二つしかありません。その場で記録を止めるか、あとから該当箇所を削るかです。この二択のどちらを選ぶかを、その場の空気で決めさせないことが重要です。判断基準を先に配っておけば、迷っている数分のあいだにも記録は進み続けるという事態を避けられます。

その場で止める／あとで削る、の使い分け

使い分けの基準は一つです。消しても消えない先まで、その情報が届いてしまったかどうかです。録音がまだ自社の会議ツール内にとどまっている段階なら、あとから該当部分を削る選択が成り立ちます。しかし外部の処理基盤へ送信済みであったり、リアルタイムで文字起こしと要約が生成されていたり、終了と同時に関係者へ自動配信される設定になっていたりする場合、あとで削るという選択肢は実質的に存在しません。削る対象が自分の手の届く範囲を超えているからです。

したがって、リアルタイム処理と自動配信が有効なツールを使っているなら、迷ったら止める側に倒してください。止める操作は、一時停止か、記録の終了を宣言するかのどちらかです。宣言するための言い回しを事前に用意しておくと実行しやすくなります。ここから先は記録を止めます、と告げるだけで足ります。理由を説明する必要はありませんし、説明すると止める判断そのものが議論になってしまいます。止めたあとに残るのは、それまでに記録された部分の扱いです。誰がいつまでに確認して削除するかを、その場で決めて担当を指名してください。

社外の人がいる会議は自社だけでは決められない

社外の参加者がいる会議では、録音するかどうかを自社だけで決められません。会議の記録は参加者全員の発言を対象にするため、告知して同意を得る手順が必要になります。会議の冒頭で記録の実施を伝え、異議がないことを確認したうえで開始するのが基本の形です。同意の取り方や告知の文面については、録音そのものの適法性を扱う情報を別途参照してください。

ここで押さえておきたいのは、その先です。録音の同意を得たことと、取引先から預かった秘密をAIサービスに通してよいことは、まったく別の話だという点です。参加者は目の前で記録されることに同意しただけであり、その音声が外部の処理基盤へ送信され、文字起こしと要約が自動生成され、その事業者のシステム上に一定期間保管されることまで想定して同意したとは限りません。守秘義務契約の対象となる情報を含む会議では、録音の同意とは別に、AI議事録サービスの利用について確認を取る必要があります。同意を得たから安心という理解が、いちばん危険な取り違えです。

入れてしまった情報は、消せるのか

ここまでは、入れないための話でした。ですが、この記事を読んでいる方の多くは、すでに何度か機密を含む会議で回してしまっているのではないでしょうか。セキュリティの解説はほとんどが予防で終わっていて、インシデント対応と書かれていても、中身は誰に報告するかという社内手続きの話にとどまります。入れてしまったデータが技術的にどこまで消えるのかという問いに答えているものは、ほとんど見当たりません。

そこでこの章では、削除操作がどこまで届くのかを段階で整理します。結論を先に言えば、画面から消えることと、データが消えることは別です。そして、この違いは事故が起きてから調べたのでは遅く、ツールを選ぶ段階で確認しておくべき項目にあたります。

音声・文字起こし・要約・ログ——どこまで消えてどこが残るか

削除を実行したとき、影響が及ぶ範囲は層になっています。手前から順に、自社の管理画面に表示されている議事録、提供事業者のシステムに保存されている音声ファイル、文字起こしのテキスト、生成された要約や議題の抽出結果といった中間生成物、誰がいつ閲覧したかのアクセスログ、障害復旧のためのバックアップ、そして基盤となる言語モデル側に一時的に保持されるデータです。

利用者が削除ボタンを押して確実に消えるのは、多くの場合いちばん手前の層だけです。中間生成物は別のデータとして管理されていることがあり、一覧から見えなくなっても実体が残る場合があります。バックアップは仕組み上、一定の世代を保持することが目的なので、即座には消えません。監査ログは、消せないことがむしろ正しい設計です。さらに、外部連携によってすでに他のサービスへ転送された内容や、自動配信で送られたメールの本文は、元のデータを削除しても回収できません。削除依頼を出すという行為は、これらの層のうちどこまでに効くのかを確認しない限り、対処したという安心感だけを生みます。

事故ってから調べても遅い。選定時に聞いておく3つの質問

以上を踏まえると、確認は選定の段階で終えておく必要があります。提供事業者に投げる質問は三つで足ります。

第一に、削除を依頼してから実際にデータが削除されるまで、どのくらいの期間がかかるのかです。即時と回答された場合は、それが管理画面上の表示のことなのか、保存されている実体のことなのかまで確かめてください。第二に、バックアップからの削除に応じてもらえるのかです。応じられないという回答であれば、保持期間が経過するまで残り続けるという意味なので、その期間を確認します。第三に、削除が完了したことを示す証跡を発行してもらえるのかです。取引先から預かった秘密を誤って入れてしまった場合、先方への報告に必要になるのはこの証跡です。

すでに入れてしまった心当たりがある場合の順序も決まっています。まず何がどの会議で送られたかを特定し、次に削除を依頼して届く範囲を確認し、最後に回収できない範囲が残ることを前提に、相手方へ報告するかどうかを判断します。この順序を逆にして、報告の要否から考え始めると、事実の特定が後回しになって判断が遅れます。

ツール選定と権限管理で確認する項目

ここまでの判断の枠組みができて、はじめてツールの選定が意味を持ちます。この領域は多くの記事が詳しく扱っているので、本記事では確認すべき項目を絞って提示します。押さえておきたい前提が一つあります。第三者認証の取得は、その事業者が組織として情報セキュリティの管理体制を運用していることの証明であって、自社の特定の会議をそのツールで記録してよいことを保証するものではありません。認証の有無は選定の足切りには使えますが、線引きの代わりにはなりません。もう一点、議事録は作られるまでより作られたあとに漏れることのほうが多い、という現実も押さえておいてください。

選定時に見る5項目（学習利用・保管場所・暗号化・権限・第三者認証）

選定時の確認は次の五項目に集約できます。カタログの記載を読むだけでなく、自社が契約する予定のプランで有効かどうかまで確かめてください。

項目	確認すること
学習利用の可否	入力データがモデルの学習に使われない設定になっているか、それが契約するプランで有効か、既定で無効なのか申請が必要なのか
保管場所	データが保管される国と地域はどこか、変更できるか、その地域の法制度で当局の開示要求を受ける可能性があるか
暗号化	通信経路と保存データの双方が暗号化されているか、鍵の管理は誰が行うか
権限とアクセス制御	議事録ごとに閲覧範囲を指定できるか、接続元の制限や多要素認証に対応しているか、操作の監査ログが残るか
第三者認証	情報セキュリティマネジメントに関する認証を取得しているか、その適用範囲に当該サービスが含まれているか

五項目のうち、最初の学習利用と二番目の保管場所は契約とプランに紐づくため、後から前提が変わりうる項目です。この点は次章で扱います。

議事録は「作った後」に漏れる——共有範囲・自動配信・退職者

作成後の管理は、選定と同じ重みで確認する必要があります。実際の漏洩は、外部への送信よりも社内での配り方から起きることが多いためです。確認すべきは四点です。一つめは共有リンクの既定設定です。リンクを知っている人なら誰でも閲覧できる設定が初期値になっていると、転送された時点で範囲が制御できなくなります。二つめは自動配信です。会議終了と同時に議事録をチャットツールやメールへ流す機能は便利ですが、宛先が固定のチャンネルになっていると、機密を含む回だけ止めることができません。この初期設定は導入時に必ず確認してください。

三つめは退職者と異動者のアカウントです。権限の削除が遅れると、在職中に参加した会議の議事録に引き続きアクセスできる状態が残ります。四つめは保存先フォルダの既定の公開範囲です。個々の議事録の権限を細かく設定しても、格納先のフォルダが全社公開であれば、そちらの設定が優先されることがあります。作った後に漏れるという前提で、配る仕組みのほうを点検してください。

導入したあとに穴が開く3つの変化

選定チェックリストの最大の弱点は、それが導入時の一度きりの作業として扱われることです。確認した時点では正しくても、時間の経過とともに前提のほうが変わります。変化は三つの形で起こります。

一つめはプラン差です。同じ製品名のサービスでも、下位のプランや無料のプランでは学習への再利用を無効化できない場合があります。導入時に上位プランで確認していても、契約更新のタイミングでプランを見直したり、部署ごとに別のプランを契約したりすると、確認した前提が崩れます。契約プランの変更を、セキュリティ設定の再確認とセットにしてください。

二つめは利用規約とデータ利用ポリシーの改定です。事業者はこれらを更新しますが、通知は契約者のメールアドレスに届くだけで、実際に読まれないまま同意扱いになりがちです。通知の受信先を個人ではなく共有のアドレスにして、誰が読んで社内に共有するかという役割を決めておいてください。

三つめは個人アカウントの併用です。会社が正式に契約したツールとは別に、以前から使われていた個人の無料アカウントが残り続けることがあります。とくに起きやすいのが、会議の招待リンクに記録用のボットが参加者として入り込む形です。会社の管理下にないアカウントが会議に同席していても、参加者一覧を意識して見ない限り気づけません。気づく仕掛けとして、会議の参加者に見慣れないボットがいないかを確認する習慣と、利用中のツールを定期的に棚卸しする運用を用意してください。三つに共通するのは、事故が起きるまで誰も気づかないという点です。

まとめ：社内ルールに書く3行と、今日確認する3つ

社内ルールに書くべきことは、多くありません。三行で足ります。一行目は、取引先から預かった秘密を含む会議では、先方の確認が取れるまでAI議事録を回さないこと。二行目は、想定していなかった機密が会議中に出たら記録を止め、止めたことと記録済みの範囲を決められた窓口へ報告すること。三行目は、使用するツールと契約プランを会社が指定したものに限り、個人アカウントでの記録を認めないこと。長い規程よりも、この三行が現場で守られるほうが実効性があります。

そのうえで、今日のうちに確認できることが三つあります。自社で使われているツールの学習設定と契約プランがどうなっているか。直近の数か月に、取引先から預かった秘密を含む会議で記録を回していないか。そして、議事録の自動配信の設定がどこ宛てになっているか。この三つを確認するだけでも、いま開いている穴の大きさが見えてきます。

あわせて読みたい

• クラウドの受注管理システムでできること｜機能表の先を読む──クラウドの利点、定着する運用、つないで効く一元化