はじめに

AI開発が急速に進む昨今、コーディング支援ツールも無数に登場し、まさに「戦国時代」の様相を呈しています。
皆さんのチームでも、すでに何らかのAIツールを導入しているか、導入を検討しているのではないでしょうか。

新規プロジェクトであれば、技術選定の段階でAIツールを統一できます。
しかし、既存のプロジェクトでは、開発者それぞれが好みのAIツールを使い、統一が取れていないケースも多いのではないでしょうか？

実際、私が参加している数年来のプロジェクトでも、AIツールの導入自体は進めていたものの、各自が異なるツールを使うバラバラの状態が続いていました。

この記事は、そうした状況をトップダウンで一斉に変えるのではなく、ボトムアップでJetBrainsのAIエージェント「Junie」のチーム導入を試みた体験記です。

AI導入には興味があるものの、

既存のワークフローが混乱するのではないか
AIが生成するコードの品質は大丈夫か

といった懸念を持つ開発者やテックリードの方々に向けて、私たちのチームが実践した 「4つのスモールステップ」戦略 をご紹介します！

Junieとは何か？ AI Assistantとの関係性

私たちのチームは、日頃からIntelliJ IDEAを利用して開発を行っています。
まず重要なのは、JetBrains AIの機能群には2つの側面があることです。

AI Assistant (補佐役) 従来のAIアシスタント機能です。コード生成、チャット、要約など、開発者のワークフローにAI機能を「組み込む」役割を担う
Junie (協働エージェント) AIコーディングエージェントです。開発者と「協働」し、タスク計画、複数ファイル編集、そして変更後のテスト実行と検証までを自律的に実施

この2つは境界が曖昧ですが、私はこの補佐から協働へのグラデーションこそがスモールステップ戦略の核だと考えました。まずは、AIエージェントに抵抗がある開発者に、補佐役として慣れてもらうことから始めたのです。

↓もっとJetBrains AIを知りたい方は、公式ページをご参照ください↓
JetBrains AI Assistant
Junie

導入の壁：既存プロジェクト特有の心理的・技術的障壁

既存プロジェクトへのAI導入には、特有の障壁が存在します。

心理的障壁: まだまだAIツール（特にJunieのように自律機能を持つもの）に対して懐疑的な開発者がいます。Stack Overflowの調査(2025)によれば、「AIの提案は“ほぼ正しい”が、結局デバッグに時間がかかり、逆に生産性が落ちる」というフラストレーションが最大の不満点として挙げられています。また、責任の重いタスク（例：プロジェクト計画やデプロイ）をAIに任せることには強い抵抗感があるという開発者の声も挙げられています
技術的障壁: 既存プロジェクトには、独自のコーディング規約、アーキテクチャ、そして暗黙のルールが往々にして存在します。AIがこれらを無視したコードを生成すれば、即座に使えないと判断されてしかねません

導入最大の障壁：JetBrains AIのセキュリティとプライバシー

チームでの導入検討時、最初に直面した最大の障壁がセキュリティとプライバシーの問題でした。

プロジェクトのコード（＝企業の知的財産）をAIに送信する以上、コードがAIの学習に利用されないという確証が必須だったのです。

この点において、JetBrainsのポリシーは非常に明確です！

データ保持（学習）はデフォルトでオフ:
商用ライセンスでは、ユーザーが明示的に許可（オプトイン）しない限り、データは保持・学習されない
企業ライセンスは管理者制御:
組織でのデータ共有は管理者が一元管理するため、個々の開発者が誤って設定を変えることはできない
ローカルファイルも制御可能:
.aiignore ファイルを使い、機密情報を含む特定のファイルやフォルダをAIの処理対象から明確に除外可能

参考：Product Data Collection and Usage Notice

この強力なプライバシーポリシーこそ、導入戦略の要です。
セキュリティ部門や、AIに懐疑的なチームメンバーを説得する上で、 最も強力な「お墨付き」 として機能しました！

