Movatterモバイル変換


[0]ホーム

URL:


見出し画像

■はじめに

プロジェクトとは、フロンティアに向かう冒険のようなものだ。

出典:片山良平 談話|2025年8月24日

Devin、ClaudeCode、Kiroといった生成AIを用いたAI駆動開発による生産性向上に取り組んでいる企業が昨今増えています。

しかし実際に取り組んでみるとザクッとタスクを丸投げすることは難しく、細かくタスクを砕いて生成AIに依頼しないと精度が上がらないことが多発します。ましてや企画やコンサル側が要件を依頼しただけでシステムができるのは夢のまた夢のような状況です。

しかしこういった状況に対して、「今はまだ生成AIの精度が悪いかもしれないが、今の速度で生成AIが進歩すれば、ザクッと丸投げできるようになるのではないか?」と言われる方も多くいらっしゃいます。

しかしそれは構造的に考えると生成AIの進化だけでは達成不可能なのです。今回は、なぜ生成AIに大きなタスクを丸投げできないのか?、構造的に生成AIの進化だけでは難しい理由を考察します。

■結論

忙しい人のために、最初に結論を提示します。

なぜ生成AIに大きなタスクを丸投げできないかの理由は、プロジェクトを進めたり開発をしてみることで初めてわかる事実からプロジェクトのゴールは変更され、その変更によってトレードオフの意思決定をビジネス、組織、チームに求められるからです。

このブログが良いなと思ったら、noteXをフォローしてくれると嬉しいです。


■生成AIが進化すればできるようになるという、よくある誤解

「今の速度で生成AIが進歩すれば、ザクッと丸投げできるようになるのではないか?」という言説はどこから生まれるのかというと、LLMのスケール則から生まれています。

「スケール則」とは、計算量、データセットサイズ、パラメーター数が増えれば性能が上がる法則です(※下図参照)。これは現時点でも継続されている法則なので、生成AI関連に巨額の資金や人が動いているのです。

Scaling Laws for Neural Language Models”(Jared Kaplan, et al. @ OpenAI, arXiv, 2020.)

このスケール則により未来の生成AIはこのスピード感でもっと性能が上がり、もっと良いものになるという楽観的な見かたが生まれています。実際に新しい生成AIモデルが次々と誕生するのもこのスケール則によるものです。

しかし生成AIにも構造的にできることとできないことがあります。単純な話で言えば、生成AIは意思決定の責任を取ってくれるわけでもなければ、調整ごとしてくれもせず、重いものを代わりには持ってくれもしません。

こういった構造的に考えて生成AIが肩代わりできない領域が含まれるタスクを生成AIに依頼しても良い結果は得られません。

つまり、生成AIがいくら進化してもできないことはそれなりにあり、ザクッとした依頼でいい感じのものが作られるのではないか、という未来は実現されないのです。

■プロジェクトにおける生成AIの課題の整理

①生成AIのプロセス設計・WBSの精度の課題 

生成AIはタスクを細かく砕いて、指示内容とゴールが明確なものを渡すとそれなりの精度でアウトプットしてくれます。

そのためClaudeCode、Devin等の開発用モデルはプロンプトを推論し、プロセス設計をし、詳細タスクに分解してから実装を始めます。しかしタスクの規模が大きくなるほど、精度が落ちがちです。

これは、与えられたタスクのプロセス設計、細かい粒度に分解する部分の課題です。この課題は生成AIの推論モデルで使われているCoT(Chain of Thought:思考の連鎖)の精度課題とも言えます。

CoTとは、複雑なタスクを最終的な解決に向けて論理的なステップの連続に区切る、人間のような推論プロセスをシミュレートしたものです。現状生成AIの推論能力はまだ課題はあるものの、生成AIの直線的な性能進化で推論能力の課題もいずれ解決可能な問題です。

つまりこの課題は生成AIの性能向上でいずれは解決されるものと考えられます。

②実装フェーズで起きた問題のプロセス設計・WBSのへのフィードバック課題

プロンプトからプロセス設計をし、詳細タスクに分解したうえで実装プロセスに入った場合でも、実際に実装してみると速度が出ないとか、実装上の不具合があるなど、問題が発生することがよくあります。

そういった場合に最初に考えたプロセス設計を見直し、その上で再度詳細タスクを洗い出し、実装プロセスをやり直す必要があります。これはClaudeCode、Devin等ではすでに実装されている機能です。

しかしこちらも現状は下記のような課題が発生しがちです。

  1. 実装プロセスでAという問題が発生

  2. プロセス設計やり直し、別方法でアプローチ

  3. A問題は解決したが、今度はB問題が発生

  4. プロセス設計やり直し、別方法でアプローチ

  5. B問題は解決したがAは問題が再発 →2に戻る

という感じでループが発生し、延々と改修を続けてしまったりします。

この課題は、生成AIのコンテキストをより長く保持し、AとBの両方の課題を認識しつつCの解決策を探るなど、それなりの計算資源は必要になるが性能向上で吸収が可能なタイプの課題です。

つまりこの課題も生成AIの性能向上でいずれは解決されるものと考えられます。

③新たにわかった問題・制約事項に対して意思決定が必要な課題

