プロンプトエンジニアリングの進化とDifyでの実践

コンテキストからハーネスとループへ、そしてグラフへと広がるプロンプト設計の考え方

「プロンプトを何度も書き直したのに、回答が安定しない」「社内資料を読み込ませたが、別のグループ会社の規程で答えてしまう」「回答案はできても、確認や申請の作業が残る」。生成AIを実際の業務に組み込もうとすると、指示の書き方だけでは解決しにくい問題が見えてきます。

そこで必要になるのが、AIに渡す情報、仕事を進める手順、結果を確かめて修正する仕組みの設計です。本記事では、プロンプト、コンテキスト、ハーネス、ループという4つのエンジニアリング手法を整理し、さらにその先にあるグラフエンジニアリングも含めてDifyを使って企業の業務にどう落とし込めるかを解説します。

最初に押さえたいのは、プロンプト、コンテキスト、ハーネス、ループの4つが重なり合う考え方だということです。プロンプトが不要になったわけでも、すべての企業が順番に4段階を進むわけでもありません。AIに任せる仕事が広がるにつれて、設計する対象も広がってきた、と捉えると理解しやすくなります。

プロンプトからコンテキスト ハーネス ループへ

新しく配属された担当者に仕事を頼む場面を想像してみてください。依頼書を分かりやすくするだけでなく、必要な資料、使えるシステム、確認する手順も用意するはずです。AIでも、これらを組み合わせることで業務を進めやすくなります。

図1　AIに任せる仕事が広がると、設計する範囲も広がる。4つは重なり合う観点で、前の技術も引き続き使う。

プロンプトエンジニアリングは頼み方を整える

プロンプトエンジニアリングは、AIへの指示を分かりやすく設計することです。目的、役割、守ってほしい条件、出力形式、回答例などを具体的にします。「見積書を比較して」よりも、「価格・納期・保守範囲を表で比較し、不明な項目は不明と記載して」と伝える方が、期待する仕事を共有しやすくなります。

コンテキストエンジニアリングは判断材料をそろえる

コンテキストとは、AIがその時点の回答や判断で参照できる入力情報です。指示文に加え、社内規程、案件データ、会話履歴、ツールから取得した情報などが含まれます。コンテキストエンジニアリングでは、その都度必要な情報を選び、適切な形で渡します。

たとえるなら、担当者の机に、今回の案件に必要な資料を正しい版でそろえることです。資料を大量に渡すだけでは、古い情報や関係のない情報が混ざります。「何を渡すか」と同時に、「何を渡さないか」も考えます。

ハーネスエンジニアリングは仕事を進める仕組みを整える

ハーネスは、AIモデルの周りに置く実行の仕組みです。利用できるツール、処理の順序、権限、途中の状態、検証、記録、失敗時の対応などを含みます。

企業の業務に当てはめれば、資料を読む、数字を確認する、不備を担当者へ返す、承認された内容を登録する、といった一連の進め方を用意することです。「承認を得てから登録してください」と指示するだけでなく、承認されるまで登録処理に進めない仕組みを作ります。

ループエンジニアリングは確かめながら次の行動を進める

ループエンジニアリングは、目標に向けて仕事を進め、結果を確かめ、必要な次の行動を選び直す反復の仕組みを設計する考え方です。まだ用法が固まりきっていない言葉であり、本記事では、その考え方を企業の業務処理に応用します。

例えば、比較表を作った後に「保守費用が不足している」と分かったら、該当する資料を追加で確認して作り直します。必要な条件を満たせば終了し、解決できなければ担当者に戻します。繰り返す方法と、繰り返しを止める条件をセットで決めます。

同じ見積比較の仕事で4つの違いを見る

調達担当者が3社の見積書を比較し、購買申請案を作る仕事を例にすると、違いが具体的になります。以下は説明用の想定例です。

例えば、B社の見積金額が最も安くても、保守費用が別契約なら、総額で最安とは限りません。必要な資料を取得するのがコンテキストの設計、条件不足なら処理を止めるのがハーネスの設計、追加情報を得て比較し直すのがループの設計です。比較の目的や出力形式を伝えるプロンプトも、その中で使い続けます。

Difyで実践するコンテキストエンジニアリング

グループ会社ごとに規程が異なる出張費の問い合わせ

国内に複数の事業会社を持つ製造業で、出張費の問い合わせに答えるAIを考えます。社員からの質問は「来月、大阪へ出張します。1泊18,000円のホテルでも精算できますか」です。

この質問には、一般的な出張の知識だけでは答えられません。所属会社、出張日、適用される社員区分、地域ごとの上限、例外申請の条件を確認する必要があります。文章が自然でも、別会社の規程や出張日に適用されない版を参照していれば、業務には使えません。

