Skip to main content

TRUST 5 品質フレームワーク

更新 2026-08-10 11分で読めます GitHub で編集 ↗

MoAI-ADK のすべてのコードが通過しなければならない 5 つの品質原則を詳しく案内します。TRUST 5 は エージェンティックハーネスの品質ゲートです — エージェントがどれだけ速くコードを生産しても、この ゲートを通過できなければ完了と認められません。

情報
一行要約: TRUST 5 は「コードがテストされているか、読みやすいか、一貫性があるか、 安全か、追跡可能か」を検証する自動化された品質ゲートです。

ハーネスレベル (3 段階)

TRUST 5 品質ゲートは SPEC の範囲に応じて 3 段階の深さで適用されます。複雑度推定器 (Complexity Estimator) が SPEC のスコープを基にハーネスレベルを自動決定します。

レベル名前検証範囲
minimal最小高速検証 — 核心ゲートのみ通過
standard標準基本検証 — 基本品質ゲートの実行 (デフォルト値)
thorough深層全体検証 — sync-auditor の独立評価 + TRUST 5 全体適用

TRUST 5 とは?

TRUST 5 は MoAI-ADK がすべてのコードに適用する 5 つの品質原則 です。AI が生成した コードも、人が書いたコードもこの基準を通過する必要があります。

日常的なたとえで説明すると、建物を建てるときに竣工検査をするのと同じです。構造 安全性、電気配線、水道配管、消防設備、建築許可書類をすべて確認しないと入居 できません。コードも同じです。

建物検査TRUST 5確認内容
構造安全性T (Tested)コードが正しく動作するかをテストで検証
電気/水道の設計図R (Readable)他の開発者がコードを理解できるか
建築規定の遵守U (Unified)プロジェクトのコーディングルールに合うか
消防/セキュリティ設備S (Secured)セキュリティ脆弱性がないか
認可書類T (Trackable)変更履歴が明確に記録されるか
flowchart TD
    Code["コード作成完了"] --> T1["T: Tested\nテスト検証"]
    T1 --> R["R: Readable\n可読性検証"]
    R --> U["U: Unified\n一貫性検証"]
    U --> S["S: Secured\nセキュリティ検証"]
    S --> T2["T: Trackable\n追跡性検証"]
    T2 --> Deploy["デプロイ可能"]

    T1 -.- T1D["85%+ カバレッジ\nLSP 0 型エラー"]
    R -.- RD["明確な名前\nLSP 0 リントエラー"]
    U -.- UD["一貫したスタイル\nLSP 警告 10 未満"]
    S -.- SD["OWASP Top 10\nLSP 0 セキュリティ警告"]
    T2 -.- T2D["Conventional Commits\nイシュートラッキング"]

T - Tested (テスト済み)

核心: すべてのコードはテストで検証される必要があります。

何を確認するか

検証項目基準説明
テストカバレッジ85% 以上コード全体の 85% 以上がテストで検証される必要があります
特性化テスト既存コードの保護リファクタリング時に既存の動作を保存するテストがある必要があります
LSP 型エラー0 個型検査でエラーがない必要があります
LSP 診断エラー0 個言語サーバーの診断エラーがない必要があります

なぜ 85% か?

100% を要求しない理由があります。

カバレッジ現実的な意味
60% 未満主要機能もテストされないことがあります
60-84%基本的な機能はテストされますがエッジケースが抜けることがあります
85-95%核心ロジックと大部分のエッジケースが検証されます (推奨)
95-100%テストの保守コストに対する効果が落ち始めます

ベストプラクティス

python
def calculate_discount(price: float, discount_rate: float) -> float:
    """割引価格を計算します。

    Args:
        price: 元の価格 (0 以上)
        discount_rate: 割引率 (0.0 ~ 1.0)

    Returns:
        割引された価格

    Raises:
        ValueError: 有効でない入力値
    """
    if price < 0:
        raise ValueError("価格は 0 より小さくできません")
    if not 0 <= discount_rate <= 1:
        raise ValueError("割引率は 0.0 から 1.0 の間である必要があります")
    return price * (1 - discount_rate)

