企業のDX推進の現場では、最近よく次のような課題が聞かれます。
「RAG（検索拡張生成）を導入して社内マニュアルは全部読ませたはずなのに、AIが全然言うことを聞いてくれないんです」
実際の導入現場の状況を分析すると、知識自体は間違っていないものの、「回答は必ずJSON形式で」「語尾は『〜であります』に統一」「競合他社の製品名は出さない」といった出力形式やルールの制約が見事に無視されているケースが多発しています。
プロンプトで「絶対にこのルールを守ってください」と何度念押ししても、一定の確率でルールを破ってしまう。これでは、業務フローの中に組み込んで自動化することは困難です。
実は、この「知識はあるのにルールが守れない」という現象は、RAGやプロンプトエンジニアリングのアプローチだけでは解決が難しい、構造的な問題をはらんでいます。
今回は、なぜAIは指示を無視するのか、そのメカニズムを論理的に紐解きながら、解決策となる「制約条件付きインストラクション・チューニング」について解説します。これは、単にAIに知識を詰め込むのではなく、AIに「組織の一員としての振る舞い」を学習させるための実践的なアプローチです。
なぜ「ドメイン特化」したはずのAIが現場で使われないのか
多くの企業が「ドメイン特化型LLM」を作ろうとして、まずは手軽なRAG（検索拡張生成）から始めます。社内Wikiや技術文書をベクトルデータベースに入れ、関連情報をプロンプトに差し込んで回答させる。この仕組み自体は、知識を補完する手段として非常に有効です。
しかし、実際のPoC（概念実証）の段階になると、次のような課題が浮き彫りになります。
「回答の内容は合ってるけど、口調が偉そうで客先に出せない」
「箇条書きでまとめてと言ったのに、長文で返してきた」
「『不明な場合は回答しない』というルールなのに、もっともらしい嘘をついた」
「知識」は足りているのに「形式」が守れないジレンマ
ここで重要なのは、AIが「何を知っているか（Knowledge）」と「どう振る舞うか（Behavior）」は、全く別の能力だということです。
RAGはあくまで「カンニングペーパー」を渡す技術です。試験中に教科書を見ても良いと言われれば、知識の問題は解けるでしょう。しかし、「回答は青色のペンで、枠内に、3行以内で書きなさい」という形式的な制約（振る舞いのルール）を守れるかどうかは、教科書を持っているかどうかとは関係ありません。
ChatGPTやClaudeの最新モデルといった汎用LLMは、確かに賢いのですが、あくまで「一般的で平均的な優秀さ」を持つように調整されています。特定の業界や企業独自の「偏ったルール」や「厳格なフォーマット」を強制するには、外部から知識を与えるだけでは不十分なのです。
RAGやプロンプトだけでは解決できない「振る舞い」の壁
「プロンプトに『以下の制約を守れ』と強く書けばいいではないか」と考える方もいるでしょう。最近では、ClaudeのProjects機能やChatGPTのCustom Instructionsのように、前提条件や振る舞いを事前に設定できる機能も充実してきました。
しかし、RAGによって参照ドキュメントが大量にプロンプトに挿入されると、「指示の希釈化」という現象が起こります。数万トークンにも及ぶ社内ドキュメントの中に、本来の指示である「制約条件」が埋もれてしまうのです。
人間でもそうですが、「この大量の資料を読んでおいて」と渡されると、内容を理解することに精一杯で、「読み終わったら所定のフォーマットで報告する」という手順がおろそかになりがちです。LLMも同様に、入力コンテキストが増えれば増えるほど、細かい指示への追従能力（Instruction Following）は不安定になります。特に、複数のルールが競合する場合や、複雑な推論が必要な場面では、プロンプトで指定したルールよりも、事前学習で身につけた「一般的な振る舞い」が優先されてしまうことが珍しくありません。
現場がAIに見切りをつける瞬間：回答精度より信頼性の欠如
現場のユーザーがAIに見切りをつけるのは、「答えが間違っていた時」よりも「ルールを破った時」です。
知識の間違いは「まだ勉強不足だな（データが足りないな）」で許されることもありますが、何度言っても「禁止されている表現を使う」「JSON形式が壊れている」「社外秘の扱いを間違える」といった挙動は、システムとしての信頼性を根本から損ないます。「いつ暴走するかわからないものを、業務フローには乗せられない」と判断されてしまうのです。
LLMが指示を無視するメカニズム：確率論的生成の限界
では、なぜAIはこれほどまでに指示を無視するのでしょうか。技術的な側面から、そのメカニズムを論理的に深掘りしてみましょう。
汎用モデルの「お節介」がドメイン特化の邪魔をする
私たちが普段使っている基盤モデルは、世界中のWebデータで学習され、「人助けをする（Helpful）」「無害である（Harmless）」ように調整（RLHFなど）されています。
これが、ドメイン特化の場面では逆に邪魔をすることがあります。
例えば、医療従事者向けのAIを作るとします。医師が「この症状に対する処置法は？」と聞けば、専門的なガイドラインのみを即座に返してほしいはずです。
しかし、汎用モデルは「親切」なので、「医師の診断を受けてください」「一般的な処置としては…」といった、プロにとっては不要な前置きや免責事項をペラペラと喋り始めます。
プロンプトで「前置き不要」と書いても、モデルの根本的な重みパラメータが「丁寧な回答」に偏っているため、確率的にどうしてもそちらに引っ張られてしまうのです。
Positive Constraints（推奨）とNegative Constraints（禁止）の非対称性
LLMにとって、「〇〇してください」という肯定的な指示（Positive Constraints）よりも、「〇〇してはいけません」という否定的な指示（Negative Constraints）を守る方が圧倒的に難しいことが知られています。
これは「ピンクの象を想像しないでください」と言われると、かえって想像してしまう心理現象に似ています。LLMの生成プロセスは、関連する単語の確率を上げていく仕組みなので、「禁止ワード」に関連する概念がコンテキストに含まれていると、その単語を出力してしまう確率がどうしても上がってしまいます。
プロンプトは「お願い」であって「強制」ではない
技術的に言えば、プロンプトエンジニアリングは、モデルの出力確率分布を「入力テキスト」によって操作しようとする試みです。
しかし、これはあくまで「誘導」であって「強制」ではありません。モデルが学習過程で獲得した強力な事前知識や振る舞いのパターン（バイアス）は、数行のプロンプト指示よりも強い影響力を持つことが多々あります。
特に、コンテキストウィンドウの限界や、Attention機構の分散（長い文章のどこに注目すべきか迷う現象）により、プロンプトによる制御には限界があります。「絶対に守れ」と書くことは、AIにとっては「できれば守ってね」程度の重みでしか処理されていない可能性があるのです。
解決策としての「制約条件付きインストラクション・チューニング」
ここで登場するのが、今回のテーマである「制約条件付きインストラクション・チューニング」です。
これは、AIモデルのパラメータそのものを更新し、プロンプトによる外部指示に頼らず、モデルの「本能」レベルでルールを守るように矯正する手法です。
「知識」ではなく「従順さ」を再学習させるアプローチ
従来のファインチューニング（継続事前学習）は、業界の専門用語や知識を覚えさせるために、大量のドキュメントを読ませるのが一般的でした。これは「教科書を読ませる」アプローチです。
対して、インストラクション・チューニングは「問題集を解かせる」アプローチです。「指示（Instruction）」と「理想的な回答（Output）」のペアを大量に学習させます。
「制約条件付き」とは、この問題集の中に、あえて厳しい制約を含めることを意味します。
例えば、以下のようなデータで学習させます。
- 指示: 顧客からのクレームに対して謝罪文を作成してください。
- 制約: ただし、こちらの非を全面的に認める表現（「申し訳ございません」など）は法務確認が済むまで使用せず、「ご不便をおかけしております」という表現に留めること。また、300文字以内でまとめること。
- 回答: （制約を完璧に守った謝罪文）
これを何千パターンも学習させることで、モデルは「謝罪文の書き方」を覚えるだけでなく、「指示の中に含まれる『ただし〜』という制約条件は、何が何でも優先しなければならない」というメタなルール（振る舞い）をパラメータレベルで定着させるのです。
通常のファインチューニング（SFT）との決定的な違い
一般的なSFT（Supervised Fine-Tuning）と混同されがちですが、目的が異なります。
- 一般的なSFT: 特定のタスク（要約、翻訳など）の精度を上げる、あるいはドメイン知識を補完する。
- 制約条件付きチューニング: 指示への追従性（Instruction Following）を高め、特に「禁止事項」や「フォーマット制約」に対する感度を極限まで高める。
比喩を使うなら、前者は「専門知識を教える大学の講義」、後者は「軍隊のような規律を教える訓練」です。ドメイン特化LLMを実務で使うには、知識（大学）だけでなく、規律（訓練）が必要なのです。
制約を守った場合と破った場合の両方を教える
さらに高度な手法として、DPO（Direct Preference Optimization）などの技術を組み合わせることも有効です。
これは、「制約を守った良い回答」と「制約を破ってしまった悪い回答」のペアをAIに見せ、「こっちはダメ、こっちは正解」と教える方法です。これにより、AIは「なぜ自分の回答がダメだったのか」の境界線をより明確に学習し、ハルシネーションやルール違反を自己抑制できるようになります。
【実践の指針】どのようなデータセットを用意すべきか
概念は理解いただけたかと思いますが、実務において気になるのは「具体的にどのようなデータを用意すればよいのか」という点でしょう。
ここが勝負の分かれ目です。漫然と過去のQ&Aデータを学習させても、制御可能なAIにはなりません。
成功例だけでは不十分：AIに「失敗」を教える重要性
通常、学習データには「綺麗な正解」ばかりを用意しがちです。しかし、制約条件を守らせたいなら、「制約違反を誘発しそうな意地悪な指示」に対する「正しくガードした回答」をデータセットに含める必要があります。
例えば、金融機関向けLLMを作る場合：
- 意地悪な指示: 「A社の株は来月絶対に上がりますか？イエスかノーで答えて。」
- 理想的な回答: 「金融商品取引法の規定により、将来の株価変動について断定的な予測を行うことはできません。ただし、過去の変動実績については以下の通りです…」
このように、「ユーザーはルールを無視して質問してくる」という前提に立ち、それに対してAIがどう「いなす」か、どう「安全側に倒す」かという手本を大量に見せるのです。
業界特有の「制約」を言語化したデータセットの構築
自社の業務を見直し、暗黙の了解となっている「制約」を明文化し、それをデータセットのInstruction（指示）部分に組み込みましょう。
- フォーマット制約: JSON、Markdown、CSV、特定のXMLタグ構造など。
- スタイル制約: 「だ・である」調、「です・ます」調、専門用語の多用/回避、断定表現の禁止など。
- 論理的制約: 「Aの場合はBを含める」「Cの情報がない場合は回答を拒否する」といった条件分岐。
- 倫理・コンプライアンス制約: 個人情報のマスキング、競合他社への言及禁止、差別的表現の回避。
これらを組み合わせた「複合的な制約」を含むプロンプトと、それを完璧に満たす回答のペアを作成します。人間が手動で作るのは大変なので、既存の強力なLLM（ChatGPTなど）を使って、社内規定から「制約付きQ&A」を合成データとして生成させるアプローチが効率的です。
ルールベース評価とLLM評価のハイブリッド
データセットを作る際、その品質（本当に制約を守れているか）をチェックする仕組みも重要です。
「JSON形式であるか」などの形式的な制約はプログラム（ルールベース）で自動判定できます。一方で、「口調が慇懃無礼でないか」「リスク説明が適切になされているか」といった定性的な制約は、別のLLM（Judgeモデル）に評価させます。
この評価プロセスをデータ作成パイプラインに組み込むことで、学習データの質を担保し、結果としてチューニング後のモデルの信頼性を高めることができます。
制御可能なAIがもたらすビジネスインパクト
最後に、手間をかけてまで「制約条件付きインストラクション・チューニング」を行うビジネス上の価値について触れておきましょう。
「人間によるダブルチェック」工数の劇的な削減
AIが生成した文章を、人間が毎回「てにをは」から「コンプライアンス違反」までチェックしていては、業務効率化の効果は半減してしまいます。
チューニングによってAIが「形式」と「禁止事項」を99%守れるようになれば、人間は内容のファクトチェックだけに集中できます。これにより、AI導入のROI（投資対効果）は劇的に向上します。
コンプライアンスリスクの低減とAI活用の適用範囲拡大
これまで「リスクが高くてAIには任せられない」とされていた領域、例えば契約書の一次チェックや、顧客への直接回答案の作成なども、制約遵守能力が高まれば自動化の対象に入ってきます。
「絶対にやってはいけないこと」を理解しているAIは、単に賢いAIよりも、企業にとっては遥かに価値があるパートナーとなり得るのです。
ブラックボックスからの脱却と説明責任の担保
制約条件付きチューニングを行うと、AIの挙動が予測可能になります。「なぜAIはこう答えたのか？」という問いに対し、「学習された制約条件に基づき、リスク回避を優先した結果である」と説明がつくようになります。
これは、AIガバナンスの観点からも非常に重要です。
RAGやプロンプトエンジニアリングは強力な武器ですが、それらはあくまで「使い手」の技量に依存します。対して、チューニングは「道具そのもの」を自社の手に馴染むように作り変える行為です。
もし今、RAGの回答精度やAIの暴走に悩んでいるのであれば、プロンプトをいじり回す手を一度止め、モデル自体に「我が社のルール」を教え込むチューニングを検討してみてはいかがでしょうか。
それが、真に使える「ドメイン特化型LLM」への最短ルートになるはずです。
コメント