ハーネスと文脈エンジニアリング（2026）

出典: Anthropic — Effective context engineering（公式） · The importance of Agent Harness（2026）（コミュニティ解説）。ハーネス＝エージェントの実行環境（何を見せ・何ができ・何を完了とし・失敗をどう改善に回すか）。モデルが推論し、ハーネスが実行を統治する。コンテキストは有限資源なので、入れる情報を絞るほど精度が上がる。

ハーネスが統治する「ループ」

エージェントは gather context → act → verify → iterate を自分で回す。プロンプト設計がループの中身（ゴール・検証可能な完了条件）を与えるのに対し、ハーネスはその回り方を統治する — 各手で何を読ませ、何を実行させ、いつ止めるか。下表は各局面とこのページの対応箇所。

2026年に入り「プロンプトの言い回し調整」より「ルール・rules ファイル・実行環境の設計」を主軸に置く論調が広がっている（Data Science Dojo — Harness Engineering、SDG Group — Context design in 2026 など、いずれも未検証のコミュニティ解説）。理由は「モデルの意図理解が向上し、文面の工夫より何を継続的に読ませるかの設計が出力品質を左右するようになったため」とされる。プロンプト技術が無効になったわけではなく、プロンプト設計で固めた指示を rules / Skills に昇格させる土台として位置づけるのが実務的。

ハーネス設計の原則

• Start Simple — 巨大な制御フローを組まない。bash など atomic なツールを渡してモデルに計画させ、guardrails・retry・検証を実装する
• Build to Delete — モデル更新で最適な構造は変わる。あとで作り直せるモジュール設計にする
• goal drift 防止 — 長丁場では高レベルの目的を tasks/todo.md に書き、コンテキストへ繰り返し再掲して目標のブレを防ぐ
• テストは不可侵の制約 — 受け入れテストを実装前に固定し、エージェントに要件を書き換えさせない（エージェント TDD）

ルール側の入口: ルールの発火モードとポータビリティ。委譲の進め方: マルチエージェント協調。

Cursor 3 — cloud agent と harness

未確認の速報扱い。出典は Cursor 公式 X（@cursor_ai） で、正式仕様は Cursor Docs / changelog を正とする。Cursor 3 の cloud agent について公式Xでは「ローカルの agent をサーバへ移すだけでは不十分で、durable execution platform・powerful harness・現実的な開発環境が要る」と紹介されている。ハーネスは実行を統治する基盤という位置づけ（上の文脈戦略表）。

Plan の運用

Plan の置き場所（チャット / ファイル）

3 ステップ以上は Plan をファイル化。tasks/todo.md がチーム正本。Cursor は .cursor/plans/ が下書き。

Plan — ズレたら follow-up ではなく計画からやり直す

公式 BP: 意図と違う出力が出たら、追加入力で直すより変更を revert → Plan を具体化 → 再 Buildの方が速くきれいなことが多い。

1. Checkpoint / git で安全な地点に戻す
2. Plan（チャット or .cursor/plans/）に不足コンテキスト・完了条件を追記
3. ユーザー承認後に Agent で再実行
4. 検証コマンド（完了前検証）を Plan に含める

同じ失敗を繰り返すなら停止条件を設ける（リトライ 2〜3 回で自走を止め、失敗を表に出す）。場当たり修正を重ねるより、計画に戻った方が速い。

マルチエージェント協調

開発セッションでは、1つの会話にすべてを詰め込まず、別の AI 担当（Task / Subagent）に調査・分析を委譲し、メインは実装と判断に集中する。プロダクト実装（LangGraph・SDK）の詳細は Tool Use 参考 — マルチエージェント、RAG 統合は RAG 参考 — Agentic RAG。

基本 — 開発文脈でのマルチエージェント

マルチエージェントとは、役割とコンテキストを分けた複数の AI 実行単位が協調すること。Cursor では Task ツール、Claude Code では Subagents が相当する。

1. Plan — メインがゴール・サブタスク・並列可否を書く（Plan の置き場所）
2. 調査委譲 — 広い grep・複数ディレクトリ探索は Subagent に任せ、結果だけ戻す（調査の任せ方）
3. 執筆・実装 — メインが構造化された調査結果をもとにコード・ドキュメントを書く
4. 検証 — テスト・curl・本番 HEAD など完了条件を満たす（完了前の検証）

Cursor Task — subagent_type の使い分け

並列: 独立タスクは複数 Task を同時起動（ファンアウト）。集約ロジックを Plan に先に書く。

並列とハンドオフ

worktree 並列 · 複数モデル比較（Cursor 2026）

出典: 公式 BP。

• Git worktree — Agent ドロップダウンから worktree を選ぶと、ファイル変更が分離された作業ツリーで実行。完了後 Apply で現在ブランチへマージ
• 複数モデル — 同一プロンプトを複数モデルに送り、結果を横並び比較。難問・エッジケースの探索向け
• 通知 — 並列実行時は完了通知を有効化（長時間タスク）

調査だけ委譲する場合は Task / Subagent。実装の並列は worktree + Plan で衝突を防ぐ。

受け渡しスキーマ（データ契約）

Subagent からメインへ戻すのは構造化結果だけ。全文ダンプ・長い grep 出力は避ける。

{
  "paths": ["src/domain/order.ts", "src/api/routes/order.ts"],
  "summary": "OrderService.create が POST /orders から呼ばれる。認可は middleware/auth.ts。"
}

• paths — 触るべきファイル（最大10件程度）
• summary — 3〜5文の要点（メインが次のアクションを決めるのに足る量）
• 必要なら blockers — 調査だけでは解決できない不明点

協調パターン

下表はパターンごとの向き不向き。

チェックリスト

1. ゴール・サブタスク・並列可否を書く
2. 各エージェントに役割・ツール・構造化出力（データ契約）を割り当てる
3. 並列/直列の境界と受け渡しを固定する
4. 失敗時フォールバックを文章化する
5. まず 2 体パイプラインで固めてから段階的に増やす
6. ハンドオフ失敗・重複作業・品質低下・トークン肥大を監視する

よくある失敗

• 汎用エージェントだらけで特化のメリットが消える
• 出力形式未標準化で次段がパースできない
• 並列を早まりで増やし観測不能になる
• 段間エラー処理がなく連鎖失敗する
• トークンコストを軽視する