コードもレビューもAIに任せたら、エンジニアは何に責任を持つのか？
はじめに
コードの生成だけでなく、レビュー、テスト、修正依頼まで、できるだけAIに任せたい。私が考えているのは、その先で人間が事業の戦略や予算、将来を踏まえた技術選定、実際に触って感じる使いやすさに時間を使う開発です。
一方、先日話した非エンジニアの方から、コードが出てきても、それが合っているかのお墨付きはエンジニアに残るのでは、という話がありました。自動で契約書を作れる時代でも、最後は弁護士に確認してもらわないと安心できない。私自身、利用規約やプライバシーポリシーは専門家のレビューを通してから公開したいと感じています。
この記事のポイント
- 生成、レビュー、テスト、修正依頼までAIに任せ、人間が集中する仕事を変えていく。
- 人間は、事業上の優先順位や予算、利用者の体験を確かめ、技術判断の根拠を説明する。
- お墨付きの中身を、確認した範囲、未確認の条件、公開後の監視と停止判断まで具体化する。
以下は2026年11月6日時点の公式資料を踏まえた考察です。製品の現状と、私が目指したい働き方、将来についての仮説を分けて整理します。
レビューまでAIに任せられるのか？
レビューを自動化する機能はすでにあります。ただし、現行の公式資料では、人間による確認を含む使い方が案内されています。
GitHubの公式ドキュメントでは、Copilotが変更をレビューして修正を提案できる一方、問題の見落としや誤りがあり得るため、フィードバックを検証し、人間のレビューで補うよう説明しています。
私個人の考えでは、AIが書き、人間が差分を一行ずつ読む分担を、将来まで固定する必要もないと思います。仕様との照合、テストの作成と実行、指摘に対する修正、再レビューは、もっと連続して任せたい部分です。
2026年11月4日、OpenAIはPierreの買収予定を発表しました。Pierreは、Gitでコードと変更履歴を管理するサービス「Code Storage」や、ファイル一覧・差分表示の開発用ライブラリを作る会社です。そのTreesとDiffsはすでにCodexアプリで使われています。買収の完了には規制当局の承認などの条件があり、完了までは両社は独立した企業です。
私は、コード生成の支援から、保存や変更の理解、レビューまで開発の仕事全体へ広げる動きとして注目しています。
人間はどこに時間を使うのか？
私が人間の仕事として厚くしたいのは、事業上の選択と、利用者の体験を確かめることです。どちらもAIを相談相手にできますが、自社が引き受ける条件や、現場で起きた違和感を持ち込む人が必要です。
たとえば、AIを前提とした問い合わせ機能を作るとして、自動回答率だけを追うのか、重要顧客が担当者と話せる経路を優先するのか。そもそも今期の予算をそこに使うべきか。コードを書き始める前に、事業側が選ぶことがあります。
アーキテクチャ、つまりシステム全体の構成も同じです。試作品を最短で出せる構成と、今の担当者が抜けても保守できる構成は一致しないことがあります。AIの扱いやすさに加え、利用料、障害時の対応、データの移行、将来の採用まで比較して選びたい。
以前の「AI時代、全員がPMになる」では、何を、なぜ作るかに踏み込む必要性を論じました。今回はそこからさらに、実装後の技術レビューも自動化する方向で、人間の仕事を考え直しています。
もう一つは、画面を触ったときの確認です。入力に失敗したとき、どこを直せばよいか直感的に分かるか。確認画面を見て、安心して確定できるか。自動テストでボタンが押せても、利用者が迷わないことまでは同じ意味で確認できません。
私の感覚では、AIは学習したパターンから、平均的には優秀なUIを作ってくれます。ただ、ともすると平均点の優等生でもある。似た余白、似たカード、似た配色が並び、金太郎飴のように既視感のある画面になりがちです。
そのAI臭さを超えて、誰のどんな操作を気持ちよくするのか、どこを自社らしくするのか。見本を選び、違和感を伝え、出てきたものを触って直す、人間の操縦力がまだ問われると感じています。
エンジニアのお墨付きには何が含まれるのか？
エンジニアに残る価値は、採用してよいと判断した理由と、その判断が成り立つ条件を説明できることだと考えます。名前だけの承認では、非エンジニアの不安は別の人に移るだけです。
文章が整っていることと、自社の条件で採用してよいことの間には、専門的な判断があります。冒頭の弁護士の例も、私が専門家の確認を頼りにしたいという感覚です。
ソフトウェアでも、テスト成功やAIの問題なしという報告だけでは答えきれない問いがあります。仕様で許した操作が、本当に業務で許してよい操作なのか。障害が起きたときの損失を、会社として受け入れられるか。前者は技術と業務をつなぐ確認、後者は経営を含む判断になります。
サイバー攻撃が変える、公開への確信
AIで非エンジニアもサービスを作り、公開できるようになった一方で、本当にインターネットに出して大丈夫なのかという不安は残ります。AIによる攻撃の報告に触れると、作れることと安心して運用できることの距離が、かえって広がったようにも感じます。
たとえばAnthropicは2025年11月の報告で、Claude Codeを悪用した攻撃者が約30の対象への侵入を試み、一部で成功したと説明しています。これは同社が観測した事例ですが、AIを使う側が開発者だけではないことを考えさせられます。
私は、ここでエンジニアに求められる技能がもう一段変わると見ています。認証や権限、秘密情報の扱い、公開範囲といったリスクを検証し、どこまで確認できたかを説明できる人が、公開判断を支える。コードを書けるというだけでは、その役割は果たしにくくなります。
セキュリティの知識がないエンジニアは、このお墨付きを求められても応えられない。そこを学び直せるかが仕事の選ばれ方を変え、淘汰にもつながるのではないかと思います。お墨付きは絶対安全の保証ではなく、専門家が根拠と残るリスクを示して判断を支えることです。
私は、専門家が次のように説明できる状態を目指したいです。
| 説明すること | 内容の例 |
|---|---|
| 判断の対象 | この変更と、この版の成果物について確認した |
| 確認の根拠 | 他社データへのアクセス拒否を試験し、結果を記録した |
| 確認できていない条件 | 本番相当の最大負荷は未検証である |
| 採用条件 | 対象を限定して公開し、異常時は機能を止める |
これは私が提案する説明の例で、製品の検証実績ではありません。確認対象の版が変われば根拠も再確認する必要があります。昨日のテスト結果を、今日追加された変更のお墨付きには使えません。
責任の分担も、エンジニア一人の無制限の保証にしないことが大切です。技術担当は確認の妥当性を説明し、事業責任者は残るリスクと費用を踏まえて採用を決める。運用担当は異常時の対応を引き受ける。小さな組織で一人が兼ねる場合も、それぞれ何を決めたかは残せます。
公開後の検証と停止判断
ソフトウェアのお墨付きは、一度の承認で終わらせず、稼働後の観測で更新できます。ここは契約書の比喩だけでは伝えきれない部分です。
GoogleのSRE Workbookでは、変更を一部へ一定期間だけ展開し、評価してから展開を進める方法を説明しています。こうした段階リリースを使えば、全利用者へ一度に影響を広げる前に判断する機会を作れます。
たとえば申請承認機能なら、私なら以下の流れを検討します。これは設計例であり、実測した運用手順ではありません。
- 期待する動作を決める。 誰が承認でき、誰の情報を見られるかを事業担当と確認する。
- AIで検証を回す。 実装、権限の否定テスト、修正、再実行をつなぎ、確認した版と結果を残す。
- 人が体験と根拠を確認する。 操作を取り消せるか、承認対象を誤認しないか、未検証の条件は何かを見る。
- 範囲を限定して公開する。 失敗率や誤操作の報告を監視し、誰が止めるかを決めておく。
ただし、他社のデータが見える不具合を、本番で少人数に試して発見すればよいとは考えません。事前に止めるべき問題と、公開後の観測で確かめられる問題は分けます。データの書き換えが伴う場合には、コードを戻すだけで復旧できるかも確認が必要です。
AIが実装と同じ仕様の読み違いをテストにも持ち込むと、両方が通ってしまう可能性があります。別のAIにレビューさせる工夫に加え、業務から決めた受け入れ条件や、実行結果との突き合わせが要ります。AIの人数を増やしたこと自体を、独立した根拠として数えないようにしたい。
まとめ
コード生成、レビュー、テスト、修正依頼は、できるだけAIに任せたい。その目標を持ちながら、人間は予算や将来を踏まえた戦略と技術選定、利用者が触る体験に集中する。これが今の私の考えです。
私は、AIによる攻撃への備えが、エンジニアの役割をもう一段変えるのではないかと見ています。お墨付きを求められるとしても、毎回すべてのコードを目で読む仕事と同じ形ではないでしょう。何を確かめれば採用できるかを決め、確認の根拠と限界を説明し、公開後も判断を更新できることに価値が移ると見ています。
ZenChAIneでも、AIを使う開発の話を、生成速度だけで終わらせず、事業として採用できる条件まで含めて考えていきます。