AI導入戦略

プロンプトは足しても良くならない｜規則を増やして50ポイント下がった実測

プロンプト 生成AI 業務効率化 AI導入 評価
プロンプトのコツを集めた記事は多いが、効いたかを測った記録は少ない。編集部は指示の書き方を変えながら合議で採点し続けた。規則を書き足したら50ポイント、背景知識を12個足したら33ポイント下がった。何が効いて何が効かなかったかを実測で記録する。

目次

この記事の立ち位置

プロンプトの書き方を扱った記事は多い。役割を与える、段階的に考えさせる、例を示す。しかし、それを実際に適用して効果を測った記録は少ない。

編集部は生成AIを業務で運用しており、指示の書き方を変えながら結果を採点し続けてきた。採点は別の大きなモデルに複数の観点で判定させ、合議で勝敗を決める方式である。

この記事は、その過程で効かなかったことと効いたことの記録である。

先に結論を書く。書き足すことは、たいてい効かない。 効いたのは、渡す材料を閉じることと、終わったことの確かめ方を先に決めることだった。

効かなかったこと1：規則を書き足す

最も多くの人がやっていて、最も効かなかったのがこれである。

出力に問題を見つけるたびに、指示へ禁止事項を書き足していく。「この表現を使わない」「この観点を必ず含める」「前回のような書き方をしない」。

結果は、合議による評価で6回中1回しか勝てなかった（16%）。書き足す前の状態から50ポイント下がった。

なぜ下がるのか

3つの理由が考えられる。

注意が規則に向く。 守るべき項目が増えると、そちらに処理が割かれ、内容が薄くなる。文章としては整っているが、中身がない出力になる。

規則同士が矛盾する。 「簡潔に書く」と「必ずこの5点を含める」は、場合によって両立しない。矛盾したときの挙動は予測できない。

終わらない。 これが本質的な問題である。観測した問題に対して規則を足す方式は、収束しない。 1つ直すと別の問題が出る。編集部の記録には「もぐら叩き」と書かれている。

では、見つけた問題をどうするか

機械で検査できるものは、指示ではなく検査で止める。 これは後述する。

検査できないものは、達成したい状態を1つ示すほうに書き換える。 個別の禁止事項を10個並べるより、「読者が明日から実行できる手順になっていること」のように、目指す状態を1つ書くほうが結果が良かった。

効かなかったこと2：背景知識を増やす

もう1つ、直感に反する結果である。

モデルに渡す背景知識を12項目追加した。いずれも、扱う分野に関係のある情報である。

結果は合議で6回中2回（33%）。追加する前から33ポイント下がった。

追加は置き換えである

渡せる情報量には上限がある。追加するということは、何かを押し出しているのと同じである。

押し出されるのは、たいてい関連の強い情報である。新しく足した情報は目に見えるが、押し出された情報は見えない。

長い入力の中央は扱われにくい

さらに、入力が長くなると中央部分の情報が扱われにくくなる傾向が報告されている（Lost in the Middle）。

情報を足して入力を長くすると、重要な情報が中央に押し込まれる可能性がある。先頭と末尾に何を置くかは、足す情報の量より効く。

実務的な対処

足す前に、何を外すかを決める。 上限がある以上、追加は選択である。

関連度で絞る。 全部渡すのではなく、その回に必要なものだけを選んで渡す。編集部のパイプラインでは、渡す情報に予算を設けて切り詰めている。

効かなかったこと3：指示でモデルの差を埋める

「プロンプトを工夫すれば、小さいモデルでも大きいモデル並みになる」という主張がある。

編集部はこの主張を、複数の調査を突き合わせる方法で検証した。結果は支持されなかった。 規則を足す実験が失敗した結果とも整合している。

混同されやすい2つの差

指示の書き方で埋まる差は確かにある。出力の形式が揃っていない、求めていない観点で答える、長さが安定しない。こうした問題は指示で直る。

モデルの能力による差は、指示では埋まらない。長い文脈の把握、複数の制約の同時充足、推論の深さ。ここは変わらない。

