Amazon Connect、Twilio、NICE CXone、Avaya：4つのメディア経路と、立てる場所は2つ

以下の仕様に関する主張はすべて、ベンダー自身が公開しているドキュメントから引用し、リンクしています。確認できなかったものは、埋めて済ませるのではなく未確認と記し、末尾近くに一覧をまとめています。この記事はまた、私たちが以前Twilioについて強く言いすぎたことをひとつ、正確な形に研ぎ直しています。その訂正には専用のセクションがあります。これらのいずれかが誤っている、あるいは変わった場合には、教えてください。日付を付して訂正します。

姉妹記事はGenesys CloudのAudioHookを同じやり方で読み、サンプルレートを型システムに固定したプロトコルと、挿入点のないメディア経路を見つけました。本記事は、私たちの買い手が実際に運用している残り4つの面を扱います。そして答えは、私たちが予想していたより一様ではありませんでした。

各プラットフォームに問うのは、ひとつの質問です。

第三者が通話音声を受け取り、処理し、その処理済み音声を、プラットフォーム自身のボット、認識器、録音、あるいは通話の相手が消費するものにできるか？

プラットフォーム	面	あなたへの音声出力	処理済み音声の返送	文書化されたレート
Amazon Connect	Kinesis Video Streams	あり	なし	8 kHz
Twilio	<Connect><Stream>	あり	あり	8000 Hz µ-law
Twilio	<Connect><ConversationRelay>	なし——JSONのみ	なし	未公表
NICE CXone	Custom Agent Assist	あり	なし	8 kHz µ-law
NICE CXone	Custom Virtual Agent	あり	ターン単位の再生のみ	G.711、レートは記載なし
Avaya Infinity	Real-time Contextual Media Streaming	あり	あり	8 kHz、またはG.722で16 kHz

このうち2つは正真正銘のマン・イン・ザ・ミドルの位置です。残りは、同じ語彙をまとったタップ、フォーク、あるいはボットのターンです。

Amazon Connect：一方向のフォーク、そして皆が間違える2つのこと

これはAPIで開始されるものではありません。 StartContactStreamingは明白な候補であり、そして間違った候補です——そのリファレンス自身が「新しいチャットコンタクトのリアルタイムメッセージストリーミングを開始する」と述べており、唯一の設定オブジェクトはSNSエンドポイントを指すチャットストリーミング設定です。これはチャットのAPIです。

音声メディアストリーミングは、インスタンスで有効化したうえで、フローの中でオンにします。

「ライブメディアストリーミングを有効化した後、Start media streamingブロックとStop media streamingブロックをフローに追加する。」——ライブメディアストリームの有効化

このブロックは2つの選択肢——顧客からのストリーム、または顧客へのストリーム——を提供し、音声のみに適用されます。他のすべてのチャネルはエラーブランチに落ちます。私たちが見つけられた限り、音声メディアストリーミングを開始する公開APIは存在せず、あるのはフローのブロックだけです。

フォーマットは8 kHzで、それ以外はほとんど何も公表されていません。 引用すべき文はこれです。

「メディアストリーミングはKinesis Video Streamsのマルチトラックサポートを使用し、顧客が話す内容は、顧客が聞く内容とは別のトラックに載る。Kinesisに送られる音声は8 kHzのサンプリングレートを使用する。」——ライブメディアストリームの計画

トラックはAUDIO_FROM_CUSTOMERとAUDIO_TO_CUSTOMERで、コンシューマーガイドは、リーダーが「このデータを生のPCMファイルとして保存する」と述べています。

これが、文書化されたフォーマットのすべてです。私たちはライブメディアストリーミングの4ページをL16、endian、bit、codecでgrepし、何も得ませんでした。よく繰り返される「audio/L16、16ビット、リトルエンディアン、モノラル」は、Amazon Connectのドキュメントには存在しません。 AWS自身の資料の中でビット深度を示す唯一のシグナルは、デモリポジトリにあるAudacityのインポート手順——エンコーディングをsigned 16-bit PCMに、サンプルレートを8000 Hzに設定せよ——であり、それはバイト列が結果として何であったかを教えるものであって、契約が何であるかを教えるものではありません。16ビットモノラルは強く示唆されています。しかし文書化されてはおらず、私たちはそれを、文書化されているかのように書き記すつもりはありません。

