データ・システム構成の設計学習記事全11節Design
依頼・利用者・履歴のデータ項目と関係を決める
この記事で身につくこと識別子・型・必須項目・重複・データ同士の関係・検索の観点を、依頼・利用者・履歴のデータで説明できる。履歴を依頼の中に持つ案と別データにする案を、検索・整合性・変更容易性から比較して選定理由を書ける。
記事内目次（27項目）
この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。04-02で作った画面の項目をもとに、アプリが保存するデータ（依頼・利用者・履歴）の項目と、データ同士の関係を決める話です。
なぜ必要か。画面の項目だけを決めて、保存するデータの形を決めずに進めると、同じ情報を重複して持ってしまったり、後から「この情報とあの情報はどうつながっているか」が分からなくなったりします。
この記事を読むとできるようになること。
- 識別子・型・必須項目・重複・データ同士の関係・検索の観点を、依頼・利用者・履歴のデータで説明できる
- 依頼・利用者・履歴の3つのデータ項目表と関係図を作れる
- 履歴を依頼の中に持つ案と別データにする案を、検索・整合性・変更容易性から比較して選定理由を書ける
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「3つのデータと関係」が分かり、ひな形を埋め始められます。
- 作って確かめる：上に加えて第5.3節（AIへの依頼）→第6節（失敗例と直し方）→第7節。
- 設計判断を深める：上に加えて第8節（履歴の持ち方の比較、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、04-02で作った画面の項目をもとに、アプリが保存するデータ（依頼・利用者・履歴）の項目表と、データ同士の関係図を作ることです。
画面に何を表示するかが決まっても、その情報をどんな形で保存するかはまだ決まっていません。この記事では、それをデータ項目表・関係図として決めます。
この記事を読み終えると、次のものが手元にできます。
- 依頼・利用者・履歴のデータ項目表（データ名、項目、型、必須、識別子、関係、検索の観点）
- 3つのデータの関係図（多重度つき）
- 履歴の持ち方（依頼の中か、別データか）の選定理由
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。基礎用語（識別子・型・データベース）は、まだ独立した記事がないため、ここで平易に説明します。
識別子
一言でいうと、たくさんあるデータの中から、1件を間違いなく指し示すための番号や記号です。たとえば、依頼が100件あっても、依頼ID「REQ-0031」と言えば、その1件だけを指せます。
これがないと、「件名が同じ依頼」が複数あったときに、どちらの依頼の話をしているか区別できません。
型
一言でいうと、その項目にどんな種類の値が入るかの決まりです。たとえば、「件名」は文字列、「提出日」は日付、というように決めます。
これがないと、日付の欄に文字が入ってしまうなど、後で扱いに困るデータが紛れ込みます。
必須項目
一言でいうと、必ず値が入っていないといけない項目です。04-02の画面の原型で「必須」とした項目（件名、内容、承認者）が、そのままデータの必須項目になります。
重複
一言でいうと、同じ内容のデータが誤って2つ以上できてしまうことです。たとえば、同じ依頼が二重に保存されると、一覧に同じ件名が2つ表示され、どちらが本物か分からなくなります。
データ同士の関係
一言でいうと、あるデータが別のデータとどうつながっているかです。たとえば、1件の依頼には1件の履歴だけでなく、複数の履歴（提出、承認など）がつながります。この「1件に対して複数」というつながり方を多重度と呼びます。
検索の観点
一言でいうと、後で「どんな条件で探すことが多いか」という視点です。たとえば、一覧画面で「状態で絞り込む」（04-02）ができるためには、依頼の状態で検索できる必要があります。
データベース
一言でいうと、データを整理して保存し、後から探したり更新したりできるようにする仕組みです。たとえば、依頼・利用者・履歴をそれぞれ表（テーブル）のような形で保存し、必要な条件で取り出せるようにします。
これがないと、大量の依頼を1つのファイルにただ書き足すだけになり、特定の依頼を探すのに時間がかかったり、同時に複数人が更新すると内容が壊れたりします。
SQL
一言でいうと、データベースに対して「この条件のデータを探して」「この項目を更新して」と指示するための、決まった書き方の言語です。たとえば、「状態が『提出済み』の依頼を探す」という指示をSQLで書けます。
システム開発では、データベースとSQLは、03-03で選ぶ保存先の技術と結びついて使われます。この記事では、具体的なSQLの文は扱わず、「何を探せるようにしておく必要があるか」（検索の観点）までを決めます。
読む順路：画面の項目は04-02が該当します。この関係図をもとにした状態遷移・更新ルールの設計は05-02が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。
3. 理解する：なぜデータの形を先に決めるか
3.1 画面の項目とデータの項目は同じではない
04-02の画面には「承認者」という入力項目がありました。この項目は、データとしては「利用者の中の1人を指す」という関係として保存します。画面の項目をそのままデータの項目にすると、次のような問題が起きます。
| そのままにした場合 | データとして整理した場合 |
|---|---|
| 承認者の氏名を依頼データに直接書き込む | 承認者は利用者データへの関係として持ち、氏名の変更があっても依頼データを書き換えずに済む |
| 履歴を件名などと一緒に1つの欄にまとめて書く | 履歴を、誰が・いつ・何をしたかが分かる項目に分けて保存する |
3.2 3つのデータ：引き継ぐ業務情報と、この記事で設計するもの
この記事の項目には、記事Aから引き継ぐ業務情報と、05-01で新たにデータ設計として決めるものが混ざっています。混同しないよう、先に分けて示します。
A. 前工程（記事A）から引き継ぐ業務情報
| データ | 引き継ぐ内容 |
|---|---|
| 依頼 | ID、依頼者、件名、内容、状態、承認者 |
| 履歴 | 依頼に対して、誰が・いつ・何をしたかを残すこと（操作、操作者、時刻） |
B. この記事（05-01）でデータ設計として決めるもの
CONTENT_MAP 05-01の完了条件（3データに識別子がある、関係図に多重度がある）を満たすために、この記事で新しく追加・設計する項目です。記事Aで確認済みの業務情報ではありません。
| 項目 | 追加する理由 |
|---|---|
| 履歴ID（識別子） | 履歴の1件を特定できるようにするため |
| 利用者データ（ID、氏名、担当できる役割） | 記事Aは「データは依頼と履歴の2つ」としており、利用者を独立したデータにするかは決めていません。依頼者・承認者を人として一意に識別し、氏名の変更等に強くするため、この記事で利用者データを設計します |
| データ同士の関係・多重度 | 依頼・利用者・履歴がどうつながるかを明確にするため |
| 検索の観点 | 04-02の画面（状態で絞り込むなど）に必要な検索を洗い出すため |
記事Aで示されたとおり、同じ人でも、自分が依頼を出すときは依頼者、他人の依頼を承認するときは承認者になります。そのため、利用者データには「今どの役割か」ではなく「どの役割を担当できるか」を持たせます。
3.3 よくある誤解
「データの形は実装するときに考えればよい」。データの形を決めずに実装を始めると、後から「この項目が足りない」「同じ情報が2箇所にある」と分かり、作り直しになります。
「項目は多いほうが後で困らない」。使う予定のない項目を増やすと、必須かどうかの判断や、後からの変更が複雑になります。04-01・04-02で決めた範囲の項目に絞ります。
「履歴は依頼の一部だから、どちらに置いても同じ」。置き方によって、検索のしやすさや、後からの変更のしやすさが変わります（第8節で比較します）。
「AIにデータ設計を任せればよい」。AIは一般的なデータ項目の候補や関係図の下書きを提示できますが、この業務でどの項目が必要かは、04-01・04-02の内容に基づいて人が確認します（第4.3節）。
4. 判断すること
4.1 何を確認すればよいか
| 確認すること | この記事での扱い |
|---|---|
| 依頼・利用者・履歴の3データに、それぞれ識別子があるか | 第5.2節で確認する |
| データ同士の関係と多重度（1件に対して複数か）が分かるか | 第5.3節の関係図で確認する |
| 日付・時刻・文字コードの扱いが決まっているか | 第5.4節で確認する（教材上の仮定として明記） |
4.2 勝手に決めてはいけないこと
- 業務上の情報（何を依頼と呼ぶか、履歴に何を残すかなど）を、04-01・04-02・記事Aにないところで勝手に増やしません。ただし、識別子・関係・多重度・検索の観点など、CONTENT_MAP 05-01が要求するデータ設計上の項目は、この記事で追加し、追加した理由を明記します（第3.2節B）。
- 保存する形式（日付の表記、文字コードなど）を、確認していないのに確定した仕様であるかのように書きません。未確認・教材上の仮定として明記します。
- 記事Aで確認済みの業務情報（依頼のID・依頼者・件名・内容・状態・承認者、履歴が依頼に対して残ること・操作・操作者・時刻）を、この記事で変更しません。
4.3 AIに任せる範囲
一般的なデータ項目の候補や、関係図の下書きの提示はAIに任せられます。しかし、この業務で実際にどの項目が必要か、履歴をどちらの形で持つかは、04-01・04-02・記事Aの内容に基づいて人が判断します。
5. 作って確かめる：データ項目表と関係図を作る
5.1 準備
04-02の画面の原型、記事Aで確認済みの依頼・履歴の業務情報（第3.2節A）を用意します。
5.2 データ項目表
| データ名 | 項目 | 型 | 必須 | 識別子 | 関係 | 検索の観点 |
|---|---|---|---|---|---|---|
| 依頼 | ID | 識別子 | 必須 | ○ | — | IDで1件を特定する |
| 依頼 | 依頼者 | 利用者への関係 | 必須 | — | 利用者（1件の依頼につき1人） | 依頼者ごとに自分の依頼を検索する |
| 依頼 | 件名 | 文字列 | 必須 | — | — | 件名の一部で検索する |
| 依頼 | 内容 | 文字列（複数行） | 必須 | — | — | — |
| 依頼 | 状態 | 区分（下書き・提出済み・差戻し・承認済み） | 必須 | — | — | 状態で絞り込む（04-02の一覧画面） |
| 依頼 | 承認者 | 利用者への関係 | 必須 | — | 利用者（1件の依頼につき1人） | 承認者ごとに割当依頼を検索する |
| 利用者 | ID | 識別子 | 必須 | ○ | — | IDで1人を特定する |
| 利用者 | 氏名 | 文字列 | 必須 | — | — | 承認者選択欄（04-02）で氏名から探す |
| 利用者 | 担当できる役割 | 区分（依頼者／承認者／運用管理者、複数可） | 必須 | — | — | 承認者になれる利用者を絞り込む |
| 履歴 | ID | 識別子 | 必須 | ○ | — | IDで1件を特定する |
| 履歴 | 対象の依頼 | 依頼への関係 | 必須 | — | 依頼（1件の依頼につき複数の履歴） | 依頼ごとに履歴を時系列で検索する |
| 履歴 | 操作 | 区分（作成・提出・承認・差戻し・再提出） | 必須 | — | — | 操作の種類で検索する |
| 履歴 | 操作者 | 利用者への関係 | 必須 | — | 利用者（1件の履歴につき1人） | 操作者ごとに履歴を検索する |
| 履歴 | 時刻 | 日時 | 必須 | — | — | 期間で絞り込む |
| 履歴 | 備考（任意） | 文字列（任意） | 任意 | — | — | — |
履歴ID・利用者データ・関係・検索の観点は、第3.2節Bのとおり、この記事でデータ設計として追加したものです。履歴の「備考」は記事Aの確認済み項目ではなく、05-01が置いた設計例です。差戻し理由（REQ-004）を記録する場所として使うことを想定しており、05-02の状態遷移表で実際に使います。本文上どうしても必要な項目のため残していますが、確認済みの事実ではなく設計例として扱ってください。
5.3 関係図（多重度つき）
利用者 1 ──── 依頼者として 0..多 ── 依頼
利用者 1 ──── 承認者として 0..多 ── 依頼
依頼 1 ──── 0..多 ── 履歴
利用者 1 ──── 操作者として 0..多 ── 履歴読み方：利用者1人は、依頼者として0件以上の依頼を持てます（依頼を出したことがなければ0件）。1件の依頼には、履歴が0件以上つながります（作成直後はまだ履歴が無いこともあります）。
5.4 日付・時刻・文字コードの扱い（教材上の仮定）
| 項目 | この記事での扱い | 確認状況 |
|---|---|---|
| 日時の形式 | タイムゾーンを明記した形式で保存する（例：いつの時刻か分かる形） | 教材上の仮定（正本に指定なし。03-03で選ぶ保存先の技術と合わせて確定させる必要がある） |
| 文字コード | 日本語の件名・内容を扱うため、広く使われる文字コード（Unicode系）を前提とする | 教材上の仮定（正本に指定なし） |
これらは、実際の企業では技術選定（03-03）と合わせて確認・確定させる必要がある事項であり、この記事で確認済みの事実として扱っているわけではありません。
5.5 AIにデータ項目表の下書きを頼む
04-01・04-02・記事Aの内容をもとに、データ項目表の下書きをAIに作らせます。
依頼・承認管理アプリのデータ項目表を作りたいです。04-02の画面原型（件名・内容・承認者などの項目）と、記事Aで確認済みの業務情報（依頼のID・依頼者・件名・内容・状態・承認者、履歴が依頼に対して残ること・操作・操作者・時刻）を渡します。
依頼：
1. 依頼・利用者・履歴の3データについて、項目・型・必須・識別子・関係・検索の観点を表にしてください。識別子・関係・検索の観点は、この工程で新しく設計してよいものです。
2. データ同士の関係と多重度を図か文章で示してください。
してはいけないこと：
- 識別子・関係・検索の観点以外で、04-01・04-02・記事Aにない業務上の項目を追加しないでください。
- 日付の形式や文字コードなど、確認していない仕様を断定しないでください。教材上の仮定として示してください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。
- 依頼データに「承認者の氏名」を直接の文字列項目として追加していた（利用者への関係にすべきところ）
- 「日時はUTC（協定世界時）で保存します」と、確認していない仕様を断定的に記載
6.2 見つけ方と直し方
- 承認者を文字列にしている：第3.1節の考え方に反します。承認者を利用者への関係に修正します。
- 日時の仕様を断定している：正本に根拠がなく、確認もしていません。「教材上の仮定」に修正します。
指摘：
1. 承認者は氏名の文字列ではなく、利用者への関係にしてください。
2. 日時の保存形式を断定しないでください。「教材上の仮定」として示してください。
変えないこと：
- 04-01・04-02・記事Aの内容そのものは変更しないでください。6.3 修正後のデータ項目表
修正後のデータ項目表・関係図は、第5.2節・第5.3節のとおりです。
7. 確認結果
第5.2〜5.4節の内容を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 依頼・利用者・履歴の3データに識別子がある | 3データすべてにID（識別子）を記載 |
| 関係図に多重度（1件に対して複数か）が書かれている | 第5.3節の関係図に多重度を明記 |
| 日付・時刻・文字コードの扱いに注記がある | 第5.4節に教材上の仮定として明記 |
残る制限：このデータ項目表は架空の業務に基づく一例です。日時の形式・文字コードは教材上の仮定であり、正本に根拠のある確認済みの仕様ではありません。この記事の本文と記入例はClaude Codeが作成し、2026-09-20にユーザーによる実読でPASSしましたが、実際の業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 履歴を依頼の中に持つ案と、別データにする案
| 観点 | 依頼の中に持つ案 | 別データにする案（採用） |
|---|---|---|
| 検索 | 1件の依頼の履歴はすぐ見られるが、複数の依頼をまたいだ検索（操作者ごと、期間ごとなど）がしにくい | 履歴だけを対象に、操作者・期間などで横断的に検索できる |
| 整合性 | 依頼データの更新と履歴の追記が同じ場所になるため、単純ではある | 状態変更（依頼データ）と履歴追加（履歴データ）を1つのまとまりとして扱う必要があり、これは05-02で扱う設計課題になる（REQ-007） |
| 変更容易性 | 履歴の項目を後から増やすと、依頼データ全体の形が変わり、影響が広がりやすい | 履歴データだけを変更でき、依頼データへの影響を抑えられる |
REQ-005（操作の履歴を残す）とREQ-007（状態変更と履歴追加のどちらかだけが完了する状況を正常として扱わない）を踏まえると、履歴を独立したデータとして持ち、状態変更とセットで正しく完了させる、という設計が必要になります。この記事では、別データにする案を採用します。状態変更と履歴追加を1つのまとまりとして扱う具体的なルールは、05-02で設計します。
8.2 適用限界
このデータ項目表は、架空企業「みらい業務サービス」の小規模な依頼・承認管理を前提にしています。利用者数や履歴の件数が大きく増える場合、検索を速くするための工夫（04以降の記事の範囲外）が別途必要になることがあります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| データ項目表・関係図ひな形（データ名、項目、型、必須、識別子、関係、検索の観点） | templates/05-01-data-model_template.md | templates/05-01-data-model_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（画面の原型、業務要件で確認済みの項目）を用意する
- 画面の項目を、データの項目（文字列・数値・関係など）に分ける
- 各データに識別子を置く
- データ同士の関係と多重度を図にする
- 日付・時刻・文字コードなど、確認していない仕様は教材上の仮定として明記する
10. 次工程への受渡し
次へ渡すもの：データ項目表・関係図、履歴を別データにするという選定理由。
次工程での使われ方：05-02（保存・更新・整合性のルールを決める）では、この関係図をもとに、状態変更と履歴追加を1つのまとまりとして扱うルールを設計します。
前工程へ戻る条件：データ項目表を作る中で、04-01・04-02にない項目が必要だと分かったら、04-01・04-02に戻って見直します。
11. 根拠と更新情報
- この記事の会社・人物・データ項目はすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 記事Aで確認済みの業務情報は、依頼のID・依頼者・件名・内容・状態・承認者、および履歴が依頼に対して残ること・操作・操作者・時刻です（第3.2節A）。履歴ID・利用者データ・データ同士の関係・多重度・検索の観点は、記事Aの確認済み事項ではなく、CONTENT_MAP 05-01の完了条件に基づき、この記事でデータ設計として追加したものです（第3.2節B）。履歴の「備考」も記事Aの確認済み項目ではなく、この記事が置いた設計例です。
- REQ-001（識別子）・REQ-005（履歴）・REQ-007（状態変更と履歴追加の一体性）は、教材設計書
AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.4節に基づきます。 - 教材上の仮定：日時の保存形式・文字コードは、正本に指定がなく、この記事が演習のために置いた仮定です。
- 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。作成時点（2026-09-20）では人による実読・内容確認は未実施でした。
- 更新履歴：2026-09-20、ユーザーレビューにより、履歴ID・利用者データ・関係・多重度・検索の観点・履歴の備考を「記事Aで確認済み」としていた記述を、「CONTENT_MAP 05-01が要求するデータ設計としてこの記事で追加したもの」に訂正しました。
- 更新履歴：2026-09-20、ユーザーによる実読でPASS。本文・データ項目・区分は変更していません。
- 未確認事項：日時の保存形式・文字コードは、03-03の技術選定と合わせて改めて確認・確定させる必要があります。業務担当者による実案件での内容確認は未実施です。