生成AIの設計はどう変わった？Prompt・Context・Harness・Loop・Graph Engineeringを整理

生成AIを用いたシステム開発において「プロンプトエンジニアリング」以外にも、コンテキスト/ハーネス/ループ/グラフエンジニアリングといった言葉を耳にするようになりました。

5つは競合する概念ではないと考えています。

AIに任せる仕事が一度の回答生成から、ツールを使った作業、完了までの反復、複数の処理の連携へと広がるにつれて、設計対象も段階的に増えてきたことを捉えるために新しい言葉が使われており、

５つの違いを理解する意味は、用語を覚えることだけではありません。

中身を理解することでAIの出力に問題が起きたとき、どのレイヤーを修正すべきか判断できるようになります。

しっかり理解していないと必要な情報が不足しているのにプロンプトだけを書き換えても、問題は解決しません。

また、完了判定が設計されていないのに「最後まで実行して」と指示しても、AIが本当にタスクを完了したかは保証できません。

この記事では、5つのエンジニアリングの意味と違いを、作業単位の広がりに沿って整理します。

そのうえで、それぞれがどのような関係にあるのか、グラフエンジニアリングによってどのような課題が生まれるのかを解説します。

1. プロンプト/コンテキスト/ハーネス/ループ/グラフエンジニアリングの違い

新しい言葉が登場するたびに、それまでの考え方が古くなったように見えるかもしれません。

しかし、これらは互いに置き換わる概念ではありません。

AIに任せる作業が複雑になるにつれて、設計する範囲が一段ずつ広がったものとして捉えると、違いが分かりやすくなります。

たとえば、AIに記事を作らせる場合を考えてみます。

「あるターゲット向けに、生成AIの記事を書いてください」と作業内容を指示するのが、プロンプトエンジニアリングです。

過去の記事、想定読者、検索キーワード、社内の文章ルールなどをAIに渡すのが、コンテキストエンジニアリングです。

検索ツールや社内データベースを接続し、文字数の計測や事実確認を実行できる環境を整えるのが、ハーネスエンジニアリングです。

記事を評価し、設計した基準を満たしていなければ修正を繰り返す仕組みを設計するのが、ループエンジニアリングです。

リサーチ、構成作成、執筆、SEO評価、事実確認といった複数の処理をつなぎ、結果に応じて次の処理を切り替えるのが、グラフエンジニアリングです。

5つの違いは、「一つの作業単位をどこまで広く捉えるか」にあります。

プロンプトエンジニアリングが扱うのは、一度のモデル入力です。

コンテキストエンジニアリングは、その入力時にモデルへ渡す情報全体まで扱います。

ハーネスエンジニアリングでは、モデルの外側にあるツール、テスト、評価、実行環境まで設計対象が広がります。

ループエンジニアリングでは、その処理を完了まで繰り返す仕組みを設計します。

グラフエンジニアリングでは、複数の処理やループをどのようにつなぎ、分岐させ、並列に動かすかを扱います。

関係を簡潔に表すと、次のようになります。

プロンプトは何を伝えるか、コンテキストは何を覚えさせるか、ハーネスはどう作業させるか、ループはいつまで続けるか、グラフは次に何を動かすかを設計する。

この違いを理解すると、AIの出力に問題があったとき、どこを修正すべきかも切り分けやすくなります。

• 指示の解釈がずれているなら、プロンプトを見直します。
• 必要な情報を参照できていないなら、コンテキストを見直します。
• ツールを使えない、結果を検証できないといった問題なら、ハーネスを見直します。
• 完了前に止まる、同じ失敗を繰り返す場合は、ループの設計を確認します。
• 問題に応じて適切な処理へ戻れない場合は、グラフの分岐やルーティングに原因があります。

プロンプトは最も簡単に編集できるため、AIの失敗はプロンプトの問題として処理されがちです。

実際には、原因がプロンプトより外側のレイヤーにある場合、指示文を何度書き換えても改善しません。

5つのエンジニアリングは、AIシステムの規模を説明する分類であると同時に、問題が起きた場所を特定するための視点でもあります。

2. 各エンジニアリングの特徴

プロンプトエンジニアリングは「指示」を設計する

