生成AIの活用方法が、大きく変わろうとしています。

これまではChatGPTやClaudeなどに対して、人間がプロンプトを入力し、回答を受け取り、その結果を確認して、必要なら再び指示を出すという使い方が中心でした。

しかし、AIエージェントの能力が高まったことで、この構造そのものが変化し始めています。AIが必要な情報を自ら調べ、ツールを使い、ファイルを変更し、結果をテストし、問題があれば修正する。さらに、別のAIエージェントへ仕事を分担したり、一定の評価基準を満たすまで処理を繰り返したりすることも可能になってきました。

OpenAIは2026年2月に公開した「Harness engineering」の事例で、エージェント中心の開発では、エンジニアの仕事そのものが「コードを書くこと」から、「環境を設計し、意図を明確にし、エージェントが信頼できる仕事をするためのフィードバックループを構築すること」へ変化したと説明しています。

つまり、これから重要になるのは「エージェントに毎回うまいプロンプトを打つこと」ではなく、「エージェントが仕事を回せる仕組みそのものを設計すること」です。

ただし、これは「プロンプトエンジニアリングが終わった」という話ではありません。むしろ、プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング、ループ／グラフエンジニアリングというように、設計対象が徐々に広がっていると考えると理解しやすくなります。

本記事では、AIエージェント開発の新しい潮流を、中小企業の経営者、DX担当者、AI活用を進めたいビジネスパーソンにも分かるように整理します。専門的なプログラミング技術だけではなく、「会社としてAIにどう仕事を任せるか」という視点から見ていきましょう。

出典：OpenAI「Harness engineering」 https://openai.com/index/harness-engineering/

AIチャットからAIエージェントへ何が変わったのか

AIチャットは「質問→回答」が基本だった

従来の生成AI活用を単純化すると、「人間が質問する→AIが回答する→人間が結果を見る→必要なら追加で質問する」という流れになります。

たとえば営業提案書を作る場合、「この資料を要約してください」「その内容を提案書にしてください」「もう少し経営者向けにしてください」「誤字脱字をチェックしてください」という具合に、人間が1工程ずつ指示していました。

AIの処理能力が高くても、仕事を進める主体はあくまで人間です。AIは非常に優秀な「回答者」ではありますが、人間から次の指示を与えられるまで基本的には動きません。

AIエージェントは「目的→計画→実行→検証」へ進む

AIエージェントでは、この構造が変わります。たとえば、「この製品について競合を調査し、比較表を作り、営業提案資料の原案を完成させてください」という目的を与えたとします。

1. 必要な調査項目を考える
2. 情報を検索する
3. 情報を整理する
4. 比較表を作る
5. 提案書を書く
6. 内容をチェックする
7. 不足があれば再調査する
8. 完成条件を満たしたら終了する

Anthropicはエージェント設計に関する解説で、あらかじめコードで手順を決める「workflow」と、LLM自身がプロセスやツール利用を動的に判断する「agent」を区別しています。同時に、実際のシステムではシンプルで組み合わせ可能なパターンが重要だとしています。

つまりAIエージェントとは、単に「回答が長いAI」ではありません。ゴールに向かって複数の処理を選び、ツールを利用し、結果を見ながら次の行動を決める仕組みだと考えるとよいでしょう。

出典：Anthropic「Building effective agents」 https://www.anthropic.com/engineering/building-effective-agents

モデル性能だけではAIエージェントの品質は決まらない

ここで重要なのが、モデルの性能だけを比較してもAIエージェントの実力は判断できないことです。同じAIモデルを使ったとしても、次の設計によって実際の成果は大きく変わります。

• どの情報を渡すのか
• どのツールを使えるのか
• ファイルをどこまで操作できるのか
• 過去の状態を記憶できるのか
• テスト環境があるのか
• 評価基準が設定されているのか
• 失敗したときにどう戻るのか
• 何回まで再実行してよいのか

2026年のAIエージェント開発では、こうした「モデルの外側」の重要性が、以前より明確になっています。

AIエージェント開発はどう進化した？4つの設計思想を比較

AIエージェント開発の変化を理解するために、4つの考え方に整理してみましょう。なお、以下の「2024年頃→2025年頃→2026年」という整理は正式な業界規格ではありません。技術コミュニティで注目されるテーマが移ってきた流れを理解するための、本記事上の整理です。

