前編では、Kimi K3の技術レポートから、2.78兆パラメータと100万トークンの文脈を支えるアーキテクチャを読み解いた。そこで見えたのは、モデルを「動かせること」と、必要な速度や可用性を備えた業務サービスとして「使えること」は別問題だという事実です。実際、Moonshot AIは2026年8月、Kimi K3をAzure、AWS、Google Cloudで提供するための買収・分配契約を3社と協議していると報じられました（2026年9月上旬時点で未締結）。
後編は視点をモデルの内部から広げて、このモデルがどのような環境で磨かれ、どう採点されたのかに注目します。
差がついているのは、モデルより訓練環境
初期モデルの構造である「事前学習」を終えたモデルを、実用的な振る舞いへ仕上げる工程（事後学習）には、3つのステップがあります。まず、教師ありファインチューニング（SFT）で初期能力を与え、実行結果を機械的に検証できる環境やモデル評価器を用いた強化学習（RL）で専門能力を高め、最後に複数の専門モデルを1つのモデルへ統合します。
普段AI開発に関わらない読者の方にはイメージしにくいのが、中核となる強化学習の方法です。初期の強化学習はAIが出したテキストに対して、人間が回答の良しあしを手動で採点するスタイルでした。しかし「Kimi K3」をはじめ、OpenAI、Anthropicなどが公開している最先端モデルはエージェントを用いた強化学習をしています。エージェントによる強化学習とは、AIモデル自身を自律エージェントとして仮想のパソコン環境に入れ、実際にツールを動かさせ、その実行結果から自動的にフィードバックを得て自習させるというものです。
実務で使えるコードを書き、「Slack」や「Gmail」などのアプリを連携させて自律的に仕事を完遂する能力を高めるうえでは、モデルを実際に行動させ、その実行結果から学ばせる動的な強化学習環境が重要な役割を果たします。
最先端の訓練、Kimi K3が手口を公開
この最先端の訓練において、Kimi K3がレポートを通じて手口を明らかにした点は画期的です。
Kimiチームはこのエージェント訓練を「一般タスク」「販売エージェント」「コーディングエージェント」という3つの領域に分けました。さらにそれぞれを「思考の深さ」（推論レベル：low、high、max）の3段階に分けて訓練し、合計9つの専門モデルを作りました。これらを最終的に1つのモデルへ融合させるプロセスまで明らかにしています。
先行する非公開モデルも、裏では同様の「思考レベルに応じた訓練と融合」を実行していると推測されますが、その具体的な手口はブラックボックスのままです。Kimi K3は事後学習の設計を本技術レポートで詳しく開示し、モデルの重みに加えて、サンドボックス基盤「AgentENV」やエキスパート並列実装「MoonEP」、KDAカーネル「FlashKDA」など一部の主要基盤を公開した点に価値があります。ただし、訓練と評価の環境全体がそのまま再現可能な形で公開されたわけではありません。
さらに、Kimiチームが用意した訓練と評価の環境のスケールも圧倒的です。複数の端日にまたがる持続的な環境の中で、GmailやSlackなどの実際のサービスを模したアプリケーションをまたぎ、相互依存的なイベントに対処させ、長大な実行と検証のループを実施しました。
特定のシステムに依存させない工夫
より興味深いのは、その訓練の方法です。
一般的に、AIエージェントを特定のシステムやプロンプトのルールに固定して訓練してしまうと、AIはその特定の手法に慣れてしまい（過学習）、環境が少しでも変わると使い物にならなくなります。
これを防ぐため、Kimiチームはシステムプロンプトやメモリ管理、ツールとの連携といったエージェントの構成要素を細かくモジュール化しました。
これらのモジュールを組み合わせることで、自社の「Kimi Code」だけでなく、「Claude Code」や「Codex」といった主要なエージェント実行環境を模した構成を再現できる仕組みを整えました。
これにより、Kimi K3は特定の実行基盤への依存（過剰適応）を回避し、異なるツール仕様やプロンプト構成にも柔軟に対応できる販売性を獲得しました。
採点の対象は「環境が実際にどうなったか」
評価の作り込みも徹底しています。長期的なアシスタント業務のために、Gmail、Notion、Slack、Canvasといった実際のアプリケーションの模擬実装が用意され、その上に人事、法務、金融の専門業務を模した課題が設計されました。エージェントは複数の端日にまたがって持続する環境の中で、アプリケーションをまたいで発生する相互依存的なイベント群に対処します。1回の試行が数十回のツール呼び出しと数億トークンの文脈に達することもあり、各イベントには決定的なルールまたは別のモデルによる評価基準が個別に付いています。
自律実行タスク（AET）と呼ばれる枠組みでは、エージェントに初期状態、制約付きの目標、ツールによる行動空間、実行予算、そして独立した検証者が与えられます。
参考となる手順書なし：タスクの分解、ツールの選択、計画、エラーからの復旧、いつ終わらせるかの判断まで自分で行う必要があります
「やったつもり」の自己申告に報酬は出さない：強化学習における報酬は、エージェントが自己申告した完了報告ではなく、検証者エージェントによる最終的な環境状態の評価に基づいて与えられます
自律実行タスク（AET）におけるAIの試行錯誤と進捗。ブラックボックス化されたシステムの複製タスクにおいて、Kimi K3が自らツールを呼び出しながらタスクを完遂していく推移。縦軸の達成度曲線（タスク進捗）が「AIの自己申告」ではなく、独立した検証者が「システムの最終状態」をチェックして採点した進捗となっている（技術レポート図10より引用、日本語は著者による）
測り方を変えれば、その裏をかく挙動も現れます。Kimiチームはこうした不正行為を検出してペナルティを与える仕組みを構築しました。
長文回答による加点狙いへの対策：正解を機械的に検証できない一般タスクでは、出力を長くして高評価を狙う挙動を抑えるため、一定の長さを超えた補足は比較で自動的に負けとするルールを設定
見かけ上の高速化への対策：GPUカーネル最適化のタスクでは、CUDAグラフの再生、入力のキャッシュ、精度の切り下げといった見かけ上速く見せる手口を検出して減点を与える仕組みを用意し、開発中に新しい手口が観測されるたびにルールを拡張したとされています
ここで注目すべきは、公開されたものとされているいないものの差です。
レポートが公開を明記しているのは、モデルの重みに加え、AgentENVやMoonEP、FlashKDAなど一部の基盤です。一方で、模擬アプリケーション群、知識グラフによるタスク合成、各種の検証者については、公開の記載がありません。
つまり、重みを手に入れても、この評価環境は付いてきません。
結論
自社業務についても、業務を再現でき、検証でき、AIの自己申告に頼らない評価環境を持てるかどうかが、ベンダー比較とPoC評価の精度に直結します。ここは、実装を外部へ委託する場合でも、業務の目的と合格基準を定義し、最終的に受け入れる主導権は企業自身が持つべきコア領域です。
企業に本レポートが提示した真の価値は、モデルの説明そのものではなく、その裏側で明らかにされた運用の考え方にあります。今後LLM（大規模言語モデル）を調達、内製化する際に企業が本当に持つべきなのは、なんでもできる巨大なLLMではなく、次の3つの力です。
自社の業務を厳密に定義する力：AIに何を完遂させるのか、どのデータと権限を使わせるのか、どこまで自動化し、どこで人へ引き継ぐのかを決める
仕事を厳格に採点する力：AIの自己申告ではなく、業務の最終状態、規約違反、再現性を確認し、本当に仕事が終わったかを判断する
必要な品質と応答時間を妥当な原価で提供する運用設計：モデルの選定だけではなく、キャッシュ、要求の分離、監視、障害時の復旧まで含めて設計する
これらは外部ベンダーへ実装を委託してはいけないという意味ではありません。実装や運用を委託しても、業務の目的と合格基準を定義し、最終的に受け入れる責任は企業側に残ります。
オープンソースAIの真の民主化とは、無料で良いモデルが手に入ることではありません。企業自身が「自社の業務をどう定義し、どう厳格に採点するか」という評価の主権を取り戻すことにかかっています。
