2026年04月24日

良いAIへの指示は「確率を狭める」。でも、狭めすぎてはいけない

Ai, その他, 仕事術, 生成AI

たとえば、会議メモを渡して「要点をまとめてください」とだけ頼むと、こちらが知りたかった決定事項や次回対応ではなく、背景説明ばかりが長く返ってくることがあります。
逆に、「300文字以内、箇条書き3つ、やさしい言葉で、でも技術的な注意点も漏らさず入れてください」と細かく指定しすぎると、大事な論点が削られて、不自然な答えになることもあります。

202604_ai_prompting_balance_01

ここでいうAIとは、ChatGPTのように文章やコードを生成するAIのことです。
この記事では、そうしたAIに何かを頼むときの「指示の出し方」について考えてみます。

先に要点だけ言うと、AIへの良い指示で大事なのは、
目的と制約を具体的にしつつ、
手段は必要以上に固定しないことです。

言い換えると、欲しい答えに近づくための条件は伝える。
ただし、まだ決めなくてよい方法までは縛りすぎない。
これが基本です。

まずはざっくりと、生成AIはどう動いているのか

生成AIの中でも、ChatGPTのように言葉を扱うものは、
「大規模言語モデル（LLM）」と呼ばれます。

LLMは、かなり乱暴に言えば、
それまでの文脈をもとに、次に続きそうな言葉を予測しながら並べていく仕組み
だと考えるとわかりやすいです。

202604_ai_prompting_balance_02

厳密には、「文字」そのものではなく、
「トークン」と呼ばれる単位を扱っています。
トークンは、単語だったり、単語の一部だったり、記号だったりします。

ただ、細かいことは気にせずに「AIは、前後の流れを見ながら、もっともらしい続きを作っている」
と捉えておけば十分です。

つまり、AIは最初から正解を知っていて、それを取り出しているわけではありません。
与えられた文脈に対して、「この続きを書くなら何が自然か」を次々につないでいる。
まずはそのイメージを持っておくと、指示の出し方も考えやすくなります。

昔話で考えるとわかりやすい

たとえば、日本の昔話を例にしてみます。

「昔々」とだけ書かれていたら、その先に続く物語の可能性はたくさんあります。
桃太郎かもしれませんし、浦島太郎かもしれませんし、かぐや姫かもしれません。
AIから見れば、「昔々」の次に来そうな表現はたくさんあるわけです。

では、「昔々、あるところに、おじいさんとおばあさんがいました」と書いたらどうでしょうか。
この時点で、物語の候補は少し絞られます。
少なくとも、最初から海や亀が出てくる話よりは、おじいさんとおばあさんが登場する昔話の方向に寄っていきます。

さらに、「昔々、あるところに、おじいさんとおばあさんがいて、主人公が桃から生まれる昔話を書いてください」と書けば、かなり桃太郎に近づきます。
ここまでくると、AIがたどる可能性の幅はかなり狭くなっています。

202604_ai_prompting_balance_03

このとき起きているのは、AIの出力候補のうち、こちらが欲しい方向の確率が高まっている、ということです。
だからAIへの指示を考えるときは、
「どうすれば欲しい答えの確率を高くできるか」
という見方をすると整理しやすくなります。

日常的なお願いでも同じ

たとえば、AIに「会議の内容をまとめてください」とだけ頼んだとします。
これだけだと、誰向けの要約なのか、どのくらいの長さにするのか、何を優先して書くのかがわかりません。

一方で、
「営業チーム向けに、今日の打ち合わせ内容を300文字程度で要約してください。決定事項と次回対応だけを箇条書きで整理してください」
と頼めば、AIはかなり答えやすくなります。

ここで起きているのは、文章が長くなったことではなく、
欲しい答えに関係する条件が増えたことです。
つまり、こちらがほしい出力に近づく確率が上がっている、ということです。

これはコード生成でも同じ

この考え方は、文章だけでなく、コードを作ってもらうときにもそのまま当てはまります。

AIに「コードを書いてください」とだけ頼んでも、候補は広すぎます。
使う言語は何か、どんな環境で動かすのか、どんな入力を受け取り、何を返すのか。
情報が少ないままだと、AIは広い可能性の中から「それっぽいもの」を出すしかありません。

