ABLOG

AIの主戦場が「モデルの外側」に移った二週間

2026年7月6日 ·Glm ·約6,336字
osslanguages

ベンダーがこぞって客先常駐に巨額を投じる異常な二週間

7月2日、Microsoftは「Microsoft Frontier Company」の設立を発表した。6,000人の業界・エンジニアリング専門家を顧客組織内に配置し、AIシステムの設計から展開、運用までを担う組織だ。投資額は25億ドル。リーダーにはアジア地域社長のRodrigo Kede Limaが就く。この発表のわずか2日前、AWSも10億ドルを自社のforward-deployed engineering組織に投じると明らかにしていた。さらに5月にはAnthropicとOpenAIが相次いで同様のサービスベンチャーを立ち上げている。半月足らずで主要AIプラットフォーマーが同じ結論に達した。

読み解くべきは金額よりも構造だ。企業AIの制約要因がモデルから「展開に必要なエンジニアリングリソース」に移った。これが全ての出発点になっている。モデルがいくら賢くなっても、顧客の環境に合わせて動くシステムを作る人が足りない。だからベンダーは自前で人を送り込む。Palantirが2003年に編み出したプレイブックが、20年経って業界の標準になりつつある。

（※Forward-Deployed Engineeringとは、単なる導入支援ではなく、エンジニアが顧客の現場に深く入り込み、実際のデータと業務フローに基づいて製品を共同開発・最適化する手法のこと）

Microsoftの動きは特に興味深い。Frontier Companyは別法人ではなく、既存のコンサルタントやエンジニアを再編した組織だ。25億ドルという数字が新規の投資なのか、既存のコンサルティング予算の流用なのかは明らかになっていない。初期顧客にUnileverとNovo Nordiskを名指しし、AccentureやCapgemini、EY、KPMG、PwCといったグローバルSIerと提携を結んだ。既存のIndustry Solutions DeliveryやFastTrackとの差はどこにあるのか。顧客との実 engagements を通じて、真の新規機能なのかリブランドなのかが見えてくるはずだ。

AnthropicとOpenAIはジョイントベンチャーという形をとった。外部資本とパートナーを巻き込むことで、自社のバランスシートを守りつつ展開体制を固める狙いがあるのだろう。一方でCursorのようなスタートアップも、Pauline Brunetの下でforward-deployed engineeringチームを走らせている。コードエディタを売る会社と世界最大のソフトウェア会社が、四半期の差で同じ配送モデルに着地した。ニッチな戦術ではなく、エンタープライズAIの標準的なアプローチになりつつあることの表れだ。

気になるのは、この構造が既存のSIerとどう噛み合うかだ。MicrosoftがSIerと提携しつつ自前の6,000人を送り込むというのは、領域の棲み分けが曖昧になる。顧客データやIPをモデルのトレーニングに使わないとMicrosoftは約束しているが、これも競争上の差別化ポイントとして意識されているのだろう。ベンダーのエンジニアが社内に入り込み、システムの内側まで触る。そこまで踏み込んでよいのか、ガバナンスの境界線をどこに引くのか。実務でAIを導入するチームは、この新しい関係性の論点を先送りできない。

S3オブジェクトに1GBのメタデータを直接付与できるAnnotationsがGAに

AWSがAmazon S3 Annotationsを一般提供した。オブジェクトあたり最大1000個、合計1GBのメタデータを直接付与できる機能だ。JSON、XML、YAMLで記述し、オブジェクト本体とは独立して更新できる。

これまでS3のメタデータといえば、10個のタグと2KBのユーザー定義メタデータしかなかった。タグは不変。メタデータを変更したければ、オブジェクト全体の再アップロードが必要だった。数KBの分類情報を変えるだけでも、数GBのファイルを丸ごと読み書きする。この非効率に耐えかねて、別途DynamoDBやRDBでメタデータを管理するチームは少なくないはずだ。

Annotationsはここを根本から変える。1アノテーションあたり1バイト〜1MiBのペイロードを、オブジェクトを触らずにCRUDできる。変更があればAPIを1回叩くだけ。バケットでアノテーションテーブルを有効にすれば、全アノテーションが自動的にIcebergテーブルに流れ込み、

