この記事は「ProcessingをPDE以外のIDE（IntelliJ / VS Code / Eclipse 等）で書きたい人」向けです。
「とりあえず動かしたい」人から、「P2D/P3Dを使った本格的な作品を作りたい」人まで、幅広く役立つ内容になっています。

はじめに

Processingは「コードによるスケッチブック」として素晴らしいツール（厳密にはJavaをベースにした開発環境/フレームワーク）ですが、規模が大きくなると標準エディタ（PDE）の機能不足に悩み始めます。「オートコンプリートが弱い」「エラー箇所がわかりにくい」「Git管理しづらい」……。

2026年現在、脱PDEを目指す開発者にはいくつかの選択肢がありますが、「ただ動けばいい」のか「本格的に開発・配布したい」のかによって正解は異なります。

この記事では、あなたのスタイルに合わせて最適な環境を提案します。

あなたはどちらのタイプですか？

Type A: 爆速コーディング派（VS Code推奨）

✅ とにかく手軽に始めたい、設定ファイルとか書きたくない
✅ 普段からWeb開発などでVS Codeに慣れている
✅ GitHub Copilot の恩恵を受けながらサクサク書きたい
✅ setup() draw() だけのシンプルなスケッチが中心

Type B: 堅牢エンジニアリング派（IntelliJ + Gradle推奨）

✅ クラスを分けて本格的なオブジェクト指向設計をしたい
✅ Gitでバージョン管理をしっかり行いたい
✅ 外部ライブラリ（動画、通信、音声など）をコマンド一発で管理したい
✅ PDEのエラー表示では満足できず、強力なデバッガーやリファクタリング機能が欲しい

結論から言うと、Type Aなら公式拡張機能、Type BならMaven/Gradleが最適解です。それぞれの導入方法とメリット・デメリットを徹底解説します。

どれを選べばいい？比較まとめ

手法	難易度	メリット	デメリット
Maven Central	★★☆	公式の安心感、最新版が最速	依存関係（JOGL等）の設定が面倒
JitPack (micycle1)	★★☆	設定が一番楽。1行で完結	非公式ミラー、更新に一時的にラグがある
VSCode 拡張機能	★☆☆	PDEに近い操作感、`.pde` のまま書ける	デバッグ不可、Javaの恩恵は薄め
手動での追加	★★★	自分のPCに入ってる公式IDEと同じ環境	Git管理が煩雑になる、プロジェクトのポータビリティが皆無

具体的な方法について

【Processing4.4.6以降の方法】VSCodeの拡張機能を使う

Processingのコミュニティは2025年8月にVSCode向けの拡張機能をローンチしました。
この拡張機能は「VSCode をフロントエンド（操作画面）として使い、実際のプログラムの解析や実行といった重い処理は、裏側で本家 Processing ソフトウェアに丸投げする」　という仕組みで動いています。

何が嬉しいのか

一番のメリットはその手軽さだと思います。

Processing4.4.6以降がインストールされていること
Visual Studio Codeが使えること

であれば基本的にVSCodeにこれをインストールするだけで使用可能です。
そして、Processingのファイル（.pde）をそのままVSCodeで書くことができることです。
Processingは内部的に構文解析などのプリプロセスを経てからJavaとして実行しています。今回の方法ではプリプロセッサも含めて使えるため、純粋なProcessingのコードを書くことができます。そしてProcessing独自のオートコンプリートも使うことができます。

問題点

VSCodeでProcessingができるのは魅力的ですが、この拡張機能はあくまで 「PDE（標準エディタ）の機能をVSCodeに移植したもの」 に過ぎません。以下の制限により、中〜大規模な開発には向かないケースがあります。

デバッガーが機能しない（最大の弱点）
Java開発の最大の強みは、プログラムを一時停止して変の中身を確認したり、1行ずつ実行したりできる「ステップ実行」や「ブレークポイント」です。
しかし、この公式拡張機能はProcessingを外部プロセスとして実行するため、VSCodeの標準デバッガーと連携できません。
- ✕ できないこと: ブレークポイントでの一時停止、変数ウォッチ、ステップ実行
- 〇できること: println() を使ってコンソールにログを出す（いわゆるプリントデバッグ）
エラーが発生した際、モダンなIDEなら「ここで変数がnullになっている」と即座にわかりますが、この環境ではPDEと同様にコンソールに出力される赤いエラーログを読み解く必要があります。
静的解析やコードジャンプの不完全さ
VSCodeの強力なJava拡張機能とは別の仕組みで動いているため、標準的なJavaプロジェクトに比べて「定義元へのジャンプ」や「型情報のプレビュー」が不安定になることがあります。
プロジェクトのポータビリティ（再現性）が低い
MavenやGradleといったビルドツールを使用しないため、「ライブラリを特定のフォルダに手動で入れる」というProcessing特有の管理方法に縛られます。チーム開発やGitHubでの共有時に、相手の環境でも全く同じように動くことを保証するための「依存関係管理」が自動化されないため、プロジェクトが肥大化すると管理が困難になります。
.pde ファイルという特殊な形式
この拡張機能は .pde ファイルを編集することを前提としています。これは一見便利ですが、純粋な .java ファイルとして記述するわけではないため、Javaのモダンな言語機能（最新のJavaバージョンで導入された構文など）がプリプロセッサ（事前解析機）に弾かれてエラーになる、あるいはVSCode側が正しく解釈できないといった、Processing独自の制約に悩まされる場面があります。

