生成AIの品質を高める作業をすべて「プロンプトをうまく書くこと」とひとまとめにすると、失敗原因を正確に診断しにくい。プロンプト・コンテキスト・ハーネス・エージェンティック・ループエンジニアリングは、互いに置き換わる流行語ではなく、要求の表現、情報の選択、実行環境、自律的な意思決定、反復的な改善という異なる制御面を扱う補完的な設計方法である。

5つの概念の核心定義

区分 核心となる質問 主な設計対象 代表的な成果物 代表的な成功基準
プロンプトエンジニアリング AIに仕事をどう指示するか？ 指示文、制約、例、出力形式 プロンプトテンプレート、例示入力・出力 指示遵守率、形式の正確性、一次結果の品質
コンテキストエンジニアリング 今AIに何を見せるか？ システム指示、検索文書、会話状態、メモリ、ツール結果 コンテキスト組み立てルール、検索・要約ポリシー 関連性、最新性、根拠性、トークン効率
ハーネスエンジニアリング AIがミスしにくいように、どのような作業環境を作るか？ ツール、権限、サンドボックス、リポジトリ構造、検証器、ログ 作業ルール、ツールインターフェース、テスト・CI、ランブック 再現性、安全性、検証可能性、復旧可能性
エージェンティックエンジニアリング 次の行動を誰が、どの範囲で決めるか？ 目標、計画、ツール選択、状態遷移、委任 エージェントループ、オーケストレーション、承認ポイント タスク完了率、適切なツール選択、人間介入率
ループエンジニアリング 最初の結果が間違っていたとき、どのように収束させるか？ 生成、評価、原因分類、修正、再実行、終了条件 評価器、回帰テスト、再試行ポリシー、失敗分類 一次通過率、復旧率、反復回数、最終通過率

5つの概念を一行でつなぐと次のようになる。

要求を表現する → 必要な情報を見せる → 安全な作業環境を提供する → AIに次の行動を選ばせる → 結果が基準を通過するまで検証し改善する。

用語を解釈するときの注意点

プロンプトエンジニアリングとエージェントは比較的広く使われる用語だが、ハーネスエンジニアリングはまだ使用範囲が文脈によって異なる。ある文章ではモデルを除いたほぼすべての実行レイヤーをハーネスと呼び、別の文章ではコーディングエージェントのユーザーがリポジトリの外側に作るルール・検証・フィードバック構造に絞って説明する。「ループエンジニアリング」も単一の標準によって固定された正式な分類というより、生成と検証を閉じたフィードバック過程として設計するという実務的な名称として理解するほうが正確である。([OpenAI][1])

1. プロンプトエンジニアリング：指示の品質を設計する

プロンプトエンジニアリングは、モデルに伝える指示を明確で検証可能なものにする作業である。多くの場合、1回の要求と応答で最も目に見える効果を出すが、システムメッセージやマルチターン会話のルールにも適用される。

良いプロンプトは通常、次の要素を分離する。

  • 目標： 何を完了すべきか
  • 入力： 分析対象と入力の境界はどこまでか
  • 制約： してはいけないこと、許容範囲、長さと形式
  • 出力契約： JSON、表、コードパッチなどの結果構造
  • 成功基準： 何を満たせば正解と見なすか
  • 不確実性の処理： 情報が不足している、または衝突しているときどうするか
  • 例： 期待される行動を示す代表的な入力・出力

実務テンプレートは次のように単純に始められる。

目標:
入力:
制約:
出力形式:
成功基準:
検証方法:
不確実なときの処理:
代表例:

プロンプトを磨く前に、成功基準と経験的なテスト方法を先に定義しなければならないという点が重要である。すべての失敗がプロンプト修正で解決されるわけではなく、コスト・遅延時間・ツールエラー・誤った資料選択は別のレイヤーの問題である可能性がある。([Claude Platform Docs][2])

