AI導入からエージェント主導の運用へ：HBSの「AI in 2026」コレクションがエンタープライズAIにもたらす意味

HBS Working Knowledgeの「AI in 2026」研究コレクションは、「導入からエージェントへ（From Adoption to Agentic）」というテーマで構成されています。当社のインフラストラクチャの解釈では、これは以下への移行を意味します。 業務の委任（delegated execution）AIが複数のステップ、ツール、システム、そして人々の間をまたいで業務を遂行できるようになれば、企業は「システムに何を許可し、誰の権限で、どのような管理下で実行させ、事後にどのような証跡を残すか」を決定しなければなりません。

1. 重要な変化は、プロンプトから「より良いプロンプト」への進化ではない

多くの初期の企業向け生成AIプログラムは、アクセスと導入に重点を置いていました。エージェント型システムは、作業の単位を拡大します。単一のやり取りで回答を得るのではなく、一連の実行プロセスの中で、モデルの呼び出し、ツールの使用、状態の保持、承認、再試行、そして外部への副作用を伴う処理が可能になります。

これにより、運用のあり方が変わります。プロンプトは情報や変換を要求するものですが、エージェントの実行は以下のようなものになり得ます。 業務の委任。

これこそが、HBSの研究全体を貫くテーマです。リーダーシップに関する論文では、経営陣がデジタル・サポート・チームを得たときに何が起こるかを問い、職務に関する研究では、人々がどのような業務を委任したいと考えているかを調査しています。チームワークの研究では、AIが共同作業の成果をいつ向上させるかを考察し、融資の研究では、アルゴリズムが重要な意思決定を行う際に人々が何を重視するかを問い、人材密度に関する議論では、組織がいかにして希少な専門知識を組織的な優位性に変換するかを論じています。

2. HBSのテーマ1：リーダーシップは「オーケストレーション」へ

論文 「エージェント型AIの世界におけるリーダーシップのあり方（What Leadership Looks Like in an Agentic AI World）」の中で、Tsedal Neeley氏とRitcha Ranjan氏は、エージェント型AIをリーダーのための潜在的なデジタル・サポート・リソースとして定義しています。それは、情報を収集し、組織の優先事項に基づいて統合し、リーダーの対話準備を整え、複雑な業務を半自律的に遂行できるシステムです。

ここでの技術的な意味合いを見落としてはいけません。有用な「デジタル・サポート・チーム」は、単一のステートレスな完了処理としてモデル化することはできません。課題を保持し、複数のやり取りをまたいで動作し、ツールを使いこなし、判断が必要な場面で一時停止し、何が起きたかを可視化できるランタイムが必要なのです。

これこそが、 エージェント・ハーネス（agent harness） が果たす役割です。 TrueForgeの公式ドキュメントでは TrueForgeは、LLMの周囲でモデルやツールの実行ループを回し、長期タスクのコンテキスト管理、MCPツールやスキルのサポート、必要に応じたサンドボックス環境での実行、人間による承認待ちの停止、サブエージェントのサポート、そして再接続や再起動をまたいだセッションの永続化を行う「エージェントハーネス」として機能します。

主張の範囲は限定的であるべきです。TrueForgeはエージェントの実行を永続的かつ検証可能なものにすることはできますが、リーダーの優先順位を決定したり、どのタスクを委任すべきかを判断したり、優れたリーダーシップとは何かを理解したりすることはできません。

3. HBSのテーマ2：タスクは自動化しても、責任は自動化しない

自動化に対する一般の意識に関するジェームズ・ライリー氏のHBSでの研究では、 940の職種にわたる2,357人を対象に調査が行われました。回答者は、現在の能力の範囲内であれば、仕事の約 30% の自動化を支持しました。AIが人間を上回るパフォーマンスを低コストで実現すると想定した場合、その支持率は 58%にまで上昇しました。しかし、社会的または道徳的な観点から自動化に抵抗を感じる職種も依然として存在しています。

エンタープライズアーキテクチャにとって重要な教訓は、見出しとなるパーセンテージそのものではありません。それは、 委任の境界線は状況によって異なるということです。無人で実行可能な作業もあれば、人間による補完が必要な作業もあります。また、モデルが技術的に実行可能であっても、人間による判断を必要とすべき作業も存在します。

このことは、単一の普遍的な「自律モード」という考え方に異を唱えるものです。本番システムには、以下のような明確な制御ポイントが必要です。

• このエージェントはどのモデルやツールにアクセスできるか？
• どの操作が介入なしで実行可能か？
• どの操作に人間の承認が必要か？
• 最終的な副作用に対して、どのダウンストリームシステムが権限を持つか？
• ポリシー、予算、または承認によって拒否された場合、どう対処するか？

