【AI時代の個人開発】2. AI開発を止めないために、最初にGitHub連携を固めた話

AIを使う側から、使いこなす側へ。

※2026年6月30日更新
シリーズを書き進める中で得た気づきを反映し、リード文・構成・文章表現を見直しました。

Replit Agentでアプリを作り、Cursorでコードを直す。

役割分担はできたはずなのに、最初の修正を終えたところで、開発は止まりかけました。

シリーズ1では、ひとつのAIツールにすべてを任せず、それぞれの強みに合わせて役割を分けた経緯を書きました。

Replit Agentでアプリの土台を作り、Cursorでコードを改善する。実際に使い始めるまでは、それだけで開発環境が整うと思っていました。

ところが、それぞれのコードが別々の場所にあります。

どちらが最新で、次はどちらから作業を始めればよいのか。明確な基準がないままでは、せっかくの修正を自分で上書きしかねません。

AIは優秀でも、つながっていなければ、それぞれが孤立した頭脳のままです。

このとき初めて、複数のAIを導入するだけでは足りないと気づきました。必要だったのは、それぞれの成果をひとつの開発フローへ集める仕組みです。

Replit Agentには、アプリの生成から公開まで進めやすい強みがあります。一方のCursorは、既存コードを読み取り、修正案の作成や差分確認、エラー調査まで支援してくれます。

今回の開発では、2つのツールをこのように役割分担しました。

それぞれの強みは異なりますが、扱うコードは同じです。異なる環境が同じコードを共有しながら動くために、その中心へGitHubを置くことにしました。

なぜGitHubが必要だったのか

どちらが最新かわからない状態で開発は止まりかけていたとき、
一番まずいのは「怖くて次の一手が打てなくなる」ことです。

この時点で足りなかったのは、新しいAIツールでも、高度な開発スキルでもありませんでした。

GitHubは、コードを保管するだけの場所として紹介されることがあります。

今回の開発では、Replitでの変更も、Cursorで行った修正も、GitHubへ集めました。

複数のAIツールを直接つなぐのではなく、共通の基準としてGitHubを間に置く。それによって変更の履歴が残り、必要なら以前の状態もたどれる。

この形が、今回つくりたかった開発環境でした。

では、実際にReplit・GitHub・Cursorをつないでいきます。

■ GitHub 連携を構築する

最初に、全体像をシンプルに押さえておきます。

今回つくる流れは、大きく分けて2つです。

Replit
   ↓
GitHub
   ↓
ローカル環境（Cursor）

1. Replit で作ったコードを GitHub へ送る

2. GitHub のコードをPCへ取り込み、Cursor で編集できるようにする

複雑に見えますが、目的はひとつです。

まずは、Replit側から進めます。

1. Replit × GitHub 連携セットアップ

前提

Replit Agentでアプリを生成し、プロジェクトを開ける状態から始めます。

① GitHub でリポジトリを作成する

最初に、コードの置き場所となるリポジトリを用意します。

1. GitHub へログインする

2. 右上の「＋」から「New repository」を選ぶ

3. リポジトリ名を入力する
   例：`my-app`

4. Public または Private を選ぶ

5. READMEなどを追加せず、空の状態で作成する

空のリポジトリにしておくと、Replit側のコードをそのまま送れます。

② Replit で Gitペインを開く

Replitのプロジェクト画面から、Gitを操作するための画面を追加します。

1. 「Tools」を開く

2. 「＋」からツールを追加する

3. 「Git」を選択する

Gitペインでは、変更されたファイルの確認やcommit、GitHubとの同期を画面上で操作できます。

③ GitHub と接続する

Gitペインに表示される「Connect to GitHub」から、GitHubアカウントとの接続を進めます。

画面の案内に沿って認証し、先ほど作成したリポジトリを接続先として指定します。

ここで決めているのは、

という一点です。

④ 変更を commit する

Gitペインに表示されたファイルを確認し、保存する変更をひとまとまりにします。

commitメッセージには、何を保存したのか分かる短い説明を入力します。

Initial commit from Replit

commitは、その時点の変更に名前をつけ、履歴として残す操作です。

⑤ GitHub へ push する

commitが完了したら、Gitペインからpushを実行します。

pushは、Replit内で記録した変更をGitHubへ送る操作です。

処理後にGitHubのリポジトリを開き、Replitで作ったファイルが表示されていれば連携は完了です。

ここまでで、Replitの中だけにあったコードへ、ほかの環境からもアクセスできるようになりました。

次は、このリポジトリをローカルPCへ取り込みます。

2. ローカル環境 × GitHub 連携セットアップ

前提

次の準備が済んでいる状態を想定しています。

• Cursor がインストールされている

• GitHub アカウントを持っている

• ローカルPCに Git がインストールされている

• ターミナルから Git コマンドを実行できる

Gitが使えるかどうかは、次のコマンドで確認できます。

git --version

バージョン番号が表示されれば準備完了です。

このパートの流れも、3つに整理できます。

1. GitHub のコードをPCへコピーする

2. コピーしたフォルダを Cursor で開く

3. 編集した内容を GitHub へ戻す

① GitHub リポジトリのURLを確認する

GitHubで対象のリポジトリを開き、「Code」ボタンからURLをコピーします。

