『届け方』が勝負を決める時代の地図 「安いCDN」
という誤読

元postの正しい部分から開ける。日本の大企業（ここでは エンプラ＝企業向けの大きな取引、と呼ぶ）の調達では、意思決定の軸が「安いか」「速いか」ではない。動いているのは 「事故ったとき、誰がケツを持つのか」 という、まったく別軸のロジックだ。

大企業のIT部門（俗に 情シス＝情報システム部）の立場で考えてみればいい。たとえば、聞いたことのない新しい会社の製品を導入した直後に、システム障害や情報漏洩が起きたとしよう。社内・役員・場合によっては金融庁や個人情報保護委員会まで、「なぜこれを選んだのか」を説明する必要が出てくる。説明責任の矢面に立たされるのは、選んだ本人だ。

そのとき「性能比較表で勝っていました」は、ほぼ何の盾にもならない。盾になるのは「業界標準だから」「世界中の大企業が使っているから」「日本法人があり、24時間日本語サポートがあるから」——要するに、自分の判断責任を組織の外側に逃がせる根拠のほうだ。

「大手だから安心」というのは、感情論ではない。契約書に書ける形で、事故対応の責任を引き受けてもらうという、極めて論理的な判断だ。だから日本の大企業は、性能を見るより先に SLA（壊れても何時間以内に直します、という約束）や、サポート窓口の場所、第三者認証（ISMS／SOC2／PCI-DSSなど＝第三者機関が「ちゃんとセキュリティ管理されてます」と認定した紙）、契約上の責任範囲、国内法に基づく契約か——といった「事故ったときの想定」を先に詰める。

つまり大企業の購買は、製品を買う行為と 同時に「事故時の説明責任を肩代わりしてもらう契約」を買う行為 でもある。後者の価値を理解せずに「機能で勝っているのに売れない」と嘆くと、永遠に的を外す。お店の喩えに戻すなら、ここで売っているのは「料理の味」ではなく 「お腹を壊しても、ちゃんと謝ってくれる店主」 のほうだ。

もう一つ、元postの「楽だからかな」には別の読みがある。「Cloudflareは安いCDN」という前提そのものが、現在の Cloudflare のプロダクトとはもうズレている、というズレだ。看板が古いまま読まれている、と言ってもいい。

CDN（Content Delivery Network）というのは、本来は 「Webサイトを世界中の拠点にコピーして、近くから速く配る仕組み」 のこと。Cloudflareは確かにこの分野で世界1位のシェアを長く取り続けている（W3Techs の集計でも長期にわたって首位）。Fortune 1000（米国の売上トップ1000社）の相当割合が顧客、という規模感の会社でもある。

けれど、本人たちはとっくに 「Webセキュリティとゼロトラスト（社内ネットを前提にしない新しい安全な働き方）の会社」 として勝負している。具体的には：

• WAF（Web Application Firewall＝Webアプリへの攻撃を遮断する盾）でForresterのリーダーポジション
• SASE／SSE（社外からの安全なアクセスを束ねる仕組み）でGartnerの上位
• ZTNA（Zero Trust Network Access＝VPNの代わりに、必要な権限だけ都度与える方式）でIDCの上位

つまり、製品そのものは大企業向けに十分通用するレベルにある。なのに日本市場では、まだ 「Cloudflare＝安いCDN」 という10年前の看板のままで読まれている節がある。これが Gate 1——認知の関門 でつまずいている状態だ。

これが何を引き起こすかというと、予算の引き出しが変わってしまう。「CDN」として稟議に上がれば、月数万円〜数十万円の引き出しから引かれる。「SASE／ZTNA」として稟議に上がれば、月数百万円〜の引き出しから引かれる。同じ製品でも、何の看板で読まれるかで桁が変わる。Cloudflareは、桁の大きい引き出しに手を伸ばせない位置に置かれてしまっている。

「楽」の話に戻ろう。エンジニアが「Cloudflareは楽じゃないの？」と言うとき、それは 技術的にシンプルだ という意味で言っている。けれど、大企業の購買担当が言う「楽」は、いつもの稟議のテンプレに流し込める、いつもの調達ルートに乗っている、社内に説明しやすい、を全部含んだ「楽」だ。両者は別軸の話なのに、同じ「楽」という単語で語ってしまうと混乱する。技術の話なのか、売り方の話なのか——それを分けないと、議論が噛み合わない。

