AI時代の「設計者」とは誰か ―エンジニアでもPMでもない、判断構造の作者という職能

AI時代になると、
必ずこういう議論が起きる。

エンジニアが重要だ
PMが要だ
データサイエンティストが不足している

どれも間違いではない。
だが、どれも核心ではない。

AIが社会に入り、
判断が自動化され始めた今、
本当に不足している役割は別にある。

「判断構造の作者」

だ。

なぜ今、設計者の正体が問われるのか

これまで述べてきた通り、

AIは責任を持てない
最適化は止まらない
確率は判断を代替しない
例外と衝突が本質を示す
境界を書かない設計は必ず破綻する

これらすべてに共通する問いがある。

「では、それを誰が書くのか？」

従来の役割では、この問いに答えられない

エンジニアは何を書くか

従来、エンジニアの主戦場は明確だった。

アルゴリズムの設計
データ処理の最適化
パイプラインの構築
実装仕様の整備

つまり、

「どう作るか」
を磨くことが中心だった。

そして近年、生成系AIの発達により、

コード生成
データ変換
モデル構築
ドキュメント作成

これらの多くは、かなりの部分まで自動化できるようになった。

技術的な実装力そのものは、
急速にコモディティ化しつつある。

しかし、ここで一つ大きな問題がある。

生成AIによって自動化できるのは、

・文章を書く
・コードを生成する
・スコアを出す
・分類する

といった「処理」や「生成」である。

だが、

「どこで止めるか」は自動化されない。

例えば：

・信頼度が低いときは止めるのか？
・金額が大きいときは人に戻すのか？
・医療や法的判断は扱わないのか？

こうした問いは、

モデルの精度の問題ではない。
アルゴリズムの問題でもない。

それは、

責任をどこに置くかという設計の問題である。

しかし多くの組織では、エンジニアの役割は次のように定義される。

・性能を上げる
・処理を速くする
・自動化率を高める

つまり「できるだけ止めない」方向に最適化する。

一方で、

・どの条件で人に判断を戻すのか
・どのリスクは自動化しないのか
・何をシステムの外に置くのか

といった「境界の設計」には、明確な責任者がいない。

その結果、

自動化は進む。
しかし、事故が起きたとき、

「誰が止める設計をしたのか？」

が答えられない。

これが、

自動化が進むほど責任が曖昧になる構図である。

生成AI時代に本当に重要なのは、

何を作れるかではない。

どこで作らないと決めるかである。

実装力より先に問われるのは、

「ここで止める」という判断停止点の設計。

そしてそれは、

アルゴリズムの精度の問題ではなく、
契約（Contract）と境界（Boundary）の問題なのである。

PMは何を決めるか

エンジニアが「どう作るか」を担うとすれば、
PMは「何を作るか」を決める。

PMが扱うのは、通常次のような領域だ。

・要件定義
・スケジュール管理
・優先順位の決定
・ステークホルダー調整

つまり、

目的と制約の整理である。

何を達成するのか。
いつまでにやるのか。
どれを先にやるのか。
誰を納得させるのか。

これはプロジェクト運営において極めて重要だ。

だがここで、もう一段深い問いがある。

システムが判断するとき、

何を最大化するのか（評価関数）
どこで止めるのか（停止条件）
例外をどう扱うのか
不確実なときはどうするのか

この「判断の構造」は、
通常の要件定義には明示的に書かれない。

なぜなら、

PMは「成果物」を定義するが、
「判断の境界」までは設計しないからだ。

例えば：

CVRを上げる
不正検知率を高める
自動化率を上げる

という目標は設定する。

しかし、

誤検知が何％を超えたら止めるのか
どの金額以上は人間確認にするのか
どのカテゴリはそもそも扱わないのか

といった「停止設計」は、曖昧なままになる。

その結果、

エンジニアは最適化を進め、
PMは成果を追い、
自動化は拡大する。

だが、

判断の境界は誰も書いていない。

生成AI時代において問題になるのはここだ。

アルゴリズムは進化する。
プロジェクト管理も高度化する。

しかし、

