2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【ServiceNow】ServiceNow Build Agentで写真と地図で道路の異常を伝える道路通報アプリを作るまで。

2
Posted at

はじめに

こんにちは、にわと(𝕏:@niwaniwa2wato)です。

今回は、ServiceNowの開発者チャレンジ「#BuildWithBuildAgentTokyo」への参加記事として、道路の不具合を通報から修繕完了まで追えるアプリ**「RescueGrid」**を作ってみました。

#BuildWithBuildAgentTokyo って何?

日本のServiceNow開発者コミュニティが一緒に「作って・試して・シェアする」  チャレンジです。

グローバルでも開催されているチャレンジと同じコンセプトで、最新機能をハンズオンで体験しながら、実際に動くアプリを作り上げることがゴールです。自分のアイデアを形にして、その体験をSNSやブログで#BuildWithBuildAgentTokyoを付けて共有する企画です。

詳細はコチラをご確認ください!→チャレンジのルール

第1章 道路の異常を連絡し修繕までを結びつけるアプリ「RescueGrid」

市民・職員・業者が使う道路通報アプリ

RescueGridでは、市民が伝えた場所と内容に、職員の判断、業者への作業依頼、施工の報告を結び付ける設計です。利用者ごとに画面を用意し、それぞれの役割に応じて案件を見たり、情報を加えたりできるようにしました。

利用者 操作する内容 業務上の狙い
市民 住所検索、地図上の位置指定、写真と説明文の入力、案件と進捗の閲覧、対応希望の登録 発見した異常の場所と内容を伝える
職員 一覧と地図で確認、公開状態の変更、業者を選んだ作業依頼、完了報告の確認 通報を案件として追い、必要な作業を業者につなぐ
業者 自社の作業依頼を閲覧し、着工と完了を報告 作業の進捗を同じ案件に残す

たとえば、市民が道路のへこみを見つけたら、地図で場所を示して異常の内容を説明します。職員はその情報を確認して対応を判断し、作業が必要なら業者と作業内容を指定する流れです。依頼を受けた業者が現場での対応を報告した後、職員が内容を確認し、市民向けの画面には案件の進捗が表示されます。

同じ案件でも、三者が知りたいことは異なります。

市民が主に知りたいのは「どこで何が起きていて、今どうなっているか」です。

一方、職員が主に知りたいのは「何を確認し、誰へ依頼するか」、業者が主に知りたいのは「どの現場で何を行うか」です。

それぞれの画面を案件で結び付け、通報と作業の記録をたどれるようにしています。

市民がアプリ上で道路の欠陥の場所と内容を伝える

市民の通報画面では、まず住所を検索して候補を選び、地図上の仮ピンを異常がある位置へ動かして場所を確定します。住所だけでは示しにくい道路上の位置を、地図の座標と合わせて伝えるための操作です。
01-location.gif

市民ロールで住所候補を選び、仮ピンを移動して位置を確定した画面です。

通報には異常の概要と説明文、任意の写真を添える設計で、地図で場所を、文章と写真で現場の様子を伝えます。

公開されている案件は、市民向けの一覧と地図から閲覧できます。
すでにある案件に対応してほしいときは「私も対応を希望」をクリックすることで、同じ場所について新たに通報するほかに、既存の案件へ要望を集めることが可能です。
09-citizen-support-count.png

職員が通報を確認して業者へ依頼する

職員画面では通報を一覧で絞り込み、地図で場所を見てから詳細を開きます。
13-staff-filtered-list.png

職員ロールで側溝の案件を絞り込み、一覧と地図から確認しています。

職員は案件の場所と内容を確認し、対応状況や公開状態を扱います。

業者へ依頼する場合は、対象の案件から作業依頼の画面を開き、依頼先と作業内容を入力する流れです。通報の説明に加えて業者に行ってほしい作業を記録することで、発見時の情報と依頼内容が結び付きます。

15-staff-work-order-form.png

業者が状況を報告して市民が進捗を見る

業者画面には、自社に割り当てられた作業依頼が表示されます。業者は依頼の詳細で対象の場所と作業内容を確認して着工を報告し、作業が終わったら完了コメントを登録して職員へ報告します。

04-vendor-report.gif

業者の「完了報告」と、職員が報告内容を確認して行う「検収」を経て、案件全体が終了します。

検収後は、市民向けの画面にも完了が表示されます。
28-citizen-completed.png

市民は業者向けの作業依頼を操作する必要がなく、自分が閲覧している案件の進捗を確認できます。
職員と業者が残す業務の記録を市民向けの表示に反映するところまで、アプリで扱うことにしました。

第2章 道路の異常を知らせ、修繕までの対応をつなぎたい

道路施設の老朽化と自治体の人員制約

RescueGridで道路の通報を扱った背景には、道路施設の老朽化と、それを維持管理する自治体の人員制約があります。

