---
title: "生成AI はフレームワークのルールに詳しくない – AI駆動開発におけるオンボーディングの必要性について考えた"
date: 2026-05-30
categories:
  - "AI / ML"
  - "LLM"
  - "雑記"
url: "https://hidetaka.dev/ja/blog/gen-ai-need-to-onboard-your-project"
---

Xでちょっと気になる論文の紹介ポストが流れてきました。最近Next.jsをAIに使わせていた時に感じたことと似通う部分もあった気がしたので、ちょっと整理がてら紹介します。

> Constraint Decay: The Fragility of LLM Agents in Backend Code Generation [https://t.co/vAjs87mOk3](https://t.co/vAjs87mOk3) 自分が日々感じているエージェンテックコーディングでバックエンド開発をやる困難さが実験的に示されていた．LLMモデルにサーバー開発をやらせるときに制約が多いほど実装が破綻すると．
> 
> — Yuta Kashino (@yutakashino) [May 25, 2026](https://x.com/yutakashino/status/2058901665017684448?ref_src=twsrc%5Etfw)

## Claude Code が `<Link>` を `<a>` で書いていた話

Next.js プロジェクトを Claude Code に書かせていて、ナビゲーション周りの実装ができたところで PR レビューに回しました。コード自体は動きます。ところが gemini-code-assist が PR レビューに入って、Medium Priority のコメントが付きました。

> Using standard `<a>` tags for internal navigation triggers a full page reload, which degrades performance and breaks the Single Page Application (SPA) experience.

ナビゲーションが全部 `<a>` タグで実装されていた様子です。

Next.js では内部リンクは [`<Link>` コンポーネント](https://nextjs.org/docs/app/api-reference/components/link)（`next/link`）を使います。公式ドキュメントでは「the primary way to navigate between routes in Next.js」と書かれているもので、HTML の `<a>` を拡張して prefetching と client-side navigation を提供します。`<a>` を直接使うと full page reload になり、状態も scroll 位置もリセットされます。

動かないわけではありませんが、Next.js の流儀ではない書き方です。Claude Code は `<Link>` を使わずに、全部 `<a>` で書いていました。gemini-code-assist が指摘するまで、Claude Code はその違いに気づきませんでした。

## 生成AIはフレームワークの扱いが苦手

柏野さんが紹介していたのが、5 月 7 日に arXiv に出た [Constraint Decay: The Fragility of LLM Agents in Backend Code Generation](https://arxiv.org/abs/2605.06445) です。

論文では、「同じ API 仕様を渡して、構造制約（フレームワーク・アーキテクチャ・データベース・ORM）を段階的に積み増していくと、LLM エージェントの実装はどんどん壊れていく。」ということが紹介されていました。

能力の高いモデルでもこの現象は発生するらしく、フレームワークが持つ独自のルールへの対応を苦手としやすいとのことです。

Next.jsアプリで、`Link`を使わずに`a`タグを使われた件も、この論文で紹介されたケースと一致するように感じます。

## 生成AIもオンボーディングが必要

この問題は、PJや開発チームへのオンボーディングにつながると思います。

人間の開発者は、自習やオンボーディング期間でフレームワークのルールや制約を覚え、馴染んでいきます。PoCや小さなPJでの経験を踏んでから、主要機能の開発などに参加していきます。しかしLLM は多くの場合そのプロセスを持たないまま、いきなり現場に突っ込まれます。そのため一般的な書き方は知っていても、「このプロジェクトで採用しているフレームワークではこう書く」という知見を持たない状態で実装を始めます。

つまりオンボーディングにおけるPJへの慣らしをどうLLMに適用するかが、この問題への解決策になるはずです。たとえばFW 公式が提供する Agent Skill を入れるのは1つでしょう。これは [ハーネスエンジニアリング](https://martinfowler.com/articles/harness-engineering.html) と呼ばれる方向の一側面で、Böckeler の整理では guides（feedforward controls）に該当するアプローチです。

また、Next.jsのコーディングでの現象を検知したように、レビューエージェントなどを用意するのも有効です。Böckeler の枠組みでは sensors（feedback controls）側、特に Inferential sensors（LLM を判定者として使うタイプ）に分類されるものです。前段のスキル（guides）と後段の AI レビュー（sensors）は補完関係で、片方だけで完結する話ではなさそうです。

## まとめ

Claude Code が指摘されるまで気づかなかった事件を、論文と重ねて整理してみたメモです。LLM にコードを書かせるとき、人間が自習やオンボーディング期間で得るような経験を、どこかで補わないと、こういう取りこぼしは普通に起きると考えています。