はじめに

第1回では、ディレクターの立場からAIが制作現場に何をもたらしたかを聞きました。今回は、その隣で実装をする側からの話です。AIがコードを書くようになって、エンジニアの手元には何が残ったのでしょうか。長くシステム開発に関わってきた視点で聞いてみました。

今回聞くのは、フロントエンド・エンジニアの森 大典です。

（聞き手・構成：編集部）

個人開発と案件で異なるAIの指示

僕がAIを使い始めたのは、コードエディタの拡張機能からでした。たしか2025年の末くらいだったかな。あのころは書いているコードを補完してもらうのが前提で、丸ごと任せるという感じではなかったです。それが2026年2月に入って、ターミナルでもClaude Codeを使うようになりました。個人のプロジェクトで要件を丸投げしてみたら、ちゃんと動くものができてきて、「すごく便利だな」というのが最初の実感でした。

案件でClaude Codeを使うようになったのは、ECサイト向けに商品データを取得してページをレンダリングするサービスを提供している会社の案件でした。

契約サイトごとにサーバー側で個別にSSRしていたものを、単一のJSでいろいろな種類のウィジェットをCSRする形に置き換えたい、という依頼内容です。受託から1年ほどは、機能が増えてもコードベースが大きくなっても、その設計の延長で収まる範囲のものばかりでした。

Claude Codeは、その範囲の作業で使っていました。ウィジェットのベース実装を足すとか、既存のコードを整えるとか、そういう単位で相談しながら進める形です。

そこに、OAuthベースの認証を前提としたお気に入り機能の依頼が出てきました。これは、それまで積み重ねてきた設計の軸には乗らない、初めて種類の異なる要求でした。契約サイトごとにドメインが異なるクロスサイトの状態だったので、認証まわりには特有の難しさもありました。

この案件は、ディレクターが要件調整、僕が実装という体制でした。ディレクターは、クライアントと調整してドメイン固有の要件を固め、そこにAIのもつコモディティ化された認証知見を掛け合わせて、AIに認証のプロトタイプを作らせていました。

僕の役割は、そのプロトタイプをこのプロダクトのコードにどう馴染ませるか、設計をAIに相談しながら考えることです。それまで、個人のプロジェクトではAIに丸投げしてできたものを受け取るだけという経験はしていました。でも、案件では、取り込み方を人間が判断する場面が最初から必要でした。

トレードオフを認識する

ただ、この認証の要件は簡単には決まらず、二転三転して。動作を確認したいディレクターとクライアントが、僕が設計を考えてコードに反映し終えるのを待つことになって、手が空くまでなかなか検証が進まないという状態でした。

そこで途中からは、ディレクターがクライアントと要件をすり合わせながら、AIに直接プロダクトコードへの反映・調整をやらせるようになりました。実装の中身は見ずに、動くかどうかで先方とやり取りを重ねていく形です。

これは、上流の要件確定という面では効果がありました。「実現できるかどうか」で揺れ動きがちな要件を、実際に動くものに当ててみながら固めていけるので、クライアントとの調整がスピーディに進むようになったんです。

しかし、そのあと、僕がコードをリファクタリングする必要が出てきます。認証の知識は一箇所にまとめて、最小限のインターフェースだけを公開する。そういう構成を大事にしてきたのですが、渡されるコードはそれを無視したものになっていました。動けばいいだけの、拡張性の悪いコードです。プロトタイプを参考にして自分で組み込むのと、すでに荒れてしまったコードから意図を汲み取って設計し直すのとでは、後者のほうが手間も難易度もずっと上がるんですよね。

要件を固めるところはAIに任せて早く確実になったけど、そのぶんのしわ寄せが、あとから設計をやり直す側にきている。そんな感覚でした。

コモディティな知識に強いAI

このコードが荒れてしまったのには理由があると思います。AIは、コモディティ化された知識やメジャーな理論をベースにした実装だと得意なんです。Next.jsのような、世の中に広く浸透しているフレームワークを前提とした設計手法であれば、素直に従ってくれるんですよね。

コードベースを前例として読み取るのも器用で、A・B・C・Dというウィジェットがすでにあって、それぞれ骨幹となる思想が一緒だとしたら、「新しくEを作ってください」と言えば、Eもその思想を引き継いだ形で作ってくれます。

ただ、コードとして表現されていない新しい思想が必要になると、これが難しいんですよね。前例がないので、読み取る手がかりがないんです。それまでは、ウィジェットを追加するくらいなら今までの設計の延長で収まっていたんですけど、この案件独自の認証の形は、そこに乗らなかったんですよね。乗らないところにAIが実装を進めると、その場では動くものができても、全体の構造とはちぐはぐなコードになっちゃうんです。

読みやすいコードの必要性

ここまでリファクタリングを前提とした話をしてきましたが、AIが正しく動作する実装にできるのであれば、リファクタリングせずそのままでもいいんじゃないか、という考え方もあるんですよね。実装は全部AIに任せて、エンジニアは要件を満たしているかをチェックするだけでいい、という発想です。実際、E2EテストもAIのおかげで書きやすくなったので、チェックのコストは下がっているんです。社内でも「動けばいいのか、そうじゃないのか」という話題になることがあります。

でも、あの認証のコードのように、実装の詳細が散乱したまま束ねられずにいると、それを次に触るのが人間であっても、AIであっても、同じように困るはずなんですよね。散らかったコードをベースに次のセッションで作業しようとしたAIも、同じように迷うと思うんです。

