予約発券システム開発の完全ガイド

予約発券システムは、外部API型、自社便型、航空会社向けPSSの三つの導入パターンに分けて考えると、必要な機能と導入規模を判断しやすくなります。

各テーマの詳細は、下にまとめた関連記事でご覧いただけます。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

予約発券システムの概要

予約発券システムは、検索画面の先にある注文の流れを受け持つ業務基盤です。在庫や運賃、旅客情報を扱ったうえで、決済から発券、変更・払戻、会計・精算へと処理を渡していきます。必要な技術と費用は自社が担う範囲によって変わるため、まずは導入パターンごとに分けて考えます。

三つの導入パターン

導入パターンによって、在庫や発券の責任範囲が変わり、必要な機能も違ってきます。

外部API型：旅行会社や予約サイトが検索・申込・決済を受け持つ。
自社便型：自社便の座席、運賃、予約変更、払戻の管理。
PSS：航空会社の予約から空港処理、収益会計までを含む基幹業務。

外部API型は小さく始めやすい一方、API条件、返金責任、在庫の更新間隔の確認が必要です。これを怠ると、画面に出ている空席と実際の予約結果がずれてしまいます。

自社便型では、便、座席、運賃、会員、帳票を業務に合わせて管理します。PSSは、付帯サービス、コードシェア、GDS、空港旅客処理との連携を含むことが多く、Web予約サイトとは規模が異なります。

CRS、PSS、PNRなどの用語

予約発券の用語は、それぞれ扱う業務や役割が違います。

CRS：航空便の予約と在庫を扱う。
PSS：出発管理や旅客サービスも含む基幹業務。
PNR：氏名、旅程、連絡先、運賃、座席を結ぶ予約記録。
GDS・NDC・DCS・CUTE：流通基盤、オファー標準、空港管理、共用端末環境。

eチケット、EMD、決済取引、会計仕訳は、それぞれ別の番号で管理されます。そのため、注文ID、PNR、チケット番号、決済ID、返金IDの対応関係を追える設計にしておく必要があります。

用語を曖昧にしたまま見積を依頼すると、予約サイトの費用でPSS刷新を期待するといった認識違いが起きることがあります。

予約発券システムに必要な機能とデータの流れ

処理済みの確認が、再実行時の二重発券防止につながります。

機能は、業務データがどう流れるかに沿って整理します。検索の速さと発券・返金の正確さは、優先度を分けて扱います。

検索・空席・運賃・予約保留の管理

検索と予約保留の段階では、在庫の鮮度と、確定時に起きる競合を管理します。

検索条件：出発地、到着地、日付、人数、搭乗クラス、付帯サービス。
検索負荷：キャッシュ、APIレート制限、在庫期限、Look-to-Book比率。
予約保留：確保時間、期限後の解放、同時予約の排他制御。

検索数は予約成立数を大きく上回ります。そのため、キャッシュの保持時間は、長すぎても短すぎても問題になります。長すぎると売り切れの席を表示し、短すぎると外部API費用と応答負荷が増えます。

決済に失敗したあと、いつ在庫を戻すかを決めておく必要があります。確定時に空席を再照会しないと、販売機会を逃すだけでなく、同じ席を二重に売ってしまうおそれがあります。

決済・発券・変更・払戻の一貫した処理

確定処理、状態管理、再実行の方針を先に決めておくと、二重発券を防げます。

確定処理：空席・運賃確認、予約、決済、発券、通知、会計連携。
状態管理：予約・決済・発券・通知の完了状態を記録。
再実行：注文IDと決済IDで処理済みを確認し、二重発券を防止。

決済は成功したのに発券が失敗した場合の補償処理も、あらかじめ決めておきます。注文の状態を分けて記録しておけば、障害のあとも処理を再実行できます。外部サービスが応答しないときも、タイムアウトだけで失敗と断定しないようにします。

変更・払戻では、航空券、差額、手数料、税、返金先、会計処理の履歴を残します。欠航や乗継失敗が起きたときは、振替、通知、返金の可否、手動での介入も要件に含めます。

販売チャネルと周辺システムとの接続

連携先を洗い出しておくと、通信方式や障害時の対応の抜けを防げます。

販売チャネル：公式サイト、アプリ、コールセンター、旅行会社、GDS、NDC対応先。
周辺システム：決済、会計・精算、顧客管理、メール・SMS、空港管理、手荷物、本人認証、監視基盤。

