AIエージェントの自作か、MCPか。データ基盤を先に整える考え方を整理

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回紹介するのは、ブログ『無駄と文化』の記事『自作AIエージェントの開発をやめた』です。データ分析用のAIエージェントの自作をやめて、分析MCPに作り直した話が書かれています。

この記事は、私が保存したブックマークの1つです。読んでいて、私の過去の記事に書いた考えと重なりました。AIを増やすほど文脈の置き場が要ること、つなげば動くとは限らないこと、手順書づくりのAIは聞き取り役と点検役にとどめること。この考えを、今回の話に重ねて読んでみました。

読み方の筋はこうです。経緯、自作で背負う部品、メモリー、MCPをつなぐこと、指標を決めること、データ基盤が先という話、そしてAIに任せる線。最後は私の読みとして整理しています。あなたが自分専用のAIエージェントを作るかどうか迷っているなら、判断の材料になるはずです。

ブログ『無駄と文化』の記事『自作AIエージェントの開発をやめた』の「3行まとめ」より（2026年11月5日公開・第1章で引く部分）

分析エージェントを開発するのはやめて、分析 MCP として作り直した

ブログ『無駄と文化』の書き手は、分析エージェントの開発をやめて、分析MCPとして作り直しました。2026年11月5日に公開された記事の、いちばんの結論です。

書き手は今年の6月まで、データ分析用のAIエージェントを、スクラッチで開発していました。スクラッチとは、ゼロから自分で作ること。それが、思うところがあってスッパリとやめたそうです。

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

もともと作ろうとしていたのは、チャット画面で分析を頼むと、データ取得、考察、結果の可視化までを担うものでした。ところがAIエージェント全体を作ろうとすると、自作する部品が多すぎる。

限られた時間では、一つひとつの質が下がってしまう。書き手はそう書いています。

そこで今年の7月から、MCPを作ることにしました。事前集計されたデータを返す。各データについての知識を、的確に返す。そういうMCPです。事前集計とは、あらかじめ数をまとめておくこと。

MCPは、AIに外の道具やデータをつなぐための共通の差し込み口の決まりです。

書き手の感触は、MCPを作り込めば充分、というものです。

Claude.aiのような普段使うAI、つまり汎用エージェントにMCPを接続するだけで、基礎的なデータ分析を担うエージェントとして使えそうだと書いています。

私の読みです。これは、何を自分で作り、何を借りるかの線引きの話なんです。AIそのものの出来の話ではありません。自分専用のAIを考えるとき、まずこの線引きから入るのが近道かな、と受け取りました。

ブログ『無駄と文化』の記事『自作AIエージェントの開発をやめた』の「3行まとめ」より（2026年11月5日公開・第2章で引く部分）

AI エージェントの全てを開発するのは手間がかかりすぎる

AIエージェントを丸ごと自作するのは、手間がかかりすぎる。書き手の実感を読者向けに言い直すと、こうなります。ここから、何に手間がかかるのかを順に見ていきます。

書き手は分析エージェントを、Google Agent Developer Kit、略してADKで作っていました。複数のAIに役割を分けて動かす仕組みを、動く場所に置くための道具です。

サブエージェントを決めて、分担の順番を指揮するオーケストレーションも手軽にできる。

それでも自作となると、賄う領域が多岐にわたります。書き手が挙げたのは8つです。UI、認証基盤、セッション管理、メモリーが前半の4つ。

続きが、サブエージェントのオーケストレーションルール、アセットアップロード、アップロードされたアセットの管理、スキルシステムです。

アセットは画像や資料などのファイル、セッションは1回のやりとりのまとまり、と読むと分かりやすいかな。

UI以外は無くても、分析エージェントとして成り立ちます。ただ、普段使っているClaude.ai、ChatGPT、Geminiと比べると、物足りないものになる。書き手はそう書いています。

私の読みです。8つのうち、データ分析そのものに当たる部分は、ほとんどありません。ログインも、記憶も、ファイルの置き場も、分析の本質ではない。

