これからのWeb — バイブコーダーが知っておくべき4つの未来

バイブコーディング入門 — 第23回（最終回）

全23回の旅、ここまでお疲れさまでした

第1回で「Webは手紙のやりとり」という話から始めて、URI、HTTPメソッド、ステータスコード、Cookie、CORS、REST API、JSON、認証、HTTPS、データベース、デプロイ、パフォーマンス、SPA・SSR、WebSocketと、Web開発の基礎を一通り見てきた。

ここまで読み切ってくれた方は、もう「AIが何の話をしているか」がだいたい分かるはずだ。AIが「JWTで認証して、CORSの設定を変えて、SSRでレンダリングしてください」と言ってきたとき、「ふむふむ、トークンで本人確認して、別ドメインからのアクセスを許可して、サーバー側でHTML生成するのね」と頭の中で翻訳できる状態になっている。

この状態が、バイブコーディングの土台だ。AIに任せきりにせず、AIと対等に会話できる土台ができた。

最終回となる今回は、少し未来の話をする。これから1〜3年であなたのバイブコーディング体験に影響を与えそうな、4つの技術トレンドを取り上げる。

  • HTTP/3（エイチティーティーピー・スリー） — 通信がもっと速くなる
  • GraphQL（グラフキューエル） — REST APIの次の選択肢
  • Edge Computing（エッジ・コンピューティング） — 計算する場所が変わる
  • AIとWebの融合 — AIエージェントが直接Webを操る時代

どれも「今すぐ使う必要がある」技術ではない。ただし、AIが「HTTP/3で接続します」「GraphQLで取得します」「Edge関数にデプロイします」と言い始めたとき、何の話をしているか分かれば、適切な判断ができる。今回は、そのための地図を提供する。

この記事を読み終えると、次のことが分かるようになる。

  • HTTP/3が従来のHTTPと何が違うか、いつ役に立つか
  • GraphQLの基本と、REST APIとどう使い分けるか
  • Edge Computingが「速さ」と「コスト」をどう変えるか
  • AIが直接Webサービスを呼び出す未来（Tool Use・MCP）の現状
  • 新技術が出てきたときに焦らないための判断軸

それでは、最後の旅に出発しよう。

トレンド1: HTTP/3 — 通信プロトコルの新世代

HTTPは今、第3世代に入っている

第1回で「HTTPは手紙のやりとり」と説明した。実はそのHTTPには、何度かバージョンアップがある。

  • HTTP/1.1: 1997年から長く使われていた標準。1本ずつ手紙を送る方式
  • HTTP/2: 2015年に登場。1本の回線で複数の手紙を同時にやりとりできるように改善
  • HTTP/3: 2022年に正式仕様化。通信の土台そのものを刷新した最新版

2026年現在、HTTP/3はGoogle、YouTube、Cloudflareなど大手サービスで実用化されている。あなたが普段使っているWebサービスの多くは、すでにHTTP/3で配信されていることがある。

HTTP/3の核心 — TCPからQUICへ

HTTP/3の最大の特徴は、その下で動く「土台」を変えたことだ。

たとえで説明しよう。HTTP/1.1とHTTP/2は「TCP（ティーシーピー）」という土台の上で動いていた。TCPは、手紙が確実に相手に届くことを保証する仕組みだ。郵便でいえば「書留郵便」のようなもの。届くことは確実だが、確認の手続きに時間がかかる。

HTTP/3は「QUIC（クイック）」という新しい土台の上で動く。QUICは、UDPという別の通信方式の上に独自の確実性を載せた仕組みだ。書留の確実さを保ちつつ、手続きを大幅に省略した。結果として、特に通信が不安定な環境（モバイル回線、新幹線の中、海外との通信など）で速度が大きく改善する。

バイブコーダーにとっての意味

「専門用語が並んだけど、私の仕事に関係あるの？」と思うかもしれない。3つの場面で関係してくる。

