Claude Architect · レッスン

例を使った重要度基準

各重要度レベルをコード例で具体化します

レッスン 3/413 ステップ

「例を使った重要度基準」はCoddyKit上の無料Claude Architectレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはClaude Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Claude Architectコースには全4レッスンが含まれています。

重大度に基準が必要な理由

Claudeにコードのレビューを依頼するとき、与えられる指示の中で最も弱いのは、be more precise や only flag important issues のような曖昧なものです。モデル間で共有された「重要」の定義がないため、判定基準がファイルごとに揺れてしまいます。

試験で問われる原則は明快です。明確な基準は、曖昧な形容詞に勝ります。重大度の尺度(Critical / High / Medium / Low)は、各レベルにモデルが一貫して適用できる明文化されたルールがあって初めて役立ちます。そして、ルールを明確に定める最も確実な方法は、具体的なコード例で示すことです。

このレッスンでは、CI/CDレビューエージェント向けの重大度基準を、各レベルに例を結び付けながら、1レベルずつ作成します。

失敗パターン:基準のない形容詞

これは、一見問題なさそうに見えても、実際にはうまく機能しないプロンプトの例です。重大度のレベル名は示していますが、その定義がないため、モデルは推測するしかなく、実行のたびに異なる推測をします。

その結果、試験で警告されているアンチパターンがそのまま現れます。nullチェックの欠落と、コメントのスペルミスがどちらも「High」とタグ付けされるような、ノイズの多いレビューです。レビュアーはラベルを信用しなくなります。

system = (
    "You are a code reviewer. "
    "Rate each issue as Critical, High, Medium, or Low. "
    "Be precise and only report important problems."
)

# Problem: 'important', 'precise', and the four levels are
# never defined. The bar is whatever the model infers today.

修正方法:各レベルに1つのルールと1つの例

修正は構造化して行います。各重大度レベルについて、モデルに次の2つを与えます。

  • ルール — テスト可能な条件(「データ損失、セキュリティ侵害、または本番環境でのクラッシュを引き起こす」)。
  • 基準となる例 — そのレベルに明確に該当する短いスニペット。

これは、基準に対して few-shot プロンプトを適用する方法です。曖昧さ1つにつき、対象を絞った例を2~4個用意します。モデルは基準となる例から一般化するのであって、単にそれらを繰り返すのではありません。そのため、適切に選んだ少数の例で尺度全体を調整できます。

Critical — セキュリティの例を基準にする

Criticalは、データ損失、セキュリティ侵害、または本番環境でのクラッシュを引き起こす問題に限定します。ここでは、SQLへの生の文字列補間という、疑いようのない例を基準にします。

この基準となる例には、もう1つの役割もあります。尺度の上限を定義することで、これより軽微な問題がこのレベルに達してはいけないことをモデルに理解させます。

CRITICAL = """
Critical: causes data loss, a security breach, or a
production crash. Always report, even if low-confidence.

Example (SQL injection):
    query = f"SELECT * FROM users WHERE id = {user_input}"
    db.execute(query)
Why: user_input is interpolated unescaped -> injectable.
"""

High — ロジックバグの例を基準にする

Highは、プロセスをクラッシュさせることはないものの、誤った結果を生む誤動作を指します。たとえば、ロジックエラー、エッジケースの不備、オフバイワンエラーなどです。この基準となる例によって、Criticalとの境界が具体的になります。侵害もクラッシュもないものの、出力が誤っているケースです。

HIGH = """
High: produces incorrect results or a test failure, but
does not breach security or crash production.

Example (off-by-one):
    for i in range(len(items) - 1):
        process(items[i])     # last item never processed
Why: range stops one element early; silent wrong output.
"""

MediumとLow — 軽微な側を基準にする

尺度の軽微な側では、曖昧なプロンプトによる誤検知が最も多く発生するため、同じように慎重に基準を定めます。

  • Medium — まだバグにはなっていないものの、保守性または信頼性に関わるリスク(タイムアウトの欠落、まれにしか発生しない未処理のエラーパスなど)。
  • Low — スタイルと命名だけに関する問題で、動作への影響はありません。

Lowを明確に定義しておけば、後から「マージ前ゲートではLowを報告しない」と指定しても、モデルが異議を唱えることはありません。

MEDIUM = """
Medium: reliability or maintainability risk, not yet a bug.
Example:
    requests.get(url)        # no timeout -> can hang forever
"""

LOW = """
Low: style or naming only, no behavioral impact.
Example:
    def calc(x): return x*2  # name 'calc' is unclear
"""

基準をシステムプロンプトにまとめる

基準を定めた各レベルを、システムプロンプト内の1つのブロックにまとめます。このブロックは安定させ、先頭に置いてください。レビューするすべてのファイルで同じ内容になるため、プロンプトキャッシュのプレフィックスに最適です。ファイルごとに変わる差分は、キャッシュされた基準の後、ユーザーメッセージに置きます。

import anthropic

client = anthropic.Anthropic()

