Running AI Agents Safely with IntelliJ IDEA & Dev Containers

Introduction

本記事は、AI エージェント機能で進化した JetBrains の開発体験をシェアしよう by JetBrains Advent Calendar 2025 Series 1の24日目の記事です. IntelliJ IDEAとDev Containerを使い、AI Agentを安全な実行環境で実行させ、開発体験を向上させる一例の紹介です.

Pain Points of AI Agents in Local Development

多くのAI Agentツールがコーディングを含む開発において実行・利用されていますが、開発者のペインとして、Agentをどこまで信頼するか、どのように実行させるかが悩みの一つとなっていると感じています.

下記のHacker Newsでの話題ように, AI Agentが HOME(~) ディレクトリを消したような事例があります.

また、ディレクトリが消されてしまうのみならず、AWSやGCPなどのパブリッククラウドのcredential、環境変数にある秘匿情報、自分や他人の個人情報の漏洩の可能性もあります. PC内の情報に対してアクセス可能な状態である以上、Agentがアクセスし、機密情報が漏洩してしまい、セキュリティインシデントが発生する可能性も往々にしてあると思います.
また、悪意のある攻撃者がプロンプトインジェクションにより上記のような挙動を誘発するようにして成功した場合、被攻撃者がOSSをpublishしているようなケースでは、昨今話題のnpm package の Supply Chain 攻撃などが生じたり(ref: GitLabがnpmサプライチェーンへの大規模攻撃を発見)、企業システムへの認証などを盗まれた場合、ランサムウェア感染したりなど重大な影響を受けます.

Principles for Secure Development with AI Agents

AI Agentの振る舞いをコントロールするためにAGENTS.mdをメンテナンスしたり、各Agentのconfigurationにあるcommandのallow list/deny listをメンテナンスすることが多いと思います. Toolによっては、Agentが走査するしたり、逆にignoreするファイルをパターン指定できたりも可能です.

JetBrainsが提供するJunieは、基本的に多くの設定をIntelliJのIDE上で行うことができます.

このようなConfigurationを適切に設定することで、期待通りのagentの挙動になることは周知の事実ではあると思いますが、完璧に防げているかというと少し疑問符がつくと思います.
allowlistやdenylistで意図していないコマンドを使用され迂回されてしまったり、そもそもアクセスできる可能性のある環境下にあることでは完全に防げているとは言い難いです.

そこで、よりSecureな開発環境にするにはSandbox環境が有効であると考えています.
つまり、Agentが実行することをコントロールという方針ではなく、Agentが何を実行しても影響がない環境で実行するという方針です.

今回は、Dev Containersを利用したセキュアなAI Agent環境の提案とIntelliJ IDEAおよびそのPlugin Ecosystemを活用することで開発者体験がどのように向上するかをハンズオン的に紹介したいと思います.

What Is Dev Container?

DevContainerは、Microsoftが主導で始めたもので、開発環境としてのコンテナとして提唱しているものです.

As containerizing production workloads becomes commonplace, more developers are using containers for scenarios beyond deployment, including continuous integration, test automation, and even full-featured coding environments.
ref: https://containers.dev/overview#overview

Introducing DevContainer in IntelliJ IDEA

IntelliJ IDEA Ultimateでは、JetBrainsが公式で提供しているDev Containers Pluginが利用できます.

非常にシンプルな例を示しますが、下記のようなDockerfileを用意します.

.devcontainer/Dockerfile

FROM mcr.microsoft.com/devcontainers/base:debian

RUN sudo apt update -y && sudo apt install -y curl

RUN sudo install -dm 755 /etc/apt/keyrings
RUN curl -fSs https://mise.jdx.dev/gpg-key.pub | sudo tee /etc/apt/keyrings/mise-archive-keyring.pub 1> /dev/null
RUN echo "deb [signed-by=/etc/apt/keyrings/mise-archive-keyring.pub arch=arm64] https://mise.jdx.dev/deb stable main" | sudo tee /etc/apt/sources.list.d/mise.list
RUN sudo apt update -y
RUN sudo apt install -y mise

このDockerfileはシンプルにdebianをbase imageとして, Language/RuntimeなどのVersion Managerであるmiseをpre-installする環境を構成するDockerfileです.

ちなみに、OpenAIが提供しているCodex(Cloud)も、miseがpre-installされた、base imageがubuntuのcontainer環境になっていることがEnvironmentのConfigurationからわかります.

このDockerfileをbaseとしてdevcontainerのを下記のようにconfigurationします.

.devcontainer/devcontainer.json

{
	"name": "mise",
    "dockerFile": "Dockerfile",
    "postCreateCommand": "bash -c 'bash .devcontainer/postCreateCommand.sh'",
    "customizations" : {
      "jetbrains" : {
        "backend" : "IntelliJ"
      }
    },
}