場面1: モバイル対応のサービスを作るとき。スマホで使うアプリを作る場合、ユーザーは電車の中、地下鉄、エレベーターなど、電波が弱い場所でも使う。HTTP/3対応のホスティング（Vercel、Cloudflare Pages、Netlifyなど主要サービスは対応済み）を選んでおけば、ユーザー体験が一段良くなる。

場面2: 海外拠点とのやりとり。海外のスタッフや顧客が使うサービスでは、地理的な距離による遅延が発生する。HTTP/3はこの遅延の影響を小さくする。

場面3: ライブストリーミングや動画配信。途切れのない配信が求められる用途では、HTTP/3の恩恵が大きい。

バイブコーディングでは、AIに「HTTP/3対応にしてほしい」と明示的に頼む必要はあまりない。多くの場合、Vercelなどのデプロイ先が自動的に対応している。ただし、AIが「HTTP/3で配信されます」と説明してきたら、「ああ、最新の通信方式ね、特にモバイルで効くやつ」と理解できれば十分だ。

あなたが今すぐすべきこと

何もしなくていい。Vercel、Cloudflare、Netlifyなどモダンなホスティングを使っていれば、自動でHTTP/3に対応する。ただし、もしまだ古いレンタルサーバーを使っているなら、移行を検討する材料になる。

トレンド2: GraphQL — REST APIの「次の選択肢」

GraphQLとは何か

第13回でREST APIを学んだ。資源（リソース）ごとにURLを用意して、GETやPOSTでやりとりする方式だった。GraphQLは、その「次の選択肢」として注目されている技術だ。

GraphQL（グラフキューエル）は、Facebook（現Meta）が2015年に公開したAPI技術だ。一言で言うと「ブラウザ側が、欲しいデータの形を指定して取りに行ける」仕組みだ。

REST APIとの違いを、注文のたとえで

中華料理店を想像してほしい。

REST APIは、メニューに載った定食を注文する方式だ。「Aセットください」と言うと、決まった料理が決まった量で出てくる。料理の組み合わせや量を細かく指定することはできない。Aセットは野菜炒めとごはんとスープが付いてくる。野菜炒めだけ欲しくても、Aセットを頼めばごはんとスープも一緒に出てくる。

GraphQLは、その日の気分で「野菜炒めを大盛りで、ごはんは小盛り、スープは要らない、デザートに杏仁豆腐を1つ」と細かく注文できる方式だ。欲しいものを、欲しい量だけ、無駄なく注文できる。

この違いが、ブラウザとサーバーのやりとりで効いてくる場面がある。

REST APIの「過剰取得」と「不足取得」問題

REST APIでは、しばしば「過剰取得」「不足取得」という問題が起きる。

過剰取得（オーバーフェッチ）とは、必要のないデータまで一緒に返ってくることだ。例えば、商品名と価格だけ表示したい画面で、商品APIを叩くと商品の説明文・在庫数・カテゴリ・関連商品リスト・画像URL一覧などの情報まで全部返ってくる。表示には使わないデータが転送されるので、通信量が無駄に大きくなる。

不足取得（アンダーフェッチ）とは、1回のAPI呼び出しでは情報が足りず、何度も呼び出す必要がある状態だ。例えば、ある記事の情報を取得した後、その記事の著者情報を取るために別のAPIを叩く必要がある。著者の所属組織を取るためにさらに別のAPIを叩く。1画面表示するために5回も6回も通信が発生する。

GraphQLは、この両方を解決する。「私が欲しいのは、記事のタイトルと、著者の名前と、著者の所属組織名だけです。1回のリクエストで全部ください」と書ける。サーバーは指定された分だけ、1回のレスポンスで返す。無駄がない。

バイブコーダーにとっての判断基準

GraphQLは万能ではない。次のようなケースで検討する価値がある。

  • モバイルアプリのバックエンドを作りたい（通信量が課題になる）
  • 画面ごとに必要なデータが大きく違う
  • 1画面あたり複数の情報を組み合わせて表示する複雑なダッシュボード
  • 開発が進んでフロント側のニーズが頻繁に変わる

