「AIをうまく動かすには、良いプロンプトを書けばいい」。生成AIが文章を返すだけだった頃、この考え方はかなり正しかった。しかし、AIが検索し、ファイルを読み、コードを実行し、外部サービスを操作するAIエージェントになると、状況は変わる。
結論から言えば、AIエージェントの品質を大きく左右するのは、プロンプト単体ではなく、モデルの周囲にあるエージェントハーネスである。
ハーネスとは、モデルに渡す情報を選び、ツールを実行し、状態を保存し、失敗時にやり直し、危険な操作を止め、完了を検証する仕組みの総称だ。モデルが「頭脳」なら、ハーネスは仕事場、道具、手順書、安全管理、進捗記録をまとめた実行環境である。
エージェントハーネスとは何か
通常のLLMは、入力を受け取り、文章を出力する。それだけではメールを送ることも、データベースを更新することも、途中経過を翌日に引き継ぐこともできない。
そこで必要になるのが、次のような処理を担当するハーネスだ。
- モデルを繰り返し呼び出す実行ループ
- 検索、API、コード実行などのツール接続
- 会話履歴、作業状態、長期記憶の管理
- ツール実行結果を次の判断材料へ戻す処理
- 権限確認、人間の承認、安全ルール
- タイムアウト、再試行、失敗からの復旧
- 実行ログ、トレース、評価、コスト監視
- 「本当に終わったか」を確かめる完了判定
AIエージェント ＝ モデル ＋ エージェントハーネス
プロンプトは重要だが、ハーネスを構成する一部にすぎない。MicrosoftのAgent Frameworkも、ハーネスをモデルが複数ステップの作業、ツール利用、文脈管理、安全な実行を行うための足場として説明している。OpenAIのAgents SDKにも、実行ループ、ツール、セッション、ガードレール、承認、トレースといった機能が組み込まれている。
なぜ「プロンプト中心」では足りなくなったのか
1. 一回の回答ではなく、行動の連鎖を扱うから
文章生成では、入力と出力を一度ずつ見ればよかった。だがエージェントは、「調べる→判断する→実行する→結果を確認する→修正する」という連鎖で動く。
このとき問題になるのは、指示文の表現よりも、次のような実行上の設計だ。
- どのツールを選べるのか
- ツールが失敗したとき何回まで再試行するのか
- 同じ処理を二重に実行しないか
- 途中の判断をどこへ保存するのか
- どの条件で作業を終了するのか
プロンプトを丁寧にしても、決済APIが二重実行される設計なら事故は防げない。逆に、適切な権限、冪等性、承認フロー、検証処理があれば、モデルが多少迷っても被害を抑えられる。
2. エージェントの失敗は途中で増幅するから
一回の文章生成なら、小さな誤りは小さな誤りで終わる。しかしエージェントでは、最初の検索ミスが誤った計画につながり、その計画が誤ったツール操作につながる。数ターン後には、どこで間違えたのか分からなくなる。
だから必要なのは「間違えない魔法の指示」ではなく、途中の状態を観測し、検証し、失敗を早く止める仕組みだ。Anthropicもエージェント評価では、最終回答だけでなく、ツール呼び出しや中間結果を含む実行軌跡と、環境の最終状態を確認する重要性を説明している。
3. 長時間の作業では、記憶の引き継ぎが品質を決めるから
長いタスクは一つのコンテキストに収まらない。単純に履歴をすべて詰め込むと、コストが増え、重要情報が埋もれ、モデルが古い方針に引きずられる。
必要なのは、会話履歴の保存だけではない。決定事項、未完了タスク、変更したファイル、検証結果、次に試すことを、次の実行へ渡せる形で残す必要がある。Anthropicの長時間エージェントに関する報告でも、初期環境を整える役割と、少しずつ進めながら次のセッションへ明確な成果物を残す役割を分ける方法が紹介されている。
プロンプトで直す問題、ハーネスで直す問題
現場でありがちな失敗は、すべてをプロンプト修正で解決しようとすることだ。次の切り分けをすると、無駄な試行錯誤が減る。
| 症状 | 疑うべき原因 | 最初に直す場所 |
|---|---|---|
| 同じツールを何度も呼ぶ | 終了条件、エラー表現、再試行制御が曖昧 | 最大試行回数、状態遷移、型付きエラー |
| 以前の決定を忘れる | 履歴の詰め込み、要約の欠落、永続状態がない | 決定ログ、タスク台帳、コンテキスト圧縮 |
| 「完了した」と言うが実際は終わっていない | 自己申告を完了条件にしている | API、DB、ファイルなど実状態の検証 |
| 実行コストが急増する | ツール出力が大きい、不要な履歴を毎回渡す | ページネーション、検索、要約、キャッシュ |
| 危険な操作を勝手に行う | 権限境界と承認フローがない | 読み取りと書き込みの分離、人間の承認 |
| 同じ入力でも品質が安定しない | 評価ケースと実行ログが不足 | 複数回試行、回帰テスト、トレース分析 |
一方、プロンプトが向いているのは、役割、優先順位、出力形式、禁止事項、判断基準、説明の粒度などを伝えることだ。
タイムアウト、権限、再試行、データ取得、状態保存、監査ログ、完了確認まで自然言語だけに任せるべきではない。守らなければ事故になるルールは、文章ではなくコードとシステムで強制した方がよい。
優れたハーネスを作る6つの設計ポイント
1. 「何を言ったか」ではなく「何が変わったか」で完了を判定する
エージェントが「予約しました」と答えたことと、予約データが実際に存在することは別だ。完了判定は、可能な限り外部状態で確認する。
- メール送信なら送信済みIDを確認する
- ファイル作成なら存在、形式、内容を検査する
- コード修正ならテストを実行する
- 予約なら予約番号と日時を取得する
- 記事投稿なら公開状態とURLを再取得する
これは小さな違いに見えるが、デモと実用品を分ける重要な境界である。
2. ツールを増やすより、迷わないツールを作る
ツールが多ければ賢くなるとは限らない。名前が似ている、説明が曖昧、引数が複雑、返却データが巨大といったツールは、エージェントを混乱させる。
良いツールには、役割が重ならない名前、狭く明確な責務、入力例、失敗理由、必要十分な返却値がある。Anthropicのツール設計に関する検証でも、ツールの選び方、名前空間、説明、返却情報、トークン効率を評価しながら改善することが重視されている。
3. 記憶を「会話ログ」ではなく「作業用データ」にする
全会話を保存するだけでは、実用的な記憶にならない。少なくとも次の情報は分けて持つべきだ。
- 短期状態：現在の手順、直前のツール結果
- 決定記録：採用した方針と理由
- 成果物：作成・変更したファイルやデータ
- 未完了項目：残作業、ブロッカー、次の一手
- 長期知識：ユーザー設定、業務ルール、過去の成功例
重要なのは、保存量ではなく、次の判断に必要な情報を正しく取り出せることだ。
4. 失敗を「文字列」ではなく「次の行動」に変換する
ツールが単に「Error」と返すと、モデルは原因を推測するしかない。エラーは、再試行可能か、入力修正が必要か、権限不足か、人間への確認が必要かを区別して返す。
RETRYABLE：一時障害。待機して再試行INVALID_INPUT：引数を修正して再実行PERMISSION_DENIED：権限または承認が必要NOT_FOUND：別の検索方法へ切り替えるFATAL：停止して人間へ報告
5. 取り返しのつかない操作には摩擦を入れる
優れたエージェントは、何でも自動化するエージェントではない。間違えたときの損失に応じて、あえて止まる設計を持つ。
検索や下書きは自動実行し、送信、公開、購入、削除、送金、権限変更などは承認を求める。さらに、可能なら下書き、プレビュー、取り消し、ロールバックを用意する。
「便利さを最大化する」より、「安全に任せられる範囲を広げる」方が、長期的には自動化率を上げやすい。
6. 最終回答だけでなく、実行軌跡を評価する
エージェントの改善では、結果が正しいかだけでなく、どのように到達したかを見る必要がある。
- 不要なツール呼び出しはなかったか
- 危険な操作の前に承認したか
- 古い情報を根拠にしていないか
- 途中の失敗から適切に回復したか
- コストと時間が許容範囲か
OpenAIのAgents SDKは、モデル呼び出し、ツール、ガードレール、引き継ぎなどをトレースできる。こうした観測機能がなければ、改善は「プロンプトを少し変えて祈る」作業になってしまう。
実装前に使える「30分ハーネス監査」
既存のAIエージェントを改善するときは、プロンプトを書き直す前に、次の質問へ答えるとよい。
- 完了を外部状態で証明できるか。
- 途中で停止しても、再開に必要な状態が残るか。
- 各ツールの役割が重ならず、失敗理由が明確か。
- ツールの返却値が大きすぎず、必要部分を取得できるか。
- 破壊的・金銭的・公開操作に承認境界があるか。
- 一回の実行を、モデル・ツール・状態変化まで追跡できるか。
- 現実的なテストケースで複数回評価しているか。
三つ以上に「いいえ」があるなら、プロンプト改善よりハーネス改善の方が効果は大きい可能性が高い。
開発の順番も変えるべき
AIエージェントを作るとき、最初から長大なシステムプロンプトを書く必要はない。現実的な順番は次の通りだ。
- 成功と失敗を、観測可能な状態で定義する
- 実際の利用に近い評価タスクを20件ほど用意する
- 短く明確な基準プロンプトを作る
- 必要最小限のツールと単純な実行ループを作る
- ログを読み、失敗を「指示・文脈・ツール・状態・制御」に分類する
- 頻出する失敗をコード、検証、権限、記憶へ移す
- 最後にプロンプトを調整し、回帰評価する
ここで重要なのは、プロンプトを最後まで放置することではない。最初に十分な基準を作り、その後の失敗を何でもプロンプトへ押し込まないことだ。
プロンプトは不要になったのか
不要ではない。曖昧な役割、矛盾した制約、悪いツール説明は、今でも性能を大きく落とす。特に、判断基準、優先順位、出力形式、ユーザーへの説明方法は、プロンプトで明確にする価値が高い。
ただし、一定水準を超えた後は、言い回しを微調整するより、次の改善の方が効きやすい。
- 正しい情報だけを必要な瞬間に渡す
- 迷いにくいツールを用意する
- 失敗を検出して回復する
- 危険な操作をシステム側で止める
- 完了を実状態で検証する
- 実行履歴から継続的に評価する
つまり、プロンプトの重要性が下がったというより、AIエージェント全体に占める割合が相対的に小さくなったと考える方が正確だ。
ハーネスは技術基盤ではなく「責任の設計」である
エージェントハーネスの本質は、モデルを便利に動かすランタイムだけではない。
ハーネスは、AIが何を見られるか、何を変更できるか、どこで止まるか、何を証拠として残すか、いつ人間へ判断を返すかを決める。つまり、組織がAIへどこまで責任を渡すかを、実行可能なルールへ変換する層である。
この視点に立つと、ハーネス設計はエンジニアだけの仕事ではなくなる。業務担当者は成功条件を定義し、セキュリティ担当者は権限境界を決め、運用担当者は復旧方法を設計し、法務や管理者は監査可能性を確認する必要がある。
まとめ
AIエージェントの時代に重要なのは、モデルへ何と頼むかだけではない。モデルがどの情報を受け取り、どの道具を使い、どの状態を記憶し、どの失敗から回復し、どの条件で止まるかを設計することだ。
良いプロンプトは、優秀な作業者へ渡す分かりやすい指示書である。しかし、道具が壊れ、資料が散らかり、権限が無制限で、進捗記録も検品工程もない職場では、優秀な作業者でも安定した成果は出せない。
これからのAI開発で差がつくのは、プロンプトを書く技術だけではなく、知能を安全で再現可能な仕事へ変えるハーネスを設計する技術である。
