2026年8月13日

エンタープライズエージェントの構築 vs 購入 vs 組み立て — コスト・スピード・ガバナンスのトレードオフ

企業のAI議論は、まだ始まり方がずれていることが多いです。問うべきは「どのモデルが一番強いか」ではありません。本番でエージェントを誰が所有し、どう運用し、どう統治するかです。

その選択は、だいたい次の3つの道に分かれます。

1. 構築（Build） — モデル、オーケストレーション、コネクタ、評価、可観測性、セキュリティまで自前で設計する
2. 購入（Buy） — ある種の業務をすでに知っているパッケージ型エージェントやチャットボットを導入する
3. 組み立て（Assemble） — プラットフォーム上でカスタムエージェントを組む。自社ナレッジ、自社ツール、自社ポリシー、自社ワークフロー

3つとも成功し得ます。失敗する理由が違います。コスト、スピード、ガバナンスは同じ方向に動きません。1つの点数で比べると、デモのあとにパイロットが止まります。

3つの道を、現場の言葉で

構築

構築とは、エージェントのランタイムを自社で持つことです。モデルを選び、ツールを書き、IDをつなぎ、トレースを保存し、APIが変わるたびにシステムを生かし続けます。

得られるのは最大の制御です。独自ロジック、プライベート基盤、独自の評価、ベンダーの製品ロードマップに縛られない自由度。

同時に、社内プロダクトの運用コストもすべて引き受けます。モデル利用料は安い行です。高くつくのはエンジニア、レビュー、障害対応、コネクタ保守、ポリシー作業です。

構築が正当化されるのは、エージェントそのものがプロダクトであるとき、あるいはワークフローが独特すぎて、プラットフォームが毎ステップで抵抗する場合です。

購入

購入とは、既知の仕事向けに完成したエージェントをベンダーから入れることです。ITヘルプデスクの一次回答、契約条項の抽出、CRMコパイロット、議事録ボット。

最初のデモまでの時間は優秀です。何ヶ月も議論していた製品判断を、ベンダーがすでに済ませています。

トレードオフは適合です。パッケージ型エージェントは、誰かのプロセスを埋め込んでいます。カテゴリに業務が合うときは強く、承認、システム・オブ・レコード、例外経路が自社固有のときは弱くなります。そして、たいてい固有です。

購入が正当化されるのは、独自性が強みではなく負債になるコモディティ業務です。

組み立て

組み立ては、そのあいだにあります。エージェント基盤を自前で書く必要はありません。自社プロセスを見られないブラックボックスのボットを受け入れる必要もありません。

プラットフォームがすでに持つ部品から、エージェントを組みます。

• 既存の権限付きの社内ナレッジ
• チャット、メール、ドキュメント、システム・オブ・レコードへのコネクタ
• ポリシー、承認、監査証跡
• 一度答えて終わりではなく、工程をまたいで進むワークフロー

プラットフォームの仕事は、差別化にならない重い部分です。ID、モデルルーティング、ツール実行、ログ、評価のフック、管理機能。現場の仕事は、成果、例外、エージェントが必要とするナレッジを定義することです。

それが、企業がAgentic Workflowに実際に必要とする道です。現場の動きに合うカスタムさ、セキュリティレビューを通るガバナンス、スポンサーが異動する前に本番へ届く速さ。

コストはライセンスではなく、総保有コスト

安いパイロットが、高い運用モデルになることがあります。

構築の高い失敗は、研究室を出ない基盤です。成果を出す代わりに、足場を保守し続ける優秀な人たち。

購入の高い失敗は、もうひとつのOSです。従業員は答えをSlack、Excel、本番システムへまだコピーします。助言に払い、仕事を終わらせる人にも払います。

組み立ての高い失敗は、プラットフォームをチャットの上張りとして使うことです。何もつなぎ、何も統治せず、チャット回数だけ測る。組み立てが回収されるのは、エージェントが完了した成果を目指すときだけです。

有効なコストの問いは「初年度のソフトウェアはいくらか」ではありません。プロセスが変わるたびに、誰が出勤しなければならないかです。

スピードは、信頼された本番ワークフローまでの時間

デモはスピードではありません。スピードは、現場のオーナーが本物の仕事をエージェントに任せるまでの経過時間です。

