わかりやすい言葉で良い抽出スキーマを書く方法

ほとんどの人が Ztract で最初にやるのは、プロジェクトを作ることです。そして次にやること——出力の良し悪しを決めるのは、まさにこの手順です——文書から何を取り出したいかを伝えることです。その説明が、あなたのスキーマになります。

ここで意外に思われるのが、コードで書く必要はないということ。覚えるべき記法も、宣言すべきフィールドの型も、ページ上に描くテンプレートもありません。新しく入った同僚に説明するのと同じ感覚で、ほしいものを言葉にするだけです。たとえば 「請求書ごとに、取引先名、合計金額、そして明細行をすべて取り出してください」 といった具合に。あとはエンジンがやってくれます。

その自由さこそがこの仕組みの核心です——ただし、それは同時に、出力の質があなたの説明の質に比例することも意味します。あいまいな依頼からはあいまいな結果が返り、的確な依頼からは、最初の一回で信頼できるきれいなデータが返ってきます。この記事では、どんな種類の文書を扱う場合でも、わかりやすい言葉で書いたスキーマを的確なものにする、いくつかのコツについてお話しします。

良いスキーマとはどんなものか

ルールに入る前に、うまく機能する説明の「かたち」を見てみましょう。たとえば請求書を抽出するとします。

「請求書ごとに、請求書番号、発行日、取引先名、支払合計額を取り出してください。あわせて、各明細行について、品目の説明、数量、単価、行ごとの金額も取り出してください。文書に存在しない項目は、推測せず空欄のままにしてください。」

この説明が何をしているか、注目してみてください。「大事なところ」ではなく、具体的なフィールドを名指ししています。文書に1つしかないもの（請求書番号、合計）と、複数あるもの（明細行）を分けています。そして、何かが見当たらないときにどうするかも書いています。どれも技術的な話ではありません——ただ的確なだけです。これから紹介する5つのコツが、その状態にたどり着くための道筋です。

スキーマを的確にする5つのコツ

1. どの値のことなのかを具体的に伝える

文書は、見た目のよく似た数字や日付であふれています。請求書の「金額」と言っても、小計のことか、税額のことか、割引前の金額か、最終的な支払合計か、いろいろ考えられます。「金額を取り出して」 とだけ書けば、どれが選ばれるかは運任せになってしまいます。

正確にどれなのかを名指ししましょう。

• ❌ 「日付」 → ✅ 「請求書の発行日（支払期日ではなく）」
• ❌ 「金額」 → ✅ 「税込・割引後の支払合計額」
• ❌ 「名前」 → ✅ 「取引先の会社名（担当者名ではなく）」

文書に紛らわしいフィールドが多いほど、この点が効いてきます。

2. どんな形式でほしいかを伝える

エンジンはページに書かれているものをそのまま読み取りますが、実際には一定の形にそろえてほしいことが多いものです——特に日付、数値、通貨については。形式が気になるなら、そう伝えましょう。

• 「日付はすべて YYYY-MM-DD の形式にそろえてください。」
• 「金額は通貨記号や桁区切りなしの、ただの数値で表してください。」
• 「出金（引き落とし）はマイナスの数値として記録してください。」
• 「通貨コード（USD、EUR など）は別のフィールドとして含めてください。」

これを伝えないと、文書に表示されているまま——$1,250.00、1.250,00、(1,250.00)——が返ってきて、あとで表計算ソフトで整える羽目になります。最初のひと言が、その手間を省いてくれます。

3. 「文書に1つ」と「行ごとに1つ」を分ける

これが多くの人がいちばんつまずくポイントで、じっくり押さえておく価値があります。文書に1度だけ現れるフィールドもあります——請求書番号、銀行取引明細書の対象期間、口座名義人など。一方で繰り返し現れるものもあります——明細行のひとつひとつ、取引のひとつひとつ、チケットの搭乗者のひとりひとり。

この2つを区別しないと、リストがほしかったのに値が1つだけ返ってきたり、構造がほしかったのに平らに潰れたぐちゃぐちゃの結果になったりします。解決策は、それをはっきり口に出すことです。

「明細書レベルの項目は1回だけ取り出してください。口座名義人、口座番号、期首残高、期末残高です。そのうえで、取引ひとつひとつをそれぞれ1行として、日付・摘要・金額とともに取り出してください。」

「〜ごとに」という言葉が味方になります。「明細行ごとに……」、「取引ごとに……」 と言えば、エンジンはリストを期待し、ごちゃ混ぜではなく、きれいに繰り返される行を返してくれます。

4. 紛らわしいフィールドには、ひと言の区別を添える

なかには本当にあいまいで、ページをいくら読んでも判断できないフィールドもあります——それを決められるのは、あなたの意図だけです。たとえば通関書類には、請求書番号と発注番号（PO）の両方、出荷先住所と請求先住所の両方、総重量と正味重量の両方が載っていることもあります。

