Coding Agent が浸透し、続々と Tips が生まれていますが、アンドパッドでも Coding Agent 活用の社内勉強会がスタートし、いかにいい感じに付き合うか模索中です。  今回はその中でも活用が進んでいるアンドパッドのフロントエンド開発において、 3 名のテックリード、小泉 佑太郎、寺島 伸、六角 創 が集まり、そのベターな向き合い方を話してもらいました ! 

フロントエンド開発でこの先、どう生き残るのかについても触れていますので、ぜひご覧ください。

寺島 伸　Zenn: sterashima78

Webフロント改善チームのテックリード。プロダクト横断での開発改善などの活動に加えてANDPAD のデザインシステム Tsukuri for Web の開発を行っている。 最近はアンドパッド社内の Coding Agent 活用の推進活動なども行っている。

六角 創　GitHub sooo-s 

ANDPAD黒板 開発チームのテックリード。普段は Nux tや Svelte を用いて開発を行っている。複数のチームで開発しているANDPAD施工管理のフロントエンドリポジトリにおける、運用・保守・改善活動も担当。

小泉 佑太郎　Zenn: ykoizumi0903

ANDPAD引合粗利管理や ANDPAD資料承認などのプロダクトや機能をテックリードとして開発しているフロントエンドエンジニア。 業務では Vue/Nuxt を中心に、Next や React Router を使った開発にも携わる。 Zenn で Vue や Nuxt に関する記事を ykoizumi0903 というユーザーネームで書いている。

アンドパッドのフロントエンド開発と Coding Agent の活用模様

―― 本日は、 Coding Agent の活用について深掘りするため、アンドパッドのフロントエンド開発をリードする皆さんにお集まりいただきました。 まずは自己紹介をお願いします。

小泉：フロントエンドエンジニアの小泉です。 担当プロダクトは「ANDPAD引合粗利管理」で、フロントエンド領域のテックリードを担当している他、「 ANDPAD資料承認 」など複数のプロダクトに関わっています。 開発は主に Nuxt を使い、一部 React を使う開発にも参加しています。 ANDPAD引合粗利管理はお金を扱う特性上、数字やデータの取り扱いにシビアで、過去との互換性を守る必要があるため、ANDPADの中でも特に堅い作りが求められるプロダクトです。

寺島：Web フロント改善チームのテックリードをしている寺島です。 組織横断的にフロントエンド開発の改善を行うのがミッションで、社内デザインシステム「Tsukuri」の Web 部分の実装も初期から担当しています。Tsukuri はそれを構成するコンポーネントやツール群など 100 程度のパッケージで構成されるモノレポです。 これを私一人でハンドリングしていることや、社内の人間が顧客という点が他の二人に比べて特殊かもしれません。 社内のメンバーに快適に利用してもらうことが重要なので、例えば、Figma の MCP サーバを使わず、自分で MCP サーバを実装し、より適切なマークアップを生成させるような工夫などもしています。

Tsukuri に関する詳細はこちらの記事をご覧ください

六角：ANDPAD黒板 開発チームのテックリードをしている六角です。 メインの技術領域はフロントエンドで、 Nuxt と TypeScript を使っています。 黒板は管理者が使う Web アプリケーションと、現場の職人さんが使うネイティブアプリで用途が完全に分かれている点が特徴です。 業務や地域ごとに存在する様々な要望を、SaaSの機能として落とし込み、 Web とネイティブの両方で実現するのは面白くも難しいです。

―― ありがとうございます。 それぞれの開発特性が AI との向き合い方にどう影響するか、非常に興味深いです。 早速ですが、皆さんが現在利用している Coding agent とその使い方について教えてください

寺島：社内で公式に許可されているのは GitHub Copilot なので、それを積極的に使っています。 特に最近は、クラウドで動く GitHub Copilot Coding Agent を並列で走らせることが多いですね。 一人で開発しているため、うまく使えるとスケール効果が大きいと感じます。

六角：私も GitHub Copilot を利用しています。 最初はシンプルなタスクや、ある程度どうすれば良いか分かっているものを選んで試していました。 最近ではエージェントにタスクの実行計画を考えてもらい、私は計画自体とその後の実行結果をレビューすることが多いです。特定のライブラリアップデートで発生する難しくはないけど、手順や確認が煩雑な作業を AI に任せることで、コードだけでなく気持ちもすっきりして、開発が楽しくなっていますね。

