GitHubとは?Gitとの違いからわかりやすく——リポジトリ・プルリクエストの意味と、外注時にコードを誰が持つか【2026年版】

「ソースコードはGitHubで管理します、と言われたのですが、それは何ですか」——システム開発を発注している方から、こうした相談をよく受けます。キックオフの席では頷いたものの、社内に戻ってから、GitHubが何なのか、そこに置かれた自社のソースコードが誰のものになるのかが分からないことに気づく。開発会社に聞き返すのも、いまさら気が引ける。そこから先に進めません。

結論から言うと、GitHubとは、ソースコードとその変更履歴を置き、チームで共有してレビューするためのサービスです。そして名前のよく似たGitは、変更を記録する道具そのもので、別物です。道具がGit、その置き場と共同作業の場がGitHub。この2つを最初に分けておくと、あとに出てくるリポジトリもプルリクエストも、素直につながります。

ただ、発注者にとって本当に大事なのは語義ではないと考えています。開発を外注すると、自社の中核資産であるソースコードが、他社のアカウントの下に置かれることがあります。リポジトリを誰の名義で持つのか、誰にアクセス権を渡すのか、契約が終わったらどう引き継ぐのか。この3つを決めないまま進むと、契約書に「著作権は当社に帰属する」と書いてあっても、実物を自分で取り出せない状態になります。

本記事では、GitとGitHubの違い、リポジトリ・コミット・ブランチ・プルリクエストという基本用語、公開範囲とOrganizationとアクセス権限、料金プランとGitHub Actions、GitLabやBitbucketとの関係、そして開発を外注するときにリポジトリを誰が持つべきかの順に解説します。料金・無料枠・権限区分はGitHubの公式ページから2026年9月15日に取得した値だけを載せ、確認できなかった数値は書きません。なお、ソースコードの著作権が誰に帰属するかという法律の話、開発会社を乗り換えるときの引き継ぎ手順、デプロイの仕組み、オフショアのセキュリティ対策は、本記事では扱わず、それぞれ既存の記事に譲ります。Gitコマンドの打ち方も扱いません。読者に開発をしていただくための記事ではないからです。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。開発会社の乗り換え相談で、私が最初に聞くのは「リポジトリはどなたの名義ですか」です。答えられない方が、少なくありません。GitHubは技術の話に見えて、その半分は資産の話です。この記事を読み終えるころには、開発会社に何を聞き、何を契約書と議事録に残すべきかが決められるはずです。

GitHubとは——ソースコードを置き、変更の履歴を残し、チームで確認するための場所

GitHubとは、ソフトウェアのソースコードを置き、その変更の履歴を残し、チームで共有して確認するためのインターネット上のサービスです。GitHub自身は、計画から開発、デプロイ、運用までのソフトウェア開発のプロセス全体を支えるプラットフォームだと説明しています。読み方は「ギットハブ」。まずは、開発チームが使っている共同作業の場所だと思ってください。

まずGitとGitHubを分ける——道具がGit、置き場と共同作業の場がGitHub

最初に切り分けておきたいのが、GitとGitHubの関係です。名前が似ているので同じものだと思われがちですが、別物です。ここを分けないまま先へ進むと、あとに出てくる用語がすべて曖昧になります。

Git(ギット)は、ファイルの変更を記録するバージョン管理システムです。開発者のパソコンの中で動くソフトウェアで、「誰が、いつ、どのファイルの、どこを、どう変えたか」を一つずつ記録していきます。文書作成ソフトの変更履歴機能を、プログラムのファイル群に対して、はるかに厳密にしたものだと考えると近いです。

GitHub(ギットハブ)は、そのGitで管理しているプロジェクトをインターネット上に置いて共有できるようにし、さらに計画と共同作業のための機能を足したサービスです。GitHubの公式ドキュメントも、GitHubはGitの上に成り立っていて、リポジトリと呼ばれるGitのプロジェクトをクラウドに置き、そこに計画と共同作業のツールを加えたものだと説明しています。

つまり、Gitがなければ記録はできず、GitHubがなくてもGitは使えます。しかし複数人で開発する現場では、記録を1か所に集めて互いに見られるようにしないと仕事になりません。その1か所を提供しているのがGitHubです。

