- 時間を食っているオフィス仕事の多くは、どのマニュアルにも書かれていない作業です。進捗の催促、データのコピー、ファイルの取りまとめなどです。
- ツールを買う前に、まずこうした作業を書き出してください。どこから始めるべきかがすぐにわかります。
- 1つの仕事の流れを最後までやり切るほうが、全部署に一斉に広げてどこでも成果が出ないよりずっと確実です。
システムを買う前に「見えない仕事」を洗い出す
各部署の責任者にチームの仕事を尋ねると、職務記述書どおりの答えが返ってきます。ところが実際に1日そばで見ていると、どの文書にも載っていない別の仕事が見えてきます。進捗の催促、システム間でのデータのコピー、ファイルの取りまとめです。実際に時間を食っているのはこちらの仕事で、システムが最も役に立つのもここです。
オフィスの仕事の多くは、業務手順書(SOP)に載っていません。ファイルをダウンロードして名前を変える、メールのデータをExcelに写す、チャットで進捗を尋ねる、最新版の書類を探す、送る前に書式を直す、といった作業です。経営層には最終的なレポートは見えても、そこに至るまでに何十回もデータが移し替えられていることは見えません。この見えない仕事はコストであり、ミスの発生源でもあるので、仕組みを作り直す対象に向いています。
業務の流れを1つ選びます。たとえばLead-to-Quote、Order-to-Cash、Invoice-to-Pay、Request-to-Approvalなどです。そして実際の案件を5〜10件追いかけ、誰がどの経路で何を受け取り、どこで同じデータを入力し直し、誰を待ち、どのルールを使い、どんな例外が起きたかを記録します。文書化された業務フロー図から始めてはいけません。実際の仕事は、たいてい別の道筋で進んでいるからです。
自動化の候補になるオフィスのサイン
- 同じデータを2回以上入力している
- 社員が受信箱やチャットを主なタスク一覧として使っている
- final_v7という名前のファイルや、複数のフォルダーに散らばったコピーがある
- 画面に情報がそろっていないため、承認者が同じことを何度も聞き返す
- チームが判断よりも進捗の確認に時間を使っている
- ミスの原因の多くが、バージョン、入力欄、送り先の間違いである
開発チーム向け · 技術指標
作業時間(Touch Time)、待ち時間(Wait Time)、エラー、引き継ぎの回数、滞留している仕事について、ベースラインを算出します。人の作業時間だけを測ると、顧客への回答が早くなる価値や、入金が早まる価値を見落としかねません。業務の流れのアウトカムは、「入力作業を減らす」ではなく「正しい見積書を1日以内に出す」のように決めます。
システムごとに役割がわかるようにAIオフィスを組み立てる
よくある失敗は、先にツールを買ってから使い道を探すことです。正しい順番は、明らかに時間を食っている仕事の流れを1つ選び、最初から最後まで本当に完結させてから、次の流れに広げることです。

AIは、メール、書類、メモのような構造化されていない言葉の扱いが得意です。一方で、価格のルール、与信限度額、税金、権限、参照番号は、答えが確実に決まるシステムに置くべきです。この2つははっきり分けます。AIは解釈と下書きに使い、重要なデータの確定にはルールエンジン、データベース、ERPを使います。
| 層 | 役割 | 管理のための質問 |
|---|---|---|
| Intake | メール、フォーム、ファイルを受け取る | どの経路を正式に認め、危険なファイルをどう防ぎますか? |
| Understand | 読み取り、分類し、データを取り出す | 原文と確信度を示せますか? |
| Rules | ID、価格、与信限度額、条件をチェックする | ルールはどのシステムから来ていて、誰が変更できますか? |
| Review | 例外を人に判断してもらう | 確認する人に、十分な理由と背景が見えていますか? |
| Action | システムを更新し、メッセージを送り、タスクを作る | 元に戻したり監査したりできますか? |
| Monitor | 品質、コスト、インシデントを監視する | アラートは誰が受け取り、SLAはどれくらいですか? |
仕事のステータスは、全員が共通に使う言葉として設計します。たとえばNew、Validating、Needs Information、Awaiting Approval、Completed、Exceptionです。全員が同じステータスを見ていれば、チャットで尋ねる必要はなくなります。システムには、止まっている理由、担当者、期限まで記録させます。「対応中」と表示するだけでは足りません。
例外だけを人が確認する(Review by Exception)
データがそろっていてルールも通る標準的な仕事は、そのまま速く流します。金額が合わない、新規の顧客、重複した書類、確信度が低いといった仕事は、どこがおかしいのかと取りうる選択肢を添えて、専用のキューに入れます。確認する人が毎回すべての文章を読み直すようではいけません。そうなると自動化は、入力作業を非効率な確認作業に置き換えただけになります。
AIオフィスの姿がよくわかる3つの業務の流れ
Meeting-to-Action
システムがメモや文字起こしを受け取り、論点、決定事項、タスク、担当者、期限をまとめます。参加者は重要な項目だけを確認してから、タスク管理システムに登録します。翌週にはAIが進捗をまとめ、遅れそうなタスクを指摘するので、スライドを作り直す必要はありません。目指すのはきれいな議事録より、アクションの抜け漏れをなくし、進捗確認の会議を短くすることです。

