BCGが説く「ツールよりも戦略が重要」 — 第1部:戦略の明確化からゲートウェイ制御へ

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
ボストン コンサルティング グループ(BCG)はこの夏、同じデスクに並べておくべき2つの文書を発表しました。2026年6月には、第4版となる AI at Work 調査(14市場の約11,749人の労働者を対象)が発表されました。この調査では、ツールの利用可能性とAIによる成果の相関よりも、戦略の明確さと測定可能なAIの成果との間に、はるかに大きな相関があることが報告されています。戦略が強固でツールが限定的な場合は、戦略が限定的なベースラインと比較してプラス25ポイントの成果が見られたのに対し、ツールが強固で戦略が限定的な場合はプラス5ポイントに留まりました。これは管理された因果関係の推定ではなく、観察に基づく比較です(bcg.com)。続いて2026年7月初旬、BCGは The Agentic Leadership Playbook: A Scaling Strategy for CTOs and CIOs を発表しました。これは、エージェント型AIの責任者であるマーク・エイブラハム氏とネヴィーン・アワド氏へのインタビューをまとめたもので、調査結果を経営層への提言へと昇華させています。それによると、BCGが定義する「真のエージェントファースト」企業は約5%に過ぎず、大半は導入率30%未満であり、技術スタックやエージェント導入に関する意思決定の約60%を現在CIOやCTOが担っています(bcg.com)。これら2つの文書を併せて読むと、明確な事実が浮かび上がります。戦略の問題は技術リーダーシップの問題へと変貌しており、技術リーダーが直面する問いはアーキテクチャに関するものだということです。すなわち、 戦略を具体的にどこで強制(実行)するのか? パート1では、調査の主要な知見とプレイブックのリーダーシップに関する知見を取り上げ、それぞれをAIゲートウェイ制御にマッピングして、その一部を運用可能にする方法を解説します。 パート2 では、BCGのエージェントに関する知見を掘り下げ、MCPゲートウェイとエージェントハーネスについて解説します。BCGが課題を診断し、本シリーズではその対応策の一部を運用可能にするコントロールプレーン・アーキテクチャを提示します。なお、これはTrueFoundryによる編集上の統合であり、BCGの推奨事項ではありません。
1. BCGとは何か、そして本シリーズが読み解く2つの文書
ボストン コンサルティング グループは世界最大級の経営コンサルティングファームであり、そのAI調査は予算決定の現場で参照されています。本シリーズが依拠する2つの文書は、それぞれ異なる役割を持つものです。 AI at Work 2026 (6月)は、14市場の約11,749人の従業員、マネージャー、リーダーを対象とした調査であり、逸話ではなくトレンドを語るための根拠となっています。その主張はサブタイトルに集約されています。 なぜツールよりも戦略が重要なのか。同レポートの4象限比較が示す通り、強力な戦略的明確性は、単に優れたツールを利用するだけの場合よりも、測定可能なビジネスインパクトを大幅に高めるという対比が際立っています。戦略とツールが限定的な回答者のうち、測定可能なインパクトを報告したのは55%でした。強力なツールがあっても戦略が限定的であれば60%(+5ポイント)に留まりましたが、強力な戦略があればツールが限定的でも80%(+25ポイント)に達し、両方が揃えば83%となりました。これは戦略がもたらす相関関係の強さを如実に物語っています。ただし、これは観察に基づく比較であり、厳密な因果関係を推定したものではありません(同レポート; プレスサマリー)。 エージェント型リーダーシップ・プレイブック (2026年7月初旬公開)は、これとは対照的なアプローチをとっています。これは調査レポートではなく、大企業でエージェント型プログラムを導入しているBCGの実務家、マーク・エイブラハム氏とネヴィーン・アワド氏への構造化インタビューをまとめたもので、CIOやCTOに向けて直接発信されています(同プレイブック)。その知見は統計データではなく実務家の観察に基づくものであり、本稿でも普遍的な真理としてではなく、特定の文脈における見解として扱います。両者は互いに補完し合っています。調査レポートは 「戦略」が 集団規模で差別化要因となることを立証し、プレイブックは 「誰が」 それを実行すべきか、そして 「何が」 実行の障壁となるかを詳述しています。以下の内容は、この両者の連携を軸に構成されています。
2. 分岐点:エージェント先行型企業5%の壁と、その境界線
同プレイブックで最も注目すべき数字は、その分布です。エージェント型AIの導入により、企業は「エージェント先行型」のリーダー企業(約5%)と、導入率30%未満に留まるその他の企業に二分されています。これに調査レポートの「戦略対ツール」の対比を重ね合わせると、必然的にアーキテクチャ上の問いが浮かび上がります。成果を左右するのがツールではなく計画(戦略)であるならば、その計画は物理的にどこで機能するのでしょうか。現代のAIアーキテクチャにおいて、その場所には名前があります。TrueFoundryは、同社のAIゲートウェイを、アプリケーションとLLMプロバイダー、そしてMCPサーバーの間に位置するプロキシ層と定義しています。これは1,000以上のモデルに対する統合インターフェースであり、可観測性とガバナンスを同一のホップで処理するものです(ゲートウェイのドキュメント)。これがなぜ 実行 レポート層ではなくレイヤーとしての配置:設定されたポリシーに基づき、ゲートウェイを通過するリクエストは、エンタープライズIDプロバイダーによる認証、RBAC(ロールベースアクセス制御)による認可、ガードレールによるスクリーニング、ポリシーに基づくルーティング、そして予算やレート制限のチェックを経て転送されます。戻りの経路では、価格設定、属性付与、追跡が行われます。誰がどのモデルにアクセスできるか、リクエストをどうルーティングするか、どのような安全対策を適用するか、各リクエストにいくらまで支出できるかといった技術的な意図は、事後のダッシュボードで記述されるものではなく、ライブのリクエストに対して評価される制御となります。ただし、ビジネス上の成果は、依然として組織の運用システムや財務システムで測定する必要があります。一つのアーキテクチャ上の解釈(BCGの診断ではなく、我々の見解です)として、組織は新しいユースケースごとにアクセス、セキュリティ、ルーティング、コスト制御を再構築しなければならないときに勢いを失います。ゲートウェイは、そうした繰り返しの作業の一部を共有設定へと変換できます。これこそが、調査で指摘されている「戦略対ツール」の対比が示唆するレバレッジのあり方です。
3. 60%のシフト:意思決定はCIO/CTOのオフィスへ
このプレイブックのガバナンスに関する知見は組織的なものです。現在、技術スタックやエージェント導入に関する意思決定の約60%がCIOまたはCTOの管轄下にあります。これは、ビジネス部門が同等以上の発言権を持っていた前回のAIサイクルからの大きな変化であると実務家は指摘しています。彼らは、これに伴うリスクを異例の率直さで警告しています。それは、ビジネスと技術のパートナーシップではなく、技術主導のプログラムになってしまうという危険性です。先見の明のあるCIOは、まずビジネス側のカウンターパートの目標、戦略、優先順位を確立し、そこから逆算して技術要件を導き出しています。技術リーダーにとって「ビジネスの優先順位から逆算する」ことは、システム上では「優先順位をポリシーとして表現可能にし、プラットフォームを再構築することなくポリシーを変更可能にする」ことを意味します。これが「ポリシー・アズ・コンフィギュレーション(設定としてのポリシー)」であり、ゲートウェイプレーンの文書化された特性です。ユーザー、モデル、メタデータに一致するルールを持つテナントおよびチーム単位の予算、ユーザー・チーム・モデル・アプリケーション全体にわたるレート制限、ユーザー・チーム・アプリケーションごとのRBACおよびスコープ付きキー、ルートごとに付与されるガードレールセットなど、アプリケーションや環境の次元は、ガバナンスされたメタデータを通じて表現可能です(プラットフォームの概要)。エグゼクティブの判断を左右する詳細が2点あります。予算は、警告のみのモードと強制停止モードをサポートし、マイルストーン通知も可能です(予算に関するドキュメント)— 探索段階は緩やかに、本番環境は厳格に、という運用を単一のメカニズムで実現します。また、制御が各アプリケーション内ではなくゲートウェイに存在するため、技術ポリシーの改訂をアプリケーションごとに再実装するのではなく、中央で一括して反映できます。60%の責任を負うポートフォリオの規模において、これはガバナンスを「舵取りする」ことと「再構築する」ことの決定的な違いとなります。そして、これらの決定を下す際に規制当局が同席するような組織にとって、このプレーンはVPC、オンプレミス、あるいはエアギャップ環境など、購入者の境界内で展開可能です(デプロイメントの姿勢)。
4. 変換のギャップ → コストの属性付与と「ビジネス理論」の結合
この調査の最も実践的な知見は、もはや課題は導入ではなく「変換(活用)」にあるという点です。現場の一般ユーザーによる導入率は74%に達し、前年比で約23ポイント上昇しました。一般ユーザーの42%は、毎週1営業日分以上の時間を節約できています。しかし、その時間の再投資に関するガイダンスはほとんど受けておらず、半数以上がより価値の高い業務に転換できていないと回答しています(プレスサマリー)。プレイブックは、リーダー層の経済的視点を補足しています。実務家の報告によれば、最も大胆な企業は機能別の総支出から15〜20%を削減しています。興味深いことに、彼らは優先順位を「スピード、成長、コスト」の順に設定しています。これらの知見は、信頼できる属性付与(アトリビューション)が重要な技術的インプットであることを示しています。AIの利用コスト、パフォーマンス、どの組織的次元から生成されたかを把握し、それを運用システム上のビジネスKPIや成果データと結合できなければ、節約された時間を価値へ変換する管理も、コストを15〜20%削減しつつスピードを優先させることも不可能です。ゲートウェイのテレメトリはそのインプットの一部を提供します。その属性付与メカニズムは文書化されており、取り込み時のメタデータタグ付けと出力時のコスト計算を組み合わせることで、呼び出しにガバナンスされたチーム、プロジェクト、アプリケーション、環境のメタデータを付与できます。これにより、支出とパフォーマンスのテレメトリを構造化された説明責任へと集約させることが可能です(ドキュメント; メカニズム)。プレイブックにある一つのアイデアが、属性付与にエグゼクティブとしての形を与えています。実務家は、すべての企業が独自の ビジネス理論 を持っていると説明しています。それは、追跡するKPI、それらの関連性、そして重要なマイクロセグメンテーション(彼らの小売業の例では、7つの顧客セグメントと地域ごとの需要のポケットにまで及びます)です。メタデータによってキー付けされた属性付与こそが、AIの支出をKPIツリーの横に浮かせるのではなく、その一部として組み込む方法です。ガバナンスされたメタデータスキーマは、AIの利用状況やコストデータをKPIモデルに結合するために必要な組織的次元をエンコードできます。調査で欠如していると指摘された「リダイレクト(再配分)とリタイア(廃止)」の決定は、推測ではなく、結合されたデータに対するクエリに基づいて行われるようになります。制御を伴わない可視化は、単なる会計に過ぎません(本ブログで論じてきたように);強制プレーン内での属性付与は管理そのものです。
5. データドクトリン — 第2部への架け橋
このプレイブックで最も技術的な部分はデータドクトリンであり、第2部で詳細に扱う前に、ここで慎重に1段落割いて解説する価値があります。アワド氏の定式化(本稿でプレイブックから直接引用する唯一の箇所)によれば、「エージェントに必要なのは完璧なデータではなく、誠実なデータである」とのことです。これは、完全なデータとは区別される、組織が信頼できるデータを指します。その周辺で実務家たちは、エージェントは推奨するだけでなく実行するためリスクが高まること、リーダーは信頼できるコアに基づいてエージェントを構築し、その実行を観察しながら信頼の向上とともに範囲を拡大すべきであること、そしてエージェントはコンテキストが整理されているほど著しく高いパフォーマンスを発揮することを主張しています。各条項はエージェントガバナンスの領域(ツールとデータアクセスの範囲設定、実行トレース、段階的な拡張)であり、まさに本シリーズが引き継ぐべき場所です。 第2部 では、MCPゲートウェイとエージェントハーネスを通じてそれぞれを展開します(MCPゲートウェイの認証とセキュリティ; エージェントハーネスのドキュメント)。

