【IT知識ゼロからOK】Webサービスが動く仕組み ― 生成AI時代のアーキテクチャ超入門・基礎編

本記事について

当サイトを閲覧いただきありがとうございます。本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ITの基礎知識」編・第1弾として、Webサービスが動く仕組みを解説する記事です。

本シリーズは「超入門」と銘打っているのですが、正直なところ、本編の記事はサーバーやデータベースといった言葉をある程度知っている前提で書かれてしまっている部分が有ります。なので、IT知識がほぼゼロの状態でも本編を読み始められる土台を作るために、この基礎編を用意することにしました。

この記事では、私たちが毎日使っているWebサービス（ネット通販や動画サイトなど）の裏側で何が起きているのかを、「レストラン」の例えだけで説明していきます。専門用語はほとんど出てきませんし、出てきたときは必ずその場で説明するようにしていますので、安心して読み進めてもらえればと思います。

この記事の結論

Webサービスは「注文する客」と「調理するキッチン」の分業と理解する
画面はフロントエンド、処理はバックエンド、記録はデータベースが担当する
本編で分からなくなったら、この記事のレストランの例えに戻ってくる

そもそもWebサービスとは何か

Webサービスとは、ざっくり言えば「ブラウザやスマホアプリを通じて使える、インターネット上のサービス全般」のことです。

ネット通販で買い物をしたり、動画サイトで動画を見たり、ネットバンキングで残高を確認したり・・・これらは全部Webサービスです。今読んでいただいているこのブログも、小さいながらWebサービスの一種ということになりますね。

ここで一つ考えてみて欲しいのですが、ブラウザで検索したり買い物したりするとき、その画面や商品の情報は一体どこからやって来ているのでしょうか？

当然ですが、自分のスマホやパソコンの中に世界中の商品情報や動画が全部入っているわけでは有りません。実際には「どこか遠くにあるコンピュータ」から、その都度取り寄せているのです。そして、この「取り寄せる仕組み」の全体像さえ分かってしまえば、本シリーズの内容は一気に読みやすくなると思います。

URLを打ってから画面が出るまでの流れ

ブラウザにURLを打ってエンターキーを押してから画面が表示されるまでの間に、裏側では次のようなことが起きています。

図の流れを言葉でも順番に追ってみます。

ブラウザが注文を出す ― 「このページを見せてください」という注文（専門用語で「リクエスト」と呼びます）が、インターネットを通って相手のコンピュータへ届きます
サーバーが注文を受け取る ― サーバーというのは、注文を受けて応えるための「お店側のコンピュータ」のことです
プログラムが調理する ― 注文の内容に合わせて、どの情報をどう組み立てて返すのかをプログラムが処理していきます
データベースから材料を取り出す ― 商品情報や会員情報といった記録された情報は、データベースという専用の保管庫から取り出されます
完成した画面が返ってくる ― 組み立てられた結果がブラウザに届いて、私たちの見ている画面として表示されます

ボタンを押すたび、ページを開くたびに、裏側ではこの5ステップの往復が毎回繰り返されています。しかも、大抵の場合この一連の流れは1秒もかからずに終わってしまうのです。改めて考えてみると、なかなか凄い仕組みだと思いませんか？

レストランに例えて整理してみる

先ほどの流れを、レストランの例えで整理し直してみます。実はWebサービスの登場人物というのは、レストランの登場人物と綺麗に対応させることが出来るのです。

レストラン	Webサービス	役割
お客さん	ブラウザ・スマホアプリ	注文を出して、料理を受け取る
注文	リクエスト	「これをください」という依頼
ホール係	フロントエンド	お客さんへの見せ方・接客を担当
キッチン	バックエンド	注文に応じた処理・調理を担当
倉庫・冷蔵庫	データベース	材料（情報）を保管しておく場所
お店の建物	サーバー	営業するための場所そのもの

この対応表は、ぜひ頭の片隅に置いておいて欲しいと思います。本シリーズの本編では「フロントエンド」「バックエンド」「データベース」といった言葉が当たり前のように出てきてしまうのですが、話が分からなくなったら「ホール係・キッチン・倉庫の話をしているんだな」と置き換えてもらえれば、大体の話は追えるようになるはずです。

クライアントとサーバー ― 「頼む側」と「応える側」

ここからもう一歩だけ踏み込みます。ITの世界では「頼む側」のことをクライアント、「応える側」のことをサーバーと呼んでいます。

レストランで言えばお客さんがクライアントで、お店がサーバーですね。ブラウザもスマホアプリも注文を出す側なので、全部クライアントということになります。つまりWebサービスというのは、「クライアントとサーバーの分業」で成り立っているのです。