プロンプトエンジニアリングがうまく解決する問題

  • 結果形式が頻繁に崩れる問題
  • 指示の優先順位が曖昧な問題
  • 分類、抽出、変換、要約のように入力と出力が比較的明確な問題
  • 代表例を与えると性能が安定する問題

プロンプトだけでは解決しにくい問題

  • 必要な事実やファイルが入力にない場合
  • 古い文書や互いに矛盾する文書が混ざっている場合
  • 外部システムを安全に照会・修正しなければならない場合
  • 複数段階の実行状態と失敗復旧が必要な場合
  • 結果が正解かどうかを客観的に検査する方法がない場合

2. コンテキストエンジニアリング：AIが見る情報を設計する

コンテキストエンジニアリングは、モデルが答えを生成する瞬間に利用できる情報全体を選択・整列・圧縮・更新する作業である。コンテキストにはプロンプトだけでなく、システム指示、ユーザー要求、会話履歴、検索文書、メモリ、ツール説明、ツール実行結果、現在時刻、権限状態と作業進行状態が含まれ得る。

コンテキストウィンドウは有限であるため、「たくさん入れること」ではなく必要な情報を適時に入れることが目標だ。Anthropicはコンテキストをエージェントの重要だが有限な資源として説明し、長い相互作用では最小限のツールセット、代表例、ランタイム検索、圧縮とメモリのような戦略を推奨している。([人類学的][3])

核心的な設計原則

  1. 関連性優先： 現在の段階に必要な情報だけを入れる。
  2. 出典と最新性： 文書の作成時点、バージョン、所有者、信頼度を一緒に管理する。
  3. 即時検索： すべての資料を事前に注入するより、必要なときにファイル・DB・検索システムから取得する。
  4. 情報の階層化： 固定ルール、現在のタスク、参考資料、ツール結果を区別する。
  5. 衝突処理： 複数の資料が異なる場合、優先順位と基準となる原本を明示する。
  6. 圧縮と状態保持： 古い会話は要約するが、決定、未解決問題、根拠リンクは失わない。
  7. 指示とデータの分離： Webページや文書内の文章をシステム命令のように扱わないよう境界を置く。

例

顧客サポートAIが返金ポリシーについて答えるとき、単に「正確に答えよ」というプロンプトだけを強化しても限界がある。適切なコンテキストエンジニアリングは、顧客の国、購入日、商品タイプ、現在のポリシーバージョン、例外条項、注文状態を必要な瞬間に照会して一緒に提供し、回答に使用したポリシー条項を追跡可能にする。

3. ハーネスエンジニアリング：AIが働く環境を設計する

ハーネスは、モデルの知能を実際の業務につなぐ実行の骨格である。ハーネスエンジニアリングは、AIがよく起こすミスを文書、ツール、権限、構造、自動検証とフィードバックによって予防したり早期に発見したりできるよう、作業環境を設計することである。

ハーネスの主な構成要素

構成要素 役割 例
作業指示 反復業務の手順と禁止事項を明示 AGENTS.md、ランブック、チェックリスト
知識構造 AIが必要な資料を見つけやすくする リポジトリマップ、ADR、用語集、例の集合
ツールインターフェース 行動の入力・出力を明確に制限 ファイル検索、DB照会、コード実行、デプロイAPI
実行環境 失敗を隔離し再現性を高める サンドボックス、コンテナ、固定依存関係
検証器 結果が基準を満たすか自動確認 スキーマ検査、単体テスト、リンター、ポリシー検査
権限・承認 危険な行動を制限 最小権限、読み取り/書き込み分離、人間の承認
観測性 何を見てどの行動をしたかを記録 トレース、ログ、ツール呼び出し記録、コスト
復旧構造 失敗後に安全に戻して再開 チェックポイント、ロールバック、再試行予算

OpenAIのハーネスエンジニアリング事例は、エンジニアの役割を単なるコード作成よりも、環境、意図、リポジトリ知識、テスト・検証・レビュー・復旧ループを設計する方向として説明している。核心は、AIに「もっと頑張れ」と再要求することではなく、不足していた能力と信号を環境に明示的に追加することである。([OpenAI][1])

