検討は次の順がおすすめです。
- 商品区分と、バス乗車券が周遊施策のどの層かを決める
- 交通系IC・QR乗車券・見せ券の正を選び、運行日・路線単位を表に固定する
- 導入手順どおり試運行する
- 運賃・精算と周遊券接続をメモし、次の見積・打合せに回す
以下、この順で説明します。
バス乗車券の方式｜周遊施策との位置づけ
バスの乗車券デジタル化は、大きく次の 3つの区分 に分けて考えるとぶれにくいです。
表は横にスクロールできます
| 区分 | 内容 | 典型例 |
|---|---|---|
| 単路線・単券種 | 1事業者・1路線（または循環1系統）の1日券・回数券 | 観光循環バスのデジタル1日券 |
| 事業者横断の乗車券 | 同一エリア内の複数路線を1事業者または連合で販売 | 路線ネットワーク共通1日券 |
| 周遊パスに内包 | バス＋鉄道・施設・クーポンを1商品に束ねる | フリーパス・MaaSチケット |
周遊施策では、来訪者向けには「1枚で乗れる」見せ方が重要ですが、バス側のマスタは路線コード・運行日・ダイヤ単位で管理されています。DMOが前面に出る商品設計と、事業者の運行システムの粒度がずれると、券面の有効路線リストや検札ログの突合が後から複雑になります。
単路線のデジタル乗車券導入から始め、需要を見て周遊パスへ拡張する進め方が多いです。最初から複数社精算まで含める場合は、方式選定の前提が変わります。
交通系IC・QR乗車券・見せ券｜利用確認の比較
IC改札のないバスでよく比較されるのは、次の3種類です。端末が要るか、停留所ごとのデータ（ODに近いログ）が取れるか、乗務員が何を見るか——この3点で選びます。
表は横にスクロールできます
| 方式 | 端末 | OD・乗降ログ | 乗務員 | 向きやすい路線 |
|---|---|---|---|---|
| 交通系IC | 運賃箱・ICリーダーが必要 | 乗降タッチで停留所ペアが取りやすい（IC利用者が分母） | 降車タッチの案内など、従来の運賃箱運用 | 距離運賃・定期券・日常路線 |
| QR乗車券 | カメラ付き読取機が必要 | 乗車・降車の両方を読取すると停留所ログが取りやすい | 読取失敗時の声かけ。移行期は目視→端末 | 事前購入1日券、複数社周遊パス |
| 見せ券 | 基本不要（車載リーダーを足す選択肢あり） | 利用件数中心。停留所別は弱い（端末を足せば改善） | 画面提示の確認。混雑時は負荷が上がる | 季節周遊バス、均一運賃の1日券 |
端末の有無だけでなく、導入（初期）とメンテナンス（ランニング）の負担も方式で変わります。金額は路線数・車両台数・委託形態で大きく異なるため、ここでは見積前に揃えるコストの種類に絞ります。
表は横にスクロールできます
| 方式 | 導入で増えやすいコスト | 運用・メンテで継続して見る項目 |
|---|---|---|
| 交通系IC | 運賃箱・ICリーダーの新設・更新、清算・運賃表連携の設定 | 端末端末保守、運賃改定時の反映、IC利用者以外への案内 |
| QR乗車券 | 乗降口または車内への読取端末、設置・配線、決済端末との共用調整 | 端末故障・読取失敗、通信障害時の代替、ソフト更新 |
| 見せ券 | 販売チャネル（MaaSアプリ登録、Web・ウォレット構築、路線向けクラウド） | ダイヤ・路線マスタの同期、プラットフォーム利用料、繁忙時の乗務員工数 |
交通系ICは、すでに運賃箱がある路線の延長です。QR乗車券は、スマホのQRを乗降口の端末で読む型で、宮古島周遊フリーパスのように乗り降りの2回読取で利用回数や停留所を残す例があります（端末は決済用リーダーと共用することが多いです）。
見せ券は、乗るときに購入済み画面を見せる方式です。端末を置かずに始められる一方、繁忙時は乗務員の目視がボトルネックになりやすいです。ここだけ、もう一段階分けます。
見せ券 — 既存MaaS・乗換アプリ内 — RYDE PASSやジョルダン乗換案内など、すでに来訪者が入れているアプリの中で1日券を売り、購入済み画面を見せる型です。新潟市観光循環バス（RYDE PASS）、神姫バス周遊線の企画1日券（RYDE PASS）のように、バス1日券が主で券種が少ないときに選ばれます。購入はアプリ側、現地は提示・検札（または後からQR端末）に役割を分けやすいです。導入は路線登録・券種設定が中心で、車両端末を後から足す場合はその分が追加見積になります（神姫バスはQR企画券実証後、乗務員提示から端末読取へ移行した例があります）。
見せ券 — 周遊バス向けの自前販売サイト — その路線・周遊商品用に、販売主体がWebとチケットウォレットを用意する型です。イベント振興券のような広域「施策サイト」とは別で、バスの運行単位・1日券・季節ダイヤに合わせた販売が中心になります。バス＋施設・クーポンを同じウォレットで見せたい、複数事業者精算を自分たちで設計したいときに検討します。ニセコ周遊バス（スカイバス）のように、自前サイトで事前購入し、停留所で画面提示やNFCで利用画面を出す運用が該当します。路線バス向けクラウド（ロコバスチケット等）は、事業者が販売主体のときに、路線管理・QR読取とセットで見積もる別枠です。
販売主体がバス事業者ではないとき（DMO、観光協議会、実行委員会、受託の旅行・地域商社など）は、周遊バス向けの自前販売サイト＋見せ券が選ばれやすいです。券の売上・返金・来訪者向け案内の窓口が事業者側にない一方、QR読取機や運賃箱の更新は事業者の車両・運行の取り決めに依存するため、販売主体だけが端末導入まで押し切れない案件が多いからです。事業者と「提示確認のみとする期間」「のちに端末を足す条件」を役割分担で切り分け、販売側は専用サイトで券種と精算を握る形が現実的です。
デジタル乗車券の導入では、路線ごとに上表のどれを正にするかを決めます。距離運賃の本線はIC、観光1日券はQRか見せ券、という組み合わせも多いです。見積依頼では、初期（端末・構築）・月次（保守・プラットフォーム）・当日（乗務員・問合せ）を分けて見積書をそろえると、方式の比較がしやすくなります。通信が弱い区間では、紙引換や乗務員リストなどオフライン代替を見積範囲に含めてください。
バス事業者の運行単位制約｜日替わり路線と券種設計
バス事業者の運行は、運行日・路線・便がセットです。ダイヤ改正、季節運行、イベント臨時便、代走バスが年度内に発生すると、券種の有効期間・対象路線リストをマスタと同期させる必要があります。デジタル乗車券の導入の見積前に、次を固定しておくと後戻りが減ります。
表は横にスクロールできます
| 運用単位 | 決める内容 | ずれると起きやすいこと |
|---|---|---|
| 1路線・1シーズン | 運行期間、休運日、1日券のみか回数券もか | シーズン外に売れた券の扱い |
| 1事業者内複数路線 | 共通1日券の対象路線表 | 一部路線だけ改札方式が異なる |
| 複数事業者 | 検札データの事業者コード、精算締め日 | フリーパス内の「どの会社の便か」の突合 |
観光周遊の循環バスでは、均一運賃・1日乗り放題が多く、上限運賃型のタッチ決済実証も行われています。一方、路線バスの通常ダイヤでは、距離段階制とデジタル券の組み合わせが難しい場合があり、導入範囲を「観光系統のみ」に限定する判断もあります。
デジタル乗車券をバス単体で完結させるか、周遊券商品の一部として載せるか、誰が販売主体かで、委託先の型が変わります。
表は横にスクロールできます
| 販売主体 | 向きやすい型 | 端末（IC・QR）を置きにくい理由 |
|---|---|---|
| バス事業者（直販・自社企画券） | 交通系IC、QR、RYDE PASS等のMaaS内、ロコバス型クラウド | 自社車両・運賃箱を更新できる |
| 事業者以外（DMO・協議会・実行委員会等） | 周遊バス向けの自前販売サイト＋見せ券（必要ならNFCで画面表示） | 他社運行・精算が絡み、事業者との取り決めなしに車載端末を決められない |
表は横にスクロールできます
| 型 | 向きやすい条件 | 複数券種・独自精算が増えたとき |
|---|---|---|
| MaaS・乗換アプリ内（RYDE PASS、乗換案内モバイルチケット等） | 事業者参加型で既存アプリにバス1日券を追加 | 施設セット・複数精算はアプリの枠次第 |
| 周遊バス向けの自前販売サイト | 販売主体が事業者以外、または路線・シーズンに合わせたWeb＋ウォレット | 事業者別精算・券種追加を一体設計 |
MaaS・乗換アプリ内の強みは、事業者参加の路線登録と、来訪者がすでに入れているアプリ上の購入フローです。周遊バス向けの自前販売サイトの強みは、購入画面を自地域のWebに置き、販売主体が事業者以外のときの売上窓口、バス＋施設・複数社精算の購入済み一覧、路線・シーズンに合わせた券面設計を一体にできる点です。見積表では購入画面と端末導入を並べて選びます。最初から広域フリーパス設計の案件では、単路線のデジタル乗車券だけを後付けすると二重マスタになりやすい点だけ、見積前に共有しておくとよいです。
市場では、路線バス向けクラウド乗車券（ロコバス等）で、事業者単位の路線・運賃表・売上レポートをパッケージ化したサービスもあります。自社ダイヤシステムとの連携範囲は見積時に機能一覧で確認してください。
デジタル乗車券の導入手順｜試運行から本番まで
バス路線へのデジタル乗車券の導入は、次の5段階で進めると現場と事務局の認識が揃いやすいです。
- 1. 対象路線と券種の確定 — 1日券・回数券・企画券のどれから始めるか、紙併用期間
- 2. 利用確認方式の選定 — 交通系IC / QR乗車券 / 見せ券（MaaSアプリ内か自前販売サイトか）の正
- 3. マスタ連携 — 運行日・路線コード・運賃表の更新フロー（誰がいつ反映するか）
- 4. 試運行 — 社内・招待者購入、繁忙停留所での検札リハーサル
- 5. 本番と併用終了条件 — 紙1日券を止める日、問合せ窓口の一本化
試運行では、バス停案内と車内放送の文案を、購入URL・表示画面と同じ用語に揃えます。周遊来訪者向けに多言語が必要なら、券面と案内の言語セットをステップ2で固定します。
運賃・精算｜複数事業者との連携
デジタル乗車券の売上は、チャネル（アプリ・Web・窓口代理）と、バス事業者への分配単位で設計します。
| 論点 | 確認すること |
|---|---|
| 手数料負担 | 決済手数料、プラットフォーム利用料を乗客・事業者・DMOのどれが負担するか |
| 精算粒度 | 1路線・1事業者・1日単位の売上CSV |
| 未使用券 | 有効期限切れ、天候休運時の返金または振替 |
| 監査 | 補助金・実証事業の報告に必要なログ項目 |
単一事業者の循環バスなら、1CSVで完結しやすいです。複数社フリーパスでは、乗車ログから事業者別に按分するルールを、導入前に按分ルールへ書き込みます。
周遊券との接続｜フリーパス・セット券
バス単体のデジタル乗車券が安定したあと、周遊券（鉄道・施設・クーポンセット）へ拡張する案件が増えます。接続点は次のとおりです。
- 券種の正本 — 1日バス券だけ先にデジタル化した場合、フリーパス発売時に同じQRを流用できるか
- 表示 — 来訪者には1枚の周遊パス、裏側では事業者別チケットが複数枚
- 検札 — 事業者ごとに端末またはアプリ画面が分かれるか
バス路線の方式と運行単位が固まっていると、広域周遊の要件メモにそのまま転記できます。
まとめ
- 対象路線・券種と運行日・路線単位を1枚のメモに固定する
- 方式表で交通系IC・QR乗車券・見せ券の正と、初期・保守・当日オペの見積列を埋める（見せ券は購入画面と端末分担も表に書く）
- 試運行の日程と紙併用終了条件を決め、社内・招待者購入で検証する
- 運賃・精算を確認したうえで、周遊券拡張用の接続メモを次の見積・打合せに回す
機能・導入イメージの詳細は、サービスサイトで確認できます。
よくある質問
Q1. IC改札がないバスでもデジタル乗車券の導入は可能ですか？
可能です。交通系IC（運賃箱）、QR乗車券（読取端末）、見せ券（画面提示）から選びます。観光周遊の1日券では、RYDE PASS等のMaaSアプリ内販売、自前販売サイト、QR端末読取を路線ごとに組み合わせる例があります（混雑・ログ・販売主体で比重が変わります）。
Q5. 見せ券
MaaSアプリ内と自前販売サイトの違いは？ — MaaSアプリ内（RYDE PASS、乗換案内モバイルチケット等）は、購入が既存アプリの導線に載る点が特徴です。周遊バス向けの自前販売サイトは、自地域のWeb URLで売り、販売主体がDMO等の売上窓口・購入済み一覧を握る点が特徴です。販売主体だけでは車載端末導入がしにくい案件では、見せ券（画面提示）と専用サイトの組み合わせが選ばれます。停留所別ログが必須なら、事業者とQR端末導入をセットでICまたはQR乗車券を正に据えます。
Q2. 紙の1日券はいつまで残しますか？
試運行で問合せ量と検札速度を見て、併用終了日を決めます。高齢者比率が高い路線では、窓口またはコンビニ引換を併用期間に残す判断もあります。
Q3. ロコバス型クラウドとDMOの周遊券サイトはどう使い分けますか？
事業者直販・路線管理が中心ならロコバス（チケット）等の路線向けクラウド、またはRYDE PASS等のMaaSアプリ内。バス＋施設セットの見積も、まず購入画面（MaaSアプリ内か自地域Webか）を決め、運行単位表とあわせて照合します。
Q4. イベント期間だけの臨時バス便はどう扱いますか？
運行日と路線コードをマスタに登録し、券種の有効日を臨時便に合わせます。臨時便だけ別QRにするか、既存1日券に含めるかを事前に決めます。
Q6. 方式ごとの導入・メンテコストの違いは？
交通系ICは端末・清算連携の初期が重く、日常路線ではランニングが見えやすいです。QR乗車券は読取端末×車両台数が初期の中心で、保守・通信が続きます。見せ券は販売側構築が中心ですが、繁忙期の乗務員工数と路線マスタ更新がランニングの主因になりやすいです。見積は初期・月次・当日オペを分けて比較すると列が揃いやすいです。
あわせて読む
- 周遊券のデジタル化｜観光と交通をつなぐ設計 — バス＋施設の周遊拡張・購入画面の型
関連サービス
SmartPlate Ticket
周遊バス向けの自前販売サイトの選択肢のひとつとして、季節運行の周遊バスやバス＋施設・クーポンを同じ販売URLとウォレットで束ねる周遊券向けに、SmartPlate Ticketを見積に並べることがあります。事前購入した券を停留所や車内で画面提示する（またはNFCで利用画面を出す）運用は、ニセコ周遊バス（スカイバス）に近い型です。MaaSアプリ内（RYDE PASS等）と自前販売サイトは、販売窓口・精算・端末導入の分担が異なる——要件表で並べて比較してください。概要はサービスサイトと事例ページで確認できます。
