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

v1.2 / 2026-05-11

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

---

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

このエージェントは、Slack でメンションするだけで HR 業務の 下書き・通知・集計・分析 を手伝ってくれる社内アシスタントです。勝手に freee を操作したり、Sheet を書き換えたりすることはありません。

一言でいうと

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

エージェントは現在、次の 3 つの形で動きます。

1. 依頼すると動く（オンデマンド） — Slack でメンションして依頼すると、方針・手順を下書き → あなたの承認後に実行
2. 時間が来ると勝手に動く（自動ジョブ） — 朝の打刻リマインドや月初の HR レポート案などを決まった時刻に投稿
3. 気軽に話しかけられる（会話型 Bot） — 別 Slack App として動く HR Assistant Bot に質問や相談を投げる

1.1 依頼すると動くこと（オンデマンド）

カテゴリ	何をしてくれるか
勤怠集計	先月の打刻データを freee から取り、従業員ごとの労働時間・残業時間を Google Sheet に書き出す
残業時間の確認	指定した月・従業員の残業時間を計算して Slack に返す
従業員一覧の取得	在籍中の従業員リストを freee から取得して Slack に返す
給与の日割り計算（下書き）	入退社月の日割り給与を計算し、根拠つきの下書きを Slack / Sheet に提示
給与の前月差分検出	freee の給与明細を前月と比較し、差異が大きい従業員を抽出
給与差異の説明文ドラフト	検出した差異について「なぜ変わったか」の説明案を AI が下書き
給与の法令リスク検出	最低賃金割れ・残業代未払い候補等のリスク候補を一覧化

依頼系はすべて 2 段階の承認ゲート（実行方針 / 実行ステップ） を通過しない限り、書き込み操作は行いません（§4 参照）。

1.2 時間が来ると勝手に動くこと（自動ジョブ）

ジョブ	いつ動く	何が起きるか
勤怠締めリマインド	毎日 09:00	締め日が近い場合に従業員へ DM、送れない場合は運用チャンネルへフォールバック
未打刻リマインド	毎日 11:00	当日打刻が無い従業員に DM、連続未打刻は HR チャンネルへエスカレーション
消滅有休アラート	毎日 09:10	残有給と付与履歴から消滅予定を判定し、段階的に DM
勤怠異常検知	毎日 12:00	打刻欠損・0 分勤務・24h 超過などを検出し、hr_flags に保存
月次勤怠サマリ	毎日 06:00	freee の勤怠を毎日スナップショット保存。月次の前月差分を算出
36 協定リスク検知	毎日 07:00	残業時間累計を 36 協定上限と突き合わせ、超過リスクを警告
月次 HR レポート案	毎月 1 日 08:00	Lane A / B の集計サマリを HR チャンネルに「下書き」として投稿、承認で配信扱い
人物マスタ同期	手動（make sync-hr-employees）	freee の login_email × Slack users.lookupByEmail で社員マスタ更新

自動ジョブは内部スケジューラ（APScheduler）で動きます。テナント単位で時刻や対象部門を切り替えられます。各ジョブの ON/OFF は環境変数（例: SCHEDULER_LANE_A_JOBS_ENABLED）で制御します。

1.3 気軽に話しかけられること（会話型 HR Assistant Bot）

通常の「依頼 → 承認 → 実行」とは別に、会話用の Slack Bot（別アプリとして動作）が用意されています。

• 社内ハウスルールに関する FAQ を、社内決まりのテキストを根拠に短く返答
• 不確実な場合は「HR に確認してください」と人にエスカレーション
• 「先月の勤怠をまとめたい」のような相談には、AI プランナーが 雑談・追加質問・本流パイプライン提案 を判断して案を提示
• 提案カードの ［この案で進める］ボタン を押すと既存の承認パイプライン（L1〜L4）に乗る

1.4 まだできないこと

• 入退社チェックリストの自動展開（Phase 5 で計画中、Issues #63 / #64）
• 引継ぎ事項のマッピングと後任提案（Phase 5 / #65）
• マイナンバー等の特機密情報の取り扱い
• 1:1 の Slack AI チャット画面（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 枚のカード（タスク・実行方針・実行ステップ・実行結果）が並び、各カードが状態に応じて上書き更新されていきます。スクロールして過去のやり取りを追いかける必要はありません。

各カードには 処理区分バッジ（routing:A 自動 / routing:B AI 補助 + 人レビュー / routing:C 人対応必須）が表示されます。給与差異が大きい場合などはルールベース判定 + L2 の AI 再判定で自動的に C へ昇格します（§4 参照）。

