コンテンツにスキップ

Slack MCP Agent — HR チーム向けご紹介

v1.1 / 2026-04-20

このページは、実際に Slack でこのエージェントに業務を依頼する HR 担当者の方に向けた、非エンジニア向けの概要ページです。
技術的な詳細は左ナビの「設計」「UI 仕様」以下にまとまっています。

1. このエージェントでできること

Slack で「先月の勤怠をまとめて」のように話しかけると、AI が 業務の段取りを組んで案を提示し、あなたが承認してから実行する 社内アシスタントです。勝手に freee を操作したり、Sheet を書き換えたりすることはありません。

一言でいうと

AI は「下書きと実行」を担当し、「判断と承認」は必ず人が行う。

従来のチャットボットのように FAQ を返すだけではなく、実際の業務処理（freee から勤怠データを取得する、Google Sheet に書き出す、Slack DM を送る）まで自動で行います。ただしその一つひとつの段取りは事前に画面に表示され、あなたの OK がない限り先に進みません。

MVP でできること

できること 具体的に何をしてくれるか
勤怠データの集計 先月の打刻データを freee から取り、従業員ごとの労働時間・残業時間を Google Sheet に書き出す
残業時間の確認 指定した月・従業員の残業時間を計算して Slack に返す
従業員一覧の取得 在籍中の従業員リストを freee から取得して Slack に返す

MVP ではまだできないこと

  • 定期実行（毎月 1 日に自動で勤怠集計 など）
  • 給与計算、入退社手続き、年末調整
  • マイナンバー等の特機密情報の取り扱い
  • 1:1 の AI チャット画面（Slack Agent Container）での依頼

いずれも技術的には拡張可能で、Post-MVP ロードマップ に沿って段階的に追加していきます。

全体の流れ（30 秒サマリ）

flowchart LR
    A["① Slack でメンション<br/>（依頼を投げる）"] --> B["② AI が方針を下書き<br/>（実行方針カード）"]
    B --> C["③ あなたが承認<br/>1 回目のゲート"]
    C --> D["④ AI が手順を下書き<br/>（実行ステップカード）"]
    D --> E["⑤ あなたが承認<br/>2 回目のゲート"]
    E --> F["⑥ AI が実行<br/>（実行中カード）"]
    F --> G["⑦ 結果が届く"]

Slack のスレッド内には常に 4 枚のカード（タスク・実行方針・実行ステップ・実行結果）が並び、各カードが状態に応じて上書き更新されていきます。スクロールして過去のやり取りを追いかける必要はありません。

2. どこで触る・どこで動く

人が直接触る場所は Slack と Web 管理画面 の 2 か所だけです。それ以外（freee・Google Sheets 等の連携）はすべて裏側で自動的に動きます。

2.1 人が触る場所

画面 誰が使う いつ使う 主な操作
Slack の業務チャンネル HR 担当者、承認者 日常業務のなかで 依頼（メンション）、承認・却下、中止、再実行、却下理由の入力
Web 管理画面 運用管理者 設定変更時・振り返り時 過去のパイプライン閲覧、承認設定、freee / Google / Slack の接続管理

Slack だけで業務が完結するよう設計されており、Web 管理画面を毎日開く必要はありません。Web 管理画面は「設定を変えたいとき」「先月の処理を振り返りたいとき」に使います。

2.2 裏で動くサービス

エージェントは以下の外部サービスと連携します。認証情報（トークン等）は Backend プロセス内にだけ保持され、AI（Anthropic）側には渡しません。

連携先 用途 実装状況
freee 人事労務 従業員情報、勤怠データ、残業時間の取得 実 API（OAuth 認証）
Google Sheets 集計結果の書き出し 実 API
Slack DM 対象従業員本人への通知 実 API
Anthropic Claude AI による業務理解・方針立案・手順分解・実行制御 実 API

2.3 全体の関係図

