背景と狙い

分断されたポートを「協調領域」にできるか

　OpenStreetは、シェアサイクルサービス「HELLO CYCLING」を通じて全国各地で事業を展開してきました。その中で浮かび上がってきた課題の一つが、事業者ごとにポートやシステム、業務モデルが分断されていることによる構造的な非効率です。

　同一エリアに複数のシェアサイクル事業者が存在していても、原則として借りた事業者のポートにしか返却できないという制約があります。その結果、目的地付近にポートがあっても利用できない、アプリを使い分けなければならないといった不便が生じ、ラストワンマイルの移動手段としての利便性を十分に発揮できない場面がありました。また自治体の視点においても、事業者ごとのポート設置により、用地確保競争や設置コスト増を招くという課題が生じていました。

　本プロジェクトでは、特定の事業者間の連携にとどまらず、業界横断で再利用可能な形でのポート共有の実現を目指しました。利用者は事業者の違いを意識せず目的地ベースで利用することができ、自治体にとっては公共空間を効率的に活用できる可能性があります。さらに事業者にとっては、協調領域と競争領域を整理することで、持続可能な事業環境につながることが期待されています。

要件定義と設計プロセス

現場で導入できる標準仕様に

　本プロジェクトの要件定義では、「この標準化が誰のどの課題を解決するのか」という視点を意識しながら設計を進めました。

　工藤さんは、利用者、自治体、事業者それぞれの立場から協調領域と競争領域を整理し、現実的に受け入れられる要件の範囲を検討しました。

　「理想的な標準を追求すれば、さらに踏み込める部分もあります。しかし、事業モデルや投資余力は事業者ごとに異なります。横展開できる仕組みにするためには、導入のハードルを上げないことが重要でした」

　要件整理では、各事業者の業務フローの違いを踏まえながら、ポート共有に必要な最小限の要件を定義しました。予約の有無、返却処理の考え方、システム更新頻度などの違いを前提とし、既存システムへの影響を抑えた設計としています。

　実装を担ったテクノロジー統括責任者の横田直也さんは、基本設計・外部設計を以下の方針で整理し、仕様書を読めば開発担当者が実装判断できるレベルまで具体化しました。

• REST APIとMQTTを組み合わせた全体アーキテクチャの整理
• API項目やデータモデルの設計方針の整理
• 業務フロー図とAPI仕様の対応関係の明確化

　設計における重要な論点の一つが、協調領域と競争領域の切り分けでした。料金設計やユーザー体験まで標準化すると、事業者の競争余地を狭めてしまいます。「どこまでを標準化するか」という線引きを、技術面・運用面・事業面の観点から丁寧に整理しました。

技術的特徴と開発内容

REST APIとMQTTでリアルタイム性と導入性を両立

　本プロジェクトでは、REST APIとMQTTという2つの通信方式を組み合わせた構成を採用しました。REST APIは、ポートの場所や名称などの基本情報をやり取りする仕組みです。一方、貸出・返却による在庫の変化など、即時共有が必要な情報についてはMQTTによるリアルタイム通信で対応する設計としました。

　この構成により、すべてのデータをリアルタイム連携するのではなく、必要な部分のみ即時更新することで、実装・運用コストと運用安定性のバランスを確保しています。

　特に駅前などの公有地のポートでは、在庫の偏在や返却不可が利用者トラブルにつながる可能性があります。リアルタイムでポート状態を共有する仕組みを取り入れることで、こうした運用上の問題を抑えることを狙いました。

　また、日本では自治体ごとに公有地利用のルールが異なるため、ポート共有は義務ではなく選択可能な協調スキームとして設計されています。料金体系やUIなどの競争領域には踏み込まず、地域ごとの判断に応じて導入できる構成としました。

　横田さんは、「標準化によって現場の負担が増えるのではなく、むしろ運用がしやすくなる設計であることを重視しました」と話します。

フィールド実証・テスト

池袋エリアでの運用検証

