プロンプトを工夫しても精度は0.8pt｜40件の実測

「プロンプトを工夫すれば、AIの精度は上がる」——この言葉を、私たちは何度も見聞きしてきました。役割を与える、定義を書く、判断ルールを並べる。たしかに手応えはあります。ですが、その手応えが本当に数字として出るのかを、自分で測った人は多くありません。

測らないまま業務に組み込むと、困るのは導入したあとです。指示文を厚くしたのに現場で誤仕分けが減らない、直したはずの箇所が別の場所で崩れる、担当者がプロンプトを直し続けて終わらない。よくある行き詰まりです。

そこでAi-Raku（アイラク）は、問い合わせメール40件を8分類×緊急度3段階に振り分けるという、中小企業の現場にそのままある作業で実験しました。指示の書き方だけを変え、各条件3回、同じモデルで実行し、機械で採点しています。実施日は2026年8月24日です。

結果は、世間で語られている論調とは逆を向きました。分類の正答率は91.7%から92.5%へ、差は0.8ポイント。私たちが期待した改善は、この課題では起きませんでした。この記事は、その報告書です。都合よく丸めず、出た数字のまま書きます。

結論｜工夫しても0.8ptだった

先に結論を置きます。指示を構造化しても、分類の正答率はほとんど動きませんでした。

3つの数字を先に出す

条件Aは「分類名を8個並べるだけ」、条件Bは「定義8個＋判断ルール6条＋緊急度の基準」を渡した指示です。両条件とも同じモデルで3回ずつ実行し、修正後の正解データで採点した結果が次の表です。

分類の差は+0.8ptです。40件を3回ずつ判定させて、この幅しか動きませんでした。緊急度は+4.2pt、両方一致は+3.3pt。数字だけを見れば条件Bが上ですが、後述するとおりこの差は、採点する側の解釈のブレより小さいことが分かりました。

なぜ差が出なかったか

理由は単純ではありませんでした。条件Bで誤りが減ったわけではなく、誤る場所が入れ替わっていたのです。ルールで直った設問が3件ある一方、ルールが原因で壊れた設問が3件ありました。合計するとほぼ相殺されます。

そして壊れた3件はすべて、私たちが書いたルールの副作用でした。「いつ届くか」と書いたつもりのルールが、「いつ直るか」にも効いてしまった。この現象がこの記事の中心的な発見です。

この記事の読みどころ

この記事は「プロンプトの工夫は無意味だ」と言うためのものではありません。プロンプトの基本的な考え方はプロンプトエンジニアリングとはで扱っており、書き方の型はプロンプトの書き方にまとめています。基本を押さえる価値は変わりません。

この記事が示すのは、「指示文を厚くする」という打ち手には天井があり、その手前で人が決めておくべきことが残っているという事実です。読みどころは、H2「ルールは意図より広く効く」の章です。ここが最も実務に効きます。

何を測ったか｜実験の設計

実験は、中小企業の現場に実在する作業をそのまま課題にしました。抽象的なベンチマークではなく、info宛メールの一次仕分けです。

課題は40件の仕分け

問い合わせメール40件を読み、それぞれに分類（8つから1つ）と緊急度（高・中・低から1つ）を付けさせます。1件につき2つのラベルなので、40件×2ラベル×3試行が1条件あたりの判定量です。

この作業を選んだ理由は3つあります。第一に、多くの会社が今も人手でやっていること。第二に、正解を定義しやすく採点が機械化できること。第三に、間違えたときの実害が分かりやすいこと（緊急の不具合を「低」に落とせば顧客を失います）。問い合わせ対応そのものの設計は問い合わせ管理で扱っています。

条件は判断基準だけ変えた

比較で最も大事なのは、変えた要素を1つに絞ることです。この実験で変えたのは判断基準の記述だけです。

モデルは両条件で同じClaude（Sonnet）を使いました。他社モデルは試していないため、この記事では他社モデルの性能に一切言及しません。「A社のAIのほうが賢い」といった話は、この実験からは何も言えません。

採点は機械で行った

採点は自作のスクリプトで行い、人の主観を入れていません。出力された40行を正解データと突き合わせ、分類の一致・緊急度の一致・両方の一致を数えるだけの単純な処理です。

