概要

記事①でOpenClawの「ファイルがエージェントそのもの」という設計を学びました。この記事では、その中核を担うSKILL.md・LEARNINGS.md・MEMORY.mdの3ファイルが実際にどう連携して「使うほど賢くなる」を実現しているかを掘り下げます。

• SKILL.mdは「やり方を知っている」、LEARNINGS.mdは「失敗から学ぶ」、MEMORY.mdは「あなたを覚えている」
• 3つは独立したファイルではなく、情報が上位ファイルへ「昇格」していく階層構造です
• この仕組みを理解しておくと、記事③のセキュリティ・コスト管理の話がより腑に落ちます

3つのファイルの役割を整理する

SOUL.mdがエージェントの「人格」なら、SKILL・LEARNINGS・MEMORYはエージェントの「スキル・経験・記憶」です。この3層が揃って初めて、OpenClawは単なる自動化ツールではなく「育つアシスタント」になります。

それぞれの役割を一言で表すとこうなります。

💡 初心者向け補足：この3つの関係は、新入社員に例えるとわかりやすいです。SKILL.mdは「業務マニュアル」、LEARNINGS.mdは「失敗ノート」、MEMORY.mdは「お客様カルテ」のようなものです。

SKILL.md ― 「やり方」を定義するファイル

SKILL.mdはOpenClawが特定のタスクを実行するための手順書です。「Gmailの未読メールを要約する」「GitHubのIssueをSlackに転送する」といったタスクごとに1つのSKILL.mdが存在します。

skills/
  gmail-summarize.md   ← メール要約スキル
  github-notify.md     ← GitHub通知スキル
  morning-brief.md     ← 朝のブリーフィングスキル
  ...（何十本も存在しうる）

重要なのは、SKILL.mdはエージェント自身が新しく作れるという点です。たとえば「Notionのタスクを毎朝Telegramに送って」と話しかけると、エージェントはそのためのSKILL.mdを自分で生成し、以後はそのスキルを使って自律実行します。

💡 初心者向け補足：コンテキスト節約のため、すべてのSKILL.mdがつねに読み込まれるわけではありません。システムプロンプトにはスキルの「名前と説明だけ」が入り、実際に必要になったときだけ本文をオンデマンドで読み込む設計になっています。

LEARNINGS.md ― 「失敗と発見」を記録するファイル

LEARNINGS.mdはSKILL.mdとよく混同されますが、役割はまったく異なります。

SKILL.mdは「最初から知っていること」、LEARNINGS.mdは「やってみて初めてわかったこと」を書くファイルです。

記録される内容の例を見てみましょう。

## 2026-04-15 | Gmail API | エラー
- 状況：メール送信時に「quota exceeded」エラーが発生
- 原因：1日100件の送信上限に達していた
- 対処：翌日まで待つか、別アカウントに切り替える
- 教訓：大量送信タスクには事前に上限を確認すること

## 2026-04-18 | ユーザー訂正
- 状況：「今週の予定を教えて」に対して月曜始まりで回答
- 訂正：ユーザーは日曜始まりを好む
- 教訓：このユーザーのカレンダーは日曜始まりで処理する

LEARNINGS.mdへの記録は自動です。タスク実行中に失敗・エラー・ユーザーからの訂正が発生すると、エージェントがタイムスタンプ・カテゴリ・内容・文脈を自動で書き込みます。

MEMORY.md ― 「あなた」を覚えているファイル

MEMORY.mdはユーザー固有の長期記憶を保存するファイルです。LEARNINGS.mdがタスク実行上の教訓を記録するのに対し、MEMORY.mdはユーザーの好み・習慣・文脈を蓄積します。

記録される内容の例です。

## ユーザープロファイル
- 名前：Mickey
- タイムゾーン：Asia/Tokyo
- 好みの言語：日本語
- カレンダー：日曜始まり（2026-04-18確認）
- 朝のブリーフィング：7:30に受け取りたい
- メール：重要度「高」のみ通知、それ以外は日次サマリーで十分

## 最近の文脈
- 現在取り組んでいるプロジェクト：社内SNSアプリ（Next.js + Supabase）
- 先週の懸案：AWS SESのバウンス問題（解決済み）

毎セッションの冒頭でMEMORY.mdが読み込まれることで、エージェントは「また一から説明しなくていい相手」として動けるようになります。