前者を後者だと思って諦めるのも、後者を前者だと思って指示を書き続けるのも、どちらも時間を失う。

見分け方

同じ指示を大きいモデルに投げてみる。 それで解決するなら、モデルの能力の差である。解決しないなら、指示の問題である。

この1回の試行で、無駄な作業を大幅に減らせる。

効いたこと1：材料を閉じる

ここから、実際に効いたことを書く。

編集部は最近、公開済みの記事に外部の出典を追加する作業を、5件同時に別々の作業者へ任せた。5件すべてが完了し、目標としていた本数をすべて満たした。

以前、同種の作業を6件同時に任せたときは、成果がゼロで終わっている。

差は指示の丁寧さではなかった

成功した側では、使ってよい材料を列挙した。 使用してよい出典を14本、すべて事前に到達を確認したものだけ挙げ、「これ以外は使わない。創作しない」と明記した。

失敗した側では、材料を自分で探させていた。

なぜこれが効くのか

生成AIは、材料が足りないときに埋める。探させるということは、見つからなかったときに作ることを許しているのと同じである。

探させないことが、この作業では正解だった。

同じ体制で成果がゼロになった側との比較は、AIエージェントとはに詳しく書いている。

閉じられない場合

すべての作業で材料を閉じられるわけではない。調査そのものが目的の場合、材料は開いている。

その場合は、見つけたものを使う前に検証する手順を指示に含める。 「URLを挙げる前に到達を確認する」「確認できなかったものは確認できなかったと書く」。

埋めることを禁じるのではなく、埋めていないことを示させる。

効いたこと2：否定形で書く

禁止事項は、肯定形の指示より確実に効く。

成功した5件では、「既存の本文の主張・数値・段落構成を変えない。リンクを足すだけ」と書いた。

肯定形が機能しない理由

「丁寧に作業すること」「品質に注意すること」は、解釈の幅が広すぎる。何をしたら違反なのかが決まらない。

対して「本文の数値を変えない」は、違反したかどうかが判定できる。

ただし否定形にも限界がある

前述のとおり、禁止事項を並べすぎると評価が下がる。否定形が効くのは、数が少なく、判定できる場合に限る。

編集部の目安は、否定形の指示は3つまでである。それ以上必要なら、指示ではなく検査で止める設計に変える。

効いたこと3：完了の判定方法を渡す

3つ目が最も効いた。

成功した5件では、検証に使うコマンドをそのまま指示に書き、その出力を報告に含めさせた。

報告が「できました」ではなく、「コマンドを実行して14と出ました」になる。こちらで検算できる。

失敗した側との差

失敗した側では、完了の判定を相手に委ねていた。結果として「完了しました」という報告を受け取ったが、成果物は存在しなかった。

報告は完了の証拠にならない。 これは相手が生成AIでも人でも同じである。

判定方法の作り方

数えられるものにする。 「十分な品質」ではなく「12本以上」。

実行できるものにする。 判定に使うコマンドか、確認する場所を具体的に書く。

出力を報告に含めさせる。 判定結果ではなく、判定の生の出力を求める。

これは人に任せるときも同じ

何を使ってよいか、何をしてはいけないか、どうなったら終わりか。この3つが決まっていない作業は、誰に渡しても戻ってこない。

生成AIに任せる話として書いているが、業務の委任全般に当てはまる。

例を示すことの扱い

指示の手法として最もよく挙がるのが、望ましい出力の例を数件示すやり方である。GPT-3の論文で少数の例による学習が示されて以来、標準的な手法として扱われている。

編集部はこれを測っていない

正直に書く。編集部は、例を示すことの効果を自社では測っていない。

社内の設計文書には「例を5件示す方式で成果が再現できる」という記述がある。しかしこの記述は、「検証可能な仮説」という見出しの下に置かれていた。 つまり、試す価値があると考えられていた案であり、測った結果ではない。

これを実績として扱うと誤りになるため、本記事では効果を主張しない。

なぜこれを書くか

社内の文書を後から読むと、仮説として書かれたものが実績として引用されることがよく起きる。見出しの階層は、引用する段階で失われる。

