“エージェントと一緒に作業する” 環境を作った話
- 5月11日
- 読了時間: 20分
こんにちは。NABLASです。
この技術ブログでは、一緒に作業できるエージェントを開発するにあたって、どういう構成のMCPサーバーを構築してどういう結果が得られたかに注目して書いていきます。特に、「MCPサーバーはよく聞くけど、具体的に何ができるの？」といった方へエージェント＋MCPサーバーの「キモチ」が説明できればと思います。
ここでいうエージェントは、雑に言うならツール付きのLLM、丁寧に言うと、ユーザーの指示に応じて必要なツールを選びながら作業を進めるLLMベースの実行主体です。エージェントは、ファイル操作や検索、分析、資料作成などをツール経由で実行し、結果を踏まえて次の行動を組み立てます。こうしたエージェントにMCPサーバーを接続することで、外部の専用機能も同じように呼び出せるようになります。
MCP（ Model Context Protocol ）サーバーはエージェント用のRPC（ Remote Procedure Call ）サーバーのような存在で、これを使うと既存のエージェントを拡張して新たなツールを外部提供できるようになります。MCPサーバー自体は裏側の仕組みとなっており、エージェント目線だとただツールが増えたように見えます。既存のエージェント部分のコードを大きく変えることなく、エージェントと新規ツールを分離できるので、メンテナンス性を向上させる効果もあると思っています。
実装の全体像
MCPサーバーはすべて自前で構築し、Azure上で運用しています。今回構築したのは次の4種類です。①弊社で開発したVLM・ツールを組み込んだSNS関連MCPサーバーと②因果推論MCPサーバー、③同じく弊社で開発したLLMを活用したファクトチェックMCPサーバー、そして自社テンプレートを用いた④PowerPointスライド生成MCPサーバーです。
以下の図は、今回紹介するシステムの全体図です。ユーザーから指示を受けたエージェントは、必要に応じてツールを呼び出し、その結果をもとに処理を進めます。
補足
簡単のためファイル編集など汎用的なツールは省いていますが、この他にもいくつかエージェントが使えるツールが存在します。また、スクリプトの実行など危険な可能性がある処理はE2Bサンドボックス内で行います。
次のセクションからは各MCPサーバーの構成と機能について一つずつ説明していきます。
スライド生成MCPサーバーの実装
何ができるようになるか
一番機能がわかりやすいスライド生成MCPサーバーから紹介していきます。これはスライドの概要を受け取り、それに沿ったPowerPointファイルを出力します。エージェントをこのMCPサーバーに接続すると、ユーザーはスライドの自動生成が行えるようになります。テンプレートを自由に指定でき、それに応じたスライドを自動生成できます。以下の図は処理の流れを示しています。
処理の流れ
プランニング → 画像の生成（or 取得）→ 中間表現の生成→ PowerPointファイルの出力の順に処理が進みます。プランニングでは概要（ focus ）とスライド枚数（ slide_count ）を受け取り、各スライドの内容とテンプレートID（ suggested_layout_ref ）などを出力します。ここでは各要素の位置関係の調節やレイアウトへの実際の当て込みは行われず、それらの処理は後段のコンパイラが行います。プランニングの入出力例を示します。
{
"step": 1,
"round": 1,
"tool_name": "plan_slide_flow",
"arguments": {
"focus": "educational flow with varied layouts for chapter 5 overview",
"slide_count": 5
},
"output": {
"storyline": "第5章の導入から具体策、実験運用、実務での着地点までを5枚で整理し、少数NG環境では“派手なモデル変更”より“現実的な改善の積み上げ”が重要だと伝える構成。あわせて、比較・要約・強調などでレイアウトを切り替え、自動生成でも表現に幅が出せることを示す。",
"slides": [
{
"slide_number": 1,
"title": "第5章 少数NGで伸ばす",
"purpose": "章の導入としてテーマと学習ゴールを提示する",
"key_points": [
"派手な改造より小さな改善",
"改善対象は学習条件と運用条件",
"実験管理まで含めて考える"
],
"suggested_layout_ref": "tmpl_layout_00"
},
{
"slide_number": 2,
"title": "まず効く改善の地図",
"purpose": "少数NG環境で優先して試す改善領域を俯瞰させる",
"key_points": [
"事前学習の活用",
"augmentationの見直し",
"oversamplingとhard negative",
"損失関数と閾値調整"
],
"suggested_layout_ref": "tmpl_layout_27"
},
{
"slide_number": 3,
"title": "AugmentationのOK / NG",
"purpose": "有効な拡張と避けるべき拡張を対比で理解させる",
"key_points": [
"OK: 照明・位置ずれ・ノイズなど現場変動",
"NG: 欠陥の意味を壊す強い変形",
"現場再現性を基準に選ぶ"
],
"suggested_layout_ref": "tmpl_layout_19"
},
{
"slide_number": 4,
"title": "再学習で効く追加データ",
"purpose": "hard negativeとoversamplingの使いどころを整理する",
"key_points": [
"誤検知例をhard negativeとして追加",
"NGはoversamplingで学習機会を確保",
"過学習を避けて分割と履歴を管理"
],
"suggested_layout_ref": "tmpl_layout_17"
},
{
"slide_number": 5,
"title": "現場での改善ループ",
"purpose": "章のまとめとして実務的な実験サイクルに落とし込む",
"key_points": [
"小さく試して差分を記録",
"評価は見逃しと誤報で確認",
"閾値調整は運用フロー込みで決める"
],
"suggested_layout_ref": "tmpl_layout_25"
}
]
}
}
次のステップではスライドで使用する画像の生成 or 取得を行います。生成 or 取得は引数で指定されるようになっていて、生成なら gpt-image-2 、取得なら Pixabay から画像を用意します。画像のアスペクト比も指定できるようになっています。画像の生成例を示します。
{
"step": 2,
"round": 2,
"tool_name": "openai_generate_image",
"arguments": {
"prompt": "Clean slide illustration for a training course on object detection with MMDetection in manufacturing inspection. Theme: improving detector training in a rare-defect environment. Show a detector pipeline with small practical tuning knobs such as pretrained model, augmentation, sampling, loss, and threshold. Modern flat infographic style, blue and orange accents, white background, no text labels, presentation-ready.",
"file_stem": "chapter5_overview",
"aspect_ratio": "1:1"
},
"output": {
"ok": true,
"prompt": "Clean slide illustration for a training course on object detection with MMDetection in manufacturing inspection. Theme: improving detector training in a rare-defect environment. Show a detector pipeline with small practical tuning knobs such as pretrained model, augmentation, sampling, loss, and threshold. Modern flat infographic style, blue and orange accents, white background, no text labels, presentation-ready.",
"mime_type": "image/png",
"label": "Clean slide illustration for a training course on object detection with MMDetection in manufacturing inspection. Theme: improving detector training in a rare-defect environment. Show a detector pipeline with small practical tuning knobs such as pretrained model, augmentation, sampling, loss, and threshold. Modern flat infographic style, blue and orange accents, white background, no text labels, presentation-ready.",
"model": "gpt-image-2",
"provider": "openai",
"size": "1024x1024",
"quality": "medium"
}
}
次はプランニングの結果をもとに、中間表現を生成します。中間表現はXML形式で表されます。各スライドはレイアウトIDと各要素の値を持っています。
<slide id="s01" layoutRef="tmpl_layout_00">
<text id="s01_title" slot="title">
<p bullet="false" level="0">
<span>第5章 少数NG環境での学習改善</span>
</p>
</text>
<text id="s01_subtitle" slot="subtitle">
<p bullet="false" level="0">
<span>派手なモデル変更より、事前学習・拡張・サンプリング・損失・閾値の積み上げが効く</span>
</p>
</text>
</slide>
中間表現をもとに、コンパイラが最終的なPowerPointファイルへのレンダリングを行います。コンパイラはその際に要素の細かい位置調整を行ったり、対応するスライドへの画像の当て込みを行ったりします。
SNS関連MCPサーバー
何ができるようになるか
SNS関連MCPサーバーについて、これはその名の通り、SNSに関するさまざまなツールをまとめたMCPサーバーです。ここでは、SNSそのものをリアルタイムに検索するのではなく、まず収集用のバッチで投稿の統計値を継続的に取り込んでベクトルDBに蓄積します。各ツールからはベクトルDBにアクセスしてデータを取得できます。
補足
各SNSプラットフォームの規約に配慮し、本実装では投稿本文そのものを恒久保存して検索対象にするのではなく、統計値・構造化情報のみを収集対象としています。
補足
今回の実装では、cl-nagoya/ruri-v3-130m を埋め込みモデルとして使用させていただきました。
以下の図は、SNS関連MCPサーバー上の利用可能なツール群とエージェントとの関係性を単純化して示した図です。ユーザーはエージェントを通してSNSに関するさまざまな作業を行えます。
構成
エージェントから呼び出せるツールとして、主に次のものを用意しました。sns_searcher は保存済みDB上で意味検索とキーワード検索を行えます。sns_flux_meter は日次の投稿数推移を取得することができるツールで、キャンペーン前後の話題量比較に向いています。sns_co_graph は商品名や評価表現から名詞・形容詞の共起語を集計できるツールで、周辺でどのような言葉が一緒に語られているかを把握するためのツールです。sns_hot_spot_finder はメトリックの値が上位の投稿を抽出し、反応の大きかった投稿を確認できるツールです。いずれも条件指定で絞り込めるため、「どういう文脈で話題か」まで追える構成にしました。
たとえば、新商品の反応を見たい場面では、「今月のチョコレート菓子に関する投稿を調べ、投稿数の推移とよく一緒に語られる表現、反応の大きかった投稿を見せて」といった依頼をエージェントに渡せます。するとエージェントは、まず sns_flux_meter で日次推移を取り、次に sns_co_graph で「濃厚」「甘さ控えめ」「コンビニ」といった周辺語を確認し、最後に sns_hot_spot_finder でエンゲージメント上位の投稿を抽出するといった流れで処理できます。あるいは、特定の商品カテゴリについて sns_searcher を使ってDBを検索し、そのまま後続の分析ツールやレポート生成ツールに渡すこともできます。保存済みデータを検索対象にしているため、処理結果を再現しやすく、社内分析フローに組み込みやすい点も実運用上の利点です。
実行例
ここでは、以下のプロンプトでホワイトデー前後の「チョコレート」に関する投稿数の推移をプロットしてみます。
2026年3月のチョコレートのお菓子に関する投稿に関して、投稿数の推移を調査してみて。さらに、ホワイトデーの影響が出てるか見たいのでトレンド成分も重ねてプロットしてみて。
すると、以下のような図が生成されました。この月だけでの簡易的な比較ですが、ホワイトデー後に徐々に投稿数が下がっていそうな傾向が読み取れます。
以下に最終返答の要約を示します。ホワイトデーの影響を断定するのではなく、2026年3月のチョコレート菓子関連投稿の日次推移から、ホワイトデー前後に話題量が高まる傾向がみられたことが言及されています。
## 2026年3月のチョコレート菓子関連投稿に見るホワイトデー前後の話題量 2026年3月のチョコレート菓子関連投稿を日次で集計し、ホワイトデー前後に投稿数がどのように変化したかを確認しました。 今回は、投稿数を生活者の関心量の近似指標として扱い、日次投稿数に加えて7日移動平均を重ねることで、短期的なブレをならしたトレンドも確認しています。  --- ## 集計方法 当初はチョコレート菓子に絞った検索条件で取得を試みましたが、十分な件数が得られなかったため、今回は関連語をやや広げて集計しました。 対象とした表現は、主に以下です。 * チョコ * チョコレート * ショコラ * ホワイトデー お菓子 そのため、本分析は「チョコレート菓子カテゴリを厳密に分類した集計」ではなく、チョコレート菓子周辺の話題量を広めに捉えた分析です。 --- ## 集計結果 2026年3月の投稿数は、全体で以下のようになりました。 | 指標 | 値 | | -------- | -----------: | | 総投稿数 | 484件 | | 1日平均 | 15.6件 | | 月内最大 | 3/7・3/8 各32件 | | ホワイトデー当日 | 3/14 30件 | 月内最大は3/7・3/8で、ホワイトデー当日ではありませんでした。一方で、3/12以降に投稿数が再び増加し、3/14にも30件の投稿が確認されています。 期間別に見ると、以下の通りです。 | 期間 | 平均投稿数 | | --------- | ------: | | 3/1〜3/11 | 17.3件/日 | | 3/12〜3/16 | 19.4件/日 | | 3/17〜3/31 | 13.1件/日 | ホワイトデー前後の3/12〜3/16は、月後半の3/17〜3/31と比べて高い水準でした。 このことから、ホワイトデー前後にチョコレート菓子関連の話題量が持ち上がっていた可能性があります。 --- ## トレンドの解釈 日次投稿数だけを見ると、3/7・3/8のような単発の山も目立ちます。そこで7日移動平均を確認すると、3/14〜3/17付近にかけて緩やかな山が見られました。 これは、ホワイトデー当日に一日だけ投稿数が増えたというよりも、数日前から話題量が高まり、当日を挟んで数日間は高めの水準が続いたことを示唆しています。 マーケティング施策の観点では、ホワイトデー当日だけではなく、3/10〜3/14あたりの直前期間に露出や訴求を厚めにする余地があると考えられます。 --- ## 注意点 今回の集計では、関連語を広めに設定しているため、純粋なチョコレート菓子だけでなく、周辺の話題も含まれている可能性があります。 また、月内最大の投稿数は3/7・3/8であり、3月の話題量全体がホワイトデーだけで決まっているわけではありません。週末要因、別キャンペーン、商品発売、SNS上の一時的な話題化などが混ざっている可能性があります。 そのため、本分析から言えるのは、ホワイトデーが投稿数を押し上げたと断定することではなく、**ホワイトデー前後にチョコレート菓子関連の話題量が高まる傾向が観察された**という点です。 --- ## まとめ 2026年3月のチョコレート菓子関連投稿では、3/7・3/8に月内最大の山がありつつ、ホワイトデー前後の3/12〜3/16にも投稿数の持ち上がりが確認されました。 7日移動平均でも、3/14〜3/17付近にかけて緩やかな山が見られたため、ホワイトデーはチョコレート菓子関連の話題量を高める一因だった可能性があります。 ただし、検索語を広めに設定していることや、他の要因を統制していないことを踏まえると、これは因果効果の推定ではなく、投稿トレンドの観察結果として解釈するのが適切です。
因果推論MCPサーバーの実装
何ができるようになるか
このMCPサーバー上には因果推論に関するさまざまなツールが実装されており、これらを使用すると、ある対象の因果効果を推定することができます。例えば、ある広告を特定のプラットフォームで配信する前後のある商品の売り上げデータを使い、その広告の施策効果がどれほどだったかを推定することができます。現在、DiD（差分の差分法）、CausalImpact、MMM（マーケティングミックスモデリング）などのツールが実装されています。以下の図は処理の流れを示しています。
処理の流れ
各ツールにはテンプレートが用意されており、このテンプレートにデータのパスやハイパーパラメーターの値などを設定することでPythonスクリプトが完成するようになっています。PythonスクリプトはE2Bサンドボックス内で実行され、結果の要約がエージェントに返されます。
重要な点として、因果推論を用いるときにはただ手法を適用するだけでなく、DAGの妥当性・識別仮定・結果の信頼性などから総合的に結果を評価する必要があります。この目的を達成するため、今回はMCPサーバーに加えて、Agent Skills を使ってエージェントの動作をコントロールできるようにしました。スキルには、データ分析を行う際に従うべき行動規範が記載されており、これを参考に行動を決定することで、専門家によるデータ分析を忠実に再現できるようになっています。また、各ツールの説明文には使用してよい状況・使用すべきでない状況・注意点などが記載されており、エージェントはそれらも考慮した上で使用するツールを決定したり、使用結果を評価します。
実行例
以下のプロンプトでMMMを自動で適用した例を示します。ここでは以下のような簡易的なデータを作成して使用します。
このデータに対し、以下のプロンプトを使用します。すると、エージェントはEDA→識別仮定の確認→データセットの作成→MMMの適用→結果の解釈という流れで動作し、TV・Webの広告への投資に対する収益関係性をどう解釈すればよいと思われるかを要約して返します。
結果変数y、TVへの投資tv、ウェブへの投資web、日時date_weekを含むこのデータセットに対し、MMMを使ってTVとWebの結果変数への因果効果を分析してください。
以下に最終返答の要約を示します。結果を言い切るのではなく、MMMの分析例として、チャネル別の寄与、ROI、効果の持続性をどのように読み解けるかが説明されています。
## 説明変数を絞ったデモデータによるMMM分析例 今回は、週次データに対してMMM（Marketing Mix Modeling）を適用し、TV投資とWeb投資が成果変数 `y` に与える影響を推定しました。 本分析は、説明変数を絞ったデモデータによる分析例です。価格、販促、競合動向、在庫、季節イベントなどの変数は十分には含まれていないため、実運用レベルの精密な因果推定ではなく、MMMの出力と解釈の流れを示すことを目的としています。 --- ## 分析結果 推定された成果への寄与は、TVが **6.7%**、Webが **4.7%** でした。 この結果だけを見ると、TVの方がWebよりも成果への押し上げはやや大きいと解釈できます。 一方で、`trend` の寄与は **70.6%**、`intercept` は **17.0%** でした。つまり、成果の大半は広告ではなく、ベース需要や全体トレンドによって説明されています。 支出割合は、TVが **58.6%**、Webが **41.4%** でした。TVの方が投資額も大きく、その分だけ成果への寄与もやや大きい結果です。 ただし、推定ROIはTV・Webともに **1.21** であり、効率面では大きな差は見られませんでした。総効果ではTVがやや上回るものの、費用対効果はほぼ横並びです。 広告効果の出方については、TVは即時効果が中心、Webはキャリーオーバー効果が大きいという結果になりました。 | チャネル | 即時効果 | キャリーオーバー効果 | | ---- | ---: | ---------: | | TV | 98% | 2% | | Web | 29% | 71% | ただし、この推定はデータ構成やモデル仕様の影響を受けるため、チャネル特性として強く一般化するには注意が必要です。 --- ## モデルの当てはまり モデルの当てはまりは以下の通りです。 | データ区分 | Adjusted R² | | ---------- | ----------: | | train | 0.8917 | | validation | 0.8869 | | test | 0.5451 | 学習データ・検証データでは高い説明力が得られましたが、テストデータでは説明力が中程度まで低下しています。 そのため、過去データの傾向は一定程度捉えられている一方で、未知期間への再現性には改善余地があります。  --- ## 解釈 今回のデータでは、TVはWebよりも成果への寄与がやや大きい結果になりました。一方で、ROIは両チャネルでほぼ同水準であり、Webを大きく削ってTVへ寄せるほどの明確な差は見られません。 また、成果の大半は広告以外のベース要因で説明されており、テストデータでの再現性も中程度です。 したがって、この結果は「TVがWebより明確に優れている」と結論づけるものではなく、**TVがやや優位に見えるものの、大きな予算変更ではなく小さな再配分で追加検証するのが妥当**、という方向感として捉えるのが適切です。
今回はデモ用に説明変数を絞った簡略データを用いているため、実運用レベルの予測精度や因果解釈を目的としたものではありません。そのため、Actual vs Predicted では全体傾向はある程度追えているものの、ピークや一部の変動は十分に再現できていません。本稿では、MMMにより「各チャネルの貢献度」「支出シェアと効果シェア」「キャリーオーバー効果」「ROAS」などをどのように可視化・解釈できるかを示すことを主目的としています。実データでは、価格、販促、競合、季節性、在庫、外部イベントなどを追加することで、より妥当なモデル化および結果の解釈が行えると思われます。
ファクトチェックMCPサーバーの実装
何ができるようになるか
このMCPサーバーに接続すると、真偽の不明な主張のファクトチェックを行えます。主張は自然文で表され、それを受け取ったエージェント（ここでいうエージェントはMCPサーバー上で動作するいわゆるサブエージェントです）はWeb情報を参考にファクトチェックと証拠の収集を行います。ファクトチェックの結果は真偽の2値だけでなく、不明といった中間値も生成できるようになっています。以下の図は、ファクトチェックMCPサーバーの処理の流れを表す図です。
補足
ここで使用されるLLMはHugging Face上でGGUF形式のオープンウェイト（Q4_K_M）としても公開されており、llama.cppなどで利用可能です。
処理の流れ
主張を受け取ったエージェントは以下のように3つの検索クエリを生成します：①もとの主張、②短縮版の主張、③短縮版の主張の最後に「ファクトチェック」という文字列を追加したもの。以下は①②③の例です。
① 東京は日本の首都である。大阪は日本の首都ではない。 ② 東京は日本の首都である ③ 東京は日本の首都である ファクトチェック
次に、各検索クエリをもとにWeb検索を行って情報を収集します。その際、本文の適切な抽出などの前処理を行います。その後、LLMによりファクトチェックを行います。LLMは結果（ verdict ）、結果の要約（ summary ）、収集した情報から得られる証拠（ evidence ）の3つをJSON文字列で返します。<think> タグとそれで囲われたエリアはこの時点で除去されます。以下は、東京は日本の首都である。大阪は日本の首都ではない。 という主張に対する実際の出力です。
補足
実際には、これらの値に加えてソースも返されます。これにより、（メイン）エージェント側で再検証もできる構成になっています。
{
"verdict": "Yes.",
"summary": "東京は日本の首都と広く認識されているが、法律上は明確に定義されていない。一方、大阪は首都ではない。",
"evidence": [
"日本語版ウィキペディアによると、東京と京都が並立する帝都であり、本来の首都は京都であるとされる。",
"毎日新聞の記事では、東京が日本の首都であると認められているが、正式な法律は存在しない。",
"参議院法制局の資料では、首都を定める法律はなく、東京が事実上の首都とされている。",
"QuizKnockの記事では、東京を首都とする法律は存在せず、法律上は首都と認められていない。",
"京都Loveの記事では、法律上は東京が首都と定義されておらず、首都の定義は曖昧であると指摘されている。"
]
}
その他のMCPサーバーの実装
他には、NotionのMCPサーバーを構築しました。公式でも提供されていますが、ここでは、ブロックごとに細かく作業できるような構成にしてみました。上の動画では、あるNotionページに対してブロックごとにレビューコメントを追加しています。ここでは簡単な例を紹介しましたが、ページの編集など、もう少し入り組んだ作業も行えます。
また、あるコンセプトを説明したい場合（機械学習とは？を説明したい場合など）、動画で視覚的に説明できると便利な場面が多いため、そのような説明動画を自動生成するMCPサーバーも作りました。先ほどのスライドの自動作成の場合と同じように、モデルは中間表現を生成します。すると、コンパイラが位置決めを行った後に、指定された内容とレイアウトにしたがってレンダリングして動画を出力します。上の例では、PDCAを簡易的に説明する動画を自動生成してみました。
APIが提供されていないサービスに関しても、高速で立ち上がる仮想デスクトップを提供するE2B Desktop Sandboxなどを使うことでComputer Useを通したMCPサーバー化にも取り組む予定です。クリックやスクロール、インストール済みアプリの立ち上げ、ブラウザ操作、エディター操作など一般的な処理を行うことができます。
社会実装としての価値
さまざまなサービスがMCPサーバーを通してエージェントが利用可能な形で実装でき、その数を増やすほどエージェントができることが増えていきます。業務で使うサービスをエージェント側でも利用可能にできれば、人間が行っていることと同じようなこと（またはレビューなどのサポート）ができるようになり、業務効率化や人間の負担減につながります。
弊社では、モデルの開発に留まらず、サービスのMCPサーバー化を通したシステム統合やエージェントの実運用まで含めて取り組んでいます。また、長年のコンサルの経験を生かしてKPIの設計や初期目標の設定など「ガワ」を含めての総合的なエージェントの社会実装を目指しています。
限界と今後の展望
「その他のMCPサーバーの実装セクション」でもあったように、APIの提供されていないサービスの接続については対応できておらず、まだ課題があるようにも思います。具体的な懸念点としては、UIやシステムの複雑性からくる精度の低下問題のみならず、画像ベースで行動を決めるので大量のトークンを消費してしまうことも挙げられます。
また、OpenClawの人気で顕著になったように、悪質なプロンプトをコンテキストに紛れ込ませられるなど、セキュリティの課題も残されています。一方で、フォームへの書き込み・送信など危険性がある処理を実行したい場合は毎回人間に許可をもらう設計にもできますが、Tool Callの回数が多くなるにつれ、人間側が毎回許可する設計だと使いづらくなってしまう可能性があります。
