音声AIエージェントを自前構築するOSS「Dograh」の仕組みと特徴

「音声AIエージェント（電話対応や通話を自動化するAI）を自社で作りたい。でも Vapi や Retell のような SaaS は、分単位の従量課金やベンダーロックイン、そして通話データがベンダーのクラウドに出てしまうことが気になる」——音声AIの内製を検討するエンジニアが必ず突き当たるのが、この「クラウドの便利さ」と「データ主権・コスト」のトレードオフです。

特に金融・医療・保険といった規制業界では、顧客との会話データを外部クラウドに渡せないケースが多く、SaaS 型のプラットフォームは選択肢から外れがちです。かといって、STT（音声認識）・LLM・TTS（音声合成）・テレフォニーをゼロから自前で組み上げるのは、相応の工数とノウハウを要します。

そこで選択肢に挙がるのが、セルフホスト型のオープンソース（OSS）です。なかでも本記事で取り上げる Dograh（ドグラ）は、「Vapi・Retell のセルフホスト代替」を明確に標榜し、しかも OSS としては珍しいビジュアルワークフロービルダー（GUI で会話フローを組む機能） を備えた音声AIエージェントプラットフォームです。

本記事では、GitHub リポジトリ dograh-hq/dograh と公式ドキュメントをもとに、Dograh が何をする OSS なのか、その主要な機能とアーキテクチャ、セルフホストの始め方、そして Vapi・Retell や Pipecat・LiveKit といった類似プロダクトとの違いまでを整理します。最後に「どんなケースに向き、どんなケースには向かないか」という採用判断の軸まで踏み込みます。

なお本記事は、リポジトリの README・公式サイト・公式ドキュメントといった公開情報をもとにした解説です。実際のインストールや動作検証は行っておらず、機能や手順はドキュメントの記載に基づいて紹介しています。

Dograhとは｜音声AIエージェントを自前構築できるOSS

Dograh は、本番運用向けの音声AIエージェント（電話対応・通話AI）を、ドラッグ&ドロップのビジュアルワークフロービルダーで構築できる、オープンソースのセルフホスト型プラットフォームです。公式の説明では「Vapi・Retell のセルフホスト代替」と位置づけられており、オンプレミス運用、Speech-to-Speech もしくは LLM/STT/TTS をまたいだ BYOK（自分の API キー持ち込み）、ビジュアルワークフロービルダー、MCP ネイティブ、テレフォニー対応を特徴として掲げています（出典: GitHub リポジトリ dograh-hq/dograh）。

リポジトリの状態としては、アーカイブ化（開発終了）やフォーク（派生リポジトリ）ではなく、独立した本家リポジトリとして公開・メンテナンスされています。ライセンスも設定されており、後述のとおり BSD-2-Clause で公開されています。

Dograhが解決しようとしている課題

音声AIエージェントを SaaS で導入する場合、典型的に次のような懸念がつきまといます。

• ベンダーロックイン: プラットフォーム独自の設定・統合に依存し、後から別基盤へ移行しにくい
• データレジデンシー（データの所在）: 通話内容や顧客データがベンダーのクラウドを経由する
• 分単位の従量課金: 通話量が増えるほどコストが読みにくくなる

Dograh はこれらに対し、「セルフホストできる OSS であること」を解決策として打ち出しています。データは自社インフラ内に留められ、ソースコードにフルアクセスできるため独自カスタマイズが可能で、セルフホスト運用ならソフトウェア利用料は発生しません（出典: GitHub リポジトリ dograh-hq/dograh の比較表）。

リポジトリの基本データ（メンテナンス状況の客観指標）

採用を検討する際は、機能だけでなく「プロジェクトが健全に動いているか」も重要な判断材料です。Dograh のリポジトリ基本データは次のとおりです（2026年6月7日時点）。

ここから読み取れるのは、Dograh が 2025年9月に作られた比較的新しいプロジェクトでありながら、すでに 4,000 を超えるスターを集め、直近（2026年6月）まで更新が続いている、という点です。短期間で一定の注目を集めている一方で、新興プロジェクト特有のリスク（仕様変更の頻度、長期メンテナンスの不確実性、コミュニティの成熟度）は残ります。本番採用を検討する場合は、後述するように更新頻度やコミュニティの活発さを継続的に確認することをおすすめします。

