バックオフィス 2026年8月25日公開

経理の月次をAIで軽くする｜請求書・経費・入金の突合をClaude Codeで「手元の表のまま」回す

「AIで請求書を照合したいのですが、どのツールから入れればいいですか」

経理の現場から寄せられる相談は、しばしばこの問いから始まります。しかし業務の状況を掘り下げると、必要なのは新製品の選定ではないケースが大半です。解消したい本当の負担は、月末ごとに繰り返す照合そのものにあります。

現場には、照合に使う資料がすでに一通り存在します。会計ソフトから書き出した補助元帳、取引先が送ってきたPDF請求書、経費申請をまとめた一覧、インターネットバンキングで取得した入出金データです。多くの会社では、これらがExcel、Googleスプレッドシート、PDFのいずれかとしてフォルダに保存されています。複数の資料を見比べ、一致するものと確認が必要なものに分けるのが突合です。

一方、「経理 AI 効率化」と調べて目に入るのは、新規システムを勧める情報が中心です。読み終えても、現在使っている表をどう処理するかは分からないままです。必要なデータは揃っているのに、それを今の形式で利用する道筋が見当たらないという隔たりがあります。

そこで本記事では、新たなSaaSを契約せず、既存のExcel・スプレッドシート・フォルダを使い続けながら突合する方法を説明します。利用するのはClaude Codeです。さらに、照合作業で重大な事故につながる「締め後の確定データを変えない」という課題について、当社が経費一覧を処理してきた実例をもとに具体策を示します。

製品の挙動については Claude Code公式のセキュリティ資料を参照し、2026年8月25日時点で確認した情報を掲載しています。スクリプトに関する制限値は、同日に確認した Google Apps Script の公式「割り当てと制限」を根拠としています。仕様や上限、設定項目は今後変わる可能性があるため、実際に設定する際は公式ページで最新情報を必ずお確かめください。第三者サイトだけに掲載された数値は使用していません。自社の事例についても、取引先が分かる名称や具体的な金額を伏せ、工程のみを紹介しています。なお、本記事は会計・税務上の助言を目的としたものではありません。個別処理が適切かどうかは顧問税理士へご相談ください。

この記事から分かること

月次業務の負担は入力よりも照合にある
一般的な検索結果と現場の課題がずれる背景
既存ファイルを直接扱える利点
照合作業を分ける2つの型
共通キーがある照合で数値計算を委ねない理由
共通キーのない照合で生きる強み
最大の難所となる確定値の保護
処理を全件取りやめた実例
情報の確度を色で見える化する方法
表計算ならではの注意点
資料不足が「該当なし」に見える問題
月次照合を進める6段階
推定には誤りがあるという出発点
人の判断を残すべき5領域
不一致データが重要な成果になる理由
導入時の30分で確かめる内容
よく寄せられる質問と答え
押さえておきたい結論

月次で時間を奪っているのは入力ではなく照合

経理の省力化では、仕訳入力や領収書のデータ変換が注目されがちです。この分野にはすでに多様なサービスがあり、OCRで文字を読み取り、仕訳候補まで自動作成する機能も広く利用されています。

ところが、月次決算を担当する人に時間のかかる工程を聞くと、別の答えが返ってきます。多くの担当者が負担として挙げるのは、入力よりも資料同士の照合です。たとえば、以下の業務が該当します。

受領した請求額を、自社側の発注・納品データと照らして差異を調べる
入金データの各明細がどの請求分なのかを割り当てる（入金消込）
申請された経費が社内ルールの条件から外れていないか確認する
カード利用明細ごとに、利用者と用途を特定して情報を追記する
前月比で大きな増減が生じた科目について、その背景を説明できるようにする

どの作業も、単独の表だけでは完了しません。複数の資料を横断して対応を見つけ、結びつかなかった項目を切り出す必要があります。入力に比べて自動化が遅れてきたのは、この対応関係を作る工程が、元資料の形式に左右されやすいためです。

