社内のみんなで、同じアプリを共同開発する
手元の Excel や Word を渡して、「このファイルをアプリにしてよ」と頼むだけ。プログラムは書きません。AI に日本語で頼みます。

「3人がそれぞれ AI でアプリを作れるようになった。次は、同じアプリをみんなで育てたい」。
面談でこの言葉が出たら、その会社はもう独学の段階を抜けています。そして、ほぼ必ずここで止まります。
止まる理由は、技術ではありません。AI の契約をチームにしても、3人のパソコンの中のアプリはつながらないからです。
席(アカウント)がまとまるだけで、作ったものは、作った人のパソコンに入ったままです。つなぐ役は GitHub です。
箱と履歴と倉庫の話は「リポジトリ・Git・GitHub の違い」に書きました。このページはその続きで、倉庫を、複数人で使う話です。
本線(main)は直接触らない。枝で作って、誰かが見てから、本線に合流させる。 人が覚えるのはこれだけで、あとは AI がやります。
逆張り:ファイルを送り合うほど、壊れます
共同開発と聞いて最初に思いつくのは、zip で送る・共有ドライブに置く、です。これが一番壊れます。
| やり方 | 起きること |
|---|---|
| zip やメールで送り合う | どれが最新か、誰にも分からなくなる |
| 共有ドライブに置いて、みんなで開く | 後から保存した人が、前の人の変更を黙って消す |
| 作った人だけが直す | その人が休むと止まる。属人化がアプリに移っただけ |
| GitHub に正本を1つ置く | 誰が・いつ・何を変えたかが全部残り、ぶつかった場所も分かる |
共有ドライブ(Google ドライブ・OneDrive)を倉庫にしてはいけない理由は、前のページのとおりです。履歴のファイルが同期と喧嘩して壊れます。
因数分解:場所は3つ、言葉は8つ
置き場所は3段です。下で作り、真ん中に正本を置き、上で動かします。
| 段 | 場所 | 役割 |
|---|---|---|
| 上 | Cloudflare | 動いているアプリ(本番)。利用者が URL で開く |
| 中 | GitHub | コードの正本。3人が共有する1つ |
| 下 | それぞれのパソコン | AI が作業する場所。人数分ある |
GitHub は設計図の正本、Cloudflare は動いている本番です。GitHub に置いただけでは、利用者は使えません。
言葉は8つ出てきますが、全部 AI が使う言葉です。意味だけ分かれば足ります。
| 言葉 | 何をするか | たとえると |
|---|---|---|
| clone(クローン) | 正本を丸ごと手元に持ってくる。最初の1回 | 台帳の写しをもらう |
| pull(プル) | 他の人の変更を手元に取り込む。毎回、作業の前 | 写しを最新にする |
| commit(コミット) | 変更を記録する。この時点ではまだ手元だけ | 作業日報を書く |
| push(プッシュ) | 手元の記録を GitHub に届ける | 日報を提出する |
| branch(ブランチ) | 本線から分けた、作業用の枝 | 下書き用の別紙 |
| pull request(プルリクエスト) | 枝を本線に入れてよいか、他の人に確認を頼む | 回覧・承認 |
| merge(マージ) | 枝を本線に合流させる | 下書きを台帳に清書する |
| fork(フォーク) | リポジトリを自分のアカウントに丸ごと写す | よその台帳を複製して自社用にする |
フォークは、社内の共同開発では使いません。 書き込む権限のない、他人のリポジトリを元にするときの手段です。同じ会社の3人は、同じリポジトリに招待すれば済みます。
1回の作業は、いつもこの順番です。
| 順 | すること | 誰がやるか |
|---|---|---|
| 1 | 最新を取り込む(pull) | AI |
| 2 | 枝を作る(branch) | AI |
| 3 | 直す | AI(頼むのは人) |
| 4 | 記録して届ける(commit・push) | AI |
| 5 | 確認を頼む(pull request) | AI |
| 6 | 見て、合流させる(merge) | 作った人以外の1人 |
人の仕事は、頼むことと、6番で見ることだけです。

