TrueFoundryでも統制が効かない原因｜自社に置くかの判断軸

「AIの窓口を一つにまとめたのに、部門ごとのAI利用料は先月より増えている」「提供元のクラウド版で済ませるか、自社の Kubernetes に置くべきか、情シスの中でも意見が割れている」——AIの利用を一か所に集めようとしている会社の情シスと基盤チームから、ここ半年で増えた相談です。米国の TrueFoundry は、AIの呼び出しを受ける窓口、エージェントの窓口、モデルの配備をまとめた基盤で、自社の窓口が1日に1兆を超えるトークンを処理していると公表しています。2026年6月には、英国で2014年に創業した Seldon の事業と顧客を引き継いだと発表しました。ただ、こうした基盤を入れても、それだけでは統制は効きません。効かない原因は製品の機能より、置き場所の選び方と、運用・費用・停止の持ち主が決まっていないことにあります。この記事では、TrueFoundry を例に、窓口を自社に置くかクラウド版を使うかの判断、運用を誰が持つか、部門別の費用の配り方と上限、買収後に確かめることを整理します。

TrueFoundry は、AIの窓口と配備の基盤を自社の Kubernetes に置ける製品

TrueFoundry は、米国サンフランシスコを拠点とする会社です。製品は大きく三つに分かれます。社内のアプリや社員からのAIの呼び出しを一か所で受けるAIゲートウェイ、エージェントが道具やほかのエージェントを呼ぶ通り道をまとめるエージェントゲートウェイ、そして自社で動かすモデルやエージェントを配備する基盤です。公式の説明では、これらを企業のAIのための、Kubernetes を土台にした一つの管理の面と位置づけています。

AIゲートウェイの紹介ページには、利用者・サービス・接続先ごとの呼び出し回数の制限、費用やトークン量の上限、上限を超えたときに遅らせる・安いモデルに切り替える・止めるといった動き、モデル・チーム・利用者・顧客・環境ごとの費用の内訳が並んでいます。入力と出力のガードレールとして、個人情報の除去、有害な表現の検出、プロンプトの乗っ取りの検出、扱わない話題の指定も挙がっています。MCP の道具の呼び出しにも、OAuth と権限の方針を一つずつ当てると説明しています。

AIゲートウェイという仕組みそのものの説明や、窓口を一つにする利点の一般論は、別の記事で扱っています。ここで扱うのは、TrueFoundry のように置き場所を自社の環境まで選べる製品を前にしたときに、何を決めなければならないかです。製品の機能表を読んでも、その答えは書かれていません。

• 1日1兆トークン、窓口の遅れが数ミリ秒といった数字は、いずれも提供元の公表値で、第三者による検証値ではありません
• 米国の調査会社 Gartner の2025年のAIゲートウェイの市場ガイドで、代表的な提供者の一つに挙げられたと同社は発表しています

2026年の動き：エージェントの窓口、Seldon の買収、オープンソースの公開

2026年に入ってからの TrueFoundry の動きは、エージェントに寄っています。5月には、エージェントが道具やモデル、ほかのエージェントとやり取りする通り道を一つにまとめるエージェントゲートウェイを打ち出し、連載の解説記事を公開しました。どの枠組みで作ったエージェントでも登録して、手順ごとの動きを追えるようにするという説明です。

6月24日には、Seldon の買収を発表しました。Seldon は英国で2014年に創業し、Kubernetes の上で機械学習のモデルを本番で動かす仕組みを10年以上手がけてきた会社で、銀行、小売、通信、保険、医療などの顧客を持つと紹介されています。TrueFoundry の公式ブログ（10月15日更新）は、Seldon の事業と顧客を引き継いだと書き、Seldon の顧客の機械学習は TrueFoundry の配備基盤で動き続け、既存の Kubernetes の環境もそのまま使えるとしています。移行の間も支援を続け、顧客には個別に連絡すると説明しています。

8月19日には、エージェントを動かす実行の枠組みをオープンソースで公開したと発表しました。同社のAIゲートウェイと MCP の窓口と組み合わせる前提の部品です。公式ブログの更新も月単位で続いており、提供終了や新規受付の停止の告知は見当たりません。一方で、買収で何が変わり何が変わらないかは、公開情報ではまだ細部まで書かれていません。これは後の章で、確かめる項目として整理します。

