Amazon Q Developerのナレッジベース
Amazon QはProject Rules、リポジトリ文脈、MCP toolsをIDEまたはCLI sessionへ取り込めます。Busabaseは結果となる開発判断に責任者、証拠、レビュー点を与え、他チームが現在の事実として使う前に確認します。
4つのcontextレイヤー
指示、ソースコード、live system、受け入れ判断を適切な場所に置く。
Amazon Qは選択したファイルやフォルダー、workspace context、Project Rules、repository Customizations、MCP resourcesを使えます。いずれも推論を助けますが、権威と更新周期は同じではありません。
| レイヤー | 役割 | 所有者 |
|---|---|---|
| Project Rules | プロジェクトchatで自動利用する永続指示 | リポジトリまたはプロジェクト設定 |
| Customizations | 自動contextとして使うリポジトリ索引 | Amazon Q customization |
| MCP resources / tools | 外部サービスの現在データと実行可能action | 接続済みMCP server |
| 受け入れ済み開発判断 | チームと後続Agentが依存できるレビュー済み状態 | Busabase |
2つの実行面
CLIとIDEは異なるAgent設定から同じシステムへ到達できる。
AWSはAmazon Q Developer CLIと対応IDEの両方でMCPを文書化しています。CLI custom agent設定は~/.aws/amazonq/cli-agents、IDE default agent設定は~/.aws/amazonq/agents/default.jsonです。再現できるようsurfaceとagent profileを記録します。
Local / remote MCP
/toolsで段階的に読み込まれるserverとtoolを確認。
IDE agent MCP設定
Project context、開いているファイル、Project Rules、Customizationsも要求へ影響。
Remote review workspace
認証identityとBase policyがread/proposal actionを決定。
Contextから受け入れ状態へ
Tool境界を越えて証拠の連鎖を残す。
Qが成功を報告しても完了ではありません。利用context、実行action、返された証拠、結果を受け入れた人を記録します。
開発判断の契約
判断を再現し異議を検討するための最小状態を保存する。
CodeはGit、raw executionはAgent sessionに残します。記録は成果物を安定した判断と現在の責任者へ結び付けます。
| フィールド | 用途 |
|---|---|
| decision_key | IDE、CLI、repositoryをまたぐ安定identity |
| question | 実行が扱った開発・運用上の質問 |
| context_refs | Rules、repository revision、files、MCP records |
| action_ref | Tool call、command、job、外部request |
| evidence | Test、log、API response、diff、source URL |
| proposed_state | Amazon Qによる結果の短い解釈 |
| decision | Accepted、conditional、rejected、superseded |
| owner | 受け入れと維持に責任を持つ人 |
| effective_at | 依存作業が判断を使える時点 |
2つの権限判断
Tool permissionは実行を、record reviewは権威を制御する。
Amazon Q MCP toolsはauto-approved、requires approval、dangerousに分類できます。これはtool実行の判断です。Busabase reviewは提案フィールド、証拠、範囲、下流への影響を別に評価します。
このtoolを実行してよいか?
現在のcommandまたは外部actionを保護。
この状態をcanonicalにしてよいか?
共有記録とそれを読む全workflowを保護。
ガバナンスチェック
Agent contextからレビュー済み状態まで最小権限を使う。
Global MCP serverは1つのtaskに不要なtoolsも公開できます。Connectionを小さくし、loaded toolsを確認し、Qが到達できるだけでopen endpointを信頼しません。
接続の境界
接続ページは設定を、このページは情報契約を扱う。
Busabase endpoint、認証、CLI/IDE設定、検証手順は保守されるConnect Agentページを使います。その後、実際のAmazon Q surfaceでreadとreview-gated proposalを1回ずつテストします。
実務上の質問
Amazon Q DeveloperナレッジベースのFAQ
BusabaseはProject Rulesの代わりですか?
いいえ。Project RulesはAmazon Qのproject内での振る舞いを定義します。BusabaseはAgent、team、workflowをまたいで検索するレビュー済み事実と判断を保存します。
BusabaseはCustomizationsの代わりですか?
いいえ。CustomizationはAmazon Qにrepository index contextを与えます。Busabaseは対応revisionをリンクし、code indexを複製せず受け入れ済みの業務・運用上の意味を保存します。
CLIとIDEは1つの判断記録を共有できますか?
できます。Surface、agent profile、repository revision、evidence refsを含め、各提案の生成方法を区別します。
Auto-approved MCP toolの結果は自動的に信頼できますか?
できません。Auto-approvedは追加確認なしでtoolを実行できるという意味です。結果が完全・最新・owner権限内とは限りません。
Amazon Qはcanonical recordへ直接書くべきですか?
管理対象knowledgeでは避けます。Proposal-level accessを使い、責任者がレビューするまでChange Requestとして保持します。
1つの開発判断から始める
Amazon Qが組み立てたcontextにレビュー済みの保存先を与える。
Repositoryと運用systemをまたぐ反復質問を1つ選び、正確なIDE/CLI surfaceを接続し、evidence contractを定義して最初の提案をレビューします。

