エージェント運用
Plan・調査の任せ方・6ルール。
エージェント運用 — 6つの基本ルール
Plan 先・調査委譲・lessons・検証・簡潔さ・自律修正。詳細は下の折りたたみと agent-workflow-orchestration.mdc。
| # | ルール | 参照 |
|---|---|---|
| 1 | Plan で始める | Phase 2 Plan |
| 2 | 調査は別 AI に任せる | マルチエージェント |
| 3 | lessons に残す | lessons · tasks/lessons.md |
| 4 | 完了前に検証 | 検証 |
| 5 | 簡潔さ | 単純修正に過剰設計しない |
| 6 | 自律的バグ修正 | バグ修正（git は許可後） |
定期ワークフロー（4要素）
都度チャットで依頼する作業と、トリガーで回す作業を分ける。チャットは答えるだけ、ワークフローは成果物を渡す。
| 要素 | 開発での置き場 |
|---|---|
| ROLE | .cursor/rules/ · AGENTS.md · SKILL.md |
| TOOLS | MCP（GitHub · CI）· gh · テストコマンド |
| TRIGGER | Cursor Automations · Hooks · /loop · CI Webhook |
| OUTPUT | Issue コメント · digest メモ · Draft PR 案（マージは人間） |
最初の1本: CI 失敗 digest（失敗ジョブ · エラー要約 · 次アクション1行）。git push / マージは人間。
CI 失敗 digest — プロンプト例
ROLE: CI 失敗要約。憶測で原因を断定しない。
TRIGGER: main の CI が red になったとき（または平日朝の定期確認）
TOOLS: GitHub MCP / gh cli — 読み取りのみ
OUTPUT: 1メッセージ（FAILURES / LIKELY_CAUSE / NEXT_ACTION 各3行以内）
制約: 自動修復・push 禁止。修正案は diff 案まで。実装手段: 委譲 · /loop · Hooks。Loop トレンド早見 → memo Loop engineering。一般業務の型 → 4要素早見。参考: @0xchromium · @samueljmcd（verifier） · @steipete（2026-06）。
6つの基本ルール・タスク管理（詳細）
- Plan で始める — 完了条件・検証ステップまで書く（Plan 成果物）
- 調査は別 AI に任せる — 1担当=1タスク。メイン会話を散らかさない
- lessons に残す — 指摘パターンを
tasks/lessons.md→ 再発時に rules へ - 完了前に検証 — テスト・curl 等で動いたことを示す
- 簡潔さ — 単純な修正に過剰設計しない
- 自律的バグ修正 — git push 等はユーザー許可を待つ
Plan 置き場パターン・適用シナリオの詳細は ルールサンプル と上記 .mdc を参照。
会話の文脈管理（2026）
AI の回答の質は、渡す情報の量より、余計な情報が少ないかで決まる。下表は状況別の推奨。
| 状況 | 推奨 |
|---|---|
| コードベースの調査・「どこにある？」 | ファイルを総 @ しない。自然言語で領域を指定。必要なら 1 ファイルだけ @ |
| ブランチ上の作業・レビュー | @Branch で差分コンテキストを渡す |
| 前セッションの続き | 会話全文のコピペではなく @Past Chats で選択的に参照（手順: ルール/プラン — @Past Chats） |
| 別タスク・別機能に着手 | 新規チャット。Plan（チャット or ファイル）/ ADR / 必要なら tasks/todo.md を正式な記録に |
| 同じ機能の反復・デバッグ | 同一会話を継続（直前の実装文脈が必要） |
| エージェントが同じミスを繰り返す | 会話を切り、ルールを 1 条追加してから再開 |
| 広い調査・並列分析 | 別の AI 担当（Task）に委譲し、結果だけメインへ（調査の任せ方） |
ツール横断の整理・公式 BP 対応表: ルール/プラン — 3ツール横断 · 公式ドキュメント。プロンプト: プロンプト設計。
分解・並列・検証の分離（2026-07）
出典: Claude Code — Best practices（公式）· 2026 上半期のコミュニティ検証。エージェント時代に効くのは仕事の分解の設計 — どのタスクが自己完結か、どの出力が短く要約できるか、人間レビューのゲートをどこに置くか。
切り出す単位の目安
| 形 | 使う場面 | 例 |
|---|---|---|
| Command（スラッシュコマンド） | プロンプトの定型文で足りるとき | /verify · /standup |
| Skill | ドメイン手順・補助ファイルが要るとき | PR レビュー観点 + チェックリスト同梱 |
| Subagent | 隔離して並列に走らせたい・結果だけ欲しいとき | 広い調査 · 大量ファイルの横断確認 |
並列数の目安
- 並列 subagent は 3〜5 が費用対効果の山。10 を超えても精度はほぼ上がらず、コストとレビュー負荷だけ増える
- 並列にするのは出力を短く要約して返せるタスクだけ。要約できない（diff 全文が要る等）ものはメイン会話で扱う
- ブランチ衝突を避けるなら worktree 並列 と組み合わせる
検証の分離 — 作った本人に採点させない
- 実装した会話（エージェント）に「動いた？」と聞かない。別の verifier（新しい会話 or 検証 subagent）に反証を試みさせる
- verifier に渡すのは完了条件と検証コマンドのみ。実装の経緯を渡すと採点が甘くなる
- 機械で検証できるもの（テスト・lint・curl）は ルール4（完了前検証）どおり自動で。人間レビューは設計判断とセキュリティ境界に集中させる