第1段階｜プロンプトエンジニアリング

プロンプトエンジニアリングとは、「AIへどう指示すれば、望む回答を得られるか」を設計する考え方です。たとえば、AIに役割を与える、目的を明確にする、条件を指定する、出力形式を決める、例や手順を示すといった方法です。

生成AIが一般に普及し始めた頃は、「よいプロンプトを書く能力」がAI活用能力として注目されました。現在でも重要です。AIへ曖昧な指示を与えれば、AIエージェントになっても曖昧な結果が返ってきます。したがって、プロンプトエンジニアリングが不要になったわけではありません。

第2段階｜コンテキストエンジニアリング

次に注目されたのが、コンテキストエンジニアリングです。Anthropicは2025年9月、コンテキストエンジニアリングをプロンプトエンジニアリングの自然な発展として説明しました。ポイントは、単一の指示文だけではなく、ある時点でモデルが利用できる「状態全体」を考えることです。

つまり、「何と言うか」だけでなく、「AIに何を見せるか」を設計します。たとえばAIに契約書を確認させる場合でも、契約書だけを渡すのか、自社の契約ルール、過去の修正事例、法務チェック基準、取引条件、関連資料まで渡すのかで、判断精度は変わります。

AIの能力を引き出すために必要なのは、長いプロンプトを書くことだけではありません。必要な情報を、必要なタイミングで、必要な量だけ与えることです。

出典：Anthropic「Effective context engineering for AI agents」 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

第3段階｜ハーネスエンジニアリング

AIエージェントがさらに長時間・複雑な仕事を担当するようになると、コンテキストだけでは足りません。そこで重要になるのが「ハーネス」です。ハーネスとは、簡単にいえば「AIが仕事をするための環境全体」です。

Anthropicは2025年11月、複数のコンテキストウィンドウにまたがって長時間働くエージェントについて、安定して進捗させるためのハーネス設計を紹介しました。OpenAIも2026年2月に「Harness engineering」という名称で、エージェントが仕事をしやすい環境、ツール、構造、フィードバックループの設計を詳しく紹介しました。

出典：Anthropic「Effective harnesses for long-running agents」 https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

出典：OpenAI「Harness engineering」 https://openai.com/index/harness-engineering/

第4段階｜ループ／グラフエンジニアリング

さらに2026年時点では、単体エージェントの環境だけではなく、「どのようなサイクルで仕事を繰り返すか」「複数のタスクやエージェントをどのような依存関係でつなぐか」まで設計対象として考える必要が出てきています。

本記事では、前者を「ループエンジニアリング」、後者を「グラフエンジニアリング」と呼びます。ただし、特に「グラフエンジニアリング」は2026年時点でハーネスエンジニアリングほど確立・統一された業界標準用語ではありません。ここではAIエージェントの仕事を分解、並列化、依存関係付与、再試行、評価、集約する設計思想を説明するための言葉として使用します。

4つは「置き換え」ではなく「積み上げ」

重要なのは、プロンプト→コンテキスト→ハーネス→ループ／グラフと前の考え方を捨てていくわけではないことです。優れたAIエージェントには、依然としてよい指示が必要です。その指示を適切な情報の中で実行し、それを安全な環境に置き、さらに複数工程を自律的に循環させる。設計範囲が外側へ広がっていると考えてください。

ハーネスエンジニアリングとは？モデル以外を設計する考え方

ハーネスとはAIが働くための「仕事環境」

会社へ新入社員が入ったと想像してください。どれだけ能力の高い人でも、社内ルールを知らない、ファイルの場所が分からない、必要なシステムへ入れない、誰に確認すればよいか分からない、完了条件が分からないという状態では、十分に働けません。

AIエージェントも同じです。高性能なAIモデルへ交換するだけでは、長時間の実務を安定して任せられるとは限りません。必要になるのが、指示、データ、ツール、ファイル、権限、メモリ、実行環境、ログ、テスト、評価基準、停止条件などを含む仕事環境です。これがハーネスの考え方です。

外部ハーネスと内部ハーネス

理解しやすくするため、本記事ではハーネスを大きく2つに分けます。これは公式な分類ではありませんが、「AIの頭の周り」と「実際に仕事をする場所」を分けると理解しやすくなります。