TrueFoundry MCP Gateway は、レジストリと検出、インバウンドID、ツールレベルのアクセス制御、ダウンストリームの認証情報、ツール実行前後のガードレール、承認ワークフロー、ゲートウェイ経由のMCPトラフィックの監査といった、共有ツール境界に自然にマッピングされます。 AIゲートウェイ は、統合アクセス、RBAC、レート制限、予算管理、ルーティング／フォールバック、ガードレール、可観測性を備えた、対応するモデル境界を提供します。

本番環境の認可においても、個別のプリンシパルを維持する必要があります。人間やワークロードは、 サブジェクト として、その代理で作業が行われます。登録されたエージェントは、 アクター として呼び出しを行い、ダウンストリームのサービスがそのターゲットに対して設定された認証情報とビジネス上の権限を適用します。TrueFoundryの ベータ版エージェントID 設計では、呼び出し元エージェントを個別に識別・認可しつつ、ユーザーやサービスを追跡可能です。ただし、これだけではビジネス上の権限付与にはなりません。つまり、 process_refund を実行する権限と、特定の注文に対して特定の金額を返金する権限は別物です。

どちらのゲートウェイも、基盤となるビジネス上の意思決定を代行するわけではありません。返金、融資、デプロイ、権限変更などにドメイン固有の認可ルールがある場合、それらのルールは依然として関連するポリシーおよび記録システムに属します。

4. HBSのテーマ3：AIはチームメイトになり得るが、チームワークには共有インフラが必要である

HBSの記事 「When AI Joins the Team, Better Ideas Surface（AIがチームに加わると、より良いアイデアが生まれる）」 は、 プロクター・アンド・ギャンブル（P&G）の専門家791名を対象としたフィールド実験について報告しています。実験において、AIを活用したチームは最高品質のソリューションを生み出しました。上位10%のアイデアは、AIを使用しない個人と比較して、AIを活用したチームから生まれる確率が3倍高くなりました。また、AIは完了時間を個人で16%、チームで13%短縮しました。最終的な査読済み研究は、 『Organization Science』誌 に掲載されました。 2026年には。

だからといって、すべての企業がエージェントを大量に導入すべきだというわけではありません。むしろ、より本質的な示唆があります。それは、AIを適切に設計された業務システムに組み込むことで、専門知識へのアクセスを広げ、部門間の壁を取り払うことができるということです。

インフラチームにとって、これは再利用性の問題を提起します。各チームが独自のモデルアダプター、ツール認証、エージェントループ、承認UX、スキル、トレースを構築すれば、組織内では局所的な加速が得られても、全体としては断片化が進んでしまいます。

よりスケーラブルなパターンは以下の通りです。

• TrueForge エージェント実行のオープンなランタイムメカニズムとして。
• AI Gateway 共有モデルへのアクセスおよびモデル側のポリシー管理として。
• MCP Gateway ガバナンスの効いたツールおよびデータアクセスとして。
• Skills Registry エージェント間で再利用可能な、バージョン管理された手順知識として。
• Agent Registry リモートエージェントを含む登録済みエージェントの共通インベントリ、アクセスインターフェース、メトリクス、およびトレースとして。

組織にもたらされるメリットは「エージェントの数が増えること」ではありません。有用な実践手法が、特定のプロンプトや開発者のPC、あるいは特定のチームのプライベートな統合環境の中に閉じ込められることなく、再利用可能になることです。

5. HBSのテーマ4：重要な意思決定にはパフォーマンスと と エビデンスが必要である

人間とアルゴリズムによる意思決定者を比較したエリザベス・ポールソンの研究では、 約9,000人の参加者を対象に調査が行われました融資のシナリオでは、参加者がアルゴリズムよりも人間の銀行マネージャーを選ぶ確率は4.3ポイント高いという結果が出ました。参加者は依然として人間による意思決定を好む傾向にありましたが、調査の結果、意思決定者が人間かアルゴリズムかということよりも、その意思決定者のパフォーマンス特性が総合的に重要であることが判明しました。

これは、公平性、合法性、適正手続きを犠牲にしてもよいという証拠ではありません。この調査自体は、2つのコンジョイント分析を通じて表明された選好を評価したものであり、自動意思決定システムを導入する際の現実世界における妥当性を評価したものではありません。より強力なシステムに関する教訓は、より限定的なものです。つまり、パフォーマンスに関する主張には測定可能な証拠が必要であり、一方で、法的、倫理的、プライバシー、公平性、透明性、および実装上の義務は個別に評価されなければならないということです。

