こんにちは、やまだたいし( https://twitter.com/OrotiYamatano )です。
前編では、Unity上でPhi-4 miniを動かしてじゃんけんゲームを作った実装についてお話ししました。
今回は、その後編で開発過程でAIコーディングツールを活用した際の所感をまとめます。
目次
なぜAIコーディングツールを使ったのか
今回のプロジェクトでは、AIコーディングツールを積極的に活用しました。
そもそもとしてAIコーディングが現実問題実務に耐えゆるのか気になったため全体をAIにコーディングに任せてみました。
使ってみて不便だったため、途中で使い方を見直したので本記事も2回にわけて所感を投稿します。
1回目の試行
1回目の利用ツール
まずはツールの概要から
CLI
今回使用したツールの多くはCLI（Command Line Interface）形式です。
CLIとは、コマンドライン（ターミナル）から実行するツールのことで、
GUI（グラフィカルユーザーインターフェース）ではなく、
テキストベースで操作するインターフェースです。
AIコーディングツールにおいてCLI形式のツールを使うことで、
といった利点があります。
MCPとは
MCP（Model Context Protocol）は、AIアプリケーションと外部ツールやサービスを連携させるための標準化されたプロトコルです。
このプロトコルにより、AIモデルがアプリケーションの状態を理解し、
操作を実行できるようになります。
MCPの特徴として、
- AIモデルと外部ツール間の標準化された通信方式
- アプリケーションの状態を取得・操作できる
- 複数のツールやサービスと統合しやすい
- AIがアプリケーションを直接操作できる
などがあります。
Codex CLI
最初に利用したツールはメインとしてCodex CLIを採用しました。
Codex CLIは、OpenAI社が開発したCodexというコード生成用のAIモデルを、
コマンドラインから利用できるようにしたツールです。
まず、Codexについて説明します。
Codexは、OpenAIが開発したコード生成専用のAIモデルで、
GPT-3をベースにコード生成に特化して訓練されています。
Codexの特徴として、
などがあります。
Codex CLIは、このCodexモデルをコマンドラインから利用できるようにしたツールで、
通常のAIコーディングツールがコードの生成や補完を行うのに対し、
Codex CLIは実際にコードを編集したり、gitコマンドを実行したりと、
開発作業そのものを自動化してくれる点が特徴です。
具体的には、
- CodexのパラメーターをTOMLで指定して、
行動全てをApproveにするように設定することで、
Codexに自然言語で命令すると処理を実行してくれます
自分のコーディング環境とは別にセットアップして動くため、
既存のワークフローを崩さずに試すことができます。
UnityMCPとは
UnityMCPは、このMCPプロトコルを使ってUnity Editorと連携するツールです。
DomainリロードやAsset Refreshなど、Unity Editor上での作業を自動化できます。
AIコーディングツールと連携することで、コードの生成だけでなく、
Unity Editor上での操作まで自動化できるようになります。
UnityのMPCでも一番有名だったため、こちらを利用しました。
1回目：やってどうだったか
Codex CLIは自分のコーディング環境とも別にセットアップし動くようにしたのですが、
モデルを揃えていても環境によって精度が違う（ABテストでもしてるのかな）という印象でした。
gitコマンドやghコマンドも命令すれば実行してくれるため、
多分AGENT.mdに詳細を書けばPRまで自動で出してくれるかもしれません。
実際に使ってみて、以下のような問題に遭遇しました。
- 何故か書き込み権限があるのに読み取り権限しかないと勘違いして
「書ける」と言っても「readonlyになっていて、編集できません」と言ってきたり - R3なのに頑なに存在しないIObservableを使おうとして変なコードを書いたり
- gitの操作に詰まってlockファイルを直接削除したり
- シーン上からComponent全Findしたり
- 「MCPでアタッチして」と言ってもAwakeでGetComponentを書き始めたり
やりたい放題で、指示出しの精度にもよるのかもしれませんが、
コンテキストの理解が限定的で、デバッグに時間がかかるという課題もありました。
正直「多分自分で書いたほうが早かった……。」というのが率直な感想です。
一方で、「たたき台となるコードの作成や簡単で物量が多いコードにはよさそう」だと感じました。
2回目：複数ツールを組み合わせた改善試行
これを踏まえ更に使い易いようにするにはどうすればいいだろうと考え、次のようなツールを導入しました。
2回目で使ったツール
使ったツールは以下の通りです。
- UnityMCP：1回目から引き続き使用
- Copilot CLI：新たに追加
- SpecKit：新たに追加
- Context7：新たに追加
- CodeRabbit: 新たに追加
Copilot CLI
Copilot CLIは、GitHubが提供する「GitHub Copilot」をターミナルから使うためのCLIツールです。
Codex CLIとは違いGithubが提供することもありGitHubのフローと非常に相性が良く使い勝手が良いです。
特に特徴的なのはコーディング エージェントのAI部分をどのモデルを選択するか設定可能な点です。
ChatGPTのCodexはもちろん、Claude Sonnetも利用可能です。
特にCludeCodeはそのまま使うとかなり高いですがColipotCLIを介して使うことでかなり安く使うことが出来ます。
今回はSonnet4.5をメインで使いました。
後CodexはTOMLファイルを変更しましたが、こちらはJsonです。
(CodexよりCludeCodeのが使い勝手は良かったです)
SpecKit
仕様書を元にコード生成を行うツールです。
ココでいう仕様書とはユーザー側で何度かコマンドで「このようなライブラリが使っている」だとか
「このような仕様でつくろうとしている」だとかを対話的に入力することで
リポジトリ内に仕様書を量産してくれてAIが見る専用のドキュメントとなります。
ここで最新のAPI仕様やドキュメントを提供することで、
AIが古いバージョンの書き方をしてしまう問題を軽減します。
公式ドキュメントや仕様書を参照しながらコードを生成するため、
より正確で最新の情報に基づいたコードが生成されます。
ただ難点としてはAIも必ずすべてのドキュメントに目を通してくれる訳ではないのでプロンプト内容は丁寧に考える必要はあります。
Context7
コンテキスト(文脈)を提供してコード生成の精度を上げるツールです。
簡単に言うとAI専用のドキュメントを提供するツール。
プロジェクトの全体構造や、他のクラスとの関係性などのコンテキスト情報を提供することで、
AIコーディングツールの文脈理解が向上します。
これにより、プロジェクト全体の設計方針に沿ったコードが生成されやすくなります。
CodeRabbit
これは実際にエージェントを使っている間ではなく、コードレビューとして入れたツールです。
Github上でPRが作られた際に挙動し、内容についてレビューをしてくれるツールです。
正直今回使ったツールで一番満足度が高いツールでした。
コードレビューだけでなくPRを空で上げるとPRの内容まで詳細に作成し、
なおかつ、コードのフロー図や既存コードの懸念点などまであげてくれます、素晴らしい。
しかも、コードレビューに対して返信するとお返事も返ってくる。
〇〇だからこうしました→なるほど！ではこうしてみたら如何でしょうか！みたいな。
2回目：やってどうだったか
これらのツールを組み合わせることで、
ほぼAIコーディングすることにしてみたところ、
実際に使ってみたところ、一通りコーディングできるようになりました。
あと一歩というところもありつつも使い方やプロンプトを調整することで使えるレベルになったように感じます。
改善された点
- 古いバージョンの書き方が減った
SpecKitやContext7を利用することで、最新のAPI情報を提供できるようになり、
古いバージョンの書き方をすることがぐっと減りました。
これにより、後から修正する手間が大幅に減りました。
- 自動化できる作業が増えた
ghコマンドを入れていれば、
自身でPRも作ってくれるし、OKといえばmergeもしてくれる、commit、pushもやってくれる
丁寧に説明を書けば、UnityのAsset/Refreshを叩き、コンソールのErrorが消えるまで一通りの修正はやってくれる
まさにフローが完結されたかのような感覚です。
新たに分かった問題点
- Promptの書き方による問題
一方でちゃんと動くようになったことで、問題が顕在化しPromptの書き方によってはうまく動いてくれないことに気が付きました。
人間に命令するのと同じように感情に訴えかけるようなPromptや、このコードに至った経緯などを話すと、
回数を重ねるとauto-compact(プロンプトややり取りが多くなった際にコンパクトに要約する機能)があってもポンコツ化することが多々ありました。
具体的には、
返事をするだけで作業を何もしなかったり
出来る作業を「出来ません」と口答えしてきたり
実際のエージェントとやり取りを晒すとこんな感じです。
AI「すぐ作業します！」(何もやってない)
草
AIに任せるような抽象的なPromptは、
すでに記述済みの類似コードを多重に書いてしまったり、
クリティカルな部分のコーディングをそれっぽい理由をつけて(例えばモックとしましたなどいって)後回しにしてしまう
そのため、Promptを書く場合は
具体的で、誰が書いても同じようになるように簡潔に圧縮された内容を示すことが必要のようです。
駄目な例
チャット機能を作っていてApplication側は出来たのでViewを完成させて
正しい例
YYYYYYAsyncメソッドを作成せよ。 ApplicationのXXXXX.csにAIが返信を返すXXXXObservableとユーザーがAIにメッセージを渡すXXXXXXメソッドがある。 現在のXXXXXXView.csにはインプットフィールドのシリアライズフィールドとボタンのシリアライズフィールドとテキストフィールドのシリアライズフィールドが存在する。 ボタンを押下した際にインプットフィールドの内容をユーザーがAIにメッセージを渡すXXXXXXメソッドの引数に渡し、XXXXObservableをawaitし取得した文字列をテキストフィールドへ表示
またどうしてもAIとやり取りをしているとポンコツ化してくるので定期的にコンテキストリセットが必要です。
またイチから説明し直しになったりするのですが、しっかりとSpeckitで資料を残していれば過不足なく毎回同じように学習してくれます。
正直このあたりのフローはSpeckitのSpecの切り方同様粒度を考えて使う必要がありそうでまだまだ使いこなせていないです。
私が実際に使っていた内容としては毎回コードが出来たらAssets/Refreshを叩き数秒待ってコンソールを確認、エラーが出ている際はエラーを直すことや
一通り作業が終わったらコミット(metaあげ漏れチェックも)、pushしghコマンドでPR作成などです。
これだけでも大分使い勝手がよくなった感じがしました。
まとめ
と、このように
今回の開発を通じて、AIコーディングツールを使って見ましたが
まだまだ言ったとおりにしか作ってくれないし、まだまだだなと思う点も多いですが
初回の試行ではCodex CLI単体では「多分自分で書いたほうが早かった」と言える結果でしたが、
2回目では複数のツールを組み合わせることで、「使えなくはないかな」と思えるレベルにまで達したと感じはしています。
逆に言えばちゃんと言えば言ったとおりに作ってくれるという感覚もあります。
有用だなと思った点としてはエラー解決の時間を大幅に短縮できたという点です。
コーディング歴がそろそろ10年になる私ですが未だにエラーで何だっけとなることはあります。
そこでAIに任せると考えるより先に直してくれることもあり単純作業はAIだなと思いました。
またまっさらな状態からそれっぽいコードを書くのもAIは得意でたたき台となるコードの作成にはかなり有効だと感じました。
ただ既存のコードを変更となるとコード量が多くなるほどコンテキストを学ぶ必要があるためトンチンカンなコードも書くことが多かったり、
一つのクラスで書きたがったりするので注意が必要だなと思いました。
また他の注意点としてはそれっぽくみえても生成されたコードは必ず検証し、理解してから使わないととんでもないコードを書いていたりすることもありしっかり読む必要があることを感じたり、
権限の問題で自分でgitのロックを削除するなどの暴挙も見られました。
そのため、AIコーディングツールは、あくまで「コードを書いてくれる存在」ではなく、「開発を支援してくれる存在」として使うのが、最も効果的ではないかと思います。
人間側で細かい仕様や作りを策定しAIに説明、そしてAIが書いている間に次の仕様(プロンプト)を考えることで擬似的にタイピング速度を上げるかのような使い方ができそうです。
とはいえ、今現在AI周りの技術の進歩が早いので、近い未来もしかしたらUnityのような環境でもAIに大部分を任されられるような日が来るかも……しれません。
今後もAIには目が離せなさそうです。
以上、やまだたいしでした。
