要約

  • IETF Toolsは2026年8月6日、AI支援で作られた大規模なpull requestが増えれば、提出コードを全行読む現在の方法がチームのレビュー能力に対する「サービス拒否」になり得ると説明した。これは将来の容量リスクであり、攻撃や停止が発生したという報告ではない。
  • 8月25日に組織共通のガイドへ実際に追加された規則は、全ての貢献をキューに入れ、一人以上の保守担当者が全行を読むというものだった。AI生成コードも、説明、分割可能なcommit、テスト、依存関係、ポリシー適合性に関する同じ要件を満たせば受け付けられる。
  • ガイドは人間による偽りの著作宣言を求めていない。提出者は、コードの目的と対象ツールへの適合を理解し、人間向け説明の全行を理解した上で、将来の不具合修正を引き受ける。
  • 将来、低影響コードの人間レビューを減らすなら、各例外について、分類者、対象、根拠、実際のレビュー範囲、AIの役割、merge承認者、保守責任、エスカレーション、rollback条件を記した「レビュー境界票」が必要になる。

大量生成が奪うのはCPUではなく保守時間である

サービス拒否という言葉から、多くの人はネットワーク帯域やサーバー負荷を想像する。IETF Toolsが示したのは別の資源である。理解できる人の時間だ。

8月6日のTools Updateは、ほとんどのシステムに対して、AI支援で書かれた大規模かつ野心的なPRが届き始めると予想した。提出者は短時間で大量の差分を作れる。ところが、受け入れる側は、その差分を既存設計、実データ、運用負荷、セキュリティ、将来保守の中に位置づけなければならない。

報告は、全行を読む現在の慣行を続ければ、それ自体がレビュー能力に対するサービス拒否になり得るとした。この表現を事実以上に拡張してはいけない。悪意あるPRがあったとは書かれていない。Datatrackerが停止したとも、AIコードがデータを壊したとも書かれていない。指摘されたのは費用の非対称性である。

公開プロジェクトであることは、どのような大きさの入力にも無制限の人的資源を割り当てる義務を意味しない。レビュー困難な提案を早い段階で断れることは、閉鎖性ではなく、運用継続の条件である。

採用された規則はレビューを減らさず、入口を整えた

8月の議論には二つの方向があった。

一つは、提出物を人間が扱える形にすることだった。高位の計画、個別に読める小さな単位、既存の書式、プロジェクトの戦略に沿うテスト、新規依存関係の説明、継続支援を約束する人を求める。

もう一つは、影響度によって確認方法を変える構想だった。高影響コードは人間が全行を読み続ける。低影響コードではテスト品質の評価、あるいは別のAIによる敵対的レビューにより多く依存する可能性がある。報告は、この構想全体がまだ検討中だと明記した。

実際に規則になったのは前者である。

8月25日のcommitに固定されたCONTRIBUTING.mdは、全ての貢献がレビュー待ちのキューに入り、一人以上の保守担当者が提出コードの全行を読むと定める。AI生成コードを禁止してはいない。同じ要件を満たすなら受け入れる。

commitの記録は2026年8月25日付で、リトリートで合意した貢献要件とAI向け指針を追加したことを示す。本稿の証拠期限に取得したmain上の現行ファイルは、この固定版と同一の内容だった。

さらに、9月1日のExecutive Director公開報告は、大規模またはAI生成の貢献を安全に取り込みながら、レビューにチームの大半の時間を使わないためにガイドラインを更新したと述べる。しかし、低レビュー階層を導入したとは述べていない。

ここでは、議論、採用、現行状態を分けて読む必要がある。将来案を既存制度として語れば、存在しない権限移譲を作ってしまう。

小さなcommitは礼儀ではなく拒否可能性を作る

採用された要件は、提出者に理解の準備費用を戻す。

PRの説明は規模に見合う詳しさが必要である。commitは個別にレビューできる大きさに分ける。コードはプロジェクトの既存様式に従い、変更部分はそのプロジェクトのテスト戦略に合うテストで覆う。新しい依存関係は明示し、必要性を説明する。コミュニティーのポリシー決定を必要とするなら、コードを先に入れて既成事実を作らず、その決定を先に終える。

小さなcommitが正しさを保証するわけではない。テストが通っても、前提が誤っていれば安全ではない。それでも、巨大な生成物を、検証可能な主張の列に変える効果がある。

一体化された大規模差分では、保守担当者は全体を受け入れるか、長時間読んだ後で全体を返すかの二択になりやすい。分割されていれば、新しい依存関係、データ変更、ポリシー前提の地点で止められる。拒否可能性があるからこそ、レビューは交渉ではなく制御になる。

