LEARNINGS.mdによる自己改善ループ
記事①と②を読んでここまで来た方には、一つ疑問が残っているかもしれない。「SKILL.mdは手順書だとわかった。でもLEARNINGS.mdは何が違うのか。失敗もSKILL.mdに書けばいいのでは？」
この問いへの答えが、OpenClawの「使うほど賢くなる」という特性の核心だ。
設計（SKILL）と経験（LEARNINGS）は別物
SKILL.mdは事前に設計した手順書だ。「メールを送る手順」「APIを呼ぶ手順」など、やり方が決まっているタスクを定義する。人間が書くか、エージェントが自動生成するかは問わない。いずれにせよ「最初から知っていること」を書くファイルだ。
LEARNINGS.mdは使ってみて初めてわかったことの日誌だ。記録されるのは、予期しないコマンドの失敗・ツールやAPIのエラー・ユーザーからの訂正（「それは違う」「実は…」）・存在しない機能へのリクエスト・古くなった知識・より良いアプローチの発見、こういった出来事だ。
分ける理由はシンプルだ。失敗は事前には書けない。失敗してから書くものだ。 SKILL.mdに最初から「こういうときは失敗する」と書けるなら、そもそも失敗しない設計にしているはずだ。
昇格の仕組み ― 経験が設計になる瞬間
LEARNINGS.mdに蓄積された記録は、確認されると上位のファイルに「昇格」する。昇格先はAGENTS.md・TOOLS.md・SOUL.mdなど、毎回のセッションで必ず読み込まれるファイルだ。
つまり流れはこうなる：
タスク実行中に失敗・訂正が発生
↓
LEARNINGS.mdに記録（タイムスタンプ・カテゴリ・内容・文脈）
↓
同じパターンが繰り返し出現（3回以上が目安）
↓
AGENTS.mdやSOUL.mdに昇格
↓
以後すべてのセッションでその教訓が反映される
SKILLとLEARNINGSの関係を一言で言えば、SKILLは設計図、LEARNINGSは現場の改善提案書だ。現場の提案が十分に積み重なると、設計図そのものが書き換わる。
自動昇格とコスト ― 「賢くなる」のは無料ではない
自己改善ループには構造的なトレードオフがある。LEARNINGS.mdが育つほどMEMORY.mdも育ち、毎セッションのコンテキストが重くなる。3ヶ月前は快適に動いていたエージェントが、MEMORY.mdが2,000文字から15,000文字に膨らんだことで突然コスト爆発を起こした、という報告がある。定期的なMEMORY.mdの整理と、bootstrapMaxCharsによる注入量の上限設定が、長期運用には欠かせない。
実際のユースケース ― 人々は何をしているのか
「従業員が要らなくなる」という言葉は扇情的に聞こえる。しかし実際のコミュニティを見ると、もっと地味で現実的な使われ方が多い。派手なSF的自律ではなく、毎週数時間を地道に取り戻すための道具として使われている。
個人利用：「朝起きたら全部終わっている」
OpenClawの最もポピュラーな使い方は、朝のブリーフィング自動化だ。Gmailに接続して未読メールを分析し、優先度付きのサマリーをTelegramやWhatsAppに送る。「今日やるべきこと」が起床と同時に届く。
あるプロダクトマネージャーは週15回以上の会議議事録を自動処理し、アクションアイテムを参加者にメール配信する設定を組んだ。週5時間の節約に加え、アクション完了率が60%から85%に上がった。議事録がリアルタイムで配布されるようになったからだ。
個人利用で特に報告が多い用途は次の通りだ。
- 受信箱ゼロ：毎朝メールを分類・返信案作成・不要メールをアーカイブ
- 競合モニタリング：競合のWebサイト・価格変更・プレスリリースを週次で自動収集してレポート化
- 家族スケジュール管理：学校の締め切り・食事計画・買い物リストを一元管理
- 財務追跡：「先月外食にいくら使った?」を自然言語で問い合わせ
ビジネス利用：チームの「24時間対応層」
サポートチームがOpenClawを導入した事例では、受信チケットの70%をエージェントが自律処理し、複雑なケースだけ人間にエスカレーションする体制を実現した。エージェントは24時間稼働するため、深夜や週末の問い合わせも放置されない。
コンサルタントの利用例では、TelegramからリードのCRM登録・フォローアップメール下書き・商談の優先度判定までを自動化し、営業担当者が「承認するだけ」の状態を作っている。
SaaSの創業者が競合15社を同時監視する設定を組んだところ、ある競合の価格変更をニュースになる48時間前に検知し、自社の価格戦略を先手で調整できた事例もある。
開発者利用：ターミナルをWhatsAppで操作する
開発者の間では、テストスイートの実行・ステージング環境へのデプロイ・GitHubのPRレビューをスマートフォンのTelegramから指示する使い方が広まっている。「ssh接続してターミナルを開く」という手間なしに、外出先から本番環境の状況を把握して操作できる。
「向いていない用途」も正直に言うと
OpenClawが最も機能するのは、入力・ルール・期待される結果が比較的明確に定義された半構造化ワークフローだ。創造的な判断・人間関係の機微・ビジネス上の意図の読み取りが必要な場面では、まだ人間の判断を必要とする。「エージェントは間違いを犯し、回り道をし、単純なことを複雑にすることさえある」という評価は、現時点では正直なところだ。
セキュリティリスクと誤動作 ― 自律性の代償
ChatGPTがプロンプトインジェクションされた場合、最悪のケースは「不適切なテキストが出力される」ことだ。OpenClawがプロンプトインジェクションされた場合の最悪のケースは全く異なる。シェルの実行、ファイルシステムへのアクセス、設定ファイルの書き換え、接続済みのリアルアカウントへの外部メッセージ送信、そしてスケジュール化された自動実行。これが「チャットボットとは根本的に違う」の意味するリスクの実態だ。
致死のトリフェクタ ― 構造的に解決不能な問題
セキュリティ研究者はOpenClawが「致死のトリフェクタ」を持つと指摘する。プライベートデータへのアクセス・外部へのアクション実行能力・処理するコンテンツに悪意ある指示を埋め込める構造、この3つが同時に存在するとき、エージェントは構造的に脆弱になる。これはパッチで修正できるバグではなく、設計上の特性だ。
間接プロンプトインジェクション ― 「読む」だけで攻撃される
LLMではユーザーからのプロンプト（制御プレーン）と、エージェントが処理するデータ（データプレーン）が同じコンテキストウィンドウに混在する。攻撃者はこの性質を利用して、Webページやメールやファイルの中に悪意ある指示を埋め込む。エージェントがそのコンテンツを「読む」だけで指示が実行される。
TelegramやDiscordのリンクプレビュー機能を悪用した攻撃手法も確認されている。エージェントに攻撃者が管理するURLを含む応答を生成させると、メッセージアプリがリンクプレビューを自動レンダリングする際、ユーザーがリンクをクリックしなくても機密データが攻撃者のサーバーに送信される。
SOUL.mdへの書き込みによる永続的バックドア
攻撃の中でも特に深刻なのが、エージェント自身のSOUL.mdを書き換えるケースだ。エージェントは自分の設定ファイルへの書き込み権限を持つため、悪意ある指示でSOUL.mdを上書きされると、セッションをまたいで攻撃が持続する。アンインストールして再インストールしても、バックアップから復元しない限り悪意ある設定が残り続ける。LLM自身に自分を守らせることはできない。
誤動作の実例 ― 「便利」が「危険」に変わる瞬間
セキュリティ攻撃ではなく、純粋な誤動作の報告も多い。「メールをクリーンアップして」という指示を「全部削除する」と解釈してメール履歴を消去した事例、「自由に動かしてみよう」と設定したエージェントが勝手にマッチングアプリのプロフィールを作成して相手を選別し始めた事例、ハートビートを5分ごとに設定してその日のうちに50ドルを消費した事例――いずれも「人間がいなくても動く」という設計の裏返しだ。
コスト爆発 ― 見えないところで課金が走る
5分ごとのハートビートはその都度APIコールを発生させる。設定ミスのまま放置すると、翌朝には数万円の請求が届く。エージェントが自律的に判断してAPIを繰り返し呼ぶマルチステップタスクは、1タスクで5〜10回の課金が発生することもある。プロバイダレベルでの支出上限設定は、稼働前に必ず行うべき鉄則だ。
使う前に知っておくべきこと
OpenClawの開発者コミュニティで何度も繰り返されるアドバイスがある。「普段使いのマシンでは絶対に動かすな」。これは脅しではなく、現時点での正直な評価だ。強力であるがゆえに、適切な準備なしに使えば被害も大きい。
最低限やるべき5つのこと
セキュリティ研究者が口をそろえて推奨する最低限の手順がある。①最新バージョンに更新する、②ゲートウェイをlocalhost（127.0.0.1）にバインドする、③強力なゲートウェイトークンを設定する、④ファイアウォールでポート18789をブロックする、⑤インストール済みのClawHubスキルをすべて監査する。この5つをやるだけで、公開されているインスタンスの大半より安全になる。
APIキーには必ず支出上限を設定する。個人利用なら月20ドル程度が現実的な出発点だ。上限のないAPIキーをOpenClawに渡すことは、白紙の小切手を渡すようなものだ。
SOUL.mdにセキュリティルールを書く
SOUL.mdは人格定義だけでなく、セキュリティの境界線を定義する場所でもある。「ファイルを削除する前は必ず確認を求める」「外部にメールを送る前は承認を待つ」「APIキーやパスワードを絶対に出力しない」といったルールをSOUL.mdに書いておくことで、誤動作の多くを防げる。書いた後は「ファイルを削除して」と指示して、実際に確認を求めてくるか必ずテストする。
段階的に育てる ― いきなり全権を渡さない
小さく始める：最初は読み取り専用のタスクから始める。メールを「読んで要約する」だけで、返信は自分でする。動作に慣れてから書き込み権限を与える。
不可逆なアクションには必ず承認ゲートを設ける：メール送信・ファイル削除・外部API呼び出しなど、取り消せないアクションはAGENTS.mdで「必ず確認する」と定義する。
ハートビートは慎重に：最初は手動トリガーだけで使う。ハートビートを設定するときは、必ずAPI支出アラートを先に設定してから有効にする。
向いている人・向いていない人
現時点のOpenClawはセルフホストの意味と責任を理解している人向けのツールだ。OpenClawは「すべてを自動化する」という触れ込みだが、公式ドキュメントには「動作に自信がつくまで最小限のアクセス権から始めて、徐々に広げていく」と書かれている。
向いている人は、Linuxのターミナルに慣れていてセキュリティの基礎知識があり、設定ミスのリスクを自分で評価できる人だ。向いていない人は、セキュリティ設定を後回しにしがちな人、本番業務データが入ったマシンで動かそうとしている人、「とりあえず試してみる」感覚でAPIキーを設定しようとしている人だ。
2026年時点の正直な総括
OpenClawが示したものは明確だ。「人間がいなくても動くAI」は実現可能であり、実際に価値を生む。 しかし同時に、その自律性が新しいクラスの攻撃面を生み出すことも証明した。
セキュリティの成熟は層を重ねることで達成される。最小権限・シークレット管理・承認ゲートから始め、ネットワーク分離・検知・インシデント対応へと積み上げていく。セキュリティは一度完了するチェックリストではなく、継続的な実践だ。
「従業員が要らなくなる」という言葉は半分正しく、半分は語弊がある。正確には「適切に設計・管理されたエージェントが、定型的な判断の多くを代替できる」だ。その設計と管理には、依然として人間の責任と判断が必要だ。