AIコーディングの「3つの負債」を溜めない技術 — 個人の実践から組織の仕組みへ

こんにちは。ACS事業部の越川です。

2026年3月12日、@ITに「AIコーディングはなぜ後から苦しくなるのか？」という記事が公開されました。従来の「技術負債」に加えて、「理解負債」と「認知負債」という新しい概念が紹介されています。

atmarkit.itmedia.co.jp

AIコーディングツールを日常的に使っている身として、この記事の問題提起はよく理解できます。しかし同時に、すでにその時代は来ているし、対策も実践の中で見えていると感じました。

本記事では、3つの負債それぞれに対して、私が日々の業務で実践している具体的な防ぎ方を紹介します。

3つの負債とは何か

@ITの記事では、AIコーディングが生む負債を3つに分類しています。

負債	定義
技術負債	質の低いコード設計による将来の修正・改善コスト
理解負債	AIが生成したコードの仕組みを開発者が理解できない状態
認知負債	AI依存によりシステム全体の設計思想を把握できなくなる状態

技術負債は以前からある概念ですが、理解負債と認知負債はAI時代に新たに生まれた問題です。いずれも「AIが書いてくれたから動く。でも、なぜ動くのかわからない」という状況に起因します。

実践1: 技術負債 — AIが生んだ負債はAIが返しやすくなった

技術負債については、AI自身が解決を手助けできる時代に入っています。

GitHub Copilotのコードレビュー機能やエージェントモードを使えば、AIが生成したコードの品質チェックやリファクタリングをAI自身に任せられます。ポイントは、生成と検査を別のプロセスにすることです。人間の開発でも「書いた人と別の人がレビューする」のは当たり前のプラクティスです。AIでも同じことが可能になっています。

ただし、AIレビューが万能というわけではありません。設計判断や非機能要件（パフォーマンス、セキュリティ、運用性など）は、人間が確認すべき領域として残ります。AIが得意なのは、コーディング規約の遵守やリファクタリングといったルール化できる範囲の品質改善です。その範囲を見極めたうえでAIに任せれば、技術負債は以前より返しやすくなっています。

実践2: 理解負債 — インストラクションファイルに判断基準を書く

理解負債は「AIが書いたコードを誰も理解していない」状態です。

ここで重要なのは、理解の主体が人間だけである必要はないという発想の転換です。「人が理解している」か「AIが文脈を保持している」か、どちらかが成立していれば問題は起きません。どちらも理解していない状態が負債になります。

私はClaude CodeのCLAUDE.mdやGitHub Copilotのcopilot-instructions.mdに、プロジェクトの判断基準やルールを書いています。例えば：

このプロジェクトで守るべきコーディング規約
なぜこの構成を選んだのかの背景
過去に踏んだ失敗と、その対策

これにより、AIは「なぜそう書くべきか」の文脈を持った状態でコードを生成します。人間の判断基準がインストラクションとして明文化されている限り、理解は失われません。

さらに、この「インストラクションを書く」という行為自体が、自分の理解を整理するプロセスでもあります。書けないということは、理解していないということ。インストラクションファイルは理解負債の検知器にもなります。

もちろん、最終的な責任は人間が持つ必要があります。障害対応や監査対応の場面では、AIが保持している文脈だけでは不十分で、人間が追える状態を確保しておかなければなりません。また、AIが保持できる文脈にはコンテキストウィンドウという技術的な上限もあります。大事なのは「人間がすべて理解する」から「人間とAIで理解を分担し、人間側の持ち分をゼロにしない」へ、考え方を更新することです。

以前の記事で、このアプローチを詳しく紹介しています。

techblog.ap-com.co.jp

実践3: 認知負債 — フィードバックを蓄積して設計思想を育てる

認知負債は「AIに任せすぎて、システム全体の設計思想を把握できなくなる」状態です。

これについて、私が実感しているのは中途半端にAIに任せるのが一番危険だということです。全体をAIに委ねるなら一貫性が保たれます。全体を人間が設計するなら理解は残ります。問題は「部分的にAIに投げて、全体像を誰も持っていない」という状態です。

私の対策は、フィードバックを仕組みとして蓄積することです。

具体的には、ブログ執筆のワークフローで lessons-learned.md というファイルを運用しています。レビューで得たフィードバックや失敗から学んだことを、AIと協力して記録していきます。

このファイルはCLAUDE.mdから参照されるように設定してあるので、AIは次の作業で過去の学びを踏まえて動きます。つまり、設計思想が人間とAIの間で共有・蓄積される仕組みになっています。

回を重ねるごとに、AIの出力が自分の考え方に近づいていく。この積み重ねが、認知負債を防ぐ最も実践的な方法だと考えています。

