Kong株式会社について

白石：Kongはサンフランシスコで2017年に創業した企業です。前身のMashape社は2009年から事業を展開しており、10年以上の歴史を持ちます。社名は前身のMashapeの「Ape」部分を強化し、より強いイメージを表現するためにKongと名付けられました。

Kongは世界で最も使用されているAPIゲートウェイとして知られていますが、それだけではありません。APIクライアント、AIゲートウェイなど豊富なポートフォリオを持つ「APIプラットフォーム」として事業を展開しています。近年、多くの企業がプラットフォーム戦略を掲げる中、Kongも総合的なAPIプラットフォームとしてのポジションを確立しています。

特筆すべきは金融系企業での高い導入実績です。グローバル市場において約40%の顧客が金融業界であり、これは安定性とセキュリティの面で高く評価されていることを示しています。



私はIBMでハードウェア、バーチャライゼーション、ネットワーク分野を経験した後、現在は日本企業の課題解決に貢献できるソリューションの普及に取り組んでいます。

Kongのミッションは、すべての企業をAPIファーストへ導くことです。本セッションでは、そのミッション実現に向けたAIとAPIの両面からのアプローチについて解説します。

AI利用の現状と日本の課題

開発生産性について語る際のキーワードとして、AI関連では「生成AIの利用」「AIエージェント」「MCP」、API関連では「マイクロサービス化」「内製化」「DevOps」などがあります。まずはAIに焦点を当てて解説します。

AIによる生産性向上について、多くの企業がAIを利用しており、その効果は明らかです。実際の事例として、Googleの生産性が10%向上したという報告があり、新規コードの30%以上をAIで生成しているとのことです。

海外の調査会社によるデベロッパーツール調査では、開発者がAIツールを使う目的として、最も多かったのは生産性向上で81%に達しました。これらのデータから、AIを活用すべきという流れは確実にあると考えられます。

一方で、日本ではAI利用があまり進んでいません。2024年のデータによると、40%の日本企業がAIを使わない方向性を示しています。米国では91%がAI推進中である一方、日本では67%にとどまっています。



エンジニアレベルでは差がさらに顕著で、米国93%に対し日本は40.6%という状況です。2025年現在は多少変化している可能性がありますが、AI利用は進んでいないのが実情です。

なぜ日本でAI利用が進まないのでしょうか。この疑問をAIに聞いたところ、技術的課題、人材不足、企業文化、データ活用に関する課題などが挙げられました。

解決策として、AI人材の育成、AIに関するリテラシー向上、データ活用環境の整備、セキュリティ対策の強化が求められています。この中で私が今日踏み込みたいのはセキュリティとリテラシーの課題です。

AIにおける課題をITで解決するには？

セキュリティやリテラシーといった課題は抽象的に語られがちですが、分解して具体的に捉えることで解決策が見えてきます。

AIについてのセキュリティ課題として、4つのポイントが挙げられます。

第一は機密情報の漏洩です。AIに何かを入力した際、それが学習されて情報漏洩が起こるのではないかという不安があります。

第二はAI利用キーの漏洩です。通常キーを取得してそれを使用しますが、そのキー自体が漏洩してしまった場合の対策が必要です。

第三はAI・AIエージェントの不正利用です。適切なAIや自社で購入したAIを使用しているかを確認する必要があります。

第四は不適切なプロンプトの利用です。社内で不適切な言葉を使用しようとしたり、変な情報を取得しようとしたりするケースへの対応が必要です。

リテラシーの課題については、3つの要素があります。

第一はコストです。トークンの使いすぎが大きな課題となります。経営者はこの点を非常に気にしますが、開発者はあまり意識せずに作業する傾向があります。

第二は正確性への不安です。ハルシネーション対策や、従業員が適切なプロンプトを作成できるかという課題があります。正しいプロンプトを入力しないと正しい答えは返ってきません。

第三は利用方針です。AIをどの業務に使うか、どのAIを使うかという選択が重要なポイントになります。



これらの課題に対する解決策を整理します。

