AIに作らせた仕組みが作り直しになる原因｜先に仕様を決める進め方

「動くものは半日でできたのに、直そうとしたら誰も中身を説明できなかった」「先月と同じことを頼んだはずなのに、まったく別の作りで出てきた」——AIに社内の仕組みを作らせ始めて数か月経った現場で、実際に交わされているやり取りです。どちらも、担当者の腕前の話として語られがちです。しかし原因はそこではありません。作り直しになるのは、AIの実力が足りないからではなく、決めていないことが多すぎるからです。決めていない欄はその場で埋められ、埋めた理由はどこにも残りません。それが積み重なると、直すより作り直すほうが早い状態になります。この記事では、作り直しを招く四つの原因を分解したうえで、思いつきを話しかけながら作らせる進め方と、先に仕様を文書にしてから作らせる進め方をどう使い分けるか、仕様に何を書き、どこで人が読み、どうやって受け入れを決めるかまでを整理します。

扱うのは、作った後ではなく作る前と作る途中

AIに作らせた社内の仕組みを、誰がどこまで使ってよいのか、どのデータを載せてよいのか、いつ正式なものへ昇格させ、いつ捨てるのか。作った後の運用と線引きについては、当サイトの別の記事で扱っています。本記事はそこには戻りません。扱うのは、作る前と作る途中だけです。運用の決まりをどれだけ整えても、作り方が変わらなければ、作り直しの発生そのものは減らないためです。

読者として想定しているのは、開発を専門にしていない人も含みます。マーケの担当者が集計の仕組みを作らせる、情報システムの担当者が申請の受付を作らせる、決裁者が外部に頼むかどうかを判断する。いずれの立場でも、決めるべきことを決めているかどうかは判断できます。技術の細部が分からなくても、この記事で扱う判断は成立します。

順番としては、作る前と作る途中を先に整えるほうが得です。運用の線引きは、動いている仕組みが増えてから必要になります。作り方が定まっていないうちに運用の決まりだけ作ると、決まりに合わない仕組みが次々に生まれ、例外の許可を出す仕事だけが増えます。実際、運用の決まりが先にできた会社ほど、申請を出さずに作られた仕組みが増える傾向があります。作り方の型がないまま線だけ引いても、線の外側が広がるだけだからです。

動くものはすぐできるのに、数か月で作り直しになる

最初の体験は、たいてい良好です。思いついたことを話しかけると、動くものがその日のうちに出てきます。集計が自動で回り、申請の受付が形になり、担当者の手作業が消える。ここまでは期待どおりです。問題が出るのは、二度目以降の変更が入ってからです。

壊れ方には型があります。前提が変わったのに、どこを直せば足りるのか分からない。似た機能を足そうとしたら、既存の部分まで書き換えられて元に戻せない。想定していなかった入力が来たときに、静かに間違った結果を返す。いずれも、動いていた状態が突然壊れるのではなく、最初から決まっていなかった部分が表に出てきているだけです。三つ目が最も厄介です。止まらないので気づかれず、間違った数字が資料に載ったまま何度も配られます。

この段階で、体感と実測がずれます。経験のある開発者を対象にした計測では、本人の体感は約20%速くなったと感じているのに、実際の作業時間は19%遅くなっていました。別の調査では、66%が「ほぼ正しい」出力の手直しに時間を取られていると答え、45%が原因を追う作業に時間がかかると答えています。速くなった感覚と、実際に終わるまでの時間は、別々に動きます。

数字で見ると、何がどれだけ残っているのか

感覚の話に留めないために、規模の大きい調査を一つ見ておきます。2026年に公開された実証調査では、公開されている開発プロジェクト6,275件から、AIが生成したとされる変更304,362件を集め、2024年1月から2025年10月までを追いかけました。対象は主要な三つのプログラミング言語です。

見つかった問題は合計484,606件でした。内訳は、読みにくさや壊れやすさにつながる書き方が431,850件で89.1%、実際に動かしたときの不具合が28,149件で5.8%、安全性に関わるものが24,607件で5.1%です。最も多かったのは、失敗の種類を区別せずまとめて握りつぶす書き方で41,723件、次いで使われていない変数が28,718件でした。どちらも、決めていない部分をとりあえず動く形で埋めた結果として現れます。

