Ollama をデータベースと API に MCP で接続：ローカルエージェントセットアップ 2026

クイックファクト

• プロトコル： JSON-RPC 2.0 を stdio（ローカルサブプロセス）または HTTP/SSE（リモート）で通信。ローカルエージェントはほぼ stdio のみ使用します。
• メンテナー： Anthropic（オープンソース仕様）；リファレンスサーバーは GitHub の modelcontextprotocol/servers で管理、加えて成長中のサードパーティーエコシステム。
• 2026 年のローカルクライアント： Goose（Block）、Cline（VS Code 拡張）、Continue.dev（VS Code/JetBrains）、LM Studio（デスクトップアプリ）、加えて複数の CLI ツール。
• 互換 Ollama モデル： ネイティブ tool call 学習を持つすべてのモデル。2026 年 5 月時点：Gemma 4 27B、GLM-5.1 32B、Qwen3 32B、Qwen3-Coder 30B、Llama 3.3 70B。
• サーバー transport の既定： ローカルプロセスは stdio；複数マシンや複数エージェント間でサーバーを共有する場合のみ HTTP/SSE。
• 設定は 1 ファイルに集約： ~/.config/goose/config.yaml（Goose）、~/.continue/config.json の MCP ブロック（Continue.dev）、または Cline の設定 UI の mcpServers。形式はどれも同じ：サーバー名、command、args、env vars。
• Claude Desktop 不要。 プロトコルは Claude Desktop の独占ストーリーより古く、すべてのリファレンスサーバーは MIT/Apache ライセンスで、準拠する任意のクライアントで動作します。

MCP がローカルモデルに対して実際に解放するもの

• **「このリポジトリのすべての TODO を見つけ、ファイルごとにグルーピングして、Markdown 要約を notes/todos.md に書き出してください」** — filesystem サーバーが読み、モデルがグルーピングし、同じサーバーが書き込みます。エンドツーエンドで往復 1 回。
• 「今四半期の売上トップ 10 顧客を出して、グラフ化してください」 — postgres サーバーが SQL を実行（read-only ロール）、モデルが要約、filesystem 経由で CSV を書き出してチャートツールに渡します。
• 「Hacker News のフロントページを開いて、AI 関連トップ 3 記事を見つけて要約し、私の reading list に追記してください」 — puppeteer サーバーがヘッドレスブラウザを操作し、モデルが抽出と要約、filesystem が追記します。
• **「私の fork に対して chore: bump deps というタイトルのドラフト PR を開き、失敗中の CI run を本文にリンクしてください」** — github サーバーが PR を作成、run を取得、本文にリンクを書き込みます。
• **「events.db の最新 100 行を見て、新しいエラースパイクの原因になっているユーザー ID を教えてください」** — sqlite サーバーが照会、モデルが推論、回答をチャットパネルで読みます。
• いずれも以前はクラウドモデルとホストツール、または手書きスクリプトを必要とした「文 → アクション」ワークフローです。MCP は同じサーバーを複数クライアント間で、同じモデルを複数サーバー間で再利用できる層です。

最もよく使われる 4 つの MCP サーバーの比較

構成要素のつながり

• Ollama はバックグラウンドサービスとして 127.0.0.1:11434 で動作し、OpenAI 互換 API でモデルを提供します。MCP のことは知りません — chat completion に応答し、モデルが要求すれば tool call を出すだけです。
• MCP クライアント（Goose、Cline、Continue.dev、LM Studio）が橋渡し役です。モデルについては Ollama と、ツールについては MCP サーバーと話します。モデルが tool call を出すと、クライアントが正しいサーバーへルーティングし、結果を取得し、会話に戻します。
• MCP サーバー は機能ごとに独立したサブプロセスです。stdio で JSON-RPC 2.0 を話します。各サーバーが Tools、Resources、Prompts を公開し、クライアントがそれらを統合してモデルに見せます。
• stdio transport ですべてがローカルに留まります。 サーバーはクライアントによって起動され、stdin/stdout で通信し、クライアント終了時に終了します。サーバー自身が接続を開かない限り（ブラウザサーバーは開きます、filesystem とデータベースサーバーは開きません）、ネットワーク経由になりません。
• モデルはフラットなツールリストを見ます。 モデル視点ではサーバーは存在せず、filesystem.read_file、sqlite.query、puppeteer.navigate のようなツール名のリストがあるだけです。クライアントがルーティングを処理します。

セットアップ：Ollama + Goose を 15 分で

