【内製開発Summit 2025】ビジネスを強くする内製化推進と生成AI活用の鍵はAPI管理にあり

開発現場のリアルな悩み

皆様、Kong株式会社と申します。本日はお時間をいただき、ありがとうございます。

最近、あるマーケティングプラットフォーム開発会社との打ち合わせで興味深い話を伺いました。この会社では約60名体制で次世代デジタルマーケティングプラットフォームを開発しており、5つのチームに分かれてDevOpsを活用し、各チームが独自のプラットフォームを構築・運用しています。

ミーティングには様々な立場の方が参加されていました。フロントエンドエンジニアからは、バックエンドシステムとの連携時にテストの手戻りが多く発生し、効率が悪いという課題が挙げられました。AIリサーチを担当する2名のエンジニアは、より精度の高いパーソナライゼーションのために複数の生成AI（GoogleのVertexやOpenAIのChatGPTなど）を活用する一方で、個人情報保護の課題に直面していました。

また、開発チームを統括する部長からは、チーム間の生産性にばらつきがあり、特にSRE（Site Reliability Engineer）が参画しているチームは開発効率が良いものの、SREリソースは限られているという現状をお聞きしました。



このような課題は多くの企業で共通しているのではないでしょうか。開発生産性の向上、AIの適材適所での活用とガバナンスの確保、人依存からの脱却など、次世代デジタルプロダクト開発の現場では頻繁に見られる課題です。これらの課題を端的に言えば、「組織全体の開発生産性低下」や「ガバナンスの欠如」といった問題を、標準化・自動化の仕組みを導入することで解決し、開発生産性を向上させることが重要です。

Kongは、API管理こそがその鍵だと考えています。API管理を適切に行えば、開発生産性が向上し、競争力のある新しいプロダクトを生み出せるようになります。

見えざる基盤、API革命

そこで本日は主に3つの課題と解決策についてお話しします。

1つ目は、コードファーストから、APIを戦略的資産として扱う「APIファースト」な文化に変えていくこと。
2つ目は、複数の生成AIを活用しながらガバナンスを確保する方法。
3つ目に、人依存を排除し、プラットフォームエンジニアリングによる仕組み化・自動化を実現することです。



現代社会において、APIはすでに社会基盤となっています。私たちの日常生活でも、朝に天気アプリを確認したり、乗換案内や地図データを使ったり、モバイル決済を利用したりと、様々なサービスの裏側でAPIが連携して動いています。現在、インターネット通信の80%以上がAPI通信と言われています。さらに、AIの出現によりAPIの重要性は今後さらに高まるでしょう。

AIはテキスト、音声、画像など様々なデータをやり取りしますが、そのすべてがAPIを経由しています。プラットフォームがモバイルやクラウドからAIへと移行する中で、APIは爆発的に増加すると予測されます。そこでKongのミッションは、すべての企業をAPIファーストの文化へと導くことです。APIファーストとは、APIを戦略的な資産として扱う文化を指します。

世界が選ぶKongの実力

Kongの設立は2017年。今から約8年前にサンフランシスコで創業された企業です。

創業者のアウグスト・マリエッティと マルコ・パラディーノはイタリアからアメリカに移住し、、ベイエリアでKongを立ち上げました。 Kongは、売上を順調に伸ばし、一般的にユニコーン企業の目安とされる年間ARR（経常収益）1億ドルを、通常10年かかると言われている中、わずか7年で達成しました現在、グローバルで800社以上の企業顧客を持ち、各業界の著名企業に採用されています。



Kongの主力製品であるAPIゲートウェイは、常時300万以上のインスタンスが稼働し、1日あたり5,000億のAPIトランザクションを処理しています。世界で最も広く使われているAPIゲートウェイ製品と言えるでしょう。

ガートナーのマジッククワドラントでも5年連続でリーダーとして評価されており、特にテクノロジーの先進性において高く評価されています。GoogleのAPIgeeやIBMのAPI Connectなども同様の製品を提供していますが、Kongは最もクラウドネイティブなAPI管理製品を提供している会社として認識されています。

一気通貫のAPI管理プラットフォーム