そのためには、少なくとも以下の4つの層を分離する必要があります。

TrueForgeの エージェント → セッション → ターン → イベント モデルは、実行時の証拠を保持できます。TrueFoundryゲートウェイは、そこを通過するトラフィックに対してリクエストおよびツール境界のテレメトリを追加します。これらの記録はデバッグ、レビュー、評価、監査のための有用な基盤となりますが、 トレースそのものは評価者ではありませんであり、承認は認可の代わりにはなりません。

6. HBSの5つ目のテーマ：タレント密度が引き起こす再利用の問題

HBS Working Knowledgeによるボリス・グロイスバーグ氏へのインタビューでは、優秀なAI人材を獲得することよりも、その知識が組織全体で蓄積されるように統合することの方が難しいという点が中心的な議論となっています。「タレント密度」とは単に優秀な人材の数だけを指すのではなく、重要な役割に強力な人材を配置し、彼らの専門知識が周囲のシステムのパフォーマンスを変えるような環境を作り出すことを意味します。

この研究は、インフラストラクチャに示唆を与えています。非常に有能なAIエンジニアは、認証、プロバイダーアダプター、ツール認証情報の管理、承認状態、コスト計算、トレースの仕組みをアプリケーションごとに作り直すのではなく、アーキテクチャ、評価、製品判断、モデルやツールの選択、そしてビジネス独自のロジックといった、希少な時間を割くべき領域に集中すべきです。

TrueFoundryスキルレジストリ は、この文脈において特に重要です。これは、リポジトリのRBAC（ロールベースアクセス制御）、バージョン履歴、監査を備えた、再利用可能でバージョン管理されたエージェントスキルの共有カタログを提供します。これにより、有用な手順が個人のテクニックから組織の資産へと変わります。同じ原則が、登録済みエージェント、ゲートウェイポリシー、ルーティングルール、予算、共有オブザーバビリティにも適用されます。

7. 組織的な知見からエージェント型オペレーティングモデルへ

HBSの5つのテーマを統合すると、「人間がすべてを承認する」わけでも「エージェントがすべてを実行する」わけでもない、エンタープライズ向けのオペレーティングモデルが浮かび上がります。それは、階層化された委任システムです。

8. 企業は今、何を標準化すべきか？

HBSの研究は組織論に関するものであり、ソフトウェアアーキテクチャの仕様書ではありません。しかし、AIがチームメイト、代理人、意思決定の参加者として機能するようになるという前提を組織が受け入れるならば、インフラストラクチャに関する一連の問いは避けて通れません。

1. エージェントのランタイムを標準化すること。 セッションの永続化、ツールの検出、コンテキスト管理、コードの分離、承認による実行の一時停止、イベントの記録方法を定義してください。
2. モデルポリシーをアプリケーションコードから分離すること。 プロバイダーの認証情報、アクセス制御、ルーティング、予算、レート制限、ガードレール、およびモデルのテレメトリを可能な限り一元管理してください。
3. エンタープライズツールには、明確なIDとポリシーによる保護を適用してください。 人間またはワークロードの主体を保持し、エージェントの実行者を特定した上で、ダウンストリームでのビジネス上の承認を強制してください。ツールは、MCPに対応しているというだけで安全になるわけではありません。
4. HITL（人間による介入）は、スコープ化されたランタイムの状態遷移として設計してください。 実行は副作用が発生する前に一時停止し、保留中のアクションを正確に保持し、レビュアーの決定を記録した上で、永続化された状態から再開する必要があります。承認は、重要な状態変更が発生した後に期限切れとなるか、再検証されるべきです。
5. 成果の証跡を保持してください。 ランタイムトレースはエージェントが何を試みたかを説明し、記録システムは実際に何が起こったかを証明します。
6. 優れた手順を再利用可能な成果物に変えてください。 スキル、ポリシー、エージェント定義、および評価は、コピーされたプロンプトの中に埋め込むのではなく、バージョン管理を行うべきです。
7. ビジネス上の説明責任はモデルの外側に置いてください。 何が重要か、何が許可されるか、そして何が成功とみなされるかを決定するのは、依然として人間のオーナーと権威あるシステムです。

具体的な制御パス：返金処理

TrueForgeドキュメントにある get_order および process_refund ツールを使用するサポートエージェントを例に挙げます。本番環境のパスは、顧客のリクエスト、セッション、およびIDコンテキストを永続化することから始まります。エージェントはMCPゲートウェイを通じて注文情報を取得できますが、ツールの到達可能性は最初のチェックに過ぎません。アプリケーションや注文システムは、その顧客（または顧客を代理するサービス）がその注文にアクセス可能であること、およびその注文が返金対象であることを確認する必要があります。