しかも、資料の作りは企業ごとに異なります。PDF請求書は発行元ごとに配置が違い、入金データの列名も金融機関によって統一されていません。自社で設計した経費表とまったく同じ様式は、他社にはないでしょう。こうした固有フォーマットへの適応が、汎用製品では解きにくい部分として残っています。

検索して出てくる解決策が自社に当てはまらない理由

本稿の準備として、経理分野におけるAI利用の記事を検索し、上位の内容を確認しました。すると、提示される情報は明確に3種類へ分けられました。

第1の種類は、大手会計クラウド事業者やコンサルティング会社が示す全体論です。AI導入後の経理像を描き、業務の全体像と企業事例を解説します。約8,000字の中で7つの変化と3社の事例を扱う記事もありましたが、照合に関する説明は発注書との照合や仕訳生成に触れる程度で、具体的な実施手順までは示されていませんでした。

第2の種類は、自社サービスの利用につなげるSaaS事業者の記事です。入金消込や請求書照合に特化したサービスを紹介するため、情報には正確さがあります。ただ、最終的な解決方法は専用製品の採用になります。

第3の種類は、プロンプト例や利用案を列挙したコンテンツです。調査結果を盛り込み、11種類の活用法を紹介する充実した記事も見つかりました。一方で、突合をどのように進めるかという詳細は扱わないと明記されていました。

実装に近いところまで説明した記事も1件ありました。三点突合を4つの段階で整理し、月間件数に応じて表計算、スクリプト、専用製品を選ぶ基準も示しています。それでも、月次締めを終えたデータの保全方法や、照合から漏れた行をどう処理するかについては、十分な具体策がありませんでした。

さらに、3種類には同じ前提があります。どれも対話型AIの入力欄へデータを貼り付ける使い方を想定している点です。この形では、元の表を開いて直接処理する選択肢が生まれません。入力できるデータ量に制約があるうえ、回答内容を表へ転記する人手も残ってしまいます。

手元の表をそのまま扱えるという性質

Claude Codeを経理で活用しやすい最大の理由は、作業フォルダに置かれたファイルを直接読み込み、必要な場合はそのファイルへ変更を加えられることです。内容をチャットへ貼る作業も、回答を元ファイルへ転記する作業も不要になります。

もっとも、ファイルへ直接働きかけられる以上、運用を誤ればリスクになります。利用前に初期状態の権限を把握することが重要です。公式の説明では、初期設定は厳格な読み取り専用になっています。編集、テスト、コマンドなど追加操作を行う段階で、利用者の明確な許可を求める仕組みです。その操作だけを認めるか、以後も許可するかはユーザー側で選択できます（2026年8月25日確認）。

作業できる場所の境界も確認が必要です。公式資料によれば、書き込みが認められるのは起動したフォルダと配下のフォルダに限られ、明示的に許可しない限り、その上位階層にあるファイルは変更できません。なお、読み取りは承認後であれば境界外にも及ぶとされています。

共通の照合キーがある場合とない場合を並べて比較した図

これらの条件を踏まえると、経理での基本的な配置が見えてきます。月次処理専用のフォルダを用意し、その場所を起点に作業を始めます。会計システム側の原データや共有ドライブで管理する原本は、変更可能な範囲に含めません。作業境界の設計例は、権限設定を具体的に解説した記事でも紹介しています。

突合は2種類に分かれる

照合を始める前に、必ず分類しておきたい点が1つあります。2つの資料を結びつける共通の鍵が存在するかどうかです。この区別をしないまま依頼すると、効果の見込める処理と、不必要な推測を伴う処理が一緒になります。

鍵を使える突合は、双方の表に同じ識別情報が含まれるケースです。請求書番号、注文番号、取引先コード、振込依頼人名など、一致を規則で判定できる列が該当します。この作業にAIは必須ではなく、表計算の関数や小さなプログラムでも解決できます。

鍵を使えない突合は、共通識別子が見つからないケースです。カード利用の明細から「誰と、どこで、何を目的に支払ったか」をたどる場合、日付・店舗名・金額は手掛かりになりますが、それだけで答えは決まりません。目的に関する情報は本人の記憶や当日の予定にあります。入金消込でも、複数請求の一括振込、手数料控除、相殺などが入ると、単純に一致する鍵がなくなります。

