エージェント基盤はLyzrか自社開発か｜自社クラウドに置く判断

「部署ごとにAIエージェントを作り始めたら、使っている基盤も記録の残し方もばらばらで、情シスが全体を把握できない」「顧客のデータを社外に出せないので、外のエージェント作成サービスは使えないと言われた」——エージェントの試行が2つ3つの部署に広がった会社で、情シスやAI推進の担当者から聞こえてくる声です。2つの声は、行き着く先が同じです。エージェントを動かす土台をどこに置き、誰が面倒を見るか、という問いです。そこで候補に挙がるのが、米国の Lyzr のように、自社のクラウドの中に置けて、安全の機能を基盤の側に組み込んだ企業向けのエージェント基盤です。ただし、基盤を自社のクラウドに置けば安全になる、という話ではありません。本当は、データの置き場所と安全の機能を基盤に寄せたぶん、その基盤を動かし、止め、やめる責任が自社に戻ってくる選択です。この記事では、クラウド型のエージェント作成サービス、Lyzr のような自社クラウドに置ける基盤、一からの自社開発の3つを、情シスが比べる観点で整理します。

Lyzr は、企業向けのAIエージェント基盤

Lyzr は、企業がAIエージェントを作り、本番で動かし、統制するための基盤です。公式サイトは「AIエージェントをより速く本番へ」を掲げ、作る・動かす・統制するまでを1つの製品群で扱うと説明しています。2026年10月時点の公式サイトに並ぶのは、エンジニア向けの作業台である Agent Studio、業務担当が会話しながらエージェントやアプリを組み立てる作成画面、全社員向けの統制された作業の助手、そして、どこで作られたエージェントでも一か所で動かし・見張り・統制する管理画面です。

管理画面の機能として挙がっているのは、安全の歯止め、評価、人の確認を挟む仕組み、版の管理、動きの観測です。使う言語モデルは、エージェントごとに OpenAI、Anthropic、Gemini、Bedrock、DeepSeek などへ振り分けられると説明されています。特定のモデルに縛られない作りは、基盤としての売り文句の1つです。モデルの提供元が入れ替わっても、エージェントの作りと統制の仕組みは基盤の側に残る、という考え方です。

対象の業種として公式サイトが挙げるのは、銀行、保険、行政、医療、金融サービス、通販などです。業務の領域では、営業、マーケ、カスタマーサクセス、人事、購買、法務が並びます。規制の厳しい業種を先に見ていることは、次に見る「自社のクラウドに置ける」「安全の機能を基盤に持たせる」という打ち出しと結びついています。データを社外に出しにくい業種ほど、置き場所と安全の機能が導入の条件になるからです。

作っている会社と、国内でまだ知られていない理由

Lyzr は米国の会社です。2025年10月には、アクセンチュアの投資部門がシリーズAに加わったと発表され、銀行・保険・金融サービスの顧客にエージェントを届けることを狙いに挙げていました。2026年3月9日には、ブルームバーグが、アクセンチュアが主導する調達で企業評価額が2億5,000万ドルになったと報じています。大手のコンサルティング会社が出資者に入っていることは、この製品が単体で売られるより、導入の支援と組になって大きな会社に入っていく形を示しています。

国内でまだほとんど知られていないのには、いくつか理由が考えられます。1つは売り方です。公式サイトは導入の際の手厚い支援を打ち出しており、試しに登録して使ってみる個人より、大きな会社の情報システム部門を相手にしています。もう1つは言語です。2026年10月時点で、公式サイトに日本語の画面や日本の拠点の記載は確かめられませんでした。紹介記事が日本語でほとんど出ていないのも、そのためでしょう。

そのため、日本の会社がすぐに国内向けに使える、とは言い切れません。ただ、この製品が立てている問い、つまり「エージェントの土台を自社のクラウドに置くか」「安全の機能を基盤の側に持たせるか」は、どの会社の情シスも近いうちに向き合うものです。この記事では、製品の紹介より、その比べ方を本題にします。Lyzr は、自社クラウドに置く形の代表として読み進めてください。

部署ごとに作り始めると、なぜ行き詰まるのか

エージェントの試行は、たいてい部署ごとに始まります。営業は商談の準備、人事は社内の問い合わせ、経理は請求の突き合わせ、と、それぞれが手近なサービスで作ります。最初の数本はこれで回りますが、10本を超えたあたりから、どのエージェントが、どのデータに、誰の資格で触っているのかを誰も答えられなくなります。

