9章 AIエージェント設計：プロンプト・コンテキスト・ハーネス・ループ・グラフと人間の関与

生成AIの利用は、1回の質問に答えさせる段階から、資料やツールを使い、結果を検証しながら複数の作業を進めるAIエージェントへ広がっています。その設計を説明する言葉として、プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング、ループエンジニアリング、グラフエンジニアリングが使われています。

ただし、特にハーネスエンジニアリング、ループエンジニアリング、グラフエンジニアリングは、2026年時点では新しく、範囲や境界が国際規格などで一意に定まった用語ではありません。ループエンジニアリングは新興の実践分野として紹介され、グラフエンジニアリングは2026年7月の提唱記事で、エージェントシステムを明示的なグラフとして設計する考え方に付けられた新しい呼称です。【E4】【E5】【E11】 一方、複数のエージェントを有向グラフで順次・並列・条件分岐・反復させる実装自体は、公式フレームワークでも提供されています。【E12】 本章では、5つを優劣や置き換えではなく、AIを囲む設計範囲が広がる関係として整理します。

本章の位置付け
本章の定義は、違いを学ぶための操作的定義です。製品、研究、組織によって用語の範囲が異なる場合があります。実装時は、利用する製品の公式資料、組織の規程、適用される法令を確認してください。

この章の対象者

• 生成AIへの質問から、AIエージェントの設計へ進みたい方
• プロンプト、コンテキスト、ハーネス、ループ、グラフの違いを整理したい方
• ループや複数エージェントによるトークン消費と費用への影響を知りたい方
• AIに外部ツールや継続作業を任せる前に、安全な境界を設計したい方
• HITL、HOTL、HOOTLによる人間の関与方法を学びたい方
• AIエージェントを導入・監督・評価する方

この章でできるようになること

1. 5つのエンジニアリングの対象範囲と関係を説明できる。
2. 目的に応じて、プロンプトとコンテキストを分けて設計できる。
3. ツール、権限、実行環境、記録を含むハーネスの構成を確認できる。
4. 証拠、予算、停止条件を備えた小さなループを設計できる。
5. ノード、エッジ、共有状態、分岐、合流、失敗経路を備えた小さなグラフを設計できる。
6. モデル呼出し、入力・出力トークン、再試行を確認し、タスク単位の利用量と費用の目安、上限を決められる。
7. 操作の影響と可逆性に応じて、HITL、HOTL、HOOTLを選択できる。

9-1. 5つのエンジニアリングを一続きで理解する

5つのエンジニアリングは、前のものを捨てて次へ移る段階ではありません。外側の仕組みは、内側の設計を利用します。

flowchart LR
  R["人が定める目的・責任・境界"] --> G["グラフ：役割・経路・共有状態"]
  G --> L["ループ：反復・評価・停止"]
  L --> H["ハーネス：環境・権限・ツール"]
  H --> C["コンテキスト：今回必要な情報"]
  C --> P["プロンプト：今回の指示"]
  P --> M["AIモデル"]
  M --> A["回答・ツール操作"]
  A --> V["観察・テスト・証拠"]
  V --> L
  L --> D{"再試行・終了・人へ引き継ぐ"}

短く言い換えると、次の関係です。

プロンプトは「指示」を設計する。
コンテキストは「判断材料」を設計する。
ハーネスは「作業環境」を設計する。
ループは「反復と終了」を設計する。
グラフは「役割分担と経路」を設計する。

プロンプトとコンテキストの境界

「プロンプト」という言葉を、モデルへ渡すすべての入力という広い意味で使う場合もあります。本章では比較のため、利用者が今回伝える依頼・条件・出力形式を主に「プロンプト」、モデルが推論時に参照できる情報全体を「コンテキスト」と呼びます。プロンプトはコンテキストの一部です。

ハーネスとループの境界

ハーネス自体が、モデルにツールを使わせる内部ループを持つことがあります。本章では、1回のエージェント実行を支える環境と制御を主に「ハーネス」、複数回・複数工程にまたがって仕事を発見し、状態を保存し、再試行・終了・引継ぎを決める外側の制御を「ループ」と呼びます。