「AIの出力をAIに採点させる」方法も一般的ですが、今回は採点側のブレを排除するため文字列の完全一致で判定しました。結果として、後述する正解データそのもののブレが浮かび上がることになります。評価の作り方そのものについては、Anthropicの公式ドキュメントでもテストケースの設計と評価ツールが案内されています。

使ったデータと正解の作り方

実験の質は、データと正解の質で決まります。ここは詳しく書きます。

40件は架空の文面

使ったのは、Ai-Rakuが実験のために作成した架空の問い合わせ文面40件です。実在の企業・個人とは関係ありません。ただし、中小企業の問い合わせフォームやinfo宛メールに実際に届く種類を想定し、わざと判断に迷う書き方を混ぜてあります。

たとえば、営業メールなのに「お見積り」という語が入っているもの、クレーム調だが主題は納期であるもの、「急ぎではない」と書いてあるが内容は不具合であるもの。実務で人が迷うのはまさにこういう文面で、きれいなデータで測っても意味がないと考えました。

分類8個の定義

正解を決めるために使った定義です。条件Bではこの定義をそのままAIに渡し、条件Aでは渡していません。

40件の内訳は見積6／不具合7／納期4／請求7／採用5／営業4／使い方2／その他5です。分布に極端な偏りがないことは確認しています。

緊急度3段階の基準

緊急度は次の基準で決めました。この基準は試行を始める前に確定させています。

正解の内訳は高5／中19／低16です。「高」を絞り込んだのは、実務で「高」が乱発されると優先順位として機能しなくなるからです。この設計判断が、後で自分たちに跳ね返ってきます。

わざと迷わせた設問

40件のうち、意図的に判断を割りにいった設問を挙げます。まず罠として最も分かりやすいのが#6です。

6. 【ご案内】業務効率化を実現するSaaSのご紹介です。今なら初期費用無料でお見積りいたします。ぜひ一度お打ち合わせのお時間をいただけませんでしょうか。

「お見積り」という語が入っていますが、見積を求めているのは相手のほうです。正解は営業・売り込み／低。語の一致で判断すると必ず外します。

次は#24です。体裁は進捗確認ですが、最後の一文が意味を変えています。

24. 3か月前に依頼した件、まだ着手されていないようですが、いつ始まりますか。もう待てません。契約の見直しも考えています。

「いつ始まりますか」だけを読めば納期・進捗ですが、契約の見直しを明示しているため、正解は不具合・クレーム／高です。緊急度の基準の4項目にはっきり当たります。

ほかにも次の設問を混ぜてあります。

• #7：見積を受け取ったあとの納期確認。見積依頼ではない（正解は納期・進捗／中）
• #11：クレーム調だが主題は納期（正解は納期・進捗／高）
• #18：「急ぎではない」と書いてあるが不具合（正解は不具合・クレーム／中）
• #26：無料トライアルの問い合わせ。購入検討の入口（正解は見積・価格／中）
• #27：資料の再送依頼。どの業務ラベルにも収まらない（正解はその他／低）
• #36：不満の芽はあるが主題は請求内容の照会（正解は請求・支払い／中）

条件A｜分類名だけ渡す

条件Aは、多くの現場で最初に書かれる素朴な指示です。定義も判断基準も書かず、ラベル名だけを並べています。

条件Aのプロンプト全文

実際に渡した指示文です。そのままコピーして試せます。

inquiries.txt に問い合わせが40件あります。これを分類して、緊急度も付けてください。

分類は「見積・価格」「不具合・クレーム」「納期・進捗」「請求・支払い」「採用」「営業・売り込み」「使い方・仕様」「その他」の8つ。緊急度は「高」「中」「低」。

出力は `番号,分類,緊急度` のCSV形式で、40行だけ返してください。見出し行・説明・前置きは不要です。

このファイル以外は読まないでください。

ポイントは出力形式だけは厳密に指定していることです。ここを揺らすと採点できません。逆に言えば、条件Aでも「形式を守らせる」という工夫はすでに入っています。何も工夫していない状態ではありません。

条件Aの試行3回の数字

3回の試行それぞれの結果です。母数は40件です。

注目していただきたいのは、定義を何も渡していないのに分類が91.7%出ていることです。「見積・価格」「不具合・クレーム」といったラベル名は、それ自体が意味を持っています。モデルはラベル名から定義を推測し、素朴な常識で振り分けます。そして、その常識はかなりの精度で当たります。

