RISC-VがCPythonの公式サポート対象に — PEP 11のTier 3が意味することと、riscv64のwheel事情

はじめに

2026年8月、CPython が RISC-V を公式サポート対象のプラットフォームに追加した。Python 公式ブログの一文はこうだ。

RISC-V is now officially supported by CPython as a tier 3 platform!

Hacker News で 279pt を集め、Python コミュニティの外にも届いたニュースだった。ただ「公式サポート」という言葉は、受け取り方を間違えやすい。これは「RISC-V ボードで Python が動くようになった」という話ではない。Python は以前から RISC-V 上でビルドできていたし、Debian も Ubuntu も riscv64 版を配っている。

今回変わったのは、動くかどうかが誰の責任になったかだ。この記事では、PEP 11 の Tier 制度が実際には何を保証して何を保証しないのか、そして「Python が動く」ことと「パッケージが入る」ことの間にまだ残っている距離を整理する。

何が決まったのか

決まった内容は具体的だ。対象は riscv64-unknown-linux-gnu、つまり 64bit RISC-V の Linux/glibc ターゲット。Python の Steering Council が 8月20日に Tier 3 サポートを承認し、8月22日に PEP 11 のプラットフォーム一覧へ正式に反映された。

支えているのは主に RISE Project（RISC-V のソフトウェアエコシステム整備を進める Linux Foundation 傘下の団体）だ。公式ブログは、RISE が CPython に複数の RISC-V 実機を提供し、それがテスト用の buildbot になったと明記している。作業には Ludovic Henry（RISE）、Furkan Onder、Emma Smith らが関わった。

現状は従来型の buildbot 依存だが、次の段階も示されている。

We are currently investigating how to improve our testing further by bringing RISC-V directly into CPython’s CI.

buildbot は基本的にマージ後に回る。これを CI に取り込めば、コントリビュータはパッチを出した段階でフィードバックを得られる。さらに長期的には「Tier 2 への昇格を目指したい」とも書かれている。

PEP 11 の Tier は何を保証するのか

ここが今回の本質なので、PEP 11 の定義を並べておく。

	CI/buildbot	リリースへの影響	担当者
Tier 1	CI 必須	失敗はリリースをブロック	全コア開発者が責任を負う
Tier 2	信頼できる buildbot 必須	失敗はリリースをブロック。破損は24時間以内に修正かリバート	コア開発者2名以上を割り当て
Tier 3	信頼できる buildbot 必須	失敗してもリリースをブロックしない。障害への応答SLAなし	コア開発者1名以上を割り当て

Tier 1 は x86_64-unknown-linux-gnu、aarch64-apple-darwin、Windows の x86/x64 など。Tier 2 には macOS の Intel 版や wasm32-unknown-wasip1 が入る。そして Tier 3 には Android、iOS、armv7l、s390x、Emscripten、FreeBSD が並び、その隣に riscv64-unknown-linux-gnu が加わった。

つまり Tier 3 は「壊れても Python 3.15 のリリースは止まらない」レイヤーである。過剰な期待をするなら、確かに肩透かしだ。

ただ、それでも意味は小さくない。Tier 3 に入るということは、buildbot が常時回り、担当のコア開発者が存在するということだ。CPython 側の変更が RISC-V を静かに壊した場合、それは誰の目にも触れずに数か月放置される問題ではなくなる。「たまたま動いていた」から「壊れたら気づかれる」への移行であり、移植を維持する側のコストが構造的に下がる。

HN でも「Tier 3 は RISC-V の市場成熟度からして妥当」という声と、「ビルドもテストも問題なく通っている以上、足りないのは CI インフラと時間を割く committer だけだ」という声が並んでいた。後者の見立てが正しければ、Tier 2 は思ったより早く来る。

「動く」と「配れる」は別問題

Tier 3 昇格はインタプリタ本体の話であって、サードパーティパッケージが入るかどうかとは別レイヤーだ。実務で効いてくるのはむしろこちらである。

こちらはこちらで、この1年で大きく動いていた。2025年夏に cibuildwheel・manylinux・warehouse（PyPI 本体）が揃って riscv64 対応を果たし、manylinux_2_39_riscv64 という正式なプラットフォームタグが使えるようになっている。PyPI は riscv64 wheel のアップロードを受け付ける。

象徴的なのが、CPython の Tier 3 承認のわずか2日前、8月18日に RISE が出した発表だ。PyTorch 2.13.0 の riscv64 wheel が配布開始されている。

pip install torch --extra-index-url https://pypi.riseproject.dev/simple/ --prefer-binary

CPython 3.12 / 3.13 / 3.14 / 3.14t 向けの4種類が、クロスコンパイルではなく RISC-V 実機上でネイティブビルドされている。ビルド時間はコールドキャッシュで約20時間、ウォームで1.5時間。sccache の Redis コーディネータを自作して複数マシンにビルドを分散させた、という規模感の話だ。

ただし制約も率直に書かれている。ATen のベクトル化（RVV）がまだ入っていないため、この wheel のテンソル演算はほぼスカラーコードで動く。oneDNN は無効で OpenBLAS 頼み。量子化は FBGEMM も QNNPACK も RISC-V 非対応のためバックエンドがない。つまり「動く」が「速い」ではない、という段階だ。

