要点

  • 2025年8月18日に発効したW3C Processの5.9節は「Do you approve of the Decision?」と問い、Approve、Reject、Abstainの三つを回答として示す。
  • 同じ節は、参加率ごとの比率でApproveがRejectを上回ると異議申立て投票が通ると定め、その次の文で、投票が通れば決定は覆されるとする。文字どおりなら、決定への賛成が決定を取り消す力になる。
  • 2023年版では、RejectがApproveを上回ったときに決定が覆るため、問いと効果が同じ方向を向いていた。pull request 901はこの判定をApprove中心の段階式閾値に差し替えたが、問いと取消し効果は残した。
  • 閾値の政策目的は妥当である。参加率5%未満は不成立、5%以上15%以下は3倍を厳密に超える差、15%超20%未満は2倍を厳密に超える差、20%以上は単純な優越が必要となる。明示的な棄権は参加率に含まれる。
  • 公開された理由は、低参加率のわずかな多数で重大な決定が動くことを防ぎ、BylawsのRequisite Member Voteを応用することだった。決定を承認する票が決定を覆すという方針転換は告知されていない。
  • 調査した公開資料は、この文言に基づく実投票が行われたこと、投票設定や集計に誤りがあったこと、既存の決定が誤って維持または取消しされたことを示していない。
  • W3Cは、正確な設問、各選択肢の対象、Good Standingの母数、参加率帯、厳密不等式、境界テスト、集計結果、決定の状態、Processの版、更正履歴を投票設定から出力する公開記録を設けるべきである。

異議申立てで「文脈を読め」は通用しない

通常の会議で表現が少し揺れても、参加者同士の共通理解で補えることはある。しかし異議申立ては、通常の合意形成が破綻し、決定の存続そのものが争われる場面に用意された制度である。そこで投票者に文脈を読ませることは、制度の役割を逆転させる。

5.9節の入口は、役割を比較的明確に分けている。Good StandingにあるMemberのAdvisory Committee代表者が、対象となる決定から3週間以内に異議申立てを開始する。Teamは1週間以内にそれを告知する。その後1週間以内にAdvisory Committeeの少なくとも5%が申立てを積極的に支持すれば、投票が行われる。

この5%は審理への入口であって、本案の勝敗ではない。少数の代表者には問題を全有資格者に諮る権限があるが、それだけで元の決定を覆す権限が生まれるわけではない。

本案の投票では、設問が具体的に記される。「Do you approve of the Decision?」。尋ねているのは異議申立てへの承認でも、取消し動議への承認でもなく、Decisionへの承認である。回答はApprove、Reject、Abstain。Memberまたは関連Memberの一群につき一票で、5.9節の集計対象はGood StandingにあるMemberの代表者である。

続いて参加率が閾値を決める。明示的なAbstainは、ApproveとRejectのどちらにも入らない一方、参加率には入る。参加率が5%に届かなければ不成立。5%以上15%以下なら、ApproveはRejectの3倍を超えなければならない。15%を超え20%未満なら2倍を超え、20%以上ならRejectより多ければよい。

最後に、「投票が通れば決定は覆される」と置かれる。

設問、回答ラベル、算式、効果はそれぞれ明確に見える。しかし同時には実行できない。DecisionをApproveするなら、その票は決定の維持を意味する。異議申立てをApproveするなら、設問が別の対象を指している。どれか一つの意味を運用者が黙って置き換えなければ、状態遷移は閉じない。

数値を通すと、反対の決定が出る

参加率が20%以上の投票を想定する。Approveが12、Rejectが8なら、現行の算式では12が8を上回るため可決である。次の文に従えば、元の決定は覆る。ところが設問に対する回答としては、決定を承認した代表者の方が多い。

Approveが8、Rejectが12なら不成立となり、決定は残る。決定をRejectした代表者が多数なのに、異議申立ては敗れる。

参加率5%以上15%以下の帯でも同じ反転が起きる。Approve 16、Reject 5なら16は15より大きく、可決となる。Approve 15、Reject 5なら不成立である。「exceeds」は厳密な超過を意味し、ちょうど3倍では足りないからだ。

これらは実在の投票結果ではなく、規則に対する仮想テストである。誰がどの立場を支持したかを持ち込まず、入力と出力の関係だけを確かめている。

Abstainはもう一つの境界を動かす。決定的な二つの票数が同じでも、明示的棄権が増えれば参加率帯が変わり、必要な倍率が下がる可能性がある。そのため、結果の検証には有資格Member数、参加者数、棄権数、Approve数、Reject数、適用した帯と厳密不等式の全てが要る。

