[Medical AI with Python: P9] 医療AI研究開発のための、Git・GitHub完全ガイド！ — 再現性を生む「タイムマシン」を使いこなす

はじめに：コードの変更履歴という「カルテ」を記録する

皆さん、こんにちは！
前回の講義で、私たちはフォルダ構成を整え、研究プロジェクトの「骨格」、いわば白紙のカルテのフォーマットを用意しました。しかし、実際の研究はここからが本番です。コードを書き、実験し、結果を見て、またコードを修正する…。このプロセスは、患者さんの状態変化に合わせて、カルテに追記を重ねていく作業に非常によく似ています。

ここで、多くの人が経験するであろう「悪夢」が頭をよぎります。「昨日までは完璧に動いていたコードが、今日の修正で全く動かなくなった。元に戻したいけど、どこをどう変更したか正確に思い出せない…」「3ヶ月前の学会で発表した、あの素晴らしい結果。再現しようにも、どのバージョンのコードとデータを使ったのか、もはや分からない…」。心当たりはありませんか？

こうした事態は、単に不便なだけでなく、研究の再現性という、科学における最も重要な根幹を揺るがしかねません。

もし、あなたのプロジェクト全体に、全ての変更内容と変更理由が自動的に記録され、いつでも好きな時点の過去に遡れる「タイムマシン」機能があったとしたらどうでしょう？さらに、その変更履歴という名の完璧な「カルテ」を、共同研究者と安全かつスムーズに共有できるとしたら？

この、夢のようなバージョン管理を実現するのが、Git（ギット）とGitHub（ギットハブ）です。これらは、現代の開発者・研究者にとって、もはやWordやExcelと同じくらい、あるいはそれ以上に必須の基本ツールと言えるでしょう。

この講義では、この強力なコンビの基本的な概念と操作方法を学び、皆さんの研究開発を、より安全で、再現性の高い、プロフェッショナルなものへと変えるための、確かな第一歩を踏み出します。

1. なぜバージョン管理が「研究者の必須スキル」なのか？ 〜「論文_最終版_本当に最終.py」からの卒業〜

皆さんが論文を書くとき、「論文_最終版.docx」、「論文_v2_修正版.docx」、「論文_本当に最終_v3.docx」…といったファイルが大量にできてしまった経験はないでしょうか。どれが本当に最新で、どのような変更を加えたのか、管理が大変ですよね。

AIの研究開発も全く同じで、コードを少し修正しては別名で保存、ということを繰り返していると、あっという間にフォルダは混沌としてしまいます。これは、単に不便なだけでなく、研究の再現性を著しく損なう、非常に危険な状態です。

この、ファイル管理の「悪夢」を、体系的かつエレガントに解決してくれるのが、バージョン管理システム（Version Control System, VCS）です。その代表格が、今回学ぶGitです。

バージョン管理システムは、ファイルやフォルダの状態を、ある時点での「スナップショット」として記録し、「誰が・いつ・何を・なぜ変更したのか」という、完璧な変更履歴（ログ）を自動で残してくれます。これにより、私たちはいつでも好きな時点の「過去」に、まるでタイムマシンのように、瞬時に戻ることができるのです。

バージョン管理がある世界とない世界とで、研究の進め方がどう変わるのか、具体的に比較してみましょう。

このように、バージョン管理は、単なるバックアップツールではありません。それは、私たちの知的生産活動の質を高め、コラボレーションを加速させ、そして何より、研究の信頼性と再現性を担保するための、現代の研究者にとって不可欠なインフラなのです。

2. GitとGitHub：よく似て非なる「最強コンビ」 〜ローカルの「実験ノート」と、クラウドの「中央図書館」〜

さて、バージョン管理の話をすると、必ずと言っていいほどセットで登場するのが、GitとGitHubという二つの名前です。ロゴも似ていますし、よく混同されがちですが、この二つは全く異なる役割を持つ、最強のコンビだと理解することが、最初の一歩として非常に重要です。

それぞれの役割：ソフトウェアとウェブサービス

