はじめに

生成AIの実用化が進み、営業支援や社内ナレッジ共有など、AI活用を検討する企業が増えています。
特に、情報システム部門やDX推進担当者、AI導入を検討する現場担当者の間では、「どの言語モデル（LLM）を選ぶべきか」が重要な検討テーマとなっています。

外部サービスとして提供されるAPI型LLMを利用するか、自社管理下のサーバやクラウド上で運用するローカルLLM（オープンソースLLM）を構築するかで、コストやセキュリティ、開発体制が大きく変わります。

この記事では、ローカルLLMの特徴とAPI型LLMとの比較を通じて、導入目的に応じた最適な選び方を紹介します。
あわせて、どちらか一方を一律に推奨するのではなく、社内業務での利用を想定し、それぞれが選択肢となる条件を整理します。

ローカルLLMとは

ローカルLLMは、MetaやMicrosoftなどが公開している自由に利用・改変可能なモデルです。
自社のサーバーやクラウド環境上で稼働させることができ、機密情報を外部に出さずに活用できます。
オープンソースとして公開されているため、ライセンス費用がかからず、モデルの内部構造を理解した上でカスタマイズできるのも特徴です。

主なローカルLLMの例

モデル名	提供元	特徴
Llama 3	Meta	高精度・軽量で商用利用可能。
Phi-3	Microsoft	小型ながら高精度。低コスト運用が可能。
Mistral / Mixtral	Mistral AI	高速処理・日本語対応が進化。
Falcon 180B	TII (UAE)	完全オープンソースで多言語対応。大規模処理にも対応可能。

ローカルLLMのメリット

1. 自社データを活かした再学習が可能
   独自データでチューニングし、業務に特化したモデルを構築できます。
2. セキュリティを自社で完結
   外部通信を行わない設計が可能で、情報漏洩リスクを抑えられます。
   特に金融や医療など、機密性の高い情報を扱う業界では有効です。
3. 長期的なコスト最適化
   一度環境を構築すれば、トークン課金なしで運用可能です。
   利用量が増えても追加コストが発生しないため、大規模な運用に向いています。

ローカルLLMのデメリット

• 初期投資が必要
  GPUサーバーやクラウド環境の構築にコストがかかります。
  特に大規模なモデルを運用する場合、高性能なGPUが必要となり、初期費用が高額になる可能性があります。
• 運用・保守の負担
  モデル更新や推論最適化にはMLOpsの知識が必要で、トラブルシューティングやパフォーマンス改善も自社で対応する必要があります。
• 性能差
  初期状態では商用モデルに劣ることもあり、精度向上には追加の学習が欠かせません。

API型LLMとローカルLLMの比較

API型LLMは「すぐに高精度なAIを使いたい企業」に向き、ローカルLLMは「自社要件に合わせてカスタマイズしたい企業」に適しています。
両者の主な違いは、運用場所とカスタマイズ性にあります。

API型LLMとは

API型LLMとは、OpenAI・Google・Anthropicなどが提供するクラウド型AIモデルです。
APIを経由で利用でき、モデル構築不要ですぐに導入できるのが最大のメリットです。

代表的なAPI型LLMの例

モデル名	提供企業	主な特徴
GPT-4	OpenAI	高精度な言語生成・要約・コード生成が可能。ChatGPTとしても利用可。
Gemini	Google	マルチモーダル対応（画像・音声・テキストを統合処理）。Google製品との連携が容易。
Claude 3	Anthropic	長文処理と安全性に優れ、企業利用に適する。
Command R+	Cohere	検索連携（RAG）に最適化され、社内ナレッジ連携に強い。

API型LLMのメリット

1. 導入の即効性
   APIキーを取得すればすぐに利用可能で、PoC（概念実証）や小規模実装に向いています。
2. 高い精度と安定性
   継続的な学習により、常に最新性能が維持され、広いタスクに高精度で対応します。
3. メンテナンス不要
   モデルの更新や改善はベンダー側が行うため、ユーザーの保守負担がほとんどありません。

API型LLMのデメリット

