API GatewayのKongのプリンシパルエンジニアにインタビュー。Backstageと差別化するScorecardsとは？

マイクロサービスによって構成されるクラウドネイティブなシステムにおいて、コンテナ化とそれをオーケストレーションするKubernetesが注目され、実際に多くのシステムがそのプラットフォームの上で稼働している。そのようなシステムにおいて、外部のサービスやマイクロサービス同士を繋ぐ方法はAPIをコールすることだ。個々のサービスをメッシュ状に繋ぐのではなくゲートウェイを介することで、アプリケーションはキャッシュの使用や高いセキュリティを担保できる。そのパイオニアのひとつと言えるのがKongだ。KongはNGINXを使ってAPI Gatewayを作り、その後、Envoyを使ってサービスメッシュを作った。パイオニアのひとつでもあるApigeeがGoogleに買収され、AWSなどが各々のAPI Gatewayを用意した後も独立した企業として奮闘していると言える。

そのKongのエンジニアであるJohn Harris氏が本社から来日、インタビューに応えてもらった。Harris氏はO'Reilly社から出ている技術書籍「Production Kubernetes」の共著者でもある。

インタビューに応えるJohn Harris氏

Kongについては創業者兼CEOのAugusto Marietti氏にインタビューを行っているので参考にされたい。

●参考：API管理を手がけるMashapeのCEO「来年には日本法人を立ち上げる」と語る

最初に自己紹介をお願いします。

Harris：私は、Kongのエンジニアリングチームの一員としてプロダクトに関するさまざまな活動をしています。例えば顧客と一緒にPoCをやったり、顧客のニーズを聞き取ったりということなどですね。Kongに入る前はDockerで働いた後にKubernetesを作ったエンジニアが創業したHeptioで働いていました。その後、HeptioがVMwareに買収された後にKongに移ったという経緯ですね。最近では、話題になっているMCPサーバーについての解説を顧客向けに行ったりもしています。

最近のVMware/Broadcomはあまり褒められた仕事をしていないようですが、それは貴方のせいではないということですね？（笑）

Harris：VMwareがBroadcomに買収されたのが2023年、私がVMwareを退社したのが2021年ですから私のせいではないと言えます（笑）。

かつて私がKongのCEOにインタビューした時にとても驚き感心したことのひとつはKongの価格体系でした。それはAPIコールの数でもデータサイズでもなく管理者IDの数で課金を行うという今から思えば独創的なもので、システム管理を行う部門にとっては非常に明快でシステムをフルに使える画期的な発想でした。デベロッパーがAPI Gatewayを使う時にどれだけのコールを行うのか、データサイズがどのくらいになるのかを開発する時点で想定するのは困難で、その結果予想外のコスト増に悩まされるというのは当時よく聞いた話でしたから。それは今では変わってしまったということですよね？

Harris：そうですね。現在はAPI Gatewayだけではなくサービスメッシュやサーバーレス、デベロッパー向けのツールなどにプロダクトのポートフォリオが拡大しているので、価格もそのプロダクトに性質に合ったものが採用されています。KongのプロダクトはAPI Gateway、AI Gateway、Kafkaで利用するEvent Gateway、Envoyを使ったサービスメッシュなどをランタイムと区分し、開発を行うためのツールやデベロッパーポータルなどが別に存在します。InsomniaやDeveloper Portal。Scorecardsなどがプロダクトの例ですね。InsomniaはAPIを開発するためのツールですが、これからはもっとランタイムのプロダクトと密に連携していくようになると思います。

MCPの話が出ましたが、Kongとしては生成AIにはどう取り組んでいるんですか？

Harris：KongのAI Gatewayは1年半くらい前にCTOのMarco Palladinoが発表したわけですが、当時からAIにおいてもAPIが必要になると言ってきました。MCPとエージェントがあればAPIは要らなくなるという人もいますが、生成AIも実際にはAPIを使って構成されているわけです。ガートナーのイベントではアナリストが「多くの生成AIではエージェントによるトラフィックが主体となる」と語っていましたが、いろいろな意見があることは確かですね（笑）。ガートナーのハイプサイクルではAIの失望期はもう少し先だと言っていますが。逆に訊きたいのですが、日本で生成AIはどう受け止められていますか？

まだ主なエンタープライズ企業は生成AIをどうやってビジネスに使えるのか？ どうやってお金を儲けるか？ どうやってコストを削減するか？ を模索している段階ではないかなと。ソフトウェア開発のアシスタントというのが直近では効果があると思いますが、日本の保守的なエンタープライズ企業は自社でデベロッパーを持っていないので。特に問題になるのは間違いを平気で教えてくれるという部分と実際に生成AIの外部サービスを使い始めた時にコストをどうやって回収するのか？ という部分だと思いますね。コストに関してはAWSが日本に来てエンジニアが使い始めた時に思ったよりもコストがかかってしまうということに気付いたエンジニアが、その間違いを繰り返さないように慎重になっているという段階だと思います。コストに関しては生成AIにおいてもキャッシュを使うというテクノロジーがFastlyから紹介されました。Fastlyのキャッシュ技術は彼らのCDN（Contents Delivery Network）のノウハウが活かされていて、コストよりも応答速度を上げるための主要なテクノロジーになっていると思います。

●参考：エッジコンピューティングのFastlyの共同創業者にインタビュー。生成AIを高速化する仕組みを解説

