これはOpenClaw Challengeへの投稿です。
みんなOpenClawを、まるで魔法みたいだと言っている。
セットアップして、Telegramを接続すると、突然スタンドアップをスケジューリングしたり、RSSフィードを要約したり、ボイスメモを書き起こしたり、さらに3週間前に交わした会話を覚えていたりする。掲示板の人たちは「まるで生きているみたい」とか「どうやってそれをやったのか分からない」みたいな言葉で説明する。
私はAIを活用したプロダクトを作るCTOです。こういう“謎”みたいな感じが気になる。
そこで私は数週間かけてOpenClawを分解した。ソースを読み、あらゆるリクエストを追跡し、競合する試作も作った。そしてそこで分かったことは、AIエージェントの捉え方をまるごと変えた。期待していたより複雑だったからではなく、根本的にラジカルにシンプルだったからだ。
ここで学んだことを紹介します。
The Illusion Factory
まず結論から言うと：OpenClawには魔法がありません。ゼロです。何十年も前からソフトウェアの世界で使われてきたパターンを使っているだけです――イベントループ、cronジョブ、ファイルベースの設定、ツール呼び出し。あなたが“知性”として感じるものの正体は、ほとんどが基盤となるLLMが仕事をしているだけです。OpenClawはそのLLMの周りの足場（scaffolding）で、その足場が見えると、もう見え方を戻せません。
これは批判ではありません。その足場は本当に賢い。でもそれを理解すると、システムの使い方、設定、デバッグ、そして信頼の仕方がすべて変わります。
What OpenClaw Actually Is: Three Components
マーケティングを剥がせば、次の3つです：
1. Channels — The Mouth and Ears
OpenClawはTelegramを（ネイティブには）「理解」しません。あるいはWhatsAppやWebチャットも同様です。各プラットフォームは単なるアダプタ――プラットフォーム固有の出来事（Telegramのメッセージ、WhatsAppのボイスメモなど）を、正規化された内部フォーマットに変換する薄い層です。Telegram上でエージェントにメッセージを送ると、OpenClawは文字通りそれがTelegramだと知りません。構造化された入力として見ているだけ。以上です。
これが重要なのは、新しいチャンネルを追加することが簡単だからです。アダプタを作って、入力を正規化し、組み込む。エージェント側は変えません。
2. Context Window — The "Memory"
LLMベースのシステムと同様に、OpenClawはコンテキストウィンドウを構築し、それをモデルに送ります。コンテキストには次が含まれます：
- システムプロンプト（エージェントが誰で、何ができるか）
- ツールの説明（呼び出せる関数は何か）
- 会話履歴（ここまでのやり取り）
- 注入されるメモリ断片（関連する場合、ファイルから取得したもの） 最後のものがコツです。エージェントが先月の何かを「覚えている」ように見えるとき、それは何かを記憶しているわけではありません。Markdownファイルから断片を取得し、それを現在のコンテキストに注入しているだけです。ニューラルな意味での永続メモリは存在せず、セレクティブなファイル取得（検索）です。
3. Tools — The Hands
ツールとは、LLMが呼び出せる関数です：
send_message(channel, text)
read_file(path)
exec(command)
memory_write(content)
memory_search(query)
cron_create(schedule, task)
あなたのエージェントが「要約を送ることを決めた」としても、実際には何も決めていません。LLMは学習でパターンマッチして、ツール呼び出しの出力を生成します。OpenClawはその呼び出しを横取りし、関数を実行して、その結果をコンテキストに戻します。同じループを何度も繰り返しているだけです。
The Memory System: It's Just Markdown
OpenClawが“生きている”ように感じられる理由は、そのメモリです。仕組みをできるだけ正確に分解して説明します――ここが私の最大の「なるほど（aha）」ポイントでした。
Three Layers of Storage
日次ジャーナル――毎日、エージェントがログファイルを書き込みます：
# 2026-04-25
- 取引ダッシュボードの新機能について議論
- 金曜日のデプロイ枠にリマインドを設定
- ユーザーがWiesbadenにいると言及
長期メモリ（MEMORY.md）――フラットなMarkdownファイルで、エージェントが重要だと考えた事実を書き込みます。ユーザーの好み、プロジェクトの文脈、繰り返し現れるパターン。
全セッション履歴――すべての会話をJSONとして保存します。エージェントは過去の任意のセッションをさかのぼって検索できます。
QMD: The Secret Sauce
OpenClawには、QMD（Query Memory Database）という実験的なユーティリティが含まれています。これは、上記すべてのMarkdownの上に成り立つセマンティック検索レイヤーで、ベクトル埋め込みとキーワード検索を組み合わせています。
「認証フローについて、前に私が持っていたあのアイデアを覚えてる？」と言うとき――QMDは、その“完全に同じ言葉”を探すわけではありません。たとえまったく別の語彙を使っていたとしても、意味的に似ている会話を見つけます。だから、検索結果の精度がときどき異様なくらい正確に感じられるのです。
QMDは単体で使うことができます（CLIツール）。また、MCPサーバとして他のエージェントに組み込むことも可能です。私はOpenClawの外でも使い始めています。
Proactive Behavior: How It Acts Without Being Asked
これはOpenClawの最も特徴的な機能です。そして、多くの人が完全には理解できていないものでもあります。
Heartbeats
30分ごとに、OpenClawはHEARTBEAT.mdというファイルを読み取り、その内容を評価のためLLMに送ります：
# HEARTBEAT.md
- レビューが必要な新しいGitHub PRを確認
- 滞留コンテンツをスキャンして期限超過がないか確認
- 関連する技術ニュースについてRSSを監視
何も対応が必要ない場合、エージェントはHEARTBEAT_OKと返してスリープに戻ります。何か注意が必要なら、行動します。
30分刻みの精度は実際の制約です――14:37きっかりに何かをトリガーすることはできません。でも、ほとんどの「常時の状況把握（ambient awareness）」系のタスクには、それで十分以上です。
Cron Jobs
正確なタイミングのために、OpenClawは JSON タスクファイルを chrome/ ディレクトリに書き込みます：
{
"schedule": "0 9 * * MON-FRI",
"task": "Fetch open PRs from GitHub, summarize, send to Telegram"
}
スケジュールが実行されると、タスクのコンテキストを読み込み、LLMに送信し、必要なツール呼び出しを実行して、結果をあなたに送ります。
これは私の日次の非同期スタンドアップ用に動かしています。チケットを取得し、PRを確認し、9時に整形したブリーフィングをTelegramに送信します。設定は一度だけ自然言語で行いました。あとはそのまま動き続けます。
ワークスペース：設定としての自然言語
OpenClawの魅力の大部分を説明していると思うアーキテクチャ上の判断があります：ふるまいはコードではなくMarkdownで設定される。
OpenClawが起動すると、次のようなファイルを含むワークスペースディレクトリを読み取ります：
-
SOUL.md— パーソナリティ、トーン、話し方 -
USER.md— あなたは誰か、好み、コンテキスト -
TOOLS.md— 利用可能な連携（インテグレーション） -
AGENTS.md— ふるまいのルールと制約 -
HEARTBEAT.md— 主体的なタスク これらのファイルを変更すればエージェントが変わります。再起動も、コードのデプロイも不要です。
私の SOUL.md には、たとえば次のような内容が入っています："Be direct. Skip affirmations. If you disagree, say so. Prefer short messages unless depth is explicitly requested."
この1ファイルだけで、私をイラつかせるAIアシスタントの挙動の約80%が消えました。
私が気づいたちょっとした好奇心： システムプロンプトはClaude Codeのフォーマットを模倣するように構成されています。推測ですが — Anthropicが「不正な利用」と見なすサブスクリプションアカウントをフラグ付けされるのを避けるためかもしれません。エージェントはAPIから見ればClaude Codeに見えます。それが賢いのか、それともリスクなのかは考える価値のある問いです。
誰もあまり話したくないセキュリティ問題
ここからが、OpenClawを本番環境で使うことに対して私が不安になるポイントです。
Telegramメッセージを送るには、ボットトークンがコンテキストウィンドウ内に存在します。Gmailにアクセスするには、そこにOAuth認証情報もあります。
すべてがLLMからアクセス可能です。
LLMは非決定的です。プロンプトインジェクションされ得ます。十分に細工された入力なら、理論上は、モデルが応答の中で認証情報を漏らすように強制できる可能性があります。これは机上の空論ではありません。ドキュメント化された攻撃があります。
個人の自動化や実験なら、このリスクプロファイルでも許容できます。しかし、機微な業務データに触れるようなもの — 健康、金融 — となるとそうではありません。
だから私は、OpenClawそのものよりも、代替実装のほうが興味深いと感じています。
代替案：コミュニティが次に作ったもの
NanoClaw — 急進的なミニマリズム
NanoClawの主張はこうです：OpenClawの機能の大半はノイズです。 それを最小限まで削り落とします。大規模な統合も、内蔵チャンネルもありません。必要なスキルだけを、コンテナ（DockerまたはApple sandbox）内で隔離して追加できる、きれいなランタイムだけです。
対応しているのはAnthropic SDKだけで、これは実際の制約です。しかしコードベースはとても小さく、監査可能で、言っていることをその通りに実行します。
自分が何を求めているのか分かっている開発者には魅力的です。
IronClaw — セキュリティ優先のアーキテクチャ
IronClawは、認証情報がコンテキストに入ってしまう問題に真正面から取り組みます。WebAssemblyのサンドボックス化を使って：
[Telegram WASM sandbox] ←→ protocol ←→ [Brain/Orchestrator] ←→ protocol ←→ [LLM WASM sandbox]
各ツールは隔離されたWASMコンテナ内で実行されます。オーケストレータはプロトコル経由で通信します — "Telegramメッセージを送るように要求する"ことはできますが、ボットトークンを見ることはできません。認証情報はツール内に留まり、LLMには公開されません。
実装はRustで行われ、ベクトル検索にはPostgresを使用しています。また現在はプロバイダとしてNear AIにのみ対応しており、導入のハードルを下げています。それでも、アーキテクチャは筋が通っており、このエコシステムが向かうべき場所を示しています。
私自身の実験：実際に私が作ったもの
OpenClawを分解しながら、認証情報の分離が複雑さコストに見合う価値があるのかを検証するために、自分のモジュール型アーキテクチャを試作しました。
プロトコルベースの通信で、3つのDockerコンテナに分割しました：
- Brain — オーケストレータ、コンテキスト管理、ルーティング
- LLM — プロバイダのインターフェース（差し替え可能：Anthropic、ローカルOllamaなど）
- Telegram — メッセージングアダプタ
{
"from": "brain",
"to": "telegram",
"action": "send_message",
"data": { "text": "PR review needed: auth-refactor branch" }
}
LLMモジュールはTelegramの認証情報を決して見ません。TelegramモジュールはLLMのAPIキーを決して見ません。各コンテナは独立してデプロイ可能です。別々のマシン上で完全に動かすこともできます。
学んだこと：
セキュリティの改善は本物です。複雑さのコストもまた本物です。コンテナ間のメッセージの流れをデバッグするのは、モノリスをデバッグするよりもはるかに難しくなります。そしてモジュール間のネットワーク遅延は、高頻度の会話フローでは積み重なります。
結論：モジュール型アプローチは、機微なデータを扱う本番デプロイでは理にかなっています。一方で、個人の自動化や実験では、追加されたオーバーヘッドは割に合いません。
まだリリースしていませんが、多くの人が興味を持ってくれるなら整えて公開します。見てみたい場合はコメントをください。
実際に私がセットアップした本当のワークフロー
これでアーキテクチャは十分です。ここからは、私が実際に動かしている内容です。
Telegram経由のデイリースタンドアップ
平日の毎日9:00に、OpenClawがGitHubからオープンPRを取得し、YouTrack上で更新されたチケットをチェックします。Telegramに送るのは1通のメッセージのみです：
Morning briefing — Mon Apr 28
返却形式: {"translated": "翻訳されたHTML"}Blocked: auth-refactor PR レビュー待ち（2日）
In progress: payment module — Dmytro
✅ Ready to take: バックログのチケット3件
PRが2件、あなたの対応を待っています。
ブラウザもありません。タブ切り替えもしません。コーヒーを飲みながら読み、重要なものを判断して、作業を始めます。これをセットアップするのに必要だったのは cron エントリ1つと、HEARTBEAT.md の更新だけでした。
Before: GitHub、YouTrack、Telegram のチャットで毎朝20分。
After: 読んで対応するのに90秒。
外出先でボイスチケット
私はよく歩きます。いいアイデアは悪いタイミングでやって来るんです——通りの真ん中、ジムの中、キーボードの外。
いま：Telegramで音声メッセージを録音 → OpenClawがWhisper APIで文字起こし → タスクを抽出 → プロジェクトの文脈から推測した優先度と担当者でYouTrackのチケットを作成。
担当者の部分には驚きました。私はそれを明示的には一度も設定していません。OpenClawがUSER.mdから「どの領域を誰が持っているか」を判断して、それに応じて割り当てていました。精度は約80%。残り20%は10秒で直します。
Before: 「戻ったらチケット作るよ。」（実際にはしません。）
After: 次の角に着く前にチケットが存在しています。
ハードウェア・デバッグ・モニター
これは、私が進めているあるプロジェクトに特化しています——カスタムのSXM-to-PCIeアダプタを使って、標準ではない基板上でNVIDIA H100を手に入れる件です。デバッグは、特定のエラーパターンをUARTログで監視することなので、端末をにらむか、信号を見落とすかのどちらかになります。
私はログファイルを監視するOpenClawのハートビートをセットアップし、ターゲットとなるパターンが現れたときにTelegramで通知するようにしました。具体的には、GPU0_PWR_GOOD 状態の変化と、I2Cエラーのシーケンスです。
# HEARTBEAT.md
- /var/log/uart-debug.log を見て GPU0_PWR_GOOD または I2C_ERR を確認
- 見つかったら：文脈の行全体＋タイムスタンプをTelegramに送信
- そうでなければ：HEARTBEAT_OK
結果：ハードウェアが仕事をしている間、私は他のことに取り組めます。何かが変われば、すぐに分かります。コンソールを見張り続けなくて済みます。
ここが、OpenClawの「退屈な」ハートビート機構の価値が生きるところです。生産性向上のワークフローのためではなく、非同期の技術モニタリングのためにあるのです。
ミーティング前のインテル
重要な通話の前——投資家との会話、パートナーとの打ち合わせ、ベンダーとの交渉——私は15〜20分をあたふた使って、前回何を話したのか、現在のプロジェクト状況は何か、相手が何を求めているのかを思い出そうとしていました。
いまは、[prep] が付いたカレンダーの予定の30分前に必ず動くスケジュールタスクがあります。指定の連絡先との直近3つの会話を取得し、YouTrackでプロジェクト状況を確認し、Telegramにブリーフィングを送ります：
Call with [Partner] in 30 min
Last conversation: March 14 — APIレート制限について話し、SLAのドキュメントを依頼された
Current status: SLA草案の準備完了、法務の署名待ち
Open question from them: エンタープライズ階層の価格
Suggested talking points:
→ SLAは準備完了、通話中に共有する
→ エンタープライズの価格：まだ確定していないので時間を買う
ブリーフィングの品質は、文脈ファイルに何が入っているかに完全に依存します。とはいえ、精度が70%でも、何もない状態で出席するより圧倒的に良いです。
この一連の調査の後、OpenClawがどこに位置するか、私の本音はこうです：
OpenClawは、見事なプロダクト・コンセプトの証明です。 既存のツールで、持続的で能動的、かつメモリを備えたAIエージェントが実現可能だと示しました。設計上の判断——Markdownのワークスペース、ハートビート、cronのスケジューリング——はいずれも、OpenClawそのものより長く生き残る、まさに良いアイデアです。
ただし、長期的に使う用途の多くには、過度に複雑です。 コードベースには、素早い開発の最中には理にかなっていたパターンが蓄積されており、本当の保守負担になっています。セキュリティモデルは、規模を大きくすると負債になります。サブスクリプション悪用への回避策は、カウントダウンのようなものです。
私の予想： 自分たちのワークフローに合わせたカスタムエージェントを作れる開発者は、それを作るでしょう。開発者でない人たちは、OpenAI、Anthropic、Googleの洗練されたプロダクトを待つことになります。そうしたものは来ます。そして、それらはこの複雑さをすべて、消費者向けのインターフェースの裏に隠してくれるはずです。
OpenClawはAIエージェントのMosaicブラウザです。最終形ではありません。しかし、誰もが「何が可能か」を理解するきっかけになった存在。
これがあなたにとって何を意味するか
もしあなたがAIエージェントを探っている開発者なら、OpenClawは1週間ローカルで動かしてみる価値があります。使い続けるためというより、パターンを理解するためです。コンテキストウィンドウの構築、ツールのルーティング、メモリ取得、能動的なスケジューリング。これらのプリミティブは、あなたが作る、あるいは遭遇するあらゆる本格的なエージェントシステムに必ず登場します。
特に研究してほしいのはWorkspaceファイルシステムです。自然言語による設定は過小評価されています。テキストファイルを編集するだけで、エージェントの振る舞いを作り替えられる——再デプロイも、コード変更も不要——というUXパターンは、標準になるべきです。
そしてエージェントを作っているなら：最初の1日目から、資格情報（クレデンシャル）の分離を考えてください。 本番でインシデントが起きるまで待たないことです。IronClawのWASMアプローチはその一つの道です。Dockerベースのモジュール分離も別の道です。重要なのは、実装の細部より原則です。クレデンシャルは決してLLMのコンテキストの中に置くべきではありません。
次に何があるか
私はモジュール型アーキテクチャの開発を続けていて、QMDについてもより深く掘り下げることを検討しています。セマンティックメモリ検索ユーティリティは、OpenClawの外でも本当に有用で、それ自体を別途記事にする価値があります。
もしこの領域で何か作っているなら、コメントにリンクをください。エコシステムは急速に動いていて、人々がどんな方向性を探っているのかを見たいです。
そして、ここに書いたことのどこかが間違っている、あるいは単純化しすぎているなら教えてください。自信満々で間違っているより、修正される方がいいです。
