ただのローカルLLM導入実験が、気づけば軽量・高速な自宅AIプラットフォームへ究極進化していた🤣

最初は本当に、「自宅PCでローカルLLMを動かしてみたい」というだけの実験やった。

Ollamaを入れて、Open WebUIからQwen 3.5 9Bと会話できれば、それでひとまず満足するはずやった。

ところが実際に使い始めると、「必要なときだけWeb検索してほしい」「自分のプロフィールやPC構成を正確に参照してほしい」「大事な会話を長期記憶へ残したい」と、欲しい機能が次々に増えていった。

その結果、ただローカルモデルを起動するだけやった環境は、Assistant Gateway、Local Knowledge Registry、SearXNG、Narrative Memory、Hardware Collector、アクセス制御、バックグラウンドWorkerまで備えた、自分専用の自宅AIプラットフォームへ発展した。

Open WebUIは操作用のコックピットに徹し、質問内容の判定、Web検索、知識取得、記憶、権限制御は外部のAssistant Gatewayが担当する。この記事では、単なる導入実験が実用的な自宅AI基盤へ育つまでの構成、軽量高速化、実装、失敗、改善点をまとめるで。

今回構築した自宅AIでできること

現在のLocal Assistantでは、主に次の処理を一つのチャット画面から利用できる。

• 自宅PC上のQwen 3.5 9Bによるオフライン回答
• 質問内容を見て、必要なときだけ自動でWeb検索
• 指定URLの取得、本文抽出、要約、分析
• Local Knowledge Registryに登録したプロフィールや確定情報の参照
• OS、CPU、GPU、メモリ、ストレージ、SMART情報の正確な回答
• /saveによるNarrative Memoryへの長期記憶保存
• 通常会話に応じたNarrative Memoryの自動検索・参照
• 個人用、公開用、世界観用アシスタントのアクセス分離
• Docker Composeとsystemdユーザーサービスによる常駐運用
• 重い解析を専用Workerへ分離したバックグラウンド処理

単に「ローカルでチャットできる」という段階から、質問の種類、情報源、権限、負荷に応じて処理方法を切り替える、小規模な自宅AIプラットフォームになった。

目指したのは、単なるローカル版ChatGPTやなかった

OllamaとOpen WebUIを導入した直後は、ローカルモデルと会話できれば十分やと思っていた。

けれど、日常的に使おうとすると、モデル単体では足りないことがすぐに分かった。

• 自分の呼び名やプロフィールを覚えてほしい
• 過去に決めた開発方針を参照してほしい
• PC構成を推測ではなく実機情報から答えてほしい
• 最新情報が必要な質問だけWeb検索してほしい
• URLを渡したら、そのページを読んでほしい
• 残したい経験だけを長期記憶へ保存したい
• 個人情報へアクセスできるAIと公開用AIを分離したい
• 情報管理を静的なMarkdownファイルだけに依存させたくない
• 精度を落とさず、不要な処理を減らして軽く動かしたい

ここまで来ると、モデルを起動してチャットUIへ接続するだけでは足りへん。モデル、検索、知識、記憶、権限、ルーティング、バックグラウンド処理を分離した、一つのAIシステムとして設計する必要が出てきたんや。

使用した技術構成

ローカルLLM関連のソースコード、設定、データ、バックアップは、原則として次のディレクトリ配下へ集約した。

~/Apps/Sources/LLM

ホームディレクトリ内へ関連ファイルが散らばらんように、物理配置にもルールを設けている。

自宅AI全体の構成

現在の大まかな通信経路は次のとおり。

Local AI Platformのシステム構成

Local AI Platformは、Open WebUIを操作画面として利用しながら、推論・知識管理・長期記憶・Web検索をそれぞれ独立したコンポーネントへ分離した、自宅運用型のAIプラットフォームです。

中央のAssistant Gatewayがユーザーの質問内容を判断し、ローカルLLM、Knowledge Registry、Narrative Memory、Web Searchへ適切に処理を振り分けます。これにより、小規模なローカルLLMでも、確定情報・過去の文脈・最新情報を用途別に参照しながら回答できます。

The Local AI Platform is a self-hosted home AI platform that separates its user interface, local inference, knowledge management, long-term memory, and web search into clearly defined components.

The Assistant Gateway analyzes each request and routes it to the appropriate service, including the local LLM, Knowledge Registry, Narrative Memory, or Web Search. This architecture allows even a lightweight local model to produce practical responses by combining deterministic facts, conversational context, and current public information.

