序
Copilot Studio でエージェントを作成して実際にテストしたときに（エラーの場合を除き）期待した回答が返ってこないことがあります。このような場合、モデルを変更したり、指示文（プロンプト）を見直したりする人は多いように思います。
指示文の例であれば、より詳しく指示すればよい、禁止事項を追加すればよい、あるいは、具体例を増やせばよい…といったような考えに至り、指示文を書き足している場面によく遭遇します。
ただ、読者の皆さまのこういった着想は真っ当で、モデルや指示文の改善によって解決する問題はあります。とりわけ「指示」に関して述べると、これが曖昧であれば、生成 AI が意図を正確に解釈できない可能性も高くなるためです。
モデルに関しても、高性能モデルや最新モデルであれば期待する出力を得られる、という保証は必ずしもありません（もちろん、将来的にできることはより増えていくはずです）
ただ、それと同時に「モデルは高性能であればよい」というわけでも「指示文は書けば書くほどよい」というものでもありません。これは人間に仕事を依頼するときと同じで、相手に仕事を上手く消化してもらえない原因は「人間（＝モデル）」とも「依頼の仕方（＝指示文）」とも限らないためです。
例えば、必要な資料が不足している、仕事の範囲が広すぎる、手順を決める必要がある、そもそも別の道具を使った方がよい、といった原因も考えられるのではないかと思います。
今回の記事のテーマである Copilot Studio でも、モデルや指示文は「エージェントを構成する一要素」に過ぎません。期待する成果が返ってこない場合、筆者は、これらだけではなく、情報（ナレッジ）や会話の流れ（トピック）、さらに Power Apps や Power Automate、AI Builder などとの役割分担まで含めて解消に導く必要があるのではないかと考えています。
当記事は、さまざまな生成AIツールの内、Copilot Studio に絞った対応策をまとめていますが、場合によっては、他の生成AIツールにも応用できるようなことが書かれてあると思います。
0. 当記事の Copilot Studio について
本題へ入る前に、本稿で扱う Copilot Studio のエージェント作成方法について整理しておきます。現在の Copilot Studio には、"Standard harness" と "GitHub Copilot harness" という二つの作成方法があります。どちらもエージェントを作成できますが、設計思想や利用できる機能、課金体系などに違いがあります。
なお、本稿では両者の違いを紹介しつつも、内容は Standard harness を前提とした考え方が中心となります。 GitHub Copilot harness にも応用できる部分は多くありますが、トピックなど Standard harness 固有の機能についても解説するためです。
Standard harness では「この回答が選ばれたら、この処理へ進む」といった会話の流れを、あらかじめ作成者側で制御できます（※このような会話や処理のまとまりを「トピック」と呼びます）。厳密には、トピックだけでなく生成AIによる回答を組み合わせて構築することもできるため、会話をすべてトピックだけで構成する必要はありません。
一方、GitHub Copilot harness では、トピックによって細かな会話の流れを設計する代わりに、生成AIが指示文やナレッジ、利用可能なツールなどを踏まえ、自ら次に実行すべき処理を判断する設計思想が採用されています。
格好つけて述べるなら、人間があらかじめトピックによって道筋を作っておく方法から、ある程度の道筋をAI自身に考えてもらう方法へと、エージェントの作り方が変化していると考えられます。
後者は、作成者が細かな会話の流れをすべてコントロールしなくてもよいという点から、ITやシステム開発の経験がない人にとっても、エージェントを作成しやすくなったと言えます。
また、新旧の違いは、作り方だけではありません。利用にかかる費用の考え方にも違いがあります。
Standard harness では、エージェントが行った回答や処理などに応じて Copilot Credits が消費されます。基本的には、作成しているだけではなく、公開したエージェントが利用される段階で消費が発生する仕組みです。
一方、GitHub Copilot harness では、より広い範囲が使用量に応じた課金の対象になります。利用者がエージェントを使用するときだけではなく、作成者がプレビューやテスト、評価を行ったりする際にも Copilot Credits を消費する場合があり、エージェントが処理する情報量や、利用するナレッジ、ツールなどによっても消費量が変わる認識です（※記事公開時点での情報です）
そのため、GitHub Copilot harness では「エージェントを１回利用するといくら」と単純に考えるより、どの程度AIに考えさせ、どのような機能を使わせるのかによって費用も変わると理解しておく方がよいでしょう。
これは、本稿で扱う「AIにどこまで任せるか」という判断軸とも関係します。AIへ必要以上の判断を委ねず、役割を適切に整理することで、期待する成果や管理性、費用のバランスを取りやすくなる可能性があるためです。
期待する成果、安定性、管理のしやすさ、そして費用まで考慮すると、生成AIを使う能力以上に、何を任せ、何を任せないかを判断し、適切に制御する能力が求められるようになるのかもしれません。
これらの見解について、委細は上の記事をご一読いただけますと幸いです。また、当記事末尾でも筆者の見解を付しておきます。前置きが長くなりましたが、本題に入りましょう。
1. Copilot Studio 以前の 「設計」
さて、最初に確認したいのは、Copilot Studio を使用する以前の問題です。上手く回答を得られないケースを見ていると、そもそも、モノづくりに欠かせないはずの「設計」が十分にできていないことがあります。
例えば「社内規程に関する問い合わせのAIエージェント化」は、Copilot Studio の文脈でよく取り上げられる事例の一つです。
ところが、その要件が「社内ナレッジをもとに回答するエージェントを作成したい」で止まっていることがあります。これは、設計ではなく要望です。
社内規程に書かれている内容を探して回答するだけでも、問い合わせ対応を効率化することはできます。しかし、実際にエージェントに尋ねられるのは、必ずしも規程にそのまま答えが書かれていることばかりではありません。
例えば「有給休暇」に関する問い合わせ一つを取っても、以下の箇条にあるような問い合わせが多く寄せられているのではないでしょうか。
- 試用期間中でも有給休暇は取得できるのか
- 休職中の有給休暇はどう扱われるのか
- 退職前に残っている有給休暇はどうなるのか
- 時間単位で取得できるのか
残念ながら、他部署の人々に「規定に書いていないことはできない」は通用しません。基本的には、制度そのものではなく「自分の置かれている条件ではどうなるのか」が尋ねられるはずです。
すべての質問を事前に予測してナレッジを用意することなど不可能ですが、設計の段階で（ある程度で大丈夫なので）実際に、どのような質問が寄せられるのかを想像して備えなければなりません。
例えば、回答に必要な情報が見つからなければ（その旨をユーザーに伝えた上で）担当者への問い合わせを希望するかを確認し、希望する場合には問い合わせ内容を SharePoint リストや Dataverse などに登録します。
それと同時に、回答担当者へ Teams で通知することで、ある程度の漏れを防止できそうです。余談ながら、案件進行中などのステータスを列で保持していれば Power Automate によるリマインドも実現できるでしょう。
担当者が回答した後は、その結果をユーザーへ Teams で返答して作業を完了する…といった流れです。Copilot Studio 自体の設定以上に、他の Microsoft 365 ツールとの連携の方も重要であることが分かります。
問い合わせ履歴を保管しておくことのメリットは、この問い合わせ履歴そのものもナレッジとして設定しておくことができる点です。Copilot Studio の利用実績があればあるほど、回答担当者の仕事量は軽減されます。
ここまで考えて初めて「社内規程について回答するエージェント」ではなく「社内規程に関する問い合わせ対応を支援するエージェント」という業務全体の姿が見えて来るのではないでしょうか。
「期待する回答」と「回答できない場合の対応」を決めていますか？
2. ナレッジ管理は適切なのか
正しい回答には、その根拠となる情報が必要です。この情報源を「ナレッジ」と呼んでいます。Copilot Studio では、SharePoint に保存されたファイル（や Web サイト）など、さまざまな情報をナレッジとして利用できます。
2.1. 生成AI の活用を意識したナレッジ管理
回答に必要な情報がナレッジに存在しなければ、指示文を改善しても解決しません。また、情報が増えれば増えるほどエージェントが判断すべき対象も増えるため、回答が安定しない可能性も考えられます。
ナレッジの種類としては、就業規則や休暇規程、過去の問い合わせ履歴などが候補になるのではないかと思いますが、いずれにしても、登録さえしてしまえばエージェントの作成が完了する⋯というのは、少々乱暴です。
これらを闇雲にナレッジとして登録するのではなく、登録の仕方を工夫することで安定して稼働するエージェントを作成できます。
一例に過ぎませんが、筆者は「人間が仕事をするときに渡されて嬉しい資料」が、そのまま良いナレッジになると考えています。
具体的には、一つの業務やテーマに沿って整理され、現在有効な情報であることが分かり、かつ、重複や矛盾がない資料です。反対に、古い情報や用途の異なる資料が混在し、どれを参照すればよいのか判断できない状態では、人間だけでなく生成AIも迷ってしまいます。
人事担当者へ休暇制度について質問するときに、経理規程や品質マニュアルまで渡す人はあまりいないように思います。このイメージで Copilot Studio のナレッジを管理するとよいのではないかと考えています。
「人間が探しやすいだけではなく、コンピュータも探しやすい状態で情報を管理する」ことについて、上に引いた資料は参考になります。Copilot Studio だけでなく、Microsoft 365 Copilot で特定のファイルを検索できるようにしたい場合にも役に立つはずです。
2.2. Copilot Studio の機能面で制御する場合
Standard harness の場合、他にも、以下の画像のように「トピック」を作成したり、エージェントフローを活用するなどして、会話や定型処理をコントロールするとよい場合があります。
↓↓
特に、Standard harness であれば、トピックを新たに作成した上で「リダイレクト」し、その先に「生成応答を作成する」ノードを配置しておくなどすると、より明示的に、エージェントに対して指示できます。
全く分野の異なる複数の作業を依頼する場合は、思い切ってエージェントを分類する機能（マルチエージェント）を活用することも視野に入れると良さそうです。
ユーザーからの質問を親エージェントが子エージェントに振り分けるように設定しておくことで、Copilot Studio が回答しやすくなる利点があります（※ただし、通常のエージェントよりもコストがかかる点には注意を要します）
基本的には「この中に答えがあると思うので調べてください」と大量の資料を相手に渡すよりも「休暇についてはこの規程を確認してください、こちらが現在有効な規程です」と整理して渡した方が、調査する側も判断しやすくなるはずです。
繰り返しになりますが、必要な情報が不足していれば回答できませんし、古い情報、内容の重複した文書、似た名称の資料、今回の業務とは無関係の情報まで大量に含まれていれば、エージェントが適切な情報を選択するための判断も必要になります。
2.3. Web サイトをナレッジとして利用する場合
また、Copilot Studio（Standard harness）で Web サイトをナレッジとして利用する場合、情報量が多いほど回答精度が上がるとは限らない点に注意が必要です。これもやはり、大量のページや類似情報および古い情報が混在すると、質問に対して適切な情報を検索しにくくなる可能性があります。
サイト全体を登録しても、すべてのページを網羅して参照できるとは限りません。URL の深さも最大で２レベルと定められているため、必要な情報の範囲を絞り、情報の整理や更新状況を管理することが重要だと考えます。
なお、Web サイト内の全データを収集して集計するような用途では、ナレッジ検索だけで網羅性を保証することは難しいため、Power Automate などによる明示的なデータ取得を検討する必要があります（※組織によってはこの操作を制限している場合があるため話し合いなど発生しそうです）
2.4. どんなナレッジを用意すればいいのか
以上の観点から、ナレッジを用意するときには、以下の箇条のようなチェック項目を掲げておくとよいかもしれません：
- 人間が見ても内容や用途を判別できる状態になっている
- １つのエージェントに大量の情報を渡さない（用途に応じてトピックなどに分類する）
- ノイズの原因になる不要な情報がナレッジ内に存在しない
- どの情報が現在有効なのか判断しやすい
エージェントが必要な情報だけを探せる状態になっていますか？
3. 「概要」 の指示文だけで解決しようとしていないか
冒頭でも述べた通り、期待した回答が返ってこない時に「指示文を修正しよう」と考えるのは、ごく自然な流れなのかもしれません。実際、指示文はエージェントの振る舞いを左右する重要な要素であるためです。
役割や回答方針、回答できない場合の対応などを明確にすることで、期待する結果へ近付けられる場面も少なくありません。その一方で、指示文が担える役割には限界がある認識です。
例えば、エージェントへ「人事制度について回答してください」と依頼することはできます。「情報が見つからない場合は推測して回答しないでください」など伝えることもできます。
その反面、「どの規程を優先するのか」や「どの範囲まで回答するのか」ならびに「問い合わせ内容によってどの部署へ引き継ぐのか」といった業務全体の設計まで、１つの指示文だけで解決することは（あくまでも筆者の観測範囲においては）難しい印象です。
ただ、この問題は「人間へ仕事を依頼する場面」を考えると理解しやすいように思います。一般的に、依頼書には、仕事の目的や注意事項を書きます。参考資料の管理方法や、組織の役割分担、業務フローそのものまで、一枚の依頼書へ書き込むことは考えにくいです。
Copilot Studio の概要（Instructions）も、それと大きく変わりがないと考えています。設計が曖昧であれば、設計を見直す必要がありますし、情報が不足していれば、ナレッジを見直す必要があります。複数の業務を一つのエージェントへ集約しているのであれば、子エージェントへの役割分担を考える必要があります。
指示文は、要点を絞ってまとめておくことが大切です。期待した回答が返ってこないとき、指示文へさらに一文を書き足す前に「この問題は、本当に指示文で解決する問題なのか」と考えてみる価値はありそうです。
指示文は、設計書ではない。設計された仕事を他者に依頼するためのもの
4. Copilot Studio だけで解決しようとしていないか
Copilot Studio の利用者の中には、一連の業務処理をすべて Copilot Studio エージェントの中で完結させたいと考えている人は少なくないはずです。
しかし、Power Platform には、異なる役割を持ったサービスがあります。それぞれの得意分野を組み合わせた方が、より処理が安定するような傾向にあります。
4.1. Copilot Studio の得意分野
Copilot Studio が得意とするのは「人間の自由な入力による要求や、特定のアクションが発生した場合に、次なる処理へと繋げること」です。
ユーザーが入力した自然な文章を理解し、その内容に応じて回答を生成したり、ナレッジを検索したり、必要に応じて他のサービスを呼び出したりすることができます。
反対に、厳密な条件分岐や、決められた手順を決められた様式通りに確実に実行することは、不得意であることがほとんどです。この場合は、他の Power Platform ツールで解決するか、部分的に作業を委任するような設計が必要と考えられます。
4.2. Power Apps
利用者から必要な情報を集めることが目的であれば、自由な入力よりも「入力フォーム」の方が適している場合があります。例えば、休暇申請、経費精算、備品管理といったようなものです。
こういった台帳管理業務では、入力漏れや入力ミスを防ぐことが重要になります。したがって、会話のような入力を求めるのではなく、Power Apps で入力画面を用意した方が、利用者や管理者にとって扱いやすいデータとなるケースが多いです。
また、Power Apps は、決められた様式通りにデータを入力してもらうだけのツールではありません。上に引いた画像のように、未読件数やキーワード検索といったように、直感的な操作で必要なデータに安定してアクセスできる仕組みを作れます。
一方、Copilot Studio の場合だと、何かを検索したいといった場合、ユーザーによる毎回の入力が発生するのに加え、その入力に対して費用が発生します（正確には Copilot Credits の消費）
Power Apps で実装すれば、Teams、Outlook、Excel といった Microsoft 365 のサービスを利用するのと同じ料金体系でこういった便利ツールを作成することができます（※AI機能などを利用する場合は別途費用が発生します）
4.3. Power Automate
Power Automate は、決められた条件に従って処理を実行することを得意としています。例えば、定期的な通知業務（リマインド）、Outlook によるメールの送信、承認が必要な申請業務など、日々の繰り返し業務が該当します。
例外処理が（少）ないのであれば、生成AIに「どう処理するか」を考えさせるより、決められたルールに従って処理を実行した方が、安定した結果を得られる場面も少なくありませんし、こちらも Power Apps と同様に、Microsoft 365 の料金体系で基本的には利用可能であることから、安価に業務効率化が見込めるといえそうです。
4.4. AI Builder
AI Builder は、文書や画像などから必要な情報を抽出することを得意としており、Power Apps と Power Automate の機能を拡張するような使い方ができます。例えば、請求書や申込書、契約書などから必要な項目を取り出し、後続の処理へ受け渡すような用途です。
このような処理を Copilot Studio で実現すること自体は可能ですが、AI Builder の方が安価かつ安定的にシステムを構築できる利点があります（ご利用には追加ライセンスを要します
また、PDFを受け取り、必要な項目を読み取り、SharePoint に登録する仕組みを考えるとします。この仕組み自体も、Copilot Studio で実装することは可能ですが、無理に利用せずとも、Power Apps や SharePoint リスト及びドキュメントライブラリの Forms 機能を活用することで実現できます。
なお、手書きの領収書や申込用紙などを AI Builder で抽出する際、稀に誤字や脱字が発生します。そういった時は、Power Apps に AI による解析結果を、一度、戻してあげることで、人間の目で確認してデータを登録することもできます（※ Power Automate 単体でも、承認コネクタの「テキスト付きの承認」アクションを活用することで同様の実装ができます）
以上のように、文書の解析を AI Builder、登録処理を Power Automate、必要に応じた入力や確認を Power Appsにお願いし、最後に、蓄積された情報との対話において Copilot Studio（Standard harness）を活用することで、Copilot Credits の節約を見込めます。
役割を分けることで各サービスに求める処理が明確になり、Copilot Studio に記述する指示も小さくでき、かつ、何か問題が発生した際の切り分けもしやすくなる印象です。
Copilot Studio だけでなく、他のツールの利用も検討してみましょう
5. 小さい単位で段階的に検証しているか
Copilot Studio のような生成AIを利用するエージェントは、設計どおりに作ったとしても、常に期待通りの回答が返ってくるとは限りません。生成AIは、決められた手順だけを実行するプログラムではなく、与えられた情報をもとに、都度、判断するような仕組みだからです。
したがって、一気に実装した後で「どこが上手く行っていないのか」を探っていくのではなく、段階的にテストしながら安定的な回答が戻ってくるのかを検証しながら実装を進める考え方の方が適しているように感じています。
一度にナレッジを大量に登録し、長い指示文を書き、Power Automate や AI Builder を組み合わせ、さらにマルチエージェントまで取り入れた状態では、期待した結果が得られなかったときに、エージェントの何が回答に影響を与えているのか等、原因を特定することが難しくなります。
やはり、人間へ仕事を依頼するのと似通っています。仕事内容を変更し、担当者を変更し、参考資料を変更し、作業手順まで変更した状態では、何が結果に影響したのかを判断することはできません。
例えば、ナレッジを１つ追加したらテストし、指示を修正したら確認し、新しいツールを追加したらその出力を確認する…といったように、変化を小さくすれば、その変化による影響も観察しやすくなります。
生成AIは、人間に近い柔軟性を持つ一方で、従来のソフトウェアとは異なる性質も持っているように見えます。当記事のような「ツールの特色」を受け入れた上で、小さく作り、小さく検証しながら微調整を積み重ねることが、実装完了までの近道になるのではないかと考えています。
末端ユーザーの私信で恐れ入りますが、Microsoft さんにお願いしたいのは、以上の背景があるため、GitHub Copilot harness の検証にかかる Copilot Credits は０、あるいは、運用時よりも安価に設定してもらえると安心して使えるユーザーの存在も多いのではないでしょうか。
１つ変化を加えたら、１つテストして確認しながら実装する
6. Copilot Studio を活用しようと考えている人へ
これから Copilot Studio を導入しようと考えている企業や担当者の方にとっては、エージェントをどのように作るかという話よりも、もう少し手前に考えておくべきことがあります。余談かもしれませんが、お時間ございましたら、ご一読いただけますと幸いです。
ご想像いただきたいのですが、社内の問い合わせ対応を効率化するためのエージェントを作りたいと仮定したとき、そのエージェントにおける回答の根拠（情報）はどこに保存されているのでしょうか。
しっかりと手順書やFAQとして整理されているのか、それとも、現場の担当者や熟練者の頭の中にあるのか…といったことをお考えいただきたいと思います。
情報は存在していても、内容が古かったり、ファイルごとに異なる説明が書かれていたりするのではないでしょうか。画像が多用されており、生成AIが理解しにくい形式になっているかもしれません。
生成AIは、組織に蓄積された知識を活用するための有力な手段ですが、組織として保有していない情報を正確に取り出すことはできません。現場の経験や判断基準が個人の中にとどまっているのであれば、Copilot Studio よりも前に、それをどのように記録し、共有し、更新していくのかという仕組みを作ることが必要です。
これは、一時期流行した「データ活用」の相談にもよく似ています。「Power BI を使ってデータ活用したい」というご要望があっても、実際には情報が個別のファイルに散在していたり、データ分析に適さない形式のデータであったり、分析に必要な項目が記録されていなかったりすることがあります。
その場合、分析ツールを導入することだけでなく、何を、誰が、どのような形で記録するのかを考えるところから始めなければなりませんでした。
Copilot Studio についても、最初からエージェントを開発することが最適であるとは限りません。既存の Microsoft 365 Copilot や検索機能、SharePoint Online などを利用して知識を共有するだけで、目的を満たせる場合もあります。
その一方で、独自の会話設計や業務システムとの連携、アクションの実行などが必要であれば、Copilot Studio を選択する理由が明確になります。
もちろん、すべての情報を整備してからでなければ、生成AIを使ってはいけないということではありません。小さな範囲でエージェントを試作し、実際にどのような情報が不足しているのか、どの業務を改善できそうなのかを確認することも、十分に意味のある進め方です。
大切なのは、エージェントを作ることを目的にするのではなく、解決したい業務上の課題を明らかにし、そのために必要な情報や仕組みを考えることではないでしょうか。Copilot Studio は、その選択肢の一つとして位置付けるのが自然だと思います。
時代の流れだから…と、雷同して生成AIを活用しようと考えていませんか？
IT 業界ではない話ですが、昨今のクマ問題に取り組んでいる方々に対する取材で興味深いコラムがあったので部分抜粋いたしました（2024年の雑誌です）
結
生成AIの能力は、今後も向上し続けると予想されます。陰謀論めいて聞こえるかもしれませんが、電力や水資源、半導体といったハードウェア側の制約が緩和されれば、その進化は現在よりもさらに加速する可能性があります。
より高性能なAIモデルを利用することで、期待する成果へ近付く場面も増えていくでしょう。ただ、その一方で、モデルの変更は、最初に検討すべきことではないと筆者は考えています。
高性能なAIモデルを利用すれば、その分だけ利用コストも増える可能性があります。そのため、本稿で紹介したように、①業務設計、②ナレッジ整理、③指示文の見直し、④AIに判断させる範囲を適切に定めた上で、必要に応じて Power Apps や Power Automate、AI Builder などへ役割を分担するだけでも、多くの課題を改善できるはずです。
画像生成のような一部の用途を除けば「高性能なモデルでなければ実現できない」という場面は、以前ほど多くなくなってきたようにも感じています。
これらを十分に検討した上で、それでもなお期待する成果へ届かないのであれば、高性能なAIモデルを選択する価値があると考えています。
生成AIの性能競争は、これからも続いていきます。しかし、一般の利用者がモデルごとの違いやベンチマークを細かく追い続ける必要は次第に失われていくことでしょう。
期待した成果が得られなかったけれど、また試してみよう。—— といった程度の距離感で、気付けば以前より良い結果が返って来ていた…。それくらい自然に性能向上の恩恵を受けられることこそ、生成AIが社会へ浸透した姿なのかもしれません。
一方で（既に多くの人々が発信されていますが）AI へ任せる仕事を設計する役割は人間に残り続けます。モデルの性能が高くなるほど、AIに任せられる仕事の範囲は広がるのも事実です。しかし、それは設計の重要性が小さくなることを意味するわけではありません。
こういった最新情報を追いかけたり振り回されたりすることよりも「人間が何を設計し、何をAIへ委ねるのか」を慎重に見極めることが、エージェント全体の品質を左右する時代になっていくのではないでしょうか。
少なくとも、筆者は、そのような未来を思い描いています。
当記事では、一部、Copilot Studio や Microsoft 365 の料金体系に触れる箇所がありましたが、こちらは記事公開時点での情報である点にご注意ください。詳細は、必ず公式情報をご参照ください。
参考文献
- Microsoft Learn - Microsoft Copilot Studio
- Microsoft Learn - Choose a harness in Microsoft Copilot Studio
- Microsoft Learn - Agents powered by the GitHub Copilot harness overview
- White paper: Choosing between the GitHub Copilot and Standard harnesses in Copilot Studio
- GitHub Copilotハーネスを活用したエージェントおよびワークフローの請求概要
- ナレッジ ソースとして公開 Web サイトを追加する
- Copilot Studio でマルチエージェントがサポートされたので試してみた
- 新しい Copilot Studio が GA したので「ハーネス」とクレジット課金体系を改めて整理してみる
- 生成 AI 時代の人材像と、その評価について考えてみる