使い方

VSCodeのマーケットでProcessingと検索すると数多くの拡張機能があります。しかし以下公式の拡張機能をインストールするようにしてください。

公式のサイトに次のように書いてある通り他の拡張機能との併用は推奨されません。

Before you begin, make sure to:

Uninstall any previously installed Processing extensions. This extension may conflict with other Processing extensions, leading to unexpected behavior.

インストールが完了すると次のようにアクティビティバーにProcessingのアイコンが表示されます。これをクリックするとデモのプログラムがありますので好きなものをクリックするか自分のスケッチを開いてください。

スケッチを開けたら右上にある実行ボタンを押すとコンパイルを始めます。少し時間がかかりますがProcessingの見慣れた画面が起動します。

VSCodeを用いているので以下のようにGithub Copilotなどを使うこともできます。

どんな人におすすめ？

普段からVSCodeを使っている人

Github Copilotを使っている人

一番手軽に開発を始めたい人

Maven Centralを使う

実は公式の方でProcessingのコアライブラリがMaven Centralにあがっています。
これをGradle/Mavenのファイルに記述するだけで勝手にダウンロードしてきてくれます。
2026年1月4日現在でPre-releaseのProcessing4.5まで既にあがっているので、すぐにGradle/Mavenで使えなくなるということはないんじゃないかなと個人的に思います。

何が嬉しいのか

公式が出しているものなので安心感がある。また、最新のアップデートのものも公開されているのでバグの修正や機能の追加が降りてくるのが早いというのが一番かなと思います。

問題点

org.processing:core は、実は「最小限のコア」しか含んでいません。そのため、JOGL（OpenGLラッパー）やGluegenといったネイティブライブラリを自分で追加しないと、実行時にエラーが発生して動かないことがよくあります。
また、将来 JOGLのバージョンが上がったり、Processingが依存するライブラリが変わったりした際に、自分で追従して build.gradle.ktsやpom.xmlを修正する必要があります。

Mavenをお使いの方へ
Maven Centralのページには以下のようにpom.xmlを自動で生成してくれる機能があります。
依存関係も含めて生成してくれるのでMavenの方はこの方法を使うのが一番良いかもしれません。

Gradleをお使いの方へ
この依存関係の問題を解決するためのGradleテンプレートを作りました。今はまだ開発途中ですがこちらのテンプレートも試してみてください。

Processing 4を他のIDEで書きたいんじゃい！【Gradle + Java 17向けテンプレート】 #gradle - Qiita
noah-devtech/Processing4-Gradle-Template | GitHub

使い方

次にP2D/P3Dなどを使わない場合のミニマムの構成での設定方法を紹介します。バージョンはProcessing4.5.0です。
Mavenでは次のように記述します。

pom.xml

<dependency>
    <groupId>org.processing</groupId>
    <artifactId>core</artifactId>
    <version>4.5.0</version>
</dependency>

Gradle(Kotlin)では次のように追加してください。

build.gradle.kts

repositories {
    mavenCentral()
}

java {
    toolchain {
        // Processing4 is based on Java17
        languageVersion.set(JavaLanguageVersion.of(17))
    }
}
dependencies {
    // Processing Core Library
    implementation("org.processing:core:4.5.0")
}

どんな人におすすめ？

Mavenを使っている人
最新のProcessingを使いたい人

非公式のミラー(JitPack)を使う

公式のコアライブラリの複雑な依存関係を解決してくれている便利な非公式リポジトリもあります。それがmicycle1/processing-core-4です。
これはProcessing 4のソースコード（公式リポジトリ processing/processing4）をサブモジュールとして取り込み、Mavenビルド用の設定ファイル（pom.xml）を追加したものです。それをGitHub上のリポジトリをそのままMavenリポジトリとして扱えるサービス「JitPack」を利用してライブラリとして配信する設計になっています。

何が嬉しいのか

