Skip to Content
Docs08. コーディングエージェント要件定義・設計工程での活用
中級se-practicerequirementsdesign-docs更新: 2026-10-04この記事の誤りを報告

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

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

要件定義・設計工程での活用

この記事の目的

企業システム開発の上流工程(要件定義・基本設計・詳細設計)で、AI コーディングエージェントコードベースを読み、ファイルを編集し、コマンドを実行して検証するループで開発タスクを遂行する Agent。コード補完と異なり「タスク単位の委任」を受けられる。を抜け漏れ観点出し・設計書ドラフト・整合性チェック・図の生成に使い分けられるようになります。あわせて、日本の SE 実務で避けて通れない「Excel 設計書文化」への現実的な向き合い方と、上流で機微情報を扱うときの守り方を持ち帰れる状態を目指します。レビューの厚さは影響範囲・可逆性・検出の難しさで決めるため、「発散はエージェント・確定は人」をどう具体化するかが主題です。

対象読者

  • 要件定義・設計を担当し、設計書などのドキュメント成果物に品質責任を負う SE
  • 上流工程で AI を使いたいが、「顧客業務の誤解」や「設計書の形式(Excel)」がネックで踏み出せていない設計担当

前提知識

本文

概要: 上流での使いどころと分担

上流工程での AI 活用は、「広げる作業をエージェントに任せ、決める作業を人が握る」の具体化です。ユースケース発見と要件定義 は Agent 案件の要件化を扱います。一般的な要件定義全体の方法論(ヒアリング手法など)は範囲外で、本記事は各活動でエージェントをどう使うかに絞ります。

上流の活動エージェントの役割(発散・下書き)人の役割(確定・責任)
要件の抜け漏れ確認観点出し・質問リスト・矛盾の指摘要件の確定・顧客合意
設計書作成既存コード/過去案件からのドラフト方式決定・非機能・設計責任
設計レビュー整合性チェック・観点提示指摘の採否・最終レビュー
図の作成Mermaid での構成図・シーケンス図内容の正しさの担保

要件の壁打ちと抜け漏れ観点出し

要件定義では、**「抜けている観点を挙げさせる」**使い方を導入候補にします。以下は本記事の役割分担案で、効果は自社の要件とレビュー時間で確かめます。

  • 観点出し・質問リスト: 要件のドラフトを渡し、「考慮漏れがありそうな点・確認すべき質問」を列挙させます。異常系・非機能(性能・可用性・セキュリティ)・移行・運用など、忘れがちな観点の洗い出しに向きます
  • 矛盾・曖昧さの指摘: 要件記述を読ませ、矛盾する記述・多義的な表現を指摘させます。人が読み飛ばす整合性の穴を拾う補助になります
  • 確定は必ず人と顧客が: 出てきた観点は候補です。どれが本案件で必要か、顧客業務の実態に照らして決めるのは人です。とくにエージェントは知らない業務を「もっともらしく」補完するため、業務固有の前提は鵜呑みにしません

設計書ドラフトの生成

設計書ではドラフトを生成して直す方法を試せます。誤りの確認・修正にかかる時間も含め、白紙から書く方法より有効かを比較します。

設計レビュー支援

人のレビューを置き換えるのではなく、レビュー前に機械的な穴を減らす使い方が有効です。

  • 整合性チェック: 要件と設計、基本設計と詳細設計、設計書とコードの間の食い違いを指摘させます。人手では見落としやすい横断的な不整合の一次スクリーニングに向きます
  • 観点レビュー: 「この設計をセキュリティ/性能/運用の観点で見て、懸念を挙げて」と観点を指定してレビューさせます。レビュー会議前の準備として、論点を洗い出せます
  • 最終責任は人のレビュー: エージェントの指摘は論点の提示であり、採否とレビュー承認は人が行います。指摘の中には的外れ・過剰なものも混じるため、そのまま設計変更の根拠にはしません

図の生成(Mermaid)

構成図・シーケンス図・フロー図は、テキストから図を生成できる Mermaid と相性が良い領域です。

  • テキストから図へ: 設計内容の説明から、Mermaid の構成図・シーケンス図・状態遷移図を生成させます。図の下書きを速く作り、細部を人が直します
  • 本ライブラリでも Mermaid が第一選択: 図をコードで管理でき、差分レビュー・修正が容易です。生成 → 修正 → レビューのサイクルが回しやすい形式です
  • 図の正しさは人が担保: 生成された図は、設計意図と一致しているかを人が確認します。もっともらしいが誤った関係線が引かれることがあります

