OpenClawのリファクタリング計画：コードを最大600行削減する方法

プロジェクトが成長するにつれて、似たようなコードが複数のファイルに散らばってしまうのはよくある悩みですよね。特にプラグイン開発では、同じような設定や処理を何度も書いていることに気づくはずです。

こうした重複を整理し、コードベースをクリーンに保つためのリファクタリング・バックログを作成しました。削減できるコード行数（LOC）の見込みや安全性、影響範囲に基づいて優先順位を付けています。

1. Channelプラグインの構成とセキュリティの雛形

最も価値の高いリファクタリング対象です。

多くのChannelプラグインで、以下のような共通の構造が繰り返されています。

- config.listAccountIds
- config.resolveAccount
- config.defaultAccountId
- config.setAccountEnabled
- config.deleteAccount
- config.describeAccount
- security.resolveDmPolicy

主な例：

- extensions/telegram/src/channel.ts
- extensions/googlechat/src/channel.ts
- extensions/slack/src/channel.ts
- extensions/discord/src/channel.ts
- extensions/matrix/src/channel.ts
- extensions/irc/src/channel.ts
- extensions/signal/src/channel.ts
- extensions/mattermost/src/channel.ts

抽出後のイメージ：

- buildChannelConfigAdapter(...)
- buildMultiAccountConfigAdapter(...)
- buildDmSecurityAdapter(...)

期待される効果：

約 250-450 LOC の削減

リスク：

中程度。各Channelごとに isConfigured の挙動や警告、正規化の処理が微妙に異なります。

2. Extensionランタイムのシングルトン・ボイラープレート

非常に安全に実施できる項目です。

ほぼすべてのExtensionで、同じようなランタイム保持の仕組みが使われています。

- let runtime: PluginRuntime | null = null
- setXRuntime
- getXRuntime

主な例：

- extensions/telegram/src/runtime.ts
- extensions/matrix/src/runtime.ts
- extensions/slack/src/runtime.ts
- extensions/discord/src/runtime.ts
- extensions/whatsapp/src/runtime.ts
- extensions/imessage/src/runtime.ts
- extensions/twitch/src/runtime.ts

特殊なケース：

- extensions/bluebubbles/src/runtime.ts
- extensions/line/src/runtime.ts
- extensions/synology-chat/src/runtime.ts

抽出後のイメージ：

createPluginRuntimeStore<T>(errorMessage)

期待される効果：

約 180-260 LOC の削減

リスク：

3. オンボーディングのプロンプトとconfig-patchのステップ

影響範囲が広いセクションです。

多くのオンボーディング用ファイルで、以下の処理が繰り返されています。

account id の解決
allowlist エントリのプロンプト表示
allowFrom のマージ
DM policy の設定
secrets のプロンプト表示
トップレベル設定とアカウントスコープ設定のパッチ適用

主な例：

- extensions/bluebubbles/src/onboarding.ts
- extensions/googlechat/src/onboarding.ts
- extensions/msteams/src/onboarding.ts
- extensions/zalo/src/onboarding.ts
- extensions/zalouser/src/onboarding.ts
- extensions/nextcloud-talk/src/onboarding.ts
- extensions/matrix/src/onboarding.ts
- extensions/irc/src/onboarding.ts

既存のヘルパーの接点：

src/channels/plugins/onboarding/helpers.ts

抽出後のイメージ：

- promptAllowFromList(...)
- buildDmPolicyAdapter(...)
- applyScopedAccountPatch(...)
- promptSecretFields(...)

期待される効果：

約 300-600 LOC の削減

リスク：

中程度。共通化しすぎないことがコツです。ヘルパーは小さく、組み合わせ可能な形に保つのがベストです。

4. マルチアカウント対応のconfig-schemaフラグメント

Extension間で繰り返されているスキーマの断片を整理します。

よくあるパターン：