Architecture diagram of the Local Assistant home AI platform, showing Open WebUI, Assistant Gateway, Ollama, Knowledge Registry, Narrative Memory, SearXNG, and background workers.

Open WebUI本体へ大きな改造を加えず、AI処理の制御をAssistant Gateway側へ分離することで、Open WebUIのアップデートへ追従しやすくしています。また、非公開情報をWeb検索クエリへ混入させないなど、プライバシーと安全性にも配慮しています。

Knowledge RegistryはPC構成やプロジェクト情報などの確定情報を管理し、Narrative Memoryは会話履歴や経験的な文脈を管理します。最新の公開情報が必要な場合のみSearXNGによるWeb検索を実行し、役割ごとに最適な情報源を利用します。

Open WebUIはAI本体ではなく「コックピット」

今回の構成で、Open WebUIは会話画面とモデル選択を担当するコックピットとして使っている。

実際に質問内容を判定し、ローカル回答、Web検索、URL解析、Registry参照、Narrative Memory、アクセス拒否などへ振り分けるのは、外部に置いたAssistant Gatewayや。

Open WebUI本体のソースコードには手を加えていない。本体へ独自改造を入れると、アップデートのたびにパッチを当て直す必要がある。外部Gateway方式なら、UIの更新と自宅AI側の機能を分離でき、問題が起きたときも切り分けやすい。

軽量・高速化は「小さいモデルへ替える」だけではない

今回の軽量高速化で重視したのは、回答精度を落とすほどモデルを小さくすることやなかった。

LLMに考えさせる必要がない処理を、LLMの外へ分離することで、無駄な推論、無駄なRAG、無駄なWeb検索を減らした。

• 一般知識で答えられる質問は、WebもRegistryも使わずローカルモデルへ送る
• 最新情報が必要な質問だけSearXNGを使う
• PC構成やプロフィールはRegistryから決定論的に取得する
• Web検索時はPrivate Registryを呼ばず、検索Queryへ個人情報を混ぜない
• 重い文書解析や記憶メタデータ生成を専用Workerへ分離する
• 文書RAGを常時使わず、質問と情報の種類に応じて経路を選ぶ

Qwen 3.5 9Bは66レイヤーをRadeon 780Mへフルオフロードできた。現行環境で確認した目安は、Prompt処理が約56.23 token/秒、回答生成が約3.65 token/秒や。速度は質問内容やContext量で変動するけど、9Bモデルを自宅PCで常用する基盤としては実用範囲へ持ってこられた。

特に効果が大きかったのは、「何でもRAG」「何でもLLM生成」をやめたことや。確定情報はAPIとデータベース、最新情報はWeb、一般知識はモデル、残したい経験はNarrative Memoryへ任せることで、精度と負荷のバランスを取っている。

Gatewayが質問内容を判定して自動ルーティング

Open WebUIから届いた質問は、Assistant Gatewayが内容を確認し、処理経路を決める。

Web検索は必要なときだけ完全自動化

以前はWeb検索のスイッチを手動で切り替える必要があった。現在はGateway側で、ニュース、現在価格、在庫、天気、障害情報、最新バージョンなど、時間とともに変わる情報かどうかを判定する。

一方で、Pythonの基本説明や一般的なLinux知識など、Webが不要な質問はオフラインのまま処理する。「現在完了形」のように、単語として「現在」を含むだけの質問を誤検索しないための除外条件も入れた。

自動判定を上書きしたい場合は、次の手動指定も利用できる。

/offline 今日のニュースを教えて
/web Qwen 3.5の最新情報を調べて
/research 公式資料を複数比較して

検索時に個人情報を混ぜない

Local AssistantはプロフィールやPC構成へアクセスできるため、Web検索Queryの境界は特に厳しくした。

検索要否の判定とQuery生成へ渡すのは、現在のユーザー発話とアシスタント種別だけ。Registry検索結果、保存済みMemory、所有者情報、非公開の世界観設定、過去のPrivate Contextは渡さない。

Web検索経路ではPrivate Registry自体を呼ばない。検索結果はそのRequest専用Contextとして使い、RegistryやConversationへ勝手に永続保存しない。

SearXNGが失敗しても会話を止めない

検索が必要と判定されたあとにSearXNGが失敗した場合は、検索なしの安全なFallbackへ移る。

