コーディングエージェントを使って慣れない言語で開発してみた

はじめに

HeritageArrowとの協業でtamariプロジェクトに参画した福嶋です。tamariは、技術ネタを投稿してコミュニティ内で共有するWebサービスです。

私は普段、PHP/LaravelとTypeScriptを使って開発をしています。今回のtamari開発では、Python/Djangoという自分にとって馴染みのない技術スタックでの開発になりました。その中で、コーディングエージェントに頼りながら開発を進めた経験について書きます。

「コーディングエージェントを使えば、知らない言語でもすぐに開発できるのでは？」と期待する方もいるかもしれません。結論から言うと、できることとできないことがはっきりありました。この記事では、その実体験を率直に共有します。

背景：なぜ慣れないDjango/Pythonだったのか

今回のtamari開発では、依頼主である的場さんの方針でDjango/Pythonを採用することが決まっていました。

普段の自分の技術スタックはPHP/LaravelとTypeScriptです。Laravelでの開発経験は十分にあり、Webアプリケーションの構造や考え方はわかっています。しかし、DjangoもPythonも本格的に使うのは今回が初めてでした。

「フレームワークの考え方は似ているはずだから、なんとかなるだろう」という気持ちと、「やっぱり不安だな」という気持ちの両方がありました。

使ったツール：CursorとClaude Code

開発の初期段階では、エディタにCursorを使っていました。Cursorを選んだ理由はシンプルで、コーディングエージェントがエディタと統合されたGUIの環境で使いたかったからです。ターミナルベースのツールよりも、画面上でコードの変更を確認しながら進められる方が、慣れない言語での開発には安心感がありました。

ただ、Cursorには利用上限があり、開発を進めていくとすぐに上限に達してしまいました。APIキーを使って追加課金する方法もありますが、実際に試してみると課金額がみるみる膨らんでいきます。慣れない言語での開発はエージェントへの問い合わせ回数が多くなるため、コストの問題は無視できませんでした。

そんな中で、CursorにClaude Codeの拡張機能があることを知り、移行しました。現時点では、この判断は成功だったと思っています。Claude Codeへの移行の詳しい経緯や使用感については、別の記事で改めて書く予定です。

エージェントが助けてくれたこと

ここでは、コーディングエージェントを使って「助かった」と感じた場面を振り返ります。

Laravelとの比較で理解を進められた

Djangoの書き方でわからないことがあったとき、「Laravelではこう書くが、Djangoではどうなるか」という聞き方をすると、理解がスムーズに進みました。自分が知っている世界との対比で教えてもらえるので、ゼロから学ぶよりも格段に飲み込みやすかったです。

加えて、エージェントはDjangoの公式ドキュメントなどリファレンスのURLも一緒に提示してくれることがありました。エージェントの説明とリファレンスの両方で確認ができるので、理解の精度を上げるのに役立ちました。

エラーの原因を素早く特定できた

これはやはりエージェントが活きる場面だと思います。見慣れないPythonのエラーメッセージが出たとき、自分にDjangoの知識がなくても、エージェントに聞けば問題箇所の特定がすぐにできました。自力で調べていたら相当な時間がかかっていたはずで、開発のスピードを落とさずに済んだのはエージェントのおかげです。

実装方針の提案からコード生成まで任せられた

開発の進め方としては、まず的場さんから大まかな構成を教えてもらい、それをエージェントに伝えて実装方針ごと提案してもらう形で進めました。ある程度理解が追いついてきた段階では、コード生成や実装自体もエージェントにお願いしていました。

実装のスピードは確かに速いです。ただ、自分が手を動かしているわけではないので、その技術を「習得した」という実感はなかなか持てませんでした。エージェントが書いたコードを読んで理解はできても、同じものを自分でゼロから書けるかと聞かれると、正直まだ自信はありません。これは、エージェントに助けてもらえた話であると同時に、エージェントとの協業で感じた率直なもどかしさでもあります。

エージェントに頼っても難しかったこと

一方で、エージェントを使っていても「これは難しいな」と感じた場面がいくつもありました。

生成されたコードの良し悪しが判断しにくい

Djangoの作法を知らない状態では、エージェントが出したコードが適切かどうかを自分で判断できませんでした。

たとえば、Django adminの管理画面を使って動作確認をしていると、少ないコードでとりあえず動く画面がすぐにできます。Django adminは非常にパワフルな機能で、モデルを登録するだけでCRUD操作ができる管理画面が自動生成されます。ただ、裏側でどう動いているのかまでは理解が追いつかず、「どこまで機能が実現できているのか」が掴めない状態でした。動いているけれど、本当にこれで合っているのかがわからない。その不安を抱えたまま進めていた場面があります。

もうひとつ苦労したのが、セルフコードレビューです。私はこれまでPHPやJavaScriptを中心に、VBScript、C系、Javaなども触ってきました。しかし、Pythonの文法はこれらの言語と大きく異なります。インデントでブロックを表現する書き方に目が慣れておらず、コードを読み返しても違和感に気づけない。文字通り「目が滑る」という感覚でした。

プロジェクト全体の設計判断はエージェント任せにできない

設計に関する問いをエージェントに投げると、それなりの回答は返ってきます。しかし、その回答がDjangoにおけるデファクトスタンダードなのか、このプロジェクトにとって最適な設計思想に基づいているのかは、自分では判断がつきませんでした。

加えて、tamariは依頼主である的場さんの意向やプロジェクトの方針があります。エージェントはそうしたプロジェクト固有の文脈を持っていないため、技術的に「動く回答」は出せても、「このプロジェクトにとって正しい回答」かどうかは別の話でした。設計の方向性を決める判断は、結局のところ人が担う必要がありました。

振り返って思うこと

今回は他の業務との兼ね合いもあり、tamariの開発にまとまった時間を確保するのが難しい状況でした。限られた時間の中でエージェントを使いながら進めた、という前提があります。

その上での正直な感想として、もし本業としてフルに時間を使える環境であれば、コーディングエージェントは技術を深めるための良いパートナーになると思います。エージェントの提案を読み解き、自分でも書いてみて、わからなければまた聞く。そのサイクルを十分に回せる時間があれば、新しい言語やフレームワークの習得を加速してくれるツールになるはずです。

一方で、「とりあえず動くものができればいい」という割り切りであれば、理解を後回しにしてエージェントに任せきりで実装を進めることもできるかもしれません。ただ、現状ではエージェントが生成するコードの精度や品質にまだ不安な点があり、中身を理解せずに進めるのはリスクがあると感じています。

おわりに

今回、tamariの開発を通じて、コーディングエージェントを活用しながら慣れないDjango/Pythonで開発する経験をしました。

Laravelとの比較で理解を進められた場面、エラーの特定や実装のスピードで助けられた場面がある一方で、生成されたコードの良し悪しを判断しきれなかったり、設計の意思決定は人が担う必要があったりと、エージェントだけでは埋められない部分もはっきりありました。

「実装は速い、でも習得した実感は持ちにくい」というのが、今回いちばん強く感じたことです。コーディングエージェントは魔法のツールではなく、使う側の土台や向き合い方次第で得られるものが変わるのだと思います。

この記事が、これからコーディングエージェントを使って新しい言語やフレームワークに挑戦しようとしている方にとって、「こういう点に気をつけよう」と考える材料になれば嬉しいです。