• 従量課金によるコスト変動
  利用量が増えるとコストが予測しづらく、展開時に費用管理が課題となります。
• データ外部送信リスク
  入力データがベンダーのクラウドを通過するため、セキュリティ上の制約が発生する場合があります。
• カスタマイズの制限
  内部構造や学習データにアクセスできず、自社固有の知識を直接反映しづらい場合があります。

ローカルLLMの導入判断ポイント

ローカルLLM導入時は「利用目的」「データの取り扱い」「社内リソース」「コスト」の4つの観点で比較検討が必要です。
社内ナレッジ検索や特定業務の自動化など用途が明確な場合や、機密情報を扱う場合はローカルLLMが適しています。

ケース別おすすめモデル

用途・導入目的別のおすすめモデルを紹介します。

シナリオ	LLM	おすすめモデル	理由
小規模なAIチャット導入	API型LLM	GPT-4 / Gemini	すぐに高品質な出力を得られる
社内ナレッジ検索システム	ローカルLLM	Llama 3 / Phi-3	内部データ連携に強い
コストを抑えたAI文書要約	ローカルLLM	Phi-3	軽量・低コストで運用可能
Google Workspace連携	API型LLM	Gemini	組織内アプリ連携が容易
特定業務向けAI構築	ローカルLLM	Llama 3	再学習により最適化が可能

さいごに

業務で生成AIを扱う機会が増える中で、目的や体制に合わせた使い分けが大切です。
まずはAPI型LLMで小さく試し、運用で得た知見をもとにローカルLLMで内製化や最適化を進めていく段階的な進め方が現実的だと考えています。
実際に使いながら理解を深めていくことで、プロジェクトに適したLLMが少しずつ見えてくるのではないかと思います。

お読みいただきありがとうございました。

はじめに

システム開発でよく使われるデータベースといえば、RDB（リレーショナルデータベース）が定番です。私のチームでも長らく、Oracle や MySQL などの RDB を利用してきましたが、ある新規APIの開発で MongoDB を採用してみたところ、思っていた以上に開発がスムーズになりました。

この記事では、MongoDB を Java + Spring Boot で使用してみて感じた3つのメリットを、実際の実装例を交えて紹介します。

MongoDB の特徴

MongoDB はドキュメント指向の NoSQL データベースであり、RDB と比べて非常に緩い設計になっているのが特徴です。RDBと違いを感じるのは、例えば以下のような点です。

• 構造化オブジェクト（JSONのようなもの）を丸ごと保存できる
• 格納するオブジェクトの仕様を厳密に決めておく必要が無い（カラム定義などは不要）
• コレクション（RDBでいうところのテーブル）に追加しようとしたときに、コレクションが無ければ自動的に作成される。データベースが無かった場合は、データベースも自動的に作成される。

プログラムから 何でも入る入れ物 的な感覚で、簡単に使えるのが特徴です。

簡単に始められる MongoDB

MongoDB の準備

MongoDB はローカルにインストールして起動します。インストール手順は割愛しますが、Dockerイメージ を使うか、公式サイトからダウンロードしてインストールすることになります。

前述した通り、データベースやコレクションを用意する必要は無いのですが、ユーザだけは用意しておく必要があります。インストールした後、以下のコマンドを MongoDB Shell などで実行します。

use admin
db.createUser({
  user: "appuser",
  pwd:  "secret",
  roles: [ { role: "readWrite", db: "sampledb" } ]
})

Spring Boot の設定

Spring Boot では、spring-boot-starter-data-mongodb を依存関係に追加するだけで、 MongoDB を簡単に利用できます。Maven の場合は以下を pom.xml に追加します。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency>

接続設定は Spring Boot の application.yml に以下のように記述します。

spring:
  data:
    mongodb:
      host: localhost
      port: 27017
      database: sampledb
      username: appuser
      password: secret
      auto-index-creation: true

auto-index-creation は、後に説明する @Indexed でインデックスを作る機能を有効にするための設定です。

エンティティ