ループとグラフの境界

本章では、一つの目標へ向けた行動・観察・評価・修正の反復を主に「ループ」、複数の処理、エージェント、人の判断をノードとして配置し、実行順序、分岐、並列処理、合流、状態の受渡しを明示する外側の構造を「グラフ」と呼びます。一つのループも循環を持つ小さなグラフとして表現でき、グラフ内の一つのノードが内部にループを持つこともあります。両者は排他的ではありません。【E11】【E12】

9-2. プロンプトエンジニアリング：今回の指示を設計する

プロンプトエンジニアリングとは、AIから目的に合う回答や行動候補を得るために、指示、入力、条件、例、出力形式を設計し、観察結果に基づいて改善することです。Googleの公式ガイドも、明確で具体的な指示、制約、出力形式、例、文脈の提示と、反復的な改善を扱っています。【E1】

基本項目

【目的】AI教室の公開前確認を行う。
【依頼】指定したページ内のリンクを検査する。
【入力】検査対象URLの一覧。
【条件】読み取りだけを行い、ページやファイルは変更しない。
【出力】URL、HTTP状態、確認日時、要確認事項を表にする。
【確認】取得できない理由を推測で断定しない。

プロンプトだけでは解決しないこと

• 与えていない最新情報や社内情報を、正確に知っているとは限りません。
• 「削除しないで」と書くだけでは、実際の削除権限を無効化できません。
• 「正しいか確認して」と頼んでも、独立したテストや原典確認にはなりません。
• 毎回人が回答を読み、次の指示を書く方法は対話的な改善ですが、それだけで自動ループにはなりません。

プロンプトの具体的な作り方は、1章「生成AI基礎：質問と回答の基本」で学びます。

9-3. コンテキストエンジニアリング：判断材料を設計する

コンテキストエンジニアリングとは、モデルが今回の推論で必要とする情報を選び、整理し、適切な時点で提供・更新する設計です。Anthropicは、プロンプト以外も含め、推論時に利用できる情報全体を選定・維持する考え方として説明しています。【E2】

コンテキストに入り得る情報

• システム上の基本指示
• 利用者のプロンプト
• 会話履歴
• 参照文書、Web情報、データベースの検索結果
• RAG（Retrieval-Augmented Generation）で取得した資料
• プロジェクトの規則、スキル、手順書
• 過去の作業結果や永続メモリー
• 利用可能なツールの名前・説明・入力形式
• ツールを実行して得た結果
• 現在日時、対象版、進行中の作業状態

良いコンテキストの条件

コンテキストウィンドウが長くても、資料を無制限に入れてよいわけではありません。大量の情報は重要事項を埋もれさせ、費用や待ち時間を増やし、矛盾や古い情報を混入させる可能性があります。必要な情報を必要な時に渡すことが中心です。【E2】

RAGとの違い

RAGは、質問に関連する外部文書を検索してコンテキストへ加える構成です。コンテキストエンジニアリングは、それより広く、検索対象、選別、順序、要約、履歴、ツール結果、メモリー、削除方針まで扱います。

9-4. ハーネスエンジニアリング：安全に作業できる環境を設計する

本章ではハーネスを、AIモデルを実際に作業できるエージェントとして動かすために、その周囲へ設けるコード、設定、実行環境、ツール、制約、記録の総体と定義します。実務家による整理では、システム指示、ツール、MCPサーバー、ファイルシステム、サンドボックス、オーケストレーション、フック、ログなどが例示されています。【E3】

AIエージェント ＝ AIモデル ＋ ハーネス

この式は理解のための簡略化です。製品によって、モデルとハーネスの境界や提供者は異なります。

ハーネスの主な構成

指示と強制を分ける

プロンプトに「本番ファイルを削除しない」と書くのは指示です。削除権限を与えない、対象ディレクトリを限定する、削除操作をフックで拒否することはハーネスによる強制です。重大な事故を避ける条件は、モデルが忘れないことだけに依存させません。

MCPとの関係

