AI SDLC と Context Engine
本番コードでエージェントを走らせた最初の半年間、失敗モードはハルシネーションではありませんでした。健忘症 でした。同じモデルが、8 週目に、3 週目に提案して却下された同じアプローチを提案する。前四半期にチームが移行を終えた deprecated API に手を伸ばす。プロンプトが実物を運ばないために、存在しない内部スタイル規約を発明する。どれもモデル品質の問題ではありません。コンテキストの問題でした。
Context Engine が SprintLoop の答えです: すべてのエージェントディスパッチに伴い移動し、ポリシーが落ちると出荷を拒否し、クローズしたレーンから学習する、5 ディメンションのレイヤード・コンテキストバンドル。
5 つのディメンション
SprintLoop のディスパッチは BMAD バンドルを運びます(Brief、Memory、Architecture、Decisions — 実際には 5 ディメンションですが、頭字語は Style 追加より前に決まっており、そのまま継承されています)。ディメンション:
| ディメンション | 何を捕らえるか | どこに住むか |
|---|---|---|
| Product | ユーザー向け機能仕様、受入基準、エッジケース | リンクされた Issue、レーン概要、プロダクト wiki |
| System | アーキテクチャ図、リポジトリマップ、サービス境界、所有権 | リポジトリから自動抽出 + 手動編集 |
| Style | コーディング規約、命名、エラーハンドリング、ログフォーマット | リポジトリの .sprintloop/style.md + linter 設定 |
| Policy | ハードルール — セキュリティ、コンプライアンス、deprecated API、禁止依存 | ワークスペースポリシーファイル、オーナーが署名 |
| Memory | 過去のレーンの結果、却下されたアプローチ、受理されたパターン | クローズしたレーン + sign-off ノートから自動派生 |
各ディメンションは異なるメカニズムでディスパッチされたエージェントに供給されます。Product と System は通常、system prompt に入ります。Style はエージェントが照会できるツールとして提供されます(style.lookup("error handling for HTTP clients"))。Policy はディスパッチ前と各ツール呼び出し時に強制されます。Memory はベクトル検索でオンデマンドに retrieve されます。
ディスパッチがバンドルを組み立てる方法
Dispatch をクリックすると、ワークスペースがコンテキストビルドを走らせます:
- Product を Pull。 レーン概要、リンクされた Issue の受入基準、ディスパッチャーが明示的に添付した参照ドキュメント。
- System を Pull。 リポジトリマップは push のたびに抽出されます。ディスパッチはレーンのスコープクレームに関連する slice を取得します。エージェントが
apps/api/auth/**を触るなら、auth サービスのディレクトリツリー、所有権タグ、直接依存を得ます — monorepo 全体ではありません。 - Style を Pull。
.sprintloop/style.mdの中身に加え、.eslintrc、.prettierrc、pyproject.tomlなどから抽出した設定。 - Policy を Pull。 常に。opt out の方法はありません。ポリシー違反はトークンを 1 つも使う前にディスパッチを中断させます。
- Memory を Pull。 重なるパスを触った、または重なる言葉を使ったクローズ済みレーンに対するベクトル検索。デフォルトでは直近 90 日に制限。ワークスペースごとにチューニング可能。
バンドルは署名され、レーンの開始エントリに添付されます。レーンがクローズすると、バンドルを開いてエージェントが何を素材に持っていたかを正確に見ることができます。
Policy: ハードフェイル
ほとんどのディメンションは助言的。Policy はそうではありません。
ポリシーファイルはこんな見た目です — ヘルスケアの顧客の実際のフラグメント:
forbid: - paths: ["src/lib/legacyAuth/**"] reason: "Legacy auth path; rewrite blocked until migration finishes 2026-Q2" - dependencies: ["moment", "request"] reason: "Banned: replace with date-fns / native fetch"require: - test_coverage_delta: ">= 0" - reviewer: "security" on_paths: ["**/auth/**", "**/billing/**"]ディスパッチのバンドルビルドがポリシー節にヒットすると、節の種類によって 2 つのことが起きます:
- Pre-dispatch hard fail。 概要から明らかにトリガされる
forbid.pathsまたはforbid.dependencies節は、ディスパッチを即座に中断。ディスパッチャーはルール名と理由を示すバナーを見ます。トークンは使われません。 - Runtime hard fail。 ハーネスは試みることができます — 特定のファイルを read するまでポリシーが適用されることを知らないかもしれません。禁止パスへの write を試みると、ストレージ層がルール名と共に
POLICY_DENIEDを返します。エージェントは tool log に denial を見て、リダイレクトするか停滞します。 - Sign-off hard fail。
require.reviewer: "security"は、レーンがクローズする前にセキュリティレビュアー(人間またはエージェント)が sign-off したことを強制します。例外パスなし。マージボタンは無効のままです。
Policy が唯一のハードフェイルディメンションである理由は規制上の事情です: SOC 2 / HIPAA / PCI のスコープにあるワークスペースは、エージェントが言いくるめて回避できる「助言」ルールを持てません。ポリシーが「セキュリティレビュアーなしで billing に触るな」と言うなら、システムはそれを機械的に強制します。
Memory: 学習が複利化する仕組み
時間軸で面白いディメンションは Memory です。各クローズしたレーンは、ワークスペースのメモリストアに少数のシグナルを書き戻します:
- 承認されたパターン。 レーンが出荷し、レビュアーが sign-off したコードを retrieval 用に埋め込み。
- 却下されたアプローチ。 「これは動くがウチではこうしない」と言う sign-off ノートが負の例になる。
- 失敗した仮定。 エージェントがコードベースを誤って推測し、人間が訂正したとき、訂正は Q&A ペアとして保存されます。
- ドメイン語彙。 公開トレーニングセットには出てこない、チームのドメインに固有の名前、略語、頭字語。
Memory retrieval はワークスペースにスコープします。顧客間で漏れません。ワークスペース自身の鍵で at rest 暗号化されます。
複利化効果は本物ですがゆっくり — エージェントが同じ間違いを 2 回しなくなるまでアクティブ利用で 3–4 週間。直接見えるシグナル: クローズした各レーンの Memory タブは、ディスパッチが retrieve した過去のレーンを表示し、diff ページはエージェントのコミットメッセージで引用された Memory エントリを表示します。
バンドルの編集
ディスパッチダイアログから直接バンドルを編集できます: Inspect bundle をクリック、組み立てられたプロンプトと tool spec を見て、任意のディメンションをインラインで編集、保存してディスパッチ。編集は単一ディスパッチにスコープされます — 元のソースは変更しません。永続的に変更したければ、.sprintloop/style.md、ポリシーファイル、システムマップなどを変えて再抽出してください。
Inspect bundle ビューは、おかしな挙動のディスパッチをデバッグする最速の方法でもあります。エージェントが deprecated API に手を伸ばすなら、バンドルがおそらく禁止ポリシーを運んでいません。エージェントがスタイル規約を発明するなら、バンドルの Style ディメンションが薄かった。バンドルが真実で、エージェントの挙動は下流です。
次に何があるか
Context Engine は SprintLoop ディスパッチが良い決定をする方法の半分です。もう半分は Review Committee — 人間に届く前に diff を採点するレビュアーエージェントのパネル。