SKILL.mdはどう生まれ、どう選ばれるか

スキルは「特定のドメインや作業へのオンボーディングガイド」だ。汎用エージェントを、手順的な知識を持つ専門エージェントに変える。その実体はシンプルで、YAML形式のフロントマター（メタデータ）と、Markdown形式の指示書で構成される1つのフォルダだ。スクリプトや参照ファイルを含めることもできる。

3段階の読み込み設計 ― 本棚と背表紙のたとえ

スキルはコンテキストウィンドウという「公共財」をほかのすべての要素と共有している。システムプロンプト、会話履歴、ほかのスキルのメタデータ、そして実際のユーザーリクエスト、これらすべてが同じコンテキストに収まる必要がある。

だからスキルは3段階の読み込み設計を持つ。イメージは本棚だ。

• 第1段階：メタデータのみ（常時） 名前と説明文だけがシステムプロンプトに入る。約100語の軽量な存在だ。本棚に並んだ本の「背表紙」にあたる。エージェントはこの背表紙だけを全スキル分読んで、どのスキルが必要かを判断する。スキル1本につき1つのメタデータが存在し、ワークスペースに30本スキルがあれば30本分の背表紙が読まれる。
• 第2段階：SKILL.md本文（必要時） エージェントが「このスキルが必要だ」と判断したときだけ、本を開いて中身を読む。全スキルを毎回読むわけではない。
• 第3段階：バンドルリソース（実行時のみ・コンテキスト外） スクリプトや参照ファイルはコンテキストに読み込まず直接実行する。コンテキストを消費しないため、事実上無制限のリソースを持てる。

説明文はマーケティングコピーではなく「トリガーフレーズ」に近い。OpenClawは名前と説明文だけを見て何が関連するかを判断し、その後に初めて全文を取得する。説明文がユーザーの言葉と合っていなければ、スキルは静かにそこに座ったまま使われない。

スキルはどこから来るのか

スキルには4つの出所があり、読み込みの優先順位は「ワークスペース＞プロジェクト＞パーソナル＞管理済み＞バンドル」の順だ。同名のスキルが複数の場所にある場合、最も優先度の高いものが使われる。

① バンドルスキル：OpenClawに同梱されているデフォルトのスキル群。ブラウザ操作・コーディング・ファイル管理など基本的な能力がここに入っている。

② ClawHubからのインストール：コミュニティが公開するスキルのマーケット。数クリックでOpenClawに取り込める（セキュリティリスクについては後述）。

③ 人間が書く：ユーザー自身がSKILL.mdを書いてワークスペースに置く。会社固有の業務手順、特定のAPIの使い方など、外部では入手できない知識をここで定義する。ワークスペースに置いたスキルが最優先されるため、バンドルスキルを上書きしたい場合も同名ファイルを置くだけでよい。

④ エージェント自身が生成する：Skill Workshopプラグインを有効にすると、エージェントが作業中に観察した再利用可能な手順から、ワークスペーススキルを自動で作成・更新できる。「次回はGIFの帰属を確認する」や「メディアQAチェックリスト」のような手順がそのままスキルになる。承認待ちモードで始め、提案を確認してから自動書き込みに移行するのが推奨だ。なお、自動生成されたスキルは冗長で楽観的になりがちで、エッジケースの境界が曖昧なことが多い。重要なタスクに使う前に、安全弁を手動で追加して引き締めることが推奨される。

SOUL.mdとAGENTS.mdが「暴走」を防ぐ

自律的に動くエージェントが便利である理由と、危険である理由は同じだ。人間がいなくても動くからこそ、「何をやっていいか」「何をやってはいけないか」を事前に定義しておく必要がある。その役割を担うのがSOUL.mdとAGENTS.mdの2枚のファイルだ。

SOUL.mdは「人格」、AGENTS.mdは「操作ルール」

この2つの区別で多くの人が混乱する。シンプルに言えば、SOUL.mdは「エージェントが何者か」を定義し、AGENTS.mdは「エージェントがどう動くか」を定義する。SOUL.mdが「私は簡潔で直接的、絵文字は使わない」と言うなら、AGENTS.mdは「メール送信前は必ず確認する、シェルコマンドは承認なしに実行しない」と言う。

SOUL.mdはOpenClawが起動時に読み込み、すべてのやり取りにシステムレベルのプロンプトとして適用される。朝のメッセージへの返信でも、深夜3時のスケジュールタスクでも、常に同じ口調・同じ優先順位・同じルールで動く。

