アサインPublicationへの投稿
🗂️

AI駆動PMの5原則と12の具体例 — Claude Code × Obsidian

CHIHIRO
に公開
AI
PM
Obsidian
pdm
Claude Code
tech

はじめに

PM業務をAIエージェントで効率化する事例は近頃よく見るようになりました。私もClaude CodeがリリースされてからPM業務もAIで管理しはじめ、現在は10ヶ月ほど経過し陥りがちな問題や守るべき原則などが見えてきたため、ここで紹介させていただきます。

本記事では業務をAIエージェントで回すために重要と考えている5つの原則と、それを実践した12の具体例を紹介します。

具体例としては、コンテキストの自動収集、プロジェクトの自律実行、スプリントタスクの一括起票といったケースでAIを利用しています。

構成図

原則を話すにあたって、先に構成図を示した方が理解しやすいため掲示します。

構成図

横軸は業務フロー、縦軸はレイヤーで分けています。
5つの原則は業務フローのどの段階を担うかで配置していて、原則1で外部サービスからMarkdownへ情報を集約し、原則2・3でMarkdown上の業務進行を支え、原則4でMarkdownから外部サービスへ成果物を反映、原則5で情報のズレを更新する、という流れになっています。

5つの原則

私が考えている重要な原則はこの5つです。
原則1・2・4はすでに実施している方も多いですが、「3. 状態を持たせる」と「5. 鮮度を保つ」は差が出やすい箇所だと思います。後のセクションで具体例を紹介します。

1. コンテキストを揃える

成果物づくりに必要なものをすべてClaude Codeの管理下に揃える。

2. 構造化する

人にとってもAIにとっても求める情報がどこにあるかすぐにわかる状態にする。

3. 状態を持たせる

目の前の業務に必要なコンテキストをすぐに与えられる状態にする。

4. 操作可能にする

AIエージェントのパフォーマンスを最大限活用するため外部リソースを操作可能にする。

5. 鮮度を保つ

古い情報を更新し、正しい情報を参照させる仕組みを作る。

前提

私はClaude CodeとObsidianの構成で業務を管理しています。
Obsidianはmdファイルの集約ビュワーと可読性向上のために利用しています。
素のmdファイルだけではタスク管理に乏しいため、できるだけ特殊なツールへのロックインを避け、軽量な構成で動かすため採用しました。

本記事で登場する構成は以下です。

  • Claude Code
  • Obsidian
    • Tasks — チェックボックスとクエリで未完了タスクを横断集約
    • Dataview — フロントマターやインラインフィールドの横断クエリ
    • Day Planner — HH:MM - HH:MM のタスクを縦タイムラインで可視化
    • Big Calendar — タスクを週次・月次のカレンダービューで俯瞰
  • MCP・API・CLI
    • Notion、JIRA、Google Calendar、Figma、Miro など

原則1：コンテキストを揃える

成果物に必要な情報をエージェントが読み書きできるMarkdownに集約します。
揃えるのはJIRAやSlackなど外部にある情報や、仮説の組み立て方・企画書の書き方といった属人的なノウハウです。
私の揃え方は大きく2パターンで、外部情報はMCPやAPIで引き込み、属人的な情報やノウハウは言語化してナレッジファイルに落としています。

外部情報の収集

外部から情報を収集するサービスと連携方法は以下のようなものです（一部抜粋）。
業務が固定化されているものはCLIやAPIで収集し、ある程度柔軟に扱うものはMCPで収集する傾向が強いです。

サービス 連携方法 収集する情報
JIRA REST API 担当タスク・スプリント状況
Slack / Google Chat MCP メンション・議論の投稿
GitHub CLI コードリポジトリの情報
ボイスメモ ローカル 音声メモの情報

属人ノウハウのナレッジ化

アウトプット品質を向上・安定させるために成果物の型やノウハウを言語化してファイルに落とします。
言語化は骨が折れる作業ですが、1度行えばアウトプットの品質を下支えする資産になります。
何度も繰り返すものはスキル配下に、使用頻度は高くないが重要な考えはナレッジ配下にまとめています。