💡 補足：組織でAI利用が制限されている場合
実際、私たちの会社でも当初は管理者がAI利用をオフにしていたため、使えない状態でした。
もし皆さんの組織でも利用が制限されている場合は、まず管理者の説得が必要です。
その際、本記事で紹介したセキュリティポリシーや導入のメリットが、説得の材料として役立てば幸いです！

実際にチームにJunieを導入した4つのスモールステップ

前置きが長くなりましたが、いよいよ本題です。
セキュリティの安心を大前提に、私たちのチームは以下の4つのフェーズでJunieの導入を進めました！（厳密には、既成事実を作り徐々に浸透させていきました笑）

###【表1：既存プロジェクトへのJunie導入4ステップ・ロードマップ】

フェーズ	目的	主な機能	対象プラン	チームの反応
Phase 1	AIを安全に試す	無制限コード補完 + 少量のクラウド機能（コミットメッセージ、ドキュメント生成）	AI Free	コストゼロで日々の作業が楽に。AIへの心理的ハードルが下がり、同時に無料枠の限界を体感。
Phase 2	AIの真価を知る	AIチャット、テスト自動生成、リファクタリング支援	AI Pro Trial (30日間)	AIが便利なアシスタントから相談相手に。チーム内でAI Proプランを契約するか評価。
Phase 3	AIを教育する	`.junie/guidelines.md` によるプロジェクト規約の指定	AI Pro Trial (30日間)	AIがプロジェクトの文脈を理解するように。手直しの量が減る。
Phase 4	AIと一緒に仕事をする	Junieエージェントによる自律的な複数ファイルリファクタリング、テスト実行と検証	AI Pro	開発者は「指示者」に。AIが「実行者」となり、生産性が飛躍的に向上。

Phase 1：AI Freeプランで心理的ハードルを下げる

スモールステップの第一歩は、コストもセキュリティリスクもゼロで始めることです。
ローカルLLMを利用するという選択肢もありましたが、試してみたところマシンスペックを要求され開発に支障が出たため、クラウド機能を選択しました。

AI Freeプランの真価とは

JetBrainsは、IDEライセンスを持つすべてのユーザーにAI Freeプランを提供しています。
このプランが導入の第一歩として優れている点には、以下の2つがあります。

無制限のローカルコード補完: JetBrains独自のモデルによるコード補完が、クレジット消費なしで無制限に使える
無料AIクレジット付与: 高性能なクラウドモデル（OpenAIやAnthropicなど）を利用するための3 AI Creditsが毎月付与

この無制限のローカル補完と無料クラウドクレジットの組み合わせが、マシンスペックを問わず、チーム全員がAI導入の第一歩を踏み出すための、入口となりました。

実践例：無料クレジット(3 AI クレジット)で地味に面倒な作業を自動化する

私たちは、貴重な無料枠（3クレジット）を使い、チームの振り返りで「地味に面倒だよね」と話題に上がったコミットメッセージの自動生成を試しました。

開発者は当然コードの内容を把握していますが、チームからは以下のような「地味な悩み」が上がっていたのです。

連休を挟むと、何を変更したか思い出すのが面倒
英語で的確なコミットメッセージを書くのが地味に大変
変更点が多くて、メッセージが端的にならない

共感してくださる方も居るのではないでしょうか。

【無料で試せるアイディア】コミットメッセージの自動生成

自動生成の方法はとても簡単です。

Commitツールウィンドウで、Generate Commit Message with AI Assistant ボタンをクリックするだけです。

AI Assistantが差分（diff）を分析し、的確なメッセージを数秒で生成してくれます。（以下はFizzBuzzの例）

チームの評価と所感

コスト効率:
消費クレジットは極めて少なく、無料プランで1ヶ月試したところ、1クレジット程度の消費で実用的に使えました。
品質（限界）:
ただ、この段階ではプロンプトを調整していないため、単に差分が列挙されるだけで、最終的には開発者自身が手直しする必要がありました。
価値（効果）:
それでも、チームの反応は非常に好意的でした。

以下が、振り返りで上がったコメントです。

「コミットメッセージの “叩き台” を作ってくれるだけでも、心理的負担が減った」
「AIの提案を見て、コミットの粒度を分けるヒントになった」※1

