OpenClaw は 2026年に最も注目されている AI エージェントフレームワークです。GitHub スター数は 32 万超で React を抜いてソフトウェアプロジェクトとして最多を記録し、Nvidia が「エージェント AI にとって、GPT がチャットボットにとってそうであったもの」と評するほどの存在感を持っています。本記事では、OpenClaw とは何か、何ができるのか、そしてどこが単なるチャットボットと異なるのかを解説します。

OpenClaw の沿革

OpenClaw の歴史は、名前の変遷そのものです:

  1. Clawdbot（2025年11月）: オーストリアの開発者 Peter Steinberger が公開。Anthropic のチャットボット Claude にちなんだ命名
  2. Moltbot（2026年1月27日）: Anthropic からの商標に関する指摘を受けてリブランド。ロブスターの「脱皮（molt）」にちなむ
  3. OpenClaw（2026年1月30日）: わずか 3 日後に再リブランド。「Open（オープンソース・コミュニティ駆動）」+「Claw（ロブスターの遺産）」

3 度の名前変更を経ても、コードベースは一貫して同じです。既存のインストールは自動的にマイグレーションされています。

名前は変わっても、プロジェクト全体を貫くモチーフは一貫して ロブスター（lobster） です。最初のアシスタント名「Clawd」が Claude のもじりで、そこからロブスターのハサミ（claw）に繋がり、プロジェクト全体のアイデンティティになりました。タグラインは「The lobster way 🦞」、マスコットは宇宙ロブスターの「Molty」です。エコシステム内の各コンポーネントもこのテーマに沿って命名されています:

コンポーネント名前の由来
OpenClawOpen + Claw（ハサミ）
Molty（マスコット）Molt（脱皮）するロブスター
ClawHub（スキルレジストリ）Claw + Hub
Lobster（ワークフローシェル）そのままロブスター

なお、Steinberger は 2026年2月14日に OpenAI への参加を発表し、プロジェクトはオープンソース財団に移管されました。Meta の Mark Zuckerberg からも直接オファーがあったものの、「ビジョンをスケールさせるために最新の技術にアクセスしたい」として OpenAI を選んだとのことです。

OpenClaw とは何か

公式の説明は「自分のデバイスで動かすパーソナル AI アシスタント」ですが、その実態は AI を中核に据えたプログラム可能なワークフローエンジン です。

最大の特徴は、チャットボットのように「ユーザーの入力を待って応答する」だけではなく、常駐デーモンとして自律的に動作する点にあります。

アーキテクチャ: Gateway が全てを統合する

OpenClaw の中核は Gateway と呼ばれる常駐デーモンプロセスです。

OpenClaw Gateway Architecture

Gateway はローカルの WebSocket サーバー（ws://127.0.0.1:18789）として動作し、以下を統合管理します:

  • 22 以上のメッセージングチャネル: WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Google Chat、Microsoft Teams 等
  • 3 層のイベントソース: ユーザー入力だけでなく、時刻やシステムイベントにも反応
  • ローカル実行環境: シェル、ブラウザ、ファイル操作、API 呼び出し

3 層のイベントソース

OpenClaw が「チャットボットではなくエージェント」と呼ばれる理由は、入力ソースの多様さにあります:

イベントソース特性例
Heartbeat定期的な状態判断。何もなければ沈黙する「受信トレイに重要なメールが来ていないか確認」
Cron時刻トリガー。指定時刻に必ず実行「毎朝 7:30 にブリーフィングを生成」
Webhooks外部イベントトリガー「GitHub push をトリガーにコードレビュー」

Heartbeat は「定期的に状態を確認し、判断を適用し、何も問題がなければ沈黙する」という仕組みです。Cron が「必ず実行する」のに対し、Heartbeat は「必要と判断した場合のみ行動する」という点が異なります。

Gateway は Orchestrator ではない

「Gateway」という名前を聞くと「実質的に Orchestrator では？」と思うかもしれません。しかし、両者の役割は明確に異なります:

GatewayOrchestrator
主な役割外部からの入力を正規化し、内部に中継する複数のタスク/サービスの実行順序を制御する
判断「どこから来たか」を識別してルーティング「何をすべきか」を判断して指揮
例え受付窓口（どの窓口に来ても同じ担当に繋ぐ）指揮者（誰がいつ何を演奏するか決める）

