「プロンプトを販売する」という発想に違和感を覚える方もいるかもしれません。「テキストを売るだけで、本当にビジネスになるのか」という疑問です。しかし2026年、Gemini Gems のカスタムインストラクション機能が成熟したことで、プロンプト群は単なるテキストではなく「業務に組み込める製品」になりつつあります。
私はここ数ヶ月、知人の中小企業向けに Gemini Gems を「設計してパッケージ販売する」試みを続けています。最初は驚くほど反応が薄かったのですが、設計思想・価格設定・サポート体制を磨くうちに、月額課金で継続契約してくれる企業が増えてきました。この記事は、そのプロセスで分かった「企業向けプロンプト製品ビジネス」の全体像を、これから始めたい方向けに体系化したものです。
なぜ「プロンプト」が製品として成立するのか
まず、プロンプトがなぜ製品として成立するのかを整理します。背景には3つの構造変化があります。
第一に、企業内に「AI を活用したいが、何をどう書けば良い結果が出るか分からない」という需要が大量にあります。多くの企業は ChatGPT や Gemini を業務で使うことは決めたものの、「具体的にどう使うか」のノウハウを持たず、社内検索でヒットする一般論的なプロンプトテンプレートをそのまま使っています。これは「使える」ではなく「使ってる」状態であり、業務改善効果は限定的です。
第二に、Gemini Gems のような「カスタムインストラクション + ファイル添付 + 実行例」をひとまとめにできる仕組みが、プロンプトの「製品化」を技術的に可能にしました。単なるテキストではなく、業務知識を含んだ実行可能なパッケージとして提供できるようになったのです。
第三に、プロンプト製品の品質は、AI モデルの汎用性能とは別軸で価値を持ちます。最新モデルが出ても、業務文脈を踏まえた良質なプロンプト設計の価値は失われません。むしろ、モデル性能が上がるほど、適切な指示を出せる人が活かせるポテンシャルが大きくなります。
これら3つを背景に、企業向けプロンプト製品ビジネスは、個人開発者にとって今まさに参入機会のある領域になっています。
「製品」としての Gem に含めるべき7要素
プロンプトを「製品」として販売するためには、単純なテキストファイルでは不十分です。私が必ず製品に含めている7つの要素を整理します。
第一に、明確な業務ターゲット定義です。「営業部門向け：顧客提案書のドラフト生成」「経理部門向け：月次レポートの草案作成」のように、誰がいつ何のために使うかを明示します。
第二に、Gemini Gems のカスタムインストラクション本体です。役割定義、出力形式の指定、禁止事項、業界用語の事前定義などを構造化して書きます。
第三に、業務知識を補強する添付ファイル群です。社内用語集、過去の優良アウトプット例、参考資料、業界規制への対応指針など。
第四に、5〜10個の実行例（プロンプト＋期待出力のセット）です。ユーザーが「こう書けばこう返ってくる」を理解するための具体的な使い方ガイドになります。
第五に、品質チェックリストです。「出力に含まれてはいけない情報」「出力に必ず含まれるべき要素」「再生成すべき条件」などを明示し、ユーザーが品質を自己判断できるようにします。
第六に、バージョン情報と更新履歴です。「v1.2: 業界用語10個追加」「v1.3: 出力フォーマット改善」のように、製品の改善を追跡可能にします。
第七に、サポート連絡先と利用規約です。問い合わせ窓口、出力の二次利用範囲、AI出力の責任所在の明確化など、企業が安心して導入できる枠組みです。
Gem 製品の納品パッケージ構成例
[1] product_overview.pdf ターゲット業務、想定ユーザー、得られる成果
[2] gemini_gem_setup_guide.md カスタムインストラクションの設定手順 Gemini Gems への取り込み方
[3] custom_instructions.txt Gem 本体（コピペ用）
[4] /attachments/ 用語集、参考資料、業界規制ガイド
[5] /examples/ 例1: 顧客提案書ドラフト 例2: 月次レポート要約 ...例10
[6] quality_checklist.pdf 出力品質の自己評価方法
[7] version_history.md [8] support_terms.pdf このパッケージ構成で納品することで、「テキストを売っている」ではなく「業務改善ソリューションを売っている」という体験を提供できます。これが価格決定権を握る鍵です。
4つのビジネスモデルの比較
Gem 製品をどう売るかについて、4つの代表的なビジネスモデルがあります。
第一は単体販売モデルです。1 Gem あたり数万円〜数十万円の買い切りで提供します。導入が簡単で初期障壁が低いですが、リカーリング収益にならないため、案件獲得を続ける必要があります。
第二はパッケージ販売モデルです。複数の関連 Gem をまとめて「営業部門向けスターターキット」「経理向けセット」のように販売します。1パッケージ 50〜200万円程度。利益率が高く、業界特化のブランディングがしやすいです。
第三はサブスクリプションモデルです。月額 5〜30万円で、使い放題のアクセス権 + 定期的な改善更新 + 限定サポートを提供します。リカーリング収益が積み上がり、長期的な顧客関係を築けます。
第四はライセンス契約モデルです。企業ごとに個別契約を結び、その企業専用の Gem を年間契約で提供します。年間 200〜500万円の規模。少数の顧客で高収益が出ますが、営業・契約コストが高いです。
4モデルの選び方ガイド
[A] 単体販売 向いている顧客: 中小企業、特定業務の単発改善が目的 初期投資少 / 即金性高 / 反復販売は難しい
[B] パッケージ販売 向いている顧客: 業界特化のソリューションを求める企業 高単価 / 競合少 / ノウハウ蓄積必要
[C] サブスク 向いている顧客: 継続的な業務改善を求める企業 リカーリング / 顧客関係深い / 解約率管理が重要
[D] ライセンス契約 向いている顧客: 大企業、機密性重視、カスタマイズ要望強い 高単価 / 安定 / 営業負荷大 私が知人企業に売る際は、まず[A]単体販売で関係を作り、満足度が高い場合に[B]パッケージへ、定着したら[C]サブスクへ、と段階的にアップセルしていく形を取っています。
価格設定の3つの原則
プロンプト製品の価格設定は、感覚で決めると必ず安すぎる方向に振れます。私が守っている3つの原則を共有します。
第一の原則は「業務時間削減量を価格根拠にする」ことです。「この Gem を導入すると、月20時間の業務が5時間に削減できます。月15時間 × 担当者の時給 5,000円 = 月7.5万円の人件費削減です」のような計算を、見積もりと一緒に提示します。これがあると、月額3万円の Gem サブスクが「破格に安い」と感じてもらえます。
第二の原則は「業界相場ではなく、自分のコスト構造から決める」ことです。1つの Gem 製品を作るのに、どれだけの設計時間・テスト時間・ドキュメント作成時間がかかったか。それを年間でどれだけの顧客に売れるか。これらを踏まえた損益分岐点を超える価格を設定します。
第三の原則は「最低価格は10万円以上に設定する」ことです。これは「安いと逆に信頼されない」ためです。プロンプト製品はコンサルティングに近い性質を持つので、安すぎると「安かろう悪かろう」と判断されます。10万円以上を最低ラインに置くことで、「ちゃんとした製品」という認識を確保します。
Gem 製品の品質保証体制
プロンプト製品を「製品」として売るからには、品質保証の仕組みが必要です。私が用意している3つの仕組みを共有します。
ひとつめは、回帰テストの自動化です。Gem 製品ごとに「想定入力 → 期待出力」のテストケースを20〜50件用意します。Gemini モデルがアップデートされたときや Gem の改修を行ったときに、テストを自動実行して品質劣化を検出します。
# Gem 回帰テストの簡易例（Python + Gemini API） import google.generativeai as genai import yaml
genai.configure( api_key = "YOUR_API_KEY" )
def run_gem_test (gem_instructions: str , test_case: dict ) -> bool : model = genai.GenerativeModel( model_name = "gemini-3-2" , system_instruction = gem_instructions, ) response = model.generate_content(test_case[ "input" ]) output = response.text
# 期待されるキーワードがすべて含まれているか for keyword in test_case[ "expected_keywords" ]: if keyword not in output: return False # 禁止ワードが含まれていないか for forbidden in test_case[ "forbidden_keywords" ]: if forbidden in output: return False return True
# テストケース読み込み test_cases = yaml.safe_load( open ( "test_cases.yaml" )) gem_instructions = open ( "custom_instructions.txt" ).read()
passed = sum ( 1 for tc in test_cases if run_gem_test(gem_instructions, tc)) print ( f "Passed: { passed } / { len (test_cases) } " ) ふたつめは、利用ログのモニタリングです。顧客が実際にどのような入力で Gem を使い、どのような出力を得たかをログ化し、月次で品質傾向を分析します。問題のある出力パターンが見つかれば、即座にカスタムインストラクションを更新します。
みっつめは、定期的な顧客ヒアリングです。3ヶ月に1度、利用顧客に「最近の使い心地」「改善してほしい点」「新たに必要な機能」を聞き取ります。これがそのまま次バージョンの改善ロードマップになります。
顧客成功事例の作り方
B2B のプロンプト製品ビジネスで最も強力な営業ツールが、顧客成功事例です。「このGemを導入したA社では、月20時間の業務が5時間に短縮されました」という具体的な数値とストーリーが、新規顧客の意思決定を加速します。
事例化のために必要な手順は3つです。第一に、契約時に「改善前後の効果測定にご協力ください」と伝え、ベースライン（導入前の業務時間・品質指標）を記録します。第二に、3ヶ月後に効果測定（業務時間・品質・顧客満足度の変化）を行います。第三に、顧客の許諾を得てケーススタディとして公開します。
事例公開には、匿名版（業界・規模だけ明記）と実名版の両方を用意します。実名版は許諾ハードルが高いですが、新規顧客への説得力が明確に高いです。許諾が得られた顧客には、何らかのインセンティブ（次回更新時の割引など）を提供する仕組みにすると、許諾率が上がります。
競合への参入障壁を作る3つの方法
「プロンプトなら自分でも書けるのでは」と感じるクライアントもいます。この潜在的な競合脅威に対して、参入障壁を作る3つの方法を共有します。
ひとつは、業界特化の知識資産を蓄積することです。汎用的なプロンプトは誰でも書けますが、特定業界の用語集・規制対応・過去事例を組み込んだ Gem は、その業界に深く入り込んだ人だけが作れます。これが最大の参入障壁になります。
ふたつは、品質保証体制とサポートを商品化することです。「Gem 単体」ではなく「Gem + 月次品質レポート + 改善提案 + 緊急サポート」のセットで売れば、自社で書く選択肢との差が明確になります。
みっつは、複数 Gem の連携・組み合わせを提供することです。「営業 Gem」「経理 Gem」「人事 Gem」など複数を組み合わせ、同じ業界用語と整合した出力ができる体系性は、単発で書いたプロンプトには出せない価値です。
全体を振り返って — 3ヶ月で最初の Gem 製品を売る
最後に、これから Gem 製品ビジネスを始める方への3ヶ月ロードマップを共有します。
1ヶ月目は、自分が深く知る業界・業務を1つ選び、最初の Gem 製品を設計します。本記事の7要素をすべて含む形で、品質保証付きの完全パッケージを作ります。
2ヶ月目は、知人や元クライアントの企業3社に、無料または超低価格（5万円程度）でβ版を提供し、フィードバックを集めます。同時に、ケーススタディの素材を蓄積します。
3ヶ月目は、フィードバックを反映した v1.0 を完成させ、最低価格を10万円以上に設定して正式販売を開始します。同時に、ケーススタディ1本を公開し、次の顧客獲得のための素材にします。
3ヶ月後にはあなたは「企業向けプロンプト製品を販売した実績のある個人開発者」というポジションを持つことになります。ここから、リカーリングモデルへの移行、業界別のパッケージ化、ライセンス契約への発展と、収益基盤を拡張していけます。今日が、その3ヶ月の起点です。
法務・契約面で必ず押さえること
プロンプト製品を企業向けに販売する場合、法務面で押さえるべき論点があります。私が必ず契約書に入れている条項を共有します。
第一に「出力結果の責任所在」です。AIが生成した出力に基づく業務判断の最終責任は顧客にあること、出力の正確性・完全性は保証しないことを明記します。これがないと、出力ミスによる損害賠償リスクを背負う可能性があります。
第二に「機密情報の扱い」です。顧客が Gem に入力する情報の機密性、その情報が Gemini API を通じて Google に送信される事実、Google の API 利用規約に従って処理されることを明示します。NDA を結ぶ場合も、API 経由の処理は除外する旨を記載します。
第三に「製品の改修と通知」です。Gem の更新タイミング、ブレイキングチェンジが発生した場合の通知方法、旧バージョンのサポート期間などを定めます。
第四に「料金改定の条件」です。Gemini API の料金変更があった場合に、製品料金を改定できる条件と通知期間を定めます。
これらは難しい法律用語で書く必要はなく、誰が読んでも分かる平易な日本語で書きます。むしろ、法律家にしか分からない契約書は、企業内での承認プロセスで時間がかかり、契約クローズが遅れます。
サブスク移行時の重要KPI
[A]単体販売から[C]サブスクへ移行する際、必ず追跡すべきKPIがあります。
第一が解約率（チャーンレート）です。月次解約率が5%を超えると、新規獲得を止めると半年で売上が半減します。3%以下を目標に運用します。
第二がARR成長率です。新規獲得 - 解約 - ダウンセル + アップセル = 純増。これが毎月プラスを維持していれば、長期的な収益基盤として機能します。
第三が顧客あたりのサポート工数です。サブスク顧客が増えるほど問い合わせも増えます。1顧客あたり月平均サポート工数を計測し、料金とサポートコストのバランスを見ます。
これらのKPIを毎月集計するダッシュボードを最初から用意しておくと、規模が拡大しても運営判断が遅れません。
バージョンを跨いで品質を数値化する回帰スコアリング
Gem 製品を実際に売り始めて、いちばん肝を冷やしたのは「良かれと思った修正が、別のところを静かに壊す」瞬間でした。ある顧客向けの Gem で、要約の精度を上げようとインストラクションを一段書き換えたところ、要約は良くなったのに、それまで安定していた文体の敬体が崩れて出るようになったのです。
先ほどのブール値の回帰テストは「キーワードが入っているか」しか見ていません。文体の劣化のような連続的な変化は素通りしてしまいます。そこで私自身は、各テストケースを 0〜100 点で採点し、バージョン間の差分を毎回記録する仕組みに切り替えました。
# Gem 品質を数値化してバージョン間で比較する（Python + Gemini API） import csv, datetime, statistics import google.generativeai as genai
genai.configure( api_key = "YOUR_API_KEY" )
# 採点の重み付け（合計 1.0 になるよう設計する） WEIGHTS = { "keyword" : 0.4 , "forbidden" : 0.3 , "tone" : 0.3 }
def score_case (instructions: str , case: dict ) -> float : model = genai.GenerativeModel( model_name = "gemini-3-2" , system_instruction = instructions ) out = model.generate_content(case[ "input" ]).text
# 1. 期待キーワードの網羅率（0〜1） hits = sum ( 1 for k in case[ "expected_keywords" ] if k in out) keyword = hits / max ( len (case[ "expected_keywords" ]), 1 )
# 2. 禁止ワードの不在（1件でも出れば 0） forbidden = 0.0 if any (f in out for f in case[ "forbidden_keywords" ]) else 1.0
# 3. 文体スコアは LLM-as-judge で 0〜1 に正規化 judge = genai.GenerativeModel( model_name = "gemini-3-2" ) verdict = judge.generate_content( f "次の文章が敬体で統一され、指定トーンに沿うかを0.0〜1.0で採点し数値のみ返答: \n{ out } " ).text.strip() try : tone = max ( 0.0 , min ( 1.0 , float (verdict))) except ValueError : tone = 0.0
return round ( 100 * ( WEIGHTS [ "keyword" ] * keyword + WEIGHTS [ "forbidden" ] * forbidden + WEIGHTS [ "tone" ] * tone), 1 )
def run_suite (version: str , instructions: str , cases: list ) -> float : scores = [score_case(instructions, c) for c in cases] overall = round (statistics.mean(scores), 1 ) # 履歴CSVに追記し、前バージョンとの差分を表示する with open ( "quality_history.csv" , "a" , newline = "" ) as fp: csv.writer(fp).writerow( [datetime.date.today().isoformat(), version, overall] ) print ( f "[ { version } ] overall= { overall } cases= { scores } " ) return overall このスコアリングに切り替えた効果は、数字で明確に出ました。文体を壊した「改善版」は、キーワード網羅率こそ 100% のままでしたが、トーンスコアが 0.61 まで落ち、総合点は 78 点から 61 点へ下がりました。ブール値のテストでは全件パスと表示されていた変更が、17 点の劣化として初めて可視化されたのです。
出荷判断は、総合点だけでなく次元ごとの下限で決めています。私が顧客に約束している基準はおおむね以下の通りです。
採点次元 重み 出荷下限 下回ったときの対応 キーワード網羅率 0.4 0.90 インストラクションに必須項目を明示追加 禁止ワード不在 0.3 1.00 1件でも出れば即差し戻し（例外なし） 文体トーン 0.3 0.80 Few-Shot 例を2件足して再採点
運用に落とすときの判断手順は、番号で固定しておくと迷いません。
新バージョンのインストラクションを用意したら、まず全テストケースを run_suite にかけて総合点を出します。
総合点が前バージョンを下回った場合は、次元別スコアを確認し、どの次元が落ちたかを特定します。
落ちた次元の出荷下限を割っていれば、その次元専用の修正（必須項目の明示、Few-Shot 追加）だけを当て、他の次元を触りません。
修正後に再採点し、総合点が前バージョン以上かつ全次元が下限を満たしたときのみ、顧客環境へ反映します。
顧客に「品質に責任を持つ」と言い切るためには、この「数字で退行を止める」仕組みが土台になります。テキストを主観で手直しし続ける運用では、いずれどこかで信頼を失うと私は考えています。
全体を振り返って - 3つの覚悟
最後に、これからGem製品ビジネスを始める方に持っておいてほしい3つの覚悟を書いて締めくくります。
ひとつめは、製品の品質に責任を持つ覚悟です。「テキストを売る」ではなく「業務改善ソリューションを売る」のですから、出力品質の継続的改善とサポートは必須です。最初の3社で関係を作る期間は、特に手厚く対応する覚悟が必要です。
ふたつめは、価格を妥協しない覚悟です。「最低10万円」のラインは、自分の労力と顧客が得る価値を踏まえて設定した妥当な数字です。ここを切り崩すと、ビジネスとして成り立たなくなります。安く売って数を追うのではなく、適正価格で深く売る覚悟を持ちます。
みっつめは、業界に深く入り込む覚悟です。汎用的に売ろうとせず、特定業界に深く根を張ることで、競合との差別化と高単価が両立します。3年は1業界に集中する覚悟があると、長期的な収益基盤が築けます。
これら3つを持って動き出せば、Gem 製品ビジネスは個人開発者にとって極めて魅力的な収益源になります。Gemini Gems という機能の成熟は、この機会を技術的に裏付けてくれています。今日からの3ヶ月、ぜひ最初の一歩を踏み出してみてください。