※1補足：GUI上でコミットするファイルを選択できるため、AIのコミットメッセージが長かったり複数の機能が入っている場合に、コミットを分ける判断材料になった、ということです。

Phase 1の総括

このステップで、懐疑的だったメンバーも「便利なアシスタントだ」と認識し始めました。

同時に、AIチャットやテスト生成など、より高度な機能を試そうとすると3 AI クレジットは枯渇してしまうというプロブレムもチーム内から上がり始めました。
この 「もっと使いたい」という内部ニーズ(需要) こそが、次のステップに進む強い動機付けとなりました！

Phase 2: AI Pro Trialで「相談相手」を見つける

Phase 1が想定以上に好評で、チーム内から「30日間のAI Pro無料トライアルがあるから、試してみようよ！」という声が上がりました。そこで、チーム全体でProトライアルへ移行。

目的は、無料枠では試せなかった「クレジット消費の多い高度な機能」を使い、AIが月額料金を支払う価値のある「相談相手」として実務に耐えうるかを評価することに設定しました。

実践例：単体テストの雛形生成

記述量が多く、定型的になりがちな正常系テストの作成をAIに任せることにしました。

テスト対象のクラスやメソッドで Alt+Enter（macOSでは ⌥⏎）を押す
AI Actions | Generate Unit Tests を選択
AIが文脈を分析し、テストの雛形を生成します（既存ファイルへの追加、または新規作成)

先ほどのFizzBuzzを対象に生成した単体テストが以下の通りです。

ただ、このままだとテスト内部に本番とほぼ同様のロジック（i % 3 == 0など）が組み込まれており、テストとして不十分です。

そこで、Specifyボタンから「3の倍数のケース、5の倍数のケース、15の倍数のケースを具体的にテストして」と追加で指示（※英語のみ）を出すことで、より実用的なテストコードに調整できます。

調整後の結果は省略しますが、概ね指示通りに生成されました。

サンプル用にサクッとイメージを掴んでもらうために生成した単体テストなので、改善の余地は十分にある点はご容赦ください。

チームの評価：生産性向上と新たな課題

AIが生成した雛形をレビューし、エッジケースを追加する作業に集中できるようになったことで、　「テストを書き始める速度が圧倒的に上がった」　という声が上がりました。これは無料枠では試せなかった、明らかな生産性向上です。

しかし同時に、　「今のままではプロジェクトのコーディングルールに沿っておらず、手直しが多い。それなら初めから自分で書いた方が良い」　という、もっともな意見も出てきました。

Phase 2の総括

トライアル開始から2週間が経過した時点での「この相談相手に月額料金を支払う価値はあるか？」という問いに対するチームの評価は、　「賛否両論」　という結果になりました。

反対派の主な意見は、以下に尽きます。

「AIがチームのコンテキスト（コーディング規約など）を理解してくれないなら、無料のChatGPTやGeminiで十分ではないか？」

この課題こそが、次のフェーズ（AIの教育）へ進む動機となりました。

Phase 3: AIを教育し、チームの一員にする

Phase 2の総括で出た「AIがチームのコンテキスト（規約）を理解してくれないなら、無料のChatGPTやGeminiで十分ではないか？」という意見は、Junie導入における核心的な問いでした。

確かに、一般的な質問やアルゴリズムのコード片を生成するだけなら、外部のAIツールでも十分かもしれません。

なぜ、IDE組み込みのJunieを使うのか？

私がチーム内にAIを活用した開発を浸透させていくにあたり、Junie（JetBrains AI）を選択した理由は、外部AIでは解決が難しいプロジェクトコンテキストとの統合にあります。

IDE組み込みのJunieならば、以下の2つのコンテキストを自動でAIに連携できます。

IDEとの深い統合 (動的コンテキスト) IDEと統合されているため、コードの静的解析（エラー、警告など）、ファイル間の依存関係、Gitの差分など、IDEが持つ膨大な動的コンテキストを自動的に理解させることが可能
プロジェクトコンテキストの永続化 (静的コンテキスト) 後述する.junie/guidelines.mdにより、Junieにプロジェクト固有のルール（静的コンテキスト）を記憶させることが可能

