メインコンテンツまでスキップ

AIネイティブ開発 2026-08-01 アップデート内容

2026-08-01のアップデートにおける変更内容は下記となります。

AIエージェント向けコンテキスト資材の更新​

以下のスキル群を追加しました。

  • 業務プロセス管理(IM-BPM)
    • 業務フロー図(BPMN)をAIエージェントに作成させる等の、IM-BPM機能向けのスキルを追加しました。
  • 試験(テスト)
    • 仕様書から試験観点一覧・試験項目書を自動生成するスキルを追加しました。
  • 環境構築(サンプルデータ)
    • 試用・デモ用のサンプル一式をまとめて自動生成するスキルを追加しました。
  • IM-LogicDesigner のルーティング呼び出しコード生成
    • IM-LogicDesigner ルーティング定義(ロジックフローAPI)をスクリプト開発モデルから呼び出すコードを生成するスキルを追加しました。
スキル何ができるか
bpm-docs-generator業務フロー図から仕様書を作成/社内ナレッジ用形式へ変換
bpm-scripts-generator仕様書から業務プロセス用の画面・処理を生成
bpm-xml-reflector確定した仕様・プログラムの内容を業務フロー図へ反映
test-spec-generator試験観点一覧・試験項目書の作成(Excel/ブラウザ閲覧用)
jssp-sample-setup-generator試用・デモ環境向けサンプルデータ一式の生成
jssp-im-logic-usageIM-LogicDesigner ルーティング呼び出しコードの生成

スキル資材はこちらにて公開しています。

業務プロセス管理(IM-BPM)の開発支援を新規追加​

「誰が・いつ・何を承認するか」といった業務の流れを描いた業務フロー図(BPMN)を起点に、システムを組み立てられるようになりました。

具体的には、以下の3つの支援機能を追加しています。

  • 業務フロー図から仕様書を自動作成 — フロー図に描かれた業務の流れ・分岐条件・作業内容を読み取り、人が読める仕様書に書き出します。作成した仕様書は社内ナレッジ(intra-mart Knowledge)へそのまま登録できる形式にも変換できます。
  • 仕様書からプログラムを自動生成 — 作成された仕様書をもとに、業務プロセスを実際に動かすための画面や処理を生成します。
  • 決定した内容を業務フロー図へ反映 — 仕様書やプログラムで確定した内容を、元の業務フロー図に書き戻します。図と実物の食い違いを防ぎます。

これにより、業務フロー図 → 仕様書 → プログラム → 業務フロー図への反映という一連の流れを、AI の支援を受けながら進められます。あわせて、業務フロー図の記述に誤りがないかを機械的に点検する仕組みも用意し、後工程での手戻りを抑えます。

試験資料(試験観点一覧・試験項目書)の自動作成を追加​

仕様書に書かれた「満たすべき条件」から、試験観点の一覧と、画面ごとの詳細な試験項目書を自動で作成できるようになりました。

  • 既存の試験項目書のレイアウト・書式を踏襲するため、これまでの社内フォーマットのまま利用できます。
  • Excel 形式に加えて、専用ツールが導入されていない環境でも使えるブラウザ閲覧用の HTML 形式も選べます。

これまで手作業で時間を要していた試験資料の作成を、大幅に短縮できます。

サンプルデータ投入資材の自動生成を追加​

試用環境・デモ環境の立ち上げに必要なサンプルデータ一式を、まとめて自動生成できるようになりました。

利用者の権限設定、メニュー、定期実行処理、初期データ、ポータル画面への部品(ポートレット)の登録、ワークフローや業務ロジックの取り込みまでを一括で用意します。3言語(日本語・英語・中国語簡体字)分を同時に生成します。

デモ環境やトライアル環境の準備にかかる手間と、設定漏れによるトラブルを減らせます。

既存の業務ロジックを再利用するコード生成を追加​

すでに IM-LogicDesigner で作成済みのREST API(ルーティング定義) を、新しく作る画面から呼び出すためのコードを自動生成できるようになりました。

