結論からいうと、

速さで押し切るタイプではないものの、安全に段階実行するエージェントとしてはかなり優秀

という評価です。

今回依頼したのは、単なるコード作成ではありません。

• 実行計画の作成

• Dry-run

• 既存ファイルの上書き防止

• 指定フォルダ外への書込み防止

• ログと証跡の保存

• 1モデルだけでの試走

• 承認するまで本戦を開始しない

といった条件を付けました。

Fuguが特に良かったのは、勝手に先へ進まなかったことです。

Dry-run後に停止し、承認を待つ。
基盤ファイル作成後にも停止する。
誤字を見つけても勝手に直さず、確認を求める。

実務では、AIが気を利かせること以上に、

発見する
報告する
承認を得る
実行する
証跡を残す

という順番が重要です。

一方で、最初の設計には、ファイル衝突確認やログ整合性など、いくつか修正点もありました。

そのため、現時点では、

実装担当としては優秀だが、独立したレビュー役は別に置く

という使い方が合っていると感じています。

Codexとの相性はかなりよい

Fuguは、普通のチャット欄よりも、ファイルやターミナルを扱えるCodexのような環境で能力が引き出されるタイプに見えます。

今回も、単にコードを書いただけではありません。

PowerShellの構文エラーを修正し、モデルの応答形式を調べ、設定を変更し、テストハーネスを作り直し、再試走まで進めました。

つまり、

• 現状調査

• 実行計画の作成

• 修正

• 実行

• 証跡保存

• 異常分析

• 停止判断

までを、一つの長い仕事として処理しています。

Codexが「作業場」、Fuguが「現場監督」という組合せです。

長時間の調査・実装・実行・証跡作成をまとめて任せる場合、かなり相性がよさそうです。

TerraやLunaと比べると、どの位置か

今回の体感では、FuguはLuna以上、Terra未満からTerra近辺に見えました。

ただし、これは単純な回答性能の比較ではありません。

Fuguは単一モデルではなく、複数のエージェントを組み合わせて仕事を進める仕組みです。そのため、ここで比較しているのは、Codex上での「実務遂行力」です。

FuguがLunaより強く見えたのは、単発のコード生成ではなく、長いジョブの流れを維持できた点です。

途中でエラーが出ても修正し、設定を見直し、再試走し、結果を報告するところまで進めました。

一方で、

• 最初の設計には安全上の漏れがあった

• 出力が長くなりやすい

• 自分で作った設計を自分で評価するため、独立性が弱い

• 次の試行が本当に最適かは、別途レビューが必要

という課題もあります。

そのため、FuguをTerraの完全な代替と考えるより、

Fuguに働かせ、Terraに検査させ、難所だけSolに上げる

という使い方が最も実務的だと思います。

私のAI Factoryで配役するなら、

• Luna：短い修正、軽いコード、ログ要約

• Fugu：調査から実装、実行、証跡作成までの一連のジョブ

• Terra：設計や成果物のレビュー

• Sol：重大な設計判断、難しい原因分析、最終確認

という役割分担になりそうです。

Fuguは、瞬発力だけで比べればTerraに一歩譲る可能性があります。

しかし、障害物のある長距離戦では、Terra級に走る場面があります。特にCodexコースへの適性は、かなり高そうです。

利用制限には注意が必要

今回、Standardプランの5時間枠を使い切りました。週間枠は36％でした。

月20ドルとしてはかなり使えますが、長い仕事では、性能より先に利用枠がボトルネックになる可能性があります。

そのため、

• 作業をPhaseに分ける

• 各Phaseでcheckpointを残す

• 利用制限後も再開できるようにする

という設計が必要です。

これはFuguに限らず、長時間動かすAIエージェント全般に必要な運用だと思います。

現時点での評価

現時点での印象は、

Fuguはスピード馬というより、指示に忠実で折り合いのよい仕事馬

です。

単独ですべてを任せるより、TerraやSolと組ませることで、価値が高まるエージェントだと思います。

Fuguに働かせ、Terraに検査させ、難所だけSolに上げる。

この組合せなら、かなり実務的なAIチームになりそうです。

ChatGPT、Claude、Gemini、NotebookLM、Obsidian、Hermes、OpenClaw、OpenInterpreter、ローカルLLM、PDF処理、音声合成、動画生成。

気づけば、会計事務所の中に小さなAI実験場のようなものができつつあります。

もちろん、面白いです。

PDFをAIに読ませる。
AIエージェントに作業を頼む。
音声を作る。
キャラクターに話してもらう。
業務フローを自動化する。

どれも、実務につながる可能性があります。

ただ、少し危ない感覚もありました。

新しいツールを見つける。
試す。
環境を作る。
別のツールが出る。
また試す。

気づくと、仕事を効率化するためのAIなのに、AIを試すこと自体が目的になりかける。

いわゆるAI沼です。

そんな状態で、Fableに壁打ちしてみました。

すると、かなり厳しめに言われました。

ざっくり言えば、

「AIツールをたくさん触っているだけでは、差別化にならない」
「動画やキャラクター制作は、それ自体では専門家としての信用に直結しない」
「インフラいじりが楽しくなりすぎると、本業からズレる」

というような指摘です。

なかなかの平手打ちでした。

でも、痛かった分だけ、かなり良い指摘でもありました。

たしかに、AIを使えること自体は、いずれ普通になります。

ChatGPTを使う税理士。
NotebookLMを使う会計士。
AIで議事録を作る経理部。
AIで文章を下書きする社外役員。

こういうことは、数年後には珍しくなくなるはずです。

では、どこに専門家としての価値があるのか。

それは、AIを使うことそのものではなく、

どこまでAIに任せるのか。
どこから人間が確認するのか。
どんな証跡を残すのか。
どう誤答を検出するのか。
誰が最終責任を負うのか。

を設計できることだと思います。

Fableの指摘を、私なりに読み替えるとこうです。

AI遊びをやめろ、ではない。
AI実装経験を、会計・税務・監査・内部統制の言葉に翻訳しろ。

これは、かなり本質的でした。

これまで触ってきたAI Factory、Hermes、OpenClaw、PDF処理、動画制作も、無駄だったとは思っていません。

むしろ、実際に手を動かしたからこそ、AIを業務に入れるとどこで危ないかが見えてきます。

AIエージェントに作業を頼むと、ログが必要になる。
PDFを読ませると、表の崩れや金額の誤読が問題になる。
スタッフがAIを使うなら、入力してよい情報とダメな情報を分ける必要がある。
AIの回答を使うなら、人間のレビュー手続が必要になる。

これは、まさに会計士・税理士・社外役員として考えるべき領域です。

ただし、Fableが言うように、危ないところもあります。

新しいツールを追い続ける。
環境構築に時間を溶かす。
キャラクター設定を延々と詰める。
ローカルLLMを育てること自体が目的になる。

これは楽しいのですが、放っておくと本業からズレます。

そういう意味で、今回のFableはかなり良いブレーキでした。

ChatGPTやClaudeは、こちらのやりたいことを前向きに広げてくれることが多いです。
それはそれで、とてもありがたい。

一方で、Fableは、ときどき耳の痛いことを言ってくれる印象があります。

「それ、本当に仕事の価値につながっていますか？」
「手段が目的になっていませんか？」
「専門家としての勝ち筋に翻訳できていますか？」

そういう問いを投げてくれるAIは、けっこう貴重です。

なので、Fableを毎日常用するかは別として、サブスクではなくAPI課金になったとしても、時々使っていこうと思っています。

常に優しく励ましてくれるAIも必要です。

でも、ときどき平手打ちしてくれるAIも必要です。

AI沼にハマりかけたときに、少し痛いことを言ってもらう。
ツール遊びが目的化していないか確認する。
実務・顧客・品質・統制の言葉に戻してもらう。

そういう使い方です。

今回の結論は、かなりシンプルです。

AIツールを触ることは悪くない。
実験することも悪くない。
動画を作ることも、エージェントを動かすことも、PDF処理を試すことも、意味はある。

ただし、それを専門家としての価値に翻訳できなければ、ただのAI沼になる。

だから、これからは少し意識していきたいと思います。

AIを使う会計士、ではなく、
AIを会計・税務・監査・内部統制に落とし込める会計士へ。

そして、沼にハマりそうになったら、またFableに平手打ちしてもらおうと思います。

これらを、結局どう組み合わせ／使い分けするか、

• 事務所PC

• ノートPC

• VPS上のAIエージェント

を組み合わせる中で何度も設計を見直しました。

まず役割を分ける

現時点では、それぞれの役割を次のように考えています。

・Google Drive：正本保管
・Obsidian：知識管理
・NotebookLM：知識活用
・rclone：クラウド同期
・Syncthing：端末間同期
・VPS：AI司令塔
・Telegram：通知・依頼

ポイントは、

保存する場所
同期する仕組み
知識を整理する場所
AIが動く場所

を分けて考えることです。

Google Driveは保管庫

Google Driveは資料の正本を置く場所です。

AIのためではなく、

まず人間のための保管庫。

バックアップ・共有・スマホ閲覧などの基盤になります。

Obsidianは第二の脳

Obsidianは同期ツールではありません。

役割は、

• ノート

• リンク

• タグ

• 検索

です。

Google Driveが図書館なら、

Obsidianは知識を整理する研究ノートです。

rcloneとSyncthing

ここは混同されやすい部分です。

rclone

Google Drive
↓
PC・VPS

クラウドとの同期向き

Syncthing

PC
↕
PC

端末同士の同期向き