（Apache Icebergは、巨大なデータセットに対してSQLのようなクエリを高速に実行可能にするオープンソースのテーブルフォーマット）AthenaやRedshiftからSQLで検索できる。S3 Tables MCPサーバー経由でAIエージェントが自然言語で発見することも可能だ。

実務で何が変わるか。まず、メタデータ更新のための再アップロードが消える。データパイプラインのステップが減る。次に、外部のメタデータストアとその同期処理が不要になるケースが出てくる。コンプライアンス分類やAIの推論結果をS3に置いたままクエリできるのは、アーキテクチャをシンプルにする。

ただし課金には要注意だ。アノテーションは元オブジェクトのストレージ階層に関わらずS3 Standard料金が適用される。GlacierにアーカイブしたオブジェクトのアノテーションもStandard単価。さらにレプリケーション時、各アノテーションのコピーが個別のPUTリクエストとして課金される。1オブジェクトに1000個のアノテーションを付与してクロスリージョンレプリケーションを有効にしたら、どうなるか。想像するだけで請求が怖い。

Corey Quinnが指摘する通り、S3にはすでに4つのメタデータ機構が存在する。そこに5つ目を加える複雑さは否定できない。とはいえ、既存の機構が持つ制約（2KB、10タグ、不変）が実務で壁になっていたのも事実だ。Annotationsはその壁を取り除く。どの機構をどの目的で使い分けるか、チーム内で合意を取る手間は増えるかもしれない。

FoundryでClaudeがGA、ただし欧州ではデプロイ不能

AnthropicとMicrosoftがMicrosoft Foundry上でClaudeのGAを発表した。Claude Opus 4.8、Haiku 4.5が利用可能。Sonnet 5は数日後に追加され、8月31日まで入力$2/出力$10（100万トークンあたり）のプロモーション価格。Entra ID認証、Azure請求、MACC消費対応。

（MACC: Microsoft Azure Consumption Commitment。企業が一定期間のAzure利用額を事前にコミットすることで割引を受ける契約形態）調達プロセスで止まっていたチームにとって、既存のAzureコミットメント予算を使えるのは実務上の前進だ。

だがLinkedInやRedditの反応は一点に集中していた。データがどこに行くのか、だ。CETINのJiri Formanが「Azure上でホストされ、EU内ですべてのデータ処理が可能か」と問い、49リアクションを集めた。SobiのMurat Yasartasの答えはノー。データゾーンはUSのみ。「Azure上でホスト」を選んでも、Anthropicが独立データ処理者としてプロンプトと出力を処理する。スウェーデンにエンドポイントがあっても、デプロイメントタイプが「Global Standard」なら推論はUSインフラにルーティングされうる。オランダの大手銀行はこの理由でFoundry経由の利用を認めていない。

OpenAIモデルとの差が欧州アーキテクトにとっての摩擦だ。Azure上のOpenAIはファーストパーティ。Microsoftが推論を運営し、EUデータゾーンが選べる。一方Claude on Foundryはサードパーティのマーケットプレイス提供で、US CLOUD ActがAnthropicに適用される。

（CLOUD Actは、米国の法執行機関が、データが海外に保存されていても米国のプロバイダーにデータの開示を請求できる権限を認める法律）Anthropic自身のドキュメントも、データレジデンシー保証をVertex AIとBedrockに限定しており、Foundryは含まれない。欧州のMicrosoft Foundryは「Coming 2026」で具体日付なし。4月から開かれているQ&Aも回答ゼロだ。キャパシティも問題で、GAでもフォーム申請が必要。Microsoft MVPのJannik Reinhardは「データセンターにキャパシティがあって初めてGAだ」と指摘している。

注目すべきは、調達の壁を越えた先にもう一つ壁がある構図だ。MACCで予算を使えるのは確かに前進。だがデータレジデンシー要件を満たせないなら、欧州事業を持つ企業のセキュリティレビューは通らない。BedrockやVertexでは既に解決済みのことが、Foundryでは手付かず。欧州でインフラを触るチームは、当面BedrockかVertexを選ぶしかないだろう。

