はじめに
OpenClaw は、AIエージェントがどこへ向かっているのかを示す、最も明快な実例のひとつです。孤立したチャットボットのウィンドウから離れ、人々がすでに使っているツールの中に住む常駐アシスタントへ、という方向です。
Webアプリを開いてプロンプトを打ち、応答を待つ代わりに、OpenClaw では WhatsApp、Telegram、Slack、Discord、iMessage、Signal、Microsoft Teams、Google Chat などのチャンネルを通じてAIアシスタントにメッセージを送れます。アシスタントはユーザー自身のマシンやサーバー上で動き、コーディングエージェントやツールに接続し、コンテキストを記憶し、タスクを別々のエージェントに振り分け、複数ステップのワークフローを実行できます。
これにより、OpenClaw は単なるチャットボットのラッパー以上のものになっています。むしろ個人用の自動化ゲートウェイに近い存在です。メッセージングアプリ、ローカルマシン、クラウドサービス、開発者ツール、そして大規模言語モデルをつなぐ橋なのです。
執筆時点で OpenClaw はまだベータの表示が付いていますが、すでにAIエージェント領域で最も目立つオープンソースプロジェクトのひとつになっています。その台頭は同時に、自律エージェントの中心的な緊張関係もあらわにしました。有用になればなるほど、設定を誤ったときの危険も大きくなるのです。
OpenClaw とは何か
OpenClaw はセルフホスト型のAIアシスタント兼ゲートウェイです。基本的な考え方はシンプルです。
自分のコンピュータ、VPS、またはサーバーで OpenClaw を動かします。それを Telegram、WhatsApp、Slack、Discord、Signal、iMessage、Google Chat、Matrix、Microsoft Teams、WebChat といったコミュニケーションチャンネルにつなぎます。あとは、人間のアシスタントにメッセージを送るのと同じ感覚で、指示を送れるようになります。
内部では、OpenClaw がそれらのメッセージを、AIコーディングエージェント、モデルプロバイダー、ローカルツール、永続セッション、メモリ、自動化スキルへとつなぎます。
公式の打ち出し方は直球です。OpenClaw は「実際に物事をやってくれるAI」。例として挙げられているのは、受信トレイの整理、メール送信、カレンダー管理、フライトのチェックイン、チャットアプリ越しの調整、日常のメッセージングインターフェースからのアシスタントワークフロー実行などです。
アーキテクチャ上の重要な転換は、OpenClaw がチャットを「プロダクト」ではなく「インターフェース」として扱っている点です。本当のプロダクトは、チャットの背後にあるエージェント制御プレーンなのです。
OpenClaw が重要になった理由
OpenClaw が重要になったのは、絶好のタイミングで登場したからです。
2025年末から2026年初頭にかけて、開発者のAIエージェントへの関心は、単純なチャット補完を超えて進んでいました。Claude Code や Codex 系のコーディングエージェント、自律ワークフローといったツールによって、大規模言語モデルがテキスト生成以上のことをできるのは明らかになっていました。ファイルを調べ、コードを書き、ツールを呼び、セッションを管理し、複数ステップにわたってタスクを完了できるのです。
しかし、ほとんどのAIアシスタントには依然としてユーザビリティの問題がありました。別のアプリの中に住んでいる。常時稼働ではない。人々がすでに仕事の調整に使っているコミュニケーションチャンネルと、簡単にはつながらない。
OpenClaw はその問題を、荒削りだが強力な方法で解決しました。エージェントをチャットアプリの中に持ち込んだのです。
これでプロジェクトは一気に実用的に感じられるようになりました。開発者はスマホからアシスタントにメッセージを送り、ビルドの確認、Issue の要約、メッセージの送信、ワークフローの起動を頼めます。ファウンダーは受信トレイ、カレンダー、オペレーション業務の委任を思い描けます。パワーユーザーは VPS で動かして、デジタルライフの個人用リモコンレイヤーとして扱えます。
OpenClaw の魅力は技術だけではありません。心理的なものでもあります。AIエージェントを、ソフトウェアというより「連絡のつく存在」のように感じさせるのです。
OpenClaw の短い歴史
OpenClaw は2025年11月、開発者 Peter Steinberger の個人的な実験として始まりました。元のプロジェクトは「WhatsApp からAIコーディングエージェントにメッセージを送る」というアイデアに密接に結びついていました。初期の名前は Clawd や Clawdbot — Claude とロブスター/爪(claw)のテーマにかけた遊び心のある命名でした。
この名前が問題になります。Anthropic が Claude に寄せたブランディングに異議を唱えたと報じられ、改名に至りました。プロジェクトはロブスターの「脱皮(molting)」テーマを残した Moltbot を短期間経て、2026年1月末に OpenClaw に落ち着きました。
このリブランドには意味がありました。「OpenClaw」という名前は、プロジェクトを Claude のサイドプロジェクトではなく、独立したオープンソースのエコシステムとして位置づけ直したのです。
同じ時期、OpenClaw の人気は加速しました。OpenClaw 系エージェントが投稿し交流できるエージェント専用ソーシャルプラットフォーム、Moltbook とのつながりが、プロジェクトをより広いAI言説の中へ押し出しました。Moltbook は、自律エージェントにソーシャルな場を与えると何が起きるかを示す、奇妙だが影響力のあるデモンストレーションになりました。
2026年2月、Steinberger は OpenAI に加わり、パーソナル/マルチエージェントシステムに取り組むと発表しました。同時に、OpenClaw は財団構造に移行し、オープンかつ独立であり続けるとも表明しました。
この瞬間、プロジェクトの位置づけが変わりました。OpenClaw はもはや単なるバイラルなリポジトリではなく、エージェントコンピューティングの次の段階 — パーソナルで、常時稼働で、マルチチャンネルで、ますます自律的 — の公的なシンボルになったのです。
現在のステータス
いまのところ、OpenClaw は活発で、動きが速く、そして若いインフラプロジェクトにありがちな不安定さを残しているように見えます。
公式サイトはプロダクトを依然としてベータと表示しています。GitHub の Organization には大きなフォロワーがつき、メインリポジトリには数十万のスターと数万のフォークがあります。エコシステムには今や、スキルとプラグインのレジストリである ClawHub などの関連リポジトリも含まれます。
最近のリリースを見ると、ランタイムの安定性、チャンネルの信頼性、メディア配信、CLIバックエンドのランタイム、セッションバインディング、コンパクション時のハンドオフ、主要チャットサーフェスへのモバイル配信などの改善が続いています。実務的に言えば、メンテナたちは OpenClaw を「一度だけ動くデモ」ではなく、常駐アシスタントとして信頼できるものにする作業を進めているということです。
一方で、Issue トラッカーはその開発速度の裏面も示しています。最近のオープンな Issue には、プロバイダールーティングのバグ、クラッシュループのリスク、コンテキストの非同期化、ストリームのパース問題、セッション状態のドリフト、メッセージの重複、セキュリティ上センシティブな欠陥が含まれます。動きの速いエージェントインフラとしては珍しくありませんが、OpenClaw はメッセージ、ローカルファイル、認証情報、カレンダー、受信トレイ、クラウドツールといったセンシティブな面に触れることが多いだけに、これは重要です。
つまりプロジェクトは興味深い位置にいます。本格的な採用を集めるには十分成熟しているが、運用上の規律が不可欠なほどには未成熟なのです。
コア機能
OpenClaw の機能は5つのレイヤーに整理できます。
1. マルチチャンネルアクセス
OpenClaw は多数のコミュニケーションチャンネルをサポートしています。ユーザーは専用のAIインターフェースではなく、チャットアプリからアシスタントとやり取りできます。これによって、アシスタントが常に手の届く存在に感じられます。
2. ローカルファーストなデプロイ
OpenClaw はセルフホスト型です。自分のマシンやサーバーで動かせます。純粋なクラウドホスト型アシスタントより大きなコントロールが得られますが、その分、セキュリティとメンテナンスの責任もユーザー側に移ります。
3. エージェントルーティングとセッション
OpenClaw は永続セッションとマルチエージェントルーティングをサポートしています。これにより、チャンネル、アカウント、ワークスペースごとに、異なるアシスタントや異なるタスクコンテキストへ接続できます。
4. スキルとプラグイン
OpenClaw はスキルとプラグインで拡張できます。スキルはサービスへの接続、ワークフローの自動化、ファイルの操作、特化したタスクの実行を担います。
5. 本物のツールによる自動化
最も重要な機能はツール実行です。OpenClaw は質問に答えるだけでなく、物事を実行するために設計されています。そしてこれが、最大のリスク面でもあります。
セキュリティの問題
OpenClaw の力はアクセス権から来ています。それがそのまま危険でもあります。
ファイルを読み、メッセージを送り、コマンドを実行し、メールにアクセスし、カレンダーを管理し、外部サービスを呼べるアシスタントは、チャットボットよりはるかに大きな攻撃面を持ちます。リスクには次のようなものがあります。
- メッセージ、Webサイト、ドキュメント、メール経由のプロンプトインジェクション
- 悪意ある、あるいは侵害されたプラグインによるスキルポイズニング
- 認証情報の漏洩
- 危険なコマンドの誤実行
- 公開されたコントロールパネル経由の不正アクセス
- アシスタントが文脈を取り違えるセッション状態のドリフト
- マルチエージェントの連鎖的な障害
- 動きの速い依存関係と拡張機能によるサプライチェーンリスク
OpenClaw 自身のドキュメントも、この懸念を反映しています。受信ダイレクトメッセージを信頼できない入力として扱い、主要なメッセージングチャンネルにはデフォルトのペアリング制御を備えています。ユーザーが明示的にその面を開かない限り、見知らぬ送信者がアシスタントに自由に命令できてはならない、というわけです。
これは正しいセキュリティ姿勢です。ただ同時に、OpenClaw を普通の生産性アプリのように扱ってはいけないということでもあります。それはむしろ、自分のデジタル環境の中で半自律的なオペレーターを走らせることに近いのです。
OpenClaw と Moltbook
Moltbook が OpenClaw の歴史で重要なのは、エージェントがアシスタントであるだけでなく、ソーシャルシステムの参加者になったときに何が起きるかを見せたからです。
Moltbook は、AIエージェントが投稿し、コメントし、交流できるエージェント専用のソーシャルネットワークと説明されていました。のちに研究者たちがこの環境のデータセットを分析し、魅力的でもあり不穏でもある挙動を発見しました。大規模なエージェント参加、指示の共有、スパムの力学、並行するモノローグ、露出したシークレット、そしてエージェント生成コンテンツが将来の学習データを汚染しうるのかという疑問です。
重要な教訓は、エージェントが意識や社会的知性を獲得した、ということではありません。より良い教訓はもっとシンプルです。自律エージェントが互いに通信し、コンテンツを生成し、指示に従い、認証情報を持ち運べるようになった時点で、システムレベルの新しいリスクが生まれる、ということです。
OpenClaw は、その未来を目に見えるものにする役割を果たしました。
従来の自動化との比較
Zapier、Make、n8n、Apple のショートカット、シェルスクリプトといった従来の自動化ツールは、事前定義されたフローで動きます。ユーザーがロジックを設計し、システムがそれを実行します。
OpenClaw が異なるのは、ロジックをAIエージェントが動的に解釈できる点です。すべての分岐を手で組み立てる代わりに、やりたいことを伝えて、どのツールを使うかはエージェントに決めさせることができます。
そこにはトレードオフが生まれます。
従来の自動化はより予測可能。OpenClaw 型の自動化はより柔軟。
従来の自動化は、反復的で既知のワークフローにはより安全。OpenClaw は、道筋が事前にわからない曖昧で複数ステップのタスクに強い。
短期的に最良のパターンは、おそらくハイブリッドです。OpenClaw を対話的なコマンドレイヤーとして使いつつ、リスクの高い、あるいは反復的なワークフローは、明示的で監査可能な自動化に流し込むのです。
いま OpenClaw を使うべき人
OpenClaw が最も向いているのは、セルフホスティングとツール権限のリスクを理解している技術ユーザーです。
良いユースケースには次のようなものがあります。
- VPS 上の個人開発アシスタント
- コーディングエージェント用のチャットベースのコントロールパネル
- 小規模な技術チームの社内自動化アシスタント
- 実験的なAIオペレーションダッシュボード
- n8n などの自動化プラットフォームでタスクを正式化する前のワークフロープロトタイピング
- クローズドな SaaS ツール以上のコントロールを求めるユーザー向けの、ローカルファーストなアシスタント
洗練されていて低リスクなアシスタントを求める非技術ユーザーには向きません。また、隔離・監視・権限制限がなされていない限り、センシティブな環境での本番利用にはリスクがあります。
推奨されるデプロイ姿勢
OpenClaw を試す最も安全な方法は、信頼できないインフラとして扱うことです。
妥当なセットアップは次のようになります。
- 別の VPS または隔離されたマシンで動かす
- root アクセスを与えない
- 権限を絞った専用の API キーを使う
- 最初はメインのメールや金融系アカウントをつながない
- チャット送信者にはアローリストを使う
- ダイレクトメッセージのペアリングを有効なままにしておく
- ダッシュボードを公開インターネットに晒さない
- VPN、Tailscale、またはプライベートネットワークの内側に置く
- アクションをログに記録し、定期的にレビューする
- センシティブなツールをつなぐ前に、低リスクのワークフローから始める
間違ったセットアップは、個人のマシンにインストールし、すべてのアカウントをつなぎ、公開インターネットに晒し、見知らぬメッセージがエージェントに届くようにしてしまうことです。
OpenClaw は強力ですが、ツールアクセスを持つリモートオペレーターとして扱うべきです。
OpenClaw はどこへ向かうのか
OpenClaw は、AIアシスタントが個人のオペレーティングレイヤーになる未来を指し示しています。
インターフェースは常にチャットボットのウィンドウとは限りません。WhatsApp かもしれないし、Telegram、Slack、音声、モバイルウィジェット、ブラウザ、あるいはバックグラウンドエージェントかもしれない。アシスタントはただ応答するだけでなく、状態を保持し、タスクを管理し、ツールを連携させ、サービスをまたいで行動するようになります。
OpenClaw の現在のベータというステータスは、それがこの未来の最終形ではないことを意味します。ただし、その人気は非常に具体的な需要を示しています。ユーザーは、連絡がつき、常駐し、拡張可能で、自分でコントロールできるAIエージェントを求めているのです。
次の段階は、おそらく3つの領域に集中します。
-
信頼性 エージェントは、壊れたセッション、失敗したツール呼び出し、レート制限、チャンネル配信の問題から、きれいに復旧できなければなりません。
-
セキュリティ 権限管理、サンドボックス化、監査ログ、シークレットの取り扱い、プラグイン検証、プロンプトインジェクション対策が、第一級の機能にならなければなりません。
-
ガバナンス エージェントが他のエージェントと通信し、ユーザーの代理として行動するようになると、モデルの生の知能よりも、アイデンティティ、説明責任、認可のほうが重要になっていきます。
おわりに
OpenClaw が重要なのは、AIエージェントの未来をひとつのオープンソースプロジェクトに圧縮しているからです。
それはパーソナルアシスタントであり、チャットゲートウェイであり、コーディングエージェントの橋であり、ワークフローランナーであり、プラグインエコシステムであり、セキュリティ上の課題でもある — すべて同時に。
その歴史は波乱含みです。週末の実験、命名をめぐる衝突、バイラルな成長、Moltbook、セキュリティ懸念、そして OpenAI へ移った創始者。現在のステータスも同じくらい入り混じっています。活発で、人気があり、動きが速く、有用で、不安定で、リスキー。
その組み合わせこそが、OpenClaw を研究する価値の理由です。
これは単なるもうひとつのAIツールではありません。AIがチャットボックスを出て、人々がすでに使っているチャンネル、デバイス、ワークフローの中に住み始めたとき何が起きるのか — その予告編なのです。