1つのInterMINDミーティングが何で構築されているか

ほぼすべての製品は、誰もが手にする巨大なプロプライエタリなSaaSのデフォルトという、同じデフォルトのスタックから構築されています。これらは摩擦の少ない道です。ミーティングデータが実際に存在するすべてのレイヤーにおいて、私たちは別の道を選びました：独自のコード、または自己ホスト可能なオープンソースです。

これは、各サービスがどこで実行され、どのようなデータが通過するかという*ジオグラフィ（地理）*をマッピングした1つのInterMINDミーティングが実際に実行される場所の補足資料です。この投稿は、セキュリティチームが次に尋ねる質問に答えます：これは何で構築されており、私たちはそれを読み、監査し、置き換えることができるか？

それがどこで実行されるかではなく — 何で作られているかを、レイヤーごとに説明します。

デフォルトのスタックとその代償

すべての製品は選択のスタックです。ほとんどの製品において、その選択のほとんどはデフォルトで決まっています：Google Analytics、Firebase、Google Translate API、Auth0、Reactなどです。これらは摩擦の少ない道であり、ほとんどのチームにとっては妥当な判断です。その代償として、それぞれの選択がスタックの一部を、読むことも、監査することも、書き直しなしには離れることもできないベンダーの背後に置くことになります。

私たちは、ミーティングデータが実際に存在するすべてのレイヤーで異なる選択をしました：独自のコード、または自己ホスト可能なオープンソースソフトウェアです。 レイヤーがミーティングのコンテンツに触れない場合、私たちはプラグマティックな対応をとり、そのように明記します。全体像は以下の通りです。

中核：エンジンはサードパーティではなく私たちのコード

最も重要なレイヤーから始めましょう。ミーティングの大部分がそこを通るからです。リアルタイムトランスポートおよび音声/チャット翻訳は、どちらも**mind-sdk + Mind API — OVH France上の独自のエンジン**で実行されます。翻訳されるミーティングを構築する一般的な方法は、リアルタイムSaaS（LiveKit）を翻訳API（DeepL、Google）に接続することですが、私たちはライブパスでどちらも実行しません。サードパーティの翻訳モデルはループに入りません。（私たちはDeepLを使用しますが、チャットにドロップされたドキュメントに対してのみであり、ライブの音声/チャットパスではありません。ランタイムマップを参照してください。パイプラインの仕組みについては、4つの翻訳パイプラインの内部で解説しました。）

ランタイムマップに記載されていない部分があります：ミーティングが実行されるSDKはBSD 3-Clauseライセンスの下でオープンソースであり、mind-sdkクライアントはgitlab.com/mindlabs/api/sdkで公開されており、著作権は私たちのエストニアのIPエンティティであるMindMeeting OÜに帰属します。これは、私たちがOVH France上で自己実行するapi.mind.comのMind APIと通信します。

これは「見ることはできても触れない」ソースアベイラブルな取り決めではありません。BSD 3-Clauseは寛容なOSI承認ライセンスです。お客様のセキュリティチームはSDKをクローンし、音声やテキストがどのようにキャプチャ、フレーミング、ストリーミングされるかを正確に読み取り、独自の要件に対してその統合を監査できます。それが通信するサーバー側のエンジンは私たちのものです — サードパーティのブラックボックスではありません — そして、それを必要とするテナント向けの完全に自己ホスト可能なエンジンは、ロードマップ上にあり、今日提供しているものではありません。出荷された瞬間にこの投稿を更新します。

レイヤーごと：デフォルトと私たちが実行しているもの

この表には2つの筋が走っています。ツールがお客様のデータを処理する場所でのオープンソース — これにより監査が可能になり、原則として自己ホストも可能です。私たちがインフラストラクチャに依存する場所でのオープン標準（Postgres、S3 API、OIDC）— これにより、あるベンダーの価格設定やコンプライアンス態勢にロックインされることはありません。Postgresは任意のPostgresホストに移動できます。ストレージは任意のS3ストアに移動できます。認証はお客様が既に実行しているアイデンティティプロバイダにフェデレーションします。最後の行は第3の軸にあります：顧客レコードを保持するCRMは、USの営業プラットフォームではなく、EUに拠点を置く（Pipedrive、エストニア）ものです — オープンソースではありませんが、USの管轄下にもありません。

これらのいくつかはもう一言説明する価値があります。PostHogはオープンソースで自己ホスト可能です。私たちはそれをPostHogのEUクラウドで実行し、独自のオリジンを通じてファーストパーティとしてプロキシするため、イベントが広告ブロッカーによってサイレントにドロップされることなく、かつサードパーティのアナリティクスドメインを通過しません。認証が、お客様とお客様のセッションの間に位置するサードパーティの認証SaaSに渡されることはありません — 私たちがOIDCフローを自分たちで実行し、お客様の既存のGoogleまたはMicrosoftのアイデンティティにフェデレーションします。そして、すべてのページのフォントは独自のドメインから提供されます。Google Fontsが私たちのコードベースに現れる唯一の場所は、オフラインのブランドアセットスクリプトであり、ユーザーが読み込むアプリには決して現れません。

