新しい取引先の登録の申請を Power Automate で受け、添付の登記・口座・インボイスの登録番号の書類と申請の記載の食い違いと不足を拾う

処理の起点を決める

申請の行が作られたことを起点にします。 When an item is created は新しい行ごとに動きます。修正のたびに動くトリガーは使いません。 フローが照合の結果を同じリストに書き戻すと、その書き込みでまた動くからです。

添付が後から足されることがあります。 拠点の担当が申請を先に保存し、書類を後で添付する場合です。申請の画面に「書類をそろえた」のチェック欄を置き、そこにチェックが付いたら照合を始める形にします。チェックの変更を見るために、トリガーの条件に「チェック欄が はい」を設定し、照合を始めたら「照合中」に変えて二重に動かないようにします。

差し戻した申請の出し直しも同じ行で受け、 前回の照合の結果を残したまま新しい照合を始めます。

入力データを集める

質を決めるのは、表記の置き換えの一覧です。 口座名義のカナは、銀行ごと・取引先ごとに略し方が揺れます。「カ）」「（カ」「カブシキガイシヤ」を同じものとして扱う、小さい「ャ」を大きい「ヤ」と同じとして扱う、といった置き換えを一覧にし、照合の前に申請と書類の両方へかけます。置き換えた後に残った違いだけを「不一致」にします。

公表情報は、申請と書類のどちらとも別の第三の情報として使います。 申請と書類が一致していても、公表情報の名称と違えば、登記の後に商号が変わっているか、書類が古いということです。

データの取得方法を決める

国税庁の Web-API は、アプリケーションIDが無いと使えません。 発行は無料で、適格請求書発行事業者公表システムのIDは、メールアドレスの仮登録、基本情報の本登録、国税庁の審査を経て発行されるとされています。このIDで、法人番号システムの Web-API も使えます。 法人番号システムのIDの発行には2週間から1か月ほどかかるとされているので、構築を始める前に申し込みます。

法人番号システムの Web-API は、法人番号を指定すると名称・所在地・法人番号の基本の3情報と付随する情報を返し、 条件を付ければ変更履歴も取れるとされています。1回で10件までの法人番号を指定できます。適格請求書発行事業者公表システムの Web-API は、登録番号の指定、取得期間の指定、登録番号と日付の指定の3つの機能があるとされています。登録番号と日付の指定を使えば、取引を始める日の時点で登録が有効かを確かめられます。

個人事業主は法人番号が無いので、法人番号の照会を飛ばします。 登録番号があれば適格請求書発行事業者公表システムだけを引き、登記の照合の代わりに、添付された開業の届出の控えなどの氏名と屋号を写させます。

AIへ渡す前に整形する

1. 添付の数と形式の確認 … 添付が3つそろっているか、形式が PDF・PNG・JPG・JPEG かを確かめます。Office の形式は PDF にしてもらいます
2. サイズとページの確認 … ファイルの合計が25MB未満、50ページ未満でないものは、分けて添付し直してもらいます
3. パスワードの付いたPDFの確認 … 開けないPDFは、AIに渡さずに「読めない」として返します
4. 法人番号と登録番号の形の確認 … 法人番号が13桁の数字か、登録番号が「T」と13桁の半角数字かを確かめます。形が合わないものはAIに直させず、そのまま「形が合わない」とします
5. 免税事業者の扱い … 申請で免税事業者とされていれば、登録番号の書類と照会を飛ばし、その旨を一覧に残します
6. 口座番号の扱い … 口座番号はフローの照合にだけ使い、照合の結果の一覧と承認の詳細には下4桁だけを載せます

4番目は、AIの外で効きます。 桁の足りない番号は、Web-API に問い合わせる前に書き写しの誤りと分かります。書類を読む前に分かる誤りは、書類を読む前に止めます。

AIに処理させる

させるのは、添付ごとに書類の種類を見分け、決まった項目を書かれたとおりに写すことと、書かれていない項目と読めない項目を分けることです。

not_written と unreadable を分けるのが要です。 通帳の表紙しか写っておらず口座番号が無いのは not_written で、拠点の担当に見開きの写しを頼みます。写っているが影で読めないのは unreadable で、スキャンのやり直しを頼みます。頼む中身が違います。

2行目が、いちばん起きやすい失敗です。 口座名義の「ヨ」が影でかすれていると、AIは申請の値に引っ張られて「ヨ」と読みます。申請の値をプロンプトに入れないのは、このためです。 書類だけを見て写させ、申請との照合は後段に回します。

指示内容を固定する

あなたは製造業の購買部で、新しい取引先の登録の書類を確かめる立場です。
添付された1つの書類だけを見て、書かれていることをそのまま写してください。
推測で埋めないでください。

【書類の種類の見分け方】
- 次のどれかを document_type に入れてください。
  registry（登記事項証明書）／bank（通帳の写し・振込先の届出書）／
  invoice_notice（適格請求書発行事業者の登録の通知書）／other（それ以外）
- 見分けられなければ unknown にしてください。

【写す項目】
- registry：商号、本店、代表者の氏名、会社法人等番号、発行日、
  商号または本店の変更の記載（あれば変更前と変更日も）
- bank：銀行名、支店名、預金の種別、口座番号、口座名義のカナ
- invoice_notice：登録番号、氏名又は名称、登録年月日

【status の選び方】
- ok ........... 値が読み取れた
- not_written .. その項目が書類に無い（写っていない欄も含む）
- unreadable ... 欄はあるが、かすれ・影・解像度で文字が確定できない
迷ったときに ok を選ばないでください。

【厳守事項】
- 値は書類に書かれた文字のまま写してください。
  全角・半角、カタカナの大小、記号を直さないでください。
