2026年2月16日、OpenClawの創設者であるSteinbergerがOpenAIへの移籍を発表した。LinkedInの投稿は短く事務的だった：「新しい挑戦を求めてOpenAIのエージェントチームに参加する。OpenClawはOpenClaw Foundationに移管される。」
反応は即座に分かれた。OpenClawのDiscordサーバーでは祝福と不安が入り混じった。GitHubのissueトラッカーには「プロジェクトの将来について」というタイトルのissueが立ち上がり、数時間で200以上のコメントがついた。OpenClawのスター数は発表後24時間でわずかに減少した——象徴的だが、25万スターの規模では微々たるものだ。
しかし、より深い問題はスター数の変動ではなかった。OpenClawのアーキテクチャに関する知識、ロードマップのビジョン、コミュニティとの信頼関係——これらが一人の人物に集中していた事実が、初めて正面から議論されたのだ。
バスファクターとは何か
ソフトウェアエンジニアリングにおける「バスファクター」は、プロジェクトが機能不全に陥るために何人がバスに轢かれる（プロジェクトを離脱する）必要があるかを示す指標だ。バスファクターが1のプロジェクトは、一人の離脱でプロジェクトの継続が危ぶまれる。
OpenClawのバスファクターは、事実上1だった。
Steinbergerはプロジェクトの唯一の初期設計者であり、主要なアーキテクチャ判断の大部分を一人で行っていた。コードベースの中核部分——エージェントランタイム、スキルシステム、WhatsApp統合——は彼が書いたものだ。130人以上のコントリビューターが存在したが、その多くはバグ修正、ドキュメント、周辺機能の貢献だった。
さらに重要なのは、暗黙知の集中だ。なぜ特定の設計判断が行われたか、どのPRを優先すべきか、どの方向にプロジェクトを進化させるべきか——これらの知識は文書化されておらず、Steinbergerの頭の中にしかなかった。
OpenClaw Foundationへの移管
Steinbergerは離脱にあたり、OpenClawをOpenClaw Foundationに移管すると発表した。Foundationは複数の企業と個人コントリビューターで構成され、プロジェクトのガバナンスを分散化することを目指していた。
移管計画は表面上は合理的だった。複数のメンテナーにコミット権限を付与し、アーキテクチャ判断をRFCプロセスで民主化し、ロードマップを公開討議で決定する。しかし、計画と実行の間には常にギャップがある。
最初の問題はスピードだ。OpenClawのリリースサイクルはSteinbergerの判断で駆動されていた。彼がPRをレビューし、マージし、リリースノートを書き、デプロイを承認していた。Foundation体制への移行は、新しい意思決定プロセスの確立を意味する。これには時間がかかる。移行期間中、OpenClawの開発ペースは不可避的に低下する。
第二の問題は方向性だ。Steinbergerはプロジェクトの方向性について明確なビジョンを持っていた。そのビジョンが正しかったかどうかは別として、方向性の一貫性がプロジェクトの急成長を支えていた。Foundation体制では、複数のステークホルダーの意見を調整する必要がある。コンセンサスベースの意思決定は安定性を高めるが、スピードと大胆さを犠牲にする。
第三の問題は技術的負債だ。バスファクター1のプロジェクトには、文書化されていない設計判断、暗黙の慣行、一人の人物の頭の中にしかない「なぜこうなっているか」の知識が蓄積されている。新しいメンテナーがこれらを理解するには時間がかかり、理解する前に行った変更が既存の設計判断と矛盾するリスクがある。
競合他社への移籍の意味
SteinbergerがOpenAIに移籍したことには、単なる人材流出以上の意味がある。
OpenAIはAnthropicの直接的な競合だ。OpenClawはClaude（Anthropic製品）を使用するプロジェクトだ。プロジェクトの創設者がAnthropicの競合他社に移籍するということは、今後OpenClawの方向性がClaude中心から離れる可能性があることを示唆する。Steinberger自身はFoundationに直接関与しないとしているが、彼の影響力は完全にはなくならない。
コミュニティの一部は、この移籍をOpenClawがマルチプロバイダー対応に舵を切る兆候と解釈した。OpenAI出身の技術的影響力が間接的にFoundationに及べば、GPTモデルのサポートが優先される可能性がある。これはClaudeユーザーにとって必ずしも悪い話ではないが、プロジェクトの焦点が拡散するリスクはある。
NanoClawとバスファクター
NanoClawはバスファクター問題に対して構造的に異なるポジションにある。
まず、NanoClawのコードベースは500行だ。新しいメンテナーが全てのコードを理解するのに必要な時間は数時間だ。何万行ものコードベースを理解するのに数ヶ月かかるOpenClawとは桁違いの差がある。
次に、NanoClawの設計判断はほぼ自明だ。「WhatsAppメッセージを受け取る」「コンテナを起動する」「Claude Agent SDKを呼ぶ」「レスポンスを返す」——これらの判断には深い暗黙知が必要ない。コードを読めば設計意図が理解できる。ドキュメントがなくてもコードが自己文書化されている。
さらに、NanoClawの複雑さの大部分はNanoClawの外に存在する。Claude Agent SDK、Docker/Apple Container、Baileys、SQLite——これらのコンポーネントはそれぞれ独自のメンテナーコミュニティを持っている。NanoClawのメンテナーが全員離脱しても、これらのコンポーネントは独立して機能し続ける。NanoClawのオーケストレーション層を再構築することは、500行のコードを理解し書き直すだけの問題だ。
フォーク可能性
オープンソースプロジェクトの持続可能性を測る別の指標は「フォーク可能性」——プロジェクトがフォークされて独立して発展できる容易さ——だ。
OpenClawのフォーク可能性は低い。コードベースが大きく、複雑で、暗黙知に依存している。フォークしても、フォーク先でプロジェクトを有効に保守できるチームを組織するのは困難だ。実際、OpenClawの改名時にいくつかのフォークが試みられたが、大半は短期間で活動を停止した。
NanoClawのフォーク可能性は極めて高い。500行のコードは一人の開発者が完全に理解でき、修正でき、自分のニーズに適合させることができる。仮にNanoClawのメインリポジトリが放棄されても、フォークして独立に保守することは容易だ。
プロジェクトの持続可能性
Steinbergerの移籍が提起した本当の問題は、「特定の個人に依存しないプロジェクトをどう設計するか」だ。
答えの一つはガバナンスの分散化だ——OpenClaw Foundationが目指していること。しかし、ガバナンスの分散化は組織的な解決策であり、技術的な問題には技術的な解決策が必要だ。
NanoClawの答えは技術的だ：コードベースを小さく保ち、複雑さを外部コンポーネントに委ね、設計判断を自明にする。500行のコードに対してFoundationを設立する必要はない。コードを読めば全てが理解でき、変更が必要なら変更でき、不要なら捨てて書き直せる。
これはNanoClawの規模だから可能なのであり、OpenClawの規模では不可能だという反論は正当だ。しかし、それ自体がNanoClawのアーキテクチャ判断——「小さく保つ」——の価値を裏付けている。小さいことは制限ではなく、持続可能性の源泉だ。
OpenClawの今後がどうなるかは時間が教えてくれるだろう。OpenClaw Foundationが成功し、プロジェクトが新しいリーダーシップの下で発展する可能性は十分にある。しかし、Steinbergerの移籍が露呈した脆弱性——バスファクター1、暗黙知の集中、ガバナンスの不在——は、大規模オープンソースプロジェクトが直面する構造的な課題だ。
NanoClawはこれらの課題を規模の小ささで回避した。エレガントとは言い難いが、効果的だ。