emahiro/b.log

日々の勉強の記録とか育児の記録とか。

トップ > AI Coding > AI Coding を始めた

AI Coding を始めた

AI Coding LLM Cursor VSCode

Overview

最近話題の AI Coding *1を先月末から始めてみました。実際に使ってみて得られた気づきや、個人的に「これは考えを改めないとな」と感じたポイントがあったので、備忘録としてまとめておきます。

AI Coding については、すでにSNSを中心に多くの知見や導入事例が出回っているため、本記事では詳しくは触れません。

個人的には、以下のZennエントリとオライリーのブログ記事が非常に刺さりました。

zenn.dev
www.oreilly.com

AI Coding との付き合い

最初に AI Coding を体験したのは GitHub Copilot でした。本格的に使い始めたのは2年前で、Copilot がローンチされてから半年以上経っていた頃でした。

当時、すでに LLM を内蔵したエディターも存在していたようですが、巨人の肩に乗る感覚で Copilot をメインに利用していました。また、その頃は Devin のような自律型AI Coding Agentもまだ登場しておらず、「ソフトウェアエンジニアはすぐに廃業にはならないだろう」「コードを書く手段として LLM を使うのは一つの選択肢だけど、これが主流になるにはまだ時間がかかるのでは？」と感じていました。

今思えば完全に見誤っていました。僕にとって当時の LLM は「めちゃくちゃプログラミングに詳しいメンター」という位置づけで、やりたいことや実装の方針を伝えたうえで、各種ドキュメントや OSS のコードをベースに提案をもらったり、コードリーディングの伴走をしてもらうような使い方をしていました。

まさに「Copilot（副操縦士）」という役割で、VSCodeとの親和性も高く、自分にとっては生産性を十分に高めてくれる存在でした。

Cursor との出会い

正直、Copilot で満足していたこともあり、「新しいエディターの機能もいずれ Copilot に取り込まれるだろうし、急いで使わなくても良いかな」と思っていました。

そんな中、現職で Cursor のトライアルが始まり参加してみたところ、その感覚が完全に覆されました。

使用感については以下に投稿しています。

実際に触ってみて感じたのは、Cursor は明確に「AI ファースト」である、ということです。

エディター自体は VSCode のフォークなので、若干 UI や機能に差はありますが、GitHub 連携以外の設定はほぼ引き継げるため、VSCode ユーザーであれば違和感なく使えると思います。

VSCode と Copilot だけを使っている人は、ぜひ一度 Cursor や、もう一つの対抗馬である Windsurf のような AI ファーストエディターに触れてみてほしいです。

開発パラダイムの変化と生産性への影響

Copilot のない時代から Copilot を経て、Cursor のような AI First Editor を体験してきた中で、「実際どれくらい業務の生産性が上がったのか？」という点ですが、個人的には Copilot を導入したときの方がインパクトは大きかったと感じています。

Cursor を使った際の生産性向上は、劇的というよりは緩やかな印象です。
これは「0→1」と「1→10」の違いや、LLM に慣れてきたこともあると思いますが、そもそも開発スタイル自体を AI 時代に合わせてシフトしてきたことも要因です。

従来は「書きながら考える」スタイルだったのに対し、現在は DesignDoc や詳細設計を先にテキストで書き、それを Cursor に渡して実装を生成させる、という流れに変わりました。

このやり方では、人間は「書く人」ではなく「出力を調整する人」になります。そして、この手法では事前に関数名やシグネチャレベルの詳細まで設計に落とし込む必要があるため、その準備に時間がかかることで「生産性が劇的に上がった」という実感を得にくい、という仮説を持っています。

実際、現職の他のエンジニアからも似たような感想を聞いています。

ただ、このパラダイム変更の利点は「変更点が確実にドキュメントとして残る」点です。
Pull Request 作成時に丁寧な説明を書く文化がない環境では、PR の意図が不明確なまま進んでしまうことも多いと思います。AI に渡す前提として、差分の全体像を言語化することを強制されるこの手法は、そうしたペインを軽減するソリューションになり得ると感じています。

とはいえ、開発スタイルを大きく変えることになるため、万人にとってフィットするわけではないとも感じています。

プレーンテキストの価値

AI Coding を始めて最も実感しているのは、「プレーンテキストで残しておくことの価値」です。
この点については、t-wada さんのポストが的確に表現してくれていました。

ソフトウェアはテキストで記述された指示や設定に基づいて動作するものであり、現状がテキストで残っていることは LLM 時代において非常に有利な状態だと感じます。逆に、テキスト化されていない情報は、LLM にとってアクセス不能です。IaC 化されていないインフラは、その典型例かもしれません。

かつて「コードがドキュメント」という言説には否定的でしたが、今では「最新の状態を反映したコード」が最良のドキュメントである場面もあると認識が変わりました。

LLM の存在により、コードをドキュメントとして読むハードルが下がり、実装と仕様の接続がしやすくなったと感じています。

MCP に感じた未来

AI Coding において重要なのは、「AI に適切なコンテキストを与えること」だと実感しています。
チームのコーディング規約やガイドライン、開発フローや外部ドキュメントなど、AI に求める出力の質を左右する情報はすべて前提として渡さないといけません。

インターネットを眺めていると全てのドキュメントを markdown に変換して cursor のルールとして定義する、という方針を見かけることもあります。
これはソリューションの1つとしてはあり得ると思いますし、実際そうしてる組織もあると思います。
AI Coding の第一歩として全てのドキュメントを1箇所に集めるという方向性は同意しますが、自分はこの方向性がベターなのかと言われると、結局ルールが肥大化してメンテしきれなる未来が想像できるので少し疑問を持っています。

このルール管理の課題を踏まえたとき、Anthropic が提唱している Model Context Protocol（MCP）は非常に興味深いアプローチだと感じました。

www.anthropic.com
zenn.dev

MCP では、AI に渡すコンテキストを用途ごとに分離・管理しやすくすることで、ルールが肥大化せず、柔軟かつシンプルに保てるのではないかという仮説を持っています。
実際に社内でいくつかの MCP デモを見たとき、コンテキストを渡す手段、及び開発補助ツールとしての活用事例に可能性を感じました。
（※あくまで個人の感想です）

まとめ

AI Coding を通じて、自分の考えを整理してみました。
現職にはこうした取り組みに先進的なメンバーが多く、自分もそのおかげで新しい開発パラダイムをスムーズに学べており、本当にありがたい環境だと思っています。

AI Coding は、開発の常識を根底から変えていく技術だと思います。
個人的には、Go や Google App Engine に出会ったとき以来の衝撃でした。最初は「乗るしかないこのビッグウェーブに！」くらいのノリでしたが、今では「やっておかないとヤバい」くらいの危機感すらあります。

こうした変化をリアルタイムで体験できるのは、自分のキャリアにとって幸運なことだと感じています。

ただし、しんどさもあるのが現実です。
「ソフトウェアエンジニア廃業論」については懐疑的ですが、仕事の中心が「書くこと」から「指示すること」にシフトした今、ある意味では仕事がしんどくなったとも言えます。

ベンダーマネジメントで行っていた「指示出し」を、今はコード実装にも求められている──そんな感覚があります。
これは実際にネット上でも同様の意見を多く見かけます。


それでも、AI Coding は不可逆なパラダイムシフトです。
だからこそ、自分も「やっていかないとな」と思っています。

*1:このブログを書いている時点では「Vibe（雰囲気）Coding」と呼ぶのが正確らしいです