要件定義をAIが下書きし、Claudeが実装する — 発注側が知っておく「AI前提の開発」の進め方 | GH Media
URLがコピーされました

要件定義をAIが下書きし、Claudeが実装する — 発注側が知っておく「AI前提の開発」の進め方

URLがコピーされました
要件定義をAIが下書きし、Claudeが実装する — 発注側が知っておく「AI前提の開発」の進め方

「見積もりを取ったら、以前の半分の工数で出てきた。うれしい反面、本当に大丈夫なのか判断がつかない」——外部にシステム開発を頼む立場の方から、最近こうした戸惑いをよく聞きます。背景には、開発の進め方そのものが変わり始めていることがあります。人が一行ずつ書く前提が崩れ、要件の下書きや実装の一部をAIエージェントが担う「AI前提の開発」が現実の選択肢になってきました。

象徴的なのが、多くの開発チームが使う課題管理ツールJiraの動きです。AIが要件定義を自動で下書きし、洗い出したタスクをClaude CodeやGitHub CopilotといったAIコーディングエージェントに割り当て、レビュー可能なプルリクエストまで生成する機能が入りました。手段の比較より先に発注者が押さえるべき勘所はAIエージェント時代にノーコード/ローコードから入らない理由でも触れましたが、本記事は「開発を外注する側」が、この変化にどう向き合うかに絞ります。

何が変わったのか — 「タスクの担当者」に人以外が並ぶ

これまで開発は、人が要件を読み、人が設計し、人がコードを書く、という流れが前提でした。Jiraの新しい仕組みでは、その一部が置き換わります。

  • 要件定義の下書きをAIが作る:ざっくりした要望から、やるべきタスクの一覧をAIが洗い出す。
  • タスクの担当者にAIエージェントを指名できる:担当者の選択肢にClaudeなどが並び、コメントで呼び出したり自動ルールで割り当てたりできる。
  • エージェントがプルリクエストまで作る:受け入れ基準や対象リポジトリを読み取り、隔離された環境でコードを変更し、レビュー可能な形で提出する。

対応するツールはClaude Code、Cursor、GitHub Copilotなどで、OpenAIのCodex対応も予告されています。ポイントは、「人が書いたものをAIが手伝う」から「AIが書いたものを人がレビューする」へ、重心が移り始めたことです。開発チームの実際のループ設計はClaude Codeを使った開発ワークフローでも扱っています。

発注する側にとって、何が良くて何が怖いのか

この変化は、発注者に恩恵とリスクの両方をもたらします。

観点良い面注意すべき面
スピード実装の初速が上がり、試作が早く出る「速い=完成」ではない。検証工程は減らない
コスト単純作業の工数が下がる余地安い見積もりが品質担保込みとは限らない
要件下書きが早く出て議論を始めやすいAIの下書きは叩き台であり、正しさは人が保証する

とくに気をつけたいのは、要件定義をAIが下書きすると、それらしい文書がすぐ出てくるがゆえに、中身を吟味しないまま進んでしまうことです。要件が曖昧なまま実装が走ると、後戻りのコストはむしろ増えます。作り込みすぎを避ける発注の考え方は過剰な作り込みを避けるスコープ設計にまとめたとおりで、AIが下書きを出す時代でも、「何を作らないか」を決めるのは人の仕事です。

AI前提の開発で、発注者が握っておくべき三つ

作り方が変わっても、発注する側の責任範囲は消えません。むしろ次の三つは、これまで以上に重要になります。

  1. 受け入れ基準を明確に渡す:AIエージェントは受け入れ基準や設計標準を読み取って動きます。基準が曖昧なら成果物も曖昧になる。「何ができたら完成か」を具体的に言語化して渡すことが、そのまま品質を左右します。
  2. レビューを軽く見ない:AIが速く大量にコードを出すほど、人によるレビューの価値は上がります。「AIが作ったから安心」ではなく、誰がどう検証したかを成果物の受け取り条件にする。
  3. どこをAIに任せ、どこを人が担ったかを説明できる相手を選ぶ:発注先が「AIで安く速く」だけを売りにしていないか。任せた範囲と、品質をどう担保したかを説明できるパートナーかどうかで判断します。

つまり発注者が見るべきは「AIを使っているか」ではなく、AIを使ったうえで最終的な品質に誰が責任を持つのかです。ここが曖昧な相手に、速さと安さだけで発注するのは危険です。

小さく試して、任せる範囲を見極める

いきなり基幹システムをAI前提で発注するのではなく、小さく確かめるのが安全です。まずは影響の小さい機能や社内ツールで、要件の下書きから実装、レビューまでを一巡させ、成果物の質と説明の丁寧さを見る。そこで信頼できると判断できてから、任せる範囲を広げていきます。この「小さく試して広げる」進め方自体は、AIに限らず外注全般に効く基本です。

まず、次の発注で「完成の定義」を一行書く

AI前提の開発は、発注者から仕事を奪うものではありません。奪われるのは単純作業で、残るのは「何を作るか」と「何をもって完成とするか」を決める仕事です。次に何かを外注するとき、要件書の前に「これができたら完成」という一行を自分の言葉で書いてみてください。その一行の明確さが、AIを使う開発でもそのまま成果物の質になります。

AIを取り入れた開発をどう発注すればいいか、見積もりの妥当性をどう判断するか、品質担保の体制をどう確認するか——そうしたご相談は、グリームハブの開発・AI・自動化のご相談からどうぞ。要件の言語化から、AIをどこまで使い、どこを人が保証するかの設計まで、御社の案件に即してご一緒します。

Sources

URLがコピーされました

グリームハブ株式会社は、変化の激しい時代において、アイデアを形にし、人がもっと自由に、もっと創造的に生きられる世界を目指しています。

記事を書いた人

鈴木 翔

鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

関連記事

「TECH」の記事一覧を見る