OpenClaw では、この 2 つの役割が二層構造で分離されています:

  • Gateway: 22+ チャネルからの入力を正規化し、セッション管理・フレーム検証を行い、Agent Runtime に渡す（受付・中継層）
  • Agent Runtime: LLM 推論、ツール実行、スキル選択、Lobster ワークフローの制御（こちらが Orchestrator）

ただし、Heartbeat や Cron のトリガー判断を Gateway 側が持っている点では、単純な API Gateway よりも「賢い」です。「Control Plane（制御盤）」という表現が実態に最も近いかもしれません。

Gateway → Agent Runtime → 実行エンジンの流れ

「Gateway がメッセージの条件ごとに Lobster YAML をマッピングして AI エージェントに渡しているのか？」と考えたくなりますが、実態はもう少し複雑です。Gateway は入力を正規化して Agent Runtime に渡すだけで、何をすべきかを判断するのは Agent Runtime（LLM） です。

[チャネル入力] → [Gateway] → [Agent Runtime (LLM)] → どうする？
                                    │
                          ┌─────────┼──────────┐
                          ▼         ▼          ▼
                     会話応答   スキル実行   Lobster
                    (大半はこれ)            ワークフロー

入力の種類に応じた処理の分岐:

入力の種類処理
「今日の天気は？」LLM が直接応答（Lobster 不要）
「メールをトリアージして」LLM がスキルを選択して実行
Cron: 毎朝 7:30事前に定義された Lobster ワークフローが起動
Webhook: GitHub push事前に定義された Lobster ワークフローが起動

大半のやりとりは LLM の直接応答やスキル実行で処理されます。Lobster が活躍するのは「承認が必要な多段処理」や「定期実行される定型ワークフロー」に限られます。Lobster はあくまで Agent Runtime から呼び出される 実行エンジンの一つ であり、全ての処理が Lobster を経由するわけではありません。

OpenClaw の処理を 3 ステップで理解する

全体をまとめると、OpenClaw のシステムは以下の 3 ステップで動作しています:

  1. イベント発生 → Gateway が正規化: チャネルメッセージ / Heartbeat / Cron / Webhook など、どこから来た入力でも統一フォーマットに変換して Agent Runtime に渡す
  2. Agent Runtime（LLM）が判断: 「会話応答 / スキル実行 / Lobster ワークフロー起動」のどれが適切かを決める
  3. Agent Runtime（LLM）が実行: 自らツールを呼び出し、スキルを実行し、必要に応じて Lobster ワークフローを起動してタスクを遂行する
[イベント] → [Gateway (正規化)] → [Agent Runtime (LLM: 判断+実行)]
                                         │
                                   ツール呼び出し
                                   スキル実行
                                   Lobster 起動
                                   会話応答

ここで重要なのは、判断と実行を行うのは同じ Agent Runtime（LLM） であるということです。「別の LLM に指示を出す」のではなく、判断した LLM 自身がツール呼び出しやスキル実行を行います。Gateway は「賢い受付」であり、Agent Runtime が「考えて動く担当者」です。指示を出す人と実行する人が分かれているのではなく、Agent Runtime が自分で考えて自分で動く という構造です。

人格と記憶: Markdown で定義される「自己」

OpenClaw のエージェント人格は、~/.openclaw/ ディレクトリ内の Markdown ファイル群で定義されます:

ファイル役割
SOUL.md人格の核。コミュニケーションスタイル、価値観、長期指示
USER.mdユーザー情報（名前、タイムゾーン、仕事の文脈）
MEMORY.md長期記憶。エージェントが学習した情報のキュレーション
memory/YYYY-MM-DD.md日記。毎日の対話から学んだことを自動記録

SOUL.md: エージェントの「憲法」

特に重要なのが SOUL.md で、毎回の推論サイクルの開始時に読み込まれ、一貫した動作を保証します。500 行以下に保つことが推奨されています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

## 人格
- 専門的だが親しみやすい
- 箇条書きを優先
- 技術概念説明時は具体例を 1 つ含める

