Salesforceの技術ブログ「Salesforce Engineering」が、本番のインフラ設定を書き換えるAIエージェントを、どう信頼できるものに作り直したかを公開しました。公開は2026年6月9日（6月11日に更新）で、この記事は10月13日に確認した内容です。結論は、プロンプトを足し続けても、エージェントを増やしても安定せず、「あいまいな調べ物はAI、毎回同じ答えが要る計算はソルバー」と分けたことで信頼性が出た、というものです。
先に、書かれていないことを分けます。ブログには、節約できた金額、処理した件数、作業時間の削減といった成果の数字がありません。「数百万ドル規模の削減余地」と書かれているのは目標としての見込みで、達成した額ではありません。信頼性が「大きく改善した」とも書かれていますが、どれだけ改善したかの数字はありません。この記事では、確認できる構成と考え方だけを扱います。
何を任せたAIなのか
対象は、Salesforceのインフラ基盤「Hyperforce」の、数千の本番サービスのCPU設定です。ブログによると、コンテナの86%が、要求したCPUの20%未満しか使っておらず、確保した容量のおよそ半分が遊んでいる状態でした（クラウドの経済性データによる）。これを減らすのが目的です。
難しかったのは、設定の「正解の場所」がどこにも一つにまとまっていないことです。CPUの値は、Terraform、Helm、Structured Configuration という複数の仕組みに散らばり、環境や地域ごとの上書きも加わります。同じサービスに複数のCPU値があり、優先順位も違い、本番で効いている値が、見た目の設定と別のことがありました。ブログは、人間が手順を確立した作業を自動化するのではなく、人間の技術者にも調査が要る問題を、AIに解かせたかったと書いています。しかも、答えを出すだけでなく、本番のインフラの変更案まで作らせるものです。
うまくいかなかった2つのやり方
- ▸1つ目：プロンプトを大きくする。最初は、モデルにリポジトリと使用状況のデータ、調べ方の指示を渡しました。単純なリポジトリではうまくいきましたが、複雑になるほど崩れました。たとえば、あるリポジトリではHelmチャートのCPU値が正解に見えたのに、実際は環境別の上書きが本番を決めていました。例外が見つかるたびに指示を足した結果、プロンプトは「英語で書かれたソフトウェア」のようになり、信頼性は上がりませんでした
- ▸2つ目：エージェントを分ける。リポジトリの調査、最適化の計画、プルリクエスト（PR）の作成、検証を別々のエージェントに分けました。ところが、同じリポジトリ・同じ使用状況・同じ目標でも、実行のたびに最適化の計画や作られるPRが変わりました。モデルを上げても、プロンプトを直しても、レビュー役のエージェントを足しても、ばらつきは残りました
ブログは、ここで見方を変えたと書いています。「言語モデルに、毎回同じ答えを出させようとしていた。そもそもモデルに任せるべきでない仕事を任せていたのではないか」という問いです。
作り直した構成（ブログで確認できる範囲）
- ▸①調べる（AI）：エージェントがリポジトリを調べ、設定がどこで定義され、どれが本番で効いているかを、構造化した形で出力します
- ▸②計算する（ソルバー）：その出力を、整数線形計画法（ILP）の最適化エンジンに渡します。設定の層を「決めるべき変数」として扱い、「使われない余りのCPUを減らす」と「設定を複雑にしない」という複数の目標を同時に最適化します。ブログがいちばん評価しているのは、同じ入力から必ず同じ答えが出ることです
- ▸③変更を作る（AI）：計算結果を、変更を適用してPRを作る別のエージェントに戻します。ブログは、この順を「推論→決定論的な計算→推論」と呼んでいます
- ▸④確かめる（機械）：ビルド、コンパイラ、リンター、検証スクリプト、CIパイプラインで、モデルの自信ではなく、実際の動作を評価します
ブログが挙げる5つの考え方
- ▸1. 推論と計算を分ける。言語モデルはあいまいさを扱うのに向き、決定論的なソフトは精度が要る仕事に向く。「テストで確かめられる決定論的なアルゴリズムで書ける論理は、おそらくモデルの中に置くべきではない」
- ▸2. 決まった答えが要る問題には、決まった仕組みを使う。最適化・スケジューリング・資源配分・計算は、LLMに繰り返し考えさせず、既に確立した解法に任せる
- ▸3. コンテキストの管理を、信頼性の問題として扱う。指示や例が増えるほど、モデルの注意を奪い合います。「スキル」で指示を必要になるまで眠らせ、「サブエージェント」で専門の作業を親の文脈から切り離しました。ブログは、スキルは指示の関連性を、サブエージェントは文脈の分離を高める、と書いています
- ▸4. 検証を構成に組み込む。レビュー役のエージェントを足したが、「説明は証拠ではない」。ときどき間違いを見つけたものの、本番インフラに必要な保証にはならなかった。ビルドやCIなどの決定論的な検査を階層にして、客観的な検証で正しいと確認できたときだけ成功とする
- ▸5. プロンプトではなく、まわりの仕組み（ハーネス）を直す。「この間違いを繰り返しにくくするには、何を変えればよいか」と問う。算術の間違いは、決定論的な計算が足りない合図で、文脈の混乱は、文脈の分離が足りない合図だとしています
数字の読み方（当サイトの見方）
- ▸「86%」は、成果ではなく、取り組む前の状態です。「コンテナの86%が、要求CPUの20%未満しか使っていない」は、なぜこの問題に取り組んだかを示す数字で、エージェントが減らした量ではありません
- ▸「数百万ドル」は、見込みです。ブログの表現は「潜在的な節約」で、実際に回収できた額は書かれていません
- ▸信頼性は「大きく改善した」とだけ書かれています。成功率やばらつきの数字は、ブログにありません
- ▸5つの考え方は、1つのシステムから得た教訓です。ブログ自身が、ほかの分野で検証したとは書いていません
確認できなかったこと
- ▸人間の承認の流れ。ブログには、PRを作るところまでが書かれていて、誰がPRを確認し、いつ本番へ反映するかは書かれていません
- ▸使っているモデルやエージェントの基盤。公表されていません
- ▸ソルバーの具体的な定式化と、その性能。「変数と目標」の説明にとどまります
- ▸実際に節約できた額・対象サービス数・失敗率などの成果。書かれていません（「数百万ドル規模の削減余地」という見込みだけが書かれています）
- ▸社内の他の用途に広げているか。ブログは触れていません
この事例から持ち帰れること（当サイトの見方）
- ▸「AIに任せる範囲」を分ける考え方は、ほかの業務にも使えます。あいまいな読み取りはAI、毎回同じ答えが要る計算や集計は従来のプログラム、というように、仕事の種類で担当を分けると、結果がぶれにくくなる、というのがブログの教えです
- ▸「AIが自分で確認しました」を、確認の根拠にしない。ブログは、AIに別のAIを見張らせるだけでは足りないと書いています。実際に動かして通るか（ビルド・テスト）という、機械的な確認を、最後の関門に置くと安心できます
- ▸失敗したら、まず指示文を足す前に、仕組みを見直す。指示を足し続けると、かえって管理できなくなる、という経験が書かれています
- ▸この事例だけでは、効果の大きさは分かりません。成果の数字が公表されていないので、自社に取り入れるときは、小さな範囲で試して、自分たちの数字で確かめるのが安全です