行政機関や自治体で生成AIを活用する動きが広がるなか、重要になっているのが「行政文書をAIが読める形に整えること」です。生成AIに庁内文書や要綱、規程、議事録、申請書類を参照させるRAGでは、AIモデルそのものの性能だけでなく、元データの整え方が回答精度を大きく左右します。

行政文書のAI検索で起きやすい問題

行政文書は、人間が読むことを前提に作られているものが多く、AI検索にとっては扱いにくい構造を含んでいます。たとえば、PDF化された規程、Wordで作られた業務マニュアル、表形式の交付要綱、複数ページにまたがる申請様式などは、見た目としては整理されていても、AIから見ると文脈が途切れやすいデータです。

特に問題になるのは、文書内の「意味のつながり」が失われることです。人間なら、表の列見出しと数値、脚注、前後の文章、章番号の関係を自然に読み取れます。しかし、単純なテキスト抽出では、表が横一列の文字列になったり、ヘッダーと本文が混ざったり、ページ番号や注記が本文の途中に入り込んだりします。その結果、検索時に必要な文脈を拾えず、回答が曖昧になります。

さらに、行政特有の用語も障壁になります。利用者が「職員の副業ルール」と質問しても、文書側では「兼業許可」「服務規程」「営利企業等従事制限」と書かれている場合があります。言葉が違っても意味が近いことをAIが理解するには、文書の見出し、章立て、表、対象制度、担当部署などが適切に構造化されている必要があります。

Markdown化がAI検索に効く理由

Markdown化とは、文書を見出し、箇条書き、表、引用、リンクなどの構造を持つテキスト形式に変換することです。単なるプレーンテキストと違い、Markdownでは「ここは大見出し」「ここは小見出し」「ここは表」「ここはリスト」といった意味のまとまりを残せます。

たとえば、交付要綱をMarkdown化する場合、制度名をH1、対象者や補助率をH2、申請手順をH3、必要書類を箇条書き、補助上限額を表として表現できます。これにより、AIは単語の羅列ではなく、文書の階層や関係性を読み取りやすくなります。MicrosoftのMarkItDownも、LLMやテキスト分析パイプラインで使うために各種ファイルをMarkdownへ変換する軽量ツールとして公開されています。

ただし、Markdown化はゴールではありません。Markdownはあくまで、行政文書をAIが扱いやすい中間形式にするための入口です。検索精度を本当に高めるには、文書名、制度名、担当部署、対象年度、申請期限、金額、根拠条文、更新日などを構造化フィールドとして切り出す必要があります。

単なるテキスト化ではなく「構造化」が必要

PDFをテキスト化するだけでは、行政文書の意味は十分に残りません。特に表や申請様式は、行と列の関係が崩れると、AIが誤った関係を推測する原因になります。たとえば「令和6年度」「横浜市」「補助上限額」という情報が本来は同じ表の1行に属していても、抽出後に離れてしまえば、AIは別の制度や年度と混同する可能性があります。

そのため、行政文書のRAG化では、次のような情報を明示的に取り出す設計が重要です。

• 文書タイトル
• 制度名・事業名
• 担当部署
• 対象者
• 申請期限
• 金額・補助率
• 根拠条文
• 更新日
• 関連文書
• 公開範囲・機密区分

こうした項目をメタデータとして付与しておくと、AI検索は「全文から何となく近い文章を探す」のではなく、「該当制度の、該当年度の、該当項目を探す」動きに近づきます。行政実務では、この違いが非常に大きいです。

PDFパーサー選定で見るべきポイント

行政文書をMarkdown化・構造化する際には、PDFパーサーや文書抽出エンジンの選定が重要になります。代表的な選択肢には、LlamaParse、Unstructured、Docling、Marker、Google Document AIなどがあります。

LlamaParseは、複雑なPDFや表、画像を含む文書をLLM向けのクリーンなデータに変換する用途で説明されています。特に、PDFはもともと印刷物の見た目を保つための形式であり、HTMLのように構造が自然に備わっているわけではない点が課題です。

Unstructuredは、文書をTitle、NarrativeText、ListItemなどの要素に分解し、必要な要素を選択して処理できる仕組みを提供しています。これは、行政文書のように見出し、本文、表、注記、リストが混在するデータを扱う際に重要な考え方です。