flowchart LR
    subgraph 人["人が触る"]
        HR([HR 担当者])
        Admin([運用管理者])
    end

    subgraph UI["インターフェース"]
        SlackCh[Slack<br/>業務チャンネル]
        WebAdmin[Web 管理画面]
    end

    subgraph Core["エージェント本体（社内で稼働）"]
        Agent[Backend<br/>4 層パイプライン]
        DB[(SQLite DB<br/>履歴・設定)]
    end

    subgraph Ext["外部サービス"]
        Claude[Anthropic<br/>Claude]
        Freee[freee 人事労務]
        Sheets[Google Sheets]
        DM[Slack DM]
    end

    HR -- メンション・承認 --> SlackCh
    Admin -- 設定・履歴閲覧 --> WebAdmin
    SlackCh <--> Agent
    WebAdmin <--> Agent
    Agent <--> DB
    Agent <-- 方針・手順の生成 --> Claude
    Agent -- 勤怠・従業員データ取得 --> Freee
    Agent -- 結果書き出し --> Sheets
    Agent -- 通知送信 --> DM

2.4 データの保管場所

何 どこに 保管期間
依頼内容・承認履歴・実行ログ 社内の SQLite データベース 無期限（MVP）
freee / Google / Slack のトークン 同上（暗号化して保存） 手動で失効させるまで
従業員データ（氏名・勤怠等） DB には保存しない（実行時のみメモリ上） 処理完了後に破棄

AI への一時的な送信は Anthropic のデータ保持なしポリシーに依拠しています（詳細は 要件定義 §8 参照）。

3. 代表シナリオ

実際の業務でどう使うかをイメージできるよう、代表的な 3 つのシナリオを紹介します。いずれも Slack の業務チャンネルでエージェントにメンション することから始まります。

3.1 月次の勤怠集計（メインユースケース）

いつ使うか: 毎月、給与計算の準備として前月分の勤怠を集計するとき。

Slack に投げるメッセージの例:

@hr-agent 先月の勤怠をまとめて、Google Sheet に書き出してください

カードの流れ

エージェントはスレッド内に 4 枚のカード を順に投稿し、各カードが状態に応じて上書きされていきます（スレッドが長大化しないよう設計されています）。

sequenceDiagram
    participant You as HR 担当者
    participant Bot as エージェント

    You->>Bot: @hr-agent 先月の勤怠をまとめて Sheet に書き出して
    Note over Bot: ① Task カード（分析中 → 完了）
    Bot-->>You: タイトル・優先度・種別を表示

    Note over Bot: ② 実行方針カード（生成中 → 承認待ち）
    Bot-->>You: 「先月分の全従業員勤怠を集計し、労働時間・残業時間を Sheet に書き出す」
    You->>Bot: [承認] ボタン押下（1 回目のゲート）

    Note over Bot: ③ 実行ステップカード（生成中 → 承認待ち）
    Bot-->>You: 1. list_employees<br/>2. list_attendance<br/>3. calculate_overtime<br/>4. write_rows_to_google_sheet<br/>5. send_slack_dm
    You->>Bot: [承認] ボタン押下（2 回目のゲート）

    Note over Bot: ④ 実行カード（実行中 → 完了）
    Bot-->>You: 各ステップの進捗と、[中止] ボタン
    Bot-->>You: 完了サマリ + Sheet の URL

承認する場面

承認ゲートは 2 回あります。どちらも [承認] / [却下] のボタンで応答します。

ゲート 何を確認するか
① 実行方針の承認 「何をやろうとしているか」の方向性が合っているか
② 実行ステップの承認 どの freee API やツールを、どの順で呼び出すかが妥当か

実行方針カード（承認待ち）のスクリーンショット

実行方針カード（承認待ち）— 青カラーバー + [承認] / [却下] ボタン

却下する場合は [却下] ボタンを押すと理由入力のモーダルが開き、入力した理由を踏まえて AI が案を作り直します（再生成）。

最終的に届くもの

  • Google Sheet（集計結果の表）の URL が Slack の完了カードに表示される
  • 対象従業員ごとに Slack DM で集計結果が通知される（※ DM 送信は手順に含まれている場合のみ）
  • 誰が・いつ・何を承認したかが自動で Web 管理画面に記録される

実行完了カードのスクリーンショット

実行完了カード — 全ステップ ✅ + サマリ + Google Sheet URL

3.2 特定従業員の残業時間確認

いつ使うか: 36 協定の遵守状況確認や、個別のヒアリング準備として残業状況を把握したいとき。