ドキュメント形式の壁への現実解(Excel 設計書文化)

日本の企業システム開発では、設計書が Excel/Word で、しかも顧客指定の書式であることが多く、これが AI 活用の実務的な壁になります。現実解は「正本をテキストに寄せる」段階論です。

  • 段階論で考える: いきなり全設計書を Markdown 化するのではなく、①テキストで書ける中身(処理説明・項目定義・観点)はエージェントで作り、②最終成果物の**体裁(Excel)**への転記は変換・貼り付けで対応、という二段構えにします
  • 正本をテキストに寄せる: 可能な範囲で「設計の正本は Markdown、Excel は提出用の派生」に寄せると、生成・レビュー・差分管理が効きます。全面移行が無理でも、新規作成部分から寄せられます
  • 既存 Excel の読み取り: 既存設計書を読ませたいときは、スクリーンショットからの読み取り(マルチモーダルモデルの仕組みの画像入力)や、テキスト/CSV への書き出しを介します。ただし細かい表・結合セルは読み取り精度が落ちるため、重要箇所は人が確認します
  • 形式変換ツールの個別解説は範囲外: 本記事は「正本をテキストに寄せる」原則と段階論までを示します。特定の Excel 変換ツールの手順は各ツールのドキュメントに委ねます

上流での機微情報の扱い

要件・設計工程は、顧客業務の生々しい情報が最も集まる工程です。ここでの情報の扱いは、経路を決めてからにします。

  • 顧客名・業務データのマスキング: 観点出し・ドラフト生成のために要件を渡すとき、顧客名・個人情報・実データは、判断に不要ならマスキング・抽象化してから渡します
  • 経路を先に決める: そもそも顧客の要件・設計情報をどのツール経路で扱ってよいかは、契約と提供形態で決まります(詳細は本シリーズの企業システム制約の記事、および技術的防御は 権限・秘密情報・破壊的操作への対策)
  • 抽象化しても価値が出る: 業務の具体を伏せても、「観点の網羅性」「矛盾の指摘」「設計テンプレートの充足」といった発散作業は成立します。まず抽象化した使い方から始めます

実務での注意点

アンチパターン

  • エージェントの観点出しを要件確定に使う → 顧客業務を知らないモデルの補完を要件にしてしまう → 観点は候補として扱い、確定は人と顧客で行う
  • 設計書ドラフトの断定を鵜呑みにする → 方式・非機能の根拠なき断定が既存方式と衝突する → 方式決定・非機能は人が決め直す
  • AI レビューを人のレビューの代わりにする → 的外れな指摘の混入と、承認責任の空洞化 → AI 指摘は論点提示に留め、承認は人のレビューで
  • 全設計書をいきなり Markdown 化しようとする → 顧客指定書式・既存資産との齟齬で頓挫する → 中身から段階的にテキストへ寄せ、体裁は変換で対応する
  • 顧客情報を経路確認前に渡す → 契約・データ保護の観点で問題になる → マスキングと経路確定を上流着手前に行う

チェックリスト

  • 要件の観点出し・矛盾指摘を「候補」として扱い、確定は人と顧客で行っている
  • 設計書はドラフト生成 → 人が方式・非機能を決め直す運用にした
  • AI レビューの指摘を論点提示に留め、最終レビュー承認は人が行っている
  • 図(Mermaid)の内容の正しさを人が確認している
  • 設計の正本をテキストに寄せる段階論を決め、Excel は派生・提出用と整理した
  • 顧客名・業務データのマスキングと、ツール経路の確認を上流着手前に済ませた

関連トピック

参考資料

  • About Mermaid  — テキスト定義から図を生成する仕組み。図の業務上の正しさや工数削減を保証する資料ではありません(アクセス日: 2026-09-10)
  • Application card: GitHub Copilot Chat  — 生成内容の誤りとレビュー・検証の必要性。要件・設計への活動割り当てと正本移行の段階論は本記事の独自整理です(アクセス日: 2026-09-10)

TODO・未確認事項

なし

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