最初はモデルのせいにしがちです。エージェントがファイルを見落とした。違う段落を直した。ブラウザで別のページを開いた。もっともらしい要約を書いたのに、そのまま使える人がいなかった。そこで、モデルがまだ弱い、プロンプトが悪い、コンテキスト長が足りない、という話に流れます。

それが正しいこともあります。ただ、現場で何度か見ていると、別の原因の方が多いです。モデルを、仕事ができる状態に整えずに放り込んでいるのです。

その周辺の仕組みをハーネスと呼ぶことが増えています。少し技術寄りの言葉ですが、現場感には合っています。AIエージェントを実務で使うには、モデルだけでは足りません。どの情報を渡すのか、どのツールを使わせるのか、どこまで変更を許すのか、結果をどう確認するのか、人がどこで見るのか、止まった時にどう戻すのかまで決めておく必要があります。

ハーネスが弱いと、優秀なモデルでも「頭の良い新人にノートPCだけ渡した」状態です。一度はうまく動くかもしれませんが、継続して任せるのは難しいです。

つかまえたかった失敗パターン

これは機能紹介ではなく、実務で手戻りが減るかを見るための記録です。AIエージェントが現場で崩れる理由を、モデル単体ではなくハーネスの設計から見直します。文脈、権限、ログ、人の確認、復旧経路まで、導入前に決めるべき点を確認します。重要なのは、どのAIが賢そうに見えるかではなく、次の人へ渡した後に作り直しが残らないかでした。

検証台にしたエージェント業務

基準にした仕事は具体的にしました。記憶、権限、ツール呼び出し、fallback規則で信頼性が決まるエージェント業務。そのうえで、入力、AIが触る範囲、確認する人、次に渡す場所を分けて見ました。OpenAI Codex、ChatGPT、Claude、LangChain、Databricks、AI agentsは、その流れを短くし、確認を重くしない場合にだけ意味があります。

ハーネスで確認した部品

見た点判断基準失敗のサイン
入力AIが扱えるだけの材料がそろっているか足りない文脈を質問せずに推測する
人の確認承認、修正、差し戻しが短時間でできるか担当者が最初から読み直す
引き渡し文書、表、チケット、業務flowへ渡せるか次の人が形式や意味を直す
再現性別の材料でも同じ手順で動くか1回目だけよく、2回目から崩れる

デモと運用を分けたメモ

根拠確認したことなぜ重要か
入力記憶、権限、ツール呼び出し、fallback規則で信頼性が決まるエージェント業務。仕事はツール名ではなく、入ってくる材料から始まります
確認点誰が確認し、何を差し戻せるかを見ました確認者がいないと、自動化に見えるだけです
失敗メモ正常系は終わるが、権限、復旧、ツール呼び出しを省いた理由を説明できない状況。うまくいかなかった実行を一つ残すと、範囲を絞れます

良い回答でも止まった場所

弱いのは最初の回答ではありません。回答の後にある引き渡しです。このテーマでよく起きる失敗は、正常系は終わるが、権限、復旧、ツール呼び出しを省いた理由を説明できない状況。きれいな下書きは開始点であって、運用可能という証拠ではありません。

権限を広げる前に求める条件

私なら、まず元資料、判断表、失敗メモ、読者が使えるチェックリストを残します。そのうえで、人が短時間で確認できるかを見ます。確認に毎回時間がかかるなら、モデルを変える前に自動化する範囲を狭めます。

エージェントを広げる前の確認

  • AIに渡す入力を一文で書く。
  • 結果を承認、修正、却下する人を決める。
  • 出力が次に行く場所を決める。
  • 成功例だけでなく、失敗例を一つ残す。
  • 生成速度ではなく確認時間を見る。
  • 次の人が毎回作り直すなら、その自動化はいったん止める。

確認した資料

変わりやすい情報は、公式文書、製品ページ、変わりやすい主張を支える出典メモを基準にしました。価格、モデル提供範囲、機能は動くので、意見と根拠を分けて扱います。

会議で短く言うなら

AIエージェントは、単なるツール付きモデルではありません。モデルを中心に置いた作業環境です。

層何を決めるか失敗のサイン
作業パケット目的、ファイル、範囲、現在状態毎回同じ説明を求める
ツール境界ブラウザ、ターミナル、文書、API、保存先読むべきものが読めず、変えてはいけないものを変える
権限モデル読む、下書き、修正、削除、送信、公開便利な操作がそのまま業務リスクになる
確認経路テスト、diff、スクリーンショット、出典、レビュー記録結果は良さそうだが証明できない
復旧経路再試行、ロールバック、担当者、停止状態予想外のページやAPIエラーで止まる
記憶と再利用保存ルール、手順、繰り返しミス翌日また最初から始める

モデル性能は大事です。ただ、モデルは作業システムの一部です。周囲のハーネスが薄いと、エージェントを動かすたびに人間の監督業務が増えます。

ハーネスを普通の言葉で言い換える

