AIに仕事を任せるとき、どのモデルを選ぶかに目が向きがちだ。だが、実際の作業では「資料をどこから読むか」「どの道具を使えるか」「失敗したら誰が止めるか」も同じくらい重要になる。Microsoftが10月28日に発表したCopilot harnessは、複数のAIモデルを同じ作業の仕組みで動かすための土台だ。
発表を読むだけでは、日々の仕事に何が変わるのか見えにくい。そこで、社内の問い合わせを調べて回答案を作るという例で、導入前に決めることを整理する。これは公開情報をもとにした設計例であり、Microsoft Foundry上での実測結果ではない。
モデルの外側にある「作業の仕組み」
Microsoftの公式発表によると、harnessはモデルに与える指示や資料、実行環境、操作の制御をまとめる層だ。モデルが文章を考える頭脳なら、harnessは作業手順書、道具箱、作業場所を一緒に用意する役に近い。
Microsoftは、この仕組みをCopilot Code、Copilot Studio、GitHub Copilotのアプリ、CLI、VS Codeなどで使い、Foundryを通して開発者にも提供すると説明している。SDKを入手する方法と、クラウドで管理された形で使う方法が示された。「同じモデルを使えば同じ結果になる」という話ではない。指示、参照資料、使える道具、確認手順が変われば、作業の品質も変わる。
問い合わせ回答を任せる前の３つの決めごと
１．何を読ませるか
たとえば「経費精算の締め日はいつか」と社員から聞かれる場面を考える。AIが古い社内資料と最新の規程を同時に読めれば、もっともらしいが間違った答えを作るおそれがある。最初に決めるのはモデル名ではなく、正本となる資料と更新日だ。
- 答えの根拠として使う規程・FAQを指定する
- 廃止済みの資料を検索対象から外す
- 資料に答えがない場合は「確認が必要」と返す
この３点がなければ、モデルを替えても誤回答の入口は残る。資料が複数の場所にあるなら、どちらを優先するかも記録しておきたい。出典を示せない回答は、そのまま送らないというルールも実務的だ。
２．どの操作まで許すか
回答案を作る作業と、社員へ送信する作業は別だ。まずは社内資料の検索と下書き作成だけを許し、送信は担当者が承認する形から始めると、問題が起きたときに戻しやすい。読み取り、下書き、送信を一段ずつ分けるのである。
Microsoftはharnessがツール利用や実行環境、制御を扱うと説明している。ただし、特定の組織の権限設定が自動で安全になるという意味ではない。接続する社内システム、与える権限、承認の位置は利用側が決める必要がある。顧客情報や給与情報を扱う仕事なら、閲覧できる範囲から先に確認しよう。
３．何を合格とするか
「賢そうな答え」では評価しにくい。過去の問い合わせから、個人情報を除いた小さな確認用セットを作る。たとえば、通常の質問を10件、例外的な質問を5件、資料に答えのない質問を5件用意する。件数は設計例であり、公開された製品の推奨値ではない。
- 答えが正しいか、最新版の資料に基づくか
- 根拠の資料名と該当箇所を示せるか
- 答えがないときに推測せず止まれるか
- 担当者の修正に何分かかったか
このように正確さ、根拠、保留、修正時間を分けて記録する。回答が速くても、人が直す時間が増えるなら改善とは言えない。費用も同じ確認用セットで比較し、１件あたりの費用と再作業を一緒に見る。
複数モデルを使うなら、比較条件をそろえる
公式発表では、20を超えるモデルや自分のキーを使う方法、作業に合わせたモデルの振り分けに言及している。ここで気を付けたいのは、モデルを替えた効果と、手順を替えた効果を混ぜないことだ。比較するときは、質問、参照資料、権限、承認手順をそろえる。違いは、回答の品質、所要時間、費用として記録する。
たとえば１回目はモデルＡで20件を処理し、２回目はモデルＢで同じ20件を処理する。正解数だけではなく、資料を見落とした件数、根拠のない断定の件数、担当者が修正した時間を並べる。モデルが変わっても失敗例が同じなら、資料や指示の設計を疑う。この切り分けこそ、複数モデルを扱う土台の価値を確かめる方法だ。
もちろん、同じ質問を繰り返すだけでは実務の全ては測れない。規程の更新後に答えが変わるか、曖昧な質問で確認を求めるか、権限外の資料を読まないかも後から加える。最初は小さな確認用セットで誤りの種類を見つける。大きな導入を急ぐより、その方が判断しやすい。
小さく試すための設計メモ
いきなり全社に広げず、１種類の問い合わせで下書きだけを試すなら、次のようなメモを担当者同士で共有できる。実際の導入手順ではなく、業務要件を整理するための例だ。使用する製品の画面や権限設定は、契約と環境に合わせて公式資料で確認する。
- 目的：経費精算の一般的な質問に、担当者向けの回答案を作る
- 資料：現行の経費規程と、担当部署が更新するFAQだけ
- 禁止：申請の承認、送金、社員への自動送信
- 保留：資料にない期限や例外は断定せず、担当者へ確認を促す
- 記録：質問、参照した資料、回答案、人が直した内容を残す
この形にすると「どこまでAIに任せるか」を会議で話しやすい。たとえば「期限を答える」ことは許しても、「個別申請が承認される」と予告することは許さない、と線を引ける。答えを作る能力と、業務を決定する権限は別物である。
確認用の質問には、境界を試す例も入れたい。「締め日が祝日なら翌日でよいか」「前年度の領収書も対象か」といった質問で、資料に書かれていない条件を補ってしまわないかを見る。誤りを見つけたら、モデル変更の前に、参照資料が足りないのか、指示が曖昧なのか、判断を人に戻す条件がないのかを分ける。原因ごとに直す場所が違うからだ。
運用開始後も、規程の更新日に同じ確認用セットを再実行する。前は正しかった答えが、資料の改定で古くなることがある。新旧の規程が同時に見つかるなら、どちらを優先するかを見直す。一度合格したら終わりではなく、資料の変化に合わせて確かめ直すのが肝心だ。
どんなチームに関係するか
今回の発表は、毎日のCopilot利用者全員が設定を変えるべきという知らせではない。主な対象は、複数のモデルを使うAIエージェントを作り、運用する開発者や企業の担当者だ。一つのチャットに質問するだけなら、複雑な土台は必要ない。社内の道具につなぎ、何段階もの作業を任せる時に検討する。
導入を考えるなら、まず自分たちの作業を「参照する資料」「許す操作」「人が確認する場所」「評価する数字」の４列に書き出す。空欄が多ければ、先に運用ルールを整える。仕組みが高度になっても、曖昧な業務手順まで自動で埋めてはくれない。モデル選びの前に、仕事の境界線を引く。そこが今回の発表から得られる、最も使いやすい教訓だ。
