🐳

2025年に調べたり構築した開発環境について

に公開
Docker
Git
Linux
VS Code
tech

はじめに

2025 年に調べたり構築した開発環境について、振り返っておこうと思います。基本的に Linux をメインに Web アプリの開発環境を構築することが多いです。

モダンな Web アプリの開発環境というと、VS Code + Docker + Git が必須となっているので、これらをベースとして環境構築をしています。2025 年は、これらを使った開発環境の構築をしていました。また、生成 AI が大きな話題となったこともあり、それを意識した環境の構築につながるように、いろいろと調べたりしていました。

生成 AI ツールについては Gemini CLI の利用に絞っていて、まだ積極的にバイブコーディングのための環境構築をしているわけではありません。とはいえ、基本的に使用する開発用ツール、プログラミング言語のバージョン、フレームワークといったものを生成 AI が把握しやすいように用意することを意識して、環境構築しています。

2025年は、開発コンテナーで常時開発するのはコンピュータリソースの有効活用から厳しいという印象を持つようになって、開発環境のリファレンス実装という位置づけとするのが良いと考えるようになりました。

個人的には開発マシンは VirtualBox や Linux KVM といった仮想マシンで構築しています。仮想マシンはデスクトップマシンであればまだ実用的に稼働できますが、ノートパソコンだと必要とするコンピュータリソースのハードルが高くて実用的ではないという印象を持っています。

とはいえ、全体的に IaC 関連の技術が発展したことで、開発環境の設計図をコード化することは手軽にできるようになってきていて、古い開発環境の維持に割くコストは以前ほど高くはありません。コンテナー、開発コンテナー、仮想マシン、実マシンをうまく組み合わせて開発の作業がしやすい環境を構築できるようになりたいと考えています。

Visual Studio Code

Visual Studio Code は、Linux、Windows、macOS に対応していて、Intel 系 CPU だけでなく ARM 系 CPU にも対応している OSS ベースの高機能エディタということで、重宝しています。VS Code や、vscode と省略されることがあります。

本体だけでも十分便利なのですが、拡張機能も充実しているのが、ありがたいです。プロファイル機能を使って、使用する拡張機能の切り替えをある程度するようにしています。

拡張機能としては下記は必ずインストールしています。

拡張機能 拡張機能 ID
Japanese Language Package MS-CEINTL.vscode-language-pack-ja
Container Tools ms-azuretools.vscode-containers
Docker DX docker.docker
Remote Development ms-vscode-remote.vscode-remote-extensionpack

特に、Remote Development には次の拡張機能が含まれているので、重宝しています。

以前は Docker 拡張機能（ms-azuretools.vscode-docker）を使っていましたが、現在は、Container Tools、Docker DX を使っています。

Docker

基本は Docker Engine を Linux マシン/WSL Ubuntu へインストールして使っています。一応、Docker Desktop も使えるようにはしていますが、こちらは個人利用をするときに使うだけなので、あまり使っていません。

Docker Desktop が提供する GUI も便利ですが、ほとんどの部分については、VS Code + Container Tools 拡張機能で対応できることなので、基本的に VS Code を使うようにしています。

とはいえ、Docker Desktop も便利な機能が多くあります。Docker Desktop を使う場合は、次の Docker Desktop 用拡張機能をインストールしています。

  • Resource usage
  • Volumes Backup & Share
  • Disk Usage
  • Logs Explorer
  • Portainer （必要な場合）

開発コンテナー dvc

VS Code の Dev Containers 拡張機能を使うと、開発コンテナーを使うことができるようになります。単純に VS Code をアタッチするという手軽な使い方から、devcontainer.json を用意して本格的に使うということもしています。

さらに、開発コンテナーを自分でビルドしてカスタムイメージも用意して使っています。Docker Hub に Docker イメージファイル、GitHub に Docker イメージビルド時に使用するファイルを公開しています。

現時点での最新版は次のとおりです。

イメージ名:タグ os node vnc mise go jdk php python ruby
dvc:base-202601 debian 13 24 - - - - - - -
dvc:novnc-202601 debian 13 24 1.2.0 - - - - - -
dvc:202601 debian 13 24 1.2.0 i - - - - -
dvc:go-202601 debian 13 24 1.2.0 i 1.24 - - - -
dvc:jdk-202601 debian 13 24 1.2.0 i - 21 - - -
dvc:php-202601 debian 13 24 1.2.0 i - - 8.2 - -
dvc:python-202601 debian 13 24 1.2.0 i - - - 3.12 -
dvc:ruby-202601 debian 13 24 1.2.0 i - - - - 3.4
dvc:gnr-202601 debian 13 24 1.2.0 i 1.24 - - - 3.4
dvc:gnpr-202601 debian 13 24 1.2.0 i 1.24 - - 3.12 3.4

