コード生成の経済的変化と AI エージェントの実験

1 月の休暇明け、私は何か根本的な変化が起きたと確信して職場に戻りました。

大規模言語モデルは、ソフトウェア開発の経済構造を変えるのに十分な信頼性と低コストで有用なコードを生成できる段階に達しました。至る所のエンジニアたちが同じ実験を行っているように見えます。AI アシスタントに提案を求めるだけでなく、エージェントに実際の業務を与え、それがどこまで到達できるかを探っているのです。

もしこの動きが続いたらどうなるのか。コード生産がソフトウェア構築における主要な制約ではなくなった時、何が変化するのか。私はその問いを考え始めました。

これらの考えを 1 月に社内メモとしてまとめました。5 月には、その論文の一部を GitLab の Act 2 で発表しました。そこでは、ソフトウェアの生産にかかるコストと時間が劇的に縮小し、機械が人間の指示のもとでソフトウェアを構築する割合が増大していくこと、そしてそれに伴ってソフトウェア開発を支えるアーキテクチャ自体も変化せざるを得ないことを論じました。

6 月の GitLab Transcend では、そのアーキテクチャの最初の要素を披露しました。機械規模での並行処理に対応した再構築されたソース管理システム、ソフトウェアライフサイクル全体を横断するコンテキストグラフとしての GitLab Orbit、そしてエージェントのアイデンティティ、ポリシー、承認、監査に関するガバナンスです。

そして 8 月 21 日、Anthropic が *AI ネイティブな SDLC プレイブック* を発表しました。その冒頭には、シンプルな一文が記されています。

「コードはもはやボトルネックではない。」

同感です。

Anthropic の提唱するアプローチは、エージェントが実装を劇的に高速化できる時代における開発ライフサイクルの変化を具体的に示したものです。計画策定が機械可読な形式になり、引き継ぎが自動化され、検証プロセスがループ内に組み込まれ、人間の判断力が重要なゲートポイントに集中します。

私が興味を惹かれるのは、このワークフローのさらに一歩先にある未来です。コードがもはや主要な制約要因でなくなった時、何が希少価値を持つようになるのでしょうか？人々、エージェント、複数のモデルが機械速度でソフトウェアライフサイクル全体に関わるようになった企業には、どのようなアーキテクチャが必要となるのでしょうか？また、コード生成そのものがますます容易になる中で、持続的な価値はどこへ移行していくのでしょうか。

過去 8 ヶ月間、私は GitLab のエンジニアリングチームや、Stripe、Spotify、Amplitude といった他の組織が、これらの問いに対する答えを実環境で模索している様子を見守ってきました。彼らの経験を通じて、私の当初の確信はさらに強固なものとなりました。重要なのは、単に AI がコードをより速く生成できるようになったという事実だけではありません。

実装コストが劇的に低下した時、ソフトウェアを取り巻く経済構造とアーキテクチャもそれとともに変化するのです。

コード生成の制約から、その信頼をどう扱うかへとシフトしています。モデルへの信頼は、もはや単独の技術に依存するのではなく、それを囲む環境——コンテキスト、検証、ガバナンス、そして証拠——にかかってきます。組織が同時に多数のモデルやエージェントを運用するようになれば、この層は耐久性を持ち、特定のモデルや基盤となるクラウドベンダーに左右されない独立したものである必要があります。さらに、エージェントが組織のワークフロー、専門知識、運用ノウハウを内包していくなら、それらはモデルやクラウドを提供するベンダーのものではなく、あくまで組織自身の資産であるべきです。

業界を築いた制約

ソフトウェアエンジニアリングは過去 60 年間、一つの事実を中心に成り立ってきました。

コードは貴重だ。

ビジネスの意図を信頼できるソフトウェアに変換するには、複雑な抽象概念を頭の中で維持できる限られた人材が必要となるため、コストがかかります。また、些細なミスが巨大な結果を招くため脆く、複雑さは個人が吸収できる速度よりも急速に蓄積していきます。私たちがソフトウェアを構築する多くの手法は、この制約から派生したものです。

既存システムを維持するのは、再構築がリスクとなるからです。技術を置き換えるのではなく、つなぎ合わせることを選びます。技術的負債は何年も残存し続けます。なぜなら、それを解消するためのリソースを割くことは、その四半期に顧客が必要とする機能の開発と競合するからです。

開発者の生産性を最大化することに重点が置かれます。彼らが希少な資源を生み出す存在だからです。ツールが断片的だったり、環境が一貫していなかったり、プロセスが使いにくかったりしても、それらを変更するとエンジニアの速度が落ちる恐れがあるため、許容されてしまいます。

そして、レビューや承認、リリースのゲート管理、セキュリティチェック、変更プロセス、さらに高度化するテストといった一連の儀式が存在します。これらはすべて、作成に莫大なコストがかかり、失敗すればさらに大きな損失を招く資産を守るために存在しています。しかし、その価値の多くは結局のところ構築されることなく終わってしまいます。

ロードマップに載るアイデアの一つに対して、エンジニアリングという希少なリソースの経済的制約によって淘汰され、実現されないアイデアが多数あります。

私たちは、変更のコストを保護するために莫大なエネルギーを費やしてきました。なぜなら、これまで変更は常に高価なものだったからです。

しかし、この制約が崩れ始めています。そして、この根本的な制約が動けば、システム全体もいずれそれに伴って変化します。

抽象化の先には新たな制約がある

これは過去にも起こったことです。