なお、ライセンスの BSD-2-Clause は、著作権表示の保持を条件に商用利用・改変・再配布を広く認める寛容なライセンスです。プロプライエタリな SaaS と比べて、自社プロダクトへ組み込む際の制約が少ない点は採用判断のプラス材料になります。

Dograhの主要な特徴とアーキテクチャ

ここからは、Dograh が具体的に何を提供するのかを機能単位で見ていきます。各機能の詳細は公式ドキュメント（docs.dograh.com）で確認できます。

ビジュアルワークフロービルダー

Dograh の最大の特徴は、コードを書かずにノードをドラッグして会話フローを構築できる、ビジュアルワークフロービルダーです。会話の分岐や処理をノードとして配置し、つなぎ合わせることでエージェントの振る舞いを設計します。さらに「QA Node」を使うことで、作成したワークフローの品質を分析できるとされています。

後述するように、Pipecat や LiveKit Agents、Vocode といった他の音声AI系 OSS はいずれもコードファースト（Python などで実装する前提）です。GUI で会話フローを組めるという点は、Dograh が「Vapi の使用感を OSS で再現したい」層に強く訴求できる差別化要素になっています。

BYOK とモジュールの差し替え

Dograh は BYOK（Bring Your Own Key） をコンセプトに掲げ、LLM・STT・TTS・テレフォニーの各プロバイダを差し替えられる設計になっています。公式サイトで挙げられている統合先の例は次のとおりです。

• STT（音声認識）: Whisper / Voxtral / Canary Qwen
• TTS（音声合成）: Kokoro / Chatterbox / カスタム音声クローン
• LLM: 任意のプロバイダ（Speech-to-Speech 用には Gemini 3.1 Flash Live / GPT Realtime 2 などが挙げられています）
• テレフォニー: Twilio / Vonage / Telnyx / Cloudonix
• プラットフォーム連携: CRM / Slack / Calendly / Webhook

特定ベンダーの API に縛られず、自社の要件（精度・コスト・データ所在）に応じてコンポーネントを選べる点は、SaaS では得にくい柔軟性です。なお公式ドキュメントによると、初回起動時は API キーの事前準備が不要（自動生成される）とされており、まず触ってみる際のハードルを下げる設計になっています。

Speech-to-Speech とパイプライン構成の使い分け

Dograh は、音声処理の方式として2つのモードに対応しています。

1. パイプライン型（STT → LLM → TTS）: 音声を一度テキストに変換し、LLM で応答を生成し、再び音声に合成する従来型の構成。各段で使うモデルを細かく選べます。
2. Speech-to-Speech（S2S）型: 音声から音声へ直接処理する方式。Gemini 3.1 Flash Live や GPT Realtime 2 のようなリアルタイム音声モデルを使い、レイテンシ（応答の遅延）を抑えやすい構成です。

低レイテンシを優先するか、各コンポーネントの制御性を優先するかで使い分けられる、という設計です。

また Dograh は「ハイブリッド音声」として、録音済みの人声クリップとクローン音声 TTS を同一の声で組み合わせることで、レイテンシとコストを最大3倍削減できると公式に主張しています（あくまで公式の主張であり、本記事で計測したものではありません）。

MCP ネイティブとテレフォニー連携

Dograh は MCP（Model Context Protocol）にネイティブ対応しており、公式ドキュメントによると Claude Code や Cursor などの AI 開発ツールから MCP 経由で音声エージェントを構築・デプロイできるとされています。エディタ／エージェントから直接エージェント構成を扱える点は、開発フローに組み込みやすい特徴です。

テレフォニー面では、Twilio・Vonage・Telnyx・Cloudonix などのプロバイダと連携し、インバウンド（着信）・アウトバウンド（発信）の両方の通話、さらに人間オペレーターへの転送に対応しています。電話チャネルでの実運用を前提とした機能が一通り揃っている構成です。

