ウェブサービスは「覚えておくもの」と「できること」でできている

この章を終えると、ウェブサービスを、画面ではなくデータと機能で見られ、ブラウザ・サーバ・データベースの持ち場と、設計と実装の違いを専門用語で説明できる。

この記事は、構成を Claude Opus が決め、本文を Gemini が書き、頁に組んだのは Claude です。

ウェブサービスを作ろうとするとき、私たちは目に見える画面の形から考え始めてしまいがちです。しかし、画面の奥にある「覚えておくもの」と「できること」を言葉で整理しなければ、本当に動く仕組みにはなりません。この章では、画面ではなくデータと機能という視点でサービスを捉え直し、ブラウザやサーバの持ち場、そして設計と実装の違いを専門用語で説明できるようになることを目指します。

画面から考えると、何が決まらないまま残るか

インターネットを通じて手元の画面から利用できる便利な仕組みがあります。これをウェブサービスと呼びます。新しいウェブサービスを作ろうとするとき、多くの人はまず画面の絵を描いてみます。画面の絵を描くと、ボタンの配置や文字の大きさといった「どう見えるか」は決まります。しかし、画面の絵を描いただけでは「何を覚えておくか」や「誰が何をしてよいか」は決まりません。

たとえば、社内の備品を貸し出す画面の絵を思い浮かべてみてください。そこには借りているものを戻すための「返す」ボタンが描かれているとします。しかし、その絵を見ただけでは、他人が借りた備品を別の人が勝手に返せるのかどうかは分かりません。誰がいつ借りたという記録が残っているのかも、画面の絵のどこにも書かれていません。

画面の絵に描かれていない決まりは、自然に消えて無くなるわけではありません。決まっていない事柄は、実際にプログラムを作る人が、作るときに黙って決めてしまうことになります。その結果、作った人の思い込みで「他人の備品でも誰でも返せる」という不都合な仕組みになってしまうかもしれません。

仕組みを正しく組み立てるには、画面よりも先に決めるべきことがあります。サービスが覚えておくもの。これをデータと呼びます。そして、サービスができること。これを機能と呼びます。ウェブサービスは、データと機能でできています。画面は、データと機能が決まった後に、それらを利用者に見せるために決めるものなのです。

題材 ── 社内の備品の貸し出し台帳

Dev Tour は第 1 部と第 2 部を通して、1 つの題材を設計し、作ります。それが社内の備品の貸し出し台帳です。

まず、貸し出し台帳の背景と要件をまとめた説明文を示します。ここには、現場で生じている困りごと 3 つと、新しい台帳への望み 6 つが書かれています。

社内の備品の貸し出し台帳

総務の佐藤さんは、会社のプロジェクタ・カメラ・ノート PC の貸し出しを、表計算のファイル 1 枚で管理しています。借りたい人は佐藤さんに声をかけ、佐藤さんがファイルに名前と日付を書き込みます。

困っていることが 3 つあります。

  • いま誰が何を持っているのか、ファイルを開かないと分からない
  • 返したのに記録が直されず、「まだ借りている」ことになっている人がいる
  • 佐藤さんが休みの日は、誰も貸し出しを記録できない

そこで、社員が自分で借りて自分で返せる、ウェブの台帳を作ることにしました。

  • 管理者(総務)は、備品を台帳に登録する
  • 備品は、どこかの保管場所(棚や部屋)に置いてある
  • 社員は、空いている備品を借りる
  • 借りた本人は、その備品を返す。管理者も代わりに返せる
  • 社員は誰でも、備品の一覧と、それぞれが空いているかどうかを見られる
  • 社員は、自分がいま借りているものの一覧を見られる

この説明文に向き合うとき、ただ漫然と読むのではなく、データと機能に読み分ける視点を持つことが大切です。ここで役に立つ最初の手がかりが、「名詞はだいたいデータ、動詞はだいたい機能」という見方です。

まず、説明文に出てくる名詞に注目してみます。すると、「備品」「保管場所」「利用者(台帳を使う人)」「貸し出しの記録」といった言葉が見つかります。これらは、サービスが覚えておくべきデータの候補です。どの備品がどの保管場所にあり、誰が借りているかという事実は、台帳が覚えておかなければなりません。

次に、動詞に注目してみます。文中には「備品を登録する」「借りる」「返す」「一覧を見る」「自分が借りているものを見る」といった行動が並んでいます。これらは、サービスができること、すなわち機能の候補です。

このように、名詞と動詞を手がかりにすれば、文章の中からデータと機能の候補を自然に拾い分けることができます。もちろん、名詞をそのままデータにし、動詞をそのまま機能に機械的に対応させればすべて決まるわけではありません。読み分けの正確な形は、1-2「エンティティ」 から章を追って少しずつ作っていきます。ここではまず、「名詞はだいたいデータ、動詞はだいたい機能」という手がかりをしっかりと受け取ってください。

ブラウザ・サーバ・データベースの持ち場

ウェブサービスは、1 つの場所だけで動いているわけではありません。役割の異なる 3 つの持ち場に分かれて協力しながら動いています。

まず、利用者の手元で画面を表示し、ボタンが押されたり文字が入力されたりする操作を受け付ける仕組みがあります。これをブラウザと呼びます。次に、届いた要求を受け取り、あらかじめ決められた決まりに従って計算や判断を行う仕組みがあります。これをサーバと呼びます。そして、サービスが覚えておくべき大切な情報を長期にわたって保管しておく仕組みがあります。これをデータベースと呼びます。第 1 節で学んだ言葉と結びつけるなら、データはデータベースに、機能はサーバに住む、と対応させて覚えて構いません。

