要約

  • IETF事務局は9月9日、標準化プロセスにおけるAI利用を議論するGeneral Area所属の非WGリストai-in-standardsを作った。執筆前の時点で、公開アーカイブにあったのは開設告知の1通だけだった。
  • IETF議長はIETF 126で、メーリングリストを作るだけでは足りず、コミュニティーの意見と意思決定を支える進行構造が必要だと述べていた。開設記録は、進行役、判断対象、成果の状態、正式手続きへの引き渡しをまだ定義していない。

「どこで話すか」は決まった

事務局の告知は簡潔だ。リストのアドレス、公開アーカイブ、購読先、General Areaへの所属、そして目的を示す。目的は、IETFの標準化プロセスでの人工知能利用を議論することだ。

この一歩には実務的な意味がある。AIをめぐるプロセス論は、全体会合、研究グループ、WG議長の会合、一般リスト、個々のInternet-Draftのスレッドなどに分散してきた。専用リストがあれば、参加者は内部事情を知らなくても入口を発見できる。後から参加する人も、何が提案され、反論され、修正されたかを一つの時系列で調べられる。

IETFのメーリングリスト案内は、日常作業の大部分がリストで行われ、多くが購読・投稿・閲覧に開かれていると説明する。非WGリストの指針によれば、新設には適切なArea Directorの承認が必要で、リスト管理者はモデレーターも務める。

つまり、これは出所不明の私的チャットではない。公式の運用主体と公開記録がある。一方で、公式に運用されることと、IETFを拘束する判断権を持つことは別である。

告知はai-in-standardsをWGやBoFとは呼んでいない。非WGリストが将来のWG形成を意図する場合もあるが、今回の告知はその目的を掲げていない。議長、進行役、コンセンサス判断者、成果物、期限、異議申立て先も記載されていない。これは公開文書から言える範囲を示すだけで、別の場所で準備が進んでいないという証明ではない。

7月に示された課題は二層あった

IETF 126全体会合の議事録では、7月22日にIETF議長Roman Danyliwが、AIはすでに草案の執筆とレビュー、リストや会議での交流、コード作成、コンセンサス形成を変えていると述べた。IESGは参加者、レビュー組織、WG議長から、現在の対応では不十分だという声を受けていたという。

その上でDanyliwは、簡単な答えと難しい仕事を分けた。メーリングリストを作るのは簡単だ。必要なのはさらに、コミュニティーの入力を集め、実務や規範についてコミュニティーが判断するための進行構造である。最終成果がRFCなのか、それ以上なのか、それ以下なのかも未定だと明言した。

この発言を納期付きの約束に変えてはいけない。IESGが特定の文書種別を選んだわけでもない。ただし、入口、進行、検討、判断、成果という機能の連鎖は公開された。9月の新設で入口とアーカイブはできたが、残りの連鎖は告知には現れていない。

区別がなければ、リスト上の活動が制度的権威を借りる。多く返信された提案が「IETFの方向性」に見え、管理者の投稿制限が内容上の判断と誤認され、進行役の要約が未解決の異論を閉じたように読まれる可能性がある。個人Internet-Draftを共有しただけでも、公式成果物のように受け取られかねない。

最初のアーカイブは評価ではなく基準点だ

本稿の調査を固定した時点で、ai-in-standardsの公開アーカイブに表示されたのは事務局の開設告知1通だった。この観測には時刻の限界がある。参加意欲が低いことも、今後静かなままであることも意味しない。

むしろ、出発点が明確である利点がある。今後の記録に、提案、証拠要求、実験案、進行役による整理、コンセンサス確認、他手続きへの移送、決定、無措置での終了といった型を付けられるからだ。送信時刻は順序を示すが、権限の型までは示さない。

RFC 9245は、一般IETFリストより適した専用の場があれば、議論を移す意義を説明する。新しい作業を持ち込むための案内では、関心を持つコミュニティーを作るための非WGリストは、DISPATCH、BoF、Area Directorのスポンサー、独立出版などと並ぶ一つの経路だ。リストができても、その先の経路はまだ選ばれていない。