CLAUDE.mdやAGENTS.mdは「巨大マニュアル」にしない

ここでありがちな失敗があります。「AIが間違えないよう、全部のルールを1ファイルへ書こう」という発想です。

OpenAIはHarness Engineeringの実践で、巨大なAGENTS.mdを作る方法を試し、問題があったと報告しています。コンテキストを大量の指示で埋めると、重要な制約が埋もれたり、古い情報が残ったりするためです。そこでAGENTS.md自体は大きな百科事典ではなく、より詳しい情報へ導く「目次」のような役割にしています。

これは中小企業のAI活用にも重要な考え方です。AIへ「この100ページを全部覚えておいて」とするより、「契約については契約ルールを見る」「営業については営業基準を見る」「顧客対応についてはFAQを見る」というように、必要な知識へ到達できる構造を作るほうが管理しやすくなります。

Hooksで「お願い」から「決定論的な処理」へ

重要な処理をAIの判断だけに任せる必要もありません。たとえば、「コードを書いたら必ずテストしてください」というプロンプトだけでは、AIが状況によってテストを省略する可能性があります。重要なルールであれば、AIにお願いするのではなく、仕組みとして必ず実行される状態に変えるほうが安全です。

• ファイル保存後に検査する
• コミット前にテストする
• 外部送信前に機密情報を検査する
• デプロイ前にレビューを通す

プロンプトには柔軟な判断を任せ、絶対に守るべきルールはコード、Hook、CI、権限設定など決定論的な仕組みに移す。これもハーネス設計の重要なポイントです。

メモリと状態を永続化する

エージェントが長時間働くようになると、「昨日まで何をしていたか」を引き継ぐ必要があります。Anthropicは長時間稼働エージェントの課題として、複数のコンテキストウィンドウをまたぐと、前回の進捗を次のセッションへ正確に引き継ぐ必要が生じることを取り上げています。

• 何を完了したか
• 何が未完了か
• 何を試したか
• 何が失敗したか
• 次に何をするか

こうした状態を外部へ保存することで、エージェントが途中から仕事を再開しやすくなります。人間でいえば、引き継ぎノートやプロジェクト管理表に相当します。

コンテキストは多ければよいわけではない

「AIのコンテキストウィンドウが大きくなったのだから、資料を全部入れればよい」とも限りません。Anthropicはコンテキストエンジニアリングについて、有限なコンテキストを効果的に利用することを重要な課題として扱っています。また、ツールが増えすぎるとツール定義だけでコンテキストを消費し、コストや遅延が増える問題もあります。

したがって、「全部覚えさせる」から「必要なときに必要な情報を取りに行ける」へ変えることが重要です。Agent Skillsのような仕組みも、その方向性と相性があります。

出典：Anthropic「Equipping agents for the real world with Agent Skills」 https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

ハーネスのアンチパターンは「過剰制御」

AIが失敗すると、人間はルールを追加したくなります。しかし、「この場合はこうしろ」「次の場合はこうしろ」「この場合だけ例外」とルールを増やし続けると、ハーネスが複雑になりすぎます。

さらにAIモデル自体が進歩すると、以前は必要だった補助が不要になる場合もあります。したがって理想は、必要な制約だけを残し、AI自身が判断できる部分まで細かく縛らないことです。

ループエンジニアリングとは？AIが自分で仕事を回す仕組み

ハーネスが「仕事環境」なら、ループは「仕事の回し方」です。従来は、人間→AIへ指示→結果を見る→AIへ修正指示→結果を見る、という形でした。ループエンジニアリングでは、この間にいる人間を減らします。

基本は「調査→実行→検証→修正」

代表的な構造は、「調査→実行→検証→修正→再検証」です。たとえばWebシステムの不具合修正なら、次のように進みます。

1. エラーログを調べる
2. 原因を仮説化する
3. コードを変更する
4. テストを実行する
5. 失敗したら原因を再分析する
6. 修正する
7. 合格したら終了する

OpenAIのHarness Engineering事例でも、エージェントが自身の変更をレビューし、追加レビューを依頼し、フィードバックへ対応し、レビューが満足するまで反復する運用が紹介されています。重要なのは、「1回のプロンプトで最高の答えを出せ」ではなく、「良くなるまで検証可能なサイクルを回せ」という設計への変化です。