system = [{
    "type": "text",
    "text": "You are a code reviewer.\n"
            + CRITICAL + HIGH + MEDIUM + LOW
            + "\nAssign exactly one level per finding using the\n"
              "rules and examples above. When unsure between two\n"
              "levels, pick the lower one.",
    "cache_control": {"type": "ephemeral"},
}]

構造を強制する:重大度をEnumにする

明文化された基準は、モデルに判断の方法を示します。一方、構造化出力は回答の形式を保証します。重大度をJSON Schemaのenumに結び付ければ、フィールドが「prettyBad」のような自由記述の形容詞になることはありません。

試験で覚えておくべきルールは、フィールドをrequiredにするのは常に存在する場合だけということです。実際の指摘にはseverityとlineが必ず存在するため、これらは必須です。一方、任意のsuggested_fixは必須ではありません。

finding_schema = {
    "type": "object",
    "properties": {
        "line": {"type": "integer"},
        "severity": {
            "type": "string",
            "enum": ["critical", "high", "medium", "low"],
        },
        "rule": {"type": "string"},
        "suggested_fix": {"type": "string"},
    },
    "required": ["line", "severity", "rule"],
    "additionalProperties": False,
}

レビュー呼び出しに基準を組み込む

ここで、キャッシュされた基準と、enumで制約したスキーマを1つのリクエストにまとめます。変動するのは差分だけなので、ユーザーメッセージの最後に置きます。

この組み合わせ、つまり判断には明確な基準を、形式には構造化出力を使う方法が、信頼性の高い抽出と分類のために試験で推奨されているパターンです。

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    thinking={"type": "adaptive"},
    system=system,                      # cached rubric prefix
    output_config={
        "format": {
            "type": "json_schema",
            "schema": {
                "type": "object",
                "properties": {"findings": {
                    "type": "array", "items": finding_schema}},
                "required": ["findings"],
                "additionalProperties": False,
            },
        }
    },
    messages=[{"role": "user", "content": diff_text}],
)

ゲートを動かすのは重大度ではなくコード

重大度が整ったenumになれば、マージをブロックするという判断はモデルの判断ではなく、決定論的なコードで行えます。モデルは分類し、パイプラインがしきい値を適用します。

これは、試験で扱われるフックの原則にも一致します。マージの失敗など、失敗が実際の結果につながる場合は、確率的なプロンプトではなく決定論的なコードで強制します。基準によってモデルのラベルが十分に信頼できるものになるため、ゲートに利用できます。

import json

findings = json.loads(resp.content[0].text)["findings"]

BLOCKING = {"critical", "high"}
blockers = [f for f in findings if f["severity"] in BLOCKING]

if blockers:
    print(f"BLOCK MERGE: {len(blockers)} issue(s)")
    raise SystemExit(1)
print("OK to merge (medium/low only)")

モデルに重大度の自己フィルタリングをさせない

微妙な落とし穴が1つあります。指摘の段階でモデルに「CriticalとHighだけを報告してください」と指示すると、再現率が低下します。モデルが低いと判断した問題をひそかに除外するため、必要だったかもしれない問題の網羅性が失われます。

堅牢なパターンは、モデルにすべての指摘を重大度付きで報告させ、その後、別の下流ステップ(BLOCKINGセットや独立したレビュー処理)でフィルタリングすることです。まず網羅性を確保し、ランキングはその後に行います。この下流でのランキングを信頼できるものにするのが、基準を明確に定めることです。

クイックチェック:重大度を基準で示す

このレッスンを、現実的な設計上の選択に適用してみましょう。

まとめ:指し示せる基準

重要なポイント:

  • 曖昧な形容詞は揺れますが、明文化されたルールは揺れません。「重要」という表現を、重大度レベルごとのテスト可能な条件に置き換えます。
  • すべてのレベルをコード例で基準付けします。対象を絞ったfew-shotの例を2~4個使うと尺度を調整でき、モデルはそこから一般化します。
  • ラベルをenumで固定します。構造化出力により、severityは常に有効な値のいずれかになります。常に存在するフィールドだけを必須にします。
  • 基準をキャッシュし、差分だけを変えます。安定した基準はシステムプロンプトの先頭に置き、ファイルごとのコードは最後に配置します。
  • モデルで分類し、コードでゲートします。すべての指摘を重大度付きで報告させ、その後、下流で決定論的にフィルタリングまたはブロックします。指摘の段階で自己フィルタリングさせてはいけません。
無料で開始

AI チューターと学ぶ Python — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース
26
レッスン
104

よくある質問

「例を使った重要度基準」レッスンは無料ですか?

はい。「例を使った重要度基準」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Claude Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Claude Architectコースには全4レッスンが含まれています。

「例を使った重要度基準」で何を学びますか?

各重要度レベルをコード例で具体化します ブラウザで直接実行するハンズオンコードでClaude Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Claude Architectを始めるのに経験は必要ですか?

事前経験は必要ありません。CoddyKitのClaude Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。

「例を使った重要度基準」レッスンにはどのくらい時間がかかりますか?

ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このClaude Architectレッスンでコードを書いて実行できますか?

はい。すべてのClaude Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 曖昧な指示より明示的な基準
  2. 分類用の例
  3. 例を使った重要度基準
  4. 誤検知を減らす
← Claude Architectに戻る