生成AIを配ったのに、社内の格差が広がったという話
帝国データバンクが2026年5月14日に公表した「生成AIに関する企業の動向調査」によれば、生成AIを業務で活用している企業は34.5%に達しました。ところが同じ調査で、生成AIによる悪影響として「使いこなせる社員と使いこなせない社員の格差が拡大した」と答えた企業が18.8%あります。この18.8%こそが、業務プロンプト集という道具が存在する理由です。ライセンスは全員に配れますが、使い方は自動的には配られません。
だから多くの会社が共有フォルダに文例をためていきます。そして半年後、そのフォルダは誰も開かないまま残ります。原因はプロンプトの文章が下手だからではありません。指示文だけを集めて配っているからです。業務で他人が同じ結果を出せるプロンプトには、指示文の外側に入力・制約・出力形式・検収基準という4つが書かれています。それが無いものは、書いた本人の頭の中を補ってはじめて動く文章にすぎません。
この記事では、タイ・チョンブリ県の日系製造業(従業員620名、間接部門80名)をモデルケースに、業務プロンプト集を「文例集」で終わらせた場合と「資産」にした場合の費用と効果を、最後まで数字で追いかけます。結論を先に4つ書いておきます。第一に、共有フォルダにあった47本のうち、最終更新が6か月以内のものは11本、23.4%しかありませんでした。第二に、資産として整備した場合の初期費用353,040バーツのうち外注できるのは300,000バーツ(85.0%)で、残る53,040バーツ(15.0%)は外注しようがありません。自社の業務と様式を知らない人間には検収基準が書けないからです。第三に、ROIを「試行錯誤の時間が減った」で書くと必ず赤字に見えます。プロンプト集が効くと利用者が増え、生成AIに触っている総時間はむしろ増えるからです。便益は対象業務そのものの工数606時間/月で測る必要があります。第四に、安く作った文例集のほうが回収年数は良く見えます。文例集0.8年に対し資産1.7年です。それでも文例集を選ぶべきではありません。文例集の便益は12か月で止まるからです。
プロンプト集が「配って終わり」になる構造
モデルケースの前提を置きます。タイ・チョンブリ県の日系製造業、従業員620名。生成AIのライセンスは間接部門80名の全員に配布済みで、内訳は総務12名、経理14名、購買10名、品質18名、生産管理16名、人事10名です。実効時給は260バーツとします。月給45,000バーツを月173時間で割った数字です。この会社が「うちにもプロンプト集がある」と言うとき、実態は次のようになっていました。
| 項目 | 数 |
|---|---|
| 共有フォルダにあるプロンプト | 47本 |
| 同一目的の重複を除いた実質 | 29本 |
| 最終更新が6か月以内のもの | 11本(47本の 23.4%) |
| 業務に紐付いていて残せたもの | 24本 |
47本という総数は、社員がまじめに取り組んだ証拠です。誰も怠けていません。しかし重複を除くと29本しか残らず、消えた18本は同じ業務に対して部門ごとに別々に書かれたものでした。品質が作った不適合報告書のたたき台と、生産管理が作った是正処置報告のたたき台が、ほとんど同じ指示文で別ファイルとして存在している。これが後述するコピペ分岐の実物です。
さらに厳しいのが鮮度です。最終更新が6か月以内のものは47本中11本、23.4%。裏を返せば76.6%は半年以上放置されています。生成AIのモデルは半年で入れ替わり、社内の様式も半年あれば変わります。放置されたプロンプトは、動かないのではなく微妙に間違った結果を返すようになります。動かなければ人は気づきますが、微妙に間違った結果は気づかれずに報告書に載ります。鮮度の切れたプロンプト集は、無いよりも危険になり得るということです。
残せた24本は、担当者名ではなく業務名で説明でき、かつ持ち主を1人決められたものだけです。「Aさんが議事録用に使っていたやつ」は残せません。文例は増えていくのに、業務との紐付けと持ち主と更新の責任が誰にも割り当てられていない。帝国データバンクの同じ調査で、生成AI活用の課題として挙がったのは上位から「情報の正確性」50.4%、「専門人材・ノウハウ不足」41.3%、「生成AIを活用すべき業務の範囲」40.0%、「情報漏洩のリスク」33.5%、「トラブル時の責任所在などのルール整備」25.5%でした。上位5つのうち4つは、プロンプトの文章力ではなく、プロンプトを使う体制の話です。ノウハウが足りないのではなく、ノウハウを置く場所とそれを腐らせない仕組みが無いのです。
プロンプト集には3つの層がある — 個人メモ・部門テンプレート・全社資産
「プロンプト集」という一語で呼ばれているものは、実際には性質のまったく違う3つの層に分かれます。この層を混同したまま運用しようとすることが、腐敗のいちばん大きな原因です。

