AIに「この機能を追加してください」と伝えるだけで、アプリのコードが生成される時代になりました。

Google AI StudioのBuildモードでも、自然言語からアプリを構築し、GitHubへプロジェクトを出力したり、既存のGitHubプロジェクトを読み込んだりできます。Googleの公式ドキュメントでも、AI StudioとGitHubを連携し、プロジェクトをリポジトリへ出力して変更をcommitできることが案内されています。

そこで、非エンジニアの方ほど疑問に感じるのが次の点ではないでしょうか。

「AIがコードを書いてくれるなら、GitHubまで覚える必要はないのでは？」

私自身、非エンジニアとしてAIと会話しながらアプリを作っていく中で、最初はGitHubを「コードを保存しておく場所」くらいに考えていました。

しかし、開発を続けていくと考え方が変わりました。

AIがコードを書いてくれるからGitHubが不要なのではありません。AIが人間よりはるかに速い速度で、多くのファイルを書き換えるからこそ、GitHubが必要になるのです。

GitHubの重要な役割は、単なるファイル保管ではありません。

「どの時点で、何を変更したのか」を正式な履歴として残し、問題が起きたときに正常だった地点を特定できることです。

この記事では、GitHubの高度な使い方やエンジニア向けのコマンドを網羅的には説明しません。

非エンジニアがAIでアプリを作るなら、まず覚えたいのは次の6つです。

• repository
• main
• commit
• push
• SHA
• diff

この6つの意味が分かるだけでも、AIアプリ開発における「今どの状態なのか」「どこで壊れたのか」「どこまで戻ればよいのか」が格段に見えやすくなります。

AI開発でGitHubが必要になる本当の理由

GitHubは単なるコードの保管庫ではない

GitHubを初めて使う人は、「Googleドライブのコード版のようなもの」と理解しがちです。もちろん、GitHub上にプロジェクトのファイルを保存できるという意味では、完全な間違いではありません。

ただし、それだけであればAI開発におけるGitHubの価値の一部しか見えていません。GitHubで重要なのは、ファイルそのものだけではなく、そのファイルがどう変化してきたかという履歴を管理できることです。

例えば、ある業務アプリを作っていたとします。最初は「顧客情報を入力する」「診断結果を表示する」というシンプルなアプリだったとします。

• PDF生成
• メール送信
• データ保存
• 管理画面
• ログイン機能

このように少しずつ機能を追加していったとき、最終的なファイルだけを保存している場合、途中で問題が起きると困ります。

「PDFまでは正常だった」「メール送信を追加した後からおかしくなった気がする」「管理画面を修正したら、なぜか診断結果まで表示されなくなった」といった状態になったとき、完成ファイルしかなければ、過去と現在を比較することが難しくなります。

GitHubで変更履歴を残していれば、「どこまで正常だったのか」をたどれるようになります。

重要なのは「いつ・何を変更したか」が残ること

AI開発では、完成したコードだけを見るのではなく、「変更の履歴を見る」という発想が重要です。例えば、次のような履歴が残っていたとします。

この履歴があれば、少なくとも「3の時点までは動いていた」「4の変更以降に問題が発生した」と考えられます。原因が必ず4の変更だけにあるとは限りませんが、何も履歴がない状態に比べれば、調査範囲を大きく絞れます。

GitHubではcommitごとに変更内容を確認でき、ファイル単位のdiffも確認できます。これがAI開発で非常に重要です。

正常に動いていた時点が「復旧地点」になる

非エンジニア向けには、commitをゲームの「セーブポイント」と考えると分かりやすいでしょう。ボス戦へ進む前にセーブしておけば、失敗してもその地点からやり直せます。AI開発も似ています。

大きな修正をAIへ依頼する前に、「ここまでは正常」という状態をcommitとして残しておけば、その時点を基準にできます。

重要なのは、「AIに元に戻してもらえばいい」と考えないことです。AIに「さっきの変更を全部元に戻して」とお願いしても、そのAIが過去のファイル状態を完全に再現できるとは限りません。

