自治体の職員も住民も使いやすいサービスを無償で　LINE公式アカウント上で活用可能な自治体向けプログラム「GovTech」

GovTechプログラムの活用方法

新田洋平氏：本日は『GovTechプログラムの活用方法』というタイトルで、アーキテクチャ技術概要と開発環境の構築手順についてお話したいと思います。

最初に、本日のセッションのスライドは、のちほどSpeaker Deckというスライド共有サイトで共有されますので、そちらで確認できるようになります。よろしくお願いいたします。

簡単に自己紹介しますと、私はLINE福岡の開発センター、開発2室で室長をしている新田洋平と申します。よろしくお願いします。2012年に家族で福岡に移住して、8年ほど福岡に住んで、LINE福岡には2014年に入社。それからLINEバイトというサービスの立ち上げに関わって、2018年1月より今の室長業務を行なっています。

（今日話す内容は）最初に無償提供しているGovTechプログラムの申し込み方法について紹介します。次に提供しているソースコードをどうやってダウンロードするのか。コントリビュートする場合にどうやって開発に参加するのかについてお話しします。

続いてアーキテクチャの話として、AWSを活用しているこちらのGovTechプログラムのアーキテクチャについて説明します。そして最後に、実際にどのAWSのサービスを利用しているのかについてお話ししたいと思います。

次に開発環境の構築手順として、LINEのプラットフォームとAWSのプラットフォームの両方を連携する必要があるので、そちらについてお話しします。そして、実際に構築したあとのマネジメントコンソールの画面が、どのようなイメージになるかといったことも、画面を共有してお見せできればいいかなと思っています。

さらに、代表的な機能としてセグメント配信やアンケート帳票といった機能があるので、そちらの簡単なデモをお見せいたします。そして最後に、今後の開発ロードマップについてお話しして、本日のセッションを終わりにしたいと思います。

GovTechプログラムの申し込み方法

最初にリポジトリとソースコードです。こちらですが、GovTechプログラムの公式サイトがありますので、そちらから申し込みフォームに移動すると、今画面の右側に出ているような申し込み手順のフォームが出てきます。こちらで個人情報を入力してもらえば、1営業日以内に招待されます。

個人情報として名前や会社名のほかに電話番号、メールアドレス、GitHubのアカウントといった情報をいただいています。これらの情報は、GovTechプログラムに関する連絡や案内、また弊社Smart City Projectの関連のニュースレターの送信以外の用途には利用しません。

続いて、こちらは招待が終わったあとのGitHubリポジトリのイメージになります。現在は利用許諾に同意した方のみに公開しているので、基本的にプライベートなリポジトリとして運用しています。GitHubでコードをクローンすることで、手元の環境にダウンロードできます。

初期状態は読み込み専用のリポジトリになっています。こちらは実際に書き込みする権限がなくても、運用は可能になっています。

もし実際に開発者としてGovTechプログラムの開発をしたい場合があるかもしれません。その場合は、こちらの手順を取ります。最初に、ICLAという個人コントリビューターライセンス契約の同意を求めています。

こちらは、実際のリポジトリからフォームに遷移して、そちらでフォームに書き込んで、こちらで申請に同意したあとに、GitHubのwrite権限を得られるようになっています。

また、バグの報告や新しい機能の改善提案などがある場合は、GitHubのIssue Trackerからイシューを提出してもらいます。そしてコードの修正や追記をする場合は、GitHub標準のPull Requestを用いたワークフローでコントリビュートしていく、という流れになります。こちらは、実際にレビュープロセス、コードレビューなども行なっていくような流れを想定しています。

自治体のシステムに求められる技術要件

そして次にアーキテクチャの話をします。まずGovTechプログラムのアーキテクチャに関してお話しする前に、自治体のシステムに求められる技術要件について考えてみたいと思います。