図2　出張費の問い合わせに必要な情報をそろえる構成例。検索条件の設定と、本人確認・閲覧権限の管理は分けて設計する。

資料と利用者の情報を先に整える

規程には、対象会社、文書種別、版、施行日、有効期間、主管部署などを付けて管理します。検索で本文だけが切り出されても適用範囲が分かるようにし、上限金額の表と、その例外を定める条文を一緒に確認できる状態にします。

利用者の所属会社や閲覧権限は、ログイン済みの社内ポータルや認証APIから受け取る設計にします。質問欄に書かれた会社名を、そのまま本人の所属や権限の証明に使わないことが重要です。

Difyで検索から回答までを組み立てる

1. 質問から出張日、行き先、宿泊費などを整理し、足りない条件は聞き返す。

2. ナレッジ検索で、会社や文書種別などのメタデータを使って対象を絞る。必要に応じてRerankで関連する検索結果の順序を調整する。

3. 取得した候補が出張日に適用されるかを、Codeノードや外部APIで確認する。対象の条文や別表がそろわなければ、再取得するか主管部署へ回す。

4. LLMノードに根拠を渡し、結論、適用条件、例外、参照文書を整理して回答する。根拠がない場合や規程が競合する場合の案内先も決める。

Difyには、ナレッジ検索のメタデータ絞り込みや検索結果をLLMへ渡す機能があります。一方、日時型の動的な絞り込みなどは設定上の制約があるため、この例では適用日の確認を独立した処理にしています。利用する版とデータの持ち方に合わせて実装を選びます。

検索対象を絞る設定は、利用者ごとのアクセス権管理と同じではありません。文書管理システムの権限がDifyへ自動的に引き継がれると仮定せず、認証済みの利用者情報と照合し、許可された情報だけを検索・取得できるようにします。検索スコアの高さも、回答の正しさを保証するものとして扱わないようにします。

回答は結論と根拠と次の行動をそろえる

例えば、次のような回答を目指します。金額、規程名、施行日、条文はすべて説明用の架空例です。

A社の今回の出張に適用される宿泊費上限は、1泊16,000円です。18,000円の宿泊には、規程に定める事前の例外申請が必要です。申請の可否は承認者が判断します。
根拠：A社 国内出張旅費規程 第8条・別表2（2026年10月1日施行）
次の行動：出張申請画面で理由を記載し、上長に確認してください。

プロンプトには「取得した規程で確認できる内容だけを回答する」「条件が不足している場合は質問する」「根拠文書名と該当箇所を示す」といった方針を設定します。その指示を、検索条件、データ整備、適用日の検証で支えるのがコンテキストエンジニアリングです。

Difyで実践するハーネスエンジニアリング

調達見積もりの比較から購買申請案の作成まで

次は、調達部門が3社の見積書を比較し、社内の購買申請案を作成する例です。ここでは、AIに文章の読み取りや比較理由の整理を任せ、金額計算、登録条件、承認の確認はそれぞれの処理で管理します。

図3　調達業務を進めるハーネスの構成例。検証と修正のループの外側に、人による確認・承認と業務システムへの登録を置く。

Difyは、文書抽出、構造化出力、コードによる計算、条件分岐、外部APIの呼び出しを組み合わせられます。画像主体の見積書には別途OCRなどの読み取り処理を用意します。構造化出力はモデルの対応状況に左右され、項目の形が整っていても内容の正しさまでは保証しないため、元資料との照合も必要です。

不備があるときの行き先を決める

B社の保守費用が別契約なら、「比較表は作成できましたが、総額を同条件で比較できていません」と返します。別紙に費用が載っていれば再確認し、どの資料にも記載がなければ担当者へ確認を依頼します。不足額を推測で埋めて処理を進めないようにします。

また、「承認待ち」「差し戻し」「登録済み」を区別します。承認期限を過ぎた場合は保留や通知へ進め、承認済みとして扱わない設計にします。AIが仕事を止めたことが、適切な動作である場合もあるからです。

承認と登録は連携先でも確かめる

Human Inputノードを使うと、途中で処理を止め、人から確認結果や修正を受け取れます。ただし、それだけで企業の承認規程を満たすわけではありません。例えば公式ドキュメントのメール方式は、リンクを持つ人が応答できる仕様です。承認者の本人確認や職務権限、多段承認が必要なら、社内の認証・承認システムと組み合わせます。

登録先のAPIでも、承認者、対象案件、承認済みの内容、操作権限を確認します。承認後に金額や取引先が変わった場合は再承認とし、通信の再試行で同じ申請を二重登録しない仕組みも用意します。AIに自由な登録先を選ばせず、使える操作を限定することも設計の一部です。