両者では、進め方もリスクも納品すべき結果も異なります。まとめて依頼すれば、本来なら識別子で確定できた行にまで推測が入りかねません。当社では初めに処理を2系統へ分離し、鍵で判定できる行を確定した後、未確定分だけを推定の工程へ渡しています。

鍵がある突合は計算そのものを任せない

共通の鍵がある場合に、最初に守るべき結論があります。件数、金額、差額などの算出をAIの回答だけで済ませてはいけません。集計はプログラムで行い、AIにはそのプログラムの作成と、得られた結果の説明を担当させます。

言語モデルは本来、正確な算術処理を保証する計算機ではありません。100行前後の合計が合う場合もありますが、確実な処理と偶然の正解を見分けられません。経理数値の怖さは、誤りがあっても外見上はもっともらしく見えることです。合計欄に自然な桁の数字が表示されていれば、目視だけで異常を発見するのは困難です。

依頼文は、たとえば「2ファイルを請求書番号で照合し、不一致の行を抽出するスクリプトを作成して実行し、結果をファイルに保存してください」とします。処理をスクリプトとして残せば、翌月以降も同一条件で繰り返せます。また、照合規則を後日確認できるため、監査や税務調査で処理方法の説明が必要になった場合にも役立ちます。

当社では、計算を決定論的な処理に任せ、AIは文章による解釈を担うという役割分担を、社内レポートでも共通ルールにしています。週次の検索流入レポートも、集計は専用スクリプトで実施し、AIが扱うのは変動理由の説明だけです。AIに数値そのものを作らせない設計が、間違いを抑える仕組みになります。詳しくは出力結果の信頼範囲を解説した記事もご参照ください。

鍵がない突合こそ、この道具が効く領域

共通キーを持たない資料は、単純なプログラムだけでは結びつけられません。このような照合でこそ、Claude Codeの強みが現れます。

当社で行った作業を例にします。確定申告用の経費一覧には、領収書から日付、店舗名、金額を転記できますが、「誰と」「場所」「目的」にあたる3列は未記入で残ります。その空欄を補うため、毎年、1年間の予定表を一次資料として照らし合わせています。

具体的には、支出日と同じ日に会食の予定が記録されていれば、予定にある参加者や場所を根拠として参照します。予定名に店舗名まで残っているケースなら、対応の確度は上がります。移動予定と宿泊予定が連続していれば、出張に関連する一連の支出として検討できます。

この対応は、文字列検索や関数だけでは判断できません。「PM飲み会」という予定と居酒屋のレシートが同じ出来事だと結論づけるには、記載が違っても意味が共通すると理解する必要があります。そして、この意味づけこそ、これまで担当者が毎年多くの時間を費やしてきた工程です。

同様の課題はほかの経理処理にもあります。入金摘要の略称を請求先の正式名称へ寄せる作業は名寄せであり、経費の但し書きから科目候補を示す作業では、支出の内容を規程の表現と照らす必要があります。どちらも唯一の正解を機械的に決められない一方、候補を選んだ根拠は示せます。この性質を持つ業務が適した領域です。

最大の詰まり：確定した数字を壊さない

ここからは、一般的な解説では見落とされやすい安全面に進みます。経理表には、変更を許してはならない領域があります。月次締めが済んだ金額、承認後の申請、税理士へ提出済みの数値などです。たった1つのセルでも変われば、過去へさかのぼって整合性を調べ直すことになります。

表計算データの変更は、画面を眺めただけでは判別しにくい点も問題です。ファイルを開いても、当日に更新されたセルが自動で強調されるわけではありません。もっともらしい金額が入っていれば、翌日見た担当者は以前からあった値だと受け取ってしまいます。

確定済みの値を保護する4つの運用ルールを示す図

当社の実務では、4つのルールを順番どおりに適用しています。

