Claude Codeに、作業のみならず、“進行管理係”を任せてみました。
見えてきたのは、AIに何を渡せるかという以前に、自分たちの仕事がどんな工程でできていたのかという意外と基本的な発見でした。
月次経理が、気づけば暗黙知になっていた
毎月同じことをしているのに、説明できない
月次の帳簿作成は、通帳やクレジットカードの明細を取り込み、仕訳を登録し、試算表をチェックして、といういくつかの作業の積み重ねです。
ただ、クライアントごとに会計ソフトが違ったり、freee（クラウド会計ソフト）と連携している・していないの差があったり、証憑の集め方が違ったりと、実際には一社一社で細かいやり方が変わります。
結果、担当者の頭の中にしか手順がない、という状態になりがちでした。
これは決して珍しいことではないと感じています。
複数のクライアントを長く担当していると、“あの会社は確かこうだったはず”という記憶だけで作業を進めてしまう場面が増えます。
記憶は便利ではありますが、担当が変わった瞬間や繁忙期には、抜け漏れの原因にもなりかねません。
属人化は悪いことばかりではない、が
長年同じ担当者が見ている業務は、判断のスピードが速く、多少の例外にも柔軟に対応できます。
その意味で、属人化そのものが悪いわけではありません。
ただ、その担当者が説明しようとした瞬間に手が止まる、というのは、工程そのものが可視化されていないサインだと思います。
そもそも工程が見えていない仕事は、どこをAIに任せられるかを考える以前の話です。
つまり、Claude Codeに任せる・任せないを判断するための土台が、そもそも欠けていたわけです。
Claude Codeに“進行管理係”をやらせてみた
入り口を1つにして、中の分岐はAIに判定させる
そこで作ったのは、月次経理の「オーケストレーター」でした。
オーケストレーターは、複数の作業をどの順番で・誰に割り振るかを管理する、いわば進行役です。
やったことはシンプルです。
クライアントごとの「記帳の仕方」「会計ソフトの種類」「freeeとの連携有無」を一覧表にまとめ、Claude Codeにその表を読ませたうえで、条件ごとに違う作業手順を割り振らせるようにしました。
人間側の入り口は「今月の分をお願い」の一言だけで、そこから先の「このクライアントはどの手順で進めるか」という分岐は、まずAIが表を見て判定します。
やってみて意外だったのは、この「分岐を整理する」という作業自体に、一番時間がかかったことです。
自分では当たり前だと思っていた判断が、言葉にしてみると思いのほか複雑でした。
AIが得意なところ、人にしかできないところが分かれてきた
工程を分けてみると、Claude Codeに任せやすい部分と、そうでない部分が自然と分かれてきました。
任せやすかったのは、次のような繰り返し性の高い作業です。
- 明細を確認し、過去の仕訳パターンと突き合わせて分類候補を出す
- 会計ソフトの試算表を取得し、あらかじめ決めたチェック項目に沿って点検する
- 処理の進捗を一覧にまとめ、報告の形に整える
一方、判断が必要な部分は、これまでどおり人が担います。
私の場合は、要所要所でAIの出力そのものに目を通すほか、特に、書込みを伴う操作の最終承認、金額の大きい取引、そして税務上の判断が必要な確認事項を、必ず人が最後に見る場所として固定しています。
これは、AIが判断そのものを代替するのではなく、判断にたどり着くまでの手を動かす部分を代替するという重要な線引きだと考えています。
AIの仕事をAIにチェックさせる、という発想
また、進めるなかで必要性を感じたのが、AIが行った作業を別のAIに検証させる仕組みでした。
というのも、AIが「登録した」という事実と、会計データに「正しく計上された」という事実は、別物でもあるからです。
“登録したつもりが金額や勘定科目を間違えていた”、というのは人間でも起こりうるミスで、AIも例外ではありません。
そこで、仕訳登録を担当したAIとは別に、その結果だけを独立に見直すAIを用意し、登録件数や金額、勘定科目のズレがないかを突き合わせる工程を挟むようにしています。
作業する係と、確認する係を分ける、という発想自体は、人間の経理チームで昔からやってきたダブルチェックと変わりません。
それをAI同士の役割分担として置き換えただけともいえます。
これを人だけでやろうとすると、確認のためにもう1人分の手が必要になります。
AIであれば、その“もう1人”を必要なときに呼び出せるという点が、地味ながら大きな違いだと感じています。
これによって精度は上がりますし、かつ、さらに上げていく仕組みを作ることができるのです。
分業ラインが見えると、次に考えたくなること
任せる範囲は、少しずつ広げていけばいい
最初から全クライアントを一括で任せようとはせず、まずは1社ずつ試すところから始めました。
うまくいかない部分が見つかるたびに、クライアントごとのルールを書き足していく、という地味な積み重ねです。
知識や仕組みが完璧に整ってから動き出そうとすると、いつまで経っても着手できませんし、動かしながら精度を上げていくほうが、結果的に早いと感じています。
最初から全部を一括で任せて失敗すると、その分の手直しも大きくなりますし、失望感やリカバリーのための労力も大きくなってしまいます。
少しずつ広げていくほうが、遠回りのようで結果的に安全だというのが実感です。
数ヶ月かけて手順が育ってきたところで、複数社を同時に処理する運用に切り替えました。
人間が最後に見る場所を決めておく
分業ラインが見えてくると、逆に「ここだけは人が見る」というチェックポイントも明確になります。
では、人間のチェックポイントの入れ方の選び方のコツは何と考えているか。
具体的には、Accountability（アカウンタビリティ）＝結果責任・執行責任、すなわち、「説明責任を負うことができるかどうか」だと解釈したうえで、チェックポイントを設けています。
工程が見える化される前は、この線引き自体も曖昧でした。
任せる部分とチェックする部分を分けて考えられるようになったことは、Claude Codeを導入して一番変わった点かもしれません。