これが今回本命の課題となります。

プロジェクトやソフトウェア・サービス開発は、実際に開発をしてみることで初めてわかる事実や制約事項が数多くあります。そういった発見からプロジェクトの要件・ゴールは変更され、その変更によってトレードオフの意思決定をビジネス、組織、チームに求められる事が多々あります。

多くの人は、無意識のうちにそれらの要件・ゴールは一意に定まっていると思いがちです。仮にそうであるとすれば、その要件・ゴールに向かって生成AIがあれこれ考えて開発を進めてくれることで、いずれその要件・ゴールに辿り着くことも可能でしょう。

ゴールが固定的である場合のプロジェクト
生成AIが選択肢を一つづつ試しながらゴールに近づけていくイメージ

しかし実態は、ほぼすべてのプロジェクトやソフトウェア、サービス開発において開始時点での要件・ゴールの不確実性は高く曖昧です。それは事前にすべての制約事項を把握するのは人間には不可能だからです。

プロジェクトの進捗とともに明らかになった課題、制約事項に応じて要件・ゴールを動かすトレードオフな戦略的意思決定が、組織を巻き込んだ形で発生します。

実際のプロジェクトでは要件・ゴールは動く
やってみて分かった制約事項をもとに意思決定と調整事項が発生するイメージ
意思決定と調整は生成AIは性能が上がってもやれるようにはならない

こちらの課題をわかりやすい例で示すと下記のようなものです

  1. 実装してみると想定の速度が出ず、サーバ増強でリアルタイム性を求めるか、サーバはそのままでバッチ処理をすることでリアルタイム性は捨ててコストメリットを取る

  2. 外部サービスのAPIからデータを取得する想定にしていたが、そもそも必要としていたデータがマニュアルに書かれているにも関わらずそのAPIで提供されていなかったので、要件を落とすか別の方法を探すか

  3. ECサービスで商品Aを見たい人にBをおすすめするロジックを作ったが、商品Aを見る人が皆無だったので、この機能を辞めるか、商品Aの接触機会をつくるか

つまりやることで見える制約事項により、調整業務と意思決定が発生するのです。調整業務と意思決定(とその責任を取ること)は生成AIの性能向上だけではどうにもならない、ということです。

「サーバを増強」するのであれば予算取りが必要ですがそれは生成AIはやってくれません。「運用で回避」を行うのであれば運用部隊に根回しや、引き継ぎが必要ですが、それも生成AIはやってくれないのです。

そしてこれはスケーリング則で示されている生成AIの性能向上だけではどうにもならない問題です。調整業務や意思決定まで含めてAIがやるためには人間社会に溶け込めるヒューマノイド型のロボティクス技術の発展と、それを受け入れる人間社会の変容(文化、社会規範、インフラ等の変容)等々のいくつかの非常に大きな壁を超えないと実現し得ない世界です。

■まとめ:やってみなければ分からないことが多い

冒頭にも書きましたが「プロジェクトとは、フロンティアに向かう冒険のようなもの」だと思います。

西回りでのインドを目指しスペインを出発したコロンブスのイメージ

コロンブスは1492年に西回りでのインドを目指しスペインを出発しましたが、当時欧州では南北アメリカ大陸の存在は知られておらず、たどり着いたのはインドではなくアメリカ大陸でした。

それが欧州におけるアメリカ大陸の発見なのですが、これは行ってみなければわからなかったことです。

アメリカ大陸の発見は、西回りはアメリカ大陸があるためインド航路としては役立たないが金銀資源や新しい植民地獲得につながり、16世紀以降は「インド航路」とは別軸の大成果と認識されていきます。

やってみて分かったことからゴールをずらして、別の成果を得た、という事例です。規模が大きめのタスクやプロジェクトで、多かれ少なかれこれと似たようなことが発生します。ちょっとしたアプリを作ることも例外ではありません。

そしてそれらのトレードオフの意思決定や調整業務、また責任者としての振る舞いは生成AIが進化しても構造的に代替はできないものです。そのため「今はまだ生成AIの精度が悪いかもしれないが、今の速度で生成AIが進歩すれば、ザクッと丸投げできるようになるのではないか?」というのは構造的に考えて、夢のまた夢であると言えます。

今回の考察を極論ベースで考えてみた記事もありますので、気になる方はこちらも合わせてお読みください。ビジネスにおける究極の丸投げは「儲かるビジネスを作ってくれ(≒ 5,000兆円欲しい)」と仮定して、それが可能になる未来が来るのかについて考察した記事です。

最後までお読みいただきありがとうございました。この記事が良いなと思ったら、ぜひnoteXをフォローしてください。

ちなみに、paizaはITエンジニア向け国内最大の転職・就職・学習プラットフォームです(paiza.jp)。生成AI講座も無料で学べるので、よかったら使ってみてください。

いいなと思ったら応援しよう!

IT・AIエンジニア90万名登録、求人企業4,800社が利用する日本最大のIT・AIエンジニア転職、就職、学習プラットフォームpaiza(パイザ)の創業者&取締役会長。 生成AI、プログラミング、開発にについての記事を書いています。https://paiza.jp/

[8]ページ先頭

©2009-2025 Movatter.jp