はじめに

API仕様書はSwaggerに落としながらも詳細な実装内容やロジック的なところは設計書として別で管理していることが多いです。
その中でもConfluenceはそう言ったものをドキュメント化するのにとても使い勝手がよく、APIの設計書などもConfluenceに落とすパターンもあります。

そのため、その設計書をCursorに読みに行かせてそのままある程度実装してほしいなと思った次第です。
構成はLaravel+Nginx+MySQLでエージェントモデルはGemini2.5proで実装してもらいます。

接続設定

今回は最近ベータ版で出たAtlassian公式のMCPを利用します。
先行して出ていた非公式のMCPもあり、そちらはDockerDesktop経由で利用できますが、せっかく公式のベータ版が出てますし、公式MCPでは認証トークンも必要なくローカル環境もnode.js環境があれば利用できるので、公式利用で問題ないと思います。

Cursorにてmcp.jsonに下記の設定をします。

{
"mcpServers":{
"atlassian": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.atlassian.com/v1/sse"]
}
}
}

Cursor SettingsのMCPタブにて下記のように緑色のステータスなら問題ないです。
黄色のままの人は、Cursorを再起動したり、node.jsが環境に入っているか確認してください。

設定後に自動でブラウザに飛ばされ連携設定を促されるので従ってボタンを押すだけで良いです。

以上で設定は完了です。

設計書準備

よく案件で使う形の設計書に近づけた簡易的なユーザの一覧を返すAPIの設計書を作成しました。


Project Ruleの準備

簡易的な実装方法のルールだけ作ります。

description：API実装方法
## 実装の流れ
コンテナを立ち上げる
コマンド：docker compose up -d --build
confuluenceからAPI設計書（MCP）配下の子ページのAPI設計書を取得する
取得したAPIに合わせてテーブル構成変更のマイグレーションを実行する
API設計書に合わせてAPIを実装する

## Confluenceで参考にする設計書の場所
スペース名：nakaji_haruto
設計書ページ：API設計書（MCP）配下の子ページ

## 開発ルール
バリデーションはリクエストクラスに記載
スキニーコントローラとする
ビジネスロジックはサービスクラスに記載
Eloquentを優先して利用
複雑なクエリはないためリポジトリパターンは使わない

いざ開発してもらう

まずはコンフルから設計書を取得してもらうところからです。
しっかりMCPツールを利用してくれています！
ただ、画像を見てもらえばわかるように、スペース名検索では拾えず、一覧をとってきて照合という挙動になり、基本的にキー指定での検索対応になります。
キーがわからない場合は、画像のようにスペース名からキーを教えてくれるので、それを利用する形で良いと思います。

そして無事に設計書の親ページは発見できたようです。
ちなみに設計書の親をフォルダにしていると、なかなか取得できず何度かやりとりしてやっとという形でした。

発見した設計書の親ページから見た子ページに設計書があるかどうか確認してもらい、あれば取得してもらいます。
出力は見にくいですが、しっかり取得できてそうです。

そのまま実装も開始してもらえてそうですね。
テーブル変更におけるマイグレーションも気を遣ってやってくれていますね。

実際に実装完了した際のフォルダ構成としては下記のようになってました。
フォルダ構成に関しては詳細なルールづけをしていないですが、その中でもしっかり則ってくれたのではないかなと思います。

そして、実装が完了したので、APIをリクエストしてみると下記のようにレスポンスが帰ってきました。
レスポンスも設計書まんまですね。

リクエストバリデーションもしっかり設計書通りです！

さいごに

簡易的なAPIとはいえ、設計書読み込ませるだけで、ここまで忠実になるとは思っていませんでしたのでこれから設計書はAI接待気味に書いてエージェントに投げてやるのが良さそうですね。
今回は簡素なPorject Ruleですが、しっかりプロジェクトのアーキテクチャを落とし込んでやれば、そこも対応して実装してくれると思うので、人間がしっかり確認することを前提に個人的には案件でも即利用可能レベルのものだと思ってます。
使いものになるかどうかは、もはやルール設定を人間がしっかりできるか次第な気もしました。

参考