予約発券システムの発注は、業務範囲と例外処理を定め、要件と責任分界をRFPと契約に落とし込むことから始まります。提案を比べたあとにテストと段階移行を進めると、追加開発や業務停止のリスクを抑えられます。
発注は、対象範囲の決定、発注形態と契約の選択、費用の見積、委託先の比較の順に進みます。
▼全体ガイドの記事
・予約発券システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
予約発券システムの発注前に押さえる全体像
予約発券システムには、検索画面や予約データベース以外にも多くの業務が関わります。航空会社や空港では、販売、在庫、運賃の管理と予約記録、発券が関係します。さらに、決済、変更・払戻、空港業務、会計・精算まで含まれます。
対象範囲を分けずに見積を取ると、簡易なWeb予約と大規模なPSSを同じ条件で比べることになります。発注側は、発注前に対象業務を定めておかないと、後から追加開発が発生しやすくなります。
予約サイト・業務システム・PSSの分け方
発注範囲は、三層のうちどれを対象にするかで決まります。
- 予約サイト：旅行会社や宿泊・交通事業者が、航空券APIで検索・予約・決済を提供する形です。
- 業務システム：自社便や自社サービスの在庫、座席、会員、変更、払戻を管理する部分。
- 航空会社向けPSS：予約・在庫・運賃・発券、販売チャネル、GDS・NDC・DCS、会計・精算を扱います。
自社で便在庫や航空券を持たず、API事業者から空席と運賃を受け取る場合は、画面、会員、決済、通知、管理画面が主な範囲になります。
各層で可用性、規格対応、移行の難しさが異なるため、発注側はRFPの表紙に対象層を記載します。
検索から発券・払戻までのデータの流れ
基本の業務は、検索や空席照会から始まり、運賃計算、予約保留、決済、発券を経て、変更・払戻、搭乗・精算へ進みます。発注時は、各工程の識別情報と例外時の処理を揃えておきます。
- PNR（予約番号）、チケット番号、決済取引ID、注文IDを相互に追跡できる状態。
- 決済後に発券できない場合やGDSがタイムアウトした場合の補償処理の決定。
- 同じリクエストの再送時に起きる二重発券と二重請求の防止。
検索数は予約成立数より多いため、ピーク時の検索数、予約成立数、発券数を分けて把握しておきます。そのうえで、各数値をキャッシュ、レート制限、API課金の前提に反映します。
標準機能・外部サービス・個別開発の境界
機能の調達方法を分けると、費用と運用責任を並べて比べられます。
- 標準機能：PSSやクラウドサービスの既製機能を購入して使う。
- 外部サービス：決済代行、航空券API、メール配信などに任せる範囲。
- 個別開発：独自の販売ルールや顧客体験に合わせて作る部分。
パッケージは導入実績や規格対応を活用しやすい一方で、業務のほうを製品仕様に合わせる必要があります。
スクラッチは独自運賃や画面に対応しやすい点が強みです。その分、税制、決済、IATA規格、脆弱性、障害対応を自社と委託先で継続して担うことになります。
比較するときは、初期費用に加えて5年間の変更費と、終了時のデータ返却条件も確認します。機能ごとに適した方法を組み合わせれば、すべてを一から作る必要はありません。
予約発券システムの発注・外注の進め方
外注では、要件を委託先に丸投げせず、業務の境界とリスクを先に揃えておきます。次に提案を比べ、設計、開発、テスト、移行を段階的に管理します。
航空業務には、欠航、空席待ち、乗継失敗、再発券、返金、決済後の発券失敗といった例外があります。そのため、例外処理は後回しにせず、発注の初期から要件に入れておきます。
発注形態の選び方（パッケージ・クラウド・スクラッチ）
発注形態は、既存PSSや予約パッケージ、クラウドサービスやモジュールの組み合わせ、スクラッチ開発の三つに分けられます。業務の特性と導入時期を踏まえ、候補を絞り込みます。
- パッケージ：国際線や複数チャネルを短期で導入する場合の候補。
- クラウド・API：LCCの付帯サービス販売やデジタルチャネルに向いています。
- スクラッチ：独自業務が多い場合に適する反面、段階移行の検討が欠かせません。
全面刷新を避け、会員や照会などの参照系から始めて、予約、決済、発券の順に移行すれば、停止リスクを抑えやすくなります。また、委託先には機能だけでなく、変更できる範囲と変更費用も尋ねます。
NDCは、航空会社の商品やオファーを販売チャネルへ届ける考え方です。一方で、ONE Orderは予約・発券・精算を注文中心へ統合する方向性です。
IATAのNDC説明と2025年の年次レビューを踏まえ、新旧のPNR、eチケット、EMDと将来のOrderの対応を検討します。そのうえで、委託先には、対応表、APIのバージョン管理、終了時の移行方法を求めます。
RFPに示す利用規模・連携・例外処理
利用者数だけで性能や料金を見積もるのは難しいため、利用規模と接続先を具体化します。
- 規模：便数・機材数・座席数、1日あたりの検索数・予約成立数・発券数、同時接続数。
- 販売・連携：Web、アプリ、コールセンター、旅行会社、GDS、NDC。
- 業務条件：国・通貨・タイムゾーン、税・手数料、決済ブランド、会員ランク。
- 運航・空港連携：コードシェア、インターライン、チェックイン、手荷物タグ。
検索数が予約の何倍になるか、繁忙期にどの時間帯へ集中するかも示します。欠航振替、空席待ち、保留のタイムアウト、決済取消を要件に含めます。また、発券失敗、部分払戻、旅程変更、注文再送も対象にします。
各要件は「必須」「初期リリースで必要」「将来対応」に分け、受入条件は一文で書きます。たとえば、決済後に発券が失敗した場合は、二重請求せず取引IDから再処理できることを条件にします。
業務担当者による要件定義と業務の固め方
システム担当者に加えて、予約センターや空港カウンター、発券・精算の担当者を参加させます。さらに、経理と顧客サポート、情報セキュリティの担当者も加えます。
画面一覧を作る前に、予約の流れを業務フローとして描き、例外時の担当者と承認方法を、証跡や復旧手順とあわせて書き込みます。
- 業務ルール：予約保留時間、キャンセル料、税明細、発券後の変更可否。
- 例外時の運用：担当者、承認、証跡、復旧手順。
- 標準機能との境界：変更できない業務と変更可能な業務。
成果物は、機能一覧に業務フローを加えて揃えます。例外・外部連携一覧やデータ定義、権限表も含めます。さらに、非機能要件、移行対象、受入条件まで含めます。
24時間365日の運用では、目標復旧時間と目標復旧時点、監視通知、障害連絡の順番、ベンダーの対応時間を明記しておきます。要件定義を省けば、その分の手間が本番後の改修費や現場の負担に回ります。
設計・開発・テスト・段階移行の契約上の工程
設計では、予約から通知までの各機能の責任境界を決めます。そのうえで、PNR、チケット番号、注文IDの対応を定めておきます。開発では、正常系に加えて、遅延、再送、同時予約、タイムアウト、返金、障害復旧にも対応して実装します。
テストは、機能、連携、負荷、セキュリティ、運用リハーサル、現場受入に分けて進めます。合格基準と再テストの費用負担は、契約書や個別契約で定めておきます。
- 段階切替：会員や参照系の機能から順に切り替える進め方。
- 対象限定：チャネル、空港、路線を絞って先行させる進め方。
- 並行稼働：旧・新システムを一定期間同時に動かす進め方。
たとえばANAは、2026年5月19日から6月9日まで、空港ごとに国内線と国際線の旅客サービスシステムを統合すると案内しました。移行前後の空港では、座席指定や予約変更などに差異が生じます（出典：ANA「システム移行期間のサービス制限について」、2026年）。
切替日は、販売、空港、顧客サポートの各部門へ周知し、利用者向けの代替手順も用意します。移行準備は技術チームだけで進めず、現場の部門も巻き込みます。
予約発券システムの契約形態と責任分界の決め方
契約では、成果物、検収、仕様変更、品質保証、運用責任、データの扱いを一体で確認します。不確実性の程度に応じて、フェーズごとの契約も検討します。
要件が未確定のまま全工程を固定価格にすると、変更が追加費用になりやすくなります。また、準委任で進める場合も、予算や完成条件が曖昧になりやすいため、契約範囲を明確にします。
請負契約の使いどころ：成果物と検収条件が明確な範囲
請負契約は、合意した成果物を完成させて検収を受ける範囲に向いています。仕様と受入条件を客観的に書ける機能から適用します。
- 仕様：画面・API・移行・テストの仕様が固まった範囲。
- 検収：納品物、検収期間、軽微な不具合、重大障害の是正期限。
- 変更・遅延：仕様変更の見積方法、第三者サービス遅延時の扱い。
- 契約範囲：負荷テスト・障害訓練の検収可否、移行リハーサルの回数。
航空会社や決済会社の仕様、業務ルール、移行データの品質は変わりやすい要素です。そのため、要件定義と基本設計を別フェーズに分ける方法も現実的です。
完成条件は稼働だけに置かず、二重発券の防止、正しい払戻額、監査ログでの追跡を受入条件に含めます。
準委任契約の使いどころ：要件定義や伴走型の開発管理
準委任契約は、専門家の稼働や業務遂行を依頼する形態です。要件定義、現行調査、ベンダー調整、アジャイル開発、移行支援、運用設計が主な使いどころです。
優先順位を柔軟に変えられる反面、成果物の完成を自動的に保証するものではありません。そのため、発注側は責任者を置き、優先順位と作業時間、担当者を管理します。さらに、レビュー頻度と成果物も確認します。
- 体制：参加者と航空業務の有識者の人数。
- 継続性：休暇・交代時の引き継ぎ方法。
- 進捗管理：月次報告と成果の評価方法。
- 予算管理：フェーズごとの上限と中止条件。
月額の総額とあわせて、誰が何時間参加するかを確認します。発注側の担当者がレビュー時間を確保し、機能、課題、リスク、次月計画の四つの観点で毎月の成果を評価します。
責任分界・SLA・出口条件の契約項目
障害対応は、開発会社、PSS、航空券API・GDSの間で分担します。決済代行、クラウド、空港機器などとの分担も含めます。そのうえで、検知、一次切り分け、顧客案内の承認者を責任分界表に記します。
- SLA：稼働率、重大障害の検知・一次回答時間、復旧目標、データ復旧点。
- 連絡・停止：休日夜間の連絡方法、計画停止の通知期限。
- 出口条件：API・データ辞書、利用権、ログ形式、返却と移行支援。
外部サービスの終了や料金体系の変更に備えて、代替策も確認しておきます。データ返却や移行支援を契約に含めれば、ベンダーロックインを抑えられます。
予約発券システムの費用相場と5年TCOの考え方
予約サイトでは数十万〜数百万円、自社在庫や発券を含む業務システムでは数百万円〜数千万円です。航空会社向けのPSS刷新になると、数千万円〜数十億円以上まで幅が広がります。
ここに挙げる金額は、機能範囲、連携数、可用性、移行対象を前提にした2026年時点の見積の目安です。公開価格表の値ではなく、旅客数や検索量によって変わります。国際線や多通貨への対応によっても変わります。既存データの量、24時間運用、外部課金も関わります。
機能範囲別の初期費用と開発期間
範囲別の初期費用と期間は、見積を比べる際の基準になります。金額だけでなく、在庫、発券、払戻、移行の責任も確認します。
- API予約サイト：50万〜300万円、期間は1〜2か月が目安。
- 中規模システム：300万〜1,500万円、期間は2〜6か月程度。
- 複数チャネル等：1,500万〜5,000万円、期間は6か月〜1年程度の場合があります。
- PSS刷新：5,000万円〜数十億円以上、期間は1年以上になりやすいです。
API予約サイトの範囲例は、予約フォーム、会員、決済、メール、簡易管理画面です。一方、中規模では自社便の在庫、座席、予約変更、払戻、会計連携、発券を含みます。
複数チャネル等の見積には、コードシェア、外部API、空港連携、高可用性、移行が影響します。PSS刷新では、DCS、GDS・NDC、精算、複数国展開も含みます。
簡易予約サイトは自社で在庫を持たない前提のため、発券や障害時の補償を外部に依存します。このため、見積は機能名だけでなく、各業務の責任を並べて比べます。
クラウド・API・決済・保守のランニング費
ランニング費は、固定費と利用量に応じて変わる費用に分けて考えます。契約時には、費目ごとの金額と課金単位を確認します。
- 基盤：クラウド、DB、バックアップ、監視、ログ保管。
- 外部利用：航空券API・GDS接続、決済手数料、メール・SMS配信。
- 維持管理：保守、セキュリティ診断、規格更新、障害対応、追加開発。
検索数、予約数、発券数、旅客数を基準とする従量料金もあります。たとえば、検索が多く予約が少ない事業では、検索リクエストの課金単位とキャッシュ条件を確認します。
一般的な業務システムでは、初期開発費の年10〜15％を保守費の目安に置くことがあります。ただし、航空業務では規則や外部規格、OS、脆弱性、決済仕様の更新があるため、この割合では足りない場合があります。
見積を依頼する際は、月額固定費、従量費、規格更新、障害対応、追加開発、移行リハーサルを別行にして出してもらいます。
5年TCOによる見積の比較
5年TCOには、初期費用に加えて、移行、並行稼働、クラウド、外部利用、保守の費用が含まれます。さらに、規格対応、追加開発、障害訓練の費用も含めます。このように費目が多いため、提案は長期の費用で比べます。
たとえば、初期2,000万円、月額固定費80万円、月の従量費40万円、年保守費300万円の場合、初期費用と年保守費を除いた月額固定費と従量費の5年間の合計は約7,200万円です。これは一例で、取引量や契約条件によって変わります。
- 利用量シナリオ：通常月、繁忙月、障害復旧月の3パターン。
- 別料金の確認：移行、環境追加、テスト環境、深夜対応、データ返却。
- 前提の確認：空欄を契約前の質問票で埋める。
候補会社には、共通の利用量シナリオで5年TCOを出してもらいます。初期費用が安い提案でも別料金が多ければ実質の差は縮まるため、前提を安易に補わず確認します。
委託先選定と見積比較で確認すべきポイント
委託先は、知名度や総額に加えて、航空業務、24時間運用、複数ベンダーの調整に対応できるかで選びます。会社の順位より、対象の規模と役割に合っているかを見ます。
Amadeus、Navitaire、Sabre、IBS Softwareは予約・発券や航空流通の候補です。また、SITAなら空港・旅客処理などの連携を、NECなど国内SIerなら国内業務、空港導線、移行、運用支援を確認します。
航空予約・発券と高可用性の実績
会社案内に載る導入社数だけでなく、航空業務の担当範囲と運用実績を確認します。提案会には、プロジェクトマネージャー、航空業務の有識者、アーキテクト、移行・運用責任者など、営業以外の責任者も同席させ、障害時の対応力を見ます。
- 案件範囲：予約・在庫・運賃・発券・払戻、GDS・NDC・DCS、決済。
- 稼働実績：ピーク量、障害と復旧、移行規模、並行稼働期間。
- 運用支援：現場教育と担当者の役割。
金融やECの高トラフィック実績も参考になりますが、航空特有の運賃規則や搭乗前後の例外対応の経験とは別に見る必要があります。なお、実績は匿名化した範囲で提示してもらいます。
決済後に発券APIがタイムアウトした場面の復旧手順を尋ねます。誰が何を確認し、どの画面で再処理し、いつ顧客へ連絡するかを説明してもらいます。製品機能の説明だけで、業務の復旧や責任分界に触れない回答には注意します。
見積の機能・前提・除外事項の比べ方
合計額を比べる前に、WBSの項目と粒度を揃えておきます。そのうえで、作業内容、工数、担当者、成果物を項目ごとに確認します。さらに、期間、前提、除外事項、追加単価も見ておきます。
- 工程：要件定義・設計、開発・連携、テスト・移行、教育・運用設計・保守。
- 別途費用：外部接続、データ整備、本番立会いなどの注記。
- 評価項目：価格、適合度、航空実績、移行・運用、セキュリティ、契約。
評価表には、提案の透明性に関する項目も含めます。配点の一例は、価格20点、機能適合25点、非機能15点、移行15点です。残りは、体制10点、セキュリティ10点、出口条件5点です。
失敗時の影響が大きい項目には、配点を厚くします。さらに、最低合格点を設けておくと、最安でも必須要件を満たさない提案を候補から外せます。
セキュリティ・運用・法令対応の必須条件
個人情報や決済情報を扱ううえに、航空の重要インフラに関係する可能性があります。そこで、セキュリティと運用の条件をRFPに含め、委託先の責任範囲を確認します。
- 情報保護：カードのトークン化、権限分離、多要素認証、暗号化。
- 監視・復旧：監査ログ、脆弱性診断、バックアップ、災害復旧。
- 委託管理：サプライチェーンと再委託先の管理。
PCI Security Standards Councilの文書ライブラリには、2024年6月公開のPCI DSS v4.0.1が掲載されています（出典：PCI Security Standards Council、2024年）。決済代行を使う場合も、カード情報に触れない構成と、その責任範囲を確認します。
国土交通省は2026年4月30日に「航空分野における情報セキュリティ確保に係る安全ガイドライン」を第7版に改定しました。第7版は、重要システムの早期検知、迅速な復旧、供給網のレジリエンスを示しています（出典：国土交通省、同ガイドライン第7版、2026年）。
そのため、開発工程だけでなく、運用後の監視、事故報告、脆弱性修正、再委託先の管理もRFPと契約に含めます。
よくある質問
発注時は、利用規模と業務範囲を分けて考え、初期費用に加えて外部サービス、移行、運用、セキュリティの条件まで確認します。
予約発券システムの開発費用はいくらですか？
API予約サイトは50万〜300万円、自社便の在庫・予約・発券を含む中規模システムは300万〜1,500万円が目安です。複数チャネルや高可用性を含む業務システムは1,500万〜5,000万円です。
航空会社向けPSS刷新は、5,000万円から数十億円以上まで幅があります。いずれも公開定価ではなく、機能、連携、利用量、移行、SLAを前提にした概算です。
パッケージとスクラッチ開発はどちらを選べばよいですか？
標準機能を早く導入し、規格対応や運用実績を重視するならパッケージが向いています。一方、独自運賃、販売ルール、顧客体験を中核にする場合は、スクラッチが候補になります。
スクラッチでは、規格更新、セキュリティ、障害対応、移行を継続して担う必要があります。また、標準機能を購入し、独自部分をAPIや個別開発で補う方法もあります。
RFPには何を書けば見積の精度が上がりますか？
便数や座席数、検索・予約・発券のピーク量を記載します。販売チャネルや国・通貨も示しておきます。さらに、外部連携、機能範囲、SLAを書き添えます。復旧目標、移行データ量、希望時期も含めます。
欠航振替、空席待ち、再発券、部分払戻、決済後の発券失敗などの例外と、その受入条件も示します。また、必須機能と将来対応を分けたうえで、見積の前提と除外事項を同じ様式で出してもらいます。
決済情報や個人情報の安全性はどのように確認しますか？
カード情報を自社で保存、処理、通過させるかどうかを、データフローで確認します。可能であれば、決済代行のトークン化を利用します。
PCI DSS v4.0.1への対応範囲、権限、多要素認証、暗号化を確認します。加えて、ログ、脆弱性診断、事故対応、再委託先も確認します。航空分野の安全ガイドラインに沿う復旧体制と代替運用も要件にします。
まとめ
発注では、対象を予約サイト、自社業務システム、航空会社向けPSSに分けて考えます。そのうえで、予約、在庫、運賃、発券、決済の範囲を明らかにし、さらに変更、払戻、空港、精算まで確かめます。
ピーク量、チャネル、連携、SLA、移行をRFPに記載します。また、発注形態は、変更費用、規格対応、ロックイン、終了時の条件まで比べて選びます。
発注前に確認する五つのポイント
発注前は、まず業務範囲と例外処理を固め、次に検索・予約・発券のピーク量を見積の前提として示します。
そのうえで、標準機能と個別開発の境界を決め、5年TCOと従量課金を比べます。責任分界、SLA、移行、データ返却も、契約前に確認します。
- 業務範囲：例外処理と責任者。
- 利用規模：検索・予約・発券のピーク量。
- 開発境界：標準機能と個別開発。
- 費用：5年TCOと従量課金。
- 契約：SLA、移行、データ返却。
要件定義やテストを削る代わりに、段階導入と優先順位付けで初期リスクを抑えます。候補会社には、障害や移行のシナリオへの対応を説明してもらい、航空業務と運用の両方を理解しているかを確かめます。
小規模開始でも見据える将来の発券・移行
小規模で始める場合も、将来の発券や移行を見据えて次の点を決めておきます。
- 小規模な予約サイトでも、注文ID、PNR、チケット番号、決済取引IDの追跡。
- 変更、払戻、会計、空港連携へ広げられる境界の設計。
- PSS刷新での段階切替、並行稼働、照合、ロールバックの計画。
- 発注側と委託先で、費用・品質・リスクを同じ指標で管理すること。
業務上の成功条件を言語化して共有すれば、予約発券システムの外注を、事業継続の基盤づくりにつなげられます。
▼全体ガイドの記事
・予約発券システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。