AI導入ロードマップ

【どんな仕事・組織か】 社員30名ほどの中小企業で、総務・経理・営業事務を兼任しています。 主な業務は、 ・問い合わせ対応 ・請求書処理 ・経費精算 ・営業案件の進捗確認 ・期限管理 ・定型メール作成 ・週次集計、報告 ・社内連絡 です。 【現在の業務上の課題】 ・期限や未対応案件を人が探している ・経費申請の不備確認に時間がかかる ・同じようなメールを何度も作っている ・週次集計と報告を手作業で行っている ・複数の管理表に同じ情報を転記している ・管理表を増やした結果、どれが最新か分からなくなったことがある ・AIや自動化の確認作業が増えるのは避けたい 【導入したいAI活用候補】 ・会議メモからTODO候補を整理する ・定型メールの下書きを作る ・長いメールの要点を整理する ・確定済みの週次集計結果から報告文を作る ・文章の誤字、表現をチェックする 【導入したい自動化候補】 ・期限間近、期限超過案件の検出 ・長期間未更新案件の検出 ・担当者、期限未設定案件の検出 ・経費申請の必須項目チェック ・定型メールのテンプレート化 ・週次集計の更新 ・同じ情報の転記削減 【優先順位が高い候補】 これまでの検討では、 1. 期限、未対応案件の検出 2. 経費申請の必須項目、形式チェック 3. 定型メールのテンプレート化 4. 会議メモからTODO候補を整理 5. 週次報告文の下書き の順で試したいと考えています。 【後回しにしたい候補】 ・すべてのメールをAIで要約する ・複数システムをAPIで一括連携する ・RPAによる画面操作の自動化 ・請求書を外部AIで読み取って自動登録する 【現時点では導入しない候補】 ・AIによる支払判断 ・請求金額の確定、変更 ・契約判断 ・経費精算の最終承認 ・顧客への重要メールの自動送信 ・法務、税務上の最終判断 【すでに試したこと】 メールをChatGPTへ貼り付けて要約する方法を試しました。 また、ExcelやGoogle Sheetsの関数による集計、Calendar通知、一部のメールテンプレートは利用しています。 【試した結果】 メール要約は、 ・コピーする手間がある ・機密情報を消す手間がある ・短いメールでは自分で読んだ方が早い ため定着しませんでした。 一方、関数やCalendar通知は継続して使えています。 【現在使っているツール】 ・GmailまたはOutlook ・Excel ・Google Sheets ・Google Drive ・SlackまたはTeams ・Google Calendar ・会計ソフト ・請求管理システム ・CRMまたは案件管理表 ・ChatGPT 【正本となるシステム・データ】 完全には整理できていません。 今後は、 ・案件情報はCRMまたは既存案件管理表 ・請求情報は請求管理システム ・会計情報は会計ソフト を正本にしたいです。 新しいAI専用管理表は増やしたくありません。 【AI導入に使える人員】 自分を含む2～3名です。 専任のIT担当はいません。 【AI導入に使える時間】 通常業務と並行して進めます。 毎日メンテナンスが必要な仕組みは避けたいです。 【予算や開発の制約】 最初は追加開発や高額ツールを使わず、既存機能で試したいです。 【API連携やシステム開発の可否】 効果が確認できてから検討します。 最初からAPI連携、独自開発、RPAを導入する予定はありません。 【扱っている情報の機密性】 ・顧客名 ・担当者名 ・メールアドレス ・請求金額 ・振込情報 ・契約内容 ・売上情報 ・社員情報 ・経費情報 などを扱います。 【AIへ入力してよい情報の範囲】 明確な社内ルールはありません。 顧客情報、請求情報、契約情報などを外部AIへそのまま入力することには抵抗があります。 初期検証では、架空データや匿名化データを使いたいです。 【人の確認を必ず残したい業務】 ・支払実行 ・請求金額の確定 ・契約内容の確定 ・経費精算の最終承認 ・顧客への重要回答 ・売上、入金の最終確認 ・社外への正式送信 【AIに任せたくない業務】 ・支払判断 ・契約判断 ・経費承認 ・顧客との重要な交渉 ・社員評価 ・法務、税務上の最終判断 【導入によって期待している効果】 ・確認時間を減らす ・期限や対応漏れを減らす ・定型作業を減らす ・転記を減らす ・週次業務を楽にする ・確認負担を増やさない 【効果を確認するために測れそうなこと】 ・対象確認にかかる時間 ・期限超過、対応漏れ件数 ・不備申請の発見件数 ・メール作成時間 ・週次集計、報告にかかる時間 ・自動化後の確認時間 ・誤検出や修正が必要だった件数 ・保守にかかる時間 【導入対象とする部署・人数】 最初は総務・経理・営業事務の2～3名だけで試します。 【将来的に展開したい範囲】 効果が確認できれば、 ・営業 ・他の管理部門 にも展開できるものは広げたいです。 ただし、部署ごとの業務が違う場合は同じ仕組みを無理に使いたくありません。 【特に確認したいこと】 ・最初の小規模検証をどう設計するべきか ・どこまで進めたら限定運用へ移るべきか ・本運用へ進む条件は何か ・効果が出なかった場合はどの段階で止めるべきか ・APIや開発を検討するタイミング ・人の確認をいつまで残すべきか ・AIを使わない方がよい候補は何か ・横展開する前に何を標準化するべきか