　本プロジェクトでは、ポート共有APIの実装可能性と運用上の課題を確認するため、東京都豊島区・池袋エリアにおいて、HELLO CYCLING（以下HC）とLimeを組み合わせたフィールド検証を実施しました。

　検証は、Limeポート（デュオステージサンシャイン60通り）とHCポート（コンシェリア池袋CROSSIA）の近接した2地点（約300m）を対象に、アプリ上でポートと車両を選択し、予約・解錠・返却までの利用フローを確認しました。

実施フィールド：東京都豊島区（池袋周辺）
実施期間：2026年3月

　今回の検証では、「往路」と「復路」で実現条件が異なることを踏まえ、それぞれ別のシナリオで確認を行いました

• 往路（実運用に近い形での検証）
  HC検証アプリからLimeポート上のLime車両を予約・利用し、HCポートへ返却する流れを検証しました。HC側では受入・管理ロジックが実装されており、Lime車両をHCポートへ返却できることを確認しています。
• 復路（UX先行の検証）
  HC車両をLimeポートへ返却するケースについては、Limeポート情報を取り込み、HCシステム側で一時的に受付処理を代行するシミュレーション構成を採用。想定されるユーザー操作や利用手順（UX）と業務ロジックを先行して確認しました。

　このように、実装済みの領域は実運用に近い形で検証し、未実装の領域についてはUXや運用成立条件を先行して確認する形で、社会実装に向けた段階的な検証を行いました。

　実証の結果、往路（HCアプリ→Lime車両→HCポート返却）は実運用に近い形で成立することを確認しました。

成果と課題

ポート共有の実現可能性と今後の論点

　本検討を通じて、ポート共有を前提としたシステム連携の基本的な枠組みを整理し、実証を通じて成立条件を確認できたことが成果です。

　具体的には、REST APIによるポート情報連携に加え、予約・解錠・決済といった「制御」領域の連携については実装を先行し、異なるシステム間でもこれらの処理が連携できることを確認しました。

　一方で、社会実装に向けた課題は「管理」領域、すなわち在庫更新・キャパシティ管理、リアルタイム同期にあります。特に日本の都市部の公有地のポートでは、車両の溢れ（キャパシティ超過）を防ぐため、予約・利用開始・返却といったステータスを高い精度で同期する仕組みが求められます。この点は、標準仕様を検討するうえでの重要な論点として整理されました。

　今回の検証を通じて、今後の論点は大きく次の3点に整理されています。

• 双方向のイベント連携（Webhook等）によるリアルタイム同期の実装
• キャパシティ（枠）管理の設計思想の違いと、ポート運用要件の整合
• 強制イベント（自動終了・強制返却など）を含む例外処理の整理

　本実証では、ポート共有が「制御」領域では一定程度成立することを確認しました。一方で、「管理」領域のリアルタイム同期やキャパシティ運用については、社会実装に向けた課題が残ることも明らかになりました。

今後の展望

業界横断の仕組みとしてどう広げるか

　本プロジェクトで整理したポート共有APIの仕様は、特定の事業者間の個別連携にとどめるのではなく、複数事業者が段階的に参加できる業界横断の仕組みとして展開していくことを目指しています。そのためには、技術仕様の整理に加え、現場運用で支障が生じない導入条件や検証プロセスを共有し、参加事業者が増えても連携コストが大きくならない仕組みを整えることが重要です。

　今回の実証で得られた示唆を踏まえ、今後は次のステップで検討を進める方針です。

• 双方向イベント連携を前提とした相互受入の実装条件の整理
• リアルタイム同期とキャパシティ管理の実装（日本の公有地運用に対応した精度）
• 限定範囲での先行導入から、参加事業者の段階的拡大

　本プロジェクトの狙いは、特定事業者間の連携を実現することだけではなく、ポート共有を協調領域として定着させ、事業者や地域が変わっても再利用できる仕組みとして広げていくことにあります。

　今後は、実証で確認できた領域を活用しながら、リアルタイム同期やキャパシティ管理といった課題の整理を進め、地域交通におけるシェアサイクルの活用に向けた共通基盤の整備について検討を進めていきます。