Vexa（Vexa-ai/vexa） は、Google Meet・Microsoft Teams・Zoom にボットが参加者として入り、話者つきの文字起こしを「自分がホストするAPI」から受け取れる、セルフホスト前提のオープンソース議事録基盤です。ライセンスは Apache-2.0、実装は Python、GitHub のスターは 2,402（本稿執筆の 2026年7月12日 JST 時点）です。

議事録AIツールは今や無数にありますが、そのほとんどは「会話をベンダーのクラウドに送って、そこにアクセス権を借りる」構造になっています。Vexa はそこを反転させ、基盤ごと自分のサーバ・VPC・エアギャップ環境で動かすという選択肢を、OSS として提供します。本稿は公式リポジトリ（README／docs）をもとに、① Vexa は結局何ができるのか、② 何を解決するのか、③ 何を代替できるのかを、仕組みから自前ホスト手順まで噛み砕いて解説します。

Vexaのアーキテクチャ：1つのAPIゲートウェイが Meetings と Agents の2ドメインに振り分け、両方が1つのruntimeの上でボット/エージェントを各々サンドボックス化したコンテナで動かす
Vexa公式のアーキテクチャ図。1つのゲートウェイが「Meetings（capture）」と「Agents（work）」の2ドメインに振り分け、どちらも同じ runtime が処理ごとにコンテナを立てて動かす（出典：Vexa-ai/vexa README）。

AIエージェントの全体像から整理したい方は、まず AIエージェントとは？仕組み・種類・代表的OSSフレームワーク【2026年版】 もあわせてどうぞ。本稿はその「会議」という入り口を、Vexa を題材に掘り下げます。

この記事のポイント
  • ・Vexaは、Meet/Teams/Zoomに実ボットが参加し、話者つき文字起こしを自分がホストするAPIで受け取れるセルフホストOSS（Apache-2.0）。
  • ・会議は自分が所有するgitのMarkdownにコンパイルされ、その上でサンドボックス化したエージェントが読み書きできる。文字起こしAPIだけの単体利用も可能。
  • ・立ち位置は「クラウドSaaS（Fireflies/Otter/Notta）」でも「ローカル録音（meetily）」でもなく、自前サーバでAPI化して所有するという第三の選択肢。
  • ・自前ホストは make all と make bot から。Docker Compose・Vexa Lite（単一コンテナ）・Kubernetes（Helm）に対応。

Vexaとは？セルフホストの議事録ボットAPIで何ができるか

まず、Vexa が提供する機能を俯瞰します。ポイントは「録って終わり」ではなく、会議を捕まえるところ（capture）から、その知識をエージェントに働かせるところ（work）までを、ひとつの基盤でカバーする点です。

Vexaでできること：会議にボット参加・話者つき文字起こしAPI・所有するMarkdown知識・エージェント・セルフホスト
Vexaの主な機能。文字起こしAPIだけを取り出して単体で使うこともできる。

公式が強調しているのは「この3つを全部そろえているツールは他にない」という主張です。順に見ていきます。

・ボットが「会議の中」にいる：Vexaは、実際のボットが Meet・Teams・Zoom に参加者として入り、進行に合わせて話者つきの文字起こしをリアルタイムに生成する。この「ボット群を安定して回す」部分こそが本当に難しいところで、世にある「ドキュメントとチャットする」系のツールは、文字起こしがすでに存在してから始まる。Vexaはその文字起こしを生み出す側を担う
・知識は「あなたが所有するファイル」：会議はgitリポジトリ内のMarkdownにコンパイルされる。ポータブルで、差分が取れて、grepできる——いわば「コードとしての知識（knowledge as code）」
・エージェントが、安全にそれを扱う：サンドボックス化したコーディングエージェント（Claude Code / Codex 等）が、そのリポジトリを開発者のように読み書きする。隔離された使い捨てコンテナで、外向き通信なし、数千を並列に、Docker でも Kubernetes でも動かせる

