概念

ローカルLLMの使い分けと推論最適化

Kurage製品群におけるローカルLLMの必須／差し替え／任意／不要という四類型の使い分けと、推論最適化の要点。

ローカルLLMとは、クラウドAPI（OpenAI APIなど）を介さず、自分の端末・サーバ上で直接実行する大規模言語モデルと、それを支える実行環境・最適化技術の総称です。個人開発やOSSプロジェクトで、コスト削減・データ秘匿・オフライン運用のために広く使われています。Kurageシリーズ（kurage）では、gemma 4 12Bをollama経由で動かすパターンが事実上の標準であり、量子化版のgemma4:12b-it-qatとして固定されています。Gemma 4は思考型モデルであるため、各APIはthink: falseを必ず指定します。この方針はLP群（kurage-lps）と公開repo群（kurage-repos）の両方に一貫して現れ、「ローカルAI」「ローカルGPU」「外部のAI事業者に送信しない」ことを売りにする設計に結びついています。商品カタログ（kurage-products）を横断しても、この「手元の gemma4 で動かし、意見・住所・音声・書類を外に送らない」という宣言がほぼ全製品の概要文に反復されます。

2026年5月18日から10月24日までの全600本におよぶ記事索引（kurage-articles-index）を横断すると、ローカルLLMは「動かす」段階から「同じGPUでどれだけ速く・小さく・正確に動かすか」という推論最適化の段階へ重心が移っていることが読み取れます。索引にはollama llama.cpp 量子化 edge-ai 系のタグが付いた記事が継続的に並び、日次AIニュースシリーズ（ai-news）にも小型モデル・量子化・ローカル実行の話題が毎回のように登場します。とくに後半は「Apple Silicon／MLX」「WebGPU」「エッジAI」「軽量モデル」の記事が毎週のように現れ、実行環境そのものがニュースになる状況です。

ただし索引は「タイトル＋タグ＋URL」の一覧であり、本文の内容を保証するものではありません。日次ニュース記事は速報性が高く後日訂正されうること、同一テーマ（Qwen、Gemma 4、量子化手法など）が多数の日次記事に分散して言及されること、「〜で読む」形式のタイトルは見出し語の組み合わせで生成されていることに注意が必要です。タグ検索だけでは横断把握に不足するため、本ページのような概念ページ側で束ねる必要があります。

そして商品カタログ（kurage-products）が示す最大の特徴は、「ローカルLLMをどこでも使う」のではなく、製品ごとにLLMの関与度を意図的に使い分けていることです。本ページは、その使い分けの型と、そこで前提になっている推論最適化の知見をまとめるものです。

KurageにおけるローカルLLMの位置づけ

公開repo群を横断すると、ローカルLLMは「OSS本体は無料・LLMなしでも動き、AI判断レイヤーだけを差し替えられる」オープンコア設計の選択肢の一つとして位置づけられています。代表的パターンは次の三択です。

rule_based：外部LLMを使わない決定論的処理。クローン直後でも安全に動くデフォルト実装
local_llm：ollama上のgemma 4など、自前GPU・自前サーバで判断する実装
x402：ホストされた有料判断APIをHTTPで利用する実装

kfreqaiは初期状態をrule_basedとし、ニュースリスクチェックや流動性サイズチェックをx402で購入できるメータードブレインを併設します。kfxaiも同じ三択を持ち、local_llm障害時にはルールベースへ安全にフォールバックします。kfxbrain・kcbrain・ksbrainは自前運用の選択肢としてローカルGemma 4を標準に保ちつつ、有料レールではdeepseekへ切り替え可能です。url2brainやkurl2grも「ローカルOllamaのGemmaまたはDeepSeek」のどちらでも動かせるため、同じ頭脳をローカルとクラウドの両方で使う思想が製品横断で共有されています。

この三択は判断API（ai-judgment-backend）に限りません。商品カタログ（kurage-products）では、より一般化した「設定1行でAIを差し替える」型が主流になっています。kcallai（通話AI分析）とkadsai（広告AI分析）は、AI要約のバックエンドを Claude Code・Codex・OpenAI互換API・社内LLM から設定1行で選べ、しかもAIが無くても規則ベースの日報が出ると明記します。kurage-light-chatbotは「OpenAI互換APIなら何でも（既定はDeepSeek・1回答1円前後）」、kocrworkはOCRエンジンと生成AIの使い方（使わない／OCRの文字から／画像を直接見て）を画面で切り替える構成です。つまり「ローカルLLMかクラウドか」という二択ではなく、判断層を宣言的に差し替え可能にすることが設計の中心にあり、ローカルLLMはその中の一つの実装に位置づけられます（config-declared-scope）。

