ハウツー・実装

ハーネスエンジニアリング入門|AIエージェントの手戻り対策7選

AIエージェントの手戻りを減らすハーネスエンジニアリングを解説。商談報告書を例に、完成見本・修正ログ・確認基準など7つの実践ポイントと導入手順を紹介します。

「ハーネスエンジニアリング入門|AIエージェントの手戻り対策7選」のアイキャッチ

AIに任せた業務で、同じような修正指示を何度も繰り返していませんか。

本記事では、そうした手戻りを抜本的に減らすための考え方「ハーネスエンジニアリング」と、現場ですぐに取り入れられる7つの実践ポイントをご紹介します。商談報告書の作成を具体例に、「社内で何を準備し、誰がどう確認すべきか」まで分かりやすく解説します。

「担当者と期限も入れてくださいと、前回も伝えましたよね」

AIへの指示が、いつの間にか毎回同じ注意の繰り返しになっている――。生成スピードは上がったものの、確認や手直しの手間は減っておらず、かえって業務効率化の実感を得にくいと感じている方は少なくありません。

そこで重要になるのが、「修正した内容を、次の業務プロセスに還元する仕組み」を整えることです。

まずは、過去の修正履歴、良質な完成見本、明確な確認基準の3点から見直します。これらは、今ある日常業務の記録をベースにすぐに始められます。


ハーネスエンジニアリングの役割とは

ハーネスエンジニアリングとは、「AIがスムーズかつ正確に業務を進められるよう、その周辺環境や実行基盤を設計・改善すること」を指します。

AIエージェントは、目的に応じて自律的に情報を収集し、各種ツールを活用しながらタスクをこなします。その中心で判断を担うのがAIモデル(頭脳)です。本記事では、そのモデルへ渡す前提条件や指示、利用可能なツール群、ログの記録、出力結果の検証プロセスなどを含めた周辺の環境全体を、広義の「ハーネス(手綱・馬具=制御基盤)」と位置づけています。

AIモデルを支えるハーネスの構成図

概念自体は新しく見えますが、日常の業務に置き換えるとシンプルです。

新入社員に商談報告書の作成を依頼する場面を想像してみてください。参考情報やフォーマットを一切渡さず、「いい感じにまとめておいて」とだけ頼んだら、いくら優秀な人材でも迷ってしまいます。

  • 誰が読むのか
  • どんな意思決定に使う報告書なのか
  • どの段階で上司のレビューを受けるべきか

こうした前提条件や運用ルールが揃って初めて、担当者は本来のパフォーマンスを発揮できます。AIも同様に、「仕事を進めやすい環境(ハーネス)」の整備が欠かせないのです。

整えるべき要素 商談報告書における具体例
目的と読み手 営業責任者が、次の一手を迅速に判断するための報告
参照情報 商談議事録、顧客カルテ、最新の提案資料
手順と完成見本 「記録確認 → ドラフト作成 → 事実照合」の手順と、承認済みの報告書サンプル
確認基準 「顧客の発言」と「担当者の推測」の明確な区別、ネクストアクション(担当・期限)の有無
権限と承認フロー 下書きまではAIが作成し、社内共有前に担当者が目視で最終確認

プロンプト(指示文)の改善もこの設計の一部ですが、そこから一歩踏み込み、「何を参照させ、どの順序で処理させ、どこで人間が介在・承認するか」までを包括して設計します。

これはモデル自体の再学習(ファインチューニング等)を必要とするものではありません。既存のAIが持つ能力を、自社の実務で最大限に引き出すための業務改善アプローチです。

米Anthropic社が実施した長時間動作エージェントの検証でも、作業コンテキストの引き継ぎや、完了状態を担保するテスト機構の重要性が強調されています。「記録を残し、次の実行に活かし、結果を検証する」というアプローチは、一般企業の業務設計においても非常に示唆に富む考え方です。


まず押さえるべき3つの基本ステップ

ここからは、記事末尾でも紹介するミチガエル社のYouTube解説動画をベースに、非エンジニアの方でも実務に落とし込めるよう再構成した「7つの実践ポイント」を解説します。

※なお、本稿で取り上げる「商談報告書の作成」は、運用の流れをイメージしやすくするためのモデルケースです。

1. 修正履歴(フィードバック)の仕組み化