Kongは、APIライフサイクル管理プラットフォームを提供しています。APIの設計からテスト、デプロイ、運用までのライフサイクル全体を一貫してカバーしているのが特徴です。

主な製品ラインナップには、開発者向けのAPI設計・テストツール「Kong Insomnia」、APIトラフィックを処理する「Kong Gateway」と「Kong Ingress」、マイクロサービス間の通信を管理する「Kong Mesh」、そしてこれらを統合管理するSaaS型の「Kong Connect」があります。



詳細は説明しませんが、APIのライフサイクルっていうのは、APIを設計してテストして、実際に使うまでデプロイして、最後運用みたいなサイクルがあると思うんですけども、そこを一気通貫でカバーしてるのがKongの大きな特徴になっています。

コードファーストから、「APIファースト」へ

冒頭で紹介したマーケティングプラットフォーム会社の事例に戻りますが、テストの手戻りが多く非効率になっていた問題は、コードファースト開発の弊害が大きいと考えられます。

これをAPIファーストの文化に変えていくことが、Kongの1つ目の提案です。APIファーストとは、API自体を戦略的な資産として扱う考え方です。



この目的は、より革新的な製品を開発し、サービスのリリースサイクルを早めることにあります。わかりやすい例としてUberが挙げられます。Uberはドライバーと利用者間の通話機能や決済、地図など、多くの機能を外部APIを組み合わせて構築しています。結果として、移動の常識を変えるサービスを生み出しました。コードファーストとAPIファーストの違いを見てみましょう。

コードファーストでは、ビジネスドメインの要件定義後、すぐにビジネスロジックをコーディングし、最終的にAPIを後付けして社内外と連携します。多くの開発現場ではこのアプローチが採られています。

一方、APIファーストでは、要件定義後、ビジネスロジックのコーディングに入る前に、APIの設計とテストを完了させます。それが終わってからコーディングを始めるのです。

APIファーストではAPIのコントラクト（契約）が重要です。プロバイダー（API提供側）とコンシューマー（API利用側）の間で、事前に明確なコントラクトを結びます。例えば、天気アプリでは、気象庁のようなデータ提供者がプロバイダー、モバイルアプリがコンシューマーとなります。



このコントラクトでは、「特定のURIにGETメソッドでリクエストを送り、パラメーターとして地域情報を付けると、HTTPレスポンスコード200とともに、エリア情報、天気、気温が特定のデータ形式で返される」といった内容を取り決めます。

多くの場合、RESTful APIでJSONフォーマットが使われます。プロバイダーとコンシューマーの間でこの契約を事前に交わし、ドキュメントを公開し、テストを先に完了させてから、ビジネスロジックのコーディングに進みます。

コードファースト VS APIファースト

コードファーストの最大の問題点は、チーム間やサービス間に依存関係が生まれることです。例えば、サービスAが需要予測を行い、サービスCが気温や天気情報を提供するとします。

サービスAが機能するためにはサービスCのデータが必要ですが、サービスCが完成するまで待つしかありません。これが依存関係です。実際にサービスCが完成してテストを行った際、仕様の違いや不明確さが発覚すると、再度コーディングしてテストをやり直す必要があります。



特に深刻なのは、セキュリティ問題やパフォーマンス問題が開発の後工程で発見された場合です。期待したパフォーマンスが得られないといった問題が起こりがちです。

一方で、APIファーストの場合は、サービス間の契約が事前に明確になっているため、依存関係がなくなります。サービスAとサービスCの開発チームは並行して開発を進めることができます。これにより全体的な開発生産性が向上します。

ベゾスが20年前に見抜いた未来

APIファーストの始まりは、2002年にAmazonのジェフ・ベゾスが社内で発したAPIマンデート（命令）にあります。2002年といえば、ソフトバンクがADSLモデムを配布していた時代で、スマートフォンもなく、ドコモのiモードが流行していました。そんな時代に、ベゾスは次のような内容のメールを社内に発信しました。

・全てのチームはデータのやり取りをAPI経由で行う必要がある
・情報共有はAPIを通じてのみ行う
・APIは他のチームの開発者が使えるように設計する
・全てのAPIは将来的に外部公開の可能性がある品質を保つ
・このルールを破る者は解雇する