DograhをDockerでセルフホストする手順

Dograh は Docker ファーストの設計で、公式 README では1つのコマンドでローカル起動できると案内されています。以下は GitHub リポジトリ dograh-hq/dograh の README に記載された起動コマンドの抜粋です（改変していません）。

curl -o docker-compose.yaml https://raw.githubusercontent.com/dograh-hq/dograh/main/docker-compose.yaml && REGISTRY=ghcr.io/dograh-hq ENABLE_TELEMETRY=true docker compose up --pull always

出典: GitHub リポジトリ dograh-hq/dograh（README）/ 公式ドキュメント

公式ドキュメントによると、起動後のおおまかな流れは次のとおりです。

• 初回起動には2〜3分ほどかかる
• 起動後は http://localhost:3010 にアクセスして管理画面を開く
• 最初のボットを作る手順は、(1) localhost:3010 を開く → (2) Inbound / Outbound を選んで命名 → (3) ユースケースを5〜10語で記述 → (4)「Web Call」で即座にテスト、という4ステップ
• 匿名テレメトリ（利用統計の送信）は、コマンド内の ENABLE_TELEMETRY を false にすることで無効化できる

本番投入前に、ダッシュボード上の「Web Call」テストモードでエージェントの挙動を確認できる点は、開発時のフィードバックループを短くしてくれます。プログラムから組み込みたい場合は、Python SDK（pypi）と Node SDK（npm）も提供されています。

繰り返しになりますが、本記事は公式ドキュメントの記載に基づいた紹介であり、上記コマンドの実行や動作確認は行っていません。実際の導入時は、お使いの環境（Docker のバージョン、ポートの空き状況、各プロバイダの API キーなど）に合わせて公式ドキュメントの最新の手順を確認してください。

Vapi・Retellや類似OSSとの違い

採用判断で最も悩ましいのが「結局、他と何が違うのか」という点です。ここでは、(1) SaaS の Vapi・Retell との違いと、(2) 同じ OSS である Pipecat・LiveKit Agents・Vocode との違いの2軸で整理します。

Vapi・Retell（SaaS）との違い

Dograh が直接の比較対象に挙げているのが、SaaS 型の音声AIプラットフォームである Vapi と Retell です。README に掲載された比較を要約すると、次のような違いになります（出典: GitHub リポジトリ dograh-hq/dograh の README 内比較表）。

要点は、Dograh が「SaaS の手軽さ（GUI ビルダーや管理画面）を保ちつつ、セルフホスト・データ主権・ソース改変の自由を確保する」という立ち位置を狙っている、という点です。逆に言えば、自社でインフラを運用・保守する責任を引き受ける前提になります。SaaS が提供する運用代行・SLA・サポートを手放してでも、データ所在とカスタマイズ性を取りたいかどうかが選択の分かれ目です。

Pipecat・LiveKit Agents・Vocode（OSSフレームワーク）との違い

音声AIエージェントを作れる OSS は Dograh だけではありません。主要な選択肢として Pipecat・LiveKit Agents・Vocode があり、それぞれ性格が異なります。

各 OSS の性格をもう少し補足します（出典: Dograh 公式ブログ「Free Alternatives to Vapi」、LiveKit Agents 公式ドキュメント、Pipecat vs LiveKit 比較記事（Cekura））。

• Pipecat: STT・VAD（音声区間検出）・LLM・TTS をつなぐパイプラインを Python で細かく制御できるフレームワークです。実は SaaS の Vapi 自体がこの Pipecat の上に構築されているとされ、いわば音声エージェントの「エンジン」に当たります。柔軟性は高い反面、GUI・ポストコール分析・CRM コネクタ・QA ツールといったプラットフォーム的な機能は付属せず、フローを変えるたびに Python を編集して再デプロイする必要があります。
• LiveKit Agents: WebRTC ネイティブで、エージェントが LiveKit の「room（部屋）」に参加者として加わる room モデルが特徴です。グループ通話、映像+音声、画面共有といったマルチ参加者シナリオがネイティブに扱えます。ただし、ビジュアルビルダーは持ちません。
• Vocode: 最も非オピニオネイテッド（決め打ちが少ない）なフレームワークです。STT/LLM/TTS を自由に差し込めますが、プラットフォーム部分は自作が前提になります。

