AI活用ナビゲーターの ワケハト です。AIエンジニアリングは、良いプロンプトを書くことだけではありません。業務で使うには、AIに何を判断させるか、どう仕事を進めさせるか、どう安全に改善するかまでを一つのシステムとして考えます。
ただし、用語を全部覚えてから始める必要はありません。この回では、増え続ける用語を3層の地図に置き、自分の仕事に必要な最小構成を選べる状態を目指します。
まず、なぜ迷子になるのか
Prompt、Context、RAG、Memory、Tool、Workflow、Agent、Loop、Graph、Multi-Agent、Harness、Evaluation……。
これらを一列に並べると、「次はAgent、その次はMulti-Agentへ進化しなければ」と見えます。しかし実際には、競争する製品名でも、上に行くほど偉いレベル表でもありません。違う問題を解くための設計部品です。
たとえば社内規定への質問に答えるだけなら、RAGと引用確認で十分かもしれません。メール送信まで任せるなら、Toolの権限、送信前承認、実行記録が必要です。同じAIでも、仕事が変われば必要な部品が変わります。
全体像は3層で見る
この3層は、特定企業や標準化団体が定めた分類ではありません。公開されている設計パターンを、初心者が役割の違いをつかめるようにこの連載で整理した見取り図です。
| 層 | 答える問い | 主な設計要素 |
|---|---|---|
| 1. 判断品質 | AIは何を見て、どう答えるか | Prompt、Context、RAG、Memory、Model |
| 2. 実行構造 | AIはどの手順で、どこまで動くか | Tool、Workflow、Agent、Loop、Graph |
| 3. 運用品質 | どう測り、守り、改善するか | Harness、Evaluation、Trace、Guardrail、人間確認 |
3層は独立していません。Loopには合格条件が要り、合格条件はEvaluationに属します。Agentが外部システムを操作するなら、ToolだけでなくGuardrailと人間承認も要ります。
ポイント: 「どの技術を導入するか」より先に、「判断・実行・運用のどこが今のボトルネックか」を決めます。
1. 判断品質：何を理解し、何を根拠に答えるか
Promptは「依頼の設計」
Prompt Engineeringは、目的、前提、制約、入力、出力形式、評価基準を言葉にする仕事です。
目的 + 前提 + 制約 + 入力 + 出力形式 + 評価基準
一度の入力に一度の回答で終わる要約、分類、文章作成なら、まずPromptから試せます。
Contextは「判断材料の編集」
Context Engineeringは、何を、いつ、どの順番でAIへ渡すかを設計します。案件の前提、過去の会話、検索結果、ツール結果、失敗履歴もContextです。
情報は多ければよいわけではありません。古い資料と新しい資料が混ざれば判断を誤り、長すぎれば重要な条件が埋もれます。必要な情報を選び、圧縮し、更新するところまでが設計です。
RAGは検索、Memoryは再利用
混同しやすい2つを分けます。
| 要素 | ひとことで | 例 |
|---|---|---|
| RAG | 今の質問に必要な外部知識を検索する | 社内規定から該当箇所を取得 |
| Memory | 過去の会話・決定・作業結果を再利用する | 顧客の希望や前回の失敗を引き継ぐ |
RAGでは検索に失敗すると、生成も失敗します。Memoryでは誤った記憶や古い判断が残る危険があります。どちらも「AIに情報を足す」だけでなく、根拠・鮮度・権限・削除を設計します。
2. 実行構造：どう仕事を進めさせるか
Anthropic は、あらかじめ決めた経路でLLMとツールを動かすものを workflow、LLMが状況に応じて手順やツール利用を決めるものを agent と区別しています。
| 要素 | 決めること | 向く仕事 |
|---|---|---|
| Tool | AIが使える検索・API・ファイル操作 | 情報取得、計算、保存、外部操作 |
| Workflow | 人が先に決める処理順・分岐 | 定型レポート、分類、変換 |
| Agent | 目標に届く途中ルートをAIが選ぶ | 調査、障害対応、コーディング |
| Loop | 観察・評価・再試行・停止 | テスト修正、品質改善、仮説検証 |
| Graph | 複数工程の分岐・並列・合流・承認 | 複数専門領域をまたぐ業務 |
| Multi-Agent | 複数Agentの役割と受け渡し | 独立した専門分業や並列調査 |
仕事の形で選ぶ
判断の軸は「新しい技術か」ではなく、次の2つです。
- 手順の不確実性：毎回同じ道か、途中で調べて道を変えるか
- 操作リスク：回答だけか、公開・送信・更新・削除まで行うか
固定手順で済むならWorkflowがテストしやすく、コストも読みやすい構成です。途中で仮説を変える必要があるならAgentとLoopが候補になります。並列調査、別担当の検証、途中承認が必要になったとき、Graphに分ける理由が生まれます。
3. 運用品質：どう測り、守り、改善するか
一度動いたデモと、業務で安定して使えるシステムの差は、この層に出ます。
HarnessはAIの「作業環境」
Harnessは、モデルを囲む実行基盤です。System Prompt、Tool、状態、再試行、タイムアウト、権限、ログ、人間への引き継ぎをまとめます。
Agent = Model + Instructions + Tools + 実行を支えるHarness
モデルが同じでも、必要なファイルを探せるか、テストを実行できるか、途中状態を残せるかで完遂率は変わります。
Evaluationは「良さ」を合否にする
AIの出力は毎回同じとは限りません。「なんとなく良い」では改善できないため、テストケースと評価基準を用意します。
| 評価対象 | 例 |
|---|---|
| 最終結果 | 正確さ、必須項目、業務目標の達成 |
| 途中経路 | 検索結果、Tool選択、引数、再試行 |
| 運用 | 処理時間、コスト、失敗率、安全違反 |
コードならテストのexit code、構造化出力ならSchema、公開文章なら人間承認など、モデルの自己採点とは別の検証器を置くのが基本です。
Trace・Guardrail・人間確認
- Trace / Observability：何を入力し、どのToolを呼び、どこで失敗したかを追えるようにする
- Guardrail：入力、出力、Tool実行、権限を検査する
- Human-in-the-loop：高リスク操作、不確実な判断、外部公開の前で人間に渡す
Guardrailは万能な壁ではありません。認証、権限管理、操作上限、監査ログと重ねて使います。
16の用語を一枚の一覧に戻す
ここまでの地図に、元の用語を戻します。
| 設計要素 | 主に設計するもの | 最初に確認すること |
|---|---|---|
| Prompt | 指示 | 一問一答で終わるか |
| Context | 渡す情報 | 必要・最新の情報だけか |
| RAG | 外部知識の検索 | 正しい根拠を取れるか |
| Memory | 過去情報の再利用 | 記憶・更新・削除の規則があるか |
| Tool | 外部取得・操作 | 権限と失敗時の挙動は安全か |
| Workflow | 固定手順 | 経路を先に決められるか |
| Agent | 動的な判断 | AIが経路を選ぶ必要があるか |
| Loop | 反復と停止 | 合格条件と回数上限があるか |
| Graph | 分岐・並列・状態 | 複数経路に分ける理由があるか |
| Multi-Agent | AIの分業 | 独立した役割や並列性があるか |
| Harness | 周辺の実行基盤 | 長時間作業を再開・追跡できるか |
| Evaluation | 品質測定 | 改善前後を同じ物差しで比べられるか |
| Observability | 実行追跡 | 失敗箇所を後から説明できるか |
| Guardrail | 安全制御 | 危険な入力・出力・操作を止められるか |
| Human-in-the-loop | 人間判断 | 承認と引き継ぎの場所が明確か |
| Model / Fine-tuning | モデル能力・特性 | 周辺設計では解けない問題か |
頻繁に変わる知識を参照させたい場合は、まずRAGやToolを検討します。Fine-tuningは、十分な教師データと評価基盤があり、特定の出力形式や振る舞いを繰り返し安定させたい場合の候補です。
導入は「足りなくなったら次へ」
Step 1：一問一答を安定させる
Prompt、出力形式、必要なContextを固定します。社内知識が必要ならRAGを足し、根拠を表示します。
Step 2：固定手順を自動化する
ToolとWorkflowを使い、分類→取得→生成→検査のような工程をコードで固定します。各工程を個別にテストします。
Step 3：探索が必要ならSingle Agent + Loop
状況によって次の調査や修正が変わる仕事だけをAgentにします。Goal、合格条件、再試行上限、禁止操作、人間への引き継ぎを先に決めます。
Step 4：分岐と責任が増えたらGraph
専門役割、並列処理、独立した検証、途中承認が必要なら経路を分けます。Multi-Agentは「Promptを分割したい」だけではなく、分業による明確な価値がある場合に使います。
OpenAIの実践ガイドも、まずSingle Agentの能力を最大化し、必要な場合に複数Agentへ分ける段階的な考え方を示しています。
例：ブログ作成なら何を組み合わせるか
この記事のようなブログ作成を例にすると、最初からMulti-Agentにする必要はありません。
Prompt（読者・目的・構成）
+ Context（既存記事・トーン・公開ルール）
+ RAG / 検索（一次情報）
+ Evaluator Loop（事実・読みやすさ・形式）
+ Human review（公開判断）
もし調査領域が独立していて並列化の効果が高い、法務レビューだけ責任を分けたい、といった理由が出たときにGraphやMulti-Agentを検討します。
つまずいたこと
以前は用語を導入順に並べ、「Promptの次はAgent、その次はGraph」と説明していました。すると、簡単な定型処理にもAgentを入れ、失敗原因が増えてしまいます。
足りなかったのは新しいフレームワークではなく、どの層の問題を解いているかという地図でした。3層に分けると、「検索が弱いのにGraphを増やしていた」「評価なしでLoopを回していた」といったズレを指摘しやすくなります。
この回の要点
- AIエンジニアリングは、判断品質・実行構造・運用品質の3層で見る
- Prompt、RAG、Agent、Loop、Graphは競合ではなく、違う問題を解く部品
- 業務の不確実性と操作リスクに合う最小構成から始める
- Agent化の前に、成功条件、停止条件、禁止操作、人間への引き継ぎを決める
- EvaluationとTraceがあって、初めて改善を続けられる
次回は実行構造の一つ、Loop Engineeringを取り出します。失敗した単体テストを直すエージェントを例に、Goal、Action、Observe、Verify、Retryを具体化します。
よくある質問
AIエンジニアリングはPrompt Engineeringの言い換えですか？
いいえ。指示の設計に加え、参照情報、ツール、実行経路、評価、安全制御、運用改善まで含むシステム設計として扱います。
RAGとMemoryは同じですか？
いいえ。RAGは必要な外部知識を検索して渡す仕組み、Memoryは過去の会話・判断・作業結果を後の処理で再利用する仕組みです。
AgentやMulti-Agentは最初から必要ですか？
多くの仕事では不要です。一問一答、固定Workflow、Single Agentの順に試し、分業や並列化が必要になってからGraphやMulti-Agentを検討します。
Loop Engineeringはどの層ですか？
主に実行構造の層です。ただし、合格条件を決めるEvaluationや停止・人間引き継ぎなど運用品質の層とセットで設計します。