文書に数値を書くときは、測ったのか想定なのかを、その行の中に書く。 「仮説」という見出しの下にあるから伝わる、とは考えない。

例を示すときの一般的な注意

測っていないと書いたうえで、一般に言われていることを整理しておく。

例が長いと入力を圧迫する。 前述の押し出しが起きる。

例に寄りすぎる。 示した例と似た出力ばかりになり、想定外の入力で崩れる。これは追加学習で観測されたのと同じ性質である。

例の質がそのまま効く。 悪い例を示すと悪くなる。

モデルを変えると指示が壊れる

指示は資産だが、固定資産ではない。

実際に起きたこと

編集部の記録に、設定項目の名前と実際に適用される範囲が食い違っていた例がある。ある環境変数は、特定の通信経路にしか効かない仕様だった。本番で使っている経路には適用されない。

名前からはそれが分からない。設定したつもりで効いていない状態が続いていた。

同種の食い違いとして、設計書に書かれた3つの動作のうち、実装されていたのは1つだけという例もあった。

指示にも同じことが起きる

モデルが更新されると、それまで効いていた指示の効きが変わる。出力の形式が変わる、禁止していた表現が出る、長さが変わる。

問題は、変わったことに気づきにくい点である。出力は依然として自然な文章として返る。

回帰試験を持つ

対策は、変更のたびに同じ入力を通して結果を比べることである。

編集部では100件の入力で通しを行っている。所要時間は約16分。ここで見るのは成功率だけでなく、出力の統計である。平均の長さ、存在しない固有名詞が混ざった割合、話題が混線した割合。

存在しない固有名詞の混入率は、改善前が30%以上、改善後が6%だった。この数字を追えるようにしたことが、改善の判断を可能にした。

小さく始める

100件は多いと感じるかもしれないが、10件でも効果がある。 業務で実際に使う入力を10件選び、モデルを変えたときに通す。それだけで、壊れたことに気づける。

気づかないまま運用を続けるのが最も高くつく。

実際に運用しているプロンプトの構成

記事生成のパイプラインで、実際に組み立てている指示の構成である。順に積み上げている。

1. 人物設定

扱う分野ごとに、記者としての人物設定を割り当てている。専門領域、文体、避ける表現。

役割を与えること自体の効果は、編集部では単独で測れていない。 ただし、文体の安定には寄与している。

2. 参照する規則

法令に関する注意事項を読み込んで渡している。景品表示法・薬機法などに触れる表現を、生成の段階で避けさせるためである。

ここはキャッシュしている。毎回ファイルを読み直すと、同じ内容を繰り返し渡すことになる。

3. 事前に調べた情報

検索で取得した情報を渡す。ここが最も量が多い。

4. 出力の要件

構成の要件を明示する。定義から始める、情報の塊を分割する、外部の参照を含める、といった項目である。

5. 禁止事項

冒頭の書き出しのパターン、一人称の表現。数を絞っている。

6. 出力の形式

構造化された形式を指定する。これは後述する。

段ごとにモデルを変える

すべての処理に同じモデルを使う必要はない。編集部のパイプラインでは、処理の性質に応じて使い分けている。

処理 使うモデル
話題の企画 検索つきの中規模モデル
本文の生成 最も大きいモデル
タイトルの最適化 軽量モデル
メタデータの生成 軽量モデル
品質の採点 モデルを使わない（プログラム）

採点にモデルを使わない理由

これが設計上の要点である。採点の基準が実行のたびに揺れると、ゲートとして機能しない。

同じ記事を2回採点して違う点が出るなら、その点数は判断に使えない。プログラムで書いた採点は、同じ入力に対して必ず同じ点数を返す。

判定する側には再現性を求める。 生成する側の揺らぎは許容できるが、判定する側が揺れると何も決まらない。

この採点の5軸と合格ラインの設計は、AIライティングで726記事を運用した結果で扱っている。

軽い処理に大きいモデルを使わない

タイトルを3案出して選ぶ処理に、最も大きいモデルを使う必要はない。量が増えると、この差が費用に効いてくる。

