GPT検索系MCP徹底解説：o3-search-mcpからagents-mcpまでコードレベルで比較検証

はじめに

Claude CodeやCursorなどのAIコーディングアシスタントをさらに賢くするために、MCP（Model Context Protocol） を活用している開発者は多いでしょう。特に、モデルが外部の最新情報にアクセスできないという弱点を補う「検索系MCP」は非常に強力です。

しかし、GitHubで「MCP」と検索すると、o3-search-mcp、openai-responses-mcp、openai-websearch-mcp、そして最近話題のopenai-agents-mcpなど、類似のツールが複数見つかります。これらは一体何が違い、どれを使えば良いのでしょうか？

本記事では、これらの「GPT検索系MCP」ツールを実際にクローンし、コードレベルで徹底的に比較検証します。各ツールのアーキテクチャの違いから、file_searchやcomputer_useといった先進的な機能の真実まで、詳細に解説していきます。

TL;DR（結論から知りたい人へ）

手軽にWeb検索を使いたいだけなら：o3-search-mcpが最もシンプルで実績もあり、現実的な第一候補。openai-responses-mcpやopenai-websearch-mcpも同様の目的で利用可能。
GUI操作の自動化など、未来の機能を試したいなら：openai-agents-mcpが唯一の選択肢。ただし、これは「開発者が用意した環境」を操作するものであり、ローカルPCを直接操作する魔法のツールではない。
ローカルファイルの検索はどのツールでも直接はできない：openai-agents-mcpのfile_searchも、事前にOpenAIにファイルをアップロードする必要がある。

1. 各ツールの概要とアーキテクチャ比較

まず、今回比較する4つのツールの概要と、それらがどのOpenAIの技術を基盤にしているかを整理します。

ツール名	主要ライブラリ	使用API/SDK	主な機能	特徴	開発言語
`o3-search-mcp`	`openai`	Responses API	Web検索	シンプルで導入が容易。多くの利用実績がある。	TypeScript
`openai-websearch-mcp`	`openai`	Responses API	Web検索	`o3-search-mcp`のPython版。モデルやリーゾニングレベルを細かく指定可能。	Python
`openai-responses-mcp`	`openai`	Responses API	Web検索	豊富な設定（YAML）とプロファイルによるカスタマイズ性が高い。	TypeScript
`openai-agents-mcp`	`@openai/agents`	Agents SDK	Web検索, ファイル検索, コンピュータ操作	最新のAgents SDKをラップ。最も多機能だが、追加の環境構築が必要。	TypeScript

ここでの重要なポイントは、Responses APIを使う3つのツールと、**Agents SDKを使うopenai-agents-mcp**という大きな分類があることです。この違いが、機能や使い方に決定的な差をもたらします。

2. コードレベルで見る！アーキテクチャの違い

各ツールがどのようにOpenAIの機能を呼び出しているのか、実際のコードを見ていきましょう。

グループA: Responses APIを直接利用するツール群

o3-search-mcp、openai-responses-mcp、openai-websearch-mcpの3つは、いずれもOpenAIのResponses APIを直接呼び出すという共通のアーキテクチャを持っています。

`o3-search-mcp` の場合

最もシンプルな実装です。index.ts の中核部分は以下のようになっています。

// ...
const response = await openai.responses.create({
  model: config.model,
  input,
  tools: [
    {
      type: "web_search_preview",
      search_context_size: config.searchContextSize,
    },
  ],
  tool_choice: "auto",
  parallel_tool_calls: true,
  reasoning: { effort: config.reasoningEffort },
});
// ...

openai.responses.create を呼び出し、tools配列に{ type: "web_search_preview" }を指定することで、Web検索機能を有効にしています。非常に直接的で分かりやすい実装です。

`openai-responses-mcp` の場合

このツールはより構造化されており、設定ファイルに基づいて動的にリクエストを構築します。src/tools/answer.ts にそのロジックがあります。

// ...
const requestBody: any = {
  model: profile.model,
  instructions: system,
  input: [{ role: "user", content: [{ type: "input_text", text: userText }] }],
  tools: [{ type: "web_search" }],
  include: ["web_search_call.action.sources"]
};

// ...

const { response, model } = await callResponsesWithRetry(client, cfg, requestBody, signal);
// ...

