書籍『LangChainとLangGraphによるRAG・AIエージェント』をローカルで進める その2:LangfuseのPromptsとTracing

前回の記事で、LM Studioを利用してローカルでRAGを試してみました。

今回は、書籍でLangSmithが使われている部分について、ここもローカルで済ませるためにオープンソースのLangfuseとRAG評価フレームワークのRagasを組み合わせてみます。

LangSmithについて「書籍:LangChainとLangGraphによるRAG・AIエージェント 7.2 LangSmithの概要」には以下のように書いてあります。

LangSmithは大きく次の3種類の機能を持ちます。

1. Tracing (トレースの収集に関する機能)
2. Prompts (プロンプトの管理に関する機能)
3. Evaluation (評価に関する機能)

この3つの機能をLangfuseでやってみます。

終わってしまえば難しいところはないのですが、ちょいちょいハマったところがあったので、「⚠️」マークでメモを残しておきます。

Langfuseの準備

Langfuseのリポジトリからcloneして、docker-composeで起動するだけ。

$ docker compose up

localhost:3000にアクセス。sign upから適当なメールアドレスとパスワードでアカウントを作る。

「組織」作成後、設定画面でAPIキーを作る。

ここまででLangfuseの準備は完了!

Prompts(プロンプトの管理に関する機能)

LangfuseのPrompts機能を使ってみる。書籍の「4.3 Prompt template」に相当する。

この機能を使うと、LLMを使うアプリケーションのソースコードとは別にプロンプトの共有やバージョン管理ができる。

プロンプトをLangfuseに登録する

Langfuseの画面からプロンプトを作成する。作成後は以下のような画面。左メニューの「Prompts」を選択し、画面右上の「+ New prompt」から作成する。

作成画面で TextChat かを選択するところで Chat を選択する。そうすると以下のような入力フォームになる。システムプロンプトやユーザーのプロンプトを書ける。ここでは以下のように入力する。

  • system : ユーザーが入力した料理のレシピを考えてください。
  • user : {{dish}}

⚠️ ユーザープロンプトには {{dish}} とだけ書いてある。 {{ }} というの変数のプレースホルダーを表す。書籍で利用している LangSmith では { } がプレースホルダーらしい。最初は {dish} と書いていてうまく動かずハマった。LangSmithとLangfuseのライブラリの違いかな。

これで作成する。作成後、一覧画面からプロンプトを選択すると以下のような詳細画面になる。ここから編集ができるが、正確には編集ではなく新しいバージョンとして登録される。↓の画面では3つバージョンがある状態。

Langfuseに登録したプロンプトを使ってみよう

じゃあソースコードからこのプロンプトを使ってみる。

ライブラリを追加。

$ uv add langfuse==4.14.0

ソースコードは以下の通り。

⚠️ 書籍のLangSmithを使った例とほぼ同じなのだけど、 prompt.compile(dish="カレー") の部分が書籍では prompt.invoke({"dish": "カレー"}) と微妙に異なっていてハマった。

import os
from langfuse import Langfuse

os.environ["LANGFUSE_SECRET_KEY"] = "sk-..." # langfuseから取得
os.environ["LANGFUSE_PUBLIC_KEY"] = "pk-..." # langfuseから取得
os.environ["LANGFUSE_BASE_URL"] = "http://localhost:3000"
langfuse = Langfuse()

prompts_response = langfuse.api.prompts.list()

print("Langfuseに登録されてるプロンプト一覧")
for p in prompts_response.data:
    print(f"- '{p.name}' (Label: {p.labels})")

print("---")
prompt = langfuse.get_prompt("foo/recipe")
prompt_value = prompt.compile(dish="カレー")
print(prompt_value)

実行!ユーザープロンプトにプレースホルダーとして登録してあった {{dish}} が、 prompt.compile(dish=カレー) によって置き換わっていることが分かる。