インナーループとアウターループ

実務では、ループを2階層に分けると考えやすくなります。インナーループは一つのタスク内部の改善サイクルで、「調査→実装→テスト→修正」のような処理です。アウターループはプロジェクト全体を管理するサイクルで、「計画→タスク選択→実行→成果評価→次のタスク選択」のように進みます。

インナーループで個別作業を完成させ、アウターループでプロジェクト全体を前進させるイメージです。

ループを支える「5＋1」の構成要素

本記事では、2026年時点の実務でループを作るための要素を「5＋1」で整理します。これは公式規格ではなく、実務上の整理です。

1．自動化

最初は、定期起動、テスト、データ取得、ファイル生成、通知などの処理を自動化します。AIの判断が必要ない処理までAIへ任せる必要はありません。決まった処理は通常のプログラムで実行し、判断が必要な部分にAIを使います。

2．ワークツリー

複数エージェントが同時にコードやファイルを変更する場合、同じ作業場所を使わせないことが重要です。OpenAIのHarness Engineering事例ではGit worktreeごとにアプリケーションを起動し、エージェントが変更ごとに分離された環境で検証できる仕組みが使われています。

3．スキル

毎回プロンプトで業務手順を説明するのではなく、再利用できる「仕事のやり方」としてまとめます。たとえば、SEO記事をチェックする、見積書を確認する、議事録を整理する、契約書の確認項目を抽出するといった能力です。

4．プラグイン・コネクタ

AIが実際の仕事をするには、メール、カレンダー、CRM、ファイルストレージ、データベース、GitHub、業務システムなど、社外・社内システムとの接続が必要です。ただし接続先が増えるほど、権限管理とセキュリティは重要になります。

5．サブエージェント

大きな仕事を1つのAIへ全部やらせず、専門役へ分担します。AnthropicのResearchシステムでは、リードエージェントが戦略を立て、専門のサブエージェントを並列に動かす「orchestrator-worker」型のマルチエージェント構造が採用されています。

＋1．メモリ

そして、すべてをつなぐのがメモリです。作業履歴、決定事項、失敗、完了状況などを残すことで、エージェントが途中から仕事を再開しやすくなります。

出典：Anthropic「Multi-agent research system」 https://www.anthropic.com/engineering/multi-agent-research-system

グラフエンジニアリングとは？複雑な仕事を構造化する

ループだけでも多くの仕事は自動化できます。しかし、会社の仕事は必ずしも一本道ではありません。たとえばシステム開発なら、要件定義の後にUI設計、データベース設計、セキュリティ設計を並行して進め、その成果を統合してから実装へ進むことがあります。そこで「グラフ」という考え方が役立ちます。

タスクを「ノード」と「依存関係」で表す

仕事を小さなタスクへ分け、それぞれをノードとして考えます。「要件整理→基本設計→実装→テスト」だけでなく、基本設計から「画面設計」「データ設計」「セキュリティ設計」へ枝分かれし、再び統合する構造もあります。

グラフにすると、「何が終わらなければ次へ進めないか」「何を並列実行できるか」が明確になります。

旧ワークフロー型AIとの関係

従来型の業務自動化では、「Aが終わったらB」「Bが成功したらC」「失敗したらD」という流れを、人間が細かく決めていました。これは現在でも非常に有効です。

一方AIエージェントでは、「Aが終わったあと、状況を見てB・C・Dから適切なものを選ぶ」という判断をAIへ任せられるようになります。重要なのは、「ワークフローかエージェントか」の二者択一ではありません。決定論的に動かしたい部分はワークフローにし、判断が必要な部分だけAIエージェントへ任せるという組み合わせが現実的です。

「グラフの中にループ」が実務的な構造

実務上は、「グラフ＝仕事全体の構造」「ループ＝各仕事の内部で品質を上げる仕組み」と分けると分かりやすくなります。たとえば、「仕様確認→実装→テスト→セキュリティ確認→公開」というグラフの「実装」ノード内部では、「作成→テスト→修正→再テスト」というループを回します。品質基準を満たしたら次のノードへ進みます。つまり、グラフの中にループがある状態です。

AIエージェントを高精度にする3層構造

AIへ長いプロンプトを渡し、「計画して、作って、チェックして、間違っていたら直してください」とすべて任せる方法もあります。しかし、重要な業務では役割を分離したほうが管理しやすくなります。代表的なのが、Planner、Generator、Evaluatorの3層です。