# 【ロードマップの結論】 AI導入ではなく、**確認時間・期限漏れ・不備・転記を減らし、確認・保守を含む総負担を下げること**を目的とします。 進め方は次の順序です。 1. 正本、項目、判定条件、情報取扱いを整備する 2. 既存ツールの標準機能で、1候補ずつ小規模検証する 3. 総作業時間の削減と安全性を確認できた候補だけ限定運用する 4. 限定運用で安定した候補だけ定常業務にする 5. 手作業のデータ取得・転記だけが残った場合に、CSV、既存コネクタ、読み取り専用APIの順で検討する 6. 他部署では同じ仕組みをそのまま配らず、部署ごとに再検証する 優先順は以下です。 1. 期限・未対応案件の検出 2. 経費申請の必須項目・形式チェック 3. 定型メールのテンプレート化 4. 週次集計の更新 5. 会議メモからTODO候補を整理 6. 確定済み週次集計から報告文を作成 7. 重複転記の削減 8. 文章の誤字・表現チェック ただし、期限検出は案件情報の正本が決まらないと開始できません。正本確定に時間がかかる場合は、並行して定型メールの検証を先に始めます。 以下の数値基準は、利用者の実績に基づく確定基準ではなく、**初期検証用の仮説的な目安**です。 - 小規模検証：2～4週間、週次業務は4回程度 - 限定運用：繁忙週などを含む8週間程度 - 総作業時間：従来比20％以上削減 - 誤検出・誤警告：20％以下 - 保守時間：週30分以内 実際の業務量と現状値を測定した後、基準を調整します。 # 【導入対象】 | 候補 | 整理内容 | |---|---| | **1. 期限・未対応・長期未更新・未設定案件の検出** | **対象業務**：営業案件、問い合わせ、期限管理の確認。<br>**任せること**：関数、フィルター、保存済みビュー、条件付き書式による候補抽出。<br>**人に残すこと**：対応要否、保留・例外判断、担当者・期限・ステータスの更新。<br>**現在の段階**：第0段階。案件情報の正本と判定条件が未確定。<br>**次に行うこと**：CRMか既存案件管理表のどちらを正本にするか決め、架空案件で抽出条件をテストする。<br>**次段階へ進む条件**：重大な期限超過の見逃しがなく、手作業確認より総時間が減り、条件変更が頻発しない。<br>**主なリスク**：正本未更新による誤検出、通知過多、完了・保留案件の誤通知。<br>**停止・縮小条件**：重要案件の見逃し、誤通知が多い、正本が更新されない、保守負担が削減時間を上回る。 | | **2. 経費申請の必須項目・形式チェック** | **対象業務**：経費申請の一次確認・事前チェック。<br>**任せること**：空欄、日付・金額形式、添付有無、例外欄の警告。<br>**人に残すこと**：本当に不備か、例外処理、費目・税務処理、差し戻し、最終承認。<br>**現在の段階**：第0段階。正本と正式なチェック条件が未確定。<br>**次に行うこと**：経費チェックリストを作り、架空申請で入力規則等をテストする。<br>**次段階へ進む条件**：重大な必須項目の見逃しがなく、正常申請への誤警告と確認時間が許容範囲内。<br>**主なリスク**：正当な例外への過剰警告、規程と設定の不一致、申請者の入力負担増加。<br>**停止・縮小条件**：重要不備の見逃し、誤警告の多発、例外の大半が手作業になる、申請を不当に止める。 | | **3. 定型メールのテンプレート化** | **対象業務**：社内期限確認、進捗確認、書類不備確認など。<br>**任せること**：Gmail／Outlookの標準機能による定型本文の呼び出し。<br>**人に残すこと**：宛先、氏名、案件、期限、金額、添付、本文、送信操作。<br>**現在の段階**：一部利用済みだが、効果未測定のため第1段階前。<br>**次に行うこと**：件数の多い2～3種類を正式テンプレート化し、作成時間を比較する。<br>**次段階へ進む条件**：修正を含めた作成時間が減り、2名以上が利用でき、重大な送信ミスがない。<br>**主なリスク**：古い文面、差し込み漏れ、テンプレート乱立、適さないメールへの利用。<br>**停止・縮小条件**：手入力より遅い、重大ミスが増える、大幅修正が常態化する。 | | **4. 週次集計の更新** | **対象業務**：案件・請求等の確定データからの週次集計。<br>**任せること**：関数、ピボット、Power Query、標準レポートによる集計更新。<br>**人に残すこと**：対象期間、除外条件、元データとの差異、数値の最終確定。<br>**現在の段階**：一部関数は利用済み。集計仕様の標準化が必要。<br>**次に行うこと**：集計元、締め時点、指標、確定者を決め、過去の確定値と照合する。<br>**次段階へ進む条件**：確定済み過去データと一致し、更新・照合を含む時間が減る。<br>**主なリスク**：古いCSV、列変更、計上基準の不一致、誤った対象期間。<br>**停止・縮小条件**：確定値との差異が続く、毎週式の修正が必要、照合負担が増える。 | | **5. 会議メモからTODO候補を整理** | **対象業務**：機密性の低い社内定例会議のメモ整理。<br>**任せること**：決定事項、TODO候補、担当者・期限候補、不明点の抽出。<br>**人に残すこと**：TODOの採否、担当者・期限の確定、正式登録。<br>**現在の段階**：第0段階。実データのAI入力ルール未整備。<br>**次に行うこと**：架空議事録で抽出精度と確認時間を測る。<br>**次段階へ進む条件**：重要TODOの見逃しが少なく、確認・修正を含めて短縮でき、入力情報の社内ルールが決まる。<br>**主なリスク**：未決事項のTODO化、担当者・期限の創作、機密情報の外部入力。<br>**停止・縮小条件**：重要TODOを見逃す、創作が続く、確認時間が減らない、入力ルール違反が起きる。 | | **6. 確定済み週次集計から報告文を作成** | **対象業務**：確定済み数値を使った週次報告文1種類。<br>**任せること**：固定構成に沿った文章の下書き。<br>**人に残すこと**：数値、期間、増減方向、要因、表現、報告先、正式送信の確認。<br>**現在の段階**：第0段階。集計仕様とAI入力ルールの整備が必要。<br>**次に行うこと**：匿名化した過去報告で、AI、固定文、関数方式を比較する。<br>**次段階へ進む条件**：数値や事実を変更せず、照合を含む総時間が短縮する。<br>**主なリスク**：数値変更、原因の創作、未確定値の利用、照合作業の増加。<br>**停止・縮小条件**：数値・事実誤りが続く、短い報告で手作業の方が早い、二重確認が増える。 | | **7. 重複転記の削減** | **対象業務**：CRM、請求管理、会計、週次資料間の重複入力。<br>**任せること**：参照式、CSV、インポート、既存コネクタによる再入力削減。AIは原則使わない。<br>**人に残すこと**：取込元、対象期間、件数、金額合計、失敗件数の確認。<br>**現在の段階**：業務整理段階。転記経路と正本が未整理。<br>**次に行うこと**：転記元・転記先・項目・頻度・時間を棚卸しし、不要な転記先を廃止する。<br>**次段階へ進む条件**：正本と一意IDが決まり、既存機能で安全に照合できる。<br>**主なリスク**：新たな管理表の増加、古いデータ、重複取込、正本不明。<br>**停止・縮小条件**：照合負担が増える、二重登録が起きる、正本との不一致が継続する。 | | **8. 文章の誤字・表現チェック** | **対象業務**：社内文、報告文、機密情報を含まない一般文。<br>**任せること**：誤字、冗長表現、読みやすさの改善候補提示。<br>**人に残すこと**：事実、数値、固有名詞、意味の変化、最終確定。<br>**現在の段階**：すぐ試せるが、優先度は低い。<br>**次に行うこと**：メールソフト等の標準校正機能とAIを比較する。<br>**次段階へ進む条件**：誤修正が少なく、確認を含めて時間が減る。<br>**主なリスク**：意味変更、新しい事実の追加、機密情報の入力。<br>**停止・縮小条件**：標準校正機能で十分、誤修正確認の方が時間を要する。 | # 【第0段階：導入前整備】 - **対象** - 優先5候補を中心とした正本、項目、判定条件、情報取扱い - 特に期限検出と経費チェックを優先する - **実施内容** - 案件、経費、週次集計、TODOの正本を決める - 「期限超過」「未対応」「長期未更新」「必須不備」などを定義する - AIへの入力可否と匿名化方法を決める - 現行作業時間、件数、不備、見逃し件数を測定する - 責任者、代替担当者、停止・手動復帰手順を決める - **人の確認** - 業務責任者が項目定義と判定条件を承認する - 経理責任者が経費チェック条件を確認する - 情報管理上問題のあるデータをAIへ入力しない - **記録すること** - 現行の作業時間と件数 - 正本、更新責任者、例外条件 - 現在発生している見逃し、不備、修正、転記 - 使用ツールと権限 - **次段階への条件** - 対象業務の正本と責任者が決まっている - テスト用の架空・匿名化データがある - 現状値を測定できる - 元に戻す方法がある - **中止条件** - 正本を決められない - 判定条件が担当者ごとに大きく異なる - 検証のために新たな重複管理表が必要になる - 外部AIへの入力ルールを決められない候補は、AI検証を保留する # 【第1段階：小規模検証】 - **対象** - 原則1候補ずつ - 最初は期限検出。正本確定が遅れる場合は定型メールを先行 - 2～3名、1業務、架空・匿名化データに限定 - **実施内容** - 現行手順と新手順を同じ条件で比較する - 事前に正解データを作り、検出・出力結果と照合する - 正本への書き込み、自動通知、自動送信は行わない - AIを使う候補では、採用・修正・削除・見逃しを記録する - **人の確認** - 全件を人が確認する - AI・自動化の結果は候補・警告・下書きとして扱う - 正式な更新は既存手順で人が行う - **記録すること** - 従来時間 - 新手順の作成、確認、修正、保守時間 - 検出数、誤検出、見逃し、修正数 - 手動へ戻した回数 - 情報取扱い上の問題 - **次段階への条件** - 総作業時間が減る傾向がある - 重大な見逃し、誤送信、情報漏えいがない - 2名以上が同じ手順を再現できる - 保守が日常的な追加負担にならない - 例外を従来手順へ安全に戻せる - **中止条件** - 総時間が従来以上 - 重大な見逃しや誤りが発生 - 毎日設定修正が必要 - 利用者が継続利用しない - 機密情報を誤入力した、またはその疑いがある # 【第2段階：限定運用】 - **対象** - 小規模検証に合格した候補のみ - 総務・経理・営業事務の2～3名、1種類の業務に限定 - **実施内容** - 実データを扱う場合も、期限検出等は読み取り専用とする - 経費チェックは警告のみ - 定型メールは判断の少ない社内連絡に限定 - AI候補は承認済み環境または認められた匿名化方法で利用 - 月末・繁忙週・例外案件を含めて評価する - **人の確認** - 期限候補の対応要否 - 経費の差し戻し・最終承認 - メールの宛先・期限・添付・送信 - TODOの確定・登録 - 週次報告の全数値・事実 - **記録すること** - 総作業時間と削減率 - 誤検出、見逃し、例外、手動復帰 - 保守時間と条件変更回数 - 利用率、利用回避、問い合わせ - 正本以外の表や個人コピーの増加 - **次段階への条件** - 仮説的な目安として8週間程度安定している - 総時間が従来比20％以上減る傾向がある - 重大事故がない - 保守時間が週30分程度以内 - 責任者以外も停止・復旧できる - 利用手順を1ページ程度にまとめられる - **中止条件** - 重要な見逃し、誤送信、誤承認への影響 - 対象の半数前後が例外処理になる - 誤検出・誤警告が継続的に多い - 二重チェックやログ確認が新しい負担になる - 個人管理表や類似テンプレートが増える # 【第3段階：本運用】 - **対象** - 限定運用で安定した範囲のみ - 最初の有力候補は、定型メール、読み取り専用の期限検出、経費の警告表示 - 会議TODOと週次報告文は慎重に限定運用を継続する - **実施内容** - 正式な定常業務として手順・責任者・対象外を明文化する - テンプレート、抽出条件、プロンプトの最新版を一か所で管理する - 月次で効果と問題を確認する - 本運用後3か月は重点監視し、その後は四半期ごとに見直す - **人の確認** - 金額、支払、契約、承認、重要回答、社外送信は恒久的に残す - AI生成文は本運用後も人が確認する - ルールベースの警告のみ、実績に応じて全件確認から例外確認への変更を検討できる - **記録すること** - 総時間、見逃し、誤検出、修正、保守 - 重大事故と情報取扱い上の問題 - 例外率、利用率、手動復帰 - 条件・テンプレート・プロンプトの変更履歴 - **次段階への条件** - 連携しなくても十分なら第3段階で完了とする - データ取得・CSV・転記だけが主要な残作業になった場合に第4段階を検討する - 他部署でも同じ業務目的がある場合だけ第5段階を検討する - **中止条件** - 総時間削減が継続しない - 保守負担が増加する - 重大事故、情報漏えい、正本破損が発生する - 作成者以外が保守・復旧できない - 正本以外の管理表が増える # 【第4段階：連携・開発】 - **対象** - 第一候補：期限・未対応案件の読み取り専用API - 第二候補：週次集計用データの取得 - 経費チェック、メールテンプレート、会議TODO自動登録は原則対象外 - **実施内容** - 標準機能、CSV、Power Query、既存コネクタ、APIの順で検討する - APIは読み取り専用から開始する - 一意ID、重複防止、エラーログ、再実行、停止・復旧を設計する - 公式API、OAuth等の正規認証、最小権限を利用する - 独自開発より既存システムの追加機能や市販サービスを先に比較する - **人の確認** - 取得元、対象期間、件数、失敗件数 - 正本との一致 - 書き込みを行う場合は更新前後と重複の有無 - 障害時の未処理データ - **記録すること** - 実行日時、対象ID、件数、成功・失敗 - エラー、再実行、連携バージョン - 開発・保守費用と削減時間 - 認証・権限変更履歴 - **次段階への条件** - 標準機能・CSVでは解消できない残作業が明確 - 同じ作業が高頻度で発生 - 仮説的な目安として、データ取得・転記が週1時間以上残るなど、開発効果を説明できる - 正本、項目、一意ID、例外、責任者が安定 - 保守担当と予算を確保できる - 停止・復旧・重複防止をテスト済み - **中止条件** - 月数十分程度しか削減できない - 保守担当がいない - 公式APIや安全な認証が利用できない - 書き込み失敗を復旧できない - 開発費・保守費が効果に見合わない # 【第5段階：横展開】 - **対象** - 優先順：定型メール、期限検出、経費チェック、週次報告 - 会議TODOは会議種別ごとの個別運用とする - **実施内容** - 1部署、1業務、1～2名から再検証する - 共通部分と部署固有部分を分ける - 部署ごとの正本、承認経路、機密区分、例外率を確認する - 4～8週間程度を仮説的な目安として効果を再測定する - 同時に複数部署へ展開しない - **人の確認** - 各部署の業務責任者が判定条件と対象外を承認する - 送信、承認、金額、契約等の確認は部署展開後も残す - 権限範囲が他部署データまで広がっていないか確認する - **記録すること** - 部署別の総時間、誤り、例外、利用率 - 保守時間、利用料、問い合わせ - 個人管理表や独自テンプレートの増加 - 部署固有の変更点 - **次段階への条件** - 元部署と業務目的、正本、承認水準が近い - 部署内でも効果が再現できる - 標準化によって入力負担が増えない - 部署の責任者・代替担当者を置ける - **中止条件** - 部署固有の例外が多い - 共通化によって業務が複雑になる - 権限過剰や情報漏えいリスクが生じる - 総時間が減らない - 個人管理や重複台帳が増える # 【最初に着手する候補】 **期限・未対応・長期未更新・未設定案件の検出**です。 AIは使わず、CRMまたは既存案件管理表の標準機能、Excel／Google Sheetsの関数・フィルター・条件付き書式を使います。 ただし、最初の作業は通知設定ではなく、次の確認です。 - 案件情報の正本をCRMと案件管理表のどちらにするか - 案件ID、担当者、ステータス、期限、最終更新日がそろっているか - 完了、保留、期限未定の扱い - 期限間近、長期未更新、未対応の具体的定義 - 誰が検出結果を確認して正本を更新するか これが短期間に決められない場合は、定型メールのテンプレート化を先行します。 # 【最初のテスト方法】 1. 正常、期限間近、期限超過、完了、保留、担当者未設定、期限未設定を含む架空案件を作る 2. 人が事前に「検出されるべき案件」を正解データとして決める 3. 関数、フィルター、保存済みビュー等で候補を抽出する 4. 正解データと比較し、誤検出・見逃しを確認する 5. 手作業で探した時間と、自動抽出後に確認した総時間を比較する 6. 問題がなければ、実データのコピーまたは読み取り専用ビューで限定検証する 7. 初期段階では自動通知、正本への自動書き込み、自動催促を行わない テスト件数や期間は実際の案件量に応じて決めます。過去工程で示した30～50件、2～4週間などは、あくまで初期検証用の目安です。 # 【本運用まで人の確認を残す部分】 ## 本運用後も恒久的に残す確認 - 支払判断と支払実行 - 請求金額の確定・変更 - 契約内容の確定 - 経費精算の最終承認 - 売上・入金の最終確認 - 法務・税務判断 - 顧客への重要回答 - 社外への正式送信 - AI生成文の事実、数値、固有名詞の確認 ## 限定運用までは全件確認を残すもの - 期限・未対応候補の対応要否 - 経費申請の警告が本当に不備か - 会議TODOの採否、担当者、期限 - 週次報告の全数値・増減方向 - テンプレートメールの宛先・期限・添付 ルールベースの機械的チェックに限り、十分な運用実績が得られた後、「全件確認」から「警告・例外中心の確認」への変更を検討できます。 # 【API・開発を検討するタイミング】 以下をすべて満たした後です。 - 標準機能による本運用で効果を確認済み - CSV、Power Query、既存コネクタでも残作業を解消できない - コピー、データ取得、転記だけが主要な残作業 - 同じ作業が毎日または週に複数回発生する - 削減できる時間、ミス、費用を定量化できる - 正本、一意ID、項目、例外処理が安定している - 保守担当者、代替担当者、予算を確保できる - 認証、最小権限、ログ、重複防止、停止・復旧を設計できる 最初の候補は、**期限・未対応案件の読み取り専用API**です。正本への書き込み、自動催促、自動送信は別段階として審査します。 # 【現時点では導入しないもの】 - AIによる支払判断・支払実行 - AIによる請求金額の確定・変更 - AIによる契約判断、経費承認、法務・税務上の最終判断 - 顧客への重要メール・正式回答の自動送信 - 全メールのAI要約 - 請求書を外部AIで読み取り自動登録する仕組み - 複数システムの一括API連携 - 正本への書き込み型AI・API連携 - RPAによる画面操作・転記 - 新しいAI専用管理表や独自台帳 - 会議TODOの自動登録、担当者・期限の自動確定 - 週次集計の計算・数値確定を生成AIに任せること # 【導入前に整備すべきこと】 1. **正本と正式な保存先** - 案件、経費申請、週次集計、TODOの正本を一つずつ決める 2. **項目・判定条件** - 担当者、期限、ステータス、更新日、未対応、完了、保留、例外を定義する 3. **AI情報取扱いルール** - 入力可、匿名化すれば可、入力禁止の3区分と、利用可能アカウントを決める 4. **責任・権限・手動復帰** - 業務責任者、代替担当者、変更権限者、停止判断者、復帰手順を決める 5. **現状値と評価方法** - 現行時間、件数、見逃し、不備、修正、転記、保守時間を測定する # 【ロードマップを見直す条件】 - 正本システムや業務手順が変更された - 経費規程、承認経路、テンプレートの利用目的が変更された - AIサービスの規約、データ保存、学習利用、料金、セキュリティ条件が変わった - 総作業時間の削減が続かない - 誤検出、見逃し、修正、例外が増えた - 保守時間が削減時間を上回った - 個人管理表、重複台帳、類似テンプレートが増えた - 情報漏えい、誤送信、正本破損、重大な見逃しが発生した - 責任者や代替担当者が不在になった - 他部署展開によって業務差・権限差が明らかになった 見直し結果は、機能追加だけでなく、対象縮小、通知停止、ルール単純化、標準機能への置き換え、完全な手動運用への復帰を含みます。 # 【次の行動】 1. **案件情報の正本を決める** - CRMと既存案件管理表の役割を整理し、期限検出に使う正本を一つ決定する 2. **期限検出の判定条件と架空テストデータを作る** - 期限間近、超過、未対応、長期未更新、担当者・期限未設定、完了・保留を定義する 3. **現状値を1～2週間測定する** - 案件確認時間、見逃し件数、経費確認時間、メール作成時間、週次作業時間を記録する 4. **AI情報取扱いの暫定ルールを1ページで作る** - 初期は実在の顧客・請求・契約・社員情報を外部AIへ入力しない方針を明記する 5. **期限検出を1候補だけ小規模検証する** - 誤検出・見逃し・総時間・保守時間を測定し、効果がなければ通知や開発へ進まず、条件縮小または手動確認へ戻す