しかしGitの履歴としてcommitが存在すれば、過去の状態は推測ではなく、特定できる履歴として残ります。つまりGitHubは、単なる保管場所ではなく、AI開発の公式な履歴台帳のような役割を持つのです。

AIが大量にコードを書くほど「どこで壊れたか」が分からなくなる

人間なら1ファイルでもAIは複数ファイルを一度に変更する

AIを使ったアプリ開発で特に注意したいのが、修正速度です。例えば人間の初心者が「ボタンの色を変えたい」と考えた場合、該当するファイルを探し、少し変更して確認するでしょう。

一方、AIに「もっと使いやすい画面にしてください」と依頼すると、指示内容によっては複数のファイルに変更が入ることがあります。

• コンポーネント
• 処理ロジック
• スタイル
• データの受け渡し
• 関連設定

AIの強みは、こうした変更を短時間で実行できることです。しかし、それは同時に「人間が変更内容を追い切れなくなる」という新しいリスクを生みます。

特にコードを読めない非エンジニアの場合、「画面は少し変わっただけに見えるのに、裏では何ファイル変わったのか分からない」という状態になりやすいのです。

「さっきまでは動いていた」が一番困る

AI開発をしていると、非常に困る言葉があります。それが「さっきまでは動いていた」です。

例えば「診断結果をPDFで保存できるようになった。次はメールでも送れるようにしよう」とAIへ依頼したとします。メール送信はうまくいった。ところが、よく見るとPDFのファイル名がおかしくなっている。それを直してもらったら、今度は診断結果画面が表示されなくなった。さらに修正を依頼すると、メール送信まで動かなくなった。

こうなると、人間側の頭の中では「どこから壊れたのか」が分からなくなります。その状態で「まだ直りません」「そこではありません」「さっきまで動いていた状態に戻してください」とAIへ次々に追加指示をすると、さらに変更が重なります。

結果として、修正のための修正が増え、原因がさらに見えなくなることがあります。

commitを比較すれば問題発生地点を絞れる

ここでGitHubの履歴が役立ちます。例えば「commit A：正常」「commit B：正常」「commit C：不具合発生」となっていれば、「BからCの間で何が変わったか」を確認すればよいと考えられます。

非エンジニアがすべてのコードを理解する必要はありません。重要なのは、調査範囲を狭くできることです。

AIへ相談するときも、「アプリが壊れました。直してください」より、「このcommitまでは正常でした。この次のcommitから問題が発生しています。この2つのdiffを確認して原因を調べてください」と伝えられる方が、はるかに具体的です。AIを使う側にも、問題を切り分ける力が必要になってくるのです。

非エンジニアならGitHubは6つの用語だけ覚えればいい

GitHubには非常に多くの機能があります。branch、merge、pull request、clone、fork、tagなど、調べ始めると次々に専門用語が出てきます。そのため非エンジニアが「やっぱりGitHubは難しい」と感じてしまうのも無理はありません。

しかし、AIを使って自分のアプリを作り始めた段階で、すべてを覚える必要はありません。まずは次の6つから始めれば十分です。

repository｜アプリ一式を管理する箱

repository（リポジトリ）は、簡単にいえば、一つのアプリやプロジェクトをまとめて管理する箱です。中には、アプリを構成する各種ファイルと、それらがどう変更されてきたかという履歴が入ります。

Google AI StudioもGitHubとの連携に対応しており、作成したプロジェクトをGitHub repositoryへ出力したり、既存repositoryを読み込んだりできます。非エンジニアの場合は、「このrepositoryが、このアプリ一式の正式な管理場所」と理解するところから始めるとよいでしょう。

main｜正式版として扱う基準

GitHubではbranchという仕組みがあります。branchとは、開発の流れを分けて管理する仕組みです。ただし初心者の段階では、まずmainを理解すれば十分です。

