Webサービスを作る上での前提知識

このテーマのゴール

使う側から、作る側の目線へ — Webサービスの中身が見えるようになる これから作るのは「サイト」ではなく「サービス」です。このテーマでは、サービスを構成するたった3つの要素を理解し、身近なサービスを作る側の視点で観察できるようになることを目指します。今日はまだ開発環境すら使いません。頭とブラウザだけのテーマです。

「Webページ」と「Webサービス」の違いを説明できます。データが動くかどうか、それが分かれ目です。 画面（フロントエンド）・処理（サーバー）・データ（データベース）。この3語でサービスの中身を語れます。 身近なサービスの画面から「裏で何が起きているか」を予想し、AIに確認して確かめる型を身につけます。

🎯 このコースの「走る例」 — 総務部の備品申請

あなたは総務部の所属です。備品の申請は今、紙・メール・口頭でバラバラ。総務担当は月末に各所からの連絡を手集計し、発注リスト作成に半日かかっています。このコースでは、この課題を申請フォーム＋申請一覧＋集計 を持つ小さなWebサービスで解決します。今講座では、このサービスを3要素に分解するところまでです。

このテーマの流れ

P テーマ 身につけること P3〜5 サービスの正体とクリックの裏側 Webページとの違い、いいねの6ステップと3者の分担 P6〜8 3要素と観察する練習 画面・処理・データの役割、解剖手順とワークシート P9〜10 開発の流れと走る例の分解 5フェーズ、人間とAIの分担、備品申請の3要素分解 P11〜12 AIへの聞き方とまとめ 聞き方2つの型とNG→OK、チェックリスト、この先の持ち物

WebページとWebサービスは何が違うのか

どちらもブラウザで見るもの、ですが、中身の動き方 が決定的に違います。このコースで作るのは後者です。

📄 Webページ

見た目が主役 の電子のチラシ。会社紹介や商品説明など、見せるだけ のもの。閲覧者が何をしても中身は変わらない（例: 会社の採用ページ）。

⚙️ Webサービス

人の仕事が動く 仕組み。入力すると保存され、他の人がその結果を見られる。データが続きけて積み上がる点がチラシと違う（例: 備品申請フォーム）。

両者の違いを1つの表で比較する

比較軸 📄 Webページ ⚙️ Webサービス 中身の主役 見た目（文章・画像） データ（申請・記録・集計） 閲覧者ができること 読む・見る・リンクをたどる 入力する・送信する・結果を見る 放置したとき 古くなるだけ データが積み上がり、業務の実態記録になる 壊れ方の典型 リンク切れ 保存できない・集計が合わない 業務での例 社内報、マニュアル掲載ページ 備品申請、経費精算、勤怠入力

Webサービスとは「誰かの課題を、続きけて動く形で解くもの」 です。一度作って終わりではなく、使うたびにデータが積み上がり、業務の実態を記録していく。この違いがあるから、作る難しさも価値も一段上がります。本コースで扱うのは常にこちらです。

「いいね」を押したとき何が起きるか

社内SNSでも評価ツールでも、「いいね」を押す という一瞬の操作の裏で、3者の間でやり取りが動いています。この流れはどのWebサービスでもほぼ同じ形です。

画面上のボタンがクリックを検知します。ここまでは画面（ブラウザ） の仕事。指先の操作を、機械への合図に変える瞬間です。 「この投稿にいいねが押されました」という依頼（リクエスト） をサーバーへ送信します。宅配便の受付に出す伝票のようなものです。 裏方のプログラムが依頼内容を確認します。「誰が・どの投稿に」押したのかを解釈し、次の作業を決めるのはこの部分です。 いいねの事実を1件保存します。ここで初めて、明日も明後日も残る記録 になります。画面を閉じても消えません。 処理が終わった旨の返事（レスポンス） を画面へ返します。「受け付けました、現在の合計はこれです」という報告です。 受け取った返事でボタンの数字を1増やして表示します。見た目が変わるのは最後の一瞬。一連の動きの完了です。

この流れの登場人物は3者だけ

🖥 画面（ブラウザ）

利用者の操作を受け付け、依頼を送り、返事を表示する。1〜2と6を担当。

⚙️ サーバー

依頼を受け取り、ルールに従って処理し、返事を返す裏方。3と5を担当。

🗄 データベース

処理の結果を記録として残し続ける棚。4を担当。 次のページで詳しく扱います。

押さえておく3語

用語 意味 リクエスト 画面 → サーバーへの「依頼」 レスポンス サーバー → 画面への「返事」 データベース 依頼の結果を残す「記録の棚」

💡 電話での受付に例えると

リクエストは「受付電話」、サーバーの処理は「担当者の作業」、データベースは「台帳への記入」、レスポンスは「折り返しの返事」。依頼 → 処理 → 記録 → 返事 の流れは、電話受付の仕事と同じ構造です。

この流れは、どのサービスでも同じ形で起きている

日常の操作 裏で走る処理の例 データベースに残る記録 経費精算で「申請」を押す 上限チェック→上司へ承認回し 申請明細と承認履歴 勤怠システムで「出勤打刻」 打刻時刻の記録と遅刻判定 日ごとの勤怠実績 問い合わせフォームで「送信」 入力チェック→受付番号の発行 問い合わせ履歴と対応状況

1回のクリックの裏では 「依頼 → 処理 → 記録 → 返事 → 表示」 が0.数秒で走っています。この型は備品申請でも経費精算でも同じ。動きの型を1つ知れば、すべてのサービスの動きが読める ようになります。

スマホアプリでも構図は同じです。アプリの中に「画面」があり、ボタンを押すと「サーバー」へ依頼が飛び、記録がデータベースに残ります。ブラウザかアプリかの違いだけで、3者の分担は変わらない — だからこのテーマで学ぶ型は、社内のWebサービスにも業務アプリにもそのまま使えます。