私の場合はGoogle Workspace中心なので、まずrcloneを採用しています。

AIエージェント時代の構成

最近は、

• Hermes

• OpenClaw

などをVPSで動かすケースも増えています。

その場合は、

Google Drive
↓
rclone
↓
VPS上のAI

という構成が扱いやすいです。

AIはInboxを監視し、

成果物をOutputへ返す。

人間はTelegramで通知を受ける。

そんな流れになります。

現時点の私の構成

顧客・メール
↓
Google Drive（正本）
↓
rclone
↓
VPS上のAI統括
↓
事務所PC・ノートPC
↓
成果物
↓
Google Drive
↓
Telegram通知

Syncthing中心の方が合う人もいますし、Google Driveを使わない設計もあると思います。

ただ、Google Workspaceを中心に運用する私にとっては、現時点ではこの形が最も扱いやすく感じています。

まとめ

どれか一つのツールですべてを解決しようとすると苦しくなります。

重要なのは、

• 保存する場所

• 同期する仕組み

• 知識を整理する場所

• AIが動く場所

を分けて考えることです。

ツールそのものよりも、

「何をどこに置くか」

という設計の方が重要です。

AI時代は、個々のツールよりも情報設計そのものが競争力になる。

最近はそう感じています。

前回までの大きな気づきは、PDF処理は単純なOCR精度の勝負ではない、ということでした。

文字をどれだけ正確に読めるかも、もちろん大事です。

ただ、会計事務所や士業実務で本当に困るのは、文字認識そのものよりも、

表の構造が崩れること

です。

試算表であれば、勘定科目と金額の対応関係が残るか。

申告書であれば、欄番号・項目名・金額・注記の位置関係が残るか。

決算書であれば、左右に並んだ資産と負債、当期と前期、科目と金額の関係が崩れないか。

AIに読ませる前提では、単に文字が読めるだけでは足りません。

AIが読める構造を残せるか

が重要になります。

前回の続き：文字データありPDFをどう分けるか

前回は、pdf-inspector のようなツールを使って、まずPDFを入口で判定する話を書きました。

ざっくり言えば、

文字データなし
→ OCRへ

文字データあり
→ テキスト抽出へ

という入口の振り分けです。

ただ、今回さらに分かったのは、ここから先です。

文字データありPDFだからといって、全部同じ処理でよいわけではありません。

テキストPDFにも、いろいろあります。

きれいな文章PDF。

罫線が明確な財務諸表。

決算短信や有価証券報告書。

法人税申告書のような複雑な帳票。

勘定式の貸借対照表のような左右に並ぶ表。

これらを全部同じツールで処理しようとすると、どこかで崩れます。

明確な罫線表は OpenDataLoader が強い

今回、OpenDataLoader と LiteParse を比較してみて、かなり面白い結果になりました。

OpenDataLoader は、罫線がしっかりしたグリッド表に非常に強いです。

たとえば、

決算短信
有価証券報告書の財務表
勘定科目内訳明細書
開示資料の表

のように、明確な罫線で囲まれた表であれば、きれいなMarkdownテーブルに変換しやすい。

しかも速い。

これはかなり魅力的でした。

AIに渡すときも、Markdownテーブルになっていると読みやすいです。

余分なスペースも少ないので、トークン効率もよい。

つまり、OpenDataLoader は、

罫線が明確な表を、きれいなMarkdownテーブルにする

という用途でかなり強いと感じました。

ただし、申告書では崩れる

一方で、OpenDataLoader が苦戦したのが、法人税申告書のような帳票です。

申告書には、1桁ずつ区切られた細かい金額欄があります。

また、左右ブロック、欄番号、注記、入れ子状の罫線が混ざっています。

OpenDataLoader は、この細かいマス目を大量の小さな表として認識してしまい、数字がバラバラに分解されることがありました。

つまり、

罫線があるからといって、常にOpenDataLoaderがよいわけではない

ということです。

ここはかなり重要です。

会計事務所目線では、申告書を壊さずに読ませたい場面は多いです。

そのため、申告書のような複雑な帳票を、単純な表としてMarkdownテーブル化しようとすると、かえってAIが読みにくくなる可能性があります。

申告書や複数カラムは LiteParse が強い

法人税申告書、地方税申告書、所得税申告書、相続税申告書のような資料は、単純な表というより、複雑な帳票レイアウトです。

左右にブロックが並ぶ。

欄番号がある。

注記がある。

1桁ずつ区切られた金額欄がある。

こういうPDFを無理にMarkdownテーブル化すると、元の意味が崩れることがあります。

このような場合は、LiteParse のように、元のPDFの物理的な配置やアライメントを残す方が、AIに読ませやすいと感じました。

LiteParse は、きれいなMarkdownテーブルを作るというより、元のPDFの位置関係をできるだけ保ったまま出力する方向に強みがあります。

そのため、

法人税申告書
所得税申告書
相続税申告書
勘定式の貸借対照表
左右2カラムの財務資料
試算表

のような資料では、OpenDataLoaderよりも LiteParse の方が向いている場面があります。

フローチャートにするとこうなる

現時点のPDF処理フローは、次のように整理できます。

ポイントは、

最強ツールを1つ決める話ではない

ということです。

PDFの種類によって、向いている処理が違います。

そして、その違いを最初に判定して、適切なルートに流す。

これが重要です。

会計事務所ではかなり効きそう

会計事務所では、日々いろいろなPDFを扱います。

決算書
試算表
総勘定元帳
法人税申告書
所得税申告書
相続税申告書
勘定科目内訳明細書
固定資産台帳
通帳明細
領収書
電子申告メール詳細
契約書
議事録

これらを全部同じ方法で処理するのは無理があります。

OCRに回すべきものもあれば、テキスト抽出だけで十分なものもあります。

Markdownテーブル化した方がよいものもあれば、元の位置関係を残した方がよいものもあります。

だからこそ、最初にPDFを仕分ける発想が必要になります。

人間が毎回判断するのではなく、まず機械的に判定する。

そのうえで、難しいものだけ人間やLLMが確認する。

この流れにできれば、ローカルPC上でのPDF×AI処理がかなり現実的になります。

PDF処理はパイプラインで考える

PDFをAIに読ませる処理は、単に

OCR

ではありません。

これからは、

判定
↓
振り分け
↓
抽出
↓
構造維持
↓
AIレビュー

というパイプラインで考える必要がありそうです。

LiteParse、OpenDataLoader、Docling OCR、NDLOCR-Lite。

それぞれに得意分野があります。

だからこそ、どれか1つを選ぶのではなく、PDFの性質ごとに適切な処理ルートへ流す。

この「振り分け係」が、ローカルAI時代のPDF処理ではかなり重要な部品になりそうです。

そこで一番大きな気づきだったのは、

OCR精度だけを見ても、実務では足りない

ということです。

会計事務所や士業実務で扱うPDFでは、単に文字が読めればよいわけではありません。

試算表であれば、勘定科目と金額の対応関係が残るか。

申告書であれば、項目名・欄番号・金額・注記の位置関係が残るか。

通帳明細であれば、日付・摘要・入金・出金・残高の列が崩れないか。

契約書や判例であれば、文章の流れが自然に保たれるか。

つまり、AIに読ませる前提では、単なるOCR精度ではなく、

AIが読める構造を残せるか

がかなり重要になります。

前回の整理

前回の検証では、現時点の使い分けをざっくり次のように整理しました。

テキストPDFの試算表・決算書・申告書
→ LiteParse

文章PDF
→ PyMuPDF

罫線のある単純な表PDF
→ pdfplumber

スキャンPDFの表・試算表・申告書
→ Docling OCR

日本語スキャン文章
→ NDLOCR-Lite

この整理自体は、今でもかなり実務的だと思っています。

ただ、実際に大量のPDFを処理することを考えると、次の問題が出てきます。

そもそも、そのPDFがどの種類なのかを、最初にどう判定するのか。

ここです。

実務のPDFは、かなり混ざっている

会計事務所で扱うPDFは、きれいに分類されているとは限りません。

たとえば、法人税申告書一式でも、

申告書本体
法人税別表
勘定科目内訳明細書
事業概況説明書
電子申告メール詳細
固定資産台帳
消費税申告書
添付資料
手書きメモ
受領印付き控え

のように、いろいろな資料が混ざります。

しかも、それぞれのPDFの性質も違います。

ソフトやe-Taxから直接出力されたテキストPDFもあれば、紙をスキャンした画像PDFもあります。

Excelから出した表形式のPDFもあります。

手書きメモをスキャンしただけのPDFもあります。

一つのPDFの中に、テキストページとスキャンページが混在していることもあります。

この状態で、

PDF
↓
とりあえず全部OCR

としてしまうと、かなり無駄が出ます。

テキストPDFなのにOCRにかけると遅い。

OCR不要なPDFまで重い処理に回してしまう。

逆に、スキャンPDFなのにテキスト抽出だけで処理しようとして、何も取れない。

こういうことが起きます。

必要なのは「PDF交通整理係」

そこで必要になるのが、PDFの入口判定です。

つまり、PDFをAIに読ませる前に、

これはテキストPDFなのか
これはスキャンPDFなのか
これは混在PDFなのか

を先に判定する工程です。

最近気になっているのが、Firecrawlの pdf-inspector です。

これはOCRエンジンそのものではありません。

役割としては、PDFの中身を見て、そのPDFをどの処理ルートに流すかを決める「交通整理係」に近いものです。

PDFの内部に文字データがあるのか。

画像中心なのか。

テキスト抽出で足りるのか。

