Rust の Borrow Checker と格闘し、Kubernetes の YAML に時間を取られ、Terraform の State 管理に頭を抱える。
個人開発でそこまでやる必要があったのか、と最近よく思います。

Perl から始まり、Java、Kotlin、Rust、React/Next.js と、モダンとされる技術をひと通り渡り歩いてきました。手元に残っているのは、作りかけのアプリケーションばかりです。

そこで考え直して、いったん素の PHP に戻ってみました。その理由を書きます。

技術を渡り歩いてきた結果

まず、私の来歴を簡単に。

Perl の CGI 時代を経て PHP の手軽さに触れ、その後は型安全と性能を求めて移っていきました。Java の冗長さに嫌気がさし、Kotlin の書き味に感動し、最終的に Rust にたどり着きました。メモリ安全性とゼロコスト抽象化は、エンジニアとしての美意識をよく満たしてくれます。

フロントエンドも同じです。素の JavaScript から jQuery へ、React の宣言的 UI に移り、TypeScript で型を整えることに時間を使ってきました。

ただ、あるときふと立ち止まりました。

私は、インフラの世話をするためにコードを書いているのだろうか。

Docker イメージの軽量化とマルチステージビルドに数時間を使い、EKS のアップグレード計画に悩み、NAT Gateway の料金を気にする。
動けばよかったはずのアプリケーションに、ずいぶん遠回りをしていました。

AI が書くようになって、選ぶ基準が変わった

開発の流れで大きく変わったのは、コードを書く主体が AI になった ことです。Claude CLI や Gemini CLI に要件を渡せば、コードはすぐ出てきます。

そうなると、Rust の「コンパイラが人間に厳しい」という特性が、逆に足を引っぱる場面が出てきます。AI が生成したコードの Borrow Checker エラーを人間が直していく時間は、正直もったいない。動的型付け言語の「実行して動けばよい」という緩さのほうが、AI と組んで進めるときは速く回ります。

そこで PHP でした。

PHP + レンタルサーバーという構成

ここで言う PHP は、Laravel のようなフレームワークでがっちり組む話ではありません。もっと素朴な、あるいは軽量フレームワークを使った最小構成です。

デプロイが rsync で終わる

CI/CD パイプラインも Blue/Green デプロイも、個人開発の初期には過剰だと感じます。

  • モダンな構成：git push → CI（テスト・ビルド）→ コンテナレジストリ → ローリングアップデート → 起動待ち
  • PHP の構成：AI が書く → rsync → 反映完了

rsync なら差分転送で一瞬です。原始的ですが、コンテナのビルドを待っている間に、こちらは本番で動作確認まで終わっています。

費用が桁で違う

AWS や GCP で、まともな RDBMS とロードバランサーを用意すると、月に数千円から数万円かかります。

一方、日本の ロリポップ！ や エックスサーバー はどうか。

  • PHP-FPM はチューニング済み
  • WAF が標準で付く
  • MariaDB も込み
  • nginx / Apache の設定は不要

これで月額500円から1000円程度です。同じものをクラウドで再現しようとすると、VM の管理コストだけで割に合いません。長年の運用で、PHP を動かすことに特化したマネージドサービスになっているのだと思います。

スケールの心配は、当たってから

PHP ではスケールしないのでは、という指摘はあると思います。
ただ、個人サービスに秒間何万リクエストが来る場面が、実際どれだけあるでしょうか。

  1. AI に PHP を書かせ、共用サーバーに置く。ランニングコストは月500円
  2. サービスが伸びてサーバーが苦しくなり、収益が出る
  3. そこで初めて、稼いだお金と AI を使って Rust や Go で作り直し、コンテナに移す

最初から最終構成で作るのは、YAGNI の原則に反します。まず動くものを出して、反応を見るほうが先です。

まとめ

コンテナのホスティングが月500円で、RDBMS 込みで、コールドスタートなしで動くなら、私も Rust を選びます。ただ、現実の選択肢はそうなっていません。

当時の私の開発の流れはこうでした。

  1. AI に要件を伝える
  2. PHP のコードを出力させる
  3. レンタルサーバーに rsync する

これより速く、安く仮説検証を回せる構成があるなら知りたいところです。
必要なのは美しい型定義ではなく、使われるプロダクトのほうだと考えるようになりました。

追記（2026-09-07）：これは当時の思考実験で、実際の構成は別です

この記事は「AIにPHPを書かせてレンタルサーバーへrsyncするのが最速で最安」という主張で書いています。読み返すと、これが私の実際の開発フローだと受け取れる書き方になっているので、はっきりさせておきます。これは当時の思考実験で、今の構成はこうではありません。

現在はこうなっています。サイトはAstroで作ってCloudflare Workersに載せ、データベースはさくらのVPSに立てたPostgreSQLをHyperdrive経由で使っています。デプロイはmainブランチへのpushだけで、rsyncは使っていません。PHPも書いていません。

ではこの記事が全部外れていたかというと、そうでもありません。主張の芯は「凝った技術選定より、仮説検証を速く安く回せるほうが勝つ」で、そこは今の構成にもそのまま引き継がれています。定額のVPSを選んだのも、従量課金でデータベースの請求が想定外に膨らんだ経験があったからで、「安く固定できること」を優先した結果です。RustやKubernetesを持ち出さないという判断も変えていません。

変わったのは、その芯を実現する手段のほうです。当時はレンタルサーバーとPHPが一番速いと考えていましたが、実際に運用してみると、静的生成とエッジ配信のほうが手離れがよく、費用も抑えられました。結論は違ったけれど、選び方の基準は同じ、というのがこの記事の今の立ち位置です。