「こっちで AI で作るから」と言われたときの、エンジニアリングの価値の示し方

私の周りの会社で、エンジニアではない人が AI と GAS、スプレッドシートを使って、顧客が利用する Web サービスを作り、公開していました。エンジニアが直接実装しなくても、顧客に触れるプロダクトを形にできるところまでは来ています。

それを見れば、「これまでエンジニアに頼んでいた実装のかなりの部分を AI で代替できる」と考えるのは自然です。文章を渡せば画面ができ、コードが生成され、実際に動く。外から見える成果だけを見れば、そう感じるだけの材料があります。

一方で、AI を日常的に開発へ組み込んでいるエンジニアを見ると、少し違う景色があります。少なくとも私の周囲では、AI に仕事を奪われるという感覚はあまりなさそうです。むしろ、これまで実装に割いていた時間を、要求の読み解きや仕様の詰め、設計の見直し、影響範囲の確認、運用の検討に回せるようになった、便利な道具として使っている人が多い。

同じ AI を見ているのに、エンジニアには「仕事のレイヤーを上げる道具」に見え、非エンジニアには「エンジニアを減らせる道具」に見える。

もちろん、すべてのエンジニアや非エンジニアがそう考えているという話ではありません。私が気になっているのは、この認識差が生まれる構造です。

この認識差は、現場によっては「こっちで AI で作るから」という一言になって現れます。エンジニアがすでに関わっているチームで、実装を事業側が AI で進めると言われたとき、エンジニアは何を担い、どう価値を示せばよいのか。

ここで難しいのは、非エンジニアが「判断できない」わけではないことです。代表的な操作が一度通れば、「動いた」「公開できそうだ」と判断することはできます。むしろ、粗い解像度のままでも、人は普通に判断できてしまいます。

では、エンジニアリングが加わることで何が変わるのでしょうか。

この記事では、エンジニアが普段当たり前にやっている要求の読み解き、仕様化、設計、レビュー、検証、運用を一度ばらして、その共通する価値を考えます。

「作れる」は本当に安くなった

まず、「AI で作れるようになった」という前提自体は正面から認めた方がよいと思っています。

DORA の2025年調査では、AI の役割を、組織がもともと持つ強みや弱みを増幅するものとして整理しています。2026年のDORA の分析では、2025年調査の技術職の90%が仕事で AI を利用し、80%以上が生産性向上を感じていると報告されています。

同じ DORA の定性分析では、AI が初期コード生成を速め、新しいタスクを始める摩擦を下げる一方、作成で節約された時間が監査や検証へ再配分される場面も報告されています。

これは私の実感とも重なります。以前ならコードを書くところから始めていた作業を、AI に最初の実装や変更案まで進めてもらい、人間はその前後に時間を使う。

だから、「本当の開発は AI ではできない」と言うだけでは、現状をうまく説明できません。

要求をコードへ変え、一通り動く状態まで持っていくコストは下がっている。ここを出発点にした方が、エンジニアリングの価値を考えやすくなります。

コードに包まれていたエンジニアリング

エンジニアリングの価値がコードそのものと強く結びついて見えていたのは、ある意味で自然です。

外から見えやすい成果は、画面が増える、API がつながる、処理が速くなる、機能が公開される、といった「動くもの」です。エンジニアに依頼し、その結果として新しい機能が動けば、「コードを書けること」が価値の中心に見えます。

ただ、実際の開発では、コードの前後に多くの仕事があります。IEEE のソフトウェア工学の用語集でも、ソフトウェア工学はソフトウェアの開発・運用・保守に体系的なアプローチを適用するものとして定義されています。コードを書くことは、その一部です。

これまでは、こうした仕事の多くが「エンジニアがコードを書いて機能を作る」という一つの成果に包まれていました。

flowchart TD
    A[エンジニアリング]
    A --> B[要求を読み解く]
    A --> C[仕様を具体化する]
    A --> D[構造を設計する]
    A --> E[実装する]
    A --> F[検証する]
    A --> G[運用を設計する]
    B --> H[外から見える成果<br>動く機能]
    C --> H
    D --> H
    E --> H
    F --> H
    G --> H

