はじめに

watsonx Orchestrate のエージェントで選べるモデルに watsonx-orchestrate/frontier が加わりました（以降"frontier"）。これまで実質 gpt-oss-120b 一択だったところに、もう一つの選択肢が来たことになります。

本記事では、この2つを実際に動かして比べた結果を書きます。検証は2026年9月時点のものです。仕様は変わりうるので、最新の情報はドキュメントを確認してください。

先に結論を書いておきます。

日本語の処理は frontier が明確に上
同じ入力に対する出力の安定性も frontier が上
RAG で「ナレッジベースに答えがない」ときに、frontier は「ない」と答え、gpt-oss は答えを作ってしまう
ただし frontier は指示の範囲を超えて情報を足す傾向があり、厳密な定型出力を求める用途では注意が要る

最後の点も含めて、正直に書きます。

1. どんなモデルなのか

ADK から一覧を取ると、こう表示されます。

$ orchestrate models list

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Mode                    　         ┃ Description                             ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ ✔★ groq/openai/gpt-oss-120b       │ openai/gpt-oss-120b is an OpenAI's ...  │
├────────────────────────────────────┼─────────────────────────────────────────┤
│ ★ bedrock/openai.gpt-oss-120b-1:0 │ openai/gpt-oss-120b is an OpenAI's ...  │
├────────────────────────────────────┼─────────────────────────────────────────┤
│ ★ watsonx-orchestrate/frontier    │ An AI model designed for advanced       │
│                                    │ reasoning, tool calling, and agentic    │
│                                    │ orchestration across enterprise ...     │
└────────────────────────────────────┴─────────────────────────────────────────┘

                    ✔ indicates the default model
             ★ indicates a supported and preferred model
              ◆ indicates a model from a custom provider
            ✖ indicates a model disallowed by tenant admin
                     $ indicates a premier model

この凡例、意外と情報量があります。frontier に付いているのは ★ だけなので、

$ が付かない → premier モデルではない。追加課金（MAU）の対象外
◆ が付かない → AI Gateway 経由で登録した virtual model ではなく、プラットフォーム組み込み
✔ は Groq 版の gpt-oss-120b に付いており、こちらが既定のまま

ということが読み取れます。

エージェント定義の YAML では、こう指定します。

kind: native
name: my_agent
llm: watsonx-orchestrate/frontier
style: react_core

UI 上の表示は「Watsonx Orchestrate Frontier」です。

実体は公開されていない

本モデルは Public preview として提供されています。仕様や利用可能なリージョンについては Available AI models に記載があります。ただし Creator と Providers はいずれも「Third party」とだけ書かれており、具体的な開発元やモデル名は公開されていません。

気づいた方もいると思いますが、他のモデルが プロバイダー/開発元/モデルID という形式なのに対し、frontier だけ watsonx-orchestrate/frontier という命名です。説明文にも開発元やモデル名が出てきません。gpt-oss-120b の説明には「OpenAI のオープンウェイトモデル」と明記されているのと対照的です。

試しにエージェントに直接聞いてみると、Anthropic の Claude であると答えます。

私はAnthropicが開発したClaudeというAIアシスタントです。具体的なモデルのバージョンについては、把握していません。

5回試して5回ともこの形でした。毎回「バージョンは分からない」と添えてきます。知識のカットオフを聞いても「2025年初め頃までの情報を持っていますが、正確な日付については確信が持てない」と、同じく留保付きでした。

ただし、モデルの自己申告は根拠になりません。同じ質問を gpt-oss-120b に投げるとこうなります。

私はOpenAIが提供するChatGPTです。使用しているモデルは GPT-4（具体的には GPT-4 turbo）です。

こちらも5回とも断定でした。回によって GPT-4 turbo だったり ChatGPT 4 だったりと細部はブレるのですが、断定の姿勢だけは一貫しています。もちろん gpt-oss-120b は GPT-4 ではありません。

使い始める前に

ADK が古いと、エージェントの export で落ちることがあります。

pip install -U ibm-watsonx-orchestrate

で解消します。しばらく触っていなかった方は、まずこれを。

