AIエージェントを動かす4つの設計。プロンプト、コンテキスト、ハーネス、ループの違い

AIの回答が期待と違ったとき、最初に直したくなるのはプロンプトです。
指示を詳しくし、禁止事項を足し、出力例を増やせば、一回の回答は改善することがあります。

しかし、AIに渡していない資料は、プロンプトを長くしても読ませられません。
テストを実行する仕組みがなければ、「必ずテストして」と書いても完了を保証できません。
一回の作業が終わったあと、次に何をするか決める仕組みがなければ、人間がプロンプトを送り続けることになります。

本サイトでは、AIを実務で動かすための設計を4つに分けて考えます。
プロンプト、コンテキスト、ハーネス、ループという4つのAIエンジニアリングです。
これは業界全体で定まった標準的な分類ではありません。
問題が起きた場所を見つけ、どの設計を直すべきか判断するための実務上の整理です。

この記事を読むと、目の前の問題に応じて、次に読むべきクラスター記事を選べるようになります。

失敗するたびにプロンプトを足していた

僕も以前は、AIが失敗するたびに注意書きを増やしていました。
形式が崩れたら出力例を足し、古い情報を使ったら「最新情報を優先」と書き、テストを飛ばしたら「必ず確認」と追記します。
ところが、同じ注意が別の仕事では効かず、プロンプトだけが長くなりました。

原因は、異なる種類の失敗をすべて「頼み方の問題」として扱っていたことです。
依頼の意味が曖昧なことと、判断材料が不足していることは別の問題です。
必要なツールを使えないことと、実行結果を受けて次の行動を選べないことも別の問題です。

直す場所を間違えると、仕組みの不足を文章で補おうとしたり、曖昧な依頼をツールで補おうとしたりします。
まず、実際に起きた問題が、4つのAIエンジニアリングのどれに当たるかを見極めます。

4つのAIエンジニアリングは直す場所が違う

この4つは、初級から上級へ進む階段ではありません。
同じ仕事の中でも、それぞれ設計するものが違います。

プロンプトエンジニアリングは、一回の依頼で達成してほしい目的、守る制約、返してほしい形式を記述します。

コンテキストエンジニアリングは、その判断に必要な資料、履歴、状態を、必要な時点で利用できるようにします。

ハーネスエンジニアリングは、モデルの外側にツール、権限、機械による検証、実行ログ、復旧方法を用意します。
これにより、一回の作業が正しく終わったか確認できるようになります。

ループエンジニアリングは、一回の実行結果をもとに、続行、方針変更、停止、人間への引き渡しを選びます。

4つは役割が分かれていますが、一つの仕事の中でつながっています。
プロンプトで求める成果を決め、コンテキストにある情報から作ります。
ハーネスで実行と検証を行います。
その結果をもとに、ループが次の行動を決めます。

競合調査を4つの設計に分ける

毎週、競合サービスの発表を調べ、先週からの変化をレポートへ追記する仕事を考えます。
人間なら、依頼の意味を確認し、調査先を開き、根拠を残し、見つからない情報を再調査します。
更新が終わったら、次週に必要な情報を引き継ぎます。
AIエージェントへ任せる場合も、この仕事を一つの長い指示に押し込む必要はありません。

ここで、毎週月曜に起動するスケジュールはループそのものではありません。
スケジュールは開始のきっかけです。
取得した結果に応じて次の行動を変え、終了か引き継ぎを判断する部分がループです。

同様に、「必ず引用URLを付ける」と依頼文へ書くことと、URLが実在するか機械で検査することも違います。
前者はプロンプトであり、後者はハーネスです。

今起きている問題から次に読む記事を選ぶ

用語から選ぶより、実際に起きている問題から選ぶ方が迷いません。

複数の問題が同時に起きることもあります。
その場合は、作業の流れで最初に起きた問題から直します。

例えば、依頼の意味を取り違えたまま反復を自動化しても、誤った作業を速く繰り返すだけです。
一方で、依頼を正しく理解しているのにテストを実行できないなら、プロンプトの推敲よりハーネスを先に直します。

依頼の解釈がずれるならプロンプトを直す

プロンプトでは、一回の仕事の仕様を決めます。
目的、入力、制約、出力形式、成功条件が曖昧なら、モデルは不足した部分を推測します。

「競合を詳しく調べて」という依頼では、競合の範囲、詳しさの基準、調査期間、納品形式が決まりません。
この状態では、検索ツールや長期メモリを増やしても、何を合格とするかは曖昧なままです。

プロンプトを直す目安は、入力が同じなのに依頼の解釈が変わることです。
出力形式を指定することと、内容の合格条件を指定することも分けます。
JSONで返ってきても、調査結果が正しいとは限らないからです。

プロンプトエンジニアリングでは、短いお願いを入力仕様へ変える7要素、例示の使い分け、評価セットによる改善まで解説しています。

根拠や前提がずれるならコンテキストを直す

依頼を正しく理解していても、必要な資料が見えていなければ、業務固有の根拠に基づく判断はできません。
逆に、資料をすべて詰め込めば解決するわけでもありません。
古い版、無関係なログ、重複した文章が混ざると、モデルが注目すべき情報を選びにくくなるためです。

コンテキストでは、何を記録し、何を選び、何を圧縮し、いつ取り出すかを決めます。
RAG、ファイル検索、会話履歴、長期メモリは、そのために使う手段です。

手段を導入しただけでは、情報の鮮度、出典、優先順位までは決まりません。
「最新情報を使って」と書いても、最新情報を取得できなければプロンプトだけでは直せません。

コンテキストエンジニアリングでは、注意予算としてのコンテキスト、RAGとメモリの役割、段階的な情報取得、鮮度と出典の管理まで扱っています。

