詳細設計書（データ）
| 項目 | 内容 |
|---|---|
| 入力 | 確認済み要件、基本設計、対象業務の入出力とデータ利用条件 |
| 本工程で決めること | エンティティ、関連、必須属性、状態、出所、版、保護条件 |
| 出力 | 論理データモデル、物理Schema作成条件 |
| 完了条件 | 実行と評価に必要なデータを、出所・版・承認状態とともに追跡できること |
1. 論理データモデル
Section titled “1. 論理データモデル”erDiagram
SUBJECT ||--o{ EPISODE : has
SUBJECT ||--o{ PROFILE_VERSION : has
PROFILE_VERSION ||--o{ PROFILE_RULE : contains
CASE ||--o{ RUN : executes
RUN }o--|| PROFILE_VERSION : uses
RUN ||--o{ RUN_EVIDENCE : references
RUN ||--o{ TRACE_EVENT : records
RUN ||--o{ ARTIFACT : produces
RUN ||--o{ REVIEW : receives
CORRECTION }o--|| SOURCE_RECORD : grounded_in比較評価は、同じ案件に対する対象人物の実行記録、基準AIの実行およびMVP実行を一つの比較単位として管理する。
2. エンティティ定義
Section titled “2. エンティティ定義”| ID | エンティティ | 主キー | 主な必須属性 |
|---|---|---|---|
| ENT-01 | Subject | subject_id | 管理単位、表示名、状態、同意・利用条件の参照 |
| ENT-02 | Source Record | source_record_id | 種別、取得元、取得日時、内容参照、Hash、データ方針参照 |
| ENT-03 | Episode | episode_id | subject_id、対象業務・ケース、取得項目、取得状態、評価分割、本人確認状態 |
| ENT-04 | Profile Version | profile_id＋version | subject_id、対象業務、状態、作成日時、承認日時 |
| ENT-05 | Profile Rule | rule_id | rule_type、内容、適用条件、例外、優先度、根拠参照、承認状態 |
| ENT-06 | Case | case_id | 目的、入力版、制約、期限、期待成果、受入条件、管理単位 |
| ENT-07 | Run | run_id | case_id、profile_id＋version、モデル・指示・処理の版、状態、計測値 |
| ENT-08 | Run Evidence | run_evidence_id | run_id、参照種別、参照ID・版、選定理由 |
| ENT-09 | Trace Event | event_id | run_id、状態、イベント種別、入出力参照、発生日時、結果 |
| ENT-10 | Artifact | artifact_id | run_id、成果種別、内容参照、Hash、版 |
| ENT-11 | Review | review_id | 対象ID、評価者役割、採用・差戻し、評価基準版、根拠 |
| ENT-12 | Correction | correction_id | 訂正対象、修正前後、理由、適用条件、状態、反映先版 |
| ENT-13 | Comparison | comparison_id | case_id、本人実行参照、基準AI実行参照、MVP実行参照、評価基準版 |
日時はタイムゾーンを含む形式で保存する。識別子はエンティティ間で再利用せず、すべての関連を明示的な参照で保持する。
3. 人物データの構成
Section titled “3. 人物データの構成”人物データは、元記録、事例、人物情報版の三層に分ける。
| 層 | 内容 | 利用条件 |
|---|---|---|
| 元記録 | 発言、操作、資料、ケース回答、成果物など取得時点の記録 | 改変せず、Hashと取得元を保持する |
| 事例 | 一件の実務または現実的なケースにおける状況、取得できた判断・行動、成果、本人の補足 | 取得方法と本人の事後説明を区別する |
| 人物情報版 | 実行時に参照する、本人確認済みの判断基準・適用条件 | 対象人物の承認後にだけ有効化する |
人物情報のRule種別は、着目、確認、調査、選択、作業順、修正、完了判断を基本とする。対象業務の決定後、実務上必要な種別だけを追加する。
人物データ作成は、実務観測の存在を開始条件にしない。構造化質問、現実的なケースへの応答、利用可能な実務記録を組み合わせて取得し、実務観測を利用できる場合は追加の根拠として併用する。
4. 取得情報の分類
Section titled “4. 取得情報の分類”取得した発言および操作は、出所、利用目的、本人確認の有無を分類し、人物情報として承認された内容だけを有効化する。
| 分類コード | 分類 | 取扱い |
|---|---|---|
| project_instruction | プロジェクト上の指示・決定 | プロジェクト記録として保持し、人物情報には登録しない |
| observed_work | 実務で観測した判断・行動 | 事例候補として保持し、観測範囲を明記する |
| elicited_case_response | 構造化質問または現実的なケースに対する本人応答 | 事例候補として保持し、提示条件と応答を対応付ける |
| subject_self_report | 本人による判断基準の説明 | 人物情報候補として保持し、適用条件を確認する |
| subject_correction | 本人による訂正 | 適用範囲と既存情報との整合を本人確認後に反映する |
| ai_inference | AIによる推定 | 推定として保持し、人物情報へ自動登録しない |
| ai_assisted_choice | AI案を踏まえた本人の選択 | AIの影響と採用理由を記録し、本人確認後に扱いを決める |
一つの記録に複数の目的が含まれる場合は、目的ごとに分けて分類する。
5. 事例の記録項目
Section titled “5. 事例の記録項目”事例では、次の項目を取得できた範囲だけ記録する。取得できない項目をAIで補完しない。
| 項目 | 内容 |
|---|---|
| 入力条件 | 受け取った依頼または提示ケース、資料、制約、期限 |
| 着目・確認 | 最初に確認した事項、不足・矛盾・危険の検知 |
| 調査 | 参照した情報、検索、確認先 |
| 選択 | 比較した選択肢、採用・棄却と取得できた理由 |
| 作業 | 実施順、途中変更、使用した道具 |
| 成果 | 作成物、残課題、完了判断 |
| 本人補足 | 対応後に本人が説明した判断理由 |
| 訂正 | AIまたは構造化結果への修正、理由、適用範囲 |
各項目に observed、elicited、self_reported、not_observed の取得状態を持たせる。評価分割は development と held_out を分離し、合否判定用ケースを人物データの調整へ使用しない。
6. 状態と版
Section titled “6. 状態と版”draft → subject_review → approved → active → retired
activeにできるのは、対象人物が承認した版だけとする。- 対象人物と対象業務の組合せごとに、有効な版を一つに限定する。
- 実行開始時に人物情報版を固定し、実行途中で切り替えない。
proposed → approved | rejected → applied
- 訂正は作成時点では候補であり、自動で人物情報へ反映しない。
- 承認時に適用条件、例外および反映先の人物情報版を記録する。
- 元記録は上書きせず、訂正前後を追跡できるようにする。
7. データ保護
Section titled “7. データ保護”各データは、共通のデータ方針を参照する。
| 項目 | 必須内容 |
|---|---|
| 利用目的 | 取得・利用する業務上の目的 |
| 機密区分 | 適用する区分体系と区分値 |
| 利用範囲 | 許可された利用、モデル送信可否、アクセス可能な役割 |
| 管理主体 | データの管理責任を持つ役割 |
| 根拠 | 同意、契約、業務上の権限などの参照 |
| 保持・削除 | 保持期限、削除条件、削除状態 |
機密区分の名称は共同開発で採用する既存ルールを確認して決める。未定義の固定区分は設けない。認証情報は、人物データ、案件、指示、モデル入出力および処理記録へ保存しない。
8. 物理Schemaの作成条件
Section titled “8. 物理Schemaの作成条件”JSON Schema、データベース定義およびAPI仕様は、対象業務の入力、成果物、権限、既存環境およびデータ利用条件が確定した後に、本設計のENT-01〜ENT-13と要件IDへ対応させて作成する。