TL;DR: 社内のマルチベンダーAI基盤にKimi K3が追加されたので、本番で使っているClaude(Fable 5)とChatGPT(Sol)に同じコードレビューを実際のdiffに対して回してみた。初回はKimi K3がいちばん弱く見えたが、条件を揃えようとするたびに新しい非対称が顔を出し、結局「完全に公平な比較」には最後まで届かなかった。それでも試行を重ねるにつれ、Kimi K3はFableと同じ根本原因に到達し、Fable・Solのどちらも挙げていなかった指摘まで加えた――ただし対照実験ではない、一連の試行から見えた結果に過ぎない。モデルの優劣の話ではなく、比較そのものがどれだけ難しいかという話として読んでもらいたい。
きっかけ
社内で運用している複数ベンダーのAI APIのラインナップに、Kimi K3が追加された(ai&の公式アナウンスより)。試しに、すでに本番運用しているClaude(Fable 5)とChatGPT(社内で運用しているエージェント環境が呼び出す、GPT-5.6ティアのひとつSol)に、同じコードレビュータスクを、実際の変更――新規のAPIクライアント2本とそのテストを追加するdiff――に対して流してみることにした。名前は出すが、競わせたいのは「どれが賢いか」ではなく、「比較する」という作業そのものだ。
ラウンド1: 条件が揃っていなかった
三者の出方は、それぞれに興味深いものだった。
Fableはファイル読み取りのフルアクセスを持ち、自発的に、インストール済みのサードパーティSDKの実体を調べに行った。diff内のテスト用モックではなく、SDKそのものを見に行ったのである。その結果、コードが読んでいるフィールド(obj.outputs)がSDKの実際のレスポンスモデルには存在しないと報告してきた(実際のフィールド名は別の名前だった)。この報告が正しければ、本番では成功・課金済みのバックグラウンドジョブが、静かに空のコンテンツを返し続けていた計算になる。既存テストが全パスしていたのは、モックが「開発者が思い描いたSDKの形」に寄せて書かれていたからだ、というのがFableの見立てだった。
ChatGPT(Sol)にも読み取り専用シェルはあったが、SDKまでは確認せず、diffの記述内でレビューを完結させた。API呼び出しが生のコンテンツをベンダー側のサーバーに残しうるというデータ保持・ポリシー上の指摘は本物だったが、SDK不整合のバグは見逃している。
Kimi K3は、ツールなしの素のAPI呼び出し――diffをプロンプトに貼っただけの条件だった。確認できる外部情報は何もない。それでも、diffの別箇所にあった.valueでのアンラップ処理から「このSDKはenum状のオブジェクトを返すことがありそうだ」と推測し、該当する関数のどこかが脆いのではないか、という仮説を、確認できていない旨の留保つきで返してきた。どのフィールドが壊れているのかの名指しは、さすがにできなかった。
ここで「Kimi K3は見劣りする」と切り捨ててよかったのだろうか。三者が「確認することを許された範囲」はまったく同じではなかった。ただし、これで判断力の差が無かったと言い切れるわけでもない。同じ条件でも結果が変わらない可能性はある。この時点で確実に言えたのは、一回目の順位付けが「実際に確認しに行った範囲」の順位と重なっていた、ということだけだった(Solは確認できる権限を持ちながら確認しなかった、Kimi K3はそもそも確認する権限がなかった――理由は違うが、どちらも「確認しなかった/できなかった」点では同じだ)。
ラウンド2・3: 非対称を減らそうとしてみたが
一度目の是正はこうだ。Kimi K3が「これを教えてほしい」と挙げたSDKの詳細を、こちらで手作業で調べ、次のターンで渡してみた。するとKimi K3はFableと同一の根本原因に到達し、さらにFableが明示していなかった観察――テストがパスしていること自体がこのバグの傍証だ、テストは現実には起こりえない形を検証していたのだから――を添えてきた。
ただし、これも公平な比較にはなっていない。FableやSolに同じ追加ターン・同じ情報を渡したわけではないからだ。Kimi K3だけが「もう一往復」を与えられた状態での結果であって、条件を揃えたとは言えない。
二度目の是正では、利用可能なことに気づいた別のエージェント型コーディングツール経由で、Kimi K3に本物の道具を持たせてみた。実ファイルの読み取り、実シェル実行、実機に入っている実SDKである。ここでKimi K3は同じ根本原因を再発見したうえで、合成ペイロードを実SDKのクラスに流すスクリプトを書いて実行し、フィールド欠如を検証し、既存テストスイートを回して「バグは実在するのに全パスする」様子を確認し、その理由を「テストは現実ではなく前提をエンコードしているから」と説明し、さらにFable・ChatGPT(Sol)のどちらも挙げていなかったSDK由来の未処理ステータス値――失敗に至るまで無駄に長く待ち続けてしまうケース――も報告してきた。
これでKimi K3にも実ツールアクセスを与えたとは言えるが、「条件を揃えた」とまでは言い切れない。FableとSolは元のセッション・元のハーネスのまま、Kimi K3だけ別のエージェント型ツールを新たに介して動かしている。ツールの種類が違えば、使える機能・既定の権限・実行ループの設計も違う。ターン数、実行時間、ツールの挙動そのものが三者で異なる以上、Kimi K3の踏み込んだ検証が、モデル自体の判断力によるものなのか、それとも接続したツールの実行ループやプロンプト設計によるものなのか、この記録だけでは切り分けられない。
余談: 車輪の再発明をしかけていた
条件を揃えようとするたびに新しい非対称が見つかる、という話のついでに、ツール設定そのものでも似た話があった。エージェント型ツールへの接続には、エンドポイント・認証用の環境変数名・モデル識別子を書いた小さな設定ブロックを手で用意する必要があった。ところがツールの組み込みベンダーカタログを開くと、同じベンダーの同じモデルが、こちらの作業とは無関係に最初から登録されていた。ゼロから書いた自分の設定は、その既存エントリとバイト単位で一致していた。
何かを新しく設定する前に、ツール側が既にその状態を知っているかどうかを確認する癖がついていなかった、というだけの話だ。今回はたまたま無駄骨で済んだが、確認を怠ったまま作業を進めていたら、もっと大きな手戻りになっていてもおかしくなかった。
この実験でわかったこと、わからなかったこと
試行を重ねてKimi K3の側の条件を近づけるたびに、その結果もFableの指摘に近い内容になっていった――これはこの一連の試行から見えた傾向であって、対照実験として設計されたものではない。二度目の是正でも追加ターンの回数は揃えていないし、三度目の是正でもハーネス自体が三者で違う。つまりこの実験は「Kimi K3が優れているか」に答えを出せる設計になっていなかった、というのが一番正直な総括だと思う。
それでも、この実験からは持ち帰れるものがあった。ひとつは、ツールの有無が「見た目の実力差」を生むという当たり前の事実を、身をもって確認できたこと。一回目にKimi K3が弱く見えた一因は、判断力そのものの差というより、確認を許された範囲の差にあったのかもしれない――ただしこれも、単発の不均衡な試行から言える範囲の話にとどまる。もうひとつは、AIの主張――特に「これは重大なバグだ」のような、具体的で自信ありげな主張――は、それ単体では確認済みの事実にならないということ。自分でSDKの実ソースを読んで裏取りするまで、Fableの説明は「もっともらしい仮説」の域を出なかった。この基準は、三度目の是正でKimi K3が見せた「スクリプトを書いて実行した」「テストを走らせた」という報告にも同じように当てはまる――それ自体、AIが自分の作業内容を語っているという点では変わらない。ただし、あの報告は再現可能な形(コードとテストの実行結果)で示されていた分、一言の断言よりは裏取りしやすかった、という違いはある。
複数のAIを比べるなら、まず条件をどこまで揃えられているかを先に見積もり、揃っていない部分は結果の一部として記録しておきたい。今回のように、揃えようとするたびに新しい非対称が見つかる、ということ自体が珍しくないのかもしれない。念のため書いておくと、これは1本のdiff・1つのタスクに対する記録であり、統計的な意味でのn=1に過ぎない。
おわりに
複数AIの運用を続けていると、「どのモデルが賢いか」より「どういう条件で比べたか」が結果を支配している場面にしばしば出くわす気がする。みなさんの現場では、比較実験の条件をどこまで揃えているだろうか。そして「これは公平な比較だ」と言い切る前に、まだ潰せていない非対称がないか、どれくらい確認しているだろうか。
出典
- ai& 公式ニュースルーム、Kimi K3ローンチ発表: aiand.com/jp/newsroom/kimi-k3-launch