KINTO Tech Blog
General

Lambda×Strands AgentsでGA4への問い合わせ画面を構築した話

Cover Image for Lambda×Strands AgentsでGA4への問い合わせ画面を構築した話

この記事は KINTOテクノロジーズアドベントカレンダー2025 の17日目の記事です🎅🎄

1.はじめに

こんにちは!

KINTOテクノロジーズのデジタル戦略部DataOpsG所属の上平です。
普段は社内のデータ分析基盤と「cirro」というAIを活用した社内アプリの開発・保守・運用を担当しています。

以前、下記の記事で、Strands Agentsの導入前の検証事例をご紹介させていただきました。
https://blog.kinto-technologies.com/posts/2025-07-18-try-strands-agent/

当時より発展し、現在「cirro」はAmazon Bedrock × Strands Agentsという構成になっています。
本記事では、「cirro」にStrands Agentsを利用し、GA4への問い合わせ画面を構築した事例を紹介します。

2.本記事の対象者

本記事は、Amazon BedrockをConverse APIやInvoke Model経由で利用した経験があり、
Strands Agents等エージェント開発SDKへの切り替えを迷っている方が対象となります。

3.GA4への問い合わせ画面構築の背景、概要

3.1.背景

GA4 (Google Analytics 4) は、Webサイトやアプリに 「誰が」「どこから来て」「何をしたか」 という、
訪問者のアクセス状況を分析できる非常に便利なサービスです。
しかし、その分析できる項目の種類があまりにも多いため、
初めて使う方にとっては、どこを見たらいいのか、どうデータを読み解けばいいのか、かなり難しいです。

GA4のデータは、主に次の2種類の要素で構成されています。

  • ディメンション:データを分類したり切り口としたりする「属性」を示す項目です。
    • 「どこから」アクセスしたか(例:Google検索、Twitterなど)
    • 「どの国・地域」から来たか
    • 「どのページ」を見たか
    • 「どんなデバイス」を使ったか(例:スマートフォン、PC)
  • メトリクス:具体的な量や頻度を表す「数値」を示す項目です。
    • Webサイトへのアクセス数(セッション数)
    • 特定のページが表示された回数(表示回数)
    • ユーザーがサイトに滞在した時間
    • サイトを訪れたユーザーの数

これらのディメンションやメトリクスの項目が200項目・300項目の規模で存在するため、
慣れていないと欲しい情報にたどり着くこと自体が課題です。

Google公開資料:アナリティクスのディメンションと指標

この課題について、例えば「今週のアクティブユーザ数が知りたい」「アクセス数が多いページは?」等、
自然言語で問い合わせできるようになれば、サイトやアプリの管理者が簡単に傾向を見ることができ
改善に役立つのでは…と構築に着手しました。

3.2.概要

GA4への問い合わせ画面は、よくあるシンプルなチャット画面です。

cirroの画面イメージ

以下の流れでユーザの問い合わせに対し、GA4の内容を応答します。

  1. ユーザの問い合わせを入力
  2. AIがGA4のAPIから現在有効なディメンションとメトリクスの一覧を取得
  3. AIが適したディメンションとメトリクスを選択し、GA4へ問い合わせる
  4. GA4の結果をAI側で表示用の形式に変換し、回答を出力

シンプルですが、ユーザはディメンションやメトリクスを把握せずともAIを介してGA4のデータにアクセスできます。
初心者には単純にデータアクセスの補助として、
ディメンションやメトリクスを全て把握していない中級者の方には、
どの項目で必要なデータが取得できそうかの当たりをつけることに役立ちます。

4.要素技術・アーキテクチャの紹介

ここからは、「GA4への問い合わせ画面」を構築時に使用した要素技術やアーキテクチャをご紹介していきます。

4.1.Strands Agentsとは?

2025年5月16日にAWS Open Source Blogで公開されたオープンソースのAIエージェントSDKです。
以下は、AWSのAmazon Web Services ブログで公開されている図です。

AWSブログからの引用図

図のように、ツールを備えたAIを実装するには、Agentic Loopと呼ばれるループ処理が必要です。
この処理では、AIの応答がユーザーへの回答なのか、ツールを使ってさらに処理を進めるべきかを判断します。

Strands Agentsを使えば、このループ処理を開発者が自前で実装することなく、AIエージェントを構築できます。

参考、図の出典:Strands Agents – オープンソース AI エージェント SDK の紹介

4.2.cirroってどんなサービス?

私の所属するDataOpsGでは下記ミッションを目的に活動しています。

「全社のデータを分析用に整備、AI-Readyなデータ分析基盤を提供することでデータドリブンな意思決定を支援する」

AIは、非エンジニアでも容易にデータにアクセスするための入り口として注目しており、
cirroはDataOpsGで独自に開発・運用している生成AIの活用基盤です。
UI等可能な限り共通化し、チャットや問い合わせ画面のような画面構成であれば、
プロンプトと参照データの追加のみで金太郎飴的に量産できる構成となっています。

cirroの構成図

図のように、①UI/コンピューティング機能と、②システムプロンプトや参照データを分離し、
②を切り替えることで1つのシステムで複数のAIの機能を実現しています。
また、URLパラメータで使用するツールを指定することができ、ツールを持ったAIエージェントとして稼働することも可能です。

