2026 年 5 月、GitHub Blog が Validating agentic behavior when “correct” isn’t deterministic を公開し、「決定論的な正解がない領域で AI エージェントの挙動を検証する」方法論として Trust Layer と dominatory analysis を提示しました。「同じ入力でも複数の正解があり得る」エージェント時代に、従来のユニットテストでは品質を担保できないことが公式に認められた格好です。
弊社では、Claude Code / GitHub Copilot / Cursor / Codex を組み込んだ受託案件が日常になり、「AI が書いたコードが正しい」と顧客に説明する根拠が必要不可欠になりました。本記事では、Trust Layer を受託に組み込むための評価基盤、契約条項、運用ダッシュボードの設計を整理します。
なぜ「正解が一意ではない」のか
エージェントの出力は、以下の 3 つの軸で揺らぎます。
| 揺らぎの軸 | 例 | 受託への影響 |
|---|---|---|
| 生成の非決定性 | 同じプロンプトでも別のコードが出る | テストの再現が難しい |
| 複数の正解 | 同じ仕様でも実装方針が複数ある | レビューの基準が揺らぐ |
| 環境依存 | OS / ライブラリ版で挙動が変わる | 検証コストが上昇 |
特に 複数の正解問題は受託で深刻で、「テストはパスするが顧客の意図と違う」コードが量産されるリスクがあります。これは Vitest 4.1 の AI Agent Reporter で扱った “AI が書いたテストの妥当性をどう測るか” と表裏一体の課題です。
Trust Layer の 4 階層
GitHub の提唱する Trust Layer は、出力を直接判定するのではなく、出力に至るプロセスと根拠を多層で観察するアプローチです。弊社では受託向けに以下の 4 階層で組んでいます。
[Layer 1: Behavior Trace（行動ログ）]
├ ツール呼び出しの順序・引数・戻り値
├ ファイル変更の差分（before / after）
└ 失敗 → 再試行の連鎖
[Layer 2: Property Tests（性質ベーステスト）]
├ 不変条件: 「データを失わない」「権限を逸脱しない」
├ 等価性: 「リファクタ前後で同じ入出力」
└ ベンチマーク: 「速度 / メモリの逸脱なし」
[Layer 3: Dominatory Analysis（支配関係分析）]
├ 候補解 A / B / C を生成
├ 「全評価軸で A が B 以上」を判定
└ 支配解のみを採用
[Layer 4: Human-in-the-Loop Sampling]
├ 高リスクな差分は人間レビュー必須
├ ランダム抜き取りで 5〜10% を二重チェック
└ 顧客 PM の最終承認ゲート特に Layer 3 の dominatory analysis は 「ベスト 1 を選ぶ」のではなく「他より明らかに劣る解を弾く」発想で、受託のコードレビュー文化と相性が良い手法です。
受託契約に書く「AI 品質条項」のひな型
AI が書いたコードが受託成果物に含まれる以上、契約書に品質基準を明記することが事故防止の最低条件です。弊社で標準化している条項のポイントを示します。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| AI 出力の責任 | 弊社が最終出力の品質責任を負う | 学習用データへの提供禁止 |
| 検証メトリクス | Trust Layer 4 階層の合格基準を列挙 | 各階層の閾値が現実的か |
| 人間レビュー範囲 | 高リスク差分の定義と承認者 | 承認権限者が指名されているか |
| 再現性 | 同等プロンプトで同等の挙動を再現可能 | ログ保存期間 |
| モデル変更通知 | 採用モデル切替時に事前合意 | 通知 SLA |
| 監査ログ提供 | 顧客が要求すればログを開示 | 期間と粒度 |
「人間レビュー範囲」をふんわり書くと、金曜夕方の自動マージで本番が壊れる事故が起きます。「DB マイグレーション / 認証変更 / 課金処理 / 個人情報を扱うコード」は人間承認必須と明記する運用が最低ラインです。
これは Claude Code Auto Mode を受託で安全運用する で扱った Approval Gates の発想を、契約書面に落とし込んだ形と捉えてください。
Trust Dashboard — 顧客と共有する運用画面
Trust Layer の検証結果は、顧客 PM が毎日 5 分で確認できるダッシュボードに集約することが運用継続の鍵です。弊社では以下のメトリクスを表示しています。
- 採用率: エージェント提案のうちマージされた割合
- 棄却率: dominatory analysis で棄却された割合
- 人間介入率: Human-in-the-Loop で差し戻された割合
- 検証時間: 提案 → マージまでの中央値・95 パーセンタイル
- インシデント連鎖: AI 起因のロールバック件数（週次）
- モデル別品質スコア: モデルごとの採用率・棄却率
これらを GitHub Audit Log + BigQuery + Looker Studio で可視化し、週次で顧客 PM と一緒に振り返る運用にしています。これは GitHub Copilot 従量課金とトークンガバナンス のコスト可視化と同じダッシュボードに統合すると、「コストと品質を同時に管理する」運用が一気に成熟します。
価格モデル — Trust Layer を含めた受託パッケージ
Trust Layer 運用を含めた受託パッケージは、以下のレンジで提供しています。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| Trust Lite | 50 万円 / 8 万円〜 | 既存案件への後付け | Layer 1〜2 構築 + 月次レポート |
| Trust Standard | 150 万円 / 20 万円〜 | 新規・継続案件 | Lite + Layer 3 dominatory + ダッシュボード |
| Trust Enterprise | 400 万円〜 / 60 万円〜 | 規制業界・上場 | Standard + Layer 4 強化 + 監査ログ + SLA |
特に 「Trust Standard を導入したらマージ後のロールバックが月 4 件 → 月 1 件に減った」事例があり、運用品質の改善幅が見えやすい領域です。中小企業でも月額 20 万円で 「AI が書いたコードを安心して本番に出せる体制」を構築できます。
ハマりやすい 5 つの落とし穴
最後に、Trust Layer を受託で構築するときに踏みやすい落とし穴を共有します。
落とし穴 1: テスト = 検証だと思い込む
ユニットテストがパスしても、「顧客の意図と違う実装」は検出できません。Layer 2 の Property Tests と Layer 3 の dominatory analysis を最初から並走させます。
落とし穴 2: ログを取るが分析しない
行動ログを Cloud Logging に貯めるだけで活用しないケースが多発します。週次で必ず 1 時間、ログを眺める時間を運用に組み込みます。
落とし穴 3: 人間レビューの基準が曖昧
「重要な変更は人間レビュー」という曖昧な基準では、結局全 PR を人間が見る羽目になり生産性が落ちます。ファイルパス・差分行数・タッチするモジュールの 3 軸で機械判定します。
落とし穴 4: モデル切替時に Trust Layer を更新しない
GPT-5.5 → Claude へモデルを切り替えたとき、閾値や Property Tests が古いままだと判定が崩れます。モデル切替 = Trust Layer 再キャリブレーションを運用ルールに含めます。
落とし穴 5: 顧客 PM がダッシュボードを見ない
弊社だけが品質を見る運用は 「弊社が品質を保証する」契約に劣化します。顧客 PM が週次で必ず 5 分見るコミットを契約条項に入れ、ダッシュボードを共同責任の場にします。
まとめ — 「テストでは足りない時代」の受託品質保証
AI エージェントの普及で、**「テストがパスする = 正しい」は受託の品質保証として成立しなくなりました。GitHub の Trust Layer は、「正解が一意ではない出力をどう信頼するか」**に対する現時点で最も実装可能な答えで、受託の品質保証フレームとして取り入れる価値があります。
弊社では Trust Lite / Standard / Enterprise の 3 段階で Trust Layer を組み込んだ受託パッケージを提供しています。「AI が書いたコードを顧客にどう説明するか悩んでいる」「マージ後のロールバックが減らない」というご相談は お問い合わせフォーム からお気軽にどうぞ。