自動ジョブの動き（30 秒サマリ）

flowchart LR
    Time["朝・昼・月初の決まった時刻"] --> Sched["内部スケジューラ"]
    Sched --> LaneA["Lane A 通知<br/>締め日 / 未打刻 / 有休消滅"]
    Sched --> LaneB["Lane B 分析<br/>勤怠異常 / 月次差分 / 36 協定"]
    Sched --> Report["月次 HR レポート案"]
    LaneA --> DM["Slack DM / HR チャンネル"]
    LaneB --> Flags["DB に異常フラグ保存"]
    Report --> ReviewCard["人事チャンネルに<br/>レビューカード"]
    ReviewCard --> Human["承認で配信扱い"]

---

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

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

2.1 人が触る場所

画面	誰が使う	いつ使う	主な操作
Slack 業務チャンネル（MCP Agent Bot）	HR 担当者、承認者	依頼を投げて承認するとき	メンション、承認・却下、中止、再実行、却下理由入力、月次レポート [配信済み] ボタン
Slack 会話チャンネル（HR Assistant Bot、別アプリ）	HR 担当者、その他社員	FAQ や相談を気軽に投げたいとき	メンション、スレッド返信、プラン採用ボタン
Web 管理画面	運用管理者	設定変更・振り返り時	パイプライン閲覧、承認設定、freee / Google / Slack の接続管理

同じ Backend に MCP Agent Bot（依頼・承認用） と HR Assistant Bot（会話用） の 2 つの Slack App が接続されており、両方で社員マスタ・タスク履歴・freee 連携を共有します。

2.2 裏で動くサービス

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

連携先	用途	実装状況
freee 人事労務	従業員情報、勤怠データ、残業時間、給与明細、有給情報の取得	実 API（OAuth 認証）
Google Sheets	集計結果・給与差異・日割り給与の書き出し	実 API（サービスアカウント）
Slack DM	対象従業員本人への通知（Lane A リマインド等）	実 API
Anthropic Claude	業務理解・方針立案・手順分解・実行制御・会話プランニング	実 API

2.3 全体の関係図

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

    subgraph UI["インターフェース"]
        SlackCh[Slack<br/>業務チャンネル<br/>MCP Agent Bot]
        SlackConv[Slack<br/>会話チャンネル<br/>HR Assistant Bot]
        WebAdmin[Web 管理画面]
    end

    subgraph Core["エージェント本体（社内で稼働）"]
        Agent[Backend<br/>4 層パイプライン + 会話プランナ]
        Sched[内部スケジューラ<br/>Lane A / B / 月次レポート]
        DB[(SQLite DB<br/>履歴・設定・人物マスタ<br/>異常フラグ・ルーティング)]
    end

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

    HR -- 依頼・承認 --> SlackCh
    EE -- 質問・FAQ --> SlackConv
    Admin -- 設定・履歴閲覧 --> WebAdmin
    SlackCh <--> Agent
    SlackConv <--> Agent
    WebAdmin <--> Agent
    Sched -- 定期実行 --> Agent
    Agent <--> DB
    Sched <--> DB
    Agent <-- 方針・手順・会話の生成 --> Claude
    Agent -- 勤怠・従業員・給与データ取得 --> Freee
    Agent -- 結果書き出し --> Sheets
    Agent -- 通知送信 --> DM

2.4 データの保管場所

何	どこに	保管期間
依頼内容・承認履歴・実行ログ・ルーティング判断	社内の SQLite データベース	無期限（MVP）
人物マスタ（freee employee_id × Slack UserID）	同上	退社時に手動で status=inactive に更新
勤怠スナップショット・異常フラグ	同上（hr_snapshots / hr_flags）	無期限（MVP）
月次 HR レポート案	同上（monthly_reports）	無期限（MVP）
freee / Google / Slack のトークン	同上（暗号化して保存）	手動で失効させるまで
従業員の詳細データ（給与明細等）	必要な処理時にのみメモリ上で扱う	処理完了後に破棄

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 朝の自動リマインド（あなたが何もしなくても来る）

いつ来るか: 平日朝 9 時前後（運用チャンネル / 対象本人 DM）。

何が起きるか:

• 9:00 — 月次勤怠締めが近いとき、対象従業員へ DM「○○日までに勤怠を提出してください」
• 9:10 — 有給の消滅予定（60 / 30 / 10 / 7 日前）に達した従業員へ DM
• 11:00 — 当日まだ打刻が無い従業員に DM「打刻を忘れていませんか？」。連続未打刻は HR チャンネルへエスカレーション