@Document(collection = "login_history")
public class LoginHistory {
    @Id
    private String id;

    @Indexed
    private String userId;

    @Indexed(expireAfter = "30d") // 30日で自動削除
    private LocalDateTime createdAt;
}

エンティティクラスに付けている @Document アノテーションで、保存するコレクション名を指定しています。

@Id をつけたフィールドは _id という特殊なフィールドにマッピングされます。これはコレクション内でドキュメントを一意に識別するための値で、RDBでいうところの主キーに相当する役割を持ちます。

@Indexed は項目にインデックスを作成するアノテーションです。RDBのインデックスと同様で、この項目による検索を高速に行えるようになります。

expireAfter をつけると、 TTL（Time To Live）インデックス という特殊なインデックスが作成されます。これは、設定した期間を過ぎると、MongoDBが自動的にレコードを削除してくれる機能です。この例では createdAt から30日以上経過している場合に削除対象となります。

リポジトリ

public interface LoginHistoryRepository extends MongoRepository<LoginHistory, String> {
    List<LoginHistory> findByUserId(String userId);
}

あとはこのリポジトリをDIして、簡単に読み書きができます。

// 保存
loginHistory.setId("a001");
loginHistory.setUserId("sampleUser");
loginHistory.setCreatedAt(java.time.LocalDateTime.now());
loginHistoryRepository.save(loginHistory);

// IDで取得
Optional<LoginHistory> h1 = loginHistoryRepository.findById("a001");

// ユーザIDで取得
List<LoginHistory> histories = loginHistoryRepository.findByUserId("sampleUser");

このようなコードで最初のレコードを save すると、MongoDB 側には自動的に login_history コレクションが作成され、userId や createdAt にインデックスが付与されます。

実感した MongoDB の3つのメリット

1. DDL作成や実行が不要

前述した通り、MongoDB はコレクションが無くても自動的に作ってくれますし、スキーマを決めておく必要もありません。

そのため、Spring のプログラムから何かを保存したいと思ったときに、エンティティとリポジトリさえ用意すれば、すぐに保存することができます。

これによって、開発者がプログラムとDBを同時に扱えるようになり、RDBと比べて開発の自由度とスピードが上がりました。

2. TTLインデックスによる自動削除が便利

ログやセッション情報など、「一定期間で削除してよいデータ」は多く存在します。RDBでは古いデータを削除するためにバッチ処理を用意し、スケジュール実行・監視を行うのが一般的です。

MongoDBでは、前述したTTLインデックスを設定するだけで、MongoDBが自動的に期限切れのデータを削除してくれるため、削除バッチを作る必要がなくなりました。

3. データ構造が柔軟で変更に強い

正規化せずにデータを格納するため、RDBでは複数テーブルに分けてJOINしていたデータも1ドキュメントにまとめて保持できます。

そのため、データ構造が変更になっても、RDBと比べて影響が少なく、変更に強いと感じました。

導入して感じたこと

MongoDB はとても使いやすくて便利なデータベースですが、必ずしもRDBよりも優れているというわけではありません。向き不向きはあります。

具体的には、やはり正規化されていないので、複雑な結合クエリや集計は書きづらいです。複雑な検索が必要なデータには、RDBのほうが向いていると思います。

一方で、複雑な集計を必要としないデータであれば、非常に使いやすく、用途によっては良い選択肢になると感じました。

まとめ

MongoDB を Java/Spring 環境で使ってみて感じたメリットは、以下の3点でした。

• DDL作成や実行が不要
• TTLインデックスによる自動削除が便利
• データ構造が柔軟で変更に強い

一昔前は、データベースと言えばRDBでしたが、最近は MongoDB のようなドキュメント指向DBを始めとして、様々な種類のデータベースが登場しています。そして、それらが現場で使われ始めているとも感じています。

データベースには向き不向きがあります。特定の技術に固執するのではなく、様々な種類のデータベースの特徴を比較検討し、最適なものを選択することが、これからの開発には求められていくと思います。

はじめに