サービスを構成する3要素

どんなに大きなサービスでも、構成要素はこの3つに分解できます。これから先の講座で設計・実装を進めるときも、常にこの3つで考えます。

🖥

画面（フロントエンド）

利用者が見て、触る部分。フォーム・ボタン・一覧表。入力の受付と結果の表示 を担う。

⚙️

処理（サーバー）

依頼を受けて仕事をする裏方。判定・計算・集計・データへの橋渡し。業務のルール がここに書かれる。

🗄

データ（データベース）

記録を残す棚。申請の履歴・利用者の情報・集計の元。ここに積もったものが業務の実態 になる。

支店に例えると、3要素は「窓口・裏方・金庫」

要素 支店での役割 備品申請での役割 壊れたら起きること 🖥 画面 受付カウンター。お客さんが対面で話す場所 申請フォーム・申請一覧・集計表の見た目 ボタンを押せない、入力できない ⚙️ 処理 裏方担当。書類を審査し、伝票を切り、棚へしまう 入力チェック、状況の更新、月末の個数合計 申請しても反映されない、集計が合わない 🗄 データ 書類庫。過去の伝票がすべて残る棚 申請の記録（日付・品名・個数・状況） 昨日の申請が消える、履歴がたどれない

3要素は独立していて、連携して動く。画面が立っても処理がなければ申請は残らない。処理があってもデータがなければ翌月には消える。どれか1つが欠けると「続きけて動く仕組み」にならない — これがWebページとの違いの正体です。

身近なサービスを「解剖」する練習

設計の材料は、すでに動いているサービスから採る ものです。ここでは、日頃使っているサービスを3要素で読み解く手順を身につけます。

STEP 1 — 画面を数える

そのサービスにいくつの画面があるか を数えます。一覧・詳細・入力・履歴。画面の数がわかると、サービスの輪郭が見えます。

STEP 2 — 入力と表示を区別

各画面のうち、ユーザーが入力するもの と参照されるだけのもの を分けます。入力がある画面が、データの入り口です。

STEP 3 — 記録を予想する

この操作の裏で何が保存されているはずか を予想します。外れたらAIに聞いて確かめる。これが観察の完成形です。

観察チェックリスト — 好きな社内システムに当てはめる

観点 チェックする問い 経費精算システムでの答えの例 画面・表示 画面はいくつあるか？ 入力せず見るだけの画面はどれか？ 申請入力、申請一覧、承認、精算結果の4画面（一覧と結果は参照専用） 入力 ユーザーが入力する項目は何か？ 日付、金額、科目、摘要、証憑ファイル 処理 裏で動いているルールは何か？ 上限チェック、上司への承認回し、月次の合計 データ 保存されている記録は何か？ 申請1件ごとの明細、承認履歴、確定済み実績

見落とさないコツ — 挙動の違いに注目する

🔄 更新してみる

再読み込みしても同じ内容が保たれるなら、それはデータとして保存されている証拠。

📱 別端末で開く

別の端末で同じ記録が見えるなら、共有されているデータの範囲 がわかる。

🕘 履歴をたどる

履歴が遡れる範囲＝データが積もる範囲。未来の集計の材料になる。

📝 走る例 — 今月中にやること

会社で使っているシステムを1つ選び、下のワークシートを埋めてみてください（紙のメモに写しても構いません）。この先の観察演習（04）や企画の講座で、この埋まったシートがそのまま設計の材料 になります。

観察ワークシート — 埋めればこの先の演習の材料になる

観察するシステム （システム名を書く） ① 画面はいくつあるか （例: 入力画面、一覧画面、承認画面…） ② 入力する項目は何か （例: 日付、金額、添付ファイル…） ③ 裏で動いていそうなルール （例: 上限チェック、承認の回し方…） ④ 保存されていそうな記録 （例: 申請の明細、承認履歴…） ⑤ 自分の予想（確かめたいこと） （例: 月次で締め処理がある？ と予想）

観察のゴールは「操作を覚えること」ではなく、「保存されている記録の形を言い当てること」 です。予想が当たるほどこの先の企画が速くなり、外れてもAIに聞いて裏取りすれば知識になります。ワークシートの⑤が特に重要 — 予想を書いてからAIに確かめる のが、このコースの基本の型です。

サービスが生まれるまでの流れと、AIの入りどころ

サービスは「思いつき」から始まりません。業務では決まった流れで作られます。本コースの講座構成も、この流れそのものです。

各フェーズの問いと、人間とAIの分担

フェーズ 中心となる問い 人間の仕事 AIの仕事 企画 誰の何の課題を解くのか 課題を知り、決める 選択肢を出し、穴を突く 設計 画面・データ・処理をどう定義するか 業務の正しい形を確認 絵と定義を書き起こす 実装 どう動かすか 確認と判断 コードを書く 公開 どう届けるか 社内の了承を取る 作業手順を整える 運用 どう回し続けるか 要望を聞き、優先順位をつける 改善案を出し、実装する

本コースの講座と対応している

講座 相当するフェーズ 前提知識（本講座） 全体の地図を持つ AIと企画する 企画 （続刊の講座） 設計 → 実装 → 公開 → 運用

人間は「監督」、AIは「実行部隊」。 課題を一番よく知っているのは現場のあなたです。企画の判断と業務の正しさの確認は、最後まで人間の仕事です。

重要なのは、企画と設計に全体の時間の半分を使う こと。ここが詰まっていれば、実装はAIが圧倒的に速く進めます。逆に企画が曖昧なまま実装に入ると、作っては直しの繰り返しになります。本コースがまず企画から始めるのはこのためです。