接続先ごとに、通信方式やデータ項目が異なります。再送方法とメンテナンス時間も、接続先によって違います。そこで、連携の一覧を要件定義の成果物に含めておきます。

IATAは、NDCを、航空会社が商品をオファーとして作成し流通させるためのデータ交換標準と説明しています。

また、ONE Orderは、予約、チケット、付帯サービスを注文中心で参照する方向性です（出典: IATA「Distribution with Offers & Orders」「Fulfilment with Orders」、2026年確認）。

既存のPNRやeチケットをすぐには廃止できない場合でも、Order IDと旧番号を対応付けるデータ設計にしておけば、移行を進めやすくなります。

予約発券システム開発の進め方

開発は、業務境界を定めるところから始まります。販売と在庫、運賃、発券の範囲を先に決めておくと、後の設計がぶれにくくなります。決済や空港との境界、精算と問い合わせの扱いも、同じように決めておきます。

小規模な予約サイトとPSS刷新では工程の重さが異なりますが、例外処理と移行条件を先に決める点は共通しています。

要件定義での業務範囲と負荷の数値化

要件定義では、業務範囲、処理負荷、例外時の役割を具体的に詰めておきます。

業務範囲：顧客、チャネル、便・座席、国・通貨、運賃、会員、決済、連携先。
処理負荷：毎秒検索数、同時予約数、1日あたりの発券数、変更・払戻件数、API呼出数。
例外場面：売り切れ、決済のみ成功、API遅延、欠航振替、運賃改定、時差、端末オフライン。

規模は利用者数よりも、処理負荷や例外の扱いで判断します。そのため、シナリオごとに、自動処理にする範囲と担当者が手動で判断する範囲を関係者で合意しておきます。

パッケージ・クラウド・スクラッチの使い分け

選択肢ごとに、費用、適合性、運用責任が異なります。そのため、自社の業務と照らし合わせて比べます。

パッケージ：標準機能や航空規格への対応を、短期間で利用できる方式。
クラウド：初期投資を抑え、旅客数や検索量に応じて拡張できる方式。
スクラッチ：独自運賃、販売ルール、顧客体験を実現しやすい方式。

パッケージでは、特殊な業務を製品の仕様に合わせる場合があります。その際は、追加開発費、更新費、データの返却、契約終了時の移行負担を確かめておきます。

クラウドでは、従量料金、データの所在、障害時の責任分界、カスタマイズの範囲を、契約で明確にしておきます。

スクラッチでは、税、決済、IATA規格、セキュリティ、障害対応を自社が継続して負担します。そこで、参照系から始めて予約、決済、発券へ段階的に広げると、業務を止めずに適合性を検証できます。

テスト・段階切替・運用設計

テストは、業務例外、基盤、移行の三つの観点で実施します。

業務テスト：在庫競合、保留期限、発券再実行、差額、返金、欠航振替。
基盤テスト：GDS・決済遅延、ピーク負荷、監査ログ、復元、災害復旧。
移行準備：対象データ、進行中予約、一定期間の並行稼働、照合、切替・ロールバック、現場窓口。

受入テストでは、業務担当者が実際の運賃規則と例外を使い、注文IDをたどって会計・精算まで追跡します。移行対象には、予約と顧客、便と座席を含みます。運賃や発券・払戻の履歴、進行中の予約も、対象に入ります。

2026年の旅客サービス統合では、5月19日から6月9日まで空港ごとに段階移行しました。座席指定や予約変更の差異も告知されました（出典: 国内航空会社のシステム移行案内、2026年）。そのため、顧客への事前告知と現場の運用も、計画に含めます。

▶ 詳細はこちら：予約発券システム開発の進め方

ポイント

開発は、業務境界と例外処理、移行条件を先に決めておくと、後の設計がぶれにくくなります。方式は5年TCOと運用責任を同じ基準で比べて選びます。

予約発券システムの費用相場とコストの内訳

業務範囲が広がるほど、想定する金額帯も大きくなります。

費用は画面数よりも、在庫・発券の範囲、連携先の数、ピーク負荷、停止を許容できる時間で変わります。

ここで示す金額は定価ではなく、類似システムと機能範囲をもとにした編集部の推定です。初期費用と運用費は、分けて比べます。