最初に、いつでも原本へ復元できる状態を整えます。処理を始める前にコピーを用意するか、更新履歴が保存される環境で作業します。方式はどちらでもよく、重要なのは当日の変更を一括して元へ戻せることです。この準備がなければ、誤りを人手で一つずつ直すほかありません。復元可能な環境については作業前に戻り道を確保する方法の記事で解説しています。

次に、更新を許す列をあらかじめ限定します。空いている3列だけを対象とするなら、その条件を依頼文と処理用スクリプトの両方へ記載します。先に範囲を狭めることで、万一の不具合が及ぶ最大範囲も限定できます。

3番目は、すでに入力されている内容を一切置き換えないことです。当社では例外を設けない社内原則として文書化し、人が記録した情報を優先すると明確にしています。書き込み先を未入力セルだけに制約すれば、この決まりを処理上も強制できます。

最後に、更新の直前に対象を再取得し、想定外のセルが1つでも見つかれば処理全体を中断します。4つの中でも特に大切でありながら、抜け落ちやすい確認です。準備中に別の担当者が同じ表を編集する可能性は常にあります。直前の状態が想定と一致するかを検査し、異なれば一切更新しない判定をスクリプトへ組み込みます。

実際に全件中止した日の話

最後のルールが実際にデータを守ったことがあります。2026年8月1日に経費一覧の未入力欄を補う処理を行った際、安全検査が差異を検知し、すべての書き込みを停止しました。

調査の結果、処理準備の途中で代表が13行を手作業で埋めていたことが判明しました。準備時点では空だったはずのセルに、最新情報が追加されていたのです。直前確認がなければ、代表が入力した13行を消し、提案内容で置き換えていたはずです。

この停止はシステムの故障ではなく、安全策が意図どおり機能した結果です。予定していた作業が終わらなかったため一見すると失敗ですが、その代わりに、本人だけが把握していた情報を保護できました。

加えて、停止記録に残された想定外セルの内容は、次の処理に役立ちました。そこには最新の入力があるため、その情報をもう一度読み込み、残りの候補を作り直せます。中断時の記録も、新しい判断材料として利用できたのです。

経理資料は、複数の利用者が同時期に編集するものとして設計する必要があります。とくに締めの時期は、承認者、記帳担当者、経費申請者がそれぞれのタイミングでアクセスします。読み取った瞬間と、実際に書き込む瞬間で状態が変わらないとは限りません。その認識を前提に安全策を作ります。

確からしさを色で残す

照合後の表には、根拠の強さが異なる内容が共存します。一次資料で確認できた情報、資料から推定した候補、作業前から記載されていた情報です。これらを同じ書式で表示すると、閲覧者が見分けられず、推定内容を確定事実として受け取る危険があります。

根拠確認済みを赤、確認待ちの提案を青、既存入力を黒で区別した図

当社では文字色を3つに分けています。赤は一次資料によって確認できた内容、青は確認を要する提案、黒は作業開始前から入力されていた内容です。この表示なら、表を見るだけで、人が確認すべき箇所をすぐ把握できます。

青い提案には、表現上のルールも設けています。冒頭へ「（提案）」を付け、裏付けになる情報が見つからない場合は「手掛かりなし」と明記します。根拠の弱さをそのまま見せることで、担当者は確認の順番を決めやすくなります。

税務に関係する証憑を扱う以上、推定と事実の区別は欠かせません。予定表に私用の記録しかない日に、存在しない業務目的を補ってはいけません。資料に記録された事実のみを示し、経費として扱うかは本人が決めます。この境界を表示上も崩さないため、色分けを運用ルールとして採用しています。

ただし、文字色を利用するときは、結果の確かめ方にも工夫が要ります。次節で具体的に説明します。

表計算ファイル特有の落とし穴

既存の表計算ファイルを維持して処理するなら、その形式に特有の問題を避けられません。ここでは、当社の作業中に実際に遭遇した注意点を紹介します。

