生成AI はフレームワークのルールに詳しくない – AI駆動開発におけるオンボーディングの必要性について考えた

生成AI はフレームワークのルールに詳しくない – AI駆動開発におけるオンボーディングの必要性について考えた
この記事の操作
Markdownで見る

Chrome(最新版)のBuilt-in AIが必要です。

Chrome(最新版)のBuilt-in AIが必要です。

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

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> コンポーネント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 です。

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

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

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

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

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

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

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

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

まとめ

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

シェア:

Hidetaka Okamoto profile photo

Hidetaka Okamoto

Developer Experience Engineer

Developer Experience Engineer。AWSやCloudflare上へのサーバーレスなアプリ開発を得意とする開発者。元Stripe Developer Advocate / AWS Samurai 2017など、サービスの使い方や活用Tipsを紹介するコンテンツ作成や登壇などを得意とする。

⭐ この記事への反応

はてなアカウントでスターを付けることができます

関連記事

入社時の情報洪水を、会社が提供するAIサービスで乗り越える

CircleCI に転職してから間も無く半年です。長年続いているサービスなだけあって、サービスの機能や最近のアップデート、顧客事例に差別化ポイントなど覚えることが山のようにあります。Stripeの時は入社前からStrip [&hellip;]

Claude Code on the Webではまだ、Agent Teamはうまく動かないらしい

Claude Codeによる複数のエージェントを駆使したタスク実行を実現できるAgent Team機能が2026/2にベータリリースされました。ベータ機能の組み合わせになるのでダメな予感はしていましたが、せっかくなので同 [&hellip;]

生成AIは開発者の自己学習を加速する

lacolacoさんのブログが面白かったので、最近あった自分の体験をちょっと共有したいなと思います。 若手開発者の育成がAIによってむしろ有益になる理由 スキルの低い開発者にAIで下駄を履かせて生産性を補強するということ [&hellip;]

AIコーディングでレビュワーとコーダーの戦いをみる

AIによるコーディングとレビューを行っていると、たまに意見の衝突を見かけます。ちょっと面白かったので、スクショでまとめてみました。 以下の記事でもAIによるコードレビューの紹介がありましたが、個人開発の方でも同じようにC [&hellip;]