本番事例の解剖 ─ パターン語彙で読み解く 7 製品
第1部 ch10 で 7 製品を **6 レイヤ（部品）**で解剖した。本章は同じ 7 製品を **パターン語彙（並べ方）**で解剖する。
これにより、各製品が「何を採用し、何を諦めたか」が言語化できる。読者は自分のチームで組むときの参考にしてほしい。
7 製品 × パターン語彙のマトリクス
| 製品 | 主要パターン | トポロジー | HITL の差し込み | 諦めたもの |
|---|---|---|---|---|
| Cognition Devin | Single Agent + Plan-and-Act + Reflexion | Single + sub-task delegation | Synchronous（PR review 必須）+ Retroactive | Mid-task の要件変更追従、ソフトスキル |
| Manus AI | Orchestrator-Workers + ReAct + CodeAct | Multi-agent（Planner / Execution / Verification） | 公開資料上は明示なし [要検証] | Sub-agent のメモリスコープ汚染の自動解決 |
| ChatGPT Agent / Operator | Autonomous Agent + Harness+Sandbox | Single agent（virtual computer） | Synchronous + Watch mode（sensitive sites 強制） | 銀行送金等の高リスクタスクの完全自律 |
| Replit Agent 3 | Evaluator-Optimizer + Hierarchical | Hierarchical（Stacks）+ Self-healing loop | Default は App Testing / Max Autonomy 切替 | 200 分連続自律のために短期介入頻度 |
| GitHub Copilot Coding Agent | Pipeline + Evaluator-Optimizer | GitHub Actions ベースの ephemeral env | Synchronous（Draft PR レビュー、CI/CD 起動） | Push 直接実行 |
| Anthropic Claude Code | Single Agent + Voyager（Skills）+ Reflexion | Single（nO loop）+ Task Agent sub-agent | Permission system（allow/deny）+ Auto Mode classifier | 多エージェント並走の自由度 |
| Cursor / Composer | Plan-and-Act + Pipeline | Plan / Execute の二段階分離 + Cloud Agent（旧 Background Agent） | Synchronous（Plan 承認）+ intervene 可能 | Plan 承認を経ない突発実行 |
各製品の解剖
Cognition Devin ── 「Single Agent の極北」
主要パターン：Single Agent + Plan-and-Act + Reflexion
Devin は Cognition AI チームが「マルチエージェントは前提衝突を起こす」というスタンスに基づき、徹底的に Single Agent で押し通している。Plan-and-Act の Planner / Executor 分離は内部で組まれているが、外から見ると 1 つのエージェントが端から端まで実装する。
Reflexion 系の CHANGELOG.md 戦略 が要所で効く。失敗履歴を残すことで、長期 horizon で同じ袋小路に入らない。
18 ヶ月運用 retrospective（2025 末公開）：
- security fix で 組織の総開発時間 5-10% 削減 / 脆弱性対応 30 分→1.5 分（20×）
- modernization で 10-14×
- test coverage 50-60% → 80-90%
- データ機能リリース 3×
諦めたもの：mid-task の要件変更、ソフトスキル、reactive collaboration。Cognition チーム自身が「junior の置き換えとして明確にポジショニング」と公言している。
V3 の進化：hypervisor-level snapshotting で「コンテナ kernel-escape を working assumption とし、idle 時 compute 停止 → CI 完了で resume」という設計に。
Manus AI ── 「Orchestrator-Workers の野心」
主要パターン：Orchestrator-Workers + ReAct + CodeAct
Manus は Planner / Execution / Verification の 3 sub-agent をモジュール化した multi-agent 構成。CodeAct パターン（Python 実行が action）で、各 step に 1 アクション、observation を確認してから次へ進む厳格な制御。
実行環境：E2B Firecracker microVM 上で 1 ユーザー 1 sandbox（150ms 起動、最大 14 日保持）。
HITL の差し込み：公開資料上、明示的な HITL モジュール記述は見当たらない[要検証]。CodeAct ループ内の人間介入点も未記述。
諦めたもの：sub-agent のメモリスコープ汚染の自動解決。「sibling task の log を相続して hallucinate 連鎖→無限 retry」事例が報告されている。
OpenAI ChatGPT Agent / Operator ── 「Autonomous + Watch mode」
主要パターン：Autonomous Agent + Harness+Sandbox
ChatGPT Agent は Deep Research + Operator + ChatGPT 対話能力を unified system に統合（OpenAI 公式発表）。Operator は CUA（Computer-Using Agent）で、GPT-4o vision + RL で GUI 操作を学習。
HITL の 3 層防御：
- refusal training（危険要求は active refusal）
- user confirmation（確認プロンプト）
- watch mode（sensitive sites でユーザーの常時監視を要求）
Operator の特徴：銀行送金は 100% 確認。Sensitive sites（メール、金融）では watch mode が自動発動。
諦めたもの：銀行送金等の高リスクタスクの完全自律。
System Card 公開で透明性は高い。ただし PDF パース困難で詳細未取得[要検証]。
Replit Agent 3 ── 「Evaluator-Optimizer + Hierarchical の極致」
主要パターン：Evaluator-Optimizer + Hierarchical
Self-healing ループ が中核：生成 → Playwright で動作テスト → エラー検知 → 自動修正 → 再テスト。これは Evaluator-Optimizer パターンの強化版。
Stacks 機能：Agent が他の Agent を生成。Docker sandbox + Postgres インスタンス・ストレージレイヤーを各ユーザに割当、日に数千スピンアップ。これは Hierarchical トポロジーの実装で、各層が独立した Docker sandbox。
自社主張：Computer Use 比 3× 高速、10× 安価。Max Autonomy で 200 分連続自律。
諦めたもの：200 分連続自律を取る代わりに、短期介入頻度（HITL の差し込み）。
GitHub Copilot Coding Agent / Workspace ── 「Pipeline + Draft PR」
主要パターン：Pipeline + Evaluator-Optimizer
GitHub Actions ベースの ephemeral env で動作。Draft PR を中継することで、人間レビューを必須化している。
HITL：
- Draft PR レビュー必須
- CI/CD 起動に人間承認必須
- Craftsman などは phase 境界で pause
Agentic code review（2026-03 GA）：PR を読んで context を集め、coding agent に直接修正 PR を投げ返す。VS Code・JetBrains 両対応。
諦めたもの：Push 直接実行。必ず Draft PR を経由。
Anthropic Claude Code（Routines / Skills）── 「Single + Skills の哲学」
主要パターン：Single Agent + Voyager（Skills）+ Reflexion
Claude Code の codename “nO” は単一スレッド・マスターループ。tool call が出ている限りループ、plain text で終了。flat message history、threaded conversation 不採用。これは Premature multi-agent を避ける設計判断。
Skills の progressive disclosure：metadata → SKILL.md 全体 → bundled files、と必要なときだけロード。Voyager 由来のスキル蓄積を context window 制約下で実装したもの。
HITL：Permission system で write/Bash/外部 tool は明示的 allow/deny。Auto Mode（2026-03-24） で classifier に委譲可能。Auto Mode は false-negative 17% を正直に開示し、「人間レビューの代替ではない」と明言。
諦めたもの：多エージェント並走の自由度。debuggability を優先。
Cursor / Composer 2 ── 「Plan-and-Act + Plan/Execute 二段階」
主要パターン：Plan-and-Act + Pipeline
Composer 2 は plan / execute の二段階分離：plan model と execute model を別々に選べる設計（Foreground / Background で plan を走らせ、最大 8 並列、git worktree で隔離）。これは Plan-and-Act の HITL 差し込み版で、Plan 時点でユーザー承認を挟める。
Cloud Agent（旧 Background Agent）：隔離 VM・別ブランチで動作。長時間タスクをバックグラウンド実行する。
HITL：Plan 時点の synchronous 承認 + 実行中も intervene 可能。
諦めたもの：Plan 承認を経ない突発実行。
製品ごとの「諦め」を並べる
各製品が 何を諦めたか を一覧化すると、業務投入の trade-off が見える。
quadrantChart
title 自律性 vs 範囲の trade-off
x-axis 狭い範囲 --> 広い範囲
y-axis 監視重視 --> 自律重視
quadrant-1 Replit Agent 3 / Manus
quadrant-2 ChatGPT Agent
quadrant-3 Cursor / Copilot Workspace
quadrant-4 Claude Code / Devin観察：
- Devin / Claude Code：狭い範囲に特化（コーディング）+ 比較的自律。HITL は最後の関門
- Cursor / Copilot Workspace：狭い範囲（コーディング）+ 監視重視（Plan 承認 / Draft PR）
- ChatGPT Agent：広い範囲（一般タスク）+ 監視重視（watch mode）
- Replit Agent 3 / Manus：広い範囲（汎用）+ 自律重視
業務投入で参考になる選択軸：
- 狭い範囲を取るなら自律性を上げられる（Devin / Claude Code）
- 広い範囲を取るなら監視を厚くする必要（ChatGPT Agent watch mode）
- 広い範囲 + 自律は難易度が高い（Replit / Manus は積極的に挑戦中だが、自社主張のベンチが多い[要検証]）
パターンの組み合わせ規則
7 製品から見えてくるパターン組み合わせの規則：
規則 1: Single Agent + ある古典パターン
→ Devin (Plan-and-Act + Reflexion), Claude Code (Voyager + Reflexion)
規則 2: Multi-agent には必ず Verification 役を入れる
→ Manus の Verification sub-agent
→ Replit の Self-healing ループ
→ Cursor の execute フェーズ
→ 「実行 → 検証 → 訂正」が万能の組み合わせ
規則 3: 広範囲を狙うエージェントには必ず Watch mode 系の HITL
→ ChatGPT Agent watch mode
→ Replit App Testing デフォルト
規則 4: コーディング系は Single Agent + 古典の組み合わせが優勢
→ Cognition Devin、Claude Code、Cursor、Copilot
→ これは ch3 の「コーディングは前提共有が必要」と整合❌ アンチパターン：「業界トップを真似ればいい」
ここまで解剖した 7 製品をそのまま真似ても、自社の業務には乗らない。
症状
─────────
- 「Devin と同じ構成にしたが、自社プロジェクトでは動かない」
- 「Claude Code を真似たのに精度が出ない」
根本原因
─────────
- 各製品が「何を諦めたか」を見ていない
- 自社のタスクの性質（前提共有度・範囲・リスク）を分析していない
- パターンと諦めの組み合わせは「タスクごと」に最適化されている
脱出法
─────────
1. 自社タスクを「前提共有度」「範囲」「リスク」の 3 軸で分類
2. その 3 軸に近い製品の「諦め」を真似る（自社で諦められないものを正しく諦める）
3. 真似た後で「自社特有の制約」を上乗せして調整
4. 「Devin の出力品質が出ないのはモデル選択ではなくパターン選択の問題かも」と疑う業務投入の観点で重要な 3 点
- 「諦め」が設計を決める：どの本番エージェントも何かを諦めている。自社で何を諦められるかを明示するのが業務投入の出発点
- コーディング系は Single Agent + 古典の組み合わせが優勢：Devin / Claude Code / Cursor / Copilot がいずれも採用。前提共有が必要なタスクの帰結
- Verification 役を必ず入れる：実行 → 検証 → 訂正 の 3 役は万能。Manus の Verification sub-agent、Replit の Self-healing、Cursor の execute フェーズ、すべて同じ構造
次章への接続
ch8（最終章）では、本作の地図を統合し、第3部（運用工学編）への伏線を回収する。本作で組んだエージェントは、運用フェーズで何が壊れるか、どう壊れずに動き続けさせるかを次のシリーズで扱う。
この章のまとめ
- 7 製品をパターン語彙で解剖したマトリクス：Devin / Manus / ChatGPT Agent / Replit / Claude Code / Copilot Workspace / Cursor
- 各製品の「諦め」が設計を決める：自律性 vs 範囲の象限で位置取りが見える
- コーディング系は Single + 古典が優勢：前提共有が必要なタスクの帰結
- 「実行 → 検証 → 訂正」の 3 役は万能：Verification の置き場が品質を決める
- 業界トップを真似るだけでは業務に乗らない：自社タスクの 3 軸（前提共有度・範囲・リスク）で評価する