分類設計の目的と前提
利用目的の整理（検索・集計・分析・運用）
分類設計は、情報を再利用可能な形で扱うために、対象を規則に従って整理する手法である。利用目的を先に定めることで、必要な粒度や属性、運用手順が決まり、後工程の手戻りを抑えられる。検索では「探しやすさ」、集計では「集計可能性」、分析では「再現性」、運用では「維持コストと変更容易性」が主眼となる。
目的別に求められる要件
検索では、表記ゆれや別名が吸収される仕組みが重要である。集計では、同一の概念が同一カテゴリに入り続けることが前提になる。分析では、カテゴリと属性の取り扱いが一貫している必要がある。運用では、付与担当者の判断がぶれないように、評価基準や例外の規定が求められる。
対象範囲の定義（何を分類し、何を除外するか）
分類対象を明確にしないと、同じ情報が異なるカテゴリに振り分けられたり、逆に重要な要素が分類外に放置されたりする。対象範囲は、分類に含める項目（例：イベント種別、主体、関連属性）と、含めない項目（例：推測要素や未確認情報）を線引きすることで成立する。
分類対象と非対象の線引き
イベント種別の設計では、観測された事実と推定を分けるのが基本である。例えば「発生した」か「発生が見込まれる」かで区別し、見込み側を別領域として扱うと後の集計が破綻しにくい。また、分類が扱う範囲を決めると、データ欠損時の扱いも定めやすくなる。
期待する成果指標（粒度、再現率、運用負荷）
成果指標は、分類の有効性と維持可能性を同時に評価するために用意する。典型的には、粒度（必要な細かさの度合い）、再現率や適合率（付与の一致度）、運用負荷（人手作業量やレビュー回数）が測られる。
指標の設定方法
粒度は、分析目的に照らして「分けるべき差」と「分けなくてもよい差」を基準化する。再現率は、既存ラベルの再現や、ルールでの判定と実運用の一致度として測定する。運用負荷は、1件あたりの処理時間、確認フローの回数、例外対応の頻度などで見積もる。
分類体系の設計原則
一貫性と重複回避
分類体系は、一貫性を守ることで品質が安定し、重複を避けることで集計や分析が単純になる。カテゴリの意味が曖昧だと、同一事象に複数カテゴリが当てはまる状態が増え、運用が難しくなる。
重複の典型と対策
カテゴリ同士の境界が薄い場合、特に「似た概念の併存」が起こる。対策として、各カテゴリに定義文を付け、該当条件を列挙し、さらに否定条件（「これは入れない」）を明記する方法がある。定義の参照可能性を高めるほど、運用の揺れは小さくなる。
粒度の考え方（細かさと扱いやすさのバランス）
粒度は、細かいほど表現力が高い一方で、分類コストや誤判定の機会が増える。設計では、必要な意思決定や分析に到達するための最小単位を基準に、カテゴリ数と運用負荷を均衡させる。
粒度を決める評価観点
分解の必要性は、集計の意思決定単位に対応しているかで判断する。例えば、集計結果が特定の観点で十分に分かれるなら、それ以上の細分化は必須でないことが多い。反対に、異なる処理方針や異なる可視化が必要なら、粒度を上げる根拠になる。
拡張性（後から増える項目への備え）
分類体系は、将来の追加に耐えるように設計する必要がある。後から要素が増える前提で、既存カテゴリに影響を与えにくい追加手順や、階層構造の置き方を工夫する。
拡張のための設計戦略
階層構造を採用する場合、上位カテゴリの意味を広く保ち、下位で具体化する設計が一般的である。これにより、新しい下位項目が追加されても上位定義を崩しにくい。加えて、未分類や暫定ラベルの運用を規定しておくと、追加前の暫定処理も安定する。
イベント種別のラベル設計
ラベルの命名規則（日本語表記、略語、表記ゆれ）
イベント種別ラベルは、読み手と付与担当者の理解を揃える役割を持つ。日本語表記では、一般名詞の採用や語順の統一、略語の扱いをルール化し、表記ゆれを抑制する必要がある。
命名ルールの例示観点
命名は「意味が想像できる」ことと「定義に照らしやすい」ことを両立させる。略語を使う場合は正式名称との対応表を持ち、漢字・ひらがな・カタカナの揺れを吸収できる正規化手順を用意する。さらに、大文字・小文字のような別体系の揺れが混ざる領域では、正規化を前提にする。
必要な属性の設計（種別に加える補助情報）
イベント種別だけでは判定が難しいケースがあるため、補助属性を設計して判定や集計を補強する。補助情報は、種別の定義を補う方向に設計し、過剰な入力負担を避ける。
補助属性の設計基準
属性は、同じ種別でも異なる処理が必要な場合に意味を持つ。例えば成果の有無、対象範囲、品質区分などが挙げられる。属性の型（カテゴリ値、数値、自由文）を決めると、運用のブレや入力ミスを抑えやすい。
2.3多クラス分類か単一分類か
イベント種別の付与方式には、1件に1カテゴリを割り当てる単一分類と、複数カテゴリを併記できる多クラス分類がある。どちらが適切かは、1件の性質が同時に複数の意味を持つか、あるいは集計単位が排他的かで決まる。
選定の判断
排他的に扱いたい意思決定がある場合、単一分類が適する。対して、事象が複合的であり、検索や分析で複数観点を同時に求める場合は多クラスが有利になる。ただし多クラスは集計ロジックが複雑になりやすいため、どの集計を主要KPIとするかも考慮する。
3.2.1 時間・場所・関係者などの補助フィールド
補助フィールドは、種別ラベルの意味を現実の文脈に結び付ける。時間は発生・記録・更新などの区別を持つことで、時系列分析や監査に役立つ。場所は粒度を揃え、住所級の詳細を扱うか、地域級に留めるかを決める必要がある。関係者は、主体・対象・実行者など役割を明確にして同一人物の混同を防ぐ。
フィールド設計の注意
時間はタイムゾーンや不明値（未特定）の表現を規定する。場所は表記揺れを抑えるため、正規化や参照データ（地名辞書等）を用意すると効果が高い。関係者は役割の定義が曖昧だと重複登録や誤認が増えるため、入力時の誘導と検証をセットで設計する。
データ運用と品質管理
付与手順（手動・半自動・自動）
ラベル付与は運用形態によって最適な品質管理が異なる。手動は判断の説明がしやすい一方でスケールに限界がある。半自動は推定を提示し、人が最終判断する方式で、誤りの回収が比較的容易である。自動は大量処理に向くが、誤判定の原因分析と継続改善の仕組みが不可欠になる。
手順の設計例
半自動では、候補提示と根拠表示（ルール一致の有無、類似度など）を行うと、人の判断が安定しやすい。手動では、ルール参照とチェックリスト運用によりブレを抑える。自動では、閾値や信頼度が低い場合の保留・人手レビュー基準を明確にする。
品質評価（誤分類、欠損、矛盾の検出）
品質評価は、誤分類だけでなく欠損や矛盾も対象にする。欠損は後段の集計で除外や偏りを生みやすく、矛盾は監査や運用の信頼を損なう。したがって、単一の指標に依存せず、検出項目を組み合わせるのが望ましい。
評価項目の構成
誤分類は、サンプル検査や既知の正解集合で測る。欠損は必須属性の充足率と、任意項目でも欠けると分析不能になる割合で評価する。矛盾は、定義上成立しない組合せ（例：特定種別に必須の属性が欠ける、時間順序が不自然など）をルールで検出する。
更新方針（ルール変更時の整合性維持）
分類ルールは、運用実績を踏まえて更新される。更新時に既存データの扱いを決めないと、期間による比較ができなくなるため、整合性維持の方針が必要である。
変更の取り扱い
ルール変更では、(1)新ルール適用の開始時期、(2)既存データの再判定の要否、(3)変更理由と影響範囲の記録を定める。再判定を行う場合は、ラベルの変化量を監視し、学習や分析の時点で混在しないよう区切りを作る。
例示とガイドライン整備
ケーススタディ（典型例・難例）
ケーススタディは、実務上の理解を統一するための要である。典型例はルールが素直に適用できる場面として示し、難例は境界条件と判断手順を明らかにする。
例示の作り方
典型例では、入力要素と判定結果の対応を短く提示する。難例では、なぜ別カテゴリが候補になるのか、どの要素が決定打となるのかを整理する。さらに、判断に迷いやすい要素をあらかじめ分解して説明することで、誤りの再発を抑えられる。
現場向けマニュアルの作成
マニュアルは、分類設計を現場で運用可能な形に落とし込む文書である。定義集、手順、入力例、チェック観点を一体化させ、担当者が迷ったときに参照すべき場所を明確にする。
マニュアルの構成要素
定義集はカテゴリごとの目的と対象条件を中心に作る。手順は付与から確認までの流れを順番で示し、チェック観点は品質評価の観点と一致させる。加えて、問い合わせ先や判断保留の手続きも含めると運用が安定する。
よくある混同（境界事例の扱い）
境界事例は、分類体系が未成熟なサインでもある。混同が頻発する領域を特定し、どちらに入れるかの判断ルール、あるいは多クラス指定の是非を明確にすることで、品質を底上げできる。
境界事例の解決アプローチ
第一に、否定条件の追加で境界を締める方法がある。第二に、補助属性を増やして判別材料を補う方法がある。第三に、どうしても区別が困難なら「暫定」や「要確認」を導入し、後で見直す運用に切り替える方法がある。
アーキテクチャ・実装への落とし込み
データモデル（分類階層、参照、コード化）
データモデルは分類体系をシステムで扱うための構造である。階層を持つ場合は、親子関係を表現する仕組み（参照キー等）が必要になる。さらに、ラベル文字列に依存せずコード化することで、表記ゆれの影響を抑える。
コード化の要点
コード化では、表示名と内部コードを分離するのが一般的である。内部コードは安定性を優先し、表示名は言語や体裁に合わせて変更可能にする。参照データ（辞書、地名、役割など）を正規化すると、品質検証も効率化できる。
互換性とバージョニング
互換性とバージョニングは、ルール更新やカテゴリ追加が起きてもシステム全体が壊れないための設計である。特に、過去データの読み取り方と、将来の拡張に対する余地を同時に確保する必要がある。
バージョン戦略
カテゴリ定義の改訂に応じて、定義バージョンを持たせると監査や再現が可能になる。APIやデータ出力においては、後方互換を維持するための変換層や、フィールド追加時のデフォルト値規定が有効である。
監査可能性（判断履歴の残し方）
監査可能性は、「なぜそのラベルになったか」を追跡できる性質である。人手判定でも、自動や半自動の推定でも、判断材料と適用されたルール、参照したバージョンを保存すると、後から検証しやすい。
履歴管理の実務
判断履歴には、付与日時、付与者またはシステム識別子、使用ルールのID、参照データのバージョンなどを記録する。誤りが見つかった際には、該当期間と影響範囲を素早く特定できるようにしておくことが重要である。