AI コーディングエージェントと向き合う
製造BTでフロントエンドエンジニアをしています。主にWebアプリケーションを担当していますが、バックエンドもモバイルも、言われたらやるタイプのエンジニアです。
さて、日付感覚と記憶がコーヒー飲料くらいには薄いので正確な時期は怪しいのですが、たしか昨年の春ごろ、部長から「WebアプリケーションをAIコーディングエージェントで作れるか?」という話題を振っていただいたことがありました。そのときの私の回答は「Hooksなどのロジックに限れば使える」というものでした。
それから1年。2026年の春の今では、GitHub issuesのURLを渡すだけで、実装からPR作成、画面テストまで一通りやってくれます。しかもこれは最近の話ではなく、もう少し前からそうなっていた、というのが体感です。
そんな中で、自分ではなんとなくうまく付き合えている気はしているのですが、「なんとなく」のままにしておくのも気持ち悪い。というわけでこの記事では、自分なりのAIコーディングエージェントの使い方を一度言語化してみようと思います。
規約ドキュメントより既存コードに語らせる
規約ドキュメントには限界があります。ルールが肥大化すると矛盾が生じ、それを解消するために「Aのケースに限りX」といった例外条項が積み重なっていきます。当然、そうしたルールの保守コストも上がっていきます。
専任で保守できるならいいのですが、製造BTの案件特性として、フロントエンドは少人数で回すことが多めです。そこにコストをかけるのは、正直なところ割に合わないと感じています。
そもそも私は、コードを読んで意図が掴めて、同じようなコードを書ける状態こそが理想だと思っています。AIコーディングエージェントも、周辺のコードを読みながら次のコードを書いてくれます。だったらルールを増やすより、参照されるコード自体を整えるほうに寄せたい、というのが今のスタンスです。
この進め方だと、最初のうちは自分の手でコードを書く割合がどうしても多くなります。過去に触ったリポジトリを参照させて立ち上げをショートカットすることもできますが…まぁ、最初に手間をかけたぶん、走り出してからのレビューや修正のしやすさで返ってくる、というのが体感です。
また、その上で、いくつかのスキルを併用しています。コードベースを読ませるだけでは同じスタイルで書いてもらいにくい部分を、スキルで補います。
npx skills add baseline-ui
npx skills add fixing-accessibility
npx skills add fixing-metadata
npx skills add fixing-motion-performance
baseline-ui
UIまわりの「AIに任せると雑になりがちな部分」を縛るスキルです。Tailwind CSSのデフォルトスケールから外れないこと、アニメーションは motion/react を使うこと、エントランスや細かい動きには tw-animate-css を使うこと、といったスタックの選び方から、タイポグラフィスケールやレイアウトのアンチパターンの検出まで含みます。「動くけど AI のにおいがする」を防ぐ用途で導入しています。また、私自身がデザインには強くないので、とりあえず動くものを求められた時にも高品質でそのまま導入できるレベルにするという目的もあります。
fixing-accessibility
HTMLのアクセシビリティ周りの監査と修正をまとめたスキルです。ARIAラベル、キーボード操作、フォーカス管理、コントラスト比、フォームのエラー表示などが対象になります。
fixing-metadata
ページのメタデータ全般を扱うスキルです。タイトル、ディスクリプション、canonical、Open Graph、Twitter Card、ファビコン、JSON-LD構造化データ、robotsまで含まれます。
fixing-motion-performance
アニメーションのパフォーマンス問題を扱うスキルです。レイアウトスラッシング、コンポジタプロパティ以外への遷移、スクロール連動アニメーション、blur系のコストなどを検出します。baseline-ui がアニメーションの「選び方」を縛るのに対して、こちらは実装後の「重さ」を見るためのもの、という棲み分けで併用しています。
関連するコードは近くに置く
Bulletproof React にある features ディレクトリの設計思想だけを間借りしています。
各ページで使うコンポーネントや hooks、utils を種類ごとにまとめて一元管理するのではなく、features/xxx という機能単位でディレクトリを切り、その下に features/xxx/components や features/xxx/hooks を置く構成です。
こうすると、レビューのときに見るべき範囲がその機能のディレクトリ以下に絞られるので、追いかけるのがだいぶ楽になります。これがコロケーションの強みだと思っています。
AI がコードを書く時代でも、人間がコードを読む場面はなくなりません。とくにフロントエンドは画面で起きていることを起点に「ページ → コンポーネント → 何かしらのロジック」と処理を辿っていくので、その経路上で見るべきディレクトリが絞られているのは、やっぱり効きます。
レビュー可能な粒度で issues を切る
これまでは、issue から PR を作る段階で「ちょっと変更が大きくなりそうだな」と感じたら、人間が手を動かしながらいい感じに PR を分割してくれていました。手で書いている以上、分割は半ば自然に発生するものでもありました。
ところが AI コーディングエージェントは、大量のコードでも難なく書き上げて、そのまま一枚の PR にまとめてしまいます。便利な反面、レビューする側からするとつらい状況になりがちです。差分500行の PR を渡されて「いい感じにレビューして」と言われても、人間の集中力には限界があります。
そうなると、PR を分割するタイミングはもう一段手前、つまり issue を切る段階に移ってきます。「人がレビューできる単位で issue を作る」というのが、最近の自分の進め方です。
粒度の目安は、なんとなくこのあたりで切るようにしています。
- 差分が ±300行 程度に収まるか
- 触るレイヤーが広がりすぎていないか(画面と API とスキーマを一気に動かす issue は分ける)
- 受け入れ条件が箇条書きで5つを超えていないか(超えるならスコープが膨らんでいる合図)
これに収まらないものは、issue を分割して依存関係を書いた上で順に消化していきます。
副次効果として、issue を細かく切ると AI に渡すコンテキストもクリアになります。「何を変えるか」「どこまでがスコープか」「何はスコープ外か」が小さい単位でハッキリしているほど、エージェントは余計なファイルに触らずに安心です。
レビューとテストは人の仕事
言葉を補足すると、「AI の補助を受けながらする、残りの人間の仕事」という意味合いです。
コード品質をエンジニア視点で確認すること、AI にテストデータやテストコードを生成させながら動作を検証すること、そういった作業は AI と分担しながら進められます。それでも、実際の画面を見て「これでよし」と判断できるのは、最終的に人間だけです。AI エージェントには目がないからです。
Web アプリケーションのフロントエンドは、とくにこの「目」が重要なドメインだと思っています。マークアップや CSS のちょっとした変更が、画面上では大きな見え方の違いになって現れることが珍しくありません。差分上は数行なのに、開いてみたら別のページかと思う、みたいなことが普通に起きます。
実は一時期、自動レビューが通ったらそのまま自動マージする運用を検討していたのですが、上のような事情もあって見送りました。コード上は問題なくても画面を見て初めて分かる崩れがある以上、最終確認を人の目から外すのは怖い、というのが結論です。
一方で、Copilot を PR 作成時に自動でレビュアーにアサインするところまでは、レビューの一次フィルタとしてかなりうまく機能しています。人間がレビューを始める前に明らかな見落としが拾われているので、最終確認に集中しやすくなります。ここはおすすめです。
導入で「ブラックボックスが生じる可能性」に触れましたが、結局それを防ぐのは、生成された PR を人がちゃんと開いて、ちゃんと動かして、ちゃんと読むという、地味な作業の積み重ねでしかないと思っています。AI がコードを書く時間が短くなったぶん、レビューとテストにかける時間はむしろ増やしてもいいくらいです。
最後に
書いて改めて思ったのは、AI コーディングエージェントとの付き合い方は、結局のところ「AI が読みやすく、人がレビューしやすいコードベース」を地道に育てる話なんだなということでした。
これは2026年春時点の自分のやり方なので、半年もすれば前提が変わっている気もしています。同じようにフロントエンドで AI と付き合っている方の工夫、ぜひ聞きたいです。
