データを設計する

6-1なぜ業務担当者がデータを設計するのか

データの設計というと、システム部門の専門的な仕事に聞こえるかもしれません。確かに、データベースの中でどう保存するかは技術者が決めます。しかし、業務で何を区別し、何を同じものとして扱い、何をいつまで覚えておく必要があるかは、業務を知る人にしか決められません。

たとえば、「取引先」と一口に言っても、請求書を送ってくる会社と、支払先の口座の名義が違うことがあります。グループ会社の請求を本社がまとめて送ってくることもあります。こうした業務上の区別をシステム部門に伝えなければ、仕組みは単純化された形で作られ、後から現場が手作業で補うことになります。

AIを使う仕組みでは、さらに重要になります。AIは渡されたデータをもとに判断するため、データの区別や意味が曖昧なら、AIの判断も曖昧になるからです。

6-2マスタデータと取引データ

業務で扱うデータは、大きく2種類に分けられます。

	マスタデータ	取引データ
何を表すか	業務に登場する「もの」や「相手」の基本情報	業務で起きた「出来事」の記録
例	取引先、社員、商品、勘定科目、部門	請求書、経費申請、注文、問い合わせ、仕訳
変わり方	ときどき変わる（住所変更、新商品の追加）	毎日増えていく。一度記録したら原則変えない
誤ったときの影響	それを使うすべての取引に誤りが広がる	その1件の誤り
管理の仕方	登録・変更できる人を限り、変更の記録を残す	入力の誤りを防ぎ、訂正は履歴を残して行う

取引データは、マスタデータを参照して作られます。請求書（取引データ）には、取引先（マスタ）のコードと、勘定科目（マスタ）が付きます。そのため、マスタの誤りは、それを使うすべての取引に広がります。取引先の振込口座が誤って登録されていれば、その取引先へのすべての支払いが誤った口座に向かいます。

6-3「もの」と「出来事」を洗い出す

業務で扱うデータを洗い出すには、第2章の業務分解表を使います。表の中の言葉から、次の2種類を拾い出します。

• 名詞のうち、繰り返し登場する相手や対象 → マスタの候補（取引先、社員、商品、部門）
• 工程の入力・出力に出てくる書類や記録 → 取引データの候補（請求書、申請、回答、仕訳）

次に、それぞれの関係を確かめます。「1つの請求書には、取引先が1つ」「1つの請求書には、明細が複数」「1つの問い合わせに、回答が複数回ある」のように、1対1か、1対多かを書き出します。この関係を間違えると、後から「1件に1つしか入力できない欄に、2つ入れたい」という問題が起きます。

データ	種類	関係
取引先	マスタ	1つの取引先に、請求書が複数
請求書	取引データ	1つの請求書に、明細が複数。取引先は1つ
請求明細	取引データ	1つの明細に、品目・金額・税率が1つずつ
発注	取引データ	1つの発注に、請求書が複数のこともある（分割請求）
勘定科目	マスタ	1つの明細に、勘定科目が1つ

6-4項目定義表を書く

データの種類が決まったら、それぞれに含まれる項目を決めます。項目ごとに次の6つを書いた表を、項目定義表と呼びます。

項目名	意味	形式	必須	例	正本・決め方
請求書番号	取引先が付けた請求書の番号	文字（30字以内）	任意	INV-2026-0451	請求書の記載
取引先コード	自社が取引先に付けた番号	数字6桁	必須	100245	取引先マスタ
請求日	請求書に記載された日付	日付（年-月-日）	必須	2026-10-05	請求書の記載
請求金額（税込）	支払うべき合計額	整数（円）	必須	330000	請求書の記載。明細の合計と一致すること
支払期日	支払いを終えるべき日	日付	必須	2026-11-30	取引先マスタの支払条件から計算
登録番号	適格請求書発行事業者の登録番号	Tと数字13桁	条件付き	T1234567890123	請求書の記載。公表情報と照合
状態	処理がどこまで進んだか	決まった選択肢	必須	確認中	処理に応じて自動で変わる（6-6）

