Codex × Skill × MCPでAIコーディングを自動化する実践フロー

最近は Codex にその場でコーディングをお願いするだけでなく、Skill と MCP を組み合わせて、Backlog での課題整理、実装、レビュー、コミットメッセージ作成、PR本文作成までを半自動化しています。

この記事では、実際に使っている Skill を交えながら、Codex を使った AI コーディングの実務フローをまとめます。

ポイントは、単に AI に質問するのではなく、Skill で作業手順をテンプレート化し、MCP で Backlog などの外部システムと接続して、開発フロー全体を自動化していることです。

Skill と MCP の役割

MCP は、AI が外部システムの情報を取得したり操作したりするための接続口です。
たとえば Backlog の課題情報を取得するときは、Backlog MCP 経由で課題キーを指定して取得します。

一方で Skill は、Codex に「どういう手順でその作業を進めるか」を教えるための作業テンプレートです。
同じ Backlog 連携でも、単に課題を取得する Skill、実装レビューをする Skill、PR 説明文を作る Skill では役割が異なります。

ざっくり言うと、次のようなイメージです。

• MCP: 外部情報を取りに行くための仕組み
• Skill: Codex にやらせる作業手順の型

普段の実装フロー

1. Backlog MCP と backlog Skill で課題内容を取得する
2. Codex とのチャットで要件や実装方針を整理する
3. Codex Agent に実装を進めてもらう
4. backlog-implementation-review Skill で課題基準のレビューをする
5. CursorAI でもう一度レビューする（Codexとは別のAIにレビューしてもらう）
6. japanese-commit-message Skill でコミットメッセージを作る
7. backlog-pr-description Skill で PR 本文を作る

1. Backlog MCP で課題を取得する

最初にやるのは、Backlog の課題キーをもとにタスク内容を整理することです。
ここでは backlog Skill を使います。

この Skill は、Backlog MCP を使って課題情報を取得し、次のような項目をまとめる前提になっています。

• 課題キー
• サマリー
• 説明
• ステータス
• 優先度
• 担当者
• 期限や開始日
• 実装時に対応すべきポイント

これを最初にやっておくと、「結局この課題で何を直すのか」がかなり見えやすくなります。
単に課題本文をコピペして AI に読ませるより、作業の入り方が安定します。

backlog Skill

# Backlog課題取得

BacklogMCPを使って課題内容を取得し、着手時の対応ポイントをまとめる。

## 手順

1. ユーザー入力から課題キーを抽出する（例: `HOGE-001`）。
2. `mcp__backlog__get_issue` を `issueKey` 指定で実行する。
3. 取得結果から以下を整理する。
- 課題キー
- サマリー
- 説明
- ステータス
- 優先度
- 担当者
- 期限・開始日（あれば）
- 親課題・マイルストーン（あれば）
4. 説明文から「対応しなければならない内容」を3-7項目で要約する。
5. 情報不足がある場合は、推測せず不足項目を明示する。

## 使い方

`/backlog HOGE-001`

2. Codex とチャットして要件を詰める

課題を取得したら、すぐにコードを書かせるのではなく、まず Codex とチャットして要件整理をします。

ここでよく詰めるのは、次のような点です。

• 課題の曖昧な部分
• 影響範囲
• 既存実装のどこを触るべきか
• テスト観点
• 実装方針の候補

この段階は Skill というより、普段の会話ベースの設計フェーズに近いです。
ただ、最初に Backlog 情報を整理しておくことで、会話の精度・実装スピードがかなり上がります。

3. Codex Agent で実装する

要件整理ができたら、Codex Agent に実装を進めてもらいます。
ここではコードベースを探索しながら、必要なファイルを読み、修正し、必要であればテストまで進めます。

個人的には、この段階で大事なのは「いきなり全部書かせる」のではなく、前段で整理した内容を材料として渡すことです。
そうすると、AI が場当たり的に変更するよりも、意図のある修正になりやすいです。
Codex Agent は AGENTS.md を参照しながら実装を進めています。
特に、勝手に実装が進んでレビューが追いつかなくなるのを防ぐため、次のように定義しています。

AGENTS.md

- ファイルの作成・編集をする場合は、必ずチャットで実装例を提示し、承認されたら実装してください。
- 不明なことがあれば、曖昧な回答はせず「分からない」と回答してください。
- コミュニケーションは明るく、時々絵文字を使ってください。

4. 課題基準でレビューする

実装後は、backlog-implementation-review Skill を使ってレビューします。

ここは少し大事なポイントで、PR 説明文生成 Skill とレビューの役割は別物です。

• backlog-implementation-review: 課題内容を基準に実装が合っているかレビューする
• backlog-pr-description: 差分と課題情報から PR 本文を作る