「過半数で可決」とだけ発表しても、権限が正しく作動したかは再現できない。算数の正確さは、何を数えているかの誤りを補正しない。

2023年版では極性が一周していた

2023年11月3日版のProcessは、同じ設問と同じ三つの選択肢を使っていた。ただし、RejectがApproveを上回ると決定が覆ると定めていた。

ApproveはDecisionの承認、RejectはDecisionの拒否。Rejectが多数なら異議申立てが成功し、成功した異議申立てがDecisionを覆す。簡素だが、言葉の向きは最初から最後まで変わらない。

一方、この旧ルールは参加率が極端に低い場合を特別扱いしなかった。わずかなMemberしか参加していないのに、51対49の差で重大な決定が覆るのは適切か。2025年の変更は、この実質的な問題への回答だった。

pull request 901の公開diffを見ると、どこで線が切れたかが分かる。RejectがApproveを上回るという旧判定を削除し、ApproveがRejectの3倍、2倍、または単純に上回るという段階式の判定を挿入している。その直後の「通れば決定を覆す」は維持され、前にあるDecisionへの承認質問も維持された。

この履歴は、意図を断定せずに欠陥を特定できる点で重要である。変わったのは閾値を満たす側であり、設問の目的語と通過後の効果は変わらなかった。

issue 886とpull requestの説明は、低参加率における薄い多数で重大な判断が動くことを問題にする。W3Cの2025年更新告知も、低参加率の異議申立て投票により高い閾値を導入したと説明する。どの資料も、ApproveをDecisionへの承認から異議申立てへの承認へ付け替えたとは述べていない。

したがって、公開記録から言えるのは、可視の編集で規範文に極性の衝突が生じたことまでである。故意の反転や、実在する投票の操作を示す証拠ではない。

Bylawsでは肯定票の対象がずれていない

段階式閾値の元になったW3C Bylaws第III条第11節は、法人としての肯定的行為に必要なRequisite Member Voteを定義する。

出席または代理されるMemberが15%以下なら、肯定票は少なくとも75%必要である。15%を超え20%未満なら少なくとも3分の2、20%以上なら過半数となる。

参加者が少ないほど、その中で強い一致を求める。参加者が増えれば、通常の多数で行為を承認できる。欠席を反対票とみなさず、小さな活動層だけで重大な行為を決めることも防ぐ。制度設計として筋が通っている。

しかもBylawsでは、affirmative voteが承認するのは、Memberに提示された法人行為そのものである。肯定の対象と効果が一致する。

異議申立て投票には二つの整合的な設計があり得る。Decisionを承認するかと問うなら、Rejectが取消し側であり、Rejectが段階式閾値を満たすべきである。異議申立てまたは取消し動議を承認するかと問うなら、Approveが取消し側となり、現在の算式を使える。

現行5.9節は前者の設問と後者の算式をつないだ。閾値の高さは移植したが、肯定票が何を動かすのかを合わせなかった。

境界にも差がある。Bylawsの「少なくとも75%」なら15対5を含む。Processの「3倍を超える」では、15は15を超えないため含まれない。実際の投票記録は、参照元の理念だけでなく、採用した演算子まで示す必要がある。

W3Cに有利な読み方をしても、文は直らない

最も強い反論は文脈である。これは異議申立てであり、申立人は元の決定を変えたい。2023年版では取消し側がRejectだった。公開された改定理由は、取消しに必要な支持を低参加率時に強めることだ。経験ある運用者なら、実際の投票画面で「異議申立てを承認するか」と問い直すか、「決定を維持する」「決定を覆す」と結果を直接表示するだろう。

ソースは公開され、版管理され、修正可能でもある。現在のEditor’s Draftにも同じ文言があるため、修正経路は見える。本稿の調査範囲では、2025年形式の実投票、誤設定、誤集計、具体的損害はいずれも確認されていない。

この反論は、主張の範囲を正しく狭める。しかし規範の矛盾を解消しない。

組織内の常識は、決定規則ではない。投票を作る担当者が、Approveの目的語をDecisionからAppealへ独自に付け替えるなら、その設定がMemberの権限を実質的に定義する。担当者が誠実に最善の判断をしても、公開Processから再現できない委任は残る。

しかも問題が表面化するのは、結果が僅差で、参加率が境界に近く、敗者が文言を精査するときである。争われない場合にだけ通じる規則は、異議申立て規則として弱い。

支持者名簿を公開しなくても権限は検証できる