コーディングエージェントで言えば、ハーネスはIDEだけではありません。リポジトリの状態、ブランチのルール、テストコマンド、パッケージ管理、ローカルサービス、シークレットの扱い、デプロイスクリプト、コードレビューの流れ、完了条件まで含みます。

ブラウザを使うエージェントなら、ログイン状態、許可ドメイン、出典の優先順位、スクリーンショットの残し方、ダウンロード先、ページにブロックされた時の扱いまで含みます。

文書作業なら、元ファイル、命名規則、テンプレート、表の形式、レビューコメント、バージョン履歴、エージェントが書き換えてよい箇所とコメントだけにすべき箇所の境界です。

サポートや営業運用なら、顧客データの境界、CRM項目、エスカレーション、文体ルール、承認点、実際に送信してよいのか下書きまでなのかがハーネスです。

だから私は、きれいなファイル一つとプロンプト一つでエージェントを判断することに慎重です。それはタスクを一つこなせる証明です。来週、ファイル名が変わり、ログインが切れ、顧客の文章が乱れ、レビュー担当が「どこを直したのか」と聞いた時にも動く証明ではありません。

実務で最初に壊れるところ

失敗は派手ではありません。地味なので見落とされます。

あるエージェントは要件書をうまく要約します。しかし法務セクションは書き換え対象ではないことを知りません。別のエージェントは表を読めます。しかし空欄がゼロではなく「未承認」を意味することを知りません。コーディングエージェントはテストを直します。しかしデプロイ時に同じファイルを再生成する内部スクリプトを見落とします。ブラウザエージェントは出典を集めます。しかし公式ページと転載ページを分けられません。

この場合、モデルが役に立たないわけではありません。作業の渡し方が足りなかったのです。

私はまずプロンプトのせいにはしません。ハーネス側の失敗として扱います。

起きた問題モデル変更前に直すこと
違うファイルを触った許可ファイルと編集前diffの確認を入れる
回答に根拠がない完了前に出典、画面、実行結果を残す
同じ例外が繰り返される長いプロンプトではなく運用ルールに例外を入れる
確認時間が減らない下書き、確認、最終実行を分ける
何が変わったか分からないファイル、出典、残るリスクを最後に残す
途中で権限を求める開始前に許可ツールと禁止操作を決める

表だけ見ると簡単です。実際にはここが、試して面白いものと現場で任せられるものの差です。

コードの例で見る

Codexのようなコーディングエージェントを考えると分かりやすいです。すごい点は、コードを書けること自体ではありません。コードは多くのモデルが書きます。大事なのは、既存プロジェクトの中で開発者に二つ目の仕事を作らずに動けるかです。

使えるハーネスには、次のような作業パケットが入ります。

  • 現在のブランチと、新しいブランチを作ってよいか。
  • 実行時の挙動を決める重要ファイル。
  • 正しいテストコマンドと、普段は避ける重いコマンド。
  • アプリが起動中でも使えるビルド方法。
  • デプロイ経路と、デプロイ後に残す証拠。
  • 顧客データ、シークレット、無関係な未コミット変更に触れないルール。

これがないと、エージェントは忙しく見えます。コードを読み、パッチを作り、説明もします。しかし開発者は結局、テストコマンドが正しいか、境界を壊していないか、暗黙の慣習を破っていないか、デプロイを残していないかを確認します。

それは自動化ではなく、確認コスト付きの補助作業です。

ハーネスがあれば、同じエージェントの使い勝手は変わります。どこから始めるか、どう証明するか、いつ止まるか、人が信頼できる引き継ぎをどう残すかが決まるからです。

文書業務の例

コード以外でも同じです。3つのPDF、1つの表、2回分の打ち合わせメモから、ベンダー比較メモを作るとします。

弱い依頼はこうです。「これを読んで比較して。」

強いハーネスはこうなります。

  • ベンダー一覧はPDFではなく表を正とする。
  • 価格は最新日付の資料からだけ拾う。
  • 未確認情報は推測せず「未確認」と書く。
  • セキュリティ懸念は点数に混ぜず、別項目にする。
  • 推薦に影響する文には出典メモを残す。
  • メモの下書きは作るが、最終推薦文は人の確認前に書き換えない。

地味です。しかし信頼はここで決まります。確定情報と打ち合わせ中の発言を分けられず、推薦の根拠を残せないエージェントに、私は判断を任せません。

現場での判断：範囲を広げる前に見ること

エージェントの権限や範囲を広げる前に、私は四つを確認します。

一つ目は、開始前に仕事の形を分かっているか。人が毎回フォルダ構造、出典順、出力形式を説明するなら、ハーネスはまだ弱いです。

二つ目は、言わなくても根拠を残すか。diff、出典、実行結果、スクリーンショット、レビューしやすい変更一覧が必要です。自信のある文章は根拠ではありません。

三つ目は、権限境界が退屈なほど明確か。読むだけなら広めでもよいです。下書きも少し広げられます。送信、削除、公開、支払い、顧客記録の変更は、確認経路が十分に安定するまで狭くします。

四つ目は、失敗した実行が次を良くするか。止まった実行が「もう一度やる」で終わるなら、何も学んでいません。例外がルール、チェックリスト、保存スキルになるなら、ハーネスが育っています。

