{"content_id":"uxrumphsyw","slug":"prompt-context-harness-agentic-loop-engineering","locale":"ja","schema_type":"TechArticle","category":"comparison","category_name":"比較","title":"プロンプト・コンテキスト・ハーネス・エージェンティック・ループエンジニアリングの違いと設計法","summary":"プロンプト・コンテキスト・ハーネス・エージェンティック・ループエンジニアリングは、それぞれ指示、情報、作業環境、自律的実行、反復的改善を扱う。この記事では、5つの方式の境界と結合構造、適用順序、検証指標と失敗防止法を実務の観点から説明する。","author":{"name":"Injoys 編集部","url":"https://injoys.com/ko/about"},"key_points":["プロンプトエンジニアリングは、目標、制約、例、出力契約と成功基準を明確にする作業である。","コンテキストエンジニアリングは、AIが現在の判断に使う情報の関連性、最新性、出典とトークン効率を管理する。","ハーネスエンジニアリングは、ツール、権限、サンドボックス、文書構造、検証器とログを通じて、AIが安定して作業できる環境を作る。","エージェンティックエンジニアリングは、目標達成のための次の行動とツール選択をAIに限定的に委任する。","ループエンジニアリングは、生成、検証、原因分析、修正、再実行と終了条件をつなげて結果を収束させる。"],"content_markdown":"生成AIの品質を高める作業をすべて「プロンプトをうまく書くこと」とひとまとめにすると、失敗原因を正確に診断しにくい。プロンプト・コンテキスト・ハーネス・エージェンティック・ループエンジニアリングは、互いに置き換わる流行語ではなく、**要求の表現、情報の選択、実行環境、自律的な意思決定、反復的な改善**という異なる制御面を扱う補完的な設計方法である。\n\n## 5つの概念の核心定義\n\n| 区分 | 核心となる質問 | 主な設計対象 | 代表的な成果物 | 代表的な成功基準 |\n|---|---|---|---|---|\n| プロンプトエンジニアリング | AIに仕事をどう指示するか？ | 指示文、制約、例、出力形式 | プロンプトテンプレート、例示入力・出力 | 指示遵守率、形式の正確性、一次結果の品質 |\n| コンテキストエンジニアリング | 今AIに何を見せるか？ | システム指示、検索文書、会話状態、メモリ、ツール結果 | コンテキスト組み立てルール、検索・要約ポリシー | 関連性、最新性、根拠性、トークン効率 |\n| ハーネスエンジニアリング | AIがミスしにくいように、どのような作業環境を作るか？ | ツール、権限、サンドボックス、リポジトリ構造、検証器、ログ | 作業ルール、ツールインターフェース、テスト・CI、ランブック | 再現性、安全性、検証可能性、復旧可能性 |\n| エージェンティックエンジニアリング | 次の行動を誰が、どの範囲で決めるか？ | 目標、計画、ツール選択、状態遷移、委任 | エージェントループ、オーケストレーション、承認ポイント | タスク完了率、適切なツール選択、人間介入率 |\n| ループエンジニアリング | 最初の結果が間違っていたとき、どのように収束させるか？ | 生成、評価、原因分類、修正、再実行、終了条件 | 評価器、回帰テスト、再試行ポリシー、失敗分類 | 一次通過率、復旧率、反復回数、最終通過率 |\n\n5つの概念を一行でつなぐと次のようになる。\n\n**要求を表現する → 必要な情報を見せる → 安全な作業環境を提供する → AIに次の行動を選ばせる → 結果が基準を通過するまで検証し改善する。**\n\n### 用語を解釈するときの注意点\n\nプロンプトエンジニアリングとエージェントは比較的広く使われる用語だが、ハーネスエンジニアリングはまだ使用範囲が文脈によって異なる。ある文章ではモデルを除いたほぼすべての実行レイヤーをハーネスと呼び、別の文章ではコーディングエージェントのユーザーがリポジトリの外側に作るルール・検証・フィードバック構造に絞って説明する。「ループエンジニアリング」も単一の標準によって固定された正式な分類というより、生成と検証を閉じたフィードバック過程として設計するという実務的な名称として理解するほうが正確である。([OpenAI][1])\n\n## 1. プロンプトエンジニアリング：指示の品質を設計する\n\nプロンプトエンジニアリングは、モデルに伝える指示を明確で検証可能なものにする作業である。多くの場合、1回の要求と応答で最も目に見える効果を出すが、システムメッセージやマルチターン会話のルールにも適用される。\n\n良いプロンプトは通常、次の要素を分離する。\n\n- **目標：** 何を完了すべきか\n- **入力：** 分析対象と入力の境界はどこまでか\n- **制約：** してはいけないこと、許容範囲、長さと形式\n- **出力契約：** JSON、表、コードパッチなどの結果構造\n- **成功基準：** 何を満たせば正解と見なすか\n- **不確実性の処理：** 情報が不足している、または衝突しているときどうするか\n- **例：** 期待される行動を示す代表的な入力・出力\n\n実務テンプレートは次のように単純に始められる。\n\n```text\n目標:\n入力:\n制約:\n出力形式:\n成功基準:\n検証方法:\n不確実なときの処理:\n代表例:\n```\n\nプロンプトを磨く前に、成功基準と経験的なテスト方法を先に定義しなければならないという点が重要である。すべての失敗がプロンプト修正で解決されるわけではなく、コスト・遅延時間・ツールエラー・誤った資料選択は別のレイヤーの問題である可能性がある。([Claude Platform Docs][2])\n\n### プロンプトエンジニアリングがうまく解決する問題\n\n- 結果形式が頻繁に崩れる問題\n- 指示の優先順位が曖昧な問題\n- 分類、抽出、変換、要約のように入力と出力が比較的明確な問題\n- 代表例を与えると性能が安定する問題\n\n### プロンプトだけでは解決しにくい問題\n\n- 必要な事実やファイルが入力にない場合\n- 古い文書や互いに矛盾する文書が混ざっている場合\n- 外部システムを安全に照会・修正しなければならない場合\n- 複数段階の実行状態と失敗復旧が必要な場合\n- 結果が正解かどうかを客観的に検査する方法がない場合\n\n## 2. コンテキストエンジニアリング：AIが見る情報を設計する\n\nコンテキストエンジニアリングは、モデルが答えを生成する瞬間に利用できる情報全体を選択・整列・圧縮・更新する作業である。コンテキストにはプロンプトだけでなく、システム指示、ユーザー要求、会話履歴、検索文書、メモリ、ツール説明、ツール実行結果、現在時刻、権限状態と作業進行状態が含まれ得る。\n\nコンテキストウィンドウは有限であるため、「たくさん入れること」ではなく**必要な情報を適時に入れること**が目標だ。Anthropicはコンテキストをエージェントの重要だが有限な資源として説明し、長い相互作用では最小限のツールセット、代表例、ランタイム検索、圧縮とメモリのような戦略を推奨している。([人類学的][3])\n\n### 核心的な設計原則\n\n1. **関連性優先：** 現在の段階に必要な情報だけを入れる。\n2. **出典と最新性：** 文書の作成時点、バージョン、所有者、信頼度を一緒に管理する。\n3. **即時検索：** すべての資料を事前に注入するより、必要なときにファイル・DB・検索システムから取得する。\n4. **情報の階層化：** 固定ルール、現在のタスク、参考資料、ツール結果を区別する。\n5. **衝突処理：** 複数の資料が異なる場合、優先順位と基準となる原本を明示する。\n6. **圧縮と状態保持：** 古い会話は要約するが、決定、未解決問題、根拠リンクは失わない。\n7. **指示とデータの分離：** Webページや文書内の文章をシステム命令のように扱わないよう境界を置く。\n\n### 例\n\n顧客サポートAIが返金ポリシーについて答えるとき、単に「正確に答えよ」というプロンプトだけを強化しても限界がある。適切なコンテキストエンジニアリングは、顧客の国、購入日、商品タイプ、現在のポリシーバージョン、例外条項、注文状態を必要な瞬間に照会して一緒に提供し、回答に使用したポリシー条項を追跡可能にする。\n\n## 3. ハーネスエンジニアリング：AIが働く環境を設計する\n\nハーネスは、モデルの知能を実際の業務につなぐ実行の骨格である。ハーネスエンジニアリングは、AIがよく起こすミスを文書、ツール、権限、構造、自動検証とフィードバックによって予防したり早期に発見したりできるよう、作業環境を設計することである。\n\n### ハーネスの主な構成要素\n\n| 構成要素 | 役割 | 例 |\n|---|---|---|\n| 作業指示 | 反復業務の手順と禁止事項を明示 | `AGENTS.md`、ランブック、チェックリスト |\n| 知識構造 | AIが必要な資料を見つけやすくする | リポジトリマップ、ADR、用語集、例の集合 |\n| ツールインターフェース | 行動の入力・出力を明確に制限 | ファイル検索、DB照会、コード実行、デプロイAPI |\n| 実行環境 | 失敗を隔離し再現性を高める | サンドボックス、コンテナ、固定依存関係 |\n| 検証器 | 結果が基準を満たすか自動確認 | スキーマ検査、単体テスト、リンター、ポリシー検査 |\n| 権限・承認 | 危険な行動を制限 | 最小権限、読み取り/書き込み分離、人間の承認 |\n| 観測性 | 何を見てどの行動をしたかを記録 | トレース、ログ、ツール呼び出し記録、コスト |\n| 復旧構造 | 失敗後に安全に戻して再開 | チェックポイント、ロールバック、再試行予算 |\n\nOpenAIのハーネスエンジニアリング事例は、エンジニアの役割を単なるコード作成よりも、環境、意図、リポジトリ知識、テスト・検証・レビュー・復旧ループを設計する方向として説明している。核心は、AIに「もっと頑張れ」と再要求することではなく、不足していた能力と信号を環境に明示的に追加することである。([OpenAI][1])\n\n### 資料構造の例\n\n```text\n/ai\n  /instructions   # 共通ルールと役割別指示\n  /skills         # 反復作業手順\n  /examples       # 良い結果と悪い結果\n  /evals          # 評価データと採点ルール\n  /policies       # 権限、セキュリティ、承認ポリシー\n  /runbooks       # 障害・例外対応\n```\n\nこの構造自体が正解ではない。重要なのは、資料が最新状態に保たれ、重複・衝突が少なく、AIが必要な時点で見つけられ、ルールが自動検査につながるかどうかである。\n\n## 4. エージェンティックエンジニアリング：目標とツールを与えて次の行動を委任する\n\nエージェンティックエンジニアリングは、AIに目標、ツール、作業状態と境界条件を与え、目標を達成するための次の段階を一定の範囲で自ら選ばせる設計である。\n\nAnthropicは**ワークフロー**を、あらかじめ定められたコード経路でLLMとツールを調整するシステム、**エージェント**を、モデルが自身の過程とツール使用を動的に決定するシステムとして区別している。OpenAIもエージェントを、LLMがワークフローの実行を管理し、外部システムと相互作用するツールを動的に選択するシステムとして説明している。([人類学的][4])\n\n### 基本エージェントループ\n\n1. 現在の目標と状態を観察する。\n2. 次の下位目標や行動を計画する。\n3. ツールを選択して実行する。\n4. 結果と環境変化を確認する。\n5. 完了、修正、再試行、人間への引き継ぎのいずれかを決定する。\n\n### エージェントが適している場合\n\n- 作業順序が入力ごとに変わる場合\n- 自然言語、文書、コードのような非構造化情報を解釈しなければならない場合\n- 複数のツールを選択的に使わなければならない場合\n- 中間結果を見て計画を変えなければならない場合\n- 失敗原因が多様で、一定水準の復旧が可能な場合\n\n### エージェントが過剰な場合\n\n- ルールと順序が固定された単純な自動化\n- 単一のAPI呼び出しやSQLで確実に解決できる業務\n- 検証手段がなく、エラーコストが非常に大きい業務\n- 決済、削除、デプロイのように戻しにくい行動を承認なしに実行する構造\n- 単一エージェントで十分なのに役割だけを増やしたマルチエージェント構造\n\n自律性は二分法ではない。推薦だけを行う補助型、制限された読み取り・書き込みだけを許可した実行型、主要段階ごとに承認を受ける監督型、低リスク範囲で長時間動作する高自律型に分けられる。業務リスクと検証能力に合わせて段階的に拡張しなければならない。\n\n## 5. ループエンジニアリング：検証可能な改善過程を設計する\n\nループエンジニアリングは単純な再試行ではない。**生成 → 検証 → 失敗原因分析 → 修正戦略選択 → 再実行 → 終了判断**を明示的な閉じたフィードバックシステムにすることである。\n\n### 適切なループの構成\n\n1. **候補生成：** 草案、コード、計画、データ変換結果を作る。\n2. **検証：** テスト、スキーマ、参照データ、ポリシー、根拠検査を実行する。\n3. **原因分類：** 指示エラー、コンテキスト欠落、ツール失敗、実装欠陥、評価器欠陥を区別する。\n4. **修正：** 失敗原因に合う最小変更を適用する。\n5. **再実行：** 全体を最初から繰り返さず、必要な段階から再び実行する。\n6. **終了：** 通過、最大反復回数、コスト上限、時間上限、不確実性しきい値のいずれかで止める。\n7. **回帰保護：** 新しい修正が既存の成功事例を壊していないか確認する。\n\nエージェント評価は、入力と出力だけを見る単一ターン評価より複雑である。エージェントは何度もツールを呼び出し、環境状態を変えるため、最終結果だけでなく過程と環境変化も一緒に検査しなければならない。自動評価の核心は、入力を与え、出力または変更された状態に採点ロジックを適用することである。([人類学的][5])\n\n### 検証器の優先順位\n\n- **決定的検証：** コンパイル、単体テスト、スキーマ、数学的制約、権限検査\n- **参照ベース検証：** 基準データ、原文引用、データベース照合\n- **ルールベース検証：** 禁止語、必須フィールド、ポリシー条件\n- **モデルベース評価：** 文体、意味保存、総合品質のようにルール化が難しい項目\n- **人間評価：** 高リスク判断、目標そのものの妥当性、例外承認\n\n可能であれば決定的検証を先に使用し、モデル評価だけで自分の結果を自分で採点させない。モデル評価を使うときは、評価基準、例、バイアス点検、サンプルの人間レビューを一緒に置く。\n\n## 5つの方式はレイヤーであり代替材ではない\n\n実際のシステムでは、5つの方式が一緒に作動する。\n\n- プロンプトは**現在の行動の契約**を作る。\n- コンテキストは**判断に必要な状態と根拠**を提供する。\n- ハーネスは**行動可能な環境と安全装置**を提供する。\n- エージェンティック設計は**次の行動の選択権**を配分する。\n- ループ設計は**エラーを発見し品質を収束**させる。\n\nしたがって、「コンテキストエンジニアリングがプロンプトエンジニアリングを置き換えた」あるいは「エージェントを使えばワークフローは不要だ」という理解は不正確である。より広いレイヤーが狭いレイヤーを含む、または活用するだけであり、単純な問題には単純な設計のほうが安定的である場合がある。\n\n## 実務例：バグを修正するAIコーディングシステム\n\n「ログイン後、特定のユーザーだけ500エラーが発生する」というバグをAIが修正すると仮定してみよう。\n\n### プロンプトエンジニアリング\n\n- エラー再現条件を確認せよ。\n- 公開APIは変更するな。\n- 最小修正で解決せよ。\n- 修正後、テスト結果と残るリスクを報告せよ。\n\n### コンテキストエンジニアリング\n\n- イシュー説明とエラーログ\n- 関連リクエストトレースID\n- 認証・ユーザーモデル関連ファイル\n- 最近の変更履歴\n- アーキテクチャルールとコーディング標準\n- 失敗したテストと実行環境情報\n\n### ハーネスエンジニアリング\n\n- リポジトリ検索、ファイル読み取り・編集、テスト実行ツール\n- 隔離されたブランチとサンドボックス\n- フォーマッター、リンター、単体・統合テスト\n- 変更禁止領域と権限ポリシー\n- すべてのコマンドとファイル変更のログ\n- 失敗時のロールバックとチェックポイント\n\n### エージェンティックエンジニアリング\n\nAIが再現、仮説立案、関連コード探索、パッチ、テスト、結果要約の順序を状況に応じて選択する。ただし、デプロイやデータ変更は人間の承認を要求する。\n\n### ループエンジニアリング\n\nテストが失敗したら、同じコマンドを繰り返す代わりに失敗タイプを分類する。再現失敗ならコンテキスト収集を補完し、回帰失敗ならパッチを小さくし、環境エラーなら依存関係と設定を復旧する。すべての必須テストが通過し、変更根拠が残れば終了する。\n\n## 問題の症状から、どのエンジニアリングが必要かを見つける方法\n\n| 症状 | 優先的に点検する領域 |\n|---|---|\n| 出力形式や文体が頻繁にずれる | プロンプト |\n| 回答に必要な事実・ファイルが抜ける | コンテキスト |\n| ツールを誤って選んだり危険なコマンドを実行したりする | ハーネスと権限設計 |\n| 固定順序では処理しにくい変形が多い | エージェンティック設計 |\n| 最初の結果はよく間違うが自動判定は可能 | ループと評価器 |\n| 失敗原因が分からず再現が難しい | ハーネスの観測性 |\n| 繰り返すほどコストだけが増え品質が改善しない | 原因分類、検証信号、終了条件 |\n| 資料が多いほどむしろ答えが悪くなる | コンテキスト整理と検索ポリシー |\n\n## 推奨構築順序\n\n### 1段階：成功基準と評価セットを先に作る\n\n代表業務、難しい事例、禁止事例を集め、結果をどう判定するか定義する。正解データがなければ、少なくともスキーマ、必須根拠、ポリシー遵守、人間評価基準を作る。\n\n### 2段階：単一呼び出しの基準線を作る\n\n最も単純なプロンプトと必要最小限のコンテキストで、性能、コスト、遅延時間を測定する。基準線なしにエージェントを導入すると、複雑性の効果を区別しにくい。\n\n### 3段階：コンテキスト供給を計測する\n\nどの文書とツール結果が入ったのか、どれくらい古いのか、実際の回答に使われたのかを記録する。検索失敗と過度なコンテキストを区別する。\n\n### 4段階：最小ハーネスを作る\n\nツール数を減らし、名前と入力を明確にする。サンドボックス、最小権限、自動テスト、ログ、チェックポイントを優先する。\n\n### 5段階：制限された自律性を付与する\n\n単一エージェントに、読み取り中心の低リスク業務から実行させる。終了条件と人間への引き継ぎ条件を明示し、書き込み・削除・決済・デプロイ権限は別途承認する。\n\n### 6段階：検証・復旧ループを閉じる\n\n失敗分類、修正戦略、最大反復回数、コスト上限、回帰テストをつなぐ。成功率が安定してからのみ、ツールと自律範囲を広げる。\n\n## 運用指標\n\n普遍的な目標値はないため、業務リスクとコストに合わせて基準を定めなければならない。\n\n| 指標 | 意味 |\n|---|---|\n| タスク完了率 | 最終成功基準を満たした比率 |\n| 一次通過率 | 反復修正なしに最初から通過した比率 |\n| 復旧率 | 最初の失敗後、ループを通じて成功した比率 |\n| 平均反復回数 | 成功または中断までに必要なサイクル数 |\n| ツール選択エラー率 | 不適切または不要なツール呼び出しの比率 |\n| 根拠完全性 | 核心的な主張に追跡可能な出典がある比率 |\n| 人間介入率 | 承認、修正、再指示が必要だった比率 |\n| 単位成功あたりのコスト・遅延 | 成功したタスク1つを完了するのに使った資源 |\n| 安全インシデント数 | 権限違反、誤った書き込み、不可逆行動の発生数 |\n| 回帰失敗率 | 新しい変更が既存の成功事例を壊した比率 |\n\n## よく発生する設計ミス\n\n| 領域 | ミス | 改善方法 |\n|---|---|---|\n| プロンプト | すべての例外を1文に積み重ねる | ルールを構造化し、代表例と評価を分離する |\n| プロンプト | 成功基準なしに「うまく作成せよ」と指示する | 形式、必須内容、禁止事項、判定基準を明示する |\n| コンテキスト | 関係ない文書をすべて入れる | ランタイム検索と段階別コンテキストを使う |\n| コンテキスト | 古いポリシーと最新ポリシーを一緒に提供する | バージョン・有効日・基準原本を管理する |\n| ハーネス | 機能が重複するツールを多く提供する | 最小ツールセットと明確なパラメータを設計する |\n| ハーネス | 書き込み権限と戻す機能がない | 最小権限、サンドボックス、チェックポイントを置く |\n| エージェンティック | 最初からマルチエージェントを作る | 単一エージェントと決定的ワークフローから検証する |\n| エージェンティック | 完了条件なしに実行し続けさせる | 明示的な終了・予算・引き継ぎ条件を置く |\n| ループ | 同じ要求をそのまま繰り返す | 失敗原因を分類し、修正箇所を変える |\n| ループ | 生成モデル1つですべての結果を自己評価する | 決定的検査、参照照合、人間によるサンプルレビューを組み合わせる |\n\n## 実装チェックリスト\n\n- [ ] 成功条件は文章だけでなく、可能な範囲で機械的に検査可能か？\n- [ ] プロンプト、参考資料、ツール結果の優先順位が分離されているか？\n- [ ] 文書の出典、バージョン、有効日と所有者を追跡できるか？\n- [ ] ツール名とパラメータが互いに重複せず明確か？\n- [ ] 読み取り、書き込み、削除、決済、デプロイ権限がリスク別に分離されているか？\n- [ ] 失敗を隔離するサンドボックスと戻す手段があるか？\n- [ ] すべての重要な行動とツール呼び出しを再現可能な形で記録しているか？\n- [ ] テスト、スキーマ、ポリシー検査などの外部検証器があるか？\n- [ ] 最大反復回数、コスト、時間、人間への引き継ぎ条件が定義されているか？\n- [ ] 新しい改善が既存事例を壊さない回帰評価があるか？\n\n## 結論\n\n良いAIシステムは、最も長いプロンプトを持つシステムではない。失敗が**指示**、**情報**、**環境**、**意思決定**、**検証・復旧**のどこで発生したのかを区別し、そのレイヤーに最も単純な解決策を配置したシステムである。まず成功基準と単一呼び出しの基準線を作り、必要な分だけコンテキストとハーネスを補強したうえで、検証可能な範囲で自律性と反復ループを拡張することが安定したアプローチである。","content_html":"\u003cp\u003e生成AIの品質を高める作業をすべて「プロンプトをうまく書くこと」とひとまとめにすると、失敗原因を正確に診断しにくい。プロンプト・コンテキスト・ハーネス・エージェンティック・ループエンジニアリングは、互いに置き換わる流行語ではなく、\u003cstrong\u003e要求の表現、情報の選択、実行環境、自律的な意思決定、反復的な改善\u003c/strong\u003eという異なる制御面を扱う補完的な設計方法である。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5つの概念の核心定義\" class=\"anchor\" id=\"5つの概念の核心定義\"\u003e\u003c/a\u003e5つの概念の核心定義\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e区分\u003c/th\u003e\n\u003cth\u003e核心となる質問\u003c/th\u003e\n\u003cth\u003e主な設計対象\u003c/th\u003e\n\u003cth\u003e代表的な成果物\u003c/th\u003e\n\u003cth\u003e代表的な成功基準\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eプロンプトエンジニアリング\u003c/td\u003e\n\u003ctd\u003eAIに仕事をどう指示するか？\u003c/td\u003e\n\u003ctd\u003e指示文、制約、例、出力形式\u003c/td\u003e\n\u003ctd\u003eプロンプトテンプレート、例示入力・出力\u003c/td\u003e\n\u003ctd\u003e指示遵守率、形式の正確性、一次結果の品質\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eコンテキストエンジニアリング\u003c/td\u003e\n\u003ctd\u003e今AIに何を見せるか？\u003c/td\u003e\n\u003ctd\u003eシステム指示、検索文書、会話状態、メモリ、ツール結果\u003c/td\u003e\n\u003ctd\u003eコンテキスト組み立てルール、検索・要約ポリシー\u003c/td\u003e\n\u003ctd\u003e関連性、最新性、根拠性、トークン効率\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eハーネスエンジニアリング\u003c/td\u003e\n\u003ctd\u003eAIがミスしにくいように、どのような作業環境を作るか？\u003c/td\u003e\n\u003ctd\u003eツール、権限、サンドボックス、リポジトリ構造、検証器、ログ\u003c/td\u003e\n\u003ctd\u003e作業ルール、ツールインターフェース、テスト・CI、ランブック\u003c/td\u003e\n\u003ctd\u003e再現性、安全性、検証可能性、復旧可能性\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eエージェンティックエンジニアリング\u003c/td\u003e\n\u003ctd\u003e次の行動を誰が、どの範囲で決めるか？\u003c/td\u003e\n\u003ctd\u003e目標、計画、ツール選択、状態遷移、委任\u003c/td\u003e\n\u003ctd\u003eエージェントループ、オーケストレーション、承認ポイント\u003c/td\u003e\n\u003ctd\u003eタスク完了率、適切なツール選択、人間介入率\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eループエンジニアリング\u003c/td\u003e\n\u003ctd\u003e最初の結果が間違っていたとき、どのように収束させるか？\u003c/td\u003e\n\u003ctd\u003e生成、評価、原因分類、修正、再実行、終了条件\u003c/td\u003e\n\u003ctd\u003e評価器、回帰テスト、再試行ポリシー、失敗分類\u003c/td\u003e\n\u003ctd\u003e一次通過率、復旧率、反復回数、最終通過率\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e5つの概念を一行でつなぐと次のようになる。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e要求を表現する → 必要な情報を見せる → 安全な作業環境を提供する → AIに次の行動を選ばせる → 結果が基準を通過するまで検証し改善する。\u003c/strong\u003e\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#用語を解釈するときの注意点\" class=\"anchor\" id=\"用語を解釈するときの注意点\"\u003e\u003c/a\u003e用語を解釈するときの注意点\u003c/h3\u003e\n\u003cp\u003eプロンプトエンジニアリングとエージェントは比較的広く使われる用語だが、ハーネスエンジニアリングはまだ使用範囲が文脈によって異なる。ある文章ではモデルを除いたほぼすべての実行レイヤーをハーネスと呼び、別の文章ではコーディングエージェントのユーザーがリポジトリの外側に作るルール・検証・フィードバック構造に絞って説明する。「ループエンジニアリング」も単一の標準によって固定された正式な分類というより、生成と検証を閉じたフィードバック過程として設計するという実務的な名称として理解するほうが正確である。([OpenAI][1])\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-プロンプトエンジニアリング指示の品質を設計する\" class=\"anchor\" id=\"1-プロンプトエンジニアリング指示の品質を設計する\"\u003e\u003c/a\u003e1. プロンプトエンジニアリング：指示の品質を設計する\u003c/h2\u003e\n\u003cp\u003eプロンプトエンジニアリングは、モデルに伝える指示を明確で検証可能なものにする作業である。多くの場合、1回の要求と応答で最も目に見える効果を出すが、システムメッセージやマルチターン会話のルールにも適用される。\u003c/p\u003e\n\u003cp\u003e良いプロンプトは通常、次の要素を分離する。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e目標：\u003c/strong\u003e 何を完了すべきか\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e入力：\u003c/strong\u003e 分析対象と入力の境界はどこまでか\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e制約：\u003c/strong\u003e してはいけないこと、許容範囲、長さと形式\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e出力契約：\u003c/strong\u003e JSON、表、コードパッチなどの結果構造\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e成功基準：\u003c/strong\u003e 何を満たせば正解と見なすか\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e不確実性の処理：\u003c/strong\u003e 情報が不足している、または衝突しているときどうするか\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e例：\u003c/strong\u003e 期待される行動を示す代表的な入力・出力\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e実務テンプレートは次のように単純に始められる。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e目標:\n\u003c/span\u003e\u003cspan\u003e入力:\n\u003c/span\u003e\u003cspan\u003e制約:\n\u003c/span\u003e\u003cspan\u003e出力形式:\n\u003c/span\u003e\u003cspan\u003e成功基準:\n\u003c/span\u003e\u003cspan\u003e検証方法:\n\u003c/span\u003e\u003cspan\u003e不確実なときの処理:\n\u003c/span\u003e\u003cspan\u003e代表例:\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eプロンプトを磨く前に、成功基準と経験的なテスト方法を先に定義しなければならないという点が重要である。すべての失敗がプロンプト修正で解決されるわけではなく、コスト・遅延時間・ツールエラー・誤った資料選択は別のレイヤーの問題である可能性がある。([Claude Platform Docs][2])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#プロンプトエンジニアリングがうまく解決する問題\" class=\"anchor\" id=\"プロンプトエンジニアリングがうまく解決する問題\"\u003e\u003c/a\u003eプロンプトエンジニアリングがうまく解決する問題\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e結果形式が頻繁に崩れる問題\u003c/li\u003e\n\u003cli\u003e指示の優先順位が曖昧な問題\u003c/li\u003e\n\u003cli\u003e分類、抽出、変換、要約のように入力と出力が比較的明確な問題\u003c/li\u003e\n\u003cli\u003e代表例を与えると性能が安定する問題\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#プロンプトだけでは解決しにくい問題\" class=\"anchor\" id=\"プロンプトだけでは解決しにくい問題\"\u003e\u003c/a\u003eプロンプトだけでは解決しにくい問題\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e必要な事実やファイルが入力にない場合\u003c/li\u003e\n\u003cli\u003e古い文書や互いに矛盾する文書が混ざっている場合\u003c/li\u003e\n\u003cli\u003e外部システムを安全に照会・修正しなければならない場合\u003c/li\u003e\n\u003cli\u003e複数段階の実行状態と失敗復旧が必要な場合\u003c/li\u003e\n\u003cli\u003e結果が正解かどうかを客観的に検査する方法がない場合\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\u003ca href=\"#2-コンテキストエンジニアリングaiが見る情報を設計する\" class=\"anchor\" id=\"2-コンテキストエンジニアリングaiが見る情報を設計する\"\u003e\u003c/a\u003e2. コンテキストエンジニアリング：AIが見る情報を設計する\u003c/h2\u003e\n\u003cp\u003eコンテキストエンジニアリングは、モデルが答えを生成する瞬間に利用できる情報全体を選択・整列・圧縮・更新する作業である。コンテキストにはプロンプトだけでなく、システム指示、ユーザー要求、会話履歴、検索文書、メモリ、ツール説明、ツール実行結果、現在時刻、権限状態と作業進行状態が含まれ得る。\u003c/p\u003e\n\u003cp\u003eコンテキストウィンドウは有限であるため、「たくさん入れること」ではなく\u003cstrong\u003e必要な情報を適時に入れること\u003c/strong\u003eが目標だ。Anthropicはコンテキストをエージェントの重要だが有限な資源として説明し、長い相互作用では最小限のツールセット、代表例、ランタイム検索、圧縮とメモリのような戦略を推奨している。([人類学的][3])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#核心的な設計原則\" class=\"anchor\" id=\"核心的な設計原則\"\u003e\u003c/a\u003e核心的な設計原則\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e関連性優先：\u003c/strong\u003e 現在の段階に必要な情報だけを入れる。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e出典と最新性：\u003c/strong\u003e 文書の作成時点、バージョン、所有者、信頼度を一緒に管理する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e即時検索：\u003c/strong\u003e すべての資料を事前に注入するより、必要なときにファイル・DB・検索システムから取得する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e情報の階層化：\u003c/strong\u003e 固定ルール、現在のタスク、参考資料、ツール結果を区別する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e衝突処理：\u003c/strong\u003e 複数の資料が異なる場合、優先順位と基準となる原本を明示する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e圧縮と状態保持：\u003c/strong\u003e 古い会話は要約するが、決定、未解決問題、根拠リンクは失わない。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e指示とデータの分離：\u003c/strong\u003e Webページや文書内の文章をシステム命令のように扱わないよう境界を置く。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#例\" class=\"anchor\" id=\"例\"\u003e\u003c/a\u003e例\u003c/h3\u003e\n\u003cp\u003e顧客サポートAIが返金ポリシーについて答えるとき、単に「正確に答えよ」というプロンプトだけを強化しても限界がある。適切なコンテキストエンジニアリングは、顧客の国、購入日、商品タイプ、現在のポリシーバージョン、例外条項、注文状態を必要な瞬間に照会して一緒に提供し、回答に使用したポリシー条項を追跡可能にする。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-ハーネスエンジニアリングaiが働く環境を設計する\" class=\"anchor\" id=\"3-ハーネスエンジニアリングaiが働く環境を設計する\"\u003e\u003c/a\u003e3. ハーネスエンジニアリング：AIが働く環境を設計する\u003c/h2\u003e\n\u003cp\u003eハーネスは、モデルの知能を実際の業務につなぐ実行の骨格である。ハーネスエンジニアリングは、AIがよく起こすミスを文書、ツール、権限、構造、自動検証とフィードバックによって予防したり早期に発見したりできるよう、作業環境を設計することである。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#ハーネスの主な構成要素\" class=\"anchor\" id=\"ハーネスの主な構成要素\"\u003e\u003c/a\u003eハーネスの主な構成要素\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e構成要素\u003c/th\u003e\n\u003cth\u003e役割\u003c/th\u003e\n\u003cth\u003e例\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e作業指示\u003c/td\u003e\n\u003ctd\u003e反復業務の手順と禁止事項を明示\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003eAGENTS.md\u003c/code\u003e、ランブック、チェックリスト\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e知識構造\u003c/td\u003e\n\u003ctd\u003eAIが必要な資料を見つけやすくする\u003c/td\u003e\n\u003ctd\u003eリポジトリマップ、ADR、用語集、例の集合\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eツールインターフェース\u003c/td\u003e\n\u003ctd\u003e行動の入力・出力を明確に制限\u003c/td\u003e\n\u003ctd\u003eファイル検索、DB照会、コード実行、デプロイAPI\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e実行環境\u003c/td\u003e\n\u003ctd\u003e失敗を隔離し再現性を高める\u003c/td\u003e\n\u003ctd\u003eサンドボックス、コンテナ、固定依存関係\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e検証器\u003c/td\u003e\n\u003ctd\u003e結果が基準を満たすか自動確認\u003c/td\u003e\n\u003ctd\u003eスキーマ検査、単体テスト、リンター、ポリシー検査\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e権限・承認\u003c/td\u003e\n\u003ctd\u003e危険な行動を制限\u003c/td\u003e\n\u003ctd\u003e最小権限、読み取り/書き込み分離、人間の承認\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e観測性\u003c/td\u003e\n\u003ctd\u003e何を見てどの行動をしたかを記録\u003c/td\u003e\n\u003ctd\u003eトレース、ログ、ツール呼び出し記録、コスト\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e復旧構造\u003c/td\u003e\n\u003ctd\u003e失敗後に安全に戻して再開\u003c/td\u003e\n\u003ctd\u003eチェックポイント、ロールバック、再試行予算\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eOpenAIのハーネスエンジニアリング事例は、エンジニアの役割を単なるコード作成よりも、環境、意図、リポジトリ知識、テスト・検証・レビュー・復旧ループを設計する方向として説明している。核心は、AIに「もっと頑張れ」と再要求することではなく、不足していた能力と信号を環境に明示的に追加することである。([OpenAI][1])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#資料構造の例\" class=\"anchor\" id=\"資料構造の例\"\u003e\u003c/a\u003e資料構造の例\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/ai\n\u003c/span\u003e\u003cspan\u003e  /instructions   # 共通ルールと役割別指示\n\u003c/span\u003e\u003cspan\u003e  /skills         # 反復作業手順\n\u003c/span\u003e\u003cspan\u003e  /examples       # 良い結果と悪い結果\n\u003c/span\u003e\u003cspan\u003e  /evals          # 評価データと採点ルール\n\u003c/span\u003e\u003cspan\u003e  /policies       # 権限、セキュリティ、承認ポリシー\n\u003c/span\u003e\u003cspan\u003e  /runbooks       # 障害・例外対応\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eこの構造自体が正解ではない。重要なのは、資料が最新状態に保たれ、重複・衝突が少なく、AIが必要な時点で見つけられ、ルールが自動検査につながるかどうかである。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-エージェンティックエンジニアリング目標とツールを与えて次の行動を委任する\" class=\"anchor\" id=\"4-エージェンティックエンジニアリング目標とツールを与えて次の行動を委任する\"\u003e\u003c/a\u003e4. エージェンティックエンジニアリング：目標とツールを与えて次の行動を委任する\u003c/h2\u003e\n\u003cp\u003eエージェンティックエンジニアリングは、AIに目標、ツール、作業状態と境界条件を与え、目標を達成するための次の段階を一定の範囲で自ら選ばせる設計である。\u003c/p\u003e\n\u003cp\u003eAnthropicは\u003cstrong\u003eワークフロー\u003c/strong\u003eを、あらかじめ定められたコード経路でLLMとツールを調整するシステム、\u003cstrong\u003eエージェント\u003c/strong\u003eを、モデルが自身の過程とツール使用を動的に決定するシステムとして区別している。OpenAIもエージェントを、LLMがワークフローの実行を管理し、外部システムと相互作用するツールを動的に選択するシステムとして説明している。([人類学的][4])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#基本エージェントループ\" class=\"anchor\" id=\"基本エージェントループ\"\u003e\u003c/a\u003e基本エージェントループ\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e現在の目標と状態を観察する。\u003c/li\u003e\n\u003cli\u003e次の下位目標や行動を計画する。\u003c/li\u003e\n\u003cli\u003eツールを選択して実行する。\u003c/li\u003e\n\u003cli\u003e結果と環境変化を確認する。\u003c/li\u003e\n\u003cli\u003e完了、修正、再試行、人間への引き継ぎのいずれかを決定する。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#エージェントが適している場合\" class=\"anchor\" id=\"エージェントが適している場合\"\u003e\u003c/a\u003eエージェントが適している場合\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e作業順序が入力ごとに変わる場合\u003c/li\u003e\n\u003cli\u003e自然言語、文書、コードのような非構造化情報を解釈しなければならない場合\u003c/li\u003e\n\u003cli\u003e複数のツールを選択的に使わなければならない場合\u003c/li\u003e\n\u003cli\u003e中間結果を見て計画を変えなければならない場合\u003c/li\u003e\n\u003cli\u003e失敗原因が多様で、一定水準の復旧が可能な場合\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#エージェントが過剰な場合\" class=\"anchor\" id=\"エージェントが過剰な場合\"\u003e\u003c/a\u003eエージェントが過剰な場合\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eルールと順序が固定された単純な自動化\u003c/li\u003e\n\u003cli\u003e単一のAPI呼び出しやSQLで確実に解決できる業務\u003c/li\u003e\n\u003cli\u003e検証手段がなく、エラーコストが非常に大きい業務\u003c/li\u003e\n\u003cli\u003e決済、削除、デプロイのように戻しにくい行動を承認なしに実行する構造\u003c/li\u003e\n\u003cli\u003e単一エージェントで十分なのに役割だけを増やしたマルチエージェント構造\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e自律性は二分法ではない。推薦だけを行う補助型、制限された読み取り・書き込みだけを許可した実行型、主要段階ごとに承認を受ける監督型、低リスク範囲で長時間動作する高自律型に分けられる。業務リスクと検証能力に合わせて段階的に拡張しなければならない。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-ループエンジニアリング検証可能な改善過程を設計する\" class=\"anchor\" id=\"5-ループエンジニアリング検証可能な改善過程を設計する\"\u003e\u003c/a\u003e5. ループエンジニアリング：検証可能な改善過程を設計する\u003c/h2\u003e\n\u003cp\u003eループエンジニアリングは単純な再試行ではない。\u003cstrong\u003e生成 → 検証 → 失敗原因分析 → 修正戦略選択 → 再実行 → 終了判断\u003c/strong\u003eを明示的な閉じたフィードバックシステムにすることである。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#適切なループの構成\" class=\"anchor\" id=\"適切なループの構成\"\u003e\u003c/a\u003e適切なループの構成\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e候補生成：\u003c/strong\u003e 草案、コード、計画、データ変換結果を作る。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e検証：\u003c/strong\u003e テスト、スキーマ、参照データ、ポリシー、根拠検査を実行する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e原因分類：\u003c/strong\u003e 指示エラー、コンテキスト欠落、ツール失敗、実装欠陥、評価器欠陥を区別する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e修正：\u003c/strong\u003e 失敗原因に合う最小変更を適用する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e再実行：\u003c/strong\u003e 全体を最初から繰り返さず、必要な段階から再び実行する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e終了：\u003c/strong\u003e 通過、最大反復回数、コスト上限、時間上限、不確実性しきい値のいずれかで止める。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e回帰保護：\u003c/strong\u003e 新しい修正が既存の成功事例を壊していないか確認する。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eエージェント評価は、入力と出力だけを見る単一ターン評価より複雑である。エージェントは何度もツールを呼び出し、環境状態を変えるため、最終結果だけでなく過程と環境変化も一緒に検査しなければならない。自動評価の核心は、入力を与え、出力または変更された状態に採点ロジックを適用することである。([人類学的][5])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#検証器の優先順位\" class=\"anchor\" id=\"検証器の優先順位\"\u003e\u003c/a\u003e検証器の優先順位\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e決定的検証：\u003c/strong\u003e コンパイル、単体テスト、スキーマ、数学的制約、権限検査\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e参照ベース検証：\u003c/strong\u003e 基準データ、原文引用、データベース照合\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eルールベース検証：\u003c/strong\u003e 禁止語、必須フィールド、ポリシー条件\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eモデルベース評価：\u003c/strong\u003e 文体、意味保存、総合品質のようにルール化が難しい項目\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e人間評価：\u003c/strong\u003e 高リスク判断、目標そのものの妥当性、例外承認\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e可能であれば決定的検証を先に使用し、モデル評価だけで自分の結果を自分で採点させない。モデル評価を使うときは、評価基準、例、バイアス点検、サンプルの人間レビューを一緒に置く。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5つの方式はレイヤーであり代替材ではない\" class=\"anchor\" id=\"5つの方式はレイヤーであり代替材ではない\"\u003e\u003c/a\u003e5つの方式はレイヤーであり代替材ではない\u003c/h2\u003e\n\u003cp\u003e実際のシステムでは、5つの方式が一緒に作動する。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eプロンプトは\u003cstrong\u003e現在の行動の契約\u003c/strong\u003eを作る。\u003c/li\u003e\n\u003cli\u003eコンテキストは\u003cstrong\u003e判断に必要な状態と根拠\u003c/strong\u003eを提供する。\u003c/li\u003e\n\u003cli\u003eハーネスは\u003cstrong\u003e行動可能な環境と安全装置\u003c/strong\u003eを提供する。\u003c/li\u003e\n\u003cli\u003eエージェンティック設計は\u003cstrong\u003e次の行動の選択権\u003c/strong\u003eを配分する。\u003c/li\u003e\n\u003cli\u003eループ設計は\u003cstrong\u003eエラーを発見し品質を収束\u003c/strong\u003eさせる。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eしたがって、「コンテキストエンジニアリングがプロンプトエンジニアリングを置き換えた」あるいは「エージェントを使えばワークフローは不要だ」という理解は不正確である。より広いレイヤーが狭いレイヤーを含む、または活用するだけであり、単純な問題には単純な設計のほうが安定的である場合がある。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#実務例バグを修正するaiコーディングシステム\" class=\"anchor\" id=\"実務例バグを修正するaiコーディングシステム\"\u003e\u003c/a\u003e実務例：バグを修正するAIコーディングシステム\u003c/h2\u003e\n\u003cp\u003e「ログイン後、特定のユーザーだけ500エラーが発生する」というバグをAIが修正すると仮定してみよう。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#プロンプトエンジニアリング\" class=\"anchor\" id=\"プロンプトエンジニアリング\"\u003e\u003c/a\u003eプロンプトエンジニアリング\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eエラー再現条件を確認せよ。\u003c/li\u003e\n\u003cli\u003e公開APIは変更するな。\u003c/li\u003e\n\u003cli\u003e最小修正で解決せよ。\u003c/li\u003e\n\u003cli\u003e修正後、テスト結果と残るリスクを報告せよ。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#コンテキストエンジニアリング\" class=\"anchor\" id=\"コンテキストエンジニアリング\"\u003e\u003c/a\u003eコンテキストエンジニアリング\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eイシュー説明とエラーログ\u003c/li\u003e\n\u003cli\u003e関連リクエストトレースID\u003c/li\u003e\n\u003cli\u003e認証・ユーザーモデル関連ファイル\u003c/li\u003e\n\u003cli\u003e最近の変更履歴\u003c/li\u003e\n\u003cli\u003eアーキテクチャルールとコーディング標準\u003c/li\u003e\n\u003cli\u003e失敗したテストと実行環境情報\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#ハーネスエンジニアリング\" class=\"anchor\" id=\"ハーネスエンジニアリング\"\u003e\u003c/a\u003eハーネスエンジニアリング\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eリポジトリ検索、ファイル読み取り・編集、テスト実行ツール\u003c/li\u003e\n\u003cli\u003e隔離されたブランチとサンドボックス\u003c/li\u003e\n\u003cli\u003eフォーマッター、リンター、単体・統合テスト\u003c/li\u003e\n\u003cli\u003e変更禁止領域と権限ポリシー\u003c/li\u003e\n\u003cli\u003eすべてのコマンドとファイル変更のログ\u003c/li\u003e\n\u003cli\u003e失敗時のロールバックとチェックポイント\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#エージェンティックエンジニアリング\" class=\"anchor\" id=\"エージェンティックエンジニアリング\"\u003e\u003c/a\u003eエージェンティックエンジニアリング\u003c/h3\u003e\n\u003cp\u003eAIが再現、仮説立案、関連コード探索、パッチ、テスト、結果要約の順序を状況に応じて選択する。ただし、デプロイやデータ変更は人間の承認を要求する。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#ループエンジニアリング\" class=\"anchor\" id=\"ループエンジニアリング\"\u003e\u003c/a\u003eループエンジニアリング\u003c/h3\u003e\n\u003cp\u003eテストが失敗したら、同じコマンドを繰り返す代わりに失敗タイプを分類する。再現失敗ならコンテキスト収集を補完し、回帰失敗ならパッチを小さくし、環境エラーなら依存関係と設定を復旧する。すべての必須テストが通過し、変更根拠が残れば終了する。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#問題の症状からどのエンジニアリングが必要かを見つける方法\" class=\"anchor\" id=\"問題の症状からどのエンジニアリングが必要かを見つける方法\"\u003e\u003c/a\u003e問題の症状から、どのエンジニアリングが必要かを見つける方法\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e症状\u003c/th\u003e\n\u003cth\u003e優先的に点検する領域\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e出力形式や文体が頻繁にずれる\u003c/td\u003e\n\u003ctd\u003eプロンプト\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e回答に必要な事実・ファイルが抜ける\u003c/td\u003e\n\u003ctd\u003eコンテキスト\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eツールを誤って選んだり危険なコマンドを実行したりする\u003c/td\u003e\n\u003ctd\u003eハーネスと権限設計\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e固定順序では処理しにくい変形が多い\u003c/td\u003e\n\u003ctd\u003eエージェンティック設計\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e最初の結果はよく間違うが自動判定は可能\u003c/td\u003e\n\u003ctd\u003eループと評価器\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e失敗原因が分からず再現が難しい\u003c/td\u003e\n\u003ctd\u003eハーネスの観測性\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e繰り返すほどコストだけが増え品質が改善しない\u003c/td\u003e\n\u003ctd\u003e原因分類、検証信号、終了条件\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e資料が多いほどむしろ答えが悪くなる\u003c/td\u003e\n\u003ctd\u003eコンテキスト整理と検索ポリシー\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#推奨構築順序\" class=\"anchor\" id=\"推奨構築順序\"\u003e\u003c/a\u003e推奨構築順序\u003c/h2\u003e\n\u003ch3\u003e\u003ca href=\"#1段階成功基準と評価セットを先に作る\" class=\"anchor\" id=\"1段階成功基準と評価セットを先に作る\"\u003e\u003c/a\u003e1段階：成功基準と評価セットを先に作る\u003c/h3\u003e\n\u003cp\u003e代表業務、難しい事例、禁止事例を集め、結果をどう判定するか定義する。正解データがなければ、少なくともスキーマ、必須根拠、ポリシー遵守、人間評価基準を作る。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#2段階単一呼び出しの基準線を作る\" class=\"anchor\" id=\"2段階単一呼び出しの基準線を作る\"\u003e\u003c/a\u003e2段階：単一呼び出しの基準線を作る\u003c/h3\u003e\n\u003cp\u003e最も単純なプロンプトと必要最小限のコンテキストで、性能、コスト、遅延時間を測定する。基準線なしにエージェントを導入すると、複雑性の効果を区別しにくい。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#3段階コンテキスト供給を計測する\" class=\"anchor\" id=\"3段階コンテキスト供給を計測する\"\u003e\u003c/a\u003e3段階：コンテキスト供給を計測する\u003c/h3\u003e\n\u003cp\u003eどの文書とツール結果が入ったのか、どれくらい古いのか、実際の回答に使われたのかを記録する。検索失敗と過度なコンテキストを区別する。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#4段階最小ハーネスを作る\" class=\"anchor\" id=\"4段階最小ハーネスを作る\"\u003e\u003c/a\u003e4段階：最小ハーネスを作る\u003c/h3\u003e\n\u003cp\u003eツール数を減らし、名前と入力を明確にする。サンドボックス、最小権限、自動テスト、ログ、チェックポイントを優先する。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#5段階制限された自律性を付与する\" class=\"anchor\" id=\"5段階制限された自律性を付与する\"\u003e\u003c/a\u003e5段階：制限された自律性を付与する\u003c/h3\u003e\n\u003cp\u003e単一エージェントに、読み取り中心の低リスク業務から実行させる。終了条件と人間への引き継ぎ条件を明示し、書き込み・削除・決済・デプロイ権限は別途承認する。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#6段階検証復旧ループを閉じる\" class=\"anchor\" id=\"6段階検証復旧ループを閉じる\"\u003e\u003c/a\u003e6段階：検証・復旧ループを閉じる\u003c/h3\u003e\n\u003cp\u003e失敗分類、修正戦略、最大反復回数、コスト上限、回帰テストをつなぐ。成功率が安定してからのみ、ツールと自律範囲を広げる。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#運用指標\" class=\"anchor\" id=\"運用指標\"\u003e\u003c/a\u003e運用指標\u003c/h2\u003e\n\u003cp\u003e普遍的な目標値はないため、業務リスクとコストに合わせて基準を定めなければならない。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e指標\u003c/th\u003e\n\u003cth\u003e意味\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eタスク完了率\u003c/td\u003e\n\u003ctd\u003e最終成功基準を満たした比率\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e一次通過率\u003c/td\u003e\n\u003ctd\u003e反復修正なしに最初から通過した比率\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e復旧率\u003c/td\u003e\n\u003ctd\u003e最初の失敗後、ループを通じて成功した比率\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e平均反復回数\u003c/td\u003e\n\u003ctd\u003e成功または中断までに必要なサイクル数\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eツール選択エラー率\u003c/td\u003e\n\u003ctd\u003e不適切または不要なツール呼び出しの比率\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e根拠完全性\u003c/td\u003e\n\u003ctd\u003e核心的な主張に追跡可能な出典がある比率\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e人間介入率\u003c/td\u003e\n\u003ctd\u003e承認、修正、再指示が必要だった比率\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e単位成功あたりのコスト・遅延\u003c/td\u003e\n\u003ctd\u003e成功したタスク1つを完了するのに使った資源\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e安全インシデント数\u003c/td\u003e\n\u003ctd\u003e権限違反、誤った書き込み、不可逆行動の発生数\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e回帰失敗率\u003c/td\u003e\n\u003ctd\u003e新しい変更が既存の成功事例を壊した比率\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#よく発生する設計ミス\" class=\"anchor\" id=\"よく発生する設計ミス\"\u003e\u003c/a\u003eよく発生する設計ミス\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e領域\u003c/th\u003e\n\u003cth\u003eミス\u003c/th\u003e\n\u003cth\u003e改善方法\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eプロンプト\u003c/td\u003e\n\u003ctd\u003eすべての例外を1文に積み重ねる\u003c/td\u003e\n\u003ctd\u003eルールを構造化し、代表例と評価を分離する\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eプロンプト\u003c/td\u003e\n\u003ctd\u003e成功基準なしに「うまく作成せよ」と指示する\u003c/td\u003e\n\u003ctd\u003e形式、必須内容、禁止事項、判定基準を明示する\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eコンテキスト\u003c/td\u003e\n\u003ctd\u003e関係ない文書をすべて入れる\u003c/td\u003e\n\u003ctd\u003eランタイム検索と段階別コンテキストを使う\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eコンテキスト\u003c/td\u003e\n\u003ctd\u003e古いポリシーと最新ポリシーを一緒に提供する\u003c/td\u003e\n\u003ctd\u003eバージョン・有効日・基準原本を管理する\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eハーネス\u003c/td\u003e\n\u003ctd\u003e機能が重複するツールを多く提供する\u003c/td\u003e\n\u003ctd\u003e最小ツールセットと明確なパラメータを設計する\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eハーネス\u003c/td\u003e\n\u003ctd\u003e書き込み権限と戻す機能がない\u003c/td\u003e\n\u003ctd\u003e最小権限、サンドボックス、チェックポイントを置く\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eエージェンティック\u003c/td\u003e\n\u003ctd\u003e最初からマルチエージェントを作る\u003c/td\u003e\n\u003ctd\u003e単一エージェントと決定的ワークフローから検証する\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eエージェンティック\u003c/td\u003e\n\u003ctd\u003e完了条件なしに実行し続けさせる\u003c/td\u003e\n\u003ctd\u003e明示的な終了・予算・引き継ぎ条件を置く\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eループ\u003c/td\u003e\n\u003ctd\u003e同じ要求をそのまま繰り返す\u003c/td\u003e\n\u003ctd\u003e失敗原因を分類し、修正箇所を変える\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eループ\u003c/td\u003e\n\u003ctd\u003e生成モデル1つですべての結果を自己評価する\u003c/td\u003e\n\u003ctd\u003e決定的検査、参照照合、人間によるサンプルレビューを組み合わせる\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#実装チェックリスト\" class=\"anchor\" id=\"実装チェックリスト\"\u003e\u003c/a\u003e実装チェックリスト\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e 成功条件は文章だけでなく、可能な範囲で機械的に検査可能か？\u003c/li\u003e\n\u003cli\u003e プロンプト、参考資料、ツール結果の優先順位が分離されているか？\u003c/li\u003e\n\u003cli\u003e 文書の出典、バージョン、有効日と所有者を追跡できるか？\u003c/li\u003e\n\u003cli\u003e ツール名とパラメータが互いに重複せず明確か？\u003c/li\u003e\n\u003cli\u003e 読み取り、書き込み、削除、決済、デプロイ権限がリスク別に分離されているか？\u003c/li\u003e\n\u003cli\u003e 失敗を隔離するサンドボックスと戻す手段があるか？\u003c/li\u003e\n\u003cli\u003e すべての重要な行動とツール呼び出しを再現可能な形で記録しているか？\u003c/li\u003e\n\u003cli\u003e テスト、スキーマ、ポリシー検査などの外部検証器があるか？\u003c/li\u003e\n\u003cli\u003e 最大反復回数、コスト、時間、人間への引き継ぎ条件が定義されているか？\u003c/li\u003e\n\u003cli\u003e 新しい改善が既存事例を壊さない回帰評価があるか？\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\u003ca href=\"#結論\" class=\"anchor\" id=\"結論\"\u003e\u003c/a\u003e結論\u003c/h2\u003e\n\u003cp\u003e良いAIシステムは、最も長いプロンプトを持つシステムではない。失敗が\u003cstrong\u003e指示\u003c/strong\u003e、\u003cstrong\u003e情報\u003c/strong\u003e、\u003cstrong\u003e環境\u003c/strong\u003e、\u003cstrong\u003e意思決定\u003c/strong\u003e、\u003cstrong\u003e検証・復旧\u003c/strong\u003eのどこで発生したのかを区別し、そのレイヤーに最も単純な解決策を配置したシステムである。まず成功基準と単一呼び出しの基準線を作り、必要な分だけコンテキストとハーネスを補強したうえで、検証可能な範囲で自律性と反復ループを拡張することが安定したアプローチである。\u003c/p\u003e\n","tags":["プロンプトエンジニアリング","コンテキストエンジニアリング","ハーネスエンジニアリング","AIエージェント","AI評価"],"faqs":[{"question":"5つのエンジニアリング手法は必ず順番に導入しなければなりませんか？","answer":"固定された成熟度段階ではない。ただし、成功基準と単一呼び出しのベースラインを作ったうえでプロンプトとコンテキストを整理し、必要に応じてハーネス・自律性・反復ループを追加すれば、複雑性の効果を測定しやすい。"},{"question":"コンテキストエンジニアリングはプロンプトエンジニアリングを代替しますか？","answer":"代替しない。プロンプトは行うべき行動と出力契約を定義し、コンテキストはその行動に必要な事実・状態・根拠を提供する。優れたシステムは両方を一緒に設計する。"},{"question":"コンテキストエンジニアリングとハーネスエンジニアリングの違いは何ですか？","answer":"コンテキストエンジニアリングは、特定の瞬間にモデルが見る情報に焦点を当てる。ハーネスエンジニアリングは、その情報を探し、行動を実行し、結果を検査するツール、権限、実行環境、文書構造、ログと復旧装置まで含む。"},{"question":"エージェントと一般的なワークフロー自動化はどのように違いますか？","answer":"一般的なワークフローは事前に定義された順序と分岐に従う一方、エージェントは現在の状態を解釈して次の行動とツールを動的に選択する。ルールが安定している業務では、決定論的ワークフローのほうが安価で予測可能な場合がある。"},{"question":"ループエンジニアリングは単純な再試行と何が違いますか？","answer":"単純な再試行は同じ条件でもう一度生成するだけだ。ループエンジニアリングは外部の検証信号で失敗を確認し、原因を分類したうえで、プロンプト・コンテキスト・ツール・実装のうち必要な部分を修正し、終了条件と回帰検査を適用する。"},{"question":"いつマルチエージェントを使用すべきですか？","answer":"役割別のツールと権限が明確に異なり、1つのエージェントのコンテキストやツールセットが過度に大きくなって性能と評価が悪化する場合に検討する。単純な役割分担だけのために複数のエージェントを作ると、コスト、遅延、エラーの伝播、デバッグの難度が増加する可能性がある。"},{"question":"AIに自分の結果を評価させてもよいですか？","answer":"補助信号としては使用できるが、唯一の検証器にするのは危険だ。可能であればテスト、スキーマ、参照データ、ポリシールールを先に適用し、モデル評価は明示的なルーブリックと人間によるサンプルレビューで補完すべきだ。"},{"question":"ハーネス文書には何を入れるべきですか？","answer":"繰り返される作業手順、リポジトリとシステム構造、許可・禁止される行動、ツールの使い方、良い例・悪い例、テストコマンド、障害対応、承認ポリシーと完了基準を入れる。文書は短く、検索可能で、バージョン管理されていなければならない。"},{"question":"外部文書をコンテキストに入れるとき、最も重要なセキュリティ原則は何ですか？","answer":"外部文書は信頼できないデータとして扱い、システム指示と分離しなければならない。文書内の命令を実行しないようツール権限を最小化し、重要な書き込み・削除・決済・デプロイの行動には別途ポリシー検査と人間の承認を設ける。"},{"question":"小規模チームはどこから始めるのがよいですか？","answer":"小さな代表評価セットと失敗事例を集め、単一モデル呼び出しのベースラインを測定する。その後、最大の失敗原因が指示、情報、ツール環境、計画、検証のどこにあるのかを確認し、1階層ずつ改善するのが効率的だ。"}],"sources":[{"url":"https://platform.claude.com/docs/ko/build-with-claude/prompt-engineering/overview","title":"プロンプトエンジニアリングの概要 - Claude Platform Docs","type":"source"},{"url":"https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents","title":"AIエージェントのための効果的なコンテキストエンジニアリング","type":"source"},{"url":"https://openai.com/index/harness-engineering/","title":"ハーネスエンジニアリング：エージェントファーストの世界でCodexを活用する","type":"source"},{"url":"https://www.anthropic.com/engineering/building-effective-agents","title":"効果的なエージェントの構築","type":"source"},{"url":"https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/","title":"エージェント構築の実践ガイド","type":"source"},{"url":"https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents","title":"AIエージェントの評価をわかりやすく解説","type":"source"},{"url":"https://martinfowler.com/articles/harness-engineering.html","title":"コーディングエージェントユーザーのためのハーネスエンジニアリング","type":"source"}],"images":[{"id":192,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg0NywicHVyIjoiYmxvYl9pZCJ9fQ==--9f1b84d1d297642915a0d27477d3800017987668/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_12_32.webp","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 04_12_32.png","translations":{"ko":{"alt":"중앙 AI 허브와 지시, 정보, 도구, 자율 실행, 검증 루프 모듈이 연결된 시스템 구조","caption":"다섯 가지 AI 엔지니어링 방식이 하나의 시스템에서 연결되고 반복 개선되는 구조를 보여준다.","description":null},"en":{"alt":"Central AI hub connected to instruction, context, tools, autonomous action, and validation loop modules","caption":"The illustration shows five AI engineering approaches working together in a connected improvement cycle.","description":null},"ja":{"alt":"中央のAIハブに指示、情報、ツール、自律実行、検証ループの各モジュールが接続された構成","caption":"5つのAIエンジニアリング手法が連携し、反復的に改善される仕組みを表している。","description":null},"es":{"alt":"Núcleo central de IA conectado con módulos de instrucciones, contexto, herramientas, acción autónoma y validación","caption":"La ilustración muestra cinco enfoques de ingeniería de IA integrados en un ciclo de mejora continua.","description":null},"id":{"alt":"Pusat AI terhubung ke modul instruksi, konteks, alat, tindakan otonom, dan siklus validasi","caption":"Ilustrasi ini menunjukkan lima pendekatan rekayasa AI yang bekerja bersama dalam siklus perbaikan.","description":null},"pt":{"alt":"Núcleo central de IA ligado a módulos de instruções, contexto, ferramentas, ação autônoma e validação","caption":"A ilustração mostra cinco abordagens de engenharia de IA integradas em um ciclo contínuo de melhoria.","description":null},"zh-hant":{"alt":"中央 AI 核心連接指令、情境、工具、自主執行與驗證迴圈模組的系統架構","caption":"圖中呈現五種 AI 工程方法如何協同運作並形成持續改進的循環。","description":null}}},{"id":193,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg1NCwicHVyIjoiYmxvYl9pZCJ9fQ==--47acd549387f7a60f4c18de6ac673ca1b551dd36/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_36_26.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 04_36_26.png","translations":{"ko":{"alt":"지시 설정부터 정보 선별, 안전 환경, 자율 실행, 검증 반복까지 이어지는 AI 구축 파이프라인","caption":"AI 시스템을 단계적으로 설계하고 검증 결과를 앞 단계에 반영하는 실무 흐름을 보여준다.","description":null},"en":{"alt":"AI build pipeline from instruction setup and context filtering to safe execution, autonomous action, and validation loops","caption":"The illustration shows a step-by-step AI workflow with feedback loops returning results to earlier stages.","description":null},"ja":{"alt":"指示設定、情報選別、安全な実行環境、自律動作、検証ループへ続くAI構築パイプライン","caption":"AIシステムを段階的に設計し、検証結果を前の工程へ反映する流れを示している。","description":null},"es":{"alt":"Flujo de creación de IA con instrucciones, filtrado de contexto, entorno seguro, acción autónoma y validación iterativa","caption":"La ilustración muestra un proceso gradual de diseño de IA con ciclos de retroalimentación hacia etapas anteriores.","description":null},"id":{"alt":"Alur pembangunan AI dari pengaturan instruksi dan penyaringan konteks hingga eksekusi aman, tindakan otonom, dan validasi","caption":"Ilustrasi ini menunjukkan tahapan perancangan sistem AI dengan umpan balik ke proses sebelumnya.","description":null},"pt":{"alt":"Fluxo de construção de IA com instruções, filtragem de contexto, ambiente seguro, ação autônoma e validação iterativa","caption":"A ilustração mostra um processo gradual de projeto de IA com ciclos de retorno às etapas anteriores.","description":null},"zh-hant":{"alt":"從指令設定、情境篩選與安全環境，到自主執行和反覆驗證的 AI 建置流程","caption":"圖中呈現 AI 系統的分階段設計流程，以及驗證結果回饋至前序階段的機制。","description":null}}}],"published_at":"2026-07-16T17:00:54+09:00","updated_at":"2026-07-16T17:00:54+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/ja/articles/prompt-context-harness-agentic-loop-engineering"}