呼び出しに必要な入出力の情報をシステムから自動で読み取るため、担当者が仕様を調べ直す必要がありません。既存資産をそのまま活かした開発が進めやすくなります。

品質・安定性​

  • 生成物の自動点検をサブエージェント化 — 画面を生成した後のレビュー・修正作業を、専任のサブエージェントに切り出す方式に変更しました。1回のやり取りで扱う情報量が減るため、規模の大きい開発でも品質が安定します。
  • ワークフロー定義の取り込み漏れを解消 — 承認ルートの分岐条件が複数ある場合に、一部が取り込まれないことがある問題を解消しました。
  • ポータル画面への部品登録を確実に — 権限設定を自動でそろえるようにし、管理画面上に正しく表示されるようにしました。あわせて、名称の文字数超過による取り込み失敗を事前に検知します。
  • 不具合修正 — GitHub Copilot 向けの設定ファイルの記述誤り、および一部の型定義の不足を修正しました。

開発環境関連​

  • IM-BPM 向けの必要ライブラリを自動追加 — IM-BPM を利用する構成を選んだ場合に、必要なライブラリが自動で組み込まれるようにしました。

提供方針の変更​

  • 機密情報の漏洩防止機能について — git を活用している環境において、APIキーなどの誤った公開を防ぐため、hooks の設定を自動で追加する改修を行いました。

@intra-mart/juggling-coreライブラリの公開​

npmレジストリに対し、@intra-mart/juggling-coreを公開しました。 これは、TypeScriptを用いてIM-Jugglingの操作を行うライブラリです。 このライブラリを使用することにより、IM-Jugglingプロジェクトに対してユーザモジュールの追加や、warファイルの生成、パッチの適用などの操作を、画面操作を介さずに自動化することが可能です。

開発支援モジュール (velbench-1.1.0)​

開発支援モジュール(velbench)のバージョン1.1.0をリリースしました。今回のリリースでは、ステージング環境における資材のデプロイやジョブ実行、サンプルデータセットアップなどの機能が追加されました。

7月の変更により、ステージング環境で確認できる範囲が次のように広がりました。

確認対象6月末時点7月末時点
画面の動作○○
提供API(ルーティング)の確認○○
ログの確認○○
テナント環境セットアップの実行○○(複数モジュール対応)
ジョブ(自動処理)の実行×○
サンプルデータの投入×○
複数ファイルの一括デプロイ×○

「共有環境に触れずに、自分の作業スペース内で完結できる作業」の範囲が拡大したことが、今月の中心的な更新内容です。

ジョブ実行機能​

ステージング環境内で、ジョブを画面から実行して結果を確認できるようになりました。

  • ステージング詳細画面「ジョブ」タブ(今回新設)
    • 資材内に定義されているジョブが一覧表示され、そこから選んで実行できます
    • 対応するジョブ種別は Javaジョブとスクリプト(JSSP)ジョブの2種類です
    • 一覧に出てこないジョブも、種別とパスを手動入力して行を追加して実行できます
    • 実行時にジョブに受け渡すパラメータを指定できます。

サンプルデータセットアップ機能​

資材に含まれるサンプルデータのセットアップ定義を、画面から確認して実行できるようになりました。 開発時に利用するサンプルデータを、ステージング環境に持ち込んでセットアップすることが可能です。

※ 実行内容は実テナントのデータベースに反映され、取り消しはできません。この点は実行前の確認ダイアログでも明示的に警告表示されます。

  • ステージング詳細画面「サンプルデータセットアップ」エリア(今回新設)
    • 資材内にあるサンプルデータセットアップ設定の一覧表示
    • 設定ファイルごとの定義内容の確認
    • セクション単位での選択実行
    • 全設定を対象とした一括実行
  • 実行後は「成功 / 失敗 / 合計」の件数と、定義ごとの結果が一覧で表示されます

複数ユーザモジュールのデプロイに対応​