Dockerfileでなくともimageの指定でも問題ありません.
今回の場合はmiseをpre installされたimageを利用するため上記のDockerfileを導入しています. Custom imageをbuildして任意のcontainer registryにpushして利用することも可能です.

IntelliJ IDEAではDev Containers Pluginがinstallされている場合、
Tools > Services > Dev Containers > New ...でDevContainerのtemplate fileを生成することができます。¹

DevContainerを起動するのは、IntelliJ IDEA上のContainerアイコンを押して、Create Dev Container and Clone Sources...を押すことで、devcontainer.json で定義した構成でコンテナが起動します.

上記の数Stepで、Sandbox環境が出来上がりました。

あとは、コンテナに任意のAgent Toolを導入して利用します.
HostでAI Agentを利用していた時に気にしていたような、commandのpermission listについて気にすることなく、実行することが可能です.

Running the IntelliJ Backend Inside the Container

ここで、先ほどのdevcontainer.jsonを振り返ってみましょう、customizationの項目に

devcontainer.json

...
  "jetbrains" : {
    "backend" : "IntelliJ"
  }
...

を記載しています。これは、JetBrains独自の拡張フィールドでIDE Backendをコンテナ内で実行するという指定になっています.

この指定をするとcontainer側にremote backendがinstallされ、IDE backendが起動します.
これによって、JetBrainsの別プロダクトであるJetBrains Gatewayを使ってRemoteへ接続し、コンテナ内部の環境下でHostで実行している時と変わらないUXでInteliJ IDEAによる開発が可能です.

また、Junieを利用する場合、Junieをコンテナ内部に閉じ込めつつ利用が可能になるので、公式が非推奨としているBrave Modeで実行することもSandbox環境下に隔離していることにより、ハードルを低くすることが可能です.

Brave ModeはCaudeにおける--dangerously-skip-permissions

But...

DevContainerの導入についてとAI AgentのSandbox化について話しました、しかし現状のcontainerベースのsandboxかではいくつかの懸念もあります.

• Security
  • Volumeのマウントの設定などによりホストの情報が露呈する. Sandboxといえど隔離自体は弱い
• Performance
  • コンテナ由来のオーバーヘッドがあり開発者体験が低下する
• Maintainability
  • imageの更新やcontainer内部の環境の更新など、本来のホストでの開発に比べてメンテナンスする項目が増える

コンテナ環境下では、多くの使い慣れたツールやソフトウェアがインストールされたホスト環境とは異るため、開発体験を維持できない可能性もあります。

(IMO: A More Secure and Lower-Overhead Runtime)

下記は本記事の本筋にはあまり関係ありませんが、Sandbox環境下では、Containerの他にWebAssemblyという技術があります.

WebAssemblyはブラウザ上での動作や、EdgeFunction上での実行で、利用されているシーンを多くみます.

WebAssemblyでは、Wasm Runtimeに対してSystem Interfaceとの仕様を策定しているWASIという標準化プロジェクトがあり、現在Preview2がstableです。Wasmが持つsandbox環境に対して、Networkやos機能, その他Runtimeのバインディングが強化され、よりportabilityが向上し、多くの環境で実行することができるようになります。

AI Agentは、非決定的な動作や外部入力に応じた挙動をします。冒頭でも述べた通り、AI Agentが動作する環境としては、その非決定的な動作でも問題ない・開発者が明示的にアクセスできるリソースをRuntimeレベルのインターフェースでカスタマイズし、capability-basedな環境を実現して、sandbox環境に閉じ込めておくことがより安全に、コンテナよりオーバーヘッドの小さく、AI Agentを実行できるポテンシャルがあると考えています.

また、Jet Brainsが提供するプログラミング言語のKotlinはWebAssemblyへのコンパイルが可能であったり、Jet Brainsが開発主導するAgent FrameworkであるKoogなどもあるため、JetBrains Ecosystemとも親和性が高いとも考えています.

Key takeaways

Fool-proofing AI Agents

Agentを動作させる環境は、Agentがしてはいけないことをcontextでチューニングするのではなく、Agentがしてはいけないことをできない環境構築をすることによって、逐次の人間による確認や安全性の懸念を省くことが可能.

Use Sandboxes

Dev Containerによってチーム開発において統一されたかつ安全な環境の提供が可能。
IntelliJ IDEAでは、IDEAが提供する機能やDev Containers PluginによってDev Containerの管理を直感的に操作でき、コンテナ内部でIDEAをbackendで動作させ、IntelliJ Gatewayをさらに利用することよって、SandboxとIntelliJ IDEAの利便性の相互運用が可能.

1. 今回利用しているIntelliJ IDEAのバージョンは IntelliJ IDEA 2025.3 Build #IU-253.28294.334, built on December 6, 2025 を利用しています. ↩