PCを2人で共有する最適解｜GitHubプルリクエスト

GitとGitHubは、仕事の書類で何をしてくれるのか

Git（ギット）は、ファイルの変更の履歴を残す仕組みです。いつ・誰が・どこを・なぜ変えたかが残り、いつでも前の状態に戻せます。一方のGitHub（ギットハブ）は、その履歴をネット上に置いて、複数の人で共有するサービスです。

エンジニアの道具と思われがちですが、エンジニア以外の人が書類を管理する例も出てきました。Insight Edge社は2026年7月の技術ブログで、デザインの成果物や設計資料、意思決定の経緯までGitやGitHubに集め、Gitに触れるエンジニア以外のメンバーが社内で増えてきたと書いています。

同じ記事には、議事録や仕様書をAIで作ってGitで管理する光景も当たり前になってきた、ともあります。「誰がいつ何を変えたか」を後から確かめたい書類ほど、履歴が残る仕組みが役に立ちます。

一方で同社の別の記事（2026年7月）では、成果物をGitHubで管理しようとすると、エンジニア以外の人には急にハードルが上がると書かれています。

cloneとは何か、branchはいつ切り替えるのかといった操作を覚えるのが、本来の仕事とは別の負担になるためです。同社はGitの操作をClaude Code（AIに作業を任せる道具）のコマンド1つにまとめ、この負担を減らしています。

Excel・Wordの書類も、同じように管理できるのか

保管して履歴を残すことはできますが、中身の違いをそのまま読めるのは文字だけのファイルです。

Git公式の説明では、Word文書（.docx）の違いを表示させると、初めは「ファイルが違う」としか出ません。文字の違いまで読むには、変換の道具を入れる設定が別に必要です。

どのファイルが向くかを、読み取れる違いの細かさで分けると次のとおりです。

当方がGitで管理しているのは、上の3行にあたるファイルです。業務の手順書やAIへの指示文は、文字だけのMarkdownで書いています。

Excelで持っていた書類をすぐ移す必要はありません。まずは、もともと文字だけで書ける手順書から始めるのが無理のないやり方です。

Gitに向くのは「文字だけで書ける書類」。Excel・Wordは保管はできても、違いを読むには設定が要ります。

1台の共有PCで、何に困っていたのか

当方では、記事づくりの仕組み一式を1台のPCに置き、代表と開発担当者の2人で使っていました。開発担当者は自分のPCからリモートでそのPCに入って作業します。

GitHubのアカウントも1つで、画面には「書き込めるのはあなただけ」と表示される状態でした。

困ったのは、片方が使っている間はもう片方が待つしかないことでした。同じ作業フォルダを2人の作業で別々に触るため、相手の作業中のファイルを巻き込まないよう、細かい約束ごとも増えていました。

テストとして1回通したとき、次の点が変わりました。ここでいう「正式な版」は、2人とも最終的に使う共通の最新版のことで、GitHubでは main と呼びます。

普段の作業をこの形に切り替えたわけではありません。パスワード類やデータベース、記事の原稿、一部のAIツールは共有PCに残しました。GitHubに載せるのはプログラムと書類だけで、会社の秘密はそこに入れない決まりにしています。

プルリクエストとは何か

プルリクエストは、「この変更を正式な版に入れてください」という申し出です。紙の書類でいえば、修正案を回覧に出し、責任者の確認印をもらってから正式な版に差し替える流れに近いものです。

GitHubでは、この回覧を画面の上で行います。変更したファイルと行が並んで表示され、相手はそれを読んでから正式な版に入れます。この入れる操作を「マージ」と呼びます。

プルリクエストを出すまでの言葉を、順に並べると次のとおりです。

1. ブランチ
   正式な版から分けた、自分用の作業の枝です。ここで何を変えても正式な版は変わりません。
2. コミット
   変更を1回分の記録として残すことです。何を変えたかの一言を付けます。
3. プッシュ
   自分のPCの記録をGitHubへ送ることです。
4. プルリクエスト
   ブランチの変更を正式な版に入れてほしいと申し出ることです。
5. マージ
   相手が確かめて、正式な版に取り込むことです。

コミットは「自分の記録」、プルリクエストは「相手への申し出」と覚えると混ざりません。

→ くわしくは「AIエージェントとは｜何をどこまで任せられるか」で解説しています。

2人の共同作業をテストで1回通した手順

普段の作業をこの形に切り替えたのではなく、テストとして1回通してみました。当方の開発担当者はチームでの開発をしたことがなく、操作はAI（Claude Code）に1つずつ聞きながら、次の順で進めました。

なお当方では、GitHubへ送るたびに自動テスト（次の節で説明します）が動く設定を、前もって用意してありました。この設定が無いと、手順5の結果は出ません。

実際に打ったコマンドと画面は、付録「GitHubで2人の共同作業をしたときのコマンド」にまとめました。手を動かす担当者の方は、あわせてご覧ください。

正式な版（main）を守る設定を非公開の保管場所で使うには、有料プランが要ります。無料プランのままなら「正式な版に直接入れない」は人の約束で守ることになります。

1. 相手をGitHubの保管場所に招待する
   保管場所の設定で「Collaborators（共同作業者）」から相手のユーザー名を入れます。途中で本人確認のコードを聞かれ、相手にはメールで招待が届きます。
