AIエージェントは「自作するもの」から
「買って育てるもの」へ変わっていく

同じように取り組んでも、同じ結果が出るとは限らない

私はこれまで、AIエージェントの構築方法や活用方法を、周囲の人にも伝えてきました。

ただ、正直に言えば、同じ情報を渡したからといって、誰もが同じところまで到達できるとは思っていません。

能力の問題ではありません。一番大きいのは、使える時間と集中度の違いです。

私はこの2か月、他の仕事をできる限り減らし、AIエージェント構築にほぼ全振りしました。一方で、普通の経営者や会社員は、 本業を抱えています。日々の売上管理、顧客対応、スタッフとの打ち合わせ、仕入れ、広告、経理、トラブル対応。 その合間にAIを学ぶことになります。

毎日30分や1時間勉強するだけでも立派ですが、それで、短期間に複数のエージェントを構築し、実際の会社で動かし、 組織化するところまで進むのは簡単ではありません。

AIによってプログラムを作ること自体は、以前より圧倒的に簡単になりました。しかし、

会社の仕事をAIが実際に担える状態にすることは、まだ別の難しさがある

難しいのは、エージェントを作ることではない

たとえば、AIに「在庫管理担当エージェントを作ってください」と頼めば、それらしい役割定義はすぐに作れます。 しかし、実務で必要なのはその先です。

• どのデータを正しいものとして扱うのか
• 在庫不足をどの時点で検知するのか
• 季節による売上変動をどう見るのか
• 発注数量を誰が最終決定するのか
• 誤発注をどう防ぐのか
• どの金額以上は人間の承認を必要とするのか
• エラーが起きた場合にどう停止するのか
• 判断の根拠をどのように記録するのか

こうしたルールを決めなければ、仕事としては使えません。

AIエージェントは、役割を与えただけでは社員にはなりません。会社の方針、仕事の進め方、判断基準、権限、責任範囲、 報告方法まで教える必要があります。この設計と育成に、最も時間がかかります。

MDファイルは流用できる

AIエージェントを構築するとき、役割やルール、知識をMDファイルに記述することがあります。たとえば、次のような内容です。

• エージェントの役割
• 仕事の目的
• 判断基準
• 報告フォーマット
• 承認が必要な操作
• 禁止事項
• 他のエージェントとの連携方法
• エラー発生時の対応
• ログの残し方
• セキュリティ上の注意

こうした内容の多くは、他社でも流用できます。経理担当、カスタマーサポート担当、広告担当、情シス担当など、 業種が違っても共通する役割は多くあります。

もちろん、細かな業務内容は会社ごとに異なります。使っているシステムも違いますし、商品も顧客も社内ルールも違います。 それでも、エージェントの基本構造や考え方、仕事の進め方は、かなり共通化できます。

このことを考えると、今後は各社がゼロからMDファイルを書くよりも、すでに整備されたものを導入し、 自社向けに修正する方が合理的です。

ただし、MDファイルだけでは商品にならない

一方で、MDファイルはコピーできます。そのため、MDファイルそのものの価値は、いずれ下がっていく可能性があります。

本当に価値があるのは、ファイルの中身だけではありません。その内容が出来上がるまでに蓄積された運用知識です。

• どの指示では動かなかったのか
• どこで誤判断が起きたのか
• どの作業には人間の確認が必要だったのか
• どこまで自動化すると危険なのか
• エージェントの役割をどの単位で分けるべきか
• どのようなログが後から必要になるのか
• 失敗したときに、どのルールを直すべきなのか

こうした知識は、実際にエージェントを動かさなければ得られません。

たとえば、「経理担当エージェント」というMDファイルだけなら、簡単に作れます。しかし実際の仕事では、

1. 各サービスから明細を取得する
2. PDFやCSVを読み取る
3. 仕訳候補を作る
4. 過去の仕訳と照合する
5. 不明なものだけ人間に確認する
6. 会計ソフト用のデータを出力する
7. 処理結果と判断根拠を記録する