2. 検証環境：フローの「生成プロンプト」ノードが便利

モデルの素の挙動を比べるなら、エージェント型ワークフローの生成プロンプトノードが使いやすいです。

理由は3つあります。

フローを組まなくても「プレビューの生成」で実行できる。エージェントを何本も作って後片付けする必要がない
システムプロンプトとユーザープロンプトが分離しているので、何を渡したかが明確
「LLM設定を調整」タブで温度・top_K・top_P を指定できる（エージェント側では触れません）

モデルの選択肢もエージェントより多く、gpt-oss-120b 2種と frontier に加えて、granite-3-1-8b-base、granite-4-h-small、llama-3-3-70b-instruct、llama-4-maverick、mistral-large-2512 などが並びます。

以下の検証は、すべてパラメータ既定値のまま、「例を追加」タブは未使用（few-shot なし）で行いました。指示だけでどう振る舞うかを見たいためです。

3. 日本語で比べる

3-1. 敬語のビジネスメール

システムプロンプト

あなたは日本企業の担当者として、取引先へのビジネスメールを作成します。
丁寧語・謙譲語・尊敬語を正しく使い分けてください。

ユーザープロンプト

以下の内容でメールを書いてください。

取引先の山田部長に、先週依頼された見積書の提出が来週火曜まで遅れることを伝える。
理由は社内の承認手続きに時間がかかっているため。
こちらの都合による遅延なので、その旨を明確に伝える。

gpt-oss-120b の出力には、はっきりした誤りが出ました。

山田部長　御中

御中は組織や部署に宛てるときの敬称で、個人には使いません。宛名を間違えるのは、業務メールとしてはかなり痛いところです。

他にも、定型句を文脈を見ずに並べる傾向がありました。

平素は格別のご高配を賜り、厚く御礼申し上げます。

文書の挨拶文で、メールの書き出しには過剰です。

引き続きご指導ご鞭撻のほど、よろしくお願い申し上げます。

年始や着任時の文言で、遅延のお詫びには合いません。

frontier は宛名も敬語の使い分けも問題なく、非の所在も明示しています。

今回の遅延は、ひとえに弊社内の手続き上の都合によるものであり、
山田部長をはじめ、貴社の皆様にご迷惑をおかけしますことを、深くお詫び申し上げます。

指示の3行目にきちんと対応しています。

ちなみに両モデルとも、頼んでいない【ポイント解説】という敬語の解説表を付けてきました。この点は後述します。

3-2. 同音異義語

ここが一番はっきり差が出ました。

システムプロンプト

日本語の文章を校正します。
カタカナで示された読みの箇所に、文脈に合う正しい漢字を当ててください。
出力は完成した文章のみ。解説や補足は一切付けないでください。

ユーザープロンプト

次の各文の「　」内をカタカナから漢字に直してください。

1. 会議の日程を「ハカル」ため、関係部署に意見を求めた。
2. 部品の寸法を「ハカル」。
3. 納期短縮を「ハカル」施策を検討する。
4. 所要時間を「ハカル」。
5. 売上を予算に「オサメル」。
6. 税金を「オサメル」。
7. 学問を「オサメル」。
8. 国を「オサメル」。
9. 契約書の内容を「アラタメル」。
10. 姿勢を「アラタメル」。

想定は、諮る／測る／図る／計る／収める／納める／修める／治める／改める／改めるです。

各モデル3回ずつ実行しました。割れた5問を並べます。

#	正解	gpt-oss 1回目	2回目	3回目	frontier（3回とも）
1	諮る	決定する	計画	計る	諮る
3	図る	図る	図る	測る	図る
4	計る	測る	計る	測る	計る
5	収める	合わせる	納める	納める	収める
7	修める	究める	修める	収める	修める

frontier は3回とも全問正解。しかも3回とも完全に同一の出力でした。1問目の「諮る」も取れています。

gpt-oss-120b は3回とも違う答えです。1問目に至っては「決定する」「計画」と、漢字を当てるのではなく語そのものを差し替えています。