主要なモデルと実行環境

モデル：gemma（Google）が最も広く採用され、gemma4:12b-it-qatとして固定されています。ほかにもqwen、deepseek V4 Flash、kimi K3、glm-5.2/5.3、mistral系、tencent Hy系などオープンウェイトモデルが中心です（open-weight-model）。記事索引（kurage-articles-index）では「DeepSeek V4 FlashがMacで動作」「Gemma 4とllama.cppで読むローカルLLM最適化」「Qwen3.8-27Bのローカル実行能力」「Kimi K3-256kの登場とGemma 4をMacで動かす技術」「Deepseek V4 FlashとDGX Sparks：ローカルLLMの処理速度競争」など、モデル別の実行ノウハウが多数公開されています。小型・エッジ向けでは LFM2.5、LFM2.5-VL-3B、LFM2.5-DSpark、Needle2、MiniCPM5-2B、Qwen3.8-Flash-Next、Ternary Bonsai 2、Kolibri-1（最大100万トークンのコンテキスト）、Ornith-1.0、Holo4 といった軽量・高効率モデルの話題も反復します。日本語用途では、kouchou-ai-local-kitが Ollama + ELYZA-JP-8B の組み合わせを実機検証しており、Gemma 4 以外のローカル選択肢も実運用に乗っていることが分かります。
実行環境：ollamaとllama-cppが代表的で、Apple Silicon向けMLXやvllmも選択肢です。記事索引には「Apple Siliconで動くローカルAIの進化」「iPhoneで実現するローカルAI最前線」「Gemma 4とApple Siliconで進化するローカルAI環境」「Apple M7／M6チップとローカルAI」「Apple SiliconとMLXが切り拓くローカルAIの最前線」などApple系の実行記事が継続的に並び、開発環境のローカル完結が進行していることがわかります。ブラウザ上での実行（Gemma 4 E2B + WebGPU、Hugging FaceのWebGPU対応）や、llama.cppのMCP対応、llama.cppの進化・Mac高速化、NVIDIAによるllama.cpp買収の噂、AMD ROCm 10.0への期待、mojoのオープンソース化など、実行基盤そのものがニュースになる状況です。音声側ではwhisper.cpp（kurage-ai-momが自社サーバー内の文字起こしに採用）が定番です。
思考型モデルの扱い：Gemma 4は思考型のため、Kurageの各APIは必ずthink: falseを指定します。ブローカーや外部APIへ配送する前に、ローカルで判断を完結させられることが重要な利点です。
埋め込み（Embedding）：kronten（論点AIマップ）のように「埋め込みもAIも手元で動き、声を外部に送らない」と明記する製品があり、LLMだけでなくベクトル化もローカルで行う構成が標準になりつつあります（rag）。

推論最適化の技術

記事索引が示すローカルLLMの技術的な焦点は、モデル選定よりも「同じハードウェアでどう速く動かすか」に移っています。索引から抽出できる主要な系統は次のとおりです。

