要約

  • Milan報告の3.1は、IETF参加者の80％が過度な労力や費用なしにビザを得られるかを問う。ところが説明は、3.2の対象である非差別性について述べており、二つとも「Met」と表示される。
  • これは公開記録の結び付けが切れていることを示すのであって、80％に達しないことの証明ではない。内部調査の有無も分からず、意見募集で追記や訂正が可能である。
  • 同じ日に同じ書式で作られたMontevideo報告は、3.1で80％の入国可能性、3.2で非差別性を別々に説明する。比較の目的は記録構造の確認であり、都市の優劣ではない。
  • Daniel Kadeは、各判定に問い、根拠、計算法、基準日、不確実性、担当、改訂、後続判断を束ねる「基準・証拠受領票」を付けるよう提案する。

表の中で起きた小さな断線

Milanの報告は2026年7月9日付で、候補施設としてAllianz MiCoを挙げる。施設の適否、開かれたインターネット、ビザ、渡航リスク、健康、大気、混乱、差別に関する当事者経験など九つのテストを並べ、八つをMet、ゼロをUncertain、ゼロをNot Met、一つを未評価とまとめる。緑、黄、赤、灰色の凡例は、複雑な調査を素早く読ませるためのものだ。

3.1の問いには数値が入っている。「ビザ要件は、IETF参加者の80％が過度な労力や費用なしにビザを取得できるものか」。答えるには、参照する参加者集団を決め、国別構成と査証免除または通常申請の経路を対応させ、費用と負担を評価する必要がある。公式テンプレートも、その形の回答例を示している。

しかしMilan欄の文章は、イタリアの規則が人種、民族、宗教、性別、性的指向、性自認を理由に差別しないと述べ、外務省の情報へ誘導する。これは3.2に必要な説明である。次の行はまさに非差別性を問い、実質的に同じ文章とリンクを載せる。二つの緑色は、別々の証拠ではなく、同じ説明を共有してしまった。

公開報告には、参照した会合、参加者の国別分布、免除と通常申請の割合、結果の百分率、費用・労力の境界、欠損の扱いが示されていない。内部で計算し、文章だけを誤配置した可能性はある。計算自体が未完成かもしれない。現段階の資料からどちらかを事実として選ぶことはできない。

したがって、緑色を「誤判定」と呼ぶのも早い。確実に言えるのは、緑色と3.1を支える公開説明の間に追跡可能な線がない、という点である。

Montevideoを物差しにしても、順位表にはしない

Montevideoの報告は同日付で、同じテンプレートを使う。3.1には、国別にみた参加者の80％が査証なし、または合理的な費用の通常手続でUruguayに入国できると書く。3.2には、ビザ規則が列挙された属性を理由に差別しないという別の説明が置かれる。少なくとも各文は自分の問いに答えている。

この違いを都市選びに拡張してはならない。Montevideoでは、大気質の情報不足と、差別に関する参加者の実体験が未評価である。七つがMet、二つが未評価だ。Milanは八つと一つである。色の数は会場費、ホテル、日程、現地支援、契約条件を含まず、いずれの報告にも承認・拒否の勧告はない。

Montevideoは文書上の対照例にすぎない。同じ書式が、入国できる割合と差別性を分離できることを示す。Milanの問題をテンプレートの曖昧さに帰すことはできない。

一方、Montevideoの文章にも計算表はない。正しい種類の説明と、再現可能な評価は同じではない。80％という精度を使うなら、参照会合、国別集計、採用した入国経路、通常費用、欠測と結果を集計値で公表できる。個人の氏名、国籍、旅券、ビザ歴を出す必要はない。

予備報告に勧告がないのは欠陥ではない

報告冒頭のRecommendationが結論を持たないことは、未完成の印ではない。現行テンプレートは、予備報告では一部の情報しか得られないため勧告を行わず、コミュニティの意見と、それが促す追加調査を最終版に反映すると説明する。

8月14日の募集も、MontevideoとMilanをともに「no recommendation」と記す。意見は公開閲覧できる一方向のメールアドレスで受け付け、Trelloにも集約される。締切は8月28日と案内された。本稿の観察時点で、どちらかを承認済み、拒否済み、契約先と呼ぶ根拠はない。

6.1が灰色であることも予備段階の意義を示す。このテストは、差別によって都市が参加者に危険かどうかを、IETF参加者の実体験に基づいて判断する。両報告はコミュニティの情報が必要だとする。机上調査で法令や渡航情報を読んでも、他人の経験を代作することはできない。ここでは未評価という表示が証拠の境界を守る。

意見募集後、IETF LLCは追加調査を行い、評価を変更し、承認または拒否の勧告を伴う更新版を出せる。拒否ならその都市の検討は終わる。承認でも直ちに選定されるわけではなく、詳細評価、場合によっては現地確認、費用、ホテル、現地支援へ進む。会合の中核的目的に関する懸念があれば、IESGが別の問いを判断する。その後、IETF LLC Boardが非公開資料を審査し、契約と通知が続く。

緑色の行、Executive Directorの勧告、詳細評価、IESGの判断、Boardの承認、契約はそれぞれ別の行為である。予備表は後段へ証拠を渡す。後段の権限を先取りするものではない。

「圧倒的多数」を計算できる問いにする

RFC 8718は、IASAが最善の判断を用い、可能な限り開かれた過程を維持し、契約を検討するより十分早くコミュニティと意見を交換するよう求める。重要な都市基準として、ビザを含む入国障壁が、参加を望む圧倒的多数の人の出席を可能にする見込みがあることを挙げる。「渡航障壁」は、会合が成功できるかという文脈で広く読む。

