AI導入

AI社員の職務記述書は何を書くか

株式会社Atsumell|8分で読めます
AI社員の職務記述書に書く項目を示すブログサムネイル

はじめに

AI社員を入れる話になると、最初に盛り上がるのは機能だ。

Slackを読ませたい。メールを下書きしてほしい。CRMも更新してほしい。議事録もまとめてほしい。気持ちはよく分かる。機能を並べるほど、すぐ仕事が進みそうに見える。

けれど、現場で詰まるのは機能一覧ではない。誰の仕事を、どの範囲で、どの基準で任せるのか。ここが曖昧なままだと、AI社員は便利な相棒ではなく、責任線のぼやけた自動化になる。

人間を採用するとき、職務記述書を書く。職務内容、責任範囲、必要なスキル、成果の見方をそろえるためだ。AI社員にも同じ発想がいる。むしろ、人間より空気を読んでくれない分、文書化はもっと大事になる。

AI社員の職務記述書で最初に決めるもの

AI社員の職務記述書は、人格設定シートではない。名前や口調を決める前に、仕事の境界を書く文書だ。

最低限、次の6項目を入れる。先に完成形を見せるなら、こうなる。

  • 配属先: どの部署、案件、業務イベントに紐づくか
  • ミッション: 何を前に進めるAIなのか
  • 入力: 何を読んでよいか
  • 出力: 何を作ってよいか
  • 権限: どこまで実行してよいか
  • 評価: 何をもって良い仕事と見るか

SIerや情シスが顧客業務にAI社員を入れる場合は、ここに「責任分界」も足す。どこまでが顧客側の判断で、どこまでが開発/運用側の管理対象か。業務仕様書、受入基準、権限マトリクス、操作ログ、例外時のエスカレーション先まで書いておくと、提案後のすり合わせがかなり楽になる。

たとえば営業支援AIなら、「営業部のAI」ではまだ広い。展示会後フォロー、商談前準備、提案書の初稿作成、失注掘り起こし。業務イベントまで落とすと、必要な入力と出力が見えてくる。

PwCのデジタル従業員に関する整理では、AIエージェントを組織内の働き手として扱うなら、業務定義、配置、権限、監督、評価、改善、廃止まで含めた管理が必要だとしている。これはAI社員の職務記述書にもそのまま当てはまる。採用して終わりではなく、配属、監督、評価まで設計する。

職務内容は「読む・書く・実行する」に分ける

AI社員の職務内容は、まず3つに分けると扱いやすい。

  1. 読む
  2. 書く
  3. 実行する

読む仕事は、比較的リスクが低い。会議メモを読む。過去の商談履歴を読む。社内ナレッジを読む。もちろん機密管理は必要だが、外部に影響を出す操作ではない。

書く仕事は、価値が出やすい。お礼メールの下書き、議事録の要点、提案書の構成、FAQ回答案。ここでは、AIが出したものを人間が直す前提にしておくと回しやすい。

実行する仕事は、慎重に扱う。メール送信、カレンダー変更、CRM更新、請求書作成、外部ツールへの登録。ここは「できるか」ではなく「任せてよいか」で切る。

この分け方は、AI社員の役割分担は3層で決める でも扱った。職務記述書に落とすなら、さらに一歩進めて、読む対象、書く成果物、実行できる操作を明記する。

権限は部署ではなく業務イベントで切る

AI社員の権限を部署単位で切ると粗くなる。

営業支援AIだから営業部の情報を全部読める。これは広すぎる。必要なのは、対象案件に紐づくメール、議事録、提案資料、CRM履歴、次回予定だ。逆に、同じ案件に必要なら、営業だけでなくCSや開発の一部情報も読むかもしれない。

だから権限は、部署名ではなく業務イベントで切る。

展示会後フォローなら、名刺情報、接点メモ、送付資料、送信テンプレート、送信履歴。商談前準備なら、対象Deal、参加者、過去議事録、提案資料、未完了タスク。請求前確認なら、契約条件、納品状態、請求予定、承認者。

Flatt SecurityのAI時代の認可制御の記事では、ユーザー本人の権限とエージェントに与える権限のずれが論点になる。AI社員の職務記述書では、このずれを放置しない。誰の代理で動くのか、AI固有の権限を持つのか、人間の承認を挟むのかを分けて書く。

社内AIエージェントは権限設計から でも同じ考え方を使っている。AI社員に「CRMを触れる」と書くのでは足りない。対象Dealは読める。Task案は作れる。フェーズ変更は承認後だけ。ここまで書くと、現場が判断できる。

評価指標は人間の仕事と同じにしない

AI社員の評価を、人間の評価制度にそのまま合わせるとズレる。

人間なら、顧客との関係構築、状況判断、交渉、例外対応まで含めて評価する。AI社員はそこまで一気に背負わない。評価すべきなのは、任せた範囲の仕事が安定して前に進んだかだ。

営業フォローAIなら、見るべき指標はこうなる。

  • 下書き作成までの時間
  • 人間が修正した割合
  • 必須情報の抜け漏れ
  • 誤った宛先や資料混在の検知数
  • 送信前に止まれた件数

議事録整理AIなら、要点の抜け、次アクションの抽出率、CRM登録までのリードタイムを見る。問い合わせ分類AIなら、顧客問い合わせと営業DMの誤判定率を見る。

GartnerのAIエージェント解説では、AIエージェントの利点だけでなく、リスクや導入課題も整理されている。そこから考えると、AI社員の評価も速さだけでは足りない。品質、リスク低減、人間の確認負荷まで見る。

停止条件と引き継ぎ先を書く