レビュー Skill では、課題本文を基準にして次の観点を見ます。

• 要件が満たされているか
• 仕様不一致がないか
• 回帰リスクがないか
• 例外系や境界値の考慮漏れがないか
• テスト不足がないか

単なるソースコードレビューではなく、「その Backlog 課題に対して正しい実装か」を見られるのが良いところです。

backlog-implementation-review Skill

# Backlog実装レビュー

入力されたBacklog課題キーをもとに、まずBacklog MCPで課題内容を取得する。
取得した課題内容をレビュー観点の基準として、ローカルコードベース上の既存実装を確認し、実装が課題に対して適切かをレビューする。

## 進め方

1. ユーザー入力からBacklog課題キーを特定する。
2. Backlog MCPを使って課題情報を取得する。
3. 課題の要件、背景、制約、受け入れ条件、注意点を整理する。
4. ローカルコードベースを調査し、課題に対応している実装箇所と関連テストを特定する。
5. 課題内容と実装内容を照らし合わせてレビューする。

## レビュー観点

- 要件の未充足
- 課題内容との仕様不一致
- 既存挙動への回帰リスク
- 境界値や例外系の考慮漏れ
- 関連テストの不足、またはテスト観点の抜け

5. Cursor でも再レビューする

Codex だけで終わらせず、Cursor(Composer) でもう一度レビューしています。
AI ごとに着眼点が少し違うので、別のレビューアを追加する感覚です。

人間のレビューを減らすというより、AI の段階で粗い見落としを減らしておくイメージです。

6. コミットメッセージは Skill で作る

差分が固まったら、japanese-commit-message Skill を使ってコミットメッセージを作ります。

この Skill は、ステージ済み差分と現在のブランチ名を見て、日本語コミットメッセージを所定フォーマットで生成します。
重要なのは、メッセージ生成までで止まり、勝手に commit や push はしないことです。

つまり、

• 差分の要約は AI に任せる
• 実際に commit / push するかは人が判断する

という分担ができます。

japanese-commit-message Skill

# 日本語コミットメッセージ生成

ステージングされているGit差分を分析し、日本語でコミットメッセージを作成する。

## 必須ルール

- `git diff --staged` で差分を確認してから作成する
- ブランチ名は `git branch --show-current` で取得する
- `commit` と `push` は勝手に実行しない
- `commit` または `push` を実行する場合は、必ずユーザー承認を得る

## 形式

- 1行目: `プレフィックス:変更の概要 #チケット番号`
- 2行目: 空行
- 3行目以降: ファイル名を `-` で始め、変更詳細を4スペースインデントで記載する

7. PR 本文も Skill で作る

最後に backlog-pr-description Skill を使って PR 本文を作ります。

この Skill は、主に次の情報を使って PR 文面を作ります。

• 現在のブランチ名
• git diff origin/master...HEAD
• Backlog MCP から取得した課題情報

出力はだいたい次のような構成です。

• 作業内容
• テスト
• 備考

変更差分だけを見て PR を書くのではなく、Backlog 課題の背景も加味してまとめられるので、レビューする側にも伝わりやすくなります。

backlog-pr-description Skill

# Backlogプルリクエスト作成

git差分とBacklogMCPを使い、PR用の説明文を作成する。

## 必須ルール

- 現在ブランチを `git branch --show-current` で確認する
- ブランチ名から課題キーを抽出する
- 差分は `git diff origin/master...HEAD` で確認する
- Backlog課題は `mcp__backlog__get_issue` を使って取得する
- 取得した `summary` と `description` を反映する

## 出力形式

```markdown
# 作業内容

[Backlogタスクの概要と実装内容を記載]

# テスト

[実施したテスト内容を記載]

# 備考

[その他の注意事項や補足情報を記載]
```

このフローのよいところ

この流れのよいところは、AI をただの質問相手として使うのではなく、作業工程ごとに役割を固定できることです。

• 課題取得は backlog
• 課題基準のレビューは backlog-implementation-review
• コミット文作成は japanese-commit-message
• PR 文作成は backlog-pr-description

このように分けることで、毎回プロンプトをゼロから考えなくて済みます。
特にチームで使う場合は、作業の進め方をそろえやすいのも大きな利点です。

まとめ

今のところかなりしっくり来ているのは、MCP で必要な情報を取りに行き、Skill で Codex の作業手順を固定するやり方です。
これによって、課題確認から実装、レビュー、コミット、PR 作成までの流れを、かなり安定して回せるようになりました。

AI に全部丸投げするというより、AI が迷いにくいレールをこちらで用意して、その上を走ってもらう感覚に近いです。