申請・承認をSlack／Teamsにつなぐ設計：既存ワークフローを活かすAPI連携

ZeroOps (ゼロオプス) は、運用の手間を可能な限り減らす思想ですが、これを実現するために既存システムを全刷新する必要はありません。既存の堅牢なワークフローシステムの上に、チャット完結のユーザー体験を統合するアプローチが現実的です。

Human-in-the-Loop (人間がループに入る) は、自動化プロセスの中に「人の判断」を組み込む設計です。チャットツールを「判断の場」に特化させることで、意思決定のスピードを最大化します。

多くの企業で「申請」はボトルネックです。しかし、ワークフローシステム（WF）の刷新は、稟議規定の改定や監査対応など、膨大なコストがかかります。

そこで提案するのが「WFはそのまま、UIだけチャットにする」というアプローチです。

承認の遅れは、承認機能そのものではなく、通知を見落とす、別システムへのログインが必要、スマートフォンで内容を確認しにくい、といった操作経路に原因がある場合があります。既存システムを置き換える前に、申請から承認までの時間を計測し、どの工程で滞留しているかを確認します。チャット連携は、正本と監査ログを既存ワークフロー側へ残せる場合に候補となります。

既存のワークフローツール（SmartHR, ジョブカン, 楽楽精算, ServiceNow 等）を「データベース＆承認エンジン」として利用し、チャットを「リモコン」として機能させる構成です。

この構成の最大のメリットは、「チャット側にはデータを永続化しない」点です。万が一チャットのログが消えても、正本データは既存WF側に残っているため、監査上のリスクが非常に低くなります。

既存システムを活かすことで、バックエンドの実装工数を大幅に削減できます。

1. 対象業務選定：既存WFの中で「承認頻度が高く、スマホで判断可能」なもの（経費、勤怠、アカウント申請）を選ぶ。
2. WFツール API調査：「申請一覧取得」「承認実行」のAPIが公開されているか確認する（非公開ならRPA連携などを検討）。
3. 認証方式の設計：チャットユーザーIDと、WFツールのユーザーIDをどう紐付けるか（Mapping Table）を設計する。
4. 通知トリガー実装：WFツールからのメール通知などをフックし、チャットへカード（Block Kit）を送信する。
5. 承認UI構築：「WFのリンク」だけでなく、チャット上で「承認/否認」ボタンを配置する。
6. API Action実装：ボタン押下時に、WFツールの承認APIを叩くFaaSを実装する。
7. 同期確認：API実行後、WF側のステータスが確実に変わったことを確認し、チャット側の表示を「承認済」に更新する。

最初はノーコードツール（Zapier/Make）で「メール通知→Slack投稿」の部分だけを作り、承認ボタンの実装後からコード開発（FaaS）に移行するのもスムーズです。

UXのゴールは「WFツールの画面を開かせない」ことです。

• 要約の表示：申請本文が長文でも、LLMで「要約：〇〇の件、金額：¥50,000、期限：明日」とサマリして通知する。
• 文脈の維持：関連する資料（見積書PDFなど）へのリンクは残すが、プレビューで判断できるようにする。
• ワンタップ承認：ログインセッションが切れている等の理由で「承認に失敗」しないよう、APIトークンの有効期限管理を裏側で自動化する。

「セキュリティが心配」という声に対してこそ、Wrapper方式が有効です。

Wrapperが完成すれば、次は「申請（入力）」側の改革です。

このように、DXロードマップの先にある「従業員体験（EX）の向上」は、既存システムの画面を捨て、対話インターフェースに移行することで実現します。

導入と運用における最終確認リストです。