量子化：QAT（量子化を意識した学習）とKVキャッシュ量子化でローカルLLMの性能が飛躍的に向上したという実測記事が代表的です。Kurage標準のgemma4:12b-it-qatもこの流れの産物です。ほかにもbitsandbytesの新量子化手法DS4 Pro、Qwenの超軽量量子化技術、Ternary Bonsai 2、Voodoo Dynamic Quant（MITライセンス公開）など、手法名が次々と登場します。
モデル圧縮・蒸留：Tencentによるモデル圧縮技術、MiniCPM系の小型化、MoE構成、蒸留（Distillation）といった話題が継続します。iPhone上で35B MoEモデルを動かす記事のように、小型モデルでも高い性能を出す方向性は、local_llmを判定に使える範囲を広げます。
推論エンジンの高速化：llama.cppによるMac高速化、vllmの高速化、LiquidAIのLFM2.5によるCPU推論効率化、UkisAIのSwift-Qwen／Swift-QuantによるQwen高速化、mojoやCerebras CS-4、Warp、Sentence Transformersの埋め込み最適化など、実行側の最適化が独立したトピックとして扱われます。
エッジ実行：NVIDIA Magpie TTSと軽量LLM Needle2、LFM2.5-VL-3B、PrismMLとQualcommのエッジAI、WebGPUによるブラウザ内推論、iPhone上での実行など、クラウドを経由しない実行形態が広がっています。製品側でもknisaのように「入力した取引はブラウザの外に出さない」計算を謳うものがあり、LLM以前にデータを端末内に閉じる発想が共通します。
音声・画像・音楽への拡張：audio.cppの音声モデル進化、whisper.cppによる日本語文字起こし（47秒の会議音声を27秒・文字誤り率2.7%）、PDFMathTranslateによるPDF翻訳（15ページを3分・費用0円）、ACE-Step 1.5 Turbo XLとHeartMuLa oss-3Bを同じ日本語歌詞で比較した楽曲生成、Kitten-TTS 2、IBM Granite Speech 5.0、ERNIE画像モデル、Wan2.1 + ffmpegによる動画生成など、LLM以外のローカルAIも同じ「自前GPUで完結させる」思想を共有します。
思考型モデルのコスト制御：思考型モデルはthink: falseを明示しないと推論コストと遅延が増えるため、Kurageでは全製品で明示指定します。PDF翻訳の実測記事では思考型モデルに切り替えると5.8倍遅くなると報告されており、これはプロンプトではなくAPI・実装レベルの最適化だと言えます。

Kurageシリーズでの活用

設計・開発支援

karchitectはローカルAI（Gemma 4）で動くオープンソースのAI設計スタジオです。曖昧なアイデアを要件JSONとシステム設計書へ育て、discover → clarify → specify → plan → design → review → readyの仕様駆動フローを持ちます。処理は外部AI事業者へ送信されず、LLM障害時もユーザー回答を失わないフォールバック保存を備えます。商品版では「Ollama互換のLLMを別途用意する必要があり、PHPのレンタルサーバーでは動かない」ことが明記され、ローカルLLM製品における実行基盤要件の例外であることが対照的です。
商品カタログには、AIエージェントに設置・改変を任せる前提の製品が多いことも特徴です。kvgwcは「AIにアプリを書かせる手順」、kreserveやkcaldavは「Claude Code等に安全に変更を頼むための設計マニュアル」を同梱します。ここでのAIは判断エンジンではなく、設定ファイルを書き換える作業者として登場します（ai-modifiable-software）。

文書校正・業務支援

kproofreadは日本語の化学試験結果報告書を対象にした校正・照査システムです。必須項目・数値整合性・識別情報・OOS記録を決定論的ルールで確認し、textlintで日本語表現を校正し、ローカルOllama上のGemma 4 12Bが本文と表の意味的矛盾を補助照査します。測定値・規格値・合否判定は自動変更せず、元ファイルを外部LLMへ送信しません。
paperless-ngxやpdfmathtranslate-japanese-kitのように、OCR・PDF翻訳といった文書処理を自社サーバ内で完結させる導線も索引に多数現れます（whisper.cppによる日本語文字起こし、AI議事録の自動化、日本語OCRで見出しが壊れる事例の実測など）。
商品カタログでも、kurage-ai-mom（Whisper＋AI議事録）、kocrwork（AI-OCR）、kurage-fillout（申請書記入）が「書類・音声を社外に出さない」ことを製品の中核に据えます。とくにkocrworkは、印刷注文書なら生成AIなしで全項目一致、手書きFAXは生成AIに画像を見せると一致率33%→93〜97%という実測を示し、ローカルAIの効果を測って見せる形になっています。

行政・シビックテック

ローカルLLMの「外部に送らない」性質が、意見・住民の声という機微なデータを扱うcivic-tech領域でとりわけ強く押し出されます。