小泉：私も普段の作業では GitHub Copilot Chat の Agent mode をメインで使っています。Visual Studio Code 上のチャット機能を使って、開発する際に、特定のステップや、コンポーネント作成のように作業を区切りやすいタスクを指示することが多いですね。

Coding Agent は、テックブログに書いた Next.js から React Router への移行作業のように、ある程度まとまった粒度のタスクを依頼できそうな時に使っています。

小泉の Coding Agent 活用模様はこちらの記事もご覧ください

―― より詳しい使い方や使って良かった点などについても教えてください

寺島：先ほど話した通り GitHub Copilot Coding Agent を使うことで、多くのタスクを実行しやすくなりました。一方で、出力が巨大だったり期待に沿わないものばかりだとレビューでより多くの時間を使うことになってしまいます。そのため、各タスクに対して設計や変更内容に関する情報を多く準備するようにしています。もともと、設計などをしっかり行って実装するタイプではあったのですが、AI を使うことでこのような作業もやりやすくなったように感じます。

また、自分が実装をしていた時よりも詳しい検討や設計を行うようになったことで、Coding agent にタスクを実行させる前に足りない情報や仕様の不備に気づくことが増えました。設計などの目的を考えるとこれは当然なのですが、AI でやりやすくなったことでより恩恵を得やすくなったと感じています。

小泉：GitHub Copilot を導入したことで、「やりたいことが明確になっているが、実際に実装するのに時間がかかる」という作業の効率は劇的に上がったという実感があります。特に、ライブラリを入れるほどではないが機能としては一般的で、車輪の再発明になりがちなもの、例えば「マウスで書いた軌跡を SVG で保存する」といった定型的な処理は、何十行ものコードを一発で生成してもそのまま採用できることが多く、生産性は大きく上がりました。

あとは、コードレビューでも Copilot をよく使います。自分が他の人の Pull Request (以下、 PR) をレビューする時にも GitHub の画面上でその PR をコンテキストに加えたチャットを呼び出せるので、内容を正しく理解してコメントするために複雑なコード・ロジックの中身を説明させたり、修正の参考になりそうなサンプルコードを作成させてから、それをアレンジしてメンバーに共有したりしています。

六角：寺島さんが言及されていることにも近いのですが、 Copilot との壁打ち的なやりとりやその結果として出力されたコードや実行計画のレビューをする中で、考慮漏れに気がついたり、より良い実装のアイディアが浮かんだりする点が良いと感じています。

またエッジケースや代替アプローチの存在は見過ごしがちです。先日はチームメンバーが書いた PR に対して、Copilot が “この新しい CSS 関数を使うとより上手く書けるよ” とレビューをし、便利だったので他のコンポーネントでも利用する といったこともありました。

(会話の雰囲気を和ませることが上手な六角)

生成AI の「不確実性」とうまく付き合う

―― 皆さん、 AI を積極的に活用されている一方で、その向き合い方には工夫があるようですね。 まずは寺島さんの、あえて Figma の MCP サーバを使わなかったという話を聞かせてもらえますか？

寺島：ここでいう Figma の MCP サーバはコミュニティで開発された、 Figma のノード情報を返してくれるようなものを指しています。これを使って Figma のノード情報を取得し、デザインシステムのコンポーネント知識と合わせれば、 AI が自動でマークアップを作れるという考えもあると思います。 しかし、私はそうせずに、それらの情報を入力としてマークアップ文字列を出力するところまでを担う MCP サーバを実装しています。 その理由は、生成 AI は入力に対して確率的に出力をするため、どこまでいっても出力が安定しないからです。 もちろん、うまくいくこともありますが、うまくいかないこともあり、その際に開発者が修正したり、 AI に再指示を与えたりする手間が発生します。

―― なるほど。 ある程度、開発者が修正することも折り込む、という考え方で運用することもありえそうですが … ？

