エンジニアじゃない僕が、AIで急に出会ったWeb開発ツールを地図にした｜GitHub・Vercel・Cloudflare・Astro・MCP入門

正直に言うと、これまで私はエンジニアじゃないので、「デプロイ」とか「リポジトリ」とか「CI/CD」みたいな言葉は、完全に"向こう側"の話だと思ってました。

ところが、AIでコードを書いたり、サイトを作ったりするようになってから、状況が変わりました。ClaudeやChatGPTに「これ作って」とお願いすると、返ってくる説明のなかに、当たり前みたいな顔で「GitHubにpushして」「Vercelにデプロイして」「MCPで繋いで」みたいな言葉が出てくる。そのたびに手が止まって、調べて、なんとなくわかった気になって、また忘れる。この繰り返しでした。

なので、いっそ全部いっぺんに整理してしまおう、というのがこの記事です。エンジニアではない人間が、同じくエンジニアではない人に向けて、それぞれのツールが「結局なにをする道具なのか」を、できるだけ噛み砕いて地図にしてみます。

最初にことわっておくと、この記事はあくまで"全体像＝地図"です。正確さより「イメージが掴めること」を優先しています。

まず街全体の地図を広げて、「このお店はこのへんにあるのね」がわかる状態を作る。そのうえで、一軒ずつ中に入って詳しく見ていく深掘り記事を、今後シリーズで書いていく予定です。

なので今回は、「ふーん、こういう役割の道具なのね」くらいの解像度で読んでもらえればOKです。

全体像｜「お店を開く」で考えると、ぜんぶ繋がる

今回出てくるツールたちは、バラバラに存在してるわけじゃなくて、「アイデア → 公開されたサイト」という一本の流れのなかで、それぞれ役割分担しています。お店を作って開店するのに例えると、こんな感じです。

この流れが頭に入ると、「あ、この道具は④の話をしてるのね」と位置づけができるようになります。

その前に、3つだけ予習｜Webサイトの正体

ここ、前の版では飛ばしてしまったんですが、特に①のAstroを理解するうえで、いちばん大事なところでした。

Webサイトの正体は、実は「ファイルの束」です。 スマホでサイトを開いたとき、あなたの手元に届いているのは、主にこの3種類のファイルです。

そして、もう2つだけ。

ここでいちばん覚えておいてほしいのは、どのツールも、結局は「この3種類のファイルを、どう作って、どう届けるか」の話をしているということです。これさえ押さえておけば、この先はかなり読みやすくなるはずです。

① 作る｜Astro（フレームワーク）

とくにブログ、LP、ポートフォリオ、メディアのような「読ませる系」のサイトが得意です。

正直、私がいちばん「結局なんなの？」となったのがAstroでした。なので、ここは少し丁寧にいきます。

▶︎そもそも「フレームワーク」って？

ざっくり言うと、「サイトを作るときの決まりごと＋部品セット」です。家を建てるときに、柱や窓の規格がすでに決まっていて、部品も揃っているような状態。ゼロから全部自分で考えなくても、よく使う仕組みが最初から用意されています。Astroは、そういうフレームワークのひとつです。

▶︎ポイントは「ページをいつ作るか」

さっきの予習で、サイトの正体はHTMLなどのファイルだ、という話をしました。サイトの作り方の違いは、突き詰めると 「そのHTMLを、いつ・誰が作るか」 の違いなんです。

• 手書きのHTML：全ページを自分で作る。10ページあれば、上のメニュー（ヘッダー）を10回書く。直すときも10ページ全部直す

• WordPress：誰かが見に来るたびに、サーバーがその場でページを組み立てて渡す

• Astro：公開する前に、全ページをまとめて組み立てておく。見に来た人には、できあがった完成品を渡すだけ

料理でたとえると、WordPressは「注文を受けてから厨房で作るお店」です。Astroは「開店前に全部作り終えて、並べておくお店」。お客さんが来たら、できているものをすぐ渡せるので、待たせません。これが「Astroのサイトは速い」と言われるいちばんの理由です。