techblog.ap-com.co.jp

スケールが大きくなったらどうするか

ここまで紹介した3つの実践は、個人やPoC・MVPのような小さなプロジェクトではよく機能します。1人とAIで全体を把握でき、インストラクションファイル1つで文脈が収まるからです。

しかし、チームが増え、リポジトリが分かれ、プロジェクトが大規模になると、話は変わります。

チームごとに設計判断がバラバラで、全体の一貫性を誰も把握していない
なぜこの構成にしたのかが、コードにもドキュメントにも残っていない
ある人のAI環境に文脈が閉じていて、その人がいなくなると文脈ごと失われる

これらはまさに、認知負債が組織スケールで表面化した状態です。

大規模で認知負債を防ぐには、個人の実践だけでは限界があります。組織として仕組みを用意する必要があります。

蓄積した文脈が「負債」に変わる瞬間

実は、フィードバックや判断の蓄積にも落とし穴があります。

例えば、プロジェクトの途中で「A案で行きます」→「B案の方がいい」→「やっぱりA案に戻す」という判断の変遷があったとします。もしB案の情報がそのまま残っていたら、AIはそれを現在のコンテキストとして読んでしまうかもしれません。蓄積すること自体がコンテキスト過多を招き、新たな負債になるのです。

この問題を解決するのが、ADR（Architecture Decision Records）です。

ADRで「今の判断」と「過去の経緯」を分離する

ADRは、設計判断の「なぜ」を記録するドキュメントです。コードには「何をしたか」は残りますが、「なぜそうしたか」は残りません。ADRはその「なぜ」を残すための仕組みです。

ADRにはステータスがあり、判断の変遷を管理できます。

ステータス	意味
Accepted	採用。現在有効な判断
Superseded	置き換え済み。新しいADRに取って代わられた

先ほどのA案・B案の例なら、こうなります。

ADR-001: A案を採用        → [Superseded]（ADR-002により置き換え）
ADR-002: B案に変更        → [Superseded]（ADR-003により置き換え）
ADR-003: やっぱりA案に戻す → [Accepted]

AIが参照すべきは Accepted のADRだけです。Supersededは「過去にこういう判断があった」という記録として残りますが、現在の仕様検討からは除外されます。「なぜB案をやめたのか？」を知りたければ、ADR-003を辿ればいい。

インストラクションファイルやPRと組み合わせれば、判断の「今」と「経緯」を分離して管理できます。これにより、蓄積がコンテキスト過多にならず、必要なときだけ過去を辿れる状態が実現します。

組織の仕組みとしてスケールさせる

ADRに加えて、以下のような仕組みを組み合わせることで、個人の実践を組織にスケールさせられます。

テンプレートで初期構成を標準化する（ゴールデンパス） — 新規プロジェクトの立ち上げ時にインストラクション付きの構成が自動生成されれば、個人の力量に依存しない
開発者ポータルでサービスカタログを一元管理する — 誰が何を持っているか、依存関係はどうなっているかを、人にもAIにも見える状態にする

個人レベルの実践をスケールさせるのは、Platform Engineeringの考え方そのものです。私が所属するACS事業部でも、こうした組織的なアプローチに取り組んでいます。

まとめ: 負債はツールの問題ではなく、使い方の問題

負債	個人の実践	組織の仕組み
技術負債	AIにレビュー・リファクタリングさせる	CI/CDにAIレビューを組み込む
理解負債	インストラクションに判断基準を書く	ADRで設計判断の「なぜ」を記録する
認知負債	フィードバックを蓄積して設計思想を共有する	開発者ポータル・ゴールデンパスで標準化する
蓄積の負債化	定期的な棚卸しとルール昇格	ADRのステータス管理で「今」と「経緯」を分離する

3つの負債はいずれも、AIを使うこと自体が原因ではありません。 AIとの協働に仕組みがないことが原因です。

インストラクションファイルを書く。フィードバックを蓄積する。AIにもレビューさせる。どれも特別なツールや高度な技術を必要としない、日々の実践で始められることです。

AIコーディングツールを使い始めて「なんだか負債が溜まっている気がする」と感じたら、今日からできることは2つだけです。

インストラクションファイルに3項目だけ書く。 プロジェクトで一番大事なルール、選んだ技術の理由、過去に踏んだ失敗。これだけで、AIが文脈を持って動き始めます
レビューで受けた指摘を1件だけ記録する。 lessons-learned.md でも、テキストファイルでも、形式は何でも構いません。1件の記録が次の改善につながります

どちらも5分で終わります。この小さな一歩が、負債を蓄積ではなく資産に変える仕組みの始まりです。