| 層 | 実体 | 持ち主 | 更新のきっかけ | 求められる品質 |
|---|---|---|---|---|
| 第1層 個人メモ | 自分だけが使う走り書き | 本人 | 気が向いたとき | 本人が結果を判定できればよい |
| 第2層 部門テンプレート | 課や係で共有する文例 | 部門の誰か(不明確なことが多い) | 誰かが困ったとき | 同じ部門の人が真似できる |
| 第3層 全社の業務資産 | 業務手順の一部として管理される | 業務のオーナー(名前で決まっている) | 業務・様式・モデルが変わったとき | 誰が使っても同じ品質で出る |
多くの会社が作っているのは第2層で、それを第3層のつもりで運用します。ここに無理があります。第2層は「同じ部門の人が真似できる」水準しか要求されていません。同じ部門の人はその業務の前提を共有しているからです。何が不良で何が手直しか、どの様式に載せるのか、誰の承認が要るのか。それらを説明せずに済むので、指示文は短くて足ります。
ところが同じ文章を全社に配ると、前提を共有していない人が使い始めます。総務の人が品質のテンプレートを流用したとき、出てくる文章はそれらしく見えますが、社内の定義から外れています。そして外れていることに誰も気づきません。第2層のプロンプトは、部門の外に出た瞬間に品質が保証されなくなるという性質を最初から持っています。
第1層を否定する必要はありません。個人メモは大量にあってよく、更新されなくても害はありません。問題は、第1層と第2層を集めてフォルダに入れ、「これが全社のプロンプト集です」と宣言することです。集めても層は上がりません。層を上げるのは、持ち主を決めることと検収基準を書くことであって、集約作業ではありません。Atlanが2026年に公開した企業向けプロンプト管理の解説でも、最も多い失敗要因として「名前の付いた持ち主(named domain owner)が居ないこと」が挙げられています。第3層とは、要するに名前の書いてある層のことです。モデルケースで29本から5本を落としたのも、品質が悪いからではなく業務のオーナーを1人に決められなかったからです。持ち主を決められないものは、作っても半年後に第1層に落ちます。
業務プロンプト1本の実体は5要素 — 指示文だけを配るから再現しない
世に出回っている「業務プロンプト テンプレート」の多くは、役割の指定と制約の一部しか書いていません。「あなたは製造業の品質保証担当です。以下の不具合内容から是正処置報告書のドラフトを作成してください」といった具合です。これで結果が出る人は、書かれていない部分を自分の頭で補っています。補えない人が使うと、それらしいが使えない文章が出ます。格差が拡大したと答えた18.8%の企業で起きているのは、まさにこれです。業務で再現するプロンプトは、次の5つの要素を持っています。
| 要素 | 書くこと | 書かないとどうなるか |
|---|---|---|
| 役割 | どの立場・どの読者に向けた文章か | 文体と粒度が毎回ぶれる |
| 入力 | 何を貼るか、どの様式のどの項目か、貼ってよい情報の範囲 | 人によって渡す材料が違い、結果が比較できない |
| 制約 | 社内の定義・禁止事項・使ってよい用語 | 社内では通らない表現が混ざる |
| 出力形式 | 項目の順番、文字数、表か文章か、そのまま様式に貼れるか | 出てきた文章を人が並べ替えることになり、時間が減らない |
| 検収基準 | 合格と判定する条件。使う人が自分で確認できる問い | 良し悪しを作った人しか判定できない |
このうち、多くのプロンプト集に完全に欠けているのが入力と検収基準です。
入力が書かれていないと、同じプロンプトでも人によって渡す材料が変わります。出てくる報告書の質が違うのは当然ですが、使った本人は「プロンプトが悪い」と判断します。入力の指定は「不具合内容を貼ってください」では足りません。どの帳票のどの欄を、何件分、どの順番で貼るのかまで書きます。そしてもう一つ、貼ってはいけない情報の範囲もここに書きます。取引先名、単価、個人名、図面番号のうち何が出してよくて何が駄目かは、プロンプト側に書いておかないと守られません。この線引きは全社で決める事項で、生成AI利用規程の作り方で扱っています。プロンプト集の入力欄は、その規程を業務ごとに具体化したものだと考えてください。
検収基準は、5要素のなかで唯一、出力を評価するための要素です。ここが無いと、出てきた文章が使えるかどうかを判定できるのは書いた本人だけになります。難しく考える必要はなく、使う人が自分でイエス・ノーを答えられる問いを数問並べれば足ります。是正処置報告書のドラフトなら、発生日と発見工程が入力どおり入っているか、暫定処置と恒久処置が分けて書かれているか、社内で使わない用語が混ざっていないか、といった問いです。モデルケースでは24本に対して1本あたり5問、合計120問を作りました。1問0.5時間で60時間、実効時給260バーツを掛けて15,600バーツです。この120問があると、直して良くなったのかを測れますし、モデルが更新されたときに24本すべてを機械的に点検できます。
プロンプト集が腐る4類型 — 原因はすべて業務ルールの直書き
Atlanは前述の解説記事で、企業のプロンプト運用が壊れる型として Monolithic Prompting、Copy-Paste Drift、Obscured Blast Radius、Deferred Runtime Errors の4つを挙げ、さらに最も多い失敗要因として名前の付いた持ち主が居ないことを指摘しています。これを業務プロンプト集の文脈に置き直すと、現場で実際に起きる腐り方は次の4つに整理できます。
| 腐り方 | 症状 | モデルケースでの現れ方 | 直し方 |
|---|---|---|---|
| 丸ごと1本化 | 1本に手順も定義も例外も全部書いてある | 1本に詰め込まれすぎて直せる人が居ない | 業務ルールを外に出し、参照させる |
| コピペ分岐 | 少しずつ違う派生版が増える | 47本のうち18本が重複 | 正本を1本に決め、派生を廃止する |
| 影響範囲が見えない | 1か所直すとどこに影響するか分からない | 用語を変えたら別部門の出力が崩れた | 参照関係を持ち、検収基準で点検する |
| 持ち主不在 | 誰も直さないまま古くなる | 76.6%が6か月以上未更新 | 業務オーナーを名前で決める |
この4つは症状が違うだけで、原因は1つです。業務のルールをプロンプトの本文に直書きしていることです。たとえば「不良率は検査で不合格となった数を検査数で割ったものとする。手直し後に合格したものは分子に含めない」という定義をプロンプト本文に書き込むと、その定義を使う本数だけ同じ文章が複製されます。定義が変わったとき、散らばった全部を直せる人はいません。だから何本かだけ直され、残りは古い定義のまま残ります。これが丸ごと1本化とコピペ分岐と影響範囲が見えないことの同時発生です。
対策は単純で、業務ルールをプロンプトの外に置き、プロンプトからは参照させます。用語定義・数値の算出方法・様式の項目順・禁止事項を1つの文書にまとめ、プロンプト側には「不良率の定義は用語定義集に従う」とだけ書く。運用としては、その定義文書をプロンプトと一緒に渡す形になります。こうすると直す場所は1か所で、直した瞬間に参照している全プロンプトの出力が変わります。影響範囲も「その定義を参照している本数」として数えられます。
影響範囲が見えないことの本当の怖さは、壊れたことが実際に誰かがその業務で使う瞬間まで分からない点にあります。プログラムのように事前に検査してくれるものが無いので、月次の報告書作成の日に初めて「今月は様子がおかしい」と気づくことになります。検収基準を持っている意味はここにあり、モデル更新や定義変更のあとに120問を通しておけば、業務の当日ではなくその前に気づけます。
どこに置くか — 共有フォルダが最下層である理由
プロンプト集の置き場所として最初に選ばれるのは、ほぼ例外なく共有フォルダです。追加費用がゼロで、全員がアクセス方法を知っているからです。しかし共有フォルダには、資産として運用するために必要な機能が3つ欠けています。版の管理、閲覧編集権限の分離、そして検収の記録です。