1点目が環境構築が容易であること。今回で言えば、自治体様向けのLINE公式アカウントを運用するという新しい試みに取り組む必要があります。その中で、システムそのものの導入のハードルが高いとなると、システム導入自体を諦めてしまう可能性もあるので、私たちとしては、環境構築の容易さはとても重要だと考えています。

そして2点目は、新しいシステム導入のために物理サーバーを調達するような予算の立て方は難しいと考えているので、運用コストを限りなく下げる考え方はとても大切です。

続いて3点目はスケーラビリティです。災害時のような緊急事態にシステムが落ちてしまう状況は、自治体システムにおいては何があっても避ける必要がある状況だと考えています。

そして4点目は、セキュリティに対する信頼性です。システムを導入するにあたって、市民や管理機能を利用する職員の情報セキュリティ上の懸念がない状態を作るのはとても大切です。また信頼性が高いという裏づけがあれば予算立案しやすいという隠れたメリットもあるんじゃないかなと思っています。

そして最後に、幅広いエンジニアが対応できる技術選定をすることが大切です。システム構築をする際に、広く使われている技術を使って構築されていれば、トラブルシューティングも容易ですし、たくさんの開発パートナー企業の参画が可能になると考えています。私たちとしては、これらが実際システムに求められる技術要件と考えています。

AWSを広範囲に利用

結論として、GovTechプログラムは「パブリッククラウド」の「フルマージドサービス」を利用するのが最適解であると考えています。

そして私たちは、パブリッククラウドとしてAWSを選定しており、AWS Serverless Application ModelというAmazon Web ServicesさんがOSSで提供している、Serverless Applicationのフレームワークをベースとしたアーキテクチャを選んでいます。

こちらはSAMと呼んでいるんですが、SAMをベースにサービスを利用することで、AWSが提供しているベストプラクティスに、自然と従ったシームレスなサービス開発を実現できました。

そしてSAM CLIは、SAMが提供しているコマンドラインインターフェースです。こちらはターミナルからコマンドを実行することで、簡単に環境構築やデプロイメントができます。

サーバー構築や環境定義は、AWS CloudFormationを利用します。これはいわゆるInfrastructure as Code、インフラの構成管理をコード化することに寄与しています。そしてYAMLファイルですべて一元管理することで、GitHubのリポジトリでシステム構成が完結する流れになっています。

続きまして、こちらはかなり簡素化した図ではありますが、GovTechプログラムのアーキテクチャ図になります。今左側に見えているアイコン4つですね。これらが今回提供している4つの機能に相当します。

まず一番左上のFAQチャットボットは、いわゆるLINEのチャットボットです。そしてアンケートについてはLIFFアプリ。LIFFというのはLINE上で動くWebアプリのことなのですが、こちらを利用して実装されています。

そして3番目の管理機能ですね。これは、典型的なSingle Page Application 、SPAでできています。こちらについては、JavaScriptのフレームワークとして近年フロントエンド開発者にとても人気があるVue.jsを、コンポーネントにはVuetifyを使用して実装しています。

この3つまでは、いわゆるWebアプリの実装レイヤーになっていますが、もう1つセグメント配信の機能として、メールを受け取って……この図で言うと右端の右下にあるLINE公式アカウント、こちらを経由して市民にMessaging API を利用してLINEのメッセージを送信する機能があります。

ここまでで説明した機能すべてが、AWS SAMをベースとして、さまざまなサービスと連携することで動いています。まずチャットボットとLIFFについては、LINEプラットフォーム上で動いているので、インターネット上にWeb APIを露出させる必要があります。

今は左側から2番目の図の話をしていますが、APIsと書いてあるところですね。こちらの認証レイヤーには、AWSのCognito利用しています。そしてAPIアクセスの部分には、API Gatewayを使っています。

そして、これらの露出されたAPIは、画面中央のAWS Lambdaとつながっていて、Lambdaの中でGovTechプログラムの実装コードが動くようになっています。LambdaのRuntimeは、主にNode.jsとPythonを利用しています。今はかなりの割合がNode.jsのLambdaコードになっています。