これまで1回のデプロイで扱えるアーカイブファイルは 1件のみでした。今回、複数のアーカイブファイルを1回の操作でまとめてデプロイできるようになりました。 例えば、プロジェクト共有モジュールと、アプリケーションモジュールをまとめてステージング環境へデプロイ、適用することが可能です。

  • Accel CLI コマンドから追加でデプロイするファイルを指定することが可能です。
  • ステージング詳細画面「デプロイメント」タブより複数ファイルのアップロードが可能となりました。
    • 複数ファイルを選択してアップロードすると、同一のデプロイメントとして1つにまとめられます
    • デプロイメント詳細画面で、そのデプロイメントに含まれるファイル名の一覧を確認できます
  • テナント環境セットアップの実行時に、複数モジュールの資材をまとめて適用することが可能です。

不具合修正​

ステージング資材内ライブラリの参照対応​

ステージング環境に持ち込んだ資材にJARライブラリが含まれている場合、スクリプト開発モデル(サーバサイドJavaScript)側からそのライブラリ内のクラスを解決できない制約がありました。 今回、ステージング用のスコープに対してクラス解決の入口をステージング資材向けに再定義する対応を行い、資材内JARのクラスが画面スクリプトから参照可能になりました。

SQLServer環境における一覧表示件数取得の不具合修正​

データベースとしてSQLServerを利用している場合、ステージング資材の一覧表示件数が正しく取得できない不具合を修正しました。

画面補助表示の対象限定​

ステージング環境において、アプリケーション画面を開いている際に注釈を表示する機能があります。 これは自動的に画面に注釈を操作する機能を埋め込んでいましたが、意図しない応答の内容に注釈が付加されてしまうことがありました。 具体的には、HTML以外の応答(例: application/json等)においても注釈が付加されてしまい、受け取り側での解析が失敗することがありました。 今回、HTML応答のみに注釈を付加するよう修正しました。

  • 応答種別が未設定の場合は、HTMLとして扱います(通常の画面は判定時点では未設定であるため、未設定を除外すると本来必要な画面に付加されなくなります)
  • 文字コード指定などの付随情報は無視し、種別部分のみで判定します

ドキュメント​

ドキュメント構成の全面刷新​

ドキュメント全体を、読者が読み進める順序に沿った構成へ刷新しました。 従来はガイド単位で個別に並んでいたため、目的の情報に辿り着くまでに複数のガイドを横断する必要がありました。今回、目的別のカテゴリへ再編し、「何を知りたいか」から辿れるようにしています。

  • 基礎知識:AIネイティブ開発の考え方と、開発を始めるうえで押さえておく前提知識
  • 環境構築:開発者個人の環境と、チームで共有する検証環境の準備
  • チュートリアル:エージェントとの対話で業務画面やワークフローを作り上げる流れ
  • チュートリアル(業務プロセス起点編):業務プロセス図を起点に開発を進める流れ
  • 開発支援モジュール:開発した資材を検証環境へ持ち込み、動作を確認するための機能
  • モジュールリファレンス:成果物の構成と各定義ファイルの仕様
  • DevOpsガイドライン:開発から配布までを自動化する仕組みの構築手順
  • サンプル:そのまま利用できる業務アプリケーションの仕様書一式

あわせて、AIネイティブ開発の考え方を解説する入門的な章と、これまで別の開発ツールで作成してきた既存の資産を新しい開発環境へ引き継ぐ手順を新設しました。

はじめての方は「基礎知識 → 環境構築 → チュートリアル」の順に読み進めることを推奨します。

業務プロセス図を起点とした開発への対応​

業務の流れを描いた図(BPMN)を渡すだけで、その業務を実現するための仕様書と、実際に動作する業務画面までを作り上げられるようになりました。

流れは次の3段階です。

  1. 図に描かれた業務の流れから、必要な画面、担当者の役割、検討が必要な事項を洗い出した仕様書を作成します
  2. 仕様書をもとに、実際に動作する業務画面を作成します
  3. 作成した内容を元の図へ書き戻し、そのまま業務プロセスとして動かせる状態にします

