AI駆動開発のエンジニアの役割 シニアが手放さない6つの判断
要約： AIがコードの大半を書く案件でも、VAONのシニアエンジニアは6つの判断を手放しません。範囲、アーキテクチャ、トレードオフ、業務ルールに合っているか、どのセキュリティ指摘が本物か、そしてリリースの可否です。下書きや確認の速さはAIが担います。CTOとテックリードは、すべての案件に関わります。
目次
- AIが書いたコードは、誰が確認するのか
- シニアエンジニアが手放さない判断は何か
- 工程ごとに、AIが得意なこととシニアが持つ判断
- なぜ、その判断をAIに任せないのか
- 基本設計書のレビューをAIに任せてみて、何が分かったか
- シニアの判断は、発注側からどう確かめられるのか
- シニアエンジニアがいても足りない場合
- よくあるご質問
1. AIが書いたコードは、誰が確認するのか
VAONでは、AIが書いたコードを複数の工程で人が確認し、影響の大きい判断はシニアエンジニアが最終的に下します。CTOとテックリードは、すべての案件に関わります。
2026年にお客様からいただいた質問で特に多かったものの一つが、「AIが書いたコードは誰が確認するのですか」でした。「人がレビューしています」だけでは、十分なお答えになりません。その人が何を判断し、どんな根拠をもとに判断しているのかまで、お伝えする必要があると考えています。
この記事は、Claude Codeを使った開発フローのうち、「人が判断すること」の列を詳しく説明するものです。10ステップのフローは多くの案件で適用している基準ですが、すべての案件ではまだありません。一方、CTOとテックリードの関与、レビューとテストの記録、プルリクエストごとの自動チェックは、すべての案件で行っています。
2. シニアエンジニアが手放さない判断は何か
VAONのシニアエンジニアが手放さないのは、間違えると影響が大きく、しかもAIには判断の材料が足りない、次の6つです。
- 範囲：今回のフェーズで何を作り、何を後に回すか。推測で埋めずにお客様に確認すべき点はどれか。
- アーキテクチャ：システムをどう分け、データをどこに置き、どこを後から差し替えやすくしておくか。
- トレードオフ：箇所ごとに速さと確実さのどちらを取るか。理由も書き残します。
- 業務ルールとの整合：動くコードが、貴社の業務ルールに合っているとは限りません。
- セキュリティ指摘の真偽：AIによるセキュリティ確認には誤検知があり、見逃しもあり得ます。
- リリースの可否：テスト、レビュー、お客様の受入テスト、セキュリティ確認の結果をもとに決めます。
6つに共通するのは、判断の根拠がソースコードの外にあることが多い点です。お客様との打ち合わせの中や、現場の実際の仕事の進め方の中にあります。
3. 工程ごとに、AIが得意なこととシニアが持つ判断
どの工程でも、下書きと確認はAIが速く進め、判断はシニアが持ち、判断の前に根拠を求めます。開発フローの記事にある簡略版の表に、「シニアが求める根拠」の列を加えると次のようになります。
| 工程 | AIが得意なこと | シニアが持つ判断 | シニアが求める根拠 |
|---|---|---|---|
| 依頼内容の整理 | 確認事項、曖昧な点の洗い出し | どれをお客様に確認し、どれを外すか | 絞り込んだ確認事項リスト |
| 仕様確定 | 議事録からの要件定義書の下書き | 今回の範囲と、後に回すもの | お客様に書面で合意いただいた要件定義書 |
| 基本設計 | 書類間の不整合、エラー処理の抜けの発見 | 業務ルール、優先度 | 対応済みの指摘、または対応しない理由 |
| 実装計画 | 作業分割、対象ファイル、リスクの洗い出し | アーキテクチャ、順序、トレードオフ | レビューを経た計画 |
| 実装 | コード、単体テスト、E2Eテストの作成 | 業務ルールに合っているか | 実行したコマンドとテスト結果 |
| プルリクエストのレビュー | プロジェクトの観点に沿った変更の確認 | どの指摘を直し、どれを見送るか | レビュー記録 |
| セキュリティ確認、リリース | すべての変更の確認 | どの指摘が本物か、リリースするか | 確認結果、キャプチャ付きの受入テスト結果、リリースノート |
いちばん右の列は、あまり語られない部分です。Claude Codeのベストプラクティスのページは、AIに根拠を出させるよう勧めています。実行したコマンドとその出力、または画面のスクリーンショットです。「すべてのテストが通りました」という報告だけでは、ほとんど何も分からないとも書かれています。シニアが読むのは、AIの自己申告ではなく根拠のほうです。
4. なぜ、その判断をAIに任せないのか
判断をAIに任せない理由は、判断の根拠が、AIが読める範囲の外にあることが多いからです。Claude Codeのドキュメント自体が、リポジトリを読んでもAIには分からないものとして、「チームが会議で決めたこと」を挙げています。
説明用の例を挙げると、貴社の決裁の決まりや、ある機能を次のフェーズに回した理由です。誰かが書き残さない限り、AIはそれを知りようがありません。
もう一つの理由は、レビューそのものにあります。同じページには、「問題を探すよう頼まれたレビュアーは、必ず何かを見つける」とあります。指摘をすべて直すと、不要な抽象化や、起こり得ないケースのためのテストが増えてしまいます。どの指摘を直すべきかは、システムと業務の両方を分かっている人が選ぶ必要があります。
責任の点もあります。責任の範囲は案件ごとの契約で定めるもので、VAONは「AIが書いた」ことを理由に責任の範囲が変わるとは考えていません。
5. 基本設計書のレビューをAIに任せてみて、何が分かったか
VAONでは、社内のプロジェクトで、基本設計書のレビューに大規模言語モデル（LLM）を使ってみました。お客様の案件ではありません。結果は、はっきり二つに分かれました。
LLMの指摘がそのまま役に立ったのは、書類間の不整合、エラー処理や境界値の抜け、非機能要件の基本的な記載、表記や用語のゆれの4つでした。一方で、業務ルールが妥当かどうか、優先度とトレードオフ、実際の運用の3つには、人の判断が必要でした。
そこで、LLMが1次レビューを行い、人は業務の観点のレビューに集中する、という分担に決めました。私たちの理解では、前者は書類の中だけで正しさを確かめられ、後者は書類の外にある事情を知らないと判断できません。この試みでは指摘の件数を数えていないため、数字は出していません。
6. シニアの判断は、発注側からどう確かめられるのか
シニアの判断は、約束ではなく記録で確かめていただけます。「AIは速度を上げ、シニアは基準を守る」という言葉は、誰が何を判断したかが見えて、はじめて意味を持ちます。
VAONでご覧いただけるものは、次のとおりです。
- レビューとテストの記録。すべての案件で保存しています。
- プルリクエストごとの自動チェック（シークレットスキャン、依存関係のスキャン、静的解析）の結果。すべての案件で動かしています。
- 技術的な判断の理由を書いた引き継ぎ資料。知識が一人に偏らないようにするためのものです。
各プルリクエストが、セルフレビュー、AIによるレビュー、別の担当者によるレビューを経る流れは、AIが書いたコードのレビュー手順でご紹介しています。リリース前の確認は、AIが書いたコードのリリース前セキュリティチェックをご覧ください。お客様の手元に残る根拠としては、受入テストのチェックリストと画面キャプチャがあります。
7. シニアエンジニアがいても足りない場合
シニアエンジニアがいても、お客様側で業務を知っている方の代わりにはなりません。ほかにも、次のような限界があります。
- シニアが詳しいのはシステムで、貴社の業務ではありません。業務の質問に答えられる方がいなければ、「業務ルールに合っているか」の判断は推測になります。
- ソースコードをAIツールに入れることへのご許可がない場合、AIによるレビューとAIによるセキュリティ確認は行いません。自動チェックと人による確認だけになります。
- 基本設計書のLLMレビューは、社内のプロジェクトでの試みです。お客様の資料に使う場合は、事前にご許可をいただきます。
- VAONの正社員は15名です。短期間に数十名が必要な案件は、お引き受けできない場合があります。
8. よくあるご質問
CTOとテックリードは、どの程度関わるのですか？ CTOとテックリードは、VAONのすべての案件に関わります。10ステップのフローでは、テックリードが実装計画を承認し、計画のレビュー後に何を直すかを決めます。マージはチームリーダーが判断します。仕様確定フェーズは、BrSE（ブリッジSE）とテックリードが進めます。
AIが書いた変更は、すべてシニアが読むのですか？ すべてのプルリクエストは、作成者以外の担当者が読んでからマージします。メインブランチは保護しており、レビューなしではマージできません。そのうえで、セルフレビュー、AIによるレビュー、自動チェックが加わります。マージとリリースの判断は、常に人が行います。
AIとシニアエンジニアの評価が分かれたら、どうなりますか？ AIの出力は判断の材料であり、結論ではありません。判断するのはシニアで、その記録はレビュー記録としてご覧いただけます。セキュリティの指摘では、結果を読む担当者が本物の指摘と誤検知を分けます。仕様書から答えが出ない業務上の問いは、推測せずにお客様に確認します。
発注側は、これらの判断にどう関われますか？ お客様が決めるべきことは、お客様に決めていただきます。要件は開発に入る前に書面で確定します。範囲外の作業は、費用と納期への影響をご承認いただいてから着手します。毎週の報告で、進捗、リスク、お客様にご判断いただきたい事項をお伝えします。最後に、リリース前に受入テストを行っていただきます。
AIを多く使う場合、不具合の責任は誰にあるのですか？ 責任の範囲は、案件ごとの契約で定めます。VAONは「AIが書いた」ことを理由に責任の範囲が変わるとは考えていません。AIが書いたコードも、人が書いたコードと同じレビュー、テスト、セキュリティ確認を通ります。問題が起きたときには、双方がレビュー、テスト、受入テストの記録をもとに話し合えます。
今日からできることが一つあります。いま開発を依頼している会社に、「直近のリリースは誰が判断しましたか。その方は何を根拠に判断しましたか」と尋ねてみてください。担当者の名前と記録の名前が返ってくれば、誰が基準を守っているのかが分かります。
貴社の案件で、これらの判断を誰が持つことになるのか、無料相談（60分）でご説明します。CEOが同席します。資料のご準備は不要で、ご契約を前提としたものではありません。
執筆者： ダン・ヴァン・ルアン（Đặng Văn Luân）、VAON 創業者・CEO。ハノイ工科大学 HEDSPI 卒業。FPT Softwareを経て、Digital Plus（東京）で5年間、1,000万人が利用するシステムの開発に携わる。その後8年間、従業員120名のITアウトソーシング企業でCOOを務め、ISO 9001・ISO 27001に基づく管理体制を構築。業界経験15年。
参考資料
- Claude Code Docs「Best practices for Claude Code」：https://code.claude.com/docs/en/best-practices（2026年10月29日確認）
