要旨
AI 会議アシスタントの導入により、インテリジェンスの抽出とプライバシーの保護の間に根本的な緊張が生じます。会議の音声を記録、文字起こし、分析するシステムは、同意が任意ではない領域で動作します。同意はほとんどの法域で法的要件であり、すべての法域で倫理的義務です。しかし、ほとんどの商用会議 AI ツールは、同意を通知バナーとして扱います。これは、参加者が読むか読まないかの受動的な開示であり、それに関係なく録音が進行します。
この文書では、別のアプローチを紹介します。 MARIA Meeting AI は ゲート アーキテクチャ を実装しています。これは、システムが会議データに対してアクションを実行する前に、4 つの独立したゲート (同意、スコープ、エクスポート、発言) がそれぞれ「合格」と評価される必要がある階層型評価システムです。このアーキテクチャは フェイルクローズ です。ゲートがその状態を判断できない場合、デフォルトで「保留中」または「失敗」となり、システムはそれに応じてその動作を制限します。同意なしにデータが保存されることはありません。外部参加者がいる場合、完全なトランスクリプトは保持されません。明示的な輸出承認なしにシステムからデータが流出することはありません。
このゲート アーキテクチャを代数構造として形式化し、フェール クローズされたゲートの構成がフェール クローズの特性を維持することを証明し、各ゲートが強制する情報フローの制約を導き出します。実際の貢献は、許可されたデータの保持をゼロに保ちながら、許可されたセッションの完全な文字起こし機能を実現する会議 AI システムです。
1. The Meeting Privacy Problem
1.1 Why Meetings Are Different from Documents
A document is a deliberate artifact. Its author chose to create it, reviewed its contents, and decided to share it. A meeting, by contrast, is an ephemeral event. Participants speak spontaneously. They share tentative ideas, express uncertainty, make mistakes, and correct themselves. The social contract of a meeting assumes that this stream-of-consciousness dialogue is transient — heard by those present, remembered imperfectly, and not recorded verbatim.
When an AI system transcribes a meeting, it transforms this ephemeral event into a permanent record. Every hesitation, every off-the-record comment, every half-formed thought becomes a searchable, quotable artifact. This transformation is not neutral. It changes the nature of the meeting itself. Participants who know they are being recorded behave differently — they self-censor, they speak more formally, they avoid sensitive topics. The Hawthorne effect is not a hypothetical concern; it is a documented phenomenon in recorded meeting research.
The engineering challenge is therefore not merely technical (how to transcribe accurately) but architectural (how to design a system whose privacy guarantees are as strong as its transcription capabilities).
1.2 The Consent Hierarchy
Meeting consent is not a binary state. It exists on a spectrum with distinct levels, each enabling different system capabilities:
- Level 0 — No consent: The system may join the meeting but must not capture, store, or process any audio. It operates as a silent observer with no data collection.
- Level 1 — Host consent only: The meeting host has consented to AI participation. The system may capture and process audio in real-time but applies gate restrictions to storage and distribution based on participant scope.
- Level 2 — Full participant consent: All participants have individually consented. The system has full authorization for transcription, storage, minutes generation, and distribution.
- Level 3 — Export consent: In addition to transcription consent, explicit authorization has been granted to export meeting data to external systems (email, project management tools, CRM).
MARIA Meeting AI operates primarily at Level 1 in its Phase 1 deployment — host consent is required, and the scope gate determines what can be stored based on participant composition.
2. Gate Architecture Formalization
2.1 Gate Evaluation Function
A gate is a function that maps a session state to an evaluation result. Formally:
ここで、$S$ は、考えられるすべてのセッション状態の空間です。セッション状態 $s \in S$ には、参加者リスト、同意記録、会議フェーズ、および現在のゲート結果が含まれます。各ゲートは独立して評価されます。
- Consent Gate $G_c(s)$: Evaluates whether the host has explicitly consented to AI participation.
- スコープ ゲート $G_s(s)$: すべての参加者が組織内部にいるかどうかを評価します。
- エクスポート ゲート $G_e(s)$: データのエクスポートが明示的に承認されているかどうかを評価します。
- Speak Gate $G_k(s)$: Evaluates whether the AI is authorized to produce audio output in the meeting (Phase 2 only).
2.2 The Fail-Closed Property
Definition (Fail-Closed Gate). A gate $G$ is fail-closed if and only if:
In other words, a gate can only evaluate to pass when positive evidence exists. The absence of evidence always results in pending or fail — never in pass. This is the fundamental asymmetry of the architecture: passing requires proof; failing requires only the absence of proof.
Theorem 1 (Fail-Closed Composition). If $G_1$ and $G_2$ are both fail-closed gates, then their conjunction $G_{12}(s) = G_1(s) \wedge G_2(s)$ (where $\text{pass} \wedge \text{pass} = \text{pass}$, and anything else yields the more restrictive result) is also fail-closed.
Proof. Suppose $G_{12}(s) = \text{pass}$. Then both $G_1(s) = \text{pass}$ and $G_2(s) = \text{pass}$. Since both are fail-closed, $\text{evidence}(s, G_1) \neq \emptyset$ and $\text{evidence}(s, G_2) \neq \emptyset$. Therefore $\text{evidence}(s, G_{12}) \supseteq \text{evidence}(s, G_1) \cup \text{evidence}(s, G_2) \neq \emptyset$. $\square$
This theorem is not merely academic. It guarantees that adding more gates to the system can only make it more restrictive, never less. A system with four fail-closed gates is at least as restrictive as any individual gate. This property enables compositional security reasoning — we can verify each gate independently and know that the composed system is at least as safe as any component.
2.3 Gate Evaluation Order
ゲートは独立して評価されますが、その結果はシステムの動作を決定する特定の順序で構成されます。
同意ゲートはすべてのデータ操作の前提条件です。同意がなければ、範囲やエクスポート ステータスに関係なく、データは保存されません。スコープ ゲートは、保存されるデータの粒度を制御します。外部参加者が存在する場合、(完全なトランスクリプトではなく) 概要のみが保持されます。エクスポート ゲートは、データが MARIA OS 境界を離れることができるかどうかを制御します。
3. 同意ゲートの実装
3.1 Consent Detection Methods
同意ゲートは、信号強度順に複数のチャネルを通じて同意を受け入れます。
1. Chat-based consent: The host types a specific keyword (e.g., 'CONSENT' or '同意') in the meeting chat. This produces an unambiguous, timestamped consent record. 2. Dashboard consent: The host clicks a consent button in the MARIA OS dashboard before or during the meeting. 3. Calendar-based pre-consent: When the meeting was scheduled through MARIA OS with explicit AI participation, the host's scheduling action constitutes pre-consent.
Each method produces a consent record $c = (\text{consentedBy}, \text{consentedAt}, \text{method})$ that is stored as part of the session state.
3.2 Temporal Consent Semantics
Consent is not retroactive. If the host consents at time $t_c$, only data captured after $t_c$ is eligible for storage. Data captured before consent — during the pending window — is processed in real-time but not persisted. This temporal boundary is enforced by the session manager, which tags each transcript segment with a capturedAt timestamp and compares it against $t_c$.
Definition (Consent Window). The consent window for session $s$ is the interval $[t_c, t_\text{end}]$ where $t_c$ is the consent timestamp and $t_\text{end}$ is the session end timestamp. Only data within this window is eligible for persistence.
If consent is never given during an active session, the gate evaluates to pending. When the session completes without consent, the gate transitions to fail, and all real-time data is discarded.
4. スコープゲート: 情報理論的プライバシー
4.1 内部分類と外部分類
The scope gate classifies each participant as internal or external based on their email domain. The organization maintains a whitelist of internal domains $D_\text{internal} = \{d_1, d_2, \ldots, d_k\}$. A participant $p$ with email $e$ is classified as:
電子メール アドレスを持たない参加者 (匿名または電話による参加者) は、保守的に外部として分類されます。この保守的な分類は、フェイルクローズの原則のもう 1 つの現れです。つまり、同一性に関する不確実性により、より制限的な分類が解決されます。
4.2 外部存在下でのデータ制限
When the scope gate detects external participants, it restricts the data that can be stored:
- Full transcript: NOT stored (only available during real-time processing)
- AI-generated summary: Stored (contains no verbatim quotes from external participants)
- Decision items: Stored (attributed to roles, not individuals, when external parties are involved)
- Action items: Stored with anonymized owners when assigned to external participants
This creates a two-tier storage model where internal-only meetings receive full transcript retention while mixed meetings receive summary-only retention. The information loss is intentional — it is the price of operating in a privacy-preserving mode.
4.3 Privacy Bound
スコープ ゲートは、保存されたデータに情報理論上の制限を適用します。 $I(T; P_\text{ext})$ が、保存されたトランスクリプト $T$ と外部参加者の音声 $P_\text{ext}$ の間の相互情報を表すものとします。スコープ ゲートにより、次のことが保証されます。
ここで、$\epsilon$ は、概要の情報コンテンツによって制限されます。要約は AI によって生成され (逐語的に保存されない)、講演者を引用するのではなくトピックと決定を説明するため、個々の講演者の逐語的な内容との相互情報は要約のエントロピーによって制限されます (通常、完全なトランスクリプトより 2 ～ 3 桁小さくなります)。
5. Export and Speak Gates
5.1 Export Gate
エクスポート ゲートは、会議データが MARIA OS システム境界を離れることができるかどうかを制御します。このゲートはデフォルトでは常に「保留中」になっており、ダッシュボード UI を介した明示的な承認が必要です。エクスポートと同意の分離により、参加者は、データが外部システムに送信されることに反対しながらも、組織の境界内で AI 転写に同意する可能性があることが認識されます。
エクスポート先は分類され、記録されます。
- Internal systems (Notion, internal Slack, company wiki): Requires export gate pass
- 外部システム (クライアント電子メール、パブリック プラットフォーム): エクスポート ゲート パスとスコープ ゲート パスが必要です
- Regulatory systems (audit trails, compliance databases): Exempt from export gate (governed by separate compliance framework)
5.2 Speak Gate (Phase 2)
The speak gate controls whether MARIA can produce audio output in the meeting — answering questions, providing summaries, or offering suggestions. This gate is automatically fail in Phase 1 (silent transcription mode) and becomes available in Phase 2.
The speak gate requires both consent AND phase authorization:
This ensures that Phase 1 deployments cannot accidentally enable voice output, even if all other conditions are met.
6. System Architecture and Integration
6.1 Gate Evaluation in the Session Lifecycle
Gates are evaluated at multiple points in the session lifecycle:
1. セッションの作成: すべてのゲートが「保留中」に初期化されます。 2. ボット参加: 同意ゲートが評価されます。 「保留中」の場合、ボットは参加しますが、データは保存されません。 3. 参加者の変更: 参加者が参加または脱退するたびに、スコープ ゲートが再評価されます。 4. ホストの同意を受け取りました: 同意ゲートは「合格」と再評価されます。すべての依存ゲートが再評価されます。 5. セッション終了: 結果が「保留中」のゲートは「失敗」に移行します。保存されていないデータは破棄されます。
このライフサイクルにより、ゲートは単一時点だけでなく、現在のセッション状態に対して継続的に評価されることが保証されます。
6.2 監査証跡
Every gate evaluation produces an immutable audit record:
これらの記録は、システムによって行われたすべてのプライバシーに関する決定の完全な追跡を提供します。ゲートが「保留」から「通過」に移行する場合、理由には移行をトリガーした証拠が含まれます (例: 「10:01:23 にチャット経由でホストの同意を受け取りました」)。ゲートが「失敗」に遷移する場合、理由には失敗の原因となった条件が含まれます (例: 「外部参加者が検出されました: tanaka@client.co.jp」)。
7. 結論
The gate architecture transforms meeting AI from a surveillance tool into a governed intelligence system. By making privacy the architectural foundation rather than a feature flag, MARIA Meeting AI ensures that the system's capability envelope is always bounded by its authorization state. The fail-closed composition theorem guarantees that this property holds regardless of how many gates are added or how they are composed. The result is a system where users can trust that the AI will never exceed its authorization — not because of policy, but because of architecture.
The four-gate design (Consent, Scope, Export, Speak) maps directly to the four questions that any responsible meeting AI must answer: Was recording authorized? Who was present? Where can the data go? Can the AI speak? By formalizing these questions as independently evaluable gates with fail-closed semantics, the system provides verifiable answers that can be audited, tested, and proven correct.