Go back

Grok の並列マルチタスクで MT プラグインを一気に進めた記録

Posted on:

Movable Type の MCP プラグイン（mt-plugin-mcp）を、Cursor の Grok（Grok 4.6）とマルチタスク・サブエージェントで一気に進めた。そのときの学びを、いったん全部書き出す。きれいに整える前の素材置き場。

触った親 issue は 実装ロードマップ #26。P1/P2 を実装して閉じ、積む分は 検討中 #44 に移した。

やったことのざっくり時系列

  1. Issue #26 の P1（Folder / Page / TemplateMap / Widgetset）をサブエージェントで実装
  2. 機能ごとに 別コミット・別 PR（#27〜#30）。Protocol.pm などが共有なので スタック
  3. P2 を issue ごと別 worktree・別 PR（#31〜#37）。独立なものは同じ base から並列、依存は直列
  4. GitGuardian がテスト用パスワードを拾った → HEAD 修正だけでは足りず、履歴から消して force-push
  5. 並列 PR が main に入るたびに コンフリクト。base をマージして通常 push
  6. CodeRabbit コメント対応
  7. 意図的に外したギャップを整理。全部スキップしてよいわけではなかった
  8. 後続 issue を起票（#38〜#40）。親のサブ issue 化を忘れ、あとから API で付けた
  9. README を導入中心に、ツール一覧は docs/ へ（#41 / PR #43）。AGENTS.md は別 issue（#42 / PR #45）
  10. P3 と後続を 検討中の親 #44 へ移動して #26 をクローズ
  11. 後続は #38 → #39 → #40 export → #40 import の順で別 worktree（PR #46/#48/#49/#50）
  12. 人間向けオンボーディングは別エージェント・別 worktree（PR #47）
  13. リモートタグの v 漏れを直し、main HEAD に v0.7.0

Grok を使った並列開発（マルチタスクエージェント）

Cursor 側の動き

親エージェントはコーディネータに寄せた。調査・実装・テスト・PR 作成はバックグラウンドのサブエージェントに渡す。親は「何を・どの順で・どこまでやってよいか」をプロンプトに書く。

うまくいった渡し方:

  • 1 リクエスト = 1 つの一貫した仕事（P1 実装、コンフリクト解消、issue クローズ、など）
  • 独立している仕事だけ 親から複数エージェントを同時起動（後続ツール列とオンボーディング docs は別ストリーム）
  • 依存がある仕事は 1 エージェントが内部で直列（#38 が push されてから #39 の worktree、のように）
  • 作業場所は dirty な元 worktree を使わず git worktree add で隔離
  • コミットは git add . 禁止、名前付きファイルだけ。force-push は明示承認があるときだけ

親から見た並列の形はこう。独立ストリームだけ同時に切り、依存は子の中で直列にする。

失敗しやすい渡し方:

  • 同じ worktree に複数エージェントを同時に入れる（ファイルがぶつかる）
  • 「P2 全部並列」とだけ言って Protocol.pm の共有を無視する
  • サブエージェントが終わったあとに親が同じ調査をやり直す（無駄）

並列化してよいものと、してはいけないもの

コードが独立でも、登録簿は共有だった。このリポジトリではだいたい次がぶつかる。

  • plugins/MTMCP/lib/MTMCP/Protocol.pm（ツール登録）
  • README.md / のちの docs/tools.md
  • config.yaml のバージョン
  • t/lib/ のスタブ

なので:

  • 並列してよい: Folder.pm と Page.pm のようにモジュールとテストが分かれている実装
  • 直列にする: Protocol への配線、README、バージョン bump、同じ Template.pm を触る変更
  • スタックする: 実装は並列に進めても、PR の base は「先に入る枝」にする

P2 では keyword / tag / log を同じ add/widgetset から同時に切った。それぞれ独立に見えるが、先頭 PR 同士が Protocol と README で衝突する。マージはスタックを直列にしないと毎回コンフリクトする。

