「意図負債」とは何か——AIエージェントが肩代わりできない「なぜそう作ったか」の設計

「意図負債」のよくある質問【5問5答】

私たちが内製化のご相談をお受けする中で、繰り返しいただく質問があります。先に1問1答でお答えし、そのうえで詳しくご案内します。

Q1. 意図負債とは何ですか

システムが「なぜ今の形なのか」を説明する理由・目的・制約が、外に書き出されていない状態を指します。2026年にソフトウェア工学の研究者が提唱し、記事後半で出典を示す論文で定義された概念です。ポイントは「外在化」の一語にあります。誰かの頭の中に理由があっても、それは負債のまま。コードベースが整っていても意図負債は高くなりえます。

Q2. 技術的負債や認知負債と何が違うのですか

帳簿が3つに分かれます。技術的負債はコードの中にあり、認知負債は人とチームの理解の中にあり、意図負債は「書き出された知識」の中にあります。3つは独立して動きます。静的解析が全て緑で、担当者が実装を説明できる状態でも、「なぜその仕様にしたか」が残っていなければ意図負債だけが膨らんでいきます。

Q3. なぜAIエージェントには返済させられないのですか

技術的負債はエージェントがリファクタで減らせます。認知負債もエージェントに説明させれば一部は回復します。しかし意図は、人から出すしかない入力です。エージェントに「なぜこうしたのか」を問うと、それらしい理由を組み立てて返してきます。もっともらしさは、当時の判断とは別物。ここが落とし穴になります。

Q4. 自社に意図負債が溜まっているか、どう確かめられますか

一番早いのは、直近3か月のうちに消えたガード節や条件分岐を1つ選び、「なぜこれが必要だったのか」を関係者に聞いてみることです。答えが「たしか何かあった気がする」で止まるなら、その一帯の意図は失われています。記事後半に5つの質問による診断を載せました。

Q5. まず何から書けばいいですか

「やってはいけないこと」からです。仕様書より先に禁止事項を書きます。禁止は意図が最も濃く凝縮された形で、しかも書く側の負担が小さい。私たちが顧客の内製担当に最初に渡すのも、たった2行の禁止事項でした。詳しくは「まず試すなら」でご説明します。

「秘伝のタレ」と呼ばれていた工賃表の話

先に、AIがまったく関係ない場面から始めさせてください。意図負債はAIが作った問題ではなく、AIが値段を書き換えた問題だからです。

ある合成樹脂・産業資材メーカーで、見積業務の棚卸しをしていたときのことです。社内で「秘伝のタレ」と呼ばれているExcelの工賃表がありました。営業を率いる方の説明は率直でした。「細かすぎて、どこに何が書いてあってどのケースはどの工賃を使うのかを理解した人じゃないと使えない。新入社員に渡して『これで検索して』と言っても、使いこなすのに時間がかかる」。

注目したのは「理解した人じゃないと使えない」という部分です。使えないのは操作ではなく、どのケースにどれを当てるかという判断でした。表の中に判断基準が書かれていないので、基準を知っている人の脳が表の一部として機能している状態です。

隣にいた原価管理の担当の方が、さらに踏み込みました。「中身は7割くらいブラックボックス化していて、Excelで配信されるので各担当がそれぞれカスタマイズしてしまう。部材を一つ変えるにも全シートのセルを一個一個探して変える。二重で計上していた箇所もあった」。

二重計上が起きたのは、計算ミスではありません。どこで何を計上する約束だったのかが共有されていなかったからです。

この工賃表は、どの負債でしょうか。

技術的負債ではありません。Excelは壊れていないし、計算式も動いています。認知負債でもない——担当者たちは使い方を知っていて、現に毎日見積を出していました。欠けているのは一つだけです。「この工賃がなぜこの数字なのか」が、どこにも書かれていない。 決めた人はいたはずです。その人の頭の中には理由があったのでしょう。けれど外に出ていないので、20年後の新入社員には再現できない。

「秘伝のタレ」という社内呼称が、実はすべてを言い当てていました。レシピはある。なぜその配合なのかが無い。

意図負債とは何か——コードは答えで、意図は問いだった

このセクションで言いたいことは一つです。意図負債の核心は「書かれていない」ではなく、「外に出されていない」にあります。

