第3回 Codex + MCPで外部サービスと連携する

はじめに

本シリーズ「VS Code + Pythonで学ぶCodexとMCP入門」は、本編・全3回を通じて、Codexを「仕組みを理解する → 公開サーバーを使う → 実務で連携する」という流れで学ぶ構成となっています。

Codexは、単にコードを提案するだけのツールではなく、プロジェクトのファイルを読み、コードを書き換え、ターミナルコマンドを実行するところまで一貫して行う「コーディングエージェント」です。本シリーズでは、MCP（Model Context Protocol）を通じてCodexを外部ツールと連携させる仕組みを理解し、公開されているMCP Serverを使い、最終的にGitHubなどと連携した実践的な開発まで、段階的に発展させてきました。

前提となる記事: 本シリーズは、Codex単体の基本的な使い方（インストール・サインイン・Pythonコードの作成/実行/修正）を理解していることを前提にしています。まだの方は、先に以下の記事をご覧ください。

VS Code中心で学ぶCodex入門〜Codexアプリ・VS Code拡張・CLIでPythonコードを作る手順〜

シリーズ全体の構成

回	テーマ
第1回	CodexとMCPを理解する
第2回	公開されているMCP ServerをCodexから使ってみる
第3回	Codex + MCPで外部サービスと連携してみる（本記事）
発展編	PythonでMCP Serverを作ってCodexから使ってみる

第1回でMCPの仕組みを、第2回で公開MCP Serverの使い方を学びました。本編の最終回となる本記事では、それらを踏まえて実践的な開発への活用に挑戦します。GitHub公式MCP Serverを使い、Issueの情報取得 → Pythonコードの修正 → テストという、実際の開発でよくある一連の流れをまとめてCodexに任せてみます。

第2回で紹介したGitHub公式MCP Serverが、いよいよ主役として登場します。

補足: 本記事の内容は執筆時点の情報にもとづいています。GitHub MCP ServerやCodexは更新が速いため、最新の設定方法はGitHub公式のCodexインストールガイドとOpenAI公式のCodex MCPドキュメントで確認してください。

この記事のゴール

本記事では、Codexを外部サービス（GitHub）と連携させ、情報取得からコード修正・テストまでの一連の開発作業をCodexに任せることを学習します。ここでいう「連携」は、完全自動のCI/CDのような仕組みではなく、Codexというエージェントに一連の開発作業を実行してもらうイメージです。

最終的には、

「Issue #1 の内容を確認し、方針を説明したうえで修正して、テストして」と頼むだけで、Codexが情報取得からコード修正・テストまでを進める

ところをゴールにします。

3-1. 今回やること

今回の連携の流れは、次のとおりです。

① GitHubのIssueを取得する（GitHub MCP Server）
        ↓
② Issueの内容を踏まえてPythonコードを修正する（Codex）
        ↓
③ テストを実行して確認する（Codex）

第1回で見たとおり、Codex自身がGitHubへ直接アクセスするわけではありません。Codexは「GitHub MCP ServerのTool」を呼び出し、実際にGitHub APIへアクセスするのはMCP Server側です。全体像を図にすると次のようになります。

Codex（MCP Client）
     │  MCP（Streamable HTTP）
     ↓
GitHub MCP Server（GitHubがホスト）
     │  GitHub API
     ↓
GitHub（Issue / PR / リポジトリ）

3-2. GitHub MCP Serverの接続を確認する

GitHub公式MCP Serverの登録（PATの発行・環境変数の設定・codex mcp add）は、第2回ですでに行っています。第3回では、それが使える状態になっていることを確認するところから始めます。

Codexを起動し、TUI内で /mcp を実行します。

codex

/mcp

実行結果（例）

github サーバーが connected になっていれば準備完了です。まだ登録していない方は、第2回を参照して次のコマンドで登録してください（PATを環境変数 GITHUB_PAT_TOKEN に設定済みの前提）

codex mcp add github --url https://api.githubcopilot.com/mcp/ --bearer-token-env-var GITHUB_PAT_TOKEN

3-3. Issueの情報を取得する

あるリポジトリのIssueをCodexにMCP経由で取得させます。

python-codex-sample の Issue #1 の内容を教えてください。

実行結果

3-4. 情報を踏まえてPythonコードを修正する

取得したIssueの内容を踏まえて、コード修正へ進みます。ここでCodexは、前提記事で学んだ「ローカルのファイルを読み書きする」能力を発揮します。

修正の前に：作業状態を確認する

いきなり修正させる前に、現在の作業状態を確認しておくと安全です。未コミットの変更を勝手に上書きされないよう、Codexに一言添えます。

作業を始める前に git status を確認してください。
未コミットの変更があれば、勝手に上書きせず内容を教えてください。

実行結果

Issueを鵜呑みにせず、方針を先に確認する

