全組み合わせで安全を証明する ― 権限判定を高速化した時のテスト設計

権限の判定を速くするとき、私たちは「洗い出した条件の範囲では、答えが1つも変わらないこと」をテストコードで機械的に確かめてから出すことにしました。判定に効く条件をすべて掛け合わせた384通りを全件確かめ、さらにテストそのものを13種類の「わざと壊した実装」で試しています。この記事では、その設計と、リリース前にテストの網の目の穴まで潰した経緯を紹介します。

※記事中のコード例は、説明のために簡略化した架空のものです。

なぜ権限判定を速くしたかったのか？

ピジョンクラウドは、800以上の企業が使うマルチテナントのWebデータベースです。テーブル、レコード、項目ごとに「誰が見られるか」「誰が編集できるか」を細かく設定できます。

この判定は、ほぼすべてのリクエストで何度も走ります。そこで、1回のリクエストの最初に「このユーザーがどのグループ・部署に属しているか」をまとめて読み込み、その結果を使い回す方式に変えました。私たちはこれを「スナップショット方式」と呼んでいます。

// リクエストの最初に、所属情報を1回だけ読み込む
$membership = MembershipSnapshot::loadFor($currentUser);

foreach ($records as $record) {
    // 以降の判定は、読み込み済みの所属情報だけで行う
    $canView = $accessRule->canView($record, $membership);
}

「数社で試して一致した」は証明になるのか？

権限は、1か所でも判定がずれると、見えてはいけないデータが見えてしまいます。速くなっても、答えが1つでも変わったら意味がありません。

そこで今回は、サンプルでの確認を主な根拠にしない、と決めました。代わりに、判定に効く条件をすべて洗い出し、組み合わせを全部テストコードで確かめる方針をとっています。

384通りの全組み合わせテストはどう作ったのか？

まず、判定の結果を左右する条件を1つずつ書き出しました。条件ごとの取りうる値を掛け合わせると、ちょうど384通りになります。今回の検証では、この384通りを全件確かめました。

次に、高速化した実装とは別に、「この条件ならこうなるべき」を素直に書いた正解の定義（参照実装。テストオラクルとも呼ばれます）を用意しました。速さは気にせず、仕様をそのまま読める形で書いたものです。384通りすべてで、実装の答えと正解の定義の答えを突き合わせます。

// 384通りをすべて生成し、1件ずつ突き合わせる（架空の簡略化コード）
foreach (allCombinations() as $case) {
    $expected = referenceRule($case);   // 仕様を素直に書いた「正解の定義」
    $actual   = fastRule($case);        // 高速化した実装
    assertSame($expected, $actual, describe($case));
}

テストが正しいことは、どう確かめたのか？

全件が一致しても、まだ安心はできません。正解の定義を置くだけでは、テストが実装の誤りを本当に見分けられるかまでは分からないからです。そこで、テストが代表的な誤りを検知できるかを確かめることにしました。

この考え方は、一般にミューテーションテストと呼ばれます。下の表は理解のための仮想の例で、実際に作った13種類の内訳ではありません。

実際の検証では13種類の壊れた版を用意し、13種類すべてをテストが検知することを確認しました。

リリース前に見つけた「網の目の穴」とは？

13種類の確認に加えて、実装を1行ずつ壊して同じことを試しました。すると、1か所だけ、壊してもテストが通ってしまう行が見つかりました。

本番に出る前の段階だったので、すぐにこの誤りを検知するテストを追加しました。そのうえで、13種類と1行ずつの壊し方のすべてを検知できる状態になったことを確かめてから、リリースに進んでいます。

// 追加したテストのイメージ（架空の簡略化コード）
public function test部署だけのグループ(): void
{
    // 個人のメンバーは0人、部署だけが所属しているグループ
    $group = makeGroup(users: [], departments: [$salesDept]);
    $user  = makeUser(department: $salesDept);

    // 部署を通じた所属として判定され、正解の定義と一致すること
    $case = caseFor($user, grantedTo: $group);
    assertSame(referenceRule($case), fastRule($case));
}

テストが全部通ることと、テストが十分であることは別の話です。わざと壊してみることで、その差を事前に埋められました。

速さより先に決めていたことは何か？

高速化の設計では、速さより先に「失敗したときにどちらへ倒れるか」と「どう出していくか」を決めていました。

最終的に、関連するテスト458件・922アサーション（検証条件）がすべて通過しました。レビューの指摘もすべて解消してから出しています。

人とAIは、どう役割を分担したのか？

384通りの突き合わせや、13種類の壊れた版での確認は、毎回人の手だけで回すには手間のかかる作業です。そこで今回は、安全の基準は人が決め、実装と検証の手間はAIに担わせるという分担で進めました。AIには、統括・実装・レビューの3つの役を分けて持たせています。

実装とは別の会話で行った設計レビューでは、重大な指摘が4件出ました。その1件が「新旧で答えが変わらないことを、網羅的なテストで担保すべき」というものです。ここから、384通りの全組み合わせテストと、テストを疑う13種類の壊れた版での検証が生まれました。

人だけでは手が回らない量の検証を、実装とは別の会話での設計レビューと、統括役による再実行・破壊確認を重ねることで確保しています。

ほかの改修でも同じ考え方は使えるのか？

使えます。別の、権限の「所有者」判定に関わる変更でも、同じ検証の型を使いました。ポイントは、変更前のコードの結果を「正解の記録」として残しておくことです。

3番目は、テストが変更点を本当に検出できるかを見る確認です。変更前のコードで失敗しないテストは、変更の効果を確かめられていません。

よくある質問

まとめ：テストで両立させる速さと安全

「速さ」と「安全」はトレードオフではなく、網羅的なテストと段階的な公開によって両立できます。今回は、条件を洗い出して全組み合わせを確かめ、テストそのものをわざと壊した実装で試し、リリース前に網の目の穴まで潰しました。基準と最終判断は人が持ち、手間のかかる実装と検証はAIに担わせることで、この徹底を毎回続けられる形にしています。

お客様の大切なデータを預かるSaaSとして、ピジョンクラウドはこうした見えにくい部分に手間をかけています。権限設定を細かく作り込みたい方は、30日間の無料トライアルで実際の設定画面をお試しください。