職務記述書に必ず入れたいのが、停止条件だ。

AI社員は、迷ったときに人間のように雑談で確認してくれるとは限らない。設定が甘いと、足りない情報を補って進める。だから、どこで止まるかを先に書く。

停止条件は難しく考えなくてよい。まずは次の4つで足りる。

  • 情報不足: 必須情報が欠けている
  • 権限不足: 読む、書く、実行する権限が足りない
  • 外部影響: 顧客、候補者、取引先へ影響する
  • 高リスク: 契約、請求、個人情報、採用判断に関わる

止まった後の引き継ぎ先も書く。営業担当、PM、承認者、管理部門、法務。ここが空欄だと、AI社員は止まっても仕事が滞留する。

KPMGのAIエージェントと権限委譲に関する解説は、AIエージェントの導入では権限委譲の範囲を明確にする必要があると述べている。権限委譲は、任せる線だけでなく、戻す線まで含めて設計するものだ。

AIエージェントの要件定義で停止条件はどう決めるか でも書いたが、停止条件は失敗時のブレーキではない。人間に戻すための業務ルールだ。

AI社員の職務記述書テンプレート

実務で使うなら、最初は1ページでよい。長すぎると更新されない。

項目書くこと
名前呼び名ではなく役割が分かる名称展示会フォローAI
配属先部署ではなく業務イベントAI Native Expo後フォロー
ミッション前に進める仕事接点メモからお礼メール下書きと次タスクを作る
入力読んでよい情報名刺情報、接点メモ、送付資料、CRM履歴
出力作ってよい成果物メール下書き、CRM活動メモ、ToDo案
実行権限自動でできる操作下書き作成まで。送信は人間承認
停止条件止まる条件宛先不明、資料混在、契約/価格の確約、個人情報の疑い
評価良し悪しの見方修正率、漏れ件数、下書き作成時間、停止理由の妥当性
管理者誰が改善するか営業責任者、運用担当、開発担当
廃止条件使わない判断4週間連続で修正率が高い、誤判定が改善しない

職務記述書という言葉に寄せるなら、Job-Usのジョブディスクリプション解説が整理しているように、職務内容、範囲、必要能力、成果責任を書く文書として捉えると分かりやすい。AI社員向けには、ここへ権限、停止条件、ログ、改善責任を足す。

レビューでは3つのズレを見る

テンプレートを書いたら、実装に進む前にレビューする。見るのは3つだけでよい。

1つ目は、任せる仕事と入力のズレだ。提案書の下書きを作らせるのに、顧客課題、提案方針、過去資料が読めないなら成果物は薄くなる。逆に、必要以上に広い共有ドライブを読ませるなら、機密混在のリスクが増える。

2つ目は、出力と承認者のズレだ。メール下書きなら営業担当、契約条項の要約なら法務、請求確認なら管理部門が見る。成果物ごとに承認者を変えないと、レビューが形式だけになる。

3つ目は、評価と改善のズレだ。KPIを「処理件数」だけにすると、速いが危ないAI社員になりやすい。修正率、停止理由、差し戻し理由、再発したエラーを残す。SIerが顧客へ導入する場合は、このログが運用保守の説明材料にもなる。

更新サイクルを決めてから始める

職務記述書は一度書いて終わりではない。

AI社員は、使いながら役割が変わる。最初は下書きだけだったものが、社内通知、CRMメモ、タスク作成まで広がるかもしれない。だから、更新サイクルを決めてから始める。

おすすめは2週間だ。最初の2週間は、修正内容と停止理由を見て、入力、出力、停止条件を直す。次の2週間で、権限を広げるか、逆に狭めるかを決める。こうすると、機能追加が思いつきベースになりにくい。

生成AI PoCの成功基準は本番化の前に決める と同じで、試す前に評価の置き方を決める。AI社員の職務記述書は、その評価を日々の運用に落とすための台帳でもある。

1体目は「下書き社員」にする

最初のAI社員でおすすめなのは、下書き社員だ。

読む。整理する。下書きを作る。ここまでを任せる。外部送信や確定更新は人間が持つ。導入初期では、この形が扱いやすい。

価値が見えやすく、事故が起きにくい。人間はゼロから書く負担を減らせる。AI社員は実行しすぎない。評価も、修正率や抜け漏れで見やすい。

Japan AIのAI社員解説でも、導入目的を人員削減ではなく業務の質向上や人間の高付加価値化として伝える重要性が触れられている。職務記述書もそのために使う。人を置き換える宣言ではなく、どこを任せ、どこを人間が持つかを共有する文書にする。

Atsumellの視点

AI社員の職務記述書は、AIに仕事を渡す前の要件定義だ。

名前を付けるだけでは足りない。ツールをつなぐだけでも足りない。任せる仕事、読ませる文脈、作る成果物、止まる条件、評価の物差しをそろえて、はじめて現場に置ける。

株式会社AtsumellがKakusillやAIエージェントの構築で見ているのも、この設計だ。AIに何かを作らせる前に、AIが読める仕様と、人間が監督できる境界を作る。ここを飛ばすと、AI社員は増えても、仕事は意外と前に進まない。

まず1体目の職務記述書を書く。配属先を決める。入力と出力を切る。止まる条件を入れる。そこまでできると、AI社員はようやく「便利なツール」から「業務を前に進める担当者」に近づく。


関連記事

#AI社員#デジタル従業員#AIエージェント#権限設計#AI導入

AI社員を職務記述書から設計しませんか?

Atsumellが業務フロー、権限境界、評価条件、停止条件まで含めて社内AIエージェントの要件定義を支援します。

相談する