エージェント型のAIツールを触り始めて数週間経つと、多くの人が「これ、単発の質問には答えてくれるが、プロジェクトとしての成果物は出してくれない」という壁にぶつかります。私もAntigravityで何度も同じ経験をしました。「オンデマンド交通サービスの導入検討ドキュメントを作って」と依頼しても、返ってくるのは長文のブログ記事のようなもので、意思決定に使える構造化された資料にはなりません。
nouernet氏がQiitaで提唱した「ハーネスエンジニアリング」の考え方は、この壁を越えるためのフレームワークです。AIエージェントに「回答を求める」のではなく「作業を実行させる」視点で指示を組み立てる、という方法論です。ここではこの考え方をAntigravityで即実行できるテンプレートに落とし込み、私が3つの実プロジェクトで検証した結果を含めて解説します。
なぜAIエージェントは「プロジェクトを完走できない」のか
人間の業務プロセスには、暗黙のうちに以下の流れが組み込まれています。
- 調査して情報を集める
- 情報を構造化する
- 誰が何を担当するか決める
- 各担当が執筆する
- レビューして指摘する
- 指摘に沿って修正する
この6段階は、成果物の品質を担保するために人間が無意識に回しているサイクルです。ところがAIエージェントに仕事を頼むとき、私たちは往々にしてステップ4（執筆）だけを依頼しています。「〜についてまとめて」という指示は、実質的に「まとめた結果を出して」と言っているだけで、そこに至るサイクルをどう回すかは一切指定していません。
ハーネスエンジニアリングは、この6段階を明示的にプロンプトに書き込み、AIエージェントに「人間が無意識にやっていること」を代行させる発想です。Antigravityのような長時間実行型エージェントとは相性が非常に良く、一度テンプレートを整備すると再利用性も高まります。
Antigravityで動く6段階ハーネステンプレート
以下は、私がAntigravityで実際に使っている「プロジェクト実行ハーネス」の完全版です。.antigravity/harnesses/project-execution.mdのような場所に保存し、/harness project-executionのように呼び出す運用を想定しています。
# Project Execution Harness
あなたはこれから、複数の段階に分けて1つのプロジェクトを完走します。各段階の成果物は必ずファイルとして保存し、次の段階の入力として参照すること。
## 入力
- プロジェクト名: {{project}}
- 調査対象: {{target}}
- 想定読者: {{audience}}
- 納期: {{deadline}}
## Step 1: Research Agent — 情報収集
- Web検索で国内・海外の事例を最低2カ国、計6件以上集める
- 各事例について: サービス名 / 運営主体 / 技術構成 / コスト構造 / 成功要因 / 課題 を要約
- 出力先: `docs/01-research.md`
## Step 2: Architect Agent — 構造設計
- Research Agentの結果を読み込み、プロジェクトに必要なドキュメント構成を設計
- `README.md`に全体のドキュメント一覧を作成
- 各ドキュメントの目的・想定読者・ページ数目安を明記
- 出力先: `README.md` と `docs/_outline.md`
## Step 3: Business Agent — 事業性整理
- 市場規模・競合分布・収益モデルを分析
- 日本市場特有の制約（規制・商習慣）も整理
- 出力先: `docs/02-business.md`
## Step 4: Engineer Agent — 技術設計
- 情報収集段階の技術構成を比較し、推奨スタックを決定
- 必要な人的リソース・開発期間・運用コストを見積もる
- 出力先: `docs/03-engineering.md`
## Step 5: Reviewer Agent — 品質レビュー
- 全ドキュメントを横断して読み、以下の観点で改善提案を出す:
- 想定読者に対する難易度のズレ
- 前提条件の抜け漏れ
- 用語定義の一貫性
- 図解の必要性
- リスク・課題の網羅性
- 出力先: `docs/99-review.md`（修正提案のリスト）
## Step 6: Revision — 修正の反映
- Reviewer Agentの指摘を、各担当ドキュメントに反映
- 反映完了後、最終版の一覧を`README.md`の末尾に追加
## 品質基準（すべてのドキュメントに共通）
- 想定読者の明記
- 前提条件の列挙
- 用語定義（最低5件）
- 図解の指示（実図は後工程）
- メリット・デメリット比較
- リスク・課題の列挙
## 完走条件
- `docs/`配下に6つ以上のドキュメント
- `README.md`が全ドキュメントをリンク
- Reviewer Agentの指摘が100%解消このテンプレートをAntigravityに渡すと、単発の質問応答ではなく、ディレクトリ構造を持った成果物一式が出力されます。重要なのは、各Stepの出力先を明示していることです。出力先を指定しないと、エージェントは1つの巨大なMarkdownに全てを詰め込む傾向があります。
5エージェント分担を1ワークフローで動かすコツ
Research / Architect / Business / Engineer / Reviewerの5つの役割を同じ会話で進めるには、「役割切り替え」を明示的にプロンプト内に書く必要があります。Antigravityは役割変更のタグを理解するので、次のように書くのが有効です。
---
## 🔄 役割切り替え: Research Agent → Architect Agent
これまでのResearch Agentとしての作業は終了です。
ここからはArchitect Agentとして作業してください。
Architect Agentの責任:
- Research Agentの成果物（docs/01-research.md）を読み込む
- プロジェクト全体のドキュメント設計を行う
- 執筆はしない（構造設計のみ）
前のAgentの成果物: `docs/01-research.md`
次のAgentへのインプット: `docs/_outline.md`
---この「切り替えブロック」をStepごとに挟むと、Antigravityが自分の現在の立ち位置を見失わずに進みます。切り替えを書かずに「次のStepを進めて」とだけ指示すると、Research Agentの文体のままArchitectの仕事をしてしまい、構造設計なのに情報収集の色が残る成果物になります。
ケーススタディ1 — オンデマンド交通サービス調査
私が実際に回した案件で、「地方自治体向けのオンデマンド交通サービス導入検討ドキュメントを作る」というものがありました。Antigravityに単純に「オンデマンド交通について調べて」と頼んだ場合と、上記ハーネスを適用した場合で、成果物を比較します。
単純指示の場合（3,000字の長文）
- 構造なし。導入・メリット・課題・事例・まとめ、という記事構成
- 自治体の意思決定に必要な「予算感」「運営主体の選択肢」「3年後の撤退判断基準」などは欠落
- 意思決定には追加の調査が必要
ハーネス適用の場合（docs/配下に6ファイル）
01-research.md: 国内5事例＋海外3事例、各々の技術構成・コスト・運営主体02-business.md: 推計市場規模、3年間の収支シミュレーション、補助金活用03-engineering.md: 必要人員・保守コスト・技術スタック比較04-risk.md: 地方交通特有のリスク（運転手不足・利用率の予測困難性）99-review.md: レビュー指摘12件とその解決状況README.md: 意思決定者向けサマリ + 各ドキュメントへのリンク
ハーネス適用版は、そのまま自治体の稟議書の添付資料になる粒度に仕上がりました。同じ所要時間（約40分のエージェント実行）でこの差が出る理由は、単純に「人間が無意識にやっているプロセスをAIに代行させているかどうか」に尽きます。
ケーススタディ2 — SaaS機能企画
個人開発のアプリに新機能を追加する企画でも、ハーネスは効きます。「家計簿アプリにAIカテゴリ自動分類を追加したい」という依頼で、次のようにハーネスを組み替えました。
Step 1（Research）: 他社の同種機能の実装を5社調査
Step 2（Architect）: 既存アプリとの統合ポイントを洗い出し
Step 3（Business）: 想定課金モデル3案の試算
Step 4（Engineer）: 技術選定（Gemini API vs Claude API vs 自前モデル）
Step 5（UX Designer）: 新設のエージェント。UIフローとエラーパターン設計
Step 6（Reviewer）: プライバシー・精度・体験の3軸でレビュー
オンデマンド交通の時はBusinessエージェントを5番目に入れましたが、機能企画では「UIフローとエラーパターン」が成果物の質を決めるので、UX Designerエージェントを追加しました。ハーネスはテンプレートとして固定するよりも、案件ごとに「必要な専門家」を足し引きするのが正解です。
ケーススタディ3 — 社内AI導入プラン
BtoB案件で「社員50名の会社にChatGPT Enterpriseを導入する計画書を作って」という依頼があったケースでは、エージェントを次のように分けました。
- Research Agent: 他社導入事例の調査
- Policy Agent: 社内ガイドライン・禁止事項の叩き台作成
- Training Agent: 社内研修カリキュラムの設計
- Budget Agent: 3年間の費用予測
- Reviewer Agent: 労務・法務視点でのレビュー
このケースで特徴的だったのは、Policy Agentが「情報漏洩リスクを踏まえた禁止事項」を、企業固有の業種（金融系）に合わせて具体化してくれた点です。一般論の「AI利用ガイドライン」ではなく、金融業の顧客情報取り扱い規程と整合性を取ったドラフトが出てきました。これはハーネスのStep 1（Research）で「金融業界のAI利用事例」を先行して調査させていたからです。前工程の蓄積が後工程の具体性を決める、というハーネスの基本原理が明確に現れたケースでした。
失敗しやすい3パターンとデバッグ順序
ハーネスを書いているつもりが、エージェントが期待通りに動かないときの典型パターンを3つ共有します。
パターン1: 指示過多 — 一つのStepに要件を詰め込みすぎる
Research Agentに「国内5件＋海外5件＋各事例の年表＋技術スタック詳細＋コスト＋成功要因＋課題＋関係者インタビュー要旨」のように全部入れると、エージェントはどれかを必ず省略します。1Stepあたり5〜7項目が現実的な上限です。
パターン2: 役割曖昧 — Agent名が具体性を欠く
「Planning Agent」「Main Agent」のような抽象名をつけると、役割切り替え時にエージェントが自分の立ち位置を見失います。「Japanese Municipality Researcher」「Financial-sector Policy Drafter」のように、業界・専門性・地域を含めた具体名が効果的です。
パターン3: 品質基準欠落 — 完走条件を書かない
「完走条件」セクションがないと、エージェントは1度書いた成果物に満足してしまい、レビューサイクルを回しません。最低でも「Reviewer Agentの指摘が100%解消されるまで継続」と書くのが基本です。
デバッグの順序は、①完走条件の有無 → ②役割名の具体性 → ③各Stepの要件数 → ④役割切り替えブロックの有無、という順で確認すると効率的です。
自分の業務にハーネスを適用するには
ハーネスエンジニアリングは、テンプレートをコピペしても効果が出にくい技法です。自分の業務の暗黙プロセスを言語化する作業が不可欠だからです。
まずは、直近で完了した「AIに頼んだが満足しなかった案件」を1つ思い出してください。その案件を人間（自分やチームメイト）がやるとしたら、どのような流れになるでしょうか。
- 最初に何を調べますか？（Research）
- どう構造化しますか？（Architect）
- 誰のどんな知見が必要ですか？（専門家Agent）
- 誰がチェックしますか？（Reviewer）
- どうなれば完成ですか？（完走条件）
この5つの問いへの答えが、そのままあなたの業務専用ハーネスの骨格になります。一度作れば、似たタイプの案件で繰り返し使えるので、最初の言語化コストは数件分で回収できます。
ハーネスは、AIエージェントを「回答マシン」から「作業者」に育てるための言語化の作業です。Antigravityのような長時間実行型エージェントと組み合わせたとき、効果が最大化されると私は感じています。