LITERAS AIを立ち上げて最初に決めたことは、「他社への提案より先に、自分たちの業務を変える」でした。創業1ヶ月、1人体制、月30〜50件規模。自社の経理業務を業務観察から畳んでいったプロセスを、時間・件数・工数の3軸の数字と、つまずきも含めて記録します。
1. 「自分たちが一番のクライアントです」
LITERAS AIを立ち上げて最初に決めたことは、「他社への提案より先に、自分たちの業務を変える」でした。
AIコンサルを名乗る会社が、自社の経理を手入力で回していたとしたら。それは、「AI化の方法は知っている、しかし自分では試していない」という状態です。私たちはその矛盾を避けたかった。顧客に「業務観察から始めましょう」と言うなら、まず自分たちが業務観察を受けるべきだ。そういう発想でした。
創業から2週間が経った頃、私は自社の経理業務を1日かけて観察することにしました。PoC設計の話をする前に、まず自社の業務フローを紙に書き出す。最初のクライアントは、自分自身だと決めました。
2. 業務観察の最初の1日——何を見て、どう仕分けたか
その日、私がやったことはシンプルです。経理に関係するすべての作業を、発生した順番に書き出す。「やること」ではなく、「実際にやっていること」を記録する。
書き出してみると、こんな一覧になりました。
- 取引先からのメール受信 → 請求書PDFをダウンロード
- ダウンロードしたPDFのファイル名を変更(日付・会社名・金額)
- 金額・振込期日・振込先口座をスプレッドシートに手入力
- 入力した内容を請求書と照合(目視)
- 月末に会計ソフトへ仕訳を入力
- 仕訳が正しいか、スプレッドシートと会計ソフトを行き来して確認
- 支払い済みか未払いかをスプレッドシートで管理(色塗りで区別)
- 月次の支出をまとめて経営判断用の一覧表を手動で作成
この段階で気づいたことがありました。「自分がやっている理由」を説明できない作業が3つあったのです。
ファイル名の変更は、後で検索するためと思っていましたが、実際には会計ソフトに取り込む時に改めて確認するので二度手間になっていました。スプレッドシートへの手入力と会計ソフトへの仕訳入力は、本質的に同じ情報を2カ所に書いているだけでした。色塗りによる支払い管理は、銀行口座の入出金明細を見れば分かることでした。
業務観察で見えてきたのは、「業務が複雑なのではなく、手順が整理されていなかった」という事実です。やっていることの半分近くは、「そういう習慣になっているから」続いていた作業でした。
3. 自社版・手放す業務リスト
観察の結果、私が作成した「手放す業務リスト」は次の7項目です。
前提:取引件数は月30〜50件規模の1人体制。使用ツール:会計ソフト(freee)、Claude、Google スプレッドシート。
| No. | 手放す業務 | 置き換え方法 |
|---|---|---|
| 1 | 受領請求書のファイル名手動変更 | ファイル名変換ルールをAIで自動処理。人が触らない |
| 2 | スプレッドシートへの金額・振込先の手入力 | AI補助による自動抽出と転記に置き換え |
| 3 | スプレッドシートと会計ソフトの二重入力 | 会計ソフトへの一元入力に統合し、スプレッドシートへの複製をやめる |
| 4 | 支払い済み・未払いの色塗り管理 | 銀行入出金データとの自動照合に変更。色塗りは廃止 |
| 5 | 毎月の経営用支出一覧の手作成 | 会計ソフトのレポート機能 + AI整形で自動生成 |
| 6 | 請求書の仕訳コードの判断 | ルールを5パターンに分類し、AI仕訳提案に委ねる |
| 7 | 紙領収書の管理(外出時の交通費・備品費) | スキャン → AI読取 → 即時仕訳候補出力のフローに変更 |
この7項目を「手放す」と決めた上で、残す業務を整理しました。残したのは「最終承認(仕訳が正しいかの人間判断)」と「例外処理(イレギュラーな取引の判断)」の2つだけです。
4. 実際にAI化した3つの業務——ビフォア/アフター
業務01:領収書・請求書の仕分けと記帳補助
ビフォア(月の状況)
- 処理件数:月40件前後(取引先・外注先・備品購入等が混在)
- 処理時間:月8〜10時間(受領 → 金額確認 → スプレッドシート入力 → 会計ソフト入力 → 照合の5工程)
- 工数の質:担当者(代表1人)が集中して行う必要があり、他の業務と並行しにくい状態
実施したこと
- 受領請求書(PDF・メール添付)をClaudeに読み込ませ、金額・振込先・期日・勘定科目候補を自動抽出
- 抽出結果をGoogle スプレッドシートに出力し、会計ソフトへのインポートデータ形式に変換
- 仕訳パターンを5種(外注費・通信費・消耗品費・旅費交通費・その他)に分類し、AI仕訳提案の精度を事前チューニング
- 最終承認(金額・勘定科目の確認)だけを人間が行う設計に変更
初期検証で見えた変化
| 計測軸 | ビフォア | アフター | 変化 |
|---|---|---|---|
| 処理時間 | 月8〜10時間 | 月1.5〜2時間程度 | 削減率75〜80%の見込み |
| 処理件数 | 月40件前後 | 月60件程度まで対応できる見込み | 同じ設計での処理余地 |
| エラー率 | 金額誤入が起きやすい | 確認工程で低減 | AI抽出後のレビューに集約 |
| 運用パターン | 月末まとめ処理 | 週2回・15分ずつ | 負荷分散 |
この業務が一番、「手放した感触」がありました。処理時間の削減もさることながら、「月末にまとめてやる憂鬱」がなくなったことが体感として大きかったです。
業務02:業務委託契約書の初稿生成
ビフォア(1件あたり)
- 処理時間:1件 2〜3時間(前回使ったWordファイルを探す → 修正箇所を特定 → 書き直す → 読み返す)
- 件数:月3〜5件(外注・パートナー契約が増加傾向)
- 工数の問題:契約書の法的チェックと文書作成が混在しており、どこまで自分でやるべきか境界が曖昧だった
実施したこと
- 定型パターンを5種(業務委託・NDA・顧問契約・利用規約・覚書)に分類
- 各パターンにあわせたプロンプトを整備し、Claudeで初稿を出力する手順を確立
- 法的に確認すべき4カテゴリ(支払条件・成果物帰属・損害賠償・解除条件)をチェックリスト化し、AI出力後に人間がこの4点だけ読む設計に変更
アフター
| 計測軸 | ビフォア | アフター | 変化 |
|---|---|---|---|
| 処理時間 | 1件 2〜3時間 | 40〜50分 | 削減率約70% |
| 月間対応可能件数 | 月5件程度 | 月15件対応可能 | 同じ時間で3倍 |
| 判断の質 | 作成と法的判断が混在 | 法的判断に集中 | 分離による集中力向上 |
業務03:社内情報整理
ビフォア(日次の状況)
- 情報の在処:Notion・メモアプリ・Googleドライブ・メール・口頭の記憶、の5カ所に分散
- 探索コスト:「どこに何があるか」を確認する時間が、1日あたり30〜60分発生していた
- 工数の問題:プロジェクト状況・取引先情報・議事録・契約情報が横断的に参照できず、都度ツールを行き来する必要があった
実施したこと
- AIメモリ構造(プロジェクトごとの構造化ファイル)を設計し、情報の一元管理ルールを確立
- 「このプロジェクトの現状を教えて」「この取引先との直近のやり取りを要約して」という形で自然言語での検索ができる状態を整備
- 新しい情報が発生したときの記録ルール(何を・どの形式で・どこに書くか)を5項目で標準化
アフター
| 計測軸 | ビフォア | アフター | 変化 |
|---|---|---|---|
| 情報探索コスト | 1日30〜60分 | 記録先を集約 | 週4〜5時間程度の削減余地 |
| 引き継ぎコスト | 口頭依存 | 構造化ファイルで再現可能 | 属人化の解消 |
5. つまずいたこと
うまくいかなかったこともあります。3つ書いておきます。
つまずき1:AI仕訳提案が「その他」を多用する問題
請求書の内容が多少あいまいなもの(たとえば、複数の作業が含まれる外注費請求)を読み込むと、Claudeが「その他」を選択する割合が高くなりました。最初の設定で「迷ったら外注費」とルール化していなかったため、毎回確認が必要な状態が続き、2週間ほど「本当に省力化になっているのか」と疑問を持ちながら使っていました。
ルールを「迷ったらこの勘定科目を選ぶ」という形で5パターン全部に例外処理を追記したことで解決しました。AIへの指示は、「迷ったらどうするか」まで書かないと精度が安定しないという学びでした。
つまずき2:契約書の初稿に「使えない条文」が入ってくる問題
Claudeが生成した契約書の初稿に、実態にそぐわない条文が複数入っていることがありました。「乙は本業務に関連して知り得た甲の秘密情報を、本契約終了後20年間は第三者に開示しない」という、実務ではまず使わない年数の設定がそのまま入っていたこともあります。
プロンプトに「日本の中小企業間の業務委託契約で一般的に使用される条件の範囲で作成」という制約を追加したことで改善しました。また、初稿をそのまま使うのではなく「雛形として4カテゴリをチェックする素材」として位置づけを変えたことで、精神的な依存リスクも下がりました。
つまずき3:情報整理の「書き方ルール」が守られない問題
自分1人でも、ルールは守れないことがあります。忙しい日はメモアプリに箇条書きで書いてそのままにする。スプレッドシートに書くべき数字をSlackのDMに書いてしまう。3週間後に「あの数字どこに書いたっけ」と探す羽目になりました。
対策は「書きやすさ」の改善です。構造化ルールを5項目から3項目に減らし、「とりあえずここに書けばいい」という場所を1つだけ作りました。完全なシステムより、続けられるシステムの方が価値があると気づきました。
6. 自社で実装してみて分かった3つのこと
1. AIは「迷い」に弱い。ルールで迷いを先取りする
AIへの指示があいまいだと、AIも迷います。「判断が難しいケースが来たら、こうする」というルールを人間側が先に設計しておく。これができていないと、AIの精度は安定しません。業務観察の段階で「例外処理」を洗い出すことが、AI実装の精度に直結しています。
2. 「手放す」と「自動化する」は別の決断
業務観察をしてみると、手放すべき業務とAIで自動化すべき業務は一致しません。手放すべき業務の一部は、そもそもやめてしまった方が早い。今回で言えば、「スプレッドシートへの手入力」は「AIで自動入力」に変えるより「スプレッドシート自体をやめて会計ソフトに一元化」する方が正しかった。自動化は、残すべき業務にだけ適用する。その判断の順序が重要です。
3. 数字は「削減時間」だけではない。「精神的コスト」が大きかった
月8〜10時間の作業を2時間程度まで短縮できる見通しが立ったこと以上に、「毎月末の憂鬱が減った」という変化が意思決定の質に影響しました。経理を気にしながら営業を考えるより、経理が回る見込みを持てている状態で営業を考える方が、判断の質が上がります。業務改善の効果は時間だけでは測れない、という当たり前のことを、自分で体験して実感しました。
7. 最後に——自社の業務観察を、試してみてください
このノートで書いたことは、創業1ヶ月の1人体制の会社が、自社の経理業務を対象に行った業務観察の記録です。大企業向けのプロジェクトではありません。取引件数30〜50件、使うツールはClaude・freee・Googleスプレッドシート。この規模でも、業務観察を先にやることで、実装の精度と定着のしやすさが変わりました。
業務観察は特殊な技術ではありません。「今日、自分がやっている業務を全部書き出す」それだけで始められます。書き出した後、「なぜこれをやっているか説明できないもの」が出てきたとき、そこが手放す業務の候補です。
自社の業務観察を試してみたい方は、まず45分の無料相談からどうぞ。「自社版・手放す業務リスト」を一緒に作る時間として使っていただけます。
本記事に記載している数字は、LITERAS AI自社の業務規模(取引件数月30〜50件・代表1人体制)を前提にした初期検証ベースの目安です。業務規模・システム環境・既存ツールの状況により、削減効果は異なります。