【議事録AI】DX担当者の導入調査20時間を1記事に。「導入して大丈夫です」と言い切れる完全ガイド

約35分
生成AI記事コンテンツ
【議事録AI】DX担当者の導入調査20時間を1記事に。「導入して大丈夫です」と言い切れる完全ガイド

概要

AI議事録ツールの導入判断には、受信側(クラウドサービス側)と送信側(利用者側)の二つの視点が必要です。サービス側は法人プランの利用やセキュリティ認証で概ねクリアできますが、見落とされがちなのは送信側の問題です。特に、秘密保持契約の相手との会議内容を生成AIに処理させる行為は契約上の「第三者への開示」に該当しうるという点が最大の盲点です。サービスの体制確認、社内規程の整備、従業員リテラシーの向上の三つが揃ってはじめて、安心した導入が可能になります。

はじめに

大手が提供しているサービスだから大丈夫だろう──生成AIを日常的に使う弁護士の私でさえ、AI議事録ツールの利用規約を「軽く確認するつもり」で開きました。

結論は、予想と違うところにありました。

この問題はサービスの問題ではなく、入力するデータの理解の問題です。議事録AIを利用する企業の従業員リテラシーと社内の運用ルールこそが核心でした。

裏を返せば、データの正体を正しく理解し、ルールを整備すれば、AI議事録ツールは安心して導入できるということです。この記事では、その判断に必要な知識をすべて整理します。

1. そもそもAI議事録ツールは何をしているのか

議事録AIが行っている処理を可視化してみる

AI議事録ツールの仕組みを説明する前に、まずは実物を見てください。あなたのマイクに入った声が、どんなデータに変換されて、どこに送られるのか。実際に処理するプログラムを構築しました。

             

このアプリでは、音声はPCM(Pulse Code Modulation/パルス符号変調)と呼ばれる方式で、1秒間に48,000回サンプリングされ、浮動小数点数の配列に変換されます。この数値データには、話している内容だけでなく、声の周波数特性、倍音構造、発声のクセなど、話者を特定できる情報がすべて含まれています。近年の研究では、音声データから人物の顔画像を生成することにも成功しているほどです。

AI議事録ツールは、この数値データをインターネット経由でクラウドサーバーに送信し、サーバー側で生成AI(Whisperなど)がテキストに変換しています。利用者に返ってくるのはテキストですが、送信されているのはテキストではなく、リッチな情報を含んだ音声データそのものです。

さらに重要なのは、同じ音声データから何を抽出するかは、サーバー側の処理次第だということです。文字起こしだけでなく、話者識別も、感情分析も、技術的には同じPCMデータから実行できます。SFのようですが、技術的には話し方のトーンから、実は好意的なのか、関心がないのかなど言葉には表れていない話者の心裡を機械が判定することができます。

そして、現在のサービスが文字起こしにしか使っていなくても、送信された音声データが保存されていれば、将来的に別の分析を追加することも原理的には可能です。

これだけ豊富な情報を含むデータがクラウドに送信されるのですから、当然、それを受け取るサービス提供者側の体制が問われることになります。
具体的には、送信された音声データを文字起こし以外の目的に使わないか、データがどの国のサーバーに保存されるか、テキスト化が完了した後に元の音声データを削除するのか保持するのか、暗号化や第三者への開示の条件はどうなっているか──こうした事項が、利用規約やプライバシーポリシーで明確にされている必要があります。

様々なPCMの解析方法

ところで、わざわざサーバーにこのような重要情報を送信しなくても、公開されているプログラムを自分のパソコン内で実行させたり、パソコンに内蔵されているマイク機能を使って文字おこしすることもできます。

精度や文字おこしからさらに進んで要約を出力させるなど、複雑な使い方をするほど、クラウド処理が主な選択肢になり、単に音声データをテキストとして出力するのみであれば、ローカル環境(インターネットを使わない/外部に送信しない方法)による方法を選択することができます。

例えば、OpenAIが公開している音声認識モデル「Whisper」は、MITライセンスのオープンソースソフトウェアであり、自社のPCやサーバー上でローカル実行することができます。
この場合、音声データはインターネット上に送信されず、端末の中で処理が完結します。ただし、ローカル実行はあくまでも技術者向けの選択肢であり、一般的な企業の従業員が手軽に使えるものではありません。

Google Speech-to-Text

Whisper

OS内蔵

処理場所

クラウド(Google)

クラウド or ローカル

ローカル(端末内)

モデルアーキテクチャ

独自(非公開)

Transformer(公開)

OS依存(非公開)

日本語精度

高い

高い(特にlarge-v3)

中〜高

句読点・話者分離

APIオプションで制御可

プロンプトで誘導

基本なし〜限定的

カスタマイズ性

専門用語辞書登録可

プロンプト・ファインチューンで調整

ほぼ不可

データ送信

音声がGoogleに送られる

APIならOpenAI社に、ローカルなら端末内

端末内

このようなことから、ローカル実行のWhisperは「情報管理上最もクリーンな選択肢」ではありますが、導入ハードルが高く、全社展開には向きません。情報の機密性が極めて高い会議(取締役会、M&A関連の協議など)に限定して使う、あるいはIT担当者がいる企業での先行導入として検討するのが現実的な位置づけです。