かつて人間は、機械語そのものを直接プログラミングしていました。アセンブリ言語がそれを抽象化し、さらに高水準な言語へと抽象化が進みました。各レイヤーが一つの問題を劇的に安価にし、その背後に隠れていた別の問題が姿を現すのです。

手書きのアセンブリコードを惜しむ人はいません。私たちは、より大きな課題に取り組むようになったからです。

大規模言語モデル（LLM）は、技術的な意味でのコンパイラではありません。それらは確率的なシステムであり、定義された意味を持つ決定論的な変換ではありません。しかし、経済的な観点からはこの比喩が有用です。LLM は、意図から実装へと移行する際に必要な人間の労力を劇的に削減します。

ここで重要なのは以下の区別です。

コードの生産は豊かになりつつある。しかし、良質なソフトウェアではない。

モデルは、人間よりもはるかに速く実装コードを生成できます。しかし、それが生成されたコードが正しく、安全で、パフォーマンスに優れ、コンプライアンスを満たし、保守可能であり、さらにビジネスの意図に沿っていることを意味するわけではありません。

そのギャップこそが本質です。かつてコードが希少だった時代には、困難な課題は「いかにしてコードを生み出すか」でした。しかし、今やコードがあふれる時代において、困難な課題は「いかにしてそれを信頼するか」へと移り変わっています。

タイピングのコストが、より困難な問題を隠していた。AI がそれを明らかにしている。

安価な反復が戦略を変える

コードをタイプすること自体が最も難しい部分ではなかったという異論ももっともだ。

本当により難しいのは「何を構築するか」を決めることである。要件は曖昧で、顧客の考えは変わり、チーム間での誤解が生じる。重要なエッジケースは、ソフトウェアが現実世界と出会うまで現れないものだ。

これらはすべて真実だ。

しかし、この議論には前提がある。「間違えた場合のコスト」が変わらないという前提である。6 週間後に要件の解釈を誤っていたことに気づけば、それは莫大なコストがかかる。そのコストが「最初から正しくあること」への圧力となる。要件定義書やアーキテクチャレビュー、慎重な計画は、反復コストが高い状況における合理的な対応策だ。

反復のコストを下げれば、戦略は逆転する。

実装前に不確実性を排除しようとするのではなく、より速く学習することに注力するようになるのだ。

さらに、おそらくそれ以上に重要な帰結もある。エンジニアリング組織には膨大な量の知識が蓄積されているが、その多くはソフトウェア自体の一部として組み込まれていない。経験豊富なエンジニアはどのサービスが脆弱かを知っているし、3 年前のデプロイ失敗の理由を覚えている人もいる。セキュリティエンジニアなら、直近のインシデントを引き起こしたミスの種類も記憶しているだろう。今日では、こうした学習の多くは人間の頭の中に存在する。実装のコストが下がれば、その知識のより大きな部分が実行可能なコードとして残るようになる。

生産環境での障害は回帰テストに、セキュリティインシデントはポリシーに、パフォーマンス要件は自動化された制約に、コンプライアンス義務は継続的な検証に変換されます。

学習がコードになるのです。

もちろん、すべてがそうなるわけではありませんし、実行可能な制約だけで判断が不要になるわけでもありません。ポリシーには誤りがあるかもしれませんし、テストには過去の前提条件が埋め込まれていることもあります。しかし、組織の知見は、その知識を持つ人が去ったときに消えてしまうのではなく、持続可能で検証可能、かつ修正可能なものとして残るようになりつつあります。これは従来の組織記憶とは異なる形態であり、コードの増加が単に量を増やすだけでなく、品質を向上させる理由の一つでもあります。

Amplitude は最近、このような大規模な見直しがもたらす可能性を示す 目を見張るような事例 を発表しました。6 ヶ月間でプルリクエストの数は 3 倍に増えましたが、報告されたバグは月間 715 件から 319 件へと減少しました。これは「AI が生成したコードが増えればソフトウェアが良くなる」という証明にはなりませんが、「変更量を増やしても、品質が比例して低下する必要はない」ことを示しています。

承認された変更あたりのコスト

この転換において最も重要な経済指標は、行ごとのコストではありません。

承認された変更あたりのコストです。

有用なソフトウェア変更には、コード生成、環境構築、文脈の提供、検証、レビュー、修正、ガバナンスといった要素が含まれます。AI は「生成」という工程を劇的に短縮していますが、それによって他の工程の相対的な重要性が浮き彫りになっています。仮に組織がコード生成速度を 10 倍にしても、CI（継続的インテグレーション）、レビュー、検証のプロセスを変えなければ、全体の開発スピードが 10 倍になるわけではありません。

単に待ち行列が移動するだけだからです。

これはまさに制約理論（Theory of Constraints）が予測している通りで、一つのボトルネックを解消すれば、システムは次のボトルネックを露呈させます。現在、その現象が現実のものとして現れ始めています。

エージェントが本番環境に到達したとき

Stripe は「minions」と呼ばれる社内コーディングエージェントを構築しました。同社では週に 1,000 件以上ものプルリクエストがマージされていますが、そのコード自体は完全に minions が生成したものです。人間が行うのはレビューのみで、実装はすべてエージェント任せです。

Amplitude は開発パイプラインの 6 ヶ月間にわたる大規模改修をドキュメント化しました。その結果、プルリクエストのサイクル時間は 5.2 時間から 44 分へと短縮され、フロントエンドの CI 時間も約 30 分から 3〜4 分にまで削減されました。