• Step 1 — Ollama をインストール。 ollama.com/download（macOS/Windows/Linux）からダウンロード。curl http://127.0.0.1:11434/api/tags でサービスが動作していることを確認してください。
• Step 2 — tool calling モデルを pull。 Gemma 4 27B（gemma4:27b）、GLM-5.1 32B（glm5:32b）、Qwen3 32B（qwen3:32b）または Llama 3.3 70B（llama3.3:70b）から選択。16 GB unified memory または 12 GB VRAM で 27B–32B を Q4_K_M で快適に動かせます。
• Step 3 — Goose をインストール。 pipx install goose-ai（macOS、Linux）または Goose リリースページからインストーラをダウンロード。CLI は goose としてインストールされます。
• Step 4 — Ollama をプロバイダーとして設定。 goose configure を実行、ollama をプロバイダーに選択、モデルを pull したものに、host を http://127.0.0.1:11434 に設定。Goose は ~/.config/goose/config.yaml に書き込みます。
• Step 5 — filesystem MCP サーバーを追加。 ~/.config/goose/config.yaml に mcpServers ブロックを追加します（下に設定例）。goose session を再起動し、テストディレクトリのファイル一覧を尋ねてください。最初のターンでサーバー接続が確認できます。
• Step 6 — 実際のタスクで検証。 goose session を試し、「notes/ 内の各 Markdown ファイルについて、タイトルと単語数の一覧を作って結果を notes/index.md に書いてください」と尋ねます。エージェントが読み、要約し、書き戻せばループは動作しています。

# 1. Pull a tool-calling model
ollama pull gemma4:27b

# 2. Install Goose
pipx install goose-ai

# 3. Configure Ollama as the provider
goose configure
# Provider: ollama
# Model:    gemma4:27b
# Host:     http://127.0.0.1:11434

# 4. Start a session — Goose reads ~/.config/goose/config.yaml
goose session

Filesystem サーバー：サンドボックス化されたディレクトリの読み書き

• インストール： リファレンスサーバーは @modelcontextprotocol/server-filesystem、npx -y 経由で実行（グローバルインストール不要）。Goose、Cline、Continue.dev はすべて設定ブロックから自動起動します。
• パスを allow-list： サーバーは 1 つ以上のディレクトリ引数を受け取り、それ以外の場所での操作を拒否します。常に明示的で範囲の狭いパスを渡してください — ~ や / は絶対に避けてください。
• 公開ツール： read_file、read_multiple_files、write_file、edit_file（行ベースの置換）、list_directory、search_files、move_file、create_directory、directory_tree。モデルからは filesystem.read_file のように見えます。
• 便利機能： directory_tree は JSON ツリーを返し、特定ファイルを読む前にモデルが構造を把握するのに最適です。search_files は grep のような再帰検索を行います。
• リスク面： サーバーは allow-list を尊重しますが、リスト内では完全な読み書き権限を持ちます。allow-list を唯一のバリアと捉え、ホームフォルダではなく専用 workspace ディレクトリを選んでください。

# ~/.config/goose/config.yaml
mcpServers:
  filesystem:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/Users/you/agent-workspace"
    env: {}

SQLite と Postgres サーバー：実データを照会する

• **SQLite サーバー（@modelcontextprotocol/server-sqlite）** は .db ファイルへのパスを取ります。ログ解析、スキーマのプロトタイピング、データベースを立てずにエクスポートを探索するのに有用です。
• **Postgres サーバー（@modelcontextprotocol/server-postgres）** は connection string を取ります。推奨パターンはエージェント用の専用 read-only ロールを作成し、そのロールの connection string を使うことです。
• 公開ツール： query（read-only 設定時は SELECT のみ）、list_tables、describe_table。Postgres サーバーは list_schemas を追加します。一部のフォークは write_query を追加しますが、このデータベースでモデルを信頼できる場合以外は無効化しておいてください。
• スキーマ認識： 分析的な質問の前に「テーブル一覧を出して、よく使われる 5 つを describe してください」とエージェントに頼んでください — describe_table を呼んだモデルは、カラム名を推測したモデルよりはるかに精度が高くなります。
• コスト： クエリは直接データベースに飛びます。1 億行テーブルへの不適切な SELECT * は人間がやった場合と同じ事故です — ロールは独立した接続プールに置き、statement timeout を設定してください。

# ~/.config/goose/config.yaml
mcpServers:
  sqlite:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-sqlite"
      - "--db-path"
      - "/Users/you/data/events.db"
    env: {}

  postgres:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-postgres"
      - "postgresql://agent_ro@127.0.0.1:5432/analytics"
    env:
      PGPASSWORD: "${PG_AGENT_PASSWORD}"

