Junieをチームで使う前に：Guidelines・.aiignore・Semantic Indexingを分ける基準

このテーマをもう少し広げて見るなら、AGENTS.md標準化の実務影響：AIコーディング指示ファイルをチーム運用に入れる判断基準 と VS CodeのCopilot Agent ModeにMCPをつなぐ前に：sandbox・allowlist・料金を確認する も合わせて確認してください。JunieのGuidelines pathと、repo共通のAGENTS.mdをどう扱うかを整理できます。

3行まとめ

IDE

JetBrains IDE内のagentとして使う。

Scope

Project pathで編集範囲を決める。

Rules

AGENTS.mdやGuidelinesを渡す。

Index

Semantic Indexingを判断する。

JunieはIDEに近いagentなので、project設定を運用設計として扱います。

• JunieはJetBrains IDE文脈を使って、複数stepのtaskを計画、実行し、testやterminal commandも扱えるcoding agentです。
• チーム導入では、Project path、Guidelines、.aiignore、Enabled technologies、質問頻度、Semantic Indexingを分けて決めると、agentが触る範囲を説明しやすくなります。
• 最初は.junie/AGENTS.mdまたはrootのAGENTS.mdへ短いrepo ruleを置き、.aiignoreで読ませない情報を外し、小さな差分とtest追加から始めます。

本文の事実確認には、JetBrains AI Assistant docs、Junie Guidelines docs、Junie CLI docs、IDE Services Cloud docs、Junie公式サイトを使っています。Xで見かけるJunie、JetBrains IDE agent、AGENTS.md、.aiignoreへの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Guidelines

repo ruleをどこへ置くか。

.aiignore

読ませないfileを決める。

Questions

質問頻度をriskで変える。

CLI

IDEとterminalを使い分ける。

JetBrains利用者には、IDE文脈を活かす設定が導入品質を左右します。

• Junieをチームで使う時に最初に分ける運用境界
• Project pathを編集範囲として扱う考え方
• Guidelines、.junie/AGENTS.md、rootのAGENTS.mdをどう分けるか
• .aiignoreで読ませないfileやdirectoryを決める方法
• Enabled technologies、質問頻度、Semantic Indexingの判断軸
• Junie CLIとIDE内Junieをどう使い分けるか

Junieは、JetBrains IDEを使うチームにとって自然なAI coding agent候補です。IntelliJ IDEA、PyCharm、WebStorm、GoLand、Riderなどの開発体験に近く、project context、terminal、test、IDE機能とつながりやすいからです。

一方で、IDEに近いagentだからこそ、どこまで読ませるか、どこまで編集させるか、どのproject ruleを毎taskへ渡すかを先に決める必要があります。

前提知識

項目	内容	見方
Junie		multi-step taskを計画、実行するagent。
Guidelines		persistent contextを毎taskへ渡す。
.aiignore		処理対象からfileやdirectoryを外す。
Project Settings		path、technologies、質問頻度を設定する。

Junieは補完機能ではなく、IDE内で作業するcoding agentとして理解します。

JetBrains AI Assistant docsでは、JunieをJetBrainsが開発したAI coding agentとして説明しています。主な役割は、promptに基づいて複雑なmulti-step actionを自律的に計画し、実行することです。large-scale edits、tests、terminal commands、external toolsを必要に応じて扱い、進捗を報告します。

同じdocsでは、Junieが.aiignoreを尊重すること、Guidelinesを毎taskへ渡せること、Project SettingsでProject path、Guidelines path、Enabled technologies、質問頻度、Semantic Indexingを設定できることが説明されています。

この記事の扱う範囲

項目	役割
Project path	Junieが作業するproject directory
Guidelines	agentへ毎回渡すpersistent context
.junie/AGENTS.md	Junieで推奨されるGuidelinesの配置
root AGENTS.md	project rootの共通agent rule
.aiignore	Junieが処理しないfileやdirectory
Enabled technologies	Junieに扱わせる言語やframework
Frequency of questions	Junieが質問する頻度
Semantic Indexing	semantic searchのためのcodebase indexing

2026年6月1日時点で公開されているJetBrains公式docsとJunie公式docsを確認しています。導入時には、利用中のJetBrains IDE version、Junie pluginまたはCLI、JetBrains AI subscription、企業向けAI設定、社内data policyを改めて確認してください。

注意点

