データ・システム構成の設計学習記事全11節Design
誰に何を許すかを権限表にし、外部連携の考え方を整理する
この記事で身につくこと認証と認可を区別し、利用者・対象データ・操作の組合せで許可を決める考え方と、連携の約束（API）の意味を説明できる。許可判定を画面・処理・保存先のどこで守るかを比較して選定理由を書ける。
記事内目次（27項目）
この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。05-02で決めた状態遷移をもとに、誰が・どのデータに・どの操作を許されるかを権限表にし、外部のシステムと連携する場合の考え方を整理する話です。
なぜ必要か。権限を決めずに実装すると、割当外の承認者が他人の依頼を承認できてしまったり、運用管理者が承認を代行できてしまったりします。04-02では画面上でボタンを隠す話をしましたが、それだけでは実際の操作を防げません。
この記事を読むとできるようになること。
- 認証と認可を区別し、利用者・対象データ・操作の組合せで許可を決める考え方を説明できる
- 依頼者・承認者・運用管理者について、対象データと操作の権限表を作り、自己承認禁止を明記できる
- 許可判定を画面・処理・保存先のどこで守るかを比較し、外部連携がある場合に決めるべきことを書ける
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「認証と認可の違い」と「権限表の形」が分かり、ひな形を埋め始められます。
- 作って確かめる：上に加えて第5.4節（AIへの依頼）→第6節（失敗例と直し方）→第7節。
- 設計判断を深める：上に加えて第8節（許可判定の置き場所の比較、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、05-02で決めた状態遷移をもとに、依頼者・承認者・運用管理者という3役割について、どのデータに何の操作を許すかを権限表にし、将来外部のシステムと連携する場合に何を決める必要があるかを整理することです。
状態がいつ変わってよいかが決まっても、「誰がその操作をしてよいか」が決まっていなければ、実装のたびに判断がばらつきます。04-02では画面上でボタンを隠す方法を扱いましたが、この記事では、実際に操作を許すかどうかの判定そのものを設計します。
この記事を読み終えると、次のものが手元にできます。
- 権限表（役割、対象データ、操作、許可、条件、要件ID）
- 許可判定をどこで守るかの選定理由
- 外部連携がある場合に決めるべきことの整理
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
認証
一言でいうと、操作しようとしている人が誰であるかを確認することです。たとえば、ログインの際に、その人が本当に本人かどうかを確かめます。
これがないと、誰でも他人になりすまして操作できてしまいます。
システム開発では、この記事の演習のように、本人確認を固定値で代用することがありますが、それは実際の認証機能を実装・検証した証拠にはなりません（設計書5.5）。
認可
一言でいうと、その人（認証で確認済みの本人）に、何を許すかを判断することです。たとえば、依頼者本人であることが確認できても、他人の依頼を承認する権限までは認めません。
これがないと、本人確認さえできれば何でもできてしまい、役割に応じた制限（REQ-002・REQ-003）が意味をなさなくなります。
システム開発では、認証（誰か）と認可（何を許すか）は別の仕組みとして設計します。この記事は認可（権限）を中心に扱います。
API（連携の約束）
一言でいうと、あるシステムが別のシステムとやり取りする際の、あらかじめ決めた約束事です。たとえば、「この情報を渡すので、この形式で返してほしい」という取り決めです。
これがないと、システム同士が何をやり取りしてよいか分からず、意図しない情報まで渡ってしまう危険があります。
システム開発では、外部のサービスと連携する場合、どの情報を渡すか、失敗したときにどうするかをAPIの約束として決めます。この記事の題材アプリには、現時点で確定した外部連携はありません。第8.2節で、将来連携する場合に決めるべきことを整理します。
読む順路：状態遷移は05-02が該当します。品質条件（安全性の基準）は02-03が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。
3. 理解する：誰に何を許すか
3.1 認証と認可の違い
| 確認する内容 | この業務での例 | |
|---|---|---|
| 認証 | 操作している人が誰か | ログインした人が、利用者データのどのIDの人か |
| 認可 | その人に何を許すか | 承認者として登録されている人でも、割当外の依頼は承認できない |
3.2 許可の決め方（利用者・対象データ・操作の組合せ）
02-03・記事Aで確認したとおり、この業務の権限は「役割」だけでなく「対象データ（自分の依頼か、割り当てられた依頼か）」の組合せで決まります。同じ承認者でも、割り当てられていない依頼は承認できません。
3.3 よくある誤解
「役割が分かれば権限も自動的に決まる」。承認者という役割でも、割当外の依頼は承認できません（対象データによる制限）。役割だけでなく、対象データとの組合せで判断します。
「運用管理者は何でもできる管理者だから、承認も代行できる」。設計書5.2・記事Aのとおり、運用管理者は承認を無条件に代行できません。管理の役割と、業務上の判断（承認）は別です。
「画面でボタンを隠せば権限は守られる」。04-02で説明したとおり、画面側の表示条件は誤操作を防ぐものであり、直接の操作を防ぐものではありません。この記事では、処理側・保存先側での確認まで設計します（第8節）。
「AIに権限表を作らせればよい」。AIは一般的な権限表の形を提示できますが、この業務でどの組合せを許可するかは、記事A・設計書5.2に基づいて人が判断します（第4.3節）。
4. 判断すること
4.1 何を確認すればよいか
| 確認すること | この記事での扱い |
|---|---|
| 3役割×主要操作の組合せがすべて埋まっているか | 第5.2節で確認する |
| 自己承認禁止・運用管理者の承認代行禁止が明記されているか | 第5.2節で確認する |
| 認証の代用（固定値）を使う演習は、実際の認証ではないと注記されているか | 第5.3節・第11節で確認する |
4.2 勝手に決めてはいけないこと
- 記事A・設計書5.2で決めた役割ごとの基本方針を、この記事で変更しません。
- 自己承認禁止・運用管理者の承認代行禁止を、この記事で緩めません。
- 正本に存在しない具体的な外部サービス名を、確認済みの連携先として追加しません。
4.3 AIに任せる範囲
一般的な権限表の形、認証・認可の一般的な説明の提示はAIに任せられます。しかし、この業務でどの組合せを許可するかは、記事A・設計書5.2・02-03に基づいて人が判断します。
5. 作って確かめる：権限表を作る
5.1 準備
05-02の状態遷移表、02-03の品質条件一覧、記事Aで確認済みの役割の基本方針を用意します。
5.2 権限表
| 役割 | 対象データ | 操作 | 許可 | 条件 | 要件ID |
|---|---|---|---|---|---|
| 依頼者 | 自分の依頼 | 閲覧 | 許可 | — | REQ-002 |
| 依頼者 | 自分の依頼 | 編集 | 許可 | 状態が下書き・差戻しのときだけ | REQ-002 |
| 依頼者 | 自分の依頼 | 提出 | 許可 | 05-02の提出条件を満たすこと | REQ-002、REQ-004 |
| 依頼者 | 自分の依頼 | 承認・差戻し・割当 | 不許可 | — | REQ-003 |
| 依頼者 | 割当依頼・全利用者 | すべての操作 | 不許可 | 自分に関係のないデータのため | REQ-002 |
| 承認者 | 自分の依頼（承認者自身が依頼者になる場合） | 閲覧・編集・提出 | 許可 | 依頼者と同じ条件 | REQ-002 |
| 承認者 | 割当依頼 | 閲覧 | 許可 | 自分に割り当てられた依頼のみ | REQ-002 |
| 承認者 | 割当依頼 | 承認 | 許可 | 状態が提出済み、自己承認でない | REQ-003 |
| 承認者 | 割当依頼 | 差戻し | 許可 | 状態が提出済み、差戻し理由がある、自己承認でない | REQ-003、REQ-004 |
| 承認者 | 割当依頼 | 編集・割当 | 不許可 | 承認者は依頼の内容そのものは編集しない | REQ-003 |
| 承認者 | 全利用者 | すべての操作 | 不許可 | 承認者の役割の範囲外 | REQ-002 |
| 運用管理者 | 自分の依頼（運用管理者自身が依頼者になる場合） | 閲覧・編集・提出 | 許可 | 依頼者と同じ条件 | REQ-002 |
| 運用管理者 | 割当依頼 | 承認・差戻し | 不許可 | 承認の無条件な代行を禁止する（設計書5.2） | REQ-003 |
| 運用管理者 | 全利用者 | 閲覧・編集・割当 | 許可 | 利用者・役割・担当割当の管理、運用記録の確認の範囲に限る | — |
5.3 認証についての注記
この記事の演習・記入例では、本人確認を固定値（あらかじめ決めた利用者ID）で代用します。これは説明のための簡略化であり、実際のパスワードや生体認証などを用いた認証機能を実装・検証したことにはなりません（設計書5.5）。実際の認証の仕組みは、この記事の範囲外です。
5.4 AIに権限表の下書きを頼む
記事A・設計書5.2の役割の基本方針をもとに、権限表の下書きをAIに作らせます。
依頼・承認管理アプリの権限表を作りたいです。役割は依頼者・承認者・運用管理者、対象データは自分の依頼・割当依頼・全利用者、操作は閲覧・編集・提出・承認・差戻し・割当です。記事Aの役割の基本方針（自己承認禁止、運用管理者の承認代行禁止）を渡します。
依頼：
1. 3役割×主要操作の組合せをすべて埋めた権限表を作ってください。
2. 自己承認禁止・運用管理者の承認代行禁止を、条件の列に明記してください。
してはいけないこと：
- 記事Aの役割の基本方針にない権限を追加しないでください。
- 正本に存在しない具体的な外部サービス名を挙げないでください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。
- 運用管理者の行に「割当依頼の承認：許可（管理者のため）」と記載されていた
- 「クラウド〇〇と連携すれば通知が送れます」と、正本に存在しない具体的なサービス名を確認済みの連携先のように記載
6.2 見つけ方と直し方
- 運用管理者に承認権限がある：設計書5.2「管理者だからといって承認を無条件に代行しない」に反します。「不許可」に修正します。
- 具体的なサービス名の記載：正本に存在しない情報を確認済みのように書いています。削除し、外部連携は現時点で確定していないと明記します。
指摘：
1. 運用管理者は承認を代行できません。「不許可」に修正してください。
2. 具体的な外部サービス名は正本にありません。削除してください。
変えないこと：
- 依頼者・承認者の権限、05-02の状態遷移は変更しないでください。6.3 修正後の権限表
修正後の権限表は、第5.2節のとおりです。
7. 確認結果
第5.2〜5.3節の内容を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 3役割×主要操作の組合せがすべて埋まっている | 第5.2節の表で3役割すべての主要操作を記載 |
| 自己承認禁止・運用管理者の承認代行禁止が明記されている | 承認者・運用管理者の行にそれぞれ明記 |
| 認証の代用（固定値）を使う演習は「実際の認証ではない」と注記されている | 第5.3節に明記 |
残る制限：この権限表は架空の業務に基づく一例です。実際の認証の仕組み、外部連携の詳細は確認しておらず、この記事の範囲外です。この記事の本文と記入例はClaude Codeが作成し、2026-09-20にユーザーによる実読でPASSしましたが、実際の業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 許可判定を画面・処理・保存先のどこで守るか
| 場所 | できること | できないこと |
|---|---|---|
| 画面（04-02で扱った範囲） | 権限がない操作のボタンを表示しない、誤操作を防ぐ | 直接の操作要求を防げない |
| 処理（採用） | 操作を実行する直前に、この権限表の条件を確認し、満たさなければ拒否する | 保存先に直接アクセスされた場合は防げない |
| 保存先 | データそのものへのアクセス制限をかける | 業務的な条件（自己承認でないか等）までは判断しにくい |
自己承認禁止や割当依頼の判定のように、業務の条件と組み合わせた判断が必要なため、処理の中でこの権限表の条件を確認する方法を中心に採用します。画面側の表示条件（04-02）は、処理側の確認を補う形で併用します。保存先での制限は、この記事の範囲外とし、必要に応じて別途検討します。
8.2 外部連携がある場合に決めるべきこと
この題材アプリには、現時点で確定した外部連携（正本に記載のある具体的なサービス）はありません。将来、何らかの外部システムと連携する場合は、次を決める必要があります。
| 決めること | 内容 |
|---|---|
| 連携先 | どのシステムと、何の目的で連携するか |
| 渡す情報の範囲 | 依頼のどの項目を渡すか。個人情報・社外秘の扱いは03-01の制約と合わせて確認する |
| 失敗時の扱い | 連携先が応答しない場合、この業務の操作（承認など）を止めるか、後で再送するか |
これらは、この記事の時点では未確定であり、教材上の想定として整理したものです。
8.3 適用限界
この権限表は、架空企業「みらい業務サービス」の3役割を前提にしています。役割が増える、あるいは複数の承認段階が必要になる場合は、権限表を作り直す必要があります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 権限表ひな形（役割、対象データ、操作、許可、条件、要件ID） | templates/05-03-permissions_template.md | templates/05-03-permissions_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（状態遷移表、役割の基本方針）を用意する
- 役割×対象データ×操作の組合せをすべて挙げる
- 各組合せに許可・不許可と条件を書く
- 自己承認禁止・代行禁止など、業務上必ず守るべき条件を明記する
10. 次工程への受渡し
次へ渡すもの：権限表、許可判定を処理側で確認するという方針、外部連携がある場合に決めるべきことの整理。
次工程での使われ方：08-03（連携実装）では、外部連携が必要になった場合にこの整理をもとに実装します。09-03（権限検証）では、この権限表の条件が実際に守られているかを確認します。
前工程へ戻る条件：権限表を作る中で、05-02の状態遷移や記事Aの役割の基本方針に不足が見つかったら、それぞれの記事に戻って見直します。
11. 根拠と更新情報
- この記事の会社・人物・権限表の内容はすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 役割の基本方針（自己承認禁止、運用管理者の承認代行禁止）は、教材設計書
AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.2節および記事Aに基づきます。 - 本人確認を固定値で代用する演習が実際の認証ではない点は、同設計書第5.5節に基づきます。
- 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。作成時点（2026-09-20）では人による実読・内容確認は未実施でした。
- 更新履歴：2026-09-20、ユーザーによる実読でPASS。本文・権限表の内容は変更していません。
- 未確認事項：外部連携（連携先、渡す情報の範囲、失敗時の扱い）は、この記事の時点では確定しておらず、教材上の想定として整理したものです。実際の認証の仕組み、業務担当者による内容確認は未実施です。