Levi's store app: 17 AI agents complete 9 months of work in 2.5 months

複数のAIエージェントが同じコードを同時に修正すると、互いに衝突して混乱が生じるのではないでしょうか。企業がこのシステムを安全に導入できる理由は、エージェントの「知能」ではなく、衝突を防ぐ「構造」にあります。Levi Strauss & Co.（リーバイ・ストラウス）は実際、店舗向けアプリ開発に17の専門化されたAIエージェントを投入し、従来9か月かかっていた開発期間を約2.5か月に短縮しました。すべてのプルリクエスト（PR）を5〜11の独立したエージェントがレビューし、修正を自動コミットしつつも、最終的なマージは人間が承認するよう制御していました。

複数のエージェントを同時に安全に運用するには、分離、権限分割、人間による承認という3重の安全装置が必要です。GitHubは、この原則をCopilotアプリの並列セッションでは「Git Worktree（Gitワークツリー）」として、エージェント型ワークフローでは「Safe Outputs」として実装しています。これら3つの仕組みがどのように混乱を防ぎ、並列作業の信頼性を確保するのか、具体的に見ていきます。

エージェントはサーバーではなく「テキストの指示文」

AIエージェントと聞いて、高性能なサーバー上で独立して稼働する複雑なプログラムを想像しがちです。しかし、Levi StraussのシニアディレクターであるJenny Patchen（ジェニー・パッチェン）氏が2026年10月のGitHub Universe（GitHub Universe 2026）で公開した実際の事例は、それよりもはるかにシンプルで透明性が高いものでした ¹, ²。Leviの開発環境において、エージェントは実行ファイルではなく、Gitリポジトリ内の特定のフォルダーに存在するMarkdown（.md）テキストファイルでした。

このMarkdownファイルには、エージェントが何をすべきかを伝える指示文が記されています。開発者はこのテキストファイルを直接編集して、エージェントの動作を変更します。一般的なアプリケーションコードと同様に、エージェントの性質を調整し、変更内容は既存のコードと同じくPRを通じて同僚のレビューを経て、バージョン管理されます ²。つまり、エージェントはブラックボックスではなく、テキストで制御可能な開発ツールであり、これにより企業はAIの動作を細かく管理できます。

第1の装置：Worktreeによる物理的な衝突の遮断

複数のエージェントが動き出すと、最も懸念されるのはファイル衝突です。エージェントAがファイルを修正した直後に、エージェントBが同じファイルを上書きしてしまえば、コードは乱雑になります。GitHubはこの問題を解決するため、Copilotアプリの並列セッションに「Git Worktree」機能を適用しました。

GitHub公式ブログで紹介された「tailspin-toys」の例では、この方式を「コインランドリーで複数の洗濯機を同時に回すこと」にたとえています ³。各洗濯機（セッション）を各自の設定で個別に回すことができ、ある洗濯機の完了を待たずに別の洗濯機をすぐに起動できるという意味です ³。

複数の洗濯機が同時に洗濯を行っても、各洗濯機は自分専用の独立したスペースを使用するため、互いに干渉しません。エージェントが機能開発、コードレビュー、テスト実行を同時に遂行しても、物理的なファイル衝突は発生せず、開発者はコンテキストを切り替える際に、各セッションが維持していた最後の状態をそのまま引き継げるため、待ち時間を短縮できます ³。

第2の装置：Safe Outputsによる権限分割

ワークスペースが分離されて物理的な衝突がなくても、複数のエージェントがリポジトリに直接ファイルを自由に書き込み、修正できると、リポジトリはすぐに混乱の渦に巻き込まれます。AIが暴走して無意味なファイルを大量に生成するリスクがあるためです。これを防ぐため、GitHubは「Safe Outputs（安全な出力）」という精巧な権限分割構造を導入しました。

Safe Outputs構造では、エージェント自体はGitリポジトリにファイルを直接書き込んだり、コマンドを実行したりできる「書き込み権限」を持つことができません ⁴。エージェントは作業中に問題を発見したり、コードを修正したりする必要がある際、システムに対して「この内容をissueとして登録してください」や「このコードを修正してください」という形式の「リクエスト」だけを構造化された出力として記録します ⁴。実際のファイル生成やコード修正といった「実行」は、別途厳格な権限を付与されたバックグラウンドタスクが代行します ⁴。

この仕組みは、制御不能なAIの暴走を防ぐ安全装置として機能します。デフォルトの設定では、エージェントが自動的に「create-issue（issue作成）」機能にアクセスできますが、実行回数の上限（max: 1）が厳格に設定されているため、無限ループに陥ることを防止できます ⁴。また、「depends-on」条件を活用して、前段のタスクが完了するまで後続タスクを待機させる順序制御も可能です ⁴。

第3の装置：人間の決定権の維持

技術的な分離と権限制御によって安全性を確保しても、最終的な成果物に対する責任は人間が負う必要があります。Levi Straussは店舗向けアプリのリニューアルを進めるにあたり、要件定義、テスト実行、セキュリティスキャンなど、17の専門化されたエージェントを配置しました ²。これらは開発ライフサイクル全体の「実行」を担いました。

しかし、このプロセスの中核原則は「エージェントは実行し、人間が決定する」でした ²。17のエージェントは外部ツールと連携してコードを修正し、コミットまで行いましたが、実際のライブ環境へ適用されるための最終的な「マージ（Merge）」ステップでは、必ず人間の確認と承認を経るよう設計しました ²。

従来のプロセスで生じていた6つの役割間の12回に及ぶタスク引き継ぎや待ち時間をなくすことで開発速度を高めつつ、プロジェクト最終承認という決定権と責任の所在は明確に開発者へ残しました ²。

実際の動作フローを追ってみる

これら3つの装置が一つに結び付き、実際の開発環境でどのように機能するかを、ひとつの機能追加プロセスを通じて確認できます。このプロセスから、AIが単にコードを高速に入力して時間を節約するだけではないことが分かります。

まず、要件エージェントが新しい機能リクエストを確認し、開発者がレビューできる仕様ドラフトをMarkdown形式で作成します。人間がこの仕様の優先順位を確定して承認すると、ビルドエージェントがそれに基づいて実際のコードを作成し、PRを生成します ²。

生成されたPRに対し、5〜11の独立したレビューエージェントが同時にアクセスし、問題点を発見するとコードの該当行に直接コメントを残したり、コードを修正してブランチにコミットしたりします ²。最終ステップでは、開発者が複数エージェントが残したコメントや自動修正結果を一覧で確認した後、最終的にマージボタンを押します。

その結果、Levi StraussのBack Pocketアプリ開発期間は、約9か月から2.5か月に短縮されました ²。これは、AIが人間のコーディング速度そのものを向上させたためではありません。各専門エージェントが待ち時間を排除し、タスクを並列処理することで、プロセス自体に要する時間を構造的に圧縮した結果です。複雑なマルチエージェント協働の時代には、AIの自律性だけを信頼するより、制御されたレールを敷くことの方が、企業環境を安全に保護する現実的な方法です。