非エンジニア向けには、main＝現在の正式版として扱う基準、くらいの理解から始めると分かりやすいでしょう。将来的に複数人で開発したり、本格的な開発フローを組んだりするとbranchの理解が重要になりますが、自分とAIで試作を進める段階では「mainに何が入っているのか」を意識できるだけでも大きな進歩です。

commit｜その時点を保存するセーブポイント

commitは最も重要な用語です。簡単にいえば、その時点の変更を履歴として記録することです。

例えば、「PDF生成機能が完成し、正常に動くことを確認した」とします。この時点でcommitしておけば、「PDF生成までは正常だった地点」として履歴を残せます。その後、メール送信を追加して問題が起きても、正常だった地点が明確です。

つまりcommitとは、AI開発におけるセーブポイントと考えると理解しやすいでしょう。ただし、単なるファイルコピーとの違いとして、「どの変更を行ったか」という履歴を追えることが重要です。

push｜変更履歴をGitHubへ送る

commitしただけでは、利用している開発環境によっては、その履歴が手元側に存在しているだけの場合があります。そこで使うのがpushです。

pushは、作成したcommitをGitHubなどのremote repositoryへ送る操作です。非エンジニア向けには、commit＝セーブする、push＝そのセーブデータをGitHubへ送る、と理解すると分かりやすいでしょう。

SHA｜その時点を特定できる「住所」

ここは、AI開発を続けるうえでぜひ理解してほしいポイントです。Gitでは各commitに固有のIDが割り当てられます。

非エンジニア向けには、SHA＝そのcommitの住所、と考えると分かりやすいです。例えば「昨日の正常だった状態」と言われても曖昧です。昨日は何回もAIへ修正をお願いしていたかもしれません。

しかしSHAが分かれば、「どのcommitを指しているのか」を明確にできます。住所を指定すれば場所が特定できるように、SHAを指定すると特定のcommitを指し示せるわけです。

diff｜前回から何が変わったかを見る

diffは、2つの状態の違いを見ることです。例えば、正常だったcommitと問題が出たcommitを比較すれば、「その間に何が変わったのか」を見ることができます。

非エンジニアがdiffのコードをすべて読めなくても問題ありません。例えば、「メール送信だけを変えたつもりなのに、診断ロジックのファイルまで変更されている」と分かれば、それだけでも重要な手掛かりです。

そしてAIに「このdiffを見て、メール送信以外に変更された部分が不具合の原因になっていないか確認してください」と依頼できます。つまりdiffは、人間が全部コードを読むためだけのものではなく、AIへ問題調査を依頼するときの材料としても役立つのです。

commitとSHAを理解するとAI開発の見え方が変わる

「最新です」ではなく「どのSHAですか？」で考える

AI開発を進めていると、よく「最新版です」という言葉を使います。しかし、開発が複数環境にまたがると「最新」という言葉は意外と危険です。

例えば、AI Studio上のプロジェクト、GitHubのmain、本番公開されているアプリがあるとします。人間の感覚では、すべて最新版のつもりでも、本当に同じ状態とは限りません。

AI Studioでは変更済みでも、まだGitHubへ反映していないかもしれません。GitHubは更新済みでも、その内容を使った本番デプロイが終わっていないかもしれません。

こうしたときに重要なのが、「最新かどうか」ではなく、「どの時点のものか」という考え方です。Git側ではcommitをSHAで特定できます。この考え方を持つだけでも、環境間の食い違いを整理しやすくなります。

SHAはアプリの「その時点の住所」

私自身、AI Studio・GitHub・Cloud Runを使ってアプリを作っていく中で、この考え方が非常に重要だと感じました。

例えば、「AI Studioでは直っているのに、公開したアプリでは直っていない」という状況があったとします。ここで「なぜ反映されないのだろう」と何度もコードを修正してしまうと、問題をさらに複雑にしてしまいます。

本当の問題はコードではなく、見ているバージョンが違うだけかもしれないからです。

実務では、「GitHubではどのcommitか」「本番側ではどのrevisionが動いているか」「そのrevisionがどのソースを基にしたものか」を照合していく考え方が重要になります。