Invoice-to-Pay
書類は共通の受付窓口に届きます。システムがファイルと取引先をチェックし、AIで請求書番号、日付、明細、条件を読み取ったうえで、ルールに従って発注書(PO)、入荷記録、税金、銀行口座と照合します。問題のない請求書は承認キューへ進み、重複や金額の不一致がある請求書は、差異を示して担当者に回します。承認が済んでから初めてERPに記帳し、支払日を設定します。どの段階にも監査証跡と、職務分掌に基づく権限があります。
Customer Request-to-Resolution
メールやフォームは分類され、顧客や製品と結びつけられます。AIは承認済みのナレッジベースから回答を下書きします。解約、契約、個人データに関わるケースは専門の担当者に回します。システムはSLAを追跡し、繰り返し起きている問い合わせの理由をまとめて、プロダクトチームが根本原因を直せるようにします。こうしてサービスのデータは、片づけるだけの受信箱で終わらず、改善の手がかりになります。
業務の流れを自動化する前に確かめること
- 正となるデータ(Source of Truth)はどこにあり、管理する人は決まっているか
- 標準的なケースは全体の何%か
- 多い例外の上位5つは何か
- お金、権限、顧客、法律に影響するのはどの段階か
- 承認する人はどんな証拠を見る必要があるか
- システムが止まったら、どうやって仕事を続けるか
3つの流れに同時に手をつけるのはやめましょう。価値、データ、責任者が最もそろっている流れを選びます。そこで学んだことを生かして、ID管理、書類の受け付け、承認、監査、監視といった再利用できる部品を作っておけば、次の流れは速く進み、似たシステムを何セットも作らずに済みます。
試験導入から日常業務までの12週間計画
| 期間 | やること | 次に進む条件 |
|---|---|---|
| 1〜3週目 | 実際の仕事を追い、ベースラインを取り、ステータスを設計する | アウトカム、責任者、データ、リスクが明確になっている |
| 4〜6週目 | 下書きまたは読み取りだけを行うプロトタイプを作る | 通常のケースと例外のテストセットに合格する |
| 7〜9週目 | 小さなチームで試し、確認キューとつなぐ | 品質と処理時間が基準内に安定して収まっている |
| 10〜12週目 | 業務手順書を改訂し、研修とサポートを用意して、実際の仕事を移す | 監視、フォールバック、責任者がそろっている |
開発チーム向け · 技術的な詳細
初期の段階では、AIには下書きや提案を作らせるだけにして、自分で送信させないようにします。オーバーライドとその理由は毎回記録します。結果が安定したら、標準的なケースに限って範囲を広げます。予算上限とレート制限を設け、データや外部サービスが変わったときに通知が届くようにします。セキュリティレビューはデータの種類に応じて行い、試験導入を理由にポリシーを省略しないでください。
開発チーム向け · 技術的な詳細
本番稼働後は、計画に沿って並行して使っていた経路を閉じます。チームがExcelと新しいシステムの両方に入力し続けていると、生産性が下がり、データの食い違いも起こります。経路を閉じるときは、いきなり告知するのではなく、本番切り替え日、データ移行、手作業でのフォールバック、サポートを用意します。最初の1か月は毎週ダッシュボードを確認します。見る項目は、処理量、リードタイム、P90、例外、エラー、未処理件数、コスト、利用の定着度です。
よいAIオフィスでも、人がいなくなるわけではありません。人の役割が、データのコピーや進捗の追いかけから、ルールを決め、例外を判断し、顧客と話し、業務プロセスを改善する仕事へと移ります。だから仕事が速くなっても品質と責任の所在は保たれ、誰にも説明できないブラックボックスにはなりません。
FIELD PATTERN · 小さく始めて、最後までやり切る
タスクを1つずつ自動化せず、短い流れを1本まるごと自動化する
メールの要約を手伝わせるだけでは、たいてい時間は戻ってきません。社員は結局、要約をExcelに写し、チャットで知らせる必要があるからです。「購買依頼を受けてから承認できる状態になるまで」のように、始まりと終わりのある流れを選んでください。対象が1つの商品カテゴリーだけでも、つながっていない自動化を10個作るより完結した成果になります。