# テスト: 正常ケースと例外ケースの両方を検証
def test_calculate_discount_normal():
    assert calculate_discount(10000, 0.1) == 9000
    assert calculate_discount(5000, 0.5) == 2500
    assert calculate_discount(0, 0.5) == 0

def test_calculate_discount_invalid_price():
    with pytest.raises(ValueError, match="価格は 0 より"):
        calculate_discount(-1000, 0.1)

def test_calculate_discount_invalid_rate():
    with pytest.raises(ValueError, match="割引率は"):
        calculate_discount(10000, 1.5)

R - Readable (読みやすい)

核心: コードは明確で理解しやすい必要があります。

何を確認するか

検証項目基準説明
命名規則意図を表す名前変数、関数、クラスの名前が明確である必要があります
コードコメント複雑なロジックへの説明「なぜ」こうしたかを説明するコメントがある必要があります
LSP リントエラー0 個リンタールールをすべて通過する必要があります
関数の長さ適切なサイズ1 つの関数が長すぎない必要があります

ベストプラクティス

python
# 悪い例: 名前だけでは何をするか分かりません
def calc(d, r):
    return d * (1 - r)

# 良い例: 名前を読むだけで役割が分かります
def calculate_discounted_price(original_price: float, discount_rate: float) -> float:
    """元の価格から割引率の分だけ割引された価格を計算します。"""
    return original_price * (1 - discount_rate)
情報
可読性のヒント: 「6 か月後の自分自身」がこのコードを読んだときすぐに理解できる か自問してみてください。理解できないなら名前を変えるかコメントを追加してください。

U - Unified (統一)

核心: プロジェクト全体で一貫したコードスタイルを維持します。

何を確認するか

検証項目基準説明
コードフォーマット自動フォーマッターの適用Python は ruff/black、JS は prettier で統一
命名規則プロジェクト標準の遵守snake_case、camelCase などの混用禁止
エラー処理統一されたパターンすべての場所で同じエラー処理方式を使用
LSP 警告10 個未満言語サーバーの警告が閾値以下

ベストプラクティス

python
# 統一されたエラー処理パターン
class AppError(Exception):
    """アプリケーションの基本エラー"""
    def __init__(self, message: str, code: int = 500):
        self.message = message
        self.code = code

class NotFoundError(AppError):
    """リソースが見つからない"""
    def __init__(self, resource: str, id: str):
        super().__init__(f"{resource} '{id}' が見つかりません", code=404)

class ValidationError(AppError):
    """入力値の検証失敗"""
    def __init__(self, field: str, reason: str):
        super().__init__(f"'{field}' の検証失敗: {reason}", code=400)

# すべてのサービスで同じパターンを使用
def get_user(user_id: str) -> User:
    user = user_repository.find_by_id(user_id)
    if not user:
        raise NotFoundError("ユーザー", user_id)
    return user

S - Secured (セキュア)

核心: すべてのコードはセキュリティ検証を通過する必要があります。

何を確認するか

検証項目基準説明
OWASP Top 10全体遵守最もよくある 10 種の Web セキュリティ脆弱性を防止
依存性スキャン脆弱なパッケージなし既知の脆弱性があるライブラリの使用禁止
暗号化ポリシー機密データの保護パスワード、トークンなどは必ず暗号化
LSP セキュリティ警告0 個セキュリティ関連の警告がない必要があります

主要なセキュリティ検証項目

脆弱性防止方法
SQL Injectionパラメータ化されたクエリdb.execute("SELECT * FROM users WHERE id = %s", (id,))
XSS出力エスケープHTML 出力時に自動エスケープ
パスワードの露出bcrypt ハッシュbcrypt.hashpw(password, salt)
ハードコードされた秘密鍵環境変数の使用os.environ["SECRET_KEY"]
CSRFトークン検証すべての状態変更リクエストに CSRF トークンを含む

