teamjcurve
AIリーダーシップ
AI NEWS
AIツール
AI Trends
AI Native Lab
Sign In
Home
AIリーダーシップ
AI NEWS
AIツール
AI Trends
AI Native Lab
購読
電話でPCを操縦できるか。
作者
팀
팀제이커브
成功かどうか
失敗
トピック
リサーチ
オープンクロー電話連動実験
目的は、「Slackでキーワードやコマンドを入力すると、ボットが私の携帯電話に電話、音声で会話しながら、自分のPCでタスクをトリガーし、結果を再び音声で知らせる」フローを実際に実装可能であることを検証することでした。
上の映像からインスピレーションを得て行われた実験です。
結論から言えば、アーキテクチャは成立しましたが、Twilio Trialアカウントポリシー、国家制限のため「韓国番号で受信」段階で詰まって、今回のラウンドは失敗で終了しました。
1) 目標と成功基準
欲しいユーザーエクスペリエンスは以下でした。
•
Slackで呼び出されるように、1行のコマンド、たとえば
/callme
または特定のキーワードメッセージ
•
ボットが私の携帯電話に電話をかける
•
通話中に音声で私のコマンドを受け取り、STTでテキスト化する
•
テキストをコマンドで解析し、自分のPCで作業（シェルコマンド、スクリプト実行など）を実行する
•
結果をTTSで読む
•
可能であればMakeなしで動作する
成功基準は最低3段階でした。
1.
SlackトリガーでTwilioの発信が実際にかかる
2.
通話中に音声入力を受信し、サーバーがWebフックを正常に受信する
3.
PCジョブ実行結果を再び音声に返す
2) 初期仮説、ツール選択
最初は「最も簡単な方法」を基準にMake（旧Integromat）で始めました。
•
Slack メッセージ検出、キーワードフィルタ
•
Twilio「Make a call」で発信
•
TwiMLを再生するか、ホストされた音声ファイルを再生する
しかしすぐに問題が明確になりました。
•
Makeだけでは「双方向音声会話、リアルタイム音声入力（STT）、コマンド解析、PC操作」までは無理
•
結局、TwilioのとWebフックサーバーが必要です
それで、アーキテクチャをこのように再定義しました。
•
Slack（トリガー）→CallBot（サーバー）→Twilio（電話、音声収集）→CallBot（ウェブフック）→PC操作（exec）→TTS応答
3）実装アプローチ、MakeなしでSlack Slash Commandに切り替える
MakeなしでSlackで1行でトリガーするには、Slash Commandがよりまっすぐです。
•
Slack
/callme
呼び出し
•
Request URLを使用してCallBotサーバーの
/ slack-call
エンドポイントにPOST
•
CallBotがTwilio REST APIに電話をかける
•
通話中にTwiMLフローに沿ってに音声を受信し、Webフックに送信
ここで重要なポイントは、Socket Modeを書いてもSlash Commandは「HTTP Request URL」が必要だという点でした。イベント受信をソケットで受け取るのと、Slash Commandが呼び出されるパスは別々でした。
4) ngrokの導入、localhostのトラブルシューティング
最初はHOST_URLを
http://localhost:3000
のままにしていましたが、Slack、Twilioがローカルホストではアクセスできず、ngrokが必要でした。
•
https://<ngrok-subdomain>.ngrok-free.dev
形式で外部HTTPS URLを取得する
•
CallBotの
.env
で
HOST_URL
をngrok URLに設定する
•
TwiMLのもngrok URLに置き換えます
途中で
Cannot GET/
画面が浮いて混乱していましたが、これは正常な動作でした。サーバーが
/
ルートを定義していないため、rootとしてアクセスすると、Expressが「Cannot GET /」を表示するのは自然な状態でした。
正常確認はルートではなく次にしました。
•
GET /call-flow.xml
アクセス時に TwiML XML が表示されたら OK
•
POST /slack-call
この外部から 200 で応答すると OK
実際にTwiML XMLが正常に出力され、
/slack-call
も200 OKで応答が戻ってきました。つまり、ネットワーク、ngrok、サーバールーティング自体は成功と判断しました。
5）実際に詰まった支店、Twilio Trial制限、韓国番号認証制限
問題は、通話の発信段階で次のエラーが繰り返し発生したことです。
•
エラー:
21219 The number +82... is unverified. Trial accounts may only make calls to verified numbers.
これはTwilio Trialアカウントの代表的な制限です。 Trialでは、発信先（To）が「Verified」リストにある必要があります。
だからTo番号をVerifiedとして登録しようとしましたが、コンソールでまた詰まっていました。
•
Trialアカウントで「verification call（電話認証）」はサポートされていません
•
「SMS認証」に切り替えようとしましたが、韓国（+82）が「restricted country for verifying a caller ID by SMS」でブロックされました
つまり、Trialアカウントの状態で韓国番号をVerified destinationにすることができる公式パスがブロックされていました。だから構造は正常なのに、ポリシー制限にかかって最後の発信が失敗しました。
6) 「認証されているのになぜunverified?」と思われた理由
途中で「Verifiedと見られるのに21219が浮かんだ」という状況があり、APIで確認してみると決定的な手がかりが出ました。
•
Verified リストに保存された番号形式が
+82
の後に
010
の 0 を含む形で捕まっていました (例:
+82010...
)
•
私たちが実際にダイヤルしたい番号は、通常のE.164フォーム
+8210
です。
この状態では「私が見たときは認証されたようですが、呼び出すときはマッチングができない」という問題が生じることがあります。
ただし、最終的には「韓国番号自体がTrialでSMS認証制限国であり、再認証も妨げられる」が本質的な原因でした。
7) 付随問題、サーバーの再起動、ポートの競合
サーバーを何度も起動する際に、3000ポートの競合が発生しました。
•
EADDRINUSE: address already in use :::3000
この問題は、すでにフローティングノードプロセスを終了して再起動する方法で解決しました。この問題自体は技術的に一般的なレベルであり、重要な障害はTwilioポリシーでした。
8) 今回の実験の結論
今回のラウンドの結論を「技術的成立」と「運営の可能性」に分けてまとめるとこんな感じです。
技術的には成立します。
•
Ngrokで外部HTTPS URLを取得する
•
Slack Slash CommandからCallBotサーバーへのPOSTの流入の確認
•
CallBotサーバーでTwiMLを提供し、TwilioがTwiMLを取得する準備ができているまで完了
運営的には「Trial、韓国番号」の組み合わせで失敗しました。
•
TrialアカウントにはTo番号がVerifiedでなければなりません
•
韓国番号はSMS認証が制限国にブロックされています
•
その結果、トライアル環境では、韓国の携帯電話での通話受信テストは不可能です
9) 次のアクションプラン
現実的なオプションは3つあります。
1.
Twilio有料切替（決済手段登録、Trial解除）
•
目的が「韓国番号で受け取る電話ボット」ならこれが一番直線です。
2.
Twilioを維持するが、韓国番号の受信をすぐ放棄し、バイパステスト
•
例: SMS 認証可能な国番号で To を Verified にして、通話フローのみを最初に検証
•
ただし、これは既存の目標とは距離があります。
3.
プロバイダの変更
•
Vonage（Nexmo）、Plivoなどで同一構造を再実装
•
ただし、既存のTwilio設定を捨てるので費用がかかります。
10）セキュリティメモ、即時措置を推奨
実験中に、認証トークン、キー値がログに公開される瞬間がありました。このような鍵は、外部流出時の費用、アカウントの消臭に直接つながります。
したがって、次のアクションは「即時」が安全です。
•
Twilio Auth TokenはすぐにRotate（再発行）し、既存の値は廃棄
•
.Env
に新しいトークンを置き換える
•
Slack、ngrokなど他のキーも同じように公開されたことがある場合は、すべて交換
11) 短い回顧
今回の実験は、「私が望む製品経験」を実装するために必要な技術スタックと接続構造を素早く確定した点では収穫がありました。一方、「政策、国家制限」などの非技術要因を最初にチェックしないと、実装がいくら当たっても最後から詰まるということを確認しました。
次のラウンドは「Twilio決済切替可否決定」が最初であり、次にSTT、コマンド解析、PCの実行範囲を安全に制限する方法（許可コマンドallowlist、認証トークン、IP制限）を設計する方に行くのが正しい。
Made with Slashpage