2026年4月23日にTencentが公開したHy3 Previewは、総295B・活性21BのMoE構成、256Kコンテキスト、MTPを前提にした推論スタックで、コード実行系と検索系のエージェントで実運用を狙ったモデルである。特に注目すべきは、公開ベンチ上でのSWE-bench Verified 74.4（Hugging Faceの評価結果欄）と、Tencent側が示す推論効率40%改善、さらにCodeBuddy/WorkBuddy・元宝・腾讯文档への先行投入で示された運用指標である。本稿は「Tencent Hy3 使い方」を検索する実装担当者向けに、数値の読み方、コーディングエージェント実装、検索エージェント実装、コスト効率設計までを手順化して解説する。

Tencent Hy3の技術仕様を、実装に必要な粒度で固定する

最初に仕様を固定する。Hy3 Previewの公式モデルカード（2026年4月23日公開）に記載されている中核値は、ArchitectureがMoE、Total Parametersが295B、Activated Parametersが21B、Expertsが192でtop-8活性、Context Lengthが256K、MTP Layer Parametersが3.8Bである。推論設計の観点では、この「295Bを毎トークン使うモデルではない」という点が重要で、実際の計算コストとレイテンシ見積もりは21B活性を基準に組み立てるのが実務的である。

同時に、Hy3 Previewは単体モデルではなく、サービング設定と一体で性能を出す前提になっている。モデルカードのデプロイ例はvLLM/SGLangともに推測補助（MTPまたはEAGLE系）を有効化しており、OpenAI互換APIでの呼び出し時に推論努力量（reasoning_effort相当）を切り替える形を取っている。つまり、導入時の成功条件は「重みをロードすること」ではなく、「推測デコード・ツール呼び出しパーサ・思考モード切替の3点をサービングに埋め込むこと」である。

ここで実装担当が陥りやすい誤読は2つある。1つ目は、ベンチ値をそのままプロダクションSLAに読み替えること。2つ目は、MoEの総パラメータだけを見てGPU見積もりを過大化すること。前者は実タスク分布と評価セット分布の差を無視している。後者は活性パラメータ、KVキャッシュ、同時接続数、推測デコード有無の関係を無視している。Hy3の導入で成果を出すには、モデル評価と運用評価を分離し、前者は能力上限、後者は業務KPIで管理する設計に切り替える必要がある。

実装前チェックリストは以下である。第一に、利用する推論サーバ（vLLMかSGLang）でHy3向けのparserとspeculative設定が有効か。第二に、API呼び出しレイヤでタスク種別ごとのmode切替が可能か。第三に、エージェントループ側でツール呼び出しログを収集し、成功率・再試行率・最終解決率を出せるか。第四に、256Kを前提とした長文投入時のトークン切り出し戦略（固定窓・再ランキング・圧縮）を定義しているか。ここまで揃って初めて、Hy3を「使った」状態ではなく「運用できる」状態になる。

SWE-bench Verified 74.4%をどう実装判断に落とすか

Hy3 Previewの評価については、数値の出どころを分けて読むべきである。Hugging Faceの評価欄ではSWE-bench Verified Resolvedが74.4、Terminal-Bench 2.0が54.4として表示される。一方、README本文ではSWE-bench VerifiedやBrowseCompで競争力があると述べられているが、個別値の多くは図表ベースで提示される。したがって、運用設計で確実に参照可能なのは「公開評価欄の指標」と「公式文面の主張」の組み合わせである。

比較対象としてよく挙がるClaude Opus 4.6については、AnthropicのSystem Card（2026年版）にSWE-bench Verified 80.8という表記がある。よって、単純比較ではHy3 74.4とOpus 4.6 80.8には6.4ポイント差がある。ここでの実務上の結論は「Hy3は追随圏にあるが、最高精度一本勝負ではまだ差がある」という整理になる。ただし、同じSystem Cardには試行回数や設定条件の注記があり、SWE-bench系はプロンプトと実行設定でブレが出る。したがって採用判断は、必ず自社リポジトリ群で再評価してから行うべきである。

SWE-bench VerifiedはOpenAIが公開した説明にもある通り、可解性検証済みの500課題で構成される。つまり、難問を解いたかどうかだけではなく、再現可能な修正手順を安定して実行できるかを問うベンチである。エンタープライズ導入で有効なのは、SWE-benchのスコアそのものより「内部課題セットに対して、同等の測定系を作れるか」である。具体的には、社内バグチケットを匿名化した100〜300件の固定セットを用意し、成功率、1件あたり実行コスト、修正までの時間、ロールバック率を計測する。