Harris：生成AIのキャッシングについてはKongもAI Semantic Cachingというサービスがすでに実装されています。その発想はFastlyと似ていると思いますね。

つまり生成AIのAPIを呼び出して毎回プロンプトから回答を生成するのではなく、中間結果をキャッシュとして保存して、よく似たプロンプトからの生成結果を使うことで応答を高速化するというやり方ですか？

Harris：そうです。ユーザーが入力したプロンプトを圧縮してベクターデータベースから近似のプロンプトを探し、その生成結果をキャッシュすることで素早く回答を生成する方法です。KongではVector Similarity Searchと呼んでいます。これはFastlyの生成AIのためのキャッシュの発想と同じかもしれません。KongのAI Gatewayではそれだけではなく大きなプロンプトを制限したり、生成する回答のジャンルを制限したりすることで無駄な処理を減らすこともできます。

KongはAPI Gatewayの経験からさまざまなサービスがスポークだとしてそのハブとなるプロダクトを作っています。MCPも生成AIもAPIが起点となってアプリケーションに組み込まれます。それを個別に開発するのではなく、ハブを介して使うことで制限や制御を組み込む工数を減らすことができます。例えば、トランザクションの中に個人情報（PII）が含まれるような場合にそこからソーシャルセキュリティナンバーだけを消したいというような別アプリケーションの仕様がある場合、それを実行するのは最後にデータをストアするデータベース側でやるのか、アプリケーションのロジックとしてやるのか。選択肢はさまざまですが、それをゲートウェイの中でやるという選択も可能になるわけです。シンプルなアプリケーションであればそれほど難しい問題ではないとは思いますが、サービスメッシュのように複数のプロセスが絡み合ったマイクロサービスのシステムでは、APIゲートウェイでやるほうが効率的だと思いますね。

KongがInternal Developer Portalをプロダクトとして持っていることは知りませんでした。これについてもう少し教えてください。Spotifyが開発して公開したオープンソースのBackstageのようなカタログのようなソフトウェアなんですか？

Harris：良い質問です。Service CatalogとInternal Developer Portalはこれから非常に重要になってくると思います。なぜなら企業が買収や合併などによってこれまで知らなかったアプリケーションを統合する必要が出てくるのは明らかですから。これから新しいアプリケーションを開発しようとした時に複数の似通ったサービスが社内に存在しているかもしれない、それを使えば車輪の再開発は避けられるかもしれないというのは良い着眼点だと思います。それはBackstageと同じですか？ という質問ですが、近いとは思いますが内容は違うと言えますね。私はさまざまなデベロッパーと出会って話をすると皆「Backstageは素晴らしい！ これが欲しかった！」と言いますが、数か月後に再会してみると「I hate Backstage！」と言ってくるエンジニアを多く見ています（笑）。

そのように考えるエンジニアが多い理由は、Backstageにはそこにリストアップされているソフトウェアを評価する仕組みがないからだと思います。それに対してKongでは、そのソフトウェアが何をするのかという概要やAPIに加えて、ソフトウェア自体の評価をScorecardsという仕組みで提示できます。評価がなければ単にリスト化されたソフトウェアの一覧でしかなく、デベロッパーにとってはこれが本当に使えるのか？ という不安が解消されないのでしょう。

もう一つは我々の哲学と言ってもいいかもしれませんが、あるテクノロジーが突然爆発するかのように拡大することがあります。生成AIは今その時を迎えていると思いますが、そうなると業界には多くの似たようなテクノロジーやツール、プラットフォームが産まれてきます。拡大するのは良いのですが、次に現れるのはFragmentation、つまり分断ですね、その時にConsolidation、つまり統合して安定させるということが必要になってきます。マイクロサービスが産まれた時も、すべてがマイクロサービスになるという人もいましたが、実際には揺り戻しが起こって「このアプリケーションはモノリシックなままでいいんじゃないか？」という現象が起こりました。そうやって分断化したものをまとめていくというのがKongの哲学だと思います。常にこのConsolidationを目指しているということを最後に言っておきたいですね。

APIゲートウェイからAIを繋ぐ役目に進化しようという思いが表れているバナーと一緒に

他に最近、注力していることはありますか？

Harris：我々の分野、つまりAPIを使うことをさらに推進するために、最近ドキュメントサイトを再構築して生成AIが再利用しやすいようにしました。API関連はマシンによる可読性が高いエリアだと思います。構成ファイルはYAMLだったりJSONでデータを表現したりというように生成AIの学習の素材として使えることを目指しているわけです。そうすれば生成AIを使ってAPIのためのコードをエンジニアがより速く高い品質で作れるようになります。

●参考：Kong Docs

最後にあなたのチャレンジは何ですか？

Harris：そうですね。生成AIもそうですが常に最先端にいることですね。FragmentationとConsolidationというキーワードがありましたが、最先端にいながらも顧客が迷うことなく使えるようなプロダクトを作ることですね。

Kongは生成AIのモデルを提供するのではなく、あくまでも繋ぐ存在、統合する役目としてMCPやエージェンティックAIも取り込んでいく姿勢を見せたインタビューとなった。生成AIが利用しやすいようにドキュメントサイトを再構築したという辺りからも、最先端のテクノロジーと積極的に関わっていこうとする意図が見えたと言えるだろう。