実装はモジュールを横に並べ、配線とマージだけ縦にする。P2 の 3 スタックは先頭同士がぶつかるので、スタックの中だけでなくスタック同士も直列。

サブエージェントに必ず書かせた制約

  • P3 を勝手に実装しない
  • main へ force-push しない
  • フックを飛ばさない
  • 秘密情報をログに出さない
  • 元 worktree の未コミット P1 を巻き込まない

「やらないこと」を先に書くと、エージェントがロードマップを先読みして P3 まで作ることが減った。

Grok と Claude の体感（リミットと余裕）

同じような「issue を分解してエージェントに実装させる」を Claude 側でもやると、すぐリミットに当たった。長いコンテキスト、サブエージェントの往復、PR コメント対応、コンフリクト解消のログが重い。

Grok は、このセッションでは リミットを気にせず P1 → P2 → ラップアップ → 後続 → docs まで続けられた。体感の差は「1 本の賢い会話」より 何本も同時に回せるか に出た。ストリームごとの時刻と件数は、下の「並列セッションの数字」に置いた。

ドル金額は出さない。Cursor の Usage ダッシュボード（2026-08-15 分）では Included が 7.3M、On-demand は 0 だった。New Relic ではこのセッションの費用は取れなかった。

「速い」の中身は、モデルが Perl を速く書くことより、待ち時間を別ストリームで埋められることだった。オンボーディング docs を書いているあいだに #38〜#40 のスタックが進む、という使い方。

タスクを回すときの issue の作業順と整理

親 issue はロードマップ、子は実装単位

#26 は「Data API 由来のツールをどの順で足すか」の親。P0/P1/P2/P3 と対象外（NOT_PLANNED）が書いてあった。

実装 PR は 子 issue 1 つ（または明確なスライス）につき 1 PR にした。

  • P1: #8 Folder、#5 Page、#12 TemplateMap、#13 Widgetset
  • P2: #19 keyword、#6 preview、#14 tag、#7 category / category set、#15 log、#10 user

「全部 #26 に突っ込む巨大 PR」はレビュー不能。逆に「ファイル単位のミクロ PR」は Protocol の配線が毎回コンフリクトする。機能境界 × 依存のスタックがちょうどよかった。

作業順の決め方

  1. Issue 本文から P1/P2 と依存グラフを書く
  2. 独立モジュールから並列実装
  3. 共有スタブ → 各ツール → Protocol / README は直列
  4. マージは 下の層から（フォルダの次にページ、のようにプロダクト依存があるならその順）
  5. コンフリクトしたら「最新 main を feature にマージして通常 push」。履歴を勝手に rebase しない（承認がない限り）

P2 の実マージはおおよそ:

  • 先に P1 スタック #27 → #28 → #29 → #30
  • そのあと P2 は 3 本のスタック（keyword→preview、tag→category→set、log→user）
  • 先頭同士は Protocol が衝突するので、スタック同士も直列マージが安全

後続は明示の順にした。

#38 user_update → #39 page_delete のアーカイブ掃除 → #40 export → #40 import

import は安全ゲート（confirm: true、既定 draft、サイズ上限）がいるので最後。export と import を 1 PR にしない。

「積む」と「後続」を混ぜない

これが一番整理で効いた。

種類 意味 例
今やる この親の完了条件 P1/P2、README/AGENTS ラップアップ
後続 今の親から切ったが、本体待ちではない user_update、page のファイル掃除、import/export
積む（P3） 技術的に不可能ではなく 今はやらない サイト CRUD、Stats、backup、migrate_*
NOT_PLANNED 必要なら再起票。親の積むリストに載せない ロール grant/revoke、テーマ、プラグイン

P3 は「できなかった」ではない。サイト削除はテナント破壊、Stats は GA 未設定で失敗する、backup は restore なし巨大ファイル、移行は専用ツールを作らない、という 判断。

後続は P3 と別枠。親 #26 の「積む」に混ぜると、「#26 が開いている＝まだロードマップ未完」が終わらなくなる。

