LLMを"賢く"するための3つの方法｜実務で使い分けてわかったこと

GASでLLMを使ったbotをいくつも作ってきました。

社内の業務を自動化したり、問い合わせに答えるbotを作ったり。その過程で気づいたのは、LLMの出力をコントロールする方法は一つではないということです。

調べてみると、LLMに独自の知識や振る舞いを持たせる手法は大きく3つあります。システムプロンプト、RAG、ファインチューニング。

私自身、システムプロンプトは日常的に使っていて、RAGは今まさに開発中、ファインチューニングは未経験という状態です。全部を使いこなしているわけではありません。ただ、実際に段階を踏んで進めてきたからこそ見えた「使い分け」があります。

今回は、この3つの手法をどう選ぶべきかを、自分の実体験をもとに整理してみます。

LLMをカスタマイズする3つの手法

LLMに独自の振る舞いや知識を持たせたいとき、選択肢は大きく3つあります。

	システムプロンプト	RAG	ファインチューニング
ひとことで言うと	指示を与える	知識を渡す	モデルを変える
導入コスト	低い	中くらい	高い
知識の更新	手動で書き換え	DB更新で即反映	再学習が必要
向いている場面	口調やルールの制御	独自データで答えたい	タスク特化で精度を極めたい

ポイントは、これらは排他的な選択肢ではないということです。シンプルな方から順に試して、足りなくなったら次の手法を重ねていく。この「段階的アプローチ」が実務での鉄則だと感じています。

システムプロンプト ― まずはここから始める

最も手軽で、すぐに効果が出る方法です。APIリクエスト時にLLMへ指示文を渡すだけ。「あなたは〇〇の専門家です」「回答はJSON形式で返してください」といった具合に、振る舞いのルールを定義します。

どう変わるか。 たとえば、何も指示しないLLMに「この物件どう思う？」と聞くと、一般的な不動産知識を並べた教科書的な回答が返ってきます。ここにシステムプロンプトで「あなたは不動産会社の営業アシスタントです。お客様への提案を意識して、メリット・デメリットを簡潔に回答してください」と加えるだけで、トーンも内容も実務寄りに変わります。さらにFunction Callingでツールの定義を加えれば、物件データベースを検索したり、計算処理を呼び出したりもできるようになる。

私はGASでこうしたbotをいくつも運用していますが、使っていて実感するのは一発で完成しないということ。最初に書いたプロンプトでいきなり理想通りの回答が返ってくることはまずありません。実際に使ってみて、想定外の回答が出たら修正する。ツールの説明を追加したり、禁止事項を明記したり。この地道なチューニングを繰り返すことで、ようやく実用レベルになります。

一方で、限界もあります。プロンプトが長くなりすぎると、指示の遵守率が下がる印象があります。「これも入れたい、あれも入れたい」と詰め込むほど、LLMが一部の指示を無視し始める。また、社内ドキュメントの内容をまるごとプロンプトに入れるのは現実的ではありません。

そこで次の選択肢が出てきます。

RAG ― 外部の知識を渡す

RAG（Retrieval-Augmented Generation）は、外部のデータベースから関連する情報を検索して、それをプロンプトに添えてからLLMに回答させる仕組みです。

簡単に言うと、「カンペを渡してから質問する」ようなイメージです。モデル自体は変えずに、回答に必要な知識だけをその都度渡す。だから知識の追加や更新もデータベースを書き換えるだけで済みます。

どう変わるか。 たとえば社内の就業規則についてLLMに聞いても、当然「そんな情報は持っていません」となります。でもRAGを使えば、質問に関連する就業規則の該当箇所を自動で検索し、その内容を踏まえて回答してくれる。「有給休暇の申請期限は3日前までです（就業規則第○条より）」のように、根拠つきで答えられるようになります。

私は今、社内ナレッジを蓄積して社員からの質問に答えるチャットボットを開発しています。Cloud Run × Python × LangChainという構成です。

LangChainを使えば、RAGのコアな流れ自体は意外とすぐに動きます。「え、もう動くの？」というのが正直な感想でした。

ただ、動くことと使えることは別の話です。

そのままでは検索の精度が悪く、質問に対して見当違いな文書を引っ張ってきてしまう。当然、LLMの回答もズレたものになります。チャンクの分割サイズを調整したり、検索のロジックを工夫したり、「精度を上げるための泥臭い作業」がRAGの本質だと感じています。

システムプロンプトが「指示を工夫する」作業だとすれば、RAGは「検索の精度を上げる」作業。レイヤーは違いますが、結局やっていることは地道なチューニングです。

ファインチューニング ― モデルそのものを作り変える

ファインチューニングは、既存のモデルに追加のデータで再学習させて、モデルの振る舞い自体を書き換える方法です。

システムプロンプトが「毎回メモを渡す」、RAGが「毎回資料を渡す」だとすれば、ファインチューニングは「その人自身を教育する」ようなものです。一度学習させれば、プロンプトで指示しなくても特定の振る舞いをしてくれるようになります。

どう変わるか。 最近の事例で言うと、楽天が2026年3月にリリースした「Rakuten AI 3.0」がわかりやすいです。これはDeepSeek V3という中国発の高性能モデルをベースに、日本語データでファインチューニングを施したモデルです。その結果、日本語の質問応答ベンチマーク（JamC-QA）でGPT-4oを上回るスコアを記録し、日本固有の文化やルールに関する知識も強化されました。文末表現や語彙の選択も自然で、「日本語ネイティブ」のような出力ができるモデルに変わった。

つまり、元のDeepSeek V3は英語・中国語が中心のモデルでしたが、ファインチューニングによって「日本語が得意なモデル」に根本から変わったわけです。これはシステムプロンプトで「日本語で答えて」と指示するのとは次元が違います。

ただし、楽天のケースは国のプロジェクト（GENIAC）として大規模なリソースが投入されています。高品質な学習データの準備、GPUコスト、学習時間。個人や小規模チームが気軽に手を出せるものではありません。

だからこそ、まずシステムプロンプトとRAGで対応できないかを考える。ファインチューニングは、それでも精度が足りないときの最終手段という位置づけです。

どう使い分けるか

3つの手法を並べてみると、やるべき順番が見えてきます。

まずシステムプロンプトを試す。 口調の制御、ルールの定義、出力形式の指定。これだけで解決するケースは想像以上に多いです。コストも低く、すぐに試せる。まだシステムプロンプトを真剣に書いたことがないなら、ここから始めて間違いありません。

システムプロンプトに収まらなくなったらRAGを検討する。 社内ドキュメントや商品情報など、プロンプトに毎回入れるには多すぎる知識を扱いたくなったタイミングです。構築にはそれなりの手間がかかりますが、モデル自体を変えずに知識を拡張できるのは大きなメリットです。

それでも精度が足りないとき、初めてファインチューニングを検討する。 多くの場合、ここまで来る必要はないと思っています。ただ、「この特定のタスクだけは絶対に外せない」という場面では、選択肢として知っておく価値はあります。

私自身、この順番で実際に進んでいます。システムプロンプトで何本もbotを作り、限界を感じてRAGに挑戦し始めたところです。大事なのは、いきなり難しい手法に飛びつかないこと。シンプルな方法で解決できるなら、それが最善です。

LLMを業務に組み込みたいと思っている方は、まずシステムプロンプトを丁寧に書くところから始めてみてください。それだけで「LLMって使えるな」と実感できるはずです。