AI エージェントの5つのレベル: プロンプトから本番運用まで

今、エージェントについて語られるときによく登場する 5 つの言葉があります。コンテキストエンジニアリング、ループエンジニアリング、Jev エンジニアリング、ハーネスエンジニアリング、Evals エンジニアリングです。

まるで 5 つの競合するアプローチのように聞こえますが、そうではありません。これらは 1 つのシステムを構成する 5 つのレイヤーであり、それぞれが 1 つの問いに答えるものです。

最もわかりやすいイメージは、新しい従業員を雇ったばかりだと想像することです。

• Context（コンテキスト） — 何か質問したとき、彼の机の上に何があるか
• Loop（ループ） — あなたのチェックリストに従うのか、それとも次のステップを自分で考えるのか
• Jev — 郵便物を仕分ける受付係。彼には本当に必要なものだけが届く
• Harness（ハーネス） — 彼のオフィス。どんなツールや鍵があり、誰が彼の作業を確認するのか
• Evals（評価） — 毎月同じテストを受けさせること。本当に成長しているかを知るため

AI エージェントとは、まさにこの従業員のことです。モデルが「人」であり、この 5 つのレイヤーがその周囲にあるすべてです。この 5 つのレイヤーを正しく設計できれば、少人数のチームでも、これまでなら人を雇わなければできなかった業務を引き受けられます。繰り返しの作業は本番環境で耐えられるエージェントに任せ、人間は意思決定に集中する。これが、人員を増やさずにスケールするということの実践的な姿です。

各レイヤーについて、「それは何か」「どう動くのか」「どこで使うのか」「どう構築するのか」を解説していきます。

さらに、各レイヤーごとにショートカットも用意しました。ゼロから構築しなくても同じ結果を得られる、初心者向けのシンプルな方法です。これらのショートカットは、友人である Viktor のチームに協力してもらってまとめました。

Viktor は、あなたの Slack や Microsoft Teams に常駐する AI 従業員です。他のメンバーと同じチャンネルに参加し、チームメイトのように働きます。新しい採用枠を開くことなくチームに追加できる存在です。

彼との働き方は、人間と働くのとほとんど変わりません。

• チャンネルやスレッドで彼にメンションし、タスクを説明します。
• 彼が手順を考え、各種ツールを横断して作業を行い、同じスレッドに結果を投稿します。

セットアップは簡単です。Viktor をワークスペースに追加するだけで、他のチームメンバーと同じように参加者として表示されます。この記事を読みながら試してみたい場合は、コード YARCHI100 を使ってください。

pic1. エージェントの 5 つのレイヤー

1. Context engineering（コンテキストエンジニアリング）

定義

質問をする前に、従業員の机の上に書類を置くとします。適切な 3 ページだけを置けば、彼は数秒で答えてくれます。しかし 300 ページも置けば、答えは紙束の真ん中に埋もれてしまい、見落としてしまいます。

ここでいうモデルが従業員であり、机がコンテキストウィンドウです。つまり、モデルが回答する前に目にするすべての情報——あなたの指示、これまでの会話履歴、データベースから取得したドキュメント、実行した各ツールの出力などです。

コンテキストエンジニアリングとは、「何を」「どこに」机の上に置くかを決める作業です。

仕組み

コンテキストが多ければ良い回答が得られるわけではありません。一定量を超えると、むしろ悪化します。

Stanford がこれを直接検証しています。モデルに 20〜30 のドキュメントを与えると、中間に配置されたドキュメントに対する精度は約 50〜57 % にまで低下しました。ドキュメントを一切与えなかった場合、同じモデルのスコアは 56 % でした。答えはウィンドウ内にあったにもかかわらず、何もない状態より成績が悪かったのです。

原因は 2 つあります。

• モデルはウィンドウの「最初」と「最後」に最も注意を払い、「中間」への注意が最も薄くなる。
• 役に立つかどうかに関わらず、すべてのトークンにコストと時間がかかる。

知っておくべき仕組みが 1 つ、プロンプトキャッシングです。プロバイダーがプロンプトの先頭部分を保存し、次の呼び出し時に再利用します。キャッシュされたトークンのコストは、新規生成時の約 10 分の 1 です。

