プロンプトの指示が「剥がれる」瞬間、あなたも経験ありませんか？

システムプロンプトに「あなたは気さくなアドバイザーです」と記述してチャットボットのプロトタイプをリリースしたとしましょう。最初の数ターンは完璧に動いても、会話が長引いたり複雑な質問が投げかけられたりすると、AIが急に冷たい「ロボット」に戻ってしまう。そんな「指示の剥がれ」に直面したことはありませんか？

これは、プロンプトエンジニアリングだけに依存したプロジェクトで頻発する課題です。

プロンプトは言わば「化粧」であり、ファインチューニングは「骨格整形」です。化粧は状況の変化で落ちてしまいますが、骨格そのものを変えれば、どんな場面でもその「顔」は揺るぎません。AIにおける骨格とは、モデルの重み（パラメータ）そのものです。

今回は、AIエージェントに確固たる「人格（スタイル）」を宿らせるためのスタイル・ファインチューニングについて、成功の鍵を握る「データセット構築」の観点から深掘りしていきます。まずは動くものを作り、仮説を検証する。そのための強固な土台となるデータエンジニアリングの世界へご案内しましょう。

なぜプロンプトだけでは「人格」が崩れるのか：データ処理の目的

技術的な観点から言えば、プロンプトだけで人格を維持し続けるのが難しい理由は、LLM（大規模言語モデル）のアーキテクチャそのものに起因しています。どれほど優れたプロンプトエンジニアリングを施しても、モデルの根本的な挙動や「地」の性格を完全に上書きすることはできません。

コンテキスト長と指示の希釈化問題

LLMは、入力されたトークン列（プロンプト＋会話履歴）全体に対して注意機構（Self-Attention）を働かせ、次のトークンを予測します。システムプロンプトは通常、会話の冒頭に配置されますが、会話履歴が長くなるにつれ、その「初期指示」へのAttentionスコアが相対的に低下する傾向があります。

GeminiやClaudeなどの最新モデルでは数百万トークンという膨大なコンテキストウィンドウを扱えるようになりました。しかし、コンテキストが長くなればなるほど、特定の指示（ここでは人格設定）が情報の海に埋もれやすくなる「Lost in the Middle」現象のリスクは依然として残ります。

特に、ユーザーからの入力に強い感情が含まれていたり、複雑な論理的推論を求められたりすると、モデルは事前学習（Pre-training）で獲得した「最も一般的で無難な回答パターン」——つまり、あの丁寧すぎる「AI口調」——に引っ張られてしまいます。これを防ぐために毎回詳細な人格定義やルールセットを再挿入すれば、今度はトークンコストが跳ね上がり、応答速度（レイテンシ）も実用レベルを超えて悪化してしまいます。ビジネスの現場では、このコストとパフォーマンスのトレードオフが致命傷になりかねません。

Few-shotプロンプティング vs ファインチューニングの適用境界

「Few-shot（いくつか例示を与える手法）で解決できるのでは？」という議論も尽きません。確かに、構造化されたプロンプト内に3〜5個の対話例を含めたり、思考の連鎖（Chain of Thought）を組み合わせたりすることで、ある程度のスタイル模倣は可能です。プロトタイプを素早く作る段階では、このアプローチが有効に機能します。

しかし、本格的な業務システムで求められる「人格」とは、単なる語尾の統一ではありません。以下のような微細なニュアンスの制御が求められます。

• 断定の強さ（自信満々に言い切るか、リスクを考慮して慎重に提案するか）
• 情報の粒度（結論から端的に箇条書きするか、背景から物語として語るか）
• 共感の示し方（オウム返しで傾聴するか、別の視点でプロフェッショナルとして切り返すか）

これらを含めた包括的な「ブランドボイス」をFew-shotだけで表現しようとすれば、プロンプトは肥大化し続け、毎回のリクエストで膨大な入力トークンを消費することになります。一方、ファインチューニングを行えば、これらのスタイルをモデルの内部パラメータ（重み）として固定化できます。推論時には短い指示だけで、あるいは指示なしでも、自然とその人格として振る舞うようになるのです。

スタイル（文体）とナレッジ（知識）の分離思考

