本記事は 2026 年 11 月 6 日に Kiro ブログで公開された「 How Kiro Auto uses model cascading to match the model to the work 」を翻訳したものです。 TL;DR： Auto は裏側でモデルカスケードを使っています。どのセッションも効率のよい最初のモデルで始まり、独立したチェックがバックグラウンドで作業を確かめ、必要になったときに Auto はセッションをより高性能なモデルに引き継ぎます。DeepSWE v1.1 を使った社内の評価では、カスケードは高性能なモデル単独とほぼ同じ成績を出し、タスクの約 5 件に 4 件は引き継ぎなしで完了しました。 Kiro では、ほとんどの方に Auto での作業をおすすめしています。 モデルのドキュメント にあるとおり、Auto がユーザーに代わってモデルを選び、高い品質の基準を保ちます。有料プランでは、その基準は Claude Opus クラスの品質です。この記事では、Auto がその基準を満たすための方法の 1 つである、モデルカスケードという手法を紹介します。 難しさはセッションが進むにつれて見えてくる Kiro に、不安定な日付パーサーの修正を頼んだとします。最初の手順は決まりきった作業です。ファイルを読み、関数を見つけ、不具合を再現する、失敗するテストを書きます。ところがそのテストで、ほかの 3 つのモジュールにまたがるタイムゾーンの前提が見つかり、小さな修正がリファクタリングに変わります。逆のことも起きます。大きく見えたタスクが、2 行の変更で済むこともあります。 モデルの性能が上がるにつれて、より大きな仕事を任せるようになり、Kiro のセッションは長くなっています。手順の多い長いセッションは、ファイルを読み、コードを編集し、テストを実行し、やり直すといった多くの手順を踏みます。その難しさは、始まった時点では決まっていません。セッションの難しさには形があり、その形は進めてみて初めて見えてきます。図 1 では、同じセッションを 3 通りのやり方で進めています。 図 1: 難しさはセッションが進むにつれて現れるため、最初に 1 回だけ選んだモデルでは、簡単な区間で性能が余るか、難しい区間で力が足りなくなります。カスケードは進めながら調整します（イメージ図）。1 枚目は途中で難しくなるセッション、2 枚目は簡単なままのセッションです。画像の右上のボタンは原文のインタラクティブな図のもので、この記事では 2 つの状態を 2 枚の画像に分けて載せています。 作業を始める前にモデルを選ぶとき、判断の手がかりは依頼の内容しかありません。高性能なモデルを選べば、効率のよいモデルでも同じようにこなせた決まりきった手順も含めて、すべての手順をそのモデルが担います。効率のよいモデルを選べば、決まりきった手順はうまくこなせますが、作業が難しくなると、行ったり来たりを始めたり、すでに終えた作業をやり直したりすることがあります。次に、図 1 の 2 枚目の、簡単なままのセッションを見てください。依頼が同じなので、最初に選ぶモデルは変わりません。カスケードは最後まで最初のモデルのままです。セッションが、そのモデルで扱える以上に難しくならないからです。 Auto のモデルカスケードのしくみ モデルカスケードは、1 回のモデルの選択を、エージェントのセッション全体を通して行う一連の判断に変えます。 効率のよいモデルで始める。 どのセッションも最初のモデルで始まります。最初のモデルは、日常的な幅広い作業をうまくこなす効率のよいモデルです。多くのセッションでは、このモデルが適切な選択で、作業のすべてをこなします。 バックグラウンドで作業を確かめる。 独立したモデルが、セッションの軌跡、つまりここまでに行われた作業を確かめます。チェックは非同期に動くので、セッションがチェックを待つことはありません。また、作業しているモデルが自分の進み具合を採点することもありません。 そのまま続けるか、引き継ぐ。 セッションが着実に進んでいるあいだは、何も変わりません。セッションが効率よく進まなくなった兆し（同じコードを繰り返し調べる、すでに終えた作業をやり直す、など）をチェックが見つけると、Auto はセッションをより高性能なモデルに引き継ぎます。引き継ぎではここまでの作業の要点が受け渡されるので、より高性能なモデルは最初からやり直すのではなく、今の状態のセッションをそのまま引き継ぎます。 必要に応じて繰り返す。 引き継ぎは、セッションが最も高性能なモデルで動くようになるまで繰り返し起こりえます。現時点では、引き継ぎは上の方向にだけ行われます。セッションを効率のよいモデルへ戻すことは、今後のアップデートで検討します。 モデルへのアクセスを管理しているチームでは、引き継ぎ先も Auto が使えるモデルの中から選ばれるので、引き継ぎにも Auto と同じガバナンスの設定が適用されます。管理者がモデルへのアクセスをどう制御するかは、 モデルのガバナンス をご覧ください。 図 2: Auto のモデルカスケードでは、最初のモデルがセッションを始め、独立したチェックがバックグラウンドで作業を確かめます。より高性能なモデルがセッションを引き継ぐのは、その必要がある兆しをチェックが見つけたときだけです。これは考え方を示したイラストで、実際のチェックの動き方を表したものではありません。 担当のエンジニアがチケットに取り組み、その肩越しにレビュアーが作業を見ている場面を考えてみてください。エンジニアは作業を続け、手を止めて自分の進み具合を採点することはありません。それはレビュアーの仕事です。作業が前に進んでいるあいだ、レビュアーは何も言いません。作業が同じところを回り始めたとレビュアーが気づいた時点で、チケットはより腕の立つエンジニアに渡り、そのエンジニアが今の状態から引き継ぎます。 カスケードを既定で動かしても安全なのは、このしくみがあるからです。作業しているモデルは自分の進み具合を採点せず、引き継ぎは最初からやり直すのではなく、すでに終えた作業の上に積み上げます。より高い性能が必要なセッションは途中でその性能を得られ、必要のないセッションは最初のモデルのまま進みます。 測定したこと カスケードを、Datacurve による、手順の多い長いタスクを扱うソフトウェアエンジニアリングのベンチマークである DeepSWE v1.1 で評価しました。タスクはこのベンチマークのために新しく作られたもので、オープンソースのリポジトリを題材にし、人が書いた、動作を確かめるテストで採点されます。そのため、難しさが途中で変わりうる、何段階にもわたるセッションが必要になります。Kiro のエージェントエンジンで 3 つの構成を動かし、それぞれの構成でベンチマーク全体を 3 回ずつ、独立に実行しました。 最初のモデルのみ。 すべてのタスクを、効率のよい最初のモデルで最初から最後まで実行します。 高性能なモデルのみ。 すべてのタスクを、より高性能なモデルで最初から最後まで実行します。 カスケード。 すべてのタスクを最初のモデルで始め、より高性能なモデルへ引き継げる状態にしておきます。 3 つの構成とも、推論（reasoning）の設定は同じです。違いは、どのモデルが作業を担うかだけです。結果は pass@1（1 回の試行で解けたタスクの割合）を、3 回の実行の平均 ± 1 標準偏差で示します。 高性能なモデル単独とほぼ同じ品質 図 3 は 3 つの構成の pass@1 を比べたもので、その下の表に同じ値を載せています。 図 3: DeepSWE v1.1 で、カスケードの pass@1 は 69.37% でした。高性能なモデル単独（70.57%）とほぼ同じで、最初のモデル単独（63.96%）より 5.40 ポイント高い値です。エラーバーは 3 回の実行の ± 1 標準偏差を示します。 構成 pass@1（3 回の実行の平均 ± 1 標準偏差） 最初のモデルのみ 63.96% ± 2.70 高性能なモデルのみ 70.57% ± 2.08 カスケード（最初のモデルで始め、より高性能なモデルを使える） 69.37% ± 1.56 カスケードはタスクの 69.37% を解きました。高性能なモデル単独（70.57%）とほぼ同じで、その差は実行ごとのばらつきの範囲内です。また、最初のモデル単独（63.96%）より 5.40 ポイント高い値です。3 つの構成のうち、実行ごとのばらつきが最も小さかったのもカスケードでした。つまり、すべてのタスクを最初のモデルで始めても、それが品質の足かせにはなりませんでした。 約 5 件に 4 件は引き継ぎなしで完了 図 4 は、カスケードのタスクがどのモデルで終わったかを示しています。 図 4: DeepSWE v1.1 の 3 回の実行を通して、タスクの 80.48% は最初のモデルだけで完了し、19.52%（約 5 件に 1 件）はより高性能なモデルに引き継がれました。 すべての実行を通して、タスクの 80.48% は最初のモデルで完了しました。残りの 19.52%、約 5 件に 1 件は、途中でより高性能なモデルに引き継がれました。 今回の DeepSWE の実行では、引き継がれたタスクには共通点がありました。最初から最後まで正しく仕上げるのが難しい変更だったことです。たとえば、型や API から CLI や設定まで、多くの層に同時に触れる機能や、保存された状態やキャッシュ、処理の順序に左右される振る舞いです。小さく局所的な変更で引き継ぎが必要になることはまれでしたが、大きな変更が必ず引き継ぎを必要としたわけでもありません。分かれ目になったのは、注意深い設計や、コードの複数の部分のあいだで整合性を保つことが、作業のどれだけを占めていたかでした。 引き継ぎが起きたタイミングにも、同じくらいはっきりした傾向がありました。これらのタスクでは、最初のモデルはほぼ必ず、序盤の手順を自力でこなしていました。コードを書き、多くの場合はビルドとテストを通すところまで進めています。引き継ぎは、そのあとの検証と統合の段階で起きる傾向がありました。最初のモデルが、変更したコード全体ですべての要件が満たされていることを示そうとしている段階で、セッションが効率よく進まなくなった兆しをチェックが見つけたのです。こうしたことは、どれも依頼の内容からは分かりませんでした。チェックが見守り続け、セッションが必要とするどの時点でも引き継ぎが起こりうるので、カスケードは作業がいつ難しくなるかを前もって知る必要がありません。 Auto がクレジット倍率 1x のまま複雑な作業を高い品質でこなせるのは、これが理由の 1 つです。ほとんどのセッションは最初のモデルで完了し、より高性能なモデルが引き継ぐのは作業上必要なときだけです。 ベンチマークの数値についての注意 これらの数値は、社内の評価用ベンチマークの、ある特定の実行で得られたものです。本番環境での見込みではなく、お客様ごとの実際のワークロードでの結果は異なります。 引き継ぎの割合はタスク全体の平均です。セッションがどれくらいの頻度で引き継がれるかは作業によるので、個々のセッションでは異なります。引き継ぎはユーザーには見えません。引き継ぎが起きていることを意識しなくても、品質の面での効果を得られます。 DeepSWE の数値は社内のベンチマーク用の実行環境（ハーネス）で測ったもので、公開されている DeepSWE のリーダーボードの公式の設定と同じではありません。そのため、割合を公開のリーダーボードの数値と比べることはできません。 試してみる モデルカスケードは Auto のしくみの一部で、効率の面での利点はすべての Kiro のお客様が利用できます。次にセッションを始めるときは、 Kiro で Auto を選んでください。Auto とモデルの選択のしくみについては、ドキュメントの モデルの概要 をご覧ください。 原文の著者 Vijay Lingam（Applied Science）、Mayank Gupta（Applied Science）、Sudipto Nandi（Engineering）、Neil Kulkarni（Engineering）、Jack Wang（Engineering）、Sai Srinivas Somarouthu（Engineering） 翻訳者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

