以下は、2026 年の IRIS リリースカレンダーの更新情報と、2027 年に予定されている変更点の概要です。2026 年における主なポイントは、メンテナンスリリースのバージョン番号付けが、これまでの年とは若干異なる点です。

2026 年：IRIS 2026.1 メンテナンスリリースのバージョン番号

• 2026 年   7 月：IRIS 2026.1の最初のメンテナンスリリース（予定バージョン：2026.1.4）
• 2026 年 10 月：次回のメンテナンスリリース（予定バージョン：2026.1.5）
• 2027 年   2 月：次のメンテナンスリリース（予定バージョン：2026.1.6）

このバージョン番号付けの変更は、2027年に予定されているメンテナンス頻度の拡大に備えたものです。

2027 年：メンテナンスリリースの頻度拡大

2027 年よりお客様が IRIS の新バージョンをより迅速に導入できるよう、メンテナンスリリースの頻度を高める予定です。

2027 年のメンテナンスリリースに関する詳細は、来年発表される予定です。

EM および CD のリリースに関する詳細については リリースストリームのドキュメント をご覧ください。

InterSystems IRIS® データプラットフォーム、 InterSystems IRIS® for Health および HealthShare® Health Connect™ のメンテナンスバージョン 2025.1.4 および 2024.1.6 がリリースされました。今回のリリースでは、最近お知らせした以下の警告や勧告の修正が含まれています。 

• 医療情報相互運用性問題に伴う InterSystems IRIS for Health, InterSystems Health Connect 2024.1.4 および 2024.1.5 キット削除
• 警告：システムワークキューのジャーナリングが無効になる可能性
• 警告：2TB以上のデータベースキャッシュを使用時システムがハングする

より良い製品を皆様と共に作り上げていくため、 アイデアポータル 内の リリース後のフィードバック カテゴリからご意見をお寄せください。

ドキュメント

