Harness Engineering Playbook: 100倍の信頼性あるソフトウェアデリバリー
AIと人間を組織化し、信頼性の高いソフトウェアデリバリーを実現する方法
AgentsZone コミュニティによる共同著作 | 編集: 傅全志、馬驰
注意: 初期ドラフト 本書はアーキテクチャ検証段階にあります。序文と目次構成はおおむね固まっており、全体的なフレームワークに対するフィードバックを歓迎します。各章の内容はAIアシストによる初稿であり、詳細、具体例、読みやすさの磨き込みが不足しています。これらは今後のバージョンで、実践者コントリビューターにより順次補完・改善されます。
Agent Coding: 1.5倍か100倍か
この2年間、AIコーディングツールの能力フロンティアは絶えず拡大してきた。関数レベルの補完からモジュールレベルの生成、プロジェクト全体の構築まで、世代ごとにモデルの対応範囲の上限が引き上げられてきた。開発者もその進化を肌で感じている。コードを書くスピードは確かに速くなり、1.5倍、2倍のエンジニアになったと実感している。
しかし、チームが実際にデリバリーデータを振り返ると、不可解な現象が浮かび上がる。PRの数は増えるが、レビュー時間は長くなり、バグ率は上昇する。モデルはより強力で、ツールはより優れ、体感は速くなっているのに、全体の生産性向上は期待を大きく下回っている。
一方で、同じツールを使いながらまったく異なる成果を出している人々がいる。PingCAP CTOのEd HuangはAIを使ってTiDBのPostgreSQL互換レイヤーをほぼ本番品質のRustコードに書き換えた。Pigsty創設者のRuohang Fengは、460以上の拡張機能を統合したエンタープライズグレードのPostgreSQLディストリビューションを一人で保守し、日常的に10のAgentを並列稼働させている。彼らの生産性向上は数十倍単位で、デリバリーされたコードは本番環境にデプロイされ、実戦で検証済みだ。
双方の経験は紛れもない事実だ。1.5倍にしかならないという実感も正しいし、数十倍を達成して本番に投入したという話も正しい。同じモデル、同じツールなのに、このギャップはどこから生まれるのか。AgentsZoneコミュニティで100人以上の開発者と交わした対話が、明確な答えを与えてくれた。本書は、1.5倍から100倍へ至る方法論とエンジニアリングプラクティスを体系的にまとめたものである。
コーディング初心者やプロダクト担当者で、すでにVibe Codingで動くプロダクトを作り、本番で信頼性高く運用・イテレーションする方法を考えているなら、仕様と検証を扱うPart Iが直接役立つだろう。「自分でコードを書く」から「Agentにコードを書かせる」へ転換中のプログラマーなら、本書全体を通じた生産性ラダーがその移行パスを示す。単一タスクをうまく管理することから、Agentの艦隊を管理し、チーム内での自分の役割を再定義するまでだ。エンタープライズでチームのAIネイティブ変革を推進する技術リーダーなら、組織アーキテクチャを扱うPart IIIが直接関連する。今の自分のステージに合った章から読み始めてほしい。
違いは規律から生まれる
核心的な問いに立ち返ろう。1.5倍と100倍のギャップは、正確にはどこにあるのか。
主流の議論はプロンプト技法、ツール選定、モデル能力比較に集中している。それらには価値があるが、あくまでオペレーションレベルの話であり、同じツールが異なるチームの手で根本的に異なる結果を生む理由を説明できない。
我々の観察はこうだ。違いはエンジニアリング規律から生まれる。 100倍の生産性を達成しているチームは、すべてAI Agentの特性に合ったエンジニアリングシステムを構築している。1倍に留まっているチームは、人間の実践者向けに設計されたシステムのままAgentを動かしている。
ソフトウェアエンジニアリングの60年間で蓄積された制度的システム（コードレビュー、テスト戦略、モジュール化、チーム分業など）は、人間の実践者の認知特性に合わせて設計されたものだ。人間のプログラマーは曖昧な要件を常識で補い、リスクの高い操作では本能的にスピードを落とし、プロジェクトを通じて暗黙知を蓄積し、それが協働を通じて自然に伝達される。これらの能力は常に実践者自身に備わっていたもので、プロセス文書に記述する必要がなかった。実践者が最初から備えていたからだ。
実践者が人間からAI Agentに変わると、これらの暗黙の前提はすべて崩壊する。Agentは入力に忠実に従い、曖昧さはランダムな判断になる。有効な処理容量にはハードシーリングがあり、タスク規模がそれを超えると品質は崖のように低下する。記憶はセッション境界で終わり、毎回のセッションが新入社員の初日になる。注意は今の指示にしか向かず、表示テキストの1行修正と決済処理ロジックの修正がまったく同じに見える。同時に、出力速度は人間の10倍から100倍であり、これらの問題すべての影響が増幅される。
実践者が変わったなら、エンジニアリング規律も変わらなければならない。これが本書の核心テーゼだ。第1章では、これら5つの構造的特性とそれが生むエンジニアリング課題を詳細に分析する。
Vibe Codingも既存フレームワークも十分ではない理由
このテーゼを理解すれば、現行アプローチの限界が明確に見えてくる。
Vibe Codingは出発点だ。フィーリングでプロンプトを書き、AIにコードを生成させ、動けば出荷する。使い捨てスクリプトやラピッドプロトタイプには確かに効率的だ。しかしVibe Codingはオープンループ制御である。指示を出し、結果を受け取り、品質を直感で判断する。「正しい」とは何かを定義する仕様もなければ、出力が意図と合致しているかを確認する自動検証もない。オープンループシステムは小規模ならかろうじて使えるが、長期保守やチーム協働が必要なプロジェクトでは、そのランダム性は許容できないものになる。
この問題を認識し、ソフトウェアエンジニアリング手法でAI開発を組織化しようとするチームも現れている。bmad、OpenSpec、SpecKitなどのフレームワークが登場し、AI Agentに構造化された仕様を与え、エンジニアリングワークフローで生成プロセスを制約している。方向性は正しく、Vibe Codingからの大きな前進だ。
しかし、これらのフレームワークはコード生成フェーズに焦点を当てている。数十年のソフトウェアエンジニアリングの核心的教訓はその反対側にある。コードは出荷された瞬間に負債になる。生成はソフトウェアライフサイクルで最もコストが低い部分だ。設計、検証、デバッグ、デプロイ、保守を合わせると、コーディング自体をはるかに上回るコストがかかる。ソフトウェアシステムはライフサイクルの80%をリリース後に過ごす。生成フェーズだけに焦点を当てる手法は、チェーン全体で最もコストの低いリンクを最適化しているに過ぎない。
より根本的には、これらのフレームワークは依然として人間の実践者の存在を前提としている。プロセス設計、品質保証メカニズム、協働モデルは、人間が本来持つ常識、経験、判断力に依存したままだ。実践者としてのAgentの構造的差異は、これらのフレームワークでは正面から向き合われていない。
2つの基本原則
これらの課題に対し、本書のアプローチは2つのエンジニアリング原則の上に構築されている。
Closed-loop control（閉ループ制御）。 Agentを大規模に活用できているチームは、すべて何らかの形でClosed-loop controlを確立している。明示的な仕様が入力を定義し、自動検証が出力をチェックし、逸脱がリアルタイムで検出・修正される。Closed-loop controlは基本的なエンジニアリング原則だ。サーモスタット、自動運転車、産業用組立ラインはすべてフィードバックループに依存して信頼性ある動作を実現している。人間の実践者環境では、プログラマー自身がフィードバックループの一部であり、自己チェックと自己修正を行う。Agentはそうではない。フィードバックループはシステムに明示的に組み込まなければならない。Vibe Codingの根本的な問題はオープンループ制御にある。
Evolution（進化）。 ソフトウェアは継続的に保守、イテレーション、新要件への適応が必要だ。Agent駆動開発はこの課題を増幅する。Agentはコードベースに既に存在するパターンを忠実に複製する（悪いパターンも含めて）。マージされたコードは後続の生成の参照セットとなる。継続的改善のメカニズムがなければ、システムは自己強化的に劣化へ向かう。仕様、テスト、Skillカード、組織プロセスなど、あらゆるレイヤーで継続的な進化が必要だ。
この2つの原則は本書のすべての章を貫いている。Closed-loop controlが各ステップの信頼性を確保し、Evolutionがシステムの継続的な改善を保証する。
ロードマップと目次
本書は生産性ラダーに沿って展開される。第1章ではAgentの構造的特性とエンジニアリング課題を分析し、全書の理論的基盤を確立する。以降の内容は3つのPartに分かれ、それぞれが生産性の飛躍の段階に対応する。
Part I: 信頼性あるAgent Programming（1倍→10倍）。 Vibe Codingからエンジニアリングへの第一歩。Agentの前に座り、対話形式でやりとりするが、出力はランダムから信頼性あるものへ変わる。第2章では仕様によって曖昧さを確実性に変換し、第3章では自動検証によってフィードバックループを閉じる。この2章をマスターすれば、フィーリングでプロンプトを書く状態から、仕様・検証・Closed-loop controlを備えたエンジニアリングモードに移行し、生産性は数倍になる。
Part II: Agent開発のスケーリング（10倍→100倍）。 Part Iの仕様・検証システムを備えれば、Agentの自律的実行を開始できる。仕様なしの自律実行はYOLOモードであり、破綻は必至だ。第4章では長時間実行におけるコンテキスト崩壊とクロスセッションメモリを扱い、単一のAgentがセッションや日をまたいでプロジェクトに継続的に取り組めるようにする。第5章はこれをさらにマルチAgent並列処理に拡張し、分離と統合の問題を解決する。Agentのリアルタイム対話相手から、タスクの設計者・受け入れ者へと転換し、さらに一桁の生産性向上を実現する。
Part III: 100倍組織のガバナンス。 個人の生産性向上には限界がある。複数の人間がそれぞれのAgent艦隊を指揮して協働する必要が生じると、問題は技術レベルを超えて組織設計の領域に入る。Part IとIIで確立したエンジニアリングプラクティス（仕様、検証、分解、プラットフォーム）は組織レベルの協働のインフラであり、このインフラなしにはチームレベルのAgent協働は不可能だ。第6章では従来のチーム構造がなぜ機能しなくなるかを分析し、新しい役割分担とガバナンスモデルを探る。第7章ではAgent時代の組織資産、すなわち新たなモートとは何かを論じる。
Part I: 信頼性あるAgent Programming（1→10倍）
Part II: Agent開発のスケーリング（10→100倍）
- Agentを自律稼働させる: 分解、コンテキスト、メモリ
- マルチAgent並列処理: 分離と統合