ソフトウェア開発においても生成AIの活用が進みつつあり、いろいろ調べていく中で「システムプロンプト」という言葉が気になりました。
システムプロンプト
AIモデルに対してどう振る舞ってほしいかを指定する指示メッセージのことです。
既存のシステムがある状態での機能追加に生成AIを使ってみたとき、生成されたコードが設計方針に沿っていないものとなり手直しが必要となる場合に遭遇することがあります。
「既存のシステムやプロジェクトに合わせてシステムプロンプトやその他の環境を整備してやることで、より良い成果物を生成してくれるのではないか?」ということでお試ししました。
検証準備 - サンプルアプリケーション -
検証の準備として、サンプル実装と仕様書を用意します。
サンプル実装はPythonとDjangoで実装したWeb APIを用意しました。
企業と従業員情報をデータベースで管理し、企業一覧と従業員一覧を取得するものです。
仕様書は、テーブル定義とER図、API仕様書を用意しました。
テーブル定義とER図はPlantUMLで作成し、API仕様書はSwaggerで作成したものです。
機能追加として、企業の拠点情報をデータベース管理し、拠点情報一覧取得、拠点従業員一覧取得のAPIを追加します。
仕様書には追加する機能も含めたものを準備します。
検証準備 - システムプロンプト -
GitHub Copilotを使用して検証します。
実装と仕様書とシステムプロンプトは以下のように配置します。
システムプロンプトには、以下のような内容を定義します（一部抜粋）。
general.instructions.md
- 実装コードはsample-projectディレクトリの配下にあります。
- API仕様書は、docs/API仕様書ディレクトリの配下にあります。
- データベースのテーブル定義とER図は、docs/ER図ディレクトリの配下にあります。
code.instructions.md
- 実装チェックや提案をするときは設計方針に則ってください。
- 以下に記載がないものでも、可能な限り既存の実装に合わせてください。
- 設計方針は以下の通りです。
- 各APIで共通となる実装は、commonプロジェクトに実装します。
- commonのmodels配下にはRDSのテーブルに対応するmodel定義を実装します。
- 各APIから利用する機能ロジックは common.services配下に定義します。
...
specifications.instructions.md
- index.yamlに全APIの情報を記載します。
- 各APIの詳細は、pathsディレクトリ配下のファイルに記載します。
- 実装チェックや提案の際は、詳細に記載のパラメータやレスポンス、例の記載と一致しているかを確認してください。
検証
検証として、システムプロンプトがある場合とない場合とで生成される実装コードを比較しました。
その結果、システムプロンプトがない状態では、追加されたコードに対して以下の課題がありましたが、システムプロンプトを用意することで既存の設計方針に沿ったコードを生成してくれるようになりました。
- common.services の下ではなく common の直下に実装追加されている。
- 追加機能の実装がクラスによる実装ではなく、関数による実装になっている。
- viewsの下に追加された実装クラス名が、ControllerではなくListViewになっている。
- 例外処理の実装がない
- マイグレーションファイルの実装がない
お試しでは、システムプロンプトの内容も最小限としていますが、蓄積していくことでAIによってやれることも増えていくのではないかと思います。
