「『エージェント・ソフトウェア・エンジニアリング』は、私が従来のソフトウェア・エンジニアリングからエージェント・ソフトウェア・エンジニアリングへと移行する過程を記録する一連の記事となるでしょう」
ベテランプログラマーの気付き
私は約 20 年もの間コードを書いてきました。工程の見積もりについては、もはや筋肉が記憶しているレベルです。タスクを分解し、優先順位を付け、経験係数を掛け、結合テストやバッファ（冗長分）を加味し、最後に「2〜3 週間」と結論付ける。この方法論は、ウォーターフォール、アジャイル、DevOps と、あらゆるパラダイムシフトに伴走し、一度として機能しなかったことはありません。
しかし、AI プログラミングが到来するまでは。
最近、私は AI エージェントを使って CLI ツールを作成しました。頭をよぎった最初の考えは、その実装プロセスでした。パラメータの解析、中核となる変換処理、検証ロジック、エラーハンドリング、テスト。一連の工程を従来の手法でこなせば、最低でも 2〜3 日はかかるでしょう。ところが、エージェントが着手してから納品するまでにかかった時間は、なんと 30 分もかかりませんでした。
効率は向上したのか？表面上は、もちろんその通りです。
しかし、より深い問題が浮かび上がってきました。私は AI にどれくらいの時間がかかるかを、正しく予測することさえできなくなっていたのです。
私の見積もりの枠組み全体が、「人間の開発者」という基盤にアンカー（係留）されていました。何行のコードか、何回のデバッグか、何回のコードレビューか。実行者が人間からエージェントに変わった瞬間、この物差しは完全に役に立たなくなったのです。
さらに皮肉なことに、AI エージェント自身も同じ過ちを犯します。Claude や GPT に「この機能にはどれくらい時間がかかる？」と尋ねると、真顔で「およそ 2〜3 日です」と答えるでしょう。なぜなら、その訓練データには Stack Overflow や技術ブログにそう書かれているからです。エージェントは人間の経験則を使って人間の時間を予測し、そして自分自身は 10 分で終わらせてしまうのです。
私は気づき始めました。ソフトウェア・エンジニアリングがエージェント・ソフトウェア・エンジニアリング（Agentic Software Engineering）へと移行する中で、最初に変えなければならないのは、この「人間の物差しで AI の仕事を測る」というメンタリティだと。
そこで私は、この問題に特化したスキル「agent-estimation[1]」を作成しました。
問題の根源：人間時間へのアンカリング
私はこの現象をHuman-Time Anchoring（人間時間アンカリング）と呼んでいます。
その仕組みは以下の通りです。
AI エージェントは見積もりを生成する際、無意識のうちに訓練データにある「集合知」を呼び出します。REST API プロジェクトなら？フォーラムでは「1 週間」と言われている。リアルタイムチャート付きのフルスタックダッシュボードは？スプリントプランニングで技術リーダーが「3 イテレーション」と見積もった。これらの数字は、人間の認知帯域幅、コンテキストスイッチングのコスト、コミュニケーションの摩擦という条件下で導き出された人間のための経験値です。これらは人間には通用しても、3 分ごとに「思考→コーディング→実行→検証→修正」というサイクルを 1 回完結できるエージェントには全く適用できません。
これにより、ある体系的なバイアスが生まれます。AI はほぼ常に、自らの工期を実際よりも長く見積もりすぎてしまうのです。
そして私たちベテランプログラマーもまた、逆の方向で同じ過ちを犯しています。過去の経験則を元に AI のアウトプット速度を予測しては、「えっ、そんなに早いの？」「いや待て、本当にできるのか？」とその間で右往左往しているのです。
問題の本質は AI のコーディングが速いかどうかではありません。問題は、AI が実際にどれほど速く、どこにボトルネックがあるのかを測定するための「AI ネイティブな測定体系」を、私たちがまだ持っていないということです。
解決策：エージェント独自の単位で思考させる
私が設計したこのスキル（Agent Work Estimation Skill）の中核にある考え方は、たった一文に集約されます。
まずは「ラウンド（Round）」で見積もり、最後にのみ人間の時間に変換する。
ここでの「ラウンド」とは、エージェントの原子的操作単位のことであり、1 回の完全なツール呼び出しサイクルを指します。思考 → コード作成 → 実行 → 出力確認 → 修正の要否判断
1 ラウンドあたり約 2〜4 分です。これは感覚で決めた数字ではなく、実際のプロジェクトにおける AI コーディングエージェントの稼働リズムを観察して導き出した経験則です。
これを基に、4 段階の見積もり単位を定義しました。
| 単位 | 定義 | 規模 |
|---|---|---|
| ラウンド（Round） | 1 回のツール呼び出しサイクル | 約 2〜4 分 |
| モジュール（Module） | 複数のラウンドで構成される機能単位 | 2〜15 ラウンド |
| ウェーブ（Wave） | 相互依存のないモジュールのバッチ。並列処理可能。 | 1〜N 個のモジュール |
| プロジェクト（Project） | 全ウェーブの順次実行＋統合＋デバッグ | ウェーブの合計 |
単一エージェントによる順次コーディングには「ラウンド」を、複数エージェントによる並列コーディングには「ウェーブ」を用います。これこそがAI ネイティブな見積もり手法です。
5 ステップ見積もり法
ステップ 1：モジュールへの分解
タスクを、独立して構築・テスト可能な機能モジュールに分割します。核心となる問いはこうです。「もし私が一度に 1 つのことしかできないとしたら、どの順序で作業を進めるか？」
ステップ 2：各モジュールのラウンド数を見積もる
ここでの校正アンカー（基準点）は以下の通りです。
| パターン | 典型的なラウンド数 | 例 |
|---|---|---|
| テンプレート化済み / 既知のパターン | 1〜2 | CRUD エンドポイント、設定ファイル |
| 中程度の複雑さ | 3〜5 | カスタム UI、状態管理 |
| 探索的 / ドキュメント不足 | 5〜10 | 未知のフレームワーク、プラットフォーム固有 API |
| 不確実性が極めて高い | 8〜15 | ドキュメント化されていない挙動、新規アルゴリズム |
直感的な校正ルールがあります。エージェントが一度の生成で動作すれば 1 ラウンド、生成してエラーが出て修正が必要なら 2〜3 ラウンド、ライブラリのドキュメントが酷く推測に頼るしかない場合は 5 ラウンドから、といった具合です。
ステップ 3：リスク係数を加味する
| リスクレベル | 係数 | 使用ケース |
|---|---|---|
| 低 | 1.0 | 成熟したエコシステム、明確なドキュメント |
| 中 | 1.3 | わずかな未知要素、追加で 1〜2 ラウンドのデバッグが発生する可能性 |
| 高 | 1.5 | ドキュメントが希少、プラットフォーム固有の癖 |
| 極めて高い | 2.0 | 壁にぶつかる可能性、アプローチの変更が必要になるケース |
ステップ 4：総量の計算
順次モード：
モジュール有効ラウンド数 = 基本ラウンド数 × リスク係数
プロジェクト総ラウンド数 = Σ(モジュール有効ラウンド数) + 統合用ラウンド数（基本総量の 10〜20%）
ウェーブモード（複数エージェントによる並列処理）：
ウェーブ所要時間 = ウェーブ内におけるモジュール最大の有効ラウンド数
プロジェクト総ラウンド数 = Σ(ウェーブ所要時間) + 調整用ラウンド数 + 統合用ラウンド数
ステップ 5：最後にのみ人間の時間に変換する
人間の時間 = プロジェクト総ラウンド数 × 1 ラウンドあたりの分数
デフォルトでは 1 ラウンド 3 分とします。ただし、このパラメータは調整可能です。高速イテレーションなら 2 分、ユーザーによる手動テストが必要なシナリオなら 5 分とするといった具合です。
重要なのは、人間の時間は「出力」であり、「入力」ではないという点です。推論の連鎖の中に「開発者一人あたりだいたい〜」といった表現は一切登場しません。
実践による校正：3 つのスケールでの比較
小規模プロジェクト例：CLI 版 JSON-to-YAML 変換ツール（約 8 ラウンド）
| モジュール | 基本ラウンド数 | リスク | 有効ラウンド数 |
|---|---|---|---|
| 引数解析 + 入出力 | 1 | 1.0 | 1 |
| JSON→YAML 中核処理 | 1 | 1.0 | 1 |
| スキーマ検証 | 3 | 1.3 | 4 |
| エラーハンドリング + UX | 2 | 1.0 | 2 |
合計 8 ラウンド、約 24 分です。人間の経験則で見積もれば「1 日」、ひどければ「2 日」と言うところでしょう。
中規模プロジェクト例：デスクトップキーボードブロードキャスター（約 36 ラウンド）
Mac のキーボードで 27 台のデバイスを制御するプロジェクトです。HTTP/WebSocket サーバー、Makepad UI、macOS CGEvent によるキーキャプチャ、QR コード生成などのモジュールを含みます。
順次実行で約 108 分（1.5〜2 時間）。もし 3 つのエージェントで並列処理するウェーブモードなら：
- ウェーブ 1：HTTP サーバー、QR コード、スマホ側（依存関係なし・並列可能）→ 3 ラウンド
- ウェーブ 2：メイン UI、クライアント管理、分類フィルタリング → 10 ラウンド
- ウェーブ 3：キーキャプチャ → 8 ラウンド
- 統合 → 5 ラウンド
- 調整オーバーヘッド → 3 ラウンド
並列処理時間は約 57 分。順次処理より 47% の短縮です。人間の経験則ならどうでしょう？おそらく「2〜3 週間」と見積もるはずです。
大規模プロジェクト例：フルスタック・リアルタイムダッシュボード（約 63 ラウンド）
React フロントエンド＋Rust バックエンド＋WebSocket ストリーミング＋グラフコンポーネント＋認証機能。
順次実行で約 189 分（3〜3.5 時間）。3 エージェントの並列処理で約 108 分。
人間なら？「3 ヶ月」と見積もっても誇張ではないでしょう。
回避すべき 6 つのアンチパターン
これらこそが、このスキルが存在する根本的な理由です。いずれも私が実践の中で直面した落とし穴です。
1. 人間時間アンカリング。「開発者 1 人あたり 2 週間くらいか」。違います。ラウンドから逆算して導き出してください。
2. 感覚でのバッファ追加。「念のため余裕を持っておこう」。違います。リスク係数を用い、1 分の膨らみにも必ず理由を持たせてください。
3. 複雑さとコード量の混同。500 行のテンプレートコードが難しいわけではありません。1 行の macOS CGEvent API 呼び出しが簡単だとも限りません。行数ではなく、不確実性に基づいて見積もってください。
4. 統合コストの忘却。個々のモジュールは動作しても、組み合わせると破綻します。必ず統合用ラウンドを追加してください。
5. ユーザー側ボトルネックの無視。ユーザーによる手動承認やアプリの再起動、実機テストが必要な場合、ラウンド数を水増しするのではなく、1 ラウンドあたりの分数を調整してください。
6. 並列処理は無料という前提。複数エージェントの連携には調整コストがかかります。契約の定義や競合の解決には追加のラウンドが必要です。
単なる見積もり手法を超えて：思考パラダイムの転換
このスキルを作成する過程で、私はこれが単なる技術的な問題ではないと強く感じるようになりました。
私たちは過渡期にいます。「人がコードを書き、人がデバッグし、人がコミュニケーションをとり、人が意思決定する」というソフトウェア・エンジニアリングの基本前提が、エージェントによって再定義されようとしています。しかし、私たちの思考の慣性は依然として旧パラダイムに留まっています。ストーリーポイントでエージェントの作業量を見積もり、スプリントでイテレーションを計画し、「人日」で成果を測る。これは馬車の速度で列車の時刻表を組もうとするようなものです。
AI コーディングによる効率向上は、単に「同じことをより速く行う」というだけではありません。それは作業の粒度そのものを変えました。人間開発者の原子的操作が「1 日のコーディング」だとすれば、エージェントのそれは「1 回のツール呼び出し」です。原子のスケールが変わった以上、その旧原子の上に成り立っていた測定体系はすべて再構築される必要があります。
同時に、もう一方の極端、つまり「AI なら何でも一瞬で片付ける」という盲目的な楽観論に陥ることもできません。macOS の権限 API の不可解な挙動、ドキュメント化されていないフレームワークの境界、システム横断的な統合に潜む暗黙の依存関係。これらの不確実性は、実行者が AI に変わったからといって消え去るわけではありません。リスク係数という概念は、まさにこの現実を尊重するために存在します。
結びに
このスキルはオープンソースであり、Agent Skills 開放標準に準拠しています。Claude Code、Cursor、Codex CLI といった主要なエージェントで利用可能です。インストールは以下で即座に行えます。npx skills add ZhangHanDong/agent-estimation
しかし、スキルをインストールすること以上に重要なのは、エージェントの視点で問題を捉える練習を始めることです。
次に「この機能はだいたい 3 日か」と口にしそうになった時、一度立ち止まってみてください。そして自問するのです。「エージェントがこれを完了させるのに何ラウンドかかるか？各ラウンドの不確実性はどの程度か？並列化可能なモジュールはどれか？」
そう考え始めた時、あなたはすでにエージェント・ソフトウェア・エンジニアリングの扉をくぐっています。
これは AI が人間を代替する物語ではありません。人間が新しい物差しで新世界を測る術を学ぶ物語なのです。
参考資料
[1] agent-estimation: https://github.com/ZhangHanDong/agent-estimation