- 口座番号・登録番号・会社法人等番号の桁を補ったり、
  それらしい番号に直したりしないでください。
- 1文字でも確定できない文字がある場合は、その項目を unreadable にし、
  value には読めた部分だけを入れ、読めない文字を「?」にしてください。
- 日付は書類の表記のまま写し、和暦を西暦に直さないでください。
- 書類の内容が正しいか、取引をしてよいかを書かないでください。
- Don't include JSON markdown in your answer.

【書類】{document}

申請の値をプロンプトに入れていないのが、この指示のいちばんの工夫です。 申請の口座名義を渡して「書類と合っているか」と聞くと、かすれた1文字を申請の値で埋めて「一致」と返します。見比べる相手を知らなければ、寄せることもできません。

「読めない文字を『?』にする」を書くのは、unreadable の理由を担当が一目で分かるようにするためです。 「カ）ヤマダセイサクシ?」と返ってくれば、どの1文字を書類で確かめればよいかが分かります。

「和暦を西暦に直さない」は、日付の計算をフローに任せるための1行です。 変換はフローの側で表を使って行い、変換の誤りがAIの読み取りの誤りと混ざらないようにします。

最後の英文の1行は、公式の案内に合わせたものです。 JSON が作れないというエラーが出るとき、この一文を足すよう案内されています。

出力形式を固定する

次の形のJSONで受け取ります。 添付ごとに1回呼び、例を書き換えて Custom の形に固定します。

{
  "document_type": "registry | bank | invoice_notice | other | unknown",
  "fields": [
    { "name": "", "value": "", "status": "ok | not_written | unreadable" }
  ],
  "change_records": [
    { "item": "", "before": "", "changed_on": "" }
  ]
}

項目を name 付きの要素の配列にしているのは、公式の制約に合わせたものです。 JSON の形はキーの無い配列を定義できないとされているので、項目ごとに name を持たせます。

JSON にする理由の1つ目は、フローが項目ごとに照合できることです。 書類の値と申請の値と公表情報を、表記の置き換えの一覧をかけてから比べます。

2つ目は、ready ／ return ／ review を規則で決められることです。 全項目が一致か表記の揺れなら ready、不足・読めない・口座名義と口座番号の不一致があれば return、申請と書類は一致しているが公表情報の名称・所在地と違うもの、change_records に商号・本店の変更があるものは review にします。後者は書類が古いのか、申請が古い情報で書かれたのかを、人が見分ける必要があるからです。

3つ目は、差し戻しの文面を一度で書けることです。 return の項目を全部並べて下書きを作るので、第3章の（c）の二度の差し戻しが起きません。

システムへ連携する

承認の詳細欄には、照合の一覧を表で載せます。 承認の詳細は Markdown で書けるとされているので、項目・申請の値・書類の値・公表情報・結果の5列の表にし、不一致と不足の行を上に並べます。 口座番号は下4桁だけにします。

承認のメールについて、2つの制約に注意します。 公式の説明では、承認の詳細にはフローの作成者が常に表示され、 承認のメールは標準のメールアカウントから送られるとされています。購買部の共用アカウントでフローを作り、担当者個人の名前が出ないようにします。

取引先マスタには書き込みません。 登録は経理部の担当が基幹システムの画面で行います。照合の結果を信じてそのままマスタに流す経路を作ると、照合の見落としが支払の誤りまで一息に進みます。

国税庁の Web-API の利用規約に注意します。 Web-API を使ったサービスを公開する場合は、国税庁が保証したものではない旨の文を示すよう求められています。社内だけで使う照合ですが、承認の詳細欄の末尾にこの文を載せておくと、扱いを迷いません。

人が確認する

人が見るのは、次の3つの場面です。

1. 本社の購買部の担当の承認（全件） … 一覧の不一致・不足・review の行と、その根拠の書類の箇所を見て、差し戻すか経理部へ回すかを選びます。 表記の揺れの行は流し見ます
2. review の申請 … 公表情報との違いや商号の変更の記載がある申請で、書類が古いのか申請が古いのかを、書類の発行日と公表情報を見て決めます
3. 経理部の担当のマスタ登録 … 確認済みの一覧を見ながら登録します。口座名義は、一覧ではなく書類の写しを見て入力します

3番目で書類の写しを見て入力するのは、一覧の値を写すと照合の意味が消えるからです。 一覧はフローが表記をそろえた後の値を含みます。マスタには、取引先が書類に書いた形で入れます。

目標は、40件をならして1件15分です。 全項目がそろった申請は一覧を流し見て数分、review の申請は書類と公表情報を見比べるので30分ほどかかります。15分を大きく超える月は、表記の置き換えの一覧が足りず、表記の揺れが不一致に落ちています。

例外に対処する

下から2行目を return にしないのは、理由がいくつもあるからです。 番号の写し間違い、登録の申請中、すでに失効している、のどれかで、どれかによって取引先へ伝える中身が変わります。 人が見てから差し戻します。

記録を残す

• 申請の項目と添付のファイル名、照合を始めた時刻
• 添付ごとにAIが返したJSONの全文
• Web-API への問い合わせの条件（番号と日付）と、返ってきた公表情報
• 項目ごとの照合の結果と、表記の置き換えの一覧のどの規則をかけたか
• 承認の結果と承認者、差し戻しの文面
• 差し戻しから出し直しまでの回数と、直った項目

3つ目で問い合わせの条件を残すのは、公表情報が変わるからです。 登録番号は後から失効することがあり、照合したときに有効だったかを後から示せるように、日付とともに残します。

4つ目は、表記の置き換えの一覧を育てる材料です。 担当が「これは表記の揺れ」と判断した不一致を集めると、置き換えの規則に足すべきものが分かります。