jokura@binary LLC

第1章　AI駆動開発

投稿日 2026年07月22日

いま、開発で起きている変化

AIの登場で、開発の前提が変わりつつあります。これまで人がコード一行ずつ書いていた実装作業を、AIが担えるようになりました。開発の敷居は下がり、二つのことが現実に起きています ── AIを使えるエンジニアは、一人で担える範囲を広げつつある。事業アイデアを持つ人は、エンジニアに頼らず、自分で動くものを立ち上げ始めている。

いずれも意味することは一つ ── 作る作業の担い手が、人からAIへ移りはじめています。

開発のあり方が、変わる

変わるのは、速さや手軽さだけではありません。開発そのものの形が、変わっていきます。

設計をまとめ、コードを書き、テストを実行する ── AIが担える領域は、こうした「作る」工程全体に及んでいます。ならば、そこはAIに任せ、人はその手前にある問いへ集中します。何を作るべきか。どんな価値を顧客に届けるか。

AIが変えたのは「作る」です。「何を作るべきかを決める」ことと、「本当に価値になったかを確かめる」ことは、人に残ります。むしろ作る速度が上がり、成果物が大量に生まれるほど、誤ったときの損失は大きくなり、決める・確かめる仕事の重みは増していきます。

ここでいうAI駆動開発とは、AIに実装を丸投げすることではなく、人とAIが、それぞれ最も価値を発揮できる役割を担う開発です。人は価値創造に、AIは作る領域に集中します。

• 人が担う ── 顧客と事業の課題を理解して仮説を立て、何を作るかを定義し、AIへ問いを与え、成果を評価して意思決定する
• AIが担う ── 要求整理・調査・設計案、対話による仕様づくり、実装・コードレビュー・テスト生成・リファクタリング・ドキュメンテーション

成立には、解くべき課題がある

これまでコードを書けなかった人まで、自分でものを作れるようになりました。個人が生み出せる量は増え、使いこなすチームでは、その積み上がりで全体の生産性も上がりはじめています。ただ、中心はまだ個人です。誰がやっても同じ速さを、チームとして安定して再現できるか ── この「再現性の確保」が、解くべき課題です。

現に、作る担い手がAIへ移る過程で、綻びも現れています ── AIが書いた中身がブラックボックスになる。前提が一貫していないと、AIがもっともらしく誤った結果を導く。手早く作っただけのシステムは、そのままでは事業に使い続けられない。前提が崩れれば、AIは速いまま誤り、増えたデリバリーは、負債として蓄積されていきます。この速さに本当の意味で再現性を持たせるには、この一貫性の課題を解く必要があります。

これらに共通するのは、人とAIが同じ前提を持てているかという点です。だからこそ、AIを使える環境を配るだけでは足りません。マルチエージェントやツールの整備は個人の速さを増やしますが、チームとして再現できる速さは、人とAIの働き方そのものを設計してはじめて生まれます。

Knowledge を、土台に据える

人とAIの働き方の設計を支えるのが、Knowledge です。顧客の目的、業務ルール、設計上の制約、過去の判断 ── こうした前提が参照できる形でそろうほど、AIの出力は安定しやすくなります。この Knowledge を軸に開発する考え方が 仕様駆動開発であり、いま挙げた課題の多くは、ここを固めることで前へ進みます。

人とAIの仕事を、4つに分ける

これらの課題の土台には、共通する1つの見方があります。人とAIのあいだに残る仕事を、その正しさの担保のしかたで4つの軸に分けて捉えるものです。

こう分けると、設計の方向が見えてきます ── できるだけ多くを、確定する「ゲート」の側へ寄せる。そして、人にしか担えない「供給」にこそ、人を残す。 先ほどの「決めるは人、作るはAI」も、この見方の一部にあたります。

AI駆動開発の成立は、確立された答えではありません。検証していく仮説として置きます ── これが本稿全体を貫く姿勢です。この見方を具体的な問いに落とすと、次の4つになります。

• 人とAIの境界を、どこに引くか。 どの仕事を、四つのどれで扱うか。最適な線は工程ごとに違い、固定した正解はありません。
• 知識を、生きたまま保てるか。 現実が動けば仕様が追随し、AIがそれを実際に読み、新しく決めたことが知識へ戻る ── これを「漏れる規約」から「確定するゲート」へ寄せられるか。仕様駆動開発が主に効くのは、ここです。
• 複数人で書き換えても、矛盾しないか。 これだけは性質が違い、4つの軸そのものが、チームの規模でも崩れないかを問うものです。一人なら保てる一貫性を、チームで保てるか ── まだ確かめていない、最大の空白です。
• AIの誤りを、人が見ていなくても止められるか。 人の「判断」に頼る領域を、どこまで「ゲート」へ落とせるか。型・テスト・自動チェックで止められる範囲を、どこまで広げられるか。

属人化は、消えるのか？

Knowledge は、属人化という根の深い問題への対処になりえます。一人に知識が偏れば、ほかの人は手を出せず、その人が休んだり辞めたりすれば、もう誰も直せない ── どの現場にもある話です。

知識が個人の頭ではなく Knowledge の側にあれば、AIはそれを読んで開発を進められ、人もAIに尋ねれば前提をつかめます。担当が代わっても、参照する前提は同じ ── だから属人化は、なくせる期待があります。

ただし、それは Knowledge の整合性が保たれている限りの話です。整合性を欠けば、担当が誰であれ前提は崩れます。ですから今は「属人化が消える」と言い切るのではなく、「理屈のうえでは排除でき、期待が持てる」段階です。

速さではなく、アウトカムで測る

作る速度が上がると、つい「どれだけ作れたか」を成果と見てしまいます。ですが、増やすべきはアウトプット（作った量）ではなく、アウトカム（生まれた価値） です。先ほど触れた、個人にAIを配って生産量を上げる動きも、ここを見失えば、手段を速くしただけで、価値には向き合えていない ── ということになりかねません。

作ったものが本当に価値になったかを計測し、成功と失敗を Knowledge として残し、次の一手を良くしていく ── この学習のループを回せるかが、成否を分けます。しかもこのループは、人だけのものではありません。人とAIが同じ Knowledge を挟んで、一緒に学び、一緒に精度を上げていきます。

これらの課題を突き詰めると、それは一人の開発者の作法の問題ではなく、組織の作り方の問題になっていきます。次章では、この協働を支えるために、開発組織の側がどう変わる必要があるかを見ていきます。