正答数の差もさることながら、同じ入力・同じ設定で出力が安定するかどうかの差が大きいと感じました。業務で使うなら、平均点より再現性のほうが効きます。フローに組み込んで実行するたび結果が変わるのでは、検証もできません。

そして1回目の差し替えは、あとで出てくる RAG での挙動と同じ性質です。答えが定まらないとき、枠の外から持ってきて埋める。

3-3. 数値計算（ここは gpt-oss-120b が勝ちます）

一方的な記事にならないよう、逆の結果も書きます。

システムプロンプト

計算問題に回答します。
各問の答えのみを番号順に出力してください。計算過程や解説は付けないでください。

ユーザープロンプト

1. 税抜12,800円の商品を3個購入した。消費税10%を加えた支払総額は。
2. 定価8,000円の商品を15%引きで販売し、さらに会員割引で5%引きとした。最終価格は。
3. 月額49,800円のサービスを4月11日から4月30日まで利用した。日割り計算（30日、円未満切り捨て）での料金は。

計算精度は両モデルとも全問正解でした。2問目の割引の重ねがけ（15% と 5% を足して 20% 引きと誤り、6,400円と答えてしまうパターン）も、両方とも回避しています。

差が出たのは指示追従のほうです。

gpt-oss-120b（5回とも数値のみ、番号の付け方は回によって揺れました）

1. 42240 2. 6460 3. 33200

frontier（4回とも同一）

1. 12,800 × 3 × 1.1 = **42,240円**
2. 8,000 × 0.85 × 0.95 = **6,460円**
3. 49,800 × 20/30 = **33,200円**

「計算過程や解説は付けないでください」と指示しているので、frontier のこれは違反です。

	計算精度	「過程を書かない」指示	出力の安定性
gpt-oss-120b	全問正解	守る	番号の有無が揺れる
frontier	全問正解	破る	完全に一定

4. 本題：RAG で「ない」と言えるか

ここからが実務で一番効く差です。

ナレッジベースには「該当なし」が存在しない

RAG は常に上位N件を返します。関連度が低くても、何かしらのチャンクが返ってくる。つまり検索結果の中に「答えがない」という状態は、生成側が判断するしかありません。

QA サポート用のエージェントでこれが崩れると、ナレッジベースに書いていないことを、あたかも書いてあるかのように回答するという壊れ方をします。

そこで、実際に運用しているエージェントのナレッジベース（IBM PA / IBM Bob に関する問い合わせと回答を抽出したもの）で、両モデルを比較しました。

テストケースは3つのパターンに分けています。