概念の出所をはっきりさせておきます。Margaret-Anne Storey教授らが2026年に論文を発表しました。これはソフトウェアの健全性を3つの負債に分解した研究です。意図負債はそのうちの一つで、「システムが今の形である理由・目標・制約が、外在化されていない、あるいは失われていく状態」と定義されています。

この概念を実務の言葉に落としたのが、Addy Osmaniによる解説「The Intent Debt」でした (出典は記事末尾)。読んでいて膝を打った一文があります。コードは答えであり、意図はその問いそのものだった——という整理です。

これは言葉遊びではありません。コードを読めば「何をしているか」は分かります。分からないのは「何を解こうとしていたか」です。答案用紙だけが残って、問題文が捨てられている。だから答案を書き換えようとしたとき、何を守るべきかが決まらない。

私たちの顧客で、この構造をそのまま口にした方がいました。ある建材メーカーで生産管理を統括する方は、図面チェックの現場をこう説明しています。「検図・工作図の担当者の入れ替わりが激しく、教える時間がないため、作業の指示のみになりがち」。

指示だけが伝わって、なぜその指示なのかは伝わらない。そして同じ方が、原因を一言で言い当てていました。図面が2Dであるため、現場を見ないと設計の意図が理解しにくいのだ、と。

「設計の意図」。現場の人が自然に使っていた言葉が、学術的な定義とぴたりと重なりました。図面には寸法が書かれています。なぜその寸法なのかは、現場を歩いた人の頭にしかない。つまり設計意図は図面の外側にあり、入れ替わりが激しければその頭ごと会社から出ていきます。意図負債を「ドキュメント不足」と訳してしまうと、この構造を見落とします。足りないのは量ではなく、判断の理由という特定の一種類です。

技術的負債・認知負債・意図負債は、別々の勘定である

3つは混ざりやすいので、表で切り分けます。

	技術的負債	認知負債	意図負債
どこにあるか	コードの中	人とチームの理解の中	書き出された知識の中。
何が欠けているか	設計の素直さ	共有された理解	判断の理由・制約。
測れるか	静的解析で測れる	聞けば分かる	失ってから気づく。
AIに返済させられるか	リファクタで減る	説明させれば一部回復	返済させられない。
症状の出方	変更に時間がかかる	質問が特定の人に集中する	変更の可否が決まらない。

重要なのは、3つが独立して動くという点です。綺麗なコードベースでも意図負債は高くなります。論文が強調しているのもそこでした。

国内でも整理は始まっています。開発者ブログで認知的負債と意図的負債を切り分けた記事が出てきました。つまり概念の輸入自体はもう起きています。ただ分量は短く、測り方までは踏み込んでいません。

ここで一つ、言葉の使い方について申し上げておきます。「負債」という比喩が雑に使われすぎている、という問題意識を私たちは持っています。何の勘定なのかを言わずに「負債が溜まっている」と言っても、返済計画は立ちません。3つのどれなのかを先に決める。そこから始める必要があります。

なお、認知負債に近い概念として「理解負債」があり、こちらは別の記事で詳しく扱いました。症状の見分け方と、請求書が誰に届くのかを整理しています。合わせて読むと3つの勘定の関係が立体的になります。

関連記事: 「理解負債」とは何か

なぜAIエージェントだけが、この負債を返済できないのか

ここが記事の中心です。

技術的負債について言えば、エージェントは有能な返済者です。重複を括り出し、500行の関数を割り、テストを足す。認知負債についても、ある程度までは助けになります。「このモジュールは何をしていますか」と聞けば、読んで説明してくれる。チームの理解の空白を、エージェントが埋め戻せる場面は現にあります。

意図だけが違います。Addy Osmaniの指摘はこうです——エージェントは意図を生成できない。意図は、人の側から出すしかない入力だからです。

これを「できないから仕方ない」で済ませると危険です。実際に起きるのは、できないことではなく、できたふりをすることだからです。「なぜこのサービス間は直接呼び出しではなくキュー経由なのか」と問えば、エージェントは一般論として筋の通った理由を組み立てます。耐障害性のため、流量制御のため、疎結合のため——どれも正しそうです。けれど当時の判断理由が「連携先の夜間バッチが2時間止まる日があるから」だったとしたら、再現された理由は全部外しています。そして外していることに、誰も気づけません。