$ uv run langfuse_prompt.py
Langfuseに登録されてるプロンプト一覧
- 'foo/recipe' (Label: ['latest', 'production'])
---
[{'role': 'system', 'content': 'ユーザーが入力した料理のレシピを考えてください。'}, {'role': 'user', 'content': 'カレー'}

Tracing (トレースの収集に関する機能)

次はTracingを試す。書籍の「5.1 Runnbable と RunnableSequence - LCELの最も基本的な構成要素」に相当する。

LangChain の LCEL( | で繋ぐ記法)で実装する。 invoke() にLangfuseの CallbackHandler を渡すだけでLangfuseの画面で処理をトレースできる。

⚠️ | で繋げられるようにLangfuseから取得したpromptを変換する。

# Prompt Template
import os
from langfuse import Langfuse
from langchain_core.prompts import ChatPromptTemplate

os.environ["LANGFUSE_SECRET_KEY"] = "sk-..." # langfuseから取得
os.environ["LANGFUSE_PUBLIC_KEY"] = "pk-..." # langfuseから取得
os.environ["LANGFUSE_BASE_URL"] = "http://localhost:3000"
langfuse = Langfuse()
langfuse_prompt = langfuse.get_prompt("foo/recipe")
prompt_messages = langfuse_prompt.get_langchain_prompt() # プロンプトのListを取得する
prompt = ChatPromptTemplate.from_messages(prompt_messages) # LangChain用のPromptTemplateに変換する



# Chat model
from langchain_openai import ChatOpenAI
model = ChatOpenAI(
    base_url = "http://localhost:1234/v1",
    api_key = "dummy",
)



# Output Parser
from langchain_core.output_parsers import StrOutputParser
output_parser = StrOutputParser()


# チェイン
chain = prompt | model | output_parser


# LangfuseのTracing
from langfuse.langchain import CallbackHandler
callback_handler = CallbackHandler()


# 実行
output = chain.invoke({"dish": "カレー"}, config={"callbacks": [callback_handler]})
print(output)

LM Studioのサーバーを起動させ(モデルは openai/gpt-oss-20b をLoadした)、実行してみる!と、Langfuseの画面、左メニューの「Tracing」から見れた!書籍では色々なチェインの組み方でRAGを使う処理を工夫するのだけど、Tracingで見れるのは楽しかった。

ちなみに出力は以下の通り。しっかりカレーのレシピが出ました。

% uv run lcel_langfuse.py
## ざっくりした日本風カレーのレシピ

| ステップ | 内容 |
|--------|------|
| 1. 下ごしらえ | 野菜・肉を切る |
| 2. カレールー作り | 油で炒めてからルーを入れる |
| 3. 煮込み | 水・コク材でじっくり煮る |
| 4. 盛り付け | ご飯とともに仕上げ |

---

### 1️⃣ 下ごしらえ(10分)

| 食材 | 量 | カット例 |
|------|----|----------|
| 鶏もも肉(または牛ひき肉) | 300 g | 1.5 cm角 |
| 玉ねぎ | 2個 | 薄切り |
| にんじん | 1本 | 斜め薄切り |
| ジャガイモ | 2個 | 1.5 cm角 |
| ピーマン | 1個 | くし切り |
| しいたけ | 4枚 | スライス |
| ニンニク | 1片 | みじん切り |
| 生姜 | 1片 | みじん切り |

> **ポイント**
> - 玉ねぎは焦げないように、弱火でじっくり炒めると甘みが出ます。
> - 皮をむいたジャガイモは水にさらしておくと、余分なでんぷんが落ちてテクスチャーが良くなります。

---

### 2️⃣ カレールー作り(15分)

1. **フライパンに油**
   鶏肉または牛ひき肉を入れ、表面が白っぽくなるまで中火で炒める。
   *(牛ひき肉の場合は、余分な脂を軽く切り落とす)*

2. **野菜を加える**
   玉ねぎ、にんじん、ジャガイモ、ピーマン、しいたけを順に加え、5分ほど炒める。
   *玉ねぎが透き通って甘みが出たら次へ。*

3. **にんにく・生姜を投入**
   1〜2分炒めて香りが立ったら、次にカレールーを入れる。
   ここで **市販のルウ**(カレー粉+小麦粉ベース)を使うと簡単。
   - ルーは **10 g × 3〜4個**(約30–40 g)を目安。
   - ルーの粒が大きい場合は、**少量の熱湯で溶かしてから加えると滑らかに仕上がります。**

4. **水を注ぐ**
   ルーが完全に溶けたら、**1.5 Lの水**(またはチキンブイヨン)を加え、全体を混ぜる。
   *水の量はお好みで調整可能です(濃いめにしたいなら少なめ)。*

---

### 3️⃣ 煮込み(20〜30分)

1. **蓋をして弱火**
   15分ほど煮込み、野菜が柔らかくなるまで待つ。
   - 途中で**火を強めて沸騰させ、アク抜き**も忘れずに。

2. **コクを加える**
   - みりん大さじ1、醤油小さじ2、塩少々(約5 g)を加える。
   - さらに**牛乳または生クリーム大さじ3**を加えるとまろやかになります。
   - お好みで **カレー粉大さじ1** も追加してスパイシーに。

3. **仕上げの味付け**
   - 味が足りない場合は、砂糖小さじ1〜2で甘味を調整。
   - **レモン汁小さじ1** で酸味を加えると、風味が引き締まります。

---

### 4️⃣ 盛り付け(5分)

1. **ご飯**
   - 蒸し米を皿に盛り、カレーを上からかける。
   - ご飯は**白米**でも、**玄米**や**雑穀米**でも◎。
2. **トッピング**(任意)
   - パクチー、ゆで卵の黄身を割り入れる。
   - **ピクルス**や**カレーパン**を添えると、味のコントラストが楽しめます。

---

## さらにアレンジしたい方へ

| アレンジ | 方法 |
|----------|------|
| **ベジタリアン** | 肉を外し、豆(レンズ豆やひよこ豆)を加える。 |
| **低糖質** | ジャガイモの代わりにカリフラワーを使用。 |
| **スパイシー** | ターメリック・カイエンペッパーを大さじ1ずつ追加。 |
| **フルーツ風味** | りんごのピューレを大さじ2入れ、甘みと酸味を追加。 |

---

### まとめ

- **下ごしらえ**で食材の味を引き出すことが重要。
- **ルーの溶かし方**を工夫すると、ムラなく滑らかなカレーに仕上がります。
- **最後の味付け**で自分好みの濃さ・スパイシーさを調整できます。

これで、誰でも手軽に作れる本格的な日本風カレーが完成です!ぜひお試しください。

おしまい

LangfuseのPrompts機能を使ってGUIで管理したプロンプトを、そのままローカルLLMに渡し、その実行ログをLangfuseのTracing機能で確認することができました!

次回は、Langfuseの「Evaluation(評価に関する機能)」を使ってRAGの評価に挑みます。

書籍『LangChainとLangGraphによるRAG・AIエージェント』をLM Studioを使ってローカルで進める

『LangChainとLangGraphによるRAG・AIエージェント』という本を読み進めていました。 この本ではOpenAIのAPIやLangSmithを使うのが標準になっているのですが、APIの課金を気にせずローカル環境で試行錯誤したかったので、LM Studioを利用してどこまでいけるかやってみました、という日記です。

今回は、1章〜4章(LLMの基本、Vision、Function Calling、RAG)までの内容をローカルLLMに置き換えて実装したメモ。

動かしたPCは、MacBook Air M2です。

LM Studioの準備

LM Studioをインストール。LLMは gpt-oss-20b をダウンロード。LM StudioでローカルにAPIサーバーを立てる。

このようにGUIでモデルをダウンロードしてサーバーを起動するだけで、OpenAI互換のWeb APIが使える。

curl でテストしてみる。

$ curl -X POST http://127.0.0.1:1234/v1/chat/completions \
     -H "Content-Type: application/json" \
     -d '{
           "model": "openai/gpt-oss-20b",
           "messages": [
               {"role": "system", "content": "You are a helpful assistant."},
               {"role":"user","content":"こんにちは!"}
           ],
           "max_tokens": 200
         }'
{
  "id": "chatcmpl-hjvrqbovlqfrylx9x35ee",
  "object": "chat.completion",
  "created": 1784507745,
  "model": "openai/gpt-oss-20b",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "こんにちは!今日はどんなことに興味がありますか?お気軽にお話しくださいね。",
        "reasoning": "Need to respond in Japanese friendly greeting.",
        "tool_calls": []
      },
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 69,
    "completion_tokens": 39,
    "total_tokens": 108,
    "completion_tokens_details": {
      "reasoning_tokens": 8
    }
  },
  "stats": {},
  "system_fingerprint": "openai/gpt-oss-20b"
}

