Blandの最高情報責任者、Juan E. Riojas：インタビューシリーズ

Juan E. Riojasは、Blandの最高情報責任者を務める、テクノロジーとデータ分野で豊富な経験を持つ経営幹部です。エンタープライズIT、データ管理、アナリティクス、オペレーション、デジタルトランスフォーメーションにわたるキャリアを積んできました。2025年12月にBlandに加わる前は、TwilioとRackspace Technologyで最高情報責任者を務め、それ以前にはInformaticaの最高データ責任者、Gogoのデータ管理・アナリティクス担当副社長としてリーダーシップを発揮しました。また、Dell、Accenture、Expeditors International、OfficeMax、AxonGroupで上級運用職および管理職を経験しており、大規模な組織におけるテクノロジーやデータ関連の取り組みを管理してきた豊富な実績があります。

Blandは、受発信の電話応対、カスタマーサポート、スケジュール調整、問い合わせ受付、ルーティングなど、複雑な業務プロセスに対応できるAIエージェントを開発する、エンタープライズ向け音声AI企業です。同社のプラットフォームは、基盤となるテクノロジースタックを自社で管理できることを重視しています。Blandは独自の音声、言語、発話モデルを開発・運用し、Bland Cloud、プライベート仮想プライベートクラウド、または完全なセルフホスト型かつ外部ネットワークから隔離されたエンタープライズ環境での導入に対応しています。特に規制対象となる用途や高度なセキュリティが求められる用途に注力しており、会話フロー、既存の電話システムとの連携、設定可能なデータ保持、役割ベースのアクセス制御、エンタープライズ向けコンプライアンス機能などを提供しています。

TwilioとRackspaceで最高情報責任者を務め、Informaticaでは最高データ責任者を担い、キャリアの大半を通信インフラとエンタープライズデータに携わってきました。そうした経験を通じて、企業がAIを導入する際に直面する障壁について何を学びましたか。また、その経験は、現在Blandで構築しているセルフホスト型プラットフォームにどのような影響を与えていますか？

Twilio、Rackspace、Informaticaでの経験から、企業がAIを導入するうえで最大の障壁となるのはテクノロジーではなく、信頼と管理能力、そして大規模環境で安全に運用する力だと学びました。企業は、データがどこに保存され、誰が管理しているのか、また、長年かけて築いてきたセキュリティやガバナンスの枠組みにAIを組み込めるのかを把握する必要があります。こうした経験がBlandのアプローチを形作りました。企業が自社のインフラやデータに対する管理権を手放すことなく、AIの力を活用できるセルフホスト型プラットフォームを提供しています。

Blandは唯一のセルフホスト型音声AIプラットフォームであり、音声認識、LLMの推論、音声合成に至るまで、AIオーケストレーションのあらゆるレイヤーを自社で所有できます。Blandがこの方式を選んだ理由は何ですか。また、音声AIスタック全体を自社で所有するうえで、技術的に最も難しかった課題は何でしたか？

自動音声認識（ASR）から大規模言語モデル（LLM）による推論、音声合成（TTS）まで、あらゆるレイヤーを自社でホストし、所有することにしたのは、3つの理由からです。1秒未満の会話レイテンシ、厳格なデータプライバシーの境界、そして高い運用信頼性です。

互いに異なる外部ベンダーのサービスを数珠つなぎにすると、遅延が積み重なります。往復のネットワーク通信、個別のキュー待ち時間、コールドスタートが次々に加わります。その結果、会話の流れを損なうような不自然な間が生じます。

モデルを統合ランタイム内に併置し、サードパーティAPIへの依存をなくすことで、そうした通信を排除できます。また、データに対する完全な主権を確保できるため、機密性の高い音声ストリームや文字起こしデータが外部の最先端モデル提供事業者に漏れることもありません。

技術的に最も難しかった課題は、レイテンシのオーケストレーション、ストリーミングの同期、高並行処理に対応するGPUスケジューリングでした。リアルタイムの双方向音声には、途切れのないトークン生成のストリーミングが必要です。TTSエンジンは、LLMが文章の生成を終える前に音声の合成を開始しなければなりません。

これを実現するために、独自の推論エンジン、低レイテンシの投機的デコードパイプライン、音響モデルの調整を開発しました。これらを組み合わせることで、ジッターを防ぎ、発話のターン交代を管理し、GPUメモリを飽和させることなく、ユーザーの割り込みにも適切に対応できます。

多くの音声AIプラットフォームは、文字起こし、推論、音声生成をそれぞれ異なるサードパーティプロバイダーのサービスで構成しています。Blandがスタックのより多くの部分を自社で所有・運用することで、どのような利点やエンジニアリング上のトレードオフが生じますか？

最大の利点は、エンドツーエンドのレイテンシを管理できることです。ASR、LLM、TTSの間にネットワークオーバーヘッドがまったくないため、統合されたストリーミングパイプラインを実行し、レイヤーをまたいだ最適化を行い、最初のバイトが返るまでの時間を厳密に管理できます。各要素を別々のベンダーから調達していては、これほどの制御は実現できません。