編集部では、明示的に指定しなかったために大きいモデルが機械的な処理を大量に捌いていた、という記録がある。既定値に任せると、たいてい高いほうが選ばれる。

渡す情報の予算を決める

前述のとおり、情報を足すと押し出しが起きる。編集部のパイプラインでは、渡す情報に上限を設けて切り詰めている。

予算を決めると優先順位が要る

上限を設けると、何を残して何を落とすかを決める必要が出る。これは面倒だが、決めないと「全部渡す」になり、結果として重要な情報が埋もれる。

キャッシュして再送を避ける

毎回同じ内容を渡すものは、キャッシュする。法令の規則、共通の用語集、出力の要件。

同じ内容を繰り返し送ることは、費用にも効く。 生成AIの費用は入力の長さに比例する部分が大きい。

禁止表現は指示ではなく検査で止める

これが、規則を書き足す失敗に対する編集部の答えである。

指示で禁止するのではなく、出力後に文字列として検出して止める。

実際に検査している例

冒頭の書き出しのパターンを8種類、一人称の表現を4パターン、正規表現で検出している。

さらに、点数と関係なく無条件で公開を止める項目を別に設けている。文末が途中で切れている、作業報告の断片が混入している、段落が重複している、本文全体がコードブロックで囲まれている。

指示と検査の使い分け

性質 どちらで扱うか
文字列として判定できる 検査
数えられる（本数・長さ） 検査
程度の問題 指示
目指す状態 指示

判定できるものを指示に書くのは、二重に損である。 指示が長くなって他を押し出し、しかも守られたかを確認できない。

検査を書いたら、壊れた例で確かめる

検査を追加したら、問題のある文例と正当な文例の両方で試す。片方だけだと、何も検出しない検査か、すべてを検出する検査になっていても気づけない。

編集部では、日本語とラテン文字以外の文字が混入していないかを見る検査を追加した際、この確認を行っている。追加のきっかけは、公開した記事に外国語の単語が1語紛れていたのを後から見つけたことだった。その時点の検査は絵文字しか見ておらず、問題なく通過していた。

法令に関する検査を機械で行う実装はAI記事のコンプライアンスチェックに、検査そのものが空振りする形はE2Eテストが16件落ちたにまとめている。

出力の形式を固定する

構造化された形式で出力させると、後続の処理が安定する。

編集部では、タイトル・タグ・URL文字列・抜粋・説明文を、項目名を指定した形式で出させている。自由な文章で返させると、抽出する処理が壊れる。

形式の指定は指示ではなく仕組みで

「JSON形式で出力してください」と書くより、出力形式を指定できる機能があるならそちらを使うほうが確実である。指示は守られないことがあるが、仕組みで制約すれば守られる。

計算できるものは計算する

読了時間のような値は、生成させずに計算している。文字数を500で割って1を足すという単純な式である。

生成AIに出させる必要のない値を出させると、揺らぎが入るうえに費用もかかる。計算できるものは計算する。

効果をどう測るか

ここまでの「50ポイント下がった」「33ポイント下がった」を出すために、測り方を決めている。

伏せて比べる

2つの出力を並べ、どちらがどの条件で生成されたかを伏せて判定させる。伏せないと、条件の名前に引きずられる。

判定は別系統のモデルに

判定するモデルは、生成したモデルとは別系統のものを使う。同じ系統だと自分の出力を高く評価する傾向がある。

さらに、複数のモデルに判定させて合議を取る。1つのモデルの癖が結果を決めないようにする。

数えられる壊れ方は数える

主観的な判定だけでは、機械的な壊れ方を見落とす。

編集部が検出した例では、同じ文が47回繰り返されるという壊れ方があった。これは数えれば分かる。もう1つ、特定の話者の発話が84%を占めるという偏りも、数えて検出した。

壊れ方には、数えれば分かるものと、読まないと分からないものがある。 前者は機械で先に落とす。

標本が小さいと差が大きく見える

重要な注意点である。編集部の比較で、23件の入力で測ったときの勝率91%が、100件に増やすと66%になった。