GitとGitHubの対比表——何が手元にあり、何がインターネット側にあるのか

もう少し具体的に、どちらがどこにあるのかを整理します。発注者が押さえるべきなのは、自社のソースコードの「正本」がインターネット側にあるという一点です。

手元のパソコンにあるものをローカルリポジトリ、GitHub側にあるものをリモートリポジトリと呼びます。開発者は、GitHub側のものを自分のパソコンに複製し(この複製をクローンと言います)、そこで作業して、また送り返します。この往復を繰り返しているだけです。

なぜソースコードをここで管理するのか——履歴・同時作業・レビューの3つ

「わざわざ外部のサービスに置かなくても、社内のファイルサーバーでよいのでは」と聞かれることがあります。理由は3つあります。

第一に、履歴が1行単位で残ること。「先週は動いていたのに」というとき、どの変更が原因かを特定して、その部分だけ戻せます。ファイルサーバーに「最終版_v3_修正済.zip」を並べる運用では、これができません。

第二に、複数人が同時に同じプロジェクトを触れること。次に説明するブランチという仕組みで、それぞれが別の枝で作業し、あとから統合します。ファイルの取り合いが起きません。

第三に、取り込む前に他人が確認できること。これがプルリクエストです。当社でも、品質管理の3点のうちの1つとして、Gitのプルリクエストによるコードレビューを標準にしています。誰がどのコードを書き、誰が確認して取り込んだかが、そのまま記録として残ります。

規模——開発者1億8,000万人、リポジトリ6億3,000万件

GitHubが公開している年次レポート「Octoverse」の2025年版(対象期間 2024年9月1日〜2025年8月31日)によれば、GitHub上で活動する開発者は1億8,000万人を超え、この1年で3,600万人以上が新たに参加しました。リポジトリの総数は6億3,000万件、1年で1億2,100万件以上が新しく作られています。マージされたプルリクエストは月平均4,320万件。もはや一部の技術者の道具ではなく、ソフトウェアを作る現場の共通インフラです。では、その置き場の中身は何と呼ばれているのか。次に基本用語を見ていきます。

GitHubの基本用語4つ——リポジトリ、コミット、ブランチ、プルリクエスト

開発会社の説明資料や進捗報告に出てくるGitHubの用語は、実のところ4つの組み合わせでできています。リポジトリ、コミット、ブランチ、プルリクエスト。この4つを押さえれば、非エンジニアでも報告の中身が読めるようになります。以下はGitHubが公開している用語集の定義に沿って、発注者の視点から補足したものです。

リポジトリ——プロジェクトのフォルダと、そこに積み上がる全履歴

リポジトリは、ひとことで言えばプロジェクトのフォルダです。ただし普通のフォルダと違って、中のファイルが過去にどう変わってきたかの記録を丸ごと抱えています。GitHubの説明でも、ドキュメントを含むプロジェクトのファイルすべてと、各ファイルの変更履歴を格納する場所とされています。

通常は1つのシステムに対して1つ、または機能のまとまりごとに数個のリポジトリを作ります。発注した業務システムが1つなら、リポジトリも1つか数個です。このリポジトリがどのアカウントの下にあるかが、後の章で扱う「誰が持つか」という話の核心になります。

手元のパソコンにある複製をローカルリポジトリ、GitHub上にあるものをリモートリポジトリと呼ぶことは前章で触れました。この記事ではGitのコマンドの打ち方は扱いませんが、発注者として知っておくとよいのは、リモートにあるものが正本で、ローカルにあるものは複製だという関係だけです。

コミットとブランチ——1回分の変更と、本線を止めずに進めるための枝

コミットは、1回分の変更に名前と日時と担当者を付けて記録する操作です。GitHubの説明では、コミットごとに固有のID(SHA、ハッシュとも呼ばれます)が作られ、誰がいつ何を変えたかを追えるようになっています。進捗会議で「今週は◯件コミットしました」と言われたら、それは作業の回数を指しています。ただし1コミットの大きさは人によって違うので、件数だけで進捗を測るのは失敗のもとです。