ちゃんとレスポンスが返ってきた!

書籍の 『2.5 Chat Completions API』の最初のPythonのコードを試す。書籍では Google Colab を使ってるが、ローカルで uv を使って動かすことにする。

$ uv init sample_proj
$ uv add openai==1.40.6

main.pyに実装する。違いは OpenIAI コンストラクタに base_urlapi_key をセットするだけ。 api_key はLM Studioで認証なしにしている場合は適当な文字列を指定すればいい。

from openai import OpenAI

client = OpenAI(
  base_url = "http://localhost:1234/v1",
  api_key = "dummy",
)
response = client.chat.completions.create(
    model = "openai/gpt-oss-20b",
    messages = [
        {"role": "system", "content": "You are a helpful assistat."},
        {"role": "user", "content": "こんにちは!私はジョンと言います!"},
    ],
)
print(response.to_json(indent=2))

実行!

$ uv run main.py
{
  "id": "chatcmpl-c6zo9zzwrmbgy8mnvxzh7",
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "logprobs": null,
      "message": {
        "content": "こんにちは、ジョンさん!  \n私はChatGPTです。どんなご質問やお手伝いが必要でしょうか?お気軽にどうぞ!",
        "role": "assistant",
        "tool_calls": [],
        "reasoning": "User greeting in Japanese. Should respond politely, introduce assistant."
      }
    }
  ],
  "created": 1784509758,
  "model": "openai/gpt-oss-20b",
  "object": "chat.completion",
  "system_fingerprint": "openai/gpt-oss-20b",
  "usage": {
    "completion_tokens": 54,
    "prompt_tokens": 89,
    "total_tokens": 143,
    "completion_tokens_details": {
      "reasoning_tokens": 12
    }
  },
  "stats": {}
}