2つのフィールドが取り違えられそうなときは、短い手がかりを添えましょう。

• 「請求書番号（売り手側の、『INV』と書かれたもの。PO 番号ではなく）」
• 「出荷先住所（商品の配送先。請求先住所ではなく）」

本当に必要なのがどちらか、あなたにはわかっています。それを書いておくだけで、推測の余地がなくなります。

5. フィールドが見当たらないときどうするかを決める

実際の文書はばらつきがあるものです。ある請求書には PO 番号があり、次の請求書にはない。どうするかを伝えなければ、判断は宙ぶらりんのまま——そして抽出においては、ほぼ間違いなくほしい安全な初期設定は 何も作り出さないこと です。

「文書に存在しない項目は、空欄のままにしてください。推測したり、仮の値で埋めたりしないでください。」

このひと言は、財務・法務・医療の文書で特に効いてきます。自信ありげに間違った値が入るほうが、目に見えて確認できる空欄よりも、はるかに危険だからです。

スキーマを作る3つの方法——どれをいつ使うか

Ztract には3つの出発点が用意されています。これまでのコツはどの方法にも当てはまります。違うのは、どこから始めるかだけです。

• 既製のスキーマから始める。 よくある文書——請求書、領収書、銀行明細書、本人確認書類、履歴書、契約書、検査報告書、通関書類など——には、定番のフィールドをあらかじめ把握したテンプレートが用意されています。文書が標準的な種類で、まず素早く始めてから微調整したいときに最適です。
• フィールドを自分で説明する。 わかりやすい言葉での説明を一から書きます。文書が珍しい形式のとき、あるいは「このフィールドだけ、ほかは一切いらない」というときに最適です。ここでこそ、5つのコツが本領を発揮します。
• サンプルから推測させる。 代表的な文書を1つ放り込めば、エンジンがそこから読み取った内容をもとにスキーマを提案してくれます。1つ見てみるまで、その文書にどんなフィールドが含まれているかわからない、というときに最適です——提案を受け取ったら、わかりやすい言葉で仕上げていきます。

結局のところ、多くの人はこれらを組み合わせて使います。テンプレートやサンプルから始め、それから上記のコツを使って、説明を手作業で磨き上げていくのです。

さらに詳しくは、スキーマの設計のドキュメントページもご覧ください。

ちょっとしたトラブル対処表

出力が思ったとおりでないとき、原因はたいてい説明のなかにあります。よくあるものを挙げます。

起きていること	考えられる原因	対処法
「金額」で違う数字が取られる	フィールドが具体的でなかった	正確な値を名指しする：「税込の支払合計」
日付の形式がバラバラ	形式を指定していない	「日付はすべて YYYY-MM-DD にそろえる」 と添える
リストがほしかったのに値が1つだけ	繰り返しフィールドを指定していない	「〜ごとに……を取り出す」 を使う
リストが1セルに潰れている	上と同じ	同じ——行ごとのフィールドをはっきり名指しする
どこにもないフィールドが作られた	欠損時のルールがない	「なければ空欄に、推測しない」 と添える
似た2つのフィールドが入れ替わる	区別を書いていない	手がかりを添える：「PO 番号ではなく請求書番号」

スキーマは、ループの半分にすぎない

よく書けたスキーマでも、もう一度見直す価値はあります。Ztract はまさにそれを前提に作られています。抽出された値はすべて、元の文書での位置に紐づいています——値をクリックすれば、それがどこから来たのかがそのまま確認できます。おかしそうなものをざっと探して、ワンクリックで直せば、それで完了です。修正には費用は一切かかりません。ページ数に数えられるのは抽出だけで、そのあとの編集はカウントされません。

ですから、良いスキーマの目標は、最初の一回で完璧にすることではありません——見直しの工程が「やり直し」ではなく「さっと目を通すだけ」で済む程度に、十分近づけることです。上記の5つのコツが、あなたをそこへ連れていってくれます。

実際の文書で試してみる

これを体感するいちばんの近道は、ふだん扱っている文書のために説明を書いてみて、何が返ってくるかを見てみることです。新規アカウントには30ページ分の無料枠が付いていて、クレジットカードも不要です——スキーマを下書きし、磨き上げ、その過程で出力が引き締まっていく様子を見るには十分な量です。

そして、ある種類の文書や、説明しようとしたスキーマでうまくいかなかったとき——ほしい結果を得るための言葉が見つからなかったとき——それこそが、私たちがいちばん知りたいフィードバックです。ぜひお聞かせください。エンジニアでない人にとってもスキーマ設計が「当たり前にできる」ものだと感じられるようにすること、それがこのプロダクトで私たちがいちばんうまくやり遂げたいと思っている部分なのです。