走る例「備品申請」を3要素で分解する

ここまでの知識を、実際に走る例へ適用します。「月末の集計に半日」という課題を、3要素で分解してみましょう。これがこの先の企画の土台になります。

画面 — 3枚そろえば業務が回る

📋 申請フォーム

申請者が入力する画面。項目を埋めて送信するだけ。誰に頼むか迷わせないのが改善点。

📑 申請一覧

総務担当が全申請を見る画面。新着順・状況で絞り込み。メールの行方不明をなくす。

📊 集計表

月末の発注リスト。品目別個数・月別件数を自動算出。半日の手作業を数分に。

データ — 申請1件ぶんの記録

項目 型のイメージ なぜ必要か 申請日 日付 いつの申請か。月次集計の軸 品名 選択肢 自由記載にすると集計不能になるため 個数 数値 発注数の合算に使う 理由 短い文章 承認判断の材料 希望日 日付 発注タイミングの判断 状況 承認済み等 処理済み見落としを防ぐ

処理 — 裏方に書くルール

ルール 内容 入力チェック 個数は1以上、希望日は今日以降 登録 送信内容に日付と状況を付けて保存 一覧の並べ替え 新着順、状況による絞り込み 集計 月別・品目別の個数合計を自動計算

この分解を「サービスの正体が見えている証拠」として、企画の講座でそのまま転用します。

知らない用語はその場でAIに聞く

入門の学習では、用語の連続です。読書と違って、分からない語をそのままにしない のがコツです。チャットAIは「引き出しの多い先輩」として使えます。聞き方の型を2つ、このテーマの内容で示します。

フロントエンド、サーバー、データベースの違いを、【総務部の備品申請】← ここを自分の業務に書き換え を題材に、窓口・裏方・書類庫のたとえで説明してください。IT未経験の社会人に向け、専門用語は避けてください。

私は今、社内の【経費精算システム】← ここを観察したサービスに書き換え を観察しています。画面は申請入力・一覧・承認の3つで、入力項目は日付・金額・科目・摘要です。この裏で保存されていそうなデータと動いていそうな処理を、3要素（画面・処理・データ）に分けて予想してください。まず私の予想【月次で締め処理がある】← 自分の予想に書き換え が正しいかも確かめてください。

聞き方のNGとOK

Webサービスの作り方を教えて 備品申請を管理するサービスを作るとしたら、まず決めるべきことを3つ挙げて 広すぎると一般論が返る。目的を絞ると使える答えが返る

フロントエンドとは何ですか フロントエンドとは何か、備品申請サービスの例で、サーバーとの違いがわかるように教えて 「何に使いたいか」を添えると、噛み砕いた説明が返る

用語は*「業務の例」を添えて聞く* と、抽象的な定義ではなく使える理解が返ってきます。また、自分の予想を先に言ってから確かめてもらうと、受け身の読みから能動的な確認 に変わり、記憶に残ります。この2つの型は、この先のすべての講座で使います。

まとめ

このテーマで目指したのは、サービスの中身が見える目 です。以下が全部「はい」と言えるなら、次のテーマに進む準備はできています。

✓ できるようになったこと 確かめ方 ☑ WebページとWebサービスの違いを説明できる 「データが積もるかどうか」の違いを同僚に説明してみる ☑ クリックの裏の動き（依頼→処理→記録→返事）を追える いいねを押したときの流れを紙に書き出す ☑ どんなサービスも3要素に分解できる 使っている社内システムを画面・処理・データに分ける ☑ 開発が5フェーズで進むことを知っている AIと作るべきフェーズを順に言ってみる ☑ 備品申請を3要素に分解した P10の分解表を自分の業務課題で埋め直す

このテーマの核心 — 3つだけ

• サービス＝続きけて動く課題解決。データが積もる点がページと違う
• 中身は3要素。画面・処理・データ。この3語でサービスの中身を語れる
• 観察が設計の材料。使っているサービスはすべて教材になる

この先 — この講座の続き（02〜05）

1. 02 AI開発の全体像 — チャットAIとコーディングAIの役割分担
2. 03 動くコードを読む — 書かずに構造を掴む練習
3. 04 観察演習 — 身近なサービスを解剖し切る
4. 05 データの基礎 — 記録の形をデザインする

🔧 続きのテーマを始める前の持ち物チェック

✓ 持ち物 確認ポイント ☑ 観察ワークシート（P8） 社内システム1件ぶんの5観点が埋まっている ☑ 備品申請の分解表（P10） 画面3枚・データ6項目・処理4ルールを自分の言葉で言える ☑ チャットAIの利用環境 無料プランでよいので、質問を1回投げて返事が返る状態

持ち物が揃っていれば、続きのテーマ（02〜05）をそのまま進められます。

このテーマのゴール

開発の主役は、あなたと2人のAI — まず登場人物を知る このテーマでは、サービスを作るときに「誰が何を担当するのか」を整理します。相談役のチャットAI、実行役のコーディングAI、道具の開発環境、そして監督であるあなた。今日はまだ道具を触りません。登場人物の名前と役割を知るだけで、この先の実装が格段に分かりやすくなります。

相談相手（頭脳）。企画や設計の壁打ち、用語の説明、文書の下書き。ブラウザさえあれば今日から使える相棒です。 実行部隊（手足）。指示を受けてコードを書き、動かし、直す。Claude Code / Codex / Gemini CLI など。実装フェーズから登場します。 何を作るかを決め、生成物を確認し、OKを出す。どのフェーズでも判断を握るのは、現場を知るあなたです。

🎯 走る例 — 備品申請を作るとき、誰が何をやる?

備品申請サービスを作るとき — 「申請画面に何を入れるか」の相談はチャットAI。「フォームのコードを書く」のはコーディングAI。「月末集計が30分になる」という完了条件を守る判断はあなた。1つのサービスを3者で作る 図を、このテーマで頭に描けるようにします。

