InterMINDのミーティングは何でできているか

ほとんどのプロダクトは、同じデフォルトのスタックで作られています。誰もが手を伸ばす、大手の独自仕様SaaSです。手間のかからない道ではあります。私たちは、ミーティングのデータが実際に存在するすべてのレイヤーで別の道を選びました。自社のコード、あるいは自分たちでセルフホストできるオープンソースです。

この記事は、geography(各サービスがどこで実行され、どんなデータが通過するか)を整理したInterMINDのミーティングが実際に動作する場所の姉妹編です。ここでは、セキュリティ担当者が次に尋ねる問いに答えます。これは何で作られているのか。中身を読み、監査し、置き換えられるのか。

どこで動くかではなく、何でできているかを、レイヤーごとに見ていきます。

デフォルトの選択と、そのコスト

どんなプロダクトも、選択の積み重ねでできています。多くのプロダクトでは、その大半がデフォルトで決まります。Google Analytics、Firebase、Google Translate API、Auth0、Reactなどです。手間のかからない道であり、多くのチームにとっては妥当な判断です。ただしその代償として、スタックの各部分が、中身を読めず、監査できず、書き直しなしには離れられないベンダーの背後に置かれることになります。

私たちは、ミーティングのデータが実際に存在するすべてのレイヤーで別の選択をしました。自社のコード、または自分たちでセルフホストできるオープンソースソフトウェアです。 ミーティングの内容に触れないレイヤーについては、現実的な判断をしており、その旨も明記します。全体像は次のとおりです。

中核:エンジンは第三者ではなく自社のコード

最も重要なレイヤーから始めます。ミーティングのデータの大半がここを通るからです。リアルタイム伝送と、音声・チャットの翻訳は、どちらも mind-sdk + Mind API、つまりOVH(フランス)上の自社エンジンで動いています。翻訳つきミーティングを作る一般的な方法は、リアルタイム系SaaS(LiveKit)に翻訳API(DeepL、Google)を組み合わせることです。私たちはライブの経路で、そのどちらも使っていません。第三者の翻訳モデルは経路に入っていません。(DeepLは使っていますが、用途はチャットに投下されたドキュメントに限られ、ライブの音声・チャット経路では使いません。runtime mapをご覧ください。パイプラインの仕組みは4つの翻訳パイプラインの内側で解説しました。)

runtime mapには載っていない点があります。ミーティングが動いているSDKは、BSD 3-Clauseライセンスのオープンソースです。mind-sdkクライアントはgitlab.com/mindlabs/api/sdkで公開されており、著作権者はエストニアの知的財産管理法人であるMindMeeting OÜです。SDKはapi.mind.comのMind APIと通信します。このAPIは私たちがOVH(フランス)上で自ら運用しています。

これは「見られるけれど触れない」ソース公開型の取り決めではありません。BSD 3-Clauseは、OSI承認の寛容なライセンスです。セキュリティ担当者はSDKをクローンし、音声とテキストがどのように取得され、フレーム化され、ストリーミングされるかを正確に読み、その実装を自組織の要件に照らして監査できます。SDKが通信するサーバー側のエンジンは私たち自身のもので、第三者のブラックボックスではありません。必要とするテナント向けの完全にセルフホスト可能なエンジンは、ロードマップ上にあり、現時点では提供していません。提供を開始した時点で、この記事を更新します。

レイヤーごとの比較:一般的なデフォルトと私たちの構成

この表には2つの方針が通っています。1つ目は、データを処理するツールにはオープンソースを使うことです。監査でき、原則としてセルフホストもできます。2つ目は、インフラに依存する部分にはオープンな標準(Postgres、S3 API、OIDC)を使うことです。特定ベンダーの価格やコンプライアンス方針に縛られません。PostgresはどのPostgresホストにも移せ、ストレージはどのS3ストアにも移せ、認証はお客様がすでに運用しているIDプロバイダーにフェデレーションします。最後の行は第3の軸に当たります。顧客記録を保持するCRMは、米国の営業プラットフォームではなくEU拠点(Pipedrive、エストニア)のものです。オープンソースではありませんが、米国の管轄下にもありません。

