この記事は Timee Advent Calendar 2025 シリーズ 2 の18日目の記事です。
はじめに
こんにちは、タイミーのDREチームのchanyouです。データ基盤の開発・運用を行っています。
社内向けのAIエージェントの開発プラットフォームを構築したので、その内容をご紹介します。
なお、この記事は人力で書きました。
「AIエージェント開発プラットフォーム」を作った背景
データ活用の新たなアプローチとして AI エージェントを位置づけ、そのために AI エージェント開発プラットフォームを作りました。ここでは、その背景に触れていきます。
データ基盤のこれまでと生成AI
タイミーでは、RDB に保存されたマッチングの記録やCRM に保存された営業の商談記録といった多様なデータを BigQuery に集約し、あらゆる業務で活用しています。
DRE チームではデータの集約を担当しつつ、 BigQuery に集まったデータを dbt を使ってセマンティックレイヤー1という形で整え、 Looker で BI として社内に提供しています。
これまでは人間向けにセマンティックレイヤーを作り込んできましたが、複雑なロジックでも一貫した結果を出力できるセマンティックレイヤーは、生成 AI にとっても有用2だと考えています。
特に AI エージェントは業務に与えるインパクトが大きいと思われるので、セマンティックレイヤーをAIエージェントが参照できるようにしたいと考えました。
外部サービスを導入するか、内製か
外部サービスの導入で解決できる領域も広い一方で、社内データをセマンティックレイヤーを通して生成AIで利用するソリューションには、まだ決定的なものがない印象です。
生成AIを取り巻く環境の変化は早いとはいえ、ソリューションを待つのも時間がもったいないです。ここは内製に振り切って、AIエージェントが使える未来に到達してしまって、課題を先回りしてつぶしておきたいと考えました。
気軽に作って壊せる開発プラットフォームを作る
単体の AI エージェントで Looker に接続できる構成を磨き込む、という選択もできました。
ただ、将来を見据えると AI エージェントで解ける課題は山積しており、AI エージェントをいくつもデプロイできる構成のほうが望ましいです。技術的にも、 A2A プロトコルの実証など、試したいことは多くあります。
このことから、カジュアルに作って壊せる、社内向けの AI エージェントを早く手軽に開発・運用できるプラットフォームを作りました。
「AIエージェント開発プラットフォーム」の解説
利用イメージ
社内利用のためリッチなUIは求めておらず、普段の業務の延長で AI エージェントを利用できる状態を作りたかったので、ユーザーインターフェイスは Slack に振り切りました。
以下の画像のように Slack で利用できるようになっています。
Devin のようにSlack Bot にメンションをするとスレッドが作成されて、AIエージェントとやり取りできます。 画像にはありませんが、人間と会話しているスレッドの途中で AI エージェントにメンションすると、新しいスレッドを作成して会話を行うこともできます。
AI エージェントとの会話の単位をセッションと呼びますが、このプラットフォームでは Slack のスレッドごとにセッションを作成する方針としました。Slack の同一スレッドであれば、AI エージェントはコンテキストを汲み取って会話を継続してくれます。
Slack に振り切ることで、Webでチャットインターフェースを構える場合と違い、実際にAIエージェントが利用されている様子が確認できて、その場でフィードバックを受け取れたりサポートできたりして、開発者としても体験が良かったです。
インフラアーキテクチャ
インフラアーキテクチャは以下の通りです。
graph RL
subgraph Slack["Slack Workspace"]
Bot[Slack Bot]
User[User]
end
subgraph GCP["Google Cloud Platform"]
AE[Vertex AI Agent Engine<br/>ADK]
CR[Cloud Run<br/>Slack Bolt App]
end
User --> |Mention| Bot
Bot --> |POST /slack/events| CR
CR --> |Query| AE
AE --> |Use tool| AE
AE --> |Response| CR
CR --> |Reply| Bot
Bot --> |Display| User
style CR fill:#ffeaa7
style AE fill:#74b9ff
style Bot fill:#00b894
ユーザーインターフェイスとして Slack Bolt アプリケーションを構築し、その背後に AI エージェントフレームワークである ADK（Agent Development Kit）の実行環境を構築する構成としました。
Slack Bolt アプリケーションの実行環境は Cloud Run を、 ADK の実行環境は Vertex AI Agent Engine を採用しました。
Agent Engine には、AI エージェントとの継続した会話に必要なセッションストレージも内包されており、永続化のためのデータベースを別途用意する必要がなく、非常に手軽に AI エージェントを運用できます。
Cloud Run と Agent Engine が各エージェントごとにデプロイされる構成としています。
リクエストからレスポンスまでの流れは以下の図の通りです。
sequenceDiagram
participant User as User
participant Slack as Slack Bot
participant CR as Cloud Run<br><br>Slack Bolt App
participant AE as Vertex AI Agent Engine<br><br>ADK App
User->>Slack: "@hello-world-agent 天気を教えて"
Slack->>CR: POST /slack/events
CR->>AE: クエリ送信
AE->>AE: エージェント処理<br/>ツール実行
AE-->>CR: 応答
CR-->>Slack: 応答を返す
Slack-->>User: 応答を表示
コード管理
コード管理はモノレポ構成を採用しています。
Slack Bolt アプリケーションのコードは共通化しており、Slack Bot の挙動（何をトリガーに、どのように返信するか）は AI エージェントによらず共通としています。
AI エージェントの開発者は、 Slack のイベントハンドリングを意識せず、エージェントの開発に集中することができます。
プレビュー環境
AIエージェントの開発に限らず、Coding Agentのおかげで日々の開発スピードは格段に向上しました。
ただ PR がすぐに作れてしまうので、コードレビューがボトルネックになってくる場面が増えてきました。
レビュー負荷を軽減するために PR ごとにプレビュー環境を作成して、各ブランチの動作確認を Slack でできるようにしました。
Slack Bot 宛のメッセージで@hello-world-agent [PR-123] こんにちは のように [PR-番号] を含めることで、その PR の AI エージェントとして振る舞ってくれます。
Slack Bolt アプリケーションで PR タグの有無を確認して、タグを含む場合はプレビュー環境宛にルーティングする仕組みとしています。
プレビュー環境へのリクエストからレスポンスまでの流れは以下の図の通りです。
sequenceDiagram
participant User as User
participant Slack as Slack
participant CR as Cloud Run<br><br>main
participant PreviewCR as Preview Cloud Run<br><br>PR-123
participant PreviewAE as Preview Agent Engine<br><br>PR-123
User->>Slack: "@hello-world-agent [PR-123] 新機能をテスト"
Slack->>CR: POST /slack/events
CR->>CR: PR-123 タグを検出
CR->>PreviewCR: HTTP転送
PreviewCR->>PreviewAE: クエリ送信
PreviewAE->>PreviewAE: エージェント処理<br/>新機能で応答
PreviewAE-->>PreviewCR: 応答
PreviewCR-->>Slack: 応答を返す
Slack-->>User: 応答を表示
「AIエージェント開発プラットフォーム」の成果
DRE チームではこの開発プラットフォーム上で、Looker で参照できるデータをもとに営業活動をさらにスムーズに行えるような AI エージェントを開発しています。全社的に展開して利用いただいており、まだ伸びしろはありますが、社内業務の効率化に寄与しています。
Looker を参照しているため、 AI エージェントの応答に含まれる数値に一定の信頼が置けています。これを取得したい指標ごとにクエリを用意するなどしていたら、心が折れていたと思います。セマンティックレイヤー様々です。
また開発者目線では、MCP Tool と Function Tool の使い分けやユーザーの認証情報の取り回し、マルチエージェントシステムのデザインパターンなど、 AI エージェントを使ったアプリケーションを開発する上で学ぶべき点が多々あります。これらの手法をすぐに試して勘所をスピーディに掴めるようになりました。
今後の課題
AIエージェント開発プラットフォームにより、作って使えるまでは爆速で行えるようになりました。
一方で、まだAIエージェントを評価する環境がプラットフォームとして整えられていません。
AIエージェントの評価は、プロンプトのチューニングや基盤モデルの変更の際のリグレッションを防ぐためにも重要なので、評価手法を確立してプラットフォームで下支えしていきたいと思います。
まとめ
今回開発したプラットフォームを通して、データ活用のアプローチとしてもAI エージェントは非常に強力であることが分かりました。しかし、AI エージェントがデータを使った業務を支えるためには、一貫した結果を扱えることが前提にあると実感しました。（毎回ブレブレの回答をされると信頼できなくて使えない）
AI エージェント開発プラットフォームが整ったことで、さらにセマンティックレイヤーの重要性が増したと思いました。引き続きプラットフォームを育てつつ、セマンティックレイヤーの拡充も進めていきたいと思います。
AIエージェントを通したデータ基盤のさらなる活用に興味のある方、ご興味があればぜひお話しましょう！
下記よりカジュアル面談がお申込みいただけます。
プロダクト採用サイトは以下よりご覧いただけます。
- セマンティックレイヤーとは、データ加工処理において、データをビジネス用語や概念に紐づけるレイヤーのことを指します。ビジネス用語や概念の定義をコードで一元管理し、タイミーでは Looker から参照するようにしています。これにより、例えば「売上」といった単純そうで意外と定義が揺れがちな指標の定義を固めておくことで、全社員が Looker を通して共通の指標を見ながら会話することができます。↩
- もちろんBigQuery へのクエリを直接 Text-to-SQL させるアプローチもありますが、複雑なドメインロジックを全て Text-to-SQL させるのは、クエリ結果の信頼性を担保するのが難しいと考えています。↩