【どんな仕事・組織か】 社員15名ほどのWeb制作会社で、ディレクターとして複数案件を管理しています。 主な業務は、 ・顧客とのメール、Slack対応 ・打ち合わせ ・修正依頼の整理 ・制作担当への共有 ・タスク登録 ・期限、進捗管理 ・決定事項、未決事項の管理 ・顧客への進捗報告 ・資料管理 です。 【現在の業務上の課題】 ・案件情報がメール、Slack、議事録、タスク管理ツール、Driveに分散している ・会議後のTODO整理に時間がかかる ・修正依頼をタスク化するのに時間がかかる ・Slack上の決定事項を正式記録へ反映し忘れる ・担当者、期限未設定タスクが残る ・複数案件の進捗確認に時間がかかる ・同じ情報を複数ツールへ転記している ・AI用の別管理表は増やしたくない 【導入したいAI活用候補】 ・会議メモから決定事項、TODO、未決事項を整理 ・修正依頼をタスク候補へ分解 ・顧客メールから依頼事項を整理 ・指定したSlackスレッドを要約 ・タスク情報から案件進捗を要約 ・顧客向け進捗メールを下書き ・正式記録から過去の決定経緯を整理 【導入したい自動化候補】 ・担当者、期限未設定タスクの検出 ・期限間近、期限超過タスクの検出 ・長期間未更新タスクの検出 ・タスク管理ツール内の案件進捗ビュー ・タスク情報の転記削減 ・資料保存先、命名ルールの統一 ・AIで作成したタスク候補の登録補助 【優先順位が高い候補】 これまでの検討では、 1. 担当者、期限未設定タスクの検出 2. 期限、未更新タスクの検出 3. タスク管理ツール内の案件進捗ビュー 4. 会議メモからTODO候補を整理 5. 修正依頼をタスク候補へ分解 6. 顧客向け進捗メールの下書き の順で進めたいです。 【後回しにしたい候補】 ・メール、Slack全体の常時AI要約 ・複数ツールを横断する決定経緯検索 ・AI抽出結果のAPI自動登録 ・複数システムへの自動書き込み ・独自の案件管理システム開発 【現時点では導入しない候補】 ・AIによる仕様変更判断 ・AIによる追加費用判断 ・AIによる納期確定 ・AIによる担当者、期限の推測確定 ・AI抽出TODOの無確認登録 ・顧客への重要メールの自動送信 ・案件完了の自動判定 【すでに試したこと】 ChatGPTで、 ・会議メモの要約 ・TODO候補の抽出 ・メール文面の下書き を試したことがあります。 また、タスク管理ツールの期限通知、Calendar通知、一部のSlack通知を利用しています。 【試した結果】 会議TODO抽出では、 ・存在しない担当者を補う ・期限未定なのに期限を作る ・提案と決定を混同する ことがありました。 そのため、AI出力をそのまま正式登録するのは危険だと考えています。 また、案件管理用Sheetsを増やした結果、タスク管理ツールと更新差が生まれたことがあります。 【現在使っているツール】 ・GmailまたはOutlook ・SlackまたはTeams ・Google Drive ・Google Docs ・Google Sheets ・Google Calendar ・ZoomまたはGoogle Meet ・Backlog、Asana、Trello、Notionなどのタスク管理ツール ・Figma ・ChatGPT 【正本となるシステム・データ】 今後は、 ・タスク、担当者、期限、進捗はタスク管理ツール ・正式な議事録、仕様、決定事項は指定した文書 ・最新版デザインはFigma ・ファイルは指定したDriveフォルダ を正本にしたいです。 メールやSlackは経緯や根拠として扱い、AI出力は候補・下書きとします。 【AI導入に使える人員】 ディレクター2名ほどです。 専任のIT担当はいません。 【AI導入に使える時間】 通常案件と並行して進めます。 毎日のメンテナンスが必要な仕組みは避けたいです。 【予算や開発の制約】 最初は既存機能と手動確認で試したいです。 追加開発は、効果が確認できてから検討します。 【API連携やシステム開発の可否】 最初は行いません。 手動検証や標準連携で効果が確認でき、転記だけがボトルネックとして残った場合に検討したいです。 【扱っている情報の機密性】 ・顧客名 ・担当者情報 ・未公開サイト ・未公開デザイン ・契約内容 ・見積金額 ・納期 ・顧客とのやり取り ・ログイン情報を含む資料 などを扱います。 【AIへ入力してよい情報の範囲】 明確な社内ルールはありません。 初期検証では架空データ、匿名化した過去案件、機密性の低い情報を使いたいです。 ログイン情報、パスワード、APIキーなどはAIへ入力しません。 【人の確認を必ず残したい業務】 ・顧客要望の最終解釈 ・仕様変更 ・追加費用 ・納期変更 ・タスクの正式登録 ・担当者、期限の確定 ・重要な顧客回答 ・案件完了判断 ・社外への正式送信 【AIに任せたくない業務】 ・仕様変更の決定 ・追加費用の判断 ・納期の正式決定 ・担当者、期限の推測確定 ・顧客との重要な約束 ・クレーム対応 ・案件完了判断 【導入によって期待している効果】 ・会議後の整理時間を減らす ・タスク登録漏れを減らす ・修正依頼整理を楽にする ・進捗確認時間を減らす ・転記を減らす ・決定事項を追いやすくする ・確認負担や保守負担を増やさない 【効果を確認するために測れそうなこと】 ・会議後の整理時間 ・修正依頼のタスク化時間 ・登録漏れ件数 ・担当者、期限未設定件数 ・期限超過、未更新件数 ・AI抽出結果の修正件数 ・タスク登録後の修正件数 ・進捗確認時間 ・転記回数 ・保守時間 【導入対象とする部署・人数】 最初はディレクター2名と、1～2案件程度で試します。 【将来的に展開したい範囲】 効果が確認できれば、 ・他のディレクター ・制作担当 ・案件数の拡大 を検討します。 ただし、案件種別や顧客ごとの運用差が大きい場合は一律展開しません。 【特に確認したいこと】 ・会議TODO抽出をどの段階で実業務へ入れるべきか ・AI出力を正式タスクへ反映するまでに何段階必要か ・手動登録から標準連携へ移る条件は何か ・API自動登録を検討するタイミング ・AI用の別管理表を作らず進められるか ・正本をどう維持するべきか ・どこまで人の確認を残すべきか ・APIへ進まず止める条件は何か ・横展開前に標準化するべきことは何か

