Skip to Content
Docs08. コーディングエージェントSE 工程別活用マップ(V 字モデルで見る使いどころ)
初級se-practicesoftware-processv-model更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

SE 工程別活用マップ(V 字モデルで見る使いどころ)

この記事の目的

企業システム開発のシステムエンジニア(SE)が、要件定義から保守までどの工程で AI コーディングエージェントコードベースを読み、ファイルを編集し、コマンドを実行して検証するループで開発タスクを遂行する Agent。コード補完と異なり「タスク単位の委任」を受けられる。が効き、どこで効かないか・何を人が握るかを 1 枚で見渡せるようになります。ここを起点に、自分の工程の詳細記事へ進める「シリーズの地図」です。読み終えたとき、工程ごとの向く作業・向かない作業・外してはいけない責任の線引きを、自分のプロジェクトに当てはめて判断できる状態を目指します。

対象読者

  • 実装だけでなく要件定義・設計・テスト・保守運用まで担う、日本の企業システム開発(SIer・情報システム部門)の SE
  • 「コーディング以外の工程で AI をどう使えるか」を工程全体で整理したいプロジェクトリーダー・リーダー格の SE

前提知識

本文

概要: このシリーズの地図

本記事は「SE 実践シリーズ」の背骨です。既存の 08 章が「エージェントを使う開発者」の視点で選定・設定・依頼設計・セキュリティ・チーム導入を扱うのに対し、本シリーズは日本の企業システム開発の工程と商流に軸を移します。各工程の詳細は個別記事に譲り、ここでは全体像と共通原則、そして「自分の工程からどこへ進むか」を示します。

このシリーズの前提: 本記事群は「エージェントを作る」話ではなく「保守・開発対象のシステムに、コーディングエージェントを道具として使う」話です。ツール選定・権限設計などの基礎は既存 08 章が正本です。

全工程に共通する原則

工程を問わず、SE の実務で AI コーディングエージェントを使うときに貫く原則があります。

  • 成果物の確認責任を定める: 本シリーズでは、設計書・テスト仕様書・エビデンス・納品コードをレビューして確定する担当者を置きます。法的な責任分担は契約・適用法に基づいて別途確認し、エージェントを使ったことだけで確認工程を省きません
  • 発散はエージェント、確定は人: 観点出し・候補列挙・下書きといった「広げる作業」はエージェントが得意です。取捨選択・整合性判断・顧客合意といった「決める作業」は人が握ります
  • 現行挙動は観測事実として確認する: 保守・レガシー理解では、生成された仕様説明を実際の挙動に照合します。ただし現行実装にも不具合がありえます。「動いていること」と「要求どおりであること」を分け、要件・契約・既知の不具合に照らして判断します
  • 機微情報は経路を先に決める: 顧客名・業務データ・ソースコードをエージェントに渡してよいかは、工程に入る前に契約と経路で判断します(詳細は本シリーズの企業制約の記事)
  • 効率化の効果は測ってから主張する: 「速くなった」は体感でなく、コーディングエージェントの評価の考え方で工程ごとに確かめます

工程別マップ(V 字モデルで見る)

V 字モデルの各工程に沿って、向く作業・向かない(人が握る)作業・主なリスクを一望します。

SE 工程別活用マップ(V 字モデルで見る使いどころ): 工程別マップ(V 字モデルで見る)の図SE 工程別活用マップ(V 字モデルで見る使いどころ): 工程別マップ(V 字モデルで見る)の図
SE 工程別活用マップ(V 字モデルで見る使いどころ): 工程別マップ(V 字モデルで見る)の図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