本質ではない部分に時間が取られる、というのが書き手の実感の中身だと受け取りました。

あなたの仕事で考えてみてください。AIを使うために、ログインと記憶と資料置き場を、全部自分で用意する場面です。本題の仕事に入る前に、手が止まりそうじゃないですか？

ブログ『無駄と文化』の記事『自作AIエージェントの開発をやめた』の「メモリーという難所」より（2026年11月5日公開・第3章で引く部分）

最大の欠点は、ユーザーが普段使っている AI エージェントとの間でメモリーが共有されないことかもしれない。

自作したAIの記憶は、普段使うAIと共有されない。書き手は、これが最大の欠点かもしれない、と書いています。

メモリーとは、セッションをまたいで、ユーザーの関心事ややりとりの注意点を覚えておく仕組みです。仕組み自体はシンプルで、3つしかありません。会話から覚えておくべきことを抽出する。

データベースに情報を永続化する。しかるべきタイミングで検索して、適切に参照させる。データベースは、情報を整理して置いておく入れ物のことです。

ところが、この仕組みがどれも奥深い。覚えておくべきことの抽出も、しかるべきタイミングの検索も、適切な参照も、深い。mem0などのサードパーティ製のAPIで楽はできます。

それでも、過去のメモリーを訂正することと、忘却させることは、実装側の工夫が残る。書き手はそう書いています。

たとえば、ユーザーが前に伝えた注意点を、後で変えたくなったとします。そのとき、古い記憶を直す仕組みが要る。要らなくなった記憶を、忘れさせる仕組みも要る。

どれだけ良いAIエージェントを自作しても、メモリーが引き継がれない。それが乗り換えの障壁になりうる、と書き手は言います。

AI氣道『NotionのFDE担当、AIの乗り換えは文脈の置き場が整えば軽いと話す』より

「AIを増やすほど、文脈の置き場が要る。置き場がないまま増やせば、毎回コピペのやり直し。」

AIを増やすほど文脈の置き場が要るという考えを、私は『NotionのFDE担当、AIの乗り換えは文脈の置き場が整えば軽いと話す』で書いています。

置き場がないまま増やせば、毎回コピペのやり直し。私の記事は、そう書いています。書き手が言う、メモリーが共有されないという話と、同じ向きなんです。

私の読みです。記憶の置き場をAIの側ではなく、自分の側に持つ。そうすると、AIを替えるときの引っ越しが軽くなるんじゃないかな、と思います。

ブログ『無駄と文化』の記事『自作AIエージェントの開発をやめた』の「使ってもらえる場所に届ける」より（2026年11月5日公開・第4章で引く部分）

普段使っている Claude.ai が突然 分析エージェントとして振る舞いだすのはみんなにとっても面白かったらしく。

普段使っているClaude.aiが、突然、分析エージェントとして動き出す。チームの人が、その様子を面白がってくれた。書き手はそう書いています。

問いは、必要な部分だけをMCPにして、残りを汎用エージェントに任せるのは現実的か、というものです。書き手の場合は、とてもうまく機能しているそうです。

作り直した分析MCPをつなぐと、汎用エージェントが分析エージェント化した感覚だと書いています。

データを表示するUIは、手放しても改善されていく。最近のClaude.aiはClaude Artifactsで、操作できる可視化もしてくれる、と書き手は言います。

認証基盤、メモリー、アセット管理、スキルシステムも、使い慣れた仕組みがそのまま使えます。

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

書き手は、先日チーム内でMCPを共有し、Claude.aiのコネクタとして接続して使ってもらった、と書いています。コネクタは、Claude.aiに外の道具をつなぐ機能のことです。

すると、こんな感じで使ってみました、と活用例がシェアされてきたそうです。ずっと自作を続けていても、この驚きと質は出せなかったと思う、と書き手は振り返っています。

AI氣道『Claude Codeで会員データベースをつなぐMCPと、使いながら直す修正ボタンを動画の相談から整理する』より

「実は、AIに頼んで、UTAGEのMCPで講座のレッスンに動画を入れてもらったことがあります。」