3ファイルの連携 ― 「昇格」の仕組み

この3ファイルの真価は、それぞれが独立しているのではなく、情報が下位ファイルから上位ファイルへと「昇格」していく点にあります。

昇格フローの全体像

【タスク実行】
        ↓
失敗・訂正・発見が発生
        ↓
LEARNINGS.mdに自動記録
        ↓
同じパターンが3回以上出現
        ↓
昇格の候補としてフラグが立つ
        ↓
ユーザーまたはエージェントが確認
        ↓
┌─────────────────────────────────┐
│ 昇格先の判断                      │
│ ・手順に関する学び → SKILL.md更新  │
│ ・操作ルールの学び → AGENTS.md更新 │
│ ・ユーザー固有の学び → MEMORY.md   │
│ ・根本的な行動指針 → SOUL.md更新   │
└─────────────────────────────────┘
        ↓
以後すべてのセッションで自動適用

具体例で見る昇格

たとえば「Gmailの送信上限エラー」がLEARNINGS.mdに3回記録されたとします。この時点でエージェントは「これはSKILL.mdに組み込むべき教訓だ」と判断し、gmail-summarize.mdの手順に「送信前に残クォータを確認する」というステップを追記します。

MEMORY.mdが肥大化したときの対処

昇格の仕組みは強力ですが、放置するとMEMORY.mdが際限なく膨らみ、毎セッションのコンテキスト消費が増大します。3ヶ月運用した後にMEMORY.mdが15,000文字を超えてコスト爆発した、という事例が報告されています。

対処方法は2つです。

• 定期的な棚卸し：古くなった情報や重複した記述を手動で整理する（月1回程度が目安）
• bootstrapMaxCharsの設定：セッション開始時にMEMORY.mdから注入する文字数の上限を設定する

{
  "memory": {
    "bootstrapMaxChars": 4000
  }
}

これを設定しておくと、MEMORY.mdがどれだけ育っても、セッション開始時に読み込まれるのは冒頭4,000文字分だけになります。重要な記憶ほど上部に置く運用がおすすめです。

SKILL.mdを自分で書いてみる

「エージェント自身がSKILL.mdを作れる」とはいえ、最初の数本は人間が書いた方が品質が上がります。基本的な構造を知っておきましょう。

SKILL.mdの基本構造は以下の通りです。

# スキル名
メールの未読を毎朝要約してTelegramに送る

## 説明
Gmailの未読メールを重要度順に分類し、
優先度「高」のものだけ全文・それ以外は件名だけを
毎朝7:30にTelegramのDMで報告する。

## 手順
1. Gmail APIで過去24時間の未読メールを取得
2. 送信者・件名・本文冒頭をもとにLLMで重要度を判定
3. 重要度「高」は全文、それ以外は件名のみ抽出
4. Markdownで整形してTelegram Bot APIで送信

## 注意事項
- 送信上限（1日100件）を超えないよう送信数を記録すること
- APIキーはSOUL.mdの環境変数セクションから取得すること
- 失敗時はLEARNINGS.mdに記録してリトライしないこと（翌日まで待つ）

このように「説明・手順・注意事項」の3点セットを書いておくと、エージェントがスキルを選択・実行する精度が大きく上がります。

会話でSKILL.mdを生成させる

最初から完璧に書かなくても大丈夫です。Telegramで以下のように話しかけるだけで、エージェントが草案を作ってくれます。

「毎朝7:30にGmailの未読を要約してここに送るスキルを作って。
重要なメールは全文、それ以外は件名だけでいい」

エージェントはこの指示からSKILL.mdを生成し、「このような内容で作成しました。確認してください」と下書きを返してきます。内容を確認して承認すれば、翌朝から自動実行が始まります。

まとめ ― 記事③への橋渡し

SKILL・LEARNINGS・MEMORYの3ファイルが連携することで、OpenClawは「使えば使うほど自分に最適化されるアシスタント」になります。ただしこの自律性は、記事③で扱うセキュリティリスクとコスト管理の問題とも表裏一体です。

ここまでの3記事の流れをまとめると以下の通りです。

記事③では、MEMORY.mdの肥大化によるコスト爆発や、SOUL.mdへの不正書き込みといった具体的なリスクを扱います。本記事でファイルの仕組みを理解した上で読むと、なぜそれが危険なのかがより明確に理解できます。