うむ、動いてる。

Visionを使った画像解析

次は画像解析。さっきは gpt-oss-20b を使っていたけれど、このモデルは画像をインプットすることができない。LM StudioでロードするモデルのCapabilitiesに「Vision」があるかどうかで判別できる。

gpt-oss-20b は以下のページでも確認できて、Capabilitiesに「Vision」はない。

Modell Catalog ページgemma-4-26b-a4b-qat が「Vision」に対応していたので、使ってみることにする。

LM Studioで、 gemma-4-26b-a4b-qat をダウンロードして、 Local Server から gpt-oss-20b をEjectしてから gemma-4-26b-a4b-qat をLoadする。

最近ふらっと長野に行ったときに食べたラーメンの写真を解析させてみよう。

messages で画像のURLを指定する。

image_url = "https://i.gyazo.com/90235c2479880102647427002ddedb40.jpg"
response = client.chat.completions.create(
    model = "openai/gpt-oss-20b",
    messages = [
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "画像を説明してください"},
                {"type": "image_url", "image_url": {"url": image_url}},
            ],
        },
    ],
)

しかし、これではダメ。以下の400エラーが返ってきた。

Openai.BadRequestError: Error code: 400 - {'error': "'url' field must be a base64 encoded image."}

エラーメッセージの通り、画像をBASE64文字列に変換してからパラメータに指定してみる。 $ uv add requests してからmain.pyを書き換える。

import base64
import requests
image_url = "https://i.gyazo.com/90235c2479880102647427002ddedb40.jpg"
image_base64 = base64.b64encode(requests.get(image_url).content).decode("utf-8")
response = client.chat.completions.create(
    model = "google/gemma-4-26b-a4b-qat",
    messages = [
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "画像を説明してください"},
                {"type": "image_url", "image_url": {"url": f"data:image/jpg;base64,{image_base64}"}},
            ],
        },
    ],
)
print(response.choices[0].message.content)

実行結果はこんな感じ。

% uv run main.py
白いボウルに入ったラーメンのクローズアップ写真です。

ラーメンの詳細は以下の通りです:
* **スープ:** 濃厚そうな白濁したスープ。                                                                                                                                   * **トッピング:** もやし、キャベツ、そしてピンクと白の渦巻き模様が特徴的な「なると」が乗っています。
* **器:** 白い陶器のボウルで、縁には日本語で「みんなのラーメン」という文字と「WELCOME」という英語のロゴが入っています。ボウルは赤い皿の上に置かれています。
* **スプーン:** 黒いプラスチック製のレンゲがボウルの中に添えられています。

背景はぼやけていますが、木製のテーブルの上にあり、調味料入れやコップなどが写っています。全体的に、明るいレストランでの食事の風景です。

プロンプトを変えて 画像を説明してください ではなく 食材の一覧を `['A', 'B', ...]` という形式で出力してください に変更してみる。ちゃんとパース可能な配列形式で出力された。なかなか良い。

% uv run main.py
['麺', 'スープ', 'キャベツ', 'もやし', 'なると', 'にんじん', 'きのこ']

Vision を使うと重くなる

gemma-4-26b-a4b-qat のVisionを使うとpcが一時的に重くなる。 gemma-4-12b-qat にすると重くなることは無くなるけど処理時間が長くなる。モデル名に含まれている a4b は Active 4 Billiton の略で、モデルのパラメータは26b (260億 × パラメータ1つのサイズ4bit = 13GB) なんだけど実行時は 4b (4億 × パラメータ1つのサイズ4bit = 2GB) で済む、ということみたい。

