IRIS 2025以降、Java、.Net、Pythonなどの外部プログラムを呼び出す共通フレームワークとして$system.externalインタフェースが導入されました。

従来は、言語別にゲートウェイ機能が提供されていましたが、インターフェースが統一され、複数言語やxDBCに対して共通の管理方法でプログラムやプロトコルの呼び出しが可能となりました。

この機能の詳細は、以下のドキュメントをご確認ください。

外部言語の操作

ここでは、.NET SDKに標準で用意されているシステム機能やユーザー作成のDllをIRISから呼び出す方法について説明します。

1. 外部サーバの設定
   管理ポータル>システム>構成>外部言語サーバメニューから%DotNet Serverを選択し、クリックします。
    

   
   管理ポータル>システム>構成>外部言語サーバ>外部言語サーバを編集で以下のように.NET用の設定を行います。
   必要な情報を入力した後、保存ボタンを押します。
   前の画面に戻って、%DotNet ServerのStartをクリックします。

   しばらくして以下のようなログが出力されれば、利用可能です。
    

     2. .NET機能を呼び出すサンプル

　以下は、.NETのSystem.DateTimeのNowプロパティを取得して、現在時刻を表示するサンプルです。
 

set netGate = $system.external.getDotNetGateway()
 
set now = netGate.getProperty("System.DateTime","Now")
 
write now
// 2026-09-25 09:52:20.7335562  ; 現在時刻が表示されるサンプル

InterSystems ObjectScript およびIRISプラットフォームにおけるLLMの性能を測定する、初のオープンベンチマークを公開いたしました： ObjectScript LLMベンチマーク。

その存在意義

確立されたコーディングベンチマーク（SWE-bench、LiveCodeBench、Terminal-Bench）は、Python、JavaScript、およびシェルを基にしています。これらには、ObjectScript、IRIS SQL、Embedded Python、あるいは%CSP.RESTは含まれていません。公表されているコーディングスコアは、IRISプラットフォームには適用されません。これは、そのギャップを直接測定しようとする初めての試みです。

測定内容

「コード生成」「コード理解」「バグ修正」の3つのカテゴリにわたる140件の手書き課題です。 主な採点モデルは稼働中のIRISインスタンスです。モデルの応答がコンパイル・実行され、その出力が期待される文字列と比較されます。 実行結果で採点される93件の課題については、主観的な採点は行われません。 47件の理解課題については、評価基準に基づいたLLMによる採点が行われます。

14のモデル（Claude 4.

1. はじめに

1.

すべては、両親を訪ねるための電車の中で始まりました。コンパートメントで隣に座った人と雑談をしていたときのことです。話はいつものように技術の話題へと移り、彼女はかなり具体的な質問を投げかけてきました。「ChatGPTを使って人間のゲノムを解析することはできるのだろうか?」というものです。私は、これほど複雑なことをChatGPTが成し遂げられるとは、非常に懐疑的でした。しかし、その質問は頭から離れず、私の心に深く食い込んでいきました。自宅の玄関を入る頃には、その懐疑心は挑戦へと変わっていました。手元にゲノムシーケンシングのデータセットはありませんでしたが、標準的なChatGPTが PyProdパッケージを使って、ゼロから機能する相互運用性プロダクションを構築できるかどうかを試してみたかったのです。 さらに、そうすれば 「アイデアからアプリケーションへ」コミュニティ・バウンティ・プログラムの第1ラウンドに参加し、第3のアイデアを実装する機会も得られると考えました。

そこで、複数のステップからなるプロンプトを使ってテストしてみることにしました：

以下の記事およびGitHubリポジトリの情報をもとに、PyProdパッケージを使用してPythonでInterSystems Productionの完全なコードを記述してください：

ステップ1：このProductionのドメインを考案してください。

Hi Developers!

前回の記事、「Electric Utility PyProd」では、PyProdフレームワークを使用して、ローカルディレクトリ内のCSVファイルを処理するシンプルな相互運用性プロダクションを構築しました。あの例では、完全にPythonで実装されたプロダクションの基本的な構成要素を紹介しましたが、実際の相互運用性ソリューションでは、外部システムとの通信が必要になることがよくあります。

この記事では、公開されている openFDA 医薬品有害事象 API(openFDA Drug Adverse Event API) から医療データを取得し、返されたデータを分析した上で、医療分析結果を InterSystems IRIS に保存する、より高度なプロダクションを構築します。

このチュートリアルでは、以下の方法について解説していきます：

• PyProd Inbound Adapter から外部 REST API を呼び出す方法
• 大規模な JSON ペイロードを効率的に処理する方法
• バッチ単位のヘルスケア分析を実行する方法
• 結果を IRIS SQL テーブルに永続化する方法
• Python のみを使用して、相互運用性ソリューション全体を実装する方法