Phase 3の目的は、AIを教育しチームの一員とすることです。

これまでのAI Assistantという「補佐役」から、プロジェクトのルール（静的）とIDEの現状（動的）を理解して協働する「パートナー（Junie）」へとAIを進化させるフェーズであり、私たちのチームはここでJunieの本格検証を開始しました。

`.junie/guidelines.md` 知識の注入

Junieをパートナーとしていくにあたり、まずは.junie/guidelines.mdの整理から着手しました。

.junie/guidelines.mdとは、プロジェクトのコーディング規約やADR（アーキテクチャ決定レコード）などをAIに記憶させておくことができるファイルです。

チーム内のコーディング規約やADRといった既に整理されていたものから、細々とした開発者の好み（暗黙知）に至るまでチーム内で話し合い、最低限のルールをguidelines.mdに記載しました。

とはいえ、この時点でガイドラインを作り込みすぎなかったのには、理由があります。

あくまで性能評価の過程であり、「新しいチームメンバー」を迎える気持ちで暖かく育てていこうとチーム内で合意したため
正直なところ、ルールの完璧な整理・明文化作業は非常に大変であり、そこに時間を使うよりもまずJunieを触ってみることを優先したかったため

Tips:
JetBrainsは、Spring Boot(Java)、Django(Python)、Gin-Gonic(Go)など、主要フレームワークのガイドライン例をGitHubで公開しています。どのように書けば良いか悩む場合は、参考にすると良いでしょう。

私たちのチームもSpring Bootで開発を行っているため、これを参考にしながら、最低限守ってほしいguidelines.mdを整理し、使ってみることとしました。

実例：ガイドラインを用いたテスト生成

Phase 2で使ったFizzBuzzのコードに対し、仮想のプロジェクトルール（.junie/guidelines.md）を用いて単体テストを作成してみます。

ガイドラインは以下のようにしました。

.junie/guidelines.md

# Project Guidelines

## 1. Refactor for Testability
**DO NOT** test `static void main`.
**MUST** refactor logic from `main` into a new, testable, public method.
All tests **must** target this new method.

## 2. Test Naming Convention
**MUST** use `should_ExpectedResult_when_Condition` naming.

## 3. Use Parameterized Tests
**MUST** use `@ParameterizedTest` with `@CsvSource` for testing multiple input/output pairs.
**DO NOT** create separate test methods for each value.

【ガイドラインの意訳】

ルール1（リファクタリング）: mainメソッドはテストしない。AIは、テストしやすいようにロジックを別のメソッドに分離すること
ルール2（命名規則）: テスト名は「（条件）のとき（結果）になるべき」という形式で、分かりやすく命名すること
ルール3（まとめ方）: 似たようなテスト（例：FizzBuzzなら「3の時」「5の時」「15の時」）を別々に作らず、@ParameterizedTestを使って1つにまとめること

ガイドラインを整理した上で、JunieにはCreate unit testsというシンプルな指示でテストを作成してもらいました。（あえてシンプルな指示にしたのは、ガイドラインがなければ、AIが FizzBuzz.java をリファクタリングする理由がないはずであり、ルールが正しく機能しているか示すためです。）

実際に、Junieを実行した結果のスクリーンショットが以下です。

Junie実行後のリファクタされた FizzBuzz.java と FizzBuzzTest.java は以下の通り。

FizzBuzz.java

public class FizzBuzz {
    public static String fizzBuzz(int n) {
        if (n % 15 == 0) return "FizzBuzz";
        if (n % 3 == 0) return "Fizz";
        if (n % 5 == 0) return "Buzz";
        return String.valueOf(n);
    }

    public static void main(String[] args) {
        for (int i = 1; i <= 100; i++) {
            System.out.println(fizzBuzz(i));
        }
    }
}

ルール１の通り、mainメソッドからロジックが切り出され、fizzBuzz(int n)メソッドへとリファクタリングされています。

FizzBuzzTest.java

public class FizzBuzzTest {

