AI が文書を編集したとき、変更の所有権は誰にあるのか？

文書は誰が文を変更したかを示すことができますが、現在の文言を誰が承認したのかは不明なままです。AI と人間の両方が文言を修正した場合、最終的な編集の横にある名前だけではその質問に答えることはできません。

たとえば、2営業日以内に返答することを約束する仮想的なサポートポリシーを考えてみます。AI が書き直した提案は1営業日です。人間の編集者がそれを3営業日に変更し、チームリーダーが文書を承認します。リリースされたファイルは普通に見えます。その履歴には、却下された提案、人間による修正、そして顧客が何を期待すべきかに関する決定が含まれています。

その変更の所有権は誰にあるのでしょうか？ それをリリースする責任を割り当てる前に、各貢献を区別する必要があります。さもなければ「AI 支援」とだけ言っても、最終的な文言がどのように形成されたかについてほとんど情報が得られません。

編集と決定を分離する

Microsoft が 2025年9月29日に行った発表で、Agent Mode in Word が Frontier ロールアウトを開始したことが示され、対話型編集が文書アプリケーション内（当初はウェブ上）に配置されました。その発表はロールアウト日を示すものであり、特定の組織が結果の変更をどのようにレビューするかを示すものではありません。

AI をこのように活用するチームにとって、有用な出発点は編集を依頼した人物です。その人物を、提案を生成したソフトウェアとは別に記録します。誰かがその提案を書き直した場合も、その貢献を保持します。承認は別のアクションであり、レビュー担当者が実際に見たバージョンに結び付けられます。

これらの役割は、すべての作業に別々の人物を必要とするわけではありません。編集者が書き直しを依頼し、修正し、承認権限を持つこともあります。区別は依然として重要です。短い段落を依頼したからといって、ソフトウェアが行うすべての変更を承認したことになるわけではありません。

このW3C PROV データモデルは、この履歴を記述するための語彙を提供します。文書とそのバージョンはエンティティとして、編集や承認はアクティビティとして、人やソフトウェアはエージェントとして表現できます。このモデルはそれら間の関係性を記述しますが、法的責任を決定したり、著者フィールドに表示される人物を認証したりはしません。

技術文書やサポート資料を含むAI 支援型文書ワークフローにおいては、各記録されたアクションが何を意味するかを定義する必要があります。コメントは議論への貢献を示します。承認は特定の文言を公開する許可を示すべきです。両方に同じ汎用的な「レビュー済み」ステータスを付与すると、記録の有用性が低下します。

1つの変更された箇所の記録を作成する

応答時間の例に戻ります。書き直しを生成する前に、承認された「2営業日」の文言とその文書バージョンを保持します。提案された変更に識別子を付与し、以降の修正や決定をそれに結び付けます。

以下は架空の識別子を用いた概念設計例です。これはテスト済み製品からの出力でも、すべての文書ツールがサポートするスキーマでもありません。

人間の修正が適用された後も AI 提案を保持します。記録が最終的な「3営業日」文言だけを残す場合、後のレビュー担当者はそのエントリから以前の提案を再構築できません。却下された変更も履歴の一部であり、公開テキストに含める必要はありません。

NIST の 2024年7月版 Generative AI Profile は、プロヴァナンス（出所情報）をコンテンツの起源と履歴、変更やソースを含む情報として説明しています。また、プロヴァナンスプロセスと人間のレビュー担当者との関係を評価することを推奨しています。この表はその概念を文書ワークフローに適用したもので、NIST の認証チェックリストではありません。

この記録は文書システム内または連携リポジトリに保持できます。いずれの場合も、リリースされたバージョンとの関係を十分に明示し、元の編集者の記憶に頼らずに誰でも取得できるようにします。

引き継ぎ後に残るものを確認する

エクスポートされたファイルは個別にチェックすべきです。編集時に利用できる履歴は、受取人が確認できる内容と、使用するアプリケーション、フォーマット、エクスポート設定によって異なる場合があります。すべての PDF が属性情報を失う、あるいは表示コメントを残すことで全てのレビュー決定が保持されると想定しないでください。

Microsoft の現在の Copilot を使用した編集のドキュメント は、機能が有効な場合、変更がトラック変更に従うと述べています。これは有用な機能です。ただし、完全な承認履歴がその後のすべての変換や引き継ぎで残ることを保証するものではありません。

チームが実際に使用しているフローをテストしてください。例の文書をレビューとエクスポートのプロセスにかけ、保持された記録を使って受諾された改訂と承認者を復元しようと試みます。もしリリースされたファイルがその履歴を保持できない場合は、別の場所に管理された記録を残し、両者の紐付きを保ってください。

より単純でないケースも注意が必要です。提案の一部だけを受け入れ、記録が何と示しているかを確認します。二人のレビュアーに同じベースバージョンで作業させ、どの変更がリリースファイルに反映されたかを特定します。最後に、承認後にその箇所を編集し、以前の決定が新しい文言の承認に静かに置き換わっていないことを検証してください。

表示された著者名は、身元確認のためにそれが認証済みアカウントに紐付いていることを確認すべきです。同様に、ファイルダイジェストはリリースされた成果物の特定に役立ちますが、応答時間のコミットが正しいかどうかは判断できません。これらは別個のチェックであり、レビュー工程ではその区別を保つ必要があります。

リリース前に承認境界を設定する

見出しの書式変更と顧客へのコミットメント変更は、同一のレビュー経路をたどる必要はありません。確立された方針の下で進められる編集と、指定された人物の承認が必要な編集を判断してください。その選択は、変更が文書利用者にとって何を意味するかを反映すべきです。

ここでは 明示的な AI 決定権限 の議論が実務的になります。例では、3 営業日以内の応答コミットメントを承認する権限が必要です。ファイルを編集する権限だけでその権限の証拠とみなすべきではありません。

そのレビュアーに十分な文脈を提供して判断できるようにします。元の文と提案された文言を、途中の人間による修正と共に表示します。未解決の衝突を可視化し、リリース対象のバージョンを特定してください。最終的に磨き上げられた段落だけを見るレビュアーは、応答時間が変更されたことに気付く理由がないかもしれません。

ユーザーにワークフローを引き渡す前に、リリースの所有者を決定してください。その人物がすべての編集を行う必要はありませんが、必要なレビューが実施され、リリースするファイルに適用されたことを確認できる手段が必要です。担当を曖昧にしておくと、文書が完成した際に争点となる変更の解決が困難になります。

すべての機密プロンプトを無期限に保存する必要はありません。組織のアクセスおよび保持ポリシーに基づき、決定を説明するために必要な証拠を保持してください。モデルバージョン情報が入手できない場合は、その制限を記録します。有用な履歴は、欠落した情報を明示的に示すべきであり、システムが取得していない詳細レベルを暗示すべきではありません。

説明可能なバージョンのみをリリースする

重要な変更をリリースする前に、記録を遡って追跡してみてください。元の提案を見つけ、人間の編集者が何を変更したかを特定し、その改訂を受諾した決定を取得します。その後、承認されたバージョンと配布されるファイルを比較してください。

その紐付けが欠如している場合は、レビュー変更を保留してください。文書が「承認された」と記憶しているだけでは、どの文言が承認されたかを特定するには不十分です。

編集者は、AI が生成したすべての提案を割り当てられなくても、自身の貢献を説明できる必要があります。リリース所有者は、何を正確に承認しているかを把握しなければなりません。変更の背後にあるプロセスを検査できる信頼できる手段を提供せずに、変更に責任を持たせることはできません。