ドメインエンティティ（例: 経歴のプロジェクト、商品、記事）に、本人・担当者が書くフィールドと AI が根拠データから合成するフィールドが同居するとき、「どちらも UI で編集できる」に倒すと壊れ方が生まれる。フィールド単位で所有者（原本=人 / 生成物=AI）を宣言し、編集経路をそれに合わせて非対称にする。

判断基準

• 原本（人の主張・言葉）: UI で直接編集可。AI の関与は下書きの提案までに留め、確定は必ず人が行う（起草支援パターン）。
• 生成物（根拠データからの合成）: UI での手編集を許可しない。閲覧＋再生成導線のみ。直したいときは元の根拠データ側を直して再生成する。
• 更新 API・ツールも所有者別に分ける（原本更新用と生成物保存用を同一エンドポイントに混ぜない）と、権限・監査・バリデーションを別々に設計できる。
• 生成物が根拠への参照（証跡 id など）を伴う場合は特に必須。人が文言だけを直すと「根拠が裏付けていない主張」が混入し、検証可能性を売りにする設計ではその信頼が死ぬ。

なぜ

生成物の品質保証は「根拠との整合」で担保されている。手編集を許すと整合の担保点が消え、以後の再生成で人の編集が無言で失われる問題も生む（編集と再生成のマージは解けない）。逆に原本まで完全生成物にすると、再生成のたびに本人の確定が飛び、本人の言葉であるべき主張が AI の文体に置換される。

落とし穴

• 所有者を分けず「とりあえず全部編集可」にすると、生成物への手直しが常態化して再生成が使えなくなる（直した内容が毎回消えるため）。
• 生成物の「手編集不可」は不便さの押し付けではなく、代替経路（根拠データの修正→再生成）を必ずセットで用意する。経路がないとユーザーは詰む。

検証

• 生成物の誤りを 1 件仕込み、「根拠データ修正→再生成」だけで直せるかを確認する。
• 原本フィールドが再生成で上書きされないこと（生成物の更新経路が原本に触れないこと）を確認する。