JunieはJetbrains製IDE専用のAIエージェントです。日頃お仕事ではPHPStorm、趣味ではRustRoverを使ってまして、どっちでもJunieを使ってます。Jetbrains All Pack + AI Ultimateでクオータを使い切ったので感想と、効率的に使うノウハウを備忘録が寺書いておきます。ちなみにCursorは使ったことないので比較はできません。あしからず。
そもそもJunieって何？
猫も杓子もAIな昨今、プログラミングにもAIを使おうという流れなのはこのブログにたどり着いた人なら知ってると思いますが、それをJetbrainsがIDEに統合しちゃったのがJunieです。
AIアシスタントとの違い
これまでもJetbrainsのIDEにはAIによるコード支援機能は標準機能で搭載されていました（たしかFreemiumだったような記憶）。入力中の内容の先を予測して補完してくれたりLintでエラーが出ている箇所を自動修正をさせたり、という機能は3年くらい前から提供されています。
チャットプロンプトの純正プラグインも1年ほど前から出ていて、プロジェクト全体を検索して修正案を提案してくれたりドキュメント生成してくれたりします。
AIチャットの方は生成内容を自分でコピペする必要がありました。（β機能で自動適用が実装されていますが、たまに違うファイルにコピペされて焦る）チャットの応答内容はプロジェクトに固有で、手動でダンプしなければ他のプロジェクトなどからは参照できません。ダンプデータはTXTのみ・AIに送信した生データを含むのでかなり読みにくいです。LLM自体の研究にはダンプデータも有益かもですけど。
Junieができること
JunieはいわゆるAIエージェントです。AskモードとCodeモードがあるんですが、CodeモードがこれまでのAIアシスタント機能とは大きく異なるものです。
自動でコマンドラインでディレクトリを作るところからプロジェクト設定ファイルなどの作成・編集、指示次第ではスキャフォールディングもやっちゃいます。既存ファイルがあるプロジェクトでは、ファイル構造を調べて適切な場所にファイルを作成したり、臨時サーバを立ててデバッグして問題特定してくれたり。
サービス過剰でちょっとビビります。
Cursorを引き合いに出しましたけど、Github Copilotのほうが近いかもしれないですね、使ったことないけど。
自律的に「指示内容が動くところまで作る」をやってくれる、アシスタントというよりは部下というか、無口だけど仕事ができる中途で入ってきた人みたいな印象です。
ASKモードとAIチャットの違い
ちなみにAskモードだとコード変更はされず、通常のClaudeのチャットがマークダウンで、全プロジェクトから参照できるスクラッチフォルダに、プロンプトの原文の名前で保存されます。
AIチャットと違って自動保存かつマークダウンで読みやすいので、改名して開発用のドキュメントとしてプロジェクトに含めるのもアリだと思います。
生成例
## 原因
このエラーの原因は、プロジェクトに**同じ名前の複数のターゲット**が存在することです。
具体的には：
1. **ライブラリターゲット** (`src/lib.rs`) - WASM用
- `Cargo.toml`の`[lib]`セクションで`crate-type = ["cdylib", "rlib"]`として定義
- パッケージ名 "trackinect" を使用
2. **バイナリターゲット** (`src/main.rs`) - ネイティブ実行用
- デフォルトでパッケージ名 "trackinect" を使用
両方のターゲットが同じ名前 "trackinect" を持つため、ビルドパイプラインが「どちらのターゲットをビルドすべきか」を判断できず、`found more than one target artifact: ["trackinect", "trackinect"]` エラーが発生しています。
## 解決方法
以下のいずれかの方法で解決できます：
### 方法1: バイナリターゲットに別の名前を付ける
`Cargo.toml`に以下を追加：
```toml
[[bin]]
name = "trackinect-desktop"
path = "src/main.rs"
```
### 方法2: 不要なターゲットを削除する
- WASM版のみが必要な場合：`src/main.rs`を削除
- デスクトップ版のみが必要な場合：`src/lib.rs`を削除し、`Cargo.toml`の`[lib]`セクションを削除
### 方法3: 条件付きビルドを設定する
特定の条件下でのみ各ターゲットをビルドするよう設定：
```toml
[[bin]]
name = "trackinect"
path = "src/main.rs"
required-features = ["desktop"]
[features]
desktop = []
```
現在のプロジェクト構造を見ると、WASM用のライブラリが主要な目的のようですので、**方法1**（バイナリターゲットのリネーム）または**方法2**（main.rsの削除）が適切だと思われます。スクラッチフォルダはWindowsだと ％APPDATA%\JetBrains\{IDE.versions}\scratches 内に、IDEごとに作成されています。なのでPHPStormで出力されたmdをWebStormでも使いたい、といった場合は上記フォルダから手動でコピーするしかないかもです。
全プロジェクトで参照できるんですけれどスクラッチフォルダのルートにガンガン生成されていきますので、他のプロジェクトで生成されたmdが邪魔ってのはあるあるです。プロジェクトごとに書き出し場所を変えれるような設定ができるように機能リクエスト出してます。
Junieで使えるLLM
いまのところAnthropicのClaude Sonnet3.5、4のみです。
Junieのいいところ
環境ごと作ってくれる
例えば新機能のアイディアを試すために、とりあえず動くサンドボックスがほしいとき。そのへんのDockerイメージを拾ってきてもいいですけど、ビミョーに環境が揃わなくてやむなくdocker-compose手書きってことありませんか？私はよくあります。
こんな時、Junieに
「Xserverと同じLAMP環境でCodeIgniterのAPIサーバをつくりたいのでdocker-composeファイルを作ってください。APIのソースルートはsrcにミラーしてDBは永続化させてください」
とこんなフワッとした指示を投げてトイレ行って帰ってくると、環境が出来てるわけですよ。時短どころの話ではないです。
どう実装したらいいかわからないものも作ってくれる
まぁプログラマとしてどうなんだって話なんですけどね💦
たとえば「ローンの金融計算作って」とか門外漢だと要件を調べるところからですけど、
- 借入金額
- 金利
- 期間
- ボーナス払い有無
- 総支払額
- うち利子分
このくらいの内容が、5分くらいでフロントエンド付きで出来上がってきます。まじフロントエンジニア涙目なんじゃないでしょうか。
「なんかもうFWいらなくね？」な気分になる
今のSEは多かれ少なかれフレームワークを使った開発をしていると思います。Rails系をはじめとするWeb系フレームワークは大規模でも運用できるようにヘビー級なものが多いですが、個人開発や小規模開発だと、使わない機能もてんこ盛りです。それなりの工数がかかるチューニング作業は省かれがちで素の状態で使うことも多く、実行時も不要な機能にリソースを持っていかれてる感があります。
AIエージェントだと少ない労力で、必要十分の機能でオレオレフレームワークが作れてしまうので、低スペックサーバでもサクサク動いてしまうんですよね。「保守もJunieにドキュメント作らせて、監査もJunieに任せたらいいのでは……？」という悪魔の囁きが聞こえてきます。
現実的なところだとPHPだとIgniterなどのOSSの軽量フレームワークに、必要な機能だけ自前実装とかのほうがランニングコストも保守コストも抑えられるんじゃないかと思います。
Junieが苦手なところ
大規模構成は一度には処理できない
TransformerのAI全般にいえることですが、処理するテキスト量が増えすぎるとハングアップしてしまいます。Claudeとかも1チャットで扱える文章量に制限を設けてますが、多分同じ理由かと。
テキトーに指示すると重複コードが出やすい
毎回関連ファイルを走査してコーディングスタイルが近いファイルを生成しているので、他のコードが変数ハードコーディングだと生成されるコードも同じようにハードコーディングな設計になりやすいです。
同様に、匿名関数を使いまくっているコードを参考にされると同じような機能の匿名関数だらけになることも。
重複する処理はモジュール化してなど、プロンプトでその都度指示する必要があります。（ちなみにGoogleのAIStudioのような事前定義プロンプトの機能はJunieには今のところありません）
あとからリファクタリングの指示をすると対象ファイルが多くなって、クソ重になりがちです。（まぁこれはAIに限った話じゃないですけど。。）処理途中でLLMがハングアップして動かなくなったりします。生成時にしっかり指示するか、生成後の内容を確認してこまめにリファクタリングした方がきれいなコードになります。時間とクォータ消費量にも優しいですし。
マイナーなライブラリは使ってくれない
内製のライブラリとかを使うと、プロンプトに書いても、後述するガイドラインにも「このライブラリを使って」と書いても、無視して独自実装をし始める時があります。マイナーで悪かったな（#^ω^）とキレつつ、ドキュメントも与えるとちゃんと使ってくれるようになります。
ドキュメントがないマイナーライブラリは……Junieにドキュメントを作ってもらいましょか。。
より良いJunie体験を作る
当方小規模開発者ですけど、3週間でクォータを使い切ってしまったくらいには使い倒してますので、AIエージェントを活用するノウハウは溜まってきました。
書き出して振り返ってみると、割と当たり前というか……。チーム開発のノウハウとそんなに変わらないのではないかなと感じています。
.junie/guidelines.mdは作ったほうがいい
事前定義のテンプレプロンプトはないんですけど、ガイドラインというファイルを作って、そこにプロジェクト構造やコーディングルールを記載することができます。Junieの+ボタンを押すとガイドラインを作るメニューが出てきます。プロンプトも勝手に生成されますので、とりあえずそのまま作っておいていいと思います。
英語で生成されますが、日本語で追記しても内容を認識してくれるようです。
ガイドラインにルールを追加させる
直接上記ファイルに記入していってもいいんですが、手書きだと無視されることがあります。推測ですが、矛盾や齟齬があるとスルーしてしまうのかなと。
そんなわけでこのガイドライン自体もJunieに書かせた方が遵守してくれる……ような気がしています。
例えば先程の重複コードの例だと
クラスxxxとクラスyyyでは重複する処理が見られます。これらの共通処理部分を抜き出した抽象クラスAbXを作り、xxxとyyyはそれを継承するように修正してください。
同様な処理はこの抽象クラスを継承する、という旨をガイドラインに追記してください。回りくどい感じしますけど、こう書いておくことで似た機能のクラスzzzを生成する指示を出すときにはAbXを継承してくれます。プロジェクト構造から察して継承してくれるときもありますが、Junieからガイドラインに書いておけばほぼ確実です。ほぼ、です。
1ファイルを大きくしない
Junieは、こちらが何も考えないで「直してください」「追加してください」とプロンプトを与え続けると、なるべく1ファイルで完結させようとしてどんどんファイルが大きくなります。5000行とかあっても気にしないで増やし続けます。
こうなってくると修正箇所を追うのも大変になるので、500行超えたくらいで機能別にモジュールで分割してくださいとか適宜挟んだほうがいいです。
モジュールが増えてくると全部のモジュールを走査しようとするので、
Aはモジュールa1,a2,a3,a4,a5,...を使用しています。これらの関連性をmarmaid形式でUML図を作成しドキュメントフォルダに保存してください。
Aを使用する場合はUML図を参照するようにガイドラインに追記してください。これで少し走査の範囲を狭めることができます。
小分けに作業させる
Junieは生成時に自動的にテストコードも生成してエラーが出なくなるまで修正を続けるシゴデキなやつです。一方で、LLMで処理できる文字列の最大量が決まっているのは上でも書いたとおりです。
1個のチャットでプロンプトを続けていくと過去のプロンプトや生成物の内容も参照しているようで、小規模な修正依頼でもLLMが反応しなくなる時がよくあります。
生成作業が一区切りついたらDoneのボタンを押して、過去の記憶から開放してあげましょう。
ドキュメントを作る
これは人間に指示するときも同じですけど、ドキュメントがあるなしでは成果物の精度がけっこう変わります。人力でドキュメントを作成・維持するのはかなり時間コストが高いですが、これもJunieにまかせてしまいましょう。
ガイドラインに プロジェクト構造はドキュメントのインデックスを参照すると追記するとなお良さげです。
そこそこ重い処理になるので、マイルストーンごと・Devブランチにマージするタイミングなど頻度は少なめでいいと思います。
たまに再起動してあげる
LLMから応答が無くなることは結構よくあります。Junieのウィンドウで停止して新しいチャットでやり直しても調子が悪いときがあるので、そんな時はIDEを再起動するのが一番です。
終了してもゾンビプロセスになっていることが多いので、タスクマネージャでキルしてスッキリ再出発。
思いつくかぎりではこんなかんじですねぇ。クォータを使い切っちゃったのであと2週間くらい試せないんですけど、もっと改良できそうなアイディアもあるので別記事でに起こしていこうと思います。
コメントを残す