AI社員を利用回数で評価する？
AI社員シリーズ 第2話：評価する能力
あっという間に、そこまで来ましたか（笑）
私は、生成AIに関する動向を継続的に調査しています。
2026年7月末、いつものように調査結果を確認していると、気になる記事がありました。
Microsoftが公開した記事では、AI活用の次の指標として「仕事の変革度合い」が打ち出されていました。
これまでは、AIの導入状況やライセンス数、削減工数などが、活用状況や効果を把握するための指標として使われてきました。今後は、それに加えて、AIによって仕事そのものがどれだけ変わったのかが重要になるという話です。
この記事を読んだとき、思わずこう感じました。
「あっという間に、そこまで来ましたか（笑）」
AIを何回利用したかという数字だけでは、仕事の成果を評価できない。それは、以前から感じていたことでした。
しかし、AIを提供するMicrosoft自身が、仕事の変革を次の評価指標として明確に打ち出す段階になったのです。
AIの利用が広がるだけでなく、その成果を評価する考え方も変化しているようです。
この記事をきっかけに、現在取り組んでいる仕事を振り返ってみました。
私の「AI社員」は、果たしてどれだけの成果を上げているのでしょうか。
私のAI社員は、プログラムを作る開発パートナー
前回の「AIよ、そこまで頼んでいない！」では、AI社員への仕事の指示について考えました。（リンク）
ここで、私がAI社員と呼んでいるものを、改めて説明しておきます。
現在、私は会社で利用できるLLM（大規模言語モデル）を使い、事務処理を自動化する仕組みの開発に取り組んでいます。
当初は、LLM自身が判断基準に従って次の作業を選び、必要なプログラムを実行するAIエージェントを構想していました。
ところが、LLMと対話しながら仕事の手順や判断基準を整理していくと、Pythonなどのプログラムで実現できる部分が、次第に明確になってきました。
結果として、当初考えていたAIエージェントとは、少し違う方向に進んでいます。
私がAI社員と呼んでいるのは、仕事の仕組みを一緒に考え、必要なプログラムを作成するLLMです。
完成したプログラムが、実際の事務処理を担当します。
もちろん、私のプログラミング能力だけでは、この仕組みを最初から開発することは難しかったと思います。
その意味で、AI社員は欠かせない開発パートナーになっています。
では、このAI社員を評価するとしたら、何を評価すればよいのでしょうか。
プログラムを10本作ったら、優秀な社員なのか？
例えば、AI社員が1日に10本のプログラムを作成したとします。
なかなか優秀に見えます。
しかし、作成したプログラムが正常に動かなかったり、要求した仕様を満たしていなかったりすれば、10本という数字に意味があるでしょうか。
逆に、1本しか作成していなくても、そのプログラムによって重要な問題を解決できたとしたら、どうでしょう。
これは、AIの利用回数についても同じことがいえます。
AI社員との対話回数が多かったからといって、必ずしも成果が大きいわけではありません。
前回の記事で紹介したように、私のAI社員は、こちらが指示していないプログラムの作成や変更を始めてしまうことがありました。
その結果、やり直しが発生することもあります。
対話回数が増えた理由が、このような手戻りだったとしたら、利用回数が多いことを成果として評価するのは、おかしな話です。
もっとも、新しいツールを導入した直後であれば、利用回数や利用率を確認する意味はあります。
利用が定着しているかどうかを把握するためには、必要な情報だからです。
しかし、利用が定着してきたら、評価の対象を広げていく必要があると思います。
人間の社員を、パソコンの起動回数やExcelの利用回数だけで評価しないのと同じです。
では、私のAI社員は、実際にどのような成果を生み出したのでしょうか。
私のAI社員と開発した仕組みが生み出した成果
現在開発している仕組みを振り返ってみると、具体的な成果が三つありました。
一つ目は、転記作業の自動化です。
これまでは、内容を確認しながら、手作業で転記していました。
実際の作業時間を調べると、平均14分かかっていました。
現在では、転記自体はすべてプログラムが処理するようになり、人間が行う必要はなくなりました。
ただし、これで14分すべてが削減されたというわけではありません。
自動化に伴い、プログラムが出力するメッセージを確認し、必要に応じて対応するという、新しい仕事が発生したからです。
二つ目は、ログの原因解析へのLLMの活用です。（リンク）
集計システムの実行状況をまとめる作業は、基本的に定型処理です。そのため、プログラムが担当しています。
問題は、WARNINGやERRORが発生した場合です。
以前は、その原因を私自身がログファイルから調べていました。
この原因解析には、平均すると約5分かかっていました。
原因はさまざまで、判断の分岐も多くなります。すべてを従来のスクリプトで処理しようとすると、複雑になりすぎてしまいます。
そこで、原因解析をLLMに任せることにしました。
定型的な集計はプログラムが行い、WARNINGやERRORが発生した場合には、LLMが原因を解析します。
私はその結果を確認し、最終的に判断します。
ここでは、開発パートナーとしてのAI社員とは別に、完成した仕組みの中でもLLMが役割を担っています。
これによって、自分自身でログファイルを調べる負担を減らすことができました。
ただし、LLMの解析結果を確認する時間は必要なので、従来の5分がそのまま削減されたわけではありません。
三つ目は、集計システム自体の自動実行です。
これまでは、私自身が実行していた処理も、自動で実行できるようになりました。
今では、コーヒーを淹れている間に、勝手に処理が進んでくれます。
これが、なかなか便利なのです。
自分で実行を開始する必要がなくなり、その間は別のことをしていられます。
こうして振り返ると、転記、原因解析、集計システムの実行という三つの仕事で、確かな変化が生まれていました。
では、この成果を数字にすると、どれくらいになるのでしょうか。
時間短縮を計算してみたら、評価の難しさに気づいた
最初は、簡単に考えていました。
従来の転記作業が14分、ログの原因解析が約5分。
単純に足し合わせれば、約19分短縮できたように見えます。
ところが、記事を書くために改めて作業内容を整理していると、そう単純ではないことに気づきました。
従来の14分は、転記だけではなく、内容を確認する時間も含まれていました。
現在は転記が不要になりましたが、代わりに、自動実行時に発生するメッセージの確認と対応が必要です。
また、以前は手作業で行っていたログの原因解析も、LLMに任せたからといって、人間の仕事が完全になくなったわけではありません。
LLMの解析結果を確認し、最終的に判断する仕事が残っています。
つまり、従来の作業時間を単純に足し合わせても、実際の削減時間にはならないのです。
正確に評価するには、新しく発生した確認作業や、LLMの解析結果を確認する時間も測定する必要があります。
さらに、WARNINGやERRORの発生状況によって、原因解析が必要になる頻度も変わります。
現時点では、これらを含めた正味の削減時間までは算出していません。
利用回数だけではAIの成果を評価できないと考えていた私ですが、いざ自分自身の成果を評価しようとすると、時間短縮という指標一つをとっても、そう簡単ではありませんでした。
なかなか面白いものです。
AI社員を評価しようとして、評価する側の自分自身にも課題が見つかったわけです。
時間短縮だけでは説明できない成果（リンク）
では、正味の削減時間を計算できなければ、今回の成果は評価できないのでしょうか。
そんなことはないと思います。
今回の取り組みでは、仕事の進め方そのものが変わりました。
転記、異常発生時の原因解析、集計システムの起動という一連の仕事が、人の手作業を中心とした流れから、プログラムとLLMを組み合わせた流れへ変わったのです。
人間の仕事も、自分自身で一つずつ作業を実行することから、仕組みを整え、結果を確認して判断することへと変化しています。
そして、これを実現できたのは、私が一人でプログラムを書けるようになったからではありません。
AI社員と相談しながら仕事を整理し、必要なプログラムを作成してきたからです。
以前の私であれば、ここまでの仕組みを自力で開発するのは難しかったでしょう。
しかし、AI社員という開発パートナーが加わったことで、自分自身が実現できることの範囲が広がりました。
これは、単純な時間短縮とは違う成果だと思います。
そして、もう一つ重要なことがあります。
当初構想していたAIエージェントを、そのまま作ることが成果だったわけではありません。
仕事の手順や判断基準を整理する過程で、従来のプログラムに任せられる部分が明らかになりました。
一方、WARNINGやERRORが発生した際の原因解析には、LLMを活用する価値がありました。
つまり、AI社員と一緒に考えた結果、AIを使うべきところと、従来ITで十分なところを整理できたのです。
AIを利用すること自体が目的ではありません。必要なところにAIを使い、仕事全体を改善することが目的なのです。
今回のMicrosoftの記事で示されていた「仕事がどれだけ変革できたか」という考え方を、自分自身の経験に当てはめると、こういうことなのかもしれません。
では、AI社員をどう評価する？
ここで、最初の疑問に戻ります。
私のAI社員は、優秀だったのでしょうか。
今回、AI社員と一緒に開発した仕組みによって、これまで自分では難しかった業務の自動化を進めることができました。
しかし、その成果をすべてAI社員の手柄にするわけにはいきません。
仕事の目的を考え、必要な手順や判断基準を整理したのは人間です。
AI社員は、仕組みの検討やプログラムの作成を担当しました。
そして、完成したプログラムとLLMが、それぞれの役割に従って実際の処理を担当しています。
今回の成果は、これらを組み合わせた結果です。
では、開発パートナーであるAI社員自身については、何を評価すればよいのでしょうか。
今回の経験から、私は次のような観点が必要だと考えています。
- 依頼した仕事の目的を正しく理解できたか。
- 適切な解決方法を提案できたか。
- 必要なプログラムを正しく作成できたか。
- 不要な作業や変更による手戻りを発生させなかったか。
- 自分一人では難しかった開発を、どこまで実現できるようにしてくれたか。
これらは、今回の記事を考える中で整理した評価の観点です。すべてを定量的に測定したわけではありません。
そして、ここまで考えて、一つ気づいたことがあります。
AI社員が作成したプログラムの品質を判断するには、評価する側が、何を実現したいのかを理解していなければなりません。
提案された解決方法が適切かどうかについても、業務の目的や制約条件を理解している必要があります。
自分自身に専門知識が不足している場合には、別の方法で検証したり、専門家に確認したりする必要もあるでしょう。
つまり、AI社員の成果を適切に評価するためには、評価する人間にも相応の能力が必要なのです。
評価されるのは、AI社員だけではなかった
今回、AIの利用回数から仕事の変革へと評価指標が広がっているという記事をきっかけに、自分自身の取り組みを振り返ってみました。
その過程で、思いがけない発見もありました。
作業時間を整理してみると、当初考えていた単純な時間短縮の計算では、正確な成果を評価できなかったのです。
自動化によってなくなった仕事もあれば、新しく発生した仕事もありました。
また、時間短縮だけでは説明できない成果もありました。
AI社員と一緒に仕組みを開発することで、これまで自分一人では難しかった仕事を実現できるようになり、人間自身の仕事の進め方も変わり始めています。
前回の記事では、AI社員に仕事を任せるためには、人間の「指示する能力」が重要だと考えました。
今回は、AI社員の成果を適切に判断するためには、人間の「評価する能力」も必要だと気づきました。
AIの能力が向上すれば、利用者が何もしなくても成果が大きくなる、という単純な話ではなさそうです。
ただし、AI活用の成果は、利用者の能力だけで決まるものでもありません。AIの性能や利用環境、仕事の内容などにも左右されます。
それでも、優秀なAIを仕事の成果につなげられるかどうかには、利用する人間自身の能力が大きく関わっているのではないでしょうか。
そして、もう一つ考えました。
AI社員が期待した成果を出せなかったとき、評価するだけで終わりにしてよいのでしょうか。
必要な知識や判断基準が不足しているなら、それを教えることも必要なのではないでしょうか。
次回は、AI社員を「学業優秀な新入社員」に例えて、AIに仕事を教える「育成する能力」について考えます。
もしかすると、育成されるのはAI社員だけではないのかもしれません。
参考資料
Microsoft「AIの成果を測る次の指標は、『仕事がどれだけ変革できたか』」（2026年7月31日）
