「提出ボタンを押す」で何が起きるかを見取り図にする

原稿の管理表（13項目：記事ID・カテゴリ・要件ID・先に読むと理解しやすい記事・成果物パス・対象ツール・検証状況・最終更新日など）

管理項目	内容
記事ID	00-01
主な中カテゴリ	00-01 アプリが動く仕組みをつかむ
関連中カテゴリ	00-02、00-03
関連要件ID	—
先に読むと理解しやすい記事	なし（入口の記事）
到達目標	利用者・画面・処理・保存先・通信の5つの登場人物と、操作から応答までの流れを自分の言葉で説明できる。ブラウザ・サーバー・APIの語に意味と例を添えて使える
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/00-01-app-overview_template.md、templates/00-01-app-overview_example.md
出典	第11節参照
対象ツール・バージョン	特定ツールに依存しない
検証状況	本文・ひな形・記入例はClaude Codeが作成。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成。同日、Phase 5B-1：Concept型のPilotとして、読む順路・第3.3節「AI時代に変わること・変わらないこと」・第4節「判断すること」を追加。見取り図・完了条件・成果物は不変）

この記事の会社・人物・アプリはすべて架空の設定です。実在する会社や案件とは関係ありません。

この記事は何の話か。依頼・承認管理アプリで「提出ボタンを押す」という1つの操作が、パソコンの中でどんな順番で処理されるかを、見取り図にする話です。システム開発とは、この見取り図に出てくる部品（画面・処理・保存先）を「誰が何をできるか」の約束どおりに作り、本当にそう動くかを確かめて、使い続けられる状態まで育てる仕事のことです。

なぜ必要か。「画面」「サーバー」「データベース」といった言葉を聞いたことがあっても、それぞれが何をしていて、どうつながっているかが分からないと、この先の記事（設計・実装・検証）で「今どの部分の話をしているか」が分からなくなります。また、AIがコードを書く時代になっても、この見取り図の部品と流れは変わりません。変わるのは「誰が作るか」であって、「何を決め、何を確かめるか」ではありません。

この記事を読むとできるようになること。

• 利用者・画面・処理・保存先・通信の5つの登場人物と、操作から応答までの流れを説明できる
• ブラウザ・サーバー・APIという言葉に、意味と具体例を添えて使える
• 「提出ボタンを押す」という操作の見取り図を自分で描き、AIに任せる部分と人が決める部分を言える

読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。

• 基本だけ理解する：第1節→第3.1節（5つの登場人物）→第5.2節（見取り図）→第9節。ここまでで、この先の記事に出てくる「画面」「処理」「保存先」が全体のどこを指すかが分かり、自分の業務の操作を1つ図にできます。
• 作って確かめる：上に加えて第3.3節（AI時代に変わること・変わらないこと）→第4節（見取り図を描くときに判断すること）→第6〜7節（描き間違えやすい点と、この図の限界）。
• 設計判断を深める：上に加えて第8節（判定をどこに置くかという、後の工程へ持ち越す論点）。

1. 今回の業務課題と完成するもの

この記事でやることは、依頼・承認管理アプリで依頼者が「提出」ボタンを押したときに、パソコンの中で何が起きるかを、5つの登場人物を使って一巡の見取り図に書くことです。

架空企業「みらい業務サービス」の総務部門では、会議室の機材手配や名刺の発注といった依頼が、メールとチャットに分かれて届いています。この教材では、その依頼を「下書き→提出済み→差戻し／承認済み」という4つの状態で管理するアプリを、企画から運用まで通して作ります。依頼者の佐藤さんが依頼を書いて「提出」を押し、承認者の鈴木さんがそれを承認する、というのが基本の操作です。

これから02〜13の記事で「画面を作る」「保存先を決める」「処理を検証する」といった話が出てきますが、それぞれが全体のどこに当たるかが分かっていないと、話がばらばらに見えてしまいます。この記事は、そのための共通の地図を作ります。工程（作業の順番）の地図は00-03で作ります。この記事はアプリの中身（部品と流れ）の地図です。

この記事を読み終えると、次のものが手元にできます。

• アプリの見取り図（登場人物、矢印の意味、提出操作1件の流れ）

2. 前提知識と読む順路

この記事はこの教材の入り口であり、前提となる記事はありません。この記事で使う言葉は、すべてこの記事の中で説明します。

先に「システム」と「アプリ」の2語だけ確認しておきます。

システム（アプリ）

一言でいうと、人の操作を受け取り、決められたルールで判断し、結果を残して返す仕組みです。

たとえば、佐藤さんが「提出」を押すと、依頼が「提出済み」として記録され、鈴木さんの一覧に現れる。これが仕組みの一巡です。

これがないと、依頼がメールとチャットに散らばり、「今どこまで進んだか」を誰かが探し回ることになります（01-02で扱う困り事です）。

