世界中のWebを支えるPHP、財団の常勤職員はわずか1人：深刻な資金不足と開発体制の実態

Webアプリケーションなどで広く利用されているプログラミング言語「PHP」を支えるPHP Foundationが、深刻な資金不足に直面している。同財団のElizabeth Barron事務局長は、2026年10月23日のReutersによるメール取材に対し、常勤職員は自身の1人だけで、主に非常勤の契約者14人とともに活動していると明かした。PHPの開発やセキュリティ対応を支える組織としては、限られた人員と資金で運営されている実態が浮かび上がった。

ただし、常勤職員が1人という数字は、PHPの開発に携わる人数全体を意味するものではない。財団は外部の専門家に開発やコードレビューを委託する形で活動しており、PHP自体も広範な開発者コミュニティによって維持されている。2025年の財務報告と、10月21日に公表されたセキュリティ対応の総括を合わせて見ると、問題は単純な人手不足にとどまらず、専門家の作業時間を確保する資金と、難しい技術的判断を下すための体制の両方にあることが分かる。

常勤職員は1人、PHP Foundationを支える開発体制

Barron氏によると、財団の理事は無報酬で活動しており、運営資金は寄付と助成金によって賄われている。財団が2026年5月に公開した2025年の年次報告では、同年末時点の体制として、8人のボランティア理事、JetBrainsの支援を受ける事務局長、常勤・非常勤を含む11人の契約開発者が記録されている。つまり、財団の常勤職員数と、契約によって確保している開発者の人数は別の指標だ。常勤職員が少なくても、外部の専門家に継続的な開発作業を委託することはできる。

また、2025年末の契約開発者11人と、2026年10月にBarron氏が説明した契約者14人を比較しても、開発体制がどの程度拡充されたかは分からない。集計時点が異なるうえ、「契約開発者」と「契約者」では対象となる人員の範囲が一致するとは限らないためだ。各契約者の稼働時間も公表されておらず、人数の増加をそのまま開発能力の向上とみなすことはできない。一方、特定の問題に複数の契約者が専念できることと、財団の常勤職員が1人しかいないことは矛盾しない。

さらに重要なのは、PHP FoundationがPHP言語そのものを統治する組織ではないという点だ。財団は年次報告で、PHPはコミュニティに属しており、自らは言語の統治権限を持たないと明記している。財団が開発者に資金を提供しても、言語仕様の変更や重要な修正を独断で決定できるわけではない。この資金提供者と意思決定主体の違いは、セキュリティ上の問題が見つかった際の対応にも影響する。

2025年は約14万ドルの支出超過、財団が明かした資金事情

PHP Foundationの2025年の寄付総額は73万534ドルだった。ただし、この全額が開発や運営に使えたわけではなく、各種手数料を差し引いた実際の受取額は64万5,191ドルとなっている。一方、同年の支出は78万4,376ドルに達しており、受取額を上回った。公式年次報告の財務データを整理すると、以下のようになる。

2025年の財団財務	金額（米ドル）
寄付総額	730,534
手数料	85,343
手数料控除後の受取額	645,191
支出	784,376
受取額に対する支出超過	139,185

2025年の支出超過額は13万9,185ドルで、支出78万4,376ドルから手数料控除後の受取額64万5,191ドルを差し引いて算出したものだ。寄付総額との差ではなく、実際に財団が受け取った資金と支出を比較している。なお、財団は一部の取引をユーロで行っているため、通貨換算に伴う丸めの差があると注記している。

もっとも、支出が収入を上回ったからといって、直ちに財団の財政が破綻しかけているわけではない。財団は年次報告で、技術人員への投資を維持するために意図的に支出を増やしたと説明しており、支払能力を維持し、健全な準備金も確保しているとしている。その一方で、収入と支出の差を縮小することを2026年の優先課題に掲げた。専門家への継続的な投資を維持しながら、財政の持続可能性を高める必要があるということだ。

ただし、今回確認できる財務数値は2025年のものであり、2026年10月時点の財政状況を直接示しているわけではない。また、PHP Foundationの会計はPHP開発コミュニティ全体の予算とも異なる。準備金の具体的な状況や今後の収入を考慮せず、この支出超過額だけから資金が枯渇する時期を予測したり、現在の契約者1人当たりの費用を算出したりすることはできない。

セキュリティ修正の遅延が浮き彫りにした資金と意思決定の課題

PHP Foundationの契約開発者は、PHP本体のソースコードを管理する「php-src」で、2025年に作成されたコミットの42％を担った。さらに、コミュニティから提出された1,685件のプルリクエスト（PR）をレビューしている。コミットの42％という数字は、変更したコードの行数や投入した作業時間、開発品質の割合を示すものではなく、PRのレビュー件数とも集計対象が異なる。それでも、財団がPHP本体の開発だけでなく、他の開発者が提案した変更の検証にも大きく関わっていることが分かる。

財団が支援する業務はコードの開発とレビューだけではない。年次報告には、リリース管理、Windows向けの配布、開発インフラや文書の維持なども含まれている。これらの継続的な業務を担当する専門家は、深刻な脆弱性が発見された場合、通常業務と並行して調査や修正に取り組む必要がある。こうした限られた人的資源の配分と、修正方針を決定する難しさは、財団が10月21日に公開したセキュリティ対応の総括でも明らかになった。

問題の発端は2024年にさかのぼる。外部監査で指摘された問題を修正する過程で、財団と契約するPHPのコア開発者が、メモリ不足に関連する別の問題の兆候を発見した。しかし、当時は具体的な攻撃経路を特定できず、修正方法についても意見が分かれた。既存の動作との互換性を損なう案や、サービス妨害につながる可能性がある案、PHPの拡張機能に広範な変更を求める案などがあり、安全に修正する方法を決められなかったという。