行き詰まる理由は3つあります。1つ目は記録の形がばらばらなことです。サービスごとに操作の記録の残し方が違い、何か起きたときに横断して追えません。2つ目は安全の歯止めの置き方がばらばらなことです。個人情報を伏せる処理を入れている部署と、入れていない部署が混在します。3つ目は、データを外に出してよいかの判断が、部署ごとに別々に下されていることです。

こうなると、情シスは後から全部を棚卸しすることになります。経理の照合のように1つの業務を手順書で任せる話は別の記事にゆずり、ここで問題にするのは、その手前にある「土台をそろえるかどうか」です。土台をそろえる判断は、エージェントが数本のうちにしておくほど安くつきます。本数が増えてからでは、移し替えの手間が判断を縛ります。

比べる3つの形：クラウド型サービス・自社クラウドの基盤・自社開発

土台の選び方は、大きく3つに分かれます。1つ目はクラウド型のエージェント作成サービスです。提供元のクラウドの上で作り、動かします。始めるのは最も速く、基盤の更新も提供元が行います。2つ目は Lyzr のように、自社のクラウドの中に置ける基盤です。製品の形で提供されますが、動く場所は自社のクラウドのアカウントの中です。3つ目は、公開されている部品や言語モデルの接続を組み合わせて、一から自社で開発する形です。

Lyzr の公式の資料では、アマゾンのエージェント実行基盤と組み合わせる構成について、エージェントは顧客自身の AWS のアカウントと仮想ネットワークの中で動き、Lyzr の共有の設備では動かない、と書かれています。作業台についても、自社の閉じた設備の中で動かせると説明されています。また、自社のデータセンターに置き、外部と切り離して動かす専用機は、2026年第4四半期の出荷予定とされています。専用機はまだ提供前の予定の製品です。今の時点で比べる対象は、自社のクラウドの中に置く形までです。

3つの形は、どれが優れているという話ではありません。同じ会社の中でも、扱うデータや業務によって使い分けることがあります。たとえば、社外に出してよい情報だけを扱う社内の調べものはクラウド型サービスで、顧客の口座の情報を扱う業務は自社のクラウドで、という分け方です。1つの形に全社を寄せる必要はありません。ただし形が増えるほど、統制の手間も増えます。

3つの形を6つの観点で比べる

情シスが比べる観点を、データの置き場所・安全機能の持ち方・作れる人・運用の手間・費用の増え方・やめ方の6つに絞って並べました。製品ごとの細かな違いではなく、形ごとの傾向です。

観点	クラウド型の作成サービス	自社クラウドに置ける基盤（Lyzr など）	一からの自社開発
データの置き場所	提供元のクラウド。契約や設定で保存先の地域を選べることもある	自社のクラウドのアカウントの中。ただし言語モデルの呼び出し先は別に決める	すべて自社の設計しだい
安全機能の持ち方	提供元が用意した範囲で使う	基盤に組み込まれた機能を、全エージェントに共通でかける	自社で作って載せる。抜けも自社の責任
作れる人	業務担当まで広げやすい	エンジニア向けと業務担当向けの画面を分けて持つ	主にエンジニア
運用の手間	小さい。基盤の更新は提供元	中くらい。更新の適用・見張り・障害の切り分けの一部が自社に来る	大きい。すべて自社
費用の増え方	利用者の数や実行の量で増える	製品の契約に加え、自社クラウドの計算資源とモデルの呼び出しの費用が別に増える	開発と保守の人件費が中心。使う量に応じてクラウドの費用も増える
やめ方	作ったエージェントと記録を書き出せるかが鍵	記録は自社クラウドに残るが、基盤の部品への依存が残る	自社の資産として残るが、保守する人がいなくなると止まる

表で見ると、真ん中の形は「データの置き場所」と「安全機能を共通でかける」ことに強みがある一方、運用の手間と費用の流れが二重になる点に注意が要ります。自社クラウドに置く形を選ぶなら、基盤の契約と、自社クラウドの費用の両方を見積もる必要があります。

比べるときは、6つの観点を同じ重さで扱わないことです。規制の厳しい業種や、顧客の個人情報を大量に扱う業務では、データの置き場所が最初に決まり、その条件を満たす形の中で残りの5つを比べる、という順番になります。逆に、社外に出してよい情報しか扱わないなら、運用の手間の小さいクラウド型サービスが有力になります。最初に決めるのは製品ではなく、扱うデータの区分です。