ブラウザサーバー：Puppeteer または Playwright で Chromium を操作

• リファレンスサーバー： @modelcontextprotocol/server-puppeteer（軽量、既定でヘッドレス）と @modelcontextprotocol/server-playwright（重め、複数ブラウザ対応）。ローカルエージェントには Puppeteer で十分です。
• 公開ツール： navigate、screenshot、click、fill、select、evaluate（JavaScript 実行）、get_page_content。モデルは構造化テキストを get_page_content で読み、視覚的確認に screenshot を使います。
• レイテンシ： 実ブラウザセッションはアクションあたり 1–5 秒。多段ブラウジングは簡単に 30–60 秒、数万トークンを消費します（ページ内容が大きいため）。32K+ コンテキストウィンドウを使ってください。
• セレクタ： モデルは CSS セレクタを選ぶ必要があります。小さいモデルはよく外しますが、27B+ tool calling モデルなら一般的なパターンを安定して扱います。タスクは絞ってください — 「この URL のタイトルと最初の段落を抽出してください」のほうが「サイトを巡回して contact ページを探してください」よりはるかに信頼できます。
• 良いユースケース： リサーチ（ページを開く、要約する、ノートに追記）、回帰テスト（ナビゲート、クリック、screenshot）、自分が管理するページのフォーム入力。悪いユースケース：本番 Web 上の誤クリックが結果を伴うあらゆる作業。

# ~/.config/goose/config.yaml
mcpServers:
  puppeteer:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-puppeteer"
    env:
      PUPPETEER_HEADLESS: "true"
      # Block obviously dangerous endpoints at the OS firewall level
      # rather than relying on the agent to refuse them.

GitHub サーバー：ローカルモデルから repo、issue、PR を扱う

• インストール： @modelcontextprotocol/server-github、GITHUB_PERSONAL_ACCESS_TOKEN 環境変数に PAT を入れて実行します。トークンが唯一の認証 — サーバー自体に別途設定はありません。
• 公開ツール： search_repositories、get_file_contents、create_or_update_file、create_pull_request、list_issues、create_issue、add_issue_comment、merge_pull_request、ほか数十。フルセットは大きいですが、ほとんどのタスクは 5–10 ツールで足ります。
• PAT を絞る。 特定 repo に絞った fine-grained PAT を、必要最小限の権限（閲覧は Read、PR/issue 作成は Write）で使ってください。実験的エージェントに対して repo 権限のクラシック PAT は使わないでください。
• 実例ワークフロー： トリアージ（「直近の open issue 20 件を読んで、グルーピングしてラベル案を出してください」）、ドラフト作成（「README を読んで誤字を直す PR を開いてください」）、レポーティング（「今週 stale な PR を教えてください」）。
• リスク面： エージェントは issue や PR を作成、コメント、（書き込み権限があれば）コミットを push できます。merge 系ツールはモデルとワークフローの両方を信頼できる場合以外は無効化してください — fine-grained PAT の repo での誤マージは復旧可能ですが、すぐに気付いた場合のみです。

# ~/.config/goose/config.yaml
mcpServers:
  github:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-github"
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
      # Fine-grained PAT scoped to one or two test repos,
      # not your personal account-wide classic token.

モデルを信頼しないセキュリティモデル

• filesystem サーバーを 1 ディレクトリに限定。 ~ や / は絶対に使わないでください。agent-workspace/ フォルダを選び、エージェントに触らせたいファイルのコピーを置きます。エージェントが暴走しても、最悪のケースは 1 フォルダです。
• データベースサーバーは既定で read-only 運用。 専用の agent_ro ロールを SELECT のみの権限と 30 秒の statement timeout で作成すれば、ある種のインシデントカテゴリ全体が消えます。
• 書き込みやシェル系ツールはすべて明示的承認の後ろに。 Goose、Cline、Continue.dev はそれぞれツール単位の承認ルールをサポートしています。読み取りツールは既定で許可、write_file、edit_file、execute_command、create_pull_request、フォーム送信を行うブラウザアクションには承認を要求してください。
• 監査ログを使ってください。 すべての MCP クライアントは tool call と結果を記録します。長時間セッション後にログをスキャンしてください：モデルがあなたが想定しなかった操作を試みていることに気付けます（無害な場合も、権限を絞り直すべき場合もあります）。
• サードパーティーアクセスはトークンスコープを狭く。 GitHub PAT は 2 つのテスト repo に絞る。Postgres ロールは read-only。ブラウザセッションは認証情報なし。モデルはいずれあなたが想定しなかった操作を試みます；できることの限界は、モデルが正しく振る舞うことに依存させてはいけません。
• 機密データ作業時はエージェントを air-gap してください。 プライベートデータを扱うとき、エージェント実行中はホストのネットワークアクセスを無効化（または network namespace を使用）してください。ローカルスタックはマシンから何も出しませんが、defense-in-depth はサードパーティーサーバーの不具合をキャッチします。
• MCP サーバー選定は依存関係選びと同様に扱ってください。 リファレンスサーバーはよくメンテされていますが、サードパーティーサーバーの多くはそうではありません。認証情報を渡す前にサーバーのコードを読んでください。

