AIに自分の仕事を覚えさせたい。そう考えると、まず資料を集めたり、指示文を長くしたりしがちです。
しかし、知識が増えただけでは、AIは仕事の判断を再現できません。何を見て、どの条件で判断し、どこで止め、誰に確認を戻すのかが書かれていないからです。
本当に移植したいのは、知識の量ではなく、仕事の判断基準です。この記事では、AIに事業を丸ごと任せる発想をいったん分解し、知識、ルール、スキル、実行権限、モデル選択を分けて設計する方法を整理します。
AIに「全部任せる」と、責任の場所が消える
AIを役職や部署のように分ければ、会社が自動で動くように見えることがあります。企画、制作、確認、公開を別のAIに担当させる構成です。
定型的な変換や分類なら、この分担は役立ちます。一方で、顧客の感情、ブランドの文脈、例外対応、公開してよい範囲などが入ると、AI同士の会話だけでは判断の根拠が薄くなります。
問題は、AIの数ではありません。最終的な意味づけを誰が行い、どの状態で人に戻すかが決まっていないことです。
最初に作るべきなのは「AI社員の人数」ではなく、次の4点です。
- AIが参照してよい情報
- AIが変更してよい情報
- AIが提案だけにとどめる判断
- 人が必ず承認する操作
この境界があれば、AIを1つ使う場合も複数使う場合も、責任の所在が曖昧になりません。
知識・ルール・スキル・実行を分ける
AIに渡す情報は、少なくとも4種類に分けます。
知識
商品、顧客、過去の事例、社内用語など、参照する材料です。事実と仮説、現在の情報と古い情報を区別し、更新日や正本の場所を添えます。
ルール
やってよいこと、禁止すること、承認が必要なことです。公開範囲、個人情報、ファイル命名、出力形式など、判断を制約する条件を書きます。
スキル
特定の仕事を進める手順と判断基準です。入力、手順、例外、合格条件、停止条件まで含めます。単なるプロンプトの言い換えではありません。
実行
ファイルを作る、既存資料を更新する、外部へ送る、公開するなど、環境に影響を与える操作です。実行権限は、知識やスキルとは別に管理します。
この4種類を一つの長い指示文へ詰め込むと、更新のたびに全体が壊れます。情報は参照先へ分け、AIには必要な範囲だけを読ませる方が、確認もしやすくなります。
1つの作業フォルダーを入口にする
複数のAIや開発環境を使う場合でも、業務の入口は一つに寄せると迷いが減ります。ここでいう一つの入口は、すべての機密データを一か所へ集めるという意味ではありません。
たとえば、次のような構成です。
company-ai/
├── README.md # 入口、現在地、最初に読むファイル
├── rules/ # 共通ルール、禁止操作、承認点
├── knowledge/ # 正本、用語、顧客課題の整理
├── workflows/ # 業務ごとの入力と出力
├── skills/ # 手順、判断基準、停止条件
├── projects/ # 進行中案件の状態
└── logs/ # 実行結果、失敗、改善履歴AIが読む入口と、顧客情報や契約情報を保管する業務システムは分けます。入口には機密データそのものではなく、どこに正本があるか、どの範囲を参照してよいかを書きます。
さらに、作業を始める前に必ず読む短いルールを用意します。どのAIから開いても最初の確認事項が揃うため、ツールを乗り換えても業務の前提が残ります。
判断基準は実際の仕事から抽出する
判断基準を最初から完璧に書こうとすると、抽象的な手順書になります。最も再現しやすい材料は、実際に仕事を完了させた会話、下書き、修正履歴、承認コメントです。
抽出の手順は次の通りです。
- 完成した仕事と、うまくいかなかった仕事を2〜3件選ぶ
- 入力、途中の判断、修正した理由、最終的な合格条件を並べる
- AIに「何を見て、なぜこの判断をしたか」を質問する
- 抽出された判断を、本人が事実と解釈に分けて修正する
- 別の事例でも同じ判断が使えるか確認する
ここで重要なのは、AIに自分の人格をコピーさせることではありません。どの条件で例外にし、どの失敗を避け、どの品質なら外へ出すのかを、他人にも読める形にすることです。
スキルに書くのは手順だけではない
業務スキルの最低限の項目は、次の8つです。
- 目的: 何を改善する作業か
- 入力: 何を渡し、何が不足しているか
- 手順: どの順番で処理するか
- 判断基準: 何を満たせば次へ進むか
- 例外: 通常手順から外れる条件
- 禁止事項: AIが勝手に進めてはいけないこと
- 停止条件: 人へ戻す条件
- 出力: 保存場所、形式、確認者、次の工程
たとえば記事作成なら、文章を生成することより、根拠のない数字を削除する、公開前に画像とリンクを確認する、判断に迷う固有名詞は保留する、といった条件の方が再現性を左右します。
スキルを作ったら、すぐ標準にしません。過去事例で動かし、どの判断を誤ったかを記録し、版番号を更新します。完成したスキルではなく、検証済みのスキルだけを共有する仕組みにします。
モデルは能力順ではなく、失敗コストで振り分ける
すべての作業に最も高性能なモデルを使う必要はありません。モデル選択は、作業の難しさより、間違えたときの影響と確認負荷で決めます。
- 短い分類や既知の形式への変換: 速さと費用を優先する
- 手順が決まった文書整理: 標準モデルで処理し、抜き取り確認を行う
- 例外が多い設計や、複数資料の突合: 深い推論と人の確認を組み合わせる
- 契約、金額確定、公開、削除: モデルの性能にかかわらず、人の承認を残す
モデルの切り替えには、次の記録を残します。
- どの工程で使ったか
- なぜそのモデルを選んだか
- 生成時間と確認時間
- 修正回数と失敗の種類
- 次回も同じ選択をしてよい条件
費用だけを見て安いモデルへ寄せるのも、性能だけを見て高いモデルへ寄せるのも危険です。確認時間と手戻りまで含めて比較すると、業務に合う振り分けが見えてきます。
AI同士の連鎖には、確認ゲートを挟んで使う
AIが作った結果を別のAIへ渡し続ける構成は、定型処理の効率化には向いています。しかし、前の判断が誤っていると、次のAIは誤りを前提にもっともらしい出力を作ります。
連鎖を使う場合は、少なくとも次のゲートを置きます。
- 入力が正本と一致しているか確認する
- 中間成果物に根拠と未確定項目を残す
- 人が意味と優先順位を確認する
- 次のAIへ渡す情報を必要最小限に絞る
- 外部送信、公開、削除は別の承認にする
創造性や顧客理解が必要な仕事では、AI同士の役割分担を増やすほど品質が上がるとは限りません。人が判断する地点を減らすのではなく、判断しやすい形へ中間成果物を整えることが先です。
3件のテストと版管理で、分身を育てる
スキルを実務へ入れるときは、いきなり全案件へ適用しません。まず代表的な3件で試します。
| 確認項目 | 見ること |
|---|---|
| 再現性 | 同じ入力で同じ基準に沿って進むか |
| 正確性 | 根拠、数字、固有名詞に誤りがないか |
| 判断の妥当性 | 例外を見落とさず、不要な作業を増やしていないか |
| 確認負荷 | 人の修正時間が短くなったか |
| 復帰性 | 失敗したとき、手作業や旧版へ戻れるか |
評価は「良かった」で終わらせず、失敗を次の版の条件へ書き換えます。v0.1 は仮説、v0.2 はテスト後、というように、更新理由と適用範囲を残します。
この履歴があると、AIの性能向上を待つだけでなく、自社の判断基準を少しずつ明確にできます。AIが自分の分身になるのではなく、自分の仕事を見直す鏡になる状態です。
Optiensの見方
AI活用の最初の成果は、全自動化ではありません。どの仕事ならAIに任せられ、どこは人が担い、何を記録すれば次回の確認が短くなるかが見えることです。
知識を集めるだけでなく、判断基準を抽出する。スキルを作るだけでなく、テストと版管理を行う。モデルを固定するのではなく、失敗コストと確認時間で振り分ける。この3つを分けると、AI導入が「便利なチャット」から、改善できる業務基盤へ変わります。
AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断（無料） で、既存業務のどこがAIパッケージ化しやすいかをご確認ください。実装まで進めたい候補が見えた場合は、導入前スコープ整理 で対象業務、含む範囲、費用感、5営業日で初期版にできるかを整理します。