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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.1):

• HealthShare Health Connect

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

InterSystems IRISデータプラットフォームは、InterSystemsの全アプリケーションに加え、ヘルスケア、ファイナンシャルサービスおよびサプライチェーンをはじめとする様々なエコシステムにおいて、数千もの顧客およびパートナーアプリケーションの基盤となっております。これは収束プラットフォームであり、トランザクション・アナリティクスデータ管理、統合された相互運用性、データ統合に加え、統合された分析およびAIを提供します。多様な分散データを管理するInterSystemsスマートデータファブリックアプローチをサポートしております。

当社のアーキテクチャの中核には、コアデータエンジン（別名一般なデータプレーン）における高性能・マルチモデル・多言語データ処理機能がございます。これを基盤として、膨大なデータ量と毎秒10億を超えるデータベース操作に及ぶ高いトランザクションレートに対応する、卓越したスケーリング機能を備えております。

次に、二つの主要なサブシステムが挙げられます。一つは分析と人工知能（AI）に焦点を当てたもので、もう一つは相互運用性とデータ統合に焦点を当てたものです。これらのサブシステムは、データに近接して全てを実行し、最小のフットプリントで高いパフォーマンスを提供する、という当社の基本理念に沿った設計となっております。

序言

極めて高いパフォーマンスが求められるアプリケーションにおいて、企業はしばしばインメモリデータベースやキーバリューストア（キャッシュ層）を採用します。しかしながら、インメモリデータベースは総所有コストが高く、スケーラビリティにも限界があり、メモリ制限を超えた場合には信頼性の問題や再起動の遅延が生じます。インメモリキーバリューストアも同様の制約を抱えるだけでなく、アーキテクチャの複雑さやネットワーク遅延といった新たな課題をもたらします。

本記事では、高パフォーマンスのSQLおよびNoSQLアプリケーションにおいて、InterSystems IRIS™データプラットフォームがインメモリデータベースやキーバリューストアに比べ優れた選択肢である理由についてご説明いたします。

パフォーマンスと効率性のレベルアップ

InterSystems IRISは、同時データ取り込みおよび分析処理において、インメモリデータベースやキャッシュ層の性能に匹敵、あるいはそれを上回る唯一の永続データベースです。市販されているハードウェア上において、ネットワーク遅延を発生させることなく、1マイクロ秒未満で着信トランザクションの処理、データのディスクへの永続化、分析のためのインデックス作成を実現します。

概要

発生する問題

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

影響

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

インターシステムズ アイデア ポータル（InterSystems Ideas Portal）で最も多くの賛同を得た提案（74票）は、IRISの軽量バージョンを要望するものです。プラットフォームは強力なデータエンジンに成長していますが、多くのプロジェクトではSQLデータベース機能のみが必要とされています。本記事では、コアなデータベース機能にのみ焦点を当てた非公式なコンパクトなIRIS Community Editionイメージを構築する方法を示し、イメージサイズを80％以上削減する方法を説明します。

⚠️ Disclaimer

このプロジェクトは、InterSystems IRIS Community Editionの非公式な実験的なイメージを生成します。

• InterSystemsによるサポートまたは推奨はされていません。
• 使用は自己責任です。これらの変更により、プラットフォームの中核機能が削除され、ツールやAPI、想定される動作との互換性が損なわれる場合があります。
• 確証または保証 なしに生は、産用途への適合性を含みます。
• 上級ユーザーによる教育および実験目的のみに供するものです。

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

USコミュニティでの開催ですが、InterSystems 技術文書ライティングコンテストの開催が決定いたしました！

✍️ InterSystems 技術文書ライティングコンテスト 2026 ✍️

InterSystemsの製品およびサービスに関連する内容であればどのような記事でもご応募いただけます。

🎁 応募者全員にプレゼントあります: コンテストに参加するすべての方に特別なプレゼントをご用意いたします！

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

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

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

キットの入手方法

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

インターシステムズは、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日仕事だったかもしれません。

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

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