6. 管理革命 → スーパーバイザーが活用できる可観測性
ある調査結果は、インフラストラクチャを最も直接的に示唆しています。回答者の47%が、自身の役割がAIの管理と指揮へとシフトしたと述べており(BCGの報道ではこれを「管理革命」と呼んでいます)、一方で回答者の過半数が、許容される仕事の基準が上がったと報告しています(プレスサマリー)。プレイブックの人的側面に関する知見は、これをさらに補強します。エージェント導入の成功要因の約70%は人材とチェンジマネジメントであり、最も進んでいる企業は従業員の半数以上をトレーニング済みです。これほどの規模での監督には、人材、プロセス、説明責任の要件に加え、ツール要件も生じます。増大する監督業務には可読性が必要です。システムは何をしたのか、コストはいくらかかったのか、その正確性を裏付ける証拠は何か(トレースは実行を示し、評価とビジネス成果は品質を判断します)。そしてエージェントによる作業の場合、どのような手順とツール呼び出しのシーケンスがその出力を生成したのか。これこそがゲートウェイの可観測性サーフェスであり、技術的に言えば、OpenTelemetry準拠のメトリクス、トレース、リクエストログ、プロンプトとレスポンスの全容およびルーティング、フォールバック、ガードレールの適用状況を示すリクエストレベルの検査、エージェント実行のステップレベルトレース、そしてコストが自動的に価格設定・属性付与されたPrometheus、Grafana、Datadog、またはElasticへのエクスポートです(ドキュメント; フィールドノート)。ここで、「70%は人材」という知見はインフラへの批判ではなく、インフラに対する要件へと変わります。トレーニングは、被訓練者がシステムが何をしたかを確認できて初めて、確信を持った委任へと変換されます。可観測性は監督業務を扱いやすくし、監査可能にします。これは、第3節で説明責任を負うエグゼクティブが最終的に証明を求められることになるものです。
7. 「動く標的としてのAIガバナンス」→ ガードレールとポリシー・アズ・コンフィグ
本調査のリーダーシップ・アジェンダには、AIを「動く標的」としてガバナンスすることが含まれています。これは一度限りのプログラムではなく、常時稼働する適応型のガバナンスを意味します。その前提(モデル、エージェント、導入状況が単一の予算サイクル内で変化する)については、本プレイブックで解説されています。実行上の要件は、組織がプラットフォームを再構築することなく、継続的に変更できる形でガバナンスを表現することです。これを実現する2つの機能が文書化されています。ガードレール:PII(個人識別情報)の検出、プロンプトインジェクションのスクリーニング、コンテンツモデレーション、およびリクエストとレスポンスの経路に適用されるカスタムポリシー(ドキュメント)。そしてポリシー・アズ・コンフィグレーション(設定としてのポリシー):誰がどのモデルやツールを、どの予算で、どのガードレールセットの下で、どのようなフォールバックチェーンを用いて呼び出せるかというルールを、ゲートウェイの設定として保持します。これにより、ガバナンスの改訂は一度の設定変更で反映され、すべてのアプリケーションを再デプロイする必要がなくなります(プラットフォームの概要)。セクション3のCIOにとって、これこそが「動く標的」を乗り切るためのメカニズムです。標的が動けばポリシーもそれに追従するため、各アプリケーションが個別にポリシー実装を再デプロイする必要はありません。
8. 境界線について、平易に説明する
ここで、本シリーズの信頼性を保つための注意点を述べます。プラットフォームは戦略そのものではありません。本分析の目的において、ゲートウェイはBCGの比較における「テクノロジーとツール」側に属するものであり、「戦略対ツール」という対比は、プラットフォームが戦略や組織変革の代わりになると主張する考え方を否定するものです。プレイブックはさらに率直です。成功の70%が人材とチェンジマネジメントにかかっているならば、どれほど優れたゲートウェイであっても、従業員のトレーニングやオペレーティングモデルの再設計、あるいは先見の明のあるCIOが実践するビジネス優先の順序付けを代替することはできません。BCGの調査結果はあくまで調査結果と実務者の観察であり、約束ではありません。本稿でのマッピングはTrueFoundryによる編集上の解釈であり、検証可能なようにリンクを付記しています。これらの前提条件をすべて踏まえた上で残る主張は限定的ですが、私たちはそれが持続可能であると考えています。つまり、戦略には実行の場が必要だということです。コスト、アクセス、安全性、測定に関する技術的な意図は、ライブリクエストの経路上の制御として実装されるか、あるいは単なるスライド上の概念に留まるかのどちらかです。ゲートウェイによる制御は、宣言されたポリシーとリクエスト経路での強制実行との間の乖離を縮小します。上位5%の企業はプロキシを購入しただけでそこに到達したわけではありません。BCGは特定の製品を推奨していませんが、多くの成熟したアーキテクチャでは共有ゲートウェイや同等のコントロールプレーンが利用されています。
9. 第2部の内容
プレイブックの最も深い洞察である「エージェントは推奨するのではなく、行動する」という点は、調査のストーリーがエージェント固有のインフラストラクチャへと引き継がれる箇所です。 第2部 では、BCGのエージェントに関する調査結果を次のように展開します。エージェントが呼び出せる範囲のガバナンス(MCPゲートウェイ:レジストリ、RBAC、ユーザーごとの委任、トレーシング、リクエストの帰属)、エージェントの実行方法のガバナンス(エージェントハーネス:サンドボックス化、承認、実行トレース、測定された成果に基づく段階的な拡張)、そしてステップレベルのオブザーバビリティによるエージェント運用の監督です。これはセクション5で述べられた「確信が深まるにつれて拡大する」という規律を、運用パターンとして構築したものです。
10. よくある質問(FAQ)
BCGのプレイブックにおける「エージェントファースト」とはどういう意味ですか? BCGは、2026年時点でエージェントの試験運用から脱却し、エージェントを中心にビジネスのあり方を再考し始めた約5%の企業グループを指してこの言葉を使っています。これに対し、大多数の企業はまだ導入率30%未満に留まっています。プレイブックでは、この差の主な要因はモデルの選択ではなく、リーダーシップ、順序付け、チェンジマネジメントにあるとしています。
CIO/CTOの意思決定シェアが60%であるという調査結果は、技術的に何かを変えるのでしょうか? 説明責任が集中すれば、強制力も集中させる必要があります。デプロイの決定権を持つリーダーには、再プラットフォーム化なしに変更可能な「設定としてのポリシー」、警告のみまたは強制モードを備えた経路内での支出管理、そしてステップごとのトレースとリクエスト記録が必要です。これらはセクション3および6で文書化されている特定の機能です。
TrueFoundryは、BCGがゲートウェイを推奨していると主張しているのですか? いいえ。BCGの出版物はTrueFoundryや特定のゲートウェイ製品を評価・推奨するものではありません。ここでの調査結果と機能のマッピングはTrueFoundryによる編集上の統合であり、すべてのBCGの数値にはソースへのリンクを、すべての機能にはドキュメントへの参照を付記しています。
シリーズ: 第1部(全2部) · 次へ → 第2部:エージェント導入からガバナンスの効いたツールとランタイムへ
参考文献
- BCG — AI at Work 2026:ツールよりも戦略が重要な理由 (2026年6月、14市場の労働者約11,749人を対象): bcg.com; プレスサマリー、2026年6月3日(導入、転換、経営革命に関する数値): bcg.com; エ ージェント型リーダーシップのプレイブック:CTOおよびCIOのためのスケーリング戦略、2026年7月上旬(実務家Mark Abraham氏およびNeveen Awad氏による、5%、30%未満、60%、70%の数値、トレーニング、15〜20%の調査結果、データドクトリン): bcg.com。
- TrueFoundryドキュメント — AIゲートウェイ、 予算制限(警告のみ、強制制限、マイルストーンアラート)、 MCPゲートウェイの認証とセキュリティ、 Agent Harness、 プラットフォームの概要とデプロイメントの構成。
- 当ブログの関連トピック: AIゲートウェイのコスト構造、 コストの帰属、 ゲートウェイ導入に関する現場の知見、 ジャストインタイムのコンテキスト、 ガバナンスされた検索、 ガバナンスされた利用アーキテクチャ、および 本シリーズの第2部。
BCGの数値はすべて、リンク先の出版物およびプレス資料を要約したものです。本プレイブックの調査結果は、構造化インタビューに基づく実務者の見解として提示されており、15語未満の引用箇所1点のみがNeveen Awad氏によるものです。調査結果と機能の対応付けはTrueFoundryによる編集上の統合であり、BCGは引用資料においてTrueFoundryやその他のベンダーを評価・推奨するものではなく、TrueFoundryはBoston Consulting Groupとは提携していません。TrueFoundryの機能は執筆時点の公開ドキュメントを要約したものです。最新情報は実際のドキュメントをご確認ください。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.

















.png)
.png)
.png)
.png)
.png)






.png)





