最近はChatGPTやCodexでコードを書く機会が増えた。

その一方で、

• AIが大量にコードを書き換える
• 動いていたものが急に壊れる
• 修正したら別の場所が壊れる

みたいなことも普通に起きる。

そこで重要になってくるのが Git。

それはわかる。わかるが、いろいろ調べても今一つよくわからない。

ので、自分で記事にすることにした。

この記事では、

• GitとGitHubの違い
• 新規作成からリリースまでの流れ
• branchを使った安全な実験方法
• 壊れた時の戻し方
• 自動デプロイ
• セキュリティ注意点

を初心者向けに整理する。

Gitがあると助かる場面

Gitは単なる「バックアップ」ではない。

実際に助かるのはこういう場面。

・昨日動いていた状態に戻せる
・AI改修前へ戻せる
・別案を安全に試せる
・PC故障時の保険になる
・公開版だけ管理できる
・どの変更で壊れたか追跡できる

AI時代は特に、

「安全に試行錯誤できること」

の価値が大きい。

AIにコードを直してもらう時ほど、先にGitでセーブポイントを作っておくと安心です。

Gitとは

Gitは「変更履歴管理システム」。

簡単に言うと、

ファイルのセーブポイントを残し続ける仕組み

に近い。

Gitがない世界

Gitなしだとありがちなのがこれ。

project_final
project_final2
project_final_last
project_final_last_fix

途中でどれが正しいか分からなくなる。

Gitがあるとどうなるか

flowchart TD

A[ファイルを編集する] --> B[Gitで変更を確認]

B --> C{保存する変更か？}
C -->|はい| D[git add]
D --> E[git commit]
E --> F[履歴として保存]

C -->|いいえ| G[変更を破棄]

F --> H[過去へ戻せる]
F --> I[変更差分を確認できる]
F --> J[どこで壊れたか追跡できる]

Gitは、

• 変更履歴
• バージョン管理
• 復旧

を助ける。

GitとGitHubの違い

ここはかなり混乱しやすい。

Git

履歴管理システム本体。

PCだけでも使える。

flowchart TD

A[ローカルPC]

A --> B[Git]

B --> C[変更履歴]

GitHub

Gitデータをクラウド保管するサービス。

flowchart TD

A[ローカルPC]

A --> B[Git]

B --> C[GitHub]

つまり：

まずはGitだけでも大丈夫。GitHubは、バックアップや共有が必要になってからでも遅くありません。

ローカルGitだけでもかなり価値がある

ここは重要。

初心者は、

GitHub必須

と思いがち。

でも実際には、

• VBA
• WordPress
• Python
• HTML/CSS

くらいなら、

PC内Gitだけでもかなり助かる

まずは：

壊れても戻せる

を体験するだけでも価値がある。

Git操作の流れ

初心者が混乱しやすいのが：

• add
• commit
• push

の違い。

まずはこの流れで考えると分かりやすい。

flowchart LR

A[ファイル編集]

--> B[git add

保存候補へ入れる]
B --> C[git commit
履歴として保存]

C --> D[git push
GitHubへ送る]

新規作成からリリースまでの流れ

初心者向けにかなり簡略化するとこう。

flowchart LR

A[プロジェクト作成] --> B[Git初期化]

B --> C[ファイル編集]

C --> D[commit]

D --> E[GitHubへpush]

E --> F[テスト]

F --> G[リリース]

実際に使うコマンド

Git初期化

git init

現在フォルダをGit管理化する。

状態確認

git status

最重要コマンド。

初心者はまずこれを多用する。

変更追加

git add .

変更ファイルをcommit対象へ入れる。

履歴保存

git commit -m "初回登録"

セーブポイント作成。

GitHubへ送る

git push

GitHubへアップロード。

GitHubから取得

git pull

GitHub側の最新状態を取得。

mainとbranchとは

Gitで重要なのが branch。

main

本線。

現在の安定版。

branch

実験用コピー。

別世界を作るイメージ。

mainをコピーして、

安全な実験空間

を作る。

branchのイメージ

flowchart LR
subgraph MAIN["main（安定版）"]
    M1[v1.0]
    M2[不具合修正]
    M3[v1.1]
end

subgraph BRANCH["feature-ui"]
    B1[UI変更]
    B2[AI改修]
    B3[色調整]
end

M1 -. branch作成 .-> B1
B1 --> B2
B2 --> B3

B3 -. merge .-> M3

なぜbranchが重要なのか

AI時代は特に重要。

