Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
安否確認を LINE Bot で
Search
sumihiro3
February 02, 2023
Programming
0
340
安否確認を LINE Bot で
【大阪会場で新年会!】LINEDC&LDGK 新年LT会【事例/ミニアプリ/bot開発Tips】
sumihiro3
February 02, 2023
Tweet
Share
More Decks by sumihiro3
See All by sumihiro3
LIFF Mock 使ってますか?
sumihiro3
1
440
20240120_SeikaEXPHack2024_テクニカルインプット.pdf
sumihiro3
0
56
LINE API を使って自治会を活性化する地域ポイントPFを開発した話
sumihiro3
0
190
TechSeeker Hackathon LINE API テクニカルインプット
sumihiro3
0
120
TechSeeker Hackathon 本番で使えるLINEのAPI紹介&過去作の紹介
sumihiro3
0
140
飲食業イベント向けLIFFアプリを開発した話
sumihiro3
0
1.1k
LINE ミニアプリ開発の現場から
sumihiro3
2
690
LINE API 総復習シリーズ LINE ミニアプリ 編
sumihiro3
1
280
時代が追いついた!? LINEミニアプリと共に拡大する順番待ちソリューション
sumihiro3
1
1.1k
Other Decks in Programming
See All in Programming
テストケースの名前はどうつけるべきか?
orgachem
PRO
0
140
StarlingMonkeyを触ってみた話 - 2024冬
syumai
3
270
採用事例の少ないSvelteを選んだ理由と それを正解にするためにやっていること
oekazuma
2
1k
コンテナをたくさん詰め込んだシステムとランタイムの変化
makihiro
1
130
Stackless и stackful? Корутины и асинхронность в Go
lamodatech
0
790
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
940
テストコード文化を0から作り、変化し続けた組織
kazatohiei
2
1.5k
tidymodelsによるtidyな生存時間解析 / Japan.R2024
dropout009
1
790
今年一番支援させていただいたのは認証系サービスでした
satoshi256kbyte
1
260
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
6
1.1k
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
190
情報漏洩させないための設計
kubotak
2
250
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
How to Ace a Technical Interview
jacobian
276
23k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
A Tale of Four Properties
chriscoyier
157
23k
How To Stay Up To Date on Web Technology
chriscoyier
789
250k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Building an army of robots
kneath
302
44k
Transcript
҆൱֬ೝΛ -*/&#PUͰ -*/&%$-%(,৽-5ձ 2023.02.02 Sumihiro Kagawa
祝 オフライン会場 イベント再開︕ 🎉 🎉 2
⾃⼰紹介
⾃⼰紹介 n 加川 澄廣(かがわ すみひろ) l 兵庫県在住 l LINE API
Expert (2019.04〜) l 所属 Ø 株式会社ブレイブテクノロジー - LINE ミニアプリを利⽤したサービスの開発・運⽤をしています - LINE DC での活動が縁で、趣味が仕事に繋がっちゃいました l 趣味 Ø 開発コンテストへの参加 Ø e-bike でゆるゆる⾛る - 時には 100km 超えの⻑距離(アワイチ、ビワイチ など)も⾛ります sumihiro3 sumihiro.kagawa 4
本⽇のテーマ
LINE Bot で安否確認 6
突然ですが n背景説明 l 社内で “ISMS管理責任者” を担当しています Ø 昨年に ISMS(※)認証を取得 •
※: 情報セキュリティマネジメントシステム, JIS Q 27001:2014 - 情報資産の管理や、情報セキュリティ対策、情報セキュリティインシデント の管理や改善などの基準を整理して認証を取得しました Ø 運⽤における “BCP (事業継続計画)” の⼀環で、年に⼀ 度「安否確認」の運⽤テストを実施します
安否確認 n主な流れ 実施すること 概要 緊急連絡先の収集 従業員の皆さんから休⽇にも連絡可能な⼿段を収集 送信先の設定 収集した連絡先を ML などに登録
事業継続観点での設問設定 “災害あったけど無事︖出勤はできそう︖” などの確認 災害情報の収集 災害はいつ、どこで発⽣するか分かりません 安否確認報告の依頼 災害の発⽣場所に応じて、誰に連絡すべきかを整理 安否確認報告の収集、催促 全員が安否報告を実施しているかを確認、未報告の⽅ には催促を実施 安否確認報告結果の整理 報告⽤にまとめる खಈͰΔͷ໘Ͱ͢ʜ
⾯倒なことは LINE Bot にやってもらおう 9
安否確認 n主な流れ 実施すること 緊急連絡先の収集 送信先の設定 事業継続観点での設問設定 災害情報の収集 安否確認報告の依頼 安否確認報告の収集、催促 安否確認報告結果の整理
໘ͳՕॴ -*/&#PU ʹ͓ͤ
安否確認 Bot ができること n友だち登録するだけで連絡先を Get︕ l 友だち登録時に⽒名と居住地を登録して もらう
安否確認 Bot ができること n災害情報を⾃動で収集 Ø 地震情報をほぼリアルタイムで提供されている API を利⽤ し、定期的に情報を収集 https://www.p2pquake.net/json_api_v2/
安否確認 Bot ができること n災害発⽣時に対象者へ⾃動で安否確認 メッセージを送信 l 地震情報を知ってから送るのではなく、 ⾃動で検知して送信できる - 災害発⽣地域に住んでいる⼈だけに送ることも⾃動で
できる - オフィスのある地域で発⽣した場合は全員に送るなど の設定も可
安否確認 Bot ができること n安否報告も LINE からポチポチするだ けで完了 l 災害時の慌ただしい時でも簡単に報告で きる
- FlexMessage を使うと視認性が上がるのでオススメ
安否確認 Bot ができること n報告結果はスプレッドシートへ登録 Ø Google スプレッドシートを DB として利⽤ Ø
安否確認の報告状況はスプレッドシートで誰でも容易に閲 覧できる Ø 回答が完了していない⽅には時間をおいてリマインド
システム構成・利⽤技術
None
主な利⽤技術(LINE) 利⽤技術 ⽤途など LINE Messaging API 皆さんおなじみ LINE を使った Chat
Bot 等を容易に構築できる API Ø UI は LINE トークルームで提供されるものを利⽤できるのでスピーディーに サービス開発できる FLEX MESSAGE SIMULATOR FlexMessage を簡単操作で作成できる便利ツール Ø GUI 操作で優れたレイアウト、視認性の⾼いメッセージを構築できる Ø 構築したメッセージを JSON 形式で出⼒できるので、コードへコピペするだ けで利⽤できる https://developers.line.biz/flex-simulator/
主な利⽤技術(その他) 利⽤技術 ⽤途など Google Apps Script (GAS) Google が提供する、主にGoogleのサービスを⾃動化するスクリプ ト⾔語と実⾏環境
Ø LINE Messaging API の Webhook 受信や、地震情報収集などの実⾏環境とし て利⽤ Clasp GAS のローカル開発環境や CLI を提供 Ø ローカルでは TypeScript で実装でき、GAS 実⾏環境への Push 時に GAS (JavaScript) へのトランスパイルをしてくれる Ø スプレッドシートなどのクラスも提供されているので型が使えて便利 Google スプレッドシー ト みんな⼤好きスプレッドシート Ø今回は DB として利⽤ Øエンジニアではない⽅でも容易に読み書きできるのも採⽤理由の ⼀つ
今回のアプリ実装での ポイント
1. Chat Bot といえばステータス管理 nステータス管理がうまくされないと、Chat Bot が 場違いな回答をしてしまう恐れアリ Ø ユーザー登録、安否報告などユースケースごとで状態管理
Ø 状態を表す Enum などを定義して状態管理での例外を少 なくする
1. Chat Bot といえばステータス管理 namespace Users { /** * ユーザー登録状態を表す
Enum */ export enum UserStatus { /** 友だち登録直後 */ CREATED = 'CREATEDʼ, /** ブロック後 */ DELETED = 'DELETEDʼ, /** ⽒名登録された状態 */ NAME_REGISTERED = 'NAME_REGISTEREDʼ, /** 居住地が登録された状態 */ AREA_REGISTERED = 'AREA_REGISTEREDʼ, /** ユーザー登録が完了した(安否確認メッセージを送信できる)状態 */ READY = 'READYʼ, }
1. Chat Bot といえばステータス管理 // ユーザーのステータスに応じた処理を実施する switch (user.status) { case
Users.UserStatus.CREATED: // ユーザーの名前を登録 updateUserEmployeeName(user, message, replyToken); break; case Users.UserStatus.NAME_REGISTERED: // 居住地を登録 updateUserArea(user, message, replyToken); break; case Users.UserStatus.AREA_REGISTERED: // 登録完了状態とする updateUserEntryCompleted(user); break; default: // デフォルトのメッセージを返す const textMessage = LineApi.createTextMessage(`${message}ンゴ`); LineApi.replyMessage([textMessage], replyToken); } 状態の型を明確にできていれば例外 的な処理(if のネスト)などもなく コードもシンプルになる ↓ テストコードも書きやすくなる
2. ユーザーからの反応は “Postback” をうまく使おう nテキスト送信してもらうと⼊⼒がブレ、 処理が複雑になるので避ける Ø 安否確認の場合、簡単・正確に処理できる よう選択肢ボタンを押してもらうのが適切 -
ボタン押下でテキストメッセージを送るのではなく、 Postback で定型データを送信 - 下記のようにクエリーパラメーター形式としています • “type=confirmation&id=1&question=3&answer=⼀部損壊”
2. ユーザーからの反応は “Postback” をうまく使おう { type: 'buttonʼ, action: { type:
'postbackʼ, data: ʻtype=confirmation&id=1&question=3&answer=なしʼ, label: 'なしʼ, displayText: 'なしʼ, }, style: 'primary', }, { type: 'buttonʼ, action: { type: 'postbackʼ, data: 'type=confirmation&id=1&question=3&answer=⼀部損壊ʼ, label: '⼀部損壊ʼ, displayText: '⼀部損壊ʼ, }, style: 'secondaryʼ, }, 単なるテキストでは判別できない、 質問の特定に必要な情報(どの安否 確認の、何問⽬への回答か)などを まとめてサーバーへ送信できる サーバーへ送信するデータと、タイムライン で表⽰される吹き出しテキストを分けて設定 できる
まとめ
まとめ 1. Chat Bot といえばステータス管理 Ø ステータス(状態)はユースケース毎に存在する Ø 型付けされているとシンプルなコードが書けます 2.
ユーザーからの反応は “Postback” をうまく使おう Ø ユーザーのテキスト⼊⼒は、データとしての信頼性は低い Ø ⾃由⽂の解析は⼿間がかかるだけなので、出来るだけ定型化 3. 業務で使う Bot なら GAS という選択肢はアリ︕ Ø エンジニアでない⼈との連携にスプレッドシートは便利 Ø Webhook 受信可能なので Bot サーバーとして問題なし - GAS デプロイ処理と、Messaging API の Webhook URL 変更を⾃動化できると尚良い
ご清聴 ありがとうございました︕
SNS アカウントなど @sumihiro3 Sumihiro.Kagawa LINE API Expert 29
E.O.C.