ハーネスエンジニアリング入門。
AIに毎回同じ説明をしない業務設計

01その手戻りは、指示文だけの問題ではない

担当者ごとに出来が違う。生成は数十秒なのに、事実確認と言い換えで時間が消える。こうした手戻りの原因は、少なくとも四つに分かれます。

• 元データ：価格表やFAQが古い、置き場所が決まっていない、文章化されていない
• 依頼内容：成果物の形、範囲、分量が決まっておらず、AIが前提を推測している
• モデル（AIの種類）の能力：扱う作業が、選んだモデルの得意範囲を超えている
• 評価基準：「出せる状態」の定義が人の頭の中にあり、確認のたびに基準が動く

この記事では、参照情報・依頼の型・評価基準を残し、次の仕事に活かす設計を扱います。導入前の業務整理は「システム導入が失敗する会社は、導入前の業務整理でつまずいている」、モデルの選び方は「AIにも原価管理が必要になってきた」で扱っています。

02ハーネスエンジニアリングを、この記事では何と呼ぶか

ハーネスエンジニアリング（harness engineering）は、AIが働く環境を設計する取り組みを指す言葉です。OpenAIは2026年2月11日に「ハーネスエンジニアリング：エージェントファーストの世界における Codex の活用」を公開し、エージェントが安定して仕事を進められる環境とフィードバックループの設計が開発チームの主たる仕事になった、と述べています。同じ言葉を日々の業務に引き寄せた広告自動化マン氏のスライド「マーケターのためのハーネスエンジニアリング入門」（2026年9月9日公開）は、指示の工夫（Prompt）、前提の整備（Context）、環境の設計（Harness）、実行と修正の反復（Loop）という段階で整理しています。

この記事では、これを四つの設計として扱います。

• 指示文：成果物を一つに絞り、対象・情報源・出力形式を先に決めた依頼の型を、業務ごとに持つ
• 参照情報：会社情報、表記ルール、禁止表現、判断の優先順位を、口頭で足すのをやめ、AIが読める形で置く
• ツールと権限：読んでよい情報、書き込んでよい場所、人の承認なしにやらせないこと
• 結果の確認：何を合格とするか、誰が見るか、直した内容をどこに戻すか

四つ目を外せないのは、ファイルを置いた時点では何も検証されていないからです。動かし、採点し、直した内容を書き戻す。この往復までが環境設計です。

文章で書くルールは精度を上げるためのもので、止めたいことは仕組みの側で止める。顧客への送信、価格の提示、契約条件の回答は、人の操作を挟まないと実行できない形にします。

03問い合わせ対応で具体化する

以下は実在の導入事例ではなく、設計の形を示す想定例です。フォームとメールで一日十数件、仕様確認・納期・見積依頼・不具合連絡が混ざって届き、担当者二名がさばく状態を分解します。

AIに渡すのは、表の「必要な情報」に挙げたものだけです。顧客管理システム全体や過去の全メール履歴は渡しません。外部のAIサービスなら、入力内容の扱いが自社の規程と契約条件に沿うかを、組み込む前に確認します。

受付番号の発行と転記は、既存システムやスクリプトで足ります。生成AIに任せるのは、分類、根拠の検索、返信案の作成のように、文章を読んで判断や生成が要る段階だけです。分けておくと、止まったときの切り分けも速くなります。

確認先は「営業担当へ」「管理部門へ」と役割で書きます。個人名だと担当が変われば止まります。参照した文書名と項目を毎回残せば、後から答えの理由を追え、根拠なしの件数がFAQの更新箇所を指します。

表の「二回」「三回」は、この想定例で置いた暫定の数字です。難易度と件数で変わるため、数週間試して自社の数字に置き換えます。同じ分解は記事制作や週次レポートにも使え、事実確認や原因の解釈といった判断の段階が人に残ります。

04最初の一業務を選び、AI業務設計シートを埋める

全社で始める必要はありません。一つ選び、まず二週間。これも判断材料が集まる目安で、件数が少なければ延ばします。選ぶ基準は三つです。

