要旨
AI 会議アシスタントの導入により、インテリジェンスの抽出とプライバシーの保護の間に根本的な緊張が生じます。会議の音声を記録、文字起こし、分析するシステムは、同意が任意ではない領域で動作します。同意はほとんどの法域で法的要件であり、すべての法域で倫理的義務です。しかし、ほとんどの商用会議 AI ツールは、同意を通知バナーとして扱います。これは、参加者が読んでも読まなくてもよい受動的な開示であり、それに関係なく記録が進行します。
この文書では、別のアプローチを紹介します。 MARIA Meeting AI は ゲート アーキテクチャ を実装しています。これは、システムが会議データに対して何らかのアクションを実行する前に、4 つの独立したゲート (同意、スコープ、エクスポート、発言) がそれぞれ「合格」と評価される必要がある階層型評価システムです。このアーキテクチャは フェイルクローズ です。ゲートがその状態を判断できない場合、デフォルトで「保留中」または「失敗」となり、システムはそれに応じてその動作を制限します。同意なしにデータが保存されることはありません。外部参加者がいる場合、完全な記録は保持されません。明示的な輸出承認なしにデータがシステムから流出することはありません。
我々は、このゲート アーキテクチャを代数構造として形式化し、フェイル クローズド ゲートの構成がフェイル クローズド特性を維持することを証明し、各ゲートが強制する情報フロー制約を導き出します。実際の貢献は、許可されたデータの保持をゼロに維持しながら、許可されたセッションの完全な文字起こし機能を実現する会議 AI システムです。
1. 会議のプライバシー問題
1.1 会議はなぜ文書とは異なるのか
ドキュメントは意図的に作成された成果物です。その作成者はそれを作成することを選択し、その内容を検討して、共有することにしました。対照的に、会議は一時的なイベントです。参加者は自発的に発言します。彼らは暫定的なアイデアを共有し、不確実性を表明し、間違いを犯し、自分自身を修正します。会議の社会契約は、この意識の流れの対話が一時的なものであること、つまり出席者によって聞かれ、不完全に記憶されており、逐語的に記録されていないことを前提としています。
AI システムが会議を文字に起こすと、この一時的なイベントが永続的な記録に変わります。あらゆるためらい、あらゆるオフレコのコメント、あらゆる中途半端な考えが、検索可能で引用可能な成果物になります。この変化は中立的なものではありません。それは会議そのものの性質を変えます。自分たちが録音されていることを知っている参加者は、普段とは異なる行動をします。自己検閲し、よりフォーマルに話し、デリケートな話題を避けます。ホーソン効果は仮説上の懸念ではありません。それは記録された会議の調査で文書化された現象です。
したがって、エンジニアリング上の課題は、単に技術的 (どのように正確に転写するか) ではなく、アーキテクチャー (転写機能と同じくらい強力なプライバシー保証を持つシステムを設計する方法) にもなります。
1.2 同意の階層
会議の同意は二項対立の状態ではありません。これは異なるレベルのスペクトル上に存在し、それぞれが異なるシステム機能を有効にします。
- レベル 0 — 同意なし: システムは会議に参加できますが、音声をキャプチャ、保存、または処理してはなりません。データ収集を行わないサイレントオブザーバーとして動作します。
- レベル 1 — 主催者の同意のみ: 会議の主催者は AI の参加に同意しています。システムはリアルタイムで音声をキャプチャして処理できますが、参加者の範囲に基づいてストレージと配信にゲート制限を適用します。
- レベル 2 — 参加者全員の同意: すべての参加者が個別に同意しています。システムには、転記、保存、議事録の生成、および配布に対する完全な権限があります。
- レベル 3 — エクスポートの同意: 文字起こしの同意に加えて、会議データを外部システム (電子メール、プロジェクト管理ツール、CRM) にエクスポートするための明示的な承認が付与されています。
MARIA Meeting AI は、フェーズ 1 展開では主にレベル 1 で動作します。主催者の同意が必要であり、スコープ ゲートは参加者の構成に基づいて保存できる内容を決定します。
2. ゲートアーキテクチャの形式化
2.1 ゲート評価機能
ゲートは、セッション状態を評価結果にマッピングする機能です。正式には:
ここで、$S$ は、考えられるすべてのセッション状態の空間です。セッション状態 $s \in S$ には、参加者リスト、同意記録、会議フェーズ、および現在のゲート結果が含まれます。各ゲートは独立して評価されます。
- 同意ゲート $G_c(s)$: ホストが AI の参加に明示的に同意したかどうかを評価します。
- スコープ ゲート $G_s(s)$: すべての参加者が組織内部にいるかどうかを評価します。
- エクスポート ゲート $G_e(s)$: データのエクスポートが明示的に承認されているかどうかを評価します。
- Speak Gate $G_k(s)$: AI が会議で音声出力を生成する権限を持っているかどうかを評価します (フェーズ 2 のみ)。
2.2 フェールクローズ プロパティ
定義 (フェイルクローズされたゲート)。 ゲート $G$ は、次の場合にのみフェイルクローズされます。
言い換えれば、ゲートは肯定的な証拠が存在する場合にのみ「合格」と評価できます。証拠がない場合は常に「保留」または「不合格」になります。「合格」になることはありません。これはアーキテクチャの基本的な非対称性です。合格するには証明が必要です。失敗するには証拠がないことが必要です。
定理 1 (フェイルクローズ合成)。 $G_1$ と $G_2$ が両方ともフェイルクローズされたゲートである場合、それらの論理積 $G_{12}(s) = G_1(s) \wedge G_2(s)$ ($\text{pass} \wedge \text{pass} = \text{pass}$、およびより制限的な結果が得られる他のもの) もフェイルクローズされます。
証明 $G_{12}(s) = \text{pass}$ と仮定します。この場合、$G_1(s) = \text{pass}$ と $G_2(s) = \text{pass}$ の両方が得られます。どちらもフェールクローズされるため、$\text{evidence}(s, G_1) \neq \emptyset$ と $\text{evidence}(s, G_2) \neq \emptyset$ になります。したがって $\text{evidence}(s, G_{12}) \supseteq \text{evidence}(s, G_1) \cup \text{evidence}(s, G_2) \neq \emptyset$ となります。 $\正方形$
この定理は単なる学術的なものではありません。システムにゲートを追加すると、制限が厳しくなるだけで、制限が緩和されることはありません。 4 つのフェールクローズ ゲートを備えたシステムは、少なくとも個々のゲートと同じくらい制限的です。この特性により、構成的なセキュリティ推論が可能になります。つまり、各ゲートを個別に検証でき、構成されたシステムが少なくとも他のコンポーネントと同じくらい安全であることがわかります。
2.3 ゲートの評価順序
ゲートは独立して評価されますが、その結果はシステムの動作を決定する特定の順序で構成されます。
同意ゲートはすべてのデータ操作の前提条件です。同意がなければ、範囲やエクスポート ステータスに関係なく、データは保存されません。スコープ ゲートは、保存されるデータの粒度を制御します。外部参加者が存在する場合、(完全なトランスクリプトではなく) 概要のみが保持されます。エクスポート ゲートは、データが MARIA OS 境界を離れることができるかどうかを制御します。
3. 同意ゲートの実装
3.1 同意の検出方法
同意ゲートは、信号強度順に複数のチャネルを通じて同意を受け入れます。
1. チャットベースの同意: 主催者は、会議チャットで特定のキーワード (「同意」または「同意」など) を入力します。これにより、明確なタイムスタンプ付きの同意レコードが生成されます。 2. ダッシュボードの同意: 主催者は、ミーティング前またはミーティング中に MARIA OS ダッシュボードの同意ボタンをクリックします。 3. カレンダーベースの事前同意: AI が明示的に参加して MARIA OS を通じて会議がスケジュールされた場合、主催者のスケジュール設定アクションは事前同意を構成します。
各メソッドは、セッション状態の一部として保存される同意レコード $c = (\text{consentedBy}, \text{consentedAt}, \text{method})$ を生成します。
3.2 一時的な同意のセマンティクス
同意は遡及的ではありません。ホストが $t_c$ 時点で同意した場合、$t_c$ 以降にキャプチャされたデータのみがストレージの対象となります。同意前 (「保留中」期間) にキャプチャされたデータはリアルタイムで処理されますが、永続化されません。この時間的境界はセッション マネージャーによって強制され、各トランスクリプト セグメントに capturedAt タイムスタンプのタグが付けられ、それを $t_c$ と比較します。
定義 (同意ウィンドウ)。 セッション $s$ の同意ウィンドウは、$[t_c, t_\text{end}]$ の間隔です。ここで、$t_c$ は同意タイムスタンプ、$t_\text{end}$ はセッション終了タイムスタンプです。このウィンドウ内のデータのみが永続化の対象となります。
アクティブなセッション中に同意が得られなかった場合、ゲートは「保留中」と評価されます。同意なしにセッションが完了すると、ゲートは「失敗」に移行し、すべてのリアルタイム データが破棄されます。
4. スコープゲート: 情報理論的プライバシー
4.1 内部分類と外部分類
スコープ ゲートは、電子メール ドメインに基づいて各参加者を内部または外部に分類します。組織は、内部ドメイン $D_\text{internal} = \{d_1, d_2, \ldots, d_k\}$ のホワイトリストを管理しています。電子メール $e$ を持つ参加者 $p$ は次のように分類されます。
電子メール アドレスを持たない参加者 (匿名または電話による参加者) は、保守的に外部として分類されます。この保守的な分類は、フェイルクローズの原則のもう 1 つの現れです。つまり、同一性に関する不確実性により、より制限的な分類が解決されます。
4.2 外部存在下でのデータ制限
スコープ ゲートが外部参加者を検出すると、保存できるデータが制限されます。
- 完全なトランスクリプト: 保存されません (リアルタイム処理中にのみ利用可能)
- AI が生成した概要: 保存 (外部参加者からの逐語的な引用は含まれません)
- 意思決定項目: 保存 (外部関係者が関与する場合、個人ではなく役割に帰属)
- アクションアイテム: 外部参加者に割り当てられる場合、匿名化された所有者とともに保存されます。
これにより、内部のみの会議では完全な記録が保持され、混合会議では概要のみが保持される 2 層ストレージ モデルが作成されます。情報の損失は意図的なものであり、プライバシー保護モードでの運用の代償となります。
4.3 プライバシーの限界
スコープ ゲートは、保存されたデータに情報理論上の制限を適用します。 $I(T; P_\text{ext})$ を、保存されたトランスクリプト $T$ と外部参加者の音声 $P_\text{ext}$ の間の相互情報を表すものとします。スコープ ゲートにより、次のことが保証されます。
ここで、$\epsilon$ は、概要の情報コンテンツによって制限されます。要約は AI によって生成され (逐語的に保存されない)、講演者を引用するのではなくトピックと決定を説明するため、個々の講演者の逐語的な内容との相互情報は要約のエントロピーによって制限されます (通常、完全なトランスクリプトより 2 ~ 3 桁小さくなります)。
5. ゲートのエクスポートと読み上げ
5.1 輸出ゲート
エクスポート ゲートは、会議データが MARIA OS システム境界を離れることができるかどうかを制御します。このゲートはデフォルトでは常に「保留中」になっており、ダッシュボード UI を介した明示的な承認が必要です。エクスポートと同意の分離により、参加者は、データが外部システムに送信されることに反対しながら、組織の境界内で AI 転写に同意できることが認識されます。
エクスポート先は分類され、記録されます。
- 内部システム (Notion、社内 Slack、会社 Wiki): エクスポート ゲート パスが必要です
- 外部システム (クライアント電子メール、パブリック プラットフォーム): エクスポート ゲート パスとスコープ ゲート パスが必要です
- 規制システム (監査証跡、コンプライアンス データベース): 輸出ゲートから免除されます (別のコンプライアンス フレームワークによって管理されます)
5.2 スピークゲート (フェーズ 2)
スピーキング ゲートは、MARIA が会議中に音声出力 (質問に答える、要約を提供する、または提案を提供する) を生成できるかどうかを制御します。このゲートはフェーズ 1 (サイレント転写モード) では自動的に「失敗」し、フェーズ 2 で使用可能になります。
スピーキング ゲートには、同意とフェーズ承認の両方が必要です。
これにより、他のすべての条件が満たされている場合でも、フェーズ 1 の導入で誤って音声出力が有効になることがなくなります。
6. システムのアーキテクチャと統合
6.1 セッションライフサイクルにおけるゲート評価
ゲートはセッション ライフサイクルの複数の時点で評価されます。
1. セッションの作成: すべてのゲートが「保留中」に初期化されます。 2. ボット参加: 同意ゲートが評価されます。 「保留中」の場合、ボットは参加しますが、データは保存されません。 3. 参加者の変更: 参加者が参加または脱退するたびに、スコープ ゲートが再評価されます。 4. ホストの同意を受け取りました: 同意ゲートは「合格」と再評価されます。すべての依存ゲートが再評価されます。 5. セッション終了: 結果が「保留中」のゲートは「失敗」に移行します。保存されていないデータは破棄されます。
このライフサイクルにより、ゲートは単一時点だけでなく、現在のセッション状態に対して継続的に評価されることが保証されます。
6.2 監査証跡
すべてのゲート評価により、不変の監査レコードが生成されます。
これらの記録は、システムによって行われたすべてのプライバシーに関する決定の完全な追跡を提供します。ゲートが「保留」から「通過」に移行する場合、理由には移行をトリガーした証拠が含まれます (例: 「10:01:23 にチャット経由でホストの同意を受け取りました」)。ゲートが「失敗」に遷移する場合、理由には失敗の原因となった条件が含まれます (例: 「外部参加者が検出されました: tanaka@client.co.jp」)。
7. 結論
ゲート アーキテクチャは、会議 AI を監視ツールから管理されたインテリジェンス システムに変換します。 MARIA Meeting AI は、プライバシーを機能フラグではなくアーキテクチャ基盤にすることで、システムの機能エンベロープが常にその認証状態によって制限されるようにします。フェールクローズ合成定理により、追加されるゲートの数やゲートの構成に関係なく、この特性が維持されることが保証されます。その結果、ポリシーではなくアーキテクチャによって、AI がその許可を決して超えないことをユーザーが信頼できるシステムが誕生しました。
4 つのゲート設計 (同意、範囲、エクスポート、発言) は、責任ある会議 AI が答えなければならない 4 つの質問に直接対応しています: 録音は許可されましたか?誰が出席していましたか?データはどこに行くことができますか? AIは話せるのか?これらの質問をフェールクローズ セマンティクスを備えた独立して評価可能なゲートとして形式化することで、システムは監査、テスト、および正しいことが証明できる検証可能な回答を提供します。