Insynergy

AI駆動開発で「最後は人が確認する」は機能しなくなる──品質問題に見えて判断責任の問題である

topic: AIdriven development, human accountability, software quality governance, decision design, judgment architecture concepts: AI駆動開発 コード生成 人間の最終責任 OSSライセンス 脆弱性管理 監査可能性 Decision…

topic: AI-driven development, human accountability, software quality governance, decision design, judgment architecture

concepts:

related_concepts:

keywords: AI駆動開発, コーディングエージェント, 品質保証, OSSライセンス, 脆弱性, 人間の責任, Decision Design, Decision Boundary, Insynergy, 判断境界, ガバナンス

論点は「便利か危険か」ではない

AIがコードを書く。そのコードを人間がレビューして本番に反映する。

この流れを聞いて、多くの人が思い浮かべる論点は「AIで開発が速くなる」か「AIを使うとリスクが増える」のどちらかだろう。生産性と安全性のトレードオフ、という構図である。

しかし日経クロステックが報じた記事「AI駆動開発で増す人の責任　品質の担保、最後は人頼み」を読むと、論点はそこではないことに気づく。記事が照射しているのは、AIが生成したコードを組織として使い続けるとき、何が起きているのかという実態だ。そしてその実態は、生産性の話でも安全性の話でもなく、もっと地味で根深い問題を指している。

最終的に誰が判断し、その判断はどこに記録されているのか。

これが問題の核心である。

コードが「古くなる」という現象

AI駆動開発の現場で起きている具体的な問題を整理しよう。

生成AIが書くコードは、学習データの時点で止まっている。つまりモデルが参照しているライブラリのバージョン情報、セキュリティ勧告、APIの仕様変更は、学習が完了した時点のスナップショットだ。コードは動く。テストも通る。しかし半年後、一年後に脆弱性が報告されたとき、そのコードが「誰の判断で」採用されたかを追跡できるチームがどれだけあるか。

OSSライセンスの問題も同じ構造を持つ。AIが生成したコードにオープンソースのコードが混入していた場合、ライセンス条件によっては商用製品への組み込みが制限される。問題が発覚したとき「AIが書いたから」は免責にならない。組織として採用を決めた、という事実だけが残る。

情報漏洩リスクも看過できない。プロンプトに機密情報を含めてしまった場合、あるいはコーディングエージェントが外部のAPIと通信する設計になっていた場合、その判断を誰がどこで承認したのかが問われる。

これらの問題は、AIの精度が上がれば解決するわけではない。AIがより賢くなっても、ライセンスの問題は人間の世界の規則であり、情報漏洩の責任は組織が負う。品質管理ツールで検査しても、最後に「これでよい」と判断したのが誰なのかは、ツールが記録してくれるわけではない。

「最後は人が確認する」という運用の脆さ

多くの組織が採用している現実的な対応は、「AIが生成したものを人間が最終レビューする」という運用だ。これは一見、理にかなっている。AIに任せつつも、最後に人間を挟むことでリスクをコントロールする。

しかし、この運用には構造的な脆弱性がある。

「最後に人が見た」という事実と、「人が判断責任を引き受けた」という事実は、同じではない。

たとえば、開発チームの誰かがプルリクエストをレビューして承認ボタンを押した。しかしそのレビュアーが見たのは差分のコードであって、AIが生成したコードに混入したOSSの出所ではなかったかもしれない。あるいは、脆弱性スキャンのツールがグリーンを出したので問題なしと判断したが、そのスキャンが対象としていない種類の脆弱性が含まれていたかもしれない。

このとき「誰が責任を引き受けたのか」という問いに、組織は明確に答えられるか。

レビュアーは「見た」かもしれない。しかし「引き受けた」かどうかは別の話だ。判断の範囲、確認した懸念の範囲、承認の根拠──これらが記録されていなければ、事後に責任の所在を確定することができない。

記録を残せ、という要請の意味

日経クロステックの記事では、検証結果を記録として残すことの重要性が指摘されている。これを「証跡保存」の話として読むと、ある種のコンプライアンス対応に見える。監査のためにログを取る、という話だと。

しかし、もう少し立ち止まって考えると、この要請はそうではない。

記録を残せという要請は、「判断の履歴を残せ」という要請である。

操作ログと判断ログは違う。操作ログは、何がいつ実行されたかを記録する。判断ログは、なぜその判断がされたのかを記録する。誰が、何を確認して、どの懸念を確認済みとし、なぜこれでよいと判断したのか──この情報がなければ、後から責任の所在を確定することも、同じ判断を再現することも、判断の質を向上させることもできない。

AIが開発過程に深く入り込めば入り込むほど、この「判断ログ」の欠如が組織に与えるリスクは大きくなる。なぜなら、判断の数が増えるからだ。AIが生成したコードのレビュー、ツールの選定、プロンプトの設計、本番反映の可否──これらすべてが判断であり、それぞれに責任の所在がある。しかし多くの組織では、これらの判断が暗黙のうちに処理され、記録されていない。

政府文書が示す方向

この問題は、個別の現場だけが直面しているわけではない。

内閣府が策定した「人工知能基本計画」や「人工知能関連技術の研究開発及び活用の適正性確保に関する指針」では、自律的に動くAIエージェントを含むAI活用に対して、誤作動やプライバシー侵害などのリスクを念頭に、人間の判断や統制を含む仕組みづくりを開発企業や利用主体に求める方向が示されている。デジタル庁が公表した「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」も同様の方向性を持つ。

これらの文書を通じて見えてくるのは、政府もまた「最後は人を置けばよい」とは言っていないという事実だ。人間の関与を残すだけでなく、その関与がどのような構造の中で機能するかを組織として設計することを、制度の方向として示している。

ガイドラインは存在する。しかしガイドラインがあるだけでは、判断の境界は設計されない。

問題の輪郭が変わる瞬間

ここまで読んで、最初の問いに戻ってみてほしい。

AIがコードを書くことで、何が問題になるのか。

答えは「品質が下がる可能性がある」ではない。答えは「判断の構造が設計されないまま、判断の数だけが増える」ということだ。

脆弱性の問題も、OSSライセンスの問題も、情報漏洩の問題も、記録の問題も、すべてこの一点に収束する。最終的に誰が判断し、誰が責任を引き受け、どこまでをAIに任せ、どこからを人が引き受けるのか。その境界が設計されていない。

「人を最後に置く」という運用は、この問題への答えではない。問題を先送りにしているだけだ。

この問題に気づくと、議論の地平が少し変わる。品質管理の改善策を探しているうちは、チェックリストやツールの導入という答えが出てくる。しかしもし問題が「判断の構造設計」にあるとすれば、必要なのは別の種類の概念だ。何を設計し、何を記録し、どこに境界を引くのか──その問いに答えるための、設計論が必要になる。

それが Decision Design（判断の設計） である。
Decision Designは、判断という行為そのものを設計対象とする思想だ。
その中心にあるのが Decision Boundary（判断の境界） という概念である。誰が決めるのか。
どこまでを任せ、どこからを引き受けるのか。
その線を、無自覚のまま放置せず、意図的に設計すること。それがDecision Designである。

詳細版について

本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。

note版を開く →