注意点として、キャッシュが機能するのは先頭部分がバイト単位で完全に一致している場合のみです。先頭付近の 1 文字でも変更すると、それ以降はすべて通常料金で請求されます。したがって、「変わらないものは常に先頭、変わるものは最後に配置する」のが鉄則です。

構築方法

すべてのコンテキストは、次の 4 か所のいずれかに配置されます。

1. システムプロンプト。 毎回必ず真となるものだけ：役割、制約、出力形式。バイト単位で常に同一に保ちます。先頭にタイムスタンプを入れたり、JSON キーの順序をバラバラにしたりしないでください。
2. ツール。 会話の途中で追加・削除しないこと。キャッシュが壊れ、存在しないツールをモデルが呼び出そうとしてしまいます。特定のステップでツールを制限したい場合は、定義は残したまま呼び出しをブロックします。
3. ディスク。 サイズが大きいものや長期的なものはファイルに保存し、ウィンドウにはパスだけを保持します。Web ページも同様で、URL は残して本文は除外します。コンテンツ自体は外に出し、それを取得するためのキーだけを保持しましょう。
4. 末尾。 数ステップごとに、コンテキストの末尾付近で現在の目標を再提示します。中間部分は修正できないので、重要なものはそこに置かないようにします。

ツールにも上限があります。Anthropic の計測では、ユーザーが 1 文字も入力する前に、58 個のツール定義で約 55,000 トークンを消費しました。すべてのツールを読み込む代わりに、モデルに検索させたところ、Opus 4 のベンチマークスコアが 49 % から 74 % へ向上しました。

ツールが約 20 個以下ならそのまま読み込み、それ以上なら検索に切り替えます。

大規模なタスク向けのもう 1 つのテクニックは、サブエージェントを送ることです。サブエージェントが独自のウィンドウで 50 ファイルを読み込み、1 ページの要約を返します。メインのコンテキストはその要約だけを見れば済みます。

pic2. 1 回のモデル呼び出しに含まれるもの

ショートカット

Viktor のコンテキストは会社レベルで管理されるため、こうした作業の大部分を肩代わりしてくれます。

• メモリ。 チーム全体を通じて、ビジネスに関する永続的な記憶を持ちます。先週共同創業者から学んだことを、今日の依頼でわざわざ貼り付ける必要はありません。
• 接続済みソース。 Notion、Google Drive、HubSpot などを連携させれば、ファイルをチャットに貼り付ける手間はなくなります。ドキュメント名やレコード名を指定するだけで、彼がソースを読みに行きます。「ディスク」のルールを自動で実現してくれるわけです。
• スキル。 タスクを実行する画面を 1 回録画するだけで、彼がそれを書き起こした手順書に変換します。あなたが修正して承認すれば完了です。以降、その指示は優れたシステムプロンプトのように固定され、レビュー済みの状態になります。

あなた側に残る作業は次のとおりです。

• 会社の概要を 1 度だけ短く書く：何を売っているか、誰が買うか、どの数字が重要か、絶対にやってはいけないことは何か。
• 1 スレッドにつき 1 タスクとし、最初のメッセージで「完了の定義」を示す。
• 間違ったことを学習してしまった場合は、スレッドごとに訂正するのではなく、設定からメモリをリセットする。

2. Loop engineering（ループエンジニアリング）

定義

従業員にはチェックリストを渡すこともできます。「ファイルを開く → 12 行目を変更する → 保存する」。あるいは、目標だけを渡すこともできます。「テストを通るようにしろ」。

目標を与えられた場合、彼は何かを試み、結果を確認し、次に何をすべきかを自分で決めます。チェックリストは「ワークフロー」であり、目標は「ループ」です。

仕組み

ループは、「考える → 行動する → 観察する → 決める」という 4 つの動きの繰り返しです。バグ修正は次のようになります。

1. テストを実行する。3 つ失敗した。
2. 最初のエラーを読む。import が不足している。
3. import を追加し、再実行する。
4. まだ 1 つ失敗している。そのエラーを読み、修正し、再実行する。
5. すべて通過した。終了。

これらのステップを事前に書いた人はいません。モデルが直前の結果を見て、一つひとつ選択したのです。