Planner｜何をするか決めるAI

Plannerは計画担当です。ゴールを理解し、タスクへ分解し、必要な情報を決め、実行順を決め、誰に任せるかを決めます。会社でいえばプロジェクトマネージャーに近い役割です。

Generator｜実際に作るAI

Generatorは実行担当です。コードを書く、文書を作る、データを整理する、調査する、提案資料を作るなど、実際の成果物を生成します。

Evaluator｜結果を採点するAI

Evaluatorは評価担当です。重要なのは「よいと思います」と感想を言わせるのではなく、明確な採点基準を与えることです。たとえば記事なら、検索意図を満たしているか、事実と意見が区別されているか、重複説明がないか、専門用語が説明されているか、指定文字数を満たしているか、といった基準です。

AnthropicもAIエージェントの評価について、入力・実行結果・採点ロジックを組み合わせた「eval」を重要な開発手段として扱っています。

出典：Anthropic「Demystifying evals for AI agents」 https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

「作ったAI自身に採点させる」だけで十分なのか

ここには注意が必要です。AIは自分自身の回答を見直せますし、自己修正によって精度が向上するケースも研究されています。一方で、「自分が作った誤り」を見落としやすい現象も報告されています。

2025年に公開されたSelf-Correction Benchでは、14のオープンソース非推論モデルを対象に、自分自身が生成した誤りと、外部から与えられた同一の誤りへの修正能力を比較し、平均64.5％のSelf-Correction Blind Spotが観測されました。ただし対象モデルや条件が限定されているため、「すべてのAIは自己修正できない」と一般化することはできません。

別の研究では、自己修正が複雑な推論などで精度改善につながる場合がある一方、複数の修正戦略を組み合わせるほど効率とのトレードオフも発生すると報告されています。したがって実務では、「自己修正は意味がない」でも「同じAIに全部任せればよい」でもないと考えるべきです。

重要な成果物では、別のAIエージェント、外部テスト、ルールベース検査、人間、評価専用モデルなど、別の視点を組み込むことが有効です。

出典：Self-Correction Bench https://arxiv.org/abs/2507.02778

AIエージェントの品質を高める「多角的レビュー」とゲート設計

AIが作った成果物を1回の評価で「合格・不合格」と判断するだけでは、複雑な仕事では不十分です。そこでレビューを役割別に分けます。

実装レビュー

本当に必要なものが実装されているかを確認します。

テストレビュー

正常系だけでなく、想定外の入力でも問題なく動くかを確認します。

仕様レビュー

依頼された仕様と成果物が一致しているかを確認します。

コードレビュー

保守性、可読性、重複、設計ルールなどを確認します。

セキュリティレビュー

権限、外部通信、機密情報、認証、入力値などを確認します。

「ゲート」を通過しなければ次へ進ませない

たとえば、「Gate1：仕様一致→Gate2：テスト合格→Gate3：品質確認→Gate4：セキュリティ確認→完了」という構造です。どこかで不合格になったらGeneratorへ戻します。

この考え方はソフトウェアだけではありません。営業資料でも、「事実確認→表現確認→法務確認→最終承認」のように応用できます。

OpenAIは2026年のAuto-review研究で、実行エージェントとは別のレビューエージェントに行動を審査させる仕組みを社内Codex環境で評価しています。繰り返し拒否された場合は軌跡そのものを停止させる仕組みも説明されています。

出典：OpenAI Alignment「Auto-review」 https://alignment.openai.com/auto-review

すべて同じAIモデルを使う必要はない

AIエージェントシステムだからといって、すべての処理へ最高性能・最高価格のモデルを使う必要はありません。Plannerは高度な推論が必要なので高性能モデル、Generatorは大量生成するので速度と価格のバランス、Evaluatorは基準に沿った判定能力を重視する、といった設計が考えられます。

単純分類や形式チェックは、さらに軽量なモデルや通常のプログラムで十分かもしれません。重要なのは、「一番賢いモデルを選ぶ」ことではなく、「仕事ごとに必要な能力を定義する」ことです。

AIエージェント運用で起きやすい5つの問題

問題1｜無限ループする

テスト→失敗→修正→テスト→失敗を延々繰り返す可能性があります。