まずは、直近のAIとのやり取り履歴を振り返ってみてください。同じような指摘を何度も繰り返していないでしょうか。

商談報告書であれば、「決定事項と保留事項を分けてほしい」「次回アクションには必ず期日を入れてほしい」といったフィードバックが見つかるはずです。その場の手直しで報告書自体は完成していても、その知見が「次回のプロンプトや前提条件」に反映されていなければ、次回も同じ修正作業が発生します。

日頃の修正内容は、次のように整理して標準化へとつなげます。

頻発するフィードバック 次回以降の共通ルール 具体的な反映先
決定事項と検討事項が混在している 「決定事項」「検討中」「未確認」にセクションを分割する 報告書作成プロンプト(手順指示)
アクションの期日や担当者が抜けている ネクストアクション欄に「担当者・期限」を必須項目として設定 完成見本・納品前チェックリスト
原文にない推測が事実のように補完される 記録にない事項は独自に補完せず「未確認」と明記させる 共通システムプロンプト(前提ルール)

注意点と運用のコツ:

特定案件固有のイレギュラーな条件を、安易に全社共通ルールへ組み込まないように注意してください。「案件固有の条件」と「全社共通の作成要件」を明確に切り分けることが運用の破綻を防ぎます。

また、修正指示を都度継ぎ足していくと、過去の指示と矛盾が生じるケースがあります。定期的に指示書を見直し、重複や不要なルールを整理・削除するメンテナンスを心がけましょう。

AIに対する修正指示には、「その企業が大切にしている業務基準やノウハウ」が色濃く反映されています。

単なる手戻りとして片付けるのではなく、次の仕事の品質を高める資産としてルール化していきましょう。

修正内容を次の仕事に反映するフィードバックの流れ

2. 「理想の完成見本」と「作成手順」の提示

修正すべきポイントが整理できたら、次は「この水準なら手戻りなく使える」と言える良質な完成見本(ゴールイメージ)を一つ用意します。

例えば商談報告書なら、「冒頭に結論(受注見込み・最重要トピック)を置き、顧客課題、決定事項、保留事項、そして次回アクション(担当・期限)へと続く構成」を定義します。

営業責任者が一読しただけで、追加のヒアリングをせずともネクストアクションを判断できるクオリティを目指します。

明確な完成見本を一つ提示するだけで、「分かりやすくまとめて」といった曖昧な指示によるブレを大幅に防げます。

完成見本を定義する際は、「なぜそのフォーマットにしているのか」という意図・理由もセットで言語化しておくことが推奨されます。

  • 「責任者が即座に判断できるよう、結論を冒頭に配置している」
  • 「曖昧な認識のまま進行するのを防ぐため、未確認事項の専用欄を設けている」

背景にある意図を共有しておくことで、別の商談パターンに応用する際にもAIや担当者がブレずに判断できるようになります。

3. 合格基準の設定と検証フローの導入

完成見本を与えても、「形式だけが似通った不正確なアウトプット」が出力されては意味がありません。体裁が整っていても、顧客が検討中の段階を「合意済み」と誤認して記載されていれば、後続の営業活動に支障をきたします。

そのため、生成指示と同時に「合格基準」と「出力後のチェック手順」をセットで指示します。

【プロンプト指示の例】
提供する商談メモに基づき、共有済みの完成見本に沿って商談報告書を作成してください。
■ 作成ルール
- 「決定事項」「検討中事項」「未確認事項」を明確に区分してください。
- ネクストアクションには、必ず具体的な「担当者」と「完了期限」を明記してください。
- 元の商談メモに根拠がない情報は独自に推測せず、「未確認」として扱ってください。
■ 検証ルール
- 作成完了後、元の商談メモと内容を照合してください。
- 商談メモ内に裏付けが取れない記述がある場合は、提出前に該当箇所を一覧で提示してください。

このように、「作る条件」と「確かめる条件」をワンセットにするのが運用の基本です。

さらに精度を高める手法として、「ドラフト作成」と「検証・照合」のプロセスを分離するアプローチも有効です。ドラフトを作成したAIとは別のプロンプト(あるいは別スレッドのAI)に元データ・完成見本・チェック項目を渡し、客観的な照合作業を行わせます。

ただし、どれほど検証プロセスを組んでもAIが誤る可能性はゼロにはなりません。契約条件、金額、納期といった重大なリスクを伴う要素については、必ず人間が一次情報を確認する承認工程を残してください。