購入はデモまでが最速です。パッケージの流れが自社に合うなら、本番までも最速になり得ます。合わなければ逆転します。回避策、項目マッピング、「うちの例外経路をボットが知らない」が何ヶ月も続きます。

構築は最初の本番までが最も遅いです。強いチームでもそうです。企業ではID、ツールのサンドボックス、プロンプト/バージョン管理、評価、監査は任意ではありません。それを飛ばすチームは速く出し、セキュリティが来た瞬間に凍結します。

組み立ては、信頼されたワークフローまでが多くの場合いちばん速いです。ソフトウェアが魔法だからではありません。セキュリティが聞く部品がすでにプラットフォームにあり、最初の単位を「基盤プログラム」ではなく「ひとつのプロセス」にできるからです。

実務的なスピードテスト：

1. 業務オーナーは「完了」を一文で言えるか
2. その経路がすでに必要とするナレッジとツールを、エージェントは使えるか
3. もともと承認が必要な工程を、人が承認できるか
4. エージェントが何にアクセスし、何を提案し、何をしたかを見られるか
5. 来月、作り直しなしでワークフローを変えられるか

(1) がイエスで、(2)〜(4) に四半期かかるなら、思っている以上に構築しています。(5) がベンダーのロードマップ待ちなら、思っている以上にロックインを買っています。

ガバナンスは、パイロットのあとの工程ではない

企業は、モデルが弱いからエージェントを拒むのではありません。次に答えられないから止めます。

• エージェントは誰のIDで動いたのか
• どのデータを見たか
• どのポリシーが適用されたか
• 外部送信、チケット完了、レコード更新を誰が承認したか
• 先週火曜の実行を再現できるか

構築は、人員を置けば最も高いガバナンス水準に達し得ます。権限、データ境界、レッドチーム、保管、人のチェックポイントは、設計すべきプロダクトです。アーキ図では統治されて見え、トレースでは漏れている社内スタックは少なくありません。

購入はベンダーの制御を引き継ぎます。それは利点になり得ます。SOCレポート、管理画面、保管設定が初日に来る。天井にもなり得ます。法務が求める承認を足せない、ポリシーが求めるリージョンにデータを置けない、起動したユーザーより広く読めてしまう。

組み立てでは、ガバナンスをランタイムのデフォルトにすべきです。後付けのプロジェクトではありません。

• 権限はユーザーとドキュメントと一緒に移動する
• ポリシーはプロンプトだけでなくツールを制約する
• 承認は、チームがすでに使う同じ経路に乗る
• トレースは、専用パイプラインなしでセキュリティが見られる

アクセス制御を継承できないプラットフォームは、組み立ての道ではありません。チャット窓の付いた、並行ナレッジベースです。

ガバナンスはスピードにも効きます。先送りするチームは速くなりません。凍結日を貯めます。監査可能性を足すいちばん安いタイミングは、全社展開の前です。

3つのトレードオフを1枚に

万能の勝者はありません。仕事を完了しなければならないエンタープライズエージェントの既定値はあります。まず組み立て、コモディティの端は購入、エージェントが戦略的な差別化であるところだけ構築。

どの道を選ぶか

構築を選ぶとき

• エージェントそのものがプロダクト、または顧客が対価を払う中核能力である
• ID、評価、可観測性、オンコールを備えた社内AI基盤がすでに回っている
• 製品プラットフォームでは出せない低レベル制御がワークフローに必要
• 試作中だけでなく、初回リリースのあともチームを維持できる

「エンジニアがいるから」で構築を選ばないでください。エンジニアは希少資源です。差別化にならないオーケストレーションに使うと、エージェント計画は止まります。

購入を選ぶとき

• 仕事が標準的：FAQ一次回答、議事録、汎用のCRM下書き
• ベンダーに合わせることが利点になる（共有されたベストプラクティス）
• 今四半期に結果が必要で、そのワークフローは独自性の源泉ではない
• ベンダーがエッジケースを外しても、切り替えコストが許容できる

自社を特徴づけるプロセス——オンボーディング、請求、審査、顧客例外、社内承認——に購入を選ばないでください。そこには、自社が持つべき判断が埋まっています。

組み立てを選ぶとき