最初の5%支持、後の参加率、最後の賛否は別の量である。申立人は制度を起動する。支持者は投票への入口を開く。全有資格のAdvisory Committeeが本案を決める。Teamは手続を運用する。元の決定機関と、それを信頼して作業するWorking Groupや実装者が結果を受ける。

W3Cの公開ガイドは、申立人が対象決定と理由を示すのを助けるが、投票の極性を定める規範ではない。支持声明のアーカイブがMember限定であることも、集計根拠まで秘密にすべき理由にはならない。

個人の選択を明かさず、有資格者数、参加者数、明示的棄権数、ApproveとRejectの総数、適用帯、式、決定の最終状態を公表できる。投票の秘密と制度権限の可視性は両立する。

Heng Luがマルチステークホルダー制度について示す区別は、ここでも有効である。参加は情報を生み、明確な規則の中で権限を生む。しかし参加したという事実だけでは、誰のための判断か、何を判断したか、誰が結果を負うかは決まらない。精密な閾値も、目的語のない委任を正当化できない。

投票画面と同じ設定から記録を作る

W3Cは各AC異議申立てについて、投票開始前に「投票極性適合記録」を公表すべきである。投票後に人が説明文を書くのではなく、代表者が見る投票画面を生成する同じ設定から出力する。そうして初めて、公開された命題と実際に投じられた票が一致する。

記録には少なくとも次を含める。

  • 対象決定の識別子、名称、決定権者、告知時刻、正規URL
  • 異議申立ての識別子、申立人の資格状態、5%支持ゲートの集計結果
  • 適用するProcessの版と節
  • 省略のない投票設問
  • 各回答ラベルと、その対象がDecision、Appeal、取消し動議のどれか
  • どの回答が決定を維持し、どの回答が覆すかの明示的対応
  • Good Standingにある有資格Memberの母数と確定時刻
  • 参加者総数と明示的Abstain数
  • 適用帯、算式、等号を含むか否か
  • 各境界の近くで通る例と通らない例
  • 最終集計、実際の計算、投票結果
  • Decisionが維持、取消し、未確定のどれになったか
  • 訂正、後継文書、暫定解釈と、その結果に依拠した後続行為
  • 個人情報をMember限定に保つ範囲

これは新しい拒否権ではなく、Processをメタデータで置き換えるものでもない。投票者の権限が流れる前に、規範、ツール、結果状態が一致していると証明する統制である。

事前公開なら訂正も安い。Decisionを承認する設問なのにApproveが取消しへ接続されていれば、投票前に指摘できる。投票後の訂正は、既に投じた一票一票が何を意味したかという解けない問題を作る。

二つの修正経路

第一の経路は、現行の設問を維持する。「Decisionを承認するか」と問うなら、Approveは決定を維持する。取消し側のRejectが参加率に応じた倍率でApproveを上回ったとき、異議申立てが通るよう式を直す。

第二の経路は、現行の算式を維持する。「異議申立てを承認するか」または「指定されたDecisionを覆す動議を承認するか」と問う。Approveは取消しを支持し、閾値を満たせばDecisionが覆る。

本稿はW3Cに代わって法的な文案を選ばない。定義語、投票ツール、制度上の慣行との接続はW3Cが決めるべきである。ただし、承認する対象、閾値を満たす側、可決後の状態が同じ方向を向くことは譲れない。

2026年8月31日の調査時点で、2025年8月18日版がW3Cの公開する現行Processであり、現在のEditor’s Draftも同じ衝突を残す。公開履歴は文章上の欠陥とその由来を示すが、実際の誤集計、故意、既存決定の無効を示さない。

被害が起きたと作り話をする必要はない。実際の異議申立てが来る前に、検証可能な形で直せばよい。

情報源

  1. W3C Process Document 2025年8月18日版、5.9節
  2. 現行W3C Process Editor’s Draft、5.9節
  3. W3C Process Document 2023年11月3日版、5.9節
  4. W3C Process pull request 901：参加率に応じた段階式閾値
  5. pull request 901で閾値を導入した最初のcommit
  6. W3C Process issue 886：AC異議申立ての閾値調整
  7. W3Cによる2025年Process更新の告知
  8. W3Cガイド：W3C Decisionへの異議申立て
  9. World Wide Web Consortium, Inc.のAmended and Restated Bylaws
  10. W3C Process issue 1034：AC異議申立ての期限
  11. W3C Process for Busy People：AC Appeals
  12. Heng Lu — The Multi-Stakeholder Mirage
  13. Heng Lu — On the Agency Problem at the Core of Internet Governance