はじめに
生成AIを開発に使うとき、「どこまでAIに任せるべきか」という議論があります。
自分は、最初から「これは人間にしかできない」と線を引くより、まずAIに任せてみる方がよいと考えています。要件理解、調査、実装、テスト設計、PR作成など、対象を限定せずに一度やらせてみます。
そのうえで、AIだけでは完遂できなかった部分があれば、なぜできなかったのかを調べます。必要なら人間がその部分だけ実行し、得られた知見をSkillやルールへ戻します。
この記事では、自分が実践している「AIを補助として使う」のではなく、「AIが作業することをデフォルトにする」開発スタイルを整理します。
AIができる仕事を探すのではなく、まず全部任せてみる
よくあるAI活用は、人間が仕事を分解し、その中からAIに向いている作業だけを渡す形です。
人間が仕事を理解する
↓
AIに任せられる部分を探す
↓
プロンプトを書く
↓
AIが一部を実行する
自分は逆の順番で考えています。
ゴールをAIに渡す
↓
まずAIに全部やらせてみる
↓
できない部分を特定する
↓
できるようにする方法もAIに考えてもらう
↓
それでも無理な部分だけ人間が実行する
つまり、「AIに何を任せるか」を人間が先に狭く定義しません。
要件の理解、コードリーディング、実装、テスト設計、テスト実行、修正、PR作成まで、まとまりのある仕事として任せます。
重要なのは、最初からAIの能力を低く見積もらないことです。
「どうやればAIができるか」もAIに考えてもらう
AIが作業を完遂できなかった場合、人間がすぐに引き取る必要はありません。
まず、次のようなことをAI自身に考えてもらいます。
- なぜ実行できないのか
- 足りない情報は何か
- 別のツールで代替できないか
- CLIやAPIから実行できないか
- ブラウザ操作で代替できないか
- テストや確認手順を追加すれば自律的に進められないか
- 次回から同じ問題を避けるために何を残すべきか
ここでのポイントは、AIがそのまま使える環境だけを対象にしないことです。
「現在の環境ではできない」という事実と、「AIにできない仕事である」は別です。実行経路や環境を変えれば、AIに任せられる場合があります。
人間は例外処理を担当する
もちろん、現実にはAIだけでは突破できない作業があります。
特に会社環境では、次のような制約があります。
- 権限不足
- 利用可能なツールの制限
- セキュリティ上の制約
- 社内ネットワークからしか触れないシステム
- AIから直接操作できないGUI
- 人間の承認が必要な操作
この場合、自分はAIに手順を説明してもらい、その部分だけ自分で操作します。
AI
↓
実行できない箇所を特定
↓
人間に必要な操作を説明
↓
人間がその部分だけ実行
↓
結果をAIへ返す
↓
AIが続きを実行
人間が常に中心でAIを補助として使うのではなく、人間をフォールバックとして残すイメージです。
面倒だと思う気持ちは自動化の入口になる
このスタイルを続けるうえで、「面倒だから自分でやりたくない」という感覚は意外と重要だと思っています。
毎回同じ手順を実行する、長いログを追う、PRの説明を書く、似たようなテストを追加する、といった作業を「自分でやった方が早い」で終わらせると、その仕事はずっと人間側に残ります。
一方で、
これを次からAIにやってもらえないか
と考えると、自動化やSkill化の対象になります。
面倒だと感じることは、単なる怠慢ではなく、人間が繰り返す必要のない仕事を見つけるきっかけになります。
失敗した知見をSkillへ戻す
AIに何でも任せるだけでは、同じところで何度も失敗します。
そこで、自分はAIが詰まった理由や新しく得た知見を、可能な限りSkillやルールへ戻すようにしています。
たとえば次のような情報です。
- このリポジトリ固有の開発手順
- よく間違える判断
- 実行前に確認すべきこと
- テストの優先順位
- ブラウザ操作の手順
- ツールの制約
- レビュー時に見るべき観点
流れとしては次のようになります。
AIに任せる
↓
失敗する
↓
原因を調べる
↓
Skill・ルール・テストを更新する
↓
次回はAIだけで処理できる範囲が増える
単発のプロンプトを改善するというより、AIが働くための環境を継続的に改善する考え方です。
理想は人間向けの環境をAI向けにも組み直すこと
さらに進めるなら、開発環境そのものをAIが扱いやすい形にしたいと考えています。
たとえば、GUIでしかできない作業をCLIやAPIから実行できるようにしたり、テスト結果を機械判定しやすくしたり、リポジトリ固有の知識をSkillへ移したりします。
人間向けの手順
↓
AIが利用できるCLI・API・テスト・Skillへ変換
↓
人間の介入箇所を減らす
ただし会社の開発環境では、自分の判断だけで権限やツール構成を変えられません。そのため現状では、AIが実行できない箇所だけ人間が補助する運用になっています。
AI-assistedではなくAI-defaultとして考える
この考え方は、AI-assisted developmentよりAI-default developmentと呼ぶ方が近いと思っています。
AI-assistedでは、人間が主な作業者で、AIは補助です。
人間 = 実行主体
AI = 補助
AI-defaultでは逆です。
AI = 実行主体
人間 = 目的の提示・例外処理・最終判断
「人間にしかできない仕事は何か」を先に探すのではなく、「この仕事もAIにやらせるには何が必要か」を考えます。
その結果として、本当に人間が必要な部分だけが残ります。
ただし評価手段は必要になる
AIに任せる範囲を広げるほど、結果をどう確認するかが重要になります。
実装を大量に任せても、正しいかどうかを毎回人間がすべて読み直すのであれば、自動化できる範囲には限界があります。
そのため、次のような機械的な評価手段を増やす必要があります。
- 単体テスト
- E2Eテスト
- lint
- 型チェック
- CI
- 差分確認
- 既存仕様との比較
- 変更してはいけない範囲のルール
AIに自由を与えることと、無条件に信用することは別です。
任せる範囲を広げるためには、失敗を検出できる仕組みも同時に強くする必要があります。
個人利用ではコストがボトルネックになる
このスタイルには、AIの性能とは別の問題があります。
会社では十分な利用枠があれば、要件理解から実装、テスト、PR作成まで長いタスクを何度も試せます。しかし個人利用では、月額20ドル前後の一般的なプランで同じ使い方を再現するのは難しい場合があります。
何でもAIに任せるスタイルでは、次のようなところで利用量が増えます。
- 大きなリポジトリを何度も読む
- 実装とテストを繰り返す
- 失敗したら別の方法を探索する
- Skill自体を改善する
- 長いタスクを最後まで実行させる
そのため、今後のAI開発ではモデル性能だけでなく、「十分な試行回数を個人が現実的な価格で確保できるか」も重要になると感じています。
AIが賢くても、利用量を気にして途中で人間が作業を引き取るのであれば、AI-defaultな開発にはなりにくいからです。
まとめ
自分のAI利用方針は、次の一文に集約できます。
まずAIに任せる。できなければ、どうすればAIができるようになるかもAIに考えてもらう。それでも無理な部分だけ人間がやる。
そして、そこで得た失敗や知見をSkill、ルール、テストへ戻します。
このサイクルを繰り返すことで、人間が担当する仕事を少しずつ例外へ追いやっていきます。
AI時代の開発では、「何が人間にしかできないか」を守ることより、「どうすれば次はAIだけで完遂できるか」を考えることの方が重要になる場面が増えていくと思っています。