また、エンコーディングにおいてConnectが異色であることにも注意してください。TwilioとNICEはどちらもコンパンディングされたG.711 µ-lawを渡してきます。Connectは同じ8 kHzの線形PCMを渡します。帯域制限は同じで、量子化ノイズが異なります。モデルを一方に対してベンチマークしているなら、それは他方に対するベンチマークにはなっていません。

これは一方向であり、AWSは遠回しに、しかし見誤りようなくそう言っています。 文書化された動詞はすべてキャプチャか消費で、書き込み経路は存在せず、計画ページにはこうあります。

「ストリームを変更することは控えるよう推奨する。変更は予期しない動作を引き起こし得る。」

これはフラグメントを読み出すライブストリームであり、デフォルトの保持期間は短い。 「データ保持なしを選択した場合、データは保持されず、消費できるのは5分間だけである」。Connectはコンタクト属性を通じて、コンシューマーにフラグメントカーソル——StartFragmentNumber、StreamARN、StartTimestamp、StopTimestamp——を渡すので、あなたのリーダーはソケットを購読するのではなく、ストリームの中へシークします。これは計画に織り込む価値のあるアーキテクチャ上の違いです。プッシュではなくプルであり、あなたのレイテンシ予算には、コンシューマーのポーリングループのコストが含まれます。

Connectの他の面はどうでしょうか？ 名前が混乱を招くので、確認しました。

• Contact Lensリアルタイムはトランスクリプトであって、音声ではありません。Kinesis Data Streams越しにUtteranceセグメントを配送します——「ライブ通話でエージェントを支援するための超低レイテンシ要件を満たす……部分トランスクリプト」。あなたが制御しない認識器の下流にある、テキストです。
• 外部音声システムはSIPREC経由でContact Lensに取り込むものです——設定ページは「SIPREC音声を受信する」ホストを名指しします。これは第三者のテレフォニープラットフォームからConnectへ入っていく音声であり、処理のために外へ出る音声ではありません。コーデック仕様はAmazon Chime SDKのガイドへ委ねられており、私たちはそれを読んでいないため、そこのフォーマットは未確認です。
• StartWebRTCContactは、Chime SDKのミーティングと参加者のクレデンシャル——AudioHostUrl、SignalingUrl、JoinToken——を返します。これはクライアントSDKが参加者として通話に加わる方法です。サーバー側の生音声パイプではありません。
• サードパーティ音声プロバイダーは、Connectが他者のモデルを経路内に文書化している唯一の場所です。「Connectは選択されたサードパーティの音声認識プロバイダーへ音声をルーティングする」。ボットのロケールごとに、プロバイダーのAPIキーをSecrets Managerに置いて設定します。サードパーティTTSの姉妹ページも存在します。これはサポート済みリストからのベンダー選択であって、あなた自身の処理の挿入点ではありません。

いまConnectについて書いている人へ、フラグをひとつ。ドキュメントの目次には現在、Amazon Connect Voice IDのサポート終了ページが載っています。その上に何かを建てる前に、ステータスを確認してください。

評決：ノー。 Kinesis Video Streamsは脇へのフォークです。すべてを聴けて、何も変えられません。

Twilio：5つの中で最も強い、汎用の挿入点

Twilioはここにある誰よりも厳密なフォーマット契約を公表しており、私たちは要約を信用するのではなく、文字列そのものを読んで検証しました。WebSocketメッセージリファレンスから：

「start.mediaFormat.encoding——これから届くペイロードのデータのエンコーディング。値は常にaudio/x-mulaw。start.mediaFormat.sampleRate——値は常に8000。start.mediaFormat.channels——値は常に1。」

「常に」が3つです。音声はJSON内のbase64として届き、1から始まるchunkカウンタと、ストリーム開始からのミリ秒を示すtimestampを伴います。メカニズムはフォークです。「Twilioは通話の生音声ストリームをフォークし、ほぼリアルタイムであなたのWebSocketサーバーへストリームする」。トランスポートはwssのみ。

トラック選択——inbound_track、outbound_track、both_tracks、デフォルトはinbound_track——は単方向の形式に属します。inboundはTwilioが相手方から受け取るもの、outboundはTwilioが通話に向けて生成するものです。

この2つの形式は、ひとつの名詞を共有する別の製品です。 これが、あなたのアーキテクチャを決める区別です。

	<Start><Stream>	<Connect><Stream>
