
仕事で使うPC環境:コーディング編
はじめに
今回はコーディング編です。研究グループでは機械学習による新物質探索を行っています。以下のような場面でコーディングすることがあります。主にPythonを使用します。
ロボットの動作制御
センサーを使った実験環境の記録、警報
データの自動整理
データの自動解析
推薦システム構築
外部データベースからのデータ抽出
私の研究グループでは実験がメインの作業ですが、これに付随する作業も含めて標準化し、スクリプトで制御することでミスを減らし、作業者の負担を減らすことができます。また、収集したデータから意味のあるケミカルトレンドを抽出したり、新物質の合成条件を予測したりする機械学習モデルの作成も行います。
これまで授業くらいでしかプログラムを書いたことがなくても大丈夫です。みんなそんなもんです。そして、そこまで難しいこともしません。また、ChatGPTなどの生成AIがコーディングを助けてくれます。私もよく使っていますし、学生さんも道具としてうまく使える、付き合えるようになるとよいと思います。
ここでは標準的な開発環境に焦点を当て、コーディングに慣れていない学生向けにツールの使い方とコーディングの考え方に関して紹介する予定です。最近注目されているAIエージェントによるコーディング環境(CursorやCline、Claude Codeなど)については、標準的なコーディングを体験してからのほうが良いかなと思いますので、別記事でまとめます。
この環境でできること
今回紹介する環境でできることは以下のような作業です:
Pythonコードの作成と編集
コードの実行・動作確認
仮想環境によるライブラリの管理
コードのバージョン管理(Git)
チームでのコード共有(GitHub)
複雑な設定や難しいことはしません。まずは「コードを書いて動かす」「コードを整理して残す」というところから始めていきましょう。
以下の説明はWSL2での動作を前提にしています。WSL2とPythonの設定は以下の記事を参考にしてください。フォルダとディレクトリという言葉が混ざっているかもしれませんが、同じだと思ってください。
コーディング環境の基本:まず整えるべきこと
本格的にPythonでコードを書き始めるにあたって、まずは環境づくりがとても大切です。
ここでは、初心者の方でも無理なく始められるように、次の3ステップで説明していきます。
① プロジェクトごとにフォルダを分けて管理する
Pythonでいろいろなことを試すうちに、ファイルがごちゃごちゃになったり、他のコードと干渉して動かなくなったりすることがあります。
そこでまずやってほしいのが、1つのプロジェクトにつき1つのフォルダを作ることです。
たとえば、以下のようにフォルダを作ります:
mkdir my_project # mkdirはフォルダを作るシェルコマンド
cd my_project # cdはフォルダを移動するためのシェルコマンドこの中にすべてのコード・データ・設定ファイルをまとめておくことで、他のプロジェクトと混ざらず、管理が楽になります。
💡「1フォルダ1プロジェクト」の習慣は、のちにGit管理や仮想環境を扱う上でもとても重要になります。
② 仮想環境を作る(venv)
Pythonでは、プロジェクトごとに使うライブラリを分けることが大事です。
他のプロジェクトで使っていたライブラリとバージョンが違っていて動かない、ということがよくあります。
そこで使うのが venv(仮想環境)です。
python -m venv venv # venvという仮想環境を作ります
source venv/bin/activate # 仮想環境を有効にします二つ目のvenvが仮想環境の名前です。その中にこのプロジェクト専用の様々な設定が蓄積されていきます。
名前はなんでもいいです。
仮想環境を有効にすると、その中だけでライブラリをインストール・実行できます。
作業を終えるときは `deactivate`で解除します。
忘れても事故になりにくいようにプロジェクトごとにターミナルを分けておくとよいです。
インストールしたライブラリは以下のように記録しておくと便利です:
pip install numpy pandas # numpyとpandasというライブラリを入れる
pip freeze > requirements.txt # どのバージョンのライブラリかを記録するrequirements.txtがあれば、別環境でも`pip install -r requirements.txt`で同じライブラリを入れることができます。
③ Gitでコードの履歴を管理する
Pythonでコードを書いていると、「昨日は動いていたのに、何かを変えたら動かなくなった」「前のバージョンに戻したいけれど、どこが違うのかわからない」といった経験をすることがあります。
こうしたときに役立つのが、Git(ギット)というバージョン管理ツールです。
Gitとは何か?
Gitは、「コードの変更履歴を記録し、必要に応じて過去の状態に戻すことができるツール」です。
Googleドキュメントの「変更履歴」のようなイメージですが、プログラムのように細かな構造を持つファイルを効率よく扱えるように設計されています。
Gitを使うと、以下のようなことができます:
コードの変更履歴を段階的に記録する
ある時点の状態にいつでも戻すことができる
「どこをどう変えたか」を視覚的に確認できる
他の人と安全にコードを共有できる(GitHubと連携)
Gitの基本的な使い方
Gitを使い始めるには、まずプロジェクトフォルダで次のように入力します:
git initこれで「このフォルダはGitで管理しますよ」という状態になります。
その後は、以下のような流れでコードの変更を記録していきます:
1.変更したファイルを「次に記録する候補」として追加する
git add ファイル名すべての変更を追加する場合は `git add .` でOKです。
2.実際に記録を残す(これを「コミット」といいます)
git commit -m "ここに説明を書く"たとえば「データ整理の関数を追加」など、自分が後から見て分かるような説明を残しておきます。日本語でもOKです。
3.状態を確認する
git statusこれで「何が変更されたか」「何が記録されていないか」が一覧できます。
.gitignore ファイルについて
Gitでは、記録したくないファイルやフォルダを指定しておくことができます。そのために使うのが .gitignore という特別なファイルです。
たとえば、次のような内容を .gitignore に書いておくとよいでしょう:
venv/
__pycache__/
*.log
これにより、仮想環境や一時ファイルなど、Gitの履歴に含める必要のないものを除外できます。
GitとGitHubの関係
Gitは、皆さんのパソコンの中で動作するローカルのツールです。一方、GitHubは、そのGitの履歴をインターネット上で保存・共有できるクラウドのサービスです。
Gitで記録したコードをGitHubにアップロードすれば、次のようなことが可能になります:
他の人にコードを見てもらったり、レビューを依頼できる
自分の作業のバックアップとして使える
チームで同じコードを同時に編集できる
GitHubと連携するためには、まずGitHub上でリポジトリ(保存場所)を作り、ローカルのGitと接続して、次のようにアップロード(「push」)します。
git remote add origin https://github.com/ユーザー名/リポジトリ名.git # ローカルのgitとGithub上のリポジトリを接続
git push -u origin main # ローカルのgitの内容をGithub上のリポジトリにアップロードよくある誤解と補足
❌ 「Gitって、自動で保存してくれるんですよね?」
これはよくある誤解のひとつですが、Gitは自動で変更を記録してくれるわけではありません。
たとえばGoogleドキュメントのように、書いたそばから自動保存されるようなツールもありますが、Gitは違います。
Gitでは、自分で「記録する」と明示的に操作する必要があります。
具体的には、次のような操作を通じて初めて「履歴」が残ります。
git add main.py # 変更したファイルを「記録対象」に追加
git commit -m "関数の引数を追加" # 実際に記録するこの操作をしなければ、どんなにファイルを編集しても、Gitには何も残りません。
つまり、Gitは「自動保存」ではなく「自分で書く実験ノート」のようなものだと考えてください。
❌ 「1人で作業するだけなら、Gitはいらないのでは?」
これもよく聞かれる疑問ですが、むしろ1人で作業しているときこそ、誰も前のバージョンを残してくれていないので、Gitは役に立ちます。
うっかりファイルを壊してしまっても、前の状態に戻れる
コーディングの「節目」で記録しておくと、後から比較・振り返りしやすい
ChatGPTや他の人に相談したいとき、「この状態を見て」と共有しやすい
つまり、Gitは安全に失敗できる環境を提供してくれるツールでもあります。
❌ 「フォルダをコピーしておけば、それで十分では?」
確かに、ファイルやフォルダを手動でコピーして「保存版」として残すこともできます。
でもそれでは、
どこをどう変更したかが見えない
変更内容を比較できない
名前が「final」「final2」「new_final2」みたいになっていく…
という状態に陥りやすいです。
Gitを使えば、変更の記録が自動で整理され、どのタイミングで何を変えたかがひと目でわかるようになります。
✔️ だからこそ、Gitは「自分のための実験ノート」
Gitはチーム作業のためだけのツールではありません。
「書いて→試して→記録する」を繰り返す研究作業において、自分の試行錯誤の記録を丁寧に残す道具として、とても有効です。
慣れないうちは1行だけでもいいので、こまめにコミットして履歴を残すことをおすすめします。
VSCodeでGitを使うとさらに便利
Visual Studio Code(VSCode)はGitととても相性が良く、以下のような操作がすべて画面上のボタンで可能になります:
変更されたファイルの一覧の表示
差分(どこが変わったか)の確認
コミット履歴の表示
GitHubへのプッシュ
これにより、初心者でも比較的ストレスなくGitを使いこなせるようになります。
このように、Gitを使うことでコードの品質や管理のしやすさが格段に上がります。最初は難しそうに見えるかもしれませんが、実験ノートをつける感覚で「こまめに記録する」ことから始めてみてください。
コーディングに使うツール:VSCode
ここまで作った「プロジェクトフォルダ+仮想環境+Git」を、使いやすくするのが VSCode です。ターミナル、高性能エディタ、gitやリモートアクセス機能がひとつの画面にまとまったものだと思ったら使わない理由がないですよね。
ファイル編集、ターミナル操作、Git連携がすべて1つでできる
ChatGPTで作ったコードを貼って編集・実行もしやすい
拡張機能が豊富で、Pythonとの相性がとても良い
よく使う拡張機能:
Python:必須の基本機能
Pylance:型推論や補完の精度が上がる
GitLens:Gitの履歴が見やすくなる
Jupyter:ノートブック形式での実行も可能(必要な人向け)
💡 VSCodeのターミナルからそのまま source venv/bin/activate すれば、仮想環境で作業できます。
まとめ
標準的なPythonのコーディング環境は、以下のようにシンプルな構成です:
プロジェクトごとにフォルダを作る
仮想環境を設定し、必要なライブラリをインストールする
Gitで履歴を管理する
VSCodeでまとめて操作する
この基本さえ押さえておけば、あとは少しずつスキルを積み重ねていくだけです。
AIエージェントなどの便利ツールを使うのは、それからでもまったく遅くありません。
おまけ:コーディングスタイルとファイルの分け方
命名規則とファイル構成の基本
Pythonでコードを書くとき、「どんな名前をつけるか」「どうやってファイルを分けるか」はとても大切です。
最初のうちは「とりあえず main.py に全部書いてしまう」でもいいのですが、コードが長くなってくると、整理されていないと後で見直すのが大変になります。
命名規則:コードに意味をもたせる名前をつけよう
Pythonには PEP8(ペップエイト) という、公式のスタイルガイドがあります。
この中で推奨されている命名規則のうち、基本的なものは以下の通りです。
関数名・変数名:スネークケース(snake_case)
単語を小文字でつなぎ、単語の間をアンダースコア _ でつなぎます。
例:
process_data()
file_path
calculate_score()
クラス名:キャメルケース(CamelCase)
各単語の頭文字を大文字にしてつなげます(Javaと同じ形式)。
例:
DataAnalyzer
RobotController
定数:すべて大文字 + アンダースコア
変更されることを想定していない値(定数)は、目立つように書きます。
例:
MAX_RETRY_COUNT = 5
DEFAULT_TIMEOUT = 30
名前のつけ方のポイント
名前は意味が伝わるものにする(x, y, tmpはなるべく避ける)
略語より少し長くても具体的な名前の方が読みやすい
ChatGPTにコードを書いてもらうときも「snake_caseで書いて」と指定すると整った名前になります
ファイル構成の基本:小さなスクリプトでも分けてみよう
最初は main.py にすべて書いても問題ありません。ただし、機能が増えてくると、以下のように目的ごとにファイルを分けるととても見通しがよくなります。
シンプルな例
my_project/
├── main.py # 実行の起点(入口)
├── utils.py # よく使う共通の関数
├── config.py # 設定値(定数、パスなど)
├── data/ # データファイルを入れるフォルダ
├── venv/ # 仮想環境(Gitでは除外)
└── requirements.txt # ライブラリ一覧もう少し大きなプロジェクトになったら
my_project/
├── main.py
├── config.py
├── utils/
│ ├── io.py # 読み書き関連
│ └── math_tools.py # 計算用ツール
├── modules/
│ ├── feature.py # 特徴量計算など
│ └── model.py # 機械学習モデル
├── tests/
│ └── test_feature.py
├── data/
├── venv/
└── requirements.txtここでは、utils/ や modules/ といったディレクトリ(フォルダ)単位で分類しており、ファイル数が増えても管理しやすくなります。
ファイルを分けると何がいいの?
必要なところだけ読み込める(例:from utils.io import read_csv_file)
再利用しやすい
ChatGPTに「utils.pyを改善して」と頼むとき、ファイル単位で相談できる
テストコードや補助関数を分けることで、本体がスッキリする
命名規則とファイル構成は「優しさ」
コードを書くとき、後から読む自分や他の人に向けた優しさとして、名前を丁寧につけたり、整理したりするのはとても大切な習慣です。
ChatGPTにコードを見てもらうときにも、整理されていると「どの部分をどう直したいのか」が伝えやすくなります。