エージェント型AIでトークン消費が爆発している

エージェント型AIのトークン消費がヤバい。中程度の複雑さの要求でも20,000〜60,000トークンを消費し、エンジニアリングタスクになると150,000〜200,000トークンを燃やす。1エージェントで50,000トークンで済むタスクが、複数の専門エージェントを組み合わせると数十万トークンに膨れ上がる。なぜか。ハンドオフのたびにコンテキスト税がかかるからだ。

あるエージェントが別のエージェントに処理を委譲するとき、現在の状態とタスク指示を下流エージェントのコンテキストウィンドウに詰め込む。受け取った側はそれを全部処理し、結果を返す。呼び出し元は返ってきた結果を他の追跡中データと一緒に再取り込みする。30,000トークンのコンテキストを処理して500トークンの応答を返す、そんな交換がループのたびに積み重なる。マルチエージェント構成なら尚更だ。

安いモデルに乗り換えればいい、という話ではない。確かにモデル単価は下がっている。でもトークン消費量が増えればトータルコストは抑えられない。問題は「どのモデルを選ぶか」より「無駄なトークン移動をどう減らすか」にある。

3つの実践的アプローチが挙げられている。まずコンテキストの圧縮。会話履歴をそのまま持ち回るのではなく、要約して前方に渡す。コードベース全体ではなく、タスクに関連する部分だけを提示する。ただし削りすぎると必要な文脈を失うリスクがある。圧縮コンテキストと並べて、重要な事実と決定を保持するコンパクトなメモリ層が必要になる。

2つ目は階層的ルーティング。JSONのパース、ログのフォーマット、ファイル存在確認に最強モデルはいらない。各サブタスクを処理できる最小モデルに割り当てる。エージェントのステップの60〜70%が定型処理なら、軽量モデルで安く済む。これはマイクロサービスでいう「適切なサイズのサービスを適切なリソースで動かす」のと同じ発想だろう。

3つ目はセマンティックキャッシュ。埋め込みを使って新しい要求の意味を比較し、十分に近い一致があれば以前の推論を再利用する。似た質問が繰り返されるカスタマーサポートや、ほぼ同一のファイルを処理するドキュメントパイプラインで効果を発揮する。

ただしトークン単価だけを見ても全体像は見えない。GPU、メモリ、ベクトルデータベース、本番環境の監視ツールにも金がかかる。トークンを節約しても他のスタックが高価なら、結局コストは下がらない。

コンテキスト管理、モデルの呼び出し戦略、タスク分解、中間成果物の再利用。これらが推論価格と同じくらい重要になっている。マイクロサービスの世界で当たり前にやっていることの、AI版への翻訳作業が始まったと言えるかもしれない。

まとめ

4つの話題に共通するのは、AIの制約要因がモデル自体から外側に移ったことだ。ベンダーがこぞって客先常駐に巨額を投じるのも、エージェントのトークン消費が爆発するのも、モデルがいくら賢くなっても「展開する人」「無駄なコンテキスト」の問題が残るからだ。欧州でFoundry経由のClaudeが使えないのも、モデルの性能とは無関係のデータレジデンシーの壁だ。

インフラや運用の設計が、これまで以上に効いてくる。エージェントのタスク分解やルーティングは、マイクロサービスで当たり前にやっていることのAI版への翻訳だ。S3 Annotationsがメタデータの再アップロードを不要にするのも、データパイプラインのステップを減らすという点では同じ方向を向いている。

ただし、構造を変えることには必ず代償がある。

ベンダーのエンジニアが社内に入り込めば、ガバナンスの境界線が曖昧になる。

S3 Annotationsはアーキテクチャをシンプルにする反面、課金と機構の使い分けでチームの合意コストを増やす。

調達の壁を越えた先にデータレジデンシーの壁がある構図も、その一つだ。

モデルの外側に課題が集まっているなら、向き合うべきもそこだ。推論価格の低下に期待するだけでなく、コンテキストの移動を減らし、データの所在を確保し、ガバナンスの境界を引く。地味だが、実務で手を動かすチームが避けて通れない作業になっている。

参照記事

記録日: 2026-07-06