このテーマの流れ

P テーマ 身につけること P3 相棒は2人 チャットAIとコーディングAIの違いと使い分け P4 開発環境3点セット VS Code・Node.js・エージェントの役割（まだ触らない） P5〜6 監督の仕事とまとめ 指示→生成→確認のサイクル、チェックリスト

相棒は2人 — チャットAIとコーディングAI

どちらも「AI」ですが、仕事と居場所 が違います。1つの表で押さえます。

比較軸 🗣 チャットAI ⌨️ コーディングAI 居場所 ブラウザのチャット画面 ターミナルとエディタの中 やり取り 日本語で相談 → 文章で返事 指示 → 実際のファイルを書き換え 主な活躍フェーズ 企画・設計・学習 実装・改善 備品申請での例 「申請画面の項目、これで十分?」と相談 「フォーム6項目のコードを書いて」と実行

開発は「相談→実行」の往復で進む

💬 相談する

チャットAIに方針を壁打ち。画面・項目・完了条件を言語化

→

⌨️ 実行する

コーディングAIに実装指示。動くものができる

→

🎬 確認する

あなたが動作確認。直すなら実行へ、OKなら次の相談へ

💡 使い分けの判断 — たった1問

「考える手伝い」が欲しい → チャットAI。「手を動かしてほしい」→ コーディングAI。迷ったらまず相談すれば、振り先も教えてくれます。

⚠️ よくある勘違い

コーディングAIでも相談はできますが、文書の壁打ちはチャットAIが得意。2本立てが基本と覚えてください。

2つのAIは競合ではなく、相談役と実行役のコンビ です。「相談（頭脳）→ 実行（手足）→ 確認（監督）」の往復 — このリズムが、このコース全体を貫く開発の基本形です。

開発環境3点セット — まだ触らない、名前だけ

実装の講座で整える道具が3つあります。今日は用意しなくてOK。名前と「何の机か」だけ持って帰ります。

🖥

VS Code — 作業机

コード（＝ただのテキストファイル）を書く・読むための専用エディタ。Wordが文書のための道具であるように、コードのための道具です。無料。

⚙️

Node.js — 電源と工場

コードをパソコン上で動かすための実行環境。電化製品に電源が必要なように、Webサービスには Node.js が必要です。無料。

🤖

コーディングAI — 職人

VS Code やターミナルの中で指示を受けて作業する 相棒。作業机（VS Code）に職人（AI）が座る、という関係です。

備品申請の「申請書の様式作り」にたとえると

道具 たとえ 備品申請での役割 VS Code 作業机と文房具 様式を書くための机。まずここに向かう 申請フォームのコード 申請書の様式 机の上で職人が仕上げる「様式」そのもの Node.js コピー機の電源 様式をみんなが開ける形に出力・動作させる コーディングAI 様式を仕上げる職人 指示を受けて様式（コード）を実際に作る あなた 様式を決める総務担当 項目と完了条件を決め、出来上がりを確認する

このテーマでは導入しません。実装の講座で手順付きで整えます（各10分ほどの作業）。今の持ち帰りは「VS Code は机、Node.js は電源、AIは職人」の3語だけです。すべて無料で、AIは自分のパソコンの中で働く — 外注もサーバー契約も不要。これが「作れる人材」の敷居を一気に下げた最大の変化です。

人間の仕事は「監督」 — 指示して、確認して、決める

AIがコードを書く時代、人間の仕事は監督に絞られます。監督の作業サイクルは、常にこの4ステップです。

タスク・対象・制約・完了条件を伝える。「フォーム6項目を作って」 AIがコードを書く。人間は待つだけ。数秒〜数分 動かしてみる。意図どおりか自分の目と手で確かめる ずれていれば直させる。問題なければOKを出して次へ

監督が手放さない3つの仕事

仕事 内容 備品申請での例 判断 何を作るか・作らないか 承認フローはv1に入れない、と決める 確認 動作と内容のチェック 申請→一覧反映を自分で1往復試す 決定 OKを出すのは常に人間 「これで公開する」と言い切る

生成だけがAIの仕事ではありません。判断・確認・決定は、最後まであなたの仕事です。

指示と確認の NG→OK

備品申請、いい感じに作って（丸投げ） フォーム・一覧・集計の3画面を、項目6つで作って。完了条件は集計30分 指示の精度が成果の精度を決める

動いたからOK、中身は見ない 申請を1件入れて、一覧への反映を自分の目で確認してからOK 「動いたように見える」と「動く」は違う

監督はAIに「任せる」のではなく「使う」。指示の精度を上げ、生成物を確認し、決定を持つ — 3つとも人間のまま、書く作業だけをAIへ。この分担が、企画の講座で学んだ「人間は問いと判断を持つ」と同じ形であることに気づくはずです。

まとめ

このテーマで身につけたのは、開発の登場人物とあなたの役割 です。

✓ できるようになったこと 確かめ方 ☑ 2つのAIの違いを説明できる 相談=チャットAI、実行=コーディングAIと言える ☑ 「相談→実行→確認」の往復を描ける 備品申請の各工程をどのAIに振るか言える ☑ 開発環境3点セットの役割を言える 作業机・電源・職人でたとえられる ☑ 監督のサイクルを回せる 指示→生成→確認→修正の順を説明できる ☑ 監督が手放さない3仕事を知っている 判断・確認・決定を挙げられる

このテーマの核心 — 3つだけ

• 相棒は2人。相談役のチャットAIと、実行役のコーディングAI
• 環境は3点。机（VS Code）・電源（Node.js）・職人（AI）。すべて無料
• あなたは監督。判断・確認・決定は最後まで人間の仕事