Issueの要求が、既存のコードやテストと矛盾していることもあります。実務では、いきなり直すのではなく、関連コードと既存テストを確認し、修正方針を先に提示してもらうのが安全です。

Issue取得
   ↓
関連コードを確認
   ↓
既存テストを確認
   ↓
修正方針を提示
   ↓
（ユーザーが確認）
   ↓
修正

この流れに沿って、次のように依頼します。

Issue #1 の内容と、main.py の現在のコードを確認してください。
そのうえで、どう修正するか方針を説明してから、multiply 関数を作成してください。
動作確認は仮想環境「c:\python\venv\Scripts\python.exe」を使用してください。

実行結果

Issue #1の要件は、multiply(a, b)でa * bを返し、multiply(10, 20)が200になることです。
既存の変更を保持したまま、mainの直前に関数を追加します。その後、c:\python\venv\Scripts\python.exeで掛け算と既存の加算処理を確認します。

上記はCodexが仮想環境のPythonをサンドボックス外で実行してよいか確認している画面です。今回なら「1. Yes, proceed (y)」を選べばOK です。

GitHubから取得したIssueの意図が、そのままコード修正に反映されました。

3-5. テストを実行して確認する

修正だけで終わらせず、テストまで依頼するのがエージェントらしい使い方です。前提記事で学んだ「実行して確認」を、テストに広げます。

multiply関数のテストを pytest で追加してください。
テストを実行して結果を確認してください。

仮想環境にpytestがインストールされていなかったため、インストールの許可を求める確認画面が表示されます。

Yes, proceed (y) が表示されるので、1を入力して処理を進めます。

Codexは以下のテストコードを作成し、pytest を実行して結果を報告します。

import pytest
from main import multiply

@pytest.mark.parametrize(
    "a, b, expected",
    [
        (10, 20, 200),
        (0, 7, 0),
        (7, 0, 0),
        (-3, 4, -12),
        (3, -4, -12),
        (-3, -4, 12),
        (0.1, 0.2, 0.02),
    ],
)
def test_multiply(a, b, expected):
    assert multiply(a, b) == pytest.approx(expected)

実行結果

3-6. 一度の指示で一連の開発フローを実行してみる

ここまでは、Issueの取得、コード修正、テストを順番に依頼してきました。MCPとCodexの連携に慣れてきたら、これらを一度の指示にまとめることもできます。

例えば、次のように依頼します。

GitHub MCP Serverを使用して、`python-codex-sample` リポジトリの Issue #1 の内容を確認してください。

以下の手順で作業を進めてください。

1. GitHub MCP Server経由で Issue #1 の内容を確認してください。
2. Issue #1 の内容と、現在の `main.py` のコードを確認してください。
3. コードを修正する前に、Issueの要件を満たすためにどのような修正が必要か、修正方針を説明してください。
4. 修正方針に基づいて `main.py` を修正してください。
5. Issue #1 の要件を確認するための `pytest` のテストコードを追加してください。
6. 追加したテストを実行し、正常に通ることを確認してください。
7. 最後に、以下の内容をまとめて報告してください。

   * Issue #1 の概要
   * `main.py` の変更内容
   * 追加したテストの内容
   * `pytest` の実行結果

なお、Pythonおよび`pytest`の実行には、以下の仮想環境を使用してください。

`C:\python\venv\Scripts\python.exe`

作業中に未コミットの変更が見つかった場合は、勝手に上書きせず、作業を止めて変更内容を報告してください。

Codexは、次のような流れで作業を進めます。

GitHub Issue取得
        ↓
Issue内容を理解
        ↓
関連するPythonコードを確認
        ↓
修正方針を整理
        ↓
コード修正
        ↓
テスト追加
        ↓
pytest実行
        ↓
結果を報告

このようにMCPを利用すると、外部サービスから取得した情報と、Codexがもともと持つローカル開発環境の操作能力を、一つのワークフローとして組み合わせられます。

MCPの価値は、単に「GitHubの情報を取得できる」ことだけではありません。外部から取得した情報を、その後のコード修正やテストとつなげられることが、CodexとMCPを組み合わせる大きなメリットです。

補足: 一度の指示にまとめても、Codexは各ステップ（ファイル変更やコマンド実行）の前に確認を求めることがあります。内容を見て承認しながら進めれば、丸投げによる暴走を防げます。

「指示書」参考

Codexに作業を依頼する際は、単に「Issueを修正してください」と指示するだけでなく、作業手順・実装内容・テスト条件・使用する仮想環境・禁止事項まで明記しておくのがポイントです。

以下は、GitHub MCP ServerでIssueを確認し、実装・テスト・コミット・pushまでを依頼する指示書の例です。

以下の手順で作業を進めてください。

1. GitHub MCP Server経由でpython-codex-sample リポジトリのIssue #1 の内容を確認してください。
2. Issue #1 の内容と、現在の main.py のコードを確認してください。
3. 作業開始前に git status を確認してください。
   未コミットの変更や未追跡ファイルがある場合は、勝手に上書きせず、変更内容を報告してください。
