AIエージェント、どう作ればみんなに使ってもらえる？ ― 実装の種類と「広めやすさ」の3つの観点

Posted at 2026-09-27

はじめに：「使ってもらえない」「作ってもらえない」

「どうしたら使ってもらえるか考えています」

先日、自社でエージェントを作って広める活動に積極的に取り組んでいる方と話しているときの呟きでした。単に生成AIを業務活用するというところから、「AIエージェント」に広がっています。一方で次のような悩みも聞こえてきます。

せっかくエージェントを作ったのに、周りが使ってくれない
「各自で業務に合ったエージェントを作ってほしい」と呼びかけても、誰も作らない
開発したものをプロジェクトの外に展開しようとしたら、環境の違いで動かなかった

使う側・作る側の双方に、興味がないわけではありません。むしろ「興味はあるけど、どう始めればいいのかわからない」という声が多いのではないでしょうか。

本記事では、AIエージェントの実装の入り口が複数あることを整理したうえで、それぞれを「広めやすさ」という観点で比較し、組織のスキルに合わせた選び方を考えます。

興味はあるけど、どう始めれば？

「AIエージェントを作ろうぜ」と言われて思い浮かべるものは、人によって大きく異なります。

業務部門の人：「Copilotに何か設定する？」
情シスの人：「Difyのようなツールを入れればいい？」
開発者：「LangChainやGoogle ADKでコードを書く？」

このことは入り口が1つではないことを示しています。そして、入り口によって「誰が作れるか」「誰に届けられるか」が大きく変わります。入り口の違いを意識しないまま始めると、「作れる人が限られる」「作ったものが届かない」というすれ違いが起きやすくなります。時により一つの入り口のみを見て「うちでは全然使われていない」と呟かれることもあります。

AIエージェント実装の入り口（例）

代表的な実装方法の例を、作り手に求められるスキルがおおむね低いものから順に並べると次のようになります。ここに挙げたのはあくまで例です。製品や技術の進化は速く、これ以外の入り口や、複数を組み合わせた形も今後さらに出てくるでしょう。

#	実装の種類	例	主な作り手
1	SaaSに組み込まれたAIエージェントを活用	業務SaaSに搭載されたエージェント機能	（作らない／設定のみ）
2	やりたいこと・参照情報を設定してエージェントを定義	Microsoft 365 Copilot の Agent Builder、ChatGPT の GPTs など	業務部門の担当者
3	ノーコード／ローコードの専用環境でエージェントを定義	Dify、Microsoft Copilot Studio など	市民開発者・情シス
4	完成済みのエージェント製品を導入して動かす	OpenClaw、NanoClaw、Hermes Agent など	ITツールの導入に慣れた担当者（多くはターミナル操作が必要）
5	開発ツールにSkillを定義	GitHub Copilot、Claude Code など	ITリテラシーの高い担当者・開発者
6	フレームワークを使ってコードでエージェントを書く	Google ADK、Strands Agents、LangChain など	開発者
7	エージェントのコードにUIをつけてコンテナで配布	コンテナイメージとして配布（Docker など）	開発者
8	開発したエージェントとUIをアプリケーションとして公開	社内Webアプリとして提供	開発者＋運用チーム

1. SaaSに組み込まれたAIエージェントの活用

すでに使っている業務SaaSにエージェント機能が組み込まれているケースです。追加の開発はほぼ不要で、ユーザーは普段のツールの中でそのまま使えます。反面、できることはSaaS側の提供範囲に限られます。

2. 設定型（Microsoft 365 Copilot の Agent Builder、ChatGPT の GPTs など）

「何をしたいか」「どの情報を参照するか」を画面上で設定してエージェントを定義します。プログラミング不要で、普段使っている Microsoft 365 や ChatGPT の中でそのまま作れ、そのまま使えるのが特徴です。

3. ノーコード／ローコードの専用環境（Dify、Copilot Studio など）

