要約

  • ICANN理事会は9月6日、President and CEOまたはその指名者が、Engineering & ITの戦略的要員増強サービスを優先ベンダーと契約し、支払いを行うことを承認した。決議は9日に公表された。
  • ICANNは、ソフトウェア開発、品質保証、コンテンツ管理などの専門性を補い、優先順位に応じて規模を変え、複数の時間帯をカバーできると説明する。
  • ICANN自身の権限委譲指針は、権限と責任は委譲できても説明責任は委譲できないと定める。契約方針も、署名の委任と承認責任の保持を分けている。
  • 公開決議には役割単位の権限図がない。内部責任者、外部機能、権限区分、承認限界、退任時のアクセス失効を、個人名や機密システムを出さずに記録できる。

増えたのは処理能力であって、統治主体ではない

2026年9月6日の承認決議は、President and CEOまたはその指名者に対し、優先ベンダーとの契約締結と関連支出を認めた。対象はEngineering & ITの戦略的なstaff augmentationである。決議ページは会合の3日後に公表された。

運用上の狙いは具体的だ。外部の専門家で内部能力を補い、事業上の優先順位が変われば規模を調整し、常設職にするほどではない技能を必要な期間だけ確保する。世界の時間帯にまたがる対応力を高め、並行案件の納期リスクを下げる。ソフトウェアエンジニアリング、品質保証、コンテンツ管理が例示され、戦略施策だけでなく継続的な業務サービスも範囲に入る。

しかし、作業を行うことと組織として決めることは同じではない。変更案を書く人が本番投入を承認するとは限らない。テスト基準に従ってビルドを止める人がICANNの方針を決めるわけでもない。オンコール担当が手順書に沿って復旧しても、運用上のリスクを受け入れた主体は別に存在する。

公開資料は、その区別が破られているとは示していない。ただ、役割の境界を外部から確かめる図を掲載していない。交渉情報の一部は非公開で、ベンダー名、金額、期間、署名日、人数、勤務地、実施中かどうかも確認できない。空白は疑惑で埋めるべきものではない。

ICANNの原則はすでに明快である

2024年10月に改訂されたDelegation of Authority Guidelinesは、冒頭で一線を引く。権限と責任は委譲できるが、説明責任は委譲できない。理事会はBylaws上の権限全体について説明責任を負い続ける。President and CEOの権限に属する仕事を組織内の別の人に主導させても、責任はPresident and CEOに残る。

同じ文書は、日常業務をPresident and CEOの所管とし、理事会決議が委譲した範囲内で実施するよう求める。理事会は監督する。これは作業の集中を求める規則ではなく、分散した作業に最後の所有者を残す規則だ。

1月施行のContracting and Disbursement Policyには、さらに実務的な例がある。承認額の段階を定め、特定プロジェクト予算に関する例外を除けば、75万米ドルを超える債務は理事会承認とする。Officerは契約の種類を明記した書面により署名権を委任でき、法務上の承認と他のOfficersへの通知も必要になる。それでも承認権そのものは移らず、最終責任はOfficerに残る。

外部技術要員にも同じ文法を当てられる。署名者、実行者、承認者、説明する者が違っていてもよい。違いを結ぶ証拠が消えなければよい。

混成チームには長い前史がある

2025年5月3日の理事会議事録によると、ICANNは2014年、IT能力を補うため外部企業を初めて起用した。2014年と2017年にRFPで選定し、その後は2025年5月まで複数回契約を更新した。当時の事業者は開発、品質保証、コンテンツ管理を支援していた。

この記録から2026年の優先ベンダーが同じだとは言えない。更新契約であるとも断定できない。確認できるのは、外部技術能力が一時的な応急措置ではなく、長く続く運用モデルに組み込まれていることだ。

FY25 Form 990は新契約の詳細ではなく、組織全体の規模を示す。対象期間に10万米ドルを超える支払いを受けた独立請負人は136。高額な契約先の複数がITコンサルティングサービスと記載されている。地域別人数には直接雇用者だけでなく、第三者の雇用主から出向した人と長期の独立請負人も含むという。

同申告書は、利益相反方針を独立請負人にも適用し、年次申告書を求めるとしている。従業員向け実務ページには機密保持と利益相反の義務が別途掲載される。統制の存在を示す資料ではあるが、9月の契約でどの職務がどの権限区分に入るかを公表したものではない。

攻撃面ではなく統制区分を公表する

請負人の氏名、ホスト名、認証情報、脆弱性、障害対応の細部を公開する必要はない。プライバシーとセキュリティを損なう恐れがある。必要なのは、決議2026.09.06.03–.04と、契約締結後の安定した契約識別子に結び付く、役割と統制の記録である。

業務分野ごとに、ICANN内部で最終責任を負うOfficerと運用責任者を置く。外部側は個人名ではなく機能区分とし、システムまたはデータの分類、権限レベル、その役割が準備・実行・推奨・承認のどこまで行えるかを示す。職務分離、エスカレーション、再委託の可否、機密保持・利益相反確認の状態も記録できる。

入口だけでなく出口も一つの統制である。開始日しかない権限は未完成だ。見直し日と失効日、アクセス撤回の確認、コードと運用証拠の引き渡し、訂正履歴まで残せば、個人や技術上の弱点を明かさずに境界を検証できる。

これはDaniel Kadeによる編集上のモデルであり、ICANNが発表した制度ではない。資料から過大なアクセス、承認の混乱、不適切な離任手続きは確認されない。見えているのは、求める能力の説明と、その能力を内部の説明責任に従属させる公開接続部との落差である。

ベンダー名が分かっても権限図にはならない

対になる決議は、President and CEOが開示可能と判断するまで交渉情報を非公開にする。将来、名称、金額、期間が開示されれば調達の透明性は上がる。しかし、重要変更を誰が承認し、権限をいつどう失効させるかは分からないままだ。

Governance Guidelinesは、経営実績、全社リスク、情報技術計画の監督を理事会に課す。ガバナンス文書一覧では、組織上の権限分担も確認できる。必要な接続部は限定的だ。この制度図を、混成チームの役割区分へ安全に投影すればよい。

ICANNは契約承認を、パブリックコメントを要しないOrganizational Administrative Functionと位置付けた。役割記録は人員配置を住民投票に変えるものではない。外部能力が契約の境界を越えても、説明責任は越境しないという原則を観測可能にするだけだ。

情報源