パターン	内容
KB内	答えがKB(ナレッジベース）に載っている
KB外・明らかにない	答えも関連情報も載っていない
KB外・ギリギリない	答えは載っていないが、隣接する話題のQ&Aは載っている

結果から言うと、差が出たのは3つめのパターンだけでした。「明らかにない」質問では、両モデルとも正しく「該当情報がありません」と回答します。

以下、実際に起きた3つの失敗例を挙げます。いずれも gpt-oss-120b 側です。

例1: 触れられていない論点を創造する

質問

IBM Bob の Bobcoin には有効期限がありますか？未使用コインは翌年に繰り越せますか？

両モデルに渡された検索結果（完全に同一）

[
  {
    "title": "qa_xxxxxxxxxx_001.txt",
    "body": "Q: IBM Bob（Pooled Consumption）でOverageが発生した後に当月中に
             Bobcoinを補充した場合、既発生分に遡及充当されるか？
             A:
             - されない。既に発生しているOverageに遡及的にBobcoinを充当することはできない。
             - Overage発生前にBobcoinを補充した場合は、当月分の消費に充当される。
             - Bobcoinの消費前（Overage発生前）に追加購入を行うよう案内すること。"
  },
  {
    "title": "qa_xxxxxxxxxx_005.txt",
    "body": "Q: IBM BobのBobcoin利用上限設定の仕様はどうなっているか？
             A:
             - Bobの管理画面でチーム単位の利用上限設定が可能。
             - 上限に達した場合、全体のBobcoinが残っていてもそのチームでは利用できなくなる。
             - これは予期せぬ超過請求の発生を防ぐための機能。"
  }
]

どちらのチャンクにも、有効期限にも繰越にも一切触れていません。

gpt-oss-120b の回答

Bobcoin には有効期限は設定されておらず、未使用のコインは翌年へ繰り越すことができます。

frontier の回答

該当情報がありません。別途確認が必要です。

gpt-oss は、Bobcoin が「補充して消費される」「上限設定がある」という記述から、期限や繰越の話を作り出しています。関連するトピックではありますが、まったく別の論点です。

そして実際には繰り越せません。ナレッジベースに載っていないだけでなく、事実としても誤った回答です。断定的な文体で返ってくるため、読んだ担当者はそのまま顧客に伝えてしまうかもしれません。

この例は、両モデルに渡された検索結果が完全に同一という点で重要です。検索の精度の差ではなく、渡された材料から何を出力するかというモデルの振る舞いの差だと言い切れます。

例2: 別製品の記述を流用する（検索クエリからして違う）

質問

IBM Bob は1テナントに最大何ユーザーまで登録できますか？

この質問では、検索に使われたクエリ自体が違いました。

モデル	生成されたクエリ
gpt-oss-120b	`1テナント最大ユーザー登録`（1回のみ）
frontier	`IBM Bob テナント最大ユーザー数上限` `Bob テナントユーザー登録最大数制限`（2回）

gpt-oss のクエリには製品名が入っていません。その結果、返ってきたチャンクの1件目がこれでした。

Q: IBM Db2 Standard Edition AU Option の最小ユーザー数と
   1ライセンスあたりのユーザー数はどのくらいか？
A:
- 最低購入数は1ユーザーから。
- 1ライセンス（AU = Authorized User）につき1ユーザー分の権限付与となる。

IBM Db2 の話です。 そしてこれを踏まえた回答がこちら。

IBM Bob のライセンスは「Authorized User」方式です。1テナントに登録できるユーザー数に上限は設けられておらず、利用したい分だけライセンスを取得すれば登録可能です。

別製品のライセンス記述から、Bob のユーザー上限を組み立ててしまいました。

再実行したところ、今度は別のチャンク（管理者がユーザーIDを招待して購入したユーザー数まで追加できる、という追加手順の説明）が返り、そこから「1テナントの上限は購入したライセンス数まで」と断定しました。材料が変わっても、毎回何かを作ります。

frontier は製品名を含むクエリで2回検索した上で、「該当情報がありません」と回答しています。

例3: 文書の存在から内容を推定する

質問

IBM Bob Advanced Support には SLA 保証の応答時間（レスポンスタイム）の規定はありますか？

1回目の検索結果は両モデルで同一でした。関連するのはこのチャンクです。

Q: IBM Bob Service Level Agreement の内容が記載された書類はどこで確認できるか？
A:
- IBM BobのSLAはサービス記述書（SD）に記載されている。
- 英語版URL / 日本語版URL

書いてあるのは書類の所在だけで、その中身には触れていません。

gpt-oss-120b の回答

IBM Bob Advanced Support の SLA に関しては、SLA の内容が記載されたサービス記述書（SD）で
確認できます。SLA には応答時間（レスポンスタイム）に関する規定も含まれていますが、
具体的な時間はサービス記述書をご参照ください。

「文書が存在する」から「その中に応答時間の規定がある」を導いています。断定ではないぶん見逃しやすいのですが、ナレッジベースにない情報を示唆している点は同じです。

frontier は「該当情報がありません」と回答した上で、Bob Advanced Support 応答時間保証サポートプラン というクエリで2回目の検索をかけています。返ってきたのは Advanced Support の金額・按分に関するチャンクで、やはり応答時間の記述はなく、情報なしを維持しました。

失敗の型は3つ

整理すると、こうなります。

例	渡された材料	gpt-oss-120bの失敗の型
1	Bobcoin の遡及・上限設定	触れられていない論点を創造する
2	Db2 のライセンス、ユーザー追加手順	別製品・別論点の記述を流用する
3	SLA の記載場所	文書の存在から内容を推定する

共通しているのは、関連はあるが答えではない材料を渡されたとき、そこから何かを作ってしまうこと。そして frontier は、同じ材料から何も作りません。

同音異義語で gpt-oss が「ハカル」を「決定する」に置き換えたのと、同じ性質だと思います。答えが定まらないときに枠の外から埋める。RAG ではそれが誤った回答として表に出ます。

もうひとつ見逃せないのが、frontier が再検索をしている点です。1回引いて答えが見つからないと、言い換えて引き直してから答えている。例2と例3の両方で確認できました。検索の引き方の時点で既に違います。

5. frontier の癖：親切さが指示を超える

ここまで frontier を推す内容が続きましたが、弱点もあります。別々の題材で、同じ現象が繰り返し出ました。

敬語メール — 頼んでいない【ポイント解説】の表を付けてくる
計算問題 — 「過程を書くな」と指示したのに式を出力する
KB検証 — 「『該当情報がありません。別途確認が必要です。』とだけ回答してください」と指示したのに、前後に説明を足す

3つめの実例です。

検索結果を確認しましたが、認証情報の保存場所に関する具体的な情報は
ナレッジベースに記載されておりませんでした。

該当情報がありません。別途確認が必要です。

認証情報の保存場所については、製品Wの公式マニュアルやサポート窓口への
お問い合わせをお勧めいたします。

同じ条件で gpt-oss は、規定の一文だけを返しました。

判断そのものは frontier も正しいのです。「記載がない」と認識できている。ただ 「とだけ」という指示を守らない。

人が読むチャット画面なら、frontier の応答のほうが親切で分かりやすいでしょう。一方、フローで後段のノードに値を渡す、決められた文言を厳密に返させる、といった用途では扱いにくくなります。

なお、指示をシンプルにすると余計な付加は減る傾向がありました。手順の説明などを詳しく書き込むほど、それを踏まえて丁寧に報告しようとするようです。指示は短く書いたほうがよさそうです。

6. まとめ

観点	評価
日本語の正確さ（敬語・漢字）	frontier
出力の安定性・再現性	frontier
計算の精度	同等
余計な情報を足さない	gpt-oss-120b
RAG：検索結果に答えがないと判断できるか	frontier
RAG：検索結果にない情報を作らないか	frontier
RAG：答えが見つからないときの再検索	frontier （gptは1回で打ち切る）

業務エージェント、とくに RAG を使った問い合わせ対応では、frontier を選ぶ理由が明確にあります。「ナレッジベースに書いていないことを答えない」というのは、精度の一項目ではなく成立条件だからです。

一方で、出力に余計なものを混ぜたくない箇所では gpt-oss のほうが扱いやすいです。用途で選ぶ、という話になります。

最後に：モデルは告知なく変わる

以前、gpt-oss-120b を使っていたエージェントで、フローが渡した「応諾」という文字列が、チャット応答では「応答」と表示されるという事象がありました。文字化けだと判断して勝手に訂正したのだと思われます。法律用語がことごとく言い換えられました。

これは「ある日突然」始まりました。IBM のサポートに問い合わせたところ、外部提供のモデルについては内容の詳細を回答できない、という回答でした。

そして今回、同じ条件を再現しようと試みたのですが、再現しませんでした。法律用語を並べても、法律文書らしい文章に埋め込んでも、両モデルとも正しく透過します。

つまり groq/openai/gpt-oss-120b という、開発元もバージョンも明記された名前であっても、挙動が変わらない保証はないということです。原因がモデル側なのかプラットフォーム側なのかも、利用者からは分かりません。

だからこそ、自分で評価データセットを持っておくことをお勧めします。watsonx Orchestrate には Evaluate 機能がありますし、今回のような「答えがナレッジベースにない質問」を数問用意して定期的に流すだけでも、挙動の変化は検出できます。

今回の比較も、しばらく経てば結果が変わっているかもしれません。だからこそ、自分の手元で測れる状態にしておきたいところです。

（本記事は、執筆にあたり Anthropic Claude を利用し、その出力を参考にしています。）