ベストプラクティス

python
# 悪い例: SQL Injection の脆弱性
def get_user(username: str) -> dict:
    query = f"SELECT * FROM users WHERE username = '{username}'"
    return db.execute(query)

# 良い例: パラメータ化されたクエリで安全に
def get_user(username: str) -> dict:
    query = "SELECT * FROM users WHERE username = %s"
    return db.execute(query, (username,))

T - Trackable (追跡可能)

核心: すべての変更は明確に追跡可能である必要があります。

何を確認するか

検証項目基準説明
コミットメッセージConventional Commitsfeat:fix:refactor: などの標準形式
イシュー連携GitHub Issues 参照コミットに関連するイシュー番号を含む
CHANGELOG変更ログの維持ユーザーに見せる変更内容の記録
LSP 状態追跡診断履歴の記録LSP 状態の変更を追跡して回帰を検出

Conventional Commits 形式

bash
# 構造: <タイプ>(<範囲>): <説明>
# 例:

# 新機能の追加
$ git commit -m "feat(auth): JWT ベースのログイン API を追加"

# バグ修正
$ git commit -m "fix(auth): トークン有効期限の計算エラーを修正"

# リファクタリング
$ git commit -m "refactor(auth): 認証ロジックを AuthService に分離"

# セキュリティ改善
$ git commit -m "security(db): パラメータ化されたクエリで SQL Injection を防止"

コミットタイプ:

タイプ説明
feat新しい機能feat(api): ユーザー一覧 API を追加
fixバグ修正fix(auth): ログイン失敗時のエラーメッセージを修正
refactorコード改善 (動作の変更なし)refactor(db): クエリ最適化
securityセキュリティ改善security(auth): 秘密鍵を環境変数化
docsドキュメント変更docs(readme): インストールガイドを更新
testテストの追加/修正test(auth): ログインテストケースを追加

LSP 品質ゲート

MoAI-ADK は LSP (Language Server Protocol) を活用してコード品質をリアルタイムで 検証します。LSP は IDE で赤い下線でエラーを表示してくれるまさにそのシステムです。

ステップ別 LSP 閾値

Plan、Run、Sync の各ステップごとに異なる LSP 基準が適用されます。

ステップエラー許容型エラー許容リントエラー許容警告許容回帰許容
Planベースライン取得ベースライン取得ベースライン取得--
Run0 個0 個0 個-不可
Sync0 個--最大 10 個不可

各ステップの意味:

  • Plan ステップ: 現在のコードの LSP 状態を「ベースライン」として取得します。これが 基準線になります。
  • Run ステップ: 実装完了時に LSP エラーが 0 である必要があります。ベースライン比でエラーが 増加してはいけません (回帰不可)。
  • Sync ステップ: ドキュメント化および PR 生成前に LSP がクリーンである必要があります。警告は最大 10 個まで許容されます。
flowchart TD
    P["Plan ステップ\nLSP ベースライン取得"] --> R["Run ステップ\n0 エラー, 0 型エラー, 0 リントエラー\n回帰不可"]
    R --> S["Sync ステップ\n0 エラー, 警告 10 以下\nLSP クリーン状態"]
    S --> Deploy["デプロイ可能"]

    R -.- RCheck{"ベースライン比で\nエラー増加?"}
    RCheck -->|"増加"| Block["遮断: 回帰検出"]
    RCheck -->|"同じまたは減少"| Pass["通過"]

Ralph Engine との統合

Ralph Engine は MoAI-ADK の自律品質検証ループです。LSP 診断結果を 基にコードの問題を自動的に検出して修正を反復します。