エコシステム全体としては、RISE が追跡している77パッケージのうち 37個が upstream で riscv64 wheel を配るようになったという数字が出ている。約半分。lxml、uv、maturin、ninja などは既に PyPI 側へ直接アップロードしている。

実務上の落とし穴が一つある。 pip が riscv64 の manylinux wheel を理解するのは 24.1 以降だ。それより古い pip では、エラーにならず、素の linux_riscv64 タグが付いた古い wheel を黙って拾ってしまう。riscv64 環境で「なぜかバージョンが古い」と悩んだら、まず pip --version を疑うべきポイントになる。

ベースライン問題 — RV64GC か、RVA23 か

もう一つ、RISC-V 特有の論点が HN で議論されていた。どの命令セット拡張を前提にするかである。

RISC-V は基本命令セットに拡張を積み上げる設計で、これは裏を返せばターゲットが一枚岩ではないことを意味する。CPython のコントリビュータはこう書いている。

We (CPython) currently only have access to RV64GC machines to test on.

RV64GC は事実上の共通ベースライン。一方、ベクトル拡張（RVV）やビット操作を含む RVA23 プロファイルを前提にすれば性能は伸びるが、そのハードウェアを持っていないユーザーは切り捨てられる。「ユーザーが RVA23 を採用しない限り、ベースラインを切り替えるのは賢明ではない」というのが現時点の判断だ。前述の PyTorch wheel がスカラーコード中心なのも、同じ制約の別の現れである。

もっとも、これを RISC-V 固有の断片化と呼ぶのは公平ではない。HN では x86-64 の v2〜v4 マイクロアーキテクチャレベルとの類推が指摘されていた。x86 も同じ問題を抱えており、ディストリビューションは長年ベースラインをどこに引くかで揉めてきた。RISC-V が特別に厄介なわけではなく、まだ「実質的な最低ライン」が市場で固まっていないというだけだ。

なお、ハードウェア側の環境は変わりつつある。SiFive の P800 系や BigSky といったデータセンター級プラットフォームが登場し、CI を回せる実機の調達性が改善している。今回 RISE がマシンを提供できたこと自体、その裏返しでもある。

エンジニアへの影響

明日から手元の開発が変わる、という種類のニュースではない。実務への影響は3段階で考えるとよい。

組込み・エッジで RISC-V を検討している場合、Python を使う判断の根拠が一段強くなった。「動くかもしれない」ではなく「buildbot が回っていて担当者がいる」と言える。ただし Tier 3 である以上、リリースブロックの保証はないと明記しておくのが誠実だ。

CI に riscv64 を足すか迷っている場合、コンテナと GitHub Actions のランナー事情はまだ x86/ARM ほど楽ではない。RISE 側も Scaleway の EM-RV1 実機を使っている。すぐ横断的に入れるより、まず対象パッケージが manylinux_2_39_riscv64 の wheel を出しているかを確認するのが先だ。

ライブラリを公開している場合が、実は一番アクションが明確だ。cibuildwheel 3.12 以降と manylinux イメージが riscv64 に対応済みで、PyPI もアップロードを受け付ける。C 拡張を含むパッケージなら、ビルドマトリクスに1行足すだけで riscv64 ユーザーがソースビルドから解放される。37/77 という数字は、まだ半分が残っているという意味でもある。

まとめ

CPython が riscv64-unknown-linux-gnu を PEP 11 の Tier 3 として正式サポート対象に追加した（Steering Council 承認8/20、PEP 反映8/22）
Tier 3 は「失敗してもリリースをブロックしない」層。ただし buildbot 常設とコア開発者の担当割り当てが伴い、静かに壊れる状態からは脱した
ハードウェアは RISE Project が提供。次の目標は buildbot から CPython 本体の CI への統合、その先に Tier 2 昇格
パッケージ側は別軌道で先行しており、manylinux_2_39_riscv64 タグと PyPI 対応は整備済み。PyTorch も riscv64 wheel を配布開始。ただし pip 24.1 以降が必須
残る課題はベースライン。RV64GC を取るか RVA23 を取るかは、ハードウェアの普及待ちという構図

「公式サポート」という見出しの強さに対して、中身は地味な整備作業の積み重ねだ。だが移植を長生きさせるのは常にこの種の作業であり、Tier 3 は終点ではなく、Tier 2 への通り道として置かれている。

今日のその他のニュース

Hugging Face 侵害事件の最終ポストモーテムが公開 — モデルハブへの攻撃について最終報告書が出た。AI 安全性評価機関の METR と Redwood Research が独立に分析を公開しており、モデル/データセットを外部ハブから取得しているプロジェクトは影響範囲の確認が推奨される。AI サプライチェーンの急所がどこにあるかを示す事例。（ITmedia / thezvi）

Dan Luu「Bug Blindness」がHN 367pt — ソフトウェアの品質問題の多くは「存在しない」のではなく「検出されていないだけ」だという品質論。観測できていないものを直すことはできない、という当たり前の指摘が刺さる。（danluu.com）

Claude Code のセッションURLがコミットメッセージに付与される件 — デフォルト挙動に対する GitHub Issue が HN 上位へ。プライバシーとコミット履歴の汚染の両面で議論されている。Claude Code でコミットしているリポジトリは設定を確認しておきたい。（GitHub Issue #66504）