自分の職場の事務業務をAIエージェントで置き換えていく話【設計編】

こんにちは、Chiapuruです。

毎年4月になると、同じような質問が飛んでくる。

「この手続き、どこに提出すればいいですか？」
「この場合はどの処理を使えばいいですか？」
「前年度はどうやっていましたか？」

答える側は毎回同じことを説明する。引継書を渡しても、読み込むまでにまた時間がかかる。担当者が変わるたびに暗黙知がリセットされ、また一から積み上げる。

これが毎年繰り返されている。

そこで取り組みを始めた。会計業務を工程別のAIエージェントに分解し、Claude Codeをオーケストレーターとして動かすというシステムだ。

なぜ会計業務を選んだか

会計業務はAIエージェント化に向いている。理由は3つ。

1. ルールが明文化されている
規程・様式・上限金額・期限——これらは文書として存在する。AIに「覚えさせる」ベースが整っている。

2. 判断が定型化できる部分が多い
「この金額なら随意契約」「この宿泊費は規程超過」という判断は、条件分岐として表現できる。

3. 属人化のダメージが大きい
担当者異動のたびに業務品質が下がり、引継期間に時間とストレスがかかる。ここに効いてほしい。

システム全体の構造

オーケストレーターが一つと、専門エージェントが六つ。

オーケストレーター（Claude Code）
      │
      ├── 総括エージェント    ← 分担管理・全体状況集約
      ├── 予算管理エージェント ← 予算配分・執行・アラート
      ├── 収入管理エージェント ← 収入記録・計画照合
      ├── 旅費管理エージェント ← 精算・旅費規程チェック
      ├── 謝金管理エージェント ← 源泉徴収計算・支払処理
      └── 物品役務エージェント ← 調達区分判定・検収

オーケストレーターは「どのエージェントに何を頼むか」だけを判断する。「今月の旅費精算を処理して」と言われたら旅費エージェントへ委託。「月次の収支サマリーを作って」なら全エージェントからデータを収集して統合する。

各エージェントは AGENT.md というファイルに定義してある。Claude Codeに読み込ませると、そのエージェントとして動く。

ディレクトリ設計がそのまま組織図になった

業務システム/
├── CLAUDE.md              # オーケストレーター定義・共通セキュリティルール
├── 総括/
│   ├── AGENT.md           # 総括エージェント定義
│   └── 分担表/            # 誰が何をやるかの管理ファイル
├── 予算/
│   ├── AGENT.md
│   └── R8fy/              # 令和8年度データ
├── 収入/
│   ├── AGENT.md
│   └── R8fy/
├── 旅費/
│   ├── AGENT.md
│   └── R8fy/
├── 謝金/
│   ├── AGENT.md
│   └── R8fy/
├── 物品役務/
│   ├── AGENT.md
│   └── R8fy/
└── shared/
    └── R8fy/              # エージェント間データ共有

年度ごとにディレクトリを切るのは、会計業務の「年度をまたいでデータが混ざってはいけない」という性質そのままだ。R8fyはひとつの年度コンテナになる。

セキュリティ設計でいちばん時間をかけた部分

業務のAI化で最も慎重に考えたのがここだ。

会計業務には個人情報が絡む。氏名・口座番号・マイナンバー・契約相手先。これをそのままAIに渡すのは論外だ。

私たちの設計方針はシンプルにした。

エージェントは「計算と判定」だけ担う。「誰のデータか」を解決する部分は、人間側（台帳・マスタ）に置く。

エージェントへ渡してよい	渡してはいけない
申請番号・処理番号	氏名・住所・生年月日
金額・区分・年月	口座番号・マイナンバー
予算コード・科目コード	契約相手先の固有名称

エージェントは「支払金額50,000円 → 源泉徴収税額5,105円、差引44,895円」という計算はする。でも「誰に払うか」はエージェント内部に持たない。

こう設計すると、エージェントが万が一誤動作しても、個人情報の漏洩リスクを切り離せる。また、ログにも個人を特定できる情報が混入しない。

✅ 正しいログ:
{ "日付": "2026-04-30", "科目コード": "旅費-国内", "金額": 15000, "申請番号": "RYH-2026-088" }

❌ 禁止のログ:
{ "日付": "2026-04-30", "科目コード": "旅費-国内", "金額": 15000, "氏名": "山田太郎" }

すでに動いていること

旅費規程チェック

入力: 宿泊費 16,000円・目的地区分「東京」
出力: 東京基準（上限14,000円）を2,000円超過しています

謝金の源泉徴収計算

入力: 支払金額 50,000円
出力: 源泉徴収税額 5,105円 / 差引支払額 44,895円

調達区分の自動判定

入力: 契約金額 120万円・区分「役務」
出力: 随意契約（3者以上見積が必要）

どれも「計算ルールを定義すれば動く」タイプの業務だ。これまで担当者がマニュアルを参照しながら手で計算していたものが、番号と金額を入れるだけで出てくる。

既存の引継書をそのまま活かした

エージェントを作る前にやったこと——それが既存ドキュメントのデジタル化だ。

過去の担当者が11シートにわたってExcelで引継書を残してくれていた。これをAIに渡して、章立てされたMarkdownマニュアルに変換してもらった。

変換前:

Excelのセル結合多数。口語体の注記が随所に混在。
「前年度との金額で大きな乖離があると、電話が来ます」
「毎年、とりまとめ担当者が変わって、様式も異なっている」

変換後: 月別業務フロー・処理の種類・規程チェック項目をMarkdownで構造化。

このマニュアルがそのままエージェントの知識ベースになる。

やってみてわかったこと

想定外によかった点: エージェントを「定義する」プロセスが、業務棚卸しになること。「このエージェントは何を受け取るか」を書き出す作業で、これまで曖昧だったフローが言語化された。

想定より大変だった点: 「何をエージェントに渡してよいか」の線引きを組織として決めること。技術的な実装よりも、このルール策定に時間がかかった。

今後の課題: 月次収支サマリーの自動生成、年度末の外部資金チェックリスト生成、引継書の差分更新。これらはまだ開発中だ。

さいごに

この取り組みの目標は「すべての業務をAIに置き換える」ことではない。

「担当者が変わっても、エージェントに聞けば最低限動ける」状態を作ることだ。

引継書を渡して「あとは読んでおいて」ではなく、「このエージェントに聞いてみて」と言える日を目指している。

運用しながら気づいたことは随時記事にしていく予定だ。

関連記事: