システム概要
はじめに
Autonomous EngineerはAIエージェントを使用してソフトウェア開発ライフサイクルを自動化するよう設計されたシステムです。
システムはAIモデルを調整して以下のエンジニアリングタスクを実行します：
- 仕様生成
- システム設計
- タスク計画
- 機能実装
- コードレビュー
- 反復的改善
- プルリクエスト作成
単純なコーディングアシスタントとして機能するのではなく、システムは構造化された開発プロセスを調整するワークフローオーケストレーターとして動作します。
システムは仕様駆動開発（SDD）と、各開発フェーズを管理する状態駆動型ワークフローエンジンを中心に構築されています。
高レベルアーキテクチャ
システムはいくつかの主要なサブシステムで構成されています。
┌─────────────────────────┐
│ CLIレイヤー │
│ (ユーザーインタラクション) │
└─────────────┬───────────┘
│
▼
┌─────────────────────────┐
│ ワークフローエンジン │
│ (状態オーケストレーション) │
└─────────────┬───────────┘
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
仕様エンジン 実装エンジン レビューエンジン
(SDDアダプター) (タスク実行) (品質ループ)
│ │ │
└──────────────┬──────┴──────┬──────────────┘
▼ ▼
LLMプロバイダー Gitコントローラー
レイヤー (リポジトリ操作)
│
▼
メモリシステム各サブシステムには明確に定義された責務があり、明確に定義されたインターフェースを通じて通信します。
コアコンポーネント
1. CLIレイヤー
CLIレイヤーはシステムを実行するためのエントリーポイントを提供します。
コマンド名は aes で、Autonomous Engineer System（自律型エンジニアリングシステム）の略称です。
コマンド例：
aes run <spec-name>CLIはワークフローエンジンをトリガーして完全な仕様駆動開発パイプラインを実行します。
責務：
- ユーザーインタラクション
- 設定の読み込み
- 実行トリガー
- 進捗レポート
2. ワークフローエンジン
ワークフローエンジンはシステムの中央オーケストレーターです。
開発ライフサイクルをステートマシンとして管理します。
各フェーズは特定の開発アクティビティに対応します。
典型的なワークフロー：
SPEC_INIT (llm slash command: `/kiro:spec-init <spec-name>`)
↓
HUMAN_INTERACTION (user input minimum requirements on `requirements.md` manually)
↓
VALIDATE_PREREQUISITES (llm prompt)
↓
SPEC_REQUIREMENTS (llm slash command: `/kiro:spec-requirements <spec-name>`)
↓
VALIDATE_REQUIREMENTS (llm prompt)
↓
REFLECT_ON_EXISTING_INFORMATION (llm prompt)
↓
VALIDATE_GAP (llm slash command: `/kiro:validate-gap <spec-name>` optional)
↓
CLEAR_CONTEXT (llm slash command: `/clear`)
↓
SPEC_DESIGN (llm slash command: `/kiro:spec-design -y <spec-name>`)
↓
VALIDATE_DESIGN (llm slash command: `/kiro:validate-design <spec-name>` optional)
↓
REFLECT_ON_EXISTING_INFORMATION (llm prompt)
↓
CLEAR_CONTEXT (llm slash command: `/clear`)
↓
SPEC_TASKS (TASK_GENERATION) (llm slash command: `/kiro:spec-tasks -y <spec-name>`)
↓
VALIDATE_TASK (llm prompt)
↓
CLEAR_CONTEXT (llm slash command: `/clear`)
↓
IMPLEMENTATION LOOP (repeat per task group):
SPEC_IMPL (llm slash command: `/kiro:spec-impl <spec-name> [task-ids]`)
↓
VALIDATE_IMPL (llm prompt)
↓
COMMIT (git command)
↓
CLEAR_CONTEXT (llm slash command: `/clear`)
↓
PULL_REQUEST (git command)(llm prompt) または (llm slash command: ...) と注記されたステップは、人間の承認ゲートなしにオーケストレーター内で自動実行されます。(user input ...) と注記されたステップはユーザーによる手動入力が必要です。optional と注記されたステップはワークフローの設定に応じてスキップ可能です。REFLECT_ON_EXISTING_INFORMATION ステップは完了したフェーズを振り返り、ステアリングドキュメント、ルール、コマンドなどのエージェントリソースの改善ヒントを洗い出すポストフェーズ振り返りです。CLEAR_CONTEXT ステップはフェーズ間のコンテキスト汚染を防ぐために LLM のコンテキストウィンドウをリセットします。
ワークフローエンジンの責務：
- システムフェーズの調整
- 適切なエンジンの呼び出し
- 遷移の管理
- コンテキスト境界の制御
これにより、開発が構造化された決定論的な方法で進行します。
3. 仕様エンジン
仕様エンジンは仕様駆動開発フレームワークとの統合を処理します。
システムはアダプターを通じて複数のSDD実装をサポートするよう設計されています。
サポートされるフレームワーク：
- cc-sdd
- OpenSpec
- SpecKit
抽象化の例：
SpecEngine
├── CCSddAdapter
├── OpenSpecAdapter
└── SpecKitAdapter責務：
- 仕様の初期化
- 要件の生成
- 設計ドキュメントの作成
- 設計の検証
- 実装タスクの生成
この抽象化により、システムは異なる仕様ワークフローをサポートできます。
4. 実装エンジン
実装エンジンは仕様プロセス中に生成されたタスクを実行します。
タスクは通常セクションまたはサブタスクに分割されます。
各タスクセクションは構造化されたループに従います：
実装
↓
レビュー
↓
改善
↓
コミット責務：
- タスクセクションの実行
- コード生成のためのAI呼び出し
- レビューサイクルの調整
- コミットの管理
このループは、タスクセクションが許容できる品質レベルに達するまで継続されます。
5. レビューエンジン
レビューエンジンは開発中の品質と正確性を確保します。
生成された出力の反復的評価を実行します。
レビューアクティビティ：
- 設計検証
- コードレビュー
- 要件整合性チェック
- 改善提案
レビューエンジンは品質しきい値が満たされるまで複数回のイテレーションを実行することがあります。
ループ例：
出力生成
↓
レビュー
↓
問題の特定
↓
改善
↓
繰り返し6. LLMプロバイダーレイヤー
LLMプロバイダーレイヤーはAIモデルへのアクセスを抽象化します。
システムは統一されたインターフェースを通じて複数のプロバイダーをサポートする必要があります。
例：
LLMProvider
├── ClaudeProvider
├── CodexProvider
├── CursorProvider
└── CopilotProvider責務：
- プロンプト実行
- レスポンス取得
- コンテキスト管理
- プロバイダー固有の処理
この抽象化により、システムが単一のAIプロバイダーに依存することを防ぎます。
7. Gitコントローラー
Gitコントローラーはリポジトリ操作を管理します。
責務：
- ブランチ作成
- コミット
- プルリクエスト生成
- リポジトリ状態の検査
システムによって自動的に実行されるアクション例：
ブランチ作成
タスク実装
変更のコミット
ブランチのプッシュ
プルリクエスト作成これにより、エンドツーエンドの開発自動化が可能になります。
8. メモリシステム
永続的メモリはシステムの重要なコンポーネントです。
メモリシステムは開発中に生成された知識を保存します。
メモリはいくつかのレイヤーに分かれています。
短期メモリ
単一のワークフロー実行中に使用される一時的なコンテキスト。
例：
- 現在の仕様コンテキスト
- タスク実行履歴
- 現在の設計アーティファクト
プロジェクトメモリ
リポジトリ固有の知識。
例：
- コーディング規約
- アーキテクチャ決定
- 繰り返し使用される実装パターン
- レビューフィードバック
知識メモリ
過去の開発アクティビティから抽出された再利用可能なパターン。
例：
- 実装戦略
- デバッグパターン
- ルールの改善
9. 失敗エスカレーション（自己修復）
実装ループがセクションごとのリトライ予算を使い切った場合、システムはそのセクションを自己修復ループにエスカレーションします。
プロセスは以下を含みます：
セクションのリトライ予算が枯渇
↓
根本原因分析（LLM：なぜ繰り返し失敗したか？）
↓
ギャップ特定（LLM：どのルールファイルを更新すべきか？）
↓
ルールファイルへの変更内容の書き込み
↓
失敗レコードをメモリに永続化出力には以下のファイルの更新が含まれる場合があります：
.kiro/steering/coding_rules.md
.kiro/steering/review_rules.md
.kiro/steering/implementation_patterns.md
.kiro/steering/debugging_patterns.md実行可能なギャップが見つからない場合、または以前に記録済みのギャップと重複する場合、そのセクションは手動介入のために escalated-to-human とマークされます。
これにより、リトライ予算内で自己解決できない種類の失敗に遭遇したとき、システムが自身のルールを更新できます。
10. フェーズリフレクション
各ワークフローフェーズが完了した後——成功した場合でも——システムは REFLECT_ON_EXISTING_INFORMATION ステップを実行します。
その動機は、成功だけでは不十分だという点にあります。情報収集に時間がかかった場合、コンテキストをゼロから再構築する必要があった場合、またはエージェントが不足したドキュメントを補いながら作業した場合、将来の実行でも同じ非効率が繰り返されます。
このリフレクションステップでは、「このフェーズをより速く、より明確にするために何ができたか？」 を問います。
フェーズ完了（成功または部分的な成功）
↓
発生した情報ギャップのリフレクション
↓
改善機会の特定
↓
エージェントリソースの更新（ステアリング、ルール、コマンド、ドキュメント）失敗エスカレーションパス（セクション9）とは異なり、このステップは積極的に実行されます——失敗によってトリガーされるのではなく、その出力は現在のフェーズの再試行ではなく将来のフェーズを改善します。
11. コンテキスト管理
LLMコンテキストは以下を避けるために慎重に管理する必要があります：
- トークンの過剰使用
- コンテキストの汚染
- 推論品質の低下
システムはいくつかの戦略を適用します。
フェーズ分離
ワークフローが新しいフェーズに遷移するときにコンテキストがリセットされます。
タスク分離
各タスクセクションは最小限のコンテキストウィンドウで実行されます。
コンテキストプルーニング
プロンプトには関連するアーティファクトのみが含まれます。
これらの戦略により、推論品質が向上し、トークン消費量が削減されます。
拡張性
アーキテクチャはモジュール式で拡張可能に設計されています。
主な拡張ポイント：
SDDフレームワーク
異なる仕様システムはアダプターを介して統合できます。
AIモデルプロバイダー
コアワークフローを変更することなく新しいLLMプロバイダーを追加できます。
ワークフローバリアント
異なるプロジェクトタイプに対して代替ワークフローを実装できます。
メモリバックエンド
メモリストレージシステムはプロジェクトの成長に応じて進化できます。
実行フロー
典型的な実行フロー：
ユーザーがコマンドを実行
↓
CLIがワークフローを初期化
↓
ワークフローエンジンが仕様ライフサイクルを開始
↓
仕様エンジンがアーティファクトを生成
↓
タスクが生成される
↓
実装エンジンがタスクを実行
↓
レビューエンジンが出力を検証
↓
Gitコントローラーが変更をコミット
↓
プルリクエストが作成されるプロセス全体が最小限の人間の介入で実行できます。
将来の進化
現在のアーキテクチャは将来のマルチエージェントシステムをサポートするよう設計されています。
将来のバージョンでは以下の専門エージェントが導入される可能性があります：
- プランニングエージェント
- 仕様エージェント
- 実装エージェント
- レビューエージェント
- アーキテクチャエージェント
これらのエージェントが協力して完全自律エンジニアリングチームを形成します。
現在のシステムはこの進化の基盤となります。
詳細情報
各サブシステムの詳細なアーキテクチャドキュメント：
- アーキテクチャ概要 — レイヤードアーキテクチャ、原則、ディレクトリ構造
- エージェントループ — PLAN→ACT→OBSERVE→REFLECT→UPDATEサイクル
- ツールシステム — ツールインターフェース、レジストリ、エグゼキューター、カテゴリー
- コンテキストエンジニアリング — コンテキストレイヤー、プランナー、トークンバジェット
- タスク計画 — ゴール→タスク→ステップ階層、計画ライフサイクル
- エージェント安全性 — 権限、ワークスペース分離、ガードレール
- コードベース解析 — シンボルインデックス、依存グラフ、セマンティック検索
- メモリアーキテクチャ — 短期、プロジェクト、知識メモリレイヤー
- 仕様駆動ワークフロー — 完全なSDDフェーズワークフロー
- 仕様計画 — v1実装を10の独立した仕様に分解