ここまでは、音声データそのものが持つ情報の話でした。

議事録AIに渡される話題の内容を考えてみる

次に、もう一つのレイヤーにも目を向けてみましょう。音声で実際に話されている中身──発話内容です。社内会議や商談先とのWebミーティングでは、会社の重要な経営情報、従業員や顧客の個人情報、秘密保持契約のもとで進めているプロジェクトの内容など、機密性の高い話題が日常的に飛び交っています。

会社の重要な情報は不正競争防止法上の営業秘密に該当します。取締役会や重役のミーティングで話される内容には多くこのような情報が含まれると考えてよいでしょう。

【不正競争防止法 2条6項】
この法律において「営業秘密」とは、秘密として管理されている生産方法、販売方法その他の事業活動に有用な技術上又は営業上の情報であって、公然と知られていないものをいう。

会話の中に第三者が登場した場合は個人情報に該当します。例えば、「人事部の佐藤さんの給与は〇〇万円」のような情報です。

【個人情報保護法 2条1項】
この法律において「個人情報」とは、生存する個人に関する情報であって、次の各号のいずれかに該当するものをいう。
一 当該情報に含まれる氏名、生年月日その他の記述等(文書、図画若しくは電磁的記録(電磁的方式(電子的方式、磁気的方式その他人の知覚によっては認識することができない方式をいう。次項第二号において同じ。)で作られる記録をいう。以下同じ。)に記載され、若しくは記録され、又は音声、動作その他の方法を用いて表された一切の事項(個人識別符号を除く。)をいう。以下同じ。)により特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。)
二 個人識別符号が含まれるもの

他にも、営業秘密とは似て非なるものとして、守秘義務の対象となる情報があります。これは、他者から秘密保持契約や守秘義務条項への同意を経て開示された情報です。研究開発や中長期的な取引関係に入った場合に設定されることが多く、特定のプロジェクトに関して、当事者の一方から開示されたデータや資料などが典型です。営業秘密は自身の情報であるためどのように扱おうが自由ですが、守秘義務の対象となる秘密情報は他社の情報であり、その扱いは秘密保持契約や法令の中で決まっているという違いがあります。

これら議事録生成AIに渡されるデータの内容については、送信側の問題です。

全体像まとめ

つまり、AI議事録ツールに入力されるデータの分析には、二つのレイヤーがあります。音声データそのものが持つ情報(声紋、話者の特徴など)と、発話された内容が持つ情報(営業秘密、個人情報など)で、これらをクリアにすることで社内で議事録AIを活用する環境が整ってくると考えられそうです。

音声データそのものが持つ情報については、情報の送信を受けたクラウドサービス側(生成AI側)の問題として整理できます。
他方で、発話された内容が持つ情報については、情報の送信を行う側(利用者側)の問題として整理することになります。

2. 生成AI議事録を社内導入していいと言い切るための条件

受信側(クラウドサービス側)の問題──送った音声データはどう扱われるのか

1つ目のレイヤーについて考えてみましょう。1つ目のレイヤーは、音声データそのものが持つ情報についての安全性を確保することを目指し、具体的にはサービス提供者側がどのようなサービス環境を構築しているのかによって判断されるのでした。

送信される音声データは、声紋などのプロファイリング情報を含むため、セキュリティ面での安全性はもちろん、使用目的の明確化や、データの保存・管理・消去に関する体制が整っていること、データ共有についてのルールが整備されていることなどが重要となってきます。

具体的には、主に以下のような事項について利用規約やセキュリティに関する第三者認証などを踏まえながら確認していくこととなります。
これら項目は、送信情報の使用を利用者がコントロールできること、送信情報の管理体制が整っていること、これらを担保する制度があることを具体化したものです。

── 送信情報の使用を利用者がコントロールできること

① データの利用目的と目的外利用の禁止
送信された音声データがサービス提供の目的に限定して使用されるか。ユーザープロファイリングや広告への利用が禁止されているか。生成AIの基盤モデル学習への利用が禁止されている、またはオプトアウトが可能であるか。また、無料プランと有料プランで利用目的の範囲に差があるかも重要な確認事項です。

② 音声データの処理範囲
音声データに対して、文字起こし以外にどのような処理が行われるかが明示されているか。第1章で見たとおり、同じPCMデータから話者識別や感情分析なども技術的に実行可能です。サービス側が現在どの処理を行っているか、また将来的に新しい分析機能が追加された場合のデータの取り扱いについて規定があるかを確認します。

③ サービス提供者の法的立場
サービス提供者がデータプロセッサ(処理者)とデータコントローラー(管理者)のどちらの立場で処理を行うか。プロセッサであれば、顧客の指示の範囲内でのみデータが処理されます。コントローラーの場合は、サービス提供者自身の判断で利用方法を決定する権限を持つため、上記①②の実効性に直接影響します。

── 送信情報の管理体制が整っていること

④ データの保存場所(レジデンシー)
音声データおよび文字起こしデータが保存されるサーバーの所在地(国・地域)が明示されているか。日本国内のデータセンターでの保存が選択または保証されているか。なお、データの「保存」と「処理」が異なる場所で行われる場合がある点にも注意が必要です。

