Google Cloud × ADK で上流工程支援AIエージェントを作ってみた ｜ R&Dで実践するAIプロダクト開発

はじめに 

はじめまして。株式会社メンバーズ テックリープカンパニーでテクニカルディレクター／エンジニアをしている栁下です。普段は要件定義などの上流工程を中心に、クライアントの技術支援を行っています。今回、社内のR&D施策で「上流工程を支援するAIエージェント」を開発する機会があり、AIプロダクト開発が初めての私が手探りで挑んだ記録を、これから同じ一歩を踏み出す方の役に立てばと思い、記事にしました。

「AIを組み込んだプロダクト開発に挑戦したいけれど、何から手をつければいいか分からない。」「普段の業務に忙殺されて、AIの進化についていけない。」—— そう感じているエンジニアの方、多いのではないでしょうか？

この記事では、Google Cloud と Google ADK（Agent Development Kit）を使い、システム開発の上流工程を支援するAIエージェントを実際に作ったR&Dの記録をシェアします。

• AIを組み込んだプロダクトを、どうやって作るのか

• AI開発まわりの Google Cloud エコシステム（ADK / Gemini Enterprise Agent Platform など）の使いどころ

• 少人数・短期間で動くものに到達する AI駆動開発の進め方

これらのことを知りたい方はぜひご一読いただければ幸いです。

「上流工程を支援するAIエージェント」開発に挑戦

テックリープカンパニーとR&Dの狙い

私が所属するテックリープカンパニーは、「伴走型テクニカルディレクター」として、お客さまのビジネス要求の整理から開発までを一気通貫でご支援する組織です。特にビジネスとITの「橋渡し」役を担い、要求を正確に開発要件へ落とし込む、システム開発における、いわゆる上流工程のご支援を得意としています。

そんな弊社テックリープカンパニーでは、2025年度の下半期、約半年の期間を利用して、AIプロダクトのプロトタイプを短期集中で作るR&D施策を実施しました。

R&Dの狙いは2つです。ひとつは、急速に進化するAI駆動開発に組織として適応すること。もうひとつは、まだ実戦経験の浅いメンバーの技術力を、実践を通じて底上げすることです。

若手メンバーを中心に3つのチームに分かれ、それぞれが設定したテーマに沿ったプロダクト開発を行いました。

何を作ろうとしたのか ― 上流工程支援プロダクト「UPSTREAM」

そんな中、私がリーダーを務めたチームで企画したのは、まさに弊社が得意とする領域をAIの力でさらに強化する上流工程支援プロダクト、通称「UPSTREAM（仮）」の開発です。

要件定義は、プロジェクトの成否を大きく左右しながら、担当者の経験に依存しがちな工程です。「何を聞けばいいか分からない」「会議で大事なことを聞き漏らす」「仕様変更の影響範囲が追えない」——こうした属人的で若手にとって痛みとなるような課題を、AIで支援することを狙いにテーマを設定しました。

モックアップとして開発した実際の画面を、ワークフローに沿っていくつか紹介します。

プロジェクト一覧：組織の内外で案件を共有し、ナレッジとして蓄積・管理する入口。

ダッシュボード：プロジェクトの進捗、AIによるリスクアラート、推奨アクションを一覧する。

Preparation（準備）：案件概要やQCDの優先度などを入力し、AIによるヒアリング項目生成の土台にする。

Hearing（ヒアリング）：AIが生成したヒアリング項目・アジェンダを管理。右上の「AI Whisper」から会議支援を起動する。

Documentation（文書化）：テンプレートに沿って要件定義書を作成・管理し、完成度やプレビューを確認できる

UPSTREAMが構想したのは、要件定義の一連の流れ——「事前準備 → ヒアリング → 文書化 → 変更管理」——を、役割の異なる複数のAIエージェントが分担して支援するプラットフォームです。具体的には、次のような機能群を想定していました。

• 事前準備：業界・ドメインの事前調査、MECEなヒアリング項目の自動生成

• ヒアリング：会議をリアルタイム支援する AI Whisper（本記事の主役）

