はじめに
近年、多くの組織が医療や法務、金融、製造などの特定ドメインに特化したLLM（大規模言語モデル）の開発に取り組んでおり、これは業務効率化やDX推進の要となっている。しかし、汎用モデルに専門文書を大量学習させても、実務に耐えうる回答が得られず、微細なニュアンスを取り違えたハルシネーションが出力される「精度の壁」に直面するケースが散見される。
これは単なるデータ不足ではなく、「専門家の暗黙知」がモデルに適切に伝達されていないことが根本原因である。不正確な専門知識を出力するAIは、誤った意思決定を誘発する深刻なリスク（倫理的負債）を抱える。この課題を解決し、システムの透明性と信頼性を担保しつつ、データ分析の質を向上させる鍵が、Human-in-the-Loop（HITL：人間参加型ループ）である。
本記事では、エンジニアとドメイン専門家（SME）が協調し、高品質な特化型モデルを構築するワークフローを提示する。Label Studioを用いたアノテーション環境構築から、LoRAを活用したファインチューニング、継続的な評価フィードバックまで、実装の道筋を論理的に解説する。
LoRAを用いた学習では、ベースモデルのライセンス制約（商用利用の可否など）のクリアランスが重要となる。また、悪意あるコード実行を防ぐため、モデルの保存・読み込みには.safetensors形式を優先利用するなど、安全な運用体制も求められる。技術の進歩と倫理的配慮を両立し、人間の知見をAIに継承させるプロセスを探求する。
このチュートリアルのゴール：技術と専門知の融合
なぜ「データ量」より「専門家のフィードバック」なのか
AI開発のアプローチは、単なる「データ量」の追求から、「データの質」および「人間による評価」の重視へとシフトしている。xAIのGrokに代表されるリアルタイム検索連動型モデルなどはWeb上の最新情報を取り込めるが、インターネット上に正解が存在しない「組織固有のノウハウ」や、高度な倫理的判断を要する「専門家の暗黙知」は、外部データからは学習できない。不正確なデータの大量混入は、モデルの信頼性を損なう重大なリスク要因となる。
ノイズの多い1万件のデータよりも、専門家が検証・修正した100件の「ゴールデンデータセット」の方が、モデルの挙動を正しく、かつ倫理的に矯正できるケースが多い。説明可能なAI（XAI）の実現やバイアス軽減には、人間がブラックボックスに関与する Human-in-the-Loop（HITL） が不可欠である。HITLは単なるラベル付与作業ではなく、人間の判断基準（倫理観、専門性、文脈理解）をモデルのアライメントに組み込む、高度な知的生産プロセスと位置づけられる。
作成するシステムの全体像（HITLパイプライン）
本チュートリアルでは、専門家の知見をAIへ転写し、業務効率化に資するモデルを構築するため、以下のパイプラインを設計する。
- Selection & Pre-annotation: 未ラベルデータに対し現行モデルが推論を行い、初期回答（仮ラベル）を付与する。これにより、人間は「ゼロから記述する」のではなく「確認・修正する」作業に集中でき、業務負荷が軽減される。
- Expert Refinement: ドメイン専門家がアノテーションツール（Label Studio等）を用いて初期回答を修正・加筆する。ここで生成されるデータが「ゴールデンデータセット」となる。
- Fine-tuning (LoRA): 修正データを正解とし、LoRA（Low-Rank Adaptation）等を用いてモデルを再学習させる。フルパラメータチューニングと比較して計算コストを抑えつつ、特定ドメインへの適応を図る。
- Human Evaluation: 新旧モデルの出力を専門家が比較評価し、採用可否を判断する。正解率だけでなく、回答の安全性や倫理的な妥当性も評価基準に含める。
このループにより、モデルは「専門家がどのように修正したか」という差分から、特有の思考プロセスや言葉選び、倫理的配慮を学習していく。
環境構築：専門家が参加しやすい基盤を作る
エンジニアがCLI（コマンドラインインターフェース）で作業することは効率的であるが、医師や弁護士、熟練技術者に対して同様の操作を要求することは、プロジェクトの持続可能性を損なう。多様なステークホルダーが参加しやすいUIを提供することは、公平で良質なデータを収集し、DX推進を円滑に進めるための第一歩である。
ここでは、Dockerを用いて容易に構築でき、API連携にも適したオープンソースのアノテーションツールであるLabel Studioを採用する。
アノテーションツール「Label Studio」のセットアップ
Dockerを使用し、ローカル環境（または組織内サーバー）にLabel Studioを構築する。コンテナ技術の活用により、環境依存のトラブルを回避し、迅速に基盤を整備することが可能となる。
# DockerでのLabel Studio起動コマンド
# 最新の公式イメージを使用
docker run -it -p 8080:8080 -v $(pwd)/mydata:/label-studio/data heartexlabs/label-studio:latest
起動後、ブラウザで http://localhost:8080 にアクセスし、アカウントを作成する。
Hugging Faceライブラリと学習環境の準備
Google ColabやローカルGPUマシンでの実行を想定し、Hugging Faceエコシステムを中心としたPython環境をセットアップする。
# 必要なライブラリのインストール
# transformers, peft, bitsandbytes, trl, label-studio-sdkを含めた環境構築
!pip install -q transformers peft bitsandbytes trl label-studio-sdk
各ライブラリの役割は以下の通りである。
transformers: 基盤モデルをロードし学習するための核心ライブラリ。2025年1月リリースのv5.0.0で内部設計が刷新され、PyTorchが主要フレームワークとなりTensorFlowとFlaxのサポートは終了した。transformers serveによるOpenAI互換APIを介したモデルデプロイなど、推論機能も強化されている。peft: LoRAなどのパラメータ効率の良い学習手法（PEFT）を扱うために必須となる。bitsandbytes: 4bitや8bitの量子化技術により、限られたGPUメモリでも大規模モデルの学習を可能にする。Transformers v5では量子化が第一級の概念として再設計された。trl: 強化学習やSFT（Supervised Fine-Tuning）を効率化する。SFTは指示付きデータでベースモデルを微調整し、アテンション重みの分布を変化させて指示追従性を向上させる。label-studio-sdk: PythonスクリプトからLabel Studioを操作するためのSDK。
※Transformersはv5への移行に伴い一部APIが変更・削除されているため、過去のコードを流用する際は公式の移行ガイドを確認することが推奨される。
専門家向けUIの簡易カスタマイズ
Label StudioのXMLタグによるUIカスタマイズ機能を活用し、専門家が直感的に「AIの回答」を修正できる画面を設計する。プロジェクト作成時の「Labeling Setup」で「Custom Template」を選択し、以下のXMLコードを設定する。
<View>
<Header value="AIモデルの回答修正タスク" />
<View style="display: flex; gap: 20px;">
<!-- 入力プロンプトの表示 -->
<View style="flex: 1;">
<Header value="質問 / 入力" size="4"/>
<Text name="prompt" value="$instruction" />
<Text name="context" value="$input" />
</View>
<!-- 修正用エリア -->
<View style="flex: 1;">
<Header value="専門家による修正回答" size="4"/>
<TextArea name="response" toName="prompt"
rows="10" editable="true"
required="true" maxSubmissions="1"
showSubmitButton="true"
value="$prediction" />
</View>
</View>
<!-- 品質フラグ（オプション） -->
<Header value="回答品質評価" size="4"/>
<Choices name="quality" toName="prompt">
<Choice value="修正なしでOK" />
<Choice value="軽微な修正" />
<Choice value="大幅な修正" />
<Choice value="ハルシネーションあり" />
</Choices>
</View>
これにより、左側に「質問」、右側に「編集可能なAIの回答」が表示される。専門家はゼロから文章を起草する必要がなく、AIの初期出力を推敲・修正する感覚で作業できるため、認知的負荷が大幅に軽減され、業務効率化に寄与する。
Step 1: ゴールデンデータセットの作成と品質定義
専門家による「正解」の定義とガイドライン策定
作業に着手する前に、「何が良い回答か」を定義するガイドラインを策定することが重要である。明確な基準が存在しない場合、修正方針にばらつきが生じ、モデルの学習に悪影響を及ぼす。
- トーン＆マナー: 「です・ます」調か、「だ・である」調か。
- 専門用語の扱い: 略語を許容するか、正式名称を使用するか。
- 安全性: 不確実な情報に対して「不明である」と回答する制約を設けるか。
これらをドキュメント化し、Label Studioのプロジェクト説明欄に明記することで、アノテーションの透明性と一貫性を確保する。
初期データのインポートとプレアノテーション
白紙の状態から回答を作成することは非効率であるため、既存モデルの出力を初期値としてインポートする。Python SDKを使用してデータをLabel Studioに登録する。
from label_studio_sdk import Client
# Label Studioへの接続
ls = Client(url='http://localhost:8080', api_key='YOUR_API_KEY')
project = ls.get_project(1) # プロジェクトIDを指定
# データの準備（例）
tasks = [
{
"data": {
"instruction": "高血圧患者への食事指導のポイントを教えてください。",
"input": "（患者背景データ...）",
"prediction": "塩分を控えめにしましょう。具体的には..." # ここにAIの初期回答を入れる
}
},
# ... 他のデータ
]
# タスクのインポート
project.import_tasks(tasks)
専門家による修正プロセスの実施
Label Studioの画面上で、専門家がAIの回答（prediction）を確認し、不正確な部分や表現の不備を修正してSubmitを実行する。このプロセスを通じて蓄積される「専門家の倫理的・専門的判断」が反映されたデータこそが、組織独自の価値ある資産となる。
Step 2: LoRAによる軽量ファインチューニングの実装
100〜300件程度の修正データが蓄積された段階で、モデルの学習を実行する。LoRA（Low-Rank Adaptation）を採用することで、一般的な計算資源でも十分に学習が可能となる。
作成したデータセットのフォーマット変換
Label StudioからエクスポートしたJSONデータを、学習に適したJSONL形式に変換する。
import json
# Label StudioからJSON-MIN形式でエクスポートしたファイルを読み込む
with open('project-1-at-2023-10-27.json', 'r', encoding='utf-8') as f:
ls_data = json.load(f)
training_data = []
for task in ls_data:
# 修正後のテキストを取得
instruction = task['data']['instruction']
input_text = task['data'].get('input', '')
# アノテーション結果（修正後回答）を取得
# outputはLabel Studioの構造に依存するため適宜調整
try:
output_text = task['annotations'][0]['result'][0]['value']['text'][0]
training_data.append({
"instruction": instruction,
"input": input_text,
"output": output_text
})
except (KeyError, IndexError):
continue
# JSONLとして保存
with open('train_data.jsonl', 'w', encoding='utf-8') as f:
for entry in training_data:
f.write(json.dumps(entry, ensure_ascii=False) + '\n')
QLoRAを用いた効率的な学習スクリプトの作成
transformersとpeftを使用し、メモリ効率に優れたQLoRA（4bit量子化LoRA）による学習を実装する。
import torch
from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig, TrainingArguments
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer
from datasets import load_dataset
# モデルID（例: 日本語対応モデル）
model_id = "elyza/ELYZA-japanese-Llama-2-7b-instruct"
# 4bit量子化の設定
bnb_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.float16,
)
# モデルのロード
model = AutoModelForCausalLM.from_pretrained(
model_id,
quantization_config=bnb_config,
device_map="auto"
)
# LoRAの設定
peft_config = LoraConfig(
r=16, # ランク：大きいほど表現力が増すがメモリを消費する
lora_alpha=32, # スケーリング係数
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM",
target_modules=["q_proj", "v_proj"] # ターゲットモジュールはモデル構造に依存する
)
# 学習データのロード
dataset = load_dataset("json", data_files="train_data.jsonl", split="train")
# トレーナーの設定
training_args = TrainingArguments(
output_dir="./results",
num_train_epochs=3,
per_device_train_batch_size=4,
gradient_accumulation_steps=4,
learning_rate=2e-4,
logging_steps=10,
save_strategy="epoch",
fp16=True,
)
trainer = SFTTrainer(
model=model,
train_dataset=dataset,
peft_config=peft_config,
dataset_text_field="text", # データセット整形関数が必要な場合がある
max_seq_length=1024,
tokenizer=AutoTokenizer.from_pretrained(model_id),
args=training_args,
)
# 学習開始
trainer.train()
# モデルの保存
trainer.model.save_pretrained("./final_adapter")
注意: 上記コードは概念実証用である。実際のデータセット形式に合わせてdataset_text_fieldやデータ整形関数（formatting_func）を適切に調整する必要がある。
学習ログの監視と過学習のチェック
学習中はTraining Lossの推移を客観的に監視する。Lossが過度に低下すると「過学習（Overfitting）」に陥り、訓練データ以外の入力に対して適切な回答ができなくなるリスクが生じる。少量のデータセットを用いる場合、Epoch数は3〜5程度から開始し、Validation Lossを確認しながら慎重に調整することが推奨される。
Step 3: 専門家による定性評価（Human Evaluation）ループ
学習完了後、倫理的および品質的な観点から評価を実施する。数値上の指標（BLEUやROUGEスコア）は文章の流暢さを測定できても、専門的な正確性や倫理的妥当性を評価することは困難である。
学習済みモデルの推論結果をLabel Studioに書き戻す
新たに学習したモデル（LoRAアダプター適用済み）を用いてテスト用プロンプトに対する回答を生成し、再度Label Studioに「評価タスク」としてインポートする。
Side-by-Side比較によるブラインドテストの実装
バイアスを軽減し、客観的な評価を行うための有効な手法が、Side-by-Side（SBS）比較である。「学習前のモデル（Model A）」と「学習後のモデル（Model B）」の出力を並置し、どちらが優れているかを専門家に判定させる。この際、どちらが新モデルであるかは伏せておく（ブラインドテスト）。
Label StudioのXML設定例（評価用）：
<View>
<Header value="モデル比較評価" />
<Text name="prompt" value="$instruction" />
<View style="display: flex; gap: 20px;">
<View style="flex: 1; background: #f0f0f0; padding: 10px;">
<Header value="回答 A" size="5"/>
<Text name="model_a" value="$output_a" />
</View>
<View style="flex: 1; background: #f0f0f0; padding: 10px;">
<Header value="回答 B" size="5"/>
<Text name="model_b" value="$output_b" />
</View>
</View>
<Header value="どちらが優れていますか？" />
<Choices name="preference" toName="prompt">
<Choice value="Aが優れている" />
<Choice value="Bが優れている" />
<Choice value="同等" />
</Choices>
<Header value="理由（任意）" />
<TextArea name="reason" toName="prompt" />
</View>
フィードバックに基づく再学習の判断基準
専門家による評価結果を集計し、新モデルの「勝率」を算出する。勝率が著しく低い場合や、「ハルシネーションが増加した」といったフィードバックが得られた場合は、学習パラメータやデータの品質を再評価する。この評価結果自体もReward Modelの学習データとして利用可能であり、継続的な改善サイクルを構築する。
トラブルシューティングと運用へのヒント
専門家の意見が割れた時の対処法
高度な専門領域においては、専門家間で見解が相違すること（Inter-Annotator Disagreement）が起こり得る。倫理的な観点からは、無理に一つの正解に収束させるのではなく、「意見が分かれた」という事実自体を記録し、透明性を確保することが重要である。第三の専門家による最終判定を仰ぐか、ガイドラインを改訂して判断基準を明確化するプロセスを経ることで、組織のデータ分析の質が向上する。
ドメイン知識の「忘れ（Catastrophic Forgetting）」対策
特定の知識を過剰に学習させると、一般的な対話能力や論理的思考力を喪失する「破滅的忘却」が発生するリスクがある。これを防ぐためには、学習データに一般的な高品質な対話データ（Instruction Tuning用データセットなど）を一定割合混合し、「Replay Buffer」として機能させることが技術的に有効である。
継続的な品質監視体制の維持
法改正や新たなガイドラインの策定などにより、ドメイン知識は常に変化する。定期的に専門家によるサンプリング評価を実施し、モデルの知識が陳腐化していないかを監視する運用フロー（LLMOps）を確立することが、DX推進を持続可能なものにする上で不可欠である。
まとめ：信頼されるAIを育てるのは「人」である
本記事では、Label StudioとLoRAを用いたHuman-in-the-Loopファインチューニングの実装方法について、論理的かつ客観的な視点から解説した。
技術的な設定も重要であるが、最も留意すべき点は「AIの精度向上および倫理的妥当性の確保は、人間側の理解と関与の深さに比例する」ということである。専門家を単なるアノテーターとして扱うのではなく、AIシステムの構築における重要なパートナーとして位置づけるプロセス設計が、プロジェクト成功の鍵となる。
倫理的で、説明可能であり、かつ業務効率化に貢献する実用的なAI。そのような「信頼されるシステム」としてのAIは、技術と人間の継続的な協調によって構築されるべきである。
コメント