無駄と文化

実用的ブログ

自作AIエージェントの開発をやめた

今年の6月まで、データ分析用途の AI エージェント (以下、分析エージェント) をスクラッチで開発していた。
が、思うところがあり開発をスッパリとやめた。この記事でいろいろと振り返ってみようと思う。

 

3行まとめ

  • 分析エージェントを開発するのはやめて、分析 MCP として作り直した
  • AI エージェントの全てを開発するのは手間がかかりすぎる
  • 良い分析体験のキモはエージェントが動く手前にある

 

分析エージェントから分析 MCP へ

もともと作ろうとしていたエージェントは、チャット UI で分析を依頼するとデータ取得・考察・結果の可視化までを担うものだった。
ところが AI エージェント全体を作ろうとすると自作しなければいけない構成要素が多すぎる。全てに注力するには時間がかかるし、限られた時間で多くのものを作ろうとすると一つひとつのクオリティは下がってしまう。

そこで今年の7月からは心機一転 MCP を作ることにした。事前集計されたデータを返したり、各データについての知識を的確に返すような MCP だ。
私たちの用途では MCP を作り込むので充分だという感触を得ている。汎用エージェント (Claude.ai など) に MCP を接続するだけで、基礎的なデータ分析を担うエージェントとして使えそうだ。

 

自作エージェントの守備範囲

分析エージェントは Google Agent Developer Kit (ADK) を使って作っていた。
ADK はマルチエージェントシステムを構築・デプロイするためのフレームワークで。サブエージェントを定義してタスク分担・オーケストレーションといったことを手軽にできるようになる。

とはいえ AI エージェントを自作するとなると賄わなければいけない領域は多岐にわたる。

  • UI
  • 認証基盤
  • セッション管理
  • メモリー
  • サブエージェントのオーケストレーションルール
  • アセットアップロード
  • アップロードされたアセット管理
  • スキルシステム

ざっと挙げただけでも、これらは自作する必要がある。

UI 以外は無くても分析エージェントとして成り立つものの。普段使っている Claude.ai, ChatGPT, Gemini などと比較してしまうと物足りないものになる。

 

メモリーという難所

特にメモリーが難しい。セッションをまたいでユーザーの関心事ややりとりの注意点を記憶させておく仕組み。

仕組み自体はシンプルだ、

  • ユーザーとの会話から覚えておくべきことを抽出する
  • なんらかのデータベースに情報を永続化する
  • しかるべきタイミングでデータベースを検索し、適切に参照させる。

これだけ。

しかし「覚えておくべきことを抽出」「しかるべきタイミングで検索」「適切に参照させる」これらが奥深すぎる。

 

一応、 mem0 などのサードパーティ製の API を使って楽をすることはできる。が、開発者側でやるべきことはいくらか残る。

  • 過去のメモリーを訂正する
  • 過去のメモリーを忘却させる

などは実装側で工夫する必要がある。

最大の欠点は、ユーザーが普段使っている AI エージェントとの間でメモリーが共有されないことかもしれない。どれだけ良い AI エージェントを自作してもメモリーが引き継がれないことが乗り換えの障壁になりうる。

 

汎用エージェントに任せられること

このように自作エージェントには本質的なタスク (例えばデータ分析) でない部分で実装コストがかかりすぎる。
一方で必要な部分だけ MCP 化して、残りを汎用エージェントにお任せするのは現実的なんだろうか。

私の場合、とてもうまく機能している。作り直した分析 MCP を接続することで、汎用エージェントが "分析エージェント化" した感覚だ。

データを表示する UI は手放しでも改善されていく。最近の Claude.ai は Claude Artifacts でインタラクティブな可視化もしてくれる。
認証基盤・メモリー・アセット管理・スキルシステムなども言わずもがな、普段の使い慣れた仕組みをそのまま分析業務にも活用できる。

これらの "備え付けられた" 便利な仕組みを捨ててまで自作エージェントをゼロから作る動機を私は見出せなかった。

 

分析の手応えとデータ基盤

では自作の分析エージェント作りは全くの無駄骨だったのか。実はそうでもない。
分析エージェントを作るなかで、分析業務に本質的に重要な部分と汎用の仕組みを活用するべき部分が見分けられるようになったからだ。

最初は『BigQuery の execute_sql ツールを AI に繋げば良い感じの洞察を語ってくれるのかな?』などと思っていた。
が、これは全然違った。当たり前のデータを渡すだけでは当たり前のことしか言わないのが AI だ。何の工夫もしなければ「朝晩は電車が混むようです」「冬はおでんが売れるようです」などのわかりきったことしか言わない。