ワークフローやツール呼び出しをGUIで組み立てます。設定型より複雑な処理を組める一方、専用環境の操作を覚える必要があります。定義をファイル（DifyのDSLなど）としてエクスポートし、別の環境の同じ製品に持ち込めるもの（Difyなど）もあれば、特定のプラットフォームと密に統合されている製品（Copilot Studioなど）もあります。

4. エージェント製品の導入（OpenClaw、NanoClaw、Hermes Agent など）

すでに完成しているオープンソースのエージェント製品をインストールして動かす方法です。「作る」というより「選んで始める」に近く、SlackやDiscordなどのチャットアプリと連携させて日常のタスクを任せられます。Skill（拡張機能）の追加や、使うほど自分向けに育っていく設計を持つ製品もあります。製品の多くは、自分のPCで動かすにはDockerなどのセットアップやターミナル操作が必要です（デスクトップアプリを提供する製品もあります）。また、サーバー構築を肩代わりするマネージドサービスも登場しています。

なお、この種の製品はファイルやアカウント、チャットアプリなどへの広い権限をエージェントに渡して動かすことになります。OpenClawではセキュリティ上の懸念も指摘されており、NanoClawのようにエージェントをコンテナで分離して動かすことを特徴とする製品も登場しています。これはOpenClawに限らず、広い権限を持つこの種の製品全般に言えることです。組織で使う場合は、渡す権限の範囲やデータの扱いを事前に確認し、公開されているサードパーティ製のSkillを追加する際も中身を確認してから導入しましょう。

5. 開発ツールへのSkill定義（GitHub Copilot、Claude Code など）

手順や知識を、SKILL.md（Markdown）を中心としたフォルダ（必要に応じてスクリプトなども同梱）として「Skill」に定義し、AIコーディングツールに読み込ませる方法です。テキストを書き換えるだけで自分好みに調整でき、ファイルとして共有もしやすいのが特徴です。ただし、前提となる開発ツールを使いこなせる人に利用者が限られます。

6. フレームワークでコードを書く（Google ADK、Strands Agents、LangChain など）

エージェントの振る舞いをコードで細かく制御できます。自由度は最も高いですが、作るにも直すにも開発スキルが必要です。

7. UIをつけてコンテナで配布

6で作ったエージェントにUIをつけ、コンテナイメージとして配布します。実行環境ごと固めるため「自分の環境では動かない」を避けやすくなりますが、受け取る側にコンテナを動かす環境と知識が求められます。

8. アプリケーションとして公開

エージェントとUIをサーバー上で動かし、ユーザーにはブラウザなどからアクセスしてもらう形です。ユーザーは何もインストールせずに使えますが、提供側にはインフラ・認証・運用の負担がかかります。

入り口に優劣はない

番号が大きいほど高度に見えるかもしれませんが、入り口の間に優劣はありません。コードで書いたエージェントが、SaaS組み込みのエージェントより優れているとは限らないのです。大切なのは、目的・要件・制約を満たせる入り口を選ぶことです。

目的：誰に、何をしてほしいのか（個人の効率化か、部署の業務改善か、全社展開か）
要件：どのデータを参照し、どのシステムと連携し、どこまで自律的に動く必要があるか
制約：予算、スケジュール、社内のスキル、セキュリティやガバナンスのルール

要件を満たせるのであれば、最も手軽な入り口を選ぶのが合理的です。

コラム：入り口の分け方の考え方

入り口の分け方は、Microsoftのガイドや、それを解説した記事、難易度別に作り方を整理した記事（ロリポップ）などが参考になります。

まず「使えるものがないか」：既製のSaaSエージェントで要件を満たせるなら、それを採用し、満たせないときに構築する（Cloud Adoption Framework）
誰が実行環境を持つか：SaaS（Copilot Studio）、PaaS（Microsoft Foundry）、IaaS（GPU・コンテナ）に分かれる（同上）
作り方の段階：作らない → ノーコード → ローコード → プロコードと進むほど、制御できる範囲も必要な技術投資も増える（Agent Academy）
誰が作り、誰が所有・運用するか：複雑さだけで選ぶべきではなく、作り手の種類・所有モデル・運用管理の要件のほうが、製品選びに大きく影響することが多い（Microsoft Tech Community）