表について、次に補足の説明事項を挙げておきます。

  • debian 13 のコードネームは trixie
  • vnc は tigervnc
  • mise は mise-en-place(jdx/mise) の略、i でインストール済みでバージョンは 2025.12.13
  • jdk は 17, 24 もインストール済み

いずれも https://github.com/devcontainers/images/tree/main/src/typescript-node で公開されている typescript-node 開発コンテナーをベースとしています。

使用している feature は下記です。ただし、desktop-lite は、dvc:base-202601 では使っていません。他では使っています。

最初、Node.js 環境と docker-outside-of-docker が使える開発コンテナー環境を自作していたのですが、mcr.microsoft.com/devcontainers/typescript-node をベースとして feature を組み合わせた Docker イメージを作れば手軽に環境構築ができるので、そちらの方法へ変えました。

Python、Go、Ruby などを使った Web アプリ開発もあるので、それに合わせてイメージを用意してあります。Web アプリの開発なので、Web ブラウザも使えるように desktop-lite の feature も組み合わせてあります。

バージョン管理 Git

Git 関連については VS Code から使うことが多いので、VS Code に次の拡張機能をインストールしています。

Git 向けのシステムについては、関連するソフトウェアも含めて、いろいろなものを動かしてみたことがあります。2024年のものですが、それらをアドベントカレンダーで紹介しています。この後に紹介するものについて、具体的に試してみたいものがあったら、次の記事が参考になるかもしれません。

GitLab

Git システムについては、専用の Linux KVM 仮想マシンを用意して、GitLab Community Edition を動かしています。

GitLab は、それなりに高いリソースを要求するので、手軽に Git リモートリポジトリを用意したいだけの場合には適していません。ある程度 Git について理解していて、十分な性能を持つマシンがあって、Git システムを構築したいと考えている人向けになります。高性能でビジネスユースにも対応できるため、本格的に自宅で開発環境を構築したい人は興味を持つはずです。

ちなみに Linux KVM（Kernel-based Virtual Machine）というのは、Linux カーネルに組み込まれているオープンソースの仮想化技術です。Linux をハイパーバイザーとして動作させ、複数の独立した仮想マシンを稼働させることができます。https://git.kernel.org/pub/scm/virt/kvm/kvm.git で開発されています。

軽量の Git システム

GitLab は専用サーバマシンが必要だという印象を持っているため、より軽量でノートパソコンでも使用可能な Git システムを 2024 年のときに検討したことがあります。次のどれかが良いと考えています。

それぞれのソフトウェアについて、稼働可能な環境は次のとおりです。

ソフトウェア名 稼働可能な環境
Gitea Ubuntu、WSL Ubuntu、Windows
Forgejo Ubuntu、WSL Ubuntu
GitBucket Java (Ubuntu、WSL Ubuntu、Windows)

Docker について詳しければ、どれを使うのも大差ありません。そうでない場合は、Gitea が良さそうに見えますが、Windows で常時稼働するにはハマることが多そうです。Linux をメインで使っている自分としては、Ubuntu や WSL Ubuntu で常時稼働させて使ってみるのが良いと考えています。なお、GitBucket は Java 環境が必要なので、Java プログラムの開発を良くしているなら選択肢に入るのですが、そうでない場合は Forgejo の方が導入しやすいでしょう。

ただし、最近の生成 AI の利用を考えると、手元の開発マシンではできるだけ開発用にリソースを確保しておいた方が良いと考えています。こういったシステムを稼働させると、その分、開発作業時に使えるリソースが減ってしまいます。

Git システム用に専用マシンをすぐに用意できない人の場合は、単純な Git リモートリポジトリで管理するというのが現実的になるのかもしれません。早く2台目を購入して、片方で Git システムを稼働できるようにすることを目指すのが良いです。

ここで、CI/CD 用のタスクランナーもリソースを多く消費する傾向があるので、Git システムの活用が増えていくと、これを切り離して用意したくなることが多いです。その場合は、次のものが良いと考えています。

