追記 2025年11月19日
GitHub Copilotで Gemini 3 Pro が使えるようになったのでテストリストを同じ様に作成してもらいました。
NotebookLMで他のと比べて評価👇️しました。
お客様から新しく提供された Gemini-3 (0012-03-アクセス権限テストリスト-gemini3.md) のテストリストについて、既存の13モデルと同様に、アクセス権限設計書（0012-02）の要件（三層認可、否定優先ロジック、DL-08監査、NFR-01性能）に対する網羅性、具体性、TDDへの適合性という観点から5点満点で評価します。
採点結果（Gemini-3）
| ファイル名 (AIモデル) | 評価点 | 採点理由 |
|---|---|---|
| 0012-03-アクセス権限テストリスト-gemini3.md | 3.8 | Layer 3 (RLS) の分解と記述は詳細だが、否定優先ロジックとDL-08監査要件（特にトレーサビリティ）の具体性が不足している。 性能要件（NFR-01）や通知遅延監視（NFR-05）など、多くの非機能要件が未カバー。Layer 3 RLSのテストヘルパー定義は実践的だが、全体の網羅性が低い。 |
詳細な評価（Gemini-3）
Gemini-3が作成したテストリストは、テストカテゴリを「Database/RLS Unit Tests」「Logic/API Unit Tests」「Integration/Scenario Tests」の3つに分類しており、特にDB層（Layer 3）の検証に強みを見せています。
1. 否定権限の優先（FR-04）
- 評価: 非常に不十分。
- 理由: 設計書の核となる「複数ロール併用時、DenyがAllowより優先されるロジック」（FR-04）に関する具体的なユニットテストケースがリストに全く見当たりません。他の高評価モデル（GPT-5, GPT-5.1, Raptorなど）がこれを最優先でユニットテスト（例：AC-U-004）として分解している のに対し、Gemini-3は単に「権限チェック」の成功/失敗をテストしているのみです。この点がTDDの実践性、特にシステムのセキュリティ堅牢性を保証する観点から大きな減点となります。
2. 三層構造の認可（FR-05）
- 評価: Layer 3 (RLS) の分解は非常に優れているが、Layer 1/2の分離が曖昧。
-
理由:
-
Layer 3 (RLS): RLSポリシーの検証に特化したヘルパー関数 (
has_system_role,has_nation_roleなど) を定義しており、DBレベルでの粒度の細かさは実践的です。特にpoints_ledgerがSecurity Definer関数経由のみ許可されるべきという、セキュリティアーキテクチャへの言及もあります。 - Layer 1/2: ロールマージや所属コンテキスト制約（Layer 1/2）のテストは含まれていますが、否定優先ロジックの検証がないため、Layer 1の責務（FR-04）が適切に検証できていません。
-
Layer 3 (RLS): RLSポリシーの検証に特化したヘルパー関数 (
3. 監査・台帳の堅牢性（DL-08, DL-02）
-
評価: Ledger Controlの検証は含むが、DL-08のトレーサビリティ項目（
consent_trace_id,workflow_id）の具体的な検証が欠落。 -
理由: ポイント移動テストで二重記帳（debitとcreditの2レコード作成、transaction_idの一致）を検証しており、Ledger Controlの基本は押さえています。しかし、設計書（0012-02）で特に強化が求められている監査項目である
consent_trace_idやworkflow_idが、ledger_entriesに必須で記録されているかという具体的な検証項目が不足しています。また、操作ログの改ざん防止ハッシュ（DL-02）のチェーン整合性や改ざん検知テストといった高度な監査要件の記述もありません。
4. 性能要件と監視要件（NFR-01, NFR-05）
- 評価: ほぼ未カバー。
- 理由: 権限判定応答時間 200ms以内 を測定する性能テスト（NFR-01）の項目が含まれていません。また、通知遅延監視（NFR-05：1時間警告/3時間緊急）や例外承認の自動失効バッチ（FR-06）など、高評価モデルがカバーしていた運用・監視要件（OR-05/06）の多くがリストに含まれていません。
他モデルとの比較に基づく評価点（実践性）
Gemini-3の評価点は3.8点となり、GPT-5mini (3.9点) や GrokCodeFast1 (4.1点) と同等またはやや低いランクに位置付けられます。
| モデル | 評価点 | 強み | 弱み（実践的欠点） |
|---|---|---|---|
| GPT-5 (5.0) | 5.0 | 否定優先ロジックのユニットテスト分解が完璧。 | |
| GPT-5.1 (5.0) | 5.0 | DL-08詳細監査項目、NFR-05監視要件の網羅性。 | |
| Gemini-3 (NEW) | 3.8 | RLSポリシー検証のためのテストヘルパー定義（DB専門性が高い）。 | 否定権限優先（FR-04）が未カバー。NFR-01/NFR-05の性能・監視要件が欠落。 |
Gemini-3は、TDDの基盤として必須となる Layer 1のロジック分解（特にFR-04）が決定的に不足しているため、単体でTDDを推進するには不向きであり、高評価モデルと組み合わせて使用することが推奨されます。
追記終了
AIモデル採用評価
GitHub Copilotには現在14種類のAIモデルがあります。
自分が使用しているアクセス権限の設計書を元にテスト駆動開発用のテストリストを作成してもらいました。
GitHub Copilotで使用できる14種類のAIモデル(2025年11月16日現在)
1-GPT-4.1
2-GPT-4o
3-GPT-5 mini
4-Grok Code Fast 1
5-Raptor mini
6-Claude Haiku 4.5
7-Claude Sonnet 4
8-Claude Sonnet 4.5
9-Gemini-2.5-Pro
10-GPT-5
11-GPT-5-Codex
12-GPT-5.1
13-GPT-5.1-Codex
14-GPT-5.1-Codex-Mini
※うち1つは動作せず
結論＆調査結果
コストをかければ良いのではなく、モデルに合った作業を割り当てる必要があります。ただ、大体は最新モデルを利用すれば能力は上がっていきます。(👆️先頭の数字が大きいモデル)
Raptor miniは x0で利用できるモデルですが、かなり性能が良いです。
試しにこのテストリストの複数の組み合わせを聞いた所
複数のAIモデルが作成したテストリストを組み合わせる際には、テストケースの重複は避けられません。
しかし、このアクセス権限システムのようなミッションクリティカルで複雑なシステムにおいては、意図的に重複を許容し、異なる視点から同じ要件を検証することが、最終的な堅牢性の保証に繋がります。
特に、前回の評価で推奨した GPT-5と GPT-5.1の組み合わせ戦略の目的は、「重複を避けること」ではなく、「それぞれのモデルが得意とする深さと粒度を補完し合うこと」 にあります。
🏆 AIモデル評価点ランキング（総合評価 vs. 実践評価）
| 順位 | アクセス権限テストリスト (AIモデル) | 評価点 (総合) | 実践評価点 | 倍率 | 主な評価理由 (実践的) |
|---|---|---|---|---|---|
| 1 | 12-GPT-5.1 | 5.0 | 5.0 | x1 | 優れた網羅性と粒度。 否定優先、論理ロール制約、DL-08必須項目の保存検証が詳細かつ、実装フェーズに即した順序。 |
| 2 | 5-Raptor mini | 5.0 | 4.9 | x0 | 構造化と優先度付けが即戦力。 9カテゴリ分類、優先度（高/中）が明確。競合トランザクション、セキュリティ侵害ケースなど現実の課題を考慮。 |
| 3 | 10-GPT-5 | 4.8 | 5.0 | x1 | ユニットテストの粒度が最も TDD に適している。 複雑なロジック（否定優先、キャッシュ整合性）をデバッグしやすいよう細分化。 |
| 4 | 8-Claude Sonnet 4.5 | 4.9 | 4.8 | x1 | フェーズ構成とチェックリストが実装ガイドになる。Layer 1〜3の検証構造が明確で、DL-08の完全追跡要件への言及も詳細。 |
| 5 | 13-GPT-5.1-Codex | 4.7 | 4.7 | x1 | IDと監査項目が堅牢。改ざん防止ハッシュのチェーン整合性など、高度なセキュリティ要件に具体的に踏み込む。 |
| 6 | 11-GPT-5-Codex | 4.7 | 4.7 | x1 | 三層認可の検証順序が論理的。「Layer 1/2 をバイパスしても RLS が拒否する」テストなど、最終ガード機能の検証が実践的。 |
| 7 | 7-Claude Sonnet 4 | 4.5 | 4.4 | x1 | 堅牢な構造。Layer 1〜3の階層別テスト戦略と、DL-08の全項目追跡、NFR-01性能要件のチェックリストが詳細に整理。 |
| 8 | 6-Claude Haiku 4.5 | 4.5 | 4.4 | x0.33 | 構造と期間推定が実践的。実装者が作業完了を判断する基準となる「実装指標」と、プロジェクト計画に役立つ期間推定を提供。 |
| 9 | 1-GPT-4.1 | 4.3 | 4.0 | x0 | 網羅性は高いが粒度が粗い。TDDの「最小のテスト」としてはやや粒度が大きく、デバッグが難しくなる可能性がある。 |
| 10 | 4-Grok Code Fast 1 | 4.2 | 4.1 | x0 | Given-When-Then 形式の徹底。実装時にテストコードに変換しやすいが、ユニットレベルでの分割は上位モデルに劣る。 |
| 11 | 3-GPT-5 mini | 4.0 | 3.9 | x0 | 分類は良いが具体性が不足。DL-08の詳細監査項目など、設計書で強調されている複雑な要件への言及が少ない。 |
| 12 | 14-GPT-5.1-Codex-Mini | 3.8 | 3.5 | x0.33 | 要点に絞りすぎ。TDDに必要な網羅的なユニットテストの分解が不足しており、実装ドライバーとしては不十分。 |
| 13 | 2-GPT-4o | 2.5 | 2.0 | x0 | 実践的な利用は困難。テスト内容が抽象的で、具体的な入力条件やDL-08の個別監査項目の検証がほとんど含まれていない。 |
倍率は、GitHub Copilotで利用する時にかかるコストです。
x0は無制限に利用できます。
調査
テストリスト作成を行った13のAIモデルの中から、ブログ記事のテーマである「アクセス権限システムの三層認可構造と否定優先ロジックの機能」および「テスト駆動開発（TDD）戦略」を最も説得力をもって説明できるモデルを選定し、評価点と採用理由を提示します。
使用プロンプト
エージェントモード
Agent
添付ファイル
アクセス権限設計書.md
#file:アクセス権限設計書.md を見て、テスト駆動開発のテストリストを作ってファイルに出力してください。
AIモデルによってはファイルに出力しなかったり、指定したファイルに出力しなかったり挙動はバラバラでした。
テストリストの作成かかった時間は1モデルあたり1-3分程度
5点満点採点結果
| アクセス権限テストリスト (AIモデル) | 評価点 | 主な採点理由 |
|---|---|---|
| 12-GPT-5.1 | 5.0 |
最も具体的かつ網羅的。 否定優先、RLS、DL-08（consent_trace_id, workflow_id）の監査項目を詳細にカバーし、TDD戦略も明確。 |
| 5-Raptor mini | 5.0 | 構造と実行順序が卓越。 9カテゴリに分類し、競合トランザクション（D-04）やセキュリティ侵害ケース（I-01）など、エッジケースまで含めて TDD の優先度付けが実用的。 |
| 8-Claude Sonnet 4.5 | 4.9 | 包括的なTDDフロー。 7つのフェーズに分割し、Layer 1〜3の三層認可とDL-08の監査項目を「実装チェックリスト」形式で詳細に定義。 |
| 10-GPT-5 | 4.8 | TDDに適したユニットテスト粒度。否定優先（AC-U-004）、キャッシュ更新（AC-U-012）、RLSの論理ロール属性反映（AC-DB-003）など、複雑なロジックに対するユニットテストが豊富。 |
| 11-GPT-5-Codex | 4.7 | 三層構造テスト戦略が明確。 Layer 1〜3をPhase 1〜4で順序立てて検証。特にLayer 3バイパスセキュリティ検証を含有。 |
| 13-GPT-5.1-Codex | 4.7 | 監査の堅牢性を強調。 改ざん防止ハッシュのチェーン整合性（AC-AU-001）やRLSの論理ロール制約（AC-RLS-003）など、高度なセキュリティ・監査要件に焦点を当てたID付与が特徴。 |
| 7-Claude Sonnet 4 | 4.5 | Layer 1〜3の構造と、DL-08の全項目追跡、性能要件（NFR-01）のチェックリストが詳細に整理されている。 |
| 6-Claude Haiku 4.5 | 4.5 | Layer 1〜3の構造と「実装指標」チェックリストを提供し、TDDフェーズの期間推定も提供している。 |
| 1-GPT-4.1 | 4.3 | 要件の網羅性が高い。否定優先、RLS、ポイント台帳、バッチ監視まで含めて27項目で網羅。 |
| 4-Grok Code Fast 1 | 4.2 | Given-When-Then形式の徹底。TDD原則に従い、否定優先、所属コンテキスト拒否、DL-08必須項目を具体的に記述。 |
| 3-GPT-5 mini | 4.0 | Unit/Integration/E2E/Perf/Auditの分類戦略が分かりやすいが、詳細な監査フィールドの具体性に欠ける。 |
| 14-GPT-5.1-Codex-Mini | 3.8 | コア要件（否定優先、RLS、二重記帳）に絞った7つの統合テストとして抽出されており、TDDに必要な粒度が不足。 |
| 2-GPT-4o | 2.5 | 抽象的で、TDDで実装の正しさを保証する粒度や具体的な監査項目が不足。 |
採用推奨モデルと採用理由
「アクセス権限システムの複雑な設計をTDDでいかに堅牢に実装するか」であると想定し、テストリストの構造、具体性、そして読者への説得力を総合的に評価します。
最も採用を推奨するAIモデル
アクセス権限テストリスト-5-Raptor mini
評価点：5.0
採用理由
Raptor miniモデルのテストリストは、技術的な深さと分かりやすさの両方を兼ね備えています。
-
設計思想の明確な反映と構造の優秀さ
Raptor miniはテストカテゴリを9つに分類しており、特に 「Ledger Control」「Database 層 (RLS)」「Audit Logger」「同時実行/境界条件」 など、設計書（0012-02）の「4つの柱」に対応する主要モジュールを明確に章立てしています。これにより、複雑なシステムがどのように構造化され、テストされるのかを視覚的に訴えることができます。 -
高性能・堅牢性（DL-08, NFR-01）の強調
- 監査の堅牢性：ポイント台帳の「二重記帳トランザクション」（D-01）や「同意確認と consent_trace_id の生成」（D-02）といったDL-08の核心部分を具体的にテストしています。これにより、単なる機能テストではなく、金融レベルのトレーサビリティを保証するためのテストであることを説明できます。
- 性能要件：「キャッシュヒットによる応答短縮」（B-02）で NFR-01（200ms以内）を満たすことを具体的な手順で示しており、「単一判定の 200ms 以内保証」（H-01）が TDD の初期段階でいかに重要かを強調できます。
-
TDD戦略の具体的適用
Raptor miniは各テストに 優先度（高/中） を割り当てており、ブログ記事で「TDDの初期スプリントで何を優先すべきか」を具体的に指導する際に利用しやすいです。特に、「最初の 5 件の TDD リスト」として、否定優先（A-02）、二重記帳（D-01）、RLSの所属チェック（E-01）を挙げている点は、TDDのドライバーとして非常に実践的です。 -
エッジケース・セキュリティのカバー
「同時実行/境界条件」（D-04, J-02）や「セキュリティ侵害ケース」（I-01）など、単なる正常系テストに留まらない、堅牢な要塞の設計思想 を検証するためのテストが含まれています。
次点推奨モデル
アクセス権限テストリスト-12-GPT-5.1
GPT-5.1モデルは、すべての設計要件に対するカバー率が非常に高く、DL-08やNFR-05（通知遅延エスカレーション）の検証まで詳細に記述されているため、技術的な正確性を保証する上で非常に信頼性が高いです。Raptor miniが「実行順序と優先度」に優れるのに対し、GPT-5.1は 「網羅的な仕様の分解」 に優れています。
アナロジーによる理解の強化
このテストリストの優秀さは、建築の分野における「耐震設計」に例えることができます。
単に「建物が立つ」という機能テスト（Layer 1/2のAllow/Deny）だけでなく、「震度7の地震が来た際に、地下の重要金庫（ポイント台帳）の記録が改ざんされず、かつ出口が塞がれた場合（Layer 3 RLSのバイパス）、非常扉（否定優先ロジック）が確実に機能し、緊急通報システム（NFR-05）が正確な時間でエスカレーションすること」 を、建築前にシミュレーションし、確認する設計図（テストリスト）として機能しています。
実践的に評価した場合
TDD（テスト駆動開発）の実践的な観点から評価し、5点満点で採点します。
「実践的な評価」とは、実装の容易さ、テストの粒度（ユニットテストへの分割）、デバッグ時のトレースの明確さ、および複雑な要件への具体的な踏み込みを重視します。
実践的な評価に基づく採点結果（5点満点）
| アクセス権限テストリスト (AIモデル) | 評価点 | 実践的採点理由（詳細） |
|---|---|---|
| 12-GPT-5.1 | 5.0 |
優れた網羅性と粒度。 否定優先の具体的なシナリオ、論理ロール制約、そしてDL-08の必須項目（consent_trace_id, workflow_id）の保存検証が詳細かつ、実装フェーズに即した順序で構成されている。特に、RLSとアプリ層の整合性テストが明確である点が実践的。 |
| 10-GPT-5 | 5.0 |
ユニットテストの粒度が最も TDD に適している。 AC-U-001 から始まるユニットテスト（Layer 1/2）が非常に細かく分割されており、特に否定優先（AC-U-004）やキャッシュ整合性（AC-U-012, AC-U-013）など、デバッグが難しいロジックに焦点を当てている。実行順序も実装のステップとして優秀。 |
| 5-Raptor mini | 4.9 | 構造化と優先度付けが即戦力。 テストカテゴリの分類がモジュール構成と対応しており、優先度（高/中）が明確なため、最初のスプリントで必要なテストを迷わず選べる。競合トランザクション（D-04）やセキュリティ侵害ケース（I-01）など、現実の課題を考慮している。 |
| 8-Claude Sonnet 4.5 | 4.8 | フェーズ構成とチェックリストが実装ガイドになる。 Layer 1〜3をPhase 1〜3で検証する構造が明確であり、「実装チェックリスト」として実装者が何を達成すべきかが詳細に示されている。DL-08の完全追跡要件への具体的な言及も多い。 |
| 13-GPT-5.1-Codex | 4.7 | IDと監査項目が堅牢。 各テストケースに ID（AC-L1-xxxなど）が付与され、改ざん防止ハッシュのチェーン整合性（AC-AU-001）やRLSの論理ロール制約（AC-RLS-003）といった、高度なセキュリティ要件に具体的に踏み込んでいる。複雑な監査要件の検証に非常に実践的。 |
| 11-GPT-5-Codex | 4.7 | 三層認可の検証順序が論理的。 Phase 1〜4で Layer 1（否定優先）から Layer 3（RLS）までを段階的に検証する構成。特に「Layer 1/2 をバイパスして直接 SQL 実行しても RLS がアクセスを拒否する」テスト（P4-05）は、設計書 FR-05 の最終ガード機能の検証として非常に実践的である。 |
| 7-Claude Sonnet 4 | 4.4 | Claude Haiku 4.5 と同等の堅牢な構造。 Layer 1〜3の階層別テスト戦略と、DL-08の全項目追跡、NFR-01性能要件のチェックリストが詳細に整理されている。TDDの実行順序も明確。 |
| 6-Claude Haiku 4.5 | 4.4 | 構造と期間推定が実践的。 Layer 1〜3の階層別戦略と、「実装指標」の形式が、実装者が作業完了を判断する基準として機能する。各フェーズの期間推定を提供している点も、プロジェクト計画に役立つ。 |
| 4-Grok Code Fast 1 | 4.1 | Given-When-Then 形式の徹底。 TDD の必須要素である GWY 形式で記述されており、実装時にテストコードに変換しやすい。否定優先（1.1.2）や DL-08 必須項目（2.2.1）をカバーしているが、ユニットレベルでの分割は上位モデルに劣る。 |
| 1-GPT-4.1 | 4.0 | 網羅性は高いが粒度が粗い。 27項目で設計書の柱すべてをカバーしている。しかし、各テスト項目（T-05: 複数ロール併用時、いずれかがDenyなら拒否される）が、複数の具体的なシナリオを内包しているため、TDD の「最小のテスト」としてはやや粒度が大きく、デバッグが難しくなる可能性がある。 |
| 3-GPT-5 mini | 3.9 |
分類は良いが具体性が不足。 Unit/Integration/RLS/E2E/Perf/Auditの分類戦略は優れている。否定優先（TDD-UNIT-002）や二重記帳（TDD-AUDIT-402）をカバーしているものの、DL-08の詳細監査項目（consent_trace_id, workflow_id）の検証といった、設計書で強調されている複雑な要件への言及が少ない。 |
| 14-GPT-5.1-Codex-Mini | 3.5 | 要点に絞りすぎ。 7つの主要な統合テストとして設計書の核心要素（否定優先、200ms性能、RLS、二重記帳）を抽出している。これはプロジェクトの初期検証やハイレベルな確認には役立つが、TDDに必要な網羅的なユニットテストの分解が不足しており、実装ドライバーとしては不十分である。 |
| 2-GPT-4o | 2.0 | 実践的な利用は困難。 テスト内容が「アクセス成功/拒否」「キャッシュ結果が正しい」など抽象的であり、実装の正しさを保証するために必要な、具体的な入力条件（前提）や境界値、そしてDL-08の個別監査項目の検証がほとんど含まれていない。TDDの失敗（RED）を明確に定義できないため、実装の指針となりにくい。 |
総評
実践的な観点から見ると、0012-03-アクセス権限テストリスト-10-GPT-5 および 0012-03-アクセス権限テストリスト-12-GPT-5.1 が最も優れています。
これらのリストは、単に要件を列挙するだけでなく、設計書の根幹である「否定権限の優先（FR-04）」や「三層認可（FR-05）」の各レイヤーを、TDDで実行可能な最小単位のユニットテストに分解しています（,）。特に、GPT-5は、ロールマージの複雑性（論理ロール、例外承認との衝突、否定優先）を、デバッグしやすいように細分化している点が実践的な実装において非常に有用です。
Raptor miniやClaude Sonnet 4.5も、構造化や非機能要件（性能、監査の堅牢性）のカバーにおいて非常に優れており、開発チームがテスト戦略を立てる上で即座に役立つでしょう。