どちらも同じ方向の結論ではあるが、「90%勝っている」と「66%勝っている」では意思決定が変わる場合がある。 少ない試行で出た大差は、そのまま信じない。

絶対評価も取る

勝敗だけでは「他より良い」しか分からない。絶対値でも測っておく。

編集部の例では、7つの観点による10点満点の絶対評価で4.2〜4.9点だった。比較では勝っているが、絶対値としては中程度である。この認識の有無で、期待値の置き方が変わる。

社内で使わせるときの設計

個人が使う話と、組織で使わせる話は別である。

テンプレートだけでは統一できない

指示のテンプレートを配ると、入力の形は揃う。しかし出力が要件を満たしたかの判定は揃わない。

各自が「良さそう」と判断して使う限り、品質はばらつく。判定の基準を揃えるほうが効く。

完了の判定を業務ごとに決める

「議事録なら、決定事項・保留事項・金額に関する発言が入っていること」のように、業務ごとに確認する項目を決める。

3項目で十分である。多いと確認されなくなる。

失敗の記録を共有する

うまくいった指示を共有するより、うまくいかなかった記録を共有するほうが効く。

編集部の場合、本記事に書いた「規則を足したら下がった」という記録が、同じ試行を繰り返すことを防いでいる。

外部に出してよい情報の線を先に引く

指示の設計以前の話として、どの情報を生成AIに渡してよいかを決める。 決めていないと、各自の判断になる。

任せる作業と任せない作業の線

指示の書き方以前に、そもそも任せてよい作業かどうかの判断がある。ここを誤ると、どれだけ指示を整えても戻ってこない。

判断の軸は2つ

編集部が使っている基準は、戻せるかどうかと、確かめるのが安いかどうかである。

戻せて、確かめるのが安い作業は任せてよい。文章の下書き、大量の読み込み、反復的な編集、データの収集、検査の実行。失敗しても捨てて作り直せる。

戻しにくいか、確かめるのが高い作業は任せない。外部への送信、本番環境への反映、再生成できないデータの上書き、対外的な文書の確定版。

「仕様が閉じているか」を先に見る

もう1つの軸が、仕様が閉じているかである。

完了の条件を事前に書ける作業は任せられる。書けない作業は、任せる前に自分で仕様を詰める必要がある。

編集部の失敗例では、仕様が開いたまま6件同時に投げて、成果がゼロだった。同じ体制で仕様を閉じたときは5件すべて成功している。体制ではなく仕様の問題だった。

曖昧なまま投げると往復で消耗する

仕様が曖昧なまま任せると、確認のやり取りが増える。往復の回数が増えると、自分でやったほうが速かったという結果になる。

任せる前に仕様を完結させる。この作業自体は任せられない。

1回失敗したら自分でやる

編集部の運用ルールとして、任せた作業が1回失敗したら、同じ内容で任せ直さない。

失敗の原因はたいてい仕様の側にある。仕様を直さずに再度投げると、同じ結果になる。仕様を直せるなら直して投げ、直せないなら自分でやる。

完了は成果物で確かめる

前述のとおり、報告は完了の証拠にならない。ファイルが存在するか、変更が記録されているか、コマンドの終了コードが何か。

編集部には、完了報告を受け取った作業の成果物が存在しなかった記録がある。

よくある誤解

「長く詳しく書くほど良い」

編集部の実測では逆だった。足すほど下がった場面が複数ある。

「役割を与えると賢くなる」

文体は安定するが、能力が上がるかは編集部では測れていない。効果を主張するなら測る必要がある。

「禁止事項を並べれば守られる」

数が増えると守られなくなり、他の要素も落ちる。判定できるものは検査で止める。

「良いプロンプトを1つ作れば終わり」

モデルが変わると挙動が変わる。指示は資産だが、固定資産ではない。

「AIが出した数値はそのまま使える」

出典のない数値は検証されていない。金額・日付・固有名詞・法令の条文は、出典に当たる。

まとめ

指示の書き方を変えながら採点し続けた記録である。

