https://thedotnetblog.com/ja/tags/evaluations/Articles, tutorials and insights from the .NET community.Hugoja@thedotnetblog (The .NET Blog)@thedotnetblogFri, 29 May 2026 00:00:00 +0000https://thedotnetblog.com/ja/news/emiliano-montesdeoca/model-router-evals-before-you-trust-the-routing/Fri, 29 May 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ja/news/emiliano-montesdeoca/model-router-evals-before-you-trust-the-routing/Foundry の新しい model router evaluation repo は、ルーティングの判断を自動モデル選択を魔法のように扱う前に、品質、レイテンシ、コストと照らし合わせて測定する必要があるため重要です。<blockquote> <p><em>この記事は自動翻訳されています。原文は<a href="https://thedotnetblog.com/ja/news/emiliano-montesdeoca/model-router-evals-before-you-trust-the-routing/">こちら</a>をご覧ください。</em></p> </blockquote> <p>自動モデルルーティングは素晴らしく聞こえますが、自分の workload に対して本当に正しい選択であることを証明しなければならない時点で、その印象は変わります。</p> <p>だからこそ、新しい <strong>model router evaluation repo</strong> は役に立ちます。</p> <p>これは、実際に重要な問いに対して、チームがより具体的に答える方法を与えてくれます。</p> <ul> <li>ルーティングは品質を保てるのか？</li> <li>コストは下がるのか？</li> <li>レイテンシにはどう影響するのか？</li> <li>model subset を制限したら何が変わるのか？</li> </ul> <h2 id="元の記事は正しい問いを投げかけている">元の記事は正しい問いを投げかけている</h2> <p>元の投稿で特に良いと思うのは、model router を当然に良いものとして扱っていない点です。</p> <p>その代わりに、気まずいけれど正しい問いを投げかけています。</p> <ul> <li>&ldquo;<strong>自分の prompts に対して、model router が自動選択した model は、私なら他に選ぶであろう single model と同等か、それ以上か？</strong>&rdquo;</li> <li>&ldquo;<strong>本当に end to end でコストを節約できているのか、それとも単に支出を別の場所へ移しているだけなのか？</strong>&rdquo;</li> </ul> <p>これこそが正しい姿勢です。</p> <p>自動ルーティングは魅力的ですが、それでも system decision であることに変わりはありません。そして system decision は、賞賛するのではなく測定すべきです。</p> <h2 id="この-repo-が見た目以上に重要な理由">この repo が見た目以上に重要な理由</h2> <p>一つの見方をすれば、これは単なる evaluation repo です。</p> <p>しかし別の見方をすれば、これは成熟のサインです。</p> <p>つまり、もし自動ルーティングを採用したいなら、次の点をより規律ある方法でテストできるということです。</p> <ul> <li>品質</li> <li>コスト</li> <li>レイテンシ</li> <li>subset のトレードオフ</li> <li>model distribution の挙動</li> </ul> <p>それは、見栄えの良い branding を持つ black box として routing を扱うより、はるかに良い方法です。</p> <h2 id="私の見解">私の見解</h2> <p>これは、AI platform がもっと必要としている種類の tooling の良い例です。もっと magic を増やすのではなく、信頼する前にその magic を検証する方法を増やすことです。</p> <p>それが、チームが未検証の前提の上に高くつく confidence を積み上げるのを避ける方法です。</p> <p>元の記事: <a href="https://devblogs.microsoft.com/foundry/how-to-run-evals-for-model-router/">How to run evals for the model router</a></p>https://thedotnetblog.com/ja/news/emiliano-montesdeoca/foundry-managing-models-cost-quality-developer-guide/Tue, 26 May 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ja/news/emiliano-montesdeoca/foundry-managing-models-cost-quality-developer-guide/新しい Foundry ガイドは、モデル選定、コスト管理、評価、ライフサイクル管理が、今や本番 AI システムにおける本当の差別化要因だと強く主張している。<blockquote> <p><em>この記事は自動翻訳されています。原文は、<a href="https://thedotnetblog.com/ja/news/emiliano-montesdeoca/foundry-managing-models-cost-quality-developer-guide/">こちらをクリック</a>してください。</em></p> </blockquote> <p>強力なモデルにアクセスできるだけでは十分であった時代は、もう過ぎました。</p> <p>この新しい <strong>Foundry のモデル・コスト・品質管理ガイド</strong> は、まさにその点を正しく捉えています。</p> <p>今の本当の課題は運用面です。</p> <ul> <li>ワークロードごとに適切なモデルを選ぶ</li> <li>自分たちのデータで検証する</li> <li>レイテンシとコストを管理する</li> <li>アップグレードと回帰リスクを統制する</li> </ul> <p>本気のチームが得意にしなければならないのは、まさにこれです。</p> <h2 id="元の記事は問題を正しく定義している">元の記事は問題を正しく定義している</h2> <p>元記事のこの一文が、この変化をとてもよく表しています。</p> <blockquote> <p>&ldquo;<strong>今日の AI システム構築で最も難しいのは、もはや優れたモデルにアクセスすることではありません。実際のアプリケーションのライフサイクル全体を通して、適切なモデルを選び、検証し、最適化し、運用する方法を知ることです。</strong>&rdquo;</p> </blockquote> <p>これはまさに正しい診断です。</p> <p>今でも多くのチームは、モデル選定こそが主な決定だと思っています。</p> <p>違います。</p> <p>より大きい問題はモデル運用です。</p> <ul> <li>どのワークロードにどのモデルを割り当てるのか？</li> <li>品質はどう検証するのか？</li> <li>どの程度のコストが許容されるのか？</li> <li>新しいモデルが出た時、あるいは古いモデルが劣化した時、何が起きるのか？</li> <li>本番ワークフローを壊さずに変更をどうテストするのか？</li> </ul> <p>今まさに本当のエンジニアリング作業はそこです。</p> <h2 id="この-foundry-記事が役立つ理由">この Foundry 記事が役立つ理由</h2> <p>この文章が好きなのは、経験豊富なプラットフォームエンジニアが実際に考えなければならないように、AI システムを語っているからです。</p> <p>「いちばん賢いモデルを選んで終わり」ではありません。</p> <p>能力、レイテンシ、コスト、安全性、ガバナンス、アップグレード圧力といったトレードオフの中で生きるシステムとして扱っています。</p> <p>それはベンチマーク頼みの楽観論よりずっと有益です。</p> <h2 id="最も重要な変化は基準を先に考えること">最も重要な変化は、基準を先に考えること</h2> <p>元記事は、モデルカタログを開く前に成功基準を定義するよう勧めています。</p> <p>これはチームが身につけるべき最も重要な習慣の 1 つだと思います。</p> <p>先にカタログを開くと、評価軸は評判に引っ張られます。</p> <p>先に基準を定義すると、評価軸はワークロードの現実に引っ張られます。</p> <p>そのほうが健全です。</p> <p>なぜなら、ベンチマークで勝つモデルが必ずしも勝つとは限らないからです。</p> <ul> <li>あなたのプロンプトで</li> <li>あなたのレイテンシ予算で</li> <li>あなたのコストガードレールの内側で</li> <li>あなたのガバナンス要件で</li> </ul> <p>その違いこそが、成熟した AI エンジニアリングの始まりです。</p> <h2 id="マルチモデルの物語が本当の利点になりつつある">マルチモデルの物語が本当の利点になりつつある</h2> <p>もう 1 つ好きなのは、モデルに依存しない姿勢です。</p> <p>この記事は Foundry を単一モデルの行き先としてではなく、次のものをまたぐ運用面の表面として提示しています。</p> <ul> <li>Microsoft のモデル</li> <li>パートナーモデル</li> <li>オープンソースモデル</li> <li>後学習済みバリエーション</li> <li>ルーティングと最適化戦略</li> </ul> <p>これは重要です。モデルの柔軟性はもはや贅沢ではありません。リスク管理の一部です。</p> <p>品質が変わり、価格が動き、クォータが制限されれば、チームには選択肢が必要です。</p> <h2 id="コスト管理は副次的な問題ではない">コスト管理は副次的な問題ではない</h2> <p>この記事が、コストをアーキテクチャ上の問題として捉えているのも正しいです。</p> <p>これは「後で最適化する」問題ではありません。</p> <p>すべてのタスクをデフォルトで最も重いモデルに送れば、デモでは素晴らしく動くかもしれませんが、本番の経済性の前では崩れます。</p> <p>だからこそ、次のような項目のほうが多くの人が思う以上に重要です。</p> <ul> <li>ルーティング</li> <li>バッチ処理</li> <li>キャッシュ</li> <li>プロビジョンドスループット</li> <li>クォータ管理</li> </ul> <p>コスト規律をシステム設計の一部として扱うチームのほうが、後片付けとして扱うチームよりずっと長持ちします。</p> <h2 id="私の見解">私の見解</h2> <p>この Foundry 記事は、経験豊富なエンジニアが実際に運用しなければならない形で AI システムを語っているので有用です。</p> <p>デモとしてではなく。 単発のプロトタイプとしてでもなく。 ベンチマーク巡りとしてでもなく。</p> <p>ワークロード、制約、トレードオフ、継続的な変化のためのオペレーティングシステムとして扱っています。</p> <p>そのレベルの会話へ進み続ける必要があります。</p> <p>本番 AI システムを構築しているなら、チームが早い段階で内面化してほしいのはまさにこの考え方です。</p> <p>元の記事: <a href="https://devblogs.microsoft.com/foundry/build-2026-foundry-models/">A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry</a></p>https://thedotnetblog.com/ja/news/emiliano-montesdeoca/foundry-observability-to-roi-agent-devops-loop/Mon, 25 May 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ja/news/emiliano-montesdeoca/foundry-observability-to-roi-agent-devops-loop/Foundry の最新の observability 発表が重要なのは、tracing、evaluation、optimization、ROI を AI agents のための 1 つの運用ループに結びつけているからだ。<blockquote> <p><em>この記事は自動翻訳されています。原文は、<a href="https://thedotnetblog.com/ja/news/emiliano-montesdeoca/foundry-observability-to-roi-agent-devops-loop/">こちらをクリック</a>してください。</em></p> </blockquote> <p>AI エージェントが本番で動くなら、可観測性はログとトレースだけで終わってはいけない。</p> <p>だからこそ、Foundry の新しい observability-to-ROI の話は重要に感じる。</p> <p>本当のメッセージは「ダッシュボードを増やしました」ではない。</p> <p>本当のメッセージは、本格的なエージェント・プラットフォームには継続的な運用ループが必要だということだ。</p> <ul> <li>何が起きたかを追跡する</li> <li>それが良かったかを評価する</li> <li>手を入れるべきところを最適化する</li> <li>結果をビジネス価値に結びつける</li> </ul> <p>これは、よくあるプラットフォームの曖昧な説明よりずっと強いメッセージだ。</p> <h2 id="元記事の重要な一文がすべてを語っている">元記事の重要な一文がすべてを語っている</h2> <p>原文は、エージェントを作るすべてのチームが注目すべき一文から始まる。</p> <blockquote> <p>&ldquo;AI エージェントを出荷するのは簡単です。本番で正確で、安全で、説明責任を果たせる状態に保つところで、チームは行き詰まります。&rdquo;</p> </blockquote> <p>まさにその通りだ。</p> <p>もう、「エージェントに面白いことをさせられるか？」が主な問いだった段階は過ぎた。</p> <p>より難しく、より価値のある問いは、</p> <p><strong>実際のユーザー、実際のツール、実際のコストとやり取りし始めたあとに、その仕組みを運用できるか？</strong></p> <p>ということだ。</p> <p>Foundry はまさにその会話を前に進めようとしている。</p> <h2 id="これが別のエージェントデモより重要な理由">これが、別のエージェントデモより重要な理由</h2> <p>多くの AI エージェント発表は今でも、作成に焦点を当てている。エージェントを作り、ツールをつなぎ、タスクを振り分け、UI を公開する。</p> <p>それはそれで良い。</p> <p>だが、運用上の問いこそが、多くの本格的なシステムを持続可能にするか、高いコストの実験にしてしまうかを分ける。</p> <ul> <li>本番でエージェントは実際に何をしているのか？</li> <li>正しいことをしたのか？</li> <li>時間とともに悪化していないか？</li> <li>それが生み出す価値に対して高すぎないか？</li> <li>どの設定変更が本当に品質を改善したのか？</li> </ul> <p>だからこそ、Foundry の発表は典型的な機能まとめより重要だと思う。単なるエージェント作成の話ではなく、Agent DevOps ループを定義しようとしているからだ。</p> <h2 id="4-つのループこそが本当の製品">4 つのループこそが本当の製品</h2> <p>この記事は、実質的にプラットフォームを 4 つの能力で整理している。</p> <ul> <li>Trace</li> <li>Evaluate</li> <li>Monitor</li> <li>Optimize</li> </ul> <p>これが正しい形だ。</p> <p>本番のエージェントワークロードで真剣に扱われたいプラットフォームなら、最終的にはこの 4 つすべてが必要になると私は思う。</p> <p>トレースだけでは足りない。</p> <p>評価だけでも足りない。</p> <p>証拠のない最適化は、ただの当てずっぽうだ。</p> <p>そして telemetry なしの ROI 論は、たいてい見せ物にすぎない。</p> <h2 id="相互運用性の観点は特に賢い">相互運用性の観点は特に賢い</h2> <p>発表の強みのひとつは、Foundry が「すべてのエージェントが 1 つのフレームワークで作られる」とは装っていないことだ。</p> <p>原文では、トレースと評価が次の範囲に広がることを明示している。</p> <ul> <li>LangChain</li> <li>LangGraph</li> <li>OpenAI SDK</li> <li>Microsoft Agent Framework</li> <li>OpenTelemetry 経由のカスタムフレームワーク</li> </ul> <p>これは重要だ。</p> <p>プラットフォーム lock-in は、もともと有用だった運用ストーリーを一気に魅力のないものにしてしまう最短ルートのひとつだからだ。</p> <p>チームがフレームワークの選択を維持しながら、それでも本番レベルの telemetry と評価面を得られるなら、摩擦はかなり減る。</p> <h2 id="ルーブリック評価は思った以上に重要になるかもしれない">ルーブリック評価は、思った以上に重要になるかもしれない</h2> <p>ルーブリック評価の部分も強調したい。</p> <p>これは記事全体で最も実用的な追加機能のひとつだと思う。</p> <p>なぜか。good の定義は文脈依存だからだ。</p> <p>この記事は、ルーブリック評価が「エージェントの意図した振る舞いから文脈を踏まえた評価基準を生成する」と述べている。まさにこういう方向が必要だ。</p> <p>一般的な品質スコアリングも役に立つ。</p> <p>しかし最終的には、チームは自分たちの基準でエージェントを評価しなければならない。</p> <ul> <li>トーン</li> <li>タスク完了</li> <li>ポリシー順守</li> <li>レイテンシの期待値</li> <li>コストの境界</li> <li>ドメイン固有の業務ルール</li> </ul> <p>評価が、学術的に面白いものから、運用上意味のあるものへ変わるのはここだ。</p> <h2 id="roi-が一番居心地の悪い部分だがだからこそ重要">ROI が一番居心地の悪い部分だが、だからこそ重要</h2> <p>発表の ROI 部分が重要だと思うのも、まさにそこが居心地の悪い問いだからだ。</p> <p>原文は直接こう問う。</p> <blockquote> <p>&ldquo;このエージェントは、そのコストに見合うのか？&rdquo;</p> </blockquote> <p>この質問は AI の会話でよく避けられる。</p> <p>だが、正しい質問だ。</p> <p>プラットフォームが cost、task completion、削減できた時間、production traces を本当に 1 か所で結びつけられるなら、エンジニアリングとリーダーシップにとって、はるかに良い共通言語になる。</p> <p>正直に言って、その共通言語はかなり必要とされている。</p> <h2 id="私の見解">私の見解</h2> <p>これはバッチの中でも優れたプラットフォームレベルの発表のひとつだ。エージェントを作ることではなく、運用することに焦点を当てているからだ。</p> <p>そして、難しい仕事はそこから本当に始まる。</p> <p>今後 2 年の強い AI プラットフォームは、より多くの models やより多くの demos にアクセスできるものではない。チームが振る舞いを追跡し、結果を評価し、安全に最適化し、証拠をもってコストを正当化できるようにするものだ。</p> <p>Foundry のこの話は、まさにその方向へ進もうとしている。</p> <p>だからこそ、真剣に受け止める価値がある。</p> <p>原文: <a href="https://devblogs.microsoft.com/foundry/build-2026-from-observability-to-roi-for-ai-agents-on-any-framework/">Build 2026: From observability to ROI for AI agents on any framework</a></p>