むしろ、分析エージェントとして前進している感覚が得られたのは、

  • 注目するべき指標をしっかり定義し、チームで合意したとき
  • 注目するべき指標が日々事前集計されるよう仕組み化したとき
  • 注目するべき指標が正確になるようにデータの収集方法を見直したとき

だった。

これらどれも AI 以前の工程であり、データ基盤として当たり前のことをコツコツやる類のアクションだ。
つまり有用な分析エージェントを作るためには有用なデータ基盤が必要で。エージェントなんか作ってる場合ではなかったのだ。

 

引き算で進んだ MCP への移行

そんなわけで分析エージェントはやめて分析 MCP を作った。
コードの多くは分析エージェント時代のものを流用できている。リライトにあたって整理整頓できたのも良かった。

MCP のベースには FastMCP を使っている。Google ADK も FastMCP もベースには FastAPI があるのでコードがとても似通ったものになる。
ドメインモデルの面でも実装の面でも移行は難しくなかった。

 

使ってもらえる場所に届ける

先日チーム内で MCP を共有し、Claude.ai のコネクタとして接続して使ってもらった。
普段使っている Claude.ai が突然 分析エージェントとして振る舞いだすのはみんなにとっても面白かったらしく。「こんな感じで使ってみました」と活用例がシェアされてきた。

私がずっと自作分析エージェントを作っていたとしても、このような驚きとクオリティを提供できていなかったと思う。技術を使うべき正しい場所をようやっと見つけ出したような気分になっている。

 

まとめ

分析エージェントをやめて、分析 MCP を作り動かし始めた。
少し遠回りだった気もするが。作って、手放して、分かったことも多かった。

 

 

私からは以上です。

歩いて福岡県脱出旅 - 2日目

福岡市から下関市まで約80kmを歩いて旅します。この記事は旅路のログです。随時更新。

行程

ログ

06:11 🚶‍♂️現在地

今日もここから。約40km先の下関駅を目指します。


06:36 🚶‍♂️現在地

折尾。


06:57 🚶‍♂️現在地

49.6km地点。


08:04 🚶‍♂️現在地

6.6km地点、黒崎駅。

まとめ

たったの7kmほど。足が痛すぎた、伴って歩くのが遅くなりすぎたので断念しました。
前日の寝不足、当日の低体温もキツかった。

そのうち再挑戦します。

歩いて福岡県脱出旅 - 1日目

福岡市から下関市まで約80kmを歩いて旅します。この記事は旅路のログです。随時更新。

行程

ログ

06:02 🚶‍♂️現在地

朝6時の博多駅です。ここから80km先の下関まで徒歩で旅します。


06:27 🚶‍♂️現在地

2.7km地点、福岡空港が見える。


06:39 🚶‍♂️現在地

この旅でお世話になりがちな国道3号線。


06:48 🚶‍♂️現在地

現場ネコ。


07:09 🚶‍♂️現在地

5.2km地点。


07:49 🚶‍♂️現在地

8.2km地点、道が広くて歩きやすい。


08:39 🚶‍♂️現在地

11.1km地点。


09:04 🚶‍♂️現在地

12.9km地点


09:25 🚶‍♂️現在地

古賀市に突入。


09:42 🚶‍♂️現在地

15.8km地点。


10:01 🚶‍♂️現在地

唐津街道 青柳宿


10:31 🚶‍♂️現在地

18.6km地点。


10:58 🚶‍♂️現在地

21.4km地点。


12:32 🚶‍♂️現在地

25.6km地点。


13:18 🚶‍♂️現在地

28.4km地点。


14:02 🚶‍♂️現在地

30.2km地点


15:50 🚶‍♂️現在地

37.5km地点。


16:04 🚶‍♂️現在地

海老津赤レンガアーチ


16:23 🚶‍♂️現在地

38.1km地点、海老津駅。


17:02 🚶‍♂️現在地

何もない!


17:16 🚶‍♂️現在地

遠賀町に突入。


17:31 🚶‍♂️現在地

ガレージみたいな古着屋さんだ。おしゃれ。


17:56 🚶‍♂️現在地

41.2km地点、遠賀川。
デカい。(暗い)


18:16 🚶‍♂️現在地

45.1km地点、水巻駅。
今日はここまで!


まとめ