MCP（Model Context Protocol）は、ハーネスが外部のデータやツールへ接続する方法の一つです。MCPを導入しても、ツールの安全性、最小権限、入力検証、承認、監査が自動的に保証されるわけではありません。【E9】 詳細は8章「AIエージェントとMCP」で学びます。

9-5. ループエンジニアリング：反復・検証・終了を設計する

ループエンジニアリングとは、AIエージェントが目標に向けて行動し、結果を観察・評価し、必要に応じて方法やコンテキストを修正し、成功・停止・人への引継ぎを判断する仕組みを設計することです。【E4】【E5】

flowchart LR
  A["目標・終了条件"] --> B["行動"]
  B --> C["結果を観察"]
  C --> D["テスト・評価"]
  D --> E{"合格条件を満たしたか"}
  E -- "いいえ" --> F{"継続可能か"}
  F -- "はい" --> G["方法・コンテキストを修正"]
  G --> B
  F -- "いいえ" --> H["安全に停止して人へ引き継ぐ"]
  E -- "はい" --> I["証拠と状態を保存して終了"]

ループを成立させる要素

「完了」という主張と証拠を分ける

AIが「完了しました」と回答しても、それは主張です。テスト結果、差分、検査日時、対象版、ログなど、現在の状態に結び付いた証拠を確認します。可能であれば、作業したエージェントとは別の検査、または決定的なテストを使います。

悪い終了条件：AIが完成したと判断したら終了

改善例：
- 指定した全ページを検査済み
- 結果表にURL・状態・確認日時がある
- 取得不能なURLが「要確認」として残っている
- ページやファイルを変更していない
- 50件または5分に達したら未完了として停止する

ループは無限反復ではない

失敗した処理を高速に繰り返すと、費用増加、外部サービスへの負荷、誤変更の増幅、同じ失敗の反復につながります。再試行回数、待機時間、同じ失敗が続いた場合の停止、料金上限を先に決めます。ループを自動スケジュールする前に、監督下で小さな1回を実行し、証拠と停止動作を確認します。

9-6. グラフエンジニアリング：複数の処理とループを編成する

本章ではグラフエンジニアリングを、AIを含む複数の処理を実行可能な有向グラフとして表し、役割、実行経路、共有状態、検証、承認、失敗時の戻り先を設計することと定義します。2026年7月に提唱された新しい呼称であり、標準化された固有の開発手法名ではありません。【E11】 一方、Microsoft AutoGenの公式資料は、有向グラフ上で順次、並列、条件分岐、安全な終了条件を持つ反復を制御する実装例を示しています。【E12】

グラフを構成する要素

ノードをすべてAIエージェントにする必要はありません。形式検査、件数確認、アクセス制御のように規則で確定できる処理は、通常のコードや設定で実行した方が、再現性と監査可能性を高められる場合があります。人による承認や外部イベントの待機もノードにできます。【E11】

flowchart LR
  A["対象URL一覧"] --> B["対象を分割"]
  B --> C1["読取り専用の検査1"]
  B --> C2["読取り専用の検査2"]
  C1 --> D["結果と根拠を合流"]
  C2 --> D
  D --> E["決定的な形式・件数検査"]
  E --> F{"合格したか"}
  F -- "はい" --> G["報告を作成"]
  F -- "いいえ" --> H["要確認として状態を保存"]
  H --> I["人が再試行・修正・終了を判断"]

グラフを使う目安

次の条件がある場合に、小さなグラフを検討します。

• 独立した作業を並列に実行し、結果を合流したい。
• 作成役と検査役で、モデル、ツール、権限を分けたい。
• 結果によって次の処理を明示的に分岐させたい。
• 公開・送信・削除などの前に、人の承認ゲートを必ず通したい。
• 一部の失敗だけを再試行し、完了済みの作業を再利用したい。
• どの経路を通り、どの状態と根拠で判断したか監査したい。

一つのエージェントと小さなループで十分な作業を、無理に多くのノードへ分割すると、受渡し、状態同期、費用、障害点が増えます。最初は単一のループで成立するか確認し、異なる責任・権限・並列性・失敗境界が必要になった時点で分割します。

用語の混同を避ける

