AIにコードを書いてもらうこと自体は、以前よりずっと身近になりました。問い合わせ管理、社内メモ、在庫確認、簡単なWebページ修正なら、CodexのようなAIコーディングエージェントに頼める場面も増えています。
ただし、ここで見落とされやすいのが変更履歴です。
AIが速く直せるほど、意図しない変更も速く入ります。昨日まで動いていた画面が崩れる。別のファイルまで変わる。元に戻したいのに、どこから壊れたか分からない。こうなると、AIで短縮した時間を復旧作業で失います。
だから、AIで業務ツールを作るなら、先にGitとGitHubの最低限を押さえるべきです。開発者っぽい言葉を全部覚える必要はありません。小さな会社がまず覚えるべきなのは、「戻せる」「共有できる」「公開前に見られる」状態を作ることです。
Gitは作業履歴、GitHubは共有とレビューの場所
Gitは、ファイルの変更履歴を管理する仕組みです。公式のGit Bookでも、バージョン管理はファイルの変更を記録し、あとから特定の状態に戻せる仕組みとして説明されています。
中小企業の実務に置き換えると、Gitは「業務ツールの作業履歴」です。
- いつ、どのファイルを変えたか
- 何のために変えたか
- 以前の状態と何が違うか
- 問題が起きたとき、どこへ戻すか
これを残すための仕組みがGitです。
GitHubは、そのGitの履歴をクラウド上で保管し、共有、レビュー、議論、公開前チェックをしやすくする場所です。GitHub公式ドキュメントでも、GitHubはGitリポジトリをホストし、pull requestやコードレビューなどの機能を提供すると説明されています。
つまり、かなり単純化すると次のように考えられます。
| 役割 | 何をするものか | 中小企業での意味 |
|---|---|---|
| Git | 変更履歴を残す | 壊れたときに戻れる |
| GitHub | 履歴をクラウドで共有する | 他の人やAIが確認できる |
| Pull request | 変更を本番側へ入れる前に見せる | 公開前レビューの箱 |
「GitHubは難しいから後でいい」と考えると、AIコーディングは危なくなります。むしろ、AIに直してもらうからこそ、GitHubで差分を見られる状態が必要です。
最初に覚える用語はこの5つでよい
最初から細かいコマンドを暗記しなくても構いません。まずは次の5つを、業務フローとして覚える方が実用的です。
| 用語 | ざっくりした意味 | AI開発での使いどころ |
|---|---|---|
| branch | 作業場所を分ける | 本番に影響させず試す |
| commit | 変更の記録を残す | 戻れる区切りを作る |
| push | GitHubへ送る | ローカルPCだけに閉じない |
| pull request | 変更を取り込む前に見せる | 人間が差分を確認する |
| pull | GitHub側の最新を取り込む | 手元の作業を古くしない |
特に重要なのは、branchとcommitです。
GitHub公式ドキュメントでは、branchは他のbranchに影響させず作業するための分離された場所として説明されています。AIに修正を頼むときも、いきなりmain branchを触らせるのではなく、作業用branchで試す方が安全です。
commitは、作業の区切りです。ひとつの機能を直した、文言を変更した、エラーを修正した。そうした単位でcommitを残しておくと、あとから差分を見やすくなります。
AIに頼むときも、「作業後に差分を説明して、問題なければcommit候補を作って」と依頼すると、人間が確認しやすくなります。
AIコーディングで壊れやすいのは、コードではなく運用
AIコーディングでよく起きる失敗は、「AIがコードを書けない」ことではありません。むしろ、動くものは意外と速く出てきます。
問題になりやすいのは、次のような運用です。
- 何を変えたか記録していない
- 作業前にbranchを切っていない
- commitが大きすぎてレビューできない
- pushしておらず、PC内だけに履歴がある
- pull requestを作らず、そのまま本番反映してしまう
- conflictが出たとき、AI任せで判断してしまう
GitHub公式ドキュメントでは、pull requestは変更を提案し、reviewして、mergeするための機能として説明されています。AIが作った変更も同じです。AIが書いたから特別扱いするのではなく、人間が差分を見てから取り込む流れに乗せます。
conflictも怖がりすぎる必要はありません。GitHub公式ドキュメントでは、merge conflictは競合するcommitがあり、Gitがどちらの変更を採用するか判断を必要とする状態として説明されています。つまり、conflictは「壊れた」というより、「人間の判断が必要」という合図です。
小さな会社では、この合図を無視しないことが大切です。
小さな会社の最低限フロー
AIで業務ツールを直すときは、まず次の流れで十分です。
- 作業前にGitHubへ最新状態をpushしておく
- 修正用のbranchを作る
- AIに、変更してよい範囲を明確に伝える
- AIが作業したら、差分を確認する
- 小さな単位でcommitする
- GitHubへpushする
- pull requestを作る
- 人間が表示、文言、機能、秘密情報の混入を確認する
- 問題がなければmainへ取り込む
この流れにすると、AIは「勝手に本番を変える存在」ではなく、「レビューできる変更案を作る担当」になります。
Codexの公式ドキュメントでも、ローカルで動くコーディングエージェントとしてCLIが説明され、サンドボックスや承認設定によって操作範囲を制御する考え方が示されています。AIを実行役として使うなら、Git/GitHubの履歴とあわせて、人間が止められる場所を作る必要があります。
最初から完璧な開発体制を作る必要はありません。ただし、次の3つは早めに決めておくべきです。
- main branchを直接触らない
- 作業ごとにbranchとcommitを分ける
- pull requestなしで公開しない
これだけでも、AIコーディングの事故はかなり見つけやすくなります。
Optiensの見方
Optiensでは、AI導入を「ツールを入れること」ではなく、業務の判断と確認の流れを設計することとして扱っています。
AIで小さな業務ツールを作る場合も、最初に見るべきはモデル名ではありません。変更履歴、秘密情報の置き場所、レビュー担当、公開前チェック、失敗したときの戻し方です。
Git/GitHubは、非エンジニアには少し取っつきにくい道具です。それでも、AIにファイルを編集させるなら避けて通れません。むしろ、ここを覚えると、AIに任せられる仕事の幅が広がります。
AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断簡易版（無料） で、既存業務のどこがAIパッケージ化しやすいかをご確認ください。より具体的に整理したい場合は、詳細版AI活用診断（¥5,500税込・MTGなし） で、AIパッケージ適合性、構成案、優先順位、費用前提を整理してお届けします。
まとめ
AIコーディングを始めるとき、最初に覚えるべきなのは高度なプログラミングではありません。
まずは、Gitで変更履歴を残す。GitHubで共有する。branchで作業場所を分ける。commitで戻れる区切りを作る。pushでクラウドへ送り、pull requestで人間が確認してから取り込む。
この基本があるだけで、AIに頼める仕事は増えます。反対に、この基本がないままAIに作業を広げると、速く作れるほど速く壊れます。
AI時代の開発入門は、コードを書く前に「戻せる状態」を作るところから始めましょう。