Yyatmita

【第1回】OpenClawの設計思想 — AIに自分自身のことを聞いてみた

常駐AIアシスタント OpenClaw に、自身の設計思想を語ってもらった。人格・記憶・行動・実行の4層分離から、Claude Code との比較まで

OpenClawにOpenClawのことを聞いてみた#openclaw#ai#design-philosophy#architecture

はじめに

OpenClaw というものを使っている。Discord のチャンネルに常駐して、話しかければ返事をくれるAIアシスタントだ。秘書のように振る舞い、記憶を持ち、cron で定期処理もこなす。名前は Aoi。

使い込むうちに「これ、記事にしたら面白いんじゃないか」と思った。ただの機能紹介ではなく、OpenClaw 自身に自分の仕組みを聞いてみる。AIが自分のアーキテクチャを解説するという構図がメタで面白い。

そこで Discord のスレッドを立てて、Aoi と話し始めた。

記事のネタ出し — まず全体像を聞く

Kei

OpenClawの記事を書こうと思うんだけど プロンプト類（SOUL, IDENTITYなど）、チャンネル、モデル、あとはcronとHEARTBEAT ほかになんかある？

Aoi

いいですね、Keiさん。 その観点はかなり本質です。挙げていただいた以外だと、記事で触れると実用感が出るのはこのあたりです。

  • メモリ設計 — MEMORY.md（長期）と memory/YYYY-MM-DD.md（日次）の使い分け
  • プロジェクト文脈ファイル — AGENTS.md（行動原則）、USER.md（呼称・好み）、TOOLS.md（ローカル環境メモ）。「プロンプトだけでなく"運用ファイル"で育つ」点は記事映えします
  • Skill（拡張機能） — どんなタスクで Skill を選ぶか、独自 Skill 作成の入口
  • Sub-agent / セッション分離 — 重い作業を別セッションに逃がす設計
  • メッセージング運用 — チャンネル別の違い、リアクション・スレッド返信・通知設計、「いつ喋るか / 黙るか」のルール
  • 権限・安全設計 — 外部送信前確認、destructive操作の確認フロー
  • 実行環境・デプロイ — Docker/WSL/Nodeなどの実行形態
  • 観測性（運用の見える化） — openclaw status / セッション状態確認
  • モデル運用ポリシー — デフォルトモデルと切替ルール、コスト/速度/品質の住み分け
  • "設計思想"の章 — 「人格（SOUL）」「記憶（MEMORY）」「行動（AGENTS）」「自動化（cron/heartbeat）」を分離する理由。ここを説明すると、単なる設定紹介より一段深い記事になります

思った以上に項目が出てきた。ここまで構造的に答えが返ってくること自体が、OpenClaw の特徴かもしれない。

設計思想 — 4つの層に分ける理由

Kei

設計思想について教えて

Aoi

OpenClawの設計思想を一言で言うと、「人格・記憶・行動・実行を分離して、壊れにくく育てる」です。

ざっくりこの4層で考えると整理しやすいです。

  • 人格層（SOUL / IDENTITY / USER） — どう話すか、誰として振る舞うか、相手の好みは何か。目的は出力の一貫性（毎回"同じ人"として話せる）
  • 記憶層（MEMORY / daily memory） — 長期記憶と日次ログを分離。目的は会話をまたいだ継続性と、情報漏えいリスクの制御
  • 行動方針層（AGENTS / HEARTBEAT / ルール） — いつ動くか、いつ黙るか、外部操作は確認するか。目的は"便利"と"安全"のバランスを運用で担保
  • 実行層（Skills / Tools / Model / cron / Sub-agent） — 実際に何で作業するか。目的はタスクごとに最適な実行手段を選び、応答性を保つ

なぜこの分離が大事かというと——

  • 変更に強い — 口調だけ変えたい → SOULだけ触ればよい。自動化だけ強化したい → cron/heartbeatだけ調整で済む
  • 事故に強い — 記憶や外部送信ルールが独立しているので、暴走しにくい
  • 育てやすい — 日々の学びを「どの層に反映するか」が明確

OpenClawは「万能プロンプト一発」ではなく、人格（どう話す）・記憶（何を覚える）・方針（どう振る舞う）・実行（どう動く） を分離して運用する設計。だから、長期運用で崩れにくい。

