こんにちは！ kintone 開発の生成 AI チームで EM をしている立山です。 今回は、4/15 にリリースした kintone AI ラボの設計・運用の工夫についてお話しします。
はじめに
kintone AI ラボでは、専門知識がなくても誰でも活用できる AI をコンセプトに、 kintone 内のデータ活用を促進する AI 機能や、kintone の利用者の裾野を広げる AI 機能を中心に提供しています。
現在は、以下の 2 つの生成 AI 機能を提供しています：
- 検索 AI：kintone 内のデータで簡単に RAG（Retrieval-Augmented Generation）を構築可能
- アプリ作成 AI：チャット形式でユーザーの業務に適したアプリを自動作成
これらの生成 AI 機能は 2025 年 3 月までは、一部のお客様のみにベータ提供していましたが、kintone AI ラボリリースに伴い、一般提供を開始しました。 このブログでは、kintone AI ラボのリリースに向けた設計・運用の工夫についてお話しします。
kintone AI ラボの詳細は、以下のリンクをご覧ください。
kintone AI ラボリリースに向けた取り組み
kintone は現在約 3 万 8000 社に導入されております。kintone はサイボウズが管理するデータセンター上で運用されており、マルチテナント環境となります。
生成 AI 機能を提供する AI 基盤は、AWS 上に構築しており、単一 AWS アカウントで複数のお客様のトラフィックを捌いています。
kintone AI ラボリリースに伴い、数万単位のお客様環境からのトラフィックを想定して機能提供を行う必要がありました。
この記事では、以下の 3 点を考慮した取り組みについて紹介します。
- kintone 本体のサービスの保護
- LLM 利用のスケーラビリティ
- 利用状況モニタリングの強化
kintone 本体のサービスの保護
課題感：kintone のコア機能には達成すべき SLO があります。 AI 機能起因で Cybozu が保有するインフラに高い負荷を与えてしまうと、SLO の達成を妨げたり、kintone 自体の提供に影響を与える可能性があります。 特に、多くの AI 機能に特徴的な、LLM による生成処理に伴う Server-Sent Events 等の長時間のコネクションは、kintone 本体のコネクションプールを枯渇させてしまう可能性があります。
取り組み: AI 基盤の kintone 本体との分離
生成 AI 機能が kintone 本体と同じアプリケーションサーバー上で動作すると、意図せず kintone 本体への負荷を高める可能性があるため、AI 基盤は kintone 本体（自社データセンターにて運用）とは分離したアーキテクチャー構成を取りました。 AI 基盤は AWS 上に構築しており、構成は生成 AI 技術を活用した kintone の新機能とシステム概要の紹介で紹介した通りです。
kintone 内のアプリのアクセス権など、kintone 本体側の複雑な権限管理等の仕組みを利用するため、ユーザーからのリクエストは kintone 本体を経由して AI 基盤に送信される構成となっています。
また、全ての通信は、kintone -> AI 基盤の一方向通信を原則とし、AI 基盤から kintone 本体への通信は行わない設計となっています。 これには、kintone 本体へのアクセスを保護するセキュリティ的な目的や、AI 機能の利用急増などに伴う、AI 基盤から kintone へのリクエストの急増が障害点とならないようにする目的があります。
取り組み: kintone 本体のコネクションプールを枯渇させないための通信設計
AI 基盤との通信で kintone 本体を経由する性質上、同時接続が多くある場合に kintone 本体のコネクションプールが枯渇する懸念があります。これを防ぐため、Server-Sent Events のような接続時間が長くなる通信は避けるようにして、生成 AI 機能実行のキューを作成し、定期的なポーリングで生成結果を取得する仕組み（下図）を採用しました。
AI 基盤との通信時間には SLO をチーム内部で設けており、長時間の通信が起こっていないかモニタリングを実施しています。
LLM 利用のスケーラビリティ
課題感：kintone AI では、クラウドサービスが提供する LLM サービスを利用しています。こうしたサービスには、時間あたりの実行回数・入力トークン数にサービスクオータがあります。AI 基盤は単一 AWS アカウントでマルチテナント環境へのサービス提供を行っているため、多くのお客様が同時に利用しても大丈夫なように AI 機能のサービスクオータを増強する必要があります。 また、限られたサービスクオータをマルチテナントで共有するため、利用回数が多いお客様がいると、別のお客様の利用が制限されてしまう懸念があります。
取り組み: 複数モデル併用によるロードバランシング・クロスリージョン推論の利用
kintone AI ラボで利用している Amazon Bedrock では、複数の LLM モデルが提供されており、アプリケーション内で利用する LLM モデルを振り分けることで、サービスクオータを増強しています。
また、Amazon Bedrock の一部の LLM モデルでは、クロスリージョン推論という、複数のリージョンにまたがって推論処理を分配することで、スループットを向上させる機能が提供されています *1。 これにより、kintone AI ラボの利用者数が増加しても、スループットを維持しやすくなります。
取り組み: お客様単位でのリクエスト量を制限し、利用の多いお客様がスループットに影響することを防ぐ
kintone AI ラボでは、お客様単位でのリクエスト量を制限することで、特定のお客様の利用が多くなっても、他のお客様が利用可能なサービスクオータを確保することができ、利用に影響しないようにしています。
また、このようなリクエスト量の制限は結果的に、AI 機能利用に伴う kintone への同時接続数を制限し、インフラ負荷を軽減することにもつながります。
利用状況モニタリングの強化
課題感：生成 AI 機能の利用量はクラウド利用料に直結するため、機能別のトークン消費やリクエスト数をリアルタイムに把握する必要があります。 さらに、一度の生成処理が複数の API リクエストに分散する仕組み上、これらを横断的にひも付けて追跡できなければ、コスト分析や障害切り分けも困難になります。
取り組み: 利用状況（トークン消費量、リクエスト傾向）の可視化
生成 AI チームでは、どの機能がどのくらいの規模感で利用されているかを可視化できるダッシュボードを作成し、日常的にモニタリングしています。 これにより、問題のある利用状況を早期に発見したり、リソースの増強や機能の改善に活かすことができます。
利用状況が簡単に可視化できるため、データサイエンティストと連携して、AI 機能の改善に向けたデータ分析を行うことも可能です。
取り組み: 生成処理の分散トレーシング
可観測性を高めるための共通基盤として OpenTelemetry を導入しました。 これにより、各リクエストの処理時間やエラー率を可視化し、問題のあるリクエストを特定することができます。 未知のエラーが発生した場合でも、分散トレーシングを利用することで、どのリクエストが原因であるかを特定しやすくなります。
AI 基盤特有のリクエストの形態である、一連のキューとポーリングの複数リクエストは、Span Link で紐づけられるように設計しています。 これにより、各リクエストがどの生成 AI の処理に紐づいているかを特定することができ、障害調査を行いやすくなります。
分散トレーシングの取り組みは後日、別の記事で詳しく紹介する予定ですので、乞うご期待ください！
終わりに
kintone AI ラボのリリースにより、より多くのお客様に AI 機能を活用いただけるようになりました。
これからも新しい AI 機能を開発し、皆様の業務を支援していきますので、ぜひご期待ください！
採用しています！
We're hiring！
一緒に生成 AI 技術を活用した機能開発に取り組みませんか？是非、エントリーをお待ちしております！
