CI/CDが自動化したものと、できなかったもの
CI/CDが開発現場に根付いたのは、「決定的な処理」を自動化できたからだ。pushやPR作成をトリガーに、lint・test・build・deployというパイプラインが回る。入力に対して一意の結果が期待できる、ルールベースの世界。これは確かに強力だった。
だが、その枠の外には手つかずの仕事が山積みになったままだった。PRの背後にある設計意図の解釈、重複Issueの整理、曖昧なユーザーフィードバックからのバグ特定、セキュリティ観点でのコード差分精査——これらは「文脈の理解」と「高度な判断」を必要とするため、決定的なパイプラインでは処理できない。人間が毎回ゼロから認知負荷をかけて対処してきた領域だ。
OpenClawの開発者Peter Steinberger氏が提唱するのは、まさにこの「CI/CDが届かなかった領域」を自動化する構想だ。
OpenClawが実践するエージェントネイティブ運用の実態
OpenClawでは現在、常時100近いAIエージェント（codex）がクラウド上でバックグラウンド稼働している。そのほとんどは開発者からは「不可視のインフラ」として機能しており、チーム規模はわずか6名だという。
具体的に何をやっているかを見ると、話が実感しやすい。
- clawsweeper：mainブランチへの修正が完了すると、関連する古いIssue（6ヶ月前のものなど）を正確なリファレンスと共に特定し、自動クローズする
- 会議からのPR自動生成：GPT Realtime 2と音声プラグインを活用し、会議中の議論をリアルタイム解析。新機能について話している最中に、その場でPRの下書きを作り始める
- QAラボ：回帰テスト専用のエージェント群がパフォーマンステストを継続的に実行し、悪化が検知されればDiscordへ即座に報告
- clawpatch.ai：プロジェクトを機能単位に分割し、バグや回帰テストを効率的に検出
入力ソースもGitリポジトリだけではない。GitHub、Discord、会議の音声、ログ、一時環境（Crabbox.sh）まで範囲が広がっている。ここが従来のCI/CDとの最大の違いだ。
Steingberger氏は「トークンのコストが問題にならない未来、ソフトウェア開発はどう変わるか？」という問いを投げかけている。この問い自体が、現在の実践をコスト前提で見るのではなく、アーキテクチャとして再設計せよという示唆になっている。
ここからは見方の話：これは何の地殻変動か
「CI/CDの正当なる進化」という整理は、構造的にはかなり正確だと思う。CI/CDが手動ビルドやデプロイを過去のものにしたように、エージェントネイティブ運用は「人間が背負ってきた認知作業」を引き受けようとしている。自動化の対象が「処理」から「判断」へシフトしたというのが本質だ。
ただ、「正当な進化」という言葉で一括りにすると、重要な断絶が見えにくくなる。CI/CDは決定的な処理を自動化するものだから、パイプラインが壊れたときの原因追跡が比較的やりやすい。一方、エージェントが「文脈を読んで判断した結果」に問題があったとき、その責任の所在とトレースはずっと難しい。
OpenClawが実際に取り組んでいるガードレール設計——読み取り専用から始める段階的導入、候補提示によるHuman-in-the-loop、マージやユーザーメッセージへの承認ステップ、エージェントによる根拠の明示義務——は、この問題に対する現時点での実践的な答えだ。「自律化を進めながら、どこで人間が介在するか」の設計こそが新しいエンジニアリングの仕事になっている。
開発者の役割変化についても、「オペレーターから成長者（Grower）へ」という表現は示唆に富む。設計図通りに作る建築家ではなく、自律的に動くエージェント群を育て、方向を与える存在。これはソフトウェア開発のスキルセットの問い直しでもある。
実務的な示唆：今すぐ考えるべきこと
100体のエージェントを今すぐ動かす必要はない。元記事が示す段階的導入の3ステップは現実的な指針だ。
- 「要約」から始める：PRの差分やCIの失敗ログをAIに整理させ、人間の初期調査コストを下げる
- 「候補提示」に広げる：重複Issueの検出や修正提案を行わせる
- 「アウトプット」へ段階的に移行する：信頼が得られた段階でPR下書きや検証動画の自動生成を許可する
多くのチームは今、1と2の間あたりにいるはずだ。ここで焦って3に飛ぶと、エージェントの判断ミスが外部に影響する範囲が一気に広がる。ガードレールを後付けするのは、前から設計するより何倍も難しい。
もう一点、見落とされがちな論点がある。エージェントが「どのファイルや過去の議論を参照してその結論に至ったか」のソース明示を義務化するという運用は、実は監査やオンボーディングにも直結する。新しいメンバーがプロジェクトに入ったとき、エージェントの判断ログが「プロジェクトの意思決定の歴史」として機能し始める可能性がある。
次に来る論点
最終的にSteingberger氏が描くのは「Dark Factory（無人工場）」のような自律運用だが、そこに至る前に次の論点が表面化するはずだ。
コスト構造：100近いエージェントを常時稼働させるトークンコストは、現在の料金水準では相当な額になる。「トークンコストが問題にならない未来」を前提にした設計が、今の料金水準で成立するチームはどれだけあるか。
責任の所在：エージェントがIssueを自動クローズし、PRを自動作成し、外部ユーザーへのメッセージを自動送信するとき、判断が誤っていた場合の責任は誰が取るか。これは技術の問題ではなく、組織と契約の問題だ。
スキルの二極化：エージェント群を設計・管理できる「Grower」と、そうでない開発者の間に、どんな評価・報酬の差が生まれるか。
OpenClawの実践は現時点では先進事例だが、この方向性は一部の先端チームだけの話ではなくなっていく。「うちには関係ない」と思っている間に、競合がエージェント群によって認知作業コストを大幅に下げている、という事態は2〜3年のスパンで十分起こりうる。今の段階で構造を掴んでおく価値は、そこにある。
