俺の考えた最強のAIPMシステム with Cursor Agent

PMBOK × Lean UX × Agile ― 総合PMフレームワーク支援Rulesセット利用ガイド

このドキュメントは、PMBOK標準、Lean UX、およびアジャイル手法を融合したプロジェクト管理システムの使い方を説明するものです。

対象読者: プロジェクト責任者 / PO / スクラムマスター / UX デザイナー / PMO ― 「ドキュメントも実装もユーザー価値も、すべて1本のレールで回したい」人たち

1. システム概要

このシステムは、プロジェクト管理における文書作成から確定・アーカイブまでの流れを自動化し、LLM（大規模言語モデル）の支援を受けながらプロジェクトを効率的に進めるためのものです。

主な特徴

PMBOK × Lean UX × Agileハイブリッド: 上流工程はPMBOK準拠の文書管理、中流にLean UXの発見と検証、実装フェーズはアジャイル手法を採用
フォルダ構造の分離: Flow（ドラフト）→ Stock（確定版）→ Archived（完了プロジェクト）
自動文書生成: 質問応答による文書ドラフト作成
自動同期: 「確定反映」コマンドによるFlowからStockへの文書移動
LLM活用: 各フェーズで適切な質問と文書テンプレートを提供

成し遂げたいこと

"正しい課題"にフォーカス: Lean UX & デザイン思考のDiscovery → 仮説検証をPMBOKの立ち上げに取り込み、作る前に迷子にならない
学習しながら作る: Dual-Track/Continuous DiscoveryをアジャイルDevelopmentと並走させ、ユーザーの声が常にバックログへ直結
ドキュメントを無駄にしない: "Flow → Stock → Archived"の3層によって、必要最小限の文書だけが公式資産として残る
拡張し続けられる: ルール自体を対話で増やせる（90_rule_maintenance.mdc）。プロセス改善がコード管理できる

2. システム全体像

┌──────────────────────────────┐   trigger（チャットコマンド）
│ 00_master_rules.mdc           │◀───────────────────────┐
└─────────┬────────────────────┘                        │
          call                                          │
┌
9E88
─────────▼────────────┐   発散/収束も Draft 化           │
│ 01‑06_pmbok_*.mdc     │──────────────────┐             │
│ 08_flow_assist.mdc    │    create_draft  │             │
└─────────┬────────────┘                │             │
          ▼ Draft (.md)              │             │
      Flow/YYYYMM/YYYY‑MM‑DD/─────────────────────────────┘       │
          │  human review + "確定反映して"                         │
          ▼                                                      │
      Stock/programs/PROGRAM/projects/PROJECT/.. ← flow_to_stock_rules.mdc  ────┘

主要コンセプト

三つ巴モデル

方法論	役割
PMBOK	フェーズ & 知識エリアで What を管理
Lean UX/Design Thinking	ユーザー中心の Why を確認
Agile / Scrum	イテレーションで How を適応

このシステムはPMBOKの骨格にLean UXのDiscoveryとアジャイルDeliveryをレイヤー合成しているため、上流で迷わず・開発中に学び・下流で残せるワークフローが1つにまとまります。

Flow / Stock / Archived

階層	役割
Flow	下書き・ラフアイデア・日次アウトプット
Stock	承認済みドキュメント・正式成果物
Archived	完了プロジェクトの凍結コピー

4ステップ・サイクル

Ask - LLMが質問で情報収集
Draft - テンプレへ自動整形（Flow）
Review - 人が編集 → 「確定反映して」
Sync - Shell / ルールでStockへ自動移動

3. 基本的なフォルダ構造

プロジェクトルート/
├── .cursor/
│   └── rules/         # LLMルールファイル群
│       ├── basic/     # 基本ルールフォルダ
│       │   ├── pmbok_paths.mdc
│       │   ├── 00_master_rules.mdc
│       │   ├── 01_pmbok_initiating.mdc
│       │   └── ...
│       └── (additional_rules)/  # プロジェクト別特化ルール
├── Flow/              # 日付ごとのドラフト文書
│   ├── YYYYMM/        # 年月フォルダ
│   │   ├── YYYY-MM-DD/    # 作業日ごとのフォルダ
│   │   │   ├── draft_project_charter.md
│   │   │   └── ...
│   │   └── ...
│   └── templates/     # テンプレート
├── Stock/             # 確定済み文書
│   ├── programs/      # プログラム（プロジェクトのまとまり）単位でのフォルダ
│   │   └── PROGRAM_NAME/  # プログラムフォルダ
│   │       └── projects/
│   │           └── PROJECT_ID/  # プロジェクトごとのフォルダ
│   │               └── documents/
│   │                   ├── 1_initiating/
│   │                   ├── 2_discovery/
│   │                   ├── 2_research/
│   │                   ├── 3_planning/
│   │                   ├── 4_executing/
│   │                   ├── 5_monitoring/
│   │                   └── 6_closing/
│   └── shared/         # 共有テンプレート
│       └── templates/
└── Archived/          # 完了プロジェクト
    └── programs/      # アーカイブ済みプログラム

4. システムのセットアップ

クイックスタート

Cursorの新規ウィンドウから簡単にセットアップできます：

Cursorを起動し、「New Window」を選択
「Clone repo」を選び、このリポジトリのURLを入力
フォルダ指定のUIが表示されたら、右下の「Select as repository destination」ボタンをタップ
リポジトリがクローンされたら、README.mdファイルを開く
Chatパネルを開き「初期設定お願いします」と入力

これだけで、READMEの内容を読み取り、必要な初期設定が自動的に実行されます。フォルダ構造の作成、ルールファイルの設定、必要なリポジトリのクローンなどが自動で行われます。

手動セットアップ

初期設定

ユーザー設定（タスク管理用）

タスク管理システムでは、バックログファイルからユーザーに割り当てられたタスクを抽出するために、ユーザー名の設定が必要です。以下の手順で設定してください：

設定ファイルを開く：
```
open /Users/daisukemiyata/aipm_v3/scripts_public/config/user_config.yaml
```
または任意のエディタで scripts_public/config/user_config.yaml を開く

ユーザー名を設定：

# ユーザー設定ファイル
# 自分のユーザー名を設定します（複数指定可能）

# assigneeフィルタリングに使用するユーザー名
user_names:
  - 宮田           # バックログでの表記に合わせて設定
  - miyatti       # 複数の表記がある場合は追加
  - Daisuke Miyata

バックログファイル内で使用されている自分のユーザー名（assignee）をすべて登録してください
これにより色々なタスク関連のタスクで、自分に割り当てられたタスクのみが抽出されるなど活用されます