セキュリティ課題については、機密情報の検知とマスキング、キーの一元管理、認証認可の実装、不適切プロンプトの内容監視とブロックが必要です。キーを個別に配布するのではなく、一箇所で一元管理することが重要です。

コストや正確性の課題については、トークン使用量の監視と制御、キャッシュ利用によるトークン削減、プロンプト補完テンプレートの利用が有効です。一言二言の簡潔なプロンプトでは適切な回答が得られないため、テンプレートで補完する仕組みが必要です。

AI選択の課題については、利用AIを簡単に変更できる仕組みの構築が解決策となります。どのAIを使用しても簡単に切り替えができる環境を整備することで、今日のタイトルにもある「AI選択の落とし穴」を回避できます。

最も重要なのは、全てのAI通信にガバナンスを効かせて抜け漏れをなくすことです。これが基本方針となります。

ゲートウェイによるAI管理

先ほど説明した課題解決策を実現するために、具体的にどのような仕組みでAI利用の土台を作るかについて説明します。

現在、多くの組織ではユーザーやエージェントがChatGPT、Claude、Gemini、Copilot、Bedrockなど様々なAIサービスに直接通信している状況です。これでは制御しようがありません。

AIへの通信（API）をすべてGatewayでまとめることで一元管理を実現し、ガバナンスを確立します。すべてのAI通信が必ずゲートウェイを通る構成にすることで、統合的な制御が可能になります。



ゲートウェイ導入で重要なポイントが2つあります。第一に、できるだけ対応AIが多いことです。今後AIが増えてきた時に「サポート外」を作らないためです。第二に、ゲートウェイがどこでも動くことです。オンプレミスでもクラウドでも動作する必要があります。

ゲートウェイには何らかのポリシーを適用します。認証認可では、ゲートウェイの段階でIdP連携を行い、OpenID ConnectなどによりEntra IDやOktaなどと連携します。怪しいユーザーは遮断し、外部ユーザーに対してはキー認証を使用するなど、状況に応じて使い分けも可能です。

キーの一元管理については、ゲートウェイにキーを保持させ、認証認可を正常に終了したユーザーに対してキーを自動的に挿入してAIサービスに送信します。これによりキーの流出を防ぎ、有効期限管理も適切に行えます。

重要情報の保護では、機微な情報がリクエストに含まれている場合の情報マスキング機能を提供し、問題のあるプロンプトを受けた場合には自動的にブロックします。例えば、RAG的な仕組みで会社の情報をAIに読み込ませる際、一般従業員が機密情報に触れるようなものを簡単に取得できて良いのかという課題をゲートウェイの層で制御します。



コスト対策とプロンプトの補助では、キャッシング機能が中核となります。チャットボットやコールセンターなどでは似たような問い合わせが多数発生するため、ゲートウェイの層でキャッシングし、類似の問い合わせには過去の回答を返すことで、トークン消費を大幅に抑制できます。

流量制限機能では、トークン使用量を監視し、使いすぎている人、部署、サービスに制限をかけます。マルチLLMの利用では、ChatGPTやClaudeなど、それぞれ異なるリクエストとレスポンスの形式をゲートウェイの層で吸収し、ユーザーが書くAPIリクエストを統一できます。

これにより、まずは一つのAIで開始し、より良いものが登場した際に簡単に乗り換えることができ、AI選択の落とし穴を回避できます。意味合いを判断した自動ルーティングも可能です。

プロンプトテンプレートの作成機能では、ユーザーがゲートウェイに送信したプロンプトを、より詳細で具体的な内容に自動的に肉付けし、正確性を担保します。



最近注目されているMCPについても、MCPクライアントからMCPサーバー、その先のUpstream APIsまでの全ての流れにゲートウェイを挟むことができ、MCP通信においても認証認可をかけることが可能になります。

APIゲートウェイの価値

KongはそもそもAPIゲートウェイの会社で、2つの側面からビジネスを支えています。一つは開発者やVPoEの視点、もう一つはIT部門のCIOやCISOの視点です。