• Git：個人のPCで動く「ソフトウェア」 まず、Gitは、あなたの個人のPC上で動く「ソフトウェア」そのものです。その役割は、前節で説明した通り、ファイルの変更履歴を記録・管理することです。これは、あなた専用の、非常に高性能な「デジタル実験ノート」だと考えてください。このノートはあなたのPCの中にあり、インターネットに接続していなくても、いつでも書き込んだり、過去のページをめくったりすることができます。完全にローカルで完結する、個人のためのツールです。
• GitHub：クラウド上の「ウェブサービス」 一方、GitHubは、インターネット上で提供される「ウェブサービス」です。その役割は、Gitで記録された「デジタル実験ノート」を、安全に保管し、他人と共有することです。これは、世界中の研究者が自分の実験ノートを持ち寄る、巨大な「オンライン上の中央図書館」や「共同研究室」のようなものです。あなたは、自分の実験ノートの完璧なコピー（バックアップ）をこの図書館に預けたり、他の研究者の優れたノートを閲覧したり、自分のノートを見せてフィードバックをもらったり、複数人で一つのノートを同時に編集したりすることができます。

この関係性を、以下の表と図で整理してみましょう。

GitとGitHubの関係

つまり、手元のPCでGitを使って日々の変更をコツコツと記録し、キリの良いところでGitHubにアップロード（push）してバックアップと共有を行う。これが、基本的な使い方になります。Gitというローカルツールだけでもバージョン管理は可能ですが、GitHubというクラウドサービスと組み合わせることで、その力は飛躍的に高まるのです。

Git & GitHub ワークフロー・シミュレータ

3. Gitの基本サイクル：研究の「セーブポイント」を作る 〜 add と commit で、変更履歴を刻む 〜

Gitの操作は、RPGで冒険の記録をセーブするのに非常によく似ています。「ここまでの進捗は完璧だ」というキリの良いタイミングで、コミット（commit）という操作を行い、プロジェクトの状態を「セーブポイント」として記録していくのです。このセーブを積み重ねることで、安全で再現性の高い開発が可能になります。

「実践！Gitを使ってみよう」シミュレータ

3.1 なぜ3つもエリアがあるのか？Gitの作業空間を理解する 〜「机の上」→「提出用封筒」→「書庫」という3ステップ〜

Gitの操作を理解する上で、多くの初学者が最初につまずくのが、「なぜ作業場所が3つもあるんだ？直接セーブ（コミット）すればいいじゃないか」という点だと思います。この3つのエリアの役割分担を理解することこそが、Gitを快適に使いこなすための、最初の鍵となります。

このプロセスを、皆さんが論文を執筆し、学会に投稿するまでの流れに例えてみましょう。

Gitの3つのエリア

1. エリア①：作業ディレクトリ (Working Directory) — あなたの「机の上」 これは、あなたのPCのプロジェクトフォルダそのものです。まさに、あなたが今、論文の草稿を書いたり、Pythonコードを編集したり、図表を作成したりしている、カオスな状態の「机の上」です。書きかけのメモ、参考にした論文、完成した原稿、全てがここに置かれています。
2. エリア②：ステージングエリア (Staging Area) — 提出用の「封筒」 さて、机の上で作業がある程度進みました。論文の「第1章」が完成し、それに対応する「図1」も出来上がりました。しかし、「第2章」はまだ書きかけで、アイデアを殴り書きしたメモも散乱しています。この状態で、プロジェクト全体を丸ごとセーブ（コミット）してしまうと、「第1章と図1の完成」という一つの意味のある変更と、作業途中のものがごちゃ混ぜになって、後から見返したときに何をしたかったのか分からなくなりますよね。 そこで登場するのが、ステージングエリアです。これは、コミット（書庫への保管）の前に、記録したい変更内容だけを一時的に置いておく「提出用の封筒」のような場所です。あなたは、「よし、今回は第1章と図1の完成版だけをこの封筒に入れよう」と、自分でコミットに含める変更を選ぶことができます（git addというコマンドがこれにあたります）。 この「封筒に入れる」というワンクッションがあるおかげで、私たちは変更内容を意味のある単位に整理し、論理的なセーブポイント（コミット）を作成することができるのです。これこそが、ステージングエリアが存在する最大の理由です。
3. エリア③：ローカルリポジトリ (Local Repository) — 安全な「書庫」 最後に、「提出用の封筒」（ステージングエリア）の中身を確認し、問題がなければ、「”第1章と図1を完成させた”」という明確なメッセージを添えて、プロジェクトの公式な記録保管庫である「書庫（リポジトリ）」に、正式にファイリングします（git commitというコマンドがこれにあたります）。一度ここに保管された記録は、いつでもその時点の状態を完璧に取り出すことができる、信頼性の高いセーブポイントとなります。

この「机の上で作業 → 完成品を封筒に入れる → 封筒を書庫に保管」という3ステップのリズムが、Gitの基本サイクルです。この流れを意識することで、皆さんの変更履歴は、格段に整理され、意味のあるものになるでしょう。

