〜ノートPCとデスクトップの同期でハマった全記録〜
あけましておめでとうございます！KeSです。
私事ですが、1/5から新しい会社で働いておりまして、更新がだいぶ途絶えてしまいました💦
今後は週末に1本ブログを上げて、成長記録のように皆さんに情報を提供できればと思ってます。
さて、年が明けて皆さんは何か目標などは決めましたか？？
「今年は100万円貯金する！」とか「毎日ジョギングする！」とか「年内に資格合格！」とか。。
僕の今年の目標は「年内に個人事業主として利益を上げる」です。（盛大な拍手）
もちろんすぐに独立して企業する話ではないので、今の会社をメインで活動しながらになりますが、「スキルを身に着け事業者登録をして売り上げを上げる」までを今年中にやろうと思います。
独立しても、業務委託として今の会社が受注してくれる環境を作ってもらえれば業務に支障はないんですけどね笑（会社側も社会保険払わなくて済むし。。）
そして、その過程でノートPCとデスクトップどちらも同じ環境でAI開発をしたいなと思ったので
今回は「Docker」と「Github」を使用して最強の開発基盤を作っていこうと思います。
※アプリの環境構築のコーディングにAIを使用しているので、よりよいコードは今後も探求し随時編集していく予定です。
なぜ「環境の固定」が必要なのか
AI開発におけるライブラリ依存関係の複雑さ
AI開発では、TensorFlowやPyTorch、NumPyなど、多数のライブラリを組み合わせて使用します。これらのライブラリは相互に依存関係を持っており、バージョンの組み合わせによっては動作しないケースも珍しくありません。
さらに厄介なのが、Pythonのバージョンやオペレーティングシステムの違いによる挙動の差異です。「手元では動くのに、別の環境では動かない」という状況は、開発効率を著しく低下させます。
2台のPC（ノート・デスクトップ）で開発をスムーズに切り替える重要性
僕の開発スタイルは、外出先ではノートPC、自宅ではデスクトップという使い分けです。この切り替えをスムーズに行うためには、両方のPCで全く同じ環境が再現できることが必須条件になります。
従来は仮想環境（venv）を使っていましたが、Pythonのバージョン管理やシステム依存の問題が残りました。そこでDockerを採用することで、OS依存を完全に排除し、どこでも同じ環境を実現することにしました。
構築したDocker × Python環境の全コード
実際に構築した環境のコードを全て公開します。このコードをそのまま使えば、同じ環境が再現できるようになっています。
Dockerfile：Python 3.12-slimを採用した軽量設計
dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "main.py"]ポイントはpython:3.12-slimを採用したことです。slimイメージは通常版と比べて容量が小さく、ビルド時間の短縮につながります。AI開発では頻繁にイメージを再ビルドすることがあるため、この軽量性は大きなメリットです。
docker-compose.yml：ボリュームマウントでローカル開発を快適に
yaml
version: '3.8'
services:
ai-dev:
build: .
volumes:
- .:/app
environment:
- PYTHONUNBUFFERED=1
stdin_open: true
tty: trueボリュームマウント（.:/app）により、ローカルのコード変更が即座にコンテナ内に反映されます。これにより、コードを修正するたびにイメージを再ビルドする必要がなくなり、開発サイクルが大幅に高速化されます。
PYTHONUNBUFFERED=1は、Pythonの出力をバッファリングせず即座に表示するための設定です。ログをリアルタイムで確認できるため、デバッグ作業が格段にやりやすくなります。
GitHub経由で環境を同期するステップ
Dockerで環境を固定できたら、次はGitHub経由で2台のPC間で同期します。手順は以下の通りです。
ローカルでのCommitからGitHubへのPush
まず、ノートPC側で環境をGitHubにアップロードします。
bash
git init
git add .
git commit -m "Initial commit: Docker環境構築完了"
git branch -M main
git remote add origin https://github.com/your-username/your-repo.git
git push -u origin mainこの時点で、Dockerfile、docker-compose.yml、requirements.txt、そして開発コードの全てがGitHubに保存されます。
2台目のPCでのCloneと環境再現
デスクトップ側では、以下のコマンドでリポジトリをクローンします。
bash
git clone https://github.com/your-username/your-repo.git<br>cd your-repo<br>docker-compose up --build
たったこれだけで、ノートPCと全く同じ環境がデスクトップ上に再現されます。ライブラリのインストールも、Pythonのバージョン設定も、全てDockerが自動で処理してくれるのです。
【トラブル解決】同期中に遭遇した3つの壁
理論上はスムーズなはずの環境同期ですが、実際には複数のトラブルに見舞われました。ここでは、私が実際に遭遇した3つの壁とその解決策を紹介します。
壁①：Git署名エラー（`user.name`の設定）
デスクトップでコミットしようとした際、以下のエラーが発生しました。
Author identity unknown
*** Please tell me who you are.これは、Gitに自分の情報を登録していなかったことが原因でした。解決策は以下のコマンドを実行するだけです。
bash
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"新しいPCでGitを使う際は、必ずこの設定が必要です。忘れがちなので、環境構築チェックリストに加えることをお勧めします。
壁②：スペルミスによる command not found
恥ずかしながら、最も時間を費やしたのがこのエラーです。
bash
docker-compse upお気づきでしょうか。docker-composeではなくdocker-compseと入力していました。こういった単純なタイポは、疲れているときほど見つけにくいものです。
対策として、私はよく使うコマンドをシェルのエイリアスに登録するようにしました。
bash
alias dcu="docker-compose up"
alias dcb="docker-compose up --build"
これにより、タイポのリスクを減らしつつ、入力の手間も省けるようになりました。
壁③：Docker Desktop未起動による接続拒否
Cannot connect to the Docker daemon. Is the docker daemon running?このエラーが出たとき、私は設定ファイルやネットワーク設定を疑いました。しかし原因は極めてシンプル。Docker Desktopを起動していなかっただけでした。
Windows環境では、Docker DesktopはOSの起動時に自動起動しない設定になっている場合があります。設定から「Start Docker Desktop when you log in」にチェックを入れることで、この問題を回避できます。
今日のナレッジ：環境構築は「自動化」と「言語化」がセット
この一連の作業を通じて得た教訓を、3つのポイントにまとめます。
1. 環境をレシピ（Docker）にする
「自分のPCでしか動かない」は、プロの世界ではリスクでしかありません。Dockerfileを作成することは、未来の自分やチームへの「招待状」を用意することに等しいのです。半年後、環境を再構築する必要が出たとき、このレシピがあれば10分で環境が復元できます。
2. エラーが出た時こそ、一歩引いて観察する
command not foundや接続エラーの多くは、高度な理論ではなく、タイポや「電源（エンジン）の入れ忘れ」といった初歩的なミスに潜んでいます。焦って難しい原因を探る前に、まずは基本に立ち返ることが重要です。
3. 「成功の理由」を特定する癖をつける
対策を複数同時に行って解決した場合、あえて一つずつ戻して「真の原因」を探りましょう。そのひと手間が、エンジニアとしてのデバッグ力を劇的に高めます。私も今回、Docker Desktopの起動とネットワーク設定を同時に見直したため、どちらが本当の原因だったのか確信が持てませんでした。次回は、一つずつ検証する習慣を身につけたいと思います。
おわりに：次なるステップは「RAGの実装」へ
今回、Dockerによる環境固定とGitHubによる同期の仕組みを構築したことで、2台のPC間での開発切り替えが劇的にスムーズになりました。もうライブラリのバージョン違いに悩まされることはありません。
この土台が整ったことで、次のステップに進む準備が整いました。それは「RAG（Retrieval-Augmented Generation）の実装」です。大規模言語モデルに外部知識を組み合わせる技術として注目されているRAGに、いよいよ挑戦します。
環境構築で得た「自動化」と「言語化」のマインドセットは、RAG実装でも必ず活きてくるはずです。次回の記事では、RAG実装の過程と、そこで得られた新たなナレッジを共有していきます。
最後まで読んでいただき、ありがとうございました。同じように環境構築で悩んでいる方の参考になれば幸いです。
コメント