この記事は、「toggle Advent Calendar 2025」の7日目の記事…のはずでした。投稿日は見ないでください。
6日目の記事は、「2時間の自律動作 - Opus 4.5で実践するエージェント開発」でした。
2025年が終わりに近づいてきました。この1年を振り返ってみると、自分にとっては「AIに関する技術が、急激にプロダクト開発の中に定着した（当たり前になった）」1年になったな〜、と思っています。 そしてその内容（自分の中のベストプラクティス）も、AIに関する技術が急速に進化していく中で、本当に毎月（下手したら週レベル）でどんどん変わっていったように思います。
この1年を振り返りつつ、あとから「2025年はこんな感じだったんだな…」というのを振り返られるように（案外、忘れてしまうので）、2025年自分がプロダクト開発においてどのようにAI技術（AIツール）を取り込んできたか、という観点で振り返ってまとめてみようと思います。
Cursor
まず、4〜5月頃からCursorを導入し始めました。この頃は、比較的まだ自分の手でコードを書いていて、その補完（これまでのGitHub Copilot等の補完よりも精度が高く、tabを押して補完するだけでそれっぽいコードが出来上がっていって、「おお〜」と思った記憶があります）と、あとはコードの分析などに使っていました。
会社でCursorの導入が始まった頃、「1年払いにしたほうが安いので、そうしましょうか？」という声に対し、CTOの id:myfinder が「このあたり、進化が激しいから月払いにして様子見ましょう」といったことを仰っていたのを今でも覚えています。実際、後述しますが夏頃にはCursorをほぼ使わなくなった（Claude Code/Codexにシフトした）ので、この見立ては完全に正しかったと思います。
当時のCursorは、たまに「謎な（？）」回答をすることがあったので、そういう時にイラッとしないよう、口調をずんだもんにしたりして遊んだりしていました。意外と効いたと思っていて、「まあ、ずんだもんだしな…。」という気持ちで向き合うことができたような気がします。
v0
4月から部署異動があり、新しく社内向けのプロダクトをガンガン作っていくことになりました。 そこで利用を開始したのがv0です。実際にブラウザ上でプロダクトが動いてる様子を見つつ、プロンプトを投げて開発することができて、特にプロトタイピングを作るには本当に有用でした。そのままVercelに展開できるのも魅力的。
ただ、ある程度コード（プロダクト）のサイズが大きくなると、生成に時間がかかったり、質が下がってくる印象があって、最初から最後までずっとv0で開発するのは難しそう、というのが当時の所感でした。そもそも、プロトタイプの開発であれば、今なら最初からClaude CodeやCodexで作り始めても十分モノになりそうです。 一方で、非エンジニア（プログラミングに不慣れな人）が、とりあえずさっくり動くモノを作ったり、プロトタイピングをするという観点では今でも有効に使えると思います。
この頃の考察が以下の記事でした。
Claude Code
7月頃からClaude Codeを使い始めました。ここからAIツールに対する向き合い方が大きく変わって、「AIツールを、コードを書く補助に使う」から、「AIツールでコードを書く」にシフトしました。というのも、その頃開発していた（5月頃から開発を進めていた）プロダクトが、
- 立ち上がったばかりで、小規模
- 自分1人で開発している
- 社内サービスなので、障害が発生しても影響範囲が狭い（社内に閉じる）
という状況だったので、「どこまでAIツールにコードを書かせられるのだろう？」と全実装をClaude Codeに行わせてみたところ、ほぼほぼ問題なく仕事を進めることができたので、「じゃあ、このままどこまで行けるか試してみよう！」となったのでした。結果としては今の今まで、ほとんどすべての実装をClaude Code（と、後述するCodex）というAIツールに任せることができています。
Claude CodeやCodexなどAIツールを使って実装を進めた場合、（定量的な評価ではなく定性的な評価ですが）自分で実装したときの60%〜70%くらいの成果物を一発で出力してくれて、人間がレビューや動作確認をしてフィードバックを与えていけば、普通に80％〜90％、更には100％も十分に目指す事ができるんじゃないか、という印象があります。 そうなってくると、もはや自分の手でコードを書くのは時間がもったいない（どう頑張ってもAIツールより早くコードを書くことはできない！）、ということで、
- 「何を」作るかをしっかり考える
- （後から変更するのが大変な）データ構造を決定する
- 作ったものを評価をする（実装、挙動）
人間はこういうところに集中して、実装はAIツールに任せる、という形に落ち着きました。
そうなると、自分の手でコードを書けなくなったり、読めなくなるんじゃないか？と心配になると思います。自分も最初はちょっと心配だったのですが、「将棋の渡辺くん」という漫画で将棋の渡辺先生が「数カ月、将棋の勉強をしなくても将棋を打てた」というエピソードを紹介されていて、であれば自分もそれくらいコード書かなくても大丈夫なのでは…？と思い、勇気を出して（怠惰に流れて、とも言う）やっていっています。
先日、チームに新卒のエンジニアが入って開発が2人体制になり、久々に（人間の書いたコードの）コードレビューをすることになったのですが、「意外とというか、普通に読めるな」と感じました。コードを読めるのであれば、（CursorなどAIツールのサポートを得ることができれば）コードを書くこともできるだろう、と思っています。このへんは、今後今取り組んでいるプロダクトが全てAIツールに任せられなくなったときに本当の結果がわかると思います。
この頃に書いた記事はこのあたりでしょうか。
Codex
10月頃、現所属会社とOpenAIの業務連携、というプレスリリースが出て、これによりClaude CodeからCodexを活用する方向にシフトしました。Claude Codeはガンガン使っていると簡単にレートリミットに達するのですが、（弊社の場合、業務連携の影響か）Codexはその心配がほとんどないので、とにかくCodexでガンガンタスクを回すようになりました。
ただ、個人的には
- Claude Codeは設計（実装）が得意
- Codexはレビュー（評価）が得意
という印象があり、そのため、
- Claude Codeと対話しつつ設計、実装
- その結果をCodexにレビューさせる
- フィードバックをClaude Codeに渡して修正
…みたいな感じで作業を進めていたように思います。
また、この頃から「とにかくエラーが出たら、Claude CodeなりCodexに食わせる」ようになりました。これまではログをGoogleに投げて調査をしていましたが、Claude CodeやCodexに投げればインターネットの知識をもとに推察して、更に解決案の提案から修正までやってくれるので、「もうこれでいいな…」となりました。そう思ったきっかけが以下のエントリです。
Vibe Kanban
10月からVibe Kanbanを使い始めました。これは6日目の記事を書いたbokiさんが教えてくれたツールです。詳しくは 
id:azukiazusa さんの記事がオススメです。
これまで、tmuxで複数タブを開いてClaude Code/Codexで開発をしていたのですが、並列数が増えると「このタブは何の作業をしていたんだっけ…？」がわからなくなって、脳の負荷が高まるという状況（？）が発生していました。せっかく（レートリミットに達しない限りは）文句を言わずにClaude CodeやCodexが仕事をしてくれるのに、人間（自分）がボトルネックになっていました。具体的には3並列を超えてくるとだいぶしんどくなってきた記憶があります。 Vibe Kanbanを使うことで、現在Claude CodeやCodexなどAIツールで行っているタスクとその状況を簡単に可視化できるようになり、ほぼ無限にスケール（タスクの同時進行）できるようになりました。
「こういうことがしたい」、「こういうのがあればいいな」と思ったら、とりあえずVibe Kanbanに登録しておく、或いはVibe Kanbanで実装させておいて、「やっぱりいいか…」となったらサクッと捨てられるというのがいいですね。
今後の課題
Vibe Kanbanによって同時実行ができるようになった結果、現在のボトルネック（？）は節操もなくガンガン使っているとすぐに到達してしまうClaude Codeのレートリミットになっていて、これをなんとかする方法を考えています。
直近は、Claude Codeのplanモードがかなり強力（これまでは、似たような処理を行う/tasksというコマンドを実装して使っていましたが、不要になりました）なので、これを使って
- 「こういうのを実装したい」を与えてClaude Codeにプランを建てさせる
- このプランをCodexに渡して実装
- Codexにコードレビューと修正をさせる
- （最後に自分がレビューして、マージ）
というフローにしつつあります。なるべくCodexを活用することで、Claude CodeのRate Limitに達しないように工夫しています。
今後の課題や展望など
何故か（何故か？）、DGX Sparkが配られたので、これをもっと活用していきたいですね。 DGX SparkにClaude Code/Codexを導入してVibe Kanbanを立ち上げておけば、いつでもどこでも（業務用のノートパソコンが壊れても）DGX Sparkさえ生きて動いていれば仕事ができる、という環境を作りたいですね。
また、Claude CodeとCodexについて、現状連携についてMCPを使っておらず、手動で（＝プロンプトなどを人力でコピペして）連携していますが、これもMCPを使ってシームレスに連携できないか？というところも模索していきたいです。
あとは、現在取り組んでいるプロダクトが社内向けなので、割とガンガンAIツールの利用に寄せることができていますが、これが社外向けに展開されるようになった場合、テストやQA、品質保証についてしっかり考えないと、障害が発生したりして大変なことになりそうです。これは今後の課題になりそうですね。
最後に、「どうすれば実装をAIツールに寄せ続けられるか（人間が実装しないで済むか）」というところも考えていきたいです。ここが明らかになれば、「ここからは人間が実装していきましょう」という判断を迷わなくて済みますし、「こうすれば、実装をAIツールに寄せ続けられるぞ」と工夫することもできそうだからです。
最後に
もはや、プロダクト開発において「AIに関する技術を一切使わない」という選択肢はないな…。という時代になってきました。当面は、どこで、どれくらいAIに関する技術を使うか、というところをしっかり考えていく必要がありそうです。
8日目の記事は「DXF/DWG解析の時に使えるezdxfを使った便利技」です。
宣伝
1月にDGX Sparkに焦点をあてた「DGX Spark Meetup」をやります！ぜひ遊びに来てください。
