InterSystems IRISは総合データプラットフォームです
InterSystems IRISは、企業にとって最も価値のある資産(データ)の取得、共有、理解、そしてデータに基づく行動のために必要なすべてのものを提供します。
完全なプラットフォームである InterSystems IRIS は、複数の開発技術を統合する必要がありません。より少ないコードで開発が可能で、そのアプリケーションは、システムリソース、メンテナンスなども少なくて済みます。
前回、Apache Spark と InterSystems Data Platform を使って機械学習を実験するためのプレイグラウンドを作成したときは（「Spark と Caché による機械学習」を参照）、Caché、Python、Apache Spark、Java、Hadoop ライブラリなど、すべてを直接自分のノートパソコンにインストールして構成しました。 これには多少の努力が必要でしたが、最終的には上手くいきました。 満足していましたが、 心配になりました。 「この手順をすべて再現できるのだろうか？」 ―多分できる。 「Windows や Java のアップデートですべてが一瞬にして台無しになる可能性はないか？」 ―ほぼ確実にある。
今では、ますます普及しているコンテナとますます使いやすくなった Docker for Windows により、事前に構成された機械学習環境とデータサイエンス環境を選択できるようになりました。 たとえば、Jupyter Docker Stacks と Zeppelin on Docker Hub をご覧ください。
IAMの管理を手動で行うには手間ががかります。OpenAPI（Swagger）仕様を使用して、APIがすでにしっかりとドキュメント化されている場合はなおさらです。 Open API仕様から直接、Kongサービスやルートを自動生成できたらいいのにと思いませんか？
このObjectScriptメソッドはまさにその処理を行います。仕様クラスの XData ブロック内に保管されているOpenAPI 2.0仕様を読み取り、IAM構成を同期するために使用できるdecKと互換性があるYAMLファイルを生成します。
メソッド ConvertOpenAPIXDataToDeckYAML の機能は次のとおりです。
OpenAPI仕様を読み取る： 指定したクラス内の OpenAPI という名前の XData ブロックから読み取ります。
JSONを解析する：動的オブジェクトに変換します。
エンドポイントを抽出する ：HTTPメソッドも抽出します。
REST API（Representational State Transferアプリケーションプログラミングインターフェース）は、GET、POST、PUT、DELETEなどのHTTPメソッドを使用してウェブアプリケーション間で通信するための標準化された方法です。 リソースを中心に設計されており、リソースにはユーザーやファイルなどあらゆるものが含まれます。 各リソースは一意のURLで識別され、これらのリソースのやり取りはステートレスです。クライアントからサーバーへの各リクエストには、リクエストを理解して処理するために必要なすべての情報が含まれている必要があります。 このステートレス性と標準的なHTTPメソッドの使用により、REST APIは高度にスケーラブルで理解しやすく、さまざまなシステムとの統合も簡単です。 RESTの原則に従うことで、開発者は一貫性があり、使いやすく、幅広いタスクに対応できるAPIを作成できます。
InterSystemsは、さまざまなツールと技術でREST API開発をサポートします。 この記事シリーズでは、私自身が特にお勧めするものを取り上げます。 記事は以下のように分類されています。
以下は、2026 年の IRIS リリースカレンダーの更新情報と、2027 年に予定されている変更点の概要です。2026 年における主なポイントは、メンテナンスリリースのバージョン番号付けが、これまでの年とは若干異なる点です。
2026 年：IRIS 2026.1 メンテナンスリリースのバージョン番号
このバージョン番号付けの変更は、2027年に予定されているメンテナンス頻度の拡大に備えたものです。
2027 年：メンテナンスリリースの頻度拡大
2027 年よりお客様が IRIS の新バージョンをより迅速に導入できるよう、メンテナンスリリースの頻度を高める予定です。
2027 年のメンテナンスリリースに関する詳細は、来年発表される予定です。
EM および CD のリリースに関する詳細については リリースストリームのドキュメント をご覧ください。
その1 では、MAIS（マルチエージェント相互運用システム）の技術的基盤を構築いたしました。「脳」の配線に成功し、LiteLLMを用いた堅牢なアダプターを構築し、IRIS資格情報でAPIキーをロックダウンし、そしてついにPython相互運用性のパズルを組み立てたのです。 しかしながら、現時点では我々のシステムはLLMへの単なる未加工のパイプに過ぎません。テキストを扱うことはできますが、アイデンティティを欠いているのです。
さて、この第2部では、エージェントの構造についてご説明いたします。単純なAPI呼び出しから、構造化されたペルソナへと進みます。LLMをビジネスロジックの層でラップし、その名称やロールを定義し、そして最も重要な点として、隣接する要素を認識する能力を付与する方法について学んでまいります。
私たちのマシンの「魂」を構築しましょう。
「脳」（LLM）との接続が確立したところで、次にその「脳」にパーソナリティを付与する必要があります。よくある誤解として、エージェントとは単に「役立つアシスタントです。」といったシステムプロンプトに過ぎないという見方がありますが、それは単なるチャットボットに過ぎません。
真正なエージェント型AIは、監視を必要としない点で際立っています。それは自律性と、任務を完遂しようとする強い意欲を兼ね備えています。
ある概念は紙に書かれたままでは完璧に理解できても、他の概念は実際に手を汚すことを必要とすることがあります。 例えば、運転を例に挙げましょう。エンジンの仕組みのあらゆる部品を暗記することはできますが、それが運転が実際にできることを意味するわけではありません。
実際に運転席に座り、クラッチの摩擦点や路面からの振動を身体で感じ取るまでは、その真髄を理解することはできません。 コンピューティングの概念の中には直感的に理解できるものもありますが、インテリジェントエージェントは異なります。それらを理解するためには、運転席に座る必要があるのです。
これまでのAIエージェントに関する記事では、CrewAIおよびLangGraphといったツールについて取り上げてまいりました。しかし、本ガイドでは、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 がリリースされました。今回のリリースでは、最近お知らせした以下の警告や勧告の修正が含まれています。
より良い製品を皆様と共に作り上げていくため、 アイデアポータル 内の リリース後のフィードバック カテゴリからご意見をお寄せください。
詳細な変更リストとアップグレードチェックリストはこちらのドキュメントをご参照ください(すべて英語 2025.
InterSystems IRISデータプラットフォームは、InterSystemsの全アプリケーションに加え、ヘルスケア、ファイナンシャルサービスおよびサプライチェーンをはじめとする様々なエコシステムにおいて、数千もの顧客およびパートナーアプリケーションの基盤となっております。これは収束プラットフォームであり、トランザクション・アナリティクスデータ管理、統合された相互運用性、データ統合に加え、統合された分析およびAIを提供します。多様な分散データを管理するInterSystemsスマートデータファブリックアプローチをサポートしております。
.png)
当社のアーキテクチャの中核には、コアデータエンジン（別名一般なデータプレーン）における高性能・マルチモデル・多言語データ処理機能がございます。これを基盤として、膨大なデータ量と毎秒10億を超えるデータベース操作に及ぶ高いトランザクションレートに対応する、卓越したスケーリング機能を備えております。
次に、二つの主要なサブシステムが挙げられます。一つは分析と人工知能（AI）に焦点を当てたもので、もう一つは相互運用性とデータ統合に焦点を当てたものです。これらのサブシステムは、データに近接して全てを実行し、最小のフットプリントで高いパフォーマンスを提供する、という当社の基本理念に沿った設計となっております。
極めて高いパフォーマンスが求められるアプリケーションにおいて、企業はしばしばインメモリデータベースやキーバリューストア（キャッシュ層）を採用します。しかしながら、インメモリデータベースは総所有コストが高く、スケーラビリティにも限界があり、メモリ制限を超えた場合には信頼性の問題や再起動の遅延が生じます。インメモリキーバリューストアも同様の制約を抱えるだけでなく、アーキテクチャの複雑さやネットワーク遅延といった新たな課題をもたらします。
本記事では、高パフォーマンスのSQLおよびNoSQLアプリケーションにおいて、InterSystems IRIS™データプラットフォームがインメモリデータベースやキーバリューストアに比べ優れた選択肢である理由についてご説明いたします。
InterSystems IRISは、同時データ取り込みおよび分析処理において、インメモリデータベースやキャッシュ層の性能に匹敵、あるいはそれを上回る唯一の永続データベースです。市販されているハードウェア上において、ネットワーク遅延を発生させることなく、1マイクロ秒未満で着信トランザクションの処理、データのディスクへの永続化、分析のためのインデックス作成を実現します。
.png)
インターシステムズ アイデア ポータル（InterSystems Ideas Portal）で最も多くの賛同を得た提案（74票）は、IRISの軽量バージョンを要望するものです。プラットフォームは強力なデータエンジンに成長していますが、多くのプロジェクトではSQLデータベース機能のみが必要とされています。本記事では、コアなデータベース機能にのみ焦点を当てた非公式なコンパクトなIRIS Community Editionイメージを構築する方法を示し、イメージサイズを80％以上削減する方法を説明します。
このプロジェクトは、InterSystems IRIS Community Editionの非公式な実験的なイメージを生成します。
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ステートメント）：
.png)
[注記：旧バージョン（例：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 HealthTM、HealthShare® Health Connect のメンテナンスバージョン 2023.1.7 をリリースしました。
より良い製品を共に作り上げるため、アイデアポータル の「Post-Release Feedback」カテゴリでご意見をお寄せください。
ドキュメント
変更点の詳細と、アップグレードチェックリストは以下のリンクからご覧いただけます。(すべて英語)
早期アクセスプログラム(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）リリースです。
データベース・スケーラビリティの強化
データベースの容量制限が撤廃されました。これにより、従来の容量制限をこえてもデータ移行が必要なく、円滑にシステム拡張できるようになりました。また低レベルパフォーマンスも改善され、大規模運用がさらに最適化されています。
ユーザー定義の論理キーに基づきテーブルと関連インデックスデータを分割し、データベース間で簡単にマッピングできるようになりました。これによりストレージの階層化が可能となり、大容量テーブルにおけるクエリパフォーマンスと運用効率が向上しました。この機能は早期アクセス・プログラムで提供されている実験的な機能です。早期アクセス・プログラムに参加いただくと、機能のアップデートを受け取ったり、フィードバックを送信することが可能となります。
相互運用プロダクションでは、HTTPクライアントとして動作するビジネスオペレーションを常に設定することが可能です。このオペレーションはOAuth 2.0による認証を利用しますが、この認証方式に対応するためにはオペレーションのカスタマイズが必要でした。 最近リリースされた v2024.3以降では、 この処理をより容易に行うための新機能が追加され、新たな設定オプションが提供されています。
HTTPアウトバウンドアダプターをご利用のビジネスオペレーションにおいて、OAuthグループの下に新しい設定項目が追加されております。
例えば：
新しいOAuth関連の 設定に関するドキュメントはこちらでご覧いただけます。
関連するオペレーションのスクリーンショットの例を以下に示します：
.png)
| 警告 ID | 影響を受ける製品とバージョン | リスクカテゴリー & スコア | 発生条件 |
| DP-449126 | InterSystems IRIS® data platform InterSystems IRIS® for Health InterSystems Health Connect™ versions 2024.1.0 – 2024.1.5, 2024.2.0, 2024.3.0, 2025.1.0 – 2025.1.3, 2025.2.0, 2025.3.0 |
データ整合性 低リスク | CSP セッションイベント用のカスタムロジックの一部として実行されるデータベース更新が、ジャーナリングされない可能性があります。 |
カスタムロジック内でのグローバルのSetおよびKillがジャーナルに記録されない問題を修正しました。修正対象となったカスタムロジックは、%CSP.SessionEvents のサブクラスを介して実装された CSP セッションイベント用に実行されるカスタムロジックです。
この問題は、カスタムロジックがミラーリングされたデータベースに対して行ったSetおよびKillでは発生しません。この条件下では、操作は通常どおりジャーナリングされます。
根本原因は、当該ロジックを実行するデーモンプロセスがプロセスごとのジャーナリング状態を、起動元プロセスから受け継いでいることにあります。
監査はサーバーのセキュリティを確保する上で極めて重要な機能であり、かなり 以前から、サーバーで実行されるSQL文を監査する機能を提供しております。
v2024.3 が既にリリースされておりますが、監査すべきこれらイベントを定義するためのより詳細なオプションを提供しております。
従来は、アクセスメカニズムに準じてSQL文の監査を決定することができました。例えば、JDBC/ODBCからの文の実行と、埋め込みSQL (例えば： コード内で&&sqlを使用する場合など) と、ダイナミックSQL(例えば：コード内で%SQL.Statement%SQL.Statementを使用する場合や、Mgmt. ポータルのSQLクエリ実行、あるいはターミナルのSQLシェルからの実行など）、そして今回、これに 加えて、 特定の種類のステートメントのみを監査対象とすることも可能です（アクセス制御機構に基づき、従来と同様に）。対象となる種類は以下の通りです：
データベースの要素や設定、その他のデータ以外のものを変更する文です。例：CREATE / ALTER TABLE
データを変更する文です。
開発者の皆さん、こんにちは。
先日の 第３回InterSystemsJapan開発者コミュニティミートアップでは、Google Colab を使ったワークショップを実施しました。
その際、解説を読みながら、その場でコードを実行できる Jupyter Notebook の良さを改めて実感しました。
こうした課題は、Notebook 形式にするだけで驚くほど解決します。
サンプルコードのすぐ横に解説を置けるので、迷う時間が減り、そのまま作業ドキュメントにもできます。
ObjectScript でも同じことができれば、学習にも現場作業にもとても便利ですよね。
実は以前、開発者コミュニティに Jupyter Notebooks に ObjectScript を追加する方法（https://jp.community.intersystems.com/node/521496）といった記事が紹介されていました。「これは便利そう！」と思い GitHub リポジトリ（https://github.com/Vekkby/objectsriptkernel
メッセージを 簡単に再送信する機能は、相互運用性における当社の強力な特徴の一つであります。
v2024.3 がまもなくリリースされます（（開発者プレビュー版は既に利用可能です） 既に 公開済みです。これにより、さらに簡単になりました！
Visual Trace 内から、メッセージヘッダーの横に「再送信」ボタンを見つけられます。こちらをクリックすると、通常の「メッセージ再送信エディター」が表示されます（メッセージビューアーを経由して特定のメッセージを 検索する必要はありません）。
以下に、その例を示します：
.png)
関連するリリースノートもご覧ください。
| 警告 Id | 影響を受ける製品とバージョン | リスクカテゴリー & スコア | 発生条件 |
| DP-448888 |
製品: バージョン: |
運用: 高リスク | 2TB以上のデータベースキャッシュを使用したとき |
上記で指定されたバージョンでは、データベースキャッシュが 2,097,152MB(2TB) 以上の場合、インスタンスの起動が失敗したり、稼働中にシステムがハングする可能性があります。キャッシュ値を手動で設定していないインスタンスの初期データベースキャッシュは、システム物理メモリの 25% になるため、物理メモリが 8TB 以上ある場合は、キャッシュ未設定のインスタンスでは本障害が発生する可能性があります。詳細については、以下のドキュメントをご参照ください。
これは InterSystems FAQ サイトの記事です。
通常、フォームデータを受け取りたい場合は、CSPと同様に %request.Get() で受け取れます。
URLパラメータで、?name=123 のようにリクエストする場合も、同様に%request.Get(“name”) で受け取れます。
ファイルの場合は、%request.MimeDataで取得できます
例：
set%request.MimeData
HTMLやPostmanなどで、通常のテキストデータをフォームデータとして送る場合も、%request.Get() で受け取れます。
例：
"name"
ただ同じフォームデータを送る場合でも、例えばPowerShellで以下のように Invoke-RestMethod コマンドを利用して、ファイルを含む Form データをを送る場合、"txt" や "name" など一緒に送るパラメータもStreamデータとして送られます。
Invoke-RestMethod -Uri
その場合は、以下のように取得できます。
例：
"name"私が若かった頃（正確にどれほど若かったかという質問はこの記事の範囲外ですが）、「トークン」という言葉は私にとって楽しみそのものでした。 というのも、年に数回だけ、友だちと一緒にゲームセンターに行って、面白いビデオゲームで遊ぶことができたからです。
今では、トークンはセキュリティを象徴するものになりました。 JSON Web Token（JWT）認証は、REST APIをセキュリティで保護するための最も人気の標準の1つになりました。 幸いなことに、IRISでは、この方式でアプリケーションを保護するための設定をシンプルに行える仕組みがあります。 それでも、アイデアは昔のアーケードで遊んでいた頃とどこか似ています。 ゲームで遊ぶには、トークンを手に入れる必要がありますよね！
セットアップ
まず最初に、ユーザーがトークンを取得できるようにIRISを設定します。 まずは、JWT認証をシステム全体で有効にするところから始めます。 これを行うには、システム管理ポータルを開き、サインインします。 次に、「System Administration」 > 「Security」> 「System Security」 >「Authentication\Web Session Options」に移動します。 ここは、LDAPや二要素認証など、他の認証方法を承認する際に使用する同じエリアです。
今回は、プログラミングというほどのこともないですが
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日仕事だったかもしれません。
この経験を通して感じたのは、既存プログラムの修正には非常に使えるということです。
多少依頼内容に曖昧な点があっても、既存のコードを非常に高速かつ完全、網羅的に理解してくれるので、そういう曖昧性をある意味埋めてくれます。
InterSystemsテクノロジーを本番環境にデプロイする際の推奨事項の1つは、高可用性を設定することです。 これらのInterSystemsテクノロジーにお勧めのAPI Managerは、InterSystems API Manager（IAM）です。 IAM（特にKong Gateway）には複数のデプロイトポロジーがあります。
高可用性を重視する場合は、以下を利用できます。
a) Kong Traditionalモード：複数ノードクラスタ
b) Hybridモード
c) DB-lessモード
それぞれ詳しく説明する前に、最初にInterSystemsが提供するすぐに利用可能なデプロイを理解しましょう（IAMバージョン3.10のインストール）。
Kong Traditionalモード
Kong Traditionalモードは単一ノードクラスタです。 まだお読みでない場合は、@Guillaume.Rongier7183による素晴らしい記事、 IAM (InterSystems API Manager), Zero to Hero をお読みください。IAMの設定してInterSystems IRISで作業する方法についてついて非常に分かりやすく説明しています。
現在、Kong Traditionalモードの単一ノードクラスタは、IKO経由でのIAMデプロイオプションでのみサポートされています。
IRISではCSPタグベースの開発は、非推奨(Deplicated)になっています。
非推奨とはいえ、いますぐ使えなくなることはないと思います。
が、CSP機能に含まれるHyperEventの#server()#呼び出しは、かなりやばいということがわかってきました。
これはChromeを始めとするメジャーなブラウザーが提供しているSynchronous XMLHttpRequestという関数を呼び出しています。
この関数をGoogleは10年前くらいから非推奨機能としていて、いつか完全に機能をドロップすると宣言しています。
インターシステムズのドキュメントにもさりげなく記載されています。
とはいえ、10年もそのままなので、希望的観測をすれば、今後も使える可能性は高いかもしれません。
しかし、ある日突然なくなるリスクはゼロではありません。
ですので、#server()#呼び出しをお手元のコードからなるべく早く取り除くのが賢明です。
それでは、どうすれば良いのか？
ということですが、今のご時世で考えれば、REST APIに変えましょうというのが美しい世界ですが、おそらく書き換えのコストは、半端じゃないでしょう。
ということで、現実的な解は、#Call()#に置き換えることだと思います。
最近話題の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プログラマーが少ない問題を大きく改善してくれる可能性があります。
それでは、私がどのようなことを行ったか説明します。