Spotify もまた、「Honk」という背景で動作するコーディングエージェントを運用しており、本番環境にマージされた AI 生成のプルリクエストが 1,500 件以上あることを報告しています。

これらは非常に能力の高いエンジニアリング組織ですが、その経験が「すべての企業が同じように変わる」という証明として扱われるべきではありません。これらの事例が有用なのは、次の制約を明らかにするまで十分に進展している点と、同じような制約が複数回現れている点にあります。

Amplitude の開発環境には、手動設定の蓄積、低速な CI（継続的インテグレーション）、そして一貫性のないツールチェーンが長年存在していました。それが何年も続いたのは、コード生産性がシステムへの変更速度を制限していたからです。エージェントはその制約を取り除き、検証とレビューが新たなボトルネックとなりました。

そこで Amplitude は基盤の再構築に着手しました。環境セットアップの高速化、劇的に速くなった CI、そして人間もエージェントも混乱させる一貫性のないパターンを減らすことです。この作業のほとんどは AI によるものではなく、AI がシステムの処理能力を変えたために必要となったインフラ整備でした。

多くの組織が現在、最適なコーディングモデルを選ぶことに注力しています。

しかし実際には、30 分かかる CI パイプラインは、どんなモデルでも無力化します。

エージェントは既存のエンジニアリング制約をなくすわけではありません。むしろ、それらをより速く浮き彫りにするのです。

成熟度の単一曲線ではなく、3 つのモード

AI 導入に関する多くの記述では、従来の開発から完全自律型開発への単一の道程が暗示されています。しかし、企業の移行はそう単純には進まないと考えます。3 つのモードが長く共存することになるでしょう。

モード1：人間が制御するレガシーシステム

ドキュメント化されていない依存関係や、まだ人の頭の中に残っている運用ノウハウを持つシステムです。これらは廃止されるか書き換えられるまで、大半は依然として人間の管理下に置かれるでしょう。

モード2：エージェントによる開発加速

人間が制御権を握り続けつつ、実装、テスト、移行、レビュー、ドキュメント作成、セキュリティ分析などの作業をエージェントが支援します。現在、多くの企業開発はこの段階にあり、近未来の経済的価値の多くもここから生まれると予想しています。

これは単なる自律化への待機室ではありません。エージェントが最も価値を発揮する用途の一つは、以前は正当化不可能だった近代化プロジェクトを、経済的に実行可能にする点にあります。

モード3：自律的な開発

実装ループの運用をエージェントが行い、人間は意図（インテント）、制約条件、そして監視を提供します。ここで重要な分岐点は「グリーンフィールドかブラウンフィールドか」ではありません。重要なのは、実行プロセスが依然として人間の制御下にあるのか、それとも安全にクローズドループで動作できるのかという点です。

システムの現状を把握する実用的な方法として、3 つの質問を投げかけることができます。

1. 利用可能なコンテキストだけで、エージェントが有用な変更を加えられるか？
2. その変更は、人間がすべての行を読み込むことなく検証できるか？
3. もし間違っていた場合、システム側で検出可能か、それとも人間に依存するか？

これらの答えが人間の介入に依存する度合いが高いほど、モデルの能力が高かろうと、その作業負荷は依然として「Mode 1」に近い状態にとどまります。

移行期間中に組織が犯しうる最もコストの高いミスの一つが、すべてのワークロードを早期に無理やり「Mode 3」へ移行させようとする試みです。

パイプラインが内部ループを実行する

Amplitude はフロントエンドの CI を 5 分未満に短縮しました。これによりリモートパイプラインが十分に高速化され、エンジニアは並列で多数の作業を開始し、結果が返ってくるたびにレビューできるようになりました。

Stripe も別のアプローチから同様のアーキテクチャを達成しています。彼らは「minions（従属プロセス）」に隔離された事前ウォームアップ済みの開発環境を提供することで、多くのジョブが互いに干渉することなく並列実行できるようにしました。

現在、コーディングエージェントのワークフローの多くはまだラップトップ上で始まります。これは出発点としては妥当ですが、アーキテクチャの最終地点である可能性は低いです。

アジェンティックシステムにおいて、パイプラインこそが内部開発ループを実行する自然な場所となります：

生成 → ビルド → テスト → 検証 → レビュー → 修正 → 繰り返し

エージェントは、単に「それらしいコード」を返すのではなく、組織が定義した制約を満たす機能的で検証済みのソフトウェアを提示できるまで、これらのフィードバック信号に対して作業を続けます。

内部ループの高速化は、協調の必要性も高めます。個々の変更がすべて妥当であっても、システム全体を矛盾する方向へ引きずる可能性があります。

AI がソフトウェア開発ライフサイクル（SDLC）の各フェーズ間のギャップを圧縮するにつれ、意図の整合性は定期的なものから継続的なものへと移行しなければなりません。

このループがリポジトリおよびその周辺システムに近接しているべきには、アーキテクチャ上の理由があります。

パイプラインはすでにコード、ビルドシステム、テストインフラストラクチャ、セキュリティ制御、デプロイ設定、そして変更を取り巻く歴史の多くと隣り合わせにあります。エージェントがこれらのシステムに近いほど、遠隔呼び出しを繰り返したり断片化された API を介して文脈を再構築する必要が減り、フィードバックを受け取る速度も上がります。

これは重要です。機械的なスピードでの開発では、わずかな遅延や文脈の喪失さえも、システム全体のボトルネックに転じかねないからです。

