こんにちは。イノベーションセンターの加藤です。先日私たちのLLMベースJSON生成についての論文がニューラルネットワーク分野の国際会議IJCNN2026 1 に採択され、ポスター発表を行いました。本稿ではその発表内容を紹介します。 プレプリントはこちら： https://arxiv.org/abs/2605.13076 IJCNNについて LLMベースJSON生成 既存手法の問題点 提案手法 今後の方向性 IJCNNについて IJCNN（International Joint Conference on Neural Networks）は、ニューラルネットワークをはじめとするAI分野を対象とした主要な国際会議のひとつです。ニューラルネットワークの理論から応用まで幅広いテーマを扱っており、近年は深層学習や大規模言語モデル（LLM: Large Language Model）に関する研究も多く発表されています。 今年のIJCNN2026は、進化計算を扱うIEEE CEC（Congress on Evolutionary Computation）およびファジィシステムを扱うFUZZ-IEEE（International Conference on Fuzzy Systems）と合同で、IEEE WCCI（World Congress on Computational Intelligence） 2 として6月21日から26日にオランダのマーストリヒトで開催されました。 この合同会議は2年に一度開催される計算知能分野の大規模な国際会議であり、分野を横断した活発な議論や交流が行われました。 LLMベースJSON生成 LLMはチャットボットのように人間向けの文章を生成するだけでなく、その出力を外部のプログラムに繋ぎ込むことで、より高度なシステムを構築できます。近年注目されているLLMエージェントは、下図のように複数のLLMやツールを連携させて複雑なタスクを遂行しますが、こうした連携ではLLM同士やLLMとツールの間でやり取りされるデータが機械的に解釈可能である必要があります。 このような用途では、決まったスキーマに従うJSONをLLMに生成させることが定番の方法となっています。JSONはキーと値の対応が明確で、多くのプログラミング言語で標準的に扱えるため、LLMの出力を後段のプログラムに渡す際のインターフェースとして広く使われています。実際、OpenAI 3 やGemini 4 など主要なLLMプロバイダはStructured Outputという名称で指定したスキーマに沿ったJSONを生成するAPIを提供しています。 一方でLLMは元々自然言語でのやり取りを前提にデザインされているので、プロンプトで「JSONのみを出力してください」と指示するだけでは、余計な説明文が混ざったり括弧の対応が崩れたりして、文法的に正しくない出力となることがあります。そこで、プロンプトのような確実性のない手段に頼るのではなく、生成の段階で選択できるトークンの候補を適切に制限することで、出力を必ず目的のフォーマットに従わせる文法制約付き生成（Structured Generation, Grammar Constrained Generation）が用いられています。 一般的な文法制約付き生成では対象とする文法のパーサーを利用します。 各生成ステップにおいて、パーサーはそれまでの途中出力を部分的にパースして次に来ることが許される終端記号を教えてくれます。終端記号とは、文法においてそれ以上分解されない最小の要素のことで、JSONでいえば { や } といった記号や、 true や false のようなキーワードが該当します。パーサーの仕様によっては文字列や数などの記述も終端記号として扱われます。対して、オブジェクト {"key": "value"} や配列 [0,1,2] のように複数の要素から構成される概念を表した記号を非終端記号と呼びます。このようにして提示された終端記号の候補をもとにして有効なLLMトークンを判定します。 より詳細な解説は こちらの記事 をご覧ください。 既存手法の問題点 文法制約付き生成のアルゴリズムはさまざまなものが提案されていますが、既存の手法はどれも停止性が保証されていないという問題があります。 LLMは無限生成を避けるため、あるいは推論コストや応答時間を抑えるために生成するトークン数の上限（ max_new_tokens 5 ）を指定することがほとんどですが、この最大トークン数の指定を文法制約付き生成と併用すると、JSONを閉じきる前に上限トークン数に達してしまったとき途中で切れたJSONが出力されてしまいます。 これは既存手法があくまで文法的に正しい続きのトークンを選択しているにすぎず、最大トークン数に達する前に出力が完成するかどうかは考慮されていないことが原因です。 私たちの論文ではこの問題に対して、文法的な正しさだけでなく将来必要になるトークン数を意識した制約を導入し、最大トークン数に達する前に必ず出力が止まる制約手法を提案しました。 提案手法 上記の問題を解決するために私たちの提案手法が必要とするのは、次に有効な終端記号だけではなく、そこから出力が完成するまでに続き得る終端記号の列です。将来的に必要となるトークン数を見積もるには、この先どのような単語がどれだけ続くのかを把握する必要があるためです。 このような「続きとして有効な記号列」の候補数や探索のための計算量は文法やそれに対応するパーサーの複雑さに依存して変化します。 私たちは有効記号列の計算を効率化するために、JSONの定義をLL(1)文法と呼ばれる形式で記述し、それに対応したパーサーを採用しました。LL(1)パーサーは1つ先の終端記号を参照するだけで内部状態を決定でき、続きうる記号列も一意に決定できます。そうして得られた「あり得る続きの候補」と、あらかじめ前計算しておいた「各記号を実現するのに必要なLLMのトークン数」をもとに、将来必要になるトークン数の最小値を求めることで、最大トークン数に達する前に必ずJSONが完成するように生成を制御します。 実験ではJSON Mode Eval 6 というJSON生成のベンチマークを使い、厳しい最大トークン数制約下では提案手法が常に文法的に正しいJSONを出力することを確認しました。それに加えて内容の正確性という観点では、Beam SearchやMonte Carlo Tree Searchのようなより良い出力を探索する生成手法と組み合わせた場合に、既存手法では効果がなかったのに対し提案手法では精度が向上することを確認しました。 今後の方向性 前述のとおり、提案手法では文法的な正しさは保証できましたが、内容の正確性についてはBeam SearchやMonte Carlo Tree Searchといったサーチ手法を併用する必要がありました。しかし、これらのサーチ手法は計算量の高さが課題です。 ポスター発表ではその課題を改善するための方向性についてのヒントをいくつか得られたので、より頑健な文法制約手法を模索しようと思います。 https://attend.ieee.org/wcci-2026/ijcnn-2026-topics/ ↩ https://attend.ieee.org/wcci-2026/ ↩ https://platform.openai.com/docs/guides/structured-outputs ↩ https://ai.google.dev/gemini-api/docs/structured-output ↩ https://huggingface.co/docs/transformers/ja/main_classes/text_generation#transformers.GenerationConfig.max_new_tokens ↩ https://huggingface.co/datasets/NousResearch/json-mode-eval ↩