sequenceDiagram
    participant Sched as 内部スケジューラ
    participant Bot as エージェント
    participant Emp as 対象従業員
    participant HR as HR チャンネル

    Note over Sched: 平日 09:00 / 09:10 / 11:00
    Sched->>Bot: ジョブ起動
    Bot->>Bot: freee + 人物マスタで対象抽出
    Bot->>Emp: Slack DM で通知
    alt Slack ID 未解決 / 連続未打刻
        Bot->>HR: 運用チャンネルへフォールバック / エスカレーション
    end
    Bot->>Bot: hr_flags に「通知済み」マーカー保存
    Note over Bot: 同日中は重複送信されない

HR 担当者がやること: 基本的になし。連続未打刻でエスカレーションが来たら本人と連絡を取る。受信したくない場合はテナント設定でジョブを OFF にする（運用管理者経由）。

---

3.5 月次 HR レポート（毎月 1 日朝 8 時に届く）

いつ来るか: 毎月 1 日 08:00 ごろ、人事チャンネルに「先月のサマリ案」が投稿されます。

カードの中身:

• 先月の勤怠完了率、未打刻件数、有休消滅件数、36 協定リスク件数
• Lane B で検知した異常件数の上位 N 名
• AI が下書きした業務総評コメント

HR が行う操作: 内容を確認して [配信済み] ボタンを押すと「レビュー済み」として記録されます。修正したい場合は別途タスクとして依頼を投げます。

レポートは monthly_reports テーブルに履歴として残り、Web 管理画面から過去分も閲覧できます。

---

3.6 会話 Bot に気軽に質問する

いつ使うか: 「育休の申請ってどうするんでしたっけ？」など、確実な手順や規程の確認を Slack で済ませたいとき。

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

@hr-assistant 育休申請の手順を教えてください

動き:

1. HR Assistant Bot（別 Slack App）に対するメンションを検知
2. AI プランナーが「FAQ で答えられる」「もう少し質問が必要」「本流パイプラインに乗せる」のどれかを判断
3. FAQ の場合は社内決まりのテキストを根拠に短く回答、不確実なら「HR に確認してください」と返す
4. 本流が必要そうなときは「この案で進めますか？」ボタン付きの提案カードを表示、承認すると MCP Agent Bot の承認フローに合流

会話 Bot は Sheets / DM への書き込みは行いません（読み取り中心）。書き込みが伴う依頼は必ず MCP Agent Bot の承認パイプラインに乗ります。

---

3.7 シナリオ全体の比較

シナリオ	きっかけ	書き込み	所要時間	承認ゲート
3.1 月次勤怠集計	あなたの依頼	あり（Sheet + DM）	30 秒〜数分	2 段階
3.2 残業時間確認	あなたの依頼	なし	10 秒前後	2 段階
3.3 従業員一覧取得	あなたの依頼	なし	5 秒前後	2 段階
3.4 朝の自動リマインド	時刻トリガ	DM 送信のみ	即時	不要（テナント設定で同意済み）
3.5 月次 HR レポート	時刻トリガ	チャンネル投稿	即時	レビュー後の [配信済み] のみ
3.6 会話 Bot への質問	あなたの会話	なし（読み取り中心）	数秒	提案を採用するときのみ

補足: 書き込み操作が含まれる依頼系シナリオでは、承認 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 管理画面または DB から確認できます。

記録される情報	保存タイミング	どこで見られるか
依頼内容・タスクのタイトル / 優先度 / 種別	依頼時	Web 管理画面のパイプライン一覧
実行方針・実行ステップの各バージョン	生成のたび	パイプライン詳細画面
承認者（Slack ユーザー ID）と承認時刻	[承認] ボタン押下時	パイプライン詳細 / Slack カード
却下者・却下理由・再生成の親子関係	[却下] + 理由入力時	同上
中止者と中止時刻	[中止] ボタン押下時	同上
実行結果（成功 / 失敗・エラーメッセージ）	実行完了時	同上
処理区分の判定理由（A / B / C）	ルール判定時 + L2 の AI 再判定時	routing_decisions テーブル
人物マスタ（freee employee_id × Slack UserID）	同期ジョブ実行時	hr_employees テーブル
勤怠スナップショット・異常フラグ	Lane A / B ジョブ実行時	hr_snapshots / hr_flags テーブル
月次 HR レポート案	毎月 1 日 08:00	monthly_reports テーブル

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

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

