【CCA Foundations対策 / Claude API編 #15】セッション管理とconfidence scoring——長期タスクと品質計測の設計
CCA Foundations試験ガイドをもとに解説しています。
長期タスクを途中で中断したとき、どうやって再開するか。複数のアプローチを同時に試したいとき、どう管理するか。抽出結果の信頼性をどう計測するか。今回はセッション管理とconfidence scoringの2テーマを整理する。
この記事でわかること：
--resumeでセッションを再開する方法とユースケースfork_sessionでセッションを分岐させる設計- named sessionsとsession context isolationの考え方
- confidence scoringのフィールドレベル設計
- キャリブレーションとstratified samplingによるエラーレート計測
セッション管理の全体像
Claude Codeのセッションは、会話の文脈と作業状態をひとまとまりとして管理する単位。長いタスクや並行する作業では、セッションをどう扱うかが品質と効率に直結する。
試験ガイドに記載されている4つの概念：
| 概念 | 目的 |
|---|---|
| Session resumption（--resume） | 中断したセッションを再開する |
| fork_session | セッションを分岐して別の方向を試す |
| Named sessions | セッションに名前をつけて管理する |
| Session context isolation | セッション間の状態を分離する |
--resume：セッションを再開する
--resumeフラグを使うと、以前のセッションを再開できる。
# 最近のセッション一覧から選んで再開
claude --resume
# セッションIDを指定して直接再開
claude --resume <session-id>
再開時、Claude Codeは前のセッションのコンテキスト（会話履歴・ファイル編集の流れ）を復元した状態から作業を再開する。
主なユースケース：
1. 長いリファクタリングタスクを翌日に続ける
2. システムクラッシュ後に途中まで進んだ作業を復旧する
3. レビュー待ちの間に別の作業をして、フィードバックが来たら元の作業に戻る
/compactとの違い：/compactは同じセッション内でコンテキストを圧縮するコマンド。--resumeはセッションをまたいで再開するCLIフラグ。
fork_session：セッションを分岐させる
fork_sessionは現在のセッションを分岐し、元のセッションを保持したまま別の方向を探索できる。
元のセッション（認証機能の実装中）
├── fork A：JWTベースのアプローチを試す
└── fork B：セッションクッキーベースのアプローチを試す
→ fork Aが上手くいった場合、fork Aを本流として継続
→ fork Bを捨てても元のセッションのコンテキストは保持されている
活用場面：
- 設計の分岐点で複数の実装アプローチを比較したいとき
- 破壊的な変更（大規模なリファクタリング）を試す前に安全な分岐点を作るとき
- 同じ問題を異なるアプローチで並行して探索するとき
named sessions：セッションを名前で管理する
セッションに名前をつけることで、複数の作業コンテキストを切り替えながら管理できる。
# セッションに名前をつけて開始
claude --session-name "auth-refactor"
# 名前を指定して再開
claude --resume auth-refactor
プロジェクト内で複数の独立した作業（機能開発・バグ修正・実験）を並行して進める場合、名前付きセッションを使うとコンテキストの混在を防げる。
session context isolation：セッション間の分離
異なるセッションはそれぞれ独立したコンテキストを持ち、状態が混ざらない。
これが重要な理由：
セッションA（本番コードのバグ修正）
セッションB（新機能の実験的実装）
→ セッションBで試した未完成のコードがセッションAに影響しない
→ 各セッションが独立して一貫した文脈を持てる
並行して複数のワークストリームを動かすマルチエージェントシステムでは、各エージェントが独立したセッションを持つことで意図しないコンテキスト汚染を防ぐ。
📋 試験ガイドより
試験ガイドのTechnologies and Conceptsに「Session management — Session resumption, fork_session, named sessions, session context isolation」が明記されている。--resumeでセッションを再開し、fork_sessionで分岐させ、named sessionsで識別し、context isolationで独立性を保つ——この4つの関係を整理しておく。
Confidence scoring：信頼スコアの設計
抽出タスクで「この値は正しいか」を評価するとき、boolean（正解/不正解）だけでは精度の実態を把握できない。confidence scoringは各フィールドに信頼スコアを付け、どこが不確実かを明示する設計。
フィールドレベルのconfidence
extraction_schema = {
"company_name": str,
"company_name_confidence": float, # 0.0〜1.0
"annual_revenue": Optional[float],
"annual_revenue_confidence": float,
"founding_year": Optional[int],
"founding_year_confidence": float,
}
文書全体に1つのスコアを付けるのではなく、フィールドごとにスコアを付ける。これにより「会社名は確実だが売上は不確実」という粒度の情報を下流に渡せる。
# 例：信頼スコアが低いフィールドを人間レビューに回す
def route_for_review(extraction_result):
low_confidence_fields = [
field for field, conf in extraction_result.confidences.items()
if conf < 0.7
]
if low_confidence_fields:
return "human_review", low_confidence_fields
return "auto_approved", []
キャリブレーション：スコアの正確さを検証する
モデルが「confidence: 0.9」と言っても、実際に90%の精度かどうかはわからない。ラベル付きvalidation setと照合して、スコアが実態を反映しているかを確認する。
def calibrate_confidence(model_outputs, labeled_validation_set):
"""
モデルの信頼スコアと実際の正答率を比較する
"""
buckets = {
"0.9-1.0": {"correct": 0, "total": 0},
"0.7-0.9": {"correct": 0, "total": 0},
"0.5-0.7": {"correct": 0, "total": 0},
"0.0-0.5": {"correct": 0, "total": 0},
}
for output, ground_truth in zip(model_outputs, labeled_validation_set):
bucket = classify_confidence_bucket(output.confidence)
buckets[bucket]["total"] += 1
if output.value == ground_truth.value:
buckets[bucket]["correct"] += 1
# confidence 0.9-1.0のバケットで実際の正答率が75%なら過信頼
return {
bucket: data["correct"] / data["total"]
for bucket, data in buckets.items()
if data["total"] > 0
}
過信頼（overconfidence）：0.9と言っているのに実際の正答率が70%。自動承認の閾値を上げるか、人間レビューの比率を増やす必要がある。
過少信頼（underconfidence）：0.5と言っているのに実際は90%正確。人間レビューに無駄に回している。
stratified sampling：エラーレートの正確な計測
全データをランダムにサンプリングすると、高confidence事例が多数を占め、低confidence事例でのエラーが埋もれる。信頼スコア別に層（stratum）を分けてサンプリングすることで、リスクの高い領域を正確に計測できる。
def stratified_sample(data, sample_size_per_stratum=50):
"""
信頼スコアの層ごとに均等にサンプリングする
"""
strata = {
"high": [d for d in data if d.confidence >= 0.9],
"medium": [d for d in data if 0.7 <= d.confidence < 0.9],
"low": [d for d in data if d.confidence < 0.7],
}
samples = {}
for stratum_name, stratum_data in strata.items():
n = min(sample_size_per_stratum, len(stratum_data))
samples[stratum_name] = random.sample(stratum_data, n)
return samples
低confidence層でのエラーレートが高ければ閾値を調整する。高confidence層でもエラーが多ければキャリブレーションに問題がある。
📋 試験ガイドより
Technologies and Conceptsに「Confidence scoring — Field-level confidence, calibration with labeled validation sets, stratified sampling for error rate measurement」が明記されている。文書全体ではなくフィールド単位でスコアを付け、validation setでキャリブレーションし、stratum別にエラーレートを計測する——この3ステップが設計の核心。
よくある誤解まとめ
| 誤解 | 実際 |
|---|---|
| --resumeは同じセッション内の再開コマンド | CLIフラグ。前のセッションをまたいで再開する。同一セッション内の操作は/compact・double-Escape |
| fork_sessionはコードのgit branchと同じ概念 | 目的は似ているが、セッションの会話コンテキストを分岐させるもの。コードの変更とは独立している |
| confidence 0.9 = 90%の精度 | キャリブレーションしていない場合、スコアと実際の精度は一致しない。validation setで検証が必要 |
| 全データをランダムサンプリングすれば十分 | 低confidence事例は少ないが高リスク。stratified samplingで層別に計測しないと見落とす |
| confidence scoringは最終出力だけに付ければよい | フィールドレベルで付けることで「どの情報が不確実か」を下流に伝えられる |
設計の判断基準
| 場面 | やりがちな選択 | 正しい選択 | 判断の根拠 |
|---|---|---|---|
| 長いタスクを翌日に続けたい | 新しいセッションで指示をやり直す | --resumeで前のセッションを再開する | コンテキストを再構築するコストが省ける |
| 2つの設計アプローチを比較したい | 1つ試して失敗したら別を試す（前の状態は失われる） | fork_sessionで分岐させて並行探索する | 元のセッションを保持したまま安全に比較できる |
| 抽出結果の品質を評価したい | 全件のサンプルで正答率を計算する | stratified samplingで信頼スコア別にエラーレートを計測する | 低confidence層のリスクが埋もれない |
| モデルの自信が高すぎる（過信頼） | そのままの閾値で運用する | validation setでキャリブレーションし、自動承認閾値を上げる | 過信頼のまま運用するとエラーが見えなくなる |
まとめ
--resumeはCLIフラグでセッションをまたいで再開する。/compact・double-Escapeとは別の機能fork_sessionで元のセッションを保持したまま別アプローチを探索できる- named sessionsで複数の作業コンテキストを識別・管理する
- session context isolationでセッション間の状態汚染を防ぐ
- confidence scoringはフィールドレベルで付け、validation setでキャリブレーションし、stratified samplingでリスクの高い層を計測する