3.2 基本的なコマンドの流れ：日々の研究記録をつける

では、この3つのエリアを行き来するための、具体的なコマンドを見ていきましょう。一連の流れとして覚えるのがおすすめです。

# (プロジェクトフォルダに移動した後...)

# ステップ1: Gitの初期化 (プロジェクトの最初の一度だけ)
# 「このフォルダをGitの管理下に置きます」という宣言。
# .gitという隠しフォルダ（リポジトリ本体）が作られます。
git init

# (ここで、README.md や src/train.py などのファイルを編集・作成します)

# ステップ2: 変更をステージングエリアに追加
# 「README.mdとtrain.pyの変更を、次のコミットに含めます」という意思表示。
# 作業ディレクトリから、ステージングエリアへファイルを移動させます。
git add README.md
git add src/train.py
# `git add .` とすると、全ての変更を一度にステージできます。

# ステップ3: ステージした変更をリポジトリにコミット
# 「"モデルの初期実装"というメッセージを添えて、ステージングエリアの中身を記録します」
# これで、ローカルリポジトリに新しいセーブポイントが作成されます。
git commit -m "Initial implementation of the model"

# (便利な確認コマンド)
# ステップA: 状態を確認する
# 「今、どのファイルが変更されて、どれがステージングされているか？」を確認できます。
# こまめに実行する癖をつけると良いでしょう。
git status

# ステップB: 過去の履歴を見る
# これまでのコミット（セーブポイント）の履歴を一覧表示します。
git log

このaddしてcommitする、というサイクルが、Gitを使った日々の研究開発における、最も基本的なリズムになります。意味のある変更のまとまりごとに、分かりやすいメッセージを添えて、こまめにコミットを残していく。これが、未来の自分を助ける、最高の「カルテ」の書き方なのです。

4. GitHubとの連携とブランチの初歩 〜「共有」と「安全な実験」で、研究を加速させる〜

さて、git addとgit commitを繰り返すことで、あなたのPC（ローカル）にある「実験ノート」には、完璧な変更履歴が刻まれていきました。しかし、このノートはまだ、あなたのPCの中にしか存在しません。もしPCが壊れたら？もし、共同研究者に最新の進捗を見せたくなったら？

ここで、いよいよGitHubという「中央図書館」の出番です。ローカルで記録した研究成果を、GitHubと連携させることで、安全なバックアップと、円滑な共同作業という、二つの大きなメリットを得ることができます。

「実践！GitHubと連携しよう」シミュレータ

4.1 リモートリポジトリとの連携：push & pull

GitHub上に作成したプロジェクトの保管庫のことを、リモートリポジトリと呼びます。これは、ローカルリポジトリの「親」のような存在です。この親子間で、変更履歴をやり取りするための基本的なコマンドがpushとpullです。

• git push: ローカルリポジトリで行った一連のコミット（変更履歴）を、リモートリポジトリにアップロードするコマンドです。これにより、あなたのPC上の成果が、クラウド上の「中央図書館」にバックアップされます。
• git pull: 他の共同研究者がリモートリポジトリを更新した場合に、その最新の変更を、あなたのローカルリポジトリにダウンロードして、手元の環境を最新の状態に保つためのコマンドです。

4.2 ブランチ：安全に「実験」するための魔法

研究を進めていると、「このアプローチも試してみたいけど、今の安定して動いているコードを壊したくないな…」と思うことが頻繁にありますよね。そんな時に絶大な威力を発揮するのが、ブランチ（Branch）という機能です。

ブランチを切る（作成する）とは、あなたの実験ノートの、ある時点の完璧な「コピー」を作成し、別のノートとして実験を始めるようなものです。元のノート（通常、mainブランチと呼ばれます）には一切影響を与えずに、新しいノート（例えばfeature-aブランチ）で、心ゆくまで新しいアイデアを試すことができます。

• 実験が成功したら: その変更内容を、元のmainブランチに合流（マージ）させます。コピーしたノートの成功したページを、本物のノートに綺麗に貼り付けるイメージです。
• 実験が失敗したら: もし、うまくいかなければ、そのブランチ（コピーしたノート）を、単純に破棄してしまえば良いのです。元のノートには、何の影響もありません。

ブランチの概念図

このブランチの考え方は、Gitを使いこなす上で最も重要と言っても過言ではありません。ブランチを複数人で共有する際の作法や、もし変更内容が衝突（コンフリクト）してしまった場合の解決方法など、より高度なトピックについては、今後の詳細記事（1.9.x）でじっくり扱いますので、まずは「安全な実験室」というイメージを掴んでください。

