パイプライン死す＝アイリス・テン・タイジェ氏、スカイバレー型環境コンピューティング

「凍結されたアーティファクト」の終焉：生成 AI がもたらす「環境コンピューティング」への転換点

ソフトウェア開発の歴史は、長らく「一度作り上げれば全員に同じものを配布する」というモデルの上に成り立ってきました。しかし、生成 AI の登場によりコード作成コストが激減した今、この数十年続く常識が崩れ始めています。

Differ 共同創設者のアイリス・テン・タイジェ氏は、従来の CI/CD パイプラインや「凍結されたアーティファクト」モデルが時代遅れであると断じ、開発と配布の境界線が消滅する新しいパラダイムを提案しています。本稿では、なぜ旧来のモデルが限界を迎えたのか、そして AI エージェントがユーザーごとにリアルタイムで最適化される「環境コンピューティング」の世界とは何かを解説します。

高コスト時代が作った「凍結されたアーティファクト」の呪縛

私たちが当たり前のように使っている CI パイプライン、パッケージャ、コンテナイメージといったインフラは、すべて一つの古い前提に基づいて設計されています。それは「ソフトウェアは一度だけ作り、全ユーザーに同じものを配布する」という発想です。

なぜこのモデルが長年支配的だったのでしょうか？答えは単純な経済性にあります。

ソフトウェアの生産には熟練した人間が数時間から数日かける必要があり、コストが高すぎました。そのため、変更は稀に行う中心的なイベントとし、検証して「凍結」し、その凍結されたものを全員に配布するしかなかったのです。

このモデルには再現性やロールバックの保証といった明確な利点がありました。しかし、代償として「ユーザーごとに異なるソフトウェアを提供する」という選択肢自体が排除されてしまいました。

誰も会議を開いて「個人用バージョン」を選んだわけではありません。ただ、コストの問題から「全員用バージョン」しか存在しなかったのです。私たちはこれを重力のような事実だと勘違いしていました。

実はこれはソフトウェアの物理法則ではなく、単なる経済的制約でした。AI の登場でコード作成のコストがほぼゼロに近づいた今、この前提はもはや成立しません。

開発と配布の境界線が消える「環境コンピューティング」

生成 AI がもたらした最大のインパクトは、「ソフトウェアを作るコスト」と「実行するコスト」が同等になったことです。以前は「作るのに高価で、実行するのは安価」だったため、両者を分離する必要がありました。

しかし今や、変更を加えることが実行するのと同じくらい安価になり、同じ場所（ユーザーの端末やライブセッション内）で行えるようになりました。この変化により、開発と配布はもともと別々の工程ではなくなります。

アイリス氏はこれを「環境コンピューティング」と呼びます。ここでは、AI エージェントがユーザーの行動や文脈をリアルタイムで理解し、ソフトウェア自体を適応させます。

境界線が曖昧になり、消滅します。開発者が一度作り上げたものを、ユーザーごとに最適化された個別バージョンとして、実行中に動的に生成するのです。

これは「一つサイズが全てに合う」モデルからの脱却です。Excel が数百万人のユーザーによって独自のスプレッドシートを構築し、最も成功したビジネスソフトウェアになったように、「ユーザー自身にソフトウェアを作る力を与える」ことが真のパーソナライゼーションへの鍵となります。

安全な個別適応：ステムとダイバージェンスのアーキテクチャ

「AI が勝手にコードを書き換えたら、システムが壊れるのではないか？」という懸念はもっともです。実際、多くの CTO は「AI が生成したコードベース一つを把握するだけで精一杯なのに、数百万ものバージョンを管理できるはずがない」と危惧します。

しかし、Differ の提案するアーキテクチャでは、この脆さを防ぐための仕組みが組み込まれています。重要なのは、「境界線のない絡み合ったアーティファクト」ではなく、「隔離された分岐」を採用することです。

1. ステム（Stem）: 全ユーザーに共通する正統なコードベース。ここには絶対的なルールやコア機能が定義されます。
2. ダイバージェンス（Divergence）: ユーザーごとに AI が生成する個別の適応版。これはステムから分岐しますが、境界があり、他者への影響を遮断されるように設計されています。

不良なバリアントがステムを破損したり、他のユーザーに悪影響を及ぼすことはありません。各バージョンは独立しており、問題があれば瞬時に元に戻せます。

開発者は、どの部分が適応可能で、どの部分（例：決済機能やセキュリティ設定）が絶対に変更不可かを定義できます。例えば CRM システムであれば、営業担当者が頻繁にスキップするフィールドを特定の投資家向けに非表示にするといった調整は、システムが自律的に行いますが、コア機能の改変は開発者の許可なしには行われません。

新たな技術的課題：生成から「観測性」と「調整」へ

コードを生成すること自体は、AI の進化によりすでに容易になっています。しかし、真の難所は「生成されたコードが正しいか」「望ましい変更かどうか」「どのように追跡・管理するか」という点にあります。

従来のバージョン管理（Git）では「コミット履歴」を追いましたが、環境コンピューティング時代には「系譜（プロベナンス）」と「意図の統合」が問われます。

1. 真実のソースと追跡可能性

ユーザーが実行しているプログラムは、単なるバージョン番号ではなく、グラフクエリとして扱われるようになります。バグレポートでは、「なぜこのユーザーにこのコードが適用されたのか」を特定する必要があります。

すべての分岐が不変で、検査可能であり、どの適応がどのシグナル（ユーザーの行動データなど）に基づいて行われたかを追跡できる基盤が必要です。

2. 正しさと望ましさの検証

コードが動作することは「正しい」ことですが、それが「望ましい」かどうかは別問題です。AI が生成した変更が、実際のビジネス指標（リテンション向上やサポートチケット削減など）に寄与しているかを測定する仕組みが不可欠です。

コードの一部を生成することは誰でもできます。しかし、その変化が本当に改善をもたらしたかを確認し、意図を統合する観測性と調整機能こそが、これからのビジネスの核心となります。

3. 自律性 vs 制御

最終的な目標は、開発者が毎回手動で承認する必要がないほどシステムを信頼できる状態にすることです。これは「制御を増やす」ことではなく、「不要になるほど信頼を得る」という逆転発想です。

新しいアップデートはコードそのものをマージするのではなく、「意図」や「結果」をマージします。全員が同じコミットを実行する必要はなく、各自の道を通って同じ目標に収束すればよいのです。

結論：20 年かけて熟練した「個別最適化」への移行

かつて支店のない銀行は無謀だと笑われましたが、今や支店こそが奇妙な存在です。同様に、「高コストゆえに一度凍結して配布する」というパイプラインモデルは、その前提条件が消えたことで機能しなくなったのです。

これからの 20 年は、開発者が「全員向けに一つのバージョン」をリリースすることに熟練してきた時代から、「誰にでも最適なバージョンを、隔離性と出所が保証された形で提供」する時代へと移行します。

これは恐怖すべき変化ではなく、ソフトウェアの可能性を根本から解放する、最も良い出来事の一つです。