こちらもresponses.create（callResponsesWithRetry内でラップされている）を呼び出していますが、プロファイル機能によって使用するモデルやreasoning_effortを切り替えられるなど、高度なカスタマイズが可能です。

グループB: Agents SDKを利用する `openai-agents-mcp`

一方、openai-agents-mcpは全く異なるアプローチを取ります。@openai/agentsという、より高レベルなSDKを利用しています。

// ...
this.agent = new Agent({
  name: 'OpenAI Responses Agent',
  instructions: 'You are a helpful assistant with access to web search, file search, and computer use capabilities.',
  model: 'gpt-4.1',
  tools: this.createTools(),
});
// ...

// Web検索の実行部分
public async executeWebSearch(query: string, options?: ExecutionOptions): Promise<ExecutionResult> {
  return this.executeWithRetry(
    async () => {
      const result = await run(this.agent, `Use the web_search tool to search for: ${query}`);
      return {
        content: result.finalOutput || 'No results found',
        metadata: { itemCount: result.newItems?.length || 0 },
      };
    },
    options?.retries || 0
  );
}

new Agent(...)でエージェントの定義（指示、モデル、利用可能なツール）を行い、run(this.agent, ...)でプロンプトを与えてエージェントを実行しています。responses.createを直接呼び出すのではなく、エージェントという一段抽象化されたレイヤーを介してOpenAIの機能を利用しているのが最大の違いです。

3. Responses API vs Agents SDK：何が違うのか？

この2つの違いを理解することが、ツール選択の鍵となります。

Responses API: 車で言えば「エンジン」そのものです。Web検索やファイル検索といった個別の機能を直接呼び出すための低レベルAPIです。開発者はリクエストの構築や状態管理を自分で行う必要がありますが、その分、自由度が高いです。
Agents SDK: 「自動運転システム」に近いものです。Responses APIなどの低レベルな機能を内包し、エージェントの状態管理、複数ツールの連携、会話履歴の管理といった複雑な処理をSDKが肩代わりしてくれます。開発者はエージェントの「目的」や「性格」を定義することに集中できます。

openai-agents-mcpがfile_searchやcomputer_useといった多様なツールを提供できるのは、まさにこのAgents SDKの強力な機能のおかげです。しかし、その力には「代償」も伴います。

4. `file_search`と`computer_use`は本当に使えるのか？徹底検証

openai-agents-mcpの魅力的な機能、file_searchとcomputer_use。これらは本当に「ローカルPCを操作してくれる」魔法のツールなのでしょうか？公式ドキュメントとコードを元に、その実態を明らかにします。

`file_search`：ローカルファイル検索の夢と現実

結論：ローカルファイルを直接検索することはできません。

file_searchの実態は、OpenAIのサーバー上に事前にアップロードされたファイルを検索する機能です。公式ドキュメントには明確に「previously uploaded files」と記載されています [1]。

File search is a tool available in the Responses API. It enables models to retrieve information in a knowledge base of previously uploaded files through semantic and keyword search. By creating vector stores and uploading files to them, you can augment the models' inherent knowledge.

つまり、file_searchを使うための手順は以下のようになります。

ベクターストアの作成: OpenAIのAPIを使って、ファイルを格納するための「ベクターストア」という入れ物を作成します。
ファイルのアップロード: 検索対象にしたいファイルを、このベクターストアにアップロードします。
ツール呼び出し: file_searchツールを呼び出す際に、作成したベクターストアのIDを指定します。

openai-agents-mcpのコードを見ても、fileSearchTool('VS_ID')のようにベクターストアIDを引数に取る設計になっており、ローカルパスを直接扱う口は存在しません [2]。

したがって、「このプロジェクト内のファイルを検索して」というような、ローカル環境を対象としたシームレスなファイル検索は実現できない、というのが現状です。

`computer_use`：Macを自動操作してくれるのか？

結論：「OpenAI上のPC」を操作するのではなく、「開発者が用意した実行環境」を遠隔操作する機能です。

これもまた、多くの人が誤解しがちなポイントです。computer_useは、モデルが魔法のようにあなたのPCを操作するわけではありません。その仕組みは、モデルとあなたのコードとの間の連携ループです [3]。

