InterSystems IRIS（医療・金融系で使われる統合データプラットフォーム）をVS Codeで運用しているチームで、GitHub CopilotなどのAIコード支援がうまく機能しないという相談が出ることがあります。原因を突き詰めると、開発環境の構成そのものに起因しているケースが目立ちます。この記事では、その根本原因の見分け方と、対策として登場したMCPサーバー（AIアシスタントに外部ツールを呼び出させる仕組み）を導入すべきかどうかの判断基準を整理します。
対象となるのは、IRISの本番環境をサーバーサイド開発スタイルで運用しているエンジニアです。具体的には、VS Codeのisfs://ワークスペース（ObjectScriptのクラスをサーバー上に置いたまま編集する仕組み）を使っている現場を想定します。AIアシスタントを導入したのに「新規メソッドは書けるが既存コードの理解は手伝ってくれない」と感じている方の参考になれば幸いです。
なぜAIがコードを見えなくなるのか
isfs://ワークスペースの正体は、IRISサーバー上のクラス定義をAtelier API（VS Code拡張がクラスの読み書きに使うREST API）経由でオンデマンドに取得する仕組みです。
ファイルを開いた瞬間にサーバーから取得し、保存すればサーバーに書き戻されます。ローカルにディスク上のファイル群がまとまって存在するわけではありません。
CopilotのようなAIアシスタントは、編集中のファイルの周辺コードを読んでコンテキストを組み立てます。「このメソッドを呼んでいるのは誰か」「このクラスを継承しているのは何か」といった質問に答えるには、プロジェクト全体をスキャンする必要があります。
ローカルプロジェクトならこのスキャンが成立しますが、isfs://は開いたファイルしか実体化しません。スキャンする対象がそもそも存在しないのです。
数百クラス程度の新規プロジェクトなら実害は小さいかもしれません。しかし数千クラス規模の本番IRISシステム、Ensembleプロダクション（IRISのメッセージ連携基盤）を含む構成では、AIは「鍵穴からシステムを覗いている」状態になります。
判断軸1: ワークスペースの構成方式
まず確認すべきは、開発チームがIRISクラスをどう扱っているかです。
ローカルにクラスファイルをエクスポートしてGitで管理し、CI/CDでIRISにデプロイする方式であれば、AIアシスタントは通常のファイルスキャンでコンテキストを得られます。この場合、既存のCopilotやCursorの標準的な使い方で問題は起きにくいはずです。
一方、isfs://でサーバーに直接接続して編集するスタイルなら、AIが見ている範囲は開いているタブだけです。VS Codeでワークスペースを開いたとき、URLバーやエクスプローラーの表示がisfs://から始まっているかを確認してください。
判断軸2: システムの規模と複雑度
クラス数が数百程度で、チーム全員が構造を把握できている規模なら、AIが全体を見渡せなくても実務上の支障は限定的です。
対して、数千クラス規模かつEnsembleプロダクションを多数運用している、あるいは長年の改修でオーナーが不明な業務ロジックが積み重なっているシステムでは、AIに「このグローバル変数を触っているコードはどこか」と聞きたい場面が頻発します。この規模になると、鍵穴越しのAI利用は非効率さが目立ってきます。
判断軉3: 障害対応・調査での利用頻度
運用監視や障害対応の文脈では、コード生成よりも「今起きていることの原因を探す」作業のほうが重要になります。
Ensembleプロダクションの稼働状況、実行中の構成とソースコードの差分（ドリフト）、エラーログの追跡といった作業は、まさにコードの静的なスキャンでは届かない領域です。障害対応でAIに手伝ってほしい範囲がコンテキスト理解に依存するほど、ライブ接続型の仕組みの必要性は高まります。
判断軸4: 運用コストと導入の手間
MCPサーバー（AIアシスタントがIRISに直接問い合わせできるようにする常駐プロセス）の導入は、新しいプロセスを1つ運用リストに追加することを意味します。
Dockerで動かすIRISインスタンスであればコンテナを1つ追加する程度の負荷ですが、認証情報の管理、VS Code拡張のバージョン（MCP対応はVS Code 1.99以降）、Claude CodeやOpenCodeとの併用状況など、確認すべき前提がいくつかあります。導入前に「誰が運用するのか」「既存の監視対象に含めるのか」を決めておく必要があります。
選択肢の比較
| 方式 | AIが見えるコンテキスト | 導入コスト | 向いている規模 |
|---|---|---|---|
| ローカルGit管理+CI/CDデプロイ | プロジェクト全体（標準スキャン） | 既存構成のまま | 小〜中規模、新規開発中心 |
| isfs://のみ（現状維持） | 開いているタブのみ | 追加コストなし | 数百クラス以下の小規模 |
| MCPサーバー併用 | namespace全体に問い合わせ可能 | プロセス追加・認証設定 | 数千クラス規模の本番運用 |
isfs://運用で数千クラス規模の本番IRISを扱っているなら、AIの実力不足ではなくコンテキストが届いていないだけの可能性が高いです。ケース別の推奨
新規プロジェクトでローカルGit管理が可能なら、MCPサーバーを急いで入れる必要はありません。標準のCopilot Agent modeで十分機能するはずです。
本番IRISをisfs://で運用しており、クラス数が数千規模、かつEnsembleプロダクションの障害調査でAIの助けを借りたい場合は、MCPサーバー導入を検討する価値があります。Atelier APIを使ってnamespace全体を検索・コンパイル・SQL実行できる仕組みは、鍵穴越しの制約を外す実質的な手段です。
導入する場合は、まずDocker上のIRISインスタンスなど本番に影響しない環境で動作確認するのが安全です。認証情報をOSキーチェーンから読み込む連携（Server Manager拡張のAuthenticationProviderを使う方式）が用意されているため、設定ファイルに平文で資格情報を書く必要はありません。
あえて見送るべき条件
クラス数が少なく、チームがIRISの構造を口頭で説明できる規模なら、新しい常駐プロセスを増やす判断は見送ってよいはずです。運用対象を1つ増やすことは、監視対象・パッチ適用対象・障害点を1つ増やすことでもあります。
また、AIアシスタントの利用がコード生成中心で、既存コードの調査や障害対応にはほとんど使わないチームでも、優先度は高くありません。まずはisfs://をやめてローカルGit管理に移行できないか検討する方が、投資対効果は大きい場合があります。
導入前に確認すること
判断に迷ったら、まず自分たちのワークスペースURLがisfs://から始まっているかを確認してください。
次に、IRISのクラス数とEnsembleプロダクションの規模を把握し、AIに聞きたい質問が「コード生成」なのか「既存システムの調査」なのかを整理します。
調査系のニーズが強く、規模が数千クラスを超えているなら、MCPサーバーを非本番環境で試験導入し、認証連携とAtelier API経由の応答速度を確認するところから始めるのが現実的な一歩になります。