oto-nari
コード画面を見つめるロボットとキャラクター

コーディングAI vs コーディングアシスタント

Kojiro Tanaka (更新: )

コーディングAI vs コーディングアシスタント

結論

Devinのようなクラウド型コーディングAI + Jetbrains AI Chat や Cursor Chat などのアシスタントAIの両刀使いが最強
以下は私見になります。

コーディングAIとアシスタントAI

決まった定義は無いので、

みたいな理解で進める。

何故両刀使いが最強なのか?

まず第一に「AIにコーディングを依頼するにしても、それらの実装がアーキテクチャとして適切かどうか」という点については、人間の目で判断する必要がある。
また、コーディングAIと開発者のIDE常駐前提のアシスタントAIとでは時と目的によって性能を発揮できる所が違うので、どちらか一方を保有/利用しているだけでは100%AIドリブンとは言えない、という形になる。
その理屈の上では、「どういう使い方をすれば効果的に開発が出来るか」というジャッジを自ら下せる状態の上で両刀使いになるのが最適で、そうでなければ全てをAIに委ねるよりは、ある程度人間の開発の手も入るという所で考えたほうが良い。

そもそもコーディングAI自体そんなに頭よくない

なぜか?→汎用的なタスクに対する性能を求めるあまりコンテキストが肥大化し、意図した命令通りに動かないケースがあるから
例えば、「◯◯ディレクトリに仕様書があるから実装して」という命令でそのディレクトリの仕様書に「詳しくは△△.mdに詳細を記載」とか書かれた日には派手にハレーションする。

コストの問題

Devin(そのほかコーディングAI)はとんでもない数のイテレーションを行って開発を行うので、「ワンショットで終わるようなマイクロタスク」であればIDEを開いてアシスタントAIに相談する方がコストも割安になる。
テストを書かせる系のタスクもAIに全部依頼すると余計なテストを描き始めたり延々とテストを実行してAIタスクが終わらなかったりするので、「開発者がマトモに時間取れなさそうだし、アシスタント使ってても時間掛かりそうだからDevinに頼もっか」位のプランニングでも良いのでどちらを使うかは判断できるようにするべき。

アーキテクチャの問題

シングルプロジェクトでデータ構造がある程度決まっているパターンなら問題ないが、特定のコーディングAIはNode.jsに最適化されてたり、コンテキストが爆発するような言語(PHPとか)には弱いという問題がある。

PlayBook的なシステムプロンプトである程度制御できるものの、結局コンテキストが少なく収まる言語やコード、システムのモジュラビリティ(どれだけ1ファイルが小さく収まるか)に出力の質が依存するという所は避けて通れない。

Junieはいいぞ

https://www.jetbrains.com/guide/ai/article/junie/intellij-idea ←だいたいここに全部書いてある
最近は右も左もVSCode and Cursorで何でも済ませている向きがあるが、JetBrains社のIDEであるIDEAファミリーもAIアシスタント時代に先駆けてAI Chatの実装から関連システムの論文執筆まで積極的に行っている。
なおかつ、All Products Packを契約しているとAI Chat Proが無料で付属し、これを利用するとCursor Chat、Cursor Agentと同じ感覚でコーディングしながらAIに指示を行うことが出来る。
ただし、Quotaの制限が非開示、かつ日常的にアシスタントを使っているとAIクレジット的ななにかが枯渇するので、JetBrains All Products Pack + AI Ultimateを買うことでAI関連のライセンスを2つ持ちながら開発できる。ヘビーに使っててもこの2製品に課金するだけでほぼ全ての開発言語の作業をAI化できる。出来る事はCursorとほぼ変わらないものの、IDEの使い勝手という所ではわざわざCursorを使わなくても既存のIDEに拡張できるという点で、選択肢として優秀だと思っている(特にJavaエンジニアに対して)

逆にDevinがワークする場面って何なの

まず大前提でACU単価が高くて基本料金の安いプランが出たものの、Devinに普通に命令すると月額500ドル掛かるという点は意識した方が良い。

コーディングAI vs コーディングアシスタント

Devinはコンテキスト爆発問題に対して「ソースコードを解析した要約を内部で持つ」という形で解決しているようで、具体的には上記添付のような、自然言語でPMからDevに伝達するような形式の命令がそのまま実現できる。Cursor AgentやJunie(JetBrains)はこのあたりが弱く、意味不明なアウトプットを出す事が多い。
設計や受け入れ条件がしっかりしていない時も、「とりあえずそのへんしっかりさせて命令すりゃなんとかなるでしょ」という信頼感が高いのでDevinを使う。
.junie/guidelines.md 等に書くプレイブックも同様にDevinに定義できるが、Devinはソースコード解析とナレッジ化を勝手に行ってくれるため、膨大なリポジトリを運用しなければならない状況において「とりあえずDevin Machineで全部動かせるようにしておいて何でも頼めるようにしておく」という体制は必ず役に立つ

ただし、性能として優れているからこそ「1ACU=2ドル」という所でのコストを気にせずに開発するとDevin代だけで10万、20万…と積み重なり、AIの出した成果を人間の出した成果と勘違いする人間まで出てくるので、コストコントロール(あるいはDevinのアウトプットをACUあたりの成果として定量的に評価する仕組み)が必須になる。

人間がAIに合わせて開発フローを整理しなければならない

既存の開発が雑であればあるほど、AIに対する命令も雑になる(=的確なアウトプットが出ない)ので、どのように命令するかという、いわゆる「上流工程」のレイヤーを遂行できる人でなければAIに対して適切な命令を行えない(または、コードの質と仕様を確認する手間が増える)。
システムの開発フローにおいて要件の置き場が「AIが取得できる場所」になければいけないので、DevinならばGitHubのIssue、その他アシスタントやエージェントならばリポジトリ内のdocsに仕様を書いて…という所で、利用するAIに適した情報伝達の方法を考えなければならない。
仕様・要件定義の段階からアサインが出来るAIエージェントが出てきた時にはまた開発プロセスも整理されるとはいえ、これは導入する企業にとって必須の検討課題となる。

AI化する時にやらなければいけないこと

ツールチェインTier評価(私見)

(S) IntelliJ IDEA Ultimate + AI Ultimate

(S+) Claude Code

(B) Gemini Code Assist

(A) Devin

Claude 4 Opus最強伝説はいつまで続くのか

コーディングAIという所でコンテキストが発散せず、意図した通りにコードが書けるAIという所でClaude 4 Opusのデキが良すぎてもう開発者の興味関心が「いかにしてClaude 4 Opusを安く使い倒すか」という所に移っている気がします
確かにGemini2.5ProやGPTと比較してエコシステムから何まで全てを古いAIに出来るポテンシャルはあるのですが、SonnetですらGemini2.5の倍のコストが掛かったり、Opusに至ってはSonnetの5倍なのでAnthropicは何かと無理をしている気がします。
Gemini 2.5 Proは安くてそれなりに速いので、プロンプトチューニングや開発者向けの統合が進んだらまた立場も逆転するかもしれない。現状は使いやすさ重視でJunieと仲良くしつつJetbrainsに期待して、その他のAIコーディングツールが出てきた頃にうまいこと乗り継いでいければ良いという感じです。

シェア

関連記事

← 記事一覧へ