実例
ある設備工事の会社で、3人がそれぞれ AI でアプリを作っていました。どれも1人で作り、1人のパソコンの中にあります。
「これを社内のみんなで育てたい」と相談を受けて、その場で勧めたことは4つだけです。
- リポジトリの持ち主は、個人ではなく会社にする(担当者が替わっても残る)
- 本線は直接触らず、枝で作って、作った人以外の1人が見てから合流させる
- 公開は、本線に合流したときに自動で行う(各自のパソコンから直接公開しない)
- 鍵(API キーなど)は GitHub に入れず、Cloudflare の側に登録する
この4つを作業ルールのファイル(CLAUDE.md)に書いて、リポジトリに入れておきます。誰の AI が開いても、同じルールで動きます。 人に覚えさせるのではなく、箱の中に書いておく。ここが要です。
事故は2つしかありません。取り込みを忘れて古い状態から作り始めることと、記録しただけで届けていないこと。どちらも、ルールのファイルに書いておけば AI が自分でやります。
公開は、入口を1本にする
3人がそれぞれのパソコンから公開すると、GitHub の正本と、動いている本番の中身がずれます。誰の版が出ているのか、誰にも分からなくなります。
| 決めること | こうする | 理由 |
|---|---|---|
| 公開の入口 | GitHub の本線だけ。合流したら自動で公開 | 「確認を通ったものだけが本番に出る」状態になる |
| Cloudflare のアカウント | 会社のものを1つ。3人をメンバーに招待 | 個人のアカウントに本番があると、その人が抜けたら止まる |
| 鍵 | Cloudflare に登録。GitHub には入れない | GitHub に入れると、招待した全員と履歴に残る |
| データベース | 本番は1つを共有。試すときは手元用 | 試しで本番のデータを壊さない |
データをみんなで見る仕組みは「D1・R2・KV でできること」、鍵の考え方は「セキュリティについて」にあります。
問い
そのアプリは、作った人が明日いなくなっても、直せますか?
直せないなら、アプリを作ったのではなく、新しい属人化を作っています。
確かめ方は簡単です。別の人のパソコンで、AI に「このアプリの続きを直して」と頼んでみてください。
利益と回収
- 作った人が休んでも、辞めても、止まらない
- 「誰が何を変えたか」で揉めない。全部残っている
- 壊しても、合流の前なら本番に出ない。出た後でも前の版に戻せる
- 新しい人には、招待を1回送るだけ。引き継ぎ資料が要らない
費用は増えません。GitHub の非公開リポジトリは、会社(Organization)でも無料で作れます。
回収は、最初の「あの人がいないと直せない」が1回消えた時点で終わっています。
頼み方
① アプリを作った人が、そのアプリの作業フォルダで貼る(アプリごとに1回)
このフォルダのアプリを、GitHub の非公開リポジトリにして、複数人で共同開発できる状態にして。 進め方 1. Git と GitHub の準備ができているか確認する。足りなければ、手順を1つずつ案内する 2. コミットする前に、フォルダの中を点検する。パスワード・APIキー・.env・顧客の実データがあれば、GitHub に上げない設定にして、何を除外したかを報告する 3. 非公開リポジトリを作って push する。作成先(会社の Organization か、自分の個人アカウントか)とリポジトリ名は、作る前に私に確認する 4. README.md に、このアプリが何か・動かし方・必要な設定を書く 5. CLAUDE.md に、次の共同開発ルールを書く(すでにあれば追記する) - 作業を始める前に、必ず最新を取り込む - main に直接 push しない。作業ごとにブランチを作り、プルリクエストを出す - プルリクエストは、作った本人以外の1人が確認してからマージする - 作業の区切りでコミットして push する。手元だけに残さない - 仕様を決めた・変えたときは docs/DECISIONS.md に「何を採用し、何を捨てたか、その理由」を追記する - 鍵・パスワード・顧客の実データはコミットしない 6. 一緒に開発する人の GitHub ユーザー名を私に聞き、共同編集者として招待する 7. 最後に、リポジトリの URL・除外したファイル・残っている作業を報告する 元に戻せない操作(公開設定の変更、ファイルの削除、履歴の書き換え)は、実行前に必ず私に確認して
② 一緒に開発する人が貼る(アプリごとに1回。〇〇は、①の最後に出たリポジトリの URL)
〇〇 の共同開発に参加します。準備をして。 1. Git と GitHub の準備ができているか確認する。足りなければ、手順を1つずつ案内する 2. リポジトリへの招待が届いているか確認し、承諾の仕方を案内する 3. 置き場所を私に確認してから、リポジトリを手元に持ってくる 4. README.md・CLAUDE.md・docs/DECISIONS.md を読み、このアプリの概要と共同開発ルールを3行で説明する 5. 手元で動かすのに必要な設定(鍵など、GitHub に入っていないもの)があれば、何が要るかを一覧にする。値は私が持ち主から受け取る 6. 実際に起動して、動いたかどうかを報告する 以後このリポジトリでは、CLAUDE.md のルールに従って作業して
③ 2回目からは、普通に頼むだけ
最新を取り込んでから、〇〇を直して。終わったらプルリクエストを出して
④ 公開の入口を1本にする(会社の Cloudflare で、1回だけ)
このリポジトリを、main にマージしたら Cloudflare に自動で公開されるようにしたい。Cloudflare の管理画面で私がやる操作を、1つずつ案内して。鍵は GitHub に入れず、Cloudflare の側に登録する形にして
で、今日から何をするか
いちばん使われているアプリを1つ選び、作った本人が①を貼ってください。
全部のアプリを一度に移す必要はありません。1つ移して、別の人が②で開き、小さな直しを1つ合流させる。そこまで通れば、2つ目からは同じことの繰り返しです。
次に読むなら:箱と倉庫の基本は「リポジトリ・Git・GitHub の違い」、AI に守らせるルールの書き方は「AI利用ルール、ありますか?」。
アプメイク