ブランチは、リポジトリの中に作る並行したバージョンです。GitHubの説明では、リポジトリの中にありながら本線(primary、main)には影響を与えず、稼働中のバージョンを壊さずに自由に作業できるもの、とされています。Gitでリポジトリを作ると main という名前のブランチが最初にできて、それが既定の開発の本線になります。

たとえば「請求書の出力形式を変える」という改修なら、そのための枝を1本作り、そこで作業します。本線は触られていないので、その間も別の人が別の枝で作業できますし、緊急の修正も本線に直接入れられます。作業が終わって確認が済んだら、枝の変更を本線に取り込みます。これがマージです。

プルリクエストとマージ——レビューはここで起きる

プルリクエストは、GitHubの説明では「利用者が提出し、リポジトリの共同作業者が受け入れるか却下するかを決める、変更の提案」です。略して「プルリク」「PR」とも呼ばれます。枝で書いたコードを本線に入れてよいかを、入れる前に他人に見てもらうための仕組みだと考えてください。

ここが、発注者にとって一番意味のある場所です。プルリクエストの画面には、変更された行が色分けで並び、その横にレビューする人のコメントが付きます。指摘に対応してから取り込むのか、そのまま取り込むのか、誰が承認したのか。すべてが日時付きで残ります。 当社が品質管理の3点のうちの1つとして、Gitのプルリクエストによるコードレビューを標準にしているのは、これが「レビューをしています」という口頭の説明ではなく、記録として確認できる形になるからです。

AIの支援でコードを書く場面が増えた分、この記録の価値はむしろ上がりました。生成されたコードを誰が読んで、何を直して、誰の判断で取り込んだのか。プルリクエストの履歴は、その答えそのものです。

非エンジニアがGitHubの画面から読み取れること

閲覧の権限をもらえば、発注者もブラウザからリポジトリを見られます。コードが読めなくても、読み取れることがあります。

• 更新が止まっていないか——コミットの日付が並んでいるので、直近1か月の動きが一目で分かる
• 誰が書いているか——コミットとプルリクエストに担当者名が付く。提案書にあった体制と実態が合っているか確認できる
• レビューが行われているか——プルリクエストに承認者とコメントが付いているか。承認なしで取り込まれ続けていれば、レビュー体制は実質ありません
• 課題が管理されているか——イシュー(Issues)という機能で、不具合や要望が一覧になっている場合がある

なお、他人のリポジトリを自分のアカウントに複製することをフォークと呼びます。これは後の章の、アクセス権を消しても複製が残るという話につながります。用語は、この4つで足ります。次は、そのリポジトリが誰に見えているのかという話です。

公開範囲とアクセス権限——パブリック、プライベート、Organizationの考え方

「GitHubに置くと、ソースコードが世界中から見えてしまうのではないか」。この質問は本当に多く受けます。答えは、公開範囲は選べる、です。そのうえで会社として使うなら、個人のアカウントではなくOrganizationという組織の器を作り、リポジトリごとに必要最小限の権限を渡す。この2つが実務の骨格になります。

公開範囲は選べる——public、private、internalの3種類

GitHubのリポジトリには可視性(visibility)という設定があり、公式ドキュメントでは次のように説明されています。

業務システムの開発であれば、選ぶのは private です。無料プランでも非公開のリポジトリを人数無制限の共同作業者で使えるので、「有料にしないと非公開にできない」ということもありません。

ただし、私が要注意だと思っているのは、公開範囲そのものよりも設定を変えられる人が誰かという点です。private を public に切り替える操作は、リポジトリの管理者権限があれば数クリックでできてしまいます。誤操作でも、意図的でも同じです。だからこそ次の権限の話が効いてきます。

Organizationとは——会社の器。個人アカウントの下に置かない

GitHubの用語集では、Organization(オーガニゼーション、組織)は「2人以上のユーザーのグループで、たいていは現実の組織を反映したもの。ユーザーによって管理され、リポジトリとチームの両方を保持できる」と説明されています。要は会社やチームの器です。

