Pythonの標準機能と外部ライブラリを制約で比較するPrompt

Python実装の技術選定を行います。『流行っている』ではなく、与えた環境で必要性を証明できる候補だけ残してください。

処理内容、入出力と外部接続：毎晩、社内の在庫CSV（約5万行・120MB）を読み込み、商品コードごとに在庫数を集計して、社内の REST API（1リクエスト1商品・約3,000商品）へ POST する。
対象Python/OS、実行・配布方法：Python 3.11 / Ubuntu 22.04 のサーバで cron 実行。配布はしない（サーバに git clone して venv で動かす）。
既存pyproject/requirementsと固定依存：requirements.txt に requests==2.31.0 だけ固定されている。pyproject.toml は無い。
データ量、I/O待ち、CPU負荷、同時処理要否：CSV 集計は数十秒で終わる（計測済み：pandas 無しの csv モジュールで 38秒）。API への POST が 3,000回×平均0.4秒で約20分かかっており、朝の業務開始（6時）までに終わらない日がある。API 側の同時接続上限は 10 と聞いている。
オフライン/ネットワークの制約：サーバから社内 API とPyPI には接続できる。
開発者の経験と保守期間：開発者は自分1人（Python 3年）。asyncio は使ったことが無い。今後2年は自分が保守する。
ライセンス/セキュリティ/運用規定：OSS ライセンスは MIT / BSD / Apache-2.0 なら可（社内規定）。脆弱性はリリース前に pip-audit を通す決まり。
比較したい候補と公式URL：候補：concurrent.futures.ThreadPoolExecutor（標準ライブラリ）、httpx（https://www.python-httpx.org/）、aiohttp（https://docs.aiohttp.org/）。

まず標準ライブラリのみの案と外部依存案を比較し、処理がI/O待ち主体かCPU主体かを分けて同期/非同期の必要性を判断する。asyncioを無条件に採用しない。候補ごとに対象Python/OS、依存、ライセンス、保守/脆弱性の確認場所、導入/削除コストを列にする。現行版・互換・セキュリティ状態をWebで実確認していなければ『未確認』と書き、検索できる場合は公式URLと確認日を記録。venvは再作成する環境、pyprojectのrequires-python/依存宣言と役割を区別する。

出力：候補比較表、暫定推奨と反証条件、15〜60分の小さなSpike（測る値と合否）、依存/環境記録方針、未確認事項。数値ベンチマークは実行していなければ作らない。

結論

この処理は CPU主体ではなく、明確にI/O待ち主体です。CSV集計は実測38秒なのに対し、API部分は 3,000 × 平均0.4秒 ≈ 1,200秒 と約20分を占めています。したがって、今回必要なのはCSV高速化やプロセス並列化ではなく、HTTP POSTをAPI側上限10接続の範囲で重ねることです。

暫定推奨は ThreadPoolExecutor + Requests の同期HTTPです。ただし、現在固定されている requests==2.31.0 はそのままでは採用せず、互換性確認後に現行の修正版へ更新する前提です。asyncio/httpx.AsyncClient/aiohttp は技術的には成立しますが、同時実行が最大10で、開発者がasyncio未経験、2年間1人保守という条件では、現時点で追加複雑性を正当化できません。

Python 3.11自体についても注意があり、公式には現在 security maintenance で、サポート終了は 2027年10月です。2年間保守すると2028年まで届くため、別途Python 3.12以降への更新計画が必要です。 
Python.org

候補比較表

「標準ライブラリのみ」は厳密には urllib.request + ThreadPoolExecutor、「新規依存なし」は既存Requestsを使う案として分けます。

候補	I/O並行方式	Python 3.11 / Ubuntu 22.04	依存	ライセンス	現行版・セキュリティ確認 2026-09-16	保守コスト	導入 / 削除コスト	判定
urllib.request + ThreadPoolExecutor	同期HTTPを最大10スレッド	Python 3.11標準ライブラリで利用可。ThreadPoolExecutor はI/O待ちを重ねる用途を想定した仕組み。 
Python documentation
	新規PyPI依存0	Python本体はPSF License。MIT/BSD/Apache-2.0そのものではない。ただし既採用Pythonランタイムの一部。社内規定が標準ライブラリにも形式上適用されるなら要確認。 