システム開発では、業務用に作るこの仕組みをアプリケーション（application、略してアプリ）と呼びます。この教材では「アプリ」と「システム」を同じ意味で使います。

読む順路：この見取り図は、00-02（ファイル・コード・データを区別する）、00-03（企画から運用までの全体像を知る）で繰り返し使う共通の図になります。

3. 理解する：5つの登場人物

3.1 誰が・何が関わるか

依頼・承認管理アプリが動くとき、次の5つが関わります。

ブラウザ

一言でいうと、利用者が画面を見て操作するためのアプリです。たとえば、依頼者が普段使っているインターネットを見るアプリが、依頼作成画面を表示する役割も果たします。

これがないと、利用者は画面を見ることも操作することもできません。

サーバー

一言でいうと、利用者から離れた場所で、処理や保存を行うコンピュータです。たとえば、佐藤さんが提出ボタンを押すと、その内容は佐藤さんのパソコンの外にあるサーバーへ送られ、そこで判断や保存が行われます。

これがないと、複数の利用者（依頼者・承認者・運用管理者）が同じ依頼のデータを共有できません。

API（連携の約束）

一言でいうと、画面（ブラウザ側）とサーバー側が「何を、どんな形でやり取りするか」をあらかじめ決めた約束です。たとえば、「提出ボタンを押したら、依頼のIDと内容をこの形式で送る」という約束がAPIです。

これがないと、画面側とサーバー側で、送る内容の形がバラバラになり、正しく伝わりません。

システム開発では、この5つの登場人物と、ブラウザ・サーバー・APIという言葉が、これから読むほぼすべての記事で登場します。

3.2 よくある誤解

「画面（ブラウザ）がすべてを処理している」。画面は入力を受け取って表示するだけで、実際の判断（承認してよいかなど）や保存は、画面の外側（サーバー・保存先）で行われます。

「保存先はどこか1つのファイルのようなもの」。保存先は、依頼・利用者・履歴といった複数の種類のデータを整理して持つ仕組みです（05-01で詳しく扱います）。

「通信は一瞬で終わるので、失敗を考えなくてよい」。通信の途中で失敗することがあり、失敗した場合にどう扱うかは08-03・08-04で設計します。

3.3 AI時代に変わること・変わらないこと

結論から言うと、AIがコードを書けるようになっても、この見取り図の部品と流れは変わりません。変わるのは「部品を作る作業の速さと担い手」です。

佐藤さんの「提出」が正しく処理されるには、誰かが次のことを決めていなければなりません。件名が空の依頼を提出できてよいか。承認者は依頼ごとに1人か。自分の依頼を自分で承認してよいか。これらは業務の約束であり、AIは「一般的にはこうです」と候補を出せても、この会社の決定はできません。決めた約束どおりに動くかを確かめるのも、約束を知っている人の仕事です。

つまり、「AIがコードを書く」ことと「システム開発ができる」ことは別です。コードは見取り図の部品の1つにすぎず、部品を何のためにどう並べ、どう確かめるかを決める仕事は残ります。この教材の01〜13は、その残る仕事を工程ごとに扱います。

4. 判断すること

見取り図は「描けばよい」ものではなく、描く前に3つの判断があります。

4.1 この記事で判断すること

4.2 勝手に決めてはいけないこと

• この記事では、画面の具体的なデザインや、保存先の具体的な種類（データベースの製品名など）を決めません。それらは04・05・03-03で扱います。
• 登場人物の名前（利用者・画面・通信・処理・保存先）は、この記事とdocs/CONTENT_MAP.mdで使う共通の呼び方であり、この記事で新しい名前に変えません。
• 「提出できる条件」（件名が必須か、承認者を必ず選ぶか）は、この記事では図の説明のために仮に置いているだけで、正式には記事Aの要件で決めます。

4.3 AIに任せる範囲

この記事の作業で、AIに任せてよいのは次のことです。

• 「画面・処理・保存先」の一般的な説明や、見取り図のたたき台を作ること
• 自分の業務の操作を1つ伝えて、5つの登場人物に当てはめた案を出させること

任せてはいけないのは、「自分の業務では、どの操作を最初に図にすべきか」「その業務で人が見て触っているものはどれか」の判断です。AIはその業務を見ていません。たたき台をもらったら、第4.1節の3つの判断を自分で確かめてから使います。

5. 作って確かめる：見取り図を描く

5.1 準備

依頼・承認管理アプリの題材（依頼者・承認者・運用管理者という役割があること）を確認します。役割の一覧は記事Aにあります。

5.2 アプリの見取り図

「依頼者が提出ボタンを押す」という1件の操作を、5つの登場人物の間でたどります。

① 利用者（依頼者）が画面で「提出」ボタンを押す
     │
     ▼
② 画面（ブラウザ）が、入力された件名・内容・承認者を、決められた形（API）で送る
     │  ─── 通信 ───▶
     ▼