プロンプトエンジニアリングは、生成AIにどのような指示を与えれば、期待する出力を安定して得られるかを設計する考え方です。

単に「詳しく書いて」「分かりやすくして」と指示するのではなく、目的、想定読者、役割、制約条件、出力形式、評価基準、具体例などを整理してモデルに伝えます。

期待した出力が得られなければ、指示の曖昧さや不足している条件を特定し、改善します。

基本的に設計対象となるのは、一回のモデル入力です。

つまり、AIに「何を、どのようにしてほしいのか」を適切に伝えるための設計が、プロンプトエンジニアリングです。

例：

曖昧な指示：
生成AIの記事を書いてください

設計した指示：
製造業のDX責任者向けに、以下の内容を定義
ペルソナ設計
・DX担当者が抱える課題
・課題の解決
構成：
・結論、文字数、見出し構成、避ける表現

コンテキストエンジニアリングは「判断材料」を設計する

AIが適切な判断をするには、指示だけでなく、その判断に必要な情報も与える必要があります。

コンテキストエンジニアリングは、モデルに何を渡し、何を残し、何を捨てるかを設計する考え方です。

記事制作であれば、過去の記事、想定読者、検索キーワード、取材内容、商品情報、文章ルールなどがコンテキストになります。

ただし、利用できる情報をすべて渡せばよいわけではありません。

不要な情報が増えれば、モデルが本来参照すべき情報を見失ったり、コンテキストウィンドウを圧迫したりします。

そのため、必要な情報は残し、大きな情報は要約し、現在の作業に関係しない情報は除外します。

プロンプトが「何をしてほしいか」の設計なら、コンテキストは「何を知った状態で考えさせるか」の設計です。

ハーネスエンジニアリングは「作業環境」を設計する

モデル単体でできることは、基本的には与えられた情報をもとに出力を生成することです。

実際の業務を任せるには、情報を取得したり、ファイルを操作したり、結果を検証したりできる環境が必要になります。

ハーネスエンジニアリングは、モデル、ツール、データ、実行環境、評価機能などを組み合わせ、AIが一回の処理を成立させられる仕組みを設計する考え方です。

記事制作なら、Web検索や社内データベースから情報を取得し、記事を生成し、文字数や禁止表現をチェックし、その結果を記録するところまでが対象になります。

単にツールをAIへ接続するだけではありません。

どのツールを使えるのか、どの権限を与えるのか、結果をどう検証するのかまで含めて設計する点に特徴があります。

業務例：

仕様を取得する
↓
関連ファイルを探す
↓
モデルが修正する
↓
テストを実行する
↓
結果とエラーを返す

ループエンジニアリングは「完了までの反復」を設計する

一度の処理で、タスクが必ず完了するとは限りません。

記事を生成しても、文字数が不足していたり、事実確認で問題が見つかったりすれば、修正が必要です。

ループエンジニアリングは、一回の処理結果を評価し、再実行するのか、完了するのか、中断するのかを設計する考え方です。

たとえば「事実確認に問題があれば再調査する」「品質評価が80点未満なら修正する」「最大3回で終了する」といった条件を定義します。

ここで注意したいのは、モデルが「完了しました」と回答したことと、タスクが本当に完了したことは別だという点です。

成功条件、継続条件、中断条件をモデルの自己判断とは別に持つことで、開始から終了までの実行全体を制御します。

グラフエンジニアリングは「複数の処理の連携」を設計する

仕事が複雑になると、一つの処理を繰り返すだけでは足りなくなります。

記事制作でも、リサーチ、構成作成、執筆、SEO評価、事実確認、校正では、それぞれ役割も判断基準も異なります。

グラフエンジニアリングは、こうした複数の処理やループをノードとして分け、どの順番で動かすか、どこで分岐するか、何を並列で実行するか、どの情報を共有するかを設計する考え方です。

たとえば、事実確認で情報不足が見つかればリサーチへ戻し、文章品質だけに問題があれば執筆へ戻す、といったルーティングを設計します。

グラフはループを置き換えるものではありません。

個々のループを含む複数の処理を連携させ、ジョブ全体をどのように進めるかを制御する、より広い設計対象です。

業務例：

