Claude Codeで経費・申請書類を突合する｜手元の表を直接触る経理・総務の手順
「経費明細の空欄に、利用目的と同席者を追記してもらえませんか」
経理・総務では、一定の時期になると繰り返し発生する業務があります。確認対象の表に載っているのは、利用日、店舗名、支払額といった最低限の情報だけ。証憑を眺めても、誰と利用したか、どの業務に関係する支出かまでは分かりません。不足している情報を周辺の記録から探し出し、元の一覧へ補うこと。それが突合の実務です。
AIを使おうとすると、表の内容を会話欄へ貼り、空欄を補ってもらう方法をまず思いつくでしょう。検索上位の解説にも、この使い方を前提とするものが多く見られます。本稿を書く前にそれらを確認したところ、指示文の例や抽出対象、回答フォーマットは詳しく説明されていても、得られた回答を元ファイルの正しい位置へ反映する工程には、ほとんど触れられていませんでした。会計事務所を対象にした詳細な解説の中には、表計算から別形式へ移して処理する方法を勧めるものもありました。
けれども、経理や総務の手元で日常的に使われているのは、何年も引き継がれてきた既存の表であることが少なくありません。独自の列順、社内の記入規則、担当者が途中まで入力した内容も、そのファイルに蓄積されています。別の仕組みへ全面移行するとなれば、単なる照合作業を超えた大規模な取り組みになります。
そこで本稿では、既存の表を維持したまま照合を進める方法を順序立てて紹介します。題材は、当社で行っている、領収書一覧と予定表の情報を照らし合わせる実務です。順調に処理できた例に限らず、更新を丸ごと止めたケースや、候補の見立てを誤ったケースも取り上げます。突合では、目立つ失敗よりも、正しく見える誤りのほうが深刻な結果を招くためです。
この記事が説明するのは実務の進め方であり、会計処理や税務判断に関する助言ではありません。費用として認められるか、どの勘定科目を選ぶか、証憑として有効かといった判断は、顧問税理士・会計士へ必ずご相談ください。ここで対象とするのは結論を出す行為ではなく、結論に必要な情報を集める過程です。なお、自社の事例は現場で生じた出来事を基にしていますが、取引先や関係者が分かる情報、ならびに金額は掲載していません。また、他社記事に掲載された手順や数値を転載したものではありません。
この記事から理解できること
突合は「答えさせる仕事」ではない
まず見直したいのは、作業に対する捉え方です。突合でAIへ渡す役割は、正解を考案することではありません。複数の資料を見比べ、同じ出来事を示す記録同士を結び付けることです。
両者の差は、完成物を見れば明確です。「この支出の用途を教えて」と尋ねて得た説明には、自然な文章であっても裏付けが存在しません。それに対し、「この日のこの店舗での決済には、予定表上のこの記録が対応する」と示せば、対応の根拠を後からたどり、再確認できます。
経理資料は、税務確認の際に証拠として扱われます。憶測を確定事項のように記録すれば、後工程で容易には修正できません。そのため当社では、「業務上の目的を創作しない」を照合ルールの最上位に置いています。予定表から私用の行動しか確認できない日に、仕事相手との会食だったと決めつけるべきではありません。残す対象は記録から読み取れる事実であり、その支出を経費にできるかどうかは人が判断します。
この境界を先に引くことで、役割分担も迷わず設計できます。AIが受け持つのは、膨大な資料から関連候補を拾い、それぞれの関係を整理する部分です。人が続けると時間がかかり、集中力の低下で見落としやすい工程を支援させ、最終判断は人の側に残します。
突合には2種類ある
続いて、照合作業を2つの型に切り分けます。必要な考え方と難易度が大きく異なるため、ひとまとめの進め方では安全を保てません。
ひとつは、共通の照合キーを持つケースです。たとえば伝票番号、請求書番号、取引先コードなど、双方の資料に同じ識別情報が記録されています。対応先はそのキーで一意に決められます。検討が必要になるのは、キーは同じなのに金額が一致しない場合です。表記差、端数処理、入金日と計上日のずれなど、その理由を調べることになります。
キーが用意されているなら、AIに結論を考えさせる場面ではありません。定型処理で照合し、不一致だけを抽出すれば十分です。AIは、その定型処理を組み立てたり、差異が生まれた理由の候補を整理したりする用途に向いています。件数や数値の計算は、再現可能な処理へ任せます。
もうひとつは、両資料をつなぐキーが存在しないケースです。領収書に利用目的や相手の記載がない、申請書に案件名が欠けているといった状況が該当します。直接結び付ける情報がないので、日時、場所、支出規模などの周辺情報を手掛かりに、対応しそうな別記録を探索する必要があります。
難所は後者であり、判断材料に推量が入り得るのもこの型だけです。前者は定型処理を一度整えれば大部分を処理できるため、以下では主にキーのない照合を扱います。
着手前に確認することは難しくありません。対象業務が2つのどちらに属するかを判定します。共通キーがあるのに担当者が目で見比べているなら、AI活用を考える前に定型化すべきです。以降の方法を適用するのは、共通キーを持たない業務に限ります。
手元の表を直接触ると何が変わるか
会話へ貼ったデータから回答を受け取るやり方と、既存ファイルを直接更新するやり方には、主に4つの相違があります。
最初の違いは、転記工程をなくせる点です。対象が数十行なら手で戻すこともできます。しかし数百行に増えると、回答を元の表へ移すだけで主要業務になるでしょう。転記位置を誤れば、以降の全データが1行ずつずれた状態で記録されるという重大事故にもつながります。
次に、すでに入力済みの情報を温存できます。運用中の表には、担当者が途中まで記載したセルが混在します。表全体を置き換える更新では、その内容まで失われかねません。元ファイルへ条件付きで書く方法なら、値のない箇所のみを対象にできます。
さらに、セルの書式を情報として利用できます。候補ごとの信頼度を文字色で表せるからです。会話で受け取るプレーンな文章には、その違いを表の状態として残せません。
最後に、大量の参照資料を処理しやすくなります。1年分の記録には、数百件から千件を超える予定が含まれることがあります。その全量を会話欄へ貼る運用は現実的ではありません。当社では、約600件の会議情報を単一の集計表へまとめる仕事にも同じ考えを採用しています。資料はファイルとして保持し、AIにそのファイルを参照させるほうが、容量と精度の両面で扱いやすくなります。
もちろん、直接更新には固有のリスクがあります。変更内容を簡単に取り消せないことがあるためです。このリスクを抑えるには、後で説明する更新前の確認が欠かせません。復元できる状態を用意する方法については、業務ファイルのバージョン管理の記事で解説しています。
突合の手順は5段でできている
当社の照合工程を5つに整理します。この並び順にも理由があるため、前後を入れ替えずに進めます。
第1段：更新対象となる表の構造を把握する。空欄の列と、すでに値が入っている行を作業前に記録します。その記録が、変更を禁止するセルの基準になります。同時に数式の有無も調べます。数式セルを一括更新の対象に含めると、表全体の計算機能を損なう恐れがあります。
第2段：参照記録を、欠落が起きない大きさで取得する。ここで資料が抜ければ、その後を正確に進めても成果は成立しません。具体的な注意点は次節で説明します。
第3段：記録同士を結び付け、入力候補をまとめる。AIが中心的に働く工程です。ただし、候補ができても即座には表を更新しません。全行の案をいったん別ファイルへ出し、人が一覧できる状態にします。当社の運用では、候補一覧に「本人の確認が要る点」を添えた資料を作成し、承認前の確認工程を必ず設けています。
第4段：反映の直前に対象範囲を再取得する。手間に見えて省かれやすい一方、事故を防ぐうえで重要な工程です。後ほど事例とともに詳しく取り上げます。
第5段：反映後の表を別ルートから取得し、内容を照合する。更新処理の完了は、期待どおりの更新を保証するものではありません。
5工程の中で、自動化の対象にできるのは第2段と第3段です。第1段には表と業務への理解が、第4段には安全装置としての独立性が、第5段には検算としての客観性が求められます。そのため当社では、この3工程を自動化から切り離しています。
材料の集め方で、静かに失敗する
5段階のうち、特に警戒すべきなのが第2段です。不完全でも処理自体は正常終了してしまうからです。
当社では、年間の予定表データを照合材料にしています。当初は月単位でまとめて取得していました。しかし、1度に受け取れる件数には上限があり、上限を超過しても残りのデータは返らず、続きの存在を表す印だけが示されます。その結果、月後半の予定が欠けた資料を、全件取得できたものとして扱ってしまいました。
問題は、その後の見え方です。一部が欠けた資料と照合しても、出力上は単に「候補なし」となります。処理エラーにはならず、「関連する予定を確認できない」という内容が各行に記録されます。担当者の目には、最後まで問題なく終わった処理のように映ります。
似た失敗は、当社の別業務でも生じています。稼働中だと思っていた自動処理が停止していたこと、通知元を通知先へ参加させておらず障害通知そのものが届かなかったこと、接続先のセキュリティ設定で通信が遮断され完了していなかったことです。いずれも、表面上は成功したように見えた点が共通しています。
経験を整理すると、照合が気づかれないまま誤る経路は5つあります。参照資料の欠落、作業中の同時更新、高額行を根拠の薄い推量で埋めること、AIへ合計計算を委ねること、完成ファイルを開かずに引き渡すことです。以下では、これらを防ぐ方策を順に説明します。
まず資料欠落を防ぐ方法は、2つあります。
ひとつは、1回当たりの取得期間を短くすることです。当社では月ごとの取得を改め、半月ごとに分割しました。実際に取得して上限へ達しないことを確かめ、適切な単位を決めます。
もうひとつは、取得件数の確認を必須にすることです。取り込めた記録数を算出し、想定する規模と大きく違わないかを調べます。件数の算出にはAIを用いません。同じ入力から同じ結果が得られる定型処理で数えます。数字の集計を定型処理へ分離することは誤計算の防止だけでなく、この場面では取得データが十分かを確かめる照合にもなります。
取得後は、比較に向いた形式へ整えます。日付、時刻、予定名、場所、同席者を1レコードに集約し、重複を取り除いて日付順にします。この前処理にも、再現可能な定型処理を使います。総件数が把握しやすくなり、対象日だけを抜き出す操作も容易になります。
確からしさを色で残す
当社の運用で特徴となるのが、記入候補の根拠の強さを文字色で可視化する方法です。
- 赤は、ほかの資料で確認できた内容。対応する記録が存在し、情報が合致する場合に限って使用します
- 青は、手掛かりに基づく入力候補。確定前に本人の確認を要する案であることを表します
- 黒は、作業開始前から入っていた内容。担当者による既存入力として変更対象から除外します
3色へ分けるのは、後から確認する人が、見るべき箇所をすぐに判別できるようにするためです。同じ色ですべてのセルが埋まっていると、記録に裏付けられた内容と推量による候補を区別できません。そうなると、全項目を再調査するか、根拠を問わず受け入れるかしか選べず、どちらも望ましい運用ではありません。
赤を付けられる要件は、作業に入る前に明文化します。当社では、次の条件を採用しています。
- 予約情報など、予定名の中で対象店舗を直接確認できる
- 同じ日付に、会食であることが分かる予定が登録されている
- 証明書の取得と発行手数料のように、用件と支出内容が整合する
- 移動、宿泊、会食など、同日の出張に関する一連の記録が確認できる
条件を満たさない候補は、例外なく青にします。青いセルには、候補を導いた根拠も併記します。例としては、「同日の予定に載る人物を参照」「支出規模から人数を推量」「同一店舗の別明細を参考」といった表現です。材料が存在しない場合には、「判断材料なし」と明確に残します。空欄をなくすために推量を積み重ねることこそ、避けるべき行為です。
店舗の所在地を補う際も、同様に扱います。名称に地名が含まれない店でも、調査によって場所が判明する場合があります。一方、複数地域に展開するチェーンでは店舗を絞れません。その場合は当日の移動記録から候補地を挙げながら、「店舗は確定できない」と書きます。つまり、確定していない事実そのものを成果物に明示するわけです。
根拠の強さを成果物へ埋め込む考え方は、経費照合以外にも応用できます。当社が他業務でも用いている基準については、出力をどこまで信じるかの記事をご覧ください。
書き込む直前に全件中止した日のこと
ここで、当社の現場で実際に生じた事例を紹介します。
あるとき、作成済みの候補を経費一覧へ反映しようとしたところ、事前チェックが異常を検知し、すべての更新を停止しました。結果として、対象表には一切変更を加えませんでした。
確認すると、候補を準備している間に本人が同じファイルを開き、十数行へ直接追記していたことが原因でした。準備時点では空欄だった対象セルに、新しい情報が追加されていたのです。
これは処理の失敗ではなく、安全機構が意図どおり働いた結果です。もし直前確認がなければ、本人の入力をこちらの案で置き換えていました。さらに、内容が自然であるほど上書きの発生には気づきにくくなります。誤った候補がそのまま正式な記録として残った可能性もあります。
安全チェックの仕組みは複雑ではありません。更新する直前に、対象セルを改めてすべて取得します。準備時に記録した状態と異なるセルがひとつでも見つかった時点で、処理全体を実行しません。一致したセルだけを書いて残りを除外する方式は採りません。中途半端に反映された表は、どこまで正しいのかを把握しづらいためです。
更新の目的に応じて、停止条件を次のように変えます。
- 新規入力の場合：空欄だけを対象とし、値が入ったセルをひとつでも検知したら処理を止める
- 訂正を行う場合：事前に想定した値と色を持つセルに限って変更し、差異があれば実行しない
なお、停止記録に表示される「事前状態と違ったセル」の値は、本人が加えた最新情報です。当社では、その記録を確認して新しい入力内容を候補へ取り込み、案全体を作り直します。処理停止はトラブルではなく、再準備へ移るための通知として扱います。
「差異がひとつでもあれば全体を止める」という原則は、照合作業以外にも役立ちます。簡単に元へ戻せない操作を伴う業務には、広く導入する価値があります。安全を前提にした工程設計は、事故を起こさない業務設計の記事で詳しく説明しています。
推定は普通に外れる
もうひとつ前提として共有したいのは、どれほど注意しても推量が誤ることはあるという事実です。
当社で経費を照合した際にも、ある明細について、当日の予定から用途を推し量り、入力案を示したことがありました。しかし実際の用途は異なり、数か月前の別日に行われたものと同じ相手、同じ目的の支出でした。しかも、その明細は支出額の大きなものだったのです。
この経験から定めた原則は明快です。高額な明細ほど、候補で確定せず本人へ直接確認する。
支出額が大きくても小さくても、候補選びを誤る可能性そのものは変わりません。一方で、誤った際に生じる影響は、金額が増えるほど大きくなります。したがって、確認に使える時間を高額な項目へ重点的に配分することには合理性があります。
実際の運用では、以下のように扱っています。
- 社内で決めた金額基準を上回る明細は青い候補として残し、本人の確認を必須にする
- 少額で件数が多い明細は根拠別に色分けし、一括して内容を確認してもらう
- 予定に記された店舗と証憑上の店舗が一致しない明細は、例外なく差異を伝える
店舗名の不一致も、現場で経験したケースです。予約先から別の店へ変更することは、実務上よくあります。同一の会食として整理できることは多いものの、2つの記録が食い違う点は省略せず報告します。同じ用件かどうかの確定は、人が行うべきだからです。
また、私用の行動と同日であっても、業務目的を補ってはいけません。同席者が仕事上の関係者ではない、あるいは私的な予定が登録されているときは、確認できた記録だけを残し、経費としての扱いを本人に尋ねます。もっともらしく整えるために「取引関係者との会食」と記すことは、決して許容できません。
書き込みの経路は、権限で決まる
次は、実際の反映手段についてです。既存の表を更新できるかどうかは、接続時に与えた権限によって決まります。
当社が表計算サービスへ接続する際は、参照だけが可能な権限に限定しています。これは意図的な安全設計であり、接続機能からデータを書き換えることはできません。
その状態で数十個を超えるセルへ反映する必要が生じたため、次の方法を比較しました。
- 画面上で1件ずつ入力する：対象が数セルなら使えますが、数十セルの入力と色設定を手作業で行うには時間がかかります
- 対象表に関連付けたスクリプトでまとめて反映する：当社はこちらを採用しました
スクリプトを組む際には、実務上押さえておきたい点があります。
データの取得と反映は、セル単位ではなく範囲単位で各1回にまとめます。1セルごとに通信すると、処理時間が大幅に延びるためです。値をまとめて読む、色をまとめて読む、更新条件を評価する、値をまとめて書く、色をまとめて設定する、という流れにします。
更新結果を確認する集計も、同一処理の末尾へ組み込みます。こうするようになったのには理由があります。実行画面で処理名を選択する欄が自動操作では切り替わらず、実行対象として選んだはずの処理ではなく、直前に選ばれていた別処理が動くことがありました。それ以降は、1ファイルに置く処理を1つに限定し、検証用集計まで同じ流れの中で実施しています。
コードを画面へ入れる際には、既存内容をすべて選んだうえで貼り付けます。末尾へカーソルを移したつもりでも適切な位置へ移動せず、既存コードの途中に新しい内容が入り、動作しなくなった経験があるためです。小さな操作上の問題ですが、原因究明に長い時間を取られます。同様の注意点は、業務システムの自動化で詰まる所の記事にもまとめています。
書いた後の検証を、別の経路でやる
ここまで進んだら第5段です。処理が書き込みに成功したことと、内容が意図どおりであることを分けて考えます。
当社では、異なる2つの観点から更新結果を確かめています。
第1は、入力値そのものの検査です。反映に利用した手段とは別の方法で対象表を再読込し、予定したセルへ予定した文字列が記録されているかを突き合わせます。更新処理から成功の応答を受けても、分かるのは処理が終了したことだけであり、データの正しさまでは保証されません。
第2は、文字色の件数確認です。ただし、ここには技術上の制限があります。参照用の接続方法では、文字色を読み出せません。そのため更新スクリプトの最後で色別に数え、赤、青、その他の件数を内訳として出力します。
出力された色別件数を、更新前の想定値と比較します。一致しなければ、いずれかの条件判定や反映に問題があります。全セルを目で追う代わりに件数を照合すれば、短時間で確認でき、見落としも抑えられます。
もうひとつ、作業用の仮文字列が残存していないかも調べます。候補作成中に付けた印や説明用の接頭語が、完成表へ混入する場合があるためです。これは特定文字列の有無を調べる定型処理で検出します。
当社では、作成物を実際に開いて確認する工程を、原則として必須にしています。この決まりは、確認を省いて問題が起きた経験から生まれました。
表計算ファイルを渡すときの落とし穴
照合結果を表計算ファイルで納品するときも、ファイル生成の成功と、受取人が期待どおり閲覧できることは同義ではありません。当社で連続して発生した2つの事例を紹介します。
ひとつは、数式の計算結果が表示されない問題です。プログラムで表計算ファイルを生成すると、セルへ数式自体を設定することは可能です。ところが、計算後の値までファイルへ保持されるとは限りません。簡易ビューアーでは該当セルが空白に見え、表計算ソフトで開いたときに初めて計算されることがあります。受取人にとっては、内容の欠けたファイルが届いたように見えてしまいます。
もうひとつは、結合と入力を行う順番の問題です。先にセルを結合すると、その範囲へ期待どおり書き込めないことがあります。正しい流れは、値を入力した後に対象セルを結合することです。順序を逆にすれば、結合範囲の値が消える場合があります。それでもファイル自体は作成されるため、生成処理にはエラーが現れません。
どちらの不具合も、完成したファイルをその場で開けば引き渡し前に発見できます。反対に確認を省けば、相手が開いた時点で初めて問題が分かります。当社では2度の経験を受け、納品物は共有前に必ず開き、表示内容まで点検することを標準手順にしました。
数式を含む資料を共有するなら、簡易表示では空欄になることがあり、表計算ソフトで開くと算出される旨を伝えるか、計算済みの値を収めたファイルも同時に用意すると親切です。経理資料は別担当者へ転送される可能性があります。転送先に注意事項が届かなければ、後から確認依頼が戻ってきます。
任せてよい突合・任せてはいけない突合
これまでの工程を前提に、AIへ委ねられる範囲を整理します。
任せられるのは、次の3条件をすべて備えた作業です。
- 別手段で検証可能である：出力が正しいかを独立した方法で確かめられる
- 誤りを元に戻せる：反映先が下書きであり、問題があれば復元できる
- 途中停止できる：異変を見つけた段階で、それ以上の進行を止められる
一方、次に挙げる操作は任せるべきではありません。
- 主要な会計システムへ直接反映すること：変更が他帳票にも及び、容易に取り消せないためです
- 金額を確定・変更すること：照合結果を基に金額を修正する行為は、単純作業ではなく判断に当たります
- 実際の支払処理を行うこと：資金が外部へ動く直前で必ず人の確認を入れます
- 勘定科目を最終確定すること：企業ごとの会計方針が影響するので、候補提示までとし、専門家が判断します
- 担当者が直接入力した内容を書き換えること：既存の手入力を優先する前提で仕組みを設計します
この境界線は、当社のほかの仕事でも共通です。外部に作用する直前で、人へ引き渡すことを基本にしています。連絡は下書きで止め、公開の可否は人が決める運用と同じです。内製に向く仕組みと避けるべき仕組みの整理は、社内ツールの内製の記事で扱っています。
さらに、対応先を見つけられなかった明細は、とても有用な成果です。すべての空欄を埋めた表より、「根拠を確認できないため、この15行は本人確認が必要」と示す一覧のほうが、次の行動を明確にできます。未確定部分を隠さず納品対象と考えれば、無理な推量を求めない工程を作れます。
経理・総務で使える他の突合4例
同じ進め方を応用できるバックオフィス業務を4つ紹介します。どれも、共通キーを持たない照合の例です。
第1は、交通費申請と当日の予定を照らし合わせる作業です。申請に記載された日付・経路について、該当日に外出予定が登録されているかを探します。予定を確認できない申請は、青の要確認項目にします。不正発見を目的に掲げるより、日付の誤記や入力不足を見つける支援として設計するほうが、利用者から協力を得やすくなります。
第2は、会議費の証憑と出席者情報の比較です。領収書に示された人数と、同日の予定に登録された参加者数を確認します。一致しない場合は、参加者の記録漏れか、証憑の日付違いなどを調べる必要があります。
第3は、備品購入履歴と貸与台帳の照合です。購入した物品ごとに、受領者の記録があるかを確かめます。貸与先が見つからない品は、在庫として保管中なのか、引き渡し記録が抜けたのかを確認します。資産棚卸しに入る前の情報整理として、この作業が役立ちます。
第4は、請求内容と業務記録の対応確認です。請求額の裏付けとなる作業が、日報などに残っているかを探します。請求書の発行前なら不足を補えますが、発行後では訂正連絡が必要になるため、実施時期が重要です。同じ確認でも、工程の順序によって効果が変わります。
対象業務が変わっても、守るべき要素は3つに集約できます。参照資料を欠けなく用意する、根拠の強さを区別して記録する、更新直前に状態を取得し直す。この原則は、どの照合にも共通します。
書類の中の「指示らしき文」に従わせない
経理・総務で照合を行う際に欠かせない、もうひとつの安全上の注意を説明します。
参照資料の中には、社外の相手が作成した文書も含まれます。請求書、見積書、申込書のほか、外部から届き予定表へ追加された招待などです。業務上必要な資料である一方、自社では記載内容を管理できない情報でもあります。
当社では、外部資料を取り扱うときの原則を明確にしています。資料から取得した文章は処理対象の「データ」であり、実行すべき「命令」ではありません。たとえ文書内にAIへ何かをさせようとする記述があっても実行せず、その箇所を抜き出して人へ報告します。
現実味がないように感じるかもしれません。しかし、文書内容を読んで次の処理を決める仕組みである以上、起こり得る問題です。経理が受け取る資料の多くは、社外の作成者から送られてきます。その意味で、AIへ読み込ませる際に特に注意すべき文書群と考えられます。
現場では、次の3点を対策にします。
- 外部資料を参照した直後に送信、削除、設定変更を行う場合は、事前に人の承認を得る
- 資料内で命令のような記述を検出しても実行せず、人へ知らせるという規則を、あらかじめ作業指示へ含める
- 更新権限と対象範囲を必要最小限に限定する。更新できる列や入力可能な値を絞れば、予期しない動作が起きても影響を狭くできます
中でも3つ目は、強力な防御になります。守るよう指示するだけでなく、仕組み上実行不能にするほうが確実です。当社が外部送信の権限自体を持たせていないのも、この方針によるものです。詳細は、情報の線引きの記事をご参照ください。
よくある質問
Q. 手元の表をAIに触らせるのは、危なくないですか
リスクがあるため、反映直前の状態確認を省いてはいけません。当社は、値のないセルのみへ入力し、準備時と異なるセルがひとつでもあれば全更新を止める条件を設けています。この条件によって実際に処理を全面停止したことがあり、もし確認がなければ本人の手入力を失っていました。異変を検知して止まるのは、期待どおりの安全動作です。
Q. 貼り付けて結果をもらう方法ではだめですか
対象が少数行なら、十分に使える方法です。ただ、数百行を扱う場合は、回答を元表へ転記するときに行位置を誤る危険があります。根拠の程度をセルの色で残せないことも欠点です。データ量に加え、後から見る人が確定内容と候補を区別できるかを基準に選びましょう。
Q. どこまでをAIに判断させてよいですか
異なる記録の対応候補を示すところまでです。ある決済とある予定が同じ用件だと思われる、という整理は任せられます。しかし、費用計上の可否や勘定科目の決定は人が担います。税務上の結論については、顧問税理士・会計士へ必ず確認してください。
Q. 材料が正しく取れているか、どう確かめますか
取得できた記録数を算出し、想定件数と比較します。取得上限を超えた分が明確なエラーなしに欠落すると、照合上は候補が存在しないように見えるためです。当社では取得期間を1か月から半月へ縮め、定型処理による件数確認を必須にしています。
Q. 金額の合計もAIに計算させてよいですか
合計計算には使用しないでください。数値集計は再現可能な定型処理へ分け、AIには記録の対応づけと説明文の作成を担当させるのが当社の運用です。計算精度を守れるだけでなく、大量の明細をAIへ渡す必要も減らせます。
Q. 作った表を、そのまま税理士に渡してよいですか
共有時には、各文字色が示す意味を説明してください。赤は別資料で確認済み、青は確認待ちの案、黒は従来からの入力であると伝えれば、税理士は確認対象を絞れます。色を保持できない形式で共有するなら、要確認行だけをまとめた別紙も添えてください。
まとめ
ここまでの重要点を整理します。
- 突合の目的は答えを創作することではなく、資料同士の関係を整理することです。AIは対応候補を示し、結論は人が出します
- 照合作業は2つの型に分かれます。共通キーがあれば定型処理を用い、キーのない場合に本稿の工程を適用します
- 安全な流れは5段階です。表の把握、資料収集、候補作成、反映前の再確認、反映後の検証という順に進めます
- 資料が欠けても、結果には単なる候補なしと表示される場合があります。取得範囲を細分化し、総件数を必ず確かめます
- 根拠の程度を文字色で示します。確認済み、要確認の案、既存入力を分けることで、人が見る範囲を限定できます
- 反映直前に対象を再取得し、事前状態との差異がひとつでもあれば処理全体を止めます。この機能によって、当社でも本人の追加入力を保護できました
- 推量には誤りが起こります。影響の大きい高額明細は、候補だけで済ませず本人へ確認します
- 成果物は共有前に実際に開きます。数式結果が見えない問題や、セル結合の順序による値の消失は、表示確認で発見できます
- 対応を確定できない明細も重要な成果です。無理に全欄を埋めず、追加確認が必要な項目として明示します
突合で最も警戒すべきなのは、誤りそのものではなく、誤りを正しい結果だと思ったまま次へ進むことです。参照資料が欠けたときも、推量が外れたときも、既存入力を上書きしたときも、画面上では正常に見える可能性があります。そこで、根拠の程度を表へ残す、反映前に状態を再確認する、反映後に件数を照合するという3つの防波堤を設けます。これらがあれば、突合を安全に委ねられる業務へ変えられます。
当社では、技術職以外の部門も対象として、Claude Codeの導入支援・研修を提供しています。経理・総務で現在使っている表を維持しながら、事故を防いで照合できる工程づくりから、個別の業務に即して支援します。最初のご相談に費用はかかりません。
