要約

  • draft-fengfar-led-01 は、AIを使う前に自分の立場を定め、出力がその立場に忠実かを確認し、「常に透明」であるよう勧める。ただし現在は個人によるInternet-Draftで、IETFの方針ではない。
  • 対象はメール、会議スライド、GitHubのissueやpull request、場合によってはインスタントメッセージである。BCP 78とBCP 79にも関係するInternet-DraftとRFCの本文は明示的に除外される。
  • 有効な開示には、責任を負う人、ツールの機能、対象範囲、資料の境界、事実と忠実性の確認、最終承認、自動送信の有無、訂正経路を貢献単位で残す必要がある。

送信者の名前だけでは工程は見えない

標準化の議論では、署名のあるメールは長くアーカイブに残る。だが末尾に「AIを使用した」と一行加えても、読者が必要とする説明はほとんど増えない。

翻訳だったのか。過去のスレッドを探したのか。反論を作らせたのか。文章全体を下書きさせたのか。ツールは一部の主張だけに触れたのか。送信前に人が事実と引用を確認したのか。自律的に投稿できたのか。

draft-fengfar-led-01 の短い勧告「Always be transparent」は正しい方向を向く。しかし、草案自身が具体的勧告を「極めて暫定的」と呼び、結論で判断にはまだ早いと記す。強い主張は、メールによる議論への信頼が薄れる前にIETFが指針を検討すべきだ、という点にある。

Datatracker上では、同草案はactiveな個人Internet-Draftで、IESG stateは I-D Exists。RFC stream、担当Area Director、telechatの日付はない。7月31日の最初の投稿は、作業を粗く、非規範的で権威を持たないものと説明した。8月6日の01版は一般討議リストの論点を取り込んだが、Working Group採択、rough consensus、IESG承認、IETFの規則のいずれでもない。

8月26日にはGeorge MichaelsonがAPNIC Blogでこの議論を取り上げ、英語で標準やRIRポリシーに参加する負担とAI支援を結び付けた。ページには、見解が著者個人のものでAPNICを必ずしも代表しないとの注記がある。注目が広がったのであって、権限ある決定が増えたわけではない。

適用範囲を曖昧にしてはいけない

草案が扱う「IETF discussions」は、メール、会議スライド、GitHubのissueやpull request、そして将来はインスタントメッセージを含み得る。一方、Internet-DraftとRFCの本文は対象外とされる。それらにはBCP 78とBCP 79の貢献および知的財産の仕組みも関わるからだ。

この線は重要である。メール向けの将来指針ができても、標準文書内の著者性や権利処理まで自動的に決めることにはならない。逆に、草案の謝辞でツール利用を明示しても、その周囲の多数のメールが翻訳、要約、生成、自動送信のどれだったかは分からない。

草案の出発点にも同じ問題がある。ある参加者は、先に自分で作った考えを表現しやすくするためAIを使った。読み手はLLMらしい文章を感じ、人の寄与が見えないため読むのをやめた。著者らはどちらかを断罪せず、二つの視点を並べる。欠けているのは共有可能な規範である。

人の立場を先に形成すること、出力が立場に忠実かを文法以上の水準で確認すること、自分の名前で送る内容に全面的な責任を負うこと。この境界は有用だ。ただし、責任という原則だけでは、後から検証できる責任記録にはならない。

誰かの速度は、別の誰かの負担になる

言語支援には明確な包摂効果がある。技術的な考えの正確さと、英語として自然に書く力は別物だ。翻訳や編集により、参加者は表現よりプロトコルの論点に時間を使える。

同じ機能は負担を読み手側へ移す。一人が短時間で長く整った回答を作れても、複数の読者は出典を調べ、実際の争点を探し、送信者が主張を理解しているかを判断しなければならない。エージェント同士が応答すれば、独立した判断なしに「多くの関心」が存在するようにも見える。

一般的なAIラベルはこの非対称を説明しない。完成済みの立場を翻訳したのか、未確認の事実を作ったのか、過去の合意を要約したのか、返信全体を生成したのか、最終確認なしで投稿したのかを区別しない。

文体を証拠にすることもできない。草案は長大な文章、不自然な確信、声の変化への懸念を記録するが、それらは来歴ではない。流暢な英語、速度、検出器の点数を証明扱いすれば、第二言語で書く人や支援技術を使う人を疑う構造になる。検出は推測、開示は帰属可能な申告であり、どちらも内容の正しさを保証しない。

隣接する三つの制度は同じ規則ではない

RFC 9775はIRTF Code of Conductで、IRSGのコンセンサスを表す。同時に、IETFの成果物でも標準でもないと明記する。IRTFの範囲では、生成AIを著者にできず、大量の生成テキストなどはシステムと寄与方法を例示して開示する必要がある。一方、綴り、文法、翻訳、表現改善は開示不要である。

