AIエージェント
社内AIエージェントの基盤は内製すべきか、ベンダーに委ねるべきか──Everyが1か月で判断を変えた理由
社内AIエージェントの基盤を内製するかどうかの判断は、技術選定ではなく「チームの時間を何に使うか」という経営判断である。
原題
“Why We Handed Our Agent's Infrastructure to Anthropic” （なぜ私たちはエージェント基盤をAnthropicに委ねたのか）
原文からの引用
“We wanted to build a coworker, not run an infrastructure team.”
日本語訳 私たちが作りたかったのは同僚であって、インフラ運用チームではなかった。
要点
- AIニュースレター運営企業のEveryは、社員ごとにOpenClaw（オープンソースのエージェント実行基盤）を使った個人用AIエージェントを運用していたが、クラウド機の死活監視やSlack認証トークンの定期更新など運用保守の負荷が重く、全社員が1つのエージェントを共有する体制に切り替えた。
- Everyは自前でエージェント基盤をホストする検証を1か月行った末、保守負荷の重さから断念し、Anthropicが提供するClaude Managed Agents（CMA）に基盤を移行、1週間で全社共有のエージェント「@Every」をSlack上で稼働させた。
- CMAへの移行後、Everyが自前で構築すべき対象は「モデルやセッション管理などの基盤（ハーネス）」から「チャットボットと社内の同僚役を区別する判断ロジック」に絞られ、少人数チームでも、運用保守の多くをAnthropicに任せられた。
- 一方でCMAはClaudeモデルしか動かせず他社LLMへのルーティングができず、各セッションの履歴を保持する仕組み上Anthropicのゼロデータ保持オプションも選べないため、Everyは移行をやり直すコストを「ハーネス・セッション・メモリ・ツール・サンドボックスを数か月かけて再構築する規模」と見積もっている。
- 7月下旬にモデルをOpus 5に切り替えると、@Everyの典型的な返信が約280字から約880字に増えて冗長になった（9月に公開されたOpus 5.5に切り替えると収まった）。また、長い会話ではキャッシュ切れによる再書き込みや文脈上限付近での無応答が起きたため、早めに新しいセッションへ切り替える仕組みを入れ、過去の会話を再実行して試すと総コストが39%下がった。
編集部の考察
エージェント基盤を内製するかどうかの判断は、技術選定ではなく「チームの時間を何に使うか」という経営判断である。Everyが1か月の自前運用検証の末にAnthropicのCMAへ全面移行した経緯（要点2）は、少人数チームが基盤の保守に時間を溶かすことの機会コストを可視化している。
自分の組織で社内エージェントの導入を検討する場合、焦点は「どのベンダーの基盤を使うか」ではなく、「基盤を外部化した場合に失う自由度（モデル選択の幅・ゼロデータ保持）をどこまで許容できるか」である（要点4）。Everyが移行し直すコストを数か月規模と見積もっている事実は、一度ベンダーに基盤を委ねると後から引き戻すのに数か月かかることを示している。
経営として決めるべきは、社内エージェント基盤を導入する前に、ベンダーロックインが許容できない要件（データ保持方針やモデルの多様性など）を事前に特定し、それを満たせなくなった場合の撤退基準をあらかじめ定めておくことである。
本記事は海外記事の独自キュレーション・考察であり、原文の翻訳ではありません。引用部分の著作権は原著者に帰属します。
この記事の調査と下書きにはAIを使っています。数値や事実は出典と照合し、公開するかどうかは運営者が判断しています。（制作方針）