という一連の仕組みが必要です。ここには、MDファイル以外にも、プログラム、データ連携、権限管理、承認フロー、 エラー処理、監査ログが必要になります。

したがって、将来売られるものは、単なるエージェント設定ファイルではないはずです。

将来は3つの商品形態に分かれる

AIエージェント関連の商品は、今後、大きく3つに分かれていくと考えています。

エージェントの購入は「中途社員の採用」に近い

AIエージェントを買うと聞くと、完成品の社員が届き、翌日から何でも完璧にこなしてくれるイメージを持つかもしれません。 しかし、実際にはそうならないと思います。

AIエージェントの導入は、

基本的な教育を受けた中途社員を採用し、自社の仕事を教えることに近い

ものです。たとえば、カスタマーサポート担当エージェントであれば、

• 丁寧な回答方法
• 問い合わせの分類方法
• クレーム対応の基本
• 返金や交換の一般的な考え方
• 上司へ確認する条件
• 対応履歴の残し方

などは共通化できます。しかし、

• どの状態の商品を不良と判断するか
• どの程度まで交換対応するか
• 顧客へどのような言葉を使うか
• 会社として何を大切にするか
• どのような顧客体験を提供したいか

は、会社ごとに違います。つまり、購入できるのは完成された社員ではなく、基礎能力を持った社員です。 導入後に、自社の価値観や業務を教え、実務を通して育てなければなりません。

共通部分は買い、固有部分だけを育てる

今後、多くの企業は、AIエージェントを一から作るのではなく、共通部分を外部から購入するようになると思います。

経理、広告、カスタマーサポート、在庫管理、情報システムなどには、業種を超えた共通部分があります。 その共通部分まで、各社が毎回ゼロから考える必要はありません。すでに実務で検証されたエージェントを導入し、 自社特有の部分だけを追加する方が効率的です。

この流れは、ウェブサイト制作に少し似ています。以前は、ウェブサイトを作るために、すべてをゼロから開発する必要が ありました。しかし現在は、WordPressやShopify、各種テンプレートを利用し、その上に自社独自のデザインや 商品情報を載せます。AIエージェントも同じように、

共通の基盤は既製品を使い、差別化部分だけを自社で作る

方向に進むはずです。

本当の商品は「エージェント」ではなく「育成方法」

AIエージェントを構築していると、MDファイルやプログラムそのものに価値があるように感じます。 しかし、本当に価値があるのは別のところにあります。

• どの順番で導入するのか
• 最初に何を任せるのか
• どこまで権限を渡すのか
• いつ自動化へ移行するのか
• どの作業に人間の確認を残すのか
• エージェントを増やすべきか
• 既存エージェントの役割を広げるべきか
• 失敗した場合に何を見直すのか

こうした判断こそが、エージェント組織を作るうえで最も重要です。

たとえるなら、MDファイルは苗木です。苗木は誰でも買えます。しかし、

• どこを剪定するか
• いつ植え替えるか
• どの枝を残すか
• どの樹形を目指すか
• どれだけ水を与えるか

によって、育ち方は大きく変わります。AIエージェントも同じです。完成品を買うというよりも、 育つ素体を買い、会社の中で育てていくものです。

AIエージェント組織は、これから一つの商品になる

将来、企業が購入するのは、単体のエージェントだけではないと思います。たとえば、

EC事業者向けAIエージェント組織スターターキット

のような商品が考えられます。内容は次のようなものです。

• 標準的なAIエージェント組織
• 各担当者の役割定義
• 共通知識ファイルのひな型
• VPSやデータベースを含む実行環境
• 各種システムとの接続機能
• 権限管理と監査ログ
• 承認フロー
• 導入手順
• 育成カリキュラム
• 定期的な改善と監査

つまり、販売するのは「AI社員10人」ではありません。販売するのは、

AI社員を採用し、教育し、管理し、働かせるための会社の仕組み

です。