そして重要なのが、「文字起こしAPIだけが目的でも、それ単体で完結した製品として使える」という点です。ボットを送り、ストリームを読むだけで、エージェント側の機能を一切使わなくてもよい。まずは議事録APIとして導入し、必要になったら知識ベースやエージェントへ広げていく、という段階的な採用ができます。

この時点で、Vexa が答える3つの問いは次のように整理できます。① 何ができる＝Meet/Teams/Zoomの会議を、自前APIで話者つき文字起こしにして取り込み、知識化・エージェント化する。② 何を解決する＝会話データを外部クラウドに預けずに議事録AIを運用したい、というニーズ。③ 何を代替する＝後述するように、クラウド議事録SaaSやDIY構成（Whisper＋自作ボット）の一部を置き換えうる。

仕組み：1つのゲートウェイと2つのドメイン（Meetings と Agents）

Vexa のアーキテクチャは、1つのAPIゲートウェイの背後に、Meetings（会議を捕まえる）とAgents（知識を働かせる）という2つのドメインがあり、その両方が同じ runtime（実行基盤）の上で動く、という構造です。冒頭のアーキテクチャ図を、日本語のフローで描き直すと次のようになります。

flowchart TD GW["API Gateway
X-API-Key で認証・ルーティング"] subgraph M["Meetings（capture）"] MA["meeting-api
bots・transcripts・recordings"] BOT["vexa-bot コンテナ
会議に参加 → 録音 → Whisper"] end subgraph A["Agents（work）"] AA["agent-api
chat・routines・events"] AG["agent コンテナ
Markdown workspace を読み書き"] end RT["runtime
1処理 = 1コンテナ / docker・k8s・process"] GW -->|POST /bots| MA GW -->|POST /agent/*| AA MA -->|dispatch| RT AA -->|dispatch| RT RT --> BOT RT --> AG BOT -->|話者つき文字起こし| OUT["あなたのAPI / Redis stream"] AG -->|SSE: message-delta・commit| OUT

ここで効いているのが、「ボットとエージェントは、同じ runtime.v1 ワークロードである」という設計判断です。会議に入るボットも、知識を触るエージェントも、runtime から見れば「隔離された、使い捨ての、アイドルで回収されるコンテナ」という同じ種類の仕事にすぎません。つまり、数千のミーティングボットを本番で回してきた実績のある機構が、そのままエージェントの実行基盤にもなるわけです。図の矢印はすべて自分のネットワークの内側にとどまります。

サービスの構成もシンプルで、make all を実行すると、Docker Compose で以下が1ホスト上に立ち上がります（それぞれがループバックにバインドされた独立コンテナ）。

・gateway（:18056）：唯一の入り口。認証・スコープ・ルーティング
・terminal（:13000）：Web版のワークベンチ（/ws をゲートウェイへプロキシ）
・meeting-api：ボット・文字起こし・録音
・agent-api：エージェントの制御プレーン（dispatch・chat・routines・events）
・runtime：ボット／エージェントのコンテナを必要に応じて起動
・admin-api・redis・postgres・minio：キー発行／バス＋スケジューラ／メタデータ／オブジェクトストレージ（録音・ワークスペース）

②何を解決するかの観点で言うと、この「1ゲートウェイ・2ドメイン・1ランタイム」という構造が、会話の入口から知識の活用までを1つの境界の内側に閉じ込めることを可能にしています。データの流れが自社ネットワークの外に出ないことが、後述する規制業界での採用理由に直結します。

リアルタイム文字起こしAPIの使い方（ボット送信→取得）

では、実際に「文字起こしAPI」をどう叩くのか。Vexa のMeetings APIは、ボットを送る → 会議に入って録音・文字起こしする → 文字起こしを取得するという3段のシンプルな流れです。

Vexaのリアルタイム文字起こしAPIは3段：POST /bots でボット送信、参加して録音しWhisperで文字起こし、GET /transcripts で取得
Vexaの文字起こしAPIの流れ。難しい「ボット運用」部分を肩代わりし、開発者はAPIを叩くだけでよい。

APIキー（vxa_...）とベースURLを用意し、まず会議にボットを送ります。platform は google_meet / teams / zoom のいずれか、native_meeting_id は参加URLに含まれる会議コードです。

export API_KEY=vxa_...
export API_BASE=http://localhost:18056

# 1) 会議にボットを送り込む
curl -X POST "$API_BASE/bots" \
  -H "X-API-Key: $API_KEY" -H "Content-Type: application/json" \
  -d '{"platform":"google_meet","native_meeting_id":"abc-defg-hij","bot_name":"Vexa"}'

# 2) 会議中に文字起こしを取得（ライブ中はポーリング）
curl -H "X-API-Key: $API_KEY" \
  "$API_BASE/transcripts/google_meet/abc-defg-hij"

Meetings API には、このほかに稼働中のボット一覧（GET /bots/status）、ボットの停止・削除（DELETE /bots/{platform}/{native_meeting_id}）、会議・録音の一覧（GET /meetings・GET /recordings）といったエンドポイントが用意されています。録音は自分のオブジェクトストレージ（MinIO）に残せます。

正直なポイント：今は「ポーリング」
文字起こしは会議の進行に合わせてリアルタイムに生成され、内部ではRedisのストリームとして流れます。ただし公開APIから受け取る現在の方法は、上のように GET /transcripts/... を定期取得（ポーリング）する形です。公式のステータス表では、WebSocketによる多重ストリーミングは「Planned（計画中・今はポーリング）」と明記されています。リアルタイム性を厳密に評価するなら、この点を前提に検証するとよいでしょう。

もうひとつのAgent API側では、POST /agent/chat が Server-Sent Events（SSE） で応答をストリームします。message-delta フレームがテキストを、commit フレームがワークスペースに記録された内容を運びます。

# 自分の全ワークスペースを文脈に持つエージェントに尋ねる（SSEで応答）
curl -N -X POST "$API_BASE/agent/chat" \
  -H "X-API-Key: $API_KEY" -H "Content-Type: application/json" \
  -d '{"prompt":"直近のミーティングで何を決めた？"}'

①何ができるかが具体的に見えてきます。開発者から見れば、Vexa は「会議に入って話者つき文字起こしを吐き出してくれるボット群」を、たった数本のHTTP呼び出しに抽象化してくれる存在です。DIYでこれを作ろうとすると、Meet/Teams/Zoom それぞれのボット参加の仕組みを作り込む必要があり、そこが最大の難所になります。

所有する知識とランタイム：会議がMarkdownになり、その上でエージェントが働く

Vexa が単なる文字起こしAPIと違うのは、捕まえた会議を「あなたが所有する知識」に変える層を持っている点です。会議は、gitリポジトリ内のMarkdown——具体的には Open Knowledge Format の kg/ バンドル——にコンパイルされ、エージェント（Claude Code、Codex など）が開発者のように読み書きします。

Vexaでは会議を取り込み→Markdownのentity pagesに整理→エージェントが更新→次の会議は既知から始まる、という形で知識が複利で積み上がる
会議のたびに知識が「複利」で積み上がる。RAGのように毎回ゼロから探すのではなく、構造化された知識を育てていく発想。

この考え方は、公式が明言しているとおり Andrej Karpathy の「LLM Wiki」パターン をチームのサービスとして走らせたものです。核にある発想はこうです——生のドキュメントに対してRAGをかける（モデルが毎回ゼロから調べ直す）のではなく、ソースを構造化・相互リンクされたMarkdownのエンティティページ（人・会社・プロジェクト・決定事項）へ「コンパイル」して、知識が積み上がる（compound）ようにする。Vexaは、いちばん情報の濃いソース——あなたの会議——から、そのWikiを作ってくれます。

・マルチプレイヤー：一人の私的メモではなく、チームで共有・帰属（attribution）される知識ベース
・自動：ボットが会議を捕まえ、文字起こしが自分自身をコンパイルして入っていく
・設計として安全：エージェントは「信頼されていない存在」として扱われ、それ自身は何も強制しない。チャットであなたが書けば直接反映され（git が undo になる）、メール・Webページのような信頼できない入力は「提案のみ（propose-only）」——エージェントが提案し、人間が承認し、信頼されたコードが適用する。取り返しのつかない副作用は常にゲートされる

ここは③何を代替できるかに効く部分です。いわゆる「AIセカンドブレイン／セルフホスト知識ベース」の多くは、すでに手元にあるドキュメントを対象に推論するツールです。会議に入って一次情報を作る役割は持っていません。Vexaは会議capture（＝moat）を握り、そこからクリーンな話者つき文字起こしを供給できるため、既存のドキュメントRAGツールと競合ではなく補完の関係にもなり得ます。

現状の正直な状態
公式READMEは、キャプチャ・文字起こし・話者分離を「Production（本番）」、エージェントのdispatchコアを「Built & proven live（実装済み・ライブで実証済み）」と、段階を分けて明記しています。ワークスペースのバケット連動ストアなど、まだ着地中の部分もあります。導入検討では、この「本番／実証済み／計画中」の区別を各機能で確認するのが安全です。

エージェント・ランタイム：botもagentも同じサンドボックスで動かす

Vexa の技術的な要は runtime（エージェント・ランタイム） です。「CLIのコーディングエージェントは、Linux上ではただのプロセス」——この事実を、Vexaはマルチテナントで、サンドボックス化された、実データに向けても安全な実行層に仕立てています。そしてそれは、本番でミーティングボットを回してきたのと同じエンジンです。

Vexaのruntimeは docker（既定）・process・k8s の3バックエンドを持ち、同じruntime.v1ライフサイクルでボット/エージェントを動かす
同じ runtime.v1 のライフサイクルのまま、ワークロードの「作られ方」だけを差し替えられる。

runtime の性質は3つに要約できます。

・隔離（Isolated）：どのdispatchも自分専用のコンテナを持つ。仲介されたツール以外に外向き通信はなく、ファイルシステムには許可されたワークスペースだけが存在する。これを強制するのはエージェントではなく基盤側。エージェントは制御プレーンでは走らない
・使い捨て（Ephemeral）：コンテナは仕事の間だけ生き、アイドルで回収される。継続性はワークスペース内のセッションファイルが担う。サブ秒起動で、数千を並列に
・オーケストレーション非依存：1つの runtime.v1 ライフサイクルに、差し替え可能な基盤（substrate）

その差し替え可能な基盤（RUNTIME_BACKEND）が、次の3つです。

バックエンド ワークロードの実体 状態（公式）
docker（既定） Dockerソケット経由の専用コンテナ（make all で起動） ✅ Shipped（オープンコア）
process 子プロセス（Dockerソケット不要） ✅ Available
k8s 素の Pod（kubectl run --restart=Never）をクラスタにスケジュール ✅ ライフサイクル＋マウント単位の隔離。Helm チャートは deploy/helm

同じ制御プレーン・同じワーカーで、変わるのは「コンテナがどう作られるか」だけ。ノートPC1台から、Kubernetes / OpenShift クラスタまで、自分の壁の内側でスケールできます。①何ができるかの答えとして、Vexaは単なる議事録ツールではなく、会議も、エージェントも、同じ安全な実行基盤の上で回すためのインフラである、と捉えると位置づけがはっきりします。

セルフホスト手順：Docker Compose・Vexa Lite・Kubernetes

ここからは実際の自前ホスト手順です。Vexa は「個人・開発用途」と「クラウド・本番用途」の2つの道を、1つのコードベースで提供します。

Vexaの自前ホストは make all でスタック起動＋APIキー発行、make bot でボット像をビルド、Terminal(:13000)/API(:18056)で使う
自前ホストは実質2コマンドから。単一コンテナ版（Vexa Lite）や、本番向けの Helm on Kubernetes も選べる。

1. 個人・開発用途：Docker で丸ごと立てる

前提は Docker エンジン v26 以上。本番ターゲットは Linux（Ubuntu 24.04）ですが、ローカル評価なら Docker Desktop 入りの Mac でも動きます（いずれもコンテナで完結）。

git clone https://github.com/Vexa-ai/vexa.git && cd vexa
make all      # Docker Composeスタック一式：.env生成・ビルド・APIキー/URL表示
make bot      # ボット像をソースからビルド（ボット参加の前に必須。pullではない）

make all が完了すると、APIキーとURLが表示されます。

  Terminal UI : http://localhost:13000     # Webワークベンチ
  API gateway : http://localhost:18056     # API
  API key     : vxa_…

もっとも手早く「何ができるか」を体感するには、http://localhost:13000 のTerminal（Webワークベンチ）を開くのが近道です。すでにセルフホストのアカウントでサインイン済みの状態で、curl なしに「ボットを送る／文字起こしがライブで流れるのを見る／全会議を文脈に持つエージェントとチャットする」を試せます。単一コンテナで手軽に立てたいときは make lite（オールインワンの Vexa Lite イメージ）も使えます。

文字起こしユニットは別立て（GPU）
make all は GPUなしで動きます。文字起こしは faster-whisper ベースの別サービス（OpenAI互換）として deploy/transcription から任意のGPUマシンに立て、.env をそこに向けます。評価中は vexa.ai の無料ホストトークンを使うこともできます。文字起こしを設定しない場合、ボットは参加・録音はしますが、テキストは生成されません。

2. クラウド・本番用途：Kubernetes に Helm で

もう一方の道が、Kubernetes / OpenShift への Helm デプロイです。deploy/helm のチャートは、同じ制御プレーンを RUNTIME_BACKEND=k8s で展開します。すべてのボット・すべてのエージェントが、それぞれ1つのKubernetesワークロード（dispatchごとに素のPod）になるため、キャパシティは「もっと大きな1台」ではなく「クラスタのスケジューラ」で決まります。最初からマルチテナント・マルチユーザー向けに作られています。

ここで規約上の注意が1点あります。複数ユーザーで運用する場合、他ユーザーのターンはAPIキー（商用規約）で回す必要があり、個人のサブスクリプション資格情報を使ってはいけません。設定の Settings → Models が、ユーザー単位／グローバルの資格情報解決を強制します。個人利用で自分のClaudeサブスクリプションを再利用できる（クレジット計測される対象利用）のは、あくまで個人デプロイの範囲です。

さらに Vexa は「持ち込み（bring your own）」の設計です。

・自分の推論を持ち込む：エージェントを自分のLLMエンドポイントに向ければ、推論はネットワークの外に出ない
・エアギャップ：すべてをVPC内に、外向き通信ゼロで——規制業界が求める姿勢
・ターゲット：make all / make bot / make lite / make up / make down / make help。本番はTLSリバースプロキシでTerminalを公開する

Vexaの立ち位置：Fireflies・Otter・meetilyとの比較、そして向く人・組織

ここが読者の関心の中心、③何を代替できるのかです。結論から言うと、Vexa は「クラウドに預ける」でも「ローカルで録る」でもない、自前サーバでAPI化して所有するという第三の立ち位置にいます。

クラウドSaaSに預ける（会話はベンダー・モデル固定・席数課金・データは境界外）から、Vexaで自前ホスト（会話は境界内・自分のLLM・Apache-2.0で所有・エアギャップ可）へ
Vexaが変えるのは「借りる」から「所有する」への軸。クラウドSaaSの手軽さと引き換えに、所有と統制を取り戻す選択肢。

代表的な議事録ツールを、「どこで動くか」「会話データがどこに置かれるか」という軸で並べると、立ち位置の違いがはっきりします。

観点 Vexa meetily Fireflies / Otter / Notta Recall.ai Attendee
キャプチャ方式 実ボットが会議に参加 端末の音声を録音（ボット無し） 各社のbotが参加 ボットが参加 実ボットが参加
どこで動くか 自前サーバ／VPC／エアギャップ 各自のPC（デスクトップ） ベンダークラウド ベンダークラウド 自前
オープンソース ✅ Apache-2.0 ✅ ❌ ❌ ✅
リアルタイム文字起こしAPI ✅（今はポーリング） △ ローカルアプリ主体 一部API ✅ ✅
対応プラットフォーム Meet / Teams / Zoom 音声録音ゆえ実質不問 Meet / Teams / Zoom 各社で異なる Meet / Teams / Zoom
話者の帰属 ✅ ✅（diarization） ✅ ✅ 実装/条件次第
所有するファイルとしての知識 ✅ gitのMarkdown ローカルDB（SQLite等） ❌ ベンダー側 ❌ ❌
知識の上で動くエージェント ✅ ❌（要約が中心） ❌ ❌ ❌

要点を言葉で補足します。

・Fireflies / Otter / Notta（クラウドSaaS）：各社のノートテイカーが会議に参加し、文字起こし・要約をベンダーのクラウドに保存する。手軽で高機能な反面、会話は自社の外に出る。Vexaとの違いは「所有と統制」の軸
・meetily（ローカル完結のOSS）：端末で流れている音声を録音してローカルで文字起こし・要約する、プライバシー重視の個人向けデスクトップアプリ。ボットは会議に入らず、100%ローカル。Vexaが「チームのための自前ホストAPI」なのに対し、meetilyは「個人のPCで完結する録音ノートテイカー」。どちらもデータを手元に置ける点は共通
・Recall.ai（ホスト型のボットAPI）：発想はVexaに近い「ミーティングボットAPI」だが、各社のクラウドで動くため自前ホストはできない
・Attendee（もう一つのOSSボットAPI）：Vexa自身が「他に唯一のオープンソースのミーティングボットAPI」として名前を挙げている同種プロジェクト

Vexa が唯一そろえている組み合わせは、「Apache-2.0で許諾された、ミーティングボットAPIサーバ」が、セルフホスト × リアルタイム × マルチプラットフォーム × 知識を所有、という点です。そしてドキュメントRAGや「セカンドブレイン」系ツールとは補完関係——Vexaのクリーンな話者つき文字起こしを供給して、そちらに得意分野を任せる、という使い方もできます。

「Bird.ai」について（補足）
議事録ツールの比較でしばしば名前が挙がる「Bird.ai」については、本稿執筆時点で「議事録・文字起こしサービス」として一次情報を特定できませんでした（Fireflies・Littlebird・Otter 等の別サービスがヒットします）。誤情報を避けるため、比較表では確認できたツールに絞っています。該当製品をご存じの場合は公式情報をご確認ください。

どんな人・組織に向くか（と、正直な現状）

最後に、Vexa が誰に向くのか、そして「今はまだ来ていないもの」を正直に整理します。

もっとも噛み合うのは、銀行・医療・行政・規制業界のように「クラウドに預けること自体が制約になる」買い手です。公式はVexaを「エアギャップされた会議インテリジェンス」＝Microsoft Copilot に対する“主権的な代替”と位置づけ、Microsoft 365 Copilot や Zoom AI Companion が構造的に動かせない軸——自社クラウド／VPC／完全エアギャップ、モデルの持ち込み、席数課金でない所有、Meet＋Teams＋Zoom横断——で差別化する、と説明しています。実際に「規制対象の銀行やFortune 500が、自社のOpenShiftとローカルLLMでフルにエアギャップ運用している」とも述べています。

評価担当者向けに、セキュリティレビューで求められる成果物がリポジトリ内にそろっているのも特徴です。

・architecture.calm.json：機械可読なアーキテクチャ（FINOS CALM）。全サービスとデータフローをCIでドリフト検知
・SECURITY.md：脆弱性の報告方法
・security-insights.yml：OpenSSF Security Insights マニフェスト
・license-exceptions.json：ライセンスゲーティング（Category-Aの寛容な依存、例外は明示）
・LICENSE：Apache-2.0

一方で、「まだ来ていないもの」もはっきり書かれています。導入判断ではここを外さないことが大切です。公式のステータス表（0.12ライン）から要点を挙げます。

機能 状態
ボットが Meet / Teams / Zoom に参加 ✅ Production
リアルタイム文字起こし（Whisper）＋話者帰属 ✅ Production
録音を自分のオブジェクトストレージ（MinIO）へ ✅ Available
runtime — Docker バックエンド ✅ Production
エージェントの chat / routines / events ✅ Built & proven live
ワークスペース（git Markdown / OKF kg/） 🟡 コアは実証済み・バケット連動ストアは着地中
runtime — Kubernetes バックエンド ✅ ライフサイクル＋隔離、Helm は deploy/helm
ライブ会議のコパイロット（通話中にカード表示） 🔵 Next
WebSocket 文字起こし多重化 🔵 Planned（今はポーリング）
保存時暗号化（ワークスペース・文字起こし・トークン） 🔵 Planned
通話中のボット設定変更 / 発話（TTS） 🔵 オープンコアでは404を返す

つまり、「送る・止める・状態確認・文字起こし・録音・エージェントのchat/routines/events」は動く一方で、通話中のボット設定変更や発話、ライブ会議コパイロット、WebSocketストリーミングは、オープンコアではまだ、というのが正直な現在地です。なお公式ホスト版（vexa.ai）は 0.10.6.13 ラインで動いており、0.12 をこれからホストする、とされています。

向くのは：会話データを自社の境界から出さずに議事録AIを運用したいチーム、Meet/Teams/Zoomを横断して文字起こしAPIを自前で持ちたい開発者、規制・監査要件でエアギャップやモデル持ち込みが必要な組織。急がば別解も：とにかく今すぐ手軽に要約が欲しい個人なら、クラウドSaaSやローカルのmeetilyのほうが早いこともあります。Vexaの価値は「所有・統制・拡張性」に納得できるかどうかで決まります。

まとめ

本記事は、OSSの Vexa が 「自前サーバで動く議事録ボットAPI」 として何ができるのかを、仕組み・API・自前ホスト手順・競合との違いまで解説しました。要点を整理します。

・Vexaは、Meet/Teams/Zoomに実ボットが参加し、話者つき文字起こしを自分がホストするAPIで受け取れるセルフホストOSS（Apache-2.0）
・アーキテクチャは「1ゲートウェイ・2ドメイン（Meetings/Agents）・1ランタイム」。ボットもエージェントも同じ runtime.v1 として隔離コンテナで動く
・会議は自分が所有するgitのMarkdownにコンパイルされ、その上でサンドボックス化したエージェントが読み書きする（Karpathyの「LLM Wiki」パターン）
・自前ホストは make all / make bot から。Docker Compose・Vexa Lite・Kubernetes（Helm）に対応し、自分のLLM持ち込み・エアギャップも可能
・立ち位置は、クラウドSaaS（Fireflies/Otter/Notta）でもローカル録音（meetily）でもない「自前サーバでAPI化して所有する」第三の選択肢
・現状は正直に公開されており、WebSocketや通話中の発話などは計画中／オープンコアでは未提供

結論
Vexaの本質は、議事録ツールの機能競争ではなく、「会話データと、その上で動くエージェントを、自分の境界の内側に取り戻す」という設計思想にある。クラウドSaaSの手軽さと引き換えに所有と統制を取り、meetilyのような個人ツールとは違ってチームのためのAPIインフラとして立てられる。会話を外に出せない事情がある組織や、Meet/Teams/Zoom横断の文字起こしAPIを自前で持ちたい開発者にとって、Vexaは有力な選択肢だ。ただし「今できること／これから来るもの」の線引きを公式ステータスで確認したうえで、まずは docker compose で手元評価から始めるのが堅実である。

参照ソース

・Vexa-ai/vexa（公式GitHubリポジトリ）
・Vexa 公式ドキュメント（docs.vexa.ai）
・meetily（Zackriya-Solutions・ローカル完結の議事録OSS）
・Andrej Karpathy「LLM Wiki」パターン（gist）
・AIエージェントとは？仕組み・種類・代表的OSSフレームワーク【2026年版】（本サイト・ピラー）