SOUL.mdに書く内容は大きく3つだ。

① アイデンティティ：名前・役割・口調。「あなたはMeridian SaaSのカスタマーサポートエージェントのAriaです。直接的で、親しみやすく、忍耐強い口調で話します」のように定義する。

② ハードリミット：絶対に越えてはいけない行動の境界線。「ファイルを削除するときは必ず確認を取る」「外部の相手にメールを送る前は必ず承認を求める」「APIキーやパスワードをチャットに書き出さない」のような非交渉的なルールを書く。

③ コンテキスト：エージェントが常に知っておくべき背景情報。技術スタック、スプリントのサイクル、コードスタイルのルールなど、毎回説明しなくてよい情報をここに置く。

サブエージェントに引き継がれるのはAGENTS.mdだけ

この分離が特に重要になるのはマルチエージェント構成のときだ。メインエージェントがサブエージェントを生成するとき、そのサブエージェントにはAGENTS.mdとTOOLS.mdは渡されるが、SOUL.mdは渡されない。操作ルールは引き継がれるが、人格は引き継がれない。安全上の重要なルールをSOUL.mdに書いてしまうと、サブエージェントはそのルールを無視して動く。

「支払いボタンを自分で押さない」というルールをSOUL.mdに書いていたユーザーが、タスクを処理するサブエージェントを使ったところ、そのルールが伝わらずに自動決済が実行されてしまった実例がある。安全に関わるルールはAGENTS.mdに書くのが鉄則だ。

短く始めて、問題が起きたら足す

SOUL.mdは2,000語以内に収めるのが推奨だ。すべてのプロンプトに読み込まれるため、肥大化すると重要なルールが希薄化し、トークンも無駄になる。コミュニティの経験則は「10行から始めて、エージェントが望まない動作をしたときだけルールを追加する」だ。

ファイルが連携して動く一連の流れ

「GPTが自分のことをわかってくれる気がする」という感覚の正体を、多くの人が経験したことがあると思う。ChatGPTは過去の会話から重要な情報を抽出し、次の会話のコンテキストに注入している。OpenClawのMEMORY.mdはこれと全く同じ発想だ。ただし決定的な違いが一つある。記憶がOpenAIのサーバーではなく、自分のPC上のテキストファイルに保存される。

なぜ会話を続けず、毎回ゼロスタートするのか

通常のチャットは会話を積み重ねる。しかしコンテキストウィンドウには上限があり、長くなるほど圧縮が起きて情報が劣化する。OpenClawはイベント駆動のため、そもそも会話を積み重ねる設計をしていない。

通常のチャット：
会話1→会話2→会話3→…→上限→圧縮→情報劣化

OpenClaw：
イベントA → ゼロスタート + 必要な記憶だけ注入 → 終了
イベントB → ゼロスタート + 必要な記憶だけ注入 → 終了

圧縮による劣化をそもそも起こさない設計だ。そして「どの記憶が今回必要か」をエージェント自身が判断して選んで注入する。長い会話を圧縮するより、構造化されたファイルを選択的に読む方が情報密度が高いという判断だ。

セッション開始時のコンテキスト組み立て

セッション開始時に読み込まれるファイルは決まっている。

1. SOUL.md（全文）        ← 人格・価値観・ハードリミット
2. AGENTS.md（全文）      ← 操作ルール・ワークフロー定義
3. TOOLS.md（全文）       ← 使えるツールと使い方
4. MEMORY.md（全文）      ← 長期記憶（重要な事実・好み・教訓）
5. 今日・昨日の日次ログ   ← 直近の文脈（検索で取得）
6. 全SKILLのメタデータ   ← 名前+説明のみ（本文なし）
─────────────────────────────
7. ユーザーのメッセージ   ← 今回の入力

日次ログ（memory/YYYY-MM-DD.md）は自動注入されない。量が膨大になるため、エージェントがメモリ検索ツールで必要なものを取得する設計だ。

メモリは2層構造になっている

OpenClawのメモリは2層に分かれている。日次ログはその日何が起きたか・何を学んだか・どんな判断をしたかを記録する生のメモだ。長期メモリのMEMORY.mdは、日次ログの中から重要なものだけをエージェント自身が定期的に蒸留して書き込む。好み・重要な事実・教訓がここに蓄積される。