財団の説明によれば、この問題に精通した開発者が限られていたことに加え、関係者の合意を重視する意思決定の仕組みが、対応の遅れにつながった。修正作業は停滞と再開を繰り返し、解決までに長い時間を要した。財団自身も、遅延の背景には資源不足だけでなく、意思決定プロセスにも構造的な問題があったと認めている。つまり、2025年の支出超過を根拠に、資金不足が直接脆弱性を生み出したと結論付けることはできない。修正によって別の不具合やセキュリティ上の危険が生じる可能性を誰が評価し、意見がまとまらない場合に誰が最終判断を下すのかという、開発体制そのものの課題もあった。

状況が大きく動いたのは2026年8月11日だ。Califが同じ根本原因を悪用し、外部からコードを実行できる具体的な攻撃経路を報告したことで、財団のセキュリティ担当者はこの問題への対応を最優先課題とした。財団は、資金が確保されていたために複数の専門家を調査と修正に専念させることができ、週末を含めて昼夜にわたる調整にも対応できたと説明している。専門家の作業時間を確保するための資金が、実際のセキュリティ対応を支えた事例といえる。

一方、開発者が処理しなければならない仕事は増え続けている。Barron氏はReutersに対し、コードの変更提案は1年前と比べて2倍近くに増えたものの、貢献者の人数は同じ割合では増えていないと述べた。提案の絶対件数や集計方法、増加分のうちAIが生成したコードの割合などは明らかにされていない。ただし、変更提案が増えても、それを確認して品質や安全性を判断する人員が比例して増えるとは限らないという問題は残る。

財団の総括によると、2026年7月1日以降に15件のCVEを公開する一方、無効、重複、再現不能と判断された報告も100件以上処理していた。ただし、CVE15件と報告100件以上が同じ報告群を分類した数値かどうかは確認できず、両者を合計して脆弱性報告の有効率を算出することはできない。無効な報告と重複した報告も性質が異なる。財団は、AIが報告の検証や同じ根本原因を持つ問題の整理に役立つとしつつも、最終的な判断と修正には人間の専門家が必要だと説明している。

こうした課題に対応するため、財団はセキュリティ体制の見直しも進めている。2026年5月にはEcosystem Security Teamを設置し、7月にAlexandre Daubois氏、9月にはDaniel Scherzer氏が参加した。さらに、セキュリティチーム内で多数決や妥協による判断を可能にする仕組みを整え、難しい案件については早い段階で上位の判断を仰ぐ方針を示している。専門家を増員するだけでなく、意見の対立によって修正作業が止まらないよう、意思決定の方法も改めようとしている。ただし、これらの変更によって実際の対応時間がどの程度短縮されるかは、今後の運用実績を確認する必要がある。

PHPの安全性維持には、利用企業側の人員と予算も不可欠

PHPのセキュリティを維持する責任は、PHP Foundationだけが負うものではない。財団などの上流開発者が問題を調査・修正し、各配布元が必要に応じてパッケージへ反映した後、利用企業は自社のアプリケーションや稼働環境で修正を検証し、適用する必要がある。財団への資金支援によって上流の開発体制を強化できたとしても、企業側に更新作業を担当する人員や予算がなければ、実際のシステムの安全性は維持できない。今回の脆弱性対応は、こうした役割分担の重要性も浮き彫りにしている。

PHPの公式リリース情報によると、10月21日に公開された修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35で、Webリクエストを処理するPHPの構成が問題の対象となる。通常の保守が終了しているPHP 7.4、8.0、8.1についても、最小限のソースコード修正が用意されており、各配布元によるバックポートも行われている。ただし、特定の脆弱性に対する修正が提供されたからといって、旧バージョンの通常サポートが再開されたわけではない。さらに10月23日には異なる条件で発生する別の脆弱性も告知されており、21日の修正版を適用するだけで、今後のセキュリティリスクがすべて解消されるわけでもない。

PHPの公式サポート方針では、各リリース系列に対して2年間の通常サポートを提供し、その後さらに2年間、重要なセキュリティ問題への修正を提供するとしている。PHP 8.2のセキュリティサポートは2026年12月31日に終了する予定だ。したがって、今回の修正版であるPHP 8.2.35を適用した企業も、サポート終了後の運用を続けるのであれば、より新しいバージョンへの移行計画を立てる必要がある。脆弱性への緊急対応と、サポート期限を見据えた継続的な更新は、それぞれ別に進めなければならない。

もっとも、企業が古いPHP環境を使い続ける背景には、技術的・組織的な制約もある。IPAが10月22日に公開した注意喚起では、アプリケーションの改修や動作検証に加え、技術的なノウハウの不足、担当者の不在、保守契約の終了などが更新を難しくする要因として挙げられている。そのためIPAは、現場の技術担当者だけでなく、事業責任者や経営層も含めて、人員、予算、保守体制を検討するよう求めている。必要な体制を確保できない場合には、システムの移行や機能縮小、公開終了、廃止も選択肢となる。

PHP Foundationが抱える問題は、オープンソースソフトウェアの安全性を維持するために、誰が費用を負担し、誰が必要な判断を下すのかという課題を改めて示している。財団は資金調達と意思決定体制の改善を進めているが、その成果は今後の修正対応や開発実績を通じて評価する必要がある。一方、PHPを利用する企業にも、上流の開発を支えることに加え、自社環境で修正を検証・適用し、サポート期限に合わせて移行を進めるための継続的な投資が求められる。PHPの安全性を維持するには、開発側と利用側の双方で、専門家の時間と予算を確保することが欠かせない。