プレゼンテーションの背景画像

「プレゼン資料生成」コマンドを実行すると、タイトルスライド（lead）用の背景画像が自動的にassetsディレクトリにコピーされます。背景画像は次の方法で利用できます：

自動適用: テーマCSS内で設定された背景画像が lead クラスのスライドに自動的に適用されます
Markdown内で指定: 特定のスライドに異なる背景画像を適用したい場合
```
![bg](assets/bg_explaza.png)
```
カスタム背景画像: 独自の背景画像をアップロードし、assets/ ディレクトリに配置すれば、同様の方法で使用できます

現在利用可能な背景画像:

bg_explaza.png: explazaテーマ用の青系背景
bg_brown.png: modern-brownテーマ用の茶系背景

セットアップスクリプトの主な機能

setup_workspace_simple.sh スクリプトを使用すると、以下の作業が自動的に行われます：

基本ディレクトリ構造の作成
- Flow, Stock, Archived などの基本フォルダ
- ルールファイル用の .cursor/rules フォルダ
- プログラム用フォルダ Stock/programs
Flow内の年月日フォルダ作成
- 現在の日付で Flow/YYYYMM/YYYY-MM-DD 形式のフォルダ作成
各種リポジトリのクローン
- ルールリポジトリ（.cursor/rules/basic など）
- スクリプトリポジトリ（scripts ディレクトリ）
- プログラムリポジトリ（Stock/programs 配下）

User Rules

Cursorの設定からユーザールールを設定してください（推奨）

Cursorの右上にある歯車アイコン（⚙️）をクリック
「Settings」から「Rules」を選択
以下の内容をコピーして貼り付け

#========================================================
# 0. ベースポリシー
#========================================================
! Always respond in 日本語
- 添付されてるRulesがないか確認。あったら必ず読み込むこと。読み込んだら✅などをつける。
- 成果物はできるだけファイルとしてedit_fileして生成してください（細かく分割）
- MCP やファイル閲覧など可能な作業は自律実行
- タスク依頼時は不足情報を確認し、自ら計画→ゴールまで進行
#========================================================
# 0. シェル処理の安全な実行
#========================================================
! 重要: コマンド実行時の禁止事項と推奨方法
- サブシェル関数($(コマンド)形式)は絶対に使用禁止
- バッククォート(`コマンド`)も使用禁止
- パイプ(|)やリダイレクト(>)を使う複雑なコマンドは個別のシンプルなコマンドに分解する
- 日付情報が必要な場合:
  1. まず単独のdate関数を実行してターミナル出力を取得
  2. 出力された日付文字列を次のコマンドで明示的に使用
  3. 例: 「date +%Y-%m-%d」を実行→出力「2024-05-12」→この文字列を直接使用

! コマンド実行の具体例
- NG: mkdir -p Flow/$(date +%Y%m)/$(date +%Y-%m-%d)
- OK: [以下の2ステップに分ける]
  1. date +%Y%m
  2. date +%Y-%m-%d
  3. mkdir -p Flow/{出力1}/{出力2}

#========================================================
# 1. 必須ルールファイル参照（pre‑load）
#========================================================
# ※ pmbok_paths_*.mdc を最優先で読み込み、以降すべて
#    {{dirs.*}} / {{patterns.*}} 変数でパスを参照する
required_rule_files:
 - /Users/<YOUR_USER>/{{PROJECT_ROOT}}/.cursor/rules/basic/pmbok_paths.mdc
  - /Users/<YOUR_USER>/{{PROJECT_ROOT}}/.cursor/rules/basic/00_master_rules.mdc

必要なルールファイル

.cursor/rules/ディレクトリに以下のファイルを配置されます：

basic/pmbok_paths.mdc - パス変数定義
basic/00_master_rules.mdc - マスタールール
basic/01_pmbok_initiating.mdc - 立ち上げフェーズのテンプレート
basic/02_pmbok_discovery.mdc - 発見フェーズのテンプレート
basic/02_pmbok_research.mdc - 調査フェーズのテンプレート
basic/03_pmbok_planning.mdc - 計画フェーズのテンプレート
basic/04_pmbok_executing.mdc - 実行フェーズのテンプレート
basic/05_pmbok_monitoring.mdc - 監視・コントロールフェーズのテンプレート
basic/06_pmbok_closing.mdc - 終結フェーズのテンプレート
basic/08_pmbok_flow_assist.mdc - フロー支援機能
basic/09_pmbok_development.mdc - 開発フェーズ支援
basic/90_rule_maintenance.mdc - ルール自体のメンテナンス用
basic/flow_to_stock_rules.mdc - 自動同期ルール

5. フェーズ別の使い方

0️⃣ 事前準備

# プロジェクト作成ガイド
「カレー作りたい　プロジェクト開始して」  # → プログラム名を尋ねられます
「夕食作り」  # プログラム名を入力
「はい」  # 確認に応答

上記の対話により、以下の処理が行われます：

プログラムディレクトリ作成（Stock/programs/夕食作り）
プロジェクトディレクトリ作成（Stock/programs/夕食作り/projects/カレー）
ドキュメントフォルダ作成（documents/1_initiating など）
Flowフォルダ作成（Flow/YYYYMM/YYYY-MM-DD/夕食作り_カレー）

1️⃣ 立ち上げ（Initiating）

# プロジェクト憲章作成
「プロジェクト憲章を作成したい」  # LLMが質問に導きます
# 質問に回答すると、Flow/YYYYMM/YYYY-MM-DD/draft_project_charter.md が生成されます

# 内容確認後、確定反映
「確定反映して」  # draft_project_charter.mdがStockフォルダに移動

# プロダクト（プログラム）定義
「プロダクト定義」  # プログラムレベルの定義書作成
「確定反映して」  # 確定処理

# ステークホルダー分析
「ステークホルダー分析やりたい」  # 同様に質問と回答で文書作成
「確定反映して」  # 確定処理

2️⃣ 発見（Discovery）

# Discoveryフェーズのメニュー表示
「Discovery」  # 利用可能なテンプレートリスト表示

# 前提条件マップ作成
「仮説マップ」  # 仮説検証に必要な前提条件をマッピング
「確定反映して」  # Flow/YYYYMM/YYYY-MM-DD/draft_assumption_map.md を確定

# ペルソナ作成
「ペルソナ作成」  # ユーザーペルソナ定義
「確定反映して」

# 問題定義
「課題定義」  # 解決すべき問題の定義
「確定反映して」

# その他のDiscoveryドキュメント
「ジャーニーマップ」  # ユーザージャーニーマップ作成
「ソリューション定義」  # ソリューション定義書作成
「検証計画」  # 仮説検証計画
「UXリサーチ」  # UXリサーチ調査概要

