Zenn
LayerXPublicationへの投稿
🏢

エンジニアの工夫で実現する、ビジネス組織のCursor活用環境の構築術

うぱ | upamune
に公開
AI
Git
Markdown
Cursor
tech

LayerX バクラク事業部 でソフトウェアエンジニアをしている@upamuneです。

最近はCursorの活用が広がっていますが、組織内でエンジニア以外がCursorを活用するには、まだいくつかハードルがあります。
バクラク事業部では、エンジニア以外のBizチームの方々も簡単かつ効果的に利用できるように、利用者のセットアップコストを極限まで下げた仕組みを構築したので、参考にしていただけると嬉しいです！

0. 前提条件

この仕組みを利用するには、以下の前提条件が必要です：

  • GitHubアカウントを持っていること（組織内のリポジトリへのアクセス権限が必要）
  • Gitがインストールされていること

1. はじめに：組織でのCursor活用の課題

組織内でエンジニア以外がCursorを活用するには、いくつかハードルがあります。

  • Cursorはルールを整備すると良いらしいけど、どういうルールを書けばいいのかわからない
  • Cursorを使うためのコードやドキュメントをどこから持ってきて、どう配置すれば良いのかわからない
  • 頑張ってコードやドキュメントを配置したけど、それをどうやったら最新版に追従させ続けるのかがわからない

もちろん、Cursorは個人でファイルを開いて使うだけなら簡単です。しかし、組織で活用する場合、特に非エンジニアが業務で使う場合は話が変わります。製品仕様を理解したい、データ分析をしたい、ヘルプドキュメントを参照しながら作業したいなど、様々なコンテキストが必要になり、それらを個人で管理するのは現実的ではありません。

そのハードルを自力で超えられる方は良いですが、AIで業務効率化したいと思っていてもハードルが高くて始められないという方々のための仕組み、Cursorを最速で効率的に使うためのリポジトリを社内で構築しました。

この仕組みで目指すことは以下の通りです。

  • Cursorがインストールされているだけで動作する（他のNode.js などの実行環境を必要としない）
  • 特殊な設定が必要なく、すぐにCursorの恩恵を得られる
  • セットアップにターミナルを一切利用しない
  • 自分好みにカスタマイズできる余地は残す
    • 自分専用の Cursor ルールの設定など

自分ですべてをカスタマイズしたい方の欲求は満たしません。その人は自分で構築すれば良いので割り切ります。

まずはCursorをセットアップする時の問題について見ていきます。

2. Cursorをセットアップする時の問題

💣 問題1: コンテキストをかき集めてくるのが大変

まず、この仕組みを利用する想定メンバーは幅広く、プロダクトマネージャー・カスタマーサポート・カスタマーサクセス・セールスです。

それぞれのメンバーがやりたいことも様々で、SnowflakeへSQLクエリを投げる手助けにしたい、製品のコード・ヘルプガイドを元に仕様理解をしたいなど、多岐に渡ります。

そのため、以下のようなコンテキストが必要になります。

  • プロダクトのソースコード
  • プロダクトのZendeskにあるヘルプガイド
  • プロダクトのNotionにある仕様
  • Snowflake(データウェアハウス)のスキーマ

これらを、それぞれのメンバーが自分でかき集めて来たとしても、それらを最新に更新していくのも大変です。

💣 問題2: Cursorルールの整備

Cursorはルールを整備することでより強力になります。
しかし、初めてCursorを触る人にとってはどういうルールを書けば良いのか分かりません。

様々なコンテキストがある中で、何がどういうものであるかを指し示すのは誰に取っても有用なものなので、ある程度共通化したいルールもあります。

💣 問題3: ファイルの配置場所の判断

多くの人が悩む問題ではないでしょうか。個々人ごとに工夫をしていると思いますが、これもまたコンテキストの置き場と同じようにどこに配置するのが良いのか迷うと思います。

3. 解決策：3つのアプローチ

これらの問題を解決するためのリポジトリを用意して、それを使ってもらうようにしました。
端的に説明すると、コンテキストはサブモジュールで管理して、編集して欲しいところは .gitkeep だけ配置してその他のファイルは .gitignore するような構成にしています。

まず、リポジトリの全体の構成です。（⚠️ リポジトリの名前は例です）