Slack に投げるメッセージの例:

@hr-agent 田中太郎さんの今月の残業時間を教えてください

カードの流れ

勤怠集計と同じく 4 枚のカードが投稿されますが、ステップ数が少なく、Google Sheet への書き出しは発生しない 点が異なります。

sequenceDiagram
    participant You as HR 担当者
    participant Bot as エージェント

    You->>Bot: @hr-agent 田中太郎さんの今月の残業時間を教えて
    Bot-->>You: ① Task カード: 「特定従業員の残業時間確認」
    Bot-->>You: ② 実行方針カード: 「従業員を特定し、今月の残業時間を算出」
    You->>Bot: 承認

    Bot-->>You: ③ 実行ステップカード:<br/>1. list_employees（従業員特定）<br/>2. calculate_overtime（残業時間算出）
    You->>Bot: 承認

    Bot-->>You: ④ 実行カード: 残業時間 XX 時間 YY 分<br/>（Slack 上にそのまま表示）

最終的に届くもの

  • Slack の完了カードに残業時間がテキストで表示される
  • 閾値超過等の判定はエージェントが自動で行わない（数値の提示まで）。判断は人が行う

残業時間確認の完了カードのスクリーンショット

残業時間確認シナリオの完了カード — 数値表示

3.3 従業員一覧の取得

いつ使うか: 部署異動後に最新の在籍者を確認したい、新しいチャンネルへの招待対象を洗い出したい、など「現在の誰が在籍しているか」を知りたいとき。

Slack に投げるメッセージの例:

@hr-agent 在籍中の従業員一覧をください

カードの流れ

最もシンプルなシナリオで、実行ステップは 1 つだけ になります。それでも 2 段階の承認ゲートは省略せず、必ず人が確認します。

sequenceDiagram
    participant You as HR 担当者
    participant Bot as エージェント

    You->>Bot: @hr-agent 在籍中の従業員一覧をください
    Bot-->>You: ① Task カード: 「従業員一覧取得」
    Bot-->>You: ② 実行方針カード: 「在籍中の従業員を freee から取得して一覧表示」
    You->>Bot: 承認

    Bot-->>You: ③ 実行ステップカード:<br/>1. list_employees
    You->>Bot: 承認

    Bot-->>You: ④ 実行カード: 従業員一覧（人数 + 名前・部署）

最終的に届くもの

  • Slack の完了カードに従業員一覧が表形式で表示される
  • 人数が多い場合は先頭 N 名のみ表示し、全件は Google Sheet に書き出す案をエージェントが提示することもある（実行方針カードで確認できる）

従業員一覧の完了カードのスクリーンショット

従業員一覧シナリオの完了カード — 表形式で従業員名・部署が並ぶ

3.4 3 つのシナリオの比較

シナリオ 処理対象 書き込み操作 所要時間の目安 ステップ数
3.1 月次勤怠集計 全従業員 × 前月 あり（Sheet 書き込み + DM 送信） 30 秒〜数分 5 前後
3.2 残業時間確認 特定従業員 × 特定月 なし（参照のみ） 10 秒前後 2 前後
3.3 従業員一覧取得 全従業員（現在） なし（参照のみ） 5 秒前後 1

補足: 書き込み操作が含まれるシナリオでも、承認 2 回を通過しない限り実行は始まりません。参照のみのシナリオでも、承認フローは省略されません。

4. 人と AI の役割分担

このエージェントは「AI に全部任せる」ではなく、重要な判断は必ず人が確認する 設計になっています。HR 業務は個人情報・給与データを扱うため、AI の判断だけで実行してはいけない、というのが出発点です。

4.1 役割分担のひと目表

段階 AI がやること 人がやること
① 業務の理解 依頼文から「何をすべきか」を整理（タスク化） —
② 方針の立案 実行方針の下書きを作る 内容を見て 承認 or 却下 ← 1 回目のゲート
③ 手順の具体化 どのツールを・どの順番で呼ぶか具体化 内容を見て 承認 or 却下 ← 2 回目のゲート
④ 実行 承認された手順だけを実行する いつでも [中止] ボタンで止められる
⑤ 記録 誰が・いつ・何を承認したかを自動記録 Web 管理画面でいつでも確認できる

