- 社内の仕事が遅れる原因は、手順の難しさより、メール、チャット、何バージョンもあるファイルをまたいで確認して回る手間にあります。
- AIを入れる話の前に、すべての仕事のステータス、担当者、次の手順がはっきりわかるシステムを用意します。
- この土台があって初めて、AIが本当に役に立ちます。依頼を読み、種類を分け、必要な情報を集め、期限を過ぎる前に知らせてくれます。
従来のWebサイトやアプリの限界
ある顧客の依頼が今だれのところで止まっているのかを知りたければ、グループチャットを開き、メールをさかのぼり、さらに2人に電話で聞かなければなりません。原因は社員の努力不足ではなく、業務の流れが見えないことにあります。
社内にシステムがいくつもあるのに、社員は今もチャットで仕事を追いかけています。どのシステムも自分の担当部分しか見えていないので、部署をまたぐ仕事には、最初から最後まで責任を持つ人がいません。
社内の仕事の多くは、特定の手順が難しいわけではなく、メール、チャット、スプレッドシート、いくつものシステムを行き来するせいで遅れます。ほかの人がどこまで進めたのかがわからないため、進み具合を尋ね、同じファイルを何度も送り、目の前の問題を個人的なメッセージでしのぐことになります。仕事が回っているのは記憶力のいい人がいるからで、業務の流れが見えているからではありません。
開発チーム向け · 技術的な詳細
AI Internal Operations Appでは、賢さを足す前に、各タスクのState、Owner、Dependency、Next Actionを明確にします。そうすればエージェントは、依頼の読み取り、分類、情報の収集、リマインド、判断材料の準備を手伝えます。メッセージの数だけが増え、正式なレコードがどこにあるのか誰もわからないシステムにもなりません。
| 従来の形 | 新しい世代のAIプロダクト |
|---|---|
| フォームを受け付け、ステータスを記録し、ダッシュボードに表示する | エージェントが依頼を細かいタスクに分け、複数のシステムからデータを取り出し、SLAに沿って優先順位をつけ、承認に回し、仕事が止まっている理由を説明する |
エージェントが調整役を果たせるのは、すべての作業項目（Work Item）に1つのステータスと1つのIDがあるときです。仕事の進む道筋はワークフローの仕組みが管理し、AIは文章の解釈とデータの準備を手伝います。この2つの役割を分けておけば、AIの自然な言葉での回答が、根拠もなく大事なステータスを書き換えることを防げます。
ビジネスに使える新しい機能
AIを入れる前に直すべきなのは、工場の作業指示書のように、すべての仕事のステータスと担当者をはっきりさせることです。それができて初めて、AIが本当に役に立ちます。届いた依頼を読み、どの種類の用件かを判断し、関係する情報を添付し、期限を過ぎそうな用件を前もって知らせます。
プロジェクトの形
システムは業務用の作業スペースになります。フォーム、メール、チャットから依頼を受け取り、全員が共有する作業項目を作ります。関係者は同じタイムライン、書類、担当者、SLA、例外を見ることになります。AIは整理されていない文章を確認できるデータに変えますが、大事なポイントでの確認を飛ばすことはしません。
備えておきたい機能
機能としては、依頼の自動受け付け、自動分類、重複の検出、チェックリスト、承認、SLAのリマインド、例外キュー、ステータスのまとめ配信、システムをまたいだ更新などが考えられます。マネージャー向けの画面には、見栄えはよくても次の行動につながらない集計グラフを置くより、止まっている仕事、その理由、必要な判断を中心に表示します。
支える技術
システムの中心は、ワークフローエンジンと、ステータスを保存するストアです。ERP、人事システム（HRIS）、CRM、文書管理、メールとはAPIやイベントでつなぎます。AIは解釈と要約に使い、ステータスの変更、権限、承認の条件には、あらかじめ決めたルールを使います。キュー、リトライ、冪等性（Idempotency）も欠かせません。同じ命令が重なったときに、取引が二重に作られたり、二重に支払われたりしないようにするためです。
組織にとっての効果
社員は仕事を追いかけたりファイルを探したりする時間が減ります。上司はSLAを過ぎる前にボトルネックに気づけ、経営層は問題の原因が人員や処理能力の不足なのか、データの欠けなのか、承認ルールなのかを見分けられます。長い目で見ると、調整役の頭の中にあった知識が、教えたり、確認したり、改善したりできる業務プロセスに変わり、例外に対応する余地も残ります。
- 普段の言葉で書かれた依頼を構造化データに変える受け付け機能
- 共通のステータスをもとに、システムや部署をまたいで動きを調整するオーケストレーション
- 人が判断すべき用件だけを見せる、例外を優先した画面設計
- ログからボトルネックと直すべきルールを見つけ出す、業務プロセスの学習
架空のケース
具体的な利用場面
新しい支店を開く依頼が、IT、購買、人事、施設の仕事に分けられます。エージェントは足りない情報を確認し、依存関係に沿ってタスクを作り、クリティカルパスが遅れたら上司に知らせます。
もう1つの架空のケースとして、新しい取引先（ベンダー）の登録を考えます。購買、経理、法務、予算の責任者の確認を通す必要があります。システムは依頼を読み、取引先の種類に応じて書類を確認し、部署ごとのタスクを作って、依存関係を表示します。納税者番号が一致しなければ、AIは次へ回す前に追加の情報を求めるので、各部署が確認を始めてから差し戻しが起きることが減ります。
急ぎで取引先を登録しなければならないといった例外が出たときは、システムがその案件を例外用の流れ（Exception Lane）に分け、理由、リスク、承認権限のある人を記録します。特別なケースを通常のフローに無理に通そうとはしません。そのため経営層は、例外がなぜ頻繁に起きるのか、社内規定や人員体制のどこを直すべきかを把握できます。
エージェントより先にステータスを決める（State-before-Agent）
AIを加える前に、ステータス、担当者、ステータスを切り替えるルールを決めます。
仕事がどの段階にあるのかをシステムが把握していなければ、エージェントはメッセージを増やすだけです。
範囲、リスク、効果の測り方
開発チーム向け · 技術指標
Idempotency、権限、手作業での復旧手段がない自動化は、ミスをあっという間に広げます。区間ごとのCycle Time、Waiting Time、Rework、Exception Rate、チャットで追いかけなければならなかったタスクの数を測ります。システムがチケットを早く閉じていても、社員がシステムの外で仕事をしているなら、その数字は実際の生産性を表していません。
冪等性、権限、監査ログがそろわないうちは、エージェントに重要なデータを変更させてはいけません。優先順位のつけ方は透明にし、特定の人や部署を不公平に扱わないようにします。
- Discover：実際の業務を追い、通常のケースと例外の実例を集めます。
- Assist：人が主導権を持ったまま、AIに下書きや提案をさせます。
- Act：テストセットに合格してから、ツールを1つずつ使えるようにします。
- Scale：監視、フォールバック、コスト管理、責任者がそろってから範囲を広げます。
取引が重複して作られる、担当者のいないままステータスが止まっている、社員が日常的にシステムの外でデータを直している、といった状態なら、自動化を止めます。こうした問題は、モデルの能力を上げる前に、ワークフローとシステム連携を直さなければ解決しないことがほとんどです。
BUSINESS & PRODUCT READINESS
エージェントに仕事を任せる前に、ステータス、担当者、依存関係を見えるようにする
開発チーム向け · 技術的な詳細
Operations Agentには、責任者のいない業務プロセスを直せません。ステータスが「対応中」しかなければ、システムはそれがデータ待ちなのか、承認待ちなのか、別のシステム待ちなのかを判断できません。まずState Model、Entry/Exit Criteria、Dependencyを作り、そのうえでエージェントに依頼の変換、キューの整理、ボトルネックの説明を手伝わせます。
開発チーム向け · 技術指標
Happy Pathだけを設計せず、実際のケースからException Catalogを作ります。繰り返される操作のIdempotency、Stateを変更できる権限、システム連携が止まったときのFallbackを決めます。Orphan TaskとException Ageを測り、部署の間で仕事が消えていないかを確認します。
まずは1種類の仕事について状態遷移図を描きます。どの出来事でそのステータスに入り、どんな根拠がそろえば次へ進めるのか、誰に判断の権限があるのかを書き込みます。次に例外カタログを作り、フローを追加で設計すべきケースと、人の判断に任せるべきケースを分けます。
エージェントに与える権限は、役割に必要な分だけにします。たとえば書類を読み、依頼を下書きすることはできても、承認やマスターデータの修正は、確認者のついた別のツールで行います。データ品質と復旧の仕組みが信頼できるようになるまでは、1つのチームの1つの業務の流れにとどめ、そのあとで組織全体のプロセスをつなぎます。
最初から最後までの成果に責任を持つのは誰か
いちばんあいまいなステータスはどれか
二重に実行してはいけない操作はどれか
システムが止まったとき、仕事はどこで止まるか
部署をまたぐ仕事を、1本の見える流れにする
DNA Makerは、業務プロセスの責任者や現場の担当者と一緒に、サービスブループリント（業務全体の設計図）を作るところから始めます。実際のケースを追いかけ、受け付け、ステータス、引き継ぎ、承認、例外が見えるようにします。自動化を考える前に、価値を生まない手順を減らすお手伝いもします。新しいシステムが、複雑なままの古いプロセスを速く回すだけにならないようにするためです。
プロダクト・UXチームは、作業キュー、例外ビュー、関連情報のパネルを設計し、どの役割の人も判断に足る情報を見られるようにします。エージェントを置くのは、構造化されていないデータを読む工程や、複数のツールを連携させる工程です。業務ルールは、確認できるワークフローの中に置きます。
DNA Makerは、チャットや人の記憶の中にある仕事を、サービスブループリント、ステータスのモデル、役割と権限、システム連携図に落とし込みます。社内規定と例外を決めるのは、引き続きお客様のチームです。私たちは、そのルールが、現場の人が実際に使えるキュー、承認、監査の画面に表れるようにします。
社内Webアプリ、ワークフローエンジン、AIによる受け付けと調整の機能、ダッシュボード、コネクターを、ルールやSLAを変更できる管理画面とあわせて開発できます。試験導入では1つの作業項目を最初から最後まで追い、作業時間（Touch Time）と待ち時間（Waiting Time）を分けて測ります。現場のユーザーにも話を聞き、システムが調整の手間を減らしたのか、負担を別の画面に移しただけなのかを確かめます。
社内Webアプリ、ワークフローエンジン、AIオーケストレーター、役割と権限、システム連携、通知、管理者向けダッシュボードを、監査、リトライ、監視の仕組みも含めて開発できます。アーキテクチャは、部品を次の業務の流れにも再利用できるように設計します。
全員がチャットで追いかけている部署横断の仕事があれば、業務の流れを1つ選び、止まっている案件を持ってご相談ください。本格的なプラットフォームに投資する前に、DNA Makerが現状と今後の業務フローを描き、作業キューのプロトタイプを作ります。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
この表の用語を使えば、ステータス、処理の重複、SLA、複数システムの調整について、チーム内で認識をそろえて話せます。エージェントに権限を渡す前に、ワークフローに通常の流れ、例外、復旧の手段がそろっているかを確認するときにも使ってください。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Orchestration | 複数の工程と複数のシステムを、順序立てて連動させること。調整を担う層は各工程のステータス、依存関係、失敗を把握し、プロセス全体をやり直さずに、止める、再実行する、人に回すといった判断ができなければならない | 依存関係の順に、支店開設の作業を進める | フロー全体に責任を持つのは誰ですか？ |
| State Machine | 仕事のステータスがどう切り替わるかを決めるルール。ステータスと切り替わり方がはっきり決まるので、仕事が手順を飛ばしたり、担当者のいない状態で止まったりするのを防げる | 下書き → レビュー → 承認済み | 間違ったステータスを元に戻せますか？ |
| Idempotency | 同じ命令が繰り返されても、結果が二重にならないようにする性質（冪等性）。タイムアウトのあとにシステムが命令を再実行するときに効いてきて、発注書が2回作られたり、代金が2回引き落とされたりするのを防ぐ | リトライしても発注書（PO）が2枚作られない | 重要な操作はすべて、二重実行を防げるようになっていますか？ |
| SLA | あらかじめ合意したサービスの提供時間。サービスを受ける側にとって意味のある時間を測り、情報待ちの時間と作業時間を分け、期限を過ぎたときにどうなるかを決めておく | IT部門が4時間以内に依頼を受け付ける | SLAを過ぎそうなとき、誰に知らせますか？ |
| Workflow Engine | ルールと仕事の流れを実行するシステム。ルール、ステータス、待ちの仕事、引き継ぎをエンジン側で管理するので、条件をすべて画面やプロンプトに埋め込まなくても、プロセスを変更できる | 金額に応じて承認者に回す | ルールは誰が変更できますか？ |
関連資料（原典）：https://openai.github.io/openai-agents-js/guides/multi-agent/