次のテーマ — 動くコードを読む

• 監督の「確認」に必要な読む力 を鍛えます
• AIに生成させたコードを「書かずに読む」練習です
• 持ち物: このテーマの役割分担（誰が何をやるか）だけです

このテーマのゴール

コードは「書く」前に「読む」— 監督に必要な最初の力 前テーマで、あなたの仕事は監督（判断・確認・決定）だと学びました。確認には「生成されたコードと、ほどほどに付き合う力」が要ります。このテーマでは、AIにコードを生成させて読む 練習をします。1行も暗記しません。部品の名前と流れを掴むだけで、監督の「確認」が始まります。

生成されたコードから見出し・入力欄・ボタン などの部品を見つけ、「この画面に何があるか」を言えるようにします。 ゼロから書くのはもう人間の仕事ではありません。読めないと確認できない から読む。書くためではありません。 分からない行はその場でAIに聞く。聞き方の型を2つ持ち帰れば、初見のコードも怖くありません。

🎯 走る例 — 備品申請フォームのコードを読む

チャットAIに「備品申請フォーム」のHTMLを生成させ、そのコードを部品単位で読んでいきます。使うのはブラウザのチャットAIだけ。開発環境はまだ要りません。

このテーマの流れ

P テーマ 身につけること P3 なぜ「読む」から始めるか 読む理由3つ、HTMLの最小ルール P4〜5 HTMLとJavaScriptを読む 生成→読解の実演、イベント→処理の型、AIへの聞き方 P6 まとめ チェックリスト、次テーマへの持ち物

なぜ「読む」から始めるのか

① 書く必要がもうない

コードを書くのはコーディングAIの仕事。人間に残るのは読んで確認する 作業だから、練習するのは読む力です。

② 読めないと確認できない

監督の「確認」は、画面が動くか見るだけでは不十分。どの部品があるか 把握して初めて「意図どおり」と言えます。

③ 読むは書くより簡単

書くには文法の暗記が要りますが、読むは部品の名前を知るだけ。旅行で現地語を読む（看板の意味を掴む）方が話すより簡単なのと同じです。

HTMLの最小ルール — たった4つ

<h1>備品申請フォーム</h1>
<p>以下の項目を入力してください。</p>
<button>送信する</button>

ルール 意味 上のコードでの例 タグ < >で囲まれた「部品の名前」。開始タグと終了タグで挟む <h1> は大見出し、<p> は段落、<button> はボタン 入れ子 タグの中にタグを置ける。箱の中に小物を入れるイメージ フォームの中に、入力欄とボタンが入る 属性 タグへの追加情報。「こういう種類で」という指定 type="number" で「数値入力欄」にする インデント 見やすさのための字下げ。動きには影響しない 入れ子の内側が右にずれている部分

HTMLは「意味の付いた箇条書き」です。<h1> や <button> といった部品の名前を数十個知っているプロでも、読むときに使うのはよく出る10個程度。全部読もうとせず、見出し・入力・ボタンなど「部品」を見つけるだけで、まずは十分です。

HTMLを読む — 生成させて、構造を見る

読む練習の材料は、AIに生成させます。「良い指示→読みやすいコード」も体験しましょう。

備品申請フォームのHTMLを、申請日・品名・個数・理由・希望日・状況の6項目で作ってください。各部品に日本語のコメントを付けて、HTMLを初めて読む人にも分かるようにしてください。デザインは最小限で構いません。

返ってくるコードの一部を読んでみる

<form>                          <!-- 申請のまとまり -->
  <label>品名</label>            <!-- 項目名の表示 -->
  <select>                       <!-- 選択肢から選ぶ入力 -->
    <option>ノートPC</option>
  </select>
  <label>個数</label>
  <input type="number" />        <!-- 数値の入力欄 -->
  <button type="submit">送信する</button>
</form>

読み取りポイント — 探す部品は5種類

部品 意味 備品申請での役割 form 入力のまとまり 「申請1件」の枠 label 項目名の表示 「品名」「個数」の表示 select 選択肢から選ぶ 品名・状況の入力 input 短い入力欄 個数（数値）の入力 button ボタン 送信の動作のきっかけ

読む順番 — 3段階

1. 外側の大枠 — form の中に部品が並んでいる、と掴む
2. 部品の名前 — label / select / input / button の4語が見つかれば合格
3. コメントを読む — 生成時に頼んだコメントが各行の説明書になる

読む前に「何を確認したいか」を1つ決める — 「品名は選択式か」など。目当てが決まると部品がすぐ見つかります。

✅ 生成を頼むとき「コメント付きで」の一言を添えると、コードが自分用の教材に変わります。読む ＝ コメントと部品名を拾う、だけで初見のフォームの構造は把握できます。

生成を頼むとき「コメント付きで」の一言を添えると、コードが自分用の教材に変わります。読む = コメントと部品名を拾う、だけで初見のフォームの構造は把握できます。

JavaScriptをざっくり読む

JavaScriptは「動き」の指示書です。パターンはほぼ1つ — 「〜したら、〇〇する」（イベント→処理）。いいねボタンの例で読んでみます。

button.addEventListener("click", () => {
  // クリックされたら、この { } の中を実行する
  count = count + 1;          // 数字を1つ増やす
  label.textContent = count;  // 画面の表示を書き換える
});

読み取れたこと — 3つだけ

部分 意味 備品申請での対応 "click" きっかけ（イベント） 「送信ボタンが押されたら」 { } の中 きっかけ後の仕事 入力を集めて、記録を残す 変数 count 値を入れる箱 申請の件数・個数の合計

addEventListener は「〜したら」を書くための定型句。暗記せず、AIに聞けばよい 辞書的な名前です。

読む必要のあること・ないこと