自社クラウドに置くと、何が変わり、何が変わらないか

自社のクラウドに置く最大の利点は、エージェントが読み書きするデータ、操作の記録、動いている計算資源が、自社のアカウントの中にとどまることです。Lyzr の資料は、アマゾンの構成について「何も環境の外に出ない」と書いています。自社のクラウドの見張りの仕組みや、アクセスの決まりをそのまま当てられるのも利点です。既存のセキュリティの点検の流れに、エージェントの基盤を乗せやすくなります。

一方で、変わらないこともあります。言語モデルをどこで動かすかは、基盤の置き場所とは別の判断です。基盤を自社のクラウドに置いても、エージェントが外部の言語モデルの提供元を呼ぶ設定なら、問いかけの中身はそちらに渡ります。自社のクラウドの中で提供されるモデルを使うのか、外部の提供元を呼ぶのか、外部を呼ぶなら学習に使われない契約かを確かめたか。この3点は、基盤とは別に決めます。

もう1つは、つなぐ先のデータの権限です。エージェントが社内の文書や顧客の記録を読むとき、誰の資格で読むかは、置き場所に関係なく設計しなければなりません。自社クラウドに置くことは、権限の設計を省く理由にはなりません。広すぎる権限を持ったエージェントは、自社のクラウドの中にあっても、見せてはいけない人に情報を渡してしまいます。

安全機能を基盤の側に持たせる設計とは

Lyzr の打ち出しのもう1つの柱は、責任あるAIの機能を、エージェントごとではなく基盤の側に組み込む設計です。公式の説明では、責任あるAIの考え方を「すべてのエージェントの中核の作りに組み込んでいる」としています。2026年10月時点で挙がっている機能は、個人情報の伏せ字、有害な内容の検出と遮断、偏りの監視、判断の理由を追って説明する層と判断の記録、言語モデルと従来の機械学習を組み合わせて正確さを上げる仕組み、人の確認を挟む仕組み、暗号化とアクセスの制御です。

基盤に持たせる利点は、部署ごとの作り方の差に左右されにくいことです。部署がそれぞれ作ると、伏せ字の処理を入れ忘れたエージェントが必ず出ます。基盤の側で共通にかけておけば、作る人の注意力に頼らずに、最低限の歯止めがそろいます。アマゾンの構成の資料には、すべてのエージェントの操作、言語モデルの呼び出し、道具の実行を記録する全体の操作記録も挙がっています。

公式サイトは、SOC 2 の報告書、ISO 27001 の認証、米国の医療情報の規則や欧州の個人データの規則への対応を掲げています。ただし、これらは提供元の表示です。認証の範囲が、自社が使う提供の形まで含むかどうかは、報告書の中身で確かめてください。自社クラウドに置く形では、自社のクラウドの設定そのものは認証の範囲の外になるのが普通です。

基盤の安全機能に任せきれないこと

基盤の安全機能は、あくまで道具です。個人情報の伏せ字は、決まった型の情報を見つけるのは得意でも、社内でしか通じない案件名や、文脈から個人が分かる記述までは拾いきれないことがあります。有害な内容の検出も、何を有害とみなすかの基準は会社ごとに違います。基盤が持っている既定の基準が、自社の基準と同じとは限りません。任せきれないことを、取り違えやすい例で並べておきます。

• 伏せ字の機能があるから、顧客の記録をそのままエージェントに読ませてよいと判断する
• 判断の記録が残るから、エージェントが出した結論を人が見なくてよいとする
• 偏りの監視が入っているから、採用や与信のような判断をエージェントに任せる
• 基盤の認証があるから、自社のクラウドの設定の点検を省く

どれも、道具が「やってくれること」を「人が決めなくてよいこと」と取り違えた例です。どの業務にエージェントを許すか、どのデータを読ませるか、いつ止めるかは、基盤ではなく人が決めます。基盤の安全機能は、その決めごとを本番で守らせる仕組みとして位置づけるのが自然です。決めごとの文書が先、基盤の設定は後という順番を崩さないようにします。

作れる人をどこまで広げるか

