ゼネフェクトの後藤です。字を書くのが面倒で、申請書のスキャン画像にブラウザ上でテキストを重ねて印刷する paperscribe というツールを今月の上旬に作りました。作ってすぐに「AI エージェントの普及で『紙の書類を埋める』という仕事自体がいずれ消える」と判断して、ローカル開発のまま公開はせずに止めていたのですが、その数日後に別件で AI に紙の退会届を埋めさせる必要が出てきて引っ張り出したところ、想定と違う形でしばらく生き残れる可能性が見えたので、改めて paperscribe.zeneffect.co.jp として公開しました。
paperscribe とは
A4 縦の紙書類（PNG / JPG のスキャン画像）を読み込んで、その上に任意の位置でテキストを重ね、そのまま印刷すれば紙が埋まる、というだけのブラウザツールです。バックエンドなし、画像も入力データもブラウザ内のメモリにしか存在しません。window.formBuilder という外部 API を持っていて、Claude in Chrome のような操作エージェントから記入欄の追加・更新・印刷を呼べるようになっています。
ライブで動くものは paperscribe.zeneffect.co.jp にあります。
なぜ作って、なぜサービス化を見送ったか
そもそもは「銀行や行政の申請書を手書きするのが面倒」という、本当に個人的なズボラがきっかけでした。スキャン画像にテキストを重ねてプリンタに流せばよい、という発想だけのものを書きました。
ただ作ったあとに考えてみると、AI エージェントがマルチモーダルで紙の画像を読んで、入力済み PDF を直接生成できるようになるのは時間の問題に思えました。「紙を埋めるという作業そのものが、近い将来 AI に肩代わりされる」 という前提に立てば、こういう中間ツールはいずれ要らなくなる。だったら作り込んで世に出すほどでもないだろう、と判断して、サービスとして公開する方針は一度見送ることにしました。
引っ張り出した経緯
きっかけは、社の法人クレジットカードを退会する手続きが必要になったことでした。退会届は紙だけ受け付けで、郵送、印鑑必須。手書きしてもよかったのですが、せっかくだし AI に任せてみようと、Cowork（Anthropic の提供するエージェントツール）に書類のスキャンを渡して埋めさせようとしました。
その時に paperscribe を引っ張り出して試してみたら、思ったよりうまく回りました。
Cowork は Claude in Chrome 経由でブラウザを操作できるので、こちらは「この書式の画像を読み込ませて、こういう内容で記入欄を置いてください」と指示するだけで、paperscribe の addField API を Cowork が直接叩いてフィールドを配置していきます。仕上がった印刷プレビューを PDF として一度書き出し、それを Cowork に見せて「氏名欄が罫線とぶつかってるからもう少し右上」「住所欄、もう少し右」みたいに自然言語で補正を伝えると、updateField で位置を調整してくれます。3 回ほど往復してきれいに収まった状態で完成しました。
紙の書類を埋める作業は AI に丸ごと取って代わられる、というのが見送り判断時の前提でしたが、現実はそこまで単純ではありませんでした。「印字部分は AI に、印鑑や自署のように物理性がどうしても残る部分や、AI 側が安全策で扱いを断る情報は人間に」 というハイブリッドな運用が、いまの過渡期では一番落ち着く形になっている。実際 Cowork のようなエージェントは、クレジットカード番号や銀行口座番号といった機密性の高い数値の入力を、安全策として明示的に拒否してきます(これは AI 側の正しい振る舞いだと思います)。そういう箇所も結局は人間が手で打つことになる。そして paperscribe は、その「印字部分のうち、AI が扱える部分」で、AI が直接操作できる薄い土台として機能していました。
AI に使われるツールとしての再定義
paperscribe を作っていたときに、わりとあっさり書いていた window.formBuilder API が、結果的に AI エージェントから扱いやすい形になっていました。これは正直、当初狙ったというより副産物に近いのですが、振り返るとこういう判断が効いていたと思います。
- 入力フィールドパーツの CRUD だけを露出した薄い API にして、画像から記入欄を自動検出するような重い機能はアプリ側に持たなかった。座標推定はマルチモーダル AI 側に完全に委ねる
- API 仕様を画面サイドバーに plain text として常時掲載しておく。エージェントが
get_page_textで読み取れるようになる - 配置の初期出しは AI に、微調整は人間に。実用では、複雑なレイアウトの書類だと AI の一発配置がそのまま枠内に収まることは少なく、結局人間がドラッグや矢印キーで微調整する。なので「AI が大まかに置く → 人間がズレを直す」という責務分割を前提に、UI 側で微調整 (ドラッグ、矢印キーで 1px 単位の移動、Option+矢印で文字間調整) ができるようにしておく
- 印刷はブラウザ標準ダイアログに任せる。アプリは印刷プレビューを呼ぶところまで担い、ダイアログ操作 (PDF 保存先指定、実印刷) は人間に戻す
「画像認識・配置判定・自然言語での補正指示」という、AI が本来得意な部分を AI に渡し、「座標が一貫している描画と印刷」というアプリの責務だけを paperscribe が引き受ける。気付いてみると、人と AI の責務分割がそのまま設計に落ちている形になっていました。
設計の備忘
「なぜ paperscribe はこういう形なのか」を、いま明文化しておくと将来の自分が迷わずに済むので、ここで簡単に残します。
バックエンドなし、単一 HTML を維持。スキャン書類は個人情報を含むことが多いので、サーバーに何も送らない設計を最優先しています。Vercel Web Analytics でページビューだけは集計していますが、書類画像と入力内容はブラウザ外には出ません。
自動配置はやらない、外部エージェントに完全委譲する。画像から記入欄を自動検出する処理を持つと、認識精度の責任をアプリが背負うことになります。それは AI モデル側の進化に乗ったほうが速いので、paperscribe は入力フィールドの追加・更新・削除といった CRUD だけを持つ薄い実装に振り切りました。
座標系の真値は元画像のピクセル座標で持つ。画面表示と印刷で単位が混ざるので層構造にはなりますが、データとして保持する値だけは1種類に正規化することで、外部 API から扱いやすくしています。
役目を終えることが完成形
paperscribe は AI エージェントが「画像を見てそのまま入力済み PDF を直接生成する」までは到達していない、過渡期にだけ存在するツールです。AI の視覚理解とドキュメント生成が成熟すれば、こういう中間レイヤーは不要になります。そしてそれは、私たちが目指している未来そのものでもあります。
なので paperscribe は 「長く生き残らせたい何か」ではなく、「不要になるべき、移行期のための足場」 として位置付けています。Vercel のアクセスを観察するのも、規模を測るためというより、利用がゼロに収束していく曲線をきちんと見届けるためです。役目を終えたタイミングで静かに片付ければよい、と思っています。
おわりに
paperscribe.zeneffect.co.jp で動いています。書類画像をドラッグ＆ドロップで読み込ませて、紙面をクリックすれば記入欄が置けます。Cowork や Claude in Chrome のような操作エージェントを持っていれば、`window.formBuilder` 経由で座標を任せる使い方もできます。これからも、こういう「個人のズボラから始まった、いずれ要らなくなるべき」小さなプロジェクトを、設計の判断を添えて記事として残していこうと考えています。AI が成熟する過程で必要になる足場と、その足場が外れた後に残る設計の知見、両方を書き残せる場所として、ブログを運用していくつもりです。