• 文書化：議事録やRFPなどから要件定義書を自動生成・更新、不足箇所の可視化

• 変更管理：仕様変更のインパクト分析、要求と仕様のトレーサビリティ管理

ポイントは、これらを1つの巨大なAIに詰め込むのではなく、役割ごとに分かれた複数のエージェントが協調して担う構想だったことです。

もう一つ意識したのが、技術スタックの選び方です。R&Dとはいえ、メンバーには実際のプロジェクトでも通用する「生きたスキル」を身につけてほしいと考えていました。そこで、自分たちだけが使える試作品で終わらせるのではなく、将来的には SaaS のような形で社内・社外のユーザーに使ってもらうことまで見据えた、本番運用を前提とする実践的な構成を狙いました。

注力したのは会議をリアルタイム支援する「AI Whisper」

もっとも、AI駆動開発全盛の時代とはいえ、これらをすべて作り切るのは、限られた人数と時間では現実的ではありません。そこで私たちは、このプロダクトが提供する最もコアな体験として、会議を支援する通称「AI Whisper」機能に注力することにしました。

AI Whisper は、オンライン会議中にAIが会話をリアルタイムで分析し、「矛盾している点」「曖昧な点」「次に聞くべき質問」などをカード形式で提案する機能です。経験の浅い担当者でも、ベテランのように的確なヒアリングができることを目指しました。

AI Whisper のイメージ。会議URLを入力するとAIボットが会議に同席し、会話から「矛盾」「曖昧さ」「次に聞くべき質問」をリアルタイム（目標5秒）にカードで提案する

どう作ったか ― Google Cloud × ADK のアーキテクチャ

さて、前置きが長くなりましたが、ここからが本題です。結論としては、私たちは Google ADK をエージェント基盤に据え、Gemini Enterprise Agent Platform（旧 Vertex AI） をはじめとする Google Cloud 製品で全体を構成することにしました。

そもそも「AIエージェント」とは？

ここで、技術選定の話に入る前に「AIエージェント」の定義について触れておきます。

ここで言うAIエージェントとは、LLM（大規模言語モデル）を"頭脳"として、与えられた目標に対し、自分で考え、必要なツールや情報を使いながら、複数のステップにわたって処理を進める仕組みのことです。プロンプトを一度投げて答えを受け取るだけの「単発のLLM利用」とは違い、状況に応じて判断とアクションを繰り返す点を特徴としています。

そして前述のとおり、UPSTREAMは「事前調査」「ヒアリング支援」「文書化」「変更管理」といった、役割の異なる複数のAIが互いに連携しながら動く構想でした。

これを Gemini API などの直接呼び出しだけで実現しようとすると、エージェント同士の制御、状態の受け渡し、ツールの実行、処理フロー全体の管理まで、そのほとんどを自前で作り込むことになります。

そこで私たちは、APIを直接叩くのではなく、複数エージェントの構築・連携・実行を支える「AIエージェント開発フレームワーク」を使う方針を決めました。

マルチエージェント基盤になぜ Google ADK を選んだのか？

候補に挙げたのは、Google ADK（Agent Development Kit）・LangGraph・CrewAI の3つです（加えて、フレームワークを使わず Gemini API を直接利用する案）。これらを、今回のR&Dで重視する次の観点で比較しました。

• マルチエージェントの構築：役割の異なる複数エージェントを組み、連携させやすいか

• 開発・評価の効率：ローカルでの実行・デバッグ・評価がしやすいか

• 実行・スケーリング：本番運用に載せるまでの導線があるか

• 外部ツール・データ連携：検索や社内データなど、外部のツール・情報源につなげやすいか

• 学習コスト・情報量：キャッチアップのしやすさ

こうした前提のうえで、Google ADK が最終的な決め手になったのは次の2点です。

1. プロトタイプから実運用までを一気通貫で扱え、開発効率が高い
   エージェントの構築・実行・評価・スケーリングまでを一連の流れでカバーでき（ローカルのDev UIでの試行から Gemini Enterprise Agent Platform の Agent Runtime（旧 Agent Engine）へのデプロイまで）、「作って終わり」ではなく実運用を見据えられる点が魅力でした。