寺島： AI を使いつつ、どうやって決定論的な結果が得られる状態をつくるかをよく考えています。 プログラムは入力に対して決定論的に出力が決まるという点に大きな意味があるからです。ある時期、生成 AI を Linter のように使って問題の検出をするような使い方がネットで共有されていましたが、ある問題が確率的に指摘できたりできなかったりするのは不便ですよね。例えば、指摘するべき対象を検出する方法やその実装方法を AI を使いながら具体化し、最終的にはそれを指摘できるようなプログラムを書くことで決定論的な結論を得られるようにするのが良い使い方だと思っています。

六角：そうですね。 必要なコンテキストを渡すなどの事前準備が足りない状態でAI が書いたコードをそのままレビューするのはかなり大変で、手直しが必要なことが多いのが現状です。 とはいえ、 AI が並列で動いてくれるのは助かるので、いかに AI を賢く使うかが重要だと感じます。

小泉：同感です。 AI が生成したものは、最終的に人間がレビューしたり、品質を担保したりするフェーズが現状では絶対に必要です。 そして、 AI が確率論的なものである限り、このフェーズが 100% 不要になることはないでしょう。プロダクトそのものに AI を組み込むケースでも、その出力結果を人間が補正する仕組みが必要になりますし、AI にコードを生成させる場合でも、その間に人間が挟まることで、生成されたものをフィルターする役割があると考えています。

寺島：小泉さんがおっしゃった 「人間の検証が必ず必要である」 という点が、 AI を使う上で最も大事なポイントです。 AI を使う際に考えるべきは、 「どうやったらこの出力を検証できるか」 です。もちろん、用途によっては検証が不要な場合もありますが、仕事で使う以上、検証可能性は多くの場合に必要です。 例えば、大規模で定型的なコードの書き換えを AI にやらせることを考えると、変更後に変更にモレがあるかや、期待通りの変更が行われているかどうかの検証は人間が目でみて確認する以上のことができません。先ほどの Linter のように AI にリファクタリング用のプログラムを書かせることで、挙動の担保やテストが可能になります。リファクタリング用のプログラムでは多くの場合 AST を扱う関係で、多くの API を知る必要があったりコードの量が多くなる場合があり、わざわざ作るのは面倒だと感じることもありましたが、AI  のおかげでかなりやりやすくなったと感じます。 

ネットで目にする情報では趣味の文脈と仕事の文脈が混在しがちですが、仕事においては検証可能かどうかが非常に重要であり、そこを中心に開発フローを組み立てるべきです。

―― 結果として AI の力をセーブすることになり、生産量が落ちるという見方もできるかもしれませんが、品質を担保するためにはそれはやむを得ない、ということでしょうか？

六角：単純に書いたコードの量や倒したタスクの量だけで生産性を表現するのであれば、 AI に制限をかけない方が良いのかもしれません。 しかし、最終的にプロダクトがリリースされ、長期的にメンテナンスされていくことを考えると、本当にそれで良いのかという感覚があります。 うまく制限をかけ、テストコードを整備したり、そもそも負債がたまらないように予防したりすることで、かえって AI 活用の幅が広がることもあると感じています。

もう一つ重要なのは、 AI が書いたコードがバグを出したり、おかしな挙動をした時に、誰が説明責任を負うのかという点です。 現状、この世の中では人間しか説明責任を負いません。 AI に全てを任せて説明責任を放棄するというのは、エンジニアの仕事とは言えないのではないでしょうか。

小泉：品質を担保しないと、後々メンテナンスができなくなったり、バグが増えたりして、かえって効率が悪くなるという側面はあると思いますね。 あとは、 「ロジックが価値の本質かどうか」 も 1 つの判断基準になると考えています。 例えば、冒頭で挙げた "マウスの軌跡を SVG として保存する" のような、仕様が担保されていれば内部のコードがどう書かれていても良いロジックは、 AI にフルパワーを出してもらっても問題ないと思います。

一方で、「ANDPAD引合粗利管理」を例にすると、お金をどのように計算し、どのように予算を確定していくかといった部分は、世の中に一意的な正解がありませんし、あるべき仕様もどんどん変わっていきますよね。 企業が業務で作っているようなサービスの多くは、そういった仕様の独自性がプロダクトの提供している価値そのものになるはずなので、そこは AI ではなく人間が制御する必要があると思います。

