AIがコードを書く時代に、第一線のエンジニアは日々どうAIと向き合っているのか。Node.jsのコミッターであり、リクルート／ニジボックスでソフトウェアエンジニアを務める古川陽介氏は、本番開発で“バイブコーディング”をしない。「自分がコントロールできないものは作りたくない」という古川氏が実践する、リサーチからラーンまでの5フェーズ開発フロー、変わりゆくレビューのかたち、そしてチームに根づくAI活用のリアルを聞いた。
AIは「便利なもの」として使い倒す——ただし本番でバイブコーディングはしない
― まず現在の古川さんのご活動について簡単にご紹介いただけますか。
古川： 肩書きは変わらず、リクルートに所属しつつ、リクルートの子会社であるニジボックスに出向して、開発室室長を務めています。いまは後者の役割のほうが若干大きくなっているのですが、リクルートからニジボックスに出向もしている、というところですね。
― 室長というと、主にマネジメントですか。それとも第一線で開発もなさっていますか？
古川： 何かリクルートのサービスやニジボックスの開発役割の仕事しているわけではありません。メインはマネージャーですね。でも研究として何かの開発はずっとしています。
― 古川さんは日々の業務で、AIをどう使っていますか。特にNode.jsやTypeScript、JavaScriptでコードを書く場面やレビューの場面や、あるいはあえてAIを使わないと判断しているシーンがあれば教えてください。
古川： 基本的にAIを使い倒していますし、便利なものとして使わせてもらっています。どう使っているかは、おそらく皆さんとそこまで大きな乖離はないと思うんですけど、一昔前に流行った、大まかな要件を渡してAIにコードを書かせるといういわゆる「バイブコーディング」は、今は全くやっていません。
本番の開発では、いまで言う「プランモード」のような形で、設計の壁打ちをしっかりやった上で、実装も自分の目の届く範囲でやらせる、という進め方が多いですね。
RESEARCH, PLAN, TODO, IMPLEMENT, そしてLEARNの5フェーズで開発を進めている
― 具体的には、どんなプロセスで開発を進めているのですか。
古川：開発は5つのフェーズに分かれています。
最初がRESEARHのフェーズです。作りたいサービスや機能について、どう作るのがいいのかを一旦リサーチします。例えばログイン機能１つとっても現在だとどんな手があるのかを複数の仕組みから調べるような調査タスクを与えて調査させています。それを踏まえて、リサーチ用のHTMLなりMarkdownなりのファイルを作らせて、自分が持っている知識とAIが調べてくれた知識を踏まえて、「じゃあこんなやり方でやろう」とおおまかな方向決めをする。これがRESEARCHのフェーズです。
次がPLANのフェーズです。方法を決めた上で、具体的にどう進めていくかを計画します。粗い設計や要件はリサーチで決まっているので、そこから実装の方針を決めていく。機能が大きければ、プラン自体をいくつかに分けるところまで含めてプランニングします。この段階で出てくる成果物、具体的にはplan.mdのようなファイルに対してコメントしながら進めていきます。
そのプランをブレイクダウンしたTODOリストを作ってもらいます。これが3番目のフェーズです。
そして、そのTODOを1件1件こなしていくのがIMPLEMENTのフェーズです。ここまでを一気に全部進めると、AIの特徴として、同じ入力をしても同じアウトプットが出るとは限らないので、ある程度コントロールがつく範囲で、まずは少しずつアイドリングさせています。TODOを1個消化させて、だいたい1コミットくらいの粒度でやらせて、テストを実施したり、方向性がずれていないかをコードを見ながらチェックしたりします。それが良さそうだったら次のTODOへ……というふうに、大きくぶれないことを担保しながら進めるイメージです。
― なるほど。
古川：RESEARCH、PLAN、TODO、IMPLEMENTと来て、最後にもう1個、ちょっと変わっているかもしれないんですが、「LEARN」というフェーズを入れています。プルリクエストを作って終わり、ではなく、そこで学んだことを記録するフェーズです。
たとえば不具合が取りきれなくて困ったとか、特定のライブラリを使おうとしたら思っていたのと違った、といったことを学習させて、次のサイクルに活かす。また同じサイクルを回していく、PDCAみたいな感じですね。
― それはいい取り組みですね。
古川： なので、AIはかなり使っているんですけど、コードを量産するような感じではなく、ある程度自分のコントロールの中に置いた状態で進める、というのを基本にしています。
「自分がコントロールできないものは作りたくない」——プロとしての一線
― それは「本番のコードだから慎重にやろう」という結果、そのフローに行き着いたということですか。
古川： まだ心配性なので、AIが生成したものに対して外れていないか不安なんですよね。「自分のコントロールが効く範囲で出力結果がブレないようにしてもらっている」という感じですかね。
開発者としては自分が作っているものなのに、コントロールできないものをアウトプットしたくないんですよね。ただし、最近の進化でどんどんAIツールのアウトプットは精度が上がってるので、徐々に簡素なフローに変えていくかもしれませんが。
レビューは「正しいか」から「価値があるか」へ
― こうした進め方は、チームのメンバーと一緒に開発する場面でもされているんですか。他のメンバーも同じようにやっていたり、レビューでも同じ感じで進めていたりするのでしょうか。
古川： 他のメンバーも似たような感じでやっています。ただ、お互いレビューしながら進めてはいるものの、レビューの内容や仕方はかなり変わってきました。ソースコードの1行1行について「この書き方がどうこう」と言うことは減って、どちらかというと、外側から見たときのデザインや動き方に口を出すことが増えました。
コードが正しく書かれているかどうかのレビューは、それはそれでするんですけど、それよりも、ユーザーにとってちゃんと価値が生まれているか、使いやすいかどうか、という「価値」のレビューに一番時間を使うようになりました。
正しいか正しくないかのレビューは、どちらかというとAIがやってくれているものをある程度信じて、人間は「価値があるかないか」——これは人間＝ユーザーにとっての価値ですね——のほうをレビューするようになっています。
― それは、プルリクエストでコードの差分を見るというより、マージして動きを見てみる、というレベルになっているんでしょうか。
古川： そこまで行くまでもなく、プルリクエストを出した時点で、ある程度プレビュー用のデベロップメント環境に「プルリクエスト番号いくつをデプロイした環境」みたいなものが立ち上がるようになっています。それを確認しながらレビューできます。もっとクラシックなスタイルだと、一度自分たちのところに持ってきて動かして、ということもやりますけどね。
plan.mdはリポジトリに残すべきか——いまも手探りの問い
― 少し素人的な質問かもしれないんですが、さっきのplan.mdのようなものも、GitHubのリポジトリに含めたりするものなんでしょうか。
古川： これは賛否があるところですね。一緒に開発している人たちの中には「不要ではないか」という人もいます。「1年以上前の plan.md をコミットしても見ないのでは？」という意見が出ました。
一方で、どういう計画で進めようとしたのか、振り返りとしてLEARN.mdで何を学んだのかについては結構面白かったりするものもあるので、今はまだ共有しておくようにしていますね。 Claude Code の使い方の参考になるので。
― 確かに。
古川：ただそうすると、一次作業のディレクトリみたいなもので汚れてしまうので、それをどう捉えるか、というのはありますね。昔は開発者用のフォルダがあって、その中にみんながどんどん入れていたんですけど。サイボウズさんが昨年のJSConf JPで紹介していた、一時的なディレクトリの中に「日付＋フィーチャーブランチ名」のセットで入れておくやり方を参考にして、一時期はそれでやっていました。
― 現在はどんなやり方を？
古川： 半年、1年くらい使ってきて、さすがに「作業ログのディレクトリを見返すことってそんなにあるのか」という話も出ましたし、無駄に差分が増えているんじゃないか、という話も出て、現在は手探りしている最中です。強く消したいというモチベーションも特にないので消してはいませんが、「みんながいらないというなら消してもいいのではないかな」という感じです。
何らかの方法で、プランの内容や過程の知見が共有できればいい。それがGitHub上に入れておく必要があるかと言われると、そうとも限らないので、そこは探っている感じです。
（続）
**********************************************************************************************
後編では、AI時代の技術コミュニティの変化や、「AI時代だからこそプログラミングや要素技術を学ぶべき」という古川さんの思想に迫ります！
プロフィール
古川 陽介（ふるかわ ようすけ）
ソフトウェアエンジニア。リクルートに所属し、子会社のニジボックスへ出向、開発室長を務める。Node.jsのコミッターとして知られ、Japan Node.js Association 代表理事、Chrome Advisory Board メンバー、TechFeed公認エキスパート。JSConf JPをはじめとする技術カンファレンスの運営にも携わる。 X（旧Twitter）：@yosuke_furukawa