Python documentation
	Python 3.11.16公式文書を確認。脆弱性管理はPython本体/Ubuntu側。	HTTPエラー、JSON、認証、接続再利用等を自前寄りに扱うため高め	導入小〜中。削除は容易	残すが第一候補ではない
既存 requests + ThreadPoolExecutor	同期HTTPを最大10スレッド	Requests現行版はPython >=3.10、3.11対応。OS Independent。 
PyPI
+1
	新規依存0。既存Requestsとそのtransitive deps	Apache-2.0。許可範囲。 
PyPI
	現行安定版は 2.34.2。一方、固定中の2.31.0は <2.32.0、<2.32.4、<2.33.0 を対象とする後発advisoryの範囲に入る。 
GitHub
+3
GitHub
+3
GitHub
+3
	低い。既存コード・経験をそのまま利用可能	最小。並列部分を戻せば容易に直列へ戻せる	暫定第一候補
HTTPX 0.28.1 + AsyncClient	asyncioによる非同期HTTP、Semaphore等で<=10	安定版0.28.1はPython >=3.8で3.11対応、OS Independent。 
PyPI
	httpcore、certifi、idna、async関連等を追加。 
PyPI
	BSD-3-Clause。許可範囲。 
PyPI
	安定版は 0.28.1 (2024-12-06)。GitHub Security Advisoriesには公開advisoryなし。現在は 1.0.dev6 (2026-08-31) までpre-releaseが進行しており、1.0系は再設計中。 
GitHub
+1
	中〜高。asyncio習得＋1.0移行動向を追う必要	導入中。削除時にasyncコードを同期へ戻す必要	今回は見送り寄り
aiohttp 3.14.3	asyncioによる非同期HTTP、Semaphore/Connectorで<=10	最新安定版3.14.3はPython >=3.10、Python 3.11対応、POSIX対応。 
PyPI
	aiohappyeyeballs, aiosignal, attrs, frozenlist, multidict, propcache, yarl 等	Apache-2.0 AND MIT。両方とも許可範囲。 
PyPI
	最新安定版は 3.14.3 (2026-07-23)。<=3.14.2 のC response parserにHigh advisoryがあり、3.14.3で修正。 
GitHub
+1
	高め。asyncio＋aiohttp固有API＋依存数増加	導入中〜高。削除時async部分を書換え	今回は見送り

HTTPX、aiohttpともに「使えない」のではありません。問題はこの案件で必要かです。最大10並行程度ならOSスレッド10本は負荷として小さく、asyncの主な強みである「非常に多数の同時I/Oを少ないスレッドで扱う」必要がありません。

また、純標準ライブラリ案も性能上は成立し得ますが、すでにRequestsが存在する環境でHTTPクライアント部分まで urllib.request へ戻す理由が薄いです。接続再利用、タイムアウト、ステータス処理、JSON送受信、例外処理などの実装量を増やす方向になるためです。

暫定推奨

ThreadPoolExecutor(max_workers <= 10) + 更新したRequestsを第一候補とします。

構成としてはCSV読み込み・集計は現在の同期処理を維持し、集計後の約3,000商品のPOST部分だけをスレッドプールへ渡します。API側上限が10なので、Pythonのデフォルトworker数には任せず、アプリケーション側で明示的に上限を持つべきです。Python公式も ThreadPoolExecutor をI/Oを重ねる用途として説明しています。 
Python documentation

Requestsを使う場合、1個の Session を無条件に全スレッドで共有する設計にはせず、workerごとのSession/thread-local SessionをSpike候補にします。これなら各worker内でHTTP connection reuseを得つつ、共有可変状態を減らせます。

requests==2.31.0 は別途変更対象です。現行は2.34.2で、2.31.0以降にもTLS検証、.netrc、一部utilityに関する修正が出ています。特に社内ルールで pip-audit が必須なら、古い固定版の維持理由を先に解消する方がよいです。 
GitHub
+1

この推奨を反証する条件

次のどれかがSpikeで確認されたら、ThreadPoolExecutor案を再評価します。APIが同時リクエスト時に429/5xxや接続切断を頻発する、スレッド版で必要な締切を満たせない、将来的に同一プロセスで数百〜数千の同時HTTP処理へ拡大することが確定する、または既存システム全体がasyncioベースへ統一される場合です。

逆に、「asyncの方が新しい」「aiohttpの方が速そう」という理由だけでは変更しません。

15〜60分のSpike

