MENU

エージェンティック・エンジニアリング

エージェンティック・エンジニアリングのインフォグラフィック
エージェンティック・エンジニアリングのインフォグラフィック

エージェンティック・エンジニアリングのインフォグラフィックを見る

Contents

序論：エージェンティック・エンジニアリングの起源と「80%問題」

人工知能の進化は、ソフトウェア開発における構造的なパラダイムシフトを引き起こし、決定論的な自動化から目標指向型の自律性への移行を決定づけた。この変革の震源地にあるのが「エージェンティック・エンジニアリング（Agentic Engineering）」である。これは、環境を認識し、計画を策定し、マルチステップのワークフローを実行できる自律型AIエージェントの設計、オーケストレーション、および運用に特化した新興のエンジニアリング領域である。歴史的に、基盤モデルは初期ソリューションの生成において高い能力を示してきたが、これは産業界の研究者によって「80%問題」として分類される現象であった1。GoogleのAddy Osmaniが指摘したこの枠組みにおいて、大規模言語モデル（LLM）はソリューションの80%を極めて高速に合成できるが、残りの20%——すなわち、アーキテクチャの決定、エッジケースの処理、プロダクション環境への適用と堅牢化——は、単なるカジュアルなプロンプティングではなく、深いエンジニアリングの知識と規律を要求する1。

エージェンティック・エンジニアリングとは、まさにこの最後の20%を方向付けるための体系的な規律である1。この分野は、モデルの出力をそのまま受け入れて最善を尽くすことを祈るようなアプローチには依存しない。むしろ、特定の設計原則、アーキテクチャ・パターン、および標準化された通信プロトコルを備えた体系的なアプローチを導入する1。一時的な対話パラダイムから脱却し、AIの厳密な取扱説明書として機能する「AGENTS.md」のような永続的なドメインファイルや命令セットを確立することで、システムの運用境界を定義する2。これは、コンピュータサイエンスが70年間にわたって構築してきた理論の論理的な帰結であり、高度な推論能力と厳格な運用境界を融合させたものである1。この分野を推進する包括的な前提は、自律型システムの真の価値が基盤モデルそのものにあるのではなく、それを制御・統制する高度に構造化されたワークスペース、すなわち「ハーネス（Harness）」にあるという認識である4。2026年までに、エージェンティックAIの分野は世界のベンチャーキャピタル投資の50%（約2,110億ドル）を占めるまでに成長し、一時的な目新しさからエンタープライズのインフラストラクチャを再定義する中核技術へと変貌を遂げた6。

AIパラダイムの進化：プロンプトからハーネスへ

現在のアージェンティック・アーキテクチャの到達点を理解するためには、2022年から2026年にかけての人間とAIのインタラクションの発展段階を追跡することが不可欠である。この進歩は、以前の方法論がエンタープライズの要求に合わせて拡張できないという認識に基づく、エンジニアリングの厳密性の継続的な再配置（Relocating Rigor）によって特徴付けられる4。

プロンプト・エンジニアリングの時代（2022年〜2024年）

大規模言語モデル導入の初期段階は、自然言語による指示を最適化するという哲学の下で運用されていた。完璧に作成されたプロンプトが完璧な応答を引き出すという命題が中心であり、自然言語の指示がプログラムとして機能する「ソフトウェア3.0（Software 3.0）」の概念が提唱された4。この時期には、複雑な論理を分解してモデルに強制的に推論させるための学術的なブレークスルーが次々と生まれた。Google BrainによるChain-of-Thought（CoT）プロンプティング、推論と行動を組み合わせたReAct、さらにはTree-of-Thought（ToT）やReflexionといった自己評価ループの導入である4。しかし、プロンプト・エンジニアリングはタスクの規模が拡大するにつれて致命的な限界に直面した。アクティブなコンテキストウィンドウに必要なコードファイルやシステム状態が含まれていなければ、どれほど詳細なプロンプト（例：「既存のコーディング規約に従え」という指示）を与えても、モデルは必然的にハルシネーション（幻覚）を引き起こし、実行に失敗した4。

コンテキスト・エンジニアリングの時代（2025年）

プロンプトの言い回しよりもコンテキストウィンドウの内容が成功を決定づけることに気づいた業界は、パラダイムを移行させた。ShopifyのCEOであるTobi Lütkeによって普及した「コンテキスト・エンジニアリング」は、必要なデータの正確なサブセットをキュレーションし、構造化してモデルの限られたメモリに注入することに焦点を当てた4。これは検索拡張生成（RAG）などの技術によって知識の欠如を緩和したが、エンジニアたちはすぐに新たな壁に直面した。どれほど完璧なコンテキストが提供されたとしても、それを消費するシステム全体のループ設計が不十分であれば、特にマルチステップの実行環境においては壊滅的な障害が発生したのである4。コンテキストの管理は成功のための必要条件ではあったが、十分条件ではなかった。

ハーネス・エンジニアリングの時代（2026年以降）

2026年に至り、焦点は「どのようなシステムを構築すべきか」へと完全に移行した。エンジニアたちは、エージェントがミスを犯すたびにプロンプトを書き直すのではなく、そのミスが構造的に再発不可能なように周囲のシステム（ハーネス）を変更しなければならないという結論に達した4。ThoughtWorksなどのコンサルタントが定式化したように、「エージェント ＝ モデル ＋ ハーネス」である4。このパラダイムにおいて、LLMは純粋な計算エンジン（CPU）に過ぎず、ハーネスがコンテキストのキュレーション、ツールの統合、権限の境界、およびエラーからの回復を管理するオペレーティングシステムとして機能する4。エンジニアリングの厳密性は、非決定論的なガイダンスから、コンパイラ、型チェッカー、および静的ルールのファイル（.cursorrulesやAGENTS.mdなど）を利用した決定論的な境界へと再配置された3。