しかし、Visionを使う場合はどうも重くなる、確認するとメモリが不足していてスワップが発生している。Visionを使うと4bで収まってなくてメモリが足りないということかなぁと思いながら、AIさんに聞きながら調べてみた。a4bではMoE(Mixture of Experts)という構造になっていてVisionを使う場合は別のエンコーダーを動かしているらしく、これでVRAMをたくさん使うのかな、と想像したけど腑に落ちるところまで辿り着けず。詳しく知りたい時はちゃんと調べるということで。。

他に gemma-4-e4b というモデルもある。e4bだと軽いし回答も速い。推論の精度は弱くなるんだと思う。

gemma-4-e4b での実行結果。

これは、具沢山の温かそうなスープがたっぷり入ったボウルのクローズアップ写真です。

**【詳細な説明】**

*   **料理の全体像:** 明るいベージュ色の、クリーミーで優しい色合いのスープが特徴的です。熱々でホッとできるような、食欲をそそる一皿に見えます。
*   **具材:** 様々な野菜が豊富に使われています。
    *   中央には、大きな鮮やかな緑色のレタス(またはキャベツ)の葉が配置されています。
    *   白くて細長い野菜(豆苗や春雨のようなもの)がたっぷりと入っており、ボリューム感があります。
    *   オレンジ色の細切りにされたニンジンが彩りを添えています。
    *   スープの中には、薄いキノコやその他の具材が確認できます。
    *   特に目を引くのは、中央のレタスの上に置かれた、淡いピンク色の花のような形の飾り(おそらく、装飾的な野菜や竹の子など)です。
*   **盛り付け:** 料理はシンプルな白いボウルに盛られており、そのボウルが鮮やかな赤色の皿(または受け皿)の上に置かれています。
*   **雰囲気:** 背景はややぼやけていますが、木製のテーブルの上で撮影されており、カフェやレストランでの食事の様子を捉えています。ボウルの縁には「みんなの WEL COME」といった
文字が見えます。

全体として、栄養バランスが良く、見た目も華やかな、心が温まるスープ料理です。

食材の方。

`['クリーミーなスープ', 'ガラス麺(ビーフン)', 'キャベツ', 'ニンジン', 'ハムまたは肉の切れ端', 'キノコ類(または暗色の具材)', 'エディブルフラワー']`

うーん、確かに微妙かも?

Function Calling

特に問題なく書籍のコードがLM Studioでも動いた。

RAG (Retrieval-Augmented Generation)

次はRAG。書籍では OpenAI の Embedding API を使ってテキストをベクトル化しているが、LM Studioでやる。LM Studioのサーバーに推論のモデルとは別に追加で Embedding 用のモデルをLoadする。LM Studioに最初から用意されている?っぽい text-embedding-omic-embed-text-v1.5 をLoadする。

↓こんな感じで2つのモデルがロードされている状態。

Vector storeには書籍の通りChromaを利用する。

必要なライブラリを追加。

$ uv add langchain-core==0.3.0 langchain-openai==0.2.0 langchain-community==0.3.0 GitPython==3.1.43 langchain-text-splitters==0.3.0 langchain-chroma==0.1.4

諸々のライブラリはバージョンがもっと新しくなってる。書籍で指定されているバージョンだと以下のエラーが出た。

書籍のバージョンで動かすことを優先するため、 httpx をバージョンを下げる。

$ uv add "httpx<0.28.0"

書籍の「4.6 LangChain の RAG に関するコンポーネント」を参考にソースコードを書く。

# Document loaderでドキュメントの読み込み
# このサンプルでは、Gitリポジトリからmdファイルを読み込む
from langchain_community.document_loaders import GitLoader

def file_filter(file_path: str) -> bool:
    return file_path.endswith(".md")

loader = GitLoader(
    clone_url="https://github.com/langchain-ai/langchain",
    repo_path="./langchain",
    branch="master",
    file_filter=file_filter,
)
raw_docs = loader.load()
print(f"len(raw_docs) = {len(raw_docs)}")


# Document transformerで何らかの変換
# このサンプルでは、1000文字で分割する
from langchain_text_splitters import CharacterTextSplitter

text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=0)
docs = text_splitter.split_documents(raw_docs)
print(len(docs))
print(f"len(docs) = {len(docs)}")

# LM Studio の Embedding model を利用
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(
    base_url="http://localhost:1234/v1",
    api_key = "dummy",
    model="text-embedding-nomic-embed-text-v1.5", # Embeddingに対応したモデル
    check_embedding_ctx_length=False,
)