読む 読まない イベントの種類（クリック等） 記号の細かい意味（=> など） 処理のあらすじ（何が変わるか） 文法の正しさの判定 画面のどこが変わるか 省略形かどうかの違い

文法の判定はAIの仕事。監督は*「きっかけと結果」が意図どおりか* だけを見ます。きっかけ（イベント）を追えば流れは読める — 「全部理解してから先へ」ではなく、構造を掴んだら先へ が監督の読み方です。

分からない行は、その場で聞く — 2つの型

このコードは何をしているか、行ごとに日本語で 説明してください。専門用語は避けてください。コード: 【分からない行の前後を貼る】

このコードの 【input type="number" の行】← ここを書き換え は何をしていますか? 備品申請フォームでこの部品が無いと何が困るかも教えてください。

まとめ

このテーマで身につけたのは、生成されたコードと付き合う読む力 です。

✓ できるようになったこと 確かめ方 ☑ コードを「書く」前に「読む」理由を言える 監督の確認に必要、の一言で説明する ☑ HTMLのルール4つを知っている タグ・入れ子・属性・インデントを挙げる ☑ フォームの部品5種を見つけられる form/label/select/input/button を拾い読みする ☑ JSを「きっかけ→仕事」で読める クリックイベントの処理の流れを言う ☑ 分からない行をAIに聞ける 型1・型2のプロンプトを1回ずつ使う

このテーマの核心 — 3つだけ

• 読むは書くより簡単。部品の名前と流れだけ掴む
• HTML=部品の羅列、JS=きっかけと仕事。2つの型で大半は読める
• 分からないは聞けばいい。コメント付き生成が教材になる

次のテーマ — 観察演習

• ここまでの3要素・コード読解を、実在のサービスの解剖 で試します
• ワークシートを埋めて、予想をAIに検証します
• 持ち物: 講座01・P8の観察ワークシート（未記入でOK）です

このテーマのゴール

知識を実地に変える — 1つのサービスを解剖し切る 講座01の観察ワークシートは、埋めてこそ設計の材料になります。このテーマは演習です。対象のサービスを1つ選び、5観点のワークシートを完走させ、自分の予想をAIに検証してもらいます。「知っている」が「観察できる」に変わる45分です。

週1以上使う、画面が複数ある、入力する場面がある — 3条件で対象を1つ決めます。社内システムが最適 です。 画面・入力・表示・処理・データの5観点を、触りながら記入します。正解ではなく予想 を書くのがルールです。 予想をAIに渡して、保存されているデータと動いている処理を推論してもらい、ズレを読み取ります。

🎯 演習の合格条件

あなたが選んだサービス1件ぶんのワークシートが埋まり、AIとの検証を1往復終えていること。きれいな正解を書く必要はありません。埋まったワークシートは、企画の講座（ai-service-planning）で自分の課題を扱うときの型になります。

このテーマの流れ

P テーマ 身につけること P3 対象の選び方 3条件での選定、避けるべき対象 P4〜5 ワークシートとAI検証 5観点の記入、予想の検証、ズレの読み方 P6 まとめ チェックリスト、次テーマへの接続

対象の選び方 — 3条件で決める

解剖に最適なのは「業務で使っている、動きのあるシステム」です。まず3条件で候補を絞ります。

◯ 向いている対象

• 社内の申請系システム — 経費精算・勤怠入力・備品購入など
• 毎週使う業務ツール — シフト閲覧、社内受付、図書借り出し
• 画面が3つ以上 あり、入力する場面があるもの

✕ 避けるべき対象

• ログイン前の静的なページ（会社サイトなど）— 動きが無く解剖できない
• 他人の個人情報が見える画面 — 観察の目的を超えるためNG
• 使ったことがないシステム — 業務知識が無いと予想が立てられない

選定チェック — 4問に全部「はい」の対象を1つ

✓ 問い 「いいえ」なら 1 週に1回以上使っているか? 観察の機会が足りない。別の対象へ 2 画面が3つ以上あるか? 3要素が確認しにくい。それでも余地があれば継続可 3 自分が入力する場面があるか? データの入り口が観察できない。参照専用なら別の対象へ 4 記録が残る予想がつくか? 残らないならサービスではなくページの可能性大

💡 なぜ社内システムが最適か

業務を知っている＝裏側の予想が立てられる からです。コンシューマー向けサービスも解剖できますが、業務知識が無いとAI検証との往復が浅くなります。まずは自分の業務で。

⏱ 決めきれないとき

候補2つで迷うなら、スコア（頻度×手間×影響）が高い方 を選びます。企画の講座で自分の課題に取り組むとき、そのまま材料になります。

対象は完璧に選ばなくていい。3条件を通過して「説明できる」ものなら何でも演習になります。迷ったら経費精算か勤怠入力 — ほぼすべての会社にあり、画面・入力・記録が揃っています。

ワークシート — 5観点を埋める

対象を実際に触りながら、次の5行を埋めます。正解を調べる必要はありません。自分の予想として書き切ることが演習です。

（名前を付けて列挙。例: 申請入力、申請一覧、承認、月次結果 の4画面） （画面ごとに。例: 申請入力…日付・金額・科目・摘要・添付） （入力しない画面。例: 一覧と月次結果は参照専用） （例: 上限チェック、承認の回し方、月末の締め処理） （例: 申請1件ごとの明細、承認履歴、確定済み実績）

進め方 — 3ステップ

STEP 1 — 触りながら拾う

画面を開き、クリックできる場所を全部押す。遷移したら新画面として①に追加。まず操作の地図を作ります。

STEP 2 — 入力と表示を分ける

各画面で入力するか、見るだけか を分類。入力項目は②に、参照画面は③に書き出します。

STEP 3 — 予想に根拠を付ける

