はじめに
こんにちは、Lighthouse Studioの新卒1年目エンジニアの きっちゃん です。
最近はAIエージェント搭載のエディタ等(Cline, Cursorなど)を利用するのが当たり前になり、自力でコードを書く機会が減ってきています。
完全自律型AIエージェントであるDevinに至っては、スマホからSlackで指示を出すだけで、PCを開くことすらせずにPRが出来上がったりもするわけで...
そこで最近、まず初めにプロンプトを作成する「プロンプト駆動開発」を試しています。 本記事では、その概要と恩恵について紹介します。
結論として、プロンプトを整理することで要件や仕様の解像度が高まり、結果的により早く、より的確な開発を進められるようになります。
プロンプト駆動開発って何？
プロンプト駆動開発とは、AIに投げるプロンプトを最初に整理することから始める開発スタイルです。
(自分なりの開発スタイルを説明するために命名しただけなので、もし同名の既存手法が存在していても、それとは別物だと思ってください)
どんな感じで進めるの？
この開発スタイルでは、まず初めにAIに投げるプロンプトを書くことから始めます。プロンプトを書き終わった段階でそのタスクにおいてやるべきことの8割は終えているイメージです。
前提や背景、やりたいこと、制約など、実装に必要な情報を整理してプロンプトに盛り込みます。
プロンプトを書き終えたら、AIに渡して実装結果を確認します。結果として期待通りの実装が得られれば、そのまま終了です。
もし期待した結果にならなかったら、その差がどの程度かを観察します。
数行程度のミスや細かい修正程度なら、自分で手を動かして修正しても良いですし、具体的な変更点を伝えてAIに再度修正を依頼しても構いません。
一方で、意図とはまったく異なる結果が返ってくることもあります。
その場合は、そもそもAIに任せるには難しいタスクだったのか、プロンプトの作り方に問題があったのかを判断します。
AIに任せるには難しいタスクだった場合でも、プロンプトを作成した段階で実装に必要な情報が整理されているため、それを元に自力で作業を進められるので、無駄にはなりません。
プロンプトの書き方に問題がある場合は、さらに2つのケースに分けて考えます。
タスクの粒度が大きすぎる場合 : タスクを小さく分割して、それぞれに新たなプロンプトを作成します。 分割後のプロンプトでも、やりたいことやそのプロンプトの立ち位置だけ明確にしてあげれば、その他の部分は共通して使いまわすことができます。
プロンプトの書き方が悪い場合 : これは上手くいくまでトライアンドエラーするしかありません。 「なぜAIが勘違いしたのか」を観察しながら修正していきます。 コツとして、同じセッションで繰り返し指示を与えるとプロンプトとAIの知識にズレが生じるので、セッションをリセットし、なるべく1つのプロンプトだけで完結するように整えます。 もし1つのプロンプトで完結が難しい場合は、タスクの粒度が大きい可能性があるので再度分割を検討しましょう。
プロンプトには何を書くの？
タスクによって変動しますが、現時点でよく使っている項目を挙げます。
ここで意識しているのは、AIに対するプロンプトであると同時に、自分やチームメンバーへのドキュメントであるということです。 理想は、プロンプトを読むことで、今回のタスクに対する理解と実装が再現できる状態です。
前提
コードを読み解くヒントになるシステムやドメインについて書きます。 特に一般的な意味とは異なる使われ方をする用語などは説明しておくと良いです。 この辺はDevinのKnowledgeやclinerulesのようなルールファイルで管理することが理想的です。
背景
なぜこのタスクに取り組むのかを書きます。 どんな課題が存在していて、何を改善したいのか。この機能を作ることでどう問題が解消されるのかを明確にします。
やりたいこと
今回のタスクで実現したい目標を整理します。 曖昧に「〜ができるようにしたい」だけではなく、達成すべき要件をなるべく具体的に挙げます。 どこまで実装すればタスクが完了するか判断できる状態を作ります。
既に実装していること
タスクに関連し、再利用可能なコードや参考になるコードを示します。
まだ実装していないこと
新しく実装が必要な要素を書きます。 実装すべきファイルの場所や、具体的な関数名やファイル名まで指定すると精度が向上します。 AIの自由度を狭めることで意図通りの実装を得やすくなります。
制約
コーディング規約、動作環境、フレームワークのバージョンなど、提供すべき制約を書きます。 タスクを超えて共通する内容は、DevinのKnowledgeやclinerulesのようなルールファイルで管理するのが理想的です。
補足
上記に含めていないが、補足として伝えるべき情報や備考があれば書きます。（特になければ省略します）
これ、何が嬉しいの？
背景や前提を最初に整理することで、要件や仕様への理解が深まり、実装途中での手戻りが減ります。
チーム内でプロンプトを共有すれば、タスクに関する認識合わせが容易になり、着手前に詳細なフィードバックを得ることができます。
さらに、プロンプトとして仕様を言語化することで、少し整理すればそのままシステムのドキュメントとして流用できる点も大きな利点です。
また、タスクの内容を細かく明文化することで、自分自身がタスクへの理解度（解像度）を高められ、結果的に再現性のある質の高いコードを書ける(または生成できる)ようになります。
さいごに
プロンプトの内容を見て気づいたと思いますが、「タスク着手から完了までの思考や工程を言語化したもの = プロンプト」となっています。
以前は細かくタスクを分解しないと精度が出なかったものが、最近では勝手にタスクを分解しながら精度高く実装してくれるケースが増えてきました。半年後、1年後には今の自分よりも優秀になっているでしょう。
つまり、今後はコードを書く技術よりも、システムを理解し、要件を整理する能力が重要になるはずです。そのため、プロンプト駆動開発は、そんな未来に向けて必要な能力を鍛えるうえでも役立っています。
