AI compliance obligation→machine-readable 制御 mapping

法令・契約・社内AI方針に含まれる義務を、機械可読なcontrol、evidence、assessmentへ追跡可能に結び付ける運用設計である。目的は、自然言語の義務をAIに自由解釈させて自動適用することではなく、原文の出典・適用条件・承認主体を保持したまま、統制実装と評価結果を一貫した識別子で接続することである。

主要claimと運用上の意味 1. NIST OSCALはcatalog、profile、implementation、assessment、assessment-resultsの層を持ち、control定義から実装・評価結果までを構造化データとして接続できる。2026-08-13公開のOSCAL v1.2.3はモデル変更を伴わないmaintenance/security patchであり、現行運用ではモデルversionを固定して処理系を検証する必要がある。 2. machine-readable化の価値は、義務文そのものを消すことではなく、stable identifierとprovenanceを介して「要求→control→実装→test/evidence→assessment result」の追跡を可能にする点にある。NISTの2026-09-23 OSCAL記事も、requirementsをstructured dataとして扱い、requirementからsystem component、test、evidence、assessment resultsへ追跡する利用を説明している。 3. control mappingは法的解釈の代替ではない。同じ義務でもjurisdiction、契約主体、intended use、risk classification、施行日、例外条項によって適用が変わる。したがって原文locator、適用条件、mapping rationale、owner/approver、effective date、versionをcontrol relationと同時に保持する。 4. mappingは一対一を前提にしない。一つのobligationが複数controlへ、複数obligationが一つのcontrolへ対応し得る。relationにはrelation type、根拠、confidence/verification state、review dateを持たせ、単なる文字列一致を「準拠」と扱わない。 5. assessment evidenceはcontrol実装の存在と有効性を分けて扱う。OSCALのAssessment Plan/Assessment Results層を利用する場合も、文書化済みcontrolと実際にtestされた結果を混同しない。

実装control / implication - obligation record: obligation_id、authoritative_source_locator、quoted/normalized requirement、jurisdiction/scope、effective_from/to、owner、legal_review_state。 - mapping edge: obligation_id、control_id、relation_type、mapping_rationale、approver、verification_state、reviewed_at、supersedes。 - control record: control_id、catalog/profile version、implementation owner、implementation statement、component/system scope。 - evidence/assessment: evidence_id、control_id、test method、artifact locator、collection time、assessor、result、exceptions、expiry/refresh rule。 - change detection: source law/contract/policy、OSCAL/catalog/profile、implementation、assessment methodのいずれかが変われば影響edgeを再評価する。 - release gate: unreviewed mapping、期限切れevidence、source locator欠落、適用条件不明を自動的なcompliance assertionへ昇格させない。

Failure / limitations / counterevidence - semantic gap: 自然言語義務とtechnical controlは粒度が一致しない。mappingが存在しても義務履行を自動的に証明しない。 - version drift: law/policy、control catalog、profile、OSCAL schema、実装のversion差で過去mappingが陳腐化する。 - scope leakage: 他地域・他契約・他systemのcontrolを誤って流用するとfalse complianceを生む。 - evidence staleness: evidenceは取得時点の状態であり、継続的適合を保証しない。 - tool conformance: OSCAL形式にschema-conformしていることと、法的・運用的に正しいmappingであることは別問題である。 - human authority: 法的適用性・例外・契約解釈は権限を持つ人間の判断を残す。

OSCALはsecurity/compliance情報を機械可読化する有力な交換形式だが、あらゆる法令・契約の意味論を標準化する汎用legal ontologyではない。組織固有のobligation schemaをOSCAL control/profile等へ関連付ける場合、原文provenanceと組織の承認workflowを別途保持する。

• 組織固有の法令・契約crosswalkに必要なrelation taxonomyの最終形。
• OSCAL外のGRC/requirements形式（ReqIF等）との正本境界と同期規則。
• jurisdictionごとの法的レビュー頻度と自動失効条件。

「machine-readable mappingは追跡・差分検出・評価連携を支援するが、mappingまたはOSCAL schema conformanceだけで法令・契約への準拠を証明するものではない。」

監査用source / provenance locator - NIST OSCAL Blog, “OSCAL v1.2.3 Patch Release”, 2026-08-13: https://pages.nist.gov/OSCAL/about/blog/ - NIST OSCAL Blog, “From Voting Systems to Structured Data with OSCAL”, 2026-09-23: https://pages.nist.gov/OSCAL/about/blog/ - NIST OSCAL Assessment Model Overview: https://pages.nist.gov/OSCAL/presentations/oscal-ap-ar-poam-v3.pdf - NIST Digital Identity Guidelines Implementation Resources, Conformance Criteria v0.1: https://pages.nist.gov/800-63-4-Implementation-Resources/conformance/criteria.html （同一criteriaをXLS/PDF/OSCAL JSON/XML/YAMLで提供する実例） - canonical proposal provenance: Enterprise AI運用辞典_発展・拡張構想_公開後アップデート原案台帳, EA-732 exact section; EA_MASTER provenance locatorに記録済み。

監査観点 canonical topic保持、主要claimのsource locator有無、法的解釈とschema conformanceの分離、version drift、many-to-many relation、evidence freshness、OPEN_UNKNOWN/SAFE_WORDINGを重点確認する。