共通する原則は「目的を果たせる最も手軽な段階から始め、壁に当たったら上がる」ことです（A Guide to Cloud & AI）。ただし、段階を上がると設定がそのまま引き継げるとは限りません。例えばCopilot StudioからMicrosoft Foundryのようなプロコード環境への移行は、実質的に作り直しになる点に注意が必要です（同上）。

「広めやすさ」の3つの観点

ここで、エージェントが組織に広がるかどうかを左右する「広めやすさ」を、次の3つの観点で定義します。

観点	意味	問いかけ
使用性	学習負荷が低く、始める敷居が低いか	初めての人がすぐ使い始められるか？
カスタマイズ性	利用者が自分なりに使いやすいものにしやすいか	自分の業務に合わせて手を入れられるか？
可搬性	異なる環境でも同じエージェントを使ってもらえるか	別の部署・別のPCでも同じように使えるか？

※ 本記事の観点は、ソフトウェア製品の品質モデルの規格 ISO/IEC 25010:2023（JIS X 25010:2025）を参考にしつつ、「組織への広めやすさ」という目的に合わせて独自に定義したものです。使用性は主に同規格の「インタラクション容易性（対話性）（Interaction capability）」のうち「習得性（Learnability）」、カスタマイズ性は「保守性（Maintainability）」の「修正性（Modifiability）」を利用者側から捉えたもの、可搬性は「柔軟性（Flexibility）」の「適応性（Adaptability）」「設置性（Installability）」に相当します。なお、「インタラクション容易性（対話性）」「柔軟性」は2023年版での名称で、2011年版（JIS X 25010:2013）ではそれぞれ「使用性」「移植性」と呼ばれていました。

3つの観点は相反しやすい

重要なのは、この3つがトレードオフの関係になりやすいことです。

使用性を上げると、裏側の仕組みを隠すことになり、利用者が手を入れられる余地（カスタマイズ性）は減りがちです。また、特定のプラットフォームに寄せるほど簡単になる一方、その外には持ち出しにくくなります（可搬性が下がる）。
カスタマイズ性を上げると、利用者ごとにエージェントが変化していき、「同じエージェント」を配ること（可搬性）が難しくなります。自由度の高さは学習負荷（使用性の低下）にもつながります。
可搬性を上げると、環境差を吸収するためにコンテナ化やアプリ化が必要になり、中身を利用者が触る余地（カスタマイズ性）は小さくなります。

つまり、3つすべてを高い水準で満たす万能な実装方法はありません。8のように使用性と可搬性を両立できる入り口もありますが、それはカスタマイズ性を犠牲にし、インフラや運用のコストを提供側が引き受けることで成り立っています。目的に応じて、どの観点を重視するかを先に決める必要があります。

実装の種類 × 広めやすさ

入り口の例を3つの観点で評価すると、おおよそ次のようになります（◎：強い、○：まずまず、△：弱い）。評価は、エージェントを受け取って使う人（自分で作って使う入り口では作り手自身）から見たものです。

実装の種類	使用性	カスタマイズ性	可搬性
1. SaaS組み込みエージェント	◎	△	△
2. 設定型（M365 Copilot Agent Builder、GPTs など）	◎	○	△
3. ノーコード／ローコード（Dify、Copilot Studio など）	○	○	○
4. エージェント製品（OpenClaw など）	○	○	△
5. Skill定義（GitHub Copilot、Claude Code など）	△	◎	○
6. フレームワークでコード記述	△	◎	○
7. UI付きコンテナで配布	△〜○	△	◎
8. アプリケーションとして公開	◎	△	◎