逆に、次のケースではREST APIで十分だ。

  • 小〜中規模のシンプルなアプリ
  • 表示するデータの形がほぼ固定
  • 開発チームが小さく、シンプルさを優先したい

バイブコーディングで小規模なツールを作るなら、まずはREST API（あるいはSupabaseの自動生成API）で十分なケースが多い。GraphQLが必要になるのは、アプリが成長して画面が複雑になり、APIの呼び出し回数や通信量が課題になってからだ。

AIへの伝え方

「シンプルなツールだから、最初はREST APIで作ってほしい。将来、画面が複雑になってデータの過剰取得が問題になったら、GraphQL移行を相談する」と伝えれば、AIは適切なシンプルさで作ってくれる。

逆に、AIが「GraphQLで実装します」と言ってきたら、「うちのアプリの規模で、本当にGraphQLが必要？ REST APIでは過剰取得が問題になる規模？」と聞き返してみよう。明確な理由がなければ、シンプルなREST APIに変更してもらえばよい。

トレンド3: Edge Computing — 「計算する場所」を変える

従来のWebの仕組み

第18回でデータベースを学んだとき、「サーバー」という言葉を使った。あなたのアプリの本体は、世界のどこか1箇所にあるサーバー（コンピュータ）で動いている。たとえば、東京リージョンのデータセンターに置かれたサーバーで動いている、というイメージだ。

ここでひとつ問題が出てくる。あなたのアプリを使うのが、東京の人だけならいい。でも大阪の人、福岡の人、海外の人が使うとどうなるか。

通信は光の速度で進むとはいえ、距離が長いほど時間がかかる。東京のサーバーに、福岡からアクセスすると、データが行って戻るのに少し時間がかかる。アメリカからアクセスすれば、もっと時間がかかる。何度もやりとりが必要なアプリでは、この遅延が積み重なって体感速度を落とす。

Edge Computingの考え方

Edge Computing（エッジ・コンピューティング）は、この問題を「ユーザーの近くで計算する」というアプローチで解決する。

たとえで説明しよう。スーパーマーケットを思い浮かべてほしい。本社が東京にあって、全国に支店がある。お客さんが「お惣菜の在庫を聞きたい」と思ったとき、本社まで電話するのではなく、最寄りの支店に聞く方が速い。

Edge Computingも同じ発想だ。世界中に「支店」（エッジサーバー）を配置しておき、ユーザーは最寄りの支店にアクセスする。本社（中央のサーバー）まで毎回行かない。

Vercel、Cloudflare、Netlifyなどのサービスは、世界中に何百ものエッジサーバーを持っている。あなたがVercelにデプロイすると、東京のユーザーには東京近郊のエッジから、ロンドンのユーザーにはロンドン近郊のエッジから配信される。

静的ファイル配信からエッジ関数へ

以前から「CDN（シーディーエヌ）」という似た仕組みがあった。第20回のパフォーマンスでも触れた。CDNは画像やCSSなど、変わらないファイルを世界中のサーバーにコピーしておく仕組みだ。

Edge Computingは、これを一歩進めて「処理（プログラム）も世界中のサーバーで動かす」段階に入った。「エッジ関数（Edge Function）」と呼ばれる仕組みで、APIのような動的処理もユーザーの近くで実行できる。

例として: あなたが顧客向けアンケートツールを作ったとする。回答を保存するAPIを作った。このAPIをVercelの「Edge Function」としてデプロイすると、東京のユーザーが回答を送信したとき、東京近郊のエッジサーバーで処理される。中央サーバーまで行かないので、処理が速い。

バイブコーダーにとっての意味

3つの場面で意味がある。

場面1: グローバル展開を考えているサービス。海外ユーザーが使う前提のサービスを作るなら、最初からEdge Computing対応のホスティングを選ぼう。

