発注しているベンダーやチームに、「タスクの粒度やレビューの基準を、何を基準に決めているか」を聞いたことはあるだろうか。
前回は、見積もりの数字がどんな条件で測られたものかを確認する重要性について書いた。今回はその一歩先、実際にプロジェクトを回しているプロセスそのものが、誰のために設計されているかについて書く。実はこれは個人の感覚の話ではなく、日本が国として掲げている原則とも関わっている。
AI駆動開発のプロセスが「人のため」に設計されているかを見極める視点と、発注者がタスク粒度・レビュー基準・完了条件で確認すべきポイントがわかります。
2019年、内閣府は「人間中心のAI社会原則」を策定した。人間の尊厳が尊重される社会、多様な人々が多様な幸せを追求できる社会、持続性のある社会という3つの価値を基本理念とし、AIに過度に依存したり、人間の行動をAIにコントロールされたりする社会を作るのではなく、人間がAIを道具として使いこなす社会を目指すとしている。
2026年3月に改訂された「AI事業者ガイドライン」も、この原則を土台にしている。AIの出力結果が公平性を欠くことのないよう、AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を介在させることが求められている。
つまり、「人がAIを活用して、人をサポートする」という発想は、単なる理想論ではない。国が掲げる公式な原則そのものだ。発注する側が「どんなプロセスで作られているか」を問う際、この原則は具体的な物差しになる。
プロセスの矢印が、どちらを向いているか考えてみてほしい。
AIは人の手足であり、主導権は人にある。
AIの処理しやすさが先に決まり、人がそこに合わせる。
前者では、AIは人の手足であり、主導権は人にある。後者では、AIの処理しやすさが先に決まり、人がそこに合わせる存在になっている。タスクの切り方、レビューのタイミング、完了の定義——これらがいつの間にか「AIにとって都合がいいかどうか」で決まっていないだろうか。
Google CloudのDORAレポートは、ユーザー中心（user-centric）の視点を持たないチームほど、AI導入によってむしろネガティブな影響を受けると報告している。逆に人を中心に据えたチームほど、AIの恩恵が増幅される。同レポートはまた、AI導入によって開発者の摩擦や燃え尽きが目に見えて改善したわけではないとも指摘しており、その理由として、摩擦の多くは個々の開発者ではなく組織のプロセスそのものに根ざしていると分析している。
こうした人間中心のプロセス設計は、理念にとどまらない。AWSが2025年に提唱した開発方法論「AI-DLC（AI-Driven Development Lifecycle）」は、「AIが提案し、人間が承認する（AI proposes, human approves）」という原則を掲げている。AIが計画・実装案を作成し、意図のすり合わせのための質問を積極的に行い、人間が各チェックポイントで検証・承認して初めて次に進む——上図の「人間中心」の矢印を、具体的な開発方法論として体系化した例のひとつだ。人間中心という考え方は、抽象的な理念ではなく、すでに実装レベルの方法論として動き始めている。
発注する側からは、納期や成果物は見えても、矢印がどちらを向いているかは見えにくい。だが、効率化を求めるあまり、そこで働く人が置き去りになっているとしたら、それは短期的な速さだけでなく、長期的な品質や離職・疲弊にも関わってくる問題だ。
プロセスの向きは、実は日々の運用ルールにも表れる。発注先に、タスクの粒度やレビューの基準を「何のために」その形にしているか、確認したことはあるだろうか。
実際、AIを導入したことで、これまでにはなかった種類の無駄が生まれることも指摘されている。たとえば、AIへの指示に対する応答を待つ間に作業が中断され、集中が途切れてしまうことなどがそれにあたる。基準や粒度の設計が、人がAIの出力を検証しやすくすることではなく、AIの処理効率だけを起点に決められていると、こうした無駄は発注する側からは見えないまま積み上がっていく。
そしてこれは、発注する側にとっても無関係ではない。現場がAIの出力を検証しやすい設計になっていれば、その内容は「なぜこの実装になっているか」を発注者に説明する材料としても使える。逆に、現場ですら検証しづらい基準で進んでいるなら、発注者がそれを確認する手段はさらに乏しい。現場の検証しやすさは、そのまま発注者の確認しやすさにつながっている。
2章で見た「AIに人が合わせる」プロセスの先には、何が起きるのか。
Anthropicが52名のソフトウェアエンジニアを対象に行ったランダム化比較試験では、AI支援を使った参加者は作業時間こそ対照群とほぼ変わらなかったが、その後の理解度テストのスコアが17%低かった（50%対67%）。
「終わったかどうか」だけを基準に進捗を管理していると、「担当者がその実装を理解できているかどうか」は測られないまま進んでしまう。納期通りに終わったという報告の裏で、後々の保守や引き継ぎに響くコストが蓄積している可能性がある。発注する側が気にすべきは、完了したかどうかだけではない。
理解されないコードは、次の保守担当者にとって「負債」になる。AIがコードを書く時代ほど、人が理解することの価値は高くなる。
ここまで見てきた落とし穴に共通するのは、「効率化」という言葉だけを追いかけ、その中身を確認しないまま進めてしまうことだ。発注する側が最初に確認できることを整理する。
「AIが処理しやすいから」ではなく「人がAIの出したものを確認・検証しやすいから」その基準になっているかを確認する。現場が検証しやすい設計は、そのまま発注者への説明可能性にもつながる。
判断が変わると手戻りが大きい部分（要件・設計）には自分たちも関与し、仕様が固まった実装だけをAIとチームに任せる、という線引きを事前にしておく。
担当者が実装意図を説明できることを、完了の基準に含めてもらう。
AIの出力が公平性や妥当性を欠く恐れがある場面では人間の判断を介在させるべきだという考え方は、社外に発注する際の要求事項としてもそのまま使える。
だからこそ、発注者が確認すべきなのは、「AIを使っているか」ではない。
「そのプロセスは、人が理解し、人が判断し、人が責任を持てるように設計されているか」という一点だ。
プロセスは、AIのためではなく、人のために設計されるべきだ。
次回は「品質」です。AIがコードを書く時代に、本当にレビューすべきものはコードなのか。それとも別のものなのかを考えます。
STVテックでは、AI導入において「人が検証・承認できるプロセス設計」になっているかを重視しています。
要件定義や設計の初期段階から、判断を人が担える体制を一緒に整理します。