4.3 主要な連携・ブランチコマンド

これらを実現するための、基本的なコマンドの流れを見ておきましょう。

5. 医療AI開発における最重要事項：.gitignoreで患者データを守る 〜事故を防ぐ、最初の「安全確認」〜

ここからお話しすることは、この講義全体を通じて、技術的に最も複雑というわけではないかもしれませんが、倫理的・法的に最も重要な、絶対に守らなければならない約束事です。

GitとGitHubは非常に強力なツールですが、その力を誤って使うと、取り返しのつかない事態を招く可能性があります。それは、患者さんの個人情報や、それに準ずる機微なデータを、誤ってGitHubのような公開（あるいは共有）サーバーにアップロードしてしまうという、医療AI開発における最大級の事故です。これは、手術室の清潔操作や、処方箋のダブルチェックと同じレベルで、私たちが遵守すべき、基本的な安全管理手順だと考えてください。

.gitignore：Gitの「無視リスト」

この重大な事故を、仕組みとして防いでくれるのが、.gitignore（ドット・ギットイグノア）という名前の、シンプルなテキストファイルです。このファイルに名前が書かれたファイルやフォルダは、Gitが意図的に「無視」するようになります。つまり、git statusに表示されなくなり、たとえ誤って git add . （カレントディレクトリの全ての変更をステージするコマンド）を実行してしまっても、ステージングエリアに追加されることがなくなるのです。

研究プロジェクトを開始したら、まず最初に、この.gitignoreファイルをプロジェクトのルートフォルダに作成し、追跡対象外とすべきものをリストアップする。 これを、最初の「儀式」として、必ず習慣づけてください。

医療AIプロジェクトにおける.gitignoreの記述例

以下に、医療AIの研究プロジェクトで一般的に使われる.gitignoreの記述例を示します。この内容は、そのままコピーして皆さんのプロジェクトで使うことができます。

研究を始める前に、まずこの.gitignoreファイルを正しく設定する習慣をつけること。これが、うっかりミスによる重大な情報漏洩を防ぎ、患者さんのプライバシーと、私たち研究者自身のキャリアを守るための、最も簡単で、そして最も効果的な防衛策なのです。

まとめと次のステップへ

今回は、研究の再現性と協業に不可欠なバージョン管理ツール、GitとGitHubの基本的な考え方を学びました。

• Gitは個人のPCで動く「タイムマシン」。
• GitHubはクラウド上でそれを共有・バックアップする「図書館」。
• add -> commit -> push が基本的な流れ。
• .gitignore は、患者さんのプライバシーを守るための「安全装置」。

参考文献

1. Chacon S, Straub B. Pro Git. 2nd ed. Apress; 2014. [Internet]. Available from: https://git-scm.com/book/en/v2
2. GitHub. GitHub Docs. [Internet]. [cited 2025 Jun 24]. Available from: https://docs.github.com/

ご利用規約（免責事項）

当サイト（以下「本サイト」といいます）をご利用になる前に、本ご利用規約（以下「本規約」といいます）をよくお読みください。本サイトを利用された時点で、利用者は本規約の全ての条項に同意したものとみなします。

第1条（目的と情報の性質）

1. 本サイトは、医療分野におけるAI技術に関する一般的な情報提供および技術的な学習機会の提供を唯一の目的とします。
2. 本サイトで提供されるすべてのコンテンツ（文章、図表、コード、データセットの紹介等を含みますが、これらに限定されません）は、一般的な学習参考用であり、いかなる場合も医学的な助言、診断、治療、またはこれらに準ずる行為（以下「医行為等」といいます）を提供するものではありません。
3. 本サイトのコンテンツは、特定の製品、技術、または治療法の有効性、安全性を保証、推奨、または広告・販売促進するものではありません。紹介する技術には研究開発段階のものが含まれており、その臨床応用には、さらなる研究と国内外の規制当局による正式な承認が別途必要です。
4. 本サイトは、情報提供を目的としたものであり、特定の治療法を推奨するものではありません。健康に関するご懸念やご相談は、必ず専門の医療機関にご相談ください。

第2条（法令等の遵守）
利用者は、本サイトの利用にあたり、医師法、医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律（薬機法）、個人情報の保護に関する法律、医療法、医療広告ガイドライン、その他関連する国内外の全ての法令、条例、規則、および各省庁・学会等が定める最新のガイドライン等を、自らの責任において遵守するものとします。これらの適用判断についても、利用者が自ら関係各所に確認するものとし、本サイトは一切の責任を負いません。