.
├── .cursor
│   └── rules
│       ├── shared-xxx.mdc
│       └── shared-yyy.mdc
├── .github
│   └── workflows
│       └── update_submodules.yml
├── .gitignore
├── .gitmodules
├── .vscode
│   ├── extensions.json
│   ├── settings.json
│   └── tasks.json
├── README.md
├── code
│   ├── bakuraku-backend # サブモジュール
│   └── bakuraku-webapps # サブモジュール
├── docs
│   └── bakuraku-zendesk # サブモジュール
├── notes
│   └── .gitkeep
└── schema
    └── bakuraku-snowflake # サブモジュール

ここまでの問題を解決している仕組みを1つずつ見ていきましょう。

✅ 問題1: コンテキストをかき集めてくるのが大変 👉 サブモジュールで解決

code ディレクトリ配下にはプロダクトのコードをサブモジュールで配置しています。この例だと、 code/bakuraku-backend と code/bakuraku-webapps がそれにあたります。

docs 配下にはZendeskヘルプガイドをマークダウン形式でエクスポートしている bakuraku-zendesk リポジトリがサブモジュールで配置されています。

schema 配下にはSnowflakeのスキーマが入っているリポジトリがサブモジュールが配置されています。

これでコンテキストを集めてくるのが面倒な問題と、最新に追従するのが面倒な問題はサブモジュールによって解決されます。GitHub Actionsの update_submodules.yml のワークフローによって、サブモジュールは定期的に更新されるようになっています。

問題として、このリポジトリを取得してきてもサブモジュールも含めて取得するにはコマンド実行が必要でしたが、どうしてもターミナルを触る必要がないようにしたかったため、 .vscode/tasks.json をコミットして、CursorのUIから 更新 を選択すればサブモジュールを含めて取得・更新できるようにしています。

.vscode/tasks.json
{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "更新: update-repo",
      "type": "shell",
      "command": "git pull --recurse-submodules --autostash --rebase && git submodule update --init",
      "presentation": { "reveal": "always" },
      "problemMatcher": []
    },
  ]
}

✅ 問題2: Cursorルールの整備 👉 共通ルールのコミット

.cursor/rules に shared- から始まるルールは共通ルールとしてコミットしています。

├── .cursor
│   └── rules
│       ├── shared-xxx.mdc
│       └── shared-yyy.mdc

.gitignore には以下のように書いているため、 shared- から始まるルールはgit管理されますが、それ以外のルールはgit管理されません。
そのため、それぞれの個人で自分専用のルールを配置したい場合は shared- から始まる以外の名前のルールにすれば問題ありません。

