Mobile Boarding Pass

世界的に大きな騒動になっている、PHPの脆弱性とその対応ですが、OpenAIのAIモデルが発見したとのこと。余りに突然な大きな修正騒動だったので、多分AI関係なんだろうなぁと思っていましたが、正直自分でサーバーとか運用してPHPを動かしているわけでは無いので、その程度の危機感というか、ちょっと他人事でした。

ところがやはり世の中は繋がっているなと感じたのが昨晩。今日はこれから国内線に搭乗して、ちょっと遊びに出掛けるのですが、そのモバイル搭乗券を昨晩チェックインをして発見していました。往路のHND-CTSは問題無く処理されたんですが、復路のCTS-HNDに関しては、チェックインは出来たけれどモバイル搭乗券を発行しようと画面をタップしても「ただいま処理出来ません」みたいなメッセージが表示されて進みません。直前まで往路の処理はちゃんと完了したのに、何故か復路は駄目。ANAアプリを一度終了してリトライしてみても駄目。これでは、北海道から帰れなくなってしまうので(嘘)、モバイル搭乗券ではなくメールで搭乗券を自分のアドレスへ送信しておきました。こちらは往復ともに問題無く処理されて、無事にそれぞれのQRコードは入手出来ました。

ここで気がついたんですが、メールで送られてきたモバイル搭乗券(QRコード)には、ちゃんとAMCの会員レベル(=AMC Diamond)、ラウンジ指定(=Suite Lounge)、そしてFFPのアカウント(=UA MP#)がちゃんと記録されています。でも、Apple Walletへ登録したモバイル搭乗券だと、毎回ラウンジ入口で弾かれて(スタアラゴールドに判定される)居るのは何故だろうか。確かに、Apple Walletに登録したモバイル搭乗券には「UA*G」としか表示されていなくて、その情報しかQRコードには含まれていないのかと思っていましたが、ちゃんとANAのFFP情報も、当日利用するFFPのアカウント情報も元データには登録されていることになります。国内線予約システムが変更される前は、同様の場合でもちゃんとAMC Diamondとして処理されていたのに、すでに変更されていた国際線の搭乗券の時は、やはり毎回確認が必要だったので、予約システムのデータの持ち方の問題何だろうなぁ。 

で、今朝になるとANAからDMが幾つも届いていて、その内容は今回のPHPの脆弱性対応の為、ANAウェブサイト、ANAアプリでのApple Wallet機能を用いた搭乗券発行を一時停止するというもの。

「えっ?」という感じ何ですよね。しかも不思議な事に「Apple Walletに登録」と書かれている。じゃぁAndroidなら発見できるのかと思い、モト君でANAアプリを起動してモバイル搭乗券を発行してみたら、こちらはちゃんと発券されて表示することが出来ました。そこで今日試してみようと思ったのが、

1. 羽田でのラウンジアクセス時に、メールでくられてきたQRコードを試して、Apple WalletのQRコードの時と同じか、そのまま問題無く通過出来るか確認
2. 千歳でのラウンジアクセス時に、AndroidでANAアプリを起動してモバイル搭乗券を表示させ、そのQRコードでどうなるか確認

もしいずれかの方法ならすんなり入室出来るなら、今後は(来年は、か)モバイル搭乗券をその方法で利用することで、入室チェック時のプチストレスが軽減できそうです。さて、結果は...