自律型システムのコア・アーキテクチャと「LLM OS」ビジョン

アージェンティック・システムの基盤となるアーキテクチャは、「LLM OS（大規模言語モデル・オペレーティングシステム）」というビジョンを通じて最もよく概念化される。Andrej Karpathyが提唱したこの概念は、LLMを単なるチャットボットではなく、新しいオペレーティングシステムのカーネルプロセスとして位置づけるものである1。このカーネルは、テキスト、音声、視覚にわたるマルチモーダルな入出力をオーケストレーションし、コードインタプリタ、インターネットアクセス、および記憶ストレージを統合する1。この実行ループは、環境を認識（Perceive）し、計画を策定（Plan）し、外部ツールを通じて行動（Act）し、結果を観察（Observe）し、目標が達成されるまでこれを繰り返すというプロセスで構成される1。

オーケストレーターとプランニング・モジュール

この実行ループの中心に位置するのがオーケストレーターである。オーケストレーターは、ユーザーの目的、現在のコンテキストメモリ、以前のアクションの結果、および利用可能なツールのリストを消費する7。オーケストレーターがもろく純粋に反応的な決定を下すのを防ぐために、アクションの前にタスクグラフを合成するプランニング・モジュール（推論エンジン）が統合されている7。高レベルの目標（例：競合分析レポートの作成）を、個別の連続したサブタスク（機能の検索、競合他社のページの読み込み、合成、構造化されたレポートの記述など）に分解することにより、プランナーはエージェントが一貫した軌道を維持できるようにする7。この推論ロジックが欠如している場合、システムは単一セッションの枠を超えた複雑なソリューションに収束するのに苦労し、チャットボットと同等の反応的ループに退化する9。

マルチレイヤー記憶アーキテクチャ（Memory Stack）

状態（ステート）管理は、本番環境のエージェンティック・システムにおいて最も頻繁に発生する障害点である7。堅牢な記憶アーキテクチャがなければ、エージェントはコンテキスト喪失（Context Amnesia）に陥り、以前に失敗したアクションを繰り返したり、コンテキストウィンドウから外れたデータをハルシネーションしたりする7。これを防ぐため、エージェンティック・エンジニアリングは4層のメモリースタックに依存している。

  1. インコンテキスト・メモリ（In-Context Memory）： 即時的でアクティブな会話ウィンドウである。直近の観察結果への高忠実度なアクセスを提供するが、トークン制限によって厳密にバインドされている7。
  2. エピソード・メモリ（Episodic Memory / 短期記憶）： 現在のセッションの個別のアクション、ツールの結果、および微視的な決定を追跡する構造化された時間的ログである。トークンのオーバーフローを防ぐために、このエピソードログは定期的に要約され、アクティブなコンテキストに再注入される7。Redisなどの高速データストアが、この一時的な状態を管理するために頻繁に使用される7。
  3. セマンティック・メモリ（Semantic Memory / 長期記憶）： 完全に分離されたセッション間で知識を保持するために、過去の実行履歴、ユーザーの好み、およびドメイン固有の知識がチャンク化され、高次元ベクトルに変換され、ベクトルデータベース（Pinecone、Weaviate、ChromaDB、pgvectorなど）に保存される7。情報は新しい実行の開始時に類似性検索によって動的に取得される7。
  4. 手続き的メモリ（Procedural Memory）： システムの仕組みに特化したリポジトリであり、検証済みのツールスキーマ、API定義、および学習済みの実行ワークフローを保存する。これにより、エージェントは構文を再計算することなく、外部システムとのインターフェース方法を即座に思い出すことができる7。

ツール実行レイヤー

自律型エージェントは、厳密にツール実行レイヤーを介してデジタル環境とインターフェースをとる。ツールはJSONスキーマなどの構造化された形式でLLMに提示され、モデルは正確にフォーマットされたツール呼び出しを出力する7。アプリケーションレイヤーはこれらのパラメータを傍受し、基盤となるネイティブコード（データベースへのクエリ実行、Playwrightを介したブラウザのナビゲーション、またはPython REPLでのコード実行など）を実行し、その生出力を「観察（Observation）」としてエージェントのコンテキストウィンドウに返す7。

マルチエージェント・オーケストレーションの設計パターンと複雑性

適切なシステム複雑性のレベルを決定することは、重要なアーキテクチャ上の決定である。複数のエージェントを導入すると、遅延、トークン消費、および調整のオーバーヘッドによるシステム障害の確率が本質的に増加する10。したがって、Microsoftのガイドラインによれば、必要なツールとドメインの範囲がモデルの推論能力を圧倒しない限り、エンタープライズワークフローのデフォルトの推奨事項は「ツールを備えた単一エージェント（Single Agent with Tools）」パターンである10。しかし、厳格なセキュリティ境界が分離を要求する場合や、ドメインの複雑性が高度に専門化された並列推論を要求する場合には、マルチエージェント・オーケストレーションが実装される10。