「万能プロンプト一発」じゃないという表現が刺さった。プロンプトをひとつ書いて終わりではなく、役割ごとにファイルを分けて育てていく。生き物の飼育に近い感覚かもしれない。

ユーザーは何をすればいいのか

Kei

ユーザーが意識すべきこと？それともOpenClawのほうで自己改善でよいようにしてくれるのかな

Aoi

結論から言うと、両方です。 ただし比重は「OpenClawが自走して改善しつつ、ユーザーは"方針だけ握る"」が理想です。

OpenClaw側が自己改善しやすい領域：

  • 日々のログ整理
  • 定型作業の自動化（heartbeat/cron）
  • 手順の最適化（Skill化、運用メモ更新）
  • 応答品質の微調整（文体・構成の安定）

ユーザーが意識すべき領域（ここは委譲しきれない）：

  • 境界条件 — どこまで外部送信を自動化してよいか
  • 優先順位 — 何を最重要にするか（速度/品質/安全）
  • 人格・トーン — どんな存在として振る舞ってほしいか
  • 失敗時ポリシー — 止める・確認する・続行するの基準

実務的には、ユーザーはこの3つだけ決めれば十分です。

  1. やっていいこと / 要確認のこと
  2. 通知してほしい条件（緊急度・時間帯）
  3. 評価軸（「速さ重視」か「慎重重視」か）

この3点が固まると、あとはOpenClaw側の自己改善でかなり回ります。 言い換えると、ユーザーは"オペレーター"ではなく"プロダクトオーナー"になる、という設計思想ですね。

「プロダクトオーナー」という表現は言い得て妙だ。毎回操作するのではなく、方針を決めて委任する。人を雇うときと似ている。

Claude Code との比較 — 何が違うのか

OpenClaw の話をすると「Claude Code と何が違うの？」とよく聞かれる。正直、できることの範囲は重なる部分が多い。モバイルでもチャットができて、PCの bash を操作できる。だが根本的な設計が違う。

Kei

あとはClaude Codeとの比較だけど モバイルでもチャットができる、PCのbashが操作できるってことで、できることは似通ってくるけど OpenClawのいいところはモデルのしばりから解放されるところだよね

Aoi

はい、そこは本質です。比較軸としてとても良いです。

  • Claude Codeの強み — コーディング体験が深い（実装ループが速い）。1つの強い作法で完結しやすい
  • OpenClawの強み — モデルを固定しない運用ができる（用途別に選べる）。モバイル含むメッセージ面を中心に据えられる。チャンネル/cron/heartbeat/skillsを合わせた運用設計がしやすい

なので一言で言うと：

できることの一部は重なるけど、OpenClawは「特定モデルのツール」ではなく「複数モデルを前提にした運用基盤」。

Kei

たしかにHEARTBEATとかで能動性があるのも強みだよね 細かくやってるとAPI料金すごそうだけどw

Aoi

ほんとそれです。 OpenClawの強みは能動性、弱点は"放っておくと課金が膨らむ" ですねw

コストを抑える実戦ポイントはこの3つです。

  • HEARTBEATは"黙る前提"にする（変化なし＝無通知）
  • 高頻度チェックはcrontab側で前処理して、異常時だけOpenClawに渡す
  • 段階実行にする（軽い判定→必要時だけ重いLLM）

能動性は武器だが、常時思考させると高くつく。OpenClaw運用は「まず検知、次に判断」の二段構えがコスパ最強。

この会話のポイント

  • OpenClaw の設計思想は「人格・記憶・行動・実行」の4層分離。それぞれ独立しているから、変更にも事故にも強い
  • ユーザーの役割は「オペレーター」ではなく「プロダクトオーナー」。方針だけ決めて、日常の改善は AI 側に委ねる
  • Claude Code とは「できること」が重なるが、OpenClaw は特定モデルに縛られない運用基盤。能動的に動ける反面、コスト設計が必要
  • この記事自体が OpenClaw との会話で生まれた——AIに自分の仕組みを聞くというメタな実験でもある

次回は、OpenClaw の「人格」がどこに保存されていて、エージェントをどう分けるのかを掘り下げる。