大規模な不動産オーナー向けEV充電プラットフォームの要件整理：2種類のドライバーアプリ、プリペイドウォレット、3段階の本人確認

充電器が4口あるマンションの課題は「設置場所オーナー」の課題です。一方、複数の地域にまたがる数十の住宅団地に充電器を設置するオーナーの課題は、性質がまったく異なります。本部の担当者が充電器の前まで行くことはできません。そのため、システムが人手を介さずに次の4つをこなす必要があります。見知らぬ利用者が充電を開始できること、料金を確実に回収できること、不正利用を抑止できること、そして団地別・地域別の実績を本部に示せることです。

私たちは最近、大規模な住宅系不動産オーナー向けに、まさにこの要件整理を行いました。本記事では、その分け方を紹介します。拠点の多いオーナーであれば同じ構造が当てはまるためです。なお、オーナー名は記載しません。また、本記事はサービス開始のお知らせではなく、要件整理の記録です。

すでに稼働しているものと、新規開発のもの

要件整理でもっとも役に立つのは、この2つを明確に分けることです。今回の内訳は次のとおりです。

当社プラットフォームですでに稼働しているもの

• 暗号化されたWebSocketで充電器が接続するOCPP 1.6サーバー。リアルタイムの状態表示と、遠隔での開始・停止に対応
• Web管理ダッシュボード：セッション、決済、アラート、遠隔操作、監査ログ、VAT内訳付きの日次売上レポート（Excel出力対応）
• ブラウザで開くスキャン・トゥ・チャージ画面と、来訪者向けのPromptPay決済
• パートナーネットワークとのOCPIローミング

このオーナー向けに新規開発として見積もったもの（未提供）

• 団地・地域を第一級のグループ単位とするダッシュボード、および本部・地域・団地ごとのロール
• 電話番号ログインのドライバーアカウントと、プリペイドウォレット
• iOS・Android向けネイティブのドライバーアプリ
• 第2フェーズとして、身分証による本人確認、プッシュ通知、アプリ内でのローミング先ステーション表示

この一覧を正直に保つことが重要です。新規開発分をすでに存在するかのように説明すると、顧客との最初のワークショップが訂正の場になってしまいます。

2種類のドライバーアプリ、アカウントは1つ

Webアプリとネイティブアプリは、しばしば二者択一として語られます。しかし不動産オーナーにとっては、同じシステムへの2つの入口です。

Webアプリは来訪者や初めて使う居住者のためのものです。充電器のQRコードを読み取るだけで、インストール不要で充電できます。修正が全員に一度に届くため、更新も最も速い方式です。

ネイティブアプリは日常的に使う利用者のためのものです。周辺ステーションの地図、充電完了や残高不足のプッシュ通知、登録車両、指紋・顔認証によるロック解除、本人確認を追加します。更新はストア審査を経るため、変化はゆっくりです。

この構成を成立させる設計ルールは、両方が同じバックエンドと通信することです。そうすれば、Webで使い始めた人が後からアプリを入れても、同じアカウント、残高、履歴が引き継がれます。もし2つのバージョンがそれぞれ別のアカウントを持つなら、実質的に2つのプロダクトを運用することになります。

充電の流れはどちらも同じ

流れはあえて平凡にしています。利用者はステーションを選び、残高が足りなければ先にチャージへ誘導されます。その後に充電を開始し、アプリには電力量と料金がリアルタイムで表示され、停止すると領収書が履歴に残ります。

flowchart TD
    A["QRを読み取るかアプリを開く"] --> B["ログイン済み"]
    B --> C["ステーションを選び料金を確認"]
    C --> D["残高が十分"]
    D --> E["充電開始"]
    E --> F["電力量と出力と料金をリアルタイム表示"]
    F --> G["停止または満充電"]
    G --> H["領収書を履歴に保存"]
    B -->|"未ログイン"| I["電話番号とワンタイムコードでログイン"]
    I --> C
    D -->|"不足"| J["PromptPayのQRでチャージ"]
    J --> E

ログインしない来訪者もゲストとして充電でき、終了時にPromptPayでセッション料金を支払えます。これにより、誰でも充電器を使える状態が保たれます。この種のオーナーにとっては、公共サービス上の目標であることも少なくありません。

リスクが集中するのはウォレット

プリペイドウォレットは「充電したのに未払い」という問題を解決しますが、要件の中でもっとも問題が起きやすい部分でもあります。重みを担う判断は3つです。

先に保留し、実績額で確定する。 セッション開始時に、システムはウォレット内の最低額を保留します。停止時に実際の料金を引き落とし、保留を解除します。残高ゼロでは開始できず、保留分が請求されることもありません。

決済事業者の確認があって初めて入金する。 チャージはPromptPayのQRで支払います。ウォレットへの入金は、決済事業者からのWebhookで確認できた時点で行い、アプリが「支払った」と言ったことを根拠にはしません。金銭に関して、アプリは信頼できる情報源ではないからです。

充電器への入口は1つ。 ドライバーAPI、管理ダッシュボード、ローミングサービスは、いずれもOCPPサーバーの制御APIを通じて充電器にコマンドを送ります。充電器と通信するのはそのサーバーだけです。監査すべき経路は3本より1本のほうが容易です。

信頼の3段階

すべてのドライバーに同じ上限が必要なわけではありません。ウォレットの上限をそれぞれ設けた3段階を設計しました。