# 【ロードマップの結論】 導入順は、次のとおりとします。 1. **正本、タスク項目、ステータス、情報取扱いを整備する** 2. **AIを使わず、タスク管理ツールの標準機能で未設定・期限・未更新を検出する** 3. **匿名化データで会議メモ抽出をシャドー検証する** 4. **タスク入力ルールが安定した後、タスク管理ツール内に進捗ビューを作る** 5. **会議メモ抽出が安定した後、定型的な修正依頼のタスク分解を検証する** 6. **正本上の進捗情報が安定した後、顧客向け進捗メールの下書きを検証する** 7. **確認後の転記だけが負担として残った場合、テンプレート、CSV、標準連携を試す** 8. **標準機能で解消できず、利用頻度と削減効果が十分な場合に限りAPIを検討する** 9. **候補ごと・案件種別ごとに横展開を判断する** 当面の完成形は、必ずしもAPI連携ではありません。 **保存ビュー、標準通知、AIによる候補作成、人による確認・登録で効果が出るなら、その段階を本運用とします。** 現時点では限定運用の実績値がないため、直ちに本運用、API開発、全社展開へ進める候補はありません。 なお、以下で示す期間、削減率、誤検出率、保守時間などの数値は、利用者の確認済み実績ではなく、**初期検証のための仮説的な目安**です。導入前の実測値を取得した後、2名で正式な判定基準を決めます。 --- # 【導入対象】 ## 1. 担当者・期限未設定タスクの検出 | 項目 | 内容 | |---|---| | 対象業務 | タスク登録後、週次確認時の設定漏れ点検 | | AIまたは自動化に任せること | タスク管理ツールの保存ビュー・フィルター・標準通知による条件抽出 | | 人に残すこと | 未設定が許容されるかの判断、担当者・期限の確定、正本の更新 | | 現在の段階 | 第0段階。検出条件の確定前 | | 次に行うこと | 「担当者なし」「期限なし」の保存ビューを作り、意図的な未設定の除外条件を決める | | 次段階へ進む条件 | 真の設定漏れを安定して検出できる、不要な検出を除外できる、確認時間が減る、2名が同じ基準で使える | | 主なリスク | 保留・メモ用タスクの過剰検出、通知疲れ、通知を見ただけで未対応になること | | 停止・縮小条件 | 不要な検出が多くルールで除外できない、通知が無視される、確認負担が従来を上回る | --- ## 2. 期限間近・期限超過・長期間未更新タスクの検出 | 項目 | 内容 | |---|---| | 対象業務 | 日次・週次の期限確認、遅延・停滞の早期把握 | | AIまたは自動化に任せること | 期限、最終更新日、ステータスによる保存ビュー・標準通知 | | 人に残すこと | 実際の遅延かの確認、期限変更、顧客連絡、優先順位の判断 | | 現在の段階 | 第0段階。日数・除外条件の確定前 | | 次に行うこと | 期限間近、期限超過、未更新の仮条件を設定し、保留・顧客確認待ちの除外を決める | | 次段階へ進む条件 | 重要タスクを見落とさない、不要通知が許容範囲、確認時間が減る、通知後の対応手順が定着する | | 主なリスク | 通知過多、形式的なコメント更新、安易な期限変更、保留タスクへの過剰通知 | | 停止・縮小条件 | 重要通知が埋もれる、通知が放置される、誤検出が継続する、条件保守の負担が大きい | --- ## 3. タスク管理ツール内の案件進捗ビュー | 項目 | 内容 | |---|---| | 対象業務 | 案件別・担当者別・期限別・ステータス別の進捗確認 | | AIまたは自動化に任せること | タスク管理ツール内の標準ビュー、ダッシュボード、集計表示 | | 人に残すこと | 表示と実態の照合、ステータス更新、保留理由の確認、元タスクの修正 | | 現在の段階 | 第0段階。項目・ステータスの標準化待ち | | 次に行うこと | 対象1～2案件で必要な表示項目を決め、正本上に保存ビューを作る | | 次段階へ進む条件 | Sheetsへ転記せず進捗を把握できる、確認時間が減る、判断不能タスクが減る、2名が保守できる | | 主なリスク | 元タスクが未更新のまま集計される、ビューが正本と誤認される、ビューの属人化 | | 停止・縮小条件 | 別資料への転記が必要になる、設定保守が増える、独自工程の案件に適合しない | --- ## 4. 会議メモから決定事項・TODO・未決事項を抽出 | 項目 | 内容 | |---|---| | 対象業務 | 会議後の議事録整理、タスク候補作成 | | AIまたは自動化に任せること | 決定、TODO候補、未決、提案・不明の分類、原文根拠の提示 | | 人に残すこと | 原文照合、決定と提案の判別、抜け・重複確認、担当者・期限の確定、正式反映 | | 現在の段階 | 第1段階前。過去に誤補完実績があるためシャドー検証から開始 | | 次に行うこと | 匿名化した過去メモと人が作った正解例を用意し、統一プロンプトで比較する | | 次段階へ進む条件 | 架空の担当者・期限を生成しない、重大な事実誤認がない、分類が安定し、人の確認を含めても時間が減る | | 主なリスク | 担当者・期限の創作、決定と提案の混同、TODO漏れ、機密情報の誤入力 | | 停止・縮小条件 | 誤補完が改善しない、原文照合を含めると遅い、重大な抽出漏れが発生する、情報取扱いルールを守れない | --- ## 5. 修正依頼のタスク候補への分解 | 項目 | 内容 | |---|---| | 対象業務 | メール、会議メモ、コメント等の修正依頼のタスク化 | | AIまたは自動化に任せること | タスク名、対象箇所、依頼内容、完了条件、原文根拠、要確認事項の候補作成 | | 人に残すこと | 顧客要望の解釈、粒度、重複、仕様変更・費用・納期影響、担当者・期限、正式登録 | | 現在の段階 | 第0段階。候補4とタスク分割基準の安定待ち | | 次に行うこと | 定型的で低リスクな匿名化依頼を使い、人のタスク案と比較する | | 次段階へ進む条件 | 抽出漏れ・重大な誤解釈がない、分割基準を2名で共通利用できる、確認込みで時間が減る | | 主なリスク | 顧客意図の誤解、過剰分割・過少分割、対象画面の取り違え、仕様変更の見落とし | | 停止・縮小条件 | 統合・再分割に手作業以上の時間がかかる、重大な見落としが出る、案件別調整が多すぎる | --- ## 6. 顧客向け進捗メールの下書き | 項目 | 内容 | |---|---| | 対象業務 | 顧客への定期進捗報告メール作成 | | AIまたは自動化に任せること | 確認済み進捗情報を基にした文章構成・表現の下書き | | 人に残すこと | 事実確認、納期・費用・仕様表現、顧客との約束、最終編集、社外送信 | | 現在の段階 | 後続候補。進捗ビューと入力情報の安定待ち | | 次に行うこと | 進捗メールの標準構成と、使用可能な正本情報を決める | | 次段階へ進む条件 | 事実誤認がなく、修正込みで作成時間が減る、重要表現を人が確実に確認できる | | 主なリスク | 古い進捗の記載、納期変更の誤表現、未確定事項の断定、重要な約束の生成 | | 停止・縮小条件 | 誤記が続く、修正時間が長い、正本以外の情報が混入する場合は定型文へ戻す | --- ## 7. 指定メール・Slack／Teamsスレッドの整理 | 項目 | 内容 | |---|---| | 対象業務 | 人が指定したメール・スレッドから依頼、質問、決定候補、正式記録への反映候補を整理 | | AIまたは自動化に任せること | 指定範囲のみの要約、依頼・質問・提案・決定候補の分類 | | 人に残すこと | 合意の有無、顧客意図、正式記録へ移す内容、反映先、タスク化判断 | | 現在の段階 | 業務整理待ち。初期優先対象外 | | 次に行うこと | 「チャットで決まった内容を誰がどこへいつ反映するか」を先に手順化する | | 次段階へ進む条件 | 正式記録先と反映責任者が明確、指定範囲だけで安全に試せる、反映漏れが減る | | 主なリスク | 短い返信や絵文字を合意と誤認、文脈欠落、機密情報入力、要約だけ作って正式反映されない | | 停止・縮小条件 | 業務手順が定まらない、AI要約が新たな中間資料になる、情報取扱いを保証できない | --- ## 8. 確認済みタスク候補の登録補助 | 項目 | 内容 | |---|---| | 対象業務 | 会議・修正依頼から作成し、人が確認済みの候補をタスク管理ツールへ登録 | | AIまたは自動化に任せること | 初期は登録形式への整形。将来はCSV、標準連携、APIによる承認後登録 | | 人に残すこと | 登録対象選択、内容・案件・重複・担当者・期限の最終確認、登録実行、登録結果確認 | | 現在の段階 | 未着手。候補4・5の品質安定待ち | | 次に行うこと | まずコピー＆ペースト、タスクテンプレート、標準インポートの順で試す | | 次段階へ進む条件 | 確認後の転記だけが主要な負担、件数が継続的に多い、標準方法では不足、重複防止と取消が可能 | | 主なリスク | 二重登録、案件違い、部分成功、無確認登録、連携の保守負担 | | 停止・縮小条件 | 転記時間が小さい、標準機能で十分、保守担当を確保できない、登録後修正が増える | --- # 【第0段階：導入前整備】 ## 対象 - 全候補共通 - 特に候補1～5 - ディレクター2名、対象1～2案件 ## 実施内容 - タスク管理ツールを正本として確定する - 必須項目、ステータス、保留条件、完了条件を定義する - 正式な議事録・仕様・決定事項の記録先を指定する - AIの入力可能情報、禁止情報、匿名化、保存・削除ルールを決める - 会議メモ、タスク登録、AI出力のテンプレートを作る - 導入前の作業時間、漏れ件数、転記回数を測る - 停止・手動切り戻し手順を決める ## 人の確認 - 正本の責任者 - AI利用ルールの承認 - タスクの例外条件 - 対象案件の選定 - 検証データの匿名化 - 評価基準と停止基準 ## 記録すること - 導入前の作業時間 - 未設定、期限超過、未更新件数 - 会議後の整理時間 - 修正依頼のタスク化時間 - 転記回数 - 現在の保守時間 - 対象案件、利用者、使用ツール、設定内容 ## 次段階への条件 - 正本と更新責任者が決まっている - 2名が同じタスクルールを理解している - AI入力禁止情報が明文化されている - 匿名化テストデータと正解例がある - 手動へ戻す方法が決まっている - 導入前の基準値を測定できる ## 中止条件 - 正本を一本化できない - AI用の別管理表が必要になる - 実案件情報を安全に扱うルールを決められない - 検証の責任者や確認者を確保できない --- # 【第1段階：小規模検証】 ## 対象 優先して以下を実施します。 1. 担当者・期限未設定タスクの検出 2. 期限間近・期限超過・未更新タスクの検出 3. 会議メモ抽出のシャドー検証 準備完了後に以下を追加します。 4. 案件進捗ビュー 5. 修正依頼のタスク分解 ## 実施内容 - 候補1・2はタスク管理ツールの保存ビュー・標準通知を使用 - 候補4は架空・匿名化した過去メモを人の正解例と比較 - 候補3は1～2案件の正本データのみで表示 - 候補5は定型的な匿名化依頼のみで比較 - AIから正本への直接書き込みはしない - AIの出力は候補として扱う 検証期間は、例えば「準備後に数週間」などを仮置きできますが、件数が少ない場合は期間を延長します。固定期間の消化ではなく、判断に必要な事例数が集まったかを優先します。 ## 人の確認 - 検出結果が本当に対応対象か - AI出力が原文に基づいているか - 担当者・期限を創作していないか - 決定と提案を混同していないか - 仕様・費用・納期に影響しないか - タスク分割の粒度が適切か ## 記録すること - 作業時間 - 検出件数と真の対応件数 - 誤検出、不要通知 - 抽出漏れ、不要な追加 - AI出力の追加・削除・修正件数 - 重大な事実誤認 - 登録前後の修正件数 - 転記回数 - プロンプト・ビュー・通知の保守時間 ## 次段階への条件 仮の目安として、以下を設定できます。 - 人の確認を含めても作業時間が短縮する - 重大な事実誤認がない - 架空の担当者・期限を正式反映しない - 登録漏れ・見落としが従来より増えない - 2名が同じ手順で再現できる - 保守負担が削減効果を上回らない - 別管理表や二重入力が発生しない 「20％以上の時間短縮」「不要通知30％以下」「全体の週次保守30分以内」などは過去工程で示した**仮説的な目安**であり、実績に基づく確定基準ではありません。 ## 中止条件 - 確認・修正時間が手作業を上回る - 重大なタスク漏れ、誤分類、誤解釈が発生する - 許可されていない情報をAIへ入力する - 通知過多で重要通知が見えなくなる - 検証のための二重管理が常態化する - 特定の1名しか運用できない --- # 【第2段階：限定運用】 ## 対象 - ディレクター2名 - 2～3案件程度を仮の上限として開始 - 小規模検証で安全性と効果を確認した候補のみ - AI候補は低機密・定型業務から開始 ## 実施内容 - 候補1・2を通常の週次・日次確認へ組み込む - 候補3を週次定例前の標準ビューとして利用する - 候補4を実会議の下書き工程へ入れる - 候補5を定型的・低リスクな修正依頼へ限定して使う - AI入力・出力を恒久的な案件管理表へ保存しない - 正式反映は正本へ直接行う ## 人の確認 AI候補は次の3段階を維持します。 1. AIが候補を作成 2. ディレクターが原文・正本と照合 3. ディレクターが正式登録・更新 仕様変更、費用、納期、担当者、期限、顧客への回答は人が確定します。 ## 記録すること - 総作業時間 - 誤検出・不要通知 - 抽出漏れ、誤分類 - 正式登録後の修正 - 例外処理件数 - 手動へ戻した回数 - 転記回数 - 保守時間 - 情報入力事故 - 対象外とした案件・理由 ## 次段階への条件 - 通常業務で継続利用しても効果が維持される - 繁忙時や担当者不在時にも手順を維持できる - 重大な誤りが正式情報へ反映されない - 2名が同じ基準で運用できる - 例外案件を対象外にできる - 正本と履歴が維持される - 保守、確認、例外対応を含む総負担が従来より小さい ## 中止条件 - 無確認登録・社外送信が行われる - 仕様・費用・納期の誤認が正式反映される - AI出力が正本として扱われる - 正式登録後の手戻りが増える - 例外処理が常態化する - 通知やAI出力が確認されなくなる - 二重入力や別管理表が再発する --- # 【第3段階：本運用】 ## 対象 候補ごとに判定します。 - 候補1～3は、標準機能で安定すれば比較的本運用へ移しやすい - 候補4・5は、十分な限定運用実績がある範囲だけ本運用化 - 候補6は、進捗情報が安定した後に別途検証 - 候補7・8は自動的には本運用へ進めない ## 実施内容 - 検証済みの案件種別・利用者・手順に限定して通常業務化 - 運用責任者、副責任者、設定変更者を指定 - 月次を基本に効果と事故を監視 - 導入直後は必要に応じて短い間隔で確認 - 効果がない候補は廃止または縮小する - 標準機能で十分なら、その状態を完成形とする ## 人の確認 本運用後も次を自動化しません。 - 顧客要望の最終解釈 - 仕様変更 - 追加費用 - 納期変更 - 担当者・期限の確定 - 正式タスク登録の承認 - 重要な顧客回答 - 案件完了 - 社外への正式送信 ## 記録すること - 時間削減が維持されているか - 漏れ、誤検出、誤分類 - 正式登録後の修正 - 例外件数 - 保守時間 - 転記回数 - 情報取扱い事故 - 利用されなくなったビュー・通知・テンプレート - 特定担当者への属人化 ## 次段階への条件 連携・開発へ進むには、さらに以下が必要です。 - 抽出・確認工程が安定している - 人の確認後の転記だけが主要な負担 - 転記量と削減可能時間を実測できる - CSV、テンプレート、標準連携では不足する - 開発・保守担当と予算を確保できる ## 中止条件 - 総作業時間が手動運用を継続して上回る - 重大事故が発生する - 正本との不一致が増える - 保守負担が効果を上回る - AIサービスや契約条件の変更で安全性を確保できない - 現場が確認工程を省略し始める --- # 【第4段階：連携・開発】 ## 対象 将来検討できるのは、主に以下です。 - 会議メモから作成し、人が確認済みのTODO候補 - 修正依頼から作成し、人が確認済みのタスク候補 - 標準機能で取得できない最終更新情報などの限定的な取得 候補1～3は原則として標準機能を完成形とします。 ## 実施内容 次の順番で検討します。 1. タスクテンプレート・複製 2. コピー＆ペースト 3. CSVインポート 4. 標準連携 5. API 6. 小規模な承認付き登録補助機能 7. RPAは最終手段 APIを使う場合も、「人が承認した内容を登録する処理」に限定します。 ## 人の確認 - 登録対象の選択 - 原文照合 - 対象案件 - 重複 - 担当者・期限 - 仕様・費用・納期影響 - 登録実行 - 登録結果 ## 記録すること - 月間処理件数 - 1件当たりの転記時間 - 月間転記総時間 - 転記ミス - 開発・利用・保守費 - APIの成功、失敗、一部成功 - 実行者、承認者 - 登録元識別子、登録先タスクID - 重複実行、取消、再実行 ## 次段階への条件 - APIの追加効果を時間・ミス削減で説明できる - 標準機能では不足している - 最小権限の認証管理ができる - 重複登録を防止できる - 操作履歴を残せる - 誤登録を取り消せる - 障害時に手動登録へ戻せる - 保守担当者または委託先を確保できる ## 中止条件 - 転記件数が少ない - コピー＆ペーストやCSVで十分 - 人の確認時間が作業時間の大部分で、登録自動化の効果が小さい - 保守担当者を確保できない - APIの削減効果より維持費・保守時間が大きい - 重複防止、監査、切り戻しを実装できない --- # 【第5段階：横展開】 ## 対象 候補別に範囲を変えます。 - 候補1・2：同じタスクルールを使う担当者・部署 - 候補3：同じステータス・工程を使う案件 - 候補4：同じ会議形式と確認手順を使える部署 - 候補5：同種の定型・低リスク案件 - 候補6：共通の進捗報告形式を使える案件 - 候補7・8：部署・ツールごとに再検証 ## 実施内容 1. 同一部署の担当者を1名追加 2. 同種案件へ拡大 3. 別部署では匿名化データで再検証 4. 別部署の1案件で限定運用 5. 効果・リスクを再判定 6. 条件を満たした範囲だけ正式展開 一斉展開は行いません。 ## 人の確認 - 部署ごとの例外条件 - 権限範囲 - 情報取扱い - AI出力の原文照合 - 正式登録 - 仕様・費用・納期のエスカレーション - 対象外案件の選定 ## 記録すること - 部署別・案件種別別の効果 - 誤りと修正時間 - 通知量 - 例外件数 - 教育・保守時間 - 利用料 - 権限事故 - 標準から外れた設定数 ## 次段階への条件 - 展開先でも時間削減が再現する - 重大な誤りを管理できる - 正本を維持できる - 部署固有の例外が過度に増えない - 教育・保守コストを含めても効果がある - 責任者、代理、問い合わせ先を確保できる ## 中止条件 - 展開先で精度・効果が再現しない - 個別プロンプトや個別ビューが増え続ける - 権限範囲が過大になる - 正本との更新差が発生する - 教育・保守コストが削減効果を上回る - 重大な漏れ、誤登録、情報入力事故が発生する --- # 【最初に着手する候補】 優先順位は次のとおりです。 1. **担当者・期限未設定タスクの検出** 2. **期限間近・期限超過・長期間未更新タスクの検出** 3. **会議メモからの候補抽出のシャドー検証** 4. **タスク管理ツール内の案件進捗ビュー** 5. **修正依頼のタスク候補への分解** 候補1・2は低リスクで、AIを使わず開始できます。 候補4は過去に誤補完があったため、実業務への直接反映ではなく、匿名化データによる比較検証から始めます。 --- # 【最初のテスト方法】 ## テストA：未設定・期限・未更新タスク - 対象：ディレクター2名、1～2案件 - 使用：タスク管理ツールの保存ビュー・標準通知 - 初期設定例： - 担当者なし - 期限なし - 期限間近 - 期限超過 - 一定期間更新なし - 保留・顧客確認待ちを除外 - 記録： - 検出件数 - 真に対応が必要だった件数 - 不要な検出 - 確認時間 - 未対応件数 - 設定・保守時間 「期限間近を何日前とするか」「未更新を何日とするか」は、確定事実ではなく仮設定として開始し、実際の通知量から調整します。 ## テストB：会議メモ抽出 - 架空または匿名化した過去の会議メモを使用 - 人が事前に正解例を作る - AIには次を明示する - 原文にない担当者・期限を補わない - 不明は「不明」「未設定」とする - 決定、提案、確認待ち、不明を分ける - 各項目に原文根拠を付ける - AI出力は正式登録しない - 記録： - 整理時間 - 抽出漏れ - 不要な追加 - 分類誤り - 架空の担当者・期限 - 人の修正件数 - 重大な事実誤認 --- # 【本運用まで人の確認を残す部分】 以下は本運用後も人の確認・判断を残します。 - 顧客要望の最終解釈 - 決定、提案、未決事項の判別 - 原文根拠の確認 - タスク化するかの判断 - タスクの粒度・完了条件 - 担当者・期限の確定 - 仕様変更の判断 - 追加費用の判断 - 納期変更の判断 - 顧客への重要な回答 - 正式タスク登録 - 正式文書への反映 - 案件完了判断 - 社外への正式送信 AI利用候補では、原則として次の3段階を維持します。 1. AIが候補を作成 2. ディレクターが原文・正本と照合 3. ディレクターが正式登録・更新 --- # 【API・開発を検討するタイミング】 以下をすべて満たした時点で初めて検討します。 - 会議TODO抽出または修正依頼分解が複数案件で安定している - 人の確認を含めても従来より時間が短い - 重大な漏れ・誤登録が管理できている - タスク項目と分割基準が標準化されている - 確認後の転記作業だけが主要な負担として残っている - 月間件数、転記時間、転記ミスを実測できる - テンプレート、CSV、標準連携では不足する - 登録前プレビュー、重複防止、操作履歴、取消、切り戻しを用意できる - 開発・保守担当者または委託先と予算を確保できる APIの目的はAI精度の向上ではなく、**確認済み情報の転記時間と転記ミスの削減**です。 転記量が少ない、コピー＆ペーストで十分、保守担当がいない場合はAPIへ進みません。 --- # 【現時点では導入しないもの】 - AIによる仕様変更判断 - AIによる追加費用判断 - AIによる納期確定 - AIによる担当者・期限の推測確定 - AI抽出TODOの無確認登録 - 顧客への重要メールの自動送信 - 案件完了の自動判定 - クレーム対応の自動化 - メール・Slack／Teams全体の常時監視・常時要約 - 複数ツール横断の決定経緯検索 - 複数システムへの自動書き込み - 独自案件管理システム - AI用の恒久的な別管理表 - ログイン情報、パスワード、APIキーのAI入力 - 効果確認前のAPI連携・RPA・独自開発 - 効果確認前の全案件・全社一斉展開 --- # 【導入前に整備すべきこと】 ## 1. 正本・更新責任ルール - 情報種別ごとの正本 - 更新責任者 - 更新タイミング - メール、チャット、AI出力の位置付け ## 2. タスク登録・ステータスルール - 必須項目 - タスク分割基準 - 完了条件 - ステータス定義 - 保留・顧客確認待ち - 未設定・未更新検出の除外条件 ## 3. AI利用・情報取扱いルール - 利用可能なAIサービス・契約 - 入力可能情報 - 匿名化が必要な情報 - 入力禁止情報 - 保存期間・削除方法 - 顧客契約上AI利用できない案件の扱い ## 4. 会議メモ・AI出力テンプレート - 決定 - TODO候補 - 未決 - 提案・不明 - 原文根拠 - 担当者・期限の明記有無 - 仕様・費用・納期の要確認欄 ## 5. 評価・停止・切り戻しルール - 導入前基準値 - 時間、漏れ、誤り、保守の測定方法 - 次段階への条件 - 即時停止条件 - 通知停止、AI停止、手動運用への戻し方 --- # 【ロードマップを見直す条件】 以下の場合は、順序、対象範囲、評価基準を見直します。 - 使用するタスク管理ツールや契約プランが変わる - AIサービスのデータ利用・保持条件が変わる - 顧客契約でAI利用が制限される - 案件種別や業務工程が大きく変わる - 誤検出・誤分類・登録後修正が増える - 作業時間の削減が維持できない - 保守・教育・例外対応が削減効果を上回る - 通知疲れやAI確認の形骸化が起きる - 別管理表や二重入力が再発する - 利用者、責任者、保守担当者が変更される - 権限事故、機密情報入力、無確認登録などの問題が発生する - 標準機能の追加により、APIやAIが不要になる - 対象案件ごとの差が大きく、共通運用できないと判明する 見直しの結果、導入停止、対象案件の縮小、AIを使わないテンプレート運用への変更も正式な選択肢とします。 --- # 【次の行動】 1. **使用するタスク管理ツールを確定し、担当者・期限・ステータス・保留条件を定義する** 2. **「担当者・期限未設定」と「期限超過・未更新」の保存ビューを対象1～2案件で作る** 3. **正本ルールとAI情報取扱いルールを、それぞれ1ページ程度で作成する** 4. **匿名化した会議メモと人による正解例を準備し、会議TODO抽出をシャドー検証する** 5. **導入前の作業時間、漏れ件数、進捗確認時間、転記回数を測り、次段階への判定基準を2名で確定する** 最初の判断点は、「AIを増やせるか」ではなく、**標準機能と候補作成によって、確認・保守を含む総負担が本当に減るか**です。効果が確認できなければ、その候補は停止または縮小し、保存ビュー、テンプレート、手動確認へ戻します。