flowchart TD
    A["コード変更"] --> B["LSP 診断の実行"]
    B --> C{"TRUST 5\nすべての項目を通過?"}
    C -->|"すべて通過"| D["検証完了\nデプロイ可能"]
    C -->|"失敗項目あり"| E["Ralph Engine\n自動修正を試行"]
    E --> F["修正されたコード"]
    F --> B

動作方式:

  1. コードが変更されると LSP が診断を実行します
  2. TRUST 5 基準に満たない項目があると Ralph Engine が自動修正を試みます
  3. 修正後に再び LSP 診断を実行して通過の可否を確認します
  4. 通過するまで反復します (最大 3 回リトライ)

関連コマンド:

bash
# 自動修正の実行
> /moai fix

# 完了するまで自動反復修正
> /moai loop

quality.yaml 設定

.moai/config/sections/quality.yaml ファイルで TRUST 5 関連の設定を管理します。

主要な設定項目

yaml
constitution:
  # TRUST 5 品質検証の有効化
  enforce_quality: true

  # 目標テストカバレッジ
  test_coverage_target: 85

  # LSP 品質ゲート設定
  lsp_quality_gates:
    enabled: true

    plan:
      require_baseline: true # Plan 開始時にベースライン取得

    run:
      max_errors: 0 # Run ステップのエラー許容: 0 
      max_type_errors: 0 # 型エラー許容: 0 
      max_lint_errors: 0 # リントエラー許容: 0 
      allow_regression: false # ベースライン比の回帰不可

    sync:
      max_errors: 0 # Sync ステップのエラー許容: 0 
      max_warnings: 10 # 警告許容: 最大 10 個
      require_clean_lsp: true # LSP クリーン状態が必要

    cache_ttl_seconds: 5 # LSP 診断キャッシュ時間
    timeout_seconds: 3 # LSP 診断タイムアウト

設定カスタマイズのヒント

状況調整方法
プロジェクト初期、テストがほとんどない場合test_coverage_target を 70 に下げて段階的に上げます
レガシーコードが多い場合allow_regression を一時的に true に設定します
厳格なセキュリティが必要な場合max_warnings を 0 に設定します

実践適用: 品質ゲート通過シナリオ

実際の開発で TRUST 5 がどう適用されるかを見てみましょう。

シナリオ: ユーザー検索 API の実装

bash
# 1. Plan: SPEC 生成 (LSP ベースライン取得)
> /moai plan "ユーザー検索 API の実装"
bash
# 2. Run: DDD で実装 (TRUST 5 検証)
> /moai run SPEC-SEARCH-001

Run ステップでの TRUST 5 検証:

項目検証内容結果
T (Tested)テストカバレッジ 85%、型エラー 0 個通過
R (Readable)リントエラー 0 個、明確な関数名を使用通過
U (Unified)ruff/black フォーマットの適用、LSP 警告 3 個通過
S (Secured)SQL Injection 防止、入力値の検証通過
T (Trackable)Conventional Commit 形式、SPEC 参照通過
bash
# 3. Sync: ドキュメント生成および PR (最終 LSP クリーン確認)
> /moai sync SPEC-SEARCH-001

Sync ステップの最終確認:

text
LSP 診断結果:
- エラー: 0 個
- 型エラー: 0 個
- リントエラー: 0 個
- 警告: 3 個 (閾値 10 以下)
- セキュリティ警告: 0 個

TRUST 5 全体通過: デプロイ可能

TRUST 5 一目で見る

原則核心の問い自動検証ツール基準
T (Tested)テストで検証されているか?pytest, LSP 型検査85%+ カバレッジ、0 型エラー
R (Readable)他の人が読めるか?ruff, eslint, LSP リント0 リントエラー、明確な名前
U (Unified)プロジェクトルールに合うか?black, prettier, LSP一貫したフォーマット、警告 10 未満
S (Secured)セキュリティ脆弱性がないか?bandit, semgrep, LSPOWASP 準拠、0 セキュリティ警告
T (Trackable)変更履歴が追跡可能か?commitlint, gitConventional Commits

関連ドキュメント