LangChain Agent on Ubuntu — Tools+Memory付きAIエージェントの実装

「LangChainって名前はよく聞くけど、Ubuntuで実際にどうやって動かすの？」というのが、最初に疑問に思うことですよね。本記事では、Ubuntu 24.04 LTS に LangChain を実際にインストールし、Tools（道具）と Memory（記憶）を持ったAIエージェントを動かすところまで、実際のコマンド出力付きで解説します。

結論からいうと、2026年6月時点で pip install langchain で入るのは langchain 1.3.9、つまり LangChain 1.x 系です。ネット上に多い langchain 0.3.x 向けの記事のコードは、Agent も Memory も書き方が変わっていてそのままでは動きません。この記事は実際に 1.3.9 を入れて動かした結果だけで書いています。

バックエンドには無料で使えるローカルLLM「Ollama」を使うので、OpenAIのAPIキーは不要です。自分のUbuntuサーバーやVPSで完全に完結します。

この記事のポイント

Ubuntu 24.04 では pip install に venv が必須（PEP 668 の制限）— 知らないと必ずエラーになる
2026-06-15 実測の最新版は langchain 1.3.9 / langchain-core 1.4.7 / langchain-ollama 1.1.0。古い 0.3.x とは API が別物
1.x の Agent は create_agent、Memory は langgraph の InMemorySaver。旧 create_react_agent / ConversationBufferMemory は廃止
Ollama をバックエンドにするので、APIキーなし・完全ローカルで動く
実際に動かして確認した Tools 呼び出し・会話記憶のコードと出力をそのまま掲載

LangChain Agent とは
前提環境
インストール手順
Tools（ツール）を定義する
create_agent で Tools+Memory 付きエージェントを実装する
1. ①エージェントのコード全体
2. ②エージェントの実行結果（実トレース）
Memory（会話履歴）が効いているか実測する
実際に動くチャットUIで触ってみる
Ollama ローカル LLM との接続設定
本当に Ubuntu で動くのか、コンテナで最終確認
よくあるエラーと解決策
VPS で本格運用する場合
まとめ

LangChain Agent とは

LangChain は Python で書かれたフレームワークで、LLM（大規模言語モデル）を使ったアプリを組み立てる部品が揃っています。その中でも「Agent（エージェント）」は特に便利な機能で、LLMが自分で「どのツールをどの順番で使うか」を判断し、複数ステップの問題を解いてくれます。

普通のチャットボットとの違いをひとことで言うと：

普通のチャットボット → LLMに質問 → 答えが返ってくる（1回のやりとり）
LangChain Agent → LLMが「何をすべきか考える」→「ツールを呼ぶ」→「結果を見てまた考える」→ 最終的な答えを返す

この「考える → 行動する → 観察する」のループを ReAct（Reasoning + Acting）と呼びます。図にするとこんなイメージです。

LangChain Agent のデータフロー（Tools + Memory の ReAct ループ概念図）

前提環境

本記事は以下の環境で検証しています。インストール手順は ubuntu:24.04 の Docker公式イメージで実際にコマンドを流して確認しました。

項目	バージョン / 設定	備考
OS	Ubuntu 24.04.4 LTS	Docker `ubuntu:24.04` / VPS どちらでも可
Python	3.12.3	Ubuntu 24.04 に標準搭載
langchain	1.3.9	2026-06-15 実測（最新安定版・1.x 系）
langgraph	1.2.5	Agent と Memory の土台
LLMバックエンド	Ollama（ローカル）	APIキー不要・完全無料

先に Ollama のセットアップが必要です

本記事ではLLMバックエンドに Ollama を使います。まだインストールしていない場合は、先に「Ollama on Ubuntu インストールガイド」をご覧ください。ollama pull llama3.2:1b のように、軽量モデルを1つダウンロードしてから続きを進めてください。

インストール手順

手順1：python3-venv をインストールする

Ubuntu 24.04 では PEP 668 という仕様により、pip install をシステムに直接実行するとエラーになります。正直、ここは初心者が必ず一度はハマるポイントです。仮想環境（venv）を使うのが正しいやり方なので、まず venv 用のパッケージを入れます。

ubuntu@server: ~

$ sudo apt update && sudo apt install -y python3 python3-venv python3-full
Reading package lists… Done
Setting up python3-venv (3.12.3-0ubuntu2.1) …
Setting up python3-full (3.12.3-0ubuntu2.1) …
$ python3 –version
Python 3.12.3

もし venv を作らずに pip install langchain を直接叩くと、次のように externally-managed-environment エラーで止まります（実際に ubuntu:24.04 で再現したログです）。

ubuntu@server: ~

