kinoko dev

Jetbrainsのプログラミング専用AIエージェント、Junie + AI Ultimateを2ヶ月の間クォータおかわりして使い切りながらいくつかプロジェクトをこなしてきました。おぼろげながら浮かび上がってきたAIエージェントのクセと付き合い方を述べていこうかと思います。

そうそう、先日ChatGPT5がリリースされてすぐにJunieでも使えるようになりまして、意気揚々と試してみたんですよね。非常に賢くて現行システムの矛盾点を指摘しつつスマートな実装を提案してくれて、
「それで実装してみてください」
って書かかせたコードがぜんっぜん動かない。しかも全く関係ないファイルまで書き換えてくれて修正に半日くらいかかっちゃいましたね。。

AIは基本アホの子であることを忘れてはいけない

上のChatGPT5のくだりもそうですけど、AIは「知識量がすごい新卒」みたいなもんだということを常にキモに銘じないといけないです。モデルが凄くなろうがパラメータが数兆になろうが、あくまでAIはツール。使い手がアホならツールもアホです。（自戒）

AIエージェントのいいところは、「書いたコードの修正もしてくれる」ところです。

が。

修正の方法を指定してあげないと「書きましたけど動作確認してません。ヨシ！」とか「全エラーログ取得してトークン使い切りました……」みたいなことを頻繁にやらかします。Web系とかだと顕著です。

AIはデバッガを使わない

IDEで開発する時はブレークポイントを仕込んでデバッガが使えれば、かなりデバッグ効率は上がりますよね。環境に応じて制限もあったりで使用できないケースもちょくちょくありますが、使えるならデバッガは使いたい、というか使えるように環境の方を変えていくことが多いんじゃないでしょうか。

しかしAIは、GBDのようなデバッガからの情報を取得できません。

AIはどうやってデバッグをしているか

AIコーディングでは基本的に

• 静的コード解析
• テストの結果解析
• ログ解析

これらの手法でデバッグを行います。要するにテキストになっていないとデバッグできないんですね。

• どの時点で
• どの変数が
• どう変わったか

デバッグ作業ではこれが重要だと思ってますが、デフォの状態ではAIはこれらを知る手段を持っていないということになります。

あくまでJunieの場合です。GeminiCLIなど他の環境だとできるのかもしれないです。あとMCPサーバとかで、やればできるのかもしれないですが未着手。

デバッガからメモリダンプを書き出して解析させる手もありますが、データ量が大きくなると思いますのであっという間にトークンオーバーしちゃうと思います。

AIがデバッグしやすい環境づくり

ゆーても「細かいデバッグは手動！」とかやってるとあっという間に人間のキャパを超えるデバッグ作業が発生しますので、できる限りデバッグもAIでやってもらいたいわけです。

AIがデバッグしやすいプロジェクトの構造にしてあげる必要が出てきます。

最優先でロガーを作らせる

手動でデバッグする場合、「ここが怪しいな」というところでブレークポイントを刺して、動作を止めて変数の中身を調べますよね。これがAIでは出来ないので、変数の中身を書き出すロガーを作ってあげれば同じようにデバッグが出来るようになります。

デバッガで見れるような全変数を書き出すような設計だとトークンオーバーしちゃいますので、環境変数などで出し分けできるようにしておきます。

一般的なロガーにあるようなINFO、DEBUGなどのトレースレベルの他に、ドメインや機能、関数名やクラス名ベースでロギングのON/OFFが切り替えれたら最高です。

既存のロガーライブラリだと限界があるので、あなたのプロジェクトに合ったロガーをAIに作らせましょう。

デバッグ用のAPIを作ってあげる

REST APIサーバの場合はそもそもデバッガの使用が難しかったりしますが、デバッグ用のエンドポイントを作っておくと手動デバッグでも便利だったりします。（セキュリティはしっかりね）

Junieはcurlでの動作テストとレスポンス内容の精査は好んで行う傾向です。

単体テストにあたる機能を直接励起できるようなエンドポイントだったり、メソッド内で使用されているローカル変数の値をビフォーアフターで出力するようなエンドポイントを細かく作るか、POSTデータにmethodなどのパラメータで切り分けするなどやり方はさまざまです。

ログの取得方法を明記する

ロガーの設計次第ですが、「標準入出力でコンソール出力のみ」とか、「Dockerコンテナの中にしかログ生成されてない」とかだったりするとせっかくのデバッグログもAIエージェントからは利用できないことになります。また、Docker上でコンパイルエラーやパニックが起こっていても

たとえば

- devサーバーとしてdocker-composeの〇〇コンテナを使用する
- デバッグログはDockerのコンソール出力を取得する
- 必要に応じてDockerコンテナのシェルでログファイルを取得する 

とかを.junie/guidelines.mdに明記しておくといいでしょう。

ASKモードで設計させて、チャット内容は残しておこう

AIはチャットのスレッドでユーザと行われたやり取りの内容すべてを前提にしながら推量を行います。その性質上、長すぎるチャットは途中で締め切られます。具体的には20万トークンで打ち切りになります。

おしゃべりでやり取りするには20万トークンは数十回やり取りできる長さなんですけど、コーディングの場合は生成したコードやテストのレスポンスやログなども含まれるので、内容によってはチャット2回で超えたりします。その場合は実装途中でも停止してしまうので、複数ファイルの変更が必要な内容だとビルドが通らない状態になっちゃいます。

最初からCODEモードで作業をさせるとこの状態になるとお手上げですので、作業範囲が広くなりそうな場合はあらかじめASKモードで作業計画を書いてもらうのがいいです。View in editor tabをクリックするとエディタ側でMarkdownが開かれるのと同時に、スクラッチファイルとして保存されます。

チャットの文言がそのままファイル名になって保存されています。新しいチャットを開いてそのMarkdownファイルをアタッチして、

添付の計画書で実装中です。作業を続けてください。

これでOK。

// ビジネスクリティカルなスパゲッティコードで直したほうがいいのはわかってるんだけどとりあえず動いてて当分変更する予定もないし問題ないから手を付けない
public function SpaghettiCore(){...}

// なにやってるのかわからないけど動いてるから触らない
function VeryDifficultFunctionForMe(){...}