24
22

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

生成 AI 時代の人材像と、その評価について考えてみる

24
Last updated at Posted at 2026-06-08

はじめに

最近、お客様との打ち合わせや、社内のメンバーとの何気ない会話の中で、「生成 AI 時代に求められる人材像とは何か」という話題になることが増えてきました。そのたびに、自分の考えを改めて言語化しておく必要があるなと感じていたので、今回整理してみることにしました。

生成 AI 時代の人材像というと、最新モデルの使い方、他のモデルとの違い、便利なプロンプト、スキル、機能や Tips を学習することなどが語られがちです。もちろん、学習し続けることは大切なことですが、個人的には、人材像という観点で、本質ではないと考えています。

※本記事は、あくまで現時点(2026/06)での私個人の見解です

全社員が「メンバーを持つ」時代になる

Microsoft 365 Copilot や、最近出てきたエージェント型のサービスは、すでに「業務効率化の延長線上にある便利なツール」という域を超えてきていると感じています。十分に、自分の仕事を頼めるだけのメンバーになってきている、という認識です。

ここで言う「当たり前に使う」とは、新しいツールを使いこなすという意味ではなく、マネジメントの延長線上の話です。つまり、一人ひとりが、人間のように仕事を頼めるメンバーを持つ、ということだと考えています。

この捉え方は、Microsoft が 2025 年の Work Trend Index で打ち出した「agent boss(エージェントの上司)」という方向性とも重なります(2025: The Year the Frontier Firm Is Born)。同レポートでは、AI を「検索ボックスのようなツール」ではなく「新しい種類のチームメンバー」として捉える発想の転換こそが鍵だ、という趣旨のことが述べられています。個人的にも、ここの認識を切り替えられるかどうかが、まず一つの分かれ目かなと思っています。

個人で「メンバーを持つ」から、組織で「メンバーを育てる」へ

ここまでは、一人ひとりが自分のメンバーを持つ、という話でした。Microsoft 365 Copilot のようなものは、基本的にこの個人の単位で効いてくると考えています。

ただ、私はここをさらに、チーム・部門・組織という単位に広げられると考えています。ポイントは、育てたメンバーを「再現可能な形」にして共有することです。

Microsoft 365 Copilot の範囲でも、多くのメンバーに共通する業務があるのであれば、作成したプロンプトや、育成の仕方、依頼の仕方、Agent Builder で作ったエージェントなどを他のメンバーに共有することで、個人のメンバーをチームのメンバーへと広げていけると思います。一人がうまく育てた頼み方が、属人的なノウハウで終わらず、チームの共有資産になる、というイメージです。

そして Copilot Studio のようなサービスは、もともと個人というより、組織の業務プロセスに AI エージェントを最適化して組み込むためのものだと捉えています。業務プロセスそのものを見直し、その中に AI エージェントというメンバーを追加し、育成し、依頼していく。そういった貢献ができるサービスだと考えています。

これらを活用すると、自分がマネージャーとして率いる「AI を含めたチーム」の生産性向上という枠を飛び越えて、より大きな単位で、AI をメンバーとして業務に組み込み、育成し、依頼して成果を最大化していけます。これもまた、生成 AI 時代に組織のアウトプット・成果を最大化するうえでの、重要な貢献につながると考えています。

だからこそ、従来の人材スキルの重要性が増す

メンバーを持つということは、マネジメントが求められるということです。そして、ここが私が一番お伝えしたいところなのですが、生成 AI 時代に求められる能力は、決して新しいものではないと考えています。

むしろ、これまでビジネスパーソンに求められてきたマネジメント能力、人材育成、コーチング、メンタリングスキル、専門性、ビジネス基礎スキル、コミュニケーションスキル、プレゼンスキル、論理的思考能力、意思決定力。こうしたスキルの重要性が、誰もがメンバーを持てるようになったからこそ、いっそう増したのだと思っています。

極端に言ってしまえば、今すでにこれらのスキルを十分に持っている方は、生成 AI も自然と使いこなして、成果を最大化していると私は考えます。