ハルシネーションの話として聞くと、ずいぶん遠い世界の問題に見えるかもしれません。でも現場の感触はもっと生々しいものです。あるプラスチック成形機メーカーの推進課マネージャーは、AI回答100問を比較評価した結果をこう話しました。「間違った回答もいくつかあった。全然畑違いな回答も一部あった。その回答で問題が解決するか微妙で、それを見て結局取説を見に行っちゃうシーンが目に浮かんだ」。

取説を見に行けるなら、まだいいのです。意図負債が深刻なのは、見に行く先が存在しないときです。

請求書は「セッションごと × エージェントの数」で届くようになった

意図負債そのものは、AI以前からありました。先ほどの工賃表がその証拠です。では何が変わったのか。支払いのタイミングと頻度が変わりました。

書かれていない理由のコストは、かつては採用と退職のときにだけ請求されていました。ベテランが辞める、担当が替わる、そのときにまとめて払う。支払いが数年に一度なら、「属人化は良くないよね」と言いながら先送りできます。実際、私たちが棚卸しに入る会社の工賃表や原価表は、10年20年そのまま使われてきたものでした。

エージェントを使うと、この分割払いが成立しなくなります。セッションが始まるたび、エージェントは初対面の新人として現れます。前回何を考えたかを覚えていない。昨日の判断も、3か月前の制約も、書かれていなければ存在しないのと同じ。Osmaniはこの変化を、セッションごと・動かすエージェントの数ごとに積まれる複利として説明しています。

私たちはこれを身をもって確かめることになりました。AI-Pathの働き方は、寝ている間もAIに指示を出し続け、1週間で4〜5個のプロダクトが立ち上がる、というものです。デスクトップに議事録・需要予測・スライド生成といったツールを並行で走らせます。社内ではこの働き方を「エージェントマネージャー」と呼んでいます。

正直に申し上げると、並列数を増やしたときに最初に詰まったのはレビュー速度でした。そこは予想していました。想定外だったのは次の段階です。レビューを速くしても、同じ説明を何度も書いている時間が減らない。3つのセッションに、3回、同じ前提を打ち込んでいる。あれは意図負債の利息を現金で払っていた時間でした。

関連記事: エージェントマネージャー

誤解のないように申し上げます。エージェントを増やすのが悪い、という話ではありません。並列化の効果は実際にあります。ただ、意図を外に出していない状態で並列数を上げると、利息の支払いが並列数に比例して増えます。先に外在化しておけば、同じ並列数で成果だけが増える。順番の問題です。

意図負債の症状チェック——5つの質問

測る指標がないのが、この負債の厄介なところです。私たちも厳密な定量指標は持てていません。海外の一次情報を当たっても、概念を語る文章には数字が出てきませんでした。論文も実務記事も、測り方までは踏み込んでいない。だから正直に書きます——これは数値ではなく、質問で検出するしかない負債です。

自社の状態を確かめるなら、次の5つが手早く効きます。

1. 直近3か月で消えたガード節を1つ選び、なぜ必要だったかを聞く。 答えが出なければ、その周辺の意図は失われています。
2. 設計判断の理由が「AIが提案したので」になっていないか確かめる。 これは理由ではなく、理由を聞かなかった記録です。
3. 非機能要件の引き継ぎを確認する。 性能・権限・監査・保持期間。機能は引き継がれても、ここだけ落ちる現象が頻発します。
4. 仕様変更のとき、ドキュメントより先に人を探していないか見る。 探す相手が決まっているなら、その人が意図の保管庫になっています。
5. 新しいエージェントのセッションに、毎回同じ前提を打ち込んでいないか数える。 打ち込んでいる内容は、本来ファイルに置くべき意図です。

5つ目が一番見つけやすいと思います。手が覚えてしまっているので、意識しないと気づかない。私たちもそうでした。

外在化しないと意図にならない——機構で縛った4点

ここからは私たちの実装です。先に申し上げておくと、最初の試みは失敗しました。

当初は「設計判断は記録しよう」という方針を掲げました。方針は掲げた瞬間から守られなくなりました。忙しいときに、人の善意に依存した運用は飛ぶ。当たり前の結論ですが、一度自分たちで踏み抜かないと腹に落ちないものです。

今は4点を機構として縛っています。

