執筆者：Leoあなたは、プログラミングということが完全に変わるかもしれないと考えたことがありますか？開発者は単にAIツールを使うだけでなく、AIをソフトウェア構築の新たな基盤として捉え始めています。これは小さな調整ではなく、根本的なパラダイムシフトです。想像してみてください。私たちが長い間慣れ親しんできたコア概念――バージョン管理、ブランチ、コードレビュー、さらには「協力」の定義さえ――が、AIエージェント駆動のワークフローによって再定義されつつあります。さらに衝撃的なのは、私たちが日常的に使っているGitは、実は20年前のメールリストのパッチワークフローのために設計されたツールでありながら、今や人間の開発者とAIエージェントの両方が同時に作業するシナリオに対応しようとしていることです。これが、GitButlerが1700万ドルのシリーズA資金調達を獲得したというニュースに立ち止まり、真剣に考えさせられる理由です。このラウンドはa16zがリードし、Fly VenturesとA Capitalが追随しています。さらに面白いのは、GitButlerのCEOであるScott ChaconがGitHubの共同創設者の一人であり、ほぼすべての開発者が読んだことのある『Pro Git』を書いた人物だということです。すでにバージョン管理の分野で大成功を収めた人物が、なぜ「すでに解決済み」と思われているこの問題に再び挑戦し、起業の道に戻ったのか。彼は発表の中でこう率直に述べています：「私たちは『より良いGit』を作っているのではなく、ソフトウェア構築の次世代インフラを構築しているのだ。」この言葉の裏には、ソフトウェア開発の未来に対する深い洞察が隠されています。---Gitの20年のジレンマ：メールリスト向けに設計されたツール多くの人は、Gitの歴史的背景をあまり理解していません。Gitは最初、Linuxカーネルチームによって2005年に作られ、その設計哲学はUnixの伝統に深く根ざしています。Scottはインタビューの中で、面白い詳細に触れています：Gitのコアチームは、ユーザーフレンドリーなインターフェースを作るつもりは最初からなかったと。彼らはUnix哲学に従い、一連の低レベルの「パイプコマンド」を構築しました。各コマンドは単純なことを行い、それらをPerlスクリプトでつなぎ合わせて、あらゆることができるようにしたのです。この設計思想は当時非常に合理的でした。なぜなら、Linuxのコアチームのような技術の専門家だけがこのツールを使うと想定していたからです。その後の展開は皆さんもご存知の通りです。Pasquyという開発者がPerlスクリプトを書き、Gitに統一されたユーザーインターフェース、つまり今私たちが使っているCLIコマンドをラップしました。これらのスクリプトは次第に普及し、最終的にはGitのコアに統合され、「瓷器層（porcelain）」と呼ばれるものになりました。面白いのは、これらのコマンドは2005年、2006年以降、大きな変化をほとんど経験していないことです。最初はPerlで書かれ、その後Cに書き直されたものの、コアのロジックやユーザーインターフェースはほぼ変わっていません。Scottは、2009年に最初の『Pro Git』を書いたときに記述したこれらのコマンドは、今でもそのまま使えると述べています。この安定性は一面では良いことです。Gitのチームは後方互換性を非常に重視し、既存の機能を削除したくないと考えています。これは、既存のワークフローを壊すことを恐れているからです。しかし、これには根本的な問題も伴います。Gitが設計された当時の仮定は、今のソフトウェア開発の実践と大きく乖離しています。Gitはメールリストを通じてパッチを送るために作られました。その時代、開発者はローカルで修正を行い、パッチファイルを生成してメールで送信し、メンテナがそれをレビューして受け入れるか決めていました。全ての流れは非同期で、テキストベース、シングルスレッドのものでした。しかし今やどうでしょう？私たちは継続的インテグレーションや継続的デプロイ、分散チームによるリアルタイムの協力、コードレビューのツール、さまざまな自動化されたテストやデプロイパイプラインを持っています。さらに重要なのは、AIエージェントが大規模にコードを書いているという事実です。Scottは、私たちが今、メールリストのパッチ設計のツールをAIエージェントに教えているという、非常に印象的な観察を述べています。このズレは、まるでテスラの車が馬車のために設計された道路を走っているような感覚です。---GitのUnix哲学設計がもたらすもう一つの問題は、それがコンピュータと人間の両方に同時にサービスを提供しようとしたことです。例えば、「git branch」を実行すると、デフォルトでは単なるブランチのリストしか得られません。これは、Gitがこのコマンドの出力を人間が読めるだけでなく、他のプログラムが解析できるようにする必要があるからです。この妥協の結果、何が起きるか？Gitは人間にとってはあまり親切ではなく、コンピュータプログラムにとっても最適化されていません。"--porcelain"オプションを使えば機械可読の出力を得られますが、これは標準的なやり方ではなく、多くのコマンドにはこのオプションもありません。---AIエージェント時代の新たな課題：作業ディレクトリだけでは不十分にAIが大規模にプログラミングに関与し始めると、Gitの制約がより明らかになります。私自身も最近、複数のAIエージェントを同時に使ってみて、Gitの基本的な設計仮定――開発者一人、ブランチ一つ、線形のワークフロー――が完全に通用しなくなっていることに気づきました。現代の開発者は線形に作業しません。複数のエージェントを同時に動かすこともあります。例えば、一つはUIのバグ修正、もう一つはデータベースクエリの最適化、三つ目はドキュメントの更新をしているかもしれません。しかし、Gitのインデックスシステムはこの並列編集に耐えられず、崩壊します。なぜなら、それはローカルの作業コピーがコードベースに対して単一かつ原子的な変更を表していると仮定しているからです。---従来の解決策は、ワークツリーを使うことです。つまり、並列タスクごとにコードベースの複数のコピーを作る方法です。しかし、これには新たな問題も伴います。エージェントが五つ同時に作業している場合、それぞれに完全な作業ディレクトリのコピーが必要となります。ストレージ面では最適化されているとはいえ、多くのファイルコピーとディスク容量を消費します。さらに、これらのエージェントは完全に隔離されており、互いの作業内容を見えません。各エージェントが完了してマージしようとしたときに初めて衝突が判明します。その時点では、衝突解決のコストは非常に高くなっています。---GitButlerが提案する解決策は、「並行ブランチ（parallel branches）」です。これは私の目を見張るデザインです。並行ブランチは、普通のブランチのように複数同時に開くことができるものです。これにより、worktreeの利点（論理的な隔離）を得ながら、すべてのファイルを複製する必要はありません。すべてのエージェントは同じ作業ディレクトリ内で操作しますが、それぞれの変更は異なる仮想的なブランチに割り当てられます。Scottはインタビューの中で、次のようなシナリオを説明しています：二つのエージェントが同時に作業し、同じファイルを編集しようとしたとき、その編集方法が互換性がない場合。結果はどうなるか？一方のエージェントが自動的に自分のブランチをもう一方のブランチの上に積み重ねて、そのまま作業を続行し、スタックされた状態でコミットします。このようなインテリジェントな衝突処理は、従来のGitのワークフローではほぼ不可能です。---私は特に、GitButlerチームの実験を評価しています。彼らは複数のエージェント間にチャットチャンネルを設け、相互にコミュニケーションさせる試みも行いました。Scottはこの機能が非常にクールに見えたと語っています。エージェント間の会話を見られるのは魅力的だと。しかし、多くのテストの結果、この機能は実際には役に立たないと判明しました。エージェントは他のエージェントが何をしているかを自動的に検知し、その理由を推測し、自分の作業戦略を調整します。明示的な通信は不要であり、通信自体にコストがかかるため、全体の効率が逆に下がるのです。この発見は非常に示唆的です。私たちは人間の協力モデルをエージェントに単純に適用できない。エージェントには独自の働き方があるのです。---ユーザーインターフェースの再設計：人間向け、エージェント向け、スクリプト向けGitButlerが最近リリースしたCLIツールには非常に興味を惹かれます。これは単なるGitのラッパーではなく、コマンドラインツールの設計を根本から見直したものです。Scottは面白い観察を述べています。約80％の開発者は依然としてコマンドラインを使ってGitを操作しており、多くのGUIツールが存在するにもかかわらず、その理由はシンプルです。多くのGit GUIは、Gitコマンドをグラフィカルにラップしただけで、機能を大きく増やすことなく操作を遅くしているに過ぎません。もしあなたが何を実行すれば良いか知っているなら、直接コマンドを打つ方が速いのです。しかし、GitButlerのCLIは違います。さまざまなシナリオに応じて異なる出力フォーマットを提供します。直接コマンドを実行すると、最適化された人間向けの読みやすい出力（ヒントや提案を含む）が得られます。"--json"パラメータを付けると、構造化されたJSONデータが返され、スクリプト解析に便利です。彼らはさらに、エージェント向けに最適化された"--markdown"オプションも検討しています。Markdown形式はエージェントのコンテキストに注入しやすいためです。---さらに面白いのは、彼らがエージェントの行動を観察しながらツール設計を最適化している点です。"--json"オプションを提供しているにもかかわらず、エージェントは実際には人間が読みやすい出力を好み、それをパイプでjqやPythonスクリプトに渡して必要な情報を抽出しています。もう一つの発見は、エージェントは何らかの変更コマンドを実行した直後に「git status」を実行して状態を確認することが多いということです。そこで、GitButlerチームはすべての変更コマンドに"--status-after"オプションを追加し、操作後に自動的に状態を表示させる設計にしました。これは従来のUnix哲学には反しますし、スクリプトにはあまり適していませんが、エージェントにとっては理想的です。---また、彼らは出力を通じてエージェントにより多くのコンテキスト情報を提供する方法も模索しています。例えば、「これをしたい場合はこのコマンドを実行してください」といったヒントを出力に含めることです。これは人間には冗長に感じられるかもしれませんが、エージェントにとっては次の行動を迅速に決定する助けとなります。Scottはこれを非常に面白いUXの問題と捉えており、エージェントを新たな「ユーザーペルソナ」として扱う必要があると述べています。---ソフトウェア開発の本質的変化：コードを書くから仕様を書くへインタビューの中で、Scottは深く考えさせられる見解を述べています。未来の最も優れたソフトウェアエンジニアは、コードを書きまくる人ではなく、コミュニケーションや文章、説明が最も上手な人になるかもしれないと。これは一見逆説的に思えるかもしれません。多くの人がプログラミングを選んだのは、機械と対話できるからであり、人と対話するためではなかったからです。しかし、よく考えると、この流れは非常に合理的です。AIエージェントが効率的にコードを生成できる時代、ボトルネックはもはや実装の詳細ではなく、「何を望んでいるのか」を明確に伝えられるかどうかに変わります。Scottは自身のワークフローを共有しています。彼は今、ほとんどの時間を仕様書の作成に費やし、詳細に機能の動作を記述しています。設計の決定を下すたびに、AIに仕様書に基づいて実装させ、結果をテストします。問題があれば仕様書に戻って修正し、AIに再実装させる。このサイクルは非常に高速に回ります。なぜなら、自分で全ての実装コードを書かなくても済むからです。---この働き方の素晴らしさは、「見せて話す（show and tell）」のようなことがいつでもできる点にあります。従来なら、アイデアを検証するために詳細な技術ドキュメントを書き、チームに理解させてフィードバックをもらう必要がありました。しかし、ドキュメントは詳細でも、動作するプロトタイプには敵わない。今では、素早くプロトタイプを生成し、チームメンバーに実際に体験させ、フィードバックをもとに素早く改善できるのです。これにより、アイデアから検証までのサイクルが大きく短縮されます。---しかし、これには新たな課題もあります。チームの協力のボトルネックは、「この機能を実現できるか」から、「何を望んでいるのか」に変わるのです。Scottは、多くの開発者、特に自分は賢いと自負する人たちが、「自分のやっていることを説明する必要はない。コード自体が最良のドキュメントだ」と考えていると指摘します。しかし、AI時代にはこの態度は通用しません。明確に意図を伝え、チームやAIが理解できる仕様書を書けることが、これからの新たなスキルとなるのです。文章力は新たなスーパー能力です。---これに関連して、コードレビューの未来も考えさせられます。Scottは鋭い質問を投げかけています。もしあなたが大多数のソフトウェアエンジニアに、「プルリクエスト（PR）をちゃんと読んでいますか？」と尋ねたら、ほとんどの人は「いいえ」と答えるでしょう。全ての行を丁寧に読み、論理を追い、ローカルでテストしますか？多くの人は「いいえ」と答えるはずです。なぜなら、徹底的なコードレビューにはコストがかかりすぎて、見返りが少ないと感じているからです。しかし、AIエージェントはこのゲームを変える可能性があります。エージェントは、各行のコードを詳細にレビューし、テストを実行し、潜在的な問題を検出するのが得意です。疲れず、飽きず、一貫した基準でレビューできます。これにより、人間のレビュアーはより高次の問題――この変更は製品の方向性に合っているか？ユーザーの本当のニーズを満たしているか？アーキテクチャは妥当か？――に集中できるのです。具体的な実装の詳細や文法の誤り、潜在的なバグはAIに任せることができるのです。---PRとIssue：20年変わらない協力モデルは進化すべきGitHubのプルリクエスト（PR）システムは、オープンソースの協力の標準となっていますが、Scottはこのモデルに根本的な問題を指摘します。PRはブランチをベースにしたレビューであり、パッチベースのレビューではありません。これにより、「ちょっとしたバグ修正」や「ファイルを忘れた」などの無駄なコミットが大量に生まれます。PRはブランチ全体に焦点を当てているため、コミットメッセージの質はあまり重視されず、PRの説明が重要になります。しかし、そのPRの説明はGitの履歴には残らず、マージ後に失われることもあります。---メールリスト時代にはこれは問題ではありませんでした。各パッチには丁寧に書かれたコミットメッセージがあり、それがPRの説明の役割を果たしていたからです。レビューはパッチ単位で行われ、その質は直接的にコードの質と結びついていました。しかし、GitHubの時代になると、その制約は失われました。Scottは、未来のコードレビューはパッチベースに回帰すべきだと考えています。ただし、現代のツールの利点も活かすべきです。レビューはローカルで行い、コードを実行したりテストしたりできるようにすべきです。エージェントはさまざまなテストを実行し、潜在的な問題をマークし、人間は本当に重要な部分だけに集中すれば良いのです。---もう一つの興味深い視点は、チーム間のコミュニケーションについてです。Scottは、ソフトウェア開発において長らく改善されてこなかったのは、リアルタイムのコミュニケーションの不足だと指摘します。もしあなたがあるファイルを修正しているときに、他の誰かも同じファイルを修正していたら、最終的にマージするときに衝突が判明します。どちらかが100％の作業を引き受ける必要があります。しかし、もしリアルタイムでお互いの作業内容を知ることができたらどうでしょうか？人間にとってはリアルタイムのコミュニケーションはコストが高く、作業の妨げになるかもしれませんが、エージェントにとっては問題ありません。空き時間に互いに通信し、チームや他のエージェントの作業を把握し、潜在的な衝突を事前に検知したり、作業戦略を調整したりできるのです。---GitButlerが模索しているメタデータシステムも非常に興味深いです。彼らは、対話の記録やエージェントの思考過程、関連するコンテキスト情報をコミットやブランチに付加できる仕組みを作りたいと考えています。現状のGitはこうしたメタデータのサポートが非常に限定的です。これらの情報は、なぜその決定を下したのか、コードの背後にある思考過程を理解するのに役立ちます。ただし、これには大きなデータの問題も伴います。Scottは、テキストだけでもこれらのメタデータの規模は急速に膨らむと指摘します。彼らは、ChromeやMicrosoft Officeのチームが使うような大規模リポジトリの技術を活用し、この規模のデータを扱う必要があると述べています。---この変革についての私の考えScottのインタビューとGitButlerの物語を通じて、私は深く考えさせられました。ソフトウェア開発は根本的なパラダイムシフトを経験しており、その基盤となるバージョン管理システムも進化を余儀なくされています。20年前のGitの設計思想は先進的でしたが、今やそれは制約となりつつあります。私たちが必要としているのは、「より良いGit」ではなく、現代のワークフローとAI時代に適した新しいインフラです。特に共感したのは、Scottの「論理的な終点」についての考えです。彼は、言語学習のスタートアップを例に挙げ、「リアルタイム翻訳技術があっても、言語学習は死なない」と反論します。完璧な翻訳器があっても、双方が翻訳器を装着し続ける必要があり、そのコミュニケーションは本質的に劣ると。実際に日本で翻訳者と一週間過ごした経験からも、翻訳は優れていても、深い関係や複雑な協力を築くには不十分だと述べています。プログラミングも同じです。AIエージェントがどれだけ強力になっても、人間の判断、創造性、コミュニケーション能力を完全に代替することはできません。---GitHubの未来についても、Scottの見解は非常に的確だと感じます。GitHubの最大の強みはユーザーベースの大きさですが、最大の弱みは大企業としての変化の遅さです。今、業界全体が「次のGitHubは何か」を模索していますが、Scottはこの問い自体が間違いだと指摘します。GitHubは何かの「次」ではなく、新たな協力モデルを創造したのです。同様に、未来には今私たちが想像もできない全く異なる協力の仕組みが登場する可能性もあります。私は、GitButlerの価値は具体的な機能だけでなく、その思考法にこそあると考えます。彼らは、なぜ一度に一つのブランチだけで作業すべきなのか、なぜコミットは線形である必要があるのか、なぜエージェントと人間は同じインターフェースを使うのか、なぜ協力はPRやIssueを通じて行うのかといった、私たちが当たり前と思ってきた仮定に疑問を投げかけています。この第一原理からの思考こそが、急速に変化するこの時代に最も必要なアプローチです。---また、私たち開発者は新たなスキルを身につける必要性も痛感します。明確な仕様書を書くこと、アイデアを効果的に伝えること、AIエージェントの働き方を理解すること――これらは、単なるコーディング能力以上に重要になるかもしれません。これは、多くの開発者にとっては挑戦ですが、同時にチャンスでもあります。低レベルの実装から解放され、より創造的な仕事に集中できるのです。問題の定義、解決策の設計、トレードオフの判断といった高次のスキルが求められる時代です。---GitButlerの1700万ドルの資金調達は始まりに過ぎません。今後数年で、ソフトウェア開発の基盤となるインフラの再考が進むでしょう。バージョン管理、コードレビュー、プロジェクト管理、テスト、デプロイなど、これらのツールはすべてAI以前の時代に設計されたものであり、見直しが必要です。新たなパラダイムに適応できる開発者やチームは、この変革の中で大きな優位性を得るでしょう。---最終的に、ソフトウェア開発は、文法や実装の詳細にとらわれるのではなく、コミュニケーション、協力、意思決定により重きを置く仕事へと変わっていきます。これは一部の伝統的なプログラマーにとっては不安かもしれませんが、私はこれを良いことだと考えています。問題解決の本質に近づき、技術的な細部に縛られなくなるからです。複雑なGitコマンドを覚える必要もなく、マージの衝突を手動で解決する必要もなく、繰り返し作業に多くの時間を費やすこともなくなれば、私たちは本当に重要なこと――ユーザーニーズの理解、エレガントな解決策の設計、価値あるプロダクトの創造――に集中できるのです。これこそが、GitButlerが私たちに取り戻そうとしているソフトウェア開発の核心なのです。
GitHub 前創始者は a16z から 1700 万ドルを受け取り、エージェント時代の Git を作る
執筆者：Leo
あなたは、プログラミングということが完全に変わるかもしれないと考えたことがありますか？開発者は単にAIツールを使うだけでなく、AIをソフトウェア構築の新たな基盤として捉え始めています。これは小さな調整ではなく、根本的なパラダイムシフトです。想像してみてください。私たちが長い間慣れ親しんできたコア概念――バージョン管理、ブランチ、コードレビュー、さらには「協力」の定義さえ――が、AIエージェント駆動のワークフローによって再定義されつつあります。さらに衝撃的なのは、私たちが日常的に使っているGitは、実は20年前のメールリストのパッチワークフローのために設計されたツールでありながら、今や人間の開発者とAIエージェントの両方が同時に作業するシナリオに対応しようとしていることです。
これが、GitButlerが1700万ドルのシリーズA資金調達を獲得したというニュースに立ち止まり、真剣に考えさせられる理由です。このラウンドはa16zがリードし、Fly VenturesとA Capitalが追随しています。さらに面白いのは、GitButlerのCEOであるScott ChaconがGitHubの共同創設者の一人であり、ほぼすべての開発者が読んだことのある『Pro Git』を書いた人物だということです。すでにバージョン管理の分野で大成功を収めた人物が、なぜ「すでに解決済み」と思われているこの問題に再び挑戦し、起業の道に戻ったのか。彼は発表の中でこう率直に述べています：「私たちは『より良いGit』を作っているのではなく、ソフトウェア構築の次世代インフラを構築しているのだ。」この言葉の裏には、ソフトウェア開発の未来に対する深い洞察が隠されています。
Gitの20年のジレンマ：メールリスト向けに設計されたツール
多くの人は、Gitの歴史的背景をあまり理解していません。Gitは最初、Linuxカーネルチームによって2005年に作られ、その設計哲学はUnixの伝統に深く根ざしています。Scottはインタビューの中で、面白い詳細に触れています：Gitのコアチームは、ユーザーフレンドリーなインターフェースを作るつもりは最初からなかったと。彼らはUnix哲学に従い、一連の低レベルの「パイプコマンド」を構築しました。各コマンドは単純なことを行い、それらをPerlスクリプトでつなぎ合わせて、あらゆることができるようにしたのです。この設計思想は当時非常に合理的でした。なぜなら、Linuxのコアチームのような技術の専門家だけがこのツールを使うと想定していたからです。
その後の展開は皆さんもご存知の通りです。Pasquyという開発者がPerlスクリプトを書き、Gitに統一されたユーザーインターフェース、つまり今私たちが使っているCLIコマンドをラップしました。これらのスクリプトは次第に普及し、最終的にはGitのコアに統合され、「瓷器層（porcelain）」と呼ばれるものになりました。面白いのは、これらのコマンドは2005年、2006年以降、大きな変化をほとんど経験していないことです。最初はPerlで書かれ、その後Cに書き直されたものの、コアのロジックやユーザーインターフェースはほぼ変わっていません。Scottは、2009年に最初の『Pro Git』を書いたときに記述したこれらのコマンドは、今でもそのまま使えると述べています。
この安定性は一面では良いことです。Gitのチームは後方互換性を非常に重視し、既存の機能を削除したくないと考えています。これは、既存のワークフローを壊すことを恐れているからです。しかし、これには根本的な問題も伴います。Gitが設計された当時の仮定は、今のソフトウェア開発の実践と大きく乖離しています。Gitはメールリストを通じてパッチを送るために作られました。その時代、開発者はローカルで修正を行い、パッチファイルを生成してメールで送信し、メンテナがそれをレビューして受け入れるか決めていました。全ての流れは非同期で、テキストベース、シングルスレッドのものでした。
しかし今やどうでしょう？私たちは継続的インテグレーションや継続的デプロイ、分散チームによるリアルタイムの協力、コードレビューのツール、さまざまな自動化されたテストやデプロイパイプラインを持っています。さらに重要なのは、AIエージェントが大規模にコードを書いているという事実です。Scottは、私たちが今、メールリストのパッチ設計のツールをAIエージェントに教えているという、非常に印象的な観察を述べています。このズレは、まるでテスラの車が馬車のために設計された道路を走っているような感覚です。
GitのUnix哲学設計がもたらすもう一つの問題は、それがコンピュータと人間の両方に同時にサービスを提供しようとしたことです。例えば、「git branch」を実行すると、デフォルトでは単なるブランチのリストしか得られません。これは、Gitがこのコマンドの出力を人間が読めるだけでなく、他のプログラムが解析できるようにする必要があるからです。この妥協の結果、何が起きるか？Gitは人間にとってはあまり親切ではなく、コンピュータプログラムにとっても最適化されていません。"–porcelain"オプションを使えば機械可読の出力を得られますが、これは標準的なやり方ではなく、多くのコマンドにはこのオプションもありません。
AIエージェント時代の新たな課題：作業ディレクトリだけでは不十分に
AIが大規模にプログラミングに関与し始めると、Gitの制約がより明らかになります。私自身も最近、複数のAIエージェントを同時に使ってみて、Gitの基本的な設計仮定――開発者一人、ブランチ一つ、線形のワークフロー――が完全に通用しなくなっていることに気づきました。現代の開発者は線形に作業しません。複数のエージェントを同時に動かすこともあります。例えば、一つはUIのバグ修正、もう一つはデータベースクエリの最適化、三つ目はドキュメントの更新をしているかもしれません。しかし、Gitのインデックスシステムはこの並列編集に耐えられず、崩壊します。なぜなら、それはローカルの作業コピーがコードベースに対して単一かつ原子的な変更を表していると仮定しているからです。
従来の解決策は、ワークツリーを使うことです。つまり、並列タスクごとにコードベースの複数のコピーを作る方法です。しかし、これには新たな問題も伴います。エージェントが五つ同時に作業している場合、それぞれに完全な作業ディレクトリのコピーが必要となります。ストレージ面では最適化されているとはいえ、多くのファイルコピーとディスク容量を消費します。さらに、これらのエージェントは完全に隔離されており、互いの作業内容を見えません。各エージェントが完了してマージしようとしたときに初めて衝突が判明します。その時点では、衝突解決のコストは非常に高くなっています。
GitButlerが提案する解決策は、「並行ブランチ（parallel branches）」です。これは私の目を見張るデザインです。並行ブランチは、普通のブランチのように複数同時に開くことができるものです。これにより、worktreeの利点（論理的な隔離）を得ながら、すべてのファイルを複製する必要はありません。すべてのエージェントは同じ作業ディレクトリ内で操作しますが、それぞれの変更は異なる仮想的なブランチに割り当てられます。Scottはインタビューの中で、次のようなシナリオを説明しています：二つのエージェントが同時に作業し、同じファイルを編集しようとしたとき、その編集方法が互換性がない場合。結果はどうなるか？一方のエージェントが自動的に自分のブランチをもう一方のブランチの上に積み重ねて、そのまま作業を続行し、スタックされた状態でコミットします。このようなインテリジェントな衝突処理は、従来のGitのワークフローではほぼ不可能です。
私は特に、GitButlerチームの実験を評価しています。彼らは複数のエージェント間にチャットチャンネルを設け、相互にコミュニケーションさせる試みも行いました。Scottはこの機能が非常にクールに見えたと語っています。エージェント間の会話を見られるのは魅力的だと。しかし、多くのテストの結果、この機能は実際には役に立たないと判明しました。エージェントは他のエージェントが何をしているかを自動的に検知し、その理由を推測し、自分の作業戦略を調整します。明示的な通信は不要であり、通信自体にコストがかかるため、全体の効率が逆に下がるのです。この発見は非常に示唆的です。私たちは人間の協力モデルをエージェントに単純に適用できない。エージェントには独自の働き方があるのです。
ユーザーインターフェースの再設計：人間向け、エージェント向け、スクリプト向け
GitButlerが最近リリースしたCLIツールには非常に興味を惹かれます。これは単なるGitのラッパーではなく、コマンドラインツールの設計を根本から見直したものです。Scottは面白い観察を述べています。約80％の開発者は依然としてコマンドラインを使ってGitを操作しており、多くのGUIツールが存在するにもかかわらず、その理由はシンプルです。多くのGit GUIは、Gitコマンドをグラフィカルにラップしただけで、機能を大きく増やすことなく操作を遅くしているに過ぎません。もしあなたが何を実行すれば良いか知っているなら、直接コマンドを打つ方が速いのです。
しかし、GitButlerのCLIは違います。さまざまなシナリオに応じて異なる出力フォーマットを提供します。直接コマンドを実行すると、最適化された人間向けの読みやすい出力（ヒントや提案を含む）が得られます。“–json"パラメータを付けると、構造化されたJSONデータが返され、スクリプト解析に便利です。彼らはさらに、エージェント向けに最適化された”–markdown"オプションも検討しています。Markdown形式はエージェントのコンテキストに注入しやすいためです。
さらに面白いのは、彼らがエージェントの行動を観察しながらツール設計を最適化している点です。“–json"オプションを提供しているにもかかわらず、エージェントは実際には人間が読みやすい出力を好み、それをパイプでjqやPythonスクリプトに渡して必要な情報を抽出しています。もう一つの発見は、エージェントは何らかの変更コマンドを実行した直後に「git status」を実行して状態を確認することが多いということです。そこで、GitButlerチームはすべての変更コマンドに”–status-after"オプションを追加し、操作後に自動的に状態を表示させる設計にしました。これは従来のUnix哲学には反しますし、スクリプトにはあまり適していませんが、エージェントにとっては理想的です。
また、彼らは出力を通じてエージェントにより多くのコンテキスト情報を提供する方法も模索しています。例えば、「これをしたい場合はこのコマンドを実行してください」といったヒントを出力に含めることです。これは人間には冗長に感じられるかもしれませんが、エージェントにとっては次の行動を迅速に決定する助けとなります。Scottはこれを非常に面白いUXの問題と捉えており、エージェントを新たな「ユーザーペルソナ」として扱う必要があると述べています。
ソフトウェア開発の本質的変化：コードを書くから仕様を書くへ
インタビューの中で、Scottは深く考えさせられる見解を述べています。未来の最も優れたソフトウェアエンジニアは、コードを書きまくる人ではなく、コミュニケーションや文章、説明が最も上手な人になるかもしれないと。これは一見逆説的に思えるかもしれません。多くの人がプログラミングを選んだのは、機械と対話できるからであり、人と対話するためではなかったからです。しかし、よく考えると、この流れは非常に合理的です。
AIエージェントが効率的にコードを生成できる時代、ボトルネックはもはや実装の詳細ではなく、「何を望んでいるのか」を明確に伝えられるかどうかに変わります。Scottは自身のワークフローを共有しています。彼は今、ほとんどの時間を仕様書の作成に費やし、詳細に機能の動作を記述しています。設計の決定を下すたびに、AIに仕様書に基づいて実装させ、結果をテストします。問題があれば仕様書に戻って修正し、AIに再実装させる。このサイクルは非常に高速に回ります。なぜなら、自分で全ての実装コードを書かなくても済むからです。
この働き方の素晴らしさは、「見せて話す（show and tell）」のようなことがいつでもできる点にあります。従来なら、アイデアを検証するために詳細な技術ドキュメントを書き、チームに理解させてフィードバックをもらう必要がありました。しかし、ドキュメントは詳細でも、動作するプロトタイプには敵わない。今では、素早くプロトタイプを生成し、チームメンバーに実際に体験させ、フィードバックをもとに素早く改善できるのです。これにより、アイデアから検証までのサイクルが大きく短縮されます。
しかし、これには新たな課題もあります。チームの協力のボトルネックは、「この機能を実現できるか」から、「何を望んでいるのか」に変わるのです。Scottは、多くの開発者、特に自分は賢いと自負する人たちが、「自分のやっていることを説明する必要はない。コード自体が最良のドキュメントだ」と考えていると指摘します。しかし、AI時代にはこの態度は通用しません。明確に意図を伝え、チームやAIが理解できる仕様書を書けることが、これからの新たなスキルとなるのです。文章力は新たなスーパー能力です。
これに関連して、コードレビューの未来も考えさせられます。Scottは鋭い質問を投げかけています。もしあなたが大多数のソフトウェアエンジニアに、「プルリクエスト（PR）をちゃんと読んでいますか？」と尋ねたら、ほとんどの人は「いいえ」と答えるでしょう。全ての行を丁寧に読み、論理を追い、ローカルでテストしますか？多くの人は「いいえ」と答えるはずです。なぜなら、徹底的なコードレビューにはコストがかかりすぎて、見返りが少ないと感じているからです。
しかし、AIエージェントはこのゲームを変える可能性があります。エージェントは、各行のコードを詳細にレビューし、テストを実行し、潜在的な問題を検出するのが得意です。疲れず、飽きず、一貫した基準でレビューできます。これにより、人間のレビュアーはより高次の問題――この変更は製品の方向性に合っているか？ユーザーの本当のニーズを満たしているか？アーキテクチャは妥当か？――に集中できるのです。具体的な実装の詳細や文法の誤り、潜在的なバグはAIに任せることができるのです。
PRとIssue：20年変わらない協力モデルは進化すべき
GitHubのプルリクエスト（PR）システムは、オープンソースの協力の標準となっていますが、Scottはこのモデルに根本的な問題を指摘します。PRはブランチをベースにしたレビューであり、パッチベースのレビューではありません。これにより、「ちょっとしたバグ修正」や「ファイルを忘れた」などの無駄なコミットが大量に生まれます。PRはブランチ全体に焦点を当てているため、コミットメッセージの質はあまり重視されず、PRの説明が重要になります。しかし、そのPRの説明はGitの履歴には残らず、マージ後に失われることもあります。
メールリスト時代にはこれは問題ではありませんでした。各パッチには丁寧に書かれたコミットメッセージがあり、それがPRの説明の役割を果たしていたからです。レビューはパッチ単位で行われ、その質は直接的にコードの質と結びついていました。しかし、GitHubの時代になると、その制約は失われました。Scottは、未来のコードレビューはパッチベースに回帰すべきだと考えています。ただし、現代のツールの利点も活かすべきです。レビューはローカルで行い、コードを実行したりテストしたりできるようにすべきです。エージェントはさまざまなテストを実行し、潜在的な問題をマークし、人間は本当に重要な部分だけに集中すれば良いのです。
もう一つの興味深い視点は、チーム間のコミュニケーションについてです。Scottは、ソフトウェア開発において長らく改善されてこなかったのは、リアルタイムのコミュニケーションの不足だと指摘します。もしあなたがあるファイルを修正しているときに、他の誰かも同じファイルを修正していたら、最終的にマージするときに衝突が判明します。どちらかが100％の作業を引き受ける必要があります。しかし、もしリアルタイムでお互いの作業内容を知ることができたらどうでしょうか？人間にとってはリアルタイムのコミュニケーションはコストが高く、作業の妨げになるかもしれませんが、エージェントにとっては問題ありません。空き時間に互いに通信し、チームや他のエージェントの作業を把握し、潜在的な衝突を事前に検知したり、作業戦略を調整したりできるのです。
GitButlerが模索しているメタデータシステムも非常に興味深いです。彼らは、対話の記録やエージェントの思考過程、関連するコンテキスト情報をコミットやブランチに付加できる仕組みを作りたいと考えています。現状のGitはこうしたメタデータのサポートが非常に限定的です。これらの情報は、なぜその決定を下したのか、コードの背後にある思考過程を理解するのに役立ちます。ただし、これには大きなデータの問題も伴います。Scottは、テキストだけでもこれらのメタデータの規模は急速に膨らむと指摘します。彼らは、ChromeやMicrosoft Officeのチームが使うような大規模リポジトリの技術を活用し、この規模のデータを扱う必要があると述べています。
この変革についての私の考え
ScottのインタビューとGitButlerの物語を通じて、私は深く考えさせられました。ソフトウェア開発は根本的なパラダイムシフトを経験しており、その基盤となるバージョン管理システムも進化を余儀なくされています。20年前のGitの設計思想は先進的でしたが、今やそれは制約となりつつあります。私たちが必要としているのは、「より良いGit」ではなく、現代のワークフローとAI時代に適した新しいインフラです。
特に共感したのは、Scottの「論理的な終点」についての考えです。彼は、言語学習のスタートアップを例に挙げ、「リアルタイム翻訳技術があっても、言語学習は死なない」と反論します。完璧な翻訳器があっても、双方が翻訳器を装着し続ける必要があり、そのコミュニケーションは本質的に劣ると。実際に日本で翻訳者と一週間過ごした経験からも、翻訳は優れていても、深い関係や複雑な協力を築くには不十分だと述べています。プログラミングも同じです。AIエージェントがどれだけ強力になっても、人間の判断、創造性、コミュニケーション能力を完全に代替することはできません。
GitHubの未来についても、Scottの見解は非常に的確だと感じます。GitHubの最大の強みはユーザーベースの大きさですが、最大の弱みは大企業としての変化の遅さです。今、業界全体が「次のGitHubは何か」を模索していますが、Scottはこの問い自体が間違いだと指摘します。GitHubは何かの「次」ではなく、新たな協力モデルを創造したのです。同様に、未来には今私たちが想像もできない全く異なる協力の仕組みが登場する可能性もあります。
私は、GitButlerの価値は具体的な機能だけでなく、その思考法にこそあると考えます。彼らは、なぜ一度に一つのブランチだけで作業すべきなのか、なぜコミットは線形である必要があるのか、なぜエージェントと人間は同じインターフェースを使うのか、なぜ協力はPRやIssueを通じて行うのかといった、私たちが当たり前と思ってきた仮定に疑問を投げかけています。この第一原理からの思考こそが、急速に変化するこの時代に最も必要なアプローチです。
また、私たち開発者は新たなスキルを身につける必要性も痛感します。明確な仕様書を書くこと、アイデアを効果的に伝えること、AIエージェントの働き方を理解すること――これらは、単なるコーディング能力以上に重要になるかもしれません。これは、多くの開発者にとっては挑戦ですが、同時にチャンスでもあります。低レベルの実装から解放され、より創造的な仕事に集中できるのです。問題の定義、解決策の設計、トレードオフの判断といった高次のスキルが求められる時代です。
GitButlerの1700万ドルの資金調達は始まりに過ぎません。今後数年で、ソフトウェア開発の基盤となるインフラの再考が進むでしょう。バージョン管理、コードレビュー、プロジェクト管理、テスト、デプロイなど、これらのツールはすべてAI以前の時代に設計されたものであり、見直しが必要です。新たなパラダイムに適応できる開発者やチームは、この変革の中で大きな優位性を得るでしょう。
最終的に、ソフトウェア開発は、文法や実装の詳細にとらわれるのではなく、コミュニケーション、協力、意思決定により重きを置く仕事へと変わっていきます。これは一部の伝統的なプログラマーにとっては不安かもしれませんが、私はこれを良いことだと考えています。問題解決の本質に近づき、技術的な細部に縛られなくなるからです。複雑なGitコマンドを覚える必要もなく、マージの衝突を手動で解決する必要もなく、繰り返し作業に多くの時間を費やすこともなくなれば、私たちは本当に重要なこと――ユーザーニーズの理解、エレガントな解決策の設計、価値あるプロダクトの創造――に集中できるのです。これこそが、GitButlerが私たちに取り戻そうとしているソフトウェア開発の核心なのです。