ここが決定的な違いです。あなたが書いた 100 ステップは、依然としてワークフローです。モデルが選んだ 3 ステップこそがループです。

ループを使うのは、事前にステップを書けない場合のみにしてください。書けるなら書きましょう。ワークフローの方が低コストで並列実行でき、ステップ 4 で失敗しても全部ではなくステップ 4 だけを再実行できます。

ループはコストもかかります。エージェントは単発の呼び出しの約 4 倍のトークンを消費します。マルチエージェント構成では約 15 倍になります。

構築方法

ループには 4 つの要素が必要です。どれか 1 つでも欠けると機能しません。

1. 明確な「完了」を持つ目標。 「バグを直す」ではなく、「auth_test.py で失敗していたテストが通り、他に何も壊れていない状態」のように定義します。
2. チェッカー。 合格・不合格を判定する、モデル外部の仕組み。テストスイート、コンパイラ、リンターなどです。自己修正に関する研究結果は一貫しており、実際の外部フィードバックがあれば機能しますが、モデルが自分自身をレビューするだけでは失敗します。チェッカーがないループは、終わりなき支出を生むだけです。
3. 停止ルール。 チェッカーが合格した、ターン数の上限に達した、直近 2 回の試行で同じ出力になった、など。
4. 予算。 ターン数と金額の両方。

コードにすると、全体はわずか数行に収まります。

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # 完了
7    if repeated(history, 2):  break   # 行き詰まり
8    if spent() > BUDGET:      break   # コスト超過
9else:
10    fallback_workflow(goal)

公開されている中で最も優れた本番環境の構成は、ハイブリッド型です。Atlan はまず決定論的なフィルターを動かし、受信アラートのうちエージェントに到達するのは約 14 % だけです。

その後、ループは最大 3 サイクルしか回りません。3 回回っても確信度が 50 % 未満の場合は、固定の Python ワークフローに引き継がれます。

まずフィルターで絞り、短くループさせ、フォールバックする。

pic3. ワークフローとループの使い分け方

ショートカット

スレッド内で Viktor に与えるタスクは、すべてループになります。あなたが目標を書き、彼がステップを選び、各種ツールを使って作業し、結果を持ってスレッドに戻ってきます。

4 つの要素は次のように対応します。

• 目標。 情報が不十分な指示には反論し、推測する代わりに質問してきます。それでも「完了」は書いておきましょう。「月曜 9 時までに先週の売上レポートを作成し、合計値が Stripe と一致することを確認して #finance に投稿する」は、「レポートを作って」よりもずっと優れています。
• チェッカー。 投稿前に、不自然な数値を警告してくれます。照合元のソース（Stripe の合計値、行数、テストスイートなど）を明示すれば、さらに強力になります。
• 停止ルール。 影響の大きい操作は人間の確認待ちで一時停止し、結果は必ずあなたに報告されます。
• 予算。 クレジットです。推論ティアが各ステップのコストを決め、定期タスクでは頻度も重要です。毎時間のレポートは、週次レポートよりはるかに高くつきます。

Atlan のハイブリッド構成は、コードなしでも実現できます。繰り返される作業はスケジュールタスクになります。彼が提案し、あなたが承認するまで一時停止されたままになります。これがワークフローです。

それ以外の自由度高いタスクはスレッドに入れます。これがループです。そして、フォールバックの役割を果たすのはあなた自身です。

3. Jev engineering（Jev エンジニアリング）

定義

オフィスの専門家が、届いた封筒をすべて自分で開けることはありません。受付担当者が郵便物を仕分けます。請求書はこの山、スパムはゴミ箱、契約書は弁護士へ。

エージェントの仕事は「何かを書くこと」と「何かを判断すること」の 2 種類です。現在、1 つの巨大なモデルが両方を担っているため、あなたは郵便物の仕分けに弁護士の高額な報酬を払っているようなものです。

Jev は受付係です。決して書きません。ただ選びます。

仕組み

Jev には、質問と選択肢をあらかじめ与えておきます。返ってくるのは次の 3 つのいずれかと、確信度スコアです。

• yes または no
• セットからの 1 つの選択肢
• スケール上の数値