---

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

社内デモ（2026 年 4 月開始）以降、HR 業務拡張は Phase 0〜4 が完了、Phase 5 が進行予定 という状態です。

5.1 今できること

依頼系（あなたが Slack で依頼すると動く）

• 月次勤怠集計（freee → 計算 → Google Sheet 書き出し → 関係者 DM）
• 特定従業員の残業時間確認
• 在籍中の従業員一覧取得
• 給与の日割り計算ドラフト（入退社月）
• 給与の前月差分検出と差異説明の下書き
• 給与の法令リスク候補抽出（最低賃金割れ・残業代未払い候補）
• 社内ハウスルール FAQ への一次回答

自動で動くもの（時刻トリガ）

• 朝 09:00 — 勤怠締めリマインド DM
• 朝 09:10 — 消滅有休アラート（60 / 30 / 10 / 7 日前段階）
• 朝 11:00 — 未打刻リマインド DM + 連続未打刻エスカレーション
• 朝 06:00 — 月次勤怠サマリの日次スナップショット + 前月差分検出
• 朝 07:00 — 36 協定リスク検出（累計超過警告）
• 昼 12:00 — 勤怠異常検知（打刻欠損・0 分勤務・24h 超過等）
• 毎月 1 日 08:00 — 月次 HR レポート案を人事チャンネルへ投稿
• 人物マスタ同期（手動: make sync-hr-employees）

処理区分の自動判定（A / B / C ルーティング）

• ルールベースで初期判定（タスク種別・重大度・フラグ種別）
• L2 の AI 再判定でコンテキスト昇格（差し戻し履歴も反映）
• 給与差異が大きい場合・36 協定違反などは自動的に C へエスカレーション

会話・FAQ（HR Assistant Bot）

• 別 Slack App としてメンション・スレッド返信に対応
• AI プランナーが「雑談 / 追加質問 / 本流パイプライン提案」を判断
• 不確実な FAQ は HR にエスカレーション

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

• パイプライン一覧・詳細・各バージョン履歴閲覧
• 承認設定（承認スキップ Bot 運用モード等）
• freee / Google / Slack の接続状態管理
• HTTP Basic 認証でアクセス制限

5.2 進行予定（Phase 5）

機能	何が変わるか	対応 Issue
入社チェックリスト	新規入社者を起票するとチェックリスト（雇用契約、社保、PC 払出、Slack 招待等）が自動展開、期限通知	#63
退社チェックリスト	退社確定で退社処理一覧が展開、電子申請が絡む項目は人介入必須	#64
引継ぎマッピング	退社者のスレッド・添付から AI が引継ぎ事項を抽出、後任候補を提案	#65

Phase 5 全体のトラッキングは #71 で進行中です。

5.3 本番運用前提として残っている課題

社内デモから顧客提供に進むには以下が必要です（詳細: Post-MVP ロードマップ）。

カテゴリ	内容
認証	Basic 認証 → Firebase Auth + Google SSO（@cast-er.com ドメイン制限）
DB	SQLite → PostgreSQL（マルチテナントの前提）
Slack 接続	Socket Mode → HTTP Mode（複数インスタンス運用）
デプロイ	ローカル / Railway → Cloud Run or ECS
PII	マイナンバー等の特機密情報のマスキング
スケジューラ	アプリ内 APScheduler → EventBridge + Lambda（高可用 / 監視強化）
マルチテナント	1 つの Bot で複数社の Slack ワークスペースを扱う

5.4 今のところ対象外

• 1:1 の Slack AI チャット画面（Agent Container）からの依頼
• 顧客ごとに独立した認証・環境分離の本格実装
• 給与の本確定計算（freee 内で確定処理させる、本エージェントは下書きと差分検出まで）

これらは顧客パイロット開始時に改めて要件を洗い出します。

---

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.1	4〜7 章（人と AI の役割分担／今できること／よくある質問／参照先）を追加し v1.0 として公開
2026-05-11	v1.2	Phase 0-4 実装に追随。Lane A / B / C 自動ジョブ、会話型 HR Assistant Bot、月次 HR レポート、A/B/C ルーティング、人物マスタを反映。§1 / §2 / §3 / §4.5 / §5 を全面更新。
2026-04-20	v1.0	4〜7 章（役割分担／MVP スコープ／FAQ／関連ドキュメント）の本文を追加。全章完成
2026-04-20	v1.1	3・4 章にスクリーンショットの差し込みポイントを追加（docs/img/placeholder.svg を暫定参照）。画像管理の README 追加