方向	フォーク出力のみ	双方向
TwiMLフロー	「直ちに次のTwiML命令へ進む」	ブロックする：後続のTwiMLは「あなたのサーバーがWebSocket接続を閉じた後」にのみ実行される
REST経由での作成	可	不可
トラック選択	可	名詞リファレンスでは単方向にスコープされる

双方向の形式では、あなたが送り返す音声は通話上で再生されます。

「双方向Media Streamsとは、あなたのWebSocketアプリケーションがTwilioから音声を受け取ると同時に、Twilioへ音声を送ることができ、それが通話上で再生されるものである。」——Media Streams

厳格なペイロード規則と、その中の罠つきです。「ペイロードはaudio/x-mulawでエンコードされ、サンプルレートは8000、かつbase64エンコードされていなければならない」、そして「media.payloadには音声ファイル形式のヘッダーバイトを含めてはならない。ヘッダーバイトを与えるとメディアは正しくストリームされない」。WAVヘッダーを書き込むライブラリでµ-lawを生成すれば、それはあなたの耳に聞こえることになります。

さらに、再生完了を追跡するmarkと、バッファ済み音声をフラッシュするclearも手に入ります——これはバージイン（barge-in）のプリミティブであり、この面が、通話者にただ話をかぶせるのではなく、本物の割り込みモデルを支えられる理由です。

評決：イエス。 <Connect><Stream>は正真正銘のマン・イン・ザ・ミドルです。通話者の音声が入り、あなたの音声が出て、通話上で再生され、再生と割り込みの制御があります。コストは、<Connect>が終端であること——その継続中、通話を所有すること——です。あなたはフローを飾るのではなく、フローそのものになるのです。

Twilioが公表していないものがひとつ：フレームサイズです。 誰もが160バイトと20 msを引用するので、私たちは特に探しました。Twilioが文書化しているのはchunkカウンタとtimestampであり、どちらのMedia Streamsページにも、メッセージあたりのバイト数やフレームあたりのミリ秒の数字はありません。その数字が必要なら、自分のトラフィックで測定し、観測値としてラベルしてください。

Twilioは、リアルタイム文字起こしのサンプルレートも公表していません。<Transcription>名詞はトラック選択とラベルを文書化し、エンジンとしてGoogleまたはDeepgramを名指ししますが、名詞リファレンスにもRESTリソースにも、レートは見つかりませんでした。

私たちが繰り返してきたTwilioの主張を、正しい形で

私たちはこのサイトで、Twilioの<ConversationRelay>は構造的に<Stream>のメディアフォークを並走させられない、と書いてきました。そう述べている文を探しに行ったところ、そんな文は存在しませんでした。 私たちにとっては結論よりも訂正のほうが重要なので、ドキュメントが含むものと含まないものを、正確にここに記します。

ConversationRelayが何であるかは、確認済みです。 それは「通話をConversation Relayサービスへルーティングし、高度なAIによる音声対話を提供する」ものです。音声認識と音声合成はTwilio自身が行い、あなたのWebSocketがやり取りするのはJSONのみです。入ってくるのはsetup、prompt（すでに文字起こしされたテキストであるvoicePromptを運ぶ）、dtmf、interrupt、error。出ていくのはテキストトークン、URLによるメディア再生、ディジット送出、言語切替、セッション終了。生の音声はどちらの向きにもこのソケットを横断せず、そのコーデックもサンプルレートも、私たちが見つけられた範囲ではどこにも公表されていません。

ドキュメントが述べていないこと。私たちは注意深く確認しました。

• <Connect>には基数の規則がありません。名詞リファレンスは4つの名詞と2つの属性を文書化しており、<Connect>が正確にひとつだけを含み得るとは、どこにも述べていません。
• <Stream>が<ConversationRelay>と非互換だという記述はありません。私たちはConversationRelayの概要、名詞リファレンス、オンボーディングページ、<Connect>リファレンスを「cannot」「not supported」「limitation」「incompatible」「only one」「simultaneously」「alongside」でgrepしました。ヒットはすべてナビゲーションの装飾でした。本文はゼロ。ConversationRelayのどのページにも、制限事項のセクションはありません。
• <Connect><ConversationRelay>の前に開始された<Start><Stream>のフォークが生き残るかどうかは、動くとも失敗するとも文書化されていません。 Twilioは、この組み合わせに一切触れていないのです。

