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

一番簡単な方法は、以下のコミュニティ記事にある ObjectScript Lite Terminalを使用する方法です。

VSCodeだけでIRISターミナル完結

IRISのコマンドをターミナルから実行する場合は、即時実行と複数行のコードを一度にまとめて実行する２つの実行方法があります。
即時実行の場合は、１個または複数のコマンドを１行で入力して、リターンキーを入力することで実行します。
即時実行の場合、複数行にまたがって一度に実行することはできません。

複数行をまとめて実行する場合には、予め複数行のコードをルーチンバッファーと呼ばれるメモリー上に一時的に保存して、一度に実行することができます。

ルーチンバッファーにコードを入力するためには、

ラベルの後ろにスペースまたはタブを入力した後に実行したいコードを入力します。
２行目以降は、スペースまたはタブを入力した後に実行したコードを入力します。

コードを入力し終わったら、以下のように実行することで、複数行まとめて実行できます。

>Do [先頭に指定したラベル名]

ルーチンバッファーの内容を確認するには、zprintコマンドを使用します。
以下はルーチンバッファーに複数行のコードを保存して、実行する例です。

InterSystems は以下のバージョンをリリースしました: 

• InterSystems IRIS Data Platform 2026.1.0.237.3
• InterSystems IRIS for Health 2026.1.0.237.3
• HealthShare Health Connect 2026.1.0.237.3

このリリースでは新たに Ubuntu 26.04 オペレーティングシステムをサポートします。Ubuntu 26.04 は Linux カーネル 7.0、セキュリティの改善、インストーラとユーザインターフェイスの改善が行われています。  

今回は Intel/AMD (x86_64) プロセッサ対応のキットのみをリリースしています。ARMサーバにおいてネットワーク障害が発生するケースが複数報告されています。これはネットワークドライバの問題だと考えていますが、念のためARMプロセッサ対応キットのリリースを保留しています。この問題が解決され次第、ARMプロセッサ対応キットをリリースいたします。

ソフトウェアの入手方法

インストールキットは WRC の Software Distribution にある InterSystems IRIS (Extended Maintenance kits) ページから入手可能です。

FHIRプロファイルとは何ですか？

FHIR プロファイル とは、基盤となるFast Healthcare Interoperability Resources（FHIR）リソースをカスタマイズし、洗練させるために用いられる一連の規則と制約の集合体です。プロファイリングは、特定のユースケース、地理的地域、医療機関、または臨床ワークフローの固有の要件を満たすために、基盤となるFHIRリソース標準を適応させる重要なプロセスです。

基本となるFHIRスペシフィケーションでは、リソース（患者、観察、薬剤など）に対して一般的な、柔軟な定義を規定しております。一方、プロファイルはこれらの一般的なリソースをより精密なものへと変換します。これにより、特定のコミュニティや実装に合わせて調整された、一貫性と相互運用性を備えたデータ交換が保証されます。

FHIRは、世界中の様々な医療シナリオをカバーするよう設計されています。プロファイルにより、実装者は標準化の利点を損なうことなく、この総合プラットフォームを適応させることが可能となります。

FHIRプロファイルはどのような場合に使用するのでしょうか？

FHIRプロファイルは、システムがデータを検証するために使用する計算可能なルールとして機能します。

2026年前半の最新情報をお伝えします。今回お伝えする注目の情報は以下の通りです。

• Ubuntu 26.04 がリリースされました。対応 IRIS もまもなく提供される予定です。
• IRIS 2026.2 にて Ubuntu 22.04 および Windows 10 のサポートが終了します。
• 2025.3以降、必要な CPU 最小バージョンが変更されました。

この情報記事を初めてご覧になるみなさまへ。この最新情報では、最近行われた機能強化、および、現時点での今後の製品機能予定について説明しています。ただし、これらは現時点の予定であり、将来変更される可能性があること、そのため本記事の内容が製品ロードマップとして確定したものでないことにご注意ください。

開発者の皆さん、こんにちは！

InterSystems オンラインプログラミングコンテストの次の内容が決定しました！

🏆 InterSystems プログラミングコンテスト：FHIR 対応 AI エージェント🏆

期間： 2026年5月25日～6月14日

賞金総額: $12,000

以前のバージョンにおいても、FHIRサーバーをOAuth 2.0経由でのリクエスト受付に対応させる設定が可能でした（例：SMART on FHIRクライアント向け）。しかし、現在では v2024.3, （以前リリースされたバージョン） , では、これをより容易に行える新機能が追加されました。具体的には、OAuth FHIR Client QuickStartが追加されました。