推奨する評価設計は4段階である。第1段階で単体タスク精度を測る。第2段階でIDE/CLI/MCP連携を有効化した実行成功率を測る。第3段階でレビュー通過率と回帰発生率を測る。第4段階で本番影響（MTTR短縮、レビュー待ち時間短縮、開発者満足度）を測る。この4段階を通すと、SWE-bench 74.4という外部指標を、自社の採用可否に変換できる。ここを省くと、ベンチで強いのに現場では使われない、典型的な導入失敗に入る。

コーディングエージェント実装パターン：MoEを活かすオーケストレーション

Hy3をコーディング用途で使うときの核心は、モデルに全処理を一任しないことである。MoEモデルの強みは、適切なタスク分解と十分なツール観測があるときに伸びる。実装パターンとしては、Planner・Coder・Verifierの3層分離が安定しやすい。Plannerは課題分解、Coderは修正生成、Verifierはテスト・静的解析・差分検証を担当し、各層でプロンプト責務を限定する。これにより、長い一発回答よりも再現性が上がる。

最小構成の手順は次の通りである。1) vLLMまたはSGLangでHy3 APIを立てる。2) 既存CIのテスト実行をMCPまたはコマンドツールとして接続する。3) エージェントに「まず再現テストを書いてから修正する」手順を強制する。4) 失敗時はreasoning_effortを段階的に上げる。5) 最終出力をPRテンプレートへ自動整形する。特に4)はコストに効く。常時高思考で回すより、低思考で一次解を作り、失敗ケースだけ高思考に昇格させる方が総コストを抑えやすい。

参考実装（概念）は以下である。

# vLLM (Hy3 preview) 起動例
vllm serve tencent/Hy3-preview \
  --tensor-parallel-size 8 \
  --speculative-config.method mtp \
  --speculative-config.num_speculative_tokens 1 \
  --tool-call-parser hy_v3 \
  --reasoning-parser hy_v3 \
  --enable-auto-tool-choice \
  --served-model-name hy3-preview
# タスク難度で思考モードを切替える簡易例
mode = "no_think"
if task.is_multi_file_fix or task.failed_once:
    mode = "high"

resp = client.chat.completions.create(
    model="hy3-preview",
    messages=messages,
    extra_body={"chat_template_kwargs": {"reasoning_effort": mode}}
)

運用上の勘所は、エージェントの行動上限を先に設計することだ。例えば「同一ファイルへの連続書換えは3回まで」「外部依存追加は明示許可がある時だけ」「テスト失敗時は原因分類を返す」などの制約を入れると、暴走を抑えながら改善速度を維持できる。Tencent側が示すWorkBuddy系の長手順ワークフロー実績は、こうした制約付きループ設計と相性がよい。モデルの賢さより、制御可能性を先に設計した方が、結果として実運用成功率が高くなる。

検索エージェント実装パターン：BrowseComp系タスクで失敗を減らす

BrowseCompは、OpenAIが公開した「Webを実際に辿って答えを作る能力」を測るベンチである。検索エージェントにおける失敗の本質は、推論力不足よりも「探索の打ち切りが早い」「根拠リンクを比較しない」「最新性確認をしない」の3点にある。Hy3のような長文保持が強いモデルでは、探索ログと根拠文書を並列保持できるため、検索経路の自己修正を実装しやすい。

実装手順は5ステップで設計する。第一に、検索クエリを1本ではなく3本生成し、異なる観点（公式、技術解説、第三者評価）を強制する。第二に、各結果から要点抽出時に発行日と更新日を必須フィールド化する。第三に、矛盾検知フェーズを入れ、数値が一致しない場合は追加探索へ戻す。第四に、最終回答では「確定情報」「企業自己申告」「未検証」を分離表示する。第五に、リンク切れと404を再試行する。これだけで、検索型エージェントの誤答率は目に見えて下がる。

Hy3導入時の実装ポイントは、256Kコンテキストを乱用しないことである。全文詰め込みは簡単だが、不要トークンが増えて推論効率を下げる。推奨は「短要約 + 出典URL + 必要抜粋」の3層格納で、最終回答直前にのみ詳細抜粋を展開する方式だ。これにより、モデルが参照すべき根拠が明確になり、ハルシネーション検知も実装しやすくなる。