この点については、Microsoft Research と Carnegie Mellon 大学の研究(2025 年, CHI )でも、興味深い結果が出ています(The Impact of Generative AI on Critical Thinking)。AI への信頼が高いほど批判的思考は減り、逆に自分自身の能力への自信が高い人ほど批判的思考をはたらかせる、という傾向です。専門性を持つ人ほど、AI のアウトプットを鵜呑みにせず使いこなせる、ということの一つの裏付けのように感じました。

マネジメントスキルは全員に求められる

従来、マネジメントスキルやプロジェクトマネジメントは、幹部社員や、一定の年次以上の方に対して育成されるものだったという印象があります。少なくとも私は、新卒で入社した会社に 9 年在籍しましたが、マネジメントスキルに関わる研修は非常に少なく、実践を通じて試行錯誤していた記憶があり、個人依存が高かったと記憶しています。しかし、これからは、全員がより求められるようになるのではないかと考えています。

当たり前のことではありますが、マネジメントスキルのないマネージャーのチームは、成果が最大化されません。メンバーが人から AI に変わっても、この構造は変わらないと考えています。

仕事を人(や AI)に依頼して成果を最大化するためには、「そもそも、なぜこの仕事をやる必要があるのか」という問いを立て、自分の仕事を言語化し、手順化、細分化し、優先順位をつけ、依頼して、進捗を管理して、レビューして、意思決定するという基礎スキルが土台になります。ここはこれまでも大事だったことですが、メンバーを持つ前提に立つと、より明確に効いてくるところかなと思っています。

実際、World Economic Forum の Future of Jobs Report 2025 でも、分析的思考が引き続き最重要のコアスキルとされ、リーダーシップ・社会的影響力や人材マネジメントが今後さらに重要性を増すスキルの上位に挙げられています(Future of Jobs Report 2025)。新しいスキルというより、これまで大事だったものの比重が上がっている、という見方ができるかと思います。

人材育成こそ、重要性が増す

ここが、一番簡単には代替されない部分だと考えています。

正直なところ、部分的には、特に若いメンバーよりも、AI のメンバーの方が能力が高い、というケースも出てくると思います。ただ、それをマネジメントできない人間だった場合は、結局チームの成果は最大化されません。

人材育成は、IT スキルのように数値化しにくく、一朝一夕で身につくものでもない、非常に泥臭いスキル、行為だと思っています。そして、人は感情で動く生き物であり、育成は生き物で変数が多すぎる。だからこそ、ここは簡単に AI に任せればいい、という話ではないと考えています。

加えて、最近よく指摘される論点として、「若手が経験を積む場が失われるのではないか」という問題があります。従来は、若手が手を動かしながら判断力を養い、やがて任せる側に回る、という階段がありました。その下段の作業を AI が担うようになると、若手はどこで意思決定の土台を積むのか、という問いが残ります(この懸念は各所で指摘されています。たとえば How AI is changing the nature of entry-level work(WEF) など)。

ただ、ここは見方を変えれば、育成の機会だとも思っています。若手自身が AI をメンバーとして持ち、最終的に自分で意思決定する。その意思決定と、上位者から見た判断との間にギャップがあるのであれば、「なぜその意思決定をしたのか」「AI のアウトプットをどう評価したのか」、「AI にどう依頼したのか」を言語化する。そこが、能力を養う場になると考えています。むしろ、何を自分が判断したのかが可視化されやすくなり、フィードバックの介入点はかえって明確になる側面もあるかなと感じています。

もちろん、これも上位者が丁寧にギャップを言語化してフィードバックできるかどうかにかかります。結局のところ、ここでも人材育成スキルが効いてくる、という構造になっているのだと思います。

「専門外の成果物を評価する力」の本質

IT の専門家でない方が、生成 AI を使ってアプリを作る。そういった機会は、今後ますます増えていくと思います。このとき「コードの良し悪しをレビューできるか」が問われると思われがちですが、個人的には、そこが本質ではないと考えています。