• 繰り返し発生する：週に数回以上。月一度では、直した結果が次に効くまで一か月かかる
• 必要な情報が揃う：参照すべき資料が社内にあり、置き場所が分かる。資料がないなら文書化が先
• 評価しやすい：「良い感じ」ではなく、合格・不合格を言える

問い合わせの一次対応、定型の報告書、議事録の整形、商品情報の下書きあたりです。選んだら次のシートを埋めます。埋まらない欄が、後の手戻りになります。

埋まったら過去の実物十件を流し、合格基準で採点し、不合格の理由を分類します。「前提を知らなかった」なら参照情報に足し、「基準が曖昧だった」なら基準を書き直す。直した内容は必ずシートか参照情報へ戻します。

準備するのはファイルではなく中身です。常に効かせる前提、その業務のときだけ効かせる前提、手順書、人の承認なしには実行させない操作。この四つを文章にしたら、整理した内容をツールに設定し、読み込みや操作制限が意図どおり働くか確認します。Claude Codeでは順に、CLAUDE.md、.claude/rules/（paths: で対象を指定）、スキル、フックのPreToolUseが当たります（2026年9月22日確認）。配置や読み込みの条件は製品ごとに異なるため、お使いのツールの公式ドキュメントで確認してください。

分量について、公式ドキュメントはCLAUDE.mdを200行未満にまとめることを推奨しています。これは強制的な行数上限ではありません。自動メモリのMEMORY.mdに設けられた起動時の読み込み制限とは別の話です。

05効果と運用負担を、同じ物差しで数える

効果は三方向に出ます。着手が速いこと。担当者による出来の差が縮まること。直した内容が残るため、同じ誤りが減ること。

工数も二種類かかります。初期構築工数は、シートの記入、参照情報の作成、分類定義や文例集の整備など、始めるときに一度かかる分。定常保守工数は、価格表の変更にともなう参照先の修正、担当変更による確認先の見直し、分類できない問い合わせへの定義追加など、業務が続く限り毎月かかる分です。誰がこの時間を持つかを先に決めます。

測定では、二つの時間を分けて記録します。

• 人の作業時間：入力の準備、指示、確認、修正、例外対応に人が費やした時間
• 完了までの経過時間：AIの処理待ちや承認待ちを含め、受付から完了までの時間

AIが生成している間に別の仕事ができるなら、その待ち時間は人の作業時間に足しません。人件費と要員計画に効くのは前者、顧客を待たせる長さに効くのは後者です。あわせて、修正回数、誤りの件数と理由の内訳、AI利用料金を取ります。

比較は、同じ種類の業務を導入前後で並べます。件数だけでなく難易度や担当者の経験も揃えます。条件が違うまま出た差は、AIの効果ではなく案件の違いかもしれません。

仮に、人の作業が1件20分から14分に減り、月80件、保守が月4時間なら、純削減は月4時間です（6分×80件÷60－4時間）。初期構築の時間とAI利用料金は別に評価します。数値は説明用の仮定です。

数十件の試行で出た差は、その業務・その期間の結果です。全社の効果としては扱わず、対象を広げるたびに測り直します。

二週間たっても人の作業時間が下がらない、修正回数が減らない、同じ理由の不合格が続く。そのときは01の四つに加えて、ツール連携の不具合、確認そのものの負担、試行件数の少なさも候補に入れ、順に確かめます。一つに決めつけないことです。

AIの手応えが出ない理由は一つではありません。この記事で扱ったのは、説明した内容が残らないという構造の部分です。一つの業務で、渡す情報と人が決める範囲を線引きし、基準で採点し、直した内容を元へ戻す。ここまで回せたとき、二つ目に広げる意味が出ます。業務構造そのものの設計は「AIを前提に、業務構造を設計し直す。」で扱っています。

まずは、繰り返し発生し、資料が揃い、合格・不合格を言える業務を一つ選び、シートの八欄を埋めてみてください。埋まらない欄が、いまの業務設計で決まっていない部分です。

eapでは、業務の棚卸しから、AIに任せる範囲と人が判断する範囲の線引き、運用に乗せるまでをご一緒します。AI活用・業務実装、業務DX・自動化の支援を行っていますので、どこから手を付けるかの整理を含めてご相談ください。