【番外編】開発環境の全体像 ― 自宅サーバー・VS Code・GitHub の構成

はじめに

この番外編では、シリーズで使っている開発環境の全体像を紹介します。自宅のサーバー、手元の PC の VS Code、GitHub が、それぞれ何を受け持ち、どうつながっているかを1枚の図で示します。

これまでの記事は、【入門編 第2回】からいきなりツールの開発に入っていました。そのため、「そもそもどんな環境で作っているの？」という部分の説明が抜けていました。組み込みでいえば、ファームの作り方は書いたのに、評価ボードと開発環境（コンパイラ、デバッガ、書き込み器）の構成を説明していなかった状態です。

なお、この記事は構成の紹介で、ゼロからのインストール手順ではありません。今のサーバーは以前から使っているもので、当時の手順が残っていないためです。VS Code の接続と GitHub への push の手順は、【番外編】VS Code の Remote-SSH で、自宅サーバーを直接開発するで詳しく紹介しています。

このシリーズに登場するドメイン名、URL のパス、ユーザー名、ポート番号などは、セキュリティのため実際とは異なる架空のものに置き換えています。

全体像：3つの場所に分かれている

開発環境は、手元の PC、自宅サーバー、インターネット上のサービス（Cloudflare と GitHub）の3か所に分かれています。

ポイントは、ソースもビルドも実行も、すべてサーバーの上にあることです。手元の PC は、サーバーを操作するための「窓」にすぎません。組み込みでいえば、ターゲットボードに直接ログインして、その上でコンパイルして動かしているような形です。

自宅サーバー：仮想マシンの上の Linux

サーバーは、自宅のマシンの上で動く仮想マシンです。仮想マシンとは、1台の物理マシンの中に、ソフトウェアで作った「別のコンピューター」を動かす仕組みです。組み込みでいえば、実機の代わりにシミュレーター上でボードを動かしているイメージに近いです。

Web のツールを動かすには、これで十分な大きさです。

入っているソフトと役割

サーバーには、役割の違うソフトが層になって入っています。

Node.js を nvm で入れた理由

OS に最初から入っている Node.js は、バージョン 20 でした。このバージョンは 2026年4月でサポートが終わっています。かといって OS の Node.js を入れ替えると、ほかの用途に影響が出るかもしれません。

そこで、開発用のユーザー（devuser）にだけ、nvm で新しいバージョン 24 を入れました。OS 全体は触らずに、自分の作業の中だけ新しい道具を使う形です。組み込みでいえば、共用のビルドサーバーの標準コンパイラはそのままにして、自分のプロジェクトだけ新しいツールチェーンを指定するのと同じです。

PM2 も同じ理由で、devuser の Node.js 24 の側に入れています。

確認してみる

サーバーに入って、それぞれのバージョンを表示すると、何が入っているかを確かめられます。

$ grep PRETTY_NAME /etc/os-release
$ httpd -v
$ node -v
$ pm2 -v
$ git --version

$ grep PRETTY_NAME /etc/os-release
$ httpd -v
$ node -v
$ pm2 -v
$ git --version

行頭の $ は、一般ユーザーで実行するコマンドであることを示す記号（プロンプト）です。実際に入力するのは $ の後ろからです。

結果は次のようになります（細かいバージョン番号は x に置き換えています）。

PRETTY_NAME="AlmaLinux 9.x"
Server version: Apache/2.4.x (AlmaLinux)
v24.x.x
7.x.x
git version 2.x.x

PRETTY_NAME="AlmaLinux 9.x"
Server version: Apache/2.4.x (AlmaLinux)
v24.x.x
7.x.x
git version 2.x.x

node -v が v24 で始まっていれば、nvm で入れた Node.js が使われています。もし v20 が出たら、OS の Node.js が使われているので、nvm use 24 で切り替えます。

外への出し方：ポートを開けずに Cloudflare Tunnel

自宅のサーバーをインターネットから使えるようにするとき、よくある方法は、自宅のルーターで「ポートを開ける」ことです。外からの接続を、ルーターがサーバーへ通すように設定します。ただし、こうすると誰でもサーバーに直接つなぎに来られるようになり、自宅の IP アドレスも知られてしまいます。

このシリーズでは、Cloudflare Tunnel を使っています。サーバーの中で動く小さなプログラム（cloudflared）が、サーバーの側から Cloudflare に接続しに行き、その接続を通して要求を受け取る仕組みです。

組み込みでいえば、機器の側で受信ポートを開けて待ち受けるのではなく、機器の側からサーバーに接続しに行き、その接続の上でコマンドを受け取る形です。外から開いている入口がないので、守る場所が減ります。

Cloudflare は、ほかにも次のことを引き受けてくれます。

• HTTPS：
  ブラウザとの間の暗号化と証明書の管理
• WAF（Web Application Firewall）：管理画面などへの怪しいアクセスを、サーバーに届く前に止める

ツールには認証をかけている

作ったツールは、誰でも使える一般公開ではありません。https://example.com/apps/<ツール名>/ の下に置き、Apache の Basic 認証（ユーザー名とパスワードの入力画面）をかけて、決まった人だけが使えるようにしています。設定の詳しい内容は、【入門編 第2回】で紹介しています。

Apache は中継するだけ（2026年11月4日に追記）

ツールのファイルは、Apache の公開のフォルダ（/var/www/…）には置いていません。ツールは、それぞれのフォルダの中で、自分の小さな Web サーバー（Node.js）として動いていて、Apache は、届いた要求をそのツールに渡す（中継する）だけです。