OCRに回す必要があるのか。

こうした判定を最初に行うことで、その後の処理をかなり最適化できそうです。

ツール比較より、ルーティングが大事になる

前回は、LiteParse、PyMuPDF、pdfplumber、Docling OCR、NDLOCR-Liteといった個別ツールを比較しました。

もちろん、それぞれのツールの性能は大事です。

ただ、実務で大量処理する場合、本当に重要なのは、

どのツールが一番強いか

だけではありません。

むしろ、

どのPDFを、どのツールに流すか

です。

たとえば、私の現時点のイメージでは、こうです。

PDF
↓
pdf-inspector で判定
↓
テキストPDFの表・帳票
→ LiteParse
↓
テキストPDFの文章
→ PyMuPDF
↓
罫線のある単純な表
→ pdfplumber
↓
画像・スキャンPDFの表・申告書
→ Docling OCR
↓
画像・スキャンPDFの日本語文章
→ NDLOCR-Lite

もちろん、これだけで完全自動化できるわけではありません。

申告書のような複雑な帳票、表と文章が混在した資料、ページごとに性質が違うPDFでは、追加の判定や例外処理も必要になるはずです。

それでも、最初にPDFの性質を見て、

軽いテキスト抽出で足りるもの
重いOCRに回すべきもの
構造化を重視すべきもの

を分けるだけでも、かなり効きそうです。

会計事務所では特に効きそう

この「振り分け係」は、会計事務所や士業事務所ではかなり相性がよさそうです。

たとえば、AIに読ませたい資料としては、

決算書PDF
法人税申告書PDF
所得税申告書PDF
相続税申告書PDF
勘定科目内訳明細書
固定資産台帳
総勘定元帳
通帳明細
領収書
契約書
議事録
相続資料
スキャンされた証憑

などがあります。

これらを毎回、人間が目で見て、

「これはLiteParse」
「これはPyMuPDF」
「これはDocling OCR」
「これはNDLOCR-Lite」

と判断するのは、なかなか大変です。

しかも、資料が増えるほど、処理ルートの選択ミスも起きやすくなります。

だからこそ、最初にPDFを判定する仕組みがあると、かなり実務的です。

人間が全部判断するのではなく、まず機械的に振り分ける。

そのうえで、難しいものだけ人間やLLMが確認する。

この流れの方が、事務所内で使うには現実的だと思います。

地味だけど、実務ではこういう部品が効く

PDF処理というと、どうしてもOCRエンジンやLLM本体に目が行きます。

どのOCRが一番正確か。

どのLLMが一番うまく読めるか。

どのツールが一番Markdown化しやすいか。

もちろん、それも重要です。

ただ、実務で大量に回すなら、その前段にある「判定」と「振り分け」がかなり重要になります。

いきなりOCRにかけない。

まずPDFの性質を見る。

テキストPDFなら軽い処理に流す。

スキャンPDFならOCRに流す。

表や帳票なら構造を残せる処理に流す。

文章PDFなら高速にテキスト化する。

この入口の交通整理があるだけで、PDF×AIの処理はかなり安定しそうです。

前回は、

OCR精度を競う時代は終わったかもしれない

と書きました。

今回、それに少し付け加えるなら、

OCRする前に、まずPDFを仕分ける時代になるかもしれない

という感じです。

AIにPDFを読ませる処理は、

OCR

だけではなく、

判定
↓
振り分け
↓
抽出
↓
構造維持
↓
AIレビュー

というパイプラインで考えた方がよさそうです。

PDF処理の主役は、LiteParseやDocling OCRかもしれません。

でも、その前段にいる「PDF交通整理係」も、実務ではかなり重要な部品になりそうです。

目的はシンプルです。

会計事務所や士業実務で扱うPDFを、できるだけ安全に、ローカルPC上で処理したい。

試算表、決算書、申告書、通帳明細、有価証券報告書、契約書、相続資料。

こうした資料をAIに読ませる前に、PDFからテキストや表をきれいに取り出す必要があります。

ただ、実際に検証してみると、思っていたよりずっと面白い結果になりました。

一番大きな気づきは、これです。

OCR精度の勝負ではなかった。

最初の仮説

当初は、こう考えていました。

日本語OCRとしては、NDLOCR-Liteがかなり強い。
日本語の文字認識精度が高いなら、士業実務のPDF処理でも本命になるのではないか。

実際、NDLOCR-Liteの文字認識精度はかなり高かったです。

漢字、かな、数字の読み取りは非常にきれいでした。
Tesseractと比べると、実務で使いたくなるレベルがかなり違います。

ところが、試算表のような表データを処理すると、問題が出ました。

文字は読めている。
でも、表の構造が崩れる。

これが致命的でした。

士業実務で本当に困ること

たとえば、試算表ではこういう情報が必要です。

売上高       1,000
売上原価       700
販管費         200

ところが、OCR結果がこうなると困ります。

売上高
売上原価
販管費

1,000
700
200

文字認識としては、かなり正しいかもしれません。

でも、会計実務では使いにくい。

なぜなら、勘定科目と金額の対応関係が壊れているからです。

AIに読ませる場合も同じです。

人間なら、元のPDFを見ながら補正できるかもしれません。

でも、AIに渡す前処理としては、行と列の対応関係が崩れると一気に価値が落ちます。

逆に、多少文字の誤認識があっても、

売上高 | 1,000
売上原価 | 700
販管費 | 200

という構造が残っていれば、AI側でかなり補正できます。

ここが今回の一番面白い点でした。

OCR精度ではなく、AI前処理性能を見る

従来のOCR評価は、主に「文字をどれだけ正確に読めるか」でした。

もちろん、それは今でも重要です。

ただ、AIに読ませる前提では、それだけでは足りません。

重要なのは、

AIが解釈できる構造を保ったまま取り出せるか

です。

つまり、評価軸が少し変わっています。

従来は、

OCR
↓
文字認識率

でした。

でも、AI時代のPDF前処理では、

OCR / PDF抽出
↓
構造維持精度
↓
AIが読めるか

になります。

士業実務でいうと、特に重要なのは次のような点です。

• 勘定科目と金額の対応関係が残るか

• 表の行と列が維持されるか

• 空白セルを勝手に詰めてしまわないか

• 金額列が縦にバラバラにならないか

• AIが後続処理できるMarkdownやCSVにできるか

ここを見ないと、単純なOCR精度だけでは実務評価を誤ります。

今回の検証結果

今回、ローカルCPU環境で複数のPDF処理ツールを比較しました。

対象は、テキストPDFの試算表・有価証券報告書、さらにそれを画像化したスキャンPDFです。

ざっくり結果をまとめると、こうなりました。

テキストPDFの本命は LiteParse

テキストPDF、特に試算表や決算書、所得税・法人税・相続税等の申告書などでは、LiteParseが非常に強い結果でした。

処理速度が速く、表や帳票のアライメントも比較的きれいに残ります。

PyMuPDFは圧倒的に速いのですが、そのままテキスト抽出すると、表の横並びや帳票内の位置関係が崩れやすい。

一方でLiteParseは、PyMuPDF系の速さを活かしながら、表や帳票の構造補正に寄せている印象です。

したがって、きれいなテキストPDFのうち、試算表・決算書・申告書のような表や帳票形式の資料であれば、まずLiteParseを使うのがよさそうです。

文章PDFなら PyMuPDF

契約書、判例、通達、稟議書のようなベタ書きの文章PDFであれば、PyMuPDFはかなり有力です。

とにかく速いです。

表構造を厳密に取りたい場面には向きませんが、文章を素早くテキスト化する用途では非常に使いやすい。

士業実務では、文章PDF用の高速抽出エンジンとして十分に使えます。

罫線のある単純な表なら pdfplumber

pdfplumberは、明確な罫線で囲まれた表に強いです。

通帳明細、一覧表、定型帳票のように、表の枠線がはっきりしていて、構造が比較的単純なPDFでは有効です。

ただし、試算表や決算書、所得税・法人税・相続税等の申告書などは、罫線はあっても、左右ブロック・入れ子・欄番号・注記が混在した複雑な帳票レイアウトなので、pdfplumberでCSV化すると崩れやすい。

使いどころを選ぶツール、という印象です。

スキャンPDFの現時点の本命は Docling OCR

画像PDF、つまりスキャンPDFでは、Docling OCRがかなり強い結果でした。

特に驚いたのは、表構造の保持です。

文字認識そのものは、NDLOCR-Liteのほうがきれいな場面もあります。

ただ、試算表のような資料では、Docling OCRのほうが行と列の関係を保ったままMarkdownやCSVに近い形で出力しやすい。

これは実務上かなり大きいです。

もちろん課題もあります。

ローカルCPUだと重い。

1ページあたり数秒から十数秒かかるため、日中に大量処理するには少し厳しい。

ただ、夜間バッチで処理するなら十分に現実的です。

NDLOCR-Liteは「将来有望株」

NDLOCR-Liteは、文字認識精度だけ見ると非常に優秀でした。

日本語の読み取りはかなりきれいです。

処理速度も比較的速いです。

ただし、試算表のような表では、読み順の整序が逆に効きすぎて、列ごとにテキストをまとめてしまうことがありました。

その結果、勘定科目と金額の対応関係が壊れる。

これでは、そのままAI前処理として使うには危険です。

ただし、NDLOCR-Liteには大きな可能性があります。

それは、座標情報です。

OCR結果に、文字や単語のboundingBox、つまり位置情報が残っています。

これを使えば、