この表で特に大事なのが、「意味」と「正本・決め方」の列です。

• 意味：同じ「日付」でも、請求日、受領日、計上日、支払日は違います。意味を書かないと、人やAIが別の日付を入れてしまいます
• 正本・決め方：その値をどこから持ってくるかです。支払期日は請求書に書いてあっても、自社では取引先マスタの支払条件で計算する、と決めているなら、そう書きます。AIに請求書から読み取らせるのか、システムで計算するのかが、ここで決まります

6-5コード・表記ゆれ・正本

同じ相手が「株式会社A商事」「(株)A商事」「A商事」と違う書き方で記録されている状態を表記ゆれと呼びます。人は同じ会社だと分かりますが、集計や照合では別の会社として扱われます。AIも、文脈から同じ会社と推測できることはありますが、確実ではありません。

表記ゆれを防ぐ基本は、マスタにコードを付け、取引データにはコードで記録することです。名前は変わることがありますが、コードは変わりません。AIに請求書を読ませる場合も、AIの仕事は「請求書に書かれた会社名から、取引先マスタのどのコードに当たるかを候補として挙げる」ことにし、最終的にはコードで記録します。

そして、情報ごとに正本（正しい情報として扱う唯一の置き場所）を決めます。取引先の住所が、会計システム・表計算ファイル・担当者の名刺で違っていたら、どれが正しいかを決めるのは正本です。他の場所は正本から写したものとして扱い、変更は必ず正本で行います。AIに参照させるのも正本です。

6-6状態（ステータス）を設計する

取引データには、処理がどこまで進んだかを表す状態（ステータス）を持たせます。状態は、業務の流れをデータとして表したものです。

受付済→読取済→確認中→承認済→支払準備済→支払済

分岐：差戻し（確認中から。取引先に再発行を依頼）保留（読取済から。AIが判断できず人へ）

状態を設計するときは、次の3つを決めます。

• どんな状態があるか：業務分解表の工程の切れ目が、状態の候補になる
• どの状態からどの状態へ進めるか：「確認中」を飛ばして「承認済」には進めない、など
• 誰が（何が）状態を進めるか：AI、システム、人のどれが、どの状態の変更を行えるか

3つ目は、AIを使う仕組みで特に大事です。AIが「読取済」まで進めることは許しても、「承認済」に進めるのは人だけ、と決めておけば、AIの誤りが人の確認を飛び越えて先に進むことを、仕組みで防げます。第3章の任せ方のレベルは、この「誰が状態を進められるか」として実現されます。

6-7データの寿命を決める

データには、生まれてから消えるまでの寿命があります。次のことを決めておきます。

• いつまで残すか：税務や会計の書類のように、法令で保存期間が決まっているものがあります。社内規程で定めているものもあります。正確な期間は、法務や経理の責任者に確かめてください
• いつ消すか：個人情報のように、目的を終えたら消すべきものもあります。残しすぎることにも危険があります
• 途中の記録をどうするか：AIの出力、確認の記録、修正の履歴など、AIを使うと新しく生まれるデータがあります。これらをいつまで残すかも決めます（第4章 4-7）

6-8AIのためのデータ

AIを組み込む仕組みでは、業務のためのデータに加えて、AIのためのデータを用意する必要があります。

データ	何に使うか	用意の仕方
正解付きの過去データ	AIの正確さを測る例題にする（第11章）	過去の請求書と、そのとき正しく処理した結果の組み合わせを集める
判断例	AIに判断の仕方を示す（第7章）	進めた例・差し戻した例・迷った例と、その理由
AIの入出力の記録	誤りの原因を調べる、改善に使う	AIに渡した内容、AIの出力、使った指示の版を保存する

メールやPDFのように、形の決まっていない情報を非構造データ、表のように項目が決まった情報を構造化データと呼びます。AIの得意なことの一つは、非構造データから必要な項目を取り出して構造化データにすることです。どの項目を取り出せばよいかを決めるのが、項目定義表です。項目定義表があれば、AIへの指示もそのまま書けます。