⑤ データの保持期間と削除
文字起こし完了後に、元の音声データがいつ削除されるか。利用者自身がデータを削除する手段が提供されているか。契約終了後のデータ削除について、期限と手順が明確に規定されているかを確認します。

⑥ データの暗号化とテナント分離
通信経路の暗号化及び保存時の暗号化といったセキュリティ措置が実装されているか。顧客ごとのデータ分離(テナント分離)が行われているかなどを確認します。

⑦ 第三者への開示・共有の条件
データが第三者と共有される条件が限定的かつ明示されているか。再委託先(サブプロセッサ)の一覧が開示されているか。法執行機関からのデータ開示要求に対する対応方針が記載されているかを確認します。

⑧ 声紋等の生体情報の取り扱い
話者識別機能がある場合、声紋データの取り扱い・保持期間・削除方法について記載があるか。声紋データがサービス改善やモデル学習に利用されないことが保証されているかを確認します。

── これらを担保する制度があること

⑨ セキュリティ認証・第三者監査
ISO 27001、ISO 27017、ISO 27018等の情報セキュリティ認証を取得しているか。SOC 2 Type II等の第三者監査レポートが入手可能か。セキュリティインシデント発生時の通知義務が規定されているか。上記①〜⑧の体制が、第三者の監査によって客観的に確認されていることが重要です。

──────────────────────────────────────────────────────────────────────

なお、上記①〜⑨のすべてを自社で一から精査するのは、時間やリソースに限りがある企業にとって現実的ではない場合もあるでしょう。

その場合は、まず⑨の担保制度(セキュリティ認証・第三者監査)から確認することをお勧めします。ISO 27001やSOC 2 Type II等の国際的なセキュリティ認証を取得しているサービスであれば、その認証取得プロセスの中で①〜⑧に相当する体制が第三者によって検証されています。十分な認証を取得しているサービスについては、コントロールや管理体制が一定の水準を満たしているという推認が働くため、そこを起点に検討を進めることができます。

大手サービスであるTeams(Microsoft 365)、Zoom、Google Meetなどは、こうした国際的なセキュリティ認証を取得した上で、送信された情報の取り扱いについて詳細なセキュリティポリシーやプライバシーポリシーを公開しています。

日本においては、政府情報システムのためのセキュリティ評価制度(ISMAP)も参考になります。ISMAPは、政府が求めるセキュリティ要求を満たしているクラウドサービスを評価・登録する制度で、登録されたサービスは政府調達の水準をクリアしていることを意味します。

ISMAPクラウドサービスリスト:https://www.ismap.go.jp/csm?id=cloud_service_list

このようなことから、大手企業の法人向けサービスであれば、セキュリティや送信情報の取り扱いに対する体制が整っており、冒頭の「大手のサービスだから大丈夫だろう」という感覚は、概ね根拠のあるものだと言えます。

生成AI議事録を導入するために絶対に見落とせないポイント

しかし、ここで絶対に見落としてはいけないポイントが2つあります。

1つ目は、法人プランと個人プランの区別です。

大手のサービスであっても、エンタープライズ(法人向け)プランと個人向けプランを分けて提供していることが多く、上記のような厳重な利用規約やポリシーが適用されるのは法人プランに限られることがほとんどです。

たとえばMicrosoftの場合、法人プラン(Business / Enterprise)ではデータ保護補遺(DPA)が適用され、ユーザープロファイリングの禁止、広告目的の利用禁止、基盤モデル学習への利用禁止、契約終了後のデータ削除義務など、上記①〜⑨の項目が契約上明確に担保されています。一方で、個人プラン(Personal / Family)にはDPAは適用されず、Microsoftサービス規約とプライバシーに関する声明が適用されます。この場合、Microsoftはデータプロセッサ(処理者)ではなくデータコントローラー(管理者)として機能し、製品改善目的でのデータ利用が規約上許容される構造となっています。

つまり、同じ「Teams」を使っていても、法人プランか個人プランかで適用される規約の体系がまったく異なります。社員がMicrosoft 365 Personalのアカウントで会議に参加し文字起こし機能を利用している場合、そのデータにはDPAの保護が及びません。

自社のプランがBusinessまたはEnterpriseであることを確認してください。最も簡単な確認方法は、Teamsにサインインしているアカウントの種類を見ることです。xxxxx@outlook.jpxxxxx@hotmail.com などの個人用Microsoftアカウントではなく、xxxxx@自社ドメイン.co.jp のような組織アカウントでサインインされていれば、法人プランが適用されています。管理者であれば、Microsoft 365管理センターにアクセスし、プランの種類やデータの保存場所を直接確認することもできます。

【Microsoftの例】
データレジデンシー例サブスクリプション例

2つ目は、利用者側の利用は適法であることが前提とされている点です。

大手のサービスであっても、利用規約上、送信される情報が適法であることを利用者側の責任としています。例えば、利用者側の送信情報やAI議事録の使用方法にそもそも法的な問題がある場合——たとえば、録音について必要な同意を得ていない、NDAに違反して秘密情報を外部サービスに送信しているなど——には、サービス提供者側も利用規約上の保護の範囲外となり、責任を負わない構造になっています。

