AIエージェントの限界を突破するProactionの事例。人間がAIを制御するワークフロー

AIエージェントの性能競争が加熱している。ベンチマークの数字だけを見て「万能」を期待する声がある。しかし、現実の業務でAIを動かすと、肝心なところで止まる。成果物が未完成のまま放置される。

実案件をAIに完遂させるベンチマークでは、最高性能モデルでも成功率は4%以下という数字が出ている。一方で、ProactionはAIを活用して営業効率を60%向上させた。エンジニアの工数を削減した。

なぜ差が生まれるのか。AIを「全自動化ツール」としてではなく、人間が介入可能な「デモ生成エンジン」として再定義したからだ。この記事では、AIエージェントの限界を突破し、実務で成果を出すための「人間とAIのワークフロー設計」を解説する。

AIを「全自動化」の夢から解き放ったProactionの戦略

フリート管理ソフトウェアを提供するProactionの事例を見る。彼らは、エンジニアの手を借りずに顧客ごとのカスタマイズされたデモ環境を構築する仕組みをAIで実現した。

これまで、顧客ごとに最適化されたデモを作成するには、エンジニアが工数を割く必要があった。ProactionのCOOであるコリン・クヌーセン氏は、以前はデモ作成のたびにエンジニアを巻き込んでいた。現在はAIを活用し、30分から45分でインタラクティブなデモ環境を構築している。

この運用により、同社は月に40時間から60時間のエンジニア工数を削減した。営業成績へのインパクトも大きい。顧客自身の車両データやワークフローを反映したデモを見せることで、初期接触から解決策の検討フェーズへ進む商談の割合が50%から60%増加した。

しんたろー：
営業担当がエンジニアを介さず、AIでデモ環境を即座に組めるのは強力だ。ThreadPostもそうだが、エンジニアがボトルネックにならない状態を作ることが、SaaS開発の勝敗を分ける。AIがコードを完璧に書くことより、実戦的なアプローチだ。

この事例は、AIに「完成品」を求めず、「人間が介入して完成させるための土台」を作らせている。営業担当が顧客との通話録音やメール、スプレッドシートをAIに入力し、顧客の車両や業務フローに合わせたHTMLベースのデモ環境を生成させる。

この環境を画面共有しながら顧客と一緒に調整を行う。エンジニアなしで最終的なソリューションを形にしている。AIを「自律的にタスクを完遂するエージェント」としてではなく、非エンジニアとエンジニア間のコミュニケーションを円滑にする「プロトタイピング・エンジン」として活用している。

AIエージェントの性能評価については、厳しい現実がある。最新のベンチマーク調査によれば、フリーランス案件をAIに丸投げするエンドツーエンドのテストにおいて、トップクラスのモデルであっても、人間が納品物として受け入れられるプロジェクト完遂率は4%以下にとどまる。

GDPvalやAPEXといった評価指標で「専門家と同等」というスコアを出しているモデルであっても、長時間かつ複雑な実業務では、品質の低さやファイルエラー、網羅性の欠如がボトルネックとなる。Proactionの事例は、AI単体での完遂能力に賭けるのではなく、AIの生成物を人間が制御・修正しやすいワークフローに組み込む合理性を示している。AIは「加速装置」として扱う。この前提が実務でのROIを左右する。

あわせて読みたいAIエージェントを自作して本番運用する方法｜最小構成の実装とサブエージェント設計 →

ベンチマークと実務の乖離を理解する

AIモデルの性能評価は、指標により景色が変わる。GDPvalやAPEXのように、専門家が設定したルーブリックに基づき、特定のタスクを測る指標では、最新モデルは60%から70%近いスコアを記録する。AIが「専門的な仕事の土台」を構築する能力は、人間と遜色ないレベルにある。

一方で、RLI（Remote Labor Index）のような、実際のフリーランス案件をエンドツーエンドで完遂させる評価では、完遂率は4%以下という数字が突きつけられている。重要なのは、AIの能力を嘆くことではなく、なぜ評価が乖離するのかという構造だ。

