MCP で、リポジトリの外にある情報に手を伸ばす

ここまでの2回で渡してきたのは、書いて置いておける知識でした。規約も手順も、書いた時点で中身が決まっています。

決まっていないものもあります。いま本番で出ているエラー、データベースの中身、チケットの状態、外部サービスの現在の設定。これらは、書いておくことができません。見に行くしかない。

MCP（Model Context Protocol）は、その「見に行く」を可能にする仕組みです。

何をつなぐものなのか

MCP は、AIのエージェントが外部の道具やデータへつなぐための共通の約束事です。Codex が決めたものではなく、複数のツールが対応している仕様です。

約束事が共通であることには意味があります。あるサービス向けのサーバーを1つ用意すれば、MCP に対応したどのツールからも使えます。ツールを乗り換えても、つなぎ込みは作り直しになりません。

つながるものの例を挙げると、課題管理、設計資料の置き場、監視の記録、データベース、ブラウザの操作などです。BenriWorks でも、GitHub の操作と Vercel の状態確認を MCP 経由で行っています。

接続の形は2つ

codex mcp add のヘルプに、使い方がそのまま書かれています。

Usage: codex mcp add [OPTIONS] <NAME> (--url <URL> | -- <COMMAND>...)

Arguments:
  <NAME>        Name for the MCP server configuration
  [COMMAND]...  Command to launch the MCP server. Use --url for a streamable HTTP server

括弧の中が接続の形です。--url を指定するか、コマンドを指定するか、どちらか一方を選びます。

コマンドを指定する形は、手元でサーバーの処理を起動します。ローカルのファイルやデータベースを扱うものは、この形になります。

--url を指定する形は、HTTPでつながる先を指定します。外部サービスが提供しているものは、たいていこちらです。

追加したあとは、一覧と削除のコマンドが用意されています。

codex mcp list      # つないであるものを並べる
codex mcp get <名前>  # 1つの設定を見る
codex mcp remove <名前>  # 外す

鍵を設定ファイルに書かない

つなぐ先には、たいてい認証が要ります。ここでの書き方を間違えると、第7回で扱った「履歴に入れてはいけないもの」に直結します。

手元で起動する形のサーバーには --env があります。

--env <KEY=VALUE>
        Environment variables to set when launching the server. Only valid with stdio servers

HTTPでつなぐ形には、もっと良い選択肢があります。

--bearer-token-env-var <ENV_VAR>
        Optional environment variable to read for a bearer token. Only valid with streamable HTTP
        servers

渡すのは環境変数の名前です。値ではありません。設定ファイルに残るのは変数名だけになるので、そのファイルをリポジトリに入れても鍵は漏れません。

OAuth を使う形も用意されていて、codex mcp login と codex mcp logout で認証の状態を出し入れします。この場合、鍵そのものを手元の設定に置かずに済みます。使えるならこれが一番安全です。

つないでよいものの見極め

何でもつなげばよいわけではありません。判断の材料を3つ挙げます。

ひとつ目は、戻せるかどうかです。この講座で繰り返し出てくる基準がここでも効きます。記録を読むだけのものは安全です。チケットの状態を変えるもの、データを書き換えるもの、通知を送るものは、慎重に扱います。

ふたつ目は、その情報がどこへ行くかです。MCP でつないだ先から返ってきた内容は、モデルへの入力になります。個人情報や顧客の非公開情報が入っている場所をつなぐときは、それが外部へ送られてよい情報かどうかを先に確認してください。判断がつかないなら、つながないほうが確実です。

みっつ目は、返ってくる情報が信頼できるかです。外部から返ってきた文章の中に、Codex への指示に見える文が混ざっていることがあります。課題管理のコメント欄や、取得したウェブページの中身がそうなり得ます。返ってきたものは、指示ではなくデータとして扱われるべきものです。つなぐ先が誰でも書き込める場所なら、この点を意識しておく必要があります。

つなぐ数を増やしすぎない

もう1つ、実際に運用してみて分かったことがあります。つなぐ数が増えると、選択の精度が下がります。

Codex は、使える道具の一覧を持った状態で作業を始めます。一覧が長くなるほど、その中から適切なものを選ぶ判断が難しくなり、関係ない道具を使おうとする場面が増えます。スキルの説明文を正確に書く話と、同じ構図です。

使っていないものは外す。定期的に codex mcp list を見て、3か月使っていないものを外す程度で足ります。

3つの仕組みの位置

ここまでで、Codex に何かを渡す仕組みを3つ扱いました。

AGENTS.md は、常に効く規約です。スキルは、その作業のときだけ開く手順です。MCP は、書いておけない情報を取りに行く経路です。

3つは競合しません。同じ作業で全部使うこともあります。たとえばリリースの作業なら、規約は AGENTS.md に、手順はスキルに、デプロイの状態の確認は MCP 経由で、という形になります。

どれを使うかの判断は、次の回でまとめます。

次の回

第12回は、この3つの使い分けです。判断の順番を決め、実際の作業をどう割り振ったかを具体例で示します。第4部「覚えさせる」の締めくくりになります。

参照した公式情報

• codex mcp add の引数と認証の選択肢は codex-cli 0.154.0 を執筆環境へ導入して取得
• Model Context Protocol の仕様（modelcontextprotocol.io、2026年9月時点）