外部システムと連携して最新の情報を取得するLINEボットを作ってみた

こんにちは!
hachidoriの坂口です。
2016年にhachidoriに参画し、サーバーサイドエンジニアとして働いています。

当社は、LINEやFacebook上で公開できるチャットボットを、ウェブブラウザ上で簡単に作成できるサービスhachidoriを開発しております。自分自身、世の中の役に立つと思ってhachidoriを運営しているのですが、「どうやって使ったらいいか分からない」という声が多く存在しています。
チャットボット活用事例は、開発者の僕が実際に作成して、利用しているチャットボットを紹介していく連載コラムの第二弾です。

活用事例② 外部システム連携チャットボット

はじめに
チャットボットと聞くと、Aと質問したらBと回答する、ような設定をひたすら行っていくイメージが強いですが、Bにあたる部分を、外部システム連携することで、チャットボットの返答内容を、常に最新の情報にすることが可能になります。
Bにあたる部分は、例えば、ECサイト上の商品情報などが挙げられます。

世の中には、外部システムとの連携方法が、たくさん公開されています。
色々あるのですが、hachidoriでサポートしているのは、RSSとREST APIです。
前回、簡単にRSSをご紹介したので、今回は、REST APIについて、触れていきたいと思います。
もし、自社システムの情報を、チャットボット経由で検索させたい、などございましたら、是非、システム担当者様に、「うちのシステムは、JSON形式で返却するREST APIの仕組みを持っているか?」と訪ねてみてください。
「はい」と返答が来たら、hachidoriと連携することが可能です。

REST APIの例
世の中には、フリーで公開されている、便利なAPIがたくさんあります。
今回は、一例として、郵便番号から、住所を検索する、zipcloudの郵便番号検索apiをご紹介いたします。
※ご利用の際は、利用規約は、確認しておきましょう。

仕様は、非常にシンプルで、
http://zipcloud.ibsnet.co.jp/api/search?zipcode=探したい郵便番号
というURLにアクセスすると、検索結果が返却される、というものです。

探したい郵便番号をチャットボットでヒアリングし、上記URLに代入すれば、郵便番号の検索結果を、チャットボットが回答する、といった仕組みを構築できますね。
例えば、
http://zipcloud.ibsnet.co.jp/api/search?zipcode=1500032
にアクセスすると、以下のような検索結果が返却されます。

{
 message: null,
 results: [
  {
   address1: "東京都",
   address2: "渋谷区",
   address3: "鶯谷町",
   kana1: "トウキョウト",
   kana2: "シブヤク",
   kana3: "ウグイスダニチョウ",
   prefcode: "13",
   zipcode: "1500032"
  }
 ],
 status: 200
}

では、
http://zipcloud.ibsnet.co.jp/api/search?zipcode=9999999
では、どうでしょう。

{
  message: null,
  results: null,
  status: 200
}

検索結果が見つかりませんでした。
検索結果が見つからないことを示す方法は、APIによって様々です。
仕様として、多いのは、statusの部分が、400になる、とか、messageに「failure」や「not found」が入る、ですが、今回のAPIは、resultsがnullになる、です。

チャットボット上の会話シナリオは、
①郵便番号をヒアリング
②APIにアクセス
③検索結果があれば、結果を表示。無ければ、①に戻る
となりそうです。

hachidori上での作り方
1.まずは、連携設定から、API連携の設定を作り込んでいきます。


zipcloudのURLを入力し、郵便番号に当たる部分には、クエリーの;#郵便番号1;を指定しています。
①郵便番号をヒアリング で、ヒアリングした郵便番号は、郵便番号1クエリーに代入することになりそうです。

2.シナリオの作り込み
では、シナリオを作り込んでいきましょう。
左側のメニューのシナリオをクリック→新しいシナリオを作成する、から、郵便番号シナリオを作成します。
以下のように設定すると、ユーザーが「郵便番号を検索する」に似ている文章をチャットして来たら、チャットボットが「検索したい郵便番号を教えてね」と返答するようになります。

次に、ユーザーが郵便番号を入力してくるので、その値を;#郵便番号1;に代入するように設定します。
画面の一番下のブロックを追加する、をクリックすると、ユーザーアクションが1つ増えます。
クエリーを指定するをクリックして、郵便番号1と入力します。
(もしくは、右側メニューのクエリーから郵便番号1をクリックして、ユーザーアクションの枠内で、再度クリックします。)

これで、①郵便番号をヒアリングは完成しました。
次に、②APIにアクセスです。
赤枠で、BOTのアクションを追加してください、とあるので、クリックします。APIリクエストをクリックします。

APIの一覧がプルダウンで表示されるため、郵便番号を選択します。

これで、②APIにアクセスが完了しました。
最後に、③検索結果があれば、結果を表示。無ければ、①に戻るです。
BOTのアクションを追加してくださいで、表示されたパーツ一覧右下の、開発者機能をクリックします。

プルダウンの一覧からクエリーが選択できるので、ここから、オウムを選択します。
下のSTRにチェック、真ん中のLにチェックを入れて、右側のフォームには、;@郵便番号(results);と入力します。
Lは、LengthのLで、右側のフォームに入力された、アイテムの個数が、左側のクエリーに格納されます。アイテムがない場合は、NULLという文字列が格納されます。

今回の例だと、以下のようになります。

・成功例
resultsのリストに東京都が1つあるため、オウムクエリーに1が格納される

{
 message: null,
 results: [
  {
   address1: "東京都",
   address2: "渋谷区",
   address3: "鶯谷町",
   kana1: "トウキョウト",
   kana2: "シブヤク",
   kana3: "ウグイスダニチョウ",
   prefcode: "13",
   zipcode: "1500032"
  }
 ],
 status: 200
}

・失敗例
resultsのリストがないため、オウムクエリーにNULLが格納される

{
  message: null,
  results: null,
  status: 200
}

③検索結果があれば、結果を表示。無ければ、①に戻るを実現するためには、オウムの中身がNULLか、そうでないかで判別できそうですね。
シナリオ詳細画面の一番下に、分岐オプションがあるため、条件分岐を選択します。
オウムがNULLだった場合のシナリオ

オウムがNULLでない場合のシナリオ

をそれぞれ作成します。
オウムがNULLだった場合のシナリオは、郵便番号が不正です、とでも返しておきましょう。

さらに画面の一番下のシナリオ接続から、郵便番号シナリオに戻るように設定しましょう。

最後に、
オウムがNULLでない場合のシナリオ
では、APIの検索結果を返答するように設定します。

以上で、③検索結果があれば、結果を表示。無ければ、①に戻る設定が完了しました!
お疲れ様です。

3.動作イメージ

statusに400が入るようなAPIだと、オウムに、STRで=、フォームには;@郵便番号(status);を入れて、400かそうでないかを判別すれば良いですし、messageにfailureが入るようなAPIだと、オウムに、STRで=、フォームには;@郵便番号(message);を入れて、failureかそうでないかを判別すれば、同じようなことができるようになりますね!

以上、活用事例第二弾でした!