AIがコードを書くスピードが上がったとき、ボトルネックはどこへ移ったのか

AIとソフトウェア開発をめぐる対談は、あるデモから始まった。コードはAIが生成し、テストはすべてグリーンになった。一見すると、これまで最も時間を要していたコーディング工程は大きく短縮されたように見える。しかし、対談に参加した二人のゲストは、すぐに現実へと話を引き戻した。テストがグリーンになったのは、あくまでコードがテストの期待に沿ったというだけであり、テストそのものが正しいとも、作ったものが顧客の本当のニーズに応えているとも限らない。

「コードを書くこと」が主要なボトルネックではなくなったとき、エンジニアリングの重心はどこへ移るのか。それがこの対談の本当の問いだった。

コードが速くなっても、ボトルネックは消えず、前後へ移動する

矢上の経験は明快だった。AI駆動の開発環境を整え、すでに一部の本番コードの開発にもAIを使っている。コーディングにかかる時間は確実に減っている。しかし、浮いた時間によって納品全体が楽になったわけではなく、かえってコーディングの前後にある負荷がはっきりと見えるようになった。

前にあるのは「何を作るのか」を決めることだ。顧客の本当の問題は何か、どの要件を満たすべきか、どこまでが表面的な要望なのか、例外をどう扱うのか。こうした判断が曖昧なままなら、AIは間違った答えをより速く生成するだけである。後ろにあるのは検証と運用だ。生成された振る舞いが業務ルールに合っているか、問題が起きたときに誰が判断するのか、本番環境に入ったあとどう保守するのか。コーディングが速くなるほど、この両端の負債は目立つようになる。

対談で矢上が最も難しいと語ったのは「言語化」だった。金融などの業界には、十数年、時には数十年にわたって動いてきたレガシーシステムが数多くある。ルールの多くは具体的な業務オペレーションと人の経験の中にしか存在せず、完全には書き残されていない。創業から約八年の会社であっても、言語化されていない業務は数多く残っている。ここでいう言語化とは、古い文書をきれいに整理することではない。「みんながずっとこうしてきたが、なぜそうなのかは誰も説明していない」という判断、例外、責任の所在を、議論でき、検証でき、最終的にはシステムに引き継げる定義へと変えることだ。

この作業をAIに任せるのは難しい。AIは文書を読み、コードを生成できるが、一度も記録されたことのない業務上の例外を自動的に知ることはできない。誰かが聞き、現場を見て、曖昧な言い方を具体的な条件へと分解しなければならない。要件定義が再びエンジニアリングの中心になったのは、道具が賢くなったからではなく、道具が「考え切れていないこと」のコストを増幅したからだ。

エンジニアの新しい立ち位置は、顧客、業務、コードのあいだにある

対談には、現実的な観察もあった。これまでのエンジニアは、主に先輩の仕事を眺めることで育ってきた。新人は先輩エンジニアの隣で、日々の仕事やプロジェクトの進め方を通じて判断を学ぶ。しかし、今AIエージェントを作っているエンジニアには、完全に対応する先輩像が見当たらないことが多い。道具も働き方も納品先も変わり続ける一方で、受け継ぐべき経験はまだ安定した形になっていない。

だからといって、技術的な基礎が不要になったわけではない。むしろ、技術的な土台がしっかりしている人ほど新しい領域へ入りやすいと対談では語られていた。本当に希少なのは、システム設計を理解し、大規模な実装と本番化を経験し、さらに顧客と直接向き合える人材だ。与えられた要件どおりにコードを書くだけでは足りず、概念だけを語ってもシステムを現実に動かすことはできない。

新しい働き方は、おおよそ次のような流れになる。まず顧客や業務チームと継続的に対話し、彼らが本当に変えたいことを理解する。次に、曖昧な要望を構造化し、足りない情報を見つける。そしてAIを使って素早く検証可能な形にし、足りない部分を埋めながら前に進める。対談では、こうした役割をFDE（Forward Deployed Engineer、顧客現場に入り込むエンジニア）と結びつけていた。純粋なプログラマーでも、インタビューだけをするコンサルタントでもなく、業務の現場と実装のあいだを行き来できる人である。

だからこそ「育成」は難しい。こうした能力は一つの講座で教えられるものではなく、実際のプロジェクトで業務側と一緒に問題を分解し、施策を作り、結果に責任を持つ過程で身につくものだ。対談では、エンジニアを、顧客を最もよく知る人たちの近くに置き、対話を続けることが、プロンプトだけを練習するよりも重要だという指摘もあった。

テストが全部グリーンでも、プロダクトとして正しいとは限らない

デモで最も見落とされやすいのは、「グリーン」がもたらす安心感だ。テストが通ることはもちろん重要だが、それが証明するのは「コードが現在のテストの期待に沿っている」ということだけである。テスト自体が重要なシナリオを漏らしていたり、要件の理解が最初から間違っていたりすれば、全部グリーンであることがかえって偽りの完成感を生む。

