APIライフサイクル管理の進化と生成AIの活用へ / 開発生産性Conference 2024

2024年6月28日(金)・29日(土)、ファインディ株式会社は「開発生産性Conference 2024」を開催しました。本カンファレンスは、虎ノ門ヒルズフォーラムのオフライン会場にて実施され、一部のセッションはオンライン配信も行われました。

本記事では、Kong株式会社 Solutions Engineerの橋谷信一氏による「APIライフサイクル管理の進化と生成AIの活用へ」の内容をお届けします。

APIライフサイクル管理の最新トレンドと、生成AI時代におけるKong社のソリューションが果たす役割についてご講演いただきました。

■登壇者
Kong株式会社 Solutions Engineer
橋谷信一（はしたにしんいち）
臨時テスター/プログラマーから業務SE、PM、アーキテクト、事業会社側デリバリー担当、アーキテクトマネージャーと開発領域にて幅広く従事。その後製品プリセールス（Pivotal/VMware Tanzu、Confluent）に転身し、クラウドネイティブ基盤（Cloud Foundry/Kubernetes）やデータストリーミング基盤（Kafka/Flink）の導入支援の経験を経てKongに2024年2月入社。専門はソフトウェアアーキテクチャ、モダナイゼーション、クラウドデータ、保険ドメイン。

APIを取り巻く環境の変化と課題

まず、APIを取り巻く環境について見ていきましょう。ガートナー社の2025年予測によると、主にアメリカ市場でAPIを取り巻く環境が大きく変化すると予想されています。

APIの数が増加し、管理が困難になる
API自体が攻撃対象になる
ミッションクリティカルなデータをAPI経由で扱うことが増え、 APIの障害がビジネスに直接影響する
REST以外での通信が増加する

日本でもこの傾向が見られ、APIの利用拡大に伴いセキュリティやガバナンスの課題が浮上しています。APIの数が増加している背景には、新規アプリケーション開発時のマイクロサービス化や、既存アプリケーションの分割、さらには当初APIを想定していなかったアプリケーションへのAPI追加などがあります。

サービス開発の分野では、マイクロサービスでのアプローチ、クラウドネイティブなランタイム、ドメイン駆動設計、プロダクトマネジメントなどが急速に成熟してきました。しかし、API管理に関しては過去5年間で大きな変化が見られず、他の分野から置いてけぼりになっているような印象を受けます。

この状況の根本的な原因は、APIをサービスの単なる一部としか捉えていないことにあると考えられます。我々はAPIの重要性を再認識し、その管理手法を進化させていく必要があるでしょう。

APIライフサイクル管理を新しい視点で理解する

我々はAPIをより重要なポジションとして捉えるべきですが、その本質的な価値を理解するのは難しいものです。そこで、APIはたまごっちのようなものだと思っていただくとわかりやすいかもしれません。

たまごっちは、ロジック部分（下部）とUI部分（上部）から構成されています。プロダクトの生命はロジックにありますが、ユーザーが実際に触れ、感情を抱くのはUI部分です。2.5インチほどの小さなディスプレイに8ビットのキャラクターが動きます。一見シンプルなUIですが、ユーザーの感情や体験を生み出す重要な役割を果たしています。

APIも同様の構造を持っています。内部にはロジックや複雑な処理が存在しますが、ユーザーである開発者が直接やり取りするのはインターフェース部分です。つまり、APIはたまごっちのUIと同じように、ユーザーとシステムをつなぐ重要な接点なのです。

この視点から、APIをサービスの単なる技術的な一部として扱うのではなく、ユーザー体験を左右する重要なインターフェースとして捉えるべきだと考えます。たまごっちのUIがユーザーの感情を生み出すように、APIは開発者の体験や生産性に大きな影響を与えます。そのため、APIにも独自のライフサイクルがあり、ユーザーである開発者のニーズに合わせて進化し、管理されるべきなのです。

APIを作る側と使う側の認識には大きなギャップがあります。このギャップが、APIが他の技術領域から置いてけぼりにされている一因かもしれません。

APIを作る側は、APIを技術的な構成要素として見ています。バージョン管理、機能の追加、パフォーマンスの最適化など、技術的な側面に注力しがちです。一方、『Web APIの設計』という本によると、APIを使う側である開発者は、自分が使用しているAPIバージョンが突然機能しなくなるような破壊的な変更があるかどうかにもっとも関心があります。ユーザーにとって、APIはサービスそのものであり、APIが安定し、一貫しているかどうかが最も重要なのです。

このギャップは主に二つの面で顕著です。それはドキュメンテーションと観測性です

ドキュメンテーションに関しては、一般的なAPIドキュメントは機械的で、アクセス方法やパラメータ、結果のSpecが記されています。これはOpenAPI Specに基づいたものが多いですが、使う側にとっては不十分なことがあります。例えば、パラメータの詳細や挙動の説明、アーキテクチャの概要などが不足していることがあります。