逆に、認証の詳細実装がばらけているなら、それを一箇所に束ねて、そこに「これは認証の後処理だ」とわかる名前を与えておくと、次に似たような機能を追加するときの前提として活きてくるんですよね。リファクタリングをしないままでも最初はうまく動くかもしれないですけど、積み重なった負債は、いずれ人間だけでなくAIにも効いてくるんじゃないかなと思うんです。

ディレクションするエンジニア

この認証の実装は、実現できるかどうかの判断が最優先だったんです。ディレクターと実装者という体制だったからこそ、AIに直接プロダクトコードを触らせて、動くかどうかで先方とやり取りを重ねる、というやり方がちょうどよかったんだと思うんですよね。

とはいえ、結果的にそのコードを僕がリファクタリングする必要が出てきたわけです。最初から完成された実装をAIにさせるには、どうすればよかったのかなと考えるんですよね。

たぶん、動く確約が得られて、要件や仕組みをよく理解している人が、あらかじめ整った設計の形に落とし込んでから、それをAIに渡すというステップがあれば、リファクタリングなしでいけたかもしれないんです。あの案件でいえば、ディレクターがその役割を担えはしたかもしれませんが、そうすると、ディレクターと実装者の2人でやる意味がなくなってしまうんですよね。

そう考えると、AIを前提にするなら、ディレクションをするエンジニアがいて、実装はAIがやる、という体制のほうが合っているのかなと思っています。人間は、クライアントとAIの間を橋渡しする役目になるかたちです。

そうなると、コードをちゃんと整えて、人間が仕組みを理解できる状態にしておくことが大事になってくるんです。クライアントと対話するときも、AIに指示を出すときも、今の実装がどうなっているかがわかっていないと、伝えようにも伝えられないんですよね。

ウォーターフォール型開発との共通点

これと似たことを、僕はもっと前にもやっていたなと思うんです。1991年ごろ、原子力燃料を製造する会社の現場で働いていました。ゆくゆくIT部門に移る前提で、システム連携が進んでいる工程に配属されていたんですよね。

その後、社内SEになってオフコンのシステム開発を1年ほどやって、次に、製造工程の設備データをリアルタイムで収集するシステム開発の取りまとめをやることになったんです。当時はC言語でCUIの、ローレベルなAPIしかない環境でした。何も準備せずに始めたら、集まってくるメンバーが全員そのローレベルなAPIを直接触りながら開発することになってしまうな、というのが見えていたんですよね。それだと保守性も品質も危ういと思ったので、先に自分から手を動かして、土台を作っておくことにしたんです。

補足：オフコン

オフィスコンピュータの略で、1960年代後半から1990年代にかけて日本で広く使われた、事務処理向けの小型汎用機です。給与計算や在庫管理、受発注などの業務システムを専用端末から動かす形が一般的でした。

画面デザインはテキストベースで定義できるようにし、入力フィールドの間をカーソルで移動する、といった基礎的なインターフェース群を、ライブラリとして先に実装しておきました。使い方のリファレンスも先に用意しておいたんです。これがあると、あとから来るメンバーは、ローレベルなAPIのことを知る必要もなく、そのインターフェースとリファレンスを見てサンプルを真似すれば書ける状態になるんですよね。

これって、AIに余計なことをさせたくない、AIに不要なコンテキストをもたせず必要な情報だけ与える今の工夫と、同じことをやっていたんだなと思うんです。

その土台ができてから、メンバーを招集しました。設備に詳しい人もいれば、現場で実際に作業する人もいるし、シーケンス制御に強いIT部門の人もいます。そういう人たちを集めてディスカッションしながら要件や設計を詰めていく、いわゆるウォーターフォールのやり方でした。

これも、今でいうクライアントとのディレクションに通じる動きだったなと思うんですよね。

これからのエンジニアの役割

これまでの仕事を振り返ると、SEとして会社や現場を移りながら、基幹系のウォーターフォールで、しっかり設計する分、時間がかかる仕事もやってきました。そのあと、WebとかアジャイルとかLL言語の時代になって、開発速度が重視されるようになってきます。当時はSEとしてPGも兼ねていたので、要件を人に伝えるという工程自体がなくなって、快適に感じていました。

補足：LL言語

Lightweight Language（軽量プログラミング言語）の略。Perl、PHP、Python、Ruby、JavaScriptのように、コンパイルなしで動かせて手早く書ける言語をまとめた呼び方です。2003年から日本で開かれた同名のイベントをきっかけに広まった呼称で、当時エンタープライズ開発の主流だったJavaやC++と対比されていました。

ピクセルグリッドに来てからは、フロントエンドの専門性がぐっと求められるようになりました。TypeScriptだったり、フレームワークの知識だったり、個々人が積み上げてきた暗黙知に頼る部分が大きくなっていったんですよね。

そこにAIが来て、その専門知識をいくらでも引き受けてくれるようになりました。ただ、その暗黙知をAIに渡すには、自分の中にあったものをちゃんと言葉にしないといけないんです。だとすると、残るのはクライアントとAIの間の旗振りとか、全体を見通す力だったりします。設計と、人やAIとのコミュニケーションが、また大事になってきているなと思うんです。

コードでも、ドキュメントでも、材料はAIから引っ張ってくればいいんですよね。むしろそのほうが速いし、いくつも角度が出てくるから、選ぶ材料が増えるんです。でも、その材料を組み立てて「これでいく」と決める骨子は、こっちに残る。そう思っています。