knowledge/
├── pdm/
│   ├── brand-concept-guide.md      # ブランドコンセプトの立て方
│   ├── jobs-to-be-done-guide.md    # JTBDの整理手順
│   ├── vpc-pain-deep-dive.md       # VPC Painの深掘り手順
│   └── document-quality-guide.md   # ドキュメント品質の基準
├── bizdev/
│   └── data-analysis-spreadsheet.md  # スプレッドシートでの分析フロー
├── documentation/
│   └── template-formatting-rules.md
└── ...

【具体例1】今日の動きを収集

毎朝コンテキストを集約するスキルを実行し、その日の仕事に必要なコンテキストをドキュメントにまとめています。
以前はJIRA→カレンダー→Slack→前日メモと巡回して頭の中で組み立てていた作業が、スキル1つで完了します。

  1. テンプレートから当日のログファイルを生成
  2. JIRA APIから当日担当タスクを取得し、曜日でフィルタリング
  3. Googleカレンダーからイベントを取得
  4. 前営業日の未完了タスク・JIRAタスク・プロジェクト・カレンダーからタスク一覧を生成

実行結果はこのようなイメージです。

今日の動きを収集した実行結果

【具体例2】MTG情報の取り込み

現実世界のMTGでの決議も外部の情報ということでここに記載します。
MTG後即座に決定事項、課題や次の行動をドキュメントに落とし込むようにスキルを作成しています。
特に以下の「3. プロジェクト特定」が便利です。デイリーログに「14:00-15:00 事業MTG」と書いてあれば、14時の録音は事業MTGのプロジェクトに紐づきます。

  1. ボイスメモDBから最新の未処理録音を取得
  2. Yapで文字起こし
  3. 録音日時とデイリーログの時間帯を照合し、該当プロジェクトを特定
  4. MTGの種類に応じたテンプレートで議事録を生成（定例／インタビュー／汎用）
  5. プロジェクトの outputs/ に格納
  6. ボイスメモのタイトルを [済] に更新

YapはmacOS専用ですがCLIで文字起こしができ非常に便利でしたので紹介しておきます。

https://zenn.dev/explaza/articles/d0e658c7862eac

原則2：構造化する

人とAIの両方が即座に情報を探せる構成が好ましいです。
情報に秩序がなければ、探索で余計なコンテキストを消費し、うまく探せないことがあります。また後述の具体例で示していますが、構造にルールがあれば機械的な集約が可能になります。
私はディレクトリを役割と時間軸で整理し、パスを見れば何の情報かが分かる構造にしています。

役割で分ける

ディレクトリを役割ごとに4つに分けています。

pm-agent/
├── daily-logs/          # 日次のタスク管理
├── projects/            # プロジェクト管理
├── products/            # プロダクト管理
└── knowledge/           # ナレッジ管理

  • daily-logs/ — 1日分のMTG・作業・持ち越しタスクを時刻順に並べる、業務の起点。
  • projects/ — 個別プロジェクトの検討・作業の置き場。VPC作成・インタビュー実施・方針検討など、完了すれば終わるタスクが中心。
  • products/ — プロダクト運営の確定情報（コンセプト、事業方針、マーケ戦略、ペルソナ、機能一覧など）。継続的に更新する。
  • knowledge/ — 成果物づくりの型や再利用可能な知見（PRD作成ガイド、JTBD整理手順）を追記していくストック。

特に projects（検討中のプロジェクト）と products（確定した情報）を物理的に分けている点は、原則5「鮮度を保つ」の設計にも繋がっています。

時間軸で分ける

デイリーログは年月日、プロジェクトは1Q〜4Qの四半期で区切っています。どちらも「期間 × 対象」で場所が一意に決まるので、数ヶ月前のログを引っ張るときも、四半期単位のロードマップを俯瞰するときも、パスを思い浮かべるだけで辿れます。

daily-logs/
└── 2026/            ← 年
    └── 4/           ← 月
        ├── 2026-04-02.md   ← 日（デイリーログ）
        └── 2026-04-03.md