この2つ目の傾向は、昨今のSaaS系サービスの特徴であり、生成AIが絡む場面の利用規約では頻出する条項となっています。サービスが安全な環境を提供していても、その中に何を入れるかは利用者の責任である——この構造こそが、受信側の条件だけでなく、次に検討する送信側の条件(社内ルールの整備)が不可欠である理由です。

受信側(クラウドサービス側)に関する導入するための条件まとめ

受信側(クラウドサービス側)に関する導入するための条件まとめ

ここまでの内容を、社内で導入可否を判断する際のチェックリストとしてまとめます。上司や経営層への説明資料としてもご活用ください。

□ 利用するサービスが法人向けプランであることを確認した 個人プラン(Personal / Family等)ではなく、法人プラン(Business / Enterprise等)で契約していること。社員が個人アカウントで利用していないことも併せて確認する。

□ 利用規約上、目的外利用が禁止されていることを確認した 送信データがサービス提供以外の目的(広告、プロファイリング、AI学習等)に使用されないことが利用規約またはDPA等で明記されていること。

□ データの保存場所が把握できている 音声データおよび文字起こしデータがどの国・地域のサーバーに保存されるかを確認した。必要に応じて、管理者画面等でデータレジデンシーを確認済みであること。

□ データの保持期間と削除ルールが明確である 文字起こし完了後の音声データの削除タイミング、契約終了後のデータ削除の期限が利用規約上明らかになっていること。

□ セキュリティ認証または第三者監査の実績がある ISO 27001、SOC 2 Type II、ISMAP等のセキュリティ認証を取得している、または第三者監査レポートが公開されていること。

□ サービス提供者の法的立場を確認した サービス提供者がデータプロセッサ(処理者)として機能するか、データコントローラー(管理者)として機能するかを把握していること。

□ 上記を踏まえ、利用者側の利用が適法であることが前提であると理解している サービス側の体制が整っていても、送信する情報の適法性(録音の同意取得、秘密情報の取り扱い等)は利用者企業の責任であることを認識した上で、送信側の社内ルール整備に進む準備ができていること。

送信側(利用者側)の問題──情報送信前のリテラシーと体制

次に2つ目のレイヤーについて考えてみましょう。

2つ目のレイヤーは、音声で実際に話されている中身──すなわち発話内容に含まれる情報の取り扱いです。第1章で整理したとおり、会議には営業秘密、個人情報、守秘義務を負っている情報が日常的に飛び交っています。これらの情報をAI議事録ツールに渡してよいかどうかは、サービス側ではなく、送信する側(=利用企業側)が自ら判断し、コントロールすべき問題です。

① 録音の同意取得──そもそも録音していいのか

AI議事録ツールを使うということは、会議の音声を録音し、クラウドに送信するということです。ここでまず問題になるのは、会議参加者から録音の同意を得る必要があるのかという点です。

この点、結論を先に述べると、日本法のもとでは、会話の当事者が相手方の同意なく録音を行う行為(いわゆる「秘密録音」)自体が違法とされるケースは多くありません

大阪弁護士会は「ほとんどの場合、秘密録音は違法となりません」と解説しています。この見解の根拠となっているのが、最高裁平成12年7月12日決定(刑集54巻6号513頁)です。

【最決平成12年7月12日 最高裁第二小法廷】
詐欺の被害を受けたと考えた者が、相手方の説明内容に不審を抱き、後日の証拠とするため、相手方との会話を録音することは、たとえそれが相手方の同意を得ないで行われたものであっても、違法ではなく、その録音テープの証拠能力は否定されない。

専門家の意見としてこの判例が引用されること自体は正当です。しかし、この判例の射程は慎重に捉える必要があります。上記決定は、あくまでも「録音する行為」の適法性を述べたものであり、録音されたデータをその後どのように取り扱うかまで適法と言っているわけではありません

たとえば、取引先との商談を対面で行っている場面を想像してください。相手方に告知せずに録音すること自体は、上記の判例に照らせば直ちに違法とは言い難いかもしれません。しかし、その録音データを社内サーバーに保存したり、クラウドサービスに送信して文字起こし処理にかけたり、その結果を社内で広く共有したりする行為は、録音行為とは別の法的評価を受ける可能性があります。

具体的には、録音データの利用方法次第で、プライバシー侵害名誉毀損の問題を惹起させることがありえます。また、商談の場におけるいわゆる「ここだけの話」──相手方が特定の場面でのみ共有したと合理的に信じる情報──を、AI議事録ツールで文字起こしし、社内で広範に利用するような場合には、相手方の合理的な期待を裏切る行為として、期待権の侵害(民法709条の不法行為)につながる可能性も否定できません。

【民法 第709条】
故意又は過失によって他人の権利又は法律上保護される利益を侵害した者は、これによって生じた損害を賠償する責任を負う。