ここが実験の出発点です。出発点がすでに高いので、伸びしろは最初から小さかったのです。

条件B｜定義とルールを渡す

条件Bは、一般に「良いプロンプト」とされる形に近づけたものです。定義を書き、迷ったときの判断ルールを並べ、緊急度の基準も明示しました。

条件Bのプロンプト全文

inquiries.txt に問い合わせが40件あります。次の定義に従って分類し、緊急度を付けてください。

## 分類（8つ）と定義

- 見積・価格 … 購入検討にあたって価格・条件・トライアルを尋ねるもの。まだ受注していない
- 不具合・クレーム … 提供物が期待どおり動かない／約束と違うという申し立て。不満の表明を含む
- 納期・進捗 … 受注済みの案件について、いつ届くか・いつ終わるかを尋ねるもの
- 請求・支払い … 請求書・領収書・支払条件・入金など、金銭事務に関するもの
- 採用 … 応募、応募前の質問、業務委託での参画希望。求職者側からの連絡
- 営業・売り込み … 相手が自社の商品・サービスを売り込んでくるもの
- 使い方・仕様 … 既存顧客からの操作方法・仕様・契約条件の照会。不満は含まない
- その他 … お礼、担当者変更、資料再送、取材依頼など上記に当たらないもの

## 迷ったときの判断ルール（上から順に適用する）

1. 相手が「何をしてほしいか」で決める。文面の調子（丁寧か、怒っているか）では決めない
2. 相手が売り込む側なら、内容が見積や採用に見えても「営業・売り込み」
3. 受注前なら「見積・価格」、受注後なら「納期・進捗」
4. 不満が書かれていても、求めているのが「いつ届くか」なら「納期・進捗」
5. 解約・契約見直しに言及していれば「不具合・クレーム」
6. 請求内容そのものへの照会は、不満の気配があっても「請求・支払い」

## 緊急度の基準

- 高 … 業務が止まっている／出荷・納入に直接影響する／全社が使えない／解約や契約見直しを明示して迫っている
- 中 … 期限が明示されている／金銭に関わる／応募（他社に流れる）／不満の芽がある／解約を検討している気配がある
- 低 … 期限がなく、放置しても当面の実害がないもの

出力は `番号,分類,緊急度` のCSV形式で、40行だけ返してください。見出し行・説明・前置きは不要です。

このファイル以外は読まないでください。

判断ルール6条は何から作ったか

ルール6条は思いつきではなく、実験の前に作った正解データの定義から導いたものです。条件Aの誤答を見て書き足したものではありません。

ただし手順として、条件Bのプロンプトを確定した時点で、条件Aの試行は2回終わっていました。完全な事前登録にはなっていないので、この点は限界として先に申し添えます。とはいえ後述のとおり、条件Bは条件Aが正解していた設問を新たに3つ落としており、後出しで有利になったとは言えない結果です。

もう1つ、結果を見る前に押さえておきたい事実があります。条件Bで直った3件のうち、2件を動かしたのはルールではなく「定義」でした。

ここは後で効いてきます。直したのは主に定義で、壊したのはすべてルールだったからです。

条件Bの試行3回の数字

結果｜差は誤差の範囲だった

両条件の数字を並べると、差の小ささが際立ちます。

分類は0.8ptしか動かない

条件A 91.7%、条件B 92.5%。差は+0.8ptです。定義8個と判断ルール6条を足し、指示文の分量を大きく増やした結果がこれでした。

正直に言えば、実験を組んだ時点では「もっと上がるだろう」と考えていました。定義を書けば迷いが減る、というのは直感的にもっともらしい仮説です。その仮説は、この課題では支持されませんでした。

緊急度は4.2pt上がった

緊急度は条件A 78.3%、条件B 82.5%で+4.2pt。分類より大きく動いています。基準（高・中・低の線引き）を渡した効果はここに出ました。

ただし、水準そのものが低いことに注意してください。条件Bでも82.5%です。分類より緊急度のほうが、そもそも難しいという事実のほうが、この数字からは重要です。

試行のばらつきと比べる

差を評価するときは、試行ごとのばらつきと比べる必要があります。条件Aの分類は3回で92.5%・90.0%・92.5%、条件Bは95.0%・92.5%・90.0%。同じ条件の中でも、これだけ振れています。

