要約

  • draft-moonesamy-authorship-ietf-00は2026年9月9日に公開された有効な個人Internet-Draftであり、IETF採択文書でも確定方針でもない。
  • draftは、生成AIを用いた執筆に手続上の指針を設けるべきかを問い、短い即席の応酬から「人の要素」を感じ取る方法を示している。
  • 会話は提案への理解を試せる。一方で、本文の由来、掲載への同意、権利確認、ツール利用の範囲、各改訂への長期責任は証明できない。
  • それらを混ぜないため、私は重要な改訂ごとの著者記録を提案する。これはDaniel Kadeの統治案であり、二つの現行draftが求める手続ではない。

リポジトリに置かれたのは結論ではなく論点だ

Datatrackerによると、Reflections on IETF Authorshipの00版は9月9日11時19分UTCに登録された。ActiveかつI-D Existsだが、RFC stream、担当Area Director、IESGでの処理日程はいずれもない。IETFの公開説明が示すとおり、Internet-Draftは誰でも提出できる。個人提出がリポジトリに載っただけでIETFの見解になるわけではない。

この限定を外すと、記事そのものが草案の問題を再現してしまう。文書は、著者、編集者、貢献者、謝辞の扱いをめぐる過去の議論をたどり、RFCでは実在の個人が功績と非難の双方を引き受けてきたと述べる。そのうえで、共同体の合意を表すIETF stream文書と、表紙に並ぶ個人名の関係を生成AIの時代に問い直す。

00版は、生成AIを使って書かれた仕様を共同体が採用・実装してよいのか、著者や編集者の裁量だけでなく手続上の指針が必要か、と問う。しかし、開示基準、判定主体、著者試験、是正措置、異議申立ては定めていない。2026年に-00提出が増えた理由を、生成ツールが執筆技能の敷居を下げたためかもしれないとする説明も著者の見方だ。IETFが確立した因果関係や品質評価ではない。

具体案は、著者との素早い「切り返し」の議論である。用意した原稿に大きく頼れない応酬なら、作業部会は人の関与を感じられるかもしれない。これはレビューの発想として読めるが、著者資格の規則ではない。

その場で説明できることと、書いたことは別だ

即席の技術対話には強みがある。前提同士をつなぎ、反例に答え、範囲外を認め、なぜ別案を採らなかったかを説明しなければならない。文書を暗唱するだけでは隠れる理解度や未解決点が見える。

ただし、その観測が示すのは一時点の説明能力である。他人が起草した仕様を深く理解する人はいる。主要著者でも即答が苦手なことはある。ある節を担当した貢献者が、全体をまとめた編集者よりその節に詳しい場合もある。母語、障害、時差、会議形式は口頭の速さに影響するが、技術的な寄与や責任を自動的に増減させない。

会話から本文の履歴を逆算することもできない。どの段落を人が書き、どこを旧RFCから再利用し、どこに生成ツールが関与し、レビュー後に誰が改めたかは残らない。掲載された全員が同意したか、引用元を認めたか、提出者がBCP 78とBCP 79の表明を行う根拠を持っていたか、次版も同じ分担だったかも分からない。

したがって結果は限定して保存すべきだ。「この人はこの時点で提案を説明し、異論に応答できた」。そこから「この人が全文を作成し、確認し、引き受けた」とは推論しない。良いレビュー手段を、来歴の代用品に変えてはいけない。

現行制度も氏名と合意を同じものとはしていない

2021年の有効なIESG声明は「surprised authorship」を明確に退ける。本人の同意と重要な寄与なしに著者・貢献者へ加えてはならず、著名な名前で支持を装う行為は誤解を招く。これはBCP 78、BCP 79に関する提出者の表明にも影響する。

RFC 7322では、著者・編集者を誰にするかは各streamが決める。表紙は通常五人までで、それを超える場合は承認主体が、少数の責任編集者と貢献者・謝辞に分けるべきか検討する。掲載者はAUTH48で最終確認し、後のerrataなどの照会にも対応する。2024年のIESG声明も、寄与の大きさに応じて著者、貢献者、謝辞を区別している。

これらの氏名は共同体の投票数ではない。RFC 8789がIETF stream文書の正統性をrough consensusに置くからだ。起草、氏名掲載、作業部会の受入れ、streamの承認、実装は重なることがあっても別々の状態遷移である。

隣接する現行個人draft、Principles and Guidelines for Assignment of RFC Authorshipの06版も重要だ。著者・編集者は内容と知的財産の責任を負い続け、AIツールを著者にしてはならないとする。AIが実質的な部分を生成した場合の開示は、なお明示的なopen issueである。政策作業が存在することと、義務が確定したことを混同してはならない。

必要なのはAI判定器ではなく改訂の責任票だ

会議を口頭試問に変える必要はない。証拠ごとに役割を絞ればよい。対話は理解とレビューを示す。変更履歴は文章への寄与を示す。明示的同意は氏名と役割の受諾を示す。権利記録はContributionに関する表明を示す。issue、議事録、判断記録は、本文がどの手続で受け入れられたかを示す。

重要な改訂ごとの簡潔な著者票には、責任著者・編集者と同意、重要な人的寄与と再利用文、節または変更単位のソフトウェア支援範囲、人が行った検証と残る不確実性、本文を受け入れた手続判断、streamレビュー開始時とAUTH48での責任再確認を残せる。

これは文体からAIを検出する仕組みではない。スペルチェックと技術節の大規模生成を同一視せず、欺瞞を推測しない。参加者が確認できる行為だけを記録し、最終的な著者名簿を決める各RFC streamの権限も保つ。

適正なツール利用も守られる。翻訳や文法支援ならその限定範囲を、実質的生成なら生成後の検証と責任の経路を示せる。機械を著者に仕立てる必要はなく、共同体も口調や文章の癖から制作過程を当てる必要がなくなる。

情報源