- const allowFromEntry = z.union([z.string(), z.number()])
- account schema plus:
  - accounts: z.object({}).catchall(accountSchema).optional()
  - defaultAccount: z.string().optional()
- repeated DM/group fields
- repeated markdown/tool policy fields

主な例：

- extensions/bluebubbles/src/config-schema.ts
- extensions/zalo/src/config-schema.ts
- extensions/zalouser/src/config-schema.ts
- extensions/matrix/src/config-schema.ts
- extensions/nostr/src/config-schema.ts

抽出後のイメージ：

- AllowFromEntrySchema
- buildMultiAccountChannelSchema(accountSchema)
- buildCommonDmGroupFields(...)

期待される効果：

約 120-220 LOC の削減

リスク：

低〜中程度。シンプルなスキーマもあれば、特殊なものもあります。

5. Webhookとモニタのライフサイクル起動

中規模ながら価値の高い項目です。

startAccount やモニタ設定のパターンが繰り返されています。

アカウントの解決
Webhook パスの計算
起動ログの出力
モニタの開始
中断（abort）の待機
クリーンアップ
ステータスシンクの更新

主な例：

- extensions/googlechat/src/channel.ts
- extensions/bluebubbles/src/channel.ts
- extensions/zalo/src/channel.ts
- extensions/telegram/src/channel.ts
- extensions/nextcloud-talk/src/channel.ts

既存のヘルパーの接点：

src/plugin-sdk/channel-lifecycle.ts

抽出後のイメージ：

- helper for account monitor lifecycle
- helper for webhook-backed account startup

期待される効果：

約 150-300 LOC の削減

リスク：

中〜高。トランスポートの詳細部分で差異が出やすい箇所です。

6. 小規模な重複コードのクリーンアップ

低リスクで実施できるクリーンアップ作業です。

例：

- duplicated gateway argv detection:
  - src/infra/gateway-lock.ts
  - src/cli/daemon-cli/lifecycle.ts
- duplicated port diagnostics rendering:
  - src/cli/daemon-cli/restart-health.ts
- duplicated session-key construction:
  - src/web/auto-reply/monitor/broadcast.ts

期待される効果：

約 30-60 LOC の削減

リスク：

テストクラスター

テストコード内にも共通化できるパターンが多く存在します。

LINE Webhook イベントのフィクスチャ

主な例：

src/line/bot-handlers.test.ts

抽出後のイメージ：

- makeLineEvent(...)
- runLineEvent(...)
- makeLineAccount(...)

期待される効果：

約 120-180 LOC の削減

Telegram ネイティブコマンドの権限マトリックス

主な例：

- src/telegram/bot-native-commands.group-auth.test.ts
- src/telegram/bot-native-commands.plugin-auth.test.ts

抽出後のイメージ：

- forum context builder
- denied-message assertion helper
- table-driven auth cases

期待される効果：

約 80-140 LOC の削減

Zalo ライフサイクルのセットアップ

主な例：

extensions/zalo/src/monitor.lifecycle.test.ts

抽出後のイメージ：

shared monitor setup harness

期待される効果：

約 50-90 LOC の削減

Brave LLMコンテキストの未サポートオプションテスト

主な例：

src/agents/tools/web-tools.enabled-defaults.test.ts

抽出後のイメージ：

it.each(...) matrix

期待される効果：

約 30-50 LOC の削減

推奨される順序

効率的に進めるために、以下の順番での実施をおすすめします。

Runtime シングルトンのボイラープレート
小規模な重複コードのクリーンアップ
Config および Security ビルダーの抽出
テストヘルパーの抽出
オンボーディング・ステップの抽出
モニタ・ライフサイクルヘルパーの抽出

セットアップや詳細な実装方法について質問がある場合は、AI Setup Assistant を活用してください。

次のステップ

OpenClaw Expert

まだ解決しませんか？

このページで解決しない場合は、OpenClaw Expertに直接質問してください。