詳細な変更リストとアップグレードチェックリストはこちらのドキュメントをご参照ください(すべて英語 2025.

• InterSystems IRIS for Health および Health Connect の対象バージョンにおいて、FHIRおよび医療情報相互運用性機能に関連するいくつかの問題が確認されました。そのため、該当バージョンは WRC 配布サイトから削除しました。同バージョンの InterSystems IRIS には影響しません。該当する InterSystems IRIS for Health および Health Connect をお使いの場合は、製品の使用状況に関わらず、以下の手順をご参照ください。
• 安定性の懸念により、アップグレードの重大な失敗や、予期せぬ および 望ましくない製品の動作を引き起こす可能性があります。安定性に関する懸念事項の詳細については、カスタマサポートセンターまでお問い合わせください。
  

概要

発生する問題

HL7 から SDA3 への変換ロジックにおいて、特定の薬剤関連 HL7 メッセージを 処理する際に無限ループを引き起こす可能性のある問題が確認されました。 この問題は、メッセージに含まれる TQ1 セグメントの「TQ1-3 Repeat Pattern」 フィールドに複数の繰り返し設定が含まれている場合に発生します。

影響

この条件が満たされる場合、該当する HL7 メッセージは SDA への変換に失敗す る可能性があります。

Claude CodeはIRISのことかなり理解してくれていますが、それでもやはり想定外が発生します。

まず１つ目は既に何回か発生した問題で、正しく指示しないと今後もよく発生する可能性の高い問題です。

IRISの文字型のデータ（%String）のコレーション（照合）は、デフォルトではSQLUPPERとなっていて、その結果としてデータをSQLで取得すると大文字に変換されて返ってくる場合があります。（GROUP BYなどのソートして集計する場合）

それを意識せずに（通常誰も意識していないと思いますが）、Claude Codeにそのデータの値に依存するような指示を与えると、期待した結果が得られないことが起こります。

例えば、何々のカラムの値がGroup BYで指定したカラムで集計した場合、返ってくるそのカラムの値が大文字となるため実際のデータはSupportだけれども実際に返ってくる値がSUPPORTとなっているためにマッチしないという感じです。

Claude Codeのスキルにこれをちゃんと記載するか、クラス定義のCOLLATEをSQLSTRINGに変更することでこの状況を回避できると思います。

もう一つ最近遭遇した問題は、これはさすがに難しいだろうという感じのものです。

IRISにはご存知の方も多いと思いますが、計算フィールドという非常に便利な機能があります。

データベースを確認したところ、巨大な^rINDEXSQLグローバルが存在しているようですが、これはなぜでしょうか？ 😬

管理ポータルのSQLページにおいて、「SQLステートメント」の下に「古いデータをクリーンアップ」ボタンがおりますが、これはどのような機能でしょうか？ 🤔

ステートメントのリストにおいて、一部のステートメントには「Location」値が設定されていますが、他のステートメントには設定されていないようです。これはどうしてでしょう？ 🤨

そうですね、確かにこれらはすべて関連しています。

一般的に、実行されたSQLクエリに関する基本的な統計情報 は保持しております。 キャッシュされたSQLクエリを削除する際、ステートメントリスト内のステートメントエントリ自体は削除せず、統計情報は保持いたします（将来の比較に役立つ可能性があるためです）。ただし、ロケーション列は「クリア」します（既存のキャッシュ済みクエリを指さなくなるためです）。 これらの「古い」ステートメント（もはやどこも指していないもの）をクリーンアップしたい場合は、「古いステートメントをクリーンアップ」ボタンを押することができます。

以下のような表示になります（システムエクスプローラー -> SQL -> SQLステートメント）：

[注記：旧バージョン（例：v2020.

Claude Codeを使うようになってから、創作意欲が爆上がりです。

今までは、何かを作りたいと思っても実際にコーディングをするのが面倒なので、よっぽどのニーズがないとプログラミングまでは至らなかったのですが、仕様をちょこちょこっと書くと後はClaude Codeが勝手にやってくれるので、生産性が雲泥の差です。

私はObjectScriptネイティブ世代なので、これからはPythonと言われても少し躊躇する部分がありましたが、逆にClaude CodeはPythonが大得意なので、新規に開発する際に、ObjectScriptを選ぶ理由がほとんどなくなりました。

とはいえ、Claude CodeがEmbedded Pythonのくせをどの程度理解しているか少し懸念があったのですが、それはかなり取り越し苦労だとわかってきました。

IRISのドキュメントに書かれていることは大体ちゃんと理解してくれています。

そして、自分でPythonコードを書いたら決して書けないような簡潔で洗練されたコードを書いてくれます。

今まであったらいいなと思いつつ、面倒なので、ほとんどやっていない処理としてテーブルのインポート・エクスポートがあります。

FHIR検索を、あらかじめ定義されたリソースの「リスト」ごとに制限することは、場合によってはより便利で、より効率的であり、より安全です。

バージョン2025.1より、当社のFHIRサーバーでは複数のリスト関連機能をサポートしております。

こちらでそれらを重点的にご説明し、いくつかの サンプルをご提供いたします。

一般的には、公式のFHIRドキュメントよりリストリソースの詳細について利用できます。

しかしながら、上記に基づいた簡単な 説明を以下に示します：

FHIRのリスト リストリソースは、フラット（オプションとしてオーダー付き）レコードの集合体を表し、臨床リスト（例：アレルギー、薬剤、アラート、病歴）やワークフロー管理（例：患者追跡、教育ケース）に使用されます。 リストは均質（単一のリソースタイプ）または 不均質（混合タイプ、例：状態、アレルギー・不耐性、処置にまたがる問題リスト）である場合があります。 リストは、単純なクエリでは取得できないキュレート・抽出されたデータセットが必要な場合に使用します（例：現在のアレルギーと全記録アレルギーの比較）。 リストをクエリすると、ポイント イン タイム スナップショットが得られます。 一方、リソースエンドポイントをクエリすると、通常はより広範でキュレートされていない「現時点での」データセットが返されます。

最新バージョン（2025.

インターシステムズは、InterSystems IRIS^® data platform、InterSystems IRIS^® for Health^TM、HealthShare^® Health Connect のメンテナンスバージョン 2023.1.7 をリリースしました。

 より良い製品を共に作り上げるため、アイデアポータル  の「Post-Release Feedback」カテゴリでご意見をお寄せください。

ドキュメント

変更点の詳細と、アップグレードチェックリストは以下のリンクからご覧いただけます。(すべて英語)

• InterSystems IRIS
• InterSystems IRIS for Health
• HealthShare Health Connect

早期アクセスプログラム(EAPs)について

現在、多くの早期アクセスプログラムをご提供しております。 こちらの ページ からご興味のあるプログラムにお申込みいただけます。

キットの入手方法

InterSystems IRIS と InterSystems IRIS for Health の通常インストーラパッケージ形式のキットは WRC Direct の IRIS ダウンロードページから、HealthShare Health Connect のキットは HealthShare ダウンロードページ からそれぞれ入手してください。

インターシステムズは、InterSystems IRIS data platform、InterSystems IRIS for Health および HealthShare Health Connect のバージョン 2026.1 をリリースをしました。2026.1 は、拡張メンテナンス（EM）リリースです。

リリースハイライト

1. データベース・スケーラビリティの強化

   データベースの容量制限が撤廃されました。これにより、従来の容量制限をこえてもデータ移行が必要なく、円滑にシステム拡張できるようになりました。また低レベルパフォーマンスも改善され、大規模運用がさらに最適化されています。

2. テーブル・パーティショニング

   ユーザー定義の論理キーに基づきテーブルと関連インデックスデータを分割し、データベース間で簡単にマッピングできるようになりました。これによりストレージの階層化が可能となり、大容量テーブルにおけるクエリパフォーマンスと運用効率が向上しました。この機能は早期アクセス・プログラムで提供されている実験的な機能です。早期アクセス・プログラムに参加いただくと、機能のアップデートを受け取ったり、フィードバックを送信することが可能となります。

相互運用プロダクションでは、HTTPクライアントとして動作するビジネスオペレーションを常に設定することが可能です。このオペレーションはOAuth 2.0による認証を利用しますが、この認証方式に対応するためにはオペレーションのカスタマイズが必要でした。 最近リリースされた v2024.3以降では、 この処理をより容易に行うための新機能が追加され、新たな設定オプションが提供されています。

HTTPアウトバウンドアダプターをご利用のビジネスオペレーションにおいて、OAuthグループの下に新しい設定項目が追加されております。

例えば：

• アクセストークンの配置 (ヘッダー | 本文 | クエリ)
• グラントタイプ (パスワード | JWT認証 | クライアント認証情報)

新しいOAuth関連の 設定に関するドキュメントはこちらでご覧いただけます。 

関連するオペレーションのスクリーンショットの例を以下に示します：

カスタムロジック内でのグローバルのSetおよびKillがジャーナルに記録されない問題を修正しました。修正対象となったカスタムロジックは、%CSP.SessionEvents のサブクラスを介して実装された CSP セッションイベント用に実行されるカスタムロジックです。

この問題は、カスタムロジックがミラーリングされたデータベースに対して行ったSetおよびKillでは発生しません。この条件下では、操作は通常どおりジャーナリングされます。

根本原因は、当該ロジックを実行するデーモンプロセスがプロセスごとのジャーナリング状態を、起動元プロセスから受け継いでいることにあります。

監査はサーバーのセキュリティを確保する上で極めて重要な機能であり、かなり 以前から、サーバーで実行されるSQL文を監査する機能を提供しております。

v2024.3 が既にリリースされておりますが、監査すべきこれらイベントを定義するためのより詳細なオプションを提供しております。

従来は、アクセスメカニズムに準じてSQL文の監査を決定することができました。例えば、JDBC/ODBCからの文の実行と、埋め込みSQL (例えば： コード内で&&sqlを使用する場合など) と、ダイナミックSQL(例えば：コード内で%SQL.Statement%SQL.Statementを使用する場合や、Mgmt. ポータルのSQLクエリ実行、あるいはターミナルのSQLシェルからの実行など）、そして今回、これに 加えて、 特定の種類のステートメントのみを監査対象とすることも可能です（アクセス制御機構に基づき、従来と同様に）。対象となる種類は以下の通りです：

• DDL （データ定義言語） - 

データベースの要素や設定、その他のデータ以外のものを変更する文です。例：CREATE / ALTER TABLE

• DML (データ操作言語) - 

データを変更する文です。

最近あるお客様にIRIS for Healthをご紹介する機会があり、技術者の方向けのデモを交えた説明をするためにIRIS for Healthのデモ環境の準備をしました。

元ネタは @Mihoko Iijima がポストした以下の投稿です。

FHIR R4 リソースリポジトリを簡単にお試しいただける開発環境テンプレートのご紹介

非常にわかりやすい動画での説明もあるのでご覧ください。

これから試す方向けに、新しいバージョン（2025.3）でお試しいただけるよう若干の修正をしましたので、紹介します。

https://github.com/TomoOkuyama/iris4h-demo

主な修正点は以下です。

• IRIS for Health 2025.3 に対応 — ベースイメージを最新バージョンに更新
• JsonAdvSQL ストレージ戦略を採用 — 2024.1 で導入された新しい FHIR サーバーのデフォルトストレージ戦略です。従来の JSON ストレージ戦略と比べ、FHIR REST API の検索性能・標準準拠性・スケーラビリティが大幅に向上しています。
• 電子カルテ UI を今風にアップデート — FHIR API だけで動作する患者サマリ画面に刷新しました。

メッセージを 簡単に再送信する機能は、相互運用性における当社の強力な特徴の一つであります。

v2024.3 がまもなくリリースされます（（開発者プレビュー版は既に利用可能です）  既に 公開済みです。これにより、さらに簡単になりました！

Visual Trace 内から、メッセージヘッダーの横に「再送信」ボタンを見つけられます。こちらをクリックすると、通常の「メッセージ再送信エディター」が表示されます（メッセージビューアーを経由して特定のメッセージを 検索する必要はありません）。

以下に、その例を示します：

関連するリリースノートもご覧ください。

[概要]

[発生する問題]

上記で指定されたバージョンでは、データベースキャッシュが 2,097,152MB(2TB) 以上の場合、インスタンスの起動が失敗したり、稼働中にシステムがハングする可能性があります。キャッシュ値を手動で設定していないインスタンスの初期データベースキャッシュは、システム物理メモリの 25% になるため、物理メモリが 8TB 以上ある場合は、キャッシュ未設定のインスタンスでは本障害が発生する可能性があります。詳細については、以下のドキュメントをご参照ください。

InterSystems IRIS for Health v2024.3 は、すでにしばらく前より 開発者向けプレビュー版として 提供されており、今回導入された FHIR 検索に関連する新しいサポートについてご紹介いたします。

以下の2つの修飾子 のサポートが追加されました：-

• not
• missing

これにより、 より柔軟で洗練された、より豊富な検索クエリが可能になります。

また、検索結果のパラメータ -

• _maxresults

を使用すると、よりコンパクトな（そしておそらくより効率的な）結果を得ることができます。

関連するリリースノートもご覧ください。

今回は、プログラミングというほどのこともないですが

IRISのフロントエンド開発ツールとしてReactを利用しています。

Reactに限らずWeb開発のフレームワークを利用する場合のポイントとしてCSSフレームワークをどうするかというのがあります。

今までは、定番というか一番とっつきやすいBootStrapを使用してきました。

利用が簡単な分、カスタマイズの幅が少ないかなということを感じていました。

とはいえ、他のCSSフレームワークを使うにしても、それをまた学習して、１から書き直すのも大変だなということでそのままにしてきました。

今回、Claude Codeという最強のツールを得たことで、BootStrapをMaterializeに変更するように依頼してみました。

結果は、一発で修正完了

実行確認まで5分もかからないスピード感で終了しました。

もし自分でMaterializeを自習して、実装した場合は、少なくとも２、3日はかかったのではないかと思います。

BootStrapの画面

Materializeの画面

すっかりClaude Codeにはまってきてしまいました。

前回はIRISデベロッパーらしくObjectScriptプログラミングの話ですが、今回は、Pythonプログラミングです。

私は、個人会社を持っていまして、経理の細かいことは、当然税理士さんにお任せなのですが、とはいえ日々の経費の管理は自分でやる必要があります。

基本はエクセルに経費情報を入力するというオペレーションなのですが、入力を省力化するためにIRISデータベースを使用したPythonプログラムを作っていました。

その中で本当はやりたいのだけれども、非常に煩雑で面倒臭い処理(決して難しい処理ではないですが)を先延ばしにしてきました。

そこでこれはClaude Codeの格好の題材だと思い、依頼してみることにしました。

結果は、三回のやり取り（実際には、二回目の依頼の際に間違えて送信ボタンを押したので、実質的に二回）で10分もかからずに修正が終わり、期待した通りの結果を得ることができました。

もし自分でコーディングをした場合、おそらく半日仕事、下手をすれば1日仕事だったかもしれません。

この経験を通して感じたのは、既存プログラムの修正には非常に使えるということです。

多少依頼内容に曖昧な点があっても、既存のコードを非常に高速かつ完全、網羅的に理解してくれるので、そういう曖昧性をある意味埋めてくれます。

最近話題のClaude Codeを使って、ObjectScriptプログラミングをトライしてみました。

もちろんClaude CodeにObjectScriptのコードを書かせるにはそれなりの指示が必要ですが、適切なプロンプトを与えると想像以上にちゃんとしたObjectScriptコードを書いてくれます。

今回試したのは、少し前に投稿したCSPの#server問題に対応するため、#serverをREST APIに書き換えるというものです。

元のソースは、

https://github.com/wolfman0719/shopdemo

これはCSPのデモアプリケーションですが、しっかりと#server機能を使用しています。

結論をいうと、%sessionがRESTとCSP間で共有できないという根本問題があって、実行成功までには至っていませんが面倒なコーディングをかなりカーバーしてくれることがわかります。

(REST APIをCSPクラスで実装することで%session共有の問題を回避でき、Claude Codeが生成したロジックの正しさは証明されました)

そして、Claude Codeは、 ObjectScriptのことかなり理解してくれています。

ObjectScriptプログラマーが少ない問題を大きく改善してくれる可能性があります。
 

それでは、私がどのようなことを行ったか説明します。

はじめに

あるお客さんから、ワークフローの待受画面での新着通知方法についてご相談がありました。

• 単純なポーリングだと、通知の遅延や、サーバリソースを消費する
• ロングポーリングは、待ち受け画面のためにIRISのライセンスを消費する
• MQTTなどを使うと専用のサーバプロセスが必要

何か良い方法は無いでしょうか。 といった内容です。

この課題に対して調査したところ、以下の方式が見つかりました。

• ブラウザからSSE(Server-Sent Event)方式を使い、nginx上にアクセス
• IRIS側から通知が必要なクライアントのIDに対してnginxにメッセージをPOST
• nginxがルーティングを行い、当該クライアントにメッセージを通知

今回は以下の点について手順や設定等解説していきたいと思います。

• nginx のソースビルドと Web Gateway のインストール
• nginx-push-stream-module を使った SSE (Server-Sent Events) 通知
• ブラウザ受信 (/subscribe) とサーバ送信 (/publish) の最小実装

全体構成

まずは全体像です。データの流れをシンプルに分けることで、役割が明確になります。