では、KongのAPIゲートウェイがどんなものかをご説明します。従来は各アプリケーションで実装していた非機能要件を、API Gateway層で巻き取ることでガバナンスとセキュリティを効かせるのが容易になります。アプリA、B、Cにそれぞれ認証認可、流量制限、ロギング、キャッシングといった機能を個別に実装していましたが、何らかの理由でアプリにロギングがない、流量制限ができないといった状況が生まれ、でこぼこができてしまいます。

これを全てAPIゲートウェイの層でまとめると、皆様の通信はここを通り、ここでセキュリティやガバナンス、コンプライアンスを全て効かせた上で、その先のAPIに通信が行く形になります。

IT部門のCIOやCISOの視点では、セキュリティやガバナンスを効かせることにより、より安心してAPIを活用できることが大きな価値です。外部へのAPI公開をしてビジネスに繋げることも楽になります。



開発者にとって、アプリを新規作成する際にビジネスロジックを書くのは楽しいかもしれませんが、非機能要件の部分を楽しく書く人はあまりいません。大抵のお客様からも「やりたくない」という声を聞きます。

また、会社の統合が起こった場合、認証やログ転送の作り直しなどで認証認可の仕組み全体が崩れてしまい、アプリを改修しなくてはいけない状況が生まれます。しかし、アプリAは影響範囲が広すぎて触れたくない、アプリBは昔のSIerが作っているからどうなっているか分からない、アプリCは重要だけど古すぎて触れたくない、といった状況がよくあります。

この問題に対して、Kongは非機能要件は最初から作らなくて良い仕組みにします。内製化するお客様が多いですが、専門の会社に任せた方が良いと考えています。改修の際も、アプリA、B、Cには全く改修を入れずに、その上の層ですべてを巻き取ることで、開発者視点でも生産性のアップにつなげることができます。これがAPIゲートウェイの良さです。

API Platformへの進化

APIゲートウェイは日々進化しており、API Gateway → API Management → API Platform、そしてその先へと発展しています。現在はAPIプラットフォームの段階まで来ており、この進化の背景には現代のマルチクラウド環境における新たな課題があります。

現在はマルチクラウドの時代で、アプリも分散しています。お客様と話していて「全部AWS」「Azureのみ」という方は珍しく、大抵は複数のクラウドを使い分けています。AWSがほとんどですが、ある部署はAzure、データ分析基盤はGCPというパターンが一般的です。

実際のデータでも、企業の6割がマルチクラウドを採用しており、最近ではAWSのシェアが30%を切ったという報告もあります。この傾向により、せっかくAPIをまとめてAPIゲートウェイでいろいろなことができるようになったのに、今度はAPIゲートウェイそのものが分散してしまうという新たな課題が生まれました。

分散されたAPIゲートウェイをどうやって管理するかが課題になります。ガバナンスを効かせたいのに、APIゲートウェイが広がったならば、ガバナンスが効かないという問題が発生します。

弊社のアプローチはシンプルです。Konnectという制御基盤をクラウド側に配置し、それとAPIゲートウェイを繋ぎ、全体に対してガバナンスを効かせることができるようにしました。

それだけでなく、さらなる追加機能を提供しています。開発者ポータルを社内や社外に公開する機能により、「このAPIを使えるんだ」ということが分かり、サービスが広がっていきます。

APIのプロダクト化では、APIの要件やスキーマ、バージョニングなどをしっかり定義します。API高度分析では、遅延やサクセスレートをここで監視できます。

サービスカタログでは、APIを作ったはいいけれども、ちゃんとそれを評価しないといけないので、横断的なスコアリングを行います。ここにAIやKafka、その他クラウドサービスを統合して、今、APIプラットフォームという形になっています。