AI が実装部分を大きく圧縮すると、このまとまりがほどけます。コード生成のコストが下がったとき、それまでコードと一緒に見えていた仕様化、設計、検証、運用まで価値が下がったように見える。

私は、ここが認識差の一つの源だと思っています。

必要なのは、「コードを書く以外にもいろいろやっています」と説明することではなく、それぞれの仕事によって対象について何が分かるようになっているのかを示すことなのかもしれません。

「購入できる」だけでは、仕様は決まらない

たとえば、事業側が EC サイトの購入機能を AI で作ったとします。商品を1つ選ぶ。カートに入れる。住所を入力する。カードで決済する。完了画面が表示される。

これは間違いなく「購入できた」です。

ただ、「購入できる」という一文だけでは、ソフトウェアとして何を実現すべきかはほとんど決まっていません。

購入する人は新規利用者なのか、既存利用者なのか。商品は通常商品なのか、予約商品なのか。数量は1個なのか、複数なのか。通常価格なのか、クーポンが使われるのか。クーポンは会員割引と併用できるのか。決済に失敗したら在庫はどうなるのか。

エンジニアは、こうした問いを出すことで、粗い要求を実装できるモデルへ変えています。

クーポン購入を例にすると、次のように分解できます。

「事前条件」「事後条件」「不変条件」は、OMG の Object Constraint Languageでも、操作の前後で成立すべき条件や、システム状態に対して常に成立すべき条件を表す概念として扱われています。

もちろん、すべての開発で OCL のような形式仕様を書く必要はありません。大事なのは、「購入できる」という一文を、対象を構成する概念、状態、ルール、制約、遷移へ分解していることです。

この記事では、対象を概念・状態・ルール・制約・遷移へどこまで分けて見られるかを、ソフトウェアの解像度と呼びます。解像度を上げる仕事は、ドメインをモデル化し、要求を仕様へ変え、実装が依存する前提を明らかにすることです。

仕様を具体化すると、穴が見える

仕様を具体化すると、最初の要求にはなかった問題が出てきます。

「クーポンを使って購入できる」という要求に対して、会員割引との併用可否を考えたとします。

併用不可なら、どちらを優先するのか。併用可能なら、どちらを先に計算するのか。最低購入金額は割引前と割引後のどちらで判定するのか。注文をキャンセルしたらクーポンは未使用へ戻るのか。

ここで答えがなければ、仕様がまだ決まっていないということです。

つまり、モデルを具体化する仕事は、決まっている仕様を整理するだけでなく、未決定の仕様を見つける仕事でもあります。

エンジニアが対象を分解することで、「ここには事業上の正解が必要だ」と外に出せます。決めるのは、仕様の持ち主である事業側です。

ドメイン分析の手法として知られるFODAでも、対象領域の特徴を、必ずあるもの・選べるもの・どちらか一方を選ぶものに分け、「一方を選ぶと他方も必要になる」「同時には選べない」といった特徴同士の組み合わせの規則まで記述します。選択肢と組み合わせの規則を洗い出すと、事業側が選ぶべき点が見えてきます。

AI が生成したコードでも、条件の欠落は観察されています。Tambon らの研究では、CodeGen、PanGu-Coder、Codex が生成したコードから333件のバグを収集し、Misinterpretation、Missing Corner Case、Wrong Input Type、Incomplete Generation など10種類のパターンに分類しています。

この研究だけで「AI は仕様を理解できない」と言うことはできません。私がここで注目しているのは、要求をコードへ変える間には、解釈すべき条件やルールが存在し、その欠落が実装上の問題として現れ得るという点です。

エンジニアが普段やっている「この場合はどうなりますか」という問いかけは、実装前の仕様化でもあり、設計でもあり、後の検証条件を作る仕事でもあります。

すべてを確かめることはできない

モデルを細かくすると、次の問題が出ます。

状態や条件の組み合わせは、掛け算で増えます。