重要なのは、残り方のほうです。見つかった問題のうち24.2%が最新の版にも残っていました。9か月以上前に入った問題でも19.2%が残り、入って三か月以内の問題では24.8%が残っています。古いか新しいかで、残り方はほとんど変わりません。時間が経てば誰かが直すという前提は、数字の上では成り立っていません。2026年2月の時点で、残ったままの問題は累計で11万件を超えていました。なお、この調査は人が書いたコードとの直接比較はしていないと著者自身が断っています。AIだから多い、と読むのではなく、放っておくと残る、と読むのが正確です。

ミニ用語解説：この記事に出てくる五つの言葉

進め方の話に入る前に、用語をそろえておきます。会議で意味がずれたまま議論が進むと、判断そのものが噛み合わなくなるためです。

言葉	意味	実務での要点
バイブコーディング	思いついたことを話しかけながら作らせる進め方	試作は速い。決めていない欄はその場で埋められる
仕様駆動開発	先に何を作るかを文書にしてから作らせる進め方	文書が残る。小さな作業には重すぎることがある
受け入れの基準	これができていれば完成とみなす条件	数と条件で書く。動いた、では判定できない
やらないことの宣言	この仕組みでは扱わないと決めた範囲	最も抜けやすい。抜けると勝手に埋められる
手戻り	終わったはずの工程に戻ってやり直す作業	原因の多くは、決めていなかったことの発覚

この五つのうち、社内で最も説明が要るのは四つ目です。仕様というと、作るものを並べる文書だと受け取られますが、実務で効くのは作らないものを書いた側です。書かれていない範囲は、AIが必要だと判断すれば埋めます。埋めた結果は動いてしまうため、誰も気づきません。

もう一つ、社内で誤解されやすいのが二つ目です。仕様駆動という言い方から、昔ながらの分厚い設計書を先に作る進め方だと受け取られることがあります。実際に書くのは用紙一枚から二枚で、しかも初稿はAIに書かせます。違いは分量ではなく、決めたことが文書として残るかどうかにあります。ここを説明せずに提案すると、手間を増やす話だと受け取られて、着手する前に反対されます。

原因1 決めていない欄を、その場で埋められる

作り直しの一つ目の原因は、決めていないことをAIが補完する性質そのものです。入力が空だったときの動き、上限の件数、権限の扱い、締め切りを過ぎたときの挙動、失敗したときの再試行。指示に書かれていなければ、もっともらしい既定の動きが選ばれます。選んだこと自体は出力に書かれないので、決まったという認識すら社内に発生しません。

五人の担当者が、それぞれ別に同じような仕組みを作らせると、五通りの前提が生まれます。片方は失敗したら三回やり直し、片方は一度で止まり、片方は失敗を記録せずに次へ進む。後で一つにまとめようとした段階で、この食い違いが一気に表面化します。統合の作業が重くなるのは、ここが理由です。

先ほどの調査で最多だった、失敗の種類を区別せずまとめて握りつぶす書き方は、この性質の典型例です。何が起きたときにどう振る舞うかを決めていないので、とりあえず止まらない形が選ばれます。止まらないことと、正しく動いていることは違います。静かに間違い続ける仕組みは、止まる仕組みより発見が遅れます。

原因2 前提が後から変わり、決めた記録が残っていない

二つ目は、会話の中で決めたことが会話とともに消えることです。やり取りの途中で、担当者が「この項目は空でよい」「この件数までで足りる」と口頭で伝えたとします。その判断は出力されたものの中に埋め込まれますが、判断の理由はどこにも残りません。数か月後に前提が変わったとき、どこを直せば足りるのかを追う手がかりがない状態になります。たとえば集計から特定の部署を外していたとします。当時は組織上の理由がありましたが、翌期に部署が統合されると、除外の条件だけが残って数字が合わなくなります。

この差は、残る成果物の違いとして現れます。思いつきで作らせる進め方で残るのは、動いているものだけです。先に仕様を決める進め方では、動いているものに加えて、何を作るつもりだったのか、なぜその判断をしたのか、どう分けて作ったのかが文書として残ります。作り直しの判断を分けているのは、コードの品質よりも、判断の記録が残っているかどうかです。

