はじめに
OpenAI の Harness Engineering や Anthropic の長時間エージェント運用に関する記事を読みながら、自分が普段 AI エージェントと仕事を進めるときにやっていることは、この考え方にかなり近いのだと感じました。
これまで AI 活用では、プロンプトエンジニアリング や コンテキストエンジニアリング といった言葉がよく使われてきました。ただ、AI エージェントにまとまった仕事を任せる段階になると、重要なのはプロンプトそのものよりも、AI が迷わず働けるレールをどう作るか になってくると思っています。
短いやり取りではプロンプト設計も重要ですが、長時間・複数段階の作業では、ハーネス設計の比重が大きく上がります。本記事では、ハーネスエンジニアリングを自分なりにどう捉えているかと、実際にどのように AI エージェントと仕事を進めているかを整理します。
この記事でわかること
- ハーネスエンジニアリングをどう捉えると理解しやすいか
- なぜ長時間作業ではプロンプトだけでは足りないのか
- 自分が実際にやっている、AI エージェントを安定して動かすための進め方
1. ハーネスエンジニアリングとは
自分の理解では、ハーネスエンジニアリングとは、AI エージェントが長時間・複数段階の作業でも迷わず前進できるように、目的、手順、記録、レビュー、役割分担といった 外側の仕組み を設計することです。
ここで重要なのは、プロンプトを工夫すること自体を否定しているわけではない、という点です。短い対話や単発の作業では、プロンプト設計だけでも十分に効果があります。ただ、設計、実装、レビュー、改修のように複数の工程をまたぐ仕事になると、それだけでは不安定になりやすいと感じています。
その意味では、自分の中では、プロンプトエンジニアリングを内包し、その上にコンテキストエンジニアリングがあり、さらにその外側にハーネスエンジニアリングがあるイメージです。ここで言いたいのは優劣ではなく、どこまで広い範囲を設計対象に含めるか の違いです。
プロンプトだけを工夫する段階より、必要な情報の持たせ方を設計する段階の方が広く、さらに作業全体の進め方まで含めて考えるのがハーネスエンジニアリングだと捉えています。
OpenAI の Harness Engineering でも、エージェント時代のエンジニアリングは、モデルを直接コントロールすることよりも、人間が方向を示し、エージェントが動ける環境を整えること に重心が移る、という話がされています。
Anthropic の記事でも、長時間動くエージェントでは、単一の会話に全部を押し込むのではなく、途中成果物や役割分担のような 外側の仕組み が重要だと整理されています。
Claude Code のドキュメントを見ても、CLAUDE.md、subagents、session の扱いなど、能力そのものより どう継続的に働かせるか に重点が置かれています。各社の表現は違っても、見ている本質は近いと感じました。
参考:
- OpenAI: Harness Engineering
- Anthropic: Effective harnesses for long-running agents
- Claude Code docs: How Claude Code works
2. なぜ長時間作業ではハーネスが重要になるのか
短い質問に答えてもらうだけなら、良いプロンプトを書くだけでもかなりうまくいきます。
一方で、設計、実装、レビュー、改修のように複数段階にまたがる作業では、それだけでは足りません。長いやり取りの中では、コンテキストウィンドウの制約、セッション切り替え、前提の欠落、完了条件の曖昧さが積み重なりやすいからです。
実際、AI エージェントとの作業が不安定になる原因の多くは、モデル性能そのものよりも、必要な前提を保持し続けられないこと や 何をもって完了とするかが曖昧なこと にあります。
だからこそ重要なのは、一発で完璧な指示を書くことよりも、
- 何を目的にしているのか
- どういう順番で進めるのか
- 何を記録として残すのか
- どの段階でレビューするのか
- 役割分担をどうするのか
を先に決めておくことです。自分にとってのハーネスエンジニアリングは、まさにこの部分を設計することです。
3. まず重要なのは、最初の対話でゴールとルールを揃えること
自分の実践の中で、いちばん重要だと感じているのはここです。いきなり実装を始めるのではなく、まず AI と対話して、ゴールと進め方の認識を揃えます。
ここで確認するのは、たとえば次のようなことです。
- 最終ゴールは何か
- どの順番で進めたいか
- 先に何を決める必要があるか
- 不明点があればどの段階で質問してほしいか
この段階で軽い draft や方針整理を作ることもあります。重要なのは、AI にいきなり作業を振るのではなく、どういうレールの上で進めるか を最初に合意することです。
自分の感覚では、ハーネスエンジニアリングの出発点は、特別なツールや複雑な仕組みではなく、この最初の対話にあります。
自分の中では、この流れ全体がハーネスエンジニアリングです。プロンプト単体を工夫するというより、最初の対話からドキュメント、レビュー、書き戻しまで含めて、AI が迷わず進める状態を先に作ります。
ポイントは、実装に入る前に対話とドキュメントでレールを敷いておくことです。これがあるだけで、長時間の作業でもぶれにくくなります。
4. 自分が使っている4つのドキュメント
最初の対話で揃えた内容を、安定した作業につなげるために、自分は主に4つのドキュメントを使っています。
design.md
設計書、または作業手順書です。AI が何を作るのか、どういう順番で進めるのかを迷わず理解できるようにするための土台になります。
task_checklist.md
タスクの抜け漏れを防ぐための一覧です。フェーズごとにやることを並べ、各タスクに受け入れ条件を書いておきます。作業後にその条件を確認できるので、なんとなく終わった状態を減らしやすくなります。
session_handoff.md
セッション切り替え時の引き継ぎメモです。直近の作業内容や判断理由を残しておくことで、別セッションになっても素早く復帰しやすくなります。
AGENTS.md
絶対に守ってほしい運用ルールを書くファイルです。更新すべきドキュメントや、作業中に従うべき原則を固定しておくことで、セッションが変わっても運用をぶらしにくくできます。
自分にとってこれらのドキュメントは、単なる補助資料ではありません。AI エージェントが長い作業の中で迷わないための 外部記憶 であり、作業レール そのものです。
5. 書き戻しとレビューを前提に進める
長いやり取りを全部会話だけで持ち続けるのは、どうしても不安定になります。そのため、自分は必要な情報を Markdown ファイルに書き戻すことをかなり重視しています。
ここで大事なのは、単なる事実の箇条書きだけで終わらせないことです。What だけでなく、Why や How も残しておくと、次のセッションでも意図がかなり復元しやすくなります。
また、最初からレビュー前提で進めることも重要だと感じています。AI の成果物は、多くの場合 1 回で完全に仕上がるわけではありません。ただ、最初の対話とドキュメント準備をしっかりやっておくと、大きくずれたものは出にくくなり、レビューは 大きな修正 ではなく 小さな補正 で済みやすくなります。
なおタスクが大きくなった場合は、さらに役割分担を進めることもあります。たとえば、実装を進めるエージェントとレビューするエージェントを分けるような運用です。ただ、自分の中ではこれはハーネスの中核というより、ハーネスを強くしていった先に出てくる発展形という位置づけです。
6. 付録: 最初に渡す依頼文の叩き台
ここまで書いてきたように、自分が重要だと考えているのは、魔法のようなプロンプトそのものではなく、AI が迷わず働けるレールを先に作ることです。
ただ、そのレール作りを始めるための 初期依頼文 はあってよいとも思っています。たとえば自分なら、いきなり作業に入らず、まず対話と叩き台作成から始めてほしいことを次のように伝えます。
あなたは、長時間・複数段階の作業を安定して進めるための AI エージェントとして振る舞ってください。
今回の目的は、いきなり実装や本文執筆を始めることではなく、まず要件と進め方を整理し、作業用のレールを作ることです。
以下のルールで進めてください。
1. 最初に、今回の目的・ゴール・前提・制約を確認してください
- ゴールが曖昧なら、作業開始前に質問してください
- 不明点を曖昧なまま埋めて進めないでください
2. いきなり成果物を完成させようとせず、まず叩き台を作ってください
- 必要に応じて `design.md`、`task_checklist.md`、`session_handoff.md`、`AGENTS.md` の叩き台を作成してください
- 各ドキュメントの役割も明確にしてください
3. 対話を通じて要件を詰めてください
- まず読者、目的、結論、進め方を揃えてください
- 重要な論点から順番に確認してください
- 一度に全部を決めようとせず、必要な単位で整理してください
4. タスクは必ず分解してください
- フェーズやタスク単位に分けて整理してください
- 各タスクには受け入れ条件を書いてください
- 何が完了条件かを明確にしてください
5. 長い作業では、必要な情報を都度 Markdown に書き戻してください
- 会話だけで持ち続けず、途中成果物や判断理由をファイルに残してください
- `What` だけでなく `Why` と `How` も残してください
6. 作業はレビュー前提で進めてください
- 一発で完成を狙うのではなく、叩き台 → 確認 → 修正 の流れで進めてください
- ずれがあれば、その場で方針を確認してください
7. もしタスクが大きすぎる場合は、役割分担案も提案してください
- 実装用
- レビュー用
- 進行管理用
のように、分けた方がよい場合は提案してください
最初の返答では、まだ本作業を始めずに以下を出してください。
- あなたが理解した目的
- 足りない情報
- 最初に確認すべき論点
- 必要なら作るべきドキュメント一覧
- 推奨する進め方
もちろん、これをそのまま使えばすべてうまくいくわけではありません。大事なのは、この依頼文をきっかけに 最初の対話 を始め、その後にドキュメントやレビューの運用を続けることです。
ハーネスは、AIエージェントの挙動を大きく左右する重要な層ですが、それだけで全体が決まるわけではありません。モデル、コンテキスト、ツールも含めた全体像を見たい方は、AIエージェントの仕組みとは？ モデル・ハーネス・コンテキスト・ツールで整理する もあわせてご覧ください。
まとめ
ハーネスエンジニアリングは、単にプロンプトを工夫する話ではなく、AI エージェントが長時間・複数段階の仕事を安定して進められるように、外側の仕組みを設計する話だと理解しています。
自分にとって特に重要なのは、最初の対話でゴールとルールを揃えること、そしてそれを支える design.md, task_checklist.md, session_handoff.md, AGENTS.md のようなドキュメントを用意することです。少なくとも自分の体感では、このレールを先に整えるだけで、AI 活用の安定性はかなり変わります。
もし AI エージェントが途中でぶれる、長時間作業になると不安定になる、と感じているなら、まず見直すべきはプロンプト単体ではなく、AI が働くためのレールをどう設計しているか かもしれません。