条件Bの最も悪い回（90.0%）は、条件Aの良い回（92.5%）を下回っています。両条件の平均差が+0.8ptしかないのに、条件内のばらつきがこれより大きい。この規模の実験では、+0.8ptに意味を持たせられないというのが誠実な読み方です。

誤りは減らず入れ替わった

平均だけを見ていると、何が起きたか分かりません。設問ごとに開くと、まったく違う景色が見えます。

直った3件と壊れた3件

分類の誤りは、条件Aが延べ10セル、条件Bが延べ9セル。ほぼ同数です。ところが、誤っている場所が違いました。

直ったセル9・壊れたセル7

セル単位で数えると、直ったセルが9、壊れたセルが7です。狙って塞いだ穴は確かに塞がりました。直った3件の原文を見ると、ルールが素直に効いたことが分かります。

26. 貴社サービスの無料トライアルはありますか。あれば申し込み方法を教えてください。

#26は、条件Aでは3回とも別のラベルに振られていました。「無料トライアル」は購入行為ではないので、価格を尋ねる文とは読みにくいのです。これを直したのはルールではなく定義でした。「見積・価格＝購入検討にあたって価格・条件・トライアルを尋ねるもの」と書いてあるだけで、3回とも正解になっています。

27. 先週伺った際に説明いただいた機能について、もう一度資料をいただけますでしょうか。社内で共有したく思います。

#27も条件Aでは3回とも誤りです。「機能について」という語があるため使い方・仕様に寄っていました。これも定義です。「その他＝お礼、担当者変更、資料再送、取材依頼など上記に当たらないもの」と例示しておくだけで、3回とも正解になりました。

#24を直したのはルール5「解約・契約見直しに言及していれば『不具合・クレーム』」です。3件のうち、ルールで直ったのはこの1件だけでした。

問題は、同時に別の穴が開いたことです。しかも開いた穴は、条件Aでは3回とも正解していた設問でした。定義を渡していない素朴な状態では正しく判断できていたものが、ルールを渡した途端に3回とも間違うようになったのです。

合計はほぼ動かなかった

直った9と壊れた7が相殺し、延べ誤りは10セルから9セルへ。これが「+0.8pt」の正体です。

平均正答率という1つの数字は、この入れ替わりを完全に隠します。もし私たちが平均だけを見て「+0.8ptだから少し改善した」と結論づけていたら、新しく壊れた3設問の存在に気づかないまま本番に載せていました。#39は「復旧見込みを尋ねる障害連絡」で、正解の緊急度は「高」です。ここを取り違えるのは実務上いちばん痛い誤りです。

精度を測るときは、必ず設問単位の差分を見てください。平均は改善を隠すのではなく、劣化を隠します。

ルールは意図より広く効く

ここがこの実験の核心です。壊れた3件はいずれも、私たちが書いたルールが書き手の意図より広く適用された結果でした。原文を引きながら1件ずつ見ます。

#39「いつ直るのか」の誤り

まず原文です。

39. 障害の報告をいただきましたが、復旧見込みが書かれていません。いつ直るのか教えてください。こちらの顧客にも説明が必要です。

正解は不具合・クレーム／高です。障害が継続していて、しかも相手方の顧客への説明が必要な状態。放置してよい連絡ではありません。

条件Aは3回とも正解しました。ところが条件Bは3回とも「納期・進捗」と答えています。原因はルール4です。

4. 不満が書かれていても、求めているのが「いつ届くか」なら「納期・進捗」

私たちがこのルールを書いたとき、頭にあったのは「注文した品物がいつ届くか」という場面でした。ところがモデルは、この条件を「いつ〇〇されるかを尋ねている」という形式として読み取ります。「いつ直るのか」も、時期を尋ねる文である以上、この条件に当てはまります。

ルールの文言は間違っていません。間違っていたのは、書き手が「当然こういう場面のことだ」と思い込んでいた範囲です。人間なら文脈で範囲を絞りますが、明文化されたルールは書かれたとおりに適用されます。

#31「最短でどのくらい」の誤り

31. 納期は最短でどのくらいでしょうか。急ぎで必要になりまして、金額は多少上がっても構いません。

正解は納期・進捗／中です。条件Aは3回とも正解、条件Bは3回とも「見積・価格」と誤りました。原因はルール3です。