2️⃣-B リサーチ（Research）

# Researchフェーズのメニュー表示
「Research」  # 利用可能な調査テンプレート表示

# 顧客調査レポート
「顧客調査」  # 顧客調査レポート作成
「確定反映して」

# 競合調査レポート
「競合調査」  # 競合分析
「確定反映して」

# デスクリサーチ
「デスクリサーチ」  # 市場・業界など総合的な調査
「確定反映して」

# 市場規模推定
「市場規模推定」  # TAM/SAM/SOM分析
「確定反映して」

2️⃣-C プレゼンテーション（Presentation）

# プレゼン資料生成
「プレゼン資料生成」  # Marpを使用したプレゼンテーション作成

# プレゼン用の図表作成
「図表生成」  # draw.ioテンプレートからの図表作成
「確定反映して」  # 編集したプレゼン資料を確定

3️⃣ 計画（Planning）

# WBS作成
「WBS作成」  # 質問に回答してWBSドラフトを作成
「確定反映して」  # 確定処理

# プロダクトバックログ初期化
「プロダクトバックログ初期化して」  # バックログの初期構造作成

# リスク計画
「リスク計画」  # リスク分析と対策計画作成

# プロジェクトスコープ記述書
「プロジェクトスコープ記述書」  # スコープ定義

# プロダクト要求仕様書
「プロダクト要求仕様書」 # PRD作成

# リリースロードマップ
「ロードマップ作成」  # リリース計画作成

4️⃣ 実行（Executing）とDevelopment

# 開発フェーズの開始
「Development」  # 利用可能な開発テンプレート表示

# 開発環境セットアップ
「開発環境初期化」  # 環境セットアップドキュメント作成

# 開発計画
「開発計画作成」  # 実装計画書作成

# 実装順序計画
「実装順序計画」  # 依存関係を考慮した実装順序の定義

# ストーリー実装
「ストーリー実装」  # 個別ストーリー実装計画

# スプリントゴール
「スプリントゴール」 # Sprint Goal Sheet作成

# 日次タスク
「今日のタスク」  # 日次タスクリスト生成

5️⃣ 監視・コントロール（Monitoring）

# 変更要求管理
「変更要求」  # 変更要求テンプレート作成

# スプリントレビュー
「スプリントレビュー作成」  # レビュー自動生成

6️⃣ 終結（Closing）

# 教訓記録
「教訓記録」  # Lessons Learned作成
「確定反映して」

# 移管ドキュメント
「移管ドキュメント作成」  # 引き継ぎ資料作成

5.5 全トリガーワード対応表

以下に、システムで使用できるすべてのトリガーワードをフェーズ別にまとめています。各コマンドがどのルールファイル内で定義されているか、必要とする情報も示しています。

フェーズ1：立ち上げ（Initiating）

トリガーワード	対応するルールファイル	必要情報	出力ファイル
プロジェクト初期化プロジェクト開始プロジェクト立ち上げ	basic/01_pmbok_initiating.mdc	プログラムID、プロジェクトID、目的、開始日、終了日、ステークホルダー	(ディレクトリ構造)
"XXX始めたい" "XXX作りたい" (プロジェクト名+開始したい)	basic/01_pmbok_initiating.mdc	プログラム名（プロダクトのカテゴリー）	(ディレクトリ構造)
プロダクト定義プロダクト目標定義 Product定義プログラム定義	pmbok/01_pmbok_initiating.mdc	プロダクト名、目標・ビジョン、関連するOKR、背景と目的	draft_program_definition.md
プロジェクト憲章プロジェクトチャーター	basic/01_pmbok_initiating.mdc	プロジェクト名、目的、背景、成果物、予算、マイルストーン	draft_project_charter.md
ステークホルダー分析ステークホルダーマップ	basic/pmbok_initiating.mdc	主要ステークホルダー、役割、期待、影響力、関与度	draft_stakeholder_analysis.md
リスク分析リスク計画	basic/pmbok_planning.mdc	リスク項目、影響度、発生確率、対応策、責任者	draft_risk_plan.md
作業開始 work start 今日の作業開始	basic/00_master_rules.mdc	なし	daily_tasks.md

フェーズ2：リサーチ（Research）

トリガーワード	対応するルールファイル	必要情報	出力ファイル
リサーチ Research	basic/00_master_rules.mdc (メニュー表示)	なし	なし
顧客調査 Customer Research	basic/02_pmbok_research.mdc	プロジェクト名、ターゲットオーディエンス、調査トピック、業界背景	draft_customer_research.md
競合調査 Competitor Research	basic/02_pmbok_research.mdc	プロジェクト名、自社製品/サービス概要、主な競合、調査フォーカス	draft_competitor_research.md
デスクリサーチ Desk Research	basic/02_pmbok_research.mdc	プロジェクト名、調査範囲、調査トピック、業界背景	draft_desk_research.md
市場規模推定 TAM SAM SOM フェルミ推定	basic/02_pmbok_research.mdc	プロジェクト名、ビジネスモデル、ターゲット顧客、地域、推定アプローチ	draft_market_size_estimation.md

フェーズ2：発見（Discovery）

トリガーワード	対応するルールファイル	必要情報	出力ファイル
ディスカバリー Discovery	basic/00_master_rules.mdc (メニュー表示)	なし	なし
仮説マップ Assumption Map	basic/02_pmbok_discovery.mdc	主な仮説、検証方法、前提条件	draft_assumption_map.md
ペルソナ作成 Persona	basic/02_pmbok_discovery.mdc	ユーザー像、年齢・職業、目標、課題、行動パターン	draft_persona.md
課題定義 Problem Statement	basic/02_pmbok_discovery.mdc	問題概要、影響、原因、解決の価値	draft_problem_statement.md
ユーザージャーニーマップ User Journey Map ジャーニーマップ	basic/02_pmbok_discovery.mdc	ユーザー、フェーズ、行動、感情、課題、機会	draft_user_journey_map.md
ソリューション定義 Solution Definition	basic/02_pmbok_discovery.mdc	提案するソリューション、機能要件、成功基準	draft_solution_definition.md
検証計画 Validation Plan	basic/02_pmbok_discovery.mdc	検証仮説、方法、成功基準、スケジュール	draft_validation_plan.md
UXリサーチユーザー調査 UX調査	basic/02_pmbok_discovery.mdc	調査目的、質問、方法、参加者要件	draft_ux_research_overview.md
インタビュー設計インタビュー質問質問表作成	basic/02_pmbok_discovery.mdc	調査目的、質問リスト、進行手順	draft_interview_guide.md
リクルーティングユーザー募集被験者募集	basic/02_pmbok_discovery.mdc	対象者プロフィール、募集方法、参加条件	draft_recruiting_plan.md
インタビュー分析インタビュー結果インタビュー記録	basic/02_pmbok_discovery.mdc	参加者ID、主な発見、引用、洞察	draft_interview_analysis_{{participant_id}}.md
リサーチサマリー調査サマリー全体分析	basic/02_pmbok_discovery.mdc	調査目的、方法、主要な発見、次のステップ	draft_research_summary.md
仮説バックログ Hypothesis	basic/02_pmbok_discovery.mdc	仮説一覧、優先度、検証方法、成功基準	draft_hypothesis_backlog.md
アイディア発散	basic/08_pmbok_flow_assist.mdc	テーマ、アイデア、評価基準	draft_flow_assist.md
プレゼン資料生成	basic/02_pmbok_presentation.mdc	タイトル、発表者、対象者、主要ポイント	draft_presentation.md