次に、データベースはDynamoDBを利用していて、セグメント配信のページ情報や、アンケートの回答情報といったものは、すべてこちらのDynamoDBに保存されています。

そしてまた左下の話に戻りますが、セグメント配信のメール受信にはAmazonのSESとLambda、メッセージキューとしてはSQS、これらを連携して実装しています。SESでメールを受け取って、Lambdaでメール本文から必要な情報を抽出。SQSにキューイングして、LINEのメッセージングAPIを使って、LINE公式アカウントを友だち追加したユーザーにメッセージを送る。

これらが全体的なアーキテクチャになっています。すべてがフルマネージドなサービスを利用しているので、運用の手間やコストが非常に少ない構成になっていると思っています。

本当に多くのAWSサービスを利用しているんですが、インフラ基盤や運用に使用しているAWSサービスは、今ここに書いてあるものがすべてです。ストレージ、JavaScriptやこういった画像ファイルといった静的コンテンツはS3、CDNにCloudFrontを利用しています。

そして設定情報や認証情報といった秘匿性の高い情報には、Secrets Managerを利用しています。そしてユーザー管理にはIAM。先ほどもお話ししましたが、環境構築、デプロイメントには、CloudFormationを利用しています。

そしてモニタリングですね。運用上のモニタリングに関しては、CloudWatchやSNSを利用しています。そしてバックアップは標準的だとは思いますが、AWS Backupを利用しています。

また、ドメイン管理や証明書についても、ほかのサービスを利用できないわけではないんですが、やはりサービスの連携上とても都合がよいので、Route53やCertificate ManagerといったAWSのサービスを使っています。このように、たくさんのAWSのサービスを利用してシステムを構成しています。

続いて、私たちはLSC CLIというものを用意しています。LSC CLIは環境構築やデプロイメントのために使う独自コマンドです。コマンドの中で、AWS CLIやSAM CLIをかなり利用しているのですが、これらをラップしたコマンドが、LSC CLIになります。これを利用することで、実際にAWS CLIやSAM CLIを直接使わないので、運用や開発時の作業の簡素化がかなり実現していることになります。

コマンド例としては、今画面に書いてあるようなものがあります。そして実装はインターフェースにbash scriptを利用していて、サブコマンドの実装はTypeScriptを用いています。

たまたまではありますが、最近AWS CLIのNode版も、次のバージョンからTypeScriptを使うようになるので、技術選定としてはわりと相性のいい技術選定をしているかなと考えています。

ここまでが、アーキテクチャの話になります。

エンジニアに求められるスキルセット

次にこのシステムを運用するエンジニアに、求められるスキルセットはどういうものかをまとめてみました。4点挙げていますが、これは大きく2つに分けられます。

AWSの運用経験、そしてサーバーレスアーキテクチャであるAWSサービスの利用経験といったAWS関連の知識。そしてLINEログイン、Messaging API、LIFFといったLINEが提供しているデベロッパー向けのAPIやライブラリ、これらについての知識。これらがあれば、運用できると考えています。

次に、どうしてもこういう場合、出てくるんじゃないかなと思うのですが、GovTechプログラムそのものに手を入れたい場合、どういったスキルがあると望ましいかをまとめています。

ここでは、6個挙げています。これら全部を網羅する必要は必ずしもないと考えています。どれか1つでも経験があるエンジニアでれば、そこを皮切りに開発に参加していけるんじゃないかなと思っています。

GovTechプログラムの環境構築手順

続いて環境構築手順について、GitHubのドキュメントには開発環境の構築手順はかなり詳細に記載されていますが、今日は実際の画面イメージを交えながら、順番に説明したいと思います。

