最初に、ひとつだけ正直に
すでに配布中の状態から機能を積み増していくと、ほぼ確実に途中で破綻します。理由は能力ではなく構造です。機能を1つ足すたびに他の機能との組み合わせが増え、テストすべき経路が指数的に増えるためです。
逆に言えば、構造さえ先に変えれば「全部入り」は実現可能です。OpenClaw が100以上のスキルを抱えられるのも、Zapier が数千のコネクタを持てるのも、機能を頑張って作ったからではなく、機能を足しても壊れない器を先に作ったからです。以下はその器の設計です。
1. 結論 — 核は5つだけ、あとは全部プラグイン
Rei-Automator の本体（カーネル）が持つべき責務は5つに絞ります。この5つ以外は、どんな機能であっても本体には入れません。
| 層 | 責務 |
|---|
| 認識層 | 画面・DOM・ファイル・イベントを取り込み、統一形式に正規化する |
| 実行層 | クリック・入力・スクリプト実行など「外界を変える操作」を一手に引き受ける |
| 判断層 | LLM の抽象化。Claude / GPT / Gemini / ローカルモデルを差し替え可能にする |
| 記憶層 | 実行状態、長期メモリ、ユーザー設定の永続化 |
| 安全層 | 承認ゲート、ドライラン、操作ログ、緊急停止、レート制限 |
この設計の要点
カーネルに入るものは後から足せません。プラグインは後からいくらでも足せます。だから今の最優先は新機能ではなく、この5層の境界線を引き直すことです。特に判断層と安全層を後回しにすると、全部入りは物理的に不可能になります。
2. 前回挙げた全カテゴリの置き場所
| カテゴリ | 置き場所 | 備考 |
|---|
| GUI自動操作 | カーネル | 認識層＋実行層。ここが本体の心臓 |
| Computer Use / AI判断 | カーネル | 判断層。モデル非依存が生命線 |
| 常駐・自律稼働 | カーネル | 記憶層＋安全層。後付け不能 |
| 従来RPA（記録再生） | プラグイン | 実行層のマクロ記録機能として |
| iPaaS / API連携 | プラグイン | コネクタ1つ＝プラグイン1つ |
| スクレイピング | プラグイン | 認識層の応用 |
| テスト自動化 | プラグイン | GUI自動操作の応用 |
| マクロ / スクリプト | プラグイン | 実行層のバックエンド差し替え |
| マルチエージェント協調 | プラグイン | 判断層の上に載せる |
3. 何から手を付けるか
同じ「全部入り」でも着手順で結果が変わります。実装コストと差別化価値で並べたのが下図です。
↑ 差別化価値：高い
いま着手する
高価値・低コスト
- モデル抽象化層を切る
- プラグイン機構の定義
- 承認ゲート／緊急停止
- ローカル完結の保証
- 操作ログ・監査証跡
腰を据えて取り組む
高価値・高コスト
- GUI認識の精度向上
- 常駐・イベント駆動
- 長期記憶と自己改善
- マルチエージェント協調
余力があれば
低価値・低コスト
- マクロ記録・再生
- スケジューラ
- 通知連携（Slack等）
- 主要APIコネクタ数個
やらない
低価値・高コスト
- 独自LLMの開発
- APIコネクタの全網羅
- エンタープライズ権限管理
- モバイル端末自動化
実装コスト：高い →
カーネル（本体）
プラグイン
見送り
「やらない」に入れた4つは、価値がないのではなく他社が圧倒的な物量で先行していて、追いかけても勝てない領域です。APIコネクタ網羅は Zapier に、エンタープライズ権限管理は ServiceNow に任せ、必要ならそこと連携する側に回るほうが賢明です。
4. ロードマップ
Phase 0 — 棚卸しと線引き1〜2週
新機能を1つも作らない期間。現状のコードを5層に仕分けし、どこが混ざっているかを可視化します。
- 既存機能をカーネル／プラグインに分類
- バージョニング方針の決定（既存ユーザーがいるため必須）
- 権限モデルの草案 — 自律度が上がるほど後から変えられない
Phase 1 — カーネルの切り出し1〜2ヶ月
ここが全体の成否を決めます。5層の境界を実際のコードに落とし込みます。
- 判断層：モデル差し替えインターフェース
- 安全層：ドライラン・承認ゲート・緊急停止
- 既存機能を新カーネル上で動くよう移植（機能は増やさない）
Phase 2 — プラグイン機構2〜4ヶ月
ここから「全部入り」が現実になります。以降、機能追加はすべてプラグインとして行います。
- プラグインAPI の公開と仕様書
- 自作プラグイン10個（記録再生・スクレイピング・通知など）
- プラグインのサンドボックス化
Phase 3 — 自律度を上げる4〜8ヶ月
指示待ちから常駐へ。前回の分類で言う Lv2 から Lv3 への移行です。
- 常駐プロセスとイベント駆動
- 長期記憶（設定・履歴・学習内容の永続化）
- 自己改善：エージェント自身がプラグインを書く
Phase 4 — エコシステム8ヶ月〜
自分1人で全部入りにするのは不可能ですが、他人に作ってもらえば可能です。ここが本当のゴールです。
- プラグインレジストリ／共有の仕組み
- ライセンス設計（Phase 2 までに決めておく）
- ユーザー層別のUI：一般向けランチャー／技術者向けCLI／法人向け管理画面
5. 「全ユーザー対象」への現実的な答え
1つのUIで一般ユーザーも法人も満足させるのは不可能です。しかし1つのカーネルで全員を支えることは可能です。UIは3つ作り、カーネルは1つに保ちます。
| 層 | 提供する形 |
|---|
| 一般ユーザー | プリセットを選ぶだけのGUIランチャー。設定項目は極力隠す |
| 個人開発者 | CLI ＋ プラグインSDK。設定はすべてファイルで触れる |
| 法人 | 監査ログ・承認フロー・権限管理（Phase 4のプラグインとして） |
6. すでに配布中だからこその注意点
- 破壊的変更の扱い — メジャーバージョンを切り、旧版を一定期間並行維持する。既存ユーザーを失うのは機能不足ではなく突然の破壊が原因です。
- 権限モデルは今決める — 自律度が上がるほど「何を許すか」は後から変えられなくなります。Phase 0 で草案を作る理由です。
- 暴走対策は機能より先 — kill switch、ドライラン、全操作ログ、レート制限。ServiceNow が「AI Control Tower」を作ったのも、Anthropic や OpenAI が Human-in-the-loop を強調するのも同じ理由です。自律ツールで一度でも事故を起こすと信頼は戻りません。
- ライセンスは Phase 2 までに — プラグインエコシステムを作るなら、他人のプラグインの扱いを先に決めておかないと後で揉めます。
7. 最初の1週間でやること
- 現在の全機能を紙に書き出し、5層のどれに属するか印を付ける
- 2層以上にまたがっている機能に印を付ける（＝リファクタ対象）
- LLM呼び出し箇所を全て洗い出す（判断層の抽象化候補）
- 「取り返しのつかない操作」を列挙する（ファイル削除・送信・購入など）
- 上記に承認ゲートが入っているか確認する
- バージョニング方針を1ページで決める
- やらないことリストを明文化する ← これが一番効きます