規則を書き足すと50ポイント下がった。 問題を見つけるたびに禁止事項を追加する方式は収束しない。

背景知識を12項目足すと33ポイント下がった。 追加は置き換えであり、押し出されたものは見えない。

指示でモデルの能力差は埋まらない。 指示で直る問題と、モデルを変えないと直らない問題は別である。同じ指示を大きいモデルに投げれば1回で切り分けられる。

効いたのは3つ。 材料を閉じること、否定形で3つまで書くこと、完了の判定方法を渡すこと。この3つで、以前は成果ゼロだった並列作業が5件すべて成功した。

判定できるものは指示ではなく検査で止める。 指示に書くと、長くなって他を押し出し、しかも守られたか確認できない。

採点する側には再現性を求める。 編集部は品質の採点にモデルを使わず、プログラムで書いている。

明日から試せる3つ

1つ目は、いま使っている指示から禁止事項を3つ残して他を消すことである。消して悪くなったら戻せばよい。たいてい悪くならない。

2つ目は、「終わったことをどう確かめるか」を1行足すことである。数えられる形にして、その出力を報告に含めさせる。

3つ目は、うまくいかない指示を、そのまま大きいモデルに投げてみることである。それで解決するなら指示の問題ではない。1回で切り分けられる。

編集部では、AI導入の支援と、生成の運用に品質確認を組み込む支援を行っている。社内で使わせているが成果にばらつきがある、という段階の相談については、サービス案内を参照してほしい。

参考にした一次資料

よくある質問

プロンプトに注意事項を書き足せば品質は上がりますか。

編集部の実測では下がりました。出力の問題を見つけるたびに禁止事項を書き足していったところ、合議による評価で6回中1回しか勝てず、書き足す前から50ポイント下がりました。規則を守ることに注意が向いて内容が薄くなること、規則同士が矛盾したときの挙動が読めないことが原因と考えています。

背景知識をたくさん渡せば精度は上がりますか。

関連の薄い知識を足すと下がります。編集部が背景知識を12項目追加したところ、評価は33ポイント下がりました。渡せる情報量には上限があるため、追加することは何かを押し出すことと同じです。押し出されたものを見ずに足すと悪化します。

社内で生成AIを使わせても成果が出ません。何から直せばよいですか。

指示の書き方より先に、完了の判定方法を決めてください。編集部の経験では、作業を任せて成果がゼロだったときと、全件成功したときの差は、指示の丁寧さではなく「使ってよい材料が閉じているか」「やってはいけないことが否定形で書かれているか」「終わったことをどう確かめるかが指定されているか」の3点でした。

プロンプトのテンプレートを配れば社内で統一できますか。

テンプレートだけでは統一できません。テンプレートは入力の形を揃えますが、出力が要件を満たしたかの判定は揃えません。編集部では、指示そのものより、出力を機械で検査する仕組みのほうが効いています。禁止したい表現は指示に書くのではなく、出力後に文字列として検出して止めます。

小さいモデルでも指示を工夫すれば大きいモデルに追いつきますか。

編集部が検証した範囲では、追いつきませんでした。この主張を複数の調査で検証したところ支持されず、規則を足す実験が失敗した結果とも整合しています。指示の工夫で埋まる差と、モデルの能力による差は別のものとして扱うほうが現実的です。

プロンプトの良し悪しはどう測ればよいですか。

同じ入力に対する出力を並べ、どちらが良いかを伏せた状態で判定します。編集部では別の大きなモデルに複数の観点で採点させ、合議で勝敗を決めています。加えて、繰り返しや偏りのように数えれば分かる壊れ方は、機械的に検出しています。感想ではなく勝敗と件数で記録すると、変更の効果が追えます。

関連する取り組み

CONNECTED SERIES
AIで投資の壁を越える
18 本の実装記録。AI 投資の「予測不能」と言われる 9 つの壁を、コードと実データで検証した連載。
note で読む →
CONSULTING
AI導入の無料相談
ALLFORCES が、本記事のような失敗パターンを回避する AI 導入支援を提供しています。まずは課題を聞かせてください。
問い合わせる →