前回は、Codexにリサーチ担当、記事ライター、校正担当を作りました。SKILL.mdを切り替えることで、1つのセッションに役割を持たせるところまでは確認できました。
そのあとも気になっていたのが、agents/openai.yamlのdependencies.toolsです。名前だけを見ると、リサーチ担当には調査用MCP、ライターには別のMCP、といった分け方ができそうです。今回はここを実際に試しました。
2026年9月17日時点、macOS、codex-cli 0.147.0での記録です。モデルはgpt-5.6-solを使いました。
dependencies.toolsにMCPを書いてみる
公式ドキュメントでは、agents/openai.yamlは表示情報、呼び出し方針、ツール依存関係を設定する任意ファイルと説明されています。Build skills
まず、リサーチ担当にだけローカルMCPを宣言しました。
interface:
display_name: "MCP付きリサーチ担当"
short_description: "ローカルMCPから調査メモを読む"
policy:
allow_implicit_invocation: false
dependencies:
tools:
- type: "mcp"
value: "department_data"
description: "検証用の社内調査メモを返すローカルMCP"
transport: "stdio"
command: "node mcp-server.mjs"比較用の記事ライターには、dependenciesを書いていません。
codex app-serverのskills/listを確認すると、リサーチ担当にはdependencies.toolsが載り、記事ライターには項目自体がありませんでした。ここまでは想定どおりです。
検証用のローカルMCPを用意する
外部サービスを使うと、認証や通信状態が結果に混ざります。今回は挙動だけを見たかったので、ローカルMCPを作りました。
公開するツールはread_research_briefの1つだけです。呼ぶと、固定のproject_codeを返します。
{
"project_code": "DEPT-MCP-42",
"note": "この値はローカルMCPから返しています。"
}MCPはユーザー設定へ追加せず、codex execの実行時だけ登録しました。普段の設定が検証に混ざらないよう、--ignore-user-configも付けています。
$ codex exec --ignore-user-config --ephemeral -s read-only \
-c 'mcp_servers.department_data.command="node"' \
-c 'mcp_servers.department_data.args=["./mcp-server.mjs"]' \
'$researcher-mcp を使って read_research_brief を呼んでください'なお、Codexアプリの作業環境からCodex CLIを起動したところ、最初は~/.codex/state_5.sqliteへ書き込めず止まりました。検証対象のMCPではなく、外側のサンドボックスが原因でした。そこでCLI側はread-onlyに固定し、通常の実行環境でやり直しています。少し入れ子になった検証でした。
依存宣言ありの担当から呼ぶ
最初はリサーチ担当です。read_research_briefを実際に呼ぶよう明示しました。
実行ログには、次の2行が出ました。
mcp: department_data/read_research_brief started
mcp: department_data/read_research_brief (completed)最終出力はDEPT-MCP-42です。MCPサーバー側のログにも、topic: dependency-declaredの呼び出しが残りました。
ここだけを見ると、dependencies.toolsによって担当へMCPを割り当てられたように見えます。
宣言していない担当からも呼べた
次に、MCP依存を書いていない記事ライターへ同じ指示を渡しました。
正直、ここは失敗すると思っていました。しかし、結果は成功でした。記事ライターからもdepartment_data/read_research_briefが呼ばれ、同じDEPT-MCP-42が返りました。
つまり、少なくとも今回の環境では、dependencies.toolsは担当ごとの許可リストではありませんでした。MCPが実行時のツールカタログに入っていれば、依存宣言のないスキルからも使えます。
依存宣言だけではMCPは起動しない
逆方向も確認しました。リサーチ担当のdependencies.toolsは残したまま、codex execからMCP設定を外します。
この状態ではdepartment_dataが利用可能ツールに現れず、呼び出せませんでした。openai.yamlにtransportとcommandまで書いていても、それだけでローカルMCPが起動する挙動は確認できませんでした。
公式ドキュメントでも、MCPの接続設定は~/.codex/config.tomlまたはプロジェクトの.codex/config.tomlへ書く形です。ChatGPTデスクトップアプリ、Codex CLI、IDE拡張は、同じホスト上のMCP設定を共有します。Model Context Protocol
dependencies.toolsは、スキルが何を必要とするかを表すメタデータだと考えるのが自然です。接続設定そのものではありません。
disabled_toolsを指定すると使えなくなった
最後に、MCPは登録したまま、ツールを明示的に無効化しました。
-c 'mcp_servers.department_data.disabled_tools=["read_research_brief"]'この状態では、依存宣言のあるリサーチ担当からも呼べません。結果はDISABLEDになりました。
公式ドキュメントには、MCPサーバー単位のenabled_toolsとdisabled_toolsが用意されています。今回の結果も、その説明と一致しました。
担当ごとにMCPを分けるには
整理すると、dependencies.toolsだけで担当ごとの権限分離はできませんでした。
担当ごとに本当に使えるMCPを変えるなら、Codexの実行自体を分ける必要があります。例えば、リサーチ工程を起動するときだけ調査用MCPを登録し、ライター工程では登録しない形です。enabled_toolsやdisabled_toolsも、工程ごとの設定へ寄せます。
前回、担当は別エージェントではなく、1つのセッションが指示書を持ち替えていると書きました。ツールも同じでした。役割を切り替えても、そのセッションに見えている道具箱までは自動で切り替わりません。
所感
dependencies.toolsという名前から、私は権限設定に近いものを想像していました。実際には、必要な道具を知らせる札に近いようです。ここは想定と違いました。
ただ、メタデータとしては意味があります。skills/listから必要なMCPを機械的に読めるので、起動前のチェックやセットアップ案内には使えそうです。
一方、社内データへ触れるMCPを担当ごとに分けたい場合、依存宣言を境界として扱うのは危ないと思います。実行単位を分け、MCP設定側で許可するツールを絞る必要があります。
次は、この構成を毎回長い-cオプションで渡さず、担当ごとの起動設定として管理できる形まで試したいと思います。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
