OpenClawでPM業務を自動化

AI社会実装勉強会第57回 (https://machine-learning-workshop.connpass.com/event/388419/) の発表資料です。

Transcript

1. OpenClawで PM業務を自動化する 理想と現実 — 実装ベースで語る設計・苦労・展望 AI社会実装勉強会第57回 | 2026年3月28日
2. 本日のアジェンダ 01 OpenClawとは何か 基本概念とアーキテクチャ 02 Workspace & HEARTBEAT Markdownで定義される「生きたAgent」 03 Claude Desktop / Code との比較 なぜOpenClawを選ぶのか 04 PM業務自動化の設計と実装 非技術者PMがプロジェクトの詰まりを把握する 05 苦労した点と良かった判断 実運用で見えたリアルな課題 06 デモ & まとめ 今できること・今後の展望 2 / 25
3. S E C T I O N 0 1 OpenClawとは何か オープンソースAI Agentの全体像
4. OpenClawとは何か Peter Steinberger開発のオープンソースAI Agent。 「チャットボットではなく、実際に動く個人AIアシスタント」 GitHub 247k+ Stars 史上最速級のOSS成長 47.7k forks (2026年3月) 25+ チャネル対応 Slack, WhatsApp, Telegram Discord, Teams, etc. セルフホスト 自分のマシンで稼働 Mac Mini / VPS / Docker 25+ LLMプロバイダ Claude, GPT, Gemini, DeepSeek + OSSモデル (Ollama等) Jensen Huang (NVIDIA CEO): "OpenClaw is the operating system for personal AI" — GTC 2026 4 / 25
5. ChatGPTとの根本的な違い 一般的なチャットAI 聞いたら答える（Reactive） ブラウザを開いて → 質問を入力 → 回答を読む → ブラウザを閉じたら終わり → 次に使うときはゼロから OpenClaw 頼んだら実行する + 自ら動く（Proactive） Slack/WhatsAppで指示 → 実際にGitHub/Jira操作 → 定期的に自分でチェック（HEARTBEAT） → 記憶を持ち、使うほど賢くなる 一般的なチャットAI OpenClaw 動作 質問→回答 指示→実行（API操作、ファイル編集等） 接続先 ブラウザのみ Slack, GitHub, Jira, Google Docs等 記憶 セッション限り Markdown記憶ファイルで永続化 能動性 聞かれるまで何もしない Heartbeatで定期的に自らチェック 5 / 25
6. アーキテクチャの全体像 Channel Slack / WhatsApp Telegram / Discord Routing Binding設定 (top-level config) Agent Workspace Session Store 外部ツール GitHub / Jira Google Docs 概念 役割 Channel 入口。WhatsApp, Slack, Telegram, Discord 等 25+プラットフォーム Agent 1つの「脳」。独自のWorkspace、Session Store、認証情報を持つ Workspace Markdownファイル群（SOUL.md / AGENTS.md / HEARTBEAT.md / MEMORY.md 等） Routing どのChannelのメッセージをどのAgentに送るか。deterministic（LLMが判断するのではない） Skill 能力追加プラグイン。5,400+がClawHubに公開。GitHub操作、Gmail連携等 Sandbox セキュリティ隔離。host側の認証情報を保護。Agentの行動範囲を制御 6 / 25
7. S E C T I O N 0 2 Workspace & HEARTBEAT Markdownで定義される「生きたAgent」
8. Workspaceのファイル構成 ~/.openclaw/workspace/ SOUL.md 人格・トーン・価値観・行動の境 界線 AGENTS.md 操作マニュアル・ブートシーケン ス・ルール USER.md ユーザーの好み・コンテキスト TOOLS.md 環境固有情報（SSHホスト、APIの 場所等） HEARTBEAT.md 定期チェックリスト（後述） MEMORY.md 長期記憶（蒸留された事実・判断 ルール） memory/YYYY-MM-DD.md 日次の作業ログ（append-only） ポイント セッション開始時にこれらのファイルを読み込み、 Agentの「人格」「ルール」「記憶」が構成される ファイルがAgent。DBもクラウドも不要。テキストエ ディタで読める コピーすれば別マシンで同じAgentが動く（ポータブ ル） 主要ファイルがシステムプロンプトに注入される（ bootstrap上限: 約20kトークン） 8 / 25
9. Agentが自分で学び、成長する 日次ログ記録 会話の要点を memory/YYYY-MM-DD.md に記録 長期記憶へ蒸留 重要な事実・好みを MEMORY.mdに キュレーション 行動ルール化 繰り返し学んだことを AGENTS.md や SOUL.md に反映 Git管理が推奨 cd ~/.openclaw/workspace git init git add AGENTS.md SOUL.md MEMORY.md git commit -m "Agent workspace" git push origin main 自動保護メカニズム コンテキストウィンドウの圧縮（compaction）前に、Agentが 自動で記憶をファイルに退避 Heartbeat実行時にworkspaceの変更をgit commit & pushするこ とも可能 9 / 25
10. HEARTBEAT — Reactiveから Proactiveへ 従来のチャットボット（Reactive） ユーザーが聞く → AIが答える 聞かなければ何も起きない OpenClaw HEARTBEAT（Proactive） 30分ごとにAgentが自ら起動 HEARTBEAT.mdのチェックリストを確認 注意すべきことがあれば通知 何もなければ HEARTBEAT_OK → 自動で握りつぶし （= スパムにならない） HEARTBEAT.md の例 # Heartbeat checklist - 未読の緊急メッセージがないか確認 - conflict状態のPRがないか確認 - 3日以上staleなPRがあれば通知 - 未アサインのJiraチケットを検出 - 2時間以内のカレンダー競合を確認 Heartbeat vs Cron Heartbeat: 定期的な「気づき」。何もなければ黙る。バッチ 処理 Cron: 正確な時刻指定。isolated session。週次レポート等に 10 / 25
11. OSSモデルで完全ローカル運用も可能 OpenClawはモデルに依存しない。用途に応じて使い分け、コストとプライバシーを最適化できる クラウドモデル Claude (Anthropic) GPT (OpenAI) Gemini (Google) DeepSeek 高い推論能力 複雑なタスク向き ローカルモデル Ollama (推奨) LM Studio (GUI付き) vLLM (本番向け) llama.cpp (最小構成) API費用ゼロ データがデバイス外に出ない ハイブリッド構成 ルーチン → ローカル 複雑な推論 → クラウド 自動フォールバック auth profilesで設定 コストと品質の 最適なバランス 推奨: 64kトークン以上のコンテキスト。Mac Mini M4 32GB（約$1,199〜）で32Bクラスのモデルが実用的に動作 11 / 25
12. S E C T I O N 0 3 Claude Desktop / Code との比較 なぜOpenClawを選ぶのか
13. Claude側も進化中 — 正確に理解する Cowork Scheduled Tasks Claude Desktopで定期タスクをGUIで設定。永続的で再起動後も残る。非技術者でも使える。Pro $20/月〜で利用可 Claude Code /loop + Cron CLIでセッション中に定期実行。ただしセッション終了で消える。3日で自動期限切れ（安全策） Channels (research preview) Telegram/DiscordからClaude Codeセッションにイベントをpush。セッションが開いている間のみ。Slack未対応 Dispatch スマホからClaude Desktopにタスクを投げる。PCが起きている間のみ動作 13 / 25
14. PM自動化の観点での比較 観点 Claude Desktop / Code OpenClaw 常時稼働 PCが起きている+アプリが開いている間のみ デーモンとして24/7稼働（VPS / Mac Mini） 定期実行 Scheduled Tasks（GUI、永続）。何もなくてもセッショ ン作成 Heartbeat（判断付き）+ Cron。異常なしなら黙る チャネル Telegram, Discord（Channels）。Slack未対応 Slack含む25+チャネルにネイティブ対応 用途 コーディング特化（ファイル操作、ビルド、デバッグ ） 汎用（PM、メール、スケジュール、複数ツール横断） モデル Claude限定 25+プロバイダ + OSSモデル（Ollama / LM Studio） ローカル運用 不可（クラウドAPI必須） 可能。OSSモデルで全データがデバイス内 コスト Pro $20/月〜、Max $100〜$200/月 OSS無料 + モデルAPI費 or ローカルで費用ゼロ Anthropicの進化速度は極めて速い（Dispatch→Channels→Scheduled Tasksが数週間で連続リリース）。 Claude Desktopから始めて、必要になったらOpenClawに移行するステップも現実的。 14 / 25
15. S E C T I O N 0 4 PM業務自動化の 設計と実装 非技術者PMがプロジェクトの詰まりを把握する
16. PM自動化はなぜ簡単ではないか 「1つの賢いagentを作れば終わり」ではない 最低5つのシステムを横断する必要がある: Slack GitHub Jira Google Docs Confluence さらに必要なもの: 人の identity の紐づけ（Slack ID ≠ GitHub username ≠ Atlassian accountId） project ごとの surface の対応表（どのch→どのJira→どのrepo） 何を「停滞」とみなすかのルール（3日？5日？PRの種類による？） 何を「PMが見るべきもの」とみなすかのルール → PM自動化 = 情報取得 + identity正規化 + surface正規化 + detector + 要約 + アクション 16 / 25
17. まず整えるべき3つの基盤 1 Project Surface Map プロジェクトごとに「どのSlack ch、どのJiraプロジェクト、 どのGitHub repoを見るか」の対応表をYAMLで作る 例: monitoring/projects/ec-renewal.yaml に systems / people / signals を定義 2 Identity Normalization Slack ID / GitHub username / Atlassian accountId / Google email の紐づけ。 Slack を anchor にするのが良い（会話が集まる+ users.info でreal_name/email取得可能） 例: monitoring/identity-map.yaml で全員の対応を管理 3 Deterministic Detector LLMに自由に要約させず、ルールベースで検出する。 conflicted PR / stale draft PR / review-required PR / unassigned Jira を機械的に分類 例: scripts/pm-health がGitHub API + Jira APIを叩いてdeterministicに判定 17 / 25
18. シナリオ: 非技術者PMの日常 あなたは「社内ECサイトリニューアル」プロジェクトのPM。 フロントエンド・バックエンドAPI・決済連携の3チームがそれぞれGitHubにPRを出している。 Jiraで80件以上のチケットが動いている。毎週の定例会議のメモはGoogle Docsにある。 従来: PMが自力でやると GitHub開いてPR一覧を確認 Jira開いてチケット状態を確認 Slack開いてblockerを探す Google Docs開いて議事録のaction itemを照合 → 毎朝30分〜1時間かかる OpenClawに聞くと 「ECリニューアルのPM healthを見て」 → 30秒でPR状態 + Jira状態 + 次アクションのサマリーが返る GitHubを開かなくてもPRの状態がわかる 誰に何を依頼すべきか判断できる 毎朝のルーティンが数十秒に短縮 18 / 25
19. PM Health: 規模が違っても同じフォーマット 企業PMの例: ECリニューアル EC PM Health (2026-03-23) >> Risks / Blockers: PR #142 conflict状態、4日放置 PR #138 review待ち3日 Jira ECR-234 未アサイン >> Next actions: #142 conflict解消を田中さんに依頼 #138 にレビュアーをアサイン >> Confirmed: PR #145, #147 マージ済み 個人開発の例: リポ健康診断（デモ） Repo Health (2026-03-23) RED: 5 YELLOW: 2 GREEN: 3 >> Risks / Blockers: cost-mgmt-mcp 143日放置 + CI failure ib-sec-mcp CI failure (6日前) old-dashboard 92日放置 >> Next actions: cost-mgmt: CI修復 or アーカイブ判断 ib-sec: workflow変数エラー修正 >> Confirmed: ib-trading 最終更新2日前 GREEN 19 / 25
20. Slackの分析とレポートの品質チェック PMの「読む仕事」をOpenClawが代行し、判断だけに集中できる Slack thread分析 「決済チームのSlackで何が話題になっているか見て」 → thread contextを読み取り、会話内容を要約（※構造化blocker検出 は今後の課題） レポート品質レビュー 週次レポートや議事録を読み取り、「action itemが曖昧」 「オーナー未記載」「進捗不明」などをPM視点で指摘 議事録 → Action Item抽出 会議メモから 誰が・何を・いつまでに を整理 既存Jiraチケットとの突き合わせも On demand: その場で 「この議事録のaction itemを 整理して、Jiraと突き合わせて」 → すぐにサマリーが返る Periodic: 定期的に Heartbeat: 「レポート更新されたら品質チェック」 Cron: 「毎週月曜9時にSlackのblockerサマリー」 20 / 25
21. S E C T I O N 0 5 苦労した点と 良かった判断 実運用で見えたリアルな課題
22. 実装で苦労した点 Slack投稿事故が一番目立つ thread間違い、文脈無視投稿、PM Bot自身のPRに変な確認。→ guarded send（thread context先読み）で対処 LLMのfree-form要約のノイズ raw Slack IDが出る / 重要でないものがtop risk / WON'T DOをblocker扱い → deterministic detectorに寄せた Identity Normalizationは地味だが最重要 Slack ID / GitHub / Atlassian / Google の紐づけ。一度ズレるとsummaryの信頼性が全部落ちる 長期secretをsandboxに渡したくない GitHub App private key等をsandbox側に持たせない設計。→ host token broker + Keychain + short-lived tokenに寄せた MCP連携の壁 「MCP toolを使う」ことと「OpenClawからnativeにきれいに見せる」ことは別問題。wrapper MCP構成で安定させた 22 / 25
23. 良かった設計判断 Slackをidentity anchorにした 実際の運用会話が集まる + users.info でreal_name/email取得可能。他ツールとの紐づけの起点になる Workspaceをprivate git repoで管理 バックアップ・バージョン管理・チーム共有が一気に解決。Agentの変更履歴が追える PM summaryをdeterministic detectorに寄せた LLMの自由要約ではなく、ルールベースで信頼性の高いサマリーを出す Slack投稿をguarded sendにした non-DM投稿では必ずthread contextを先読み。投稿事故が大幅に減少 Project registryをYAMLで持った プロジェクトごとにsystems / people / signals を構造化。PMの見方がプロジェクトで違う問題を解決 PM summary outputを定型フォーマットに As of → Confirmed → Risks → Next actions → Open questions の順で常に返す 23 / 25
24. デモで見せること ここまでは企業PM×複数ツール横断の例で説明しました。 デモでは、同じ仕組みを個人開発者のリポ管理で実演します。 1 セットアップの簡単さ repos.yaml（監視対象）、thresholds.yaml（健康基準）、AGENTS.md（行動規則） の3ファイルだけでPM Agentが動き始める 2 Cronで自律レポート生成 毎週自動でリポの健康診断 → Risks/Blockers/Next actions形式で出力 OpenClawが自分でgit commitまでやる。人の操作はゼロ 3 対話 + 複数エージェントによる分析 ターミナルからPM Agentに質問 → 即座にプロジェクト全体の状況を返答 さらにsessions_spawnでreviewer（CI調査）とstrategist（復活/アーカイブ判断）を 並列起動し、PMが統合判断を出す 実運用ではSlack/WhatsAppから聞くので非技術者でもそのまま使えます。 デモではターミナルから直接見せますが、裏の仕組み（Workspace / Cron / Sandbox）は同じです。 24 / 25
25. 今できること・まとめ 今できる（相性がいい頼み方） 「PM healthを見て」→ PR + Jira サマリー 「未アサインのJiraを見て」 「この議事録からaction itemを抜いて」 「このthreadに返す確認文をdraftして」 「Slackでblocker出てないか見て」 まだ苦しい 「全部いい感じに進めておいて」 「議事録から勝手にJira全部起票して」 「Slackの空気を読んで自律フォローして」 今後の改善方向 Heartbeat + pm-health → 定期レポートへ進化 Meeting note detectorの独立化 Slack blocker detector / Reviewer policy 持ち帰ってほしい4つ 1 常時稼働する能動的AI 2 全てがMarkdown — git log で追える 3 非技術者PMでも詰まりを 把握できる 4 OSSモデルで完全ローカル 運用も可能 25 / 25
26. A P P E N D I X セキュリティ設計: Docker Sandbox & Token Broker PM自動化を「安全に」動かすための工夫
27. Docker Sandbox — Agentの行動範囲を制御する Gatewayはhost上で動く。Tool実行だけがDocker sandbox内で隔離される Host側 Gateway channel plugins, routing Keychain 長期secret（GitHub App key等） Token Broker 短命tokenを生成・配布 Slack Web API bot tokenはhost側のみ 短命 token Docker Sandbox（Agent tool実行） Workspace scripts scripts/gh, scripts/gws, scripts/slack-send CLI tools gh, gws, uv, jq, git, curl, python3 Deterministic detectors scripts/pm-health 等 Registry / Runbook project YAML, identity map 長期secretは一度もcontainer内に入らない 漏れても被害は短命tokenの有効期間のみ Appendix A
28. Token Broker — credential flowの具体例 GitHub の場合 sandbox内でplain ghは使わず、scripts/gh をentry pointにする → scripts/gh がhost側token brokerに問い合わせ → GitHub App installation token（短命）を取得 → その回のgh processにだけ GH_TOKEN として渡して実行 → App private keyはcontainerに入らない Google Workspace の場合 scripts/gws がbrokerに問い合わせ → 短命access tokenを受け取り → gws実行 以前はexported credentials fileをsandboxに置いていたが、やめてhost Keychainに一本化 Slack の場合（さらに厳格） sandboxはbot tokenを一切見ない。scripts/slack-send がhost側brokerを呼び、brokerがhost上で Slack Web APIを叩く。sandboxは「送信したい内容」を渡すだけ 設計原則: Keychain → Broker → Short-lived Token → Wrapper → One Process Only OpenClawのsandboxは「完全なsecurity boundary」ではないが、この設計で被害時間を最小化する Appendix B