SE 工程別活用マップ(V 字モデルで見る使いどころ): 工程別マップ(V 字モデルで見る)の図SE 工程別活用マップ(V 字モデルで見る使いどころ): 工程別マップ(V 字モデルで見る)の図
工程向く作業(発散・下書き)人が握る作業(確定・責任)主なリスク
要件定義抜け漏れ観点出し・質問リスト・用語整理要件の確定・顧客合意・優先順位顧客業務の誤解を「もっともらしく」補完
基本・詳細設計設計書ドラフト・構成図/シーケンス図・整合性チェック方式決定・非機能要件・設計責任既存方式との不整合、根拠なき断定
実装コード生成・リファクタ・定型実装(既存 08 章が正本)設計意図の担保・レビュー・マージ判断動くが設計から外れたコード
テスト観点表・テストケース/データ・エビデンス整理テストの妥当性判断・品質保証責任生成コードを生成テストで検証する自己参照
保守・運用障害調査支援・影響調査コードやデータへの変更が、システムのどこに波及するかを事前に洗い出す作業。レガシー保守で特に重要。AI コーディングエージェントは波及範囲の「当たり付け」に使えるが、動的呼び出しやコード外連携(バッチ・DB トリガ・外部システム)を追い切れないため、「影響なし」の保証には使わない。・経緯復元・ドキュメント追従本番判断・恒久対策の決定本番データ/環境の境界越え、現行挙動の誤認

このマップは、**「エージェントに広げさせ、人が絞る」**という本記事の役割分担案です。V 字は成果物と検証の対応を示すもので、手戻り費用や検出率を証明する図ではありません。誤りの影響と検出しやすさは、変更範囲・リスク・検証手段で評価します。

ウォーターフォールとアジャイルの読み替え

V 字モデル(ウォーターフォール)を軸に整理していますが、アジャイル・反復開発でも中身は同じです。

  • アジャイルでは、同じ「要件 → 設計 → 実装 → テスト」の活動が短い反復で回るだけで、各活動でのエージェントの向き不向きは変わりません
  • 反復が速いぶん、「発散はエージェント・確定は人」の切り替えが1 日に何度も起きます。ドラフトの回転数が上がるほど、レビューの負荷管理(チーム導入とレビュー体制)が効いてきます
  • ウォーターフォールでは工程間の**成果物(設計書・テスト仕様書)**が重く、後述の要件・設計記事の「ドキュメント形式の壁」への対応が重要になります

自分の工程から始める

このシリーズは、自分の担当工程の記事から読み始められます。

まずは自分の工程で「発散に使う小さなタスク」から試し、成果物責任の線を保ったまま範囲を広げるのが、SE 文脈での安全な入り方です。

実務での注意点

アンチパターン

  • 工程を問わずエージェントに「決めさせる」 → 要件・設計・テスト妥当性の判断まで委ね、品質責任の所在が曖昧になる → 「発散はエージェント・確定は人」を全工程で固定する
  • 上流の誤りを下流で気づく前提で進める → 要求の誤解が広く波及する場合がある → 工程名ではなく、影響範囲・可逆性・検出の難しさでレビューを厚くし、根拠を人が裏取りする。本番操作や機密データ処理も同じ基準で扱う
  • 効率化を体感で語る → 「AI で速くなった」を測らずに顧客・上長へ主張し、後で齟齬が出る → 工程ごとに効果を測ってから示す
  • 機微情報の経路を決めずに使い始める → 顧客コード・業務データを承認前にツールへ渡してしまう → 工程に入る前に契約と経路(本シリーズの企業制約記事)を確定する

チェックリスト

  • 自分の担当工程で「向く作業(発散)」と「人が握る作業(確定)」を仕分けた
  • 各工程の成果物(設計書・テスト仕様書・コード)の品質責任が人にあることを明文化した
  • 影響範囲・可逆性・検出の難しさに応じて、工程を問わずレビュー・裏取りを厚くした
  • 既存システムの実測挙動・合意した要求・生成された仮説を区別した
  • エージェントに渡してよい情報の経路を、工程着手前に決めた
  • 効率化の効果を工程ごとに測る仕組みを用意した

関連トピック

参考資料

TODO・未確認事項

なし

GitHub Copilot 実践ガイド要件定義・設計工程での活用