CI/CD 用のタスクランナーについて、これらを使うメリットは、採用している Git システムに依存しない構成が可能となる点です。いろいろな Git システムと連携ができるので、プロジェクトによって使っている Git システムが違う場合でも、同じタスクランナーで対応することができます。

個人レベルだと、ここまですることはあまりないでしょうが、会社で Git システムを利用しているときに、これらを採用することはあるでしょう。そういった場合に、手元で動かして自分で評価する程度のことはできると良いと考えています。いずれも Docker があれば試用はできます。

hiro345g/gblan

2023 年に作成してから、ほとんどさわれていません。当時、大学になったばかりの知り合いのために、インフラ初心者でも簡単に使えるセルフホスト Git システムの環境を構築できるように、次のものを作成しました。

これは、Docker を使って「Git システムも含めた Web アプリ用の開発環境を 1 台のマシンで構築できる」というものです。

内部的には次のコンテナを同じ Docker ネットワーク環境で使えるようにしています。

DNS も含めてあることからわかるように、https://www.dev.internal/app といった FQDN の HTTPS 対応 Web アプリを実行する環境を Docker ネットワーク内に閉じて用意することができます。

すでに紹介した hiro345g/dvc と組み合わせることも簡単にでき、Web アプリの開発用の環境構築に使えます。なお、Web アプリ開発ができるエンジニアを目指すなら、ここで使われている Docker コンテナについて、一通り説明ができるくらいの知識が必要だと考えています。

ちなみに、これを使う専用マシンを1台用意しておけば、生成 AI を使った Web アプリの開発が捗りそうな気がしていますが、実際には試してみていません。生成 AI を使う場合は、実際の Web アプリが稼働する環境と近い環境を用意して、そこでスクラップビルドができると良いはずだと考えています。hiro345g/gblan は、そういった環境として役に立ちそうです。ただし、GitBucket は必要がない気もするので、生成 AI 用とするなら、もう少し軽量化したものを用意するのが良いと考えています。

プログラミング言語用ツールのバージョン管理

node、java、go といったプログラミング言語用ツールのようコマンドについて、Ubuntu/WSL Ubuntu を使う場合は、apt コマンドでインストールできるシステムのものを使えるようにしています。開発時は、システムが提供するバージョンとは違うものを使いたい場合があるので、プログラミング言語用ツールのバージョン管理ができるツールも併用しています。

プログラミング言語バージョン管理については、VS Code + Docker の開発コンテナーを使うことで解決することが多いのですが、ネイティブ環境でもプログラミング言語のバージョン切り替えが必要です。そういった用途に適した専用ツールはいくつかあります。筆者は2025年に mise-en-place（jdx/mise） を知ってから、java 系以外はこれを使うようにしています。

なお、java 系については SDKMAN! を使用しています。mise でも java、gradle、mvn などを管理できるのですが、主要でないコマンドはプラグイン経由で利用可能となっているため、メンテナンス状態に少し不安を感じています。SDKMAN! はメンテナンスがしっかりとされているのと、Windows でも一応利用可能なので、採用しています。

Windows で利用する方法について説明している資料をオンラインであまりみかけないので、次の記事で説明しています。

ところで、mise、SDKMAN! については、hiro345g/dvc でも採用しています。基本的に開発コンテナーには 1 つのプログラミング言語バージョンを入れるようにしているのですが、同じ開発コンテナーで他のプログラミング言語バージョンが必要となったときに、これらを使ってインストールできるようにしています。

Web アプリの開発では、複数のプログラミング言語を組み合わせて使うということはよくありますし、便利なツールを使うために python、ruby、go といったコマンドが必要となることもあるからです。

Node.js なら nvm、Python なら uv、Ruby なら rbenv などのように、プログラミング言語単位でいろいろありますが、これらを個別に使うと大変なので、mise コマンドを使って管理しています。以前は、anyenv や asdf-vm (asdf コマンド) を使っていました。

Bash のプロンプト

Bash のプロンプトについて、Docker や Git をよく使うようになってから、プロンプトに表示しておきたい項目が以前より増えました。そのため b-ryan/powerline-shell などを使っています。

Oh My Posh の利用、プロンプトのカスタマイズについては、下記の記事があるので、興味があるようでしたら参考にしてください。