会社で開発するなら、この器を自社名義で作り、その配下にリポジトリを置きます。個人アカウントの下に置いてはいけません。理由は単純で、個人アカウントは個人のものだからです。その人が退職すれば、会社はそのアカウントに手を出せません。開発会社の担当者の個人アカウントの下に自社のシステムが置かれている、という状態は、実際に起こります。

Organizationには、リポジトリとは別に組織そのものへの役割(ロール)があります。GitHubの公式ドキュメントが挙げているのは、組織全体の管理権限を持つOrganization owner(少なくとも2人にすることが推奨されています)、既定の役割であるOrganization member、支払い情報などの請求設定を扱うBilling manager、セキュリティ警告の閲覧と設定を担うSecurity manager、公開リポジトリでの荒らし対応を担うModerator、そして組織のメンバーではないが一部のリポジトリにアクセスできるOutside collaborator(外部コラボレーター)です。

外注先のエンジニアは、この Outside collaborator として、必要なリポジトリにだけ招くのが基本の形になります。組織のメンバーにしてしまうと、組織全体の情報に触れられる範囲が広がります。

リポジトリの権限は5段階——誰にどこまで渡すか

リポジトリ単位のアクセス権は5段階です。GitHubの公式ドキュメントの区分に沿って整理すると、次のようになります。

発注者として押さえるのは2点だけです。自分はReadでよいこと。そしてAdminを開発会社だけに持たせないことです。Adminは削除も公開範囲の変更もアクセス権の付け外しもできます。ここを相手側だけが握っている状態は、自分の家の鍵を全部預けているのと変わりません。

組織側のロールと、権限の棚卸し

権限は、渡すときよりも外すときに忘れられます。人が入れ替わった月に棚卸しをしないと、二度とやりません。これは私の持論ですが、実際に「3年前に案件を離れた方のアカウントが、まだAdminで残っていた」という状況を何度か見てきました。

やることは難しくありません。四半期に一度、リポジトリのアクセス権者の一覧を出してもらい、いま関係のある人だけが残っているかを見る。それだけです。開発会社側の担当者が交代したときは、その月に必ず行ってください。

なお、オフショア開発全般のセキュリティ対策——リスクの類型、契約・人・環境・運用・法規制の各層で何をするか、発注前に確認する項目——については、本記事では扱いません。「オフショア開発 セキュリティ」の記事にまとめてあるので、体制全体を設計する段階ではそちらを参照してください。本記事はあくまで、GitHubというサービス上の権限の話に限定しています。

いま、自社のシステムのリポジトリには、誰がアクセスできる状態になっていますか。

料金プランとGitHub Actions——2026年9月15日時点の公式情報

料金は、GitHubの話題のなかで最も情報が古くなりやすい部分です。プラン名も金額も改定されるため、日本語のまとめ記事に載っている数値が現在と違うことがよくあります。以下はすべて、GitHubの公式の料金ページとドキュメントを2026年9月15日に直接確認した値です。実際の発注の前には、必ず同じページで再確認してください。

プランは3つ——Free、Team、Enterprise(2026年9月15日確認)

公式の料金ページに並んでいるのは3つです。価格は米ドル建てで、1ユーザーあたりの月額です。

読み方のポイントは3つあります。

第一に、無料プランでも非公開リポジトリを人数無制限の共同作業者で使えます。「会社で使うには有料契約が必須」ではありません。ドキュメントによれば、無料プランの非公開リポジトリは一部の機能が制限されます。個人アカウント向けの上位プランであるGitHub Proでは、非公開リポジトリでもレビュー必須の設定や保護されたブランチといった機能が使えるようになると説明されています。

第二に、有料プランの差は主に管理機能と利用枠です。月額4USD(1USD=150円換算目安で約600円)と21USD(約3,150円)の差は、大きく言えばセキュリティと統制の機能です。10名の体制なら、Teamで年額480USD(約7.2万円)、Enterpriseで年額2,520USD(約37.8万円)。開発費全体から見れば小さな額ですが、誰の契約なのかは小さな話ではありません。

第三に、Copilot(AIによるコード補完)は、これらの基本プランには含まれず、別のプランとして提供されています。無料で月2,000回の補完まで使い始められる旨が料金ページに記載されています。