資料構造の例

/ai
  /instructions   # 共通ルールと役割別指示
  /skills         # 反復作業手順
  /examples       # 良い結果と悪い結果
  /evals          # 評価データと採点ルール
  /policies       # 権限、セキュリティ、承認ポリシー
  /runbooks       # 障害・例外対応

この構造自体が正解ではない。重要なのは、資料が最新状態に保たれ、重複・衝突が少なく、AIが必要な時点で見つけられ、ルールが自動検査につながるかどうかである。

4. エージェンティックエンジニアリング：目標とツールを与えて次の行動を委任する

エージェンティックエンジニアリングは、AIに目標、ツール、作業状態と境界条件を与え、目標を達成するための次の段階を一定の範囲で自ら選ばせる設計である。

Anthropicはワークフローを、あらかじめ定められたコード経路でLLMとツールを調整するシステム、エージェントを、モデルが自身の過程とツール使用を動的に決定するシステムとして区別している。OpenAIもエージェントを、LLMがワークフローの実行を管理し、外部システムと相互作用するツールを動的に選択するシステムとして説明している。([人類学的][4])

基本エージェントループ

  1. 現在の目標と状態を観察する。
  2. 次の下位目標や行動を計画する。
  3. ツールを選択して実行する。
  4. 結果と環境変化を確認する。
  5. 完了、修正、再試行、人間への引き継ぎのいずれかを決定する。

エージェントが適している場合

  • 作業順序が入力ごとに変わる場合
  • 自然言語、文書、コードのような非構造化情報を解釈しなければならない場合
  • 複数のツールを選択的に使わなければならない場合
  • 中間結果を見て計画を変えなければならない場合
  • 失敗原因が多様で、一定水準の復旧が可能な場合

エージェントが過剰な場合

  • ルールと順序が固定された単純な自動化
  • 単一のAPI呼び出しやSQLで確実に解決できる業務
  • 検証手段がなく、エラーコストが非常に大きい業務
  • 決済、削除、デプロイのように戻しにくい行動を承認なしに実行する構造
  • 単一エージェントで十分なのに役割だけを増やしたマルチエージェント構造

自律性は二分法ではない。推薦だけを行う補助型、制限された読み取り・書き込みだけを許可した実行型、主要段階ごとに承認を受ける監督型、低リスク範囲で長時間動作する高自律型に分けられる。業務リスクと検証能力に合わせて段階的に拡張しなければならない。

5. ループエンジニアリング：検証可能な改善過程を設計する

ループエンジニアリングは単純な再試行ではない。生成 → 検証 → 失敗原因分析 → 修正戦略選択 → 再実行 → 終了判断を明示的な閉じたフィードバックシステムにすることである。

適切なループの構成

  1. 候補生成： 草案、コード、計画、データ変換結果を作る。
  2. 検証： テスト、スキーマ、参照データ、ポリシー、根拠検査を実行する。
  3. 原因分類： 指示エラー、コンテキスト欠落、ツール失敗、実装欠陥、評価器欠陥を区別する。
  4. 修正： 失敗原因に合う最小変更を適用する。
  5. 再実行： 全体を最初から繰り返さず、必要な段階から再び実行する。
  6. 終了： 通過、最大反復回数、コスト上限、時間上限、不確実性しきい値のいずれかで止める。
  7. 回帰保護： 新しい修正が既存の成功事例を壊していないか確認する。

エージェント評価は、入力と出力だけを見る単一ターン評価より複雑である。エージェントは何度もツールを呼び出し、環境状態を変えるため、最終結果だけでなく過程と環境変化も一緒に検査しなければならない。自動評価の核心は、入力を与え、出力または変更された状態に採点ロジックを適用することである。([人類学的][5])

