Tied Inc.

AIエージェント・MCPとは何か:LLMが「道具を使う」仕組みの基礎

Tied株式会社 Read in English

AIエージェントとは、LLM(大規模言語モデル)が自らの判断で外部のツールやデータソースを呼び出しながら、複数ステップの作業を自律的に遂行する仕組みです。 単に質問に答えるチャットボットとは異なり、「検索する」「計算する」「予定を登録する」といった行動を実行できる点が本質的な違いです。そして、エージェントが多種多様なツールに安全かつ効率的につながるための標準規格として登場したのが MCP(Model Context Protocol)です。

AI導入を検討する経営者・推進担当者にとって、「エージェント」「function calling」「MCP」という言葉はセットで語られることが多いものの、それぞれが指す範囲は異なります。専門用語を正確に押さえておくことは、ベンダーの説明を鵜呑みにせず投資判断を下すための技術リテラシーの基礎でもあります。本稿ではこの3つを切り分けながら、業務のどこまでが自動化でき、どこにリスクが残るかを整理します。

チャット・ワークフロー・エージェントの違い

AIを使った業務自動化には、自律性のレベルが異なる3つの形態があります。混同すると導入判断を誤るため、まず区別します。

形態何をするか判断の主体典型例
チャット1回の入力に対して1回の応答を返す人間(次に何をするか毎回決める)ChatGPT・Claudeへの質問応答
ワークフロー(自動化)あらかじめ決められた手順を順に実行する設計者(分岐条件は事前に固定)「メール受信→分類→通知」のRPA的処理
エージェント目標だけを与えられ、手順そのものをLLMが都度組み立てるLLM(次のツール呼び出しをその場で決定)「今月の問い合わせを集計してSlackに要約を投稿して」を1つの指示で完結させる

ワークフローとエージェントの境界線は「分岐や手順をあらかじめ人間が書いたか、実行時にLLMが決めたか」にあります。ワークフローは再現性が高く挙動を予測しやすい一方、想定外の入力に弱いという特性があります。エージェントは未知のパターンにも対応できますが、その分「次に何をするか」が実行してみるまで完全には予測できません。この予測可能性とのトレードオフが、後述する導入リスクの核心になります。

ツール呼び出し(function calling)の仕組み

エージェントが「道具を使う」ための土台になる技術が function calling(ツール呼び出し、tool use とも呼ばれます)です。仕組みは次の3ステップで説明できます。

  1. ツールの登録:開発者は「このツールは何ができ、どんな入力を受け取るか」をLLMに事前に説明します(例:「search_orders(customer_id) は顧客IDから注文履歴を返す」)。
  2. 呼び出しの判断:ユーザーの指示を受けたLLMは、登録されたツールの説明文を読み、目的達成に必要なツールと引数を自ら選び、呼び出しリクエストを生成します。この時点でLLM自身がコードを実行するわけではなく、「このツールをこの引数で呼んでほしい」という構造化されたリクエストを出すだけです。
  3. 実行と結果の受け渡し:アプリケーション側が実際にツールを実行し、結果をLLMに返します。LLMはその結果を踏まえて次の行動(別のツール呼び出し、または最終回答)を決めます。

このループ(判断→呼び出し→結果受領→再判断)を必要な回数繰り返すことで、単純な一問一答では処理できない複数ステップのタスクが完結します。ここまでは各AIモデル提供企業が個別に実装してきた仕組みで、LLM組み込み時のアーキテクチャ選択(API利用・RAG・Fine-tuning等)とも関わりがあります。詳細な判断軸はLLM/AIをプロダクトに組み込む際のアーキテクチャ判断軸で解説しています。

MCPがない場合:個別接続(M×N問題) LLM A LLM B LLM C 検索ツール 社内DB カレンダー 組み合わせごとに個別実装が必要 MCPがある場合:共通プロトコル経由 LLM A LLM B LLM C MCP 検索ツール 社内DB カレンダー 1つの実装を使い回せる
図1:MCPはLLMとツールの接続を標準化し、組み合わせ爆発(M×N問題)を回避する

MCP(Model Context Protocol)とは何か:標準化が意味すること

上の図で示した通り、MCPが登場する前は「どのLLMを、どのツールに、どうやって接続するか」をモデル提供企業やツールごとに個別実装する必要がありました。LLMがM種類、接続したいツールがN種類あれば、最大でM×N通りの接続コードが必要になる、いわゆる「M×N問題」です。

MCPは、Anthropicが2024年に公開したオープンな標準規格で、LLM(クライアント側)とツール・データソース(サーバー側)の接続方式を統一します。ツール開発者は「MCPサーバー」を1つ作れば、MCPに対応した任意のLLMアプリケーションから利用できるようになり、LLM提供企業は「MCPクライアント」を1つ実装すれば、MCPに対応した任意のツールにつながります。USB規格が周辺機器とパソコンの接続を統一したのと似た役割だと考えると理解しやすいでしょう。

事業上の含意は2つあります。

1. 統合コストの低下:自社の業務システム(顧客DB、会計ソフト、社内Wiki等)をAIエージェントに接続する際、個別のAPI連携を都度開発する必要が薄れます。MCP対応のコネクタが増えるほど、導入時の開発工数は減っていきます。

2. ベンダーロックインの緩和:特定のLLM提供企業向けに接続コードを書き込む必要がなくなるため、将来別のLLMに切り替える際の移行コストが下がります。これはAPI・SDKの標準化が契約・調達戦略に与える影響と同じ構造の論点です。詳しくはAPI・SDK・OSS:用語の正確な理解と契約・知財上の含意で扱っています。

