カード明細をそのまま会計に流すとき、摘要を1行ずつ読んで勘定科目を選んでいる。「タクシー代 東京駅まで」なら旅費交通費、「コピー用紙5束」なら消耗品費。判断としては同じことの繰り返しなので、キーワードの辞書を作って式で引いた。
47語の辞書で200件の摘要を振り分けたら、166件に正しい科目が付いた。残りは辞書に当たらなかった22件と、違う科目が付いた12件だ。
以下の計算は、2026年9月21日にMicrosoft 365のExcel（バージョン16）で行った。200件の摘要は式を確かめるために作った架空のもので、実際の明細ではない。科目の決め方そのものは会社の基準に従う。
配列数式を使わずに、キーワードを1つずつ探す
辞書のキーワードを上から順に探して、当たったものの科目を返す。普通に書くとINDEXとMATCHの配列数式になって、Ctrl+Shift+Enterが要る。それをファイルに保存して配ると、開いた人が編集したとたんに壊れる。
代わりにLOOKUPを使った。
=IFERROR(LOOKUP(1,0/(ISNUMBER(SEARCH(辞書!$C$3:$C$202,ASC($B3)))
*(辞書!$A$3:$A$202<>"")),辞書!$B$3:$B$202),"未判定")LOOKUPは第2引数に範囲を渡すと、中で配列として扱ってくれる。Ctrl+Shift+Enterは要らない。SEARCHが当たった行はISNUMBERがTRUEになり、0/TRUEで0が入る。当たらなかった行は0/FALSEでエラーになる。LOOKUPは探す値より大きい要素とエラーを飛ばすので、0の入っている行だけが候補になる。
ここで大事なのは、LOOKUPが候補の中の最後を返すことだ。2つのキーワードに当たったら、辞書の下にあるほうが勝つ。この性質は運用に合っている。間違いを見つけたときに辞書の末尾へ行を足せば、前の行を書き換えなくても上書きできる。
辞書の空行が、全部の行に当たった
最初は(辞書!$A$3:$A$202<>"")を掛けていなかった。結果は全行が同じ科目になった。
原因はSEARCHの仕様だ。SEARCH("","タクシー代")は1を返す。空文字はどんな文字列の先頭にもあると判定される。辞書の200行のうち使っているのは47行で、残り153行は空。その空行が全部当たるので、LOOKUPが返すのは一番下の空行になる。
キーワードが空でない行だけを残すために、TRUEかFALSEに1か0を掛けている。0/0はエラーになって候補から外れる。
半角カナで書かれた12件のうち、8件を外した
200件には、カード明細でよくある書かれ方を混ぜた。「ﾀｸｼｰ代 本社まで」「ｶﾞｿﾘﾝ代 ﾚｷﾞｭﾗｰ32L」のような半角カナが12件ある。
そのまま照合すると、このうち8件が未判定になった。SEARCHは半角カナと全角カナを別の文字として扱う。辞書に「タクシー」と書いてあっても「ﾀｸｼｰ」には当たらない。
ASCを挟んで両側を半角にそろえたら、12件とも当たるようになった。摘要はASC($B3)、辞書側は作業列でASC($A3)を作って、その列を探しにいく。片側だけ変換しても意味がない。
全体では、正解が158件から166件に増えた。的中率で79.0%から83.0%になる。
半角と全角の差はASCで消せるが、ひらがなとカタカナの差は消せない。「たくしー代」と書かれたら当たらない。辞書に「たくしー」を足せば当たるようになる。関数でひらがなとカタカナを寄せる方法は確認していない。
SEARCHが英字の大小を無視するのは助かる。辞書に「ETC」と書いておけば「etc利用料」にも当たる。ただし辞書側を全角で「ＥＴＣ」と書くと、半角の「ETC」には当たらない。ASCを挟めばここもそろう。
未判定22件より、誤判定12件のほうが危ない
未判定の22件は、画面で色が付くので必ず目に入る。「セブンイレブン」「立替分」「カード明細より」のように、摘要だけでは科目が決まらないものだ。これは人が見るしかない。
問題は12件の誤判定のほうだ。「会議室までタクシー」に会議費が付いた。「打合せ後タクシーで移動」も会議費になった。どちらも旅費交通費が正しい。辞書には「タクシー」も「会議」も入っていて、下にある「会議」が勝ったからだ。
科目が付いているので、画面では正常に見える。誰も見ない。
そこで、別の科目のキーワードにも当たっているかを数える列を足した。
=IF(SUMPRODUCT(ISNUMBER(SEARCH(辞書!$C$3:$C$202,ASC($B3)))
*(辞書!$A$3:$A$202<>"")*(辞書!$B$3:$B$202<>$D3))>0,"要確認","")当たったキーワードのうち、いま付いている科目と違う科目を持つものを数える。0より大きければ「要確認」を出す。
200件で試すと、印が付いたのは12件。誤判定12件は全部その中に入り、印が付かないまま間違っていた行は0件だった。人が見る件数は22件から34件に増えるが、見逃しは消える。
「打合せ弁当6人分」のように、2つ当たっても科目が同じなら印は付かない。「打合せ」も「弁当」も会議費だからだ。違う科目に当たったときだけ人に回る。
200件のうち166件はそのまま通せて、34件が人の手に残る。経費精算のチェックを式でやった記事では208件のうち人が見るのは18件だったので、こちらのほうが残る割合は大きい。科目を決める判断は、金額の異常を見つけるより曖昧だからだと思う。
キーワードに*と?は入れられない
辞書に*を含む語を入れて、当たらないはずの行が全部当たったことがある。SEARCHはワイルドカードを解釈する。SEARCH("*","コピー用紙")は1を返す。?も同じで、任意の1文字として読まれる。
同じ条件でFINDを使うと、*を文字そのものとして探す。ただしFINDは英字の大小を区別するので、「ETC」と「etc」が別物になる。どちらを取るかだが、摘要にワイルドカードが入ることはまずないので、大小を無視するSEARCHを選んだ。辞書側に記号を書かない、という決めごとで足りる。
辞書は、直すたびに下へ足していく
運用は単純にした。要確認と未判定の行を人が見て、科目を決める。決めた科目は手入力の列に書き、確定科目の列がそちらを優先する。同じ摘要がまた来そうなら、辞書の末尾に語を足す。
確定科目の列は、要確認と未判定の行では空のままにした。科目を出しておくと、直さないまま会計ソフトへ流れる。空なら、取り込みのときに弾かれるか、少なくとも手が止まる。空の行が何件あるかを数える式も置いてある。
上の行を書き換えないのは、いつ何を足したのかが残るからだ。「会議室までタクシー」を旅費交通費にしたいなら、末尾に「会議室まで」を足して旅費交通費と書く。前に入れた「会議」は触らない。
ただし、これで科目は直っても印は消えない。「会議」にも当たったままなので、要確認の表示は残る。印を消すには、その行の科目を手入力の列に書いて確定させる。曖昧な摘要は一度人が見る、という形になる。
辞書は200行まで用意した。47語から始めて、月に2つか3つ足していくとして、数年は足りる。増えるほど再計算は重くなる。500行すべてに摘要を入れて再計算させたら0.09秒だった。ファイルを開いて計算が終わるまでは3.2秒。この規模なら気にしなくていい。
辞書を増やすか、未判定を人が読むか、AIに投げるかは件数で決まる。判定をAIに任せるかどうかを50件測って決める話と同じで、月に10件しか出ない摘要のために辞書を育てても割に合わない。うちは要確認と未判定が月30件を超えたら辞書を見直す、という線にしている。