つまり、「秘密録音は違法ではない」という命題は、録音行為のみに焦点を当てた場合の話であって、録音データの保存・送信・処理・共有といった後続行為を含めた全体のプロセスが当然に適法になるわけではないのです。AI議事録ツールの導入は、まさにこの後続行為(クラウド送信、テキスト化、社内共有)を前提とするものですから、録音行為単体の適法性だけでは導入の根拠として不十分です。

このようなリスクを踏まえ、多くの専門家は、録音行為が仮に違法と評価されない場合であっても、事前に同意を取得することを推奨しています。 これは、後続行為によって容易に違法性を帯びるリスクを事前に回避するためであり、また信頼関係を基礎とするビジネスの場面では、同意を得ることがマナーとして求められるためです。

ウェブ会議における同意取得の実務

ウェブ会議サービスにおいては、録音や文字起こしを開始する際に、参加者に対して事前承諾を求めるポップアップを表示する機能が実装されていることがほとんどです。たとえばTeamsの場合、録音・文字起こし開始時に全参加者に対して通知が表示され、参加者はその場で録音されていることを認識できます。

社内で確認すべき重要なチェックポイントは、この承諾通知の設定が有効化されているかどうかです。 管理者設定によっては通知が無効化されている場合もあります。ウェブ会議ツールの管理画面で、録音・文字起こし開始時に参加者全員への通知が自動的に表示される設定になっていることを確認してください。

オフライン(対面)会議における対応

対面の商談やミーティングにおいてAI議事録ツールを活用する場合は、ウェブ会議のような自動通知機能に頼ることができません。したがって、社内規程の整備が不可欠です。

前提として、商談には、個人情報や相手方企業の営業秘密など法的保護の対象となる情報が含まれうることについて、従業員のリテラシーを高める社内教育が重要です。秘密録音が違法ではないという知識だけが独り歩きし、録音後のデータの取り扱いに関する意識が欠落してしまうと、かえってリスクを拡大させることになります。

その上で、オフラインにおける議事録AI活用のための社内規程を整備し、たとえば、対面会議でAI議事録ツールを使用する場合は会議冒頭に使用の旨を告知すること、社外参加者がいる場合は事前にメール等で通知し同意を得ること、同意が得られない場合の代替運用(手動での議事録作成等)を定めておくこと、などをルール化しておくことが求められます。

② 守秘義務との関係──対外の秘密情報を処理していいのか

前項では、議事録AIを用いる際のベースとして、録音やAI処理について参加者の同意を得ることで正当性を担保する方法を検討しました。

しかし、同意があるからといって、外部参加者の発言に含まれる秘密情報までもが、当然にこの同意によって正当化されると考えるには慎重さが必要です。

ウェブ会議ツールの録音同意ポップアップひとつで、すべての行為──録音、クラウド送信、テキスト化、社内共有──を正当化させようとするのではなく、情報の性質に応じた適切な枠組みを設けるべきです。すなわち、一般的な対話内容についてはアプリケーションの同意機能により担保し、参加者の発話に含まれる秘密情報については、本来これについて規定している秘密保持契約書などで担保する方が適切です。

秘密保持契約の確認

まずは、議事録AIを利用する場面における相手方(会議参加者)との間に、秘密保持契約や秘密保持条項が存在するかを確認する必要があります。

多くの場合、秘密保持契約等に含まれる条項は、秘密情報の定義→守秘義務→秘密情報の管理・保存といった構成を含んでいます。議事録AIの使用がこれらの条項との関係でどのように評価されるかを検討することが重要です。

議事録AIの使用と秘密保持条項の関係

ここで問題になるのが、議事録AIの使用と既存の秘密保持条項との関係です。

従来のクラウドストレージサービス(BoxやGoogle Driveなど)は、いわばデジタル版の「金庫貸し出しサービス」です。ストレージ内に保存された情報について、サービス提供者はその内容にアクセスしないことを利用規約上謳っています。そのため、ストレージサービスの利用は、不正競争防止法が秘密管理性の喪失事由とする「開示」行為には該当しないと考えられてきました。

ところが、生成AIサービスは本質的に異なります。生成AIを利用する場合、入力されたデータに対して必然的に演算処理が行われ、その演算結果が出力されるというプロセスを伴います。この演算行為は、入力されたデータ──すなわち営業秘密に該当しうる情報を解析し、計算処理に供する作用を持っています。したがって、生成AIサービスへの情報入力は、ストレージサービスと同列には論じることができず、秘密保持契約上の「第三者への開示」に該当しうると考えられます。

議事録AIも生成AIサービスの一種です。つまり、会議の音声データを議事録AIに送信する行為は、秘密保持契約上の「第三者への開示」に該当する可能性があります。

既存の秘密保持契約書に「受領者は秘密情報を第三者に開示してはならない」という典型的な守秘義務条項がある場合、相手方から受領した秘密情報を含む会議を議事録AIで処理すること自体が、この守秘義務に抵触するおそれがあります。

では、どうすればよいか

この問題を解消するためには、秘密保持契約における生成AI利用に関する条項の整備が必要です。具体的には、最低限、次の2点が求められます。