kurage-bill-ai-interview（法案AIインタビュー）は、審議中の法案を出典つきで解説し、AIインタビューで賛否・理由・暮らしへの影響・懸念・提案を聞きます。生成AIは手元の gemma4 で動かし、意見を外部のAIサービスに送りません。作られた「意見のまとめ」は本人が確かめて同意したときだけ保存・公開され、公開意見は法案ごとに束ねられてkconsensusへ渡されます。
kronten（論点AIマップ）は、国会の発言・Xの投稿・ニュースコメント・アンケート自由記述から意味の近さで話題をまとめ、賛否を問える論点を立てます。埋め込みもAIも手元で動き、声を外部に送りません。MCP対応（mcp）。
kconsensus（合意形成AI・Pol.is互換）は、判定を手元のLLMで行い外部APIに一度も出しません。読み取り精度（75〜85%）と誤読を画面に表示し、票が足りないときは数字を出さず「足りない」と書く姿勢は、evidence-traceabilityと通底します。
kshuisho（質問主意書アシスト）は、置いただけなら外部AIやAPIに何も送らず文章も作りません。事務所内のAI（Ollamaなど）を設定したときだけ、言い換え検索と下書き作成が有効になり、下書きの引用は原文と一字一句照合して合わないものを出しません。
一方でkurage-seido-naviやkurage-chinjo-naviは「検索・判定にLLMを使わない」設計です。陳情の所管委員会は語の一致で選び、どの語で判定したかを画面に出し、当たらなければ「判定できませんでした」と表示します。同じ自治体向け製品でも、LLMを使う／使わないが用途で分かれています。
kouchou-ai-local-kitは、オープンソース「広聴AI」をOpenAIキーなし・完全ローカルで動かす実測キットです。Ollama + ELYZA-JP-8B とローカル埋め込みを組み合わせ、意見48件の分析が2分33秒・API費用0円（RTX3090実測）。政治団体・自治体・労組など、意見データを外部クラウドに置けない組織向けの構成で、no-external-data-egressの代表例です。
開発中の無料枠（kurage-ai-soudan-chat、kurage-subsidy-navi、ktochi、kshoken、kkyufu、kkaigo）は、いずれも「公開データから規則で絞り込み、その結果をAIが説明する」型です。AIは候補抽出に関与せず、説明だけを担います。
ktoshikeikaku（都市計画ナビ）とkhisai（被災者支援ナビ）は、AIチャットを備えつつ「答える材料を原文・本文だけに限定する」型です。前者は条文を原文のまま引用し、後者は内閣府資料の本文だけを材料に答え、被害の程度は規則で先に示します。

文書処理・OCR・申請書

kocrwork（AI-OCR）は、OCRエンジン（PaddleOCR・Tesseract＋OCRmyPDF・Docling・生成AIの直読み）と生成AIの使い方（使わない／OCRの文字から／画像を直接見て）を画面で切り替え、同じ書類を読み比べられます。見本では印刷の注文書は生成AIなしで全項目が正解と一致し、手書きFAXは生成AIに画像を見せると一致率が33%から93〜97%へ上昇しました。すべて自社サーバーで動き、生成AIもローカルのモデルを選べます。
kurage-fillout（申請書記入アシスト）は、Word・Excel・PDFの空欄を「今日の日付・保存した会社情報・自分が書いた値」の3つだけで埋め、分からない欄は空のまま残します。AIに文章は作らせず、ローカルLLMで動くためファイルも会社情報も外部へ出ません。ただし共有レンタルサーバーでは動かずVPS・専用サーバーが必要で、self-contained-php-appの原則から外れる数少ない製品です。
kurage-ai-mom（AI議事録）は、自社サーバー内のWhisper（whisper.cpp）が文字起こしし、AIが議事録の下書きを作ります。人が録音と全文を見比べて承認したものだけが確定議事録になる設計で、AIは承認できないようコードで関門を強制します（approval-workflow）。録音を外部クラウドに上げられない会社・士業・医療・自治体向けで、MCP同梱により確定議事録がAIの調べもの先になります。

自動日報・マーケティング

kcallai（通話AI分析）は、トビラフォン Cloud の着信通知メールと PLAUD の文字起こしを毎朝取り込み、成約・失注・検討の判定、失注理由、折り返し漏れ、金額トラブルの兆しを規則で抽出してLINEへ流します。AI要約は設定1行で差し替え可能で、AIが無くても日報が出る設計です。
kadsai（広告AI分析）も同型で、同じ曜日の過去4週との比較、成果ゼロ検索語の除外候補、除外キーワードの衝突、予算負け・順位負けを規則で指摘します。設定変更は人が承認したものだけ実行します（approval-workflow）。
kmentionは、ChatGPTなどに自社が何番目に挙がったかを毎週記録し、強化すべきキーワードの抽出とページの下書きまで作りますが、判定にAIを使わない（OpenAIのAPIキーも不要）と明記します。
ktrackgeoはGPTBotやClaudeBotの来訪を実測する製品で、GAがボットを除外するために見えない「AIに読まれているか」を可視化します。ktrackgeoseoはSEO・AEO・GEOをまとめて診断しますが、判定に生成AIを使わないと明記します。ai-search-optimization領域でも、判定は決定論・生成は限定という分担が徹底されています。
khyogen（広告表現チェック）はURLだけで景品表示法・特商法・業種許可を点検しますが、「判定にAIは使わず、PHPを置くだけで動く」と明言します。