機能範囲別の初期費用と開発期間

機能範囲ごとの初期費用と開発期間を比べると、想定する規模を整理できます。

小規模予約サイト：50万〜300万円、1〜2か月。
中規模システム：300万〜1,500万円、2〜6か月程度。
複数連携・高可用性：1,500万〜5,000万円、6か月〜1年程度。
PSS刷新：5,000万円から数十億円以上になる場合があります。

小規模は、外部航空券API、会員、決済、メール、簡易な管理画面を想定しています。中規模は、自社便の在庫と座席、予約を扱います。そこに決済や発券が加わり、変更・払戻と管理画面まで含みます。

複数連携の範囲には、販売チャネルと会計、会員が含まれます。外部APIや空港周辺システムとの接続、高可用性、データ移行も、この範囲に入ります。また、PSS刷新では、予約、在庫、発券を含む場合があります。DCSとGDS・NDCに加え、国際展開や並行稼働に広がることもあります。

参考として、2026年7月に公示された航空券の政府購入向け清算サブシステムは、予算額280.5万元でした。この案件の範囲は、データ処理、照合、調整、報告が中心で、販売・在庫・発券を含むフルPSSとは異なります（出典: 中国政府調達公告、2026年）。そのため、公開案件の金額をPSS全体へそのまま当てはめることはできません。

従量料金と5年TCOの比較

運用費は課金の単位が項目ごとに分かれているため、利用量も分けて総額を試算します。

運用費：クラウド利用料、監視・保守、外部航空券API・GDS接続料。
取引関連費：決済手数料、SMS・メール費用、旅客数・取引量に応じたPSS利用料。

検索数に応じた課金と発券数に応じた課金が、別々に設定されている場合があります。そのため、月間の検索数、予約成立数、発券数、変更・払戻件数を分けて試算します。

5年TCOは、初期開発・導入費と移行費、並行稼働費を含めて比べます。5年間の固定費と従量費、規格改修・追加開発費、障害対応費も、同じ範囲に入れます。

一般的な業務システムでは、初期開発費の年10〜15％を保守費の目安とする場合があります。航空分野では、規格改定、24時間対応、外部接続、ピーク増強といった要素も加わります。

特に、初期提案の金額が安くても、従量料金や出口費用が高くなる場合があります。取引量が増えたときに適用される単価表も、必ず確認しておきます。

▶ 詳細はこちら：予約発券システム開発の見積相場・費用

ポイント

金額は、自社がどこまでを担うかで大きく変わるため、機能範囲をそろえてから比べます。初期費用だけで判断せず、従量料金と5年TCOを合わせて見ると、稼働後の費用の増え方もつかめます。

予約発券システムの開発会社・サービスの選び方

候補先は、知名度や価格だけでなく、航空業務と高可用性の両方を扱えるかどうかで見ます。

予約サイトの開発会社、航空向けパッケージの提供者、クラウドサービス、連携・移行に強いSIパートナーでは、得意な範囲が異なります。そのため、比較の前に導入パターンを決めておきます。

航空業務・規格・本番運用の実績

候補先の実績は、業務範囲、連携規格、運用規模の三点で確かめます。

業務範囲：予約、在庫、運賃、発券、払戻、空港、会計・精算。
連携規格：NDC、GDS、DCS、決済、会員、税計算。
運用規模：旅客数、国・通貨、販売チャネル、検索・発券量。

「対応可能」という説明に加えて、自社に近い本番稼働の実績を、対象範囲とあわせて示してもらいます。

24時間365日の監視、一次切り分け、目標復旧時間と時点、インシデント連絡、規格更新の責任者についても、確かめておきます。デモでは、正常な予約だけでなく、決済後の発券失敗、返金中の通信断、在庫競合、欠航振替も再現してもらいます。

料金、責任分界、データ返却の契約条件

契約では、課金単位、障害時の責任、データ返却の三点を明確にしておきます。

課金単位：初期費用と月額に加え、検索、予約、発券、変更、払戻、顧客数。
責任分界：提供者、開発会社、決済事業者、航空会社、空港運用者。
出口条件：データ形式、移行支援期間・費用、API終了予告、バックアップ期間。