例えば：

• Codexで大規模改修
• CSS全変更
• WordPress改造

を直接mainでやると危険。

branchなら：

• 失敗しても捨てられる
• mainは壊れない

ので安全。

branch作成

git branch feature-ui

branch切替

git checkout feature-ui

branch作成＋切替

git checkout -b feature-ui

これをよく使う。

AI改修を頼む前に branch を切る、という癖をつけると事故が減ります。

merge（反映）

問題なければmainへ反映。

git checkout main
git merge feature-ui

Gitを使ったリリースイメージ

Gitは「開発」だけではなく、

公開まで繋がる。

flowchart LR

A[開発]

--> B[テスト]
B --> C[mainへmerge]

C --> D[GitHubへpush]

D --> E[本番公開]

壊れた時の戻し方

Gitの最大価値。

変更取り消し

git restore .

commit前の変更を戻す。

過去commitを見る

git log

履歴一覧を見る。

過去commitへ移動

git checkout コミットID

昔の状態を見る。

reset –hard は強力なので注意

git reset --hard コミットID

完全に戻す。

ただし、

• 作業内容が消える
• 初心者は事故りやすい

ので注意。

reset --hard は強力です。迷ったら、先に別branchを作るか、作業フォルダをコピーしてから実行した方が安全です。

GitHubと自動デプロイ

最近かなり便利。

自動デプロイとは

GitHubへpushすると：

• サーバーへ自動反映
• 公開サイト更新

まで自動化する仕組み。

イメージ

flowchart LR

A[ローカルPC]

--> B[git push]
B --> C[GitHub]

C --> D[GitHub Actions]

D --> E[サーバーへデプロイ]

E --> F[Webサイト更新]

何が便利か

例えば：

• WordPressテーマ
• HTMLサイト
• React
• Pythonアプリ

など。

毎回FTPアップロードしなくてよくなる。

FTPは注意

昔ながらのFTPは危険。

できれば：

• SFTP
• SSH

推奨。

セキュリティ注意点

ここはかなり重要。

APIキーをcommitしない

例えば：

API_KEY=xxxxx
PASSWORD=abc

をGit管理すると危険。

理由

Gitは履歴が残る。

つまり：

一瞬でもcommitすると履歴から掘れる

削除しても危険。

実際に起きている事故

実際には、

• AWSキー流出
• OpenAI APIキー流出
• WordPressパスワード流出

などが起きている。

.gitignore を使う

Git管理除外設定。

.env
node_modules/
vendor/
config.local.php

秘密情報を除外する。

APIキーやパスワードを一度commitすると、削除しても履歴に残ります。公開リポジトリでは特に注意です。

初心者向けおすすめ運用

最初はこれで十分。

Step1

ローカルGit。

PC
 └ Git

まずは「戻せる」ことを覚える。

Step2

GitHub Private。

PC
 ↓
GitHub Private

バックアップ追加。

Step3

自動デプロイ。

GitHub
 ↓
サーバー

更新自動化。

AI時代はGitが重要

最近は特に重要。

AIは：

• 一括変更
• 大量修正
• 想定外変更

を普通にやる。

つまり、

「戻せる前提」

がかなり重要になる。

Gitはその保険。

よく使うGitコマンド一覧

まとめ

Gitは、

「完成品保存」

ではなく、

「安全に試行錯誤するための履歴管理」

に近い。

特にAI開発では：

• 壊れる速度が速い
• 修正範囲が広い
• 何を変えたか追いにくい

ので、Gitの価値がかなり上がっている。

個人開発でも、

• 復旧性
• 実験性
• 継続改善

を考えるなら、かなり重要な基盤だと思う。

JADERは、PMDAが公開している医薬品副作用データベースだ。副作用が疑われる症例報告をもとにしたデータであり、医薬品と有害事象の関係を考えるうえで参考になる。

ただし、報告件数が多いから危険、少ないから安全、という読み方はできない。使用患者数、報告されやすさ、重複、併用薬、症例背景など、さまざまな要素が影響するためだ。

今回の作業は、JADERを研究として深掘りするというより、発表資料で使えるように必要な観点でデータを整理し、集計表やグラフの形に落とし込むことが主な目的だった。

今回の作業範囲

作業の内容は、JADERデータの内容確認、分析対象となる薬剤・有害事象の絞り込み、SPSSで扱いやすい形へのデータ整理、件数集計・クロス集計・割合の算出、発表資料用の表・グラフの作成、結果の読み取りメモの作成だ。