記録が無いと、直す作業が調査から始まります。調査に時間がかかるほど、作り直したほうが早いという結論に傾きます。作り直しは技術的な判断のように見えて、実際には調査の費用が高すぎるという判断です。

原因3 作った本人しか中身を読めない

三つ目は、読み手の不在です。AIの支援を導入した806件の開発プロジェクトを追った調査では、複雑さが41%増え、自動検査の警告が30%増えました。速度は一時的に上がるものの、増えた分は残り続けます。作るのが速くなった分だけ、読む負担が後ろに積み上がる構図です。

読みにくさは、似て非なるものが増える形でも現れます。重複したかたまりは2024年に過去八倍まで増えたと報告されています。同じような処理が少しずつ違う書き方で何か所にも置かれると、一か所を直しても他が直っていない状態が生まれます。別の調査では、AIが書いたコードは変更の取り込み依頼1件あたりの問題が1.7倍多く、810万件の依頼を調べた範囲で、負債にあたるものが30%から41%増えたとされています。

組織の側の症状も出ています。開発者の40%が、チームの決まりごとと合わないことを負担に挙げています。個人が速く作れるようになるほど、チームで読める形からは離れていきます。この二つは同時には解決しないので、どちらを優先するかを案件ごとに決める必要があります。

原因4 「できた」の基準が人によって違う

四つ目は、完成の定義です。作った本人は動いたら完成だと考え、依頼した側は業務が回ったら完成だと考え、情報システムの担当者は障害が起きない状態を完成だと考えます。基準を先に文章にしていないと、受け取る段階で初めて食い違いが出ます。この時点での差し戻しが、最も費用の高い手戻りになります。

数字にも表れています。AIの支援が入ったチームでは、変更の取り込み依頼が20%増えた一方で、障害は23.5%増えたという報告があります。出す量が増えても、確かめる基準が増えていないためです。使っている、または使う予定と答えた開発者は84%に達し、取り込まれたコードのおよそ41%がAIの支援によるものだとされています。分母が大きくなった分、基準の不在が効いてきます。

基準が無いと、確認そのものが属人化します。詳しい人が全部見るしかなくなり、その人が休むと止まる。受け入れの基準を先に書くのは、品質のためであると同時に、確認できる人を増やすためです。基準は一行で足ります。先月分の実績が、締め日の翌営業日の朝までに、部署ごとの表として出ていること。この形なら、動いたかどうかではなく、業務が回ったかどうかで判定できます。

二つの進め方を並べて比べる

ここまでの四つの原因は、どれも「決めていない」という一点に集まります。では常に先に決めればよいかというと、そうでもありません。二つの進め方には、それぞれ向く場面があります。

比べる点	思いつきで話しかけながら作らせる	先に仕様を決めてから作らせる
起点	その場で思いついた指示	何を作るかを書いた文書
進み方	頼む、出す、動かすの繰り返し	決める、割る、作る、確かめるの順
残るもの	動いているものだけ	動いているものと、判断の記録
強み	形になるまでが速い	同じ結果を再現できる。引き継げる
弱み	決めていない欄が勝手に埋まる	小さな作業には手順が重すぎる
向く場面	使い捨ての試作、方向の確認	本番で使うもの、複数人が触るもの
引き継ぎ	作った本人に聞くしかない	文書を読めば追える

表を見て分かるとおり、対立するものではありません。試作の段階まで仕様を書くのは無駄で、本番で使うものを思いつきで作るのは危ない。それだけの話です。実際、方向を確かめる段階では話しかけながら作り、方向が決まった時点で仕様に起こしてから作り直す、という二段構えが現実的です。

業界の動きもこの方向に寄っています。2025年9月と11月に、開発者向けの基盤を提供する二つの事業者が、仕様を先に書く進め方を支える道具を相次いで公開しました。個人の心がけではなく、道具として支える段階に入ったと見てよい状況です。道具の側は、いま使っている作業環境にそのまま足せる形と、専用の環境として提供される形の二種類に分かれます。ただしどちらを選ぶにせよ、先に決めるべきは道具ではなく、自社でどこまで書くかの型のほうです。

