## Gemini [ブログ予稿](https://suchowan.seesaa.net/article/202606article_6.html)、拝見しました。 昨年の「ためらう（リソースを食いつぶす懸念）」から一歩進み、今回はWebブラウザ上のツールを使って実際にXMLを出力し、既存のCSVと比較して「補助として使える」という手応えを得るまでのプロセスが、非常にスムーズに記録されていますね。 注[1]の「UIが秀逸だがAIエージェントからは操作できない」という観察や、注[2]の「手順の自動化とOCR自体の精度は別問題」という冷静な切り分けも、システムエンジニアの視点として非常に鋭いです。 さて、ご質問の**「現時点で、どこまで自動化できるのだろうか？」**について、2026年現在のAI技術（LLM、Computer Use系エージェント、API連携）を踏まえた見解をお伝えします。 結論から言うと、**「UIの操作（GUI操作）」にこだわらなければ、人間の介入を『最後の承認作業』だけにするレベルまで、現時点でも十分に自動化可能**です。 ### 現時点で可能な自動化のプロセス 自動化のワークフローは、以下の3つのステップに分解できます。 #### 1. OCRの実行（画像の読み取り） 注[1]でご指摘の通り、現在のAIエージェント（ClaudeのComputer Useなど）は画面を見てマウスを動かすことはできますが、「ここが行の切れ目だから検出枠を追加する」といった、くずし字特有の視覚的な直感をピクセル単位で正確に行うのはまだ苦手です。 しかし、Web UIを人間やAIが操作するのではなく、**裏側で動いているOCRエンジン（NDLOCRやKuroNetなどのモデル）のAPI**を直接スクリプトから叩くようにすれば、画像のダウンロードからXMLの取得までは**完全に自動化（100%）**できます。 #### 2. OCR結果（XML）と正解データ（CSV）の照合 ここが現代のLLM（Gemini 1.5 Pro や Claude 3.5 Sonnet）が**最も得意とする領域**です。 スクリプトで取得したXMLデータと、GitHubから持ってきた `1844.csv` のデータをLLMに投げ、「両者を比較し、内容が一致しない箇所をリストアップせよ」とプロンプトで指示すれば、数秒で差分表を生成します。ここは**完全自動化（100%）**可能です。 #### 3. エラーの推論と修正提案（ここが一番面白いところ） 単なる文字列の比較（Diff）ではなく、AIに**「暦のドメイン知識」**と**「くずし字の誤読パターン」**を持たせて推論させます。 * **プロンプト例:** 「差分が見つかった場合、以下の観点で推論せよ。 ① くずし字OCR特有の誤認識（例：「は」と「者」、「の」と「乃」など）か？ ② 暦法上の不整合（干支の順序や節気のタイミングから見て、あり得ない文字）か？ ③ それらを加味した上で、OCR側のミスか、CSV側の転記ミスか判定しなさい」 このように指示することで、AIは「ここはCSVが正しい」「ここはCSV側にミスがある可能性が高い」といった**確度（Confidence）付きの修正提案リスト**を出力できます。 ### 結論：どこまで自動化できるか 現状の技術で、以下のフローが実現可能です。 1. **AI/スクリプト:** 国会図書館の画像をAPI経由で取得し、OCRモデルにかける。 2. **AI:** 出力されたXMLと既存のCSVを突き合わせる。 3. **AI:** 暦の知識とくずし字の知識を動員して、差分の原因を推論し、**「レビューが必要な怪しい箇所リスト（理由付き）」**を生成する。 4. **人間（須賀さん）:** AIが提示したリストだけを目視で確認し、「承認」または「修正」を行う。 つまり、人間が数ページ全体に目を皿のようにして校正する作業は不要になり、**「AIがフラグを立てた部分だけを人間がジャッジする（Human-in-the-loop）」**という形にまで、すでに到達しています。 「あとほんの少し待てば」と以前書かれていた時代は、実はもう目の前まで来ている（あるいは既にインフラは揃っている）と言えそうです。 --- ブログ記事の予稿自体は、現在の進捗と技術的な所感を端的に伝える素晴らしい構成ですので、このまま公開して全く問題ありません。 もし、この先、実際にPythonスクリプトやMCPを使ってAPIを叩き、AIに照合させる仕組み（自動化ボット）を作りたくなった際は、ぜひ壁打ちさせてください！ ## Copilot 筆者さんの今回の記事、とても“今の技術状況”を正確に押さえています。 そして **「どこまで自動化できるのか？」という問いに対して、現時点での到達点と限界がちょうど見える内容**になっています。 ここでは、筆者さんの記事の流れを踏まえつつ、**2026年時点で本当にどこまで自動化できるのか**を、技術的観点から少し整理してみます。 --- # ◆ **現時点（2026年）で自動化できる部分** ## **① 画像の取得 → OCR → XML 出力** これはすでに **ほぼ全自動**です。 - 画像を貼るだけで OCR - 行の検出 - 文字の XML 化 - くずし字辞書の参照 - 既存の翻刻データとの整合性チェック（人間が確認） 今回の例でも、 **既存 CSV の校正補助に使えるレベル**まで精度が上がっているのは大きい。 --- ## **② “行の順序”や“読み取り対象の追加”の UI 操作** これは **半自動**。 UI が優秀なので、 - 読み取り漏れの行を追加 - 順序を指定 などが簡単にできる。 ただし、 **AI エージェントが UI を直接操作する段階にはまだない** というのが現状。 --- ## **③ 翻刻結果の整形・比較・差分抽出** これは **AI エージェントで自動化可能**。 - OCR XML と既存 CSV の比較 - 差分の抽出 - 疑わしい箇所のマーキング - 既存データの更新案の生成 ここはすでに ChatGPT 系のエージェントが得意とする領域で、 **人間の介入は最小限で済む**。 --- # ◆ **現時点で“まだ自動化できない”部分** ## **① OCR 精度そのものの向上** 筆者さんが脚注で書かれた通り、 **手順の自動化と OCR 精度は別問題**。 - くずし字の揺れ - 版面の汚れ - 行間の乱れ - 文字の潰れ - 変体仮名のバリエーション これらは **モデルの学習データ**に依存するため、 エージェントが勝手に改善することはできない。 --- ## **② “読み取り対象の行”の自動推定（完全版）** 現状の UI は優秀だが、 - 行の欠落 - 行の分割・結合の誤り - 余白の誤検出 などは **人間の目が必要**。 ただし、 **2027〜2028 年にはここも自動化される可能性が高い** （画像セグメンテーション技術の進歩により）。 --- ## **③ 翻刻の“意味解釈”** OCR は文字を読むが、 **文脈を理解して誤りを訂正する**のはまだ難しい。 例： - 「ゑ」と「る」の誤読 - 「之」「也」「於」などの文脈依存の揺れ - 暦用語の専門的な読み分け ここは **人間の専門知識が不可欠**。 --- # ◆ **結論：2026年の到達点** 筆者さんのまとめは、現状を非常に正確に捉えています。 > **“手順の自動化”はほぼ可能。 > しかし “OCR 精度の向上”は別問題。** そして、 **「人間の介入を最小化できるか？」という問いに対しては、 “ほぼできるが、完全自動はまだ先”** というのが現実的な答えです。 ただし、今回の OCR の精度を見る限り、 **「人間が最終チェックするだけ」レベルには到達しつつある**。 --- # ◆ この記事の良いところ - 実例（1844v → NDL → OCR → XML）を示している - 既存 CSV との比較という“実務的な評価”がある - UI の長所と限界を正確に書いている - AI エージェントの可能性と限界を分けて述べている - 「どこまで自動化できるか？」という問いが自然に立っている これは **仮名暦研究の現場にとって非常に価値のある記録**になります。