受託開発にAIエージェントをどこまで任せられるか｜1人会社の実例で検証

監督だ。「AIを使って開発しています」。そう聞いて、何をどこまで任せているのか気になったことはないだろうか。

調べものの相談相手なのか。コードを書く担当なのか。それとも、変更内容の確認まで任せているのか。同じ「AI活用」でも、開発の進め方はかなり違う。

俺が見てほしいのは、AIに任せる工程と、人が責任を持つ工程の境目だ。今回は、受託開発を1人体制で運営するdreamiの実例をもとに、その境目を整理する。

結論：実装とPR作成を任せても、要件と採用判断は人が握る

先に結論を言おう。この記事で紹介するdreamiの運用では、issueへのラベル付けをきっかけに、AIエージェントが実装し、PRを作成するところまでを自動化している。

issueは「何を直すか、何を作るか」を記録する作業票。PR（プルリクエスト）は「この変更を取り込んでよいか」を確認するための提案だ。

流れはこうなる。

1. 人が依頼内容を整理し、GitHubのissueに要件を書く
2. 対象のissueに特定のラベルを付ける
3. 自前の実行環境でAIエージェント（Claude Code）が起動する
4. AIがコードを変更し、PRを作成する
5. 人が変更内容を確認し、取り込むか、修正を求めるかを判断する

ここで混同したくないのは、コードを書かせることと、納品を任せることは別の判断だという点だ。

何を作るべきか。依頼者の意図と合っているか。既存の動作に問題を起こさないか。そうした確認や、クライアントとの合意形成は人が担う。AIがPRを出した時点では、まだ変更案にすぎない。

「最後にボタンを押すだけ」と言うと格好はいいが、その前の判断まで消えたわけではない。

ラベル一つで動く。ただし、要件まで自動で決まるわけではない

この仕組みの分かりやすいところは、開始の操作がラベル付けにまとまっていることだ。毎回チャットを開いて事情を説明し直す代わりに、issueに書いた内容を起点に実装へ進める。

ただし、入口が簡単でも、依頼の中身が曖昧なら迷う。人に頼むときと同じだ。

たとえば「予約画面を使いやすくして」だけでは、何を変えれば完了なのか分からない。依頼を書くなら、次のように具体化したい。

issueに書く項目	記載例
困っていること	予約完了後に、利用者が次の操作に迷う
変更してほしいこと	完了画面に「予約一覧へ戻る」ボタンを追加する
完了の条件	ボタンから自分の予約一覧へ移動できる
確認する範囲	スマートフォンでも表示と操作に問題がない

これは依頼の書き方の例であり、今回の実績として紹介する案件ではない。

ラベル付けという開始手順は共通化できる。一方で、要件整理やレビューの質まで、操作一つでそろうわけではない。仕組み化できた部分と、まだ人の判断に依存する部分を分けて見る。ここが運用の要だ。

人間に残るのは、要件・確認・合意形成

この実例で人が担っている仕事は、大きく三つある。

何を作るかを決め、issueに落とす

クライアントの「困っている」を、そのままコードにはできない。目的、優先順位、変更範囲、完了の条件を整理する必要がある。

俺は、ここを軽く扱いたくない。作る速度が上がっても、違うものを速く作ったら手戻りになる。

PRの内容を確認し、取り込むか判断する

AIが出した変更について、意図に合っているか、必要な確認ができているかを見て、採用を決める。

確認の深さは変更内容によって変わる。表示の文言修正と、権限や請求に関わる修正を、同じ軽さで扱うわけにはいかない。自動化の範囲を広げるときも、どこで人の確認を必須にするかを決めておきたい。

仕様や優先順位をクライアントと合意する

何を先に作るか。どこまでを今回の範囲にするか。変更にどんな影響があるか。こうした説明と合意形成も、人の担当だ。

「AIがそう言ったので」は、合意の代わりにはならない。開発側が内容を理解して説明できることが必要になる。

次の検討対象は、別のAIによる一次レビュー

この記事の元となる実例では、実装に使うAIとは別のAIに、PRの一次レビューを担当させる仕組みを検討している。ここは実装済みの工程と分けて読んでほしい。

狙いは、人が確認する前に、変更の問題点や確認漏れの候補を挙げてもらうことだ。実装とは異なる観点で点検できれば、レビューの助けになる可能性がある。

ただし、別のAIを使えば見落としがなくなる、とは言えない。同じ問題を見逃すことも、問題のない変更を誤って指摘することもあり得る。指摘の妥当性は確認が必要だ。

俺なら、一次レビューの自動化を「人が読む必要をなくす仕組み」としては扱わない。人が重点的に確認する場所を見つける補助として考える。任せる範囲を広げるにも、その結果を確かめる工程は要る。

発注先には「AIを使うか」の先を聞いてみよう

システム開発を依頼する立場なら、ツール名だけで判断する必要はない。次のように、実際の進め方を聞いてみてほしい。

聞いてみたいこと	確かめたい点
AIはどの工程を担当していますか	調査、実装、レビューなどの担当範囲
AIが作った変更は誰が確認しますか	確認の手順と責任者
要件が曖昧なときはどう進めますか	実装前の認識合わせの方法
問題が見つかったらどう対応しますか	修正、再確認、取り込み判断の進め方
担当者が変わっても運用できますか	手順や判断基準が記録されているか

具体的な答えがあれば、自社の依頼に合う体制かを判断しやすい。

もっとも、自動化の範囲が広い会社ほど、あらゆる案件で優れているという話でもない。仕様変更の多さ、既存システムの複雑さ、確認が必要な内容によって、適した進め方は変わる。発注側にとって大切なのは、自分たちの要件を満たす品質と費用、納期で進められるかだ。

小さな体制ほど、任せ方を具体的にする

今回の実例で運用しているのは、issueへのラベル付けからAIの実装、PR作成へ進み、人が確認して採用を判断する流れだ。別のAIによる一次レビューは、その先の検討事項になる。

作業時間や費用をどれだけ削減できたかの数値は、この記事では示していない。だから「AIを使えば安く、速くなる」と一律には約束できない。それでも、どの工程を任せ、どこに人が残るかは具体的に説明できる。

やれることはAIに任せて、人は創るほうへ。 俺は、そのためにも判断の境目を曖昧にしないことが大事だと考えている。

「自社の開発なら、どの部分を任せられるだろう」。そんな検討からでも構わない。作りたいものや現場の課題を整理し、必要な開発範囲と概算費用を考えるところから、dreamiに相談してほしい。