さらに、InsomniaというAPIクライアントまでつけることで、開発の生産性をさらに上げることに成功しています。統合的なAPIクライアントを使うことで、いわゆるDevOpsのAPIバージョンのような、APIOpsというものを弊社は提唱しています。Open API Specを書けば、たとえばそれをInsomniaを利用してGitHubにCommitできます。それを起点としてそこからGitHub Actionsでパイプラインを走らせることができます。Open API Specを作成し、GitHubに送ることをきっかけとして、APIバージョンの更新、スキーマ管理の更新を行い、開発者ポータルも更新します。さらにAPIゲートウェイの更新すらできるため、1つのOpen API Specのコミットをきっかけに、APIに関わるところのほとんどすべてに対して変更を加えていくことができ、APIの運用が楽になります。

横断的環境管理では、APIを作るとなってくると、部署ごとに横串を刺してみた方が絶対楽になってきます。このAPIはどの部署が使っていて、どんなスコアで、それを使っているGitリポジトリーは何で、どのSlackチャネルで、プロジェクトマネージャーは誰かといったものを、Excelで管理するのではなく、Konnect側で管理することでぐっと楽になります。

Kafkaについては、APIは基本的に同期通信ですが、Kafkaのような非同期通信のデータをREST APIの形で抜いてくる、それをデータ活用しようというイベントゲートウェイも弊社は持っています。

マイクロサービスをやる場合のサービスメッシュについては、IstioなどよりもKong Meshの方が運用コストを低く、教育コストを低く使えるというのが弊社の特徴です。

最後に、AIのガバナンス、セキュリティをここでしっかり担保することで、これが今後のAPIのプラットフォームという形になります。APIゲートウェイから始まったビジョンが、今、ここまで広がっていて、皆様のAPI環境を包括的に管理することができます。

APIファーストの世界

APIプラットフォームが実現する最終的な目標は、弊社のミッションである「すべての企業をAPIファーストへ導く」ことです。全てのAPIにセキュリティとガバナンスを効かせ、APIをより活用するためのソリューション群を提供し、APIOpsによるパイプライン作成を可能にします。

従来の開発手法は「コードファースト」でした。要件定義をして、コーディングをして、最後に連携も考えてAPIを入れていくという流れです。

しかし、APIファーストでは要件定義の段階でAPI設計を先に行い、その後でコーディングを進めます。連携を視野に入れ、APIありきで設計・開発を行うことで、APIをより重要なものと位置付け、APIでビジネスを拡張していくアプローチです。

この違いは重要です。連携を見据えたサービスが最初から後戻りなくできるからです。お客さんと話している中で、「10年ぐらい前に作ったサービスですが、API連携を考えていませんでした。今、これとこれを連携させたいんだけど、どうしたらいいですか」という相談を受けることがあります。

このような後戻りなく、ビジネスの速度を止めることなくサービスを打ち出していくには、API設計を先に行うAPIファーストという発想が必要になってきます。APIファーストを採用することで、皆様のサービスはもっと広がっていき、連携がもっと広がっていき、そして皆様のビジネスがさらに広がっていきます。

導入事例：LINEヤフー様

最後に、LINEヤフー様の事例を紹介します。

Yahoo Japanのポータルサイトから、Yahoo!オークション、Yahoo!ショッピングなど、様々なサービスに遷移すると思いますが、ああいったサービスの間にKongが使われています。

LINEヤフー様での導入効果について、3つの大きなポイントがあります。

まず開発工数の削減効果です。開発者は認証と認可の実装をAPIごとに作成する必要がなくなりました。これにより、1個のAPIにつき数時間分の作業を削減できたという実績があります。

次に、Kong を通じた社内向けAPIの一元的な公開です。これがデベロッパーポータルの機能になります。デベロッパーポータルにAPIの仕様を公開することで、他の開発者が「このAPIを使うんだ」「このデータを抜けるんだ」ということを容易に把握できるようになりました。

3つ目は、Kongのカナリアリリース機能の活用です。APIを更新した際、AからA'へのトランザクションをKongが少しずつマイグレーションしながら、だんだん新しいAPIに通信を移していくという機能があります。

LINEヤフー様からは「冗長なコードの作成に費やしていた数百時間を削減できると考えている」というコメントもいただきました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です