エクストーンでAndroidエンジニアをしている石原です。本記事は私個人が9ヶ月続けてきた実験の記録で、チームや会社の標準的なやり方ではありません。一人のエンジニアが何を試して、何にぶつかったかという前提で読んでいただければと思います。
はじめに：コードを書かなくなった9ヶ月
2025年7月、Claude Codeに触れた瞬間に「これは何かが根本的に変わる」という直感がありました。明確な根拠はありません。ただ、試さずにはいられませんでした。当時はツールも発展途上で、短期的には生産性が落ちることも覚悟していました。それでも踏み切ったのは、失敗しても得るものは大きいという予感があったからです。
そこで決めたのが、コードを100% Agentに書かせるという実験でした。
最初は半信半疑でした。本当に全部を任せていいのか、ずっと決めかねていた時期もあります。ただ9ヶ月続けてみて、想定以上の手応えが返ってきました。100%を目指したからこそ、Agentが得意な領域と人間の判断が不可欠な領域の境界線が、実践を通じて鮮明になっていきました。
「コードを書く力が不要になる」という話ではありません。Agentの出力を正しく評価するには技術力が前提になります。ただ、価値の重心は確実に動いていくと感じています。エンジニアの本質的な価値は「コードを書くこと」から「何を解くべきかを定義し、正しく導くこと」へ移っていくんじゃないかと思っています。
2026年に入って海外でも同様のアプローチが報告され始めました。個人の思いつきではなく、業界全体で起きつつある構造的な変化なのかもしれません。
本記事ではこの9ヶ月で得た知見を Builder-Driven Development として体系化します。当初は「Agent-Driven Development」と呼んでいました。ただ実践を重ねるうちに気づいたのは、駆動しているのはAgentではなく人間——builderだということです。Claude Codeの開発者であるBoris Chernyは「ソフトウェアエンジニアという肩書きはbuilderに置き換わる」と書いています。Builder-Driven Developmentは、この潮流を開発プロセスとして言語化する試みです。
1. Builder-Driven Developmentとは何か
Builderとは何か
Builder-Driven Developmentにおける「builder」とは、自らコードを書く者ではなく、課題を定義し、Agentを使って解決を実現する者を指します。その振る舞いはEM（エンジニアリングマネージャー）に近く、Agentというエンジニアリングリソースをマネジメントする存在です。
builderはエンジニアに限りません。デザイナーでもPMでも、課題を構造化しAgentに解かせる能力があれば、builderと呼べます。AIツールによって「作る」行為の参入障壁が下がったことで、職種ではなく行動がbuilderを定義するようになってきました。
従来の開発では、エンジニアの価値は「コードを書く能力」で測られていました。Builder-Driven Developmentでは、価値の源泉が変わります。従来との比較を以下に整理しました。
従来とBuilder-Drivenの価値比較
| 従来 | Builder-Driven |
|---|---|
| コードを書く速度・品質 | 課題を定義し、Agentに解かせる能力 |
| 実装の技術力 | Agentに適切なコンテキストとIssueを与える能力 |
| デバッグ力 | Agentのアウトプットを評価・修正する判断力 |
| 個人の生産性 | Agentセッションを効率的に管理する統率力 |
これは人間のチームメンバーに仕事を振るときとほぼ同じ構造です。マネージャーとして「何を解くべきか」を定義し、適切な粒度でタスクを切り、メンバーに委任し、アウトプットをレビューします。9ヶ月やってみて、この類似性は偶然ではないと感じています。Agentを上手くマネジメントできる人は、人間のチームもうまくマネジメントできます。逆もまた然りです。
「AI丸投げ」との違い
Builder-Driven Developmentは「AIに丸投げ」とは別物です。
丸投げのアプローチは「この機能を作って」と投げて、出力をそのまま使う形です。これだと品質にばらつきが出ますし、的外れなアウトプットも増えます。
対してBuilder-Driven Developmentは、「このシステムにはこういう構造的課題があり、ここに介入すると効果的だ。だからこのIssueをこの粒度で解いてほしい」という形で、文脈と判断軸ごとAgentに渡します。出力はドメイン知識で評価・修正します。結果として、一貫した品質と的確なアウトプットが返ってきます。
違いは一行で言えます。自分の経験・仮説・視点をAgentに食わせているかどうか。これがなければAgentを使う意味がありません。いくらツールが高性能でも、入力が曖昧なら出力も曖昧になります。
なお、2025年以降「vibe coding」「agentic coding」といった用語でAI活用が語られるようになりましたが、これらはツールや手法を名前に据えています。Builder-Driven Developmentで主体に置きたかったのは、ツールではなく作る人間そのものです。
2. Builder-Driven Developmentの成長段階
Builder-Driven Developmentは、AIツールの使い方を覚えれば実践できるものではありません。実践者には段階があり、それぞれの段階で求められる行動と能力が異なります。各段階の概要を以下に示します。
Builder-Driven Developmentの成長段階
| 段階 | 行動 | アウトプットの質 |
|---|---|---|
| Lv1 コードを書かせる | 「この機能を作って」→ 出力をそのまま使う | 動くが品質にばらつき |
| Lv2 レビュー・修正する | 出力をドメイン知識で評価し、修正を加える | 安定した品質 |
| Lv3 Issue設計で制御する | 入力（Issue・コンテキスト・制約）を精密に設計する | 高い生産性と品質の両立 |
| Lv4 型化して組織に展開する | 暗黙知をSkills等で形式知化し、チームに共有する | 組織全体のベースライン向上 |
Lv1：Agentにコードを書かせる
最初の段階です。Agentに「この機能を作って」と指示し、出力をそのまま使う段階です。Agentが動くこと自体に価値を感じる時期で、指示が曖昧なため出力にはばらつきがあります。Agentの出力を評価する力もまだ備わっていません。そのうちバグや設計上の問題に気づき、「動くけど、これで良いのか？」という疑問が芽生えます。そこからLv2に進みます。
Lv2：Agentの出力をレビュー・修正できる
Agentの出力を鵜呑みにせず、自分のドメイン知識で評価・修正できる段階です。「このアーキテクチャでは保守性が低い」「このパターンではなくこちらを使うべき」と具体的に指摘し、技術的な方向性を示してAgentに書き直させる動きができるようになります。
ここで重要な事実があります。自分で書けないコードのレビューはできません。 Agentは生産性を飛躍的に高めますが、判断力の代替にはなりません。ドメイン知識と技術力は、Agentを使いこなすための前提条件です。
Lv2を続けていると、ある時点で「レビューで毎回同じ修正をしている」ことに気づきます。入力の質を上げれば出力の質も上がるはずです。そういう仮説が芽生えると、Lv3が見えてきます。
Lv3：Issue設計でAgentの出力品質を制御する
Agentへの入力（Issue、コンテキスト、制約条件）を精密に設計することで、レビュー工数を最小化する段階です。ここがBuilder-Driven Developmentの核心だと考えています。
やることは、対象をシステムとして捉え、どこに介入すべきかを見極めた上で、Agentが解ける粒度にIssueを分解することです。背景・文脈・達成条件・技術方針を明示した指示を設計し、Agentの出力精度を入力側から制御します。
この段階に到達すると、Agentセッションを効率的に管理できるようになります。Agentが作業中の時間を別タスクのレビューや方針検討に充てるサイクルが回り始め、生産性が非連続的に上がります。ただし高い自己規律も求められます。余剰時間を漫然と過ごすか、別の文脈に能動的に投資するか。この選択が成長の分水嶺になると感じています。
Lv3を続けていると、「このIssue設計パターン、他の人にも使えるんじゃないか？」という発想が出てきます。そこからLv4の世界に入っていきます。
Lv4：型化して組織に展開する
個人の暗黙知をAgent Skills等の形式知に変換し、チーム全体の開発ベースラインを引き上げる段階です。この段階の実践についてはセクション5で詳しく書きます。
ツール進化と段階モデル
この段階モデルは2025年7月からの実践をもとに設計しました。ただ、ツールの進化は急速です。
2026年現在、Agent Teams（複数エージェントを協調させるワークフロー）の成熟により、Lv1〜3で「人間が担う」と書いた作業の一部はエージェント間の連携で代替できるようになっています。
では、Lv1〜3は不要になったのか。自分はそうは思っていません。自動化された出力を評価するには、自動化される前の作業を理解している必要があるからです。変わったのは段階の必要性ではなく、各段階での レバレッジ でした。ツールの進化は段階を不要にするのではなく、各段階での生産性の天井を引き上げます。そう捉えています。
3. 実践：Builder-Driven Developmentの具体的プロセス
Issue設計
9ヶ月やってきて、ここが一番効くと感じています。システム思考で対象の構造を把握し、どこに介入すべきかを見極めた上で、Agentが解ける粒度にIssueを分解します。
良いIssue設計には共通する条件があります。
- 問題の背景と文脈が明記されていること
- 達成条件が具体的に定義されていること
- スコープがAgentが迷走しない程度に絞られていること
- 技術的な方向性（アーキテクチャ判断、使うべきパターン、避けるべきアプローチ）が示されていること
逆に、以下のどれかに該当するとAgentは確実に迷走します。
- 文脈なしの「この機能を作って」
- 達成条件が曖昧
- スコープが広すぎる
- 技術判断をAgentに丸投げしている
具体例：悪いIssueと良いIssue
実際のプロジェクトから例を出します。
悪い例：
「ログイン機能を実装して」
これではAgentが「どの認証方式？」「トークンの保存先は？」「エラー時のUIは？」と迷走し、独自の判断で実装を進めてしまいます。
良い例：
「現在のアプリはセッショントークンをSharedPreferencesに平文保存している。EncryptedSharedPreferencesに移行し、トークンリフレッシュのリトライロジックをRepository層に実装する。MVIパターンに従い、AuthStateにLoading/Success/Errorの3状態を定義すること」
こちらは、現状・方針・技術的制約・達成条件がすべて入っています。Agentは判断に迷わず、具体的な実装に集中できます。
Issue設計の質は、そのままアウトプットの質に直結します。ここに時間を投下するのが、結局は一番速いと感じています。
セッション管理（Session Isolation）
Agentセッションの扱いには、Session Isolation という原則を置いています。「1セッション＝1コンテキスト」です。タスクごとにAgentセッションを分け、コンテキストスイッチのコストをAgent側に押しつけます。各タスクのルールや学びはプロジェクト設定ファイルに蓄積し、Agentの「記憶装置」として機能させます。これでセッションが切れてもプロジェクト固有の知見が引き継がれます。
人間はEMとして、各セッションの優先度判断とレビューに集中します。たとえばある日の午前はこんな具合でした。バグ修正のIssueをAgentに投入し、Agentが調査・実装している間に別の機能開発の前日のPRをレビュー。バグ修正の結果が返ってきたらdiffを確認してフィードバックを返し、次は設計タスクのIssue設計に取りかかります。この間、自分でコードを書く場面はほぼありません。書いているのはIssueとレビューコメントです。
4. Agentの境界線——失敗と限界から見えたもの
100% Agentに書かせると決めた以上、失敗は前提条件です。重要なのは、失敗を素早く検知し、効率的にリカバリーするプロセスを持つことです。テストの自動化、CIの整備、レビューの型化。これらが失敗吸収の基盤になります。
デグレ連鎖——Agentが「木を見て森を見ない」とき
あるプロジェクトで、カードスワイプ時の透明度（alpha値）計算ロジックの修正で、典型的な失敗を経験しました。
まずAgentが「全画面から戻る際のalpha」を修正します。次に別のIssueでAgentが同じalpha変数を上書きし、前の修正がデグレします。そのデグレ修正が、今度は高速スワイプ時の表示崩壊を引き起こします。さらにその修正が、カード透過表示の消失を引き起こします。1つ直すたびに別が壊れる連鎖でした。
Agentは個別のIssueは解けますが、「複数の要件が交差する1つの変数」への影響を俯瞰できませんでした。最終的には、人間が全体の条件分岐を整理し直して収束させました。
この経験から生まれたのが、2-Strike Rule という運用ルールです。Agentが同じ問題で2回失敗したら、そのまま再試行させません。一度止めて、自分に3つの問いを投げかけます。
- Issueの前提情報は十分か？ — 入力の不足がAgentの失敗原因の大半
- スコープが広すぎないか？ — Issueを分割すれば解ける可能性あり
- そもそもAgentが解くべき問題か？ — 人間の判断が不可欠な領域の可能性
名前があるルールは行動を変えます。「また失敗した」ではなく「2-Strikeだ、止めて考えよう」と判断できるようになりました。小さい工夫ですが、効果は大きかったです。
「Agentの限界」に見えた人間側の課題
別のプロジェクトでは、全Issueのうちかなりの割合がアニメーション関連の調整でした。「スワイプの動きが早すぎる」「ふわっとした印象にしたい」といった要件を、自分の解釈だけでIssueに落とし込み、Agentと二人で試行錯誤していた時期は、正直うまくいきませんでした。
突破口は意外なところにありました。デザイナーやディレクターに仕様を言語化してもらう ことです。「イージングはease-in-outで、持続時間は300ms、スワイプ量に対するalpha値の変化は線形」。このように感覚的な要件を具体的なパラメータとして言語化してもらえれば、Agentは正確に実装できました。
つまり問題はAgentの能力不足ではなく、仕様の言語化の欠如 でした。エンジニアが自力で解釈してAgentに投げるのではなく、デザイナーやディレクターから言語化された仕様を引き出し、それをIssueに変換します。この「翻訳」こそが人間の役割だったと、今は考えています。
二つの限界、一つの教訓
100%を目指した実験だからこそ、Agentの限界には二つの種類があると気づけました。ひとつは、デグレ連鎖のように、複数の要件が交差する箇所を俯瞰できないというAgent自体の能力の限界です。もうひとつは、アニメーション事例のように、入力（人間側の仕様言語化やコミュニケーション）が不足していただけというケースです。後者はAgentの限界に見えて、実は人間側の課題でした。どちらの限界に直面しているのかを見極めることが、Builder-Driven Developmentの実践では決定的に大きな判断になります。
失敗から仕組みへ
これらの経験から大事な気づきがありました。Agentは同じミスを繰り返す——人間のチームメンバーなら一度指摘すれば次から気をつけてくれますが、Agentはセッションが切れると前回の失敗を忘れます。そこで、学びをプロジェクトルールとして蓄積するAgent Skillsや、失敗検知を高速化するテストランナーを開発しました。学びの蓄積と失敗検知の高速化。この両輪が、Builder-Driven Developmentにおける失敗吸収の核になっています。そしてこの「学びの蓄積」の取り組みが、次のセクションで書く重要な教訓につながっていきます。
5. 9ヶ月で見えた「投資すべき場所」
9ヶ月の実践を経て、Builder-Driven DevelopmentはLv4（型化して組織に展開する）段階に入りました。ここで学んだ大事なことを共有します。
汎用Skillsはコモディティ化される
実験の初期に、セッション中の失敗・修正・発見をプロジェクトのルールファイルに自動蓄積する「学習トライアド」を開発しました。セッションの学び、PRレビュー指摘、CI失敗パターン。3つの情報源から構造化された形で知見を抽出し、プロジェクトルールに変換する仕組みです。当時は非常に有効に機能していました。
ただ、Claude CodeにビルトインのMemory機能が導入されたことで、「セッション横断で学びを永続化する」という核心部分はプラットフォーム側でカバーされるようになりました。同様に、コードレビュー系のSkillsも、公式のレビュー機能の充実により差別化が難しくなっています。
これは「自作のSkillsが無駄になった」という話ではありません。汎用的な機能はツールベンダーによって必然的にコモディティ化される。それが構造的な学びでした。トライアドを開発したことで「学びの蓄積」という概念の重要性を深く理解でき、その理解があるからこそMemory機能を効果的に活用できています。先行投資は無駄ではなく、次の正しい投資先を見極めるための材料になると捉えています。
投資すべきは「組織固有のコンテキスト」
では、どこに投資すべきか。9ヶ月続けて辿り着いたのは、自分たちの開発組織固有のコンテキストにフォーカスしたワークフローの型化 でした。
具体的には、次のような取り組みをチームで進めています。
仕様管理ツール → Markdown仕様書変換
チーム外から提供される仕様書を、Agentが直接参照できる構造化されたMarkdown仕様書に変換するワークフローです。単なるフォーマット変換ではなく、画面仕様書・機能仕様書・乖離記録といった構造化されたドキュメント体系に落とし込みます。これにより、Agentが仕様を正確に理解した上でコードを書ける環境が整います。
仕様書 → テストケース自動生成
上記で生成した仕様書から、テスト管理ツール互換のテストケースを自動生成するワークフローです。仕様の網羅性チェックとテスト設計が同時に行われるため、仕様の抜け漏れを早期に発見できます。
E2Eテスト自動化オーケストレーター
E2Eテストの設計からテストフロー生成、結果管理までを一気通貫で扱うオーケストレーターです。従来はQAエンジニアが手動で行っていたテストシナリオの設計・実行・結果登録のサイクルを、Agentが仕様書を起点に自動化します。「テストコードを自動生成する」だけのツールではなく、仕様書を起点にテスト戦略そのものを設計し、実行し、結果を管理するワークフロー全体をカバーしている点が肝です。
チームの力
これらのワークフローは、私一人ではなくチームメンバーの協力によって実現しています。仕様書変換やテストケース生成のワークフローは、チームのリーダーが中心となって開発を進めてくれました。Lv4の「型化して組織に展開する」は、一人で完結するものではなく、チームとして推進する段階です。
なぜ「組織固有」が重要なのか
これらのワークフローに共通するのは、「仕様書 → コード → テスト → 結果管理」という、この開発組織の業務フロー全体を貫いている ことです。汎用的なコードレビューSkillsは他のプロジェクトでも使えますが、この業務フローは自分たちの組織でしか成立しません。だからこそコモディティ化されず、投資に対するリターンが持続すると考えています。
6. Agentの出力品質を構造で担保する
Lv3「Issue設計で出力品質を制御する」を、個人のスキルではなく仕組みで実現するアプローチです。
プログレッシブディスクロージャー仕様書
従来の仕様書は、すべての情報を一度に展開する「フラットな構造」でした。これはAgentにとって認知負荷が高く、必要な情報を拾い上げるのが難しくなります。
プログレッシブディスクロージャー仕様書は、情報を段階的に開示する構造 を持ちます。
- 概要レイヤー：この機能は何か、なぜ必要か（1分で読める）
- 設計レイヤー：技術方針、アーキテクチャ判断、制約条件（5分で読める）
- 詳細レイヤー：具体的な実装仕様、エッジケース、テスト条件（必要に応じて参照）
Agentは概要レイヤーで文脈を掴み、設計レイヤーで方針を理解し、必要に応じて詳細レイヤーを参照します。人間がコードレビューするときと同じ認知プロセスです。Agentも人間も、「まず全体像を掴み、必要に応じて深掘りする」という認知の流れは共通していると感じています。
事前タスクリスト管理開発
プログレッシブディスクロージャー仕様書と組み合わせて、開発着手前にタスクリストを完成させる 運用を行っています。
- 仕様書を段階的に記述する
- 仕様書からタスクを分解し、タスクリストに登録する
- 各タスクに「背景・達成条件・技術方針」を紐づける
- タスクリストの完成をもって開発に着手する
この運用により、Agentがタスクに着手する時点で「何をやるか」の判断コストがゼロになります。Agentは純粋に実装とレビューに集中でき、人間はEMとしてタスクの優先度判断と進捗管理に集中できます。
これはLv3「Issue設計の質＝出力の質」の組織的な実装です。個人のIssue設計スキルに依存するのではなく、仕様書のフォーマットとワークフローで品質を担保する 仕組みになっています。
7. 結論：「何を解くべきか」を問い続ける
実験の成果
9ヶ月間の「100% Agentに書かせる」実験で、具体的に何が起きたかを整理します。
Issue設計・Session Isolation・2-Strike Ruleの3つのプラクティスが再現可能な方法論として機能し、Agentの出力品質と人間の生産性を同時に担保する構造を作れたこと。さらに、個人の実践から始まったAgent Skillsの型化が、チームメンバーの協力により、仕様書からテストまでを貫く開発パイプラインへと進化したこと。この2点が大きな成果でした。
ただし、これはドメイン知識とレビュー力を持つ人間がいて初めて成り立ちます。Agentへの丸投げでは再現しません。Builder-Driven Developmentは、人間の能力を前提とした上でそのレバレッジを最大化するフレームワークです。
この実験を通じて見えたこと
これらの実践を通じて見えたのは、Agentの能力でも限界でもなく、自分自身の仕事の本質 でした。コードを書かなくなったことで、「問題を構造化する」「適切に委任する」「アウトプットを評価する」「仕様を言語化する」。これらが自分の価値のすべてだと気づきました。そしてこれらは、優れたエンジニア、優れたマネージャーに共通して求められる能力でもあります。
Builder-Driven Developmentは今すぐ誰にでもできるものではありません。ドメイン知識、構造的思考力、自己規律。どれも一朝一夕には身につきません。だからこそ段階的なアプローチが効きます。まずLv1から始め、失敗し、学び、仕組み化する。そのサイクルを回すこと自体が、Builder-Driven Developmentの実践です。
Agentの能力は急速に進化しています。今日「人間が判断」と書いた領域も、半年後にはAgentに委譲できるようになっているかもしれません。ただ、それでも最後まで残る問いがあります。「何を解くべきか」——この問いに答える力は、経験と実践の中でしか養えないと感じています。
9ヶ月前の自分は、この実験の終着点をまったく想像できていませんでした。だから今、「最初は半信半疑でも、まずやってみる価値はある」とだけ書いておきたいと思います。
本記事は、2025年7月のBuilder-Driven Development実践開始から約9ヶ月間の経験と考察をもとに体系化したものです。今後の実践を通じて継続的にアップデートしていきます。
本記事の評価は筆者の経験と観測に基づくものです。技術選択はプロジェクトや組織により大きく異なります。
参考文献
システム思考・問題設計
- ドネラ・メドウズ『世界はシステムで動く ─ いま起きていることの本質をつかむ考え方』—— Issue設計セクションで述べた「システム思考で対象の構造を把握する」アプローチの理論的基盤
- 安宅和人『イシューからはじめよ ─ 知的生産の「シンプルな本質」』—— 「何を解くべきか」という本記事の結論に通底する問い
- 馬田隆明『解像度を上げる ─ 曖昧な思考を明晰にする「深さ・広さ・構造・時間」の4視点と行動法』—— Issue設計における粒度と構造化の考え方に影響
- Will Larson『An Elegant Puzzle: Systems of Engineering Management』—— 「EMメタファー」の着想源
AI・Agent活用
- Boris Cherny, "Will Claude Destroy Software Engineer Coding Jobs?"（Fortune, 2026年2月）—— 「ソフトウェアエンジニアという肩書きはbuilderに置き換わるだろう」
- Boris Cherny「How I Use Claude Code」（Xスレッド）—— Claude Code開発責任者による実践ワークフローの公開
- Thorsten Ball「Joy & Curiosity #68」（Register Spill, 2026年1月）—— 15年以上手でコードを書いてきたエンジニアがAI Agentを経験し「自分の前提を問い直した」経験談