案件IDを共通の手掛かりにして、入力資料、参照した版、検証結果、承認履歴、登録結果を結び付けると、後から処理を確認できます。これらはDifyのワークフローと、接続する業務システムを合わせて設計する内容です。

関連する考え方：Human in the LoopがいよいよDifyで可能に

ループエンジニアリングで検証と修正をつなぐ

ループエンジニアリングは、定期的に仕事を見つけて割り当てる仕組みまで含む広い考え方です。ここでは、Difyで取り組みやすい、一件の業務を完了させるための反復を取り上げます。

同じ依頼を繰り返すだけでは改善にならない

見積比較で、AIに「もう一度よく確認して」と何度伝えても、見ている資料と判定基準が同じなら、同じ誤りを繰り返す可能性があります。そこで、確認結果を次の行動につなげます。「B社の保守費が未取得」「C社の納期に根拠がない」のように、不足している箇所を特定してから、再検索や修正を行います。

DifyのLoopノードは、前回の結果や変数を引き継ぎながら処理を繰り返す部品です。終了条件、最大回数、途中で抜ける処理を設定できます。一方、Iterationは、複数の見積書など配列の各要素に処理を適用するときの部品で、両者は役割が異なります。

「最大3回」は設計例であり、推奨やDifyの仕様ではありません。費用や時間の上限も、変数の検査や外部の実行管理で具体化します。保守費用が元資料に存在しなければ、何回繰り返しても確認できないため、人に戻す判断が必要です。

検証を別のLLMに担当させる場合も、その判定を無条件に正解とは扱いません。計算や必須項目はプログラムで確かめ、意味の解釈や例外判断は元資料と人の判断を組み合わせて確認します。

一件の処理を回す仕組みと運用を改善する仕組みを分ける

ここまでのループは、一つの仕事を完了させるための反復です。これとは別に、運用側にも改善のサイクルを設けます。失敗例を調べ、原因が検索、規程の更新漏れ、計算、承認手順のどこにあるかを分類し、担当者が修正します。

Difyのログは、回答やワークフローの実行状況を確認する材料になります。ただし、ログを保存するだけで正解判定や改善が自動で進むわけではありません。通常の質問、例外、情報不足、回答すべきでないケースを評価用に用意し、変更前後を同じ条件で比べます。使うモデルやナレッジ、ワークフローの版も記録しておきます。

利用履歴をそのままナレッジに追加すると、誤回答まで再利用するおそれがあります。担当者が確認した知見だけを更新し、効果を検証して反映します。この運用改善は、利用するだけで基盤モデルが自動的に再学習されるという意味ではありません。

グラフエンジニアリングで仕事同士のつながりを設計する

ループを含めて業務全体を組み立てる

ループで検証と修正を繰り返せるようになると、次は「どの仕事を分担し、どの結果を待って、次へ進むか」が課題になります。このつながりを明示的に設計する観点が、グラフエンジニアリングです。

ここでいうグラフは、処理を表す点（ノード）と、処理同士の関係を表す線（エッジ）で仕事の構造を表したものです。処理の順番や分岐に加えて、途中で引き継ぐ情報や確認状況も設計します。ノードには、LLM、検索、計算、API呼び出し、内部にループを持つエージェントなどを置けます。

グラフの中にはループも含められます。グラフエンジニアリングは、プロンプト、コンテキスト、ハーネス、ループを組み合わせ、業務全体の関係を設計する考え方として捉えるとよいでしょう。

調達業務を複数の観点で確認する

先ほどの見積比較を広げてみます。大企業の調達では、金額だけでなく、必要な仕様を満たすか、契約条件に確認すべき点がないかも判断します。これらを役割ごとに分け、独立して確認できる部分を並列に進める設計が考えられます。

図4　仕事の分担、結果の合流、再確認、人の承認をつなぐ設計例。戻り矢印は業務上の関係を示し、DifyではLoopと条件分岐などで実装する。

例えば、価格の確認では「保守込み」と判断した一方、契約条件の確認では「保守は有償オプション」と読み取った場合、そのまま申請案を確定できません。根拠を突き合わせ、該当する確認に戻すか、担当者へ引き継ぎます。複数の回答を集めた後に、矛盾を見つける処理が必要です。

また、仕様の確定が見積金額を計算する前提なら、その部分は順番に進めます。見積書や仕様書の版が変わったら、影響を受ける確認結果を更新し、古い結果を承認に使わないようにします。並列化できる箇所と、先の結果を待つ箇所を見分けることが設計の要点です。

Difyで分岐と合流を実装する