課題1：窓口を入れても、部門ごとの費用が止まらない

AIの窓口を入れる動機として最も多いのは費用の見える化です。部門ごとに契約がばらばらだったAIの利用料を一か所に集め、誰がどれだけ使ったかを知りたい。TrueFoundry の窓口も、モデル・チーム・利用者・顧客・環境ごとに費用を分けて見せる機能を前面に出しており、同社は平均で3割の費用の削減につながると説明しています。

ところが、入れた後に起きがちなのは、見えるようになったのに止まらないという状態です。マーケ部門が記事の下書きや広告文の生成を大量に回し、営業部門が商談の要約をエージェントに任せ、どちらも月末に請求を見てから驚く。窓口には上限を設定する機能があるのに、上限の値と、超えたときの動きが決まっていないため、全部を通してしまうのです。

もう一つは、費用を見る単位の問題です。窓口が出す内訳は、設定した区分でしか分かれません。部門の区分を作らずに利用者の単位だけで集めていると、兼務の社員や共有のサービスの利用が、どの部門の予算から出たのか後から説明できません。費用を配る単位が決まらないまま窓口だけ入れると、月次の会議で数字はそろうのに、誰も削る判断ができないという結果になります。

課題2：記録はそろったのに、誰も読んでいない

窓口を通すと、AIへの要求と応答が一か所に記録されます。TrueFoundry の紹介ページも、要求と応答の全文を一元的に保存し、目印を付けて絞り込めること、エージェントの動きを手順ごとに追えることを挙げています。監査の観点では大きな前進です。

しかし、記録が残ることと、記録が読まれることは別の話です。全文の記録には、社員がAIに貼り付けた顧客の情報や、社内の未公開の資料も含まれます。それを誰が、どの頻度で、何を探すために読むのかが決まっていなければ、記録は事故の後に掘り返すための倉庫にしかなりません。加えて、全文の記録はそれ自体が機密の塊になります。読める人を絞らずに管理画面の権限を広く配ると、窓口が新しい漏えいの経路になります。

記録の置き場所も論点です。後で詳しく見るように、TrueFoundry の置き方によっては、記録を自社の保管場所に書き出せる一方で、提供元の管理の面がその保管場所を読みに来る設定もあります。記録をどこに置き、誰が読めるかは、置き方を選ぶ段階で決めておく必要があります。

課題3：エージェントが窓口の外を通る

三つ目の課題は、エージェントです。AIの窓口は、アプリが窓口を経由してAIを呼ぶように設定されて初めて効きます。ところが、部門が独自に試しているエージェントは、手元の端末から直接AIの提供元を呼んだり、MCP の道具を個別につないだりしています。窓口の内側にいるのは、情シスが把握している呼び出しだけという状態が珍しくありません。

TrueFoundry がエージェントゲートウェイと MCP の窓口を別に用意しているのは、この隙間を埋めるためです。エージェントの登録、道具の呼び出しごとの権限の確認、手順ごとの記録をまとめて扱うと説明しています。ただし、これもエージェントを窓口に登録させる運用があって初めて意味を持ちます。登録しないエージェントは、どれだけ良い窓口を置いても見えないままです。

社員が独自に置いたエージェントを見つける方法そのものは、別の種類の製品の領域です。ここで押さえておきたいのは、窓口の製品を選ぶ前に、社内のエージェントを窓口に通させる決まりを作れるかどうかを確かめることです。決まりが作れない会社では、窓口を自社に置くかどうかの議論より先に、そちらが詰まります。

原因1：置き場所を「安全そう」で選び、運用の持ち主を決めていない

ここからは原因を見ていきます。一つ目は、置き場所の選び方です。自社の Kubernetes に置けると聞くと、データが外に出ないから安全だ、と考えがちです。たしかに TrueFoundry の紹介ページは、自社のクラウドや社内の環境で動かす場合について、データとモデルが自社の範囲にとどまると説明しています。

