日本国内のAPI利活用最新トレンドについて、日立製作所様と対談してみた

野崎

まず、弊社F5から見たAPIの最新動向については、先日公開しましたF5の年次ユーザ調査レポート「アプリケーション戦略レポート」からデータを一つご紹介しました。下記にあります通り、特に公開APIについてセキュリティを導入している（予定含め）と回答頂いた率が、世界平均と日本の回答者でかなり違った傾向になったというものになります。

野崎

一目瞭然なのですが、グローバルでは半数近くがAPIセキュリティ導入済み、予定も含めると8割近くです。一方、日本では予定無しと回答した方々が7割、と真逆に近い結果となりました。数字だけで見ると日本のAPIセキュリティの導入が世界平均と比較して遅れているように見えてしまうところですが、例えばこの辺り、日立製作所様が日々お客様とお話しされる中で感じていること、見えていることと比べるといかがでしょうか？

岡井様

弊社のグローバル動向の認識としては、こちらのデータが示す通り、公開APIによるビジネス化進んでおり、APIセキュリティの導入が進んでいる認識です。一方、日本国内動向の認識としては、公開APIによるビジネスをされるお客様は限定的でこれからの状況ではありますが、DXやモダナイゼーションにおいてAPI化を検討するケースはかなり一般的になってきている印象を持っています。
「APIセキュリティの予定がない」については、確かに国内では、公開APIビジネスの延長で必要になるようなセキュリティ対策を明示的には意識されていないお客様も多いですが、我々がコンサルテーションさせて頂いている社内システムのモダナイゼーションのようなケースでも、程度の大小はありながらも認証・認可を全く対応しないでよい、と考えるお客様はあまり多くはない印象です。定義の問題かとは思いますが、API化の延長で何らかの認証や認可の仕組みを取り入れる動きは国内でも比較的あるのではないかと思います。
弊社では公開APIでビジネスをされるお客様、社内システムでAPI連携されるお客様の双方の実績がありますが、社内システムでも、APIセキュリティの対応をした案件は多数実績があります。

野崎

なるほど！失礼しました、それはおっしゃる通りでして、実際弊社の調査プロジェクトでも一応用語の定義はしておりますものの、もしかしたら「APIセキュリティ」の定義として「公開が前提である」という調査です。その意味ではご指摘いただいた通り、我々の調査でカバーしきれなかった文脈として、「API化を進めているものの、その対象となるのが社内に閉じたシステムなどであるがゆえに存在する可能性というのはまさしくその通りかも知れません！

田畑様

弊社から見ると、この「（API公開の）予定がない」と回答いただいた層、というのが今後弊社のターゲットに変わっていくのかな、と感じています。グローバルなAPIの「公開」というところには追いついていない、というのは私から見てもその通りで、国内と比較した時に、グローバルを見ているとセキュリティのインシデントなどにおいても、規模が大きかったり頻度が高い、というのは見受けられますよね。国内でもインシデントは報道されるようになってきていますし、それらがきっかけで弊社に相談が来るようになってきている、というのは感じますね。

飯島

そこで興味深いのですが、先日弊社の NGINX OSSコミュニティイベントにご登壇頂いたご講演内容では、APIゲートウェイの前段にBFF (Backend for Frontend)を配置して、社外に公開する、というアーキテクチャでした。これはまさに「バックエンドのAPIを社外向けの公開する時にBFFを活用して幅広いクライアントに対応するということが主流になるのでしょうか？」

田畑様

BFFを活用するのはあくまで一例ですね。API社外公開のために、既存の社内用のAPIゲートウェイにエンハンスを加えることもありますし、社外公開用のAPIゲートウェイをもう一段設けて多段にする、といった構成もあります。もちろん最初から社外公開用のAPIゲートウェイを構築することもあります。セキュアにAPIを公開する一例として、コミュニティ版NGINXを活用した例を、NGINXユーザー会ではご紹介させていただきました。

野崎

同じ流れで是非お聞きしたいのですが、これらのDX、モダナイゼーションの取り組みを進める中でお客様がお持ちの課題、というのはどのようなものがあるか、日立製作所様の視点から見ますといかがでしょうか？

岡井様

DX、モダナイゼーションの課題は様々かと存じますが、今回トピックに挙がっている認可・認証などのセキュリティを考慮したモダナイゼーションでの困りごとに限定しますと、専門家じゃないと問題ない対応ができているかわからない点ですね。お客様が実現されたい機能要件が実現できているか、問題なくシステムが稼働するかといった部分は、専門家ではない技術者でも確認ができますが、セキュリティに対しては、「一応稼働はできてはいるけれど、上手く作れていない」状態や、「実はこういう穴があるけど気づかずに作ってしまう」状態に陥るケースが多く、専門家が対応しないと危険性が高いです。セキュリティ担保のための標準仕様などもありますが、一つの製品を導入さえすればそれらの仕様をすべて満たす、という事ではなく、標準仕様に準拠するためには専門家の知見が必要になります。それ無しに、そのまま突き進んでしまって、事故に繋がってしまう可能性もあります。API、認証認可、セキュリティは専門家でないと担保できない領域であるとも思っており、この専門性が我々の強みとして対応を進めていきたいと思っています。