これには、当時のAmazonでチームが増えてデータ共有が難しくなっていたこと、将来的にマーケットプレイスを作る計画があり外部にAPIを公開する構想があったこと、開発者が増えていたためマイクロサービス的な考え方を導入しようとしていたことなどの背景がありました。このAPIファースト戦略は、2006年のAWSの誕生とクラウド市場での成功につながったと言われています。

ゴールドマン・サックスの成功事例

またゴールドマン・サックスは、投資・金融会社でありながら、社員の4分の1はエンジニアであり、10年以上APIファーストに取り組んでいます。インフラ側からアプリケーション開発者を支える役割を担当するRohan氏は、昨年Kongのグローバルイベントで講演し、興味深い内容を共有しました。

彼によると、APIは非常に戦略的な資産になっていますが、ゴールドマン・サックスが当初からAPIファーストを目指していたわけではありません。モバイルアプリやウェブ開発の時代が来たとき、開発者のボトルネックを取り除こうとした結果、APIプラットフォームの導入に至りました。開発者はプラットフォーム側に依頼せずとも、セルフサービスでポータル画面から必要なサービスを受け取れるようになりました。



APIファーストアプローチの良さとして、異なるチーム間で数万人の開発者が分離して並行開発できることが挙げられています。APIコントラクトを守れば、開発者は自由にビジネスロジックを変更したり、新しいテクノロジーを導入したりできるため、自由度が高まります。

また、プラットフォーム側とアプリケーション開発者の間の壁を繋ぐものがデベロッパーポータルです。これは利用可能なAPIをポータルで公開し、開発者に使ってもらうための仕組みです。このようなポータルがないと、数十人規模でも誰がどのようなAPIを作成しているか把握しづらくなります。数千人、数万人となれば、どこにどのようなAPIが存在しているかを把握するのは極めて困難なものになり、同じようなAPIが重複して作られるなどの非効率が生じます。

デベロッパーポータルを公開することで、開発者から信頼される存在となり、プラットフォーム側と開発者側の信頼関係が構築されました。セキュリティの観点では、開発者が自由にセキュリティを実装すると、レベルにばらつきが出てしまいます。標準化されたAPIを使用することで、認証・認可などのセキュリティレベルが一定に保たれるようになります。

AI活用とガバナンスの重要性

2つ目の課題は、複数の生成AIを活用する際のガバナンス確保です。ガートナーによれば、2026年までに企業の80%以上が生成AIのAPIを利用してアプリケーションを本番環境で稼働させるようになると予測されています。



アプリケーションにAIが組み込まれることが一般的になるでしょう。現在のAIトレンドについて、日立ソリューションズ様が参加した米国の大規模AIイベント「AI4」のイベントレポートによると、以下の3つのトレンドがあります。

1つ目が、マルチモデルへの対応が当たり前になっていること。様々なAIがあり、それぞれ得意分野が異なるため、複数のAIを適材適所で組み合わせてサービスを構築する必要があります。また、AIエージェントが処理を分割して自動的に処理をこなし、人を介在せずにAIがAIを使うようになっています。

2つ目が、大規模言語モデル（LLM）だけでなく、小規模言語モデル（SLM）も注目されていることです。H2OのAIが開発した「Danube」のような、少ないリソースでオフライン動作可能なAIがエッジやIoT用途で登場しています。

3つ目に、ガバナンスが非常に重要になっていること。EUでは基本的人権を侵害するようなAI利用が法的に禁止され、AIが作成したコンテンツの著作権問題やAIが生成した内容のトレーサビリティ確保なども課題となっています。



AIのメリットは明らかですが、著作権問題や非倫理的情報の活用、企業機密情報の取り扱いなどのリスクもあります。レースで勝つためには加速だけでなく適切な減速も必要なように、AIの活用においてもアクセル（推進）とブレーキ（規制）のバランスが重要です。

AIリスクから守る「AI Gateway」

実際のデータ通信では、様々なアプリケーションやエージェントがAPI通信を介して、オンプレミスAI、クラウド型AI、業界特化型のファインチューニングされたAIなどと通信しています。