その際、モデルへ「最新情報を確認できた」と誤認させず、Webで検証できていないことをContextへ明示して通常会話を継続する。実検索、Private Query分離、失敗Fallback、Streaming応答まで一連のRuntime Acceptance Testを通した。

OllamaとOpen WebUIから構築を開始

最初に導入したのはOllamaとOpen WebUIや。

Linux Mint上でOllamaを起動し、Open WebUIからQwen 3.5 9Bを選択して会話できる環境を整えた。モデルへの入力と推論を自宅PC内で処理できるため、個人情報や未公開の開発内容を外部AIサービスへ送らずに済む。

さらにContinueを導入し、コードエディタ上からもローカルモデルを利用できるようにした。コード生成だけでなく、Gitのブランチ作成、コミット、リリース作業など、開発支援環境の一部として使う構成や。

Open WebUIのRAGを試して分かったこと

次に、Open WebUIのRAG機能を検証した。

ベクトルデータベースにはQdrant、埋め込み処理にはsentence-transformers系のモデルを使い、登録文書から関連箇所を検索できるところまで構築した。

ただし、実運用では次の課題が見えてきた。

• RAG使用時のCPU負荷が高い
• 取得された断片が最新情報か判断しにくい
• 確定情報まで類似検索へ任せると回答が不安定になる
• 情報の更新、削除、変更履歴を管理しにくい
• プロフィールと一般文書を同じ検索方式で扱うのは無理がある

自分の呼び名やPC構成のような明確な情報まで、文章の類似度だけで探す設計には不安が残った。そこで、一般文書のRAGとは別に、確定情報を構造化して管理するLocal Knowledge Registryを作ることにした。

Local Knowledge Registryで確定情報を管理

プロフィール、PC構成、プロジェクト情報などを管理するために、Local Knowledge Registryを構築した。

Registryでは、情報を単なる文章の塊ではなく、次の単位で扱う。

• 名前空間
• エンティティ
• ファクト
• リレーション
• ドキュメント
• Narrative Memory

たとえば使用中のPCは、machineエンティティとして登録する。そのエンティティへ、OS、Linuxカーネル、CPU、GPU、メモリ、ストレージ、SMARTなどの情報をファクトとして紐づける。

俺のPCのCPUは何やったっけ？

この質問へ、LLMの学習内容や会話履歴から推測して答える必要はない。Registryへ保存した正規データをAPI経由で取得し、確実な情報として回答できる。

会話を長期記憶へ残すNarrative Memory

確定情報をRegistryへ登録できても、人生経験、過去の出来事、開発中の判断、サイト運営の経緯などは、最初からきれいなファクト形式へ整理できるとは限らん。

そこで追加したのがNarrative Memoryや。

/save 俺が所有しているWebサイトは、

十円玉ドットコム | オッサンが狂喜乱舞するブログである
www.10yendama.com

Internet Radio & Podcast Jukebox | 10yendama.com
A lightweight internet radio and podcast jukebox for your browser. Choose a genre, switch M3U stream servers, and listen...
radio.10yendama.com

国内外ニュース・技術・Linux情報 | 10yendama.com News Station
国内外ニュース、テクノロジー、Linux関連情報と東京都の天気をまとめて確認できる、10yendama.com運営の軽量ニュースフィードです。
news.10yendama.com

/saveを使うと、まずユーザーが入力した原文をそのまま保存する。そのあとQwen 3.5 9Bが内容を解析し、タイトル、要約、タグ、機密度、時系列、人物、場所、主張、関係性などの動的メタデータを生成する。

🧠 記憶へ保存したで。

タイトル：ユーザーのWebサイト所有
要約：ユーザーが10yendamaドメインの複数サイトを所有している。
タグ：Webサイト、所有物
機密度：通常
状態：analyzed
記憶ID：mem_...

原文を先に保存する理由

LLMによる解析は、常に完璧とは限らん。そのため、Narrative Memoryでは次の順序を守っている。

原文をraw_onlyで保存
  ↓
ローカルLLMでメタデータ解析
  ↓
成功：analyzed
失敗：analysis_failed

解析に失敗しても、元の発言は失われへん。タイトルが空なら原文から安全に補い、要約やタグが不正な場合は正規化する。推測による事実追加は行わない。

保存した記憶は所有者をuser、公開範囲をprivateへ固定し、/saveを利用できるのはLocal Assistantだけに限定した。

