1. 自動化スコープ

どこを自動化し、どこを残すか を明確にします。

「面談」と「人の判断」は祐衣さんに残り、事務作業とデータ転記 がAIと自動化基盤に移ります。

1.1 全体マップ（CA業務の中で何が自動化対象か）

flowchart LR
    subgraph human["祐衣さん（人の判断が残る領域）"]
        Talk[初回・2回目面談<br/>30min×]
        Judge[推薦判断<br/>クロージング]
        Close[企業対応<br/>面接対策]
    end

    subgraph auto["自動化対象（MVP-1〜3）"]
        Prep[面談前準備<br/>事前情報整理]
        Folder[Driveフォルダ自動作成]
        Circus[サーカス転記]
        Minutes[議事録→推薦文ドラフト]
        Receive[書類受領→Drive格納]
    end

    subgraph future["将来フェーズ（Phase 2以降）"]
        Doc[書類添削]
        Interview[面接対策]
        Closing[クロージング支援]
        Lookback[お見送り振り返り]
    end

    Prep --> Talk
    Folder --> Talk
    Receive --> Talk
    Talk --> Minutes
    Minutes --> Judge
    Judge --> Circus
    Judge --> Close
    Close -. 将来 .-> Doc
    Close -. 将来 .-> Interview
    Close -. 将来 .-> Closing
    Close -. 将来 .-> Lookback

    classDef autoStyle fill:#e0f7fa,stroke:#00838f,stroke-width:2px
    classDef humanStyle fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef futureStyle fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px,stroke-dasharray:4 4
    class Prep,Folder,Circus,Minutes,Receive autoStyle
    class Talk,Judge,Close humanStyle
    class Doc,Interview,Closing,Lookback futureStyle

判断の置きどころ

自動化は 「ドラフトを作るところまで」 が原則。サーカス書き込み・LINE送信・推薦確定など、外部に影響が出る操作の最終ボタンは祐衣さん が押す設計です。

1.2 MVP の3本柱

MVP-1 ─ サーカス転記の自動化

現状: ii-ne からサーカス（circus-job.com）へ求職者情報を 手作業で転記。1名10分。

自動化後: 祐衣さんが通知Botに「○○さん登録して」と LINE するだけで、ii-ne の情報をサーカスへ自動入力＆保存。

sequenceDiagram
    participant Yui as 祐衣さん
    participant Bot as 通知Bot（LINE）
    participant System as 自動化基盤
    participant Circus as サーカス

    Yui->>Bot: 「○○さん登録して」
    Bot->>System: コマンド受信
    System->>System: ii-ne から求職者情報取得
    System->>Circus: ログイン→各項目入力→保存
    System->>Bot: 完了通知
    Bot->>Yui: 「○○さん サーカス登録完了」

規約面: 自動化はサーカス利用規約の解釈に基づいた運用ルールで実施します。具体的には以下を遵守する設計です。

リクエスト間隔は最小2秒、同時並列実行は禁止、1日あたりの操作上限は200回、リトライは最大3回
サーカスから取得した個人情報はVPS上に永続化しない（処理完了で即削除）
全操作を監査ログとして記録、画面スクリーンショットを保存
サーカス側から指摘があれば即時停止できる構造
万一規約上の論点が発生した場合、Chrome拡張による半自動モード（祐衣さんが画面前にいる時だけ動く） へ即時切替可能

解釈の根拠は別途「サーカス利用規約解釈合意書」（docs/terms-interpretation.md）に整理しています。

MVP-2 ─ 面談前準備の自動化

現状: 毎朝、その日の面談予定者ごとに ii-ne・Drive・既存書類を確認し、見立てを立てる。1名15分。

自動化後: 毎朝7時に、当日の面談予定者全員分の 初回面談シートが事前情報入りで自動生成 されます。

sequenceDiagram
    participant Cron as 毎朝7時（自動）
    participant GCal as Googleカレンダー
    participant LINE as 公式LINE / ii-ne
    participant AI as Gemini（祐衣さん設計済プロンプト）
    participant Sheets as 初回面談シート
    participant Bot as 通知Bot

    Cron->>GCal: 今日の面談予定取得
    Cron->>LINE: 求職者プロフィール取得
    Cron->>AI: 面談前準備プロンプト実行<br/>（キラー質問／転職理由仮説）
    AI-->>Cron: 分析結果
    Cron->>Sheets: テンプレ複製→事前情報流し込み
    Cron->>Bot: 完了通知
    Bot->>祐衣さん: 「○○さん 面談準備完了」+シートURL

ここで使うのは祐衣さん自身が既に設計済みのプロンプト。

キャリアパス構造化分析＋潜在転職理由仮説3パターン＋キラー質問3つ＋クロージングストーリー設計（ヒアリングシート「プロンプト」シート第1フェーズより）

ゼロから AI に書かせるのではなく、既存資産をそのままパイプラインに乗せる 設計です。

MVP-3 ─ 面談後処理の自動化

現状: Gemini で議事録ができたあと、能力評価・推薦文ドラフト・求人候補ピックアップを順番に作る。1名30分。

自動化後: 議事録が Drive に保存された瞬間、面談後まとめ → 推薦文ドラフト → 求人提案 が連続で走り、求職者フォルダに納品されます。

sequenceDiagram
    participant Drive as Google Drive
    participant System as 自動化基盤
    participant AI as Gemini
    participant Bot as 通知Bot

    Drive->>System: 新規議事録ファイル検出（5分毎）
    System->>AI: 面談後まとめプロンプト
    System->>AI: 推薦準備プロンプト
    System->>AI: 求人紹介プロンプト
    AI-->>System: 全成果物
    System->>Drive: 求職者フォルダにMarkdown保存
    System->>Bot: 完了通知
    Bot->>祐衣さん: 「○○さん 成果物完成」+リンク

成果物は ドラフト として保存されます。最終的な推薦・送信は祐衣さんがレビューしてから。

1.3 自動化「しない」もの（明示的に範囲外）

ここを明確にしておくことで、過剰な自動化による事故 を避けます。

項目	なぜ範囲外か
スカウト工程	別担当（アシスタント業務）
面接対策・クロージング・お見送り振り返り	求職者個別性が高く、初期スコープからは外す
求職者へのメッセージ自動送信	LINE送信は半自動（生成→通知→祐衣さんが内容確認後に送信）
サーカス書き込みの無人化	祐衣さんからの明示的指示（LINE Botコマンド）を起点に動作

1.4 期待効果

時間削減（パイロット完了時）

求職者1名あたり：60min → 5min の事務削減。

担当案件 30件/月で換算すると 月 27.5 時間 の解放。

質の改善

AIプロンプト資産が 毎回100%適用 される（手作業の漏れがなくなる）
求職者ごとの情報が 同一フォーマット で蓄積される（後の振り返り・横展開に効く）
議事録〜推薦文の タイムラグが10分以内（鮮度の高い推薦が出せる）

確認ポイント（章末）

ここまで読んだ段階で、祐衣さんに確認したい2点：

MVP-1〜3 の順序（サーカス転記 → 面談前準備 → 面談後処理） で問題ないか？
特にサーカス転記を最優先にしている理由は「最も日々の手作業負荷が高い」と理解していますが、別の順序を希望される場合はその旨を。
「自動化しない」リスト に追加すべき項目はあるか？
特に「LINE送信の無人化」「推薦の自動送信」など、人の判断を残すべき と感じる工程があれば。

次の章

➡️ 2. アーキテクチャ概観 ── どのような基盤の上で動くか