はじめに
AI エージェントが判断を下すほど、その経緯は薄れやすい。
「なぜそのコミットが入ったか」「その提案はどういう判断の結果か」——人間の判断なら会話や Slack を遡って再現できる。しかし AI エージェントの場合、実行ログは個別セッションに閉じ、複数エージェント連鎖では文脈が分散し、監査や引き継ぎで「判断の根拠が見えない」という課題に直面する。これはツールの問題ではなく、判断履歴を残す設計がないことに起因する。
本稿では、私たちが Yakumo で実践している「判断集約 + 3層記録」の設計パターンを解説する。このアプローチにより、複数エージェント連鎖でも判断経緯を追跡可能に、監査対応や技術負債整理の効率が大幅に改善された。
課題：判断の経緯が分散し、追跡が困難
複数の AI エージェントを実運用すると、スクレイピング・スコアリング・提案書作成といったアクションが数分のうちに連鎖する。
「この案件をなぜ B ランクにしたのか」を後から確認しようとしても、実行ログは個別セッションに閉じている。A エージェントが情報収集、B エージェントが採点、C エージェントが提案書を生成した場合、責任は A→B→C に流れるが、最終判断に至った論拠を辿るには各セッションを個別に追い、複数の決定ポイントを再構成する必要がある。
さらに以下の問題が生じやすい：
- 追跡可能性の喪失: エージェント実行の数か月後に「この判断はなぜ」と聞かれても、セッション履歴は消失または検索不可
- 監査対応の困難: 規制・法令対応で「この決定の根拠を示せ」という要求に応答できない
- 引き継ぎコストの上昇: 新しいメンバーや別プロジェクトが同じ判断ロジックを再学習する際、明示的な記録がないと理解に時間がかかる
- エージェント改善の停滞: 過去の判断から学ぶ機会が失われ、同じ失敗を繰り返す
一言でいえば、残す仕組みをつくらない限り、判断の経緯は蒸発する。
設計の核：判断を責任者エージェントに集約する
私たちが採用している構造は「定型作業はスキル（確定的ロジック）に任せ、判断は領域責任者エージェントに集約する」というパターンだ。
責任者エージェントは 3 体：
- blog-director: ブログ事業全体・トラック振り分け・優先順位判断
- editor-in-chief: 編集方針・読者層判定・トーン・固有名詞の扱い
- seo-director: キーワード戦略・メタ最適化・流入分析
メインスレッド（ユーザーからの指示）が直接スキルを呼び出すことは禁じられている。必ず責任者エージェント経由で判断してから実行する。この単一の制約が、判断を一箇所に集める効果を生む。
例えば「新しいブログ記事を公開する」という指示が来た場合：
- blog-director が原文を読み、tech か case か mixed かを判定する
- editor-in-chief が読者層・ブランドトーンの適合性を評価する
- seo-director が タイトル・メタディスクリプション・キーワード戦略を提言する
- 3 者の判断がメモリ・コミットメッセージ・PR 説明に記録される
- その後、実行スキル（
/blog-publishなど）が起動される
この流れにより、「最終判断に至った複数の視点」が責任者エージェントのセッション内に集約される。セッション履歴を読めば、どの判定基準で、誰（どのエージェント）がどう考えたかが明示的に見える。
3 層記録媒体の使い分け
判断を残す手段は 1 つではない。私たちは 3 つの記録先を用途別に使い分けている。
1. MEMORY.md：ルール化された判断基準
エージェントが意思決定や判断ミスをしたとき、その背景をメモリシステムに記録する。単なるルール記述ではなく「なぜこのルールが必要か」という文脈ごと保存する。
例（実装予定）:
---
name: 責任者エージェント経由の実行
description: スキルは必ず責任者 agent 経由で呼び出す、直接呼び出し禁止
type: feedback
---
責任者エージェントに経由させることで判断文脈が一箇所に集約される。
分散実行では複数エージェントの決定経緯が追跡困難になり、監査対応で説明コストが爆増する。
Why: 過去、スキルをメインスレッドから直接呼び出していた時期は、
エージェント連鎖の判断ログが分散し、「なぜこの提案書が送られたか」
を 3 ヶ月後に追跡する際に各セッションを個別に掘り直す必要があった。
結果、1 件の監査対応に 6 時間のログ読み込み作業が発生。
How to apply: 判断要素がある操作（記事トラック判定、読者層評価、
提案内容の選別）は必ず責任者エージェントを経由させる。メモリシステムの蓄積により、AI が同じ落とし穴に陥る頻度が低下するだけでなく、新しいメンバーがルールの背景を理解しやすくなる。
2. コミットメッセージ：変更経緯と意図
Conventional Commits 形式を採用しつつ、ボディ部に「なぜそう変えたか」を記述する。
例:
fix(blog): bump body text contrast against star background
- 導入前: #ffffff on #fffaed = 1.08:1 (WCAG 要件 4.5:1 未満)
- 導入後: #1a1a1a on #fffaed = 13:2:1
- 検証: Lighthouse > Accessibility 100 達成
背景: 直前の記事更新で背景を明色化したが、テキストコントラスト
チェックを見落とし、読者からの指摘で判明。
レビュー時点で気づくべきでした。
改善: デプロイ前チェックリストに「カラーコントラスト検証」を追加し、
今後同様の見落としを防止します。このように記述すれば、コミットメッセージそのものが判断ログになる。git log --oneline で変更履歴を一覧できるだけでなく、git show <commit> で変更理由まで一貫して読める。数ヶ月後に「なぜこの行が必要か」と問われた時、コミットメッセージが即座の回答になる。
3. PR 説明：設計意図と判断基準
PR 説明には「What」だけでなく「Why」と「意思決定の基準」を記載する。
例:
## Summary
責任者エージェント経由の実行に制約を変更し、直接呼び出しを禁止しました。
背景として、複数エージェント連鎖時に判断文脈が分散し、
監査対応で説明コストが増加していました。
## Decision Rationale
- 選択肢 A（元の分散実行）: 各スキルが独立して動作、エージェント数に応じた並列化が可能
→ 欠点: 判断理由を後追いする際に複数セッションを個別に参照する必要がある
- 選択肢 B（本PR、責任者集約）: 全スキル呼び出しを責任者エージェント経由に一本化
→ 利点: 判断文脈が一箇所に集約、監査対応で説明ロジックが一貫
→ 欠点: 責任者エージェント呼び出しのオーバーヘッド（）
採用理由: 判断追跡可能性を優先。監査対応コスト削減メリット > 呼び出しオーバーヘッドPR 説明が「意思決定の記録」になることで、将来的なルール改定やリプレイスの際に「なぜこう設計したか」という文脈が保存される。
実運用：判断経緯を辿る動線
記録があるだけでは不十分だ。記録から判断経緯を再現できる動線が必要である。
検索・追跡の具体例
ステップ 1: 変更背景をコミットメッセージから探る
git log --oneline --grep="コントラスト" | head -5
# → 該当のコミットハッシュを特定
git show abc1234 | less
# → 変更理由と背景がボディに記述されているステップ 2: 判断ルールをメモリで確認
grep -r "コントラスト" ~/.claude/projects/*/memory/ | head -3
# → カラーコントラストチェックの背景ルールが memory ファイルに記録されている
cat ~/.claude/projects/.../memory/feedback_a11y_contrast.md
# → 「なぜこのルールが必要か」の背景を読めるステップ 3: PR 説明から意思決定基準を理解
gh pr view 42 --json body
# → 選択肢の比較・採用理由がまとめられているこの 3 ステップで「今この判断に至った文脈」を再現できる。数ヶ月後の監査や技術負債整理でも、意思決定の背景が追跡可能だ。
実運用で顕在化した落とし穴と改善策
実装から 8 ヶ月運用してわかった効果と課題を報告する。
効果
- 判断追跡時間の短縮: 従前は同じ提案内容について「なぜこう判定されたか」を確認する際に、複数セッションを個別に掘り直す必要があり、1 件あたり 3〜6 時間を要していた。責任者集約後は、セッション履歴 1 本で判断経緯が完結するため、確認作業が 30〜60 分に短縮された
- エージェント改善の加速: feedback メモリが蓄積することで、同じ判定ミスが再発する頻度が低下（）
- 引き継ぎのスムーズ化: 新メンバーがルール背景を MEMORY.md から読みながら理解できるため、口頭説明の時間が削減
落とし穴 1：メモリの陳腐化
古いルールが運用中に不適切になっても残り続けると、エージェントが誤った判断をする。
具体例:
本来、記事の公開判定は「tech トラックは数字 3 つ以上」というルールで運用していた。しかし 2 ヶ月後、「コンセプト記事は定性的表現でも可」という新方針に転換したにもかかわらず、メモリファイルを更新しなかった。その後、AI が古いルールに従い、本来公開すべきコンセプト記事を「数字不足」で却下する事態が発生。
改善策:
- ルール変更時に明示的にメモリを上書きする
- 月次で MEMORY.md の整合性をレビューする（変更されたルールの追跡）
- feedback ファイルに「有効期限」のラベルを付ける（e.g.,
valid_until: 2026-08-31）
落とし穴 2：コミットメッセージの品質のばらつき
意思決定の記録が「update script」「fix bug」のような情報量ゼロのメッセージになることがある。
改善策:
- CLAUDE.md にコミットメッセージルールを明記し、AI エージェントの指示に含める
- PR レビュー時に「なぜを書いてあるか」をチェックリスト化
- コミットメッセージ生成時に「背景・影響・理由」のテンプレートを提供
落とし穴 3：「履歴がある」と「読まれる」は別
記録を大量に残しても、週次レビューや PR マージ前確認を習慣化しなければ、ファイルは堆積するだけで活用されない。
改善策:
- 記事公開前に「判定ログを確認する」を手続き化する
- 月次の監査・レビューセッションを定期化する
- MEMORY.md のヒット数が多いエントリを「有用ルール」として可視化
落とし穴 4：トレードオフの不明示
責任者エージェント経由への一本化は判断追跡性を高める一方で、並列実行のシリアル化によるレイテンシ増加という代償がある。
比較検討表:
| 方式 | 利点 | 欠点 | 適用場面 |
|---|---|---|---|
| 責任者集約（現行） | 判断文脈が一箇所、監査対応が容易 | レイテンシ増加（） | 判断追跡が重要（監査対応、技術負債整理） |
| 分散実行 | 並列度が高い、レイテンシが低い | 判断文脈が分散、後追い困難 | 定型・自動処理で判断が少ない流れ |
| ハイブリッド | 定型・自動は分散、判断要素は集約 | 構造が複雑、運用管理の負担増 | スケール段階での移行パターン |
現在は「判断追跡」を重視して責任者集約を採用しているが、スケール時（エージェント数が大幅に増える場面）は「ハイブリッド」への移行も視野に入れている。
責任者エージェント以外の設計選択肢
判断を残す手段は責任者集約だけではない。他の選択肢との比較を記録として示す。
選択肢 A: 自動決定ログ（設定ファイル駆動）
責任者エージェントを経由させず、config JSON でルール化し、実行ログから判断経緯を復元する方式。
- 利点: エージェント呼び出しオーバーヘッド なし、レイテンシ低い
- 欠点: ルール化しきれない判断（複雑な文脈判定、創造的な提案）が取り落ちる
- Yakumo での評価: 定型・確定的な判断（例: カテゴリの自動分類）には有効だが、編集判断・戦略判断は対応不可
選択肢 B: エージェント個別セッション記録
各エージェントが個別セッションで判断し、セッション履歴そのものを監査ログとする方式。
- 利点: 記録の自動化が容易、責任者集約の統合コスト なし
- 欠点: セッション検索が複雑、複数エージェント連鎖で経緯を再構成する負担大
- Yakumo での評価: 個別エージェント内の判断は追跡できるが、複数エージェント接点での意思決定が見えにくい
選択肢 C: 責任者集約（採用）
本稿で説明した方式。複数エージェントの判断を責任者エージェントのセッション内に集約。
- 利点: 複数判断の文脈が一箇所、ルール変更が単一 MEMORY.md で管理可能
- 欠点: 責任者エージェント呼び出しのシリアル化による若干のレイテンシ増
- Yakumo での評価: 判断追跡性と運用性のバランスが最適（現段階）
まとめ
AI エージェントの判断履歴を残すには、ツールよりも先に設計が必要だ。
要点:
-
判断を集約する構造: 領域責任者エージェント経由で全判断を一本化することで、文脈が一箇所に集まり、後追い追跡が容易になる
-
記録媒体の使い分け:
- MEMORY.md → ルール化された判断基準（背景を含む）
- コミットメッセージ → 個別の変更経緯と意図
- PR 説明 → 設計意図と意思決定基準
-
辿れる動線を設ける: 記録があっても検索・参照できなければ役に立たない。
git log --grep、メモリファイルの grep、PR 説明の参照を習慣化する -
陳腐化と品質のばらつきに対処: メモリの定期レビュー、コミットメッセージルールの明記、マージ前確認の手続き化
「AI が判断したから経緯がわからない」のではなく、残す仕組みを設計すれば AI でも判断経緯が追跡可能——この前提で構造を組み立てることが、継続的で監査対応可能な AI 活用の鍵だ。
責任者エージェント集約の詳細は 領域責任者エージェントパターン 、メモリシステムの実装は AI メモリーシステム運用 を参照。