#---- Cursor Rules ----
# デフォルトで全 .mdc を無視
.cursor/rules/*.mdc
# ただし shared-*.mdc だけ追跡する
!.cursor/rules/shared-*.mdc

コミットしているルールはRule Typeが Always ルールの例で言うと、このリポジトリについてどこにどういうコンテキストがあるのかを教えるものであったり、プロダクトの基本的なことについて書いています。
Rule Typeが Manual ルールの例で言うと、 shared-bakuraku-snowflake-sql.mdc のように、Snowflakeを使う時用のルールなどがあります。

✅ 問題3: ファイルの配置場所の判断 👉 ファイルを配置する場所の指定

├── notes
│   └── .gitkeep

基本的にこのリポジトリを使う人は notes ディレクトリ配下にファイルを配置します。

.gitignore には以下のように書いているため、ディレクトリを維持するための .gitkeep ファイルは存在しますが、それ以外はgit管理下に置かれません。

.gitignore
#---- notes ----
notes/*
!notes/.gitkeep

そのため、この仕組みを使う人は、notes ディレクトリ配下に作ることだけを守っておけば、自由にファイルやディレクトリを配置することができます。
その中でどういうファイルやディレクトリの配置するかは職種や個人によって違うと思うので、そこはあえて縛りを設けていません。

まとめ：3つのアプローチによる解決

この3つのアプローチによって、先に挙げた3つの問題は解決しました。
ここまでで必要最低限をセットアップできるようになりましたが、次からはあると嬉しい追加の仕組みを見ていきます。

4. おすすめ拡張機能提案

インストールすると、Cursorがこのリポジトリでインストールすべき機能を提案してくれます。

これは、 .vscode/extensions.json をリポジトリにコミットしているためです。

Markdownファイルをよく扱ったりするため、Markdownの拡張機能を中心にインストールしています。

この拡張機能と、この拡張機能を入れて... とするのは入れる方も大変ですし、違う拡張機能を入れてしまうこともあるので、簡単にインストールできるように設定しています。

.vscode/extensions.json
{
  "recommendations": [
    "yzhang.markdown-all-in-one",
    "shd101wyy.markdown-preview-enhanced",
    "takumii.markdowntableformatter",
    "EditorConfig.EditorConfig",
    "marp-team.marp-vscode",
    "ms-ceintl.vscode-language-pack-ja",
    "takumii.markdowntable",
    "janisdd.vscode-edit-csv",
    "catppuccin.catppuccin-vsc",
    "catppuccin.catppuccin-vsc-icons",
    "bierner.markdown-mermaid"
  ]
}

5. おすすめCursor設定

Cursorというより、Visual Studio Codeの設定ですが、これもコミットしているため共有されています。

.vscode/settings.json は以下のようになっています。
自動保存できるようにして欲しいという要望があったので最初からそうなるようにしたり、面白いのが「明るいテーマがいい」という方々が多かったので Catppuccin Latte を指定して、ライトテーマな白いテーマを採用しています。これは要望をしてもらうまで思ったことなかったので新たな発見でした。

.vscode/settings.json
{
  "[markdown]": {
    "editor.wordWrap": "on",
    "files.trimTrailingWhitespace": false
  },
  "markdown.extension.toc.levels": "2..4",
  "markdown.extension.toc.updateOnSave": true,
  "files.associations": {
    "*.mdx": "markdown"
  },
  "git.autofetch": true,
  "git.detectSubmodules": true,
  "explorer.excludeGitIgnore": false,
  "editor.rulers": [80, 120],
  "editor.semanticHighlighting.enabled": true,
  "terminal.integrated.minimumContrastRatio": 1,
  "workbench.colorTheme": "Catppuccin Latte",
  "files.autoSave": "afterDelay",
}

6. まとめ

この仕組みを導入すれば、以下のステップで使い始められるようになります。

  1. Cursorを起動
  2. CursorのClone repoにGitHubのリポジトリURLを指定
  3. Cursorの タスクの実行 から 更新 を選択し、サブモジュールを更新
  4. 下から出てくる拡張機能のおすすめのポップアップから拡張機能をインストール

利用する側はこれだけで、必要なコンテキストが整備され、コンテキストも最新に追従でき、Cursorルールもセットアップされ、おすすめの設定が反映された状態でCursorを利用することができるようになりました。

なお、これらのセットアップ手順は動画でも録画して社内で共有しています。実際の画面を見ながら操作できるため、初めての方でも迷うことなくセットアップできるようになっています。

7. 導入後のサポート体制

この仕組みを導入するだけでなく、継続的に活用してもらうために、専用のSlackチャンネルを用意しています。

このチャンネルでは以下のようなやり取りが行われています：

  • 使い方に関する質問と回答
  • 新しい活用方法の共有
  • この仕組みの改善要望の収集
  • 実際のユースケースの共有

特に非エンジニアの方々から「こんな使い方ができた！」という報告が上がってくることで、他のメンバーの参考になり、組織全体でのCursor活用が加速しています。

8. おわりに

この記事では、組織全体でCursorを活用するための環境構築方法を紹介しました。個人利用とは異なり、組織での活用には様々なコンテキストの管理が必要ですが、今回紹介した仕組みによって、非エンジニアの方でも簡単にCursorを使い始められるようになります。

もしあなたの組織でも同じような課題を抱えている場合は、ぜひこの仕組みを参考にしてみてください。より良いアイデアがあれば、ぜひコメントで教えていただけると嬉しいです！

実際に、この仕組みを使ってのユースケースを書いてくれているnoteも出ているので、こちらもぜひ！

コードを書かないBiz職こそCursorを使った方が良い理由（エンジニアとの協働でもっと業務を加速できる）

LayerX
LayerXPublication

すべての経済活動を、デジタル化する。SaaS + Fintech に取り組む LayerX のエンジニアの記事が集まる Publication です。

Discussion