つまり正確な記述は推論であり、私たちはそれを推論としてラベルすべきでした。 ConversationRelayのプロトコルは音声を運ばず、<Connect>は終端として文書化されています。この2つを合わせると、Twilioはメディアを自ら終端して再生成しているはずであり——通話者と認識器の間に第三者のプロセッサを置ける、文書化された場所は残りません。この推論は健全であり、そして引用ではありません。先行する<Start><Stream>の実証実験を私たちは実行しておらず、実行するまでの間、この主張の正直な形はこうです。Twilioはこの組み合わせを文書化していない。アーキテクチャは、プロセッサを挿入する場所がないことを示唆する。私たちはそれを検証していない。

この実験をどちらの向きにでも実行した方がいれば、その結果を心から歓迎します。出典を明記して公開します。

NICE CXone：ドキュメントは、探しそうな場所にはない

公開の開発者ポータルは18のAPIファミリーを列挙しており、そのどれもライブ音声ではありません。「Real-Time Data」はメトリクスです。「Media Playback」は録音です。そこで探すと、CXoneにはリアルタイム音声の面が存在しないと結論することになり、その結論は間違いです——仕様は管理者向けヘルプセンターの、エージェントアシスト統合の下に住んでいます。

詳細の前に、持っておく価値のある否定的な発見をひとつ。CXone Real-Time Audio、RTMS、CXone Voice Streaming API、CXone Open Agent Assistという名前の製品は見つかりませんでした。これらの名前は第三者の記事に現れます。NICE自身のドキュメントを6,000件のURLにわたって走査しても、現れませんでした。これらの名前の上に検索を組み立てないでください。

Custom Agent Assist Integrationsがリアルタイム音声の面であり、そのフォーマットの文に曖昧さはありません。

「音声パケットはG711 μlaw 8ビット8000 kHzの生音声としてエンコードされる。これは、すべてのNiCE CXoneテレフォニー音声と同じフォーマットである。」——エージェントアシストのリソース

単位はNICE自身のタイポで、8000 Hzの意であることは明白です。この文は後半のほうが有用な半分です。これは、すべてのCXoneテレフォニー音声と同じフォーマットなのです。 プラットフォームは、その内部のメディア表現がどこでも狭帯域のG.711だと告げています。

チャネルモデルはトラック単位ではなく接続単位で、これは珍しく、間違えやすいところです。

「streamPerspective: RX——エージェントの電話機が送信している音声：エージェントの発話。TX——エージェントが聞く音声：コンタクトの発話……MIX——エージェントとコンタクトの両方の音声ストリームを含む。個々のwebsocket接続は、ひとつのパースペクティブの音声のみを含む。」

つまり通話のステレオビューはソケット2本であり、相関を取るのはあなたで、ペイロードに共有クロックはありません——ペイロードには音声以外の何も入っていないからです。

「webhookを流れるのはバイナリデータのみである。音声インタラクションでは、通話から送られる唯一のデータは音声バイトである。通話制御やその他のメタデータは含まれない。」

運用面では：少なくとも2,000の同時リクエストをサポート、接続の期限や最大継続時間はなし、保留はソケットを閉じ、再開は同一のハンドシェイクで新しいソケットを開きます。NICEが非セキュアなエンドポイントを許していることにも注意してください——「音声リレーのエンドポイントはwebsocketでなければならない。セキュア（WSS）でも非セキュア（WS）でもよい」——これは、サンプルをコピーして決めるのではなく、意図して下すべき選択です。

方向：出力のみ。 あなたが返すのは、エージェントの画面にレンダリングされるテキストとリソースです。音声が通話に再び入ることはありません。これらの統合を仲介するAgent Assist Hubは、したがって生のG.711 µ-law音声を第三者へストリームし、第三者が自前の音声認識を行うことを期待します。

Custom Virtual Agentは、CXoneが音声を返すことに最も近づく場所であり、ストリーミングではなくターン単位です。発話は「G-711コーデックのフォーマットの音声として、または文字起こし済みテキストとして」届き、応答スキーマには——NICE自身のスペルミスをそのままに——base64EndcodedG711ulawWithWavHeaderという名前のフィールドがあり、「次のターンで再生される」エンコード済みWAVと説明されています。トランスポートはHTTPS上のRESTです。これはボットの返答であって、インラインのフィルタではありません。

評決：エージェントアシストはノー、バーチャルエージェントはターン単位の再生のみ。 すべてを、8 kHzのµ-lawで、パースペクティブごとに別々のソケットで聴くことができます。そして、他の誰かが聞くものを変えることはできません。