LLMを使っていると、「毎回似たような指示を書いているのに、出力が安定しない」という課題に直面することがあります。これは、入力の書き方や順序のわずかな違いによって出力が変わってしまうためです。安定した結果を得るためには、うまく書くことよりも一貫した構造でプロンプトを設計することが重要です。

この記事では、生成AI開発で注目されている LangChain を使い、再現性・保守性の高いプロンプトを設計する方法を紹介します。

LangChainとは

LangChain（ランチェーン） は、OpenAIやGoogle Geminiなどの大規模言語モデル（LLM）を効率的に活用するためのPythonライブラリです。プロンプト設計・外部ツール連携・メモリ管理・出力制御などを体系的に扱うことができ、AIアプリケーション開発の土台として広く使われています。

その中でもプロンプト設計に重要なのが PromptTemplate 機能 です。これはプロンプトをテンプレート化し、「固定ルール」と「変動要素」を分離することで、再利用性と安定性を高める機能です。

たとえば、「口調や出力形式は固定」「質問内容だけ毎回変える」といった使い方が簡単にできます。

LangChainでできること

LangChainでは、主に次のような機能を利用できます。

機能カテゴリ	説明	主なクラス	活用例
プロンプト設計	テンプレートで一貫性を保つ	PromptTemplate​, ChatPromptTemplate​	役割・口調・出力形式を固定
モデル接続	各種LLMを統一的に扱う	ChatOpenAI​, ChatGoogleGenerativeAI​	OpenAI ⇔ Gemini の切り替え
チェーン構築	複数プロンプトを連携	LLMChain​, SequentialChain​	生成→要約→整形 などの分割
出力制御	JSONなど構造化出力に対応	PydanticOutputParser​	APIで安全なデータ返却
メモリ管理	会話履歴を保持	ConversationBufferMemory​	チャットボット開発
外部連携	APIやDBと接続	Tool​, Agent​	検索・ファイル操作・自動化

再現性を高めるプロンプト設計

プロンプト設計の基本

プロンプト設計では、固定部分と変動部分を分けて考えることが重要です。LangChainの PromptTemplate を使うと、これらを明確に分離でき、同じ構造で安定した出力が得られます。

区分	内容	例
固定部分	役割・口調・出力形式など常に同じルール	役割: 専門家、口調: 丁寧、形式: 箇条書き
変動部分	質問や条件など、毎回変わる部分	「ダイエット中でも筋肉を落とさない食事は？」

PromptTemplateの使い方とコード例

以下は、Google Gemini モデルを使ってプロンプトテンプレートを作成する例です。

!pip install -U langchain langchain-google-genai protobuf==4.21.6

from langchain_google_genai import ChatGoogleGenerativeAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

llm = ChatGoogleGenerativeAI(model="gemini-2.5-flash", api_key="API KEYを入力")

prompt = ChatPromptTemplate.from_messages([
  ("system", "あなたは{role}です。回答は{tone}で、出力形式は{format}です。"),
  ("human", "質問: {question}")
])
chain = prompt | llm | StrOutputParser()

result = chain.invoke({
  "role": "スポーツ栄養士",
  "tone": "科学的",
  "format":"簡潔な3つの箇条書き",
  "question": "ダイエット中でも筋肉を落とさない食事の工夫は？"
})
print(result)

　

■ 出力結果

このように、テンプレートを使うと構造を保ちながら質問だけを変えることができ、再現性が向上します。

テンプレートを使わない場合との比較

同じ内容を文字列連結で書くと次のようになります。

llm = ChatGoogleGenerativeAI(model="gemini-2.5-flash", api_key="API KEYを入力")

role = "スポーツ栄養士"
tone = "科学的"
format = "簡潔な3つの箇条書き"
question = "ダイエット中でも筋肉を落とさない食事の工夫は？"

prompt = f"あなたは{role}です。回答は{tone}で、出力形式は{format}です。\n質問: {question}"

result = llm.invoke(prompt)
print(result.content)

この書き方だと、要素を追加・変更するたびに文字列全体を直す必要があり、system と human の役割構造も崩れやすくなってしまいます。固定部分と可変部分の区別がつきにくく、プロンプトの形が一定せず、結果の再現性も下がってしまう点が課題です。