防災（規則が結論、AIは言い換え）

kbousai（防災AIチャット＋防災判定セット）は、避難すべきかの結論を内閣府「避難情報に関するガイドライン」の警戒レベルに合わせた決まった規則で出し、AIはその結論を質問に合わせて言い換えるだけで結論を変えません。AIが止まっていても規則の答えとカードはすぐ出ます。deterministic-coreの最も明示的な実装例です。
同じ姿勢はhazard-map-judgment系の製品群（kurage-flood-hazard-map、kurage-landslide-hazard-map、kurage-tsunami-map、kurage-refuge-map、kurage-disaster-risk-area-map、kurage-morido-map、kurage-earthquake-map、kurage-juyo-saigai-check、kurage-disaster-judgment-set）にも共通し、判定は決定的コード、AIは説明の層に限定されます。ここでは「区域外」と「未収録」「判定対象外」を区別するunknown-vs-outside-distinctionが中核設計になります。kurage-earthquake-mapのようにLLMを一切持たずPython＋SQLiteだけで動きながらMCPサーバーを同梱する製品もあり、MCP対応はローカルLLM内蔵を意味しません。

ナレッジ・検索・SEO

openkbで自社ナレッジのAI相談窓口とWikiを構築した事例では、gemma4 12bとDeepSeekは「コンパイル」と「回答」で効き方が異なると報告されています。ベクトルDB不要のrag「PageIndex」の解説もあり、ローカルLLMとDeepSeekでの実測が紹介されています。
fessは日本発の全文検索OSSで、Dockerで立てた索引に対してローカルLLMで「聞けば答える」構成が実測されています（検索10/10・回答9/10）。
kgeoはGEO Optimizerを監査エンジンに、日本語AEO採点とグラウンデッドLLM評価を重ねるai-search-optimizationツールです。
kseoは日本語サイト向け技術SEO診断で、判定はすべて決定論的チェックで行い、言語モデルは改善案の文章生成だけに使います。無料枠・管理者は自社GPUのGemma、有料実行はDeepSeekという役割分担です。これはdeterministic-coreの考え方と親和性が高い構成です。
kgrowthはGSCとアクセスログを統合した週次グロース自動化で、ローカルLLMで「固有名詞SEO」を自動化した事例も索引に含まれます。
kurage-light-chatbotは逆方向の事例で、本体は1ファイルPHP・DB不要のまま、LLMはOpenAI互換APIなら何でもよい設計です（既定はDeepSeek・1回答1円前後）。「ローカルLLMでなければならない」のではなく、「差し替え可能な判断層」としてLLMを外付けする発想がここに現れています。
kcheckitは「見ておきたいサイトの差分を毎日拾い、自社に関係しそうなものだけを理由つきでメール通知」する製品で、LLMを使わずRSS・API・HTML差分・SSL期限の4方式で実現します。ローカルLLM以前に、規則で足りる仕事を規則に留める姿勢がここにも表れます。

トレーディング領域

トレーディング領域はローカルLLMのユースケースが最も広い分野です。判断APIにはブローカー認証情報を渡さないtrust-boundaryが共通し、初期状態をpaper-tradingに固定するプロダクトが多いのも特徴です。