今回はこの機能を利用し、cirroでGA4への問い合わせ画面を構築しました。

4.3.GA4の問い合わせ用のツール

Googleが公開する2つのAPIをStrands Agentsが使用するツールとしてラップし構築しました。
cirroはツールを使用して、「利用できるディメンションとメトリクスの取得」と「ユーザの質問に合ったデータをGA4から取得」を実現しています。

4.3.1.getMetadata

GA4で使用できるメトリクスとディメンションを取得するAPI
getMetadata詳細

4.3.2.runReport

指定したプロパティID、メトリクス、ディメンション等から、合致するデータを取得するAPI
runReport詳細

5.実装時のポイント

本記事では、MCPを使用せずツールの形で機能追加を実現しました。
ここではMCPを使用しなかった理由や、ツールでの実装を採用したメリットをご紹介します。

5.1.MCPを使用しなかった理由

cirroはLambdaがコンピューティングエンジンです。
そもそもがツールでできることについて、より工数をかけてMCPサーバを立てることにメリットを見いだせなかった背景もありますが、
Lambda主体とすることで以下の課題があり、確実に機能提供するためツールでの実装を採用しました。

  • Lambdaでの起動方法や、起動時のオーバヘッドの課題
    • Googleが公開するMCPサーバはローカル稼働前提になっている
    • 別途ECS等を使用し自前でリモートサーバとして用意する方法もあるが、Lambda主体の維持管理が容易なcirroのコンセプトと異なる。
  • Lambdaの特性上、うまくMCPサーバと通信できるかの課題
    • MCPサーバとAIの通信は、調べる限り別プロセスを立ち上げ、標準出力を介してやり取りしている。
      Lambda上でMCPサーバと通信できるか調査期間では確証が持てなかった。

5.2.ツールでの実装を採用したメリット

ツールとして実装することによるメリットもありました。

5.2.1.クレンジング処理の追加が容易

API「getMetadata」は大量のディメンションやメトリクスの内容を応答します。
おそらくすべてのディメンションやメトリクスが必要なケースは少ないのではないでしょうか?
私の環境でも、使用していなかったり、想定するユーザ(GA4初心者)にとって不要と思われる項目を、
ツール内で除去しています。
AIに与える情報を削減することで、精度の向上や応答速度、トークン消費量を抑える工夫をしました。

5.2.2.カスタムが容易

ローカルでも稼働するツールとすることで、実装と確認を容易にしました。
また各クライアントで資源を共有するMCPサーバでなく、ツールとして独立するため、
案件ごとの個別の変更を他に影響なく実施できます。
修正前後の比較も、新たなツールと旧ツールそれぞれ共存させ、確認することが容易です。

5.2.3.親子構成のマルチエージェントが構築しやすい

ツールはただの関数です。当然関数内でBedrock等AIのサービスを呼び出すことができます。
AIを呼び出すツールを用意すれば、メインのAIとツール内の子AIが存在するマルチエージェントの構成が組めます。

本記事では採用しませんでしたが、例えば自由記述の文面の前処理や、AIの出力内容のチェック等、
ロジックベースの処理では難しい内容を子エージェント側で処理させるようなこともできそうだ…と考えています。

MCPが注目される昨今ですが、ツールにはツールのメリットがあり小規模で個別開発が発生するようなケースの場合、
まだまだツールでの実現の選択肢は残るだろうな...と個人的には思っています。

6.おわりに

今回は、デジタル戦略部で展開しているAI活用システム「cirro」を活用し、
GA4への問い合わせ画面を構築した事例を紹介させていただきました。

「AIにツールを持たせる」というと難しく感じるかもしれませんが、Strands Agentsを使えば驚くほどシンプルです。
元々「Converse API」を使用したただのチャットボットだったcirroが、
「Strands Agents」に切り替えるだけで、ツールを使ってAPIを呼び出すエージェントに進化しました。

AIエージェント開発に興味はあるけれど、何から始めればいいか分からない...という方は、
まずStrands Agentsで簡単なツールを1つ持たせてみることから始めてみてはいかがでしょうか?
きっと、AIができることの幅が一気に広がる体験ができると思います。

Facebook

関連記事 | Related Posts

We are hiring!

生成AIエンジニア/AIファーストG/東京・名古屋・大阪・福岡

AIファーストGについて生成AIの活用を通じて、KINTO及びKINTOテクノロジーズへ事業貢献することをミッションに2024年1月に新設されたプロジェクトチームです。生成AI技術は生まれて日が浅く、その技術を業務活用する仕事には定説がありません。

【ソフトウェアエンジニア(バックエンド領域)】FACTORY 業務支援G/東京

FACTORY 業務支援GについてFACTORY 業務支援グループは、TOYOTAのアップグレード事業を支える基幹システムおよびバックオフィスシステムの開発・運用・保守を担っています。基幹システムでは、TOYOTA・販売店・KINTOをつなぐ重要な役割を果たしており、今後の成長が期待されるアップグレード事業をシステム面から強力に支援しています。

イベント情報