実装が速くなるほど「何を作るか」が重くなる――LayerXが広げる、アウトカムまでの要件定義

LLMによって実装が速くなると、ソフトウェア開発の問題は解けるのか。LayerX代表取締役CTOの松本 勇気氏が「AI要件定義サミット2026」で示した答えは、その期待とは逆のものだった。実装の制約が薄れるほど、「何を作るか」と「使われて成果が出たか」が新しいボトルネックになる。同社が取り組むForward Deployed Engineer（FDE）とプラットフォームの組み合わせから、要件定義をアウトカムまで広げる方法を読み解く。

リリースが速くなっても、アウトカムは増えない

従来のソフトウェア開発は、現場の暗黙知を要件へ変え、設計、実装、検証を経てリリースする多段階の翻訳だった。工程をまたぐたびに設計意図が抜け落ちていく。それでも実装に時間と費用がかかる以上、上流で仕様を固め、手戻りを抑える設計には合理性があった。

しかしLLMとコーディングエージェントが、その前提を崩しつつある。松本氏によると、LayerXでもAI利用を広げた後、開発量が増えた。そこで表面化したのは、作れる機能の数に、営業や顧客の理解が追いつかないという問題だった。新機能を毎日出しても、営業が説明できず、顧客も使いこなせなければ、リリースは事業成果へつながらない。

松本氏の整理では、ボトルネックは作るべきものを見定める側へ、ゴールラインはリリースからアウトカムへ移った。実装が速くなった分だけ、要件定義の前にある課題発見と、リリース後の定着がより重要になる。AIによって開発工程は縮まるが、開発全体が短くなるとは限らないというわけだ。

機能数や開発量をゴールに置けば、中央の開発工程だけが効率化される。営業部門が新機能を理解するまでの時間や、顧客への導入と利用定着にかかる時間は縮まらない。要件定義を設計書作成の開始点ではなく、成果の仮説を置き、利用後に確かめる循環として捉え直す必要がある。LayerXの議論は、開発の範囲を実装の外側へ広げるものだった。

要件定義に残るのは、意思と例外を掘る仕事

松本氏は、暗黙知を2つに分けた。一つは、既存の仕様書、設計書、操作ログに痕跡が残る「行動」に関する暗黙知である。これはプロセスマイニングやLLMで掘り起こしやすくなっている。もう一つは、判断、意図、戦略、例外対応の背後にある暗黙知だ。

同じ経費精算や見積書処理でも、会社ごとに承認条件や例外が異なる。たとえば、少額の支出も必ずレビューするというルールだけなら、AIは手順として再現できる。だが、その裏に「金額の大小ではなく、投資の妥当性を説明できるかを見る」という経営の意思があれば、表面のルールだけを渡しても足りない。

システムには「この場合は差し戻す」という動作が残っても、なぜそう判断するのかまでは記録されていないことがある。経営者や現場が守ろうとした価値を渡せなければ、AIは想定外の例外に出会ったとき、何を基準に判断すればよいか分からない。

「事業の価値源泉にある暗黙知は、なかなか表に出てこない」と松本氏はいう。AI時代の要件定義では、文書をきれいに作ることより、現場の観察と対話から意思や例外を掘り、その背景をAIが実行できる制約へ変える仕事が残る。入力文を増やすだけでは足りない。AIが迷わない道筋を設計するエージェントハーネスも必要になる。

こうした暗黙知は、一度の会議ですべて聞き出せるものでもない。人は、自分が「当然だ」と思っている判断基準ほど説明しにくい。試作品を見せ、反応を確かめ、例外を聞き直す。その往復によって初めて、暗黙知はAIへ渡せる要件に変わっていく。

ここで人が担うのは、AIより詳しくコードを書くことではない。AIに任せる範囲と、あらかじめ固定する手順を決める。例外が起きたときに、人へ戻す条件も定める。暗黙知を文章へ起こすだけでなく、実行時の境界条件へ変換できて初めて、要件はエージェントの動作につながる。

プラットフォームは、エージェントに考えさせすぎないための器である

LayerXが2024年6月に提供を始めた「Ai Workforce」は、エンタープライズ企業向けのAIプラットフォームである。講演で松本氏は、エージェントハーネス、決まった手順を実行するワークフロー、外部データやツールとの接続、セキュリティや権限管理を再利用可能な器へまとめる考え方を説明した。

企業ごと、業務ごとにAIエージェントをゼロから作れば、接続、認証、監査、品質保証を毎回やり直すことになる。松本氏は、将来一社で必要になるエージェントを「数千から数万」と見立てる。その数を前提にすれば、一つずつ受託開発する方法では追いつかない。共通部分をプラットフォームへ寄せ、個別要件だけを設定する形が必要だ。

設計思想は「エージェントになるべく考えさせない」である。たとえば見積書の値を管理用Excelの所定セルへ転記する業務では、自由な推論より再現性が優先される。データ取得やセル指定を確定的なソフトウェアへ任せ、AIが判断する範囲を狭める。モデルが賢くなるほど自由に考えさせるのではなく、迷う余地をプラットフォーム側で減らすことが重要になる。

改善もプラットフォームへ反映させていく。FDEが現場の暗黙知を要件へ変え、コーディングエージェントが実装を支援し、本番運用で検証する。修正で得た知見はテンプレートや機能として資産化し、次の案件で再利用する。「作る、検証する、改善する、資産化する」のループを閉じることで、今日の案件が明日の実装速度を上げる。

この分担では、プラットフォームは単なる共通部品集ではない。FDEが案件で直面した認証、接続、品質管理の知見を製品へ戻し、次の顧客では個別開発しなくてよい状態を増やす器である。反対に、プラットフォームだけでは、顧客固有の意思や例外を見つけられない。標準化する側と現場へ入る側を往復させて初めて、再利用と個別最適を両立できる。

FDEは常駐要員ではなく、顧客課題の最前線に立つ

実装からリリースまでの時間をプラットフォームが短くする。だが、両端はプラットフォームだけでは埋まらない。前端では、顧客が本当に欲しいアウトカムを見つける。後端では、導入された仕組みが使われ、事業成果へつながるまで伴走する。LayerXは、その両端をプラットフォームとFDEが共に担う。

Forward Deployedは「前方展開」を意味するが、松本氏は常駐の同義語ではないと説明した。FDEとは「お客様の課題の最前線にいるエンジニア」である。業務を観察し、仮説を立て、プラットフォームでその場に近い速度で試作品を作り、顧客の反応から要件を更新する。その更新はプラットフォームにも蓄積され、次の現場での試作の速度を上げる。一度のヒアリングで正解を聞き出すのではなく、対話と実験の回数で暗黙知を明確にする。

LayerXは、FDEを含め、AIエージェントを駆使して事業のアウトカムを実現する人材を「AI Builder」と呼ぶ。顧客の事業KPIを読み、アウトカムを定義する事業開発力、プロジェクトを動かす力、実装を判断する技術力、新しい業務を定着させるチェンジマネジメントが必要になる。要求される範囲が広い分、FDEを単発の小さなエージェント開発へ振り向ければ採算も合わない。事業インパクトの大きい課題に絞る必要がある。

FDEという肩書を付けるだけでは、このモデルは回らない。プラットフォームとFDEが独立に動くのであれば、知見はその場限りで終わるからだ。現場で得た知見を蓄えるプラットフォームがあり、FDEが顧客の成果創出まで伴走し、両者が互いを更新することが前提になる。AI時代の要件定義を分けるのは、文書作成の速さではない。要件からアウトカムまでの距離を、案件を重ねるほど縮められるかである。