本章の「グラフエンジニアリング」は、作業の実行経路を設計するエージェント・ワークフローの文脈で使います。エンティティ、関係、語彙、オントロジー等を設計・構築・管理する「知識グラフエンジニアリング（Knowledge Graph Engineering）」は、以前から使われている別の分野です。【E13】 GraphRAGも知識や検索の構成を表す言葉であり、本章の実行グラフとは区別します。

また、Mermaid等でフロー図を描いただけでは実行可能なグラフになりません。各ノードの入力・出力、状態の保存先、遷移条件、権限、タイムアウト、再試行、停止、監査方法を実装し、失敗経路を含めてテストする必要があります。

9-7. トークン消費と費用の考え方

ループやグラフは、1回の質問だけでは難しい作業を、反復、分担、検証によって進められる一方、モデルを呼び出す回数と、各呼出しで処理する入力・出力が増えるため、単発のモデル呼出しより総トークン消費が増えやすいというデメリットがあります。同じ処理を基準にしてモデル呼出しを追加すれば、その追加呼出しで使った入力・出力トークンは確実にタスクの総量へ加算されます。グラフ自体がトークンを消費するのではなく、グラフ内でLLMを使うノード、ループ、検査、要約、引継ぎが消費します。通常のコード、条件判定、データ保存など、LLMを呼ばないノードはモデルのトークンを消費しません。

ただし、1トークンは文字数やバイト数のような共通の固定単位ではありません。文章の内容や言語、モデルが使うトークナイザーによって分割結果が変わるため、文字数から一律に換算することはできません。【E16】 料金も、サービス、モデル、入力・出力、キャッシュ、推論、利用時点の単価や契約条件によって変わります。そのため本節では、将来の消費量や費用を一つの式で正確に予測するのではなく、利用するサービスが示す利用量と料金表を基に、増減の傾向、費用の目安、上限を考えます。

なぜトークン消費が増えるのか

例えば、3つの独立したLLMノードについて、利用量情報にそれぞれ1万トークンと記録されれば、並列実行で終了までの時間が短くなっても、タスク全体の記録上は合計3万トークンです。さらに、計画役と統合役の呼出し、引継ぎの要約、再試行があれば、その分が加算されます。ただし、異なるモデルや利用区分では単価が異なる場合があるため、トークン数の合計だけから費用を決めることはできません。

特定システムの実測例

Anthropicは、自社の調査システムについて、通常のチャットと比べてエージェントが約4倍、マルチエージェントシステムが約15倍のトークンを使用したと報告しています。【E14】 これは、複数エージェントが必ず同じ倍率になるという一般則ではありません。調査の広さ、モデル、コンテキスト、ツール、サブエージェント数、再試行、停止条件によって変わるため、教材上の見積係数にはせず、実測が必要であることを示す一例として扱います。

利用量と費用の確かめ方

利用量を確認するときは、画面に見える最終回答だけでなく、モデルへ渡した入力と、各モデル呼出しが生成した出力をタスク全体で確認します。サービスによっては、キャッシュ入力、キャッシュ書込み、推論トークン、画像・音声トークン等を別区分で記録・課金します。OpenAIのUsage APIも、モデル要求数、入力、出力、キャッシュ入力、キャッシュ書込み等を集計項目として提供しています。【E15】

タスク全体のトークン利用量（サービスが報告する値を集計）
  ＝ Σ 各モデル呼出しで報告された総トークン

総トークンがない場合
  ＝ Σ 入力トークン ＋ Σ 出力トークン
  ＋ そのサービスで上記に含まれず、別に計上される区分

費用の目安
  ＝ Σ モデル・利用区分ごとの利用量 × 利用時点の単価
  ＋ 外部ツール等の別料金

この式は考え方を整理するための目安であり、すべてのサービスに共通する料金式ではありません。キャッシュ入力、キャッシュ書込み、推論トークン等が、入力・出力・総トークンに含まれるかはサービスによって異なります。利用量情報と料金表の定義を確認し、内訳を総量へ再加算して二重計上しないようにします。