現在、メインマシンでは、Powerline 系で Go で実装された https://github.com/justjanne/powerline-go を使っていますが、Windows や開発コンテナーでは Oh My Posh ベースのものを使っています。コンテナーでは必要に応じて Starship を使っています。

Starship は軽量で Nerd フォントがなくても、それなりの表示ができるテーマがあるので、VS Code をアタッチして開発コンテナーを軽く使う場合など、簡易的に使いたいときに便利です。これを使ったコンテナーの利用方法は下記で公開しています。

なお、Powerline 系のプロンプトとテーマについて、使用するマシンによって変えることで、勘違いによる操作ミスが発生しにくくなります。プロンプト用のソフトウェアとテーマを変えておきたいものは次のものになります。5 パターンぐらい用意しておくと良いはずです。

  • サーバーマシン
  • デスクトップマシン
  • ノートパソコン
  • 開発コンテナー
  • Docker コンテナー

フォント

Powerline 系のプロンプトを使う場合は Nerd 対応フォントが基本的に必要です。また、プログラミング時には I と l の区別がつきやすいフォントを使いたいところです。ということで、フォントについて気にしています。

Nerd 対応フォント

日本語に対応しているフォントでは HackGen、Cica など日本語フォントと英語フォントの両方をまとめてひとつのセットにして見やすくする調整をしたフォントがあります。そういったフォントについて、個人的に選択肢としているものを一覧にしてみました。

他にも、次の URL で公開されている Nerd 対応フォントを使うこともあります。

このサイトのダウンロードページを確認すると、次のフォントをベースとする Nerd 対応フォントもあります。

Noto は CJK のものが Ubuntu Desktop の日本語環境では標準でインストールされるので知っている人も多いでしょう。それと合わせておきたい時は、Nerd 対応フォントも Noto ベースのものにすると良いはずです。

Meslo のものは、Oh My Posh の公式サイトで紹介されているものなので、世界的には人気があるのでしょう。Nerd 対応のフォントは 3.3.0 のものなら Nerdfonts のダウンロードページ からダウンロードできます。

Nerd 対応フォントのインストールについては、Oh My Posh をインストールすると oh-my-posh font install コマンドが使えるようになるので、これを使うのが簡単です。このコマンドでインストールできないものもあるので、その場合は手動でインストールすることになります。

少し話がそれますが、Nerd 対応フォント関連では、次の関連記事も書いたので、よろしかったら参考にしてください。

プログラミング用フォント

フォントについては、優先度をつけて複数指定ができるようになっているアプリも多いので、デスクトップ環境だと複数インストールすることが多いはずです。プログラミング用途で使いやすいフォントとしては、次のものがあり、これらも組み合わせて環境を用意することを検討しても良いでしょう。

Linux でよく使うフォント

Linux では、IPA フォントなどがよく使われています。IPA フォントは、IPA (情報処理推進機構) が開発したオープンソースの日本語フォントで、高品質かつ無料で利用できます。よく聞くものを一覧にしておきます。

Docker を使っていて日本語フォントが必要となったときなどに、こういったフォントの名前を知っておくと役に立ちます。

ちなみに、Ubuntu のパッケージだと下記があります。東風フォント（kochi）やさざなみフォント（sazanami）は開発プロジェクトのページがメンテナンスされていないようなので、最近の Ubuntu だと使えないかもしれません。

  • fonts-noto-cjk
  • fonts-mplus
  • fonts-ipafont-gothic, fonts-ipafont-mincho
  • fonts-ipaexfont-gothic, fonts-ipaexfont-mincho
  • fonts-vlgothic
  • ttf-kochi-gothic, ttf-kochi-mincho
  • ttf-sazanami-gothic, ttf-sazanami-mincho

ターミナル

基本的に VS Code のターミナルを使っています。各 OS でもコマンドラインは実行するので、そのときに使っているターミナル関連のソフトウェアも紹介しておきます。とはいえ、基本は標準で提供されているターミナルアプリを使っています。

Ubuntu Desktop では標準のターミナル (GNOME Terminal) を使っています。次のアプリもインストールしています。

  • byobu
  • tmux
  • screen (必要な場合)

macOS も標準のターミナルを使っています。

  • ターミナルアプリ

Windows はターミナルといって良いのか難しいところがありますが、関係するソフトウェアとしては次のものを使っています。

  • Git Bash
  • MSYS2 (必要な場合)
  • ターミナル
  • PowerShell
  • WSL Ubuntu (bash)

