title: "AI駆動開発の本当のリスクは、コードではなく「判断の無設計」にある"topic: "AI駆動開発と判断責任"author: "Ryoji Morii"organization: "Insynergy Inc."language: "ja"content_type: "note article"framework: "Decision Design / Decision Boundary"concepts:- AI駆動開発- OSSライセンス- 脆弱性- 情報流出- AIガバナンス- 判断の設計- 判断の境界- Decision Logkeywords:- AI駆動開発- Decision Design- Decision Boundary- AIガバナンス- OSSライセンス違反- 脆弱性- 人間の判断- AI事業者ガイドラインprimary_sources:- "日経クロステック『普及するAI駆動開発、古いコード混入や規約違反の懸念 人の責任重く』"- "総務省・経済産業省『AI事業者ガイドライン（第1.2版）』（令和8年3月31日）"published: "2026-04-11"
コードが速く書ける時代に、何が問われているのか
生産性革命の裏側で起きていること
GitHub CopilotやCursor、あるいはClaude・ChatGPTを直接呼び出しながらコードを書く「AI駆動開発」は、もはや一部の先進的な開発チームだけの話ではなくなった。コード補完から設計の提案、テストコードの自動生成まで、AIはソフトウェア開発の現場に深く入り込んでいる。
生産性が上がることは否定しない。むしろ、熟練エンジニアがAIを使いこなせば、これまで数日かかっていた作業が数時間で終わるケースも珍しくない。
しかし、日経クロステックの記事「普及するAI駆動開発、古いコード混入や規約違反の懸念 人の責任重く」が指摘するように、この生産性革命には静かなリスクが同居している。
問題は四つある。
第一に、古いコード・非推奨コードの混入。AIは大量のコードデータで学習しているが、そのデータには時代遅れのAPIや、すでに廃止された実装パターンが含まれる。AIが提案するコードが「動く」ことと「適切である」ことは、別の話だ。
第二に、脆弱性の混入。AIが生成したコードに既知の脆弱性パターンが含まれる事例は、複数の研究で報告されている。ツールによる検出も「限界がある」と同記事は述べている。
第三に、OSSライセンス違反の可能性。AIが学習データから特定のOSSコードに近い出力を生成した場合、ライセンス上の問題が生じうる。意図せず違反を犯すリスクは、開発者が自覚している以上に高い。
第四に、情報流出の懸念。AIツールにコードやビジネスロジックを入力することは、機密情報をツール提供者側に送信することと同義になりうる。
これらは個別の技術的問題に見えるが、実は一つの構造的問題につながっている。それについては後述する。
「最終的には人が責任を持つ」は正しいが、足りない
日経クロステックの記事は、こう示唆している。どのツールを使い、どのようなプロンプトで出力させ、どのように「問題なし」と判断したかの記録を残すべきだ、と。
この指摘は本質を突いている。しかし同時に、「最終的には人が責任を持つ」という原則だけでは、現場が実際に何をすればよいかが見えてこない。
「人が最後に確認する」という慣行は、これまでのソフトウェア開発にも存在していた。コードレビューがそうだ。しかしAI駆動開発では、AIが出力する量が人間のそれを圧倒的に上回る場合がある。レビュアーが精読できる量には上限があり、「人が見た」という事実が形式化していく危険がある。
つまり、「人が最終責任を持つ」という命題は正しい。だが、その責任をどのように「設計」するかが問われていないままでは、責任は言葉の上にだけ存在することになる。
制度側も、すでに同じ問題を見ている
この問題は、現場だけの悩みではない。
総務省・経済産業省は2026年3月31日、「AI事業者ガイドライン（第1.2版）」を公表した。今回の改訂の最大の特徴は、AIエージェントとフィジカルAIを初めて正面から規制対象に位置づけたことだ。そして、AIエージェントが自律的に外部へのアクションを実行する場合、重要な意思決定に人間の関与を組み込むことを明示的に求めている。
さらに注目すべきは、「関連情報の文書化やトレーサビリティの確保」が、開発者・提供者・利用者の全主体に共通して強調された点だ。ログ（操作履歴や入出力記録等）の管理体制整備も求められており、日経クロステックの記事が指摘する「記録を残すべき」という現場の要請と、制度側の要求が完全に重なっている。
また1.2版では、「自動化バイアス」——AIの判断をそのまま鵜呑みにしてしまう人間の傾向——についても明示的に言及している。AIが生成したコードをレビューする場面で、「AIが出したものだから大丈夫だろう」という判断の形骸化は、まさにこのバイアスの一形態だ。
制度と現場が、同じ問題に別の角度から向き合っている。
四つのリスクをつなぐ「共通の構造」
先ほど挙げた四つのリスク（古いコード・脆弱性・ライセンス違反・情報流出）を並べると、一つの共通点が浮かぶ。
どれも、「AIが出力した」と「人間が確認した」の間に、判断の空白があるという問題だ。
古いコードが混入するのは、AIが「これで動く」と出力したものを、誰も「これが現在の推奨実装か」という観点で確認していないからだ。脆弱性も同じ。ライセンス問題も、AIが「それらしいコード」を出し、誰もライセンス観点で止めていないから起きる。情報流出も、「このプロンプトに何を含めていいか」の判断基準がないから起きる。
つまり、問題の本質はコードの品質ではなく、判断の構造にある。
誰が、何を、どの条件で、どのレベルの権限で判断するか——この設計が抜け落ちているから、リスクは「頑張って気をつける」という属人的な努力に依存してしまう。
レビューを強化すれば解決するのか
「ならばレビューを強化すればいい」という発想は自然だ。しかし、それは問題の半分しか解決しない。
レビューを増やすことは、チェックの頻度を増やすことだ。しかし、チェックの設計ではない。
何をチェックすべきか。誰がチェックすべきか。どのリスクレベルにはどの種類の確認が必要か。チェックした事実をどう記録するか。承認の権限はどこに置くか。
これらを定義せずにレビューを増やしても、「誰かが見た」という形式だけが増え、責任の所在はかえって曖昧になる可能性がある。
違和感の正体
ここまで読んで、薄々気づいていることがあるかもしれない。
「ガバナンスを強化しよう」「DXを推進しよう」「AIガイドラインに準拠しよう」「AI ethicsを浸透させよう」——こういった言葉は溢れている。どれも正しい。だが、どれも判断そのものを設計するという発想には、完全には到達していない。
これは概念の不足ではないかと、私は考えている。
レビュー工程の追加でも、ガバナンス規程の整備でも、ツールの導入でも、倫理規範の共有でも届かない何か——判断という行為そのものを設計対象にする思想が、まだ言語化されていないのではないか。
AI駆動開発のリスクを本当に制御しようとするなら、この問いに向き合う必要がある。
静かな予告
コードが誰によって生成されるかは、もはや問題の中心ではない。問題の中心は、そのコードを「使う」という判断を、誰がどのような条件のもとで引き受けているかだ。
レビューがあったかどうかではなく、誰がどの観点で、どの権限のもとで、何を確認したのか——その線引きが、設計されているかどうか。
その問いに応えるための概念が、次の節にある。
Decision Designとは何か
AI駆動開発のリスク管理を、「人が最後に見る」という原則に落とし込んでも、責任は本当には設計されない。制度側が求めているのも、「人間の関与」そのものではなく、人間が判断する仕組みの設計だ。
レビューを増やすことでも、ガバナンス規程を整備することでも、AI ethicsを共有することでも、DXを推進することでも、自動化レベルを上げることでもない。いずれも重要だが、いずれもどこで人間が何を判断するかという境界線そのものを設計することには、直接届かない。
その空白を埋めるために必要な概念が、Decision Design（判断の設計） だ。Decision Designは、判断という行為そのものを設計対象とする思想である。
その中心にあるのが Decision Boundary（判断の境界） という概念だ。誰が決めるのか。
どこまでを任せ、どこからを引き受けるのか。
その線を、無自覚のまま放置せず、意図的に設計すること。それがDecision Designである。
詳細版について
本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。