最終的にビジネスの意思決定をするうえで重要なのは、その成果物が「何のビジネスの問いに対する手段なのか」という点です。資料であってもアプリであっても、ここは変わらないと考えています。コードの技術的な良し悪しはもちろん大事ですが、それは「どこまでリスクを許容するか」という話であって、不安があるのであれば、別の手段(専門家のレビュー等)を取ればいいだけだと思います。

本質は、目的を適切に設定できるか。正しい問いを立てられているか。その問いに照らして、最終的に意思決定・判断できるか。ここだと考えています。

では、何をもって測るのか

ここまでが「どんな能力が大事か」という話で、ここからは「では、それをどう測るのか」という話です。お客様からも、社内の評価設計の文脈でも、相談をいただくことがあるテーマです。

大前提として、最終アウトプットが主役

大前提として、最終ゴールはビジネスの結果、つまり生産性やアウトプットです。AI をメンバーとしてマネジメントすることで、ここが高まるはず。ですので、評価面談などでも、まず最大限に評価されるべきは、最終的なアウトプットそのものだと考えています。AI を使ったか使わないかに関わらず、ここが本丸です。

そのうえで、いきなりそこを担えない方もいると思います。だとすると、途中経過のチェックポイントや、成果を説明するための材料として、何かしらの観点を補助的に置くこともありかなと思います。たとえば AI の活用率を指標の一つに含める、といったケースです。

ただ、ここで冷静に見極めたいのは、活用率はあくまで手段であって、目的ではない、ということです。活用率を上げること自体が目的化してしまっては、本末転倒だと思います。あくまで先行指標のひとつにとどめ、最終的にはアウトプットで測る。手段と目的を取り違えないようにしたいところです。

過程は「成果のアピール軸」として認める

そのうえで、同じ成果に対して「どう AI を使いこなし、マネジメントし、依頼したのか」という過程も、一つのアピール軸として認めてよいのではないかと考えています。位置づけとしては、なぜその成果を出せたのか、なぜ再現できるのか、を説明するための補助線、というイメージです。主役は、あくまで成果に置きます。

過程を見る切り口としては、AI との協働を整理したフレームワークが参考になります。たとえば Anthropic が公開している「AI Fluency」フレームワークでは、4 つのコンピテンシー(Delegation / Description / Discernment / Diligence)で整理されています(The AI Fluency Framework)。私なりに業務の言葉に言い換えると、以下のような対応になるかと考えています。

観点 元の表現 かみ砕くと 見たいこと
依頼 Delegation 何を自分でやり、何を AI に任せるか ツールを開く前に、線引きを意図を持って考えられているか
記述 Description 仕事を言語化・細分化して伝える 目的と文脈を添えて依頼できているか
評価 Discernment 出てきたものを見極める 「このビジネスの問いを満たすか」で評価し、第一稿を鵜呑みにしていないか
責任 Diligence 最終成果物に責任を持つ 自分が何を意思決定したのかを説明できるか

この 4 つは、これまで述べてきた「問いを立てる」「言語化する」「目的に照らして評価する」「最終意思決定する」という話と、ほぼ一対一で対応していると感じています。

具体的な測り方の案

数値だけでなく、振る舞い(コンピテンシー)で見る観点が重要になると考えています。いきなり精緻な仕組みを目指すのは現実的ではないと思うので、まずは軽いところから始めるのが良いかと思います。現実的に使えそうな手段をいくつか挙げてみます。

  • 4D 振り返りシート:代表的な成果物 1〜2 件について、上の 4 つの観点を本人が言語化する。最も軽く始められ、そのまま評価面談でのアピール材料になります。
  • 意思決定ジャーナル:立てた問い/ AI の提案で採ったもの・捨てたもの/その理由を、数行で残す。AI の第一稿と最終版の差分(before / after)を添えると、評価(Discernment)の質が客観的に見えやすくなります。
  • 再現性・横展開:一発の成果で終わったのか、テンプレートやエージェント、業務プロセスに落として仕組み化できたのか。少人数で成果を最大化する、という観点の核になるところです。
  • 上司側のストレステスト:面談で「この前提が崩れたらどうなりますか?」「AI がここで間違っていたら気づけましたか?」と一段掘ってみる。鵜呑みにして通したのか、理解したうえで通したのかが見えてきます。