数式を含む列へまとめて値を書けば、式が失われる可能性があります。広い範囲を一括更新する方法は高速ですが、その領域に存在した数式まで計算後の固定値へ変えてしまいます。翌月になって数値が連動しないことで発覚することもあり、原因の切り分けには手間がかかります。更新前に対象内の数式を検出し、1つでも含まれる場合は一括処理を避けるのが対策です。

セル結合があると、行列の位置を誤認することがあります。表示を整えるために結合した見出しが、機械による読み込みでは空セルとして扱われ、後続データの位置関係がずれる原因になります。原本を複製する際、結合を外した平らな作業表も用意しておくと確実です。

プルダウンなどの入力規則は、直接値を入れると違反状態になることがあります。候補に含まれない文字が書き込まれると、画面には値が見えていても、規則上は不正なセルになります。事前に許可された候補を取得し、その中にある値だけを選ぶ制限が必要です。

外部の処理から文字色を取得できない環境もあります。当社でも、セル値を読める一方で文字色は参照できないケースがありました。そこで、色を設定した処理自身が終了時に各色の数を集計し、ログへ記録する方式にしています。赤、青、その他がそれぞれ何件だったかを確認し、予定数と照らします。作成後に正しさを確認できる成果物だけを出すという原則を、色にも適用した例です。

スクリプトには連続して動かせる時間の制約があります。Googleスプレッドシートに連携したスクリプトは、公式の割り当て一覧上、1回につき最大6分です。この上限は無料アカウントとGoogle Workspaceアカウントで共通しています。トリガーによる実行時間の総量は、無料アカウントでは1日最大90分、Google Workspaceアカウントでは1日最大6時間とされています（2026年8月25日確認。制限値は変わる可能性があるため、必ず公式の割り当てページで最新情報をご確認ください）。数千行を一度に処理すると上限へ達しやすいため、あらかじめ小分けに実行できる構成にします。

材料の取りこぼしは「該当なし」の顔をする

突合において発見が難しいのは、誤った相手と結びつけることだけではありません。必要な資料を取得できていない状態も、見逃しやすい失敗です。

当社の経費照合では、予定表から取得できる件数の上限に直面しました。1か月を一括取得すると上限を超え、続きのデータを残したまま後工程へ進んでしまいます。欠落した予定はエラーとして現れず、その日の記録が存在しないように見えます。実際には予定が登録されているにもかかわらず、照合結果だけが「該当なし」になります。

この問題は、取得期間を半月単位に分けることで解消しました。範囲を短くすれば件数制限に収まり、未取得の続きも生じません。この経験から得られる基本動作は、短い期間ごとにデータを集め、取得数を毎回記録することです。

経理で使う別の資料でも、同じ種類の欠落が発生します。会計システムの表示上限で一部が出力されない、金融明細が期間別のファイルに分かれる、共有フォルダの一部を権限不足で参照できない、といった場合です。どれも明確なエラーではなく、結果が自然な0件として返る可能性があります。

そのため、処理前に人が資料の想定総数を把握しておかなければなりません。当月の請求書が何通あり、経費申請が何件あるかを先に数えておきます。最後にその想定数と実処理数を比べることが、静かな取りこぼしを見つける唯一の方法です。

月次突合を回す6つの工程

複製の準備、資料収集、キー照合、残件推定、色分け、検証からなる6段階の図

ここまで説明した内容を、実際に作業する順序へ整理します。当社の経費一覧で用いている手順を、一般的な月次経理へ置き換えた流れです。

第1工程では、専用の作業場所を作ります。当月用フォルダへ原本のコピーを配置し、以降の処理と起動をすべてその中で行います。原データの保存場所は、変更できる範囲の外側に維持します。

第2工程では、シートの構造を把握します。各列の意味、空欄の位置、数式・セル結合・入力規則の有無を調べます。この時点で更新禁止セルを一覧化します。この確認を省けば、以降の判断は不確かな構造理解に依存してしまいます。

第3工程では、参照資料を期間ごとに分けて収集します。入出金の明細、請求書、カレンダー、申請一覧などを集め、それぞれの取得数を記録します。この数が最終確認の基準になります。