観測性については、我々のKong Konnect基盤では、APIをプロダクトとして捉え、重要なメトリクスを表示しています。特に注目すべきは、リクエスト数、エラーレート、レイテンシーの3つです。リクエスト数はAPIの価値そのものを直接表し、エラーレートとレイテンシーはユーザーエクスペリエンスに直結します。

これ以外にもメトリクスはありますが、使う側の観点から本当に重要なKPIを的確に見ているかを考えることが重要です。

APIをプロダクトとして捉え直すことで、このギャップを埋めることができます。APIのライフサイクル全体を通じて、ユーザーの視点を重視し、フィードバックに基づいて継続的に改善していくのです。これは一見遠回りに感じるかもしれませんが、長期的にはAPIの価値を最大化し、ユーザー満足度を高める重要なアプローチとなります。

しかし、APIにこの考え方を当てはめると、いくつかの課題が見えてきます。例えば、ドキュメンテーションが使う側の視点で不十分だったり、APIのユーザーエクスペリエンスを測定する指標が偏っていたり、CI/CDパイプラインでAPIが適切に扱われていなかったりします。

APIのライフサイクルについては、いくつかの見方があります。一般的なものは、プランニング、開発、テスト、デプロイ、公開、フィードバック、そして再度開発というサイクルです。これはソフトウェア開発のライフサイクルと似ていますね。

しかし、私が今日お話ししたいのは、別の視点です。Postmanが提唱している考え方で、ライフサイクルを2つに分けて考えます。

1つは作り手側のライフサイクルで、APIの要件定義、設計、開発、デプロイ、公開、そしてフィードバックを受けて再度要件定義するというサイクルです。

もう1つは使う側のライフサイクルで、APIの発見、評価、統合、デプロイ、観察、そして新しいAPIや変更を見つけて再度評価するというサイクルです。

この2つは独立しているように見えますが、実は密接につながっています。作った側が公開したAPIを使う側がすぐに利用でき、使う側のフィードバックを作る側が適切に反映できるというモデルが理想的です。

Kong社が提案するAPIライフサイクルマネジメント

ここからは、我々Kongの考えるAPIライフサイクルマネジメントについて解説します。

Kong社のソリューションの中心となるのは、Kong GatewayというオープンソースのAPIゲートウェイです。これはVMやKubernetesクラスタにデプロイでき、南北のトラフィックを管理します。

また、Kong Meshというサービスメッシュ実装もあり、これはKubernetesクラスタ内部や複数クラスタ間の東西トラフィックをサポートします。さらに、Kong InsomniaというAPIの設計、テスト、モック作成などができる統合開発環境も提供しています。これらを横断的に管理するのがKong KonnectというSaaSのマネージドサービスです。

Kong Gatewayの主な特徴は以下の通りです。

軽量性：50MB以下のシングルバイナリで提供され、デプロイメントが簡素化される
高性能：2コア4GBメモリで秒間1万リクエストを処理できる
スケーラビリティ：需要増加に柔軟に対応できる
拡張性：プラグインで様々な機能を追加できる
統合管理：複数のAPIゲートウェイを一元管理できる

Kong Gatewayは、プラグインシステムにより拡張性が高く、認証やレート制限など様々な機能を追加できます。自社提供のプラグインが数十種類、OSSのものを含めると1000種類以上あります。

最近のAPIゲートウェイの使い方として、外部サービス（AIモデルやLLMなど）への接続を一元管理するアプローチが増えています。これにより、個別のアカウント管理やアクセスコード管理が不要になり、認証・認可を一括で行えるのです。

Kong Gatewayでは、ボット検出、DDoS対策、ヘッダー変換、アクセストークン管理、流量制限などを必要に応じてプラグインで実装できます。

このアプローチにより、多くの非機能要件をアプリケーションから分離し、APIゲートウェイレイヤーで対応できます。ルーティング、ロードバランシング、認証・認可、ログ・メトリクス取得、キャッシングなどを一元管理でき、アプリケーション自体の自由度を高められます。

要するに、横断的なアクセス／トラフィック管理をPolicyで行い、そのPolicyを宣言的に管理することがKongの提供する大きな価値だと考えています。

ここからは、APIライフサイクルマネジメントに対する我々Kongの考えについてお話しします。今日は特に「Secure & Package」の部分に焦点を当てて、我々のアプローチを詳しく説明したいと思います。

この部分が重要だと考える理由は、私自身もKongに入る前に苦労した経験があるからです。例えば、CI/CDパイプラインを構築する際、開発者は価値を生む作業に集中したいと考えます。そのため、ソースコードだけでなく、OpenAPI SpecでのAPI定義、テストコード、ドキュメントなども含めてCIで回すことができます。しかし、CDへ渡るのは主にコードのみが対象となります。

