AI 時代に仕様書が見直される理由：開発基盤の差が表面化する

コーディングアシスタントがプルリクエストの大半を書き、そのままマージされたとき、作業は終わったと考えたくなります。しかし実際には、その思い込みこそが本当の作業の始まりであることが多いのです。

AIコーディングツールはすでに標準的な道具になりました。Google Cloudの2025年DORAレポートでは、約5,000人の技術者を対象とした調査で、90%が仕事でAIを使っていると回答しました。同じ調査では、生成されたコードをほとんど、あるいはまったく信頼していないという回答が30%に上っています。2つ目の数字こそ、残された仕事を表しています。

コードを書く仕事はもう「ごく一部」に 

開発者の中には、自分のコードの大半が AI によって生成されていると見積もる人も出てきました。残る作業は、細部を補うこと、ロジックが成り立っているかを確かめること、そして新しいコードをシステム全体に組み込むことです。この変化は、一言で表せます。コードを書くことは、仕事のごく一部になりました。確認することこそが、仕事の中心です。 

そのチェックがどれだけうまくいっているかは、内側からは思いのほか判断しづらいものです。2025 年初頭に経験豊富なオープンソース開発者を対象として行われたランダム化比較試験で、METR は次の結果を報告しました。開発者は AI によって作業が 24% 速くなると予想し、タスクを終えた後でも 20% 速くなったと感じていました。ところが実測では、作業時間は 19% 長くなっていました。METR はその後、この結果は現状に合わなくなったとしています。2026 年 2 月のフォローアップでは、2026 年初頭には開発者が AI からより多くの成果を得ていた可能性が高いとされています。ただし、新しいデータは根拠として弱く、その程度までは示せないとのことです。理由の一つは、AI なしでは作業したくないという開発者が増えていることです。それでも、今後も残る知見は、この認識のずれです。AI で生産性が上がったと感じることは、AI が実際に何を生み出したかを示す証拠にはなりません。

「ほぼ正しい」コードは明らかな誤りより見つけにくい 

このエンジニアが気づけたのは、コードベースを熟知していて、どこかおかしいと感じたからです。判断の拠りどころとなる知識がなければ、捏造されたコードはそのまま通ってしまいます。

根本的な問題は、AI の出力が明らかに間違っていることは少なく、たいていは「ほぼ正しい」ことにあります。ほぼ正しいものは、明らかに間違っているものより見つけにくいのです。生成されるコードが増えるほど、コードベースの中身を細部まで把握している人は減り、レビュー担当者が確認すべきコードは大幅に増えます。

リポジトリのデータも同じ傾向を示しています。GitClear の 2026 年の分析では、6 億 2,300 万件のコード変更を対象に、重複コードブロックが 2023 年と比べて 81% 増えていました。一方、リファクタリング(「移動」)されたコードは、変更行全体の 21%(2022 年)から 3.8%(2026 年)に減っています。このデータが示すのは AI 導入期を通じた傾向であり、AI がすべての行を書いたことを証明するものではありません。それでも、方向性は一貫しています。新しいコードは増え、既存のコードの整理は減っているのです。 

経験則は次のとおりです。アルゴリズムで確認できることは、AI ではなくアルゴリズムに任せる。決定論的なチェックは毎回同じ結果を返すため、その結果を証拠の一部として使えます。 

責任は変わらないが負担は増えた 

出荷したものに責任を負うのは人です。コードを書いたのが人であっても、モデルであっても、それは変わりません。モデルにプロンプトを与えるだけでは、安全規格への準拠も、コーディング標準の遵守も実現できません。丁寧に頼めば成功率は上がるかもしれませんが、それは証拠にはならないのです。だからこそ、静的コード解析(実行せずにソースコードを解析し、問題を検出する自動ツール)は、誰が、あるいは何がコードを書いたかにかかわらず、パイプラインに組み込んでおく必要があります。結局のところ、AI は副操縦士であり、機長ではありません。 

責任の所在は変わらない一方で、その裏にある作業量は急増しました。DORA の 2025 年の調査では、AI の導入はデリバリーのスループット向上と同時に進んでいるものの、デリバリーの安定性は依然として低下していることがわかりました。自動テストと迅速なフィードバックループが充実しているチームは、増えた作業量を吸収できます。そうでないチームでは、それが不安定さとなって表れます。 

品質の共同責任が AI によって試される 

開発者がコードを書き、別のテスト部門がバグを見つける、という厳格な分業を続けているチームは、今ではわずかです。開発者が自分でテストを持ち、変更のたびに継続的インテグレーション(CI)が実行され、品質は全員の責任になっています。

AI は、この仕組みに大きな負荷をかけます。コードの大部分をモデルが生成する場合、「品質の責任は開発者にある」と言えるのは、開発者がそのコードの正しさを示せるときだけです。ビルドが通ることや、同時に生成されたテストに合格することだけでは足りません。

安全規格が求められる開発では、この要求は以前から明確にされてきました。ISO 26262 や IEC 62304 などの規格は、要件が実装され、検証されたことを示す、文書化されたトレーサブルな証拠を求めます。故障による被害が大きいほど、求められる厳密さも高くなります。ほとんどのチームに、そこまでの形式性は必要ありません。ただし、その根底にある習慣は取り入れられます。「完了」とは、マージされたことではなく、動作が示されたことを指すのです。 

ドキュメント軽視のツケ

だからこそ、仕様が再び重要になっているのです。

ここから、チームの差が開き始めます。それは、どの AI ツールを使っているかとは関係ありません。