スキャンPDF
↓
NDLOCR-Lite
↓
座標情報を取得
↓
行ごとに再整列
↓
CSV化
↓
AIレビュー

という処理ができる可能性があります。

もしこれがうまくいけば、かなり面白いです。

日本語に強い。

CPUで動く。

ローカルで完結する。

しかも表構造も復元できる。

つまり、士業実務向けの強力なローカルPDF前処理基盤になるかもしれません。

現時点の使い分け

今回の検証をもとに、現時点ではこう整理しています。

テキストPDFの試算表・決算書
→ LiteParse

文章PDF
→ PyMuPDF

罫線のある単純な表PDF
→ pdfplumber

スキャンPDFの表・試算表
→ Docling OCR

将来有望
→ NDLOCR-Lite + 座標再構築

特に士業実務では、PDFの種類ごとに処理ルートを分けるのが大事です。

すべてを1つのツールで処理しようとすると、どこかで無理が出ます。

きれいなテキストPDFなのか。

スキャン画像なのか。

表なのか。

文章なのか。

罫線があるのか。

スペースで列が表現されているのか。

この分類を最初に行い、そのうえで処理ツールを選ぶ。

これが実務的には一番安全です。

まとめ

今回の検証で、PDF処理に対する見方が少し変わりました。

OCRの価値は、単に文字を読むことではありません。

少なくともAIに読ませる前提では、重要なのは、

AIが解釈できる形で構造を残せるか

です。

文字認識率が高くても、表の行と列が壊れれば、実務価値は大きく下がります。

逆に、多少の誤認識があっても、構造が保たれていれば、AIで後補正できます。

その意味で、これからのPDF処理は、

OCR精度

だけでなく、

AI前処理性能

で評価する必要がありそうです。

今回の第1ラウンドの私の結論は、こうなりました。

テキストPDF
→ LiteParse

画像・スキャンPDF
→ Docling OCR

これは単なるツール比較ではなく、士業実務における「AI時代のPDF前処理」の研究テーマになりそうです。

次は、NDLOCR-Liteの座標情報を使って、試算表の行と列を自動復元できるかを試してみたいと思います。

AI秘書を持つハードルが、かなり下がってきた

という話を書きました。

インストールして、SOUL.mdに役割を書いて、長期記憶をONにする。

それだけで、自分専属のAI秘書っぽいものを作れる。

これは今でも変わっていません。

ただ、その後さらに触ってみて、少し整理が変わりました。

特に大きかったのは、

Hermes Desktopは、ローカルLLMで全部動かすにはまだ重い

という点です。

ローカルLLMでもいけると思っていた

私はもともと、ローカルLLMにかなり期待しています。

会計、税務、法務、M&A、社内資料、顧客資料。

こういった仕事では、AIに読ませたい資料がたくさんあります。

ただ、何でもクラウドAIに入れればよいわけではありません。

機密情報や未公表資料、顧客情報を含むものは、やはり慎重になります。

そう考えると、ローカル環境でAI秘書が動いてくれるなら非常に魅力的です。

そこで、Hermes DesktopとOllamaを組み合わせて、ローカルLLMでどこまで動くか試してみました。

接続はできた。でも実用は重かった

結果から言うと、接続自体はできました。

Ollama単体での生成は動きました。
OpenAI互換APIとしての応答も確認できました。
Hermes側からOllamaプロファイルで起動するところまでも進みました。

つまり、Ollamaが壊れているわけではありません。

ローカルLLM自体も動いています。

問題はその先でした。

HermesをローカルLLMにつないで動かそうとすると、かなり重い。

こちらが入力したのは短い一文でも、Hermes側では最初からかなり大きなコンテキストを背負っているように見えました。

考えてみれば当然です。

Hermesは、単なるチャットアプリではありません。

メモリ、スキル、ツール、ブラウザ操作、cron、サブエージェントなどを持つ、高機能なAIエージェントです。

その分、初期状態でAIに渡す前提情報も大きくなります。

7Bや14Bクラスのローカルモデルに、その全部を背負わせるのはかなり厳しい。

今回の検証では、まさにそこがボトルネックになりました。

「ローカルLLMが使えない」ではない

ここは誤解しないようにしたいところです。

今回分かったのは、

ローカルLLMが使えない

という話ではありません。

Ollama単体ではきちんと動いています。

短い文章生成、要約、簡単な壁打ち、モデル比較などには使えます。

問題は、

Hermes Desktopのようなフル装備のAI秘書を、ローカル小型モデルにそのまま任せるのは重い

ということです。

Ollamaは動く。
ローカルLLMも動く。
Hermesとの接続もできる。

でも、Hermesのフル装備をそのまま背負わせると重い。

ここまで切り分けできたのは、今回の大きな収穫でした。

Hermes Desktopは「クラウドAI秘書UI」と見るのが現実的

今回の検証を踏まえると、現時点ではこう整理するのがしっくりきます。

Hermes Desktopは、クラウドAIを束ねる高機能なAI秘書UI

Gemini、Claude、OpenAI、OpenRouterなどのクラウドAIを使いながら、役割、記憶、ツール、ワークフローを組み合わせて、自分のAI秘書として育てる。

この方向では、かなり有力です。

一方で、

Hermes DesktopをローカルLLMだけでフル稼働させる

となると、今の私の環境ではまだ厳しい。

少なくとも、軽量ローカルモデルにそのまま全部任せるのは現実的ではありませんでした。

前回は、

「AI秘書の導入コストが下がった」

という話でした。

今回はその続きとして、

ただし、本番のAI秘書として使うなら、当面はクラウドAIと組み合わせるのが現実的

という話です。

ローカルAI秘書は、別プロジェクトとして育てる

では、ローカルAI秘書をあきらめるのか。

それは違います。

むしろ、ローカルAI秘書は今後かなり重要になると思っています。

特に士業や経営実務では、ローカルAIには大きな意味があります。

顧客資料を外に出さずに読ませたい。
月次試算表を安全にレビューしたい。
契約書や議事録をローカルで要約したい。
税務・会計・法務の一次チェックを手元で回したい。

こういうニーズは確実にあります。

ただし、それはHermes DesktopにローカルLLMをつないで、すぐ全部できる、という話ではありません。

マシンパワー、モデルサイズ、コンテキスト量、使うツールの絞り込み、読ませる資料の前処理。

このあたりをきちんと設計する必要があります。

私の場合、本格的なローカルAI秘書は、Mac Studio 128GB級のAI母艦を入れてから再挑戦するテーマかなと思っています。

それまでは、ローカルLLMは単体生成や軽い検証にとどめる。

本番のAI秘書は、Hermes Desktop＋クラウドAIで育てる。

この方が現実的です。

現時点の使い分け

今回の検証を踏まえた、現時点での整理はこうです。

Hermes Desktop
クラウドAIを束ねる本番用AI秘書UI。
Gemini、Claude、OpenAI、OpenRouterなどと組み合わせて使う。

Ollama
ローカルLLMの検証用。
短い生成、モデル比較、軽いローカル処理に使う。

ローカルHermes
接続はできるが、フル装備では重い。
使うならツールやスキルをかなり絞る必要がある。

本格ローカルAI秘書
将来のテーマ。
高メモリのローカルAI母艦を用意してから再挑戦。

この整理にしたことで、だいぶスッキリしました。

まとめ

前回、Hermes Desktopを触って、

AI秘書の導入コストはかなり下がった

と書きました。

その考えは今も変わっていません。

ただし、追加で分かったことがあります。

Hermes DesktopをローカルLLMだけでフル稼働させるのは、まだ簡単ではない。

少なくとも、今の私の環境では、7Bや14BクラスのローカルモデルにHermesのフル装備を背負わせるのはかなり重いと感じました。

現時点での結論はこうです。

Hermes Desktopは、当面はクラウドAI秘書として使う。
Ollamaは、ローカルLLMの検証用として使う。
本格的なローカルAI秘書は、将来のAI母艦導入後に再挑戦する。

AI秘書は、たぶんこれから普通になります。

ただし、その形は一つではありません。

クラウドで育てるAI秘書。
ローカルで育てるAI秘書。
その両方を、用途に応じて使い分ける時代になっていくのだと思います。

私自身も、当面はクラウドAI秘書を本番ラインとして育てつつ、ローカルAI秘書は将来の「辞めない社員」候補として、少しずつ準備していくつもりです。

Claude Code、Codex、Google Antigravity、OpenClaw、Hermes Agent、Obsidian、VPS、MCP……。

自分でも思います。

「普通の人は、ここまでやらない」

と。

AIに興味がある人でも、

• WSL

• Docker

• APIキー

• MCP

• VPS

• GitHub

• Obsidian連携

このあたりの単語が出てきた瞬間に、たぶん多くの人は止まります。

私自身は、仕事柄というか趣味というか、かなり深く触っています。

AIエージェントにファイル整理を任せたり、ローカルLLMを試したり、複数のAIに役割分担させたりしています。

ただ、最近ふと思いました。

「AI秘書が欲しい」という人に、いきなりAntigravityやClaude Codeを勧めるのは、かなり無理があるのではないか。

AI秘書が欲しい人は多い

周りでも、

「自分専属のAI秘書がほしい」

という話はよく出ます。

メールを整理してほしい。
予定をまとめてほしい。
資料を読んで要点を出してほしい。
自分の仕事の前提を覚えておいてほしい。
相談したときに、毎回ゼロから説明しなくて済むようにしたい。

これは、かなり自然なニーズだと思います。

でも実際にやろうとすると、これまでは意外と大変でした。

単なるチャットAIならすぐ使えます。