【どんな仕事・組織か】 社員80名ほどの会社で、人事・採用を担当しています。 中途採用を中心に、 ・求人管理 ・応募者対応 ・面接日程調整 ・面接官への連絡 ・候補者情報の確認 ・面接記録の整理 ・選考進捗管理 ・結果連絡 ・内定者対応 を行っています。 【現在の業務上の課題】 ・面接日程調整に時間がかかる ・面接官への催促が手作業 ・評価未入力を人が探している ・ステータス未更新が残る ・結果連絡漏れが怖い ・候補者への定型メールを何度も作っている ・ATS、メール、Calendar、Sheetsへの重複入力がある ・面接記録整理に時間がかかる ・採用進捗用Sheetsを作った結果、ATSとの更新差が生まれたことがある 【導入したいAI活用候補】 ・求人票の文章改善 ・候補者向けメールの下書き ・面接記録の要約 ・面接記録から確認事項候補を整理 ・面接官コメントを所定形式へ整理 ・候補者ごとの選考経緯を整理 【導入したい自動化候補】 ・面接官の空き時間から日程候補を抽出 ・確定した面接予定のCalendar登録 ・面接前リマインド ・評価未入力の検出 ・面接官への評価入力依頼 ・ステータス未更新候補の検出 ・結果連絡未実施候補の検出 ・応募受付メールのテンプレート化 ・採用実績集計 【優先順位が高い候補】 これまでの検討では、 1. ATSの保存検索、進捗一覧 2. 評価未入力の検出 3. 面接日程候補の抽出 4. ステータス未更新候補の検出 5. 面接官向けリマインド 6. 定型メールのテンプレート化 7. 結果連絡未実施候補の検出 8. 面接記録、面接官コメントのAI整理 の順で考えています。 【後回しにしたい候補】 ・面接記録を実データで外部AIへ入力する運用 ・応募者メール全文の常時AI要約 ・ATSと複数ツールのAPI一括連携 ・AIによる候補者ごとの選考経緯自動生成 ・採用専用の独自システム開発 【現時点では導入しない候補】 ・AIによる採用、不採用判断 ・候補者の点数付け ・候補者の順位付け ・人物評価 ・能力、将来性、定着可能性の予測 ・面接官評価をAIが統合して採否を提案すること ・候補者への結果通知の完全自動送信 ・給与、待遇、内定条件の自動決定 【すでに試したこと】 ChatGPTで、 ・求人票の文章修正 ・候補者向けメールの下書き ・面接記録の整理 を試したことがあります。 また、Calendar通知、ATSの一部ステータス管理、一部メールテンプレートは使っています。 【試した結果】 求人票や定型メールは比較的使いやすかったです。 一方、面接記録整理では、 ・候補者が言っていない内容を補う ・面接官の意見と事実を混同する ・評価のような表現を追加する ことがありました。 そのため、面接記録をAI出力だけで正式記録にすることは避けたいです。 【現在使っているツール】 ・採用管理システム（ATS） ・求人媒体 ・GmailまたはOutlook ・Google Calendar ・ExcelまたはGoogle Sheets ・SlackまたはTeams ・ZoomまたはGoogle Meet ・Google Drive ・ChatGPT 【正本となるシステム・データ】 今後は、 ・候補者情報 ・選考ステータス ・面接日時 ・面接官 ・評価入力状態 ・連絡履歴 は可能な限りATSを正本にしたいです。 Calendarは予定確認、メールは正式な候補者連絡として使います。 採用進捗用の別Sheetsは増やしたくありません。 【AI導入に使える人員】 採用担当2名ほどです。 専任のIT担当はいません。 【AI導入に使える時間】 通常の採用業務と並行して進めます。 毎日のメンテナンスが必要な仕組みは避けたいです。 【予算や開発の制約】 最初はATSやCalendarの標準機能を優先したいです。 独自開発や高額な追加ツールは、効果が確認できてから検討します。 【API連携やシステム開発の可否】 最初は行いません。 ATS標準機能、Calendar連携、メールテンプレートなどで効果を確認し、それでも転記や確認負担が残る場合に検討したいです。 【扱っている情報の機密性】 ・候補者名 ・メールアドレス ・電話番号 ・履歴書 ・職務経歴書 ・面接記録 ・面接官評価 ・選考結果 ・希望年収 ・給与、待遇情報 などを扱います。 【AIへ入力してよい情報の範囲】 明確な社内ルールはありません。 求人票など個人情報を含まない情報は比較的扱いやすいです。 履歴書、面接記録、評価情報などを外部AIへ入力してよいかは未確認です。 初期検証では架空データ、匿名化した過去データを使いたいです。 【人の確認を必ず残したい業務】 ・採否 ・次の選考へ進める判断 ・候補者評価 ・面接記録とAI整理結果の照合 ・給与、待遇 ・内定条件 ・結果通知 ・重要な候補者回答 ・例外対応 【AIに任せたくない業務】 ・採用、不採用の決定 ・候補者の評価 ・候補者の順位付け ・人物像の推測 ・能力、将来性の予測 ・待遇決定 ・選考結果の自動決定 【導入によって期待している効果】 ・日程調整を楽にする ・評価未入力や更新漏れを減らす ・面接官への催促を減らす ・選考進捗確認を楽にする ・候補者メール作成を早くする ・転記を減らす ・確認負担や保守負担を増やさない 【効果を確認するために測れそうなこと】 ・日程調整にかかる時間 ・評価未入力件数 ・ステータス未更新件数 ・結果連絡漏れ件数 ・面接官への催促回数 ・メール作成時間 ・転記回数 ・誤検出件数 ・導入後の確認時間 ・保守時間 【導入対象とする部署・人数】 最初は採用担当2名と、1求人または一部候補者だけで試します。 【将来的に展開したい範囲】 効果が確認できれば、 ・他の求人 ・他の採用担当者 ・新卒採用 への展開を検討します。 ただし、中途採用と新卒採用で運用が異なる場合は、同じ仕組みをそのまま使いません。 【特に確認したいこと】 ・最初の小規模検証を何にするべきか ・ATS標準機能をどこまで優先するべきか ・評価未入力検出をどの段階で自動通知へ進めるべきか ・日程調整をどこまで自動化するべきか ・面接記録AIをどの段階まで保留するべきか ・情報管理ルールが整えば面接記録AIをどう試すべきか ・採否や候補者評価をロードマップ対象外にできるか ・API連携を検討するタイミング ・本運用へ進む条件は何か ・横展開前に何を標準化するべきか