MicrosoftのAIエージェント設計パターンは、オーケストレーションのダイナミクスを確立されたクラウドコンピューティングのパラダイムに直接マッピングしている10。

オーケストレーション・パターン

クラウド設計の同等物

運用メカニズムとアーキテクチャ

最適なユースケース

シーケンシャル（Sequential）

Pipes and Filters

エージェントが厳密で直線的なパイプラインで動作する。先行するエージェントの出力が次のエージェントの入力となる。

予測可能なステップバイステップのワークフロー。段階的な改良（例：起草 → レビュー → コンプライアンスチェック）10。

コンカレント（Concurrent）

Fan-out / Fan-in

複数の特化型エージェントがタスクを並行して処理する。結果は決定論的ロジックまたはLLMの合成によって集約される。

幅広い視点や独立した分析が必要なタスク（例：大規模なログ分析、アンサンブル推論）10。

グループチャット（Group Chat）

Pub/Sub (Threaded)

エージェントが共有された管理下の会話スレッド内で相互作用する。メーカー・チェッカー（Maker-Checker）の検証ループを含む。

アイデア出し、コンセンサス形成、厳格なピアレビューによる品質保証（QA）プロセス10。

ハンドオフ（Handoff）

Dynamic Routing

エージェントが自律的に自身の信頼度を評価し、適切な専門エージェントに制御を動的に委譲する。

事前に必要な専門性が不明なトリアージシステム10。

マジェンティック（Magentic）

Dynamic DAG Generation

中央のマネージャー・エージェントが、リアルタイムの観察に基づいて動的なタスク台帳（Ledger）を積極的に構築、更新、および委譲する。

決定された解決経路を持たないオープンエンドな問題解決や、重大なインシデント対応10。

実装の考慮事項と信頼性の課題

マルチエージェントシステムの展開は、分散コンピューティングアーキテクチャに内在する古典的な問題（ノードの障害、ネットワークの分断など）を反映している10。エージェントが通信する際、システムは「コンテキストの圧縮（Context Compaction）」を管理しなければならない。これは、制御を移行する前に状態を要約するプロセスであり、ダウンストリームのエージェントがトークン制限を超えることなく十分なコンテキストを確実に受け取れるようにする10。さらに、グループチャットやハンドオフ構成などの動的なオーケストレーションパターンは、無限の実行ループ（Infinite Loops）のリスクをもたらす10。暴走したエージェントの通信を強制的に終了させるために、最大反復回数の上限やプログラムによる構造チェックなどの厳格な決定論的セーフガードを展開する必要がある10。また、長時間実行されるタスク中の復元力を保証するために、状態（ステート）は外部の耐久性のあるデータベースに永続化されなければならず、これによりエージェントは履歴コンテキストを失うことなく中断されたワークフローをシームレスに再開できる10。

モデルコンテキストプロトコル（MCP）とツールの標準化

初期のエージェンティック・システムにおける根本的なボトルネックは、API統合の断片化であった。独自仕様のエンタープライズシステムごとに特注のコネクタロジックを記述する必要があり、これはスケーリング不可能なデータサイロのマトリックスを生み出した13。さらに、エージェントの品質は提供されるツールの数が約50を超えると顕著に低下するという臨界性能閾値（Critical Performance Threshold）が存在し、厳格なツールのキュレーションが不可欠であった1。

この課題を解決するために導入されたのが、オープンソース標準であるモデルコンテキストプロトコル（Model Context Protocol：MCP）である。Anthropicによって開発されたこのプロトコルは、概念的にAIアプリケーションのための「USB-Cポート」として機能し、AIエージェントと外部リソース間の普遍的な双方向接続の標準を提供する13。

MCPのアーキテクチャとプリミティブ

MCPはクライアント・サーバー型アーキテクチャで動作する。IDEなどのアプリケーション環境であるMCPホスト（MCP Host）は、プロトコルロジックを管理しLLMにコンテキストを転送するMCPクライアントを内包する16。一方、MCPサーバーは以下の3つの主要なプリミティブをエージェントに公開する。

  • リソース（Resources）： 内部または外部のデータベースからの読み取り専用のデータストリーム。実用的な計算は実行しない18。
  • ツール（Tools）： 外部システムで副作用（データベースの書き込みやAPIリクエストの実行など）を引き起こすことができる実行可能な関数18。
  • プロンプト（Prompts）： LLMとサーバー間の通信を標準化する、再利用可能なワークフローテンプレート18。

ツール統合を抽象化することにより、MCPは新しいサービスごとにハードコードされたオーケストレーションロジックを要求することなく、エージェントが機能を動的に発見して利用することを可能にする10。さらに、MCPは計算の負担を移行させる。LLMにインコンテキストで大規模なデータセットを処理させる代わりに、MCPサーバーは複雑なロジックやフィルタリングをサーバー側でネイティブに実行し、高度に蒸留された結果のみをモデルに返すことができる。これにより、トークン消費が劇的に削減され、コンテキストの劣化が緩和される19。2025年12月にLinux FoundationのAgentic AI Foundationに寄贈されたMCPは、Gartnerの予測によれば、2026年末までにエンタープライズ・アプリケーションの40%に搭載されると見込まれている1。

セキュリティ、脅威モデリング、およびMCPの脆弱性

