# OpenClaw スキル活用事例①｜Obsidian作業ログ＋Redmineチケット運用を完全自動化した話｜株式会社テクノスフィア

> OpenClaw のスキル機構で作業ログを Obsidian Vault に自動記録し、Redmine チケット運用を AI に任せる方法。SKILL.md・AUTO ゾーン同期・起票・ステータス遷移まで実運用を公開。

URL: https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine

** 目次
1. はじめに：記録は人がやるべき仕事か？
2. OpenClaw のスキルとは何か（SKILL.md 構文）
3. スキル①：obsidian-log で作業ログを完全自動化
4. AUTO ゾーンによる「壊さない自動更新」
5. スキル②：redmine-ticket で起票〜完了まで任せる
6. GitHub × Redmine × Obsidian の三位一体
7. 運用 3 ヶ月でわかった効果と落とし穴
8. スキル設計の 5 つの鉄則
9. まとめ
    ** 本記事のスコープ

本記事は [OpenClaw 入門｜環境構築完全ガイド](https://technosphere.co.jp/blog/openclaw-getting-started) の続編です。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.py
```

### SKILL.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 の書き方が運命を分ける

description が雑だと、AI がスキルを呼び出してくれません。**「いつ呼ぶか」「呼ぶと何をしてくれるか」**を 2〜3 文で書き、想定キーワード（"作業ログ", "セッション開始時"）を埋め込むのがコツです。逆に description が雄弁すぎると無関係なリクエストでも呼ばれてしまうので、ピンポイントが正解。

### YAML フロントマターの実用フィールド
| キー | 用途 |
| `name` | スキル ID（一意）。スラッシュコマンドからも呼べる |
| `description` | マッチング判定の核。10〜30 字程度の自然文＋キーワードを混ぜる |
| `tools`（任意） | スキルが使えるツールを絞る。誤発火防止に有効 |
| `model`（任意） | スキル単位で primary を上書き（重い解析だけ Codex に逃がす等） |

## スキル①：obsidian-log で作業ログを完全自動化

弊社で最初に整備したのがこの `obsidian-log` です。エンジニアが OpenClaw を開いた瞬間に、その日の作業ログファイルを準備して、作業の節目で勝手に追記する──を実現しています。

### スキルがやってくれる 4 つのこと
1. **環境判定：**`uname -r` から `wsl / pi5 / mac / linux` を識別し、日次ログのサフィックスを切り替え（複数環境同時編集での Git コンフリクト回避）
2. **日次ログの自動作成：**`~/obsidian-vault/開発/作業ログ/YYYY-MM-DD-<env>.md` がなければテンプレからコピー
3. **プロジェクトセクションの追記：**`### 作業N: [プロジェクト名] - [タイトル]` ブロックを日次ログ末尾に挿入
4. **プロジェクトページの 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 つのこと
1. **新規起票：**「○○の修正を始めたい」と言うと、プロジェクト判定 → トラッカー（バグ/実装/サポート等）選定 → 期日設定の確認 → 起票
2. **ステータス遷移：**「対応中にして」「レビュー依頼中に」「完了に」を自然言語で受け取って Redmine API 経由で更新
3. **関連コメント追記：**コミットメッセージ / PR タイトル / 顧客とのやり取りを抜粋してチケットコメントに転記
4. **担当者変更：**「清水さんにアサインして」をユーザー ID 解決して `assigned_to_id` に反映
5. **進捗率の自動更新：**ステータス完了化と同時に `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 マージ済み')
```

   ** 「自然言語 → ID」のテーブルが命

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 つの落とし穴
1. **「過剰起票」問題：**初期は些細な相談でもチケットが立ってしまう事案が頻発。SKILL.md に「**10 分以内で終わる相談はチケット化しない**」を明示してから安定
2. **「ステータス迷子」問題：**レビュー依頼中のまま放置されるチケットが増加。週次で `status_id=11 のまま 7 日以上`を一覧化する別スキル（`redmine-stale-check`）を追加で解決
3. **「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 スキル活用事例②｜画像生成・ブラウザ自動操作で広がるマルチモーダル業務自動化](https://technosphere.co.jp/blog/openclaw-skills-image-browser) で扱います。

## まとめ

###  この記事のまとめ
- 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 に任せたい」といったご相談はお気軽にどうぞ。    ／この内容の受託開発・PoC相談はこちら＼

### 既存業務システムの AI 化・ナレッジ自動連携

議事録・チケット・ナレッジを横断する社内 AI ワークフロー、Obsidian / Redmine / Notion / Slack を AI で連携する受託開発はテクノスフィアにご相談ください。スモール PoC から全社展開まで。  [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [業務システムAI化相談](https://technosphere.co.jp/contact)     # OpenClaw # スキル # Obsidian # Redmine # 業務自動化 # AIエージェント # 社内DX # ナレッジ管理

##   次に読む｜OpenClaw シリーズ
-  [OpenClaw シリーズ OpenClaw 入門｜OSSのAIアシスタントを社内 Kubernetes で動かす環境構築完全ガイド Docker Compose から k3s 本番運用まで](https://technosphere.co.jp/blog/openclaw-getting-started)
-  [OpenClaw シリーズ スキル活用事例②｜画像生成・ブラウザ自動操作で広がるマルチモーダル業務自動化 gpt-image-2 / Browser Use を OpenClaw に統合](https://technosphere.co.jp/blog/openclaw-skills-image-browser)
-  [関連記事 RAGチャットボット社内ヘルプデスク導入事例 社内 DX × AI の代表例](https://technosphere.co.jp/blog/rag-chatbot-helpdesk)
-  [サービス AI ソリューション開発 業務自動化スキル設計のご支援](https://technosphere.co.jp/ai-solution)
    [技術コラム一覧に戻る](https://technosphere.co.jp/blog/)