機密情報を保護したり、倫理的に問題のあるデータ利用を防いだりするためのガバナンスが必要です。Kongが提供する「AI Gateway」は、AIを利用するクライアント側とAIサービスの間に配置されるプロキシとして機能し、API通信を監視・制御することで一元的なセキュリティを確保します。主に3つの具体的なメリットがあります。



1つ目が、AIのコスト管理です。トークン数の上限設定や、より低コストのAIへの自動ルーティングが可能になります。2つ目が、機密情報保護の保護です。個人情報などの機密データをAIに送信しないようブロックします。3つ目に、利用状況の可視化です。どのようなデータがやり取りされているかのログ記録と分析を行います。

グローバルでは既に活用が始まっており、大手製薬会社では新薬開発のための論文データベース解析や臨床データの保護、規制ガイドラインの自動分析などにKongのAIゲートウェイを活用しています。



また、世界最大級の航空会社や米国東海岸の金融機関でもAIゲートウェイの導入事例があります。日本でも特定の金融機関でPoC（概念実証）が進行中であり、AIガバナンス確保のためのユースケースは確実に拡大していくでしょう。

人依存から「プラットフォームエンジニアリング」へ

3つ目の課題は、人依存からの脱却とプラットフォームエンジニアリングの導入です。DevOpsは2010年頃から始まり、約15年の歴史があります。

理想的には、ビジネスドメインを最もよく理解している開発者が開発から運用まで担当することが望ましいのですが、実際にはそれほど簡単ではありません。 マイクロサービスやクラウドネイティブ環境では、コンテナ、IaC（Infrastructure as Code）など、非常に多くのツールが存在します。



一人の開発者がこれらすべてを理解し、使いこなして運用まで担当するのは現実的ではありません。 現実的には、開発者10名に対してSRE（Site Reliability Engineer）1名程度の割合で、プラットフォーム側の業務を担当するという形が多いでしょう。

SREはインフラに強いだけでなく、コーディング能力や開発者との折衝能力も求められる、いわばスーパーエンジニアです。 しかし、そのようなスキルを持つエンジニアは多くないため、企業全体で見ると、SREが充実しているチームとそうでないチームで開発効率に差が生じます。冒頭で紹介したデジタルマーケティングプラットフォーム会社の事例のように、多くの組織で人依存の問題が発生しています。

そこで注目されるのが「プラットフォームエンジニアリング」です。これは、開発者がビジネスロジックのコーディングに集中できるよう、それ以外の部分をプラットフォーム側で担当する考え方です。具体的には、Gitリポジトリ、コンテナ、CI/CDパイプラインなどの自動化ツールをポータルサイトから提供し、開発者がワンクリックで必要な開発環境を整えられるようにします。



これにより、組織全体の開発効率のばらつきをなくし、生産性を向上させることができます。近年ではCCoE（Cloud Center of Excellence）とも呼ばれ、開発者のための共通プラットフォームを構築する取り組みが広がっています。Kongでは、このプラットフォームにAPI管理（APIOps）を組み込むことを提案しています。

「APIOps」で自動化を加速

APIOpsは、GitOpsの概念をAPIに適用したものです。GitOpsでは、Gitリポジトリにインフラやアプリケーションコードを保存し、変更する際にはプルリクエストを出して他者のレビューと承認を受けます。

その後、CI/CDパイプラインでテスト、セキュリティチェック、パフォーマンスチェックを行い、問題がなければステージング環境や本番環境にデプロイします。APIOpsも同様の流れで、APIの設計変更をGitにコミットし、プルリクエストを出します。



ここでリンティングと呼ばれるプロセスで、APIの仕様が標準に準拠しているかを確認します。例えば、「このAPIを公開するには特定レベルの認証・認可が必要」といった基準をプラットフォーム側で設定できます。基準を満たさない変更は却下され、修正が求められます。

基準を満たしたAPIは、自動的にYAMLファイルが生成され、APIゲートウェイの設定が更新されて公開されます。さらに、APIの通信状況の可視化も可能です。Kongは、このようなAPIOpsの一連の流れをサポートする製品を提供しています。

