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

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

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

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

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

┌──────────────────────────────┐   trigger（チャットコマンド）
│ 00_master_rules.mdc           │◀───────────────────────┐
└─────────┬────────────────────┘                        │
          call                                          │
┌─────────▼────────────┐   発散/収束も 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の骨格にLean UXのDiscoveryとアジャイルDeliveryをレイヤー合成しているため、上流で迷わず・開発中に学び・下流で残せるワークフローが1つにまとまります。

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

プロジェクトルート/
├── .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/      # アーカイブ済みプログラム

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

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

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

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

1. 自動適用: テーマCSS内で設定された背景画像が lead クラスのスライドに自動的に適用されます

2. Markdown内で指定: 特定のスライドに異なる背景画像を適用したい場合

   ![bg](assets/bg_explaza.png)

3. カスタム背景画像: 独自の背景画像をアップロードし、assets/ ディレクトリに配置すれば、同様の方法で使用できます

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

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

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

1. 基本ディレクトリ構造の作成

   • Flow, Stock, Archived などの基本フォルダ
   • ルールファイル用の .cursor/rules フォルダ
   • プログラム用フォルダ Stock/programs

2. Flow内の年月日フォルダ作成

   • 現在の日付で Flow/YYYYMM/YYYY-MM-DD 形式のフォルダ作成

3. 各種リポジトリのクローン

   • ルールリポジトリ（.cursor/rules/basic など）
   • スクリプトリポジトリ（scripts ディレクトリ）
   • プログラムリポジトリ（Stock/programs 配下）

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

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

#========================================================
# 0. ベースポリシー
#========================================================
! Always respond in 日本語
- 成果物はできるだけファイルとして出力（細かく分割）
- MCP やファイル閲覧など可能な作業は自律実行
- タスク依頼時は不足情報を確認し、自ら計画→ゴールまで進行
- 立てた計画はタスクリストとして提示
- 日付に関する処理をやるときは、必ずdate関数で正確な情報を確認

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. マスタールールへのトリガー追加: 00_master_rules_kc.mdc にトリガーキーワードと処理フローを追加
2. 専用ルールファイルの作成/更新: 新しいフェーズ専用のルール（例: 0X_pmbok_xxxxx.mdc）を作成するか、既存のカテゴリに質問やテンプレートを追加
3. パス変数の追加: 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 開発環境初期化（「開発環境初期化」と入力）

   • プロジェクト専用の開発フォルダ構造を自動生成
   • 必要な初期ファイルのセットアップ
   • 開発環境構成の定義

2. 開発計画作成（「開発計画作成」と入力）

   • 対象ストーリーの特定
   • 実装アプローチの定義
   • 技術スタックの選定

3. 実装順序計画（「実装順序計画」と入力）

   • ストーリー間の依存関係分析
   • 優先度付けと最適な実装順序の決定
   • フェーズ分けと実装スケジュール案の作成

4. ストーリー実装（「ストーリー実装」と入力）

   • 個別ストーリーの詳細な実装計画
   • 実装ステップの定義
   • 主要コード構造の設計

5. 記事執筆（「記事執筆」と入力）

   • 技術記事やドキュメントの構成立案
   • 執筆プラン作成
   • 添付資料の管理

6. 成果物確認（「成果物確認」と入力）

   • 開発成果物の品質チェック
   • レビュープロセスの実施
   • Flow→Stockへの確定プロセス

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

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

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

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

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

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

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

1. VSCode拡張機能「Yaml2Table Preview」

   • Marketplace リンク
   • インストール方法: VSCodeのQuick Open (Ctrl+P)でext install adautomendes.yaml2table-previewを実行
   • 使用方法: YAMLファイルを開いた状態でCtrl+Shift+Pから「Yaml2Table: Open preview」を選択

   

2. VSCodeの標準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操作よりも自然言語での指示の方が、場合によってはスピーディーで正確なバックログ管理が可能になります。

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

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

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

• Twitter: @miyatti

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

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

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

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

• あなたの仕事に"AI秘書"を。ノンエンジニアでもOKなCursorエージェント超入門
• プロジェクト管理もストレスもAIがサポート！ ノンエンジニアでもOKなCursorエージェント講座 実践編

• Cursorエージェント講座 超応用編
• ノンエンジニアでもOKなCursorエージェント講座

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

© 2025 宮田大督 (Daisuke Miyata)

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

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

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

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

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

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

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