Cursorでなんちゃって仕様駆動開発

はじめに

こんにちは！朝日新聞社エンジニアの長坂です。
普段はクロスサーチやけんさくくんといった、学校や図書館向けの記事データベースサービスを担当しています。

この記事では、AI開発ツール「Cursor」を活用して、上記サイトでも使用されているDBのデータ移行プログラムを開発した事例をご紹介します。

今回のタスクについて

担当したのは、数十万件の記事データを旧DB（MySQL）から新DB（OpenSearch）へ移行するタスクです。

旧DBはRDBのため、記事の情報は記事テーブル、著者テーブル、画像情報テーブル・・・のように、複数のテーブルに分かれて格納されていました。
一方、移行先のOpenSearchでは、これらを記事ごとのJSONドキュメントにまとめる必要がありました。

▼データ構造のイメージ（※実際のデータとは異なります）

旧DB: MySQLの複数テーブル例

テーブル名	テーブル内容	データ例
articles	記事情報	id: 1, title: '記事の見出し', article: '記事本文・・・'
authors	著者情報	id: 101, name: '〇〇記者'
photos	画像情報	id: 33, file: 'photo33.png', detail: '〇〇の事件現場'

↓

新DB: OpenSearchのJSON例

{
  "id": 1,
  "title": "記事の見出し",
  "article":"記事本文・・・",
  "authors": [
    { "id": 101, "name": "〇〇記者" }
  ],
  "photos": [
    { "id": 33, "file": "photo33.png", "detail": "〇〇の事件現場" }
  ]
}

このように、1つの記事に複数の著者が紐づくようデータを配列にまとめたり、不要なカラムを除外したり、その他諸々、、、新DBにあった形式への変換が求められました。

Cursorを使った「なんちゃって仕様駆動開発」を試す

なぜ仕様書から始めたか

今回、複雑な変換ロジックを正確に実装する必要がありました。当時はAIによる開発も初めてでしたし、いきなりCursorにコードを生成させると後からそのコードを読み解くのが大変そう…と思ったので、まずは人間が理解しやすい日本語の仕様書をAIに作らせ、それを片手にコードレビューを進める方がやりやすそうだと考えました。

全体の流れ

実際の開発は、以下のようなサイクルで進めました。

各ステップの詳細

1. 仕様書の作成

Cursorに要件を箇条書きで伝え、マークダウン形式で仕様書を生成させました。

▼Cursorに投げた指示の例

dumpファイルを読み込んでOpenSearchに投入するJSONに変換するpythonプログラムを作ります。まずは以下の通りに仕様書を作って。
- idごとにJSONにして
- 1つのidに複数のauthorsがあったら配列にして
...

2. 実装とコードレビュー

仕様書を元にCursorに実装させた後、そのままコードを読むのではなく、まずは「このコードの解説書を作って」と依頼しました。
そして、生成された「仕様書」と「解説書」を片手にコードレビューを進めていきます。読みながらわからないところは直接チャットで聞けるので、ググる手間も省けました。特にありがたかったのは、実際に関数の出力例や処理途中の値の変化などもわかりやすく説明してくれた点です。

3. テスト

テストデータの作成も「テストデータ○件作って」という大雑把な指令を出してから、様子を見つつ「改行が２個連続するデータ作って」という具体的な指令に移行していく感じでCursorと進めました。
先に完璧なスペックを作るのは難しかったので、進めながらCursorに見てもらってどんどんパターンを追加していくという手法を取りました。
地味に面倒なテストデータの作成や確認も一瞬で終わって助かりました！

やってみて感じたこと

仕様書の粒度について

実際にやってみて一番難しかったのは、仕様書の粒度のコントロールでした。どこまで定義しておくのか？暗黙知となっているところはないか？などの確認が難しかったです。

AI相手だから「手戻り」が怖くない

「実装してから仕様書に戻る」という手戻りは、人間同士でウォーターフォール的に開発していると大きな時間的・心理的コストになります。しかし、相手がAIなのでサッと修正がかかり、何度も修正しても大きなロスにならないのは大きなメリットだと感じました。これは人力開発にはない、AI開発ならではの利点だと思います。

大まかな構成は人間が担う？

一点注意が必要だと感じたのは、プログラムの構成についてです。特に指示をしないと、Cursorはどんどんファイルや関数を細かく分割していく傾向がありました。

最初は「仕様書1つで全部定義して上手いことやってくれ〜」という感じで丸投げしたのですが、結局こちらが考えた単位のプログラムごとに分けて仕様書を作成してもらいました。

どの処理をどのファイルや関数に切り出すかなど全体の構成や処理の粒度は、ある程度人間が設計思想を持って指示する方がいいのかもなと感じました。ルールであらかじめ指示するのがスマートな気もしますが、小規模であれば大枠は自分で考えるほうがいいのかも。古い考えな気もしますが、ここももう少し勉強していきたいです。

まとめ

CursorのようなAIツールを使えば、一人でもAIと一緒に思考しながら開発できると感じました。
忙しい先輩にはなかなか聞けないことも、AIなら納得できるまで質問できます。今回はCursorが仕様書の作成〜テストまで、共に伴走してくれました。

実装当時に「仕様駆動開発」という単語は意識していませんでしたが、今回のようにAIに仕様書を作らせてから実装を進める方法で、その一端を体感できた気がします。

最近は単語自体を耳にすることも増えましたし、次は仕様駆動特化型ツールなども試したいなと思います！