projects/
└── fy2025/          ← 年度（4月始まり）
    └── 4q/          ← 四半期（1Q〜4Q）
        ├── 01-08_it_industry/    ← 月日_プロジェクト名
        │   └── README.md
        └── 02-15_onboarding/
            └── README.md

【具体例3】タスクの動的集約

ディレクトリの細分化が進むと、タスク確認時に深い階層まで何度もクリックして探索する必要があります。
そこでObsidian Tasksのようなプラグインでクエリで集約して1つのファイルで確認する方法があります。たとえばデイリーログの「プロジェクトタスク」セクションには、こんなクエリが埋め込まれています。

タスクの動的集約のクエリ

projects/ 配下の稼働中プロジェクトを集約しています。
読み手（デイリーログ）にタスクを転記することなく、クエリで動的に各プロジェクトのタスクを操作できます。必要なビューはObsidianのクエリが自動で組み上げる、という形で回しています。

タスクの動的集約の表示例

原則3：状態を持たせる

AIはステートレスなためコンテキストを保持できませんが、業務は過去のプロジェクトと地続きです。
このギャップを埋めるためドキュメントにステータスやフラグを作り、状態を持たせることで新規セッションでも必要なコンテキストをすぐに与えられます。

5原則のうち最も効果を感じているのがこの原則です。プロジェクト横断で状態を機械可読にしておくと、どこまで進んだかをエージェントに会話で伝える手間がなくなりました。本記事でも他より具体例を厚めに紹介します。

フロントマターの活用

冒頭のフロントマター（YAML）には、id・タイトル・タイプ・完了フラグといった機械可読なメタデータを入れています。
yq コマンドでファイル全体を読まずに特定フィールドだけ取得できるほか、Dataview で横断検索の起点として使えます。プロジェクト作成時にこのフロントマターを自動生成し、以降のスキルは completed: false や type: 業務改善 を機械的に判定して動きます。

projects/xx/README.md
---
id: 26040201
title: Zenn記事作成ワークフロー
type: 業務改善
completed: false
---

## 概要
素材からZenn記事を作成するスキルを構築する。

## 背景
Zenn記事の作成にあたり、多様な素材を効率的に記事化する仕組みが
必要になっている。現状は手作業でプロセスが属人的。

## 進め方
### Phase 1: 設計
- [x] 既存スキルの棚卸し 📅 2026-04-04 ✅ 2026-04-02
- [x] スキルの処理フロー設計 📅 2026-04-07 ✅ 2026-04-02

### Phase 2: スキル構築
- [x] スキル作成 📅 2026-04-10 ✅ 2026-04-02
- [/] 実際の素材で試行 📅 2026-04-14
- [ ] [人間-承認] PRDレビュー 📅 2026-04-15

タスクステータス

タスクにステータスを持たせています。
会話の中でタスクに着手した時点でエージェントが [/] に更新し、完了時に [x] と日付を書き込む、というルールで運用しています。

  • [ ]（未着手）
  • [/]（進行中）
  • [x]（完了）
  • [-]（キャンセル）
  • [>]（先送り）

開始日時のコンテキストを作る

デイリーログのタスクには、行頭に HH:MM - HH:MM のタイムブロックを付けています。これがあるだけでタスクは時刻順に上から並び、「いつやるか」がファイル上で一意に決まります。

daily-logs/2026/4/2026-04-02.md
- [ ] 09:00 - 10:30 企画MTG準備 📅 2026-04-02
- [ ] 10:40 - 11:20 タスク整理 📅 2026-04-02
- [ ] 13:00 - 14:00 企画MTGに参加 📅 2026-04-02
- [ ] 16:30 - 18:00 要件定義 📅 2026-04-02

タイムブロック自体もタスクの状態です。ステータス記号（[ ] / [/] / [x]）と組み合わせれば、現在時刻を突き合わせるだけで「今やるべきこと」が機械的に取り出せます。

【具体例4】1日のスケジュールの自動組み立て