問題2｜API・トークンコストが高騰する

AIが何十回も検索したり、複数エージェントを大量に起動したりすれば、コストは増えます。複数エージェントは大量の並列処理に向く一方、すべてのタスクに適しているわけではありません。

問題3｜複数AIが同じ作業場所を変更する

Aエージェントがファイルを変更した直後に、Bエージェントが古い状態を基に上書きすると、「先祖返り」が起きます。

問題4｜機密情報や権限の範囲が広すぎる

AIへ「必要なら何でも調べて何でも変更してよい」という権限を与えるのは危険です。

問題5｜一つの解決策に固執する

AIが最初に立てた仮説が間違っているにもかかわらず、その仮説の中だけで修正を繰り返す可能性があります。これは「局所最適」に陥る問題です。

暴走を防ぐハードストップを設計する

AIエージェントには「いつ止めるか」を必ず決めておくことが重要です。

リトライ回数の上限

たとえば、同じエラーが3回続いたら停止します。3回失敗したら、「もっと頑張れ」ではなく、人間へ相談させます。

コスト上限

一つの仕事に利用できるAPI費用やトークン量に上限を設けます。

時間上限

「最大30分」「最大2時間」など、実行時間を制限します。

権限上限

たとえば「読み取りは自動」「下書き作成は自動」「外部送信は承認必須」「削除は禁止」「本番環境変更は人間承認」のようにします。

失敗したら人間へエスカレーションする

AIが仕事をできないこと自体は問題ではありません。むしろ危険なのは、できないのに、できるまで勝手に試し続けることです。したがって「ここまではAI」「ここを超えたら人間」という境界線を決めておきます。

複数のAIエージェントを安全に並列実行する方法

AIエージェントの大きな魅力は並列化です。人間1人は通常、一度に1つの作業へ集中します。一方、AIエージェントなら、競合調査、市場調査、顧客分析を3エージェントへ同時に依頼し、最後に統合することができます。

AnthropicのマルチエージェントResearchシステムでも、リードエージェントが複数のサブエージェントへ調査テーマを分担し、結果を統合する構造が採用されています。ただし並列化にはルールが必要です。

作業場所を分離する

コード開発なら、Gitブランチ、Git worktree、コンテナ、サンドボックスなどを分けます。

担当範囲を分離する

「全員が全部を見る」のではなく、「A：市場」「B：競合」「C：顧客」のように担当範囲を決めます。

統合担当を決める

最後に誰が結果をまとめるのかを決めます。複数エージェントの出力をそのまま足すだけでは、矛盾が残る場合があるためです。

セキュリティと機密情報保護はハーネス側で守る

AIエージェントのセキュリティでは、「AIに注意するようプロンプトで指示する」だけでは足りません。

最小権限にする

AIへ必要な権限だけを付与します。営業資料を作るAIなら、会計データベースを削除する権限は不要です。

サンドボックス・コンテナで隔離する

外部環境から隔離した場所でコードやファイルを実行する設計も重要です。長時間・高自律エージェントほど、実行環境を分離して影響範囲を限定する考え方が重要になります。

外部アクセスを制限する

すべてのWebサイトやAPIへ自由にアクセスさせるのではなく、必要な接続先に限定します。

プロンプトインジェクションを前提にする

AIエージェントがWebページ、メール、文書など外部コンテンツを読む場合、その中に悪意ある命令が含まれる可能性があります。外部コンテンツを「命令」ではなく「データ」として扱う境界設計や、権限分離、重要操作の承認が必要です。

不可逆な操作には承認ゲートを置く

メール送信、契約、支払い、データ削除、本番公開、顧客情報変更などは、人間承認を残すべきケースが多いでしょう。

局所最適を避ける「並列探索」という考え方

AIへ一つの案を作らせ、その案を10回修正させる方法があります。しかし最初の方向性が間違っていたら、10回修正しても間違った方向の中で最適化するだけかもしれません。そこで、「案A」「案B」「案C」と複数案を並列に作る方法があります。

その後Evaluatorに、目的適合度、コスト、実現可能性、リスクなどを比較させます。これは「改善だけでなく探索する」という発想です。特に正解が一つではない、新規事業、マーケティング、設計、コピー、戦略、原因分析などで有効です。

AIエージェント時代、人間の役割はどう変わる？