The computer use tool operates in a continuous loop. It sends computer actions, like click(x,y) or type(text), which your code executes on a computer or browser environment and then returns screenshots of the outcomes back to the model.

モデルがアクションを提案: モデルは「座標(123, 456)をクリック」「'hello'と入力」といった抽象的なアクションを指示します。
あなたのコードが実行: あなたが書いたプログラムがその指示を受け取り、実際の操作（例: Playwrightでブラウザをクリック、OSのAPIでマウスを動かすなど）を実行します。
結果をスクリーンショットで報告: あなたのプログラムは、操作後の画面のスクリーンショットを撮り、それをモデルに送り返します。
モデルが次の手を判断: モデルは送られてきたスクリーンショットを見て、次のアクションを判断します。

このループを繰り返すことで、GUI操作の自動化が実現されます。

つまり、openai-agents-mcpでcomputer_useを有効にしただけでは何も起こりません。開発者自身が、操作対象となるブラウザ環境やVM環境、そしてそれらをスクリーンショット撮影＆遠隔操作するためのコードをすべて用意する必要があるのです。

macOSのデスクトップを直接操作しようとすれば、アクセシビリティや画面収録の権限周りの対応も必要になり、非常に複雑な実装が求められます。OpenAIが推奨しているのも、PlaywrightやDockerを使った隔離されたサンドボックス環境での利用です。

5. 結論：2025年、どのGPT検索系MCPを選ぶべきか

ここまでの分析を踏まえて、あなたの目的に合ったツールを選びましょう。

ケース1：とにかく手軽にWeb検索を導入したい

→ o3-search-mcp が最適解

シンプルさ、導入の手軽さ、そしてコミュニティでの実績を考えれば、o3-search-mcpが最も現実的で強力な選択肢です。Pythonが好きならopenai-websearch-mcp、より細かい設定をしたいならopenai-responses-mcpも良いでしょう。これらはすべて同じResponses APIを基盤としており、安定したWeb検索機能を提供してくれます。

ケース2：GUI操作の自動化など、未来のAIエージェントを構築したい

→ openai-agents-mcp を研究・開発する

computer_useは、現時点では「研究開発者向け」の機能です。手軽に使えるものではありませんが、PlaywrightやVMと連携するバックエンドを自分で構築する覚悟があるならば、非常に強力なエージェントを開発できる唯一の選択肢となります。これはもはや「検索系MCP」というより、「汎用エージェント実行基盤MCP」と呼ぶべきものです。

6. 導入方法（o3-search-mcpの場合）

最も現実的なo3-search-mcpの導入方法を簡単にご紹介します。

Claude CodeやCursorなどのMCPクライアントの設定画面で、以下の情報を入力します。

{
  "mcpServers": {
    "o3-search": {
      "command": "npx",
      "args": ["o3-search-mcp"],
      "env": {
        "OPENAI_API_KEY": "sk-xxxxxxxxxxxxxxxxxxxx",
        "OPENAI_MODEL": "o3" // gpt-5なども指定可能
      }
    }
  }
}

OPENAI_API_KEYを自身のものに書き換えるだけで、すぐにAIアシスタントがWeb検索の能力を手に入れます。

まとめ

GPT検索系MCPは、それぞれ異なる設計思想とアーキテクチャを持っています。

Responses APIベースのツール（o3-search-mcpなど）は、Web検索という明確な目的をシンプルに実現するための堅実な選択肢です。
**Agents SDKベースのopenai-agents-mcp**は、より高度で複雑なエージェントを構築するための野心的なフレームワークですが、その能力を最大限に引き出すには相応のバックエンド開発が必要です。

file_searchやcomputer_useといった言葉の響きに惑わされず、その実態を正しく理解すること。そして、自分の目的に合ったツールを冷静に選択することが、AI開発の生産性を向上させる鍵となるでしょう。

References

[1] OpenAI. "File search | OpenAI API." OpenAI Platform. https://platform.openai.com/docs/guides/tools-file-search
[2] OpenAI. "Tools | OpenAI Agents SDK." OpenAI Agents SDK. https://openai.github.io/openai-agents-js/guides/tools/
[3] OpenAI. "Computer use | OpenAI API." OpenAI Platform. https://platform.openai.com/docs/guides/tools-computer-use