| 置き場所 | 版の管理 | 権限の分離 | 検収の記録 | 実務上の限界 |
|---|---|---|---|---|
| 共有フォルダ | ファイル名に日付を付ける運用のみ | フォルダ単位でしか分けられない | 残らない | 最新がどれか分からなくなる |
| 文書管理システム・社内ポータル | 版が残る | 閲覧と編集を分けられる | 承認履歴として残せる | プロンプト特有の評価はできない |
| プロンプト管理の専用ツール | 版と差分が残る | 役割ごとに分けられる | 評価結果を版に紐付けられる | 費用と運用の学習が要る |
共有フォルダの何が致命的かというと、閲覧と編集を分けられないことです。プロンプト集は、使う人が80名いて直す人が数名という構造になります。全員が編集できる場所に置くと、良かれと思った微修正が正本に入り、しかも誰が何を変えたか残りません。かといって編集を止めると、現場が気づいた改善が反映されません。必要なのは、誰でも改善提案を出せて、正本に入れるのは持ち主だけ、という分離です。PromptLayerが2026年にまとめた「プロンプト管理ツール7選」のような記事が成立していること自体、版管理・評価・権限を持つ専用ツールが市場として成り立っていることの表れです。
ただし、いきなり専用ツールを入れる必要はありません。モデルケースの第4層120,000バーツは、既存の社内ポータルの上に置き場所と版管理と権限を作り込む費用であって、ツールを買う費用ではありません。ここで同時に決まるのが、そこに載る情報の管理水準です。プロンプト集には社内の定義・様式・禁止事項が書かれるので、業務ノウハウの塊になります。社外のサービス上に置くか、生成AIのサービスと同じ環境に置くかは、利便性ではなく情報管理の判断です。この論点はセキュアな生成AI環境の構築で扱っています。なおAtlanは、保管・版管理・権限・検収ゲートまでを整えるのに3〜6週、業務ルールの外出しまで含めると10〜14週という所要期間を示しています。年単位の計画ではありませんが、数日で終わるものでもありません。
多言語拠点の設計 — 訳させない180語を先に決める
タイの拠点では、ここに一段の難しさが加わります。日本語・タイ語・英語が同時に走っているからです。そして多くの会社が、良かれと思ってプロンプトを言語ごとに翻訳します。これがコピペ分岐の多言語版を生みます。正しい設計は、1本のプロンプトを3つの部品に分け、それぞれ別々に言語を決めることです。
| 部品 | 言語の決め方 | 理由 |
|---|---|---|
| 指示文 | 日本語または英語で1本だけ持つ | 言語ごとに書き分けると同じ業務のプロンプトが3本に分岐する |
| 入力データ | 現物の言語のまま渡す | タイ語の日報を先に和訳すると、そこで情報が落ちる |
| 出力 | 読む人の言語で指定する | 読み手が読めなければ工数は減らない |
この3分割をせずに「全部タイ語にそろえる」と決めると精度が落ちます。とくに入力データを事前に翻訳する運用が危険です。タイ語の日報に書かれた現場の表現を人が和訳した時点で、判断が1回入っています。その判断込みの文章を生成AIに読ませても、元の情報には戻りません。
そのうえで、訳させてはいけない語を先に固定します。モデルケースでは180語の用語辞書を作りました。中身は型番、部品番号、様式名、社内用語、役職名です。これらは訳された瞬間に照合できなくなります。型番が現地語表記に置き換わると図面と突き合わせられませんし、様式名が意訳されるとどの帳票のことか分からなくなります。180語という規模感は決して大きくなく、逆にこの180語を決めずに始めると、同じ型番が3通りの表記でデータに残り、あとから直すほうがはるかに高くつきます。なお正規プロンプト24本のうち多言語で使うものは15本で、残り9本は日本語だけで完結します。全部を多言語対応にしようとしないことも設計のうちです。
費用を5層に分ける — 外注できるのは第4層と第5層だけ
ここから費用の話に入ります。24本を第3層の業務資産として整備した場合の初期費用は、次の5層に分かれます。内製分は実効時給260バーツで換算しています。

