前置き✋
- VS Code拡張機能のIBM i Project Explorerについて2025年の技術セッションでは2回ほどとりあげておりました
- その際に調べ、自身が理解した内容を整理する記事とさせていただきます
- 今後詳細手順の記事を作成しますが、今回は概要とメリットをメインに記事化しました
IBM i Project Explolerとは
- 公式ドキュメントを読みながら紐解いていきます
Visual Studio Code の拡張機能で、ビルド可能なローカルプロジェクトを使用して IBM i アプリケーションを開発するのをサポート
- すなわち、ローカルPC上のフォルダーにてIBM i のソースをダウンロード・編集をし、さらにはコンパイル指示までローカルフォルダーで完結するということですね
- RDiのi プロジェクトと似ていますね!
プロジェクト・エクスプローラー・ビューアーを活用して、プロジェクトのライブラリー・リスト、変数、オブジェクト・ライブラリー、インクルード・パスなどを管理する。また、ジョブ・ログ・ビューアーも活用すれば、ビルドまたはコンパイル実行後のジョブ・ログの内容を簡単に視覚化できる。
- IBM i の開発で必要な諸々の管理をローカル環境で実現しますよーということで、よりオープン系と同じような開発の流れになりそうです
用語・概念について
- IBM i Project Explorer では、ローカルフォルダーをローカルプロジェクトとして設定し、IFSのフォルダーと紐づけを行います
- これにより、ローカルフォルダーで、ソースの編集、デプロイ (PC→IFSへ) 、ビルド (コンパイル) まで一気通貫で使用することができます

はたして何ができるの?
1. プロジェクト管理
-
iproj.jsonを作成し、IBM i向けプロジェクト設定を定義することができる
| 設定項目 | 説明 |
|---|---|
version |
iproj.json のフォーマットバージョン。 |
description |
プロジェクトの説明文(任意)。 |
repository |
このプロジェクトのホームリポジトリのURL。 |
objlib |
コンパイル済みオブジェクトのターゲットライブラリ。指定しない場合、デフォルトは*CURLIBとなる。例: "KOINULIB"
|
curlib |
プロジェクトの接続におけるLIBL内のCURLIBライブラリ。objlibが指定されていない場合、これ自体がobjlibとしても機能する。 |
preUsrlibl |
IBM i LIBLのユザー部分先頭に追加するライブラリ |
postUsrlibl |
LIBLのユーザー部分末尾に追加するライブラリ |
setIBMiEnvCmd |
このプロジェクトがIBM iに接続するたびに実行されるCLコマンドの一覧(通常はLIBL、ENVVAR、iASPの設定を含む) |
includePath |
コンパイル時に参照するコピーソースやヘッダーのパスを指定。 |
buildCommand |
このプロジェクト全体をビルドするために使用されたPASEコマンドライン。 |
buildObjectCommand |
このプロジェクト内の特定のオブジェクトを構築するために使用されるPASEコマンドライン。 |
compileCommand |
このプロジェクト内の特定のソースファイルをコンパイルするために使用されるPASEコマンドライン。 |
2. ローカルフォルダーとIFS(IBM i)の同期
- ローカルフォルダーとIFSを紐づけて、ソースコードのデプロイ(ローカルフォルダーからIFSへソース転送)を簡単に実行
- デプロイ検知レベルを選択可能:
| オプション名 | 内容 | こんなときにおすすめ |
|---|---|---|
"compare" |
ローカルとIFSのファイル内容を比較して、差分があるものだけをアップロード | 安全重視・確実に最新にしたい |
"changes" |
VS Code上で変更された(保存された)ファイルをアップロード(内容比較しない) | とにかく高速に開発したい |
"workingChanges" |
GitのWorking Treeで変更されたファイルだけアップロード | Gitと併用してる人にぴったり |
"stagedChanges" |
Gitでadd(ステージ)されたファイルだけアップロード | コミット前に限定デプロイしたいときに超便利 |
"all" |
すべてのファイルを強制的にアップロード | 初回デプロイ・全体を上書きしたいときに使う |
3. ビルド(コンパイル)のルール化
- ビルド=コンパイル指示のこと
-
Run Compileで単一ソースをビルドする -
Run Buildでプロジェクト全体を一気にビルドする -
Build Objectで特定オブジェクト(PGM/SRVPGM/MODULE など)をビルドする - IBM i Bobと連携し、
Rules.mkを使ったMakeベースのビルドをサポート- 差分ビルド(インクリメンタルビルド)対応
4. アクション管理
-
.vscode/actions.jsonを生成し、ビルド(コンパイル)コマンドを登録 -
Run Actionでカスタム処理を実行可能
5. Git連携
- ソース変更をGitで管理し、ブランチ作成・コミット・PushまでVS Codeで完結させる
-
workingChangesやstagedChangesオプションでGitとデプロイを連動する
IBM i Project Explolerのメリットを考えてみる(主観)
- 1つ目は「Git利用のしやすさ」があげられると思います
- なぜIBM i がサーバー上だけで開発が完結しているのに、あえてローカル環境を使えるようにするのか?という観点からもGitの利用がスムーズになる恩恵は大きいです
- Gitを利用することで、変更履歴の管理やコードのレビュールールを統一していくことができます
- 2つ目は、「ビルド(コンパイル)をコードとして定義できる」という点です
- .vscode/actions.json に「コンパイルコマンド」を定義することができると上に記しました
- そうです、人によってコンパイルコマンドのパラメーター情報が違うなんてこともこのファイルを共有することでなくなるのです!
- Makefile 的なビルドワークフローも定義が可能です
- GitHubのActionsと組み合わせてCI/CDを加速させることも可能になってきます
- RPG、CLP、SQLRPG など言語混在プロジェクトにも強く、「どのソースをどうコンパイルするか」がコード化されて再現性UPとなると考えられます
- .vscode/actions.json に「コンパイルコマンド」を定義することができると上に記しました
- 3つ目は、1、2のことからも「チーム運用が楽になる」で
- ライブラリーリストやコンパイルコマンド等を共通ルールにした、Projectの設定ファイル
iproj.jsonとGitでセットで運用することで、チーム内の標準化を進めることができます
- ライブラリーリストやコンパイルコマンド等を共通ルールにした、Projectの設定ファイル
- 4つ目は、
Source Orbitと組み合わせて使うこと真価を発揮できるという点です-
Source OrbitはVS Codeの拡張機能としても提供されており、IBM i 開発者向けの依存関係管理ツールです。Git を活用したモダンな開発環境への移行を支援する重要な機能を提供します。※詳細は別途記事化します - この
Source Orbitが提供するMigrate Source機能を使うと、RPGⅢやDDS、DSPF、PRTF等もGit管理対象(最終的にIFSへ配置)することができます - 上記機能はIBM i Project Explolerを使っていることが前提となっています
-
おわりに
- 文章だけだと何が何だか感もあります…ローカル開発の加速させるツールであることは少しでも伝わっていると嬉しいです…
- 次回、実際にやってみた編をアップしたいと思います!