セットアップ

リポジトリをクローンしてください：

git clone https://github.com/Gra-ach/openfda-healthcare-pyprod.git
cd openfda-healthcare-pyprod

はじめに

InterSystems IRIS 2026.1 がリリースされてから、しばらく時間が経ちました。すでに手元の環境で触ってみた方もいれば、「気にはなっていたけれど、まだ試せていない」という方もいらっしゃるのではないでしょうか。

そんなどちらの読者にもすぐに動作を確かめていただけるように、2025.1（前回 EM）と 2026.1 を Docker Compose で並べて起動し、新機能の挙動を Before/After で比較できるデモ環境一式とドキュメントを GitHub で公開しました。docker compose up -d 一発で、IRIS 2025.1 / 2026.1 の両管理ポータルに加え、Grafana・Prometheus・Keycloak・PostgreSQL までまとめて立ち上がります。

2026.1 は EM（Extended Maintenance）リリースで、CD版である 2025.2 / 2025.3 の機能をすべて含み、加えて 2026.1 で新たに追加された機能が組み込まれています。EM と CD はいずれも production release で、InterSystems の正式サポート対象です。

現代の医療現場において、臨床的に類似した患者を見つけることは、しばしば「干し草の山から針を探すようなもの」に感じられます。医療用語には微妙なニュアンスが多いことから、従来のキーワード検索では失敗することがよくあります。「心不全(Heart Failure)」と検索しても、「うっ血性心不全(Congestive Cardiac Failure)」という表現が含まれる記録を見逃してしまう可能性があるからです。

iris-medmatchをご紹介できることを大変嬉しく思います。これは、InterSystems IRIS for Healthを基盤として構築された、AIを活用した患者マッチングエンジンです。ベクトル探索を活用することで、このツールは単なる文字列の一致だけでなく、臨床的な意図を理解することができます。 ## 革新の核心：セマンティック臨床検索

`iris-medmatch`は、FHIRの生データとAIによる実用的なインサイトとの間のギャップを埋めます。`all-MiniLM-L6-v2`モデルを活用することで、このエンジンは病状を数値ベクトルに変換します。

一般的な検索では正確な単語が検索対象となりますが、当エンジンは**臨床状況**を理解します。例えば、数値ベクトル類似度を用いて、「高血圧」という検索語に対して「高血圧症」と診断された患者を照合することができます。

開発者の皆さん、こんにちは！ ウェビナー＆ハンズオンシリーズ 久々お知らせです！📣今回のテーマは「AI エージェントの開発」です。🤖

AI エージェントって結局何なの？

AI エージェントの開発に興味はあるけれど、何から学べばよいのか分からない。

そんな方を対象に、「仕組みを理解する → コードを見る → 実際に作る」の 3 ステップで学ぶシリーズです。

• 「AI チャット」と「AI エージェント」の違いって？
• どんな機能を用意したら「AI エージェント」になるの？
• なんとなく会社で使ってるけど、実際どんな仕組みになっているの？

そんな疑問を、デモやコード例、ハンズオンを通じて一緒に解明していきましょう！

LangGraph を使用して、推論、ベクトル検索、ツール統合を組み合わせた、スケーラブルで自律的な AI エージェントの設計方法を学びましょう。

長すぎるので読み飛ばしました

• AIエージェントとは、メモリ・コンテキスト・主体性を組み合わせ、単なるチャットボットを超えたタスクを自動化する能動的なシステムです。
• LangGraphは、組み込みの状態管理機能を備えたノード（タスク）とエッジ（接続）を活用し、複雑なAIワークフローを構築できるフレームワークです。
• このガイドでは、優先度を分類し、関連するトピックを特定し、エスカレーションを行うか自動返信するかを判断する、AI搭載のカスタマーサポートエージェントの構築手順をご説明します。

では、一体、AIエージェントとは何でしょうか？

率直に言って、「AIエージェント」と聞くと、まるで役員室を乗っ取ろうとするロボットのように聞こえるかもしれません。しかし実際には、複雑なワークフローを効率化し、反復的な作業を排除してくれる、先を見越した頼もしい相棒なのです。チャットボットをさらに進化させた存在だと考えられるでしょう。AIエージェントは単に指示を待つだけでなく、自らアクションを開始し、複数のステップを調整し、状況に応じて適応していくのです。

