# 1つのAIコストを削ると2つ生えてくる：Prosusが語る社内AI運用の総保有コスト

- 番組: [Agentic Conversations (formally mlops.community)](https://ai-curator.jp/podcasts/shows/cmv3z5c0n000l5o10j1ogyu9h)（Demetrios）
- 元のタイトル: Cut One AI Cost and Two More Grow Back
- 配信日: 2026年11月6日
- 長さ: 41分
- 要約作成日: 2026年11月6日
- トピック: [#AIコスト](https://ai-curator.jp/topics/AI%E3%82%B3%E3%82%B9%E3%83%88) [#TCO](https://ai-curator.jp/topics/TCO) [#エージェント](https://ai-curator.jp/topics/%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#モデルルーター](https://ai-curator.jp/topics/%E3%83%A2%E3%83%87%E3%83%AB%E3%83%AB%E3%83%BC%E3%82%BF%E3%83%BC) [#ファインチューニング](https://ai-curator.jp/topics/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%B3%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0) [#評価（evals）](https://ai-curator.jp/topics/%E8%A9%95%E4%BE%A1%EF%BC%88evals%EF%BC%89)
- URL: https://ai-curator.jp/podcasts/cmw3xepsp00005v11fyj9mxev

## 要約

Prosus の AI ディレクター Ioannis Zempekakis が、Demetrios Brinkmann とタンデム自転車で走りながら、全社規模でエージェントを運用する際のコストを語った回。クラウド API 依存の限界、コンテキスト制御とモデルルーターによる10倍のコスト削減、小型モデルのファインチューニング、ベンダーロックインへの警戒、採用の考え方まで幅広く議論している。

## ポイント

- エージェントハーネスはサンドボックスと豊富な連携のためトークン消費が極めて大きく、クラウド API に頼るだけでは大規模組織でコストが指数的に増えると述べている。
- 5分ごとの定期実行や、コードベースを捨てて作り直す習慣など、AI の誤用や無駄が積み上がる点は、データ分野の「鮮度」の教訓と同じだという。
- 最も簡単な最適化はコンテキストの制御と基本的なモデルルーターで、これでコストを10分の1にしたが、月10個の新機能がその効果を上回るペースで増えている。
- 評価（evals）を整備すればタスクごとにモデルを比較でき、ルーターやファインチューニングの副産物として全社に展開できる能力が育つ。
- 技術の変化が速いため、単一ベンダーやオープンソースに全面依存せず、スタックの主要部分を自前で握って選択肢を保つ価値があると主張している。
- 採用では肩書きより、システム設計力、過剰設計を見抜く感覚、エージェントを使うか自作するかを判断できる直感を重視し、両方を備えた人材探しが最も難しいとしている。

## 章立て

- [00:48] **クラウドAPIの限界と百万ドルの決断** — ハーネスやサンドボックスが大量のトークンを消費し、API頼みでは規模に耐えられないことを説明する。
- [03:02] **誰もが作れる時代の誤用と無駄** — 5分ごとの定期実行や作り直しの繰り返しなど、無料に感じられる利用が積み上がるコスト問題を語る。
- [06:16] **ユースケースの選別とマーケットプレイス** — 予算責任者による配分と、既存のアプリやエージェントをチャットで提示する仕組みを説明する。
- [10:19] **評価基盤とROI、10倍のコスト削減** — タスク別にモデルを評価し、コンテキスト制御と基本ルーターでコストを10分の1にした経緯を述べる。
- [16:48] **小型モデルの学習とその採算** — 繰り返しの多い業務で小型モデルを微調整する利点と、規模による採算判断、副産物としての能力を議論する。
- [25:13] **ロックイン回避とSlackボットからの進化** — ベンダーやOSSの変動リスクを挙げ、自前でスタックを握ることでGPT-3のSlackボットからハーネスへ進化できたと語る。
- [28:30] **トップダウンとボトムアップの投資** — 既存の重要業務への投資と、全員が作れるツールから新たな知見を得る戦略を説明する。
- [32:19] **AIエンジニアの採用基準** — 設計力、過剰設計を見抜く目、エージェントへの直感を重視し、両方を備えた人材探しの難しさを語る。

## 解説記事

Prosus の AI ディレクター Ioannis Zempekakis が、ホストの Demetrios Brinkmann とアムステルダムでタンデム自転車に乗りながら、全社規模で AI を使うとコストは実際どうなるのかを語った。2024年からエージェントを本番運用してきた経験に基づく話で、コスト、内製、採用が一続きの問題として語られている。

#### クラウドAPIだけでは規模に耐えない

Ioannis は、GCP や OpenAI、Claude のエンドポイントを叩くだけなら安心感は大きいが、スケールしない、高すぎると述べる。利用者が増えて実際に消費が始まると、特にエージェントハーネス（エージェントを動かす実行基盤）はトークンを非常に多く使うという。ハーネスにはサンドボックス付きの「コンピュータ一式」が与えられ、Slack、メール、Google Doc、Notion などから情報を引き出して PR やチケットと突き合わせる処理が何百回も走りうるためだ。

人間にとっては無料に感じられるが実際は無料ではなく、現状は補助金で安く提供されている面が強いという見方も示した。補助金が切れればさらに高くなる可能性があるとの認識だ。

#### 誤用と無駄の積み重ね

誰でも作れるようになった結果、本来は不要な5分ごとの定期実行が設定されたり、うまくいかなかったコードベースを捨てて何度も作り直したりする。コンテキストが膨らむとコストも膨らむ。これはデータの世界で、鮮度が不要なのに頻繁に更新していた問題と同じ構図だと指摘する。かつてはデータ担当者だけが扱い、責任も明確だったが、今は強力な道具が全員に渡っている点が違う。

対策としては、予算責任者を置いてトークンを配分する、コスト感を利用者に教育する、既存のアプリやエージェントをマーケットプレイスで共有する、といった手が挙がった。ただし Demetrios が懸念したように、人は市場を探索したがらない。Ioannis も、第一の目的は「何ができるか」を知らせる教育であり、ユーザーの依頼に対してチャット内で「すでに誰かが作っている」と提示する形にすべきだと答えた。

#### 評価、ルーター、小型モデルで下げる

最大の変化は優れた評価（evals）を作ったことだと言う。評価をタスクごとにまとめれば、全モデルをベンチマークして「このタスクにはこのモデル」と使い分けられる。最も簡単な最適化はコンテキストの制御と、賢くなくてよい基本的なモデルルーターで、これだけでコストを10分の1にしたという。ただし月に10個の新機能を作っており、「1つ削ると2つ生えてくる」ヒドラ状態で、ペースが最適化を上回っているとも述べた。

さらに、繰り返される業務（物流のトレースやデータ分析など）では小型モデルのファインチューニングが有効になりうるとする。小さいほど速く安いからだ。ただ採算は規模次第で、5人しか使わないなら見合わない。計算して判断する必要があり、副産物として得られる評価基盤や社内の技術力を全社に展開できる点も価値だと説明した。ルーター自体は購入できるが、それを支える評価スイートが必要になる。生成 AI でエンジニアリングが不要になったわけではなく、速く作れる分、インフラや可観測性の土台がより重要になるという見解だ。

#### ロックインを避け、スタックを握る

技術変化が速いため、制御できないものに縛られたくないと言う。OpenAI や Claude に全面依存すれば乗り換えは難しい。オープンソースも、数か月で主流が移り変わる例（OpenClaw から Hermes、さらに別プロジェクトへ）があり、小さな企業は方針転換もしうる。そのため最初の採用者にならない、または自前で作って素早く転換できるようにする、という選択肢の価値を語った。Prosus は GPT-3 を使った Slack ボットから、Web アプリ、ツールを選ぶエージェント、そしてハーネスへと進化させたが、これはスタックの大部分を握っていたから可能だったという。

投資先の選び方は二本立てだ。カスタマーサポート、データ分析、マーケティング予算や物流の最適化など、AI 以前から重視してきた業務はトップダウンで拡張する。同時に、誰でもアプリを作れるツールを配り、使われ方から新しい知見を得るボトムアップも進める。

#### 採用で見るもの

「AI エンジニア」という肩書きでは採用せず、製品の特定領域の専門性で採るという。インフラ、評価、GPU 配信まで全部できる人はほぼいない。重視するのは、コーディングが抽象化された今も残る設計力で、ホワイトボードでのシステム設計面接が重要だと述べる。AI が出しがちな過剰設計を嗅ぎ分ける力も必要だ。

AI 面では、モデル学習の深い知識より、エージェントの構築方法や限界についての直感を求める。例えば Hermes が OpenClaw より好まれる理由を試して語れるか、といった点だ。静的なダッシュボードを作るのか、エージェントに変化するキャンバスを任せるのかといったトレードオフを判断できることも挙げた。最も難しいのは、ソフトウェア経験が豊富で、新技術にも前のめりな人材を見つけることだという。肩書きの意味が曖昧なので、求人票には具体的に何を指すかを書くべきだという Demetrios の指摘にも同意した。

#### まとめ

この回の核心は、AI のコストは API 単価だけでなく、利用が広がった後の使われ方、コンテキスト、評価、内製の判断を含む総保有コストで考えるべきだという点にある。日本企業でも全社展開が進めば同様の問題が出るはずで、まず評価基盤とシンプルなルーターから始め、ベンダー依存の度合いを意識するという順序は参考になる。なお数値や方針は Ioannis 個人の発言であり、一般化には注意が必要だ。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Agentic Conversations (formally mlops.community)「Cut One AI Cost and Two More Grow Back」