kfreqai：Freqtrade/FreqAI（LightGBM）を土台にした暗号資産用AIトレードシステムで、現在はdry-run運用です。ローカルGemmaが市場レジームの判定（毎時）、リスク指示（1日3回）、取引後レビュー（毎時）、改善仮説（毎日）を担当します。仮説は制約付きDSLで表現され、約160ペアのバックテストを経て採用候補になります。初期状態はrule_basedでLLM・GPU・APIキー不要です。索引には特徴量設計（相関ペア追加で赤字が黒字に反転した検証）やentry_thresholdの罠を扱う記事も並び、LLMの自己反省・自己改良ループを組む実験も記録されています。
kfxai：OANDAのAPIを使うFX自動運用ボディです。paper／practice／liveの3モードを持ち、liveは環境変数と確認文字列の二重明示なしでは起動しません。判断レイヤーはルール／OllamaのGemma 4／有料x402 APIから選択でき、AIは注文API・認証情報・注文数量を持ちません。
kfxbrain・kcbrain：FX・暗号資産向けの構造化判断API群です。kfxbrainは、固定コミットでvendorしたtradingagents・fingpt・ai-hedge-fund・finrobot・finmemの知能をGemma 4向けHTTP APIとして公開します。判断だけを返し、モデルが失敗した場合はテンプレートや別LLMへ黙ってフォールバックせず、明示エラーを返します（oss-vendoring）。
ksbrain：日本株向けの根拠追跡APIです。ollamaへ直接接続し、価格・財務・開示・ニュース・市場環境を評価します。/v1/evidenceで登録した証拠IDと分析結果のevidence_idsを突合するevidence-traceability設計で、資料が足りなければ「証拠不足」と正直に返します。J-Quantsキーが無い場合もデータを捏造せず503を返します。
kfinanalyst・ktajp：金融レポート／株式分析のマルチテナントSaaSです。一般ユーザーの分析はDeepSeek固定、adminのみ運営内部のローカルLLM・課金対象外という役割分担になっています（tenant-isolation）。
nofx：「戦略そのものが言語モデル」を掲げるオープンソース取引ターミナルです。モデルは市場構造を読んで判断・実行・理由記録のループを回しますが、Goランタイムがポジション上限・レバレッジ上限・交換所側の損切り／確率を強制し、モデルはそれらを覆せません。日本語モードではAI推論の表記だけを日本語化し、取引アクション値は英語に保つ安全設計です。稼働環境ではDeepSeek、ローカルLLMへの切替も選択できます。
openalice-jp：x402対応のAIエージェント化やHyperliquidへの非カストディ委任など、判断と執行の分離をさらに推し進める設計が続いています。

営業・商談・バックオフィス

kdealdesk（Deal Desk）は、商談の記録と自社の製品・価格・資料（ナレッジ）を根拠に、AIが次の提案を考え、答えには使ったナレッジを出典として付ける製品です。打ち合わせメモやメールを貼るとAIが記録の下書き（日付・次にやること・期日）を作りますが、担当者が承認したときだけ記録に入ります。顧客台帳を持たずCSV・API・WebhookでCRMにメールアドレスでつなぐ設計で、PHP 8＋SQLiteのまま動きます。
kurage-ai-meishi-analysis（名刺管理）は、AIが12項目を読み取って下書きに登録し、人が原本画像と見比べて承認した分だけ台帳へ入れます（approval-workflow）。
kurage-crm-agent（入力ゼロCRM）は、日報からAIが顧客・商談・活動を下書きに起票し、人が1タップで承認します。台帳にAIは直接書けない安全設計です。
kurage-line-crmは、LINE公式アカウントの相談を相手ごとに記録する窓口で、「対応済みにしても新着が来れば自動で未対応に戻る」というフラグレス設計を持ちます。MCPサーバーを同梱し、AIとの対話から「未対応は何件？」「この会社の経緯を3行で」を引ける一方、顧客への送信ツールは既定で無効化されます。
kurage-hr-postは「職（ポジション）」に記録を紐づける人事製品で、達成率はコードが決定的に計算し、AIに採点させません。kurage-kintaiも顔照合の正否をサーバーの決定的コードが決め、AIに委ねません。kninteiは要介護認定の55問を条文・定義つきで示しますが、要介護度そのものは判定しません。
これらはkocrworkやkurage-ai-momと同じく「AIは下書き、人間が承認」という共通の型を持ち、ローカルLLMの誤りを業務データへ直結させない構造になっています。
決済・請求系（kbilling、kpaylink、kinvoice）、受発注（kweborder）、ファイル共有（kfileshare）、取引先照合（ktorihiki）、建設業許可の期限管理（kkensetsu）、民泊可否（kminpaku）はLLMを使わず、DB不要・PHPのみ（またはSQLite）で完結します。ローカルAIの射程は「判断が要る仕事」に限定されていることが分かります。