# 【ロードマップの結論】 導入は、生成AIより先に、**ATSを正本とした業務ルールと標準機能の整備**から開始します。 実行順序は次のとおりです。 1. ATSの機能・入力項目・ステータス・期限・責任者を確認する 2. ATS保存検索で「評価未入力」を一覧化する 3. 人が対象を確認して手動で催促し、検出条件を安定させる 4. 条件が安定した場合だけ、面接官への1回通知へ進める 5. 並行して、定型メール、日程候補抽出、求人票改善を小規模検証する 6. ATSへの入力が安定してから、ステータス未更新・結果連絡未実施を検出する 7. 面接記録AIは情報管理ルール整備後も、架空・匿名化データから試す 8. API・独自開発は、本運用後も大きな転記負担が残る場合に限って検討する 9. 横展開は、中途採用の他求人から始め、新卒採用は別検証とする 現時点は全体として**第0段階「導入前整備」**です。求人票改善やメール下書きには利用経験がありますが、効果・誤り・確認時間を記録した正式な小規模検証は未完了です。 AI・自動化は、採用判断を代替するものではなく、**確認、転記、文章作成、未処理検出にかかる総負担を減らすための手段**とします。人の確認、例外対応、保守を含めて効果がなければ、停止または手動運用へ戻します。 なお、以下で示す期間・件数・精度・削減率などは、確認済みの実績値がないため、すべて**初期検証用の仮説的な目安**です。導入前の実績を測定した後に確定してください。 --- # 【導入対象】 ## 1. ATSの保存検索・進捗一覧 - **対象業務** 採用進捗、対応待ち、評価待ち、連絡待ちの確認 - **AIまたは自動化に任せること** ATS内の条件抽出、一覧表示、保存検索。生成AIは使用しない - **人に残すこと** 抽出された候補者が本当に対応対象かの確認、例外判断、ATS更新 - **現在の段階** 第0段階。ATSの製品・契約プラン・利用可能機能の確認が必要 - **次に行うこと** 1求人を対象に、評価未入力一覧を作れるか確認する - **次段階へ進む条件** 必要項目がATSに入力され、採用担当2名が同じ一覧と定義を使えること - **主なリスク** ATSの入力不足による見落とし、一覧の増やしすぎ、別Sheetsの再発 - **停止・縮小条件** ATS外の管理表が必要になる、確認時間が増える、検索条件を毎日修正する必要がある場合 ## 2. 評価未入力の検出・面接官リマインド - **対象業務** 面接後の評価入力状況確認、面接官への催促 - **AIまたは自動化に任せること** 面接終了後、評価未入力の候補者を一覧化する。安定後は1回の通知まで - **人に残すこと** 面接実施状況、辞退・延期・中止、評価免除、代理入力の確認。評価内容の入力・判断 - **現在の段階** 第0段階。判定条件と入力期限が未確定 - **次に行うこと** 一覧化のみを小規模検証し、催促は採用担当が確認後に手動送信する - **次段階へ進む条件** 例外を区別でき、誤検出・見落とし・確認時間が許容範囲内であること。仮説的な目安は、2～4週間または10～20件程度の確認 - **主なリスク** 実施前・辞退済み面接への誤通知、入力完了後の通知、通知疲れ - **停止・縮小条件** 通知先間違い、同じ誤通知の反復、確認を含む総時間の増加、頻繁な条件修正が発生した場合 ## 3. 面接日程候補の抽出・Calendar登録 - **対象業務** 面接官の空き時間確認、候補日時作成、確定予定の登録 - **AIまたは自動化に任せること** Calendarの空き時間から、条件に合う候補日時を抽出する。標準機能があれば確定後の予定登録まで - **人に残すこと** 候補者への提示、最終確定、時差・移動・余白・会場・例外予定の確認 - **現在の段階** 第0段階。ATS・Calendarの標準連携範囲と権限確認が必要 - **次に行うこと** 定型的なオンライン面接に限定して、架空予定で候補抽出を試す - **次段階へ進む条件** 二重予約や時差誤りがなく、人の確認を含む調整時間が減ること - **主なリスク** Calendar上は空きでも面接不可、二重予約、確定前登録、ATSとの不一致 - **停止・縮小条件** 二重予約、誤った候補提示、確定前送信、不一致の増加が発生した場合。例外が多い面接は手動へ戻す ## 4. ステータス未更新候補の検出 - **対象業務** 面接後などにATSのステータスが更新されていない候補者の確認 - **AIまたは自動化に任せること** 最終更新日、面接日時、現在ステータス等による一覧化 - **人に残すこと** 評価待ち、社内判断待ち、候補者回答待ち、正当な保留の判別と更新 - **現在の段階** 第0段階。ステータスの開始・終了条件と更新期限が未統一 - **次に行うこと** ステータス定義表を作り、読み取り専用の保存検索を作成する - **次段階へ進む条件** 保留と更新漏れを区別でき、採用担当2名の判断が一致すること - **主なリスク** 正当な滞留の誤検出、根拠のない更新、採否に関係する状態の誤変更 - **停止・縮小条件** 自動変更が発生する、誤検出確認で負担が増える、担当者間で定義が一致しない場合 ## 5. 候補者向け定型メールテンプレート - **対象業務** 応募受付、日程候補提示、面接案内、面接前リマインド - **AIまたは自動化に任せること** 承認済みテンプレートの呼び出し、差し込み、必要に応じた下書き - **人に残すこと** 宛先、氏名、求人名、日時、タイムゾーン、場所、URL、署名の確認と送信 - **現在の段階** 部分利用済みだが、正式な効果測定は未実施 - **次に行うこと** 3種類程度の承認済みテンプレートと送信前チェックリストを作る - **次段階へ進む条件** 重大な差し込みミス・誤送信がなく、作成時間とATS履歴未登録が減ること - **主なリスク** 宛先間違い、古い文面、日時・URL誤り、他候補者情報の残存 - **停止・縮小条件** 誤送信、他候補者情報の混入、結果・待遇の誤記載が発生した場合。問題のテンプレートだけを停止する ## 6. 結果連絡未実施候補の検出 - **対象業務** 結果確定後、候補者への連絡が完了していない案件の確認 - **AIまたは自動化に任せること** 結果確定日、連絡期限、ATSの連絡履歴による未連絡候補の一覧化 - **人に残すこと** 結果、宛先、文面、連絡要否の確認と送信。結果通知自体は自動化しない - **現在の段階** 保留。ATSへの連絡履歴登録を安定させる必要がある - **次に行うこと** メール送信後にATSへ履歴を残す手順または標準連携を統一する - **次段階へ進む条件** 結果確定日と送信履歴が安定して登録され、送信済みを未実施と判定しないこと - **主なリスク** メール送信済み・ATS未登録による誤検出、誤った結果通知、連絡不要案件の混入 - **停止・縮小条件** 誤った結果の通知、他候補者への送信、履歴不備による大量誤検出が発生した場合 ## 7. 求人票文章のAI改善 - **対象業務** 求人票の構成整理、明確化、読みやすさの改善 - **AIまたは自動化に任せること** 見出し整理、冗長表現の修正、複数の文章案作成 - **人に残すこと** 業務内容、応募資格、待遇、勤務地、法令、不適切表現の確認と公開承認 - **現在の段階** 試用済み。正式な運用ルールと効果測定は未実施 - **次に行うこと** 公開済みまたは架空の求人票を使い、元原稿・AI案・最終版を比較する - **次段階へ進む条件** 事実にない内容が最終版に残らず、人の確認を含めても作成時間が減ること - **主なリスク** 存在しない待遇・魅力の追加、必須条件の変質、差別的・不適切な表現 - **停止・縮小条件** 事実と異なる条件が公開される、確認負担が増える、承認されていない情報をAIへ入力する必要がある場合 ## 8. 面接記録・面接官コメントのAI整理 - **対象業務** 面接記録から、候補者発言、面接官意見、確認事項、記載なしを分けて整理 - **AIまたは自動化に任せること** 所定項目への抜き出し、文章形式の統一。評価・推測・補完はさせない - **人に残すこと** 原文との照合、事実追加・脱落・混同の確認、正式記録への反映判断 - **現在の段階** 保留。実データを外部AIへ入力するルールが未整備 - **次に行うこと** 情報管理ルール整備後、架空データで誤整理の傾向を検証する - **次段階へ進む条件** 承認済みAI環境があり、匿名化基準が明確で、照合を含む総時間が減ること - **主なリスク** 発言していない内容の補完、事実と意見の混同、評価表現の追加、個人情報漏えい - **停止・縮小条件** 未承認データの入力、AI出力の無確認登録、事実追加が継続する、照合負担が削減時間を上回る場合 --- # 【第0段階：導入前整備】 - **対象** 全8候補。特にATS保存検索、評価未入力検出、ステータス定義 - **実施内容** - ATSの製品名、契約プラン、保存検索、通知、Calendar・メール連携を確認 - ATSの必須項目、入力者、入力期限を決定 - 評価未入力、ステータス未更新、結果連絡未実施の判定条件と例外を決定 - 現状の作業時間、漏れ、催促、転記回数を測定 - AIへ入力可能・禁止とする情報を決定 - **人の確認** 業務責任者がステータス・期限・例外を承認し、情報管理責任者がAI利用範囲を承認する - **記録すること** 現状値、ATS機能、設定可能範囲、入力責任者、例外条件、権限、承認状況 - **次段階への条件** 1求人を選定し、ATSに必要データが入力され、採用担当2名が同じ定義を理解していること - **中止条件** ATS標準機能で実現できず、複雑なSheetsや毎日の手作業が必要になる場合は、その候補を保留する --- # 【第1段階：小規模検証】 - **対象** 1. ATS保存検索・評価未入力一覧 2. 日程候補抽出 3. 定型メール 4. 求人票AI改善 ステータス未更新は定義整備後に追加 - **実施内容** - 架空データで正常・辞退・延期・保留・誤登録を試す - その後、1求人または一部候補者で限定して使用 - 評価未入力は一覧化のみとし、催促は人が行う - 日程調整は候補抽出まで、メールは人が送信、求人票は人が公開する - **人の確認** 抽出結果、例外、宛先、日時、URL、求人内容、ATS反映状況を毎回確認する - **記録すること** - 作業時間 - 誤検出・見落とし - 催促回数 - メールの修正・差し込みミス - 日程の再調整・不一致 - 初期設定時間と保守時間 - **次段階への条件** 重大事故がなく、人の確認を含む総時間が減り、採用担当2名が同じ手順で扱えること。仮説的な目安として、2～4週間または10～20件程度の確認を行う - **中止条件** 情報漏えい、誤送信、二重予約、採否に関係する誤変更、第二の正本の発生、導入前より総負担が増えた場合 --- # 【第2段階：限定運用】 - **対象** - 評価未入力一覧と、確認付き通知または1回通知 - 定型的なオンライン面接の日程候補抽出 - 応募受付・日程提示・面接案内テンプレート - ステータス未更新一覧 - 求人票AI改善 - 連絡履歴が安定した後の結果連絡未実施一覧 - **実施内容** - 中途採用の一部求人に広げる - 評価未入力は「一覧化→通知案→1回通知」の順で進める - ステータスや結果を自動変更・自動送信しない - 例外案件は手動運用へ分ける - **人の確認** 自動通知の対象、日程確定、メール送信、ステータス更新、結果通知、求人公開を人が確認する - **記録すること** 第1段階の指標に加え、問い合わせ、例外率、手動へ戻した件数、設定変更回数、ATSとの不一致 - **次段階への条件** - 一時的でなく効果が継続している - 重大事故が0件 - 誤検出・見落としが許容範囲内 - 保守担当と停止方法が明確 - 別Sheetsなしで運用できる 仮説的な目安として、検出精度90％以上、誤検出率10％以下、週当たり保守30分程度以内などを置き、実績に応じて見直す - **中止条件** 誤検出が継続する、例外処理が多い、保守負担が削減時間を上回る、ATS・Calendar・メールの差異が増える場合 --- # 【第3段階：本運用】 - **対象** - ATS保存検索・進捗一覧 - 安定した評価未入力一覧・限定通知 - 定型メール - ステータス未更新一覧 - 承認済み範囲での求人票AI改善 - 条件を満たした範囲での日程候補抽出 - 履歴登録が安定した場合の結果連絡未実施一覧 - **実施内容** - 定義済みの求人・利用者・処理だけを通常業務に組み込む - 運用手順、変更権限、停止方法を固定する - 開始後は週次、安定後は月次で効果と事故を確認する - **人の確認** 採否、評価、結果通知、日程確定、重要メール、ステータス更新、求人公開は引き続き人が行う - **記録すること** 総作業時間、誤検出、見落とし、誤送信、不一致、保守時間、例外、設定変更、停止履歴 - **次段階への条件** 標準機能で解消できない転記・確認が継続して残り、その負担とAPI化による削減効果を数値化できること - **中止条件** 重大事故、ATSの正本性喪失、運用責任者不在、手動復帰不能、総負担増加、ログ確認不能 --- # 【第4段階：連携・開発】 - **対象** - 面接確定後のATS・Calendar間登録 - メール送信後のATS連絡履歴登録 - 必要に応じた採用実績集計 - **実施内容** - ATS標準機能、既存連携、CSV、公式オプションの順に確認 - それでも負担が残る場合のみ、公式APIによる一方向連携を検討 - 独自開発やRPAは最後の選択肢とする - **人の確認** 本番反映前のテスト、権限、対象データ、重複防止、障害復旧、費用対効果を承認する - **記録すること** 対象ID、実行日時、成功・失敗、更新前後、重複、再実行、設定変更、停止・復旧 - **次段階への条件** - 公式APIがある - 保守担当者を確保できる - 二重登録防止と手動復帰が実装されている - 費用・保守を含めても総効果がある - 単一の一方向連携が安定している - **中止条件** 保守担当者を確保できない、API仕様変更に対応できない、標準機能との差が小さい、重複登録や正本不一致が発生する場合 --- # 【第5段階：横展開】 - **対象** 1. 中途採用内の他求人 2. 他の採用担当者 3. 新卒採用 4. 必要な場合のみ他部署 - **実施内容** - 共通ステータス、期限、テンプレート、例外処理を標準化 - 展開先ごとに権限と業務差分を確認 - 一度に全体展開せず、段階ごとに再検証する - **人の確認** 展開先の責任者が業務適合性、権限、教育完了、停止方法を確認する - **記録すること** 展開先別の効果、誤り、例外、問い合わせ、保守時間、追加費用、独自運用の発生 - **次段階への条件** 共通ルールで処理でき、例外設定より標準設定が多く、展開後も総負担が減ること - **中止条件** 新卒採用などで業務差が大きい、権限を最小化できない、独自設定が増える、教育・保守体制が不足する場合 --- # 【最初に着手する候補】 **ATS保存検索による「評価未入力候補の一覧化」**です。 理由は以下のとおりです。 - 現在の優先課題である評価未入力と手作業催促に直接対応できる - ATSを正本としたまま実施できる - 生成AIや外部への個人情報送信が不要 - 自動通知を始めなくても効果を確認できる - ステータス未更新や結果連絡未実施の検出にも展開できる - 問題があれば保存検索を停止し、容易に手動運用へ戻せる --- # 【最初のテスト方法】 1. **ATS機能を確認する** - 保存検索 - 面接実施状態 - 評価入力状態 - 面接官 - 日時条件 - 辞退・延期・中止の区別 2. **判定条件を仮置きする** - 面接が終了している - 所定時間を経過している - 評価が未入力 - 辞退・延期・中止・評価免除ではない 3. **架空データで試す** - 面接済み・未入力 - 入力済み - 面接前 - 辞退 - 延期 - 評価免除 - 面接官変更 4. **1求人で一覧化する** - 初期は自動通知しない - 採用担当が一覧を確認してから個別に催促する 5. **効果を記録する** - 一覧確認時間 - 未入力件数 - 見落とし - 誤検出 - 催促回数 - 評価完了までの時間 - 設定・保守時間 仮説的な目安として、2～4週間または10～20件程度を確認し、条件が安定した場合にだけ「通知案の作成」、その後「1回の自動通知」へ進めます。 --- # 【本運用まで人の確認を残す部分】 以下は本運用後も人の確認・判断を残します。 - 採用・不採用 - 次の選考へ進める判断 - 候補者評価 - 候補者の順位付けや人物像の判断 - 面接官が入力する評価内容 - 評価未入力通知の例外判断 - 日程候補の候補者への提示と最終確定 - メールの宛先、氏名、求人名、日時、URL - 結果通知の内容確認と送信 - ステータス更新の根拠確認 - 給与、待遇、内定条件 - 求人票の事実確認と公開承認 - 面接記録AI出力と原文の照合 - 重要な候補者質問への回答 - 例外・苦情・配慮依頼への対応 --- # 【API・開発を検討するタイミング】 次の条件をすべて満たした後に検討します。 1. ATS標準機能、Calendar・メールの既存連携、CSV、公式オプションを確認済み 2. 本運用後も同じ転記・照合作業が高頻度で残っている 3. 残存時間、転記回数、誤り件数を実績で測定できている 4. API化による削減効果が費用・保守負担を上回る 5. 公式APIと最小権限の認証方法が利用できる 6. 採用担当2名以外に、技術的な保守担当または委託先を確保できる 7. 二重登録防止、ログ、停止、再処理、手動復帰の設計ができる 最初に検討し得るのは、以下の一方向連携です。 - 面接確定後のATSからCalendarへの登録 - メール送信後のATS連絡履歴登録 複数ツールの双方向同期、RPA、採用専用システム開発は優先しません。 --- # 【現時点では導入しないもの】 - AIによる採用・不採用判断 - 次の選考へ進めるかの自動判断 - 候補者の点数付け・順位付け - 人物評価、能力・将来性・定着可能性の予測 - 面接官評価のAI統合や採否提案 - ステータスの自動変更 - 候補者への結果通知の完全自動送信 - 給与、待遇、内定条件の自動決定・自動記載 - 評価未入力者への連続自動催促・自動エスカレーション - 実名の履歴書、面接記録、評価情報を未承認の外部AIへ入力すること - 面接記録AI出力のATSへの自動登録 - 応募者メール全文の常時AI要約 - ATSと複数ツールのAPI一括連携 - 採用専用の独自システム開発 - 候補者対応や結果通知に対するRPA利用 --- # 【導入前に整備すべきこと】 ## 1. ATSの正本ルールと必須入力項目 候補者情報、ステータス、面接日時、面接官、評価状態、結果、連絡履歴をATSへ集約し、入力者と期限を決めます。 ## 2. ステータス・未処理検出ルール 評価未入力、ステータス未更新、結果連絡未実施について、判定条件、期限、辞退・延期・保留などの例外を決めます。 ## 3. 標準業務フローと責任者 応募受付から結果連絡までの担当者、確認者、更新順序、例外時の対応者、停止判断者を定めます。 ## 4. 情報管理・AI利用ルール 利用可能なAI、入力可能・禁止情報、匿名化基準、出力照合、保存・削除、事故報告、アカウント権限を決めます。 ## 5. 効果測定・停止・手動復帰方法 導入前後の作業時間、漏れ、誤検出、保守時間を同じ方法で測定し、停止方法と手動運用への戻し方を1ページでまとめます。 --- # 【ロードマップを見直す条件】 以下の場合は、優先順位、対象範囲、判定条件を見直します。 - ATSの製品、契約プラン、標準機能が変更された - 採用フロー、ステータス、評価方法が変更された - 採用件数や求人構成が大きく変わった - 新卒採用、集団面接、対面面接など別の運用へ展開する - 誤検出、誤通知、例外処理が想定より多い - 人の確認を含む総作業時間が減らない - 週次・月次の保守負担が増える - ATSとCalendar・メールの不一致が増える - 情報管理ルール、AIサービスの利用条件、保存条件が変更された - 運用責任者・副担当・保守担当が不在になった - 個人情報漏えい、誤送信、二重予約などの重大事故が発生した - APIや追加ツールの費用が効果に見合わなくなった - ATS外に第二の正本が作られ始めた --- # 【次の行動】 1. **利用中ATSの製品名・契約プラン・標準機能を確認する** 保存検索、評価状態、通知、Calendar・メール連携、履歴管理の可否を確認します。 2. **評価未入力の判定条件を採用担当2名で決める** 入力期限、辞退・延期・中止・評価免除・代理入力の扱いを定義します。 3. **導入前の基準値を測定する** 評価未入力確認時間、催促回数、日程調整時間、メール作成時間、転記回数を短期間記録します。 4. **架空データで評価未入力の保存検索をテストする** 正常ケースだけでなく、面接前、辞退、延期、入力済みなどの例外を含めます。 5. **1求人で一覧化のみを開始する** 自動通知は行わず、人が対象を確認して催促し、誤検出・見落とし・確認時間を記録します。効果がなければ条件を1回見直し、それでも改善しなければ導入を停止します。