## 核となる価値観
- ユーザープライバシーを最優先
- 財務影響のある行動前に確認
- すべての事実について引用元を示す

## 長期指示
- 朝のブリーフは最大 5 ポイント
- メール要約時はアクション項目から開始

記憶の蓄積プロセス

エージェントは毎日の終わりに memory/YYYY-MM-DD.md に日記を書きます。重要な情報は MEMORY.md にキュレーションされ、長期記憶として蓄積されます。使い込むほどユーザーの好みや文脈を深く理解するエージェントに成長していきます。

スキルシステム

OpenClaw の機能拡張は スキル によって行われます。各スキルは SKILL.md ファイルを含むフォルダで定義されます。

スキルの読み込み優先度

優先度場所説明
高<workspace>/skillsエージェント固有スキル
中~/.openclaw/skillsマシン全体で共有
低バンドルスキルインストール時に付属

ClawHub: スキルの共有レジストリ

公式レジストリ ClawHub（clawhub.com）には 13,000 以上のコミュニティ製スキルが登録されています:

1
2

clawhub install <skill-slug>   # スキルのインストール
clawhub update --all           # 全スキルの更新

代表的なスキルの例:

  • agent-team-orchestration: マルチエージェントチームのオーケストレーション
  • image-lab: Gemini API を活用した画像生成・編集
  • Composio 連携: 860 以上の外部ツール（GitHub、Slack、Gmail 等）へのアクセス

Lobster: 型付きワークフローランタイム

Lobster は OpenClaw のオプションプラグインで、スキルやツールを組み合わせた多段パイプラインを 1 回のツール呼び出しで決定論的に実行する ワークフローランタイムです。Unix のシェルパイプライン（cmd1 | cmd2 | cmd3）に似ていますが、AI エージェント向けに設計されています。

本質的に言えば、Lobster の YAML は AI エージェントに対して何を行ってもらうかを指示する DSL（ドメイン固有言語） です。自然言語プロンプトとの違いを整理すると:

自然言語プロンプトLobster YAML
実行順序LLM が解釈して判断YAML で明示的に定義
再現性毎回微妙に違う結果になりうる同じ定義なら同じ順序で実行
承認ゲート「確認してね」と書いても守る保証なしランタイムが強制的に停止
エラー処理LLM 任せcondition で明示的に分岐

Claude Code の世界に例えるなら、CLAUDE.md が「人格・方針の指示」、Lobster YAML が「具体的な作業手順の指示」 という関係です。プロンプトで曖昧に指示していたことを、決定論的に記述するための仕組みと言えます。

ワークフローの YAML は ユーザーが手書きすることも、自動生成させることも できます。手書きの場合は .lobster ファイルに直接記述し、lobster run workflow.lobster で実行します。自動生成の場合は ClawFlows（clawflows.com）という専用サービスを使い、自然言語で「何を自動化したいか」を伝えると YAML を生成してレビュー用の PR まで作成してくれます。つまり Lobster は実行エンジン、ClawFlows は YAML を自動生成するフロントエンド という役割分担です。

YAML の定義例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

name: inbox-triage
steps:
  - id: collect
    command: inbox list --json
  - id: categorize
    command: inbox categorize --json
    stdin: $collect.stdout
  - id: approve
    command: inbox apply --approve
    stdin: $categorize.stdout
    approval: required          # ← ここで停止して人間の承認を待つ
  - id: execute
    command: inbox apply --execute
    condition: $approve.approved

Unix パイプとの違い

Unix パイプLobster
承認機能なしビルトイン（ステップ途中で停止・再開）
LLM コスト各ステップごとにツール呼び出し1 回の呼び出しで全ステップ実行
安全性スクリプト依存ランタイムが強制（タイムアウト、出力上限、サンドボックス）
再開最初からやり直しresume token で途中から再開可能

Lobster の核心的な価値は 承認チェックポイント にあります。ただし、全てのステップで承認を求めるわけではありません。YAML で approval: required と明示したステップでのみ停止 します。どこで止めるかはワークフロー設計者が決めます。

上の inbox-triage の例で言えば:

  1. collect（メール収集）→ 自動実行
  2. categorize（分類）→ 自動実行
  3. approve（承認ゲート）→ ここで停止。エージェントがメッセージングチャネル（Slack、WhatsApp など）を通じて「2 通の返信を送信しますか？」のようにユーザーに確認を求める
  4. execute（送信実行）→ ユーザーが承認すると resume token で途中から再開