▶︎Astroがやっていることを、4ステップで

1. 部品を作る：ヘッダー、フッター、記事ページの型など。一度作れば、全ページで使い回せます

2. 原稿を書く：記事の文章は、Markdown（マークダウン）という書き方のテキストで書けます。行の頭に「#」をつけると見出しになる、くらいの簡単なルールです

3. 組み立てる（ビルド）：Astroが部品と原稿を合体させて、全ページ分のHTMLを作ります。この作業を「ビルド」と呼びます

4. 置く：できあがったファイルの束を、④で出てくるNetlifyなどに置いて公開します

デザインの仕事をしている人なら、「レイアウトの型と原稿を入稿すると、全ページを刷り上げて製本までしてくれる印刷所」をイメージすると近いと思います。

そして地味にうれしいのが、修正のラクさです。たとえばヘッダーのメニューを1つ増やしたいとき、ヘッダーの部品を1か所直して、もう一度ビルドするだけで全ページに反映されます。手書きのHTMLだと、全ページを1枚ずつ直すことになるので、ここは大きな違いです。

▶︎「動く部分だけ島にする」アイランドという考え方

もうひとつ、Astroを語るときに必ず出てくるのが「アイランド（島）」です。

Astroで作ったページの大部分は、印刷されたポスターのように「動かない部分」です。そこに、検索ボックスやスライドショーのような「動かしたい部分」だけを、ぽつんと置く。静かな海に、動く島がいくつか浮かんでいるイメージです。公式はこれを「アイランド」と呼んでいます。

動きを担当するのはJavaScriptですが、Astroは何も指定しなければ、JavaScriptをゼロで出す設計になっています。動く仕掛けは、必要な島にだけ積む。海全体に電源を入れないから、軽いんです。

▶︎Astroで作ると、何がうれしい？

• 表示が速い：完成品を渡すだけなので、待ち時間が少ない

• 壊れにくく、狙われにくい：見に来るたびに組み立てる仕組みがないぶん、故障や攻撃の入り口が少ない

• 置き場所代が安い：ファイルを置くだけなので、NetlifyやCloudflareの無料枠で収まることが多い

• 検索エンジンやAIに読まれやすい：中身が最初からHTMLに書かれているので、機械にとっても読み取りやすい

▶︎逆に、向いていないこと

• 画面を見ながら、ドラッグで配置して作りたい：STUDIOのほうがずっとラクです

• ログインして使うアプリ（SNS、予約システム、管理画面など）：別の道具のほうが向いています

• 更新する人がコードを触れない：たとえばクライアントが自分で記事を更新したい場合は、管理画面を別に用意する工夫が必要です

なお、Astroは「一部のページだけ、見に来たときに作る」こともできます。ただ、基本の考え方はあくまで「作り置き」だと思っておけば十分です。

▶︎WordPress・STUDIOと比べると

• WordPress：見に来るたびにページを組み立てる。更新は管理画面から。ブラウザで記事を書いて更新したい人向け

• STUDIO：画面上で配置して作る。更新もエディタから。コードを書かずにデザインしたい人向け

• Astro：公開前にまとめて組み立てておく。更新はファイルを書き換えてビルド。速さを重視したい人、AIにコードを書いてもらう人向け

▶︎AIと組み合わせると、一気に現実的になる

Astroはもともと「コードを書ける人の道具」でした。でも今は、Claudeに「Astroでポートフォリオサイトを作って」とお願いすれば、部品も型もひと通り作ってもらえます。自分は原稿をMarkdownで書いて、GitHubに置いておけば、あとはNetlifyなどが自動でビルドして公開してくれる。コードを書くハードルをAIが下げてくれたことで、非エンジニアにとっても十分選択肢に入る道具になってきた、というのが自分の実感です。

ちなみに、2026年1月にはCloudflare（⑤で出てきます）がAstroの開発チームを迎え入れました。Astroは引き続き誰でも無料で使えるオープンソースのままで、Cloudflare以外の場所にも公開できる方針です。なので「NetlifyでもCloudflareでも組み合わせやすい」と思っておけば大丈夫です。