ツールへのアクセスの標準化は開発速度を飛躍的に向上させる一方で、攻撃対象領域（アタックサーフェス）を同時に拡大させる。非決定論的なモデルを実行可能なシステムツールとブリッジングすることにより、エージェンティック・システムは従来のアプリケーション・セキュリティ・フレームワークでは緩和が困難な深刻なセキュリティ・パラダイムをもたらす16。STRIDE（スプーフィング、改ざん、否認、情報漏洩、DoS、権限昇格）およびDREADフレームワークを利用した脅威モデリングにより、最も致命的な脆弱性はLLMの推論内部ではなく、モデル、MCPクライアント、および外部データストア間のインターフェースに存在することが明らかになっている21。

プロンプト・インジェクションとツール・ポイズニング

エージェンティック・システムに対する主要な攻撃ベクトルは間接的プロンプト・インジェクションであり、これは「ツール・ポイズニング（Tool Poisoning）」として一般的に兵器化される16。LLMは環境から受け取るトークンを暗黙的に信頼するため、悪意のある攻撃者は外部データソース（要約されたWebページやドキュメント内の非表示の文字列など）に指示を埋め込むことができる。エージェントのMCPツールがこのデータを取得すると、LLMは隠された文字列を受動的なデータとしてではなく、実行可能な命令として処理してしまう16。

エージェントが特権の高いツールを保持している場合、攻撃者はエージェントの実行ループを乗っ取り、攻撃者に代わって許可されたツールを呼び出すようエージェントに強制できる16。この「混乱した代理人（Confused Deputy）」の脆弱性により、ホストアプリケーションの正当な認証コンテキストの下で、データ引き出し（WhatsAppメッセージ履歴の流出など）や不正なコード実行などの悪意のある操作が発生する可能性がある16。信頼できない外部の指示と、非常に有能なローカルツールを混在させることは、根本的に揮発性の高いセキュリティ状態を生み出す22。

緩和策と防御戦略

エージェンティック環境を保護するには、境界防御から実行パスの検証への移行が必要である。ツールのメタデータの静的検証とパラメータの可視性は重要な第一歩であり、MCPサーバーに渡されるパラメータが予期されたスキーマに厳密に準拠していることを確認する21。さらに、プラットフォームは多層防御戦略を採用しなければならない。これには、実行のペースを監視する行動異常検出や、エージェントが特定のツールシーケンスを選択した理由を監査するためのモデル決定パスの追跡が含まれる21。状態の書き込みや機密の暗号化シークレットへのアクセスを伴うツールの実行には、ヒューマン・イン・ザ・ループ（HITL）による承認ゲートがプログラムによって強制されなければならない17。

2026年のフレームワークと開発エコシステム

エージェンティック・エンジニアリングをサポートするソフトウェア・エコシステムは、汎用的なLLMラッパーから脱却し、状態、並行性、およびオーケストレーションを管理する高度に専門化されたツールチェーンへと急速に分岐している5。適切なフレームワークの選択は、フレームワークのコア抽象化をエンタープライズ・プロジェクトの支配的な制約に合わせることに根本的に依存している25。

主要なプロダクション・フレームワークとプラットフォーム

  1. LangGraph（プロダクション標準）： LangChainチームによって開発されたこのフレームワークは、エージェントのワークフローを明示的な有向巡回グラフ（状態機械）として扱う23。この明示的な状態管理により、堅牢なロールバック機能、タイムトラベル・デバッグ、およびネイティブのヒューマン・イン・ザ・ループ（HITL）制御を必要とする、高度に複雑で決定論的なエンタープライズ・パイプラインの標準的な選択肢となっている23。
  2. Claude Agent SDK： Anthropicのネイティブ・フレームワークであり、Claude Codeを強化するのと同じアーキテクチャを利用する25。MCPサーバー、フック、およびサブエージェント・オーケストレーションのプロダクション・グレードの統合を提供し、精度を最優先するアプリケーションに最適である23。
  3. CrewAI： 役割ベースの組織構造の抽象化を中心に構築されたCrewAIは、開発者が明示的なペルソナ（例：研究者、査読者）を持つエージェントの「クルー（チーム）」を定義し、階層的なタスクを委譲することを可能にする23。プロトタイピングの障壁は非常に低いが、グラフベースのモデルが提供する深い粒度の状態制御は犠牲にしている25。
  4. Microsoft Agent Framework / Semantic Kernel： AutoGenとSemantic Kernelの後継として開発されたこのエコシステムは、C#やPythonにおけるエンタープライズ・グレードの状態管理、テレメトリ、および厳格な型付けと、動的なエージェント・ルーティングを融合している10。.NETおよびAzureインフラストラクチャに投資している企業にとって最適な選択肢である25。
  5. Pydantic AI： Pythonの型システムを活用し、厳密な入出力検証を強制することで、FastAPIレベルの人間工学をエージェント設計にもたらす。構造的なガードレールをネイティブに処理し、フォーマット関連のハルシネーションを劇的に削減する12。
  6. LlamaIndex Workflows： エージェントの主な責任がインデックス化されたプライベートデータ（RAG）のクエリと推論である場合に最も強力なオプションとなる23。
  7. ノーコード / ローコードの代替案： 視覚的ビルダーや規制産業向けのソリューションとして、Gumloop（コード不要のエージェント構築）、StackAI（規制産業向け）、n8n（セルフホスト型ワークフロー自動化）などがエンタープライズ展開のギャップを埋めている27。

Alice Labsのプロダクション展開基準が示す通り、フレームワークの選定だけでは不十分であり、可観測性（LangSmithやLangfuseの統合）、評価ハーネス、およびガードレール（NeMo Guardrailsなど）の非フレームワーク・コンポーネントの実装が本番環境での成功を左右する25。