| 層 | 内容 | 金額(バーツ) | 内製/外注 |
|---|---|---|---|
| 第1層 | 棚卸しと選別(47本の収集・重複排除・業務との紐付け)60時間 | 15,600 | 内製 |
| 第2層 | 正規プロンプト24本の作成(3.5時間/本 = 84時間) | 21,840 | 内製 |
| 第3層 | 検収基準の作成(24本 × 5問 = 120問、0.5時間/問 = 60時間) | 15,600 | 内製 |
| 第4層 | 置き場所・版管理・閲覧編集権限の整備 | 120,000 | 外注 |
| 第5層 | 展開と教育(部門別ハンズオン6回 × 3時間 + 資料) | 180,000 | 外注 |
| 合計 | 353,040 |
見るべきなのは金額の大小ではなく、内製と外注の線がどこに引かれているかです。内製分は第1層から第3層の合計53,040バーツで総額の15.0%、外注分は第4層と第5層の300,000バーツで85.0%。金額では外注が圧倒的ですが、外注できない15.0%のほうが決定的です。
第1層の棚卸しは、47本を集めて重複を排除し、どの業務に紐付くかを判定する作業です。この判定は社外の人間にはできません。品質の不適合報告と生産管理の是正処置が同じ業務なのか違う業務なのかは、その会社の運用を知らないと決められないからです。第2層も同じで、1本3.5時間の中身は文章を書く時間ではなく、社内の定義と様式を確認して要素に落とす時間です。そして第3層の検収基準は決定的に外注できません。合格の条件を書くとは、自社の業務で何が正しいかを宣言することです。それを外部に決めさせた時点で、そのプロンプト集は自社の資産ではなくなります。
逆に第4層と第5層は外注が向いています。置き場所と版管理と権限の作り込みは技術作業ですし、部門別ハンズオンの運営と資料作成も外から入れたほうが速い。ハンズオンを6回に分けているのは、総務・経理・購買・品質・生産管理・人事の6部門で使うプロンプトも入力する帳票も違うからです。1回にまとめると、自部門に関係のない話を聞く時間が5部門分発生し、その場で自分の業務のプロンプトを試せません。見積を比べるときは、第1層から第3層が「お客様作業」と書かれているかを必ず確認してください。含まれていない見積は表示金額こそ300,000バーツですが、実際には自社で53,040バーツ相当、時間にして204時間の作業が発生します。
さらに、見積から抜けやすいのが年間の運用費です。
| 項目 | 金額/年(バーツ) |
|---|---|
| 月次レビュー(8時間/月 × 12) | 24,960 |
| 四半期の再検収(12時間 × 4回) | 12,480 |
| モデル更新時の総点検(16時間 × 年2回) | 8,320 |
| 合計 | 45,760 |
年45,760バーツ、時間にすると176時間です。初期費用353,040バーツの13.0%に相当し、決して小さくありません。しかしこの176時間を払わないと、冒頭の「76.6%が6か月以上未更新」の状態に戻ります。プロンプト集は、運用費を払った月だけ価値が続くタイプの資産です。買い切りの設備とは性質が違います。稟議書には初期費用だけでなく、この年間運用費を必ず併記してください。
ROIの組み立て — 試行錯誤時間で書くと必ず赤字になる
ここが、稟議書を書く人がいちばん転ぶところです。プロンプト集の効果を「プロンプトを考える試行錯誤の時間が減る」で説明すると、必ず赤字になります。
理由は単純です。プロンプト集が良くなると、生成AIを使う人が増えます。今まで使っていなかった人が使い始め、今まで1日1回だった人が5回使うようになります。試行錯誤の1回あたりの時間は減りますが、回数が増えるので、生成AIに向かっている総時間はむしろ増えます。ログを取って導入前後の生成AI利用時間を比べれば、増えた数字が出ます。この数字を持って役員会に行けば、その場で企画は終わります。
正しい測り方は、生成AIに向かっている時間ではなく、対象業務そのものの工数を見ることです。間接部門80名について、生成AIが効き得る業務類型の工数を洗い出すと次のようになります。
| 業務類型 | 時間/月 |
|---|---|
| 文書作成(報告書・議事録・社内通知) | 210 |
| 要約・読み込み(英文規格・本社資料) | 96 |
| 翻訳・多言語化(日 ↔ タイ ↔ 英) | 168 |
| 照合・チェック(帳票・仕様) | 132 |
| 合計 | 606 |
合計606時間/月。これが分母です。80名で割ると1人あたり月7.6時間ですから、誇張した数字ではありません。タイ拠点で翻訳・多言語化が168時間と大きいのが特徴で、これは日本語とタイ語と英語が同時に走る拠点に固有の工数です。この606時間に対して、実際に生成AIが適用できている割合(適用率)と、適用できた業務で何%短縮できたか(平均短縮率)の2つを掛けます。
| 適用率 | 平均短縮率 | 削減時間/月 | |
|---|---|---|---|
| 整備前 | 18.0% | 32.0% | 34.9 |
| 整備後 | 46.0% | 41.0% | 114.3 |
計算は 606 × 18.0% × 32.0% = 34.9時間/月、606 × 46.0% × 41.0% = 114.3時間/月です。増分は79.4時間/月。実効時給260バーツを掛けて20,644バーツ/月、年間で247,728バーツになります。
この表で重要なのは、適用率と短縮率の両方が上がっていることです。適用率が18.0%から46.0%に上がるのは直感的に分かります。使える業務が増えるからです。しかし短縮率まで32.0%から41.0%に上がる理由は説明が要ります。プロンプトが5要素で書かれていて出力形式まで指定されていると、出てきた文章をそのまま様式に貼れます。出力形式の指定が無いプロンプトでは、出てきた文章を人が並べ替え、項目を足し、体裁を整える作業が残ります。この後工程が消えるので、1回あたりの短縮率そのものが上がるのです。検収基準があることで手戻りが減る効果も、ここに含まれます。
実務で必ず聞かれるのが「適用率46.0%をどうやって測るのか」です。生成AIサービスの利用ログでは測れません。ログに出るのは利用回数であって、対象業務のうち何%で使われたかではないからです。現実的な測り方は、606時間の内訳を作ったときの業務一覧に対して、四半期ごとに担当者へ「この業務で正規プロンプトを使っていますか」を確認することです。手間はかかりますが、これをやらないと投資の効果が永久に検証できません。この実利用率の追いかけ方はAI活用の定着支援で詳しく扱っています。
年間便益247,728バーツから年間運用費45,760バーツを引くと、純便益は201,968バーツ/年です。初期費用353,040バーツを割ると、353,040 ÷ 201,968 = 1.7年(21.0か月)。これが資産として整備した場合の回収年数です。
文例集と資産 — 回収年数では文例集が勝つ
さて、ここからがこの記事のいちばん厄介な部分です。
同じモデルケースで、第3層から第5層を省き、第1層と第2層だけをやって共有フォルダに置く案を考えます。棚卸しをして24本を書き、フォルダに入れて周知する。検収基準は作らず、置き場所も整備せず、ハンズオンもやらない。世の中でいう「プロンプト集を作った」の大半がこれです。初期費用は 15,600 + 21,840 = 37,440バーツで済みます。
| 文例集 | 資産 | |
|---|---|---|
| 初期費用(バーツ) | 37,440 | 353,040 |
| 適用率 | 24.0% | 46.0% |
| 平均短縮率 | 34.0% | 41.0% |
| 削減時間/月 | 49.4 | 114.3 |
| 年間便益(増分・バーツ) | 45,240 | 247,728 |
| 回収年数 | 0.8年 | 1.7年 |
文例集でも効果はゼロではありません。606 × 24.0% × 34.0% = 49.4時間/月。整備前の34.9時間/月から14.5時間/月増えています。260バーツを掛けて月3,770バーツ、年45,240バーツ。初期費用37,440バーツを割ると0.8年です。回収年数の数字だけを見れば、文例集の圧勝です。0.8年と1.7年なら、どんな役員会でも0.8年が通ります。
この比較を正直に出すことを恐れないでください。隠して資産だけを提案すると、誰かが必ず「もっと安く済むのでは」と言い出し、そこで議論が止まります。最初から並べたうえで、なぜ回収年数で比べてはいけないのかを説明するほうが強い。
理由は、回収年数という指標が便益の持続期間を無視するからです。文例集には検収基準がありません。だからモデルが変わったときに何が壊れたか分かりません。持ち主も決まっていません。だから業務の様式が変わっても誰も直しません。置き場所も整備されていないので、誰かが良かれと思って直した派生版が増えます。冒頭で見た「47本のうち鮮度が保たれているのは23.4%」という状態が、12か月かけて再生産されます。文例集の便益45,240バーツは1年目には出ますが、そこで止まり、2年目には効果が整備前の水準に戻ります。一方の資産は、年45,760バーツの運用費を払い続けることで201,968バーツ/年の純便益が翌年以降も続きます。
| 文例集 | 資産 | |
|---|---|---|
| 年間便益(増分・バーツ) | 45,240 | 247,728 |
| 年間運用費(バーツ) | なし(レビューも再検収も設定しない) | 45,760 |
| 年間の純便益(バーツ) | 45,240 | 201,968 |
| 2年目以降 | 整備前水準に戻る | 運用費を払う限り継続 |
| 3年間の累積純便益(バーツ) | 45,240 | 605,904 |
| 初期費用を引いた3年後の手残り(バーツ) | 7,800 | 252,864 |
資産側の3年累積は 201,968 × 3 = 605,904バーツ、そこから初期費用353,040バーツを引いて252,864バーツ。文例集側は45,240バーツで打ち止めなので、初期費用37,440バーツを引くと7,800バーツしか残りません。3年で見ると差は32倍以上です。回収年数では2.1倍負けていた選択肢が、3年累積では32倍勝ちます。
ここから引き出すべき教訓は、プロンプト集に限りません。回収年数だけで比べると、資産にならない選択肢が必ず勝ちます。 初期費用が小さく、効果が短期間で出て、そして消えるものほど、回収年数という指標では良い数字が出るからです。稟議書に回収年数を書くこと自体は構いませんが、必ず3年間の累積を並記してください。並記しないと、社内でいちばん安い案が自動的に選ばれ、2年後に「生成AIは効果がなかった」という結論だけが残ります。PwC Japanが公開している生成AIの実態調査でも、業務プロセスやデータ、利用環境、ガバナンスといった土台を先に整えることが効果創出の前提だと整理されています。土台を整える費用は効果が出るまでの時間を延ばすので、回収年数の数字は必ず悪化します。それを承知で払うかどうかが、この投資の分かれ目です。
プロンプトエンジニアリング研修・利用規程・定着支援との役割分担
「プロンプトエンジニアリング研修を受ければプロンプト集は要らないのでは」という質問をよく受けます。逆に「プロンプト集を配れば研修は不要では」とも聞かれます。どちらも違います。この4つは対象も持続性も違う道具です。
| 施策 | 何を解決するか | 誰に効くか | 持続性 |
|---|---|---|---|
| プロンプトエンジニアリング研修 | 書き方の原理を理解する | 作る側の数名 | 本人が異動すると消える |
| 業務プロンプト集 | 業務ごとの再現性を確保する | 使う側の全員 | 更新すれば続く |
| 生成AI利用規程 | 入れてよい情報の線引き | 全員 | 改訂すれば続く |
| 定着支援 | 実際に使われているかを測り、直す | 使う側の全員 | 継続活動 |
研修は作る側の数名に効きます。5要素で書くという発想も、業務ルールを外に出すという発想も、研修なしにいきなり出てくるものではありません。しかし研修だけでは80名の格差は埋まりません。研修を受けた人が上手くなるだけだからです。格差が拡大したと答えた18.8%の状況は、研修だけを実施するとむしろ広がります。逆にプロンプト集だけを配ると、書かれたとおりに使う人は増えますが、業務が少し変わったときに誰も直せません。生成AIの実務研修やハンズオン研修の設計は製造業の生成AI研修にまとめています。モデルケースの第5層180,000バーツは部門別ハンズオン6回分で、これは研修というより「自部門のプロンプトを自分の帳票で1回動かしてみる」場であり、座学とは別物として設計しています。
タイの拠点で押さえておきたい前提もあります。ETDAとNSTDAが実施した調査では、2024年時点でタイの組織のうちAIを利用中と答えたのは17%、今後導入を計画しているのが73%でした。これは2024年時点の調査であって、2026年現在の数字ではありません。ただし、計画段階の組織が7割を超えていたという構造は重要です。多くの組織が同時に立ち上げ期に入るということは、他社に参考にできる先行事例が少ないということでもあります。だからこそ他社のプロンプト集をそのまま借りてくることはできず、自社の業務に紐付けた第1層から第3層の作業が要ります。
90日の進め方
初期費用353,040バーツのうち内製作業は合計204時間です。これを日常業務の合間でこなす前提で、90日を4つの区切りに分けます。4つの区切りを重ねず、前の区切りを終わらせてから次に進むのが要点です。
| 期間 | やること | 完了の判定 |
|---|---|---|
| 1日目から30日目 | 既存プロンプトの棚卸しと選別、業務との紐付け、残す24本の確定 | 24本それぞれに業務名と持ち主の名前が入っている |
| 31日目から60日目 | 24本を5要素で書き直す。並行して用語辞書180語と業務ルール文書を作る | 24本の本文に社内定義が直書きされていない |
| 61日目から75日目 | 検収基準120問の作成と、置き場所・版管理・権限の整備 | 24本すべてで、使う人が自分で合格判定できる |
| 76日目から90日目 | 部門別ハンズオン6回。実運用開始と月次レビューの体制決め | 6部門とも自部門の帳票で1本以上を動かした |
最初の30日で最も重要なのは、24本を絞り込むことではなく持ち主の名前を入れることです。ここで名前が入らない業務は無理に残さないでください。名前が入らないまま先に進むと、61日目以降の検収基準を誰が承認するのかで必ず止まります。用語辞書と業務ルール文書を書き直しと並行して作るのにも理由があります。プロンプトを5要素で書き直していると、「この定義はプロンプトに書くべきではない」と気づく瞬間が何度も来るからです。そのとき外に出す先が無いと、結局本文に書いてしまいます。
61日目からの検収基準120問は、まとめて1人で書かないでください。24本の持ち主がそれぞれ自分の5問を書くのが正しい進め方です。1人で書くと速く終わりますが、その5問はその人の基準になり、持ち主が承認できません。そして76日目からのハンズオンでは、必ず自部門の実際の帳票を使ってください。サンプルデータでやると全部うまくいきますが、実データでやると入力の指定が足りないことや出力形式が様式に合っていないことがその場で見つかります。ハンズオンは教える場ではなく最後の検収の場です。
よくある質問(FAQ)
業務のプロンプト集は何本くらい必要ですか
モデルケースでは間接部門80名に対して24本です。出発点は共有フォルダにあった47本で、重複を除くと29本、業務に紐付いて持ち主を決められたものが24本でした。目安は人数ではなく業務類型の数で決まります。文書作成・要約・翻訳・照合の4類型に部門ごとの帳票の違いを掛け合わせると、20本台に落ち着きます。本数を増やしすぎると月次レビューが8時間では収まらなくなり、そこから更新が止まります。本数を増やすより1本の5要素を厚くするほうが効果が出ます。
プロンプトエンジニアリング研修を受ければプロンプト集は要らなくなりますか
なりません。研修が効くのは作る側の数名で、書き方の原理を理解してもらうためのものです。使う側の80名全員を研修で同じ水準に引き上げることは現実的ではありませんし、仮にできても異動と入退社で毎年やり直しになります。帝国データバンクの調査で「使いこなせる社員と使いこなせない社員の格差が拡大した」と答えた企業が18.8%あるという状況は、研修だけを実施するとむしろ悪化します。作る側に研修、使う側にプロンプト集という役割分担が現実的です。
業務プロンプトのテンプレートは市販や公開のものを買えば済みますか
出発点としては使えますが、それだけでは業務に載りません。公開されているテンプレートに書かれているのは5要素のうち役割と制約の一部です。入力の指定と検収基準は、自社の帳票と定義を知らないと書けません。モデルケースの内製分53,040バーツは、まさにこの書けない部分の費用です。総額353,040バーツの15.0%にすぎませんが、ここを購入で埋めようとすると、出てきたものを自社で合格判定できず結局使われません。
生成AIの実務研修とハンズオン研修はどちらを先にやるべきですか
正規プロンプトを書ける状態を作ってからハンズオンです。モデルケースの90日計画では、24本の書き直しと検収基準の作成を終えた76日目以降に部門別ハンズオンを6回置いています。プロンプトが無い状態でハンズオンをやると、当日その場で作ったものを持ち帰ることになり、それは第1層の個人メモにしかなりません。作る側の数名に対する実務研修は逆に早いほうがよく、31日目からの書き直しに入る前に受けておくのが理想です。
生成AIの社内展開でプロンプト集はどの順番で作るべきですか
先に利用規程、次にプロンプト集、最後に定着支援の測定という順番になります。利用規程が無い状態でプロンプト集を作ると、入力の要素に「何を貼ってよいか」を書けません。取引先名や単価や個人名をどこまで出してよいかは、業務ごとではなく全社で決めるものだからです。逆に規程だけあってプロンプト集が無い状態は、禁止事項だけが配られて使い方が配られていない状態で、利用率が上がりません。
プロンプト集の効果はどう測ればよいですか
生成AIの利用時間や利用回数では測らないでください。プロンプト集が効くと利用者が増えるので総時間は増え、その数字を出すと投資が赤字に見えます。測るべきは対象業務そのものの工数で、モデルケースでは間接部門80名の606時間/月が分母です。そこに適用率と平均短縮率を掛けます。整備前は18.0%と32.0%で34.9時間/月、整備後は46.0%と41.0%で114.3時間/月、増分79.4時間/月が便益です。適用率は利用ログでは取れないので、四半期ごとに業務一覧に対して使用の有無を確認する運用が要ります。
生成AIで業務効率化の効果が出ないのはプロンプトが悪いからですか
多くの場合、悪いのはプロンプトの文章ではなく、プロンプトに書かれていない部分です。入力として何を渡すかが決まっていない、出力形式が様式に合っていない、合格の条件が本人にしか判定できない。この3つのどれかが欠けていると、文章をいくら磨いても再現しません。腐り方の4類型はいずれも業務のルールをプロンプト本文に直書きしていることが原因です。ルールを外に出して参照させる形に変えると、1か所直せば全本に反映され、影響範囲も数えられるようになります。
まとめ
プロンプト集が使われないのは、文章が下手だからではありません。指示文だけを集めて配っているからです。業務で他人が同じ結果を出せるプロンプトには、役割・入力・制約・出力形式・検収基準の5要素が書かれています。このうち入力と検収基準は、自社の帳票と定義を知らないと書けません。だから初期費用353,040バーツのうち、外注できない内製分53,040バーツ、総額の15.0%が決定的に重要になります。
プロンプト集には個人メモ・部門テンプレート・全社資産という3つの層があり、多くの会社は第2層を作って第3層のつもりで運用します。層を上げるのは集約作業ではなく、持ち主を名前で決めることと検収基準を書くことです。モデルケースでは47本を棚卸しして29本に整理し、持ち主を決められた24本だけを残しました。鮮度が保たれていたのが47本中11本、23.4%だったという事実は、持ち主不在の帰結です。
ROIは試行錯誤時間の削減で書いてはいけません。プロンプト集が効くと利用者が増え、生成AIに向かう総時間は増えるからです。便益は対象業務そのものの工数606時間/月で測ります。適用率18.0%・短縮率32.0%で34.9時間/月だったものが、整備後は46.0%・41.0%で114.3時間/月になり、増分79.4時間/月、年247,728バーツ。運用費45,760バーツを引いた純便益201,968バーツで初期費用を割ると1.7年、21.0か月です。
そして最後に、この記事でいちばん伝えたいことです。第1層と第2層だけの文例集なら初期37,440バーツ、年間便益45,240バーツで回収0.8年。回収年数だけを見れば文例集が勝ちます。しかし文例集の便益は12か月で止まり、3年間の累積は45,240バーツで打ち止め、初期費用を引くと手残りは7,800バーツです。資産のほうは3年で605,904バーツ、初期費用を引いて252,864バーツ残ります。回収年数だけで比べると、資産にならない選択肢が必ず勝ちます。 稟議書には、回収年数と3年累積を必ず並べて書いてください。
まだ本数も対象業務も決まっていない段階で構いません。共有フォルダに何本のプロンプトが眠っているか、そのうち何本に業務名と持ち主を付けられるかを一緒に数えるところから始められます。既存のプロンプトのファイル一覧と、間接部門の業務分担が分かる資料があれば、24本相当の絞り込みと、内製と外注の線引きの当たりまではその場で付けられます。ご相談はお問い合わせフォームからお寄せください。