お問い合わせ
資料ダウンロードNode.js古川陽介のAIコーディング実践史: ツール比較から運用設計へ
リクルートや大手企業の実績多数！
ニジボックスの開発案件事例をご紹介！
ニジボックスでは、Japan Node.js Associationの代表理事であり、JSConf JPのオーガナイザーとしても知られる古川陽介がデベロップメント室の室長を務め、ReactやTypeScriptなどモダン開発における技術力の向上と実践に力を入れてきました。
本記事は、古川が実際にどうAIツールと関わり、何を学んできたかという「学びとツール選定の変遷」を中心に整理・執筆したものです。
生きた実践情報をもとに、ご自身の現場に合ったAI活用プロセスを検討したい方は必見です！
※以降、古川が執筆した本文となります。
目次
本記事で扱う内容
AIコーディングツールの進化は非常に速く、価格やモデル名だけを追いかけても、実務で再利用できる知見は残りにくくなっています。新機能の一覧だけを覚えるのは、地図を見ずに道路標識だけを覚えるようなものです。どの道を選ぶかという判断軸がないと、現場では迷ってしまいます。
そのため本記事では、ツールの比較を主軸にはしません。今必要なのは、すぐに古くなる「ベストプラクティス」や「体系立てられた情報」よりも、個人開発者が実践している 「生煮えの実践的知見の共有」 だと考えているからです。古川陽介が実際にどうAIツールと関わり、何を学んできたかという「学びとツール選定の変遷」を中心に整理します。
扱う内容は以下の通りです。
- 補完中心期: 『Copilot』時代に得たものと限界
- IDEエージェント期: 『Cursor』 / 『Cline』 / 『Windsurf』を試した時期
- UI特化型エージェントや『Slack』常駐型を試した時期: 『v0.dev』 / 『Devin』
- CLIエージェント期: 『Claude Code』中心運用への移行
- 閑話休題: この時期に作っていたもの
- 今現在の使い方: 『Claude Code』 + 『Codex』の二段構え
- これからの開発方法（2026-2027）: 再現可能な開発方式の設計へ
- まとめ: ツール選定より、関わり方の設計が成果を分ける
この記事の目的は、「どのツールが最強か」を決めることではありません。読者が自分の現場に合わせて、再現可能なAI活用プロセスを設計できる状態をつくることです。
補完中心期: 『Copilot』時代に得たものと限界
最初のフェーズは、AIを「コード補完ツール」として使っていた時期です。ここでの主役は『GitHub Copilot』でした。定型コードや繰り返し作業は確実に速くなり、特にテストコードの作成や、実装方針が固まったAPIの組み立てでは効果が大きく出ました。
入力スピードが上がり、手を動かすまでの心理的コストも下がります。補完は、開発を前に進めるための「はじめの一歩」として機能しました。
一方で、限界もはっきりしていました。この時期のAI活用は「速く書く」には強いものの、「何を作るべきかを決める」には弱いという点です。長い文脈をまたぐ設計判断や、複数ファイルにまたがる変更の整合性までは支えきれません。
また、レビュワーとしてコードを読む時間が長い場面では、補完が提示されること自体が読むことのノイズになることもありました。結果として、補完中心の使い方だけでは運用の中心にならない、という判断につながっていきます。
一方、今でも『Copilot』を現役で利用しているところもあります。『Copilot』自体の普及について、公開情報では利用規模の拡大が確認できます。MicrosoftのFY25 Q4決算報告では、『GitHub Copilot』のユーザーは2,000万人、Fortune 100の90%が利用中とされています。つまり、導入は現在も進んでおり、AIツールの普及に大きく一役買ったと言えるでしょう。
古川がこのフェーズで得た学びは3つです。
- 補完は生産性を上げる入口として非常に有効である
- 一方、長い文脈をまたぐ設計判断は補完だけでは支えきれない
- コードリーディングをする場面では補完がノイズになることもある
IDEエージェント期: 『Cursor』 / 『Cline』 / 『Windsurf』 を試した時期
次のフェーズでは、補完中心の使い方から一歩進み、IDE上でエージェントにまとまった作業を任せる運用へ移りました。ここで試したのが、『Cursor』 / 』 『Cline』/ 『Windsurf』です。目的は共通していて、既存コードベースに対する変更をどこまで安全かつ高速に進められるかを見極めることでした。
まず『Cursor』は、既存コード修正とマルチファイル編集で明確な強みがありました。関連ファイルを横断して修正候補をまとめる動きが速く、仕様がある程度固まっているタスクでは、実装速度を押し上げやすい印象でした。特に「複数ファイルにまたがるが、変更方針は明確」という場面で有効でした。
『Cline』は、OSSかつBYOKという透明性の高さが評価ポイントでした。どのモデルを使い、どこにコストが乗っているかを把握しやすく、制御可能性は高いです。一方で、実運用ではタスクの精度と安定性にばらつきがあり、プロンプトや確認工程を厚くしないと期待値を外すケースもあります。運用負荷と自由度のトレードオフがはっきりしているツールでした。
『Windsurf』は、「開発者のフロー状態」を重視した設計思想が特徴です。開発中の集中を切らさない体験設計は強力で、相性が合うと非常に快適に進みます。ただし、これは裏返すと作業スタイル依存が強いということでもあります。コンテキストスイッチが多い働き方では、能動的な提案が過剰に感じられる場面もあり、性能だけでは決まらない相性の差が出ます。
データ面でも、このフェーズの難しさは確認できます。価格体系は固定額からクレジット/従量へ移行する流れが強く、同じ月額でも実質コストが変動しやすくなっています。さらに、開発者レビューは高評価と不満が二極化しやすく、アップデート頻度の高さに対して安定性やサポート品質が追いつかないという指摘も見られます。『Cline』周辺では、Roo CodeやKilo Codeのようなフォーク分裂も起きており、OSSの自由度がそのまま選定難易度の上昇につながる側面もあります。
このフェーズで古川が学んだことはシンプルです。
- IDE型エージェントは「自分の作業特性に合うか」で決める
連続して深く作業するタイプなのか、短時間で多数の文脈を切り替えるタイプなのか、使っているIDEはキーバインドなども含めて自分に慣れたものなのか、このあたりのIDEとしての使いやすさで選べば良いと思いました。
UI特化型エージェントやSlack常駐型を試した時期: 『v0.dev』 / 『Devin』
IDEエージェントと並行して、別のアプローチのツールも試していました。1つはUI生成に特化した『v0.dev』、もう1つは『Slack』経由で作業を依頼できる自律型エージェントの『Devin』です。
『v0.dev』は、Vercelが提供するフロントエンド特化の生成AIツールです。テキストやFigmaのURLを渡すだけで、React / Next.js / Tailwind CSSベースのコンポーネントを生成してくれます。UI開発の初速は明らかに上がり、画面のプロトタイピングには便利でした。ただし、できることがUI生成に限定されているため、プロジェクト全体の開発フローには組み込みにくいという制約がありました。結果的に、『Claude Code』でもUIは十分に作れるようになった段階で、役割を終えた形になりました。
『Devin』は、『Slack』上でタスクを依頼すると、自律的に調査・実装・PR作成まで行ってくれるエージェントです。簡単な修正であれば依頼するだけで完結するため、体験としては新しいものでした。一方で、試行錯誤が必要なタスクには弱く、プロンプトの精度やAI側の判断精度の問題で完了しきれないケースも出ました。さらに当時は従量課金モデルだったため、失敗してもコストが発生する点が運用上のハードルになりました。
このフェーズで得た学びは、「特化型ツールは初速は速いが、開発フロー全体には組み込みにくい」ということです。UI生成もタスク代行も、単体では便利ですが、調査から実装・テスト・コミットまでを一貫して回すには汎用性が足りません。この経験が、次のCLIエージェントへの移行を後押ししました。
CLIエージェント期: 『Claude Code』中心運用への移行
IDEエージェントや特化型ツールを経て、次に重心を移したのがCLIエージェントです。理由はシンプルで、実装だけでなく調査、計画、実行、検証までを一つの流れで扱いたかったからです。エディタの中での補助から、開発プロセス全体の伴走へと役割を広げる段階に入りました。
このフェーズで中心になったのは『Claude Code』です。古川の運用では、単にコードを書かせるのではなく、調査資料の作成、計画の立案、TODO管理まで含めてタスクを持たせるようになりました。ここで重要だったのは「いきなり実装させない」ことです。作業を急がせるほど、後で手戻りが増えるためです。
具体的には、次の4段階で進めます。
- Research
最新仕様、既存実装、関連ドキュメントを調べ、前提をそろえます。例えば同様の機能を持ったツールやアプリケーションはないのか、今のツールやアプリケーションを作る際にどのような技術が出てきているのか、などの情報を調べて RESEARCH.md に記述させます。 - Plan
タスクを分解し、優先順位と実行順を決めます。何を作るかにもよりますが、Webアプリケーションであればフレームワークの雛形作り、ツールであれば難易度の高いコアロジックの実装などの重要で難しいもの、逆にテスト作成や単純な画面の設計などは簡単で重要性が低いもの、などの優先度評価を行います。そのうえで PLAN.md に記述させます。 - TODO
実行可能な粒度まで落とし込みます。TODOリストを作成し、 TODO.md というファイルを作らせます。これも一度で全部終わらせずに、少しずつ進ませます。一つ一つの作業はセルフレビュー、テスト実行、失敗したら要因検証というふうに進ませます。 - Implement
TODOに沿って実装・テスト・確認を進めます。完了後はTODOを更新し、必要に応じてコミットやPRを分割します。
この運用では、いきなり走り出すのではなく、ルートを引いてから移動するイメージです。遠回りに見えても、全体では最短になることが多いです。CLIエージェントは、プロジェクト全体を横断しながらこの流れを回しやすく、設計と実装の接続が安定します。
一方で、CLIエージェントは強力な分だけ、誤った前提を渡すと間違いを高速化します。そのため、抽象的な状態から、実行可能な具体的な実現アイデアの状態になるまで壁打ちし、誤差を吸収できるフローを作ることが重要だと思いました。
この時期に学んだことは、「自分が実際に行う開発のやり方がどんなものなのか、開発フローの解像度を上げる」ことです。Research → Plan → TODO → Implement のように工程を明示すると、AIの出力品質だけでなく、人間側のレビュー品質も一段上がります。
閑話休題: この時期に作っていたもの
この時期にはいくつかのアプリケーションを作っていました。社内イベント（性能試験コンテスト）用のアプリケーションや、SaaS型のアプリケーション、ユーザー同士がコミュニケーションするSNS的なアプリケーションも作りました。
『Claude Code』初期時点では失敗も多く、その多くは「いきなり実装作業に取り掛からせて、手戻りを発生させてしまい、最終的なアウトプットが思ったものとは違うものになる」ことでした。
ある程度開発フローを安定させることができるようになってからは、作るものも安定してきました。
今は自分のTODO管理を『Claude Code』に作らせています。古川は本業以外にも副業やJSConf.jpの運営などもやっており、メールで来るメッセージや『Slack』での問い合わせが多く、それらを捌ききれていないシーンがあったので、インカミングなメッセージを収集し、「タスクのTODOっぽいもの」をTODOとして管理するツールを作って運用しています。
毎日TODOリストを送ってもらい、それをこなすだけでうまく回るようにしています。
▼表: TODO管理ツールの出力結果
| # | タイトル | 緊急度/重要度 | ソース |
| 1 | 新規アサインメンバー連携準備（3月開始） | high/high | slack |
| 2 | 記事執筆依頼（今週末まで） | high/high | slack |
| 3 | 3/10懇親会の出欠回答 | high/medium | slack |
| 4 | 3月分LT再登録 | high/medium | slack |
| 5 | GitHub権限更新リクエスト対応 | medium/medium | gmail |
| 6 | PRレビュー指摘への対応 | medium/medium | gmail |
| 7 | PRレビュー対応 | medium/medium | gmail |
| 8 | 承認案件の発注申請手順共有 | low/medium | slack |
| 9 | チャンネル作成の確認依頼 | low/low | slack |
今現在の使い方: 『Claude Code』 + 『Codex』の二段構え
ここまでの変遷を経て、現在は『Claude Code』と『Codex』を併用する運用も試しています。使い分けの軸は「どちらが常に上か」ではなく、「どの役割を持たせるか」です。
実運用では、主に2つの使い方をしています。1つ目はA/B実行です。同じ課題を両方に投げ、調査の深さ、変更の妥当性、テスト観点の網羅性を比較します。2つ目はセカンドオピニオンです。先に『Claude Code』で作業を進め、『Codex』側にレビュー役として別視点の指摘を出させます。
ここで重要なのは、習熟度バイアスを前提に置くことです。使い慣れたツールのほうが結果が良く見えるのは自然で、実際の差と使い方の差が混ざります。そのため、単発の印象ではなく、同種タスクで複数回比較して判断する運用にしています。
AIツールのベンチマークの傾向を少し見てみましょう。
2026年2月時点でのAIツールのベンチマーク比較では、
- 『SWE-bench Verified』は『Claude Opus 4.5』が80.9%で首位（出典）
- 『Terminal-Bench 2.0』は『GPT-5.3-Codex』が75.1%で首位
- 『Aider Polyglot』は『Claude Opus 4.5』が89.4%で首位
でした。これらのベンチマーク自身も様変わりしており、さまざまな方法で計測されています。ちなみに『SWE-bench Verified』の結果自体は『OpenAI』が「信頼できるスコアでない」などの評価も行っており、ベンチマーク結果も参考情報にすぎません。
一方でどのベンチマークでも『Claude』と『Codex』が安定した結果を出しており、それらのモデルの違いから併用できる環境では併用するとお互いの強みや弱みを補完する結果が出ると感じています。
今試しているところで得られている学びは以下のようなことです。
- 1ツール固定で最適化するより、複数併用したほうがブレが少なくなる
- 併用の仕方には2種類、同じタスクを並行させる方法と別々のタスクに分けてお互いの強みを補完する方法がある。例えば「実装担当」には『Claude』、「レビュー担当」には『Codex』、のように責務を分けることも検討するとよい
これからの開発方法（2026-2027）: 再現可能な開発方式の設計へ
ここまで振り返ってきた変遷を踏まえて、これからの開発がどう変わっていくかを考えてみます。ポイントは「次にどのツールが来るか」ではありません。ツールは今後も入れ替わります。重要なのは、ツールが変わっても崩れない開発の進め方を設計することです。
人間の役割の再定義
AIがコードを書く速度と精度が上がるほど、人間の仕事は「実装する」ことから離れていきます。代わりに比重が増すのは、要件定義、制約設計、レビュー設計です。
「誰がコードを書くか」はもはや重要ではなくなりつつあります。問われるのは「誰が品質基準を持つか」です。
更にいうと、品質基準にもパターンが存在します。
- このアプリケーションがユーザーの何の課題を解決するのかという価値の基準
- アプリケーションのメンテナンス性や使いやすさ、セキュリティやパフォーマンス、設計妥当性といった正しさの基準
が存在します。つまり「価値があるかどうか」と「正しいか正しくないか」という2つの基準が存在します。AIが生成したコードのなかで「正しいか正しくないか」はある程度AIでも判断が可能ですが、「価値があるかどうか」を判断できるのは、ドメイン知識を持った人間だけです。実装の手を動かす時間が減った分、何を作るべきか、何を作るべきでないかの判断に時間を使うほうが、全体の成果物の質は上がります。
モデル/ツールの使い分け戦略
前章で述べた『Claude Code』 + 『Codex』の併用もその一例ですが、これからは「単一ツール固定」ではなく、用途ごとの役割分担が基本になると考えています。実装担当、検証担当、レビュー担当のように、工程ごとに適したツールを割り当てる運用です。
ベンチマークの差をそのまま信じるのではなく、自分のプロジェクトの実務タスクで再現性があるかどうかを優先すべきです。『SWE-bench』で1位のモデルが、自分のコードベースでも最適とは限りません。実際に同じタスクを複数ツールで試し、手戻り率や修正精度で比較するほうが、現場での判断材料としては確実です。
この「役割分担」の考え方を、ツール内部でも実現する動きが出てきています。2026年2月、Anthropicは『Opus 4.6』のリリースと同時に『Claude Code Agent Teams』を実験的機能として公開しました。これは、複数の『Claude Code』インスタンスをチームとして協調させる仕組みです。1つのセッションがチームリードとなり、タスクの割り当てや成果の統合を行い、チームメイトはそれぞれ独立したコンテキストウィンドウで並行作業を進めます。
例えば、PRレビューをセキュリティ・パフォーマンス・テストカバレッジの3観点に分けて並行レビューさせたり、バグ調査で複数の仮説を同時に検証させたりといった使い方ができます。チームメイト同士が直接メッセージをやりとりして互いの発見を共有・反論し合う構造は、単なる並列実行ではなく、協調的な開発プロセスの自動化に近いものです。
まだ実験的機能であり、トークン消費量も単一セッションより大幅に増えるため、全てのタスクに向くわけではありません。しかし、「実装担当/検証担当/レビュー担当」という役割分担がツール側で実現されつつあるのは、使い分け戦略の方向性を裏付けていると感じます。
チーム運用の標準化
個人での試行錯誤はここまでの章で描いてきましたが、チームで再現するにはルール化が必要です。古川が考えている方法は、1スプリント単位で導入実験を行い、うまくいったパターンをルールとして残していくやり方です。
具体的には、プロンプト規約（どのような指示の出し方をするか）、レビュー観点（AI生成コードのどこを見るか）、禁止事項（AIに任せてはいけない作業は何か）をリポジトリに明文化します。暗黙知のまま運用すると、メンバーごとにAIの使い方がばらつき、品質のブレが大きくなります。ルールファイルとして共有することで、チーム全体の底上げが可能になります。
実際にチーム単位でAI活用の標準化に取り組んでいる事例もあります。JSConf JP 2025では、サイボウズが「大規模プロダクトで実践するAI活用の仕組みづくり」というスポンサーセッションを行いました（登壇資料）。大規模プロダクト『kintone』の開発チームにおいて、個人レベルではなくチーム全体でのAI活用体制をどう構築したかを紹介する内容です。
このセッションで扱われていたのは、AIツールに依存しないドメイン知識の管理、ドキュメントの陳腐化を防ぐ継続的な更新、auto-compactによる記憶喪失対策、AIエージェントを乗り換えても開発フローが崩れない設計、MCPの活用、そしてチームをまたいだ知見共有の仕組みです。
特に「AIツールに依存しないドメイン知識の管理」と「エージェント変更時にも柔軟に移行できる開発フロー」は、前述したプロンプト規約やレビュー観点の明文化と同じ方向を向いています。ツール固有の機能に乗りすぎず、知識とルールをリポジトリ側に残す設計が、チーム運用の安定性につながるという点で、古川の考えとも一致します。
まとめ: ツール選定より、関わり方の設計が成果を分ける
古川の変遷を一文でまとめるなら、「補完で速くなり、IDEエージェントで任せ方を覚え、特化型ツールで汎用性の壁を知り、CLIエージェントで開発フローそのものを設計するようになった」ということです。ツールが進化するたびに、人間の役割は「コードを書くこと」から「AIとの関わり方を設計すること」へ移ってきました。
振り返ると、各フェーズで学んだことはつながっています。補完中心期には「速く書けるが設計判断は支えきれない」ことを知り、IDEエージェント期には「自分の作業特性に合うかで選ぶ」ことを学び、特化型ツール期には「初速は速いが開発フロー全体には組み込みにくい」ことを経験しました。CLIエージェント期には「Research → Plan → TODO → Implement」という前工程を明示することで手戻りが減ることを実感し、併用期には「1ツール固定より役割分担のほうがブレが少ない」ことを確認しました。
どのフェーズでも、成果を分けたのはツールの性能差ではなく、運用の設計でした。この記事で伝えたかったことは2つあります。
1つ目は、ツールとの関わり方が一番性能差を分けるということです。ツールは変わり続けます。『Copilot』から『Cursor』、『Claude Code』、『Codex』と、古川自身もこの1年半で何度も乗り換えてきました。しかし、各ツールで実験・検証して得たナレッジは次のツールでもそのまま生きています。「いきなり実装させない」「前工程を明示する」「役割を分けて併用する」といった学びは、特定のツールに依存しません。ツールが入れ替わっても、関わり方の設計が残っていれば、次への移行はスムーズです。2つ目は、生煮えで良いので周りに使い方を展開しようということです。AIツールの活用はまだ誰も正解を持っていない領域です。体系立てられた完成形を待っていたら、いつまでもチームに広がりません。「このプロンプトの書き方がうまくいった」「このタスクはAIに任せないほうがよかった」といった小さなTipsを、生煮えのまま共有する。その量がある時点で質に変わる時期が来ます。サイボウズの事例もそうですし、古川自身もこの記事で「まだ試している最中の情報」をあえて出しています。完成を待たず、今の知見を周りと共有すること。それが、チーム全体のAI活用を少しでも前に進める方法だと考えています。
以上が古川の執筆記事となります。
実践情報をもとに、ご自身の現場に合ったAI活用プロセスの検討にぜひご活用いただければと思います。
ニジボックスの詳しい実績については、以下のリンクからご覧いただけます。
ニジボックスが注力している開発改善プロセスの効率化「Growth Development」や、モダンフロントエンド開発の事例・プロセスを紹介した資料もございます。お気軽に資料をダウンロードいただき、情報収集にお役立てください！
資料を通じて私たちの取り組みや成果をぜひご確認いただき、今後のプロジェクトにおいてもご一緒できる機会があれば幸いです。
以下よりぜひお気軽にご相談ください。
執筆者
古川 陽介
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー
株式会社ニジボックス デベロップメント室 室長
Node.js 日本ユーザーグループ代表
複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。 現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。 2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。 Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。
Github： yosuke-furukawa
