OpenClaw vs LangChain：なぜフレームワークを使わないのか

Claw-Stackを見た人が最初に尋ねるのは：なぜLangChainを使わないのか？ということだ。これはPython AIエージェントの主要フレームワークで、巨大なエコシステムを持ち、自分で構築しなければならない多くの配管を処理してくれる。答えは「フレームワーク」の意味と、私たちが実際に必要としていたものに関係している。

OpenClawとは何か（そして何でないか）

OpenClawはnpmパッケージだ。インストールして設定すれば、Claudeにツールへのアクセス（ファイルシステム、シェル、MCPサーバー、メモリ）を提供するローカルプロセスとして実行される。フレームワークではなく、ランタイムだ。エージェントロジックをどのように整理すべきかは指示しない。ただツール呼び出しを実行してセッションを管理するだけだ。

これは意味のある区別だ。OpenClawはツールがどのように呼ばれるかについては意見を持つが、エージェントが何をするかについては意見を持たない。継承すべき基底クラスもなく、組み合わせるチェーンもなく、定義するグラフもない。エージェントの動作を説明するCLAUDE.mdファイルを書けば、OpenClawはそのコンテキストと登録したツールでClaudeセッションを実行する。

LangChainはその逆だ。エージェントロジックの構造化について強い意見を持っている：チェーン、ランナブル、エージェント、ツール、メモリ、リトリーバー。古典的な意味でのフレームワーク——骨格を提供し、あなたが詳細を埋める。骨格がユースケースに合うときは有用だ。合わないときは問題になる。

抽象化の問題

LangChainの抽象化は、LLM呼び出しをパイプラインで構成するという考えを中心に設計されている：入力→検索→LLM→出力→次のLLM呼び出し。これはRAGシステムと単純な質問応答エージェントにはうまく機能する。パイプラインモデルに合わないものが必要になると、衝突し始める。

例えば私たちのマルチエージェント会議プロトコルは、複数のClaudeインスタンスを構造化された議論の「参加者」として実行する。各参加者は会話履歴を読み、回答を生成し、オプションでコンセンサスを示すか次のラウンドを要求する。コーディネーターはその後、継続するかどうかを決定する。これはLangChainのエージェント/ツールモデルにきれいに収まらない。プロトコルをカスタムツールを持つエージェントに詰め込むか、LangChainの抽象化のほとんどを完全に迂回するかのどちらかになるだろう。

OpenClawでは、調整ロジックを自分で書くだけだ。コーディネーターエージェントは共有ファイルから現在の状態を読み込み、参加者エージェントをサブプロセスとして呼び出し、レスポンスを収集し、次に何をするかを決定するOpenClawセッションだ。JavaScript（Node.js ESモジュール）で書かれ、6つのソースファイルに分散している——コーディネーター、セッションマネージャー、サマライザー、コンセンサス検出器、タイムアウトハンドラー、議事録ライター——そのすべての行が私たちが理解していることをしている。

デバッグ体験

LangChainエージェントで何かがうまくいかないとき、エラーは抽象スタックの数層深いところにあることが多い。ランナブルをデバッグしていると、それがチェーンを呼び出し、チェーンがLLMを呼び出し、LLMが出力を返し、出力が出力パーサーによってパースされ……どこかで何かが失敗している。有用なスタックトレースを得るには、どの抽象レイヤーがどの動作を担当しているかを理解する必要がある。

OpenClawでは、確認する場所は基本的に2つしかない：ツール実装とClaudeセッションログ。エージェントが間違ったツールを呼び出したなら、セッション履歴を確認する。ツールが間違った出力を生成したなら、ツールを確認する。助けようとする中間レイヤーはない。

これは聞こえる以上に重要だ。私たちは何時間も続き、数十回のツール呼び出しを伴い、数百KBのコンテキストを蓄積するセッションを実行してきた。2時間目に何かがうまくいかなくなったとき、セッションログを読んで何が起きたかを正確に理解できることが望ましい。薄いランタイムでは、セッションログが何が起きたかの完全な記録だ。厚いフレームワークでは、フレームワークの内部状態が並行する事実の源となり、それも検査しなければならない。

ロックインとエコシステム依存

LangChainには500以上の統合パッケージがある。多くはコミュニティによって管理されており、ライブラリの更新で壊れる。LangChainの抽象化を中心にエージェントロジックを構築すると、それらすべてが維持され互換性があることへの依存を暗黙的に受け入れることになる。

OpenClawの統合モデルは異なる：統合はMCP（Model Context Protocol）を通じて行われる。MCPサーバーはツールを公開するプロセスにすぎない。新しいデータソース向けのMCPサーバーを書くのに約50行のコードが必要だ。インターフェースは標準的で、プロトコルはシンプルで、サードパーティの統合が壊れたとき、修正はそのサーバーに限定される——エージェントロジックを通じてカスケードしない。

これが、フレームワークコードなしにウェブ自動化レイヤー（26のChrome DevTools Protocolツール）、AIとテックコンテンツアグリゲーター、バックアップ統合を構築できた理由だ。それぞれが起動時にOpenClawにツールを登録する独立したMCPサーバーだ。

LangChainが意味をなす場合

これはLangChainに対する全面的な反論ではない。関連ドキュメントを検索し、LLMに渡し、答えを返すというRAGシステムを構築しているなら——LangChainの抽象化はそのパターンにうまくマッピングされる。LCEL（LangChain Expression Language）は検索パイプラインの構成に本当にクリーンだ。

ベクターデータベース、ドキュメントローダー、エンベディングモデルとの強力な統合も持っており、一から構築するには時間がかかる。素早くプロトタイプを作りたいチームや、既存のPythonアプリケーションに従来のAI機能を組み込むチームには、フレームワークのオーバーヘッドは統合のショートカットに値する。

私たちのユースケースは異なる。自律的に動作し、日々週々にわたって状態を蓄積し、複数のエージェントを複雑なタスクで調整し、問題が起きたときにデバッグできる必要があるAIエージェントシステムを構築している。そのために、見つけられる最も透明でミニマルなランタイムが必要だった。

原則：薄いランタイム、豊かなスキル

私たちのアーキテクチャは「薄いランタイム、豊かなスキル」として考え始めた原則に従っている。OpenClawがランタイムだ：ツールディスパッチ、セッション管理、Claudeへのインターフェースを処理する。他のすべて——メモリ、セキュリティ、マルチエージェント調整、ブラウザ自動化——は独立した、個別にデプロイ可能なモジュールに存在する。

これにより各スキルは独立してテストでき、他に触れることなく置き換えられ、システム全体を理解することなく推論できる。欠点はより多くの配線を書かなければならないことだ。利点は何かが壊れたとき、それはほとんど常に配線部分にある——それはあなたが書いて理解している部分だ。

このアプローチを普遍的に正しいものとして伝道しているわけではない。すべてのレベルでデバッグ、拡張、理解される必要がある研究プロジェクトには正しいトレードオフだ。締め切りに追われてプロダクト機能をリリースするなら、LangChainのフレームワークオーバーヘッドは価値があるかもしれない。私たちには、そうではなかった。