開発スピードをビジネスのスピードに。「新たな価値」をMuleSoftで量産するANAのAPI戦略

Key Takeaways

• 「部分最適」の解消が、新たな顧客価値創出につながる
• レガシー刷新は、「作り直し」ではなく「価値量産への転換」
• API基盤で差が出るのは、機能より「思想と設計思想」
• 大規模変革を前に進めたのは、「ツール＋組織づくり」
• 人材難の壁は、「育成と伴走体制」で乗り越えられる

12年連続でSkytraxの最高評価「5スター」を獲得し、約4200万人のマイレージ会員を擁する全日本空輸（ANA）。

支えるシステムは、長年アップデートを重ねてきたことで複雑に絡み合ったレガシー環境となり、ビジネスのスピードに応えきれないという課題を抱えていました。

その打開策としてANAが選んだのが、システムやデータをAPIで連携させ、管理・活用するための統合プラットフォーム「MuleSoft」です。2022年の第1段階稼働を経て、API再利用率68%、27種類の新サービスをリリースするという迅速な展開を実現。さらにAIエージェントとAPIを組み合わせた次世代の顧客体験構想も進んでいます。

プロジェクトを牽引するデジタル変革室サービスプラットフォーム部の近藤貴仁部長に、変革の舞台裏と今後を語ってもらいました。

密結合のレガシーを解体。ビジネスの変化に俊敏に応える体質へ

──まずは、近藤さんが所属するデジタル変革室サービスプラットフォーム部のミッションを教えてください。

近藤：サービスプラットフォーム部は、Webサイトやモバイルアプリ、コンタクトセンター、SNSなどお客様との接点となるデジタルチャネルからそれらを支えるネットワークやサーバーなどのインフラまで、テクノロジー基盤の開発・運営を管轄する部門です。

現在、私たちが注力しているのは、「MuleSoft」を活用したシステム基盤の刷新です。これは単なるITシステムのリプレースではなく、ANAグループがビジネスの変化に迅速に対応できる体質に変わるための戦略的なプロジェクトと位置づけています。

──MuleSoftの導入以前、どのような課題があったのでしょうか。

ANAのWebサイトは何十年にもわたって機能を積み上げてきた歴史があり、システムが密結合な状態に陥っていました。

ロジックが複雑に絡み合っていたため、「ユーザーインターフェイスを変えたい」「フローを少し変更したい」といった業務部門からの要望に対しても、膨大な時間とコストが必要になっていました。Webの世界はスピードが命。これではお客様のニーズに即座に応えることができません。

加えて、オンプレミス環境で構築していたため、運用・監視の観点でもランニングコストがかさむ課題を抱えていました。

──システム基盤の大規模な刷新に踏み切ったきっかけは何だったのですか。

きっかけは、バックエンドの国内予約システムを国際線のシステムに統合するビッグプロジェクトでした。

裏側の基幹系が変わるのであれば、当然フロントエンドのWebも改修しなければなりません。しかし、単に現在の構成を踏襲すると同じ課題の繰り返しになるのは明白。そこで、この機会を好機と捉えてシステムの構成そのものを根本から見直す決断をしました。

具体的には、画面と裏側の機能を切り離し、画面はCMS上へ配置し、機能についてはAPIとして再利用可能な独立した「部品」に分解して、これらをつなぎ合わせる疎結合な構成へ転換することを狙いました。

そうすれば、予約システムのために作った機能という部品を、モバイルアプリや外部サービスでも自由自在に使い回せるようになります。さらに、インフラをパブリッククラウドへ移行することで、コストの競争力も確保したいと考えました。

2020年度に構想をスタートし、2021年度から本格的な開発へと入りました。

MuleSoftを選んだ3つの理由

──さまざまな選択肢がある中で、システムの「疎結合」基盤としてMuleSoftを選んでいただいた決め手を教えてください。

メジャーなAPIによるシステム統合プラットフォームを複数比較しましたが、どれも実績があり、APIを作って動かすという機能面での大きな差はありませんでした。