改善ルールを更新した後は、次回の商談でも運用し、以前のミスが減っているか、新たな手戻りが発生していないかを継続検証することが重要です。


運用を定着・スケールさせる4つの工夫

修正履歴の活用、見本の定義、検証の仕組み化ができたら、次は日々の運用を形骸化させずに回し続けるための工夫を取り入れます。

4. 社内ナレッジの体系化(外部メモリの活用)

担当者や利用ツールが変わるたびに、会社概要や業務ルールを一から入力し直すのは非効率です。この課題を解消するアプローチとして、動画内では「外部メモリ」の活用が挙げられています。

外部メモリとは、AIが必要に応じていつでも参照できる「社内wiki」や「引き継ぎドキュメント」のようなナレッジ拠点です。会社方針、商品仕様、判断基準などを、個別のチャットセッションから切り離して一元管理します。

商談報告書であれば、NotionやGoogleドライブ等の共有ストレージに、最新のサービス資料、標準フォーマット、共通ガイドラインを集約することから始められます。

管理上のチェックポイント:

  • どのAIツールから接続・参照できる設定になっているか
  • どの業務で、どのドキュメントを読み込ませるか
  • ドキュメントの最終更新日と管理責任者が明確になっているか

機密情報や顧客データについては、全社共通情報とアクセス権限を明確に切り分ける必要があります。「ただ情報を集める」だけでなく、「必要な権限を持つ担当者とAIが、常に最新の正確な情報を引き出せる状態」を整えましょう。

5. AIの役割分担(マルチエージェント的発想)

複数のAIツールやプロンプトを運用する場合、「どんな最新ツールを使うか」よりも「それぞれのAIにどの役割を任せるか」という機能分担の整理が先決です。

動画では、「全体方針の策定役」「リサーチ役」「実務の実行役」と役割を分担させる構成が紹介されています。商談報告書であれば、以下のように工程を切り分けることが可能です。

  1. 抽出役:商談ログから確定事実と次回アクションを過不足なく抜き出す
  2. 作成役:指定の見本フォーマットに沿って文章を整える
  3. 照合役:完成した報告書と元ログを突き合わせ、誤認や漏れをチェックする

ただし、チーム運用と同様に、前工程からの引き継ぎ情報が不十分だと連携ミスが発生します。

前工程から次工程へパスする際は、「業務の目的」「参照した一次情報」「確認できた事実」「未確定な点」をセットで渡すのが鉄則です。

要約文だけを渡すと、重要な文脈や前提条件が抜け落ちてしまうリスクがあります。

AIと人の確認・引き継ぎの流れ

最初から複雑な連携を組む必要はありません。まずは1つのツール内でプロンプトを段階的に分け、手戻りが多発するボトルネック部分から段階的に分担を試していくのが堅実です。

6. 人による品質評価とガバナンス

AIが整った文章を出力すると、内容の精査を怠り、そのまま承認してしまいがちです。しかし、ビジネス文書において「もっともらしい文章」と「判断に使える情報」は全く異なります。

例えば「お客様は前向きに検討中」と記載されていても、「来期の予算枠がすでに確保されている」のか、「単に担当者が興味を示しただけ」なのかによって、営業マネージャーが下すべき判断は大きく変わります。

こうした文脈の機微を見極められるのは、現場のビジネスを熟知した人間の知見にほかなりません。

人間が確認すべき観点:

  • 単なる誤字脱字だけでなく、重要な取引条件に抜け漏れがないか
  • 客観的事実と個人的な推測が混同されていないか
  • 次の営業アクションを即座に決断できる情報粒度になっているか

人間がレビューで違和感を覚えた部分は、必ず言語化して完成見本や確認チェックリストへフィードバックします。AIの出力精度を高める基準は、人間の的確なレビューによって磨かれます。

また、誤送信などの事故を防ぐため、「AIが自律的に送信まで行わないよう、社内ツール側の権限設定やワークフローで物理的にストップをかける」といった安全策も併せて設計しておきましょう。

7. 異常系を考慮した動作テストの設計

社内ツールや業務フローを自動化する仕組みを構築する場合、押さえておきたいのが品質検証の考え方です。

