導入：汎用モデルが「現場」で使い物にならない瞬間
多くの企業のDX推進担当者の方から、こんな相談を受けることが増えました。
「生成AIを導入したけれど、専門的な業務になると途端に『知ったかぶり』をする」
「社内用語や業界特有の言い回しが通じず、結局人間が修正している」
皆さんも、似たような経験はありませんか？
例えば、建設現場で「ネコ持ってきて」と言われて、本物の猫を連れてくる作業員はいません。これは手押し車（一輪車）のことです。また、「朝礼看板」と言えば、単なる看板ではなく、当日の作業内容や安全注意事項が書かれた掲示板全体を指す文脈があります。
汎用的な大規模言語モデル（LLM）は、インターネット上の膨大な知識を持っていますが、あなたの会社の「現場」の文脈を知りません。RAG（検索拡張生成）を使えば社内ドキュメントを検索させることはできますが、それだけでは「言葉のニュアンス」や「熟練者の暗黙知」までは模倣できないのです。
ここで必要になるのが、AIモデルの「ドメイン適応（チューニング）」です。
しかし、いきなり「ファインチューニングしよう」と舵を切るのは危険です。莫大なコストがかかり、元のモデルが持っていた汎用的な賢さを失うリスクもあるからです。
そこで今回は、Google CloudのVertex AI Model Gardenを活用し、リスクを最小限に抑えながら、自社専用の「現場に強いAI」を育てるための戦略的ロードマップを解説します。技術的な詳細よりも、プロジェクトリーダーとして「何を基準に判断すべきか」に焦点を当ててお話しします。
1. 戦略なきチューニングは失敗する：ドメイン特化の現在地
AIプロジェクトにおいて、「とりあえずファインチューニングすれば精度が上がるだろう」という考えは、基礎工事をおろそかにして高層ビルを建てるようなものです。まずは、なぜドメイン特化が必要なのか、そして多くのプロジェクトがどこで躓くのかを整理しましょう。
汎用LLMが「専門業務」で躓く構造的理由
ChatGPTやClaude、Geminiといった汎用LLMは、最新のアップデートにより推論能力やコーディング支援、長文理解が飛躍的に向上しています。
- ChatGPT: 最新モデルでは、複雑な推論やエージェント的なタスク処理能力が強化され、より高度な業務支援が可能になっています。
- Claude: 最新モデルでは、開発者向けのツール連携や、コードベース全体を理解した上での自律的なタスク実行能力が拡充されています。
- Gemini: 最新版では、動画や画像を含むマルチモーダル処理能力が大幅に向上しており、長時間の動画コンテキストの理解や高解像度な出力にも対応し始めています。
- GitHub Copilot: 単なるコード補完ツールから進化し、
@workspaceコマンドによるプロジェクト全体の文脈理解や、エージェントモードによる自律的な課題解決が可能になりつつあります。
しかし、どれだけ汎用モデルが高機能化しても、特定の業界や社内固有のタスクにおいては、依然として以下のような「構造的な限界」が存在します。
- 専門用語の文脈不一致: 建設業界における「ネコ（一輪車）」のように、一般的でない意味で使われる用語を、汎用モデルは一般的な文脈で解釈してしまいます。
- ハルシネーション（幻覚）のリスク: 知らない情報を問われた際、もっともらしい嘘をつく傾向は完全には解消されていません。安全基準や法規制が関わる業務では、これが致命的な欠陥となります。
- 出力形式の制御: 最新のモデルでも、社内システム連携に必要な厳密なJSON形式や、独自の帳票フォーマットでの出力を完全に守り続けることは困難な場合があります。
「とりあえずファインチューニング」が招くコスト増と精度低下
「精度が足りないなら学習させればいい」と安易にファインチューニング（モデルの全パラメータを更新する再学習）を行うと、痛い目を見ます。
まず、コストの問題です。高性能なGPUを長時間稼働させるための計算リソース費用は莫大です。次に、「壊滅的忘却（Catastrophic Forgetting）」という現象です。特定の業務データを過剰に学習させた結果、モデルが元々持っていた一般的な言語能力や論理的推論能力を失ってしまうリスクがあります。
さらに、ベースとなるモデルは頻繁にアップデートされます。例えばGeminiなどの主要モデルは、数ヶ月単位で新世代（例：2.5系から3系へ）が登場し、性能が劇的に向上します。旧世代のモデルに依存したチューニングを行うと、モデルの廃止やサポート終了に伴い、再学習や移行コストが雪だるま式に膨れ上がることになります。
Vertex AI Model Gardenが提供する「選択と集中」の環境
ここで役立つのが、Google CloudのVertex AI Model Gardenです。これは、Google自身のモデル（Geminiの最新版など）だけでなく、MetaのLlamaモデルやMistralなどのオープンモデルまで、150以上のモデルをカタログから選んで利用・調整できるプラットフォームです。
これを推奨する理由は、単にモデルの数が多いからではありません。「目的に応じて最適なモデルを選び、必要最小限の調整で済ませるための選択肢が揃っている」からです。
すべてをフルスクラッチで作るのではなく、既存の優れたモデルという「部品」を選び、自社の色に染め上げる。このアプローチこそが、変化の激しいAI技術をビジネスに適用する際の正解ルートです。
RAGとチューニングの使い分け基準
現場でよく聞かれる「RAGとチューニング、どっちがいいの？」という質問に対する答えは、明確な使い分けにあります。
- RAG (Retrieval-Augmented Generation): 「知識」を補うアプローチ。施工マニュアル、安全規定集、最新の現場日報など、事実情報を参照させたい場合に有効です。情報の更新が頻繁な場合に向いています。
- チューニング (Fine-tuning / PEFT): 「振る舞い」や「形式」を教えるアプローチ。専門用語の理解、トーン＆マナーの統一、特定のフォーマットでの出力、熟練技術者の思考プロセスの模倣など、パターンを学習させたい場合に有効です。
多くの場合、これらは対立するものではなく、組み合わせることで最強のソリューションになります。
参考リンク
2. 現状分析とモデル選定：自社データに最適なパートナー選び
チューニングを始める前に、まずは「どのモデルをベースにするか」を決める必要があります。Vertex AI Model Gardenには多種多様なモデルがありますが、闇雲に選んではいけません。
保有データの「質」と「量」による実現可能性診断
まず、自社の手元にあるデータを見てください。
- データが少ない（数十〜数百件）: 大規模なファインチューニングは不可能です。プロンプトエンジニアリングや、Few-shot Learning（例示を与える手法）で対応すべきです。あるいは、後述するParameter Efficient Fine-Tuning (PEFT) が選択肢に入ります。
- データが中規模（数千件）: 特定のタスクに特化させるチューニングが効果を発揮します。
- データが大規模（数万件以上）: 独自の基盤モデルに近い性能を目指せますが、データの品質管理が大変になります。
建設現場の例で言えば、過去数年分の「日報データ」や「ヒヤリハット報告書」が数万件あれば、かなり精度の高い特化モデルが作れる可能性があります。逆に、マニュアルが数冊あるだけなら、RAGの方が適しています。
プロプライエタリ（Gemini）かオープンモデル（Llama/Gemma）か
Model Gardenの大きな魅力は、GoogleのGeminiと、OSS（オープンソース）モデルの両方を使える点です。選定の基準は以下の通りです。
1. Gemini (Googleプロプライエタリモデル)
- メリット: 圧倒的な基礎能力、マルチモーダル対応（画像や動画も理解）、Googleによるフルマネージドな安全性。
- デメリット: モデルの中身（重み）はブラックボックス。詳細なカスタマイズには制限がある場合も。
- 推奨ケース: 高度な推論が必要なタスク、Google Workspaceとの連携、とりあえず早く高品質な結果が欲しい場合。
2. Llamaモデル, Gemma, Mistral (オープンモデル)
- メリット: モデルの重みにアクセス可能で、詳細なチューニングが可能。自社のVPC（仮想ネットワーク）内で完結させやすく、データガバナンスを効かせやすい。特定のタスクに特化させれば、Geminiより低コストで高速な場合も。
- デメリット: インフラ管理（GPUの確保など）の手間が発生する場合があります（Vertex AIではある程度マネージドですが）。
- 推奨ケース: 徹底的にコストを下げたい、特定のニッチなタスクに特化させたい、データの機密性が極めて高く外部APIを叩きたくない場合。
コスト・セキュリティ・精度の3軸トレードオフ評価
プロジェクトマネージャーは、常にこの3つのバランスを見る必要があります。
- コスト: Geminiモデルのような巨大モデルを毎回使う必要があるか？ 実は、Gemma 7Bのような軽量モデルをチューニングした方が、特定タスクでは安くて速いかもしれません。
- セキュリティ: Vertex AIを使えば、学習データがGoogleのモデル改善に使われることはありません（これはGoogle Cloudの契約上の強みです）。しかし、より厳格な規制がある業界では、オープンモデルを自社管理のインスタンスで動かす選択肢も重要です。
- 精度: 汎用的な会話能力が必要なら巨大モデル。定型業務なら軽量モデルのチューニング。
私の経験では、最初はGeminiなどの高性能モデルでPoC（概念実証）を行い、運用フェーズでコスト削減のために軽量なオープンモデルをチューニングして置き換える、という「蒸留（Distillation）」的なアプローチが成功しやすいと考えられます。
3. チューニング手法の戦略的選択：リスクを最小化するアプローチ
モデルが決まったら、次は「どう教えるか」です。ここが技術的な分岐点になりますが、リーダー層が知っておくべきは「リスクとコストのコントロール」です。
全パラメータ更新の罠とPEFT（効率的パラメータ調整）の推奨
従来のファインチューニング（フルファインチューニング）は、モデルの全てのパラメータ（数百億〜数千億個）を更新します。これは、教科書を全て書き換えるようなもので、膨大な計算資源と時間がかかります。
現在、主流となっているのはPEFT (Parameter-Efficient Fine-Tuning) というアプローチです。これは、モデルの大部分を凍結（固定）し、ごく一部のパラメータだけを追加・更新する手法です。
Adapter TuningとLoRA：低コストで専門性を注入する技術
PEFTの中でも、特にLoRA (Low-Rank Adaptation) という手法が業界標準になりつつあります。
イメージしてください。分厚い専門書（元のモデル）があります。フルファインチューニングは、この本の内容を直接書き換える行為です。対してLoRAは、「重要なページに付箋を貼り、注釈を書き込む」ようなものです。
- メリット1：低コスト
学習に必要なパラメータ数が数千分の一になるため、GPUメモリが節約でき、学習時間も劇的に短縮されます。 - メリット2：モジュラー性
「建設用語LoRA」「経理処理LoRA」「法務チェックLoRA」のように、タスクごとの「付箋セット（Adapter）」を作ることができます。ベースモデルは1つのまま、リクエストに応じてAdapterを切り替えるだけで、多能工なAIを実現できます。Vertex AIでは、このAdapterの管理・デプロイが非常に容易です。 - メリット3：壊滅的忘却の回避
元のモデルを壊さないため、基礎的な言語能力を維持したまま専門知識を追加できます。
Vertex AI Model Gardenでは、このLoRAを用いたチューニングジョブを、コードをほとんど書かずにGUIや簡単なSDKから実行できます。
RLHF（人間によるフィードバック）が必要になる境界線
さらに高度な手法として、RLHF (Reinforcement Learning with Human Feedback) があります。これは、AIの回答に対して人間が「良い/悪い」の評価を下し、そのフィードバックを元にAIを強化する方法です。
これは非常に強力ですが、人間の評価者チームを組織する必要があり、コストと時間がかかります。通常、業務特化型AIであれば、教師あり微調整（SFT: Supervised Fine-Tuning）で十分なケースがほとんどです。RLHFが必要になるのは、「倫理的な判断」や「極めて微妙なニュアンスの使い分け」が求められる、対顧客用のチャットボットなどです。
4. データ準備と実行計画：成功を決める「教師」の質
「Garbage In, Garbage Out（ゴミを入れればゴミが出る）」はAIの鉄則です。チューニングの成功は、アルゴリズムよりもデータの質で8割決まります。
ドメイン知識を「学習データ」に変換するプロセス
チューニングに必要なデータは、通常「プロンプト（入力）」と「完了（理想的な出力）」のペアです。
建設現場の日報自動生成AIを作る場合を例にしましょう。
- 悪いデータ: 単なる日報のテキストデータだけを流し込む。
- 良いデータ:
- Input: 「今日、3階の床コンクリート打設完了。作業員5名、残業なし。明日は墨出し予定。」
- Output: 「【作業報告】
実施場所：3階
作業内容：床コンクリート打設
人員：5名（残業：無）
【翌日予定】
作業内容：墨出し
ステータス：完了」
このように、「雑多な入力」に対して「理想的なフォーマットの出力」をペアにして教え込むことで、AIは「変換のルール」を学びます。
ノイズ除去とフォーマット統一の重要性
社内データは往々にして汚れています。誤字脱字、表記揺れ、個人情報などが含まれています。
- PII（個人識別情報）の削除: Cloud DLP (Data Loss Prevention) などを使い、氏名や電話番号をマスキングします。
- 表記揺れの統一: 「V.A」「VertexAI」「Vertex AI」など、同じ言葉が違う表記になっていると学習効率が落ちます。
- 重複の削除: 全く同じデータが大量にあると、特定のパターンに過剰適合（Overfitting）してしまいます。
合成データ（Synthetic Data）活用の可能性と注意点
「質の高いデータが数百件しかない」という場合、合成データを使う手があります。これは、Geminiなどの高性能モデルに「このデータに似た例を100個作って」と指示し、学習データを人工的に増やす手法です。
Vertex AIでは、このデータ生成パイプラインも構築可能です。ただし、生成されたデータに誤りがないか、専門家（人間）がサンプリングチェックを行うプロセスは必須です。
段階的な学習計画：パイロットから本番へ
いきなり全データで学習させず、以下のステップを踏むことを推奨します。
- ベースライン評価: チューニング前のモデルでどれくらいできるか確認。
- 小規模実験: 100〜500件程度の高品質データでLoRAチューニング。効果が出るか確認。
- データ拡張: 効果が確認できたら、データを数千件に増やして本格学習。
5. 評価と継続的改善：デプロイ後の品質保証
モデルができたら終わりではありません。むしろ、そこからがスタートです。エンジニアとして最も重視してほしいのが「評価（Evaluation）」です。
Vertex AI Evaluationサービスの活用法
「AIの回答が良いかどうか」をどう判断するか。以前は人間が一つ一つ読んで評価していましたが、これでは時間がかかりすぎます。
Vertex AIにはEvaluation（評価）サービスが統合されています。これを使うと、以下の指標を自動算出できます。
- BLEU / ROUGE: 正解データとどれくらい単語が一致しているか（翻訳や要約で使われる機械的な指標）。
- モデルによる評価（LLM-as-a-Judge）: 別の高性能なLLM（評価用モデル）に、「この回答は正確か？」「ハルシネーションはないか？」を判定させる手法。
AutoSxS（自動サイドバイサイド評価）による効率化
特に便利なのがAutoSxS (Automatic Side-by-Side) です。これは、モデルA（チューニング前）とモデルB（チューニング後）の回答を並べ、評価用AIに「どっちが優れているか、その理由は何か」を判定させる機能です。
これにより、「チューニングした結果、専門用語には強くなったが、文章が不自然になった」といった副作用を素早く検知できます。
モデルの陳腐化を防ぐ再学習サイクル
ビジネス環境は常に変化します。建設業界でも新しい工法や法改正が頻繁にあります。一度作ったモデルも、時間が経てば「古い知識」になります。
Vertex AI Pipelinesを活用して、以下のようなMLOpsサイクルを構築することが理想です。
- ユーザーからのフィードバック（Good/Badボタンなど）を収集。 2. 評価の低かったデータを分析し、正解データを作成。 3. 新たなデータを追加して、定期的にモデルを再チューニング（またはAdapterを更新）。 4. AutoSxSで旧モデルと比較し、性能向上を確認してからデプロイ。
このループを回せる体制こそが、真の「ドメイン特化AI」の強みとなります。
まとめ：自社専用AIへの第一歩を踏み出すために
汎用モデルの限界を感じているなら、それは御社のビジネスが「高度で専門的である」という証拠です。Vertex AI Model Gardenと適切なチューニング戦略を用いれば、その専門性をAIに実装し、強力な武器に変えることができます。
重要なのは、技術に溺れず、「解決したい課題」と「許容できるコスト・リスク」のバランスを見極めることです。
- まずはRAGで解決できないか検討する。 * どうしても必要な場合、Model Gardenから最適なモデルを選ぶ。 * LoRAなどの効率的な手法で、小さく始めて大きく育てる。 * 評価の仕組みを最初から組み込む。
これらが、現場で学んだ「失敗しない鉄則」です。
コメント