Slack MCP Agent — 要求定義書¶
v1.3 / 2026-04-20
1. プロジェクト概要¶
1.1 プロジェクト名¶
Slack MCP Agent（HR AI Agent）
1.2 目的¶
業務担当者が Slack を離れずに「依頼 → 承認 → 結果受取」を完結できる、AI 駆動型業務自動化エージェントを構築する。
AI が立てた計画を 2 段階で人間が確認してから実行に移す仕組みにより、HR 業務のように慎重さが求められる領域でも安心して AI に業務を委任できる。
1.3 背景¶
キャスターの HR BPO 事業では、月次の労務オペレーション（勤怠集計、給与計算補助、入退社手続き等）に多くの人的工数を費やしている。既存の ACC（アカウントコンサルタント）モデルは属人性が高く、スケーラビリティに制約がある。
NEO ACC 構想として「AI フロント」を導入し、定型作業・指示・報告・マニュアル化を AI が担い、人間は判断・承認・関係構築・AI の育成に集中する体制への移行を目指す。
最終ゴールは月次オペレーションにおける人間の作業工数を約 72% 削減することである（52h/月 → 14.5h/月）。
1.4 先行プロジェクト¶
caster-division-ai（Caster オーケストレーション）の思想を踏襲する。具体的には以下を継承する：
- 4 層パイプライン: L1（業務理解）→ L2（計画立案）→ L3（ツール分解）→ L4（エージェント実行）
- 2 段階承認ゲート: Prompt 承認 + Process 承認による人間介入
- Managed Agents + Custom Tool 方式: エージェントループは Anthropic Cloud、ツール実行は Backend 内で完結
- Slack 完結型 UX: チャンネルメンションで開始し、スレッド内で承認・進捗確認・結果受取（Agent Container は Post-MVP）
- 1 タスク 4 メッセージ原則: chat.update による状態遷移、スレッド肥大化の防止
2. 解決すべき課題¶
| # | 課題 | 詳細 |
|---|---|---|
| C-1 | Slack を離れずに業務を依頼・完結させたい | 現在は依頼→確認→結果受取が複数ツールに分散している |
| C-2 | AI の計画を確認せずに実行されるのは受け入れられない | HR 業務では個人情報・給与データを扱うため、実行前の確認が必須 |
| C-3 | 重要操作の前に必ず止まり、人が確認してから進めたい | 取り消せない操作（データ書込・外部送信）を AI の判断だけで行わせるのは危険 |
| C-4 | 実行中の進捗と判断材料が散らばっていると状況把握が困難 | スレッドを遡って情報を探すのは非効率 |
| C-5 | 差し戻し・やり直しの仕組みがないと実務で使えない | AI の出力が不適切な場合に修正ループを回せる必要がある |
3. 提供する価値¶
| # | 価値 | 説明 |
|---|---|---|
| V-1 | Slack 完結型 UX | チャンネルメンションから業務が動く。スレッドを離れずに承認・実行確認が可能（Post-MVP で Agent Container を追加） |
| V-2 | 2 段階承認による安全性 | 方針（Prompt）と手順（Process）を段階的に確認。重要操作前には必ず停止 |
| V-3 | 1 枚カードによる可視性 | 実行の進捗・結果・判断材料がすべて 1 枚のステータスカードに集約 |
| V-4 | 差し戻し・再生成による品質確保 | 不適切な計画やステップを却下し、理由を反映した再生成が可能 |
| V-5 | Custom Tool によるセキュリティ | ツール実行が Backend 内で完結し、認証情報が外部に渡らない |
| V-6 | MCP 差し替えによる拡張性 | 接続する MCP / Custom Tool を変えれば対応業務が変わる。初期は HR 勤怠、以降は他ドメインへ転用可能 |
4. ユーザーストーリー¶
4.1 MVP ストーリー（社内デモスコープ）¶
US-1: Slack メンションで業務依頼 労務担当者として、Slack で「今月の勤怠をまとめて」とメンションするだけで、Agent が実行結果を返してほしい。ツールを指定せずに業務を依頼できるのが真の効率化だから。
US-2: 2 段階の計画確認 労務担当者として、Agent が立てた方針とステップを段階的に確認したい。従業員の個人情報や給与データを扱う業務では、実行前に内容を確認する運用が必須だから。
US-3: 重要操作の手前での停止 労務担当者として、重要な操作の手前で必ず止まり、何をするのかを確認してから続行したい。取り消せない操作を AI の判断だけで行わせるのは危険だから。
US-4: 進捗の一目把握 労務担当者として、進捗と判断材料が 1 枚のカードに集約されていてほしい。スレッドを遡って情報を探すのは面倒で、現在の状況を一目で把握したいから。
US-5: 差し戻しと再生成 労務担当者として、Agent が立てた方針やステップが不適切な場合に却下理由を伝えて再生成させたい。1 回で完璧な計画が出ることは稀で、フィードバックループが必要だから。
4.2 Post-MVP ストーリー（将来スコープ）¶
US-6: 定期実行 労務担当者として、月次の勤怠集計を定期的に AI が自動実行し、結果を承認するだけにしたい。毎月同じ依頼をメンションする手間を省きたいから。
US-7: 管理画面での設定・監査 運用管理者として、承認フローの ON/OFF、ツール接続の管理、監査ログの閲覧を Web 画面で行いたい。Slack だけでは設定変更や監査証跡の確認が困難だから。
US-8: 複数業務シナリオ 労務担当者として、勤怠集計だけでなく、給与計算補助、入退社手続き、年末調整なども AI に依頼したい。対応業務が増えるほどサービスの価値が高まるから。
5. 対象ドメインと業務シナリオ¶
5.1 MVP 対象業務¶
勤怠集計（先月分の打刻データ集計 → Sheet 出力）
具体的なフロー: 1. 従業員一覧を取得 2. 各従業員の先月分の勤怠データを取得 3. 労働時間・残業時間を集計 4. 集計結果を Google Sheet に書き込み 5. 完了通知を送信
5.2 MVP で使用するツール¶
| ツール名 | 種別 | 実装 | 説明 |
|---|---|---|---|
list_employees |
Custom Tool | 実 freee API | 従業員一覧取得 |
list_attendance |
Custom Tool | 実 freee API | 勤怠データ取得 |
calculate_overtime |
Custom Tool | 実 freee API | 残業時間計算 |
write_rows_to_google_sheet |
Custom Tool | 実 API | Google Sheet 書き込み |
send_slack_dm |
Custom Tool | 実 API | Slack DM 送信 |
5.3 将来のドメイン拡張（参考）¶
ロードマップに基づく HR 業務シナリオ:
| カテゴリ | シナリオ数 | 時期 |
|---|---|---|
| 給与計算 | 27 | MVP2（6 月〜） |
| 勤怠管理 | 29 | MVP2（7 月〜） |
| 入社対応 | 12 | MVP2（8 月〜） |
| 退社対応 | 20 | MVP2（9 月〜） |
| ストレスチェック | 12 | MVP2（10 月〜） |
| 健康診断 | 12 | MVP2（11 月〜） |
| 年末調整 | 7 | MVP2（12 月〜） |
対応ツールの利用率（顧客環境）: - 勤怠管理: KOT 24%, freee 18%, ジョブカン 11% - 給与計算: freee 45%, MF 17%, 給与奉行 10% - 人事管理: freee 38%, SmartHR 32%
6. 操作者と役割¶
| 誰 | トリガー | 操作 | MVP スコープ |
|---|---|---|---|
| 労務担当者 | Slack で Bot にメンション | パイプラインを開始 | 対象 |
| 労務担当者 | Block Kit ボタン押下 | Prompt / Process の承認・却下 | 対象 |
| 労務担当者 | Block Kit ボタン押下 | 失敗時の再実行 | 対象 |
| 開発者 / 運用 | 設定ファイル / 環境変数 | 承認設定・ツール管理 | 対象（CLI ベース） |
| 運用管理者 | Web 管理画面 | パイプライン閲覧・設定・外部連携・監査ログ | 対象 |
7. スコープ定義¶
7.1 MVP スコープ（4 月中完了）¶
| 機能 | 含む |
|---|---|
| 4 層パイプライン（L1-L4） | ○ |
| 2 段階承認ゲート | ○ |
| 却下 → 理由入力モーダル → 再生成フロー | ○ |
| Slack Block Kit カード（4 枚、chat.update 方式） | ○ |
| 実行中の中止機能 | ○ |
| エラー表示 + 再実行ボタン | ○ |
| Custom Tool（実 freee API 3 個 + 実 API 2 個） | ○ |
| 実 freee API 統合（勤怠集計シナリオ） | ○ |
| Managed Agents + Custom Tool によるL4実行 | ○ |
| Web 管理画面（Pipeline / Settings / Integrations） | ○ |
| SQLite によるデータ永続化 | ○ |
| シングルテナント（tenant_id はデータモデルに含む） | ○ |
7.2 MVP スコープ外¶
| 機能 | 理由 | 時期 |
|---|---|---|
| マルチテナント運用 | 社内デモはシングルテナント | MVP2 以降 |
| 定期実行（スケジューラー） | US-1〜5 で完全なループを検証 | MVP1 後半 |
| Firebase Auth + Google SSO | 環境変数ベースで運用 | MVP2 以降 |
| 38 個の HR ツール | 5 個でパイプライン動作を検証 | MVP2 以降 |
| スラッシュコマンド UI | メンションのみ | 将来 |
| マイナンバー等のマスキング | 社内デモ段階では不要 | 顧客提供前 |
| Agent Container（Split Pane） | MVP はチャンネルメンションのみで検証 | Post-MVP |
監査ログ UI（/audit） |
Backend 書込のみ MVP で実装、UI は後回し | Post-MVP |
| L4 のリアルタイム進捗更新（ツール単位） | on_progress 配線が未実装 |
Post-MVP |
8. セキュリティ要件¶
8.1 MVP 段階¶
- LLM への入力は
<user_input>タグで隔離（プロンプトインジェクション対策） - L4 は Managed Agents + Custom Tool。ツール実行は Backend 内で完結
- 認証情報（API キー、OAuth トークン）は Backend プロセス内に保持。外部に渡さない
- MVP ではモックデータのため実データ漏洩リスクなし
- HR 個人データの LLM API 送信は許容する（Anthropic のデータ保持なしポリシーに依拠）
8.2 顧客提供段階で追加すべき対策¶
- マイナンバー等の重要個人情報のマスキング
- テナントごとの認証情報分離
- 監査ログ（操作ログ全件保存）
- Claude Enterprise 契約によるデータ保護強化
- AI 利用に関する顧客の情報セキュリティポリシー合意
9. ビジネスモデル（参考）¶
| 項目 | 既存 ACC | NEO ACC（過渡期） | NEO ACC（最終） |
|---|---|---|---|
| フロント AI/人間 | 0/10 | 7-8/2-3 | 10/0 |
| オペレーション AI/人間 | 5/5 | 8/2 | 10/0 |
| ターゲット従業員数 | 50 名以上 | 30 名以下 | 30 名以下 |
| ランニングコスト | 人件費（従量） | LLM 3 万+サーバー 2.5 万+保守 7.5 万 | 確認中 |
制約事項¶
- freee MCP: マスターアカウントから 1 AI に対して 1 アカウントのみアクセス可能
- 現時点で 100% 代替はできない。人間とハイブリッドで運用する前提
- 最終承認・月次労務業務結果責任は人間が 100% 担う（変えない）
10. 成功基準¶
10.1 MVP（社内デモ）の成功基準¶
- Slack でメンション → 勤怠集計タスクが生成される
- 方針（Prompt）の承認・却下・再生成が動作する
- 実行ステップ（Process）の承認・却下・再生成が動作する
- 承認後、AI Agent がモックツールを使って勤怠集計を実行し、結果を返す
- 実行中の進捗がリアルタイムで Slack カードに反映される
- エラー発生時に再実行できる
- PM が社内デモとして関係者に見せられる品質
10.2 顧客パイロット（Post-MVP）の成功基準¶
- 実 freee API を使った勤怠集計の E2E 完走
- 顧客環境での 1 ヶ月間の試験運用
- 月次オペレーション工数の定量的削減測定
11. 開発優先順序¶
4 月中完了の制約下で、以下の順序で開発する。Worktree による並列開発を活用する。
| 優先度 | 領域 | 内容 | 備考 |
|---|---|---|---|
| 1 | Slack Bot + パイプライン | L1-L4、承認ゲート、却下再生成、中止、再実行 | コア体験 |
| 1 | 実 freee API 統合 | OAuth 認証、勤怠集計シナリオの 3 ツール | Slack Bot と並行 |
| 2 | Web 管理画面 | Pipeline / Settings / Integrations / Audit の全画面 | 作り込み必要 |
| 0 | 開発基盤 | ハーネス・テスト・CI・Cursor Rules | 最初に整備 |
12. 参考資料¶
| 資料 | 場所 | 内容 |
|---|---|---|
| 設計ドキュメント PDF | raw/Slack MCP Agent — 設計ドキュメント.pdf |
フロー図、Slack UI モック、AI Agent 設計、Caster 既存 UI |
| HR AI Agent ロードマップ | raw/HR AI Agentロードマップ.xlsx |
フェーズ別ユーザーストーリー、スケジュール、HR 業務タスク詳細 |
| HR 業務リスト | raw/HR業務リスト及び業務割合 (1).xlsx |
140+ タスクの詳細定義、ツール利用率統計 |
| 顧客展開資料 | raw/【HR】AIフロント導入_顧客展開資料.xlsx |
顧客要件、判断項目、環境条件、工数削減試算、フローチャート |
| 既存 HR と NEOHR | raw/既存HRとNEOHR.xlsx |
既存 ACC vs NEO ACC 比較、コスト構造、制約事項 |
| アーキテクチャ検討 | outputs/architecture-proposal.md |
マルチテナント、ハイブリッドツール、Skills 設計の検討 |
| Notion 調査 | outputs/agent-development-notion-dive.md |
caster-division-ai の設計思想、Outer/Inner Agent 概念 |
変更履歴¶
| 日付 | バージョン | 変更内容 |
|---|---|---|
| 2026-04-18 | v1.0 | 初版作成 |
| 2026-04-18 | v1.1 | Web 管理画面・実 freee API 統合・中止機能を MVP スコープに追加 |
| 2026-04-18 | v1.2 | Agent Container（Split Pane）をエントリーポイントとして追加 |
| 2026-04-20 | v1.3 | MVP 実装整合に合わせ、Agent Container・監査ログ UI・L4 リアルタイム進捗更新を MVP スコープ外に移動 |