モデルが process_refundを提案した場合、ランタイムは変更を加える前に保留中のアクションを作成する必要があります。その記録は、特定の注文、金額、理由、操作ID、および関連するポリシーやデータのバージョンに承認を紐付けるものです。レビュアーが承認するのは、抽象的なツールや将来のあらゆる引数セットではなく、その特定のアクションです。実行が一時停止されている間に注文内容に重大な変更があった場合、そのアクションは再検証されるか、再度承認のために送り返されるべきです。

承認後、TrueForgeは永続化された状態から連鎖セッションを継続できます。変更を伴うリクエストには、冪等性キーまたは安定した操作IDを含める必要があります。接続がタイムアウトした場合、システムは失敗と見なして盲目的に返金処理を再試行すべきではありません。権威ある注文システムや決済システムと照合を行い、記録された結果が許可する場合にのみ再試行する必要があります。この区別は、 エージェントが返金を試みることを決定した時点、 ツール呼び出しが実行された時点、そして 返金が実際に確定した時点。

TrueForgeのイベントとGatewayのトレースにより、提案、ポリシーチェック、承認、呼び出し、応答、レイテンシ、コストを関連付けることができます。記録システム上の領収書が、権威ある結果の証拠となります。評価者は、結合された記録（オフライン回帰セット、軌跡やタスク成功のチェック、デプロイ後の結果監視など）に基づいて運用できます。その際、トレース自体が品質を保証すると錯覚してはなりません。このプラットフォームの価値は、ランタイム状態、モデルポリシー、ツールポリシー、ID、承認、証拠といった境界の整合性にあります。これらは接続された状態を保ちつつ、ビジネス上の承認と最終的な真実はドメインシステム側に残されます。

9. より深い視点：エージェント型AIは組織のシステム課題である

「導入からエージェントへ」という言葉は、責任の所在が明確に変化することを意味するため有用です。AIがツールである場合、人間が作業を行い、AIはそれを支援します。AIがエージェント化すると、作業の一部は、中間ステップを選択し外部機能と対話できるシステムへと委譲されます。

だからこそ、エンタープライズ向けエージェントのアーキテクチャは、モデルの選定だけで完結してはならないのです。組織には、委譲された作業のためのランタイムと、その作業がアクセスできるリソースを制御するコントロールプレーンが必要です。

TrueForge は、このランタイム層を実現するためのTrueFoundryのオープンソース・エージェントハーネスです。 AI Gateway、 MCP Gateway、 Agent Registry、そして Skills Registry モデル、ツール、エージェント、および手順に関する知識を横断的に制御・再利用するための基盤を提供します。これらは組織の判断に取って代わるものではありません。これらを組み合わせることで、ポリシーのコード化、アクセス権の管理、実行記録の保持、そしてエージェントの挙動を継続的に改善するためのインフラが構築されます。

参考文献

1. HBS Working Knowledge — エージェント型AI時代におけるリーダーシップのあり方。
2. HBS Working Knowledge — AIによる業務の自動化に対する人々の意識：その許容範囲とは。
3. HBS Working Knowledge — AIがチームに加わることで、より優れたアイデアが生まれる。
4. Organization Science — サイバネティック・チームメイト：生成AIとチームワークに関するフィールド実験。
5. HBS Working Knowledge — 銀行融資の承認は誰が行うべきか：人間か、アルゴリズムか。
6. PNAS Nexus — アルゴリズムと人間による意思決定のパフォーマンスに対する一般の意識。
7. HBS Working Knowledge — AI活用で成功するための鍵は「タレント密度」にある。
8. TrueForge — はじめに。
9. TrueForge — SDKのコンセプト.
10. TrueForge — サンドボックス.
11. TrueFoundry — AIゲートウェイ入門.
12. TrueFoundry — MCPゲートウェイ.
13. TrueFoundry — MCPゲートウェイの認証とセキュリティ.
14. TrueFoundry — エージェントID（ベータ版）.
15. TrueFoundry — エージェントレジストリ.
16. TrueFoundry — スキルレジストリ.

編集上の開示：ハーバード・ビジネス・スクール（HBS）、HBS Working Knowledge、および本記事で取り上げている教員は、本記事とは一切関係がなく、TrueFoundryを推奨するものではありません。HBSの研究は外部フレームワークとして使用されており、製品のマッピングおよびインフラストラクチャに関する結論はすべてTrueFoundryによる編集上の分析です。製品機能は、2026年9月1日時点で公開されているドキュメントに基づいています。

‍