プラグマティックな対応をしている部分 — 明確に記載

スタック全体が手作りである、あるいは非USであると装うつもりはありません。そうではありませんし、そのように主張する投稿は、私たち自身のランタイムマップによって矛盾するでしょう。

配管 — ホスティングとSSR（Vercel）、ミーティングサーバーのコンピュート（Fly.io）、決済（Stripe）、トランザクショナルメール（Resend）— は、US拠点のSaaS上で実行されます。StripeとResendは請求と招待を処理し、ミーティングのコンテンツを見ることはありません。VercelとFlyはレンタルされたコンピュートです：独自のコードがそれらの上で実行され、Fly上のミーティングサーバーはライブセッションと私たちのダイジェストが読むトランスクリプトを処理します — しかしそれは、彼らのマシン上で実行される私たちのコードであり、お客様のミーティングを取り込むベンダー製品ではありません。それらはすべて、実行時にEUで実行されます（ランタイムマップの主題です）。

これは意図的で境界のあるトレードオフです：データプレーンを所有してオープンソース化し、コントロールプレーンには利用可能な最適なSaaSを使用します。それを明確にすることがポイントです — 例外が成功の隣にテーブルに置かれていなければ、「主権」はほとんど意味を持ちません。

ミーティング後のAIステップとプラン

US拠点のプロプライエタリなモデルは、ミーティング由来のコンテンツに一切触れません。通話後に実行される言語モデルのステップ — AIダイジェスト（トピック、決定事項、アクションアイテム）、ミーティング後のサマリー、およびAIノートエディタ — はすべてEUのプロセッサ上にあります。ダイジェストとエディタの生成アクションは、データ保持ゼロのEUでホストされたMistral（VercelのAI Gatewayを通じてMistralプロバイダにピン留め）で実行されます。サマリーとエディタの翻訳アクションは、OVH上の独自のEUエンジン — ライブ音声とチャットの背後にあるものと同じ — で実行されます。リアルタイムの音声、チャット、ノート、ドキュメントは、そもそも汎用LLMの近くにすら寄りませんでした。

ループ内に残っている唯一のUSモデルは、私たちの公開翻訳ベンチマークを採点するものです — 固定されたFLORES-200リファレンス文の機械翻訳を採点するものであり、誰のミーティングでもありません。

私たちはEU-Mistralのステップについてさらに進んでいます：ダイジェストを完全にオフにするオーナー制御のオプトアウト、および外部Mistralを置き換えるためのOVH上の自己ホストされたオープンウェイトのサマライゼーションモデル（Kimi-class）です。オープンウェイトのルートのポイントは、どのラボがウェイトをトレーニングしたかではなく、オープンウェイトが私たちが制御するインフラストラクチャ上で実行できることです。これにより、データプレーンの他の部分と同じオープンかつ自己ホスト可能な軸上に保たれます。どちらもロードマップ上にあり、出荷されたものではありません。それらが実現したらこの投稿を更新します。

なぜこれが私たちを超えて重要なのか

これはエンジニアリングのためのエンジニアリングではありません。このようにスタックを構築する理由は、契約のあなた側に現れます：

1. 監査可能。 ミーティングが実行されるSDKはセキュリティチームが読めるオープンソースコードであり、その背後にあるエンジンはサードパーティのブラックボックスではなく私たちのものです。
2. ポータブル。 すべてのデータレイヤーでのオープン標準 — Postgres、S3、OIDC — はプロプライエタリなロックインがないことを意味します。移動できるものは単一のベンダーに縛られません。
3. 自己ホスト可能。 オープン標準のデータレイヤー — Postgres、S3、OIDC — はすでに制御下のインフラストラクチャで実行されています。それを必要とするテナント向けの完全に自己ホスト可能な翻訳エンジンはロードマップ上にあります。

これは2026-06-07時点の状況です。スタックが変更された時点 — ベンダーの入れ替え、レイヤーの再構築、ダイジェストモデルの置き換え — で更新します。現在の構成は、公開されているvercel.json、nuxt.config.ts、および上記でリンクしたBSD-3-Clauseのmind-sdkリポジトリで検証可能です。

ここのレイヤーが間違っていると思われる場合、またはこのマップが提供していない答えをセキュリティレビューで必要とする場合は、ご連絡ください。コード監査でお客様に見つけていただくより、欠落している詳細を修正したいと考えています。

情報源: mind-sdkリポジトリ (BSD-3-Clause), FLORES-200; スタックの事実は、デプロイされた構成（vercel.json, nuxt.config.ts）および出荷されたコードに対して検証済み、2026年8月確認。