会員種別が2通り、クーポン状態が3通り、商品種別が複数あり、決済手段も複数ある。そこへ在庫状態、配送方法、キャンペーン、購入数量などが加われば、すべての組み合わせについて、実装前に挙動を決め、実装後に確かめることは現実的ではありません。

ここで重要なのは、モデルとして存在を認識していることと、実際に検証したことを分けることです。

たとえば、予約商品という状態を仕様上は認識していても、今回の公開前検証では対象外かもしれません。会計連携という後続処理は実装されていても、別チームの確認待ちかもしれません。

組み合わせによって問題が現れること自体は、テストの研究でも知られています。NIST の組み合わせテスト研究では、調査したソフトウェア障害について、1〜6個の要因の相互作用が観察されています。

組み合わせテストの文脈では、こうしたものを因子やパラメーターと、その値としてモデル化します。ただ、すべてを網羅できないという制約はテストに限りません。

設計でも、レビューでも、検証でも、運用でも同じです。

だからエンジニアリングでは、何を今回の対象に含めるのかを選びます。

• どの仕様を公開前に確定させるのか
• どの状態を設計上の対象に含めるのか
• どの変更影響をレビューするのか
• どの条件を公開前に検証するのか
• どのリスクは監視しながら運用するのか

この選択自体も、エンジニアリングの一部です。

違いは、判断の前提が見えるかどうか

ここで最初の話に戻ります。

代表的な購入操作が一度通れば、「公開できそうだ」と判断することはできます。

違うのは、判断するときに何が見えているかです。

たとえば、次の2つは同じ「公開する」という判断につながるかもしれません。

左側でも判断はできます。

ただ、右側では、何を根拠にその判断をしているのか、その根拠がどこまで届いていて、どこから先は分からないのかが見えます。ソフトウェアの解像度を上げると、判断の前提とその限界が見えるようになります。

この違いを、私はエンジニアリングの価値を考えるうえで重要だと思っています。

エンジニアが増やしているのは、判断する能力そのものではありません。

要求をモデルへ変えることで未決定を見つける。設計することで依存関係を明らかにする。レビューすることで変更の影響範囲をつかむ。検証することで確認済みと未検証を分ける。運用を設計することで、公開後に何を見るかを決める。

個々には当たり前にやっている仕事ですが、共通しているのは、判断の前提と、その限界を見えるようにしていることです。

エンジニアリングの価値を可視化する

この価値がエンジニアの頭の中にだけあれば、外からは見えません。

「設計しました」「レビューしました」「テストを200件書きました」「アーキテクチャを改善しました」という活動量だけでは、他の職種から見たときに、何が分かるようになったのかが伝わりにくい。

成果として共有するなら、少なくとも次の3つに分けると扱いやすいと思っています。

クーポン購入なら、たとえば次のようになります。

この形なら、「購入機能はテスト済み」という一文より、判断の前提がかなり見えます。

AI に実装を任せる場合も同じです。作業報告を「実装しました。テストはすべて通りました」で終わらせず、エージェントへの指示ファイル（AGENTS.mdなど）に、報告の形を決めておけます。

## 作業の報告
変更の最後に、次を分けて報告する。

- 決めたこと：仕様・設計として新しく確定した前提
- 確認したこと：どの条件で、どこを見て確かめたか
- 確認していないこと：試していない条件と、その理由
- 決まっていないこと：仕様として判断が必要な点
- 残るリスク：今回受け入れている不確実性

人が書くチケットや進捗報告でも同じです。「8割できています」より、何が決まり、何を確かめ、何がまだ決まっていないかを出した方が、残りの2割の中身が分かります。

共有するのは技術ではなく、前提と限界

エンジニアリングの価値を共有する、と言うと、「非エンジニアにも技術の難しさを理解してもらう」という話になりがちです。

私は、そこまで理解してもらう必要はないと思っています。

コードを読めなくても、データベース設計を知らなくても、判断に使っている前提とその限界は共有できます。

質問の仕方を変えるだけでも違います。

エンジニア側も、技術用語をそのまま渡すだけでは足りません。

前提と限界は、新しい文書を増やさなくても既存の置き場に残せます。

