【ITニュース解説】Drafting Rights: Assign Every Doc Section to a Model or a Named Human

現代のソフトウェア開発において、ドキュメントの作成は不可欠な工程である。しかし、多くのプロジェクトでは、ドキュメントの品質そのものよりも、「この情報が誰によって承認されたのか」「その内容は本当に信頼できるのか」といった説明責任（アカウンタビリティ）の点で課題を抱えている。特に、近年注目される生成AI（記事中では「モデル」と表現される）がドキュメント作成に関わるようになると、この問題はさらに深刻になる可能性がある。AIは流暢な文章を生成する一方で、その内容が未検証の主張を含んでいても、レビュー担当者がそれを深く確認せずに承認してしまうリスクがあるからだ。

この記事では、そうした課題を解決するために、ドキュメントの各セクションに対してAIがどこまで記述してよいか、また人間がどこまで責任を持つべきかを明確にする「権利階層（Drafting Rights）」というアプローチを提案している。その根底にある考え方は非常にシンプルだ。AIが書くことを許されるのは「ソフトウェアが現在どのように振る舞うか」という事実の記述に限定し、「将来どうなるか」といった約束事や法的な義務は決して書かせない、というものである。

このアプローチの最初のステップは、ドキュメントの内容をその「コミットメント（約束）」の度合いに応じて四つの階層に分類することだ。これはドキュメントのページ単位や製品領域単位ではなく、文脈に応じて各セクションがチームにどの程度の「約束」をさせるか、という観点で行われる。なぜなら、単なる記述内容は時間とともに古くなるだけだが、「約束」に関する内容は将来的に問題やインシデントに発展する可能性があるからだ。

第一の階層は「プロース（prose）」である。これは導入部、文章間のつながり、用語集の言葉、ナビゲーションに関する記述など、一般的な散文的表現を指す。これらの内容はAIがドラフトすることを許可される。特定の事実を述べるというよりは、読みやすさや理解の助けとなる部分であるため、人間による個別の責任追及は必要とされない。ただし、それでも事実に関するゲートチェックは通過する必要がある。

第二の階層は「メカニズム（mechanism）」である。これは現在のソフトウェアビルドがどのように振る舞うか、設定キー、コマンドラインインターフェースのフラグ、エラーの意味など、具体的な動作記述を指す。AIはこれらの内容を、信頼できる証拠（例えば、コードから自動生成された情報）に基づいてドラフトすることが許可される。しかし、最終的には指名されたレビュー担当者が、AIが参照した証拠ポインター（証拠の場所を示す情報）を確認し、その内容の正確性を承認する必要がある。

第三の階層は「コミットメント（commitment）」である。これはサポート期間、非推奨化の期日、価格、サービス品質保証（SLA）、ロードマップに関する文言など、具体的な「約束」に関わる内容を指す。これらの内容は、たとえ証拠があったとしてもAIがドラフトすることは許されない。必ず指名されたオーナー（責任者）が内容を承認し、その承認日を記録する必要がある。これは会社としての約束であり、将来にわたって責任を負うべき情報だからだ。

第四の階層は「義務（obligation）」である。これはセキュリティに関する姿勢、データ保持ポリシー、ライセンス、法的条件といった、より重い義務に関わる内容を指す。この階層もAIによるドラフトは一切許可されない。指名されたオーナーに加え、そのリスクを負うチーム全体が責任を持つ必要がある。コミットメントと義務の二つの階層は、AIが安易に生成してしまうと大きな問題に発展しかねないため、特に厳格な管理が求められる。

次に、この階層分けの決定を永続的に記録する方法として、docs-rights.ymlというマニフェストファイルをリポジトリのルートに配置することが提案されている。このファイルには、各ドキュメントファイル内のセクションごとにどの階層に属するかを明示的に記述する。例えば、「クイックスタートガイドのインストールセクションはプロース階層」「セキュリティドキュメントのデータ保持セクションは義務階層」といった具合だ。明示的にリストされていないセクションは、デフォルトで「メカニズム」階層とみなされる。これにより、AIに意図しない自由を与えてしまうことを防ぐ。このマニフェストファイルは、通常のコードと同じようにバージョン管理され、変更があればレビューされるため、AIの権利範囲を広げる変更は、人間の目を通して承認されることになる。