3. 受注前なら「見積・価格」、受注後なら「納期・進捗」

この文面は明らかに納期を尋ねています。しかし「金額は多少上がっても構いません」とあるとおり、まだ受注はしていません。ルール3を素直に適用すれば「見積・価格」になります。

つまりルール3は、私たちが定めた定義そのものと矛盾していました。分類の定義では「納期・進捗＝受注済みの案件について、いつ届くかを尋ねるもの」としているので、受注前の納期質問はどの定義にも収まりません。定義に穴があるところに、その穴を埋めるルールを書いたつもりが、穴を別の場所へ移しただけでした。

ルールは定義の欠陥を隠します。直すべきだったのは定義のほうです。

#7 受注前か受注後か

7. 見積書をいただきありがとうございました。B案で進めたいのですが、納品時期はいつ頃になりますでしょうか。

正解は納期・進捗／中。条件Aは3回とも正解、条件Bは1回誤りました（3回中1回なので、揺れが出たという読み方が正確です）。

この文面は、見積を受け取り「B案で進めたい」と意思表示した状態です。これは受注前でしょうか、受注後でしょうか。契約書に判を押していないなら受注前ですが、実務感覚では受注確度が非常に高い状態です。

この境界を、私たちは定義していませんでした。定義していないものは、AIには判断できません。3回中1回だけ揺れたのは、まさに境界上だからです。人が決めていない線を、AIが安定して引けるはずがありません。

ルールは足すほど副作用が増える

3件をまとめると、次の構図になります。

そして、この副作用はルールを足すほど増えます。ルールが1条増えるたびに、そのルールが意図せず当たる文面の候補が増えるからです。「精度が出ないからルールを足す」という対処は、ある地点から先は穴の位置を動かすだけになります。

Anthropicの公式ドキュメントでも、明確で直接的な指示や例示（マルチショット）、思考の連鎖といった手法が体系的に案内されています。手法そのものは有効です。この実験が示すのは、手法の前段にある「人が何を決めたか」のほうが結果を左右するということです。

緊急度は低く見積もられる

もうひとつ、指示の書き方では直らなかった傾向があります。緊急度の見積もりです。

過大評価は消えた

条件Aでは過大評価が7セルありました。実際は「中」なのに「高」と付ける、といった誤りです。条件Bで基準を渡すと、過大評価は0になりました。「高」の条件を4つ明示した効果は、はっきり出ています。

過小評価はむしろ増えた

ところが、過小評価は条件Aの19セルから条件Bの21セルへ増えています。誤りの総数は26セルから21セルへ減りましたが、その中身はすべて過小評価に寄りました。

これは基準の書き方の帰結でもあります。「高」の条件を厳しく4つに絞ったため、それに当てはまらないものはすべて下へ落ちます。過大評価を潰す基準は、同時に過小評価を増やすという、当たり前ですが見落としやすい構造です。

落とされたのはどれか

低く見積もられたのは、放置すると本当に危ないものでした。応募者からの連絡、請求先の変更、操作に困っている既存顧客。いずれも「今すぐ業務が止まる」わけではありません。ですが、応募者は返信が遅ければ他社に流れます。請求先の変更を落とせば入金が止まります。

17. 操作方法が分からず困っています。マニュアルのどこを見ればよいか教えていただけますか。

この文面は穏やかですが、正解は「中」です。既存顧客が自社の製品を使えずに困っている状態だからです。文面の温度と、事業上の重さは一致しません。「重さの判断」は文面の穏やかさに引きずられる——これが、指示の書き方では直らなかった傾向です。

実務的な結論はシンプルです。緊急度は人が持つ工程にしてください。AIには分類だけ任せ、優先順位は人が付ける。この線引きが、数字の上でも支持されました。

正解データが2件ずれていた

この実験でいちばん驚いたのは、AIの挙動ではありませんでした。自分たちが作った正解データのほうが先に崩れていたことです。

#8と#30を高から中へ

採点をしている最中に、正解データ2件が、自分たちが先に決めた緊急度の基準に合っていないことに気づきました。

8. 何度もご連絡しているのですが、担当の方から折り返しがありません。先週お伝えした不具合はまだ直っていません。どうなっているのでしょうか。

30. 導入から半年経ちましたが、当初聞いていた効果が全く出ていません。説明と違うのではないでしょうか。契約時の資料も見返しましたが、納得できません。