また、説明の長さやテスト数を成熟度と取り違えにくくなる。AIは豊富な文章とテストを作れるが、重要なのはそれらが現実の制約と結びついているかである。

全行レビューが見ているのは「公開コード」だけではない

ガイドは、全行を読む理由として、保守可能性、効率、セキュリティ、データの完全性、ロジックの配置を挙げる。

開発環境で問題のないクエリが、本番データではSQLクエリの嵐になることがある。便利な依存パッケージが、更新、脆弱性、ライセンス、供給停止の負担を持ち込むこともある。あるファイルでは自然な判断が、別のサービスにある中核ロジックの重複かもしれない。

IETF Toolsの多くは公開情報を扱う。しかし公開データでも正確性は重要である。役職、文書の状態、会合資料、履歴といった記録が誤れば、秘密漏えいがなくても制度上の結果が変わる。

テストは、書かれた問いに対して強い証拠を出す。書かれていない問いには答えない。人間による読解も見落としを免れない。したがって、本来の論点はどちらが絶対に優れているかではない。どの証拠を、どの判断の代わりに使うかである。

現行制度はテストと全行読解を併用する。将来、テストを読解の代替にする場合は、その置換関係自体が記録対象になる。

人間の役割は作者ではなく、継続責任の引受人である

AI coding agentを使う提出者への指針は、注意深く限定されている。

提出者は、コードが何をする目的なのか、対象となるIETF Toolの中でどう位置づくかを理解しなければならない。人間向け説明は一行残らず読んで理解する。AIに説明や文書を書かせた場合は、独特の曖昧な言い回しを除き、簡潔な技術英語に直す。

ここで求められているのは、人間が全行を書いたという宣言ではない。該当箇所は、生成コードの全行を理解したと誓う文面でもない。規則を実際より強く言い換えると、責任の検証可能性が落ちる。

より重要なのはmerge後である。提出者は単に名前を置くのではなく、そのコードから生じた問題を修正することを約束する。守らなければ、コードを取り除かれ、将来の貢献を断られる可能性がある。

これは保守の保証金に近い。IETF Toolsの最終責任を提出者へ丸投げするものではないし、その人が永遠に対応できることも保証しない。それでも、大きな機能を入れた評価だけを得て、長期負債をチームに残す行動を難しくする。

信頼は履歴であって、コードの性質ではない

ガイドは、AIを使う常連提出者が時間とともに知られ、信頼されるようになると見込む。

過去に明確な説明を行い、指摘に応答し、不具合を修正してきた履歴は有用である。新規アカウントの巨大なPRと、継続して責任を果たした人のPRを、全く同じ未知量として扱う必要はない。

ただし、信頼は人物と関係に関する証拠であり、コードの無害性ではない。現行ガイドには信頼スコア、必要期間、レビュー免除、merge権限は書かれていない。全貢献を同じく読むうちは、それでよい。

信頼によって技術確認を減らす日が来たら、履歴が関係する項目だけに効果を限定すべきである。応答性、設計理解、保守継続性は履歴から推定できる。セキュリティやデータ整合性は、善意とは独立した証拠を要求する。

「低影響」を決める人は、例外を承認している

影響別レビューには合理性がある。

容易に戻せる表示調整と、認証、私的会合資料、標準メタデータ、メール状態、制度記録の変更に、常に同じ労力を使う必要はない。重要な面へ人間の注意を集中させることは、全体の信頼性を高め得る。

だが、低影響という性質はコードから自動的に現れない。

数行の処理が中核テーブルを書き換えることがある。保存を伴わない画面が、公開される制度状態を選別することもある。バイナリは戻せても、変更済みデータは戻らないかもしれない。小さなコード量と小さな結果は別物である。

誰かが分類対象を決め、損害の種類を選び、不確実性を受け入れ、エスカレーション要否を判断する。分類者はラベルを付けるだけではない。別の証拠基準を使う権限を行使している。

提出者が自分で決めれば、低く見積もる誘因がある。キュー管理者には処理量を増やす圧力がある。長時間読んだ保守担当者は、疲労から可逆性を楽観視するかもしれない。データ、認証、セキュリティ、制度記録、移行に触れる場合は、別の責任者による確認を必須にする方が、複雑な単一スコアより有効である。

例外にはレビュー境界票を残す

低レビュー経路の透明性は、promptやcredential、悪用可能な脆弱性情報を公開することではない。例外を正当化した判断状態を残すことである。