フェーズ3：計画（Planning）

トリガーワード	対応するルールファイル	必要情報	出力ファイル
プロジェクトスコープ記述書 Project Scope Statement	basic/03_pmbok_planning.mdc	プロジェクト範囲、成果物、除外事項、制約、前提条件	draft_project_scope_statement.md
プロダクト要求仕様書 PRD Product Requirements Document	basic/03_pmbok_planning.mdc	製品概要、ユーザー、要件、優先度、制約	draft_product_requirements.md
Design Doc デザインドック設計文書	basic/03_pmbok_planning.mdc	システム概要、アーキテクチャ、コンポーネント、インターフェース	draft_design_doc.md
WBS作成作業分解構造	basic/pmbok_planning.mdc	主要フェーズ、サブタスク、所要時間、担当者	draft_wbs.md
プロダクトバックログ初期化 backlog初期化バックログ初期化	basic/pmbok_planning.mdc	プロダクト名、ストーリー一覧、優先度、見積もり	backlog.yaml, epics.yaml
ルーチンタスク定義 routines作成ルーティン定義	basic/07_task_management.mdc	日次/週次/月次タスク、スケジュール、所要時間	routines.yaml
バックログが正しく出力されたか確認バックログ検証バックログ確認バックログチェック	basic/00_master_rules.mdc	検証したいバックログYAMLのパス	検証結果（ターミナル出力）
ルーチンタスクが正しく出力されたか確認ルーチンタスク検証ルーチン検証ルーチンチェック	basic/00_master_rules.mdc	検証したいroutines.yamlのパス	検証結果（ターミナル出力）
ロードマップ作成プロダクトロードマップリリース計画	basic/pmbok_planning.mdc	リリース計画、マイルストーン、機能、日程	draft_product_roadmap.md

フェーズ4：実行（Executing）

トリガーワード	対応するルールファイル	必要情報	出力ファイル
今日のタスク日次タスク作成 Daily tasks	basic/07_task_management.mdc	当日の作業予定、完了タスク、メモ	daily_tasks.md
週次レビュー Weekly review	basic/07_task_management.mdc	週番号、主な成果、課題、次週の計画	weekly_review.md
Sync WBSと同期リスクログと同期	basic/07_task_management.mdc	対象アーティファクト、更新内容	(既存のWBSやリスクログを更新)
開発フェーズ Development 実装フェーズ	basic/00_master_rules.mdc (メニュー表示)	なし	なし
開発環境初期化 Development初期化実装環境セットアップ	basic/09_pmbok_development.mdc	プロジェクト名、技術スタック、開発環境要件	draft_dev_setup.md
開発計画作成 Development計画実装計画	basic/09_pmbok_development.mdc	機能一覧、技術スタック、スケジュール、担当者	draft_dev_plan.md
実装順序計画開発順序ストーリー依存関係	basic/09_pmbok_development.mdc	ストーリーリスト、依存関係、優先度	draft_implementation_order.md
ストーリー実装実装開始ユーザーストーリー実装	basic/09_pmbok_development.mdc	ストーリーID、実装詳細、タスク分割	draft_dev_story.md
記事執筆ドキュメント作成記事作成	basic/09_pmbok_development.mdc	タイトル、概要、対象読者、構成	draft_dev_article.md
成果物確認実装確認確定レビュー	basic/09_pmbok_development.mdc	レビュー対象、確認項目、フィードバック	draft_development_review.md
スプリントゴール Sprint Goal	basic/pmbok_executing.mdc	スプリント番号、期間、目標、成功基準、デモ項目	draft_sprint_goal_{{sprint_number}}.md
議事録ミーティングノート	basic/pmbok_executing.mdc	会議名、日時、参加者、議題、決定事項、アクション	draft_meeting_minutes.md

フェーズ5：監視・コントロール（Monitoring）

トリガーワード	対応するルールファイル	必要情報	出力ファイル
変更要求チェンジリクエスト	basic/pmbok_monitoring.mdc	変更内容、理由、影響範囲、優先度	draft_change_request.md
スプリントレビュー作成 Sprint Review	basic/pmbok_executing.mdc	スプリント番号、達成事項、デモ項目、課題、次のステップ	draft_sprint_review_{{sprint_id}}.md

フェーズ6：終結（Closing）

トリガーワード	対応するルールファイル	必要情報	出力ファイル
教訓記録レッスンラーニドレッスンずらーんど	basic/pmbok_closing.mdc	成功事例、改善点、学び、提案	draft_lessons_learned.md

ユーティリティ

トリガーワード	対応するルールファイル	必要情報	出力ファイル
確定反映して	flow_to_stock_rules.mdc	対象ドラフトファイル	(Stock内の対応ファイル)
フェーズ追加 Phase追加新フェーズ作成	basic/90_rule_maintenance.mdc	フェーズ名、トリガーワード、ルールの詳細	新規ルールファイル

各ドキュメント間の参照関係

開発やドキュメント作成時に参考にできる主な参照関係は以下の通りです：

ペルソナ作成：市場調査レポート、ユーザーインタビュー結果、競合調査結果を参照すると効果的
プロジェクト憲章：プロダクト定義、ステークホルダー分析、リスク分析を基にすると整合性が高まる
バックログ初期化：プロダクト要求仕様書、WBS、ユーザージャーニーマップの内容を反映させると良い
スプリントゴール：プロダクトバックログ、ロードマップを参照して設定すると計画との整合性が確保できる
週次レポート：日次タスク、スプリントゴール、課題記録の情報を集約して作成すると効率的
実装計画：バックログ、デザインドック、技術仕様書を基に作成すると実装の指針が明確になる

6. ユースケース：カレープロジェクト