次のターミナルアプリは話題になっているのを何度か見かけていて、興味はありますが、まだあまり使ってみていないです。

生成 AI をつかったバイブコーディングでは VS Code などを使わずにターミナルから直接 CLI ツールを使うのが良いという声も聞くので、今後こだわるかもしれません。

Linux GUI

Linux GUI については、主に Ubuntu Desktop 24.04 を使っています。日本語版 Remix はインストーラーが 22.04 までの対応なので、24.04 をインストールするときには使っていません。

Raspberry Pi では Ubuntu Server + MATE を使っています。以前は MATE 版イメージがダウンロードできたのですが、24.04 からは Ubuntu Server をインストールしてから MATE をインストールすることが推奨されています。Raspberry Pi は USB ブートにしたら microSD カード起動のときよりファイルクラッシュがしにくくなり、安定稼働するようになった気がします。

なお、Docker コンテナーで Linux GUI を使いたい場合は、linuxserver/docker-webtop があります。日本語入力が可能となる指定も簡単にできるので便利です。

ところで、docker-webtop がなくても開発コンテナーで Web ブラウザが使えるように、desktop-lite フィーチャーを使っています。これに採用されている Window マネージャーは fluxbox/fluxbox です。

これは今は開発が止まっていて、更新されていないので、どこかで別の Window マネージャーに置き換わるのだろうと考えています。

最近の Ubuntu Desktop が採用している Wayland 対応の Window マネージャーには次のものがあります。

さきほど紹介した docker-webtop も Wayland 対応は進めている模様です。docker-webtop は複数のデスクトップ環境やウィンドウマネージャをサポートしており、ユーザーは好みのものを選択できます。この中に Wayland 対応のものもあるので、使い勝手を調べたいときは、docker-webtop を使ってみると良いかもしれません。

  • XFCE
  • KDE
  • MATE
  • i3
  • Openbox
  • IceWM
  • KDE Plasma (KWin)
  • Sway
  • Hyprland
  • LabWC

ところで、n100 の Windows マシンを使っていて、そこで WSL Ubuntu を使えるようにしてあるのですが、2025年になって WSLg（microsoft/wslg）対応となり、GUI アプリも使えるようになりました。

ただし、使ってみた感想としては日本語対応をさせるのが大変そうなので、どうしても Windows で Linux 系の GUI アプリが使いたいなら docker-webtop コンテナー経由が良さそうだという印象を持ちました。

もしくは Hyper-V 仮想マシンか VirtualBox の仮想マシンを使うのが良さそうです。その場合は、仮想マシンを快適に動かせるマシンスペックが必要となるので、デスクトップマシン限定となります。

設計関連ツール

設計時によく使っているツール。

Markdown

ドキュメントは基本的に Markdown で記述するようにしています。図については Power Point 互換のプレゼンテーションツールで編集・参照できるものを使っていますが、mermaid なども採用しつつあります。

他には、Obsidian というソフトウェアを使うと Markdown ドキュメントの整理がしやすくなりそうで、良さそうなのですが、まだあまり使いこなせていません。

OpenAPI

REST ベースの API サーバーや、それを使うアプリについては、基本的に OpenAPI を使うのが楽だろうと考えています。OpenAPI については、OpenAPI Initiative をご覧ください。

OpenAPI の仕様を作成するにあたっては、サーバーサイドで生成するのが良いと考えています。これは、仕様からサーバー用コードを生成するというのが、あまり現実的ではないからです。これは、仕様変更時に特に感じることです。

仕様からサーバー用コードを生成する方式だと、生成したコードと既存のコードのマージ作業がそれなりに面倒なことになり、既存コードに影響する部分を手作業で対応する際の手間が多くなります。

インタフェースと実装を完全に分けて生成できるなら、仕様からサーバーのインタフェース用のコードだけを生成して、その変更により問題が起きた部分を直していくとすれば良いのですが、そういった対応ができるジェネレーターというのはみかけないので、なかなか難しいところがあります。

逆にサーバーのコードから、仕様を生成するようにしておくと、仕様変更時も、サーバーのコード上で変更してから仕様生成をすれば済みます。