2つ目は、セキュリティとコンプライアンスの境界を統一できることです。データが管理下の環境から外に出ることはないため、顧客の音声データと文字起こしデータは、検証済みの保護領域内にとどまります。これにより、サードパーティの再委託先に伴うリスクがなくなり、HIPAA、SOC 2、PCI DSSへの準拠も大幅に容易になります。ベンダーのセキュリティ審査を経験したことがある人なら、これがどれほど重要か分かるはずです。

3つ目は、コストの予測可能性です。外部の基盤モデルAPIに対してトークン単位や分単位の上乗せ料金を支払う必要がないため、エンタープライズ規模でもユニットエコノミクスを予測しやすくなります。また、モデルを自社で所有しているので、音響特性、韻律、タスク固有の推論に関する重みを直接ファインチューニングできます。

ただし、これらはすべて無料で実現できるわけではありません。このアプローチでは、大規模なインフラとGPUへの多額の投資が必要です。専用GPUを大規模に運用するには、高度なスケジューリングやオーケストレーション、複数リージョンにまたがるフェイルオーバーが求められ、ハードウェアの負担も大きくなります。

モデルの保守や専門分野への特化も、当社が自ら担っています。最先端の研究を外部ベンダーに任せることはできません。その代わり、多様なアクセントや背景雑音の条件、言語に対応する自社モデルの学習、評価、保守を継続的に行うためのエンジニアリングにも取り組んでいます。

当社にとって、そのトレードオフを受け入れる価値はあります。

Blandは8月にFedRAMP 20x Class A認証を取得し、これを保有する初の音声AIプラットフォームだとしています。多くの読者には、20xと従来のFedRAMPの違いが分からないでしょう。Class Aとは何ですか。また、認証取得にあたって実際に何を証明する必要があったのでしょうか。

FedRAMP 20xは、FedRAMP統合規則2026年版（CR26）の下で導入された、現代的なクラウドネイティブの枠組みです。従来のプロセスでは、すべてをFIPS 199の影響度レベル（Low、Moderate、High）に分類していましたが、書類作業が非常に多いことで知られていました。20xでは、これらに代わって、A、B、C、Dのアルファベットで示す認証クラスが設けられています。

Class Aは、最初の段階にあたる区分です。成熟したセキュリティプログラムをすでに整備し、連邦政府市場への参入を目指す民間のクラウドサービスプロバイダー（CSP）を対象に設計されています。恒久的な到達点ではなく、参入への足がかりと考えてください。FedRAMPプログラム管理室（PMO）が直接発行する、公的に認められたプログラム認証を取得した後、Class B、C、またはDへ移行するまでに2年間の猶予があります。

認証取得に向けて、当社は4つの事項を証明する必要がありました。第一に、セキュリティ、機密性、可用性の基本原則を対象とする、最新の検証済みSOC 2 Type II監査を受けていること。第二に、音声、SMS、チャットの各サービスを含む連邦政府向けクラウドサービスの境界が明確に定義され、論理的に分離されていることです。

第三に、FedRAMP 20xの必須の主要セキュリティ指標（KSI）を基本レベルで実装し、継続的な監視に対応できる体制を整えていることです。これには、脆弱性スキャン、インシデント対応手順、アクセス制御の徹底、機械可読形式による継続的なセキュリティ報告が含まれます。

第四の要件では、自社で技術スタックを保有していたことが大きな強みになりました。文字起こし、推論、音声合成のすべてがBlandの認可済みコンテナ境界内で厳密に実行され、未審査のサードパーティー製最先端AIプロバイダーに連邦政府のデータが送信されないことを確認する必要がありました。外部ベンダーの製品を組み合わせて構築したプラットフォームでは、これは非常に満たしにくい要件です。

Blandは、プライベートクラウドVPCから専用のオンプレミスGPUインフラまで、幅広い導入形態に対応しています。特にレイテンシー、スケーリング、インフラ要件の面で、導入形態に応じてアーキテクチャはどのように変わるのでしょうか。

要点を言えば、オンプレミスに近づくほどレイテンシーが下がり、制御性が高まる一方、柔軟な拡張性は失われます。

まずはレイテンシーです。オンプレミス環境と専用VPC環境は、どちらも外部ネットワークを経由する通信を最小限に抑えられます。企業の内線電話網のトランクやSIPゲートウェイのすぐ近くに配置されるためです。たとえばAWSやGCP上のプライベートクラウドVPCでは、レイテンシーはリージョン内のネットワークやクラウド相互接続によって左右されます。専用のベアメタル型オンプレミスハードウェアなら、さらに一歩進んだ構成になります。ハイパーバイザーによる仮想化レイヤーとパブリックインターネット経由のルーティングを完全に排除できるため、音声のジッターを可能な限り低く抑えられます。