1. ルールは配信機構で渡す。 各リポジトリの作業環境に、エージェント向けのルールファイルを機構側から配ります。人が「読んでおいてね」と言って渡すのではなく、セッションが始まった時点でそこに置かれている状態を作る。余談ですが、この記事を書いている作業フォルダにも同じ仕組みでルールが配られていて、だからこの記事は文体のルールに沿って書かれています。

2. 決定は理由とセットで記録する。 何を決めたかだけでは足りません。何を比較して、何を捨てたかまで残します。捨てた選択肢は、半年後にたいてい誰かが再提案してきます。そのときに「検討したが、この理由で捨てた」が出てくるかどうかで、議論の長さが変わります。そして決定を下すのは人間だけ、という線は動かしません。AIは論点を深め、選択肢を並べるところまで。

3. 「やってはいけないこと」を先に書く。 禁止は意図が最も濃い形です。顧客の内製担当に最初に渡すのも、たった2行でした——「最初はデータベースをいじらないものに留めた方がいい。DBをいじると、もう後戻りできない。自分のブランチをどんだけ汚そうが、DBさえ直接いじらなければ大丈夫」「メインに直接マージせず、まずPRを上げる」。この2行には、復旧可能性という制約と、レビューを通すという価値判断が両方入っています。仕様書を100ページ書くより、この2行のほうが遠くまで効きました。

4. 外部の人・外部のエージェントにも同じ意図を渡す。 業務委託先、別のAIツール、顧客側の内製担当。ここで意図が途切れると、せっかく外在化した意味がなくなります。社内のエージェントだけが賢く、外のエージェントが前提を知らないまま本番に触る——という状態は、意図負債の最も危ない現れ方です。

この4点の背後にある考えは、代表が社内で繰り返している一言に尽きます。AIは信用するのではなく、こちらの考えをぶつけ、前提情報や意図を渡し続けることで深い対話が生まれる。 AIは相手を見て会話します。表向きの情報しか渡さなければ、表向きの回答しか返ってこない。

AGENTS.md は設定ファイルではなく「意図の台帳」である

実装の話に降りてきます。AIエージェントに渡すルールファイル——AGENTS.mdやCLAUDE.mdは、いまや事実上の標準フォーマットになりました。ここで設計を間違えると、せっかくの箱が無駄になります。

Osmaniの主張は明快です。AGENTS.mdは**意図の台帳(intent ledger)**として扱うべきで、自動生成された設定の置き場所にしてはいけない。この区別が実務では効きます。

自動生成できる情報は、意図ではありません。ビルドコマンド、ディレクトリ構成、使っているフレームワーク——これらはリポジトリを見れば分かります。エージェントは自分で読めます。わざわざ書いても価値が増えない。

書くべきは、リポジトリを読んでも分からないことです。

• この制約はどの事故から来ているのか。
• なぜこの方式を選び、何を捨てたのか。
• どこまでは自律でやってよく、どこから人の判断が必要か。
• 守らなければ何が壊れるのか。

正直に言えば、私たちも最初はここを間違えました。ルールを足し続けて、誰も——人もエージェントも——通読しない長大なファイルを作ってしまったのです。情報を増やすほど賢くなるつもりでいました。実際に起きたのは、重要な制約が雑多な情報に埋もれて効かなくなる現象でした。

対処は分割です。常に効かせたい少数の制約だけを本体に残し、詳細は別のファイルへ参照で飛ばす。目安として150〜200行を超えたら切り出しを検討する、という線が界隈で共有されていますが、私たちの実感では行数より「全部が同じ重みで並んでいないか」のほうが効きます。禁止事項と参考情報が同じ階層に並んでいたら、もう読まれません。

書いても読まれない意図は、書いていないのと同じ

ここは意見が分かれるところかもしれませんが、私たちの立場を書いておきます。

意図を外在化したつもりで失敗する形が2つあります。配信されない意図と、検証されない意図です。

書いてどこかに置いてあるが、セッションに渡っていない。これが1つ目。ドキュメントは存在するのに参照されない、という古典的な問題が、エージェント時代にそのまま再演されます。人間なら「どこかにあったはず」と探してくれますが、エージェントは探しません。渡されたものだけが世界です。

2つ目は、書いた内容が実態と乖離していくこと。半年前の制約が今も有効なのか、誰も確かめていない。古い意図は、無い意図より危険です。エージェントは疑わずに従いますから。

