Amazon Q DeveloperBusabase × Amazon Q Developer

Amazon Q Developerのナレッジベース

Amazon QはProject Rules、リポジトリ文脈、MCP toolsをIDEまたはCLI sessionへ取り込めます。Busabaseは結果となる開発判断に責任者、証拠、レビュー点を与え、他チームが現在の事実として使う前に確認します。

開発コンテキスト提案レビュー必須
Amazon Q Developerが提案した開発コンテキストを確認するBusabase
Agentは文脈を集めtoolを実行できます。再利用できる開発上の事実は記録責任者が決めます。

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を記録します。

Q CLI

Local / remote MCP

/toolsで段階的に読み込まれるserverとtoolを確認。

IDEのQ

IDE agent MCP設定

Project context、開いているファイル、Project Rules、Customizationsも要求へ影響。

Busabase

Remote review workspace

認証identityとBase policyがread/proposal actionを決定。

Contextから受け入れ状態へ

Tool境界を越えて証拠の連鎖を残す。

Qが成功を報告しても完了ではありません。利用context、実行action、返された証拠、結果を受け入れた人を記録します。

01定義開発上の質問と変更対象記録を明確化。
02取得Qが関連するproject/MCP contextを読む。
03実行許可されたtoolが外部systemを照会または変更提案。
04証拠化Code、command output、API response、test、source recordを関連付け。
05提案結果を小さなBusabase Change Requestへ変換。
06受け入れ責任者が下流で使えるか判断。

開発判断の契約

判断を再現し異議を検討するための最小状態を保存する。

CodeはGit、raw executionはAgent sessionに残します。記録は成果物を安定した判断と現在の責任者へ結び付けます。

フィールド用途
decision_keyIDE、CLI、repositoryをまたぐ安定identity
question実行が扱った開発・運用上の質問
context_refsRules、repository revision、files、MCP records
action_refTool call、command、job、外部request
evidenceTest、log、API response、diff、source URL
proposed_stateAmazon Qによる結果の短い解釈
decisionAccepted、conditional、rejected、superseded
owner受け入れと維持に責任を持つ人
effective_at依存作業が判断を使える時点
Amazon Q Developerの開発証拠を確認するBusabase Inbox

2つの権限判断

Tool permissionは実行を、record reviewは権威を制御する。

Amazon Q MCP toolsはauto-approved、requires approval、dangerousに分類できます。これはtool実行の判断です。Busabase reviewは提案フィールド、証拠、範囲、下流への影響を別に評価します。

AMAZON Q TOOL PERMISSION

このtoolを実行してよいか?

現在のcommandまたは外部actionを保護。

BUSABASE CHANGE REQUEST

この状態をcanonicalにしてよいか?

共有記録とそれを読む全workflowを保護。

ガバナンスチェック

Agent contextからレビュー済み状態まで最小権限を使う。

Global MCP serverは1つのtaskに不要なtoolsも公開できます。Connectionを小さくし、loaded toolsを確認し、Qが到達できるだけでopen endpointを信頼しません。

Identity必要なSpace/Baseだけを持つ専用Busabase identityを使う。
Tool setWorkflowに必要なread/proposal actionだけを有効化。
Approval明確な範囲なしにdangerous/state-changing toolを自動承認しない。
EvidenceNarrativeだけでなくimmutable revisionとdurable outputをリンク。
Review影響を受ける開発・運用domainを理解するownerを指定。

接続の境界

接続ページは設定を、このページは情報契約を扱う。

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を定義して最初の提案をレビューします。