ここで注意したいのは、Gitのcommit SHAとCloud Runのrevision名が、そのまま同じ値になるという意味ではありません。それぞれ別の識別情報です。

大切なのは、GitHub側のcommit SHAなどを基準に、「この本番環境はどのソースから作られたのか」を追える状態にしておくことです。

AI Studioでは直ったのに本番で直らない理由を切り分けやすくなる

アプリの問題は、大きく分けると次のような複数の可能性があります。

1. コードそのものに問題がある
2. 正しいコードが本番へ反映されていない
3. 本番側の設定や環境に問題がある

そのため、「本番がおかしい＝コードをさらに書き換える」と短絡的に考えないことが重要です。

まず、「開発環境はどの時点か」「GitHubはどのcommitか」「本番はどのrevisionか」を見ます。これだけでも、コードを直すべき問題なのか、反映状況を確認すべき問題なのかを切り分けやすくなります。

GitHubなしでAI開発を続けると何が起こる？

どの時点が正常だったのか分からなくなる

AI開発で一番避けたいのは、「完成間近だったのに、どこまで戻ればいいか分からない」という状態です。変更履歴を残していなければ、正常だった時点が曖昧になります。

「昨日は動いていた」「3回前の修正までは大丈夫だった気がする」という人間の記憶に頼るしかなくなります。しかし、AIは短時間に何度も修正できます。人間側が「3回前」と思っていても、その間に多くのファイルが変更されている可能性もあります。だからこそ、記憶ではなく履歴が必要なのです。

AIへ「元に戻して」と頼んでも完全には戻らない可能性がある

生成AIは非常に便利ですが、正式なバージョン管理システムそのものではありません。

例えば「昨日の午前中の状態に完全に戻してください」と依頼しても、その時点の正確な全ファイルが履歴として残されていなければ、AIは会話内容や現在のコードから推測して戻すことになります。それでは「完全に同じ状態」とは限りません。

一方、commitという正式な履歴が残っていれば、「このcommitの状態」という明確な基準を持てます。ここが大きな違いです。

修正するほど別の場所が壊れるループに入りやすい

履歴がない状態で、修正→別の問題発生→追加修正→さらに別の問題発生、という状態になると危険です。

このとき必要なのは、さらにAIへコードを書かせることではありません。一度「どこまでは正常だったのか」を確定し、正常だった時点から何が変わったのかを見る必要があります。そのための基準になるのがcommitとdiffです。

AI開発では「小さく変更してcommitする」が安全

GitHubを導入しただけで、AI開発が自動的に安全になるわけではありません。大切なのは使い方です。特におすすめしたい考え方が、「小さく変更し、正常ならcommitする」という習慣です。

一度に大量の変更を依頼しない

例えばAIへ、「管理画面を追加して、デザインも変更して、メール送信も直して、PDFもきれいにして、スマホ対応もしてください」と一度に頼んだとします。AIは対応できるかもしれませんが、何か一つ問題が起きたとき、どの変更が原因なのか分かりにくくなります。

できれば「管理画面を追加→動作確認→commit→デザイン変更→動作確認→commit→メール送信修正→動作確認→commit」というように分けます。この方が遠回りに見えて、結果的には安全です。

動作確認できたらcommitする

commitのタイミングは、「作業をしたら毎回」と機械的に考える必要はありません。おすすめは、一つの意味のある変更が終わり、正常に動くことを確認した時点です。

例えば、顧客入力画面完成、診断ロジック完成、PDF生成完成、メール送信完成、管理画面完成というように、区切りのよい地点で残します。すると後から履歴を見ても分かりやすくなります。

次の修正前に正常地点を残す

特に重要なのが、大きな変更を始める直前です。例えば「ここまで完璧に動いている。次はログイン機能を追加しよう」というときは、ログイン機能を追加する前に正常な状態をcommitしておきます。

