Just in Time Software の勃興

—— ソフトウェアは「所有」から「発生」へ。ファイルシステム回帰が示す次の 10年

エグゼクティブサマリー

AI が「API を呼び出す存在」から「環境そのものを操作する存在」へと変容しつつあります。Anthropic の Computer Use や OpenClaw、Claude Skills といった技術は、いずれも従来の Web API ではなく、シェルコマンドとファイルシステムという「OS のプリミティブ」に直接アクセスする設計を採用しています。これは偶然ではありません。

本レターでは、この動きが示す大きな構造変化——すなわち、事前に構築された静的なソフトウェアを「所有」する時代から、AI が実行時に動的にソフトウェアを生成・配備するJust in Time (JIT) Software の時代への移行について分析します。この変化は、インフラ戦略、セキュリティ設計、そしてコスト構造のすべてに影響を及ぼす可能性があります。

1. ニュースフック：分離から融合へ

2025 年後半以降、AI 業界で注目すべき動きが続いています。Anthropic は ComputerUse 機能を通じて、AI エージェントがデスクトップ環境を直接操作できる仕組みを提供し始めました。ほぼ同時期に登場した OpenClaw は、AI がブラウザを操作し、ファイルを書き換え、シェルコマンドを実行するオープンソースフレームワークです。さらに、Anthropic の cowork や Claude in Chrome といったプロダクトは、ユーザーのローカル環境に直接作用する設計思想を明確にしています。
興味深いのは、これらの製品がいずれも「きれいな API」を介さず、CLI やファイル操作というプリミティブな手段を選択している点です。従来の Web 開発が 10 年以上かけて追求してきた「ランタイムの隔離」と「疎結合なマイクロサービス」の設計原則とは、正反対の方向と言えます。

2. ファイルシステムへの先祖返りその必然性

Vercel 型ランタイムの限界
では、なぜこの「先祖返り」が起きているのでしょうか。背景には、現在主流のサーバーレスアーキテクチャの構造的な制約があります。

Vercel や AWS Lambda に代表されるステートレスなランタイム環境は、Web アプリケーションの配信には最適化されています。しかし、AI エージェントが必要とする作業——複雑な依存関係を持つライブラリの実行、中間ファイルの生成と参照、試行錯誤を伴う反復的な処理—— を支えるには根本的に不向きです。エージェントは「考えるための作業場」を必要としますが、関数が呼ばれるたびにリセットされるステートレス環境では、その作業場を維持できません。

CLI とローカルファイルの再評価
OpenClaw や Claude Skills が、抽象化された API レイヤーを排除し、OS のプリミティブに直接アクセスする設計を採用していることには、明確な合理性があります。ファイルシステムは、あらゆるプログラミング言語・ツール間で共通の「通貨」として機能します。中間生成物を自由に読み書きでき、プロセスを自在に起動・監視できる環境こそが、AI にとっての「自由度」に直結しているのです。

この文脈で「SaaS is Dead」という言説が改めて意味を持ちます。特定の UI/UX に固定された SaaS—— いわば「機能の箱」—— から、ユーザーのファイルシステム上で動的に生成される使い捨てのソフトウェアへ。これが Just in Time Software の本質です。ソフトウェアは事前に「購入」するものではなく、必要な瞬間に「発生」し、用が済めば消えていくものになります。

3. JIT Software を支える新たなインフラ層

Sandbox-as-a-Service の台頭
exe.dev や sprites.dev といったサービスが注目を集めています。これらは単なるホスティングサービスではなく、エージェントが「思考するための作業場」をオンデマンドで提供するインフラ—— いわば Sandbox-as-a-Service です。

ここにマルチテナントのジレンマが生じます。スケールを重視する従来のクラウド設計は、多数のユーザーが計算資源を共有することで効率を実現してきました。しかし、JIT Software が求めるのは「フル権限」と「永続性」—— つまり、各エージェントが独立した環境を専有し、自由にファイルを生成し、プロセスを管理できる状態です。これは従来のマルチテナントモデルとは根本的に相容れません。

ローカルとクラウドの境界線
cowork や Claude in Chrome に見られる「ローカルファイル志向」は、ユーザーの文脈（コンテキスト）を最も忠実に保持できるアプローチです。ユーザーのデスクトップにあるファイル、開いているタブ、進行中のプロジェクト—— これらの情報は、クラウド上の APIよりもローカル環境にこそ存在します。

一方で、AI が動的に生成したコードをローカルで実行することには、重大なセキュリティリスクが伴います。信頼できないコードが、ユーザーのファイルやネットワークに無制限にアクセスできる状態は許容できません。この矛盾を解決する手段として、「隔離されたマイクロ VM 」——Firecracker 等を用いたミリ秒単位で起動する軽量な仮想環境 ——が注目されています。

4. 技術的展望：マイクロ VM からエージェント FinOps へ

歴史的な類似性を指摘するならば、この動きは AWS の誕生期に似ています。2006 年、AWS は「必要なときに必要なだけ計算資源を使う」というパラダイムを提示し、IT 投資の構造を根本から変えました。JIT Software のインフラ層は、同じ変革を「エージェントの作業環境」というレベルで再現しようとしていると言えるでしょう。

しかし、ここで見落としてはならない課題があります。アンビエントエージェント——常時稼働してユーザーのタスクを監視・実行し続ける AI——が普及した際、LLM のトークンコスト以上に深刻になるのが、「待機・稼働し続けるコンテナや VM のリソースコスト」です。

現在の FinOps（クラウドコストの最適化管理）は、主に「クラウド破産を避ける」ための管理手法です。しかし、今後求められるのは、数百から数千のエージェントが個別に専有する計算資源をどう最適化するかという、エージェント・インフラの FinOps です。トークンの単価が注目される現在のコスト議論は、やがて「ランタイムの維持コスト」という別の次元に移行する可能性があります。

これは、Token Economics（LLM 推論のコスト経済学）から Runtime Economics（実行環境の維持コスト経済学）への関心移行と表現できるかもしれません。CxOの皆様にとって、この視点は中期的な IT 投資計画を検討する上で、重要な判断材料となり得ます。

5. 結論：意思決定者が考慮すべきこと

API で繋がれた静的なソフトウェアの世界から、ファイルシステムという原点に立ち返り、AI が動的に環境を構築する世界へ。この移行は始まったばかりですが、その速度は加速しています。

開発者の役割は「完成品を作る」ことから、「エージェントがソフトウェアを生成・実行するための健全な土壌（インフラ）を整える」ことへシフトしつつあります。これは開発組織のあり方だけでなく、ベンダー選定やセキュリティポリシー、コスト管理の基本前提にも影響を与えるでしょう。

最後に、意思決定者として検討いただきたい問いを三つ提示します。

第一に、自社のインフラは、AI エージェントが「作業場」を必要とする時代に対応できる
設計になっているでしょうか。ステートレスなサーバーレス基盤だけでは不十分になる可能
性があります。

第二に、AI が動的に生成するコードのセキュリティをどう担保するか。Sandbox-as-a-
Service の評価と導入計画は、早期に検討する価値があるでしょう。

第三に、エージェント時代のコスト構造をどう予測し、管理するか。トークンコストだけで
なく、ランタイムの維持コストを含めた総合的な FinOps 戦略の策定が求められます。

JIT Software の時代は、ソフトウェア産業にとっての大きな転換点となる可能性を秘めて
います。その波が自社にとって機会となるか脅威となるかは、今この時点での戦略的な準備
にかかっていると言えるでしょう。