でも「自分のことを覚えている」「役割を持っている」「継続的に相談できる」「秘書らしくふるまう」となると、急に設定や運用が難しくなります。

Hermes Desktopを試してみた

そこで、新しく発表されたHermes Desktopを試してみました。

https://hermes-agent.nousresearch.com/desktop

正直、最初は少し半信半疑でした。

ところが、触ってみるとかなりシンプルでした。

やったことは、ざっくり言うとこの程度です。

1. インストールする

2. SOUL.mdに秘書としての役割を書く

3. 長期記憶をONにする

これだけで、かなり「それっぽい専属秘書」になりました。

試しに、

「私は中村先生です。公認会計士・税理士・行政書士です。覚えてください」

と伝えてみました。

すると、次のセッションでもちゃんと覚えていました。

もちろん、これだけで実務の重要判断を全面的に任せられる、という話ではありません。

ただ、少なくとも

「AI秘書っぽいものを自分で持つ」

という入口としては、かなりハードルが下がった印象です。

重要なのはAI性能だけではない

最近のAI界隈では、どうしてもモデル性能の話になりがちです。

どのLLMが賢いか。
Claudeがいいのか、GPTがいいのか。
Geminiが伸びているのか。
ローカルLLMはどこまで使えるのか。

もちろん、それも大事です。

でも、実務で使う立場からすると、もう一つ重要なことがあります。

それは、

導入できるかどうか

です。

どれだけ高性能でも、普通の人が設定できなければ広がりません。

逆に、多少できることが限定されていても、インストールしてすぐ使えるなら、一気に普及する可能性があります。

今回Hermes Desktopを触って感じたのは、まさにそこでした。

AI秘書の性能競争というより、
AI秘書の導入コストが下がった
という変化です。

AIマニア向けと一般向けは違う

私自身は、AntigravityやClaude Code、OpenClawのようなツールも好きです。

複雑な作業を任せたり、ファイルを操作させたり、複数AIに役割分担させたりするなら、こうしたツールは非常に強力です。

ただ、それはやはりAIマニア向け、あるいは開発者・実験者向けの世界です。

一方で、一般の人に

「まずAI秘書を1人持ってみたら？」

と言うなら、もっとシンプルである必要があります。

その意味で、Hermes Desktopのような方向性はかなり面白いと思いました。

AI秘書は“社員”ではなく“見習い秘書”から始める

もちろん注意点もあります。

AI秘書にいきなり重要な仕事を丸投げするのは危険です。

特に士業や経営実務では、顧客情報、契約情報、税務判断、会計処理など、慎重に扱うべき情報がたくさんあります。

なので、最初は

• 自分のプロフィールを覚えさせる

• よく使う仕事の前提を整理させる

• アイデア出しを手伝わせる

• 記事のたたき台を作らせる

• 判断ログを残させる

くらいから始めるのがよいと思います。

いきなり「有能な社員」として扱うのではなく、
見習い秘書として育てる
くらいがちょうどよいです。

誰でもAI秘書を持てる時代へ

今回感じたのは、AIの世界がまた一段階進んだということです。

以前は、AI秘書を本格的に作ろうとすると、それなりの知識が必要でした。

でも今後は、

「インストールする」
「自分の役割を書いておく」
「覚えてほしいことを伝える」

だけで、自分専属のAI秘書を持てる時代になっていくのかもしれません。

AI秘書は、まだ完璧ではありません。

でも、導入のハードルは確実に下がっています。

そしてたぶん、ここから先は、

「AIを使える人」

ではなく、

「AI秘書をどう育てるか」

が差になっていくのだと思います。

※私は関係者でもなく、案件でもPRでもありません。興味があったので、個人的に試してみた感想を書いています。

最初に触る前は、正直なところ、

「既存の生成AIに、士業っぽい名前を付けたサービスなのかな」

という印象も少しありました。

ただ、実際にいくつかの実務論点を投げてみると、その印象はかなり変わりました。

結論から言うと、

実務家目線で見ても、かなり良いです。
ただし、最終判断を任せるというより、“一次レビューAI”として使うのがよさそうです。

試してみた論点

今回は、いくつか実務で気になりやすいテーマを投げてみました。

たとえば、

保険税務
譲渡制限付株式報酬、いわゆるRS
医療法人の消費税
個人情報保護法まわりの基本論点

などです。

このあたりは、一般論だけなら通常の生成AIでもそれなりに答えます。

ただ、士業実務で重要なのは、その先です。

どの制度なのか。
どの条文、通達、会計基準が関係するのか。
どこで判断を間違えやすいのか。
実際の顧問先対応で、そのまま使ってよい水準なのか。

ここを確認しないと、実務では危ないです。

良かった点

一番良いと感じたのは、一次情報に当たりにいこうとする設計です。

税務なら国税庁や法令、会計ならASBJ、法務ならe-Govなど、できるだけ公的情報・一次情報を参照しようとしている印象がありました。

これは、士業向けAIとしてかなり重要です。

普通の生成AIでも、税務や会計の説明はできます。

しかし怖いのは、「それっぽい回答」です。

文章は自然。
説明もそれらしい。
でも根拠を確認すると、微妙に違う。

士業実務では、ここが一番危ないところです。

その点、「士業AI」は「根拠に戻る」ことを意識しているように見えました。
ここはかなり好印象でした。

一次整理ツールとして使いやすい

特に、会計まわりは良い印象でした。

RS、譲渡制限付株式報酬のような論点では、ASBJの取扱いを踏まえながら整理してくれました。

もちろん、これだけで最終判断するわけではありません。

ただ、

事前交付型なのか
事後交付型なのか
費用処理はどう考えるのか
EPSへの影響はあるのか
税務上の事前確定届出給与との関係はどうか

といった論点の入口を作るには、かなり使いやすいと感じました。

税務についても同じです。

保険税務や医療法人の消費税などは、契約内容、会計処理、過去の処理、業種慣行などが絡みます。

AIの回答だけで判断するのは危険です。

ただ、

「何を確認すべきか」
「どの資料を見るべきか」
「どの制度が関係しそうか」
「根拠情報の入口はどこか」

を整理するには便利です。

若手や補助者に、

「まず士業AIで論点を整理してから相談して」

という使い方は、十分ありそうです。

気になった点

一方で、現時点では、実務の“事故感”までは少し弱いと感じる場面もありました。

税務や会計の論点は、制度説明としては正しくても、実務で本当に怖いのは別のところだったりします。

契約書の文言
会計処理とのズレ
過年度処理との整合性
申告調整の漏れ
別表処理
税務調査で聞かれそうなポイント

こういう部分です。

AIが出してくれる回答は、あくまで入口です。

そこから先は、人間の実務家が資料を見て、状況を確認して、最終判断する必要があります。

この前提は忘れてはいけないと思います。

さらに欲しいのは「士業専用PROモード」

個人的には、ここにさらに士業専用PROモードのようなものがあると、かなり刺さります。

たとえば、

条文・通達・会計基準の該当箇所をもっと細かく表示する
「結論」「根拠」「実務上の注意」「要確認資料」を分けて出す
別表調整や会計処理への影響まで整理する
税務調査で聞かれそうなポイントを出す
顧問先説明用の簡潔な説明文も作る

こういうモードがあれば、実務家としてはかなり使いやすいです。

AIに最終判断をしてほしいわけではありません。

欲しいのは、判断材料です。

どの根拠を見るべきか。
どこにリスクがあるか。
何を確認しないといけないか。

ここを整理してくれるAIであれば、かなり実務に入り込めると思います。

現時点での感想

「士業AI」は、

“士業の代替”ではなく、“士業の一次整理を助ける道具”

として見ると、かなり良いサービスだと感じました。

そのまま申告判断に使うものではありません。
税務調査対応や複雑なスキーム判断を、AIだけで完結させるものでもありません。

ただ、実務家が最後に見る前提であれば、十分に使える可能性があります。

特に、一次情報に当たりにいこうとする設計は、士業向けAIとしてかなり大事な方向性だと思います。

ここにさらに、条文・通達・会計基準の該当箇所を深掘りできる士業専用PROモードのようなものがあれば、個人的には即決で申し込むかもしれません。

ひとまず、しばらくお試しで使わせてもらおうと思います。
無料プランでは、月5回まで会話できるようです。

AIに答えを丸投げするのではなく、判断材料を整理してもらう。

その使い方であれば、「士業AI」はかなり面白いサービスだと感じました。

最近は、資料の整理、ノート作成、ログの作成などをAIに任せる場面が増えています。

うまく使えば、とても便利です。

ところが今回、あるはずのファイルが見当たらなくなりました。

「あれ、ない」

最初は見落としかと思いました。

フォルダを確認し、検索もしました。

それでも見つからない。

この時点で、一気に血の気が引きます。

もしかして、消されたのか──

もし削除されて、ゴミ箱にも残っていなかったらどうするのか。
万一、必要なファイルまで削除されていたら、かなりまずい。

頭の中で、最悪のケースが一気に広がりました。

結論からいうと、ファイルは消えていませんでした。

削除ではなく、ごそっと大胆に移動されていただけでした。

助かった……

ただ、ここで冷静になって考えると、かなり重要なポイントがあります。

今回は、私の指示が「移動しておいて」に近い内容だったから、AIも移動で止まったのだと思います。

もしこれが、

「不要なファイルは消しておいて」
「整理して、いらないものは削除しておいて」

という指示だったら、どうなっていたか。

たぶん、AIはかなり素直に実行したと思います。

人間なら、重要そうなファイルを消す前に一瞬ためらいます。