$ pip install langchain
error: externally-managed-environment
× This environment is externally managed
╰─> If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
See PEP 668 for the detailed specification.

手順2：仮想環境を作成して有効化する

~/lc-env という名前の仮想環境を作成します。ここだけは順番を間違えると動きません。activate を実行してからでないと、インストールしたパッケージが分離されません。

ubuntu@server: ~

$ python3 -m venv ~/lc-env
$ source ~/lc-env/bin/activate
(lc-env) $
# プロンプトに (lc-env) が表示されたらOK

手順3：LangChain パッケージをインストールする

Ollamaを使うので langchain-ollama も一緒に入れます。2026-06-15 時点の実測では、ここで langchain 1.3.9 がインストールされました。依存として langchain-classic も一緒に入ってきます（後述しますが、これが「1.x で何が変わったか」を物語っています）。

ubuntu@server: ~ (lc-env)

(lc-env) $ pip install langchain langchain-community langchain-ollama
Collecting langchain…
Successfully installed langchain-1.3.9 langchain-classic-1.0.8
langchain-community-0.4.2 langchain-core-1.4.7 langchain-ollama-1.1.0
(lc-env) $ python3 -c “import langchain; print(langchain.__version__)”
1.3.9

Ubuntu 24.04 での LangChain インストール実ログ（PEP668エラー→venv→pip install、2026-06-15 実測）

インストールされた主要パッケージのバージョンをまとめると次のとおりです（pip show で取得した実測値）。

LangChain エコシステムの実測バージョン一覧（2026-06-15 実測）

重要：0.3.x 系の記事のコードはそのまま動きません

日本語のLangChain記事の多くは langchain 0.3.x 前提で、from langchain.agents import create_react_agent, AgentExecutor や from langchain.memory import ConversationBufferMemory を使っています。ですが 1.x ではこれらは標準パッケージから外れました。実際に 1.3.9 で import すると次のようになります。

ubuntu@server: ~ (lc-env)

(lc-env) $ python3 -c “from langchain.memory import ConversationBufferMemory”
ModuleNotFoundError: No module named ‘langchain.memory’
(lc-env) $ python3 -c “import langchain.agents as a; print([x for x in dir(a) if not x.startswith(‘_’)])”
[‘AgentState’, ‘create_agent’, ‘factory’, ‘middleware’, ‘structured_output’]
# 1.x の Agent は create_agent ひとつに集約された

つまり 1.x で覚えるのは、エージェントは create_agent、記憶は langgraph の InMemorySaver の2つだけ。むしろシンプルになりました。以降はこの新しい書き方で進めます。

Tools（ツール）を定義する

LangChain Agent の真価は Tools（ツール）にあります。ツールとは「エージェントが呼び出せる機能」のこと。電卓・Web検索・ファイル読み込みなど、Python 関数なら何でもツールにできます。

1.x では @tool デコレータを付けるのが一番シンプルです。関数の docstring（説明文）がそのままLLMへの「この道具の使い方」になるので、ここは丁寧に書きます。

ubuntu@server: ~ — tools.py

from langchain_core.tools import tool

@tool
def calculator(expression: str) -> str:
“””数式を計算して結果を返す。例: ’42 * 7′, ‘(100 + 8) / 2′”””
try:
return str(eval(expression, {“__builtins__”: {}}, {}))
except Exception as e:
return f”Error: {e}”

@tool
def word_count(text: str) -> str:
“””与えられた英文の単語数を数えて返す。”””
return str(len(text.split()))

eval() を使う場合は {"__builtins__": {}} のように組み込み関数を必ず制限してください。これを省くと、悪意のある入力でOSコマンドが実行される危険があります。本番では simpleeval や numexpr など専用の数式パーサーを使うのが安全です。

create_agent で Tools+Memory 付きエージェントを実装する

いよいよ本題です。LangChain 1.x では create_agent ひとつで、ツールを使い、会話も覚えるエージェントが作れます。Memory は langgraph の InMemorySaver を checkpointer に渡すだけです。

①エージェントのコード全体

ubuntu@server: ~ — agent_main.py

from langchain.agents import create_agent
from langchain_core.tools import tool
from langchain_ollama import ChatOllama
from langgraph.checkpoint.memory import InMemorySaver

# 1. ツール（@tool デコレータで定義）
@tool
def calculator(expression: str) -> str:
“””数式を計算して結果を返す。例: ’42 * 7′”””
try:
return str(eval(expression, {“__builtins__”: {}}, {}))
except Exception as e:
return f”Error: {e}”

# 2. LLM（Ollama）の初期化
llm = ChatOllama(
model=”llama3.2:1b”, # ollama pull 済みのモデル名
base_url=”http://localhost:11434″,
temperature=0,
)