こんにちは。サイオステクノロジー OSS サポート担当 山本です。 今回は OpenTelemetry について、他の「監視」関連の OSS を交えながら概要をざっくり見ていこうと思います。 ■OpenTelemetry ってなんだ？ OpenTelemetry は、Linux Foundation 傘下のプロジェクト CNCF (Cloud Native Computing Foundation) から生まれた OSS で、 「 Observability (可観測性)」と呼ばれるものの実現・標準化を目指した フレームワーク です。 ■そもそも Observability ってなんだ？ Observability (可観測性) は、 システムの状態を観測・分析 できるかどうかを示す指標です。 転じて、 システムの状態を観測するため に 情報を出力・収集できるようにする のを目指した機能やソフトウェアの役割 (カテゴリ) のことを指します。 概ねの目的・方向性は「監視 (Monitoring)」と似通っていますが、複数システムでの連携 (クラウド等含む) によるシステムの複雑化などに対応して、 システム内部の処理なども含めて より広範に・より詳細に情報収集する ことを目指したものです。 雑に言えば「すごい監視」と思っておけば、そう外れた認識ではないでしょう。 OpenTelemetry では、 　・ トレース ：一連の処理の追跡記録 (複数サービスを跨ぐ場合でも追跡可) 　・ メトリクス ：システムリソースの状況などの測定値 　・ ログ ：ログ を観測できるようにすることで、Observability の実現を目指しています。 ■ざっくり理解する OpenTelemetry この OpenTelemetry ですが、単体で見ても何をするのかわかりにくい……というか 単体では機能しない ものだったりします。 なので今回は、他の「監視」ツールの極めて大まかな概要を合わせて見ることにより OpenTelemetry がどんなものかを見ていこうと思います。 ■参考：超ざっくり見る「他の “監視” ツール」 ということで、まずは脇道。”監視” ツールについてざっくり見ていきます。 これは先述のとおり Observability と似通っており、「 システムに関する情報を収集して閲覧できるようにする 」ことを目指したソフトウェアのカテゴリです。 “監視” ツールにも色々ありますが、大枠としては基本的には 　・情報の 収集 ：システムから必要な情報を収集する 　・情報の 転送 ：情報を保存する機構を持つプロセスへ収集した情報を転送する 　・情報の 保存 ：情報をデータベースなどに保存する 　・情報の 可視化 ：データベースなどに保存された情報をユーザが閲覧しやすい形で表示する という4つの役割をまとめたものになります。 もちろんこれはあくまで全体的な傾向の話であり、個々のツールを掘り下げていけば色々な違いはあります。 （「収集：”監視対象のコードへ監視用コード埋め込む” か “ツールによる監視” かなど」「転送：”収集側と一体化した Push 型” か “保存側と一体化した Pull 型” かなど」…などなど） また、 一部機能を切り捨て て、切り捨てた部分は 他のツールに任せる という思い切った構造をしているツールもたまにあります。 これの有名な例としては、 「可視化」以外の機能を切り捨てている “Grafana” が挙げられます。 ■本題：超ざっくり見る OpenTelemetry では OpenTelemetry に目を向けてみましょう。 先述のとおり、OpenTelemetry も目的・方向性は “監視” ツールとほぼ同じであり、先に見た 4つの役割 (情報の「収集・転送・保存・可視化」) が必要になるはずです。 それでは OpenTelemetry が何をするかと言うと…… 　・情報の 収集 ： 監視対象コードに組み込む API により必要な情報を出力 + それを 収集するプロセス “コレクター” 　・情報の 転送 ： “コレクター” から独自規格 “OTLP (OpenTeLemetry Protocol)” で転送 ……までです。 そう。OpenTelemetry は “4つの役割” のうち 「保存」と「可視化」を切り捨てて、他のツールに任せています 。 「単体で機能しない」という話はこれのことで、単体では説明しづらいため先に “監視” ツールのお話をしました。 「保存」「可視化」を任せる他のツールへの連携については、転送規格 “ OTLP ” の仕様を公開しておくことで連携先のツール側で対応してもらう形です。 連携先のツールとしては、「Grafana Tempo (トレースのみ) / Grafana Mimir (メトリクスのみ) / Grafana Loki (ログのみ)」や「Zabbix (8.0 以降)」などが挙げられます。 ■OpenTelemetry のメリットは？ では OpenTelemetry のメリットは何か、というところを考えてみましょう。 メリットの前に、先述の「OpenTelemetry 単体では機能しない」というのは明確に手間がかかりわかりにくい箇所と言えます。これを上回るメリットはあるのでしょうか？ ・ “ベンダーロックイン” の回避 殆どの “監視” ツールでは、それぞれ 「そのツールにだけ通用する方法・形式」で先述の “4つの役割”「収集・転送・保存・可視化」の連携 をしています。 このため、何らかの理由で「別のツールに乗り換えたい」と考えた場合、”4つの役割” の 全ての要素を完全に置き換えねばならず、移行コストが高騰しがち です。 この「移行が大変だからあまりやりたくないなあ」と思わせる戦略は、”ベンダーロックイン” などと呼ばれています。 その点、OpenTelemetry は 元々「収集・転送」のみを担当して他のツールへ連携する 構造であり、かつ「 コードに直接干渉してデータ収集させる 」という、”監視ツール” において対応コストが最も高くなりがちな部分を担当しています。 これにより、移行の前後双方で OpenTelemetry を活用しておくことにより、移行コストを大幅に下げることができる可能性があります。 ・ カバー範囲の広さ OpenTelemetry は、 一つで「 トレース/メトリクス/ログ 」の収集を全て行なう ことができます。 OpenTelemetry 以前にも「トレースのみ」「メトリクスのみ」「ログのみ」を収集する OSS “監視” ツールは存在していましたが、(本記事の執筆時点では) これら全てをカバーできる OSS は希少です。 ・構造自体の優位性 繰り返しになりますが、OpenTelemetry は「保存・可視化」を捨てて 「収集・転送」のみ を担当しています。 これにより、「保存・可視化」を伴う他ツールと競合せずに協力・発展が可能で、かつこれ自身の開発リソースは「収集・転送」に集中されるため、将来的な機能追加にも期待できるでしょう。 また、バックボーンが Linux Foundation 傘下の CNCF であることから、中立性の維持も期待してよいと言えます。 ■最後に 今回は OpenTelemetry の概要についてお話ししました。 改めて要点を纏めてみると、「 CNCF (Linux Foundation 傘下) による、 “監視” のためのコード組み込み型アプローチによるデータ収集の標準化 を目指している OSS」と言えるでしょう。 単体では機能しない以上、他の “監視” ツールの動向にも大きく影響を受けるソフトウェアではありますが、 高機能な UI を備えることで有名な Grafana や Zabbix などもこの OpenTelemetry のデータの「保存・可視化」の対応に踏み切っており、”監視” システムの世界へ確実な影響を与えていくものになるはずです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Observability 実現の代表格「OpenTelemetry」って何だ？ first appeared on SIOS Tech Lab .

はじめに こんにちは 🐈 東京工科大学 学部3年の広瀬 エイトル（@Heitor_Hirose）です ...