Quantum Sea

タグ: テスト自動化

  • Zuulのゲーティング、取り込む順番に沿って変更をテストする

    Zuulのゲーティング、取り込む順番に沿って変更をテストする

    それぞれの変更はテストに通ったのに、二つを取り込むと動かなくなる。ソフトウェアの開発では、変更そのものだけでなく、組み合わせた状態も確かめる必要があります。後から取り込む変更を、古い状態のまま試した結果では、その違いが抜け落ちるためです。

    この問題を扱うのが、Zuulのゲーティングです。コードを本流へ取り込む「マージ」の前に、必要な試験を通す仕組みを指します。OCP Korea Tech DayでOpenInfra Korea User GroupのSeongsoo Cho氏が紹介したZuulについて、公式文書を重ね、変更の順番と再試験の関係を見ていきます。［1］［2］

    簡単にまとめると？

    • Zuulは、前の変更も取り込まれると仮定し、後ろの変更をその組み合わせで先にテストします。
    • 前の変更が失敗すれば、それを除いた状態で後続を試し直します。ただし、失敗した変更を本当に必要とする変更は、そのまま先へ進めません。
    • 関連するリポジトリの範囲、試験内容、先に試す変更の数を合わせて設計します。並列化すれば必ず速くなるわけではありません。

    「単独で通る」と「一緒に通る」の間

    仕組みを理解するための例として、送信側が一度に8件を送り、受信側は16件まで受け取れる処理を考えます。変更Aで送信を12件に増やしても、現在の受信上限16件なら収まります。別の変更Bで受信上限を10件に下げても、現在の送信件数8件なら収まります。

    ところがAとBを合わせると、12件を送る先の上限は10件です。各変更を元の構成に対して試すだけでは、この組み合わせを確かめたことになりません。これは説明用の仮例で、特定製品の試験結果ではありません。

    一つ取り込むたびに次の変更を試せば、順番に沿った確認はできます。ただ、試験が長いほど待ち行列が伸びます。Zuulのdependent pipeline managerは、この順序を保ちながら試験を並行させる役割を持ちます。［3］

    前の変更が通ると仮定して、先に試す

    変更A、B、Cがこの順でキューへ入ったとします。キューは、取り込みを待つ変更の列です。ZuulはAだけ、AとB、AとBとCという組み合わせを作り、利用できる実行資源の範囲で並行して試験します。これがspeculative execution（先行する変更の成功を仮定した実行）です。まだ確かめていない変更を本流へ先に入れる、という意味ではありません。［2］［3］

    同じ開始時点から、どの変更を重ねて試すか
    対象の変更 試験する状態
    A 現在の本流 ＋ A
    B 現在の本流 ＋ A ＋ B
    C 現在の本流 ＋ A ＋ B ＋ C

    この表は公式文書の説明を三つの変更に整理したものです。Bを試す環境にAが入っているため、Bだけを古い本流に載せた試験とは、結果の意味が違います。後続の試験が早く終わっても、先行する変更の合否を無視してよいわけではありません。［2］

    失敗したら、何を除いて試し直すか

    先頭のAが失敗すると、Aを含めて試したBとCの結果は、そのまま使えません。単に順番待ちしていた独立した変更なら、Aを列から外し、Bは「現在の本流＋B」、Cは「現在の本流＋B＋C」で試し直します。前提となる組み合わせが変わったからです。［3］

    ここで区別したいのが、順番の都合で先行変更を含めることと、機能としてその変更を必要とすることです。例えば、共通ライブラリーへ新しい関数を加える変更Aと、その関数を呼ぶサービス側の変更Bは、Aを除いてBだけ進められません。Zuulでは、変更URLを指定するDepends-Onで、こうしたリポジトリをまたぐ依存を明示できます。依存先が失敗すれば、その依存先とそれに依存する変更はキューから外され、依存先が取り込まれるまでは依存する側も取り込めません。［2］

    「失敗したものを飛ばす」と一律に考えると、この違いを見失います。再試験で進められる変更と、前提の修正を待つ変更を分けるためにも、コード上の依存を記録しておく必要があります。

    一緒に試す範囲を、リポジトリの境界と照合する

    リポジトリは、ソフトウェアや設定の変更履歴を保存する単位です。サービスと共通ライブラリーを別のリポジトリで管理しているなら、それぞれの単体試験だけでは、組み合わせの不整合を見逃すことがあります。

    Zuulのproject.queueでは、試験で相互に関わるプロジェクトへ同じ共有キューを指定します。dependent pipelineでは、その列の先行変更を含めて後続を試します。共有キューの設定自体は、試しの変更として置くだけでは有効にならず、設定をマージしておく必要があります。［4］

    queue.typeをper-branchとしてブランチ名ごとにキューを分ける場合には、関連プロジェクトのブランチ名をそろえる条件もあります。名前が違えば、一緒に試したい変更が別のキューへ入るためです。また、複数のリポジトリを同じキューへ置いても、複数のマージが一つの不可分な操作になるわけではありません。公式文書は、循環する依存を許可した場合でも、一部だけ取り込まれる失敗があり、人の介入が必要になり得ると説明しています。［5］

    共有する範囲は、部署や組織の大きさより、実際に一緒に試す必要のある関係から考えます。無関係な変更まで同じ列へ集めると、ある変更の失敗によって、試し直す範囲も広がり得ます。

    待ち時間だけでなく、試し直す量も見る

    並行して試す変更を増やせば、すべて通るときは待ち時間を減らせます。一方、先行変更が頻繁に失敗する環境では、後続の試験をやり直す負担が増えます。Zuulのwindowは、キューの先頭から何件の変更について試験を開始できるかを制御します。これは、個々のテストジョブの本数と同じ数ではありません。［3］

    導入を考えるなら、まず関連する二つのリポジトリと、それらを組み合わせる試験を一組選びます。通常の変更が通る場合に加え、先行変更が失敗する場合、明示した依存先が失敗する場合に、どの結果が破棄され、どの変更が止まるかを見る。待ち時間の短縮と、再試験に使う時間・実行資源を合わせて比べるための確認です。

    ゲーティングが整えるのは、変更を試す状態と取り込みの条件です。用意していない試験の不具合まで自動で見つけたり、本番への配備が安全であると保証したりするものではありません。早い段階で結果を返す試験、取り込みを決める試験、取り込み後の配備を区別したうえで、どの組み合わせを合格とするかを設計することが、Zuulを使う出発点になります。［3］

    参考資料

    1. Seongsoo Cho／OpenInfra Korea User Group「Open Infrastructure: Global Trends」、2026 OCP Korea Tech Day、全36頁。Zuulの紹介はpp.23–25。OCP公式資料一覧。
    2. Zuul contributors「Project Gating」。並行試験、再試験、共有キュー、明示的な変更依存。
    3. Zuul contributors「Pipeline」。independent／dependent／serialの役割、pipeline.window。
    4. Zuul contributors「Project」。project.queueと設定の有効化。
    5. Zuul contributors「Queue」。ブランチ単位の区分と、循環依存を扱う際の制約。

    資料確認日：2026年10月12日。公式文書のlatest版を参照しています。試験環境を動かした検証や、講演に登場する個別企業の改善効果の検証は行っていません。

  • GoogleのAIチップ電源検証案、インターポーザーと負荷変動の自動試験

    GoogleのAIチップ電源検証案、インターポーザーと負荷変動の自動試験

    AIチップへ電気を届ける回路は、必要な電流が急に変わっても、電圧を許容範囲に保たなければなりません。その確かめ方も、一定の電流を流すだけでは足りません。電流の変化をどれほど速く、どの周期で繰り返すかまで、試験の条件になります。

    2026年8月のOCP APAC SummitでGoogleが示したのは、専用の処理を担うASICなどの電源を検証するために、試験用インターポーザーの設計から、負荷を自動で変える試験までをつなぐ手順です。装置のつまみを自動で回す前に、何を再現し、どこで測るかをそろえる。そこが、この提案の出発点です。［1・2］

    簡単にまとめると？

    • AIチップの電源試験では、最大電流だけでなく、電流が変わる速さや繰り返し方もそろえます。
    • Googleの提案は、試験用基板の配線・測定点から、負荷を順に変えて波形を記録する自動化までをつなぎます。
    • 仕様公開やAIによる波形判定は発表時点の計画で、短縮率や判定精度の実測値は示されていません。

    電流の大きさと、変わる速さを分けて見る

    まず確認するのは、チップの電源仕様です。資料は、電源系統である電源レールごとに、定常時と変動時の電圧条件、リップルと呼ばれる電圧の細かな揺れ、電流が変化する速さを確認するよう求めています。この変化の速さがスルーレートです。同じ最大電流でも、ゆっくり増える場合と急に増える場合では、試す条件が異なります。［2］

    続いて、その条件を作れる負荷ツールを選びます。必要な最低電圧とピーク電流に対応するか、電流を正確に読めるか、立ち上がり・立ち下がりの速さを調整できるかを確認します。発熱への冷却や、過熱・逆挿しへの保護も選定項目です。ノイズの許容範囲が厳しいレールには、静的な負荷を備えたインターポーザーで試験する案も示されています。［2］

    試験用の接続基板も、測定結果を左右する

    ここでのインターポーザーは、電源の試験対象と負荷ツールをつなぐ接続基板です。資料では、高密度に配線できるHDI基板を使い、電源、グラウンド、制御信号、電流測定用のシャント信号の接続を確認します。電源を試すための基板として、配線と測定点を設計します。［2］

    負荷ツールは、電源レールの出力の近くに置きます。接続経路の抵抗による電圧低下、IRドロップを小さくするためです。測定点へは専用の配線対を引き、どこの電圧を読み取るかも設計段階で決めます。負荷をかける位置と電圧を測る位置の両方を整えて、試験したい電源の状態を捉えます。［2］

    さらに、基板の層をつなぐビアに電流が偏らないか、配線の抵抗が最大負荷時の動作を妨げないかを、直流のシミュレーションで確認します。電圧の測定にはMMCX同軸コネクターや適切なアクティブプローブを使う案もあります。試験を自動化しても、その入口となる配線や測定方法が不適切なら、欲しい波形は得られません。［2］

    負荷を変えながら、電圧と電流を一緒に記録する

    試験の構成では、直流電源が負荷ツールと電圧レギュレーター（VR）へ給電し、信号発生器が負荷の変動を作ります。オシロスコープは出力電圧と、電流を知るためのシャント信号を記録します。操作画面であるGUIが、条件の変更と波形の取り込みをまとめて制御します。［2］

    資料の「3D Automation」は、この条件をプログラムで順に変える自動掃引の構想です。GUIでは負荷電流の最大値と増減の速さを設定し、周波数とデューティー比の開始・終了値を指定します。周波数は負荷変動を繰り返す速さ、デューティー比は一周期のうち負荷パルスがオンになっている時間の割合です。［2］

    掲載された3Dグラフは、周波数とデューティー比に対して、出力電圧の最大値がどう変わるかを立体的に表しています。この発表の3Dは、試験条件の自動掃引と応答の立体表示に関する表現で、半導体の積層構造を指してはいません。［2］

    たとえば、最大電流だけを合わせて一度測る試験では、繰り返し方を変えたときの電圧応答まではわかりません。周波数とデューティー比を順に変えれば、どの組み合わせで電圧が大きく変動するのかを探れます。自動化の狙いは、測定回数を増やすだけでなく、条件と波形を対応づけて比較しやすくすることにあります。

    基板・負荷ツール・操作画面を、共通の手順でつなぐ

    発表が目指しているのは、ASICの設計者、基板の設計者、負荷ツールの提供者が、同じ試験手順を共有できる環境です。仕様の読み取り、負荷ツールの選定、インターポーザー設計、測定系の構築、自動掃引を一続きにすることで、どこまで確かめたかを共有しやすくしようとしています。［2］

    発表時点では、負荷ツール、インターポーザー、GUIの設計プロセスを扱うOCP仕様を公開する計画が示されています。発表資料を、確定済みの仕様書として読むことはできません。AIで波形を識別して調整案を出すことも今後の可能性として述べられており、この資料には、試験時間の短縮率やAIによる判定精度の実測値は示されていません。［2］

    この提案から見えるのは、電源試験の自動化を支える基板と計測の大切さです。必要な負荷を作れること、そのときの電圧を正しい位置で測れること、条件を変えて同じ手順を繰り返せること。その三つをそろえるところから、AIチップの電源を確かめる仕組みは始まります。

    Googleの親会社Alphabetについて

    Googleを傘下に持つAlphabetの事業と収益構造は、cyclewaveの企業解説にまとめています。

    cyclewaveでAlphabetの企業解説を読む

    参考資料

    2026年8月11〜12日開催の発表資料をもとに構成。仕様公開とAI活用に関する記述は、発表時点の計画・提案です。

    1. Open Compute Project「2026 OCP APAC Summit」 — 公式イベント・発表資料一覧。
    2. Google「Interposer design flow with 3D Automation loading Slammer for ASIC/xPU.」 — Li-Chung（Leo）Chen、Jimmy Chen。公式一覧からリンクされたスライド。pp.3〜8：設計・試験手順と自動掃引、pp.9〜11：共通化と仕様公開の計画。
  • MicrosoftのAIエージェントによるサーバー検証、試験生成から不具合分類へ

    MicrosoftのAIエージェントによるサーバー検証、試験生成から不具合分類へ

    サーバーの不具合は、ハードウェア、ファームウェア、ソフトウェアのどれか一つに、きれいに分かれて現れるとは限りません。温度の変化、装置側のログ、ソフトウェアのエラーを別々に見ていると、同じ問題を何度も調べたり、必要な試験へたどり着くまでに時間がかかったりします。

    MicrosoftがOCP APAC Summitで示したのは、テスト生成と不具合分類を、層をまたぐ計測情報でつなぐ検証AIです。試験項目を一度作って終えるのではなく、結果や過去の不具合を次の検証へ戻す仕組みとして、自律検証エージェントを位置付けています。［1・2］

    簡単にまとめると？

    • Microsoftの検証AIは、装置の計測情報やログを、試験の生成・実行・不具合分類へつなぐ仕組みです。
    • 過去の不具合と人の確認を次の試験へ戻しますが、似たログだけで原因を確定するわけではありません。
    • 重複試験の削減はサンプルデータでの結果で、検証全体の短縮は予測値として区別されています。

    ログを並べるだけでなく、次の試験へつなぐ

    資料の検証ループは、ソフトウェアの不具合情報、ファームウェアのログ、ハードウェアのテレメトリーを入力にします。異常を見つけたら、その装置の条件に合う試験を起動し、過去の似た故障と関連付けて、原因を絞っていく流れです。［2］

    例として、ハードウェアとファームウェアの情報にメモリーエラーが現れた場合、ストレステストを実行し、過去の類似障害と照合する構成が描かれています。「エラーが出た」と記録するだけでなく、次に何を確かめるかまでつなぐ点が特徴です。［2］

    もちろん、同じようなログが出ていても、原因が同じとは限りません。似た事例は調査の手がかりであって、それだけで原因が確定するわけではないため、試験結果と人の判断を戻す経路も必要になります。

    TestGen.AIとBugEval.AIの役割

    資料では、検証シナリオを作るTestGen.AIと、不具合を評価・分類するBugEval.AIが示されています。意味の近い情報を探す検索や、過去の不具合のまとまりを使い、その時点で優先すべき試験や問題を選ぶ考え方です。［2］

    ここで大事なのは、過去に用意した試験だけを引き継ぐのではなく、前の世代で見逃した不具合も、次の世代の試験へ反映することです。資料は、過去世代の故障パターンを調べ、試験と変更提案を作る流れを示しています。［2］

    Microsoftの関連ブログも、こうしたエージェントを社内の検証・プラットフォーム開発で使う仕組みとして説明しています。公開資料に名前が出ていることと、そのまま利用できる一般向け製品であることは別です。［3］

    CPUの温度保護を、生成から再試験までたどる

    具体例は、CPUのサーマルトリップ点、つまり温度保護が作動する条件の検証です。まずTestGen.AIが試験を生成し、実行を統括するオーケストレーターが対象のハードウェアへ割り当てます。装置で負荷を動かし、温度の計測情報を集めます。［2］

    次にBugEval.AIが、集まった情報を判定条件と照合し、合否と診断に役立つ情報を返します。不合格なら、その結果を使って試験を調整し、再試験へ進みます。試験生成、実行、計測、評価を、ひと続きに扱う構成です。［2］

    この資料には、具体的な温度閾値や負荷条件までは示されていません。ここで示されているのは検証の組み立て方であり、個々のCPUで保護機能を試すための操作手順ではありません。

    試験を減らすときは、見逃しを増やしていないかを見る

    資料は、サンプルデータセットで重複する試験の実行を30％減らしたとしています。一方、検証サイクル全体を40％短くするという数字には、予測値と明記されています。評価対象の規模や詳細な比較条件も、このスライドだけでは分かりません。［2］

    試験の数や時間が減るだけでは、品質が良くなったとは判断できません。必要な不具合を引き続き見つけられるか、過去に見逃した条件を追加できたか、誤った分類が増えていないかも合わせて見る必要があります。これは、資料の効率改善を実際の検証へ持ち込むときの確認点です。

    変わりやすいハードウェア構成やファームウェアの条件を、試験結果と一緒に残すことも欠かせません。前の環境で役立った試験が、次の環境でも同じ意味を持つとは限らないからです。

    人の判断を残しながら、検証のつながりを短くする

    資料のループには、人が結果を確認し、学習へ戻す段階が含まれています。AIが情報を集め、似た不具合を整理し、試験の候補を用意する。その先の設計判断まで、根拠が追える状態にしておく構成です。［2］

    検証AIの価値は、試験を自動で増やすことだけではありません。過去に分かったことを、いま必要な試験へ結び直すことにあります。ハードウェアとソフトウェアを一緒に設計するなら、検証もまた、それぞれの情報をつないで進める必要があります。

    Microsoftの事業をもう少し知る

    Azureを含むクラウド、業務ソフト、Windowsなど、Microsoft全体の事業についてはcyclewaveの企業解説にまとめています。

    Microsoftの企業解説を読む

    参考資料

    2026年9月27日確認。講演の公開スライドをもとに構成しています。

    ［1］Open Compute Project：2026 OCP APAC Summit 公式セッション一覧

    ［2］Microsoft：Embedding Intelligence into Hardware-Software Co Design Through Autonomous Validation Agents（講演スライド）

    ［3］Microsoft：Driving Efficiency in Modern System Engineering with AI Agents