エージェンティック・プラットフォーム・エンジニアリングとエンタープライズの拡張

プラットフォーム・エンジニアリング組織が拡大するにつれて、スクリプトベースのCI/CDや宣言型のInfrastructure as Code（IaC）などの従来の静的な自動化は、現代のクラウド環境の動的でコンテキスト豊富な現実を処理できなくなっている3。スクリプトは事前定義されたコマンドを実行できるが、ユーザーの意図を解釈したり、競合する運用上の制約（コストとセキュリティなど）について推論したり、ネットワーク障害時に動的に適応したりする能力に欠けている28。この摩擦から生まれたのが、「エージェンティック・プラットフォーム・エンジニアリング（Agentic Platform Engineering）」である。これは、目標主導型でコンテキストを認識するAIを、組織のコントロールプレーン（ID管理、ポリシー、ガードレール）に直接統合するパラダイムである3。

この統合の基本原則は「境界付けられた自律性（Bounded Autonomy）」である28。エージェントは、プラットフォームによって定義されたセキュリティ・ポリシー、アイデンティティ管理、およびコスト制約という厳格なガードレール内で展開され、インフラストラクチャのテレメトリを推論し、人間のエンジニアに代わって安全なアクションを実行する28。人間のエンジニアは、単なるコードの記述者から、エージェントが働くための制約や仕様を定義する「システム設計者（System Designer）」へと役割を変容させている29。

ケーススタディ：Thomson Reuters と Amazon Bedrock AgentCore

アージェンティック・プラットフォーム・エンジニアリングの最も優れた適用例は、Thomson Reuters（TR）によって展開されたアーキテクチャに見られる。データベースのパッチ適用、クラウドアカウントのプロビジョニング、情報セキュリティおよびリスク管理（ISRM）操作など、手動で反復的なクラウド運用におけるボトルネックに直面していたTRは、Amazon Bedrock AgentCoreを利用して「アージェンティック・プラットフォーム・エンジニアリング・ハブ」を構築した17。

システムのセキュリティ侵害を防ぐため、TRはLangGraph上に構築されたモジュラー・アーキテクチャを展開した17。生のユーザープロンプトがインフラストラクチャ・レイヤーと直接対話することを許可するのではなく、「Aether」と呼ばれる中央のオーケストレーターがクエリを傍受する。オーケストレーターは、Amazon DynamoDB上に構築された独自のエージェント・レジストリからコンテキスト要件を取得し、決定論的なツール呼び出しを介してプログラム的にデータを入力する17。これにより、プロンプト・インジェクション・ベクトルが効果的に無効化される17。開発と展開を簡素化するため、TRは「TRACK（TR-AgentCore-Kit）」と呼ばれる独自のフレームワークを構築し、AgentCoreランタイムとの接続やコンプライアンス要件への準拠を自動化した17。

この実装では、高度に専門化されたドメイン・エージェントが機能する。たとえば、クラウドアカウント・プロビジョニング・エージェントは、セキュリティポリシーやベースライン・ネットワークの適用を自律的に行い、データベース・パッチ適用エージェントはバージョン・アップグレードのライフサイクル全体を処理する17。重要なのは、この展開が「Aether Greenlight」と呼ばれるヒューマン・イン・ザ・ループ（HITL）検証サービスに依存していることである。このサービスは、2次的な人間の暗号化された承認が登録されるまで、機密性の高いインフラストラクチャ変更の実行を強制的に停止する17。このアーキテクチャは、コンプライアンスと監査可能性を維持しながら、エンジニアリング・チームから膨大な認知的負荷を軽減する方法を見事に実証している17。Signal65の調査データは、AgentCoreなどのインフラストラクチャを導入することで、インフラ構築に費やす時間を根本的に削減し、エンドツーエンドのエージェント開発を大幅に加速できることを示唆している17。

評価指標とベンチマーキング：CLASSicフレームワークと実環境テスト

生成されたテキストから自律的な行動への移行は、AIの評価パラダイムを根本的に破壊する。LLMを純粋にテキストの正確さ（Accuracy）のみに基づいて評価することは、コードを実行し、データベースを変更し、計算リソースを消費するエージェントを評価する場合には著しく不十分である30。自律型システムは環境からの継続的なフィードバックに適応しながらループ内で反復的に動作するため、評価は意思決定プロセス全体のライフサイクルを測定するものでなければならない30。さらに、パフォーマンスエンジニアリングの原則（アムダールの法則やボトルネックの特定など）に従い、ユニットテスト、統合テスト、およびE2E（エンドツーエンド）テストを網羅した自動化テストフレームワークが不可欠である32。この多次元の複雑さに対処するため、業界は「CLASSic評価フレームワーク」を中心に標準化を進めている30。

CLASSic評価フレームワークの次元

CLASSic方法論は、エンタープライズの準備状況を5つの重要な軸にわたって包括的に評価する。

評価次元

測定の焦点とビジネス上の意義

コスト（Cost）

エージェントはループ内で動作するため、1つのタスクに数十回の推論が必要になる場合がある。API使用料や、成功したワークフロー実行あたりの総トークン消費量を測定する30。

遅延（Latency）

認識-計画-行動の実行ループの累積速度を追跡する。ツールの応答が遅延すると、同期ワークフローでのシステムタイムアウトやユーザーエクスペリエンスの低下を招く30。