JunieはAI Assistantのchat補助とは違い、実際にprojectへ変更を加え、commandを実行し、testを回すagentとして使われます。便利ですが、最初から大きなrefactorを任せるより、小さな差分で設定が効いているかを見ます。

まず6つの境界に分ける

項目	内容	見方
Scope		Project pathと編集許可。
Context		AGENTS.mdとGuidelines。
Ignore		.aiignoreの対象。
Stack		Enabled technologies。
Autonomy		質問頻度と承認。
Index		Semantic Indexing。

境界を分けると、Junieに任せた作業を説明しやすくなります。

Junieをチームで使うなら、最初に6つの境界を分けます。

境界	確認すること
Scope	Project pathと編集してよい範囲
Context	Guidelines、AGENTS.md、coding rule
Ignore	.aiignoreで読ませない情報
Stack	Enabled technologiesで扱う技術
Autonomy	質問頻度と人間確認
Index	Semantic Indexingを有効にする範囲と理由

この6つを決めずにJunieを使うと、「IDE内で便利に動いた」以上の説明が難しくなります。チーム導入では、誰のIDEでも同じルールで使えることが大切です。

IDE内agentの強み

JetBrains IDEは、project構造、language service、test runner、debugger、refactor機能に強い環境です。Junieがこの文脈に近いところで動くと、単なるtext generationよりも実作業へつなげやすくなります。

IDE内agentの注意点

IDEに近いということは、local projectのfile、generated code、secretに近いということでもあります。.aiignore、Project path、Guidelinesを整えずに使うと、agentが読まなくてよい情報を見たり、触らなくてよい場所を提案したりする可能性があります。

判断基準

迷ったら、「Junieがそのfileを読んだ理由、触った理由、testした理由をPRで説明できるか」を基準にします。説明できない範囲は、最初は閉じます。

Project pathは編集範囲として扱う

Root

作業対象directoryを決める。

Outside

範囲外編集は確認対象。

Monorepo

subproject単位で分ける。

Review

変更fileを範囲で見る。

Project pathは単なる設定ではなく、Junieの作業境界です。

JetBrains docsでは、Project SettingsにProject pathがあり、Junieが変更を加えられるdirectory pathとして説明されています。Junieがこのdirectory外のfileやfolderを編集しようとする場合、確認を求めると説明されています。

これは単なるUI設定ではなく、agentの作業境界です。

monorepoでは必ず分ける

monorepoでは、repository root全体をProject pathにすると、Junieの探索範囲が広がりすぎることがあります。frontend、backend、mobile、infraなどのsubproject単位で始める方がreviewしやすいです。

project構成	初期Project pathの例
single app	repository root
frontend/backend分離	apps/web または services/api
package monorepo	対象package directory
mobile + backend	mobile側だけ、backend側だけに分ける
infra混在	infraは初期対象から外す

範囲外編集はsignalとして見る

JunieがProject path外を触ろうとする場合、task scopeが広すぎる可能性があります。許可する前に、なぜ範囲外fileが必要なのかを確認します。

Project pathとPR reviewを合わせる

PR reviewでも、Project path内の変更かどうかを見ます。範囲外の変更が入っている場合は、意図通りか、Junieの探索が広がりすぎたかを確認します。

初期設定例

最初は、ひとつのserviceまたはpackageだけをProject pathにします。test追加、minor bug fix、docs更新で流れを確認し、必要に応じて対象を広げます。

GuidelinesはAGENTS.mdへ寄せる

項目	内容	見方
.junie/AGENTS.md		推奨位置として扱う。
AGENTS.md		rootの共通ruleに使う。
Custom path		monorepoや特殊構成で指定。
Legacy		guidelines.mdは移行対象として見る。

Guidelinesは毎回promptへ貼る前提をrepo資産にする場所です。

JetBrains docsでは、JunieのGuidelinesがpersistent, reusable contextとしてagentへ追加されると説明されています。AI Assistant docsでは、Guidelinesは.junie/AGENTS.mdに保存でき、version control下に置いてprojectで再利用できると説明されています。

Junie Guidelines docsでは、AGENTS.md open formatとJunie-specific guidelines.mdがsupportされると説明されています。AI Assistant docs側では、.junie/AGENTS.mdがpreferred standard locationとして扱われ、rootのAGENTS.mdもfallbackとして見られます。

配置の考え方

配置	使いどころ
.junie/AGENTS.md	Junie向けの推奨位置として使う
AGENTS.md	複数agentで共有するrepo rule
custom path	monorepoや特殊構成で明示する
.junie/guidelines.md	legacyとして移行候補にする

