AI社員の作り方は業務定義から
目次
はじめに
AI社員を作りたい、という相談が増え ている。
最初に出てくる話題は、だいたいツール名だ。どのモデルを使うか。Slackにつなぐか。CRMを触らせるか。RAGを入れるか。気持ちは分かる。動くものを早く見たいからだ。
ただ、実際に社内へ置こうとすると、別の問題が先に来る。
このAIは、何の仕事を担当するのか。どの情報を読んでよいのか。どこまで書いてよいのか。失敗したら誰に戻すのか。成果は何で測るのか。
ここが曖昧なまま「AI社員」を作ると、見た目は便利でも運用で止まる。人間の社員を採用するときに職務定義なしで配属しないのと同じだ。AI社員も、先に業務定義が要る。
PwC Japanのデジタル従業員に関する整理では、AIエージェントを組織内の働き手として捉え、業務定義、権限、監督、評価、停止まで含む管理が必要だとされている。これはかなり実務に近い見方だ。設計は、モデル選定ではなく「どんな働き手として組織に置くか」から始まる。
最初に決めるのは職種名ではなく業務単位
「営業AIを作りたい」「総務AIがほしい」と言うだけでは足りない。
営業にも、商談準備、議事録整理、メール下書き、CRM更新、見積確認、契約前の条件整理がある。総務にも、問い合わせ対応、備品管理、入退社手続き、規程確認、稟議の案内がある。職種名だけでは、AIが読む情報も出す成果物も決まらない。
最初に決めるべきなのは、業務名ではなく業務の単位だ。
- 入力: 何を読ませるか
- 判断: 何を分類・抽出・提案させるか
- 出力: 何を成果物として返すか
- 承認: どこで人間に戻すか
- 記録: 何をログや学習として残すか
たとえば「商談後フォローAI社員」なら、入力は議事録、商談メモ、顧客情報、過去メールに絞れる。判断は次アクション抽出と温度感の整理。出力はお礼メールの下書きとCRM更新案。承認は送信前とCRM確定前。記録は人間の修正点と次回改善メモ。
ここまで切ると、AI社員は急に作りやすくなる。逆に「営業を全部手伝って」だと広すぎる。AIはそれっぽく動くが、現場は安心して任せられない。
既存記事の AI社員の作り方は役割分担から では、読む・書く・確認する分担を中心に整理した。今回はその前段として、どの業務を担当範囲にするかを決める。役割分担や権限境界の細かい論点は既存記事へ譲り、ここでは1体目を配属する前の「5枚定義」に絞る。
「AI社員」と「AIエージェント」を混ぜない
AI社員は、AIエージェント技術を社内運用の言葉に置き換えたものだと考えると分かりやすい。
Laboro.AIのAIワークフローとAIエージェントの整理では、事前に決めた手順で動くか、状況に応じて自律的に判断するかが分けて説明されている。社内で使うAI社員も、この違いを見誤ると設計がぶれる。
すべてを自律判断にする必要はない。むしろ1体目は、AIワークフロー寄りで十分だ。
- 決まった条件で起動する
- 決まった資料だけ読む
- 決まった形式で下書きを出す
- 判断に迷ったら人間に戻す
この程度でも、毎日の仕事はかなり軽くなる。Slackの従業員向けAIエージェント解説でも、反復作業や情報探索、承認待ちの負担を減らす存在としてAIエージェントが扱われている。大事なのは、最初から「自律的に全部やる同僚」を作ろうとしないことだ。
AI社員という名前に引っ張られて、最終判断まで渡す必要はない。最初は「下ごし らえを正確に進めるメンバー」でよい。そこから運用ログと評価を見て、少しずつ権限を足す。
1体目は、繰り返し発生する小さな仕事に配属する
AI社員の1体目に向いている仕事には条件がある。
まず、繰り返し発生すること。次に、入力と出力の形がある程度そろっていること。最後に、人間が確認しやすいこと。
たとえば次のような業務は始めやすい。
| 業務 | AI社員に任せること | 人間に残すこと |
|---|---|---|
| 商談後フォロー | 議事録から次アクションとメール下書きを作る | 送信、条件の確約 |
| 社内問い合わせ | 関連規程や過去回答を探して一次回答を作る | 例外判断、制度解釈 |
| 採用一次整理 | 履歴書と要件を照合して論点を並べる | 合否判断、候補者連絡 |
| 請求前確認 | 金額、期日、取引先情報の確認リストを出す | 発行、送付、承認 |
| 週次レポート | 数値と差分を集めて草案を作る | 解釈、意思決定 |
フィンチジャパンのAIエージェント作成プロセス解説でも、AIエージェントの導入は流行として始めるのではなく、業務課題に対する具体的なソリューションとして設計することが重要だとされている。これはAI社員にもそのまま当てはまる。
「何を自動化できるか」ではなく、「どの業務なら任せても検証できるか」で選ぶ。この順番が現実的だ。
AI社員の作り方は5枚定義で決める
AI社員の業務定義は、最初から分厚い仕様書にしなくてよい。むしろ、最初の1体 は5枚くらいで足りる。
1枚目は役割。何のために存在するAI社員かを書く。
2枚目は入力。読んでよい情報、読んではいけない情報、参照元の優先順位を書く。
3枚目は出力。出してよい成果物、必ず含める項目、出してはいけない断定を書く。
4枚目は権限。できる操作、できない操作、人間承認が必要な操作を書く。
5枚目は評価。何を合格とし、何が起きたら停止・修正するかを書く。
この5枚があれば、実装前の会話がかなり楽になる。エンジニアにも、現場にも、経営にも同じ絵を渡せるからだ。
たとえば商談後フォローAI社員なら、業務定義はこうなる。
- 役割: 商談後24時間以内に次アクションとメール下書きを作る
- 入力: 議事録、顧客名、参加者、過去メール、商談フェーズ
- 出力: 要約、宿題、担当者、返信下書き、CRM更新候補
- 権限: 下書き作成まで。外部送信とCRM確定更新は禁止
- 評価: 人間の修正が軽微、日付や社名の誤りがない、送信前確認に必ず止まる
ここまで書けば、1体目の設計はかなり具体になる。モデルやツールは、この定義を実現する手段として選べる。
権限は「できること」より「止まる条件」から決める
AI社員を作るとき、権限表は後回しにされがちだ。だが、実務ではここがいちばん効く。
JAPAN AIのAI社員解説では、AI社員は業務フローに組み込まれ、自ら状況を判断して動く能動的な存在として説明されている。能動的に動くなら、なおさら止まる条件が必要になる。
権限は、広げるほど便利になる。一方で、事故の影響も大きくなる。だから最初は「できる操作」より先に「止まる条件」を決める。
- 外部送信が必要なら止まる
- 金額、納期、契約条件に触れるなら止まる
- 個人情報や機密情報を外へ出す可能性があるなら止まる
- 参照元が不足しているなら止まる
- 既存ルールと矛盾するなら止まる
この止まり方を仕様に入れておくと、監査しやすくなる。人間が判断すべきところで戻ってくるからだ。
権限の考え方は 社内AIエージェントは権限設計から でも整理している。AI社員は、人間の責任を置き換える存在ではない。人間が責任を持てるように、判断材料と下書きを 整える存在だ。
評価は「賢いか」ではなく「仕事が前に進んだか」で見る
AI社員の評価で「回答精度」だけを見ると、運用に残りにくい。
仕事で本当に見たいのは、業務が前に進んだかどうかだ。下書きが使えたか。抜け漏れが減ったか。確認の時間が短くなったか。危ない操作の前で止まったか。
見る指標は、たとえば次のように置ける。
- 下書きの採用率
- 人間の修正回数
- 抜け漏れの再発回数
- 承認待ちから次アクション化までの時間
- 止まるべき場面で止まれた割合
SlackやTeamsのような普段の業務導線で使うなら、反応速度も大事になる。AI社員が1分で返すのか、15分かかるのかで、任せられる仕事が変わる。
メンバーズの業務フロー自動化に関する記事では、AIエージェントを業務フローへ組み込み、社内システムと適切なタイミングで連携させる必要があると説明されている。評価も同じだ。単体の回答ではなく、業務フローの中で何が改善したかを見る。
Atsumellの視点
Atsumellでは、社内AIを作る工程は要件定義そのものだと考えている。
どの業務を任せるか。何を読ませるか。何を出させるか。どこで止めるか。どう評価するか。これは実装前に決める仕様であり、運用後に改善する前提でもある。
Kakusillで扱っている「AIが読める仕様」の考え方もここにつながる。人間が暗黙知で回している業務を、AIが扱える構造へ直す。業務定義、権限、評価、停止条件をそろえる。そこまでできて、AI社員は初めてチームに配属できる。
AI社員は、派手なデモよりも地味な業務定義で決まる。
1体目を作るなら、ツール選定の前に5枚の定義を作る。役割、入力、出力、権限、評価。この5つが埋まれば、AI社員は「便利そうなチャット」から「仕事を前に進めるメンバー」に変わる。
Atsumellでは、社内AIエージェントやAI社員の業務定義、権限設計、評価設計、SlackやGoogle Workspaceとの連携まで支援している。最初の1体を自社業務に合わせて設計したい場合は、お問い合わせフォームから相談してほしい。