一方、クライアント側については、仕様変更後に生成した OpenAPI の仕様からクライアント用のコードを生成して利用するということで良いと考えています。クライアント側は API を利用する側なので、利用するライブラリのアップデートに対応することはいずれ必要となります。この方式の場合、必要となる作業が増えるということもなく、ツールで自動生成できるメリットを享受することができます。

ということで、こういった作業をするのに適したツールがあるか探しながら使っています。

DB 用ツール

DB 用のドキュメントツールとしては、SchemaSpy が便利です。DB のテーブル情報から、ドキュメントを生成してくれます。

ここで、OpenAPI では、サーバーサイドのコードから仕様を生成するのが良いという話をしました。DB についても似たような話があります。

  • a）DB のテーブル情報から DB アクセス用コード生成
  • b）エンティティ用コードからテーブル作成・更新

サーバーサイドのアプリでは、ORM を使うことが多いのですが、大体の ORM は a も b も対応していることが多いです。

こちらも、変更時のコード変更を考えると b の方式が良さそうな気がするのですが、利用する DB に合わせてエンティティ用のコードを調整するというのはなかなか面倒だったりします。

RDB を使う際に、テーブルの正規化をする、テーブル間の関連について制約をつける、といった作業はエンティティ用コードを設計するときの話というよりは、データベース設計の話になります。

サーバーサイドのアプリでは、できるだけプログラムから扱いやすいデータ構造のエンティティとしておきたいのですが、使用するデータベースの機能や制限に合わせて、抽出や永続も考慮したデータ構造にする必要が出てきます。

そういったことを考えると、データベースを利用する場合は、DB のテーブル設計を決定してから、エンティティ用コードを作成するという流れになります。

サーバーサイドのアプリのコードを変更する場合も、DB に保存するデータの構造について変更が必要なのか検討するところから始めるはずです。

となると、a の「DB のテーブル情報から DB アクセス用コード生成」という方式の方が良さそうな印象です。この場合は、DB と DB 用コードの作成・更新は次のような手順となります。

  1. データ定義
  2. テーブル作成・変更
  3. テーブル情報から DB アクセス用コード生成・変更

ということで、こういった作業をするのに適したツールを、使用する DB やフレームワークで探しながら使っています。

プログラミング言語

構築した開発環境で使ってみているプログラミング言語やフレームワークなど。

TypeScript

Web ブラウザで表示する画面を作る場合は TypeScript でコードを書くのが良いと考えています。型がない開発はやはりきつい。

フロントエンド向けのフレームワークは次のものが有名で、チェックしています。

サーバーサイド向けのフレームワークは次のものをチェックしています。

OpenAPI の spec.json からクライアント用コードを生成するには次のツールがあります。

DB アクセスまわりは、次のものがあります。2025年は Drizzle ORM が話題になっていましたね。

Java

Java 関連では、Java Runtime、Java SDK といったものについての知識も必要なので以前記事にしたのですが、JDK の LTS が2025年10月に 25 となったので、それに合わせて最新の記事を公開しました。

また、Java については、Web アプリ開発時には Jakarta EE についての知識が必要なので、記事にしてあります。また、IDE についても記事にしてあります。これらは2024年版です。

VS Code での Java 開発環境については、2025年にきちんと調べて記事を公開しました。

VS Code での Java 開発については、まだ快適というところまではいってなくて、Java 専用の IDE の方が高機能で使いやすい印象があります。ただし、開発コンテナーについては VS Code からの利用がしやすいです。

開発コンテナー + Java 関連では次の記事を公開しています。

Java は、ビルドツールなしの環境で学習した後に、Gradle や Maven といったパッケージ管理、ビルドツールについての知識も必要で、最近だと Spring Boot についても理解が必要だというのが、ハードルを高くしている印象です。最近は、これらに追加で Docker についての知識も必要です。そのあたりについての知識をおさらいするのに適した記事を公開したつもりです。

Tomcat

Java で Web アプリを開発する時によく使われている Tomcat について、インストール方法を調べてみました。いろいろな方法があって、どれを選択すると良いのかはプロジェクト次第、個人の開発環境次第ではありますが、選択肢が多いです。また整理して記事にして公開できればと考えています。

運用環境や CI/CD だと次の選択肢があります。

  • 手動バイナリ展開による伝統的なインストール
  • Ubuntu の apt パッケージ管理による導入
  • Docker
  • Maven/Gradle + Codehaus Cargo
  • Apache Tomcat Embed（Spring Boot 組み込み Tomcat など）