分析ツールはSPSSを使用した。Excelでもある程度の集計はできるが、項目数が多く条件を切り替えながら集計する場合は、SPSSの方が作業の見通しを立てやすい。特に、クロス集計やカテゴリ別集計を繰り返す場面では、どの条件で集計したのかを残しやすい点が助かった。

JADERデータで最初に注意したこと

最初に気を付けたのは、JADERのデータを「そのまま比較に使えるデータ」と見なさないことだった。

JADERは副作用が疑われる症例報告を集めたデータであり、医薬品を使ったすべての患者を把握しているわけではない。報告件数が多くなる理由には、使用患者数が多い、注目されている薬剤で報告されやすい、同じ症例に複数の有害事象が登録されている、といったことが挙げられる。

このあたりを整理しないままグラフにすると、発表資料としては見やすくても、読み手に誤解を与える可能性がある。今回の取りまとめでは、「件数が多い＝危険」と読める表現は避けた。

SPSSに取り込む前の整理

JADERのデータは、そのままSPSSに入れれば終わり、というものではなかった。分析対象にする項目を確認し、どの単位で集計するかを先に整理する必要があった。

特に迷ったのは、症例単位で見るのか、薬剤単位で見るのか、有害事象単位で見るのかという点だ。同じ症例に複数の薬剤や有害事象が紐づく場合があるため、集計単位を曖昧にしたまま作業すると件数の意味が分からなくなる。

作業前に、1行が何を表しているのか、症例番号をキーとして扱えるか、集計結果の件数は症例数なのか報告数なのか、発表資料ではどの粒度で見せるべきかを確認した。ここを先に決めておかないと、後から表やグラフを作ったときに説明が難しくなる。

SPSSで行った主な集計

主な集計は、対象薬剤ごとの報告件数、対象有害事象ごとの報告件数、年齢区分・性別・転帰別の集計、薬剤と有害事象のクロス集計、条件を絞ったサブグループ集計だ。

発表資料用の分析だったため、集計できる項目をすべて出すのではなく、説明に使えるものを選ぶ必要があった。全部出すと資料として逆に分かりにくくなる。そのため、まず全体像を見せ、次に対象薬剤・有害事象に絞り、必要に応じて背景情報を加え、最後に読み取り上の注意点を添える順番で整理した。

発表資料用に意識した見せ方

SPSSの出力表は確認用としては便利だが、そのままスライドに載せると情報量が多すぎる。発表資料では、表は必要な列だけに絞り、件数と割合の意味を明確にし、グラフは比較したい項目だけに限定した。

特に意識したのは、断定的な因果関係に見える表現を避けることと、注釈でJADERデータの性質を補足することだ。棒グラフにすると差が強調されるが、その差が本当に意味のある差なのかは別の問題である。グラフ化する場合でも、単純な順位付けに見えすぎないよう注意した。

苦労した点と得たこと

IT関連の業務に関する分析・統計は知見があったが、医療統計、SPSSの使い方も学習しながらの業務となった。分析をするまでについても簡単ではなかった。

さらに苦労したのは、分析そのものよりも結果の意味をどう説明するかだった。JADERのようなデータでは件数は出せる。しかしその件数をどう読むかは簡単ではない。

発表資料では限られたスライド数の中で説明する必要があり、注意点を省きすぎると単純な安全性比較のように見えてしまう。そのため、主な結果は絞り、補足資料として集計表を残し、スライド上には注釈を入れ、「傾向を確認するための集計」として位置づけるバランスを取った。

今回の作業で感じたのは、集計作業そのものよりも前提条件の整理が重要だということだ。どの単位で数えているのか、何を比較しているのか、その結果から何を言ってよいのかを整理しないと、発表資料としては危ういものになる。ツールよりも、最初の設計の方が重要だった。

まとめ

JADERデータの分析取りまとめでは、SPSSを使って発表資料用の集計表やグラフを作成した。重要だったのはSPSSの操作そのものではなく、JADERデータの性質を踏まえて結果をどう見せるかだった。

JADERは医薬品と有害事象の関係を考えるうえで有用なデータだが、単純な件数比較で安全性を判断できるものではない。その前提を崩さずに発表資料として整理する。今回の作業は、公開データを使った分析結果を誤解されにくい資料に整えるための実務だった。

要件は「休暇申請は管理者が承認する」「休暇はカレンダーで全員で参照可能とする」である。