    @ParameterizedTest
    @CsvSource({
            // basics
            "1,1",
            "2,2",
            "3,Fizz",
            "4,4",
            "5,Buzz",
            "6,Fizz",
            "10,Buzz",
            "15,FizzBuzz",
            "30,FizzBuzz",
            // some higher numbers in the typical range
            "98,98",
            "99,Fizz",
            "100,Buzz"
    })
    public void should_ReturnExpectedFizzBuzz_when_InputProvided(int input, String expected) {
        // Act
        String actual = FizzBuzz.fizzBuzz(input);

        // Assert
        assertEquals(expected, actual);
    }
}

単体テストも、ルール2の命名規則通り（should_Return...）になり、ルール3の通り@ParameterizedTestを使ってシンプルにまとめられました！

Phase3のチーム評価と所感

この結果にはチーム内でも良い反応がありました。

「AI Assistantと比べても、Junieの方が質の高い単体テストやリファクタ案を出してくれる」
「Junieがプロジェクト固有ルールや今書いているコードを理解して適切に修正してくれる。これこそIDE統合の恩恵だ」
「これなら外部のChatGPTやGeminiよりも使い勝手が良い」

と、チーム内でも肯定的な声が多くなりました。

最終的に、無料Trialの終了を待たずして「AI Proプランを契約しよう」という話になりました。

Phase 3の総括

この.junie/guidelines.mdを作成するプロセスは、AIを教育すると同時に、チームの暗黙知をドキュメントに落とし込むという強力な副次的効果をもたらしました。

「私たちのプロジェクトのルールとは何か？」をチームで議論し、合意形成するプロセスは、AIのためだけでなく、チーム全体のコーディング規約の統一・再認識にも効果を発揮しました。（この副産物として、レビューでの指摘も減ったように感じています）

なお、一点注意点があります。

.junie/guidelines.mdは主にJunieエージェントのためのものです。

Phase2まで主に使っていたAI Assistantの動作（例：コミットメッセージなど）は、

IDEの
Settings | Tools | AI Assistant | Prompt Library

で制御されています。

この「二重管理」状態は、現状の課題だと感じています。

ただ、私たちのチームではPrompt Libraryの設定内容もプロジェクトのWikiに記載しているため、オンボーディングの際にコピペして一度設定するだけ、と割り切り、大きな負担にはならないと判断しました。

もし、IDEのCode Style設定のように、Prompt Libraryもインポート/エクスポートできる簡単な方法を知っている方がいたら、ぜひ教えてくれると嬉しいです。（あるいは、この記事を読んだJetBrainsの中の人が「良いな」と思ったら、開発していただけると嬉しいです！）

私たちのチームの場合、フェーズ3の段階で無料トライアルが終了しました。

先ほども書きましたが、チームとして「AI AssistantやJunieを使い倒した方が、生産性もコードの品質も上がる」という点で合意が取れ、AI Proプランを契約することを決めました。

Phase 4: Junieと一緒に仕事をする

いよいよ、Junieの本来の力である自律的なタスク実行を本格的に活用し、AIと一緒に仕事を進めていくフェーズに入りました。

Proプランを契約すると決めた時点で、私の「Junieの導入」という目標は完了しています。
しかし、ツールは入れただけでは意味がありません。

使ってこそ価値があります。

そこで最後に、私たちチームが実際にJunieを使ってみて感じた「使い所」と、正直な「失敗談」を共有したいと思います。

失敗談： Junieは曖昧なタスクが苦手

まず、Junieは（そして現行のAIは皆そうですが）全知全能の神ではありません。
ついつい以下のような曖昧なタスクを丸投げしてしまいました。

このWebサイトのデザインを今風にして
古いプロジェクトのコード(oldProject/)を新しいアーキテクチャを適応して
（広範囲の）パフォーマンスを改善して

結果: Junieはタスクの意図を汲み取れず、空のファイルを生成したり、的外れな変更を加えたりして、タスクを完了できませんでした。

今回の記事で使った FizzBuzz.java のような単一クラス・少量コードであれば、「パフォーマンスを改善して」という曖昧な指示でも意図を汲んでくれることがありますが、実際のプロジェクトではそうはいきません。

