コードもプロンプトも書かないIssue駆動開発 〜Linear MCPとCodexとReview AgentとAgent Skillと〜

2026-03-14

プロダクションコードやコードを生成するためのプロンプトを人が書くと，

  • 時間がかかる
  • 実装品質のばらつきが生まれる

ため，コーディング・プロンプティングでの人間の介入を極力減らして，成果物レビューと承認以外の人間の作業はなるべくゼロにしていこう！の実践記です。

2026年現在で普通のことしかやっていないのですが，足跡として残します。Issue駆動開発という名前の通り，Issue以前のブレストやステークホルダーが関わる仕様調整やタスクのブレークダウンは対象にしていません。

TL;DR

Issue を作ったら，あとはPRマージまで人間は作業をしない。エージェントの監督と指示も最小限。

AI成果物のレビューと動作検証と承認はちゃんとする。

(mocobeta式)Issue駆動開発のプロンプトは５つのみ：「Issue ### を読んで実装計画を立てて」「実装計画をIssueにコメントして」「Issue ### の実装計画を読んで実装して」「PR作成して」「レビュー指摘に対応して」

使うもの

  • Linear / Linear MCP
    • Jira, Notion でも代替可だけど，Linearのほうがストレスフリー＆タスク管理効率が高い
  • Codex
    • Claude, Cursor その他で代替可
  • Agent Skills

ミッションコンプリートまでのステップ

赤字：人間がやること

青字：コーデイングエージェントがやること

  1. 準備：Codex にLinear MCPサーバーをインストールしておく。実装中に無駄なapprove待ちが起こらないように，実装作業で必要なコマンドへのpermissionをCodexに与えておく。
  2. LinearにIssueを立てる（セーブポイント①）
    • Issueタイトルはタスクのゴールを書く。
    • Issue本文にはどうやってゴールを達成するかを書く。要件，実装方針，テスト方針など，それぞれ数行程度で，宣言的に明確に言語化しておく。
  3. CodexにIssueを読ませ，Planモードで開発計画・実装方針を立てさせる
    • 壁打ちはここで
  4. 作った実装計画をCodexを使ってIssueにコメントさせる（セーブポイント②）
    • どういう意図での実装か，未来のCodexと自分とチームメンバーがアクセスできるように残しておく。
  5. Issueコメントに書いた実装計画をCodexに読ませて実装計画通りに実装させる
  6. CodexにPRを作成させる（セーブポイント③）
  7. Review AgentにPRレビューさせる（CI workflow）
  8. レビュー指摘をざっと全部読んで，対応しないと決めたコメントは理由を書いてResolve
    • レビュー指摘をスルーしない。大抵の不具合と障害はReview Agentのレビュー指摘にきちんと対応していれば防げる。
  9. Codexにレビューコメントへ対応させる
  10. 成果物の実装と動作をざっと確認
  11. チームメンバーにレビュー依頼を出す
    • チームメンバーからのレビュー指摘をコーディングエージェント向けに書き換えて，レビューコメントを追加する。（レビュー指摘が明快ならそのままで良い）
  12. Codexにレビューコメントへ対応させる
  13. マージ 🎉

Agent Skill

いろいろあるけど，特に

  • branchとworktreeを良い感じで管理するスキル
    • これはCodex Appを使い始めるといらなくなる
  • コミット・PRを良い感じで作成するスキル
  • PRレビュー指摘に良い感じで自動対応するスキル

を空気のように使っています。

気をつけていること

  • 開発環境のセットアップを人間がコマンド叩いてやったら負け
  • コードを手で書いたら負け
  • コード調整のためのプロンプトを手で書いたら負け
  • Codexのチャット欄にテキストをコピペしたら負け
  • テストやLinterやFormatterが通らないコードをGitHubにPushさせたら負け
  • New Codeのカバレッジが90%を下回ったら負け
  • 動作しないコードをGitHubにPushさせたら負け
  • コーディングエージェントに書かせたコードが不具合を生んだら負け（それはそう）

と思ってワークフローとハーネスを改善しています。まだまだ達成できていないから精進必要。

FAQ: 実際のところ時間効率はどう？

体感で：

  • スピード：設計（調査・計画含む）と実装フェーズは１０倍以上
  • スループット：人間のマルチタスク能力の限界があり，今のところ４並列くらい。ハーネスがうまく設計できればこの１．５〜２倍くらいはいけそう

FAQ: 設計方針やドメイン知識はどこに置く？

個人的には：

フローナレッジは，WYSIWYGエディタがあるLinearかNotionに書く。タスクがアクティブな間はチームメンバーと共有でき，必要ならすぐに誰かに引き継げるようにセーブポイントを作る。

将来にわたって共有必須レベルのストック知識はリポジトリに残しておくのが良いだろうが，これってコミットすべき？どうやって整理したらコンテキスト肥大化・汚染が発生しないか？と迷う時間はもったいないので，置き場所に迷う時はLinear, Notionにセーブして先に進む。

FAQ: いうてプロンプト書いてるじゃん

すまん

FAQ: それよりボトルネックは人間同士の意思疎通と合意形成なんですが

そうなんですよね。ステークホルダーとの合意形成が一番難しいですが，とはいえまずはツールレベルでできる効率化・品質改善に取り組むと，人間同士のコミュニケーションにもいい影響を与えます。 🤝

https://blog.mocobeta.dev/posts/feed.xml