プロンプトエンジニアリングよりも重要なプロブレムフォーミュレーションという考え方
プロンプトエンジニアリングとは大規模な言語モデルから良い結果を得る目的でテキスト入力を最適化する仕事であり、この分野は「未来の仕事」として期待されているが、実はそれよりもプロブレムフォーミュレーション（問題を識別、分析、明確化する能力）の方が、生成型AIの潜在能力を引き出すためのより持続可能で適応性のあるスキルであるとこちらの記事で主張されています。
著者によると、高品質のプロンプトを作成できたとしても、問題そのものが的外れであれば意味がないと言っていますが、確かにその通りだと思います。Howの部分に注力するあまり、そもそも何（What）を解決しようとしていたかの部分が置き去りにされていく現象を私たちは、ありとあらゆる分野で何度も見てきました。
プロブレムフォーミュレーションはプロンプトエンジニアリングに代わるものではなく、むしろプロンプトエンジニアリングの質をも向上させることができる基礎となります。
現在、プロンプトエンジニアリングの一環として「プロンプト集」のような応用のための具体例がたくさん出てきました。それらを有効に利用するためにも、ここはいったんズームアウトして生成AIの活用を全体として見直し、真に効果的に活用するための戦略を整理していくべきだと感じました。
記事の著者はこのプロブレムフォーミュレーションを以下の４つの点にまとめています。
- Problem diagnosis ～ 問題や症状の原因を特定するための診断
- Decomposition ～ 複雑な問題をより簡単な部分や要素に分ける問題の分解
- Reframing ～ 問題や状況を新しい視点や角度から考え直す枠組みの再構築
- Constraint design ～ 特定の制約や限界内で最適な設計を行う制約設計
以下、ひとつづつ考察していきたいと思います。
Problem diagnosis ～ 問題や症状の原因を特定するための診断
記事ではまずはじめのステップとして「問題を診断し、根の問題」を探し当てることを提案しています。その具体的な手法として「５ Whys（５つのなぜの質問）」を例に挙げています。ここで５という数字はだいたいそのぐらい深掘りすれば根の問題に到達するだろうという目安です。問題を表す文章からスタートして「次のレベルのなぜ」の疑問文を作り、それに対しての回答文を考える。次にその回答文についてさらに「なぜ」の疑問文を作り、それの回答を考える。それを繰り返して、もうそれ以上「なぜ」を出せないか出しても意味がないレベルまで到達したら「根本原因」が見つかったということになります。
例えば、以下のような深掘りをすることで問題の根本的な原因を明確にすることが出来ます。
この問題診断を行うことで、的外れなソリューションに進んでしまったりして資源を無駄にしてしまうといったリスクを少なくすることが出来るでしょう。
特に「生成AIを毎日の問題解決に利用したい、だけど実際どのようにしたらいいのか、どこから始めたらいいのかわからない」という状況にいる場合は、問題診断を５Whyの手法などを使って行い、最も直接的な根の問題文を突きとめることができれば「どこから始めればいいのか」のヒントが見えてくるかもしれません。
Decomposition ～ 複雑な問題をより簡単な部分や要素に分ける問題の分解
「分割」はもう何世紀にもわたって使われているアプローチですが、ここでもその有用性は高いといえます。戦争における基礎的な戦術に「divide and conquer（分割統治）」があります。プログラミング的思考などでも抽象化と並んで重要とされる考え方にdecomposition（分解分割）があります。平たく言うと、複雑な問題を部分に分けて、それぞれの部分について解決していくというやり方です。
記事にあった例として、ChatGPTなどに「サイバーセキュリティーを強化したいのでそれについて助言してください」といったプロンプトを投げたとしてもあまりにも広範囲すぎて一般的な返答しか得られない、とあります。そこで、「サイバーセキュリティー」という問題をいくつかのサブ問題に分割し、それぞれのサブ問題について、より具体的な解決を探ることができるようになります。
以下はChatGTPにサイバーセキュリティーという大きなトピックを分割してもらいました。
アクセス制御と認証
- パスワードは十分に安全か？
- ログインに追加のセキュリティ手段はあるか？
- 誰が何にアクセスできるのか？
ネットワークセキュリティ
- 外部からの不正アクセスは防げているか？
- データのやり取りは安全に行われているか？
- 侵入をどうやって感知し、防ぐか？
データ保護
- 保存されるデータは安全に保管されているか？
- データの予備コピーはあるか？
- 個人情報は適切に匿名化されているか？
～長くなるので以下略～
このように分割することで、高度なサイバーセキュリティーを保つための具体的な項目が明確になり、評価や実装もより容易になります。これらの部分ごとにソリューションを実装し、それらを組み合わせることで全体としてのサイバーセキュリティー問題が解決できます。
生成AIにプロンプトを渡してもすぐに行動に移せるような返答が得られない場合、そのプロンプトの抽象レベルが高すぎるか、問題が複雑すぎる可能性があります。「どのようなプロンプトを書けばいいか？」という考えを一旦停止し、「この問題はどのような構成要素を持っているのか？」と明確にし、各構成要素ごとに解決策を見つけることが重要です。
「正しい回答」を得るためには「正しい質問」をしなくてははならない。「正しい質問」をするには「問題を正しく定義」しなくてはならない、ということです。
Reframing ～ 問題や状況を新しい視点や角度から考え直す枠組みの再構築
Re-framing という英語は「frame（枠）に当てはめなおす」という意味で、問題の視点やアプローチを変えてみることで見えてくるであろう新たな解決アプローチを模索する取り組みのことです。「問題の再定義」、「問題の捉え方を変えてみる」、「問題を別の角度から解釈してみる」というような表現もあてはまるでしょう。
下図ではシリンダー状の物体を２つの異なる視点から見ることで長方形と円として捉えることを示しています。抽象的に表現される「問題」も、このようにいくつかの視点が存在すると仮定できます。
問題の見方を変えてみるということは、問題の見方を広げてみるということでもあります。固定的な見方や、アプローチの決めつけを避け、どこかに存在する最適解を見つけ出すために網を広げるようなイメージととらえてもいいかもしれません。
例えば発想の転換による例として
- 元の問題: もっと多くのプラスチックをリサイクルするにはどうすればいいか？
- 再定義された問題: 最初からプラスチックが廃棄物の流れに入らないようにするにはどうすればいいか？
- 解決策: ゼロウェイストプログラムの実施と、生分解性素材の使用を推進する。
というものがあります。この場合は「そもそも・・・」という枕詞を使うことでこの着想を得ることが出来たのかもしれません。
さらには、全く新しい視点から問題を再定義した例としては
- 元の問題: 絶滅危機にある動物をどう保護するか？
- 再定義された問題: 絶滅危機にある動物を「ブランド」としてどうマーケティングするか？
- 解決策: WWF（世界自然保護基金）などがパンダをシンボルとして使い、商品やキャンペーンでの認知度を上げ、資金を集めて成功を収めた。
というものもあります。解決策は直接的に保護を目的にはしていないが、結果的には保護するという目的の達成に役立っています。
このように、元の問題を別の問題に置き換えることで解決に導くことが出来るます。問題定義の段階で柔軟な発想を試すことで全体のプロセスが効率的になっていると言えるでしょう。生成AIに限らず、現段階での解決アプローチが効果的に問題を解決していないと思える際は、もしかしたら問題そのものが間違っているかもしれないと疑ってみるのが良いのかもしれません。
Constraint design ～ 特定の制約や限界内で最適な設計を行う制約設計
まず、制約を設けることで問題解決の範囲を限定することができます。この制約を問題定義の段階で明確にしておくことで、より効果的にプロンプトエンジニアリングを行うことができます。問題定義に従って、回答の範囲を明示的に指定して限定したり、逆にネガティブプロンプトとして「望ましくない結果」を指定することができ、全体の効率が上がることが期待できます。逆に制約が明確でない場合、結果が期待とずれてしまったり、無駄なコミュニケーションが増えたりする可能性があります。
また、制約を緩めることで生成AIの回答の自由度を高めることもできます。例えば「感情に訴えること」が最重要な目的であり、生成AIにはより創造的な提案を求めたい場合、またはより広範囲な解決策を探りたいときは、意図的に制約を緩める場合もあるでしょう。
さらに、"Constraint Design"（制約デザイン）は制約条件をデザインや問題解決のプロセスに積極的に取り入れるアプローチです。制約をただの障壁としてではなく、創造性やイノベーションを促す要素として考えます。以下はそのいくつかの例です。
X（旧Twitter）の文字数制限
- 制約: 一つのツイートは最大280文字。
- 結果: 制約があるために、ユーザーは情報を短く、分かりやすく伝える工夫をします。この制約がTwitterの特徴的なコミュニケーションスタイルを生んでいます。
IKEA（イケア）のフラットパック家具
- 制約: すべての部品と説明書が一つの箱に収まるようにする。
- 結果: この制約によって、IKEAは効率的な運送と格安の価格を実現しています。また、ユーザー自身が組み立てることで、製品に対する愛着や満足感も高まります。
制約はプロンプトエンジニアリングにおいては非常に重要な要素になるので、生成AIをソリューションの一部として活用する際には得に重要になります。
プロンプロエンジニアリング vs プロブレムフォーミュレーション
このブログのタイトルはいくらかミスリードを含んでいます。「プロブレムフォーミュレーションはプロンプトエンジニアリングよりも重要」という構図ですが実際は「プロブレムフォーミュレーションもプロンプトエンジニアリングも両方重要」か「プロブレムフォーミュレーションはプロンプトエンジニアリング支えるために重要」という構図が正しいでしょう。
以下にLinkedInに両者の関係を示す記事（と動画）があります。
この記事を参考にプロブレムフォーミュレーションの重要性を、プロンプトエンジニアリングと対比しながら要約すると以下のようになります。
- 人工知能の世界では、問題解決は単に正確なプロンプトを作成するだけのものではなく、正確な問いを立てて問題を適切に定義することが含まれます。
- 氷山の先端、すなわち「プロンプトエンジニアリング」は、AIから正確な回答を引き出すための具体的な入力を作成することについてですが、沈んでいる部分、すなわち「プロブレムフォーミュレーション」は、問題の範囲、データ、および基準を定義することに焦点を当てています。
- これら二つの側面の間でバランスを取ることで、AIは単なる回答ではなく正確な回答を提供するようになります。
- このように、見える部分と見えない部分の両方にある要素に注意を払うことでAIを効果的に活用することが可能になります。
プロンプト集やプロンプトのカテゴリ分けだけでは十分ではない
ここまでの考察から得られる最も重要な気づきは「プロンプトエンジニアリングのみに注力すると真の問題解決に到達できない可能性がある」ということです。
もちろんパターン集としてのプロンプトの参考例は非常に便利です。いくつかのパターンは自分が抱えている問題とシンデレラの靴のようにぴったり当てはまることもあるでしょう。
しかし、私たちが取り組む問題はほとんどの場合、ユニークであり特別です。それらを解決する上で、現在最も一般的なアプローチとしては「最も近いプロンプト」を探し当て、それを改造することで自分の問題の解決に再利用するやり方でしょう。このやり方は決して間違ってはいませんし、多くの場合はそれで充分でしょう。ですが、なかなか望む結果を得られなかったり、参考になるプロンプトを見つけられなかったりといった停滞が発生した場合は、一度「プロブレムフォーミュレーション」というフェーズまで戻って、ここで挙げたような手法を用いて問題を明確化することで突破口を見出すことが出来るかもしれません。