開発環境でのインストールだと、これらに追加で下記の選択肢があります。

  • SDKMAN!
  • mise-en-place
  • Gradle + Gretty
  • VS Code + Red Hat Community Server Connector 拡張機能
  • Pleiades All in One Eclipse
  • Eclipse IDE for Enterprise Java Developer（WTP プラグイン）
  • IntelliJ IDEA Ultimate 版

デバッグ可能な開発環境を用意するにあたっては、アプリケーションサーバーを組み込んだ方が楽なので、今後もこの方針は変わらないのだろうと考えています。実際、Spring Boot アプリは組み込み Tomcat を使うプロジェクトを生成しますし、Apache Tomcat Embed のグループとして Maven Repository: org.apache.tomcat.embed があったりして、組み込み Tomcat を使うことが増えているようです。サンプルも、Heroku の古いものですが、heroku/devcenter-embedded-tomcat で公開されていたりします。

そうなると、開発環境へ個別に Tomcat をインストールする必要があるプロジェクトというのは少なくなっていくはずです。とはいえ、これまでの資産があるため、実際の開発現場では自分でインストールしないといけない場面というのはありそうです。そういったことから、インストール方法について、どんな選択肢があるのかについては、知っておきたいところです。

Python

シェルスクリプトだと対応しにくいツールを用意するときは Python が便利だと考えていて、たまに使っています。

最近は uv が pip よりも人気があるようです。ライブラリの管理については、pip についての知識があることが前提となる場面が多いのですが、実用面では uv も知っておく必要がありそうです。

きちんとした解説はありませんが、mise + uv 環境のサンプルについて、次の記事で紹介しています。

Web アプリ用のフレームワークについては、API の開発なら FastAPI、手軽な Web GUI アプリなら Flask、高機能な Web GUI アプリなら Django を採用という方針でいます（2024年と変わりません）。

FastAPI は OpenAPI の spec.json 生成にも対応しているので使いやすいです。

DB アクセスまわりは、次のものになります。2024年のものと比較して SQLModel が増えています。FastAPI を使うなら選択肢として覚えておくのが良いものです。

Python だと、次のフレームワークもチェックしています。

Streamlit は Python で Web UI を持つアプリを手軽に作れることから人気があります。

Flet は Flutter ベースの Android/iOS アプリが開発できます。動的な Web サイト用 アプリを開発することもできます。ただし、動的な Web サイト用 アプリを開発する場合は内部的に FastAPI を使った実装になるため、Android アプリ や iOS アプリとしてのパッケージ化はできません。

Go

開発用ツールを手軽に用意するには Go を使うのが良い、REST API で高性能な Web サービスを作成するには Go を使うのが良い、という話があって、そういった意見に賛成しています。Docker Engine も Go で実装されていて、実績は十分にあります。

マルチプラットフォーム対応の実行ファイルが手軽に用意できるのも魅力です。たとえば、ラズパイ用のツールを Intel/AMD マシンで開発してクロスコンパイルするのが、本当に手軽にできて、ありがたいことです。

勢いで下記のツールを作ったりしました。Pi 5 に対応していないので、そのうちアップデートしなければ...

Go については、サーバーサイド、OpenAPI 対応、DB アクセスについて、次のものがあります。

開発コンテナーについての解説記事も公開しています。よろしかったらご覧ください。

PHP

PHP は他のプログラミング言語での Web フレームワークが普及してきたことから、筆者は以前ほど「手軽に Web アプリを開発するのに便利」だと感じなくなってきています。言語仕様も PHP7, PHP8 で強化された分、覚えないといけないことが増えたのも影響しています。

パッケージ管理は composer がない頃に比べると、しやすくなりました。

Web フレームワークについて、こちらも個人で開発するときは軽量なものがいいと考えてチェックしていて、Slim や CakePHP が良さそうだと考えています。

高機能・高性能の要求がされる場合は Java や Go を使うことにしてしまうので、筆者が Laravel を採用することはあまりなさそうです。PHP エンジニアが多いプロジェクトや PHP が得意な人だと Laravel を使うことになるのだろうという印象です。

CMS は WordPress が使えれば良いという考えです。プラグインを使えばサイトジェネレータとしても活用できるので、動的サイトだけでなく、静的サイト用にも使えます。