ただし、判断の前提を作ることと、最後の事業判断をすることは別です。

割引の併用可否、追加で1週間かけて確認するか、低頻度の問題を受け入れて公開するか。そこには売上、顧客対応、契約、スケジュールなど技術の外にある情報が必要です。

エンジニアが事業判断を代わりにするのではなく、判断に使う前提と限界を外に出す。その材料を使って事業側が決める。

この分業の方が、私の経験には近いです。

AI が仕様化・設計・検証まで担ったら

ここまでの話をすると、次に出てくる問いがあります。

実装だけでなく、要求の整理も、仕様候補の抽出も、設計も、レビューも、テストも AI が担うようになったらどうなるのか。

その可能性は十分あると思います。

すでに AI はコード生成だけでなく、テストケース生成、コードレビュー、ログ分析、仕様候補の抽出、テストの合否を決める基準であるテストオラクルの生成まで扱っています。

だから、この記事の主張を「コードは AI でも、仕様化や確認は人間に残る」と置くつもりはありません。

AI が検証を担う場合でも、何を正しい挙動の根拠にするかで結果は変わります。テストオラクル生成の例では、Doc2OracLLが Javadoc を正しさの根拠として利用し、メソッド実装を使う既存手法との比較で、Defects4J の実バグを条件によって19〜94%多く検出したと報告しています。

人間でも AI でも、何を仕様の根拠にするのか、対象をどうモデル化するのか、どの領域まで検証したのかによって、分かることは変わります。

そして、何を根拠にし、どこまで確かめるかという設計自体も、AI が担うようになるかもしれません。

そうなったとき、「ここから先は人間の仕事だ」と境界線を引き続けても、エンジニアリングの価値をうまく説明できない気がします。

むしろ、誰が作業したかとは別に、対象について何が明らかになったのかを見る。

仕様の未決定が見つかった。依存関係が明らかになった。検証済みの範囲が広がった。未知の領域が分かった。運用で見るべき場所が決まった。

AI が作業したとしても、こうした変化はエンジニアリングの成果として扱えます。

共通するのは、解像度を上げること

AI で「作れる」が当たり前になるほど、コードを書いた量だけでエンジニアリングの価値を説明するのは難しくなります。

要求を具体化する。状態とルールをモデル化する。決まっていない仕様を見つける。依存関係を設計する。変更の影響をレビューする。挙動を検証する。公開後に見るものを決める。

エンジニアは以前から、こうした仕事をしてきました。

flowchart LR
    A[粗い要求] --> R[ソフトウェアの<br>解像度を上げる]
    R --> B[モデル化・仕様化]
    R --> C[設計・実装]
    R --> D[レビュー・検証]
    R --> E[運用]
    B --> F[未決定が見える]
    C --> G[依存関係が見える]
    D --> H[確認済み・未検証が見える]
    E --> I[公開後に見るものが決まる]
    F --> J[判断の前提と限界]
    G --> J
    H --> J
    I --> J
    J --> K[事業判断]

どれも、対象について見える範囲を広げ、分かっていること、決まっていること、確かめたことと、その限界を明らかにする仕事です。

AI で作るコストが下がったことで、コードの中に包まれていたエンジニアリングの仕事が見えやすくなったのかもしれません。

私もまだ整理している途中ですが、今は、ソフトウェアの解像度を上げ、判断の前提とその限界を見えるようにすることが、エンジニアリングの価値を説明する一つの言葉になる気がしています。

参考資料

• State of AI-assisted Software Development 2025dora.dev
• Balancing AI tensions: Moving from AI adoption to effective SDLC usedora.dev
• IEEE Standard Glossary of Software Engineering Terminology（IEEE Std 610.12-1990）IEEE Standards Association
• Object Constraint Language, Version 2.4omg.org
• Feature-Oriented Domain Analysis (FODA) Feasibility StudySEI Digital Library
• Bugs in Large Language Models Generated Code: An Empirical StudyarXiv.org
• Why do Combinatorial Testing?CSRC | NIST
• Doc2OracLL: Investigating the Impact of Documentation on LLM-Based Test Oracle Generationdoi.org