原因は 10〜15 年前にさかのぼります。多くのチームがアジャイル開発への移行から受け取ったのは、「短いサイクルで開発しよう」という教訓ではありませんでした。「ドキュメントは省略してもよい」という認識です。スプリントを始め、すぐにコーディングを始め、2 週間ごとにリリースする、という進め方が定着しました。

その結果、要件はタイトルだけに近いものになり、その機能が何をすべきかを説明する内容は、どこにも残りませんでした。

以前は、そのコストの多くは人の間で生じていました。開発者とテスト担当者が、あいまいな同じ要件を別々に解釈していたのです。今では、そのコストが積み重なっていきます。AI が必要とするのは、まさにそうしたチームに欠けている入力だからです。本物の要件ではなくタイトルだけをモデルに渡せば、返ってくるのはコードではなく推測です。

だからこそ、仕様書が再び重要になっています。

AI で強くなるチームと AI で課題が露呈するチームの違い 

軽量な Ready のレビューでも、十分に機能します。20 分の枠を確保しても、たいていは 10 分で終わります。さらに重要なのは、多くのチームで「Doneの定義」に品質基準が一切含まれていないことです。「Readyの定義」を使っているチームもわずかです。これは、不十分な要件が開発者(人であれ AI であれ)に届く前に止める関門になります。

要件や設計の問題は、後になって直すほどコストが膨らみがちです。その上に積み上げたものすべてを、あわせて修正しなければならないからです。定期的なクリーンアップ用のスプリントでは、この問題は解決しません。

コードを半年間ためこみ、次のリリース前に慌てて整理する。このやり方がうまくいかないのは、構造的な理由があります。リリースの 2 週間前にクリーンアップを承認する人はおらず、リリースの 2 週間後には、その必要性に気づく人もいないからです。

問題を1時間以内に表面化させる、継続的で自動化されたチェックのほうがはるかに効果的です。

次の世代に迫る判断力のギャップ

今この仕事をうまくこなしているエンジニアは、モデルの出力を見て、使うか捨てるかを素早く的確に判断できます。この直感は、生まれつきのものではありません。AI が登場するはるか前から、コードを書き、読み、直す経験を何年も重ねて培われたものです。 

本当に懸念されるのは、そうした判断の拠りどころを持たずに育つ世代です。優れたコードがどのようなものかに何年も触れていなければ、AI の出力を判断する基準がありません。数年のうちに、キャリアの最初から AI を使える環境にあり、それ以外の働き方を知らないために比較もできない開発者が、一つの世代として現れることになります。 

今すぐ取り組むべき4つのこと

品質の基準を下げるのではなく、品質の高い仕事をするための障壁を下げる

コーディング標準は、マージのたびに自動でチェックします。問題はエディター上でリアルタイムに表示します。文を書き終える前にスペルミスを知らせてくれる、スペルチェックのような仕組みです。全員を品質エンジニアにすることはできませんが、品質エンジニアのように行動するためのコストを、限りなくゼロに近づけることはできます。 

研修カリキュラムだけでなく、実際に触れる機会を中心にオンボーディングを組み立てる

新しいエンジニアには、製品が壊れた状態で大規模にリリースされたとき何が起きるかを、できるだけ早い段階で実際に見てもらいましょう。

意図を書き残し、検証可能な状態に保つ

要件と、意図したアーキテクチャが仕様です。人がコードより先にこれらを書くのは、システムが何をするべきかを記録するためです。一度レビューされただけで棚上げされれば、実態とずれていきます。ツールがチェックできる形で保てば、コードが設計と今も一致しているかを確かめる、継続的なテストになります。 Axivion アーキテクチャ検証のようなツールは、意図したアーキテクチャと実際のコード構造を継続的に比較することで、これを実現します。  

入力となるドキュメントが良くなければ、コードが良くなる道筋はなく、その後に続くものが良くなる道筋もありません。

説明的なドキュメントはコードに追従させる 

API リファレンスや、実際の依存関係の図のように、コードが現在どう動いているかを説明するドキュメントは、コードそのものから生成するほうが、はるかに維持しやすくなります。コードはすでに機械が読める形だからです。コードをビルドする同じパイプラインで生成しているチームもあり、両者が気づかないうちにずれることはありません。

意図が書き残され、現状の説明が生成されていれば、両者を比較できます。差異が見つかれば、それはコードが設計からずれているか、設計の更新が必要か、のどちらかを意味します。

 意図を管理するツールが何であれ、チーム全員が理解できる形にしておいてください。アーキテクチャモデルを読んだり更新したりできる人が 1〜2 人しかいないプロジェクトは、その人たちが去った日に深刻な問題を抱えます。専門家にしか理解できない高度なモデルよりも、誰もが読める単純な箱と矢印のほうが、プロジェクトの役に立つことも少なくありません。 

仕様書の時代がふたたびやってきた 

チームの成否を分ける変数は、AI ではありません。AI は増幅器です。DORA の 2025 年版レポートも、調査データから同じ結論に至っています。AI は増幅装置である。では、何を増幅しているのか？のです。

明確な要件、検証可能なアーキテクチャ、軽量でも実効性のある品質ゲートといった、地味な基本を守ってきたチームこそ、AIによって速く進められるようになっているチームです。

その規律をおろそかにしてきたチームは、今、その代償に気づき始めています。かつて人の頭の中にあった知識は、コンテキストウィンドウには収まらないからです。この記事の前半で紹介した、捏造されたコードサンプルに気づけたのは、AI の外に判断の拠りどころがあったからです。それは、モデルが登場するずっと前から、長年の経験によって培われたものでした。

チームにその基準がなければ、ツールが救ってくれることはありません。むしろ、弱点を浮き彫りにするでしょう。