どちらも当初は「高」を付けていました。読めば分かるとおり、明らかに関係が悪化している連絡です。感覚としては「高」です。

ですが、私たちが先に決めた「高」の基準は「業務が止まっている／出荷・納入に直接影響する／全社が使えない／解約や契約見直しを明示して迫っている」の4つでした。#8も#30も、このどれにも当たりません。強い不満はありますが、業務は止まっておらず、解約や契約見直しを明示してもいません。

基準は先に決めていた

誤解のないように書きます。基準そのものは試行の前に確定させており、あとから変えていません。変えたのは、その基準に照らして誤っていたラベル2件です。

とはいえ、これは結果を見てから正解を動かす操作にあたります。実験の作法としてはグレーです。だからこの記事では、修正前の正解で採点した数字も後述の章で必ず併記します。読者が自分で判断できるようにするためです。

先に崩れたのは人だった

この事実の重さは、AIの精度の話より大きいと考えています。基準を先に文章で決めていたにもかかわらず、40件のうち2件で、自分たちがその基準を守れませんでした。

人間は文面の感情に引きずられます。「何度もご連絡しているのですが」という一文を読めば、基準の4項目を確認する前に手が「高」を選びます。基準は書いた瞬間から守られるものではありません。

ここから引き出せる実務的な示唆は明快です。AIの精度が出ないと嘆く前に、人が同じデータを2回仕分けして一致するかを見てください。人同士、あるいは同じ人の2回で一致しない作業は、AIに渡しても安定しません。中小企業のAI導入で最初につまずくのは、たいていモデルの性能ではなく、この定義の詰めです。

採点次第で結論が反転する

正解データを2件修正したことで、この実験には決定的な事実が加わりました。どちらの正解データで採点するかによって、勝敗が入れ替わります。

修正前で採点すると

修正前の正解データで採点した場合、全体は次のようになります。

修正前の正解で採点すると、緊急度も両方一致も条件Aが上になります。「定義とルールを渡したほうが悪い」という、まったく逆の結論が出るのです。動かしたのは40件中2件のラベルだけです。

差より解釈のブレが大きい

ここから言えることは1つです。条件AとBの差は、採点する側の解釈のブレより小さい。

2件のラベルを動かすだけで結論が反転するのですから、+0.8ptや+4.2ptという差を「プロンプトの工夫の効果」と呼ぶことはできません。「プロンプトを工夫したら精度が上がった」と言えるだけの差は、この課題では出ていない、というのが誠実な報告です。

これは、世の中で見かける「プロンプト改善で精度が◯%向上」という報告を読むときの視点にもなります。その報告に、正解データの作り方と、正解データを動かしたかどうかが書かれているかを見てください。書かれていなければ、数字だけを信じることはできません。

数字の読み方を先に決める

この事故を防ぐ方法はあります。採点を始める前に、次の3つを紙に書いておくことです。

1. 正解データを確定した日を記録し、以後は原則として動かさない
2. どうしても動かす場合は修正前でも採点し、両方を併記する
3. 何ポイント差がついたら「改善した」と呼ぶかを、実験を始める前に決めておく

3つ目が特に効きます。基準を決めずに測ると、出た数字を見てから「これは改善だ」と解釈してしまうからです。私たちもこの実験で、そうなりかけました。

実務で先にやるべきこと

ここまでの結果を、明日から使える形にします。結論は「プロンプトを書く前に決めるべきことがある」です。

プロンプト前のチェック項目

AIに仕分けや判定を任せる前に、次の項目を埋めてください。埋まらない項目があるなら、プロンプトをどれだけ磨いても安定しません。

境界例を先に3つ書く

この8項目のうち、手間の少なさに対していちばん効いたのは項目2「境界例を先に書く」でした。具体的な手順にします。

1. ラベルを2つ選ぶ（例：見積・価格 と 納期・進捗）
2. その2つのどちらにも読める実際の文面を3つ、過去のメールから探して書き出す
3. 3つそれぞれに、どちらを正解とするか、その理由つきで決める
4. 決めた理由を、そのまま定義文に追記する（ルールとして別立てにしない）

4番目が重要です。この実験で壊れた#31は、境界の判断を「定義」ではなく「ルール」として別立てにしたために起きました。定義の中に「受注前の納期質問は納期・進捗に含める」と書き足していれば、ルール3と衝突しなかったはずです。

