AI駆動開発で差がつくのは、「AIに何を渡さないか」を決められる人だ

みなさん、こんにちは。
現役IT執行役員のグイグイです⚡

このところ、AI駆動開発について連続で記事を書いています。

1本目では、AIを一番使ったメンバーが結果として一番進捗が遅かった話を書きました。
2本目では、AIによって「できるかできないか」の差が「速いか遅いか」の差に変わってきた話を書きました。

今回は、そのもう一段深い話です。

ハーネス（AIがブレずに動くための仕組みの総体）を作る側として、現場で一番悩んでいること。それが「AIに何を渡し、何を渡さないか」という判断です。

これは単なるプロンプトの書き方の話ではなく、人間がどこまで決めてどこからAIに考えさせるのか、その境界線を引く話です。

現場で議論が起きた

今のプロジェクトはSpring Batchを使ったバッチ処理の開発です。

最初のうちは比較的パターンが決まっている共通機能を作っていて、SPECSの記述が多少あいまいでもAIエージェントがある程度正しく実装してくれていました。

ところが、バッチジョブ本体の実装に入ったタイミングで、あるメンバーがこう言いました。

「細かく書かないと、AIが誤判断するのではないか」と。

Spring BatchにはTasklet・Chunk・Chunk Partitionといった処理方式があって、どれを選ぶかは機能固有の設計判断になります。

性能要件もあるし既存の作り方もある。

AIが自分で好きに選んでいいものではないので、処理方式そのものは人間が明示する必要がある。

そこまでは私も同意です。

問題は、その先です。

各処理の中でReader・Processor・Writerの役割分担まで全部SPECSに書くべきか。

書けばAIは迷いにくくなります。

ただ、それを全部人間が書くなら、何のためにAIを使っているのかという話にもなります。

設計書を人間が読み、SPECSに細かく変換し、AIがそれをなぞる。

安全に見えますが、実務でやると人間側の設計コストがどんどん増えていきます。

書きすぎても、書かなすぎても問題になる

ここは微妙な線引きです。

書きすぎると、本来AIに考えさせられる部分まで人間が先回りして全部書いてしまう。

AIエージェントは実装者というより清書係に近づいていきます。

書かなすぎると、AIが勝手に判断してプロジェクトの規約と違う構成にしてしまう。

レビューや手戻りが増えます。

今回の現場での決着はこうでした。

処理方式（TaskletかChunkか）とChunkのアイテム数までは明示する。

ただしReader・Processor・Writerの役割分担は書かない。

日本語の業務仕様があれば「ここからデータを取得する」「ここで加工する」「ここに書き込む」はAIが自然言語から判断できるはずだという前提に立ちました。

Spring Batchの文脈でChunkと明示されていれば、そこからの分解はAIが推論できる。

だから、そこはAIに任せる判断にしました。

もちろんすべてのケースでこれが正解だとは思っていません。

ただ今回の現場では、この境界線が一番現実的でした。

AIを少しわかり始めた人ほど、極端に振れやすい

今回のメンバーの反応を見ていて、ひとつ気づいたことがあります。

AIをわかり始めた人間が陥りやすいパターンが2つあります。

AIを疑いすぎて過剰に指示しようとするケースと、疑わなすぎて丸投げするケースです。

今回のメンバーは前者に振れかけていました。

AIの失敗パターンが見えてくると、必要以上に怖くなることがある。

エンタープライズ開発でAIを使うなら間違える前提で考えるのは正しいのですが、疑いすぎるとAIの推論力を殺してしまいます。

面白いのは、AIをまったく知らない人よりも、少しわかってきた人の方がこういう極端な振れ方をしやすいということです。

知識が中途半端なうちは、恐れか過信かのどちらかに偏りやすい。

これは現場で見ていて感じます。

同じ構造がスキルやコンテキスト管理にも出てくる

この「何を渡し、何を渡さないか」という問いは、設計書の粒度だけの話ではありません。

AIエージェントに与えるスキルやコンテキストの管理でも、同じ構造が出てきます。

スキルをたくさん用意しておくのは有効です。

プロジェクトの規約・コーディングルール・テスト方針・ログ設計・例外設計・レビュー観点、こういうものをAIが参照できる形にしておくと出力の安定感は上がります。

ただし毎回全部ロードすればいいわけではない。

関係ない情報まで毎回入れるとコンテキストが肥大化してトークン消費が増えるし、ノイズになって精度が下がることもある。

「とにかく詰め込めば精度が上がる」という発想は、「とにかく細かく書けばAIが正しく動く」という発想と構造的に同じ間違いをしています。

何を常に持たせるのか、何を必要なときだけ渡すのか、何をあえて渡さないのか。

足すことと同じくらい、削ることが実務では大事になります。

この判断は、マニュアル化しにくい

ある程度のルール化はできます。

処理方式は明示する、プロジェクト固有の規約は渡す、ログや例外の設計方針は固定する。

こういうものはハーネスとして整備できます。

ただ最終的な線引きは現場で判断するしかありません。

この仕様ならAIに分解させていい、この処理は人間が固定した方がいい、ここはコンテキストに入れるべき、これは今は入れない方がいい。

こういう判断はマニュアルだけでは決めきれない。

実際にAIに渡してみて、出力を見て、失敗パターンを見て、どこまで任せられるかを少しずつ見極める。

その積み重ねでしか精度は上がっていきません。

この判断を正しく引けるようになるには2つが必要です。

対象の技術スタックへの深い理解と、AIエージェントの推論能力への理解。

Spring Batchをわかっていなければ処理方式の違いが設計にどう影響するか見えないし、AIの推論能力をわかっていなければ本来AIが分解できるところまで人間が書いてしまいます。

技術を知っているだけでも、AIを知っているだけでも引けない線があります。

だからこそ、この境界線を引ける人間の価値が高い。

AIに何を渡さないかを決められる人は、まだ多くないと思っています。

AI駆動開発はまだ始まったばかりです。

こういう地味な判断の積み重ねも含めて、引き続き現場で起きていることを書いていきます。

#AI駆動開発
#生成AI
#AIエージェント
#GitHubCopilot
#エンタープライズ開発
#システム開発
#SpringBatch
#プロンプト設計
#AI活用
#現場のAI活用