# Vector store (Chrome) にドキュメントをベクトル化して保存

from langchain_chroma import Chroma

db = Chroma.from_documents(docs, embeddings)


# retriever を使ってドキュメントを取得
retriever = db.as_retriever()
query = "perplexityからデータを読み込むためのDocument loaderはありますか?"
context_docs = retriever.invoke(query)
first_doc = context_docs[0]
print(f"len(context_docs) = {len(context_docs)}")
print(f"metadata = {first_doc.metadata}")
print(first_doc.page_content)

実行する。

% uv run rag.py

len(raw_docs) = 29
Created a chunk of size 1037, which is longer than the specified 1000
Created a chunk of size 1037, which is longer than the specified 1000
Created a chunk of size 1455, which is longer than the specified 1000
len(docs) = 135
Failed to send telemetry event ClientStartEvent: capture() takes 1 positional argument but 3 were given
Failed to send telemetry event ClientCreateCollectionEvent: capture() takes 1 positional argument but 3 were given
Failed to send telemetry event CollectionQueryEvent: capture() takes 1 positional argument but 3 were given
len(context_docs) = 4
metadata = {'file_name': 'README.md', 'file_path': 'libs/partners/perplexity/README.md', 'file_type': '.md', 'source': 'libs/partners/perplexity/README.md'}
# langchain-perplexity