ここまで自動化すると、「では、人間はいらなくなるのか」と感じるかもしれません。むしろ人間の役割は、より上流へ移ります。OpenAIはHarness Engineeringの実践を、人間が方向づけ、エージェントが実行する関係で説明しています。会社に置き換えると、人間は「プレイングマネージャー」から「オーナー・ディレクター」に近づきます。

目的とゴールを定義する

AIが得意なのは「与えられた目的へ進むこと」です。何を実現するべきなのかは、人間が決めます。

ルールと制約を決める

何をしてよいか、何をしてはいけないか、どのデータを使えるか、どこまで自動化するかを決めます。

評価基準を決める

「よい提案書」ではなく、「必要項目が全部入っている」「根拠が確認できる」「指定価格を超えない」「禁止表現がない」のように、可能な限り判定可能な条件へします。

ハードストップを決める

どの状態になったらAIを止めるのか決めます。

最終レビューと承認を行う

法務、財務、採用、医療、安全など影響の大きな判断では、人間による最終承認が重要です。

これから重要になるのは「プロンプト力」だけではない

生成AIの初期には、「プロンプトが上手な人」がAI活用の中心人物になりやすい傾向がありました。AIエージェント時代には、さらに別の能力が求められます。

プロジェクトマネジメント

大きなゴールを小さなタスクへ分割する力です。

上流設計

「何を作るか」「何を自動化するか」を決める力です。

テスト設計

「正しくできたか」を機械的・客観的に確認する力です。

評価基準設計

AIの成果物を何点なら合格にするか決める力です。

リスク管理

AIに与える権限、情報、操作範囲を決める力です。

つまりこれから問われるのは、「AIへ何と聞けばよいか」だけではありません。より重要なのは、「AIへ何の仕事を、どんな条件で、どこまで任せるのか」を設計する能力です。これはエンジニアだけの仕事ではありません。経営者、管理職、DX担当者、現場責任者にも関係するテーマです。

中小企業がAIエージェント導入を始める5ステップ

では、中小企業は何から始めればよいのでしょうか。いきなり「完全自律型AI社員」を作る必要はありません。むしろ、小さなループから始めることをおすすめします。

STEP1｜繰り返しAIへ頼んでいる仕事を見つける

最初に探すべきなのは、すでに人間がAIへ何度も頼んでいる仕事です。「この文章を作って→事実確認して→修正して→短くして→最終チェックして」のように、人間自身がすでにループを回しているなら、AIエージェント化の候補になります。

STEP2｜ゴールを決める

AIエージェントにとって、開始条件より重要なのが終了条件です。「記事を書く」では曖昧ですが、「10,000文字以上」「指定見出しを含む」「引用元が明記されている」「禁止表現がない」「FAQを5問入れる」なら判定できます。

STEP3｜必要なツール・データ・権限を整理する

何を読ませるか、どのシステムへ接続するか、何を変更できるか、何を変更できないかを決めます。

STEP4｜小さなループを作る

最初から10エージェントを動かす必要はありません。まず、「作成→評価→基準未達なら修正」という3段階から始めます。

STEP5｜評価・停止・人間承認を追加する

最後に、最大試行回数、最大コスト、最大時間、人間承認ポイントを追加します。これだけでも、単なる「ChatGPT活用」とは違う業務設計になります。

AIエージェント導入前チェックリスト

• AIに任せたい業務が具体的に決まっている
• 完了条件を言葉または数値で説明できる
• 正解・不正解をある程度判定できる
• AIに与えるデータが決まっている
• 必要なシステム・ツールが分かっている
• AIに与える権限を限定できる
• 外部送信や削除など危険な操作を区別できる
• 失敗時に元へ戻せる
• リトライ回数を決められる
• 時間またはコスト上限を設定できる
• 人間が承認すべき工程が決まっている
• 実行ログを残せる
• 評価結果を改善へ戻せる

Yesが少ない状態で、いきなり自律性だけを高めるのはおすすめできません。モデルを変える前に、まず業務そのものを整理する必要があります。

AIエージェント開発は「モデル選び」から「仕事設計」へ

ここまでを見ると、AIエージェント開発の本質が見えてきます。数年前までは、「どのAIモデルが一番賢いか」が中心的な関心でした。もちろん今でもモデル性能は重要です。