動画では、ソフトウェア開発の手法であるTDD(テスト駆動開発:期待する動作をあらかじめテストとして定義し、それをクリアするように開発を進める手法)の思想が紹介されています。

これを一般的な業務自動化に置き換えると、「正常に動いたとき」だけでなく、「例外的なデータが入ってきたときにどう振る舞うべきか」を事前に決めておくことを意味します。

商談報告書の自動化であれば、以下のようなケースです。

  • 商談メモが極端に短い、または白紙の場合、どのようなエラーメッセージを出すか
  • 期限や担当者に関する発言が一切なかった場合、勝手に日付を補完せず正しく「未設定」と出力できるか

業務においては、「分からない情報を適当に埋めない」という挙動も極めて重要な品質基準です。

例外ケースを運用ルールに反映する図

非エンジニアの担当者であっても、「通常パターンのデータ」に加えて「情報が欠落したパターンのデータ」と「その時に期待する正しい出力結果」を用意することは可能です。その基準を提示できれば、開発担当者やAIが堅牢なフローを構築しやすくなります。


現場で無理なく導入を進めるための5つのステップ

これら7つの要素を、最初からすべて完璧に導入する必要はありません。まずは「頻度が高く、担当者自身で出来栄えの良し悪しを判断しやすい業務」を1つ選び、スモールスタートで進めます。

商談報告書をパイロット運用する場合、以下のように役割分担を定義しておくとスムーズに推進できます(少人数組織であれば、1人が複数の役割を兼務しても問題ありません)。

フェーズ 主な担当者 準備するもの・確認すること
1. 対象業務の選定 経営層・事業責任者 対象とする業務、推進担当者のアサイン、試行に必要な工数の確保
2. 基準の策定 現場責任者・実務担当者 承認済み報告書サンプル(良質な見本)、元データ、確認チェック項目
3. 実践と記録 実務担当者 AIによる下書き作成、人間による修正箇所のログ、所要時間の記録
4. ルールの改善 推進担当者 頻発した指摘事項のプロンプト反映、古くなった指示の棚卸し
5. 効果検証・展開 現場責任者 アウトプット品質の向上度、修正頻度の低減、工数削減効果の測定

効果検証においては、単に「AIが文章を出力するまでの秒数」を見るのではなく、「資料準備から確認、手直し、最終承認に至るまでのトータル工数が削減されたか」を評価基準にします。

作成自体が速くなっても、確認の手間や事実の取り違えが増えていれば、設計を見直す必要があります。逆に、全体の作業時間が劇的に減っていなくとも、「確認に伴うストレスや手戻りの往復」が減っていれば、確かな改善効果が出ていると判断できます。

また、1つの案件だけで満足せず、他案件や他メンバーでも試行し、「属人的なルールになっていないか」を検証しながら段階的に適用範囲を広げていきましょう。

なお、こうした見本づくりや運用の振り返りには相応の工数がかかります。「現場の空き時間でやっておいて」という指示では形骸化しやすいため、経営陣が公式なプロジェクトとして検証時間を確保することが定着の鍵を握ります。


自社の業務フローに合わせたAI活用のご相談

「良質な完成見本の作り方が分からない」「プロンプト研修を実施したものの、実務への定着が進まない」といったお悩みをお持ちの企業様に向けて、ミチガエルでは伴走型の導入支援を提供しています。

貴社固有の業務プロセスの可視化から、現場社員の習熟度に合わせた実践型トレーニング、手戻りを防ぐ業務基盤の設計・定着まで、実情に応じた最適なステップをご提案いたします。AIを単なるツールで終わらせず、真の業務効率化へとつなげたい方は、ぜひお気軽にご相談ください。

この記事の執筆・監修

t-yamashita

執筆

山下 敏樹

IT/AIコンサルタント

IT企業勤務。Web制作会社で社内業務改善・DX推進に携わり、code4bizで学んだAIコーディングを活用してさまざまな業務を自動化。半年間の取り組みで、年間約2,500時間相当の業務削減を実現。その後、IT/AIコンサルタントへ転身。DX現場での経験をもとに、AI活用・業務改善・DX・システム開発に関する知識やノウハウを、読者の成果につながる形で発信しています。

生成AI業務整理DX

Services

内製化支援で「自走できる状態」へ

社内の推進担当が自力で改善を回せるよう、業務設計と技術移管をセットで支援します。