ただし、記事更新のために WordPress を起動しないといけないというのは負担となるので、Markdown などで記述できるサイトジェネレーターへ移行したいという気持ちもあります。

PHP についても開発コンテナについて解説をしています。自分では WordPress 関連の開発作業をするときに PHP を使うことが多いので、まとめて環境を用意して説明しています。

Rails

Ruby で Web アプリといったら Rails なので、チュートリアルの最初の方を動かせる開発コンテナを用意して、さわってみています。

GitLab や Redmine は Rails を採用していて、世の中では Rails を使ったサービスも数多くあります。そういったことから、Rails についてもさらに理解を深めたほうが良いのだろうという印象を持っています。

スタティックサイトジェネレーターと CSS フレームワーク

ランディングページやポートフォリオページを作る場合は、スタティックサイトジェネレーターと CSS フレームワークを何にするかが重要になってきます。

スタティックサイトジェネレーターとしては、Jamstack のページが参考になります。Hugo や Jekyll を検討してみたことがありますが、具体的にページを作ったことはありません。2025年に Hugo を使ってみようと思っていたのですが、結局、まだ使ってみていません。

綺麗なポートフォリオページは作成しておきたいと考えているのですが、なかなか実行できないでいます。

CSS フレームワークは次のものをチェックしてます。

Bootstrap ベースのテーマとしては日本語フォント対応しているものがきれいなのだろうと思って調べてみたことがあります。

CSS 関連では、管理画面用のダッシュボードなどを手軽に開発できるようになりたいという視点からも調べています。次のものが良さそうだと思ったのですが、NestJS との組み合わせが手軽にできそうになかったので、あまり詳しく調べていません。

UI コンポーネントということでは次のものも気になっています。

2024年までは、このあたりについてよく調べていたのですが、2025年になってからは、生成 AI が使えるようになったので、あまり調べなくなっています。UI については、使用する CSS フレームワークを指定して、生成 AI にコードを生成してもらえば済むような気がしていて、選択肢の調査についての優先度が下がった印象です。

Ubuntu 環境で使うアプリ

Ubuntu 環境でインストールしてあるものを列挙しておきます。linuxbrew、snap、apt で管理しています。

linuxbrew は Homebrew on Linux — Homebrew Documentation にあるとおりにインストールしています。snap と apt は Ubuntu Desktop であれば標準でインストールされています。

apt-get install -y curl git gpg openssh-server sudo unzip wget zip
apt-get install -y byobu sysstat autossh
brew install lazydocker \
brew install lazygit \
brew install hadolint \
brew install xz \
brew install jandedobbeleer/oh-my-posh/oh-my-posh \
brew install dagger/tap/dagger \
brew install ctop \
brew install oha \
brew install scorecard
snap install htop
snap install trivy

必要に応じて次のものもインストールしています。

snap install chromium
snap install flutter --classic
snap install netbeans --classic

mise で管理しているものについては、~/.config/mise/config.toml に記載しています。具体的には次のツールを使っています。

[tools]
fzf = "latest"
ghq = "latest"
go = "1.25.3"
php = "8.4.1"
zellij = "latest"
node = "20.19.5"
neovim = "0.11.5"
ripgrep = "15.1.0"
uv = "0.9.5"
ruby = "3.4.7"
shfmt = "3.12.0"
shellcheck = "0.11.0"
jq = "1.8.1"

[settings]
idiomatic_version_file_enable_tools = ["java"]
experimental = true
auto_install = false
exec_auto_install = false

おわりに

後半、開発環境構築から話がずれている感じもありますが、構築した開発環境がターゲットとしているプログラミング言語やフレームワークの説明にはなったのではないかと思います。

プログラミング言語については2024年のときと変わらず、下記も使えるようになりたいという気持ちは持っていますが、なかなかきちんと使うというところまでにはいかないです。

2025 年は開発コンテナーを実際に使って Go、Java といったプログラミング言語で実装したアプリの開発をしてきました。生成 AI のブームが到来したので、それを使って開発を効率よくする方法についても調査してきました。2026年は、生成 AI を使った開発に適した開発環境の構築について研究したり、構築した環境を活用して実際の開発をしていきたいと考えています。

最後に宣伝です。環境構築にあたってはバックアップが大事です。バックアップ時に使用する GParted について書籍を出してますので、よろしかったら購入をお願いします。

2026年最初の記事もバックアップについての記事でした。よろしかったらご覧ください。

Discussion