AI社員を導入すると、まずは時間がかかる業務や、成果が大きそうな業務を任せたくなります。ところが、判断や例外の多い仕事を丸ごと渡すと、期待した出力にならなかった原因が、AI、指示、入力、評価のどこにあるのか分かりません。
最初に必要なのは、大きな成果を狙うことより、短い周期で試し、修正を次に戻せる業務を選ぶことです。本稿では、文章作成や情報整理など、人が出力前後を確認できる知的業務を対象に、最初の一件を選ぶ5つの観点を紹介します。
この記事の結論
AI社員に最初に任せるのは、効果が最大の業務ではなく、反復性、範囲、可逆性、受入基準、人によるレビューの5条件を説明できる小さな業務です。入力・出力と戻し方を決め、同じ型で複数回試し、修正理由を次回へ戻せる仕事から始めると、導入の成否を判断しやすくなります。
この記事の要点
効果が大きい仕事ほど判断要素や例外が多く、失敗した原因を切り分けにくいからです。最初は、AIの能力を証明する仕事ではなく、自社が入力・確認・改善を繰り返せる仕事を選びます。
議事録、顧客メール、提案書、データ整理、問い合わせ対応。候補を並べると、時間がかかる仕事や経営上重要な仕事を優先したくなります。しかし、複数部門の判断を含む提案書を丸ごと任せた場合、出力が使えなくても、原因がAIの性能なのか、指示なのか、入力資料なのか、評価基準なのかが分かりません。
そこで、顧客向け提案書の完成版ではなく、商談メモから次回確認事項を3点抽出する。問い合わせメールを自動送信するのではなく、過去の回答を参照して返信案だけを作る。このように検証可能な単位へ切れば、誤りの場所と修正内容を残せます。
NISTのAI Risk Management Frameworkは、AIリスクへの対応を、組織として継続的に管理・測定する考え方を示しています。本稿の5基準はNISTの公式分類ではありませんが、「一度導入して終わり」ではなく、役割、測定、見直しを運用へ組み込むという外部の考え方と整合するよう、SHIOパートナーズが実務向けに整理したものです。
5基準は「同じ型で試せるか」「小さく切れるか」「元に戻せるか」「良否を判定できるか」「人が確認できるか」です。候補業務の名前ではなく、実際の入力、出力、確認工程に当てはめます。
毎週、毎月、案件ごとなど、同じ目的とおおむね同じ手順で繰り返す仕事を選びます。一度だけの仕事では、結果が改善によるものか偶然かを判断できません。反復できれば、「結論を先に出す」「出典を付ける」といった修正が次回に効いたかを比べられます。
入力と出力を一文で説明できる単位にします。「営業を支援する」ではなく、「商談メモを入力し、未確認の論点を3点出す」と定めます。対象外も書けば、AIが範囲を越えたのか、依頼側が曖昧だったのかを区別できます。
誤りがあっても公開・送信・更新の前に止められ、元データを残せる仕事を選びます。下書きや候補提示は比較的戻しやすい一方、顧客への自動送信、本番データの上書き、契約条件の確定は取り消しが難しく、初回の対象には向きません。
「自然」「分かりやすい」だけでなく、必須項目、指定形式、数字と元資料の一致、事実と推測の区別など、確認可能な条件を3つ程度決めます。人の成果物でも良し悪しを説明できない仕事は、先に良い例と差し戻し例から判断基準を言語化します。
成果物の目的を理解する人と、確認する時間を決めます。AIに詳しい人より、実務で使えるかを判断できる人が必要です。初期の修正は余分な作業ではなく、次の指示、テンプレート、受入基準を改善するための材料になります。
候補を「満たす」「要調整」「満たさない」の3段階で比べ、要調整の理由を業務の切り方へ戻します。合計点で優劣を競うのではなく、試せる大きさへ変えるために使います。
たとえば「月次営業レポートを作る」は、そのままでは範囲が広く、受入基準も曖昧です。「確定済みの月次数値を入力し、前月比の変化と要確認点を指定形式で下書きする」まで小さくすれば、入力、出力、確認者が明確になります。元の数値を変更せず、責任者が公開前に確認すれば、可逆性と人レビューも確保できます。
5つをすべて満たす候補がなければ、月次レポート全体ではなく数値コメント、顧客メールの送信ではなく返信案、契約書の判断ではなく確認論点の抽出へ切り直します。それでも受入基準を作れない仕事は、最初の候補から外します。
5基準は、業務を小さく試すための選定基準です。個人情報・顧客機密を扱う業務や、金額・契約・人事の判断、本番データの更新、対外送信では、業務適性とは別に、利用環境、アクセス権、承認手順を先に決めます。
公開可能な範囲では、コラム制作を企画、執筆、レビュー、画像、HTMLの役割に分け、記事ID単位で成果物を管理しています。AI社員へ「記事公開を丸ごと任せる」のではなく、人が確認できる工程ごとに担当と受入基準を置く運用です。
具体例として、まずプロジェクト管理の役割がテーマと既存記事との重複を確認し、ライターの役割がアウトラインとWord初稿を作ります。初稿は、読みやすさ、根拠、既存記事との差分、次の行動が明確かをレビューした後、デザインとHubSpot取り込み用HTMLの工程へ渡します。対外公開の最終判断は人が行います。
この運用は、最初から自動投稿まで進めるものではありません。記事の入力資料、Wordの体裁、HTMLの構造など、各工程の受入基準を一つずつそろえます。また、編集元と確認用ファイルを分け、管理側にも記事IDごとの確認用一式を置くことで、誰が何を確認するかを見失わないようにしています。
ここでの学びは、AI社員の人数を増やすことではなく、一つの成果物を検証可能な工程へ分けることです。役割名や使用ツールを同じにする必要はありません。自社の業務でも、「誰が入力をそろえ、誰が受入を判断し、どこで公開を止められるか」を決めれば応用できます。
同じ型を複数回試し、実施回数、修正内容、確認時間を記録して、継続・拡大・中止を決めます。速さだけでなく、どの修正が繰り返されたかを見ることが重要です。
まず3回から5回など、同じ業務を比較できる期間を置きます。各回で、受入基準を満たした項目、修正した箇所、確認にかかった時間、重大な見落としを記録します。毎回同じ修正が必要なら指示やテンプレートへ反映し、修正理由がばらばらなら範囲が広すぎないかを見直します。
安定した場合も、すぐに全自動化する必要はありません。下書きから分類候補まで広げる、対象部署を一つ増やすなど、一段ずつ範囲を広げます。反対に、人がほぼ書き直している、確認時間が減らない、誤りの影響を限定できない場合は、業務を再分割するか、候補から外します。中止も学習結果の一つです。
最初から完璧な業務や、レビュー不要の仕事を探す必要はありません。判断できる範囲で試し、結果を基準へ戻せることを優先します。
いいえ。複雑な業務でも、調査、整理、草案、確認論点の抽出など、受入基準を作れる部分へ分ければ候補になります。最初の対象を小さくするのは、AIの役割を固定するためではなく、安定した工程から段階的に広げるためです。
初期は修正理由を集めるため、確認時間が必要です。ただし、同じ修正をテンプレートへ戻しても確認時間が減らない場合は、効果を期待だけで評価せず、範囲の再設計または中止を判断します。将来の効率化を理由に、未確認の成果物を増やさないことが大切です。
AIへ任せたい業務を3つ書き出し、5基準を「満たす・要調整・満たさない」で確認してください。最も重要な仕事ではなく、入力、出力、戻し方、合格条件、確認者を最も具体的に説明できる小さな仕事が最初の候補です。
候補を一つ選んだら、最初の3回で何を記録するかまで決めます。今日の一歩は、導入計画を大きく描くことではなく、一件の業務を一文で定義することです。候補業務をどこまで切れば検証できるか判断しにくい場合は、現在の手順と成果物を基に、小さな試行の設計からご相談ください。