これらはあくまで案であり、箇条書きのまま運用するものではないと思っています。補足として、運用上の注意点を 3 つ挙げておきます。1 つ目は、過程の指標はあくまで補助線に徹すること。主軸は必ず成果に置く、という点です。2 つ目は、育成や責任は数値化しにくいので、無理に数値化せず、定性で扱う方が健全だという点です。3 つ目は、評価者の間で言葉の基準を揃えないと、結局は印象評価に戻ってしまう、という点です。

なお、市場の温度感としても、AI フルーエンシーを測り・育てるニーズは急速に高まっているようです(複数の調査で、全社的な AI フルーエンシーの向上を人材戦略の最優先に挙げる企業が増えている、という報告があります)。指標化そのものへの関心は、今後さらに強まっていくのではないかと考えています。

成果を出した人を、組織のロールモデルにする

評価の話に関連して、もう一つ付け加えておきたいことがあります。

実際に社内で、生成 AI をフルに活用し、AI を人と同じようにメンバーとしてマネジメントすることで、結果的に大きなアウトプット・成果を出している人がいるとします。そういう人がいる場合は、まず適切に評価をする。そのうえで、その人を「組織が求める人材像」、言い換えれば生成 AI を使いこなしたマネジメントの一つの形として、組織に広く共有・紹介していくことは、少なからず有効だと考えています。高い生産性を発揮している例として紹介する、というイメージです。

というのも、多くの人は、成果を出したい、世の中に貢献したい、評価されたい、という欲求を少なからず持っていると思うからです。身近な人が大きな成果を出していれば、自分もそれに負けないように、真似をしたり、参考にしたりする。そういう動きは自然と出てくると思います。トップダウンで「使いなさい」と促すよりも、こうした横の広がりのほうが、定着という意味では効くこともあるのではないかと感じています。

ただ、ここで一つ気をつけたいことがあります。それは、「ものすごく学習しないと、こういう成果は出せないのだ」という印象を与えないことです。AI という、特に IT の専門部署でない方からすると未知に感じられる分野について、相当な勉強が必要だと思わせてしまうと、かえって遠ざけてしまうように思います。

実際のところ、Microsoft 365 Copilot のようなサービスは、ものすごく学習して使いこなすというより、従来のマネジメントの延長線上としてフル活用すれば、大きな成果につながると考えていますし、個人的に、それがサービスの目指す姿だと思っています。十分な専門性やマネジメントの経験を持っている方であれば、現状は意図を「翻訳」するために学ぶことはあっても、同じように成果を出せるものだと、私は思っています。これは、この記事で述べてきた「新しいスキルというより、従来の力の延長線上にある」という話とも、つながってくるところです。

まとめ

今回は、生成 AI 時代の人材像と、その評価の考え方について整理してみました。要点を振り返ると、以下のようになります。

生成 AI 時代の人材像は、目先の Tips ではなく、マネジメントと人材育成という、昔から大事だった営みの延長線上にある、というのが私の見立てです。誰もがメンバー(AI)を持てるようになったからこそ、マネジメント・専門性・ビジネス基礎・意思決定力といった従来の高度なスキルの重要性は、むしろ増したと考えています。そして評価については、最終アウトプットを主役に置きつつ、「依頼・記述・評価・責任」という過程を補助的なアピール軸として認める。活用率のような手段を、目的と取り違えない。このあたりが大事かなと思っています。

ここで挙げた評価の手段は、あくまで現時点での案です。実際の現場では、もっと良い測り方があるかもしれません。「私のところではこうしている」「こういう観点も使えるのでは」といった声をいただけると、とても嬉しいです。

本記事が、生成 AI 時代の人材育成や評価設計について考える方の、何かのお役に立てば幸いです。

24
22
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
24
22

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?