OpenClawチューニングハンドブック：「使える」から「手放せない」への7つの上級設定
はじめに：この記事は以下を前提としています
すでに以下ができている方：
- OpenClawをインストール済みで、正常にチャットできる（Discord / Telegram / WebChat どれでもOK）
SOUL.md / USER.md / IDENTITY.mdを書いたことがあるMEMORY.md、memory/階層構造、memorySearchがだいたい何かを理解している
であれば、読み進めてOKです。
この記事では7つのテーマを扱います。すべて「すぐに実践できる」設定ポイントです：
AGENTS.md：AIにワークマニュアルを渡す（最重要）- メモリシステム実践：AIに本当に覚えさせ、自分でメンテナンスさせる
- サブAgent：一人が小チームに（並列処理 + コンテキスト分離）
- Cronスケジュールタスク：分単位の自動化
- Skill開発：AIに新しいスキルを教える（ゼロからSkillを書く）
- マルチチャネル接続：いつでもどこでもAIにアクセス
- 設定早見表：よく使うパラメータの「推奨値」と注意点
一目で分かる：「前回の記事レベル」から「本記事のチューニング後」まで
| 次元 | 前回の記事レベル | 本記事のチューニング後 |
|---|---|---|
| 行動規範 | SOUL.md に数行の原則 | ワークマニュアルあり、何を読み・書き・聞くべきか把握 |
| メモリ | 階層構造 + 検索可能 | 自動書き込み、自動圧縮、週次メンテナンス、命中率向上 |
| タスク能力 | メインブレイン・シングルスレッド | サブAgentを並列派遣し、結果を集約できる |
| 自動化 | Heartbeat巡回 | Cron精密スケジューリング、日報/週報の自動送信 |
| 拡張性 | 既成Skillをインストール | 自分でSkillを書ける、欲しい能力は何でも追加可能 |
| チャネル | 1プラットフォームのみ接続 | Discord/Telegram/WebChat 同時オンライン |
| 設定 | 「動けばOK」レベル | 主要パラメータを安定化とトークン節約に最適化 |
一、AGENTS.md：AIに「ワークマニュアル」を書く
1）何の問題を解決するのか？
SOUL.md は「誰に似ているか」を決め、USER.md は「誰を助けるか」を決めますが、多くの人が見落としていること：AIは仕事の仕方を知らない。
例えば：
- 新しいセッション開始時、最初にどのファイルを読むべき？順番は？
- メモリはどこに書く？どんなフォーマットで？
- どの操作は直接やってOK？どれは先に確認が必要？
- グループチャットであなたのプライベートメモリを参照してもいい？
これが AGENTS.md の価値です：性格設定ではなく、ワークマニュアルです。
こう理解してください：
SOUL.md= 性格（「率直に話す、結論を先に」）AGENTS.md= SOP（「最初に何を読むか、次に何をするか、どう記録するか、何をしてはいけないか」）
2）セッション起動フロー：AIが「目覚めて」最初にすべきことは？
新しいセッションは本質的に「起きたばかり」——前回の会話のコンテキストは自動的に持ってきません。「シーン復元」のワークフローをハードコードする必要があります。
AGENTS.md にセクションを追加します（ルールは英語で書く方が安定します）：
Every Session
Before doing anything else:
- Read
SOUL.md— this is who you are - Read
USER.md— this is who you're helping - Read
memory/YYYY-MM-DD.md(today + yesterday) for recent context - If in MAIN SESSION (direct chat with your human): Also read
MEMORY.md
Don't ask permission. Just do it.
「今日 + 昨日」のログを読む理由は？深夜の時間帯は「今日」がまだ空でも、昨日には内容があるからです。
なぜ MEMORY.md はMAIN SESSIONのみ？MEMORY.md にはより個人的で核心的なインデックス情報が含まれることが多く、グループチャットやcron/サブAgentのセッションで読み込むのは適切ではないからです。
3）メモリ書き込み規範：「再利用可能な結論」の記録方法を教える
メモリシステムが失敗する原因の多くは、階層構造の問題ではなく、書き込み規範が定義されていないことです。
結果は通常2パターン：
- 全部
MEMORY.mdに詰め込む（最終的に雑記帳化） - もしくは全く書かない（次回にはすっかり忘れる）
「どこに書くか、何を書くか、どう書くか」を明確に定義することをおすすめします。例えば：
Memory
You wake up fresh each session. These files are your continuity.
メモリ階層
| レイヤー | ファイル | 用途 |
|---|---|---|
| インデックス層 | MEMORY.md | コア情報とインデックス、簡潔に（推奨 < 40行） |
| プロジェクト層 | memory/projects.md | 各プロジェクトの現在のステータスとToDo |
| インフラ層 | memory/infra.md | サーバー、API、デプロイ設定のクイックリファレンス |
| 教訓層 | memory/lessons.md | 踏んだ落とし穴、深刻度でランク付け |
| ログ層 | memory/YYYY-MM-DD.md | 毎日の生記録（ただし「結論を記録する」） |
書き込みルール
- ログ：当日の出来事を
memory/YYYY-MM-DD.mdに固定フォーマットで記録 - プロジェクトステータス：プロジェクトに進展があったら
memory/projects.mdを同期更新 - 教訓：ハマった後に
memory/lessons.mdに記録 - MEMORY.md：インデックスが変わった時のみ更新、簡潔に保つ
鉄則
- プロセスではなく結論を記録する
- memorySearch のヒット率向上のためにタグを使う
- 覚えておきたいならファイルに書く——「頭で覚えている」ことを期待しない
ログフォーマット例：
[PROJECT:名称] タイトル
- 結論: 一文の要約
- 変更ファイル: 影響があるファイル
- 教訓: ハマりポイント（あれば）
- タグ: #tag1 #tag2
このフォーマットの利点：memorySearch でキーワード検索すると、ヒットがより集中的でクリーンになります。
4）安全境界：何ができて、何は確認が必要か
「内部 vs 外部」を明確にしておくことをおすすめします——でないといずれ問題になります（特にグループチャット、自動化タスクで）。
Safety
- Don't exfiltrate private data. Ever.
- Don't run destructive commands without asking.
trash>rm(recoverable beats gone forever)- When in doubt, ask.
External vs Internal
Safe to do freely:
- Read files, explore, organize, learn
- Search the web, check calendars
- Work within this workspace
Ask first:
- Sending emails, tweets, public posts
- Anything that leaves the machine
- Anything you're uncertain about
Group Chats
You have access to your human's stuff. That doesn't mean you share it. In groups, you're a participant — not their voice, not their proxy.
二、メモリシステム実践：AIに本当に「覚えさせ」、自分でメンテナンスさせる
おそらく以下の3つの典型的な問題に遭遇したことがあるでしょう：
- 長い会話の途中で突然「記憶喪失」（コンテキスト圧縮時に詳細が消える）
- ログはどんどん増えるが品質にばらつきがあり、検索ヒットがますます不安定に
- メモリをメンテナンスする人がいなくて、古い情報がノイズとして蓄積
この章ではこれら3つの問題をそれぞれ解決します。
1）memoryFlush：圧縮前に重要情報をファイルに書き出す
OpenClawはコンテキストが上限に近づくとcompaction（圧縮）をトリガーします。圧縮自体は正常ですが、圧縮で詳細が失われることがあります。
解決策：memoryFlush を有効にして、圧縮前にディスクに書き出させる。
openclaw.json に追加（例）：
{
"agents": {
"defaults": {
"compaction": {
"reserveTokensFloor": 20000,
"memoryFlush": {
"enabled": true,
"softThresholdTokens": 4000
}
}
}
}
}推奨値の簡単な解説：
reserveTokensFloor=20000：圧縮後も少なくとも「直近の会話」を一定量保持softThresholdTokens=4000：残り容量が4000トークンを下回ったらflushをトリガー（小さすぎると書き込む余地がない、大きすぎるとトリガーが頻繁になりすぎる）
2）memorySearchの精度を上げる：一つのログに一つのトピック
ベクトル検索は内容が少ないことは怖くない——むしろ「内容が雑多」の方が怖い。
経験上、最もヒット率が高い書き方：
- タイトルにトピックを明記（例：nginx リバースプロキシ、IPv6、ポート衝突）
- 結論を固定の位置に配置
- タグに同義語を補足（#deploy #nginx #reverse-proxy）
構造化されていない「雑記帳」は類似度スコアを希薄化させ、検索が不安定になります。
3）週次自動メンテナンス：「メモリの腐敗」を防ぐ
ログが増えると、古い情報が検索結果を汚染します。自分のやり方：メンテナンスを定期ルーティン化して、AIに毎週自動実行させる。
HEARTBEAT.md に「週次メンテナンス」タスクを追加し、ステートファイルで頻度を制御：
memory/heartbeat-state.jsonに前回のメンテナンス日を記録- ハートビートで「前回のメンテナンスから 7日以上経過しているか」をチェック
- 経過していれば実行：抽出、圧縮、クリーニング、日付更新
メンテナンスアクションは3種類がおすすめ：
- 抽出：長期的に有用な情報を
projects.md / lessons.mdに移動 - 圧縮：一度きりのタスクを長いログから一行の結論に圧縮
- クリーニング：完全に期限切れの情報を削除（例：「明日ミーティング」）
三、サブAgent：一人が小チームに（並列処理 + コンテキスト分離）
1）サブAgentは具体的に何を解決する？
メインブレインがシングルスレッドだと問題になるのが：複雑なタスクが来ると、非常に時間がかかるか、途中で割り込めないこと。
サブAgentの主な価値は2つ：
- 並列処理：2つのヘルパーを同時に派遣し、それぞれ別のことをさせられる
- コンテキスト分離：サブAgentの長時間タスクがメイン会話を圧迫しない
2）最もよくあるハマりポイント：サブAgentはデフォルト「ゼロコンテキスト」
サブAgentはメインブレインから渡されたtask記述しか見えないので、task記述が雑だと結果も雑になります。
良いtask記述には最低限これが含まれるべき：
- 目標（何を生成するか）
- ファイルパス（どれを読む/書く？）
- 制約（読み取り専用？変更不可な部分は？規約は？）
- 受け入れ基準（何をもって「完了」とするか）
taskを「賢いけど初対面の同僚」に宛てた説明書だと思ってください——具体的であればあるほど安定します。
3）並行処理のヒント：まずは2つのサブAgentから
同時に多くのAgentを派遣すると、APIレート制限（429）に簡単に引っかかります。経験上：
- 通常の個人枠：同時2つが最も安定
- 大きな枠/ローカルモデル：3つを試すのもあり
- 4つ以上は429が頻発しやすい（特にWeb検索/ツール呼び出し時）
四、Cronスケジュールタスク：分単位の自動化
1）Heartbeat vs Cron：混同しないこと
- Heartbeat：「ついでにチェック」する軽量タスク向け（精度は低い）
- Cron：「何時何分に必ず実行」するタスク向け（分単位で正確）
「毎日9:00にデイリーレポート」「毎週月曜10:00に週報」をやりたいなら、Cronの方が適切です。
2）よく使うcron式
0 9 * * *：毎日 9:000 9 * * 1：毎週月曜 9:000 9,18 * * *：毎日 9:00 と 18:00*/30 * * * *：30分ごと
必ずタイムゾーン tz を設定してください——デフォルトはUTCなので、8時間ズレます（東アジア圏で最もよくあるハマりポイント）。
五、Skill開発入門：ゼロから使えるSkillを書く
1）Skillとは？
本質は「操作マニュアル（Markdown）」です。
OpenClawは各Skillの description をシステムプロンプトに含めます。ユーザーがメッセージを送ると、どのSkillがトリガーされる可能性があるかをマッチング——マッチしたら、対応する SKILL.md を読み込み、ステップどおりに実行します。
ですから description は「エレガントに書く」のではなく、「網羅的にカバーして書く」ものです。
2）SKILL.mdの推奨構成
- frontmatter（name/description）
- トリガー後の最初のアクション
- ステップ（できれば実行可能、再現可能）
- 出力フォーマット（固定テンプレート）
- エラーハンドリング（必ず書く）
3）練習のすすめ：IP検索Skillから始める
「IPジオロケーション検索」のようなSkillは初心者の練習に最適：トリガーがシンプル、ステップが明確、出力が固定、エラーハンドリングも簡単。
Skill作成の一つの原則：まず手動でワークフローを一通り実行してから、それをSkillとして書き起こす。 この方法が最も成功率が高いです。
六、マルチチャネル接続：AIを24時間オンラインに、ただし余計なことは言わせない
マルチチャネル接続の重要ポイントは「多く接続すること」ではなく、2つのこと：
- ソースコントロール：
allowFromは必ず絞る（サーバー/ユーザー/チャネル） - フォーマット適応：プラットフォームによってMarkdownの対応が異なる（特にテーブル）
Discord + Telegram を併用するなら、AGENTS.md に「プラットフォーム別フォーマットルール」を書くのがおすすめ：
- Discord：テーブル、コードブロック ともにOK
- Telegram：テーブルは不安定、できればリストで代替
- WhatsApp：基本的にプレーンテキストとして扱う
七、設定早見表：よく使うパラメータの安定チューニング
この章では、「効果が明らかに高い」と思うものだけ残しています——最初から設定に溺れないように。
1）blockStreaming：長い返信で最後まで待たされない
AIに長い返信をチャンク分割で送らせることで、「リアルタイムでタイプしている」ような体験に。
推奨：
blockStreamingDefault: "on"minChars: 200（小さすぎるとスクリーンが荒れる）maxChars: 1500（大きすぎるとストリーミングの意味がなくなる）
2）ackReaction：まず「受け取りました」のフィードバックを返す
特にDiscord/Telegramのようなインスタントメッセージングでは非常に重要です。ないと「落ちた？」と思ってしまいます。
3）compaction + memoryFlush：長い会話でもキー情報をなるべく失わない
一言だけ覚えてください：圧縮前にファイルに書き出す。 これが memoryFlush の意義です。
4）Heartbeat activeHours：深夜3時に起こされない
ハートビート巡回を有効にしているなら、activeHoursを設定しましょう。例えば 08:00〜23:00。これで寝ている間にメッセージが来ることはありません。
最後に：おすすめの設定順序（時短バージョン）
一度に全部やりたくなければ、この優先順位でやるのが最も安定です：
AGENTS.md：起動フロー + メモリ規範 + 安全境界memoryFlushを有効化（長い会話でもキーポイントを失いにくい）ackReactionを設定（体験がすぐに向上）blockStreamingを有効化（長い出力がより快適に）- Heartbeat に
activeHoursを設定（邪魔しない） - その後 Cron、サブAgent、Skill、マルチチャネルを検討（必要に応じて）
変更履歴
1236d-日