Intersystems IRIS プロダクションは、さまざまなプロトコルやメッセージ形式を持つ異種システム間を、信頼性が高く、可観測性があり、スケーラブルな方法で接続するための強力なフレームワークです。intersystems_pyprodは、 InterSystems Python Productionsの略称は、開発者がこれらの相互運用性コンポーネントをPythonで完全構築できるようにするPythonライブラリです。柔軟性を重視して設計されており、ハイブリッドなアプローチをサポートしています。つまり、既存のObjectScriptベースのコンポーネントと新しいPythonベースのコンポーネントをシームレスに組み合わせ、確立されたIRISインフラストラクチャを活用することができます。一度定義されると、これらのPythonコンポーネントは他のコンポーネントと同様に管理されます。つまり、[IRIS プロダクション構成]ページを使用して、追加、構成、接続を行うことができます。

InterSystems IRIS プロダクション：簡単な入門書

プロダクションの主要な要素

画像提供：ラーニング・サービス研修資料

通常、IRISプロダクションは外部インターフェースからデータを受け取り、調整したステップを通じて処理を行い、宛先へと転送します。

INTRO

Barricadeは、InterSystems OMOP向けのFHIRからOMOPへの変換を効率化し、そのサポートをスケールアップするために、ICCA Opsが開発したツールです。当社のクライアントは、InterSystems OMOPを使用してFHIRデータをこのOMOP形式に変換することになります。マネージドサービスとして、当社の役割は変換プロセスに伴うあらゆる問題のトラブルシューティングを行うことです。Barricadeは、さまざまな理由から、このプロセスを支援する理想的なツールです。第一に、効果的なサポートには、FHIR標準、OHDSI OMOPモデル、そしてInterSystems特有の運用ワークフローにわたる専門知識が必要ですが、これらはすべて高度に専門化された分野です。Barricadeは、大規模言語モデルを活用してFHIRやOHDSIに関する専門知識を提供することで、知識のギャップを埋めるお手伝いをします。さらに、特定の変換問題を解決するために詳細な説明が行われたとしても、その知識はメールやチャットの中に埋もれてしまい、将来的に活用できなくなることがよくあります。Barricadeなら、その知識を収集・再利用し、類似のケースにスケールさせることも可能です。最後に、多くの場合、ソースデータにアクセスできません。

これは InterSystems FAQ サイトの記事です。

これらのファイルを個別にエクスポートする最も簡便で確実な方法は、VSCodeを利用してIRISのソースファイルを管理することです。

VSCodeの利用方法は、以下をご参照ください

VSCodeを使ってみよう

VSCode以外のツールとしての提供はありませんので、是非VSCodeのご利用をご検討ください。

VSCodeをご利用できない場合は、IRISが提供するAPIを使用して、個別にプログラミングする必要があります。

1) クラス定義

%SYSTEM.OBJクラスのExportAllClassesIndividualメソッドを使用してクラス毎にファイル出力できますが、その出力形式がXML形式です。

XML形式での出力は、可読性も低く、クラス数が多量にある場合には、インポートの時間も余計にかかるため、複数クラスを１ファイルにまとめる目的以外では、推奨しておりません。

可読性の高いUDL形式で出力するためには、

該当ネームスペースに存在するクラス名をクエリーで抽出し、クラス定義をUDL形式でエクスポートするメソッドで出力することができます。

以下はClaude Codeで生成したサンプルコードです。

Class Samples.ExportUDLAll
{

/// 指定されたネームスペース内のすべてのクラス定義を
/// 個別のUDL形式ファイルとして指定ディレクトリに出力する
///
/// @param pDirectory 出力先ディレクトリ名
/// @return %Status ステータスコード
ClassMethod Export(pDirectory As %String) As %Status
{
Set tSC = $$$OK
Try {
// %SYSTEM.OBJ の GetClassList メソッドでクラス名一覧を取得
// items はローカル多次元配列として ByRef で返る
// 第一サブスクリプトにクラス名が格納される
Set tSC = $SYSTEM.OBJ.GetClassList(.items, "/application=1")
If $$$ISERR(tSC) Quit

// items 配列をサブスクリプト順に走査してクラス数分繰り返す
Set tClassName = ""
For {
Set tClassName = $Order(items(tClassName))
Quit:tClassName=""

Write "class name = ", tClassName, !
Set tFileName = pDirectory _ "/" _ tClassName _ ".cls"
Write "file name = ", tFileName, !

// ExportUDL の第一パラメータ(itemname)はクラス名に ".cls" を付加
Set tSC = $SYSTEM.OBJ.ExportUDL(tClassName _ ".cls", tFileName)
If $$$ISERR(tSC) Quit

Write "Exported: ", tClassName, " -> ", tFileName, !
}
} Catch ex {
Set tSC = ex.AsStatus()
}
Quit tSC
}

}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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