こんにちは! KINTOテクノロジーズ(以下、KTC)のAIファーストグループで、生成AIの活用推進を担当している和田です。 先日、JDLA(日本ディープラーニング協会)の資格合格者コミュニティ「CDLE」の業種別勉強会にお招きいただき、「個人の発見を、組織の知恵に」というテーマで登壇してきました。本記事は、その内容を再構成したものです。 https://jdla.connpass.com/event/393970/ 1. はじめに KTCはトヨタ自動車のグループ会社で、クルマのサブスク「KINTO」をテックの力で支える内製開発の会社です。 2023年の春、GPT-4とAPI版が出てきたタイミングで内製の生成AIチャットを立ち上げて以来、3年以上にわたって生成AIの活用推進を続けてきました。最近ではKTC/KINTOで培った技術力を、トヨタグループの各社へとアドバイジングや開発支援を通じた提供もしています。 その立場から国内の状況を眺めると、対照的な数字があります。生成AIを「導入済み」と回答した国内企業は57.7%^[ NRI「IT活用実態調査(2025年)」 ]。導入の壁は、もうほとんど越えられています。一方で、AIが利益(EBIT)に5%以上効いていて、かつ大きな価値を生んでいると答えられる企業は6%^[ McKinsey "The State of AI in 2025" ]。導入はしたが、成果を出していると言い切れる会社はまだ一握りです。 おそらくこの記事を読んでいるような、新しい技術への感度が高い方は、すでに仕事が大きく変わっているはずです。メールの下書き、議事録の要約、コーディング支援。少なくとも、これらを全てカタカタ手で打っている人は、かなり減っているのではないでしょうか。しかし問題はその先です。あなたの「周りの人」はどうでしょうか。個人としては価値が出ている。でも、組織としてはどうでしょう。今回のテーマは、個人の成果と組織の成果の間にある、この溝についてです。 2. キャズムのどこに手を打つか ― 今日は「B」の話 本題に入る前に、組織へ新しいものを広げるときのイメージを共有させてください。何度も見たであろう、キャズム理論^[ジェフリー・ムーアが提唱した、新技術の普及プロセスを説明する理論。利用者をイノベーター/アーリーアダプター/アーリーマジョリティなどの層に分け、層の間にある溝(キャズム)を越えることの難しさを論じたものです。]の図です。 新しい技術や文化を組織へ広げるときの手法。A・B・Cのどこに手を打つか これは生成AIの話だから持ち出した図ではありません。DXのときも、RPAのときも、新しい技術や文化を大きな組織に入れる場面では、いつもこの概念を使ってきました。 図にはA・B・Cという3つの矢印を描いています。それぞれが別の打ち手です。みなさんの組織は、いまどの矢印に手を打っているでしょうか。そしてご自身はどの層にいて、どの矢印ならコミットできそうでしょうか。そんなことを考えながら見てもらえればと思います。 A:イノベーターに自由を渡す。 新しいものは、放っておいても勝手に調べ、勝手に始め、勝手に実験してしまう人たちがいます。彼らにできる限り自由な環境を渡す。ただ自由なだけでなく、ガードレールを敷いて「ここでなら安心して遊んでいい」という空間にするのがAです。 B:キャズムに橋をかける。 イノベーターやアーリーアダプターが見つけた価値に、アーリーマジョリティ以降の人たちが追従できるよう、崖になっているキャズムへ橋をかける取り組みです。 C:後ろ向きな層を動かす。 配ってもなかなか触ってくれない、興味を持ってもらいにくい層に、どう使ってもらうか。ここに悩んでいる会社さんは、きっと多いはずです。 今日お話しするのは、このうちBが中心です。Bをやるには、その手前でAも回っている必要があるのですが、本記事では「見つかった価値を、キャズムの向こう側へどう渡すか」に軸足を置きます。 3. 価値創出の両輪 ― 探索と実装 組織で価値を出すには、2つの循環が要る、と私は考えています。 1つは探索。イノベーターやアーリーアダプターにあたる人たちが自由に価値を探せる環境を用意し、「この使い方は効く」という発見を生んでもらうフェーズです。もう1つは実装。見つかった0→1の発見を、組織に固定して10にも100にもするフェーズです。藪まみれの中をしらみつぶしに歩いてゴールを見つけるのが探索だとすれば、見つかった道を舗装して誰でも歩けるようにするのが実装です。 探索だけでは、個人の発見で止まります。IRレポートに載るようなインパクトは、個人技からは出ません。逆に、発見のない組織でいきなり実装(仕組み化)から入ると、舗装すべき道がどこにあるのか分からないまま工事が始まります。これらは両輪であってどちらが欠けても前進することはできません。 ここからは、KTCがこの両輪をどう回しているか、探索→実装の順でお話しします。 4. 探索:トークンマキシング ― 自転車の乗り方は、本では学べない 探索の打ち手の一つとして「トークンマキシング(Tokenmaxxing)」^[あるものを極限まで盛るというネットスラング "-maxxing" を、トークン消費にくっつけた言葉です。]を紹介します。社内のAIのトークン消費を、とにかく最大化する。価値創出はいったん脇に置いて、まず使う量を増やす施策群のことです。 なぜ価値創出にこだわると言っておきながら、消費量に注目するのでしょう。生成AIの正しい使い方は、机上で学べないからです。私はよく自転車の乗り方に例えるのですが、自転車の乗り方を本で学んだ人は、おそらくいません。補助輪をつけて、サポーターをつけて、河原で何度も転んで、身体で覚えたはずです。「AIにこう頼むとうまくいく」「これはAIには苦手だ」という感覚も同じで、試行錯誤からしか生まれません。だから、まずたくさん漕いで、たくさん転ぶことで、AIと効率よく協業する感覚が磨かれます。 トークンマキシングを構成する施策は、「消費を増やす施策」と「消費量を観測する施策」で構成されます。 消費を増やす施策の例としては「手作業コーディング禁止」があります。一定期間、人手でのコーディングを禁止して実装はAIエージェントに任せ、人間は指示と検証に集中する、というものです。コーディング界隈で広まった施策ですが、「手作業での資料作成禁止」のように事務系へのアレンジも利きます。 私自身は資料作成へのこだわりが強く、今でもつい手作業で熱中してしまう時があるのですが、最初の1割は人間が作り、そこから7〜8割まではAIに持っていかせて、最後にまた、人間のこだわりを入れるようにしています。何度も失敗しながら最近ようやくちょうど良いAIとの協業感覚を掴めてきています。 KINTOテクノロジーズで実施した手作業コーディングを禁止する施策「Vibe Coding Week」については、Findyさんによるインタビューブログでも取り上げていただきました。 https://jp.findy-team.io/blog/ai-casestudy/kintotechnologies_vibecodingweek/ もう1つの要素が観測です。増やしっぱなしではコストが爆発するので、誰が・どれだけ使っているかを可視化する。この文脈で有名になったのがMetaの「Claudeonomics」で、8.5万人超の従業員がトークン消費量でランク付けされ、上位250名にはRPG風の称号が与えられていたそうです^[ Fortune「A Meta employee created a dashboard so coworkers can compete to be the company's No. 1 AI token user」(2026/04/09) ]。KTCでも、Claude Codeのメトリクスを各ユーザーから収集し、個人と組織それぞれの使い方を分析する仕組みを動かしています。ツールは配ったけれどその後を見ていない、という組織は、まずここから始めるのを勧めます。 KTCで運用しているClaude Codeメトリクスのダッシュボード(数値はダミーデータ) 5. ただし、トークン消費はハック可能 ・・・ただしトークン消費量は、あくまで間接指標です。 たくさん使った≠価値が出た。実際、Metaの番付では、順位のためにAIを空回しして消費量を水増しする従業員が現れたという情報もあります。そりゃそうですよね。指標は必ずハックされます。入力量で成果を測るのは、印刷したページ数で文章の質を測るようなものなので、報酬や人事評価に直接ひもづけるのは慎重であるべきです。トークンマキシングは、短期的に組織のモメンタムを作る旗印としては効きますが、ずっと続けるものではありません。習熟が進んで消費が落ち着いてくるところまでがセットです。 消費量はあくまで間接指標。指標は必ずハックされる そしてもう1つ、この打ち手には賞味期限があります。これまでのコーディングエージェントの多くは月額定額、いわば携帯のパケ放題のような契約でした。「とにかく使え」が安心して言えたのは、この建て付けがあったからです。ところが課金体系は従量制へ動いています。 GitHub Copilotは2026年6月1日から使用量ベースの課金へ移行します し、他のエージェントも続々と後を追っています。 Uberが2026年のAI予算をわずか4か月で使い果たし、コーディングエージェントの利用に従業員一人当たりの月額上限を設けた という報道も出始めました。 従量課金の世界で大事になるのは、トークンマネジメントや最適化、つまり妥当なコストで成果を増やす考え方です。難しいのは、マキシングを経験しないまま従量課金に入ってしまった組織で、転んだことのないまま管理から始めることになります。もしいま手元に使い放題のプランがあるなら、それは最後のモラトリアムかもしれません。プランが生きているうちに、探索をやり切ることをお勧めします。 定額制(パケ放題)から従量課金へ。「とにかく使え」が言えた時代は終わりつつある ここまでが探索の話。次は、見つけた発見をどう組織に固定するかです。 6. 実装:発見をAgent Skillに固める ― 発見した本人に、文書化まで背負わせない どの組織にも、キャズムでいうイノベーターやアーリーアダプターにあたる人たちがいます。新しいものを勝手に調べ、勝手に試し、「この頼み方ならうまくいく」という良い使い方を見つけてくる人たちです。問題は、その発見が本人の中にしかないことです。 そこでKTCで今増えているのが、 Agent Skill です。Agent Skillとは、AIエージェントに特定タスクの「やり方」を教える再利用可能な手順書のことで、いつ何をするかを書いた指示書(SKILL.md)、手順とOK/NGの線引き、テンプレートやスクリプトといった参照ファイルを1つのパッケージにまとめたものです。属人的だったカンコツを取り出して、誰でも再現できる形に固める。暗黙知やワザを、Skillという形で全員に配ることができます。 Agent Skillは指示書・手順/判断基準・参照ファイルの3点セット KTCの例でいうと、トヨタグループには「物と情報の流れ図(物情)」という業務の可視化手法があるのですが、このドラフトをAIに作らせるSkillを固めて、社内に配布しています。先行する人たちの発見を、お湯を注げば誰でも食べられるインスタント食品に加工して配る、というイメージです。 一方でこうした探索の担い手は、新しい使い方を探すこと自体は好きでも、それを手順書に書き起こすことには関心が薄かったりします。であれば、横串の推進組織が本人のところへ出向いて、「文書化はうちらが代わりにやります」と引き受けてしまうのはどうでしょうか。発見した本人に、文書化の手間まで負わせる必要はないかもしれません。 7. 運用と文化 ― 「手でプロンプトを打たない」という逆説 Skillは作っておしまいではなく、運用が必要です。誰でもSkillを探して使える場所(Plugin Market)を作る。命名ルールを決める・・・検索できないSkillは、存在しないのと同じだからです。ブランチ名や関数名に払っている気遣いを思い出してください。あれと同じ気遣いがSkillにも必要です。ただ、Skillの命名規則のベストプラクティスはまだ世の中に整備されていないので、会社ごとに独自で決めてしまうのが有効だと思います。それから、定期的なメンテナンス。数か月で前提が変わる領域なので、古いSkillは放置すれば負債になります。 Skill運用を支える4つの仕組み(Plugin Market・命名ルール・定期メンテ・対象発掘) そして、そのメンテナンスをどう回すか。ここが地味に大変なところなのですが、KTCではSkillの保守そのものをSkillにしてしまうことを試しています。いわば、Skillを点検・整備するためのSkill群です^[公開されているmizchiさんの「 waxa 」を参考にしています。]。役割を分けた、4つのモードがあります。 検証する:書いたばかりのSkillを、まっさらな別セッションに白紙で読ませ、「ここが伝わらない」という曖昧さや暗黙知を炙り出す。 棚卸しする:Skill群ぜんぶを複数の観点で健康診断し、どれから手を入れるべきかのリストを作る。迷ったら、まずここから。 命名を整える:名前とdescriptionだけを命名規則に合わせて直す。何をするSkillか一目で理解でき、検索で見つかる状態を保つための整備になる。 本文を直す:古いSkill名やモデル名、URLといった陳腐化した参照を、機械的に一括置換する。 コツは、各修正のポリシーきっちり分けて、1つのセッションに何もかもやらせないこと。さきほど「検索できないSkillは存在しないのと同じ」と書きましたが、その状態を保つ作業自体を、人間の根性ではなくSkillに肩代わりさせるわけです。運用とは、こういう地味な仕組みの積み重ねなのだと思います。 Skillの保守そのものをSkillにする。役割を分けた4モードで運用を回す(参考: mizchiさんのwaxa) 文化の面では、事例共有会や勉強会といった地道な取り組みを続けてください。「こんな効くSkill作ったぜ」を見せ合う場は、評価制度ではなく、つい誰かに見せたくなる気持ちで回り始めます。地味ですが、文化醸成はこういう積み重ねでしか進まないと思っています。 最後に1つ、逆説的な話を。個人の仕事を組織の仕事にする上で、プロンプトエンジニアリングのスキルが邪魔をすることがあります。個人が勘とコツでプロンプトを丁寧に調整し、エージェントをいい感じに動かすのは、良いようでいて横展開が非常にしにくい。プロンプト頼みの業務は、それ自体が属人化です。なのでKTCでは最近、組織の仕事にする場合は手でプロンプトを打つのをできるだけやめて、スラッシュコマンドやSkillの呼び出しだけで完結させることを推奨しています。上手に打てる人ほど、打たない。妙な話ですが、組織化とはそういうことだと考えています。 なお、ここまでの打ち手は、KTCがクラウド・AI領域で新しいことに踏み込みやすい立場にある、という前提と切り離せません。新しいことを試し、うまくいったものを少しずつ周囲へ広げていく——そんな意識で取り組んでいるので、キャズムでいう上位層に意識的に時間を寄せています。どの層にどれだけ時間をかけるかのポートフォリオは、自社の立ち位置や方針に従って決め、経営層と握っておくのが筋だと思います。 8. まとめ ― 個人の発見を、組織の知恵に 「個人の発見を、組織の知恵に」今回お伝えしたかったのは、結局この一行です。探索のフェーズでは、トークンマキシングでたくさん試して、転ぶことを恐れない。正しい使い方は、試行錯誤からしか生まれないからです。実装のフェーズでは、発見をAgent Skillのような形に固め、誰でも再現できるようにして配る。そして、仕組みと文化で回し続ける。 探索→実装→仕組み・文化。個人の発見を、組織の知恵に G検定やE資格を持っているような方は、すでに一本のスペシャリティがある状態です。AIは自力にレバレッジをかける道具なので、自力が10の人と100の人では、掛けた後の差がまるで違います。ご自身のドメイン知識と、資格を通じて学んだ知識と、生成AIやAIエージェントを掛け算して、まずはたくさん転ぶところから。そして、転んで見つけた発見を、ぜひ組織に配ってください。 ここまで読んでいただき、ありがとうございました! あなたや周囲の人の発見が、組織の知恵になっていくことを願っています。