④⑤は予想＋根拠1行。「月末に締めがあると思う。翌月1日に前月が見えなくなるから」のように書きます。

解説資料やマニュアルを読んでから書くのはNG。触った観察だけで書く ことには意味があります — あなたの観察力と、後のAI検証のズレこそが教材になるからです。

ワークシートの価値は「正しさ」ではなく*「自分の予想が言語化された状態」*。この5行があるだけで、次ページのAI検証が具体的な質問になり、講座02（企画）での課題選定が一瞬で終わります。

予想をAIに検証させる

ワークシートをAIに渡して、裏側の推論をしてもらいます。AIはあなたの観察結果から*「この画面なら裏でこう動いているはず」* を導ける道具です。

私は社内の【経費精算システム】← 対象名を書き換え を観察しました。結果は次のとおりです。\ ① 画面: 【入力・一覧・承認・月次結果の4つ等】\ ② 入力項目: 【日付・金額・科目・摘要等】\ ③ 参照専用画面: 【一覧と月次結果等】\ ④ 処理の予想: 【上限チェック、月末締め等＋根拠】\ ⑤ データの予想: 【申請明細、承認履歴等】\ この観察から、裏で保存されているデータと動いている処理を、3要素（画面・処理・データ）に分けて推論してください。私の予想④⑤の正誤も判定し、外れていれば正しい姿を教えてください。

検証結果のズレの読み方 — 3パターン

一致 — 観察の精度

AIの推論と自分の予想が同じなら、観察が正確 だった証拠。この調子で講座02の課題選定に進めます。

AIが深い — 見落とし

AIの推論に自分が書けなかった処理があれば、見落としを拾えた。なぜ見落としたか（触っていない操作など）を1行メモします。

自分が詳しい — AIの推論ミス

業務の実態はあなたの方が正しい こともあります。「実は承認は2段階です」と伝えて推論をやり直させれば、AIの精度も上がります。

🔁 往復は2回まで

推論→修正→再推論を2往復 程度で切り上げます。完璧な裏側の再現が目的ではなく、「予想を持って検証する型」を体に入れることが目的です。

💾 記録の残し方

ワークシートの④⑤に検証結果を色ペンで追記。「予想→正解」が1枚に残ると、講座02で同じ型を回すときの比較材料になります。

検証で大事なのは「誰が正しいか」ではなく、業務知識はあなたにあり、AIは推論の相手だ と実感すること。監督としての自信は、この往復から育ちます。

まとめ

このテーマで身につけたのは、観察を1人で完走する手順 です。

✓ できるようになったこと 確かめ方 ☑ 3条件で解剖対象を選べる 候補を4問のチェックに通せる ☑ 5観点のワークシートを埋められる 触るだけで予想を言語化できる ☑ 予想に根拠を付けられる ④⑤に「〜だから」を1行添えられる ☑ AIに検証を依頼できる 観察検証プロンプトを1往復使った ☑ ズレの3パターンを読み取れる 一致・見落とし・推論ミスへの対処を言える

このテーマの核心 — 3つだけ

• 観察は予想を書き切ること。正解を調べない
• 検証はAIの推論との往復。2往復で十分
• 業務知識はあなたが正しい。ズレは敵ではなく教材

次のテーマ — データの基礎

• 観察で見えた「⑤ 保存されていそうな記録」を設計する側 に回ります
• 表・型・キーの3つの考え方を学びます
• 持ち物: 埋まったワークシート（④⑤に検証結果の追記があると尚良し）です

このテーマのゴール

「データ」を自分でデザインする最初の一歩 3要素のうち「データ」は、サービスの価値を決める土台です。このテーマでは、データベースを難しい仕組みとしてではなく、ルールが1つだけの表 として扱います。備品申請の6項目に「型」を付け、「記録の形」を自分で設計できるようになります。この感覚が、講座02の企画から先の設計まで通じる土台です。

1行=1件の記録、1列=1つの項目。このたった2つの約束 で、バラバラの連絡が集計できる形になります。 項目ごとに「文字列・数値・日付・選択肢」を決めます。型が集計できるかどうか を決めます。 1件ごとの背番号。同名の申請を区別し、履歴が積もる 仕組みの正体です。

🎯 走る例 — 備品申請の6項目を「記録」にする

申請日・品名・個数・理由・希望日・状況の6項目を、集計できる表の形 に落とし込みます。「月末集計が30分」の完了条件を支えるのは、画面ではなくこの表の設計です。

このテーマの流れ

P テーマ 身につけること P3 データベースは「整列された表」 1行1件の原則、エクセルの表との違い P4 項目に「型」を付ける 型の種類、6項目の型付け、自由記述 vs 選択肢 P5〜6 キーとまとめ IDの役割、AIとのデータ壁打ち、チェックリスト

データベースは「整列された表」

データベースという言葉は難しく聞こえますが、中身はルールが1つだけの表 です。普段のエクセルと何が違うかを見れば、正体が掴めます。

エクセルの表との違い

観点 📊 エクセルの表 🗄 データベースの表 1行の意味 決まりなし（何でも） 1件の記録（申請1件ぶん） 1列の意味 決まりなし 1つの項目（品名など） 並び順 見た目の並びが情報 保存順に意味なし（表示時に並べ替え） 集計 手で式を入れる 必要なときに自動計算

備品申請の「申請データ」を表にする

ID 申請日 品名 個数 状況 1 4/3 ノートPC 2 承認済み 2 4/5 チェア 1 承認済み 3 4/5 ノートPC 1 未承認

1行が「申請1件」。月末の集計は、この表の「個数」列を品名ごとに足すだけ — 計算ではなく「数える」作業 になります。

📄 紙の申請書との違い