選ぶだけなので、高速かつ低コストです。公称値は 3〜329 秒に対して 70〜500 ミリ秒、入力 100 万トークンあたり $0.042 で出力は無料とされています。

ここからは正直な話です。Jev は登場からまだ 2 週間であり、第三者による検証結果が出始めたばかりです。

• メール分類では、単純なロジスティック回帰が 98.9 % に対し、Jev は 98.6 % でした。
• フィッシング検知では、Jev が 62.6 % だったのに対し、Claude Haiku 4.5 は 81.3 % でした。
• 「ハルシネーションゼロ」という数字には、著者自身の注釈がついています。実証的なものではなく、出力が常にスキーマと一致するという意味にすぎません。

また、確信度スコアもそのままでは本当の確率ではありません。ランキングとして扱い、自社でラベル付けしたデータに基づいて閾値を設定してください。

構築方法

現実的な構成は、高コストなモデルの前にゲートを置くことです。

1. すべての入力がやってくる。
2. Jev が各項目について 1 つの限定的な質問に答える。
3. 確信度が高く定型なもの：低コストで処理。ラベル付け、ルーティング、または破棄。
4. 不確かなものや非定型なもの：メインモデルへ送る。

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # フェイルクローズド：不確かなものは高コストな経路へ

いきなり凝ったことをする前に、「うまくいくかもしれない最も単純なこと」を試してください。数百件の実データをラベル付けし、基本的な分類器を訓練します。それで十分でない場合のみ、次の段階に進みます。

これは 30 分ほどの作業ですが、あらゆるベンダーの主張が超えなければならないベースラインとなります。

pic4. Jev が答える 3 種類の質問

ショートカット

Jev は Viktor の公開スタックには含まれていませんが、その考え方はあなたがコントロールできる 2 か所で応用できます。

• 推論ティア。 彼は 3 つのモードで動作します。Smart（Claude Opus）、Balanced（Claude Sonnet、コスト約半分）、Ultra（Claude Fable、コスト約 2 倍）。リクエストの仕分けや数値の抽出に最上位ティアは不要です。
• 彼の手前に置くゲート。 サポートメールやアラートのようなストリームを処理させたい場合、ストリーム全体をそのまま渡さないでください。先に分類器や Jev の呼び出しを挟み、判断が必要な項目だけが彼のタスクになるようにします。

これは、Viktor を使っていても自社のエンジニアリングが依然として重要になる 2 つのレイヤーのうちの 1 つです。

4. Harness engineering（ハーネスエンジニアリング）

定義

同じ従業員に、2 つの異なるオフィスを用意したとします。1 つ目のオフィスには適切なツール、壁に貼られたマニュアル、作業をチェックする同僚がおり、金庫の鍵は渡されていません。2 つ目のオフィスにはノートパソコンと管理者パスワードがあります。

スキルは同じでも、結果は大きく異なります。従業員がモデルであり、オフィスがハーネスです。

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

仕組み

ハーネスとは、モデル以外のすべてを指します。ツール、権限、サンドボックス、プロジェクトを説明するファイル、出力に対するチェックなどです。

2026 年にこれが独立した分野となったのは、人々が計測を始め、モデル自体が期待ほど差を生んでいないことがわかったからです。

• Anthropic はコンテナのリソースを変更しただけで、ベンチマークスコアを 6 ポイント動かしました。
• LangChain はモデルを固定し、ハーネスの変更だけで同じベンチマークを 13.7 ポイント向上させました。
• さらに、10 分の 1 のコストのオープンモデルに合わせてハーネスをチューニングし、Opus 4.8 の 0.87 に対して 0.86 というスコアを叩き出しました。

もはやモデル単体を買っているのではありません。モデルとハーネスをセットで買っているのです。

エージェントが現実のもの（リポジトリ、受信トレイ、決済、本番データベース）に触れた瞬間、ハーネスが必要になります。

構築方法

外側から内側に向かって構築します。