第3条（医療行為における責任）

1. 本サイトで紹介するAI技術・手法は、あくまで研究段階の技術的解説であり、実際の臨床現場での診断・治療を代替、補助、または推奨するものでは一切ありません。
2. 医行為等に関する最終的な判断、決定、およびそれに伴う一切の責任は、必ず法律上その資格を認められた医療専門家（医師、歯科医師等）が負うものとします。AIによる出力を、資格を有する専門家による独立した検証および判断を経ずに利用することを固く禁じます。
3. 本サイトの情報に基づくいかなる行為によって利用者または第三者に損害が生じた場合も、本サイト運営者は一切の責任を負いません。実際の臨床判断に際しては、必ず担当の医療専門家にご相談ください。本サイトの利用によって、利用者と本サイト運営者の間に、医師と患者の関係、またはその他いかなる専門的な関係も成立するものではありません。

第4条（情報の正確性・完全性・有用性）

1. 本サイトは、掲載する情報（数値、事例、ソースコード、ライブラリのバージョン等）の正確性、完全性、網羅性、有用性、特定目的への適合性、その他一切の事項について、何ら保証するものではありません。
2. 掲載情報は執筆時点のものであり、予告なく変更または削除されることがあります。また、技術の進展、ライブラリの更新等により、情報は古くなる可能性があります。利用者は、必ず自身で公式ドキュメント等の最新情報を確認し、自らの責任で情報を利用するものとします。

第5条（AI生成コンテンツに関する注意事項）
本サイトのコンテンツには、AIによる提案を基に作成された部分が含まれる場合がありますが、公開にあたっては人間による監修・編集を経ています。利用者が生成AI等を用いる際は、ハルシネーション（事実に基づかない情報の生成）やバイアスのリスクが内在することを十分に理解し、その出力を鵜呑みにすることなく、必ず専門家による検証を行うものとします。

第6条（知的財産権）

1. 本サイトを構成するすべてのコンテンツに関する著作権、商標権、その他一切の知的財産権は、本サイト運営者または正当な権利を有する第三者に帰属します。
2. 本サイトのコンテンツを引用、転載、複製、改変、その他の二次利用を行う場合は、著作権法その他関連法規を遵守し、必ず出典を明記するとともに、権利者の許諾を得るなど、適切な手続きを自らの責任で行うものとします。

第7条（プライバシー・倫理）
本サイトで紹介または言及されるデータセット等を利用する場合、利用者は当該データセットに付随するライセンス条件および研究倫理指針を厳格に遵守し、個人情報の匿名化や同意取得の確認など、適用される法規制に基づき必要とされるすべての措置を、自らの責任において講じるものとします。

第8条（利用環境）
本サイトで紹介するソースコードやライブラリは、執筆時点で特定のバージョンおよび実行環境（OS、ハードウェア、依存パッケージ等）を前提としています。利用者の環境における動作を保証するものではなく、互換性の問題等に起因するいかなる不利益・損害についても、本サイト運営者は責任を負いません。

第9条（免責事項）

1. 本サイト運営者は、利用者が本サイトを利用したこと、または利用できなかったことによって生じる一切の損害（直接損害、間接損害、付随的損害、特別損害、懲罰的損害、逸失利益、データの消失、プログラムの毀損等を含みますが、これらに限定されません）について、その原因の如何を問わず、一切の法的責任を負わないものとします。
2. 本サイトの利用は、学習および研究目的に限定されるものとし、それ以外の目的での利用はご遠慮ください。
3. 本サイトの利用に関連して、利用者と第三者との間で紛争が生じた場合、利用者は自らの費用と責任においてこれを解決するものとし、本サイト運営者に一切の迷惑または損害を与えないものとします。
4. 本サイト運営者は、いつでも予告なく本サイトの運営を中断、中止、または内容を変更できるものとし、これによって利用者に生じたいかなる損害についても責任を負いません。

第10条（規約の変更）
本サイト運営者は、必要と判断した場合、利用者の承諾を得ることなく、いつでも本規約を変更することができます。変更後の規約は、本サイト上に掲載された時点で効力を生じるものとし、利用者は変更後の規約に拘束されるものとします。

第11条（準拠法および合意管轄）
本規約の解釈にあたっては、日本法を準拠法とします。本サイトの利用および本規約に関連して生じる一切の紛争については、東京地方裁判所を第一審の専属的合意管轄裁判所とします。

For J³, may joy follow you.