なお、GitHubには自社サーバーに設置して使うGitHub Enterprise Serverという形態もありますが、本記事では扱いません。

GitHub Actionsとは——テストやビルドを自動で走らせる仕組み

提案書に「GitHub Actionsによる自動テスト」と書かれていて、意味が分からず止まった方もいると思います。GitHub Actionsは、GitHubの公式ドキュメントで「ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーション/継続的デリバリー(CI/CD)のプラットフォーム」と定義されている、GitHubの中の一機能です。別サービスではありません。

仕組みは、次の5つの言葉でできています。

• イベント——リポジトリで起きる特定の出来事。プルリクエストが作られた、コードが送られた、など
• ワークフロー——そのイベントをきっかけに動く、自動化された処理のまとまり。リポジトリ内の設定ファイルに書かれる
• ジョブ——ワークフローの中で、同じ実行環境の上で動く一連の手順
• ステップ——ジョブを構成する個々の処理。順番に実行される
• ランナー——ワークフローを実際に動かすサーバー。GitHubが用意するものと、自社で用意するものがある

発注者の実務に引き寄せると、こういうことです。エンジニアがプルリクエストを出した瞬間に、自動テストが走って、壊れていないかを機械が確認する。通ったものだけが人のレビューに進む。この一連が自動で回るようになります。手作業のチェックリストを人がたどる運用と比べて、抜けが減ります。

費用は、上の表の「CI/CDの月間無料枠」に対応します。GitHubのドキュメントによれば、公開リポジトリでは標準のGitHub提供ランナーの利用は無料で、非公開リポジトリではプランごとの無料枠を超えた分が従量課金になります。ドキュメントに記載されている標準ランナーの単価は、2コアのLinuxで1分あたり0.006USD、Windowsで0.010USD、macOSで0.062USDです(いずれも2026年9月15日確認)。OSによって10倍以上の差があるため、どのOSでどれくらい回すのかで金額が変わります。

本番環境への反映(デプロイ)そのものの仕組みと、発注者が決めるべきリリースまわりの取り決めについては、「デプロイとは」の記事で扱っているのでそちらを参照してください。本記事では、Actionsが「自動で走らせる仕組み」であるという位置づけまでに留めます。

発注者が料金で見るべきなのは、金額より「誰の契約か」

提案書に「GitHubの費用はお客様ご負担」と書かれていたら、それは悪い話ではありません。むしろ、自社名義の契約で自社のOrganizationを持つということなので、次の章で説明する「リポジトリを誰が持つか」という論点では望ましい形です。

確認すべきなのは金額そのものより、次の3点です。契約の名義は自社か。支払いを止めたときにリポジトリがどうなるか。Actionsの実行時間はどちらが負担し、超過したときに誰が判断するか。金額は月に数千円から数万円の世界ですが、名義は資産の話です。

GitHub以外の選択肢——GitLab、Bitbucketとの関係

開発会社によっては、GitHubではなくGitLabやBitbucketを使っています。「うちはGitHubじゃないと困りますか」と聞かれることがありますが、結論から言えば、ほとんどの案件で困りません。土台にあるGitは共通だからです。ただし、まったく同じというわけでもありません。

Gitは共通。だから乗り換えは「できる」が「そのまま」ではない

3つのサービスはいずれもGitを土台にしています。ですからソースコードとその全履歴——つまりコミットの積み重ね——は、サービス間で持ち運べます。ここは安心してよい部分です。

一方で、サービス固有の機能に蓄積されたものは、そのままでは移りません。プルリクエストのやり取りとレビューのコメント、課題管理(イシュー)の履歴、自動化の設定、権限の構成。これらは移行ツールを使えば一部を移せることもありますが、手間がかかりますし、完全ではありません。

発注者として覚えておくのは、「コードは移せる。議論の記録は移しにくい」という区別です。開発会社を変える判断をするときに、この差が効いてきます。

3つのサービスの位置づけ

公式の情報から確認できる範囲で、位置づけを並べます。