寺島：お二人の話を聞いて思うのは、 AI に抽象的な要求を与えて大きなコードを作らせ、その後「面倒を見る」というシナリオを強く想定されている点です。一方で、そもそも要求したコードが完成しないというより手前の問題もあると思います。 私は、AI の力をセーブすべきかどうかの最大のポイントが、 「要求通りの出力が出てくるという確信があるかどうか」 だと思います。要求に対して許容できる出力のスコープが存在すると思いますが、 もしも出力がそこに収まるという確信があるなら、抽象的な指示で AI の力を存分に活用して作らせる方が良いでしょう。 しかし、出力がスコープから外れた時には、それを求めるスコープに収めるためのレビューや修正、再指示といった労力が必要です。

AI の出力が確率的である以上、この労力は常に発生します。 例えば「 100 回やったら 80 回は成功する」としても、 20% は失敗する可能性があるわけです。これまでもソフトウェア開発は不確実性とうまく付き合うための方法などが議論されてきましたが、 AI がコードを書くことで新しい不確実性をもたらすことになります。 この新しく増えた不確実性に向き合い、うまく扱うための工夫を重ねることで AI の力をフルに活用できるようになるのだと思います。

六角：まるで、すごく手の早いジュニアメンバーがいたとして、「もう少し保守性や変更容易性を考えてコードを書いた方が良いよ」と指導するのと似ています。 AI に対しても、人間がそういう風に整備してあげることが必要なのだと、今のところは感じますね。

小泉：寺島さんが言う「 100 回やったら 80 回成功」というのを、「常に 20% の確率で失敗する」というイメージで捉えている方もいるかもしれませんが、私の感覚では「100 個のタスクのうち 80 個はほぼ確実に成功するが、 20 個は何度指示を出してもできない」という理解の方が近いと思っています。その境目がブラックボックスなので確率論的に見えてしまうのですが。

そこには AI に伝えきれないコンテクスト、例えば「工事現場」という物理的な世界で使われるという ANDPAD ならではの状況など、人間が理解している価値観や目的が含まれていると思います。 AI に任せられる価値のものは頼めるかもしれませんが、それ以上のプロダクトを作っている会社では、そうした人間の介入なしには目的の出力にはたどり着かない場合が多いのではないでしょうか。

(今回のインタビューが秋葉原オフィス初出社だった寺島)

フロントエンドはチャット UI だけになる ? 生き残るには ?

―― AI の力をいい感じに使う道筋が見えたところで、フロントエンド開発特有の話にしてきましょう。 フロントエンドでは UI/UX デザインなど、 AI には難しい領域もあるかと思います。 そうした特有の課題はいかがでしょうか？

六角：そうですね。フロントエンド特有の技術的な話や、人間が目視で確認していたような部分と AI の連携については、もっと議論されるべき点だと感じています。

小泉：特にフロントエンドは「手触り」や「感性」といった、そもそも正解がない領域が多く存在します。 例えば、 transition の duration のようなパラメータをどのくらいにするか、といった話には明確な「正解」がなく、流行によっても変わります。 そのため、 AI が常に 100% の正解を出してくれる時代は来ないでしょう。 AI にどこまで任せ、どこから人間が手を加えていくか、というバランスが今後も続くと思います。

寺島：確かに、人間の感性に関わる部分で AI が正解を探すのは難しいですね。 しかし、 AI はアウトプットが非常に速いですから、 「正解になりそうなものの候補を大量に生成する」 ことは得意です。 そうなると、私たちは「正解を探して一から作る」のではなく、 AI が提示した候補の中から「選び取る」だけで良くなるかもしれません。 例えば、 AB テストで AI に様々なパターンを生成させ、良い成績のものをを選ぶ、といった使い方が考えられます。

小泉：私も最近は CSS アニメーションを書く際、ゼロから書くのではなく、 AI にそれっぽいものを一旦作ってもらい、そこから調整を加えていく、というやり方をしています。 スピードは上がりましたが、最初から 100% 完璧なものが出てくるわけではない、という実感もあります。 この「選び取る」というプロセスにおいても、やはり 「検証可能性」 が重要になります。 広告のように、明確な成果値で評価できるものであれば、 AI に大量生成させて選ぶことができます。 しかし、手触りやビジュアルのように「人間の好み」でしか検証できない部分も現状ではあります。 検証というものを言語化する努力が、 AI をより高度に活用するために必要になってくるでしょう。