2026年3月のW3C Advisory Board Group Noteは別の境界を置く。主にLLMが出力した内容に明確なラベルを求め、個人が正確性を確認し、機密を守り、自動応答で熟議を置き換えないよう勧める。これはAdvisory Boardが支持したNoteで、W3C全体やMembersの支持を意味しない。

IRTFの「significant amounts」、W3C文書の「primarily output」、IETF個人草案の「always be transparent」は、同じ世界規則の言い換えではない。異なる権限の下にある異なる閾値であり、IETFは境界を明示せず借用できない。

Daniel Kadeが提案する責任記録

最小単位は、人の属性ではなく、個別の貢献に付く記録である。

まず人間の送信者と安定した貢献IDを置く。次に、翻訳、編集、要約、下書き、検索、分析、コード、モデレーション支援、自動送信というツールの機能を示す。そして、メッセージ全体、特定節、添付、コード片、特定の主張という対象範囲を結ぶ。

資料の境界も分類する。公開資料だけか、本人のローカルノートか、機密情報か。分類は資料そのものの公開を意味しない。完全なプロンプト、認証情報、私的な検討、非公開草稿、専有情報、思考過程を要求すれば、透明性が新たな情報漏えいになる。

人が行った確認を続ける。どの事実資料と引用を確かめたか。文章が本人の実際の立場に忠実かを見たか。最終版を人が承認したか。ツールに自律送信権限があったか。最後に、適用されたポリシーの版と日付、誤った開示や貢献を訂正・置換する経路を残す。

モデル名は補助情報にすぎない。提供者は製品名を変えずに挙動を更新できる。何より、モデル名はプロトコル理解、引用確認、責任受諾を証明しない。

これはDaniel Kadeによる提案であり、現草案の要件ではない。目的はツール実行を監査可能にしながら、判断の主体を人に保つことだ。

モデレーションより定義が先である

RFC 9245は一般討議リストを定義し、より適切な場がない場合にIETFの方向、方針、標準プロセスを扱う。RFC 9945は公開オンラインフォーラムで、参加者、管理者、モデレーター、Area Director、IESGの責任を分ける。措置をdisruptive communicationに限定し、公開手続、再考、上訴を設ける。

どちらもAI著者判定器を作っておらず、AIらしさを単独違反にしていない。将来の開示をモデレーションに結び付けるなら、制裁より先に閾値、証拠、通知、訂正、上訴を定める必要がある。そうしなければ文体への疑いが手続的権力になる。

草案は疑わしい利用について非難しない質問を勧める。また、新規参加者が新ルールを知らない可能性や、ツール利用可能性の差が新たな障壁になる点も記す。したがって、機能と範囲を定義し、責任記録を試し、読者負担が減るか測り、その後に未開示を助言、プロセス違反、妨害行為のどれとして扱うかを決めるべきだ。

ラベルを発言許可証にしてはならず、ラベルの不在を欺瞞の証明にもしてはならない。

証拠から言えないこと

IETFはAI支援による参加を採用も拒否もしていない。生成文が実際のコンセンサス結果を変えた証拠はない。現在、すべての支援メッセージに開示義務があるとも言えない。

RFC 9775はRFC SeriesにあるというだけでIETFの通常議論を支配しない。W3C Group NoteはW3C Membersのコンセンサスではない。APNIC Blogの記事はAPNICの方針ではない。特定の参加者が著者性を偽った、または自律送信させたと示す証拠もない。

限定的な結論は、草案が責任主体を正しく人に置いた一方、読み手が責任を調べる記録は未定義だということだ。「常に透明」は方向である。対象、権限、証拠、訂正経路が具体化して初めて、方向が統治になる。

出典

  1. https://datatracker.ietf.org/doc/draft-fengfar-led/
  2. https://www.ietf.org/archive/id/draft-fengfar-led-01.html
  3. https://mailarchive.ietf.org/arch/msg/ietf/3VaBJ6pEdhtkpOtnZYA_HcVHejU/
  4. https://mailarchive.ietf.org/arch/msg/i-d-announce/_nalEUgYdyn7LdNfwQghXW9dPRc/
  5. https://blog.apnic.net/2026/08/26/the-emerging-role-of-ai-in-governance-discussion/
  6. https://www.ietf.org/rfc/rfc9775.html
  7. https://www.w3.org/TR/2026/NOTE-llms-standards-20260324/
  8. https://datatracker.ietf.org/doc/html/rfc9245
  9. https://datatracker.ietf.org/doc/html/rfc9945
  10. https://datatracker.ietf.org/doc/html/rfc5378
  11. https://datatracker.ietf.org/doc/html/rfc8179