ここから導ける選定軸はシンプルです。「GUI で会話フローを完結させたい」なら Dograh、「パイプラインを Python で握りたい」なら Pipecat、「マルチ参加者のリアルタイム通信が主役」なら LiveKit Agents、「最小限の枠組みから自作したい」なら Vocode、という整理になります。Dograh の独自ポジションは「OSS で数少ないビジュアルワークフロービルダーを持つプラットフォーム」であり、コードファーストの他 OSS とは初めから狙っている層が異なります。

Dograhが向いているケース・向かないケース

ここまでの内容を、採用判断の観点で整理します。

向いているケース

• GUI で会話フローを設計したい: 非エンジニアも含めてフローを編集したい、あるいはコード編集と再デプロイのサイクルを避けたいチーム
• データ主権が要件の規制業界: 金融・医療・保険・法務・製薬などで、通話データを自社インフラ内に留める必要がある場合。公式サイトでも FinTech・HealthTech・遠隔医療・保険・銀行・法務インテーク・防衛・政府といった領域が想定ユースケースとして挙げられています
• Vapi の使用感を OSS で再現したい: SaaS のような管理画面・ワークフロービルダーは欲しいが、ロックインや分単位課金は避けたい場合
• 運用コストをコントロールしたい: 通話量が多く、従量課金より自社インフラのほうがコストを読みやすい場合

向かない・注意したいケース

• パイプラインレベルの細かい制御を Python で握りたい: この場合は Pipecat のほうが素直です
• マルチ参加者のリアルタイム通信（グループ通話・映像）が主役: room モデルを持つ LiveKit Agents が適しています
• 長期安定性を最優先する本番採用: Dograh は2025年9月に作られた比較的新しいプロジェクトです。スター数の伸びや直近の更新は活発ですが、新興ゆえに仕様変更やメンテナンス継続の不確実性は残ります。本番投入の前には、リポジトリの更新頻度・Issue の対応状況・コミュニティの活発さを継続的に確認することをおすすめします
• インフラの運用・保守を自社で持てない: セルフホストは運用責任を伴います。SLA やサポートを重視するなら SaaS のほうが合う場面もあります

採用是非は「機能の多さ」ではなく、「自社が GUI 完結を求めるか／データ主権が要件か／運用責任を引き受けられるか」という条件で決まります。これらに当てはまるほど、Dograh は有力な候補になります。

まとめ｜Dograh採用判断のポイント

最後に、本記事で見てきた内容を採用判断の観点で振り返ります。

• 採用適合性: Dograh は「GUI で音声AIエージェントを構築でき、セルフホストでデータ主権を確保できる OSS」です。Vapi・Retell の使用感を求めつつロックインを避けたいチーム、規制業界でデータを外に出せないチームにとって有力な選択肢になります
• 類似 OSS との違い: 最大の差別化は「OSS では希少なビジュアルワークフロービルダーを持つプラットフォームである」点です。コードファーストの Pipecat・LiveKit Agents・Vocode とは狙う層が異なります。Python でパイプライン制御を握りたいなら Pipecat、マルチ参加者通信なら LiveKit Agents が適します
• メンテナンス状況: 2025年9月作成の新興プロジェクトながら、スター数 4,251・直近2026年6月まで更新が続く活発なリポジトリです。一方で新興ゆえの不確実性は残るため、継続的な状況確認が前提になります

次のアクションとしては、自社要件（必要な STT/TTS/LLM プロバイダに対応しているか、テレフォニー連携先が揃っているか、デプロイ要件を満たせるか）を公式ドキュメント（docs.dograh.com）で確認することをおすすめします。製品全体の概要やユースケースは公式サイト（dograh.com）、コードやライセンス・更新状況はGitHub リポジトリ（dograh-hq/dograh）で確認できます。これらを突き合わせれば、Dograh が自社の音声AIエージェント基盤として「採用すべきか」を、より具体的な根拠を持って判断できるはずです。