野崎

おっしゃる通り、非常に重要なポイントですね！今いただいたまさにそのポイント、「専門性」というところをぜひ深掘りしてお聞きしたいのですが、お客様が感じていらっしゃる日立様のAPIソリューションの強みである専門性、具体的に挙げるとしたら、どのようなところが重点分野になりますでしょうか？

田畑様

例えばですが、APIセキュリティではOAuth2.0やOIDCなどの業界標準の規格がありますよね。これらの領域に従来関わっていない人にとってみれば、これらを実装するだけでも大変な作業となります。OAuth2.0やOIDCは、規格として幅広く規定しているため、抜けているところもあります。となると、「OAuth2.0 / OIDCを実装しています」というだけですと、セキュリティが担保できないのです。実際、これらの規格を実装していたにもかかわらずセキュリティインシデントが起きてしまったケースが複数報道されています。それは何故かというと、これらの規格を「セキュアに実装」していない、というのがポイントなんです。そこで、じゃあセキュアに実装していきましょう、というのは簡単ではなく、それらを専門的な目線からお客様にご提供することが弊社の価値となっていると感じます。
更に、お客様のユースケースを理解し、ユーザビリティとも折り合いをつけて、損なうこと無く、セキュリティを担保したシステムに仕上げていく、というのが我々専門家の価値、と考えています。

野崎

非常に重要なポイントかと思います！それでは貴社の強みとなるのは設計などのフェーズになるのでしょうか？

田畑様

案件によって様々ですが、設計・開発フェーズだけでなく、更に上流工程から参画することもあります。コンサルティング、フィージビリティ確認、PoC（概念検証）、要件定義、などからどのようにお客さまの要件を実現していくか、という段階です。先程の標準規格の例1つとっても、どのようなフローでやり取りをするかが、ネットワーク設計、システム構成に少なからず影響を与えます。それらを早い段階で整理することにより、のちのちの様々なリスクの顕在化を減らす事に繋がる、と考えています。

野崎

単純な設計フェーズのみならず、幅広い上流工程にニーズがあるということですね！なお、松本さん、日々NGINXのビジネスを通してお客様とお話していて、同様の課題や要望を感じる時ってありますかね？

松本

はい、私もNGINX OSSコミュニティイベントにご登壇頂いたお話で、これらの課題に対する日立製作所様の取り組みは学ばせて頂きました。そして、先程お話に出たフローなど含めて、認証はとても複雑です。それゆえ、その複雑さに触れないように、まさに「使うこと」という目的達成するためにSaaSなどの利用するお客様も多い印象です。ただ、例えば金融関係の内部システムなどでは、通信のトランザクションの性質からもセキュリティ的に外部に出せない通信もあります。その場合、フローが内部に閉じた形で作り込むしか無いため、このようなケースでは日立様が強みとされている点はお客様のニーズに強く合致すると考えます。そして、そこをきっちり突き詰めて提供できる、というのも簡単なことではないですから。

野崎

まさしく課題感として、NGINXのビジネスとして見えているところと共通点は多いかな、と感じますね！
では、続いて日立製作所様から見て、弊社のNGINX Plusの強みをお聞きしたいのですが、今回ご採用頂くに至ったポイントなど、何かございますか？

田畑様

はい、やはり、OSSコミュニティイベントの登壇でも少し触れましたが、一番はその「性能」と「カスタマイズ性」と考えています。APIゲートウェイですから、全てのAPIトラフィックが通過するという意味で性能は非常に重要です。またAPIゲートウェイは、APIを呼び出す側と呼ばれる側の双方の要件を吸収するような実装が求められることがあります。NGINXはこの複雑な要件に対してJavaScriptやLuaを使った開発により機能を拡張することで最適な構成を実現することができ、このようなカスタマイズ性を評価いただけるお客様にとってはNGINXが最適な選択肢となります。OSSコミュニティイベントでは、Luaによる開発と外部にRedisを配置したセッション共有の仕組みをご紹介しましたが、NGINX PlusであればRedisを利用せずNGINX Plusが持つKey Valueストアの機能でセッション共有を実現することができますし、更に他のユースケースではNGINX Plusのヘルスチェックの機能が重宝されることもあります。先ほどお話した話にも繋がりますが、高いセキュリティ要件が求められるケースでは、やはりOSS版ではなくサポート対応いただける商用版を求めるお客様もいらっしゃいます。これらのケースでは、NGINX Plusは非常にありがたい選択肢となりますね。