このシステムを実効性のあるものにするためには、単にマニフェストを置くだけでは不十分だ。そこで、リンター（コードの構文やスタイルをチェックするツール）と「再レビューレシート」の仕組みを組み合わせる。提案されているdocs_rights.pyというスクリプトは、ドキュメントの各セクションの内容をハッシュ値（データの同一性を確認するための短いコード）に変換し、前回のレビュー時に記録されたレシートのハッシュ値と比較する。もしセクションの内容に変更があれば、レシートは無効となり、人間による再レビューが行われるまでチェックが失敗する。

具体的には、commitmentやobligationといった人間が責任を持つべき階層のセクションについては、責任者の名前（owner）が記録されていること、そしてそのセクションのハッシュ値がレビュー時のものと一致していることを確認する。mechanism階層のセクションについては、AIが参照した証拠ポインター（evidence）が記録されていることを確認する。これにより、重要な情報が変更された際に必ず人間の承認プロセスが再度行われることを保証する。レシートにはオーナー、レビュー日、証拠ポインター、そしてレビューされた時点でのセクションのハッシュ値が記録される。このチェックは、ソフトウェアのリリースをブロックするCI/CDパイプラインの一部として組み込まれる。

さらに、ドキュメントのセクションに特定のキーワードが含まれる場合、そのセクションの階層を自動的に引き上げる「シグナル」によるエスカレーション機能も提案されている。例えば、「サポート」「SLA」「GDPR」といった単語が検出された場合、自動的にそのセクションを「コミットメント」や「義務」の階層に格上げする。これにより、人間が見落としがちなリスクの高い内容がAIによって安易に生成されることを未然に防ぐ。もし自動エスカレーションが誤りであると判断された場合は、人間がマニフェストファイルでその階層を上書きすることも可能だ。

実際にAIによるドラフト生成を行う際には、この階層システムが重要な役割を果たす。AIはマニフェストを読み込み、proseとmechanism階層のセクションのみをドラフト対象とする。もしページ全体が人間によるオーナーシップを必要とする階層（commitmentやobligation）であれば、AIは生成を行わずに処理を終了する。AIへの指示（プロンプト）には、コードから生成された「事実の塊」を含め、そして「サポート期間や価格などの約束事を発行しない」といった明確な拒否ルールを盛り込む。AIがそのような約束事を書こうとした場合は、例えば{{HUMAN_OWNED}}のようなプレースホルダーを出力し、人間による対応が必要であることを示す。

このシステムを導入することで、もう一つ重要なメリットが得られる。それは、「人間が書いたドキュメントの割合」をリリースごとに測定できることだ。バージョン管理システム（Gitなど）の差分情報から、どの階層のドキュメントがどれだけ変更されたかを計算し、人間が責任を持つ階層の変更が全体に占める割合を追跡する。この数値が不自然に減少している場合、本来人間が責任を持つべき「コミットメント」セクションが、AIによってドラフトされた散文に変わってしまっている可能性があることを示唆する。この指標をリリースノートと共に公開することで、ドキュメントの品質に関するチーム内の議論の質を高めることができる。

ただし、このアプローチにはいくつかの限界もある。マニフェストファイルが適切にレビューされなければ、階層の定義が陳腐化する。見出しが重複している場合、複数のセクションが一つとして扱われてしまう可能性がある。また、ドキュメントの書式変更（空白の調整など）でもハッシュ値が変わるため、内容が変わっていなくても再レビューが求められることがある。そして、このワークフローは、前提となる「事実チェック」を置き換えるものではない。例えば「メカニズム」階層のセクションが、階層としては適切でも、その内容自体が間違っている可能性は依然として残る。

このシステムが特に適しているのは、複数の開発者やチームが関わる比較的規模の大きいリポジトリである。全てのドキュメントを一人で書き、公開しているような小規模なプロジェクトでは、レビューレシートのオーバーヘッドがメリットを上回ってしまうため、導入は推奨されない。また、セキュリティや価格設定に関するドキュメントの責任者を明確にできないチームも、このシステムを導入するべきではない。なぜなら、明確な責任者の存在こそが、このシステムが機能するための最も重要な前提条件だからである。

このシステムを導入する際の最初のステップとしては、まず「現在のソフトウェアの動作」と「約束事」が混在しているようなページを一つ選び、そのセクションを提案された階層に分類してみることが挙げられている。実際に試してみると、チュートリアルの中に紛れ込んだいくつかの「コミットメント」文を発見することがよくある。これらはまさに、AIにドラフトさせるべきではない内容の典型である。