ルールは定義の外側にある例外ではなく、定義そのものを直す材料として使ってください。これがこの実験から得た、いちばん実務的な教訓です。

緊急度は人が持つ

過小評価が条件Bで21セルまで増えたことを踏まえ、私たちは次の分け方を推奨しています。

「AIに全部任せるか、全部やめるか」ではありません。工程ごとに、数字で線を引くことができます。

任せる範囲の決め方

とはいえ、自社の業務でこの線をどこに引くかは、実際に測ってみないと決まりません。Ai-Rakuでは、いきなりプロンプトを書き始めるのではなく、まず「何を任せて、何を人が持つか」を決めるところからご一緒しています。この記事の実験は、その判断材料を作るために自分たちで行ったものです。

業務ごとの任せ方の整理は業務タスク別のAI活用にまとめています。費用は初期費用0円・月額5万円〜です。「精度が出るか分からないので踏み切れない」という段階からで構いません。無料相談はこちらからどうぞ。測り方の設計だけでもお手伝いできます。

この実験の限界と再現手順

結論を一般化しすぎないために、限界を明記します。

4つの限界

• モデルは1つだけ：Claude（Sonnet）のみで実施しました。他社モデルは試していないため、他社モデルの性能については何も言えません
• 試行は各条件3回：この規模では、数ポイントの差に意味を持たせられません。条件内のばらつき（分類で90.0%〜95.0%）のほうが、条件間の差（+0.8pt）より大きい状態です
• データは架空：実際の問い合わせではなく、Ai-Rakuが作成した40件の架空の文面です。実データでは分布も文体も変わります
• 正解はAi-Rakuの基準：分類・緊急度の正解は、あくまで私たちが定めた基準によるものです。別の会社なら別の正解になります
• 完全な事前登録ではない：条件Bのルールは実験前に作った定義から導いたものですが、手順としては、条件Bのプロンプトを確定した時点で条件Aの試行が2回終わっていました。条件Bに有利に働きうる並びだったにもかかわらず、条件Bは条件Aが正解していた設問を新たに3つ落としています
• 正解データを2件、実行後に直している：#8と#30です。直す前と後で緊急度の勝敗が逆転するため、本文では両方の採点を載せました

特に2つ目は重要です。この記事は「条件Bが優れている」とも「条件Aが優れている」とも主張していません。主張しているのは「この規模の差では、どちらが優れているとも言えない」ということです。

再現の手順

同じことを自社で試す手順です。1日あれば終わります。

1. 自社に実際に届いた問い合わせを40件集める（個人情報は伏せる）
2. 自社の業務に合うラベルを決め、1行の定義を書く
3. 緊急度の基準を決める。「高」は絞る（乱発すると優先順位として機能しない）
4. 40件に正解を付ける。付け終えた日付を記録し、以後は動かさない
5. ラベル名だけの指示（条件A相当）で3回実行する
6. 定義とルールを足した指示（条件B相当）で3回実行する
7. 設問ごとにどちらで正解／不正解が入れ替わったかを並べる
8. 壊れた設問について、どのルールが効いたかを特定する

7番と8番を飛ばさないでください。平均正答率だけを見ると、この記事で見つかった現象は何も見えません。

次に試したいこと

私たちが次に測りたいと考えているのは、次の点です。

• 例示（数件の実例）を渡した場合：定義やルールではなく、正解付きの実例を見せる方式との比較
• ルールを定義に統合した場合：ルールを別立てにせず定義文に織り込むと、副作用が減るか
• 試行回数を増やした場合：条件内のばらつきがどこまで収束するか
• 実データでの再現：架空の文面ではなく、実際の問い合わせで同じ現象が起きるか

エージェント設計の一般的な考え方については、Anthropicの効果的なエージェントの構築やプロンプトエンジニアリングの概要が参考になります。使用モデルの世代差についてはモデル一覧で確認できます。AIを業務に組み込むときのリスク管理の枠組みとしては、NISTのAIリスクマネジメントフレームワークや、国内ではIPAのAI関連情報が参考になります。

よくある質問

Q. プロンプトの工夫は無駄ですか？

A. いいえ。出力形式の指定や役割の明示は、この実験でも条件Aから使っており、それがあるから採点できています。この実験が示すのは、基本を押さえたあとに「定義とルールをさらに足す」打ち手の効果が小さいということです。