ローカル MCP vs Claude Desktop：何が変わり、何が残るか

ローカル MCP 用 tool calling モデルの選定

• **Gemma 4 27B（gemma4:27b）** — Google の tool call 学習はサイズに対して best-in-class。16 GB unified memory または 24 GB VRAM で Q4_K_M に収まります。一般推論は良好；連鎖した tool call にはやや保守的です。
• **GLM-5.1 32B（glm5:32b）** — Zhipu のモデルは tool call 信頼性が非常に高く、out of the box で 128K コンテキストウィンドウ。Gemma 4 よりやや重め；24 GB GPU に余裕で収まります。
• **Qwen3 32B（qwen3:32b） — バランスが良く、dense な 32B が MCP をクリーンに処理し、長時間エージェントループでも安定します。Qwen3-Coder 30B（qwen3-coder:30b）** はエージェント作業がコード形態の場合の最良の選択です。
• **Llama 3.3 70B（llama3.3:70b）** — 最高の天井ですが最も重い。Q4_K_M で 48 GB+ unified memory または 2× 24 GB GPU。ハードウェアが対応している場合のみ；通常は小さいモデルで十分です。
• MCP 作業で避けるべきもの： 7B 未満すべて、明示的な tool call 学習のない汎用モデルすべて。形式不正な call を出してループが止まり、ハーネスを責めることになりますが — ハーネスは問題ありません。
• 任意のモデルで tool call 品質を改善する構造化プロンプティング手法は、Chain-of-Thought Prompting を参照してください。
• 頭ごなしの比較データは、2026 年のローカル tool calling 最強モデル を参照してください。

MCP vs プレーン Function Calling：違いは何か

• Function calling は LLM 側の能力です：モデルがツール名と引数を記述する構造化 JSON を出力します。OpenAI Tools、Anthropic Tools、Ollama の tool call API はすべて同じ考え方を、わずかに異なる wire format で使います。
• MCP はその上に乗ります：ツールがどう記述、発見、呼び出し、返却されるかを、プロセス間で標準化します。Function calling モデル単体ではあなたの filesystem を知りませんが、MCP サーバーが filesystem 操作を提供し、クライアントがモデルの function calling API にマッピングし、モデルがそれを呼び出せるようになります。
• メリットは interop です。 filesystem サーバーを一度書けば、Claude Desktop、Goose、Cline、Continue.dev、LM Studio が変更なしで使います。モデルを Claude から Gemma 4 に変えても、サーバーは変わりません。
• Function calling だけでエージェントは作れます。 プロジェクトごとに filesystem、データベース、ブラウザのハンドラを再実装することになります。MCP ならそれらは out-of-the-box の依存関係です。
• 1 回限りのスクリプトには素の function calling のほうが簡単です。 プロジェクトやモデルをまたいで再利用したいものなら、数日以内に MCP のほうが手間が少なくなります。

日本ユーザーのための活用ポイント