以下は、実際のプロジェクト例として「カレー作り」プロジェクトの流れを示します。

1. プロジェクト初期化

User: カレー作りたい　プロジェクト開始して
AI: 「カレー」のプログラム名（カテゴリ）を教えてください。
User: 夕食作り
AI: 以下の内容でプロジェクトを初期化します：
    プログラム: 夕食作り
    プロジェクト: カレー
    よろしいですか？
User: はい

この対話により、以下のフォルダ構造が作成されます：

Stock/programs/夕食作り/projects/カレー/
└── documents/
    ├── 1_initiating/
    ├── 2_discovery/
    ├── 2_research/
    ├── 3_planning/
    ├── 4_executing/
    ├── 5_monitoring/
    └── 6_closing/

Flow/202505/2025-05-05/夕食作り_カレー/
└── daily_tasks.md

2. プロジェクト憲章の作成

User: プロジェクト憲章つくって
AI: 【プロジェクト憲章】の作成に必要な情報を収集します。以下の質問に回答してください。
    1. プロジェクト名: カレー
    2. プロジェクトの目的: 
    3. プロジェクトの背景: 
    [...]
User: おまかせ
AI: 収集した情報で「プロジェクト憲章」のドラフトを作成してよろしいですか？
User: はい

AIは以下の内容を含む詳細なプロジェクト憲章を作成します：

プロジェクト概要（名前、期間、オーナー）
目的と背景
スコープ（含まれるもの/含まれないもの）
成果物
ステークホルダー一覧
マイルストーン
予算（食材費3,000円、消耗品500円）
リスク管理計画
制約条件と前提条件

3. ペルソナの作成

User: ペルソナ作成して
AI: 【ペルソナ作成】に必要な情報を収集します。以下の質問に回答してください。
    1. ペルソナの名前: 
    2. 年齢・世代: 
    [...]
User: おまかせ

AIは以下の詳細情報を含むペルソナを作成します：

基本情報：田中健太（42歳、IT企業PM、4人家族）
ライフスタイル：平日は仕事、週末は料理担当
目標と課題：家族の好みにばらつきがある、調理時間の見積もりが苦手
行動特性：レシピサイトやSNSで情報収集、家族の意見を聞いて決定
好みと傾向：程よい辛さのカレーが好き
使用ツール：スマートフォン、料理アプリ
代表的な発言：「家族が笑顔になる料理を作りたいな」

この例はプロジェクト管理手法を日常的なタスクに適用する方法を示しており、以下のフェーズに進むことで、カレープロジェクトは成功へと導かれます：

Discovery：材料や調理方法の調査
Planning：レシピ決定、買い物リスト作成
Executing：材料購入、調理
Monitoring：味の調整
Closing：完成・振り返り

7. 主要コマンドリファレンス

文書作成コマンド（トリガーワード）

立ち上げフェーズ

コマンド	説明	出力先
「プロジェクト初期化」	プログラム・プロジェクト構造作成	Stock/programs//projects//
「プロダクト定義」	プロダクト（プログラム）定義書作成	Flow/YYYYMM/YYYY-MM-DD/draft_program_definition.md
「プロジェクト憲章」	プロジェクト憲章作成	Flow/YYYYMM/YYYY-MM-DD/draft_project_charter.md
「ステークホルダー分析」	ステークホルダー分析	Flow/YYYYMM/YYYY-MM-DD/draft_stakeholder_analysis.md

Discoveryフェーズ

コマンド	説明	出力先
「仮説マップ」	前提条件マップ作成	Flow/YYYYMM/YYYY-MM-DD/draft_assumption_map.md
「ペルソナ作成」	ユーザーペルソナ作成	Flow/YYYYMM/YYYY-MM-DD/draft_persona.md
「課題定義」	問題定義書作成	Flow/YYYYMM/YYYY-MM-DD/draft_problem_statement.md
「仮説バックログ」	仮説リスト作成	Flow/YYYYMM/YYYY-MM-DD/draft_hypothesis_backlog.md
「ジャーニーマップ」	ユーザージャーニーマップ	Flow/YYYYMM/YYYY-MM-DD/draft_user_journey_map.md

Researchフェーズ

コマンド	説明	出力先
「顧客調査」	顧客調査レポート	Flow/YYYYMM/YYYY-MM-DD/draft_customer_research.md
「競合調査」	競合分析レポート	Flow/YYYYMM/YYYY-MM-DD/draft_competitor_research.md
「デスクリサーチ」	総合調査レポート	Flow/YYYYMM/YYYY-MM-DD/draft_desk_research.md
「市場規模推定」	TAM/SAM/SOM分析	Flow/YYYYMM/YYYY-MM-DD/draft_market_size_estimation.md

プレゼンテーションフェーズ

コマンド	説明	出力先
「プレゼン資料生成」	Marpによるスライド作成	Flow/YYYYMM/YYYY-MM-DD/draft_presentation.md
「図表生成」	Draw.io図表テンプレート作成	Flow/YYYYMM/YYYY-MM-DD/assets/diagram.drawio

Planningフェーズ

コマンド	説明	出力先
「WBS作成」	WBSドラフト作成	Flow/YYYYMM/YYYY-MM-DD/draft_wbs.md
「リスク計画」	リスク分析と計画	Flow/YYYYMM/YYYY-MM-DD/draft_risk_plan.md
「プロジェクトスコープ記述書」	スコープ定義書	Flow/YYYYMM/YYYY-MM-DD/draft_project_scope_statement.md
「プロダクト要求仕様書」	PRD作成	Flow/YYYYMM/YYYY-MM-DD/draft_product_requirements.md
「ロードマップ作成」	リリース計画	Flow/YYYYMM/YYYY-MM-DD/draft_product_roadmap.md

Developmentフェーズ

コマンド	説明	出力先
「開発環境初期化」	環境セットアップ	Flow/YYYYMM/YYYY-MM-DD/development/draft_setup.md
「開発計画作成」	実装計画書	Flow/YYYYMM/YYYY-MM-DD/development/draft_development_plan.md
「実装順序計画」	実装順序定義	Flow/YYYYMM/YYYY-MM-DD/development/draft_implementation_order.md
「ストーリー実装」	ストーリー実装計画	Flow/YYYYMM/YYYY-MM-DD/development/draft_story_implementation.md

Executingフェーズ

コマンド	説明	出力先
「スプリントゴール」	スプリント目標設定	Flow/YYYYMM/YYYY-MM-DD/draft_sprint_goal_Sn.md
「今日のタスク」	日次タスク	Flow/YYYYMM/YYYY-MM-DD/daily_tasks.md
「議事録」	会議議事録	Flow/YYYYMM/YYYY-MM-DD/draft_meeting_minutes.md