責任の所在が曖昧だと、予約が成立した後に発券状態を確認できないといった事故が起き、顧客対応が遅れます。さらに、API仕様とデータモデルのほか、予約・チケット履歴や監査ログ、設定値、運賃ルールについても、返却の形式を確かめておきます。

将来の変更に備えて、標準APIと自社の業務データを直接結び付けすぎない構成にしておきます。

RFPの評価表による候補の比較

RFPの評価項目と費用の範囲をそろえて、候補どうしの違いを比べます。

評価軸：機能、非機能、業務適合性、移行、運用、費用、契約。
運用実績：ピーク性能、99.99％などの可用性根拠、復旧訓練、監査、脆弱性対応。
費用範囲：追加開発、移行、テスト、教育、並行稼働、端末、監視、保守。

規格改修の納期、国内の問い合わせ体制、要件変更時の単価も、評価の対象にします。納期が遅れたときの扱い、受入基準、解約と出口条件を比べておくと、予算のずれを抑えやすくなります。

▶ 詳細はこちら：予約発券システム開発でおすすめの開発会社6選と選び方

ポイント

開発会社は、航空業務と本番運用の実績を自社に近い範囲で確かめ、評価表で同じ基準にそろえて比べます。契約では課金単位、責任分界、データ返却を固めておくと、後の食い違いを防げます。

セキュリティと2026年時点の最新動向

決済情報の扱いと操作記録を、複数の対策で支えます。

予約発券システムは、個人情報、旅程、決済、運航・空港業務を扱うため、可用性と機密性の両方を広く見て設計します。設計では、技術名を並べるよりも先に、データを扱う人と、障害時にも続けるべき業務を決めておきます。

カード情報を保持しない設計と監査

決済情報の保護と操作の記録は、設計と運用の両面で整えます。

カード情報：保持を避け、トークン化や決済代行のホスト画面を利用。
アクセス保護：認証・認可、多要素認証、特権操作の承認、最小権限。
情報保護：秘密情報の保管、通信・保存の暗号化、脆弱性診断。
監査：注文、発券、払戻、設定変更のログを改ざんの有無を確認できる形式で一定期間保管。

PCI DSS v4.0.1では、将来日付の要件が2025年3月31日から有効になる移行が示されています（出典: PCI Security Standards Council公式文書、2025年）。また、国土交通省は、航空分野の情報セキュリティ安全ガイドライン第7版を2026年4月30日に改訂しました（出典: 国土交通省、2026年）。

委託先を含めた責任分界、インシデント報告、復旧訓練も、RFPに記載します。

OffersとOrdersへの移行を見据えた将来要件

標準の役割、移行ロードマップ、既存データとの対応関係を、あらかじめ整理しておきます。

NDC：商品・価格をオファーとして流通させる標準。
ONE Order：予約、航空券、付帯サービス、決済、精算を注文中心で扱う考え方。
対応付け：現行PNR、eチケット、EMDと新しいOrderを結ぶ。

IATAの2025年年次レビューは、2026〜2027年に、Ordersと旧システムの間の変換を運用する計画を示しています。注文対応の画面や連携も広がる見込みです（出典: IATA「Annual Review 2025」、2025年公開）。

NDCやONE Orderの採用そのものよりも、返金や会計の単位、現場が参照する番号を先に決めておくことが大切です。

APIゲートウェイで機能を疎結合にし、旧システムとの変換ログを残しておくと、段階的な移行に対応しやすくなります。

ポイント

カード情報を持たない設計と監査ログの保管を、要件に先に入れておきます。OffersとOrdersへの移行では、返金や会計の単位を先に決めることが大切です。

予約発券システムを発注・外注・委託する方法

業務担当者と技術担当者が同じ要件を確認できる状態を作ってから、候補先へ共通の情報を渡します。便数や旅客数だけでなく、ピーク時の検索数や予約・発券数も示すと、見積の前提がそろいます。販売経路と国・通貨を示し、連携先とSLA、移行量も伝えておきます。

RFPに書く取引と例外の条件

RFPでは、業務要件、例外条件、非機能要件、移行要件を分けて記載します。

業務要件：対象業務、利用者、便・座席・運賃、ピーク、決済、発券・払戻。
例外条件：保留時間、タイムアウト、再送、二重発券防止、決済後の発券失敗。
非機能要件：稼働率、応答、接続数、バックアップ、復旧目標、監視、脆弱性対応。
移行要件：旧データ期間、進行中予約、並行稼働、照合、ロールバック、教育、切替体制。

