Anthropicは11月9日、難しい推論と長時間のAgentタスクを重視したFable 5.2を公開した。発表資料には、PythonからRustへサービスを移行し、起動が26倍速くなったというテスト事例がある。これはそのサービスの起動性能であり、モデルの生成速度や他の移行で得られる効果を示す数字ではない。
こうした能力があると、複数モジュールの依存関係を追い、実装を書き換え、テストを使って修正する大きな仕事もAgentへ任せたくなる。人が受け取るものはコード差分だけではなく、作業中に生まれた判断にも広がる。
どの互換動作を残すべきか。古いインターフェースをまだ消せない理由は何か。性能改善は特定の環境でしか成立しないのか。これらは別のリポジトリやチームの作業も左右する。現在のAgentが使う文脈だけでは、次の担当者に「チームが何を受け入れたか」が伝わらないことがある。
大規模移行には、検証可能な実装と、後続作業が依拠できる判断という二つの成果が必要になる。それぞれに合った検収を結び付けたい。
PRは変更を検証し、決定記録は次の前提を示す
コード、テスト、ベンチマーク、リポジトリ内の設計判断記録であるADRはGitに置いたままでよい。PRは実装と議論をつなぐ。利用者が同じリポジトリ内にいるなら、適切に維持されたADRだけで十分な場合もある。モデル更新だけを理由に別の知識基盤を追加する必要はない。
追加の共有記録が役立つのは、結論がリポジトリ外にも影響するときだ。別チームのサービス、運用上の環境制約、異なるプロジェクトで作業するAgentが同じ判断を使う場合、元のPRだけでなく、現在の適用範囲や責任者も検索できる必要がある。
Busabaseはこの共有層を担える。簡潔な決定、適用範囲、証拠リンク、変更履歴を保存する。ただしテストを代替せず、整った要約を自動的に設計承認へ変えることもない。Gitの実装レビューとBusabaseの知識受け入れは目的の異なる検収だ。
最初の変更より前に制約を読む
既存の設計文書、有効なADR、インターフェース要件をAgentへ読ませる。信頼できる原本があるなら、資料を丸ごと複製せず元の場所へリンクする。二つのコピーを別々に更新する状態を避けたい。
小さく始めるなら、移行用Folder、範囲と検収条件のDoc、共有する判断のBaseを用意する。以下は設定案であり、製品に組み込まれたテンプレートではない。
| リソース | 保存内容 | 役割 |
| --- | --- | --- |
| Folder：移行プロジェクト | DocとBaseへの入口 | 今回の仕事の境界 |
| Doc：範囲と検収条件 | 目標、互換要件、Git、責任分担 | Agentとレビュー担当の共通条件 |
| Base：設計判断 | 結論、根拠、範囲、責任者、状態 | 共有判断の検索と提案 |
| SkillまたはカスタムPrompt | 制約の読み方、変更提案、証拠の紐付け | 次の仕事で方法を再利用 |
開始時の指示は、次のように具体化できる。
このプロジェクトの範囲と検収条件のDocを読み、このサービス向けに受け入れ済みの設計判断を調べてください。守る互換要件と出典を列挙し、証拠不足、期限切れ、矛盾は分けてください。未解決事項を実装の前提にせず、共有記録はまだ変更しないでください。
最初の成果は出典付きの制約一覧と、責任者が判断する未解決事項になる。Fableの利用権限やClaude Code環境での選択可否は別に確認する。Busabaseプラグインの導入はモデルへのアクセスを付与しない。
発見をすぐにチームの規則へ変えない
移行中には、未文書化の動作や、互換処理を削除できそうだという発見が出る。観測と決定を分けたい。テスト結果は証拠であり、将来どの動作を採用するかは責任を伴う判断だ。
提案には具体的な結論、実際のコードやテスト、対象サービスと環境、未確認の境界、責任者を付ける。「移行成功、全体へ展開可能」だけでは広すぎる。一つのモジュールの合格は、他にも同じ制約があることを証明しない。
「互換経路を削除してよいか」を構造上の例として考える場合も、削除承認を先に埋めない。実際のPRとテストをAgentが示し、担当者が結論と範囲を決める。証拠がなければ未確認とし、例のURLを実証データの代わりに使わない。
判断の状態とChangeRequestの状態を分ける
Baseには次のような項目を設けられる。チームが設計し運用するスキーマであり、Busabaseが設計の正しさを自動判定する機能ではない。
| 項目 | 型の案 | レビューすること |
| --- | --- | --- |
| decision | テキスト | 次のAgentが何に依拠できるか |
| evidence | テキストまたはURL | 実際のPR、テスト、計測、ADR |
| scope | テキスト | サービス、リポジトリ、版、環境 |
| owner | メンバーまたはテキスト | 誰が受け入れ維持するか |
| state | 単一選択 | 未確認、受け入れ済み、条件付き、廃止 |
| supersedes | 同一Baseの関連 | 置き換える旧判断、または空欄 |
| review_condition | テキスト | 再確認を必要とする変化 |
stateはChangeRequestのレビュー状態とは異なる。前者は結論を使えるか、後者は項目変更が正式記録へ入ったかを示す。CRがmergedでも、保存した判断自体は未確認かもしれない。それを実装承認として扱ってはいけない。
共有知識を正式にする前に人が確認する運用では、提案専用の接続権限を使う。Write権限の既定では即時マージされるため、その接続では明示的にレビューを残す必要がある。「承認を待つ」というPromptだけではAPIの動作は設定されない。API Keysと実際の接続条件を確かめる。
実装と結論を突き合わせて検収する
技術レビュー担当はGitの差分、実行したテスト、未検証範囲を見る。共有判断の責任者は、証拠が結論を支えるか、適用範囲が検証より広くないか、別チームが廃止対象の動作を使っていないかを確認する。
PRがマージされても、部門間の互換性は未確認や条件付きのままでよい。逆に設計方針を受け入れても、実装・テスト・デプロイ済みにはならない。それらはGitとデプロイ証拠へ戻って確認する。
範囲の修正や証拠追加はChangeRequestで行い、権限のある判断の後にマージし、現在の記録を読み返す。新判断が旧判断を置き換えるなら関連と状態を明示し、過去の理由を履歴から消さない。
Agentへの書き戻し指示は次のようになる。
後続の移行に影響する結論を、設計判断の提案として整理してください。実際のPRとテスト、適用範囲、未解決事項、責任者を添えてください。同じ判断の既存記録があれば再利用し、重複を作らないでください。自分で承認せず待ち状態の変更として提出し、CRリンクと項目差分を返してください。承認・マージ後に読み返し、受け入れ済みと、まだ実装前提にできない結論を報告してください。
次のAgentは現在有効な判断から始める
次の担当はプロジェクトと権限を確認し、mergedの現行記録を読む。その上で業務状態が受け入れ済み、範囲が一致し、廃止されず、再確認条件を満たすものを選ぶ。審査中のCRは問題の手がかりにできても、受け入れ済み一覧には混ぜない。
矛盾を単に更新日時の新しさで解消しない。置換関係、範囲、責任者を確認し、説明できない場合は人へ返す。記録は自動的に最新の事実になるわけではない。PR変更、依存更新、環境変更で再確認が必要になる。
Busabase Playbooksに読み取りと提案の方法をSkillまたはカスタムPromptとして保存できる。誰が次を実行し、いつ読み、失敗をどう報告するかも決めたい。手順を保存しただけでAgentやスケジュールが起動することはない。
次の仕事が必要とする一つの結論から
実際のPRとテストがあり、次の作業へ影響する結論を一つ選ぶ。読み取り、提案、人工レビュー、マージと読み返し、次回の再利用を一周させる。すべての会話や途中の推論を知識化する必要はない。
Claude Code知識ベースガイドは、共有記録とCLAUDE.md、auto memory、リポジトリ資料の役割を説明している。Claude Codeプラグインの現行指示から導入ガイドをAgentに読ませ、認可後は読み取り専用の接続確認から始められる。
能力の根拠はAnthropicの発表資料にある。チームが成果を引き継ぐには、実装証拠、判断責任、次回の読み取りをつなぐ必要がある。結論だけでなく、なぜ、どこで、誰が受け入れたかを後続担当が確認できるようにする。