同じKPIを見ているつもりでも、営業部と経営企画で数字の定義が違う。業務ルールは仕様書に書かれず、担当者の頭に残っている。こういう会社に高性能なAIモデルを入れたら、どちらの数字を使い、誰の判断に従って仕事を進めるのだろう。
AIエージェントの議論は、推論能力、長文処理、ツール利用、コード生成、マルチモーダル対応といったモデルの性能に向かいやすい。進歩によって自動化できる仕事が増えたのは確かだ。ただ、企業の現場で成果が出るかは、モデル以外の条件にも大きく左右されると思っている。
自社の業務、データ、知識、権限、判断基準を、AIが扱える形につなげられるか。そのために仕事を組み替え、現場で使い続けられるか。エージェント時代の競争優位は、こうした文脈の実装と運用にあるのではないか。
AIに渡っていない業務の前提
自然言語で依頼を受け、複数の情報源を調べ、判断を伴うタスクを進める。AIが仕事の流れに入れる範囲は広がっている。しかし、企業の仕事には、入力も正解も明確なベンチマークと異なる難しさがある。
データは散在し、定義は揺れ、例外処理は多い。意思決定の背景が文書化されていないこともある。モデルが一般的な知識を持っていても、その企業で何を正しいとし、何を優先し、どの順番で判断するかは、それだけでは分からない。
自分は、企業のAI活用でまず疑うべきなのは、この前提の不足だと思っている。ここでいう「接続」はAPI連携に限らない。データ同士の関係をそろえ、どの業務で使うかを定める。業務の評価基準を置き、その基準で決める責任者を明らかにする。個人の暗黙知を取り出し、次の担当者やAIも再利用できる形にする。こうした接続が必要になる。
冒頭のKPIなら、モデルを替える前に、部門ごとの定義の違いと使い分けを明確にしたい。それが整えば、どのモデルを使っても同じ前提を渡せる。モデルをある程度差し替え可能にするためにも、企業の文脈をモデルの外で管理する意味がある。
提案を意思決定に使える条件
営業で「次に提案すべき商品」を出せても、そのまま現場で使えるとは限らない。どの顧客情報に基づき、過去のどの施策と整合し、どの制約の下で有効なのかを確かめたいはずだ。提案を受け取る人が、その根拠を追える必要がある。
分析でも、グラフや示唆を作ることと、それを意思決定に使えることには差がある。どのデータ定義を使い、どの仮説を前提とし、どの判断に役立てるための分析なのか。後から辿れなければ、結果を評価し、修正することが難しい。
予測精度や自動化率は引き続き測れる。しかし、エージェントの評価には、出力を組織の判断に使えるかも含めたい。答えの精度はモデル性能に左右される一方、根拠を確かめ、責任を持って採用できるかは、仕事の設計にも左右されるからだ。
結果だけでは分からない、判断の理由
顧客や案件の文脈は、売上テーブルや顧客マスタだけには収まらない。議事録、提案書、過去の分析メモ、失注理由、例外対応の履歴、社内ルールを更新した経緯にも含まれている。とくに「なぜそう判断したか」は、結果だけを記録したデータからは分からない。
これらは半構造・非構造の情報で、検索しにくく、個人の手元に閉じたままになりやすい。だが、先ほどの営業提案が過去の施策と矛盾しないかを確かめるには、その施策の理由も必要になる。判断の経緯を残した記録が、提案の評価に直接関わる場面だ。
文書をためて検索できるようにするだけでは、この用途を満たせないこともある。誰が、どの判断の前に、どの記録を確認すべきかまで、業務の流れに組み込みたい。知識を保存する作業と、仕事で再利用する設計は、続けて考える必要がある。
エージェントを前提にした仕事の分担
文脈をそろえても、人間とAIの役割が曖昧なら運用は安定しない。既存の仕事にAIを追加する際には、少なくとも次を決めたい。
- 人間が判断・承認する内容
- AIが探索できる範囲と、人へ引き渡す条件
- 保存する判断ログ
- 許容する失敗と、防ぐべき失敗
- 分析や判断のパターンを再利用する方法
例えば、AIが提案を作り、人間が採用を判断するなら、採用者が根拠を追える出力と記録が必要になる。AIの探索中の失敗を許せても、顧客への誤送信は防ぎたいなら、その二つを同じ権限で実行させるべきではない。分担と制約を決めて初めて、どこを自動化できるかも見えてくる。
この設計が抜けると、便利でも責任を持って使えず、速くても確認に手間がかかり、試行の後に定着しないという状態になりやすい。だからエージェント導入は、業務再設計の仕事でもある。人間の判断、AIの作業、責任の境界を一緒に組み直す必要があると思う。
文脈を実装する人の技能
この仕事を担うには、最新モデルに詳しく、プロンプトを上手に書けるだけでは足りない。もちろんそれらも大事だが、モデルやインターフェースが変われば差は縮まりやすい。持続する価値として、自分は次の力に注目している。
- 業務を観察し、エージェントを使う場所を見極める
- データ定義の曖昧さを見つけ、整理する
- 暗黙知を引き出し、再利用できる形にする
- 評価指標と失敗の許容範囲を設計する
- 承認、差し戻し、監査を組み込む
- PoCの結果を現場の継続運用につなげる
データ定義をそろえるだけでも、分析、業務の優先順位、システム設計をまたぐ判断がある。評価基準を決めるときも、技術的に測れるものと事業が必要とするものを合わせる必要がある。データサイエンティスト、AIストラテジスト、アーキテクトの仕事が重なる領域だ。
AIエージェントを導入しようとすると、まず自社の未整理な部分に気づくかもしれない。KPIの意味が違う。判断基準が人によって違う。過去の理由を知る人が限られている。誰が採用を決めるかもはっきりしない。モデルが答えを返せるようになった分、その答えを仕事に使う側の条件が問われる。
自分は、ここに実務家の価値があると思っている。冒頭の二つのKPIを見て、単に片方をAIへ渡すのでなく、なぜ違い、どの判断ではどちらを使うべきかを確かめる。そのうえで、次から同じ迷いを繰り返さずに済む仕組みを作る。モデルが進歩しても、この仕事が自動的に済むとは思えない。