検索意図分析
↓
リサーチループ
↓
構成作成
↓
執筆ループ
↓
SEO評価 ──┐
事実確認 ─┼→ 最終校正 → 完了
文体評価 ─┘

評価結果によって戻り先を変えます。

情報不足 → リサーチへ戻る
構成不良 → 構成作成へ戻る
文章品質の問題 → 執筆へ戻る
重大な判断 → 人間へ引き継ぐ

5つのエンジニアリングはどのような関係にあるのか

5つのエンジニアリングは、どれか一つが新しい概念に置き換わっていく関係ではありません。AIに任せる仕事が複雑になるにつれて、設計する範囲が外側へ広がっていく関係として捉えると分かりやすくなります。

プロンプトエンジニアリングでは、一回の入力として「何をしてほしいか」を設計します。コンテキストエンジニアリングでは、その判断に必要な情報まで対象を広げます。ハーネスエンジニアリングでは、モデルに加えてツールや検証機能を含む一回の処理全体を設計します。ループエンジニアリングでは、その処理を再実行するか、完了するかを判断します。そしてグラフエンジニアリングでは、複数の処理やループのうち、次にどれを動かすかを設計します。

つまり、視点を外側へ広げるほど、設計対象も「入力」から「情報」「処理」「一連の実行」「ジョブ全体」へと大きくなります。

この関係を理解すると、AIの問題をすべてプロンプトの問題として扱わずに済みます。必要な情報が不足しているならコンテキスト、検証できないならハーネス、完了前に止まるならループ、誤った工程へ進むならグラフと、原因があるレイヤーを切り分けて改善できます。

Graph Engineeringで生まれる課題

グラフエンジニアリングでは、処理を細かく分割して連携できる一方、システム全体の複雑さも増します。

人間の認知が追いつかない

これは代表例です。複数の処理が並列で動き、分岐や再実行が発生すると、現在どこで何が起きているのか把握しにくくなります。実行履歴や分岐理由、状態の変化を記録し、人間が必要な情報だけ確認できる仕組みが必要です。

人間側にもハーネスが必要になる

すべてを監視するのではなく、重大な判断や例外だけを通知し、承認や介入を求める設計が求められます。

さらに、ノードを増やしすぎると、ルーティングミスや状態管理の複雑化、コスト増加につながります。単純な処理は無理に分割せず、責任や判断基準が異なる箇所だけをグラフ化することが対策になります。

Graph Engineeringを過剰設計にしないための考え方

グラフエンジニアリングでは、処理を細かく分ければよいわけではありません。ノードが増えるほど、情報の受け渡し、状態管理、分岐条件、エラー処理も増え、グラフを維持するためのコストが大きくなります。

そのため、最初から複雑なグラフを作るのではなく、まずは一つの処理やループで成立するかを確認することが基本です。そのうえで、役割や評価基準が異なる、異なる権限が必要、失敗したときの戻り先を分けたい、といった理由がある場合にノードを分割します。

また、すべてをAIエージェントに任せる必要もありません。文字数の計測や形式チェックなど、ルールで確実に処理できる部分は通常のプログラムに任せたほうが安定します。

グラフ化の目的は、エージェントやノードを増やすことではなく、複雑な仕事を制御しやすくすることです。分割によって制御性や検証可能性が高まる場合にだけ、グラフを広げるのがよいでしょう。

まとめ

プロンプト、コンテキスト、ハーネス、ループ、グラフの5つは、どれか一つが前の考え方を置き換えるものではありません。AIに任せる仕事が複雑になるにつれて、設計対象が「一つの入力」から「情報」「一度の処理」「完了までの実行」「ジョブ全体」へと広がっていったものと捉えられます。

この整理が役立つのは、AIの出力に問題が起きたときです。指示が曖昧ならプロンプト、必要な情報が足りないならコンテキスト、ツールや検証に問題があるならハーネス、完了判定が弱いならループ、処理の分岐や連携が適切でないならグラフを見直します。

AIシステムが複雑になるほど、すべての失敗をプロンプトの書き方だけで解決することは難しくなります。どのレイヤーに問題があるのかを切り分け、必要な範囲だけを設計することが、生成AIを安定して業務へ組み込むための出発点になります。