ループをそこで実行することは、作業に関する証拠を保全することにもつながります。変更を開始したアイデンティティ、適用されたポリシー、実行されたテスト、行われたレビュー、エージェントが実施した修復、そして最終的にリリースされたアーティファクトは、すべて相互に接続されたまま維持できます。

これは効率性以上の意味を持ちます。自律性の向上を管理可能にするための基盤だからです。

パイプラインは、開発の終わりにあるゲートから、開発ループそのものを実行するシステムへと進化します。

エージェント開発が最も効果的にスケールするのは、実行環境・文脈・ガバナンスが作業現場に密着している場合です。エージェントが適切な文脈を素早く取得し、決定論的なフィードバックを受け取り、自身の成果を検証できるほど、人間に引き継ぐ前に安全にループを完遂できる割合は高まります。

もはや問われるべきは「コードがコンパイルされたか」だけではありません。

重要なのは、「この変更は実際に良質だったのか」、そして「それをどう証明できるか」という点です。

自律性は付与されるものではなく、ガバナンスによって制約される

モデルの能力が向上するにつれ、私は自律性を制限する最大の要因がガバナンスになると考えています。

私が目にしてきた停滞した企業プロジェクトは、モデルにコードを生成させること自体が難しいから止まったわけではありません。

むしろ、より基本的な問いで足踏みしています。「エージェントは何を許可されているのか」「その成果をどう証明するのか」「間違えた場合の責任の所在はどこか」です。

Stripe のアーキテクチャ（Stripe’s architecture）はこのパターンを示しています。Minion は、オープンエンドなエージェントループと、Git・リンティング・テストのための決定論的なソフトウェアを組み合わせます。これらは隔離された環境で実行され、プッシュ前にローカルチェックを通過し、300 万を超えるテストからなるスイートの中から必要なテストを選択的に実行します。

エージェントには創造性が求められます。

しかし、その創造性の限界はどこかを決めるのはシステムです。

Amplitude ではリスクモデルを用いて、自動的にマージできる作業と、依然として人間のレビューが必要となる作業を区別しています。

Spotify の検証アーキテクチャでは、エージェントが検証機能にアクセスできる一方で、検証器の内部実装は隠蔽され、プルリクエストの作成前に必要なチェックが実行されます。

これらの組織はいずれも、プロンプトの改善だけで信頼性を高めたわけではありません。能力の高いモデルと、決定論的なゲート、分離環境、検証プロセス、ポリシー、そして証拠を組み合わせることで、自律性の安全な拡大を実現しています。

また、これがリソースに恵まれた大手テック企業以外ではより困難になる理由も説明しています。多くの企業は、独自のエージェント認証モデルや分離層、検証アーキテクチャ、証拠システムを一から構築する気はありません。既存の仕組みを継承することを期待しているはずです。

まさにそれが、GitLab が「コントロールされたスピード」と語る際に意味するところです。

コントロールのないスピードは、組織がリスクを受け入れられなくなることでいずれ止まります。一方、スピードのないコントロールでは AI の価値が十分に発揮されません。この二つは、一体的に設計される必要があります。

説明責任の明確化

自律的な開発に対する懸念の一つとして、「説明責任が機械の中に消えてしまう」というものがあります。これはシステム設計が不適切な場合に起こり得ます。しかし、実行プロセスにおいてアイデンティティ、ポリシー、コンテキスト、証拠を維持することで、自律的な開発はむしろ説明責任をより明確にすることができます。

人間が責任を負うべきは、セキュリティポリシーやパフォーマンスの閾値、コンプライアンス上の義務、そして過去のインシデントから組織が何を学んだかといった制約条件を定義することです。制御プレーンは、これらの制約に対して実行が行われたことを証明できるものでなければなりません。

Amplitude が SOC 2 のアプローチ を説明した内容は示唆に富んでいます。同社の自動承認プロセスは、すべての適合する変更に対して人間が手動で「承認」ボタンを押すことを要求するのではなく、文書化された基準、記録された意思決定、そして例外処理のパスに基づいて機能します。人間の役割は、個々のアクションを承認することから、アクションが許可されるための基準そのものを管理・所有することにシフトします。これはより本質的な業務であり、監査も容易になります。

永続的なレイヤー

エージェントの能力が高まるにつれて、「ソフトウェア開発ライフサイクルの多くがモデル内部に収束し、周辺はコモディティ化されたインフラになる」という結論を導く人もいます。しかし私は、その逆の方が起こりやすいと考えています。

エージェントが実装ループを担う割合が増えるほど、永続的なエンタープライズ層の重要性はむしろ高まります。コンテキスト、アイデンティティ、ポリシー、出所証明、検証、そして組織の記憶といった要素は、作業を実行している特定のモデルやエージェント内部にのみ存在してはいけません。それらはモデルやエージェントを超えて持続的に保持されなければなりません。

そして時が経つにつれ、製品開発ライフサイクルでは、目的別に設計された複数のモデルを利用していくようになるでしょう。

タスクごとに最適化される要素は異なります。推論の質、レイテンシ、コスト、セキュリティ、ドメイン特化型、あるいはモデルが動作する環境などです。一部のケースでは最先端モデルが使われますが、他のケースでは顧客データやインフラに近い場所にデプロイされた小規模モデルやオープンウェイトモデルが採用されます。プランニングに最適なモデルが、コードレビュー、セキュリティ分析、テスト、または修正処理にも最適とは限りません。

