要約

  • 2026年6月30日までの未監査財務報告は、MyAFRINIC v2について、承認額650,000ドルに対し実績CAPEXを20,790ドルとする。約3.198％という比率は支出の観測値であり、完成率ではない。
  • 6月24日のAFRINIC-37議事録は、人員がMyAFRINIC v2へ振り向けられ、範囲拡大を抑えながら年末稼働を見込んでいたと記録する。ただし人数、期間、内部費用は示さない。
  • 承認予算は旧ポータルを耐用終期、レジストリの単一障害点、政策・RPKI・RDAP改善のボトルネックと表現する。これはAFRINIC自身のリスク説明であって、障害や遅延の発生証拠ではない。
  • 必要なのは、内部作業、運用費、契約上の約束、請求、現金支払、受入済みマイルストーン、残存リスクを別々に示すプロジェクト資源対応表である。

20,790ドルは明瞭な数字だ。しかし、何を数えているかを外せば、明瞭さは誤解の速さに変わる。

2026年上半期の未監査財務実績は、MyAFRINIC v2の実績CAPEXを20,790ドル、年間の承認CAPEXを650,000ドルと記す。その商は約3.198％になる。同じ表のCAPEX全体は、実績42,053ドル、承認1,265,875ドルで、約3.322％である。

どちらも財務比率だ。設計、実装、試験、データ移行、利用者受入、障害リスクの解消を測る比率ではない。

この違いは、AFRINIC-37の議事録と並べると分かりやすい。6月24日の説明によれば、MyAFRINIC v2は2020年に開発が始まり、複数年の予算・資源制約を経て再開された。年末の稼働を目指し、scope creepを避けるため範囲を限定していた。さらに、AFRINICの人的資源がこのプロジェクトへ向けられているとされた。

人の作業は、そのままCAPEXになるとは限らない。給与は運用費に残るかもしれない。外部契約は締結済みでも未請求かもしれない。請求済みでも未払いかもしれない。支払い済みでも成果物が受入基準を満たしていない場合がある。公開資料は、MyAFRINIC v2についてどの境界を採用したかを説明していない。

したがって、二つの記録の間に必ず矛盾があるわけではない。比較方法が公開されていないことが問題なのである。

完成率へ変換してはいけない

資本プロジェクトは毎月同じ速さで支出する必要がない。機器調達が後半に集中することも、受入後にマイルストーン支払が発生することもある。内部開発が先行すれば、作業が進んでもプロジェクト固有のCAPEXが小さい場合がある。逆に、多くを支払っても、移行やロールバックが未検証なら利用可能性は証明されない。

この境界はAFRINICを不当な推測から守る。上半期の低い実績だけで、調達失敗、活動停止、契約不在、年末目標の未達を断定できない。証拠の締切時点では年末は来ておらず、確認した資料に利用者試験の失敗や契約取消しは記録されていない。

同時に、低い数字を効率の証拠にしてもいけない。内部労働がCAPEX外なら、20,790ドルは会計科目として正確でも、投入資源全体を小さく見せる。契約上の債務がまだ請求されていなければ、期末時点の経済的な拘束も見えない。正しい評価には、数値を増やすより、分類を分ける必要がある。

「人的資源」も数量ではない

議事録の表現を、全職員が全勤務時間をポータルだけに使ったという意味に読むことはできない。AFRINICはその間も登録、会員対応、セキュリティ、財務、政策会議を続けていた。文脈上、限られた実装能力を共通基盤へ集中的に配分したという説明と読むのが妥当である。ただし、対象チーム、期間、配分率は分からない。

Q2報告にはHR全体の行がある。実績822,142ドル、年間予算2,901,811ドル、28％と表示される。しかし組織全体の集計であり、MyAFRINIC、インフラ、日常のレジストリ業務、政策支援に分解されていない。この総額からポータルの労務費を逆算することはできない。

会計処理には複数の妥当な可能性がある。内部開発をOPEXに置く、一定部分を資産計上する、外部サービスを別勘定に置く、段階によって組み合わせる、といった方法だ。ここでどれかを事実として選ぶ根拠はない。必要なのは、外部の論者が処理を決めることではなく、AFRINICが採用した方針とプロジェクトへの配賦方法を示すことである。

なぜ人の配分がレジストリに効くのか

2026年承認予算は、優先順位の理由を明記する。MyAFRINIC v1は5年前にEnd-of-Lifeと宣言され、レジストリの単一障害点であり、政策実装、RPKI、RDAP改善を妨げるボトルネックだと説明された。置換は2026年最大の支出とされた。

これらは、プロジェクトが除去すべきリスクの定義である。期間中に実際の停止が起きた証拠でも、特定のROAやRDAP応答が失敗した証拠でもない。受入時には、どの機能依存が旧系から外れ、どの依存が残ったかを確かめる基準になる。

人員集中には機会費用もある。AFRINIC-37では、階層型AS-SET名の提案について、MyAFRINIC v2完了後に実装を優先すると説明された。ほかの批准済み政策にもポータル依存が示されていた。共通基盤を先に整える判断は合理的であり得るが、その間に待つ作業はCAPEX表には現れない。

範囲限定にも同じ二面性がある。小さな一貫したリリースは、大きすぎるリリースより安全かもしれない。一方、除外した機能を記録しなければ、後日の「稼働」という一語が当初計画をすべて実現したように見せる。範囲変更は失敗の印ではないが、履歴から消してよい情報でもない。

公開できる資源対応表

個人別タイムシート、給与、取引先、ソースコード、構成図を公開する必要はない。必要なのは、内部証拠を安全な集計へ投影する設計である。

財務欄は、承認枠、契約・発注済み価値、請求額、支払現金、認識済みCAPEX、プロジェクトに配賦したOPEXを分ける。それぞれに締切日と定義を付ける。承認は約束ではなく、約束は請求ではなく、請求は支払ではなく、支払は受入ではない。

人員欄は、製品、エンジニアリング、会員サービス、セキュリティなどのチーム区分と、人月の幅で示せる。個人名も給与も不要だ。配賦方法を変えた場合は、過去を書き換えず、変更日と影響を追加する。

成果欄は、試験可能な単位を使う。認証経路、特定の資源更新フロー、データ照合、ロールバック演習、会員UAT、限定ベータなどである。適用バージョン、受入基準、受入主体、例外を残す。ログイン画面が表示されたことは全機能の受入ではなく、ポータル稼働は依存する各政策の実装完了でもない。

最後に、残存リスクと延期項目を記録する。旧系の単一依存のうち何が解消され、何が残るかを機能単位で示せば、セキュリティ詳細は守れる。範囲から外した作業には、決定主体、理由、次の判断条件を付ける。訂正は履歴を削除するのではなく、新しい状態として追加する。

言えることを狭く保つ

AFRINICは、年間計画、上半期実績、人員制約の説明を公開した。財務資料一覧から出所を追うことができ、Q2資料は未監査であることも明示している。この開示は評価すべきである。

それでも20,790ドルから内部作業量は分からない。「人員を集中した」という説明から、その費用や受入成果も分からない。分からないことは失敗の証拠ではない。次に公開すべき項目を示している。

資金、人、成果、残存リスクを別々に保ちながら結ぶ対応表があれば、支払の遅れ、納品の遅れ、CAPEX外の内部作業を区別できる。MyAFRINIC v1が単一障害点だとされたのなら、その置換を説明する記録まで一つの数字に依存させるべきではない。

出典