接続方式にはHTTPSとSSHがあります。初回は、ブラウザ認証へ進みやすいHTTPSから始めると流れを追いやすくなります。

② ローカルに作業用フォルダを用意する

PC上に、開発用のフォルダを作成します。

例えば、WindowsでDドライブ直下に`dev`フォルダを作った場合は、ターミナルから次のように移動できます。

cd d:\dev

# bash系の場合は
cd /d/dev

フォルダ名は半角英数字で作り、空白を避けておくと、後の操作で迷いにくくなります。

③ GitHub のコードを clone する

次のコマンドを実行し、GitHub上のコード一式をPCへコピーします。

git clone https://github.com/ユーザー名/リポジトリ名.git

この操作を`clone`と呼びます。

完了すると、現在のフォルダ内にリポジトリと同じ名前のフォルダが作られます。

④ Cursor でフォルダを開く

Cursorを起動し、次の順番でフォルダを開きます。

1. 「File」を選ぶ

2. 「Open Folder」を選ぶ

3. cloneで作成されたフォルダを指定する

これで、GitHubから取得したコードをCursorで編集できるようになりました。

⑤ 接続状態を確認する

Cursorでターミナルを開き、次のコマンドを実行します。

git status

次のように表示されれば、Gitリポジトリとして認識されています。

On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean

ローカル環境の準備は、これで完了です。

3. ローカル環境での開発フロー

環境をつないだ後は、ほぼ同じ流れを繰り返します。

① 作業前に最新のコードを取り込む

Replitなど、別の環境からGitHubへ変更が送られている可能性があります。

作業を始める前に、最新の状態を取り込みます。

git pull origin main

古いコードから作業を始めると、後から変更同士がぶつかりやすくなります。最初に現在地をそろえておくことで、混乱を減らせます。

② Cursor でコードを編集する

Cursorでは、コードを書くことに加えて、次のような支援を受けられます。

• コード全体を踏まえた修正案の作成

• エラー原因の調査

• 変更差分の確認

• 既存実装に合わせた改善

• コミットメッセージの提案

ただし、AIが提案した変更をそのまま採用するのではなく、差分を確認し、意図した修正になっているかを自分でも確かめます。

AIへ任せる範囲が広がるほど、人間には、変更の目的と結果を確認する役割が残ります。

③ 変更を確認する

編集後は、変更されたファイルと差分を確認します。

git status
git diff

CursorのSource Control画面から確認する方法もあります。

④ 変更を commit する

GitHubへ送る変更を登録します。

git add .
git commit -m "変更内容"

例：

git commit -m "Fix login validation logic"

コミットメッセージは日本語でも構いません。後から履歴を見たときに、何を変えたのか分かる表現を残します。

⑤ GitHub へ push する

commitした変更をGitHubへ送ります。

git push origin main

これで、Cursorで行った修正がGitHubへ反映されます。

pushが拒否された場合

Replitなど、別の環境から先に変更が送られていると、pushが拒否される場合があります。

そのときは、先にGitHub側の変更を取り込みます。

git pull --rebase origin main
git push origin main

同じ場所が変更されていた場合は、コンフリクトの解消が必要です。対象ファイルの差分を確認し、残す内容を選んでから統合します。

ここまでで、何が変わったのか

GitHubを中心に置いたことで、ReplitとCursorが同じコードを共有できるようになりました。

Replit
      ↓
GitHub
      ↑
Cursor

Replitで作った変更も、Cursorで改善した変更も、GitHubへ集まります。

2つの環境を無理に直接同期するのではなく、共通の基準点を間に置く。この形ができたことで、次にどのコードから作業を始めればよいのか迷いにくくなりました。

Cursorを使うということ

Cursorは、GitHubと接続するためだけのツールではありません。

GitHubから取得したコードを読み、理解し、改善するための開発環境です。

基本の流れは、次の3つに集約できます。

1. cloneして開く

2. 編集内容を確認する

3. commitしてpushする

Cursorでは複数のAIモデルを選べますが、使えるモデルの数だけが価値ではないと感じています。

新しいAIが登場するたびに開発環境を入れ替えるのではなく、すでにある開発フローの中で、そのAIをどう機能させるかを考える。

環境をつないだことで、ようやくその視点を持てるようになりました。

まとめ

GitHubを中心に置いたことで、Replitはアプリを生成し、動かす場所に、Cursorはコードを読み、改善する場所になりました。

役割の異なるツールが同じコードを共有するようになり、ようやく、自分が開発全体を動かす側に立てた感覚がありました。

AIに任せられる作業が増えても、何を作りたいのか、どの状態を目指すのかは、人間側で考える必要があります。

いまは「使えるプロンプト」を探すよりも、「何をしたいか」をAIとの対話を通じて言語化していく。

その過程に、AIを使いこなすための手がかりがあるのだと思います。

次回は、
「3. Firebase認証を採用して「ログイン地獄」を回避した話」
について書きます。

関連情報

次回：シリーズ３

本記事内の表について

Replit Agent と Cursor の強みを見た目でわかりやすく表現するために「表」を使用しました。この表は、まるしょーさんのChrome拡張機能を使用しています。

前回：シリーズ１

【AI時代の個人開発】シリーズを最初から読む

創作大賞2026の選考期間中は、創作大賞2026 ビジネス部門 応募作品｜AI時代の個人開発 にも全10話をまとめています。