正確性（Accuracy）

テキストの正しさだけでなく、最終的な目標状態を達成するために外部環境を正常に操作・変更できたか（タスク成功率）を測定する30。

セキュリティ（Security）

敵対的な操作、間接的なプロンプト・インジェクションに対する回復力、およびツール使用時の最小特権データアクセスモデルの遵守状況を評価する30。

安定性（Stability）

ドリフトするデータパターンや変化する入力に対するエージェントの堅牢性と、複数の非決定論的な実行にわたって同一の結果に到達する一貫性を評価する30。

産業界に特化したベンチマーク環境

これらの次元を定量化するために、学術界および産業界の研究者は、実際の運用上の曖昧さをシミュレートする厳格な環境ベースのベンチマークを展開している31。

  • SWE-bench / SWE-bench-Pro： ソフトウェアエンジニアリングに特化した非常に厳格なベンチマーク。エージェントは数千の実際のGitHubイシューを解決することを強制される。エージェントはリポジトリをナビゲートし、コードを記述し、隔離された実行環境内でユニットテストに合格する必要があり、手続き的および推論的能力を直接テストする31。
  • WebArena / WebShop： ブラウザ環境でのエージェントの能力を評価する。エージェントは、直接的なAPIアクセスなしで、動的なグラフィカルユーザーインターフェース（GUI）をナビゲートし、マルチステップの対話を完了し、複雑なDOM構造を解析する能力が試される31。
  • GAIA： 多様なモダリティにわたる一般的な推論と実世界のタスク実行を測定し、非定常的な分布の下での長期間の適応性を示す重要な指標として機能する31。

評価データによれば、タスクに特化したドメイン固有のアージェンティック構成は、多くの場合、汎用的な最先端（Frontier）モデルよりも、数倍低いコストで大幅に高いタスク成功率（精度）を確実に達成する。これは、適切に設計された「ハーネス」が、単に巨大なパラメータスケールよりも優れているという前提を強力に裏付けている39。

産業別の実世界アプリケーションとユースケース

エージェンティック・アーキテクチャの成熟により、企業は実験的なパイロット段階を超え、収益を積極的に生み出したり、システミックリスクを直接軽減したりする本番環境の展開へと移行している40。これらのシステムはリアルタイムのデータに推論を適用することで、エンタープライズ運用のユニットエコノミクスを根本的に変化させている40。

サイバーセキュリティとIT運用： エージェンティック・エンジニアリングは、自律的な脅威の修復への移行を促進している。セキュリティ・エージェントは、単に人間にレビューのために異常をフラグ付けするのではなく、ネットワークのテレメトリを自律的に合成し、侵害されたワークロードを隔離するための一時的なファイアウォール・ルールを記述し、悪意のある攻撃者を罠にかけるための「ハニートークン（Honeytokens）」を展開することで、機械の速度でTier-1の脅威を無力化する42。ITサービス管理においては、エージェントがIDプロバイダーやデバイス管理APIと直接統合することで、VPNの障害を診断し、ソフトウェアを動的にプロビジョニングする43。

財務運用とウェルスマネジメント： 金融のコンテキストでは、アージェンティック・システムが継続的なコンプライアンス・チェックとポートフォリオの再調整を実行する。特化型のアロケーター・エージェントは、構造化商品のペイオフをシミュレートし、リアルタイムのリスクヘッジを管理することで、年間数千万ドルに及ぶ運用上の損失を削減している44。さらに、バイテンポラル（二時点）データベースを利用するエージェントは、正確な履歴データ状態を即座に再現でき、アルゴリズム取引が人間の遅延なしに厳格な規制監査に準拠し続けることを保証する44。

サプライチェーンと製造業： サプライチェーン・エージェントは、マクロ経済のセンチメント、IoTテレメトリ、および局所的な天候の混乱を継続的に監視し、グローバルな出荷ルートを動的に変更し、在庫戦略を精緻化する43。製造業においては、コンピュータ・ビジョンの入力がアージェンティックな制御ループに供給され、生産の実行を最適化する。さらに、リアルタイムの音響および熱の異常に基づいて、設備のメンテナンスを自律的に事前スケジュールすることで、ダウンタイムを最小限に抑えている43。人事（HR）領域においても、エージェントは履歴書のスクリーニングや面接のスケジューリングを自律的に行い、バックオフィスの業務効率を抜本的に改善している43。

結論：2026年以降の戦略的要請

生成型チャットボットからエージェンティック・エンジニアリングへの移行は、ソフトウェア・アーキテクチャの根本的な再構築を意味する。テクノロジー・エコシステムの根底にある力学は逆転した。主な競争優位性はもはや生の基盤モデルのインテリジェンスではなく、エージェンティック・ハーネスの構造的な洗練度と、MCPのようなツール統合プロトコルの流動性にある。

この市場は漸進的な改善ではなく、カテゴリの創造の市場である5。2026年の時点で、Cursorが年間経常収益（ARR）で10億ドルを突破し、Devinが価格を月額500ドルから20ドルへと劇的に引き下げ、Replitが90億ドルの評価額を達成した事実は、ソフトウェア開発における「1000倍の開発者（1000x developer）」の台頭を裏付けている5。AnthropicのCEOであるDario Amodeiが述べるように、「コーディングそのものが最初に消滅する」現象は遠い未来の話ではなく、自然言語をデプロイされたインテリジェントなシステムに変換するプラットフォームによって、2026年現在すでに進行中である5。