Avaya：驚き、そしてこの調査で唯一の広帯域コーデック

私たちは、Avayaのリアルタイム音声の面は公開文書化されていない、と書くことになると予想していました。されています——詳細に、ログインなしで。しかも、5つの中で最も明示的に双方向の設計です。

Avaya InfinityはReal-time Contextual Media Streamingを公開しており、最終更新は2026年7月23日です。

「Real-time Contextual Media Streamingは、あなた自身のAIサービスをAvaya Infinityへ直接接続できるオープンなWebSocketベースのプロトコルである……プロプライエタリなSDKなし。ミドルウェアなし。 双方向音声と構造化JSONメッセージを運ぶWebSocket接続、それだけである。」

メディア契約を逐語で示します。

「コーデック：PCMU（8 kHz）、PCMA（8 kHz）、G.722（16 kHz） ／ フレームサイズ：デフォルト20ms、セッションごとに設定可能 ／ チャネル：顧客音声、エージェント音声、または両方——セッションセットアップ時にネゴシエート」

これは、この調査全体で唯一の広帯域コーデックです。ここにある他のすべてのプラットフォームも、Genesysも、狭帯域を、そして狭帯域だけを文書化しています。AvayaがG.722の16 kHzを文書化しているからといって、あなたの通話が広帯域になるわけではありません——帯域を決めるのは依然としてキャリアレッグです——しかし、帯域制限を強制しているのがプラットフォームではない、ということであり、それは他の4つとは異なる状況です。

方向のモデルは明示的で、サービスごとです。

「Egress（出力）（Avaya Infinity → あなたのサーバー）——エンドポイントからのライブ音声。処理のためにあなたのサーバーへストリームされる……Ingress（入力）（あなたのサーバー → Avaya Infinity）——あなたのサーバーが生成した音声。エンドポイントへ再生される。」／「Virtual Agentボットは通常、両方のフローを使う……録音サービスはegressのみ。TTSサービスはingressのみ。どのフローをアクティブにするかは、エンドポイントごとにあなたのサーバーが制御する。」

トランスポートモードは2つ文書化されています——avaya-wss（TLS WebSocket上のバイナリフレーム）と、「超低レイテンシ環境向け」のavaya-wss-rtp（UDP上のSRTP）——どちらも制御にJSONを使い、どちらも動的なコーデックネゴシエーションをサポートします。AvayaがWebSocketのクライアントで、あなたがサーバーなので、「あなたの側にインバウンドのファイアウォールルールは不要」。認証は、あなたのサーバーが検証する署名済みJWT。TLS 1.2以上とパブリックCAの証明書。1本のソケットが複数のエンドポイントを多重化し、フレームはエンドポイントIDでタグ付けされます。

これを正直に保つただし書き：ライブなのはVirtual Agentだけです。 同じページには「Coming Soon」の表があり、Agent Assist、Recording、Text-to-Speech、Speech Recognition、Transcription、Translationが、同じプロトコル上の将来のサービスとして列挙されています。つまり今日、双方向の経路は存在し、それを使う方法はバーチャルエージェントになることです。このセクションを「Avayaは今日、サードパーティのASRや録音の挿入を許している」と読まないでください。ベンダーはそう言っていないのです。

スコープに関する注記をさらに2つ。Avaya Experience Platformには相当物がありません——そのメディア処理はファイルの署名付きアップロードとダウンロードであって、ライブ音声ではありません。リアルタイムストリーミングは、より新しいプラットフォームであるAvaya Infinityにあります。そして、Avaya Aura、AES、Avaya Aura Media Serverはまったく調査していません。 これはこの記事の中の未解決の問いであって、否定的な発見ではありません。沈黙が不在として読まれるくらいなら、そう明言したいのです。

これらが足し合わさって意味すること

独立した結論が2つあり、それぞれ別の方向を指しています。

サンプルレートについて、くさびは保たれ、ただし私たちが言ってきたよりわずかに狭い。 5つの面のうち4つは8 kHzを、そして8 kHzだけを文書化しており、NICEは狭帯域（narrowband）のG.711が「すべてのNiCE CXoneテレフォニー音声と同じフォーマット」だと言い切っています。それがお金の届くチャネルであり、市場にある音声強調モデルは本質的にすべて広帯域で訓練されています——公表されている大半のノイズ除去モデルがそれに合わせてチューニングされているベンチマークシリーズ、DNS Challengeには、狭帯域トラックが一度も存在しませんでした。しかし私たちは「どこでも8 kHzのµ-lawだ」と書くのをやめるべきです。Amazon Connectはコンパンディングではなく線形PCMであり、AvayaはG.722の16 kHzを文書化しています。6つの面のうち2つの例外は、丸め誤差ではありません。

