自律的なソフトウェア開発に関する会話の大半は、エージェントがコードを書くことから始まります。エージェントが課題を拾い、機能を実装し、プルリクエストを作成する。デモは動作する。人々は興奮します。
自律的なデリバリーが確実に機能するためには、その自律性が動作するエンジニアリングシステムを誰かが設計しなければなりません。プロジェクト構造、技術選定、アーキテクチャの境界、設計の方向性、エンジニアリング規約、検証メカニズム、専門家の役割、承認の境界。これらは、並行して推測する独立したエージェントの集合から生まれるべきではありません。
私のアプローチは、責任の異なる分割から始まります。人間がエンジニアリングシステムを設計します。専門化されたエージェントが作業を実行します。非同期ループが、その作業がいつ行われ、次に何が起こるかを調整します。
目的は、ソフトウェア開発から人間を排除することではありません。判断、文脈、製品理解を必要とする決定に人間の関与を集中させ、実行の大部分を自律的に進められる環境を構築することです。
以下は、私が見守らなくても最終的に実行されることを意図したプロジェクトを開始するたびに従う6つのステップです。
ステップ 1: 人間がエンジニアリングシステムを設計する
プロジェクトを始める時、私は自律エージェントにその基盤を発明するよう求めません。
まず重要な部分を決定します：リポジトリの構成方法、使用する技術、主要なアーキテクチャの境界の仕組み、設計の方向性、従うべきエンジニアリング規約、そして自律性をどこで止めるべきか。これらの決定は、以降のすべての基盤となります。
次に、opencode-onboard を使用してそれらをリポジトリにエンコードします。
/make-engineer は、プロジェクトに必要な専門 AI エンジニアを作成します。フロントエンド、バックエンド、インフラストラクチャ、テスト、セキュリティ、データ、モバイルなど、製品が要求するものすべてです。これらはラベルが異なるだけの汎用エージェントではありません。それぞれに定義された専門分野、一連の能力、エンジニアリングワークフロー内での明確な位置付けがあります。
/make-architecture は、技術構造と境界を ARCHITECTURE.md にキャプチャします。 /make-design は、視覚言語、デザイントークン、コンポーネントパターンを DESIGN.md にキャプチャします。 /make-guardrails は、それらの決定すべてを、すべてのエージェントが尊重しなければならない具体的なルールに変換します。アーキテクチャの境界、命名規則、テストの期待値、コードスタイル、セキュリティ制約、Git の慣行。これらは、元の開発者だけが持つ知識ではなくなり、実行環境の一部になります。
リポジトリには、ドキュメント以上のものが含まれることになります。エンコードされたエンジニアリング組織と、その内部で作業するすべてのエージェントのための共有された信頼できる情報源が含まれます。
人間が最初にシステムを定義します。そうして初めて、自律的な実行が有用になります。
ステップ 2: 自律性の前にインタラクティブな基盤を構築する
エンジニアリングシステムが定義されたら、プロジェクトの初期基盤をインタラクティブに構築します。
この段階では通常、/plan-quick と /plan-apply を使用します。 /plan-quick は、焦点を絞った目標を分析し、それを具体的で順序付けられたタスクの並びに変換します。これは、完全な仕様ワークフローよりも意図的に軽量です。作業が明確で、可視性や制御を失うことなく迅速に進めたい場合に使用します。 /plan-apply は、それらのタスクを実装し、結果を検証します。
これにより、プロジェクトの基本インフラストラクチャを確立します。リポジトリ構造、アプリケーションスケルトン、データベースセットアップ、認証基盤、デザインシステム、テストインフラストラクチャ、CI/CD 設定、デプロイ基盤。
プロジェクトの初期段階には、その後構築されるすべてに影響を与える決定が含まれます。弱い抽象化、一貫性のないフォルダ構造、不明確なテスト戦略。これらのいずれも、自律エージェントが作業を開始すると何百回も再現される可能性があります。私はそれを目撃したことがあります。美しいものではありません。
そのため、このフェーズは迅速かつ AI 支援を受けながらも、監視下に置かれます。
目的は、可能な限り早期に自律性を最大化することではありません。目的は、プロジェクトを十分に安定、理解可能、予測可能にし、後で自律性がその内部で安全に動作できるようにすることです。
ステップ 3: 人間の関与をプロジェクトポリシーにする
基盤の準備ができたら、デリバリーシステムが持つべき自律性の度合いを決定します。
これは、手動開発と完全自動化の二者択一ではありません。人間の関与はライフサイクルの異なる時点で存在でき、適切な構成はプロジェクトによって異なります。
完全に監視されたプロジェクトでは、人間が課題を洗練し、実装計画を承認し、プルリクエストをレビューし、マージを承認し、デプロイを承認する必要があるかもしれません。
部分的に自律的なプロジェクトでは、AI が洗練と実装を行い、人間は未解決の質問に答えたり、重要なプルリクエストをレビューしたり、最終的なマージの制御を保持したりするかもしれません。
高度に自律的なプロジェクトでは、必要なガードレール、テスト、品質チェックがすべて合格した場合、システムが自動的に変更を洗練、実装、レビュー、マージすることを許可するかもしれません。
要件が不安定な新製品は、成熟した内部ツールよりも多くの人間の参加を必要とします。規制されたシステムは、小さな実験には不要な明示的な承認ゲートを必要とします。そして、同じプロジェクトでも、アーキテクチャ、テスト、デリバリーメカニズムが成熟するにつれて、時間の経過とともにより自律的になる可能性があります。
重要な点は、自律性が意図的に定義されることです。課題の洗練、質問の解決、計画の承認、プルリクエストのレビュー、マージの承認、デプロイの承認。これらは偶発的な中断ではありません。これらはエンジニアリングシステムにおける設定可能なゲートです。
すべてのプロジェクトが異なるレベルの自律性を選択し、それらの境界はプロジェクトとともに進化します。
ステップ 4: アイデアを永続的なバックログ項目にする
インタラクティブコンソールは、依然としてアイデアを調査する場です。
アイデアが不完全な場合、私は /plan-explore を使用します。これは実装コマンドではありません。協調的な探索プロセスです。エージェントはリポジトリを調査し、関連コンポーネントをマッピングし、既存のパターンを特定し、前提に挑戦し、依存関係をトレースし、リスクを考慮し、実際に何を構築すべきかを判断するのに役立ちます。
多くの開発問題は、最初はコーディングタスクのように見えますが、実際には理解の問題です。不明確なアイデアを自律的な実装ワークフローに直接送り込むと、通常は不明確な実装が生成されます。探索により、アイデアは解決策に時期尚早にコミットすることなく、実行可能な構造を得ることができます。
方向性が明確になったら、/ops-backlog を使用して、GitHub、Azure DevOps、または Jira に構造化された作業項目を作成します。作業項目は、インタラクティブな思考と非同期実行の間の永続的な引き継ぎポイントになります。これには、ワークフローの次の段階で必要となるコンテキスト、スコープ、受け入れ基準、リスク、未解決の質問、依存関係を含めることができます。
この時点で、バックログは単にタスクが保存される場所ではなくなります。人間、エージェント、ループ間の共有調整レイヤーになります。
人間はアイデアを作成し、質問に答え、決定を下します。ループは課題の状態を監視し、実行可能な作業を選択します。エージェントは、実行に必要なコンテキストとともに焦点を絞ったタスクを受け取ります。
バックログは、インタラクティブな会話を、その会話が終了した後も継続する永続的な作業に変換します。
ステップ 5: loop-task が非同期作業を調整する
プロジェクト、エンジニア、ガードレール、バックログ、承認ポリシーの準備ができたら、ローカルマシンまたは VM 内で loop-task を設定します。
loop-task は外部オーケストレーションループを実行します。これらのループは継続的にバックログを検査し、実行可能な作業を特定し、適切なエンジニアリングワークフローを呼び出し、各課題の状態を更新します。
洗練ループは、新しい課題を選択し、調査し、仕様を改善し、情報が不足している場合に質問を追加できます。人間の判断が必要な場合、課題は待機状態に移行します。担当者は可能な時に回答し、情報が表示されるとループが再開されます。
課題が十分に明確になると、実装準備完了状態に移行します。実装ループがそれを拾い上げ、自律的なエンジニアリングワークフローを呼び出します。
レビューループは、プルリクエストのフィードバックを検査し、修正を調整し、必要なワークフローを再実行し、変更を受け入れに向けて進めることができます。完了ループは、承認された作業をマージし、関連する課題をクローズし、次の実行可能な項目がシステムに入ることを許可します。
ループは互いに直接通信する必要はありません。永続的なバックログ状態を通じて調整します。典型的な課題は、次のようなライフサイクルを経ます：
新規、洗練中、回答待ち、実装準備完了、実装中、プルリクエスト、レビュー中、完了。
人間は、プロジェクトポリシーが必要とするときにいつでもプロセスに参加できますが、システムは誰かが継続的にターミナルを監視することに依存しません。開発者がオフラインの場合でも、VM はバックログをチェックし続け、実行可能な作業を前進させます。
これがループエンジニアリングの中心にある区別です：
エージェントは作業を実行します。ループは、作業がいつ存在するか、いつ開始すべきか、どのワークフローがそれを実行すべきか、そして次に何が起こるかを決定します。
ステップ 6: /plan-goal が1つの課題を最初から最後まで実行する
実装ループが準備完了の課題を見つけると、/plan-goal を呼び出します。
このコマンドは、製品の方向性を決定したり、プロジェクトのアーキテクチャを発明したりする責任はありません。それらの決定は既に行われ、リポジトリにエンコードされています。その責任は、既存のエンジニアリングシステム内で、十分に洗練された1つの作業項目を実行することです。
/plan-goal は、課題を読み取り、コードベースの関連部分を探索し、OpenSpec 提案を作成し、構造化タスクを生成し、仕様またはテストのギャップを特定し、適切な専門エンジニアを選択し、モデル層を割り当て、依存関係を計算し、実装作業を並列実行ウェーブに編成します。
独立しており、リポジトリの別々の領域を変更するタスクは、異なるエンジニアに同時に割り当てることができます。以前の作業に依存する、または同じファイルに触れるタスクは、必要な順序で実行されます。
リードエージェントは作業を調整し、各結果を収集し、焦点を絞ったコミットを作成し、テスト、リンティング、型チェック、ビルドを実行します。検証を正常に完了できない場合、変更を出荷するのではなく停止します。
実装が有効な場合、ブランチがプッシュされ、必要なコンテキストと証拠とともにプルリクエストが作成されます。
次に、設定されたプロジェクトポリシーが何が起こるかを決定します。人間がプルリクエストをレビューするかもしれません。別の AI システムがレビューを実行するかもしれません。高度に自律的なプロジェクトでは、必要なチェックがすべて合格した場合に自動的にマージされるかもしれません。他のプロジェクトでは、最終的な決定は明示的に人間に委ねられます。
これにより、システム内の2つのオーケストレーションレイヤーが明らかになります。loop-task は外部オーケストレーションレイヤーです。バックログのライフサイクルを管理し、洗練、実装、レビュー、または完了がいつ発生すべきかを決定します。/plan-goal およびその他の opencode-onboard コマンドは、内部エンジニアリングワークフローを形成します。これらは、特定の変更を探索、計画、割り当て、実装、検証、デリバリーする方法を理解しています。
会話を超えて存続するシステム
プロンプトベースの開発の限界の1つは、あまりにも多くの状態が一時的な会話の中に存在することです。
アーキテクチャを毎回説明し直さなければなりません。以前の決定は忘れられます。中断された実装を再開するのは困難です。開発者は、各ステップの後にエージェントが何をすべきかを決定するために常に存在していなければなりません。
このワークフローは、その状態を永続的なシステムに移行します。リポジトリには、アーキテクチャ、設計ルール、エンジニア、ガードレールが含まれます。OpenSpec には、計画された変更とそのタスクが含まれます。Git には、実装履歴と復旧ポイントが含まれます。バックログには、デリバリー状態と人間の決定が含まれます。ローカルマシンまたは VM は、ループが実行され続ける永続的な環境を提供します。
結果は、ソフトウェア組織全体のように振る舞おうとする単一の自律エージェントではありません。異なるコンポーネントが異なる責任を持つ、調整されたシステムです。
人間は方向性、制約、責任の境界を定義します。専門化されたエージェントは焦点を絞ったエンジニアリング作業を実行します。ループは非同期にライフサイクルを調整します。バックログがそれらを接続します。
最も重要な変化は、エージェントがより多くのコードを生成できるようになることではありません。より大きなシフトは、孤立した AI インタラクションから永続的なエンジニアリングシステムへの移行です。
すべてのタスクの前にリポジトリを説明する代わりに、プロジェクトは独自のアーキテクチャとガードレールを保持します。汎用エージェントにすべてを実装するよう依頼する代わりに、作業は専門家に割り当てられます。各ステップの後に何が起こるべきかを手動で決定する代わりに、ループは永続的なワークフロー状態に反応します。プロセス全体を会話内に保持する代わりに、進捗は課題、仕様、コミット、プルリクエスト、ローカル状態に生き残ります。
人間の役割は消えません。自律的な実行が許可される環境を設計することへと移行します。
これが私が現在構築しているモデルです：開発者が最初にエンジニアリング環境と自律性の境界を確立し、その後、非同期ループがバックログ駆動のデリバリーライフサイクルを通じて専門化されたエージェントを調整する、人間が設計した AI SDLC です。
ゼロから、ループが自律的に実行されるまで。6つのステップ。それぞれが前のステップに基づいて構築され、それぞれが会話からシステムへ、もう少し多くの状態を移行します。忘れることのないシステムへ。
追記：loop-task、opencode-onboard、およびその他のツールは、ckgrafico.com でご覧いただけます。