実際の操作:

  • 後続 3 件を起票（#38〜#40）
  • ラップアップ（#41 docs、#42 AGENTS.md）は #26 に残す
  • P3 と後続を新親 #44 検討中 のサブ issue にする
  • #41/#42 の PR が main に入ったら #26 を閉じる

GitHub のサブ issue は本文リンクではない

関連: 親 #26 と本文に書いただけでは サブ issue にならない。parent は null のまま。

REST は issue number ではなく database id を integer で渡す。文字列だと 422。

起票したらすぐサブ issue API で付ける。あとから「なってる？」と確認することになった。

意図的に外したものは、issue を読まないと危険

「今はやらない」を全部スキップしてよいわけではなかった。

  • 積んだ方がよい: #6 の import/export（後続と書いて CLOSED のまま）、#5 の page_delete 後の孤立 HTML
  • 積まなくてよい: grant/revoke、ログ書き込み、template_preview の page_id、permutate_folders、widget 専用 CRUD
  • 必要なら別 issue: user_update（#10 の必須ツール一覧に無かった）

親に「積まなかった理由」をコメントしておかないと、数週間後に「なぜログ write が無いのか」が issue から消える。

ドキュメントの切り方

README にツール 50 件超を置くと、インストール手順が埋もれる。

  • README: インストール、Apache、トークン、クライアント、prove、リンク
  • docs/tools.md: 何ができるか、権限、警告
  • docs/guides/: 人間向け「記事を作る」「CT を作る」
  • docs/developer-onboarding.md: 人間の開発者向け
  • AGENTS.md: エージェント向け（触る場所、P3 を勝手に進めない）
  • Claude Skill (#23): まだ OPEN。人間ガイドの要約を AI コンテキストに載せる想定

正本は人間向けガイド。Skill はコピー先。tools.md は引数と権限の正本。AGENTS.md を開発者オンボーディングの代わりにしない。

マージと Stacked Pull Requests

並列で実装すると、PR は増える。困るのは GitHub 上で 全部 main 向けに見えて、依存順が分からなくなること。

Stacked pull requests（public preview） は、大きい変更を短い PR の列にする。各 PR は下の層を base にする。レビューは層ごと。マージは下から、またはスタックごと。公式アナウンスは GitHub Changelog（2026-07-30）。

今回効いた点:

  • P1 は Folder → Page → TemplateMap → Widgetset。下をマージすると上が追従しやすい
  • P2 の 3 スタック、後続の #46→#48→#49→#50 も同じ
  • 並列実装で起きたコンフリクトは、同じファイルを 3 本が main から同時に変えるから起きる
  • Stacked の順でマージすると、2 本目以降は「すでに入った兄弟」ではなく「自分の下の層」との差分になる。スムーズだった
  • 逆に、スタックを無視して #32 と #31 を両方 main に向けたまま交互にマージすると、README が毎回衝突する

#48 をマージしたあとの実スタックがこれ。下から main → #46（Merged）→ #48（Merged、current）→ #49 / #50（Ready）。

GitHub の Stacked PRs。#46←#48←#49←#50。#48 マージ後で current が page_delete

公式の「1 クリックで下の層までまとめてマージ」は、ブランチ保護と Checks が層ごとに付く前提。こちらはコンフリクトが出た層だけ origin/main を feature にマージして通常 push した。force-push しない方針と両立する。

エージェントへの指示も「独立 PR を default branch から」より、依存が本物ならスタックと書いた方が事故が少なかった。

並列開発で起きたトラブルと対処

GitGuardian は HEAD だけでなく PR 内の全コミットを見る

t/user_tools.t のダミーパスワードが Generic Password になった。HEAD を changeme にしても、初回コミットに残っていると Checks は赤のまま。

対処: 明示承認のうえで 2 コミットを 1 つに squash し、--force-with-lease（main ではない feature ブランチ）。実クレデンシャルではなかったのでローテーションは不要。

教訓: テストの秘密っぽい文字列は最初から changeme にする。スキャナーは履歴も見る。

コンフリクトは README が本命

コードの自動マージは意外と通る。人間が直すのは権限注記の箇条書きと、テストスタブのメソッド追加。両側のツールを残すのが正解で、片方を取るのは事故。

サブエージェントのタイムアウト

worktree 解決で 30 秒タイムアウトした。同じ指示で打ち直して通った。親は「失敗した子の仕事を自分でやり始めない」。打ち直す。

タグは v を揃える

リモートに 0.4.2 と v0.1.0 が混在していた。同じコミットに v0.4.2 を打ち、旧タグと Release を付け替えた。main HEAD の版（config.yaml 0.7.0）に v0.7.0 を打った。

並列セッションの数字

親チャットは 2026-08-14 21:30 JST に始まっている（transcript の先頭）。P1 実装から v0.7.0 公開（08-15 08:03 JST）まで、時計のうえでは約 10 時間半。中身は夜の実装塊（21:30〜23:46）と翌朝のラップアップ（07:23〜08:03）で、そのあいだは #43 のマージ待ちが長い。

時刻の取り方:

  • PR の作成・マージは GitHub の createdAt / mergedAt（UTC）を JST にした。ここは正確
  • エージェントの所要は、指示の timestamp と transcript ファイルの最終更新。終了時刻は分単位の目安
  • prove の件数は各ストリームが報告した値。スイート全体の合計ではない（同じ folder.t を何度も数える）
  • +/- 行は各 PR の GitHub 差分。スタックなら base との差分なので、層を足すと実装量の目安になる
並列ストリーム 内容 期間の目安（JST） PR テスト（prove 報告） 備考
P1 実装 Folder / Page / TemplateMap / Widgetset 08-14 21:30〜21:45（約 15 分） まだ無し 6 files / 324 tests PASS worktree y4vv。内部で 3 本（21:35 起動）
P1 PR 分割 #27→#30 スタック エージェント 21:50〜22:02。PR 作成 22:00〜22:02、マージ 22:49〜22:52 4（#27〜#30） 分割時は prove を再実行していない オープン約 50 分はほぼ CI 待ち
P2 3 スタック keyword→preview、tag→category→set、log→user コーディネータ 22:07〜22:36。ワーカー 22:11〜22:35。PR 作成 22:17〜22:35、マージ 22:54〜23:17 7（#31〜#37） スライスごと（下表） 先頭同士が Protocol / README で衝突
ラップアップ README→docs、AGENTS.md #43: 23:40〜23:46 作成、翌 07:08 マージ。#45: 07:23〜07:28 #43 #45 ドキュメントのみ #43 は夜作成・朝マージ
後続ツール #38→#39→#40 export→#40 import エージェント 07:41〜07:52（約 11 分）。PR 07:44〜07:59 #46 #48 #49 #50 78 / 101 / 25 / 54 直列スタック。オンボーディングと同時起動
オンボーディング 人間向け docs（#22） エージェント 07:41〜07:46（約 5 分）。PR 07:46〜08:00 #47 なし 後続と同じ 07:41 に親から並列起動

P2 の prove はストリームごとにこう報告されていた。

PR スライス prove
#31 keyword LIKE 4 files / 138
#32 log 読み取り 当該 72。周辺込み 8 files / 396
#33 tag rename/delete 7 files / 389（P1 テストを含む）
#34 entry_preview 4 files / 157
#35 記事カテゴリ write 240（category / folder / tag / page）
#36 user 管理 3 files / 133
#37 category set category_set / category_write / folder / CT が PASS（件数は transcript に無し）

後続とオンボーディングの重なりは、エージェント実働で 約 5 分（07:41〜07:46。そのあと後続だけが 07:52 まで）。PR が同時に開いていた時間は 約 13 分（#47 の 07:46〜08:00 と、#46〜#50 の 07:44〜07:59）。壁時計では docs を書いているあいだに 4 PR が進んだ、で合っている。

GitHub 上のこの波（#27〜#37, #43, #45〜#50）は 18 PR。差分の合計は約 +15,295 / −611（スタックの層を足した値）。v0.7.0 は 08-15 08:03 JST 公開。

スピードと費用感

上の表が「速さ」の中身。

短かったもの（エージェント実働）

  • P1 4 機能の実装: 約 15 分（モジュール並列、配線は直列）
  • P1 の 4 PR 切り出し: 約 12 分
  • P2 7 PR: 実装〜作成まで約 30 分（最大 7 worktree）
  • 後続 4 PR: 約 11 分（中は直列）
  • オンボーディング 1 PR: 約 5 分

長かったもの（並列にできない）

  • P1 スタックのマージ: 作成から約 50 分（CI）
  • P2 マージ: 最後の作成 22:35 から最後のマージ 23:17 まで約 42 分。コンフリクトで origin/main を取り込み直した
  • #43: 作成からマージまで約 7 時間（夜→朝）
  • GitGuardian の履歴 squash、方針確認、CodeRabbit の 1 件ずつ

Claude と同じ「issue を分解してエージェントに実装させる」をやると、こちらでは すぐリミットに当たった。Grok はこの親セッションを夜から朝まで続けられた。差として確かなのはそれだけで、モデル単価の比較はしていない。Claude 側のリミット画面は今回撮っていない。

トークン量は Cursor の Usage（2026-08-15 のみ）で見えた。合計 7.3M。内訳は Included 7.3M、On-demand 0。モデル別は cursor-grok-4.6-high が約 4.5〜4.7M、cursor-grok-4.6-medium が約 2.6〜2.8M。ドルは出さない。New Relic ではこの作業の費用は取れなかった。

Cursor Usage。2026-08-15 の Included 7.3M、On-demand 0。high と medium の内訳

リクエスト表では、同じ分に複数行が並ぶ。並列バースト。1 行で 225.8 万トークン（high）もある。

同日のリクエスト表。Included。同じ時刻に複数行。high で 225.8 万の行

プラン側の枠は Cursor Pro の Included in Pro。Cursor Models（Grok と Composer）は 17% used、Other Models は 9% used。Cursor Models を使い切ったあとは Other Models の枠か on-demand に乗る。Other Models には少なくとも $20 の API usage が含まれる、と画面に書いてある。どちらもまだ大半が残っている。7.3M トークンを積んでも、Grok 側の枠は余裕、という話の根拠。

Cursor Pro の Included in Pro。Cursor Models 17% used、Other Models 9% used

並列は壁時計を短くする。合計トークンは増える。親がコーディネータに徹すると、同じ調査を 3 回やらなくて済む、という話は残る。

次に記事にするときの構成案

公開用に削るなら、この 3 本立てで足りる。

  1. Grok + Cursor のマルチタスクで MT プラグインを並列実装した
  2. issue の親・積む・後続を分けないとロードマップが閉じない
  3. 並列 PR のコンフリクトは Stacked PRs の順でマージすると楽

コード片は最小。リンクは #26、#44、Stacked PRs の Changelog、リポジトリ。スクショはスタック UI と Cursor Usage（8/15）を置いた。Claude リミット画面は無し。

残っていること（記事の「いま」）

  • P3 は検討中のまま（#44）
  • Claude Skill（#23）は未着手
  • 人間向けオンボーディング #47、後続 #46/#48/#49/#50 は 08-15 朝にマージ済み。v0.7.0 公開済み
  • Cursor 用 Skill の issue は無い

自分用チェックリスト（次のリポジトリでも）

  • 親 issue に今やる / 後続 / 積む / やらない を先に書く
  • 実装 PR は機能単位。共有ファイルがあるならスタック
  • エージェントには worktree を分ける。dirty な木を共有しない
  • 独立実装は並列、Protocol 配線とマージは直列
  • サブ issue は API で parent を付ける
  • テストに秘密っぽい文字列を置かない
  • README にカタログを増やさない。docs へ逃がす
  • タグは最初から v
  • リミットが浅いモデルでは「巨大 1 エージェント」より「短い指示の並列」より先に、作業を日をまたがないサイズに切る