💥予測が現実に──エージェントエンジニアリングを実際にやった人が現れた
毎度rorosukeです。
少し前に、こんな記事を書きました。
どんな内容かというと、「今話題のバイブコーディングの先に、エージェントエンジニアリングってのが来るらしいよ」という内容です。
これが実現されれば、たとえば10万行もあるような大規模なプログラムも、全部AIが自動的に作ってくれるというのですから、マジか！ って感じです。
とは言ったものの、
「でもまあ、そのうちでしょ？」
とも思っていたのですが、なな、なんと、
もう来ました！
しかも「NOTE」内で、今まさにバズり中です！
🤖実証した人が現れた
それが、チームみらいの伊藤（エディ）氏の次の記事です。
どんな内容かというと、「人間がほとんど指示しなくても、AIが勝手に開発を進め続ける仕組みを作った」という報告です。具体的にはこう書かれています。
「3〜4時間のロングセッションで、数千〜1万行程度の、比較的品質の高い実装が安定して完成する」
これはつまり「ClaudeCodeでとある手法（本記事では「伊藤メソッド」と呼称）を確立したんだけど、やってみたら数千〜1万行程度の品質の高いコードを、安定的に作ることができたよ。3〜4時間かけるけどね」という意味になります。
ここで私ピンときました。
「これってエージェントエンジニアリングの実証実験じゃん！」
えっ、えっ、すごい！ すごすぎる！
でも、ちょっと待てよ・・・
ただ、この報告に、少しひっかかる部分がありました。
「AIを3〜4時間も動かして1万行程度のコードしか作れないの？ 時間かかりすぎじゃない？」
私の経験ではClaudeで2千行のコードを作っても、数分しかかからないからです。しかし、これはおそらく、コードを書く時間よりテスト実行・マージ・検証のループの待ち時間の方が長いからなのだと思います。つまり「ちゃんと動くものを確認しながら作る」ことへのコストが大半を占めている、ってこと・・。
記事の内容を読むまで、「それ、ほんまかいな」と少し思いました。ただ、仕組みを読み解いてみると、上記のような疑問も「なるほど」と納得するものがあります。時間がかかるのも理にかなったことをやっている証拠に見えてきました。やっぱ、すごいことが起きているんじゃないの！
🤖何をやったのか、かみ砕いて説明する
ここからは実際の記事内容を、できるだけ平易に解説してみたいと思います。というのは、この方のスキルが高すぎて簡単に理解できないからです。そこで、私レベルでもわかるようにかみ砕いて説明してみたいと思います。いわゆる「中学生レベルでもわかるようにして」です。
なお、本記事の最後に、用語辞典を追加しておきましたので、元記事を読むときの参考にでもしてもらえればと思います。
バイブコーディングの弱点のおさらい
私の前回記事でも指摘しているのですが、バイブコーディングには次の2つの大きな弱点があります。
ブラックボックス問題 1つ目はブラックボックス問題です。AIが生成したコードは動いてはいる。でも「なぜこの構造なのか」「どこを変えると何が壊れるか」が人間側に見えにくい。企業が本格導入をためらう最大の理由です。
スケールの壁問題 2つ目はスケールの壁です。2,000行程度なら問題なく作れますが、10万行規模になるとAIのコンテキスト限界でシステム全体の整合性が保てなくなる。部分的には動くコードが生成できても、全体として一貫したシステムにならない。
以上を踏まえて、伊藤メソッドがどうこの問題を解決しようとしているのかを説明していきます。
コンテキスト問題をどう解決したか
AIには「一度に覚えられる量」に限界があります。これをコンテキストといいます。すっごい昔のことは忘れてしまう、というやつです。
Claudeはコンテキストが大きいほうなので、2,000行程度のプログラムなら一気に作れます。しかし1〜10万行のプログラムになると、前半で決めたルールを後半で忘れ始め、どんどん整合性が崩れてくることになります。これが「スケールの壁」の正体です。
伊藤メソッドの解決策はシンプルです。
「1セッションに詰め込みすぎなければいい」
プログラムを機能単位に分割し、それぞれを「新鮮な状態のAI」に別々に作らせる。そして出来上がったものを順次合体（マージ）させていく。
工場のライン作業に近いイメージです。
分割はどうやるか
ポイントは「行数で分割するわけではない」ということです。
分割の単位は機能です。ログイン機能、検索機能、データ保存機能……といった単位で1タスクになります。そしてこのタスクの中身は、関数・モジュール・クラスといったソフトウェア設計の自然な単位になります。つまり、分割といっても行数で分割するのではなく、あくまでもプログラムのブロック単位での分割となります。
実際のところ、タスクは3つの階層で管理しているそうです。
マイルストーン（大）：「ログイン機能が動く」レベル
ウェーブ（中）：依存関係の順序
タスク（小）：1つのAIセッションが担う作業
10万行クラスになれば、この分割も、ものすごく多層的になります。ブロック→モジュール→関数、という入れ子構造のオンパレードですね。
3つのエージェントが分業する
伊藤メソッドのもう一つの特徴が、AIを3役に分けていることです。
Planner（設計担当）：仕様書を書き、タスクに分解する
Builder（実装担当）：個別のタスクを実際に実装する（複数が同時並列で動く）
Verifier（検証担当）：できたものをつなぎ合わせ、動作確認する
なぜ分けるのか？ それは1つのAIに「設計も実装も検証もやれ」と言うと、複数の目的を持たせてしまうことで、質が下がってしまうからです。そこで、役割を設けて分担することで質の低下を防いでいるわけです。
以上をまとめると「うまく回っている会社みたいにしたよ」ってことですね。上層部がちゃんと全体設計をして、中間管理職が間に入って、現場がしっかり作業するって感じです。
肝は「10個のファイル」
これで全体的なしくみは、うっすらとわかりましたが、じゃあ実際どうやってんの？ って話になります。
それがなんと、この仕組み全体を動かしているのが、「たった10個のファイル」なんだそうです。
しかも、プログラム（コード）は1ファイルだけ。残り9つは全部、人間が書いた「指示書」や「規約集」ということです。
私の記事でも書いたのですが、「エージェントエンジニアリング」という言葉の本質は、コードを書く技術ではなく、「AIに仕事をさせる構造を設計する技術」という記述と完璧にシンクロします。ますます、AIに仕事をさせる構造を設計するのが人間の役割ってことを実感するばかりです。
いずれにしても、伊藤メソッドが実際に機能し、コードが作成できた……実証できちゃった、ということで「エージェントエンジニアリング」が予測の段階から、完全に現実への段階へと移行したとみていいでしょう。
「スピードが速くて、気持ちが追い付かない？」
そりゃもう、私も同感です！
🤖この手法が特に輝く場面──複数プログラムの連携
ここからは、私の話になります。
個人的に伊藤メソッドが使えそうと思ったのが、複数の独立したプログラムを連携させて作るケースです。
たとえばネットワークプログラムでは、送信側・受信側・サーバー側と、最低でも3つのプログラムを同時に作る必要があります。それぞれが小さくても、互いに整合性が取れていないと動きません。これを一人でやるのは、それなりに大変です（というか頭が混乱の極みです）。
また、Google AI Studioで作るようなアプリでも、HTML・JavaScript・サーバー側の処理など、複数のファイルが絡み合っているので、これを一人で作るのは全部の知識も必要ですし「あーめんどくさい」って思います（だからGoogle AI Studioは画期的なんですが……）。
しかし、伊藤メソッドを使えば、それぞれを別のBuilderエージェントが同時並列で担当します。連携仕様を設計書に書いておけば、各エージェントがインターフェースを守りながら独立して実装を進め、最後にVerifierがつなぎ合わせてくれることになります。これは、いろんな会社を束ねて、もの作りをするようなものですね。
私個人が数万行のコードを作る必要に迫られることは、まずありませんが、上記のような複数のプログラムで成立しているネットワークプログラムやWebアプリが一人で、しかもAIが設計からデバッグまで行ってくれるとしたら、これほど歓迎したいことはありません。
🤔疑問も正直に書く
なんか、もうパラダイスって感じになってきていますが、ここでいったん気持ちを静めましょう。「すごい！これで何でもできる！」と受け止めてしまうのは、いつでも危険なものです。
条件付きの話である
伊藤氏自身がはっきり書いておられるのですが、実証に用いたのは、TypeScript + Next.js（ネット上に実例が豊富で、AIが得意とする技術）を使用していて、バグが致命的にならないタイプのプロダクトで、かつ1人開発という条件が揃ったという前提の上でのことです。最善のものを用意したし、不足しているものがないっていうことです。
「完璧な設計書」はできない
AIが作る設計書は、必ずしも完璧ではありません。曖昧な部分や矛盾が生じることもあります。最終的な判断や責任は人間に残ります。なんの知識も経験もない人が、「10万行のコードを作って」といっても、うまくいくはずがありません。
部分修正の問題
仮に10万行のプログラムコードができたとしましょう。しかし、コードは完成後もアップデートされるものです。そのとき、「ここを直したいんだけど」となったとき、AIが作ったコードは構造の意図が見えにくいですし、修正が別の場所に影響する場合もあります。このアップデートやメンテナンスをどうするかという問題は、まだ残ります。
つまり、企業の仕事レベルで用いることができるようになるためには、解決しなければならない問題がいっぱいあるってことですね。
まとめ：最初の突破口はできたけど本当に気になるのは……
いかがでしょうか？ 自分でもやってみたい、切実にそう思います。
しかし、ここで私が一番気がかりなのは何か？
それはコストです。
3〜4時間・複数エージェント並列で回すって、それいくらかかるのよ！
AIに試算してもらいました。
💻の回答
元記事にコストの具体的な記載はありませんでした。なので以下は推計です。3〜4時間・複数エージェント並列で回すと、おそらく総トークン数は500万〜2,000万トークン程度と推測されます。
概算で3,000円〜15,000円前後ではないかと思います。
モデルがOpusなら5倍以上になります。並列数・ウェーブ数によって大きく変わります。あくまで推計であり、実際は著者本人しか知りません。
ですよねー。そしてAIはこうも答えています。
💻の回答（続き）
1万行のプログラムが3〜4時間・1万円以内で完成するなら、フリーランスエンジニアに頼む場合と比べると桁が2つくらい違います。コスパとしては相当破格だと思います。
ごもっとも。
そんなわけで、ともかく波は「ざっぶーん」と来ています。
乗れるかどうかはあなた次第！
ですね。
以上！
PS：内容の精査が足りてない部分があったらすみません。
✨ついに私もやってみました
理屈はわかった。
でも、実際どうなんだろう。
そう思ったので、触ってみました。
📖用語辞典
「用語が難しくて」とお嘆きの方のために用意したうれしい用語辞典です。
【ツール・サービス名】
Claude Code AnthropicのAI「Claude」をプログラミング専用に特化させたツール。ターミナル（コマンド画面）から操作し、コードの生成・修正・テストまでを自律的に行える。
ralph-loop AIコーディングエージェントを無限ループで自律的に動かすパターンの名称。発見・命名したGeoffrey Huntley氏の愛犬の名前に由来するとされる。
Git / Gitワークツリー（worktree） Gitはプログラムのバージョン管理ツール。「いつ・誰が・何を変えたか」を記録する。ワークツリーは「複数の作業スペースを同時に開ける」機能で、複数のAIが別々の場所で同時に作業するために使われる。
TypeScript / Next.js TypeScriptはJavaScript（Webサイトを動かすプログラム言語）を使いやすく改良したもの。Next.jsはWebアプリを作るためのフレームワーク（土台となる道具セット）。どちらもAIが得意とする技術スタックとして知られる。
E2Eテスト 「End to End（端から端まで）テスト」の略。実際にブラウザを操作して「ボタンを押したら正しく動くか」を自動確認するテストのこと。
【概念・手法】
コンテキスト（文脈制限） AIが「一度に覚えられる量」の上限のこと。人間でいうと作業台の広さに相当する。作業台が狭いと、前の資料を脇に置かないと新しい資料が広げられない。AIも同様で、長い会話や大量のコードを扱うと、前半の内容を「忘れ始める」。
バイブコーディング 「ノリ（Vibe）でコードを書く」という意味で、AIにざっくり指示してコードを生成させる手法。AIが普及し始めた頃に流行した言葉で、OpenAIの研究者アンドレイ・カーパシー氏が命名した。
エージェントエンジニアリング AIを「指示を受けて動くだけ」ではなく「自律的に判断して動く」エージェント（代理人）として扱い、その動き方を設計・管理する手法。バイブコーディングの次の段階とされる。
ループ処理 / 無限ループ 同じ処理を繰り返し実行すること。この記事では「タスクが全部終わるまでAIを何度も起動し続ける」仕組みを指す。通常、無限ループはプログラムのバグとして嫌われるが、ここでは意図的に使っている。
マージ（統合・合体） 別々に作ったプログラムを1つに合体させること。複数人が分担して作ったコードを最終的に1本にまとめる作業。
ブランチ（作業スペース） Gitの機能で、本体のコードを壊さずに「別の場所で試作する」ための分岐。木の枝（branch）に例えられる。試作がうまくいったら本体にマージする。
並列実行 複数の処理を同時に走らせること。この記事では複数のBuilderエージェントが同時に別々の機能を実装することを指す。順番にやるより大幅に時間が短縮できる。
モック / スタブ（ごまかし実装） 本来つなぐべきデータベースや外部サービスの代わりに、「とりあえず決まった値を返すだけ」の仮の部品を使うこと。テストを通すためのごまかし手段として使われることがある。実際にDBを繋ぐと動かないケースが多い。
【設計・開発用語】
アーキテクチャ プログラム全体の「設計思想・構造」のこと。建物の設計図に例えられる。どのように機能を分けるか、データはどう流れるかを定めたもの。
DDD（ドメイン駆動設計） 「ビジネスの世界（ドメイン）をそのままプログラムの構造に反映させよう」という設計手法。たとえば「注文」「顧客」「在庫」といったビジネス上の概念をそのままプログラムの部品にする考え方。
レイヤードアーキテクチャ プログラムを「層（レイヤー）」に分けて設計する手法。画面の処理・ビジネスロジック・データ保存、といった役割ごとに層を分け、互いに干渉しすぎないようにする。
ユニットテスト プログラムの「小さな部品ひとつひとつ」が正しく動くかを確認するテスト。全体をまとめてテストするのではなく、関数1つ・クラス1つといった単位で行う。
lint / typecheck lintはコードの「書き方の乱れ」を自動検出するツール。typecheckは「型（データの種類）の使い方が正しいか」を確認するツール。どちらもバグを未然に防ぐための自動チェック機能。
オーケストレーション オーケストラの指揮者のように、複数のエージェント（AI）や処理を統括・調整すること。誰に何をいつやらせるか、を管理する役割を指す。
ハーネスエンジニアリング テストや検証の仕組み（ハーネス＝馬具・装具）を丁寧に整備すること。AIが間違った実装をしたときに自動的に検知できる仕組みを作ることで、品質を安定させる。
SDD（仕様駆動開発） 「仕様書（Spec）を先に書いてから開発する」手法。コードを書く前に「何を作るか」を文書化しておき、それに沿って実装を進める。AIに対して「これを守って実装せよ」と指示できる。