決め手は、私たちがもっとも重視していた「ビジネスの価値にどれだけつなげられるか」という思想の部分で、MuleSoftが群を抜いてこの思想に合致していました。

私たちが求めていたのは、単にシステムをつなぐことではなく、作ったAPIがビジネスにどう貢献しているかを可視化し、必要であれば改善すること。そして、素早く作り、動かし、モニターし、価値を高めるというサイクルを高速で回していくことでした。MuleSoftは、この考え方を最初の提案から明確に示してくれました。

そのうえで、秀でていた具体的なポイントが大きく3点あります。

1つは、高度なスキルがなくてもAPIを素早く開発できるローコードの仕組み。もう1つは、再利用性を極限まで高めるAPI主導の接続（API-led connectivity |3階層）の設計思想です。これらが1つのプラットフォームで完結している点は、非常に魅力的でした。

そして3つ目がC4E（Center for Enablement）という推進組織の提案をしてくれたことです（＊）。C4Eとは、再利用可能なAPIやベストプラクティスの整備・公開・活用促進を担う、MuleSoftが提唱する部門横断型のガバナンスの枠組みです。

＊C4E（Center for Enablement）は、IT運用モデルの転換を推進する部門横断型チーム。再利用可能なAPIやテンプレートなどの資産を整備・公開し、事業部門がIT部門に頼ることなく自立的に資産を活用できるよう支援する。名称が似ているCoE（Center of Excellence）は専門知識とノウハウを一元化する点が特徴だが、情報が閉じられやすく、開発者のボトルネックになるという課題を抱えている。C4Eはこの課題を解消するアプローチ。

これまでのWebシステムにおける開発・運用は、ビジネス部門の要望に沿ったアプリケーション作り、正しく動いているかどうかを監視するということに終始しがちでした。

ですが、C4Eでは人がガバナンスを利かせながらAPIの価値を組織的に高め、資産を共有し合う文化を根付かせるための思想が根底にあります。ツールという道具だけでなく、それを使って組織をどう変えるかというフレームワークまで備えていたことが、ANAの変革を託すに足る唯一無二の強みだと感じました。

私は、MuleSoftを単なるツールを導入したという意識ではなく、MuleSoftが描く世界観や思想、文化をツールとともに導入したと思っています。

巨大マイグレーションの舞台裏

──この巨大プロジェクトをどのような計画で進めたのでしょうか。

長年かけて積み上げてきたシステムを新しいプラットフォームに丸ごと移行するわけですから、それだけでもリスクの大きな挑戦です。しかも、スケジュールの制約がある中で、バックエンドの基幹系システムの切り替えと同時に、フロントエンドもリプレースしなければなりません。

私たちにとってMuleSoftを使うのは初めてで、本当にうまく導入できるのかという不安もあったので、開発は二段階に分けて進めました。

第一段階として、2022年に会員系機能や認証系など一部のAPIを先行して稼働させ、プラットフォームとしての基盤を固めました。そのうえで第二段階。国内線・国際線の予約システムやチェックイン機能のAPI化です。

──これほど大規模になると、一筋縄ではいかない場面も多かったのではないでしょうか。

最大の苦労はエンジニアの調達でした。コロナ禍明けでエンジニアが不足していたのに加え、当時はMuleSoftに詳しいエンジニアが国内にまだ少ない状況。私たちの業務に詳しいパートナーはMuleSoftの知見がなく、MuleSoftの知見があるパートナーは航空業務の知識がない。すべてを兼ね備えたパートナーを見つけるのに苦労しました。

そこで、Salesforceの支援を受けながらトレーニングを実施し、グループ会社のANAシステムズにもプロジェクトに参加してもらいました。業務知識を新しいパートナーに共有しながら並走する体制を組み、パートナーの組み替えや大量の人員投入によってなんとか稼働にこぎつけたというのが正直なところです。