では、何を伝えると良いのでしょうか。
次のような情報です。

使う言語
バージョン
開発で使う仕組み（フレームワークやライブラリ）
実装したい機能
入力と出力の形
制約条件
守ってほしい方針やスタイル

実際に、
「PHP 8.2で、Laravel 11を使い、JSON APIとして実装したい。入力チェックも入れて、既存のDB設計に合わせてほしい」
と伝えれば、AIが選ぶべき答えの幅はかなり絞られます。

このことから、AIにうまく指示を出すとは、単に長文を書くことではなく、
欲しい出力に関係する条件を適切に与えること
だと言えます。

ただし、狭めれば狭めるほど良いわけではない

ここで注意したいのは、AIの出力は、狭めれば狭めるほど良くなるわけではないということです。

大事なのは、どこを狭めるかです。
欲しい結果に近づく条件を伝えるのは大切ですが、
まだ決めなくてよい手段まで先に固定すると、
かえって良い答えの可能性を自分で減らしてしまうことがあります。

これは、いわゆる
「ドリルを売るには穴を売れ」
という話に少し似ています。

人が本当に欲しいのは、ドリルそのものではなく、
その先で実現したい結果です。
だから本来は、どんな道具を使うかより先に、
どんな状態にしたいのかを考える必要があります。

しかも、もう一段さかのぼって考えると、
そもそも穴を開ける必要があるのか、という問いもありえます。

たとえば、壁に何かを取り付けたいとしても、
方法は穴を開けることだけではありません。
つっぱり棒かもしれませんし、両面テープかもしれませんし、
壁を傷つけにくい固定具のほうが合っているかもしれません。

202604_ai_prompting_balance_04

それなのに、AIに
「穴を開ける方法を教えてください」
と聞いてしまうと、AIは穴を開ける方向でしか答えられません。
もしかしたらもっと良い方法があったのに、
その可能性を自分で閉じてしまうことになります。

これは開発の相談でも同じです。
本当に解決したい課題が
「処理をもっと速くしたい」
なのに、AIへの依頼を
「for文を効率よく書く方法を教えてください」
としてしまうと、AIはfor文を前提に考えるしかありません。

しかし実際には、
データの持ち方を変えたほうが良いかもしれませんし、
DBの問い合わせを見直したほうが良いかもしれません。
あるいは、別の関数やライブラリを使えば、
もっと簡潔で速い実装になるかもしれません。

つまり、「どうやって穴を開けるか」や
「どうやってfor文を改善するか」と聞いた時点で、
AIが考えられる範囲をこちらが先に狭めてしまっているわけです。

言い換えると、AIにうまく頼むコツは、
欲しい答えに近づくための条件は伝えつつ、
まだ決めなくてよい手段は縛りすぎないことです。

だから大事なのは「何を狭めるか」

AIへの指示で大事なのは、「狭めること」そのものではなく、
何を狭めるかです。

狭めるべきなのは、主に次の2つです。

何を達成したいのか
どんな制約があるのか

一方で、手段については、
それが本当に確定しているときだけ指定するほうがうまくいきやすいです。

たとえば、
「何に困っているか」
「どんな状態になればうれしいか」
「使える技術や守るべき条件は何か」
は、できるだけ明確に伝えたほうが良い情報です。

逆に、
「まだ検討の余地がある方法」
まで最初から固定してしまうと、
AIの提案の幅を不必要に狭めてしまうことがあります。

すぐ使える書き方の型

AIに何かを頼むときは、次の順番で書くと整理しやすくなります。

何を達成したいか
誰向けの出力か
どんな制約があるか
どんな形式で出してほしいか
避けたいことは何か

たとえば、次のように書けます。

目的:
大量データの集計処理を改善したい

対象:
開発メンバー向け

制約:
PHP8.2とLaravel11を使っている
既存APIのレスポンス形式は変えたくない

出力形式:
実装方針を複数案
それぞれのメリット・デメリット付き 

避けたいこと:
for文の改善だけに話を限定しない
前提を勝手に決めない