免責事項として、今の構築手順は完璧にシンプルなものかと言うと、そうはなっていないと思っています。ある程度順番に作業する必要がありますし、所要時間もだいたい1、2時間くらいかかります。手順としては、この5つの順番を守って作業する必要があります。

1つずつ順番に見ていきますが、まずLINE Developersのコンソールでチャネルを作る作業があります。これはAWSの環境設定のために、先にLINEプラットフォーム上で設定した情報を得る必要があるので、LINEログインとMessaging APIのチャネルを作成します。

次に、作成したあとにそれぞれのチャネルID、チャネルシークレットを取得します。そしてMessaging APIを介してメッセージを送る必要があるので、チャネルアクセストークンのトークン情報を取得しておきます。

そして、これらの情報をAWS Secrets Managerを利用して保存していくんですが、どのようにやるかと言うと、まず右側のスクリーンショットにあるようなJSONファイルを定義して、そこに先ほど取得した情報を書いていくんですね。そして、LSC CLIコマンドを利用してSecrets Managerに情報を反映させる手順になります。

このときJSONファイル名は、環境名だけではなくて、実際の生成されるサブドメインやAWSの環境名において接頭辞として使用されたりするので、ユニークなものになっている必要があります。すでに利用しているドメイン名にしないような工夫というか、そういったところが必要になるかなと思っています。

続いて現在は、AWSのすべての設定がコマンド化されているわけではないので、ここに挙げているSESとRoute53とCertificate Manager、この3つの設定を先にマネジメントコンソールで済ませておく必要があります。

そして最後に、こちらがGovTechプログラムの環境構築ですね。ここが一番シンプルですが時間がかかるところでして。実際にコマンドを叩くと、40分から50分程度の実行時間がかかります。スクリーンショットは、実際に実行中のスクリーンショットですね。このようなかたちで、どんどん環境が作られていくうかたちになります。

そしてこれが終わると、もう実際に動いている環境ができているので、最後にMessaging APIのWebhookのURLを設定します。これは、実際に設定して動いているかどうか検証する必要があるので、環境を構築したあとにWebhookを設定するといった順番が必要になっています。

そしてこれが、本当に最後の最後なんですが、LINE公式アカウントの管理画面であるLINE Official Account ManagerでWebhookを有効化して、Messaging API経由でメッセージが送れるLINE公式アカウントに設定を変更します。

実際に、今からコマンドを叩いて40分50分待つわけにいかないので、料理番組みたいな感じで、すでに環境が用意されているので、そちらをちょっと今共有したいと思います。

GovTechプログラムの画面例

今画面を共有していますが。こちらがAWSマネジメントコンソールの状態です。これはAPI Gatewayの設定になります。実際に構築されたインスタンスは、こんな感じで4つのAPI Gatewayインスタンスが構築されていて。例えばこのscenario……lscというのは、JSONファイルの接頭辞なのですが。lsc.jsonで生成すると、このようになります。

このように、API Gatewayのファイルを開くと、こうやってchatbotのcallbackURIが設定されていたり、scenarioというのはLINE Bot DesignerのシナリオファイルのAPIですね。このようなかたちでAPI定義がされているというかたちになります。

次に、これも一例ですが、AWS Lambdaの定義ファイル、定義状態はこのようになっています。今（17）と書いてありますが、実際にファンクションが17個定義されていて、ランタイムはこのようにPythonの3.8、Node.jsの12.xみたいに設定されています。

実際のコードはPython3とNode.jsですが、これはJavaScriptで書かれています。このような感じで、AWSマネジメントコンソールに定義が反映されるという流れになっています。

そしてまたスライドに戻りますが、次に代表的な機能の紹介ということで、本日は技術概要の説明に留めているので、実際に構築した機能の説明は行いません。ですので、今から画面共有をして実際の画面や操作感というのがどんなものになっているかを見て、なんとなく雰囲気を把握してもらえたら嬉しいかなと思います。

