Twilioでオセロ（Reversi）を作ってみました

本記事は、Twilio Advent Calendar 2020の12月22日担当分です。

はじめに

Twilioについて勉強せねば、と思っていたところでタイミングよくAdvent Calendarの話があったので手を挙げてみました。私は普段、Webやメールを扱うエンジニアです。電話を扱う機会はそれほど多くありません。また、Twilioのハンズオンに参加したりドキュメントを読んだことがある程度で、プロダクトでTwilioを使い込んでいるわけでもありません。今回の記事は、Twilio初心者が実際に使ってみて得られた気付きを共有する内容と思って読んでいただけると幸いです。

新しいサービスやハードウェアを理解しようと思ったときに、チュートリアルに沿って手順通り進めるとたいてい動くものができあがるので、なんとなく理解した気分になってしまうのですが、そこから外れたことをやろうと思った瞬間「何から手を付けりゃいいんだっけ」と思考が固まってしまうことがよくあります（自分だけかもしれませんが）。そんな時は、何でもいいので自分で考えたアプリケーションにそのサービスなりハードウェアを組み込んでみるのが、理解のための近道と思っています。

というわけで、Twilioを使ってオセロ（Twilio-Reversi）を作ってみました。

概要

このアプリは、大きく分けて2つの機能で構成されています。一つは、電話機からTwilioの番号に電話をかけてゲームを進める部分です。もう一つは、打った手を対戦相手の電話機にSMSで通知する部分です。

まずはじめにゲームの進行部分です。

（1）電話機からTwilioの番号に電話をかけると、（2）Twilioからアプリケーションに対してWebhookのリクエストが飛びます。アプリケーションはリクエストに応じてゲームを進行させ、（3）状況に応じた結果をTwiMLとして返すと、（4）Twilioは電話機に対して音声応答を返します。これが基本的な流れですが、石を置けない座標を指定したり、手番じゃない方の電話機で石を置こうとすると、（3）の内容が変化して電話機には入力の拒否ややり直しを伝える音声応答が返ります。

次に対戦相手にSMSで通知する部分です。

こちらは非常にシンプルで、SMS APIを呼び出すと、Twilioが以下のようなメッセージをSMSとして対戦相手の電話に送ってくれます。


2台の電話機で交互に電話をかけて石を置いていき、全マスが埋まるか、両プレイヤーがパスをしたらゲーム終了となり、その旨がSMSで通知されます。

気付き

静的なTwiMLとTwilMLを切り替えるプログラム

今回は、すべてのTwiMLをTwilio Node.jsライブラリを使って動的に生成しましたが、よくよく仕様を整理してみると静的なTwiMLを数パターン（正常系、準正常系数パターン）用意して、あとはプログラムでTwilioに返すTwiMLの切り替えを制御するのが良さそうに思いました。こうすることでコード量が減らせて見通しがよくなりそうです。もちろん、TwiMLに動的な内容の埋め込みが必要な場合は、素直にTwilioライブラリを使うのが良いと思います。

電話機の制約されたインターフェイス

電話機からの入力で使えるのは「数字と＊と＃」だけです。可変長のデータを入力させる場合は、このうちデータの終端として1種類を使う必要があります。これらの制約はとても厳しくて、使い勝手のよいインターフェイスにするにはいろいろと注意すべき点がありそうです。

一度に入力させるデータの種類は1種類に

 今回は2種類のデータ（ゲームを特定するIDと石を置く座標）を一度にまとめて入力させることにしましたが、たぶんこれは初見でわかりにくいので、できれば一度に入力させるデータは1種類に絞った方がよさそうです。その分、入力ステップ数が増えてしまうのが難点です。

可変長データはできるだけ避けたい

利用者からみると、データが可変長かどうかなんてわからないので、データの終端文字を入力してもらおうと思ってもなかなか期待通り入力してくれません。データはなるべく固定長がよさそうです。

エラー処理は丁寧に