保存した記憶は通常会話から自動参照される

現在は、保存済みの記憶を探すための専用コマンドを入力する必要はない。

Local Assistantへ普通に質問すると、Gatewayが現在の発話を使って関連するNarrative Memoryを自動検索する。条件に合う記憶だけをRequest専用のmemory_referenceとしてContextへ追加し、回答後に破棄する。

マニラに住んでいた頃の話、覚えてる？
ローカルLLMの開発方針はどう決めた？
俺が運営しているWebサイトは？

すべての会話履歴を毎回モデルへ渡さず、現在の質問に関係する過去だけを取り出せる。一般RAGが「文書から関連箇所を探す」仕組みなのに対し、Narrative Memoryは「ユーザーが明示的に保存した経験や判断を、会話中に自動参照する」仕組みや。

保存そのものは引き続き/saveで明示的に行う。何でも自動保存しないため、雑談や一時的な発言が無制限に蓄積されることもない。

Local Assistant・Public Assistantを分離

用途によってアクセス可能な情報を変えるため、アシスタントを役割別に分離した。

Local Assistant

所有者専用のAI。プロフィール、PC情報、Registry、Narrative Memory、URL解析、Web検索などへアクセスできる。

Public Assistant

将来の一般公開を想定したAI。一般質問、公開URL、Web検索には対応できるが、次の情報や機能へはアクセスできない。

• 所有者のプロフィール
• 自宅PCのハードウェア情報
• 個人用Registryの非公開情報
• Narrative Memory
• /saveとNarrative Memoryの自動参照
• localhostや内部ネットワークのURL
• Registry APIの内部エンドポイント

PC情報を自動収集するHardware Collector

俺のPC構成を教えて

この質問へ、LLMに推測で答えさせるわけにはいかへん。そこで、実機から情報を取得するHardware Collectorを作った。

現在は次のような情報を収集できる。

• Linuxディストリビューション
• Linuxカーネル
• CPUモデル、論理CPU数、物理コア数、スレッド数
• メモリ容量
• GPUとカーネルドライバ
• ストレージ構成
• SMART情報
• NVMe Health
• 温度センサー
• ネットワークアダプター

一方で、シリアル番号、MACアドレス、WWN、UUIDなど、AIの回答に不要な識別情報は保存対象から除外している。

収集結果はJSONスナップショットとして保存したあと、Registryへ同期する。回答時はLLMに自由生成させず、Registryの値を決められた形式で整形するため、同じ質問には同じ内容を返す決定論的なハードウェア回答を実現できた。

構築中に発生した主な不具合

見た目上は成功しているのに、裏側では処理されていない問題や、日本語環境特有の問題など、かなりのデバッグが必要やった。

Registry同期が成功表示なのに更新されない

ハードウェア同期処理が終了コード0で成功扱いになるのに、データベースが更新されていない問題があった。

原因はPythonモジュールの起動方法。パッケージ内部のCLIモジュールを直接実行していたため、メイン処理が呼ばれず、エラーも出さずに終了していた。正しいパッケージエントリーポイントへ変更して解決した。

typeとentity_typeの食い違い

Gatewayや検証スクリプトの一部では、エンティティ種別をtypeで確認していた。しかし、Registry APIが返す正式なキーはentity_typeやった。

entity.get("entity_type") or entity.get("type")

互換性を持たせるため、両方を確認する方式へ変更した。

登録済みPCが検索結果に出ない

RegistryへPC情報は登録できているのに、一般的な検索文だけでは対象マシンへ十分に一致しない問題があった。検索時に現在のホスト名を追加し、対象のmachineエンティティを安定して取得できるようにした。

CPU情報がMicrocodeしか取得できない

Hardware Collectorはlscpuの英語フィールド名を前提にしていた。日本語ロケールではフィールド名が変わるため、許可リストと一致せず、多くのCPU情報が捨てられていた。

env LC_ALL=C LANG=C lscpu -J

lscpu実行時だけCロケールへ固定し、CPUモデル、論理CPU数、物理コア数、コアあたりのスレッド数を正しく取得できるようになった。

Narrative Memoryのタイトルが空になる

Qwenが有効なJSONを返していても、titleだけ空になることがあった。この場合に記憶全体を失敗扱いへせず、原文の先頭文から安全なタイトルを生成するFallbackを追加した。

Web検索の設定は正しいのに、自動検索されない