第4工程では、共通キーを持つ行を規則に従って確定します。作成したスクリプトで照合を行い、一致分と不一致分へ分離します。後の工程で扱うのは、ここで対応が決まらなかった行だけです。

第5工程では、未確定行ごとに根拠を添えた候補を作成します。元の表へすぐ反映せず、最初は全候補を別ファイルへ出力し、判断材料も併記します。担当者はその一覧を確認し、明らかな誤りを除外します。

第6工程では、直前確認後に反映し、その結果を検証します。対象セルを再読込し、差異があれば全件を止めます。反映が終わったら、値は外部から読み返して件数を照合し、文字色は書き込み処理の内部で集計します。

この手順で重要なのは、第5工程の段階で判断を人へ戻すことです。表へ反映する前に提案一覧を確認できれば、方向性が誤っていても影響は候補ファイル内だけにとどまります。

推定は普通に外れるという前提

共通キーのない照合を行う以上、推定結果が間違うことは避けられません。これはAIの性能だけの問題ではなく、そもそも参照資料の中に正解が記録されていなければ当然に起こります。

当社でも、金額が大きい会食費を、過去の類似支出から社内交流のためのものだと推測したことがあります。しかし実際は、別月に実施した取引先との連携協議に関連する会食でした。推論の過程に不自然さはなくても、導かれた結論は正しくありませんでした。

この事例を受け、金額の大きな項目ほど推測で埋めず、本人へ確認する運用にしています。全件に占める割合は小さくても、誤りが与える影響の大きな項目です。一方、金額が小さく件数の多い項目は候補提示を活用し、青色のまま残して後でまとめて確認します。

資料間で名称が一致しないことも、日常的に起こります。カレンダーの予定名とレシートの店舗名が違う例は珍しくなく、予約後に店を変更した場合などが考えられます。同じ出来事に属すると判断できることはありますが、表記の不一致が存在した事実は報告へ必ず記載します。差異を隠して統一すると、検証の手掛かりが失われるからです。

任せてはいけない5つの領域

活用できる業務がある一方、経理の中にはAIへ最終権限を渡すべきでない領域も明確に存在します。ここでは5つに分けます。

第1は、勘定科目を最終的に確定することです。候補の提示と決定は同じではありません。税務判断を含む処理になるため、最後は顧問税理士が確認する前提を維持します。

第2は、税務解釈に基づく結論です。損金として認められるか、消費税をどう区分するか、どの割合で按分するかは、法令や通達を踏まえた解釈を要します。調査補助には使えても、結論を出す主体には置けません。

第3は、確定後の数値を変更することです。締め処理済みの月を直す行為は、日常処理ではなく例外対応です。承認者や証跡の残し方を定めた正式手続きで扱い、自動処理から切り離します。

第4は、漏れがないことを保証する必要がある照合です。全件性を証明しなければならない業務を任せるべきではありません。検索結果が0件であっても、対象が存在しない証拠にはならないためです。

第5は、承認行為です。経費を認める判断、支払処理の実行、最終金額の確定など、外部や会社へ効力が及ぶ行為は人が担当します。当社でも社外へ出る成果物は下書きで止め、送信・実行権限自体を与えない構成にしています。詳細は失敗を前提に安全を作る業務設計の記事で説明しています。

突合できなかった行こそが成果物

突合の価値を一致件数だけで評価すると、担当者が必要とする成果を見失います。問題なく一致したものは、そもそも追加確認を要しない行です。実務で詳しく見るべきなのは、対応先が決まらなかった行です。

当社では結果を2種類に分けています。1つは対応関係が確定した一覧、もう1つは、結びつかなかった項目と不一致理由をまとめた一覧です。後者のほうが、その後の対応を決めるうえで有用な場合も少なくありません。

不一致の理由をあらかじめ分類しておけば、次に取るべき行動も明確になります。実務上は、次の5つに整理できます。