「これは本当に消していいのか？」

そう考えます。

場合によっては、念のため残しておきます。

でも、AIエージェントは違います。

AIは、指示されたことを実行しようとします。
そして、こちらが思っている「常識」や「空気」を、必ずしも共有していません。

「消して」と言えば、消す。
「整理して」と言えば、大胆に動かす。

悪気はありません。
むしろ、真面目に仕事をしているつもりです。

だから怖いのです。

今回の件で、私が痛感した教訓はこれです。

AIエージェントに、削除という選択肢を簡単に与えてはいけない。

実務でAIを使うなら、基本ルールはこうすべきです。

削除しない。
上書きしない。
迷ったら止める。
不要なものは消さずに隔離する。
移動した場合は、移動前と移動後のパスを記録する。

特に大事なのは、「削除」ではなく「隔離」です。

AIに、

「不要なファイルは削除して」

と言うのではなく、

「不要と思われるファイルは、削除せず、_review または _archive フォルダに移動してください」

と指示する。

さらに、

「移動前と移動後のフルパスを一覧で報告してください」
「判断に迷うものは移動せず、要確認としてリストアップしてください」
「私が承認するまで削除・上書きはしないでください」

ここまで書く。

AIエージェントを実務で使うなら、このくらいでちょうどよいと思います。

チャットAIは、基本的には答えるだけです。

しかし、AIエージェントは違います。

ファイルを作る。
ファイルを移動する。
フォルダを整理する。
ツールによっては、コマンドを実行する。
場合によっては、実際の業務環境を変えてしまう。

つまり、便利さのレベルが上がった分、リスクのレベルも上がっています。

これからは、AIを「賢い相談相手」として使うだけでなく、
「作業権限を持った部下」として扱う必要があります。

今回の事件は、結果的には笑い話で終わりました。

ファイルは消えていなかった。
移動されていただけだった。
見つかった瞬間は、本当に力が抜けました。

でも、笑い話で済んだからこそ、今のうちにルール化しておいた方がよいと思いました。

今後、私がAIエージェントにファイル操作を任せるときは、最低限、次のルールを入れます。

1. 削除は禁止
不要ファイルは削除せず、隔離フォルダへ移動する。

2. 上書きは禁止
既存ファイルを変更する場合は、事前にバックアップまたはコピーを作る。

3. 作業範囲を限定する
指定したフォルダ以外は触らない。

4. 移動ログを残す
移動前パス、移動後パス、理由を一覧にする。

5. 判断に迷うものは止める
AIが勝手に判断せず、「要確認」として人間に戻す。

6. 本番前に退避する
Gitで管理できるものはコミットする。
それ以外は作業前コピーを残す。

特に士業や管理部門の業務では、ファイルの紛失や誤削除はかなり致命的です。

申告書。
添付資料。
顧客別ノート。
確認メモ。
過年度資料。
届出書。
税務署や自治体とのやり取り。

こうしたものをAIに整理させる場面は、今後ますます増えていくと思います。

だからこそ、便利さだけでなく、事故が起きたときに戻れる仕組みが必要です。

AIエージェントは、これから間違いなく実務に入ってきます。

でも、任せ方を間違えると、かなり怖い。

今回の私の教訓は、シンプルです。

AIに任せるなら、削除ではなく隔離。
自由に作業させるなら、必ず戻れる状態にしてから。
そして、AIの作業ログは必ず残す。

今回のヒヤリハットは、実務でAIを使ううえでかなり大事な経験になりました。

AIは便利です。
ただし、便利な道具ほど、使い方を間違えると怖い。

笑い話で済んだうちに、運用ルールを作っておく。

これが、AIエージェント時代の実務家に必要な備えなのだと思います。

他人事だと思っていましたが……みなさんもご注意ください！

きっかけは、とても単純です。

会計や税務の仕事では、AIに読ませたい資料がたくさんあります。 上場会社の計算書類、事業報告、月次試算表、契約書、社内資料。

クラウドのAIに入れれば、かなり便利です。 実際、長文を読む力だけでいえば、今のクラウドAIはとても強い。

ただ、何でも気軽にクラウドへ入れてよいわけではありません。 機密性の高い資料、まだ外に出していない数字、顧客情報を含む文書は、どうしても慎重になります。

もちろん、法人向け契約や ZDR（Zero Data Retention）を前提にしたクラウド利用という選択肢はあります。 それでも、

―できるなら、手元のPCの中だけで読ませられないか。

という関心はずっとありました。

そこで今回は、ローカルLLMで計算書類のPDFをどこまで読めるのか、実際に試してみました。

結論からいうと、

ローカルLLMでも、短いPDFならかなり読めます。

ただし同時に、

長いPDFをそのまま丸ごと渡せばよい、というほど簡単ではありませんでした。

むしろ、実務で使おうとすると、 資料の切り方まで含めて設計する必要がある ということがよく分かりました。

まず試したこと

今回試したのは、手元のPC上で動かすローカルLLMです。 モデルは Gemma 4 の26B級。 PDFや画像を読ませながら、計算書類の内容を確認させてみました。

最初に少し驚いたのは、 同じモデルでも、使うアプリによってできることが違う という点です。

LM Studio では、今回の構成では画像入力がうまく通りませんでした。 一方で、Ollama 経由では画像を読ませることができました。

同じ「ローカルLLM」といっても、 モデルだけを見ればよいわけではなく、 どの実行環境で使うかまで含めて挙動が変わります。

短いPDFは、思ったより読める

まず、ページ数の少ない計算書類を読ませてみました。

貸借対照表、損益計算書、株主資本等変動計算書など、数ページ程度の資料です。

この範囲であれば、ローカルLLMでもかなり素直に読めました。 数値の抜き出しや、科目構成の確認、前年との比較といった使い方は、十分に可能性があります。

ただし、長いPDFを丸ごと渡すと危ない

問題は、資料が長くなったときでした。

たとえば、招集通知のように、計算書類だけでなく、事業報告や注記まで含む長いPDFをそのまま渡して読ませると、挙動が怪しくなります。

一見すると、それらしい回答を返してきます。 しかし、よく見ると、 全文をきちんと読んだというより、一部を読んで全体を推測している ような答えが混ざります。

これが、実務では一番怖いところです。

「読めません」と返してくれればまだよいのですが、 ローカルLLMも、クラウドAIと同じく、 読んだように見える答えを返す ことがあります。

分割すると、一気に実用に近づく

そこで、PDFを章ごとに分けて読ませてみました。

たとえば、

• 計算書類だけ

• 事業報告だけ

• 注記だけ

というように、人間が読むときの単位に近い形で切り分けます。

すると、結果はかなり改善しました。

計算書類4ページ程度、事業報告7〜8ページ程度であれば、かなり安定して読めます。 一方で、注記のように文章量が多い箇所は、10ページ程度でも一気に難しくなります。

ここで分かったのは、 単純なページ数ではなく、文字量と情報密度が効いている ということです。

表が中心の4ページと、細かい文章がびっしり詰まった4ページでは、AIにとっての重さが違います。

ローカルLLMで実務資料を扱うなら、 「何ページまで読めるか」ではなく、 どの単位なら、全文をきちんと渡せるか を考えた方がよさそうです。

現時点での結論

今回の試行で、現時点ではこう考えています。

ローカルLLMでも、計算書類のような短い資料はかなり読めます。 機密性の高い資料を手元で扱う選択肢として、十分に可能性があります。

ただし、長い資料を丸ごと渡しても、正確に読み切ってくれるとは限りません。 コンテキストを増やせばすべて解決、という段階でもありません。

実務で使うには、

大きな文書を人間が読む単位に切り、全文を確実に渡せる形に整える。

この一手間が、かなり重要です。

ローカルLLMは、クラウドAIの単純な代用品ではありません。 ただ、資料の切り方や任せ方を工夫すれば、機密資料を扱う現場でも、少しずつ実務に入ってきます。

今はまだ、何でも一発で読ませる段階ではなく、人間が読ませ方を設計する段階なのだと思います。

次に試したいこと

今回は、まず「計算書類PDFをどこまで読めるか」を見ました。

次は、もう少し先へ進めてみたいと思っています。

具体的には、同じ Gemma 4 の調整された Instruct 版も試してみたいと思っています。それで読み取り精度がどう変わるか。

それから、話題になっている MTP による高速化は、実際の手元環境でどこまで効くのか。

さらに、ローカルLLM単体ではなく、 ローカルエージェントに資料を参照させる形にすると、 実務での使い勝手はどう変わるのか。

まだ、試している途中です。

ただ、こういう地味な試行錯誤の先に、 「クラウドに入れにくい資料でも、AIを少しずつ使える」 という現実的な道が見えてくるのではないかと思っています。

ChatGPT、Claude Code、Codex、Gemini CLI、Google Antigravity。
さらに、OpenClaw、Hermes といったAIエージェント系のツールも試しています。

こういうツールを触っていると、つい考えてしまいます。
「Claude Code と Codex はどちらがよいのか？」
「次に伸びるAIエージェントはどれなのか？」

でも、最近は少し考え方が変わってきました。

大事なのは、どのAIが最強かではなく、
どのAIに何を任せるかなのではないか。

そう感じています。

Google Antigravityをコンマスにした

いま、私の中で中心に置いているのは Google Antigravity です。

単なるチャット相手というより、コンサートマスターのような位置づけです。

考えたことを整理する。作業の流れを組み立てる。
必要に応じて、自分でも実行するし、他のAIツールにも仕事を振る。

