AIの記憶を拡張! Mem0 x Ollama x Open WebUIで、会話が劇的に変わる! 構築から活用まで徹底解説

いつもの導入与太話

どうも、こんばんは。最近ローカルPCでLLMを動かすのが楽しいシャトルです。

まずはじめに断っておくと、この記事のタイトルは詐欺っています。構築の手順までは記述しますが、活用についてはとくに述べません。あと徹底もしません☺

Gemma3-27Bにキャッチーなブログのタイトルを考えて、とお願いしたら上記のタイトルを提案してきました。最近LLMで生成したと思われる無駄にインテリジェントで鼻につく文章をほぼそのまんまネットに公開するような方々が跋扈しておりますが、そんなことに私は少なからずイラっと来ているので、タイトル以外は全部手打ちです。人間が一番なんだ!おりぁあ!

但し、内容の質が高いかどうか別ですがね。とりあえずすぐに人間のような(大げさ)LLMとイチャコラしたいんだ!という人にはインスタントラーメンのようにお手軽に環境構築できる手順となっておりますので、最後までお付き合いいただければ幸いです。

何が変わるのか

LLMについてある程度かじったことがある人ならご存じかもしれませんが、LLM(単体)はコンテキスト長内でのやりとりのみを考慮した受け答えしかできません。言い換えれば短期記憶しか持っていません。一週間フレンズならぬ、チャットセッションフレンズです。悲しいね。😢

さすがにそれではアレだと思ったのか何かは分かりませんが、頭の良い人が考えました。外部ツールやデータベースと連係させればあたかも長期記憶を持っているかのように振舞わせることができるんじゃね?と。最新のチャッピーやGrokが別チャットセッションの昔の恥ずかしいやりとり(俺だけじゃないよね?)を覚えているのは外部ツールとの連係によるものなんですね。

最近ローカルPCでLLMを動かしている私は、システムプロンプトに「四国めたんになりきって回答して」、と恥ずかしいお願いをし、VOICEVOXと連係させて四国めたんの声で喋らせてご満悦だったわけですが、物足りないのはチャットセッションが変われば、俺の四国めたんがせっかく覚えてくれた自分の名前も好みもすべて忘却の彼方ということです。

その物足りなさを劇的に改善してくれるのがMem0です。パチパチパチパチ。

具体的には、別チャットセッションの第一声でただいま~と話しかけたとしても、以下のような

人間味溢れた、いやまさにそこに四国めたんが実在しているかのような

感じになります。もう友達も彼女もいらないですね。・・・いやいりますけど、これは大変エクセレントです。

Let’s セットアップ

