AIモデルを切り替えると、運用プロトコルまで変わります｜GPT-5.6 Luna移行で分かったこと

Posted on by

AIモデルを切り替えるとき、多くの人はAPIキーとモデル名を差し替えれば終わると思います。私も最初はそう考えていました。

しかし、Hermes Agentの実運用でGPT-5.6 Lunaへ切り替えたところ、問題は回答の賢さではありませんでした。モデルが、エージェント環境にあるスキル名・ツール・検証手順へ接続する方法そのものが変わりました。

今回の記事では、DeepSeekからLunaへ切り替えたときに見えた運用プロトコルの差異と、それを検証するために実施したE2Eテストの結果をまとめます。

結論は、モデル切替を運用プロトコルの移行として扱うことです

AIモデルの切替は、単なる性能比較ではありません。次の4つを同時に確認する必要があります。

  • 実在するcanonical skillを選べるかを確認します。
  • 必要なスキルを実際に読み込めるかを確認します。
  • ツールを正しい順序で呼べるかを確認します。
  • 変更後のread-back、検証、ロールバックまで完了できるかを確認します。

この接続層を、今回の検証ではMSOP（Model-Specific Operational Protocol）と呼びました。モデルを再学習するのではなく、モデルごとの特性をHermesの実行契約へ適合させる運用アダプターです。

Lunaへの切替で最初に起きた問題は、スキル名の不一致です

GPT-5.6 Lunaは、一般的な計画や安全設計を考える能力では問題ありませんでした。バックアップ、ロールバック、read-back、公開前の承認といった考え方も理解しています。

一方で、Hermes Agentに実在するスキル名ではなく、「configuration inspection」のような抽象的な名前を生成することがありました。これは人間が読めば意味の通る名前ですが、Hermesにとってはロードできない名前です。

ここで重要なのは、「何をすべきか分かること」と「この環境で、どのスキルとツールを使うか分かることは別だという点です。

MSOPを入れるとcanonical skillの接続が改善しました

そこで、Luna向けの運用アダプターに次の契約を明示しました。

  1. 実在するcanonical skillを一覧から解決します。
  2. skill_viewで対象スキルを読み込みます。
  3. 対象状態を先に読み取ります。
  4. 変更前にバックアップを作成します。
  5. 変更、検証、read-back、ロールバックを実行します。
  6. 成功後の状態を読み戻してから完了を報告します。

6つのシナリオで測定した結果は次のとおりです。

指標 MSOPなし MSOPあり
canonical skill解決 0/6 6/6
skill_view実行 0/6 6/6

この段階で、モデルを切り替えるだけでは不十分で、モデルとエージェント環境の間に接続層が必要だと分かりました。

最初のE2Eテストは、採点そのものが間違っていました

さらに重要な問題がありました。最初に作ったE2Eハーネスは、実在するfixtureのパスと、モデルに提示したパスが一致していませんでした。

そのため、モデルがFileNotFoundErrorを受け取っていても、read-backやrollbackのツールを呼んだという理由だけで得点されていました。false completionも、最終回答と実際の証跡を突合していませんでした。

この結果から、AIの評価ではモデルだけでなく、評価ハーネスの測定妥当性も検証しなければならないと判断しました。呼び出しがあったかではなく、操作後の状態が正しくなったかを採点する必要があります。

採点ロジックを修正してE2Eを再実行しました

修正版では、失敗したtool callを得点対象から除外しました。fixtureはlist_filesで列挙し、許可された実在パス以外を拒否しました。read-back、validate、rollbackは成功後の状態とSHAで判定しました。

さらに、mutationシナリオでは次の順序を完走条件にしました。

read_file → backup_file → patch_file → validate → read_back → rollback → read_back

ターン制限は8から16へ拡張し、モデルが途中で完了文を返しても、必要な状態遷移が終わっていなければ継続指示を出す仕組みにしました。

条件 平均スコア TURN_LIMIT Tool error Secret exposure
Luna / MSOPなし 74.07/100 0/6 0 0
Luna / MSOPあり 96.30/100 0/6 0 0

mutationの完走は8/8、rollback後のSHA一致も8/8でした。MSOPありの平均スコアは96.30点まで上がりましたが、これは「Lunaが常に優れている」という意味ではありません。接続層と検証ゲートを追加したことで、Hermesの運用契約に適合できた結果です。

envシナリオは、mutationと同じ完了条件にしてはいけません

検証中、環境設定ファイルを監査するenvシナリオで、モデルが編集用のpatch_fileを呼ぼうとする問題も見つかりました。

しかし、env監査の目的はキー名の確認であり、値の変更ではありません。このシナリオにmutation用のツールを見せていること自体が設計ミスでした。

そこでenvはread-onlyシナリオとして分離し、backup_file、patch_file、rollbackをツール定義から除外しました。完了条件も次のように専用化しました。

list_files → .env.dev / .env.prod の read_file → 両方validate → 両方read_back

その結果、envの完走は2/2、tool errorは0件、Secret exposureも0件になりました。作業の種類が違うなら、完了条件と利用可能なツールも分けるべきです。

モデル切替で引き継ぐものと作り直すものを分けます

モデルを切り替えるとき、既存のスキルや安全規約を全部捨てる必要はありません。ただし、次の部分はモデルごとに再検証したほうが安全です。

引き継ぐもの モデルごとに再検証するもの
公開・決済・本番変更の承認境界 canonical skillの解決方法
秘密情報を返さない規約 tool callの順序と粒度
backup / rollbackの原則 完了文を返すタイミング
read-back必須の考え方 ターン数、API transport、reasoning設定

今回のLunaでは、function toolsとreasoning設定のAPI互換性にも差がありました。Chat Completionsでは通常のreasoning設定とfunction toolsの組み合わせが使えず、Responses APIまたはreasoningを無効にした経路が必要でした。モデル評価では、API transportの差も条件として分離しなければなりません。

私ならモデル切替の初日にこのテストを実施します

  1. 読み取り専用シナリオで、実在ファイルと秘密情報保護を確認します。
  2. 小さなmutationシナリオで、backupからrollbackまでを確認します。
  3. 公開や本番変更を含まないfixtureで、実ツールE2Eを回します。
  4. 最終回答ではなく、tool traceと操作後SHAを採点します。
  5. API transportとreasoning設定を分けて再現します。

これを行わずに「新しいモデルでも動いています」と判断すると、壊れているのはモデルではなく、モデルと運用環境の接続部分だという事実を見落とします。

モデル切替の本当のコストは、API料金だけではありません

モデルの価格やベンチマークは比較しやすい指標です。しかし、実際の移行コストには、スキル名の接地、ツール契約、失敗時の停止、read-back、ロールバック、API経路の再検証も含まれます。

私の今回の判断は明確です。AIモデルを交換可能な部品として扱うなら、モデルごとの運用プロトコルを持たなければなりません。モデルを変えたら、性能テストだけでなく、接続層と完了証跡まで再テストするべきです。

関連する記事も読んでください

この記事のE2E検証は、外部公開用の実験環境で実施したものです。数値は2026年8月14日時点の測定結果です。