すると最悪の場合でも、「ログイン追加前」という明確な地点があります。AIによる大きな修正ほど、先にセーブポイントを作っておくのです。

問題が出たらdiffと直前のcommitを見る

不具合が発生したときに、「直して」とすぐAIへ依頼するのではなく、まず「最後に正常だったcommitはどれか」「そこから現在まで何が変更されたか」の2点を確認します。

この2つが分かれば、AIにもかなり具体的な調査を依頼できます。

非エンジニア向けAI開発の安全な7ステップ

STEP1　現在の正常な状態を確認する

最初にアプリを一通り操作します。最低でも、主要画面が開く、入力できる、保存できる、結果が表示される、主要機能が正常に動くなど、今回の変更と関係する部分を確認します。

STEP2　commitを残す

正常であることを確認した状態をcommitします。ここが今回のセーブポイントです。commitの説明も「修正」だけではなく、「PDF生成機能の正常動作確認済み」など、後から意味が分かる内容にすると便利です。

STEP3　AIへ一つの変更を依頼する

次にAIへ変更を依頼します。このときは、一度に多くを頼みすぎません。例えば「診断結果PDFに会社名を追加する」くらいの一つの目的に絞ります。

STEP4　動作を確認する

AIが「修正しました」と回答しても、それだけで完了ではありません。実際のアプリを操作して確認します。そして、変更した部分だけではなく、関連する主要機能も確認します。

STEP5　diffで変更内容を見る

次に「AIが何を変えたのか」を確認します。コードを完全に理解できなくても、変更されたファイル数、想定外のファイルが変更されていないか、大量に削除されていないかなどを見るだけでも意味があります。

STEP6　問題なければcommit・pushする

動作に問題がなければ、その変更をcommitします。必要に応じてGitHub側へpushします。これで新しい正常地点ができます。

STEP7　公開後にバージョンを確認する

本番環境へ公開したら「公開できたから終わり」にしません。GitHub側ではどのcommitを基準にしたのか、本番側ではどのrevisionが稼働しているのか、可能であればそのrevisionがどのsourceを基に作られたかを照合します。この習慣が「開発画面では直っているのに本番では直っていない」という問題を切り分ける助けになります。

GitHubを使っていても注意したいこと

commitしていなければ復旧地点にはならない

GitHubと接続したから安心、と考えるのは危険です。重要なのは、正常な時点を履歴として残しているかです。変更を大量に続けた後で一度だけcommitしても、途中の正常地点が残っていなければ、問題の切り分けは難しくなります。

変更をまとめすぎると原因を特定しにくい

一つのcommitで、ログイン追加、PDF変更、デザイン変更、メール修正、データベース変更まで行ってしまうと、問題が出たときの調査範囲が大きくなります。変更の目的を小さく区切ることは、AI開発における重要な安全策です。

AIの変更内容をすべて信用しない

AIが「指定された部分だけ修正しました」と回答したとしても、最終的には人間側で確認する必要があります。コードが読めない場合でも、変更ファイル、diff、実際の動作の3点は確認できます。AIへコードを書かせることと、人間が確認責任まで手放すことは別です。

mainへ反映されたことと本番公開は別問題

ここも非エンジニアが混乱しやすい部分です。GitHubのmainが最新になったからといって、必ずしもその瞬間に本番環境も同じ状態になるわけではありません。

したがって、GitHubの状態と実際にユーザーが見ている本番環境は分けて確認する必要があります。

GitHub AI開発でよくある質問

GitHubはプログラミングできなくても使えますか？

はい。少なくともAI開発で変更履歴を管理する目的であれば、最初から高度なGit操作をすべて覚える必要はありません。まずはrepository、main、commit、push、SHA、diffの6つを理解し、「正常だった時点を残す」「何が変わったかを見る」ことから始めるとよいでしょう。

AIが全部コードを書いてくれるならGitHubは不要ではありませんか？

