Simon Späti氏は2026年9月26日、AIコードの設計意図を論じるノートを公開しました。10月3日に更新されたノートは、AIコード時代の論点を示します。タイトルは「The Problem is not the AI Code, but Nobody Knows Anything Anymore」です。コードの出来だけでなく、システムのアーキテクチャや、なぜその選択をしたのかをチームが把握できなくなる問題です。
AI支援コードの保守性をめぐる研究は、「AIコードは悪い」という単純な結論ではありません。実リポジトリ分析では、AIが導入した問題の22.7%が最新リビジョンにも残りました。一方、別の保守性実験では、AI支援コードを後から発展させる場合の一律の悪化は確認されていません。
企業が確認したいのは、AI利用を止めるかどうかではなく、別の担当者が設計理由を説明して安全に変更できる状態です。目的、制約、採用しなかった案をArchitecture Decision Record（ADR）に残し、生成前の仕様確認と生成後のレビューにつなげます。
※本記事は2026年10月5日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
AIコードの問題は品質だけではない｜設計意図が抜け落ちる
起点になったSpäti氏のノートは、AIが生成したコードの品質を一律に批判する内容ではありません。システムの構造と意思決定の理由を人やチームが知らないまま、コードや仕様をAIに作らせ続ける状態を問題にしています。
コードがテストを通っても、「なぜこの方式を選んだのか」「別の方式をなぜ採用しなかったのか」が説明できなければ、次の変更で判断をやり直すことになります。担当者が替わったとき、生成時のチャットや個人の記憶だけでは設計の根拠を引き継げません。
この問題は、生成AI活用の質を考えるときにも表れます。回答やコードを採用する前に、目的と制約を人間が確認し、採用理由をチームで共有できるかが分かれ目です。
ポイント
AIが生成したコードの受け入れ条件に、テスト結果だけでなく「設計理由を別の担当者が説明できるか」を加えます。
AI生成コードの負債はどこに残るか｜22.7%の問題が最新リビジョンにも残存
2026年4月26日にv2へ改訂されたarXiv論文です。論文名は「Debt Behind the AI Boom」です。5種類のAIコーディングアシスタントを対象に、6,299 GitHubリポジトリの検証済みAI作成コミット302.6k件を分析しました。変更前後の静的解析で、コードスメル、正確性問題、セキュリティ問題を追跡した研究です。
特定された問題は484,366件で、その89.3%をコードスメルが占めました。5種類すべてのアシスタントで、15%超のコミットが少なくとも1件の問題を導入しています。問題を導入した瞬間の検出だけでなく、その後も残ったかどうかを調べた点が特徴です。
追跡したAI導入問題の22.7%は、リポジトリの最新リビジョンにも残っていました。この数字は研究対象と解析方法に基づくもので、AIコード全体の失敗率ではありません。ただし、生成速度だけを成果指標にすると、修正されない問題が保守コストとして蓄積することを示す材料になります。
生成物を受け入れた時点で静的解析とテストを実行し、指摘は修正チケットに記録します。レビューの役割を「AIが書いた行を読むこと」だけに限定しません。問題がなぜ残ったのか、次の担当者が何を前提にすべきかまで記録します。開発現場のレビュー負荷については、AI生成コード時代のコードレビューも参考にしてください。
| 評価軸 | 見るもの | 残す記録・確認 |
|---|---|---|
| 生成速度 | 実装がどれだけ早く進んだか | 変更範囲、生成物の出所 |
| コード品質 | コードスメル、正確性、セキュリティ、テスト | 静的解析結果、テスト結果、修正チケット |
| 設計意図 | なぜその構造・制約・選択を採ったか | ADRのContext・Decision・Alternatives・Consequences |
| 保守性 | 別の担当者が安全に変更できるか | 変更時間、レビュー指摘、ADRとの整合性 |
この表は、AI導入の判断を速度だけに寄せないための確認項目です。
ポイント
22.7%は全AIコードの失敗率ではありません。自社では生成速度、問題の残存、設計理由の共有を別々に測り、速度だけで導入効果を判断しないことが必要です。
AIコードは常に悪いのか｜保守性研究は一枚岩ではない
AI生成コードの問題を考えるとき、反対方向の研究も確認する必要があります。2026年6月9日に公開されたSpringer Natureの論文「Echoes of AI」は、AI支援あり／なしで作られたコードを別の開発者が発展させる2段階の実験を行いました。
Phase 2の無作為化比較試験はN=75で、全体では151件の解答を収集し、その95.4%をプロのソフトウェア開発者が完了させました。AI支援コードを手作業で発展させる効率について明確な優位性は示されず、処理時間の差は小さく統計的に信頼できませんでした。
コード品質も、従来の頻度主義分析では処置群と対照群に有意差がありませんでした。習慣的なAI利用者が作ったコードではCodeHealthが少し改善する可能性が示されたものの、特定のサブグループに限られます。AI支援コードを一律に禁止する根拠にはなりません。
ただし、この実験は2024年後半に実施され、現在増えているコーディングエージェントの潮流より前のデータです。論文も、過剰なコード生成によるコード肥大化や、開発者が思考負荷をAIへ移すことによる認知的負債を今後の研究課題に挙げています。自社では「新しい担当者が変更できるか」を受け入れテストに加え、設計意図の説明も確認します。
ポイント
AIコードの評価は、コードスメルと保守性を分けて考えます。別の担当者が安全に変更できるかを、自社のコードと業務で確かめてください。
設計意図をADRに固定する｜コンテキスト・決定・影響を残す
Microsoft Azure Well-Architected Frameworkは、設計意図を残す形式としてArchitecture Decision Record（ADR）を推奨しています。ADRは、システムが現在の形になった方法と理由を記録するものです。対象は、構造、主要な品質属性、変更の難しさに影響するアーキテクチャ上重要な判断に絞ります。
記録するのは結論だけではありません。Microsoftは、問題とコンテキスト、検討した選択肢、決定、トレードオフ、確信度、ステータスを項目例として示しています。採用しなかった案を残すと、後任者が同じ比較をやり直すときに、過去の制約を確認できます。
運用では、受け入れ済みのADRを編集しません。決定が変わったときは、新しいADRを作って以前の記録を置き換えます。状態をProposed、Accepted、Supersededのように管理すれば、現在の方針と過去の判断を混同しにくくなります。
最初からすべての実装を文書化する必要はありません。構造、非機能要件、依存関係、API、採用するライブラリや開発プロセスなど、後で変更しにくい判断から始めます。チャット履歴やプロンプトは補助資料にとどめ、チームの決定はリポジトリで参照できる短い記録に移します。
ポイント
ADRは「何を作ったか」だけでなく、「なぜそれを選び、何を捨てたか」を残す記録です。設計意図をコードと同じリポジトリで追える形にします。
AIを速く使うほど運用を変える｜生成前・レビュー・保守の3点
AWS Prescriptive Guidanceは、ADRを決定ログとして集める効果を説明しています。プロジェクトの文脈や実装・設計の情報を引き継ぐためです。最低限、決定のコンテキスト、決定内容、プロジェクトや成果物への影響を含めます。理由に戻れることが、設計意図の消失を防ぐ土台です。
AIを開発工程に組み込む場合は、次の3段階に分けると運用しやすくなります。
- 生成前：目的、非機能要件、制約、採用しない案をADRまたは仕様で確認する。
- 生成後：テストと静的解析を実行し、ADRとの整合性をレビューする。
- 保守中：問題、変更理由、方針の更新を新しいADRやチケットへつなぐ。
AWSは、受け入れたADRを不変として扱い、判断が変わったら新しいADRで旧記録を置き換える運用を示しています。コード変更にはピアレビューと少なくとも1人の承認を求め、ADRとの不一致があればレビューで指摘する考え方です。AIに作業を任せても、人間の責任は設計意図、判断、承認に残ります。
すでに設計理由が失われているシステムでは、Microsoftが示すように、分かっている過去の判断を遡及的にADRへ整理できます。すべてを推測で埋めるのではなく、構造や非機能要件など影響の大きい判断から始め、根拠がない部分は次の変更時に検証する対象として管理します。
AIエージェントを使う場合も、丸投げの成否ではなく、誰が境界を決め、どの記録を見て承認するかを先に決めます。AIエージェントの監督体制を検討するときも、ADRをレビューの参照点に置くと、担当者の経験だけに依存しにくくなります。
ポイント
AIの速度を活かすほど、生成前の意図、生成後の検証、保守中の変更理由を分けて記録します。人間の判断をADRとレビューに残すことが、技術的負債の見えにくい蓄積を抑えます。
よくある質問
Q. AIが書いたコードは、すべて技術的負債になりますか？
すべてではありません。実リポジトリ分析ではAI導入問題の残存が確認された一方、保守性実験ではAI支援コードの一律の悪化は確認されていません。対象、手法、品質保証の有無を分けて判断します。
Q. ADRには何を書けばよいですか？
少なくとも決定のコンテキスト、決定内容、影響を書きます。実務では検討した選択肢、トレードオフ、確信度、ステータスも加えます。
Q. 既存システムで設計意図が分からない場合はどうしますか？
重要な構造、非機能要件、依存関係などの判断から、分かっている根拠と制約を整理して遡及的なADRを作ります。判断が変わったら、旧記録を改変せず新しいADRで置き換えます。
まとめ
AI生成コードをめぐる課題は、コードの品質だけではありません。実リポジトリ分析ではAI導入問題の22.7%が最新リビジョンにも残りましたが、保守性実験はAI支援コードの一律の悪化を示していません。利用の可否を二択にせず、品質と設計意図を別々に測る必要があります。
まずは変更しにくい構造、非機能要件、依存関係、APIなどの判断をADRに残します。生成前に目的と制約を確認し、生成後にテスト・静的解析・レビューを行い、方針が変わったら新しい記録へつなげてください。
ポイント
AIにコード生成を任せても、設計の目的・制約・選択理由・承認は人間が管理します。ADRをコードと同じ変更の流れに置くことが、次の担当者へ意図を渡す最小単位です。
関連記事
- AI生成コード時代のコードレビューを解説｜開発現場のボトルネックと対策
- AIエージェント実験の失敗事例を解説｜丸投げを防ぐ監督体制のポイント
- 生成AI活用の質を解説｜回答の丸写しを防ぐ組織運用のポイント
- 生成AIの使いこなし格差を解説｜組織で整える運用ルールと研修のポイント
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。