当法人（熊本市の税理士法人）の社内の仕事は、3つの道具の上で回っています。
- 顧客マスタ：スプレッドシートと AppSheet（スプレッドシートを元に業務アプリを作れる Google のツール）。顧問先の基本情報と、仕事の単位である「案件」をここで管理しています
- お客様とのやり取り：Backlog（タスク管理ツール。1件ごとの作業を「課題」と呼びます）。資料のお願い、ご質問への回答、申告後のご報告を課題として残しています
- お客様とのデータの受け渡し：Google ドライブ（共有ドライブ）。顧問先ごとのフォルダに書類を置き、その中で受け渡しをしています
この3つを GAS（Google Apps Script。スプレッドシートや Backlog をつなぐ自動処理のプログラム）でつなぎ、人の手を介さずに動く仕組みに変えようとしてきました。その過程で、いろいろ失敗しました。この記事は、その失敗の記録です。
先にお伝えしたい結論
細かい事故の話に入る前に、ここまでの経験から言えることを先に書きます。
- 自動化すると、事故も自動で広がる。 いちばん怖いのは、エラーで止まらず「黙って失敗する」仕組みです。案件が黙って「削除済み」になり、通知が黙って止まり、顧問先が黙ってずれる。この記事の3つの事故は、すべてこの型でした
- 設計で先に決めるのは、うまくいく場面ではなく「入力が想定と違ったとき、自動処理は何をするか」と「失敗したとき、誰がどうやって気づくか」。 「見つからない」を「消された」と推測させない。「成功」の返事だけで済ませず、別の経路で確かめる。書き換える前に、変更予定の一覧だけを出して人が確かめる
- それでも、自動化と AI の活用はやめない。 進め方は「まず小さく始める → 品質を上げる → 全体に広げる」の順です。最初から全体に広げようとしないことで、事故が起きても影響を小さく抑えられます
- AI や自動処理が探しやすいように、データの置き場所と道具をそろえる。 上の3つの座組（顧客マスタ・Backlog・共有ドライブ）は、そのための土台です。置き場所が決まっていないデータは、自動化しても取り違えのもとになります
- ミスのリスクを過大に見積もらない。代わりに、戻せる体制を作る。 データが残る契約、書き換える前の試運転、取り消せない操作は人に残す。戻せる体制があるから、小さく始めて試せます
この記事では、この結論に至った事故と、設計の変え方を、件数と時期つきで公開します。読み終えると、次のことが分かります。
- 自動処理が「黙って失敗する」とは、具体的にどういう状態か
- 自動化を設計するとき、うまくいく場面より先に決めておくべきこと
- 自社の仕組みを点検するための5つの質問
お急ぎの方は、上の結論と、記事の後半にある「顧問先にとって何が変わったか」「自社の仕組みを点検する5つの質問」だけでもどうぞ。
このシリーズでは、当法人が AI コーディングツール「Claude Code」と一緒に社内の業務システムを作り替えてきた過程を、実際の数字と失敗談を含めてお伝えしています。前回は、AppSheet・スプレッドシート・Backlog をつないだ社内システムの全体像を紹介しました。今回はその裏側、自動化して初めて起きた事故の話です。対策は入れて終わりではないため、2026年10月時点の状況も書き添えました。
事故1：自動処理が「見つからない」を「消された」と推測し、64件を「削除済み」にした
2026年6月、AppSheetのボタンから、Backlogの課題のステータスを更新する処理を実行しました。
ところが、選んだ案件を対応表から引き当てるAppSheet側の式（LOOKUP 関数）に誤りがありました。どの案件を選んでも、対応表の先頭1行しか返さなかったのです。
その状態で更新をかけたため、Backlogからは「見つかりません（404）」が返りました。当時のGASは、404が返ると「Backlog側で消されたのだろう」と判断し、シート側の案件を自動で「削除済み」にする作りでした。
結果、98件の案件のうち64件が、実際にはBacklogに残っているのに「削除済み」扱いになりました。
復旧では、Claude Codeに、Backlogの実データとシートを突き合わせて「本当は生きている案件」を洗い出させました。そのうえで復旧処理を作りました。1回目は60件が成功、4件が失敗でした。失敗の4件は、プロジェクト側の入力ルールでコメントなしの更新が受け付けられなかったものです。コメント付きで再実行し、64件すべてを戻しました。
対策：「404なら削除」の自動処理をやめた
復旧より大事なのは、この自動処理そのものを廃止したことです。
今は、削除はBacklog側で人が行います。自動処理がシート側の案件を「削除済み」にするのは、Backlogから「削除された」という通知が届いたときだけです。シート側が勝手に削除と判断する逆方向の処理は持ちません。週に1回の点検でも、Backlogに見つからない課題は「要確認」として数えるだけで、自動では消しません。
自動処理に、「見つからない」から「消された」と推測させない。 「見つからない」は「消された」とは限りません。通信の不調でも、こちらの指定ミスでも404は返ります。データを消すなど、元に戻しにくい操作は、推測を根拠にしない。相手側から届く明示的な通知を根拠にする。これが、この事故から得た原則です。
2026年10月時点：この設計は今も変わっていません。削除の通知を取りこぼしたことが一度ありました。そのときも自動では推測せず、人が確かめて手作業で反映しました。
事故2：期限から14日を過ぎたタスクが、通知されなくなっていた
期限を過ぎたタスクを担当者に知らせる仕組みは、最初は「凝った」設計でした。超過3日目・7日目・14日目に1回ずつ通知して、それ以外の日は静かにする「段階式」です。「毎日同じ通知が来ると、誰も見なくなる」という配慮からでした。
ところが運用してみると、穴がありました。14日を過ぎたタスクは、その後どこにも出てこないのです。一番放置されているタスクほど、一番静かになる設計になっていました。
対策：3日以上過ぎたタスクを、毎朝すべて通知する
2026年7月に段階式をやめ、期限を3日以上過ぎたタスクを、毎朝すべてまとめて通知する方式に変えました。通知の量は増えました。その代わり、「昨日も出ていたタスクが今日も出ている」ことが、そのまま放置の目印になります。
「賢い仕組み」を作りたくなったときほど、一番単純な方式で何が困るのかを先に確かめるべきでした。
2026年10月時点：その後、運用に合わせて次の2点を調整しています。
- 土日祝日は通知を止め、翌営業日に回す
- 担当者が決まっていないタスクは、担当者あての通知とは別の一覧にまとめる
また、処理が時間内に終わらず、その日の通知が1通も出なかった日が何日かありました。「通知が来ない＝期限切れが無い」とは限らない、という次の課題が見えています。
事故3：1つのプロジェクトに複数の会社が同居し、顧問先の判定がずれた
Backlogは本来、顧問先ごとに1つのプロジェクトを作って運用しています（顧問先とのBacklogの使い方はこちらの記事で紹介しています）。ただ、歴史的な経緯で、1つのプロジェクトに複数の会社が同居しているケースが残っていました。
システムは、「どのプロジェクトがどの会社か」を対応表で引きます。同居しているプロジェクトでは、対応表に後から登録された会社のほうが採用され、課題がすべてその会社のものとして扱われていました。
データの食い違いを調べる点検（整合性チェック）で、手動で起票された課題を数えました。すると107件のうち46件で、Backlog上のカテゴリとシート上の顧問先が食い違っていました。
対策：判定し直し、同居は毎週の点検で見えるようにした
まず、課題ごとに正しい顧問先を判定し直す処理を作り、ずれた分を直しました。判定しきれない課題は、推測で決めずに、人が確認する一覧に回しています。
次に、週次の点検（毎週月曜の朝）に、「1つのプロジェクトに複数の会社が紐づいていないか」の検査を足しました。
2026年10月時点：同居していたプロジェクトのうち、会社ごとに分けられたのはまだ一部です。残りは、毎週の点検に「同居あり」として出し続けて、見えている状態を保っています。判定し直す処理も、その後にもう一度実行しました。
「直した」と書いて終わりにせず、直しきれていないものを毎週見える場所に出し続ける。これも、壊れにくい運用の一部だと考えています。
その後に分かったこと：いちばん怖いのは「黙って失敗する」仕組み
3つの事故には、共通点があります。どれもエラーで止まらず、黙って誤った状態を作り続けたことです。案件は黙って「削除済み」になり、通知は黙って止まり、顧問先は黙ってずれていました。
この記事の下書きを書いた2026年8月以降も、同じ型の出来事や、それに近い出来事が続きました。主なものを5つ記録しておきます。
- 「成功」の返事のまま、操作ログが記録されていなかった
- 「正常」の返事を信じて、照会が失敗した
- 見た目を整えた変更で、異常の検出が約7週間エラーのままだった
- AIの書き込みが途中で失敗し、社内ファイルが空のまま残った
- 参照していた科目一覧が別の事業者のもので、仕訳の登録がすべて失敗した
ここからは仕組みの細かい話です。要点は章末の囲みにまとめたので、読み飛ばしても大丈夫です。
「成功」の返事のまま、操作ログが記録されていなかった
スプレッドシートに追加して使う社内用の機能（アドオン）の操作ログを、別のスプレッドシートに送って記録しています。2026年9月、記録先のシートの空き行が尽きた時点から、操作ログが黙って記録されなくなっていました。
受け取る側は失敗していたのに、送る側はその返事を「成功」と扱っていました。そのため、やり直しの仕組みにも乗らず、どこにもエラーが出ませんでした。対策は次の3つです。
- 受け取る側で起きた失敗を記録し、点検で報告する
- 受け取る側が、足りなくなった行を自動で足す
- 念のため、空き行が少なくなったら点検で知らせる
さらに調べると、毎日動くはずだった点検の予約そのものが、それまで設定されていなかったことも分かりました。点検の仕組みを作っても、動いていることを確かめなければ、無いのと同じでした。
このときの調査では、毎日決まった時刻に送られる記録が1行だけ残っていない、という別の欠けも見つかりました。2026年10月に原因を突き止めると、月次の処理が、同じデータを同時に書き換えないための順番待ち（ロック）を長く握ったままでした。その間に届いた記録は時間切れになり、やはり黙って落ちる作りでした。同じ10月に、処理がロックを長く握らないように直しています。
「正常」の返事を信じて、照会が8回失敗した
Backlogに届いたご質問に、社内に蓄えた専門資料から回答案を用意する仕組みがあります。2026年9月、資料を読むための認証（ログインの状態）が切れていたのに、状態を確かめる窓口は「正常」と答え続けていました。
そのあいだに照会が8回失敗しました。しかも「ここまで処理した」という目印だけが先に進んだため、あとでまとめて拾い直す処理でも拾われませんでした。担当のAIは「あとで拾い直されます」と報告していましたが、これも誤りでした。失敗した照会は、認証を直したあと、手作業で照会し直しました。
今は、「正常」の返事だけでなく、中身（認証が生きているか）まで確かめ、止まっているあいだは目印を進めません。知らせるのは止まったときと直ったときだけにして、知らせが多すぎて見られなくなることも避けています。
10月には、新しいPCへ移す作業の確認中に、別の不具合にも当たりました。「認証が生きているか」の確認そのものが、壊れたログイン情報を「有効」と答えたのです。使っていた道具の古い版の問題で、版を上げて直しました。確かめる仕組みも間違えることがある、という例です。
見た目を整えた変更で、異常の検出が約7週間エラーのままだった
2026年8月下旬、月次のチェックで作る推移表（科目ごとの月別の金額の表）を読みやすくするため、金額に桁区切りの「,」を付けました。ところが、この書式が表の月の見出し（「2026年2月」など）にもかかり、見出しが月ではなく数値として読まれるようになりました。
その結果、毎月の推移から大きく動いた科目を拾う「月次の異常検出」が、それ以降に作った表で毎回エラーになりました。指摘は1件も出ていませんでした。結果のシートには「エラー」と出ていたものの、Backlogに起票する報告では中身が読めない表示になっていて、気づけませんでした。
見つけたのは、10月中旬にBacklogで月次の分析を頼んだAIです。報告に、月次の異常を拾うチェックがエラーで実施されていない、と書いてあったため、調べて翌日に直しました。8月27日から10月16日まで、約7週間でした。
今は、月の見出しに月の書式を当て直し、すでに作った表も作り直さずに読めるようにしています。報告の本文にも、どのチェックがどんなエラーになったかを読める形で出します。
教訓は2つです。見た目だけの変更でも、その表を読むほかの処理が動くかを確かめること。そして、「異常が見つからなかった」と「調べられなかった」を取り違えないことです。
AIの書き込みが途中で失敗し、社内ファイルが空のまま残った
ここからの2件は「黙って」ではありませんが、おかしな状態のまま作業を進めてしまった例です。
2026年8月、Claude Codeが共有ドライブ上の社内用のファイル（顧問先の基本情報をまとめたもの）を書き換えようとしました。「中身を空にしてから書き込む」手順の、書き込みのほうに失敗し、ファイルを空のまま残しました。書き込みの権限が無い状態で作業していたことが原因です。内容は復元しました。
この件から、次の2つを決めました。
- 共有ドライブ上のファイルは、「空にする」と「書き込む」を分けずに、1回の操作で書き切る
- 書き込む前に元の内容を読んで、戻せるようにしておく
あわせて、共有ドライブ上のファイルの削除は、AIが判断せず、人の承認を得てから行う決まりにしています。
参照していた科目一覧が別の事業者のもので、仕訳の登録がすべて失敗した
2026年9月、仕訳を登録するときに参照する科目などの一覧が別の事業者のものになっていて、登録がすべて失敗しました。マネーフォワード クラウド会計の側ですべて受け付けられなかったため、誤って登録された仕訳はありませんでした。ただ、原因が分からないまま同じ処理を何度かやり直し、読み取りの費用だけがかかりました。
今は、登録の前に「参照している一覧の事業者」と「選んでいる顧問先」が一致しているかを確かめ、食い違えば読み取りの前に止めます。月次のチェック用のデータを作るときも、他の顧問先の情報が混ざっていないかを、作る前と作った後の両方で確かめます。
「止まる」より「黙って続く」ほうが怖い。 エラーで止まれば、誰かが気づきます。危ないのは、失敗しているのに「成功」「正常」と見えるときです。仕組みを作るときは、これまでの失敗から学んだ次の3つに気をつけています。
- 返事が「成功」でも、本当に届いたか・書けたかを別の経路で確かめる（受け取る側の失敗の記録や、毎日の点検など）
- 点検の仕組みは、動いていることまで確かめる
- おかしいときは、処理を進めずに止めて知らせる
クラウド会計の帳簿でも起きる「黙って失敗する」状態
同じことは、クラウド会計を使う会社の帳簿でも起こります。たとえば、銀行口座やクレジットカードのデータ連携が止まっていても、試算表はいつもどおり出てきます。そのため、その月の明細が抜けていることには気づきにくいものです。
当法人の月次のチェックには、この抜けを確かめる項目があります。口座・カードごとに帳簿に登録された最後の取引日を見て、月末（カードは締め日）まで記帳されているか、抜けている期間がないかを確かめます。対象は、マネーフォワード クラウド会計をお使いで、この仕組みに登録している顧問先です（仕組みは第4回で紹介します。近日公開）。
顧問先にとって何が変わったか
社内の事故の話ですが、対策の多くは顧問先へのサービスに直結しています。
- 期限を過ぎたタスクが埋もれにくい：期限を3日以上過ぎたタスクは、片づくまで毎朝（土日祝日は翌営業日に）まとめて通知されます（担当者が決まっていないタスクは別の一覧にまとめています）。ただし、処理が時間内に終わらず、通知が出なかった日もありました
- 進行中の案件が、誤って「削除済み」になりにくい：自動処理は「見つからない」というだけでは消しません。削除は人がBacklogで行います
- 別の会社の情報が混ざるリスクを減らす：仕訳の登録前に、参照している一覧の事業者と選んでいる顧問先が一致しているかを確かめます。食い違えば止めます。月次のチェック用のデータも、他の顧問先の情報が混ざっていないかを、作る前と作った後に確かめます
- 調べられなかったチェックを見落としにくい：月次のチェックでエラーになった項目は、どのチェックがどんなエラーになったかを報告の本文に出します
- 顧問先の判定のずれを毎週点検：1つのプロジェクトに複数の会社が紐づいていないかを、毎週月曜の朝に確かめています
自動化を検討している方へ：先に決めておきたい2つのこと
3つの事故には、もう1つ共通点があります。コードのバグそのものより、「その状況で自動処理に何をさせるか」の判断が甘かったことです。
- 見つからない → 消す（事故1）
- 通知しすぎない → 一番古いものが通知されない（事故2）
- 対応表は最後の登録が正しい → 同居していると全部ずれる（事故3）
どれも、作っているときは合理的に見えました。自動化の設計では、「うまくいくとき」より、次の2つに時間を使う価値があります。
- 入力が想定と違ったとき、自動処理は何をするか
- 失敗したとき、誰がどうやって気づくか
AIに作業を任せる場合も同じです。「あとで拾い直されます」というAIの報告は誤りでした。一方で、異常の検出が止まっていたことに気づけたのも、AIが「できなかったこと」を報告に書いてくれたからでした。AIの「できました」「大丈夫です」は、中身を確かめるまで結論にしないようにしています。
当法人がバックオフィスDX化支援でお客様の仕組みづくりをお手伝いするときも、この視点を持ち込んでいます。
- 業務フローの診断では、「例外が起きたらどこで止めるか」を一緒に決めます
- 承認ワークフローや会計への連動の設定では、差し戻しの流れ・消してよいデータの範囲・止まったときに誰が気づくかまで、できるだけ先に決めておきます
ツールの機能説明より、そこに時間をかけます。導入の最初でつまずきやすい点は、マネーフォワード クラウドでバックオフィス業務はここまで効率化できるでも整理しています。
事故を経ても、AIと自動化を進める理由と順番
ここまで事故の話ばかり書きましたが、当法人は自動化や AI の活用をやめていません。むしろ、事故を経て「うまくいく進め方」がはっきりしてきました。冒頭の結論の3〜5を、少し詳しく書きます。
1. まず小さく始め、品質を上げてから全体に広げる
AIの導入は、とにかく始めてみることが出発点です。最初から全社・全顧問先に広げる計画を立てるより、小さな作業1つでよいので、まずAIにやらせてみます。動かしてみて初めて、AIがどこでつまずき、どこで人の確認が要るかが分かります。
当法人でも、新しい仕組みは対象を絞って動かし、出てきたミスや手戻りを1つずつ直して品質を上げてから、全体に広げてきました。上の事故の多くも、対象を広げる前後の「動かしてみた段階」で見つかったものです。始める → 品質を上げる → 全体に広げるの順番を守ると、事故が起きても影響を小さく抑えられます。
2. 整理されたデータを、AIが探しやすい形で渡す
AIの出来は、AIそのものの賢さより、渡すデータが整理されているかどうかで大きく変わります。必要な情報がどこにあるのかAIが迷う状態では、読み違いや取り違えが起きやすくなります。事故3（1つのプロジェクトに複数の会社が同居して顧問先の判定がずれた）は、まさにデータの置き方が原因でした。
そのため当法人では、AIに仕事を頼む前の土台として、次のことをそろえてきました。
- Googleドライブのフォルダ構成を体系立てて管理する：顧問先ごと・決算期ごとに、どこに何を置くかを決め、同じ形で並べる（第1回の振り分けも、この決まった置き場所が前提です）
- 顧客マスタを1つに決める：顧問先の情報（会社コード・会社名・どのプロジェクトやフォルダとつながるか）を1つの台帳で管理し、ほかの仕組みはそこを見る（第2回）
- 使うツールを統一する：お客様とのやり取りはBacklogを通して行い、Google Meetでの会議は議事録にして、決まった共有ドライブに格納する。情報の入口と置き場所が決まっていれば、AIはそこだけを探せばよくなります
ツールや置き場所がばらばらのままAIを入れると、AIが探す場所が増え、そのぶん間違える余地も増えます。AIが探しやすいように整えておくことが、いちばん効く準備でした。
3. ミスのリスクを過大に見積もりすぎず、戻せる体制を作っておく
AIや自動化を使えば、ミスが起きることはあります。この記事で書いた事故も、その例です。ただ、人の手作業にもミスはあります。ミスのリスクを過大に見積もって何も始めないことのほうが、損失は大きいと考えています。
大事なのは、ミスを完全になくそうとすることより、何か起きたときに気づけて、元に戻せる体制にしておくことです。
- データが残る仕組みにしておく：当法人では Google Workspace を Enterprise のプランで契約し、誤って消したり書き換えたりしても、データが残り、元に戻せる体制にしています
- 書き換える前に、変更の一覧を出して人が確かめる：事故1の64件も、復旧の前に「戻す予定の一覧」を出し、人が確かめてから戻しました
- 取り消せない操作は人に残す：送金・削除・お客様への連絡のように、あとから戻せない操作はAIや自動処理に任せない
戻せる体制があるから、小さく始めて試すことができます。1と3は、セットで考えるとうまく回ります。
自社の仕組みを点検する5つの質問
当法人の事故を自社の業務に置き換えると、次の5つの質問になります。クラウド会計の連携、承認ワークフロー、スプレッドシートの自動処理など、すでに動いている仕組みにも当てはめてみてください。
- 相手のシステムから「見つからない」と返ってきたとき、自動で消したり「完了」にしたりしていませんか（事故1）
- 通知や催促を減らす工夫が、いちばん長く放置されているものほど目に入らない形になっていませんか（事故2）
- 1つの対応表や設定に、複数の会社や部署が同居していませんか（事故3）
- 「成功」「正常」という返事だけで済ませず、本当に届いたか・処理が動いたかを別の方法で確かめていますか
- データをまとめて書き換える前に、変更予定の一覧を出して人が確かめていますか
答えに詰まる質問があれば、そこが「黙って失敗する」かもしれない場所です。
事故を繰り返さないための3つの習慣（仕組みを作る側の補足）
事故対応そのものもClaude Codeと一緒に行っていて、次の3つのやり方が定着しました。
1. 事故は「インシデントメモ」として残す
何が起きたか、影響件数、復旧の手順と結果、再発防止策を1つの文書（インシデントメモ）にまとめます。このメモは、Claude Codeのルールブック（CLAUDE.md）から参照されます。そのため、次に似た機能を作るとき、Claude Codeが過去の事故を踏まえて注意点を先に挙げてくれることが増えました。
2. 「壊してはいけない前提」をコードの説明に書く たとえば「削除はBacklogからの通知だけを根拠にする」は、コメントとしてコードの横にも書いてあります。半年後の自分やAIが「ここ簡略化できそう」と思ったときの歯止めです。
3. 書き換える処理は、試運転から データをまとめて書き換える処理や、ファイルを動かす処理には、「先に一覧だけを出す」試運転（ドライラン）を入れるようにしています（第1回のファイル振り分けも同じです）。64件の復旧のときも、まず「戻す予定の一覧」だけを出させ、人が目で見てから実行しました。復旧処理で二次事故を起こすのが一番つらいからです。
なお、顧問先の情報をAIサービスで扱う場合は、法人向けのプランまたは有料のサービスを、入力した情報をAIモデルの学習に利用しない設定又は契約のもとで利用しています。マイナンバー（個人番号）はAIサービスに入力しません（AIの活用について）。
事故ではないが、運用して分かった3つの調整（仕組みを作る側の補足）
運用して初めて分かった、細かい調整の記録です。
1. 変更を取り込む定期処理（安全網）の頻度を下げた（2026年8月） Backlogの変更をシートに取り込む定期処理を、5分ごとから60分ごとに変えました。頻繁すぎて、リアルタイムの通知処理と順番待ち（ロック）がぶつかり、本来のリアルタイム更新のほうが失敗することがあったためです。「安全網は網であって本線ではない」と割り切りました。頻度を下げた後もぶつかりは起きていますが、順番を取れなかった通知は捨てずに、あとでやり直す仕組みもあわせて使っています。
2. 削除の作法を文書化した テスト用の案件を消したときに、関連データ57件が孤立して残り、整合性チェックで59件の違反として検出されました。そこで、「案件を消すときは何をセットで消すか」を規約にしました。
3. AIが生む作業ファイルを隔離した ブラウザを自動操作させると、スクリーンショットや途中の記録が大量に残ります。数えたら456件・約86MBあり、専用フォルダに退避するルールにしました。
次回：税理士は毎月の帳簿のどこを見るか
次回は、当法人の中でいちばん規模の大きい仕組みを紹介します（近日公開）。マネーフォワード クラウド会計と連携して月次・決算のチェックを行うスプレッドシート群と、その結果をAIが判断して報告書の下書きを作る、2階建ての仕組みです。
シリーズ
- e-Taxの控えを共有ドライブへ自動振り分けし、Backlogで報告する仕組み
- AppSheet（スプレッドシート）×GAS×Backlogで顧問先管理とタスク起票を自動化した話
- 自動化で起きた3つの事故と、壊れにくい設計に変えるまで（本記事）
- 税理士は毎月の帳簿のどこを見る？マネーフォワード連携の自動チェックとAIの2階建て（近日公開）
- Backlogで頼むと、AIが申告書の入力と仕訳チェックを進め、税理士が確認する仕組み（近日公開）
