「このIssue、誰かに投げられないか」と思うような軽微な修正タスクは、仕様も変更範囲も明確なのに、人が抱えると意外と心理的コストがかかります。
- Linearの担当者をAI用Botに変更するだけで自動実装フローを起動できる
- Webhook → GitHub Actions → Codex → PR作成までをつなげられる
- 実装とレビューを分け、人間が最終承認を持つ運用が安全
この記事では、Linear・GitHub・Codexを組み合わせて、Issueの担当者をAIにアサインすると自動でタスクが走り、PR作成と報告まで進む仕組みを整理します。
「このIssue、誰かに投げられないか」と思った際に、人間だと「この人今タスク大丈夫かな・・・？」とか「こんなことお願いして大丈夫かな？」と思うことがあります。
仕様は固まっている。変更範囲も狭い。軽微と言える修正。でも手を動かすのが億劫なタスク。それをいちいち手を止めてどうしようか・・・と考えるのは結構なストレスになると思います。
今回整理するのは、LinearのIssue担当者をCodex用のBotに変えるだけで、実装からPRまで自動で流れる仕組みです。
特別なインフラは不要です。Linearが一番初期設定が楽ですが、他のツールでも工夫すれば作れるはずなので、ぜひ参考にしてみなさんのタスクツール上でもAIと連携できる仕組みを構築してみてください。
ちなみにこのタスクは、Codexが対処できるものであればかなり幅広く対応できます。今後はClaude CodeやGeminiでも似たようなことができるようになり、テキスト修正やデザイン修正なども、人間の担当者のように役割をアサインできるようになっていくはずです。
全体像を先に把握する
構成は6ステップで、順番に並べるとこうなります。
見た目は複雑に映りますが、やっていることはバトンを渡しているだけです。それぞれのレイヤーは独立していて、どこかで止めても問題ありません。運用しやすい形に調整してもらえれば大丈夫です。
なぜこの3つを選ぶのか
今回は Linear、GitHub、Codex の組み合わせを使います。これは一番構築が手っ取り早いからです。
LinearのWebhookは「何が変わったか」を教えてくれる
LinearはIssueが更新されるたびにHTTPS POST通知を送ります。ここで重要なのが updatedFrom フィールドです。
{
"action": "update",
"type": "Issue",
"data": {
"assigneeId": "codex-bot-id"
},
"updatedFrom": {
"assigneeId": "previous-user-id"
}
}
data.assigneeId が新しい担当者、updatedFrom.assigneeId が変更前の担当者です。 この差分を見ることで、Codex Botが新しく割り当てられた瞬間だけ に限定したトリガーが作れます。
GitHubのrepository_dispatchが外部からのキックに対応している
GitHub Actionsには repository_dispatch というトリガーがあります。外部からHTTP POSTを受け取って、特定のworkflowを起動できる仕組みです。
curl -X POST \
-H "Authorization: token YOUR_GITHUB_TOKEN" \
-H "Accept: application/vnd.github.v3+json" \
https://api.github.com/repos/{owner}/{repo}/dispatches \
-d '{
"event_type": "linear-codex-assigned",
"client_payload": {
"issue_title": "ユーザー認証APIの実装",
"issue_body": "...",
"issue_identifier": "ENG-123"
}
}'
LinearのWebhookを受け取ったサーバーが、このリクエストを送る。それだけでGitHub Actionsが動き出します。
Codexは「実装」と「レビュー」を分けて使える
Codexには大きく2つの使い方があります。
-
openai/codex-actionをGitHub Actionsで動かして実装させる - PRができた後にGitHubのレビュー機能としてコードレビューさせる
この2つを別のworkflowとして設計できるのが、Codexの大きな強みです。実装担当のCodexと、レビュー担当のCodexを役割として分離できます。
実装の中身
Step 1：Webhook受信サーバー
Node.jsで書く場合、こんな構造になります。
app.post('/webhook/linear', async (req, res) => {
// Linearのシグネチャ検証
const signature = createHmac('sha256', process.env.WEBHOOK_SECRET)
.update(JSON.stringify(req.body))
.digest('hex');
if (signature !== req.headers['linear-signature']) {
return res.status(400).send('Invalid signature');
}
const { action, type, data, updatedFrom } = req.body;
// ここが肝：「担当者がCodex Botに変わった瞬間だけ」を検出
const CODEX_BOT_ID = process.env.CODEX_BOT_USER_ID;
const isAssignedToCodex =
type === 'Issue' &&
action === 'update' &&
data.assigneeId === CODEX_BOT_ID &&
updatedFrom?.assigneeId !== CODEX_BOT_ID; // 変更前はCodexじゃなかった
if (!isAssignedToCodex) {
return res.status(200).json({ skipped: true });
}
// GitHub Actionsをキック
await triggerGitHubAction({
issue_title: data.title,
issue_body: data.description,
issue_identifier: data.identifier,
});
res.status(200).json({ triggered: true });
});
updatedFrom.assigneeId !== CODEX_BOT_ID の条件が二重起動を防ぎます。Linearはコメント追加やラベル変更でも通知を飛ばしてくるので、ここを省くと同じIssueでCodexが何度も走り出します。
Step 2：GitHub Actionsのworkflow
.github/workflows/codex-implement.yml に書きます。
name: Codex Auto Implementation
on:
repository_dispatch:
types: [linear-codex-assigned]
jobs:
implement:
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
steps:
- uses: actions/checkout@v5
- name: Run Codex implementation
uses: openai/codex-action@v1
with:
openai-api-key: ${{ secrets.OPENAI_API_KEY }}
prompt: |
以下のIssueを実装してください。
タイトル: ${{ github.event.client_payload.issue_title }}
説明: ${{ github.event.client_payload.issue_body }}
識別子: ${{ github.event.client_payload.issue_identifier }}
- テストも必ず書くこと
- 既存のコードスタイルに合わせること
safety-strategy: drop-sudo
sandbox: workspace-write
- name: Create Pull Request
uses: peter-evans/create-pull-request@v6
with:
token: ${{ github.token }}
title: "[${{ github.event.client_payload.issue_identifier }}] ${{ github.event.client_payload.issue_title }}"
body: |
Linear Issue: ${{ github.event.client_payload.issue_identifier }}
Codexによる自動実装。レビューをお願いします。
branch: "codex/${{ github.event.client_payload.issue_identifier }}"
reviewers: "your-team-reviewer"
reviewers に人間のレビュアーを設定することを忘れないでください。自動化しながら、責任の所在だけは手放さないのが安全な運用の基本です。
Step 3：Codexのレビューworkflow
PRが作られた後は、別のworkflowでCodexにレビューさせます。実装とレビューを別のjobに分けることで、どちらかが失敗しても他方に影響しません。
name: Codex PR Review
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v5
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- name: Pre-fetch refs
run: |
git fetch --no-tags origin \
${{ github.event.pull_request.base.ref }} \
+refs/pull/${{ github.event.pull_request.number }}/head
- name: Run Codex review
id: run_codex
uses: openai/codex-action@v1
with:
openai-api-key: ${{ secrets.OPENAI_API_KEY }}
prompt-file: .github/codex/prompts/review.md
output-file: codex-review.md
safety-strategy: drop-sudo
sandbox: read-only
- name: Post review comment
uses: actions/github-script@v7
with:
github-token: ${{ github.token }}
script: |
const fs = require('fs');
const review = fs.readFileSync('codex-review.md', 'utf8');
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
body: `## Codex Auto Review\n\n${review}`
});
Step 4：AGENTS.mdでレビュー基準を固定する
レビューが毎回ぶれる問題は、AGENTS.md を置くことで解決できます。
リポジトリルートに置くと、Codexはタスク開始前にこのファイルを読みます。
## Review guidelines - PII（個人情報）のログ出力を禁止する - すべてのAPIエンドポイントに認証ミドルウェアが適用されているか確認する - テストカバレッジが下がるような変更をP0として扱う - 型定義が不明瞭なコードをP1として指摘する ## Implementation guidelines - `npm test`を必ず実行してからコミットする - 既存の命名規則に従うこと - 新しい外部依存を追加する前に確認を求めること
ディレクトリ階層に合わせてファイルを分散配置することもできます。パッケージごとに違う基準を持ちたい場合に便利です。
ハマりやすい4つのポイント
1. 二重起動
冒頭のコード例で示したように、updatedFrom との差分チェックを必ず入れること。Linearは担当者変更以外でも通知を飛ばします。コメント追加、ラベル変更、ステータス更新、すべてにWebhookが走るので、条件を絞らないと同じIssueでCodexが何度も起動します。
2. Issueの粒度
Codexに渡すIssueの本文がふくらみすぎると、実装範囲が曖昧になります。「1 Issue 1責務」に寄せることが大事です。
たとえば「ユーザー認証周りをリファクタしてほしい」は広すぎますが、「/api/users エンドポイントのJWTバリデーションを auth.middleware.ts に分離する」なら渡しやすくなります。
これはAI相手に限らず、人間でも同じです。ただ、人間は「だいたいわかった」で動けてしまうのに対し、Codexは文脈の補完に限界があります。この部分は人間側が学ばなければいけない部分でもあります。
3. セキュリティ設定
openai/codex-action には safety-strategy の設定があります。
drop-sudo
パブリックリポジトリで使う場合は drop-sudo を必ず設定すること。設定しないと、CodexがAPIキーを読み取れる状態になる可能性があります。ここは必ず丁寧に設定したいポイントです。
4. レビュー担当者の明示
PRを自動作成しただけでは「誰が最後に見届けるか」が曖昧になります。create-pull-request の reviewers フィールドに人間のレビュアーを必ず指定してください。
Codexレビューはあくまで一次チェックで、承認権限は人間が持つ。これを省くと、自動化したはずのPRが結局押し付け合いになります。人間が確認するのは最終確認だけなので、ここは明確にしておくのが大切です。
段階的に始めるおすすめの進め方
最初からフル自動実装に行く必要はありません。むしろ最初から全部つなごうとすると、どこで失敗したか追いにくくなります。順番にやっていくのがコツです。
Phase 1（Webhook + Issue作成のみ）
Linear担当変更 → Webhook受信 → GitHub Issueの雛形作成 → 人が実装
Webhookが正しく動いているかを確認するだけの段階です。GitHub Issueにタイトルと説明が飛んでくるだけでも、手間は減ります。
Phase 2（Codex実装 + 人レビュー）
Linear担当変更 → Webhook → Codex実装 → PR作成 → 人がレビュー・承認
ここで初めてCodexに手を動かさせます。Codexが作ったPRを人間がちゃんとレビューできる状態を確保してから次に進みます。
Phase 3（Codexレビュー + 人が最終承認）
Linear担当変更 → Webhook → Codex実装 → PR作成 → Codexレビュー → 人が最終承認 → Slack通知
Codexが一次レビューまで担う形です。人間は最終承認だけでよくなります。
Phase 2で一度踏みしめてからPhase 3に進んだほうがいいです。自動化は、成功の速度より失敗の見え方のほうが大事なことがあります。何かがおかしくなったとき、どのレイヤーで止まっているかわかるか。それが設計の肝です。
まとめ
この仕組みの構造はシンプルです。
- Linear → Webhookで開始条件を作る（
updatedFromで差分を取る） - Webhook受信サーバー → 条件判定してGitHub Actionsをキック
- GitHub Actions → Codexを実行、PRを作成
- Codex → 実装担当とレビュー担当を別のjobで役割分担
-
AGENTS.md→ レビュー基準を固定し、毎回ぶれないようにする - 人間 → 最終承認と、責任の所在を持ち続ける
うまくハマると「小さな定型開発」は本当に一段軽くなります。全部自動にするより、人間が判断すべき場所を守りながら、それ以外を委ねる。そのバランスをどこに引くかを探るのがとても大事です。
転載元
※XAが運営するNoteメディアの記事を転載しています。
“つくる火”を分かち合うメディア「Created To Create」