必要資料が未着：請求書をまだ受領していない、取得した明細の対象期間が短い
名称表記に差がある：略称と正式名、変更前の社名、部署名を含むかどうか
金額に差異がある：振込手数料の控除、一部のみの入金、相殺処理、値引き
複数分が一括処理されている：いくつかの請求をまとめて1件として入金している
対応対象が実際に存在しない：計上の漏れ、重複計上、取引先側の処理ミス

5分類のうち、純粋な異常に当たるのは最後の項目です。それ以外の4つには定型の対処があるため、理由を判別できた時点で具体的な作業へ移せます。分類なしで「50件が不一致」とだけ報告しても、担当者が調べる負担はほぼ変わりません。

依頼時点で、結果に理由分類を含めるよう指定します。たとえば、不一致行ごとに5分類のどれに該当するか、その判定材料とともに提示するよう求めます。説明根拠を必須にすれば、裏付けのない分類を抑えられます。

最初の30分で試すこと

導入したばかりの経理担当者には、次の試行方法を案内しています。最初から月次工程を丸ごと対象にせず、ファイルを変更しない読み取り作業だけで使い勝手を確かめます。

初めの10分で、資料を準備します。専用フォルダを作成し、前月分の入金明細と請求一覧を複製して入れます。この段階では、ファイルの内容には手を加えません。

続く10分で、表の構成を読み解かせます。フォルダ内の2表について、列ごとの内容と、双方で照合に使えそうな列を整理するよう依頼します。返された説明を自分の認識と照らしてください。理解が食い違う場合は、資料のレイアウトを先に見直す必要があります。

残りの10分では、正解が分かっている問題で確認します。処理が完了している過去月を使い、特定の入金がどの請求に対応するかを尋ね、既存の確定結果と比較します。正しければ活用可能な範囲を確認でき、誤っていれば不足している資料や条件を特定できます。

この30分で評価する対象は、AIの性能そのものではありません。自社で使っている表を現状のまま処理できるかを見極めます。数式や結合セルが多い、同じシート上に複数表が混在するといった場合には、先に作業用データを整える必要があります。詳しい扱い方は Excel・Googleスプレッドシートの実務利用を解説した記事をご覧ください。

経費照合に絞った詳しい流れを確認したい方には、経費と申請書類を照らし合わせる手順の記事でも一連の工程を紹介しています。

よくある疑問への回答

Q. 会計ソフトがあっても、表計算で別途照合する必要があるのでしょうか。
会計ソフト内で完結できる照合は、その機能を利用するのが適切です。ここで扱うのは、ソフト外に保存された資料との照合です。取引先発行の請求書、経費申請、各部門から提出される報告などが外部に残る限り、それらを照らす工程はなくなりません。

Q. AIへ会計情報を渡すことに不安があります。
当然検討すべき懸念です。使用前に、渡す情報の種類と範囲を明確に決めてください。取引先名・金額を含む明細を対象にする場合と、名称を伏せた数値だけを使う場合では、必要な管理が異なります。当社も情報区分ごとに扱いを定めており、判断基準は入力可能な情報の境界を整理した記事で紹介しています。

Q. 経理の担当者もプログラミングを学ぶ必要がありますか。
自分の手でスクリプトを書く技能までは求められません。ただし、集計はプログラムへ任せ、AIには説明を担当させるという役割の違いは理解しておく必要があります。ここを区別しないと、AIへ直接計算させた値が、検算なしで資料へ使われるおそれがあります。依頼文の作り方は非技術職向けプロンプト例の記事にまとめています。

Q. 月次の定例業務として根付かせるには、どう進めればよいですか。
最初の1か月は作業手順の記録を優先します。次の月に同じ工程を再現し、3か月目を目安に定期実行を検討してください。導入直後から無人化すると、処理停止に誰も気づかない状態になりかねません。定期処理と停止検知の仕組みは自動実行の設計を扱う記事で解説しています。

Q. 経理部全体へ展開する前に、何を決めるべきですか。
利用者、アクセス可能なファイル範囲、承認を挟む地点、記録方法、停止手段、運用責任者という6項目を先に定めます。具体的な検討事項は情報システム部門向けの展開設計の記事でご確認いただけます。