「エージェントの品質」より見る指標

エージェントが良いか悪いか、という質問は大きすぎます。

私は確認負担を確認します。人が結果確認に何分使ったか。直す必要のある事実はいくつあったか。入力不足で何回止まったか。最終操作が何回差し戻されたか。人が手でやり直したステップはいくつか。

見栄えのよい下書きを作っても確認時間が減らないなら、ハーネスはまだ働いていません。少し地味な下書きでも手戻りが減り、引き継ぎが明確になるなら、私はそちらを選びます。

質問良いサイン悪いサイン
現在状態を理解しているか正しいファイル、日付、担当者を参照するシステム内の基本情報を聞き返す
ツールを安全に使うか広く読み、狭く書く計画を見せる前に編集する
根拠を残したかレビュー担当が経路を確認できる人が作業を再現しないと分からない
失敗が次を良くしたか例外がルールになる次も同じミスをする
人の仕事が減ったか確認時間が下がるきれいだがまだ危ない

エージェントを先に選ばない

私は「どのエージェントを買うか」から入りません。まず痛みが見える繰り返し業務を一つ選びます。

良い候補には、明確な入力、繰り返せる出力、レビュー担当、測れる引き継ぎがあります。悪い候補は、隠れた政治、曖昧な判断、確認習慣のない実行権限に頼っています。

たとえば「週次のベンダーリスクメモの下書きを、出典付きで作る」は始められます。「ベンダーリスクを処理する」は大きすぎます。前者にはハーネスがあります。後者は願望です。

プロンプト集に失望する理由もここにあります。プロンプトは一瞬を良くします。ハーネスはその前後の流れを良くします。

失敗基準を先に書く

エージェントがうまく見える前に、中止基準を書いた方がよいです。

  • 推薦の出典を言えないなら止める。
  • 人が全行を確認し直すなら止める。
  • 日常業務のために権限拡大を何度も求めるなら止める。
  • 確認前に外部向け資料を書き換えるなら止める。
  • 同じ例外が3回続くなら止める。
  • 担当者がエージェントの作業内容を説明できないなら止める。

慎重に見えます。それでも、実システムに触れた後で自信のあるミスを回収するより安いです。

先に作るもの

モデルを替える前に、小さなハーネス文書を作ります。1枚で足ります。

  1. どんな仕事がエージェントに入るか。
  2. エージェントが何を読めるか。
  3. エージェントが何を変えられるか。
  4. どんな根拠を残すか。
  5. 誰が結果を確認するか。
  6. 止まった時にどう扱うか。
  7. どの繰り返しミスを新しいルールにするか。

そのうえで同じ仕事を5回回します。雰囲気ではなく確認時間を比べます。5回目でも1回目と同じ説明を人がしているなら、まだ解けていません。

よくある質問

ハーネスエンジニアリングはコードだけの話ですか？

違います。コードではリポジトリ、テスト、diffがあるので問題が見えやすいだけです。文書、ブラウザ調査、サポート、営業運用、社内レポートでも同じです。

モデルが良くなればハーネスは不要ですか？

一部のミスは減ります。ただし運用問題は残ります。強いモデルにも、正しい文脈、安全なツール、根拠、確認経路が必要です。

すべての業務をエージェント化すべきですか？

いいえ。まれな仕事、判断が重い仕事、組織的な調整が絡む仕事は、チェックリストと良い担当者の方が向く場合があります。繰り返し、根拠、引き継ぎが明確な時にエージェントは力を出します。

ハーネスが効き始めた最初のサインは何ですか？

エージェントの動きが落ち着きます。設定質問が減り、根拠が残り、止まる時は安全に止まり、レビュー担当の仕事を増やさなくなります。

最後の判断

次のAIエージェントの差は、モデルの大きさだけでは決まりません。仕事を渡しやすく整え、ツールを制限し、結果を証明し、繰り返し失敗を運用ルールに変えるチームが強くなります。

だからハーネスエンジニアリングが重要です。モデルの横に置く飾りではありません。一度だけうまくいく実行と、明日も任せられる業務の流れを分けるものです。

業務フロー

このガイドがつながる業務フロー

読んでいるガイドが、どの業務フローに関係するのかを確認できます。

ツールスタック選定 チームの運用成熟度に合うスタックを選びます。

自動化プラットフォーム、アプリビルダー、エージェントビルダー、会計ツール、汎用AIアシスタントを比較するルートです。

関連トピックを見る
向いている場合
単体ツール購入、社内ワークフロー構築、広いプラットフォーム導入で迷うチーム
向かない場合
判断基準よりも手順書が先に必要な場合は、実装型の記事の方が向いています。
関連ガイド

参照した公開情報

報道内容、公式文書、政策背景、製品情報、変わる可能性のある主張を確認するために参照した公開情報です。

次のステップ

このガイドを運用チェックリストに変える。

まずリソースで業務フローを点検し、現在のプロセスと引き継ぎポイントを整理してからツールを比較します。

比較 更新を報告