4. コードを修正する前に、Issue #1 の要件を整理し、どのように修正するか方針を説明してください。
5. Issue #1 の要件に基づいて main.py を修正してください。
6. Issue #1 の要件を確認するための `pytest` のテストコードを追加してください。
7. 追加したテストを実行し、正常に通ることを確認してください。
8. テストが成功したら git diff と git status を確認し、意図したファイルだけが変更されていることを確認してください。
9. 問題がなければ変更内容をコミットしてください。
   コミットメッセージは、今回実装した内容が分かるものにしてください。
10. コミット後、現在のブランチをGitHubへ push してください。
11. 最後に、以下の内容をまとめて報告してください。
    - Issue #1 の概要
    - 修正方針
    - main.py の変更内容
    - 追加したテストの内容
    - pytest の実行結果
    - コミットIDとコミットメッセージ
    - push先のブランチ

【実行環境と禁止事項】
- Pythonおよびpytestの実行には、以下の仮想環境を使用してください。
  C:\python\venv\Scripts\python.exe
- テストが失敗した場合は、そのままコミット・pushせず、原因を調査して修正してください。
- テストの失敗を修正できない場合は、コミット・pushを行わず、原因を報告してください。

このように作業の順序だけでなく、「未コミットの変更を勝手に上書きしない」「テストが失敗した状態ではpushしない」といった条件も明示しておくことで、Codexに任せる範囲と、事前に確認してほしい範囲を分けやすくなります。

3-7. ここまでの流れの振り返り

第3回でCodexに任せたのは、次の一連の流れです。

GitHub Issue取得（MCP）
     ↓
Issue内容を理解（Codex）
     ↓
Pythonコード修正（Codex + ローカルファイル）
     ↓
テスト作成・実行（Codex + pytest）
     ↓
結果を確認・報告

前提記事と本編（第1回〜第2回）で学んだ要素が、すべてここで組み合わさっています。

要素	学んだ回	今回の役割
ローカルのコード修正・実行	前提記事（Codex入門）	コード修正・テスト実行
MCPの仕組み（Client/Server）	第1回	GitHubとの連携の理解
公開MCP Serverの利用・登録	第2回	GitHub公式MCP Serverを登録

3-8. 外部連携を行うときの注意点

外部サービスとつなぐ場合、セキュリティと安全性への配慮がより重要になります。

トークンは環境変数で管理する: PATを設定ファイルやコードに直接書かない。--bearer-token-env-var のように環境変数名で渡す。
最小権限にする: PATのスコープは必要最小限にとどめる。権限不足のエラーが出たら足す、が安全。
公開リポジトリにコミットしない: .env は必ず .gitignore で除外する。誤ってコミットしたトークンは、すぐに無効化（ローテーション）する。
書き込み操作は特に慎重に: Issue作成やPRマージなど、影響のある操作は実行前に必ず内容を確認して承認する。
信頼できるサーバーだけを使う: 今回のようにGitHub公式など、提供元が明確なMCP Serverを使う。

シリーズ全体のまとめ

本編・全3回を通じて、CodexとMCPを次のように段階的に学んできました（Codex単体の使い方は前提記事で扱っています）。

前提：Codexを使う（アプリ / VS Code拡張 / CLI）
        ↓
第1回：MCPを理解する（Client / Server / プロトコル）
        ↓
第2回：公開MCP Serverを使う（GitHub公式など）
        ↓
第3回：GitHub連携で外部サービスと連携する（情報取得→修正→テスト）
        ↓
Codexを「MCPで拡張して実務で使う」へ

このシリーズの狙いは、Codexを「便利なコード生成ツール」で終わらせず、MCPを通じて外部ツールと連携させ、実務で使えるようになることでした。

第1回で「MCPとは何か」という土台を作り、
第2回で「公開されているサーバーを使う」体験をし、
第3回で「外部サービスと連携して実務フローを回す」ところまで進みました。

MCPを使い分ける基本的な考え方は、「既存のGitHub MCPでできることは既存サーバーを使う。既存サーバーでは提供されていない自分独自のToolが必要になったら、Pythonで自作する」です。公開サーバーでは足りない自分専用の機能がほしくなったら、発展編でPythonによるMCP Serverの自作にも挑戦してみてください。

本シリーズの記事一覧は以下の通りです。

【第1回】VS Code + Pythonで学ぶCodexとMCP入門〜CodexはどうやってMCPで外部ツールとつながるのか〜
【第2回】GitHub公式MCP ServerをCodexから使ってみる〜公開MCP Serverの基本〜
【第3回】Codex + MCPで外部サービスと連携してみる
【発展編】PythonでMCP Serverを作ってCodexから使ってみる

ぜひシリーズを通して、MCPを「理解する」段階から「使い・実務で連携する」段階まで身につけていきましょう。