自動化のはしご
- 入ってくるデータの形式をそろえる
- AIに下書きや分類をさせる
- ルールと確認キューを加える
- 品質が安定してからアクションをつなぐ
- フォールバックが整ったら古いやり方をやめる
ヒント:システム連携を作る前に、例外を20件印刷して壁に貼ってみてください。それぞれの案件を誰に回すのかチームが答えられないなら、新しいシステムは混乱を速く届けるだけです。
知識を、現場で使える問題解決の仕組みへ
問題の核心
オフィスの仕事が遅いのは、AIがないからではありません。データに責任者がおらず、ステータスがはっきりせず、仕事がメール、Excel、チャットを何度も行き来しているからです。
段階を踏んだ解決の進め方
- 依頼が届いてから成果が出るまでのサービスブループリントを描き、価値を生まない引き継ぎを見つける
- 正となるデータ、ステータス、ルール、例外、承認者を決める
- アクションをつなぐ前に下書き優先で試験導入し、フォールバックを用意したうえで古いやり方をやめる
人が各段階で仕事を追いかけなくても、データが自然に流れるようにする
オフィス業務の自動化でつまずく原因は、AIモデルよりも、散らばったデータ、はっきりしないステータス、部署ごとに違う言葉づかいにあることがほとんどです。DNA Makerは実際の利用者と一緒にサービスブループリントを作り、依頼が届いてから成果が出るまでを順にたどります。そのうえで、どれが正となるデータなのか、どのルールは100%正確でなければならないのか、どんなケースを人に回すべきかをはっきりさせていきます。業務プロセスを私たちが推測で決めることはしません。メールやファイル、社員の経験の中にある知識を、確認と改善ができるワークフローに変えるお手伝いをします。
こうして整理ができたら、メール、書類、CRM、ERP、既存システムをAPIでつなぐWebアプリケーションを設計・開発できます。書類を読み、分類し、回答を準備するAIエージェントを組み込み、ルール、承認、例外キュー、通知を1つの画面体験にまとめます。DNA Makerのチームは、最初に取り組む業務の流れの選定、プロトタイプの作成と利用者テスト、アーキテクチャの設計、開発から、本番切り替えと稼働後の運用まで支援します。社内でいまも「この仕事は誰のところにあるのか」と頻繁に聞き合っているなら、一緒に仕組みを設計し始めるのにちょうどよい題材ですので、ご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
この表は、経営層、業務の責任者、開発チームが同じ言葉を別々の意味に取らずに話し合うためのもので、暗記する必要はありません。意味と例に加えて、右端の質問も読んでください。こうした質問から、開発を始める前に隠れていた範囲、リスク、コストが見えてくることがよくあります。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| System Integration | 複数のシステムをつなぎ、データが途切れずに流れるようにすること | メールが届くと、承認システムに案件が作られる | データを管理するのはどのシステムですか?連携できなくなったらどうしますか? |
| Source of Truth | 全部署が共通のよりどころにする、正となるデータ | 価格は古いファイルではなく、ERPから読み取る | 正となるデータはどこにあり、誰に変更する権限がありますか? |
| Exception Queue | 人の判断が必要な異常案件を集めたキュー | 金額の合わない請求書が確認キューに送られる | 最も重要な例外はどれですか?SLAはどれくらいですか? |
| Webhook | イベントが起きたときに自動で送られる通知 | リード(見込み客)のステータスが変わると、CRMがすぐにシステムへ知らせる | 通知が重複したり届かなかったりしたとき、仕事の重複をどう防ぎますか? |
| Fallback | メインのシステムが使えないときの代わりの作業方法 | 仕事をいったんキューに保存し、後で処理する | システムが止まったとき、業務はどのような方法で続けますか? |