Q. なぜ分類は0.8ptしか上がらなかった？

A. 出発点が高かったからです。定義を渡さない条件Aでも91.7%出ています。ラベル名自体が意味を持っているため、モデルは常識で振り分けられます。伸びしろが最初から小さかったのです。

Q. 誤りの入れ替わりはどう見つける？

A. 平均ではなく設問単位で並べます。条件Aと条件Bで、同じ設問がそれぞれ何回正解したかを表にしてください。この実験では#24・#26・#27が直り、#31・#39・#7が壊れていました。

Q. ルールは何条までなら安全ですか？

A. 条数で決められません。この実験ではルール6条のうち少なくとも2条（ルール3・ルール4）が意図より広く効きました。条数より、各ルールが当たる文面を先に3つ書き出せるかで判断してください。

Q. 緊急度をAIに任せてもよい？

A. 判定を任せきりにするのは勧めません。条件Bでも82.5%で、誤りは21セルすべてが過小評価でした。危ない案件が下に落ちる方向に外れます。候補出しはAI、確定は人という分け方を推奨します。

Q. 過小評価はどうすれば減りますか？

A. この実験の範囲では、指示の書き方で直せませんでした。基準を渡すと過大評価は0になりましたが、過小評価は19セルから21セルへ増えています。人が確認する工程を残すのが確実です。

Q. 正解データは何件必要ですか？

A. この実験では40件でした。ただし40件・3試行でも、条件内のばらつきが条件間の差を上回っています。数ポイントの差を論じたいなら、より多くの件数と試行が必要です。

Q. 正解データは修正してよいですか？

A. 原則は動かさないことです。やむを得ず直す場合は、この記事のように修正前でも採点して両方を出してください。この実験では、2件動かすだけで緊急度の勝敗が反転しました。

Q. 他社のAIなら結果は違いますか？

A. 分かりません。この実験はClaude（Sonnet）1つでしか実施しておらず、他社モデルは試していないため、比較できる材料を持っていません。

Q. うちの問い合わせでも同じ結果になる？

A. 分布も文体も違うので、同じ数字にはなりません。ただし「ルールが意図より広く効く」「緊急度が低く見積もられる」という現象そのものは、定義の詰め方が甘ければ起こります。

Q. まず何から手を付ければよい？

A. ラベルの定義を1行ずつ書き、ラベル同士の境界例を3つ書くところからです。プロンプトを書くのはそのあとで十分です。境界を人が決めていない限り、AIは安定しません。

Q. 精度が出ないときの最初の一手は？

A. ルールを足す前に、同じデータを人が2回仕分けして一致するかを見てください。この実験では、AIより先に私たち自身の正解データが2件ずれていました。人が揺れる作業は、AIでも揺れます。

Q. 相談するとしたら何を用意すればよい？

A. 過去の問い合わせを40件ほど（個人情報は伏せて）と、現在の仕分けルールがあればそれだけで十分です。定義がまだ無い状態からで構いません。定義を作るところが実際の作業の中心になります。

この実験の要点をあらためて並べます。指示を構造化しても分類の正答率は91.7%から92.5%へ、差は0.8ptでした。誤りは減らず、直った9セルと壊れた7セルが入れ替わっただけです。壊れた原因はすべて、私たちが書いたルールが意図より広く適用されたことにありました。緊急度は条件Bでも82.5%で、誤りは21セルすべてが過小評価でした。そして正解データ2件を動かすだけで、緊急度の勝敗は反転しました。

この結果は「AIをやめたほうがよい」という話ではありません。分類は定義なしでも91.7%出ているのですから、任せられる工程は確かにあります。決めるべきなのは、どこまで任せて、どこから人が持つかです。

Ai-Rakuは、その線引きを決めるところからご一緒します。プロンプトを書き始める前に、ラベルの定義と境界例、そして「間違えたときに誰が損をするか」を一緒に整理する。地味ですが、ここが最も結果を左右する工程だと、今回の実測で確認できました。費用は初期費用0円・月額5万円〜です。まずは無料相談で、自社のどの工程を任せられるかを一緒に見立てましょう。関連する内容はプロンプトの書き方、問い合わせ管理、中小企業のAI導入もあわせてご覧ください。