• METI AI ガバナンス 2024： 経済産業省の AI ガバナンスガイドラインは、特に金融、医療、法務など規制業界での AI 利用において、データ保護とトレーサビリティを求めています。ローカル MCP スタックは外部データ送信を排除し、監査ログでトレーサビリティを担保するため、これらの要件にクリーンに整合します。
• 個人情報保護法（APPI）： 顧客データや従業員データをクラウド AI プロバイダーに送るには、第三者提供の同意とリスク評価が必要です。ローカル推論ではこの第三者提供自体が発生せず、契約上の負担と説明責任が大幅に軽減されます。
• 日本企業のユースケース： 法律事務所、税理士法人、医療機関、製造業の設計部門、人事 — クライアント・患者・従業員データを OpenAI、Anthropic、Google に送れない領域すべて。Apple M5 Mac mini や RTX 4090 搭載ワークステーションで 27B–32B モデルが動き、書類要約、契約レビュー、社内データベースに対するコード片の検証ができます。
• 東アジアのデータ越境： 日本、シンガポール、マレーシア、韓国はそれぞれ独自のデータ residency 枠組みを持ち、APAC 全域へのクロスボーダー転送には個別の評価が必要です。ローカル推論はこの転送を完全に回避し、東アジアでの multi-region 展開時のコンプライアンス負担を取り除きます。
• 日本の中堅企業（中小企業）： 大企業向けに作られたクラウド AI 契約は、中小企業にとってはコスト・契約レビュー両面でハードルが高いケースが多く、PoC が頓挫しがちです。ローカル MCP スタックは設備投資 1 回（マシン代）のみで月額課金なし、契約も社内のみで完結します。
• 監査と説明責任： MCP クライアントの監査ログ（Goose、Cline、Continue.dev）は「エージェントが想定外の操作をしていないこと」を示す主たる証拠になります。WORM ストレージや、エージェント自身からは上書き不可能な Git リポジトリに保存してください。日本の監査文化との親和性は高いです。

ローカル MCP セットアップでよくある間違い

• 間違い 1：小さい汎用モデルを使う。 7B 未満（および tool call ファインチューニングなしの 7B–13B 汎用モデルの大半）は形式不正な tool call を出します。27B+ tool call チューン済みモデルを使い、ハーネスと戦うのをやめてください。
• 間違い 2：ホームディレクトリを allow-list する。 「テストだけ」のはずの ~ の allow-list は本番運用に残ります。最初から専用の agent-workspace を作ってください。
• 間違い 3：データベースサーバーを read/write モードで放置。 自信を持ったエージェントが本番テーブルに書く DELETE クエリこそ、これで防げるインシデントです。agent_ro を既定にし、書き込みが明示的に必要なタスクのためだけに、その期間だけ別の writable ロールを立ててください。
• 間違い 4：すべてのツールを自動承認。 「すべて承認」トグルは便利で危険です。読み取りツール（read_file、list_directory、query）は自動承認、書き込み・シェル・PR 系は常に承認を要求してください。
• 間違い 5：多段ブラウザ作業に 32K コンテキストモデル。 ページ内容は大きく、3 ページ巡回で推論前に 32K トークンを使い切ることがあります。ブラウザ重めのタスクには 128K コンテキストモデルを使ってください。
• 間違い 6：エージェントに判断力があると仮定。 ありません。モデルは「これは本番データベース」「この PR はデプロイされる」という概念を持ちません。権限が唯一のバリアです。
• 間違い 7：リファレンスサーバーを最初に全部入れる。 ツールが多い = system prompt が大きい = ツール選択が遅く不正確になります。filesystem から始めて、必要になったら他を追加してください。

出典

• Model Context Protocol 仕様 — 公式仕様、JSON-RPC スキーマ、transport およびライフサイクル定義。
• modelcontextprotocol/servers GitHub リポジトリ — リファレンスサーバー（filesystem、sqlite、postgres、github、puppeteer など）と設定ドキュメント。
• Goose プロジェクトドキュメント — CLI インストール、Ollama プロバイダー設定、MCP サーバー設定構文。
• Ollama モデルライブラリ — 利用可能なローカルモデル、tool call サポートフラグ、本ガイドで参照する量子化レベル。
• Cline GitHub リポジトリ — VS Code MCP クライアント実装、MCP サーバーパネル。
• Continue.dev ドキュメント — Continue.dev クライアント用 mcpServers 設定ブロックリファレンス。

FAQ

関連資料

• 2026 年のローカル tool calling 最強モデル — 上記推奨モデル（Gemma 4、GLM-5.1、Qwen3、Llama 3.3）の頭ごなしベンチマーク。
• 自律ローカルエージェントは実際に動く — 長時間タスクでローカル MCP エージェントが何を確実にこなし何ができないかの現実チェック。
• Continue.dev vs Cline vs Aider：2026 年最強のローカルコーディングエージェント — コード形態作業のための隣接エージェント文脈；Cline と Continue.dev も MCP クライアント。
• 2026 年の最強ローカル LLM — より広い open-weights ランドスケープのモデル権威。
• ローカル AI エージェントで Zapier を置き換える — 同じ MCP スタックのワークフロー自動化フレーミング。
• Power Local LLM ハブ — ガイド全集。