Difyのワークフローは、ノードをつないで直列・並列の処理を組めるため、この考え方を実践する入口になります。並列の枝は実行中に互いの変数を参照できませんが、合流後の処理は各枝の結果を参照できます。案件IDや資料の版を最初にそろえ、各枝から確認状況、根拠、未解決事項を返す設計にします。

結果をまとめる際には、使う部品を区別します。Variable Aggregatorは、If-Elseなどで一つだけ実行された枝の出力をそろえるためのノードです。複数の枝を並列に動かした結果をまとめる場合は、CodeやTemplateを使います。この例ではCodeで必要な結果がそろったかを確かめ、未確認事項が残る場合は承認へ進めないようにします。

再確認はLoopと条件分岐で組み、前章で決めた上限と停止条件を引き継ぎます。共通する確認処理は、User Inputで始まる別のWorkflowにまとめ、Toolとして再利用することもできます。承認や登録を含めた状態の保存、操作権限の確認は、接続する業務システムと合わせて設計します。

なお、この章のグラフは、仕事や判断のつながりを扱っています。文書から抽出した知識や関係を検索・回答に使うGraphRAGとは設計する対象が異なります。GraphRAGを検索部分に組み込むことはできますが、グラフエンジニアリングの必須条件ではありません。

AIを増やす前に引き継ぎを設計する

大企業での価値は、担当するAIを増やすことよりも、部門をまたぐ仕事のつながりを明確にできる点にあります。「どこまで確認したか」「何が未解決か」「誰が次に判断するか」を受け渡すことで、途中の確認漏れや手戻りを減らす設計ができます。

一方で、処理を細かく分けるほど、呼び出し回数、待ち合わせ、結果の統合、保守する接続が増えます。Google Researchの比較研究でも、複数エージェントによる効果は、仕事を並列に分けられるか、前の判断への依存が強いかによって変わると報告されています。

そこでOmlucとして重視したいのは、実際の業務で役割を分ける効果がある部分を見極めることです。まず一つの業務で、正しく完了できた割合、人の確認時間、処理時間、1件当たりの費用を比較します。その結果を基に、分ける処理、まとめる処理、人が判断する箇所を調整する。この積み重ねが、現場で使い続けられるAIの仕組みにつながると考えます。

自社ではどこから手を付けるか

最初から大きな自律型エージェントを作る必要はありません。困っている業務を一つ選び、失敗の原因に合う部分から整えます。

業務部門は正しい結果と例外条件を決め、AI推進部門は評価方法や共通の作り方を整え、IT部門は認証・権限・システム接続を担う。こうした分担を決めると、問題が起きたときに誰が何を直すかが明確になります。

効果は、回答の正しさに加え、根拠の妥当性、必要なときに保留できたか、人が確認・修正した時間、申請まで含めた完了時間、1件当たりの費用で見ます。回答が速くても、後工程の確認が増えれば、業務全体の負担は減りません。処理を始める前に、何が改善すれば成功なのかを決めておきましょう。

全社展開の役割分担については、CoE組織の重要性と役割について考えてみたでも解説しています。

よくある質問

プロンプトエンジニアリングは不要になりますか

引き続き必要です。検索した資料をどう使うか、何を出力するか、分からない場合にどう答えるかを伝える役割があります。その指示が機能するように、情報と実行の仕組みも合わせて整えます。

RAGとコンテキストエンジニアリングは同じですか

RAGは、必要な情報を検索して生成AIに渡す方法です。コンテキストエンジニアリングでは、検索する資料の範囲や版、会話履歴、システムから取得するデータ、渡すタイミングなど、AIが使う情報全体を設計します。RAGはそのための有力な手段です。

Difyだけですべて実装できますか

検索、生成、分岐、反復、人の入力、API連携などはDifyを中心に構成できます。一方、社員ごとの認証・認可、厳格な承認、二重登録防止、監査記録の保管などは、既存の社内システムと合わせて設計します。ノード名や設定、利用可能な機能は、バージョン・提供形態・プランによって異なります。

Difyを業務に組み込む設計をOmlucに相談する

「プロンプトを直しても回答が安定しない」「社内資料を使わせたいが、最新版や閲覧権限の扱いに迷う」「AIが作った案を、確認・承認まで含めて業務につなげたい」。こうした課題は、参照する情報と仕事の進め方を一緒に整理すると、改善すべき場所が見えてきます。

Omlucでは、Difyの環境構築、業務に合わせたワークフローの開発、研修、保守運用を支援しています。現在の取り組みと、AIで改善したい業務についてお聞かせください。

Difyの業務活用についてOmlucに相談する

OmlucのDify導入支援サービスを見る