休暇申請は「申請フォームを作る」だけでは終わらない。申請者が入力し、承認者に通知が届き、承認・却下され、カレンダーに反映され、結果が通知される。この一連の流れがつながっていないと、結局どこかで手作業が残る。

今回は、Microsoft 365環境の中で使える仕組みを前提に、休暇申請から承認、カレンダー登録、通知までをできるだけ一つの流れにまとめた。

作成したワークフローの概要

今回作成した休暇申請フローは、次のような流れで動作する。

1. 申請者が登録済みの休暇予定を確認する
2. Microsoft Formsから休暇申請を送信する
3. 承認者へTeamsまたはOutlookで承認依頼を通知する
4. 承認者が申請内容を承認または却下する
5. 承認された休暇を指定のカレンダーへ登録する
6. 申請者へ結果を通知する

申請フォームはMicrosoft Formsで作成し、処理のつなぎ込みはPower Automateで行う構成とした。通知先はTeamsとOutlookのどちらにも対応できるよう整理した。

対応した休暇パターン

複数日にまたがる休暇

申請フォームで開始日と終了日を受け取り、承認後にカレンダーへ一括登録できるようにした。1日ずつ手作業で登録する手間がなくなるだけでなく、共有カレンダー上で見える形にすることで、チームメンバーが後から確認しやすくなる。

時間休

申請フォーム内に時間を記入する欄を設け、カレンダー登録時の予定名や補足情報に反映する想定とした。午前休・午後休・指定時間帯など、運用によって必要な表現は変わるため、要件定義の段階で入力項目と表示内容を調整する前提にした。

承認者への通知

Formsから申請が送信されると、Power Automateが起動し、承認者へ承認依頼を送信する。承認者は、申請者名・休暇日・休暇区分・理由などを確認し、その場で承認または却下できる。

意識したのは、承認者が別の画面を探しに行かなくても判断できることだ。通知が届いても内容が足りなければ、結局Formsの回答や別ファイルを確認する必要が出てくる。そのため、承認画面上に必要な情報をできるだけ集約する構成にした。

承認後のカレンダー登録

承認された申請については、指定されたカレンダーへ休暇予定を登録する。登録先は、部署内の休暇共有カレンダーやチームのOutlook予定表など、運用側で用意してもらう前提とした。

休暇情報は、チームとして確認できる場所に反映されて初めて業務調整に使える情報になる。特に、複数人の休暇予定を確認しながら調整する職場では、カレンダー連携の効果は大きい。

申請者への通知

承認結果は申請者にも通知する。承認時はチームへの共有も兼ねて、チームメンバーへも通知する形を想定した。一方、却下時はチーム全体に共有する必要は薄いため、申請者（または代行申請の場合は代行者）への個別通知とした。承認時と却下時で通知先を分けることで、必要以上に情報を広げない運用にできる。

作ってみて重要だと感じた点

申請フォームだけでは業務改善にならない

Formsで入力を受け付けるだけでは、自動化としては半分しか完結していない。承認者への通知、承認結果の保存、カレンダー登録、申請者への返答、チームへの共有——このあたりまで含めて考えないと、フォームだけ増えて裏側の手作業が残る。

カレンダー登録までつなげると効果が出やすい

休暇申請は、承認されて終わりではない。承認済みの休暇を共有カレンダーへ反映しておけば、後からメールや申請履歴を探す手間が減る。

通知先はTeamsとOutlookのどちらがよいか

どちらが優れているかではなく、現場で普段どちらを見ているかで決める方がよい。Teamsを日常的に使っている組織ではTeams通知の方が見落としにくく、正式な通知や記録性を重視する場合はOutlookメールが扱いやすいこともある。

個別の会社ルールに合わせる必要がある部分

休暇申請は会社ごとのルール差が出やすい。休暇区分の種類、承認者の決め方、却下時の通知先、カレンダーに表示する文言、休暇理由をどこまで共有するかといった点は、事前に確認が必要になる。

特に注意が必要なのは、休暇理由の扱いだ。承認者には見せるとしても、チーム全体に同じ情報を通知してよいとは限らない。承認者向けの情報とチーム共有向けの情報は分けて考える必要がある。

まとめ

休暇申請ワークフローは、申請フォームを作るだけでは完結しない。承認者への通知、承認・却下、カレンダー登録、申請者への結果通知までつながって初めて、現場の手間が減る。

今回の構成では、Microsoft Forms・Power Automate・Teams・Outlook予定表を組み合わせることで、一連の流れを自動化した。大きな業務システムを新しく作らなくても、既存のMicrosoft 365環境を活用しながら比較的小さく始められるのが、この構成の扱いやすさだと感じた。