しかしAIが長時間、自律的に業務を実行するようになるほど、「何を目的とするか」「どの情報を渡すか」「どのツールを与えるか」「どこまで権限を与えるか」「どう評価するか」「どこで停止するか」「誰が最終承認するか」の重要度が高まります。

AIエージェントの性能は、「AIモデル単体のIQ」のようなものだけでは決まりません。モデルが仕事を成功させやすい環境を企業側が作れるかが重要になります。ここに、ハーネスエンジニアリングやループエンジニアリングが注目される理由があります。

まとめ｜AIエージェント開発は「プロンプトを書く」から「仕事の仕組みを設計する」へ

AIエージェント開発は2026年時点で、大きな転換期にあります。以前は「AIへどう指示するか」が中心でした。そこから、「何を見せるか」というコンテキストエンジニアリングへ広がり、さらに、「どんな環境で仕事をさせるか」というハーネスエンジニアリングへ進みました。

そして現在は、「どう調査・実行・検証・修正を繰り返すか」「複数タスクや複数エージェントをどう分解・並列化・統合するか」まで含めて考える必要が出てきています。

ただし、「プロンプトエンジニアリングの時代は終わった」という意味ではありません。より正確には、プロンプト＋コンテキスト＋ハーネス＋ループ＋グラフへ、AIエージェントの設計範囲が広がったと考えるべきです。

そして人間の仕事も変わります。一つひとつAIへ作業指示を出すプレイヤーから、目的を決め、仕事を分解し、ルールを作り、評価基準を決め、AIチームを管理するディレクターへ近づいていきます。

これから求められるのは、「魔法のプロンプト」を覚えることだけではありません。プロジェクトマネジメント、業務設計、テスト、評価、セキュリティ、リスク管理といった、これまで人間の組織運営で培われてきた能力が、むしろ重要になります。

AIエージェント導入を検討する中小企業も、最初から複雑なマルチエージェントシステムを作る必要はありません。まずは、「人間がAIへ何度も同じような指示を出している仕事」を一つ見つけてください。そして、「作る→評価する→修正する→基準を満たしたら終了する」という小さなループを作るところから始めるのが現実的です。

AIエージェント時代に重要なのは、AIに仕事を奪われない方法を考えることではありません。AIにどの仕事を、どんな条件で、どこまで任せるのかを設計できる会社になることです。

よくある質問

Q1．プロンプトエンジニアリングはもう不要ですか？

不要ではありません。AIエージェントでも目的、条件、役割などを明確に伝える必要があります。ただし、プロンプトだけで品質を改善するのではなく、必要情報、ツール、メモリ、テスト、評価基準などを含めた環境全体を設計する重要性が高まっています。

Q2．ハーネスエンジニアリングとコンテキストエンジニアリングの違いは何ですか？

コンテキストエンジニアリングは「AIに何を見せるか」が中心です。一方、ハーネスエンジニアリングは、コンテキストに加えてツール、権限、実行環境、メモリ、テスト、ログなど「AIが仕事をする環境全体」を扱う、より広い考え方として理解すると分かりやすいでしょう。

Q3．ループエンジニアリングと従来のワークフロー自動化は何が違いますか？

従来のワークフローでは、人間があらかじめ処理順を細かく決めることが一般的です。AIエージェントでは、結果を評価しながら次の処理をAI自身が選べる点が異なります。ただし両者は排他的ではなく、決められた工程はワークフロー、判断が必要な工程はエージェントという組み合わせが実務的です。

Q4．AI自身に成果物をチェックさせても大丈夫ですか？

一定の効果は期待できますが、それだけに依存しないほうが安全です。研究では自己修正が精度改善につながるケースがある一方、自分自身が生成した誤りを見落とす現象も報告されています。重要な業務では、別エージェント、外部テスト、ルールベースチェック、人間による確認など複数の評価手段を組み合わせることが望ましいでしょう。

Q5．中小企業でもAIエージェントを導入できますか？

可能です。最初から高度なマルチエージェントシステムを構築する必要はありません。「作成→評価→修正」のように、現在人間がAIとの間で繰り返している小さな業務から自動化する方法があります。重要なのは、自動化する業務、完了条件、利用データ、権限、停止条件を先に整理することです。

CTA｜AIに何を任せるべきか分からない企業へ