1日のスケジュールを半自動で組み立てられるようにしています。
具体例1で示した「外部からのコンテキスト収集」と、原則3で示した稼働中のプロジェクト配下のステータスと日付を見て、今日やるべきタスクを機械的に収集できます。
それを HH:MM - HH:MM のタイムブロックを付けて、デイリーログで管理します。
タイムブロックの並びは、そのままDay Plannerプラグインの入力にもなります。Day Plannerはタイムブロックを縦軸の時刻に並べたタイムラインビューに変換し1画面で把握できる状態にしてくれます。

1日のスケジュールとDay Plannerのタイムラインビュー

ObsidianのDay Plannerプラグインはこちら

https://github.com/ivan-lednev/obsidian-day-planner

【具体例5】予実管理

タスクの予実管理は計測が面倒で長続きしないことが多いですが、私が負荷なくできている方法を紹介します。
具体例4のように朝に1日のスケジュールを決め、その時点の見積もりを予定工数として記録します。見積もり記録スキルで、その時点のタイムブロックから時間が計算され、各タスクに [予定:: "Xh"] というフィールドが付与されます。

- [ ] 09:00 - 10:30 企画MTG準備 [予定:: "1.5h"] 📅 2026-04-02
- [ ] 10:40 - 11:20 タスク整理 [予定:: "40m"] 📅 2026-04-02
- [ ] 16:30 - 18:00 要件定義 [予定:: "1.5h"] 📅 2026-04-02

タスクをこなしながら、実数値はDay PlannerでGoogleカレンダーのように予定を引き伸ばして調整します。
これで1日の終わりには予定と実数値が取得でき、以前は思ったよりも時間がかかったという感覚でしか振り返れませんでしたが、今はタスク別の見積精度を数字で追えるようになり、どのタイプの作業で見積を外しやすいかが見えてきました。
以下はdataviewjsを利用して予定と実際のギャップを動的に算出するテーブルを作成しています。

予実管理のイメージ

【具体例6】「今やるタスク」コンテキストを即座に渡す

「今この時間帯にやるべきタスク」と「今走っているプロジェクト」を機械的に抽出し、「今はXXをやっていて…」と説明し直す手間を無くしています。
当日のデイリーログからタイムブロック付きのタスクをgrepで集め、現在時刻と突き合わせて「今」「次」「時間超過」を判定します。本文は一切読まず、タイムブロックとステータス記号、日付タグだけで判定しています。
ここから実施するプロジェクトのAなどと1文字打てば具体例7の「プロジェクトを自律遂行するスキル」が立ち上がります。

「今やるタスク」コンテキストの表示例

【具体例7】プロジェクトの自律実行

プロジェクトを進めるたびに「前回どこまでやったか」「次は何のタスクか」を会話でエージェントに渡していましたが、新規セッションのたびに同じ説明を繰り返すのは面倒です。
今やるべき状態がドキュメントに残っていれば、新規セッションでもすぐにプロジェクトを進行させることができます。
プロジェクトの背景や未完了タスクがドキュメントに記載し、それを上から順に実行し、[ ]→[/]→[x] のステータス遷移を書きながら自律的に進めるスキルを作成しています。中断しても、次のセッションは同じREADMEを読んで「どこまで進んだか」を再構築できます。
さらに、人間の判断が要るタスクには [人間-確認] / [人間-承認] というタグを頭に付けておきます。エージェントが自律遂行していく中で、このタグに到達したら必ず止まるというガードレールとして使っています。意思決定は人が行い、情報収集・整理・ドキュメント化をエージェントが担う、という役割分担を状態ラベルで表現している形です。

プロジェクトの自律実行

【具体例8】稼働中のプロジェクトの全体俯瞰

複数のプロジェクトを並行で進めていると、「今期のプロジェクトは何件あるか」「特定のタイプだけで絞りたい」といった横断的な確認が必要になります。Dataviewプラグインを使うと、プロジェクトのフロントマター（YAML）をクエリして横断ビューを作れます。さらに obsidian eval 経由でCLIからもDataview APIを叩けるため、Claude Codeから直接プロジェクト一覧を取得できます。