「全部自動でいい」ならば approval を一切書かなければ通しで実行されますし、「送信前だけ確認したい」なら送信ステップの直前にだけ置く、という柔軟な設計です。

「AI に自律的に動いてほしいが、重要な操作は人間が確認したい」というニーズに対して、その境界線をワークフロー設計者が YAML の 1 行で制御できる のが Lobster の仕組みです。

bash/python スクリプト生成ではダメなのか？

「LLM に bash や python スクリプトを生成させて実行すれば同じでは？」という疑問は自然です。実際、多くのケースではスクリプト生成で十分です。Lobster が必要になるのは以下の条件が揃ったときです:

bash/python スクリプト生成Lobster
途中停止・承認自前で実装が必要（エージェント実行のスクリプトに対話的入力は使えない）approval: required の 1 行
途中再開最初からやり直しresume token で途中から
安全性LLM が生成したコードを信頼するしかない（ハルシネーションで意図しないコマンドが混入するリスク）ランタイムが allowlist / タイムアウト / 出力上限を強制
決定論性LLM が毎回微妙に違うコードを生成しうるYAML 定義は固定、実行結果が再現可能
監査スクリプトの中身を読む必要がある構造化された YAML、ログ・リプレイ可能

使い分けの判断基準:

  • スクリプト生成で十分: 一気に実行して結果を返せばいい処理、副作用がない・リスクが低い操作、1 回限りの処理
  • Lobster が必要: 途中で人間の承認が必要な処理、副作用のある操作（メール送信、課金、データ削除など）、繰り返し実行される定型ワークフロー

要するに Lobster は「汎用的なスクリプト実行環境」ではなく、副作用を伴う多段処理に人間の承認を組み込むための専用ランタイム です。

インストールと始め方

システム要件

  • Node.js 24 推奨（22 LTS 22.16+ も対応）
  • macOS / Linux / Windows（WSL2 推奨）

インストール

1
2
3
4
5
6

# 推奨: インストールスクリプト
curl -fsSL https://openclaw.ai/install.sh | bash

# npm の場合
npm install -g openclaw@latest
openclaw onboard --install-daemon

初期セットアップ

openclaw onboard コマンドでオンボーディングウィザードが起動し、Gateway、ワークスペース、チャネル、スキルの設定を対話的に行えます。

1
2
3

openclaw doctor      # 設定確認
openclaw status      # Gateway の状態確認
openclaw dashboard   # ブラウザ UI を起動

チャットボット + イベントハンドラとの本質的な違い

「チャットボットにイベントハンドラを定義して、そこから Claude Code を呼び出せば同じではないか？」という疑問が浮かぶかもしれません。概念的には近いですが、OpenClaw には以下の違いがあります:

チャットボット + Claude CodeOpenClaw
入力ソース1 つのチャットプラットフォーム22+ チャネルを 1 つの Gateway で統合
自律性イベント発火時のみ動作Heartbeat + Cron + Webhooks の 3 層
状態管理会話履歴程度セッション永続化 + SOUL.md / MEMORY.md
スキル個別に実装が必要ClawHub から 13,000+ スキルをインストール
デプロイ個別に配線が必要単一デーモンが全てを管理

OpenClaw の本質は「プログラム可能なワークフローエンジン」です。個別のパーツ（イベント駆動、永続記憶、マルチチャネル）はそれぞれ自前で構築可能ですが、これらを 1 つの統合ランタイムとして提供している のが OpenClaw の価値です。

まとめ

OpenClaw が定義した「イベント駆動 + 永続記憶 + マルチチャネル + スキルエコシステム」というパターンは、2026 年の AI エージェントの標準アーキテクチャになりつつあります。Anthropic の Claude Cowork Dispatch も同じ方向性を示しており、今後エージェントランタイム間の競争と相互運用がさらに進むと考えられます。

AI エージェントの「人格」が Markdown テキストファイルで定義され、プラットフォーム間で移植可能であるという事実は、エージェント AI の設計哲学として興味深いものです。