検証器の優先順位

  • 決定的検証： コンパイル、単体テスト、スキーマ、数学的制約、権限検査
  • 参照ベース検証： 基準データ、原文引用、データベース照合
  • ルールベース検証： 禁止語、必須フィールド、ポリシー条件
  • モデルベース評価： 文体、意味保存、総合品質のようにルール化が難しい項目
  • 人間評価： 高リスク判断、目標そのものの妥当性、例外承認

可能であれば決定的検証を先に使用し、モデル評価だけで自分の結果を自分で採点させない。モデル評価を使うときは、評価基準、例、バイアス点検、サンプルの人間レビューを一緒に置く。

5つの方式はレイヤーであり代替材ではない

実際のシステムでは、5つの方式が一緒に作動する。

  • プロンプトは現在の行動の契約を作る。
  • コンテキストは判断に必要な状態と根拠を提供する。
  • ハーネスは行動可能な環境と安全装置を提供する。
  • エージェンティック設計は次の行動の選択権を配分する。
  • ループ設計はエラーを発見し品質を収束させる。

したがって、「コンテキストエンジニアリングがプロンプトエンジニアリングを置き換えた」あるいは「エージェントを使えばワークフローは不要だ」という理解は不正確である。より広いレイヤーが狭いレイヤーを含む、または活用するだけであり、単純な問題には単純な設計のほうが安定的である場合がある。

実務例：バグを修正するAIコーディングシステム

「ログイン後、特定のユーザーだけ500エラーが発生する」というバグをAIが修正すると仮定してみよう。

プロンプトエンジニアリング

  • エラー再現条件を確認せよ。
  • 公開APIは変更するな。
  • 最小修正で解決せよ。
  • 修正後、テスト結果と残るリスクを報告せよ。

コンテキストエンジニアリング

  • イシュー説明とエラーログ
  • 関連リクエストトレースID
  • 認証・ユーザーモデル関連ファイル
  • 最近の変更履歴
  • アーキテクチャルールとコーディング標準
  • 失敗したテストと実行環境情報

ハーネスエンジニアリング

  • リポジトリ検索、ファイル読み取り・編集、テスト実行ツール
  • 隔離されたブランチとサンドボックス
  • フォーマッター、リンター、単体・統合テスト
  • 変更禁止領域と権限ポリシー
  • すべてのコマンドとファイル変更のログ
  • 失敗時のロールバックとチェックポイント

エージェンティックエンジニアリング

AIが再現、仮説立案、関連コード探索、パッチ、テスト、結果要約の順序を状況に応じて選択する。ただし、デプロイやデータ変更は人間の承認を要求する。

ループエンジニアリング

テストが失敗したら、同じコマンドを繰り返す代わりに失敗タイプを分類する。再現失敗ならコンテキスト収集を補完し、回帰失敗ならパッチを小さくし、環境エラーなら依存関係と設定を復旧する。すべての必須テストが通過し、変更根拠が残れば終了する。

問題の症状から、どのエンジニアリングが必要かを見つける方法

症状 優先的に点検する領域
出力形式や文体が頻繁にずれる プロンプト
回答に必要な事実・ファイルが抜ける コンテキスト
ツールを誤って選んだり危険なコマンドを実行したりする ハーネスと権限設計
固定順序では処理しにくい変形が多い エージェンティック設計
最初の結果はよく間違うが自動判定は可能 ループと評価器
失敗原因が分からず再現が難しい ハーネスの観測性
繰り返すほどコストだけが増え品質が改善しない 原因分類、検証信号、終了条件
資料が多いほどむしろ答えが悪くなる コンテキスト整理と検索ポリシー

推奨構築順序

1段階：成功基準と評価セットを先に作る

代表業務、難しい事例、禁止事例を集め、結果をどう判定するか定義する。正解データがなければ、少なくともスキーマ、必須根拠、ポリシー遵守、人間評価基準を作る。

2段階：単一呼び出しの基準線を作る

最も単純なプロンプトと必要最小限のコンテキストで、性能、コスト、遅延時間を測定する。基準線なしにエージェントを導入すると、複雑性の効果を区別しにくい。

3段階：コンテキスト供給を計測する