これは技術が成熟する過程でよく見られるパターンです。単一の汎用機能が、異なるワークロード向けに最適化されたより専門的なスタックへと移行していきます。

そのような世界では、モデル自体が永続的なアーキテクチャとなるわけではありません。それは実行コンポーネントに過ぎません。

企業が使用するモデルやエージェントが増えれば増えるほど、それらを取り巻く共通の文脈、制御、履歴の価値は高まります。

これは、従来私たちがソフトウェア開発ライフサイクル（SDLC）と呼んでいたものの境界線も変えます。

SDLC は人々が計画、構築、テスト、セキュリティ確保、デプロイ、運用という一連の工程を作業を進めるために設計されました。しかし AI によってこれらの工程が継続的なエージェントループに圧縮されるにつれ、「ソフトウェアを開発すること」と「製品そのものを作成すること」の区別は曖昧になっていくでしょう。

emerging なモデルを製品開発ライフサイクル（PDLC）と捉えることができます。ビジネス上の意図がシステムに入力され、エージェントがそれをソフトウェアに変換し、検証とガバナンスが次に進むべき内容を決定します。そして生産結果が次の意思決定フィードバックとしてループに組み込まれ、このプロセスは継続していきます。

十分な規模に達すると、従来の開発プロセスというよりは、ソフトウェア工場のように見えてきます。これは、意図やビジネスのシグナルを継続的に取り込み、検証済みのソフトウェアに変換するシステムです。

しかし、ソフトウェア工場は単なる自律型エージェントの集まりではありません。その下層には、モデルやエージェントが変化しても文脈、アイデンティティ、ポリシー、証拠、そして組織の記憶を保持し続ける堅牢なレイヤーが存在する必要があります。

文脈と出所

Anthropic の AI ネイティブ SDLC プレーブック は、この移行を具体的な形にする点で有用です。ここでは、意図や仕様、計画が機械可読なアーティファクトへと変換される様子や、組織の知見が Claude に提供される仕組み、行動を強制するフックとスキル、エージェントをツールに接続する MCP、そして作業の証拠を保存するバージョン履歴などが説明されています。これらは有用なパターンであり、多くの組織がここから始めると考えられます。

GitLab における私たちのアーキテクチャへの賭けは、アジェンティック開発には単なるモデルの改良ではなく、新しいプラットフォームアーキテクチャが必要であるという点です。

そのアーキテクチャには、4 つの本質的な機能が必要です。それはエージェントプラットフォーム、機械スケールでの実行、永続的な文脈、そしてガバナンスです。これらについては後ほど詳しく説明します。

企業は複数のモデルを利用します。ベンダーが提供するエージェントと、自社で開発したエージェントを併用するようになります。さらに、ベンダーが生み出す優れたエージェントに加えて、自社のワークフローや専門知識、運用ポリシーを反映させた独自のエージェントを構築したいという要望も高まっています。

そのため、プラットフォームは両方の道筋をサポートする必要があります。顧客が選んだエージェントを持ち込み、自社で開発・カスタマイズ・運用するエージェントを自由に扱えるようにすべきです。

これらのエージェントは、コード処理、計画策定、セキュリティ管理、CI（継続的インテグレーション）、デプロイメント、そして本番システムなど、複数の領域にまたがって同時に動作します。組織が使用するモデルやクラウド環境を変更しても、エージェントを再構築する必要はありません。また、組織の文脈、ポリシー、アイデンティティ、履歴は、その時点での流行に合わせて選択された特定のモデルやエージェントベンダー、インフラプロバイダに縛られてはいけません。

モデルは交換可能であるべきです。エージェントは顧客のものとなるべきです。組織の記憶と制御機能は持続するべきです。

だからこそ、私はアーキテクチャ上の圧力は、単一のモデルやエージェントベンダー、クラウドが記録システムになる方向ではなく、モデルやクラウドに依存しないプラットフォームへと向かっていると信じています。

これは、ソフトウェア開発に関わるすべてのアセットを一つのベンダーが独占することを意味しません。アイデンティティは連合（フェデレーション）できます。イベントはシステム間を移動可能です。文脈はインデックス化できます。ポリシーは一元管理できます。MCP やその他のオープンインターフェースにより、エージェントは企業内のあらゆるツールにアクセスできるようになります。多くの組織がこのようなアプローチを採用していくでしょう。

このパターンにおけるより困難な課題は、自律システムがその環境を横断して動作する際に、意図から行動、そして結果へと至る連鎖をいかに維持するかです。

要件変更の承認が行われ、特定のアイデンティティとポリシー体制の下で変更が実行されます。検証によって証拠が生成され、デプロイによってそれが本番環境へ展開されます。最終的に本番環境で結果が生み出されるという一連の関係性が、因果グラフを形成します。

これら自体は新しい概念ではありません。変化しているのは、これらの関係性を維持する必要がある頻度です。人間の開発速度であれば、事後に複数のシステム間で追跡情報を再構築するのは苦痛を伴いますが、多くの場合生き残れるものです。

しかし、機械の速度で動作する場合、追跡情報は実行パスそのものの一環となります。

関連する関係性が共通システムや制御プレーン内でネイティブに存在すれば、エージェントはそれらを直接推論できます。一方、複数のシステムにまたがって存在する場合は、何らかの方法でそれらを再構築する必要があります。それは可能ですが、アイデンティティの整合性、同期、ポリシーの一貫性、意味マッピング、そして証拠の取得といった作業が発生します。機械的な規模での処理においては、その調整自体がシステムの制約になりかねません。