ここで最も重要なのが、システム設計として「何を話すか（Knowledge）」と「どう話すか（Style）」を明確に分けて考えることです。

多くの開発現場で、業界知識も口調も一度にモデルへ学習させようとして失敗するケースが見受けられます。しかし、専門的な視点から言えば、最も効果的で持続可能なのは「スタイル特化のファインチューニング」です。

知識部分は、モデルの内部パラメータに焼き付けるのではなく、RAG（Retrieval-Augmented Generation） で外部から動的に取得します。この分野の進化は著しく、現在は以下のような高度な手法が実用段階に入っています。

• GraphRAG: ナレッジグラフを活用し、単語の類似性だけでなく概念的な関係性から情報を探索する手法。
• Agentic RAG（エージェント型RAG）: AIが自律的にクエリを分解・計画し、複数の情報源を横断して回答を生成する手法。
• マルチモーダルRAG: テキストだけでなく、画像や図表、UIの文脈まで統合して検索・参照する手法。

このように高度化した検索システムから得られた「正確な情報」を、ファインチューニングされたモデルに入力し、「自社らしい口調」に変換して出力させる。この役割分担こそが、幻覚（ハルシネーション）を抑えつつ、一貫した魅力的なAIエージェントを構築する最適解であると考えられます。

スタイル学習のための「ゴールデンデータ」要件定義

では、具体的にどのようなデータを学習させればよいのでしょうか。ここで多くのプロジェクトが陥りやすい罠があります。それは、「Q&Aデータセット」を作ってしまうことです。

Q&A形式ではなく会話形式の重要性

スタイルを学習させるためのデータ（Instruction Tuningデータ）において、単純な「質問→回答」のペアだけでは不十分です。なぜなら、人格は「対話の流れ」の中に現れるからです。

例えば、ユーザーが不満を言ったとき、単に正解を返すのがQ&Aですが、まず謝罪し、共感を示し、その上で解決策を提示するのが「優れたサポート担当者」という人格です。学習データには、こうしたマルチターン（複数回のやり取り）の構造を含める必要があります。

「人格」を表す特徴量の特定

データセットを設計する際、まず以下の「スタイル特徴量」を定義します。

1. Sentence Length（文長）: 短く簡潔に話すか、詳しく丁寧に話すか。
2. Vocabulary Level（語彙レベル）: 専門用語を多用するか、中学生でもわかる言葉を選ぶか。
3. Empathy Markers（共感マーカー）: 「それは大変でしたね」「おっしゃる通りです」といったクッション言葉の使用頻度。
4. Tone（語尾・トーン）: 「〜です/ます」か、「〜だね/だよ」か。

これらが統一されていないデータで学習すると、モデルは混乱し、結局元の「平均的なAI」に戻ってしまいます。これを防ぐために作成するのが「ゴールデンデータ」です。

理想的な対話ペアの構造例

以下は、同じ意図（Instruction）に対して、異なるスタイルで作成された学習データの比較です。

要素	一般的なAIの回答（NG例）	スタイル適用後のゴールデンデータ（OK例）
ユーザー入力	「ログインできないんだけど、どうなってるの？」	「ログインできないんだけど、どうなってるの？」
スタイル定義	中立・丁寧・客観的	親身・迅速・解決志向（カスタマーサクセス）
回答出力	「ログインできない状況とのこと、承知いたしました。以下の手順をお試しください。1. パスワードの再設定...」	「ご不便をおかけしており申し訳ございません！ログインできない状況ですね、すぐに解決しましょう。まずは一番多い原因であるパスワードの再設定からご案内してもよろしいでしょうか？」
特徴	事務的で冷たい。手順を羅列するだけ。	感情への寄り添い（!の使用）、能動的な提案、許可取りが含まれている。

このように、単なる情報の正しさだけでなく、「感情的な正解」を含んだデータを数千件規模で用意することが、スタイル・ファインチューニングの重要な要素となります。

ソースデータの収集戦略：既存資産と合成データの活用

「そんな高品質なデータ、数千件も手動で作れない」と思われるかもしれません。現代のAI開発において、全てのデータを人間がゼロから書くことは稀です。ここでは、既存資産の活用と、AIによるデータ生成（Synthetic Data Generation）の戦略を紹介します。スピーディーに仮説検証を回すためにも、これらの手法は欠かせません。