外部検索、コード実行、画像生成、MCP接続先などに別料金がある場合は、トークン料金と分けて集計します。また、キャッシュは同じ入力を効率的に処理し、料金や待ち時間を下げる場合がありますが、キャッシュされた入力も利用量として記録されることがあります。キャッシュ利用と、トークンを処理しなかったことは同じではありません。

トークン消費を抑える工夫

• まず単発処理または一つの小さなループを基準として、グラフ化前後のモデル別・利用区分別のトークン利用量、費用、所要時間、成功率を比較する。
• タスク、日、利用者ごとに、モデル要求数、ターン数、サブエージェント数、並列数、再試行数、トークン、料金の上限を設ける。
• 形式、件数、重複、必須項目など、規則で判定できる検査は通常のコードで行う。
• 各ノードへ、その処理に必要な資料、履歴、ツールだけを渡し、長い中間出力は要約または外部成果物への参照にする。
• サブエージェントの担当範囲を重複させず、同じ調査や検査を複数ノードで繰り返さない。
• チェックポイントと完了状態を保存し、失敗時にタスク全体を最初から再実行しない。
• 利用可能な場合は、安定した共通指示のキャッシュ、簡単なノードへの小型モデル、必要時だけのツール読込みを検討する。
• 合格条件を満たしたら直ちに終了し、品質向上が確認できない追加反復を止める。

トークン数を最小にすることだけが目的ではありません。トークンを多く使っても、難しいタスクの完了率や品質が十分に上がり、その価値が費用を上回る場合があります。反対に、単発処理と結果が変わらないなら、複雑なループやグラフを維持する理由は弱くなります。品質、証拠、所要時間、費用を同じ評価表で比較します。

9-8. 人間はループのどこにいるか

HITL、HOTL、HOOTLは、ループ内での人間の位置と権限を考えるための分類です。これらはループエンジニアリングだけの用語ではなく、AI・自動化システム全般の人間による監督を扱う考え方です。

欧州委員会の「信頼できるAIのための倫理ガイドライン」は、人間による監督方法としてHITL、HOTL、Human-in-Commandを挙げています。【E6】 香港政府Digital Policy Officeの倫理的AIフレームワークは、影響に比例して人間の関与レベルを決める考え方と、HITL、HOOTL、Human-in-Commandを示しています。【E7】 このように分類は資料によって異なるため、本章では次の3つを操作的に定義します。

人の関与が多い                                      AIの自律性が高い
HITL  ─────────────→  HOTL  ─────────────→  HOOTL
承認してから実行          監視し必要時に介入         実行中の人の介入なし

HITL：承認ゲートをループ内に置く

flowchart LR
  A["AIが案を作る"] --> B["根拠・差分・影響を表示"]
  B --> C{"人が承認するか"}
  C -- "承認" --> D["実行"]
  C -- "修正・拒否" --> E["修正または安全に終了"]

承認ボタンを置くだけでは有効なHITLになりません。担当者に、判断に必要な情報、時間、能力、権限が必要です。高リスクAIについてEU AI Act第14条も、監督者が能力と限界を理解し、異常を監視し、出力を解釈できることなどを求めています。【E8】 本章はEU法の個別適用を判断するものではありませんが、形式だけの承認を避ける設計原則として参考にできます。

HOTL：監視と介入を可能にする

HOTLでは、AIの処理を毎回止めません。その代わり、次の機能が必要です。

• 現在の状態、対象、進行状況を確認できる
• 異常・予算超過・停滞を通知する
• 実行履歴と変更差分を記録する
• 人が緊急停止できる
• 取消・復旧・再開の手順がある
• 介入できる担当者と連絡経路が決まっている

通知が多すぎて誰も確認できない、停止操作が間に合わない、担当者に権限がない状態は、実質的な監督になりません。

HOOTL：限定範囲で無人実行する

HOOTLは「人間や組織に責任がない」という意味ではありません。実行中に人が介入しない場合でも、導入目的、権限、対象範囲、停止条件、影響評価、運用後の検証に対する責任は残ります。

本章では、次の条件を満たす低影響・限定範囲の作業から検討します。