GitLabの各プランの単価については、公式の料金ページが当方の環境から取得できなかったため、本記事では金額を記載しません。プラン名が Free / Premium / Ultimate の3階層であること、SaaS版と自社設置版の両方が提供されていることは公式ドキュメントで確認しています。金額は必ずGitLabの公式料金ページで直接ご確認ください。第三者のまとめ記事の数値を引いて書くことは、この記事の方針として行いません。

ソースコードを社外のサービスに置けない規制がある業種では、自社設置という選択肢があるGitLabが候補に上がります。逆に、すでにJiraで課題管理をしている組織ならBitbucketが自然です。当社も、Gitでのコードレビューを標準にしている一方で、サービスそのものはお客様の環境に合わせています。

発注者が指定すべきか、開発会社に任せてよいか

指定して失敗する型が、いくつかあります。

• 開発会社が使い慣れていないサービスを指定する——自動化の設定やレビューの運用を一から組み直すことになり、立ち上がりが遅れます
• 自社に規制がないのに自社設置を要求する——サーバーの運用と保守の負担を自社で抱えることになります
• サービス名だけ指定して、名義と権限を決めない——本当に決めるべき論点が抜けたまま進みます。これが一番よくある失敗のもとです

原則として、サービスの選択は開発会社に任せて構いません。発注者が指定すべきなのは、サービス名ではなく、アカウントの名義とアクセス権の持ち方です。 どのサービスであれ、次の章の論点は変わりません。

開発を外注するとき、リポジトリは誰が持つべきか——発注者が決める5つと、当社の進め方

ここからが本題です。開発を外注すると、自社の中核資産であるソースコードが、他社の管理するアカウントの下に置かれることがあります。契約書に「成果物の著作権は委託者に帰属する」と書いてあっても、実物がどこにあり誰がログインできるかは、まったく別の層の話です。決めるべきなのは次の5つで、いずれも契約前か、遅くとも開発開始の週には決められます。

原則——リポジトリは発注者のOrganizationの下に置く

いちばん簡単で確実な方法は、発注者が自社名義のOrganizationを作り、その下にリポジトリを作ってもらうことです。開発会社のメンバーは、そこに外部コラボレーターとして招かれる形になります。無料プランでも非公開リポジトリは人数無制限で使えるので、最初の一歩に費用はかかりません。

この形にしておくと、何が起きても自社のOrganizationの中に実体があります。契約が終わっても、担当者が辞めても、移管の手続きそのものが不要です。逆に、開発会社のOrganizationや担当者の個人アカウントの下にある状態は、終わるときに必ず手続きが要る状態です。手続きが要るということは、相手の協力が要るということでもあります。

私は人材業界の出身で、2018年からホーチミンで約100社の開発体制を支援してきました。開発会社の乗り換え相談で最初に聞くのは「リポジトリはどなたの名義ですか」です。答えられない方が、少なくありません。名義を後から変えるのは可能ですが、関係が良好なうちにやるほうが、はるかに簡単です。

退任・交代のときにアクセス権を消す——ただし複製は消えない

ここは誤解が多いところなので、はっきり書きます。アクセス権を取り消しても、すでに手元に複製されたソースコードは消えません。

GitHubの公式ドキュメントも、組織からメンバーを削除すると、そのメンバーは非公開リポジトリと非公開フォークへのアクセスを失うが、コードのローカルコピーは保持されうる(ただし組織のリポジトリと同期はできなくなる)と説明しています。そして、削除した相手が機密情報を確実に破棄したかを確認する責任は、組織側にあるとも書かれています。加えて、削除から3か月以内に再度招待した場合は、メンバーシップの情報と所有していた非公開フォークが復元される仕組みになっています。

つまり、アクセス権の管理は流出の防止策ではなく、それ以上の複製を止める措置です。実効性を持たせるには、秘密保持の条項と、終了時のデータ破棄の取り決めを契約側で用意しておく必要があります。だからこそ、権限は最初から必要最小限に絞る。渡してから外すより、渡さないほうが確実です。

納品物としてのリポジトリ——何をもって「渡された」と言えるか

