Cursor RulesリポジトリへのDevSecOpsとプロジェクト管理ガイドのRule追加（開発日記 No.068）

この記事はgemini-2.5-pro-exp-03-25によって自動生成されています。

関連リンク

• 前回の開発日記

はじめに

昨日は、CursorのRuleを管理するための @my-cursor-rules リポジトリを作成し、最初のRuleとして development_process_guide.md をベースにしたファイル群を整備しました。
今日はその勢いを借りて、さらに複数のドキュメントをRule化していく作業に取り組みます。具体的には、devsecops_guide.md、project_management_guide.md、pytest_best_practices.md、quality_dashboard_guide.md の4つのドキュメントが対象です。

背景と目的

これらのドキュメントには、開発プロセスにおける重要な知識やベストプラクティスが詰まっています。これらをCursorのRuleとして体系化することで、AIエージェントがこれらの情報をより効率的に活用できるようになり、開発支援の質を向上させることが目的です。特に、専門的な知識を必要とする場面や、特定のタスクを実行する際に、適切なガイダンスを提供できるようにしたいと考えています。

検討内容

昨日と同様の規則で、各ドキュメントを知識Rule、専門モードRule、参照ドキュメントに分割していきます。

まず、devsecops_guide.md についてLLMと相談しながら分割案を練りました。このドキュメントはDevSecOpsの概要から各種セキュリティツールの使い方まで幅広くカバーしているため、以下のような方針で分割することにしました。

• 知識Rule: DevSecOpsの全体像や、セキュリティツールの一般的な概念などを記述。
• 専門モードRule: 脅威モデリング支援、SAST実行、DAST実行など、具体的なアクションを伴うタスクごとにモードを作成。これらは既存の包括的な開発実行モード (mode_development_execution.mdc) から呼び出せるようにする。
• 参照ドキュメント: BanditやSemgrepといった具体的なツールの使い方やコマンド例などを、それぞれ独立したMarkdownファイルとして保存。

次に、project_management_guide.md についても同様に分割案を検討しました。こちらはプロジェクト管理の基本、GitHubの活用法、テスト戦略、品質管理、ドキュメント管理など、多岐にわたるトピックを含んでいます。こちらも知識Rule、モードRule、参照ドキュメントに分割する方針で合意しました。

実装内容

LLMに指示を出しながら、具体的なRuleファイルの作成を進めました。

1. devsecops_guide.md の Rule 化

検討した方針に基づき、以下のファイル群を作成し、@my-cursor-rules リポジトリの適切なディレクトリに配置しました。

• 知識 Rule:
  • my-cursor-rules/knowledge/knowledge_devsecops_overview.mdc
  • my-cursor-rules/knowledge/knowledge_security_tools_general.mdc
• 参照ドキュメント:
  • my-cursor-rules/references/sast_bandit_usage.md
  • my-cursor-rules/references/sast_semgrep_usage.md
  • my-cursor-rules/references/dast_owasp_zap_usage.md
  • my-cursor-rules/references/sca_pip_audit_usage.md
  • my-cursor-rules/references/sca_trivy_usage.md
  • my-cursor-rules/references/secrets_detect_secrets_usage.md
  • my-cursor-rules/references/container_hadolint_usage.md
• 専門モード Rule:
  • my-cursor-rules/modes/mode_threat_modeling_support.mdc
  • my-cursor-rules/modes/mode_sast_execution.mdc
  • my-cursor-rules/modes/mode_dast_execution.mdc
  • my-cursor-rules/modes/mode_sca_execution.mdc
  • my-cursor-rules/modes/mode_secret_detection.mdc
  • my-cursor-rules/modes/mode_container_security_scan.mdc
  • my-cursor-rules/modes/mode_incident_response_support.mdc

さらに、これらの新しい専門モードRuleを呼び出せるように、既存の包括的モードRuleである my-cursor-rules/modes/mode_development_execution.mdc を更新しました。
一連の変更をGitにコミットして、devsecops_guide.md のRule化は完了です。

