この記事は弥生 Advent Calendar 2023の12日目のエントリーです。

弥生の石橋です。開発本部でデスクトップ製品共通モジュールのエンジニアを担当しています。
突然ですが、皆さんChatGPTは使っていますか？
文章の校正やコーディングのお供はもちろん、YouTuberの挨拶を考えるなんてこともしてくれる頼れる相棒です。
職場によっては使用が制限されていることもあるかと思いますが（前職はそうでした）、仕事ではなくても勉強しててわからないことを聞いたり、一週間の献立を考えてくれたりと様々な場面で活躍します。
そんなChatGPTですが、効果的な質問の仕方（プロンプト）が存在するのをご存じでしょうか？
本記事ではプロンプトシステムと、それを使った例をご紹介します。

プロンプトシステム

深津式プロンプト

深津式プロンプトは、note株式会社のCXOである深津貴之氏によって考案されたフレームワークです。
具体的な役割（例：プロのエンジニア）を命令して、指定した制約条件のもとで質問や指示を入力する形式となっています。

#命令書:
あなたは、<役割>です。
以下の制約条件と入力文をもとに、 最高の結果を出力してください。

#制約条件:
・最高の結果を出すために追加の情報が必要な場合は、逆質問をしてください。
・<文字数>字以内で回答してください。
・<その他制約条件>

#入力文:
<入力文>

#出力文:

深津式プロンプトの例（単一責務の原則を教えてもらう）

# 命令書:
あなたはプロのエンジニアです。
以下の制約条件と入力文をもとに、最高の説明文を出力してください。

# 制約条件:
・小学生でもわかるように答えてください。
・PlantUMLの図が出力できるテキストを提供してください。
・具体例と違反例を提示し、図もあわせて出力してください。
・回答は長くなってかまわないので、できるだけわかりやすく回答してください。
・回答の質を高めるためにもっと情報が必要な場合は、私に質問をしてください。

# 入力文:
単一責務の原則について教えてください。

# 出力文:

ChatGPTの回答例

単一責務の原則は、1つのクラスやメソッドは1つの責務（役割）だけを持つべきだという考え方です。これは、プログラムの保守性や拡張性を高めるための重要な原則です。

たとえば、レストランの例を考えてみましょう。料理人が料理を調理する責任、ウェイターが注文を受け取る責任、会計士が支払いを処理する責任などがあります。料理人が支払いを処理することは責務が混乱しています。

具体例として、単一責務の原則に従ったクラス図を示します。
@startuml

class 料理人 {
    + 調理する()
}

class ウェイター {
    + 注文を受け取る()
}

class 会計士 {
    + 支払いを処理する()
}

料理人 --> ウェイター : 注文
ウェイター --> 会計士 : 支払い

@enduml
違反例として、単一責務の原則に反するクラス図を示します。
@startuml

class 従業員 {
    + 調理する()
    + 注文を受け取る()
    + 支払いを処理する()
}

@enduml
この違反例では、1つのクラスが料理する責任、注文を受け取る責任、支払いを処理する責任を全て持っており、単一責務の原則に反しています。これにより、変更が必要な場合にコードの修正が複雑になり、保守性が低下する可能性があります。

単一責務の原則を守ることで、各クラスやメソッドが明確な役割を果たすことができ、コードの理解や保守がしやすくなります。

PlantUMLで出力した画像は以下になります。

いかがでしょうか？
身近な例で図付きで説明してくれるので、すごくわかりやすい回答が得られたと思います。
「入力文」だけを修正すればよいので、上記の例をテンプレートとして保存しておくと便利です。

ReActプロンプト

ReActプロンプトは推論、行動、最終的な見解の3ステップを踏まえて質の高い応答を得ることができるプロンプトです。
質問内容の後に、Thought、Action、Observationと記述するだけでよいため、簡単に回答の質を高めることができます。

<質問内容>
Thought :
Action :
Observation :

ReActプロンプトの例（ソフトウェア開発についての相談）

これからのソフトウェア開発において重要なことは何でしょうか？
Thought :
Action :
Observation :

ChatGPTの回答例

Thought（考え方）:
ソフトウェア開発において重要なことは、持続的な価値提供とユーザー中心のアプローチです。ソフトウェアはただ動作するだけでなく、ユーザーのニーズや期待に応えることが不可欠です。また、テクノロジーの進化やビジネス環境の変化に対応し、持続的に価値を生み出すことが求められます。

Action（行動）:
1. ユーザー中心の開発：ユーザーのニーズを理解し、使いやすい、価値のあるソフトウェアを提供するために、ユーザーのフィードバックを積極的に収集し、製品や機能を改善することが重要です。
2. アジャイル開発の採用：アジャイルなアプローチを用いて、継続的な改善を行いながら、柔軟かつ効率的にソフトウェアを開発・リリースすることが重要です。
3. 品質管理の向上：品質を重視し、テスト、コードレビュー、自動化されたデプロイなどのベストプラクティスを導入して、信頼性の高いソフトウェアを提供することが重要です。

Observation（観察）:
これらのアクションを実践することで、以下のような効果が得られます：
- ユーザー満足度の向上：ユーザー中心のアプローチを取ることで、ユーザーのニーズに即したソフトウェアを提供し、満足度を向上させます。
- 迅速な変更への対応：アジャイル開発により、変化する要求や市場状況に迅速に対応し、価値を継続的に提供できます。
- 高品質なソフトウェアの提供：品質管理の向上により、バグの少ない、セキュアで信頼性の高いソフトウェアを提供できます。

このように、ユーザーのニーズを理解し、アジャイルな開発手法を採用し、品質管理を重視することが、今後のソフトウェア開発において重要なポイントとなります。