長年、多くのソフトウェア開発者に愛用され、UNIX系OSにおける標準的なテキストエディタとして君臨してきた「Vim」のエコシステムにおいて、ソフトウェア開発プロセスそのものの在り方を根底から問う新たな動きが表面化した。SourceHutの開発者として知られ、分散型かつ独立志向の強い技術インフラを推進してきたDrew DeVaultは、生成AI(LLM:大規模言語モデル)の支援を受けたコードがオープンソースプロジェクトに混入することに強い反発を示し、独自のフォークである「Vim Classic 8.3」の初版をリリースした。本プロジェクトは、AIツールを開発プロセスにおいて一切使用せずに保守される長期サポート版(LTS)のVimを提供することを主眼に置いている。

このプロジェクト分裂の背景には、近年のオープンソースコミュニティにおけるLLM活用の急速な普及と、それに伴う開発パラダイムの急激な変化がある。例えば、Vimの強力なオルタナティブとして急成長を遂げた「Neovim」のプロジェクトにおいては、AIの支援を受けて作成されたプルリクエスト(PR)に対して専用のラベルが付与されており、実際にそうしたコードが多数のレビューを経てメインラインにマージされている実態がある。DeVaultは2026年3月の時点で、VimおよびNeovimの双方におけるこうしたAI依存の進行に深い懸念を表明しており、ブラックボックス化されたLLMの支援を受けて開発されたソフトウェアを自身のツールチェーンで使用することへの明確な拒絶を示していた。

また、Vim本体の開発コミュニティにおいても、特定の貢献者が提出したパッチにおいてLLMを使用しているのではないかという疑惑がGitHubのイシュー上で議論される事態が発生している。Vimのコアメンテナ側は、技術的な正当性が確認できれば出所を過度に問わないとしてこうした告発に対して慎重な姿勢を見せているものの、コードの生成元やライセンスの汚染リスク、あるいは機械生成コード特有の品質担保に関する疑心暗鬼は、開発者間の透明性と信頼関係に微妙な影を落としている。Vim Classicの誕生は、こうした生成AIのコード生成能力に対する根本的な不信感と、職人的で純粋な人的コーディングのプロセスを維持したいという技術的イデオロギーが正面から衝突した結果として生み出されたものである。

AD

Vim 8.2.0148をベースとする技術的背景とVim9 Scriptの排除

Vim Classic 8.3のアーキテクチャにおける最大の技術的特徴は、あえて最新のVim 9.x系をフォークのベースにせず、Vim 8.2.0148という数年前の過去のバージョンを起点としている点にある。この特定のパッチバージョンが選ばれた理由は、Vimの拡張スクリプト言語に根本的な刷新をもたらした「Vim9 Script」がコードベースに導入される直前の状態であるためだ。DeVaultは、本プロジェクトのコンセプトを「Vim9 Scriptが存在せずにVim 8.3がリリースされた代替の歴史」と位置づけており、過度な機能拡張よりも既存の動作の安定性と保守性の維持を最優先する設計思想を明確にしている。

この意図的な先祖返りとも言える技術的決定は、Vim Classicの開発チームが本家Vimのエコシステムに比べて人的リソースや制度的知識において決定的な劣勢にあることを率直に認めた結果の、極めて現実的かつ戦略的な選択である。Vim9 Scriptは実行速度の大幅な向上をもたらした一方で、言語仕様やインターフェースを劇的に複雑化させた。このような大規模かつ複雑な新機能を維持・保守していくことは、少数の有志によって運営されるフォークプロジェクトにとっては過大な重荷となる。限られた人的リソースのみでプロジェクトのライフサイクルを維持するためには、コードベースを極力シンプルに保ち、メンテナンスの表面積を意図的に縮小する必要があったのだ。

vim-classic-forking-path.webp

しかしながら、この保守的なアーキテクチャの選択は、エンドユーザーに対して極めて厳しい技術的代償を要求することになる。最も顕著かつ直接的な影響は、近年のVimプラグインエコシステムとの互換性の完全な喪失である。Vim9 Scriptの高速な実行性能や厳格化された新しい構文に強く依存して開発された最新の強力なプラグイン群は、古いスクリプトエンジンしか持たないVim Classic上では一切動作しない。ユーザーは、AIフリーという思想的純潔性を手に入れることと引き換えに、現代的なVimが提供する高度な機能拡張や非同期処理のパフォーマンスといった多大な技術的恩恵を放棄する選択を迫られることになる。

セキュリティと保守体制における不確実性という課題

