音声エージェントが動かない理由

重大度ではなく、頻度順です。以下の確認は、どれも見るべき画面を名指しします。 「動かない」は、ほぼいつも四つの画面が互いに矛盾しているだけのことだからです。

1. 番号は応答するが、あなたのエージェントではない

最も多い報告で、最も見つけにくいもの。電話が つながる からです。接続済みの 番号は、紐付けが何もない段階でも応答します — テスト用エージェントが受けて、 まずまずに聞こえます。

確認: 番号に発信して、エージェントが最初に話す内容 が聞こえるか待って ください。それ以外が聞こえたら、番号はあなたのエージェントに紐付いていません。

修正: /phone-numbers で、番号がエージェント名入りで 「… がこのチャネルに応答します」 となっているか確認します。/agents では、 デプロイ セクションが Not deployed や 音声チャネルなし ではなく 「… にデプロイしました」 となっているか。間違っている方を直してください。

2. マイクテストは通るのに、電話がダメ

この二つは別物を試しており、前者に合格しても後者については何も証明しません。 /agents 自身が言っています: “WebRTCはブラウザでのテストに使用できます。 電話経由の場合は番号が必要です。”

マイクテストを開始 はエージェントを動かします。番号、紐付け、キャリアは動かし ません。マイクテストが良くて通話がだめなら、問題は電話の経路にあります。 確認 1 に戻ってください。

3. エージェントは応答するが、何も知らない

不具合ではありません。ナレッジのないエージェントは、正しく、役に立たずに 応答します。

確認: /agents/knowledge。空なら、それが答えです — “まずエージェントを作成し、その後で根拠となるナレッジを追加してください。”

営業時間、料金、サービス内容、場所を入れて、マイクテストをやり直してください。 このリストで最も回収率の高い修正で、しかもバグの報告ではありません。

4. 通話はつながるのに、その後失敗する

/conversations を開き、通話を見つけてください。結果から、どちらの半分が 壊れたかがわかります:

通話のタイムライン には 接続中、呼び出し中、通話中、終了処理中 の各段階が出るので、どこまで進んで止まったかがわかります。

キャリア変更の直後に 失敗 が続くなら、大抵はキャリアが拒否しています: “通信事業者が通話を受け付けませんでした。少し待ってから再試行してください。” 番号の ダイヤル形式 を確認してください — 国内形式を期待するキャリアは E.164 を 拒み、しかも設定は問題なく保存されています。

5. 動くのに、何も記録されない

通話は起きているのに、後に見るべき構造化されたものが残らない。

確認: /dialog-insights。未紐付け と出ているインサイトは動きません — “対話インサイトは、紐付けたエージェントまたはキャンペーンの会話でのみ実行され ます。” 保存と紐付けは別の操作です。

フィールド自体も確認してください: “フィールドのない対話インサイトは結果を 生成しません。“

6. 音声が勝手に変わった

勝手には変わっていません。パイプラインの変更がそうします。リアルタイム系は 独自の音声を持ち、標準は音声合成プロバイダーの音声を使うため、パイプライン を 切り替えると、前の音声を含まないリストから選ぶことになります。 音声パイプライン を参照。

7. 何かを一時停止したら動かなくなった

エージェントを一時停止・アーカイブすると、応答も 止まり、発信も 止まります。 そのエージェントを使うキャンペーンが走っていると、残りの通話はすべて スキップしてラベルを付けながら消化されます。あなたが止めたつもりのエージェントの 名で、ダイヤルし続けるよりはいい、という設計です。

どれでもなければ

一度も発信したことのない電話から番号にかけ、その間 /conversations を見て ください。会話が一つも現れないなら、こちらまで何も届いておらず、問題は Octo の 手前にあります — 番号、そのルーティング、あるいはキャリアです。