税・手数料と会計、帳票は、具体的な項目として書き出します。言語・通貨や移行範囲も同じように書き、保留時間や稼働率などは数値にします。要件の記載が抜けていると、後から追加費用が発生しやすくなります。

提案比較の責任分界と出口条件

提案は、要件適合、費用、担当範囲、障害対応、終了時の条件で比較します。

提案内容：要件適合、追加開発単価、テスト・移行の担当、補償範囲。
障害対応：発券失敗、二重決済・発券、返金遅延、API停止時の責任。
契約・出口：契約期間、固定費・従量上限、仕様変更、データ返却、移行支援。

一次対応、顧客への連絡、手動での復旧、費用の負担、再発防止は、契約に定めておきます。仕様変更の扱いも確認します。複数年契約の単価上限と、契約終了時の切替期間、データ返却の形式・費用についても、合意しておきます。

▶ 詳細はこちら：予約発券システム開発の発注・外注・委託方法

ポイント

見積を頼む前に、社内で要件の読み方をそろえておきます。例外条件と移行要件まで書いたRFPで候補を比べると、前提の違いによる追加費用を抑えやすくなります。

予約発券システムに関するよくある質問

導入規模は、機能の数だけでなく、在庫・発券の責任、外部サービスへの依存、ピーク負荷、移行対象を合わせて判断します。

予約発券システムの開発費用はいくらですか？

外部API型は50万〜300万円、自社便の中規模システムは300万〜1,500万円が目安です。複数連携・高可用性の業務システムは、1,500万〜5,000万円程度が編集部推定の目安です。

PSS刷新は、5,000万円から数十億円以上になる場合があります。見積では、移行、並行稼働、従量料金、規格改修も含めて考えます。

パッケージとスクラッチ開発はどちらが良いですか？

標準的な予約・在庫・発券を早く導入したい場合は、パッケージやクラウド型が合います。独自運賃、特殊業務、独自のUXを重視する場合は、スクラッチや追加開発が適しています。

パッケージでも移行や連携は個別に設計する必要があり、スクラッチでも規格対応やセキュリティ更新が続きます。そのため、5年TCO、変更の自由度、データ返却、運用体制を同じ基準で比べます。

既存システムを止めずに移行できますか？

可能です。ただし、段階移行、並行稼働、照合、切替条件、ロールバックを、事前に設計しておく必要があります。

進め方には、会員や照会から始めて予約、決済、発券へ広げる方法や、空港・販売チャネル単位で切り替える方法があります。

進行中の予約、変更・払戻、欠航振替、旧チケットの照会は、新旧どちらで扱うかを決めておきます。現場で使う手動の手順も、あわせて準備します。

NDCやONE Orderに今すぐ対応する必要がありますか？

一度に置き換える必要はありません。ただし、新規開発の時点で、将来の対応を妨げないデータ設計にしておくことが必要です。

旧PNR、eチケット、EMD、決済、会計と、新しいOrder IDやオファーを対応付け、APIとイベントログで履歴を追えるようにします。販売チャネル、空港、顧客サポートが参照する番号と責任分界も、先に決めておきます。

まとめ

予約発券システムは、予約と在庫、運賃を扱い、決済や発券、変更・払戻までつなぐ基盤です。さらに、販売や空港、会計・精算とも接続します。二重販売や二重決済を防ぎ、障害や移行の最中も業務を続けられるようにします。

最初に行う対象範囲の分類

外部API型、自社便の予約・発券基盤、航空会社向けPSSでは、在庫管理、発券の責任、連携の範囲、費用が異なります。そのため、対象を分類してから要件と見積を作れば、簡易サイトの予算で基幹刷新を想定してしまう認識違いを防げます。

費用と移行の同時計画

初期費用に加えて、従量料金、保守、規格改修、移行、並行稼働、障害対応を含む5年TCOで比べます。

切替：例外処理と新旧の切替条件を、早い段階で決める。
要件：方式、ピーク負荷、連携先、SLA、移行対象を整理する。
方式比較：パッケージ、クラウド、スクラッチを5年TCOで比べる。

NDC、ONE Order、PCI DSS、航空分野の指針は、データ、責任分界、監査、復旧訓練の設計に反映します。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。