Some Other Thoughts on Clawbot

OpenClawの登場によって、agenticシステムの全体像がかなり明確になった。「エージェントはOSのようなものだ」という言い方はこれまで比喩の域を出なかったが、今ではより実質的な対応関係が見えるようになった。

大きく分けると二つの種類がある：

1. Run-centricのワークフローモード（n8n、Dify、ComfyUI）——従来の一連の処理を最初から最後まで実行する方式
2. Runtime-centricの常駐モード（OpenClaw）——常時オンラインの制御プレーン

どちらも従来のシステム設計では非常に成熟したパラダイムだが、agenticな文脈ではそれぞれ異なるアプリケーションシナリオを可能にする。

ワークフローは入力を受け取り、プロセスを実行し、出力を返すセッションである。典型的なユースケースはアプリのバックエンドとして、カスタマイズされたLLMの「専門」能力を提供すること。セッションはwebhookなどでトリガーできるが、セッション自体は常時オンラインにはなれない。

注意すべきは、この二つを区別するキーワードは「イベントドリブン」ではないということだ。n8nのワークフローはトリガーノードから起動し、Difyはトリガーをスケジュールまたは外部イベントとして定義し、ComfyUIはワークフローを実行キューに投入してWebSocketで状態をプッシュする——すべてイベントで起動できる。run-centricとruntime-centricを本当に区別するのは三つの要素だ：

OpenClawがより24時間オンラインのパーソナルアシスタント「らしく」感じられるのは、まさに無限ループのruntimeレイヤーが空母のように連続的かつほぼ同時に複数のセッションタスクをlaunch/回収しながら、自身は永遠にオンラインでいられるからだ。ここで重要なのは、「空母」のエンジンは24時間トークンを燃やし続けるLLMではなく、従来のソフトウェアエンジニアリングの意味でのdeterministicなループだということだ。OpenClawのGatewayはまさにそのようなalways-onプロセスであり、セッション状態はgateway hostが保持し、cron、hooks、webhooksが組み込まれ、runは各セッションレーン内でシリアルに実行されるが、セッション間では並行実行できる。

ワークフロー型のアプリケーションが重視するのは結果の予測可能性であり、固定のステップで固定の結果を出す。LLM以外のシステムでは主にデータ処理、企業プロセス、金融・政府の承認シナリオで使われている。一方、runtime-centricのアプリケーションはマイクロサービスアーキテクチャに近く、与えられたイベントに対して反射的に反応するシステムの能力を重視する——IoTの条件トリガー、高頻度取引のリアルタイムデータストリーム分析、SNSのアップロード・処理・公開パイプラインなど。

OpenClawはruntime-centricエージェントの最初の事例ではない——LangGraphはdurable executionとlong-running stateful agentsを主力とし、Lettaはstateful agentsを主力とし、AutoGenはagent runtimeをインフラストラクチャの概念として位置づけている——しかし、runtime-centricエージェントが初めて真にエンドユーザーに届いたと言える（以前は開発者しかアクセスできないインフラレイヤーにとどまっていた）。パーソナルアシスタントとしてのOpenClawは、runtime-centricエージェントパラダイムの大規模浸透の始まりに過ぎないだろう。

この構図は計算産業の初期の歴史と驚くほど似ている。IBMメインフレーム時代はエンタープライズ優先だった：強力で、集中的で、タイムシェアリング方式で、IT部門が管理していた。PC革命は企業を迂回し、個人に直接向かうことで突破した——まずギーク（Altair、Apple II）、次に消費者（Macintosh、Windows）。現在のほとんどのエージェントスタートアップはB2B SaaSの道を歩んでいる——LangChain、CrewAI、AutoGenはエンジニアリングチームと企業顧客を対象とし、明確な収益、定義されたユースケース、容易なGTM——構造的にはメインフレームのパターンだ。OpenClawが個人ユーザーに直接向かうのはPCの突破により近い。