※ 製品やバージョン、組織の環境によって評価は変わります。あくまで傾向として捉えてください。
※ エージェント製品は、製品自体は多くの環境にインストールできます。ただ、Skillや記憶が利用者ごとに育っていくため、「同じエージェント」を組織に配るという意味での可搬性は△としています。マネージドサービスを使えば、使用性はさらに上がります。
※ ノーコード／ローコードの可搬性は製品によって差があります。定義をエクスポートできるDifyなどは○、Microsoft 365 などのプラットフォームと密に統合されたCopilot Studioは△寄りです。
※ UI付きコンテナの使用性は、受け取る側にコンテナの実行環境が用意されていれば○、なければ△です。

表から、おおむね次の3つのグループが見えてきます。

「すぐ使える」グループ（1・2）：使用性が高く、既存ツールの延長で始められる。ただし、そのプラットフォームの外には持ち出しにくい。
「自分で育てる」グループ（4・5・6）：カスタマイズ性が高く、自分の業務に合わせて育てられる。ただし、使える人が限られたり、利用者ごとに中身がばらばらになったりしやすい。
「同じものを届ける」グループ（7・8）：可搬性が高く、全員に同じ品質のエージェントを配れる。ただし、利用者が手を入れる余地は小さい。

3（ノーコード／ローコード）は各観点のバランスが比較的よく（製品による差はあります）、作り手を増やす段階の足がかりとして選ばれやすい位置にあります。

繰り返しになりますが、◎の数が多い入り口ほど優れているわけではありません。自分たちの目的・要件・制約にとって重要な観点で◎が付いているかが、選ぶときの判断基準です。

組織のスキルによって選ぶ

どの観点を重視すべきかは、「誰に広めたいか」と「組織にどんなスキルがあるか」で決まります。

組織の状況	重視する観点	向いている入り口
ITに詳しい人が少なく、まずは触ってもらいたい	使用性	1. SaaS組み込み、2. 設定型
市民開発者や情シスがいて、部署ごとに工夫させたい	使用性＋カスタマイズ性	2. 設定型、3. ノーコード／ローコード
個人や小さなチームで、自分たち専用のアシスタントを手早く持ちたい	使用性＋カスタマイズ性	4. エージェント製品
開発者やITリテラシーの高いメンバーが多く、各自の業務に最適化したい	カスタマイズ性	5. Skill定義、6. フレームワーク
開発チームがあり、全社に同じエージェントを展開したい	可搬性＋使用性	7. コンテナ配布、8. アプリ公開

段階的に広げるという考え方

最初から1つに決め打ちする必要はありません。例えば次のような段階的な進め方も考えられます。

まず体験してもらう：SaaS組み込みや設定型で「エージェントってこういうものか」を知ってもらう（使用性重視）
作り手を増やす：ノーコード／ローコード（ITリテラシーの高いメンバーならSkill定義も）で、業務を知っている人自身に工夫してもらう（カスタマイズ性重視）
良いものを全体に届ける：現場で育って効果が確認できたエージェントを、開発チームがコード化・アプリ化して展開する（可搬性重視）

現場で生まれたアイデアを、組織全体で使える形に「昇格」させていく流れを作れると、使う人と作る人の両方が増えていきます。

まとめ

AIエージェントの実装には、SaaS組み込みからアプリ公開まで複数の入り口があり、本記事の8つは一例にすぎない
入り口に優劣はなく、目的・要件・制約を満たせるものを選ぶ
広めやすさは使用性・カスタマイズ性・可搬性の3つの観点で考えられる
3つの観点は互いに相反しやすく、すべてを同時に高い水準で満たすのは難しい
目的（誰に・何を届けたいか）と組織のスキルに応じて、重視する観点と入り口を選ぶ
1つに決め打ちせず、体験 → 作り手を増やす → 全体展開と段階的に広げる道もある

「なぜ使ってもらえないのか」「なぜ作ってもらえないのか」に悩んだときは、今選んでいる入り口が、重視すべき観点と合っているかを見直してみてください。

最後に、広めるためには、作ったエージェントを見つけやすくする社内カタログやレジストリ、社内で紹介する機会など、「知ってもらう仕組み」も必要です。この点もいつか別の記事でまとめたいと思います。

参考

※ 記載の会社名・製品名は、各社の商標または登録商標です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up