これにより、業務部門が描いた業務フローを、そのまま開発の出発点として使えます。従来は、業務フローを人が読み解いて仕様へ落とし込む工程が必要でした。

商談管理業務を題材とした具体的な事例も収録しています。

なお、生成される仕様書はあくまで提案です。内容を確認し、要望と異なる点は加筆・訂正してご利用ください。

開発から配布までの自動化(DevOps)の手順を提供​

作成した資材の検査・組み立て・配布を自動で行う仕組みの構築手順を追加しました。

変更を登録するたびに検査と組み立てが自動で走るため、問題があればその時点で気付けます。また、動作確認を終えた最新の資材が常に同じ場所から取得できるようになり、「どれが最新か分からない」「手元では動いたのに他の環境では動かない」といった状態を防げます。

広く使われている2つの基盤(GitHub Actions、GitLab + Jenkins)それぞれの手順を用意しました。すでにいずれかを利用している組織は、そのまま適用できます。

あわせて、対応してほしい課題を登録するだけで、エージェントが原因を調査し、修正案の提出まで自動で行う運用例も紹介しています。1件あたりの費用に上限を設ける方法など、安全に運用するための勘所も含めています。

※ これらの手順は、あくまで一例です。組織の運用方針に合わせて、必要な部分だけを取り入れることも可能です。 ※ 本ドキュメントは継続したアップデートを行う予定です。

@intra-mart/juggling-coreライブラリの活用ドキュメントの追加​

@intra-mart/juggling-coreライブラリの紹介およびサンプルコードを含めた説明をドキュメントに追加しました。

その他​

  • 開発に必要な前提ソフトウェアの推奨バージョンを更新しました。
  • 検証環境の構築について、コンテナ技術(Docker)の利用は必須ではない旨を明記しました。あわせて、利用する場合の利点(構築の手間の削減、チーム内での環境共有、上記の自動化への展開)を整理しています。
  • サンプルとして提供している業務アプリケーションの仕様書一式(休暇申請・物品購入)を更新しました。

Accel CLI​

update コマンドの追加​

配布済みの資材を最新化するコマンドを追加しました。「配布時点の内容」「開発者の手元の現在の内容」「最新の内容」の3つを突き合わせて、ファイルごとに扱いを判定します。

対話式の update は毎回およそ12項目の設問すべてに答える必要がありました。実行直後に 「既存の設定のまま更新しますか」 を確認し、既定の「はい」を選べば全設問を省略できるようにしました。適用前の内容確認は引き続き表示されます。

状況動作
開発者が手を加えていない最新の内容で上書き
開発者が編集しており、最新側に変更がない手元の内容を維持
両方が同じ箇所を変更している双方の内容を併記し、開発者に判断を委ねる

補足事項:

  • init と同じ設定項目を指定できます。省略した項目は現在の設定が維持されます。
  • 対話モードでは、現在の設定値が初期値として提示されるため、更新と同時に構成変更もできます。
  • 開発者による編集の有無は、配布時に記録したファイルのハッシュ値で判定します。
  • 設定変更(利用モジュールの追加など)に伴う内容変化も、更新として反映されます。
  • 判断待ちの箇所が残った場合も、処理自体は異常終了として扱いません(作業を止めないための設計)。
  • 資材の取得元(配布元の場所・枝・時点)をプロジェクト設定に記録するようになりました。

外部コマンド(git)への依存を撤廃​