2. 必要な外部ツールが、組み込みで揃っている
   外部ツール連携自体はどのフレームワークも備えていますが、私たちが必要とした検索やRAGは、google_searchやvertex_ai_search_toolのような形でADKの組み込みツールとして用意されていました。おかげでRAGや情報収集まわりを、追加の作り込みを最小限に抑えて実現できました。

逆に、扱う処理が単純で単発のLLM呼び出しで足りるなら、フレームワークを挟まず Gemini API を直接使う方が軽量です。今回は「複数エージェントの連携」と「実運用までの見通し」の両方を要件として設定したため、ADKが適切であると判断しました。

全体アーキテクチャと中心となる Google Cloud 製品

全体像は次の通りです。

※ ★が、今回のR&Dで実際に作り込んだ AI Whisper。ほかのエージェントは、全体構想の一部です。

中心となる構成要素は次のとおりです。

• Google ADK：AIエージェントの開発フレームワーク。本プロダクトの中核

• Gemini Enterprise Agent Platform の Agent Runtime（旧 Agent Engine）：エージェントの実行・運用基盤。モデルの呼び出しやセッション管理を担う

• Gemini（Gemini Enterprise Agent Platform 経由）：エージェントの"頭脳"となるLLM

• Google検索 / Agent Search（旧 Vertex AI Search）：エージェントが ADKの組み込みツール として呼び出す外部サービス。前者はWeb上の情報収集、後者は社内ナレッジの検索（RAG）に使う。

• Cloud Run：バックエンドの実行環境。コンテナベースでオートスケール

• Cloud SQL（PostgreSQL）／ Cloud Storage：プロジェクトや要件のデータ、ドキュメント・議事録などの保管。プロジェクト単位でデータを分離する想定

• MCP（Model Context Protocol）：今回は未使用。将来、Backlog や Jira などのプロジェクト管理ツールと連携するための拡張口として見据えている

処理の流れはこうです。バックエンド（Cloud Run）からの依頼を受けて、ADKのコーディネーターが各エージェント（Knowledge / Documentation / Whisper / Reviewer など）に処理を委譲します。各エージェントは、ADKの組み込みツールを介して外部サービスを呼び出します。たとえば、情報収集ではGoogle検索、社内ナレッジの参照ではAgent Searchを、それぞれツールとして使う、といった具合です。データや成果物は Cloud SQL・Cloud Storage に保存します。

なお、図中に点線で示した MCP（Model Context Protocol） に関しては、将来 Backlog や Jira といったプロジェクト管理ツールと連携させるための拡張口として位置付けています。

唯一、Google Cloud 以外から採用したのが recall.ai です。AI Whisper はオンライン会議での利用を前提としていたため、会議の音声を取得する手段が欠かせませんでした。recall.ai は、Google Meet / Zoom / Microsoft Teams といった主要なオンライン会議システムに bot として同席させ、音声の取得と文字起こしを1つのAPIで容易に行える点が魅力でした。

AI Whisper のアーキテクチャ ― リアルタイム提案の仕組み

AI Whisper の処理は、準備段階（セッション開始）とリアルタイム分析ループの2段階に分かれます。

まず準備段階では、ユーザーが会議URLを指定してセッションを開始すると、バックエンドがその会議のコンテキスト（要件定義の現状やヒアリング項目）をエージェントに読み込ませ、 recall.ai に会議botを作成して会議へ参加させます。

会議が始まると、あとは次のループが回り続けます。

1. recall.ai が会議音声を文字起こしし、Webhook でバックエンドに送る

2. バックエンドは即座に受領応答（200）を返し、分析は裏側で非同期に進める

3. LLM（Gemini Flash系）が、読み込んだコンテキストと発話から「矛盾／曖昧／次の質問」を1回の呼び出しで判断する

4. 結果を SSE（Server-Sent Events） でフロントにプッシュし、カードとして描画する