本ブログは、2025 年 10月 20 日に公開された Amazon Science Blog “ Introducing Chronos-2: From univariate to universal forecasting ” を翻訳したものです。 Chronos-2 は、追加学習なしに、多変量も共変量も扱える時系列基盤モデルです。 時系列予測は、ビジネス、科学、工学における数多くのアプリケーションにとって不可欠です。近年、基盤モデルが時系列予測にパラダイムシフトをもたらしました。1本の時系列を延長する統計モデルや、特定タスク専用に訓練された従来の深層学習モデルとは異なり、時系列基盤モデル（Time Series Foundation Model : TSFM）は大規模な時系列データで事前に訓練され、その後さまざまな予測問題に適用されます。 初回リリース以来、Amazon の TSFM である Chronos と Chronos-Bolt は、Hugging Face から累計6億回以上ダウンロードされており、TSFM への関心の高さと、幅広い予測シナリオで活用されていることを示しています。 しかし既存の TSFM には、単変量予測しかサポートされないという重要な制約があります。単変量予測は重要ですが、多くのシナリオでは追加の機能が必要です。現実の予測問題では、互いに関連しながら変動する複数の時系列を同時に予測すること（多変量予測）や、予測対象に影響を与える外部要因を取り込むこと（共変量付き予測）が求められることが多くあります。例えば、CPU 使用率、メモリ消費量、ストレージ I/O などのクラウドインフラストラクチャの指標は連動して変化し、同時にモデリングすることでより正確な予測が得られます。同様に、小売の需要はプロモーション活動に大きく影響され、エネルギー消費は気象条件に大きく依存します。 この問題を解決するため、私たちは Chronos-2 を発表しました。Chronos-2 は、単変量、多変量、共変量付き予測など、任意の予測タスクをゼロショットで処理するために設計された基盤モデルです。Chronos-2 はコンテキスト内学習（in-context learning : ICL）を活用し、追加学習なしに多変量・共変量付き予測を実現します。 多変量予測では、Chronos-2 は互いに連動する複数の時系列を同時に予測し、変数間の依存関係を捉えて予測精度を向上させます。例えば、クラウド運用チームは CPU 使用率、メモリ消費量、ストレージ I/O を同時に予測し、リソースのボトルネックを事前に検知できます。 共変量付き予測では、Chronos-2 は予測対象に影響を与える外部要因を取り込むことができます。このモデルは、過去共変量（将来のトレンドを示唆する過去の交通量データなど）と、将来既知の共変量（計画済みのプロモーションや天気予報など）をサポートします。また、特定の祝日やプロモーションの種類などのカテゴリカル共変量も扱えます。例えば、小売業者はプロモーションキャンペーンや祝日スケジュールを考慮しながら需要を予測し、在庫水準を最適化できます。 Chronos-2 の強化された ICL 機能は、系列間の情報共有（クロスラーニング）を可能にし、単変量予測も改善します。これはコールドスタートのシナリオで特に有用です。新しい配送センターを開設する物流会社は、既存施設のパターンを活用して、運用履歴が最小限であっても正確な予測を生成できます。 図1 : Chronos-2 のパイプライン Chronos-2 の全体パイプラインは以下のように構成されます。 入力時系列（予測対象と共変量）をスケーリングで正規化 タイムインデックスとマスクのメタ特徴量を追加 得られた系列を重複のないパッチに分割し、残差ネットワークを介して高次元の埋め込みにマッピング コアの Transformer スタックがこれらのパッチ埋め込みに対して動作し、入力でマスクされた将来パッチに対応するマルチパッチ分位点出力を生成 訳注：タイムインデックスは各データポイントの時間的な位置を示し、マスクは将来区間（＝予測対象）がどこかをモデルに伝える役割を持ちます。 訳註：残差ネットワーク（residual network）は入力をスキップ接続で保持しながら変換するネットワーク構造を意味します。「高次元の埋め込みにマッピング」は、各パッチを Transformer が処理しやすい数値ベクトルに変換することです。 各 Transformer ブロックは時間アテンション層とグループアテンション層を交互に配置しています。時間アテンション層は単一の時系列内のパッチ間で情報を集約し、グループアテンション層は各パッチインデックスにおいてグループ内のすべての系列間で情報を集約します。図 1 は、それぞれ 1 つの既知共変量を持つ 2 つの多変量時系列を示しており、対応するグループが青と赤でハイライトされています。この例は説明のためのものですが、Chronos-2 は任意の数のターゲットとオプションの共変量をサポートします。 Chronos-2 のように多様な予測タスクに対応する TSFM を構築するには、モデルアーキテクチャと訓練データの2つの面でイノベーションが必要でした。下流の予測タスクは、変数の数も変数が表す意味も多様です。未知のタスクにおける変数間の相互作用は事前に分からないため、モデルは与えられたコンテキストからそれを推論する必要があります。 私たちのグループアテンション機構は、任意のサイズの時系列グループ内での情報交換を通じて、このような相互作用を考慮します。例えば、Chronos-2 がクラウドの各種指標を予測する場合、CPU 使用率のパターンがメモリ消費量の予測に情報を提供できます。グループアテンションは共変量も考慮でき、例えばプロモーションスケジュールの情報を使って需要予測を支援します。 訓練コーパスはアーキテクチャのイノベーションと同様に重要です。多様な予測タスクに対応する TSFM は異種の時系列タスクで訓練される必要がありますが、多変量の依存関係や有用な共変量を含む高品質な事前学習データはほとんど存在しません。この問題に対処するため、私たちは合成時系列データを活用しています。具体的には、ベースとなる単変量生成器から時系列をサンプリングし、それらに多変量構造を付与することでデータを生成しています。 図2 fev-bench の結果 fev-bench 時系列ベンチマークでの実験結果です。平均勝率とスキルスコアは、確率的予測性能を評価するスケーリング分位点損失（SQL）指標に基づいて計算されています。両指標とも値が高いほど結果が良好であることを示します。Chronos-2 は、単変量、多変量、共変量付き予測タスクを含むこの包括的なベンチマークにおいて、既存のすべての事前学習済みモデルを大幅に上回っています。 図3 : 単変量予測との比較 Chronos-2 の単変量予測での結果と、fev-bench の共変量サブセットにおける ICL による改善（積み上げ棒グラフとして表示）です。ICL は共変量を含むタスクで大きな改善をもたらし、Chronos-2 が ICL を通じて共変量を効果的に活用できることを実証しています。Chronos-2 以外では TabPFN-TS と COSMIC のみが共変量をサポートしており、Chronos-2 はすべてのベースライン（TabPFN-TS と COSMIC を含む）を大幅に上回っています。 図4 : GIFT-Eval の結果 GIFT-Eval 時系列ベンチマークでの結果です。(a) 確率的予測指標および (b) 点予測指標に対する平均勝率とスキルスコアを示しています。両指標とも値が高いほど結果が良好であることを示します。Chronos-2 は、これまで最高性能であった TimesFM-2.5 と TiRex を上回っています。 実証的な評価により、Chronos-2 が TSFM の飛躍的な能力が確認されました。単変量、多変量、共変量付き予測など幅広い予測タスクを網羅する包括的な時系列ベンチマーク fev-bench において、Chronos-2 は既存の TSFM を大幅に上回っています。最大の改善は共変量付きタスクで見られ、この実用上重要な設定における Chronos-2 の強みを実証しています。 GIFT-Eval ベンチマークでは、Chronos-2 は事前学習済みモデルの中で1位にランクされています。Chronos-2 はその前身である Chronos-Bolt を大幅に上回り、直接比較で90%以上の勝率を達成しています。 Chronos-2 は ICL により追加学習なしに本番パイプラインへ組み込めるため、予測パイプラインを大幅に簡素化できます。Chronos-2 は現在オープンソースとして公開されています（リンクは以下）。研究者や実務家の皆様にぜひ Chronos-2 をお試しいただき、時系列基盤モデルの研究の最前線に加わっていただければ幸いです。 参考情報： Chronos-2 モデルカード Amazon SageMaker への Chronos-2 のデプロイ Chronos-2 技術レポート Chronos GitHub リポジトリ 著者について Abdul Fatir Ansari Amazon Web Services の Senior Applied Scientist Oleksandr Shchur Amazon Web Services の Senior Applied Scientist Jaris Küken Amazon Web Services の Applied Science Intern。フライブルク大学コンピュータサイエンス専攻の大学院生 本ブログは、Solutions Architect の 寺山 怜志が翻訳しました。