紙は「1枚=1件」だが並べ替えも集計も手作業。表にすると、同じ1件ぶんの記録が数えるだけで処理できる 形になる。

📤 保存順に意味がない理由

表示するときに「新着順」「品名順」へ並べ替えて見せる ため。保存は1つのルールで、見せ方は画面ごとに変えられます。

🔍 観察との接続

前テーマのワークシート⑤「保存されていそうな記録」は、まさにこの表の列 の予想でした。

「1行=1件・1列=1項目」— この2つの約束を守るだけで、紙・メール・口頭に散っていた連絡が集計できる記録 になります。「実態が見えない」という備品申請の差分は、ここから解消されます。

項目に「型」を付ける

表の列を決めたら、次は各項目の型 — 「どんな種類の値が入るか」を決めます。型は入力ミスを防ぎ、集計できるかどうか を分けます。

型は5種類だけ

型 入るもの 備品申請での例 文字列 短い自由文 理由（「腰痛のため」など） 数値 数字（計算対象） 個数 日付 日付（期間計算が効く） 申請日・希望日 選択肢 あらかじめ決めた候補 品名・状況 真偽 はい/いいえ 「発注済みか」のフラグ

数値と「数字の文字列」の違いに注意 — 電話番号のように計算しない数字は文字列 にします。個数は計算するので数値です。

6項目の型付け — 走る例の完成形

項目 型 理由 申請日 日付 月次集計の軸になる 品名 選択肢 表記ブレを防ぎ、集計を安定させる 個数 数値 発注数の合算に使う 理由 文字列 承認判断の材料（短く運用） 希望日 日付 発注タイミングの判定 状況 選択肢 未承認/承認済みの絞り込み

この型付けは、講座02の企画（v1のIN）で決めた6項目と1対1で対応します。企画→データ設計が一直線に繋がる例です。

自由記述 vs 選択肢 — 集計性の分かれ目

品名は「詳しく書いてもらう」ため自由入力にする 品名はプルダウン10品目から選ぶ（要望は別途の自由欄で受け付ける） 自由入力は「PC」「パソコン」で別物扱いになり集計不能

理由を長文自由記述の必須にする 理由は2行程度の文字列（任意）。承認判断に足りなければ口頭確認 長文必須は申請者の負担になり、書かせる意味も薄い

型の判断基準は「集計するか・絞り込むか」。するなら選択肢・数値・日付。しないなら文字列。自由度は誰かの仕事になる（講座02の「めんどう」の原則）— データ設計にも同じ原則が効いています。

キーとID — なぜ連番を振るのか

表の左端に置く「ID」。たった1列ですが、履歴が積もる仕組み の正体です。

ID 申請日 部署 品名 個数 何が起きているか 1 4/3 営業部 ノートPC 2 — 最初の申請 2 4/5 経理部 チェア 1 — 別の申請 3 4/5 営業部 ノートPC 1 — 営業部の2回目。1件目とは別物

🔍 区別できる

部署名も品名も同じ申請が続いても、IDが違えば別の1件。「先週のあの申請」を指差せます。

📚 履歴が積もる

1件消さずに追記していくから、月が変わっても昨月の実績が残る。予算計画の材料になります。

🔄 状況を更新できる

「ID=3の状況を承認済みにする」のように、特定の1件だけ を正しく更新できます。

データ設計もAIと壁打ちする

表・型・キーが決まったら、AIに穴を突かせます。企画の壁打ちと同じ型です。

備品申請のデータ項目を、次の表として設計しました。【ID/申請日/品名(選択肢10種)/個数(数値)/理由(文字列)/希望日(日付)/状況(選択肢)】← 自分の設計に書き換え\ 月別・品目別の集計 と 履歴の管理 という目的に対して、欠けている項目・型の問題・運用で壊れそうな箇所を、質問形式で 指摘してください。

よく飛んでくる指摘の例

指摘 直し方 申請者は誰? 部署名の列を追加（個人名は入れない） 取り下げは? 状況の選択肢に「取下げ」を追加 過不足の訂正は? 編集で上書きせず履歴を残す設計に（v2検討）

指摘に全部応える必要はありません。判断して記録に残す — 監督の仕事です。

IDとは「1件ごとの背番号」です。これがあるから「あの申請、どうなった?」に答えられ、履歴が積もります。表・型・IDの3つ — これが「データ」要素の設計に必要な知識のほぼ全部です。

まとめ — 講座「前提知識」の総括

このテーマで講座「Webサービスを作る上での前提知識」が完結します。

✓ できるようになったこと 確かめ方 ☑ データベースを「表」として説明できる 1行1件・1列1項目の約束を言う ☑ エクセルの表との違いを言える 保存順に意味がない・集計は自動、を挙げる ☑ 5種類の型を使い分けられる 6項目に型を付け、理由を言える ☑ 自由記述と選択肢を使い分けられる 集計する項目は選択肢にできる ☑ IDの役割を説明できる 区別・履歴・更新の3つを挙げる ☑ データ設計をAIに壁打ちできる 設計表を渡して指摘を1往復もらった

この講座（全5テーマ）で得たもの

1. 01 サービスの正体 — 3要素とクリックの裏側
2. 02 AI開発の全体像 — 相棒2人と環境3点、あなたは監督
3. 03 動くコードを読む — 部品と流れを読む力
4. 04 観察演習 — 予想を書き切り、AIと検証した
5. 05 データの基礎 — 表・型・IDで記録を設計する

次の講座 — 人に使ってもらうWebサービスをAIと企画する

• ここまでの知識（3要素・監督役・観察・データ）を土台に、企画 を仕上げます
• 3行メモから始まり、AIとの壁打ちで企画書まで落とします
• 持ち物: 観察ワークシート（04で完成）と、自分の課題の素振りです