2026-04

AI共生

【ローカルLLM】GUIからCLI(Ubuntu)へ移行して、PDF自動翻訳バッチを完全自動化・安定運用する設計手法

GUI中心のLM Studioから、Ubuntu上のCLI運用へローカルLLMをシフトし、PDF自動翻訳バッチをどのように設計するかを整理。ocrmypdfとllama-cli、DeepSeek-R1やGemma4を用いながら、IBM i 的な運用思想でAIを「使う」から「共に動かす」へ移行する道筋を解説。Ryzen AI 9 HX470
Windows 11

KB5083769(Build 26200.8246)徹底解説:Copilot+ PC と一般PCで何が変わったのか

AI時代のWindowsアップデート:Copilot+ PC と非NPU PCの違いを技術的に整理する2026/04、Windows 11 25H2 に適用された KB5083769(Build 26200.8246) は、単なる不具合修正...
AI共生

【ローカルLLMの限界】モデル選定とマニュアル翻訳の実践から見えた「コンテキスト解像度」の壁と対策

生成AIは便利だが、時に平然と“嘘”をつく。だからこそ私はクラウド依存を避けるために Local LLM を導入し自分の手元でモデルを動かすことに挑戦した。しかしPDFのページ数が増えた瞬間に精度が落ち前の文書の内容が混ざりモデルを eject して再読み込みするという作業を繰り返すことになった。この章では私が実際に行ったモデル選定PDF解析の試行錯誤そして「Local LLM の限界」をどう乗り越えたかをまとめる。Ryzen AI 9 HX470
AI共生

【ハルシネーション対策】生成AIの「嘘」を制御する:マニュアル翻訳バッチにLocal LLMを導入した理由と設計

生成AIを利用する際に最も重要なのは、AIを誘導しないことである。ユーザーが意識していないと、AIは欠損した情報を補完し、もっともらしい文章を生成する。以前の記事でも触れたように、存在しない製品の型番や仕様を提示するケースが確認されている。これは特定のモデルに限らず、生成AI全般に共通する構造的な特性である。本稿では、LM Studio を用いて複数の Local LLM を検証した結果をもとに、生成AIの特性と、AIとの共生に必要な視点を整理する。Ryzen AI 9 HX470
PR広告