活用例として載せているのは、うまくいく形が見えているものです。ただ実際には、試してみたものの割に合わなかった、という場面のほうが先に来ます。ここでは、経理・財務の仕事でAIが働かないときの典型的な形を4つ挙げ、それぞれどう切り抜けるかを書いています。
請求書の画像を読み取らせて、仕訳案を作らせる。金額・取引先・日付までは正確に取れます。ところが勘定科目は8割程度しか合わず、プロジェクトコードと部門に至っては安定しません。確認と手直しに、自分で入力するのと変わらない時間がかかります。
プロジェクトコードを決めているのは請求書ではなく、受注データと社内の運用ルールだからです。請求書だけを渡している限り、AIは判断材料を持っていません。しかもAIは「材料が足りません」とは言わず、もっともらしいコードを埋めてきます。これが確認を重くします。
判断材料を一緒に渡すか、渡せない項目は空欄にさせるかの二択です。前者なら、取引先ごとの過去の仕訳パターンを一覧にして添える。後者なら「プロジェクトコードは推測せず空欄にしてください」と明示する。空欄で返ってくれば、確認すべき箇所がその場でわかります。
この形が強く出るため、このサイトでは請求書から仕訳案を作る例を「汎用例」として、考え方の提示にとどめています。
「この資産グループに減損の兆候があるか判定してください」「この繰延税金資産は回収可能と言えますか」と聞く。よく書けた文章が返り、結論まで示されます。
結論の当否を確かめる方法がないためです。照合なら元データに戻れば確かめられ、下書きなら読んで直せます。しかし見積りや重要性の判断は、確かめる基準そのものが自社の状況の中にあります。返ってきた文章が上手であるほど、検討したつもりになってしまうのが一番の危うさです。
問いの立て方を変えます。「兆候があるか」ではなく「兆候の判定項目を基準から抜き出して、資産グループごとの記入欄がある表にしてください」。判断は手元に残したまま、その手前の整理だけを渡す形です。考え方編の第2章に、結論と手前の作業の対応表を載せています。
「関連する会計基準と項番号を列挙してください」と頼む。20項目ほどが整った形で返ってきます。ところが1つずつ原文に当たると、基準名は合っているのに番号が違うもの、改正前の番号のもの、存在しない号数が混じっています。
項番号は、文章としての自然さと正しさがまったく連動しない情報だからです。そして誤りが1割混じっているとき、どの1割かはすべて確認するまでわかりません。20項目のうち2つを直すために、20項目すべてを原文で確認することになります。
網羅性を求めないことです。「確実なものだけを3つまで、自信がないものは『要確認』と付けて」と枠をはめると、確認の総量が管理できる範囲に収まります。もともと調査の入口として使う道具であって、引用元として使う道具ではない、と位置づけを決めておくのが確実です。
100ページの規程や長い業務委託契約を一度に渡し、論点を洗い出させる。前のほうと終わりのほうの条項は拾えているのに、真ん中あたりの重要な条項がごっそり落ちている。
長い入力ほど、中間部分の扱いが薄くなる傾向があるためです。落ちた箇所は出力に現れないので、原文を知らない人が読んでも気づけません。「洗い出し」という網羅性が前提の作業と、この性質は相性が悪い組合せです。
章や条の単位に切って、複数回に分けて渡します。手間は増えますが、どこまで見たかが自分で管理できます。あわせて、最後に「渡した条項のうち、今回の観点で言及しなかったものを番号で挙げてください」と聞くと、見落としの点検になります。
4つとも、根っこは同じところにあります。AIは、自分に何が足りないかを申告しません。したがって使う側が、渡す材料の範囲と、返ってこなかったものの確認方法を、あらかじめ決めておく必要があります。考え方編で挙げた4つの検証の型は、そのための最低限の備えです。