# 3. Memory（会話履歴を保持するチェックポインタ）
checkpointer = InMemorySaver()

# 4. エージェント生成（これ1発で ReAct ループが組まれる）
agent = create_agent(
model=llm,
tools=[calculator],
system_prompt=”計算が必要なときは必ず calculator ツールを使ってください。”,
checkpointer=checkpointer,
)

# 5. 実行（thread_id で会話スレッドを指定）
cfg = {“configurable”: {“thread_id”: “demo”}}
result = agent.invoke(
{“messages”: [{“role”: “user”, “content”: “42かける7はいくつ？”}]}, cfg)
print(result[“messages”][-1].content)

旧 0.3.x の AgentExecutor(agent=..., memory=..., verbose=True) のような組み立ては不要です。create_agent が内部で LangGraph のグラフを構築し、ツール呼び出しのループを自動で回してくれます。

②エージェントの実行結果（実トレース）

実際に動かすと、戻り値の messages に Human → AI(tool_calls) → Tool → AI(最終回答) という ReAct のサイクルが入っています。gpt-oss:20b で実行した実測トレースが以下です。

ubuntu@server: ~ (lc-env) — エージェント実行トレース

(lc-env) $ python3 agent_main.py # messages を順に表示
[human] 42かける7はいくつ？ calculator ツールを使って。
[ai] tool_calls=[calculator(expression=’42 * 7′)]
[tool] calculator → ‘294’
[ai] 42 × 7 は 294 です。
# 応答 2.9 秒（ツールを選ぶ→実行→結果を読んで回答）

create_agent が Tool を呼ぶ実トレース（langchain 1.3.9 + Ollama、2026-06-15 実測）

LLMがいきなり答えを言うのではなく、「calculator というツールに 42 * 7 を渡す」と自分で判断し、返ってきた 294 を読んでから最終回答しているのがポイントです。これがエージェントの動きです。

Memory（会話履歴）が効いているか実測する

Memory は「前の会話を覚えておく」仕組みです。1.x では InMemorySaver が会話を thread_id ごとに保存します。本当に覚えているのか、同じ thread_id で2ターン会話して確かめました。

ubuntu@server: ~ (lc-env) — memory_test.py

cfg = {“configurable”: {“thread_id”: “mem”}}
# 1ターン目：名前と趣味を伝える
agent.invoke({“messages”: [{“role”: “user”,
“content”: “私の名前はTaroです。趣味はLinuxです。覚えておいてください。”}]}, cfg)
# 2ターン目：同じ thread_id で思い出させる
r = agent.invoke({“messages”: [{“role”: “user”,
“content”: “私の名前と趣味は何でしたか？”}]}, cfg)
print(r[“messages”][-1].content)
あなたのお名前は Taro で、趣味は Linux です。

名前も趣味も正しく思い出しました。さらに checkpointer.get(cfg) でチェックポイントの中身を見ると、human / ai / human / ai の4メッセージが保存されていました。一方、別の thread_id で同じ質問をすると「お名前を知ることができません」と返ってきます。会話がスレッドごとにきちんと分離されている証拠です。

InMemorySaver による会話記憶のスレッド分離検証（2026-06-15 実測）

実際に動くチャットUIで触ってみる

コードと出力だけだと実感が湧きにくいので、上のエージェントを Flask で包んだ簡単なチャット画面を作って、ブラウザから実際に話しかけてみました。下は gpt-oss:20b をバックエンドにして動かしている本物の画面です。

「1980円の8%税込はいくら？」と聞くと、エージェントが calculator ツールを 1980*1.08 で呼び出し、2,138.40円と正しく答えています（黄色い枠が実際のツール呼び出しの記録です）。

LangChain Agent チャットUI：Calculator ツールで税込計算（Playwright 実撮影 screenshot、2026-06-15）

続けて「私の名前はTaroです」と伝えてから「私の名前を覚えていますか？」と聞くと、ちゃんと「はい、タロウさんですね」と返ってきます。Memory が効いているのがブラウザ越しにも確認できます。

チャットUIで会話記憶が効いている様子（Playwright 実撮影 screenshot、2026-06-15）

Ollama ローカル LLM との接続設定

エージェントの裏で動いている Ollama の確認方法です。起動していれば base_url のデフォルト（http://localhost:11434）で繋がります。

ubuntu@server: ~

$ curl -s http://localhost:11434/api/tags | python3 -m json.tool | grep ‘”name”‘
“name”: “llama3.2:1b”,
“name”: “gpt-oss:20b”,
# ↑ ダウンロード済みモデルが表示されればOK