分析のポイントは、ルールを固定したパターンマッチではなく、LLMに会話の文脈ごと判断させていることです。これにより「一般的にはそうですが、今回は具体的に決めたい」のような、文脈に依存する発言にも対応できます。

そしてもう一つ重要なのが、会議セッションの開始時に「その会議の文脈」をエージェントへ渡していることです。要件定義の現状や、ヒアリングすべき項目といった情報をあらかじめ入力しておくことで、AIは字面だけを追うのではなく、プロジェクトの文脈を踏まえて「いま何が曖昧か」「次に何を確認すべきか」を判断できます。

このコンテキスト連携はまだ構想段階で、今回は十分に検証する時間が取れませんでした。ですが、ここを Agent Search などと組み合わせれば、過去の議事録や関連資料まで踏まえて、AIの応答をいっそう文脈に沿った的確なものにできると考えています。

さらに、リアルタイム性も重要な観点でした。設計時に置いた目標は、発言からカード表示まで5,000ms（5秒）以内。recall.ai の通知（Webhook）にはタイムアウトがあるため、「通知には即座に受領応答を返し、AIの分析は裏側で非同期に走らせる」設計にしています。設計段階で粗く見積もったレイテンシの内訳が、次の表です。

ただし、これはあくまで「発話のたびに即座に分析する」という設計時の理想値です。実際に動かしてみると、発話ごとに分析するとカードが頻繁に出すぎてしまい、LLMの呼び出しコストもかさみました。そこで実装では、確定した文字起こしを約10秒分まとめてから分析する方式に切り替えています。

動作デモ

実際の動作を見てみましょう。デモでは、あらかじめ用意した会議のシナリオを流し、それに対してAIがどう反応するかを実演しています。題材は「紙ベースの患者管理システムを電子化したい」という想定の模擬ヒアリング（約5分・10発話）で、わざと曖昧な表現や矛盾を仕込んであります。具体的には、こんな反応を確認できます。

• 「なるべく早めに」「セキュリティは適宜対応で」といった曖昧な発言 → 🟡 曖昧性を検出し、具体化を促す

• 予算が「500万円」と言った後で「やっぱり1000万円くらい」に変わる → 🔴 矛盾を検出

• 冒頭の挨拶のような発言 → カードを出さずスキップ

動作デモ：上記シナリオを流し、会議の進行に合わせて Whisper Card がリアルタイムに表示される様子。

ご覧のとおり、会議の会話に応じて概ね適切な提案カードが表示されています。残念ながら、R&Dとして与えられた期間で形にできたのは、ここまでです。一方で、AIの打ち返しには少し「間」があり、実用に向けてはまだ詰めしろが残っていることがわかります。

（余談）さらにチューニングして実用へ近づけるには

ここからは余談ですが、実用に耐える水準へ近づけるとしたら、処理のストリーミング化 が検討対象に上がりそうです。現状では発話が確定してからまとめて分析していますが、文字起こしの途中経過を使って分析を先行させ、AIの応答も逐次描画していけば、体感のレスポンスはかなり改善できるものと思われます。

「双方向通信」の文脈において、Google には Gemini Live API が存在します。これは人と音声で対話するエージェント向けの仕組みで、裏方に徹するAI Whisperとは少し毛色が違いますが、リアルタイム性を突き詰める選択肢として検討の余地は十分にあると考えています。

（実はこのR&D期間中、メンバーを引き連れて Google Agentic AI Summit '26 Spring に参加してきました。そこで見たリアルタイムなAIエージェントの実演には大いに刺激を受け、「自分たちのAI Whisperも、いずれこのなめらかさに近づけたい」と素直に思わされたものです。こうした最新の動向も追いながら、プロダクトを自由に改善していけるのもR&Dの良さだと思います。）

R&Dを通じて感じたこと

今回のR&Dは、通常の案件稼働とは別枠で、2025年10月末からの半年弱をかけて行いました。チームは6名でしたが、メンバーの多くは案件を抱えており、さらに期の途中で新たに案件へ稼働する若手も出てくるなど、リソースの配分は終始ままなりませんでした。ならしてみれば、6名を合わせても月に1人月あるかないかくらいの規模感です。