Webのフォームと違って、キーを押した瞬間入力が確定してしまうので、入力ミスをした際に利用者の負担をできるだけ減らしてあげる工夫が必要そうです。エラーメッセージをわかりやすくしたり、再入力のポイントをわかりやすくしたり、といったあたりでしょうか。

セッションが使えない

Webの場合、セッションを利用して状態の保持を簡単に行うことができますが、電話の場合そういった便利な仕組みはありません。今回はゲーム進行の都合上、石を置いたら毎回電話を切らなくてはいけないので、次に電話をかけた際に、石を置くところに復帰させる方法に悩みました。最終的には、ゲームを特定するIDと石を置く座標を数字で指定させることにしました。

等幅フォントを期待してはいけないメッセージアプリ

上のキャプチャを見るとわかるかと思いますが、ボードの状態をSMSで飛ばした瞬間、絶望しました。スマホ側のメッセージアプリが等幅フォントじゃないので崩れるんですね。少なくとも私のスマホでは。アプリ側でフォント設定を変更することもできません。また、1行に表示可能な文字数も機種によって異なるはずなので、こういうUIには無理があるんだな、と気付かされました。

料金負担設計

やる前から薄々感付いてはいましたが、ゲームを最後まで進めるにはそれなりのお金がかかります。例えばドコモ回線で、TwilioでUSの番号を利用した場合、1ゲームあたり概算で、

  • 国際電話（プレイヤー負担）：60回（30秒）＝60✕31円＝1860円
  • 国際SMS送信（サービス提供者負担）：60回＝60✕9.7円＝582円

これくらいの金額がかかります。料金的な意味で、今回のような用途に電話やSMSがあまり合っていないという話は置いておいて、サービスを設計する上では誰がどういう料金をどれくらい負担するのかを考慮した方がよさそうです。メールやWebと違って電話の場合、基本的に使った人が支払う、かつ、極めてシンプルな従量課金の世界であることを実感しました。


チャージはプロジェクトに紐づく

昔チャージしたポイントが、いつの間にか消えていて不思議に思っていたのですが、チャージしたポイントは「プロジェクト」に紐づくんですね。チャージしたのと別のプロジェクトを選択していて全く気付いていませんでした。赤い芸人さんが詳しく説明されているので、読んで理解しました。プロジェクトはダッシュボードの一番左上のプルダウンで選択できます。


チャージ済みのプロジェクトを削除すると返金される

上述のチャージポイントがプロジェクトに紐づくことに気付く前の話ですが、不要なプロジェクトを削除していたら、そのうちの一つにチャージポイントが残っていたようで、しばらくしたら返金する旨メールで連絡が来ていました。ありがたや。

まとめ

今回はVoiceとSMSのみを利用してみました。最初、Webhookを受ける機能を用意しなくてはいけないのが分かりづらい印象でしたが、そこさえ乗り越えてしまえば、一般的なWebアプリケーションを作成するのと同じスキルでいろいろな機能が利用できそうです。

他にもサーバサイドをFunctions上で動かしたり、UIをFAXにしたり、VerifyやAuthyで二要素認証を入れたり、Videoでお互いの顔が見えるようにしたり、Studioでグラフィカルにワークフローを作成したりとTwilioだけでいろいろな機能を組み込めそうです。

最後に、昔作ったSendGrid-Reversiという同系列のネタもどうぞ。

明日はkimihomさん担当です！

コメント

コメントを投稿

このブログの人気の投稿

Execノードを使う