Note Wellは、リストへの投稿に権利・開示・行動上の責任を結び付ける。しかし、それは投稿が人間だけで書かれたこと、技術的に正しいこと、IETFが支持したことを証明しない。「IETF Contribution」は出所と義務のラベルであり、真実性の認証ではない。

既存の議論は単純な賛否ではない

IETF 126で開かれたRASPRGの議題は、AIが言語などの障壁を下げ得る一方、少ない人間の労力で参加量を増やし、有限の専門家の注意力を圧迫し得ると整理した。会合メモには、より堅牢な規則、実験、明示的な方法論、制度的処理能力についての発言が残る。

これらは論点を豊かにするが、IETF全体の決定ではない。研究グループの討議、全体会合での議長発言、非WGリスト、将来のプロセス文書は、それぞれ別の証拠と権限を持つ。まとめて「IETFは決めた」と書けば、新しい場が処理すべき差異を先に消してしまう。

投稿数も結論を出せない。生成モデルなら、似た支持意見を低い追加費用で増やせる。企業が複数の人間による発言を調整することもできる。逆に、英語を母語としない参加者がAIを使って独自の技術的異議を正確に表現する場合もある。同じ件数が正反対の現実を覆い隠す。

RFC 7282が重視するのは、票数ではなく、争点と異議が実質的に検討されたかどうかである。判断には理由と判断者が必要だ。最終判断をリストで確認するという原則も、すべてのリストに無限定の決定権を与えるものではない。

小さな状態表が大きな誤読を防ぐ

必要なのは長大な憲章とは限らない。購読先とアーカイブの隣に、版管理された小さなフォーラム記録を置けばよい。

最初に範囲を示す。「標準化プロセスのAI」は、執筆、レビュー、翻訳、検索、コード、参加、モデレーション、会議運営、コンセンサス評価を含み得る。扱わない項目には、正しい移送先を示す必要がある。

次に役割を分離する。リストの技術管理、行動規範に基づくモデレーション、議題設定、未解決点の要約、コンセンサス評価は同じ権限ではない。モデレーターが投稿を止められても、実務規範を採択できるとは限らない。

提案には状態が要る。例えば「提起」「証拠待ち」「実験提案」「起草中」「GENDISPATCHへ移送」「IESGへ送付」「独立出版」「置換」「無措置」「異論を記録して終了」と区別できる。用語を決めるのはIETFだが、件数を進捗に見せないことが重要だ。

実験には問い、データ範囲、ツール版、誤検出、見逃し、人手確認、訂正方法、影響してよい判断を記録する。要約は元の異論へリンクし、他の手続きへ移る際は日付、受領者、権威の新しい状態を残す。

AIの利用法は変化が速いため、訂正履歴も欠かせない。最新版だけを上書きすると、過去の行動がどの規範に基づいたか検証できなくなる。

開かれた入口には、たどれる出口が要る

RFC 3935は、開放性を技術的能力、品質、関連性と結び付ける。専用リストは入口を開く。進行構造は、投稿を検証可能な争点に変え、適切な権限の場所へ送る。

新規参加者に必要なのは、非公開の紹介者ではなく公開された道筋だ。レビュー担当者には、すべてを同じ優先度で読む義務ではなく、何のレビューを求められているかが必要だ。IETFは「受領」と「支持」、「移送」と「採択」、「終了」と「コンセンサス」を書き分けなければならない。

9月9日の開設は確かな前進である。次に見るべき成果は、メールの量ではなく、議論を根拠ある処理結果へ変える接続記録だ。

情報源

  1. IETF事務局によるai-in-standards開設告知
  2. ai-in-standards公開アーカイブ
  3. IETF 126全体会合議事録
  4. RASPRG議題：AI in Standards Participation
  5. RASPRG会合メモ
  6. IETF非WGリスト指針
  7. IETFメーリングリスト案内
  8. IETFへ新しい作業を持ち込むための案内
  9. RFC 9245：IETF Discussion List Charter
  10. RFC 7282：IETFのコンセンサス
  11. RFC 3935：IETFの使命声明
  12. IETF Note Well
  13. Lu Heng：The Policy Mirror
  14. Lu Heng：Running Code Primary
  15. Lu Heng：Why BTW Media Exists