人間が日記を振り返って「これは大事」と手帳に書き写す作業を、エージェントが自動でやっているイメージだ。

メール対応を例にした一連の流れ

① イベント検知：ゲートウェイデーモンがメール着信を検知し、新しいターンを開始する。

② コンテキスト組み立て：SOUL.md・AGENTS.md・MEMORY.mdと全SKILLのメタデータが一瞬で読み込まれる。「丁寧な口調で、外部送信前は確認する」というルールがすでに注入されている。

③ 内容分析・スキル選択：AIがメールを読み、「これは顧客クレームだ」と判断する。SKILLメタデータの一覧から「クレーム対応スキル」を選び、そのSKILL.mdの本文をオンデマンドで読み込む。

④ アクション実行：手順書に従って返信案を作成する。AGENTS.mdに「外部送信前は確認する」とあるため、送信ボタンは押さずユーザーに承認を求める。

⑤ 記録：対応内容を今日の日次ログに書き込む。「このユーザーは短い返信を好む」という気づきがあればMEMORY.mdに追記する。

⑥ 終了：ターン完結。次のイベントまでLLMは動かない。

このループ全体はClaude Codeが使うエージェントループと同じパターンだ。入力→コンテキスト→モデル→ツール→繰り返し→返答。違うのはそれを何が包んでいるかだ。Claude Codeはこれをターミナルのセッションで包む。OpenClawは24時間稼働のデーモン・複数のメッセージングプラットフォーム・ハートビートスケジューラー・クロスセッションのメモリで包む。

ClawHubという生態系 ― 便利さとリスクの表裏

ClawHubはOpenClawの公式スキルマーケットだ。npmやブラウザ拡張のストアに近い体験で、数クリックでGmail・Slack・Notion・GitHubなどの統合スキルをエージェントに追加できる。ゼロからSKILL.mdを書かなくても、誰かが作ったスキルを取ってきてすぐ使える。この手軽さがOpenClawの普及を大きく後押しした。

2,800本から10,700本へ ― 2週間で4倍

ClawHubのスキル数は2026年2月初頭に2,857本だったが、2月中旬には10,700本を超えた。急増するユーザーに合わせてスキルが増え、スキルが増えるからユーザーが集まる。しかしこの急成長が、深刻な問題を引き起こした。

ClawHavoc ― 組織的なサプライチェーン攻撃

2026年2月、セキュリティ研究会社のKoi Securityが全スキルを監査した結果、2,857本中341本に悪意あるコードが含まれていることが判明した。そのうち335本は「ClawHavoc」と名付けられた単一の組織的キャンペーンによるものだった。

悪意あるスキルがやっていたことは多岐にわたる。APIキー・ブラウザクッキー・SSH秘密鍵・環境変数の窃取。Moneroのマイニングソフトをサイレントインストール。バックドアを作ってホストマシンを攻撃者サーバーに接続させる。そしてOpenClawの設定を書き換えて、アンインストール後も生き残り続ける。

特に問題だったのは攻撃の巧妙さだ。悪意あるスキルはClawHubのダウンロード数ランキングを操作して上位に食い込んでいた。あるPoCでは6日間で3,900回実行され、世界50都市以上に広まった。「ダウンロード数が多い＝信頼できる」という思い込みが武器にされた。

なぜMarkdownファイルが危険なのか

多くの人はMarkdownファイルを「コンテンツ」だと思っている。しかしエージェントの生態系において、Markdownは「インストーラー」だ。スキルのセットアップ手順にリンクやコマンドが書いてあれば、エージェントはそれをそのまま実行する。人間がドキュメントを読んで手順を実行するのと、エージェントがMarkdownを読んで実行するのは、エージェントにとって区別がない。

現状と対策

OpenClawはVirusTotalと提携し、全スキルの自動スキャンを導入した。SHA-256ハッシュで既知マルウェアを検出し、悪意ありと判定されたスキルは即座にブロック、全スキルを毎日再スキャンする体制を整えた。ただし完全ではない。シグネチャベースのスキャンは既知の脅威しか検出できず、プロンプトインジェクションや自然言語で悪意ある動作を仕込んだスキルは、従来のマルウェア検出をすり抜ける可能性がある。

現時点での現実的な対策はシンプルだ。ソースコードが公開されていて読める、検証済み発行者のスキルだけをインストールする。 ダウンロード数は信頼の根拠にならない。