野崎

ありがとうございます。
APIゲートウェイ以外ですと、いかがでしょうか？

田畑様

もはや当たり前となっている多層防御などの要件に対応できる、WAF機能を持つNGINX App Protectに注目しています。NGINX由来の性能とBIG-IP由来の豊富な機能を持つというのがポイントです。さらに、昨今のクラウドのリフト＆シフトを考えると、コンテナ環境でも使える、というのが一番の価値だと考えます。コンテナ移行を将来的にやる時に、都度再設計する必要はなく、そのナレッジを適切に環境に適合できるのがポイントだと感じていますね。

また、Open Source Summit Japan 2021でも公演させていただいたことがあるのですが、Zero Trustのユースケースも注目しています。設定・ナレッジをそのままVMからIngress Controllerへと活用できる、というのがポイントです。さらに、Kubernetes環境では、Ingressだけなく、（さらにきめ細やかに）Per Service、Per Podなどのトラストゾーンに対しても適切に「ゼロトラスト」を実現できる、という点もNGINX Plusのアピールポイントだと感じています。

野崎

ちなみに、ここでいう性能、というのはパフォーマンスのようなものを指しますでしょうか？

田畑様

そうですね、APIでよく要件になるのが、スループットでしょうか。この辺りはNGINXであれば問題になることはないですが（笑）

野崎

なるほど、ありがとうございます！この辺りの強みは弊社としても訴求している価値と合致しているようです、大変ありがたいお言葉、感謝致します！

野崎

これからの展望として、多くの活用事例を期待できる分野はありますでしょうか？

田畑様

そうですね、先程のAPIゲートウェイやBFFなどは、すでに活用事例などもありますし、一番多いかな、と思っております。

野崎

ありがとうございます、やはりそちらの分野が注目ですね！なお、これから更にお客様のAPI実装において外部連携が進む潮流は感じますでしょうか？例えば分かりやすい例で言うと、Fintechのようなプレイヤーと大手の金融機関の間でのAPI外部連携などのような展開は海外では増えているとお聞きしています。このような流れは、今後日本でどのようになっていくか、何か展望があればお聞きしたいと思います。

田畑様

そうですね、その流れの中で、NGINXを扱うことによる弊社ならではの価値を提供できる箇所はあると思います。例えば、Lua拡張は一般的に多くの人が知見を持っているわけではないのですが、弊社はNGINXのLua拡張をAPIゲートウェイとして用いている3scaleへのコントリビュートを行っているため、その知見があります。実際に、例えば高いセキュリティが求められるケースで準拠が推奨されている、2021 年 3 月に最終版が公開された Financial-grade API (FAPI) に準拠するために必要な機能の、3scaleへのコントリビュート実績もあります。このような実例も含めて、NGINXが従来持つカスタマイズ性を活かして、他社に比べて高いレベルでNGINXをカスタマイズ出来ることが弊社の強みだと思います。
更にOSSのIAM製品であるKeycloakにも積極的にコントリビュートし、社内にメンテナーを保有しています。様々なAPIの認証・認可基盤の核となる認可サーバにKeycloakや、商用版のRed Hat Single Sign-Onを活用し、APIゲートウェイにNGINXを活用する、といった連携実績も多くあります。セキュリティを担保するためには、認可サーバのみならず、APIゲートウェイであるNGINXや、APIを呼ぶクライアント含めたシステム全体でセキュリティを担保しなければなりません。認可サーバで培ったノウハウ・知見を活用してNGINXも含めた包括的なセキュリティの担保を実現する、というのも弊社の強みと考えております。FAPIのような規格を代表とする、より高いセキュリティ要件への対応や、コンプライアンス準拠への対応など、まさに現在進行形で相談を複数受けており、今後も増えていくと思います。

松本

ソフトウェアプラットフォーム開発元としての優先順位付けの問題で、F5が認証ソリューションとしてのFAPIにCertified取得はできていません。そこに、日立様というパートナー様がソリューションを提供いただけることは大変ありがたい状況ですね。
FAPIに対応しているだけであれば、ソリューションは出来るかもしれない。実際、FAPIの中のパーツひとつひとつは社内でも対応しているという話題があります。ただ、それをお客様の本番環境で適切なレベルで実装し、提供できるというところが日立様の強みになると思っています。

野崎

これらのFAPI含めた業界標準や要件に柔軟に対応できる、という点は日立様の強みとして捉えて問題ないでしょうかね？

田畑様

もちろんFAPIも一つの強みですし、セキュリティ面を考慮したAPI公開等、高度な技術でセキュアな要件に対しても対応できるのが、弊社の強みと感じております。

野崎

ありがとうございます！本日は長丁場になりましたが、ありがとうございました！
今後とも是非多方面で協業させて頂ければと思います！