またこれが実際に環境構築されてアクセスできる管理画面になります。このようにヘッダー部分に実際に使える機能が並んでいます。今はセグメント配信を説明しようかなと思います。

これ、一覧に今条件検索と表示されていますが、一例として毎日配信11/29というセグメント配信があります。こちらで検索してみると、1件ヒットしてこれが出てくるので、実際に開いてみます。

これが配信設定の情報になります。中身がどうなっているかをちょっと見てみたいので、修正ボタンを押してみると、このように実際の配信名や、絞り込み、どのようなセグメントの絞り込みをしているか見てみましょう。

これはテストデータなので、無題質問みたいなちょっと味気ないものになっていますが、その選択肢2を選んでいるユーザーという感じで、絞り込んでいます。これを選んでいるユーザーに、今設定している配信時間で実際に配信が動くかたちになっています。

これだけじゃなくて、実際に先ほども説明しましたが、メールマガジンのメールを受信できるようにして、受信したメールをMessaging APIで流し込んだり。手動配信として、送信時間を定義する配信だけじゃなくて、すぐにメッセージを送信する機能もついています。

次の帳票作成は、実際に答えていただくアンケートの画面イメージを作る機能になります。Googleフォームでアンケートを作るときのようなシンプルなUIになっていて、これはけっこうイメージがしやすいんじゃないかなと思っています。

例えばこれでプラス……今ここが選択されて1個だけ無題質問がありますが、こちらにテストとか入れてみると……これをプレビューすると反映されるみたいな感じです。

ほかに選択肢を増やしたいなと思ったら、プラスボタンを押して、今あるような記述式だけじゃなく、こういったそれぞれフォームのかたちをこうやって選んでいける。けっこう馴染みがあるインターフェースなんじゃないかなと思います。

そして設定したら、プレビューが見れる。こういう感じになっています。これらが代表的な機能になります。ちょっと時間が押してきたので、次に進みます。

GovTechプログラムの運用コスト

ここまでが全体的な流れのひと通りの説明になりますが、GovTechプログラムとしては、気になるのが運用コストの話なんじゃないかなと思います。こちらのだいたいの目安について今できる範囲の情報を共有します。

新規のサーバー調達コストは一切ないので、基本的には低コストの運用が実現できると考えています。マネージド型サービスのみなので、利用量に応じた重量課金体系になります。先行事例では、今月額数千円から1万円くらいの負担に収まっていると聞いています。

これは、実際にはLINE公式アカウントの友だち数であるとか、需要が高まったりしてくると……これはたぶん嬉しい悲鳴だと思いますが、すごく市民に受け入れられて利用される状態になってくると、その利用量に応じて課金額というのは増えていくんじゃないかなと思っています。

そしてLINE公式アカウントそのものについては、地方公共団体プランというのを前提としているので、LINE公式アカウントそのものにはお金はかかりませんし、メッセージ送信1通いくらといったような課金体系もありません。

GovTechプログラムのマイルストーン

最後に、今後のGovTechプログラムのマイルストーンについてお話しします。こちらはプレスリリースにも出ている画像ですが、2020年中にはこれらの追加開発を予定しています。

1つ取り上げると、すべての欄にUIの改善があります。GovTechプログラムは、もともと福岡市LINE公式アカウントというものをモデルとしています。福岡市のアカウントは、そもそもスモールスタートで立ち上げて、徐々に機能を追加していったという経緯があります。

なので、少しユーザーインターフェースやユーザー体験という部分で煩雑になっている面があるので、現在提供している機能を総合的に見て、ユーザーにとって使いやすい、いいユーザー体験が得られるようなUIにしていきたいと考えているところです。

ほかにも粗大ゴミの回収であるとか、今AWS Cognitoによる認証基盤を利用していますが、そのほかの認証に対応したりとか、そういった要望が上がっている機能についても、徐々に対応していきたいと考えています。

以上となります。ご清聴ありがとうございました。