社内チャットログ・メール履歴の匿名化と抽出

組織内に理想的な対応をしている担当者がいる場合、その過去のメールやチャットログは貴重な情報源となります。これらは「生のスタイル」を含んでいるからです。

ただし、そのまま学習させるのは危険です。個人情報（PII）が含まれているだけでなく、文法的な誤りや、文脈が不明瞭なやり取りも含まれているからです。ここで必要なのが、厳格なフィルタリングです。

1. PII除去: ツールを使って名前、電話番号、アドレスをマスキング。
2. 高品質フィルタリング: 顧客からの評価が高かった対応のみを抽出。
3. コンテキスト補完: 「例の件」といった指示語を、具体的な内容に書き換える。

既存FAQからの「スタイル変換」によるデータ増強

より現実的でスケーラブルなのが、既存のFAQやマニュアルをベースに、LLMを使って「スタイル変換（Style Transfer）」を行う手法です。これは「データ錬成（Data Alchemy）」とも呼ばれます。

例えば、高性能なモデルに、先ほど定義した「ペルソナ」と「数件のゴールデンデータ（Few-shot）」を与え、既存のFAQを書き換えさせます。

プロンプトのイメージ:

あなたは「熟練のエンジニア兼メンター」です。以下の無機質な技術解説を、後輩を励ましながら教えるような口調に書き換えてください。技術的な正確さは維持しつつ、比喩表現を1つ以上含めること。
[入力テキスト]: ...

このプロセスを通すことで、元となる事実（ナレッジ）はそのままに、表現（スタイル）だけをターゲットペルソナに合わせたデータセットを大量に生成できます。これが、コストを抑えつつ高品質なInstruction Tuningデータを作る実践的なアプローチです。

データクレンジングとスタイル正規化プロセス

集めた（あるいは生成した）データは、そのままではまだ「原石」です。研磨が必要です。特にスタイルを固定する場合、わずかなノイズが影響を与える可能性があります。

ノイズ除去：挨拶、定型文、フィラーの取捨選択

通常のデータクレンジングでは、「あー」「えっと」といったフィラーや、「お世話になっております」といった定型的な挨拶は削除対象です。しかし、スタイル・ファインチューニングの場合は判断が分かれます。

もし「人間味のある、少しくだけたAI」を作りたいなら、あえてフィラーを残すことも戦略の一つです。逆に、プロフェッショナルなAIを目指すなら、これらは徹底的に削除しなければなりません。

一般的に推奨されるのは、正規表現による一括置換ではなく、LLMを用いたセマンティックなクリーニングです。「意味を変えずに、口調だけを統一する」というタスクは、ルールベースのプログラムよりもLLMの方が得意だからです。

「知らないこと」への回答スタイルの制御

見落とされがちなのが、拒絶応答（Refusal）のスタイル統一です。モデルが答えられない質問をされたとき、「私はAIなのでわかりません」と答えてしまうと、せっかく作り込んだ世界観が損なわれる可能性があります。

学習データには、あえて「答えられない質問」を含め、それに対する「ペルソナを保った断り方」を学習させる必要があります。

• NG: 「申し訳ありませんが、その質問には答えられません。」
• OK（熱血コーチ風）: 「うーん、すまない！その分野は私の専門外だ。でも、一緒に調べることはできるかもしれないぞ！」

このように、ネガティブなケースも含めてスタイルを定義・データ化することが、ペルソナ構築には不可欠です。

学習用フォーマットへの変換とパイプライン設計

クレンジング済みのデータが整ったら、実際にモデルがトレーニング可能な形式（主にJSONL）へ変換します。ここでは、業界標準となりつつあるOpenAIのChat形式や、Hugging Faceのエコシステムで採用されているフォーマットを例に挙げます。

JSONL形式への構造化（System, User, Assistant）

多くのファインチューニングAPIや最新のオープンソースモデルの学習では、以下のようなメッセージリスト形式が要求されます。