AIに頼んでUTAGEのMCPで講座に動画を入れてもらった話を、私は『Claude Codeで会員データベースをつなぐMCPと、使いながら直す修正ボタンを動画の相談から整理する』で書いています。

実は、AIに頼んでUTAGE（講座を配信するサービス）のMCPで講座のレッスンに動画を入れてもらったとき、動画の部品にvideo_idだけを入れると、受講生の画面で動画が立ち上がりませんでした。

1本中0本です。video_urlに完全なURLを入れると、1本中1本が立ち上がりました。それを測ったのもAIです。つなげば動く、とは限らないんです。

私の読みです。MCPは、つないだあと、使う人の画面で確かめて初めて、詰まりが見えます。書き手の記事は、チームの人が実際に使って、活用例が返ってきた、という形で確かめています。

ブログ『無駄と文化』の記事『自作AIエージェントの開発をやめた』の「分析の手応えとデータ基盤」より（2026年11月5日公開・第5章で引く部分）

当たり前のデータを渡すだけでは当たり前のことしか言わないのが AI だ。

AIは、当たり前のデータを渡されると、当たり前のことしか言いません。書き手の言葉を言い直すと、こうなります。

書き手は最初、BigQueryのexecute_sqlツールをAIにつなげば、良い感じの洞察を語ってくれるのかな、と思っていたそうです。

BigQueryはGoogleのデータ分析用のデータベース、execute_sqlツールはAIにデータへの問い合わせ文を直接実行させる道具です。でも、これは全然違いました。

何の工夫もしなければ、AIは分かりきったことしか言わない。書き手の例が、朝晩は電車が混むようです、冬はおでんが売れるようです、です。たしかに、聞いた瞬間に力が抜けますよね。

分析エージェントとして前進している感覚が得られたのは、次のようなときでした。注目するべき指標をしっかり定義して、チームで合意したとき。注目するべき指標が、日々事前集計されるよう仕組み化したとき。

注目するべき指標が正確になるよう、データの収集方法を見直したとき。

書き手は、これらはどれもAI以前の工程だと言います。データ基盤として当たり前のことを、コツコツやるアクションです。データ基盤は、分析に使うデータを集めて整えて置いておく土台のこと。

私の読みです。いちばん手前にあるのは、何を数えるかを決めて、チームで合意することだと、私は読みました。AIに何をさせるかより先に、AIに何を見せるかを決める。

あなたの仕事で、毎月見ている数字を1つ選んでみてください。その数字の定義を、人に説明できますか？ 説明できるかどうかが、AIに渡す前の最初の確認になります。

ブログ『無駄と文化』の記事『自作AIエージェントの開発をやめた』の「分析の手応えとデータ基盤」より（2026年11月5日公開・第6章で引く部分）

つまり有用な分析エージェントを作るためには有用なデータ基盤が必要で。エージェントなんか作ってる場合ではなかったのだ。

役に立つ分析エージェントには、役に立つデータ基盤が要る。書き手は、そう気づいたと書いています。

では、自作の分析エージェント作りは、全くの無駄骨だったのか。書き手の答えは、実はそうでもない、です。

作るなかで、分析業務に本質的に重要な部分と、汎用の仕組みを使うべき部分が、見分けられるようになったからだそうです。

移行は、引き算で進みました。コードの多くは、分析エージェント時代のものを流用できたとのこと。書き直すときに、整理整頓できたのも良かった、と書いています。

MCPのベースには、FastMCPを使っています。FastMCPは、MCPを作るためのPythonの道具です。

書き手は、Google ADKもFastMCPも、ベースにはFastAPIがあるので、コードがとても似通ったものになる、と説明しています。FastAPIは、Pythonのウェブの道具です。

ドメインモデル、つまり仕事の中身を表すデータの設計の面でも、実装の面でも、移行は難しくなかった。書き手はそう書いています。

私の読みです。作ったものを捨てるのではなく、使える所だけ残して、要らない所を引く。そのやり方なら、自作に使った時間も、むだになりません。

