0. はじめに
ELYZAと株式会社マイナビが共同開発した「マイナビAI Pencil」が公開されました。本記事ではこの開発過程において重要な役割を果たした「Prompt Engineering」と、それを支える体系的な運用基盤「PromptOps」について解説します。
「マイナビAI Pencil」については、当社リリースならびにマイナビリリースをご覧ください。
- 株式会社ELYZA プレスリリース：https://prtimes.jp/main/html/rd/p/000000062.000047565.html
- 株式会社マイナビ様 プレスリリース：https://www.mynavi.jp/news/2025/07/post_49493.html
なお、本ブログに関する研究開発は、プロジェクトに関わった ML（機械学習）エンジニアの曽我部 (@sog4be)、堤 (@ozro_223)らで取り組み、曽我部が代表して執筆しました。
1. LLM 社会実装の「理想」と「現実」
最新の LLM は驚くほど賢く、簡単な指示でもある程度のタスクをこなしてしまいます。その性能の高さゆえに「プロンプトの作り込みは、もはや些末な問題だ」という考え方が生まれるのも無理はないと言えます。
しかし、LLM の出力を本番運用に耐える品質に昇華させるためには、細部にこだわった泥臭い試行錯誤が必要です。
「なんだか出力が微妙だな…」
「期待通りの答えが、安定して返ってこない…」
LLM を業務へ組み込もうと試行錯誤されている方であれば、一度はこの"壁"に突き当たった経験があるのではないでしょうか。
プロトタイプとして「動く」ことと、本番環境で「ビジネス価値を生み続ける」ことの間には天と地ほどの隔たりがあります。その溝を埋めるのが、数%の精度改善のために 100 以上のバージョンを生み出すような、妥協のないプロンプトエンジニアリングであり、それを支えるチームの仕組みです。
ELYZA のソリューション事業部では、自社開発モデルの利用にこだわらず、お客様の課題や要件に応じて OpenAI 社の GPT シリーズ、Google 社の Gemini、Anthropic 社の Claude など、あらゆる選択肢の中から最適なモデルを組み合わせてソリューションを構築しています。
ここからは、私たちがいかにして「微妙」な出力を「理想」の出力へと磨き上げているのか、その地道な試行錯誤のプロセスである「Prompt Engineering」やそれをチームの力で支える仕組みである「PromptOps」について、具体事例を交えてご紹介します。
2. 「なんだか微妙」を解き明かす、Prompt Engineering
LLM を実際のビジネス現場で活用しようとするとき、誰もが直面するのが「なんだか微妙」という漠然とした課題です。「もう少し自然な表現にしてほしい」「なんとなく違和感がある」といった曖昧な要求は、エンジニアやプロジェクトメンバーを大いに悩ませます。
私たちが考える Prompt Engineering の本質は、まさにこの曖昧さを具体的な指示に変えるプロセスにあります。
例えば、お客様から「この文章が微妙です」とフィードバックをいただいた際には、それを徹底的に言語化し分析します。単に「自然な表現」という抽象的な言葉で終わらせるのではなく、「この文章は『〜しました』という表現が 5 回連続しており、リズムが単調で稚拙な印象を与えています」と具体的に課題を特定します。
そこまで具体的に掘り下げる理由は、ここで曖昧さを残してしまっては、改善プロセスが運任せになり、再現性がないからです。例えば次のように、プロンプトに明確な指示を加えます。
同一の文末表現（用言の活用種類＋付属語、体言止め）が連続するのは2回までとし、次は別の表現を使用してください。
実際、転職活動中のユーザーの自己 PR 文章を生成する例を考えてみましょう。この場面では、曖昧で微妙な文章は許されません。なぜなら、自己 PR の文章が相手企業に与える第一印象を決定づけ、採用結果を左右するからです。
この自己 PR 文章生成タスクでは、約 100 パターンものプロンプトを作成し、試行錯誤を重ねました。100 パターンも試すのは非効率に聞こえるかもしれませんが、この妥協のない地道な作業が、最終的な出力品質を決定づけることを私たちは経験から何度も学んでいます。
たった一つのプロンプトでも、表現の仕方、指示の粒度、細かな言葉選び一つで出力は劇的に変わります。私たちが追求する Prompt Engineering は、単なる「指示書の書き方」ではなく、「ビジネス要件に応じた言語化の技術」であり、高品質な出力を保証し、「確かなビジネス価値」をつくるために欠かせない工程だと言えます。
3. 属人化を防ぎ、改善を加速させる仕組みの中核「PromptOps」
前章でご紹介したような、細部にまでこだわる Prompt Engineering は、LLM の出力を本番運用に耐える品質に引き上げる上で不可欠です。しかし、この職人芸ともいえるスキルが、特定の個人の経験や勘だけに依存してしまうと、そこには大きなリスクが潜んでいます。
「このプロンプトの意図は、A さんにしか分からない」
「B さんが作ったプロンプトは、誰も怖くて触れない」
このような状況は、俗に「属人化」と呼ばれます。担当者がいなければ改善が止まってしまい、せっかく蓄積したノウハウが組織の力になりません。また、LLM は日々進化し、お客様からの要求も変化し続けます。一度完成したら終わり、ということはあり得ないのです。
そこで重要になるのが、個人の「職人芸」をチームの「仕組み」へと昇華させ、継続的な改善を可能にする運用基盤、すなわち「PromptOps」です。
なぜ PromptOps が必要なのか？
優れたプロンプトは、一度作って終わりではありません。むしろ、そこがスタートラインです。
市場の変化、新しい LLM の登場、お客様からの新たなご要望。これらに迅速かつ的確に対応し続けるためには、プロンプトを体系的に管理し、チーム全員で改善していくための仕組みが不可欠になります。PromptOps は、この継続的な改善活動の心臓部ともいえる存在です。
私たちの取り組み
私たちは、PromptOps を単なるツール導入やルール作り活動ではなく、最高の品質を追求する「文化」そのものだと考えています。ここでは、私たちの取り組みの根幹をなす 3 つの要素をご紹介します。
① エンジニアに閉じない「開かれたプロンプト改善」
プロンプト改善はエンジニアだけの仕事ではありません。
LLM の出力品質は、技術的な正しさだけで決まるものではないからです。お客様の業務プロセスや、業界特有の言い回し、さらには企業文化といった、言語化されにくいニュアンスを汲み取ることが極めて重要になります。
そのため ELYZA のソリューション事業部では、ML エンジニアだけでなく、顧客課題を深く理解するプロジェクトマネージャーや、業界のドメイン知識を持つビジネスサイドのメンバーが一体となってプロンプトをレビューし、改善案を出し合っています。
プロンプトや実験結果、改善の経緯を Notion に集約することで、職種や役割に関係なく同じ情報をリアルタイムに把握し、共同でプロンプトを改善する文化が醸成されていきました。
② バージョン管理：変更の意図を未来へつなぐ
プロンプトは、日々の改善活動の中で少しずつ形を変えていきます。しかし、「いつ、誰が、なぜ」その変更を加えたのかが分からなくなると、改善の方向性がブレたり、過去の優れたバージョンが失われたりする原因になります。
そこで私たちは、ソフトウェア開発で広く使われているSemVer（セマンティックバージョニング）の考え方に倣い、プロンプトのためのバージョン管理ルールを策定しました。
また、新しいバージョンのプロンプトを作成する際には Git のコミットメッセージのように、
- 何を狙って
- 何を変えて
- どうだった
を端的に記載するようにしています。
実際にプロンプトを管理している Notion ページの抜粋
この取り組みにより、すべての変更に意図と履歴が記録されるため、チームメンバーは安心して改善作業に集中できます。変更の影響範囲も明確になり、チームでの開発が格段にスムーズになりました。
③ 客観的データに基づく実験管理と高速な改善サイクル
最高のプロンプトを見つけ出すためには、勘や経験だけに頼るのではなく、客観的なデータに基づいた評価が欠かせません。
私たちは、使用モデルとプロンプトバージョンの組み合わせごとの出力結果を、すべて Google のスプレッドシートで一元管理しています。特定のモデルに固執しないことは ELYZA の強みの一つです。お客様の課題に応じて、Claude、GPT、Gemini から自社開発モデルまで、複数の選択肢の中から最適なものを客観的なデータに基づいて選定し、ご提案します。スプレッドシートを見れば、どのモデルとプロンプトの組み合わせが最も高い性能を示したか、一目瞭然です。
さらに、以下の 3 つのステップからなる改善プロセスを高速に回しています。
- クイック改善 (Notion 上): 日々発生する「この表現を少し変えてみては？」といった細かな改善アイデアを、まずは 10 件程度の少量の評価データセットでスピーディに試します。
-
定性・定量評価 (スクリプト実行): クイック改善で有望だった候補を、100〜300 件のより大きなデータセットで評価します。ここでは、LLM 自身に出力を評価させる
LLM-as-a-Judgeといった手法も活用し、性能を客観的なスコアとして算出。結果はランキングボードで可視化します。 - 顧客レビュー (評価シート): 技術的な評価でトップに立った候補が、必ずしもお客様にとっての正解とは限りません。最終的には、お客様に実際の出力をご確認いただき、「現場の感覚としてはこちらの表現の方が自然で分かりやすい」といった貴重なフィードバックをいただきます。この現場のリアルな声こそが、次なる改善の出発点となります。
4. 仕組み化がもたらした成果と、次なる挑戦
Prompt Engineering を「属人的な職人芸」から「組織の仕組み」として体系化したことで、多くの具体的な成果を得ることができました。
成果 ①：混沌からの脱却と資産化
PromptOps を導入する前は、「最新のプロンプトはどれか」「この指示の意図は何か」といった質問に対して、明確な回答が難しい状況が頻繁にありました。過去のプロジェクトを振り返るたびに、「記憶と勘」を頼りにしてしまうため、改善の方向性が曖昧になり、同じミスや議論を繰り返してしまうこともありました。
PromptOps の体系化以降は、すべてのプロンプトが明確にバージョン管理され、変更履歴やその意図が記録されるようになりました。その結果、チームメンバーは常に最新のバージョンを迅速に参照できるようになり、過去の試行錯誤の蓄積を簡単に活用できる「資産」としてプロンプトが活用されるようになりました。
成果 ②：職種を超えたチーム開発の実現
技術的な視点に限らずビジネスサイドの視点が積極的に取り入れられるようになりました。例えば、ビジネスサイドから「この表現は誤解や消費者クレームにつながる可能性がある」という指摘が Slack や Notion 上で気軽に行われるようになり、技術的正しさに加え「ビジネスとしての正しさ」を追求する文化が定着しました。
今後の展望と次なる挑戦
PromptOps の仕組みを構築し、プロンプトをチームの資産として管理できるようになりましたが、私たちの挑戦はまだ道半ばです。現状の Notion とスプレッドシートをベースとした運用は、職種を問わず誰でも参加できるという大きなメリットがある一方で、実験規模の拡大に伴い、特に定量評価の管理における手作業の多さが課題となっています。
この課題を解決し、改善サイクルをさらに加速させるため、私たちは二つの方向から検討を進めています。
一つは、これまで培ってきた Notion 中心の文化を活かした内製ツールの深化です。Google Apps Script（GAS）や Notion SDK を活用し、実験結果の記録やランキングボードへの反映を自動化することで、ヒューマンエラーを減らし、より正確で迅速なプロンプトの改善が可能になると考えています。
そしてもう一つが、LLM 開発に特化した最先端の外部ツールの積極的な活用です。近年ではプロンプトのバージョン管理、評価セットの管理、A/B テスト、人間によるフィードバック収集までを包括的にサポートする PromptLayer のようなマネージドサービスや、オープンソースの評価基盤である agenta といったツールが急速に進化しています。
これらを組み合わせて、内製の仕組みが持つ柔軟性と、外部ツールが持つ堅牢性や効率性を両立させた、ハイブリッドな開発基盤づくりを目指していきます。
5. PromptOps 実践 Tips
ここまで概念的なお話が続いたので、この章では、明日からでも試していただける TIPS を 2 つご紹介します。
Tips 1: プロンプトにもバージョン管理を！ SemVer の効果的な使い方
前章で、プロンプトのバージョン管理が重要だとお話ししましたが、「具体的にどんなルールで番号を付ければ良いの？」と疑問に思われた方もいらっしゃるかもしれません。
私たちのチームでは、ソフトウェア開発の世界では広く使われているSemVer（セマンティック バージョニング）を、プロンプトの管理に応用しています。これは、v1.2.3 のようなバージョン番号の付け方に、明確な意味を持たせるためのシンプルなルールです。
このルールを導入することにより、コード内で下記のような条件分岐を作り、前後処理を切り替えるなどのロジックを実装しやすくなります。
if prompt_version.major == '1':
...
else:
...
具体的には、私たちのチームでは以下のような基準でバージョン番号を更新しています。
- MAJOR (v1.0.0 → v2.0.0)
プロンプトに渡す情報（入力データ）の形式や、出力後の処理（後処理）の仕様が変わるなど、過去のバージョンと互換性がなくなる大きな変更があった場合に更新します。例えば、自己 PR 生成タスクで、入力情報として{{ strength }}（強み）だけでなく新たに{{ career_goal }}（将来の目標）を追加する場合などがこれにあたります。この変更に追従しないとシステムが正しく動作しなくなる、という重要なサインになります。 - MINOR (v1.2.0 → v1.3.0)
出力の品質を上げるために、指示の追加や削除など、互換性を保ちながら機能的な改善を行った場合に更新します。「文字数を 400 字から 600 字に変更する」「より丁寧な言葉遣いを心がけるように、という指示を追加する」といったケースが該当します。 - PATCH (v1.2.3 → v1.2.4)
機能的な変更はないものの、誤字の修正や、文章のリズムを整えるための細かな表現（てにをは）の調整など、ごくわずかな改良を加えた場合に更新します。
とはいえ、プロジェクトの初期段階では、プロンプトの骨格が固まらず、仕様変更が頻繁に起こりがちです。そのため、バージョンが v0. で始まる間は、こうしたルールに過度に縛られることなく、チームで合意しながら大胆な変更をどんどん試していくのが効率的だと私たちは考えています。
このように一貫したルールを設けることで、プロンプトという無形のノウハウが、誰にとっても理解しやすく、扱いやすい「資産」へと変わっていきます。
Tips 2: .tomlでプロンプト管理すると幸せになれる理由
Notion やスプレッドシート上での実験を経て、いざ完成したプロンプトをシステムに組み込むフェーズになると、多くの開発者が「どのファイル形式でプロンプトを保存するか？」という、ささやかですが悩ましい問題に直面します。
よく使われる設定ファイルの形式にはJSONやYAMLなどがありますが、私たちのチームではTOMLという形式を愛用しています。その理由は、プロンプトという「長文のテキスト」を扱う上で、TOML が持つ特徴が非常に優れているからです。
- 複数行の文章が、見たまま書ける
プロンプトはどうしても長文になりがちです。JSON で長い文章を書こうとすると、改行のたびに特殊な文字（\n）を入れる必要があり、読みにくさの原因になります。TOML は、'''（3 つのシングルクォーテーション）で囲むだけで、改行やインデントを含んだ複数行の文章を、見たまま直感的に記述できます。 - インデント（字下げ）のエラーに悩まされにくい
YAML も複数行の記述に強い人気の形式ですが、インデントのわずかなズレがエラーの原因になることがあり、慣れないうちは思わぬトラブルに時間を取られてしまうことも。TOML はインデントのルールがより緩やかで、こうしたストレスが少ないのが嬉しいポイントです。
百聞は一見に如かず。自己 PR 文章の生成を例にしたプロンプトファイル（の一部）をご覧ください。
# プロンプトのバージョンや設定を記述
version = "v0.1.0"
engine = "jinja2" # 変数を埋め込むためのテンプレートエンジンを指定
[engine_options]
undefined = "debug"
# ここから下が、LLMに渡す実際の指示
# OpenAIのAPIなどで使われる形式に合わせています
[[messages]]
role = "system"
content = '''
あなたは、キャリアコンサルタントのプロフェッショナルです。
ユーザーが入力した情報に基づき、採用担当者の心に響く、論理的で魅力的な自己PR文章を作成してください。
'''
[[messages]]
role = "user"
content = '''
以下のルールを厳守して、自己PR文章を生成してください。
# ルール
- 全体で400字程度にまとめること。
- 同一の文末表現（「〜しました」など）が3回以上連続しないように、多様な表現を用いること。
- ユーザーが提供する「強み」と「具体的なエピソード」を必ず含めること。
# ユーザー情報
- 強み: {{ strength }}
- 具体的なエピソード: {{ episode }}
'''
プロンプトの役割（system / user）、バージョン情報、そして実際の指示内容が、とてもスッキリとまとまっているのがお分かりいただけるかと思います。{{ strength }}のような部分は、テンプレートエンジンという仕組みを使って、実行時に実際のユーザー情報に置き換えられます。
もしプロンプトの管理方法で迷うことがあれば、ぜひ一度.tomlを試してみてはいかがでしょうか。
6. おわりに
私たちの根底には、常にお客様のビジネス成果に貢献したいという強い想いがあります。本記事では、その想いから生まれた「Prompt Engineering」、「PromptOps」、「開かれた開発文化」について紹介しました。
ELYZA は『未踏の領域で、あたりまえを創る』というミッションのもと、これからも LLM を活用した社会課題解決の最前線を走り続けていきます。
そのために、機械学習エンジニアやソフトウェアエンジニアなど、様々な職種で一緒に事業を前に進めてくれる仲間を募集しています。記事内容に共感いただけた方は、ぜひ下記をご覧ください。
Discussion