GitHub / Cloudflare MCPを使って Workers アプリのリリース前チェックを実施する

GitHub / Cloudflare MCPを使って Workers アプリのリリース前チェックを実施する

Article actions
View in Markdown

Requires Chrome (latest) built-in AI.

Requires Chrome (latest) built-in AI.

この記事では、リリース前のチェック作業をMCPの力を借りて効率化する方法を紹介します。GitHubにコードをホストし、Cloudflare Workersへのデプロイを行なっているケースであれば、リリースノート作成などにも使えるはずなので、参考になるかと思います。

MCPとは何か

Model Context Protocol (MCP) は、Anthropic が2024年11月に発表したオープンスタンダードです。LLM アプリケーションと外部データソース・ツールを接続するための標準化されたインターフェースを提供します。

MCP を使うと、AI アシスタントが GitHub や Cloudflare などの外部サービスから直接情報を取得できるようになります。これにより、ブラウザを開いて手動で情報を収集する代わりに、会話の中で必要なデータを取得し、即座に分析できます。

やりたかったこと

個人開発では、「デプロイしたっきり放置しているPJ」が少なくありません。その場合、ちょっとした更新をデプロイするだけでもいろんなことが不安になります。

  • 最後にデプロイしたのがいつだっけ?
  • 変更を入れたけど、そもそも変更前のコードって全部デプロイ済みなんだっけ?
  • 環境変数とかちゃんと設定してたっけ?
  • というか前回のリリースからの変更点で結局何?

この辺りをクリアにする事前調査を、GitHub / Cloudflareにあるデータも使って調査させました。

MCPに期待した調査内容

Cloudflare MCPには、「現状調査」を依頼します。例えば「最後にデプロイされたのはいつか」や「必要な環境変数やbindingが設定されているか」などをレポートさせることを期待しています。

これらの調査には「Cloudflare Workers Bindings MCP Server」を使いました。workers_listworkers_get_workerなどのツールを利用させることで作成日や更新日などを取得できます。取得した情報とgitのログやtag作成日を照らし合わせることで、「いつのコミットがデプロイされていると言えるか」を検証することができます。

GitHub MCPには、「何をなんのために変更したか」を調査させました。具体的には「マージされたPRの調査」です。コミット履歴を追いかけることで何をしたかは把握できるのですが、「どんな問題(issue)に対応するために変更したか」などの情報はGitHub側に残っています。そこでgitのログを調査した上で対応するPull Requestや関連するIssueを調査し、レポートさせることにしました。

リリースごとにgit tagしておくと、調査が楽

やってみて感じたのは、「リリースしたら、とりあえずその日の日付でもいいからgit tagしておこう」ということです。これによりgitの情報を見るだけで「リリースしたバージョンはどれか」が特定しやすくなります。Cloudflare MCPで毎回調査させるよりも、コンテキストウィンドウを節約することもできました。

また、リリースノートの作成やリリースされる機能の把握についても、以下のようなコマンドですぐに調べれるようになることもいいなと思っています。

# コミット履歴を確認
git log --oneline 2026.01.07..main

# 変更ファイルの統計を取得
git diff 2026.01.07..main --stat

# 変更ファイル一覧を取得
git diff 2026.01.07..main --name-only

まとめ

gitで「何を変更したか」を理解し、Cloudflare MCPで「今どんな設定・状況か」を整理、そしてGitHub MCPが「その背景」を調査してくれます。Backlog / Jiraなどを使っている場合は、それらのMCPも組み合わせると、よりリリース内容の把握や整理がしやすくなりそうです。

今のところ手元でMCPサーバーと接続したAIツールに調査を指示していますが、Devin / Amazon Bedrock AgentCoreなどのリモートでもMCPを利用できるツールを利用することで、自動的に情報を収集してSlackなどに通知する仕組みも作れるかもしれません。

現状把握やリリース前の不安感除去は、個人開発でもチームの開発でも地味にリソースや気持ち的なコストの嵩む範囲です。機械に任せれるものは、なるべく任せて「漠然とした不安」を減らしていきたいところです。

Share:

Hidetaka Okamoto profile photo

Hidetaka Okamoto

Business Development

I'm a Business Development professional at DigitalCube. Based on my experience in EC ASP development and as a Developer Advocate at Stripe, I'm working on methods to increase revenue for SaaS and EC sites, exploring efficiency improvements using generative AI, and developing new business models. You can follow me on Twitter at @hidetaka__dev

Related Articles