Spotify の事例は、コードベース内部で同様の課題が起きていることを示しています。ある マイグレーション において、Honk は複数のパイプラインフレームワークに直面しました。標準化されたフレームワークほど自動化は容易でしたが、一貫性の欠如が信頼できる文脈の構築を困難にしています。人間が作業する速度では、文脈の一貫性がないことが摩擦を生みます。一方、機械の速度では、それが出力の質を繰り返し低下させます。

自律的な開発において重要視される単位は、もはや個々の成果物ではありません。それは、意図とコード、ポリシー、証拠、デプロイメント、そして結果との間の関係性です。

だからこそ、私はソフトウェア開発の内部ループが、共通の制御平面へと向かう圧力にさらされると考えています。単一のベンダーがすべてのツールを独占する必要があるからではありません。信頼できる自律性を確保するには、機械が人間が経験したことのない規模で動作する間も、これらの関係性が一貫して保たれる必要があるからです。多くの要素を既に保有しているプラットフォームは、後からそれらを再構築しなければならないシステムに対して構造的な優位性を持っています。

ファイルではなくレコード

エージェント型開発において台頭しつつある実践の一つに、意図や仕様、実装計画を Markdown ファイルとして記述し、リポジトリにコミットする方法があります。

この発想には共感します。意図を明示化し、バージョン管理され、人間とエージェントの両方が読み取れるようにすることは、即座に価値を生みます。

しかし、ファイルと管理可能な記録の間には重要な違いがあります。大規模な企業環境では、システムは最終的にファイル単体では回答できない問いに答えなければなりません。

• 誰がこれを修正できるのか？
• 現在の状態はどうなのか？
• 誰が承認したのか？
• 適用されたポリシーのバージョンは何か？
• これによってどのようなデプロイが行われたのか？
• これらを一万件単位でどのように照会すればよいのか？

チームは Markdown の周りにある規約を通じてこれらの機能を再現できますが、まさにそれらは「記録システム」が長年かけて開発してきた機能そのものです。

最適なアーキテクチャでは、エージェントへのインターフェースとして Markdown を提示しつつ、その下層には構造化され管理された記録を保持します。

インターフェースはシンプルで構いません。しかし、その背後にあるシステムはそうはいきません。

エージェントは組織に帰属すべきである

エージェントには、組織がどのようにソフトウェアを構築しているかという文脈が必要です。具体的には、リポジトリの構造、コーディング規約、ビルドコマンド、テストプラクティス、アーキテクチャルール、そして既知の障害モードなどです。

Spotify はこの取り組みを コンテキストエンジニアリング と呼び、本物のコードベース上で信頼性が高くマージ可能なプルリクエストを生成するために不可欠であると発見しました。その知識が蓄積されるにつれ、それは組織の資産となります。

エージェント自体についても、同様に真実味を増しています。

エンタープライズエージェントには、長年にわたって蓄積された指示、ワークフロー、ツールアクセス権限、評価基準、運用ポリシーが組み込まれている可能性があります。時を経るにつれ、これらはエンジニアリング組織にとって最も価値ある知的財産の一部となり得ます。

それはモデルベンダーやクラウドプロバイダー、あるいは独自ランタイムに属するものではなく、あくまで組織のものであるべきです。

所有権が重要視されるもう一つの理由は、システムが複利効果を生み出せるからです。

エージェントが行動するたびに、組織は「何が機能し、何が失敗したか」に関する証拠を生成します。どの変更が承認され、どの変更が却下されたのか？どこで人間が介入したのか？本番環境で何に問題が発生したのか？どのような制約が問題を捉えたのか。

時を経て蓄積されたこれらの証拠は、組織独自のコードベースと成果に基づいた内部評価セットとなり、公的なベンチマークとは異なります。組織はこのデータを用いてモデルを評価し、エージェントを改善し、指示やワークフローを洗練させ、どこに真の自律性が求められるかを判断できます。

その結果生まれるのはフィードバックループです。エージェントが作業を行い、システムがその成果を測定し、組織が得た教訓が次世代のエージェントを、その組織特有の業務により適したものにします。

これは「学習がコードになる」という概念を拡張するものです。学習はテストやポリシーとして定着するだけでなく、評価基準（evals）、文脈、そして改善されたエージェントへと変容し得ます。

これは特定のベンダーを批判する主張ではありません。現在私たちは Anthropic のモデルを活用しており、今後も継続して利用していく方針です。Claude Code を使用する顧客は、自社で構築したエージェントと同様に、同じエンタープライズコンテキスト、アイデンティティ、監査証跡を保ちながら使い続けることが可能であるべきです。

重要なのは、顧客がモデルを選択し、必要に応じて変更したり、異なるタスクに異なるモデルを使ったり、自社のビジネス要件に適したインフラ上でエージェントを稼働させられることです。また、他社製のエージェントを持ち込み、同じエンタープライズコンテキストと管理機能へのアクセス権を与えることも可能であるべきです。

`AGENTS.md` は、コーディングエージェントに対してプロジェクトの指示やコンテキストを提供するためのオープンフォーマットの一例です。GitLab はこれをサポートしており、私たちは組織がモデルやエージェント、ベンダーを変更しても蓄積された知識が引き継ぎ可能でなければならないという観点から、同様のオープンフォーマットを今後も支援し続けます。

重要なのはファイル名そのものではなく、この原則です。

