AIの性能を上げても、仕事が安定しない理由
AIエージェントに仕事を任せるとき、最初に比較されやすいのはモデルの性能です。
しかし、同じモデルを使っても、結果が安定する現場と、毎回やり直しになる現場があります。
差を生むのは、モデルの外側にある設計です。
- 何を前提として読ませるか
- どの情報を正本として扱うか
- どのツールを使ってよいか
- どこまで自動で進めるか
- 何を確認したら完了とするか
- 失敗したとき、何を次回へ残すか
この外側の仕組みを、ここではハーネスと呼びます。ハーネスエンジニアリングは、AIに長い指示を与える技術ではありません。AIが同じ業務を繰り返すたびに、判断材料と確認手順が少しずつ改善されるように、仕事の環境を設計することです。
ハーネスは「モデル以外の全部」ではなく、境界を引くための言葉
ハーネスという言葉の範囲は、製品や研究者によって少し違います。
OpenAIはCodexの説明で、ユーザーの入力をモデルへの指示にまとめ、モデルのツール呼び出しを実行し、その結果を次の推論へ戻すエージェントループを説明しています。Anthropicも、ハーネスをモデルへ呼び出しを送り、ツールの実行先へ振り分けるループとして説明しています。
一方、実務で使うときは、ループだけでなく、指示ファイル、スキル、接続先、権限、ログ、レビューも含めて考えた方が便利です。
重要なのは、定義を一つに決めることではありません。
「モデルが考える部分」と「モデルが考えるために用意された外側」を分けて見ることです。定義の違いで議論を止めず、今回どの境界を設計しているのかを明示すれば、話が具体的になります。
AIが止まるのは、文章力だけが原因ではない
例えば、会議の記録から責任者向けの報告書を作る業務を考えます。
AIに「会議メモを報告書にして」と頼めば、文章らしいものは返ってきます。ただし、実務で必要なのは文章の流暢さだけではありません。
- 誰が読むのか
- 何を意思決定してほしいのか
- 過去の報告書で何が基準になっているか
- 会議メモ以外に参照すべき資料は何か
- 不足情報を見つけたら、どこで止まるか
- 公開や送信の前に誰が確認するか
この条件が決まっていなければ、AIが正しい文章を書いても、仕事は完了しません。
ハーネスの役割は、AIの頭の良さを補うことだけではありません。業務の目的、入力、出力、確認者、停止条件をつなぎ、AIの出力を次の判断へ渡せる状態にすることです。
最初に残すべきは、成功例ではなく失敗の型
AI導入の初期に、うまくいった回答だけを保存する運用は危険です。成功例は、なぜ成功したのかが分かりにくいからです。
先に残すべきなのは、次の実行でも起きそうな失敗です。
- 必要な資料を読んでいなかった
- 古い資料を正本として扱った
- 出力の対象読者を取り違えた
- 途中で確認すべきなのに最後まで進めた
- 事実と推測を区別しなかった
- 人間の承認なしに送信や公開へ進もうとした
失敗を見つけたら、次の5項目で記録します。
- 何を依頼したか
- どの前提が不足していたか
- どの出力が問題だったか
- 次回から何を変えるか
- 変更後に何を確認するか
ここで大事なのは、毎回同じ失敗をプロンプトで注意し直さないことです。繰り返し出る失敗は、指示ファイル、チェックリスト、ツール制限、入力フォーマットのどこかへ移します。
まずは4つのファイルで十分
ハーネスを始めるために、いきなり複雑なマルチエージェント構成や独自連携を作る必要はありません。1業務につき、次の4つから始められます。
業務名/
AGENTS.md または CLAUDE.md 指示と禁止事項
inputs.md 入力の正本と参照先
checks.md 完了条件と人間の確認点
failure-log.md 失敗、原因、次回の変更ファイル名は使う製品に合わせてください。大切なのは名前ではなく、役割を分けることです。
AGENTS.md や CLAUDE.md には、業務の目的、対象範囲、禁止事項、実行してよい操作だけを書きます。正本の場所や古い資料の扱いは inputs.md に、合格条件は checks.md に置きます。失敗ログには、感想ではなく次回の行動変更を書きます。
例えば、次のような記録です。
失敗: 直近の料金情報ではなく、古い資料を参照した
原因: 正本の場所と確認日を入力に書いていなかった
変更: inputs.mdに正本URL、確認日、対象期間を追加する
確認: 次回の出力に参照元と確認日が表示されるかを見るこれだけでも、失敗が会話の中だけで消える状態から、業務資産として残る状態へ変わります。
指示ファイルは「全部を説明する場所」ではない
Codexの公式ドキュメントでは、AGENTS.md は作業前に読み込まれる追加指示であり、プロジェクトの階層に応じて適用範囲を分けられると説明されています。Claude Codeでも、CLAUDE.md とルールファイルを使って、セッションをまたぐプロジェクト文脈を整理できます。
ただし、指示ファイルを長くすればよいわけではありません。
最初のファイルには、次のような「迷うと危険なこと」だけを置きます。
- 業務の目的と対象範囲
- 正本の場所
- 参照してはいけない情報
- 自動実行してよい操作
- 人間の承認が必要な操作
- 完了条件
- 失敗ログの保存先
詳しい手順や専門知識は、別のスキルやチェックリストへ分けます。また、追加ディレクトリの指示ファイルは自動で読まれない場合があります。重要なファイルは、ツールの公式仕様を確認したうえで、入口の指示から明示的に案内してください。
ハーネスに必ず入れる4つの境界
業務用のハーネスでは、便利さより先に境界を置きます。
1. 情報の境界
AIが読んでよい資料、参考にするだけの資料、読ませない資料を分けます。古い資料や個人情報を、正本と同じフォルダーに置かないことも重要です。
2. 操作の境界
読み取り、下書き、ファイル編集、外部送信、公開、削除を同じ権限にしません。最初は読み取りと下書きだけに絞ります。
3. 品質の境界
「それらしい」ではなく、何を満たせば合格なのかを決めます。出典、対象者、形式、数値、リンク、禁止表現など、機械的に見られる項目から始めます。
4. 停止の境界
不足情報、矛盾、権限不足、未確認の外部事実があるときは、推測で埋めずに止めます。人間へ質問を返すことは、失敗ではなくハーネスが機能している状態です。
7日間で回す最小の学習ループ
長期の自動化をいきなり目指すと、どの部品が効いたのか分からなくなります。最初は1業務、1出力、7日間で十分です。
1日目: 業務を一つに絞る
社内報告、問い合わせ下書き、議事録整理など、入力と出力が見える作業を選びます。公開、送信、請求、契約変更は最初の対象から外します。
2日目: 現状を記録する
AIなし、または現在の依頼文で一度実行し、所要時間、手戻り、確認漏れを記録します。比較対象がないと改善を判断できません。
3日目: 失敗を一つだけ分類する
情報不足、指示不足、ツール不足、品質基準不足、承認不足のどれかに分類します。全部を一度に直しません。
4日目: 変更を一つだけ入れる
指示ファイル、入力一覧、チェック項目のうち、一つだけ変更します。複数を同時に変えると、効果が分かりません。
5日目: 同じ条件で再実行する
同じ入力に近いケースで実行し、変更前と比べます。文章がきれいになったかではなく、手戻りが減ったか、確認漏れが減ったかを見ます。
6日目: 人間の確認点を更新する
AIが安定してできることは自動確認へ寄せ、まだ不安定なことは人間の確認点として残します。
7日目: 残す、戻す、広げるを決める
効果があった変更だけを残し、効かなかった変更は戻します。次の業務へ広げるのは、入力、出力、停止条件、責任者が説明できるようになってからです。
Anthropicの公式記事でも、長時間のエージェント作業では、作業を小さく分け、次のセッションへ成果物を残すことが重要だと説明されています。ハーネスは、一度作って終わる設定ではなく、実行結果を受けて更新する作業環境です。
複雑にする前に、効いている部品を確かめる
ハーネスを整えると、スキル、フック、外部連携、複数エージェントを追加したくなります。
しかし、部品を増やすほど、どこで失敗したのか分かりにくくなります。最初はMarkdownの指示、入力一覧、合格条件、失敗ログだけで試し、それで解けない問題が出たときに一つずつ機能を追加します。
追加した部品には、次の記録を残してください。
- 解決したかった失敗
- 追加した部品
- 期待した変化
- 実際に変わった結果
- 不要になった場合の削除方法
モデルが更新されたら、以前のハーネスがまだ必要かも見直します。公式のハーネス研究でも、ハーネスには「モデルが自力でできない」と置いた仮定が含まれ、その仮定はモデルの改善で古くなり得ると指摘されています。
まとめ: AIを育てるのではなく、仕事の仕組みを育てる
ハーネスエンジニアリングを難しい開発手法として始める必要はありません。
まず、モデルと外側の仕組みを分けます。次に、1業務の入力、出力、確認、停止を定義します。最後に、失敗をログへ残し、次の実行に一つだけ反映します。
AIに同じ注意を何度も伝えているなら、その注意は会話からファイルやチェックへ移す候補です。AIが途中で止まるなら、止める条件と質問先が不足している可能性があります。出力の確認に時間がかかるなら、完了条件が曖昧なのかもしれません。
モデル選びは大切です。ただし、業務を継続的に改善したいなら、モデルの周囲に何を残し、どこで人間へ戻すかを先に設計する方が、長い目で見て効きます。