Guidelinesに書くこと

項目	例
architecture	directoryごとの責務
commands	test、lint、build、format
style	naming、error handling、logging
forbidden	secret、public API変更、generated file
review	変更後に説明してほしいrisk

書きすぎない

Guidelinesは毎taskへ入る前提情報です。長すぎると、重要なruleが埋もれます。必ず守る項目、頻繁に間違える項目、reviewで必要な項目に絞ります。

生成して終わりにしない

Junie docsでは、Junieにprojectをexploreさせてguidelines.mdを生成できることも説明されています。これは出発点として便利ですが、そのまま正解扱いにしません。人間がreviewし、不要なruleを削り、社内の禁止事項を足します。

.aiignoreで読ませない範囲を決める

Secrets

credentialやenv dumpを外す。

Generated

生成物や巨大fileを外す。

Data

customer dataやsample dumpを外す。

Vendor

vendorやcacheを外す。

.aiignoreは安全性とcontext品質の両方に効きます。

JetBrains docsでは、Junieが既存の.aiignore fileを尊重し、そこにlistedされたfilesやdirectoriesを処理しないと説明されています。これは安全性とcontext品質の両方に効きます。

.aiignoreに入れる候補

対象	理由
secretやcredential	agentへ渡す必要がない
.env dump	local設定やtokenを含む可能性
customer data	個人情報や機密情報の混入防止
generated files	noiseが多く変更対象になりやすい
vendor/cache	contextを圧迫する
large fixtures	taskと無関係な情報が多い

.gitignoreとは目的が違う

.gitignoreはGit管理から外すfileを決めます。.aiignoreはAI agentに読ませないfileを決めます。Gitに入っているfileでも、AI agentへ渡す必要がないものは.aiignoreで外します。

例外許可を慎重にする

docsでは、明示的に許可しない限り.aiignore対象を処理しないと説明されています。例外を許可する時は、なぜ必要なのかをtaskに残します。特にdata、credentials、production configは慎重に扱います。

review観点

Junieが作ったdiffを見る時は、「.aiignoreで外すべきfileが変更されていないか」も見ます。agent導入後にgenerated fileが頻繁に触られるなら、ignore ruleを見直します。

Enabled technologiesは対象stackに絞る

項目	内容	見方
Backend		Java、Kotlin、Goなど。
Frontend		TypeScript、Reactなど。
Mobile		AndroidやRider系project。
Disable		不要な技術は外す。

対象stackを絞ると、Junieの探索と提案が読みやすくなります。

JetBrains docsでは、Project SettingsでEnabled technologiesを選べると説明されています。利用できるlanguagesやtechnologiesはJetBrains IDEによって変わります。

この設定は、Junieがどの技術を扱う前提でtaskへ向き合うかに関係します。

使っている技術だけを開く

たとえばWebStorm projectならTypeScript、React、test frameworkに寄せます。IntelliJ IDEAのbackend projectならJava、Kotlin、Maven、Gradleなどに寄せます。不要な技術を広く開く必要はありません。

project	初期対象
Java backend	Java、Maven/Gradle、test framework
Kotlin backend	Kotlin、Gradle、Springなど
Web frontend	TypeScript、React/Vue、test tool
Go service	Go、module、test command
.NET/Rider	C#、test framework、solution構成

技術を増やすタイミング

Junieが別stackにまたがるtaskを扱う必要が出たら、Enabled technologiesを見直します。最初から全部入れるより、taskの種類に合わせて広げる方がreviewしやすいです。

IDEごとの差を確認する

JetBrains docsでは、available languages and technologiesがIDEに依存すると説明されています。チーム内でIntelliJ IDEA、WebStorm、PyCharmが混ざる場合、同じJunieでも使える設定が違うことがあります。

team標準を作る

主要projectごとに、推奨IDE、Project path、Enabled technologies、Guidelines pathを短くまとめます。個人の設定に任せきりにしない方が、reviewの前提が揃います。

質問頻度はtask riskで変える

項目	内容	見方
Normal		初期導入の基準。
Never ask		低risk taskだけに限定。
High risk		auth、billing、migrationは確認を残す。
Review		diffとtest結果を見る。

質問頻度は快適さだけでなく、risk管理として決めます。