• 読み取り専用、または隔離された環境である
• 人、資産、権利、公開情報へ重大な影響を与えない
• 対象、回数、時間、費用が制限されている
• 失敗時は安全側で停止する
• 実行結果と証拠が記録される
• 必要に応じて元に戻せる

個人情報、採用・評価、医療、法律、金融、重要インフラなどへの影響、外部公開、削除、送信、支払い、権限変更を伴う処理を、影響評価なしにHOOTLへしません。NIST AI RMFも、AIリスクを用途と影響に応じて継続的に管理する枠組みを示しています。【E10】

エージェント特有のセキュリティリスクも確認する

OWASPの「Top 10 for Agentic Applications 2026」は、エージェント固有の主要なリスクとして、目標の乗っ取り、ツールの誤用、ID・権限の悪用、エージェント型サプライチェーン、予期しないコード実行、メモリ・コンテキスト汚染、安全でないエージェント間通信、障害の連鎖、人間とエージェントの信頼関係の悪用、暴走・逸脱するエージェントを挙げています。【E17】

これらは別々に発生するとは限りません。外部文書の不正な指示が目標を変え、過大な権限を持つツールを実行し、その結果が共有状態や他のエージェントへ伝わると、グラフ全体へ影響が広がります。外部データ、記憶、エージェント間メッセージを信頼済みの命令として扱わず、エージェントごとのIDと最小権限、実行前の検証、障害の隔離、人による独立確認を組み合わせます。

システム全体ではなく、操作単位で選ぶ

1つのループの中で、すべてを同じ関与方式にする必要はありません。読み取りはHOOTL、下書きはHOTL、公開はHITLのように、操作の影響と可逆性に応じて分けます。

グラフ、ループ、ハーネスの役割分担

• グラフエンジニアリングは、どの処理の前後に承認・監視・引継ぎの経路を置くかを決めます。
• ループエンジニアリングは、どの条件で人が関与し、反復を止めるかを決めます。
• ハーネスエンジニアリングは、承認画面、権限、ログ、通知、停止ボタンなど、関与を実際に機能させる仕組みを実装します。

9-9. 実践例：AI教室のリンク切れ点検

同じ作業を5つの設計層に分けます。

人間の関与を操作ごとに決める

最小のループ設計例

【目標】
AI教室内の指定ページについて、リンク切れ候補を確認可能な表にする。

【対象】
指定された公開ページだけ。認証が必要なページは対象外。

【権限】
Webページと対象ファイルの読み取りだけ。修正・削除・公開は禁止。

【合格条件】
- 全対象URLについて結果がある
- URL、状態、確認日時、要確認理由が記録されている
- 変更操作を行っていない

【予算・停止条件】
- 最大50URLまたは5分
- 同じURLの再試行は1回
- 認証要求、アクセス拒否、想定外の大量URLを検出したら停止

【人への引継ぎ】
未確認URL、異常、次に必要な判断を一覧にして終了する。

9-10. 安全なループとグラフの設計チェックリスト

目標と評価

• [ ] 目標が具体的で、外部から確認できる。
• [ ] 「完了」の証拠が定義されている。
• [ ] 作業担当とは独立した検査、または決定的なテストがある。

コンテキスト

• [ ] 必要な資料、版、日時、出典がそろっている。
• [ ] 古い情報、重複、無関係な情報を除いている。
• [ ] 外部データを信頼できる命令として扱わない。
• [ ] 記憶・共有状態・エージェント間メッセージの出所と版を確認できる。
• [ ] 個人情報・機密情報を必要以上に含めていない。

ハーネス

• [ ] 読取り、書込み、送信、削除の権限が分離されている。
• [ ] 最小権限と対象範囲が実装で制限されている。
• [ ] エージェントごとにIDと認証情報を分け、委任時に権限を拡大しない。
• [ ] テスト、ログ、通知、停止、復旧の手段がある。
• [ ] APIキーなどの秘密情報がプロンプトや通常ログに出ない。

ループ

• [ ] 再試行回数、時間、トークン、料金に上限がある。
• [ ] 同じ失敗や進展のない状態を検出して停止できる。
• [ ] 状態が会話外にも保存され、次回に引き継げる。
• [ ] 失敗時に安全側で止まり、未完了を成功と記録しない。