Lyzr は、エンジニア向けの作業台と、業務担当が会話しながら組み立てる作成画面を分けて持っています。公式サイトは対象を「開発者、企業、業務の利用者」と書いています。作れる人を業務担当まで広げられるのは、クラウド型の作成サービスでも、自社クラウドに置く基盤でも同じです。違いが出るのは、広げたあとの統制の手間です。

作れる人を広げるほど、基盤の上に載るエージェントの数は増えます。業務担当が作ったエージェントを本番に出す前に、誰が確かめるかを決めておく必要があります。全員が作れて公開できる配り方と、部署の推進役だけが作る配り方をどう比べるかは、別の記事で扱っています。ここでは、置き場所の違いが統制にどう効くかに絞ります。

自社クラウドに置く形で特に気をつけたいのは、業務担当が作ったエージェントが、自社のクラウドの中の他のデータに届いてしまうことです。クラウド型サービスでは提供元の側で区切られていた範囲を、自社で区切る必要があります。作成画面を開く前に、エージェントが届いてよいデータの範囲を部署ごとに情シスが決め、業務担当の作成画面からは、決めた範囲の外のデータが見えないようにしておくのが基本です。

運用の手間：自社クラウドに置くと情シスが持つもの

自社クラウドに置く基盤を選ぶと、クラウド型サービスでは提供元が持っていた仕事の一部が自社に来ます。基盤の版の更新をいつ当てるか、計算資源の見張り、障害が起きたときの切り分け、記録の保存と削除の期間、などです。提供元の支援を受けるとしても、自社のアカウントの中で起きたことに最後に答えるのは自社です。導入の前に、次の4つを誰が持つかを名前で決めておきます。

• 基盤の版の更新を当てる判断と、当てる前に既存のエージェントが動くかの確かめ
• 計算資源と言語モデルの呼び出しの量の見張りと、上限を超えたときの連絡先
• 障害や誤動作が起きたときの、提供元との切り分けの窓口
• 操作の記録をどこに、どれだけの期間残し、いつ消すか

これらを持つ人がいないまま自社クラウドに置くと、データは手元にあっても、誰も見ていない基盤になります。人の手当てができないなら、クラウド型サービスの形のほうが安全なこともある、という見方も持っておきたいところです。置き場所の安全と、運用の安全は別のものだからです。

費用の増え方

料金の金額は、この記事では扱いません。増え方の仕組みで見ると、自社クラウドに置く基盤の費用は2つの流れで増えます。1つは基盤の製品の契約の費用、もう1つは自社のクラウドで消費する計算資源と、言語モデルの呼び出しの費用です。クラウド型サービスでは、この2つが1つの料金にまとまっていることが多く、見え方が違います。

後者は、エージェントの本数と実行の回数に比例して増えます。エージェントが別のエージェントを呼ぶ構成や、1件の処理で何度もモデルを呼ぶ構成では、見積もりより大きく膨らむことがあります。本番に出す前に、1件あたりのモデルの呼び出しの回数を測っておくと、月の費用の見通しが立ちます。

費用の請求も、基盤の分とクラウドの分に分かれます。部署ごとに費用を割り振るなら、エージェントごとにクラウドの費用を区別できるように、名札の付け方を最初に決めておきます。後から割り振ろうとしても、どのエージェントがどれだけ使ったかを分けられなければ、部署の側は費用の重さを実感できず、使い方も見直されません。

やめ方・乗り換え方を先に決める

エージェントの基盤は、数年で入れ替わる可能性が高い領域です。言語モデルの提供元も、基盤の製品も、まだ動きが速いからです。選ぶときに、やめるときのことを決めておきます。

確かめたいのは3点です。作ったエージェントの設定や手順を、基盤の外に書き出せるか。操作の記録は自社のクラウドに残るか、残るならどの形式か。基盤の部品に依存した作りのエージェントを、別の基盤に移すときにどれだけ作り直しが要るか。自社クラウドに置いていても、基盤の部品への依存は残ります。置き場所が自社でも、製品をやめれば動かなくなる部分はあるのです。

止め方も同じように決めます。特定のエージェントだけを止める手順、基盤全体を止める手順、止めたときに業務を人の手に戻す手順の3つです。止める判断をするのは誰か、夜間や休日はどうするかまで決めておかないと、止めるべきときに止められません。止める権限を持つ人を、導入の前に名前で決めておくことが、基盤を選ぶ前提になります。