AI は承認を受けた手順以外は絶対に実行しません。たとえば「従業員一覧を取得する」承認しかしていないのに、勝手に DM を送ったり Sheet を書き換えたりすることはありません。

4.2 なぜ 2 回も承認するのか

1 回だけの承認だと、「方針は妥当だが、実際の freee API 呼び出し方がおかしい」 というケースを検知できません。そのため 2 段階に分けています。

ゲート 確認する観点 典型的な却下理由
① 実行方針 目的と範囲が依頼と合っているか 「全従業員ではなく営業部のみにしてほしい」「先月ではなく前四半期で集計して」
② 実行ステップ ツール選択・順序・対象データが妥当か 「DM 送信は不要」「Sheet に書き出す前に合計行を入れて」

4.3 やり直しの仕組み（却下 → 再生成）

[却下] ボタンを押すと、却下理由を入力するダイアログ が開きます。入力した理由を踏まえて AI が案を作り直し、新しいバージョン（v2, v3, ...）として提示します。

sequenceDiagram
    participant You as HR 担当者
    participant Bot as エージェント
    Bot-->>You: 実行方針カード v1（承認待ち）
    You->>Bot: [却下] ボタン → 却下理由モーダルが開く
    You->>Bot: 「営業部のみに絞って」と入力して送信
    Bot-->>You: 既存カードが「却下 → 再生成済み」に更新
    Bot-->>You: 実行方針カード v2（承認待ち）として再掲示
    You->>Bot: [承認] ボタン

却下しても 元のカードは消えず履歴として残り、いつ・誰が・どんな理由で却下したかが監査ログに自動保存されます。

却下理由入力モーダルのスクリーンショット

却下理由入力モーダル — 入力内容を踏まえて次バージョンが生成される

やり直しの上限

  • 方針・手順の再生成: 1 タスクにつき最大 5 回
  • 失敗時の再実行: 最大 3 回
  • 上限に達した場合はタスクをキャンセルし、新しく依頼し直します

4.4 実行を止める仕組み

実行カードに表示される [中止] ボタンでいつでも止められます。誤操作防止のため、押すと「本当に中止しますか？」の確認ダイアログが挟まります。中止後は新しいタスクとして再依頼する流れになります。

中止確認ダイアログのスクリーンショット

中止確認ダイアログ — 誤操作防止のため 2 ステップで中止する

中止のタイミングに注意

ステップ単位で中止するため、すでに実行済みのステップ（例: freee からデータ取得完了）は取り消されません。書き込み系のステップの途中で中止した場合、書き込み済みの行は残ることがあります（Sheet を手動で編集するなどの運用対応が必要）。

4.5 自動で記録されるもの

以下はすべて自動的に DB に記録され、Web 管理画面で閲覧できます。

記録される情報 保存タイミング どこで見られるか
依頼内容・タスクのタイトル / 優先度 / 種別 依頼時 Web 管理画面のパイプライン一覧
実行方針・実行ステップの各バージョン 生成のたび パイプライン詳細画面
承認者（Slack ユーザー ID）と承認時刻 [承認] ボタン押下時 パイプライン詳細 / Slack カード
却下者・却下理由・再生成の親子関係 [却下] + 理由入力時 同上
中止者と中止時刻 [中止] ボタン押下時 同上
実行結果（成功 / 失敗・エラーメッセージ） 実行完了時 同上

監査ログ専用画面（/audit の検索 UI）は Post-MVP で追加予定です。MVP でも記録自体は取得できており、DB から直接確認できます。

Web 管理画面のパイプライン詳細ページのスクリーンショット

Web 管理画面のパイプライン詳細ページ — 承認者・時刻・再生成履歴が一望できる

5. 今できること／今はまだできないこと

MVP（社内デモ版、2026 年 4 月完成）時点でできることと、今後の予定を整理します。

5.1 今できること（MVP）

業務シナリオ

  • 勤怠集計（全従業員 × 前月、Google Sheet 書き出し）
  • 残業時間確認（特定従業員 × 特定月）
  • 従業員一覧取得

