AI開発 （2026年10月4日 更新） 6 min read

少人数の開発チームで、AIに任せた作業と任せなかった作業

少人数の開発チームで、設計の壁打ち・資料作成・コードレビューの補助をAIに任せた記録。断片的な知識を一本の流れに整理させる使い方と、判断や事実確認など自分の側に残した作業の分け方をまとめる。

テックリードAI開発チーム開発

少人数の開発チームでは、設計判断を同じ目線で相談できる相手がチーム内にいないことがある。自分はその部分をAIで補ってきた。任せたのは設計の壁打ち、資料作成、コードレビューの補助で、いちばん効いたのは「断片的な知識を一本の流れに整理させる」使い方だった。一方で、判断と事実確認は自分の側に残している。

この記事では、何を任せて何を任せなかったかを、方法として整理する。

背景：自分の知識がチームの上限になる

少人数のチームでテックリードをしていると、見る範囲が広くなる。自分の場合は次のようなものだ。

  • コード管理
  • 要件定義
  • 技術管理（スタック選定・アーキテクチャ判断）
  • プロジェクト管理・タスク管理
  • チーム設計（教育計画など）

この体制で一番困るのは、作業量よりも相談相手の不在だった。設計や実装方針を同じ目線で検討する相手がいないと、自分の頭の中にある知識と判断力が、そのままチームの上限になる。自分が知らないことは、チームにとっても存在しないことになる。これが一番怖かった。

任せた作業

実装の相談

最初に使ったのは Cursor だった。コードを書いてくれること自体も便利だったが、それ以上に役に立ったのは、実装の相談ができることだった。書く前に方針を話し、返ってきた案を見て考え直す、という往復ができる。

断片的な知識を一本の流れに整理させる

検索は、キーワードに合う情報を外から探してくる道具だ。AIの使いどころはそこではなかった。自分の頭の中にある断片的な知識を、一本の流れに並べ直してもらう使い方が一番効いた。

考え始めの段階の知識は、たいてい順序も粒度もばらばらだ。それを渡して流れにしてもらうと、「自分が何を考えているのか」が文章として目の前に出てくる。相談相手がいない環境では、この言語化を手伝ってくれる相手がいなかった。

自分のやり方を手順にすると、次のようになる。

  1. 分かっていること・気になっていることを、順序を気にせず箇条書きで渡す
  2. それを一本の流れ（前提 → 処理の順序 → 分岐）に整理してもらう
  3. 整理された結果を読み、抜けている箇所や自分の認識と違う箇所を探す
  4. 違っていた箇所は、自分の言葉で直してからもう一度渡す

3 が要点で、整理された文章は「正解」ではなく、自分の考えを点検するための材料として読む。

依頼文は、たとえば次のような形になる。決まった書式があるわけではなく、「整理だけを頼み、足りない点は質問として返してもらう」ことが伝わればよい。

以下は、ある機能について自分が分かっていること・気になっていることのメモです。
順序も粒度もそろっていません。

- （メモを箇条書きで貼る）

これを「前提 → 処理の順序 → 分岐」の一本の流れに整理してください。
メモに書かれていないことは補わず、不足や矛盾があれば質問として列挙してください。

「書かれていないことは補わない」と明示するのは、後述する誤りの混入を減らすためだ。それでも混ざることはあるので、3 の点検は省かない。

設計の壁打ち・資料作成・コードレビューの補助

日常的に任せているのは次の3つだ。

| 作業 | AIに任せる部分 | 自分がやる部分 | |---|---|---| | 設計の壁打ち | 案に対する指摘、別案の提示 | どの案を採るかの判断 | | 資料作成 | 構成と叩き台の作成 | 内容の事実確認、最終的な文面 | | コードレビューの補助 | 一次的な指摘の洗い出し | 指摘の採否、承認 |

設計の壁打ちの具体例はClaude Codeを設計の壁打ち相手として使うに、コードレビューでの使い方と利用指針はClaude Codeを実務導入して開発フローが変わった話に書いた。

任せなかった作業

上の表の右列がそのまま答えになる。AIに任せなかったのは、判断と事実確認だ。

  • 技術的な最終判断：スタック選定やアーキテクチャの決定。AIの案は材料であり、採否は自分が決める
  • 事実の確認：AIの出力に含まれる事実関係は、自分で確かめる
  • レビューの承認：補助の指摘は参考にするが、通すかどうかは自分が見て決める

こう分けているのは、使い続ける中で次の2つを経験したからだ。

  • 誤った情報が、自信のある文体で出てくる
  • 渡した文脈から外れた質問をすると、的外れな回答が返ってくる

便利な面だけを見ていると、この2つに気づかないまま出力を採用してしまう。限界を知っていることが、道具として使うための前提だと考えている。

うまくいかなかった点

  • 相談相手の不在が解消したわけではない。AIは自分が渡した前提の範囲でしか答えないので、自分が気づいていない前提の誤りは、そのまま残ることがある。「自分の知識がチームの上限になる」という構造は、緩和はされたがなくなっていない
  • 確認の手間は残る。出力をそのまま使えないため、整理や叩き台が速くなった分の一部は確認に回る
  • 整理された文章は読みやすいので、納得しやすい。読みやすさと正しさは別だと意識しておかないと、点検が甘くなる

まとめ

  • 少人数のチームで不足するのは、手の数だけでなく設計判断の相談相手だった
  • AIに任せたのは、実装の相談、断片的な知識の整理、設計の壁打ち、資料の叩き台、コードレビューの一次指摘
  • いちばん効いたのは、断片的な知識を一本の流れに整理させ、それを自分の考えの点検に使う方法
  • 任せなかったのは、技術的な最終判断、事実の確認、レビューの承認
  • 誤った情報と的外れな回答は必ず出る前提で、確認の工程を手順に含めておく

関連記事:

関連記事

↑