ChatGPTに相談しながら方向性を決め、Google Antigravityで作業を整理する。
Gemini CLI に調査を依頼し、実装はClaude Code に振る。レビューや検証は Codex に依頼する。

そう考えると、Google Antigravity は単体で何かをするツールというより、チーム全体を動かす管制役に近い存在です。

正本はObsidianに置く

ただし、Google Antigravity にすべてを閉じ込めるつもりはありません。

AIツールは変化が速いです。
昨日まで調子がよかったツールが、今日は少し不安定になる。
逆に、別のツールが急に使いやすくなる。

だから、仕様、判断、運用ルール、作業ログなどの正本は、なるべく Obsidian に置くようにしています。

AIツールは、その時々で使い分ける。でも、正本は Obsidian に残す。

この形にしておくと、使うAIが変わっても、前提を引き継ぎやすくなります。

自分がやったのは、役割を決めたこと

私はエンジニアではありません。

すべてを自分で一から作っているわけではありません。
むしろ、ChatGPTに相談しながら、Google Antigravityに整理してもらい、必要に応じて他のAIツールに仕事を振っています。

自分がやったことは、突き詰めるとかなりシンプルです。

どこに正本を置くか。
どのAIに何を任せるか。
どこで人間が確認するか。
そして、全体を誰に取りまとめてもらうか。

私の場合、その取りまとめ役に Google Antigravity を置きました。

単体ツール選びから、チーム設計へ

これまでAI活用というと、どうしても「どのツールが一番よいか」という話になりがちでした。

もちろん、ツール選びは大事です。
性能差もありますし、得意不得意もあります。

ただ、実際に使ってみると、単体で完璧なAIを探すより、役割分担を考えた方が実務には合う気がしています。

大事なのは、最強のAIを一つ探すことではない。
自分の仕事に合わせて、AIたちの役割を決めること。

私が作っているのは、AIオーケストラかもしれません。

そして、その中心にいるコンマスが、今のところ Google Antigravity です。

名前だけ聞くと、「入れたらすぐに働いてくれそう」な雰囲気があります。
実際、インストールして動かすところまでは進みます。

画面が立ち上がる。
コマンドが動く。
ログも出る。

「お、これはいけるのでは？」と思います。

でも、そこからが本番でした。

最初から賢く動くわけではない

いま、Hermes というAIエージェントを「見習い秘書」のように育てようとしています。

OpenClaw などが出したログや報告書を読み、人間が判断しやすい形に整理してもらう。
そんなタスクを与えてみました。

ところが、最初からうまくはいきませんでした。

重いモデルを回してしまい、処理がかなり遅くなる。
軽いモデルに変えたら、日本語で頼んだのに中国語で返ってくる。
指定した出力形式を守らない。

最初は、つい「このモデルはあまり賢くないのかな」と思いそうになります。

でも、何度か試していくうちに、見え方が変わってきました。

失敗は、モデルの能力不足とは限らない

AIエージェントの失敗は、必ずしもモデルの能力不足とは限りません。

ファイルの渡し方。
プロンプトの型。
出力フォーマット。

こうした指示の仕方が効いてきます。

また、AIに「この報告書をレビューして」とだけ渡しても、期待する見方をしてくれるとは限りません。

「結論だけ出してほしい」のか。
「異常なしという判断を疑ってほしい」のか。
「次に人間が見るべきポイントを出してほしい」のか。

そこまで明確にして初めて、AIエージェントは仕事の型を理解し始めます。

人間の部下に仕事を頼むときと似ています。

ChatGPTに相談しながら育てている

私はエンジニアではありません。
実はAI全般のことは、ChatGPTに相談しながら、二人三脚で進めています。

どのモデルを使うか。
どんなプロンプトにするか。
どんな出力形式にするか。

こうしたことを一つずつ整理していきました。

最初は出力が崩れました。
そこで、出力項目を固定しました。

結論。
事実。
論点・リスク。
誤読の余地。
次に見るべきログ。

このように、報告書の型を決めました。

すると、少しずつ回答が変わってきます。

最初はただの感想に近かったものが、だんだん「報告書レビュー」らしくなっていく。
まさに、見習い秘書を育てている感覚に近いものでした。

最初から何でも任せない

AIエージェントというと、つい「何でも自動でやってくれるもの」と考えたくなります。

でも、実際にはそうではありません。

大事なのは、最初から何でも任せないことです。

OpenClaw には実行役としての仕事を任せる。
Hermes には報告書を読み、判断材料にする仕事を任せる。
Mercury には補佐的な読み取りや提案を任せる。

それぞれのAIに、いきなり全部を任せるのではなく、役割を分ける。

そして、最初は狭い仕事から始める。

AIエージェントも一日にしてならず

AIエージェントは、導入して即完成するものではありません。

役割を決め、型を与え、失敗を観察し、少しずつ育てていくものです。

今はまだ、見習い秘書を育てている途中です。

でも、その過程も含めて、かなり面白い時代になってきたなと感じています。

OpenClaw、Hermes、Mercuryと導入していくと、最初はどれも「動いた」ように見える。
でも、動くことと、実務で任せられることは別だった。

2. Mercuryにログ監視を任せようとした

Mercuryには、管制補佐としてログの最新行やエラー有無を見てもらおうとした。
しかし、実際には以下の課題が出た。

• 存在するログを「存在しない」と誤認する

• ディレクトリを渡すと勝手に探索する

• 指示していない場所を見に行く

• 存在しないパスの扱いはできる

• Cドライブ側の安全なファイルなら読める

3. 問題は「能力不足」ではなく「任せ方」だった

Mercuryがダメというより、
「ログ監視」というタスクがまだ広すぎた。

ログ監視には、実は複数の判断が含まれる。

• どのファイルを見るか

• パスが存在するか

• ディレクトリかファイルか

• 最新行はどれか

• エラー件数をどう数えるか

• 見えないものをどう報告するか

これを全部まとめて任せると、軽量エージェントは崩れる。

4. そこで役割を小さくした

最終的に、Mercuryには直接ログを見せない方針にした。

• Antigravity／Gemini CLIがログを抽出

• Cドライブ側にログスナップショットを保存

• Mercuryはその1ファイルだけ読む

• 返答は「エラー有無」「最新行」「判定不能」だけ

つまり、AIエージェントを育てるとは、能力を盛ることではなく、失敗しないサイズまで仕事を削ることだった。

5. 実務での教訓

AIエージェントに仕事を任せるとき、最初に必要なのは自由度ではなく制約である。

「できること」を増やす前に、「してはいけないこと」を決める。

そのうえで、1ファイル、1判断、1行出力から始める。

AIエージェントは、いきなり有能な部下になるのではなく、まず「任せてよい仕事のサイズ」を人間側が設計するところから始まる。

Claude Codeが不調だ。
Codexが速い。
Gemini CLIも使える。

そんな話が毎日のように流れてきます。

でも、これは単に「どのAIツールが最強か」という話ではありません。

むしろ大事なのは、どのAIツールが不調になっても、仕事が止まらない設計にしておくことだと思っています。

AIツールは、良くも悪くも変化が速い

AIツールは進化が速いです。

昨日まで調子がよかったツールが、今日少し微妙になることもあります。
逆に、別のツールが急に伸びてくることもあります。

Claude Code、Codex、Gemini CLI、その他のエージェント系ツールも、アップデートによって使い勝手が大きく変わります。

だから、ひとつのツールに業務の記憶や判断を閉じ込めてしまうのは危ない。

ツールに依存しすぎると、そのツールが不調になった瞬間に、仕事の流れまで止まってしまいます。

大事なのは「正本」をAI側に置かないこと

私の場合、仕様、判断、運用ルール、作業ログはObsidianに置くようにしています。

Claude Code、Codex、Gemini CLIは、あくまで実行役です。

Claude Codeが実装する。
Codexがレビューする。
Gemini CLIが整理する。

でも、前提や判断の置き場はAIツール側ではなく、Obsidianに置く。

そうしておけば、どれかのツールが不調になっても、Obsidianに残っている前提を別のAIに渡せます。

つまり、AIツールを乗り換えても、毎回ゼロから説明し直さなくてよくなります。

役割分担のイメージ

今のところ、私の中では次のように整理しています。

Claude Code：実装・Skill・Routines
Codex：レビュー・修正・監査
Gemini CLI：軽作業・整理・Google系作業
Obsidian：正本・長期記憶・判断の置き場

もちろん、この役割分担も固定ではありません。

AIツールはどんどん変わるので、その時点で一番使いやすいものに役割を寄せればよいと思っています。

大事なのは、どのツールを使うかではなく、どのツールにも移れる状態にしておくことです。

クラウドAIだけでなく、ローカルにも移れる設計にする

さらにいうと、これはクラウドAI同士の乗り換えだけの話ではありません。

Claude CodeからCodexへ。
CodexからGemini CLIへ。

というだけでなく、必要に応じて、ローカルLLMや自前のエージェント環境にも移れるようにしておくことが重要です。

クラウドAIは便利ですが、料金、速度、制限、障害、仕様変更の影響を受けます。

一方で、ローカルLLMや自前環境は、すべてを任せるにはまだ難しい部分もありますが、特定の用途では十分使える場面も増えています。

だからこそ、クラウドかローカルかを最初から固定しない。

どちらにも移れるように、業務の前提や判断を自分の管理下に置いておく。

そのための置き場として、Obsidianはかなり相性がよいと感じています。

結論

AIツールは、乗り換え前提で使う時代になってきました。