ただし、標準化は「接続のしやすさ」を保証するだけで、「安全な使い方」までは保証しません。次章で扱う権限設計は、MCPを使う場合でも使わない場合でも同様に必要です。

業務への影響:何が自動化でき、何が人に残るか

エージェントが得意な業務と、人が判断を残すべき業務は明確に分かれます。

自動化に向く業務の特徴

  • 判断基準が言語化・パターン化できる(「この条件ならこの分類」)
  • 誤りが発生してもリカバリーコストが低い(下書き作成、一次分類、要約)
  • 参照系(読む・検索する・まとめる)が中心で、実行系(書き換える・送信する・決裁する)を伴わない

人の判断を残すべき業務の特徴

  • 誤りが金銭・契約・対外的信用に直結する(請求処理、契約送付、顧客への確定回答)
  • 判断基準が状況依存で言語化しきれていない(過去の商習慣、個別の力関係を踏まえた交渉判断)
  • 前例のない例外処理(マニュアル化されていない初めてのクレーム対応等)

実務上の目安としては、「参照系のタスクから自動化を始め、実行系のタスクは人の承認ステップを挟んで段階的に拡張する」という順序が事故を防ぎます。中小企業がどの業務から着手すべきかの判断枠組みは中小企業のAI活用はどこから始めるか:経営者のための全体像と進め方に整理しています。

導入時のリスク:権限・誤操作・監査

エージェントに実行系のツールを接続する際、特に確認すべきリスクは3つです。

1. 権限のスコープ:エージェントに与えるツールの権限は、そのタスクに必要な最小限にとどめるのが原則です。「顧客情報を検索するエージェント」に誤って「顧客情報を削除できる権限」まで付与してしまうと、意図しない指示や誤動作が実害につながります。ツールごとに「読み取り専用」「書き込み可」を明示的に分離して設計します。

2. 誤操作・暴走の許容範囲:LLMは確率的に出力を生成するため、まれに意図と異なるツール呼び出しを行うことがあります。金額や送信先を伴う実行系の操作には、一定の閾値を超えたら人間の承認を必須にする、実行前に確認画面を挟む、といったセーフティネットが必要です。

3. 監査ログ:「いつ、どのエージェントが、どのツールを、どんな引数で呼び出したか」を記録・追跡できる仕組みがなければ、問題が起きた際に原因を特定できません。特に複数のツールを連鎖的に呼び出すエージェントでは、途中経過のログを残すことが事後検証の前提条件になります。

これらは目新しいリスクというより、システム権限管理の基本原則(最小権限の原則、承認フロー、監査証跡)をAIエージェントという新しい実行主体に適用し直したものです。裏を返せば、既存のアクセス権限設計がしっかりしている組織ほど、エージェント導入のハードルは低くなります。

まとめ:エージェントの自律性は「便利さ」と「予測不能性」のトレードオフ

AIエージェントとMCPは、AIが「答えるだけの存在」から「行動する存在」へと役割を広げる基盤技術です。要点を整理します。

  • チャット・ワークフロー・エージェントは自律性のレベルが異なり、混同すると導入判断を誤る
  • function calling はLLMがツールを呼び出す基本メカニズムで、判断→呼び出し→結果受領のループで複数ステップの作業を実現する
  • MCP はLLMとツールの接続方式を標準化し、統合コストとベンダーロックインを下げるが、安全性そのものを保証するものではない
  • 導入は参照系から始め、実行系は権限設計・承認フロー・監査ログを整えてから拡張するのが安全な順序

「どの業務から着手すべきか」「権限設計をどう組むべきか」の具体的な判断は、業務内容や既存システムの構成に依存します。現場伴走型技術支援(embedded consulting)では、こうした個別の技術判断を実際の業務データを見ながら一緒に設計します。導入を検討する際はお問い合わせからご相談いただくか、投資先・買収先のAI活用状況を評価したい場合は投資家向けTiedPro、自社プロダクトへのAI組み込みを検討中のスタートアップの方はスタートアップ向けTiedProもご覧ください。


よくある質問

Q. AIエージェントとチャットボットは何が違いますか?

チャットボットは「会話の中で回答する」だけですが、AIエージェントは「与えられた目標に向けて自らツールを呼び出し、複数ステップの作業を遂行する」点が異なります。会話の応答で完結するか、外部への行動(ツール呼び出し)を伴い状態を変化させるかが分岐点です。

Q. MCPを導入すれば自動的に安全になりますか?

なりません。MCPはツール接続の方式を標準化するプロトコルであり、権限管理・監査ログ・誤操作対策そのものは別途設計する必要があります。むしろ接続が容易になる分、権限設計を怠ると事故の範囲が広がるリスクがあります。

Q. 中小企業がAIエージェントを導入する際、最初に確認すべきことは何ですか?

そのエージェントが「参照だけできるツール」と「実行・変更ができるツール」のどちらに接続されているかです。参照系(検索・要約)から始め、実行系(送信・更新・決裁)は承認フローを挟んでから拡張するのが安全な順序です。

Tied株式会社

Tied株式会社

技術経営の専門家による技術支援サービス。スタートアップから成長企業まで、技術戦略の策定から実装、チーム構築まで包括的にサポートします。

お問い合わせはこちら →