社内スキャンPDFを、ローカルOCRとローカルLLMだけで Markdown にするThis article explains how to convert scanned internal PDFs into Markdown using…

Converting scanned internal documents into clean, machine-readable text is a common bottleneck for organizations that want to modernize their knowledge base but cannot risk exposing confidential material. A recent write-up on Zenn describes a workflow for turning scanned internal PDFs, and Word files, into Markdown using only local OCR and a local large language model, with no data ever leaving the user's own machine. The premise matters because many teams stall at exactly this point: they want to summarize manuals or build training data from internal procedures, but policy, contract terms, or simple caution forbid sending the contents outside.

The author frames the approach as strictly self-contained. This is not about outsourcing documents to a vendor, the piece stresses, because even a contractor who promises not to use external LLMs still introduces leakage risk the moment the client hands over the files. In that framing, the only path that fully preserves confidentiality is to do the work yourself on hardware you control. That distinction, between "we don't use the cloud" and "the data never leaves this room," is the core argument.

Cloud OCR and cloud LLM services are undeniably convenient, and for many use cases they remain the fastest option. But the article targets a specific situation where those tools are simply unavailable, whether the block comes from an organizational policy, a signed agreement, or a subjective sense that the material is too sensitive to transmit. For teams in that position, tools like ChatGPT or Gemini are off the table regardless of their quality, so a fully local pipeline becomes the only viable route to digitizing and structuring documents.

The workflow breaks into two stages that map to two categories of local software. First, optical character recognition extracts raw text from scanned images or PDFs. Because scans lack an embedded text layer, OCR is the prerequisite step before any language model can reason about the content. Widely used local OCR engines in this space include Tesseract and PaddleOCR, and Japanese-language documents in particular often benefit from engines tuned for CJK character recognition, since layout and character density differ from Latin scripts. The output of this stage is typically imperfect, with recognition errors, broken line breaks, and lost structure such as headings and tables.

The second stage is where a local LLM adds value. Rather than treating OCR output as final, the model can clean up recognition noise, reflow text, and reconstruct structure into Markdown, restoring headings, lists, and tables into a consistent format. Markdown is a sensible target here because it is plain text, easy to version-control, and readily ingested by downstream systems such as retrieval-augmented generation pipelines and internal search tools. Running the model locally is now practical thanks to runtimes such as Ollama, LM Studio, and llama.cpp, which let users run open-weight models like the Llama, Qwen, or Gemma families on consumer hardware, including machines with a capable GPU or Apple Silicon.

It is worth noting the trade-offs that any local setup implies. Local models generally trail the largest hosted systems in raw capability, and processing speed depends heavily on available hardware, so throughput on a home or office PC is likely to be slower than a cloud API. Quality also hinges on the OCR step: if recognition is poor on a low-resolution scan, the language model can only do so much to recover meaning. These are the practical costs an organization accepts in exchange for keeping everything in-house.

The broader context is a growing industry interest in on-premises and on-device AI, driven by data governance, regulatory pressure, and privacy expectations. Sectors such as healthcare, legal, finance, and government frequently face the same constraint the article describes, where the utility of AI is clear but transmission is prohibited. Approaches like this one, which combine mature open-source OCR with increasingly capable open-weight models, appear to be filling that gap, offering a way to unlock document workflows without the confidentiality cost that cloud services impose. For readers evaluating such a pipeline, the takeaway is that a self-contained OCR-to-Markdown chain is a realistic option, provided the hardware and the tolerance for hands-on setup are in place.