2. 相手のPCに保管場所を複製する（クローン）
   GitHubから、相手のPCへ一式をコピーします。以後、相手はそのコピーで作業します。
3. 自分用のブランチを作って作業する
   正式な版を直接触らないので、途中の状態が相手の作業を邪魔しません。
4. 変更をコミットしてGitHubへ送る
   変えたファイルだけを名指しで記録します。まとめて全部を記録しない決まりにしています。
5. プルリクエストを出す
   GitHubの画面から申し出ます。プルリクエストの画面で、自動テストの結果を確かめます。
6. 自動テストが通ってから、相手が確かめて正式な版に入れる
   当方では、代表のアカウントでマージしました。
7. 両方のPCで正式な版を最新にする
   作業を始める前に、毎回これをします。相手の変更を取り込んでから始めるためです。

なぜ自分のPCで動くのに、相手のPCでは動かなかったのか

作った人のPCにしか無いものに、気づかないうちに頼っていたからです。それを見つけてくれたのが自動テストでした。

自動テストは、プログラムが正しく動くかを自動で確かめる小さなプログラムです。当方の仕組みには約2,400件あり、変更のたびに流します。これを開発担当者のPCで流すと、共有PCでは通っていた9件が通りませんでした。

直して出したプルリクエストでは、GitHub上の自動テストでも別の14件が通りませんでした。原因を調べると、次の3つでした。

当方では、共有PCだけで作業している間は、どれにも気づけませんでした。共有PCではこの9件も通っていたので、誰も困っていなかったわけです。

直すたびに同じブランチへコミットしてGitHubへ送れば、プルリクエストに自動で加わり、自動テストもやり直されます。当方では3回目のコミットで、GitHub上で実行した自動テストがすべて通りました（フォントが無いため飛ばしたテストは除きます）。

画面の右端には、コミットごとの結果が×と✓で並びます。「通らないものは正式な版に入れない」と決めておけば、自動テストで見つかった問題を、直さないまま正式な版に入れずに済みます。

AIに作業させるとき、Gitは何を守るのか

AIがどのファイルを変えたかが、行の単位で残ることです。当方ではClaude CodeやCodexといったAIにプログラムの修正を任せています。AIが変えた中身は、Gitの差分で人が1行ずつ確かめてから正式な版に入れます。

一度、AIが相手の作業中のファイルまでまとめて記録に含めてしまったことがありました。

正式な版に入る前に気づいて取り消しましたが、それ以来、一度に大量のファイルを記録する操作を仕組みの側で止めています。相手の作業かどうかを見分けるのではなく、ファイルの数で止めます。

50という数は、当方の過去460回の記録で1回あたりの中央値が3ファイルだったことから決めました。

この仕掛けは、PCごとに1回だけ有効にする設定が要ります。設定していないPCでは働かないため、最後は人が差分を読むところが残ります。

AIに作業させるほど、「何が変わったかを人が読める」ことの値打ちが上がります。

テストで通してみて、どこに限界があったのか

1回通してみて、当方の開発担当者が感じた限界は3つです。

1. 共有PCにしか無い道具は使えない
   記事の原稿、パスワード類、データベース、一部のAIツールは共有PCにしかありません。別のPCでできたのは、プログラムと手順書の修正だけでした。
2. Claude Codeのリモート操作でも代わりになる
   同時に作業したいだけなら、Claude CodeのRemote Control（別の端末から、共有PCで動くClaude Codeを操作する機能）でも足りると感じました。道具が共有PCにそろったまま作業できます。
3. エンジニア以外の人には敷居が高い
   AIに1つずつ聞きながらでも、黒い画面（ターミナル）でコマンドを打つ操作は残りました。

1つめと2つめを合わせると、「別のPCで作業を分ける」のが向くのは、どのPCでも動くプログラムや書類を扱うときに限られます。ただしRemote Controlで同じフォルダを2人が同時に触ると、ファイルがぶつかる心配は残ります。

3つめは、先に紹介したInsight Edge社の記事も同じ点を挙げていました。エンジニア以外の人に使ってもらうなら、コマンドを覚えてもらうより、Gitの操作をAIに任せる仕組みを先に用意するほうが現実的です。

社長・管理職が先に決めておくこと

操作は担当者が覚えれば済みますが、次の4つは担当者に決めさせないほうが揉めません。

1. 誰が正式な版に入れるか
   プルリクエストを出す人と、確かめて入れる人を分けます。当方では開発担当者が出し、代表のアカウントで入れました。
2. 正式な版に直接入れてよいのは誰か
   当方では、共有PCだけは正式な版へ直接、それ以外のPCはプルリクエストに決めています。
3. GitHubに入れないもの
   パスワード類、取引先とのやり取り、個人情報は入れないと先に決めます。当方では、外に出せない記録が混ざった履歴を正式な版に入れないよう、中身を分けてから移しました。
4. 自動テストが通らない変更をどう扱うか
   「赤いままのものは入れない」と決めておけば、判断が人によって変わりません。

FAQ

自社の業務に合わせたAIツールの選定・導入は、
ぜひ、ジッソウLABのゲンバAIへ無料でご相談ください。

執筆・監修

大平 — ジッソウLAB代表

中小企業の業務改善・メルカリ物販、中古PC販売の実務経験を活かし、現場目線でAI活用を検証・発信