[![PyPI - Version](https://img.shields.io/pypi/v/langchain-perplexity?label=%20)](https://pypi.org/project/langchain-perplexity/#history)
[![PyPI - License](https://img.shields.io/pypi/l/langchain-perplexity)](https://opensource.org/licenses/MIT)
[![PyPI - Downloads](https://img.shields.io/pepy/dt/langchain-perplexity)](https://pypistats.org/packages/langchain-perplexity)
[![Twitter](https://img.shields.io/twitter/url/https/twitter.com/langchain_oss.svg?style=social&label=Follow%20%40LangChain)](https://x.com/langchain_oss)

Looking for the JS/TS version? Check out [LangChain.js](https://github.com/langchain-ai/langchainjs).

## Quick Install

```bash
uv add langchain-perplexity
```

## 🤔 What is this?

This package contains the LangChain integration with Perplexity.

## 📖 Documentation

Chromaから該当のドキュメントがちゃんとヒットした!

おしまい

ここまでで、ローカルLLMを使ったRAGの構築まではうまくいきました!

次は「プロンプトを変えたり、検索件数を変えたときに、本当に精度が良くなっているのか?」をどう評価すればいいのか。書籍ではここでLangSmithを利用しますが、次はこの部分をOSSのLangfuseを使ってローカルで試していこうと思います。

RustでC言語コンパイラ実装の途中経過メモ

2025年、学ぶプログラミング言語としてRustにしました。このあたりの話は過去記事に書きました。なんとなくの静的型検査が実装できたところで、一旦中断!(ちょっと飽きてきたのもある)

将来、再開した時の自分宛にメモ書きを残しておく、という日記です。

構文解析までは「Go言語でつくるインタプリタ」を参考にしながら順調に進みましたが、意味解析でASTを辿りながらツリー構造を構築するところでRustの洗礼を浴びました。。

過去記事でインプットは以下の1冊、アウトプットはC言語コンパイラと書いていましたが、

他にも色々参考にさせていただきました。参考資料&書籍は以下のとおりです。

処理の流れ

Rustのファイルの置き方、というか mod の使い方に最初は戸惑った。今でもあんまり分かってない気がする。「プログラミングRust」を参考に、最終的に以下の構成に落ち着いた。

src
├── bin
│   └── foo.rs
├── lexer
│   └── token.rs
├── lexer.rs
├── lib.rs
├── parser
│   ├── ast.rs
│   ├── parser_for_expressions.rs
│   ├── parser_for_external_items.rs
│   └── parser_for_statements.rs
├── parser.rs
├── sema
│   ├── env.rs
│   ├── scope_checker.rs
│   ├── semantic_checker.rs
│   └── type_checker.rs
└── sema.rs
// lib.rs
mod lexer;
mod parser;
mod sema;

pub fn compile(input: &str) {
    let mut parser = create_parser(input);
    let ast = parser.parse_program();
    sema::semantic_analyze(ast)
    // TODO:
}

コンパイラのフェーズごとにモジュールを作り、データを流していく。

  • lexer
    • 入力となるC言語ソースコード文字列 → トークン列
  • parser (構文解析)
    • トークン列 → AST
  • sema (意味解析)
    • scope_checker
      • AST → スコープツリー
    • semantic_checker
      • AST → 文や式の妥当性チェック(トップレベルに break がないか、 return がグローバルにないか、などなど)
    • type_checker
      • AST + スコープツリー → 静的型検査

構文解析

lexer, parserあたりの実装は、「Go言語でつくるインタプリタ」を参考にした。parserの処理はGoと比べてRustだから有利/不利、というのは特に感じなかった。

Rustのenum

ASTの表現はRustの方がしやすいと感じた。enumで代数的データ型を表現できるのがとても強力だった。パターンマッチで網羅性をコンパイル時に担保できる、かつ、Destructureで内部の値を各変数に分配できる。ソースコードがとても簡潔に書けるし読みやすい。

Rust最高!という気分。

Rustで再帰的なデータ構造

「Go言語でつくるインタプリタ」ではASTをExpressionを再帰的に参照するツリー構造で表現している。

type Node interface {
  TokenLiteral() string
}

type Expression interface {
    Node
}

...

type InfixExpression struct {
  Token token.Token
  Left Expression
  Operator string
  Right Expression
}
func (oe *InfixExpression) TokenLiteral() string { return oe.Token.Literal }

...

Rustではデータはスタックに置かれる。そのため、コンパイル時にメモリサイズが分かる必要がある。再帰的なデータ構造だと、どこまで再帰が続くか分からないためサイズが決まらないためコンパイルエラーになる。

pub enum Expression {
  ...
  Infix {
        operator: String,
        left: Expression,
        right: Expression,
  },
  ...
}

left , right をポインタにして、実体はスタックではなくヒープに置くようにすればいい。Rustでは Box<T> を使ってこれを実現できる。実体のサイズは不確定だが、ポインタのサイズは決まっているためスタックに置ける。

pub enum Expression {
  ...
  Infix {
        operator: String,
        left: Box<Expression>, // Expressionそのものではなく、ヒープを指すポインタ
        right: Box<Expression>,
  },
  ...
}

スタックに確保された Box<T> が解放されるタイミングで、ヒープに置かれた実体のメモリも解放される。

意味解析で壁にぶつかる

構文解析までは「Go言語でつくるインタプリタ」と大きな違いはなかったけど、この先が大きく違う。

「Go言語でつくるインタプリタ」ではASTを辿りながら式の評価を行う。ore-c-rustでは、ASTを辿りながら意味解析をする。意味解析では大きく2つのステップに分けてる。

  1. ASTを辿ってスコープツリーを構築し、変数名と型定義のマッピングをする
  2. ASTを辿って型解析をする

これをRustで実装するのが簡単ではなく、Rustコンパイラにたくさん怒られた。所有権と借用チェッカと仲良くならないといけない。

スコープツリーの構築

スコープとASTノード

「Go言語でつくるインタプリタ」では、ソースコード上に登場する変数や関数を格納しておくために Environment というstructを実装してる。 store map[string]Object で変数や関数を管理している。 outer で親スコープを持つ。

type Environment struct {
  store map[string]Object
  outer *Environment
}

func (e *Environment) Set(name string, val Object) Object {
  e.store[name] = val
  return val
}

func (e *Environment) Get(name string) (Object, bool) {
  obj, ok := e.store[name]
  if !ok && e.outer != nil {
    obj, ok = e.outer.Get(name)
  }
}

ASTの各ノードを辿りながら、新たな変数が登場したら Environment に追加していく。変数を取得する際は、まず自分自身から取得し、存在しなければ親スコープから取得することを試みる。

さらに、ASTを評価した際に Function というstructのオブジェクトを作り、このstructに関数スコープの Environment を持たせることで、関数本体を表すASTノードとスコープの関連づけをしている。直感的・シンプルで分かりやすい。

type Function struct {
  Parameters []*ast.Identifier
  Body       *ast.BlockStatement
  Env        *Environment
}

ここまででオブジェクトの関連は以下のようになる。

ある Environment が、 Function と子の Environment と2つのオブジェクトから参照されている。 Function 経由で参照される場合は変数が追加される時である可能性があるため書き込まれる。子の Environment から参照される場合は変数を探す時であるため書き込みはなく読み取りのみとなる。

これをRustでは簡単に表現できない!

借用チェッカ

Rustでは参照は借用と呼ばれ、いつか借り元へ返さないといけない。借用チェッカによっていくつかルールを守っているかどうかコンパイル時にチェックされる。

ルールの1つ:

  • アイテムの所有者に加えて以下のどちらかだけが存在できる
    • そのアイテムへの任意の数の不変参照
    • そのアイテムへの1つの可変参照
  • ただし、両方を持つことはできない

このルールによって所有者の操作も制限される。参照が存在する場合は、所有者であってもアイテムの更新はできない。所有者による更新とは言っても、一時的に可変参照を使って更新すると考えると納得できる(可変参照は1つしか取得できないため)。

上記のことから、先ほどの Environment の表現は子の Environment からの参照が存在する状態で、”関数”からも参照させて Environment に新たな変数を追加したいわけだが、追加するということは可変参照が必要なのだけど、一方で子から親への不変参照も必要。これはRustでは上記のルールによってコンパイルエラーになる。”関数”を Environment の所有者にしたとしても、これもコンパイルエラーで実現できない。

struct Environment<'a> {
  parent: &'a Environment // 不変参照
}
struct Function {
  environment: Environment // 所有
}

Goのように気軽にポインタを繋ぐ設計は破綻。だけど、Rustでもスマートポインタ( RcRefCell )を使うと近いことを実現できる。今回はRust学習のため、使わないことにした。

解決策:ID管理による疑似ポインタ

scope_checker.rsに実装。今回の実装では、 Environment 相当のstructを Scope と命名した。

では、スマートポインタを使わずにASTノードとスコープの関連づけをどうするか?

それは全ての Scope の所有権を持つ管理者( Env )を作り、各 Scope はID(数値)で管理するというアプローチにした。(Arenaパターンと呼ばれるパターンに近いような、そうでもないような)

Scope にIDを用意して、各 Scope では親 Scope のIDを持たせる。そして、 Env というstructを用意して全ての Scope の所有者にする。ASTを辿るときは Env の可変参照を持ち回る。

pub struct Scope {
  pub id: usize,

  // 親Scopeのid
  parent: Option<usize>,

  /// シンボル名と型名を対応表
  entities: HashMap<String, TypeRef>,
}

struct Env {
  scope_table: HashMap<usize, Scope>,
}

impl Env {
  fn find(&self, scope: &Scope, name: &str) -> Option<TypeRef> {
     // 引数の `scope` から、 `name` で指定された変数を探す
    let mut result = scope.find(name);
    ...
    let parent_id = scope.parent; // 見つからなければ `scope` から親ScopeのIDを取得する
    ...
    result = self.scope_table.get(parent_id).and_then(|p| p.find(name)); // `scope_table` から親Scopeを取得して、変数を探す
    // 繰り返し...
  }
}

さらに、ASTノードと Scope の関連づけも Env に持たせる。

struct Env {
  scope_table: HashMap<usize, Scope>,
  node_scope: HashMap<Node, usize>,
}

これでASTを辿りながら Scope を構築できる。同じ要領で、型名と型定義の解決もする。

※ 現状、型のテーブルを Env で管理してしまっているけど Scope で管理するように直すのが正しいはず。そうしないと、Cソースコードで関数内でtypedefを定義するとグルーバルスコープで同名のものが定義されていた場合にコンフリクトしてしまう。。

GoをベースにRustでの実装し直すというは、単なるロジックの移植ではなくメモリ管理とデータの所有権の再設計だった。GCなしでメモリを安全に扱うためにRustコンパイラが助けてくれるというのが少し分かった気がする。

型検査

型検査は「型システムのしくみ」という本で学んだことを実装した → 前回のブログ記事

担当しているのはtype_checker.rs。ASTを辿りながら各式が返す型を評価する。ここで上述のscope_checker.rsで構築したスコープツリーを利用する。ASTノードから Scope を取得 → Scope から変数定義を取得 → 変数定義から型定義を取得 → 取得した型定義を使って型検査する、という処理の流れ。

例えば int a = f(x); というCソースコードの文があったら、左辺の型定義と右辺の型定義を手に入れて、同じ型かどうかチェックする。

本を読むまではとてもハードルが高く感じていたのだけど、「型システムのしくみ」がとても良い本で勉強になったのでありがたい。

おしまい

再開した時の自分宛にメモはここまで!再開して次にやりたいことは、アセンブリを生成したい。

けど、その前にやった方が良さそうなことがあるなぁ。。

  • 型テーブルを Env じゃなくて Scope に持たせる
  • 再起的な関数定義いける?
  • プリプロセッサの対応(特にinclude)
  • printfとか(暫定的に組み込み関数にする?)
  • 中間表現(IR)はスキップで良いかな..