イメージ
ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はExecノードです。Execノードを使うと外部のコマンドを実行することができます。コマンドが出力した、標準出力や標準エラー出力などをノードから出力できます。 標準出力の内容を出力する 最初に確認するサンプルは「 flows > node-red > function > exec > 01 - Get standard output from external command 」です。 Execノードのプロパティを見ると以下の通りになっています。 実行コマンドは「 echo 」 msg.payload で受け取った値を引数として利用 出力モードは「 コマンド終了時 - execモード 」 コマンド終了時に結果を出力します Execノードには出力ポートが3つあります。 標準出力 標準エラー出力 返却コード 実行すると、標準出力には「 Hello World! 」、返却コードには「 {code : 0} 」が出力されます。この挙動は特に説明することはないかと思います。 標準エラー出力の内容を出力する 次に確認するサンプルは「 flows > node-red > function > exec > 02 - Get error output from external command 」です。外部コマンドのエラーをポートに出力します。中身は先程のサンプルフローとほぼ同じですが、Execノードで存在しないコマンドを実行しています。 実行すると、以下のログが出力されます。これも説明不要かと思います。 実行中に出力する 最後に確認するサンプルは「 flows > node-red > function > exec > 03 - Run external command in spawn mode 」です。出力がコマンド実行中に行われるのがこれまでのサンプルと違う点です。 コマンドはwhieループ内で2秒おきに「 Hello 」を標準出力に出力し続けます。Spawnモードで実行するとループ内でechoコマンドが実行されるたびにログが出力されます。サービスっぽい...
続きを読む

SendGridのX-SMTPAPIヘッダの使い方（Section Tags、Substitution Tags編）

イメージ
前回に引き続き SendGrid についてです。 今回は SMTP API を使ってみました。 SMTP APIについて SendGridのSMTP APIは基本的には普通のSMTPプロトコルに則ったものですが、X-SMTPAPIヘッダというカスタムヘッダを使うことで機能を拡張することができます。 X-SMTPAPIヘッダについて X-SMTPAPIヘッダはSMTPプロトコルの拡張ヘッダです。 X-SMTPAPI: { "category": "newuser" } みたいな感じでJSON形式でパラメータを与えることで機能を拡張します。 Section TagsとSubstitution Tagsについて 今回はSMTP APIで使える機能のうちSection TagsとSubstitution Tagsを使ってみました。 Section TagsとSubsitution Tagsは送信メールの内容を宛先毎に特定の文字列を置換するための機能です。toと合わせて使うことで機能します。 例えば、X-SMTPAPIヘッダの値を以下のような形にします。 { "to": ["test1@xxx.xxx", "test2@yyy.yyy"], "sub": { "-body-": [ "-bodyFemale-", "-bodyMale-" ], "-favorite-": [ "バナナ", "カツオ" ], " "-nickname-": [ "ミキ", "サブロー" ] }, "section": { " "-bodyFemale-": "-nickname-さん！女性向けの商品のご紹介です。", "-bodyMale": "-nickn...
続きを読む

Joinノードを使う（その4）

イメージ
ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はJoinノードの4回目です。終わらねぇ。 確認するサンプルは、 前回 に引き続き「 読み込み > サンプル > flows > node-red > sequence > join > 02 - Manual join mode 」です。 メッセージを結合してkey/valueオブジェクトにする 5段目のフローから見ていきます。ざっくりとした流れは以下のとおりです。 DataノードでCSVデータを送信する CsvノードでCSVデータをJSONオブジェクトに変換する msg.payloadには以下のような値が指定されたメッセージ4つに分解される { name: "Apple", price: 100 } Changeノードでmsg.payload内の値を以下のプロパティに設定する msg.topic = "Apple"（msg.payload.nameの値） msg.payload = 100（msg.payload.priceの値） Joinノードで、2個の受信メッセージごとにmsg.topicの値をキーとしてkey/valueオブジェクトに結合して送信する これを実行すると、以下のようにmsg.payloadにJSONオブジェクトが指定されていることを確認できます。 メッセージを結合して結合オブジェクトにする 先ほどは結合した値がkey/valueオブジェクトでしたが、6段目のフローでは単純にオブジェクト結合します。ざっくりとした流れは以下のとおりです。 DataノードでJSON配列を送信する nameをキーに持つオブジェクトとpriceをキーに持つオブジェクトを交互に含んでいます（実際、こんなに都合の良いデータが生成されることはあるんだろうか） Splitノードで配列データを個別のメッセージに分割します Joinノードで、2個の受信メッセージごとにオブジェクトに結合して送信する これを実行すると、以下のようにmsg.payloadに2個ずつのオブジェクトがJSONオブジェクトに結合されたものが指定されていることを確認できます。ちなみに、Joinノード...
続きを読む