Closingフェーズ

コマンド	説明	出力先
「教訓記録」	教訓記録	Flow/YYYYMM/YYYY-MM-DD/draft_lessons_learned.md
「移管ドキュメント作成」	引き継ぎ資料	Flow/YYYYMM/YYYY-MM-DD/draft_transition_document.md

システムコマンド

コマンド	説明
「確定反映して」	Flow→Stock同期を実行
「作業開始」	今日の日付フォルダとタスクファイルを作成
「フェーズ追加」	新しいフェーズルールの雛形を生成

8. バックログ管理

本システムでは、プロダクトバックログをYAML形式で管理する方法を採用しています。この方法には大きなメリットがありますが、YAMLの可読性については工夫が必要です。

YAMLでバックログを管理する利点

AIエージェントとの親和性: YAML形式はCursorエージェントが正確に解析・操作できるため、口語的な指示でもバックログを効率的に更新できます
構造化された情報管理: 階層構造を持つバックログを自然に表現でき、ストーリー間の関係性を明確に記述できます
変更操作の簡便さ: 「ストーリーAのステータスを完了に変更して」「担当者をBさんに変更して」といった指示をAIに伝えるだけで正確に更新されます
他システムとの連携: YAMLはプログラムで扱いやすく、JIRAやGitHubなど他のツールとの連携も容易です

バックログの初期化と管理

プロダクトバックログは「プロダクトバックログ初期化」「backlog初期化」「バックログ初期化」などのトリガーワードを使用することで自動生成できます。初期化プロセスではプロジェクト名、ストーリー一覧、優先度、見積もりなどの情報を入力することで、構造化されたbacklog.yamlとepics.yamlファイルが生成されます。

生成されたバックログは日次タスク作成やスプリント計画などの下流プロセスで活用されるため、正しく機能することが重要です。特にYAML形式のファイルはインデントや構文に敏感なため、「バックログ検証」「バックログ確認」などのトリガーワードを使用して定期的に検証することをお勧めします。これにより、バックログの構造的な問題を早期に発見し、タスク管理プロセス全体がスムーズに動作することを確保できます。

バックログ操作テクニック

YAMLファイルをAIエージェントで効率的に操作するテクニック：

User: バックログのストーリーUS-123のステータスを「完了」に変更して、担当者を田中さんにしてほしい

AI: backlog.yamlを更新します:
    - ストーリーUS-123のステータスを「完了」に変更
    - 担当者を「田中」に変更
    変更を行いますか？

User: はい

AI: backlog.yamlを更新しました。以下が変更内容です:
    - US-123のstatus: "in-progress" → "done"
    - US-123のassignee: "佐藤" → "田中"

このようにUI操作よりも自然言語での指示の方が、場合によってはスピーディーで正確なバックログ管理が可能になります。

ルーチンタスク定義機能

Backlogとは別に、ルーチンタスクというものも別に定義できます。違いは、バックログは一度きりのタスクですが、ルーチンは繰り返し実行するタスクです。プロジェクトのルーチンタスクを定義するには、以下のトリガーワードを使用できます：

User: ルーチンタスク定義して

または、以下のトリガーワードも同様の機能を呼び出します：

「routines作成」
「ルーティン定義」

このコマンドを実行すると、AIがルーチンタスクに関する情報を収集するための質問を行います。質問に回答すると、プロジェクトのルートディレクトリにroutines.ymlファイルが自動生成されます。

ルーチンタスク定義の主な機能：

日次、週次、月次のルーチンタスクを簡単に定義
曜日や日付指定でのタスクスケジュール設定
所要時間や依存関係の設定
プロジェクト固有のルーチンワークフローの定義

作成したルーチンタスク定義は、「確定反映して」コマンドでStockフォルダに移動でき、「日次タスクまとめて」コマンドで自動的に参照されるようになります。

ルーチンタスク定義ファイルの例

各プロジェクトのルートディレクトリにroutines.ymlを作成することで、プロジェクト固有のルーチンタスクを定義できます：

朝の作業ルーティンタスクの例

morning_routines:
  name: "朝の作業ルーティン"
  description: "出社時に行うべき作業の標準セット"
  total_estimate: 34 # 分単位の合計見積もり
  items:
    - id: "RT-001"
      reference: "US-001"
      title: "Slackのフォローアップ確認"
      estimate: 5
      priority: 1

    - id: "RT-002"
      reference: "US-002"
      title: "PCデスクトップの整理"
      estimate: 1
      priority: 2

    - id: "RT-003"
      reference: "US-003"
      title: "出勤登録"
      estimate: 3
      priority: 1

ルーチンタスクもバックログタスク同様、作成後に「ルーチンタスクの検証をして」ということで、正しいフォーマットで出力されたか確認できます。

YAML可読性向上のためのツール

バックログやルーチンタスクのYAMLをより見やすく表示するために、以下のツールを推奨します：

VSCode拡張機能「Yaml2Table Preview」
- Marketplace リンク
- インストール方法: VSCodeのQuick Open (Ctrl+P)でext install adautomendes.yaml2table-previewを実行
- 使用方法: YAMLファイルを開いた状態でCtrl+Shift+Pから「Yaml2Table: Open preview」を選択
VSCodeの標準YAML拡張機能
- YAMLの構文ハイライト、入れ子構造の折りたたみ、スキーマ検証などの基本機能を提供
- これだけでもかなり見やすくなります

8. 日次タスク管理

日次タスク機能は、複数プロジェクトにまたがる作業を一元管理し、日々の業務を効率化するための機能です。複数のソースから情報を自動的に集約し、その日に集中すべきタスクの全体像を把握できます。

日次タスクの主な機能

User: 日次タスクまとめて

このコマンドを実行すると、以下の情報が自動的に集約されます：

Googleカレンダーからの予定取得（※追加設定が必要）
- その日のミーティングやイベントを時系列で一覧表示
- 会議の準備や事前作業が必要なものを強調表示
プロジェクトバックログからのタスク抽出
- 各プロジェクトのbacklog.ymlから、現在のスプリントに割り当てられたタスクを抽出
- 担当者フィルタリングや優先度ソートにも対応
ルーチンタスクの確認
- 各プロジェクトのroutines.ymlに定義された定期的な作業を抽出
- 曜日やプロジェクトフェーズに応じた適切なルーチンを表示

日次タスクの活用方法

日次タスク機能は単なるタスク表示だけでなく、以下のようなワークフローを支援します：