いくつかは補足しておきます。PostHogはオープンソースでセルフホストも可能ですが、私たちはPostHogのEUクラウドで運用し、自社オリジン経由でファーストパーティとしてプロキシしています。そのため、イベントが広告ブロッカーに黙って落とされることもなく、第三者の分析ドメインを経由することもありません。認証は、お客様とセッションの間に入る第三者の認証SaaSには送りません。OIDCのフローは自社で運用し、お客様が既存のGoogleまたはMicrosoftのIDにフェデレーションします。また、全ページのフォントは自社ドメインから配信しています。コードベースの中でGoogle Fontsが現れるのは、オフラインで実行するブランドアセット用スクリプトだけで、ユーザーが読み込むアプリには出てきません。

現実的に対応している部分:明言します

スタック全体が手作りだとも、米国と無関係だとも言うつもりはありません。実際そうではなく、そう主張する記事は、私たち自身のruntime mapと矛盾してしまいます。

配管部分、つまりホスティングとSSR(Vercel)、ミーティングサーバーの計算資源(Fly.io)、決済(Stripe)、トランザクションメール(Resend)は、米国拠点のSaaSで動いています。StripeとResendは請求と招待を扱い、ミーティングの内容は一切見ません。VercelとFlyは借りている計算資源です。私たち自身のコードがその上で動いており、Fly上のミーティングサーバーはライブセッションと、ダイジェストが読み取るトランスクリプトを扱います。ただしそれは、ベンダーのプロダクトがミーティングを取り込んでいるのではなく、あくまで私たちのコードが彼らのマシン上で動いているということです。そのすべては、実行時にEU内で処理されます(runtime mapの主題です)。

これは意図した、範囲を限定したトレードオフです。データプレーンは自社コードとオープンソースで持ち、コントロールプレーンには利用可能な最良のSaaSを使います。明示することが肝心です。例外を成果と並べて示さなければ、「データ主権」という言葉に意味はありません。

AIのステップと、実際に提供したプラン

言語モデルを使うステップは、AIダイジェスト(トピック、決定事項、action items)、ドキュメント要約、AIノートエディターの生成アクション、Ask AI、Miaです。これらは、組織が選択するAIゲートウェイで動きます。デフォルトはEU Data ZoneのAzure OpenAIで、選択によって、EUマルチリージョンエンドポイントのVertex AI、またはフランクフルトのAmazon Bedrockも使えます。いずれも私たち自身のテナント内で、データ保持なし、お客様のコンテンツでの学習なしで動作します。あるいは独自のOpenAI互換エンドポイントを指定すれば、モデルをお客様が管理するインフラ上に置けます。ミーティング後のサマリーと、エディターの翻訳アクションは、言語モデルではなく翻訳の経路を通ります。リアルタイムの音声、チャット、ノート、ドキュメントは、そもそも汎用LLMには一度も触れていません。

このレイヤーの実情は次のとおりです。モデルは独自仕様で、そのベンダーは、EUリージョンを運用する米国企業です。上で述べた配管部分と同じトレードオフであり、隠さずにそのすぐ隣で明示しています。自社でセルフホストするモデルの代わりに実現したのが、選択肢です。組織はAIを完全にオフにでき(文字起こしと翻訳は動き続けます)、すべてのAI機能を自分のエンドポイントに向けることもできます。自社データセンターのvLLMや、自社テナント内のデプロイメントがその例で、これによりこのレイヤーも、データプレーンの他の部分と同じ、オープンでセルフホスト可能な軸に乗ります。公開している翻訳ベンチマークは、固定のFLORES-200参照文に対し、LLMジャッジ(Gemini、フォールバックはClaude)が採点しています。誰かのミーティングが使われることはありません。

私たち以外にとっても意味があること

これは技術のための技術ではありません。このようにスタックを組む理由は、契約の相手側であるお客様の側に現れます。

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月確認)。