場面2: 速度がビジネスに直結するサービス。決済、商品検索、SNSの投稿など、コンマ数秒の遅延が体験を左右するサービスでは効く。

場面3: コスト削減。意外に思うかもしれないが、エッジ関数は使った分だけの課金になることが多く、固定でサーバーを借りるよりコストが低くなる場合がある。月間アクセスが少ないサービスにとっては、料金面のメリットが大きい。

注意点 — エッジ関数で動かないこと

エッジ関数には制約もある。データベース接続が必要な処理、長時間かかる処理、特定のファイルシステム操作などは、エッジでは動かないことがある。

バイブコーディングでAIに依頼するときは「軽い処理はEdge Functionで、データベースを多用する処理は通常のサーバーレス関数で動かしてほしい」と伝えると、適切に分けてくれる。

また、Supabaseのようなデータベースサービスも、世界中にレプリカ（コピー）を配置する機能を持ち始めている。エッジで動くアプリと組み合わせると、グローバルに高速なサービスが作れる。

トレンド4: AIとWebの融合 — AIが直接Webサービスを操る時代

今のAIとWebの関係

2026年4月時点で、AIとWebの関係は急速に変わりつつある。

これまで、AIは「文章を書く」「コードを書く」「画像を作る」など、人間が指示したものを生成する役割が中心だった。あなたがバイブコーディングでAIを使うときも「こういうアプリを作って」と頼んで、コードを書いてもらう関係だった。

次の段階では、AI自身が直接Webサービスを呼び出して、業務を進める時代に入りつつある。具体的には次のような動きだ。

  • AIがGoogleカレンダーに直接予定を登録する
  • AIがSlackに直接メッセージを送る
  • AIがNotionに議事録を直接書き込む
  • AIが請求書システムから請求書を発行する

AIが人間を介さずに、Webサービスのボタンを「押す」ような操作をする。これを支える技術が「Tool Use（ツール使用）」と「MCP（エムシーピー）」だ。

Tool Useの仕組み

Tool Useとは、AIが「外部のツール（API）を呼び出せる」仕組みだ。たとえば、Claude APIに対して「あなたはGoogleカレンダーAPIを使えます」と教えておくと、Claudeはユーザーの依頼を受けたとき、自分でカレンダーAPIを呼び出して予定を作成できる。

第8回で学んだHTTPメソッドや、第13回で学んだREST APIの知識は、ここでまた効いてくる。AIが内部でやっているのは、結局のところHTTPリクエストを送ってJSONを受け取るという、これまで学んできた基本動作だ。

MCPとは何か

MCP（Model Context Protocol、モデル・コンテキスト・プロトコル）は、Anthropicが提唱している規格だ。一言で言えば「AIに外部のツールやデータをつなぐ標準ルール」だ。

例えるなら、家電のコンセントの形の話だ。日本の家電は日本のコンセントに、海外の家電は海外のコンセントに、それぞれ形が違う。MCPは「AIと外部サービスをつなぐ統一規格」を作ろうという試みだ。

MCPに対応したサービス（GitHub、Slack、Notion、Google Driveなど）が増えると、Claudeに「Googleドライブの最新ファイルを見せて」と頼むだけで、Claudeが自動でドライブを参照する、といった連携がスムーズになる。

バイブコーダーにとっての意味

この変化が、バイブコーディングにどう関係するか。3つの観点から考えよう。

観点1: 作るアプリの幅が広がる。これまでは「人間が触るUI」を作るのが中心だった。これからは「AIが裏で操作するAPI」も意識する必要が出てくる。あなたが社内ツールを作るとき、人間が画面で操作するUIだけでなく、AIが自動で呼び出せるAPIも併せて用意する設計が増えてくる。

観点2: AIに既存サービスをつなぐ仕事が増える。「うちの会社のSlackと、顧客管理システムと、Googleカレンダーを、AIから一括で操作できるようにしたい」という相談は今後増える。MCPサーバーを構築するスキル（といっても、AIに頼んで作る範囲）が役に立つ。