つまり、テストをパスしたコードをビルドイメージやバイナリに変換してデプロイするのがCDの役割ですが、ここでゲートウェイのConfigも考慮する必要があります。

このConfigはOpenAPI Specと完全に同じではありませんが、Specで定義されたものを反映させる必要があります。例えば、新しいパスを定義した場合、それをゲートウェイのConfigに反映させないと、リクエスト時にアクセスエラーが発生してしまいます。

ここで同期を取りたいのですが、OpenAPI SpecとAPIのConfigは同一ではないため、この部分がつながらないとマニュアルの作業が増えてしまいます。この自動化は一見シンプルなポイントに見えますが、全体的な健全性を自動で維持するためには非常に重要です。

APIライフサイクル管理の自動化でAPIOpsを実現

APIライフサイクル管理の自動化について、Kong社が提供する2つのツール、InsomniaとdecKをご紹介します。

まず、Insomniaは APIの統合環境です。

主な機能としては、OpenAPI Specをこのツールで書いてモックサーバーとしてデプロイしたり、外部で提供されたAPIを自分でテストしたりデバッグしたりできます。また、curlコマンドやPostmanのコレクションをインポートしたり、自作のスクリプトをチーム内で共有したりすることもできます。これはデスクトップで使用するツールです。

さらに、Insomniaにはinso commandという、部分的な機能をコマンドラインで提供するものもあります。このinso commandでは、パイプライン上でコマンドを「inso lint spec」とするとSpecの検証をしてくれたり、「inso run test」とすると関連するテストを実行できます。これにより、CIの領域でもOpenAPI Specに対して、問題ない状態までパイプライン化できます。

もうひとつのdecKは、Kong Gatewayを宣言的に管理するツールです。

API Specは1つではありません。複数のサービスがあれば、それぞれにAPI Specがあり、それらを1つのゲートウェイにデプロイします。さらに、Kongのプラグイン定義や、ユーザー側の認証情報、ロール、RBAC権限なども別々のファイルで定義されています。

新しいAPI Specが作成されたり更新されたりした場合、パイプライン内で「deck file openapi2kong」というコマンドを使用します。これはAPI SpecをKongのConfigに変換するものです。

このコマンドを実行すると、OpenAPI Specの定義をそのままKong GatewayのConfigに変換できます。その後、ファイルをマージして「deck gateway dump」コマンドを実行すると、現在のKong Gateway Config全体をエクスポートします。

「deck gateway diff」で問題がないか差分を確認し、OKであれば「deck gateway sync」コマンドを実行します。すると、変更箇所だけがKong Gateway上に反映され、Open API Specの変更がそのままKongにデプロイされるというモデルになります。

この2つのツール、InsomniaとdecKを組み合わせることで、我々が「APIOps」と呼んでいる1つのパイプラインを構築できます。

APIライフサイクル管理の課題は、APIのエコシステムを柔軟に保ちながら、同時に健全な状態をPolicyで管理し、さらにAPIの設計と運用をシームレスにつなげることです。これがライフサイクル管理のゴールだといえるでしょう。

生成AI時代に対応するKong AI Gateway

最後に、今年の春に新しく公開したKong AI Gatewayを紹介します。これは新しい製品というよりも、既存のAPIゲートウェイに対するプラグインとして定義されています。

例えばOpenAIのLLMを使い始めた後、コスト面や機能面で別のLLMに切り替えたい場合、Kong AI Gatewayによって、アプリケーション側ではなくゲートウェイのレイヤーで切り替えができます。また、LLMに送信してはいけない機密情報をフィルタリングしたり、APIコールごとのコスト管理ができます。

APIコールのコストは予測が難しく、例えばカレーのレシピを尋ねる簡単なプロンプトと、大量のグラフデータを処理する複雑なプロンプトでは、同じAPIコールでもコストが大きく異なります。そのため、AIに特化した流量制限機能も提供予定です。

現在、8つのAIプラグインがあり、そのうち6つはOSSで公開しています。これらのプラグインを使うことで、認証情報の管理、複数のLLMの切り替え、プロンプトのテンプレート化、ポリシーの適用、特定の文言のブロックやマスキングなどが可能になります。

今日は3つの主要なプラグインを紹介します。

AI Proxy
異なるLLMへの接続を制御します。パスやヘッダー情報の変更で、リクエストの送信先を切り替えられます。

AI Prompt Decorator
プロンプトにポリシーを埋め込みます。例えば、翻訳や要約の指示、データ量制限、フォーマット指定などができます。

AI Prompt Template
プロンプトをテンプレート化し、パラメータや変数で埋め込むアプローチです。これにより、プロンプトの精度向上や使用方法の制御ができます。

これらのプラグインにより、AIの管理やセキュリティ、コスト制御など、現在企業が直面している課題に対する解決策を提供できると感じています。

以上で終了となります。