エージェント基盤の開発速度を、スター数ではなくコミットで測る時代が来ています。
この記事では、OpenClawが直近12時間で50件を超えるコミットを公開した事実と、その中身であるMattermostポリシー、Slack relay、WhatsApp修正、レート制限、自律修復の各改善を整理します。
この記事でわかること
- OpenClawが直近で何を強化したのか
- Mattermost・Slack・WhatsAppそれぞれの変更点
- 「star noise」と開発速度を見分ける視点
OpenClawとは何か
OpenClawは、自分のマシンやサーバー上で動かすセルフホスト型のAIエージェント基盤です。単一のGatewayプロセスがWhatsApp、Telegram、Slack、Discord、Mattermostなど20以上のチャット経路を束ね、コーディングエージェントへメッセージを届けます。MITライセンスのオープンソースで、設定ファイルは ~/.openclaw/openclaw.json に置きます。
2026年6月21日、開発進捗を追うアカウントRazzReportが、12時間で50件超のコミットが入ったと報告しました。GitHub APIで同じ期間を確認すると、実際のマージ数はそれ以上に達しています。スター数だけを見ても開発の実態は分からない、という文脈での発信です。
何が変わったのか
直近の変更は、チャネル連携の信頼性と運用時の制御を厚くする方向に寄っています。大きく5つの領域に分けられます。
Mattermostのポリシー強化
Mattermost連携は @openclaw/mattermost プラグインで提供されます。今回の強化は、アクセス制御とコールバック検証が中心です。
DMはデフォルトで dmPolicy: "pairing" となり、未知の送信者にはペアリングコードが返ります。公開DMにする場合は dmPolicy: "open" と allowFrom: ["*"] の両方が必要です。チャンネル側は groupPolicy: "allowlist" が標準で、メンションをトリガーに応答します。
ネイティブスラッシュコマンドのコールバックは、Mattermost APIで現行登録を確認できない場合に拒否する「fail closed」設計です。失敗した検証は短時間キャッシュし、同時リクエストはまとめて処理します。さらにコマンドごとにレート制限をかけ、リプレイ攻撃の圧力を抑えます。ゲートウェイ再起動なしで、削除や再生成されたスラッシュコマンドの古いトークンを無効化する仕組みも入っています。
DMチャンネル作成が一時的に失敗した場合は dmChannelRetry で再試行します。429や5xx、タイムアウトは再試行対象で、それ以外の4xxは即座に打ち切ります。
Slack relayモードの追加
Slack連携に3つ目の接続方式 relay が加わりました（PR #94707）。従来のSocket ModeやHTTPに加え、外部の openclaw-slack-router がWebSocketでイベントを中継し、ゲートウェイはSlack Web APIで返信を送る構成です。
設定は mode: "relay" に加え、relay.url、relay.authToken、relay.gatewayId を指定します。BearerトークンとゲートウェイIDで認証し、既存のSlackバックオフ方針で再接続します。ルーター側でユーザーグループメンションから宛先ゲートウェイが決まるため、relay経由のイベントは承認済みメンションとして処理されます。
Socket Modeの接続を中央ルーターに集約しつつ、各ゲートウェイはペルソナや送信経路をそのまま使える点が狙いです。relayアカウントはボットトークンが必須ですが、アプリトークンやHTTP署名シークレットは不要です。
WhatsAppの安定性修正
v2026.6.9リリースではWhatsAppまわりの修正が複数入っています。ソケット操作に上限を設け、ターミナル切断時も認証状態を保持します。メディア送信が途中で失敗しても、先頭のテキストチャンクを落とさないようになりました。末尾メディアの失敗時はサイレントドロップではなくユーザーへ通知します。マークダウン変換でコードスパン直後の数字が消える不具合も修正されています。
インバウンド受付の基盤リファクタや、読み取り確認ソケットのスタール検知も含まれ、長時間稼働する個人アシスタント向けの改善です。
レート制限の拡充
レート制限はチャネル横断で入っています。Mattermostのスラッシュコマンド検証はコマンド単位で新規ルックアップを抑制します。ノードのペアリングリクエストにもレート制限が適用され、短時間の大量接続試行を防ぎます。DMチャンネル再試行は429を一時障害として扱い、指数バックオフで再送します。
エージェント基盤を常時稼働させる場合、外部APIの制限と内部リソースの両方を意識した設計が必要です。今回の変更はその両面に手が入っています。
自律修復とエージェントリカバリ
運用面では openclaw doctor --fix が設定や状態の修復を担います。古い設定のマイグレーション、スーパーバイザー設定の更新、プラグイン修復などを対話なしで適用できます。OPENCLAW_SERVICE_REPAIR_POLICY=external を指定すれば、外部スーパーバイザー管理下ではサービス再起動だけを抑えた修復も可能です。
エージェント実行側では、v2026.6.9で「More dependable agent recovery」が謳われています。思考のみで終わったターンの再試行、コンパクション後の使用量保持、セッション履歴の修復、返信の再整合など、中断や部分完了から最終応答へ戻す処理が強化されています。CLIの公式プラグイン修復や、更新失敗後のゲートウェイ再起動も同じ流れです。
開発速度をどう見るか
OpenClawのGitHubスター数は2026年6月時点で約38万件に達しています。一方、スターだけでは実装の鮮度や品質は測れません。今回の報告が「star noise」に触れているのは、注目度と開発速度を切り分けよ、という意味合いです。
12時間で50件超のコミットは、チャネルアダプタ、エージェントランタイム、CLI、CIまで横断した改善が同時進行しているサインです。Mattermostのポリシー、Slack relay、WhatsApp修正、レート制限、doctorによる自律修復は、いずれも本番運用で効く変更です。
誰にとって有益か
複数チャット経路でAIエージェントを常時稼働させている開発者やパワーユーザーが主な対象です。Slackをチームの作業場にしている場合はrelayモードでルーター分離を検討できます。Mattermostを社内チャットに使っている場合は、ペアリングやスラッシュコマンドのfail closed設計をそのままセキュリティ境界に使えます。
すでにOpenClawを動かしている環境では、openclaw doctor で設定を点検し、最新版へ更新するのが現実的な次の一手です。新規導入は openclaw onboard --install-daemon から始め、使うチャネルだけを段階的に有効化する進め方が公式ドキュメントで推奨されています。