従来は利用者の環境にバージョン管理ソフト(Git)2.25 以上が必須でした。必要な通信処理をツール内部に実装し、この前提条件を撤廃しました。取得するデータの範囲(必要なファイルのみ)は従来と同等で、配布元の規模が拡大しても取得コストが増えない特性も維持しています。

  • 社内プロキシ環境(各種プロキシ設定の環境変数)に対応しました。
    • 環境変数 http_proxy / https_proxy / no_proxy を参照します。大文字小文字の違いは区別しません。
  • 内容の突き合わせ処理も内部実装に置き換えました。表示形式は従来と同一です。
  • プロジェクト作成時のバージョン管理初期化のみ、引き続き外部の Git を使用します。未導入の環境では警告を表示して処理を続けます。
  • 受信データ量の上限設定と、配布元から受け取る情報の妥当性検査を追加しました。想定外のデータによる異常動作を防ぐためです。

性能改善​

スキル資材のダウンロード方法を改善し、取得時間を従来の約1/3に短縮しました。大規模な資材でも、ダウンロードにかかる時間が大幅に減ります。

iAP へのデプロイの改善​

複数成果物の同時デプロイ​

共通部品を本体とは別に管理している開発体制に対応するため、--additional-file で追加の成果物を同時デプロイできるようにしました。

  • 繰り返し指定が可能です。指定されたファイルは、存在の有無・形式・重複(本体との重複を含む)を検証し、問題があれば処理を中止します。
  • 既定の配信順序は「追加ファイル(指定順)→ 本体を最後」 です。パスが重複した場合に本体の内容が優先されます。
  • 対話モードでは順序を提示し、変更したい場合に選び直せます。自動実行では常に既定順序が使われます。
  • ファイル一覧はプロジェクト基準の相対パスで表示するようにし、確認しやすくしました。
  • 従来、特定の形式のファイルで拡張子が二重に付与される不具合があり、あわせて修正しました。

デプロイ後のセットアップ​

デプロイ後、テナント環境の設定に続いてサンプルデータの投入をその場で提案するようにしました。一覧提示 → 確認 → 全件または選択 → 結果表示という同一の流れです。テナント環境設定を実行したかどうか、成功したかどうかに関わらず提案されます。

  • 前段の処理に致命的な失敗があった場合は警告として示し、残りのモジュールの処理は継続します。1件の失敗で全体が止まることを避ける方針です。
  • --tenant-setup / --sample-setup を指定すると、確認を挟まず一括実行します(対話・自動実行の双方で有効)。
  • 指定した処理が失敗した場合は異常終了しますが、「配信自体は成功している」ことを明示します。原因の切り分けを誤らせないためです。対象の設定が存在しない場合は警告のみで、正常終了として扱います。

接続情報の誤登録を防ぐ検査を自動配置​

accel login コマンドを実行した際、認証用のキーが AI 開発支援ツール向けの設定ファイルに書き込まれます。これを誤って共有リポジトリに登録すると外部流出につながるため、接続情報の保存と同時に、登録前の自動検査を組み込む変更を加えました。

既存環境への配慮:

  • 検査の仕組みは、ツールが管理していることを示すマーカーを付けて配置します。マーカーのないファイル(開発者自身が用意したもの)は上書きしません。
  • 自動有効化は、他の仕組みが未設定かつ管理外のファイルが存在しない場合に限ります。それ以外は警告を表示し、手動設定を案内します。既に導入済みの他社製の仕組みを黙って無効化しないための判断です。
  • プロジェクト設定で機能を無効化できます。

資材側から利用者へのメッセージ表示​

配布する資材の側で、条件に応じた利用者向けメッセージを定義できるようにしました。「お知らせ」と「注意」の2段階があり、構成に応じた表示条件を指定できます。

  • 既存の処理の中で収集するため、処理時間への影響はありません。同一内容は重複表示されません。
  • 「この構成ではこの資材は提供されません」といった不在の通知も表示できます。
  • ファイル配置の完了後、依存インストールの前に表示されます。更新時は、変更対象がなかった場合でも表示されます。
  • 定義に誤りがある場合は、処理を止めずにその項目のみ読み飛ばします。

2026-07-01 リリース資材からのアップデート方法​

accel update コマンドが利用できる場合は、プロジェクトのルートで accel update を実行します。利用できない場合は accel detach → accel attach で資材を入れ替えてください。