JetBrains docsでは、JunieのFrequency of questionsをProject Settingsで設定できると説明されています。defaultはnormal amountで、task processing中にJunieが質問できる設定です。Never ask meを選ぶと、task processing中にJunieから質問されないようにできます。

これは快適さだけの設定ではありません。risk管理です。

初期導入はnormalを基準にする

初期導入では、normal amountを基準にします。Junieが迷う箇所、前提が不足する箇所、追加情報が必要な箇所を見たいからです。

Never ask meに向くtask

task	条件
docs更新	対象文書と事実が明確
test追加	対象関数とcaseが明確
small rename	影響範囲が狭い
formatting	ruleが明確

Never ask meに向かないtask

auth、billing、data migration、public API変更、large refactor、security fixは、質問を残した方がよいです。Junieが迷った時に人間へ確認できる余地を残します。

質問を減らす前にやること

質問頻度を下げる前に、Guidelines、test command、Project path、.aiignoreを整えます。前提が薄いまま質問だけ減らすと、ズレた実装が進みやすくなります。

Semantic Indexingは検索性と扱う情報で判断する

Search

意味で関連fileを探す。

Privacy

扱う情報を棚卸しする。

Monorepo

対象pathを先に絞る。

Review

有効化後の挙動を見る。

Semantic Indexingは便利ですが、対象情報とproject範囲を先に整理します。

JetBrains docsでは、Semantic Indexingを有効にすると、Junieがsemantic searchで関連dataをより速く見つけられると説明されています。keyword matchingではなく、semantic meaningやcontextに焦点を当てたcodebase indexingです。

これは大規模projectでは魅力的です。一方で、何をindex対象にするか、どのproject pathで使うかを先に整理します。

有効化を検討する場面

場面	理由
large codebase	関連file探索が難しい
domain用語が多い	keywordだけでは拾いにくい
legacy project	file名と責務が一致しない
cross-module task	複数moduleの関係を見たい

先に確認すること

Semantic Indexingを使う前に、Project path、.aiignore、Guidelinesを整えます。読ませたくない情報を外さずにindexを有効にするのは避けます。

有効化後のreview

有効化したら、Junieがどのfileを参照し、どのようにtaskへ反映しているかを見ます。関係ないfileを拾い続ける場合は、Project pathやGuidelinesを見直します。

monorepoでの注意

monorepoでは、Semantic Indexing以前に対象pathを絞ります。全体を一度に見せるより、taskに関係するworkspaceやpackageから始める方が安全です。

CLIとIDEの使い分けを決める

項目	内容	見方
IDE		project contextとreviewを活かす。
CLI		terminalでreview、write、modifyする。
CI/CD		issueやpipeline起点を検討する。
ACP		editor/agent連携を理解する。

JunieはIDEだけでなくCLIにも広がるため、作業場所を決めます。

JetBrains docsでは、Junieがinteractive terminal interfaceでも使えると説明されています。Junie公式CLI docsでは、Junie CLIがterminal interfaceでcodeをreview、write、modifyするagentic coding toolとして説明されています。

Junie公式サイトでは、terminal、GitHub、GitLab、CI/CD pipelineとの接続も紹介されています。つまり、JunieはIDEだけでなく、terminalやautomation側にも広がります。

IDEに向く作業

作業	理由
code review	IDEのnavigationやdiff確認を使いやすい
framework task	JetBrains IDEのproject理解を活かせる
test修正	test runnerやdebuggerと合わせやすい
refactor補助	IDE機能に近い文脈で見られる

CLIに向く作業

作業	理由
terminal中心の調査	commandと差分確認が速い
remote環境	IDEを開きにくい環境でも使える
simple edit	小さな修正を素早く頼める
automation候補	CI/CD側へ広げやすい

CI/CDは後から検討する

初期導入ではIDE内の小さなtaskから始めます。CI/CDやGitHub/GitLab issue起点の自動化は、Project path、Guidelines、.aiignore、review flowが固まってから検討します。

ACPの位置づけ

Junie CLI docsには、Agent Client Protocolに関する説明もあります。editorやIDEとcoding agentの連携を標準化する流れとして見られますが、導入初期ではまずIDEまたはCLIの基本運用を固めます。

導入初週の進め方

1. 1日目

   Project pathと.aiignoreを確認。

2. 2日目

   .junie/AGENTS.mdを作る。

3. 3日目

   小さなtest追加を試す。

4. 5日目

   質問頻度とindexを見直す。

5. 7日目

   CLIやCI連携の必要性を見る。