ここで AIエージェント（人間が指示しなくても自律的にタスクをこなすAI）の話に切り替える。3関門の地図はこのまま使える。むしろ、いま起きているAIエージェント導入競争を眺めると、Cloudflareで起きたことが完全に再演されつつあるのが見える。

2026年4月のAWSの開発者向けイベントで、Amazonは AgentCore を「オープンなオーケストレーション層」として再定位した（同社製モデル以外の外部モデルも扱える方針）。同時に Managed Agents という、AWSが運用までまるごと面倒を見るマネージドのエージェントを投入している。「賢いAIを売る」より先に「動かせる場所を売る」に商売の重心がはっきり寄っている。

米国の調査会社 Futurum Research が同年5月に出した分析は、もっとはっきり書いている——AIエージェント市場の支配点（control point）は、製品ではなく 調達（procurement）／ID（identity）／可観測性（observability） の3つだ、と。要するに「どう売るか・誰の名前で動かすか・あとから何をしたか追えるか」。これは本稿で言ってきた チャネル・責任 の言い換えにほぼなっている。

Microsoftも同じ路線で、2026年の Copilot Studio のテーマは "pilot → production"（試して終わるのではなく、本番運用に持っていく）。同社の「2026年にエージェント採用をスケールさせる6つの能力」というブログ記事で強調されているのも、製品仕様ではなく Agent 365 によるガバナンス（暴走させない仕組み）、管理者によるアクセス制御、社員IDとの紐付け ——つまり全部、責任とチャネルの話だ。AgentCoreの公式ページも production-grade security from day one（初日から本番品質のセキュリティ）を最初の売り文句に据えている。

つまり もっとも賢いモデルを持つベンダーが、そのまま日本の大企業で勝つわけではない。3関門を先に越えた者が、賢さの取り分まで持っていく——という、CDNで起きたことの再演になる。エージェント自体の技術的な中身は エージェントハーネスの内部 や AIエージェントは誰が動かしているのか でも書いたが、市場に届くかどうかは別階層の話で、そこを動かしているのは3関門のほうだ。

ここまでは「送り手側がどう動いているか」の話だった。次は 受け手側——導入したい日本企業の側がなぜ詰まるのか、を開ける。3関門を高く設計しているのは、買い手側の構造でもある。

3関門を地図として持つと、エンジニア個人の立ち位置の話までそのままつながる。価値は「作る（コーディング）」から「翻訳・設計・責任を引き受ける」レイヤーへ移る——というのが、ここでの主張だ。

米国の労働市場データを眺めると、AI到来「前」からの趨勢として、伸びている職種と伸びていない職種がはっきり分かれている。需要が大きく伸びているのは アーキテクト、データストラテジスト、セキュリティマネージャー ——どれも「翻訳・設計・責任」の仕事だ。一方で ソフトウェアエンジニア系（特にフロントエンド）は総じて低調、というデータもある。「作る」だけの仕事は、AI到来を待たずに既に希薄化が進んでいた。AIエージェントの登場はこの傾向をさらに加速させる、というのが妥当な読みだろう。

これを3関門の地図に重ねると見えてくるのは、「作る」は3関門の手前の話で、3関門の中身を埋める仕事は「翻訳・設計・責任」のほう、ということだ。買い手の言語を組み立てる（認知）、契約と運用責任を引き受ける（責任）、いつもの調達フローに乗せる（チャネル）——これらは全部、コードを書くこととは別軸の仕事である。AIに置き換わりにくいのも、この別軸の側。

(a) はニッチ戦略、(b) はSIer的な立ち位置の再発明だ。どちらも「いいツールを作れば売れる」とは正反対の発想で、要は 技術そのものではなく、技術と買い手のあいだに横たわる "不安" を解消する仕事を売る ことになる。AI時代に個人が選べる勝ち筋は、ほぼこのどちらかに収束していくと思う。

余談だが、これは日本の業界構造的にも追い風になりうる。日本は買い手側に翻訳人材が薄いぶん、「翻訳・設計・責任」を引き受けられる個人 への需要が構造的に大きい。多重下請けピラミッドという話はネガティブな文脈で語られがちだが、視点を変えると、3関門を越える層の市場が分厚く存在している、ということでもある。問題は、ここに飛び込む個人が、エンジニア出身者の側からどれだけ出てくるか、という供給側の話だろう。

Cloudflareから始めた話は、結局ここに着く。技術の優劣ではなく、3関門の越え方が勝負を決める。それは送り手の戦略の話であると同時に、買い手の構造の話でもあり、そしてエンジニア個人がどこに立つかの話でもある——同じ補助線が、3つの階層を貫いて使える。