{
  "messages": [
    {"role": "system", "content": "あなたは親切なカスタマーサポートです。"},
    {"role": "user", "content": "返品したいのですが。"},
    {"role": "assistant", "content": "ご購入ありがとうございます。返品についてですね、ご不便をおかけし申し訳ございません。商品到着から何日経過していますでしょうか？"}
  ]
}

ここでシステム設計者として意識すべき重要なテクニックがあります。それはSystemプロンプトをデータセットに含めるかどうかの戦略です。

特定のペルソナや口調をモデルの「素の振る舞い」として固定したい場合、学習データの全サンプルに一貫したSystemプロンプトを含めることを強く推奨します。これにより、モデルは「このSystem指示（入力）に対して、この口調（Assistantの出力）で応答する」というパターンを強固に学習します。

また、Hugging FaceのTransformersライブラリ等を使用する場合は、モデルごとに異なる特殊トークン（<|user|>, [INST]など）を自動処理する「Chat Templates」機能の活用が必須です。手動でタグを埋め込むのではなく、トークナイザーの機能を使って動的にフォーマットすることで、モデルのバージョンアップや切り替えに強いデータセットになります。

再現可能なデータパイプラインの構築

データの作成は一度きりのイベントではありません。運用開始後、ユーザーからのフィードバックやエッジケース（予期せぬ入力）を受けて、モデルは継続的に再学習（Retraining）されるべきです。手作業での管理から脱却し、コードベースのパイプラインを構築しましょう。

1. Raw Data Store: 生データ（ログ、FAQ、チャット履歴など）の保存場所
2. Processing Script: クレンジング、個人情報マスキング、フォーマット変換を行うPythonスクリプト
3. Validation: データ形式の整合性チェック、トークン数計算、重複排除
4. Training Data: バージョン管理された学習用データセット

このフローを自動化することで、モデルの改善サイクルを高速に回すことが可能になります。これはDevOpsの概念をAI開発に適用したLLMOps（Large Language Model Operations）の基本であり、品質を担保する生命線です。

スタイルの定着度を測る品質評価メトリクス

最後に、学習させたモデルが本当に意図したペルソナを獲得できたのか、どうやって評価すればよいのでしょうか。従来のNLP指標であるBLEUやROUGEスコアは、ここではほとんど役に立ちません。これらは「正解文との単語の一致率」を見るものであり、「スタイルのニュアンス」は測れないからです。

LLM-as-a-Judgeによる自動評価

現在、最も有効なアプローチの一つが、LLM-as-a-Judge（審査員としてのLLM）です。高性能なモデルに、ファインチューニング済みモデルの出力を評価させます。

評価プロンプトの例:

あなたは対話品質の審査員です。以下の[モデルの回答]が、[定義されたペルソナ]にどれだけ合致しているかを1〜5点で評価し、その理由を述べてください。

評価基準:

1. 語尾は「〜だね」になっているか？
2. 共感的な言葉が含まれているか？
3. 専門用語を噛み砕いているか？

このように、定量的なスコアと定性的なフィードバックを自動生成させることで、大量のテストケースを効率的に評価できます。プロトタイプを素早く検証する上でも、この自動評価の仕組みは非常に強力です。

過学習（Overfitting）による柔軟性喪失の検知

スタイルを学習させすぎると、モデルが柔軟性を失い、どんな質問にも同じようなフレーズでしか返せなくなる「過学習」が起こることがあります。これを防ぐため、評価セットには「スタイル学習に使ったデータとは全く異なるトピックの質問」を含めておくことが重要です。未知の話題に対しても、スタイルだけを適用して適切に回答できるか。それが真の「人格獲得」の証です。

---

データエンジニアリングこそがAI人格の魂を作る

プロンプトエンジニアリングは手軽で強力ですが、ビジネスの現場で求められる「揺るぎないブランド体験」を提供するには、ファインチューニングによる根本的な人格形成が不可欠です。そして、その成否を分けるのは、モデルのアーキテクチャではなく、用意するデータの質と構造です。

「無機質なデータを、いかにして血の通った対話データに変えるか」

このプロセスこそが、これからのAI開発において求められる創造性であり、ビジネスにおける競争優位の源泉となります。まずは手を動かし、小さなデータセットからプロトタイプを作って検証を始めてみてください。その一歩が、確固たるAIエージェント構築への最短距離となるはずです。