2. project_management_guide.md の Rule 化

続いて、project_management_guide.md のRule化に着手しました。まずは知識Ruleから作成を進め、以下のファイルを作成しました。

• 知識 Rule:
  • my-cursor-rules/knowledge/knowledge_project_management_overview.mdc
  • my-cursor-rules/knowledge/knowledge_github_basics_for_pm.mdc
  • my-cursor-rules/knowledge/knowledge_test_strategy_overview.mdc
  • my-cursor-rules/knowledge/knowledge_quality_management_overview.mdc
  • my-cursor-rules/knowledge/knowledge_documentation_management.mdc

しかし、knowledge_development_iteration_overview.mdc の作成に取り掛かったところで、想定よりも時間がかかっていることに気づきました。キリの良いところで本日の作業を終えることにし、LLMにその旨を伝えました。

技術的なポイント

• Ruleの粒度: ドキュメントの内容を、知識として提供すべき部分、特定のタスク実行を支援するモードとして機能させるべき部分、詳細な手順やコマンド例として参照させるべき部分、と適切に切り分けることが重要でした。
• モードの連携: 新しく作成した専門モードを、既存の包括的なモードから呼び出す形にすることで、Ruleのモジュール性と再利用性を高めました。これにより、AIエージェントは状況に応じて適切な専門モードを起動しやすくなります。
• 命名規則とディレクトリ構造: 昨日定めた命名規則 (knowledge_*.mdc, mode_*.mdc, *_usage.md など) とディレクトリ構造 (knowledge/, modes/, references/) に従うことで、多数のファイルを体系的に管理できています。

所感

devsecops_guide.md のRule化は、対象範囲が広く、多くのツールや概念を整理する必要があったため、なかなか骨の折れる作業でした。しかし、一つ一つの知識や手順をRuleファイルに落とし込んでいく中で、情報が整理され、AIエージェントが活用しやすい形になっていくのを実感でき、大きな達成感がありました。特に、各種セキュリティスキャンを専門モードとして独立させたことで、より具体的な開発支援が期待できそうです。

一方で、project_management_guide.md のRule化は道半ばで中断となってしまいました。こちらも概念的な内容が多く、知識Ruleへの分割・記述に思ったより時間がかかっています。LLMとの共同作業は効率的ではあるものの、大量のドキュメントを処理するにはやはりそれなりの時間が必要です。

また、作業の途中でLLMに「開発日記をつけていないようだ」と指摘される一幕がありました。自動ログ機能に頼っていた部分で抜け漏れがあったようで、AIとの協調作業においても、最終的な確認や指示の明確化は人間の重要な役割だと再認識しました。この点は今後の開発プロセスでも気をつけていきたいです。

全体として、多くのRuleファイルを作成・管理する作業なので、初期段階で命名規則やディレクトリ構造をしっかり設計しておいたことが、今日のスムーズな（時間はかかりましたが）作業進行に繋がったと感じています。

今後の課題

本日の作業は途中で中断となったため、明日以降に持ち越すタスクがいくつかあります。

• project_management_guide.md の Rule 化完了:
  • 残りの知識 Rule (ドキュメント内 AIエージェント中心の開発イテレーションサイクル 以降のセクションに対応するもの) の作成。
  • 合意済みの分割案に基づき、モード Rule と参照ドキュメントを作成。
  • 必要に応じて、作成したモード Rule を mode_development_execution.mdc に統合。
  • 完了後、変更をGitにコミット。
• pytest_best_practices.md の Rule 化に着手:
  • ドキュメントを読み込み、知識 Rule、モード Rule、参照ドキュメントへの分割案を検討・提示し、合意を得る。
  • 合意に基づき、各種 Rule ファイルを作成。
• quality_dashboard_guide.md の Rule 化に着手:
  • 上記 pytest_best_practices.md と同様の手順で進める。
• 開発日記の継続的な記録:
  • 作業の区切りごとに、進捗と決定事項を確実に記録する。

まとめ

本日は、@my-cursor-rules