古いコードベースをフォークして独自の系統として維持する際、最も深刻かつ永続的な技術的課題となるのが、セキュリティパッチの継続的なバックポート適用と脆弱性管理のサイクルの構築である。Vim Classic 8.3の公式リリースノートにおいて、開発チームはVim 8.2以降から現在までに発見・修正された多数のCVE(共通脆弱性識別子)に対するパッチを本家のリポジトリから抽出し、バックポートするよう特別な努力を払ったと強調している。しかし同時に、適用可能で実際に悪用可能なすべてのセキュリティパッチを網羅しきれたという確証は持てていないという、技術的な不確実性を率直に認めている。

Vim 8.2.0148のリリース以降、本家のリポジトリには数千コミットにも及ぶ膨大な数のパッチがマージされており、Vim Classicの開発チームはそのすべての変更内容を詳細に評価・検証できているわけではない。したがって、過去数年間に本家で既に修正されたはずのマイナーな不具合や、特定条件下でのみ発火する脆弱性が、Vim Classicの環境下でそのまま再発するリスクが構造的に内在している。このため、DeVaultはVim Classic 8.3を即座に日々の業務におけるメインのテキストエディタとして使用することは推奨しておらず、潜在的なバグや未修正の脆弱性が依然として存在するというセキュリティ上の重大なトレードオフを十分に理解し、許容できるアーリーアダプターのみを対象としていると強い警告を発している。

今後の持続可能な保守体制の確立において、Vim Classicプロジェクトはユーザーコミュニティの自発的な貢献に対する強い依存を余儀なくされる。各ユーザーの多様なユースケースにおいて発生するエッジケースの不具合の特定や、本家から該当するパッチを探し出して競合を解決しながら移植するバックポート作業には、コミュニティメンバーの高度な技術的知識と積極的な参加が不可欠である。AIを完全に排除した純粋なオープンソース開発という思想的理想を掲げる一方で、その理想をコードレベルで支えるための労働力である手作業によるコードの精査と移植をどのように継続的に確保していくかが、本プロジェクトの長期的な存続可能性を左右する最大の焦点となる。

AD

Charitywareモデルの継承とソフトウェア開発の社会的責任

Vimの長い歴史と強固なエコシステムを語る上で欠かせないのが、原作者である故Bram Moolenaarが提唱し、長年にわたって実践してきた「Charityware(チャリティウェア)」という独自のライセンスおよび社会貢献のモデルである。Vim Classicは、本家からのコード分岐に加え、こうした利他主義的な思想をそのまま継承しており、ユーザーに対してウガンダの恵まれない子供たちへの支援を継続的に呼びかけている。かつてMoolenaarが心血を注いで支援していた慈善団体ICCF Hollandは、彼の逝去に伴い解散することとなったが、その貧困救済の使命はKuwashaという新たな慈善団体に引き継がれている。DeVaultは、Vim Classicへの移行を一つの契機として、ユーザーに改めてこのプロジェクトの社会的側面に目を向け、Kuwashaへの寄付を行うよう強く求めている。

ソフトウェアの配布インフラストラクチャやコミュニティの形成手法についても、DeVaultの非中央集権的な設計思想が隅々にまで強く反映されている。Vim Classic 8.3のソースコードおよびバイナリは、現在オープンソース開発の標準となっている巨大プラットフォームを意図的に避け、彼自身が開発に関与するSourceHutを通じて、堅牢なPGP署名付きのソース・ターボールという伝統的な形式で配布されている。また、プロジェクトの方向性を決定づける重要なリリース情報や議論は、クローズドなチャットツールではなくメーリングリストを通じて告知および進行される。開発・配布のインフラ全体において、特定の大企業エコシステムやAIを積極的に推進する巨大資本に一切依存しない、オープンで独立したハッカー文化の伝統的な作法が徹底して貫かれている。

生成AIがコーディングの生産性を飛躍的に向上させ、ソフトウェアエンジニアリングの常識を塗り替えつつある現代において、Vim Classicの存在は一見すると時代錯誤であり、技術的合理性とは対極にあるように見えるかもしれない。しかし、AIモデルの学習データに関する法的な著作権問題や、生成されたコードの品質保証、さらにはセキュリティリスクに対する懸念が業界全体で完全に払拭されていない現在、AIの介入を意図的に排除するという極端な選択肢を提供すること自体が、オープンソースコミュニティの健全な多様性を示す一つの重要な指標となっている。Vim Classicが今後、一部の熱狂的な支持者による局所的なニッチプロジェクトに留まるのか、あるいはAI駆動開発に対する広範なアンチテーゼとして確固たる勢力を築き上げるのか、その動向はソフトウェア開発の未来における純粋な人間の介在価値を問い直す重要な試金石となる。