どちらで進めるかは、二つの問いで決める

案件ごとに迷わないよう、判断は二つの問いに絞ります。三か月後もこの仕組みを使い続けるか。作った本人以外が触る可能性があるか。どちらか一方でも当てはまるなら、先に仕様を書きます。両方とも当てはまらない場合に限り、話しかけながら作って構いません。

この二問は、意外なほど実務に当てはまります。展示会の当日だけ使う集計、一度きりの調査のための整形、方向を確かめるための画面の試作。これらは三か月後には存在しないので、仕様を書く手間のほうが高くつきます。一方、毎月の定例で使う集計、問い合わせの受付、承認の記録は、作った翌月にはもう本人以外が触ります。マーケの業務でいえば、広告の実績を毎月まとめる集計、資料請求の受付、配信の停止依頼の記録が該当します。いずれも担当者が変わることを前提にすべき業務です。

中間もあります。しばらく使うが、範囲は限られている補助的な機能です。この場合は、何を作るかと受け入れの基準だけを書き、作り方の設計は省く軽い形で足ります。三段に分けておくと、毎回どこまで書くかで揉めなくなります。

先に仕様を決める進め方の四工程

先に仕様を書くといっても、分厚い文書を人が書くわけではありません。文書の初稿はAIに書かせ、人は判断と妥当性の確認に集中します。工程は四つです。

この順で進めると、人の仕事は「何を、なぜ作るのか」の判断と、書かれた内容が妥当かどうかの確認に寄ります。コードを読む時間が減り、決めごとを読む時間に置き換わるのが、この進め方の実質的な変化です。決めごとであれば、開発を専門にしていない担当者でも読めます。

一工程目で書く文書の分量は、多くの場合で用紙一枚から二枚に収まります。長くする必要はありません。むしろ、長い仕様は読まれなくなり、読まれない仕様は無いのと同じです。一枚で足りないと感じたときは、書く量が足りないのではなく、一度に作ろうとしている範囲が広すぎる合図だと考えて、分けて扱います。

仕様に書く項目の一覧

何を書けばよいかで手が止まりやすいので、そのまま使える一覧にしておきます。全部を毎回書く必要はありませんが、書かない項目は「今回は決めない」と明示的に選んだ状態にしてください。

十二項目のうち、社内の議論で最も価値が出るのは五番目と八番目です。やらないことを決めると、範囲がじわじわ広がる現象が止まります。人が決める欄を書き出すと、どこまで任せるかの議論が、抽象論ではなく具体的な項目の話になります。

八番目の書き方には注意が必要です。重要な判断は人が行う、と書いても線は引けません。送信先の最終確認、金額の確定、社外に出す文章の最終稿、といった業務の言葉で並べます。読んだ人が、自分の作業のどれが該当するかを判断できる粒度が目安です。あわせて、その欄をAIが埋めた形跡があれば差し戻す、という扱いまで決めておくと運用に乗ります。

曖昧な言葉を、条件と数に置き換える

仕様を書いても、書き方が曖昧なら結果は変わりません。使いやすくする、しっかり確認する、なるべく速く。こうした表現は、読む側が解釈を補います。補った解釈は書かれないので、思いつきで作らせているのと同じ状態になります。

解決策として広く使われているのが、条件と振る舞いを型にはめて書く方法です。2009年に要求の書き方をテーマにした国際会議で発表された五つの型が、いまもそのまま通用します。日本語に直すと次のようになります。

曖昧さを消す五つの型
・常に成り立つこと：この仕組みは、常に◯◯であること
・出来事が起きたとき：◯◯が起きたら、この仕組みは△△すること
・ある状態の間：◯◯している間、この仕組みは△△すること
・特定の設定のとき：◯◯の設定になっている場合に限り、△△すること
・異常が起きたとき：もし◯◯なら、この仕組みは△△して止まること

五つ目が最も抜けます。正常に動いたときの記述は誰でも書きますが、失敗したときにどうするかは書かれません。異常時の型を一行ずつ埋めるだけで、静かに間違い続ける仕組みはかなり減ります。