どの文書とツール結果が入ったのか、どれくらい古いのか、実際の回答に使われたのかを記録する。検索失敗と過度なコンテキストを区別する。

4段階：最小ハーネスを作る

ツール数を減らし、名前と入力を明確にする。サンドボックス、最小権限、自動テスト、ログ、チェックポイントを優先する。

5段階：制限された自律性を付与する

単一エージェントに、読み取り中心の低リスク業務から実行させる。終了条件と人間への引き継ぎ条件を明示し、書き込み・削除・決済・デプロイ権限は別途承認する。

6段階：検証・復旧ループを閉じる

失敗分類、修正戦略、最大反復回数、コスト上限、回帰テストをつなぐ。成功率が安定してからのみ、ツールと自律範囲を広げる。

運用指標

普遍的な目標値はないため、業務リスクとコストに合わせて基準を定めなければならない。

指標 意味
タスク完了率 最終成功基準を満たした比率
一次通過率 反復修正なしに最初から通過した比率
復旧率 最初の失敗後、ループを通じて成功した比率
平均反復回数 成功または中断までに必要なサイクル数
ツール選択エラー率 不適切または不要なツール呼び出しの比率
根拠完全性 核心的な主張に追跡可能な出典がある比率
人間介入率 承認、修正、再指示が必要だった比率
単位成功あたりのコスト・遅延 成功したタスク1つを完了するのに使った資源
安全インシデント数 権限違反、誤った書き込み、不可逆行動の発生数
回帰失敗率 新しい変更が既存の成功事例を壊した比率

よく発生する設計ミス

領域 ミス 改善方法
プロンプト すべての例外を1文に積み重ねる ルールを構造化し、代表例と評価を分離する
プロンプト 成功基準なしに「うまく作成せよ」と指示する 形式、必須内容、禁止事項、判定基準を明示する
コンテキスト 関係ない文書をすべて入れる ランタイム検索と段階別コンテキストを使う
コンテキスト 古いポリシーと最新ポリシーを一緒に提供する バージョン・有効日・基準原本を管理する
ハーネス 機能が重複するツールを多く提供する 最小ツールセットと明確なパラメータを設計する
ハーネス 書き込み権限と戻す機能がない 最小権限、サンドボックス、チェックポイントを置く
エージェンティック 最初からマルチエージェントを作る 単一エージェントと決定的ワークフローから検証する
エージェンティック 完了条件なしに実行し続けさせる 明示的な終了・予算・引き継ぎ条件を置く
ループ 同じ要求をそのまま繰り返す 失敗原因を分類し、修正箇所を変える
ループ 生成モデル1つですべての結果を自己評価する 決定的検査、参照照合、人間によるサンプルレビューを組み合わせる

実装チェックリスト

  • 成功条件は文章だけでなく、可能な範囲で機械的に検査可能か？
  • プロンプト、参考資料、ツール結果の優先順位が分離されているか？
  • 文書の出典、バージョン、有効日と所有者を追跡できるか？
  • ツール名とパラメータが互いに重複せず明確か？
  • 読み取り、書き込み、削除、決済、デプロイ権限がリスク別に分離されているか？
  • 失敗を隔離するサンドボックスと戻す手段があるか？
  • すべての重要な行動とツール呼び出しを再現可能な形で記録しているか？
  • テスト、スキーマ、ポリシー検査などの外部検証器があるか？
  • 最大反復回数、コスト、時間、人間への引き継ぎ条件が定義されているか？
  • 新しい改善が既存事例を壊さない回帰評価があるか？

結論

良いAIシステムは、最も長いプロンプトを持つシステムではない。失敗が指示、情報、環境、意思決定、検証・復旧のどこで発生したのかを区別し、そのレイヤーに最も単純な解決策を配置したシステムである。まず成功基準と単一呼び出しの基準線を作り、必要な分だけコンテキストとハーネスを補強したうえで、検証可能な範囲で自律性と反復ループを拡張することが安定したアプローチである。