実行結果を確認できないならハーネスを直す

モデルが正しい方法を答えられても、実際の作業を安全に終えられるとは限りません。
ファイルを変更し、外部サービスへ書き込み、テストを実行する仕事には、モデルの外側の仕組みが必要です。

ハーネスでは、利用できるツール、操作できる範囲、品質ゲート、実行ログ、チェックポイント、復旧方法を決めます。

「テストしてから完了と報告する」とプロンプトへ書くことは、期待する行動を伝えるうえで役立ちます。
ただし、テストが成功しなければ完了と判定しない仕組みは、ハーネスで実装します。

プロンプトとハーネスの役割を分けると、同じ注意を会話へ貼り直す仕事を減らせます。
プロンプトは期待する行動を伝え、権限と検証の仕組みは実際の操作を制限します。

ハーネスエンジニアリングでは、実行契約、ツールと権限、機械検証、失敗からの再開、人間の確認へ切り替える条件を具体例から説明しています。

次の指示待ちになる仕事にはループを設計する

一回の実行が検証できても、その結果から次の行動を決められなければ、継続する仕事は人間の指示待ちになります。
ループでは、目標、現在の状態、実行結果、評価、次の行動、停止条件をつなげます。

失敗したら同じ処理を繰り返すだけのリトライとは異なります。
前回の結果に応じて、再実行するか、方針を変えるか、止めるかを選ぶ必要があります。

市場調査のような定期業務では、全体が永久に完了するわけではありません。
各回を終了し、次回が再開できる状態まで進めることが、その回の停止条件になります。
ループを作る前に、無限実行を防ぐ予算と、人間へ判断を戻す条件も決めます。

ループエンジニアリングでは、リトライや固定ワークフローとの違い、評価後の再計画、停止条件、状態の引き継ぎまで解説しています。

一つの機能を4つのAIエンジニアリングで考える

実務では、一つの機能に複数のAIエンジニアリングが関わります。
「どれか一つが担当する」と決めず、誰が何を決めるかに分けると設計しやすくなります。

例えば、長期メモリを「コンテキストの機能」とだけ考えると、保存権限や更新タイミングが抜けます。
反対に、保存用データベースを作っただけでは、何を残し、次回に何を読ませるかは決まりません。
この分類は、設計から抜けている役割を見つけるために使います。

4つのAIエンジニアリングを全部そろえる必要はない

単発の文章作成なら、プロンプトとコンテキストだけで足りることがあります。
AIがファイルや外部サービスを変更するなら、権限と検証を持つハーネスが必要になります。
検証済みの実行を複数回つなぐなら、状態と停止条件を持つループを追加します。

仕事を高度に見せるために4つをそろえるのではありません。
モデルへ渡す責任が増えたとき、その責任を制御できる設計を加えます。

設計を始めるときは、次の順に現状を書き出します。

1. 実際に何が失敗したか。
2. その失敗は、依頼、情報、実行環境、継続の仕組みのどこで起きたか。
3. 改善したと判断できる結果は何か。
4. その結果を誰が、どの仕組みで確認するか。

この4問へ答えると、「とりあえずプロンプトを長くする」状態から離れられます。

よくある質問

プロンプトエンジニアリングは古くなったのですか

古くなったわけではありません。
一回の依頼の目的、制約、出力、成功条件を伝える役割は残ります。
ただし、情報取得、権限、検証、反復までは、プロンプトだけでは担えません。

コンテキストエンジニアリングはプロンプトエンジニアリングを含みますか

モデルが応答時に読むトークン全体をコンテキストと呼ぶ定義では、プロンプトもコンテキストに含まれます。
本サイトでは設計責任を明確にするため、依頼文の設計をプロンプト、作業中に見せる情報の選択と維持をコンテキストとして分けています。

ハーネスエンジニアリングはコーディングエージェントだけの技術ですか

コーディング以外にも使えます。
ブラウザ操作、データ収集、文書更新、問い合わせ処理など、モデルが外部のデータやサービスを操作し、その結果を確かめる仕事が対象です。

ループエンジニアリングは自動化やスケジュール実行と同じですか

同じではありません。
自動化やスケジュール実行は、決められた処理を開始できます。
ループは、前回の結果に応じて次の行動や停止の判断を変える仕組みまで扱います。

すべてのAI活用に4つのAIエンジニアリングが必要ですか

必要ありません。
単発の相談ではプロンプトだけで足りる場合もあり、参照資料が増えればコンテキストが必要になります。
外部操作と継続実行を任せる段階で、ハーネスとループの必要性が高まります。

どのAIエンジニアリングから改善すればよいですか

現在繰り返している失敗から選びます。
依頼の解釈、判断材料、作業結果の確認、次の行動のどこで止まっているかを確認し、主な原因を受け持つ設計から直します。

今起きている失敗を一文で書く

まず、今起きている失敗を一文で書きます。
「同じ入力なのに形式が変わる」「古い資料を優先する」「テストせず完了と報告する」「一回ごとに人間の指示を待つ」のように、実際に起きていることを書き出します。

依頼の問題なら、プロンプトを作業仕様へ変える方法から始めてください。

情報の問題なら、AIへ何を読ませ、何を省くかを確認します。

実行と検証の問題なら、モデル外部の作業環境を設計する方法へ進みます。

継続と停止の問題なら、結果から次の行動を決める方法が入口です。

自社の業務を4つのAIエンジニアリングに分け、AIエージェントの実行設計まで落とし込みたい場合は、お問い合わせからご相談ください。

情報元

• OpenAI：Prompt engineering
• Anthropic：Effective context engineering for AI agents
• OpenAI：Harness engineering
• Addy Osmani：Loop engineering

更新履歴

• 2026年7月18日：初版公開