B2B SaaSのエージェント企業はもちろん価値あるビジネスを構築できる——SaaSモデルはデータとワークフローのロックインによって高いリテンション率を実現する。しかしクラウド時代の経験が示すのは、利益とボトルネック標準は別物だということだ。IaaS（AWS、Azure、GCP）は資本密度で寡占を築いた——営業利益率約35%、堀は「建設できない」。SaaS（Salesforce、Workday）はデータロックインで高いリテンションを得たが、垂直領域に限定される。PaaS（Docker、Kubernetes、Heroku）は巨大な影響力を持ちながらマネタイズに苦戦し、オープンスタンダードへ向かった。三層すべてが利益を上げたが、Windowsの市場権力を再現した層はない——これは偶然ではない。IaaSとPaaSはインフラビジネスであり、顧客が一人増えるごとに実際のコストがかかる——ソフトウェアのコピーがほぼ無料のWindowsとは違う。SaaSは限界費用こそ低いが、垂直領域しかロックインできず、Windowsのようなすべてのアプリケーションを横断する水平ロックインは実現できない。オープンソース標準の台頭が単一APIロックインの形成を阻み、OEMプリインストールのようなチャネルもない。Windowsのボトルネック標準は複数の条件が同時に成立する必要があった——クラウドでは各層がそれぞれ異なるピースを欠いている。IBMはメインフレームで利益を上げ、AWSはIaaSでさらに多くの利益を上げた——実際、AWSはOS使用料だけでなくインフラスタック全体を販売しており、カバー範囲が広く、絶対的な利益も大きい。ボトルネック標準がなくても良いビジネスは成立する。特にアドレス可能な市場が十分に大きい場合は。しかしボトルネック標準レベルの市場権力——収益あたりの利益率が最も高く、ロックインが最も深く、最も置き換えが困難な——は歴史的にパーソナルコンピューティングのソフトウェア層でしか現れていない：マイクロソフトとインテルだ。現在のB2B SaaSエージェント企業はエンタープライズ契約とリテンションを獲得できるが、ボトルネック標準には程遠い。OpenClawが開発者向けruntimeにとどまるなら、PaaSの道を辿ることになる——歴史的にマネタイズが最も困難な層だ。しかし一般ユーザーにとってのOpenClawは抽象的なruntimeの概念ではなく、具体的な個人agenticエントリーポイント——すべてのエージェント、ツール、サービスとの間のデフォルトインターフェースだ。前者はDocker、後者はWindows。エージェント時代の決定的な分岐点はまさにここにある：開発者インフラの一部になるか、すべての人のデフォルトのagentic OSになるか。

商業的な観点から考えると、OpenClawがパーソナルコンピュータ時代のマイクロソフトに相当するかどうかが問われる。

しかしより正確な類比はWindowsではなく、DockerやNode.jsかもしれない——消費者向けOSプラットフォームではなく、開発者向けruntimeだ。つまり近期の主戦場は消費者への浸透ではなく、開発者の採用である。ただしこれは類比の価値を損なわない——DockerもNode.jsも、まず開発者を獲得することで各自のエコシステムを再編したのだから。

GitHubでリポジトリをクローンできるギークは少数派だ。OpenClawの30万GitHubスターは、グローバルなスマートフォン普及率と比べれば誤差の範囲だ。エンタープライズSaaSユーザーはウェブ操作に慣れているが、膨大なC端ユーザーの筋肉記憶はプリインストールや中央集権的なストアからのワンクリックインストールにある。

パッケージングがスマートフォンのように一般消費者に浸透できるほど成熟した後、プラットフォーム化——App Storeのようなアプリケーションストア（Clawhub）を構築し、他のアプリケーションやサービスをOpenClawのようなruntime上で動作させること——は自然な次のステップだ。

しかし、パーソナルコンピューティングの利益と権力は、歴史的に「マシン全体の価値」に比例して分配されたことはない。それはボトルネック標準に集中する。マイクロソフトが異常に高い利益を得たのは、最も多くのことをしたからではなく、五つの条件を同時に押さえたからだ：ボトルネック標準（Windows APIは開発者が必ず向き合うインターフェース）、間接ネットワーク効果（ユーザーはアプリの多いプラットフォームを、開発者はユーザーの多いプラットフォームを求める）、限界費用ほぼゼロ（ソフトウェア複製コストはゼロに近い）、後方互換ロックイン（一度書いたアプリは書き直したくない）、補完財の連動マネタイゼーション（OfficeはWindows上で動き、WindowsはOEMハードウェアにプリインストールされる）。米国政府は反トラスト訴訟でこのメカニズムを明確に分解した：Windowsの独占力は市場シェアだけでなく、applications barrier to entryに依存していた——Windows APIのクローンは高コストでほぼ追いつけない。「開発者が誰に向けてアプリを書くか、OEMが何をプリインストールするか、ユーザーがデフォルトで何に触れるか」——この三つのインターフェースを支配する者が、PC時代で最も厚いレントレイヤーを手に入れた。