観点3: セキュリティの考え方が変わる。AIが自動で操作する以上、間違った操作をしないための制限、操作ログの記録、誰の許可で動いたかの記録、といった「ガードレール」の設計が重要になる。第17回で学んだ認証・認可の知識が、ここでも基礎として効く。

今すぐ意識すべきこと

まだ全社規模でAI連携を導入する段階の会社は少ない。多くの中小企業にとって、向こう1年くらいは「個人やチームでClaude Coworkを使いこなす」段階で十分だ。

ただし、これからアプリを作るときは「将来AIから呼ばれる可能性」を意識しておくと無駄がない。具体的には、AIに「データの取得や登録は、なるべくAPIとして外から呼べる形にしておいて」と伝えておくとよい。後でMCP連携を追加するときが楽になる。

4つのトレンドを、あなたの仕事に翻訳する

ここまで4つのトレンドを見てきた。最後に、あなたが「いつ・なぜ気にすべきか」を整理する。

トレンド 今すぐ気にする必要 気にすべき場面 AIへの伝え方の例
HTTP/3 ほぼなし モバイル中心・海外ユーザー多数のサービス 「Vercelなど、HTTP/3対応のホスティングを使ってほしい」
GraphQL なし 画面が複雑・データ取得が多重化したとき 「最初はREST APIで。GraphQLは規模が大きくなってから検討」
Edge Computing 場合による グローバル展開・速度重視・コスト削減したいとき 「軽い処理はEdge Functionで、DBが必要な処理は通常関数で」
AI×Web 設計段階で意識 AI連携を将来やりたいとき 「データ操作は外部APIから呼べる形にしておいて」

どれも「今すぐ全部やる必要はない」が、AIが提案してきたときに判断できる土台を持っておくことが大事だ。

新しい技術が出てきたとき、焦らないための3つの判断軸

最後に、もう少し抽象的な話をしたい。Webの世界は、これからも新しい技術が次々に登場する。半年ごとに新しい用語が出てくると言ってもいい。バイブコーダーとして、その都度焦らないために、3つの判断軸を持っておこう。

判断軸1: その技術は、何の問題を解決しているか

新しい技術は、必ず「既存の何かを解決するため」に生まれる。HTTP/3はTCPの遅さを、GraphQLはRESTの過剰取得を、Edge Computingは距離による遅延を、それぞれ解決するために生まれた。

AIから新しい技術名が出てきたら、最初の質問はこれだ。「この技術は、何の問題を解決するために生まれたの？ うちのアプリで、その問題は今困っている？」

問題が困っていなければ、新技術を急いで使う必要はない。

判断軸2: 採用のコストとリターンは見合うか

新技術には、必ず学習コスト・移行コスト・運用コストがついてくる。8人の事務所で、運用が複雑になる新技術を入れて、社員1人を新技術の習得に当てる余裕があるかどうか。

バイブコーダーは「シンプルさ」を最優先にしてよい。新しいから、流行っているから、という理由で採用するとあとで運用に苦しむ。

判断軸3: 1〜2年後も生き残りそうな技術か

Webの世界では、流行ってもすぐに消える技術もある。一方で、数年〜10年単位で標準として使われ続ける技術もある。

見分けるポイントは「大手企業や標準化団体が支持しているか」「既存の大規模サービスが採用しているか」「学習資料が増え続けているか」あたりだ。HTTP/3はGoogleが推進、GraphQLはMeta発でNetflixやGitHubも採用、Edge Computingは主要ホスティングが対応済み、MCPはAnthropicが提唱中。どれも「明日消える」可能性は低い。

よくある不安と答え

Q1. 全部覚えないとバイブコーディングできないのか

A. いいえ。今回紹介した4つは「今後出てきたとき判断できるための地図」だ。今すぐ全部使う必要はない。むしろ、必要になってから「あの記事で見た話だ」と思い出して、改めて深く調べるくらいでちょうどいい。