コンテンツ生成・運用

aimediapost：テキストを音声ナレーション・BGMミックス・字幕MP4・SNS投稿文へ変換する自律メディア生成ツールキットです。TTSバックエンドは外部APIでもVoiceVoxのローカル実装例でも動かせます。
kurl2gr：休眠サイト向けに、サイト概要を土台とする調査記事を継続追加するプロダクトです。GPT Researcherの調査部分と、サイト理解・記事化のLLM部分を分離し、後者は自社GPU上のGemma 4（rqdb4aiのホスト別キュー経由）またはDeepSeekで実行します。調査は非同期ジョブです。
kmontage：ローカルLLMでショート動画の台本を作成し、元ネタだけを根拠に12シーンを組み立てます。品質ゲートを通らない台本は作り直し・停止します。
url2brain：URL解析からSNS告知文とブログ記事を生成する頭脳です。OSS版はローカルOllama上のGemma 4を既定とし、無料で自前運用できます。投稿は行わず、既存の投稿ツールへ委譲する安全モデルです。
kurage-voice-pro：UMediaとOSS Voice-Proをつないだ翻訳字幕・吹き替え動画生成で、TTS・字幕・ffmpegを自前パイプラインに組み込みます。公開APIが直接叩かれたインシデント記事は、ローカル完結の利点と公開時の守りを同時に示す事例です（agent-security-incident）。
kvtuber：ブラウザ型AI VTuberの配信ランタイムです。VTuberが作業依頼をkurage-agent-deckのAgent Taskへ渡し、成果物を返すagent-executing-vtuberを志向しています。配信キャラクターの判断をローカルLLMで支える余地があります。
klogogen：画像モデルERNIEを自前のローカルGPUで動かしており、外部の画像生成APIに依存しない事例です。LLMではありませんが、ローカルAIの思想を共有します。

障害監視とセルフホスト運用

kzabbixは、Zabbixが検知した障害をローカルGPU上のGemma 4 12Bが調査し、概要・時系列・ログ解析・原因候補と確度・推奨対応をレポート化します。機密ログは外部へ送らず、メールと限定ブログ（bludit）へ配信します。索引にはメモリ99.8%障害のような実障害で「犯人が証拠に写っていなかった」実録も含まれ、ローカルLLM運用の限界と手順が記録されています。
ksecwatch（改ざん監視）とkseccheck（URL診断）は、いずれもAIを使わず決定的な検査で判定します。前者はYARAによるマルウェア検査、後者は「攻撃に近い検査はしない」という制約を明示します。
記事索引には、krayin-crm-japanese-kitやdocuseal、vikunja-japanese-kit、docmost-japanese-kit、zammad、espocrm-japanese-kit、freescout-japanese-kit、libredesk-japanese-kit、planka-japanese-kit、billionmail-japanese-kit、docspell-japanese-kit、appsmith、codealmanac-japanese-kit、decap-cms-japanese-kit、openvpm、theyworkforyou、alaveteli、fixmystreetなどOSSの日本語化・セルフホスト導入ガイドも多く含まれ、self-hostingの流れとローカルLLMが組み合わさっています。これらのキットは「公式手順どおりでは動かない箇所を実機で測る」というmeasured-pitfall-catalogの型を共有し、日本語検索・OCRの穴（japanese-search-gap）を埋める知見を蓄積しています（oss-japanese-localization）。

商品カタログから見える四類型

商品カタログ（kurage-products）を横断すると、LLMの関わり方は次の四類型に整理できます。価格帯もこれに概ね対応し、LLMを中核に据える製品は110,000円以上、判断層を差し替える分析製品は220,000円、決定論的処理だけで完結する製品は55,000円が中心です。

類型	意味	代表製品
ローカルLLM必須	判断・対話・生成の中核をローカルモデルが担う。外部送信なしを製品価値にする	kurage-bill-ai-interview、kronten、kconsensus、karchitect、kurage-fillout、kouchou-ai-local-kit
判断層を差し替え（設定1行）	Claude Code／Codex／OpenAI互換API／社内LLM／ローカルOllamaを同じ製品で選べる。AI無しでも動く	kcallai、kadsai、kocrwork、kurage-light-chatbot、kdealdesk
任意接続（設定すると有効）	素の状態ではLLMなしで動き、事務所内のOllama等を設定したときだけAI機能が現れる	kshuisho、kurage-ai-mom（下書き生成）、ksbrain（証拠不足を返す）、ktoshikeikaku・khisai（本文だけを材料に答える）
LLM不要（規則で判定）	判定・検索を決定論的ルールに閉じ、AIは説明の言い換えや下書きに限定、あるいは使わない	kbousai、kseo、ktrackgeoseo、kmention、khyogen、kurage-seido-navi、kurage-chinjo-navi、kurage-kintai、kurage-hr-post、knintei、kseccheck、kcheckit