(Vue Fes などイベントでの登壇も多い小泉)

―― なるほど。 フロントエンドならではの事情がありますね。 それをふまえ、今後の AI 活用の展望はどのように捉えられていますか？

六角：AI の進化の方向性として、電子的にアクセスできる情報、つまり Web 上のコンテクストを理解し、活用する能力はさらに高まっていくでしょう。 しかし、「物理世界」の情報をうまく取り込むことにはまだ時間がかかりそうです。 例えば、 AI エージェントが現場に出向いてカメラで情報を取得したり、社内の営業担当者に話を聞きに行ったりできるようになったら、エンジニアの仕事の進め方や市場の理解の仕方も大きく変わるかもしれません。

小泉：ビジネス的な視点で見ると、結局、 AI と現実世界をつなぐ役割の人が必要になるのはしばらく変わらないだろうと思っています。 今はそれがエンジニアの仕事の一部になりつつあります。 PdM やビジネスサイドの要求を、 AI に任せられる形にブレイクダウンし、コンテクストを与えるのがエンジニアの役割になる、ということです。 その点では、モデル自体の劇的な進化よりも、 「どのようにコンテクストを渡せるようになれば、 AI がより精度の高いものを返してこれるのか」 という部分に期待しています。 チャットやプロンプトを通じて渡せる情報には限界があるので、 MCP のようなツールの進化が、そのコンテクストの渡し方をより円滑にする上で重要になりそうです。

寺島：先日 Claude Opus 4.1 、 GPT-5 がリリースされモデルの改善が目覚ましいです。一方でそれらには初めて ChatGPT に触れた時の「衝撃」はありません。 今後、もし再びそのような衝撃的なAIが登場するとすれば、それは予測不能な形で世の中を根底から変える「イベント」になるでしょうから、あまり具体的には考えていません。なので、 今の延長線上にある AI の進化についてだけを考えていますが、それもせいぜい「人間と同じぐらいのことができる」レベルに留まると思います。

そうなった時、私たち人間のチームのメンバーとして迎えた AI が、いくら膨大な知識を持っていたとしても、 例えば、「この会社特有の事情や文化、文書化されていない個人の知識」 といった部分に依存した仕事はできません。 結局、人間も含めた広い意味で全員が、うまく仕事をするための情報やツールにアクセスできる環境をどう作るかがすべてだと考えています。 MCP のようなツールは、情報の受け渡しを便利にするためには重要なのですが、どちらかというとミクロな話だと思っており、そもそも埋もれている情報をどうするかなど、もっと本質的な課題に直面し、取り組む必要があるのだろうと思っています。

―― それでは最後に、アプリケーションのユーザが人間から AI に、そして UI はチャットになるといった未来像も描かれる中、「今後フロントエンドエンジニアはどう生き残っていく」とお考えでしょうか？

小泉：UI がチャットベースに変わっていく、という見方もありますが、全てがチャットに吸収されるわけではないと考えています。 例えば、チャットで買い物を完結させるような AI サービスも出てきていますが、間違ったものを買ってしまうリスクを考えると、最終的な購入判断を完全に AI に任せるのはまだ怖いと感じます。 AI がなぜそのような選択肢や答えを出したのかを説明できない限り、完全に責任を委ねることは難しいでしょうから、その判断材料としての情報に人間がアクセスするためのインターフェースも残り続けるのではないでしょうか。

六角：カスタマーサービスのように、チャットである程度対応できるパターンは増えるかもしれませんが、本当に困った時には人間が出てくる、という構図は続くはずです。 業務サービスにおいては、最終的に人間が触る部分、責任を持つべき部分は残っていくでしょう。フロントエンドの仕事は減りはするかもしれませんが、完全に無くなることはない、というのが私の考えです。

寺島：私は「最後のチャット UI を作る最後のフロントエンドエンジニアになります」(笑)。 

―― なるほど、それも生き残る道ですね !! 本日は示唆に富んだ話をありがとうございました !

小泉・六角・寺島：ありがとうございました !