Open WebUI側でSearXNGが利用できても、質問ごとに検索スイッチを切り替える仕組みのままでは、ChatGPTのような自動判断にはならへん。

最終的にOpen WebUIを改造するのではなく、GatewayへAutomatic Web Routerを実装した。検索要否判定、Private Query分離、検索失敗Fallback、StreamとNon-streamの共通Context経路を検証し、実検索とStreaming応答まで通した。

テストとデプロイ

Assistant GatewayはDocker Composeでビルドし、コンテナとして稼働させている。Local Knowledge Registryはsystemdユーザーサービスとして常駐させた。

検証では、主に次の項目を確認している。

• Gateway、Open WebUI、RegistryのHealth
• Local Assistant、Public Assistantのアクセス分離
• ハードウェアプロファイルの決定論的回答
• Public Assistantから個人情報へのアクセス拒否
• 一般質問、URL解析、自動Web検索の経路
• Web検索QueryへPrivate Registryが混入しないこと
• 検索失敗時の安全Fallback
• Non-streamとStreamingの双方で同じPrepared Contextを使うこと
• /saveの原文先行保存と解析失敗時の保全
• 記憶の所有者と公開範囲の固定
• テストデータ削除後の件数復元
• Gateway再起動後の設定維持
• 本番Source、Container、Registry DBの整合性

変更作業では、候補コピーへ実装してから構文テストとAcceptance Testを実行し、成功した場合だけ本番へ反映する。失敗した場合は事前Backupへ自動Rollbackする方式にした。

ローカルLLMを構築して分かったこと

ローカルLLMは、モデルをダウンロードして起動しただけでは「自分専用AI」にはならへん。

実際に使える形にするには、モデルの周辺にある仕組みが重要になる。

• 何をLLMに考えさせるか
• 何をデータベースから正確に取得するか
• 何を長期記憶へ残すか
• いつWeb検索するか
• 誰がどの情報へアクセスできるか
• 重い処理をいつバックグラウンドへ回すか
• 取得した情報が本当に正しいか
• 成功表示だけで処理完了と判断してよいか
• 不具合発生時にどこまで安全に戻せるか

Registry同期が成功したように見えて、実際には何も実行されていないこともあった。日本語ロケールの影響でCPU情報の大半が消えたことも、Narrative MemoryでJSONは正しいのにタイトルだけ空になったこともあった。

表面的な成功表示を信用せず、収集、保存、解析、検索、整形、権限、公開範囲、Streaming、Rollbackを個別に検証したことで、ようやく安定した自宅AI基盤になった。

今後残っている作業

自宅AI基盤の大枠は完成したけど、今後の拡張候補は残っている。

Open WebUI側のモデルACL

Gateway内部ではLocal AssistantとPublic Assistantの権限を分離できた。外部公開前には、Open WebUI側でも管理者だけがLocal Assistantを利用でき、一般ユーザーにはPublic Assistantだけが表示される状態を最終確認する。

Public Assistantの外部公開

外部公開する場合は、HTTPS、リバースプロキシ、IP単位のレート制限、入力文字数制限、同時接続数制限、タイムアウト、ログ確認、不正利用時の遮断などが必要になる。

が、現在実験的にOpenWRTへCloudflaredを導入し、下記の仕組みで外部アクセスできるようにしている。

1. 専用ドメインのNSをCloudFlareへ移管し、DNS情報をOpenWRT上のCloudflaredで同期
2. Zero Trustの導入
3. Cloudflare Accessにて認証→Tunnel→HTTPSでのリバースプロキシでOpen WebUIでログイン

ChatGPTエクスポートデータの取り込み

過去の会話や開発記録をLocal Assistantへ取り込む計画もある。ただし、すべての会話を無差別にベクトル化するつもりはない。

プロフィール、決定事項、作業履歴、プロジェクト情報、人生経験、一時的な雑談を分類し、Registry、Narrative Memory、一般RAGへ振り分ける必要がある。

とはいえ、現在はChatGPTの履歴データをNarrative Memoryへメタデータとしてインポートしてある。

RAGと埋め込み処理のさらなる最適化

精度を落として軽くするのではなく、確定情報をRegistryへ分離し、個人記憶をNarrative Memoryへ分離し、検索対象文書を絞り、更新されていない文書の再処理を避ける方向で改善を続ける。

関西弁LoRAは対応GPU導入まで保留