1. 隔離（Containment）。 エージェントが物理的に到達できない範囲。コンテナ、別ブランチ、読み取り専用の DB ユーザー、許可リスト以外のネットワーク遮断。最初のプロンプトの前に実施します。
2. ガイド（Guides）。 行動前に方向づけるもの。AGENTS.md のようなリポジトリ内のファイル、モデルが正しいものを選べるほど明確なツール説明、良質な出力例など。
3. センサー（Sensors）。 行動後にチェックするもの。リンター、型チェッカー、テストスイートは高速かつ決定論的なので、すべてに対して実行します。2 つ目のモデルで差分をレビューするような遅いチェックは、重要なものに限定します。
4. 権限（Permissions）。 エージェントが承認を求める場合、人間は 93 % の確率で承認してしまいます。承認プロンプトはほとんど防御になりません。本当の防御は、「そもそもその操作ができない」状態にすることです。承認フローは、本当に不可逆な少数の操作のためだけに取っておきましょう。

ガイドファイルは長くある必要はありません。たった 4 行で挙動は変わります。

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Run tests with `make test`. They must pass before any commit
4- Never edit /migrations by hand, use `make migration`
5- DB access is read only. Ask before any schema change

フックは、同じアイデアを強制力を持たせたものです。Claude Code におけるフックとは、ツール呼び出しの前に実行され、それをブロックできる小さなスクリプトです。「main ブランチに push しない」は、プロンプト内の 1 行としてではなく、フックとして実装すべきです。

1 つ注意点があります。ハーネスの各要素は「モデルにはこれができないだろう」という賭けであり、その賭けには有効期限があります。Anthropic は、モデルのアップグレードによって不要になった足場（scaffolding）のコンポーネントを丸ごと削除しました。

数ヶ月ごとにハーネスを見直し、モデルが卒業した要素は削除しましょう。

pic5. ハーネスの 4 つの輪

ショートカット

エージェント ＝ モデル ＋ ハーネスであるなら、Viktor で得られるものの大半はハーネスです。基盤となるモデルは Claude で、その周囲のすべてがすぐに使える状態で揃っています。

• ツール。 3,200 以上の連携：GitHub、Linear、HubSpot、Stripe、Notion、Google Drive など。既存の連携がないツールでも、彼自身が構築できます。
• ガイド。 スキル機能です。AGENTS.md を自分で書く代わりに、画面を録画すれば彼が手順書の草案を作り、あなたが編集します。
• センサー。 整合性の取れないデータを警告し、情報が欠けた指示には質問してきます。そしてすべてのステップが、チームが読める Slack スレッドに残ります。
• 権限。 顧客メールや財務情報の変更は承認待ちで一時停止します。新しいスケジュール自動化も、誰かがオンにするまで停止したままです。

どの製品も代わりに作れないのが「隔離」です。なぜなら、それはあなたが渡す認証情報で構成されるからです。あの 93 % を思い出し、業務に必要な最小限のアクセス権で連携させてください。

• 読み取り専用のデータベースユーザー
• 制限付きの Stripe キー
• 個人用ではなく共有のサポート受信トレイ
• 特定のリポジトリにスコープを絞った GitHub トークン

触れないものは、壊せません。

pic6. Viktor のハーネス

5. Evals engineering（Evals エンジニアリング）

定義

新入社員が成長したと、どうやってわかりますか？ 先月と同じテストを受けさせ、比較するはずです。

同じテストがなければ、あなたが加えるすべての変更は推測にすぎません。Evals とはエージェントにとってのそのテストであり、「すでに正解がわかっているタスク群」を、何かを変更するたびに実行する仕組みです。

仕組み

チェックには 2 種類あります。

• エンドツーエンド。 最終的な回答は正しかったか？ スコアが変わったことはわかっても、理由はわかりません。
• ビヘイビアラル（行動）。 特定の 1 つのアクションは起きたか？ 回答前に検索を呼び出したか。曖昧な依頼に対して明確化のための質問をしたか。完了と言う前に検証したか。

行動チェックは最終回答だけでなく、エージェントが行ったすべてのログである「トレース」に対して実行されます。Google のルールでは、このテストスイートは 5 秒以内に終わらなければなりません。そうすることで、すべての変更に対して実行できるからです。

モデルが採点を行う場合、それは「ジャッジ」と呼ばれ、ジャッジ自身もチェックが必要です。Airbnb では、モデルが生成した参照回答の約 4 分の 3 が、同じ入力でも実行するたびに異なる結果になることがわかりました。自分たちの評価基準が、自らのノイズを測定していたのです。

