この記事の途中に、以下の記事の引用を含んでいます。
Show HN: I cross-compiled llama.cpp to run on Windows XP
レトロPCで生成AI！？—「馬にEメールを送らせる」ような異色挑戦
みなさんは、「24年前のパソコンで最新のAIが動く」と聞いて、どんな印象を持つでしょうか？
今回紹介する記事は、そんな“あり得ない”ミッションを現実にした技術者の週末の記録です。
彼はウィークエンドを丸ごと使い、人気の大規模言語モデル推論エンジン「llama.cpp」を、2001年リリースのWindows XPマシンで動作させることに成功しました。
「馬にEメールを送らせる」——記事内のこの喩えは、まさに読者の抱く驚きを的確に表現しています。
この挑戦は、実用性はともかく、技術的・歴史的にきわめて興味深いもので、多くの示唆に富んでいます。
すべては「古いOSでもAIは動くの？」という素朴な疑問から
この記事では、筆者が「what’s the oldest OS you could theoretically run inference on?（理論的に最も古いOSはどれだろう？）」という会話をきっかけに、実際にWindows XP上でllama.cppを動かすことに挑戦した経緯を記しています。
“This started, as these things do, with a stupid question in a Discord server: … I said nothing, but I opened a terminal.”
つまり、理屈抜き・実用性抜きで、「やってみたいからやってみる」。
これが現代のOSS文化の醍醐味である、と私は感じます。
特に着目すべきは、筆者が進めた「クロスコンパイル」。
macOS上でWindows XP向けにビルドし、なんと「70以上のWindows実行ファイル」「フルGGUFモデル対応」で、ありし日のPCハードウェア（時代相応のCPU）上で実際に2～8トークン/秒で動作させています。
記事ではこの過程を、Stage 1からStage 5までの“挫折と突破”のドラマとして描いています。
技術的な“壁”—失われたAPI、現実のハード制約
Windows XPといえば、もはや現役で使っている人は少ないかもしれません。
しかし、組み込みや工業用機器など“レガシー”な現場では、今も長期サポートのため稼働している場面もあります。
筆者はこう書いています。
“First, proof of concept. If llama.cpp can run on XP, it can run anywhere. The codebase is genuinely portable.”
技術解説として、特に注目したいポイントがいくつかあります。
1. APIとバイナリ互換性の壁
XP時代にはなかったAPI（例えばSRWLOCKなどの同期プリミティブや、UCRT/Universal C Runtime）がこのプロジェクトの大きな難所になりました。
ビルドツールチェーンの“ターゲットWindowsバージョン”を0x0502（XP x64）に明示し、さらにスレッド同期方法やCランタイムのバージョンにも細かな調整が必要です。
この試行錯誤を記事は次のように綴っています。
“llama.cpp uses SRWLOCK for synchronization… XP doesn’t have them. XP has CRITICAL_SECTION… This is where Claude did the heavy lifting.”
つまり、Vista以降登場した高速プリミティブを古典的な手法に置換しなければならない。
ここで、AIアシスタント「Claude」がコード分析を担い、該当部分をXP互換に“書き戻す”ことで突破口が開かれました。
2. 外部ライブラリの“歴史的バージョン”追跡
ネットワーク通信機能（モデルダウンロードやサーバー機能のためのcpp-httplib）は、最新バージョンがXP非対応。
そこで
“The answer was version pinning. cpp-httplib v0.15.3 doesn’t have the Windows version check…”
とある通り、Git履歴をたどって「XP互換が残っていた」バージョンまでダウングレードし、通信機能ごと巻き戻すことで問題を解決しています。
このような「レトロ互換性バグ」は、現実のレガシー保守現場でもありがちな課題です。
古いOS／古いランタイム／新しいアプリの三角関係を、現場技術力で“手繰り寄せて”動かす好例と言えるでしょう。
3. ハードウェア制約との闘い
加えて、XP時代のCPUにはAVXやFMA命令がなく、SSE4.2までが安全圏。
ビルド時に対象命令セットを正しくON/OFFすることで、ターゲットハードに最適化しています。
bash
cmake -B build-xp \
-DGGML_NATIVE=OFF \
-DGGML_AVX=OFF \
-DGGML_AVX2=OFF \
-DGGML_FMA=OFF \
-DGGML_SSE42=ON
このような細やかな対応があって、初めて古いPCで“現代のAI”が動きます。
ここにクロスコンパイラの意義と凄みが光ります。
“目的なき情熱”から生まれるイノベーションの価値
筆者は「なぜこんな無駄なことを？」という問いに、次のように答えています。
“Sometimes you build things because building things is fun. Not everything needs a business case.”
ここに、現代のOSS文化やエンジニアリングの原点が現れています。
“役に立たないこと”に本気で取り組むことで、結果としてコードの可搬性やDAOメンテナンス力、ひいては後世に残るドキュメントと技術資産が生まれる。
これはかつてのLINUXやGNU開発現場にも共通した“遊びの本気度”です。
また、「AIにコーディングそのものを任せる」のではなく—
“This is what actual development with AI assistance looks like. Not magic. Not ‘AI wrote everything.’ A collaboration…”
と述べるように、「人間がゴールを知り、AIが探索を助ける」。
これは現代開発のリアルであり、AIリテラシーの高い少数精鋭の象徴といえる手法です。
読者への示唆—変人の“無意味”はやがて技術史を動かす
このプロジェクトは一見、“変わり者の無駄な苦労”に思えます。
しかし、レトロコンピューティングとしての知的おもしろさに加え、「現代のAIエンジンは、実はOSやハードに相当ピュアに依存している」「細やかな対応さえ怠らなければ、最新AI技術も20年前のOS・CPUで動かせる」という“技術遺伝子”の証明にもなっています。
とりわけ、「業務で使うわけじゃない」と軽んじるなかれ。
組み込み現場やスタートアップ黎明期では、「既存資産の上に未来技術を載せる」場面は確実に生じます。
本記事の細かなノウハウは、苦しい現場で意外と役立つ知見となるはずです。
また、「変わったことをやった結果、実はコードの移植性・構造体の設計原則・OSS開発体制――こうした“ふつうの”現場課題が根こそぎ鍛えられる」という、現代の開発者へのメッセージを私は強く受け取りました。
まとめ：現代OSSの遊び心と職人魂を再評価せよ
本記事が、プログラム技術者としてどんなに有益なレッスンを私たちに与えてくれるか。
その核は、「何の役に立つのか？」の問いを超えた“作ることの面白さ”への情熱と、「一見くだらない挑戦」こそがイノベーションの原動力になりうる、という歴史的真実です。
どうせ最新のハードじゃないと生成AIなんて動かないだろう――そんな先入観を見事に打ち砕く“証明”として、技術者はもちろんレガシーシステム保守に携わる方から「楽しい技術遊び」を求める皆さんにも、本記事の価値はきわめて高いと断言できます。
みなさんも、週末に「バカバカしい疑問」を持って手を動かしてみてはいかがでしょうか？
“Go build something weird.”
この言葉に象徴されるエネルギーこそが、未来を切り開く原動力なのです。
categories:[technology]
コメント