航空券流通に数十年ぶりの大きな変革をもたらすとも言われる「NDC(New Distribution Capability)」。NDCをめぐる動きはここ数年加速しつつあり、旅行業界でもNDCへの対応を検討すべき時は近づいているようです。
第1回記事では、「【第1回】航空業界がNDCを策定した狙いとは?」という視点から、航空会社がNDCを導入した狙いを中心にまとめました。第2回目の今回は、それを技術的な視点から見てみたいと思います。旅行会社はどのように対応していけばいいのでしょうか。
インターネット時代の標準技術を採用、リアルタイムに情報交換
まずは、従来のGDSとNDCにおける航空会社と旅行会社間の情報の流れを図示します。
この図のように、現行のGDSの世界では、航空会社はATPCOやSITAを介して情報を配信しなければなりません(図1:①)。これがNDCになると、航空会社のシステムと旅行会社のシステムをダイレクトに接続して、リアルタイムに情報をやり取りするかたちが取れるようになります(図1:②)。
ただしこれは“理屈上の話”であり、現実には旅行会社側から見ると問題も生じます。旅行会社は複数の航空会社と取引を行いますが、システム間をダイレクト接続するならば航空会社1社ごとにそのためのシステム改修を行わなければならず、そこにかかるコストの懸念がつきまといます。
ここで登場するのが「アグリゲーター(図1:③)」です。アグリゲーターは、旅行会社が複数の航空会社と接続する際の“仲介役”として機能し、システム間の接続を一手に引き受けてくれる存在です。そのため旅行会社は、自社システムをアグリゲーターと接続すれば、上述したような懸念が払拭できるわけです。つまり、これまでGDS事業者が果たしてきた役割をNDCの世界で担うのがアグリゲーターであり、NDCを扱えるGDS事業者をGDSアグリゲーターと呼びます。
さて、前回記事でも触れたとおり、NDC環境を導入すれば取り扱える情報の種類が増えます。航空会社ごとに、販売を強化したい路線の運賃を細かく設定したり、新機材をアピールするコンテンツを提供したりして“お得意様”向けの販売強化が可能となるのです。
たとえば航空券の予約クラス(運賃クラス)を見ると、GDSでは最大26種類しか登録できませんでしたが、NDCでは676種類も登録できるようになります。さらに航空券関連の情報だけでなく、各航空会社独自のアンシラリーサービスに関する情報も追加可能です。その際、写真やビデオといったリッチコンテンツも含めて提供できるので、たとえばラウンジサービスの内容やアップグレードシートの広さを具体的、視覚的にアピールできます。
またNDC導入の目的には「インターネット時代への対応」という意味合いもあります。具体的には、インターネット時代の標準的な技術であるXMLやAPIが採用されています。これもそれぞれ簡単に説明しておきましょう。
「XML(Extensible Markup Language)」は、データの「項目名」と「値」を“タグ付け”によって表す書式です。タグ付けとは、どの部分が何の項目の値なのかをコンピューターが読み取れるように「<項目名>値」という形式でテキストを書くことです。
たとえば、航空会社システムが相手のシステムに「予約クラスYの航空券は20000円です」と伝えたい場合は、「<予約クラス>Y<価格>20000」という形のデータを送信すれば間違いなく伝わるわけです(実際の項目名は英語で定義されており、この例はあくまでもイメージです)。
このとき、項目名が双方で一致しないとやり取りは成り立ちませんから、NDCではこの項目名が多数定義されています。もっと言えば航空券の検索から予約/決済/発券といった処理ごとに、問い合わせ(リクエスト)と返答(レスポンス)のそれぞれで必要となる項目を細かく定めています。また、NDCの規定を改訂(バージョンアップ)することで項目名が柔軟に増やせること、つまり将来的な拡張性があることも重要なポイントでしょう。
もうひとつの技術要素が「API(Application Programming Interface)」です。APIは、インターネット経由でアプリケーションがシステムに接続するために用意された接続口であり、いわばシステムの“受付窓口”です。この“窓口”の場所(URL)を知っており、接続が許可されていれば、インターネット経由でどこからでもアクセスできます。そして、接続したシステムがこの窓口に問い合わせれば(決まった形式でデータを送信すれば)、相手側のシステムが自動的に応答してくれる(決まった形式でデータを返信してくれる)という仕組みです。
APIはスマートフォンアプリの開発でよく利用されており、たとえば航空会社が提供するモバイルアプリも、API経由で自社システムにアクセスしデータを取得しています。また企業間のシステム連携に利用されるケースも多く、たとえばLCCの多くは旅行会社と直接契約し、API経由でシステム間をダイレクトに接続しています。NDCは、このLCCの取り組みを業界標準として発展させたものとも言えるでしょう。
XMLとAPIという標準技術、そしてNDCという標準データ規格を採用し、かつGDSなどのアグリゲーターが複数の航空会社との接続をまとめることで、航空会社と旅行会社は個々の相手に合わせて個別にシステムを開発したり、専用回線を用意したりする必要がなくなりました。
さらに、NDCの規格は誰でも入手できるオープンなものであり、現在のWebアプリやモバイルアプリを開発するエンジニアはXMLやAPIに精通していますから、NDCを使った新たなアプリやサービスを開発して市場に新規参入することも容易になります。IATAでは、NDCを使ったアプリの開発を促すためにハッカソン(アプリ開発コンテスト)(図3)などを開催して、新しいアイデアの発掘に取り組んでいます。
NDCの普及はこれからの段階、航空会社の戦略もまちまち
前回、今回とNDCの狙うところ、いわば“理想像”を見てきましたが、それでは現状はどうなっているのでしょうか。
IATAがNDCプロジェクトをスタートさせたのは2012年のことです。その後、数年間をかけて規格策定の作業が行われ、2015年にNDCの最初のバージョンがリリースされました。それ以後も策定作業は続けられており、バージョンアップとともに扱える情報を段階的に拡張しています。
2016年6月からは、IATAによる「NDC Certification(NDC認証)」という技術認証制度もスタートしています。(図4) これは、航空会社が提供するNDCのAPIと、そのAPIを利用する旅行会社やアグリゲーターが、正しく規格に準拠していて他社と問題なく接続できる状態にあることを保証するものです。
そして取得するNDC認証には、実施可能な機能ごとに3つのレベルが用意されており、NDC規格の一部(アンシラリーサービスなど)のみ対応のレベル1、航空券の検索部分のみ対応のレベル2、規格全体(検索と予約/決済/発券、その他サービス)に対応するレベル3と分かれています。(図5)
それでは現在、どのくらいの航空会社がNDCに対応済みなのでしょうか。IATAのサイト(NDC Registry)で調べると、NDCに対応する航空会社は世界で62社でした(本項執筆時点)。レベル1が7社、レベル2が5社、レベル3が48社という内訳です。
2016年のNDC認証開始時点では18社だったので、2年間で3.5倍ほどには増えているものの、IATA加盟航空会社の290社と比べると2割ほどの数です。また、現在のところ日本の航空会社はこのリストに見当たりません。普及はまだこれから、というのが率直なところでしょう。
また、NDCをどうビジネス戦略に組み込んで行くのかも各社各様です。NDCを起爆剤として航空券販売の利益率を高めようとしている航空会社もあれば、航空券は従来どおりGDS経由で扱いつつ、アンシラリーサービス販売の部分でNDCを活用したい航空会社もあります。もちろん様子見の会社も多くあり、各社の戦略はNDCの普及とともに変化していくことになります。
現状では航空会社側の動きが明確ではありませんから、旅行会社側としても当然慎重にならざるを得ないでしょう。将来的にNDC規格そのものの普及が進むのは間違いないにしても、「それが旅行会社のビジネスにどう影響を与えるのか」「どんなメリットがあるのか」が見えていないのは事実です。
“NDC黎明期”とも言える現状においては、最初の一歩を踏み出すことも肝要ですが失敗したくはありません。そうなると、まずは航空会社と旅行会社の間で長年“仲介役”を務めてきた実績を持つGDSアグリゲーターをチョイスしておくのも手だと言えます。
次回は、NDCをめぐる具体的な航空/旅行業界内の動きにもさらに踏み込みながら、旅行会社がこれからどう取り組んでいくのがベストなのかを考えてみたいと思います。