グラフ

• [ ] 各ノードの役割、入力、出力、権限が明確である。
• [ ] 正常、分岐、差戻し、失敗、停止の各経路が定義されている。
• [ ] 並列処理の合流条件と、欠損・重複・競合の扱いが決まっている。
• [ ] 共有状態に版、根拠、承認結果を残し、誰が更新できるか制限している。
• [ ] 一部の失敗を隔離し、完了済みノードを不必要に再実行しない。
• [ ] 1つの誤り・汚染・不正なメッセージが、下流ノードや他のエージェントへ無制限に広がらない。
• [ ] ノード数と並列数を増やす前に、単一ループで不足する理由を説明できる。

トークン・費用

• [ ] 単発処理または単一ループを基準として、グラフ化前後を比較している。
• [ ] タスク全体とノード別のモデル要求数、入力・出力トークン、再試行を記録している。
• [ ] ターン数、サブエージェント数、並列数、再試行数、トークン、料金に上限がある。
• [ ] 並列化による時間短縮と、総トークン・総費用の増減を分けて評価している。
• [ ] 規則で判定できる処理を、不必要にLLMへ任せていない。
• [ ] 長い履歴・中間結果・ツール定義を必要以上に各ノードへ渡していない。
• [ ] キャッシュ、推論トークン、外部ツール等のサービス固有の課金区分を確認している。
• [ ] 増えた消費に見合う成功率、品質、根拠、時間短縮が得られている。

人間の関与

• [ ] 操作ごとにHITL、HOTL、HOOTLを選んでいる。
• [ ] 承認者に、情報、時間、能力、権限がある。
• [ ] HOTLで通知・監視・停止が実際に間に合う。
• [ ] HOOTLは低影響・限定範囲から始めている。
• [ ] AIの説明や自信を承認根拠にせず、証拠と影響を独立して確認している。
• [ ] 公開、送信、削除、支払い、権限変更に適切な承認がある。

9-11. ミニ演習：5層とトークン消費、人間の位置を考える

次の課題を考えます。

AI教室の出典URLを毎週確認し、リンク切れ候補と更新日が古い資料を報告する。Webサイトの本文は自動変更しない。

次の項目を記入してください。

1. プロンプトに書く目的、依頼、条件、出力形式
2. コンテキストとして必要な資料と、除外する情報
3. ハーネスへ与えるツール、権限、ログ、停止方法
4. ループの合格条件、再試行、予算、異常時の停止条件
5. グラフのノード、エッジ、共有状態、分岐、合流、失敗時の経路
6. 単発処理を基準にしたモデル要求数・入力・出力・再試行の目安と、タスク全体に設けるトークン・料金の上限
7. 読取り、報告、修正案作成、公開の各操作に使うHITL・HOTL・HOOTL
8. 「完了」を示す証拠

振り返り

• プロンプト上の禁止事項を、権限制御でも強制できているか。
• AIの自己申告ではなく、機械的に確認できる証拠があるか。
• 人の承認が必要な操作を、AI自身が回避できない構造になっているか。
• 自動化による時間短縮より、監視・確認の負担が大きくなっていないか。
• 並列化で待ち時間が短くなっても、総トークンと総費用が過大になっていないか。
• LLMを使わず通常のコードで処理できるノードがないか。
• 問題が起きたとき、誰が止め、誰が判断し、どう元に戻すか説明できるか。

まとめ

• プロンプトエンジニアリングは、今回の指示・条件・出力形式を設計する。
• コンテキストエンジニアリングは、モデルが今回使う判断材料を選択・更新する。
• ハーネスエンジニアリングは、ツール、実行環境、権限、検査、記録、復旧を設計する。
• ループエンジニアリングは、目標、行動、観察、評価、再試行、終了、引継ぎを設計する。
• グラフエンジニアリングは、複数の処理・役割をノードとエッジで結び、共有状態、分岐、合流、承認、失敗経路を設計する。
• 5つは置き換え関係ではなく、外側の設計が内側の設計を利用する。
• ループの反復、複数のLLMノード、検査、引継ぎ、再試行は、単発処理より総トークン消費を増やしやすい。
• 並列化は待ち時間を短縮できても総トークンを減らすとは限らないため、タスク全体でモデル要求数、入力、出力、再試行と、利用量・費用の増減を確認する。
• HITL、HOTL、HOOTLは、人間をループのどこに置くかを示す設計軸である。
• 関与方式はシステム全体で一律に決めず、操作の影響と可逆性に応じて選ぶ。
• 無人実行でも人間や組織の責任はなくならない。証拠、上限、停止、復旧を先に設計する。
• ハーネス、ループ、グラフは黎明期の用語であるため、用語名よりも、目的・権限・経路・状態・証拠・人間の責任を具体的に記録する。