朝の作業開始時
- 「日次タスクまとめて」でその日の全体像を把握
- 優先度の高いタスクを特定して計画を立てる
日中の進捗管理
- タスクの完了状況をチェックリスト形式で記録
- タスク実行中に発生した課題やメモを記録
終業時の振り返りと更新
- 進捗状況を「バックログ更新して」コマンドで各プロジェクトのbacklog.ymlに反映
- 翌日に持ち越すタスクを確認
- 学びや気づきを記録

Googleカレンダー連携機能（オプション）

Googleカレンダーから予定を直接取得するには、以下のリポジトリで公開されているアプリケーションのセットアップが必要です：

calendar_app - Google Apps Script & Claspを使用したカレンダー連携ツール

このアプリケーションを導入すると、エージェントが直接Googleカレンダーから予定を取得できるようになり、MCPの不安定さを回避した安定した運用が可能になります。セットアップ方法は上記リポジトリのREADMEを参照してください。

セットアップ後は「予定確認」と入力するだけで、Googleカレンダーからの予定取得が可能になります。

タスク管理のベストプラクティス

一貫したステータス管理: バックログとの整合性を保つため、タスクのステータス更新は日次タスク→バックログの流れを保つ
複数プロジェクトの並行管理: 関連タスクをプロジェクト横断で確認することで、リソース配分を最適化
記録の習慣化: 実施したこと、気づき、課題は日次タスクに都度記録し、知見を蓄積
日々のバックログ更新: 一日の終わりに「バックログ更新して」コマンドで正式な進捗状況を反映

9. ルール追加と拡張プロセス

システム自体を成長させるため、新しいルールの追加や既存ルールの拡張機能が組み込まれています。ルール追加自体もルール化することで、システムの継続的進化を促進します。

ルール拡張の基本的な流れ

「フェーズ追加」トリガー: チャットで「フェーズ追加」や「新フェーズ作成」と入力すると、ルール拡張モードが起動します
情報収集: システムが新規フェーズやルールに関する情報を質問します
自動ルール生成: 情報を基に必要なルールファイル更新を行います

自動更新される要素

ルール追加機能は主に以下の3つの要素を自動的に更新します：

マスタールールへのトリガー追加: 00_master_rules_kc.mdc にトリガーキーワードと処理フローを追加
専用ルールファイルの作成/更新: 新しいフェーズ専用のルール（例: 0X_pmbok_xxxxx.mdc）を作成するか、既存のカテゴリに質問やテンプレートを追加
パス変数の追加: pmbok_paths.mdc に必要なパス変数を追加（これにより実際のパスを変数で参照可能になる）

使用例

User: フェーズ追加
AI: 新しいフェーズやルールを追加します。以下の情報を教えてください：
    1. 追加したいフェーズ/ルール名:
    2. 主な機能や目的:
    3. 必要なトリガーワード:
    ...

User: マーケティングフェーズを追加したい。
     トリガーワードは「マーケティング計画」「広告戦略」など。
     成果物としてはマーケティング計画書、広告戦略、分析レポートなど。

AI: 以下の内容でルールを追加します：
    1. マスタールールにトリガーワード追加
    2. 12_pmbok_marketing.mdc ファイル作成
    3. パス変数追加
    
    よろしいですか？

User: はい

AI: ルール追加が完了しました。
    以下のファイルが作成/更新されました：
    - .cursor/rules/pmbok/00_master_rules_kc.mdc
    - .cursor/rules/pmbok/12_pmbok_marketing.mdc
    - .cursor/rules/pmbok/pmbok_paths_kc.mdc

    「マーケティング計画」と入力して新機能をテストできます。

カスタムルールのメリット

再利用性: 一度定義したルールはプロジェクト間で再利用可能
一貫性: テンプレートやワークフローの標準化により、チーム全体での一貫性を確保
効率化: 繰り返し作業が自動化され、本質的な思考に集中できる
知識の形式化: チームの知見やベストプラクティスをルールとして形式化し共有

ルール追加自体もルール化することで、プロジェクト完了時や作業が一段落した時点で「次回からはこうしたい」という改善をすぐにシステムに反映できます。たとえ面倒に感じる場合でも、このプロセスが習慣化されることで、システムは継続的に進化していきます。

10. よくある質問 (FAQ)とベストプラクティス

システムとツールの利用

Q1. トリガーワードが反応しない場合はどうすればいいですか？

A1. Rulesの限界により、トリガーワードが期待通り動作しない場合があります。その場合でも、LLMはRuleを読まなくてもPMBOKの知識をベースに基本的な対応はしてくれますが、カスタムテンプレートは無視される可能性があります。対処法：

明示的なルール指定: トリガーワードが属するルールを明示的にメンションする（例: @01_pmbok_initiating.mdc）
情報源の指定: 特定のプロジェクト文書を参照させたい場合は、明示的にドキュメントを指定する
基本に戻る: うまく動かない場合は、通常のプロンプトとして質問を具体的に記述する

Q2. Cursorの特徴と限界について教えてください

A2. Cursorの主な特徴と実用上のポイント：

ルールファイル参照: MDファイルに書いたプロンプトをメンションするだけで呼び出せるため、毎回同じ指示を書く必要がない
生成物の再利用: 前のプロンプトで生成された成果物を次のプロンプトの入力に簡単に使える
限界: ルールファイルの読み込みが常に完璧ではなく、Thinkingペインでの表示や動作に不安定な部分がある
β版としての位置づけ: 本システムは継続的に改善されており、不具合や改善点のフィードバックを歓迎

チーム活用のベストプラクティス

Q3. チームでの成果物共有はどのように行うのが最適ですか？

A3. Stockフォルダの共有: GitHubやObsidian（Sync機能）などのファイル共有サービスを活用して、Stockフォルダをチーム全体で共有しましょう。これにより、確定した成果物に全員がアクセスできるようになります。

Q4. プロジェクト固有のニーズに対応するにはどうすればよいですか？

A4. プロジェクト固有のルール: 独自のフォルダ（例: .cursor/rules/project_specific/xxxxx.mdc）を作成し、プロジェクト固有のルールを定義・共有することをお勧めします。これにより、プロジェクトの特性に合わせたカスタマイズが可能になります。

Q5. 新メンバーの導入をスムーズにする方法はありますか？

A5. セットアップの簡易化: setup_config.sh をカスタマイズして、プロジェクト固有のルールやプロジェクトのレポジトリを設定しておくと、新しいメンバーの初期設定が簡単になり、チームの生産性向上に役立ちます。

Q6. チーム全体で効率的に連携するためのワークフローは？

A6. 以下のようなチーム連携のワークフローをお勧めします：

