GitHubで公開された「Distributed Systems Testing Skills」は、Claude Code、Copilot CLI、Cursor、Geminiなど主要AIコーディングエージェントが分散・ステートフルシステムのテストを「クレーム駆動」で自律設計・実行できるSKILL.mdファイル群だ。

分散システムテストの「本当の難しさ」

分散システムのバグは、通常の統合テストではほとんど検出できない。本番環境で実際に問題を引き起こすのは以下のような再現性の低い複合障害だ。

  • 部分的なネットワーク分断（ノード間の通信が途中で切れる）
  • 非決定的な並行処理（タイミング依存の競合）
  • クラッシュ・リカバリ（書き込み途中のノード再起動）
  • アップグレード・ロールバック時の不整合
  • リプレイ下でのべき等性（idempotency）の破れ

「統合テストを数本書いて完了」という従来アプローチでは、こうした本番障害の大半を発見できない。このプロジェクトはその問題に正面から向き合った設計になっている。

SKILL.md——AIエージェントが読む「実行可能な手順書」

このOSSの本質は「MarkdownとシェルをサポートするAIエージェントなら何でも動く」汎用設計だ。2本のSKILL.mdファイルで構成される。

第1スキル: テスト計画設計 製品が保証している「クレーム（約束）」を起点に仮説を立て、各クレームを反証するシナリオを設計する。整合性が重要なシナリオには、抽象モデル（register / queue / log / lock / lease / ledger など）、オペレーション履歴スキーマ、名前付きチェッカー（linearizability、serializability、session-consistency など）、ネメシス（障害注入）をセットで紐付ける。

第2スキル: テスト計画実行 エージェントがまず既存のテスト・ランブック・フォルト注入スキャフォールディングを探索し、新規実装の前に再利用できるものを特定する。その上でシナリオを順次実行し、発見レポートを生成する。

「クレーム駆動テスト」とはなにか

このプロジェクトの核心概念が Claim-Driven Testing（クレーム駆動テスト） だ。

従来のTDD（テスト駆動開発）が実装コードのふるまいを起点とするのに対し、クレーム駆動テストは製品・サービスが外部に対して保証していることを起点にする。各シナリオはクレームの名前を冠し、そのクレームを特定の障害条件下で「反証しようとする」。

たとえば「書き込みが完了したら永続化される」というクレームに対しては「書き込み直後にノードをクラッシュさせたとき、データは失われないか」というシナリオが生成される。クレーム名がそのままシナリオ名になるため、テストが形骸化したり「なんとなく通った」扱いになりにくい。

10状態の判定と責任の明示

注目すべきもう一つの特徴が 10状態の判定（10-state verdict） と SUT（テスト対象）/ハーネス/チェッカー/環境の責任分類 だ。

従来のテストは「PASS」か「FAIL」しかない。このシステムでは「カオステストスクリプトが問題なく完走した」と「クレームが障害に耐えた」を明確に区別する。FAILが発生した場合、原因がシステム本体なのか、テストハーネスのバグなのか、チェッカーのロジックなのか、環境的な問題なのかを分類して記録する。これにより、次の担当者がゼロから原因調査をする必要がなくなる。

テスト計画書の構造

設計スキルが生成する計画書（testing-plans/<slug>.md）は §0〜§7 の章立てで構成される。

セクション 内容

§0 アーキテクチャサマリー（実際の構成）

§1b テスト対象クレーム一覧（テストの背骨）

§1c ドキュメントとコードのドリフト発見

§3 既存テストインベントリ

§5 カバレッジマトリクス（クレーム×仮説）

§7 シナリオ定義

計画書の末尾には「このシナリオセットがリリース判断に十分か」というカバレッジ妥当性の論証と「何が未検証のまま残るか」の誠実な列挙が含まれる。レビュアーはこの2つの成果物を読むだけで出荷判断が下せる設計だ。

実務への影響

日本のエンジニア・IT管理者にとっての実践的なポイントを整理する。

  • 今日から試せる: 既存のAIコーディングエージェントにSKILL.mdを読ませるだけで動く。新しいツールの導入は不要
  • 既存資産の再利用が前提: 実行スキルは既存のテスト・ランブック・フォルト注入スクリプトを最初に探す。一から書き直す必要はない
  • 一貫性モデルの明示化: linearizability（線形化可能性）、serializability（直列化可能性）など分散システム理論の概念をシナリオに紐付けることで、テストの意味が明確になる
  • マルチエージェント分業: 一方のエージェントが計画書を書き、別のエージェントが実行するという役割分担も可能

筆者の見解

分散システムのテストは長年「一部のベテランだけが持つ暗黙知」の領域だった。Jepsenのようなツールは強力だが、設計・解釈に深い専門知識が必要で、多くのプロジェクトで現実的に適用できなかった。

このSKILL.mdアプローチが興味深いのは、専門知識を「エージェントが実行できる手順書」に落とし込んだ点だ。AIエージェントが単発の指示を処理するだけでなく、クレームの策定→シナリオ設計→実行→判定→報告というループを自律的に回す。これは「エージェントが自己完結したループで動き続ける」ハーネスループ設計の実例として非常によくできている。

日本のシステム開発現場では、分散システムのテストが「なんとなく動いているからOK」で済まされているケースが今も多い。AIエージェントの使い道はコードを書くことだけではない。テスト設計の民主化・障害分析の体系化こそ、エージェントが最も価値を発揮できる領域のひとつだ。こうした仕組みが普及することで、専門家でなくても高品質な分散システムテストを実施できる時代が近づいている。

出典: この記事は Testing distributed systems with AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。