最初に、repository、component、影響を受けるserviceまたはrecord surface、PR、正確なcommit群を記録する。提出の由来は、人間主体、AI支援、主にagent生成といった実用的な区分でよい。機械著作率を精密に装う必要はない。

次に、継続責任を負う人、影響分類、分類者、日付、適用したpolicy versionを示す。security、data integrity、privacy、performance、availability、standards record custody、reversibilityは別々に評価する。一つの数値に畳むと、最も重要な前提が見えなくなる。

証拠欄では、計画、test strategyとcoverage、新規dependency、performance evidence、security check、data migration、staged deployment、rollback demonstrationを、対象リスクと結びつける。「tests passed」だけでは足りない。テストへの依存を高める決定なのだから、何を検証していないかも必要である。

レビュー欄は予定ではなく実績を示す。どの範囲を人間が全行読んだか、誰が読んだか、何を読まなかったか。別のAIを使ったなら、閲覧できた入力、探索範囲、未解決findingsを残す。AIは証拠を生成するが、merge権限を持たない。

最後に、人間のmerge approver、deployment owner、maintenance owner、完全レビューへ切り替える条件、monitoring period、rollbackまたはremove triggerを記す。後から分類を変えても、当初判断は上書きしない。

現行の全行レビューを受ける通常PRでは簡易票でよい。詳細票は例外に限定する。監査が再び保守時間を枯渇させてはならない。

二つ目のAIは反論者になれても、事故当番にはならない

別のAIによる敵対的レビューは役に立ち得る。境界条件、未テスト経路、不審な依存関係、ファイルをまたぐ矛盾を大量に探索できる。

9月の公開報告には、AIの効用を示す別の事例がある。Datatrackerの二つの深刻なperformance problemについて、従来なら数週間から数か月かかり得た診断が数時間に短縮され、迅速な緩和と後日の実質修正につながったという。

これはAIが事故を起こしたという記録ではない。同時に、診断で成果を出したことはmerge承認権の根拠にもならない。

二つのmodelが同じ前提、同じcontext不足、似たcoding patternを共有する可能性がある。対抗的なpromptは検討の摩擦を増やすが、損失を負う独立主体を作らない。modelは障害対応をせず、データを修復せず、数年後の保守をせず、例外の説明責任を負わない。

したがって、machine reviewは範囲付きの証拠として保存し、最終判断者を人間として明記しなければならない。

ツールの運用権限と標準の決定権限を混ぜない

Tools Teamの公式ページは、同チームをIETF Administration LLCの下に置き、IETF活動を支えるapplicationsの開発と運用を担うと説明する。参加者はこれらを使って標準を書き、議論し、公開する。完全性が重要なのは当然である。

しかし、重要な運用を担うことと、標準内容を決めることは同じではない。

RFC 8711は、IETF LLCに継続運用の責任を与える一方、IETFのstandard development activityに対する権限はないと明記する。ガイドが、community policy decisionを要する変更はその決定後に提出するよう求めるのも、この境界に沿っている。

低影響分類が、争われている規則をsoftwareへ先に埋め込む抜け道になってはならない。保守担当者は確定したルールの実装を判断できるが、実装の小ささによって未決の政策を確定できない。

Heng LuのRunning-Code Primacyをここで狭く用いるなら、実際の運用状態と検証可能な証拠が制度的主張を拘束する、という意味になる。稼働したコードがIETFの標準手続きを上書きするという意味ではない。誰が、どの証拠で、そのコードを稼働可能としたかを、行政ラベルで隠さないという意味である。

インターネットガバナンスのagency problemという視点は、利害のずれを示す。提出者は採用を望み、agentはもっともらしい完成物を生成し、queue managerはbacklogを減らし、reviewerは作業を終えたい。長期の損失は運用者とcommunityが負う。境界票は利害を消さないが、「AI contribution」という一語へ責任が溶けるのを防ぐ。

最初の例外を書くまで、現在の線を保つ

確認した記録には、IETF Toolsが既にレビューを減らした証拠も、悪意あるAI contributionを受けた証拠も、ガイド違反の証拠もない。

確認できるのは、レビュー経済が拡張しにくいと認識し、まず入力品質と継続責任を引き上げ、全行読解を残したことである。より大きな制度変更は検討中にとどまる。

次の規則を「human in the loop」という曖昧な言葉で済ませてはいけない。要約だけを見てbuttonを押す人も、形式上はloopにいる。必要なのは、誰が分類し、どこを読み、何を読まず、どのmachine evidenceを採用し、どのversionに基づき、問題時に何を引き受けるかである。

AIが可視化したのは、生成量と受入能力の差だ。その差を埋める時、レビュー量だけでなく責任の所在まで削ってはならない。