Processingを通常のMaven依存関係として利用しようとすると、グラフィック描画に必要なネイティブライブラリ（JOGLやGluegen）やGUIライブラリ（JavaFX）の依存関係解決が非常に複雑で、エラーになりやすいという問題があります。
このリポジトリの最大のメリットは、pom.xml でこれらの複雑な依存関係（JavaFX, JOGLなど）があらかじめ定義されている点です。これにより、利用者はこのライブラリを1つ追加するだけで、必要なライブラリ一式が自動的に揃い、すぐにコーディングを始めることができます。

問題点

以前はProcessing 4の公式Mavenアーティファクトが存在しないため、このようなミラーリポジトリが必須でした。しかし、2026/1/4時点で、Maven Centralには公式のorg.processing:coreバージョン 4.5.0 が公開されていますがこのミラーリポジトリでは最新のリリースがProcessing 4.4.4 となっています。これによってこのリポジトリを使うと最新機能やバグ修正が含まれていない可能性があります。
また、このミラーリポジトリは公式ではない開発者（micycle1氏）によってメンテナンスされている非公式なものです。公式の変更への追従が遅れたり、メンテナンスが停止したりするリスク があります。

2026/1/12追記
こちらのリポジトリ約7ヶ月ぶりのアップデートによりProcessing4.5.0に対応しました。現在は4.5.0に対応していますが、公式のMaven Centralに比べると更新が遅れるリスクがあるのには変わりありません。
Release 4.5.0 · micycle1/processing-core-4

使い方

使い方は以下の通りです。JitPackを使って配信されているためそれを使う旨を宣言しています。

pom.xml

<repositories>
  <repository>
   <id>jitpack.io</id>
   <url>https://jitpack.io</url>
  </repository>
</repositories>
<dependency>
  <groupId>com.github.micycle1</groupId>
  <artifactId>processing-core-4</artifactId>
  <version>4.5.0</version>
</dependency>

build.gradle.kts

repositories {
    mavenCentral()
    // add JitPack repository
    maven { url = uri("https://jitpack.io") }
}

dependencies {
    implementation("com.github.micycle1:processing-core-4:4.5.0")
}

どんな人におすすめ？

とにかく手っ取り早くMaven/GradleでProcessingを動かしたい

【Processing4.3.4までの方法】`processing-java.exe` を使う

かつて、VS CodeやSublime TextからProcessingを実行する際の「黄金律」だった方法です。Processing IDEに付属しているコマンドライン用ツール processing-java を外部エディタから呼び出す仕組みです。

何が嬉しいのか

Processingのプリプロセッサ（.pde を .java に変換する機能）をそのまま通すため、PDEで書くのと全く同じ文法で、外部エディタから実行できました。
複雑なMaven/Gradleの設定なしに、エディタの「Build System」にパスを通すだけで動かせた手軽さがありました。

問題点

インストーラー版（.msi）への移行: Processing4.0.0以降、Windows版はzip配布からmsiインストーラー形式へ移行しました。これに伴い、以前のようにprocessing-javaの実行ファイルが単純なパス指定で見つからなかったり、実行権限周りの挙動が変わったりして、従来の拡張機能が軒並みエラーを吐くようになりました。
公式拡張機能の登場: 2025年に「公式VSCode拡張機能」が登場したことで、わざわざ自分でprocessing-javaのパスを通す職人芸が必要なくなりました（公式拡張機能が内部でこの役割をより安全に担っています）。
CLIとしての限界: この方法はあくまで「実行」するためのものであり、モダンなIDEが提供する「高度な補完」や「リファクタリング」といった恩恵は、Maven/Gradleを使う方法に比べると圧倒的に限定的です。

使い方

過去の方法であり現在では非推奨であるためこの記事で紹介するのは避けようと思います。
一応おおまかなやり方の流れとしては次のようになると思います。

「Processing Language」という拡張機能を入れる
Processing: Path に自分のPC上の processing-java.exeのパスを通す
ビルドタスクを設定するためにtasks.jsonを作成する

どんな人におすすめ？

どうしても古いバージョン（Processing 3系や 4.3以前）を使わなければならない人
独自のビルドスクリプトを自作して、CLIからスケッチを自動生成・実行したいマニアックな開発者

まとめ

結論：2026年、私たちはどれを選ぶべきか？

初心者〜中級者で、サクッと書きたいなら「公式VSCode拡張機能」。
Javaの力をフルに使い、大規模な作品やツールを作りたいなら「Gradle (Template) または JitPack + IntelliJ IDEA」。

processing-javaを手動でいじる時代は、2025年の公式拡張機能リリースによって、一つの区切りを迎えたと言えるでしょう。

参考文献

processing/processing4: Source code for Processing, the software sketchbook and Java-based programming language for students, artists, designers, educators, hobbyists, and creative coders. Includes the core library, and editor (PDE)

Processing 4を他のIDEで書きたいんじゃい！【Gradle + Java 17向けテンプレート】 #gradle - Qiita
Maven Central関連