「一式で納品します」と言われたときは、何をもって渡したことになるのかを聞いてください。ZIPファイルを1つ受け取ることと、リポジトリを引き継ぐことは、まったく違います。ZIPにはその時点のファイルしか入っておらず、誰が何のためにどう変えたかという履歴が丸ごと抜け落ちます。次の開発会社が最初に困るのは、まさにそこです。

納品条件として書くなら、「本件のソースコードは、委託者が指定するアカウント配下のリポジトリに格納し、契約終了時点で委託者が当該リポジトリのAdmin権限を保持している状態とする」といった形になります。あわせて、環境構築の手順書、設定値の一覧、外部サービスの接続情報の引き渡しも条件に含めてください。

なお、ソースコードの著作権が誰に帰属するのか、業務委託契約書の知的財産条項で何を決めるのかは、それ自体が大きな論点です。本記事では扱いませんので、「システム開発 著作権 ソースコード 帰属」の記事を参照してください。所有の話(リポジトリがどこにあるか)と、権利の話(著作権が誰にあるか)は別の層であり、両方そろって初めて資産になります。

開発会社を変えるとき——移管で動くもの、動かないもの

リポジトリは、別のアカウントや組織へ移管(transfer)できます。GitHubのドキュメントによれば、移管にはリポジトリの管理者権限が必要で、移管先の組織ではリポジトリを作成する権限が要ります。移管すると新しい所有者はただちに内容・イシュー・プルリクエスト・リリース・設定を管理でき、イシュー、プルリクエスト、Wiki、スター、ウォッチャー、Webhook、デプロイキー、コミット履歴は一緒に移ります。旧URLは新しい場所へリダイレクトされます。

一方で、そのまま引き継がれないものもあります。組織のリポジトリを個人アカウントへ移す場合の読み取り専用の共同作業者、GitHub Pagesの独自ドメイン(DNSの設定変更が必要)、パッケージレジストリとの一部の紐づけなどです。

同じサービス内の移管はこのように整理されていますが、GitHubからGitLabへといったサービスをまたぐ移行になると、前章で書いたとおりコードは移せても議論の記録は移しにくくなります。開発会社を乗り換えるときに受け取る資産の全体像、契約で確認する項目、並走期間の設計については「開発会社 乗り換え 引き継ぎ」の記事にまとめてあります。本記事では、リポジトリという一点に絞りました。

当社の進め方と、向く案件・向かない案件

当社はホーチミンを拠点に、日本人PMやブリッジSEをフロントに置いたラボ型の開発チームを提供しています。2,000名以上のIT人財データベースから直接アサインするため、協力会社を経由する仲介マージンはありません。ソースコードの管理はGitHubまたはGitLabでの標準運用とし、どちらを使うかはお客様の環境と規制に合わせます。リポジトリはお客様側のアカウント配下に置くことを原則としてご提案しています。品質管理では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を行っています。介護記録SaaS「CareViewer」では、日本語のできるブリッジSE1名とフルスタックエンジニア2名の体制で、週次で優先順位を判断しながら継続開発しています。

向く案件は、継続的に機能を追加していく自社サービスやシステムで、レビューの記録を資産として残したい案件です。体制は1名から、最短2週間で開始でき、増員は約1週間、縮小や交代は1か月単位。最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

向かない案件もあります。ソースコードを社外に一切出せない規制がある案件、1〜2週間で終わる単発の修正、仕様も体制も固まっておらず社内に判断者がいない案件。こうした場合は、その旨を率直にお伝えしています。

これから開発を発注する方へ。リポジトリの名義は、開発が始まってからでは動かしにくくなります。契約書に1行足すだけで済む話です。「本件のソースコードは委託者が指定するアカウント配下のリポジトリで管理する」。今日の見積もり依頼に、この一文を添えてください。

GitHubに関するよくある質問

GitHubについて、発注者の方から実際によく届く質問を5つ挙げます。いずれも契約の段階で確認しておくと、開発が終わるときに困らずに済むものです。

Q1. GitHubを社内資料で説明するとき、何と書けばよいですか

「ソースコードとその変更履歴を保管し、開発チームが共同で作業するためのクラウドサービス」と書けば、技術者でない決裁者にも通じます。あわせて「Gitはパソコン側で変更を記録する仕組み、GitHubはそれを預かって共有する場所」と一文添えると、用語の混同を防げます。