書き手も、自作に時間をかけたからこそ、どこが本質かが分かった、と書いています。

読者の場面に置くなら、こう考えてみてください。いま手元にある下書きや手順を、全部捨てる必要はない。使える部分を残せるかどうかが、乗り換えの重さを決めます。

記事のまとめは、短いです。分析エージェントをやめて、分析MCPを作り動かし始めた。少し遠回りだった気もするが、作って、手放して、分かったことも多かった。書き手はそう締めています。

ブログ『無駄と文化』の記事『自作AIエージェントの開発をやめた』の「3行まとめ」より（2026年11月5日公開・第7章で引く部分）

良い分析体験のキモはエージェントが動く手前にある

推測: 良い分析体験の鍵は、AIが動き出す前の準備にある。書き手の言葉をそう受け取って、ここからは、私の考えを当てはめてみます。

人が先に決めることは、3つあると考えます。何を数えるか、つまり指標の定義。どこに置くか、つまりデータと資料の置き場。何をAIに見せるか。

第5章の書き手が前進を感じたとき、指標の定義と合意、日々の事前集計、収集方法の見直しと、同じ向きです。

たとえば、毎月の問い合わせの件数を見たいとします。件数の数え方を決めておく。問い合わせの記録を置く場所を決めておく。AIに見せる範囲を決めておく。この順番が、AIより前の仕事です。

次は、AIに任せてよい線。手順書づくりは、聞き取り役と点検役にとどめる。外に出る操作の承認は、人が持つ。

AI氣道『Agent Skillsとは。業務手順書の設計8つのコツを風音屋の記事で整理』より

「手順書づくりにAIを使うなら、聞き取り役と点検役にとどめます。外に出る操作の承認は人が持つ。これが私の考えです。」

手順書づくりにAIを使うなら、聞き取り役と点検役にとどめるという考えを、私は『Agent Skillsとは。業務手順書の設計8つのコツを風音屋の記事で整理』で書いています。

手順書づくりにAIを使うなら、聞き取り役と点検役にとどめる。そう書いた私の考えは、MCPで道具をつなぐときにも、同じに使えるんじゃないかな、と読みます。AIが下書きと棚卸しをして、人が決める。

外に出る操作の承認は、人が持つ。

推測: 自作か、つなぐかで迷ったら、次のように分けて言えるかを確かめます。1つめは、自分で作るもの。本質の部分です。2つめは、既存のAIに任せるもの。画面やログイン、記憶の部分です。

3つめは、AIより前に整えるもの。指標の定義やデータの取り方、置き場の部分です。

あなたが今ある仕事を1つ選ぶなら、確かめることは2つです。AIに渡す情報の置き場が整っているか。AIに任せるのを棚卸しと下書きまでにして、決める所を自分に残せているか。どちらから始めても大丈夫です。

ブログ『無駄と文化』の書き手は、データ分析用のAIエージェントの自作をやめて、分析MCPに作り直しました。自作すると、UI、認証、セッション、メモリーなど8つの部品を背負います。中でもメモリーは難所で、普段使うAIと共有されないことが乗り換えの障壁になりうる、と書かれています。

汎用エージェントにMCPをつなぐと、書き手の場合はとてもうまく機能しました。ただ、分析で前進した感覚が得られたのは、指標を決め、日々まとめ、収集方法を見直したときです。データ基盤が先。作って、手放して、分かったことも多かった、という締めが印象に残りました。

私の読みでは、つないだあとに使う人の画面で確かめること、AIを増やすほど文脈の置き場が要ること、手順書づくりのAIは聞き取り役と点検役にとどめること。これらが、書き手の話と同じ向きでした。

推測: 自作かつなぐかで迷ったら、自分で作るもの、既存のAIに任せるもの、AIより前に整えるものに分けて言えるかを確かめます。あなたの今ある仕事を1つ選び、AIに渡す情報の置き場が整っているかを見るか、AIに任せるのは棚卸しと下書きまでにして決める所を自分に残すか。どちらか一方から始められます。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！