GitBookが3万サイトのサブ秒コンテンツ更新をVercelで実現
GitBook は Vercel のキャッシュ無効化機能を活用し、30,000 サイト規模でサブ秒更新を実現すると同時に、AI クローラーによるトラフィックが全体の 41% に達したインフラの再構築を成功させた。
キーポイント
マルチテナント環境での精密なキャッシュ無効化
全サイトの広域クリアではなく、タグベースの無効化により、特定のサイトの変更が他社への影響を与えずに 300ms 以内で反映される仕組みを構築した。
AI クローラーによるトラフィック構造の変化
2025 年時点で AI 駆動のトラフィックが 5 倍増加し、全ページビューの 41% を占めるようになり、ドキュメントが LLM の学習ソースとして不可欠な役割を果たしている。
開発者体験とインフラの統合
Next.js と Vercel のキャッシュディレクティブをコード内で直接制御可能にし、従来の外部設定に依存しない高速で信頼性の高い配信モデルを実現した。
AI クローラーによるキャッシュ負荷の増加
AI クローラーは人間とは異なり、一度に多数のサイトやページをスキャンするため、予測不能なトラフィックと冷たいキャッシュパスへのアクセスが急増している。
100% キャッシュヒット率の追求
GitBook は AI 対応に限らず、すべてのユーザーに対して高速なドキュメント提供を目標としており、キャッシュヒット率をほぼ 100% に近づけるアーキテクチャを採用している。
スケーリングにおける一貫性とコスト管理
30,000 サイト規模での拡張に伴い、変更後の即時一貫性を保ちつつ、トラフィック増加でもインフラコストを予測可能に維持することが主要な課題となっている。
影響分析・編集コメントを表示
影響分析
この事例は、大規模なマルチテナントシステムにおいて、従来の広域キャッシュ無効化に代わる「タグベースの精密制御」が実用レベルで可能であることを示す重要な指標です。また、AI クローラーがドキュメント消費の主要層となった現在、インフラ設計において「人間向け」と「機械読み取り向け」の両方を考慮する必要性を浮き彫りにしています。
編集コメント
ドキュメント管理システムが単なる情報アーカイブから、AI エージェントの学習基盤へと役割を変化させた象徴的な事例です。エンジニアリングチームは、ドキュメントの鮮度と可用性をプロダクトコードと同列に扱うインフラ設計が不可欠となっています。
GitBook on Vercel
単一のVercelデプロイメントでホストされる30,000のドキュメントサイト
エッジから配信される月間1億2,000万ページビュー
1日40,000回処理されるキャッシュ無効化、各々300ミリ秒未満で解決
全トラフィックの41%がAIクローラーと自動化システム由来
GitBookはVercel上で30,000のドキュメントサイトをホストし、毎月1億2,000万ページビューを配信しています。n8n、Nvidia、Zoomなどの企業が、自社のドキュメントを高速かつ最新の状態に保つためにこのプラットフォームを信頼しています。現代のエンジニアリングチームやコーディングエージェントにとって、ドキュメントはそれが記述する本番コードと同様に重要であり、GitBookはその期待の中心に位置しています。
GitBookの公開モデルは、チームがソフトウェアをリリースする手法を反映しています。変更を提案し、レビューし、マージするのです。それぞれ独自の更新頻度で管理される30,000のサイトにおいて、コンテンツを高速かつ最新に保つことは複雑な技術的課題でした。Vercelへ移行する前は、サイト編集者がマージを実行し、公開サイトを訪れて確認しても、古いバージョンのコンテンツが表示されることがありました。「ある顧客が大規模な機能リリースを計画した際、ローンチ当日にドキュメントが製品本体に遅れをとったことがありました」と、GitBookのエンジニアリング責任者であるSteven Hallは述べています。「その瞬間、私たちはドキュメントが本番環境にデプロイされるコードと同じくらい重要であることを本当に理解しました。」
マルチテナント規模で「マージ即公開」を実現する
GitBookの公開コンテンツフロントエンドはNext.jsで動作し、オープンソースです。Vercelのuse cacheディレクティブが利用可能になった時、チームは速度課題の解決策を見出しました。それは、ページ全体のレスポンスではなく、個々のデータ取得関数をキャッシュするという方法です。これにより、負荷の高いAPI呼び出しがリクエスト間で重複排除され、キャッシュの挙動が外部設定に埋もれるのではなく、コード内で直接確認できるようになりました。
より困難な課題は無効化でした。マルチテナントシステムでは、広範囲なキャッシュパージはコストが高く、無駄も生じます。あるチームが誤字修正をマージしたからといって、他の29,999サイトの再検証をトリガーすべきではありません。GitBookは既に、コンテンツが陳腐化したタイミングを知る信頼できるシグナルを持っていました。それは、GitBookアプリ、GitHub、またはGitLabを介したマージイベントです。チームはこれらのイベントによって直接トリガーされるタグベースの無効化を構築しました。キャッシュされたデータはコンテンツ単位でタグ付けされ、マージが発生した場合、影響を受けるタグのみが再検証されます。それ以外は全てキャッシュされたまま維持されます。
現在では、変更がマージされると、更新されたコンテンツは300ミリ秒以内にグローバルに表示されるようになります。GitBookは毎日40,000回のこのような無効化を処理しています。「独自のキャッシュシステムを構築すること以外、他の選択肢は考えていなかったと思います」とHallは語ります。
トラフィックの41%が人間以外の場合、何が変わるのか
GitBookドキュメントへのAI駆動トラフィックは2025年に前年比5倍に急増し、現在では全ページビューの41%を占めています。LLMや自動化システムは、内部ツール、SDK、AIアプリケーションの信頼できる情報源としてGitBookを利用し、プログラム的にドキュメントをクロールします。
これはインフラの計算式を変えます。人間の読者は単一のドキュメントサイト内の数ページを訪問するかもしれませんが、AIクローラーは単一セッションで数百サイトにわたる全ページを走査し、通常の人間の読者が訪れないコールドキャッシュパスにアクセスすることがあります。これを30,000サイトに拡大すると、キャッシュ基盤は単にトラフィック量の増加だけでなく、根本的に予測が難しいトラフィックパターンにも対応しなければなりません。コンテンツはあらゆる変更後も即座に一貫性を保つ必要があり、トラフィック量が増加してもインフラコストは予測可能な範囲に収める必要があります。
Hallによれば、彼らが特にAIを理由にこのキャッシュアーキテクチャを選んだわけではないが、結果的にそれが正しい基盤となったとのことです。「読むのがAIであれ人間であれ、高速なドキュメントが必要です」と彼は言います。「私たちの目標はキャッシュヒット率を100%に近づけることです。キャッシュヒットは高速なドキュメントを意味し、高速なドキュメントはGitBookの重要な機能です。」
次の30,000サイトへ
キャッシュインフラの開発は終わっていません。閲覧者に応じてコンテンツを変更するアダプティブドキュメンテーションのような機能は、マルチテナントキャッシングを著しく複雑にします。また、AIトラフィックが増加し続けるにつれ、30,000サイトを流れるリクエスト量はさらに増大するでしょう。
「トラフィック量はあらゆる場所で増加しています」とHallは述べます。「エンジニアのリリースが増えることは、ドキュメントの変更も増えることを意味します。LLMは日々より多くのページをクロールしています。私たちの主な目標は、規模が拡大する中でも、レイテンシと予測可能性に関する高い水準を維持することです。」
GitBookは、30,000以上のチームによって製品および開発者向けドキュメントを大規模に作成、公開、維持するために利用されているAIネイティブのドキュメントプラットフォームです。GitBookの公開コンテンツフロントエンドはオープンソースです。
Read more
原文を表示
GitBook on Vercel
30,000 documentation sites hosted on a single Vercel deployment
120 million monthly page views served from the edge
40,000 cache invalidations processed daily, each resolved in under 300ms
41% of all traffic now comes from AI crawlers and automated systems
GitBook hosts 30,000 documentation sites on Vercel, serving 120 million page views every month. Companies like n8n, Nvidia, and Zoom trust the platform to keep their docs fast and current. For modern engineering teams and coding agents, documentation is as critical as the production code it describes, and GitBook sits at the center of that expectation.
GitBook's publishing model mirrors how teams ship software: propose changes, review, and merge. With 30,000 independently managed sites each on its own update cadence, keeping content fast and fresh was a complicated engineering problem. Before migrating to Vercel, site editors would hit merge, visit the published site to validate, and see old version of the content. "One of our customers planned a large feature release, and on launch day, the docs lagged behind the rest of the product," says Steven Hall, Head of Engineering at GitBook. "That was the moment we really internalized that docs are as important as your code going to production."
Making merge mean live at multi-tenant scale
GitBook's published content frontend runs on Next.js and is open source. When Vercel's use cache directive became available, the team saw a solution to their speed problem: cache individual data-fetching functions rather than full page responses. That meant expensive API calls were deduplicated across requests, and cache behavior became visible directly in code rather than buried in external configuration.
The harder problem was invalidation. In a multi-tenant system, a broad cache purge is expensive and wasteful. One team merging a typo fix shouldn't trigger revalidation for 29,999 other sites. GitBook already had a reliable signal for when content becomes stale: a merge event, whether through GitBook's app, GitHub, or GitLab. The team built tag-based invalidation triggered directly by those events. Cached data is tagged by content unit, and when a merge occurs, only the affected tags are revalidated. Everything else stays cached.
Today, when a change is merged, updated content becomes visible globally within 300 milliseconds. GitBook processes 40,000 of these invalidations daily. "Outside of building our own caching, I don't think we considered anything else," says Hall.
What changes when 41% of your traffic isn't human
AI-driven traffic to GitBook documentation surged 5x year-over-year in 2025 and now accounts for 41% of all page views. LLMs and automated systems crawl docs programmatically, using GitBook as a source of truth for internal tooling, SDKs, and AI applications.
That changes the infrastructure math. A human reader might visit a handful of pages on a single docs site, but an AI crawler can sweep every page across hundreds of sites in a single session, hitting cold cache paths that no human would visit. Multiply that across 30,000 sites and the caching foundation has to handle not just more traffic, but fundamentally less predictable traffic. Content still has to be immediately consistent after every change, and infrastructure costs have to stay predictable even as volume climbs.
Hall says they didn't choose the caching architecture because of AI specifically, but it turned out to be the right foundation. "We need fast docs regardless of whether AI or humans are reading them," he says. "Our target is closer to 100% cache hits. Cache hits mean fast docs, and fast docs are a critical feature of GitBook."
The next 30,000 sites
The caching infrastructure isn't finished. Features like adaptive documentation, which modifies content based on who's reading it, make multi-tenant caching meaningfully more complex. And as AI traffic keeps climbing, the volume of requests flowing through 30,000 sites will only grow.
"Volume is going up everywhere," Hall says. "Engineers shipping more means more docs changes. LLMs are crawling more pages every day. Our main goal is to maintain that high bar for latency and predictability as we scale."
GitBook is an AI-native documentation platform used by more than 30,000 teams to create, publish, and maintain product and developer documentation at scale. GitBook's published content frontend is open-source.
Read more
関連記事
DeepStreamコーディングエージェントを使用したビジョンAIパイプライン構築方法
NVIDIAが、DeepStreamコーディングエージェントを使用してリアルタイムビジョンAIアプリケーションの開発を効率化する方法を紹介した。複雑なデータパイプラインや大量のコードを必要とする課題を解決する技術を提案している。
NVIDIA、チップソフトウェアメーカーと提携しシミュレーションと現実のギャップを縮める
NVIDIAはCadenceとの提携を拡大し、ロボットトレーニングデータの精度向上とエンジニア向けAIサービスの構築を目指す。
NVIDIA、ロボットシミュレーション訓練を拡張するLyra 2.0を発表
NVIDIAの研究者が、単一写真から大規模で一貫性のある3D環境を生成するシステム「Lyra 2.0」を発表した。生成されたシーンはリアルタイムで探索可能で、ロボットシミュレーションに直接使用できる。