基盤モデルがコモディティ化するにつれて、状態（ステート）を維持し、非決定論的な環境において決定論を確保し、自律的なツールの実行を保護するために必要なエンジニアリングの規律が、エンタープライズ・ソフトウェアの絶対的な差別化要因となる。AIを単なるテキスト生成ツールとして捉え、「技術が成熟するのを待つ」組織は、急速に技術的負債を蓄積し、これらのシステムを数年にわたって反復してきた組織との競争に敗れることになる45。

決定的な証拠は提示されている。継続的な観察、計画、および実行が可能な自律型システムを展開することは、複利的な組織的優位性を生み出す。堅牢なプラットフォーム・エンジニアリングを通じて境界付けられた自律性を確立し、CLASSicフレームワークを通じて厳格なパフォーマンス標準を強制することにより、企業は複雑でマルチステップのワークフローを機械知能に安全に委譲することができる。2026年において、「エージェント・フレンドリー（Agent-Friendly）なシステム設計」は決定的な競争上の「堀（Moat）」である。自らの機能をAPIやMCPを介してエージェンティックな操作に公開できない製品は、競合他社のエージェントによって容赦なく迂回されるだろう6。エージェンティック・エンジニアリングは、ソフトウェア開発の未来ではなく、すでに進行中の不可逆的な運用上の現実である。