むしろ逆です。AIが短時間で多くのコードや複数ファイルを変更できるからこそ、人間が変更を追えなくなるリスクがあります。そのため、「どの時点で何を変えたか」という正式な履歴の重要性が高まります。AIが書くからGitHubが不要なのではなく、AIが大量に書き換えるからGitHubが必要になる、と考えると分かりやすいでしょう。

commitとバックアップは何が違いますか？

バックアップは、ある時点のファイルを別の場所へ保管しておく考え方です。一方commitは、プロジェクトの変更を履歴として記録し、どの変更が行われたかをたどれる点が重要です。AI開発では、単に昔のファイルが残っていること以上に、変更の流れを追えることに価値があります。

SHAは覚える必要がありますか？

SHAの文字列そのものを暗記する必要はありません。大切なのは、「一つひとつのcommitには、その時点を特定できる固有IDがある」と理解することです。問題が起きたときに、「昨日の状態」ではなく、「このSHAのcommit」と特定できることが重要です。

毎回commitしたほうがよいですか？

細かな操作のたびにcommitする必要はありません。おすすめは、「意味のある変更が一つ終わり、正常動作を確認できた時点」です。また、大きな機能追加の直前にもcommitしておくと、安全な復旧地点を確保できます。

まとめ｜AIが大量に書き換えるからこそGitHubが必要

AIによって、アプリ開発のハードルは大きく下がりました。以前であればプログラミングを学ばなければ作れなかったものでも、今ではAIと会話しながら試作できるケースが増えています。

しかし、AIがコードを書いてくれるようになったことで、別の問題が生まれました。それが「人間が変更内容を追い切れない」という問題です。

一つの修正依頼で複数のファイルが変わり、短時間に何度も改修できるため、「どこまで正常だったのか」「どの変更から問題が起きたのか」が分からなくなりやすくなります。

そこで重要になるのがGitHubです。GitHubを単なるコード保管庫として考えるのではなく、正式な変更履歴と復旧地点を残す仕組みとして使います。

正常確認 → commit → AIへ一つだけ変更依頼 → 動作確認 → diff確認 → commit・push → 本番確認

• repository＝アプリを管理する箱
• main＝正式版の基準
• commit＝セーブポイント
• push＝GitHubへ履歴を送る
• SHA＝その時点の住所
• diff＝何が変わったかを見る

AI開発で必要なのは、AIにすべて任せることではありません。AIには高速にコードを書いてもらい、人間は「どこが正常地点なのか、どの変更を採用するのか、何を本番へ出すのか」を管理する。この役割分担ができると、非エンジニアでもAIを使ったアプリ開発を安全に前へ進めやすくなります。

AIを使えば、非エンジニアでもアプリの試作まで進められる時代になりました。

一方で、本番運用では、変更履歴だけでなく、データ管理、アクセス権限、セキュリティ、障害時の復旧、保守など、試作段階とは異なる視点も必要になります。

「AIでここまでは作れたが、このまま自分で進めても大丈夫なのか」「どこまでAIで作り、どこから開発会社や専門家へ任せればよいのか」「自社業務で実際に使えるアプリにするには何を整理すべきか」と迷っている場合は、現在の試作品と実現したい業務を整理したうえでご相談ください。

現在できている機能、今後追加したい機能、実際に利用する人、困っている点などを整理すると、次に何をすべきか判断しやすくなります。

AI・アプリ開発について相談する

参考情報（公式）

• Google AI Studio Build mode：https://ai.google.dev/gemini-api/docs/aistudio-build-mode
• GitHub Docs：Commits：https://docs.github.com/en/pull-requests/reference/commits
• GitHub Docs：Comparing commits：https://docs.github.com/en/pull-requests/committing-changes-to-your-project/viewing-and-comparing-commits/comparing-commits
• GitHub Docs：Pushing commits：https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository
• Google Cloud：Cloud Run revisions：https://cloud.google.com/run/docs/managing/revisions
• Google Cloud：Rollouts and rollbacks：https://cloud.google.com/run/docs/rollouts-rollbacks-traffic-migration