「どのファイルを」「具体的にどういった方法で（例えばStream APIを活用して）改善したいのか」まで、具体的に指示を出す必要がありました。

失敗から学んだこと

AIエージェントであるJunieも、人間と同じです。曖昧な指示では意図を理解できず、開発者が期待した通りに動くことはできません。

一緒に働く同僚や後輩にタスクをお願いするように、「何を」「どのように」して欲しいのかを省略せず、具体例を交えて伝えることが重要だと改めて感じました。

AIエージェントを使いこなす上でも、開発者側にはタスクを適切に分解し、言語化する能力が、引き続き（あるいは、より一層）重要であると痛感させられた失敗談です。

私たちのチームでは、振り返りの際にこうした失敗談と成功談を共有し、ノウハウを蓄積していきました。
その中でも、特にチームの生産性向上に直結した成功例を紹介します！

成功例：Junieの真価「テスト実行・検証」サイクル

失敗から学び、タスクを具体化できるようになったことで、AIが生成するコードの質は格段に上がりました。

私たちはさらに一歩進め、Junieが「自分で動作を確かめる」仕組みを活用し、単体テストのサイクルを効率化しました。

これこそが、Junieの真価ともいえる 「テスト実行と検証」機能 です。

なぜテスト生成が強力なのか？

Junieは、コードから仕様が読み取りやすい正常系の単体テスト作成において、絶大な効果を発揮します。
メソッドやロジックを分析し、正常系のテストケースを高速で生成できるためです！

しかし、Junieの強みは生成するだけではありません。

コードを生成した後、自律的にテストを実行し、すべてがグリーンになるまで検証することが可能なのです。

もしAIが生成したコードがコンパイルエラーを起こしたり、既存のテストを失敗させたりした場合、Junieはそれを「検知」し、自ら修正を試みます。

開発者はバグの温床に集中できる

この正常系のテスト自動化がもたらす価値は絶大です。
私たちチームは、単調になりがちな正常系テストの記述作業から解放されました。

その結果、開発者のリソースを、本当に頭を使うべき異常系やエッジケースといった、バグの温床となりやすいロジックの検証に集中できるようになりました。

Junieが正常系はパスしたという"お墨付き"を与えてくれる安心感が、より複雑なケースのテスト設計に臨む上での、強力な心理的セーフティネットにもなっています。

AIと協働し、カバレッジと品質を両立させる、これが私たちのチームの成功パターンとなりました。

まとめ：既存プロジェクトへのJunie導入は、スモールステップが鍵

私たちのチームは、まず AI Free プランでリスクゼロで「便利さ」と「限界」を体験し、次にAI Proトライアルで「AIがプロジェクトの規約を理解しない」という壁に直面しました。

この課題は、.junie/guidelines.mdでAIを教育することで解決でき、このプロセスは「チームの暗黙知の明文化」という副産物も生みました。

私たちが感じているJunieの真価は、AIが単なるツールを超え、自律した同僚エンジニアのように協働してくれる点にあります。

例えば、Junieに正常系テストの生成・検証を任せることで、開発者は異常系・エッジケースといった、より重要な作業に集中できるようになりました。

Junieを既存プロジェクトに導入したいと考えている方の参考になれば幸いです。
まずは、AI Freeプランや無料トライアルを使い倒して新しい開発体験をチームに "布教"することをおすすめします！

この他にもJunieを活用したコードレビューやMCPサーバの活用などもありますが、長くなりすぎてしまうので、本アドベントカレンダーに参加している他の方に譲りたいと思います。（また、別の機会に書きます）

長文ではありましたが、ここまで読んでくださりありがとうございました。

おまけ

今回の記事を執筆するにあたり、私物のPCでサンプルコードの生成、AI Assistant, Junieの利用をしました。

実際にかかったコストは、以下の通り約1クレジットでした。

（プライベートで別件で使ったものもあるので厳密ではありませんが、目安として）

当記事は、誤字脱字や可読性の向上等の添削、サンプル用コードのアイディア出しや生成にGemini 2.5 Proを利用しましたが、文章構成やアイディアは筆者オリジナルのものです。