では、なぜわざわざ分業するのでしょうか。この理由としては、「情報を1箇所にまとめて管理したい」というのが大きいです。もし商品の在庫情報が全員のスマホの中にバラバラに保存されていたら、誰かが商品を買うたびに、他の全員のスマホの在庫数を書き換えて回る必要が出てしまいます（考えただけでも不可能だと分かりますよね・・・）。お店側（サーバー）が一括で管理して、聞かれたら答えるという方式にしておけば、情報は常に1つで、みんなが同じ最新の状態を見られるというわけです。

フロントエンドとバックエンド ― 見た目と中身の分業

実は、お店の中もさらに分業されています。

フロントエンドはレストランで言うところのホール係で、メニューの見せ方や注文の受け付け方、料理の出し方といった、お客さんの目に触れる部分すべてを担当しています。Webサービスで言えば、画面のデザインやボタンの配置、入力フォームの動きなどがこれに当たりますね。

一方のバックエンドはキッチンです。注文された料理を実際に作る係で、「在庫を1つ減らす」「支払いを記録する」「会員かどうかを確認する」といった、お客さんからは直接見えない処理の部分を担当しています。

なぜこの2つを分けるのかというと、これもレストランと同じで、求められる技能が違うからです。接客の上手さと調理の腕前は別物ですよね。ITの世界でも見た目を作る技術と中身を作る技術は別の専門分野になっていて、大きなチームでは担当者も分かれています。本シリーズに「フロントエンドアーキテクチャ」という独立したカテゴリが有るのは、これが理由だったりします。

データベース ― なぜExcelではダメなのか

材料の保管庫であるデータベースについても、もう少しだけ補足しておきます。

「情報を記録しておくだけなら、Excelみたいな表でも良いのでは？」と思った方は、かなり筋が良いと思います。実際、データベースの中身は表の集まりのようなものですので、発想としてはかなり近いのです。

ただ、Webサービスの保管庫には、Excelでは耐えられない特殊な事情が有ります。それは「何千人・何万人が同時に読み書きする」ということです。

1つの帳簿に1万人が同時に書き込もうとしたらどうなるでしょうか？おそらく順番待ちや書き間違いで大混乱になってしまいますよね。それに、在庫が残り1個の商品を2人が同時に買おうとしたとき、両方に「購入完了」と出てしまったら大事故です。データベースというのは、こうした同時アクセスの交通整理を安全にさばくために作られた、専用の保管庫だと考えてください。

なので、本シリーズの「データアーキテクチャ」カテゴリは、この倉庫をどう設計してどう選ぶのかを延々と論じているカテゴリなんだな、と思ってもらえれば大丈夫です。

サーバーはどこにあるのか ― クラウドとは何か

最後に、お店の建物であるサーバーの「場所」の話をしておきます。

サーバーというのは、要するに性能の高いコンピュータのことです。昔は各企業が自社ビルの一室にサーバー用のコンピュータを買って置いていました（これを「オンプレミス」と呼びます）。ただ、自前で持ってしまうと、故障対応も停電対策も全部自分たちでやらなければならなくなります。

そこで現代の主流になったのがクラウドです。クラウドとは、ざっくり言えば「巨大なデータセンターにある大量のコンピュータを、必要な分だけ借りられるサービス」のことです。レストランで言えば、自分で店舗ビルを建てる代わりに、設備の整ったテナントを借りて営業するイメージでしょうか。

借りる方式にしておけば、お客さんが増えたら広い区画に引っ越すのも簡単に出来ますし、掃除や設備の保守はビルのオーナーがやってくれます。本編で頻繁に出てくるAWSというのは、このテナント貸しの世界最大手（Amazonが運営しています）の名前です。

この対応関係が分かれば本編が読める

ここまでの内容を頭に入れておくと、本シリーズの各カテゴリが「レストランのどこの話をしているのか」という形で整理出来るようになります。

フロントエンドアーキテクチャ ― ホール係（見た目と接客）の設計の話
ソフトウェア／アプリケーションアーキテクチャ ― キッチン（調理の段取りとレシピ）の設計の話
データアーキテクチャ ― 倉庫（材料の保管と管理）の設計の話
システムアーキテクチャ ― 建物・立地・電気水道（土台一式）の設計の話
セキュリティアーキテクチャ ― 鍵・防犯・衛生管理の話
開発運用アーキテクチャ ― 開店準備と、毎日お店を回し続ける仕事の話

つまり本シリーズというのは、「レストランを開いて、繁盛させて、何年も回し続けるための設計論」を担当ごとに分けて解説しているシリーズなのです。こう考えると、80本以上ある記事も少し身近に感じられるのではないでしょうか。全体像はシリーズの入口記事にまとめていますので、こちらもぜひ読んでみてください。