この記事は中国語版を AI が翻訳したものです。内容に相違がある場合は中国語版を正とします。
はじめに
個人開発をするとき、私の動機はいつもシンプルです。純粋な興味で何か作ってみたいか、日頃の仕事をちょっと便利にするツールが欲しいかのどちらかです。
ここ2年ほどAIを使ったコーディングが日常的になるにつれ、以前なら当たり前だと思っていた技術選型の基準が変わってきました。手元のコードを整理するついでに、今後の個人開発で軸にしていく技術スタックを一度しっかり固めてみることにしました。
Delphi と Java から離れた理由
Delphi：好きな言語だが、学習データとエコシステムが限られる
私のプログラミングの原点は Delphi です。今でも Object Pascal はとても気持ちよく書ける言語だと思っています。波括弧を使わず、begin...end で構成されるブロック構造は読みやすく、構造もすっきりしています。
ただ現実問題として、Delphi のコミュニティはかなり小さくなりました。基本的なライブラリを自分で書かなければならない場面が多く、さらに大きいのが、近年の大規模言語モデル（LLM）の学習データに Delphi のコードが少ない点です。AI にコードを書かせても精度や速度がいまひとつ奮いません。言語への愛着はありますが、現在のメイン言語にするのは難しいと判断しました。
Java：仕事には最適だが、個人開発には重すぎる
仕事で一番長く付き合ってきた言語は Java です。エコシステムも整っており、大規模開発やエンタープライズ領域では今でも手堅い選択肢です。
しかし、個人開発に持ち込むと重さが気になります。
- 事前の準備が多い：簡単な機能を作りたいだけなのに、パッケージ構成や設定ファイルの手間がかかり、素早く形にしづらい。
- リソース消費が大きい：ビルド後の成果物が大きくなりがちで、実行時にも相応のメモリを食います。個人で借りている低スペックな VPS では、Java アプリをいくつか動かすだけで手一杯になってしまいます。
そのため、プライベートの開発では Java から距離を置くことにしました。
フロントエンド：モダンフレームワークを使わない理由
Web アプリの開発において、私は React や Vue といった主流のフロントエンドフレームワークをあえて外しています。
理由は大きく2つあります。
1つは、もともと私がフロントエンドを得意としていないことです。加えて、この分野のフレームワークやビルドツールは変化が非常に早く、少し触らないでいると新しい概念に置き換わっています。個人開発の範囲で、そのキャッチアップに労力を割き続けるのは割に合いません。
もう1つは、Node エコシステム特有の巨大な node_modules です。ちょっとしたツールをいくつか作るだけでディスク容量をギガ単位で圧迫し、管理が煩わしく感じてしまいます。
自分用の操作画面を作るだけであれば、重厚なフロントエンド環境を持ち込む必要性はありません。
軸となる選択：C# と .NET
バックエンドや画面付きツールの開発において、中心に据えたのは C# と .NET です。
C# の言語設計は昔から好感を持っています。LINQ やパターンマッチング、レコード型、null許容参照型など、言語機能の進化にも積極的です。Delphi と C# の生みの親が同じアンダース・ヘルスバーグ（Anders Hejlsberg）であるためか、文法や設計思想にもどこか通底する心地よさがあります。
近年の .NET はクロスプラットフォーム対応も十分に成熟しました。Linux Mint と Windows でツールを書いてきましたが、Native AOT を使えば 10〜20MB 程度の単一バイナリにまとまります。起動は一瞬でメモリ消費も少なく、低スペック VPS や普段使いの PC でも軽快に動いてくれます。
Web 画面には C# Minimal API + HTMX + Tailwind CSS を組み合わせています。
- ビジネスロジックや API は C# で完結させ、サーバーからレンダリング済みの HTML 断片を直接返す。
- フロントは素の HTML をベースに、HTMX の属性を使って必要な部分だけを画面更新する。
- Node 環境の構築も TypeScript のビルドも不要になり、依存関係のメンテに悩まされずに済みます。
開発シナリオ別の使い分け
用途や形態に合わせて、以下のように整理しました。
1. CLI や自動化スクリプト：Go
コマンドラインツールやバックグラウンドで動かす常駐デーモン、スクレイピングスクリプトには Go を第一候補にしています。
- ビルドが非常に速く、生成される単一バイナリをそのまま配れるため運用が手軽です。
- 文法が明快でブレが少ないため、AI の生成精度も高く、コンパイルエラーが出てもエラーメッセージを読ませればほぼ一発で修正してくれます。
2. デスクトップアプリ：Windows ネイティブと Linux での現実解
普段使っている OS は Windows と Linux Mint です。
- Windows：ネイティブの C#（WPF または WinUI） を採用。使い慣れており、OS との親和性やツール群の安定感も抜群です。
- Linux Mint：
- 現状は Electron を優先：小さなツールに 100MB 以上の容量を割くのは本意ではありませんが、Linux 上での環境互換性やウィンドウ管理のトラブルシューティングにおいて、現状もっとも情報と実績が集まっているのは Electron です。AI も熟知しているため、開発効率を最優先し、サイズ面は妥協しています。
- 今後は PyQt を検討：C++ で GUI を組むのはハードルが高いため、Linux 上でより軽量なネイティブ UI を目指すなら PyQt が最も現実的な選択肢になると考えています。
3. モバイルアプリ：Android ネイティブに絞る
個人の用途ではモバイルアプリを作る機会は少なく、iOS 端末も持っていないため、マルチプラットフォーム対応を気にする必要がありません。
以前 Flutter でいくつか小型アプリを作ったこともあり、感触自体は悪くありませんでした。ただ現在の状況を踏まえると：
- 第一候補：Android ネイティブ（Kotlin + Jetpack Compose）。長年 Java を扱ってきた経験があるため、Kotlin は違和感なく書けます。権限周りやバックグラウンド処理の扱いも素直で、AI も Compose の扱いに長けています。
- 控え案：もし将来複数の OS に対応する必要が出てきたら、その時に Flutter を再検討すればよいと考えています。
AI 協働における現実的な視点
言語やツール自体の使い勝手だけでなく、普段利用している AI の能力差も技術選定に直結します。
私の利用環境は以下の通りです。
- 会社の業務環境：会社契約の GitHub Copilot（OpenAI や Anthropic の最上位モデルが利用可能）。
- プライベート環境：opencode を利用（opencode go のサブスクリプション）。
個人の開発では、通常枠のモデル枠内でやりくりすることになります。そのため、選ぶ技術スタックには次の2つの条件が求められます。
- 学習データが潤沢であること：Go、C#、Kotlin はオープンソース界隈で非常にメジャーなため、AI が定番の書き方をしっかり把握しており、見当違いなコードを吐きにくくなります。
- コンパイラが明確なフィードバックを返してくれること：モデルの能力に制約がある場合、動的言語で生じたロジックの不具合は修正のループに陥りがちです。Go、C#、Kotlin のような静的型付け・コンパイル型言語であれば、明確なエラー出力が AI にとって確かな道標となり、素早い自己修復が期待できます。
データ永続化と実行環境
コードを取り巻く周辺環境も、できるだけシンプルに保っています。
- データストレージ：組み込み型の SQLite または DuckDB。単一ファイルでデータが完結するため、データベース用のサーバープロセスを立てる必要がなく、バックアップもファイルコピーだけで済みます。
- 実行環境：Docker Compose と軽量ベースイメージの組み合わせ。起動と撤退が容易で、環境を汚しません。
- ビルドスクリプト：Linux は
build.sh、Windows はbuild.ps1を用意し、よく使うビルドコマンドやテスト手順をスクリプト化しておきます。
おわりに
整理してみると、現在の自分に適した組み合わせは次のようになりました。
- システム系・CLI：Go
- Web サービス・ツール：C#（.NET + HTMX）
- デスクトップ：Windows は C# ネイティブ、Linux Mint は当面 Electron（将来 PyQt を視野に）
- モバイル：Android ネイティブ（Kotlin）
最先端の流行を追った構成ではありませんが、自分のプログラミング嗜好を満たし、追従に疲弊しがちなフロントエンドのビルド環境を避け、個人の AI 環境のスペックとも綺麗に噛み合っています。余計な手入れを気にせず、思い立ったアイデアを少ないエネルギーで形にするための、現時点で一番しっくりくる技術スタックです。