エージェントは自らが所有する。指示も、学習の基盤となるコンテキストもすべて自社で管理する。その下にあるモデルやインフラは選択肢として残す。

誰でもコードをリリースできる

Amplitude の事例 で得られた興味深い結果の一つは、エンジニアに関するものではありませんでした。開発環境の改善、検証プロセスの見直し、レビュー体制の強化を行った後、デザイナー、プロダクトマネージャー、マーケターが自らコード変更を行うようになりました。非エンジニアからのプルリクエストは、実質ゼロから約 5% に増加しました。

これは、今後さらに拡大すると予想される変更の初期段階です。実装コストが低下するにつれて、「何を構築するかを決定すること」と「実際に構築すること」の境界線は崩れ始めています。

プロダクトマネージャーは意図を実際のソフトウェアに変換できるようになります。デザイナーもプロトタイプから実装へと移行できます。エンジニアは、製品全体を通じてより高い抽象度のレベルで活動可能になります。また、従来の研究開発組織に属さない人々も、すでに持っている専門知識を直接活かしてソリューションを構築できる機会が増えています。

私は、この広範な役割を説明する用語として「ビルダー（Builder）」が有用になると考えています。ビルダーにはエンジニア、デザイナー、プロダクトマネージャー、セキュリティ専門家、マーケター、あるいはドメインのエキスパートが含まれます。彼らに共通するのは、「意図を表現し」「エージェントを指揮し」「結果を検証し」「アイデアを実働するものへと変換する」能力です。

これは前述の PDLC（プロダクト開発ライフサイクル）への移行の一部でもあります。プロダクトの意図、デザイン、実装、フィードバック間の距離が縮まることで、ソフトウェア開発はエンジニア内での専門的な引き継ぎという形から、継続的な製品構築ループへと変化していきます。

これは、専門性が消滅したり、全員がエンジニアになったりするわけではありません。むしろ逆かもしれません。エージェントが実装作業を多く担うようになるほど、ドメインの専門知識と判断力がより重要になります。アジェンシーシステムを監督する人物は、コーディングエージェントを管理するエンジニアマネージャーである必要はありません。それは「何が起きるべきか」を表現でき、「結果が正しいかどうか」を見極められるドメインのエキスパートであっても構いません。

その結果、ソフトウェアエンジニアリングにおける判断を必要とせずとも、より多くの人々がソフトウェアを作成できるようになります。

限られた人間の注力は、意図やアーキテクチャ、制約条件、困難なトレードオフの検討、そしてシステムが組織が本当に望んだ成果を生み出したかの評価へと向かっていきます。

ソフトウェア構築における作業範囲はエンジニアリングを超えて広がりますが、判断を要する必要性は変わりません。

統合の役割が外側へ移行する

これらはすべて、統合が不要になるという意味ではありません。むしろ、その重心が移動すると予想しています。

高頻度の実行ループ内では、エージェントが迅速なフィードバック、一貫したアイデンティティ、共有された文脈、そして強制可能なポリシーに依存するため、より密接な統合の価値が高まります。

一方、そのループの外側では、ソフトウェアを駆動する意図がビジネス内の他の場所から生まれることが増えるため、統合はさらに重要になります。

カスタマーサポートには顧客の課題があり、CRM にはコミットメントが含まれ、データプラットフォームには利用状況やビジネス成果が格納されています。オバザビリティはプロダクションの健全性を示し、コンプライアンスシステムは義務を定義します。これらのシステムがシグナル、意図、制約を提供し、開発制御プレーン（control plane）がそれらを管理されたアクションへと変換します。

時を経て、ビジネス上のシグナルとソフトウェアによるレスポンスの間の距離は劇的に縮まると予想しています。

したがって、その世界において最も重要な開発プラットフォームは、どれだけ多くの開発者ツールを置き換えるかではなく、ビジネスの要件を記述するシステムと、管理されたソフトウェア実行をいかに効果的に接続できるかで定義されるべきです。

新しいプラットフォームアーキテクチャ

そのような未来を実現するには、4 つの能力を中心としたプラットフォームアーキテクチャが必要です。

エージェント・プラットフォーム: 組織が所有するエージェントを作成、カスタマイズ、運用する能力。ここで重要なのは、自社のモデルとインフラストラクチャを選択して利用しつつ、外部から持ち込まれる顧客のエージェントもサポートできる点です。

実行環境:次世代の Git、アーティファクト管理、CI/CD を含む機能。人間規模だけでなく機械規模でも、ソフトウェアの構築、テスト、デプロイ、運用を可能にする能力です。

文脈: 作業に関連する要件、コード、履歴、ビジネス上の優先順位、制約などに関する一貫した全体像を提供することです。

ガバナンス: セキュリティ、コンプライアンス、品質、アイデンティティ、権限に関する強制可能な境界を設けること。さらに、エージェントが何を行ったか、なぜ許可されたのか、どこで人間の介入が必要なのかを理解するために必要な可視性も提供します。

自律性が向上するにつれ、ガバナンスは個々のアクションの承認から、例外を理解し方向付ける支援へと重心を移していきます。ポリシーとテストは組織がすでに決定した事項の判断を自動化しますが、最も難しいケースは誰も予測していなかったものです。

自律性の究極的な制約は、エージェントが行動できるかどうかではなく、人間が数百のエージェントを同時に理解し、制御できるかどうかにあるかもしれません。