次の講座

次は、用途を一つ選び、「読み取り専用の小さなループまたはグラフ」を監督下で試します。8章のMCP、6章の導入・監査、4章のテストを組み合わせ、正常終了だけでなく、上限到達、権限不足、取得失敗で安全に停止できることも確認します。単発処理または単一ループを基準に、総トークン、総費用、所要時間、成功率も比較します。

出典・エビデンス

• 【E1】 Google AI for Developers, *Prompt design strategies*（利用前に最新版を確認）

https://ai.google.dev/gemini-api/docs/prompting-strategies

• 【E2】 Anthropic, *Effective context engineering for AI agents*（2025年9月29日）

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

• 【E3】 Addy Osmani, *Agent Harness Engineering*（2026年4月19日）

https://addyosmani.com/blog/agent-harness-engineering/

• 【E4】 Addy Osmani, *Loop Engineering*（2026年6月7日）

https://addyosmani.com/blog/loop-engineering/

• 【E5】 IBM, *What Is Loop Engineering?*（2026年7月17日）

https://www.ibm.com/think/topics/loop-engineering

• 【E6】 European Commission High-Level Expert Group on AI, *Ethics Guidelines for Trustworthy AI*（2019年4月8日）

https://digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai

• 【E7】 Digital Policy Office, The Government of the Hong Kong Special Administrative Region, *Ethical Artificial Intelligence Framework, Version 2.0*（2025年12月）

https://www.digitalpolicy.gov.hk/en/our_work/data_governance/policies_standards/ethical_ai_framework/doc/Ethical_AI_Framework_en.pdf

• 【E8】 European Union, *Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14: Human oversight*（2024年6月13日）

https://eur-lex.europa.eu/eli/reg/2024/1689/oj

• 【E9】 Model Context Protocol, *Security Best Practices*（利用前に最新版を確認）

https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices

• 【E10】 National Institute of Standards and Technology (NIST), *Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile*（NIST AI 600-1、2024年7月26日）

https://doi.org/10.6028/NIST.AI.600-1

• 【E11】 Josh C. Simmons, *We Are Entering the Graph Engineering Phase*（2026年7月4日）

https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase

• 【E12】 Microsoft AutoGen, *GraphFlow (Workflows)*（利用前に最新版と実験的機能の注意を確認）

https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/graph-flow.html

• 【E13】 Meyer et al., *LLM-assisted Knowledge Graph Engineering: Experiments with ChatGPT*（2023年7月13日）

https://arxiv.org/abs/2307.06917

• 【E14】 Anthropic, *How we built our multi-agent research system*（2025年6月13日）

https://www.anthropic.com/engineering/multi-agent-research-system

• 【E15】 OpenAI, *Usage — OpenAI API Reference*（利用前に最新版を確認）

https://developers.openai.com/api/reference/resources/admin/subresources/organization/subresources/usage

• 【E16】 OpenAI, *Tokenizer — OpenAI API*（利用前に最新版を確認）

https://platform.openai.com/tokenizer

• 【E17】 OWASP Gen AI Security Project, *OWASP Top 10 for Agentic Applications 2026*（2025年12月9日）

https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

参照日：2026年8月14日。ハーネス、ループ、グラフ、トークン・料金区分、エージェント機能、製品仕様、法令・ガイドラインは更新され得ます。公開前および実装前に、対象地域・用途・製品の最新資料を確認してください。本章は法的助言ではありません。