これら 3 つの持ち場は、互いに通信しながら動きます。ブラウザがサーバへ向けて送る「これをしてほしい」という依頼。これをリクエストと呼びます。依頼を受け取ったサーバが処理を行い、その結果としてブラウザへ送り届ける返事。これをレスポンスと呼びます。

たとえば、社員が備品を借りる場面の流れを追ってみましょう。社員がブラウザの画面で「借りる」を押すと、ブラウザはサーバへ「この備品をこの社員に貸し出してください」というリクエストを送ります。リクエストを受け取ったサーバは、台帳の決まりに従って処理を進め、新しい貸出の記録をデータベースに残します。データベースはその記録を確実に覚えておきます。処理を終えたサーバは、ブラウザへ「貸し出しを記録しました」というレスポンスを返します。レスポンスを受け取ったブラウザが画面を更新し、無事に「借りました」という表示に切り替わります。

ここで、持ち場を大きく 2 つの側に分ける呼び名も覚えておきましょう。利用者の手元で動くブラウザの画面側。これをフロントエンドと呼びます。そして、手元からは直接見えないサーバとデータベースの側。これをバックエンドと呼びます。

では、決まりはどちらの側で守るのでしょうか?台帳には、「空いていない備品は借りられない」「他人の貸出は返せない」といった決まりがあります。これらを守る持ち場はバックエンドです。フロントエンドは利用者の手元にあるため、利用者がいくらでも画面の仕組みを作り替えることができてしまいます。そのため、決まりを守る判定をフロントエンドに任せることはできません。バックエンドが必ず責任を持って決まりを調べ、データベースのデータを正しく保つのです。

設計は決めること、実装は決めたことを写すこと

ウェブサービスを作る作業は、大きく 2 つの段階に分かれます。

まず、どんなデータを覚えておくか、どんな機能を用意するか、そしてそれらが守るべき決まりを言葉で決める作業があります。これを設計と呼びます。次に、設計で決めた言葉の内容を、コンピュータが動かせるプログラムに写し取る作業があります。これを実装と呼びます。

設計は、日本語などの日常の言葉で書くことができます。プログラミングの技術を持っていなくても、業務の都合や必要な約束事を整理して設計を進めることは十分に可能です。

たとえば、「空いていない備品は借りられない」という 1 つの文を考えてみてください。設計の段階では、これは台帳が守るべき大切な決まりという言葉の約束事です。一方、実装の段階では、備品が貸出中かどうかをプログラムの中で判定して貸出を断る、という具体的な確かめになります。決めた約束事を、そのままプログラムという形に写し取るのが実装の役割です。

Dev Tour の第 1 部では、この設計の進め方を扱います。そして第 2 部では、Gleam という言語を使って、決めたことを実際に実装していきます。第 1 部の終わりには、社内の備品台帳を作るための設計メモが 1 枚きちんと完成します。

AI は、決めていないことを黙って決める

AI にプログラムを書かせると、人間が指示の中で説明しきれなかった足りない部分を、それらしく埋めて書き上げてしまいます。そして困ったことに、どの部分を AI が自分勝手に埋めたのかは、後から言われなければ誰にも分かりません。表面上は綺麗に動いて見えても、中身では予期せぬ処理が行われていることがあります。

たとえば、備品の貸し出し台帳の作成を、仕様を決めずに AI に頼んだとします。そのとき AI が黙って決めてしまうことの例として、次の 3 つが挙げられます。1 つ目は、同じ備品を 2 人が同時に借りようとしたらどうなるか、という問題です。2 つ目は、管理者は他人の貸出を返せるか、という権限の扱いです。3 つ目は、返却を終えた後に、返した記録を残すか消すか、という履歴の管理です。これらを人間が決めて伝えていなければ、AI はどれか 1 つの選択肢を勝手に選び、その通りに実装を組み立ててしまいます。

こうした問題を防ぐために、設計を先に書いておくことが不可欠です。設計を言葉にして先に残しておけば、AI の書いた実装が設計を守っているかを人間が自分の目で確かめられます。重要なのは、AI に対する頼み方の工夫ではありません。AI が書いたコードを評価し、不都合がないかを正しく確かめる物差しを先に持つ、ということです。

設計を決めずに作らせる「AI に丸投げする」やり方と、設計を人間が言葉で定義して「AI に書かせて設計を担う」やり方の違いがここにあります。

この章のまとめ

ウェブサービスは、目に見える画面ではなく、「覚えておくもの」であるデータと、「できること」である機能でできています。データはデータベースに保管され、機能はサーバに住んでいます。利用者の手元にあるブラウザは、サーバへリクエストを送り、処理された結果をレスポンスとして受け取って画面に映し出します。画面の具体的な姿は、これらデータと機能、そして持ち場の役割を整理した後に決めるものです。

次の章(1-2「エンティティ」)では、台帳の日常の言葉で書かれた説明文から、台帳が覚えておくデータの単位(エンティティ)を拾い出します。そして、それらを混同せずに 1 つずつ見分ける具体的な方法を学んでいきます。

© 2026 Canonicalgleam.canon-ical.com