これら 4 つのアーキテクチャ層はお互いを補強し合っています。エージェントは実行レイヤーを通じて行動します。実行によって生じるシグナルが文脈を豊かにし、より優れた文脈がエージェントの能力向上とガバナンスの精度向上をもたらします。そして、強化されたガバナンスにより、これらのエージェントはより高い自律性を持って運用できるようになります。

企業にとっては、その下で多数の異なるモデル、クラウド、製品、エージェントが参画している場合でも、これらすべての機能が一つの統合されたプラットフォームとして機能することが必要となります。

実務における意味合い

これらは遠い未来の自律システムに向けた単なるアーキテクチャ原則ではありません。すでに私たちが構築するものを変え始めています。

Act 2 では、ソフトウェア開発が機械スケールで運用されるようになるという前提に基づき、いくつかのアーキテクチャ上の賭けについて説明しました。6 月の GitLab Transcend では、そのアーキテクチャの最初の構成要素を示し、それぞれのデモを公開しました。

顧客は、自らが所有するエージェントを構築・実行できる場所を必要としています。GitLab Duo Agent Platform は、組織固有のワークフローや専門知識を中心に、これらのエージェントを作成し、カスタマイズして運用するためのプラットフォームです。顧客は基盤となるモデルを選択でき、ビジネスに必要なインフラ上で実行できます。また、外部のエージェントと併用することも可能です。目指しているのは、すべての企業を単一のエコシステムに縛り付けることではありません。むしろ、特定のモデルやクラウドベンダーにロックインされることなく、顧客が自らのエージェントを構築し、進化させていける場を提供することです。

実行は機械スケールで運用されなければなりません。エージェントは、従来のソース管理アーキテクチャでは想定されていなかった規模で、クローンを作成し、ブランチを分岐させ、リトライを実行し、パイプラインをトリガーします。この現実に対応するため、次世代のソース管理システムが再構築されています。これには、サーバーサイドでのアクセスパターンも含まれており、エージェントはタスクに実際に必要なデータのみを取得できるようになります。これにより、レポジトリ全体を繰り返し転送する非効率な作業が解消されます。内部テストでは、これらの変更により、タスクの実行速度が最大 50 倍向上し、移動させるデータ量が劇的に減少することが確認されています。

コンテキストはインフラストラクチャとなる必要がある。 GitLab Orbit は、コード、作業項目、パイプライン、デプロイメント、そして本番環境のシグナルをソフトウェアライフサイクル全体にわたる「コンテキストグラフ」として接続します。エージェントはこの関係性を、無数のバラバラな呼び出しを通じて再構築するのではなく、直接クエリできます。重要なのは、このコンテキストが GitLab 独自のエージェント専有ではないということです。サードパーティ製のエージェントも、同じ組織の記憶を利用できます。

ガバナンスはエージェントのプロンプト内部ではなく、それを囲む形で存在する必要があります。 「Agents のためのガバナンス」は、エージェントのアクションに対してアイデンティティ、ポリシー、承認、監査の制御を適用するように設計されています。これにより、組織は証拠や説明責任を放棄することなく、自律性を高めることが可能になります。

これらは異なるエンジニアリングプロジェクトですが、同じ前提に基づいています。

実装が豊富になるのであれば、その下にあるプラットフォームは、企業がエージェントを構築・導入できるようにし、すべてのエージェントに機械スケールでの実行、コンテキスト、制御を提供できなければなりません。

次の 90 日間で何をすべきか

承認された変更あたりのコストを測定する。 生成された変更から承認されるまでの経過時間を追跡し、それを環境、CI（継続的インテグレーション）、レビュー、修正、ガバナンスの各要素に分解してください。多くのチームでは、生成にかかる時間は全体のごく一部であることに気づくでしょう。

CI の時間を計測する。 完全なパイプラインが 5 分よりもはるかに長くかかる場合、モデルを切り替えることよりも、その時間の短縮の方が重要になる可能性があります。

承認の基準を明記するだけでなく、その根拠も書き留めよう。 低リスクの変更クラスの一つを選び、人間が手動で確認しなくてもマージしてよい条件を定義する。それが実行可能なガバナンスの第一歩となる。

文脈を移植可能にしよう。 リポジトリ内の指示や運用知識を、人間とエージェントの両方が利用できるオープンな形式でバージョン管理する。

どのビジネスシグナルを開発ループに直接取り込むべきかを選ぼう。 サポート、観測性（オバザビリティ）、コンプライアンスシステムには、すでに意図や制約が埋め込まれつつある。人間がそれらを再入力する必要なく、これらシグナルの一部を管理されたソフトウェア作業として扱うかを決定する。

ここから先へ進む道

コード生成はますますコモディティ化されている。それはソフトウェア開発が無料になるという意味ではない。経済構造が変わるだけだ。

有用な指標は「行ごとのコスト」ではない。

「承認された変更ごとのコスト」こそが重要なのだ。

生成コストが下がるほど、生成を取り巻く要素——環境、文脈、検証、ガバナンス、証拠——の相対的な重要性も比例して高まる。

これは、希少な人間の判断力がどこに集中すべきかも変える。実装が容易になっても、エンジニアリングの判断力が豊富になるわけではない。人間の注目は上位層へとシフトする：アーキテクチャ、意図、制約、困難な例外処理、そしてシステムが組織が望む成果を生み出したかどうかの評価へと。

それはまた、ソフトウェア開発スタックの中で戦略的価値がどこに蓄積されるかという私の見方さえも変える。過去 60 年間、実装