第1に、使用する議事録AIサービスのプロバイダーを特定すること。議事録AIサービスの場合、アプリケーションを提供する事業者と、その裏側で音声認識や要約処理を行う基盤モデルを提供する事業者が異なる場合があります。複数のレイヤーが存在する場合は、全レイヤーのプロバイダーを特定する必要があります。

第2に、上記プロバイダーが守秘義務を負っていることを確保すること。多くの生成AIサービスでは、法人プランにおいて利用規約上の守秘義務が設定されています。この利用規約による守秘義務の構造を利用し、情報開示者のコントロールが及ぶ状態を確保します。

さらに、MCP・外部ツール連携の無効化やモデル学習へのデータ利用禁止といった技術的条件も含めて、契約上明確にしておくことが望ましいでしょう。

なお、既存の秘密保持契約にこうした条項が含まれていない場合には、相手方との間で覚書や契約変更を行い、議事録AIの利用についての同意を得ることが、運用開始前の必須ステップとなります。

③ 個人情報の取扱い──データのレジデンシー

会議や商談の内容には、参加者やその関係者の個人情報が含まれる場合が少なくありません。録音する場合の個人情報の取扱いについては、個人情報保護委員会がQ&Aにて解説を行っています。

Q1-10
顧客との電話の通話内容は個人情報に該当しますか。また、通話内容を録音している場合、録音している旨を相手方に伝えなければなりませんか。

A1-10
通話内容から特定の個人を識別することが可能な場合には個人情報に該当します。個人情報に該当する場合、個人情報取扱事業者は、個人情報保護法上、利用目的を通知又は公表する義務を負いますが、録音していることについて伝える義務までは負いません。(令和4年4月更新)

出典:個人情報保護委員会「Q&A」 https://www.ppc.go.jp/all_faq_index/faq1-q1-10/

つまり、自社のプライバシーポリシー等において個人情報の利用目的が公表されており、議事録AIの利用がその範囲に含まれていることが前提となります。

第三者提供と委託の整理

また、議論が完全に固まっているわけではありませんが、議事録AIにおいては生成AIを用いた演算処理が行われる以上、個人情報の第三者への「委託」による提供であると捉えることが適切と考えられます。

そうすると、委託先であるサービスプロバイダーに対する監督義務(個人情報保護法25条)が発生します。もっとも、この監督義務については、本記事の第2章で確認した法人プランの利用規約やセキュリティ認証(ISO 27001、SOC 2 Type II等)を通じて実質的に履行しているといえる場合が多く、議事録AIの利用のみを理由として特別な追加措置を講じる必要性までは高くないと考えられます。

海外サービスプロバイダーの場合──外国にある第三者への提供

注意が必要なのは、サービスプロバイダーが海外に所在する場合です。この場合、個人情報の「外国にある第三者への提供」(個人情報保護法28条)に該当し、単に議事録AIを用いることの同意に加えて、個人情報を外国にある第三者へ提供することについての同意が別途必要になると考えられます。

ただし、個人情報保護法施行規則が定める以下の例外に該当する場合には、この追加同意は不要となります。

第1に、サービスプロバイダーの所在地がEUまたは英国である場合です。これらの国・地域は、個人情報保護法施行規則において「個人の権利利益を保護する上で我が国と同等の水準にある」とされており、「外国」に含まれないものとして扱われます。

第2に、サービスプロバイダーがAPECの越境プライバシールール(CBPR)の認定を受けている場合です。この場合、当該事業者は「第三者」の例外に該当し、同意は不要となります。

第3に、サービスプロバイダーが個人情報保護法第4章第2節の規定に沿った体制を整備している場合も、同様に第三者の例外として扱われます。

これらの例外要件を充足するかどうかは、サービスプロバイダーが取得している第三者認証や利用規約の内容等を個別に精査する必要があり、一律の判断は困難です。

このようなことから、データのレジデンシーについては、日本国内にサーバーを有するサービスを選択することが、実務上はより望ましいといえます。

④ 自社の営業秘密との関係──議事録AIを使われる側の場合

ここまでは、自社が議事録AIを使う側としての検討を行ってきました。しかし、実際のビジネスの現場では、取引先やパートナー企業など、相手方が議事録AIを利用する場面も当然に想定されます。

もし、取引先がこの記事で検討してきたような情報保護体制──法人プランの利用、利用規約上の守秘義務の確保、セキュリティ認証の取得など──を整えていない状態で議事録AIを使用していた場合、自社の秘密情報が十分な保護のないまま外部サービスに送信されるリスクが生じます。

さらに深刻なのは、不正競争防止法上の営業秘密としての法的保護が失われるリスクです。営業秘密の保護要件である「秘密管理性」は、情報が秘密として管理されている状態を意味しますが、相手方が管理体制の不十分な議事録AIに自社の秘密情報を入力してしまった場合、自社のコントロールの及ばないところで秘密管理性が損なわれるおそれがあります。

従業員のリテラシー向上が必要

このリスクに対処するためには、従業員に対して、会議のオーナーが自社以外の場合に注意すべきポイントについてリテラシーを高めておくことが重要です。