初週は自動化より、IDE内でreviewできる小さな差分を優先します。

Junieの導入初週は、大きな実装よりも「IDE内で小さな差分を安全に作れるか」を見ます。

日	やること	目的
1日目	Project pathと.aiignoreを確認	触る範囲と読ませない範囲を決める
2日目	.junie/AGENTS.mdを作る	repo ruleを毎taskへ渡す
3日目	docs更新またはtest追加を試す	小さな差分で流れを見る
4日目	Enabled technologiesを見直す	不要な技術を外す
5日目	質問頻度とSemantic Indexingを検討	task riskと検索性を調整
6日目	PR review観点を整える	Junie差分を人間が見やすくする
7日目	CLIやCI/CD連携の必要性を見る	次の拡張を判断する

初週の評価軸

評価軸	見ること
scope	Project path内に変更が収まるか
context	Guidelinesが効いているか
safety	.aiignore対象を触っていないか
review	diffとtest結果を説明できるか
fit	JetBrains IDEの既存workflowに合うか

広げる条件

次の条件を満たしたら、より大きなtaskへ広げます。

• .junie/AGENTS.mdまたはAGENTS.mdが最新
• .aiignoreでsecret、data、generated fileを外している
• Project pathがtask範囲に合っている
• test commandがGuidelinesに書かれている
• Junieの質問に答える運用が決まっている
• PRで変更理由とriskをreviewできている

FAQ

AI Assistant?

chat補助とagent作業を分ける。

Guidelines?

短く保守する。

Never ask?

初期標準にはしない。

Monorepo?

pathとGuidelinesを明示する。

迷ったら、Junieが触った差分をIDEとPRでreviewできるかを見ます。

JunieとAI Assistant chatはどう分けますか？

AI Assistant chatは相談や説明、部分的な生成に向きます。Junieはmulti-step taskを計画し、file変更やtest、command実行まで進めるagentとして見ます。実作業を任せるなら、Project path、Guidelines、.aiignoreを先に整えます。

.junie/AGENTS.mdとrootのAGENTS.mdはどちらを使うべきですか？

Junie専用のruleを置くなら.junie/AGENTS.md、複数agentで共有するrepo ruleを置くならrootのAGENTS.mdが向いています。チームでCodex、Jules、Aiderなども使うなら、共通ruleはrootに寄せ、Junie固有の補足だけ.junie/AGENTS.mdへ置く形が保守しやすいです。

.aiignoreはどこまで厳しくすべきですか？

最初は厳しめにします。secret、customer data、generated files、large fixtures、vendor/cacheを外し、必要になった時だけ例外を検討します。AI agentに読ませる情報は少ないほど安全ですが、少なすぎると文脈不足にもなります。taskごとに見直します。

Semantic Indexingは有効にすべきですか？

大規模projectやlegacy projectでは有効な場面があります。ただし、Project pathと.aiignoreを整えてから判断します。扱う情報が整理されていない状態で有効化するより、読ませる範囲を先に決めた方が安全です。

Never ask meを標準にしてよいですか？

初期標準にはしない方がよいです。docs更新や小さなtest追加など低risk taskなら使えますが、auth、billing、migration、public API変更では質問を残します。

WSLで使えますか？

JetBrains AI Assistant docsでは、Junieは現在WSLでは動作しないと説明されています。利用環境がWindows + WSL中心のチームでは、導入前に最新docsと実機で対応状況を確認してください。

---

次に読むなら

参照した主な情報源

• https://www.jetbrains.com/help/ai-assistant/junie-agent.html
• https://www.jetbrains.com/help/junie/customize-guidelines.html
• https://junie.jetbrains.com/docs/junie-cli.html
• https://junie.jetbrains.com/docs/junie-cli-acp.html
• https://www.jetbrains.com/help/ide-services-cloud/manage-aie.html
• https://junie.jetbrains.com/
• https://blog.jetbrains.com/junie/2025/02/meet-junie-your-coding-agent-by-jetbrains

次に読むなら

更新履歴

1. 2026年6月1日

   JetBrains公式docs、Junie公式docs、IDE Services Cloud docsを確認し、初版を作成しました。

導入時には利用中のJetBrains IDE versionとJunie設定を確認してください。

• 2026年6月1日: JetBrains AI Assistant docs、Junie Guidelines docs、Junie CLI docs、IDE Services Cloud docs、Junie公式サイトを確認し、初版を作成しました。