具体的には、KongのSaaS型ポータル「Konnect」を通じて、各開発チームが必要なAPIライフサイクルサービスを利用し、自身のAPIを管理・モニタリングできる環境を提供しています。

プラットフォームエンジニアリングのTips

プラットフォーム設計において重要なのは、プラットフォーム側でどこまでの機能を提供するかという境界線の設定です。

アプリケーション開発においては、インフラ部分は明確ですが、パフォーマンス、セキュリティ、可用性などの非機能要件も考慮する必要があります。良いプラットフォームは、汎用的な機能をできるだけプラットフォーム側で提供し、アプリケーション開発者がビジネスロジックに集中できるようにします。



API開発においては、認証・認可やレートリミット（秒間リクエスト数の制限）などの汎用的な機能はプラットフォーム側で提供すべきです。一方、注意すべき例として、APIゲートウェイで業務データを直接操作するようなケースがあります。

APIゲートウェイ上でプログラムを開発できる機能が提供されておりAPI通信のデータを追加、削除、変換するなど様々な処理が可能ですが、データベースへクエリを実行して業務データを取得・加工するといった処理をAPIゲートウェイに実装すると、将来的な変更や製品移行の際に問題が生じます。アプリケーションとインフラの依存関係が強くなりすぎると、運用が難しくなるため避けるべきです。

LINE/Yahoo!とメルセデス・ベンツの成功事例

プラットフォームエンジニアリングの事例として、LINE/Yahoo!の例を紹介します。Yahoo!のサービスは月間700億ビューを記録し、数百の開発チームが存在します。

Kong導入前は、各アプリケーションチームが個別に認証・認可をコーディングしていました。これをKong側に移行したことで、開発時間が数百時間削減されました。また、開発チームによってセキュリティレベルが異なっていた問題も解消され、認証・認可のレベルを全チームで統一することができました。



もう一つの事例として、メルセデス・ベンツが挙げられます。メルセデス・ベンツは車両の走行データをIoTプラットフォームに収集し、ビジネスパートナーに公開しています。Kongを使用したポータルでは、様々なAPIが提供されており、例えばサスペンションの動きを確認するためのデータも利用可能です。

具体的な活用例として、スウェーデンの運輸局がこのAPIを利用しています。スウェーデンは冬季に雪が多く、道路のメンテナンスが重要です。メルセデス・ベンツの車両データを活用することで、どの道路区間が特に凹凸が多いかを特定し、効率的にメンテナンスを行えるようになりました。



このように、企業が保有する固有のデータは、自社内では重要性が認識されなくても、ビジネスパートナーにとっては大きな価値を持つ可能性があります。APIプラットフォームを活用することで、このような情報を新たな販売チャネルや新サービス開発につなげることができます。

「API管理」こそ内製開発と生成AI活用のカギ

お伝えしたかったのは、皆さんの会社にも企業固有の情報があるということです。自社でしか持ち得ない情報であっても、社内では特に価値を見出せていないようなデータであっても、ビジネスパートナーにとっては非常に大きな利用価値を持つ可能性があります。

APIプラットフォームを活用することで、このような固有情報に新たな価値を見出し、新しい販売チャネルの構築や新サービスの開発など、様々な形で活用できるのではないかと考え、今回事例を紹介させていただきました。



API管理こそが内製化推進と生成AI活用の鍵です。適切なAPI管理を導入することで、開発生産性を向上させ、新しいサービスや競争力のあるプロダクトを生み出すことができる—これがKongの考え方です。

最後に、個人的な趣味になりますが、最近和歌を勉強しておりまして、今日のまとめを一言で表現してみました。「組織ごとAPI活かしAIのせ、Kongが支え開発加速」。 少し空気が変わって寒くなったかもしれませんが、大丈夫でしょうか。



私の思いは伝わったのではないかと思います。 このようなことを実現したいというのがKongの目指すところです。ブースもすぐそばにございますので、興味を持たれた方、面白そうだと思われた方は、ぜひブースでお話しできればと思います。 以上で発表を終わります。ご清聴ありがとうございました。

アーカイブ動画はこちら

https://findy-tools.io/events/89b79359179835d8cc5e