AIがコードを書く時代のチーム設計
「このPRのレビュー、AIが書いたコードなのか人が書いたコードなのか、もう判別できない」——2026年の現場でエンジニアリングマネージャーが漏らすこの言葉は、冗談ではありません。ChatGPTをはじめとするAIエージェントが自律的にコードを生成・修正・テストまで回す環境が整い、チームの仕事の中身が静かに、しかし急速に変わっています。問題は技術の進化ではなく、評価と役割の設計が追いついていないことです。
「動くけど誰も責任を持てない」という現実
あるSaaSスタートアップでは、開発速度が半年前の3倍になった一方で、障害対応に時間がかかるようになっています。AIが生成したコードの意図を誰も説明できないからです。「Pythonが書ける」「Reactの経験3年以上」という採用要件は、AIがその作業を代替できる前提で作られていません。結果として、AIをうまく使いこなしているエンジニアより、手書きコードにこだわるエンジニアの方が評価される逆転現象が起きているチームも出てきています。
ChatGPTで自チームの役割を可視化する方法
この状況を整理するのに、ChatGPTが使えます。やり方はシンプルで、直近のスプリントで各メンバーが実際に行った作業を箇条書きにして貼り付け、「この作業のうち、AIが代替できるもの・できないものに分類して」と指示するだけです。出力された分類を見ると、ほとんどの実装作業が「代替可能」に入り、残るのは「AIが出したアウトプットの品質を判断する」「ステークホルダーとの要件のすり合わせ」「アーキテクチャの意思決定」だけです。これが2026年のエンジニアの仕事の実態です。
採用要件も評価シートも書き直す必要がある
評価すべきは「何を書けるか」ではなく、「AIに何を任せ、どこに人間の判断を入れるかを設計できるか」です。ChatGPTに「AIエージェントを使いこなすエンジニアに必要なスキルセットを、従来の求人票と対比して書いて」と依頼すると、具体的な文言の差分が出てきます。「実装経験」より「レビュー判断力」、「言語スキル」より「システム設計力と説明責任」という軸の変化が言語化されます。これをそのままチームの評価シートに転用しているマネージャーもすでにいます。
役割設計で最初に決めるべきこと
役割設計で先に決めるべきことは一つです。「AIが生成したコードに最終的に責任を持つ人間を、チームのどこに置くか」という問いです。この答えを出さないまま開発速度だけを上げると、障害が起きたときに誰も説明できないチームが完成します。AIエージェントのマネージャーとしての能力をどう定義するか、それがいまチームに問われています。
今回の内容をすぐ使える形にしたプロンプトテンプレートと評価シートの雛形を、まとめた資料としてご用意しています。
コピペで使えるプロンプト集
① AIエージェント時代のエンジニア評価基準を再設計する
エンジニアリングマネージャーや人事責任者が、旧来の「コーディング力重視」評価制度を見直したい時
あなたはエンジニア組織設計の専門コンサルタントです。AIがコードを自律生成する2026年以降を見据え、【会社規模:例 従業員50名のSaaS開発会社】の評価制度を再設計してください。まず①現行の「コーディングスキル重視」評価の課題を3点整理し、次に②AIエージェント時代に必要な新評価軸を5項目(各30文字以内)で定義し、最後に③各評価軸の具体的な行動指標を1項目につき2例ずつ箇条書きで示してください。トーンは現場導入可能な実務的表現で。あなたの提案がわが社の組織変革の礎になることを期待しています。
② AIマネージャー型エンジニアの採用要件を30分で作成
採用担当・CTOが、AIエージェントを使いこなす新時代のエンジニアJDを求人票に書きたい時
あなたはIT企業の採用戦略に精通したHRコンサルタントです。【ポジション:例 AIエージェント活用リードエンジニア】の求人票を作成してください。思考手順:①従来型「言語スキル重視」JDとの差分を明確にする→②新設すべきスキル要件を必須3項目・歓迎3項目で列挙→③1日の業務イメージを時系列で3ステップ記述→④応募者の心を動かす50文字以内のキャッチコピーを提示。出力はそのまま求人サイトに貼れる構成で、読み手は【ターゲット:例 AI活用に関心のある中堅エンジニア】を想定してください。採用市場で差別化できる最高品質のJDを期待します。
③ 現場エンジニアへの「役割変化」説明会スクリプトを即作成
テックリードやマネージャーが、AIツール導入後の役割再定義をチームメンバーに納得感を持って伝えたい時
あなたは組織変革を専門とするエンジニアリングコーチです。AIエージェント導入により【チーム状況:例 10名のバックエンドチームで全員がコーディング中心業務】の役割が変わることを、現場エンジニアに説明する15分間のミーティングスクリプトを作成してください。構成:①変化の背景説明(不安を和らげる共感の一言から始める)→②新しい役割の具体例を3つ(各「Before:〇〇 / After:〇〇」形式)→③よくある懸念Q&A 3セット→④前向きに締めくくるクロージングメッセージ50文字以内。メンバーが「自分の価値が高まる」と感じられるポジティブな表現で統一してください。チームの心理的安全を守る最善のスクリプトを期待します。
「動いてるのに誰も説明できない」という状況、技術的な話というよりチームの設計の話なんですよね。
自チームの作業をAIに分類させるというアプローチ、やってみると思った以上にリアルな結果が出てきて面白いです!
評価基準の見直しって後回しになりがちですが、ここに手を入れるだけでチームの空気がかなり変わります。まずスプリントの振り返りで一度試してみてください。