OCPIとは何か：CPOとeMSPがEVローミングのために本当に構築すべきもの

充電ステーションを運営している、あるいは自社が所有していないネットワークでもドライバーが充電・決済できるアプリを開発している場合、事業を自社ハードウェアの外へ拡張できるかどうかを左右する3文字に必ず出会います。それがOCPIです。

本記事はプロトコル仕様の解説ではありません。OCPIが誰のためのものか、なぜ2年前より2026年の今の方が重要なのか、そして実際に動くインテグレーションを構築するには何が必要かという、事業レベルの視点を整理します。

まず整理すべき混同：OCPIはOCPPではない

EV充電を動かす「OC」から始まる2つのプロトコルがあり、これを混同することが開発チームへの誤った指示につながる最も多い原因です。

OCPP（Open Charge Point Protocol）は物理的な充電器とそのバックエンド管理システムを接続します。「充電開始、充電停止、これがメーター値」という、ステーションと運営者の間の会話です。
OCPI（Open Charge Point Interface）は2つの事業者を接続します。充電ステーション運営者（CPO）とeモビリティサービスプロバイダー（eMSP）です。「あなたの顧客が当社のステーションで充電しました、これが請求です」という、プラットフォーム間の会話です。

シンプルに言えば、OCPPはネットワークの内側、OCPIはネットワークの間で動きます。ドライバーの1回の充電セッションは、本人が気づかないうちに数分の間に両方のプロトコルに触れていることがあります。

2つの役割：CPOとeMSP

CPO（Charge Point Operator）は物理的な充電器を所有・運営します。設置場所の選定、ハードウェア、電力調達、稼働率、OCPP側の制御までを担います。
eMSP（e-Mobility Service Provider）はドライバーとの関係を所有します。アプリ、サブスクリプションや決済アカウント、カスタマーサポート、そして「どこでも充電できる」という約束です。

多くの企業が両方の役割を担っていますが、ドライバーが直接アカウントを持たないネットワークで充電しようとした瞬間、そのセッションと背後の資金決済を成立させるにはOCPIが必要になります。

なぜ今、この論点がより重要なのか

EVローミングはかつて「あれば良い」機能でしたが、今ではコンプライアンス要件であると同時に競争上の最低基準になりつつあります。

国際的な規制の後押し：EUの代替燃料インフラ規制は、公共のCPOに対してリアルタイムの空き状況と価格情報をeMSPに開示することを求めており、OCPIが標準的な実装経路とされています。同様の相互運用性への要求は、公的資金による充電インフラ整備プログラムなど他地域にも広がっています。
ドライバー側の期待：誰もスマートフォンに充電アプリを5つ入れたくありません。ローミングに対応しないネットワークは、対応しているネットワークにセッションを奪われます。
日本市場の文脈：経済安全保障推進法の下でエネルギー・通信インフラの重要性が高まる中、充電ネットワークが複数の外部eMSPプラットフォームとデータをやり取りする設計は、セキュリティとガバナンスの観点からも初期段階で検討すべき論点です。また個人情報保護法（APPI）の観点では、CDRに含まれる決済・利用データの越境移転や第三者提供の扱いを、CPOとeMSP双方の契約とデータフローの両面で整理しておく必要があります。

「新しい市場への展開」や「フリート事業者との提携」がロードマップにあるなら、OCPIは往々にしてチームが早期にスコープしそこねる依存関係です。

ローミングの接続方式：Bilateral対Hub

Bilateral（相対接続）：CPOとeMSPが契約に基づきアクセストークンを交換し、直接接続します。コントロールは効きますが、新しいパートナーが増えるたびに新しいインテグレーションが必要です。
Hub：双方が互いにではなく中央のローミングハブに接続します。1回の接続で、そのハブに参加済みの全パートナーへのアクセスが開きます。拡張は速いですが、個別の関係へのコントロールは弱まります。
混合型：大規模事業者は両方を併用することが多く、戦略的パートナー数社にはBilateral、それ以外はHubという構成が一般的です。

適切なモデルは、必要なローミングパートナーの数とスピードによって決まります。1つの市場で2社のeMSPと組む程度であればHubの複雑さは不要ですが、複数国展開を計画するCPOはほぼ確実にHubが必要になります。

OCPIがプラットフォーム間で実際にやり取りするデータ

Locations — 充電器の位置、コネクタの種類、リアルタイムの空き状況
Sessions — 認証、開始/停止、進行中セッションのリアルタイムステータス
CDR（Charge Detail Record） — CPOとeMSP間の請求・精算に使われる最終的な標準化レコード
Tariffs — ドライバーがプラグを挿す前に実際の料金を確認できるようにする価格情報

CDRと精算のレイヤーを誤ると、派手に失敗するわけではありません。数ヶ月後になって請求の紛争や照合作業の頭痛の種としてじわじわ表面化します。

自社構築、インテグレーション、それともHub利用？

既存のCSMSにOCPI対応を内製で構築 — 充電がプロダクトの中核であり、充電器バックエンド周りにすでにエンジニアリング体制がある場合に理にかなっています。
既存のCSMSにOCPIモジュールを組み込む — より速いですが、セッション・認証・請求データとの連携の質次第です。
ローミングハブ提供事業者経由で接続 — 多数のパートナーに到達するためのエンジニアリング負荷は最小ですが、そのハブの稼働率と商業条件への依存が生じます。

これらはいずれも純粋な技術的判断ではありません。展開する市場の数、必要なパートナーの数、そしてドライバー体験をどこまで自社でコントロールしたいかによって形作られます。

よくある質問

日本国内だけで運営する場合、OCPIは必要ですか？
即座に必須ではありませんが、対象市場の規制が空き状況・価格データの公開を求める場合や、フリート事業者や他ネットワークとの提携を計画している場合、OCPIはパートナーごとの個別インテグレーションを避けるための標準的な経路になります。

OCPIとOICPは同じものですか？
異なります。OICPはHubject独自のプロトコルで、Hubjectのネットワークに接続する場合に限り必要です。OCPIはベンダーニュートラルなオープン標準で、多くのBilateralローミングや規制対応のデータ共有における既定の選択肢です。

どのOCPIバージョンを対象に構築すべきですか？
2026年時点の本番環境の多くはOCPI 2.2.1で稼働しており、規制・税制対応機能が追加されたOCPI 2.3.0の採用も増えています。OCPI 3.0はまだ開発中で、新規本番構築の対象としては時期尚早です。

既存のOCPPベースの充電バックエンドは、作り直さずにOCPIを追加できますか？
セッション、ロケーション、料金のデータモデルがすでに整理されていれば、多くの場合可能です。OCPIレイヤーはOCPPを置き換えるのではなく並行して動作します。両プロトコルは同一の充電セッションの異なる側面を担っているためです。

CDR、料金体系、複数パートナー接続を含め、ローミングを見据えた充電プラットフォームの構築・拡張は、まさに当社のEV CSMS — Charging Station Management System (OCPP/OCPI)サービスが対応する領域です。OCPIインテグレーションのスコープ検討や、自社構築か外部連携かの評価をされている場合は、hello@simplico.netまでご連絡ください。