自己紹介
初めまして、FIXERでプロンプトエンジニアをしている高桑と申します。
FIXERで、初めてプロンプトエンジニアとして入社した背景から、世界的にも新しいこの職種のValueの定義を、あくまで個人的な見解としてお話します。
プロンプトエンジニアとは
生成AIやLLMなどのシステムに対して、出力の指示を設計する専門職です。
出力の例は、文章の要約、企画、クリエイティブ(画像、台本、歌詞など)、各種質疑応答などです。
こういったタスクの処理や生成を指示するための、入力する指示文のことを「プロンプト」といいます。
また、「〇〇について教えて」などの一般的な応答では、プロンプトの専門的な技術はほとんど必要なく、誰でも簡単に出力を指示することができると思います。
一方で、「ハルシーネーション」というエラーと向き合う必要性も出てきます。「ハルシネーション」とは、生成AIやLLMにおいて、もっともらしいが事実とは異なる情報や文脈と無関係な情報が生成されることを指します。
プロンプトエンジニアの専門性は?
「〇〇について教えて」などのような、個人で一般的な応答や壁打ちをする場合以外にも、AIの利用はあります。
例えば、業務の自動化やプロダクトのUXへ応用する場合です。
この場合、出力結果をよりコントロールすることが求められるため、その品質を担保する責任から専門性が必要になってきます。
具体的には、「ハルシネーション」の発生頻度を最小限に抑えたり、発生しても問題ないような出力をコントロールしたり、といった「守り」の部分があります。
または、一般的な応答では引き出せない「未知のAIのポテンシャル」を引き出したり、平均的になりがちな出力を目的に沿って特化させるなど、「攻め」の部分もあり、応用はいくらでも創造できそうです。
そこで、専門性の具体例をいかに2つご紹介します。
専門的なプロンプトが必要な事例①:業務の自動化
業務の自動化に関しては、GPTのAPIを連携して業務の自動化を図っても、「ハルシネーション」が起きてしまうと業務に支障が発生して、むしろ自動化しない方が効率的になってしまうこともあり得ます。
例えば、ミーティングの内容を自動で文字起こしして、そのまま「要約」「todoとその担当者」「他チームへ共有するべきこと」をテキストで自動生成してSlackで自動で展開される、といった業務改善をする場合にも、そのテキスト生成の結果が「思ったより違う...」となることが想定されます。
これらの精度は、このツールのバックエンドに仕込むであろうプロンプトの設計次第です。
専門的なプロンプトが必要な事例②:UXの設計
プロダクトのUXの設計に関しても、例えば和料理屋さんのチャットボットの人格を「〜でござる。」で統一するUXを図っても、「〜です。」となってしまう場合や、その後に「〜でござる。」に戻らなくなってしまうリスクもあります。
また、もう少し目線を上げて、そもそも「〜でござる。」だけではなく「こんなこともできるのか!」と感動するようなAIの未知のポテンシャルを引き出すことも、プロンプトエンジニアだからこそ実現できることと言えそうです。
AIの出力を開発し、その再現性を研究し、もっと奥深く、エンタメ性のあるUXを0から設計することも可能です。今後は、広義の意味での「UX設計者」に、「プロンプトエンジニア」が含まれていく流れになるかと思います。
このように、プロダクトとしての品質、およびUXの精度向上や新開発を実現する上で、プロンプトの設計は非常に重要です。
つまり、本格的な応用においては、品質やUXを担保できる専門的な知識でプロンプトを設計する必要があり、これがプロンプトエンジニアの中心的な責任範囲かと私個人は考えています。
プロンプトエンジニアがいると何が変わる?
結論、「生産性」と「UX」が変わります。そして、これがプロンプトエンジニアのValueかなと思います。
特にプロンプトによる「UX」については、今後のプロダクトのUIにも大きな影響を与えます。
生成AIによるプロダクトのUX設計の例として、例えば下記があります。
- チャットボットで、人格表現
- 検索プラットフォームで、ユーザーによる入力値を軌道修正してあげる検索補完
- SNSで、ユーザーの趣味・嗜好に基づいて、タイムライン上の投稿をリアルタイム生成する
上記からわかるように、プロンプトがユーザーのインターフェースを直接的に設計することになってきます。
こうなると、プロンプトエンジニアはプロンプトの開発のみならず、ユーザーへの理解を高め続ける必要性も出てきます。
さらには、人類にとって未知の領域も含めた、生成AIやLLMの新しいポテンシャルを引き出すことも、より強く求められる世界線になるかなと思います。
なので、もしLLMでユーザーのインターフェースを設計するプロダクトのPdM(プロダクトマネージャー)であれば、プロンプトエンジニアではなくても、プロンプトの知見を高めることが求められるかもしれません。
私は、前職までPdMを本業としてUXの設計を経験させていただき、その次にプロンプトエンジニアに転身した立場として、そのように実感しています。
これは、時々耳にする「PdMやPMであればSQLはかけた方がいい」あたりの価値観に近いものかもしれません。
つまり、チームにプロンプトエンジニアがいると、既知のUXを大幅に拡張した、新時代の「UX」を設計できるチームに変わると思います。
じゃあプロンプトエンジニアのスキルセットは?
ざっくり下記かなと思います。
自然言語処理(NLP)の理解
プロンプトなどの指示文を、AIがどのようなプロセスに沿って処理をしているのかを理解します。
応用例
「ネームドエンティティ認識 (NER)」や「リレーショナルエンティティ抽出モデル」などのキーワードをプロンプトに入れて、文脈理解の精度を高めることができます。
用途にもよりますが、手元の実験で効果を確認できています。これは、自然言語処理の知識から着想できる設計です。
Python
自然言語で入力後、特定の演算や処理においてPythonで実行するモデル(例 GPTのAdvanced Data Analysis)を利用する場合に、そのエラーハンドリングの手段が増えます。
応用例
「ローカルのエクセルファイルの100行目を削除してほしい」と指示した場合に、101行目を削除するエラーが起こりがちです。この原因は、Pythonの0-indexedによるもので、要するに行を「1」からではなく「0」からカウントしていたことが影響しています。
これは、処理のプロセスであるPythonのコードを見るとわかります。一般的な方からすると、この処理は「ブラックボックス」になると想定される観点で、専門的知識かなと思います。
言語化と構造化
これはプロンプトエンジニアの専門的な知識というよりは、どの職種でも重要な「言語化」の能力です。
AIへの指示は、人間と話すのと同じようなコミュニケーションスキルが必要で、具体的に表現すると「言語化」と「構造化」は特に重要かなと考えています。
応用例
「Chain of Thought Prompting(CoT)」です。これは、「ハルシネーション」が起きやすい複雑なタスクを、成功率高く出力させる有名なプロンプトの手法です。
内容は「複雑なタスクを分解し、一つひとつ指示する」というものです。具体的には、プロンプトとして「Step1. 〇〇, Step2. △△, Step3. ◻︎◻︎, ...」と指示したり、一言にまとめて「下記をstep-by-stepで実行して」と指示する手法です。
CoTは海外の論文「Chain-of-Thought Prompting Elicits Reasoning
in Large Language Models」で発表されたもので、個人的に試した複数のタスクでも有効性を確認できています。
このCoTは、プロンプトを「構造化」させる手法そのものです。
英語
ユースケースによっては、プロンプトの言語を選択するところから設計する場合もあります。
応用例
特に英語のプロンプトには、下記の有利な点があると考えています。
- 処理時間が比較的短い
- 計算リソースも節約されやすい
- 1と2で共通して、英語は形態素数が少なく、一つの単語がそのままトークンとして処理されることが多いためです。
- 学習されている量が他言語よりも多い
- ゆえに、モデルにもよりますが、一般的に英語で書いた方が比較的高い精度を期待できる可能性があります。
- 例えば、「プロンプトエンジニア」に関する生成はその典型的な例であると考えています。
- なぜなら、最新のテクノロジーをアメリカがリードすることも多いために、現在進行形で最先端の「プロンプトエンジニア」のデータベースが突出している期待があるためです。実際、「プロンプトエンジニア」の求人の数を調べた時も、アメリカが最も多かった印象でした。
逆に、日本語のプロンプトの方が精度が高いユースケースもあると思います。
例えば、「かるた」や「俳句」の生成タスクです。
日本の文化であるため、「かるた」や「俳句」は原則、平仮名と漢字のみで作成されるはずですので、当然「かるた」や「俳句」のデータベースも日本語と相性がいいと思われます。
なので、おそらくですがそれを引き出すプロンプトも日本語の方がより高精度になるのではないか、と考えています。
以上、「自然言語処理(NLP)」、「Python」、「言語化と構造化」、「英語」について具体的にお話しました。上記以外にも、別項目で述べたUXの延長として「創造性」、Pythonと同じようにブラックボックスと諦めないための知識としての「モデル(+機械学習)の理解」などもあるかと思います。
また、海外の「プロンプトエンジニア」の求人を調べた時には、「倫理(AIから色んな言葉を引き出せてしまう可能性があるため)」と「データサイエンス」を多く見かけました。
今後プロンプトエンジニアはどうなるのか?
「どのような専門知識を持ち、どのようなプロンプトを設計するべきか?」といった観点については、正直未知数ではあります。
今後、AIの進化として「一般的な応答のみでも高精度な出力ができる」未来や、「プロンプトを書かなくてもAIの方から話しかけてきて、方向性もレコメンドしてくる」未来が来るとも思います。
また、LLMも、各ドメインごとに特化して学習されたモデルが一気に増えてくると思います。
一方で、AIをマネジメントする役割としては、ますます重要になってくる存在だと考えています。
なので、先述したような「自動化」や「UX」などの応用的な設計を実現するにあたって、一般的な状態のままではなく、自分たちの現場やプロダクトにマッチした状態にするためには、何かしらのAIマネジメントが必要であり続けると考えています。
便利なツールに対して、受動的に口を開けて待つのではなく、AIを主体的に応用して攻めるのであれば、AIがどこまで便利になっても「設計」、「エラーハンドリング」、「ディレクション」は常に必要になると思います。
こういったマネジメントの手法の1つとして、現段階では「プロンプトが有効的である」という段階に過ぎないです。
つまり、「プロンプトエンジニア」という呼称に縛られることなく、世界中の情報を対象に「最先端の技術」や「LLMを利用したサービス」の動向などを学び続ける姿勢が肝心になるかなと思います。