具体的には、相手方が議事録AIの使用を告知した場合に、そのサービスの法人プランの利用有無やセキュリティ体制について確認を求めること、秘密保持契約が締結されている場合には契約上の条項と整合するかを法務部門に照会すること、場合によっては議事録AIの使用を辞退する(または自社の秘密情報に触れる議題を別の会議に分けるなどの対応をとる)こと、といった判断ができるよう、定期的な社内教育を実施することが求められます。

自社が議事録AIを導入するにあたっての体制整備と同時に、「使われる側」としての備えも忘れてはなりません。

送信側(利用者側)に関する導入するための条件まとめ

ここまでの送信側の検討内容を、社内で導入可否を判断する際のチェックリストとしてまとめます。受信側のチェックリストと併せて、上司や経営層への説明資料としてもご活用ください。

□ ウェブ会議ツールの録音・文字起こし開始時に参加者への通知が有効化されている 管理者設定で通知が無効化されていないことを確認した。

□ 対面会議における同意取得の社内規程を整備した 会議冒頭での告知、社外参加者への事前通知、同意が得られない場合の代替運用(手動での議事録作成等)を定めた。

□ 秘密保持契約に生成AI利用に関する条項が整備されている(または整備予定がある) 使用する議事録AIサービスのプロバイダーの特定、守秘義務の確保、MCP等外部ツール連携の制限が契約上明確にされている。未整備の場合は覚書や契約変更による対応を予定している。

□ 自社のプライバシーポリシーに議事録AIの利用目的が含まれている 個人情報の利用目的として、議事録AIによる処理が公表範囲に含まれていることを確認した。

□ 海外サービスプロバイダーの場合、個人情報の外国第三者提供に関する要件を確認した EU/英国所在、CBPR認定、または個人情報保護法第4章第2節準拠の体制があるか精査した。日本国内サーバーの利用を優先的に検討した。

□ 他社が議事録AIを使用する場合の自社秘密情報の保護方針を定めた 相手方が議事録AIを使用する場合の確認事項(サービス種類、プラン、セキュリティ体制)、秘密情報に触れる議題の分離、法務部門への照会手順を社内規程として整備した。

□ 上記を踏まえた従業員向けの社内教育を実施した(または実施予定がある) 録音の同意取得手順、秘密保持契約がある相手との注意点、他社会議参加時のリスクと対応について、従業員に対するリテラシー向上施策を計画・実施した。

3. 議事録生成AIを活用するにあたって社内リテラシーを高めるべきポイント

ここまで、議事録AIの導入にあたって必要な技術的理解、サービス側の体制確認、法的整理を行ってきました。しかし、これらの条件をすべてクリアしたとしても、実際に議事録AIを日々使用するのは現場の従業員です。導入後の安心した運用を実現するためには、従業員一人ひとりのリテラシーを高めることが不可欠です。

以下の4つのポイントについて、定期的なナレッジ共有を行っていくことで、組織全体として安全な運用体制を構築することができます。

採用している議事録AIのセキュリティ・プライバシー保護の理解

第1に、自社が採用している議事録AIサービスのセキュリティ体制やプライバシー保護の仕組みについて、従業員が基本的な理解を持っていることが重要です。

第2章で確認したとおり、法人プランの利用規約やデータ保護補遺(DPA)によって、送信データの目的外利用禁止、モデル学習への利用禁止、データの暗号化やテナント分離といった保護措置が講じられています。従業員がこうした保護の存在を認識していることで、「なぜ法人プランでなければならないのか」「なぜ個人アカウントで利用してはいけないのか」といった判断が自然にできるようになります。

また、第1章で解説した音声データの特性──PCMデータには声紋や話者の特徴といった豊富な情報が含まれていること──についても、基礎的な理解があれば、議事録AIに送信するデータの重要性を実感できるでしょう。

議事録AI使用時の同意取得の重要性

第2に、議事録AIを使用する際に会議参加者から同意を得ることの重要性を、従業員が十分に理解していることが必要です。

第2章の①で検討したとおり、秘密録音は直ちに違法とはされませんが、録音後のクラウド送信やテキスト化、社内共有といった後続行為を含めると、プライバシー侵害や期待権の侵害につながるリスクがあります。ウェブ会議ツールの録音同意通知が有効化されていることの確認はもちろん、対面会議においては会議冒頭での告知や事前のメール通知など、場面に応じた同意取得の手順を従業員が実践できる状態にしておく必要があります。

秘密保持を交わしている相手とのやり取りにおける注意点

第3に、秘密保持契約を締結している相手方との会議で議事録AIを使用する場合の注意点です。

第2章の②で整理したとおり、生成AIサービスへの情報入力は秘密保持契約上の「第三者への開示」に該当しうるため、既存の秘密保持契約に生成AI利用に関する条項が含まれているかの確認が前提となります。条項が未整備の場合は、覚書や契約変更によって議事録AIの利用についての同意を得る必要があることを、従業員が認識しておくべきです。

特に営業担当者や事業開発担当者など、社外との商談や協議の場に頻繁に参加する従業員に対しては、「秘密保持契約がある相手との会議では、議事録AIの使用前に法務部門に確認する」というシンプルなルールを浸透させることが有効です。

他社のウェブ会議に参加する場合の自社秘密情報の保護

第4に、第2章の④で検討した「使われる側」としてのリスクへの対応です。