トレードオフが表れるのはスケーリングです。クラウドVPCでは、クラウドGPUインスタンスを利用するKubernetesクラスターの自動スケーリングなど、弾力的なオーケストレーションによって水平方向に拡張し、着信が急増した際には容量を動的に調整できます。オンプレミスでは、そうはいきません。物理GPUの容量上限が固定されるため、厳格な受付制御、キューイングポリシー、ピーク時の同時通話数に基づく固定的なハードウェアの調達が必要です。最も通話が多くなる日を想定し、事前に計画しておかなければなりません。

インフラ要件も大きく異なります。プライベートVPCの導入では、マネージドクラウドストレージ、ネイティブIAM、クラウド管理型のシークレット管理を利用できます。一方、オンプレミス環境では、ラック搭載型の専用GPUクラスター（たとえばNVIDIAのエンタープライズ向けアクセラレーター）、高スループットのローカルネットワークファブリック、ハードウェアセキュリティモジュール（HSM）またはローカルの鍵保管庫、ローカルのテレメトリー収集システムが必要です。さらに、これらすべてを、完全なエアギャップ環境や外部への通信が制限された環境でも稼働できるエンタープライズ向けコンテナランタイム上で動かさなければなりません。

Blandでは、企業がリリースを管理し、テスト環境を分け、実際の通話の一部で新バージョンをカナリアリリースしてから、より広く展開できます。AIエージェントが顧客対応の本番環境に導入されるにつれ、従来のソフトウェアリリース手法が特に重要になっているのはなぜでしょうか。

AIエージェントは、従来のエンタープライズソフトウェアのようには動作しないからです。

決定論的なソフトウェアは、毎回同じ動作をします。一方、生成AIエージェントの動作は確率的で、決定論的ではありません。プロンプトのわずかな調整、モデルの重みの更新、処理経路の変更によって、会話品質の劣化、ハルシネーション、コンプライアンスポリシー違反が意図せず引き起こされることがあります。多くの場合、変更内容を見ただけでは、そうした事態が起きると分かりません。

だからこそ、従来のリリース規律は重要性が薄れるどころか、以前にも増して重要になっています。隔離されたステージング環境で、過去の通話コーパスを使った厳格な回帰テストを行えば、本番公開前に多くの問題を検出できます。カナリアリリースでは、さらに一歩踏み込みます。新しいバージョンを稼働中の通話のうち管理された割合に段階的に展開し、感情の低下、目標達成率、レイテンシの急増、エスカレーションや引き継ぎのトリガーといった指標をリアルタイムで監視します。こうしたことはすべて、より広範な顧客層に新バージョンを展開する前に行われます。

これが譲れない条件となるのは、失敗した場合の影響が大きいためです。カスタマーサービス、保険金請求、アカウント管理では、障害が規制上の問題やブランドへの深刻な損害につながるおそれがあります。カナリアリリースを規律正しく段階管理し、問題があれば即座にロールバックすることで、アップデートの失敗が悪いニュースになるのを防げます。

銀行、医療機関、保険会社、政府機関は、ほかの業種に比べて、生成AIの導入に際してはるかに高いハードルに直面することがよくあります。こうした組織との対話を通じて、現在、音声AIの導入を妨げている最大の要因は何だと感じますか。セキュリティ、データ主権、信頼性、統合の複雑さ、調達、それともほかの要因でしょうか。

圧倒的に大きな課題はセキュリティとデータ主権で、次いで統合の複雑さとレガシーアーキテクチャが僅差で続きます。銀行、医療、保険、政府の各分野で話を聞くなかで、これは一貫して見られる傾向です。

セキュリティの面では、厳しい規制下にある組織は、機密性の高い音声ストリーム、保護対象保健情報（PHI）、非公開の個人情報が外部APIの境界を越えたり、サードパーティのモデル提供事業者に学習用として保持されたりするアーキテクチャを、到底受け入れられません。こうした組織にとって、監査可能性、データを一切保持しない保証、HIPAA、FedRAMP、PCI DSSなどに基づく厳格なコンプライアンス境界は、あれば望ましいというものではありません。最低限満たすべき前提条件です。それらに対応できなければ、たいていそこで話は終わります。

次のハードルは統合です。こうした大企業の多くは、今もレガシーなオンプレミス型PBXシステム、複雑なIVR、分断された基幹記録システムを運用しています。医療分野のEpicやCerner、銀行のメインフレーム基幹システムなどがその例です。こうした環境全体で、会話のフローをリアルタイムかつ低遅延の双方向読み書き可能なAPIアクセスとつなぐには、統合に相当な負担がかかります。

さらに、信頼性とハルシネーションのリスクもあります。法務、リスク管理、調達の各チームが、自律型音声エージェントによる不正確な金融、医療、規制関連の助言を懸念するのは当然です。本番環境への大規模導入を承認する前に、こうしたチームは、きめ細かなガードレール、決定論的な会話の代替対応、明確な人間へのエスカレーション経路を求めます。

素晴らしいインタビューをありがとうございました。さらに詳しく知りたい方は、Blandをご覧ください。