ただし、毎回ゼロからやり直さないためには、正本を自分の管理下に置いておく必要があります。

最強のAIツールを探すより、どのAIにも移れる設計にしておく方が強い。

そして、その設計はクラウドAI同士の乗り換えだけでなく、ローカルLLMや自前のエージェント環境への移行も含めて考えるべきです。

仕様、判断、運用ルール、作業ログの正本は、AIツール側ではなくObsidianに置く。

これが、AIツールの変化が激しい時代に、仕事を止めないための基本設計だと思っています。

OpenClaw、Hermes Agent、Mercury Agent…

正直、最初に思ったのは
「これ、どれが最強なんだ？」でした。

でも実際に触ってみて分かったのは、
“最強は存在しない”ということです。

■ 結論：単体最強ではなく「役割分担」

現時点の構成はこうしています。

• OpenClaw（VPS） → 実行担当

• Hermes（WSL） → 思考・実験

• Mercury（WSL） → 管制補佐（監視）

つまり、

👉 AIを1つ選ぶのではなく、役割で分ける

■ ただし問題がある

そのまま使うとどうなるか。

実際に起きたこと👇

• 勝手にディレクトリを探索する

• ログを読まずに「それっぽいこと」を言う（嘘）

• 無駄に長文を出す

• トークンが一瞬で溶ける（3万token超）

• 処理がループして止まらない

正直、「これ業務で使えるのか？」という状態でした。

■ 解決方法はシンプルだった

いろいろ試しましたが、結局これでした。

👉 「できることを減らす」

■ 実際にやったこと

① まず list_dir しかやらせない

対象ディレクトリだけ確認して、entries数だけ返す

👉 これで初めて安定

② 次にファイル名だけ

list_dirで取得したファイル名だけ列挙

👉 まだ読ませない

③ 1ファイルだけ読む

errors.log だけ read_file

👉 他は禁止

④ エラー件数だけ返す

要約禁止、件数だけ

👉 初めて「使える」状態に

■ ここで気づいたこと

AIエージェントは

👉 賢すぎるから壊れる

正確にはこうです。

• 何でもできる
  

• だから何でもやろうとする
  

• だからズレる
  

■ 本質

👉 AIは賢さで使うのではなく、制約で使う

■ 今の状態

現時点でできることはこれです。

• ログディレクトリ確認
  

• ファイル一覧取得
  

• 指定ログのエラー件数確認
  

やっていないこと👇

• 要約
  

• 判断
  

• 自動実行
  

• 書き込み
  

■ なぜこれでいいのか

理由は単純です。

👉 嘘をつかないから

■ 次にやること

• agent.logの最新行取得
  

• その後に要約を段階解禁
  

• OpenClawログの統合
  

■ まとめ

AIエージェントは

• 育てるものではなく
  

• 最適化するものでもなく
  

👉 縛るもの

でした。

■ 最後に

今回の構成、

• OpenClaw
  

• Hermes
  

• Mercury
  

を全部入れて分かったのは

👉 「どう使うか」のほうが「何を使うか」より重要

ということです。

AIエージェントは強力ですが、
ツールを増やすほど効率が上がるわけではありません。

むしろ、設計を誤ると
・どこで何をしているか分からない
・責任の所在が曖昧になる
といった問題が発生します。

前提

現在、OpenClaw・Hermes・各種エージェントツールなど、
選択肢が急激に増えています。

いろいろ試しながら進めるのは重要ですが、
いくつか注意点があります。

注意点① ツールを増やしすぎない

新しいツールが出るたびに追加していくと、
全体構成が崩れます。

実務では、
「どれを使うか」よりも
「どれを使わないか」を決める方が重要です。

注意点② 役割を分ける

エージェントは用途ごとに分けないと機能しません。

例えば、
・思考（整理・設計）
・実行（処理・自動化）
・検証（レビュー）

この3つを分けるだけで、安定性が大きく変わります。

注意点③ 本番と実験を分ける

新しいツールは魅力的ですが、
いきなり業務に入れるのはリスクがあります。

実務では、
・本番環境（安定性重視）
・実験環境（検証用）
を明確に分ける必要があります。

注意点④ 再現性を優先する

一度うまくいった方法でも、
再現できなければ意味がありません。

特に士業の場合、
「誰がやっても同じ結果になるか」が重要です。

注意点⑤ 最終判断は人が行う

AIエージェントは補助ツールであり、
最終的な判断を任せるものではありません。

出力の検証と責任は、
必ず人が持つ必要があります。

現時点の整理

現時点では、シンプルに以下の構成で運用しています。

・思考：Hermes / 対話型AI
・実行：OpenClaw
・検証：Codex

新しいツールについては、
検証しながら段階的に取り入れています。

最後に

AIエージェントは「ツール」ではなく、
「仕事の設計」に近いものです。

何を使うかよりも、
どう組み合わせるか。

この視点を持つことが、
実務で活用する上では重要だと考えています。

生成AIの利用ルールは、業界によって大きく異なります。

・医療現場 → 原則禁止＋厳格管理
・一般企業 → 条件付きで活用

この違いを理解せずに運用すると、
過剰な制限か、重大なリスクのどちらかに陥ります。

実務で重要なのは、次の3点です。

比較（実務で重要なポイント）

この3点を押さえるだけでも、AI利用のリスクは大きく変わります。

最後に

生成AIは強力なツールですが、
「どの業界でも同じように使えるものではない」という前提が重要です。

自社の業務・リスクに応じて、適切な線引きを設計すること。
これが、これからの実務において不可欠だと考えています。

※医療機関・企業それぞれの実務で使える比較表も整理しています。
社内ルール整備やAI導入のたたき台として使いたい方は、お気軽にコメントください。

AIは税理士業務の多くに活用できますが、
「任せていいこと」と「任せてはいけないこと」は明確に分ける必要があります。

特に重要なのは、
・データの取り扱い
・最終判断の責任

この2点です。

前提（実務ルール）

当事務所では、AIの利用について以下のルールを設けています。

・法人契約のAIのみ使用（無料版は使用しない）
・一般的な財務情報はクラウドAI
・個人情報・機密情報はローカル環境
・最終判断は必ず人が行う

この前提で、どこまで任せるかを考えています。

任せていいこと

以下は、現時点でもAIに任せて問題ない領域です。

・論点整理
・財務データの初期分析
・調査のたたき台
・資料の下書き

いずれも「作業」に該当する部分です。

これらはAIの方が速く、効率的です。

任せ方を変えるべきこと

一方で、データの性質によって使い分けが必要です。

・一般的な財務情報 → クラウドAI
・マイナンバー等の機密情報 → ローカル環境

ここを誤ると、利便性よりもリスクが上回ります。

任せてはいけないこと

以下は、AIに任せてはいけない領域です。

・最終判断
・対外的な説明
・検証を省略した意思決定

AIの出力をそのまま使うことは、実務上のリスクになります。

特に、税務判断は前提条件によって結論が変わるため、
人間による確認は不可欠です。

実務上のポイント

AIを使う上で重要なのは、
「何を任せるか」よりも「どう使うか」です。

・必ず前提を確認する
・出力の根拠を検証する
・最終責任は人が持つ

この3点を外さなければ、AIは強力なツールになります。

最後に

AIの導入は、ツールの問題ではなく運用の問題です。

ルールを決めずに使うとリスクになりますが、
適切に使えば実務の質と効率を大きく高めることができます。

この線引きを明確にすることが、今の実務では重要だと考えています。

AI導入の失敗は、ツールの問題ではなく「使い方の設計ミス」で起きます。
特に多いのは、「目的が曖昧なまま導入する」「人の判断を外してしまう」この2点です。

AIは強力なツールですが、前提を間違えるとむしろ非効率になります。

よくある失敗パターン

実務で見ていると、AI導入の失敗にはいくつか共通点があります。

① 目的が曖昧

「とりあえずAIを入れる」というケースです。

・何を効率化したいのか
・どの業務に使うのか
・どこまで任せるのか

これが決まっていないまま導入すると、結局使われなくなります。

② 作業と判断を分けていない

AIに任せるべきは「作業」であって、「判断」ではありません。

しかし実際には、
・そのまま出力を使う
・検証せずに意思決定に使う

といった使い方がされがちです。

これがリスクの原因になります。

③ 過度な期待

AIに対して「完璧さ」を求めると、必ず失敗します。

AIはあくまで補助ツールであり、
・前提のズレ
・情報の不足
によって結果が変わります。

この特性を理解せずに使うと、「使えない」という評価になりがちです。

④ 業務フローに組み込んでいない

単発で使うだけでは、効果は限定的です。

重要なのは、
・どのタイミングで使うか
・誰がチェックするか
・どこで最終判断するか

といった「流れの設計」です。

ここができていないと、AIは定着しません。

ではどうすればいいか

基本はシンプルです。

・作業はAIに任せる
・判断は人が行う

この役割分担を前提に、業務に組み込みます。

さらに、

・使う目的を明確にする
・出力は必ず検証する
・小さく試して広げる

この3点を意識するだけで、失敗の多くは避けられます。

実務での使い方（現実的なライン）

現時点では、以下の用途が現実的です。

・論点整理
・調査のたたき台
・資料の下書き

一方で、

・最終判断
・対外的な説明
・リスクを伴う意思決定

は、人が責任を持って行う必要があります。

最後に

AI導入は、「ツールを入れること」ではなく「仕事のやり方を変えること」です。

うまくいくかどうかは、
ツールの性能ではなく、設計の質で決まります。

この前提を外さなければ、AIは確実に実務の武器になります。