Slack 上での操作

  • 業務チャンネルでエージェントにメンションして依頼
  • 実行方針・実行ステップの承認 / 却下（理由入力 → 再生成）
  • 実行中の中止（確認ダイアログつき）
  • 失敗時の再実行

Web 管理画面（ブラウザで http://localhost:3100）

  • パイプライン一覧と詳細表示
  • パイプラインごとの各バージョン履歴閲覧
  • 承認設定（承認をスキップする Bot 運用モードなど）
  • freee / Google / Slack の接続状態管理
  • HTTP Basic 認証でアクセス制限（ID / パスワードを環境変数で設定）

5.2 近いうちにできるようになる予定（Post-MVP）

機能 何が変わるか
1:1 AI チャット画面（Agent Container） Slack サイドバーから Split Pane で、AI との対話専用画面が開ける
監査ログ専用 UI（/audit） 誰が・いつ・何を承認したかを検索・フィルタできる
実行中のリアルタイム進捗表示 実行カードのチェックマークが各ステップ完了ごとに更新される
Google SSO ログイン Web 管理画面を @cast-er.com アカウントのみで利用可能に
定期実行（スケジューラー） 「毎月 1 日に勤怠集計を自動起動」のような定型業務の自動化
他の HR 業務シナリオ 給与計算補助、入退社手続き、年末調整など
マルチテナント運用 1 つの Bot で複数社の環境を扱う

詳細なロードマップと優先順位は Post-MVP ロードマップ を参照してください。

5.3 今のところ対象外（顧客提供前に改めて検討）

  • マイナンバー等の特機密情報の取り扱い（マスキング未実装）
  • 顧客ごとに独立した認証・環境分離（マルチテナント分離の本格実装）
  • AI 利用に関する顧客の情報セキュリティポリシーへの個別合意

これらは社内デモ段階では不要なためスコープ外としています。顧客パイロット開始時に改めて要件を洗い出します。

6. よくある質問

誰がこの Bot にお願いできますか？

Bot が参加している Slack チャンネルに入っている人は誰でもメンション して依頼できます。MVP ではメンションできる人・依頼できる人に制限はありません。運用上の制限をかけたい場合は「エージェント専用チャンネル」を作り、そのチャンネルの参加者を管理する方法を推奨します。

承認できるのは誰ですか？

MVP では カードの [承認] / [却下] ボタンを押せる Slack ユーザーなら誰でも承認者になれます（権限チェックは行わない）。承認した人の Slack ユーザー ID と時刻が自動で記録されるため、事後の監査は可能です。

運用としては、依頼した人自身が承認する「セルフ承認」と、第三者がレビューする「ダブルチェック承認」のどちらでも回せます。厳密な承認者ロール制御は Post-MVP で検討します。

どのチャンネルで使えますか？ DM でも使えますか？

MVP では Bot を招待した業務チャンネルでのメンションのみ 対応しています。DM（ダイレクトメッセージ）や、Slack の 1:1 AI チャット画面（Agent Container）は Post-MVP での対応予定です。

個別従業員の残業時間など、他の人に見せたくない情報を扱う場合は、該当担当者のみが参加するプライベートチャンネル を作って Bot を招待してください。

失敗したらどうなりますか？

実行中にエラーが発生すると、実行カードが「失敗」状態に更新され、エラーメッセージと [再実行] ボタンが表示されます。ボタンを押せば同じ手順で再実行できます（最大 3 回）。

注意点として、書き込み系のステップ（Sheet 書き込み・DM 送信）の途中で失敗した場合、書き込み済みの行や送信済みの DM はそのまま残ります（自動ロールバックは行わない）。失敗したステップ以降のみが再実行の対象になります。影響範囲は失敗カードに表示されるステップ進捗（✅ / ❌ / ⬜）で確認できます。

freee のトークンは誰が管理していますか？ AI に渡りますか？

freee / Google / Slack などの 認証トークンは Backend プロセス内にだけ保持 され、Anthropic（AI）側には絶対に送信しません。

トークンの設定は Web 管理画面の「接続管理」画面 から行います（MVP では運用管理者が設定）。トークンは DB に暗号化して保存され、Slack のメッセージや LLM への入力には含まれません。