テンプレートは「圧倒的多数」を80％という運用テストに変えた。抽象語を比較可能にする良い工夫である。ただし、数値を採用した瞬間に、分母と算定法の説明が必要になる。問いだけが精密で、答えが印象評価のままではいけない。

対象集団には選択肢がある。直近数回の登録者、重複を除いた個人、会合ごとの延べ参加、地域を考慮した予測。国別配分も国籍、居住地、通常の出発地で異なる。「通常申請」が遠い領事館への移動を含むか、「合理的費用」を雇用主負担と自費参加のどちらで測るかでも結果が変わる。

この分析が正解を指定する必要はない。公開評価が採った答えを記せばよい。集計方法ならプライバシーも守れる。参照期間、国別人数、公式入国制度、費用仮定、例外、欠損、算定値を示せば、読者は個人情報ではなく仮定を検証できる。

ビザ制度は変化するため、取得日も不可欠だ。7月9日に妥当だった緑色が、その後の制度変更で再評価を要することはあり得る。基準日を持つ証拠は、参加者だけでなく評価担当者も守る。後から変わった事情を、当時の恣意性と混同せずに済む。

意見募集で直すことと、正式審査は別である

現時点で比例的な対応は、募集された公開意見として3.1の不整合を指摘することだ。報告の版と行番号を示し、説明が3.2に対応すると述べ、80％の方法を加えるか判定を変えるよう求める。同時に、Milanの不適格や他都市の優位を主張していないと明記できる。

RFC 8711の4.7節には、より正式な説明責任の経路がある。参加者は、Executive DirectorまたはBoardの行為がBCPやLLCの方針・手続に沿わないと考える場合、Boardに正式審査を求められる。対象行為、違反理由、救済案を記し、LLCは請求と回答または結果を公表する。重要な最終保障だが、意見募集の最中にある表の修正をすべて審査案件にする必要はない。

軽い修正には軽い記録を残せばよい。最終報告に、予備版の3.1が3.2の説明を重複していたこと、追加した証拠、判定が維持・変更されたか、日付と理由を記す。文章だけを静かに差し替えれば現在の読みやすさは増すが、外部意見が作用した証拠は消える。

変更履歴は失敗者を名指しするためではない。入力ミスと政策変更を区別し、古い要約を使う人に版の違いを知らせ、将来の担当者に何が学ばれたかを残すためである。訂正可能性を掲げるだけでなく、訂正が起きた事実を保存する。

基準・証拠受領票

Daniel Kadeの提案は、各行に薄い受領票を付けることだ。現行のIETFルールではなく、新しい会場規制機関でもない。色が別資料へコピーされても、根拠が落ちないための最小記録である。

最初に、RFCの根拠、更新文書、テンプレート版を記す。次に、安定したテスト番号と問いの全文を保存する。国・都市・施設のどれを評価するか、対象名、観察期限を明確にする。

証拠欄では、各情報がなぜその問いに答えるのかを短く説明する。計算なら母集団、重み、閾値、欠損処理、例外を示す。外部情報なら出典と取得日を示す。判定と不確実性を分離しない。Metには根拠を、未評価には待っている情報を付ける。

責任と段階も必要だ。Secretariatの初期評価、Executive Directorの予備報告、意見反映後の最終報告、後の意思決定資料を区別する。旧文、意見、修正文、日付、理由を変更履歴に残し、追加調査、勧告、必要なIESG判断、Board承認、契約は別々の状態として扱う。

受領票が運んではならない情報もある。個人のビザ事情、保護属性、非公開意見、施設の入札、Boardの機密資料は除外する。公開投票を作らず、LLCの判断権も移さない。証拠と権限の接続だけを可視化する。

いま言えること、言えないこと

8月28日時点で、Milanの3.1説明が問いと一致せず、3.2と重複し、両方が緑色であることは確認できる。公式テンプレートとMontevideo報告が二つの問いを別に扱うことも確認できる。両都市に勧告がないことも事実である。

一方、Milanが80％未満、緑色が赤や黄であるべき、Montevideoが優先、内部計算が存在しない、という結論は出せない。最終勧告、商業条件、Board判断、契約も分からない。

小さな不一致だからこそ、修正は小さくできる。都市を断罪する必要はない。答えを正しい問いへ戻し、根拠と変更を残せばよい。色は情報を圧縮する道具である。証拠の代用品にした瞬間、圧縮されたのは情報ではなく説明責任になる。

証拠の限界

本稿は二つの予備報告、現行テンプレート、募集告知、会場選定ページ、RFC 8718、8711、9712を用いた。Secretariatの内部資料、国別算定、非公開意見、Trello全記録、商業提案、後の最終報告は持たない。最終的な適否や契約を判定できない。

公開報告に計算がないことは開示上の所見であり、計算が行われなかった証明ではない。Montevideoは欄の意味を示すだけで、数値を検証せず、都市を順位付けしない。受領票はDaniel Kadeの分析上の提案である。

情報源

  1. MontevideoとMilanの会場評価に関する意見募集
  2. Milan Venue Assessment Report
  3. Montevideo Venue Assessment Report
  4. IETF Venue Assessment Reportテンプレートv3
  5. IETF会場特定・選定プロセス
  6. IETF Meeting Location Assessment
  7. RFC 8718：IETF全体会合の会場選定
  8. RFC 8711：IASA 2.0の構造
  9. RFC 9712：会場要件の見直し