自然な関西弁を学習させるLoRA用データセットは準備したものの、Radeon 780Mでは現時点の公式ROCm対応と学習環境の安全性に課題があった。無理な互換設定は使わず、対応するNVIDIA GPUを利用できる環境になるまで保留している。

まとめ｜ローカルLLMは「俺専用の自宅AIプラットフォーム」へ進化した

最初は、OllamaとOpen WebUIを導入し、自宅PCでQwen 3.5 9Bを動かしてみるだけの実験やった。

ところが実際に使い始めると、モデルと会話できるだけでは足りへんことが分かった。

必要なときだけWeb検索してほしい。自分のプロフィールやPC構成を正確に参照してほしい。過去の経験や開発方針を必要な場面で思い出してほしい。それでいて、個人情報や非公開データを外部へ無制限に送る構成にはしたくない。

そこで、Open WebUIを操作用のコックピットとして残し、判断と制御を外部のAssistant Gatewayへ分離した。

• 一般知識はローカルLLM
• 最新の公開情報はSearXNGによるWeb検索
• プロフィールやPC構成などの確定情報はLocal Knowledge Registry
• 残したい経験や判断はNarrative Memory
• 重い解析や同期処理はバックグラウンドWorker

それぞれの処理を得意な仕組みへ分担させることで、何でもLLMへ考えさせる必要がなくなった。

確定情報を推測させず、不要なRAGやWeb検索を減らし、重い処理を会話経路から分離する。その結果、9Bモデルでも回答精度と実用速度を両立しながら、自宅PC上で日常的に利用できる環境へ育てられた。

今回の構築で得られたもの

• ローカルLLMによるオフライン回答
• 質問内容に応じたWeb検索の自動実行
• URL取得・本文抽出・要約・分析
• Registryによる確定情報の決定論的な回答
• Narrative Memoryへの長期記憶保存と自動参照
• 実機ハードウェア情報の自動収集
• 個人用AIと公開用AIのアクセス権限分離
• Docker Composeとsystemdによる常駐運用
• バックアップ・検証・Rollbackを含む安全な更新手順
• Open WebUI本体を改造しない、アップデート耐性の高い構成

特に大きな成果は、単にモデルを高速化したことやない。

どの情報を、どの仕組みへ任せるべきかを整理し、AIシステム全体を軽量化できたことや。

モデルの規模だけで性能を追いかけるのではなく、検索、知識、記憶、権限、バックグラウンド処理を適切に分離する。これによって、小規模なローカルモデルでも実用的なAI基盤を構築できることが分かった。

さらに現在は、ChatGPTからエクスポートした過去の会話履歴もNarrative Memoryへ取り込み、自分の開発履歴や経験を必要に応じて参照できるようになっている。

ただのローカルLLM導入実験が、気づけば自分の知識、記憶、PC、Web検索、開発環境をつなぐ自宅AIプラットフォームへ究極進化してしまった🤣

これはもう、ローカルで動くチャットボットというだけの存在やない。

自分で管理し、自分で機能を追加し、自分の知識と記憶を育てていける、俺専用のAI基盤や。

追記：Thinking Modeも自動制御するようになった

この記事を書いたあと、Assistant Gatewayをさらに改良した。

Qwen 3.5 9Bの回答精度を検証していたところ、Ollamaへ常時think:falseを指定していたことが、複雑な質問での回答品質を大きく落とす原因のひとつになっていることが分かった。

そこで現在は、軽い雑談ではThinkingを無効化して速度を優先し、技術相談、ログ解析、コード、比較・検証、ブログ執筆などではThinkingを自動的に有効化するAuto Think RoutingをAssistant Gatewayへ実装している。

さらに、以前設定していたデフォルト768 tokenの生成上限も撤廃した。

つまり現在の自宅AIは、

「どの情報源を使うか」だけでなく、「その質問をどれだけ考えて答えるか」まで自動判定するようになった。

実際にQwen 3.5 9BでThinking有効・無効を比較した検証結果と、Auto Think Routingを実装するまでの経緯は別記事へまとめた。

Qwen 3.5 9Bはアホじゃなかった？OllamaのThinkingを自動切替してローカルLLMを高速・高精度化

Qwen 3.5 9Bの回答精度が低い原因を検証したところ、Ollamaのthink:false固定と生成token上限が判明。Thinking有効化による改善結果と、質問内容からThinking Modeを自動切替するAssistant Gatewayの実装を紹介します。

www.10yendama.com

2026-08-08