それでも、フロントエンドからバックエンド、AIエージェント、インフラまでをフルスタックで一通り組み上げ、動くところまで持っていけました。この前提を踏まえたうえで、半期のR&Dで得た学びを3つにまとめます。

AI駆動開発はもはや「マスト」になった

企画から設計、実装まで、全工程で Claude Code を全面的に導入しました。一人月という限られた工数で、企画・設計・実装を横断できたのは、間違いなくAI駆動開発のおかげです。AIプロダクト開発が未経験でも、ここまで作り切れる時代になっていることを肌で実感することができました。

スキルやリソースが足りなくても作り切れる時代

前提として触れたとおり、割けるリソースはごく限られていました。それでもフロントエンドからバックエンド、AIエージェントまでを形にできた最大の理由は、AI駆動開発で多くの作業をAIに任せられたことにあります。

もちろん、つまずきもありました。ADKの構造化出力がツール併用時にうまく動かない既知の問題に当たったり、RAGの勘所が不足していて当初は過剰な構成を描いてしまったり。それでも、AIに調べてもらい、検証を回しながら乗り越えられました。詰まっても、解にたどり着く速度が上がっていると感じました。

「どう作るか」より「何を作るか」が重要になった

振り返ると、私たちは「どう作るか」の検討でずいぶん遠回りをしました。知見が足りなかったために、技術を決めるまでの「調べて、選ぶ」段階で迷走してしまいました。エージェント基盤をどれにするか二転三転し、RAGも当初は要件に対して過剰な構成を検討してしまう。実装に着手する前のリサーチに、多くの時間を吸い取られました。

その一方で実装そのものに使った時間は、決して多くありませんでした。参考までに、GitHubのコミット履歴で「実際にコードを書いた日」を数えると、フロントエンドとバックエンドを合わせて実日数でおよそ20日強でした。しかも1日にR&Dへ割けた時間は限られていたので、正味の作業時間はさらに短いはずです。半年のR&Dのうち、手を動かしてコードを書いていたのは、その程度だったのです。AIを相棒にすれば「実装」のフェーズはここまで圧縮できる——裏を返せば、残りの大半の時間は「何を作るか」「どう作るか」を考えることに費やしていたわけです。

そして、ここに最大の学びがありました。AIが「どう作るか」をどんどん肩代わりしてくれる時代だからこそ、本当に価値を分けるのは「何を作るか」の見極めだ、ということです。技術選定に消耗するより、解くべき課題の選定に頭を使う。速さよりも、何を作るかの質が問われていると感じました。

まとめ ― R&Dで終わらせず、実業務とカスタマーサクセスへ

今回のR&Dは、AI駆動開発への適応とメンバーの底上げという狙いに、確かな手応えを残しました。

私たちは、この取り組みを今後も案件にアサインされていない待機メンバーや有志を中心に続けていきます。そして、R&Dで終わらせず、実際の業務に組み込めるプロダクトへと磨き上げ、AIの力でクライアントのカスタマーサクセスを実現していくつもりです。

AIの登場により、AIプロダクト開発は、経験豊富でなくても、手を動かしながら十分に挑戦できます。この記事が、その最初の一歩を後押しできれば嬉しいです。

テックリープカンパニーが目指すもの

私が参画するテックリープカンパニーは、ビジネス部門とIT部門の「架け橋」となり、ビジネス要求をシステム仕様に翻訳するテクニカルディレクター支援に特化した専門組織です。

今回のR&Dで挑戦したような「AI駆動開発」や、要求と仕様のトレーサビリティを担保する「仕様駆動開発」といった最先端のアプローチを強みとしています。顧客のビジネスを深く理解し、成果志向を持つ「あたかも社員®」のようなパートナーとして、システム企画や要件定義といった上流工程から実装・運用フェーズまで一気通貫で伴走支援いたします。

「上流工程の属人化に悩んでいる」「AIを活用した次世代の開発プロセスを取り入れたい」という方は、ぜひカンパニーサイトもご覧ください。