AI-DLC Workflow V2のKnowledge：エージェントが「何を知っているか」を設計する
「うちのAPIパターン、毎回説明するの面倒だな…」。チームの知見をエージェントに持たせる仕組み、それがV2のknowledgeです。Memory（ルール）との違いと育て方を見ていきましょう。シリーズ第7回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 7AI-DLC Workflow V2のKnowledge：エージェントが「何を知っているか」を設計する This article
1. はじめに
この記事はAI-DLC Workflow V2（以降V2）シリーズの第7回です。第6回 ではMemoryとLearning Loopを扱い、人間のフィードバックがルールとして永続化される仕組みを見ました。
第6回の話を一言で振り返ると、「修正したら次から覚えている」仕組みでした。
memory/ディレクトリに格納されるルールは、エージェントに「何をすべきか・何をすべきでないか」を指示する行動規範です。では、エージェントが判断を下す際に参照する「背景情報」はどうでしょうか。たとえば「うちのチームはAPI GatewayでLambdaオーソライザーを必ず前段に置く」というパターン。これはルール（やれ・やるな）ではなく、設計判断の文脈として参照される情報です。
今回のゴールは、この「参照情報」をどこに・どう配置するかを理解することです。V2ではこれをKnowledgeと呼び、2層構造で管理しています。さらに、チームが持っているPDFやWordなどの既存ドキュメントをエージェントが引用できる形で取り込むDocumentKBという派生カタログも用意されています。
2. 全体像：Memory・Knowledge・ルールの位置づけ
V2でエージェントの振る舞いを形作る要素は3つあります。それぞれの役割を整理しましょう。
| 要素 | 格納場所 | 性質 | 更新モデル |
|---|---|---|---|
| ルール（Memory） | aidlc/spaces/<space>/memory/ | 行動規範（指示） | Learning Loopとpractices-discoveryで自動蓄積 |
| Tier 1 knowledge | .kiro/knowledge/（ハーネスにより異なる） | 方法論の参照情報 | フレームワーク同梱。アップグレードで上書き |
| Tier 2 knowledge | aidlc/spaces/<space>/knowledge/ | チームの参照情報 | チームが手動で管理 |
3者の関係を図で示します。
ここで重要なのは、ルールとknowledgeの違いです。ルールは「Never log PII」「Always use Result型」のような行動命令で、違反すればレビュアーが差し戻します。knowledgeは「うちのAPI Gateway構成はこうなっている」「認証フローの設計パターンはこれを採用している」のような参照情報で、エージェントが設計判断の文脈として使います。
両者はどちらも「エージェントの振る舞いを形作る」ものですが、指示と参照という異なる役割を担っています。
3. Tier 1：方法論knowledge
まずフレームワークに同梱されるTier 1を見ていきましょう。
配置場所と構造
Tier 1はハーネスのフレームワークディレクトリ内に配置されます。Kiro CLIでは
.kiro/knowledge/、Claude Codeでは.claude/knowledge/です（Knowledge ）。1
2
3
4
5
6
7
8
9
10
11
.kiro/knowledge/
├── aidlc-shared/ # 全エージェントが読む共有原則
│ ├── ai-dlc-principles.md # 方法論の中核原則
│ ├── audit-format.md # 監査イベント分類
│ ├── brownfield.md # 既存コードベースへの安全策
│ ├── state-template.md # 状態ファイルの契約
│ └── verification.md # フェーズ境界の検証ルール
├── aidlc-architect-agent/ # Architectが活性化した時だけ読む
├── aidlc-developer-agent/ # Developerが活性化した時だけ読む
├── aidlc-product-agent/ # Productが活性化した時だけ読む
└── ... # エージェントごとに1ディレクトリaidlc-shared/は全エージェントが毎ステージで読みます。エージェント別ディレクトリは、そのエージェントがステージを担当する時だけ読み込まれます。触らない理由
Tier 1ファイルはフレームワークのアップグレード時に上書きされます。ここにチームの規約を書き込んでも、次のアップグレードで消えます。チーム固有の情報を置く場所はTier 2です（次のセクションで扱います）。
同様に、
.kiro/agents/*.mdのエージェント定義ファイルにチーム情報を書き込むのも誤りです。これもフレームワーク管理下のファイルであり、アップグレードで上書きされます。4. Tier 2：チームknowledge
では、チーム固有の参照情報を配置するTier 2を見ていきましょう。
配置場所と構造
Tier 2はワークスペースの
aidlc/spaces/<space>/knowledge/に配置されます。memory/やcodekb/と同じスペースレベルのディレクトリで、スペース内のすべてのインテント（ワークフロー実行単位）から参照されます（Knowledge ）。1
2
3
4
5
6
7
8
9
10
aidlc/spaces/<space>/knowledge/ # 初回起動で空ディレクトリが作られる
├── aidlc-shared/ # 全エージェントに読まれる（任意）
│ ├── company-coding-standards.md
│ └── naming-conventions.md
├── aidlc-architect-agent/ # Architectだけが読む（任意）
│ └── api-gateway-standards.md
├── aidlc-developer-agent/ # Developerだけが読む（任意）
│ └── company-coding-conventions.md
└── aidlc-quality-agent/ # Qualityだけが読む（任意）
└── company-testing-standards.md空で始まる
初回の
/aidlc実行時、フレームワークは空のaidlc/spaces/<space>/knowledge/ディレクトリを作成します。中身のサブディレクトリやファイルは作られません。スキャフォールドコマンドも、シードされたREADMEも存在しません。必要なディレクトリを、必要になった時に自分で作る設計です。aidlc-shared/ とエージェント別ディレクトリ
ディレクトリの使い分けはシンプルです。
aidlc-shared/: 全14エージェントに適用される情報を置く場所。コーディング規約、命名規則、コミットメッセージのフォーマットなどaidlc-<agent-name>/: 特定のエージェントだけに適用される情報を置く場所。API設計パターンはArchitect向け、セキュリティポリシーはDevSecOps向け
ディレクトリ名はエージェントのslugと完全一致させます。
aidlc-architect-agent/であってarchitect/ではありません。名前が一致しないディレクトリは、ローダーが見つけられず無視されます。5. DocumentKB：チームの既存ドキュメントを引用可能にする
ここまでのTier 2は、チームが手書きするMarkdownの参照情報でした。しかし現実には、設計判断の背景はすでにPDFの設計書やWordの規約文書、Markdownのランブックとして存在していることが多いはずです。それらを手作業でknowledgeファイルに書き直すのは現実的ではありません。
そこでV2はDocumentKBを用意しています。DocumentKBは、チームが持っている既存ドキュメントをそのまま置いておき、エージェントが引用できるカタログに変換する仕組みです（
v2.6.15で追加）。同じスペースレベルのknowledge/配下に、2つのサブディレクトリとして存在します。2ディレクトリ構造：原本とカタログの分離
DocumentKBの核心は、所有者が異なる2つのディレクトリを分けていることです。この分離がすべての設計の土台になっています。
1
2
3
4
5
6
7
8
9
10
11
aidlc/spaces/<space>/knowledge/
├── documents/ # ユーザー所有：あなたの原本
│ ├── api-design-guide.pdf
│ ├── security-policy.docx
│ └── runbooks/
│ └── incident-response.md
└── documentkb/ # ツール所有：派生カタログ
├── index.json
└── <document-id>/
├── metadata.json
└── content.mddocuments/（ユーザー所有）: あなたの原本を置く場所。PDF、Word、Markdown、プレーンテキストを、好きな構造で入れて構いません。フレームワークはここを一切移動・書き換え・削除しません。 サブディレクトリで整理してもOKですdocumentkb/（ツール所有）: 原本から派生させたカタログ。index.json（全体の索引）と、ドキュメントごとのディレクトリ（metadata.json= 行の同一性とソース情報、content.md= 抽出テキスト）で構成されます。ワークスペースロックの下でトランザクショナルに書き込まれます
この分離が意味するのは、「あなたのファイルはあなたのもの、カタログはツールのもの」という明確な境界です。ツールは原本を触らないので、誤って大事なファイルを消す心配がありません。
使い方：onboard して sync する
DocumentKBは
/aidlc knowledge <verb>（または/aidlc-knowledgeスキル）で操作します。基本の流れは「documents/にファイルを置く → onboardで索引する」だけです。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# documents/ に置いたドキュメントを索引する
/aidlc knowledge onboard # 未索引のファイルをまとめて索引
/aidlc knowledge onboard <path> # 1ファイルだけ索引
# フォルダの実態とカタログを突き合わせる
/aidlc knowledge sync # 新規=索引、削除=tombstone、変更=再抽出
# カタログを確認する
/aidlc knowledge list # 全行を状態つきで一覧
/aidlc knowledge show <id> # 1ドキュメントの記録と抽出テキスト
# インテントにスコープする（省略時はスペース全体）
/aidlc knowledge associate <id> --intent <slug>
/aidlc knowledge dissociate <id> --intent <slug>
# 移動 かつ 編集された原本の同一性を修復する
/aidlc knowledge rebind <id> --to <path>主要なサブコマンドの性質を押さえておきましょう。
| verb | 何をするか |
|---|---|
onboard [path] | 1ファイル、またはdocuments/配下の未索引ファイルを索引。冪等で、変更のないファイルはalreadyと報告し二重行を作らない。編集済みファイルはその行を上書き更新しeditedと報告する |
sync | documents/とカタログを突き合わせて調整：新規を索引、削除をtombstone、無効になった行を再抽出、index.jsonが失われていれば各metadata.jsonから再構築 |
list [--json] | カタログ全行を抽出/可用性の状態つきで一覧 |
show <id> [--json] | 1ドキュメントの記録と抽出テキストを、untrusted警告つきで表示 |
associate / dissociate <id> --intent [slug] | ドキュメントを1インテントにスコープ／解除。冪等 |
rebind <id> --to <path> | 原本が移動しかつ変更された行を修復。syncではパスもダイジェストも手がかりが残らず解決できない唯一のケース |
removeは意図的に存在しません。 削除は「自分の原本を消してからsyncする」という手順です。ツールがユーザー所有ファイルに対して破壊的な操作を握らない設計です。原本を削除した行はtombstone（墓標）として残り、「一時的に到達不能」を意味するsource_unavailableとは区別されます。リカバリ境界：何が再構築でき、何ができないか
DocumentKBで最も重要な設計判断は、リカバリ境界です。「壊れても直せるもの」と「消えたら戻らないもの」の線引きが明確に決まっています。
index.jsonは再構築可能。 索引を失っても、syncが各ドキュメントのmetadata.jsonからindex.jsonを再構築します。tombstoneも含めて復元されます。各metadata.jsonが、行の同一性（ドキュメントid）とソース情報を二重持ちしているためですdocumentkb/ツリー全体の削除は不可逆。 ツリーごと消すと、すべてのmetadata.jsonも一緒に消えます。つまりドキュメントidもtombstoneもインテントリンクも失われ、syncは生き残った原本を新しいidの新規行として再オンボードします
この非対称性が設計の肝です。「索引だけ壊れた」は自動修復できるが、「カタログ全体を消した」は同一性の復元源そのものを消しているので戻せない、というわけです。
安全性：ジャーナル、シンボリックリンク拒否、untrusted扱い
DocumentKBは、外部由来のデータを扱う機能として複数の安全策を持っています。
トランザクションはジャーナルされる。 抽出処理（外部の抽出ツールを呼ぶため遅いことがある）はワークスペースロックの外で行い、ロックの中でソースのダイジェストを再検証してから、完成した staging ディレクトリを
rename()で本番位置に差し込みます。クラッシュした実行はdocumentkb/.journal/配下にどの索引行も参照しない孤児ディレクトリを残すだけで、カタログを壊しません。だから回収可能です。すべてのパスはuntrusted入力として扱う。 CLI引数、ディレクトリ走査、コミット済み索引行のいずれから来たパスも信用しません。まず
knowledge/やknowledge/documentkb/がシンボリックリンクなら、どのknowledge verbも実行を拒否します。リダイレクトされたコンテナは、以降のすべての書き込み先を決めてしまうためです（両ディレクトリがまだ無い初回実行は影響を受けません。「無い」と「リダイレクトされている」は別物です）。各パスはスキーマ検証（相対・POSIX・..禁止・NUL禁止）され、パスの構成要素にシンボリックリンクが無いことを確認し、realpath後にO_NOFOLLOWハンドルで読んだバイト列で包含関係を再チェックします。抽出テキストはデータであって指示ではない。 顧客のドキュメントに埋め込まれた命令文がワークフローを乗っ取れないよう、抽出テキストは常にuntrusted dataとして扱われます。
showはこの警告を内容とインラインで出すため、両者が切り離されることがありません。ドキュメントのパスやファイル名も同様にuntrustedです。IGNORE ALL PREVIOUS INSTRUCTIONS.mdというファイル名は、指示ではなく単なるファイル名です。各コマンドは出力の先頭にこの宣言を付けます（--jsonならpath_noticeキーが先頭に来ます）。監査イベント
DocumentKBは3つの監査イベントを持ちます：
DOCUMENT_INDEXED、DOCUMENT_UPDATED、DOCUMENT_REMOVED。これらはaidlc-knowledge.tsが発行し、インテントにスコープされたドキュメントであってもスペースレベルのシャードに書き込まれます。ドキュメントは特定のインテントより長く生き、associate/dissociateで後からスコープが移りうるため、その時々のアクティブなインテントに provenance を綴じると、1つのドキュメントの履歴がシャードをまたいで分断されてしまうからです。このイベントには、フレームワーク全体でここだけの順序の例外があります。詳しくは次のセクションで扱います。
6. エージェントの読み込み順序
ステージ開始時、エージェントのコンテキストには6ステップで情報が積み上がります（Knowledge § Knowledge Loading Order ）。
| Step | ソース | 何が読まれるか |
|---|---|---|
| 1 | aidlc/spaces/<space>/memory/ | ルールチェーン（org → team → project → phase → stage の解決済み全ルール） |
| 2 | .kiro/knowledge/aidlc-shared/ | 方法論の共有原則（Tier 1） |
| 3 | .kiro/knowledge/<agent>/ | エージェント別の方法論（Tier 1） |
| 4 | aidlc/spaces/<space>/knowledge/aidlc-shared/ | チーム共有の参照情報（Tier 2。存在する場合のみ） |
| 5 | aidlc/spaces/<space>/knowledge/<agent>/ | チーム×エージェント別の参照情報（Tier 2。存在する場合のみ） |
| 6 | 前ステージの成果物 | 現在のステージが宣言した入力に基づき、先行ステージの出力を参照 |
この順序で押さえておきたいポイントが3つあります。
ルールが最初に来る。 Step 1でルールが先に読まれることで、knowledgeはルールの文脈の中で解釈されます。「テストカバレッジ80%以上」というルールがある状態で、テスト戦略のknowledgeが読まれれば、エージェントはカバレッジ閾値を前提に戦略を適用します。
Tier 2は存在する場合のみ読まれる。 Step 4-5のディレクトリが未作成でもエラーにはなりません。空で始まるTier 2に情報を追加していくにつれ、エージェントの判断材料が徐々に増えていく構造です。
前ステージの成果物がStep 6。 これはディスク上のファイルではなく、オーケストレーターが実行時に注入するランタイムコンテキストです。現在のステージが必要とする入力に基づいて、先行ステージの出力が参照されます。
なお、DocumentKB（前セクション）は、この自動的な6ステップの読み込みとは性質が異なります。手書きの
aidlc-shared/やエージェント別ディレクトリが「ステージ開始時に自動で読まれる」のに対し、DocumentKBはエージェントが**引用（cite）**する対象のカタログです。読み込み順の一部として毎回全文が積み上がるのではなく、showなどを通じて参照される点を区別しておきましょう。7. 最初のknowledgeファイルを作る
ここまで構造を見てきました。では実際にTier 2にファイルを追加してみましょう。ドキュメントに記載されているAPI Gatewayの例をベースに進めます（Knowledge § Worked Example ）。
状況
チームではAmazon API GatewayをREST APIとして使い、全ルートにLambdaオーソライザーを配置し、リクエストバリデーションをゲートウェイ層で行い、レスポンスは統一エンベロープで返す設計を採用しています。Architectエージェントに新規API設計時にこのパターンを前提としてほしい場合を考えます。
Step 1: ディレクトリを作る
初回
/aidlcでaidlc/spaces/default/knowledge/は空の状態です。必要なサブディレクトリを作ります。1
mkdir -p aidlc/spaces/default/knowledge/aidlc-architect-agentディレクトリ名は
aidlc-architect-agentです。architectやarchitectureではありません。Step 2: knowledgeファイルを作成する
1トピック1ファイルで作成します。
1
2
# ファイルパス
aidlc/spaces/default/knowledge/aidlc-architect-agent/api-gateway-standards.mdファイル名のルールは3点です。
- 小文字ハイフン区切り
- トピックを表す名前にする（
architecture.mdのような汎用名は避ける） - 拡張子は
.md
Step 3: 内容を書く
エージェントはファイルをそのまま読むため、簡潔に、参照しやすい構造で書きます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
All new HTTP APIs use Amazon API Gateway REST APIs with:
- Lambda authorizer in front of every route
- Token source: Authorization header, Bearer scheme
- Authorizer result cached for 300 seconds
- Every request body validated against a JSON schema attached to the method
- Reject at the gateway layer — do not validate in handlers
All successful responses follow:
{ "data": <payload>, "requestId": "<uuid>", "timestamp": "<iso-8601>" }
Error responses follow:
{ "error": { "code": "<short-code>", "message": "<human-readable>" }, "requestId": "<uuid>" }Step 4: ワークフローを実行する
次に
/aidlcを実行すると、Architectエージェントがステージを担当する時点でこのファイルが自動で読み込まれます。設定変更やCLIフラグは不要です。ファイルの存在そのものが登録です。確認方法
ファイルが読まれているか確認するには、ワークフロー中の承認ゲートで「このステージではどのチームknowledgeを参照していますか？」と質問します。エージェントは読み込んだTier 2ファイルを一覧で回答します。
既存ドキュメントがあるなら：手書きの代わりにDocumentKB
もしAPI設計標準がすでにPDFやWord文書として存在しているなら、手書きのknowledgeファイルに書き直す必要はありません。
documents/にその原本を置いて/aidlc knowledge onboardするだけで、エージェントが引用できるカタログに変換されます（セクション5参照）。手書きのTier 2ファイルとDocumentKBは併用でき、前者は「短い規約を直接書く」、後者は「既存の分厚いドキュメントをそのまま取り込む」使い分けになります。8. Knowledge vs Rules：使い分けガイド
knowledgeとルールはどちらもエージェントの振る舞いに影響しますが、使い分けの基準は明確です（Knowledge § Knowledge vs Rules ）。
| knowledgeを使う場面 | ルールを使う場面 |
|---|---|
| 判断の材料として参照する情報 | 違反したら差し戻しになる行動規範 |
| 「うちのパターンはこうです」 | 「これは絶対やるな / 必ずやれ」 |
| 長い散文、テーブル、図を含む場合がある | 1行の命令文で書ける |
特定のエージェント・ドメインに閉じることが多い（aidlc-shared/で全エージェントにも適用可能） | ステージやエージェントをまたいで適用される |
| チームが手動で追加・更新する | Learning Loopやpractices-discoveryで蓄積される |
具体例で考えてみます。
| 情報 | 分類 | 理由 |
|---|---|---|
| API Gatewayの構成パターン（オーソライザー、バリデーション、エンベロープ） | knowledge | 設計判断の参照材料。違反しても即差し戻しではなく、文脈次第で別パターンもあり得る |
| 「PIIをログに出力してはならない」 | ルール | 違反すればレビュアーが差し戻す。例外なく適用される行動規範 |
| ドメイン用語集（"transaction"は銀行取引を意味する） | knowledge | エージェントがドメイン固有の文脈を正しく解釈するための参照情報 |
| マイクロサービス間通信にgRPCを使う設計方針 | knowledge | Architectが設計時に参照する背景情報 |
| 既存のPDF設計書・Word規約文書 | knowledge（DocumentKB経由） | 原本をそのままdocuments/に置き、onboardして引用可能にする |
| 「データアクセスは必ずRepository層を経由すること」 | ルール | コード生成時に必ず従うべき規約。違反すればレビュアーが差し戻す |
判断に迷った時の基準は、「レビュアーが不合格にするかどうか」です。不合格なら
memory/にルールとして書き、合格だが改善を促すならknowledge/にknowledgeとして書きます。既にドキュメント化された参照情報があるなら、DocumentKBで取り込みます。9. 維持管理とリファクタリング
knowledgeファイルは一度書いて終わりではありません。プロジェクトの進化に合わせて管理していく必要があります（Knowledge § Managing Knowledge Over Time ）。
更新
ファイルを直接編集します。knowledgeはステージ開始時に毎回読み込まれるため、次の
/aidlc実行で変更が反映されます。キャッシュや登録の更新は不要です。DocumentKBの原本を更新した場合は、
/aidlc knowledge sync（または該当パスのonboard）を実行すると、変更された行が再抽出され、editedとして報告されます。削除
手書きのknowledgeファイルは、削除するだけで完了です。レジストリも設定ファイルもないため、クリーンアップの手順はありません。DocumentKBの場合は、
documents/の原本を削除してから/aidlc knowledge syncを実行します。tombstone行が残り、以降のステージで参照されなくなります。分割
1ファイルが複数トピックを扱うようになった場合は分割します。
1
2
3
4
api-standards.md
→ api-gateway-standards.md
api-versioning-standards.md
api-error-handling-standards.md小さなファイルの方が更新しやすく、レビューしやすく、矛盾が入り込みにくくなります。
昇格
特定エージェント向けに書いたknowledgeが実はチーム全体に適用される場合、
aidlc-shared/に移動します。1
2
aidlc/spaces/default/knowledge/aidlc-architect-agent/naming-conventions.md
→ aidlc/spaces/default/knowledge/aidlc-shared/naming-conventions.mdaidlc-shared/に配置されたファイルは全14エージェントに読まれるようになります。レビュー頻度
knowledgeファイルは古くなると、エージェントの判断を積極的に誤らせます。現在の実態と合わない情報がコンテキストに含まれるためです。
2つのタイミングでのレビューが有効です。
- スプリントレトロ（軽いチェック）: 直近で違和感のあったエージェントの振る舞いがknowledge起因かを確認し、必要なら更新・削除する
- 四半期プルーニング: 全ファイルを開き、現在の実態と合っているかを確認する。合っていないファイルは更新か削除する
10. ベストプラクティス
ここまでの内容を踏まえ、knowledge管理のベストプラクティスをまとめます（Knowledge § Best Practices ）。
1トピック1ファイルにする。
company-standards.mdに全部入れるのではなく、api-gateway-standards.md、auth-standards.md、logging-standards.mdのようにトピックで分割します。更新時に影響範囲が明確になり、不要になった時に安全に削除できます。ディレクトリ名はエージェントのslugと完全一致させる。
aidlc-architect-agent/であってarchitect/ではありません。名前が一致しないディレクトリは無視されます。Tier 1を編集しない。
.kiro/knowledge/配下はフレームワーク管理です。チームの情報は必ずaidlc/spaces/<space>/knowledge/に置きます。エージェントの振る舞いを制約したい場合はルール（memory/）を使います。大きくなったら分割する。 1ファイルが複数の関心事を含み始めたら、トピックごとに分けます。エージェントはファイルをそのまま読むため、無関係な情報が混在するとノイズになります。
aidlc-shared/の使用は慎重に。 全エージェントに本当に適用される情報だけをaidlc-shared/に入れます。API設計パターンは全エージェントに必要ですか。Architectだけで十分なら、エージェント別ディレクトリに置く方が適切です。エージェント定義ファイルを編集しない。
.kiro/agents/*.mdにチーム情報を書き込むのは、Tier 1ファイルを編集するのと同じ誤りです。アップグレードで消えます。既存ドキュメントはDocumentKBで取り込む。 分厚いPDFやWord文書を手でMarkdownに書き直さないこと。
documents/に原本を置いてonboardすれば、原本を保ったままエージェントが引用できます。原本はdocuments/（ユーザー所有）に、カタログはdocumentkb/（ツール所有）に分かれるため、ツールがあなたのファイルを壊すことはありません。documentkb/ツリーを手で消さない。 索引が壊れた程度ならsyncで再構築できますが、documentkb/ツリーごと削除するとドキュメントidもtombstoneもインテントリンクも失われ、復元できません。削除したいのは常にdocuments/側の原本であり、その後syncする、という手順を守ります。11. まとめ
この記事ではV2の2層knowledgeシステムと、その上に載るDocumentKBを見てきました。
- ルール（Memory） は行動規範。Learning Loopで蓄積され、「やれ・やるな」をエージェントに指示する
- Knowledge は参照情報。チームが手動で管理し、エージェントが設計判断の文脈として使う
- Tier 1 はフレームワーク同梱の方法論knowledge。触らない。Tier 2 はチーム管理の参照情報。空から育てる
- DocumentKB はTier 2 knowledgeルート配下の派生カタログ。
documents/（ユーザー所有の原本）とdocumentkb/（ツール所有のカタログ）を分け、既存のPDF/Word/Markdownを原本のまま引用可能にする。index.jsonは再構築できるが、documentkb/ツリー全体の削除は不可逆
ルールが「エージェントの行動を制約する」仕組みなら、knowledgeは「エージェントの判断材料を豊かにする」仕組みです。DocumentKBは、その判断材料をチームがすでに持っているドキュメントから引き出す仕組みです。これらを使い分けることで、エージェントはチームの文脈を理解した上で、チームのルールに従って動くようになります。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 7AI-DLC Workflow V2のKnowledge：エージェントが「何を知っているか」を設計する This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article