一からの自社開発を選ぶ場面

3つ目の形である一からの自社開発は、自由度が最も高い反面、基盤そのものを作り続ける負担を負います。内製と外注の分かれ目の一般論は別の記事で扱っていますので、ここでは基盤の置き場所と安全機能の観点だけで触れます。

自社開発が向くのは、エージェントが会社の中核の業務の差別化そのものである場合や、既存の製品では満たせない規制や接続の条件がある場合です。逆に、安全機能や記録の仕組みを一から作るのは、思った以上に手間がかかります。伏せ字、記録、評価、人の確認の仕組みを自前で作り、保ち続ける費用を、製品の契約の費用と並べてみると、判断がつきやすくなります。

実際には、基盤は製品を使い、その上のエージェントの中身を自社で作る、という組み合わせが多くなるでしょう。Lyzr も、記憶・道具・検索・連携などの部品を、自社の実行環境の中で組み合わせられる形を打ち出しています。どこまでを製品に任せ、どこからを自社で持つかの線を、最初の1本で決めておくのが現実的です。自社で作る部分は、自社で直し続けられる部分に限るという考え方が、線を引く目安になります。

情シスが決める順番

ここまでの観点を、決める順番に並べ直します。製品の比較は、最後の段に来ます。

この順番で決めると、製品の比較は最後になります。製品の機能表を先に比べ始めると、自社の条件が後付けになりがちです。Lyzr を候補にするかどうかも、1つ目と2つ目の条件が決まってから判断すれば、機能の多さに引っ張られずに済みます。

よくある質問

Lyzr で日本語の業務のエージェントを作れますか

使う言語モデルを選べる作りのため、日本語の処理の出来はモデルの能力に左右されます。一方で、管理画面や資料の日本語対応、日本での支援の体制は、2026年10月時点の公式サイトで確かめられませんでした。試用の段階で、自社の日本語の文書を使って確かめてください。

自社クラウドに置けば、外部の言語モデルを使ってもよいですか

基盤の置き場所と、モデルの呼び出し先は別の判断です。外部の提供元を呼ぶなら、問いかけの中身はその提供元に渡ります。扱うデータの区分ごとに、使ってよいモデルを決めるのが基本です。

クラウド型のサービスから始めて、後で自社クラウドに移せますか

移すこと自体は考えられますが、作ったエージェントの設定や記録を書き出せるか、移した先でどれだけ作り直しが要るかは、サービスごとに違います。始める前に、やめ方と移し方を確かめておくと、後の選択肢が残ります。

安全機能が入っていれば、社内の審査を軽くしてよいですか

基盤の安全機能は、決めた範囲を守らせる道具です。どの業務にエージェントを許すかの審査は、基盤に関係なく必要です。審査で決めた条件を、本番で守らせる手段として基盤の機能を使うと考えてください。

自社のデータセンターに置く専用機は使えますか

公式サイトでは、自社のデータセンターに置き、外部と切り離して動かす専用機が2026年第4四半期の出荷予定とされています。2026年10月時点では提供前の予定の製品として扱い、導入の前提にはしないでください。

まとめ

Lyzr は、企業向けのAIエージェント基盤で、自社のクラウドの中で動かせる形と、個人情報の伏せ字や判断の記録などの安全機能を基盤の側に持たせる設計を打ち出しています。2026年3月には、アクセンチュアが主導する調達が報じられました。クラウド型の作成サービス、自社クラウドに置ける基盤、一からの自社開発の3つは、データの置き場所・安全機能の持ち方・作れる人・運用の手間・費用の増え方・やめ方で比べられます。自社クラウドに置けばデータは手元に残りますが、運用と止める責任も手元に戻ります。基盤の安全機能は道具として使い、どの業務にエージェントを許すか、データをどこに置くか、いつ止めるかは人が決める。この線を先に引いてから、製品を比べてください。

• 製品の機能と提供形態は、Lyzr の公式サイト（製品・作業台・責任あるAI・アマゾンの実行基盤向けの各ページ）を2026年10月21日に確かめた範囲に基づきます。予定の製品は時期や中身が変わることがあるため、導入の前に最新の原文で確かめてください
• 調達の情報は、2025年10月の出資の発表と、2026年3月9日のブルームバーグの報道に基づきます
• 認証や規則への対応は提供元の表示です。範囲と対象の提供形態は、報告書や契約で確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。