Q2. AIが新しい技術を自動で選んでくれるなら、人間は何を判断すればよいか

A. 「うちのアプリで本当に必要か」「運用していけるか」の判断だ。AIは技術的に最先端のものを提案する傾向がある。しかし、運用するのは人間だ。シンプルなアプリには、シンプルな技術が合う。AIの提案を鵜呑みにせず、規模・予算・人手と相談しながら選ぶ判断は、人間が担う。

Q3. HTTP/3対応のホスティングを使えば、自動で速くなるのか

A. ほぼ自動で速くなる。VercelやCloudflareにデプロイすれば、特別な設定なしにHTTP/3で配信される。古いブラウザを使うユーザーには自動でHTTP/2にフォールバックする仕組みもあるので、互換性の心配もほぼない。

Q4. MCPを今すぐ業務に使う方法はあるか

A. Claudeデスクトップアプリでは、すでにMCPサーバーを設定して、Slackや GitHub、Google Driveなどと連携できる。社内で試したいなら、まずClaudeデスクトップを1人〜数人で使ってみて、どんな業務がAI連携で楽になるか試すと感覚がつかめる。

Q5. 全23回読み終わったあと、次にすべきことは何か

A. 実際にバイブコーディングで何かを作ってみることだ。社内の業務で「これ、ツールがあれば楽になるな」というものを1つ選び、AIに「こういうアプリを作りたい」と相談してみよう。第1回〜第22回で学んだ知識が、AIとの会話で「ああ、これあのときの話だ」と次々に活きてくる。実装で詰まったら、関連する回を読み返せばよい。

まとめ — 全23回を終えて

全23回のバイブコーディング入門、お疲れさまでした。

ここまで学んだことは、「Webアプリを作るための基礎言語」だ。あなたはもう、AIが何を言っているか理解し、AIと対等に会話できる。技術的な詳細を全部覚えている必要はない。「どこに何が書いてあったか」を覚えておけば、必要なとき第◯回を読み返せばよい。

バイブコーディングは、エンジニアの仕事をAIが奪う話ではない。非エンジニアが「こういうものが欲しい」と考えて、それを形にできる時代を切り開く動きだ。社長が、フリーランスが、経理担当者が、自分の業務を自分で改善できるようになる。これまでエンジニアに頼らないと作れなかったツールを、自分で作れるようになる。

今回紹介した4つのトレンド（HTTP/3、GraphQL、Edge Computing、AI×Web）は、これからのバイブコーディング体験をより豊かにしていく。新しい技術が出てきても、第1回から積み上げた基礎があれば、慌てる必要はない。

さあ、最初の1本を作りに行こう。

特典 — バイブコーディング入門 完走チェックリスト

全23回の要点を、1枚にまとめたチェックリストPDFを用意した。

  • 各回のキーワード一覧（HTTP、URI、CORS、JWT、JSON、SSR、WebSocketなど全用語）
  • AIへの依頼テンプレート集（認証・データベース・デプロイ・リアルタイム機能）
  • 「困ったときに見返す回」早見表
  • バイブコーディングで最初に作る5つのアプリアイデア

バイブコーディングを実際に始めるとき、デスクの横に置いておくとAIとの会話が一段スムーズになる。

ダウンロードはこちら → /download/vibe-coding-completion-checklist

参考リファレンス

  • 前回: 第22回「WebSocketとリアルタイム通信」（/articles/vc-022）
  • 第1回: 「あなたのWebアプリは『手紙のやりとり』で動いている」（/articles/vc-001）
  • 第13回: 「REST API設計の基礎」（/articles/vc-013）
  • 第17回: 「HTTPS・セキュリティの基本」（/articles/vc-017）
  • 第18回: 「データベースの基本」（/articles/vc-018）
  • バイブコーディング入門 全23回カリキュラム（/vibe-coding）
  • Anthropic 公式 Model Context Protocol（modelcontextprotocol.io）