■はじめに
最近、業務でもプライベートでもAI、特にLLMを利用する機会が増えたので、自分なりに使い方と今後の展望についてまとめたので、記事にさせていただきます。
特に、巷でよく言われる「AIがあれば素人でもなんでもできる。勉強は不要」という言説について、私なりの見解を示させていただきます。
結論から申し上げますと、
少なくとも今の段階では、勉強は必要。
むしろ、今まで以上に重要になる。
と考えられます。
以降の記事で、その結論に至るまでの考え方を示そうと思います。
※本記事は2025年8月段階のLLMの挙動、主にGPT-4oとGPT-5を基準にしています
■良いプロンプトとは
このテーマについて語るためには、良いプロンプトとは何か？
ということについてまず触れる必要があります。
皆さんも、仕事・プライベート問わずAI活用していて、その出力結果が役に立ったり、立たなかったりと落差に悩んだことはないでしょうか。
特に、組織で複数人の人間がAIを使うと、その差が出やすいのではないかと思います。
では、何故その様な差が出るかというと、やはりAIに対する入力、プロンプトの差ではないかと考えます。
プロンプトは大まかに以下の2つ手法に大別できます。
※厳密にはもっとたくさんあるのですが、説明のために2つに強引にまとめています
① シングルターン型：1回の入力で結果を得る。
② マルチターン型：1つの質問を出し、その応答に対してさらに質問を重ねて結果を得る。
今回は①、シングルターン型をモデルに私なりの"良いプロンプト"について考察してみます。
●2つのプロンプトの比較
AWSのAPIGatewayについてのプロンプトを2つ例示します。
結果をわかりやすくする為に、極端な例を用いていますが、ご了承ください。
・サンプル①
> API Gatewayの使い方を教えて
・サンプル①に対する応答
>APIゲートウェイは、複数のAPIを管理し、クライアントとバックエンドサービスの間のインターフェースを
>提供する重要なコンポーネントです。以下に、APIゲートウェイの基本的な使い方とその利点を説明します。
>APIゲートウェイの基本的な使い方
>
>APIの設計:
>まず、提供したいAPIのエンドポイントやリクエスト/レスポンスの形式を設計します。
>APIゲートウェイの選定:
>
>AWS API Gateway、Azure API Management、Google Cloud Endpointsなど、
>さまざまなAPIゲートウェイサービスがあります。ニーズに合ったものを選びます。
>APIのデプロイ:
>
>選定したAPIゲートウェイにAPIをデプロイします。
>これには、エンドポイントの設定、認証、ルーティング、スロットリング（リクエスト制限）
>などの設定が含まれます。
>
>認証と認可の設定:
>
>APIへのアクセスを制御するために、OAuth、APIキー、JWTなどの認証メカニズムを設定します。
>
>リクエストのルーティング:
>
>クライアントからのリクエストを適切なバックエンドサービスにルーティングする設定を行います。
>
>モニタリングとロギング:
>
>APIの使用状況を監視し、ログを記録することで、
>パフォーマンスの分析や問題のトラブルシューティングを行います。
>
>バージョン管理:
>
>APIのバージョンを管理し、古いバージョンをサポートしつつ新しいバージョンを提供します。
>
>APIゲートウェイの利点
>統一されたエンドポイント: 複数のサービスを一つのエンドポイントで管理できるため、
>クライアントは簡単にアクセスできます。
>
>セキュリティ: 認証や認可の機能を提供し、APIへのアクセスを制御します。
>
>スケーラビリティ: トラフィックの増加に応じて、バックエンドサービスをスケールさせることが容易です。
>
>モニタリングと分析: APIの使用状況を追跡し、パフォーマンスを分析するためのツールを提供します。
>
>エラーハンドリング: エラーを一元管理し、クライアントに適切なエラーメッセージを返すことができます。
>
>具体的な例
>
>例えば、AWS API Gatewayを使用する場合の基本的な手順は以下の通りです。
>AWS Management Consoleにログイン。
>API Gatewayサービスを選択。
>新しいAPIを作成（REST APIまたはHTTP APIを選択）。
>リソースとメソッドを定義（GET、POSTなど）。
>
>バックエンドサービス（Lambda関数やHTTPエンドポイント）を設定。
>デプロイステージを作成し、APIをデプロイ。
>APIキーや認証を設定して、セキュリティを強化。
>
>このように、APIゲートウェイはAPIの管理を効率化し、セキュリティやスケーラビリティを向上させるための
>強力なツールです。具体的なサービスや要件に応じて、設定や運用方法は異なるため、
>公式ドキュメントを参照することをお勧めします。
続けて、次のサンプルです。
・サンプル②
>AWSのAPI Gatewayを使って、外部公開するWebサービスを作りたいです。
>アクセスはRoute53によるドメインアクセス⇒API Gateway⇒Lambdaの順に行います。
>CloudFront等のCDNは利用しません。
>使い方としては、ユーザにデータを登録してもらいますが、削除だけは裏で管理者が行うようにしたいです。
>この場合、どの様なメソッドを用意すべきでしょうか？
>Deleteメソッドは使わず、GETとPOSTだけで良いと考えているのですが、PUTも必要でしょうか？
・サンプル②に対する回答
>AWS API Gatewayを使用して外部公開するWebサービスを構築する際、ユーザがデータを登録し、
>管理者が裏で削除を行うという要件に基づいて、以下のようなHTTPメソッドを用意することをお勧めします。
>
>GETメソッド:
>ユーザが登録したデータを取得するために使用します。特定のデータを取得するためのエンドポイントや、全データ>を取得するためのエンドポイントを用意することができます。
>
>POSTメソッド:
>ユーザが新しいデータを登録するために使用します。
>データを作成するためのエンドポイントを用意します。
>
>PUTメソッド (オプション):
>ユーザが既存のデータを更新する必要がある場合、PUTメソッドを使用します。
>もしユーザがデータの更新を行わない場合は、PUTメソッドは必須ではありませんが、
>将来的にデータの更新機能を追加する可能性がある場合は、用意しておくと良いでしょう。
>
>DELETEメソッド (使用しない):
>管理者が裏でデータを削除するために使用することができますが、ユーザにはこの機能を公開しないため、
>API Gatewayの設定でこのメソッドを無効にするか、管理者専用のエンドポイントを別途設けることが考えられます。
>
>まとめ
>GET: データ取得
>POST: データ登録
>PUT: データ更新（必要に応じて）
>DELETE: 管理者専用（公開しない）
>
>この構成により、ユーザはデータの登録と取得ができ、管理者は必要に応じてデータを削除できるようになります。
>APIの設計は、将来的な拡張性やセキュリティも考慮して行うことが重要です。
2つ回答に関してどの様な違いがあるか観察してみると
①APIゲートウェイの使い方を問うシンプルなプロンプト
・返答の分量が多い
・APIゲートウェイの複数の機能に言及
・具体的な設計やユースケースより、機能説明に終始
⇒個人的な見解ですが、AWSの公式ドキュメントや機能紹介の記事のサマリのような内容です。
②APIゲートウェイを自分の目的のためにどう使うべきかを問うプロンプト
・返答の分量が少ない
・APIゲートウェイのメソッドに絞った言及
・ユーザの設計思想にマッチするメソッドの使い方をレコメンド
⇒どのような設計にすべきか？という問いに対して明確なビジョンで返答があります。
なぜこのような差が発生したのでしょうか？
単純に、プロンプトの文章が違う。
それもありますが、単に文章量の多いプロンプトが良い応答を得るわけではなく、
実際には追加された情報が、AI(特にLLM)にとって有益な情報だったからだと考察します。
次の章で、この2つのサンプルの違いを掘り下げてみましょう。
■プロンプトの質を高める要素
私自身、先ほどの2つのサンプルの違いの本質は何なのか、GPTに聞いてみました。
結果として、以下のような違いにたどり着きました。
・用途が明確
・利用する技術スタックが明確
・利用しない技術を明示
・自分なりの仮説
上記の付加情報によって、プロンプト内の語が意味ベクトル空間における方向性を持ち、
LLMの内部で適切な構造にマッピングされやすくなったと考えられます。
簡単な図解にしてみましたので、サンプル①と②を比較してみます。
図中では「ベクトル空間」としていますが、正式には「組み込み(Embedding)空間」と呼びます。イメージ優先での表現になっています。
サンプル①の動作イメージ
サンプル②の動作イメージ
特に、自分なりの仮説を盛り込むことが重要だと思われます。
たとえ、仮説が間違っていたとしても、どこがどう間違っているのかが指摘できるため、結果的に良い結果を得られやすくなると思います。
■結論
最初に示した
「AIがあれば素人でもなんでもできる。勉強は不要」
という考え方が適切かどうか。
現時点ではNoと結論付けます。
ここまでで示した様に、AI(特にLLM)から良い応答を引き出すには、プロンプトに対して単なる情報量ではなく、有益な付加情報を添付する必要があります。
そして、その付加情報を自然言語(プロンプト)に落とし込む必要がある。
これを実現するためには、人間側に以下のような制約が発生します。
・技術的な課題の把握
・付加情報(特に自分なりの仮説)を構築するための知識
例)一般的なIT基礎知識、AWS等の要素技術知識 …etc
・課題や問の言語化能力
また、今回の例に使ったプロンプトは、少ない回数で結果を得ることに主眼を置いていますが、あえて汎用的な回答を出させ、その中から役立ちそうな要素を見つけて深掘りしていく場合でも、技術に関する知識や経験がなければ、気になるポイントを見つけることができません。
今回示したのはAIの使い方のごく一部ですが、少なくとも現段階では
「エンジニアが勉強から解放される」とは言えないでしょう。
むしろ、今までより抽象的な理解が求められると考えられます。
特に、自分なりの仮説を立てられるようになるまでは、エンジニアとしてそれなりのキャリアを積む必要があり、少しでも早くAIを使いこなすには、スタートダッシュで勉強する事が重要です。
ある程度AIを使えるようになれば、後はAIを使った学習で、効率的に学ぶことができます。
以上、最後まで読んでいただき、ありがとうございます。
初めての執筆で、つたない部分、間違っている部分等あるかもしれませんが、ご容赦ください。
注意事項
本ブログに掲載している内容は、私個人の見解であり、
所属する組織の立場や戦略、意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。