AXのMissing Piece：Conversational Intelligence
「2026年現在、AIパイロットの95%は、測定可能な収益効果を生み出していない。」
— MIT NANDA, State of AI in Business 2025
月曜の朝、ダッシュボードに1件のアラートが表示されます。
「A社のPoC利用量が、過去7日間で30%減少しました。」
CSエージェントが自動で対応案を生成します。
「割引提案を送ってください。」
担当者は思わず笑います。2週間前、A社とのPoCミーティングでA社CTOが残したフィードバックを覚えていたからです。
「弊社チームでエージェント連携を進めるにはAPIが安定して動作することが前提ですが、現在API連携で課題があり、十分にサービスを活用できていません。セキュリティ部門の承認もまだ完了していません。」
問題は価格ではありませんでした。連携のボトルネックだったのです。
この状況で割引を送ることは、むしろ「この会社は私たちの状況を理解していない」というシグナルになります。
担当者は結局、エージェントの提案を無視し、自らメールを書きます。技術支援ミーティングを設定し、PoC期間を延長し、連携ガイドを添付します。
エージェントの判断は間違っていました。しかし、それをエージェントの責任とするのは難しい話です。担当者とA社CTOの間で行われた、最も重要な会話記録にアクセスできなかったからです。
同じ場面を、もう一度見てみましょう。
エージェントがアラートを受け取ります。今回は違います。A社との直近3件のミーティング記録を先に検索します。
「API連携に課題があり、十分にサービスを活用できていない」というCTOの発言を見つけ出します。さらに、セキュリティ部門の承認が未完了である点も把握します。返信間隔が徐々に伸びているパターンまで検知したうえで、エージェントはこう判断します。
「主要ボトルネックは、API連携の複雑さとセキュリティ承認の遅延。技術支援ミーティングの設定、PoC期間延長、連携ガイド送付を推奨します。」
担当者はその判断をもとに、エージェントが作成したメール草案を確認し、「送信」を押します。
この2つの場面の違いは、モデルではありません。
モデルは変わっていません。むしろ時間が経つほど、より安く、より高性能になっていきます。
唯一の違いは、エージェントがその会議を知っていたかどうかです。
なぜエージェントは知らなかったのか
前回、私はAXが5つのレイヤーで構成されるとお話ししました。
そして多くの企業は後方レイヤー、つまり AI Model / Agentic Workflow / User Interface に投資する一方、前方レイヤーである Context Source と Ontology を空白のままにしている、と指摘しました。
この場面は、その空白が実際にどのようなコストとなって返ってくるかを示しています。
多くの企業はAXを始める際、まず業務ツール同士をコネクタでつなぎます。ドキュメントツール、課題管理ツール、CRM、メッセンジャーを連携すれば、AIが会社を理解すると考えます。
しかし現実は違います。
ドキュメントツールに記録されるのは「何が決まったか」です。その決定に至るまでの議論の大半は残りません。課題管理ツールが示すのは「どんなタスクがあるか」です。なぜそのタスクが他より優先されたのかは分かりません。CRMが示すのは顧客のステージです。なぜその顧客が迷っているのかは説明しません。
現在のコネクタが集めているのは、意思決定の結果です。意思決定に至る過程は取得できていません。そして、その過程に関する情報の90%以上は、重要な会話や会議の中で失われています。
「うちもAI議事録を使っていますが」
すでに導入されている企業も多いでしょう。
しかし、そのAI議事録は先ほどの場面で、本当にエージェントを助けられるでしょうか。
多くのAI議事録は、人間が読むための要約を作ります。
エージェントが検索・推論に使える形にはなっていません。
文字起こしは記録ではあっても、文脈ではありません。
音声がテキスト化された後も、エージェントが活用するにはさらに複数段階の変換が必要です。
話者分離
トピックごとのセグメンテーション
意思決定事項とアクションアイテム抽出
参加者・会議ID・日時などのメタデータ付与
検索可能なベクトル形式で保存
このパイプラインを経て、初めてそれは LLM-Ready Data になります。
AI議事録が一人の時間を節約する生産性ツールだとすれば、Conversational Intelligenceは、組織全体のAIシステムに燃料を供給するインフラです。前者は個人の利便性、後者は組織の資産です。同じ音声ファイルから始まっても、どこまで変換するかで全く別のカテゴリーになります。
95%が失敗する本当の理由
MIT NANDA研究チームが300件以上の企業AIプロジェクトを分析した際、失敗した案件には共通点がありました。AIが組織のワークフローから学習できず、その流れに適応できていなかったことです。
この診断は、業界用語の変化とも一致します。ChatGPT登場初期に注目された prompt engineering は、今や context engineering へと置き換わりました。本当に価値を生むために最適化すべき対象が変わったのです。
OpenAI共同創業者のAndrej Karpathy氏はこう述べています。「本質的な技術とは、コンテキストウィンドウを、次のステップに必要な“ちょうど良い情報”で満たすことだ。」
LLMの性能を分けるのは、モデルそのものではなく、そのモデルに何を見せるかです。そして「何を見せるか」は、純粋な技術課題である前に、組織設計とワークフローの課題でもあります。
AXの95%が失敗するという研究結果と、冒頭のシーンの距離は、思っている以上に近いのです。
なぜ日本語会議ではさらに難しいのか
ここまで読んで、「それなら汎用ツールで会議録を取ればよいのでは？」と思われるかもしれません。
しかし現実は少し異なります。現在広く使われている音声認識モデルでは、英語の誤認識率は約4%、同モデルのアジア語は約14%水準とされています。
ビジネス会議において、この差は致命的です。100語中14語が誤っていれば、その中に担当者名や決定金額が含まれているかもしれません。
その瞬間、議事録は「真実の源泉」ではなく「誤情報の源泉」になります。
さらに規制もあります。日本の個人情報保護法では音声データがセンシティブ情報と見なされる余地があり、公共機関向けCSAP認証は海外SaaSベンダーにとって高い参入障壁です。エンタープライズAXでは、技術性能とデータ主権を切り離して考えることはできません。
Tiroはこの課題を解くために設計されました。Tiroは、日本語を含む15言語に対応しています。
AES-256による保存時暗号化
TLS 1.3による通信暗号化
AWS KMS管理キー
文字起こし後の原音声削除
第三者AIベンダーによる学習利用を契約上制限
設計の出発点は、ただ一つの問いでした。「会話が組織のSource of Truthになるには、何が必要か。」その答えとして、Tiroが置いた基準は3つです。
どの言語で話しても十分に高精度な文字起こしであること
セキュリティが堅牢であること
出力がエージェントがそのまま読める構造化データであること
AI議事録カテゴリーにおいて「精度」は、通常「どれだけ上手く要約できるか」で語られます。しかしConversation Intelligenceでは問いが違います。
この記録は、組織の真実として受け入れられる誤差率か
この記録は、どれだけ構造化され、再利用可能か
この視点の違いが、製品設計そのものを変えます。
FAQ
Conversation IntelligenceとAI議事録の違いは？
AI議事録は、個人の時間を節約する生産性ツールです。Conversation Intelligenceは、会話データをエージェント・CRM・RAGなど他のAIシステムが利用できる構造化資産へ変換するインフラです。
単純な文字起こしではなぜ不十分ですか？
文字起こしは音声をテキスト化するだけです。実際にAIが使うには、話者分離・トピック分類・意思決定抽出・メタデータ付与・埋め込み生成が必要です。文脈を欠いたテキスト断片は、検索されても活用されません。
海外の汎用ツールで韓国語会議を処理すると何が問題ですか？
精度と規制の両面です。韓国語の誤認識率は英語比で約3倍高く、固有名詞や数字が多い商談では特に致命的です。加えて、個人情報保護法、CSAP、金融機関のネットワーク分離要件などにより、海外SaaSの実運用導入は容易ではありません。
はじめる
はじめる
