[{"data":1,"prerenderedAt":813},["ShallowReactive",2],{"/ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds":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-celebrating-gits-20th-anniversary-with-creator-linus-torvalds":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/celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う",[7],"patrick-steinhardt",[9],"Patrick Steinhardt","バージョン管理システム「Git」の最初のバージョンは、Linuxカーネルの父であるリーナス・トーバルズ氏によって、2005年4月7日にリリースされました。現在ではほぼすべてのデベロッパーが使うようになったこの重要なプロジェクトの20周年を記念して、トーバルズ氏にインタビューし、Gitの歴史、Gitのメンテナーとしての役割を別の人物に引き継いだ理由、そしてもっとも重要なマイルストーンとは何かについてうかがいました。\n\n**Gitをリリースした2005年には、すでに人気のLinuxカーネルのメンテナーを務めていらっしゃいました。それなのに、なぜ新しいバージョン管理システムの開発を始めようと思ったのですか？**\n\nバージョン管理を行うのが、すごく嫌になっていたんです。\n\n従来型のバージョン管理システム（CVS／RCS／SCCS）はエンドユーザーとしても（例：[GCC](https://gcc.gnu.org/)などのオープンソースプロジェクトの追跡に使用）、デベロッパーとしても（トランスメタ社では何にでもCVSを使用していたため）使用していましたが、非常に嫌な体験でした。\n\n\u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\" align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nその当時、CVSを使用していたプロジェクトはほとんど、[SVN](https://subversion.apache.org/)に移行したと思いますが、正直なところ、SVNは単に表面的な部分だけを変更した「ブタに真珠」だと感じていました。CVSを単に別のソフトにしただけのもので、ある程度UIが改善されていたものの、基本的な問題は一切修正されておらず、代わりに新たな問題を内包していました。\n\nCVSや類似のソフトウェアの問題は、数えきれないほどあります。幸いなことに、それらの問題はもはや重要でなくなっており、若いデベロッパーは対処しなくて済んでいるはずです。90年代にはいくつかのサブシステム（特にネットワーク側）で実際にCVSを使ってコードを追跡していましたが、カーネルでCVSを使うことは断固として拒否しました。\n\nその当時、私はサンフランシスコ・ベイエリアに住んでいました。別のプロジェクト（主に[lmbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf)）で知り合ったラリー・マクボイがBitMoverを立ち上げ、BitKeeper（略称「BK」）と呼ばれる新たなバージョン管理モデルを開発しました。\n\nBitKeeperはオープンソースではなかったものの、ラリー自身はオープンソースプロジェクトを好んでおり、バージョン管理の欠如がカーネルの足かせになっていると強く感じていました。ラリーの考えには同意していたものの、従来のソースコード管理ツール（SCM）の導入にはまったく賛成できませんでした。ラリーは時間をかけて、デイヴィッド・ミラー（ネットワーク機能のメンテナーで既存のCVSユーザー）と私に、BitKeeperでできることを説明してくれました。\n\nBitKeeperは完璧ではありませんでした。また、他の多くの従来型SCMと同様、ソースコード管理システム（SCCS）をベースにしていたため、うまく機能しない「ファイルごとの履歴」モデルが使用されていました。そのため、ファイルの名前変更や削除の際に根本的かつ重大な問題が生じるという欠点がありました。\n\nしかしながら、BitKeeperは単なる「ブタに真珠」ではありませんでした。下層レベルではSCCSが用いられていたかもしれませんが、それより上のレベルでは非常に根本的な部分がいくつか修正されており、適切に分散型開発が行われていました。また、ファイルごとではなく、全体的に履歴が管理されていたため、別のツリーからのコードのマージも実際に行えました。\n\nCVSでは、ブランチを作成してマージする場合、事前に計画して関係者と話し合う必要があり、一大イベントでした。一方、BitKeeperではすべてのリポジトリがブランチでした。これは今となっては当たり前のことです。もちろんGitではこれをさらに推し進め、リポジトリ*ごと*に複数のブランチを持てるようになっています。それと比べると、BitKeeperモデルははるかに制限されたものでしたが、当時は大きな前進でした。\n\nもう一度言いますが、BitKeeperは完璧ではありませんでした。先ほどもお話ししたように、ファイルごとに履歴を保持していたため、名前変更やファイルのマージが確実ではないという根本的かつ重大な問題がありました。そのため、どうしても混乱と手間が苦痛が生じていました（CVSを使っていた方は、Atticを思い出してみてください）。さらに、スケーラビリティの問題もいくつかありましたが、当時はまだ大きな問題ではありませんでした。\n\nしかしながら、BitKeeperの最大の問題はライセンスでした。数年かけて（2002年から2005年までBitKeeperを使用）、多くのカーネルメンテナーがBitKeeperに移行しましたが、毎回ライセンスの面で摩擦が生じていました。2004年後半にはそれが大問題となり、カーネルにBitKeeperを使用することは、数か月後には基本的に不可能という事態となりました。\n\n当時の私は、ようやく機能するソース管理ツールを使用できるようになってから3年間経っており、おかげで非常に多くの問題を解決できていました。ソース管理を行っていなかった時代に戻るのはお断りでしたが、BitKeeperを使用していた数年の間、それよりも良いツールはオープンソースコミュニティから出てこなかったのです。\n\nCVSやSVNがうまく機能しないことは周知の事実であり、別のアプローチを試したプロジェクトもありました。それらのアプローチの中には、さらにひどいもの（多くは「手の込んだパッチ追跡」に相当するもの）や、アイデア自体は良かったのに、その過程で新しい重大なデザインミスが起きたもの（[Monotone](https://www.monotone.ca/)）もありました。\n\nそのため、しばらく探し回ってから、他に選択肢はないから自分で開発しなければ、と決断しました。\n\n技術的には、Gitの最初のバージョンの作成には数日しかかかりませんでした。それはすべて、Gitのコミット履歴に残っています。ほぼ何もなかった状態から、1週間後には他の人から提供されたパッチを適用し始める（さらにその数日後には、カーネルに積極的に使用されるようになった）ほど使える状態になった様子は簡単に見て取れます。\n\nしかしながら、コミット履歴からは、それまでに私がこの問題についてしばらく*考えていた*という事実はわかりません。コードを書くこと自体は簡単です。重要なのは、良いデザインを行うことです。ですので、あの数日間の前にかなり長い準備期間がありました。その部分は、コミット履歴には反映されていません。\n\n最初のバージョンはとても粗削りなもので、後から登場する機能はほとんど備わっていませんでした。しかしながら、この最初のバージョンには、核となるデザインの大部分がすでに含まれていました。\n\n**Gitプロジェクトがどのように始まったか、最初の数日間と数週間について簡単に説明していただけますか？**\n\n私は基本的には、満足できる代替ツールができあがるまで、カーネルの開発を中断すると決めていました。主な目標は、分散型かつ高性能であること、そしてどんな破損でも確実に検出可能と信頼できるものを開発することでした。\n\nただし、お伝えしておきたいのは、SCM自体には興味がなかったということです。私が興味があったのは、プロセスではなく、最終的に得られる結果でした。そのため、私にとって、Gitはカーネルと同じではありませんでした。Linux開発はカーネルに興味があるから行っていますが、Gitは必要性に迫られて取り組みました。\n\nこれが、次の質問の回答にも直接つながります。\n\n**数か月後に、Gitのメンテナーの役割を濱野純氏に引き継がれました。今でも引き続き濱野氏がメンテナーを務めています。メンテナーを退いた理由、そして濱野氏を選んだ理由についてお聞かせください。**\n\nメンテナーの役割を引き継ぐことは、難しい決断ではありませんでした。「Gitのメンテナンスを任せられると思える相手が見つかったら、すぐにカーネルのメンテナーに戻ろう」と考えていたためです。\n\nもちろん、責任だけを押し付けて、成功を祈ったというわけではありません。メンテナンスを長期間にわたって担当してくれる、「センスが良い」人を探す必要があると考えていたため、結局、Gitのメンテナーを4か月ほど務めることになりました。\n\n濱野さんは、初期から参加したメンバーの1人でした（文字どおり、開発の最初の週から参加）。でも、すぐに「次のメンテナーになってください」と言ったわけではありません。誰が長期にわたって担当してくれるか、また誰がコードを書いて、適切な決定を下せるかを見極めるには、ある程度の時間がかかります。\n\n濱野さんはまさにぴったりでした。私がGitに費やしたのはわずか数か月間ですが、特に20周年を迎えるにあたり、賞賛を受けすぎていると感じています。適切に核となるデザインを行い、プロジェクトを立ち上げたことは私の実績ですが、（もちろん他の何百人もの関係者も重要ですが）実際にプロジェクトを主導してきたのは濱野さんです。\n\n**バージョン管理システムであるMercurialの最初のバージョンは、Gitの最初のバージョンがリリースされてからわずか12日後（2005年4月19日）にリリースされました。MercurialのユーザーエクスペリエンスはGitよりも優れていたと多くの人々が主張していますが、今では圧倒的にGitの方が人気があります。GitがMercurialに勝った理由は何だとお考えですか？**\n\n主な理由は、明らかにネットワーク効果だと思います。SCMには、非常に強力なネットワーク効果があります。制限が多いにもかかわらず、CVSがあれほど長く生き残った理由もそれです。\n\nつまり、カーネルでGitを使用していたためです（その後、ある時点でRuby on RailsコミュニティでGitが大人気となり、それからさまざまな場所で普及しました）。\n\nでも、Gitのデザインは本当に優れていると思います。コアモデルは非常にシンプルかつ強力です。そのおかげで、他の環境に簡単に移植できたと考えています。JGitは初期の移植例ですが、他にもMSgit仮想ファイルシステムなどの実装があります。\n\nたしかに当初はGitが使いにくいという評判がありましたが、その理由の一部は、Gitでは「正しく」処理を行っていたことが原因だと思います。Gitでは、従来のSCMでは決して行わなかったような、難しい判断をいくつか行っていたため、他の環境から移行したユーザーはGitを直感的ではないと感じたのでしょう。\n\n**Gitプロジェクトは、あなたが濱野氏にメンテナーの役割を引き継いだ後も、一度も停止せずに、コミュニティメンバーによる新機能の開発が常に進行中です。プロジェクトを離れた後、もっとも重要なマイルストーンは何だったとお考えですか？**\n\nそれは非常に答えにくい質問です。というのも、自分が満足するようにGitを開発したため、*私自身*が活用している機能は、開発当初から使えたためです。わかりやすい例としては、GitがWindowsに対応したことことは、他のユーザーにとっては間違いなく大きなステップでしたが、*私*にとってはまったく関係のないことでした。\n\nもちろんGit自体に、使いやすさを向上するためのインフラがすべて備わっていますが、大きなマイルストーンの大半は、Gitのインフラを利用して、それを中心に何かを構築してきた人たちによって成し遂げられたものだと思います。当然ながら、これらは最終的にはGitの機能に反映されがちです。しかしながら、本当のマイルストーンは外部に関するものです。\n\nわかりやすい例を挙げると、Gitのホスティングサイトはすべて大きなマイルストーンです。ホスティングサイトによって、より簡単にGitを配信できるようになったものの、*本当のマイルストーン*は、ホスティングによってユーザーがさまざまなプロジェクトでGitを非常に簡単に使えるようになったことです。\n\n**もし、またGitにフルタイムで携わることができるとしたら、実装したい機能はありますか？**\n\n一切ないですね。Gitではかなり初期の段階から、本当に必要としていたことをすべて実現できました。実のところ、私の使い方はかなり限定的で、本当に重視しているのは1つのプロジェクトだけなんです。\n\nそして、「一切ない」とお答えしたのは、先ほどお伝えしたとおり、私は当初からSCMにまったく興味がなかったためです。Gitが他のSCMとこれほど違うものになった（おおむね良い意味で）主な理由は、私が従来のSCMというより、分散型ジャーナリングファイルシステムに対してのように取り組んだからだと思います。\n\n**Gitの機能やデザイン上の決定で、後悔していることはありますか？**\n\nデザイン上の決定ですか？後悔していることはありません。今でも基本デザインは非常に優れていると思っています。実際の実装の複雑な詳細に一切触れることなく、さまざまなGitのコンセプトについて話し合えます。\n\nプロジェクトにおいては、それが重要だと思います。プロジェクトのコンセプトの方向性を指示するには、基本的なデザイン方針がある程度必要です。\n\nときにはこれが行き過ぎて、実装時に、基本デザインの核となる方針に盲目的に従うべきだと考える人もいます。これも間違っています。現実はややこしく、人々は変わったものを求めるため、*実装時*には複雑な多数のコーナーケースが生じます。なので、厄介な現実に対処しなくて済むように、参考になり、高度なレベルで検討できるような、ある種の基本デザインが必要となります。\n\nGitはそう言った面でバランスが取れていると思います。非常にわかりやすいオブジェクトストアデザインが採用されています（CS分野の方にとっては「マークル木構造」、ファイルシステム担当者には「内容アドレス記憶装置」という呼び方がピンとくるかもしれません）。コアデザインは存在しますが、一方でそれは実際のところ、実コードのほんの一部にすぎません。*コード*の大半はコアデザインに沿った内容です。根本的にデザインがわかりやすいため、プロジェクトにある種の基本構造が生まれます。\n\nこれは、かつてのUNIX自体の基本構造（すべてがファイルから構成されている仕組みや、プロセス処理方法）と同じようなものです。デザインのベースとなる「コンセプト」はいくつかあるものの、コードの99%は、それを実世界に適用するために、その上に構築される非常に細かな内容です。\n\n私には、技術に関する信念が2つあります。それは「私がかなたを見渡せたのだとしたら、それは巨人の肩の上に立っていたからです」（ニュートン）と「天才とは、1%のひらめきと99%の努力である」（エジソン）です。\n\n99%の努力について考えてみると、大まかなデザインには非常に満足していますが、細かい点については、もし今Gitに携わるなら違う風にしていただろうなと思うところは、確かに多々あります。\n\nでも正直なところ、そういった点はあまり重要でありません。それよりも、過去20年間に行われたすべての*良い*実装こそがはるかに重要です。\n\n**Linuxカーネルにおいて、一部のサブシステムのプログラミング言語としてRustの使用が開始されました。Gitの場合、このような新しいプログラミング言語を使い始めることは妥当だとお考えですか？**\n\nGitに関して言えば、新たな言語を使い始めることにあまり意味はないと思います。大抵の場合、苦労することになります。\n\nカーネルの場合、最終的な成果物は単一のカーネルバイナリです。その大半はモジュールとして動的に読み込むことはできるものの、実質的には単一のバイナリにリンクされています。\n\nそのため、複数の言語を使用すると、より複雑になります。しかしその一方で、カーネルではメモリ安全性についてさらに気を付けなければならないため、新しい言語に目を向ける必要性があります。\n\nGitの場合は、もしその一部をRustや他の言語で書きたいのであれば、複数の言語で1つのバイナリを開発するよりも、個別に実装する方がはるかに理にかなっていると思います。\n\nGitの核となるアイデアの多くはシンプルなので、中核となる部分の並列実装だけならそれほど難しくないはずです。そうすれば、別の言語での開発がより適切な問題領域に、個別に取り組めます。\n\nもちろん、このやり方はすでにGitでも行われています。まさにこの方法で開発されているのがJGitです。別の言語を使用したのは、Gitとは異なるウェブベースの環境であるため、より自然な選択だったからです。\n\nGitの主要機能の一部に対応したRustの実装はすでにいくつかありますが、同様の状況だと思います。特定の状況においては、「すべてをRustに移植しよう」というよりも、このアプローチの方が適切だと思います。\n\nですので、Rustでの実装に興味がある方には、Rustを使用する利点がより明らかな箇所を探すことをおすすめします。標準的なGitのソースベースでは、C言語の使用はそれほど問題はなかったと思います。\n\n**数年ごとに、新しいバージョン管理システムが登場しています。Gitは今後も、重要なツールとしての地位を維持できるとお考えですか？** \n\nSCMにネットワーク効果があることは先ほどお話ししました。そのため、Gitに取って代わるには、少し優れているだけではなく、はるかに優れている必要があると思います。もしくは、互換性が高すぎると、実質的にGitの新しい実装となります。\n\nSCMを取り巻く状況は実際に変わったと思います。Gitには、Git以前のSCMが抱えていたような、深刻かつ根本的な問題はありません。したがって、「はるかに優れている」ツールを開発するのはかなり大変です。\n\nですので、当面の間、Gitが現在の地位を維持できると考えています。人々はGitに代わるツールではなく、Gitを*ベース*として改善に取り組んでいくでしょう。\n\n*注：このインタビューは、長さを調節し、文意を明確にするために編集されています。*\n\n## Gitの関連リンク\n\n- [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)  \n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Gitプロジェクト](https://git-scm.com/)","open-source",{"slug":13,"featured":14,"template":15},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds",true,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21},"トーバルズ氏がオープンソースのバージョン管理システムの開発にいたった経緯、数か月で手を引いた理由、そしてGitでの新しいプログラミング言語のサポートについてどう考えているかをご紹介します。",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","2025-04-07",[22,23],"open source","git","yml",null,{},"/ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","seo:\n  title: Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う\n  description: >-\n    トーバルズ氏がオープンソースのバージョン管理システムの開発にいたった経緯、数か月で手を引いた理由、そしてGitでの新しいプログラミング言語のサポートについてどう考えているかをご紹介します。\n  ogTitle: Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う\n  ogDescription: >-\n    トーバルズ氏がオープンソースのバージョン管理システムの開発にいたった経緯、数か月で手を引いた理由、そしてGitでの新しいプログラミング言語のサポートについてどう考えているかをご紹介します。\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png\n  ogUrl: >-\n    https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: >-\n    https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds\ncontent:\n  title: Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う\n  description: >-\n    トーバルズ氏がオープンソースのバージョン管理システムの開発にいたった経緯、数か月で手を引いた理由、そしてGitでの新しいプログラミング言語のサポートについてどう考えているかをご紹介します。\n  authors:\n    - Patrick Steinhardt\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png\n  date: '2025-04-07'\n  body: >-\n    バージョン管理システム「Git」の最初のバージョンは、Linuxカーネルの父であるリーナス・トーバルズ氏によって、2005年4月7日にリリースされました。現在ではほぼすべてのデベロッパーが使うようになったこの重要なプロジェクトの20周年を記念して、トーバルズ氏にインタビューし、Gitの歴史、Gitのメンテナーとしての役割を別の人物に引き継いだ理由、そしてもっとも重要なマイルストーンとは何かについてうかがいました。\n\n\n    **Gitをリリースした2005年には、すでに人気のLinuxカーネルのメンテナーを務めていらっしゃいました。それなのに、なぜ新しいバージョン管理システムの開発を始めようと思ったのですか？**\n\n\n    バージョン管理を行うのが、すごく嫌になっていたんです。\n\n\n    従来型のバージョン管理システム（CVS／RCS／SCCS）はエンドユーザーとしても（例：[GCC](https://gcc.gnu.org/)などのオープンソースプロジェクトの追跡に使用）、デベロッパーとしても（トランスメタ社では何にでもCVSを使用していたため）使用していましたが、非常に嫌な体験でした。\n\n\n    \u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\"\n    align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom:\n    10px\"/>\n\n\n    その当時、CVSを使用していたプロジェクトはほとんど、[SVN](https://subversion.apache.org/)に移行したと思いますが、正直なところ、SVNは単に表面的な部分だけを変更した「ブタに真珠」だと感じていました。CVSを単に別のソフトにしただけのもので、ある程度UIが改善されていたものの、基本的な問題は一切修正されておらず、代わりに新たな問題を内包していました。\n\n\n    CVSや類似のソフトウェアの問題は、数えきれないほどあります。幸いなことに、それらの問題はもはや重要でなくなっており、若いデベロッパーは対処しなくて済んでいるはずです。90年代にはいくつかのサブシステム（特にネットワーク側）で実際にCVSを使ってコードを追跡していましたが、カーネルでCVSを使うことは断固として拒否しました。\n\n\n    その当時、私はサンフランシスコ・ベイエリアに住んでいました。別のプロジェクト（主に[lmbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf)）で知り合ったラリー・マクボイがBitMoverを立ち上げ、BitKeeper（略称「BK」）と呼ばれる新たなバージョン管理モデルを開発しました。\n\n\n    BitKeeperはオープンソースではなかったものの、ラリー自身はオープンソースプロジェクトを好んでおり、バージョン管理の欠如がカーネルの足かせになっていると強く感じていました。ラリーの考えには同意していたものの、従来のソースコード管理ツール（SCM）の導入にはまったく賛成できませんでした。ラリーは時間をかけて、デイヴィッド・ミラー（ネットワーク機能のメンテナーで既存のCVSユーザー）と私に、BitKeeperでできることを説明してくれました。\n\n\n    BitKeeperは完璧ではありませんでした。また、他の多くの従来型SCMと同様、ソースコード管理システム（SCCS）をベースにしていたため、うまく機能しない「ファイルごとの履歴」モデルが使用されていました。そのため、ファイルの名前変更や削除の際に根本的かつ重大な問題が生じるという欠点がありました。\n\n\n    しかしながら、BitKeeperは単なる「ブタに真珠」ではありませんでした。下層レベルではSCCSが用いられていたかもしれませんが、それより上のレベルでは非常に根本的な部分がいくつか修正されており、適切に分散型開発が行われていました。また、ファイルごとではなく、全体的に履歴が管理されていたため、別のツリーからのコードのマージも実際に行えました。\n\n\n    CVSでは、ブランチを作成してマージする場合、事前に計画して関係者と話し合う必要があり、一大イベントでした。一方、BitKeeperではすべてのリポジトリがブランチでした。これは今となっては当たり前のことです。もちろんGitではこれをさらに推し進め、リポジトリ*ごと*に複数のブランチを持てるようになっています。それと比べると、BitKeeperモデルははるかに制限されたものでしたが、当時は大きな前進でした。\n\n\n    もう一度言いますが、BitKeeperは完璧ではありませんでした。先ほどもお話ししたように、ファイルごとに履歴を保持していたため、名前変更やファイルのマージが確実ではないという根本的かつ重大な問題がありました。そのため、どうしても混乱と手間が苦痛が生じていました（CVSを使っていた方は、Atticを思い出してみてください）。さらに、スケーラビリティの問題もいくつかありましたが、当時はまだ大きな問題ではありませんでした。\n\n\n    しかしながら、BitKeeperの最大の問題はライセンスでした。数年かけて（2002年から2005年までBitKeeperを使用）、多くのカーネルメンテナーがBitKeeperに移行しましたが、毎回ライセンスの面で摩擦が生じていました。2004年後半にはそれが大問題となり、カーネルにBitKeeperを使用することは、数か月後には基本的に不可能という事態となりました。\n\n\n    当時の私は、ようやく機能するソース管理ツールを使用できるようになってから3年間経っており、おかげで非常に多くの問題を解決できていました。ソース管理を行っていなかった時代に戻るのはお断りでしたが、BitKeeperを使用していた数年の間、それよりも良いツールはオープンソースコミュニティから出てこなかったのです。\n\n\n    CVSやSVNがうまく機能しないことは周知の事実であり、別のアプローチを試したプロジェクトもありました。それらのアプローチの中には、さらにひどいもの（多くは「手の込んだパッチ追跡」に相当するもの）や、アイデア自体は良かったのに、その過程で新しい重大なデザインミスが起きたもの（[Monotone](https://www.monotone.ca/)）もありました。\n\n\n    そのため、しばらく探し回ってから、他に選択肢はないから自分で開発しなければ、と決断しました。\n\n\n    技術的には、Gitの最初のバージョンの作成には数日しかかかりませんでした。それはすべて、Gitのコミット履歴に残っています。ほぼ何もなかった状態から、1週間後には他の人から提供されたパッチを適用し始める（さらにその数日後には、カーネルに積極的に使用されるようになった）ほど使える状態になった様子は簡単に見て取れます。\n\n\n    しかしながら、コミット履歴からは、それまでに私がこの問題についてしばらく*考えていた*という事実はわかりません。コードを書くこと自体は簡単です。重要なのは、良いデザインを行うことです。ですので、あの数日間の前にかなり長い準備期間がありました。その部分は、コミット履歴には反映されていません。\n\n\n    最初のバージョンはとても粗削りなもので、後から登場する機能はほとんど備わっていませんでした。しかしながら、この最初のバージョンには、核となるデザインの大部分がすでに含まれていました。\n\n\n    **Gitプロジェクトがどのように始まったか、最初の数日間と数週間について簡単に説明していただけますか？**\n\n\n    私は基本的には、満足できる代替ツールができあがるまで、カーネルの開発を中断すると決めていました。主な目標は、分散型かつ高性能であること、そしてどんな破損でも確実に検出可能と信頼できるものを開発することでした。\n\n\n    ただし、お伝えしておきたいのは、SCM自体には興味がなかったということです。私が興味があったのは、プロセスではなく、最終的に得られる結果でした。そのため、私にとって、Gitはカーネルと同じではありませんでした。Linux開発はカーネルに興味があるから行っていますが、Gitは必要性に迫られて取り組みました。\n\n\n    これが、次の質問の回答にも直接つながります。\n\n\n    **数か月後に、Gitのメンテナーの役割を濱野純氏に引き継がれました。今でも引き続き濱野氏がメンテナーを務めています。メンテナーを退いた理由、そして濱野氏を選んだ理由についてお聞かせください。**\n\n\n    メンテナーの役割を引き継ぐことは、難しい決断ではありませんでした。「Gitのメンテナンスを任せられると思える相手が見つかったら、すぐにカーネルのメンテナーに戻ろう」と考えていたためです。\n\n\n    もちろん、責任だけを押し付けて、成功を祈ったというわけではありません。メンテナンスを長期間にわたって担当してくれる、「センスが良い」人を探す必要があると考えていたため、結局、Gitのメンテナーを4か月ほど務めることになりました。\n\n\n    濱野さんは、初期から参加したメンバーの1人でした（文字どおり、開発の最初の週から参加）。でも、すぐに「次のメンテナーになってください」と言ったわけではありません。誰が長期にわたって担当してくれるか、また誰がコードを書いて、適切な決定を下せるかを見極めるには、ある程度の時間がかかります。\n\n\n    濱野さんはまさにぴったりでした。私がGitに費やしたのはわずか数か月間ですが、特に20周年を迎えるにあたり、賞賛を受けすぎていると感じています。適切に核となるデザインを行い、プロジェクトを立ち上げたことは私の実績ですが、（もちろん他の何百人もの関係者も重要ですが）実際にプロジェクトを主導してきたのは濱野さんです。\n\n\n    **バージョン管理システムであるMercurialの最初のバージョンは、Gitの最初のバージョンがリリースされてからわずか12日後（2005年4月19日）にリリースされました。MercurialのユーザーエクスペリエンスはGitよりも優れていたと多くの人々が主張していますが、今では圧倒的にGitの方が人気があります。GitがMercurialに勝った理由は何だとお考えですか？**\n\n\n    主な理由は、明らかにネットワーク効果だと思います。SCMには、非常に強力なネットワーク効果があります。制限が多いにもかかわらず、CVSがあれほど長く生き残った理由もそれです。\n\n\n    つまり、カーネルでGitを使用していたためです（その後、ある時点でRuby on\n    RailsコミュニティでGitが大人気となり、それからさまざまな場所で普及しました）。\n\n\n    でも、Gitのデザインは本当に優れていると思います。コアモデルは非常にシンプルかつ強力です。そのおかげで、他の環境に簡単に移植できたと考えています。JGitは初期の移植例ですが、他にもMSgit仮想ファイルシステムなどの実装があります。\n\n\n    たしかに当初はGitが使いにくいという評判がありましたが、その理由の一部は、Gitでは「正しく」処理を行っていたことが原因だと思います。Gitでは、従来のSCMでは決して行わなかったような、難しい判断をいくつか行っていたため、他の環境から移行したユーザーはGitを直感的ではないと感じたのでしょう。\n\n\n    **Gitプロジェクトは、あなたが濱野氏にメンテナーの役割を引き継いだ後も、一度も停止せずに、コミュニティメンバーによる新機能の開発が常に進行中です。プロジェクトを離れた後、もっとも重要なマイルストーンは何だったとお考えですか？**\n\n\n    それは非常に答えにくい質問です。というのも、自分が満足するようにGitを開発したため、*私自身*が活用している機能は、開発当初から使えたためです。わかりやすい例としては、GitがWindowsに対応したことことは、他のユーザーにとっては間違いなく大きなステップでしたが、*私*にとってはまったく関係のないことでした。\n\n\n    もちろんGit自体に、使いやすさを向上するためのインフラがすべて備わっていますが、大きなマイルストーンの大半は、Gitのインフラを利用して、それを中心に何かを構築してきた人たちによって成し遂げられたものだと思います。当然ながら、これらは最終的にはGitの機能に反映されがちです。しかしながら、本当のマイルストーンは外部に関するものです。\n\n\n    わかりやすい例を挙げると、Gitのホスティングサイトはすべて大きなマイルストーンです。ホスティングサイトによって、より簡単にGitを配信できるようになったものの、*本当のマイルストーン*は、ホスティングによってユーザーがさまざまなプロジェクトでGitを非常に簡単に使えるようになったことです。\n\n\n    **もし、またGitにフルタイムで携わることができるとしたら、実装したい機能はありますか？**\n\n\n    一切ないですね。Gitではかなり初期の段階から、本当に必要としていたことをすべて実現できました。実のところ、私の使い方はかなり限定的で、本当に重視しているのは1つのプロジェクトだけなんです。\n\n\n    そして、「一切ない」とお答えしたのは、先ほどお伝えしたとおり、私は当初からSCMにまったく興味がなかったためです。Gitが他のSCMとこれほど違うものになった（おおむね良い意味で）主な理由は、私が従来のSCMというより、分散型ジャーナリングファイルシステムに対してのように取り組んだからだと思います。\n\n\n    **Gitの機能やデザイン上の決定で、後悔していることはありますか？**\n\n\n    デザイン上の決定ですか？後悔していることはありません。今でも基本デザインは非常に優れていると思っています。実際の実装の複雑な詳細に一切触れることなく、さまざまなGitのコンセプトについて話し合えます。\n\n\n    プロジェクトにおいては、それが重要だと思います。プロジェクトのコンセプトの方向性を指示するには、基本的なデザイン方針がある程度必要です。\n\n\n    ときにはこれが行き過ぎて、実装時に、基本デザインの核となる方針に盲目的に従うべきだと考える人もいます。これも間違っています。現実はややこしく、人々は変わったものを求めるため、*実装時*には複雑な多数のコーナーケースが生じます。なので、厄介な現実に対処しなくて済むように、参考になり、高度なレベルで検討できるような、ある種の基本デザインが必要となります。\n\n\n    Gitはそう言った面でバランスが取れていると思います。非常にわかりやすいオブジェクトストアデザインが採用されています（CS分野の方にとっては「マークル木構造」、ファイルシステム担当者には「内容アドレス記憶装置」という呼び方がピンとくるかもしれません）。コアデザインは存在しますが、一方でそれは実際のところ、実コードのほんの一部にすぎません。*コード*の大半はコアデザインに沿った内容です。根本的にデザインがわかりやすいため、プロジェクトにある種の基本構造が生まれます。\n\n\n    これは、かつてのUNIX自体の基本構造（すべてがファイルから構成されている仕組みや、プロセス処理方法）と同じようなものです。デザインのベースとなる「コンセプト」はいくつかあるものの、コードの99%は、それを実世界に適用するために、その上に構築される非常に細かな内容です。\n\n\n    私には、技術に関する信念が2つあります。それは「私がかなたを見渡せたのだとしたら、それは巨人の肩の上に立っていたからです」（ニュートン）と「天才とは、1%のひらめきと99%の努力である」（エジソン）です。\n\n\n    99%の努力について考えてみると、大まかなデザインには非常に満足していますが、細かい点については、もし今Gitに携わるなら違う風にしていただろうなと思うところは、確かに多々あります。\n\n\n    でも正直なところ、そういった点はあまり重要でありません。それよりも、過去20年間に行われたすべての*良い*実装こそがはるかに重要です。\n\n\n    **Linuxカーネルにおいて、一部のサブシステムのプログラミング言語としてRustの使用が開始されました。Gitの場合、このような新しいプログラミング言語を使い始めることは妥当だとお考えですか？**\n\n\n    Gitに関して言えば、新たな言語を使い始めることにあまり意味はないと思います。大抵の場合、苦労することになります。\n\n\n    カーネルの場合、最終的な成果物は単一のカーネルバイナリです。その大半はモジュールとして動的に読み込むことはできるものの、実質的には単一のバイナリにリンクされています。\n\n\n    そのため、複数の言語を使用すると、より複雑になります。しかしその一方で、カーネルではメモリ安全性についてさらに気を付けなければならないため、新しい言語に目を向ける必要性があります。\n\n\n    Gitの場合は、もしその一部をRustや他の言語で書きたいのであれば、複数の言語で1つのバイナリを開発するよりも、個別に実装する方がはるかに理にかなっていると思います。\n\n\n    Gitの核となるアイデアの多くはシンプルなので、中核となる部分の並列実装だけならそれほど難しくないはずです。そうすれば、別の言語での開発がより適切な問題領域に、個別に取り組めます。\n\n\n    もちろん、このやり方はすでにGitでも行われています。まさにこの方法で開発されているのがJGitです。別の言語を使用したのは、Gitとは異なるウェブベースの環境であるため、より自然な選択だったからです。\n\n\n    Gitの主要機能の一部に対応したRustの実装はすでにいくつかありますが、同様の状況だと思います。特定の状況においては、「すべてをRustに移植しよう」というよりも、このアプローチの方が適切だと思います。\n\n\n    ですので、Rustでの実装に興味がある方には、Rustを使用する利点がより明らかな箇所を探すことをおすすめします。標準的なGitのソースベースでは、C言語の使用はそれほど問題はなかったと思います。\n\n\n    **数年ごとに、新しいバージョン管理システムが登場しています。Gitは今後も、重要なツールとしての地位を維持できるとお考えですか？** \n\n\n    SCMにネットワーク効果があることは先ほどお話ししました。そのため、Gitに取って代わるには、少し優れているだけではなく、はるかに優れている必要があると思います。もしくは、互換性が高すぎると、実質的にGitの新しい実装となります。\n\n\n    SCMを取り巻く状況は実際に変わったと思います。Gitには、Git以前のSCMが抱えていたような、深刻かつ根本的な問題はありません。したがって、「はるかに優れている」ツールを開発するのはかなり大変です。\n\n\n    ですので、当面の間、Gitが現在の地位を維持できると考えています。人々はGitに代わるツールではなく、Gitを*ベース*として改善に取り組んでいくでしょう。\n\n\n    *注：このインタビューは、長さを調節し、文意を明確にするために編集されています。*\n\n\n    ## Gitの関連リンク\n\n\n    - [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \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-the-git-reftable-format/)\n\n    - [Gitプロジェクト](https://git-scm.com/)\n  category: open-source\n  tags:\n    - open source\n    - git\nconfig:\n  slug: celebrating-gits-20th-anniversary-with-creator-linus-torvalds\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/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","https://about.gitlab.com","article","ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",[11,23],[22,23],"VBy-79idVSt8xN9os7nFyMddmmii5ZAKlZ7f7GnJnqQ",{"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},1777493679215]