AIが生成するのは抽象的なコードではなく、実際に動く振る舞いだ。その振る舞いが正しいかどうかは、最終的には業務上の問題を解決しているか、異常時にも制御できるか、結果に責任を持つ人がいるかで決まる。Codexのようなツールは生成を安くし、その分「判断」を高価にした。対談では、同じツールでも使う人によって生成の質が次第に分かれていくという現象が語られていた。問題をどんどん収束させられる人もいれば、もっともらしく見えるが目標から外れたものを生成し続ける人もいる。

だからこそ、技術的な判断力は自動化に取って代わられていない。むしろ、より前の工程へ押し出されている。AIに何をさせるか、どんな文脈を与えるか、結果をどう検証するか、どこで止めて人を介在させるか。コーディングの速さは下限を決めるが、上限を決めるのは判断力だ。

AIをどこに入れるか：まず「人が判断すべき点」を探す

二つ目のテーマはより具体的だ。組織はAIをどの工程に入れ、どの工程には明確に入れないのか。

矢上は金融業務を例に、職種で分けるのではなく、意思決定の性質で分けるという考え方を示した。ルールが明確で、機械的に確認でき、推論を必要としない工程はできるだけシステム化する。人が価値判断をし、例外に対応し、責任を負う必要がある箇所は徹底的に洗い出し、人に残す。これまでの業務設計では、人の工程をまとめてシステム化することがよくあった。今は、そのうち推論や生成に適した部分をAIに任せ、人の判断を重要なポイントに残す。

この境界は、アーキテクチャ図に一本の線を引けば済むものではない。具体的な業務に落とし込む必要がある。どの指示は自動実行してよいのか、どれは二重確認が必要か、どの異常はエスカレーションすべきか、問題が起きたとき誰が責任を負うのか。対談で挙がった銀行の例——資金の移動や口座の凍結、強制引き落としなどの指令——が敏感なのは、それが単なる「情報処理」ではなく、権限、責任、取り返しのつかない結果を伴うからだ。こうした工程ほど、AIが見た目にもっともらしい操作を生成できるという理由だけで、本番フローに入れてよいわけではない。

渡辺は、もう一つ見落とされがちな前提を補足した。セキュリティとガバナンスである。ソフトバンクが自社内でAI活用を進める場合、重要データや個人情報を扱うことになり、通信業界には非常に厳しい情報管理の要件がある。こうした条件下では、あるツールを使えるかどうかは効果だけでは決まらない。データがどう処理されるか、権限をどう制御するか、問題が起きたときどう追跡するかも問われる。多くの企業はAIが有用だと知らないのではない。「使える」と「管理できる」を同時に満たす準備がまだできていないのだ。

最初の一歩はモデル選びではなく、責任と条件を整えること

対談の最後に、司会者は問いかけた。もし明日から始めるなら、最初の一歩は何か。

二人の答えは、道具ではなく組織に向いていた。各社の事情は異なるが、避けて通れないことがいくつかある。第一に、経営層の明確な姿勢だ。AI変革が一部のチームの自発的な実験にとどまっていては、部門の境界を越えるのは難しい。会社として推進する人が必要であり、結果に責任を持つ責任者も必要になる。第二に、データと技術的な条件の整備だ。データが整理されておらず、権限やセキュリティの境界も決まっていなければ、道具がどれだけ優れていてもデモの段階で止まる。第三に、現場の人に身近な小さな問題から自動化を始めてもらうことだ。最初から基幹システムを作り替える必要はない。

これは、司会者が語った若い世代の不安にも通じる。準備が整うまで待つ必要はない。社内の反復的で細かな、境界の明確な業務を一つ自動化するだけでも、十分な出発点になる。そうしたプロジェクトでは、業務、データ、システムを同時に理解できる。AIがどこで役立ち、どこで誤るのかも見えてくる。対談ではまた、若い人の関心はメディアや広告のようなインターネットサービスだけに向かう必要はなく、社会を支え、命を守るミッションクリティカルなシステムにも、進んで入っていく人が必要だという話もあった。能力は先に学び終えてから発揮するものではなく、小さな結果を積み重ねる中で育っていく。

対談は、そのまま真似できる答えを提示したわけではない。示されたのは、答え続ける必要がある三つの問いだった。エンジニアリングの現場はどこへ移ったのか。誰が何を作るかを決めるのか。そして、AIと人の境界をどこに引くのか。コードが速くなっても、組織が自動的に速くなるわけではない。結果を決めるのは、「何をするか」と「誰が責任を負うか」を組織が考え抜けているかどうかだ。

速さはゴールではない

一つだけ持ち帰るなら、こうなる。AIはコーディングを速くしたが、「問題を定義すること」と「結果を判断すること」をより前の工程へ押し出した。テストが全部グリーンで、デモが滑らかでも、価値がすでに生まれたことにはならない。エンジニアにとっての新しい競争力は、コードを書くことだけではなく、業務の現場に入り、語られていないことを言葉にし、AIに任せるべきでない部分を守ることにある。

だからこそ、AIが素早く生成できる時代ほど、「何を、なぜ、どこまでやるのか」に責任を持つ人が必要になる。道具はこれからも速くなるだろう。しかし、境界は自動的には現れない。議論し、設計し、具体的な人が責任を負うことでしか形にならない。