GDPval等の指標は「単発の成果物」の良し悪しを評価する。対して、実務案件は「複数のステップ」が連鎖し、途中でファイルエラーが発生したり、要件の網羅性が求められたりする。AIは「一点突破」の出力は得意だが、数時間にわたるプロジェクトの「整合性維持」には弱い。この現実を無視して、AIに最初から最後まで全てを丸投げしようとするから、開発者は疲弊する。

Proactionの事例は、この「AIの限界」を逆手に取ったワークフローの設計だ。彼らはAIを「自律エージェント」として扱うのをやめ、非エンジニアがAIを使って「エンジニアが着手可能な中間生成物」を作るためのプロトタイピング・エンジンとして位置づけた。

しんたろー：
ベンチマークで「専門家並み」と言われても、実務で使うとバグを埋め込むのが今のLLMだ。AIが書いたコードの「詰め」を人間がやる羽目になる。この「詰め」の時間をいかに減らすかが、開発者の腕の見せ所だ。

開発者目線で言えば、AIに期待すべきは「完成品」ではない。非エンジニアが要件を具体化し、手戻りを最小限に抑えるための「コミュニケーション・インターフェース」としてAIを活用する。ProactionのCOOが自らデモ環境を作れるようになったのは、AIがコードを完璧に書いたからではない。「エンジニアが修正しやすい形」でAIがプロトタイプを出力し、それを人間が制御できるフローが確立されていたからだ。

多くの開発者が陥る罠は、AIに「コードを書いてもらう」こと自体をゴールにすることだ。真に生産性を高めるのは、AIが出力したコードの「論理的な土台」を、エンジニアが素早く精査し、結合するプロセスである。

特に、Claude CodeのようなCLIツールは、このワークフローを加速させる武器になる。ローカル環境でAIがコードを生成・修正し、それを人間が即座に確認・介入できる環境があれば、Proactionが実現した「エンジニアの工数削減」は、小規模なチームや1人SaaS開発でも再現可能だ。

AIの性能競争は「どれだけ賢いか」から「どれだけ人間が制御しやすいか」へと軸足が移っている。AIを「自動操縦」の道具として見るのではなく、人間とAIが「中間成果物」を介して対話する仕組みを作ること。これが、実務で成果を出すための現実的な解だ。

実務でAIの恩恵を最大化するためのアクション

AIを「全自動のエージェント」として期待する段階は終わった。実務において重要なのは、AIの生成物を「完成品」として受け取るのではなく、「エンジニアが修正を加えるための素材」として定義することだ。

明日からの開発で取り組むべきは、AIによるコード生成を「エンジニアの作業を置き換えるもの」ではなく、「エンジニアが作業を開始するためのプロトタイプを作成するもの」へと意識を切り替えることだ。プロンプトの設計において「最終的なコードを完成させる」のではなく、「特定の機能要件を満たす中間的な構造や、モックアップを生成させる」ことを優先する。

例えば、新しい機能を実装する際、AIに対して一度で完璧な実装を求めるのではなく、まずはインターフェースの定義や、主要なロジックの骨組みを生成させる。エンジニアがその骨組みをレビューし、修正方針をAIにフィードバックする。この「人間による介入」を前提としたワークフローを設計しておくことで、プロジェクトの途中でAIが失速し、コードが中途半端なまま止まるリスクを減らせる。

また、非エンジニアのメンバーと協力して開発を進めているなら、彼らがAIを使って「エンジニアへの指示書」や「要件の可視化」を行えるような環境を整えるのも有効だ。Proactionの事例のように、営業担当が顧客との会話内容をAIに渡し、簡易的なデモ環境を構築させるような仕組みは、エンジニアの時間を節約する防波堤になる。

しんたろー：
AIに「全部やって」と丸投げした時ほど、後から負債が積み上がる。Claude Codeでバッチ処理を書く時は、いきなり全機能実装させず、まずはデータ変換のロジックだけ叩き出し、構造に違和感がないか確認してから細部を詰める。この「小分けの介入」が、一番の時短になる。