安定した出力と再利用性を実現するには、PromptTemplateを使ってプロンプトを構造化する設計が効果的です。

PromptTemplateの応用

1. 出力形式を制御

PydanticOutputParser​ を使うと、AIの出力をJSON構造に固定できます。この方法を使えば、「AIが返すデータの形」を決めておけるため、システム側での処理が安定します。

from pydantic import BaseModel, Field
from langchain_core.output_parsers import PydanticOutputParser
from langchain_core.prompts import ChatPromptTemplate
from langchain_google_genai import ChatGoogleGenerativeAI

class HealthAdvice(BaseModel):
    topic: str = Field(..., description="健康トピック名")
    tips: list[str] = Field(..., description="アドバイスを3つ")
    
llm = ChatGoogleGenerativeAI(model="gemini-2.5-flash", api_key="API KEYを入力")
parser = PydanticOutputParser(pydantic_object=HealthAdvice)
prompt = ChatPromptTemplate.from_template(
    "トピック: {topic}\nについて、科学的根拠に配慮し一言で回答してください。\n"
    "JSON形式で出力してください。\n"
    "{format_instructions}"
).partial(format_instructions=parser.get_format_instructions())
chain = prompt | llm | parser

result = chain.invoke({"topic": "睡眠の質向上"})
result.model_dump()

　

■ 出力結果

2. プロンプトテストの自動化

LangChainを使えば、プロンプトをテンプレート化して構造的に扱えるため、自動テストが容易になります。文字列を直書きする場合と違い、出力の形式や再現性を機械的に検証でき、品質を安定して保てます。

from langchain_google_genai import ChatGoogleGenerativeAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

llm = ChatGoogleGenerativeAI(model="gemini-2.5-flash", api_key="API KEYを入力")
prompt = ChatPromptTemplate.from_messages([
    ("system", "あなたは{role}です。簡潔に3つ箇条書きで答えてください。"),
    ("human", "{question}")
])
chain = prompt | llm | StrOutputParser()

def test_prompt():
    result = chain.invoke({"role": "トレーナー", "question": "短時間でできる筋トレ方法"})
    print(result)
    bullets = sum(line.strip().startswith(("*", "・", "-")) for line in result.splitlines())
    if bullets != 3:
        raise AssertionError(f"異常終了：箇条書きが{bullets}個")
    print("正常終了")

test_prompt()

　

■ 出力結果

3. プロンプトチェーンで処理を分割

複数のプロンプトを「チェーン」でつなげ、以下のように「生成 → 要約」の2段階処理を自動化できます。このように「分業型のプロンプト設計」をすることで、結果の一貫性と開発効率が大きく向上します。

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_google_genai import ChatGoogleGenerativeAI

llm = ChatGoogleGenerativeAI(model="gemini-2.5-flash", api_key="API KEYを入力")

# Step 1: 情報生成
prompt1 = ChatPromptTemplate.from_template("『{topic}』について詳しく説明してください。")

# Step 2: 要約
prompt2 = ChatPromptTemplate.from_template("以下の説明を読み、最も重要なポイントを1文で要約してください。\n\n{content}")

chain = (
    prompt1 | llm | StrOutputParser()
) | (
    prompt2 | llm | StrOutputParser()
)

result = chain.invoke({"topic": "筋トレが美容にもたらす効果"})
print(result)

　

■ 出力結果

　

さいごに

LangChainの PromptTemplate を活用することで、プロンプトの品質や再現性、保守性を着実に高めることができます。
プロンプトを構造的に整理し、テンプレートとして管理することで、誰でも同じ結果を再現しやすくなります。
さらに、出力形式の制御や処理の分割、外部連携などと組み合わせることで、より安定した仕組みを作ることも可能です。
こうした工夫を重ねることで、属人的なノウハウに頼らず、再利用しやすく継続的に改善できるプロンプト設計が実現できます。

お読みいただき、ありがとうございました。