取引先やパートナー企業が主催する会議において、相手方が議事録AIを使用している場合、自社の営業秘密が相手方の管理体制のもとで外部サービスに送信されることになります。相手方の情報保護体制が不十分であれば、自社の営業秘密に対する不正競争防止法上の保護が失われるリスクが生じます。

従業員には、相手方が議事録AIの使用を告知した場合に、サービスの種類やプラン、セキュリティ体制について質問すること、必要に応じて秘密情報に触れる議題を別の会議に分離すること、判断に迷う場合は法務部門に照会すること、といった行動指針を周知しておくことが重要です。

──────────────────────────────────────────────────────────────────────

これら4つのポイントは、一度の研修で完結するものではありません。議事録AIサービスのアップデートや利用規約の変更、新たな法的論点の出現に応じて、継続的にナレッジを更新し共有していくことが、安心した運用を支える基盤となります。

まとめ

AI議事録ツールの導入を「大丈夫です」と言い切るためには、サービスの仕組みを正しく理解し、受信側(クラウドサービス側)と送信側(利用者側)の両面から条件を整備することが必要でした。

まず、議事録AIが行っている処理の本質を理解すること。音声データはPCM形式で送信され、声紋など話者を特定できる情報を含んでいます。送信されるのはテキストではなく、リッチな音声データそのものです。

次に、受信側については、法人プランの利用、利用規約上の目的外利用禁止、データのレジデンシー、セキュリティ認証の取得といった体制が整っていることを確認します。
大手サービスの法人プランであれば、概ねこれらの条件は満たされています。

送信側については、録音の同意取得、秘密保持契約との整合性の確認、個人情報保護法上の要件充足、そして「使われる側」としてのリスク管理が求められます。

そして最後に、これらの仕組みを実際に機能させるのは、現場の従業員のリテラシーです。
「制度を整え、人を育てる」この両輪が揃ったとき、はじめて「導入して大丈夫です」と言い切ることができます。

すぐに使える導入チェックリスト

A. ツール選定のチェックリスト

□ 法人向けプラン(Business / Enterprise等)で契約している
個人プランではなく、DPA等が適用される法人プランであることを確認した。

□ 利用規約上、目的外利用(広告・プロファイリング・AI学習等)が禁止されている
送信データがサービス提供以外の目的に使用されないことが明記されている。

□ データの保存場所(レジデンシー)が把握できている
音声データ・文字起こしデータがどの国・地域のサーバーに保存されるかを確認した。

□ データの保持期間と削除ルールが明確である
文字起こし完了後の音声データ削除タイミング、契約終了後のデータ削除期限が規定されている。

□ セキュリティ認証(ISO 27001、SOC 2 Type II、ISMAP等)を取得している
第三者監査によって情報管理体制が客観的に検証されている。

□ サービス提供者の法的立場(プロセッサ / コントローラー)を確認した
法人プランにおいてデータプロセッサとして機能することが確認されている。

B. コンプライアンス確保のチェックリスト

□ ウェブ会議ツールの録音・文字起こし開始時に参加者への通知が有効化されている
管理者設定で通知が無効化されていないことを確認した。

□ 対面会議における同意取得の社内規程を整備した
会議冒頭での告知、社外参加者への事前通知、同意が得られない場合の代替運用を定めた。

□ 秘密保持契約に生成AI利用に関する条項が整備されている(または整備予定がある)
サービスプロバイダーの特定、守秘義務の確保、MCP等外部ツール連携の制限が契約上明確にされている。

□ 自社のプライバシーポリシーに議事録AIの利用目的が含まれている
個人情報の利用目的として、議事録AIによる処理が公表範囲に含まれていることを確認した。

□ 海外サービスプロバイダーの場合、個人情報の外国第三者提供に関する要件を確認した
EU/英国所在、CBPR認定、または法4章2節準拠の体制があるか精査した。日本国内サーバーの利用を優先的に検討した。

C. リテラシー確保のチェックリスト

□ 自社が採用している議事録AIのセキュリティ・プライバシー保護体制を従業員に周知した
法人プランの保護措置、個人アカウント利用の禁止理由等を説明した。

□ 議事録AI使用時の同意取得の手順を従業員に教育した
ウェブ会議・対面会議それぞれの場面での同意取得手順を周知した。

□ 秘密保持契約がある相手との会議での注意点を従業員に周知した
「秘密保持契約がある相手との会議では、議事録AIの使用前に法務部門に確認する」ルールを浸透させた。

□ 他社が議事録AIを使用する場合のリスクと対応を従業員に教育した
相手方のセキュリティ体制を確認する方法、秘密情報に触れる議題の分離、法務部門への照会手順を周知した。

□ 定期的なナレッジ更新の仕組みを設けた
サービスのアップデートや法改正に応じて、継続的に従業員教育を実施する体制を整備した。

この記事の内容でお困りですか?

法律相談もお見積りも、まずはお気軽にフォームからご連絡ください。原則1営業日以内にご返信します。

【議事録AI】DX担当者の導入調査20時間を1記事に。「導入して大丈夫です」と言い切れる完全ガイド | tAiL. 法律事務所