日々の開発において「AIの生成物が、どれだけ人間の介入を許容しているか」を評価基準に加える。AIが出力したコードの可読性は高いか、モジュールは適切に分割されているか、エンジニアが後から手を入れやすい状態かという観点だ。もしAIがブラックボックスのような複雑なコードを生成し、修正が困難なら、それは実務においては「使えない成果物」と判断する。

AIの性能が上がれば上がるほど、エンジニアの役割は「コードを書く人」から「AIが生成した論理的な土台を洗練させる人」へとシフトしていく。この変化を恐れず、AIを「自分専用のプロトタイピング・エンジン」として使い倒す。そうすれば、1人SaaS開発のような環境でも、スピード感でプロダクトを磨き上げることが可能になる。

次の開発タスクで、AIに「コードを書いて」と頼む代わりに、「この要件を整理するためのドラフトを作って」と声をかける。その変化が、AIを「期待外れの自律エージェント」から「加速装置」へと変える第一歩になる。

あわせて読みたい【2026年版】AI活用1人SaaS開発の完全ロードマップ｜5ステップで始める個人開発 →

よくある質問

AIエージェントに業務を任せると、なぜ途中で止まってしまうのですか？

現在のAIは単発のタスクには高い精度を発揮するが、長時間かつ複雑なプロジェクトでは文脈の維持やファイルエラーの回避、品質の網羅性において安定性を欠くためだ。複数のステップが絡む業務では、AIが「それっぽい成果物」を作ったとしても、細部の不完全さが積み重なり、最終的な納品レベルに達しないケースが多発する。AIを全自動化の手段とするのではなく、人間が途中で介入し、AIの生成物を修正・確認する「Human-in-the-loop」のワークフローを前提に設計することが、実務で成果を出すための現実的な解だ。

ProactionのようにAIで営業効率を上げるには、何から始めるべきですか？

まずは「エンジニアが毎回手作業で行っている定型的なカスタマイズ業務」を特定する。Proactionの事例では、顧客ごとのデモ環境構築という「エンジニアの工数を圧迫していたが、論理的なルールがある業務」をAIに委譲した。重要なのは、AIにすべてを任せるのではなく、非エンジニアがAIを使って『エンジニアへの指示書』や『プロトタイプ』を生成し、それをエンジニアが最終確認するフローを構築することだ。これにより、エンジニアはゼロからの構築から解放され、AIが作った土台を洗練させる作業に集中できる。

開発者が「AIの成果物」を評価する際、特に注視すべきポイントは？

「そのコードがどれだけ人間の介入を許容しているか」という可読性とモジュール設計だ。AIが生成したコードがブラックボックス化していて修正が困難な場合、実務では「使えない成果物」と判断する。AIがモジュールを適切に分割し、ロジックが論理的に整理されていれば、エンジニアは後から容易に手を入れられる。AIの性能向上に伴い、開発者の役割は「コードを書く人」から「AIが生成した論理的な土台を洗練させる人」へとシフトしている。AIを「プロトタイピング・エンジン」として使い倒し、手戻りを減らすことを評価基準に置くことが重要だ。

まとめ

Proactionの事例は、AI活用における「あるべき姿」を示している。AIを「魔法の杖」として全自動化を夢見るのではなく、人間が介入可能な「中間生成物」を作るエンジンとして再定義する。この発想の転換こそが、開発現場の生産性を変える鍵だ。

僕自身、Claude Codeを使いながら「AIに完遂させる」ことよりも「エンジニアが修正しやすい土台をいかに速く作るか」を意識するようになってから、開発スピードが変わった。AIは自律的なエージェントではなく、技術を拡張するパートナーだ。AIを全自動化の幻想から解放し、実務の加速装置として使いこなすための戦略を、引き続きThreadPostで深掘りしていく。