Microsoft Teams の会議を「ボットが自動で参加して自動で録画してくれる」仕組みは、多くの現場で求められています。しかし現行の Teams / Microsoft Graph / Azure Bot Service の仕様では、思った以上に制約があります。本記事では、その制約を正しく理解したうえで、現実的に組めるアーキテクチャと実装パターンを具体的に整理します。
Teams ボットによる会議自動参加・録画の全体像
まず最初に整理しておきたいのは、「通常の Teams チャットボット」だけでは、会議への参加も録画の開始もできないという点です。必要になるのは、Teams の音声・映像ストリームを扱うことができる アプリケーションホステッドメディアボット（calling bot） と、Microsoft Graph の Communication API です。
この記事でゴールとするイメージを、先にざっくりまとめます。
- ユーザーが Teams 会議を予定・開始する
- バックエンドがユーザーのカレンダー（Graph API）を監視し、対象会議を検知する
- 検知した会議に対して、ボットを「参加者として招待」する
- ボットは Graph Communication API の
joinCall/joinMeetingで会議に参加する - ボットは取得した音声・映像ストリームを自前で保存する、または別のロジックで録画をトリガーする
一方で、よくある誤解も先に潰しておきましょう。
- テナント内のすべての会議に、ボットが勝手に入って録画することはできない
- 「録画ボタンを押すための Graph API」は存在しない
- 「チャットボット」だけでは音声・映像ストリームを扱えない
これらを踏まえたうえで、どこまで自動化できるのかを、順を追って見ていきます。
課題と解決策の整理
まずはよくある要望と、それに対する現実的な解決策・考え方を表にまとめます。
| 課題 | 解決策・補足 |
|---|---|
| チャットボットでは会議参加ができない | 通常のチャットボットはテキストメッセージの送受信が主目的。会議に入るには アプリケーションホステッドメディアボット（C# / .NET）を作成し、Microsoft Graph Communication API で joinCall, joinMeeting を呼び出す必要があります。 |
| テナント内すべての会議へ無条件参加は不可能 | ボットは「招待された／許可された会議」にしか入れません。ユーザーのカレンダーを Graph API で監視し、対象会議が開始したらボットを招待して参加させる、というフローを組むのが現実的です。 |
| 録画ボタンを押す API がない | Graph API から Teams クライアントの「録画開始ボタン」を直接操作する機能はありません。会議に参加したメディアボットが取得した 生の音声・映像ストリームを自前で保存・エンコード して録画ファイルを生成するか、Teams 標準の録画機能（管理センターの設定や Power Automate など）を別途トリガーする必要があります。 |
| 必須権限と設定が複雑 | Calls.AccessMedia.All などのアプリケーション権限を Azure AD アプリに付与し、管理者同意が必須です。また Azure Bot リソースのチャネル設定で Calling を有効化し、通話イベントを受け取る Webhook URI を実装する必要があります。 |
| 実装負荷を減らしたい | 会議自動参加・録画を API で提供する外部サービス（例: ボットが会議に参加して録画するタイプの SaaS）を利用する選択肢もあります。自前実装よりも早く、安全に PoC が行えます。 |
チャットボットではなぜ会議に参加できないのか
Azure Bot Service で作成する一般的な Teams ボット（チャットボット）は、主に「メッセージ処理」に特化しています。ユーザーからのメッセージに応答したり、アダプティブカードで UI を返したりするのが主な役割で、Teams 会議の音声・映像に直接関わることは想定されていません。
会議に参加してメディアを扱うには、次のような追加要素が必要になります。
- Calling / Online Meetings に対応した Graph API の呼び出し
- RTP / SRTP などのリアルタイムメディアを扱うメディアスタック
- メディアボットのライフサイクル管理（接続・切断・再接続など）
これらを統合してくれるのが、Microsoft が提供している アプリケーションホステッドメディアボット SDK（C#/.NET） です。このボットは、Graph Communication API から通知を受け取りつつ、音声・映像ストリームを取得・送信する役割を担います。
アプリケーションホステッドメディアボットの位置づけ
構成イメージを簡単に言うと、次のようになります。
- Teams クライアント … 通常のユーザーが利用するアプリ
- Teams サーバー / Graph … 会議や通話の制御・シグナリングを担う
- メディアボット … Graph 経由で会議に参加し、メディアストリームを送受信
- バックエンド API / スケジューラ … どの会議にいつボットを参加させるかを制御
チャットボットとメディアボットは別コンポーネントとして設計することも多く、チャットボットが「この会議を録画して」と指示を受け、裏側でメディアボットを起動・参加させるといったアーキテクチャも一般的です。
「テナント内すべての会議へ無条件参加」ができない理由
次に、多くの人が最初に思い描く「理想」と現実のギャップを整理します。
よくある要望は次のようなものです。
- テナント内の全ての会議にボットを自動参加させたい
- 誰かが会議を作ったら、何もしなくても必ずボットが参加して録画するようにしたい
しかし現時点の Teams / Graph API の仕様では、ボットが「存在を知らない会議」に勝手に入り込むことはできません。参加できるのは、あくまで次のような会議だけです。
- ボット（＝Azure AD アプリ）が招待されている会議
- 組織ポリシー上、ボットの参加が許可されている会議
- Graph API 経由でボットが joinCall / joinMeeting することが許可された会議
これはプライバシー・コンプライアンスの観点からも当然で、「誰が会議に参加しているか」「会議が録音・録画されているか」をユーザーが明確に認識できるようになっている必要があります。
現実的なアプローチ：カレンダー監視＋招待ベース
ではどうするかというと、「テナント全体の会議をフックする裏技」を探すのではなく、次のような堅実なフローを設計するのが現実的です。
- 対象ユーザー（または全社）の会議予定を Graph API で取得する
- 「ボットに参加してほしい会議」の条件を決める（例: タイトルに特定キーワードが含まれる、主催者が特定の部門、特定の Teams 会議テンプレートなど）
- 会議が開始されるタイミングを検知する（開始時刻＋数分間など）
- 条件にマッチした会議に、ボットを参加者として追加・招待する
- 招待をトリガーに、ボットが Graph Communication API を通じて会議に join する
このフローなら、「ユーザーにとってもボット参加が明示的」でありつつ、「指定条件に合致した会議には自動参加」という要件を満たすことができます。
ボット参加のトリガーパターン
ボットを会議に参加させるトリガーには、いくつかのパターンがあります。
- 会議招待メールの内容を監視する
Exchange / Graph のメールボックスを監視し、会議招待メールに特定の条件があれば、ボットを追加招待する。 - カレンダーイベントの変更通知を利用する
Graph の change notification（Webhook）を利用し、会議イベントの作成・更新を契機に判定する。 - ユーザーの明示操作をトリガーにする
Teams チャットボット経由で「この会議を録画して」と指示を受けたときだけ、裏側でボットを参加させる。
要件によって組み合わせ方は変わりますが、「ボットが参加することをユーザーが意識できる設計」にしておくことが、後のトラブル回避につながります。
録画の実現方法：API で録画ボタンは押せない
次のポイントは「録画」です。残念ながら、現行の Graph API には、Teams クライアントの録画ボタンをプログラムから押すための API は存在しません。したがって、やりたいことに応じて、次のいずれか（または組み合わせ）で設計します。
パターン1：メディアボットが自前で録画する
もっとも自由度が高いのは、会議に参加したメディアボットが取得した音声・映像ストリームを、自分たちの環境で録画するパターンです。
- ボットが会議に join する
- Teams から送られてくる音声・映像ストリームを受信する
- 受信したストリームをファイルに保存する（例: MP4 / MKV など）
- 必要であれば、文字起こし・要約・インデックス付けなどの後処理を行う
この方式のメリットは次の通りです。
- 録画の開始・終了タイミングを自由に制御できる
- 解像度・ビットレート・フォーマットなどを自分で決められる
- 録画データをそのまま AI 解析（文字起こし・要約・検索など）に回せる
一方で、デメリットも小さくありません。
- リアルタイムメディア処理の知識（コーデック・バッファ管理など）が必要
- 大容量のストレージ、ネットワーク帯域を確保する必要がある
- 録画データの保管・暗号化・アクセス制御など、セキュリティ設計が重くなる
「自社プロダクトに組み込む」「録画データを高度に解析したい」など、投資する価値が明確な場合に向いているパターンです。
パターン2：Teams 標準の録画機能と連携する
もう一つの考え方は、「録画そのものは Teams 標準機能に任せ、ボットは参加だけする」というパターンです。
具体的には以下のような設計が考えられます。
- 会議の開始時に、ユーザー側で録画を開始してもらう（または会議ポリシーで自動録画を有効化する）
- ボットは録画の有無に関わらず会議に参加する（チャットへのログ投稿、参加者の収集など）
- 録画ファイル（OneDrive / SharePoint に保存されたもの）に対して、Graph API でメタデータやリンクを収集する
このアプローチでは、録画データの保存・暗号化・権限管理は基本的に Microsoft 365 側に任せることができ、自前のインフラ設計が比較的軽くなります。一方で、「完全自動録画」が要件だと、ユーザー操作やポリシー設定との組み合わせを慎重に設計する必要があります。
パターン3：外部サービス（録画 SaaS）を利用する
実装負荷を最小限にしたい場合は、「既に Teams 会議への自動参加・録画機能を提供している SaaS」を使うのも現実的です。これらのサービスは、基本的に本記事で説明しているのと似たアーキテクチャのボットを自前で運用しており、ユーザーはシンプルな API や管理画面で「どの会議を録画するか」を指定できるようになっています。
このパターンのポイントは次の通りです。
- PoC を素早く回せる（自社でメディアボットを実装しなくて良い）
- 録画データの保管場所・保持期間・暗号化などの要件を、サービスの仕様に合わせる必要がある
- 機密性の高い会議を録画する場合、契約やコンプライアンス審査が重要になる
最終的に自社実装を目指すとしても、要件の検証やユーザビリティ確認のために、一旦 SaaS で実現性を確認してから内製に切り替えるパターンもよく見られます。
必要な権限と Azure 側の設定
Teams ボットを会議に自動参加させるには、Azure AD アプリケーションに適切な権限を付与し、Azure Bot リソース側の設定も行う必要があります。
Graph API の代表的な権限
シナリオによって微調整は必要ですが、代表的なアプリケーション権限は次のようなものです。
| 権限名 | 用途 | 補足 |
|---|---|---|
Calls.AccessMedia.All | 通話・会議のメディアストリームにアクセスする | メディアボットとして音声・映像を扱う場合に必須 |
Calls.Initiate.All / Calls.JoinGroupCall.All | ボットから発呼したり、グループ通話・会議に参加する | 会議へ join するために必要 |
OnlineMeetings.Read.All | 組織内のオンライン会議情報を取得する | 対象会議の情報を取得し、join 用 URL などを知るために使用 |
Calendars.Read / Calendars.ReadBasic.All | ユーザーのカレンダー予定を取得する | どの会議にボットを参加させるかの判定に利用 |
これらの権限は、いずれも 管理者同意 が必要なアプリケーション権限であり、付与するとテナント全体に影響し得る強い権限です。PoC の段階でも、情報システム部門・セキュリティ担当との合意形成を事前に行うことを強くおすすめします。
Azure Bot リソースの設定
アプリケーションホステッドメディアボットを利用する場合、Azure Portal 上の Bot リソースで次のような設定を行います。
- チャネル設定で Microsoft Teams を有効化
- Teams チャネルの中で Calling を有効化し、通話イベントを受け取る URL（Webhook）を指定
- HTTPS で公開されたエンドポイント（ボットアプリケーション）が、Teams / Graph からのリクエストを受信できるようにする
また、メディアボットが実際に音声・映像ストリームを受信するには、Azure VM や Kubernetes クラスターなど、常時稼働する実行環境が必要になります。スケーリングや冗長構成をどうするかも、早めに検討しておきましょう。
ネットワークとセキュリティの考慮点
メディアボットは、Teams のメディアリレーサーバーと RTP / SRTP で通信します。したがって、次のような要件を満たす必要があります。
- 必要なポート（UDP）を開放する、または適切にアウトバウンド通信を許可する
- ボットが稼働するネットワークから、Microsoft 365 / Teams のエンドポイントへの通信が制限されていないこと
- 録画データを保存するストレージ（Azure Blob Storage など）のアクセス制御・暗号化を適切に設定する
クラウド上で完結させるか、オンプレミス環境とハイブリッドにするかによっても設計は変わりますが、「録画」という特性上、セキュリティレビューで厳しく見られるポイントになることを意識しておきましょう。
実装ステップの例（エンジニア向け）
ここからは、実際にシステムを構築する場合のステップを、ややエンジニア寄りの視点で整理します。言語としては、Microsoft がメディアボット SDK を提供している C# / .NET を前提とします。
ステップ1：要件の整理とスコープの決定
いきなり開発に入る前に、次のような点を決めておくと設計がスムーズになります。
- 録画対象は「特定部門だけ」なのか「全社」なのか
- 録画の開始トリガーは 「完全自動」か「ユーザーの明示指示」か
- 録画データの保持期間・保存先・暗号化ポリシー
- 録画データに対して行いたい処理（文字起こし・検索・要約など）
- PoC のスコープ（ユーザー数・期間・対象会議の種類）
これらが決まると、「自前録画が必要か」「Teams 標準録画と組み合わせるか」「外部サービスで足りるか」といった選択肢を絞り込めます。
ステップ2：Azure AD アプリと Bot のセットアップ
- Azure AD でアプリケーション登録を作成し、必要な Graph API の権限を追加
- 管理者にアプリケーション権限の同意を依頼
- Azure Portal で Bot リソースを作成し、先ほどの AAD アプリを紐づける
- Bot の Teams チャネルを有効化し、Calling 機能をオンにして Webhook URL を設定
この段階で、通話イベントの着信だけでもログに出るようにしておくと、後続のデバッグがしやすくなります。
ステップ3：カレンダー監視とボット招待ロジック
続いて、「どの会議にボットを参加させるか」を決めるロジックを実装します。
- 定期的に（例: 1分または5分間隔で）対象ユーザーのカレンダーを Graph API で取得する
- 開始時刻が近づいている会議を抽出する
- 会議タイトルや参加者、カスタムプロパティなどに基づき「録画対象かどうか」を判定する
- 録画対象であれば、その会議にボットを参加者として追加・招待する
カレンダー監視は Azure Functions や Logic Apps、あるいは自前のスケジューラを用いても構いません。最初は対象ユーザーを数人に絞って PoC し、問題がなければ徐々に対象を広げていくのがおすすめです。
ステップ4：メディアボットの join と録画処理
招待を受けたボットは、Graph Communication API を通じて会議への join を開始します。メディアボット SDK を利用すると、参加後はコールバック経由で音声・映像フレームが渡されるので、それをファイルにエンコードして保存します。
録画が完了したら、次のような後処理を行うことも多いです。
- 録画ファイルをストレージに格納し、メタデータ（会議タイトル・日時・参加者など）を付与
- Teams のチャットに「録画が完了しました」というメッセージとリンクを投稿
- 文字起こし・要約・キーワード抽出などの AI 処理を実行
この一連の流れを、キューやイベント駆動で非同期に処理することで、スケーラブルなアーキテクチャにすることができます。
ユースケース別の設計パターン
最後に、「どのような用途でボットによる会議自動参加・録画を使うのか」によって変わってくる設計パターンを簡単に紹介します。
パターンA：個人向け「自分の会議だけ自動録画」
- 対象ユーザー: 一部の社員（管理職・営業・サポート担当など）
- 録画対象: 特定のキーワードを含む会議、またはユーザーが明示的に指定した会議
- トリガー: Teams チャットボットから「この会議を録画して」と指示
- 保管: ユーザーごとの専用ストレージ領域、またはユーザーの OneDrive / SharePoint
このパターンでは、ユーザーが自分の会議を自分の意思で録画することが前提になるため、プライバシー上のハードルは比較的低めです。
パターンB：部門・プロジェクト単位の自動録画
- 対象ユーザー: 特定のチームやプロジェクト
- 録画対象: 特定の Teams チャネルで開催される会議、または特定の会議テンプレート
- トリガー: 会議テンプレートやチャネル設定に紐づける
- 保管: 部門用の SharePoint サイトやプロジェクト専用ストレージ
プロジェクトの振り返り・引き継ぎ・監査に備える目的で用いられることが多く、「会議は基本的に録画される」という文化を作りやすいパターンです。
パターンC：コンタクトセンター・サポート業務などの記録
- 対象ユーザー: 顧客対応やコールセンター業務
- 録画対象: 顧客との打ち合わせ、オンラインサポートセッション
- トリガー: 業務システム（CRM など）から API 経由で会議作成＆ボット参加
- 保管: ログ管理システムやカスタマーサポート基盤と連携
このパターンでは、業界ごとの規制（金融・医療・公共など）に応じた録画・保管ポリシーが強く求められるため、コンプライアンス担当との密な連携が欠かせません。
セキュリティ・コンプライアンス・プライバシーの注意点
会議の録画は、技術的な実現可能性だけでなく、次のような観点が非常に重要です。
- 参加者に対して録画中であることが明示されるか
- 録画データにアクセスできる人をどこまで絞り込めるか
- 録画データの保持期間・削除ポリシーが明確か
- 社外参加者がいる会議でも録画してよいのか、契約・規約でどう取り扱うか
技術的には「やろうと思えばできてしまう」ことでも、組織として許容できるかどうかは別問題です。PoC の企画時点で、情報システム部門だけでなく、コンプライアンス・法務・人事・労務などの関係者と早めに議論しておくことが、後の手戻りを防ぎます。
まとめ：何ができて、何ができないのか
最後に、本記事の内容を改めて整理します。
- 通常の Teams チャットボットだけでは、会議への参加も録画の開始もできない
- 会議に参加させるには、アプリケーションホステッドメディアボット と Graph Communication API が必要
- テナント内のすべての会議に「勝手に」参加させることはできず、招待・許可された会議にのみ参加可能
- 録画ボタンを押すための API はなく、録画は
- ボットが自前でメディアストリームを録画する
- Teams 標準の録画機能と組み合わせる
- 外部の録画 SaaS を利用する
- Graph API の強い権限（
Calls.AccessMedia.Allなど）と、Azure Bot の Calling 設定が必須 - 実装にあたっては、ネットワーク・ストレージ・セキュリティ・コンプライアンスの検討が不可欠
「Teams ボットを会議に自動参加させて録画したい」という要望は、単なるチャットボット開発の延長ではなく、リアルタイムメディア処理や組織全体のポリシー設計を含む大きなテーマです。本記事を出発点に、自社の要件・制約・投資余力を踏まえた最適なアーキテクチャを検討してみてください。
コメント