[{"data":1,"prerenderedAt":813},["ShallowReactive",2],{"/ja-jp/blog/journey-through-gits-20-year-history":3,"navigation-ja-jp":38,"banner-ja-jp":449,"footer-ja-jp":459,"blog-post-authors-ja-jp-Patrick Steinhardt":695,"blog-related-posts-ja-jp-journey-through-gits-20-year-history":709,"blog-promotions-ja-jp":751,"next-steps-ja-jp":804},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":24,"externalUrl":25,"featured":14,"heroImage":19,"isFeatured":14,"meta":26,"navigation":14,"path":27,"publishedDate":20,"rawbody":28,"seo":29,"slug":13,"stem":34,"tagSlugs":35,"tags":36,"template":15,"updatedDate":25,"__hash__":37},"blogPosts/ja-jp/blog/journey-through-gits-20-year-history.yml","20年にわたるGitの歴史をたどる",[7],"patrick-steinhardt",[9],"Patrick Steinhardt","Gitプロジェクトはちょうど20周年を迎えました。20年の間にさまざまなことがありました。Gitの概念的なデザインは、その登場以来大きく変わってはいないものの、ユーザーによるGitの操作方法は大きく変化しました。GitLabは、この重要な技術をベースにサービスを構築し、その歴史の一部であることを誇りに思っています。\n\nそれでは、Gitの歴史をたどり、長年にわたってどのように進化を遂げてきたかを一緒に見ていきましょう。\n\n## 初めてのコミット\n\n初めてのコミットは、2005年4月7日にLinuxカーネルの生みの親であるLinus Torvalds氏によって行われました。`e83c5163316 (Initial revision of \"git\", the information manager from hell, 2005-04-07)`\n\nご覧のとおり、このコミットには多くのファイルは含まれていませんでした。\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nビルドインフラストラクチャに加え、最初のコミットでは以下の7つのトップレベルコマンドが提供されていました。\n\n- `init-db`：新たなGitリポジトリを初期化\n- `update-cache`：インデックスにファイルを追加\n- `write-tree`：インデックスの内容を取得し、それをもとに新たなツリーを作成\n- `read-tree`：ツリーオブジェクトを読み込む\n- `commit-tree`：ツリーからコミットを作成\n- `cat-file`：特定のオブジェクトを一時ファイルに読み込む\n\nなお、この時点では、`git`コマンド自体存在していませんでした。代わりに、上記のコマンドを直接実行する必要がありました。\n\nでは、試しにリポジトリを新規作成してみましょう。\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nみなさんにはまったくなじみがないと思います。`.git`ディレクトリではなく、`.dircache`ディレクトリが使用されていました。では、プライベートストレージ領域はどこでしょうか？\n\n初期のGitのデザインでは、オブジェクトストレージ領域は「共有」と「プライベート」に分かれていました。このオブジェクトストレージ領域には、コミットやblobなども含め、あらゆるGitオブジェクトが格納されていました。\n\n`init-db`は、デフォルトではプライベートオブジェクトストレージ領域を作成します。これは、領域の作成先の管理ディレクトリ専用として使用されていました。一方、同じオブジェクトを二重に保存する必要がないように、「共有」オブジェクトストレージ領域を使用して、複数の管理ディレクトリ間でオブジェクトの内容を共有していました。\n\n### コミットを作成する\n\nリポジトリの作成後は、どのようにコミットを作成していたのでしょうか？作成方法は、現在利用可能な`git add . && git commit`ほどシンプルではありませんでした。その代わりに、以下の方法で行っていました。\n\n1. 追加するファイルごとに`update-cache`を呼び出してインデックスを更新する。\n1. `write-tree`を呼び出して新規ツリーを書き込む。インデックスに追加済みのすべての内容をもとに作成される。\n1. 環境変数を設定して、Gitにコミッターの情報を伝える。\n1. `commit-tree`を呼び出して、コミットオブジェクトを書き込む。\n\nそれでは、リポジトリにコミットを作成してみましょう。\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\n人間工学的な方法とは言えないものの、コミットは作成されます。それでは、生成されたコミットを見てみましょう。\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\n注目していただきたいのは、`cat-file`は内容を直接表示せず、まずは一時ファイルに書き出す点です。しかしながら、ファイルの内容は、まさに現代的なコミットと同じように見えます。\n\n### 変更を加える\n\nファイルの作成後、どのようにステータスを確認していたのでしょうか？おそらくお察しのとおりで、`show-diff`を使用していました。\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\n驚くべきことに、すでに`show-diff`では、変更されたファイルの新旧の状態を比較して差分を取得していました。しかも面白いことに、GitではこれをUNIXのdiff(1)ツールを使用するという簡単な方法で実現していました。\n\nつまり、これらはすべて必要最低限の機能しか備えていなかったものの、履歴の追跡に必要なすべての役割を果たしていました。以下のように制限は多数ありました。\n\n- あるコミットから別のコミットへ簡単に切り替える方法がなかった。\n- ログを表示できなかった。\n- ブランチやtag、また参照すら存在しなかった。そのため、ユーザーは手動でオブジェクトIDを追跡しなければならなかった。\n- 2つのリポジトリを相互に同期させる方法がなかった。代わりに、ユーザーがrsync(1)を使用して、`.dircache`ディレクトリを同期させる必要があった。\n- マージの実行方法がなかった。\n\n## Git 0.99\n\nGitの最初のテストリリースは、バージョン0.99でした。バージョン0.99は、最初のコミットからわずか2か月後にリリースされたものの、すでに1,076件のコミットが追加されていました。約50人のデベロッパーが開発に携わっており、最も頻繁にコミットを行っていたのはTorvalds氏自身でした。トーバルズ氏に続く勢いで、コミット件数の多かったコミッターは、現在メンテナーを務めている濱野純氏でした。\n\n最初のコミット以降、多数の変更が加えられました。\n\n- Gitは参照を使って複数の開発ブランチを追跡するようになりました。その結果、大抵の場合、手作業でオブジェクトIDを追跡せずに済むようになりました。\n- 新たにリモートプロトコルが導入され、2つのリポジトリ間で相互にオブジェクトを交換できるようになりました。\n- `.dircache`ディレクトリの名前が`.git`に変更されました。\n- 個々のファイルを相互にマージできるようになりました。\n\nただし、最も重要かつ顕著な変化は、トップレベルの`git`コマンドとそのサブコマンドが導入されたことでした。興味深いことに、「配管（plumbing）」コマンドと「磁器（porcelain）」コマンドの概念が導入されたのも、このリリースです。\n\n- 「配管」ツールは、基盤となるGitリポジトリにアクセスして低レベルな処理を行うコマンドです。\n- 「磁器」ツールは、「配管」コマンドをラップして、高レベルでよりユーザーフレンドリーなユーザーインターフェイスを提供するShellスクリプトです。\n\nGitには現在でもこの分け方は採用されており、[`git(1)`](https://git-scm.com/docs/git#_high_level_commands_porcelain)にも概説されています。しかしながら、「磁器」ツールの大半はShellスクリプトからC言語に書き直されたため、これらの2つのカテゴリ間の境界線はかなり曖昧になってきています。\n\n## Torvalds氏、メンテナーの役割を濱野氏に引き継ぐ\n\nTorvalds氏がGitに取り掛かった理由は、バージョン管理システムが好きだったためではなく、Linuxカーネル開発のためにBitKeeperの代替ツールを必要としていたためです。そのため、Gitのメンテナンスをずっと続けるつもりはなく、信頼できる人が現れるまで、メンテナーを務めようと考えていました。\n\nその条件に当てはまったのが、濱野純氏でした。濱野氏は、Torvalds氏が最初のコミットを行った約1週間後にGitの開発に参加しました。Git 0.99のリリース後にはすでに数百件のコミットを行っていました。そのため、2005年7月26日に、[Torvalds氏は濱野氏をGitプロジェクトの新たなメンテナーに任命しました](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/)。Torvalds氏は引き続きGitにコントリビュートしているものの、徐々にGitプロジェクトへの関わりは薄れていきました。これは、Linuxプロジェクトの責任者として多忙を極めているため、当然のことでした。\n\n現在でも、引き続き濱野氏がGitプロジェクトを率いています。\n\n## Git 1.0\n\n濱野氏は、2025年12月21日にGitの最初のメジャーリリースを行いました。興味深いことに、バージョン0.99から1.0の間には、34回もリリースが行われました（0.99.1～0.99.7、0.99.7a～0.99.7d、0.99.8～0.99.8g、0.99.9～0.99.9n）。\n\n0.99以降の特に重要なマイルストーンのひとつは、おそらく2つのツリーを相互にマージできる`git-merge(1)`コマンドの追加でしょう。それまでは基本的にファイルのマージを行う場合、ファイルごとにスクリプトを作成する必要があったことを考えると、非常に対照的です。\n\n### リモート\n\nもう1つの大きな変化は、リモートリポジトリの省略記法が導入されたことです。すでにGitからリモートリポジトリを操作することはできましたが、変更をフェッチする際に毎回、対象のリポジトリのURLを指定する必要がありました。通常は同じリモートリポジトリと何度もやり取りを行うため、これはユーザーにとってかなり使い勝手の悪い仕様でした。\n\n現在のremoteコマンドの仕組みはご存知だと思いますが、当時の仕組みはまだ大きく異なっていました。リモートリポジトリを管理するための`git-remote(1)`コマンドはまだ存在しておらず、リモートリポジトリの情報は`.git/config`ファイルに保存すらされていませんでした。実のところ、バージョン0.99.2でremoteコマンドが最初に導入された際、Gitにはconfigファイル自体*ありませんでした*。\n\n代わりに、`.git/branches`に直接ファイルを書き込んでリモートリポジトリの設定を行う必要がありました。今となってはあまり直感的な方法とは思えません。しかしながら、この仕組みは今でも動作します。\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nそれだけではなく、その直後にGitバージョン0.99.5でディレクトリ名が「remotes」に変更されたため、現在のGitクライアントではリモートリポジトリの設定方法が全部で3つあります。\n\nおそらく多くの方は、`.git/branches`も`.git/remotes`も使ったことがないと思います。これらはそれぞれ、2005年、および2011年以降、非推奨化されています。また、最終的にこれらのディレクトリは、Git 3.0で削除される予定です。\n\n## Gitのブランディング\n\n2007年に、Gitの最初のロゴが作成されました。これは、単に3つの緑のプラス記号の上に3つの赤いマイナス記号が配置された構成（`git diff`の出力がどのように見えるかを表していた）だったため、ロゴと呼べるかどうかについては、議論の余地があります。\n\n![`git diff`の出力がどのように見えるかを表し、3つの緑のプラス記号の上に3つの赤いマイナス記号が配置されている](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nそれから少し経った2008年に、ウェブサイト[git-scm.com](https://git-scm.com)が公開されました。\n\n![2026年時点でのgit-scm.comのランディングページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\n2012年に、Scott Chacon氏とJason Long氏によって、Gitのウェブサイトは[リニューアル](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/)されました。ご覧のように現在の外観にかなり近くなりました。\n\n![2012年にリニューアルされたGitウェブサイト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\n再デザインされたウェブサイトには、Jason Long氏がデザインし、今でも使用されている新しい赤橙色のロゴが目立つように掲載されていました。\n\n![Gitロゴ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nGit 1.0のリリース時点で、すでに現在のGitとかなり同じようになってきたため、ここでGitの歴史をたどる旅の歩みをGit 2.0まで進めます。Git 1.0の約10年後にリリースされたこのバージョンは、中央ワークフローに後方互換性のない変更を意図的に含めた最初のリリースでした。\n\n### `git-push(1)`のデフォルトの動作\n\nこのリリースで最も混乱を招いたのは、間違いなく`git-push(1)`のデフォルトの動作が変更されたことです。\n\nリモートリポジトリへのプッシュ時に何をプッシュするかを具体的に指定しなかった場合、Gitは以下のいずれかのアクションを取る可能性がありました。\n\n- Gitは何も実行せず、何をプッシュするか具体的な情報をユーザーに要求する。\n- その時点でチェックアウトされているブランチをプッシュする。\n- その時点でチェックアウトされているブランチをプッシュする（ただし、リモート側に対応するブランチがあることを確認できた場合に限る）。\n- リモート側に対応するブランチが存在する全ブランチをプッシュする。\n\n現在のGitは、いわゆる「シンプル」な手法を採用しており、上記の3番目のアクションを行います。しかしながら、Git 2.0より前のバージョンにおけるデフォルトの動作は、「マッチング」手法を使用した上記の最後のアクションでした。\n\n「マッチング」手法は、現在採用されている手法と比べて、はるかにリスクがありました。プッシュする前に毎回、リモート側に対応するブランチがあるすべてのローカルブランチをプッシュしても問題がないか確認する必要がありました。そうしないと、意図せずに変更がプッシュされてしまう可能性がありました。そこでリスクを軽減し、Gitを使い始めたばかりのユーザーにとって使い勝手をよくするために「シンプル」手法が採用されました。\n\n### `git-add(1)`\n\nもう1つの大きな変化は、削除された追跡済みファイルに対する`git-add(1)`のデフォルトの動作が変更されたことです。Git 2.0より前のバージョンでは、`git-add(1)`は削除済みのファイルを自動的にステージングしませんでした。そのため、コミットに含めるには、`git-rm(1)`を使用して削除済みのファイルを1つずつ手動で追加する必要がありました。Git 2.0ではこの動作が変更され、`git-add(1)`を実行すると、削除済みのファイルもインデックスに追加されるようになりました。\n\n## Gitコミュニティの業績を称えよう\n\nおそらくみなさんGitを日々活用しているかと思いますので、Gitの現在の仕組みについて細かくはここでは取り上げません。まだ活用していない方向けには、利用開始に役立つチュートリアルが多数用意されています。現在の仕組みについて説明する代わりに、Git誕生から20年経った今でも機能するように取り組んでくださったGitコミュニティの業績を称えたいと思います。\n\nGitは、その歴史の中で以下の実績を達成してきました。\n\n- Git 2.49のリリース時点での累計コミット件数、56,721件\n- 2,000人の個人のコントリビューターによるコントリビュート\n- 公開されたメジャーリリース件数、60件\n\nまた、Gitプロジェクトは[Google Summer of Code（GSOC）](https://summerofcode.withgoogle.com/)や[Outreachy](https://www.outreachy.org/)にも参加しており、新たなコントリビューターが着実に増えています。このような新たなコントリビューターのおかげで、Gitプロジェクトは長期的に健全な状態を保てます。\n\nこの場を借りて、すべてのコントリビューターに心からお礼申し上げます。みなさんのコントリビュートのおかげで、Gitが実現しました。\n\n## 今後の展開\n\nGitがバージョン管理システムの競争で事実上勝利を収めたと言っても、異論はほとんどないでしょう。Gitは大きな市場シェアを占めており、Git以外のバージョン管理システムを使用しているオープンソースプロジェクトはほとんどありません。そう考えると、Gitが多くのことを正しく成し遂げてきたことは明らかです。\n\nとは言っても、Gitの開発は完結したわけではなく、依存として多くの課題が残されています。その例が、以下のような技術的な課題です。\n- 古くなったコードベースのモダナイゼーション  - 拡大し続けるモノレポのサイズに合わせたスケーリング  - サイズの大きいバイナリファイルの処理の改善\n\nそれとは別に、以下のような社会的な課題もあります。\n- Gitの使いやすさの向上  - 長期にわたってプロジェクトの健全性を確保することを目的とした、Gitコミュニティの育成 \n取り組むべき作業は常にあります。次の20年もGitが素晴らしいバージョン管理システムであり続けられるよう、私たちGitLabもコントリビュートできることを誇りに思います。\n\n## Git関連のその他のリソース\n\n- [Gitの生みの親であるLinus Torvalds氏と20周年を祝う](https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/)\n- [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  - [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)  - [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)","open-source",{"slug":13,"featured":14,"template":15},"journey-through-gits-20-year-history",true,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21},"初めて行われたコミット、初期リリースのユニークな特徴、そしてgit-push(1)のデフォルト動作の変更によって生じた混乱について、一緒に振り返っていきましょう。",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","2025-04-14",[22,23],"open source","git","yml",null,{},"/ja-jp/blog/journey-through-gits-20-year-history","seo:\n  title: 20年にわたるGitの歴史をたどる\n  description: >-\n    初めて行われたコミット、初期リリースのユニークな特徴、そしてgit-push(1)のデフォルト動作の変更によって生じた混乱について、一緒に振り返っていきましょう。\n  ogTitle: 20年にわたるGitの歴史をたどる\n  ogDescription: >-\n    初めて行われたコミット、初期リリースのユニークな特徴、そしてgit-push(1)のデフォルト動作の変更によって生じた混乱について、一緒に振り返っていきましょう。\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png\n  ogUrl: https://about.gitlab.com/blog/journey-through-gits-20-year-history\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/journey-through-gits-20-year-history\ncontent:\n  title: 20年にわたるGitの歴史をたどる\n  description: >-\n    初めて行われたコミット、初期リリースのユニークな特徴、そしてgit-push(1)のデフォルト動作の変更によって生じた混乱について、一緒に振り返っていきましょう。\n  authors:\n    - Patrick Steinhardt\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png\n  date: '2025-04-14'\n  body:\n    \"Gitプロジェクトはちょうど20周年を迎えました。20年の間にさまざまなことがありました。Gitの概念的なデザインは、その登場以来大きく変わって\\\n    はいないものの、ユーザーによるGitの操作方法は大きく変化しました。GitLabは、この重要な技術をベースにサービスを構築し、その歴史の一部であること\\\n    を誇りに思っています。\n\n\n    それでは、Gitの歴史をたどり、長年にわたってどのように進化を遂げてきたかを一緒に見ていきましょう。\n\n\n    ## 初めてのコミット\n\n\n    初めてのコミットは、2005年4月7日にLinuxカーネルの生みの親であるLinus Torvalds氏によって行われました。`e83c5163316\n    (Initial revision of \\\"git\\\", the information manager from hell,\n    2005-04-07)`\n\n\n    ご覧のとおり、このコミットには多くのファイルは含まれていませんでした。\n\n\n    ```shell\n\n    $ git ls-tree e83c5163316\n\n    100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\\tMakefile\n\n    100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\\tREADME\n\n    100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\\tcache.h\n\n    100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\\tcat-file.c\n\n    100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\\tcommit-tree.c\n\n    100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\\tinit-db.c\n\n    100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\\tread-cache.c\n\n    100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\\tread-tree.c\n\n    100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\\tshow-diff.c\n\n    100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\\tupdate-cache.c\n\n    100644 blob 921f981353229db0c56103a52609d35aff16f41b\\twrite-tree.c\n\n    ```\n\n\n    ビルドインフラストラクチャに加え、最初のコミットでは以下の7つのトップレベルコマンドが提供されていました。\n\n\n    - `init-db`：新たなGitリポジトリを初期化\n\n    - `update-cache`：インデックスにファイルを追加\n\n    - `write-tree`：インデックスの内容を取得し、それをもとに新たなツリーを作成\n\n    - `read-tree`：ツリーオブジェクトを読み込む\n\n    - `commit-tree`：ツリーからコミットを作成\n\n    - `cat-file`：特定のオブジェクトを一時ファイルに読み込む\n\n\n    なお、この時点では、`git`コマンド自体存在していませんでした。代わりに、上記のコマンドを直接実行する必要がありました。\n\n\n    では、試しにリポジトリを新規作成してみましょう。\n\n\n    ```shell\n\n    $ mkdir repo\n\n    $ cd repo\n\n    $ init-db\n\n    defaulting to private storage area\n\n    $ ls -a\n\n    .  ..  .dircache\n\n    ```\n\n\n    みなさんにはまったくなじみがないと思います。`.git`ディレクトリではなく、`.dircache`ディレクトリが使用されていました。では、プライベー\\\n    トストレージ領域はどこでしょうか？\n\n\n    初期のGitのデザインでは、オブジェクトストレージ領域は「共有」と「プライベート」に分かれていました。このオブジェクトストレージ領域には、コミットやb\\\n    lobなども含め、あらゆるGitオブジェクトが格納されていました。\n\n\n    `init-db`は、デフォルトではプライベートオブジェクトストレージ領域を作成します。これは、領域の作成先の管理ディレクトリ専用として使用されていま\\\n    した。一方、同じオブジェクトを二重に保存する必要がないように、「共有」オブジェクトストレージ領域を使用して、複数の管理ディレクトリ間でオブジェクトの内\\\n    容を共有していました。\n\n\n    ### コミットを作成する\n\n\n    リポジトリの作成後は、どのようにコミットを作成していたのでしょうか？作成方法は、現在利用可能な`git add . && git\n    commit`ほどシンプルではありませんでした。その代わりに、以下の方法で行っていました。\n\n\n    1. 追加するファイルごとに`update-cache`を呼び出してインデックスを更新する。\n\n    1. `write-tree`を呼び出して新規ツリーを書き込む。インデックスに追加済みのすべての内容をもとに作成される。\n\n    1. 環境変数を設定して、Gitにコミッターの情報を伝える。\n\n    1. `commit-tree`を呼び出して、コミットオブジェクトを書き込む。\n\n\n    それでは、リポジトリにコミットを作成してみましょう。\n\n\n    ```shell\n\n    $ echo content-1 >file-a\n\n    $ update-cache file-a\n\n    $ echo content-2 >file-b\n\n    $ update-cache file-b\n\n    $ write-tree\n\n    3f143dfb48f2d84936626e2e5402e1f10c2050fb\n\n    $ export COMMITTER_NAME=\\\"Patrick Steinhardt\\\"\n\n    $ export COMMITER_EMAIL=ps@pks.im\n\n    $ echo \\\"commit message\\\" | commit-tree\n    3f143dfb48f2d84936626e2e5402e1f10c2050fb\n\n    Committing initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n\n    5f8e928066c03cebe5fd0a0cc1b93d058155b969\n\n    ```\n\n\n    人間工学的な方法とは言えないものの、コミットは作成されます。それでは、生成されたコミットを見てみましょう。\n\n\n    ```shell\n\n    $ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\n\n    temp_git_file_rlTXtE: commit\n\n    $ cat temp_git_file_rlTXtE\n\n    tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n\n    author Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\n    committer Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\n\n    commit message\n\n    ```\n\n\n    注目していただきたいのは、`cat-file`は内容を直接表示せず、まずは一時ファイルに書き出す点です。しかしながら、ファイルの内容は、まさに現代的な\\\n    コミットと同じように見えます。\n\n\n    ### 変更を加える\n\n\n    ファイルの作成後、どのようにステータスを確認していたのでしょうか？おそらくお察しのとおりで、`show-diff`を使用していました。\n\n\n    ```shell\n\n    $ show-diff\n\n    file-a: ok\n\n    file-b: ok\n\n\n    $ echo modified-content >file-a\n\n    $ show-diff\n\n    --- -\\t2025-03-26 13:14:53.457611094 +0100\n\n    +++ file-a\\t2025-03-26 13:14:52.230085756 +0100\n\n    @@ -1 +1 @@\n\n    -content-1\n\n    +modified-content\n\n    file-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\n\n    file-b: ok\n\n    ```\n\n\n    驚くべきことに、すでに`show-diff`では、変更されたファイルの新旧の状態を比較して差分を取得していました。しかも面白いことに、Gitではこれを\\\n    UNIXのdiff(1)ツールを使用するという簡単な方法で実現していました。\n\n\n    つまり、これらはすべて必要最低限の機能しか備えていなかったものの、履歴の追跡に必要なすべての役割を果たしていました。以下のように制限は多数ありました。\n\n\n    - あるコミットから別のコミットへ簡単に切り替える方法がなかった。\n\n    - ログを表示できなかった。\n\n    - ブランチやtag、また参照すら存在しなかった。そのため、ユーザーは手動でオブジェクトIDを追跡しなければならなかった。\n\n    -\n    2つのリポジトリを相互に同期させる方法がなかった。代わりに、ユーザーがrsync(1)を使用して、`.dircache`ディレクトリを同期させる必要が\\\n    あった。\n\n    - マージの実行方法がなかった。\n\n\n    ## Git 0.99\n\n\n    Gitの最初のテストリリースは、バージョン0.99でした。バージョン0.99は、最初のコミットからわずか2か月後にリリースされたものの、すでに1,07\\\n    6件のコミットが追加されていました。約50人のデベロッパーが開発に携わっており、最も頻繁にコミットを行っていたのはTorvalds氏自身でした。トーバ\\\n    ルズ氏に続く勢いで、コミット件数の多かったコミッターは、現在メンテナーを務めている濱野純氏でした。\n\n\n    最初のコミット以降、多数の変更が加えられました。\n\n\n    - Gitは参照を使って複数の開発ブランチを追跡するようになりました。その結果、大抵の場合、手作業でオブジェクトIDを追跡せずに済むようになりました。\n\n    - 新たにリモートプロトコルが導入され、2つのリポジトリ間で相互にオブジェクトを交換できるようになりました。\n\n    - `.dircache`ディレクトリの名前が`.git`に変更されました。\n\n    - 個々のファイルを相互にマージできるようになりました。\n\n\n    ただし、最も重要かつ顕著な変化は、トップレベルの`git`コマンドとそのサブコマンドが導入されたことでした。興味深いことに、「配管（plumbing）\\\n    」コマンドと「磁器（porcelain）」コマンドの概念が導入されたのも、このリリースです。\n\n\n    - 「配管」ツールは、基盤となるGitリポジトリにアクセスして低レベルな処理を行うコマンドです。\n\n    - 「磁器」ツールは、「配管」コマンドをラップして、高レベルでよりユーザーフレンドリーなユーザーインターフェイスを提供するShellスクリプトです。\n\n\n    Gitには現在でもこの分け方は採用されており、[`git(1)`](https://git-scm.com/docs/git#_high_level_\\\n    commands_porcelain)にも概説されています。しかしながら、「磁器」ツールの大半はShellスクリプトからC言語に書き直されたため、これ\\\n    らの2つのカテゴリ間の境界線はかなり曖昧になってきています。\n\n\n    ## Torvalds氏、メンテナーの役割を濱野氏に引き継ぐ\n\n\n    Torvalds氏がGitに取り掛かった理由は、バージョン管理システムが好きだったためではなく、Linuxカーネル開発のためにBitKeeperの代替\\\n    ツールを必要としていたためです。そのため、Gitのメンテナンスをずっと続けるつもりはなく、信頼できる人が現れるまで、メンテナーを務めようと考えていまし\\\n    た。\n\n\n    その条件に当てはまったのが、濱野純氏でした。濱野氏は、Torvalds氏が最初のコミットを行った約1週間後にGitの開発に参加しました。Git\n    0.99のリリース後にはすでに数百件のコミットを行っていました。そのため、2005年7月26日に、[Torvalds氏は濱野氏をGitプロジェクトの新\\\n    たなメンテナーに任命しました](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.322\\\n    7@g5.osdl.org/)。Torvalds氏は引き続きGitにコントリビュートしているものの、徐々にGitプロジェクトへの関わりは薄れていきまし\\\n    た。これは、Linuxプロジェクトの責任者として多忙を極めているため、当然のことでした。\n\n\n    現在でも、引き続き濱野氏がGitプロジェクトを率いています。\n\n\n    ## Git 1.0\n\n\n    濱野氏は、2025年12月21日にGitの最初のメジャーリリースを行いました。興味深いことに、バージョン0.99から1.0の間には、34回もリリースが\\\n    行われました（0.99.1～0.99.7、0.99.7a～0.99.7d、0.99.8～0.99.8g、0.99.9～0.99.9n）。\n\n\n    0.99以降の特に重要なマイルストーンのひとつは、おそらく2つのツリーを相互にマージできる`git-merge(1)`コマンドの追加でしょう。それまで\\\n    は基本的にファイルのマージを行う場合、ファイルごとにスクリプトを作成する必要があったことを考えると、非常に対照的です。\n\n\n    ### リモート\n\n\n    もう1つの大きな変化は、リモートリポジトリの省略記法が導入されたことです。すでにGitからリモートリポジトリを操作することはできましたが、変更をフェッ\\\n    チする際に毎回、対象のリポジトリのURLを指定する必要がありました。通常は同じリモートリポジトリと何度もやり取りを行うため、これはユーザーにとってかな\\\n    り使い勝手の悪い仕様でした。\n\n\n    現在のremoteコマンドの仕組みはご存知だと思いますが、当時の仕組みはまだ大きく異なっていました。リモートリポジトリを管理するための`git-rem\\\n    ote(1)`コマンドはまだ存在しておらず、リモートリポジトリの情報は`.git/config`ファイルに保存すらされていませんでした。実のところ、バ\\\n    ージョン0.99.2でremoteコマンドが最初に導入された際、Gitにはconfigファイル自体*ありませんでした*。\n\n\n    代わりに、`.git/branches`に直接ファイルを書き込んでリモートリポジトリの設定を行う必要がありました。今となってはあまり直感的な方法とは思\\\n    えません。しかしながら、この仕組みは今でも動作します。\n\n\n    ```shell\n\n    $ git init repo --\n\n    Initialized empty Git repository in /tmp/repo/.git/\n\n    $ cd repo\n\n    $ mkdir .git/branches\n\n    $ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n\n    $ git fetch origin refs/heads/master\n\n    ```\n\n\n    それだけではなく、その直後にGitバージョン0.99.5でディレクトリ名が「remotes」に変更されたため、現在のGitクライアントではリモートリポ\\\n    ジトリの設定方法が全部で3つあります。\n\n\n    おそらく多くの方は、`.git/branches`も`.git/remotes`も使ったことがないと思います。これらはそれぞれ、2005年、および20\\\n    11年以降、非推奨化されています。また、最終的にこれらのディレクトリは、Git 3.0で削除される予定です。\n\n\n    ## Gitのブランディング\n\n\n    2007年に、Gitの最初のロゴが作成されました。これは、単に3つの緑のプラス記号の上に3つの赤いマイナス記号が配置された構成（`git\n    diff`の出力がどのように見えるかを表していた）だったため、ロゴと呼べるかどうかについては、議論の余地があります。\n\n\n    ![`git\n    diff`の出力がどのように見えるかを表し、3つの緑のプラス記号の上に3つの赤いマイナス記号が配置されている](https://res.cloudin\\\n    ary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blo\\\n    g/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\n\n    それから少し経った2008年に、ウェブサイト[git-scm.com](https://git-scm.com)が公開されました。\n\n\n    ![2026年時点でのgit-scm.comのランディングページ](https://res.cloudinary.com/about-gitlab-c\\\n    om/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/ima\\\n    ge4_aHR0cHM6_1750097387930.png)\n\n\n    2012年に、Scott Chacon氏とJason\n    Long氏によって、Gitのウェブサイトは[リニューアル](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F7\\\n    2h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/)されました。ご覧のように現在の外観にかなり近くな\\\n    りました。\n\n\n    ![2012年にリニューアルされたGitウェブサイト](https://res.cloudinary.com/about-gitlab-com/ima\\\n    ge/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aH\\\n    R0cHM6_1750097387932.png)\n\n\n    再デザインされたウェブサイトには、Jason Long氏がデザインし、今でも使用されている新しい赤橙色のロゴが目立つように掲載されていました。\n\n\n    ![Gitロゴ](https://res.cloudinary.com/about-gitlab-com/image/upload/v17500973\\\n    88/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_175009738793\\\n    4.png)\n\n\n    ## Git 2.0\n\n\n    Git 1.0のリリース時点で、すでに現在のGitとかなり同じようになってきたため、ここでGitの歴史をたどる旅の歩みをGit\n    2.0まで進めます。Git\n    1.0の約10年後にリリースされたこのバージョンは、中央ワークフローに後方互換性のない変更を意図的に含めた最初のリリースでした。\n\n\n    ### `git-push(1)`のデフォルトの動作\n\n\n    このリリースで最も混乱を招いたのは、間違いなく`git-push(1)`のデフォルトの動作が変更されたことです。\n\n\n    リモートリポジトリへのプッシュ時に何をプッシュするかを具体的に指定しなかった場合、Gitは以下のいずれかのアクションを取る可能性がありました。\n\n\n    - Gitは何も実行せず、何をプッシュするか具体的な情報をユーザーに要求する。\n\n    - その時点でチェックアウトされているブランチをプッシュする。\n\n    - その時点でチェックアウトされているブランチをプッシュする（ただし、リモート側に対応するブランチがあることを確認できた場合に限る）。\n\n    - リモート側に対応するブランチが存在する全ブランチをプッシュする。\n\n\n    現在のGitは、いわゆる「シンプル」な手法を採用しており、上記の3番目のアクションを行います。しかしながら、Git\n    2.0より前のバージョンにおけるデフォルトの動作は、「マッチング」手法を使用した上記の最後のアクションでした。\n\n\n    「マッチング」手法は、現在採用されている手法と比べて、はるかにリスクがありました。プッシュする前に毎回、リモート側に対応するブランチがあるすべてのロー\\\n    カルブランチをプッシュしても問題がないか確認する必要がありました。そうしないと、意図せずに変更がプッシュされてしまう可能性がありました。そこでリスクを\\\n    軽減し、Gitを使い始めたばかりのユーザーにとって使い勝手をよくするために「シンプル」手法が採用されました。\n\n\n    ### `git-add(1)`\n\n\n    もう1つの大きな変化は、削除された追跡済みファイルに対する`git-add(1)`のデフォルトの動作が変更されたことです。Git\n    2.0より前のバージョンでは、`git-add(1)`は削除済みのファイルを自動的にステージングしませんでした。そのため、コミットに含めるには、`gi\\\n    t-rm(1)`を使用して削除済みのファイルを1つずつ手動で追加する必要がありました。Git\n    2.0ではこの動作が変更され、`git-add(1)`を実行すると、削除済みのファイルもインデックスに追加されるようになりました。\n\n\n    ## Gitコミュニティの業績を称えよう\n\n\n    おそらくみなさんGitを日々活用しているかと思いますので、Gitの現在の仕組みについて細かくはここでは取り上げません。まだ活用していない方向けには、利\\\n    用開始に役立つチュートリアルが多数用意されています。現在の仕組みについて説明する代わりに、Git誕生から20年経った今でも機能するように取り組んでくだ\\\n    さったGitコミュニティの業績を称えたいと思います。\n\n\n    Gitは、その歴史の中で以下の実績を達成してきました。\n\n\n    - Git 2.49のリリース時点での累計コミット件数、56,721件\n\n    - 2,000人の個人のコントリビューターによるコントリビュート\n\n    - 公開されたメジャーリリース件数、60件\n\n\n    また、Gitプロジェクトは[Google Summer of\n    Code（GSOC）](https://summerofcode.withgoogle.com/)や[Outreachy](https://www.o\\\n    utreachy.org/)にも参加しており、新たなコントリビューターが着実に増えています。このような新たなコントリビューターのおかげで、Gitプロジ\\\n    ェクトは長期的に健全な状態を保てます。\n\n\n    この場を借りて、すべてのコントリビューターに心からお礼申し上げます。みなさんのコントリビュートのおかげで、Gitが実現しました。\n\n\n    ## 今後の展開\n\n\n    Gitがバージョン管理システムの競争で事実上勝利を収めたと言っても、異論はほとんどないでしょう。Gitは大きな市場シェアを占めており、Git以外のバー\\\n    ジョン管理システムを使用しているオープンソースプロジェクトはほとんどありません。そう考えると、Gitが多くのことを正しく成し遂げてきたことは明らかです。\n\n\n    とは言っても、Gitの開発は完結したわけではなく、依存として多くの課題が残されています。その例が、以下のような技術的な課題です。\n\n    - 古くなったコードベースのモダナイゼーション \\\n\n    - 拡大し続けるモノレポのサイズに合わせたスケーリング \\\n\n    - サイズの大きいバイナリファイルの処理の改善\n\n\n    それとは別に、以下のような社会的な課題もあります。\n\n    - Gitの使いやすさの向上 \\\n\n    - 長期にわたってプロジェクトの健全性を確保することを目的とした、Gitコミュニティの育成 \\\n\n\n    取り組むべき作業は常にあります。次の20年もGitが素晴らしいバージョン管理システムであり続けられるよう、私たちGitLabもコントリビュートできるこ\\\n    とを誇りに思います。\n\n\n    ## Git関連のその他のリソース\n\n\n    - [Gitの生みの親であるLinus\n    Torvalds氏と20周年を祝う](https://about.gitlab.com/blog/celebrating-gits-20th-anni\\\n    versary-with-creator-linus-torvalds/)\n\n    - [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)\n    \\\n\n    - [Git\n    2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/) \\\n\n    - [初心者向けGit\n    reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to\\\n    -the-git-reftable-format/)\"\n  category: open-source\n  tags:\n    - open source\n    - git\nconfig:\n  slug: journey-through-gits-20-year-history\n  featured: true\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":30,"ogImage":19,"ogUrl":31,"ogSiteName":32,"ogType":33,"canonicalUrls":31},false,"https://about.gitlab.com/blog/journey-through-gits-20-year-history","https://about.gitlab.com","article","ja-jp/blog/journey-through-gits-20-year-history",[11,23],[22,23],"o5unhCc5YrVWHmaW2ejyQ_IBNJHxnEesPrnuVjkrV-o",{"data":39},{"logo":40,"freeTrial":45,"sales":50,"login":55,"items":60,"search":369,"minimal":402,"duo":419,"switchNav":428,"pricingDeployment":439},{"config":41},{"href":42,"dataGaName":43,"dataGaLocation":44},"/ja-jp/","gitlab logo","header",{"text":46,"config":47},"無料トライアルを開始",{"href":48,"dataGaName":49,"dataGaLocation":44},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":51,"config":52},"お問い合わせ",{"href":53,"dataGaName":54,"dataGaLocation":44},"/ja-jp/sales/","sales",{"text":56,"config":57},"サインイン",{"href":58,"dataGaName":59,"dataGaLocation":44},"https://gitlab.com/users/sign_in/","sign in",[61,88,185,190,291,351],{"text":62,"config":63,"cards":65},"プラットフォーム",{"dataNavLevelOne":64},"platform",[66,72,80],{"title":62,"description":67,"link":68},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":69,"config":70},"プラットフォームを探索",{"href":71,"dataGaName":64,"dataGaLocation":44},"/ja-jp/platform/",{"title":73,"description":74,"link":75},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":76,"config":77},"GitLab Duoのご紹介",{"href":78,"dataGaName":79,"dataGaLocation":44},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":81,"description":82,"link":83},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":84,"config":85},"詳細はこちら",{"href":86,"dataGaName":87,"dataGaLocation":44},"/ja-jp/why-gitlab/","why gitlab",{"text":89,"left":14,"config":90,"link":92,"lists":96,"footer":167},"製品",{"dataNavLevelOne":91},"solutions",{"text":93,"config":94},"すべてのソリューションを表示",{"href":95,"dataGaName":91,"dataGaLocation":44},"/ja-jp/solutions/",[97,122,145],{"title":98,"description":99,"link":100,"items":105},"自動化","CI/CDと自動化でデプロイを加速",{"config":101},{"icon":102,"href":103,"dataGaName":104,"dataGaLocation":44},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[106,110,113,118],{"text":107,"config":108},"CI/CD",{"href":109,"dataGaLocation":44,"dataGaName":107},"/ja-jp/solutions/continuous-integration/",{"text":73,"config":111},{"href":78,"dataGaLocation":44,"dataGaName":112},"gitlab duo agent platform - product menu",{"text":114,"config":115},"ソースコード管理",{"href":116,"dataGaLocation":44,"dataGaName":117},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":119,"config":120},"自動化されたソフトウェアデリバリー",{"href":103,"dataGaLocation":44,"dataGaName":121},"Automated software delivery",{"title":123,"description":124,"link":125,"items":130},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":126},{"href":127,"dataGaName":128,"dataGaLocation":44,"icon":129},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[131,135,140],{"text":132,"config":133},"アプリケーションセキュリティテスト",{"href":127,"dataGaName":134,"dataGaLocation":44},"Application security testing",{"text":136,"config":137},"ソフトウェアサプライチェーンの安全性",{"href":138,"dataGaLocation":44,"dataGaName":139},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":141,"config":142},"ソフトウェアコンプライアンス",{"href":143,"dataGaName":144,"dataGaLocation":44},"/ja-jp/solutions/software-compliance/","software compliance",{"title":146,"link":147,"items":152},"測定",{"config":148},{"icon":149,"href":150,"dataGaName":151,"dataGaLocation":44},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[153,157,162],{"text":154,"config":155},"可視性と測定",{"href":150,"dataGaLocation":44,"dataGaName":156},"Visibility and Measurement",{"text":158,"config":159},"バリューストリーム管理",{"href":160,"dataGaLocation":44,"dataGaName":161},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":163,"config":164},"分析とインサイト",{"href":165,"dataGaLocation":44,"dataGaName":166},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLabが活躍する場所",[170,175,180],{"text":171,"config":172},"大企業",{"href":173,"dataGaLocation":44,"dataGaName":174},"/ja-jp/enterprise/","enterprise",{"text":176,"config":177},"スモールビジネス",{"href":178,"dataGaLocation":44,"dataGaName":179},"/ja-jp/small-business/","small business",{"text":181,"config":182},"公共部門",{"href":183,"dataGaLocation":44,"dataGaName":184},"/ja-jp/solutions/public-sector/","public sector",{"text":186,"config":187},"価格",{"href":188,"dataGaName":189,"dataGaLocation":44,"dataNavLevelOne":189},"/ja-jp/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":278},"リソース",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"すべてのリソースを表示",{"href":197,"dataGaName":193,"dataGaLocation":44},"/ja-jp/resources/",[199,232,250],{"title":200,"items":201},"はじめに",[202,207,212,217,222,227],{"text":203,"config":204},"インストール",{"href":205,"dataGaName":206,"dataGaLocation":44},"/ja-jp/install/","install",{"text":208,"config":209},"クイックスタートガイド",{"href":210,"dataGaName":211,"dataGaLocation":44},"/ja-jp/get-started/","quick setup checklists",{"text":213,"config":214},"学ぶ",{"href":215,"dataGaLocation":44,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"製品ドキュメント",{"href":220,"dataGaName":221,"dataGaLocation":44},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":223,"config":224},"ベストプラクティスビデオ",{"href":225,"dataGaName":226,"dataGaLocation":44},"/ja-jp/getting-started-videos/","best practice videos",{"text":228,"config":229},"インテグレーション",{"href":230,"dataGaName":231,"dataGaLocation":44},"/ja-jp/integrations/","integrations",{"title":233,"items":234},"検索する",[235,240,245],{"text":236,"config":237},"お客様成功事例",{"href":238,"dataGaName":239,"dataGaLocation":44},"/ja-jp/customers/","customer success stories",{"text":241,"config":242},"ブログ",{"href":243,"dataGaName":244,"dataGaLocation":44},"/ja-jp/blog/","blog",{"text":246,"config":247},"リモート",{"href":248,"dataGaName":249,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":251,"items":252},"つなげる",[253,258,263,268,273],{"text":254,"config":255},"GitLabサービス",{"href":256,"dataGaName":257,"dataGaLocation":44},"/ja-jp/services/","services",{"text":259,"config":260},"コミュニティ",{"href":261,"dataGaName":262,"dataGaLocation":44},"/community/","community",{"text":264,"config":265},"フォーラム",{"href":266,"dataGaName":267,"dataGaLocation":44},"https://forum.gitlab.com/","forum",{"text":269,"config":270},"イベント",{"href":271,"dataGaName":272,"dataGaLocation":44},"/events/","events",{"text":274,"config":275},"パートナー",{"href":276,"dataGaName":277,"dataGaLocation":44},"/ja-jp/partners/","partners",{"background":279,"textColor":280,"text":281,"image":282,"link":286},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":283,"config":284},"ソースプロモカード",{"src":285},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":287,"config":288},"最新情報を読む",{"href":289,"dataGaName":290,"dataGaLocation":44},"/ja-jp/the-source/","the source",{"text":292,"config":293,"lists":295},"会社情報",{"dataNavLevelOne":294},"company",[296],{"items":297},[298,303,309,311,316,321,326,331,336,341,346],{"text":299,"config":300},"GitLabについて",{"href":301,"dataGaName":302,"dataGaLocation":44},"/ja-jp/company/","about",{"text":304,"config":305,"footerGa":308},"採用情報",{"href":306,"dataGaName":307,"dataGaLocation":44},"/jobs/","jobs",{"dataGaName":307},{"text":269,"config":310},{"href":271,"dataGaName":272,"dataGaLocation":44},{"text":312,"config":313},"経営陣",{"href":314,"dataGaName":315,"dataGaLocation":44},"/company/team/e-group/","leadership",{"text":317,"config":318},"チーム",{"href":319,"dataGaName":320,"dataGaLocation":44},"/company/team/","team",{"text":322,"config":323},"ハンドブック",{"href":324,"dataGaName":325,"dataGaLocation":44},"https://handbook.gitlab.com/","handbook",{"text":327,"config":328},"投資家向け情報",{"href":329,"dataGaName":330,"dataGaLocation":44},"https://ir.gitlab.com/","investor relations",{"text":332,"config":333},"トラストセンター",{"href":334,"dataGaName":335,"dataGaLocation":44},"/ja-jp/security/","trust center",{"text":337,"config":338},"AI Transparency Center",{"href":339,"dataGaName":340,"dataGaLocation":44},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":342,"config":343},"ニュースレター",{"href":344,"dataGaName":345,"dataGaLocation":44},"/company/contact/#contact-forms","newsletter",{"text":347,"config":348},"プレス",{"href":349,"dataGaName":350,"dataGaLocation":44},"/press/","press",{"text":51,"config":352,"lists":353},{"dataNavLevelOne":294},[354],{"items":355},[356,359,364],{"text":51,"config":357},{"href":53,"dataGaName":358,"dataGaLocation":44},"talk to sales",{"text":360,"config":361},"サポートを受ける",{"href":362,"dataGaName":363,"dataGaLocation":44},"https://support.gitlab.com","support portal",{"text":365,"config":366},"カスタマーポータル",{"href":367,"dataGaName":368,"dataGaLocation":44},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":370,"login":371,"suggestions":378},"閉じる",{"text":372,"link":373},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":374,"config":375},"GitLab.com",{"href":58,"dataGaName":376,"dataGaLocation":377},"search login","search",{"text":379,"default":380},"提案",[381,383,388,390,394,398],{"text":73,"config":382},{"href":78,"dataGaName":73,"dataGaLocation":377},{"text":384,"config":385},"コード提案（AI）",{"href":386,"dataGaName":387,"dataGaLocation":377},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":107,"config":389},{"href":109,"dataGaName":107,"dataGaLocation":377},{"text":391,"config":392},"GitLab on AWS",{"href":393,"dataGaName":391,"dataGaLocation":377},"/ja-jp/partners/technology-partners/aws/",{"text":395,"config":396},"GitLab on Google Cloud",{"href":397,"dataGaName":395,"dataGaLocation":377},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":399,"config":400},"GitLabを選ぶ理由",{"href":86,"dataGaName":401,"dataGaLocation":377},"Why GitLab?",{"freeTrial":403,"mobileIcon":407,"desktopIcon":412,"secondaryButton":415},{"text":46,"config":404},{"href":405,"dataGaName":49,"dataGaLocation":406},"https://gitlab.com/-/trials/new/","nav",{"altText":408,"config":409},"GitLabアイコン",{"src":410,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":408,"config":413},{"src":414,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":200,"config":416},{"href":417,"dataGaName":418,"dataGaLocation":406},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":420,"mobileIcon":424,"desktopIcon":426},{"text":421,"config":422},"GitLab Duoの詳細について",{"href":78,"dataGaName":423,"dataGaLocation":406},"gitlab duo",{"altText":408,"config":425},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":427},{"src":414,"dataGaName":411,"dataGaLocation":406},{"button":429,"mobileIcon":434,"desktopIcon":436},{"text":430,"config":431},"/switch",{"href":432,"dataGaName":433,"dataGaLocation":406},"#contact","switch",{"altText":408,"config":435},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":437},{"src":438,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":440,"mobileIcon":445,"desktopIcon":447},{"text":441,"config":442},"料金ページに戻る",{"href":188,"dataGaName":443,"dataGaLocation":406,"icon":444},"back to pricing","GoBack",{"altText":408,"config":446},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":448},{"src":414,"dataGaName":411,"dataGaLocation":406},{"title":450,"button":451,"config":456},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":452,"config":453},"GitLab Transcendを今すぐ視聴",{"href":454,"dataGaName":455,"dataGaLocation":44},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":457,"icon":458,"disabled":14},"release","AiStar",{"data":460},{"text":461,"source":462,"edit":468,"contribute":473,"config":478,"items":483,"minimal":686},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":463,"config":464},"ページのソースを表示",{"href":465,"dataGaName":466,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":469,"config":470},"このページを編集",{"href":471,"dataGaName":472,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":474,"config":475},"ご協力をお願いします",{"href":476,"dataGaName":477,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":479,"facebook":480,"youtube":481,"linkedin":482},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[484,529,582,625,652],{"title":186,"links":485,"subMenu":500},[486,490,495],{"text":487,"config":488},"プランの表示",{"href":188,"dataGaName":489,"dataGaLocation":467},"view plans",{"text":491,"config":492},"Premiumを選ぶ理由",{"href":493,"dataGaName":494,"dataGaLocation":467},"/ja-jp/pricing/premium/","why premium",{"text":496,"config":497},"Ultimateを選ぶ理由",{"href":498,"dataGaName":499,"dataGaLocation":467},"/ja-jp/pricing/ultimate/","why ultimate",[501],{"title":51,"links":502},[503,505,507,509,514,519,524],{"text":51,"config":504},{"href":53,"dataGaName":54,"dataGaLocation":467},{"text":360,"config":506},{"href":362,"dataGaName":363,"dataGaLocation":467},{"text":365,"config":508},{"href":367,"dataGaName":368,"dataGaLocation":467},{"text":510,"config":511},"ステータス",{"href":512,"dataGaName":513,"dataGaLocation":467},"https://status.gitlab.com/","status",{"text":515,"config":516},"利用規約",{"href":517,"dataGaName":518,"dataGaLocation":467},"/terms/","terms of use",{"text":520,"config":521},"プライバシーに関する声明",{"href":522,"dataGaName":523,"dataGaLocation":467},"/ja-jp/privacy/","privacy statement",{"text":525,"config":526},"Cookie 優先設定",{"dataGaName":527,"dataGaLocation":467,"id":528,"isOneTrustButton":14},"cookie preferences","ot-sdk-btn",{"title":89,"links":530,"subMenu":539},[531,535],{"text":532,"config":533},"DevSecOpsプラットフォーム",{"href":71,"dataGaName":534,"dataGaLocation":467},"devsecops platform",{"text":536,"config":537},"AI支援開発",{"href":78,"dataGaName":538,"dataGaLocation":467},"ai-assisted development",[540],{"title":541,"links":542},"トピック",[543,547,552,557,562,567,572,577],{"text":107,"config":544},{"href":545,"dataGaName":546,"dataGaLocation":467},"/ja-jp/topics/ci-cd/","cicd",{"text":548,"config":549},"GitOps",{"href":550,"dataGaName":551,"dataGaLocation":467},"/ja-jp/topics/gitops/","gitops",{"text":553,"config":554},"DevOps",{"href":555,"dataGaName":556,"dataGaLocation":467},"/ja-jp/topics/devops/","devops",{"text":558,"config":559},"バージョン管理",{"href":560,"dataGaName":561,"dataGaLocation":467},"/ja-jp/topics/version-control/","version control",{"text":563,"config":564},"DevSecOps",{"href":565,"dataGaName":566,"dataGaLocation":467},"/ja-jp/topics/devsecops/","devsecops",{"text":568,"config":569},"クラウドネイティブ",{"href":570,"dataGaName":571,"dataGaLocation":467},"/ja-jp/topics/cloud-native/","cloud native",{"text":573,"config":574},"コーディングのためのAI",{"href":575,"dataGaName":576,"dataGaLocation":467},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":578,"config":579},"エージェント型AI",{"href":580,"dataGaName":581,"dataGaLocation":467},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":583,"links":584},"ソリューション",[585,588,590,595,599,602,605,608,610,612,615,620],{"text":132,"config":586},{"href":127,"dataGaName":587,"dataGaLocation":467},"Application Security Testing",{"text":119,"config":589},{"href":103,"dataGaName":104,"dataGaLocation":467},{"text":591,"config":592},"アジャイル開発",{"href":593,"dataGaName":594,"dataGaLocation":467},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":596,"config":597},"SCM",{"href":116,"dataGaName":598,"dataGaLocation":467},"source code management",{"text":107,"config":600},{"href":109,"dataGaName":601,"dataGaLocation":467},"continuous integration & delivery",{"text":158,"config":603},{"href":160,"dataGaName":604,"dataGaLocation":467},"value stream management",{"text":548,"config":606},{"href":607,"dataGaName":551,"dataGaLocation":467},"/ja-jp/solutions/gitops/",{"text":171,"config":609},{"href":173,"dataGaName":174,"dataGaLocation":467},{"text":176,"config":611},{"href":178,"dataGaName":179,"dataGaLocation":467},{"text":613,"config":614},"公共機関",{"href":183,"dataGaName":184,"dataGaLocation":467},{"text":616,"config":617},"教育",{"href":618,"dataGaName":619,"dataGaLocation":467},"/ja-jp/solutions/education/","education",{"text":621,"config":622},"金融サービス",{"href":623,"dataGaName":624,"dataGaLocation":467},"/ja-jp/solutions/finance/","financial services",{"title":191,"links":626},[627,629,631,633,636,638,640,642,644,646,648,650],{"text":203,"config":628},{"href":205,"dataGaName":206,"dataGaLocation":467},{"text":208,"config":630},{"href":210,"dataGaName":211,"dataGaLocation":467},{"text":213,"config":632},{"href":215,"dataGaName":216,"dataGaLocation":467},{"text":218,"config":634},{"href":220,"dataGaName":635,"dataGaLocation":467},"docs",{"text":241,"config":637},{"href":243,"dataGaName":244,"dataGaLocation":467},{"text":236,"config":639},{"href":238,"dataGaName":239,"dataGaLocation":467},{"text":246,"config":641},{"href":248,"dataGaName":249,"dataGaLocation":467},{"text":254,"config":643},{"href":256,"dataGaName":257,"dataGaLocation":467},{"text":259,"config":645},{"href":261,"dataGaName":262,"dataGaLocation":467},{"text":264,"config":647},{"href":266,"dataGaName":267,"dataGaLocation":467},{"text":269,"config":649},{"href":271,"dataGaName":272,"dataGaLocation":467},{"text":274,"config":651},{"href":276,"dataGaName":277,"dataGaLocation":467},{"title":292,"links":653},[654,656,658,660,662,664,666,670,675,677,679,681],{"text":299,"config":655},{"href":301,"dataGaName":294,"dataGaLocation":467},{"text":304,"config":657},{"href":306,"dataGaName":307,"dataGaLocation":467},{"text":312,"config":659},{"href":314,"dataGaName":315,"dataGaLocation":467},{"text":317,"config":661},{"href":319,"dataGaName":320,"dataGaLocation":467},{"text":322,"config":663},{"href":324,"dataGaName":325,"dataGaLocation":467},{"text":327,"config":665},{"href":329,"dataGaName":330,"dataGaLocation":467},{"text":667,"config":668},"Sustainability",{"href":669,"dataGaName":667,"dataGaLocation":467},"/sustainability/",{"text":671,"config":672},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":673,"dataGaName":674,"dataGaLocation":467},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":332,"config":676},{"href":334,"dataGaName":335,"dataGaLocation":467},{"text":342,"config":678},{"href":344,"dataGaName":345,"dataGaLocation":467},{"text":347,"config":680},{"href":349,"dataGaName":350,"dataGaLocation":467},{"text":682,"config":683},"現代奴隷制の透明性に関する声明",{"href":684,"dataGaName":685,"dataGaLocation":467},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":687},[688,690,693],{"text":515,"config":689},{"href":517,"dataGaName":518,"dataGaLocation":467},{"text":691,"config":692},"Cookieの設定",{"dataGaName":527,"dataGaLocation":467,"id":528,"isOneTrustButton":14},{"text":520,"config":694},{"href":522,"dataGaName":523,"dataGaLocation":467},[696],{"id":697,"title":9,"body":25,"config":698,"content":700,"description":25,"extension":24,"meta":704,"navigation":14,"path":705,"seo":706,"stem":707,"__hash__":708},"blogAuthors/en-us/blog/authors/patrick-steinhardt.yml",{"template":699},"BlogAuthor",{"name":9,"config":701},{"headshot":702,"ctfId":703},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661952/Blog/Author%20Headshots/pks-gitlab-headshot.png","pksgitlab",{},"/en-us/blog/authors/patrick-steinhardt",{},"en-us/blog/authors/patrick-steinhardt","SV9Yd_vW69UbvntDP-SEOV9NKT_VwUAj5nfftf2ElSw",[710,724,739],{"content":711,"config":722},{"heroImage":712,"body":713,"authors":714,"updatedDate":716,"date":717,"title":718,"tags":719,"description":721,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1776457632/llddiylsgwuze0u1rjks.png","AIがコードを書く時代になりました。それはもはや当然のことです。しかし、計画、セキュリティ、コンプライアンス、デプロイメントはどうでしょうか？これらの課題はまだ残っています。私はコントリビュータープログラムを長年運営してきましたが、コミュニティがこれほどまでにテクノロジーに反応するのを見たことがありませんでした。\n\nそこで私たちは[GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/)を開放し、世界中の開発者に対して、チームがより安全なソフトウェアを迅速にリリースできるAIエージェントの構築を呼びかけました。質問に答えるだけのチャットボットではなく、ワークフローに直接入り込み、イベントに反応し、ユーザーの代わりに行動するエージェントです。GitLab AIハッカソンは、2026年2月9日から3月25日まで、ハッカソンプラットフォームのDevpostで開催されました。Google CloudとAnthropicがコスポンサーとして参加しました。\n\nGoogle CloudおよびAnthropicとともにこのハッカソンを企画した際、私は審査員に4つの観点でスコアリングするよう依頼しました。技術的な完成度、デザイン、潜在的なインパクト、そしてアイデアの質です。参加者が多く集まることを期待していましたが、実際の結果は私たちの予想をはるかに上回るものでした。19名の審査員が18日間かけてすべてのエントリーを審査しました。Google CloudとAnthropicは審査員、賞品、クラウドアクセスを提供しました。コミュニティは、これらの課題を解決したいという思いから、数百ものエージェントとフローを構築したのです。\n\n約7,000人の開発者が参加し、数週間で600以上のエージェントとフローを構築しました。全カテゴリーの賞金総額は、GitLab、Google Cloud、Anthropicから合計65,000ドルに上りました。\n\nベテランエンジニアが退職してチームの知識の半分を持ち去っていくのを目の当たりにしたことがある方なら、なぜグランプリ受賞プロジェクトがこれほど刺さるのか、おわかりいただけるでしょう。\n\nコミュニティが何を作り上げたのか、ぜひご覧ください。\n\n## グランプリ：LORE\n\n[LORE](https://devpost.com/software/lore-living-organizational-record-engine)（Living Organizational Record Engine）は、各質問を適切なエージェントに振り分けるルーターを備えた8つのエージェント、ナレッジグラフ内の循環ループを防ぐロジック、ビジュアルダッシュボード、そしてカーボントラッキングで構成されています。コマンドラインツールには43のテストが付属しています（ハッカソンプロジェクトで43のテストとは、驚くべき数字です）。\n\nLOREが解決するのは、エンジニアの頭の中に蓄積された知識が、退職とともに失われてしまうというリアルな問題です。私の経験上、ハッカソンプロジェクトで43のテストを書くチームはほとんどいません。その数字が、このチームの本気度を物語っています。\n\n審査員のApril Guo氏（Anthropic）はこう記しました。「ハッカソンの作品というより、製品のような完成度です。」\n\n### Google Cloud賞受賞者\n\n[Gitdefender](https://devpost.com/software/gitdefender)がGoogle Cloudグランプリを受賞しました。コードレビューのワークフロー内でセキュリティ上の問題を発見・修正します。バグを検出し、修正を記述し、コードレビューを自動でオープンします。開発者が介入する必要はありません。\n\n[Aegis](https://devpost.com/software/aegis-2m1oq0)がGoogle Cloud準グランプリを受賞しました。すべての判断に対してAIによる説明を提供し、Google Cloudにデプロイされた本番環境にも対応しています。\n\n### Anthropic賞受賞者\n\n[GraphDev](https://devpost.com/software/graphdev)がAnthropicグランプリを受賞しました。コードの依存関係をマッピングし、システムが時間とともにどのように変化したかを可視化します。審査員のAboobacker MK氏（GitLab）は「GitLabのナレッジグラフに関する私たちの取り組みと方向性が一致している」と指摘しました。また審査員のAyush Billore氏（GitLab）は「デモとUXが素晴らしく、システムの変遷や変更による影響範囲を理解するうえで非常に有用です」と述べました。変更を加える前に、その全体的な影響を把握することができます。\n\n[DocSync](https://devpost.com/software/pipeheal)がAnthropicの準グランプリを受賞しました。Detector、Writer、Reviewerの3つのエージェントを使用します。DocSyncが修正に確信を持てる場合はコードレビューをオープンし、そうでない場合は人間が確認するためのイシューを作成します。\n\n## カテゴリー賞受賞者\n\n### 最も技術的に印象的な作品\n\nデータベースのマイグレーションは障害の原因になりがちです。[Time-Traveler](https://devpost.com/software/time-traveler-w3cxp0)は、本番環境のコピーを安全に作成し、そのコピーに対してマイグレーションを実行して結果を報告します。ブリッジで接続された5つのエージェントが動作し、Google Cloudへの実際のデプロイ、実際のPostgreSQLマイグレーション、そして実際のデータを使用します。\n\n### 最もインパクトのある作品\n\n[RedAgent](https://devpost.com/software/redagent)は、AIが生成したセキュリティレポートを検証し、AI分析結果と開発者の行動の間にある信頼のギャップを解消します。セキュリティスキャンにAIを活用しているチームであれば、この問題はご存知でしょう。検証できないという理由でAIの分析結果を無視してしまうチームを、私も多く見てきました。RedAgentは、AIの出力を開発者に届ける前に検証する手段をチームに提供します。\n\n### 最も使いやすい作品\n\n[Launch Control](https://devpost.com/software/launch-control-bgp8az)は洗練されたUXと堅牢なインフラを備え、サステナビリティの面でも高評価を得ました。\n\n## サステナビリティの可能性\n\n5つのプロジェクトが、環境への配慮に対して賞またはボーナスを受賞しました。CI/CDパイプラインと同様に、ソフトウェアデリバリーにはカーボンコストがかかります。そして今や、LLMも大規模なコンピューティングリソースを消費します。私たちはGreen Agentカテゴリーを設け、開発者にそのフットプリントの計測と削減に挑戦してもらいました。GitLabのサステナビリティチームのStacy ClineとKim Buncleが、Green Agentカテゴリーの審査に参加しました。\n\n### Green Agent賞\n\n[GreenPipe](https://devpost.com/software/greenpipe)は、CI/CDパイプラインの環境負荷をスキャンし、カーボンフットプリントレポートを生成します。審査員のKim BuncleとRajesh Agadi氏（Google）の両者から高く評価されました。\n\n### サステナブルデザインボーナス\n\nサステナブルデザインボーナスは、モデルの最適化技術からエネルギー効率の高いアーキテクチャの選択に至るまで、設計において卓越したサステナビリティへの取り組みを示したプロジェクトに授与されました。\n\n* [BugFlow](https://devpost.com/software/bugflow-ai-regression-detective-ci-optimizer)は20分間で1件のバグレポートから10件の修正を実現しました。\n* [DELTA Cyber Reasoning](https://devpost.com/software/delta-cyber-reasoning-system)はセキュリティのための自動ファジングテストです。\n* [CarbonLint](https://devpost.com/software/carbonlint)はエネルギー消費にコード分析を応用しました。\n* [TFGuardian](https://devpost.com/software/tfguardian)はカーボンフットプリントアナライザーなど複数のエージェントを備えています。\n\nサステナブルデザインボーナス受賞者の皆さん、おめでとうございます！\n\n審査員のJens-Joris Decorte氏（TechWolf）は成果をこう述べています：月額コストが556ドルから18ドルに下がり、カーボン排出量が96%削減されました（サステナビリティの観点から見ても、月538ドルのコスト削減です）。\n\n## 特別賞とその他の受賞者\n\n6つのプロジェクトが特別賞を受賞しました：\n\n- [SecurityMonkey](https://devpost.com/software/securitymonkey)は既知の脆弱性をテストブランチに注入し、セキュリティスキャナーがどれだけ検知できるかをスコアリングします。\n- [stregent](https://devpost.com/software/stregent)はCI/CDパイプラインを監視し、開発者がノートPCを開かずにWhatsAppから調査・マージ修正を行えるようにします。\n- [Compliance Sentinel](https://devpost.com/software/compliance-sentinel-autonomous-devsecops-governance)はすべてのマージリクエストのコンプライアンスリスクをスコアリングし、重大な違反が検出された場合はマージをブロックします。\n- [Carbon Tracker](https://devpost.com/software/carbon-tracker-ij25kf)はCI/CDパイプラインの各ジョブのカーボンフットプリントを算出し、最適化のヒントをマージリクエストに投稿します。\n- [RepoWarden](https://devpost.com/software/docuguard)は初のLiving Specification Engineであり、コードが「何をするか」だけでなく「なぜ書かれたか」を記録するAIシステムです。\n- [MR Compliance Auditor](https://devpost.com/software/mr-compliance-auditor)はマージリクエスト全体からエビデンスを収集し、SOC 2コントロールにマッピングして、コンプライアンススコアをライブダッシュボードにストリーミングします。\n\n審査中で私が最も印象に残った言葉は、Luca Chun Lun Lit氏（Anthropic）がstregentのモバイルファーストなアプローチについて述べたものです。「スマートフォンから実質的にコーディングできるというのは、エンジニアリング体験の新たなレベルです。」\n\n> [プロジェクトギャラリー](https://gitlab.devpost.com/project-gallery)で600以上のエントリーをご覧ください。\n\n## 今後の展開\n\nこのハッカソンに参加したすべてのエージェントは、単一プロジェクト内で動作していました。それでも印象的な成果を上げています。一部の参加者は、リポジトリ内のコードの関係性や依存関係を把握するために、ローカルのナレッジグラフをエージェントと並行して動かしていました。LOREはプロジェクトの履歴を記録し、Gitdefenderは脆弱性を発見します。より豊かなローカルコンテキストとエージェントを組み合わせることで、コントリビューターはすでにより精度の高いツールを構築しつつあります。次回のハッカソンは、コントリビューターが豊かなコンテキストですでに実現していることをさらに発展させます。詳細が公開され次第いち早くお知らせを受け取るには、[contributors.gitlab.com](https://contributors.gitlab.com/)でサインアップしてください。\n\n## さあ、始めましょう\n\nこのハッカソンの舞台裏を支えてくれたLee Tickett氏（GitLab）とMattias Michaux氏（GitLab）に、特別な感謝を申し上げます！\n\n参加してくださったすべての開発者の皆さん、ありがとうございました。約7,000人のみなさんが、GitLab Duo Agent Platformの可能性を証明してくれました。皆さんが作り上げたものを誇りに思いますし、次に何を構築してくれるのか、今から楽しみです。\n\n[GitLab Duo Agent Platform](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/)で自分だけのエージェントを構築しましょう。コミュニティが作成したエージェントは[AIカタログ](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/ai_catalog/)でご覧いただけます。オーケストレーションはあなたが、加速はAIが担います。\n",[715],"Nick Veenhof","2026-04-23","2026-04-22","GitLab AIハッカソン2026：受賞者発表",[720,262],"AI/ML","約7,000人の開発者がGitLab Duo Agent Platform上で600以上のAIエージェントとフローを構築したハッカソンの結果をご紹介。",{"featured":30,"template":15,"slug":723},"gitlab-ai-hackathon-2026-meet-the-winners",{"content":725,"config":737},{"date":726,"heroImage":727,"title":728,"authors":729,"category":11,"body":731,"description":732,"tags":733},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[730],"GitLab Team","## 目次\n\n1. [git mergeとは？](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%81%A8%E3%81%AF%EF%BC%9F)\n2. [git mergeコマンドの基本](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%AE%E5%9F%BA%E6%9C%AC)\n3. [マージ先のブランチを準備する](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#%E3%83%9E%E3%83%BC%E3%82%B8%E5%85%88%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%82%92%E6%BA%96%E5%82%99%E3%81%99%E3%82%8B)\n4. [最新のリモートコミットをフェッチする](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#%E6%9C%80%E6%96%B0%E3%81%AE%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%82%B3%E3%83%9F%E3%83%83%E3%83%88%E3%82%92%E3%83%95%E3%82%A7%E3%83%83%E3%83%81%E3%81%99%E3%82%8B)\n5. [早送りマージと３ウェイマージ](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#%E6%97%A9%E9%80%81%E3%82%8A%E3%83%9E%E3%83%BC%E3%82%B8%E3%81%A8%EF%BC%93%E3%82%A6%E3%82%A7%E3%82%A4%E3%83%9E%E3%83%BC%E3%82%B8)\n6. [git mergeによるコンフリクトの解決](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%81%AB%E3%82%88%E3%82%8B%E3%82%B3%E3%83%B3%E3%83%95%E3%83%AA%E3%82%AF%E3%83%88%E3%81%AE%E8%A7%A3%E6%B1%BA)\n7. [git mergeコマンドのベストプラクティス](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%AE%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9)\n8. [GitLabでgit mergeを使う](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%AE%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9)\n9. [git merge のFAQ](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89-%E3%81%AEfaq)\n\n## git mergeとは？\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。別のリポジトリからの変更を組み込む際にも使われ、git pull（git fetchとgit mergeを組み合わせたもの）の一部としても機能します。チームで開発を実施するときなどにmainブランチから作業用ブランチを作り、テストをしてからマージ、プッシュすることも多いでしょう。\n\nたとえば、main ブランチに基づいて作成された新しいブランチ’feature’があるとします。この feature ブランチを main にマージするのに使われるのがgit mergeコマンドです。\n\n## git mergeコマンドの基本\n\ngit mergeの基本的なコードは次のようになります。\n\n```shell\ngit merge BRANCH_NAME\n```\n\nブランチ名は、取り込みたいブランチの名前を入力します。\n\n一見簡単そうですが、マージをスムーズに実行するにはいくつか準備が必要となりますので、次の章で確認しましょう。\n\n## マージ先のブランチを準備する\n\ngit status を実行して、HEAD が取り込む先のブランチであることを確認します。必要に応じて\n\n```shell\ngit checkout BRANCH_NAME\n```\n\nを実行して、マージする先のブランチに切り替えます。\n\n## 最新のリモートコミットをフェッチする\n\nリモートで変更を加えたら、マージ先ブランチとマージ元ブランチに最新の変更内容を反映させます。その際は、[git fetchとgit pull](https://about.gitlab.com/ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull/)を使います。その後、リモートで加えた変更内容がmainブランチに反映されていることを確認します。\n\n## 早送りマージと３ウェイマージ\n\n早送りマージは、ブランチが分岐していない場合にのみ使えるコマンドです。早送りマージでは、マージ自体は行われませんが、ブランチの先頭とブランチの末尾の履歴を結合することで、旧ブランチからアクセスできたコミットが、新ブランチからも利用できるようになります。\n\n強制的に早送りマージを実施する場合は以下のコードを使います（分岐がある場合など早送りマージができない場合にはエラーとなりマージはできません）\n\n```shell\ngit merge --ff-only\n```\n\n一方、ブランチが分岐している場合には、早送りマージを適用することはできず、マージする手段は３ウェイマージに限られます。３ウェイマージは、3 つのコミット （2 つのブランチのそれぞれ先端のコミットと履歴を統合するために生成される専用のコミット）を使用してマージコミットを生成することから来ています。\n\n```shell\ngit checkout BRANCH_NAME\n```\n\nを使うと、早送りマージが可能な時は早送りマージを実施し、できない時に３ウェイマージを実施します。\n\n## git mergeによるコンフリクトの解決\n\nマージの基本を理解すると、同じ箇所を同時に更新してしまったらどうなるのか、という疑問を持たれる方もいるのではないでしょうか。この場合、Git側ではどちらを優先すべきか判断ができず、手作業でコンフリクトを解決することを求めます。\n\nエラーメッセージは次のように表示されます。\n\n```shell\ngit merge BRANCH_NAME\nAuto-merging index.html\nCONFLICT (content): Merge conflict in index.html\nAutomatic merge failed; fix conflicts and then commit the result.\n```\n\nコンフリクトを解決するまで、処理は中断されます。どのファイルでコンフリクトが発生してマージできなかったのを確認するにはgit status を実行します。\n\n```shell\ngit status\n```\n\n未解決のコンフリクトについては unmerged として表示されます。標準的なコンフリクトマーカーがファイルに追加されるため、該当ファイルから修正できます。git addを実行して、コンフリクトが解決したことを Git に通知します。続いて通常の git commit を実行してマージ コミットを生成します。\n\n## git mergeコマンドのベストプラクティス\n\ngit mergeコマンドでよく起こる問題として、他のデベロッパーが加えた変更を破棄してしまうことが挙げられます。個々人がこまめにgit mergeを実行することで、変更を破棄してしまう問題は避けることができますが、マージそのもののコストが膨れ上がる可能性があります。複雑なコンフリクトが出ない場合に自動マージしてくれるようなツールの導入は、git mergeを使うチームの大きな手助けになるはずです。\n\n## GitLabでgit mergeを使う\n\ngit mergeのベストプラクティスとしてツールの使用をおすすめしましたが、[GitLab](https://about.gitlab.com/ja-jp/)なら自動マージ機能のほかにもリモートリポジトリのホスティング、インターフェースの提供、変更内容のコードレビュー、プッシュされたコードの自動ビルド、テスト、デプロイまでを一括で管理できます。\n\ngit mergeで起きるコンフリクトを自動で解決できるGitLabの無料トライアルは[こちら](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)からお申し込みいただけます。\n\n## git mergeコマンド のFAQ\n\n### git mergeコマンドとは何ですか？\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。\n\n### mainブランチにマージするにはどうしたらいいですか？\n\nまず、\u003Ccode>git checkout BRANCH_NAME\u003C/code>を使ってmainブランチに移動します。\n\n次に\u003Ccode>git merge BRANCH_NAME\u003C/code>を使ってマージしたいブランチを指定します。\n\nマージ先ブランチ名）master\\\nマージするブランチ名）feature1の場合には\n\n```xml\n\u003Ccode>git checkout master\u003C/code>\n\u003Ccode>git merge feature1\u003C/code>\n```\n\n\\\nとなります。\n\n### git mergeとgit rebaseの違いは何ですか？\n\ngit mergeとgit rebaseはどちらもブランチを結合するコマンドです。mergeが新しいコミットを生成してコミット履歴が分散してしまうのに対し、rebaseはコミット履歴をひとつのブランチにまとめます。rebaseはログを整理する目的で使われることが多いですが、別のブランチで他のメンバーが加えた変更の履歴を消してしまう可能性などがあるので、上級者向けのコマンドといえます。\n\n*監修：知念 梨果* *[@rikachinen](https://gitlab.com/rikachinen)（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n","この記事では、git mergeコマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[734,23,735,736],"collaboration","tutorial","workflow",{"featured":14,"template":15,"slug":738},"git-merge-command-overview",{"content":740,"config":749},{"title":741,"description":742,"authors":743,"heroImage":744,"date":745,"body":746,"category":11,"tags":747},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[730],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720740/g9x8oi988xuhioglpczi.jpg","2025-07-17","## オープンソースとは？\n\nオープンソースとは、ソフトウェアのコードが公開され、誰もが利用、改良、再配布できるという仕組みのことを指します。「オープンソースソフトウェア」と同義で使用されることが多いです。\n\n## オープンソースソフトウェア（OSS）とは？\n\nオープンソースソフトウェアはOSSとも記述され、Open Source Softwareの略称です。一般的な商用ソフトウェアとは異なり、誰でも利用、改良、再配布ができるようソースコードが公開されています。これにより個人や企業のデベロッパーは、各々の環境に合わせてソフトウェアを自由に改変し、特定の用途や問題に最適化することが容易にできます。ただし、OSSによってはライセンス制約が存在する場合もあります。\n\nフリー（無料）ソフトと混同されることがありますが、フリーソフトのほとんどはソースコードが非公開です。よって、ソースコードが公開されているかどうかで、OSSかの判断をするのが一般的です。\n\n## オープンソースソフトウェアの基本原則\n\nオープンソフトウェアに明確な定義はありませんが、「ソースコードが公開されていること」以外にも広く認知されている要件があります。これら要件は、米国のOpen Source Initiative（OSI）という団体が提唱した以下10項目を指すのが一般的です。\n\n* 再配布の自由\n* ソースコードの配布\n* 派生ソフトウェアの配布許可\n* 作成者のオリジナルコードの完全性\n* 個人やグループに対する差別禁止\n* 使用分野に対する差別禁止\n* ライセンスの配布\n* 特定製品でのみ有効なライセンスの禁止\n* 他ソフトウェアを制限するライセンスの禁止\n* ライセンスの技術的中立\n\n要約するとOSSの基本原則は、ユーザーやデベロッパーに自由を提供し、協力的な環境を促進することと言えます。ただし、「自由」ではあるものの、ライセンスによって一定のルールは設定されています。例えば、GPLやMITライセンスは、OSSに付随するライセンスの利用や再配布、改変の範囲を規定し、自由利用を促進しつつも、デベロッパーやユーザーの権利を保護しています。OSS利用の際は、こういったライセンスルールを理解し、遵守することを忘れないようにしましょう。ライセンスについては後ほど詳しく解説します。\n\n## オープンソースソフトウェアの具体例\n\nどういったソフトウェアがOSSなのかと問われると、すぐには思いつかないかもしれません。実際に、どういったソフトが様々な分野で活躍しているのかいくつかご紹介しましょう。\n\n### WordPress\n\nWordPressという名前は、誰もが一度は聞いたことがあるでしょう。WordPressはウェブサイトを簡単に作成できるコンテンツ管理システム（CMS）で、世界中でもっとも利用されているCMSとなっています。ウェブサイトデベロッパーは自由にカスタマイズを行うことができ、また、活発なコミュニティで互いをサポートし合うことにより、新たな拡張機能の開発等に貢献しています。\n\n### GIMP\n\nGIMPは、イラストレーター、グラフィックデザイナー、フォトグラファー、サイエンティストなど画像を扱う専門家に人気の画像編集ソフトウェアです。ユーザーは無料でダウンロードして利用でき、WordPressと同じく活発なコミュニティが、日々のバグ修正や、新プラグインを開発をサポートしています。\n\n### Brave Browser\n\nBraveは、ユーザーのプライバシー保護を主眼としたウェブブラウザであり、広告やトラッキングを防止してくれます。さらに、独自の暗号通貨（BAT）や検索システムを開発しているなどの理由で、デベロッパー間では人気のブラウザの一つです。Braveもオープンソースであるため、個人が自由にブラウザ機能をカスタマイズしたり、新たに機能を追加したりすることができる仕様となっています。\n\n### GitLabのオープンソースプロジェクト\n\n[GitLabプラットフォーム](https://about.gitlab.com/ja-jp/)を利用して開発されているオープンソースプロジェクトをいくつかご紹介します。\n\n#### Drupal\n\nDrupalはWordPressと同様に、オープンソースのコンテンツ管理システム（CMS）です。堅牢性と拡張性の高さが評価されており、NASAや経済産業省といった政府機関や、Teslaなどの企業に採用されています。\n\n#### VLC\n\nWindowsやMacにとどまらず、LinuxやiOS等でも使うことできる、メディアプレイヤーです。多様な種類の音声や動画ファイルを再生でき、様々なファイル形式に対応しています。広告等、ユーザーにとって不要な機能が一切搭載されておらず、世界中で広く利用されています。\n\n#### LibreOffice\n\nMicrosoft Officeとよく比較されることがあるのが、LibreOfficeです。無料で利用することができ、様々なオフィスツールを提供することから、たくさんの企業や個人に使用されています。\n\n## オープンソース開発のメリットとデメリット\n\nOSSの開発には様々なメリットとデメリットがあります。開発手法についての議論は付きませんが、ここでは言及されることが多いポイントをいくつか挙げてみます。\n\n### メリット\n\n#### コミュニティによる自発的なサポートと開発\n\nオープンソース開発は通常、世界中のデベロッパーが参加した活発なコミュニティを形成しています。多種多様なバックグランドを持つ個々のユーザーたちがお互いにアイデアやフィードバック、サポートし合うことを基本とし、継続的な開発とサポートをしてくれます。\n\n#### 高い透明性に担保された信頼とセキュリティ\n\nOSSの信頼とセキュリティは、誰もがソースコードを参照できることで実現されています。\n\nまず、たくさんのデベロッパーの目に触れるため、脆弱性やバグが比較的早い段階で発見されます。これにより、セキュリティを高レベルに引き上げることができます。そして、ソースコードが公開されているため、不正な動作やバックドアの存在といったリスクを排除しやすく、ソフトウェアの信頼性を高めてくれます。\n\n#### 開発にかかる時間と費用の削減\n\nオープンソースソフトウェアは大抵が無料で、自由にソースコードを改変できます。よって、ライセンス料とスクラッチ開発が不要であり、個人や企業の費用と開発時間を大幅に削減してくれます。\n\n### デメリット\n\n#### 開発プロジェクトの継続性\n\nオープンソース開発は、有志が中心となって行われる場合が多いため、プロジェクトが遅延したり、突然中止となったりするリスクがあります。また、安定した開発スケジュールが維持されないこともあります。\n\nプロジェクトの多くは無償、スポンサー、寄付で成り立っていることが一般的なので、開発コアメンバーが抜けた、資金が枯渇してしまった、などの理由から開発自体が立ち行かなくなることもあります。\n\n#### 責任の所在が曖昧\n\nコミュニティ主導で開発が進められる場合、ユーザーにバグや他ソフトと統合できないといった問題が発生しても商用ソフトウェアとは異なり、自己解決しなくてはならないケースが通常です。迅速かつ的確なサポートが受けづらいケースも、発生することがあります。\n\n#### ライセンスの準拠で\n\n当然ながら、OSSにもライセンスが存在します。無条件に利用や再配布ができるわけではないので、しっかりとライセンスを理解した上で使用しなければいけません。ライセンス規約に違反してしまい、過去には訴訟に発展したケースもあるため、注意が必要です。詳しくは後ほど解説します。\n\n### オープンソースの課題とGitLabのアプローチ\n\nGitLabというプラットフォームが、OSSにおける課題に対してどう取り組んでいるかについて、いくつかご紹介しましょう。詳細を知りたい場合は、[オープンソースプロジェクト向けのGitLabソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を読んでみてください。\n\n#### 脆弱性の早期発見と修正\n\nオープンソースは、コードが公開されているため、悪意のある人物が脆弱性を発見してしまうリスクがあります。\n\n[DevSecOpsプラットフォーム](https://about.gitlab.com/ja-jp/topics/devsecops/)であるGitLabは、開発プロセス全体においてセキュリティを重要視しています。静的アプリケーションセキュリティテスト（SAST）や依存関係スキャンといった強力なツールが、早期の脆弱性発見と修正を実現する仕組みを実現します。\n\n#### サポートの補完\n\nOSSはコミュニティによるサポートが中心となり、的確なサポートや迅速な対応を受けられないケースが発生することがあります。\n\n[商用版GitLab](https://about.gitlab.com/ja-jp/pricing/)には、「GitLab Premium」「GitLab Ultimate」があり、公式サポートという選択肢が用意されています。また、コミュニティの結束を高める働きかけをすることで自発的サポートも促進しています。\n\n#### コミュニティの活性化\n\n活発なコミュニティなしに、OSSを成功させることはできませんが、これを維持するのは容易ではありません。\n\nGitLabは、[GitLabフォーラム](https://forum.gitlab.com/c/community/gitlab-for-open-source/49)を運営したり、[オープンソース団体向けプログラム](https://about.gitlab.com/ja-jp/solutions/open-source/join/)を実施、GitLabハッカソンやオンラインイベントを開催したりすることで、デベロッパー同士の繋がりを促進、コミュニティの活性化と拡大に貢献しています。\n\n## オープンソースのライセンスとその重要性\n\nオープンソースのライセンスは、ソフトウェアの利用、配布、変更等に関する権利と制限を明記したものであり、法的拘束力を持ちます。よって、ソフト利用者はこれをしっかりと理解した上で、トラブル回避をすることが望ましいといえます。\n\nまた、ソフトウェアデベロッパーがどのライセンス規約にするかを考える場合には、透明性を重視するのか、自由度を重視するのかなどにより選択するライセンスが異なってきます。ここでは、いくつか代表的なものをご紹介しましょう。\n\n以下に表としてまとめてみました。\n\n![オープンソース　ライセンスのタイプと代表例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720035/v9ld6h78ilk22x30nged.jpg)\n\n### コピーレフト\n\nコピーレフトライセンスは、元となるソフトウェアを再配布する時には、派生物も元OSSと同じ条件下で行う必要があるというものです。このタイプのライセンスは、非常に伝播性が強いのが特徴です。\n\nまたコピーレフトという言葉は、「コピーライト」をもじったものから誕生しました。\n\n### 準コピーレフト\n\nコピーレフトと比べ、伝播性が多少弱いのが準コピーレフトです。元のOSSのソースコードを再利用した時に、元のライセンスと同条件で再配布する必要があります。\n\n### 非コピーレフト\n\nパーミッシブライセンスとも呼ばれます。名前の通りですが、元のOSSと同条件のライセンスにする必要がありません。ソースコードの公開義務がないため、商用利用されることが多いです。\n\n## よくある質問\n\n### オープンソースソフトウェア（OSS）とは何ですか？\n\nOSSとは、ソースコードが公開され、誰でも自由に利用、修正、配布できるソフトウェアのことです。\n\n### OSSのセキュリティは安心ですか？\n\nOSSライセンスは、ソフトウェアの利用や再配布に関する自由と制約を明確に定義したものです。\n\n### OSSのライセンスにはどんな種類がありますか？\n\nライセンスにはGPL、MIT、Apache Licenseなど、異なる自由度や利用条件を持つものがあり、コピーレフト、準コピーレフト、非コピーレフトの３つに大別されます。\n\n### なぜ企業がOSSを採用するのですか？\n\nコスト削減、柔軟性、信頼性向上、技術コミュニティとの連携が理由となる場合が多いです。またGitLabでは、[オープンソースプロジェクト向けのソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を提供しています。ぜひご確認ください。\n\n*監修：佐々木 直晴* [@naosasaki](https://gitlab.com/naosasaki)*（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[734,262,22,748],"security",{"featured":14,"template":15,"slug":750},"what-is-open-source",{"promotions":752},[753,767,779,790],{"id":754,"categories":755,"header":757,"text":758,"button":759,"image":764},"ai-modernization",[756],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":760,"config":761},"Get your AI maturity score",{"href":762,"dataGaName":763,"dataGaLocation":244},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":765},{"src":766},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":768,"categories":769,"header":771,"text":758,"button":772,"image":776},"devops-modernization",[770,566],"product","Are you just managing tools or shipping innovation?",{"text":773,"config":774},"Get your DevOps maturity score",{"href":775,"dataGaName":763,"dataGaLocation":244},"/assessments/devops-modernization-assessment/",{"config":777},{"src":778},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":780,"categories":781,"header":782,"text":758,"button":783,"image":787},"security-modernization",[748],"Are you trading speed for security?",{"text":784,"config":785},"Get your security maturity score",{"href":786,"dataGaName":763,"dataGaLocation":244},"/assessments/security-modernization-assessment/",{"config":788},{"src":789},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":791,"paths":792,"header":795,"text":796,"button":797,"image":802},"github-azure-migration",[793,794],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":798,"config":799},"See how GitLab compares to GitHub",{"href":800,"dataGaName":801,"dataGaLocation":244},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":803},{"src":778},{"header":805,"blurb":806,"button":807,"secondaryButton":811},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":46,"config":808},{"href":809,"dataGaName":49,"dataGaLocation":810},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":51,"config":812},{"href":53,"dataGaName":54,"dataGaLocation":810},1777493672796]