──ANAは、Salesforceのサポートサービス「Signature Success Plan for MuleSoft」も国内で初めて採用いただきましたが、こちらを利用いただいた効果もありましたか。

前例のないプロジェクトでしたから、グローバルを含めた支援体制は強力な後ろ盾になりました。

C4Eの組織運営においては、Customer Success ManagerをはじめとするSalesforceのカスタマーサクセスグループが伴走支援してくれていることも大きな力になっています。

──お話しいただいたように、今回、Salesforceの日本法人だけでなくUS本社とも連携をとっていただきました。

一時は品質と進捗のジレンマに陥りましたが、そこを救ってくれたのがSalesforceのUS本社との連携でした。

プロジェクトの途中で、USのメンバーが何度かANA本社に来てくれ、課題をダイレクトに伝えると、必ず持ち帰って対応してくれた。これは非常に心強かったです。

また、私自身がサンフランシスコに出向き、Salesforceが開催する年次カンファレンス「Dreamforce」で現地の開発責任者にANAの状況と想いを直接伝える機会もいただきました。

通常であれば、USと日本には距離があり、ユーザーの声はなかなか届きにくいものですが、MuleSoftはUSからも手厚いサポートをいただき、とてもありがたかったです。稼働直前に性能面での課題が発生した際も、USのエンジニアを含めてスピーディーに対応してもらい、スムーズな稼働につながりました。

API再利用率68%、27の新サービスが誕生

──プロジェクトを振り返って、今どのような成果、手応えを感じていますか。

2024年12月時点で、API再利用率は約68%に達しています。2025年5月には予約系システムの刷新が完了し、現在は搭乗系システムのリプレースに取り組んでいるところです。

再利用率の向上は、そのままビジネススピードの劇的な進化を意味します。かつては新しいサービスを立ち上げるたびに専用のアプリケーションを一から構築していましたが、今はAPIを組み合わせるだけでよくなりました。これにより、すでに27もの新サービスを迅速に展開できました。

航空サービスのみならず、グループ事業への横展開や、チャットボット、モバイルアプリといった他チャネルへの展開も極めてスピーディーです。実際、業務部門からも「以前と比べて開発スピードが格段に早くなった」という声が届いています。

現場のマインドセットも大きく変わりました。正直に言って、導入当初は社内やグループ内に、長年積み上げてきた手法を変えることへの葛藤や、新しいプラットフォームに対する抵抗感も少なからずありました。

しかし、実際に稼働し、その恩恵を肌で感じるようになってからは、現場の空気がポジティブに転じました。「どうすればもっとうまく使いこなせるか」「再利用しやすい設計にするにはどうすべきか」「自分たちのスキルをさらに高めよう」と、前向きな意欲が組織全体に広がっていったのです。

システムを作ることをゴールにするのではなく、「作ったものがいかにビジネスの価値につながるかを全員で追求する」。そうした意識がANAのエンジニア組織に根づき始めていることが、数字以上に大きな成果だと感じています。

──C4Eがあることも導入の決め手だったそうですが、どのように運営しているのでしょうか。

MuleSoftは、Webサイトだけでなくアプリや他のチャネルでもAPIを再利用する前提で設計しています。複数のパートナーが開発に関わるため、自由に作れてしまう環境を放置すると、似たようなAPIが乱立したり、再利用しにくい設計になったりするリスクがあります。価値の高いAPIを維持するには、組織的なガバナンスが欠かせません。

ANAではC4Eリード1名、アーキテクト2名、プラットフォームオーナー2名、アセット管理1名の計6名で組織化しています。社内のプロジェクトが立ち上がる際には必ずC4Eの審査を通す仕組みにしており、似たようなAPIを作っていないか、設計の方針は適切かをチェックし、アドバイスを行う体制です。

ANAとANAシステムズだけでなく、Salesforceのカスタマーサクセスチームにも参加いただき、一緒に協議しながら進めています。