各メンバーは自分のローカル環境で Flow で作業
確定した成果物は Stock に反映
共有リポジトリに定期的にプッシュ/コミット
チームミーティングで成果物をレビュー
フィードバックを Flow で反映させて改善サイクルを継続

このアプローチにより、個人の作業とチーム全体の成果を効率的に統合できます。

Q7. モデル選択とルール読み込みのコツはありますか？

A7. 最適な結果を得るためのヒント：

推奨モデル: ThinkingモードでClaude3.7を使用。高品質アウトプットが必要な場合はMAXモデルが推奨
ルール参照確認: Thinkingペインで「Rulesを読み取ってます」などの表示があればOK
明示的指定: うまく動作しない場合は、チャット入力時に@から必要なRuleを明示的に指定
マスタールール重視: 特に「Master Rules」が最重要。これが読み込まれていれば基本機能は動作

11. 開発Tips

このワークスペースは単なるドキュメント管理だけでなく、開発活動自体もサポートする機能を備えています（※ベータ版/試験運用中）。

開発フェーズの活用方法

.cursor/rules/basic/09_pmbok_development.mdc に定義されたルールを活用することで、以下のような開発ワークフローを実現できます：

開発環境初期化（「開発環境初期化」と入力）
- プロジェクト専用の開発フォルダ構造を自動生成
- 必要な初期ファイルのセットアップ
- 開発環境構成の定義
開発計画作成（「開発計画作成」と入力）
- 対象ストーリーの特定
- 実装アプローチの定義
- 技術スタックの選定
実装順序計画（「実装順序計画」と入力）
- ストーリー間の依存関係分析
- 優先度付けと最適な実装順序の決定
- フェーズ分けと実装スケジュール案の作成
ストーリー実装（「ストーリー実装」と入力）
- 個別ストーリーの詳細な実装計画
- 実装ステップの定義
- 主要コード構造の設計
記事執筆（「記事執筆」と入力）
- 技術記事やドキュメントの構成立案
- 執筆プラン作成
- 添付資料の管理
成果物確認（「成果物確認」と入力）
- 開発成果物の品質チェック
- レビュープロセスの実施
- Flow→Stockへの確定プロセス

開発ディレクトリ構造

開発作業は以下のディレクトリ構造で管理されます：

プロジェクト/
├── development/           # 開発成果物のルートディレクトリ
│   ├── code/              # コードベース（ソフトウェア開発の場合）
│   ├── articles/          # 記事/ドキュメント（コンテンツ作成の場合）
│   └── assets/            # 共有リソース（画像、データなど）
└── documents/             # プロジェクトドキュメント（既存）

開発Tipsの活用例

ユーザーストーリーを「実装順序計画」で最適な順序に整理
最重要ストーリーを「ストーリー実装」で詳細設計
同時並行で「記事執筆」機能を使って技術ドキュメントを作成
開発完了後「成果物確認」でレビューし、Stockに確定

このワークフローにより、プロジェクト管理と開発作業を一貫したプロセスで進めることができます。

13. 作った人

プロフィール

株式会社エクスプラザで生成AIエバンジェリスト・リードAIプロデューサーを務める宮田大督。生成AI技術の社会実装と普及に注力し、企業のAI導入支援やコミュニティ活動を推進。

前職のGaudiyや令和トラベルでは、SNSでのエージェント実装やDifyなどノーコードツール活用での大量コンテンツ生成など、様々な企画から実際の実装まで手がける。楽天やメルカリでのPdMの経験を活かし、PdMに関する登壇・執筆活動も行い、最近はAIxPM領域に特に関心をもち活動している。

生成AI技術の可能性と実践的な活用方法について情報発信を行い、企業のDX推進やイノベーション創出をサポート。AIと人間が共生する未来の実現を目指し、技術と社会の架け橋となることを使命としている。

SNSアカウント

Twitter: @miyatti

企業情報

会社名：株式会社エクスプラザ
ミッション：「プロダクトの力で、豊かな暮らしをつくる」
事業内容：生成AIの活用支援/プロダクトマネジメントコンサルティング事業
設立：2020年7月
代表者：高橋一生
本社：東京都港区六本木4-8-5 和幸ビル503
コーポレートサイト：https://explaza.jp/
採用ページ：https://lifeat.explaza.jp/

14. 参考ブログ記事

実際の活用事例

実際のCursorエージェントとのやり取り例（Twitter）
- ブログ作成プロジェクトでの実際の対話例を公開しています
- システムがどのように質問し、ユーザーの意図を理解していくかがわかります

活用シナリオ

ブログ記事作成プロジェクト管理
技術ドキュメント整備
研究プロジェクト管理
小規模チームでの業務効率化

基本コンセプトとCursorエージェント活用法

このシステムの背景にある考え方や活用方法について、以下の記事も参考にしてください：

解説資料

これらの記事では、Cursorを使ったAIエージェントによるタスク管理、プロジェクト管理、文書作成の自動化などについて詳しく解説しています。本システムを最大限に活用するためのヒントやテクニックを学ぶことができます。

15. 著作権・ライセンス・免責事項

著作権

本「俺の考えた最強のAIPMシステム with Cursor Agent」のコンテンツ（テキスト、ルールファイル、スクリプト、ドキュメント構造など）は、作者の許可なく無断で複製、配布することはできません。

ライセンス

本システムは以下のライセンス条件の下で提供されます：

個人利用: 個人的な学習、プロジェクト管理、非商用目的での利用は無償で許可されます。
社内利用: 一つの法人・団体内でのプロジェ 5D03 クト管理ツールとしての利用は無償です。
商用利用: 本システムをベースにした有料サービスの提供、コンサルティングなど営利目的で利用する場合は、作者への連絡が必要です。
配布・改変: 改変版の作成・配布を行う場合は、オリジナルの著作権表示とこのライセンス条件を維持し、作者のクレジットを明記してください。

免責事項

本システムは「現状有姿」で提供され、明示または黙示を問わず、いかなる種類の保証もありません。システムの利用によって生じた直接的または間接的な損害について、作者は責任を負いません。

連絡先

著作権、ライセンス、商用利用に関するお問い合わせ：

Twitter: @miyatti
会社: 株式会社エクスプラザ

謝辞

本システムの開発にあたり、多くの方々からのフィードバックとサポートをいただきました。特に、初期テスト段階でご協力いただいたコミュニティメンバーの皆様に感謝いたします。

Name		Name	Last commit message	Last commit date
Latest commit History 25 Commits
.gitignore		.gitignore
README.md		README.md
setup_config.sh		setup_config.sh
setup_workspace_simple.sh		setup_workspace_simple.sh

miyatti777/aipm_v0

Folders and files

Latest commit

History

Repository files navigation