当時、私は不動産業務についてほとんど知識がありませんでしたが、実際にお客様とWeb会議を

重ねる中で、これまでの知見も生かし、「必要とされる機能を利用しやすい形で」を目指して

お客様と共にシステム化を進めました。

結果として、この案件は1次開発から4次開発まで続き、段階的に改善を重ねる形になりました。

今回は、その流れを振り返ってみます。

なぜExcelから始めたのか

最初に検討したのは、「どこまでシステム化するべきか」でした。

一般的には、最初からWebシステムやクラウドサービスを想像しがちです。

ただ、実際には、

• 利用人数がそこまで多くない
• Excel運用に慣れている
• ITリテラシーに差がある
• まず業務整理が必要

という状況でした。

そのため、最初から大きなシステムを作るのではなく、

「今の業務を壊さずに改善する」

ことを優先し、Excelベースで進めることにしました。

1次開発：まずは業務を理解する

最初の開発では、

• 不動産業者をマスタ管理
• 業者ごとに案内した物件情報を管理
• PDF資料を添付保存

といった基本機能を実装しました。

この時点では、不動産業界特有の業務知識がほとんどありませんでした。

そのため、実装よりも先に、

• どんな流れで業務が進むのか
• 誰が何を見ているのか
• どこで困っているのか

をWeb会議で丁寧に確認することを重視しました。

実際、小規模業務改善では「技術」より「業務理解」の方が重要だと感じています。

2次開発：部署ごとの運用と集計機能

1次開発したツールは、部署ごとに配布して利用する形になりました。

ただ、運用が始まると、

「部署ごとのデータをまとめたい」

という要望が出てきました。

そこで2次開発では、

• 部署ごとのデータをマージする機能
• 成績グラフの自動生成
• VPSサーバーによる共有環境

を追加しました。

特に印象的だったのは、「分析したい」というニーズが徐々に強くなっていったことです。

単に記録するだけでなく、

• どの部署が成果を出しているか
• どの業者との取引が多いか

を見たいという要望が増えていきました。

現場で実際に使われ始めると、必要な機能が具体化していくのを感じました。

3次開発：Accessへの移行

運用が進むにつれて、管理する業者数も増えていきました。

その結果、Excelだけでは扱いづらくなってきたため、データ管理部分をAccessへ移行しました。

ただし、入力画面はExcelを維持しました。

これは、

「利用者の使用感を変えない」

ためです。

もし入力方法まで大きく変えてしまうと、現場負荷が増えてしまいます。

小規模業務改善では、

「技術的に正しいか」

だけでなく、

「現場で使い続けられるか」

が非常に重要だと感じています。

また、2次開発で追加したグラフ機能も強化し、さまざまな軸で実績を確認できるよう改善しました。

ちなみにですが、Accessのライセンスは不要になる点も、この形態とした理由の一つです。

4次開発：OCRへの挑戦

4次開発では、新たにPDFで送られてくる物件情報の電子化に挑戦しました。

Pythonを利用し、OCR処理によって情報を読み取る仕組みを作成しました。

ただ、実際に試してみると、100%正確に読み取ることはできませんでした。

帳票形式の違いや文字品質の問題もあり、完全自動化には限界がありました。

そこで最終的には、

• OCR結果を保存
• 元画像も保存
• 目視確認しやすいUIを用意
• 修正しやすい形にする

という方向へ切り替えました。

「完全自動化」ではなく、

「確認作業を減らす」

方向へ落とし込んだ形です。

今振り返っても、この判断は間違っていなかったと思っています。

小規模業務改善で大事だと感じたこと

この案件を通して感じたのは、

「最初から完璧を目指さない」

ことの重要性でした。

特に小規模事業では、

• 現場に合うか
• 続けられるか
• 壊れないか
• 修正しやすいか

の方が重要になる場面が多いです。

最初から大規模システムを作るのではなく、

• Excelから始める
• 必要に応じて拡張する
• 運用しながら改善する

という進め方は、今でも有効だと感じています。

おわりに

最近はAIや自動化の話題も増えていますが、

実際の現場では、

「どこまで自動化するか」

より、

「どうすれば現場で使い続けられるか」

の方が重要になることも多いです。

この案件は、自分にとっても「業務改善とは何か」を考えるきっかけになった案件でした。

今後も、現場運用を壊さない形の改善を意識していきたいと思っています。