本記事は OpenClaw 入門｜環境構築完全ガイド の続編です。OpenClaw 本体の設置・LLM 設定が終わっている前提で、社内業務向けスキル（skills/）の設計と運用ノウハウを扱います。Claude Code の skill 機構ともコンセプトは互換性があり、移植も容易です。
はじめに：記録は人がやるべき仕事か？
受託開発・社内 DX に関わるエンジニアにとって、「何を、いつ、どこまでやったか」の記録は避けて通れません。弊社の場合、最低限ここまでが日々の記録対象でした。
- その日の作業を Obsidian Vault の `作業ログ/YYYY-MM-DD.md` に書く
- 関連する Redmine チケットのステータス・コメントを更新する
- コミットメッセージ・PR タイトル に Redmine 番号（
refs #123）を含める - 顧客向けの返信メール文面と返信ステータスをチケットに転記する
- プロジェクトページの「最終作業」「最新コミット」を最新に保つ
真面目にやろうとすると、1 日あたり 30〜45 分が記録だけに溶けます。でもこれを怠ると、月末に「あの案件、結局何やったんだっけ」が積み上がる。記録は重要だが、人がやる仕事として面白くない──この典型的な業務こそ OpenClaw に任せるべき領域です。
過去にも cron で日次サマリを書かせる、Git hook でチケット番号を抽出する、といった半自動化を試してきました。問題は 「フォーマットがすぐ崩れる」「他人の更新を上書きする」「文脈を補完できない」の 3 点。OpenClaw のスキル＋ LLM 推論を組み合わせると、この 3 点が一気に解けます。
OpenClaw のスキルとは何か（SKILL.md 構文）
OpenClaw のスキルは、1 つのディレクトリ＋ SKILL.md 1 枚で完結します。AI エージェントが LLM 呼び出しの直前に、スキルの説明（description）から「今のリクエストに該当するスキルがあるか」をマッチングし、該当すれば SKILL.md 本文をプロンプトに展開します。
最小構成
.openclaw/workspace/skills/
└── obsidian-log/
├── SKILL.md # 必須：説明＋手順
├── templates/ # 任意：埋め込みテンプレ
│ ├── 作業ログ.md
│ └── プロジェクト.md
└── scripts/ # 任意：補助スクリプト
└── update_dashboard.pySKILL.md フォーマット
---
name: obsidian-log
description: Obsidian Vault への作業ログ自動記録。
セッション開始時の作業ログ確認・プロジェクトページ更新、
作業中のログ記録、トラブルシューティング記録で使用。
---
# Obsidian 自動記録スキル
## Vault パス
`~/obsidian-vault`
## セッション開始時
### 1. 環境判定
`uname -r` の出力で判定し、サフィックス `` を決定:
| 判定条件 | env |
|---------|-----|
| `microsoft` or `WSL` | `wsl` |
| Raspberry Pi 検出 | `pi5` |
| Darwin | `mac` |
| その他 Linux | `linux` |
### 2. 作業ログの確認・作成
ファイル: `~/obsidian-vault/開発/作業ログ/YYYY-MM-DD-<env>.md`
... description が雑だと、AI がスキルを呼び出してくれません。「いつ呼ぶか」「呼ぶと何をしてくれるか」を 2〜3 文で書き、想定キーワード（"作業ログ", "セッション開始時"）を埋め込むのがコツです。逆に description が雄弁すぎると無関係なリクエストでも呼ばれてしまうので、ピンポイントが正解。
YAML フロントマターの実用フィールド
| キー | 用途 |
|---|---|
name | スキル ID（一意）。スラッシュコマンドからも呼べる |
description | マッチング判定の核。10〜30 字程度の自然文＋キーワードを混ぜる |
tools（任意） | スキルが使えるツールを絞る。誤発火防止に有効 |
model（任意） | スキル単位で primary を上書き（重い解析だけ Codex に逃がす等） |
スキル①：obsidian-log で作業ログを完全自動化
弊社で最初に整備したのがこの obsidian-log です。エンジニアが OpenClaw を開いた瞬間に、その日の作業ログファイルを準備して、作業の節目で勝手に追記する──を実現しています。
スキルがやってくれる 4 つのこと
- 環境判定：
uname -rからwsl / pi5 / mac / linuxを識別し、日次ログのサフィックスを切り替え（複数環境同時編集での Git コンフリクト回避） - 日次ログの自動作成：
~/obsidian-vault/開発/作業ログ/YYYY-MM-DD-<env>.mdがなければテンプレからコピー - プロジェクトセクションの追記：
### 作業N: [プロジェクト名] - [タイトル]ブロックを日次ログ末尾に挿入 - プロジェクトページの AUTO ゾーン更新：
~/obsidian-vault/開発/プロジェクト/<プロジェクト名>.mdの最終作業・最新コミット・未コミット件数を最新化
プロジェクト名判定（優先順）
package.json → name フィールド
pyproject.toml → [project].name フィールド
.git/config → リポジトリ名
（フォールバック） → カレントディレクトリ名これにより、Node・Python・素の Git リポジトリのどれでも「いま自分はどのプロジェクトにいるか」を AI が一意に決められます。複数案件を切り替えるエンジニアにこそ効きます。
記録テンプレートを SKILL.md に直書きする
### 作業N: [プロジェクト名] - [タイトル]
**時間**: HH:MM
**プロジェクト**: [プロジェクト名]
**Redmine**: [#123 タイトル](http://192.168.11.241:8080/issues/123) → 対応中
**ブランチ**: `feature/123-xxx`
**コミット**: `abc1234`
**内容**:
- [やったこと]
**実行したコマンド**:
```bash
[コマンド]
```
**結果**: ✅成功 / ⚠️課題あり / ❌失敗
**学んだこと**: [学び・発見]テンプレを SKILL.md にそのまま埋め込んでおくと、LLM は記録ごとにこの形を再現してくれます。フォーマットがブレないことが、後の grep 検索性と Obsidian Dataview クエリの精度を決めます。
AUTO ゾーンによる「壊さない自動更新」
記録自動化で最大の事故は 「人が書いたメモを AI が上書きする」です。これを防ぐために、弊社では AUTO マーカー方式を採用しています。
マーカーの仕組み
# プロジェクト名
## 概要
（ここは人が書く領域。AI は絶対に触らない）
## 自動同期セクション
<!-- AUTO:project-status -->
- 最終作業: 2026-05-21 17:30
- パス: /mnt/data/repos/happy-caremainte-site
- ブランチ: main
- 最新コミット: 6800ea3d
- 未コミット件数: 0
<!-- /AUTO:project-status -->
<!-- AUTO:recent-commits -->
- 6800ea3d feat: パートナーLP ボタン文言変更 (koyama, 5h ago)
- 5415bee6 Merge pull request #42 (koyama, 1d ago)
<!-- /AUTO:recent-commits -->
## メモ（自由記述）
（ここも人が書く領域）SKILL.md には「マーカー間のみ更新、マーカー外は絶対に書き換えない」と明文化し、LLM にも徹底させます。AUTO ゾーンとして実装しているのは以下です。
| マーカー | 更新内容 |
|---|---|
AUTO:project-status | 最終作業時刻、パス、ブランチ、最新コミット、未コミット件数 |
AUTO:tech-stack | package.json / pyproject.toml / Cargo.toml / go.mod 等から自動検出 |
AUTO:recent-commits | git log -10 --pretty=... の結果 |
AUTO:recent-changes | git status --short + git diff --stat HEAD~1..HEAD |
AUTO:readme-excerpt | README.md 先頭 8 行の抜粋 |
AUTO:active-projects | 開発ダッシュボードに最近作業したプロジェクト最大 10 件 |
マーカー名は AUTO:<name> と /AUTO:<name> の対で運用。マーカー自体を消さないこともスキルに明記しています。一度マーカーが消えると次回更新時に書き場所を見失い、AUTO ゾーンが二重に生成されたり、人の記述領域に AI が書き込んだりする事故が起きます。
スキル②：redmine-ticket で起票〜完了まで任せる
弊社の社内ルールはシンプルです：「すべてのコミット・PR には Redmine チケット番号を含める」。逆に言うと、チケットがなければ作業を始めない。これを徹底するために、redmine-ticket スキルで以下を AI に任せています。
スキルがやってくれる 5 つのこと
- 新規起票：「○○の修正を始めたい」と言うと、プロジェクト判定 → トラッカー（バグ/実装/サポート等）選定 → 期日設定の確認 → 起票
- ステータス遷移：「対応中にして」「レビュー依頼中に」「完了に」を自然言語で受け取って Redmine API 経由で更新
- 関連コメント追記：コミットメッセージ / PR タイトル / 顧客とのやり取りを抜粋してチケットコメントに転記
- 担当者変更：「清水さんにアサインして」をユーザー ID 解決して
assigned_to_idに反映 - 進捗率の自動更新：ステータス完了化と同時に
done_ratio: 100%を入れる
SKILL.md に書く Redmine 接続情報
---
name: redmine-ticket
description: Redmineチケットの作成・更新・ステータス変更時の運用ルール適用。
期日設定、担当者変更、作業時間記録、チケット移管など、
Redmine操作全般で使用。
---
## Redmine 接続
- URL: https://redmine.technosphere.co.jp/
- API key: 環境変数 `REDMINE_API_KEY`
## ユーザー
| ID | ログイン | 名前 |
|----|---------|------|
| 5 | koyama | 小山 訓弘 |
| 6 | m_shimizu | 清水 誠 |
| 7 | j_higashijima | 東嶋 潤一 |
| 8 | c_yara | 屋良 朝星 |
## トラッカー
| ID | 名前 |
|----|------|
| 1 | バグ |
| 2 | 実装 |
| 3 | サポート |
## ステータス遷移（開発・保守）
新規(1) → 対応依頼(13) → 対応中(2) → レビュー依頼中(11)
→ 保留(12) → 完了(5) / 却下(6)API 呼び出しは Python ＋ python-redmine
from redminelib import Redmine
redmine = Redmine('https://redmine.technosphere.co.jp/',
key=os.environ['REDMINE_API_KEY'])
# 起票
issue = redmine.issue.create(
project_id='happy-caremainte-site',
tracker_id=2, status_id=1,
subject='パートナーLP ボタン文言変更（260521 ハッピー橋本様 ご依頼分）',
description='5/21 朝、橋本様より以下の修正依頼を受領 ...',
assigned_to_id=5,
)
# レビュー依頼中へ遷移
redmine.issue.update(issue.id,
status_id=11,
notes='PR #43 を出しました。確認をお願いします。')
# 完了化
redmine.issue.update(issue.id,
status_id=5, done_ratio=100,
notes='橋本様確認OK → PR #43 マージ済み')Redmine API は ID ベースなので、AI が「対応中にして」と言われたときに 「対応中＝status_id=2」と即座に変換できる必要があります。SKILL.md に ユーザー名・トラッカー・ステータスの ID テーブルを明示しておくのが運用安定のコツです。LLM の暗記に頼らせない。
GitHub × Redmine × Obsidian の三位一体
obsidian-log と redmine-ticket は単独でも価値がありますが、GitHub と組み合わせると 1 回の指示で全部が回るのが本領です。実際のセッションを再現するとこんな流れになります。
👤 ユーザー: 「ハッピー様から橋本さん経由でパートナーLPの修正依頼が来た。
既存チケット #136 の続きで対応して」
🤖 OpenClaw:
1. redmine-ticket: チケット #136 を取得 → ステータスを「対応中」に
2. 既存リポジトリで feature/136-partner-lp-260520 ブランチを作成
3. 修正10件をエディタで実装（HALサンプル / CSS / コピー差し替え）
4. git commit -m "refs #136 パートナーLP 修正案反映"
5. gh pr create → PR #42 起票（タイトルに refs #136）
6. redmine-ticket: ステータスを「レビュー依頼中」に変更、
コメントに PR URL と修正項目を転記
7. obsidian-log: 今日の作業ログに
「作業N: ハッピー - パートナーLP 修正案反映（#136）」を追記
8. プロジェクトページの AUTO:project-status を更新
9. 「修正10件を反映、PR #42 を出しました」と返事ユーザーの 1 発言から最大 9 アクションが連鎖します。これを人が手でやると 30 分仕事ですが、AI に任せると 3〜5 分で全部終わります。しかも記録漏れがゼロ。
refs #123」を必須化するのか弊社の Redmine は GitHub と双方向連携しています。コミットメッセージや PR タイトルに refs #123 が入っていると Redmine 側にも自動で記録される仕組みです。AI が起票→ブランチ→コミット→PR→記録までを一気通貫で扱えるのは、この命名規約が骨格になっているからです。
運用 3 ヶ月でわかった効果と落とし穴
定量効果
| 指標 | 導入前 | 導入後 | 削減 |
|---|---|---|---|
| 日次作業ログ記録時間（1人） | 30〜45 分 | 5〜10 分（最終確認のみ） | 約 70% |
| Redmine 起票漏れ率 | 週 2〜3 件発生 | 月 0〜1 件 | 約 90% |
| 「あの案件、何やったか思い出せない」率 | 月数件 | ほぼゼロ | — |
| プロジェクトページの鮮度 | 1〜2 週遅れ | 当日中 | — |
※ 弊社社内 4 名のエンジニアの主観評価ベース。導入は 2026-02 頃から段階的に進行、3 ヶ月時点の数値。
定性効果
- 引き継ぎが圧倒的に楽になった：プロジェクトページの AUTO ゾーンを見るだけで現状把握できる
- 客先報告に厚みが出た：作業ログを Obsidian Dataview で集約して、月次報告書を半自動生成
- 朝のブリーフィングが定着：セッション開始時に AI が「今日の作業ログを作成しました」「アクティブなチケットは 5 件です」と切り出してくれる
3 つの落とし穴
- 「過剰起票」問題：初期は些細な相談でもチケットが立ってしまう事案が頻発。SKILL.md に「10 分以内で終わる相談はチケット化しない」を明示してから安定
- 「ステータス迷子」問題：レビュー依頼中のまま放置されるチケットが増加。週次で
status_id=11 のまま 7 日以上を一覧化する別スキル（redmine-stale-check）を追加で解決 - 「Obsidian Vault の Git コンフリクト」問題：複数環境（Pi5・WSL・Mac）で同じ日付ファイルを同時編集してコンフリクト発生。ファイル名に
-<env>サフィックスを付ける運用に変更して根絶
スキル設計の 5 つの鉄則
3 ヶ月の運用で見えてきた、業務自動化スキルを設計するうえでの鉄則を共有します。
① 1 スキル = 1 業務単位
「Obsidian と Redmine を一緒に扱うスキル」のような大くくりを作ると、AI が呼び出しを迷います。1 スキルは 1 ドメインに絞り、組み合わせは AI の判断に任せる。
② description にトリガー語を 3 つ以上
「いつ呼ぶか」のキーワードを 3 つ以上散りばめると、AI が高い再現率で発火します。例：「作業ログ」「Obsidian」「セッション開始時」。
③ ID テーブルは SKILL.md に直書き
Redmine のユーザー ID やステータス ID は、外部 DB ではなく SKILL.md にハードコードするのが運用安定します。LLM の暗記に頼らず、推論時点で確実に参照させる。
④ 「やらないこと」を明記
SKILL.md には 「マーカー外を書き換えない」「Vault 内で git push しない」「10 分以下の作業はチケット化しない」といった禁止事項を必ず入れます。AI は「やれること」より「やってはいけないこと」を明記された方が安全に動きます。
⑤ テンプレを内包する
記録フォーマットや起票時の項目テンプレは SKILL.md 本文に丸ごと貼るのが正解。外部ファイル参照にすると、AI が省略・変形してしまうことがあります。
obsidian-log と redmine-ticket で「文字情報の自動化」は完成しました。次は画像・動画・ブラウザなどマルチモーダルなスキル統合です。OpenClaw スキル活用事例②｜画像生成・ブラウザ自動操作で広がるマルチモーダル業務自動化 で扱います。
まとめ
この記事のまとめ
- OpenClaw のスキルは SKILL.md 1 枚で完結。description で発火条件を表現する
obsidian-logスキルで 環境判定・日次ログ作成・プロジェクトページ AUTO ゾーン同期まで自動化- マーカー付きの AUTO ゾーン方式で「人の記述を AI が壊さない」を担保
redmine-ticketスキルで 起票・ステータス遷移・コメント転記・進捗率反映まで自然言語経由で実行可能に- GitHub × Redmine × Obsidian の連鎖により、1 発言から最大 9 アクションが回る業務体験を実現
- 導入 3 ヶ月で 日次記録時間 70% 削減・起票漏れ 90% 削減
- 設計の鉄則：1 スキル 1 業務単位、トリガー語 3 つ以上、ID テーブルは直書き、禁止事項を明記、テンプレは内包
テクノスフィアでは、OpenClaw / Claude Code 等の AI エージェント基盤を社内業務に組み込み、Redmine・Obsidian・GitHub・社内ファイルサーバとつなぐ 業務自動化スキルの設計・実装支援を行っています。「うちの業務記録もこれくらい楽にしたい」「Redmine 起票を AI に任せたい」といったご相談はお気軽にどうぞ。
既存業務システムの AI 化・ナレッジ自動連携
議事録・チケット・ナレッジを横断する社内 AI ワークフロー、Obsidian / Redmine / Notion / Slack を AI で連携する受託開発はテクノスフィアにご相談ください。スモール PoC から全社展開まで。