VPS上でOllamaを動かしている場合は、ChatOllama(base_url="http://<VPS-IP>:11434") に変えれば、ローカルのLangChainからリモートのOllamaを叩けます。

本当に Ubuntu で動くのか、コンテナで最終確認

最後に、ここまでのコードがまっさらな Ubuntu 24.04 で本当に動くかを確かめるため、ubuntu:24.04 の Docker公式イメージの中で venv 作成 → pip install → エージェント実行までを通しで流しました（Ollama はホスト側、host.docker.internal 経由で接続）。

ubuntu@server: ~ — ubuntu:24.04 コンテナ内で実行

PRETTY_NAME=”Ubuntu 24.04.4 LTS”
LANGCHAIN_VERSION: 1.3.9 / PY: 3.12.3
[human] 42かける7はいくつ？
[ai] tool_calls=[calculator(expression=’42¡7′)]
[tool] Error: invalid character ‘¡’ (U+00A1)
[ai] 42 × 7 = 294

フレームワークの組み立て・Ollamaへの接続・ツール配線は問題なく動きました。ただし、この回は llama3.2:1b がツールに渡す式を 42¡7 と打ち間違え、calculator がエラーを返しています。それでもモデルが自力で 294 を計算し直して回答しました。小さいモデルはツールの引数を時々こうして崩します——これは捏造ではなく実際に出た結果です。

モデルサイズで挙動が変わります（実測）

同じコードでも、gpt-oss:20b は 1980*1.08 のような式も安定してツールに渡せたのに対し、llama3.2:1b は単純な掛け算は通っても、たまに引数を崩しました。エージェント用途では、軽さ重視なら 1B〜3B、安定性重視なら 7B 以上を選ぶのが目安です。VPSで動かすなら次の章のスペックも参考にしてください。

よくあるエラーと解決策

エラー①：externally-managed-environment（pip install が失敗する）

Ubuntu 24.04 で pip install langchain を直接実行すると PEP 668 エラーになります。解決策：「インストール手順」のとおり python3 -m venv ~/lc-env で仮想環境を作り、activate してから pip install してください。

エラー②：ModuleNotFoundError: No module named ‘langchain.memory’

0.3.x 向けの古いコードをそのまま動かすと出ます。1.x では ConversationBufferMemory は廃止されました。from langgraph.checkpoint.memory import InMemorySaver を使い、create_agent(..., checkpointer=InMemorySaver()) と thread_id の組み合わせに書き換えてください。同様に create_react_agent / AgentExecutor も create_agent に置き換えます。

エラー③：Connection refused（Ollama に繋がらない）

ubuntu@server: ~

httpx.ConnectError: [Errno 111] Connection refused
# Ollama が起動していない
$ sudo systemctl start ollama
● ollama.service: active (running)

VPS で本格運用する場合

ローカルで動作確認できたら、VPSに移してサービスとして動かすのが次のステップです。LangChain エージェントは FastAPI でラップして REST API として公開するのが一般的です。Ollama でローカルLLMを動かすので、選ぶ基準は RAM の量です。

VPS	最安プラン	vCPU / RAM	東京リージョン	Ollama 動作	評価
Vultr	$5/月〜	1 / 1GB	あり	◯（軽量モデル）	★★★★★
DigitalOcean	$6/月〜	1 / 1GB	なし（最寄シンガポール）	◯（軽量モデル）	★★★★☆
ConoHa VPS	¥880/月〜	1 / 1GB	あり	◯（軽量モデル）	★★★★☆

$5プランの 1GB RAM では、今回安定して動いた gpt-oss:20b のような大きめモデルはまず載りません。1GB帯なら llama3.2:1b や qwen2.5:0.5b のような軽量モデルを選びましょう。ツール呼び出しを安定させたいなら RAM 8GB 以上を借りて 7B クラスを動かすのが快適です。GPU付きVPSなら推論が桁違いに速くなります。

Vultr でLangChain AgentをVPSにデプロイする →

まとめ

Ubuntu 24.04 LTS に LangChain 1.x をインストールし、Tools と Memory を持ったエージェントを実装する手順を、実測ベースで解説しました。

Ubuntu 24.04 では python3 -m venv で仮想環境を作ってから pip install する（PEP 668 対応）
2026-06-15 時点の最新は langchain 1.3.9 / langchain-core 1.4.7 / langchain-ollama 1.1.0 / langgraph 1.2.5
1.x の Agent は create_agent、Memory は InMemorySaver + thread_id。旧 create_react_agent / ConversationBufferMemory は使えない
Ollama をバックエンドにすれば、APIキーなし・完全ローカルでエージェントが動く
ツールの安定動作はモデルサイズ次第。1Bは引数を崩すことがあり、安定性なら大きめのモデルを選ぶ