稼働中プロジェクトの一覧をCLIから取得
obsidian eval code="const dv = app.plugins.plugins.dataview.api; JSON.stringify(dv.pages('\"projects\"').where(p => p.completed === false).map(p => ({title: p.title, path: p.file.path})).array())"

プロジェクト一覧の全体俯瞰

原則4：操作可能にする

ドキュメントは成果物の一部に過ぎないため、MCPやAPIでデザインやプロトタイプの作成、チケット起票といったアウトプットまで任せられると良いです。

外部サービスとの連携

作成・照会・更新・削除といったCRUD操作で以下のサービスを操作しています。

サービス 連携方法 行う操作
JIRA REST API 課題作成・スプリント登録
Miro REST API リーンキャンバス・VPC等の付箋配置
スプレッドシート MCP データ操作
Notion MCP ページ同期・更新
Figma MCP Code Connectマッピング

JIRAは原則1でも取得側として出てきましたが、原則4では起票・登録の方向で使います。これらを個別に呼ぶのではなく、「スプリント計画」「ディスカバリー分析」のように業務単位のスキルに束ねて、人間がスキル1つで呼び出せるようにしています。

【具体例9】次週スプリントタスクの一括登録

JIRAのUIで1件ずつ編集するのではなく、次回スプリントで着手するタスクをMarkdownで計画した後に、JIRAへ一括登録する流れにしています。
ただしMarkdownだけでは、翌週や中期のバックログを見渡すときの可読性が良くありません。そこでBig Calendarプラグインを使って、デイリーログやバックログのタスクを週次・月次のカレンダー上に並べ、着手日で詰まっている曜日や空いている曜日を俯瞰できるようにしています。
このビュー内でタスクをドラッグ&ドロップすると、着手日（📅）の変更が元のMarkdownファイルに書き戻されるので、GUIで直感的に日程を動かしつつ、データの本体はMarkdownに残るという形です。

Big Calendarでのスプリント計画ビュー

※ Big Calendarは、Obsidian Big Calendarプラグインをフォークし、自分のディレクトリ構造やタスク書式に合わせて拡張して使っています。

【具体例10】ディスカバリー分析

プロダクトマネジメントのディスカバリーフェーズは、Markdownで分析を書いて、Miroでチームと議論できるようにしています。リーンキャンバス・VPC・SWOT分析・PEST分析のそれぞれに、Markdownの分析結果をMiroの付箋として一括配置するスキルを用意しています。

たとえばVPCなら、項目ごとに絵文字ラベル（💡仮説、📗検証済み、📘事実）を付けておきます。スキルを叩くとMiro APIで付箋を一括生成し、ラベルごとに色分けして配置するので、チームで「これは仮説だから検証が必要」「これは事実だから議論の前提」と切り分けて話せます。分析のインプットはAIと1対1で深く考える、アウトプットはMiroでチームと議論する、という役割分担です。

Miroへの付箋一括作成の例
curl -X POST "https://api.miro.com/v2/boards/${BOARD_ID}/items/bulk" \
  -H "Authorization: Bearer ${MIRO_ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '[
    {
      "type": "sticky_note",
      "data": { "content": "見積作成に1件あたり30分かかっている" },
      "style": { "fillColor": "light_blue" },
      "position": { "x": 1800, "y": 600 },
      "parent": { "id": "<FRAME_ID>" }
    }
  ]'

VPC配置スキル実行後のMiroボード

原則5：鮮度を保つ

ドキュメントが増えてくると古い情報がノイズになり、ドキュメント間の累積的なズレが生じます。これを抑える仕組みが、長期運用で情報の信頼性を保つ基盤になります。
実際にあった例では、検討中の仮説に修正が入り、その古い情報を参照して新たなドキュメントが生成され、さらにそれを参照して別ドキュメントに影響を及ぼすというネズミ算式に累積的なズレが生じていきました。

検討と確定を置き場で分ける