この「QuickStart」は、ウィザード形式の「ヘルパー」ツールであり、わずか5つの簡単なステップ（実際には3ステップのみです...）で、FHIRサーバーをOAuthサーバーに接続し、FHIRリクエストに対するOAuth認証および認可を有効にすることができます。

• ステップ1 - FHIRサーバーの作成または選択

すでに定義済みのFHIRサーバー（エンドポイント）をお持ちの場合もあれば、まだ定義しておらず、このクイックスタートとして今定義したい場合もあるかもしれません。

• ステップ2： FHIRサーバーを選択

開発者の皆さん、こんにちは！

18名のコミュニティメンバーが参加した InterSystems 技術文書ライティングコンテスト（USコミュニティ） ですが、なんと

🌟 21 の素晴らしい記事 🌟の投稿がありました！

このコンテストには、専門性と革新性を兼ね備えた優れた出版物が多数集まりました。質の高い応募作品が数多く寄せられたため、審査員にとって最優秀作品を選ぶのは非常に困難な作業でした。

それでは、受賞作品を発表します！

以下は、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 のリリースに関する詳細については リリースストリームのドキュメント をご覧ください。

ある概念は紙に書かれたままでは完璧に理解できても、他の概念は実際に手を汚すことを必要とすることがあります。 例えば、運転を例に挙げましょう。エンジンの仕組みのあらゆる部品を暗記することはできますが、それが運転が実際にできることを意味するわけではありません。

実際に運転席に座り、クラッチの摩擦点や路面からの振動を身体で感じ取るまでは、その真髄を理解することはできません。 コンピューティングの概念の中には直感的に理解できるものもありますが、インテリジェントエージェントは異なります。それらを理解するためには、運転席に座る必要があるのです。

これまでのAIエージェントに関する記事では、CrewAIおよびLangGraphといったツールについて取り上げてまいりました。しかし、本ガイドでは、AIエージェントのマイクロフレームワークをゼロから構築してまいります。エージェントを構築することは、単なる構文の習得を超えた取り組みであり、開発者にとって実世界の問題を解決に挑戦する貴重な旅と申せます。

とはいえ、経験そのもの以上に、これを行う根本的な理由がもう一つあります。それはリチャード・ファインマンの言葉に最もよく表れています：

「自分でつくれないものは、本当に理解しているとはいえない」

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

具体的に説明いたします。エージェントとは、本質的に目的を追求するコードです。

その1 では、MAIS（マルチエージェント相互運用システム）の技術的基盤を構築いたしました。「脳」の配線に成功し、LiteLLMを用いた堅牢なアダプターを構築し、IRIS資格情報でAPIキーをロックダウンし、そしてついにPython相互運用性のパズルを組み立てたのです。 しかしながら、現時点では我々のシステムはLLMへの単なる未加工のパイプに過ぎません。テキストを扱うことはできますが、アイデンティティを欠いているのです。

さて、この第2部では、エージェントの構造についてご説明いたします。単純なAPI呼び出しから、構造化されたペルソナへと進みます。LLMをビジネスロジックの層でラップし、その名称やロールを定義し、そして最も重要な点として、隣接する要素を認識する能力を付与する方法について学んでまいります。

私たちのマシンの「魂」を構築しましょう。

エージェントの構造： ただのプロンプトではなく

「脳」（LLM）との接続が確立したところで、次にその「脳」にパーソナリティを付与する必要があります。よくある誤解として、エージェントとは単に「役立つアシスタントです。」といったシステムプロンプトに過ぎないという見方がありますが、それは単なるチャットボットに過ぎません。

真正なエージェント型AIは、監視を必要としない点で際立っています。それは自律性と、任務を完遂しようとする強い意欲を兼ね備えています。

現代のデータアーキテクチャでは、リアルタイムのデータ収集、データ変換、データ移動、データロードのソリューションを活用し、データレイク、分析用倉庫、ビッグデータリポジトリを構築しております。様々なソースからのデータを、それらを利用する操作に影響を及ぼすことなく分析することを可能にします。これを実現するためには、継続的、拡張的、弾力的、かつ堅牢なデータフローを確立することが不可欠です。そのための最も一般的な方法は、CDC（変更データキャプチャ） 技術によるものです。CDCは小さなデータセットの生成を監視し、このデータを自動的に収集して、分析用データリポジトリを含む1つ以上の受信先に配信します。主な利点は、分析におけるD+1（データ生成の翌日）の遅延が解消される点です。データは生成されるとすぐにソースで検知され、その後、対象の宛先へ複製されるためです。

本記事では、CDCシナリオにおいて最もよく使用される2つのデータソース（データソースおよびデータ宛先として）についてご説明いたします。データソース（元）としては、SQLデータベースおよびCSVファイルにおけるCDCの活用方法について探ってまいります。