② 保管・共有｜GitHub

まず、似た名前の「Git」と「GitHub」の違いから。ゲームでたとえるとわかりやすいです。

AIの説明によく出てくる言葉も、このたとえで整理できます。

何がうれしいかというと、セーブがあるので「昨日の状態に戻したい」ができること。複数人やAIが同じプロジェクトを触っても、ぶつからないように管理できること。そして、変更を確認してから反映できることです。

AIとの関係で言うと、GitHubはいまや「ここにあるのが正しい最新版」という基準の置き場になっています。AIエージェントにコードを直してもらうときも、基本はGitHubのコードを見て、GitHub上で修正を提案する、という流れです。AIツールを本格的に使い始めると、たいていどこかでGitHubアカウントを作ることになります。「なんか登録させられたやつ」の正体は、この保管庫だったんですね。

③ 自動化｜GitHub Actions

GitHub Actionsは、GitHubにくっついている自動化の仕組みです。たとえば、こんなことを人の手なしで回せます。

• コードを更新したら → 自動でチェック（テスト）を走らせる

• 問題なければ → 自動で公開（デプロイ）する

• 毎朝9時に → 変更の記録をまとめて、資料を更新する

Astroの例でいうと、「記事を1本書いてpushする → 自動でビルド → 問題なければ公開」という流れを、ボタンひとつ押さずに回せるイメージです。この「更新したら自動でチェック＆公開」の流れを、専門用語でCI/CDと呼びます。読めなくてOKで、"自動化の流れ作業"くらいの理解で十分です。

ひとつ安心材料を。実は④で出てくるNetlifyやVercelも、「pushしたら自動でビルドして公開」を最初から自分でやってくれます。なので、最初のうちはGitHub Actionsを意識しなくても大丈夫です。「もっと細かい自動化をしたくなったら出てくる道具」と思っておいてください。

AI時代の変化として面白いのは、このロボットの中でAIそのものを動かせるようになってきたことです。「チェックに失敗したら、AIが原因を読んで、修正案まで作ってくれる」みたいなことが起き始めています。保管庫の番をしていたロボットが、ちょっと賢くなってきた感じですね。

④ 公開｜デプロイ／Vercel／Netlify

まず「デプロイ」という言葉から。

自分のPCの中だけで動いているサイトに、ネット上の住所（URL）を与えて世に出す作業です。お店でいえば、完成した店舗の看板を掲げて開店する瞬間。この「開店する場所」を提供してくれるのが、VercelやNetlifyです。

どちらも共通して、こんなことをしてくれます。

• GitHubと繋いでおけば、pushするだけで自動でビルドして公開してくれる

• サーバーの管理をしなくていい

• 公開前に確認できる、プレビュー用のURLが自動で発行される

で、この2つ、似ているようで方向性が少し違います。

▶︎Vercel（バーセル）

Next.jsというフレームワークの開発元が作っている公開サービスです。だからNext.jsとの相性が抜群で、表示の速さや性能に強い。特定のコースで最速を出すために調整されたスポーツカーのような存在です。最近は、言葉でお願いすると画面を作ってくれる「v0」など、AI開発まわりの道具も一気に揃えてきています。ひとつ注意点として、無料プランは個人・非商用向けなので、仕事で作るサイトは有料プランが必要です。

▶︎Netlify（ネットリファイ）

こちらは特定のフレームワークに寄らない「全部入り」路線です。お問い合わせフォームなど、サイトによく必要な機能が最初から同梱されていて、外部サービスをあれこれ繋がなくても済みます。なんでも積める万能ワゴンのような存在です。無料枠でも商用利用OKなのも、地味にうれしいポイントです。

⑤ 届ける・守る｜Cloudflare

これも「機能が多すぎて何屋さんなのかわからない」となりがちなサービスですが、「訪問者とサイト本体の"あいだ"に立つ存在」だと捉えると、一気にスッキリします。