③ 処理（サーバー側）が、必須項目がそろっているかなど確認する
     │
     ▼
④ 処理が、保存先に「状態を提出済みに変える」よう指示する
     │
     ▼
⑤ 保存先が、依頼の状態を書き換える
     │
     ▼（応答が逆向きに戻る）
② 画面が、「提出しました」という結果を利用者に表示する

矢印の意味：実線の矢印は「情報が渡る向き」を表します。①→⑤まで進んだあと、結果が②まで戻ってくることで、利用者は「提出できたかどうか」を知ります。

③で「確認する」と書いた部分が、第4.1節の3つ目の判断（判定をどこに置くか）に当たります。この図では処理側に置いていますが、画面側でも保存先側でも確認はできます。どこで確認するかで守れることが変わる、という論点は第8.1節へ持ち越します。

5.3 完了条件との照合

この見取り図は、実際に動くアプリを観測したものではなく、この記事のための説明用の図です。実際の実装は08以降で扱います。この図の③〜⑤に当たる処理と保存先を、実際にローカル通信で動かして観測した記録は08-03にあります。

6. よくある勘違いと直し方

見取り図を初めて描くとき、次のような勘違いが起こりがちです。

• 画面から保存先へ直接矢印を引いてしまう。実際には、画面は処理を経由して保存先とやり取りします。画面が直接データを書き換えることはありません。
• 「提出」で終わりだと思ってしまう。提出のあと、結果が利用者に返る（応答）までが1件の操作です。応答が無いと、利用者は結果が分かりません。
• AIに描かせた図をそのまま自分の業務の図にしてしまう。AIの図は一般的なアプリの形です。自分の業務で「人が見て触っているもの」「判断しているもの」「覚えておくもの」を、第4.1節の対応で確かめてから使います。

7. 確認結果

第5.2節の見取り図を、実際のアプリ実装（08以降）で確かめる工程はまだ先です。この記事の時点では、見取り図が完了条件を満たしているかどうかの照合（第5.3節）までを行っています。

残る制限：この見取り図は、実際に動くコードを観測して作ったものではなく、教材として理解のために描いた説明図です。実際の実装で同じ流れになるかは、08以降で確認します。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 判定をどこで行うか（画面側・処理側・保存先側）

この段階では、まだ実装がないため、どこで判定するかを確定させません。04-02・05-03で改めて具体的に判断します。ここでは「複数の場所で判定できる」という論点があることだけを持ち越します。3つの場所を実際に比較した結果は記事Bにあります。

8.2 適用限界

この見取り図は、依頼・承認管理アプリの「提出」という1つの操作を単純化して示したものです。実際にはエラー処理や同時操作など、この記事では扱わない複雑さがあります。それらは05-02・08-03・08-04で扱います。

9. 持ち帰る成果物

自分の業務に使うときの手順は次のとおりです。

1. 自分の業務アプリに関わる人・画面・処理・保存先を挙げる
2. よく行われる操作を1つ選ぶ（第4.1節）
3. その操作が、利用者から始まり、画面・処理・保存先を経て、利用者に結果が返るまでの流れを図にする
4. 「どこで判定するか」は決めずに、論点として書き残す

10. 次工程への受渡し

次へ渡すもの：アプリの見取り図（5つの登場人物、提出操作の一巡の流れ）、持ち越す論点（判定をどこに置くか）。

次工程での使われ方：00-02（ファイル・コード・データを区別する）では、この見取り図の「処理」「保存先」が具体的に何のファイルやデータでできているかを扱います。00-03（企画から運用までの全体像を知る）では、この見取り図を工程全体の地図に位置づけます。00-04では、第3.3節の「変わらないこと」を人とAIの役割表として決めます。

前工程へ戻る条件：この記事は入口の記事のため、前工程はありません。

11. 根拠と更新情報

• この記事の会社・人物・アプリの動きはすべて架空の設定です。
• 5つの登場人物（利用者・画面・通信・処理・保存先）とブラウザ・サーバー・APIの説明は、教材設計書AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第4.1節の基礎テーマ配置に基づきます。
• 第3.3節の「AIがコードを書けても、決めることと確かめることは人に残る」という整理は、docs/content/LEARNING_UNIT_SPEC_V1.md第6節（人とAIの責任分界）に基づきます。
• 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
• 2026-09-20（Phase 5B-1）：Concept型のPilotとして、読む順路（3つの深さ）、第2節の「システム（アプリ）」の用語説明、第3.3節「AI時代に変わること・変わらないこと」、第4節の判断項目（判断すること・仮置き可否・間違えた場合の影響・AIに任せる範囲）、記事間の参照を追加した。見取り図・完了条件・成果物は変えていない。
• 未確認事項：この見取り図が実際の実装（08以降）と一致するかは、この記事の時点では確認していません。