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

ZeroOpsは、運用の手間をできるだけ減らす考え方です。そのために既存のシステムをすべて作り直す必要はありません。今使っているワークフローシステムはそのまま残し、通知の確認から承認までをチャットの中で済ませられるようにする方法が、取り組みやすい選択肢です。

Human-in-the-Loop（HITL）は、自動化した処理の流れの中に、人が判断する工程を組み込む設計です。チャットツールを承認などの判断を行う場として使うと、承認者が申請に気づいてから判断するまでの時間を短くできます。

申請と承認の待ち時間は、多くの企業で業務が滞る原因になっています。一方で、ワークフローシステム（以下、WF）を入れ替えるには、稟議規程の改定や監査への対応など、大きな費用と手間がかかります。

そこでこの記事では、WFはそのまま使い、通知と承認の操作だけをチャットに移す方法（WFラッパー）を取り上げます。

表の評価は目安です。WFラッパーの「監査・統制」は、API経由の承認操作が承認者本人の操作として既存WFに記録されることを、製品の仕様と契約プランで確認できた場合に限ります。記号の評価だけで統制が保たれるわけではありません。

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

既存のワークフローツール（SmartHR、ジョブカン、楽楽精算、ServiceNowなど）を、データの保存と承認の処理を担う仕組みとしてそのまま使い、チャットからはその操作だけを行う構成です。

この構成では、申請データ・状態・正式な承認記録の正本を既存WFに置き、チャット側には正本となるデータを持たせません。記録は次のように分けます。

すべての記録をチャットへ集める構成や、チャットの履歴だけで監査要件を満たす構成は前提にしません。保存先、保存期間、閲覧権限、変更履歴の管理、チャットでの操作と申請・承認記録の対応関係は、既存WFの機能と、自社の監査・運用要件に照らして確認します。

既存システムを活かすと、バックエンドとして新たに作る部分を大きく減らせます。最小の構成は、次の手順で作ります。

1. 対象業務の選定：既存WFの申請のうち、承認の回数が多く、スマートフォンで判断できるもの（経費、勤怠、アカウントの申請など）を選びます。
2. WFツールのAPIの調査：申請一覧の取得と承認の実行（否認・差し戻しも扱うならその操作）のAPIが公開されているか、API経由の操作がWFにどう記録されるか、APIの利用制限を確認します。APIが公開されていない場合は、RPAでの連携などを検討します。
3. 認証方式の設計：チャットのユーザーIDとWFツールのユーザーIDを対応づける表を設計します。API実行時に承認者本人の権限で処理されるかも確認します。連携用の共通アカウントで操作すると、WFの履歴に本人の承認として残らない場合があります。
4. 通知の仕組みの実装：WFツールからのメール通知などをきっかけに、チャットへ申請内容のカード（Block Kit）を送ります。
5. 承認画面の構築：WFへのリンクに加えて、チャット上に「承認」ボタン（APIが提供していれば「否認」も）を置きます。APIが提供していない操作は、WF画面へのリンクから行います。
6. 承認処理の実装：ボタンが押されたときに、WFツールの承認APIを呼び出す処理をFaaSで実装します。
7. 状態の同期の確認：API実行後、WF側の状態が変わったことを確かめてから、チャットの表示を「承認済」に更新します。

最初はノーコードツール（Zapier / Make）で、メール通知をSlackに投稿する部分だけを作り、承認ボタンを実装する段階からFaaSでの開発に移る進め方もあります。

目指すのは、通常の承認であれば、WFツールの画面を開かずに判断できる状態です。原文や詳細が必要なときは、WFの画面へすぐ移れるようにします。

• 判断に使う項目の表示：申請の対象・金額・期限などは、WFに入力された項目の値を、そのまま定型文で通知します（例：「〇〇の件 / 金額：¥50,000 / 期限：明日」）。AIを使わなくても、通知と承認の連携は成り立ちます。
• AIによる要約（任意）：長い申請本文をLLMで要約して添えるのは、そのAIサービスと用途が対象の情報の区分で許可され、契約・学習への利用・保存・アクセス権などの条件を確認できた場合に限ります。渡す内容も、要約に必要な範囲に絞ります。チャットに表示する項目を絞っても、LLMへ渡した入力まで制限したことにはなりません。金額・期限・対象は要約ではなくWFの値で確認し、権限付きのWFリンクから原文も開けるようにします。条件を満たせない場合は要約を使わず、WFの項目の値による定型の通知と、WF画面での詳細の確認にします。入力条件の決め方は企業のAI利用ルールブックで扱っています。
• 関連資料へのリンク：関連する資料（見積書のPDFなど）へのリンクを添え、プレビューでも内容を確かめられるようにします。
• ワンタップでの承認：ログインの有効期限切れなどで承認に失敗しないよう、APIトークンの有効期限の管理を裏側で自動化します。

セキュリティに不安がある場合も、承認の処理を既存WFに任せるこの方式には、次の利点があります。

承認の連携ができたら、次は申請の入力を見直します。

対話で受け付けた内容をAIで解釈してWFへ渡す場合も、承認UX設計の「AIによる要約」と同じ入力条件を適用します。

申請の入力を対話に置き換えると、社員が既存システムの画面を操作する手間を減らせます。DXロードマップの先にある、従業員体験（EX）を高める取り組みの一つです。

ここまでは、既存ワークフローへの入力を対話に置き換える話です。さらに進めて、申請の代わりに仕事そのものを依頼する形にしたものが、AIAG（AI業務Orchestrator）です。依頼を受けて作業の計画を示し、重要な判断だけを人に戻します。

問い合わせの受付から担当者への確認、必要な承認、対応記録までをAIエージェントの業務の流れとして組む例は、AIエージェントの始め方と活用例で扱っています。

導入と運用の前に確かめる項目です。