従業員の個人データは AI（Claude）に送られますか？ どこに保存されますか？

実行時の一時データ（氏名・勤怠時間等）は AI に送られます が、Anthropic は データ保持なしポリシー に基づき学習にも再利用にも使用しません。

社内の DB（SQLite）には 依頼内容・承認履歴・実行ログ は残りますが、従業員の生データ（勤怠時間の詳細等）はメモリ上でのみ扱い、処理完了後に破棄します。マイナンバー等の特機密情報は MVP では取り扱いません（顧客提供前に改めてマスキング要件を検討します）。

エージェントが勝手に DM を送ったり Sheet を書き換えたりしませんか？

いいえ、2 段階の承認ゲートを両方とも通過しない限り、書き込み系の操作は一切実行されません。

  • 実行方針カード（方針レベル）で承認
  • 実行ステップカード（ツール呼び出しレベル）で承認
  • 実行開始後も、[中止] ボタンでいつでも止められる

さらに、各書き込みステップ（DM 送信・Sheet 書き込み）は 実行ステップカードに明示的に含まれていない限り呼ばれません。「念のため」といった理由で AI が独自判断で追加実行することはない設計です。

Web 管理画面は社内の誰が見られますか？

MVP では HTTP Basic 認証（ID とパスワードを環境変数 ADMIN_USER / ADMIN_PASSWORD で設定）で保護しており、ID とパスワードを知っている人のみアクセスできます。

Post-MVP で Firebase Auth + Google SSO に差し替え、@cast-er.com ドメインのアカウントのみアクセス可能にする予定です。

Slack の通知が来ない、Bot が反応しないときは？

以下を順に確認してください:

  1. Bot がチャンネルに参加しているか（メンション候補に出るか）
  2. メンションの宛先が正しいか（例: @hr-agent）
  3. Web 管理画面の「接続管理」で Slack 接続が緑色（接続済み）になっているか
  4. それでも反応しない場合は 開発者チャンネル に連絡してください（ログから原因を追えます）
ボタンを押した後、カードの表示が固まって動かないときは？

Slack の表示が古いままになっている場合は スレッドを一度閉じて開き直す と最新状態に更新されます。それでも復旧しない場合は、同じタスクを新しく依頼し直すのが確実です（過去のタスクも Web 管理画面からは完了状態として見えます）。

7. もっと詳しく知りたい方へ

読者の関心に応じて、次のページをご覧ください。

業務・運用の方向け

関心 参照先
プロジェクトの背景と業務要件の全体像 要件定義
MVP で何を作るかの詳細（業務シナリオ別） MVP 仕様
将来の拡張計画と優先順位 Post-MVP ロードマップ
Slack で見えるカードの詳細（モック付き） Slack UI 仕様
Web 管理画面の画面仕様 管理画面仕様
失敗したとき・却下したときの挙動の細部 エラーハンドリング

技術・実装の方向け

関心 参照先
システム構成（3 プロセス構成、4 層パイプライン） アーキテクチャ
DB テーブル定義・状態遷移 データモデル
Custom Tool 設計、freee API アダプタ Custom Tool 設計
L1-L4 のプロンプト設計 プロンプト設計
ディレクトリ構成・命名規則 プロジェクト構成
技術選定の判断根拠（ADR） 技術選定

困ったとき・問い合わせ

  • Slack Bot が反応しない・表示がおかしい → 本ページ 6 章 FAQ の末尾項目を参照
  • 業務内容の相談・改善要望 → プロジェクト運用チャンネルへ投稿（詳細は社内ポータル参照）
  • バグ報告・機能要望 → GitHub Issues（開発者向け）

変更履歴

日付 バージョン 変更内容
2026-04-20 v0.1 章立てスケルトン作成（本文はレビューしながら順次追記）
2026-04-20 v0.2 1〜3 章（できること／どこで動くか／代表シナリオ）の本文を追加
2026-04-20 v1.0 4〜7 章（役割分担／MVP スコープ／FAQ／関連ドキュメント）の本文を追加。全章完成
2026-04-20 v1.1 3・4 章にスクリーンショットの差し込みポイントを追加（docs/img/placeholder.svg を暫定参照）。画像管理の README 追加