• ベンダーのテンプレートより、現場のほうが仕事を理解している
• ナレッジは散在し、権限はすでにDrive、チャット、システム・オブ・レコードにある
• 成果がツールと人をまたぐ：トリアージ、準備、経路、承認、通知、記録
• セキュリティには監査可能性が必要だが、2年の基盤構築は待てない
• 変更のたびに専任AIエンジニアチームを置かず、カスタムエージェントが欲しい

それが、いま企業の「AI変革」と呼ばれている仕事の大半です。チャットボットではありません。ナレッジ、ツール、ポリシーから組み立てる Agentic Workflow です。

過剰な精密さを避ける判断手順

40行の採点表は飛ばしてください。この順で進みます。

1. 成果を名付ける — 「経理AI」ではなく、「承認に回せる請求例外パケット」
2. コモディティか聞く — イエスなら購入し、一次回答率を測る。ノーなら汎用ボットを買って祈らない
3. エージェントが事業そのものか聞く — イエスなら構築。ノーなら基盤から始めない
4. 最小の組み立てを描く — ナレッジ源、コラボレーション面は一つ、システム・オブ・レコードは一つ、すでに存在する人のチェックポイント
5. 変更ループの値段を付ける — 来年、ポリシー、システム、ハッピーパスはどれくらい変わるか。変更が多ければ購入より組み立て、カスタムランタイムよりプラットフォーム
6. 最初のワークフローにガバナンスを載せる — ID、権限、トレース、承認。これができない道は、デモが良くても本番準備ができていません

それからワークフローを一つ出す。信頼されてから広げる。道を混ぜるのは普通です。議事録は購入、オンボーディングエージェントは組み立て、独自の価格判断は構築。ルールなく混ぜると、スタックは3つ、オーナーはゼロになります。

WellSkate AIの考え方

WellSkate AIは、組み立ての道のために作られています。意図的にです。仕事を最もよく理解している人が、その理解をカスタムAIエージェントとAgentic Workflowへ変えられるべきです。モデル基盤、コネクタ農場、ガバナンスプログラムをゼロから立てずに。

スローガンではありません。コスト、スピード、ガバナンスに対する、プロダクトの形です。

コスト：共有基盤の上で、現場がエージェントを持つ。 専門知識がなくても、現場がカスタムエージェントを作り、運用できます。プロセスが変わるたびに、専任のAIエンジニアや別途のインフラチームがクリティカルパスに乗る必要はありません。フロンティアモデルは単一のサブスクリプションの向こうにあり、モデルアクセスは調達プロジェクトになりません。払うのは、ID・実行・管理がすでに回っているプラットフォームであり、社内のエージェントOSではありません。

スピード：ナレッジの移し替えも、新しいAI画面への引っ越しもなく、信頼できるワークフローへ。 エージェントは、会社がすでに持つポリシー、ドキュメント、業務の文脈に根ざします。契約書、レポート、マニュアル、請求書、SOPは検索できるハブになり、クリーンルームのナレッジグラフを先に作る必要はありません。エージェントは Slack、Teams、メール、すでに使っているシステム・オブ・レコードに入り、従業員に並行するAI作業場所を求めません。最初に出す単位は Agentic Workflow ひとつです。部門とシステムをまたいで複数ステップを計画・調整・完了し、もともとある承認は人の手元に残します。

ガバナンス：後付けのプログラムではなく、ランタイム。 エージェントは、起動した人の権限を継承します。ポリシーは、どのデータにアクセスし、処理し、共有できるかを制約します。機微なコンテンツは、サードパーティのモデルに届く前にスキャンできます。監査証跡、エスカレーション、人の監督はワークフローと一緒に動きます。セキュリティレビューが、デモのあとにスタックを発明する必要はありません。

その組み合わせが、組み立てを構築より安く、購入より長く効かせます。誰かのプロセスを買っているのではありません。社内のエージェント基盤に資金を投じているのでもありません。すでに回っている業務のまわりに、本番エージェントを組み立てています。

前回のAI投資が、デモとライセンスと、同じ数の引き継ぎを残したなら、足りなかった判断はモデルではありません。運用の道です。

実際のプロセスのまわりに本番エージェントを組み立てたい方は、wellskate.ai または contact@wellskate.ai までご連絡ください。