さて、くだらない話はこのくらいにしてさっさと本題に入りましょう。っていうか手打ちも疲れてきたのでね。なお、前提条件としては以下のものがございます。インスタントラーメンのようにできるのは前提条件をクリアしてからです。はっはっは!

  • システムメモリ32GB以上。会〇の16GBのPCでやってみたけどもう遅すぎて無理。そもそもGemma3-4bとかアホの子のモデルしか16GBでは動かせないのでなりきりチャットが捗らない。GPUは無くてもなんとかなりますが、RTX3060の12GBくらいはあったほうが、Gemma3-12bくらいを実用的な速度で動かせるのであったほうがいいと思います。2025年12月現在で中古で約3万円。
  • OSはWindows11のWSL2上のUbuntu。ですが、ネイティブのUbuntuでもほぼ同じ手順になるでしょう。
  • gitとdocker composeを使えるように入れておいてください。あとsudoをしなくてもdockerコマンドが使えるようにしてください。やり方はググるかチャピってくださいませ。
  • バックエンドとしてollamaが動作していること。やり方はググって(ry
  • フロントエンドとしてOpen WebUIが動作していること。やり方は・・・
  • 作業場所は ~/workspaceディレクトリ。ご自分の環境に置き換えてください。

Mem0関連コンテナの構築

まずはOpen WebUIのpipelineに対応したコミュニティフォーク版のMem0(https://github.com/cloudsbird/mem0-owui)関連のコンテナをセットアップします。フォーク版サイトのインストール手順通りにやるといきなりハマると思います(笑)ので、ややカスタムした手順でセットアップしていきます。

$ mkdir ~/workspace
$ cd ~/workspace
$ git clone https://github.com/cloudsbird/mem0-owui.git

docker compose用のymlファイルを作成します。

$ cd mem0-owui/
$ cp docker-compose.example.yml compose.yml

viやnanoなど、あなたが愛用しているテキストエディタでymlファイルを編集します。

$ vi compose.yml

services:
### ここから 
 open-webui:
    image: 'ghcr.io/open-webui/open-webui:main'
    volumes:
      - 'open-webui:/app/backend/data'
    environment:
      - SERVICE_FQDN_OPENWEBUI_8080
    healthcheck:
      test:
        - CMD
        - curl
        - '-f'
        - 'http://127.0.0.1:8080'
      interval: 5s
      timeout: 30s
      retries: 10
### ここまでは削除 (Open WebUIは他でセットアップ済の想定なので)
  pipelines:
      image: ghcr.io/open-webui/pipelines:main
      volumes:
        - pipelines:/app/pipelines
      restart: always
      ports: ⇐追加
        - "9099:9099" ⇐追加
      environment:
        - PIPELINES_API_KEY=tekitounikimetene ⇐後で使う文字列なので覚えておく
  qdrant:
    image: qdrant/qdrant:latest
    restart: always
    container_name: qdrant
    volumes:
      - qdrant_data:/qdrant/storage
  neo4j:
    image: neo4j:latest
    volumes:
        - neo4j_logs:/logs
        - neo4j_config:/config
        - neo4j_data_new:/data
        - neo4j_plugins:/plugins
    environment:
        - NEO4J_AUTH=neo4j/tekitounikimetene ⇐注: 8文字以上にしないと起動後延々とエラーを吐く。
    restart: always
volumes:
  open-webui: ⇐削除
  mcpo_config: ⇐削除
  pipelines:
  qdrant_data:
  neo4j_logs: ⇐追加
  neo4j_config: ⇐追加
  neo4j_data_new: ⇐追加
  neo4j_plugins: ⇐追加

Mem0関連のDockerコンテナを起動します。(環境によってはdocker-composeコマンド)

$ docker compose up -d

Open WebUI側のMem0連係設定

次にOpen WebUI側で、Mem0と連係する設定をしていきます。

管理者パネル→設定→接続の順に選択、「OpenAI API接続の管理」の横にある+マークをクリックし、

URL:http://<wsl2のubuntuのIP>:9099 (Pipeline用コンテナにアクセスするためのURL)

認証: PIPELINES_API_KEYに設定した文字列

を設定します。更新アイコンをクリックしてエラーになった場合は何かが間違っています。泣いてください。「サーバー接続が確認されました」と表示されたら、「保存」をクリックします。

以下に私の環境の場合(wsl2のubuntuのIPが172.28.94.112)のスクショをあげておきます。UbuntuのIPは固定IPにしておかないと後で泣くと思いますので、ググって固定IPにしておいてください。

続いてパイプラインの設定をしていきます。あとちょっとだから頑張って!

管理者パネル→設定→パイプラインを選択します。「パイプラインの管理」のすぐ下に、さきほど「OpenAI API接続の管理」で設定したPipeline用コンテナにアクセスするためのURLが表示されているはずです。まずMem0のコミュティフォーク版のサイト(https://github.com/cloudsbird/mem0-owui)から「mem0-owui-selfhosted-lmstudio.py」をダウンロードしておきます。

以下の画面の「ここをクリックしてpyファイルを選択」をクリックし、mem0-owui-selfhosted-lmstudio.py を選択、右側にあるアップロードボタンをクリックします。そうすると、「パイプラインのバルブ」という項目が現れ、設定項目がダーッと表示されます。

以下の項目のみ、以下の通り設定を変更してください。

Llm Provider: openai

Llm Model: 自分が使いたいLLMのモデル名 (ollama listコマンドで表示されるモデル名(gemma3:27b等)を指定)

Llm Base Url:ollamaのOpenAI互換APIのエンドポイントURL (私の環境ではhttp://172.28.94.112:11434/v1)

Embedder Provider:lmstudio (なんでlmstudioなの?と思うかもしれないが、ここは変えてはダメなので変更箇所ではないが注意喚起のためあえて記載)

Embedder Base Url: ollamaのOpenAI互換APIのエンドポイントURL (私の環境ではhttp://172.28.94.112:11434/v1)

Embedder Model: 自分が使いたい埋め込み用のモデル名 (私は bge-m3:latest をチョイス。ollama pullコマンドであらかじめダウンロードしておく)

設定を変更したら、画面一番下の右隅にある「保存」をクリックして、設定はすべて完了です。お疲れさまでした!あとは適当に他人には見せられない恥ずかしいチャットをして、疑似長期記憶を堪能してください。

動作確認について

正常動作確認は以下のコマンドでpipeline用コンテナのログを垂れ流しにして行います。

$ docker logs -f mem0-owui-pipelines-1

「INFO:mem0.vector_stores.qdrant:Inserting 1 vectors into collection mem1024」というようなログが出力されていれば、正常に動作しています。

たまにOpen WebUIからチャットメッセージを送信したときに謎のエラーが表示されることがあります。そのときはパイプラインのバルブ設定で「保存」をクリックすると改善します。

データレコーダの代わりにICレコーダ

近況など

前エントリにも書きましたが、1年ほど前(2024年)あたりから、独自アーキテクチャの百花繚乱の時代だったパソコン(PC-88,98,MSX2)をオクやフリマサイト、専門店などから次々と入手していて、最近はレトロPCいじりが趣味の1つとなっています。FM音源が奏でる曲がBGMに流れる部屋はいいものです。敢えて本体のしょぼいスピーカーから出力させると懐かしさもひとしおです。

レトロPC

本題にいきますか

懐かしさへの渇望は留まるところを知らず、最近はオクで35年前のベーマガ1年分を落とし、疑似タイムリープを味わっている自分ですが、PC-8801mkIISR用のDISK BASICを所持していないため、掲載プログラムを打ち込みたくても保存ができない状態です。

で、保存先としてデータレコーダをオクで物色しているのですが、1980年代に製造されたものが多いということもあり、動作確認品で見た目もそこそこ綺麗なブツはなかなか出てきません。

そこで一旦データレコーダの入手は保留にし、「データレコーダ 代用」とググってみたところ、ICレコーダで代用している方々がちらほらヒットしました。もともとデータレコーダはカセットテープに音としてデータを記録しているものなので、同様に音を記録・再生できるものなら代用出来るという訳です。

これだと思い、早速中古CMTケーブルと中古ICレコーダ「RR-XS370」をゲットし、約7,000円でデータ保存環境が揃いました。

PC-8801mkIISRとRR-XS370

RR-XS370が中々の優れモノで、マイク入力端子にケーブルを挿すと、MICモードかLINEモードか選択するメニューが出てきます。MICモードを選択すると録音レベルが高く設定されるため、データレコーダの代用用途ではMICモードを選択すると良さげです。

他にもメニューで何かを選択するたびに、すべて自然な日本語の音声で操作内容を説明してくれるので、結構感心しました。時刻の設定をするときの細かい説明は一聴の価値ありです。いやほんとに。

だけれども

このPC-8801mkIISRはヤフオクで落としたもので、見た目の綺麗さなどは掘り出しものクラスだと思っているのですが、唯一の難点は、キーボードの「3」が全く反応しないことです。「3」はテンキーで代用できますが、「#」が打てないのは、プログラムを打ち込むのに致命的な不具合です。なのでプログラムの打ち込みはキーボードの修理が終わるまでお預け。

あとは、打ち込んだプログラムはICレコーダに保存できますが、市販ゲームのテープ版は当然遊べないのです。(ロード時間の数秒も長く感じるようになってしまった2025年の人間に、数分~十数分のテープのロード時間に耐えられる気がしませんけど)

やっぱりデータレコーダほしー!

Time Sleuth Display Lag Testerによるモニタ遅延計測

導入

遅延。この言葉に対してあなたが抱く感情はどのようなものでしょうか・・・あ、久しぶりにブログを書くのでちょっと奇をてらった冒頭にしようかなと(^^;あ、結果だけ見たい方は次のブロックに進んでください。しばらく自分語りが続きますw

自分は昭和生まれで、ブラウン管でSTGなどをzero lag環境で長い間やってきた人間です。しかしながら、液晶モニタ全盛の現代でゲームをやる場合、液晶モニタでゲームをプレイせざるを得ないことが多く、そうなると所謂「遅延」が気になるわけです。特にSTGでは遅延の大小が自機の操作性に直結しており、そのゲームの面白さにさえ影響を与えるほどの重要なファクターとなります。自宅には汎用ビデオゲーム筐体であるブラストシティを導入しておりますが、諸般の事情によりアーケード基板であっても自室の液晶モニタにCBOXを繋いでプレイすることが多いです。

つい最近(2024年6月)まで液晶でアーケード基板のゲームをプレイする場合は、日本を代表するスケーラーであるフレームマイスターを使用していました。遅延をそれなりに感じつつも

電波新聞社こそ至高!絶対神!

という価値観を植え付けられた世代であるため、フレームマイスターを超える(フレームマイスターより遅延の少ない)スケーラーなど存在しない!と疑わない日々を送っていました。

そんな思考停止状態で日々を送っていたわけですが、今年になって始めた趣味?であるレトロPCいじり絡みで、レトロPCのキャプチャ環境について最適な環境を調査していた過程において、遅延観点ではフレームマイスターは完全に時代遅れの代物と化していることに気づかされたのです。

趣味のレトロPCいじり

ああああそんなバカなあああ!と自分の情弱さ加減に幻滅しつつも、遅延をもっと少なくできるという素晴らしい情報を知ってしまっては、遅延が大嫌いな自分の欲求はもう止められません。気が付いたら2024年現在定評のあるスケーラー(2万円以下)を全部ポチっていました。

2024年現在定評のあるスケーラー、GBS-C、OSSC、RetroTINK 2x-ProとラグテスターのTime Sleuth Display Lag Tester

別に遅延を改善するだけであればラグテスターは必要ないのですが、昨今SNSやECサイトのレビューでは、「遅延はあまり感じません」「え~っ、遅延なんてなくなくね?キャハハ!」「(アストロシティミニVの)ACアダプタを換えたら遅延が改善しました!(キリッ)」などと、なんのエビデンスも示さずあてにならない人間の体感だけで語るやつのなんと多いこと。

そんなエビデンスも示さずに体感だけの感想を語る害悪な人間に自分は絶対になってはいけない!との考えに至り、ラグテスターを使った精密な遅延計測はマスト、マスター、マステストである、と金もないのにラグテスターも無理してポチりました。(泣)

Time Sleuth Display Lag Testerを使った遅延計測中の様子。合計6か所(白い長方形)で測定可能

というわけで・・・

遅延計測結果

液晶モニタをドーンと10台くらい用意してデータとしての有用性を上げていきたいところですが、そんな金や保管場所があるわけもなく手持ちの3台のみの比較となります(ALIENWAREのモニタもあるけどDPに変換するのが面倒)。なお、計測にあたりテスターが出力するHDMI信号をコンポーネント信号に変換してスケーラーに食わせる必要があるため、avedio linksのHDMItoコンポーネントコンバータを使用しました。日本の尼では売り切れていたので米尼より取り寄せました。最初アリエクのほうが安かったのでそっちから買ったのですが、コンバータだけで20msほど遅延するという粗悪製品だったので、もしもオレっちも計測するぜ!なんて奇特な方は米尼から買うことを強くお勧めします。送料に糸目をつけなければ3日で日本に来ます。どっちの製品も取説にメーカー名の記載すらないノンブランド臭のする中華のアレな作りですが、アリエクの方は画質も悲惨で完全にゴミです。

というわけで計測結果はGoogle スプレッドシートに上げました。

https://docs.google.com/spreadsheets/d/14iLRMDgA8F1GQ09rNE-5QCfUe2qJiHFV/edit?usp=sharing&ouid=103781726692634923394&rtpof=true&sd=true

画像としても上げておきます。

遅延計測結果

総評、というか感想および数値だけでは見えてこない情報の補足

  • 低遅延で有名な製品というわけではないと思うけど、GB2770HSUは比較的新しい世代のモニタであり、総じて優秀
  • 3つのスケーラーの遅延の違いは1~3ms程度で僅差ではあるが、ゼロラグのブラウン管から数msの液晶になっただけで操作感に違和感を覚えることを考慮すると、1ms程度であっても過小評価するべきではない。
  • GBS-CはOSSCより遅延が若干多い、という情報をYoutubeで見たけど自分の環境ではGBS-Cのほうがやや良好
  • OSSCはGBS-Cより遅延が若干多いが、ブレが非常に少ない。プレイに影響を及ぼすような違いとなるのかは分からない。計測前の体感ではOSSCの方が良好であったが、計測してみたらこの結果である。
  • OSSCで240pがすべてno syncになってしまっているが、HDMItoコンポーネントコンバータのせいかもしれない。
  • 240p前後になるアーケード基板の場合はRetroTINK 2x Proが最適かも。ただし画質はS端子またはコンポーネントレベルになる。
  • テレビはテレビ番組を観るために使うものであり、ゲームをするために使うものではない。(ガチ勢並みの感想)
  • なんとなく3か所を計測ポイントとしてみたけど、top以外を計測する意味は何かあったのかと自問自答している。
  • 遅延の話ではないけど、画質という点ではRGB入力のOSSCが一番綺麗
  • 同様に遅延の計測をされている先人の方々のデータをみるとPixioのモニタが遅延が少ないようなので、いずれ入手して追試したい。

というわけでこの記事はいかがでしたでしょうか。役に立ったのなら、高評価およびチャンネル登録をお願いします。(そんなボタンはない)