ただ、自社に置くということは、窓口が止まったときに直すのも、版を上げるのも、穴がふさがれた版に入れ替えるのも、自社の仕事になるということです。窓口はAIの呼び出しをすべて通すため、窓口が落ちると社内のAI利用がまとめて止まります。公式の資料は、自社に置く場合に自社が窓口と記録の取り込みの仕組みを動かし続ける責任を持つと書いています。夜間や休日に誰が呼び出されるのかを決めずに置くと、安全のつもりで選んだ置き方が、最も止まりやすい置き方になります。

持ち主の問題は、情シスと基盤チームの間でも起きます。Kubernetes の運用は基盤チーム、AIの利用の方針は情シス、費用は経営企画、という分け方をしている会社では、窓口がどこにも属さないことがあります。窓口の持ち主は、一つのチームの一人の名前で決めるのが原則です。

原因2：費用を配る単位が、組織とずれている

二つ目の原因は、費用を配る単位です。TrueFoundry の窓口は、要求に付けた目印をもとに費用やトークンの上限を設定できると説明しています。つまり、何を単位に上限をかけるかは、目印の付け方で決まります。部門で付けるのか、案件で付けるのか、アプリで付けるのか。この設計を後回しにすると、上限機能があっても使えません。

よくあるずれは三つあります。一つは、利用者単位で集計していて、異動や兼務で部門が変わったときに過去の費用が移ってしまうこと。二つ目は、全社で共有するアプリ、たとえば社内の問い合わせ応答の費用が、どの部門にも配られずに情シスの予算に積み上がること。三つ目は、顧客に提供するサービスの中でAIを呼ぶ費用と、社内の業務での費用が同じ区分に混ざることです。前者は売上の原価、後者は経費であり、混ざると採算の判断ができません。

費用の配り方は、経理の決まりと合わせる必要があります。窓口の設定だけで完結する話ではないため、情シスが単独で決めず、経営企画や経理と一度すり合わせてから目印の設計に入るのが近道です。

原因3：止める条件が、設定ではなく人の頭の中にある

三つ目の原因は、止める条件です。窓口には、上限を超えたら止める、遅らせる、安いモデルに切り替えるといった動きを設定できます。ガードレールにも、個人情報を検出したら止める、伏せて通す、といった選択肢があります。しかし多くの会社では、「おかしなことが起きたら誰かが止める」という人の判断に頼っています。

人の判断に頼る運用の弱点は、気づくのが遅いことです。月末の請求で気づく、取引先からの指摘で気づく、という順番になります。一方で、すべてを自動で止める設定にすると、商談の直前に営業のエージェントが止まる、といった業務の事故が起きます。自動で止めるものと、人が判断してから止めるものを分けて書き出すことが必要です。

ここで注意したいのは、止めるかどうかの判断そのものをAIに任せないことです。窓口が出す警告や、AIが作る利用状況の要約は判断の材料にはなりますが、業務を止めるかどうかは、影響を受ける部門の責任者と窓口の持ち主が決めます。窓口は決まりを実行する場所であって、決まりを作る場所ではありません。

置き方は四つ。何が社外に出るかで選ぶ

TrueFoundry の公式ドキュメントは、AIゲートウェイの置き方を四つに分けて説明しています。違いは、窓口と管理の面がどこで動き、要求と応答、記録がどこを通るかです。費用は自社の環境を動かす目安として示されたもので、契約料は別です。

置き方	どこで動くか	社外に出るもの	運用の持ち主	契約区分と目安
提供元のクラウド版	窓口も管理の面も提供元	要求と応答が提供元の窓口を通る	提供元	入門の区分
クラウド版と自社の保管場所	窓口と管理の面は提供元、記録は自社の保管場所	要求と応答は提供元の管理の面を通る。一時的な保持はあるが長期には持たないと説明	提供元。保管場所は自社	入門の区分。保管と転送の費用は自社
窓口だけ自社	窓口は自社、管理の面は提供元	AIへの要求は提供元を通らない。指標は管理の面に保存。記録を見るには提供元に保管場所の読み取りを許す	窓口と記録の取り込みは自社	Enterprise の区分。自社環境で月約600ドルと案内
窓口も管理の面も自社	認証と分析の一部を除き自社	社員のメールアドレスと要求の件数のみが認証の仕組みに送られると説明	ほぼすべて自社	Enterprise の区分。月約800〜1,000ドルと案内