選定時には、単に「変換できるか」ではなく、次の観点で比較するべきです。

• 表の構造を維持できるか
• 見出し階層を正しく判定できるか
• OCRノイズに強いか
• 日本語文書に対応できるか
• ローカル処理が可能か
• クラウド送信が許容される文書か
• API連携しやすいか
• 処理コストが運用に合うか

行政機関では、個人情報や内部資料を扱うため、クラウドAPIに投げられる文書と、オンプレミスまたはローカル環境で処理すべき文書を分ける設計も欠かせません。

チャンキング設計が検索精度を左右する

Markdown化した文書をそのままRAGに投入しても、検索精度が上がるとは限りません。RAGでは、文書を適切な大きさに分割する「チャンキング」が必要です。

小さく分けすぎると、必要な文脈が欠けます。たとえば、申請条件だけが検索され、対象者や除外条件が含まれないまま回答される可能性があります。反対に、大きく分けすぎると、検索対象が広くなりすぎ、回答生成時に不要な情報が混ざります。

LangChainのドキュメントでは、多くのユースケースでRecursiveCharacterTextSplitterが文脈維持とチャンクサイズ管理のバランスを取りやすい手法として紹介されています。

行政文書では、文字数だけで機械的に分割するよりも、見出し単位、条文単位、表単位、FAQ単位で分ける方が実務に合います。たとえば、交付要綱なら「目的」「対象者」「補助対象経費」「申請期限」「提出書類」「審査方法」をそれぞれ意味単位で分割します。

さらに高度な設計として、親子チャンキングも有効です。小さなチャンクで検索し、回答生成時にはその親となる大きな文脈を渡す方法です。これにより、検索の細かさと回答時の文脈保持を両立できます。

信頼性制御とUI設計もセットで考える

行政分野のAI検索では、「それらしい回答」では不十分です。回答の根拠となる文書名、該当箇所、更新日、担当部署を表示できなければ、職員は安心して使えません。

そのため、RAGシステムには、検索結果の確信度を管理する仕組みが必要です。確信度が高い場合は自動回答、やや低い場合は根拠文書を複数提示、低い場合は「該当文書が見つかりません」「担当部署へ確認してください」と返す設計が現実的です。

特に、国会答弁、住民の権利に関わる手続き、法令解釈、個人情報を含む問い合わせでは、AIに判断を委ねすぎる設計は危険です。検索できなかった場合に無理に推測させないことも、行政AIの品質管理では重要です。

実務導入のロードマップ

行政文書のMarkdown化とRAG活用は、いきなり全庁展開を目指すよりも、対象業務を絞って進める方が成功しやすいです。

最初に取り組むべきは、問い合わせが多く、文書量が多く、参照ミスが業務負担になっている領域です。たとえば、庁内規程、FAQ、補助金要綱、申請マニュアル、議会答弁資料、条例・規則集などが候補になります。

次に、対象文書を棚卸しし、PDF、Word、Excel、HTMLなどの形式を確認します。そのうえで、Markdown化、メタデータ付与、チャンク設計、検索テスト、職員レビューを繰り返します。

重要なのは、最初から完全自動化を目指さないことです。行政文書は誤回答の影響が大きいため、初期段階では人間のレビューを前提にし、どの文書で失敗しやすいか、どの表が崩れやすいか、どの質問で根拠不足になるかを確認する必要があります。

まとめ

行政文書のAI検索精度を高めるには、生成AIモデルの性能だけに期待してはいけません。PDFやWordを単にテキスト化するだけでは、表、見出し、条文、注記、担当部署、対象年度といった重要な文脈が失われる可能性があります。

Markdown化は、行政文書の構造をAIに伝えるための第一歩です。しかし、本当に重要なのは、その先にある構造化フィールドの設計、PDFパーサーの選定、チャンキング、メタデータ管理、確信度制御、UI設計です。

行政AIの実用化は、AIに文書を読ませることではなく、AIが誤解しにくい文書基盤をつくることから始まります。今後は、行政文書の標準フォーマット化、文書更新時の自動再構造化、回答根拠の監査ログ化、LLM-as-a-Judgeによる継続評価まで含めた運用設計が重要な研究テーマになります。