「動かなかった、それでも立った」― ローカル業務RAGの『半分着地』を308日目に書く
こんにちは！YaroTechです。
木曜のクロ助は、OpenAIの公式単価をExcelに落として「議事録1時間172.8円・月14,700円」というAPIインフラ価格を試算しました。「API単価が電気代と同じ感覚に降りてきた」と書いた翌日、金曜のYaroTechはエッセイで「ここ最近の生成AI、一般人がキャッチアップできてる気がしない」と動向を俯瞰しました。そして土曜の今日、私はもう片方の軸を開きにいきました。「同じ業務RAGを、Surface Laptopの中だけで動かしたら、いくらか」。土曜の自分は、8日前のDay300_2末尾予告 ―「次回はAnythingLLM Desktop × Foundry Local で業務RAG環境を組み立てる」― を、ようやく実機で着地させにいく1日のはずでした。
結論から書くと、当初の目論見「AnythingLLM × Foundry Local」は 動かなかった っちゃ。それでも、AnythingLLM 内蔵 Ollama × Qwen3 1.7B（CPU推論）に切り替えて、業務RAG の土台自体は半日で立ち上がりました。Day300_2予告から8日越しの正面回収は、「半分着地」 の手触りで土曜の手に残りました。
※見出し画像のプロンプトは一番下におまけで公開中！
実行環境
PC: Microsoft Surface Laptop 7th Edition
CPU: Snapdragon X Elite（ARM64・Hexagon NPU 45 TOPS）
OS: Windows 11 Home 25H2 ARM64
RAM: 16GB
既設: Microsoft Foundry Local v0.8.119.102（Day300_2で構築済み・`phi-3.5-mini-instruct-qnn-npu:2` 動作確認済み・21.42 tok/s）
新規導入: AnythingLLM Desktop v1.12.1（ARM64版あり）
検証データ: 過去note記事のMarkdown（`day300_2_article.md`）
⚠️ 本記事は Surface Laptop 7th（ARM64）での実機構築メモです。x64版Windowsでは挙動が変わる可能性があります。
この記事で得られること
Foundry Local v0.8.119 の HTTP API がどう動かなかったかの実機エビデンス（GitHub Issue と症状一致）
AnythingLLM 内蔵 Ollama × Qwen3 1.7B（CPU推論）で業務RAGを半日で立てた手順
自分のnote記事をローカルRAGに読ませた検証結果と、軽量モデルの限界（ハルシネーション観察）
「常にPC内ファイルを読ませる」運用の現実的な3つの回避策と、llama.cpp MCP という別の道筋
Day300_2予告から8日越しの「半分着地」の手触り
当初の目論見 ― なぜ「土曜にローカルRAG」だったのか
木曜にAPIインフラ価格をExcelに落とした時点で、私の手元には2つの軸が出来上がっていました。1つは「使った分だけ払うAPI」（月14,700円・OpenAI米国サーバー送信・180msレイテンシ）。もう1つは「電気代を払って自分で持つローカル」（Day300_2の21.42 tok/s・PC内完結）。
Day306のExcel試算は前者の軸を「インフラ価格」として可視化する作業でした。じゃあ後者の軸はどうなのか ― 「ローカルで業務RAGを動かしたら、月いくらか」「自分のnote記事を自分のPCの中で検索できるって、どんな体感か」。この2つを実機で確かめておかないと、Day306の14,700円という数字が 比較する相手のいない単独の数字 で終わってしまう。Day307のエッセイで「キャッチアップなんて全部追わなくていい、1個に絞れ」と書いた手前、自分こそ「絞った1個」を実機で動かして見せないと格好がつかない、というのも正直なところでした。
そこで土曜の自分は、Day300_2で動かしたFoundry Localの上に、業務RAG層を1枚積むことにしました。使うのは AnythingLLM Desktop ― 公式互換APIを「Generic OpenAI接続」で受けられる、Windows向けのRAG構築ツールです。OpenAI公式に払わなくても、設定画面の数項目で「自分のPC内で完結するAI」が立ち上がる、らしい。
ところが、実機はそう素直には動かなかったっちゃ。
Foundry Local CLI は動いた、でも HTTP API は動かなかった
土曜の午前、`foundry service start` を叩いて Foundry Local を起動。動的ポート（今日は 64891 → 再起動後 60742）を確認して、`foundry model run phi-3.5-mini-instruct-qnn-npu:2` で CLI対話モードに入る ― ここまでは Day300_2 と完全に同じ景色。NPU使用率がスパイクして、日本語で挨拶を返してくれる。「Day300_2と同じだべ、足元は健在」と確認できた瞬間です。
問題はその次。AnythingLLM Desktop の LLM Provider 設定で Generic OpenAI を選び、Base URLに `http://localhost:64891/v1` を、Chat Model Name に `phi-3.5-mini-instruct-qnn-npu:2` を入れて Save。LLMが利用可能のグリーンサインまで出る。ここまでは Day300_2のつまずきを引き継いだ通り、`:2` サフィックスも忘れていない。
そしてチャットを送ると ― 応答が返ってこない。
`Premature close`。HTTP コネクションが応答を返す前に切れている。AnythingLLM 側の問題かと疑って、PowerShell から `Invoke-RestMethod` で `/v1/chat/completions` を直接叩いてみる。返ってきたのは同じく接続切断。Foundry Local のサービスログを見ると、Unhandled exception was thrown by the application ― .NET の Kestrel サーバーが内部例外で死んでいるっぽい。
`/v1/models` エンドポイントは正常に応答する。モデル一覧（`phi-3.5-mini-instruct-qnn-npu:2`、maxInputTokens=114688、maxOutputTokens=16384）も取れる。しかし、`/v1/chat/completions` を叩いた瞬間に Kestrel が落ちる。CLIで `foundry model run` を叩いたときは、別ポートで別サービスが立ち上がる仕組みになっているらしく、そちらは正常動作している。HTTP API経路だけが、私の環境では壊れている。
調べてみると、GitHub の `Mintplex-Labs/anything-llm#3194` と `#2962` で、Surface Laptop 7 + Snapdragon X Elite 環境で QNN engine が boot failure を起こす同じ症状が複数報告されていました。Microsoft の Foundry Local 公式リポジトリも、HTTP API とCLI は「development workflows」用で、本番運用には SDK の直接組み込みが想定されている、と注記している。
つまり、「AnythingLLM × Foundry Local を Generic OpenAI接続で繋ぐ」というシナリオは、私の環境では 公式の設計思想からも、現状の実装からも、外れていた ということ。土曜の午前11時、Day300_2予告から8日越しの正面回収は、半分で詰まりました。
諦めずに代替経路 ― AnythingLLM 内蔵 Ollama + Qwen3 1.7B
ここで土曜の自分が選んだのは、「Foundry Local を別の方法で動かす」道筋ではなく、「Foundry Local を今日は脇に置いて、AnythingLLM 単体で業務RAG の土台を立てる」方向でした。
AnythingLLM 1.12.1 を起動すると、LLM Provider の選択肢に AnythingLLM 自前の 内蔵 Ollama プロバイダーがあります。Snapdragon NPU を使わない CPU推論経路ですが、AnythingLLM側で完結している分、Foundry Local の HTTP API バグを踏まずに済む。さらに 1.12.1 では、Qwen3 / Qwen3.5 / Gemma 4 / Liquid AI の LFM2.5 など、軽量モデルがプロバイダー画面のカードで直接選べる UI に変わっていました。
私が選んだのは Qwen3 1.7B（1.4GBの軽量モデル）。
理由は3つ。
①1.7BならSurface Laptop 7th の16GB RAM で余裕、
②CPU推論でも応答速度は実用に乗る、
③Qwen系は日本語対応が比較的しっかりしている。
Phi 3.5 Mini や Gemma 4 E2B も候補でしたが、「とにかく動くものを最短で」が土曜の優先順位でした。
ダウンロードを開始。1.4GB、進捗バーが3% → 80% → 100% へ。所要約5分。完了と同時にモデルが Active になって、メイン画面のチャットで挨拶を送る ― 「私はアルイバクラウドの大規模言語モデルです」と少しタイポ気味の自己紹介が返ってきました。日本語、動いてる。NPU推論ではないので画面の上部に「NPU 100%」スパイクは見えないけれど、タスクマネージャーのCPUは確かに張り付いている。Foundry Localの21.42 tok/sは今日は出せないけれど、応答は確かに返ってくる。それで十分でした。
業務RAG構築 ― 自分のnote記事を、自分のPCの中で検索する
LLM側が動いたので、ここからが本題の業務RAG。AnythingLLM のワークスペース管理画面（左サイドバーの「↑」アイコン）を開くと、マイドキュメント と マイワークスペース の2カラム構造の画面が立ち上がります。
最初に投入したのは、Day300_2 の記事 Markdown（`day300_2_article.md`、約30KB）。下部の「クリックしてアップロード」エリアにドラッグ&ドロップ ― 一瞬で左カラム（マイドキュメント）に表示されて、「ワークスペースへ移動」ボタンで右カラム（マイワークスペース）に送る。右下に「保存して埋め込む」が出現したので、押す。
ベクトル化の所要時間は 20秒未満。AnythingLLM Embedder（CPU処理）がチャンク分割→ベクトル化→LanceDBへ保存まで一気に処理して、ベクター数は10。「これで自分のnote記事の中身が、自分のPCの中で検索できる状態」になりました。
質問を投げてみます。
質問A：「Day300_2でのFoundry Localの推論速度は何tok/sでしたか？」
→ 回答: 「Foundry Local on Day300_2 achieved an average inference speed of 21.42 tok/s（estimated true value: ~24 tok/s）. This was achieved using the model phi-3.5-mini-instruct-qnn-npu:2 on a Snapdragon X Elite processor, despite the OS update that caused the previous Nexa SDK performance drop.」
→ 出典として `day300_2_article.md` が明示
完璧な応答です。記事内の数値（21.42・24）、モデル名（phi-3.5-mini-instruct-qnn-npu:2）、状況説明（OSアップデート問題の克服）まで正確に引き出している。1.7Bの軽量モデルでも、適切にチャンク化されたドキュメントが手元にあれば、RAG はここまで仕事をするんだなぁ。
質問B：「Day300_2では何が起きましたか？簡単に日本語で教えてください。」
→ 回答: 「Day300_2では、以前のNexa SDKで達成した23.91 tok/sの推論速度が再現され、ARM64 Windows環境でも正常に動作し、OSアップデートによる問題が克服されました。特に、5つのAIモデル同時DeepResearchで半年の沈黙を解き、平均21.42 tok/s（真値24 tok/s）を維持する構造的な復活が成功しました。」
日本語で要約まで返してくれる。これも文句なしの応答だべさ。
質問C：「クロ助の語尾の特徴は何ですか？」
→ 回答: 「『クロ助』の終了は、静かなカと成長の物語を描き、キャラクターの経験や関係性を深く描いた…」
これは ハルシネーション。理由は単純で、Day300_2 の記事内には AI 5兄弟キャラの設定情報が含まれていない ― クロ助の東北弁の語尾なんて書いていないので、モデルは「クロ助」を別の何か（おそらく架空のアニメ作品のキャラ）と勘違いして、もっともらしい文章を生成してしまった。
これは RAG の本質を、1往復で実演してくれる重要な観察 だと思います。RAG は「投入したドキュメントに書いてある内容なら、軽量モデルでも正確に応答できる」。逆に「投入したドキュメントに書いていない内容は、軽量モデルだと"知らない"とは言えずに、それっぽい何かを返してくる」。良い RAG を立てるかどうかは、モデルの大きさよりも、投入する素材の質と網羅性で決まる ― 土曜の体感です。
ローカルRAGの運用上の現実 ― 「常に同期」はできない
ここで土曜の自分が気付いたのは、AnythingLLM のもう一つの制約です。
「PC内のローカルフォルダを常時監視して、ファイルが更新されたら自動でベクトル化し直す」機能は、AnythingLLM 単体では持っていない。今日 Day300_2 を投入したけれど、明日 Day309 の記事を書いたら、それを業務RAG に反映させるには 手動で再アップロード が必要です。フォルダの中身を AnythingLLM が "見続けてくれる" わけではない。
これは実用性に対してかなり大きな制約で、業務で日々ファイルが更新される現場だと、毎日手動で再投入するのは現実的ではない。AnythingLLM 単体で「常にPC内のファイルを読ませる」のは、用途が スポット調査・単発の知識検索 に限られそうだ、というのが今日の見立てです。
回避策は3つ見えています。
AnythingLLM API でローカルスクリプト経由の自動投入。Python でフォルダを監視して、更新ファイルを API 叩いて再投入する仕組みを自前で作る。これが一番現実的
データコネクタ機能を使う。GitHub・YouTube・Confluence・ウェブサイトURL取得などの外部サービスとは標準で連携できる ― ただし「ローカルフォルダの監視」は対象外
LlamaIndex / LangChain で自作する。フォルダ監視＋ベクトル化＋検索を Python で組む。本格運用ならこっち
それと、もう1つ気付いたのが ― llama.cpp が MCP に対応していた という別の道筋。MCP のファイルシステムツール経由で、ローカルLLMがPC内のファイルを"動的に"読みに行く設計が成立しそうです。AnythingLLM のように"事前にベクトル化する RAG" とは別の発想で、「LLMが必要なときに、必要なファイルを開く」アプローチ。これは別記事の検証ネタとして残します。
Day306との対比 ― 理想形と実機形
土曜の山場は、Day306との対比表をもう一度引いてみることです。ただし、今日は 「動かなかった理想形」 と 「動いた実機形」 の2つを並べる必要があります。
$$
\begin{array}{|l|l|l|l|} \hline
\text{軸} & \text{Day306 API} & \text{Day308 ローカル（理想形）} & \text{Day308 ローカル（実機形）} \\ \hline
\text{モデル} & \text{GPT-Realtime-2（GPT-4世代）} & \text{phi-3.5-mini（3.8B・NPU）} & \text{Qwen3 1.7B（CPU推論）} \\ \hline
\text{推論経路} & \text{OpenAI公式API} & \text{AnythingLLM × Foundry Local} & \text{AnythingLLM 内蔵 Ollama} \\ \hline
\text{月額} & \text{約14,700円（インフラ）} & \text{電気代のみ・月数百円想定} & \text{電気代のみ・月数百円想定} \\ \hline
\text{データ} & \text{OpenAI米国サーバー送信} & \text{Surface Laptop内完結} & \text{Surface Laptop内完結} \\ \hline
\text{速度} & \text{180msレイテンシ} & \text{21.42 tok/s（NPU推論）} & \text{計測未実施・体感は普通} \\ \hline
\text{RAG動作} & \text{（外部API）} & \text{想定動作} & \text{⭕ ベクトル化20秒・正確応答} \\ \hline
\end{array}
$$
「理想形」では NPU 推論で 21.42 tok/s が出るはずだった。実機では HTTP API が動かなかったので、NPU の利得は今日得られず。「実機形」では CPU 推論で代替して、業務RAGの土台自体は半日で立った。
数字だけ見ると、土曜の収穫は 半分の着地 です。Foundry Local の NPU 推論を業務RAGの推論バックエンドにする目論見は今日達成できなかった。それでも、「自分のnote記事が自分のPCの中で検索できる」体感は、CPU推論経路で確かに取り戻せました。「動かなかった、それでも立った」。土曜の手触りです。
「APIとローカルは対立軸ではなく、データ性質で使い分ける」というメッセージ自体は変わりません ― Lv.6.7「データ性質で接続先を選ぶ」 は提案として残します。ただ、その実装は「経路を1つ選ぶ」ではなく、「複数の経路を試して、動いた経路から本格運用に乗せる」柔軟性込みの選択 だ、というのが今日の気付きです。
つまずきポイント5つ（実機メモ）
つまずき① Foundry Local の HTTP API バグ
v0.8.119 の `/v1/chat/completions` を叩くと Unhandled exception で接続切断。CLI対話モード（`foundry model run`）は別ポートで正常動作するが、AnythingLLM や PowerShell から HTTP API 経由で繋ぐと使えない。GitHub Issue #3194 /#2962 と症状一致。Microsoft公式も HTTP API は開発用と位置づけている
つまずき② 代替経路の選択基準
動かないものに時間を使うか、別の経路で「業務RAGの土台を立てる」を優先するか。土曜は後者を選んだ。具体的には AnythingLLM 内蔵 Ollama + Qwen3 1.7B（CPU推論）に切り替え。NPU の利得は捨てたが、RAG の体感は確保
つまずき③ RAG のハルシネーション観察
投入したドキュメントに書かれていない内容を質問すると、軽量モデル（Qwen3 1.7B）は「知らない」と答えずに、それっぽい何かを生成してくる。今日の例では「クロ助の語尾」を聞いたら、Day300_2にAIキャラ設定がないため、モデルが架空のアニメキャラ風の応答を返してきた。RAG の品質はモデルの大きさより素材の網羅性で決まる
つまずき④ ローカルフォルダの常時同期は AnythingLLM 単体ではできない
今日Day300_2 を投入したら、明日Day309 を書いたあとは手動で再投入が必要。AnythingLLM API を叩いて自動化するか、LlamaIndex で自作するかのどちらか。スポット利用なら手動で十分、業務継続利用なら自動化を組む必要がある
つまずき⑤ Continue.dev 連動は今回も持ち越し
Day300_2 で予告した「1台NPU三役（推論・RAG・コーディング支援）」の3役目は、Foundry Local の HTTP API が動かなかった時点で今日は諦め。Continue.dev は別の経路（AnythingLLM NPU プロバイダー、npurun 等）で再挑戦予定
Day300_2予告から8日越しの「半分着地」
5月8日（木）のDay300_2末尾予告から、今日でちょうど8日。Day301（金）でOffice内Claude、Day302（土）で別シリーズ、Day303（月）で宿題3点宣言、Day304〜Day306（火〜木）でその宿題を完走、Day307（金）で生成AI動向のエッセイ ― という流れを経て、今日Day308で 半分 着地しました。
「半分」というのは、AnythingLLM × Foundry Local の Generic OpenAI接続が動かなかった分。代わりに AnythingLLM 内蔵 Ollama × Qwen3 1.7B（CPU推論）で業務RAGの土台は立った 分。Foundry Local の NPU推論をRAGバックエンドに使う目論見は持ち越しだけど、「電気代だけで動く業務RAG」の体感は土曜の手の中に確かに残りました。
継続投稿は、こうやって持ち越した予告を1つずつ降ろしていく作業でもあって、降ろした結果が「思った通り」じゃなくても、降ろした事実は事実 として記事に書ける、という気付きが今日のもう一つの収穫です。「動く前提」で書いたpreparation.md と、「動かなかった事実」を反映して書く article.md の落差は、継続投稿308日目の自分にとって、思った以上に学びになりました。
木曜のクロ助が「APIのインフラ価格」をExcelで試算し、金曜のYaroTechがエッセイで生成AI動向を俯瞰した翌朝、土曜の自分はSurface Laptopの中だけで動く"自分専用RAG"を ― 目論見とは違う経路で ― 半日で立ち上げました。セルフ突っ込み形式のリレーは、月→火（Day304）／火→水（Day305）／水→木（Day306）／木→金（Day307エッセイ）／金→土（Day308）とつながって、土曜分も「半分着地」で着地。
関連記事
今回の内容に関連する過去記事もぜひご覧ください：
まとめ
「Foundry Localが私のExcelを読まなかった土曜日」 ― この問いを実機に落とした今日。AnythingLLM × Foundry Local を Generic OpenAI接続で繋ぐシナリオは、HTTP API のバグで動きませんでした（GitHub Issue #3194 /#2962 と症状一致）。それでも、AnythingLLM 内蔵 Ollama × Qwen3 1.7B（CPU推論）に切り替えて、自分のnote記事を 自分のPCの中で検索できる業務RAG環境 が半日で立ち上がりました。
土曜の最大の発見は3つ：
「適切な質問なら完璧、知らない内容ならハルシネーション」 ― RAG の本質を1往復で実演できた。良いRAGはモデルの大きさより、投入素材の質と網羅性で決まる
「PC内のファイルを常時同期して読ませる」機能はない ― 回避策は AnythingLLM API・LlamaIndex 自作・llama.cpp MCP 連携の3つ。これは次の記事ネタ
生成AIとのセッション縦割り問題に、自分のローカル業務RAGで補助線を引ける ― Claudeのチャットエクスポートを業務RAGに投入する設計（次回検証）
「動く前提で書いた予告は、動かない事実とぶつかって、半分着地で記事になる」 ― 308日続けて見えた、もう一つの景色です。
次回予告
Day309（日曜）以降、土曜の積み残しを埋める検証シリーズに入ります。
AnythingLLM NPU プロバイダー（Qualcomm AI Hub 版 Phi 3.5 Mini Instruct）の検証 ― Foundry Local 経由とは別のNPU経路
npurun（OSS Rust製 NPU runtime）の検証 ― Foundry Local の HTTP API バグを回避する代替経路として有力
llm-jp4（日本純正LLM）を Surface Laptop で動かす ― Hugging Face GGUF インポート機能経由
Continue.dev 連動による「1台NPU三役」の3役目を、別経路で実現する
Claude のチャットエクスポートを業務RAGに投入する ― 生成AIとの対話のセッション縦割り問題に、自分のローカルRAGで補助線を引く設計
特に llm-jp4 は、日本純正LLMが Surface Laptop の中だけで動く時代の象徴になりそうなので、最有力候補です。
おまけ：見出し画像作成プロンプト
今日の見出し画像のベースはジミー（Gemini）に下記プロンプトで作成してもらいました！クロ助の参考画像（`AI擬人化\Gemini_Generated_Image_クロ助（Claude Desktop）.png`）を添付して、人物の一貫性を確保しています。
詳細なアニメの美意識の画像を作成してください。表情豊かな瞳、なめらかな網掛けセルの色使い、はっきりした線画を使用します。アニメのシーンに典型的な身ぶりと雰囲気で、心情と登場人物の存在を強調してください。
下記条件のnote見出し画像をサイズは横長で作成してください。サイズは必ず横長で作成してください。
添付した画像のキャラクター（クロ助）を登場させてください。
## 見出し画像案
### デザインコンセプト
- 背景: 土曜の午後、デスクの上にSurface Laptopが置かれ、画面にAnythingLLM Desktop のチャット画面が開いている。画面の左側にFoundry Localの「Unhandled exception」のエラーログが小さく表示され、右側にAnythingLLM 内蔵Ollama × Qwen3 1.7B が日本語で応答している"代替経路成功"の対比構図。窓から差す午後の少し傾いた光。ワークスペースはディープブルー×アンバー（動かなかった理想と、動いた実機の対比）の濃いめのグラデーション
- メインビジュアル: 中央にクロ助（ダークブラウン・ウェーブヘア、丸眼鏡、クリーム色ケーブルニット、少し困った表情から優しい笑顔への変化）。片方の手で「動かなかった」エラー画面を指差し、もう片方の手で「動いた」AnythingLLM応答画面を指差す対比ポーズ。画面の周りに「HTTP API ❌」「内蔵Ollama ⭕」「RAG ⭕」「ハルシネーション観察」などのバッジが薄く光って浮かんでいる
- テキスト要素:
- 上部（白・太字・30pt）: 「動かなかった、それでも立った」
- 中央（ゴールド・特大・48pt）: 「半分着地」
- 下部（白・細字・22pt）: 「ローカル業務RAGを308日目に書く土曜日」
- 装飾: NPUチップアイコン（紫色のスパイク・Day300_2のNPU 100%象徴を継承するが、今日は影として薄く）、ローカルRAGの矢印（Markdown → AnythingLLM Embedder → LanceDB → 応答 の循環）、エラーログの赤い波線、午後の柔らかい光粒子、「半分着地」のバッジ
### 作成手順
1. スライドサイズ（1536×1024px）の横長フォーマット
2. 背景にディープブルー×アンバーの落ち着いたグラデーションを設定（土曜午後の光×動かなかった理想と動いた実機の対比）
3. メインビジュアル：クロ助を画面中央に配置（左手で「動かなかった」エラー画面を指差し、右手で「動いた」AnythingLLM応答画面を指差すポーズ）
4. 画面の中央左側：Foundry Local の Unhandled exception エラーログを半透明で表示
5. 画面の中央右側：AnythingLLM Desktop のチャット画面（Qwen3 1.7B が日本語で応答中）を半透明で表示
6. 装飾要素：NPUチップアイコン（薄く・影）、ローカルRAGの循環矢印、エラーログの赤い波線、「半分着地」のバッジ
7. テキストを3段構成で追加（上「動かなかった、それでも立った」/ 中央「半分着地」/ 下「ローカル業務RAGを308日目に書く土曜日」）
8. 下部中央寄りに「YaroTech」のロゴを12ptで控えめに配置
9. 全体のバランスを確認して完成#YaroTech #生成AI #AI活用 #ローカルLLM #SnapdragonXElite #SurfaceLaptop #NPU #FoundryLocal #AnythingLLM #ARM64 #業務RAG #Qwen3 #ハルシネーション #エッセイ #実演 #継続は力なり
いいなと思ったら応援しよう！
記事がお役に立てたなら嬉しいです！
いただいたチップは、新しいMCPツールの検証や、より深い実践実験の資金として大切に使わせていただきます。
あなたの応援が次の「AI活用の感動」を生み出す原動力になります✨
一緒に羽ばたき続けましょう！