表で見ると、自社に置くほど社外に出るものは減り、自社の運用は増えます。判断の軸は、社外に出してよくないデータが、AIへの要求の中に実際に含まれるかどうかです。マーケ部門の記事の下書きが中心なら、提供元のクラウド版で足りる場合もあります。顧客の個人情報や、契約上ほかの会社に渡せない資料をAIに渡す業務があるなら、窓口だけでも自社に置く理由になります。

見落としやすいのは、窓口だけ自社の置き方で、記録を見る機能のために提供元に自社の保管場所の読み取りを許す点です。許さなければ記録の閲覧が使えず、許せば提供元の管理の面が記録に触れられます。どちらを選ぶかは、記録の中身の機密度で決めることになり、この点は契約前に書面で確かめておくべき項目です。

自社に置くと、誰の仕事が増えるか

自社に置く場合に増える仕事を、具体的に書き出しておきます。窓口と記録の取り込みの仕組みを動かし続けること、版の更新と穴の修正を取り込むこと、提供元の管理の面との認証の鍵を管理すること、記録の保管場所の容量と保存期間を管理すること、障害時に連絡を受けて切り分けることです。

これを担える体制があるかどうかは、Kubernetes を本番で動かしている基盤チームがいるかでほぼ決まります。基盤チームがいない会社が、AIの窓口のためだけに Kubernetes の運用を始めるのは、守りたいものより、守るための仕事のほうが大きくなる選び方です。この場合は、提供元のクラウド版で始め、記録だけを自社の保管場所に置く形から入るほうが現実的です。

逆に、すでに Kubernetes で社内のサービスを動かし、Seldon のような仕組みで機械学習のモデルを本番に出している会社にとっては、自社に置く追加の負担は小さくなります。今回の買収は、まさにそうした会社を対象にしたものです。自社に置けるかどうかは、製品ではなく自社の運用の成熟度で決まると考えておくとぶれません。

対策1：部門ごとの上限と、超えたときの動きを先に決める

ここからは対策です。一つ目は、費用の上限と、超えたときの動きを設定として先に書くことです。TrueFoundry の窓口は、上限を超えたときに止める、遅らせる、安いモデルに切り替えるといった動きを選べると説明しています。どれを選ぶかは業務によって変わるため、部門と業務の組み合わせごとに決めます。

ここで、安いモデルへの自動の切り替えには注意が要ります。費用は守れますが、出力の質が変わるため、顧客に出す文章や判断の材料に使う要約では、利用者が気づかないうちに質が下がります。切り替えてよい業務と、止めて人に知らせるべき業務を分けるのが、この設定の要点です。

対策2：記録を読む人と、読む目的を決める

二つ目の対策は、記録の読み方を決めることです。全文の記録を全部読むことは現実的ではありません。読む目的を絞ります。たとえば、ガードレールで止まった要求の確認は週に一度、費用が急に増えた区分の中身の確認はその都度、監査のための抜き取りは四半期に一度、といった形です。

読む人は、目的ごとに分けます。止まった要求の確認は情シスの担当者、費用の急増は窓口の持ち主と該当部門の責任者、監査の抜き取りは内部監査や法務です。そして、全文の記録を読める権限は、この人たちだけに絞る必要があります。TrueFoundry は単一のログインや権限の管理、監査の記録を機能として挙げていますが、誰に何を見せるかの線は会社が引きます。

記録の保存期間も決めておきます。長く持つほど監査には役立ちますが、漏えいしたときの被害も大きくなります。個人情報を含む要求を記録から伏せる設定があるかどうか、伏せた場合に事故の調査に支障がないかは、導入前の検証で実際の要求を流して確かめる項目です。

対策3：エージェントと MCP の道具を、窓口の内側に入れる

三つ目の対策は、エージェントを窓口に登録させる決まりを作ることです。部門が試しているエージェントを、試行の段階から窓口を経由させ、MCP の道具も窓口に登録したものだけを使えるようにします。TrueFoundry の説明では、MCP の窓口は道具の呼び出しごとに OAuth と権限の方針を当て、社内で作った MCP サーバーも登録できるとしています。

この決まりは、禁止ではなく近道として示すのが定着のこつです。窓口を通せば、AIの提供元の鍵を各自が持たなくてよい、費用が部門の予算に自動で配られる、記録が残るので監査の対応が楽になる。現場にとっての手間が減る形で窓口を差し出すと、登録は進みます。逆に、申請書と承認の待ち時間だけが増えると、部門は窓口の外で試し続けます。

