2026年9月、Pythonのパッケージ管理の決まりごとを見守る新しい組織、Python Packaging Councilの最初のメンバー5人が決まりました。Pythonを支える非営利団体PSFが行った選挙で選ばれ、結果は9月17日に発表されています。
パッケージ管理と聞くと、pip installを打つくらいで、自分には遠い話に感じるかもしれません。けれども、pipやPyPI、pyproject.tomlの書き方といった、私たちが毎日使っている仕組みの決まりごとに関わる話です。
今回は、この評議会が何をするのか、これまでと何が変わるのかを順番に見ていきます。
まずは何が起きたのかを整理しよう¶
最初に、今回のニュースの要点を表にまとめます。評議会の仕組みは、PEP 772という文書で定められています。
| 項目 | 内容 |
|---|---|
| 新しい組織 | Python Packaging Council（Pythonパッケージング評議会） |
| 根拠となる文書 | PEP 772（2026年4月16日に承認） |
| 人数 | 5人 |
| 選び方 | PSFの投票権を持つ会員のうち、参加を希望した人による選挙 |
| 結果の発表 | 2026年9月17日 |
| 役割 | パッケージ管理の標準を見守り、決め方のルールを整える |
PEPは、Pythonの仕様や運営の方針をまとめた文書です。PEPそのものについては、こちらでやさしく紹介しています。【関連記事】PEPとは？
そもそもパッケージ管理の決まりごととは¶
Pythonのパッケージ管理には、たくさんの道具が関わっています。pipでインストールし、PyPIから配布物を受け取り、pyproject.tomlに設定を書く、という流れです。
これらの道具がばらばらに動くと、あるツールで作ったパッケージが別のツールで入らない、といった困りごとが起きます。そこで、道具どうしが同じ約束で動けるように、共通の標準が決められています。
身近な例を表にまとめます。どれも、PEPとして決められた標準です。
| 標準 | 中身 | 状態 |
|---|---|---|
| PEP 621 | pyproject.tomlにプロジェクトの情報を書く方法 | Final（確定） |
| PEP 751 | インストールを再現するためのロックファイルの形式 | Final（確定） |
| PEP 772 | 今回のPackaging Councilの仕組み | Accepted（承認済み） |
pyproject.tomlの書き方は、こちらで詳しく解説しています。【関連記事】pyproject.tomlとは？
これまでは誰が決めていたのか¶
PEP 772には、これまでの体制の課題が率直に書かれています。ポイントを、初心者向けに言い換えて紹介します。
PyPAという集まり¶
pipやvirtualenvなど、パッケージ管理の基本的な道具の多くは、PyPAという集まりで開発されています。PyPAはPython Packaging Authorityの略です。
PEP 772によると、PyPAは個人の集まりではなく、プロジェクトの集まりとして定義されていました。コミュニティの選挙で選ばれたメンバーはおらず、話し合いも必要に応じて開かれる形だったと説明されています。
標準を決める人が、個別に指名されていた¶
標準を変えるかどうかの判断は、Python全体の運営委員会であるSteering Councilから、分野ごとに特定の個人へ任されていました。任された人が、さらに別の人へ判断を任せることもできたそうです。
PEP 772は、このやり方は長くは続けられないと書いています。判断を任されている本人たちからも、決める場をきちんと作ってほしいという声が上がっていたようです。
私は10年ほどエンジニアとして開発に関わってきましたが、特定の人に判断が集まる体制は、その人が忙しくなった途端に何も決まらなくなるものです。仕組みとして決める場を用意するのは、チームでも大きな組織でも大切だと感じます。
Steering Councilが直接決めない理由¶
それなら、Python全体のSteering Councilが決めればよいのでは、と思うかもしれません。PEP 772は、これに対しても理由を説明しています。
パッケージ管理は、Pythonという言語の進化とは少し離れた分野で、専門的な知識が必要です。そのため、言語の運営とは別の、専門の場を作るほうがよいと判断されました。
Packaging Councilは何をするのか¶
PEP 772によると、評議会はパッケージ管理の標準と、packaging.python.orgで公開されているPython Packaging User Guideについて、幅広い権限を持ちます。ただし、その力はできるだけ使わない方針です。
評議会の仕事は、自分たちで何でも決めることではありません。拘束力のある決定をどう下すか、その手順を整えることが中心です。
PEP 772に書かれた主な役割を、表にまとめます。
| 役割 | 意味 |
|---|---|
| 標準の品質と安定を保つ | ツールどうしが同じ約束で動けるようにする |
| 決め方の手順を整える | 誰がどう決めるのかをはっきりさせる |
| 使い心地をよくする | パッケージ管理の分かりにくさを減らす |
| 貢献しやすくする | 新しく参加する人が関わりやすい場にする |
| 合意を大切にする | 投票より先に、関係者の合意を目指す |
評議会で採決するときは、5人のうち3人以上が棄権せずに参加し、その過半数の賛成が必要です。自分たちで決められない場合は、Steering Councilに判断を任せることもできます。
最初のメンバーと任期の仕組み¶
最初の選挙で選ばれたのは、次の5人です。PSFの発表によると、Brett CannonさんとPradyun Gedamさんが2年、Donald StufftさんとHenry SchreinerさんとRalf Gommersさんが1年の任期です。
任期が2年と1年に分かれている理由¶
通常、評議会のメンバーの任期は2年です。それなのに最初だけ1年の人がいるのは、PEP 772で決められた仕組みによるものです。
PEP 772では、メンバーを2人のグループと3人のグループに分けます。全員を一度に選ぶ最初の選挙では、得票の多い2人が2年、続く3人が1年の任期になります。
こうしておくと、次からは毎年どちらかのグループだけが選び直されます。一度に全員が入れ替わらないので、経験が途切れにくいわけです。
なお、PEP 772ではメンバーの再選に回数の制限はありません。また、これまでの体制を定めていたPEP 609は、PEP 772に置き換えられました。
選挙はどう行われるのか¶
PEP 772によると、選挙は3つの段階で進みます。それぞれの段階は2週間ずつです。
| 段階 | 中身 |
|---|---|
| 1 | PSFの投票権を持つ会員のうち、希望した人が選挙人になる |
| 2 | 選挙人が候補者を推薦する。自分自身の推薦もできる |
| 3 | 選挙人が、すべての候補者が載った投票用紙で投票する |
候補者もPSFの投票権を持つ会員であることが条件で、推薦するときには所属する組織などの情報を添える決まりです。選挙の結果は、PSFの理事会が正式に認めます。
PEP 772は、選挙の透明さを信頼の土台として重く見ています。匿名性を守りつつ、できるかぎり得票の集計を公開するよう求めているのもそのためです。
評議会がうまく働かないときの仕組み¶
選ばれたら終わり、というわけではありません。PEP 772には、特別な事情があるときにメンバーを外すための、不信任投票の仕組みも用意されています。
不信任投票は、Steering Councilが呼びかけて始まります。2週間の投票で、選挙人の3分の2以上が不信任を示すと成立します。
対象は、1人のメンバーの場合と、評議会全体の場合があります。全体への不信任が成立すると評議会は解散し、すぐに新しい選挙が行われます。
学習者にとって何が変わるのか¶
ここまで読んで、自分のpip installは明日から何か変わるのか、と気になった方もいるでしょう。結論から言うと、今日から操作が変わることはありません。
評議会は、標準を決める場を整えるための組織です。pipやuvの使い方がすぐに変わるわけではなく、変化はこれからゆっくり表れてきます。
それでも、長い目で見ると嬉しいことがあります。標準の決め方がはっきりすると、ツールどうしの足並みがそろいやすくなるからです。
標準のおかげで、ツールを選べる¶
実際に、標準がどう役に立っているのかを見てみましょう。PEP 621で決められたpyproject.tomlの[project]の部分は、どのツールからも同じ形で読めます。
次のコードは、Python 3.11から標準ライブラリに入ったtomllibで、pyproject.tomlの中身を読み取ります。
import tomllib
from pathlib import Path
with Path("pyproject.toml").open("rb") as f:
data = tomllib.load(f)
project = data["project"]
print(project["name"], project["version"])
print("必要なPython:", project["requires-python"])
for dep in project["dependencies"]:
print("依存:", dep)
nameとversion、requires-python、dependenciesを書いた小さなpyproject.tomlで試すと、次のように表示されました。
my-app 0.1.0
必要なPython: >=3.11
依存: requests>=2.32
依存: rich
この形が標準で決まっているからこそ、pipでもuvでも同じファイルを扱えます。ツールを乗り換えても設定を書き直さずに済むのは、標準のおかげです。
tomllibの使い方は、こちらで紹介しています。【関連記事】Pythonのtomllibとは？
uvのような新しいツールが短い期間で広く使われるようになったのも、こうした標準があったからこそです。【関連記事】uvとは？Rust製の高速Pythonパッケージ管理ツール
実務の人が押さえておきたいこと¶
実務でPythonを使っている方にとっても、すぐに対応が必要な話ではありません。ただ、これからの標準の動きを追うときの窓口が、はっきりしたと考えておくとよいでしょう。
以前、社内で使うパッケージの配布方法を決めるとき、どの情報が最新の標準なのかわからず、古い書き方のまま進めてしまったことがあります。あとから直すのに、思った以上の手間がかかりました。
これからは、Packaging Councilの決定とPython Packaging User Guideを見れば、今の標準がわかるようになっていくはずです。新しい書き方が出てきたら、一度ここで確かめる習慣をつけておくと安心です。
まとめ¶
Pythonのパッケージ管理に、初めて選挙で選ばれた5人の評議会、Python Packaging Councilが誕生しました。PEP 772にもとづく組織で、パッケージ管理の標準を見守り、決め方の手順を整える役割を担います。
学習者の操作が今すぐ変わることはありません。それでも、pipやuv、pyproject.tomlが同じ約束で動き続けるための土台が、一段しっかりしたニュースだと言えます。
次にpip installを打つときは、その裏にある標準と、それを支える人たちのことを少しだけ思い出してみてください。
ここまでお読みいただきありがとうございました。
