Web制作会社がホスティング選定で重視すべきSLAと保証のチェックポイント
Webサイトの公開直後にサーバーがダウンしたり、サポートの返信が来なかったりするトラブルは、多くの制作現場で頭を悩ませる問題だ。こうした事態を防ぐための指標となるのが、SLA（Service Level Agreement / サービス品質保証）である。
SLAとは、サービス提供者が利用者に対して「どの程度の品質を保証するか」を明文化した合意書を指す。多くのホスティング会社が「高い信頼性」を謳うが、具体的な数字や補償内容が伴わなければ、それは単なるスローガンに過ぎない。
特に複数のクライアントサイトを管理するエージェンシーにとって、インフラの安定性は自社の信頼に直結する。この記事では、ホスティングパートナーを選ぶ際に確認すべきSLAの核心と、見落としがちな保証の裏側について詳しく掘り下げていく。
SLAの正体とWeb制作会社が注視すべき理由
SLAは、ホスティングプロバイダーが提供するサービスの品質を定義し、その目標が達成されなかった場合の救済措置を定めた正式な文書だ。これには稼働率の目標値、サポートの応答時間、セキュリティ対応などが含まれる。
SLAは「単なる努力目標」ではない
マーケティング資料で見かける「高速なパフォーマンス」や「専門家によるサポート」といった言葉には、客観的な基準がない。一方でSLAは、これらを測定可能な数値で定義する。例えば「月間稼働率99.9%を維持し、下回った場合は利用料金の一定割合を返金する」といった具体的な約束事だ。
KinstaのCarlo Daniele氏によれば、SLAはプロバイダーが自社のサービスにどれだけの責任を持っているかを示す指標となる。障害が起きた際のフレームワークが事前に決まっていることで、利用者側はリスク管理がしやすくなるという利点がある。
クライアントへの信頼性に直結するインフラの裏付け
Web制作会社にとって、ホスティングのトラブルは自社のトラブルとしてクライアントに認識されることが多い。サーバーが原因のダウンタイムであっても、クライアントが最初に連絡を入れるのは制作担当者だからだ。
明確なSLAを持つパートナーを選んでおけば、万が一の際にも「どのような保証があるか」「いつまでに復旧が期待できるか」をクライアントへ論理的に説明できる。これは、制作会社のプロフェッショナリズムを守るための防波堤となるのだ。
稼働率99.9%の落とし穴と数字の読み解き方
ホスティングの比較で最も頻繁に目にするのが「稼働率（Uptime）」のパーセンテージだ。一見すると99.9%も99.99%も大差ないように思えるが、年間の停止時間に換算するとその差は歴然としている。
わずか0.01%の差が年間ダウンタイムに与える影響
稼働率の数字が意味する「許容される停止時間」を整理してみよう。以下のデモ表は、各稼働率における年間の最大停止時間を示している。
この表からわかる通り、99.9%の保証では年間で1営業日近い停止が発生する可能性がある。ECサイトや広告キャンペーン中のランディングページにとって、数時間の停止は大きな機会損失につながるため、この差は無視できない。
ネットワーク層かアプリケーション層か：測定範囲の重要性
稼働率をどこで測定しているかも重要なチェックポイントだ。一部のプロバイダーは「ネットワークの稼働」のみを保証し、サーバー上のアプリケーション（WordPressなど）が正常に動作しているかどうかを保証対象外としている場合がある。
実務においては、ネットワークが生きていてもデータベース接続エラーでサイトが表示されなければ「ダウン」と同じだ。アプリケーションレベルでの稼働を監視し、保証に含めているプロバイダーの方が、Web制作の実務に即しているといえるだろう。
サポートとパフォーマンスの保証をどう評価するか
サーバーが動いていることと同じくらい重要なのが、問題が発生したときの「人の対応」と、平常時の「表示速度」だ。これらもSLAの対象となることがある。
応答時間と解決時間は別物である
サポートのSLAでよく見られるのが「初回応答時間（First Response Time）」だ。これはチケットを発行してから最初の返信が来るまでの時間を指す。しかし、ここには落とし穴がある。最初の返信が自動送信メールや「確認します」というだけの定型文であっても、応答時間はカウントされてしまうからだ。
本当に評価すべきは、問題を解決するまでのプロセスや、技術レベルの高いエンジニアに直接つながる仕組みがあるかどうかだ。24時間365日の対応はもちろん、緊急時のエスカレーションパス（上位エンジニアへの引き継ぎルート）が明確に定義されているかを確認したい。
インフラ構成がパフォーマンス保証の根拠となる
パフォーマンスに関する保証は、単なる数値目標よりも「それを実現するためのインフラ」に注目すべきだ。例えば、以下のような要素がSLAの信頼性を支える技術的根拠となる。
- 隔離されたコンテナ環境：他のサイトの負荷影響を受けない仕組み
- 自動スケーリング：急激なトラフィック増に対応できるリソース配分
- グローバルなCDN統合：物理的な距離による遅延を最小化する配信網
これらの技術が組み込まれているプロバイダーは、結果として安定したレスポンスタイムを提供できる可能性が高い。パフォーマンスの低下は直帰率の増加やSEO順位の下落を招くため、インフラの堅牢性はビジネス上の成果に直結する。
セキュリティとバックアップに関する合意事項
セキュリティ事故が起きた際、誰がどこまで責任を負うのかを明確にすることもSLAの役割だ。特にWordPressのようなCMSを利用する場合、プラットフォーム側の保護範囲を知っておく必要がある。
マルウェア除去とDDoS対策の責任範囲
多くのプロバイダーがセキュリティ対策を謳っているが、実際にサイトが改ざんされた際の「無償での復旧」までを保証しているケースは限られる。SLAの中にマルウェアの検出だけでなく、除去作業が含まれているかどうかは大きな分かれ目だ。
また、DDoS攻撃（大量のアクセスでサーバーを麻痺させる攻撃）に対するネットワークレベルの防御が標準で含まれているかも確認したい。攻撃を受けてから対策を追加するのではなく、インフラ側で常にトラフィックを監視・遮断する体制が保証されているのが理想的だ。
RTO（目標復旧時間）とRPO（目標復旧時点）の確認
バックアップは「取っていること」よりも「戻せること」が重要だ。ここで重要になるのがRTO（Recovery Time Objective / 目標復旧時間）とRPO（Recovery Point Objective / 目標復旧時点）という概念である。
- RTO：障害発生からどれだけの時間で復旧させるか（例：2時間以内）
- RPO：どの時点のデータまで戻せるか（例：1時間前のバックアップまで）
これらが明文化されているホスティングサービスは、万が一のデータ消失時にも事業継続性を担保しやすい。制作会社としては、クライアントの要件に合わせてこれらの指標をチェックする必要がある。
契約前に確認すべき「隠れた制限事項」と除外規定
SLAには必ずといっていいほど「除外規定（Exclusions）」が存在する。ここを読み飛ばすと、いざという時に保証が受けられない事態になりかねない。
最も一般的な除外項目は「計画メンテナンス」だ。サーバーのアップデートなどのために事前に通知された停止時間は、稼働率の計算から除外されるのが通例だ。ただし、その頻度や時間帯（深夜帯かどうかなど）が適切かどうかは確認しておくべきだろう。
また、アプリケーション層の不具合も除外されることが多い。例えば、特定のプラグインが原因でサイトが真っ白になった場合、それはサーバーの責任ではなく利用者の責任とみなされる。SLAがカバーするのはあくまで「ホスティング側がコントロールできる範囲」であることを理解しておく必要がある。
さらに、補償の申請方法も重要だ。稼働率を下回った場合に自動で返金（クレジット付与）されるのか、あるいは利用者側がログを添えて申請しなければならないのか。WP Mayorなどの専門メディアでも指摘されている通り、申請の手間が壁となり、実質的に補償を受けられないケースも少なくない。
独自の分析：マネージドホスティングがSLAを強化する理由
筆者の見解として、SLAの信頼性を最も高めるのは「マネージド（管理代行型）」の運用体制だ。単にサーバーを貸し出すだけのサービスとは異なり、マネージドホスティングはプラットフォーム全体を最適化し、プロアクティブ（先回り的）な監視を行う。
問題が起きてからSLAに基づいて補償を求めるよりも、問題が起きないように常にリソースを調整し、脆弱性をパッチで塞ぐ運用のほうが、結果としてWeb制作会社のコスト（対応工数）を抑えられる。SLAの数字そのものだけでなく、その数字を維持するための「運用の質」に投資するという視点が重要だ。
エージェンシーにとっては、自社のエンジニアがサーバーの保守に時間を取られるのを防ぎ、本来の業務であるクリエイティブやマーケティングに集中できる環境を作ることこそが、真のSLAの価値といえるのではないだろうか。
この記事のポイント
- SLAは単なる宣伝文句ではなく、品質未達時の救済措置を含む法的合意である
- 稼働率99.9%と99.99%の間には、年間で約8時間の停止時間の差が存在する
- サポートの評価は「返信の速さ」だけでなく「解決までの技術力」を重視すべき
- セキュリティやバックアップの保証範囲を確認し、責任の所在を明確にする
- 計画メンテナンスやユーザー起因のトラブルなど、SLAの除外規定を必ずチェックする
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare Client-Side Securityが全ユーザーに開放。GNNとLLMを融合した最新の検知技術を解説
Cloudflareは、ウェブサイトの閲覧者側で実行される悪意のあるスクリプトを検知・遮断する「Client-Side Security」の大幅なアップデートを発表した。これまでエンタープライズ向けに提供されていた高度なセキュリティ機能が、セルフサービスを利用するすべてのユーザーに開放される。1日あたり35億ものスクリプトを評価する同社のネットワークが、より広範なウェブサイトを保護する体制を整えた。
今回の更新で最も注目すべきは、AIを用いた新しい検知システムの導入だ。グラフニューラルネットワーク（GNN）と大規模言語モデル（LLM）を組み合わせることで、誤検知を劇的に減らしつつ、未知の攻撃を高い精度で特定できるようになった。従来のシグネチャベースの防御では防ぎきれない、高度に難読化された攻撃への対策が強化されている。
クライアントサイドを標的とした攻撃は、サイトの表示を崩すことなくデータを盗み出すため、運営者が気づきにくいという特徴がある。Cloudflareはこの課題に対し、最新のAI技術を統合することで、運用の手間を最小限に抑えながら強固な防御を提供することを目指している。本記事では、その技術的な仕組みと実戦での成果について詳しく解説する。
Cloudflare Client-Side Securityの進化と新展開
Cloudflareは、強力なセキュリティ機能を営業担当者との交渉なしに利用可能にすることを基本原則として掲げている。その一環として、これまで「Page Shieldアドオン」と呼ばれていた機能を「Client-Side Security Advanced」へと統合し、セルフサービスプランのユーザーでも即座に導入できるようにした。
全ユーザーへの門戸開放と無料化の意義
今回のアップデートにより、ドメインベースの脅威インテリジェンスがすべての顧客に無料で提供される。2025年には、Magentoなどのプラットフォームを利用する中小規模のECサイトが、クライアントサイドからの攻撃により数週間にわたって被害を受け続ける事例が多数報告された。こうしたリソースの限られたサイト運営者でも、ダッシュボード上のトグルを切り替えるだけで、既知の悪意のあるドメインとの通信を可視化できるようになった。
PCI DSS v4への対応とコンプライアンス
Client-Side Security Advancedには、コードの変更を継続的に監視する機能が含まれている。これは、クレジットカード業界のセキュリティ基準である「PCI DSS v4」の要件11.6.1を満たすために不可欠な要素だ。EC事業者はこのツールを導入することで、法規制や業界基準への準拠を容易に進めることができる。また、コンテンツセキュリティポリシー（CSP）に基づいたプロアクティブなブロックルールの運用も可能となっている。
攻撃をあぶり出す仕組み：ASTとブラウザレポーティング
クライアントサイドのセキュリティ管理は、膨大なデータを扱う極めて困難な課題だ。一般的なエンタープライズサイトでは、平均して2,200もの固有のスクリプトが動作している。さらに、これらのスクリプトの約3分の1は30日以内に更新される。これらを手動で承認していては、開発パイプラインが停止してしまうため、自動化された高度な分析が必要となる。
レイテンシゼロで監視するアーキテクチャ
Cloudflareのシステムは、ブラウザレポーティング（Content Security Policyなど）を利用して信号を収集する。これにより、サイトにスキャナーを導入したり、アプリケーションに特別なコードを埋め込んだりする必要がない。ユーザーのブラウザからの報告をCloudflareのプロキシ経由で受け取る仕組みのため、ウェブアプリケーションの表示速度に一切の影響を与えないのが大きな強みだ。
難読化を突破するAST解析の威力
攻撃者は検知を逃れるために、コードの変数を意味のない文字列に書き換えたり、構造を複雑にしたりする「難読化」を行う。Cloudflareはこれに対抗するため、スクリプトを「AST（Abstract Syntax Tree / 抽象構文木）」に分解して解析する。ASTとは、プログラムの構造を樹状図のような形式で表現したものだ。コードの見かけ上の書き方が変わっても、論理的な構造や挙動（インテント）を抽出できるため、悪意のある意図を正確に特定できる。
以下のデモは、難読化されたコードがどのようにAST的な構造として捉えられるかを視覚化したイメージだ。
var _0x1a2b = ["\x63\x6F\x6F\x6B\x69\x65"];
function _0x3c4d(){
send(_0x1a2b[0]);
} このデモは難読化されたコードが解析され、データの持ち出しという構造が特定される過程を視覚化したイメージである。
GNNとLLMを組み合わせた「二段構え」の検知システム
Cloudflareが導入した最新の検知システムは、2つの異なるAIモデルを連携させる「カスケード型」のアーキテクチャを採用している。これにより、広大なインターネット上に存在する無限に近いバリエーションのスクリプトを、効率的かつ正確に処理することが可能になった。
構造を捉えるGNNの役割と限界
第1段階として、すべてのスクリプトはグラフニューラルネットワーク（GNN）によって評価される。GNNはASTの構造を学習し、変数の名前が変更されていても、実行パターンの特徴から悪意のある挙動を検知する。GNNは処理が高速であり、未知の脅威（ゼロデイ攻撃）を見逃さない「高い再現率」を持っている。しかし、その一方で、複雑な広告用スクリプトや難読化された正当なライブラリを誤って「攻撃」と判定してしまう「偽陽性」が課題となっていた。
Workers AIによるLLMの「セカンドオピニオン」
GNNが「疑わしい」と判定したスクリプトのみ、第2段階として大規模言語モデル（LLM）に送られる。ここで使用されるのは、Cloudflareの「Workers AI」上で動作するオープンソースのLLMだ。LLMはコードの意味的な文脈を深く理解しており、開発者がよく使う記述パターンやフレームワーク特有の動作を識別できる。LLMが「これは怪しいが見た目は無害なコードだ」と判断すれば、GNNの判定を上書きして誤検知を防ぐ。この二段構えにより、独自の評価では偽陽性を約3分の1にまで削減することに成功した。
実戦での成果：ルーターを標的にした「core.js」の検知事例
この新しい検知システムは、すでに実際の攻撃を特定する成果を上げている。最近検知された「core.js」という悪意のあるスクリプトの事例は、AIによる構造・意味解析の有効性を証明するものとなった。
高度な難読化とゼロデイ攻撃の正体
「core.js」は、特定の地域でXiaomi製のOpenWrtベースのホームルーターを乗っ取ることを目的としたスクリプトだった。このスクリプトは、ルーターのWAN設定（DHCP、スタティックIP、PPPoEなど）を動的に照会し、DNS設定を書き換えてトラフィックをハイジャックしようとする。さらに、管理パスワードを密かに変更して、正当な所有者を締め出す機能まで備えていた。この攻撃はウェブサイトを直接改ざんするのではなく、侵害されたブラウザ拡張機能を通じてユーザーのセッションに注入されていた。
偽陽性を劇的に減らす精度の向上
このスクリプトは高度に圧縮・難読化されており、従来のシグネチャベースの防御システムでは検知が困難だった。しかし、CloudflareのGNNは難読化の奥にある悪意のある構造を暴き出し、Workers AI上のLLMがその意図を「ルーターのAPIを悪用する攻撃である」と確信を持って判定した。全体的なトラフィックにおける偽陽性率は約0.3%から0.1%へと低下し、固有のスクリプト単位では、偽陽性率が1.39%から0.007%へと約200倍も改善されたという。これにより、運用担当者はアラート疲れに陥ることなく、真の脅威に集中できるようになった。
独自の分析：クライアントサイドセキュリティが不可欠になる理由
今日のウェブ制作において、サードパーティ製スクリプトの利用は避けて通れない。広告、アクセス解析、チャットボット、SNS連携など、1つのサイトで数十の外部サービスが読み込まれることは珍しくない。しかし、これは「サプライチェーン攻撃」のリスクを常に抱えていることを意味する。自社のサーバーをどれだけ堅牢に守っても、読み込んでいる外部のJavaScriptが侵害されれば、ユーザーの個人情報や決済データは簡単に盗まれてしまう。
Cloudflareの今回の取り組みが画期的なのは、AIを「検知の高速化」だけでなく「運用の現実化」に活用した点だ。これまでのクライアントサイドセキュリティは、厳格に設定すれば誤検知が増えてビジネスを阻害し、緩く設定すれば攻撃を見逃すというジレンマがあった。GNNで広く網を張り、LLMで賢く精査するというアプローチは、膨大かつ変化の激しい現代のウェブエコシステムにおける現実的な解といえる。
特に、Workers AIを活用して自社ネットワーク内でLLMを完結させている点は、プライバシーとレイテンシの両面で合理的だ。セキュリティ製品が「導入するとサイトが重くなる」というこれまでの常識を覆し、パフォーマンスを維持したまま高度なAI防御を適用できるようになった意義は大きい。今後は、さらにLLMの判定基準を最適化することで、よりアグレッシブな検知設定が可能になり、未知の攻撃に対する防御力はさらに高まっていくと指摘されている。
この記事のポイント
- Cloudflare Client-Side Security Advancedがセルフサービスプランの全ユーザーに開放された
- ドメインベースの脅威インテリジェンスが無料化され、中小規模のサイトでも導入が容易になった
- GNNによる構造解析とLLMによる意味解析を組み合わせた二段構えの検知システムを導入した
- Workers AIを活用することで、サイトの表示速度に影響を与えずに高度なスクリプト解析を実現した
- ルーターを標的とした「core.js」のような、従来のシステムでは見逃されやすいゼロデイ攻撃の検知に成功した
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare Gen13サーバーの設計思想 192コアAMD EPYCで2倍のスループットを実現
Cloudflareが第13世代サーバー「Gen13」の設計詳細を公開した。192コアのAMD EPYC Turin 9965プロセッサを搭載し、前世代比で最大2倍のスループットを実現している。
Gen13は768GBのDDR5-6400メモリ、24TBのPCIe 5.0 NVMeストレージ、デュアル100GbEネットワークインターフェースを備える。特に注目すべきは、Rustで書き直された新リクエスト処理層「FL2」への移行により、大容量L3キャッシュへの依存を解消した点だ。これによりコア数を2倍に増やしながら、レイテンシの増加を抑えることに成功した。
この記事では、Cloudflare Blogの記事を基に、Gen13サーバーの各コンポーネント選択の背景と設計思想を解説する。
CPU設計の転換：キャッシュからコアへ
Gen13の最大の特徴は、AMD EPYC Turin 9965プロセッサの採用だ。192コア/384スレッドを備え、前世代のGen12（96コア）からコア数を2倍に増やしている。
L3キャッシュ依存からの脱却
興味深いのは、コア数が2倍になった一方で、コアあたりのL3キャッシュ容量が83.3%減少している点だ。Gen12のAMD EPYC Genoa-X 9684Xはコアあたり12MBのL3キャッシュを持っていたが、Gen13のTurin 9965はコアあたり2MBしかない。
この一見逆行するような選択の背景には、Cloudflareのソフトウェアスタックの根本的な変化がある。Cloudflareはリクエスト処理層をFL1からFL2へ移行した。FL2はRustで書き直された新アーキテクチャで、大容量L3キャッシュへの依存度が大幅に低減されている。
Cloudflare Blogの記事によると、FL2ワークロードはコア数に対してほぼ線形にスケールする特性を持つ。このため、コア数を増やすことが直接的なスループット向上につながる。L3キャッシュ容量の減少による潜在的なパフォーマンス低下は、FL2の効率的なメモリ使用によって相殺された。
3つの候補から9965を選んだ理由
Cloudflareのエンジニアチームは、Gen13のCPU候補として3つのAMD Turinプロセッサを評価した。128コアの9755、160コアの9845、そして192コアの9965だ。
評価の結果、9965が選ばれた理由は明確だ。生産環境でのテストにおいて、9965の192コアは最高の総合リクエスト処理性能を示した。さらに、500WのTDP（熱設計電力）における性能/ワット効率も優れており、ラックレベルでの総所有コスト（TCO）が最も低くなると判断された。
運用面でも、192コアという高密度構成はメリットがある。同じ計算能力を提供するために必要なサーバー台数が減るため、プロビジョニング、パッチ適用、監視にかかる運用オーバーヘッドを削減できる。
メモリとストレージの拡張
12チャネルDDR5-6400で帯域幅33%向上
CPUコア数が2倍になったことで、メモリサブシステムにもより高い要求が課せられた。Gen13は12個のDDR5-6400メモリチャネルすべてを活用する構成を採用している。
各チャネルに64GB DIMMを1枚ずつ配置する「1DIMM per channel」構成で、合計768GBのメモリ容量を実現。ピークメモリ帯域幅はソケットあたり614GB/sに達し、Gen12から33.3%向上した。
すべてのチャネルを均等に使用する構成は、メモリインターリーブの観点から重要だ。AMD Turinプロセッサは、同じDIMMタイプ、同じ容量、同じランク構成のメモリチャネル間でインターリーブを行う。インターリーブにより、連続したメモリアクセスが単一のチャネルではなくすべてのチャネルに分散され、実効的なメモリ帯域幅が向上する。
コアあたり4GBの「適正容量」を維持
メモリ容量の決定において、Cloudflareは「コアあたり4GB」という比率を維持することを選択した。Gen12でも同じ比率が採用されており、実績のあるバランスだ。
設計初期には、コアあたり4GBから6GBの範囲が検討された。192コアの場合、768GBから1152GBに相当する。実際のDIMM容量の粒度を考慮すると、選択肢は12x48GB（576GB）、12x64GB（768GB）、12x96GB（1152GB）の3つだった。
12x48GB構成は容量が不足し、メモリを多く消費するワークロードを飢餓状態にするリスクがある。一方、12x96GB構成はコアあたり50%の容量増加となるが、電力消費の増加とコストの大幅な上昇（現在のメモリ価格は1年前の10倍）が問題だ。
12x64GBの768GB構成は、コアあたり4GBという実績のある比率を維持しつつ、サーバーあたりの総容量をGen12の2倍に拡大する。FL2はFL1と比べてメモリ使用効率が大幅に向上しており、ソフトウェアスタックの移行によって生じた余剰容量が、今後数年間のCloudflareの成長を支えるヘッドルームとなる。
ストレージ：PCIe 5.0と容量50%増
ストレージサブシステムも大幅に強化された。Gen13はPCIe Gen 5.0 NVMeドライブを採用し、レイテンシの改善と増大するストレージ帯域幅要求に対応する。
物理的なストレージ容量も、3台のNVMeドライブにより24TBに拡張された。Gen12サーバーは4つのE1.Sストレージスロットを備えていたが、実際に使用されていたのは2スロットのみだった。Gen13では同じ4スロット設計を維持しつつ、3スロットに8TBドライブを実装している。
3台目のドライブ追加により、サーバーあたりのストレージ容量は16TBから24TBへ50%増加した。これはCDNキャッシュ性能の維持・向上に加え、Durable Objects、Containers、Quicksilverサービスなどの成長予測を支えるためだ。
さらにGen13シャーシには、最大10台のU.2 PCIe Gen 5.0 NVMeドライブを収容できるフロントドライブベイが追加された。この設計により、同じシャーシをコンピュートプラットフォームとストレージプラットフォームの両方で使用できる柔軟性が生まれる。必要に応じてコンピュートSKUをストレージSKUに変換することも可能だ。
ネットワークと電源の刷新
8年ぶりのネットワークアップグレード：25GbEから100GbEへ
Gen13で最も大きな変化の一つが、ネットワークインターフェースの刷新だ。8年以上にわたりCloudflareフリートの基盤となってきたデュアル25GbEから、デュアル100GbEへと移行する。
この変更の必要性は明白だ。192コアという高性能CPUがより多くのリクエストを処理できるようになると、ネットワーク帯域幅がボトルネックになる。実際、世界中のコロケーション施設から収集した1週間分の本番データによると、Gen12ではポートあたりのP95帯域幅が利用可能帯域幅の50%を一貫して超えていた。
Gen13ではサーバーあたりのスループットが2倍になるため、NIC帯域幅が飽和するリスクが高まる。100GbEへの移行は、このボトルネックを解消するための必然的な選択だ。
50GbEではなく100GbEを選んだ理由は、産業界の経済性にある。50GbEトランシーバーの市場規模は依然として小さく、サプライチェーン上のリスクが高い。デュアル100GbEポートによりサーバーあたり200Gb/sの集約帯域幅を実現し、今後数年間のトラフィック成長に対応できる将来性も確保した。
電源：800Wから1300Wへ拡張
コンピュート能力とネットワーク能力の向上に伴い、サーバーの電力エンベロープも自然に拡大した。Gen13は必要な電力を供給するため、より大型の電源装置を搭載する。
Gen12ノードは800W 80 PLUS Titanium CRPS（共通冗長電源装置）で十分に動作していたが、Gen13では1300W 80 PLUS Titanium CRPSを選択した。
Gen13の通常動作時の電力消費は850Wに達する。Gen12の600Wから250Wの増加だ。主な要因は、TDPが400Wから500Wに上がったCPU、メモリ容量の2倍化、追加のNVMeドライブである。
1000Wではなく1300Wを選んだ理由は、現在のPSUエコシステムに1000Wの高効率オプションがほとんどないためだ。サプライチェーンの信頼性を確保するために、産業界標準の次の階層である1300Wに移行した。
EU Lot 9規制は、欧州連合に展開するサーバーが、負荷10%、20%、50%、100%において規制で指定された効率率閾値を満たす電源装置を備えることを要求する。この閾値は80 PLUS Power Supply認証プログラムのチタニウムグレードPSU要件と一致する。Gen13ではEU Lot 9に完全準拠するためチタニウムグレードPSUを選択し、欧州のデータセンターをはじめとする全世界での展開を可能にした。
セキュリティと管理の継続性
Project Argus DC-SCM 2.0の継承
Gen13では、Gen12で導入された管理機能とセキュリティ関連コンポーネントをマザーボードから分離するアーキテクチャを維持する。これらは「Project Argus」データセンターセキュアコントロールモジュール2.0（DC-SCM 2.0）に集約されている。
DC-SCMモジュールには、サーバーのセキュリティの中枢となる重要なコンポーネントが収められている。
- 基本入出力システム（BIOS）
- ベースボード管理コントローラ（BMC）
- ハードウェアルートオブトラスト（HRoT）とTPM
- 冗長性のためのデュアルBMC/BIOSフラッシュチップ
このアーキテクチャをGen13でも継続する決定は、前世代で実証されたセキュリティ上の利点に基づく。管理機能を専用モジュールにオフロードすることで、以下のメリットを維持できる。
迅速な回復機能は、デュアルイメージ冗長性により、偶発的な破損や悪意のある更新が検出された場合にBIOS/UEFIおよびBMCファームウェアをほぼ瞬時に復元できる。
物理的耐性については、Gen13シャーシでは侵入検知メカニズムをシャーシの平坦な端からさらに遠ざけ、物理的な傍受を難しくしている。
PCIe暗号化は、Gen10プラットフォームから有効化されていたCPUとメモリ間の暗号化（TSME）に加え、AMD Turin 9965プロセッサがPCIeトラフィックにも暗号化を拡張する。これにより、システム内のすべてのバスを通過するデータが転送中も保護される。
運用的一貫性も重要だ。Gen12管理スタックを維持することで、セキュリティ監査、展開、プロビジョニング、運用標準手順が完全に互換性を保つ。
ドロップインアクセラレータサポートの強化
フリートのモジュール性維持は、Cloudflareのサーバー設計における中核的な要件だ。この要件により、Cloudflareは2024年にGPUを世界中の100以上の都市に迅速に改造・展開できた。
Gen13では、高性能PCIeアドインカードのサポートを継続する。Gen13の2Uシャーシレイアウトは更新され、より要求の厳しい電力と熱要件をサポートするように構成されている。Gen12がシングル幅GPU1枚に制限されていたのに対し、Gen13アーキテクチャはダブル幅PCIeカード2枚をサポートする。
この記事のポイント
- Cloudflare Gen13サーバーは192コアAMD EPYC Turin 9965を採用し、前世代比最大2倍のスループットを実現
- FL2（Rust製新リクエスト処理層）への移行により、大容量L3キャッシュへの依存を解消。コア数増加による性能向上を可能にした
- メモリは12チャネルDDR5-6400構成で768GBを実装。帯域幅33%向上とコアあたり4GBの適正容量を維持
- ネットワークは8年ぶりに刷新。デュアル25GbEからデュアル100GbEへ移行し、帯域幅ボトルネックを解消
- セキュリティはProject Argus DC-SCM 2.0アーキテクチャを継承。PCIe暗号化を追加し、データ転送中の保護を強化
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Kubernetesの1行修正で年600時間を削減——Cloudflareが直面したPVマウントの罠
Kubernetesの設定ファイルをたった1行書き換えるだけで、年間600時間ものエンジニア工数を削減した事例がある。Cloudflare（クラウドフレア）のインフラチームが直面したこの問題は、システムの規模が拡大するにつれて静かに忍び寄る「デフォルト設定の罠」を浮き彫りにした。
原因は、ストレージの権限管理を行うKubernetesの標準的な振る舞いにあった。数百万ものファイルを抱えるボリュームにおいて、再起動のたびに30分ものダウンタイムが発生していた事態を、彼らはどのように特定し、解決したのだろうか。
本記事では、CloudflareのエンジニアであるBraxton Schafer氏が公開したデバッグの過程と、大規模なKubernetes運用において見落としがちなパフォーマンスのボトルネックについて詳しく解説する。
Atlantisの再起動がなぜか「30分」もかかる謎
Cloudflareでは、Terraform（テラフォーム）によるインフラ管理の自動化ツールとして「Atlantis（アトランティス）」を利用している。Terraformはコードでインフラを定義するツールだが、Atlantisを導入することで、GitHubやGitLabのプルリクエスト上で実行計画（Plan）の確認や適用（Apply）が可能になる。
AtlantisはKubernetes上で「StatefulSet（ステートフルセット）」として動作しており、リポジトリの状態を保持するためにPV（Persistent Volume / 永続ボリューム）を使用している。StatefulSetとは、Pod（ポッド）の再起動後もデータの永続性を保証するための仕組みだ。
頻繁な再起動がエンジニアの時間を奪う
問題は、このAtlantisを再起動するたびに発生していた。新しいプロジェクトの設定を読み込ませたり、認証情報を更新したりするために、Cloudflareでは月に約100回ほどの再起動を行っていた。しかし、再起動を開始してからPodが正常に立ち上がるまで、毎回30分もの時間がかかっていたという。
この間、エンジニアはインフラの変更を行うことができず、作業が完全にブロックされてしまう。月100回の再起動で毎回30分待機が発生すれば、月間で50時間、年間では600時間もの時間が「ただの待ち時間」として消えていく計算だ。これは、一人のエンジニアが数ヶ月間フルタイムで働く時間に匹敵する大きな損失である。
「inode不足」がきっかけで表面化した問題
この遅延が決定的な問題として認識されたのは、ストレージの「inode（アイノード）」が枯渇した際だった。inodeとは、ファイルシステム上でファイルやディレクトリの情報を管理するためのデータ構造だ。ファイルが大量に作成されると、ディスク容量が残っていてもinodeが足りなくなり、新しいファイルが作成できなくなる。
Cloudflareの環境では、ファイルシステムを拡張することでしかinodeを増やせない仕様だった。拡張を反映させるにはPodの再起動が必要となり、そのたびに30分のダウンタイムが発生する。チームは当初、アラートの通知設定を調整して「見かけ上の問題」を回避することも検討したが、根本的な原因の調査に乗り出すことを決めた。
Kubernetesのログを深掘りして見えてきたボトルネック
調査を開始したBraxton Schafer氏は、まずkubectl rollout restartコマンドを実行し、新しいPodが立ち上がる様子を観察した。Pod自体はすぐにスケジュールされるものの、ステータスが「Init（初期化中）」のまま30分間も停止していることが判明した。
Podのイベントログを確認しても、イメージのプルが開始されるまでに不可解な空白時間があることしかわからなかった。そこで氏は、より低レイヤーのログを確認するため、各ノードで動作するコンポーネント「kubelet（クブレット）」のログを調査した。
kubeletのログに隠された「空白の時間」
kubeletは、各ノードでPodの実行を管理し、ボリュームのマウントなどを制御する重要なエージェントだ。システム管理ツールであるKibana（キバナ）を使ってログを分析したところ、PVのマウント自体は成功しているものの、その直後にタイムアウトエラーが発生し、リトライを繰り返している様子が記録されていた。
ログには「context deadline exceeded（処理時間の制限を超過した）」というメッセージが並んでいた。何らかの処理が異常に時間を要しており、Kubernetesの監視機構がそれを「失敗」とみなして処理を中断、再試行するというループに陥っていたのだ。
数百万個のファイルが引き起こす権限変更の罠
さらに詳細なログを追うと、決定的なメッセージが見つかった。そこには「Setting volume ownership（ボリュームの所有権を設定中）」という記述があった。実はこれが、30分もの時間を浪費させていた真犯人だった。
Kubernetesには、Pod内のプロセスがボリュームにアクセスできるように、マウント時に所有権を自動で調整する機能がある。具体的には、PodのsecurityContextで指定されたfsGroupのIDに合わせて、ボリューム内の全ファイルに対して再帰的にchgrp（グループ変更）を実行する。Atlantisのようなツールは運用期間が長くなるほど管理するファイル数が増大し、Cloudflareの環境では数百万個ものファイルが蓄積されていた。高速なストレージであっても、数百万個のファイルに対して一つずつ権限を確認・変更していく処理には膨大な時間がかかるのは必然だ。
わずか1行の修正でパフォーマンスが劇的に改善
原因が「再帰的な権限変更」であると特定できれば、解決策は非常にシンプルだった。Kubernetes 1.20以降、この振る舞いを制御するための新しい設定項目が追加されている。それがfsGroupChangePolicy（エフエスグループ・チェンジ・ポリシー）だ。
デフォルトでは、このポリシーはAlways（常に実行）に設定されている。つまり、Podが起動するたびに、すでに権限が正しく設定されていようがいまいが、すべてのファイルをスキャンして権限を上書きしようとする。これが大規模なボリュームにおいて致命的な遅延を引き起こす。
fsGroupChangePolicyの設定とは
解決策は、このポリシーをOnRootMismatch（ルートディレクトリが不一致の場合のみ実行）に変更することだ。この設定にすると、Kubernetesはまずボリュームのルートディレクトリの権限を確認する。もしルートの権限がすでに正しく設定されていれば、配下のファイルに対する再帰的なスキャンをスキップする。
spec:
template:
spec:
securityContext:
fsGroupChangePolicy: OnRootMismatchこの1行をマニフェストファイルに追加するだけで、権限変更のプロセスが大幅に簡略化される。Cloudflareのケースでは、これまで30分かかっていた再起動時間が、わずか30秒にまで短縮された。実に60倍の高速化だ。
30分から30秒へ、驚異的な短縮効果
この修正により、エンジニアがデプロイの待ち時間に拘束されることがなくなった。また、再起動が長引くことによって発生していた「Podが正常に起動しない」という偽のアラートに、オンコール担当者が夜中に叩き起こされることもなくなったという。技術的には極めて単純な変更だが、組織全体の生産性に与えたインパクトは計り知れない。
大規模システムにおける「デフォルト設定」の落とし穴
今回の事例から学べる最も重要な教訓は、Kubernetesの「安全なデフォルト設定」が、規模の拡大とともに牙を向く可能性があるということだ。fsGroupによる自動的な権限変更は、初心者が権限エラーに悩まされないようにするための親切な機能として設計されている。
しかし、エンタープライズレベルの運用において、数テラバイトのデータや数百万のファイルを扱うようになると、その「親切心」がシステムの可用性を損なう要因へと変わる。これは、小規模なプロジェクトでは決して表面化しない問題だ。
小規模なら問題ないが、スケールするとボトルネックになる
多くのインフラエンジニアは、マウントが遅い場合にネットワークやストレージ装置の性能を疑う。しかし、今回のケースのように「OSレベルのファイル操作」がバックグラウンドで走っていることに気づくには、深いオブザーバビリティ（観測性）が必要だ。Braxton Schafer氏が、Kubernetesのイベントログだけでなく、kubeletのシステムログまで掘り下げたことが早期解決の鍵となった。
SRE的視点での教訓
SRE（Site Reliability Engineering / サイト信頼性エンジニアリング）の観点では、「なぜシステムはこのように振る舞うのか？」という問いを持ち続けることの重要性が再確認された。30分の待ち時間を「そういうものだ」と受け入れてしまえば、年間600時間の損失は永遠に解消されなかっただろう。
もし読者の環境でも、特定のPodの起動が異常に遅かったり、ボリュームをマウントする際にInitコンテナで止まっていたりする場合は、securityContextの設定を見直してみる価値がある。特に、大量の静的ファイルを保持するCMSや、データベースのバックアップファイルを扱うPodなどは、同様の問題を抱えている可能性が高い。
この記事のポイント
- 原因の特定: Atlantisの再起動に30分かかっていたのは、Kubernetesがマウント時に全ファイルの所有権を再帰的に変更していたため。
- 1行の修正:
fsGroupChangePolicy: OnRootMismatchを設定することで、不要な権限変更をスキップできる。 - 劇的な改善: Cloudflareはこの修正により、再起動時間を30分から30秒に短縮し、年間600時間の工数を削減した。
- 教訓: 安全のためのデフォルト設定が、大規模環境では深刻なパフォーマンス低下を招くことがある。
- 推奨アクション: 大容量PVを使用するPodでは、
securityContextの設定を監査し、不必要な再帰処理を避ける設定を検討すべきだ。
出典
- Cloudflare Blog「A one-line Kubernetes fix that saved 600 hours a year」（2026年3月26日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare Workflowsの可視化技術——ASTを活用したコードから図への変換プロセスを解説
Cloudflare Workflowsでデプロイされたすべてのワークフローに対し、ダッシュボード上で完全な視覚的図解（ダイアグラム）を表示する機能が追加された。この機能は、YAMLやJSONのような宣言的な設定ファイルからではなく、実際に記述されたJavaScript/TypeScriptのコードを直接解析して生成される点が最大の特徴だ。
開発者が記述したコードを「oxc-parser」を用いてAST（Abstract Syntax Tree / 抽象構文木）へと変換し、静的解析によってステップ間の依存関係や並列処理を抽出している。これにより、複雑なループや条件分岐を含む動的なワークフローであっても、その構造を一目で把握することが可能になった。
AIエージェントによるコード生成が増加する現代において、人間がコードの全容を即座に理解するための補助ツールとして、この可視化技術は極めて重要な役割を果たす。本記事では、難解な最小化済みコードからどのようにして意味のある図を導き出しているのか、その技術的な裏側を詳しく見ていく。
Cloudflare Workflowsの可視化機能とその背景
なぜ「コードからの可視化」が必要なのか
従来のワークフロー構築ツールの多くは、ドラッグ＆ドロップのビジュアルエディタや、YAML/JSONによる宣言的な定義をベースにしていた。これらは図解しやすい反面、複雑なロジックを記述する際の柔軟性に欠けるという弱点がある。
対してCloudflare Workflowsは「コードがすべて」というモデルを採用している。Promise.allによる並列実行、複雑なforループ、条件分岐などが通常のJavaScriptとして記述できる。しかし、自由度が高い反面、コードが複雑になると全体の流れを把握するのが難しくなる。記事によれば、特にAIが生成したコードを人間が確認する際、その「形状（shape）」を視覚的に理解できるメリットは大きいという。
動的実行モデルという技術的ハードル
Workflowsは「動的実行モデル」に従っている。これは、ランタイムがコードを実行中にステップ（step.do）に遭遇するたびに、制御をエンジン（Durable Object）に渡す仕組みだ。エンジンは実行されたステップの結果を保存するが、次にどのステップが来るかを事前には知らない。
図を作成するには、実行前（デプロイ時）に全体の構造を知る必要がある。しかし、エンジンが実行時にしかステップを把握できないのであれば、静的な図を作ることはできない。そこで、Cloudflareのチームはデプロイ時にスクリプトを解析し、コードの構造を「読み解く」アプローチを選択した。
AST（抽象構文木）を用いたコード解析の仕組み
最小化されたJavaScriptという難問
デプロイされるコードは、通常esbuildやrspack、viteなどのツールによって「最小化（Minify）」されている。変数名はaやbに書き換えられ、改行は消え、人間には解読不能な1行の巨大な文字列となる。この状態からワークフローのステップを抽出するのは容易ではない。
AST（Abstract Syntax Tree / 抽象構文木）とは、プログラミング言語の構文構造を樹木構造で表現したデータ形式だ。コードをトークンに分解し、どの関数がどの引数で呼び出されているかを構造的に把握できる。Cloudflareは、このASTを利用して最小化されたコードのジャングルからstep.doやstep.sleepといった特定の呼び出しを特定している。
高速な解析を実現するoxc-parserの採用
解析エンジンには、Rust製の高速なJavaScriptツールチェーンである「OXC（JavaScript Oxidation Compiler）」のoxc-parserが採用された。当初はコンテナ上でRustを動かしていたが、最終的にはWebAssembly（Wasm）を介してCloudflare Workers上で動作するRust Workerへと移行されたという。
このRust Workerが最小化されたJSをASTに変換し、定義されたノードタイプ（LoopNode, ParallelNode, IfNodeなど）にマッピングしていく。以下に、コードがどのようにASTを経て図の要素へ変換されるかの概念図を示す。
step.do('task', ...)このデモは、ソースコードがAST解析を経て、最終的にダッシュボード上の視覚的なステップノードへとマッピングされる流れを視覚化したものだ。
複雑なロジックをグラフ構造にマッピングする手法
並列処理を表現する「開始」と「解決」のインデックス
Workflowsにおいて最も表現が難しいのが、並列処理だ。JavaScriptではawaitを付けずにステップを呼び出すと並列に実行され、Promise.allでそれらをまとめて待機できる。これを図にするため、Cloudflareのチームは各ノードにstartsとresolvesというフィールドを持たせた。
解析中にawaitされていないPromiseに遭遇すると、そのノードに「開始（starts）」のインデックスを付与する。その後、awaitに遭遇した時点でインデックスを増やし、「解決（resolves）」として記録する。この数値の重なりを見ることで、どのステップが垂直方向に並ぶべきか（＝並列か）、どのステップが完了を待って次に進むべきかを正確に判定している。
制御構文（ループ・分岐）のパターン網羅
単なる直線的なフローだけでなく、実務では多様な構文が使われる。著者のAndré氏とMia氏は、以下のような多岐にわたるパターンをASTから抽出できるように設計したと述べている。
- ループ:
for...of,while,items.map,forEach - 分岐:
switch/case,if/else, 三項演算子 - エラーハンドリング:
try/catch/finally - 関数呼び出し: ステップをラップした関数の追跡
特に、関数の中に隠れたステップの追跡は工夫が必要だ。ある関数が直接ステップを呼び出していなくても、その中で呼び出している別の関数がステップを含んでいる場合、その依存関係をグラフに含める必要がある。記事によれば、関数ごとのサブグラフを作成し、最終的にステップを含まない「葉」の部分をトリミングすることで、ノイズのない図を実現している。
開発体験（DX）における可視化の価値と今後の展望
デバッグ効率を劇的に高めるリアルタイム追跡
この可視化機能は単なる「清書された図」ではない。Cloudflareは、これをフルサービスのデバッグツールへと進化させる計画だ。具体的には、実行中のワークフローが今どのノードにいるのかをグラフ上でリアルタイムに追跡できるようにするという。
エラーが発生した場所の特定、人間による承認待ちの状態確認、あるいはテスト目的での特定ステップのスキップなど、ビジュアルインターフェースを通じて操作できる未来を目指している。さらに、ローカル開発環境での可視化も視野に入れているとのことで、開発サイクル全体での利便性向上が期待される。
独自の分析：コードを「正解」とするアプローチの意義
今回のCloudflareの取り組みで特筆すべきは、「ビジュアルエディタで作ったものをコードに書き出す」のではなく、「コードからビジュアルを逆生成する」という方向性を徹底している点だ。これは、エンジニアにとっての真実の源泉（Source of Truth）が常にコードであることを尊重している。
このアプローチの利点は、Gitによるバージョン管理やコードレビューといった既存の開発フローと完全に共存できることにある。図を作成するために特別な設定ファイルを書く必要がなく、普段通りにコードを書くだけで、非エンジニアのステークホルダーにも共有しやすい図が手に入る。これは、開発組織におけるコミュニケーションコストを大幅に下げる可能性を秘めている。
また、AST解析という「枯れた」技術を、最小化されたJSという「汚れた」実データに適用し、それをWasmでエッジ上で高速実行するという構成は、非常にCloudflareらしい合理的でパワフルな解決策だと言えるだろう。
この記事のポイント
- コードから図を自動生成: Cloudflare Workflowsは、JS/TSコードを解析して視覚的な図を自動作成する。
- AST（抽象構文木）の活用: 最小化された難解なコードも、AST解析によって構造的に理解し、ステップを抽出する。
- oxc-parserによる高速処理: Rust製の解析器をWasmで動かすことで、デプロイ時の高速な図解生成を実現した。
- 並列処理の可視化:
startsとresolvesというインデックスを用いて、複雑な並列実行の関係を正確に図示する。 - デバッグツールへの進化: 今後はリアルタイムの実行追跡や、図からの操作機能も追加される予定だ。
出典
- Cloudflare Blog「How we use Abstract Syntax Trees (ASTs) to turn Workflows code into visual diagrams」（2026年3月27日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AIエージェント実行を100倍高速化。Cloudflare Dynamic Worker Loaderの革新性
AIエージェントが自らコードを書き、それを実行してタスクを完結させる「コード実行型」のワークフローが注目を集めている。しかし、AIが生成したコードを安全に動かすには、メインのシステムから隔離された「サンドボックス」が不可欠だ。
Cloudflareは2026年3月24日、このサンドボックスをオンデマンドで、かつ従来のコンテナ技術より100倍高速に起動できる「Dynamic Worker Loader」のオープンベータ公開を発表した。V8 Isolate技術を基盤とすることで、ミリ秒単位の起動と圧倒的なリソース効率を実現している。
この記事では、Dynamic Worker LoaderがなぜAIエージェントのスケールにおいて重要なのか、そしてエンジニアがどのようにこれを活用できるのかを詳しく解説する。
AIエージェントの安全性を支える「サンドボックス」の課題
AIエージェントがAPIを呼び出す際、単なる「ツール呼び出し（Tool Calling）」ではなく、コードを生成して実行させる手法は、トークン消費量を大幅に削減できることが分かっている。記事によれば、TypeScript APIを使用することで、トークン使用量を最大81%削減できた例もあるという。
なぜAI生成コードの直接実行は危険なのか
AIが生成したコードをアプリケーション内で直接実行（evalなど）することは、セキュリティ上の致命的なリスクとなる。悪意のあるユーザーがプロンプトを通じて脆弱性を注入し、システムの機密情報にアクセスしたり、不正な操作を行ったりする可能性があるからだ。
そのため、コードを実行する場所は、アプリケーションや他の環境から完全に隔離された「サンドボックス（砂場）」でなければならない。サンドボックスとは、特定の権限やリソースのみにアクセスを制限した実行環境のことだ。
既存のコンテナ技術が抱える「重さ」の壁
これまで、サンドボックスの構築にはDockerなどのLinuxコンテナが一般的に使われてきた。しかし、コンテナには大きな弱点がある。起動に数百ミリ秒から数秒かかり、メモリ消費量も数百MB単位と「重い」ことだ。
数百万人のユーザーがそれぞれAIエージェントを動かすようなコンシューマー規模のサービスでは、コンテナを都度立ち上げるコストは無視できない。かといって、セキュリティのためにコンテナを使い回さず、リクエストごとにクリーンな環境を用意しようとすると、パフォーマンスとコストの両面で限界に突き当たる。
Dynamic Worker Loader：V8 Isolateによる100倍速の革新
Cloudflareが提供する「Dynamic Worker Loader」は、この「重さ」の問題を根本から解決する。その鍵となるのが、Google Chromeでも採用されているJavaScript実行エンジン「V8」の「Isolate（アイソレート）」という仕組みだ。
起動時間は数ミリ秒、メモリ消費も最小限
Isolateは、OSレベルの仮想化であるコンテナとは異なり、プロセス内でメモリを論理的に分離する。これにより、起動時間はわずか数ミリ秒、メモリ消費も数MB程度に抑えられる。著者のKenton Varda氏らは、これが一般的なコンテナと比較して「100倍高速で、10〜100倍メモリ効率が良い」と指摘している。
この軽量さにより、1つのリクエストごとに新しいサンドボックスを生成し、実行が終わったら即座に破棄するという運用が現実的になる。同時並行で数百万のリクエストが発生しても、Cloudflareのインフラ上でシームレスにスケール可能だ。
世界数百拠点でのゼロレイテンシ実行
Dynamic Worker Loaderで生成されたワーカーは、通常、それを作成した親ワーカーと同じマシン、あるいは同じスレッド上で動作する。そのため、遠くのサーバーにある「ウォーム状態のコンテナ」を探しに行く必要がない。
Cloudflareが世界中に持つ数百の拠点すべてで動作するため、ユーザーに最も近い場所で、遅延（レイテンシ）をほぼ感じさせることなくAIコードを実行できるのが強みだ。
TypeScript RPCによる効率的なAPI連携
AIエージェントが外部のAPIと通信する際、従来はOpenAPI（REST）などの定義ファイルが使われてきた。しかし、Dynamic Worker Loaderでは、より簡潔な「TypeScript」による定義を推奨している。
OpenAPIより優れたトークン効率
OpenAPIの定義ファイルは冗長になりがちで、LLM（大規模言語モデル）に読み込ませる際のトークン消費が激しい。一方、TypeScriptのインターフェース定義は非常にコンパクトだ。AIにとっても理解しやすく、少ないトークン数でAPIの仕様を正確に伝えられる。
Dynamic Worker Loaderは「Cap’n Web RPC」という技術を使って、サンドボックス内のエージェントと親ワーカーの間で高速な通信を行う。エージェント側からは、あたかもローカルライブラリを使っているかのように、型安全なメソッド呼び出しが可能になる。
認証情報の注入とセキュアな外部接続
セキュリティ面でも、このRPCモデルは有利に働く。例えば、外部サービスへの認証トークンをエージェントに直接教える必要はない。エージェントがHTTPリクエストを送る際、親ワーカー側でリクエストをインターセプト（傍受）し、そこで認証ヘッダーを付与する「Credential Injection（認証情報の注入）」が可能だからだ。
これにより、万が一AIが生成したコードに悪意があったとしても、生の認証情報がエージェント側に漏洩するリスクを最小限に抑えられる。
AI開発を加速させる3つの公式ヘルパーライブラリ
Cloudflareは、Dynamic Worker Loaderをより使いやすくするために、3つの強力なヘルパーライブラリを提供している。これらを組み合わせることで、高度なAIエージェント環境を短期間で構築できる。
コード実行を簡略化する「Code Mode」
@cloudflare/codemodeは、LLMが生成したコードの実行を管理するライブラリだ。コードの正規化（フォーマットエラーの修正）や、fetch()の挙動制御を簡単に行える。完全に隔離された状態（ネットワークアクセス禁止）から、特定のプロキシ経由の通信まで、柔軟に設定可能だ。
ランタイムでのバンドルを可能にする「Worker Bundler」
Dynamic Workerは、依存関係が解決された「バンドル済み」のモジュールを必要とする。@cloudflare/worker-bundlerを使えば、実行時にnpmパッケージを含むソースコードをバンドルできる。例えば、Honoなどの軽量フレームワークをAIエージェントに使わせることも容易だ。
仮想ファイルシステムを提供する「Shell」
@cloudflare/shellは、サンドボックス内に仮想的なファイルシステムを提供する。エージェントはファイルの読み書き、検索、置換、diffの取得などが可能になる。ストレージの実体はSQLiteやR2（Cloudflareのオブジェクトストレージ）に保存されるため、実行を跨いでファイルを永続化させることもできる。
実務への応用とコストパフォーマンスの分析
Dynamic Worker Loaderの導入は、AIアプリケーションのアーキテクチャに大きな変革をもたらす。筆者の分析によれば、特に以下の3つの分野で大きなメリットがある。
第一に、「Tool Calling」のオーバーヘッド削減だ。従来のように、AIが1つずつツールを呼び出して結果を待ち、次のアクションを決めるループを繰り返すと、その都度コンテキストが膨らみ、レイテンシも増大する。Dynamic Workerを使えば、AIが「一連の処理をまとめたスクリプト」を一度に書き、それを実行するだけで済む。これは、大規模なAPIセットを持つシステムほど効果が高い。
第二に、コスト効率の劇的な向上だ。Dynamic Workerの料金は、ロード1回につき0.002ドル（ベータ期間中は無料）に、通常のCPU使用料が加算される仕組みだ。これはLLMの推論コストと比較すれば微々たるものだ。重いコンテナを常時起動させておく「ウォームスタンバイ」のコストから解放される意味は大きい。
第三に、プロトタイピングの高速化だ。Ziteなどの企業がすでに導入しているように、ユーザーの要望に応じてその場でCRUDアプリや自動化ロジックを生成し、即座にデプロイして動かすような「AIネイティブなPaaS」の構築が容易になる。
この記事のポイント
- 100倍の高速化: V8 Isolateにより、コンテナより圧倒的に速く軽量なサンドボックスを実現。
- セキュアな隔離: AI生成コードをメインシステムから分離し、安全にオンデマンド実行できる。
- 高いトークン効率: TypeScript RPCを活用し、冗長なOpenAPI定義を避けてコストを削減。
- 充実のライブラリ: コード実行、バンドル、ファイル操作を支援する公式ツールが提供されている。
- スケーラビリティ: Cloudflareのグローバルネットワーク上で、数百万のリクエストに即座に対応可能。
出典
- Cloudflare Blog「Sandboxing AI agents, 100x faster」（2026年3月24日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VPNからCloudflare Oneへ——レガシー環境を安全にSASEへ移行するための戦略的ロードマップ
ネットワークエンジニアにとって、既存のVPN環境を新しいアーキテクチャへ切り替える週末は、キャリアの中でも最もストレスのかかる48時間になりかねない。数万人規模の組織が、千を超えるレガシーアプリケーションを断片化されたVPNから新環境へ一斉に移行しようとすれば、そのリスクは計り知れないものになる。
設定ミス一つで基幹サービスが停止し、業務が停滞する恐怖は、多くの組織がZero Trust（ゼロトラスト）への移行を躊躇する最大の要因だ。ゼロトラストとは「何も信頼しない」ことを前提に、すべてのアクセスを検証するセキュリティモデルを指す。本記事では、Cloudflareが提唱する「ビッグバン」を避けた、安全でアジャイルなSASE移行の戦略について解説する。
SASE（Secure Access Service Edge / サシー）は、ネットワーク機能とセキュリティ機能をクラウド上で統合して提供する枠組みだ。この記事を読むことで、レガシーなインフラを抱える企業が、いかにしてダウンタイムなしに最新のセキュリティポスチャ（セキュリティの状況や姿勢）へと進化できるかが理解できるだろう。
なぜレガシーVPNからの脱却は「ビッグバン」ではいけないのか
従来のネットワーク移行でよく見られる失敗は、ネットワークを単なる「配管」として扱ってしまうことだ。元記事の著者であるWarnessa Weaver氏は、多くの組織がアプリケーション間の複雑な依存関係を理解せずに、数百のアプリを一斉に移動させる「リフト・アンド・シフト」の罠に陥っていると指摘している。
ネットワークを単なる「配管」と捉えるリスク
多くの企業において、ネットワークは単にデータを運ぶ土台ではなく、アプリケーションやデータベースが密接に絡み合ったエコシステムとなっている。ある公共部門のプロジェクトでは、4,000以上のアプリケーションのうち500個を一度に移行しようとした結果、システム全体に深刻なサービス中断が発生したという。これは、バックエンドの依存関係を精査せずに移行を強行した典型的な失敗例だ。
依存関係の把握不足が招くサービス停止の連鎖
VPN（Virtual Private Network）は、一度認証されるとネットワーク全体へのアクセスを許可する「境界型セキュリティ」に基づいている。これに対し、SASEへの移行は、アプリケーションごとにアクセス権限を細かく設定する「最小権限の原則」への移行を意味する。事前の調査なしにこの制限を適用すると、本来必要だった内部APIの呼び出しやデータベース接続が遮断され、アプリが正常に動作しなくなる。エンジニアは、移行を「配管の交換」ではなく「アプリケーションの近代化プロジェクト」として捉える必要がある。
Cloudflare Accessによるレガシーアプリケーションの「ラッピング」
移行のリスクを抑えるための鍵は、既存のアプリケーションを書き換えることなく、最新のセキュリティ層で「包み込む（ラッピングする）」ことだ。これには、Cloudflare Accessというツールが活用される。
コードを書き換えずにMFAを導入する仕組み
多くの古い（レガシーな）社内アプリには、多要素認証（MFA / Multi-Factor Authentication）の機能が備わっていない。MFAとは、パスワードだけでなく、スマホの承認や物理キーなど複数の手段で本人確認を行う仕組みだ。通常、これらを導入するにはアプリのコード修正が必要だが、Cloudflare Accessを使えば、アプリの前段に認証ゲートウェイを設置できる。これにより、アプリ自体は古いまま、最新のSSO（Single Sign-On）やMFAを強制することが可能になる。
Cloudflare Tunnelで外部からの攻撃面を最小化する
さらに、Cloudflare Tunnelという技術を組み合わせることで、セキュリティはより強固になる。これは、社内サーバーからCloudflareのネットワークに向かって「外向き」の接続を確立する仕組みだ。サーバーにパブリックIPアドレスを割り当てる必要がなくなるため、インターネット上からサーバーの存在自体を隠すことができる。攻撃者がスキャンしても入り口が見つからない状態、つまり「攻撃面（アタックサーフェス）」がほぼゼロになるのだ。
成功率を高めるための「4つの事前監査」とティア分け
移行を開始する前に、ITリーダーは環境の「建築的準備」を整える必要がある。CDWのセキュリティエグゼクティブであるEric Marchewitz氏によれば、十分な準備なしに最小権限アクセスを適用すると、多くのレガシーアプリが動作しなくなる可能性があるからだ。
IDプロバイダーと依存関係の徹底的な洗い出し
まず最初に行うべきは、アイデンティティ（ID）とアーキテクチャのアセスメントだ。Oktaのようなクラウド型IDプロバイダーを利用しているアプリと、古いローカルディレクトリを使っているアプリを仕分ける。同時に、バックエンドのデータベースやAPIの依存関係をマップ化する。このデータがあれば、切り替え時にどのAPIコールが切断されるかを事前に予見し、対策を講じることができる。
アプリケーションの複雑度に応じた4段階のティア管理
元記事では、アプリケーションをその技術的複雑さに応じて4つの「ティア（階層）」に分類することを推奨している。これにより、現実的な移行スケジュールを立てることが可能になる。
| ティア | 説明 | 推定移行工数 |
|---|---|---|
| ティア 0 (モダンSaaS) | SAML/OIDC対応。CloudflareがIDプロバイダーとして機能する | 1アプリあたり1〜3時間 |
| ティア 1 (内部Webアプリ) | 標準的なWebプロトコル。Cloudflare Tunnelでリバースプロキシ化 | 1アプリあたり3〜6時間 |
| ティア 2 (非Webアプリ) | 特定のポートや厚いクライアントが必要。専用クライアントを使用 | 1アプリあたり4〜8時間 |
| ティア 3 (レガシー基幹) | P2Pや双方向通信が必要。WANデプロイメントなどの補完が必要 | 1アプリあたり1〜3日 |
段階的な移行を実現する「3フェーズ」のロードマップ
レガシーハードウェアからの「脱出速度」を得るために、CDWとCloudflareは、一斉置換ではなく「共存」を優先する段階的なロールアウトを提案している。
戦略策定からパイロット導入までのステップ
第1フェーズでは、戦略チームと実装チームを分離して組織する。第2フェーズでは、少数の従業員グループ（パイロットグループ）に対してCloudflare Oneクライアントを導入する。ここで重要なのは、セキュリティ強化による「遅延（レイテンシ）」がユーザー体験を損なわないかを確認することだ。Cloudflareは世界中にエッジ拠点を持っているため、多くの場合はVPNよりも高速な接続が期待できるが、実環境での検証は欠かせない。
VPNとCloudflare Oneを併用する「デュアルクライアント」期間
第3フェーズの生産スケールでは、既存のVPNとCloudflare Accessを一時的に併用する「デュアルクライアント」期間を設ける。これにより、万が一新環境で問題が発生しても、すぐに旧環境へロールバックできる安全策を確保する。ユーザーは徐々に新しいアクセス手法に慣れていくことができ、IT部門のサポート負担も分散される。このアプローチは、日本の企業における慎重なシステム移行プロセスとも非常に相性が良いと言えるだろう。
パフォーマンスと将来性——セキュリティを高速化の武器にする
セキュリティを強化すると動作が重くなる、という考えはもはや過去のものだ。Cloudflareのシングルパス・アーキテクチャは、すべてのセキュリティチェックを同時に実行するため、効率的なデータ処理が可能だ。
シングルパス・アーキテクチャによる遅延の解消
従来のセキュリティ対策では、ファイアウォール、ウイルススキャン、DLP（データ漏洩防止）などの各装置をデータが順番に通過するため、その都度遅延が発生していた。Cloudflareのアーキテクチャでは、これらをクラウド上の1回のパスで処理する。Cloudflare One GTM責任者のAnnika Garbers氏は、この「接続クラウド」への移行が、セキュリティチームがボトルネックになるのを防ぎ、運用速度を劇的に向上させると述べている。
ポスト量子暗号への対応と将来の脅威への備え
さらに、このプラットフォームは将来の脅威にも備えている。量子コンピュータが実用化されると、現在の暗号技術の多くが突破されるリスクがある。Cloudflareは既に「ポスト量子暗号（PQC / Post-Quantum Cryptography）」に対応した基盤を構築しており、今移行することは、将来的な脅威に対する防御を先行して手に入れることを意味する。一度クラウドベースのSASEに移行してしまえば、こうした最新技術の恩恵を、ハードウェアの買い替えなしに受け続けられるのが大きなメリットだ。
この記事のポイント
- ビッグバン移行を避ける：一斉切り替えはリスクが高すぎるため、段階的な「共存」モデルを採用すべきだ。
- ラッピングで近代化：レガシーアプリのコードを直さず、Cloudflare AccessでMFAやSSOを追加できる。
- 徹底した事前監査：IDプロバイダーの確認とアプリのティア分けが、移行の成功率を左右する。
- パフォーマンスの向上：シングルパス・アーキテクチャにより、セキュリティ強化と高速化を両立できる。
- 将来への備え：クラウド型SASEなら、ポスト量子暗号などの最新機能を即座に利用可能だ。
出典
- Cloudflare Blog「From legacy architecture to Cloudflare One」（2026年3月13日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress制作会社が直面する「成長の壁」と突破口——4人の創業者が語る経営のリアル
Web制作会社が成長の過程で直面する課題は、技術的な問題よりも経営上の意思決定に起因することが多い。特にWordPressを中心とした受託ビジネスでは、案件の獲得、組織の拡大、そして収益性の維持という3つの要素が複雑に絡み合う。15年以上にわたり業界の最前線でエージェンシーを率いてきた4人の創業者は、いかにしてこれらの「成長の壁」を突破してきたのか。
元記事によれば、Kinstaが実施したインタビューシリーズ「They figured it out (mostly)」において、規模も拠点も異なる4つの制作会社が、自らの失敗と成功の軌跡を明かしている。彼らの経験からは、単なるコーディングスキルを超えた、持続可能なビジネスを構築するための共通項が見えてくる。
本記事では、WooCommerceへの特化、エンタープライズ（大規模企業）向けエンジニアリングへの転換、そして1,000社以上のクライアントを抱える組織の管理術など、実務に直結する知見を整理した。Web制作の現場で指揮を執るディレクターや経営者にとって、自社のロードマップを描くための指針となるはずだ。
専門特化（ニッチ）がもたらす競争優位性
「何でもできる」ことは、制作会社にとって初期段階では武器になるが、成長段階では足かせになる場合がある。特定の領域に特化することで、競合との差別化を図り、高単価な案件を獲得する戦略が有効だ。ここでは、WooCommerceとサイバーセキュリティという異なる分野に特化した2社の事例を見ていく。
WooCommerceへの完全特化：Built Mightyの事例
シアトルを拠点とするBuilt Mightyの創業者、ジョニー・マーティン氏は、2009年にオンラインショップの運営者としてキャリアをスタートさせた。しかし、彼は次第にショップを運営することよりも、システムを構築すること自体に強い関心を持つようになった。これが、同社をWooCommerce専門の制作会社へと変貌させるきっかけとなった。
現在、同社はWooCommerceのカスタムプラグイン開発や複雑な外部システム連携を専門としている。他の制作会社が「技術的に難易度が高すぎる」として断るようなプロジェクトが、同社に集まってくる仕組みだ。マーティン氏は、特定のプラットフォームに精通した人材を揃えることが、最大の資産であると指摘している。
WooCommerceとは、WordPressをECサイト（ネットショップ）化するためのプラグインである。世界で最も利用されているECプラットフォームの一つだが、カスタマイズには高度なPHPの知識とデータベースの理解が求められる。Built Mightyはこの「難易度の高さ」を参入障壁として利用し、独自のポジションを確立した。
サイバーセキュリティとエンタープライズ：Fixelと40Q
ヴィン・トーマス氏が率いるFixelは、サイバーセキュリティ分野のスタートアップとの仕事をきっかけに、そのニッチな市場での地位を固めた。初期のクライアントが業界内で買収・統合されるたびに、そのマーケティング担当者が新たな会社でFixelを指名するという「紹介の連鎖」が発生した。これにより、広告費をかけずに専門性の高いポートフォリオを構築することに成功した。
一方、ブエノスアイレスの40Qは、自らを「WordPressデベロッパー」ではなく「WordPressエンジニア」と定義している。同社のエディー・ワイズ氏は、単にテーマをカスタマイズするのではなく、DAM（Digital Asset Management：デジタル資産管理）やLMS（Learning Management System：学習管理システム）といった、複雑なアプリケーション開発の概念をWordPressに持ち込んでいる。
DAMとは画像や動画などの素材を一元管理する仕組み、LMSはオンライン講座などを運営するための基盤である。これらをWordPressで構築するには、一般的なWebサイト制作とは一線を画す設計思想が必要となる。40QはAdobe Experience Managerなどの高価なエンタープライズ向けツールと比較されるレベルのソリューションを提供することで、大規模案件を勝ち取っている。
組織拡大の罠と「正しいサイズ」の再定義
案件が増えれば人を増やす。この一見正論に思えるサイクルが、組織のアイデンティティを損なうリスクを孕んでいる。制作会社が成長する過程で直面する「採用」と「組織規模」の課題について、創業者の実体験に基づいた教訓が語られている。
「Hire Fast, Fire Fast」——採用プロセスの変革
Built Mightyのマーティン氏は、従来の「慎重に採用し、速やかに解雇する（Hire slow, fire fast）」という格言は、現代のスピード感には合わないと考えている。同社では、履歴書を受け取ってから数日以内に、候補者に対して「有償のテストプロジェクト」を依頼する。面接だけで人柄やスキルを見極めるのは不可能に近いからだ。
テストプロジェクトを通過した候補者は、実際のクライアントワークに携わる前に、架空のクライアントを想定したオンボーディング（導入研修）を受ける。このプロセスにより、実務開始から1週間以内にその人材がチームにフィットするかどうかが判明する。マーティン氏によれば、この「高速な試行」こそが、ミスマッチによる損失を最小限に抑える鍵であるという。
140人から80人へ：Pronto Marketingの教訓
タイとフィリピンを拠点に1,000社以上のクライアントを抱えるPronto Marketingは、一時期、従業員数が140名まで膨れ上がった。創業者のティム・ケルシー氏は、エレベーターで一緒になった人物が自社の社員であることに気づかなかった経験を振り返っている。組織が大きくなりすぎたことで、誰が何をしているのかが見えなくなったのだ。
その後、同社はあえて規模を縮小し、現在は約80名の体制で運営している。ケルシー氏は、「自分の組織の限界を知るには、一度その限界を超えてみるしかない」と述べている。規模を追うことだけが正解ではなく、サービスの質を維持しながら管理が行き届く「適正規模」を見極めることの重要性が示唆されている。
収益構造の安定化とリスク管理
制作会社の経営において、特定のクライアントへの過度な依存や、不適切な価格設定は致命的なリスクとなる。4人の創業者は、大きな損失を経験したことで、より強固な収益モデルへと舵を切った。
特定クライアントへの依存という「時限爆弾」
Fixelのトーマス氏は、売上の3分の1を占めていた主要クライアントを失った経験を語っている。そのクライアントが数十億ドル規模で買収された際、継続していたリテーナー（月額固定の保守・運用契約）が突如終了した。大きな売上が一晩で消滅したことは、同社にとって深刻な打撃となった。
この経験から、トーマス氏は「卵を一つのカゴに盛らない」戦略の重要性を再認識した。現在は、特定のクライアントに依存しすぎないよう、顧客ポートフォリオの分散を意識し、不測の事態に備えたクッション（内部留保や複数の小規模案件）を確保することに注力している。
10年越しの価格改定がもたらした意外な結果
Pronto Marketingのケルシー氏は、10年以上据え置いていた月額サポート料金の改定に踏み切った際の出来事を明かしている。値上げの通知メールを送信した際、大量の解約が発生することを覚悟していた。しかし、実際に不満を漏らしたのは1,000社以上のうち、わずか2社だけだったという。
「なぜもっと早くやらなかったのか」とケルシー氏は振り返る。制作会社はクライアントとの関係悪化を恐れて価格改定を躊躇しがちだが、提供している価値に見合った適正な価格設定は、サービスを継続させるための責務でもある。特にインフレや人件費の高騰が続く状況では、定期的な価格見直しが経営の健全性を左右する。
技術トレンドへの向き合い方：AIとパートナーシップ
AIの台頭や広告単価の上昇など、外部環境は常に変化している。創業者の4人は、これらの変化を脅威として捉えるのではなく、自社のワークフローや成長戦略にどう組み込んでいるのだろうか。
AIは「思考」の代替ではなく「ツール」
4人の創業者に共通していたのは、AIを「魔法の杖」とは見なしていない点だ。Fixelではコンテンツ戦略のためにカスタムのClaude（AIモデルの一種）を活用し、40QではAIを活用したページビルダーの開発を進めている。しかし、AIが人間の「思考」そのものを代替することはないというのが彼らの一致した見解だ。
AIはプロセスを効率化し、より多くのタスクをこなす助けにはなるが、アウトプットの質を担保し、戦略的な判断を下すのは依然として人間の役割である。ケルシー氏のチームでは、AIが生成したものを必ず人間が反復（イテレーション）して磨き上げる工程を設けている。AIは戦略ではなく、あくまで道具であるという認識が重要だ。
広告よりも強力な「戦略的パートナーシップ」
40Qのワイズ氏は、デジタルマーケティングによるリード獲得（見込み客探し）よりも、戦略的パートナーシップの方が多くの案件をもたらすと断言している。また、Built Mightyのマーティン氏も、同規模あるいは異なる規模の制作会社とのネットワークを構築している。ある制作会社が閉業した際、長年の信頼関係があったために、50社ものクライアントをそのまま引き継いだ事例もあるという。
Google広告などのWeb広告に頼るのではなく、信頼に基づく紹介ネットワークを構築することが、結果として最も効率的な営業活動になる。これは、制作会社が「単なる下請け」ではなく、業界内での信頼を勝ち取った「パートナー」として認知されているからこそ成し遂げられることだ。
独自の分析：日本の制作会社が学ぶべき3つの教訓
今回の4人の創業者の対話から、日本のWeb制作業界にも共通する重要な示唆が得られる。筆者の分析によれば、特に以下の3点は、これからの厳しい市場環境を生き抜くために不可欠な要素である。
第一に、「WordPressのコモディティ化」への対策だ。単にサイトを立ち上げるだけのスキルは、ノーコードツールの普及やAIの進化により、急速に価値が低下している。40Qのように「エンジニアリング」の領域まで踏み込むか、Built Mightyのように特定のプラグインを極めるか、何らかの「技術的参入障壁」を自ら築く必要がある。
第二に、「採用と教育のリスクマネジメント」である。日本の制作現場でも慢性的な人材不足が続いているが、焦って採用した人材がミスマッチだった場合のコストは、金銭面だけでなく既存メンバーのモチベーションにも悪影響を及ぼす。Built Mightyが実践している「有償テストプロジェクト」は、実務能力とカルチャーフィットを同時に確認する合理的な手法として、日本でも導入を検討する価値があるだろう。
第三に、「リテーナーモデル（継続収益）の質的転換」だ。保守・運用という名目の「何もしない月額費用」は、クライアントにとって真っ先に削減対象となる。FixelやPronto Marketingのように、クライアントのビジネス成長に直接寄与する「パートナー」としての立ち位置を確立し、定期的な価値提供と適正な価格改定を行うことが、長期的な安定経営につながる。
この記事のポイント
- 専門分野の確立: WooCommerceやエンタープライズ向け開発など、特定のニッチに特化することで競合を排除し、高単価案件を獲得できる。
- 採用プロセスの高速化: 面接だけでなく有償のテストプロジェクトを実施し、1週間以内にフィット感を見極める「Hire Fast, Fire Fast」が有効。
- リスク分散と適正価格: 特定クライアントへの依存を避け、提供価値に見合った価格改定を躊躇せずに行うことが組織の持続可能性を高める。
- パートナーシップの活用: 広告による集客よりも、同業者や関連企業との信頼ネットワークを通じた紹介の方が、質の高いリード獲得につながる。
出典
- Kinsta Blog「4 agency founders share the decisions that shaped their businesses」（2026年3月18日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflareが「Custom Regions」発表。データ処理の地理的境界を自在に定義、ISMAP対応も拡充
Cloudflare（クラウドフレア）は2026年3月18日、同社の「Regional Services（リージョナル・サービス）」の大幅なアップデートを発表した。今回の更新では、特定の国や地域を自由に組み合わせてデータ処理の境界を定義できる「Custom Regions（カスタム・リージョン）」が導入された。
また、日本政府のセキュリティ評価制度である「ISMAP」への対応を含む、新しい管理リージョンの追加も行われている。これにより、企業はグローバルなDDoS防御の恩恵を受けつつ、各国の法規制やコンプライアンスに基づいた厳格なデータ局所化が可能になる。
データ主権（データ・ソブリンティ）への要求が世界的に高まる中、今回の機能拡張はインフラ構成の柔軟性を大きく向上させるものだ。記事によれば、従来の固定された地域選択から、個別のビジネスニーズに合わせた「独自の境界線」を引くフェーズへと移行したことが示唆されている。
Regional Servicesの仕組み：防御とコンプライアンスの両立
Cloudflareが提供するRegional Servicesは、グローバルネットワークの規模を活かしたセキュリティと、特定の地域内でのデータ処理という、一見相反する要素を両立させる仕組みだ。一般的なソブリンクラウド（主権クラウド）が特定の地域にインフラを隔離するのに対し、Cloudflareはネットワーク全体で攻撃を防ぎつつ、データの「中身」を扱う場所だけを限定する手法をとる。
グローバルなDDoS防御とローカル処理の共存
トラフィックの処理フローは、大きく4つの段階に分かれている。まず、ユーザーに最も近い世界各地のデータセンターでトラフィックを受け入れ、L3/L4（ネットワークおよびトランスポート層）レベルでのDDoS防御を即座に実行する。DDoS防御とは、大量の不要なデータを送りつけてサイトをダウンさせる攻撃を防ぐ仕組みであり、これを世界規模のネットワークで受けることで、攻撃を効率的に分散・無効化できる。
次に、パケットのメタデータを検査し、指定されたリージョン外のデータセンターに届いた場合は、Cloudflareのプライベートバックボーンを経由して指定リージョン内のデータセンターへと転送される。ここで重要なのは、この段階ではまだデータの復号（暗号化の解除）が行われていない点だ。
データの復号、つまりTLS（Transport Layer Security）の終端と、WAF（Web Application Firewall）によるL7（アプリケーション層）の検査、およびCloudflare Workersによるロジックの実行は、必ず指定されたリージョン内のデータセンターで行われる。これにより、機密性の高いデータの解析や処理を特定の地理的境界内に閉じ込めることが可能になる。最終的に、処理されたリクエストは再度暗号化され、オリジンサーバーへと送られる。
Custom Regionsによる柔軟なデータ制御
2020年の提供開始以来、Regional Servicesは欧州、英国、米国などの固定されたリージョンを提供してきた。しかし、各国の規制は複雑化しており、単一の国や特定の組み合わせでのデータ処理を求める声が強まっていた。これに応える形で登場したのがCustom Regionsだ。
独自の地理的境界を定義する「式」の活用
Custom Regionsでは、リストから地域を選ぶのではなく、開発者が「式（Expression）」を用いて処理場所を定義する。例えば、ISOコード（国コード）を使用して、特定の国を含める、あるいは除外するといった柔軟な設定が可能だ。記事では、以下のような定義例が示されている。
- 単一の国のみ（例：トルコのみ）
- 複数の国の組み合わせ（例：ドイツ、フランス、オランダ）
- 特定の国を除外（例：北米以外すべて）
この定義はCloudflareのインフラ全体に配布され、各データセンターが「自分はこのカスタムリージョンに含まれるか」を即座に判断する。インフラが拡張され、新しいデータセンターが稼働した場合も、条件に合致すれば自動的にリージョンに組み込まれるため、運用負荷が低いのも特徴だ。
実務における具体的な活用シナリオ
Custom Regionsの柔軟性は、法規制対応以外の場面でも威力を発揮する。著者のAndrew Berglund氏らは、早期アクセスユーザーによる活用例として、AI推論のリージョン化を挙げている。大規模言語モデル（LLM）へのプロンプトや応答を特定の国々に留めることで、パフォーマンスの最適化とデータ局所化の義務を同時に果たしているという。
また、政府機関との契約に基づいた特定の境界設定や、企業の組織構造（EMEA、APACなど）に合わせたガバナンスの適用にも利用されている。温度単位に華氏を使う国々（米国、バハマなど）といった、極めて特殊なグループ化さえも理論上は可能であり、ビジネス要件に合わせた「境界の設計」が可能になったと言える。
技術的アーキテクチャの深掘り
Custom Regionsがどのようにして最適なパフォーマンスと信頼性を維持しているのか、その裏側にはCloudflare独自のルーティング技術がある。単にデータを転送するだけでなく、リアルタイムのネットワーク品質を考慮した動的な決定が行われている。
最適なインレジョン・ルーティングの算出
リクエストがリージョン外のデータセンターに届いた際、どのリージョン内データセンターに転送すべきかの判断は、2段階のプロセスで行われる。まず、定義されたリージョンのメンバーセット（どのデータセンターが対象か）を特定する。次に、流入地点から見て最もパフォーマンスが高い転送先のリストを作成する。
このランキングは物理的な距離だけでなく、遅延（レイテンシ）、パケットロス、タイムアウトなどのネットワーク品質指標、さらには各拠点のキャパシティや負荷状況、稼働ステータスを基に算出される。この情報は「Quicksilver」と呼ばれるCloudflare独自の分散キーバリューストアを介して、エッジネットワーク全体に瞬時に共有される仕組みだ。
境界の強制とエラーハンドリング
Regional Servicesの設計思想において、レジリエンス（回復力）と境界の強制は最優先事項だ。ルーティング時には複数の候補地が考慮され、特定の拠点がダウンしている場合は、リアルタイムで次善の候補へとフェイルオーバー（切り替え）が行われる。ネットワークの監視データが不十分な場合は、新しいルーティング情報の更新を停止するなどの安全策も講じられている。
特筆すべきは「フェイル・クローズ（Fail-close）」設計だ。もし有効なリージョン内の転送先が一つも見つからない場合、リージョン外で処理を継続するのではなく、接続をエラーとして遮断する。これにより、意図しない場所でデータが復号されるリスクを物理的に排除している。
日本のISMAP対応と管理リージョンの拡大
今回のアップデートでは、Custom Regionsだけでなく、Cloudflareが定義・管理する「Managed Regions」も拡充された。新たにトルコ、アラブ首長国連邦（UAE）、オーストラリアのIRAP、そして日本のISMAPに対応したリージョンが追加され、合計で35のリージョンが利用可能となっている。
ISMAP（Information System Security Management and Assessment Program）とは、日本政府がクラウドサービスのセキュリティを評価するための制度だ。政府機関がクラウドを採用する際の基準となるものであり、民間企業にとっても信頼性の高いサービスの指標となっている。CloudflareがISMAP対応リージョンを明示したことは、日本の公共セクターや厳格なコンプライアンスを求める金融、インフラ企業にとって、導入の大きな後押しとなるだろう。
これらの管理リージョンは、Cloudflareの管理画面（ダッシュボード）やAPIから標準的な手順で有効化できる。一方で、独自の定義が必要なCustom Regionsについては、現時点ではセルフサービス形式ではなく、アカウントチームとの連携による個別設定が必要となる。将来的なセルフサービス化に向けた技術開発も継続されているとのことだ。
独自の分析：データ主権時代のインフラ戦略
Cloudflareの今回の発表は、エッジコンピューティングの役割が「高速化」から「統治（ガバナンス）」へと進化していることを象徴している。かつてのCDN（Content Delivery Network）は、いかにコンテンツを速く届けるかが主眼であったが、現代のWebインフラには「どこでデータを扱うか」という法的な正確性が求められている。
Custom Regionsが提供する「式による境界定義」は、コードによるインフラ管理（IaC）の流れを汲むものだ。地理的な境界をソフトウェア的に定義できるようになったことで、国境という物理的な制約を、アプリケーションのロジックと同じ柔軟さで扱えるようになった。これは、GDPR（欧州一般データ保護規則）などの地域特有の規制と、インターネットのボーダレスな利便性を橋渡しする重要な技術的解決策と言える。
特に日本市場においては、ISMAP対応の明文化が大きな意味を持つ。国内のレンタルサーバーやクラウドから、グローバルなエッジサービスへの移行を検討する際、最大の懸念事項であった「セキュリティ基準の適合」と「データの所在」がクリアされたからだ。今後は、グローバルなDDoS耐性を維持しつつ、日本の法域内で全ての重要処理を完結させる構成が、エンタープライズWebサイトの標準となっていくのではないだろうか。
この記事のポイント
- Cloudflareが「Custom Regions」を導入し、国単位でデータ処理の境界を自由に定義可能になった。
- 世界規模のDDoS防御を維持しつつ、TLS終端やWAF検査などのL7処理を指定地域内に限定できる。
- 日本政府のセキュリティ評価制度「ISMAP」に対応した管理リージョンが追加された。
- 独自のルーティング技術により、リージョン内での最適なパフォーマンスと、フェイル・クローズによる安全性を両立している。
- データ主権の確保とグローバルなセキュリティ対策を、一つのプラットフォームでシームレスに実現できる。
出典
- Cloudflare Blog「Introducing Custom Regions for precision data control」（2026年3月18日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
React/Next.jsで動的フォームを構築する2つの手法——RHF+ZodとSurveyJSの比較
Reactアプリケーションにおいて、フォームの実装は避けて通れない課題だ。ログイン画面のような単純なものから、条件分岐が複雑に絡み合う多ステップの入力フォームまで、その難易度は多岐にわたる。
多くの開発者が「フォームはコンポーネントとして構築すべきだ」という共通のメンタルモデルを持っている。React Hook Form（RHF）とZodを組み合わせる手法は、現在のReactエコシステムにおける標準的な選択肢となっている。
しかし、フォームが「UI」の枠を超え、複雑な「ルールエンジン」へと変貌したとき、このモデルは限界を迎える。本記事では、コンポーネント駆動とスキーマ駆動という2つの異なるアプローチを比較し、プロジェクトに最適な手法を選択するための基準を提示する。
コンポーネント駆動アプローチ：React Hook FormとZodの組み合わせ
React Hook Form（RHF）は、非制御コンポーネントを活用して再レンダリングを最小限に抑えるライブラリだ。これにスキーマバリデーションライブラリであるZodを組み合わせることで、型安全で直感的なフォーム実装が可能になる。
Zodによるバリデーションスキーマの定義
コンポーネント駆動開発では、まずZodでデータの形状（Shape）を定義する。単純な必須チェックだけでなく、特定の条件に基づいた相関バリデーションも記述できる。
import { z } from "zod";
export const formSchema = z.object({
firstName: z.string().min(1, "必須項目です"),
email: z.string().email("無効なメール形式です"),
price: z.number().min(0),
quantity: z.number().min(1),
taxRate: z.number(),
hasAccount: z.enum(["Yes", "No"]),
username: z.string().optional(),
password: z.string().optional(),
satisfaction: z.number().min(1).max(5),
positiveFeedback: z.string().optional(),
improvementFeedback: z.string().optional(),
}).superRefine((data, ctx) => {
if (data.hasAccount === "Yes") {
if (!data.username) {
ctx.addIssue({ code: "custom", path: ["username"], message: "必須項目です" });
}
if (!data.password || data.password.length < 6) {
ctx.addIssue({ code: "custom", path: ["password"], message: "6文字以上必要です" });
}
}
});
export type FormData = z.infer<typeof formSchema>;このコードでは、`superRefine` を使用して「アカウントあり（Yes）」の場合にのみユーザー名とパスワードを必須にするロジックを実装している。Zodのスキーマはデータの構造を定義するものであり、どのフィールドがどのタイミングで表示されるかといった「表示ロジック」までは関与しない。
RHFによるフォームの実装と課題
RHFを用いた実装では、フォームの表示状態やステップの管理をReactの `useState` や `useWatch` で行う。
const { register, control, handleSubmit } = useForm<FormData>({
resolver: zodResolver(formSchema),
});
const hasAccount = useWatch({ control, name: "hasAccount" });
const price = useWatch({ control, name: "price" });
const quantity = useWatch({ control, name: "quantity" });
const subtotal = useMemo(() => (price ?? 0) * (quantity ?? 1), [price, quantity]);この手法の利点は、Reactの標準的な作法に従っているため、学習コストが低く自由度が高い点にある。一方で、条件分岐が増えるにつれてJSX内にインラインの条件式が散在し、ビジネスロジックがUIコードと密結合になるという課題がある。
スキーマ駆動アプローチ：SurveyJSによるデータ中心の実装
スキーマ駆動アプローチでは、フォームをコンポーネントの集合体ではなく、一つの「データ（JSONスキーマ）」として扱う。SurveyJSはこの手法を代表するライブラリであり、フォームの構造、バリデーション、表示ロジック、計算式をすべてJSON内に集約できる。
JSONスキーマによるロジックの集約
SurveyJSでは、JavaScriptのコードではなく、宣言的なJSONオブジェクトでフォームを定義する。
const surveySchema = {
pages: [
{
name: "order",
elements: [
{ type: "text", name: "price", inputType: "number" },
{ type: "text", name: "quantity", inputType: "number" },
{
type: "expression",
name: "subtotal",
expression: "{price} * {quantity}"
}
]
},
{
name: "account",
elements: [
{ type: "radiogroup", name: "hasAccount", choices: ["Yes", "No"] },
{
type: "text",
name: "username",
visibleIf: "{hasAccount} = 'Yes'",
isRequired: true
}
]
}
]
};ここで注目すべきは `visibleIf` や `expression` というプロパティだ。これらはSurveyJSのランタイムエンジンによって評価され、Reactのステート管理を介さずに動的な表示切り替えや計算結果の表示を可能にする。
Reactコンポーネントの役割の変化
SurveyJSを採用すると、Reactコンポーネントの役割は「スキーマを読み込んで描画するだけ」という極めてシンプルなものになる。
import { Model } from "survey-core";
import { Survey } from "survey-react-ui";
export function SurveyForm() {
const [model] = useState(() => new Model(surveySchema));
model.onComplete.add((sender) => {
console.log(sender.data); // 送信データ
});
return <Survey model={model} />;
}ビジネスロジックがReactから切り離されるため、エンジニア以外の担当者がJSONを書き換えるだけでフォームの挙動を調整できる。これは、要件変更が頻繁に発生するエンタープライズ向けのシステムにおいて、運用上の大きなメリットとなる。
技術的なトレードオフと選択基準
どちらのアプローチが優れているかは、プロジェクトの性質に依存する。ここでは、開発効率と保守性の観点から両者を比較する。
コンポーネント駆動（RHF+Zod）が適しているケース
RHF+Zodのスタックは、フォームが単純なCRUD（作成・読み取り・更新・削除）操作に限定されている場合に最適だ。
- UIの微調整や独自のアニメーションを多用する場合
- フォームのステップ数が少なく、条件分岐が単純な場合
- エンジニアがすべての挙動をコードで管理し、外部からロジックを注入する必要がない場合
このアプローチでは、TypeScriptの恩恵を最大限に受けられる。型定義が明確であるため、大規模なリファクタリングにも強いという特性がある。
スキーマ駆動（SurveyJS）が適しているケース
一方で、SurveyJSのようなスキーマ駆動が威力を発揮するのは、フォーム自体が「ビジネスルール」を体現している場合だ。
- 法規制や業務フローの変化により、入力項目や条件が頻繁に変わる場合
- 10ステップを超えるような長大な多ステップフォームを構築する場合
- フォームの定義をデータベースに保存し、複数のプラットフォーム（Web、モバイルなど）で共有する場合
スキーマ駆動は、ロジックの「可視化」に優れている。JSONを見ればどの項目がどの条件で表示されるかが一目瞭然であり、コードを追う必要がない。
実務における運用上のメリットと分析
Web制作会社の視点では、保守コストの削減が最も重要な関心事となる。コンポーネント駆動で構築された複雑なフォームは、半年後の仕様変更時に「どの `useWatch` がどこに影響しているか」を解読する作業から始めなければならない。
スキーマ駆動を採用した場合、ロジックが中央集権的に管理されているため、修正箇所が限定される。また、SurveyJSにはGUIのビジュアルエディタも存在するため、非エンジニアであるディレクターやクライアントが直接フォームを編集し、エンジニアは生成されたJSONを組み込むだけという分業体制も構築可能だ。
ただし、SurveyJSのような重量級のライブラリは、バンドルサイズが増大する傾向にある。パフォーマンスが最優先されるBtoCのランディングページなどでは、RHFを用いた軽量な実装が選好されるだろう。
この記事のポイント
- RHF+Zodは、UIの自由度が高く、小〜中規模のCRUDフォームに最適である。
- SurveyJSは、ビジネスロジックをJSONに集約し、複雑な条件分岐を持つフォームの保守性を高める。
- 「フォームを消したときに失われるものがUIならRHF、ロジックならSurveyJS」という判断基準が有効だ。
- 運用フェーズでの要件変更の頻度を予測し、適切な抽象化レベルを選択することが重要である。
出典
- Smashing Magazine “Building Dynamic Forms In React And Next.js”（2026年3月10日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験