窓口に登録したエージェントについても、何をしてよいかの判断はAIに任せません。道具の呼び出しの権限は人が決め、エージェントの手順ごとの記録は、エージェントが自分で報告する内容ではなく、窓口の側の記録で確かめます。エージェントに自分の行動の正しさを判断させないのが、記録を窓口で取る意味です。

買収後に確かめること

Seldon の買収は、TrueFoundry にとって機械学習のモデルの本番運用と、生成AI・エージェントの窓口を一つの管理の面にまとめる動きです。公式ブログは、既存の TrueFoundry の顧客には何も変わらないとし、Seldon の顧客には移行の支援を続けると書いています。ただし、公開情報には書かれていないことがいくつかあります。

• Seldon のオープンソースの中核部分の使用許諾が今後変わるかどうかは、公式ブログでは触れられていません
• Seldon の製品をいつまで個別に支援し、いつ TrueFoundry の配備基盤への移行を求めるのか、具体的な時期は示されていません
• 買収の金額や条件は公表されていません

すでに Seldon を使っている会社は、移行の時期と、移行しない場合の支援の期限を書面で確かめておきます。これから TrueFoundry を検討する会社は、買収で増えた機能が、自社が使う置き方でも提供されるかを確かめます。新しい機能が提供元のクラウド版から先に出て、自社に置く版には遅れて届くことは、この種の製品では珍しくありません。

もう一つ、窓口の製品は買収や事業の方針転換の影響を受けやすい領域です。AIゲートウェイの分野では、2026年に入ってほかの製品でも買収が続いています。窓口を外す手順を、入れる前に作っておくことが、どの製品を選ぶ場合でも共通の備えになります。アプリが窓口を呼ぶ設定を一か所にまとめ、窓口を経由しない経路に戻せるようにしておけば、乗り換えも停止もできます。

導入前に確かめる項目の一覧

ここまでの内容を、導入を決める前に確かめる項目として並べます。すべてに答えが出るまで、本番の利用を窓口に集めないほうが安全です。

• 窓口の持ち主を、一つのチームの一人の名前で決めた
• 社外に出してよくないデータが、AIへの要求に実際に含まれるかを業務ごとに確かめた
• 四つの置き方のうち、どれを選ぶかと、その理由を記録した
• 自社に置く場合、夜間・休日の障害の連絡先と、版の更新の担当を決めた
• 費用を配る単位を経理とすり合わせ、要求に付ける目印の決まりを作った
• 部門と業務ごとの上限と、超えたときの動き（止める・遅らせる・切り替える）を決めた
• 全文の記録を読める人、読む目的、保存期間を決めた
• エージェントと MCP の道具を窓口に登録させる決まりを作った
• 買収後の支援と使用許諾、置き方ごとの機能の差を書面で確かめた
• 窓口を外して元の経路に戻す手順を書いた

逆に、次のような進め方は避けます。

• データが外に出ないからという理由だけで、運用の体制がないまま自社の Kubernetes に置く
• 上限を決めずに全部門の利用を窓口に集め、月末の請求を見てから配り方を考える
• 全文の記録を見られる権限を、部門の担当者に広く配る
• 上限に当たった業務を、利用者に知らせないまま安いモデルに自動で切り替える
• 止めるかどうかの判断を、窓口やAIの要約に任せる

まとめ

TrueFoundry は、AIの窓口、エージェントの窓口、モデルの配備を一つにまとめ、提供元のクラウド版から自社の Kubernetes まで置き方を選べる製品です。2026年6月の Seldon の買収で、機械学習の本番運用まで範囲を広げました。ただ、窓口を入れるだけで統制が効くわけではありません。効かない原因は、置き場所を印象で選ぶこと、費用を配る単位が組織とずれていること、止める条件が人の頭の中にあることです。置き方は社外に出るデータで選び、運用の持ち主を名前で決め、部門ごとの上限と超えたときの動きを先に設定する。止めるかどうかの最後の判断は、窓口やAIではなく人が持つ。この順番で決めてから入れれば、窓口は統制の道具として働きます。

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