構築方法

1. 実際の失敗から始める。 実際の実行ログを確認し、何が間違っていたかを見つけ、それぞれをテストケースにします。Airbnb のゴールデンセットは 50〜100 件のサンプルで構成され、失敗例の含入が必須とされています。
2. 1 ケースにつき 1 つの行動チェックを書く。 1 つのケースで確認することは 1 つだけ。
3. ジャッジを検証する。 信頼する前に、サンプルを手作業で採点し、あなたとモデルの判定がどの程度一致するかを確認します。
4. 本番環境からサンプリングする。 Airbnb は毎日ライブトラフィックの 5 % を抽出しています。実際の利用が乖離していくにつれ、評価セットは陳腐化します。

1 つのケースはこれくらい小さくて構いません。

1input: "Refund order #1042, customer says it arrived broken"
2expect:
3  - looks up the order before replying
4  - asks for approval before issuing the refund
5check:
6  - trace has get_order before send_reply
7  - trace has approval_request before refund

全体の合格率ばかり見てはいけません。特定の 1 つの挙動が静かに壊れているのに、全体の数値は上がることがあります。個別のチェック項目を監視してください。

pic7. 質の高い評価ケースはどこから生まれるか

ショートカット

あなたのビジネスにおける「正解」が何かを知っているのはあなただけなので、このレイヤーを製品が肩代わりすることはできません。ただし、手法はそのまま転用できます。

• 2 週間後、正解がわかっている彼の 20 スレッドを選びます。あなたが訂正しなければならなかったものはすべて含めてください。
• 1 ケースにつき 1 つのシンプルなチェックを書きます。すべての数値にソースをリンクしたか、指示が曖昧なときに質問したか、社外に出る前に一時停止したか。
• 変更（新しいスキル、編集した指示、ティアの変更）を加えるたびにセットを再実行します。Smart から Balanced への変更でクレジットは約半分に節約できるので、完全に切り替える前にテストしましょう。
• 週に 1 回、ランダムに 5 スレッドを手作業で採点します。

まとめ

5 つのレイヤー、5 つの問い。Context は「何を見るか」。Loop は「誰が決めるか」。Jev は「低コストな判断」を担います。Harness は「何に触れられ、誰がチェックするか」。Evals は「どうやってそれを知るか」です。

Viktor を使えば、そのうち 3 つ（Context、Loop、Harness）はほぼ組み込まれた状態で提供されます。Jev、Evals、そしてあなたが渡す認証情報は、依然としてあなた自身のエンジニアリング領域です。

今日から始める場合の、各レイヤーにおける最もコスパの良い第一歩は次のとおりです。

• Context： 変わらない指示をシステムプロンプトに移し、二度と変更しない。
• Loop： 放置して実行する前に、ターン数の上限と金額の上限を設定する。
• Jev： エージェントが最も頻繁に判断している事柄について、200 件のサンプルをラベル付けする。
• Harness： 何も削除できないユーザー権限でエージェントを実行する。
• Evals： 直近 5 つの失敗をテストケースとして書き留める。

Viktor を使う場合、同じ 1 日はこうなります。

• Context： 会社の概要を書き、最初のスキルを録画する。
• Loop： すべてのタスクに「完了の定義」を入れ、意図的にティアを選ぶ。
• Jev： ストリームが彼のタスクになる前にフィルターをかける。
• Harness： 読み取り専用かつスコープを絞った認証情報で連携する。
• Evals： 実際の 20 スレッドを保存し、最初のテストセットとする。

これで 1 日分の作業で、5 つすべてをカバーできます。

私の考えでは、もはや難しいのはモデルではありません。その周囲にある 5 つのレイヤーです。ここを正しく設計できれば、人員を増やさずにキャパシティを拡大できます。ほとんどのチームは、最初の 3 つは既製品に任せ、品質を左右する残り 2 つ（低コストな判断と Evals）に自分たちの時間を費やすべきです。

本記事のスポンサーである Viktor に感謝します。

@viktor_com で無料でお試しください。$100 分のクレジット付き、カード登録不要。詳細リンクは私の最初のリプライにあります。

サインアップ時にはコード YARCHI100 をご利用ください。

Paid Partnership