Web 会議に最初から付いている AI 要約を使うか、別の要約サービスを入れるか。この判断は、要約の精度ではなく「要約と録画がどこに保存され、誰が開けて、後から探せるか」で決まります。精度は後から改善できますが、保存先と権限の設計を間違えると、数か月後に「誰も開けない議事録」や「退職者のアカウントに閉じ込められた録画」が積み上がります。
結論を先に言えば、社内の会議が中心で、すでに Microsoft 365 や Google Workspace を全社で使っているなら、まずは標準機能で始めるのが無難です。一方、商談やカスタマーサポートなど社外との会議が中心で、会議を跨いだ横断検索や CRM 連携が要るなら、別サービスを検討する価値があります。この記事では、その分かれ目を保存先・権限・検索の 3 点で整理します。
標準の AI 要約と別サービスは、そもそも何が違う？
まず前提を揃えます。Web 会議に付属する AI 要約とは、Microsoft Teams、Zoom、Google Meet などが自社のサービス内で提供する、録画・文字起こし・要点抽出の機能を指します。多くは上位ライセンスや追加オプションとして提供されます。
別サービス（以下、外部サービス）は、会議に「ボット」と呼ばれる参加者として入り込むか、録音データを受け取って、文字起こしと要約を行う独立したサービスです。会議プラットフォームを横断して使える点が特徴です。
両者の違いは機能の多寡ではなく、データがどの会社の管理下に置かれるかにあります。標準機能なら、録画も文字起こしも要約も、すでに契約している会議プラットフォーム（および連携するストレージ）の中に残ります。外部サービスを入れると、会議の音声と文字起こしが、もう 1 社の事業者の管理下にも置かれることになります。この 1 点が、後述する権限・退職処理・監査のすべてに波及します。
保存先はどこまで確認すべき？
保存先の確認は、「クラウドかオンプレミスか」という大枠だけでは足りません。発注前または契約前に、次の項目を文書で確認しておくと後が楽です。
- 実体の置き場所：録画ファイル、文字起こしテキスト、要約文がそれぞれどこに保存されるか。標準機能でも、録画は共有ストレージ、文字起こしは会議サービス側、というように分かれることがあります。
- 保存期間（リテンション）の設定単位：全社一律か、チーム単位か、会議単位か。「商談録画は 1 年、社内定例は 90 日」といった分け方ができるかどうかで、運用の手間が変わります。
- エクスポートの可否と形式：契約を終了したとき、過去の要約と文字起こしを一括で持ち出せるか。テキスト、CSV、JSON のどれで出るか。会議ごとに手作業で落とすしかない設計だと、乗り換えが事実上できなくなります。
- 学習利用の扱い：入力した音声やテキストを、事業者がモデルの学習に使わない設定になっているか。多くの法人向けプランでは学習利用をしない旨が明示されていますが、プランやリージョンによって条件が異なることがあるため、契約書と利用規約の両方で確認します。
- 保管リージョン：国内保管が必須か否か。業種によっては取引先との契約上、国内保管が求められる場合があります。
外部サービスを入れる場合、ここに「委託先の管理」という論点が加わります。個人情報保護法では、個人データの取り扱いを外部に委託する場合、委託元に委託先の監督義務があるとされています。会議の音声には参加者の氏名・所属・発言内容が含まれますから、外部サービスの利用は委託の一形態として扱うのが安全側の判断です。委託先一覧への追加、安全管理措置の確認、再委託の有無の確認を、導入前の手順に組み込んでおきます。
権限は誰が持つのが正しい？
保存先の次に効いてくるのが権限です。ここは実装時に最も揉めやすい箇所でもあります。
初期値を「作成者だけ」にするか「参加者全員」にするか
会議の録画と要約には、たいてい所有者が設定されます。既定では会議の開催者または録画を開始した人が所有者になり、参加者には閲覧権が付く、という設計が一般的です。ここで決めるべきは共有範囲の初期値です。
初期値を広くすると、採用面接や人事評価の会議の要約が、意図せず部門全体から見える状態になり得ます。逆に初期値を狭くすると、欠席者が要約を見られず「結局 Slack に貼り直す」という手戻りが発生します。現実的には、会議の種類ごとにテンプレートを分け、人事・法務・経営に関わる会議だけ狭い初期値を当てる運用が落ち着きます。
退職・異動のときに要約はどうなるか
見落とされがちなのが、所有者が退職したときの扱いです。アカウント削除とともに録画・要約が消える設計なのか、別の管理者に引き継がれるのか。標準機能ならば既存のアカウント削除手順に乗せられますが、外部サービスではそのサービス独自のユーザー管理が別に存在することが多く、退職処理の手順書に追記しないと残り続けます。
シングルサインオン（SSO、既存の社内 ID で外部サービスにログインする仕組み）と、SCIM などの自動プロビジョニング（ID の作成・停止を自動で同期する仕組み）に対応しているかは、ここで効いてきます。対応していなければ、退職者の棚卸しが手作業になります。増えた AI 契約の整理は統合より棚卸しからで触れたとおり、使っていないアカウントが残ることそのものがリスクになります。
社外の参加者をどう扱うか
商談やサポート会議では、相手方が参加者に含まれます。録音・録画について事前に同意を取る運用は、標準機能でも外部サービスでも必要です。外部サービスのボットが参加者一覧に表示される場合、相手方から「この参加者は誰か」と質問されることがあるため、説明の文面をあらかじめ用意しておくと現場が迷いません。会議の招待文に録音の旨を記載する、冒頭で口頭確認する、といった手順を決めておきます。
検索はどこまで効く？
導入半年後に効いてくるのが検索です。「あの件、どの会議で決まったか」を探せないなら、要約を取っている意味が薄れます。確認すべきは次の 3 点です。
- 横断検索の範囲：自分が参加した会議だけか、権限のある会議すべてか。チーム全体の議事録を横断して探せるかどうかで、使われ方がまったく変わります。
- 検索対象：要約文だけか、文字起こしの全文も含むか。決定事項は要約に残っても、その背景のやり取りは全文にしかないことが多いため、全文が対象かどうかは重要です。
- 既存の検索との統合：社内の文書検索やグループウェアの検索結果に、会議の要約も一緒に出るか。別々の場所を探し回る設計だと、結局使われなくなります。
標準機能は、同じプラットフォーム内の検索に乗りやすいのが強みです。外部サービスは、会議プラットフォームを跨いで検索できる一方、既存の社内検索とは別の入り口になりがちです。社内の文書検索と統合したい場合は、API でのエクスポート経路があるかを先に確認してください。ここは 社内文書検索 AI が古い規程を答えるで扱った、更新設計の話とも地続きです。古い会議の決定事項が最新の決定より上位に出てくる、という問題は議事録検索でも起こります。
3 点を並べて比べると、どう違う？
| 観点 | Web 会議標準の AI 要約 | 外部の要約サービス |
|---|---|---|
| 保存先 | 既存の契約範囲内。委託先が増えない | 事業者が 1 社増える。委託先管理の手順が要る |
| 保存期間の制御 | 既存のリテンションポリシーに乗せやすい | サービス独自の設定。全社ポリシーとの整合を取る必要がある |
| 権限管理 | 既存の ID 基盤と同一。退職処理に自動で乗る | SSO と自動プロビジョニング対応が前提条件になる |
| 検索範囲 | 同一プラットフォーム内は強い。他社会議は対象外 | 複数プラットフォームを横断できる |
| 既存検索との統合 | グループウェア検索に統合されやすい | 別の入り口になりやすい。API 連携で寄せる |
| CRM・タスク連携 | 限定的なことが多い | 連携先が豊富な製品が多い |
| 導入の重さ | ライセンス変更で済む場合がある | 契約・審査・ID 連携の工程が増える |
表を見れば分かるとおり、外部サービスの利点は横断性と連携に集中しています。逆に言えば、会議が 1 つのプラットフォームに統一されていて、CRM 連携も不要なら、外部サービスを入れる理由は薄くなります。
外部サービスを入れるとき、実装で詰まるのはどこ？
受注開発で既存の業務システムに会議要約を組み込む案件では、次の 3 か所で工期が伸びることが多くあります。
1. ボットの参加が管理者設定で弾かれる。外部サービスの多くは、ボットを会議参加者として入室させます。ところが、企業のテナント設定で外部参加者の入室を制限していると、ボットが入れません。検証環境では動いたのに本番テナントで動かない、という典型例です。会議プラットフォーム側の管理設定を、要件定義の段階で確認しておきます。
2. 話者の識別と、固有名詞の取りこぼし。誰の発言かを分ける処理（話者分離）は、複数人が同じ端末から参加している会議や、発言が重なる会議で崩れます。また、社内の製品名・取引先名・略語は、辞書登録をしないと高い確率で誤変換されます。要約の品質がここに引きずられるため、文字起こし AI は精度で選ぶと失敗するで述べた観点も合わせて確認してください。
3. 要約を業務システムに流し込む部分。「要約を自動で日報や案件管理に反映する」という要件は、実装してみると項目の対応付けで止まります。要約は自由記述のテキストですから、案件 ID や担当者、次回アクションの期日といった構造化された項目に落とすには、別途の抽出処理が必要です。ここを「AI が自動でやってくれる」と見積もると、必ず超過します。どの項目まで自動化し、どこから人が確認するかを、着手前に線引きしてください。
まとめ
会議の AI 要約をどちらで賄うかは、次の順で決めると迷いません。
- 会議プラットフォームが 1 つに統一されているか。統一されているなら、まず標準機能を試す
- 要約と録画の保存先・保存期間・エクスポート方法を文書で確認する
- 退職・異動時に、要約の所有権がどう移るかを手順書に落とせるか確認する
- 検索が「参加した会議だけ」で足りるのか、「部門全体の横断」が要るのかを現場に聞く
- 外部サービスを入れるなら、SSO・自動プロビジョニング・API エクスポートの 3 つを必須条件に置く
標準機能で始めて物足りなければ外部サービスに移る、という順序は現実的です。ただしその前提として、要約と文字起こしをテキストで持ち出せることを最初に確認しておいてください。持ち出せないまま運用すると、乗り換えのたびに過去の議事録が断絶します。
なお、会議には人事情報や取引先の機微な内容が含まれます。どの会議を録音・要約の対象にするか、逆にどの会議は対象外にするかという線引きも、ツール選定と同じくらい早い段階で決めておく価値があります。入力の段階で止める設計については、AI に渡せない入力を止める手順も参考になるはずです。