統合面について、フィールドはきれいに割れます。そしてそれは、マーケティングが示唆する割れ方ではありません。 これらのプラットフォームはどれも聴くことは許してくれます。そのうち2つ——Twilioの<Connect><Stream>とAvaya InfinityのRCMS——は、ライブのメディア経路へ音声を戻す方法を文書化しています。Genesys、Amazon Connect、NICE CXoneはしていません。そして、音声を返せる面においてさえ、あなたが求められているのはボットになることであって、フィルタになることではありません。あなたが送る音声は人間へ行くのであって、他の誰かの認識器へ行くのではないのです。

ビルドの意思決定へ持ち込むべき区別は、これです。「プラットフォームの音声認識器が聞く前に、通話者の音声を処理できるか？」は、「この通話に音声を送り込めるか？」とは別の問いであり、この調査のどこかにイエスが存在するのは片方だけです——それも、あなたが認識器も所有しているプラットフォームの上で、です。

ここで、プラットフォームではなく測定が制約になります。私たちの7つのテレフォニー条件では、テストしたどの強調器も、未処理音声に対する意味のある改善を生まず、いくつかは単語誤り率（WER）を5〜10ポイント劣化させました。挿入点は簡単な部分です。挿入する価値のある何かを持つこと——それこそ、数字を私たちが検証できる者の誰も解いていない部分であり、まさに私たちが埋めようとしているギャップです。

確認できなかったこと

• Amazon Connect：ビット深度、エンディアンネス、チャネル数。 8 kHzと「生のPCM」が、公表されたフォーマットのすべてです。16ビットモノラルはAWS自身のデモ資料から示唆されますが、文書化されていません。
• Amazon Connect：レイテンシの数字。 読んだどのページにも公表されていません。
• Amazon Connect：SIPREC取り込みのコーデックプロファイル。 AWSによってAmazon Chime SDKの設定ガイドへ委ねられており、私たちはそれを読んでいません。
• Twilio：メディアメッセージあたりのバイト数またはミリ秒。 公表されていません。広く引用される160バイト／20 msは、Twilioのドキュメントにはありません。
• Twilio：ConversationRelayの音声フォーマットとサンプルレート。 私たちが見つけられた範囲では、どこにも公表されていません。TTSプロバイダーとプロソディ設定を扱い、コーデックを一切扱わない音声設定ページも含めて、です。
• Twilio：<Start><Stream>のフォークが、後続の<Connect><ConversationRelay>まで生き残るかどうか。 どちらの向きにも文書化されておらず、私たちもテストしていません。
• Twilio：リアルタイム文字起こしのサンプルレート。 公表されていません。
• NICE CXone：Custom Virtual Agentの音声サンプルレート。 コーデックはG.711 µ-lawと記載されていますが、レートはスキーマのページに記載がありません。
• NICE CXone：Agent Assist Hubの背後にあるプロバイダーごとのフォーマット。 統合のページはそれらを再掲しておらず、唯一のフォーマット仕様はカスタム統合のページにあります。
• Avaya：ワイヤレベルのプロトコル仕様。 Avayaはプロトコル仕様のPDF（バージョン1.1）を公開していますが、私たちは取得していません——したがって、セッションのライフサイクルとメッセージ定義は、ここでは未検証です。
• Avaya Aura、AES、Avaya Aura Media Server。 調査していません。未解決の問いであって、否定的な発見ではありません。

手法についての注記をひとつ。これらの発見にどれだけの重みを載せられるかが変わるからです。この調査は、検索によってではなく、ベンダーが所有するドキュメントの索引を歩き、ページを直接読むことで行いました。これは、文書が何を言っているかの確認にはより信頼でき、文書が存在しないことの証明にはあまり信頼できません。上のすべての「文書化されていない」は「ベンダー自身の索引をクロールしても見つからなかった」を意味し、それは「ベンダーは文書化していない」より弱い主張です——そして、逐語である確認済みの引用より、さらに弱いものです。