中継の設定は、ツールごとに数行です（値は架空のものです）。

ProxyPass        "/apps/unitconv" "http://127.0.0.1:5002/apps/unitconv"
ProxyPassReverse "/apps/unitconv" "http://127.0.0.1:5002/apps/unitconv"

• ProxyPass：
  /apps/unitconv に来た要求を、サーバーの中の 5002 番のツールに、パスを書き換えずに渡す
• ProxyPassReverse：
  ツールが返す「場所が変わった」の案内（/ のないときの 301 など）を、外から見た URL に直して返す

この形にしているのは、次の理由です。

組み込みでいえば、Apache は受付の窓口で、来た要求を、決まった番号の担当（ツール）に回すだけです。担当の机の中（ツールのフォルダ）を、窓口が直接見せることはありません。

手元の PC：VS Code はサーバーを操作する窓

手元の PC（Windows）に入れているのは、主に次の3つです。

VS Code の画面は手元に出ていますが、開いているファイルも、ターミナルで動くコマンドも、すべてサーバーの上のものです。そのため、PC に Node.js や Git を入れる必要はありません。

SSH 鍵でログインする

SSH 鍵は、「秘密鍵」と「公開鍵」の組です。秘密鍵は手元の PC だけに置き、公開鍵をサーバーに登録しておくと、パスワードを打たずにログインできます。組み込みでいえば、機器に公開鍵を書き込んでおき、署名の検証が通ったときだけ接続を受け付ける、セキュアブートに近い考え方です。

PC の設定ファイル（.ssh/config）にサーバーを myserver という名前で登録しておくと、PowerShell からも、VS Code からも、この名前で接続できます。

$ ssh myserver

$ ssh myserver

手元の PC の PowerShell で実行します。パスワードを聞かれずに、サーバーのプロンプトが出れば、鍵でのログインができています。

ポート転送で開発中の画面を見る

開発中の画面（Vite の開発サーバー）は、サーバーの中だけで待ち受けていて、外からは見えません。VS Code のポート転送を使うと、SSH の接続の中を通して、手元のブラウザで http://localhost:5173/ のように開けます。外に入口を開けずに済むので安全です。

VS Code の接続、ポート転送、GitHub のサインインの手順は、【番外編】VS Code の Remote-SSH で、自宅サーバーを直接開発するで詳しく紹介しています。

GitHub：ソースの控えを置く金庫

ソースはサーバーの上で Git で管理し、区切りごとに GitHub へ送って（push して）控えを残しています。サーバーが壊れても、ソースは GitHub から取り戻せます。

タグは、組み込みでいえば出荷したファームのバージョン番号を、ソースの履歴に打っておくのと同じです。

認証の仕組みと、SSH 鍵での接続がうまくいかなかった話は、【番外編】VS Code の Remote-SSH で、自宅サーバーを直接開発するに、Git のつまずきは、【番外編】組み込みエンジニアが Git でつまずいた6つのことにまとめています。

1つのツールができるまでの流れ

ここまでの部品が、1つのツールを作るときにどう使われるかを、順に並べます。

1. 書く：
   手元の VS Code から Remote-SSH でサーバーに入り、/home/devuser/apps/<ツール名>/ にソースとドキュメントを書く
2. 画面を確かめる：
   サーバーで Vite の開発サーバーを動かし、ポート転送で手元のブラウザから見る
3. ビルドする：
   サーバー上で npm run build。TypeScript が JavaScript に変換される
4. 常駐させる：
   PM2 にツールを登録する。ツールはサーバーの中だけで、ツール専用のポート（例：5001）で待ち受ける
5. 中継する：
   Apache に、/apps/<ツール名>/ への要求をそのポートへ渡す設定を1つ追加する
6. 外から確かめる：
   ブラウザで https://example.com/apps/<ツール名>/ を開く。Cloudflare、Tunnel、Apache、Node.js の順に届き、認証の画面のあとにツールが表示される
7. 控えを残す：
   Git でコミットし、タグを付けて GitHub に push する

手順の 1〜3 は 入門編 第4回、4〜6 は 入門編 第7回、7 は 番外編 Git で、実際の手順と結果を紹介しています。

この記事に書いていないこと

自宅のサーバーを外から使えるようにしている以上、構成の細かい部分は攻撃の手がかりになります。そのため、次のことは記事に載せていません。

• 実際のドメイン名、URL のパス、ユーザー名、ポート番号（架空のものに置き換えています）
• WAF のルールの具体的な条件
• 自宅のネットワークの IP アドレスや、Cloudflare Tunnel の設定の詳細
• 認証に使うユーザー名や設定ファイルの名前

組み込みでいえば、製品の解説記事は書いても、デバッグポートの場所や保守用のパスワードは載せない、という感覚です。同じような環境を作るときも、こうした値は自分の環境に合わせて決めてください。

まとめ

• 開発環境は、手元の PC、自宅サーバー、インターネット上のサービス（Cloudflare、GitHub）の3か所に分かれている
• ソース、ビルド、実行はすべてサーバーの上。手元の VS Code は、Remote-SSH でサーバーを操作する窓
• 外からの要求は、ポートを開けずに Cloudflare Tunnel で受け、Apache が各ツールに振り分ける
• ソースの控えは GitHub の非公開リポジトリに置き、認証は VS Code のサインインに任せる

この記事は、シリーズ「組み込みエンジニアの Web 開発入門」の1本です。ほかの回は、シリーズの目次からどうぞ。