評価関数・停止条件・例外処理という“判断の骨格”は、
明示的に設計されないまま動き出す。

だから事故が起きたとき、

「誰がその評価関数を定義したのか？」
「誰がその停止条件を決めたのか？」

が答えられない。

これはPMの能力不足ではない。
役割の定義がそこまで踏み込んでいないだけだ。

だが生成AI時代には、

「何を作るか」でも
「どう作るか」でもなく、

「どう判断させるか」

が設計対象になる。

そしてそれは、

プロジェクト管理でもアルゴリズム設計でもなく、
契約（Contract）と境界（Boundary）の設計問題である。

AI時代の設計とは「構造を書くこと」である

ここまで見てきたように、

エンジニアは
「どう作るか」を最適化する。

PMは
「何を作るか」を決める。

だが、もう一つの問いが残る。

「どう判断させるか」は、誰が書くのか。

ここで、設計という言葉の意味を更新する必要がある。

AI時代の設計とは、

画面を描くことでもない。
APIを定義することでもない。
モデルを選ぶことでもない。

それは、

判断がどのように生まれ、
どこで止まり、
誰に戻るかを書くことである。

これは技術の問題ではない。
マネジメントの問題でもない。

判断構造の問題である。

判断構造の作者とは何をする人か

判断構造の作者は、次の問いに明示的に答える人である。

何を最適化してよいのか
何を最適化してはいけないのか
どの例外は自動化してよいか
どの例外は人に戻すべきか
合意しなかった結果をどう記録するか
判断を止める条件は何か

これらは通常の職務記述書には書かれていない。

しかし、AIが自律的に振る舞う世界では、
これを書かなければシステムは暴走する。

なぜこの役割は不可視なのか

理由は単純である。

成果がコードにならない
KPIに直接現れない
事故が起きるまで評価されない

判断構造の作者は、

「何も起きなかったこと」で評価される。

だから存在が見えにくい。

だが、事故が起きた瞬間に必ず問われる。

「なぜここで止まらなかったのか？」

そのとき初めて、
停止条件を書いた人の不在が露呈する。

判断構造の作者は「責任を引き受ける人」である

この役割は権限職ではない。

最終決裁者でもなければ、
組織のトップでもない。

だが、

判断の前提を書いた人である。

事故が起きたとき、
こう言える立場にいる。

「この境界を、私はここに書いた。」

これは承認の責任ではない。

構造の責任である。

なぜこの役割を置かないとAIは壊れるのか

この役割が不在の組織では、必ず次が起きる。

判断はAIに寄せられる
例外は現場に押し戻される
責任は承認フローに拡散する

そして誰も作者ではなくなる。

その結果生まれるのが、

Human-in-the-loop という名の無責任である。

人が最後にボタンを押しているが、
判断構造は誰も設計していない。

これは安全装置ではない。
責任の希薄化である。

判断構造の作者は、AIと人の「間」に立つ

この職能は、

エンジニアの上でもない。
PMの横でもない。
経営の代理でもない。

AIと人間の境界に立ち、
その境界線を書く人である。

ここまでは計算
ここからは判断
ここは保留
ここは衝突として残す

この線を引くこと自体が仕事になる。

これは新しい職種ではない。再発見された役割である

実はこの役割は、昔から存在していた。

熟練の設計者。
ベテランの現場責任者。
技術と業務の両方を知る人。

彼らは暗黙に境界を書いていた。

AI時代は、

それを暗黙のままにしておくことを許さなくなった。

境界は、明示的に書かなければならない。

まとめ

エンジニアは「どう作るか」を担う
PMは「何を作るか」を担う
しかしAI時代に本当に重要なのは「どう判断させるか」である

設計とは、判断構造を書くことである。

判断構造の作者は、
境界と停止条件を書く人である。

この役割がないAIは、必ず責任を失う。

設計者とは、

「この判断構造を私は書いた」と言える人である。

AIが進化するほど、
人の役割は縮小するどころか、より厳密に問われる。

最後に残る問いはこれだ。

誰が、この判断の構造を書いたのか？

それに答えられないAIシステムは、
いずれ破綻する。