• 数で書けるものは必ず数で書く。速い、多い、といった形容は残さない
• 境界の値を明示する。ちょうど上限のとき、ゼロ件のとき、期限当日のとき
• 扱ってはいけない情報は、種類ではなく書類の名前で挙げる
• 決めないと選んだ項目は、決めていないと明記する。空欄のまま渡さない
• 仕様を直したら、その場で文書のほうも直す。直さない文書はすぐ嘘になる

レビューと受け入れは、人が読む場所を先に決める

仕様を書く進め方に変えると、人が読む場所が前にずれます。コードができてから読むのではなく、作り始める前に仕様を読むほうが、はるかに安く直せます。この配置換えが、実際の負担を減らす最大の要因です。

読む観点は三つで足ります。やらないことの範囲が業務の実態と合っているか。異常時の動きが全部の入口に書かれているか。受け入れの基準が、読んだ人によって解釈の割れない書き方になっているか。コードの良し悪しではなく、決めごとの抜けを探す読み方に切り替えます。開発を専門にしていない担当者が価値を出せるのは、この三つです。読む時間の目安は、用紙二枚の仕様で三十分です。ここで見つかる抜けは、作った後に同じ抜けを見つけた場合より、直す費用がひと桁下がります。

受け入れの確認も、範囲を先に固定します。決めた条件を満たしているか、想定外の入力で止まるか、記録が残っているか。この三点だけを見ると決めてしまうと、作った本人でなくても確認できます。あわせて、なぜその作りにしたのかを一行で書かせておくと、後から前提を追えます。

うまくいかない型と、仕様を書かなくてよい場合

最後に、この進め方が空回りする形をまとめます。多くは、書く量を増やす方向に走ったときに起きます。

• 最初に全機能を完全に書こうとする：書き終わる前に前提が変わり、文書ごと捨てることになる
• AIに仕様を全部書かせて読まない：長い文書が自動で生まれ、誰も読まないまま作業が進む
• 仕様を直さずにコードだけ直す：二回目の変更で、文書と実物が食い違って使えなくなる
• 割らずに一度に全部作らせる：どこで方向がずれたのかを特定できない
• 受け入れの基準を「問題なく動くこと」とする：判定できないので、結局は詳しい人の感覚に戻る
• 使い捨ての試作にも仕様を求める：手順が重くなり、現場が隠れて作り始める

二つ目は2025年後半の技術動向のまとめでも指摘されています。手順が重厚で小さな作業には過剰になりやすいこと、レビューしづらい長大な仕様が自動で生成されがちなこと、作業の規模と種類によって使い勝手が大きく変わること。道具を入れれば解決するという話ではないという点は、導入前に共有しておいたほうがよい前提です。

導入は一機能から始めます。中くらいの新機能を一つ選び、四工程を通しでやってみる。生成された仕様を読んで、自社の言葉に合わせた型を作る。次に、どの規模から仕様を必須にするかを決めて文章にする。この順で進めると、使い分けの線を、机上ではなく実際にやってみた感触で引けます。

まとめ

AIに作らせた仕組みが作り直しになるのは、性能の問題ではなく、決めていない欄がその場で埋められ、埋めた理由がどこにも残らないからです。原因は四つ。決めていない欄を補完されること、前提が変わっても判断の記録が無いこと、作った本人しか読めなくなること、そして完成の基準が人によって違うことです。大規模な調査では、AIが生成した変更に見つかった問題の24.2%が最新の版にも残っており、時間が経てば誰かが直すという前提は成り立っていませんでした。対策は、二つの問いで進め方を分けることから始まります。三か月後も使うか、本人以外が触るか。どちらかが当てはまるなら、何を作るのかを先に文書にします。仕様には、やらないこと、異常時の動き、人が決める欄、受け入れの基準を必ず入れ、曖昧な形容は数と条件に置き換えます。読む場所は作る前に置き、受け入れの確認は三点に絞って誰でもできる形にします。まずは次に作らせる予定の仕組みを一つ選び、やらないことを三行書き出すところから始めてください。書き出せなかった範囲が、そのまま作り直しの候補です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。