国土交通省の「連携協力道路制度ガイドライン」は、建設後50年以上の道路橋(橋長2m以上)やトンネルについて、2025年には全体の約42%、10年後には約65%になると説明しています。

同じ資料では、技術系職員が5人以下の市区町村は約50%、技術系職員がいない市区町村は約25%とされています。

出典は同ガイドラインの本文1ページです。

受付後にも続く業務

道路の異常を受け付けた後には、担当者による内容の確認、現地確認、修繕の要否の判断、業者への作業依頼、完了確認が続きます。
通報時の写真と場所だけでなく、その後に誰が何を判断し、どの作業を依頼したかも記録する必要があります。

RescueGridでは、受付から完了確認までの記録を案件ごとに残すことを狙いました。
職員が確認した内容を業者への依頼に結び付け、業者からの報告を職員が読み、市民が対応状況を確認する流れです。
担当が替わっても、元の通報と作業の記録を同じ案件からたどれる形を目指しています。

既存の通報サービスを踏まえた位置付け

写真と位置情報による通報は、すでに自治体で使われています。
たとえば町田市のLINE通報では、市が管理する道路の不具合を、写真と位置情報を添えて知らせられます。

今回形にしたかったのは、受付から職員の判断、業者への依頼、進捗表示までをServiceNow上で結ぶ構想です。

第3章 RescueGridのアプリ構成

シーケンス図

利用者の画面とServiceNowをつなぐ

RescueGridの構成を、利用者の画面、API、業務ルール、保存するデータの順に整理しました。

architecture.png

市民、職員、業者の操作をServiceNow内の処理と4つのテーブルにつなぐ構成図です。
三者の画面は、ServiceNowのUI Page上でReactを表示しています。
画面で入力した内容やボタン操作をAPIへ送り、返ってきた案件や作業依頼の情報を表示する構成です。

APIには、標準のTable APIとAttachment APIに加え、アプリ固有の処理を持つScripted REST APIを使っています。
たとえば市民の通報作成は標準Table API、職員の作業依頼作成や業者の進捗更新は独自APIを通ります。
同じServiceNow上のデータを扱いながら、操作に応じて呼び出し先を分けています。

4つのテーブルで通報と依頼を結ぶ

中心となる業務データは、次の4種類です。

テーブル 保存する内容と関係
Issue 異常の場所と内容、対応状況、市民向けの進捗を持つ通報案件
Work Order Issueを参照し、業者への依頼内容と作業の進捗を持つ作業依頼
Vendor 依頼先の業者と、業者のログイン利用者との対応
Support 利用者とIssueを結び、誰が対応を希望したかを記録するデータ

IssueとWork Orderは、ServiceNowの標準のtaskテーブルを拡張しています。
番号や状態などの共通項目を引き継ぎ、Issueには住所や座標、Work Orderには関連するIssueとVendorなどを持たせています。

通報案件と作業依頼を分けることで、市民が伝えた異常と、職員が業者へ依頼する具体的な作業を区別できます。
Work OrderからIssueを参照する構造で、両者を常に1対1にする制約はありません。
職員は通報案件ごとに状況を把握し、業者は割り当てられた作業依頼ごとに報告します。

地図表示と住所検索

地図の表示にはMapLibreを使い、背景地図として地理院タイルを読み込みます。
画面を開いたブラウザがタイルを取得し、案件の座標や通報位置のピンを重ねて表示することができます。

住所検索では、地図表示とは別に通信し、入力した検索文字列をServiceNowサーバーへ送り、サーバーが国土地理院の住所検索APIへ問い合わせて、候補となる住所名と座標を画面へ返します。
市民は候補を選んだ後、地図上でピンの位置を調整します。

住所の文字列と地図上の座標は、別の情報として保存します。
場所の指定には地図と住所検索を使い、業務の記録はServiceNow側で扱います。

まとめ

今回はPDIのBrazil リリースでBuild Agentを試してみました。
Zurichリリースより、UI、モデルの性能、アプリを実装するための会話の道筋もかなり進化した印象です。
CodexやCloude Codeで開発するような感覚にかなり近づいた印象です。
ServiceNow専用に開発するのであれば、Build Agentを利用する方が、Codex等を利用するより長けているかもしれません。

誰でもPDIを利用して、Build Agentを体験できるので、ぜひお試しください!

🗼ServiceNow World Forum Tokyoに参加してみませんか?

ServiceNow Japan 最大規模のカンファレンスイベントが、2026年10月27日(火) - 10月28日(水)で開催されます。最新プロダクト、お客様事例、開発者向けセッションなど、ServiceNowに関わる人にとって見どころ満載の1日になります。普段イベントに参加したことがない方も、これからのモチベーションが上がる1日になること間違いなしです!ぜひ下記リンクから参加登録をしてみませんか?

イベント概要

日程:2026年10月27日(火) - 10月28日(水)
会場:グランドプリンスホテル新高輪
主催:ServiceNow Japan合同会社

World Forum Tokyoの詳細と参加登録はこちら

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?