Tencentの公開記事では、元宝/imaや腾讯文档AI PPTでの改善指標が示されている。これを自社検索エージェントへ転用する場合は、「回答精度」だけでなく「初回トークン遅延」「完了時間」「再質問率」を同時管理することが重要である。検索エージェントはユーザー体感が支配的であり、精度が同程度なら体感速度の良い方が継続利用されるからだ。したがって、BrowseComp系能力を活かす設計は、精度最適化と同時にUI待ち時間最適化を行う二軸設計であるべきだ。

40%効率化を前提にしたエンタープライズ導入とコスト設計

Tencent Cloud開発者コミュニティの記事では、Hy3 Previewで推論効率40%改善という主張が示されている。これは公式財務資料ではなく製品紹介記事ベースの数値であるため、導入時は「前提仮説」として扱うのが妥当である。実務では、この40%をそのまま予算に反映せず、保守的に15〜25%の改善を初期仮定に置き、実測で上振れを回収する設計が安全である。

コスト最適化は、モデル単価よりトークン設計が効く。具体的には、1) ルーティングで難問だけHy3に送る、2) 低難度は軽量モデルへ分流する、3) キャッシュヒット率を上げる、4) 長文を段階圧縮する、5) 再試行条件を厳格化する、の5点である。特にコーディングエージェントは同一ファイルを何度も読むため、差分キャッシュを導入すると入力トークンを大きく圧縮できる。

導入ロードマップは90日を1サイクルにすると運用しやすい。Day 1-14でPoC環境と評価セットを整備、Day 15-45でコーディング/検索それぞれの最小実装を本番類似データで検証、Day 46-75でガードレールと監査ログを実装、Day 76-90で対象部署を限定して段階公開する。各フェーズのゲートは「精度」「速度」「コスト」「安全性」の4指標で統一し、いずれかが閾値未達なら公開範囲を拡大しない。この統制がないと、短期的なデモ成功が長期運用失敗へ直結する。

最後に比較軸を整理する。Hy3の価値は、最高スコア単独で勝つことより、MoE効率とエージェント指向設計を使って、業務フロー全体のスループットを上げる点にある。SWE-benchで上位モデルとの差が残っていても、タスク分解、思考モード切替、キャッシュ戦略、ツール統合を適切に実装すれば、実運用ROIで逆転する余地は十分にある。導入責任者が見るべきは、単発ベンチ順位ではなく「1か月後に何件の業務を安定自動化できるか」という実務KPIである。

FAQ

Tencent Hy3 使い方の最短ルートは何か

最短ルートは、Hy3をvLLMまたはSGLangでOpenAI互換APIとして立ち上げ、既存のエージェント実行基盤からモデル差し替えで検証する方法である。最初から大規模移行せず、バグ修正や調査回答など評価しやすい業務に限定してA/B比較を行うと、導入可否を2〜4週間で判断しやすい。

MoEモデル実装で最初に気を付ける点は何か

総パラメータではなく活性パラメータでコストを見積もることが重要である。Hy3は295Bだが毎トークンで活性なのは21Bであり、サービング設定とバッチ設計次第で実効コストが大きく変わる。さらに、推測デコードやキャッシュ戦略を有効化しないと、MoEの効率メリットを取り逃しやすい。

74.4%というSWE-bench値はそのまま信頼してよいか

参考値として有用だが、そのまま自社本番性能とはみなさない方がよい。SWE-bench Verifiedは公開ベンチとして比較価値が高い一方、実行環境やプロンプト方針で結果が変動する。自社リポジトリを使った固定評価セットを作り、成功率とコストを同時に比較して採用判断するのが実務的である。

検索エージェントでBrowseComp系能力を活かすには

単発検索ではなく多経路探索を前提に設計することが有効である。公式情報、技術文書、第三者分析を分離して収集し、日付と出典の突合を行う。最終回答では確定情報と企業自己申告を分けて提示すると、利用者の誤解を抑えながら意思決定に使える回答になる。

エンタープライズ導入で最も失敗しやすいポイントは何か

ベンチマーク順位だけで導入を決めることが最大の失敗要因である。実運用では、再試行回数、監査ログ、セキュリティ制約、レビュー体制まで含めた運用設計が必要になる。モデル性能と同時に、制御可能性と監査可能性を満たす実装にしないと、短期導入はできても継続運用で止まる。

参考文献