この整理から読み取れるのは、「ローカルLLMを使うこと」自体が目的なのではなく、外部に送れないデータを扱う製品ほどローカルLLMを必須とし、判定の正しさが問われる製品ほどLLMを脇に置くという使い分けです。前者はno-external-data-egress、後者はdeterministic-coreとして、それぞれ別の概念ページで捉えられます。

さらに、MCP同梱（mcp）は「ローカルLLMを持つ製品」に限らず、LLMを一切持たないkdbagentやkurage-earthquake-map、kurage-line-crm、knisaにも広がっています。これは、判断層を製品の内側に閉じ込めるのではなく、外側のAIエージェントに道具として渡すという第三の道であり、ローカルLLMの使い分けを「内蔵するか否か」の二択から解き放つ設計です。

商品カタログ全体の前提として「全商品ソース同梱・AIエージェントで改変拡張可」が掲げられており、kappstore-ecosystemやk-prefix-product-naming、sales-partner-systemといった販売・提供の仕組みと、ローカル実行（self-hosting）がセットで設計されている点も見逃せません。

技術的な要点

量子化（QAT、KVキャッシュ量子化など）や蒸留、モデル圧縮により、小規模モデルでも高い性能を実現します。Gemma 4 12Bのgemma4:12b-it-qatもその一例です。
Apple SiliconやMac上での実行が進み、開発環境のローカル完結が広がっています。WebGPUによるブラウザ内実行も現実的な選択肢になりました。
思考型モデルはthink: falseを明示しないと推論コストと遅延が増えるため、Kurageでは全製品で明示指定します。PDF翻訳で5.8倍遅くなるという実測がその根拠の一つです。
機密データを外に出さない利点が、karchitect・kproofread・kzabbix・kurage-fillout・kurage-ai-mom・kurage-line-crmなど「外部AI事業者へ送信しない」ことを価値として明示するプロダクトに結びついています。
ローカルLLM単体の性能・安定性の限界は、x402による従量課金APIや、kcallai・kadsaiのように Claude Code／Codex／OpenAI互換API を設定1行で差し替える併用で補うパターンが確立しています。
複数ジョブ環境ではrqdb4aiのホスト別キューでGPU競合を避けます。
kseoやkbousai、ktrackgeoseo、kmention、khyogenのように判定を決定論的ルールに閉じ、LLMを言い換え・改善文生成など限定用途に使うdeterministic-core設計も広がっています。kurage-kintai（顔照合）やkurage-hr-post（達成率）、knintei（要介護度を判定しない）は「AIに採点・判定させない」ことを明示する例です。
ローカルLLMを必須とすると、共有レンタルサーバーでは動かずVPS・専用サーバー・GPUが必要になります（karchitect、kurage-fillout）。self-contained-php-appの「FTPで置くだけ」原則とローカルLLM必須は両立せず、製品ごとに実行基盤の要件が分かれる点に注意が必要です。
逆に、LLMを使わない製品では「入力はブラウザの外に出さない」だけで非送信性を担保できます（knisa、ktoriteki、kchingin）。非送信性の実現手段は、ローカル推論だけではないことに注意が必要です。
MCP同梱（mcp）が一般化し、ローカルで動くシステムのデータをAIエージェントの調べもの先・操作先にする流れが進んでいます。kdbagentは「宣言した表・列・操作だけを触らせる」config-declared-scopeの徹底例で、AIにDBを触らせる際のtrust-boundary設計として参考になります。MCPを持つことはLLMを内蔵することと同義ではありません。
記事索引（kurage-articles-index）をトピックタグで引くと、ollama llama.cpp 量子化 edge-ai 系の知見が継続的に蓄積されていることが確認できます。ただし日次ニュース群は同じテーマが分散しており、索引だけでは横断把握ができないため、本ページのような概念ページでの束ねが不可欠です。