さて、この話はどこかで聞いた構図だと思います。プロンプトエンジニアリングからコンテキストエンジニアリング、そしてハーネスエンジニアリングへ——AIに渡す情報環境をどう設計するかという議論は、名前を変えながら進んできました。私たちの見方はこうです。技術の名前は変わっても、コアは変わらない。 問いを立てる技術であり、使う人の顔が見えているかどうかであり、渡す意図の質です。ハーネスという器を整えても、入れる意図が空なら出力も空になります。

AI-Path の見解——意図負債は、経営の帳簿に載っていない

最後に、エンジニアの話から少し広げさせてください。この負債の請求書は、経営にも届きます。

ある大手化学メーカーで企画業務を統括する方が、2027年稼働予定の基幹システム刷新について漏らした言葉が忘れられません。自分も進捗を見ているが出来が良いとは思えない、でも、もう後戻りできない——と。要件は固めた。あとはどうにでもしてくれ、という状態だと明かされました。

これは技術の失敗ではないと思っています。要件という「答え」は作られたのに、なぜその要件なのかという「問い」が外在化されなかった。だから途中で「違う」と感じても、何を基準に戻せばいいのか決まらない。後戻りできないのは契約や予算の問題もありますが、根っこには判断基準の不在があります。

もう一つ、重工・製鋼メーカーのシステムグループマネージャーの話も効きました。社内のQC発表での報告によると、開発にAIを入れて対応コールを30%削減したそうです。ところが、反応は鈍かった。「全然評価が悪くて、あまり響かなかった。どうやってやっていいのかな、と思う」と漏らされました。

30%の削減は立派な成果です。響かなかったのは、なぜそれをやるのかが社内で共有されていなかったから。意図負債は、成果の評価までおかしくします。目的が外在化されていない組織では、達成も測れません。

私たちの現場経験では、意図負債の整理は内製化の前提条件です。順番を逆にすると詰まります。別の大手化学メーカーの執行役員が「一度作ったら、メンテナンスはさすがにできない。ある程度は内製化していかないと世の中の力についていけない」と話されていました。まったく同意します。ただ、内製化とは手を動かす人を社内に置くことではありません。判断の理由を社内に残せる状態を作ることです。コードを書く速度はAIが埋めてくれます。埋めてくれないのは、なぜそう決めたかの蓄積だけ。

誤解のないように申し上げると、すべてを文書化すべきだとは考えていません。全件記録は現実的ではないし、書く負担で手が止まれば本末転倒です。私たちが線を引いているのは「元に戻せない判断」と「禁止事項」の2つ。ここだけは理由ごと残す。それ以外は、必要になったときに書けばいい。この割り切りがないと、意図の外在化そのものが新しい負債になります。

まず試すなら

明日から試せる順に3つ挙げます。どれも1日かかりません。

1. 消えたガード節を1つ、掘り返す。 直近3か月のPRから、削除された条件分岐やバリデーションを1つ選びます。「なぜこれが必要だったか」をチームに聞いてみてください。答えが出れば、その場で1行書き足す。出なければ、意図負債が可視化されたことになります。どちらに転んでも収穫があります。
2. ルールファイルから、自動生成できる記述を削る。 AGENTS.mdやCLAUDE.mdを開いて、「リポジトリを読めば分かること」に線を引いてください。消した分のスペースに、禁止事項と、その禁止がどの事故から来ているかを書きます。量を増やすのではなく、入れ替える作業です。
3. 禁止事項を2行だけ書いて、内製担当に渡す。 完璧な開発ガイドを目指すと、いつまでも完成しません。私たちが渡している2行は「DBを直接いじらない」「メインに直接マージせず、まずPRを上げる」でした。復旧できる範囲を決めるだけで、非エンジニアでも安全にAIを走らせられます。

そのうえで、業務のどこに意図が溜まっていて、どこが抜けているのかを外から見てほしいという場合は、ご相談ください。AI-Pathでは**無償の業務プロセス診断(BPR)**を実施しています。業務の棚卸しから、どの判断が属人化しているか、どこからAIに任せられるかまでを、たたき台として一気に可視化します。「秘伝のタレ」がどの会社にもある、というのが私たちの実感です。先に見つけておけば、内製化の順番を間違えずに済みます。

参考リンク

• 3つの負債を切り分けた論文 (arXiv) — Margaret-Anne Storey教授ら。

• The Intent Debt — Addy Osmaniによる実務向けの整理。