結論：2026年8月、Claude Codeに「自己ホスト型実行環境（self-hosted environments）」が公開ベータで追加された。Team/Enterpriseプランで、クラウドセッションを組織自身のネットワーク内サーバーで実行できるようになり、リポジトリのチェックアウトやビルド成果物、シークレット、セッションが作成・変更したファイルを組織側の管理下に留められる。院内ネットワークからの外部送信に慎重な医療機関にとって、これはClaude Code導入検討のハードルを下げる材料になる。
- 要点1：self-hosted environmentsは
claude self-hosted-runnerというコマンド一つで、組織が用意したマシンやコンテナをClaude Codeの実行レイヤーにできる（2026年8月3〜7日のWeek 32アップデート、code.claude.com公式ドキュメント記載）。 - 要点2：院内の電子カルテ関連システムや医事会計システムのようにネットワーク境界が厳格な開発対象でも、Web・モバイル・デスクトップ・ターミナル・スケジュール実行のどこから起動したセッションでも、組織のネットワーク内で実行される設計になっている。
- 要点3：ただしこの機能自体は「実行場所」を組織内に持ち込む仕組みであり、医療情報システムのコンプライアンス適合そのものを保証するものではない。適合判断は各医療機関の情報システム部門・コンプライアンス部門が個別に行う必要がある。
対象読者：医療機関・医療系SaaSベンダーのエンジニア、情報システム部門、導入検討中のPM・経営企画
今日やること：自組織のネットワーク要件を洗い出し、self-hosted environmentsのベータ申込対象になるか（Team/Enterpriseプラン契約有無）を確認する
事例区分：想定シナリオ
以下は、2026年8月に公開ベータとなったClaude Codeの自己ホスト型実行環境という実在の機能をもとに、医療機関の院内システム開発チームが直面しやすい課題と実装パターンを一般化して構成したモデルケースです。実在の特定医療機関の導入事例ではありません。数値は「想定効果」として試算値を示しています。
「Claude Codeを使いたいけど、うちは院内ネットワークの外にコードを一切出せないんです」
医療系の受託開発やSIerのエンジニアと話していると、正直、この相談が本当に多いんです。電子カルテ本体を触るわけじゃなくても、周辺の医事会計連携ツールや院内向けの業務効率化スクリプトを作るだけでも、情報システム部門の審査で「クラウドAIツールは外部送信の懸念があるので不可」と一蹴されるケースをよく聞きます。Claude Codeのクラウドセッションは便利な一方、ソースコードや設定ファイルの断片が一時的にAnthropicのインフラを経由する構成だったため、この手の相談に対しては「オンプレでLLMを動かすしかないですね」という重い提案しかできませんでした。
この状況が、2026年8月のアップデートで少し変わりました。Claude Codeの自己ホスト型実行環境（self-hosted environments）が公開ベータになり、クラウドセッションの実行場所そのものを組織のネットワーク内に持ち込めるようになったからです。この記事では、院内ネットワーク限定の開発体制をこの新機能で構築する実装パターンを、想定シナリオとして具体的に見ていきます。
2026年8月現在のスナップショット：Claude Codeの自己ホスト型実行環境
まず前提を正確に押さえておきます。Anthropic公式のClaude Codeドキュメント「What’s new」Week 32（2026年8月3〜7日、対象バージョン v2.1.220〜v2.1.224）によると、この週のアップデートで発表されたのは以下の3点です。
- クロスセッション通信：macOS/Linuxで複数のClaude Codeセッションが相互にメッセージを送れるようになった
- 自己ホスト型実行環境（self-hosted environments）：クラウドセッションを組織が運用するインフラ上で実行できる機能が、Team/Enterpriseプラン向けに公開ベータで提供開始
- オートモードのデフォルト化：Pro/Max/Teamプランの新規セッションで、2026年8月14日からオートモード（権限確認を分類器が肩代わりする権限モード）がデフォルトになった
自己ホスト型実行環境の具体的な仕組みは、Web・モバイル・デスクトップ・ターミナル・スケジュール実行のいずれから起動したセッションでも、組織のネットワーク内部（内部サービス・ツールチェーン・セキュリティ統制のそば）で実行される、というものです。リポジトリのチェックアウト、ビルド成果物、シークレット、セッションが作成・変更したファイルは、組織が用意したマシン上に留まります。導入はclaude self-hosted-runnerという単一コマンドで、手元のマシンやコンテナをClaude Codeの実行レイヤーに変える形です（初期状態ではオフで、明示的に有効化する必要があります）。
正直にお伝えすると、この記事執筆時点（2026年8月16日）でこの機能はまだ公開ベータです。医療機関の情報システム部門が求める水準の第三者監査やSOC2的な統制文書がベータ段階でどこまで揃っているかは、公式ドキュメント上では明言されていません。「オンプレだから安全」と単純化せず、導入検討時は必ず自組織のセキュリティ・コンプライアンス部門とAnthropicの営業窓口の双方に確認してください。
導入前の状況：院内ネットワーク限定という制約
想定する開発チームは、地域の中規模病院（病床数300〜500床規模を想定）向けに、医事会計システムと連携する院内業務効率化ツール群を開発している内製エンジニアチーム、という設定です。開発対象は電子カルテ本体ではなく、外来受付の待ち時間案内システムや、部門システム間のデータ連携バッチ、院内向け問い合わせ対応ツールといった周辺システムです。
それでも、開発環境が扱うテストデータには患者IDや診療科コードなど、匿名化が不十分だと個人情報保護法上の懸念が生じうる項目が含まれます。厚生労働省の医療情報システムに関するガイドライン群でも、外部への情報送信を伴う仕組みの導入時には情報システム部門の事前確認が求められるのが一般的で、この病院でもクラウドAIツールの導入は情報システム部門の審査対象でした。Claude Codeのクラウドセッションをそのまま使う提案は、審査の初期段階で「外部インフラを経由する構成である」という理由で保留になっていました。
審査担当者から出た懸念は主に3つでした。
- 開発中のソースコードやビルドログが、院内ネットワークの外（Anthropicのインフラ）を経由する
- テスト用の擬似データであっても、外部に一時的にでも送信されることへの心理的抵抗が院内で強い
- 監査対応のとき「どこでコードが実行されたか」を明確に説明できる資料がなかった
Claude Codeの役割：自己ホスト型実行環境での実装パターン
self-hosted environmentsを使うことで、上記3点への回答方針をこう組み立てました。
- 実行基盤の院内配置 — 院内ネットワークのDMZ内に管理用の仮想マシンを1台用意し、
claude self-hosted-runnerで実行レイヤーとして登録。Claude Codeセッションはこのマシン上でコードを実行する。 - リポジトリ・シークレット管理 — Gitリポジトリは院内のGitLabサーバーに置いたまま、self-hosted runnerからのみアクセス可能にする。DB接続情報などのシークレットも、外部に持ち出さず院内のシークレットマネージャーで管理する。
- セッション起動経路の制限 — 開発者がデスクトップ版・ターミナル版のどちらからセッションを開始しても、実行自体は院内runnerに固定されるよう設定し、Web版からの起動は許可しない運用にする。
- 監査ログの整備 — どのセッションが、いつ、どのファイルに触れたかを追える形で院内runner側のログを保存し、情報システム部門の定期監査に提出できる状態にする。
- 段階的な対象範囲の拡大 — 最初から電子カルテ周辺の全システムに広げず、患者情報を直接扱わない社内向けツールから着手する。
実際に使ったプロンプトの一部を紹介します（いずれも本番データではなく、匿名化済みのテスト用ダミーデータを対象にした指示です）。
院内向け問い合わせ対応ツールのFAQ検索ロジックを実装してください。
対象は /app/faq_search.py です。
検索対象はダミーの院内FAQデータ（tests/fixtures/faq_dummy.json）のみで、
患者情報や実データには一切アクセスしないでください。
不足している情報があれば、最初に質問してから作業を開始してください。部門システム間のデータ連携バッチについて、エラー時のリトライ処理を追加してください。
対象システムは検査部門システムと医事会計システムの連携部分です。
接続先の情報は環境変数から読み込む設計にし、
接続文字列やAPIキーをコードやログに直接出力しないでください。
仮定した点は必ず"仮定"と明記してください。外来受付の待ち時間案内システムのUIバグを調査してください。
再現手順: 患者ダミーID D-0001 で受付登録すると待ち時間表示が0分のまま更新されない。
デバッグ用のログ出力を追加する場合は、患者を特定できる情報を含めないでください。self-hosted runner上で実行しているセッションのログから、
直近1週間でアクセスされたファイル一覧をレポートしてください。
監査提出用に、ファイルパスと日時のみを抽出し、ファイル内容は含めないでください。医事会計連携バッチのコードレビューをしてください。
特に、外部通信が発生する箇所（HTTPリクエスト・DB接続・ファイル送信）を洗い出し、
それぞれの通信先が院内ネットワーク内に限定されているか一覧化してください。
不明な通信先があれば、断定せず「要確認」として報告してください。実装スタック
| レイヤー | 構成 |
|---|---|
| 実行環境 | 院内DMZ内の管理用VM（Claude Code self-hosted-runner） |
| ソース管理 | 院内GitLabサーバー（外部公開なし） |
| シークレット管理 | 院内シークレットマネージャー（環境変数経由で注入） |
| 開発クライアント | Claude Codeデスクトップ／ターミナル（Web版からの起動は不可設定） |
| 監査ログ保存 | 院内runnerのアクセスログをSIEMへ転送 |
段階的導入のロードマップ（想定）
Phase 1（1〜2ヶ月）：患者情報を扱わない社内向けツール（院内FAQ検索、勤怠関連の業務ツール等）から self-hosted environments を試験導入。情報システム部門と合同でログ・監査運用を確立する。
Phase 2（3〜4ヶ月）：部門システム間のデータ連携バッチなど、患者IDを扱うが直接の診療行為には関わらない領域へ拡大。プロンプト運用ルール（患者特定情報をログに出力しない等）をチームに周知する。
Phase 3（5〜8ヶ月）：電子カルテ本体に近い領域への適用可否を、情報システム部門・コンプライアンス部門と改めて協議。この段階の可否は病院ごとの規程次第であり、一律に「進める」とは言えない。
想定効果
以下は実測ではなく、想定シナリオに基づく試算値です。実際の効果は組織のシステム構成・開発体制によって大きく変わります。
| 指標 | 導入前（想定） | 導入後（想定） | 備考 |
|---|---|---|---|
| クラウドAIツール導入の審査期間 | 不承認・保留のまま数ヶ月停滞 | Phase 1着手まで1〜2ヶ月 | 実行場所の説明がしやすくなったことによる想定短縮 |
| 院内向けツールの開発リードタイム | 手動実装中心 | Claude Code併用 | 具体的な短縮率は組織・タスクにより異なるため本記事では数値化しない |
| 監査提出資料の準備 | 実行場所の説明資料なし | runnerログをそのまま監査資料に転用 | 準備工数の削減効果は未測定 |
【要注意】よくある失敗パターンと回避策
失敗1：self-hosted environments＝コンプライアンス対応済み、と誤解する
❌「院内で実行されるから、個人情報保護法や医療情報ガイドライン上の懸念はすべて解消した」
⭕「実行場所が院内に閉じることと、組織の情報セキュリティ規程・各種ガイドラインへの適合は別問題。self-hosted environmentsはあくまで技術的な選択肢の一つで、適合判断は情報システム部門・コンプライアンス部門が個別に行う」
なぜこれが重要か：2026年8月時点で公開ベータの機能であり、第三者認証の取得状況などは公式発表で明言されていません。「オンプレだから安全」と対外的に断定するのは避けるべきです。
失敗2：最初から電子カルテ本体を対象にする
❌「self-hosted environmentsがあるから、いきなり電子カルテ本体の開発にClaude Codeを使う」
⭕「患者情報に直接触れない周辺システムから段階的に対象を広げる」
なぜこれが重要か：新しい実行方式の運用ノウハウが院内に蓄積されていない段階でリスクの高い領域に踏み込むと、トラブル時の切り分けが難しくなります。
失敗3：Web版からの起動経路を制限し忘れる
❌「self-hosted-runnerを設定したから、どのクライアントから起動しても安全なはず」
⭕「起動経路（Web・デスクトップ・ターミナル・スケジュール実行）ごとに、実行先が院内runnerに固定されているかを個別に確認・設定する」
なぜこれが重要か：設定漏れがあると、一部のセッションだけAnthropicのクラウド側で実行されてしまう可能性があり、想定していた統制が崩れます。
失敗4：監査ログの保存期間・粒度を決めずに運用開始する
❌「とりあえずrunnerを動かして、ログは後で考える」
⭕「情報システム部門の監査要件（保存期間・粒度・アクセス権限）を先に確認してからログ設計する」
なぜこれが重要か：医療機関の監査要件は一般企業より厳格なことが多く、後からログ設計をやり直すコストは小さくありません。
適用余地のある業界・規模
この実装パターンは、院内ネットワークに限らず、外部へのコード送信に慎重な業界全般に応用できます。金融機関のバックオフィスシステム開発、官公庁・自治体の内部システム、製造業の工場内ネットワーク（OTネットワーク）に閉じた開発などが典型例です。共通するのは「実行場所を組織内に留めたい」というニーズであり、self-hosted environmentsはこの種の調達ハードルを下げる技術的な選択肢になり得ます。ただし、いずれの業界でも「実行場所が閉じている＝規制対応済み」という短絡は避け、各業界の個別規程に照らした確認が必要です。
よくある質問（FAQ）
Q1. self-hosted environmentsは無料で使えますか？
A. 2026年8月時点で、TeamプランとEnterpriseプランでの公開ベータ提供です。料金体系の詳細はAnthropicの営業窓口・公式ドキュメントで最新情報を確認してください。
Q2. 電子カルテシステム本体の開発にそのまま使えますか？
A. 技術的には実行場所を院内に閉じられますが、電子カルテ本体への適用可否は各医療機関の情報セキュリティ規程・コンプライアンス部門の判断によります。本記事のロードマップでも、電子カルテ本体への適用は最終フェーズかつ「協議が必要」という位置づけにしています。
Q3. self-hosted environmentsとオンプレミスLLMの違いは何ですか？
A. self-hosted environmentsは「実行の場所」を組織内に持ち込む仕組みで、モデル自体はAnthropicが提供するClaude系モデルを使います。モデル本体まで完全に自組織内で動かす完全オンプレミス構成とは異なります。この違いは調達検討時に必ず区別してください。
Q4. 導入にはどのくらいの技術的な準備が必要ですか？
A. 公式ドキュメントによればclaude self-hosted-runnerという単一コマンドでマシンやコンテナを実行レイヤーに変えられます。ただし、院内ネットワークのDMZ設計やシークレット管理、監査ログ整備といった周辺の設計・調整には相応の準備期間が必要です。
Q5. 監査ログはどこまで自動化できますか？
A. self-hosted-runner側のアクセスログをSIEM等に転送する構成自体は一般的なインフラ設計で対応可能です。ただし監査要件を満たすログの粒度・保存期間の設計は組織ごとに異なるため、情報システム部門と個別に詰める必要があります。
まとめ：今日から始める3つのアクション
- 今日やること：自組織がClaude CodeのTeam/Enterpriseプランを契約しているか、self-hosted environmentsのベータ対象になっているかを確認する
- 今週中：情報システム部門と、外部送信の懸念がある開発対象・懸念がない開発対象を棚卸しし、Phase 1の対象範囲を決める
- 今月中：監査ログの保存要件（保存期間・粒度・アクセス権限）を情報システム部門とすり合わせ、runner導入前に設計を固める
—
次回予告：次の記事では、self-hosted environmentsを金融機関の与信審査バッチ開発に適用した想定シナリオを、監査ログAPIとの組み合わせも含めて取り上げます。
—
参照・出典
- Claude Code Docs「What’s new」Week 32（2026年8月3〜7日） — self-hosted environments公開ベータ、オートモードのデフォルト化（2026年8月14日）を公式発表（参照日: 2026-08-16）
- Anthropic「Claude for Financial Services」 — 規制業界におけるClaude Code活用の背景事例（公開日: 2025-07-15、参照日: 2026-08-16）
- TechCrunch「Anthropic is turning Claude Code’s auto mode on by default」（公開日: 2026-08-09、参照日: 2026-08-16）
あわせて読みたい
- 【2026年最新】Claude Codeセルフホスト実行ガイド｜4ステップ — self-hosted-runnerの技術的なセットアップ手順を、業界を問わず解説した基礎ガイド
- 【医療】電子カルテのサマリ生成をClaude Codeで実装した事例｜HIPAA配慮の安全設計【2026】 — 医療分野でClaude Codeを扱う際の安全設計の考え方を、別タスクの実装事例で解説
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