したがって問題は、OpenClawがプラットフォームになれるかどうかではなく、エージェント時代のボトルネック標準を支配できるかどうかだ。

エージェント時代の技術スタックは大まかに：モデル → ツールインターフェース → エージェントruntime → アプリケーション。ボトルネックはどの層にも落ちうる：モデル層（OpenAI/AnthropicのAPI）、ツールエコシステム（プラグイン、API標準、エージェントプロトコル）、アイデンティティと権限層（エージェントは自律的に行動するため、認可を制御する者が行動の境界を制御する）、あるいはruntime自体。OpenClawはruntimeの層に位置している。ボトルネック標準を獲得できるかどうかは、開発者がエージェントを構築する際にどの層を最も乗り換えたがらないかにかかっている——その層がボトルネック標準となる。

プラットフォーム化を分解すると、実は四つのレイヤーがある：

プラグインインターフェース——他者がどう接続するか。プラグインのパッケージング、マニフェストの形式、登録可能なツール、スキーマの定義。OpenClawにはすでに雛形がある。

権限モデル——接続後に何ができるか。エージェントはボタンクリックを待つのではなく、権限付与後に自律的にツールを呼び出すため、従来のアプリより権限が重要になる。OpenClawのGatewayプロトコルにはすでにoperator scopes、node caps、グローバルなallow/denyがある。

ディスカバリー層——ユーザーがどう見つけてインストールするか。ClawHubは基本的にこれだ。

決済層——エコシステムでお金がどう流れるか。ディスカバリーだけならnpm、両方握って初めてApp Storeに近づく。ClawHubは現在free public registryであり、決済層はまだプロダクト化されていない。

一言にまとめると：プラグインインターフェースだけならフレームワーク、権限を加えればruntime、ディスカバリー層を加えればエコシステム、決済層を加えて初めてプラットフォームらしくなる。

この四つのレイヤーは理論的な抽象ではない——パーソナルコンピューティングの歴史にすでに完全なケーススタディがある。初期のWindowsはオープンだった：プログラムはファイルシステム、レジストリ、ネットワーク、他のプロセスに直接アクセスできた。その代償はマルウェアの蔓延、システムの不安定さ、ドライバの競合だった。iOSはこのモデルを反転させた：app → サンドボックス → 承認済みAPI → システムリソース——セキュリティ、安定性、予測可能性をもたらしたが、同時に高度に管理されたエコシステムでもある。

iOSのアーキテクチャはこの四つのレイヤーにそのまま対応する：

Appleは十年かけてこの四層をゼロから完成させた。もしagent runtimeが同じ道を辿るなら——オープンなフレームワークから管理されたプラットフォームへ——この四層の完成度こそが、GitHubのスター数ではなく、誰がボトルネック標準に最も近いかを測る真の指標となる。

OpenClawは今、runtime + discoveryに到達しているが、platform captureにはまだ至っていない。スターは注目であって、install baseではない。ましてや当時のWindowsのようなOEMプリインストール権でもない。デスクトップOS（Windows約67%）、モバイルOS（Android約68%、iOS約32%）、ブラウザ（Chrome約69%）の現在のシェア構造自体が、新しいruntimeがデフォルトの地位を奪うことの難しさを示している。

かつてマイクロソフトが占めたパーソナルコンピュータOSとインテルが占めたCPU設計・製造は、PC時代で最も利益率の高いエコロジカルニッチだった。OpenClawがそのような位置を占めるかどうかは、runtimeプロバイダーからボトルネック標準の支配者へと進化できるかにかかっている——エージェントを動かすだけでなく、すべての人がそれに向けてエージェントを作らなければならない状態にすることだ。