他人が実際に使ってこそ、エージェントも製品になる

AIを使う人と製品をつくる人

AIに頼んでウェブサイトを作ったり、必要な情報を探したり、文書を整理したりすることは珍しくなくなりました。ですが、自分が作ったエージェントやスキルを他人に渡し、その人が実際の業務で使い続けるようにする人はまだ少ないです。私はこの違いに注目したいと思います。

ジョシュア・ミラーはWIREDのインタビューで、テック業界の外ではエージェントを使っているという話をほとんど聞かないと語りました。彼が強調したのは、消費者が求める製品を作らなければならないという点でした。

私はミラーの問題提起をこう受け止めました。誰かが実際に使うまでは、技術が動作するというだけで製品を作ったとは言いにくいのです。 AIで何かを作りやすくなった分、作った後に誰が使うのかまで見なければならないという意味です。

自分が使っていたスキルを同僚に渡すと

ここでいうエージェントとは、AIが必要なツールを使いながら複数段階の作業を行う方式のことです。スキルは、AIが特定の業務を行う際に参照する手順や資料をまとめたものです。対話画面上でもエージェントを使うことができます。画面の見た目よりも重要な違いは、自分が望む結果を得ることにとどまるのか、他人もその機能を使えるようにするのかという点にあります。

会議録から週次報告書を作成するスキルを作ったとしましょう。自分が使うときはかなりうまくいきます。どの会議録を入れればよいか分かっていますし、チームで使う略語も理解していますし、結果がおかしければ指示を直せばよいからです。抜けている内容は自分で埋めればいいですし。

そのスキルを同僚に渡すと、それまで自分が特に意識せず処理していた部分が露呈します。同僚はどのファイルを入れればいいのかすら分からないかもしれません。別の形式の会議録を入れたら、報告書に必要な項目が抜け落ちることもあります。そのたびに作った人に使い方を尋ねなければならないなら、来週もこのスキルを使う理由は減っていきます。

同僚が使い続けるようにするには、入力する資料と実行方法がはっきりしている必要があります。どんな結果が出るのか事前に分かるべきですし、情報が足りないときはその旨を知らせるべきです。結果を修正したり、再実行したりする方法も必要です。作った本人がそばで説明しながらデモをするときには見過ごされがちな問題です。

AIが報告書を一度作ってくれたという事実だけでは、こうした条件を確認することはできません。他の人が自分の資料で使ってみて、次の業務でもまた使うかどうかまで見る必要があります。

ユーザーがすべきことを先に決める必要がある

「何でも代わりにやってくれるエージェント」という説明を聞くと、ユーザーはまず自分が何を任せられるのかから考えなければなりません。一方、「毎週会議録を入れると、私たちのチームの様式で週次報告書を作る」と説明すれば、いつ使う道具なのかが分かります。その仕事を頻繁に行う人に使用を提案することもできます。

ミラーが紹介したDiaの朝のブリーフィングも、この観点から見ることができます。ユーザーはカレンダーとメールから整理された今日のやるべきことを見ます。その裏にどんなエージェントがいるのかを知る必要はありません。

もちろん用途がはっきりしていても、実際の業務に合わなければ使われません。報告書の形式がチームのやり方と違ったり、毎回入力資料を準備するのに時間がかかったりすれば、使用が途絶えることもあります。そのため配布した後も、どこでつまずいているのかを見て直す必要があります。エージェントやスキルを開発する仕事には、この過程まで含まれるべきだと私は考えます。

ユーザーが多かったり有料でなければならないという意味ではありません。チームメンバー数人が毎週使う社内ツールや、他の人が自分の業務に持ち込んで使う無料のスキルも、実際のユーザーを持つ製品になり得ます。インストール数や公開したという事実だけでは分からない部分です。

Oswarldの視点

私はこれをGTM、つまり製品を顧客に知らせ、実際の使用につなげる戦略の問題として見ています。

GTM戦略を練る中で繰り返し出会った失敗パターンが一つあります。作る側が使う技術用語をそのまま顧客に差し出すことです。製品説明に社内の技術用語を使うと、顧客はその技術をまず理解しないと製品を選べなくなってしまいます。

「エージェントとスキルを開発した」という説明も同じです。開発した人にとっては、どんな機能を実装したかが大きな成果かもしれません。しかし顧客にとっては、自分の仕事の何を任せられて、使えば何が良くなるのかが先です。開発を終えた後も、ユーザーを定め、その人の業務に合わせ、使い続ける理由を作る仕事が残っています。

私が導入検討を手伝うときに入れる質問の一つに、**「このエージェントが間違っているとき、誰がいつ気づくのか？」**というものもあります。

この質問もまた、実際に使えるかどうかを確認するためのものです。結果を人が確認するとしても、全体の作業時間が減り、品質が良くなるのであれば使う理由があります。逆に、毎回エラーを直すのにかえって時間がかかるなら、ユーザーは元のやり方に戻ってしまうでしょう。確認にかかる時間まで含めて、どんな助けになるのかを見る必要があります。

そのため私は、エージェントの機能を説明するだけで導入が終わったとは考えません。実際に使う人に渡し、その人の業務で役立つかどうかを確認するところまで行く必要があります。AIと対話して自分が使う成果物を得る経験だけでは、この過程を代わりにすることはできません。

おわりに

AIのおかげで何かを作ってみられる人は増えました。その一部は、自分が繰り返し行う仕事をエージェントやスキルにします。ここから、他の人も使えるように仕上げ、実際の使用につなげる段階が残っています。

この文章で言う格差はその段階にあります。技術的に実装した機能があるかどうかと、誰かがその機能を必要として使うかどうかは、別々に確認する必要があります。私は後者までやり遂げることを、製品を作ることだと考えています。

💬 自分で作ったエージェントやスキルを他の人に渡してみたことはありますか。その人が使い続けたか、途中でやめてしまったならどこでつまずいたのか、教えてください。

---

📨 エージェントやスキルを作って他の人に提供しようとしている方がいたら、この記事を伝えてください。

---

参考資料と関連リンク

• Why Normal People Aren’t Using AI Agents — WIRED: ミラーの製品観点を説明したインタビューです。
• Building effective agents — Anthropic: エージェントの動作方式と、実際の業務に適用する際に考慮すべき点を説明しています。対話画面もエージェントの使い方の一つになり得ます。
• Agent Skills 公式ドキュメント: スキルに含まれる指示・資料・実行ファイルと、エージェントがこれらを使う方式を説明しています。

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。