訪問者はサイト本体に直接アクセスするのではなく、いったんCloudflareを"通って"からたどり着きます。その通り道で、主に3つの仕事をしてくれます。

さらに、実はCloudflare自体を④の「公開する場所」として使うこともできます。①で触れたとおりAstroの開発チームも加わったので、Astroで作ったサイトの置き場所としても自然な選択肢になりました。

AI時代の文脈だと、「AIに勝手に学習されないようにクローラーを制御する」機能や、AIが言葉でインフラを操作できる仕組みを出すなど、新しい機能がどんどん増えています。個人サイトのレベルでも、無料で使える配送網＆門番として普通に重宝します。

⑥ AIに手足を渡す｜エージェント・サブエージェント・MCP・Skills

ここが、今回いちばん「急に出会うようになった」領域だと思います。①〜⑤の道具を、AIが自分で操作できるようにするための仕組みたちです。お店にたとえると、新しく入ったAIスタッフに、仕事を任せるための仕組みです。

▶︎エージェント｜仕事を最後までやり切るAIスタッフ

ふつうのAIチャットは「質問に答える」だけですが、エージェントは「タスクを最後までやり切る」ことを目指します。たとえば「このバグ直して」と頼むと、コードを読んで、原因を探して、修正して、確認して……と、自分で段取りを考えて手を動かしてくれる。この"自分で動くAI"がエージェントです。

▶︎サブエージェント｜AIスタッフが仕事を振るアルバイト

大きな仕事を一人（一体？）で抱えると大変なので、メインのエージェントが細かい作業を"部下"に振り分けることがあります。この部下がサブエージェントです。「考えるのは賢いAI、細かい作業は身軽なAI」と分業したり、同時に何人も動かしたりできるので、速くなったり、役割分担でミスが減ったりします。

▶︎MCP（Model Context Protocol）｜どの道具にも挿せる共通コンセント

AIが実際に仕事をするには、外の道具（GitHub、カレンダー、データベース、Cloudflareなど）に繋がる必要があります。でも、繋ぎ方が道具ごとにバラバラだと大変ですよね。そこで「繋ぎ方を統一しよう」という共通規格が生まれました。それがMCPです。よく「AIのためのUSB-C」とたとえられます。この規格に対応していれば、AIはいろんな道具を同じやり方で操作できます。

ちなみに「WebMCP」は、これをWebサイト側に持ち込んだ新しい動きで、「サイトが自分の機能を、AI用の道具として差し出す」仕組みです。まだ実験段階ですが、今後のWebの使われ方を変えるかもしれない話なので、これは別で1本書きたいと思っています。

▶︎Skills（スキル）｜AIスタッフに渡す業務マニュアル

エージェントも万能ではないので、「この作業はこういう手順でやってね」という専門のマニュアルを渡すことで、特定の仕事の精度を上げられます。この手順書のかたまりがSkillsです。「文章チェック用」「資料作成用」みたいに、目的別に付け替えられます。

4つをまとめると、こうなります。

この一文が頭に入っていれば、⑥はひとまずOKです。

通しでやってみると｜ポートフォリオを公開するまで

最後に、①〜⑥が実際にどう繋がるのかを、「ポートフォリオサイトを作って公開する」流れで通してみます。

こうして並べると、「知らない横文字」だったものが、ひとつの作業の流れの中にちゃんと収まっているのがわかると思います。

早見表｜結局それぞれ何担当なの？

おわりに

こうやって並べてみると、バラバラに見えていた横文字たちも、「アイデアを公開サイトにするまでの流れ」のどこかに、ちゃんと居場所があるとわかってきます。

全部を深く理解する必要はなくて、「あ、これは公開の話ね」「これはAIに道具を繋ぐ話ね」と地図の上で位置づけられるだけで、AIの説明を読むときの手の止まり方がだいぶ減る気がします。少なくとも僕はラクになりました。

同じように「知らない横文字に急に囲まれてる」人の、地図がわりになれば嬉しいです。