検討中の情報と確定した情報で置き場を分けて、情報をマスタ化しています。
例えばprojects/ は個別プロジェクトの検討・作業を扱う置き場、products/ はプロダクトの確定情報（コンセプト、事業方針、マーケ戦略、機能一覧など）をストックする場所です。各プロジェクトで固まった決定事項は products/ に昇華させて残していきます（原則2でディレクトリを役割で分けたのもこのため）。
検討と確定を分けているだけで、検討中の案を確定情報として引き合いに出してしまうというズレは大きく減らせます。

情報の種類によってSSoTを分けて更新する

同じ情報を複数箇所で扱うとメンテコストがかかり、陳腐化しやすいため、真実の情報は1箇所にして参照する形にしたいです。
SSoTを全てClaude Code管理下のドキュメントにしたいところですが、情報の種類によっては外部サービスの情報が正しい場合が往々にしてあります。例えば外部との予定が入りやすいカレンダーや、チームで管理しているロードマップなどです。
そこで、情報の種類によってSSoTを分けることで、メンテコストと陳腐化を防ぐ仕組みがあると運用がグッと楽になります。

【具体例11】カレンダーの予定とタスク期日のズレ検知

予定の追加・変更に伴い、新規タスクの登録漏れやタスク期日の不整合が発生しやすくなります。
このスキルはGoogleカレンダーの予定とプロジェクトREADMEのタスクを照合し、漏れ・期日のズレ・状態の不整合を検出します。たとえばカレンダーに「04-10 ○○インタビュー」が入っているのにREADME側にタスクがなかったり、タスクはあってもステータスが未着手のままになっていたら、修正提案が出ます。

実行結果はこんな形で返ってきます。

ズレを3件検出しました

- [要追加]   04-10 採用候補者インタビュー（カレンダー） → README側にタスクなし
- [期日ズレ] PRDレビュー（README 📅 2026-04-15 ↔ カレンダー 04-17 15:00-16:00）
- [状態ズレ] 04-09 キックオフMTG（カレンダー側は済）→ README側が [ ] のまま

【具体例12】ロードマップと実績の進捗整合

ロードマップは陳腐化しやすいため、自動で更新する仕組みを作っています。
このスキルは、四半期ロードマップのマイルストーンと稼働中プロジェクトのREADMEタスクを照合し、各マイルストーンの状態を自動判定します。予定日を過ぎても該当フェーズのタスクが完了していなれば「リスク」と判定され、プロジェクト側のタスク期日から見込み日が算出されます。
遅延が見つかった場合は、後続の未完了マイルストーンに同じ日数をスライドさせ、最終マイルストーン（例: 新機能開発）の開発期間への影響まで計算したうえで、マイルストーンテーブルとガントチャートを更新します。

  1. ロードマップのマイルストーンテーブルを取得
  2. 稼働中プロジェクトのタスクを並列取得
  3. マイルストーンの状態を判定（完了／遅延／進行中／未着手／リスク）
  4. リスクの見込み日を算出し、後続マイルストーンへスライド
  5. 提案を提示し、承認後にテーブルとガントチャートを更新

ロードマップ進捗レポート

まとめ

ここまでAIエージェントで業務を回すための5つの原則と、それを実践した12の具体例を紹介してきました。

試行錯誤を経て、手応えが一番大きかったのは原則3「状態を持たせる」でした。プロジェクト横断で状態を機械可読にしておくと、新規セッションでも文脈を会話で渡し直す手間がなくなり作業効率がグッと上がりました。

一方で原則5「鮮度を保つ」はまだ改善の余地があり、検知スキルで凌いでいる段階です。ここが整えば長期運用でも情報の信頼性が落ちないため引き続き模索中です。良い知見があれば共有していきたいと思います。

アサイン
アサインPublication

株式会社アサインのテックブログです。アサインは「人」と「技術」の力で、若手ハイエンド向けのキャリア支援サービスを提供しています。転職サイト『ASSIGN』を始め、技術の力を最大限活用し、ユーザーへの提供価値を向上させています。

Discussion