レベル	到達方法	ウォレット
ゲスト	アカウントなし。セッションごとにPromptPayで支払い	なし
電話番号確認済み	SMSで届くワンタイムコードを入力	低めの残高上限
本人確認済み	ネイティブアプリでタイの身分証をスキャンし、自撮りの照合に合格	高めの上限

上限額は顧客と一緒に決めるもので、当社が固定するものではありません。本人確認は第2フェーズの任意機能です。正しく仕上げるのにもっとも時間がかかる部分であり、確認事業者の選定と、身分証画像を取得するアプリに対するストア審査に左右されるためです。

2つのフェーズ、それぞれ単独で稼働可能

第1フェーズ単独でも役に立つように、納品を分けました。第1フェーズは、本番環境、ダッシュボードの改修、アカウントとウォレット、Webアプリとネイティブアプリに加え、充電器の立ち上げ、受入試験、スタッフ研修までを含みます。第2フェーズでは、ネイティブアプリに本人確認、ローミング先ステーション、プッシュ通知を追加します。2つのフェーズは別々に検収し、別々に請求します。

スケジュール上の本当の制約はハードウェアです。充電器の立ち上げは、充電器と現地ネットワークが届いて初めて始められます。そのため、キックオフ時に準備完了日を合意し、開発の早い段階から疑似充電器でテストします。

最初から机の上に並べておくリスク

• ウォレットに関する規制。 前払式のウォレットは、タイでは法的な論点を生みます。最初の数週間で法務レビューを行うことを勧めており、規制が後から変わっても作り直しにならないよう、ウォレットの上限は設定で変更できるようにしています。
• 個人情報。 ドライバーの電話番号や身分証画像は、タイの個人情報保護法（PDPA）の対象です。そのため、同意画面、暗号化、保存期間の上限、アクセスログ、請求に応じた削除を要件に含めています。
• ホスティング方針。 官公庁や大企業の顧客には、ホスティングやセキュリティの要件があることが多くあります。システムはコンテナで動かすため、同じ構成を当社管理のクラウドでも、顧客自身のデータセンターでも動かせます。
• ストア審査。 ウォレットや身分証取得を伴うアプリは審査が厳しくなります。リリースごとに余裕期間を設け、その間もWebアプリは利用可能です。
• 最初のバッチを超えたときの価格。 基本価格は決まった台数の充電器をカバーします。それを超える分は、台数に応じて単価が下がる充電器1台ごとの導入費と保守費にするほうが、拡張のたびの再見積もりより公平です。

コードを1行書く前に答えるべき8つの質問

多数の拠点を所有・管理しているなら、機能一覧よりも、これらの質問が要件を決めます。

1. 各フェーズで何団地・何台か。メーカーと型式は何か。設置は誰が行うか。
2. 充電器は居住者専用か、一般にも開放するか。居住者に別料金を適用するか。
3. 料金は誰が決めるか。駐車料金や滞留料金はあるか。パートナーが一部の拠点を運営する場合、収益はどう分けるか。
4. 指定のクラウドやデータセンターは必要か。準拠すべきセキュリティ基準は何か。
5. ダッシュボードにアクセスが必要なスタッフのロールは何か。各ロールには何を見せるか。
6. 本人確認レベルごとのウォレット上限はいくらか。法務の専門家は誰が手配するか。
7. 本人確認事業者はどこを使うか。
8. 調達手続きでタイ語の書類や特定の書式が必要か。

自社のポートフォリオでこれらを整理したい場合は、拠点数、充電器の台数、電気料金の負担者を hello@simplico.net まで、件名 「Property EV scoping」 でお送りください。48時間以内に、要件のたたき台をご返信します。

FAQ

プリペイドウォレットはすでにプラットフォームの一部ですか？
いいえ。PromptPay決済付きのスキャン・トゥ・チャージ画面、OCPPサーバー、ダッシュボード、OCPIローミングは稼働中です。本記事で説明しているウォレット、ドライバーアカウント、ネイティブアプリ、本人確認は、要件整理した新規開発の範囲です。

ドライバーはアプリのインストールが必須ですか？
いいえ。充電器のQRコードを読み取れば、ゲストとしても、電話番号確認済みアカウントとしても、ブラウザから充電できます。ネイティブアプリは任意で、地図、プッシュ通知、本人確認が加わります。

Webで使い始めて、後からネイティブアプリに移れますか？
はい、設計上そうなっています。アカウント、ウォレット、履歴は共通なので、残高は利用者についていきます。

ウォレット残高がゼロのまま充電されることはありませんか？
充電開始時に最低額を保留します。残高が足りなければ、アプリが先にチャージへ誘導します。

オーナーは団地別・地域別に売上を確認できますか？
そのグルーピングは、要件整理したダッシュボード開発の一部です。既存のダッシュボードでは、VAT内訳付きの日次売上をExcelに出力できます。

どの充電器がプラットフォームに対応しますか？
WebSocket経由でOCPP 1.6Jに対応している充電器であれば利用できます。EV CSMSのページに、当社がセッションを実際に動かしたメーカーを掲載しています。

この記事を書いているのは誰ですか？
タイを拠点とするソフトウェアエンジニアリングスタジオのSimplicoです。タイと東南アジアの事業者向けに、EV充電プラットフォームの構築と運用を行っています。

関連記事

• 設置場所オーナー問題：マンション・ホテル・飲食店に、アカウントを増やさず充電器ダッシュボードを渡す方法
• OCPIとは何か：CPOとeMSPがEVローミングのために本当に構築すべきもの
• 作らなくていいEVドライバーアプリ：OCPP IDタグによるQRコード充電