引用文献

  1. What Is Agentic Engineering? Complete History: From … – Taskade, 5月 19, 2026にアクセス、 https://www.taskade.com/blog/what-is-agentic-engineering
  2. The Age of Agentic Engineering: A Comprehensive Guide to AI-Assisted Coding (Part 3) | by Padmaraj M | Medium, 5月 19, 2026にアクセス、 https://medium.com/@padmaraj.m/the-age-of-agentic-engineering-a-comprehensive-guide-to-ai-assisted-coding-part-3-02daaca53c8a
  3. Agentic Platform Engineering: How to Build an Agent Infrastructure That Scales From Your Laptop to the Enterprise – DEV Community, 5月 19, 2026にアクセス、 https://dev.to/sarony11/agentic-platform-engineering-how-to-build-an-agent-infrastructure-that-scales-from-your-laptop-to-11np
  4. From Prompts to Harnesses — Four Years of AI Agentic Patterns, 5月 19, 2026にアクセス、 https://bits-bytes-nn.github.io/insights/agentic-ai/2026/04/05/evolution-of-ai-agentic-patterns-en.html
  5. 12 Best Agentic Engineering Platforms and AI Tools (2026) – Taskade, 5月 19, 2026にアクセス、 https://www.taskade.com/blog/agentic-engineering-platforms
  6. State of AI Agents & Agentic Engineering 2026 – Metavert, 5月 19, 2026にアクセス、 https://www.metavert.io/state-of-ai-agents-2026
  7. How Agentic AI Systems Execute Multi-Step Workflows (Architecture …, 5月 19, 2026にアクセス、 https://dev.to/eric_weston_970c1bf3e9146/how-agentic-ai-systems-execute-multi-step-workflows-architecture-stack-29a5
  8. Effective context engineering for AI agents – Anthropic, 5月 19, 2026にアクセス、 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  9. Agentic AI architecture: Planning, memory, and tool-use – Moxo, 5月 19, 2026にアクセス、 https://www.moxo.com/blog/agentic-ai-architecture
  10. AI Agent Orchestration Patterns – Azure Architecture Center …, 5月 19, 2026にアクセス、 https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
  11. What is AI Agent Orchestration? – IBM, 5月 19, 2026にアクセス、 https://www.ibm.com/think/topics/ai-agent-orchestration
  12. What are the best tools and frameworks for building AI agents in 2026? : r/AI_Agents – Reddit, 5月 19, 2026にアクセス、 https://www.reddit.com/r/AI_Agents/comments/1sfrb3t/what_are_the_best_tools_and_frameworks_for/
  13. Introducing the Model Context Protocol – Anthropic, 5月 19, 2026にアクセス、 https://anthropic.com ews/model-context-protocol
  14. What is the Model Context Protocol (MCP)?, 5月 19, 2026にアクセス、 https://modelcontextprotocol.io/docs/getting-started/intro
  15. Protecting against indirect prompt injection attacks in MCP – Microsoft for Developers, 5月 19, 2026にアクセス、 https://developer.microsoft.com/blog/protecting-against-indirect-injection-attacks-mcp
  16. New Prompt Injection Attack Vectors Through MCP Sampling – Unit 42 (Palo Alto Networks), 5月 19, 2026にアクセス、 https://unit42.paloaltonetworks.com/model-context-protocol-attack-vectors/
  17. How Thomson Reuters built an Agentic Platform Engineering Hub …, 5月 19, 2026にアクセス、 https://aws.amazon.com/blogs/machine-learning/how-thomson-reuters-built-an-agentic-platform-engineering-hub-with-amazon-bedrock-agentcore/
  18. What is Model Context Protocol (MCP)? – IBM, 5月 19, 2026にアクセス、 https://www.ibm.com/think/topics/model-context-protocol
  19. Code execution with MCP: building more efficient AI agents – Anthropic, 5月 19, 2026にアクセス、 https://www.anthropic.com/engineering/code-execution-with-mcp
  20. Model Context Protocol (MCP): Understanding security risks and controls – Red Hat, 5月 19, 2026にアクセス、 https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls
  21. [2603.22489] Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning – arXiv, 5月 19, 2026にアクセス、 https://arxiv.org/abs/2603.22489
  22. Model Context Protocol has prompt injection security problems – Simon Willison’s Weblog, 5月 19, 2026にアクセス、 https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/
  23. Top AI Agent Frameworks in 2026: A Production-Ready Comparison | by Pratik K Rupareliya, 5月 19, 2026にアクセス、 https://pub.towardsai.net/top-ai-agent-frameworks-in-2026-a-production-ready-comparison-7ba5e39ad56d
  24. I Tried 20+ AI Frameworks: Here are My Top 10 Recommendations for 2026 | by Soma | Javarevisited | Mar, 2026, 5月 19, 2026にアクセス、 https://medium.com/javarevisited/i-tried-20-ai-frameworks-here-are-my-top-10-recommendations-for-2026-927168fed61c
  25. AI Agent Frameworks 2026: Production-Tested Ranking by Alice Labs, 5月 19, 2026にアクセス、 https://alicelabs.ai/en/insights/best-ai-agent-frameworks-2026
  26. Top 5 AI Agent Frameworks in 2026 — Tested Across 100+ Production Deployments – Intuz, 5月 19, 2026にアクセス、 https://www.intuz.com/blog/top-5-ai-agent-frameworks-2025
  27. 6 best AI agent frameworks (and how I picked one) in 2026 – Gumloop, 5月 19, 2026にアクセス、 https://www.gumloop.com/blog/ai-agent-frameworks
  28. The rise of agentic platforms: Scaling beyond automation, 5月 19, 2026にアクセス、 https://platformengineering.org/blog/the-rise-of-agentic-platforms-scaling-beyond-automation
  29. DevOps Playbook for the Agentic Era | All things Azure – Microsoft Developer Blogs, 5月 19, 2026にアクセス、 https://devblogs.microsoft.com/all-things-azure/agentic-devops-practices-principles-strategic-direction/
  30. What is AI Agent Evaluation: A CLASSic Approach for Enterprises – Aisera, 5月 19, 2026にアクセス、 https://aisera.com/blog/ai-agent-evaluation/
  31. A Survey of Self-Evolving Agents What, When, How, and Where to Evolve on the Path to Artificial Super Intelligence – arXiv, 5月 19, 2026にアクセス、 https://arxiv.org/html/2507.21046v4
  32. The Complete Guide to Agentic Coding in 2026 – TeamDay.ai, 5月 19, 2026にアクセス、 https://www.teamday.ai/blog/complete-guide-agentic-coding-2026
  33. An agentic playbook for production-scale performance fixes: How we cut p95 latency by 30x in 24 hours without new infra – EPAM, 5月 19, 2026にアクセス、 https://www.epam.com/insights/ai/blogs/agentic-playbook-for-production-scale-performance-fixes
  34. 5月 19, 2026にアクセス、 https://aisera.com/blog/ai-agent-evaluation/#:~:text=The%20CLASSic%20Evaluation%20Framework&text=This%20framework%20evaluates%20agents%20across,agent’s%20logic%20and%20final%20output.
  35. Agentic AI Evaluation: Ensuring Reliability and Performance – TechAhead, 5月 19, 2026にアクセス、 https://www.techaheadcorp.com/blog/agentic-ai-evaluation-ensuring-reliability-and-performance/
  36. AI benchmarking framework measures real-world effectiveness of AI agents – Aisera, 5月 19, 2026にアクセス、 https://aisera.com/blog/enterprise-ai-benchmark/
  37. A Survey of Self-Evolving Agents – OpenReview, 5月 19, 2026にアクセス、 https://openreview.net/pdf/3345d492f049f49353081001b10c99e2d7124cc5.pdf
  38. Daily Papers – Hugging Face, 5月 19, 2026にアクセス、 https://huggingface.co/papers?q=meta%20agent
  39. Beyond Accuracy: A Multi-Dimensional Framework for Evaluating Enterprise Agentic AI Systems – arXiv, 5月 19, 2026にアクセス、 https://arxiv.org/html/2511.14136v1
  40. Agentic AI, explained | MIT Sloan, 5月 19, 2026にアクセス、 https://mitsloan.mit.edu/ideas-made-to-matter/agentic-ai-explained
  41. What industries already use agentic AI in production? : r/AI_Agents – Reddit, 5月 19, 2026にアクセス、 https://www.reddit.com/r/AI_Agents/comments/1t5837y/what_industries_already_use_agentic_ai_in/
  42. Real-world gen AI use cases from the world’s leading organizations | Google Cloud Blog, 5月 19, 2026にアクセス、 https://cloud.google.com/transform/101-real-world-generative-ai-use-cases-from-industry-leaders
  43. 10 Agentic AI Examples and Use Cases – Boomi, 5月 19, 2026にアクセス、 https://boomi.com/blog/10-agentic-ai-use-cases/
  44. Real-world agentic AI use cases across industries – Grid Dynamics, 5月 19, 2026にアクセス、 https://www.griddynamics.com/blog/agentic-ai-use-cases
  45. Why Multi-Agent Engineering Teams Will Replace Traditional Dev Shops by 2027 – Medium, 5月 19, 2026にアクセス、 https://medium.com/@ailoittetech/why-multi-agent-engineering-teams-will-replace-traditional-dev-shops-by-2027-ea05b66d92ba

次に読む

用語集
Contents