社内向けにはC4Eポータルサイト「SPACE（Service Platform for ANA Customer Experience）」を開設し、設計ガイドラインやベストプラクティスを発信しています。メールマガジンも定期配信しており、各プロジェクトが自走で開発を進められる環境づくりを目指しています。まだこれからの部分もありますが、稼働当初に比べると知見は着実に深まっていると感じます。

AIエージェント×APIで描く新しい顧客体験

──今後の展望をお聞かせください。

お客様のカスタマージャーニー全体を見たとき、今回のプロジェクトでカバーしたのは予約という一場面に過ぎません。しかし、私たちの本当のゴールは、空港での搭乗、機内、そして到着地に至るあらゆるシーンで、お客様に期待以上のサービスを感じていただくことです。

そのためには、予約システムにとどまらず、搭乗システムや機内での接点を支える仕組みにもAPIを広げ、利用可能なAPIを量産していく必要があると考えています。

──2025年11月の「Agentforce World Tour Tokyo」では、AIエージェントとAPIの連携構想を発表されていました。

お客様は「いつでも、どこでも、好きなデバイスで」サービスを受けたいし、ニーズは自然な言葉で伝えたいと考えています。曖昧な要望にも高度な回答を期待されています。こうした声に応えるためには、AIエージェントとAPIの連携が不可欠だと考えています。

具体的には、予約や搭乗、イレギュラー対応といった目的別のAIエージェント群と、それらを統合するAgent Orchestration Layerの構想を描いています。各エージェントはLLMで会話を理解し、MCP（Model Context Protocol）やA2A（Agent to Agent）といったプロトコルを介してAPI基盤と連携します。予約の変更、遅延時のサービス提示、パーソナライズされたオファーなど、お客様のニーズに動的に応える仕組みです。

ただ、お客様のお問合せにお応えするでは足りないと思っています。AIエージェントの裏側にAPIがあるからこそ、即座にお客様の複雑なご要望に応えるアクションにつなげられる。MuleSoftで構築してきたAPI資産が、まさにこのAI時代の基盤になると確信しています。

もう1つ重視しているのが、従業員体験へのAPI活用です。

海外のエアラインでは、係員がスマートフォンを手にお客様のもとへ歩み寄り、搭乗手続きや手荷物の処理をその場で完結させています。日本ほどカウンターに列を作るシーンはあまりみかけません。

こうしたモバイルオペレーションを支えているのもAPIです。従業員が使いやすいツールを整えれば業務効率が上がり、それがお客様の体験にも直結する。お客様向けに作ったAPIは従業員にも使えますし、その逆もまた然り。この循環を加速させていきたいですね。

──MuleSoftには今後どんな期待をしていますか。

MuleSoft自体もAI機能が備わって多機能化しています。私たちの環境を深く理解するパートナーとして、「この基盤を使えば、さらにこんな価値を生み出せる」という一歩先の提案を引き続きいただきたいですね。

また、Salesforceの「Agentforce Service（旧Service Cloud）」や「Agentforce Marketing（旧Marketing Cloud）」などと連携することで、ANAグループにどのようなシナジーが生まれるのか。その可能性を共に広げていければと思っています。

これまでは、巨大プロジェクトを無事に稼働させることが私たちのミッションでした。しかし、本当の勝負はここからです。

デジタル変革室が掲げるビジョンは、「ひとあじ、おせっかい、頼られる存在になる」です。言われたことにプラスアルファを返し、待つだけでなく自ら「こういうことをしませんか」と提案できる組織でありたいと思っています。C4Eの体制、ノウハウ、ツールが整ってきた今、ようやくそれを実現できる環境になってきました。

API基盤の上に、AIエージェントと人の共創を重ねて、お客様にとって最高の体験を創り続けていく。そのためにも、さらにギアを一段上げて、一気に走り始める仕組みを仕掛けたいと考えています。

執筆：野垣映二（ベリーマン）
撮影：北山宏一
取材・編集：木村剛士