Q2. 無料プランで会社の開発に使えますか

使えます。無料プランでも非公開リポジトリを共同作業者の人数制限なく使えます(2026年9月15日時点の公式情報)。有料プランとの差は、主に管理・セキュリティの機能とCI/CDの利用枠です。ただし判断すべきなのはプランより名義で、無料でよいので自社名義のOrganizationを持つほうが先です。

Q3. 開発会社のアカウントにあるリポジトリを、こちらへ移してもらえますか

移せます。リポジトリの移管という機能があり、イシュー、プルリクエスト、コミット履歴、Wiki、Webhookなども一緒に移ります。ただし移管には相手側の管理者権限での操作が必要です。関係が良好なうちに移しておくほうが確実で、契約更新のタイミングが自然な機会になります。

Q4. 海外のメンバーにソースコードのアクセス権を渡して大丈夫ですか

権限の設計と契約の条項で管理する話であって、国内か海外かで決まる話ではありません。外部コラボレーターとして必要なリポジトリにだけ、必要な権限区分で招く。離任した月に削除する。秘密保持と終了時のデータ破棄を契約に書く。この3つを守れば、国内の委託先と管理の考え方は変わりません。体制全体のセキュリティ設計は「オフショア開発 セキュリティ」の記事を参照してください。

Q5. GitHubを使っていない開発会社は避けるべきですか

避ける理由にはなりません。GitLabやBitbucketでも、Gitを土台にしている点は同じです。見るべきなのはサービス名ではなく、プルリクエストによるレビューが実際に運用されているか、リポジトリの名義を自社側にできるか、契約終了時の引き渡しを条件に書けるかの3点。逆に、この3つに明確に答えられない会社こそ要注意です。判断の軸は、道具ではなく運用と取り決め。

まとめ: GitHubはソースコードの置き場——発注者が決めるのは、名義・権限・引き継ぎの3つ

GitHubとは、ソースコードとその変更履歴を置き、チームで共有して確認するためのサービスです。よく似た名前のGitは、開発者のパソコンの中で変更を記録するバージョン管理システムで、別物です。道具がGit、その置き場と共同作業の場がGitHub。この切り分けができれば、あとに出てくる用語はつながります。リポジトリはプロジェクトのフォルダと全履歴、コミットは1回分の変更、ブランチは本線を止めずに進めるための枝、プルリクエストは取り込む前のレビューの場。進捗報告に出てくる語は、ほぼこの4つの組み合わせです。

公開範囲は選べます。業務システムなら非公開(private)にすればよく、無料プランでも非公開リポジトリを人数無制限の共同作業者で使えます(2026年9月15日にGitHub公式ページで確認)。会社で使うなら自社名義のOrganizationを作り、開発会社のメンバーは外部コラボレーターとして必要なリポジトリにだけ招く。リポジトリの権限はRead、Triage、Write、Maintain、Adminの5段階で、発注者はReadで足りますが、Adminを相手側だけに持たせてはいけません。GitHub ActionsはCI/CDの機能で、プランごとに月間の無料枠があります。GitLabやBitbucketでも土台のGitは同じなので、サービス名を指定する必要はほとんどありません。

そして発注者が決めるのは3つです。リポジトリの名義(自社のOrganizationの配下に置く)、アクセス権の渡し方と外し方(離任した月に削除し、四半期ごとに棚卸しする)、契約終了時の引き継ぎ(何をもって納品とするかを契約に書く)。アクセス権を取り消しても、すでに手元にある複製は消えません。だから渡す時点で最小限に絞るのが実務です。ソースコードの著作権が誰に帰属するかという権利の話はシステム開発の著作権・ソースコードの帰属に、開発会社を変えるときに受け取る資産と契約の確認項目は開発会社の乗り換えと引き継ぎにまとめてあります。当社はホーチミンを拠点に、日本人PMをフロントに置いたラボ型の開発チームを提供しており、リポジトリはお客様のアカウント配下に置くこと、Gitのプルリクエストによるコードレビューを標準にすることを原則としています。最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、ソースコードの持ち方を含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。