コード全体を書き換えず、API送信部だけ比較します。できればステージングAPIを使用し、無ければPOSTが冪等かを確認してから同一在庫値を送る必要があります。

測定対象	測る値	合否
直列Requests	同一商品サンプルのwall time、成功数、4xx/5xx、timeout、p50/p95 latency	比較基準として記録
ThreadPool 5	同上＋最大同時実行数	データ結果が直列と一致し、エラー率が悪化しない
ThreadPool 10	同上＋最大同時実行数	in-flightが10を超えず、429/5xx/timeoutが許容範囲、結果一致
CPU/RAM	process CPU%、最大RSS	並列化で異常なCPU/RSS増大がない
接続再利用	新規接続数またはサーバログ/クライアントdebugで確認可能なら測定	3,000回すべてで新規TLS/TCP接続していないことが望ましい
総ジョブ時間予測	実測並列API時間 + 実測CSV時間 + retry余裕	06:00 - cron開始時刻以内なら性能合格

最後の条件だけは絶対値を今決められません。cronの開始時刻が提示されていないためです。ここを勝手に「5分以内」などとは設定しません。

Spikeではさらに、worker数を10固定と決め打ちする前に5と10を比較します。APIの平均応答時間が並行数とともに悪化するなら、6〜8程度の方が総時間や安定性で有利になる可能性があります。これは実測して決める部分です。

HTTPX/aiohttpまで同じSpikeで実装する必要はありません。まずThreadPoolExecutor版が締切・エラー率・保守性を満たせば、その時点でasync候補には必要性がないと判断できます。これが最小のSpikeです。

依存・環境記録方針

venv、requirements.txt、pyproject.toml は役割を分けます。

venv は再作成可能な実行環境であり、仕様や依存管理の原本にはしません。壊れたら削除して作り直せる状態にします。

pyproject.toml を導入するなら、ここにはプロジェクトとしての最低Python要件を置きます。今回なら将来の3.12移行を阻害しないよう、特別な3.11依存コードがなければ requires-python = ">=3.11" が自然です。「今のサーバが3.11」という事実と、「3.11以外では動かない」という互換性宣言は別物です。

依存宣言については、pyproject.toml と requirements.txt の両方を手編集して二重管理するのは避けます。小規模cronなら、当面 requirements.txt をデプロイ再現用の固定ファイルとして使い、採用版を明示的にpinする方法でも十分です。将来パッケージ化するなら pyproject.toml を論理依存の原本、別のlock/requirementsをデプロイ時の具体バージョン記録に分けます。

リリース証跡としては、最低でも python --version、pip freeze またはlock相当、OS情報、pip-audit結果、採用理由、Spike結果、API同時接続上限をGit管理下に残すのがよいです。

Requestsを継続するなら、まず新しいvenvで現行安定版2.34.2を入れて既存テストを通し、その後 pip-audit を実行する順序が妥当です。Requests 2.34.2はPython >=3.10で、Python 3.11は対象範囲です。 
PyPI
+1

未確認事項

cronの実際の開始時刻。これがないため「6時まで」という絶対性能の合否時間はまだ算出不可。

APIの「同時接続上限10」が、TCP connection数・同時request数・アカウント単位・サーバ全体のどれを意味するか。

429時の Retry-After、5xx/timeout時の推奨retry仕様。

POSTが冪等か。retry設計に直結するため重要。

APIがkeep-aliveを有効にしているか。

現行 requests==2.31.0 を固定している理由、および2.34.2への更新時の互換性。

pip-audit の実環境結果。Webでは既知advisoryを確認しましたが、今回のvenvに対して実際には実行していません。

HTTPX/aiohttpの全transitive dependencyのライセンス。トップレベルパッケージのライセンスは確認済みですが、社内規定が全依存に及ぶならlock後に一括確認が必要です。

Ubuntu 22.04上のPython 3.11がUbuntu公式パッケージ、deadsnakes、ソースビルド等のどれか。セキュリティ更新経路を記録する必要があります。

Python 3.11は2027年10月に公式サポート終了予定なので、2年保守期間中のPython 3.12+移行時期。 
Python.org

したがって現段階の技術選定は、**「asyncライブラリは採用保留。まずRequests更新可否を確認し、ThreadPoolExecutor 5/10並行のSpikeで締切適合を証明する」**まで確定してよい状態です。asyncioを導入するのは、この案が実測で反証された後で十分です。