投稿者: 縁際誠(えんぎわまこと)

  • OpenDolphin 構築ログ:WildFly, PostgreSQL, クライアント接続

    電子カルテクライアントが “沈黙” した原因と、接続成功までのすべて

    本記事は、私が OpenDolphin(2.7系)を自前環境で構築するという目的で行った作業と、その過程で遭遇した“接続しないクライアント問題”を、最初から最後まで一切省略せずに記録した技術ログである。

    「OpenDolphin を触るのが初めての人」
    「評価版クライアントでハマった人」
    「WildFly で動かしたい人」

    そうした方々の参考になれば幸いである。

    ただし、オープンソースである電子カルテ「OpenDolphin」は開発を終了している。現在は  株式会社メドレーが事業を承継し、開発・サポートを行っている


    1. 作業開始:OpenDolphin を「まず動かす」ことを目標に設定

    今回の PoC の目的はシンプルだった。

    • OpenDolphin の仕組みを理解する
    • 自前で構築したAWS上のWindowsServer2022に載せたい
    • クライアントが自前サーバに接続する流れを確認したい

    そのために、まずは OS 上に単純な構成を置いた。

    使用環境

    • Windows Server 2022(両方検証)
    • Java(OpenJDK 8)
    • WildFly
    • PostgreSQL
    • 評価版クライアント(2.7.1 とされる ZIPをGitHubからダウンロードした)

    「公式手順」を参考にしながら、“できるだけ純粋な構成に近い状態” を作ることを意識した。


    2. WildFly をインストールして起動する

    2.1 まず WildFly を入手

    ダウンロードサイト:https://adoptium.net/temurin/releases/?version=8

    OpenDolphin 2.7 系で最も安定なのは WildFly 10 〜 11 です

    2.2 配置

    C:\WildFly\wildfly-26.1.3.Final

    に展開。

    2.2 起動

    cd C:\WildFly\wildfly-26.1.3.Final\bin
    standalone.bat
    

    WildFly が 8080 で起動することを確認。

    ここまでは順調。


    3. PostgreSQL を準備する

    今回の OpenDolphin は、内部的に PostgreSQL を想定している。すでに過去の電子カルテサーバでPostgresql8.4をインストールしていたため、そちらを使用した。

    3.1 DB 作成

    DB名       : dolphin
    ユーザー名 : dolphin
    パスワード : 任意

    3.2 初期データ投入(最低限)

    OpenDolphin の認証にはテーブルが必要。

    デプロイが正常終了後に初期データを投入してください

    INSERT INTO d_facility
    INSERT INTO d_users
    INSERT INTO d_roles
    

    これで「サーバ側は動く状態」が整った。

    3.3 Postgresql JDBCドライバ設定

    ①pgjdbc (PostgreSQL JDBC Driver) を入手

    ダウンロードサイト:https://jdbc.postgresql.org/download/

    PostgreSQL 8.4 なら JDBC Driver 42.x 系でも基本動作します。


    ②WildFly の module として配置

    以下にディレクトリを作成:

    C:\wildfly-10\modules\org\postgresql\main

    配置するファイル:

    • postgresql-42.7.1.jar
    • module.xml

    ③module.xml の作成

    <?xml version="1.0" encoding="UTF-8"?>
    <module xmlns="urn:jboss:module:1.3" name="org.postgresql">
        <resources>
            <resource-root path="postgresql-42.7.3.jar"/>
        </resources>
        <dependencies>
            <module name="javax.api"/>
            <module name="javax.transaction.api"/>
        </dependencies>
    </module>
    ※ resource-root path= のファイル名は、実際に置いた JAR 名に合わせてください。

    ④参照先DBの設定(WildFlyのStandalone.xmlにDataSource設定)

    C:\wildfly-10\standalone\configuration\standalone.xml を編集します。

    <drivers> の中に JDBC ドライバ登録

    <driver name="postgresql" module="org.postgresql">
        <driver-class>org.postgresql.Driver</driver-class>
    </driver>

    <datasources> に DataSource を追加

    <datasource jndi-name="java:/jdbc/dolphinDS" pool-name="dolphinDS">
        <connection-url>jdbc:postgresql://localhost:5433/dolphin</connection-url>
        <driver-class>org.postgresql.Driver</driver-class>
        <driver>postgresql</driver>
        <security>
            <user-name>dolphin</user-name>
            <password>*****</password>
        </security>
    </datasource>

    ⑤WildFly を再起動して DataSource をテスト

    standalone.batを起動して、エラーが出ていないことを確認します。エラーがある場合は、Postgresqlドライバが認識されていないか、Standalone.xmlの記述に誤りがある状態です。

    4. dolphin.war の配置とデプロイ

    GitHubからOpenDolphinをCloneしOpenDolphinのサーバファイル(warファイル)をBuildします。Buildしたwarファイルを、わかりやすい名前(例:dolphin.war)に変更して、WildFly のdeployments へコピー。

    C:\WildFly\wildfly-26.1.3.Final\standalone\deployments\

    その後、WildFlyを再起動すると、.deployed ファイル生成 され、WildFly ログで “Deployed dolphin.war” が確認できるれば、サーバ側の起動は問題なし。もし、deployファイルが作成されていない場合は、deployファイルが作成されるまでトラブルシューティングしてください

    自分自身が経験したBuildエラートラブルです

    ①postgresql-9.2-1002.jdbc4.jarをext_libにコピーして再Build

    理由:OpenDolphinのソースがPostgresql9.2のJDBCを参照していたため

    こちらでいったんBuildは正常

    このあと、デプロイしてもfailedだけが作成し続け、deployedを作成するまで苦労しました

    ②OpenDolphinが期待しているDataSource名ではない
    以下のようにPostgresDSというDataSourceを追加した

    <datasources>
        <!-- 既存の ExampleDS は残しておいて構いません -->
    
        <datasource jndi-name="java:jboss/datasources/PostgresDS"
                    pool-name="PostgresDS"
                    enabled="true"
                    use-java-context="true">
            <connection-url>jdbc:postgresql://localhost:5433/dolphin</connection-url>
            <driver>postgresql</driver>
            <security>
                <user-name>dolphin</user-name>
                <password>*****</password>
            </security>
        </datasource>
    
        <drivers>
            <driver name="h2" module="com.h2database.h2">
                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
            </driver>
            <driver name="postgresql" module="org.postgresql">
                <driver-class>org.postgresql.Driver</driver-class>
            </driver>
        </drivers>
    </datasources>

    ③Standalone.xml内のJPA のデフォルトデータソースが 空(“”) だった

    <subsystem xmlns="urn:jboss:domain:jpa:1.1">
        <jpa default-datasource="java:jboss/datasources/PostgresDS"
             default-extended-persistence-inheritance="DEEP"/>
    </subsystem>

    ④ClassNotFoundException

    failedの中を確認すると、ClassNotFoundException: Could not load requested class : org.hibernate.type.StringClobTypeというエラーが出ていた

    OpenDolphinのソースを全検索して

    @Type(type=”org.hibernate.type.StringClobType”)

    の行を

    @Type(type=”org.hibernate.type.StringType”)

    に変更して再Build、再デプロイ

    ⑤NullPointer Exceptionエラー

    failedの中を確認すると、jboss.deployment.unit.”opendolphin-server-2.7.1.war”.component.PvtService.START … EJBException: NullPointerExceptionというエラーが出ていた

    解決として、

    C:\wildfly-10.1.0.Final\custom.properties

    というテキストファイルを作成します。

    最低限、ファイルの中身には、

    # OpenDolphin basic settings
    
    # 医療機関ID(DBに入れる予定の facilityId と合わせる想定)
    dolphin.facilityId=1.3.6.1.4.1.9414.70.1
    
    # ORCA連携用(今はダミーでOK)
    claim.host=localhost
    claim.port=8000
    claim.user=ormaster
    claim.password=ormaster
    
    # ログレベルなど(あってもなくてもよいが、一応)
    dolphin.logLevel=WARN

    と記述します

    standalone.xml<subsystem xmlns="urn:jboss:domain:logging:…"> の中には、以下の内容を記述しておきます(念のため)

    <logger category="open.dolphin">
        <level name="WARN"/>
    </logger>
    <logger category="dolphin.claim">
        <level name="WARN"/>
    </logger>
    

    この後、再デプロイして確認します

    こちらを行って、サーバは正常起動しました


    5. ここからさらに問題発生:クライアントが“完全に沈黙”

    5.1 初期データをDBに投入

    この時点で、OpenDolphinのテーブルは作成されているはずです。クライアント接続に必要な認証データを投入してください

    5.2 クライアントアプリを作成する

    サーバアプリをBuildしたように、OpenDolphinのソースからクライアントアプリケーションをBuildします

    5.3 クライアントアプリを実行する

    コマンドラインから

    java -jar OpenDolphi

    しかし、トラブル発生。ログイン画面が出る。しかし・・

    • WildFly には 1 つもリクエストが来ない
    • PostgreSQL 側にもクエリが飛ばない
    • クライアントには「接続できない」というエラーすら出ない
    • ログインしても無反応(沈黙)

    この時点で、サーバ側が悪いのか、クライアント側が悪いのか、判断がつかない。


    6. 切り分け開始:「サーバは問題ない」ことを確認

    まずサーバ側を確認した。

    • dolphin.war は正しく起動
    • WildFly ログには deploy エラーなし
    • PostgreSQL も正常に接続可能
    • DB 初期データも投入済み

    つまり サーバ側は正常

    ではなぜ接続が来ない?


    7. 次の仮説:

    「クライアントは接続先 URL が固定されているのでは?」

    ここで、OpenDolphin は接続先サーバが固定されているのでは?と疑い始める。

    実際、世の中には

    • クラウド用に URL を固定したビルド
    • 体験版として接続先変更不可のもの

    が存在する。

    このOpenDolphinクライアントも、その可能性が十分ある、と思った


    8. 設定画面を開く → 一見変更できそうだが、保存されない

    クライアント右下の [設定] を開いたところ、
    「サーバ」「スキーマ」「ポート」といった項目が並んでいた。

    しかもサーバの項目は、test.open.dolphinがデフォルト

    設定変更できる雰囲気がある。

    ところが:

    • http://localhost:8080 と入力 → 保存 → 値が消えている
    • http://192.168.10.5:8080 → 保存 → 消える
    • /dolphin を書いてみる → 保存 → 消える
    • localhost を書いてみる → 保存 → 消える
    • 127.0.0.1 を書いてみる → 保存 → 消える

    これは、設定項目が「見せかけ」で実際には固定 URL に接続しているのでは?
    という疑惑が深まっていく。

    ここでしばらく時間を消費した。


    9. hosts ファイルで出口を書き換える案(緊急回避策)

    万が一、本当に URL が固定なら、

    C:\Windows\System32\drivers\etc\hosts

    で名前解決を書き換えれば、
    強制的に自前サーバへ誘導できる

    しかし、

    • 固定 URL かどうかの確証がない
    • これは「根本解決ではない」

    ため、一時保留とした。


    10. さらに試行錯誤:クライアントを自前ビルドする案

    GitHub 上の OpenDolphin 2.7m(猪俣先生開発版?)のソースを clone し、クライアントだけ自前ビルドして差し替える案も検討した。本来、サーバもBuildしなおす必要があるかもしれないが、時間を割きたくないのでいったんクライアントだけ。


    11. 決定的瞬間:

    すると、サーバの設定ができた共に、正しい設定の仕方が偶然わかった

    設定画面をもう一度よく見ると、
    項目は次のように分かれている。

    項目入れるもの
    スキーマhttp / https
    サーバホスト名または IP だけ
    ポート数字だけ(例:8080)

    ここで気づいた。

    サーバ欄に “http://” や “:8080” を入れてはいけない。
    純粋なホスト名だけを書く仕様だった。

    つまり、正しい入力はこう:

    正しい例

    スキーマ:http
    サーバ:127.0.0.1
    ポート:8080

    正しくない例(保存されず消える)

    サーバ:http://localhost:8080
    サーバ:localhost:8080
    サーバ:http://192.168.x.x/dolphin
    

    これがすべての原因だった。


    12. 正しく設定して保存 → 接続成功!

    サーバ欄を 127.0.0.1のみにし、
    ポート欄に 8080 を入力して保存。

    期待半分、不安半分でログインボタンを押す。

    WildFly ログを見ると──

    POST /dolphin/login
    200 OK

    来た。初めてクライアントが喋った。

    沈黙状態が続いていたOpenDolphinクライアントが、ようやく自前サーバに接続を開始した。

    結局、当初BuildしていたOpenDolphinのソースは、サーバをDockerで構築する簡易版だったのかもしれない(推測)

    OpenDolphin 2.7mでBuildしたクライアントアプリで電子カルテを操作してみようと思う。もしかしたら、サーバも再構築する必要があるかもしれないが、問題があった時に対応するつもり。


    13. hosts の修正は不要に

    hosts 書き換え案は不要となり、即座に元に戻した。


    14. clone した OpenDolphin ソースの扱い

    clone していたソースは、

    • WildFly に影響なし
    • クライアント実行にも影響なし
    • 今後ビルドするなら Work に移動すればよい
    • 使わないなら削除して OK

    という結論に達した。


    15. 結果:

    この環境で OpenDolphin は問題なく動作する

    サーバ:WildFly
    DB:PostgreSQL

    という構成で、OpenDolphin の認証と画面まで通った。

    「クライアントは URL 固定されている」という疑いは誤りで、
    真の原因は 設定画面の入力仕様の誤解 だった。


    16. 今回の学び(技術的教訓)

    1. OpenDolphin クライアントの設定項目は“URL”ではなく“サーバ名””IPアドレス”を入れる欄である。
    2. プロトコル(http)とポート(8080)は別欄で指定する。
    3. WildFly 側が正常でも、クライアントが正しく設定されていなければ完全沈黙する。
    4. hosts 書き換え案は“最終手段”であり、本質的な解決ではなかった。
    5. 結局のところOpenDolphin 2.7mでクライアントは再Buildしただけで、いったんはサーバ再構築は不要でした。ただ、設定の仕方が問題の核心であることもわかりました。
  • 昔開発した電子カルテアプリを AWS 上で復元し、リモートDB接続するまでの全手順まとめ

    この記事は、2000年代の旧電子カルテアプリを AWS 上で再構築し、Windows2000の VM から リモートで PostgreSQL に接続するところまで成功した技術ログです。

    成功・失敗・試行錯誤すべてを “備忘録として残す” 目的でまとめています。


    1. 目的

    • 旧電子カルテ(Windows2000 + PostgreSQL)の環境を検証目的で復元したい
    • AWS 上に Windows Server を構築し、DB を立ち上げる
    • Windows2000(VM)の電カルアプリから リモートで DB に接続できるか検証
    • できればアプリも起動させたい
    • 最終的には DB を別用途で使えるようにすること

    2. AWS 側の構築

    ■ Windows Server 2022 を EC2 で構築

    • インスタンスタイプ:最初 t3.medium
    • ElasticIP:今回は 使用しない(検証環境のため割り切り)

    ■ ネットワーク設定

    • セキュリティグループで PostgreSQL ポート(5433)を開放
    • ただし 自分のグローバルIP のみに限定
      (→ リスク最小限でパブリックIP接続を許可)

    3. PostgreSQL 8.x の構築

    ■ 3-1. PostgreSQL 8.2 → インストールエラー

    管理者実行トラブル等あり断念

    ■ 3-2. PostgreSQL 8.4 で再構築

    安定して動作。

    ■ 設定(postgresql.conf)

    listen_addresses = '*'
    port = 5433
    

    ■ pg_hba.conf

    host all all 127.0.0.1/32 md5
    host all all <自分のグローバルIP>/32 trust
    

    AWS 内でも psql による接続確認:

    .\psql.exe -h 127.0.0.1 -p 5433 -U postgres
    → 接続成功
    

    DB が正常に起動していることを確認。


    4. Windows2000(VM)からのリモート接続テスト

    ここが今回の記事の中心となる「成功ポイント」。


    4-1. 電カル側の接続先を AWS のパブリックIP に変更

    開発した電子カルテは起動時のログイン画面で DB 認証を行うため、
    以下を設定:

    Server = <AWSのパブリックIP>
    Port = 5433
    User = postgres(または設定したアカウント)
    

    4-2. セキュリティグループで 5433 を “自分のIP のみ許可” に設定

    → 全世界に開くことはせず、
     検証用途として最低限のリスクに限定


    4-3. リモート接続結果 → 成功!

    Windows2000 上で電カルを起動すると:

    • ログイン画面が出現
    • 認証成功
    • DBと正常通信を開始

    つまり、

    Windows2000(VM) → AWS PostgreSQL(パブリックIP)

    という「リモートDB接続」に成功した。**

    これは今回の大きな成果。


    5. SSHポートフォワード方式も検証(結果:不採用)

    ■ 5-1. ホストPC から PowerShell で SSHトンネルを作成

    ssh -L 5433:127.0.0.1:5433 <AWSユーザー>@<EC2 Public IP>
    

    ■ 5-2. トンネル自体は成功(netstat の LISTENING も確認)

    Win2000 からの telnet も通った。

    ■ 5-3. しかし電カルアプリは DB に接続できず

    原因は複合的:

    • Windows2000 の TCP/IP スタックが現代 SSH トンネルと相性悪い
    • ODBC/INI の参照位置が複雑
    • VM の NAT → Host-only のルーティング
      など。

    結論:
    パブリックIP で接続できていれば、SSH トンネルにこだわる必要はない。

    今回の目的の範囲では“不採用”と判断。


    6. 電カルアプリ起動結果

    • ログイン:成功(リモートDB接続成功の証拠)
    • メイン画面:表示されるが ストアドプロシージャの互換性エラー多発
      • 電子カルテアプリのロジックが DB(PostgreSQL 8.4)に依存
      • 古い関数や PL/pgSQL の仕様変更で動作不可

    アプリとしての実用は困難 と判断。


    7. 今後に向けて

    • 医療DBの構造分析研究
    • FHIRリソースへのマッピング研究
    • データ移行の検証
    • システム設計の参考資料
      として活用していこうと思う

    8. まとめ(今回得た成果)

    電カル → AWSリモートDB接続に成功(パブリックIP経由)

    ✔ 電カルアプリ起動までは再現できた

    ✔ DBは完全に生きており、別用途で利用する予定

    ✔ SSHトンネルは技術的には張れたが、旧OSとの相性で実用不可

    ✔ 検証としては十分以上の成功

  • 診療所と大病院のあいだで揺れる患者──紹介の“行間”に潜む医師の本音

    日本の医療は「地域完結型医療」「役割分担」「医療連携」がキーワードとして語られて久しい。
    しかし現場に身を置いていると、その理念の裏にある“行間”が、患者を静かに疲弊させているのを感じる。

    今日、総合病院の耳鼻科を受診した。
    数ヶ月前にもかかっていて、そのときは症状も落ち着いていたため「診療所で経過観察してください」と言われ、一度役割が診療所へと戻った。

    その後、診療所で再び診察を受け、検査をするとわずかだが病変が見つかり、
    診療所は「これは診られない」と判断して再び病院へ紹介状を書いた。

    そして今日、病院で検査を受けた結果は
    「今のところ心配ない。診療所で経過観察してよい」
    というものだった。

    頭では理解している。
    診療所では行えない高度な検査がある。
    病院は重症患者を優先したい。
    紹介は悪いことではない。
    安全のための仕組みなのだ。

    だが、患者として往復する身からすると、
    “この揺さぶられる感じ” は決して小さくない。

    ■ 大病院の医師がこぼした、ほんの一言

    診察の時間に、私は経緯を丁寧に説明した。
    診療所 → 病院(初回) → 診療所 → 病院(今回)
    という往復があったことを。

    すると病院医師が、少しだけ声を落として言った。

    「この先生は、すぐ紹介するタイプだね」

    たった一言だった。
    けれどその後ろにある医師の本音が、ふっと見えた気がした。

    • 診療所でフォローできるレベルなのに病院に回してくる
    • 軽症の患者で外来枠が圧迫される
    • しかし角を立てないよう、患者にはやんわり伝える

    医師は本音を直接口にしない。
    代わりに“行間”で語る。

    その空気を感じ取った瞬間、
    以前相談したある出来事を思い出した。

    ■ 「診療所にも反省してもらわないと」──紹介状に滲む医師の言葉

    以前、大学病院からの紹介状を紹介先から見せてもらったとき、
    そこにはさりげなく、しかし強いニュアンスを持った一文があった。

    「診療所にも反省してもらう必要があります。」

    もちろん、こんなストレートな書き方はしていない。
    医師のことばはもっと婉曲だ。

    • 「適切な時期にご紹介いただければ」
    • 「必要時には早めにご相談いただけると幸いです」

    こうした一文に、“やんわりとした批判”が込められている。
    医師同士はその行間を読む。
    医学部の六年間で鍛えられた、特有の文脈だ。

    紹介が遅すぎる医師には
    「もっと早く送ってほしい」
    紹介が早すぎる医師には
    「またこのレベルで?」

    そうした感情を、医師は直接言わず、文章の角度で伝える。

    ■ 患者はどこに立たされているのか

    診療所の本音もわかる。

    • 設備的な限界
    • 診断責任の重圧
    • 訴訟への恐れ
    • 少しでも異常があれば「大病院にお願いしたい」という心理

    病院の本音もわかる。

    • 外来は重症者に時間を割きたい
    • 軽症患者で枠が埋まると本来の医療ができない
    • 「診療所で診られる範囲のものは戻してほしい」

    両者の“安全のための判断”が、
    結果として 患者の往復 を生んでしまう。

    診療所 → 病院 → 診療所 → 病院
    主治医がどこなのかわからないまま、
    医師それぞれの“判断の揺れ幅”に揺さぶられる。

    医療者の論理、仕組みの論理は理解できる。
    でも、その隙間にいる患者の身体と心は、
    案外消耗している。

    ■ 医療連携の本当の課題は「役割」ではなく「温度差」

    医療システムは“役割分担”をうたう。
    だが現場で起きているのは、
    役割そのものよりも、医師同士の“温度差”だ。

    • 紹介の基準の違い
    • 診断責任の重さの感じ方の違い
    • リスクに対する耐性の違い
    • 患者にどこまで寄り添うかの違い

    温度差が生む微妙な摩擦が、
    患者の動線にそのまま表れる。

    今日の病院医師の一言、
    紹介状の“反省”という行間、
    それらはすべて同じ構造の上に乗っている。

    ■ 結論:医療者の論理は正しくても、患者の疲労は本物だ

    私は今日、久しぶりにその縮図を体験した。
    そして改めて思った。

    診療所も、病院も、それぞれの立場で「正しいこと」をしている。
    だがその“正しさ”のすき間で、
    患者は静かに揺られ続けている。

    医療が変わるというのは、
    役割分担の再構築だけではなく、
    その揺れをどう埋めるか の議論が必要なのだと思う。

  • AMIコピーから電子カルテ用 Windows Server を再構築する手順(実践録)

    はじめに

    今日は、AWS 上に 電子カルテアプリを載せるための Windows Server を再構築する作業 を行いました。

    元となるサーバはすでに別用途で構築済みで、それを AMIコピーして流用する ところからスタート。
    ただ、コピーしただけではアプリや設定が残ってしまうため、

    「クリーンで、SSM だけで完全管理できる Windows Server テンプレート」

    を作ることを目的に作業しました。

    この記事では、その再構築の流れを記録としてまとめます。


    ■ 1. AMI コピーからの新規 EC2 起動

    まず、既存サーバの AMI をもとに新しいインスタンスを起動しました。

    • インスタンスタイプ:t2.medium
    • セキュリティグループ:インバウンドなし(後でRDP削除)
    • キーペア:既存のものを流用
    • IAM ロール:Systems Manager が動作するロールを再割り当て

    これにより、元サーバと同じ構成をもったインスタンス が立ち上がります。


    ■ 2. コピー元アプリ(RSBASE など)の完全削除

    AMI コピー元には、もともとテスト用途のアプリが入っていたため、
    新しいサーバではこれをすべて削除し、電子カルテ用サーバとしてクリーンにしました。

    • RSBASE のアンインストール
    • 対応フォルダの削除
    • 残存レジストリの確認(不要なものをクリア)

    この時点で、

    “アプリが何も入っていない、空の Windows Server”

    の状態に戻りました。


    ■ 3. ディスク構成の整理(Cドライブ + Dドライブ)

    コピーされたサーバは C:80GB / E:20GB の構成でしたが、
    内容を削除したため E ドライブをフォーマットし、新しい D ドライブとして再構成。

    結果:

    • Cドライブ:80GB
    • Dドライブ:20GB(アプリやログ用に利用)

    ※Cドライブは80GBより縮小できないため、今回は現状維持。

    ここは将来的に「スリム版テンプレート」を作るときに再検討します。


    ■ 4. Session Manager(SSM)が動作しない問題の修復

    AMI コピー直後は SSM Agent がオフライン になっており、
    Session Manager で接続できない状態でした。

    PowerShell で確認すると amazon-ssm-agent.exe がうまく動いていない。

    そこで以下の対処を実施:

    1. TLS 1.2 の有効化
    2. 正式 URL から SSM Agent を再インストール
    3. サービス再起動
    4. IAM ロールの再割り当て確認

    再インストールコマンド例:

    $installer = "$env:TEMP\AmazonSSMAgentSetup.exe"
    Invoke-WebRequest "https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/latest/windows_amd64/AmazonSSMAgentSetup.exe" -OutFile $installer
    Start-Process $installer -ArgumentList "/S" -Wait
    Restart-Service AmazonSSMAgent
    

    これで SSM がオンラインに復帰。
    Session Manager 接続が無事成功しました。


    ■ 5. RDP ポートを完全に閉じる(インバウンド0)

    SSM が動作した時点で、RDP は管理上不要となったため、
    セキュリティグループの 3389 を削除。

    結果:

    • インバウンド完全ゼロ
    • Session Manager のみで管理
    • 医療機関でも安心して使えるセキュア構成

    AWS が推奨する「RDP を開けない運用」が実現しました。


    ■ 6. Session Manager での RDP(ポートフォワード)も同時検証

    必要に応じて RDP を使う場合は、
    Session Manager の ポートフォワード で利用できることも確認。

    例:

    aws ssm start-session \
      --target i-xxxxxxx \
      --document-name AWS-StartPortForwardingSession \
      --parameters '{"portNumber":["3389"],"localPortNumber":["23389"]}'
    

    これにより、

    • EC2 → 3389
    • ローカル → 23389

    のトンネルが張られ、
    localhost:23389 を RDP クライアントに入力すると GUI ログインが可能。

    重要なのは、

    AWS側の設定変更は不要で、ローカルポートを変えるだけで複数サーバへ同時接続できる

    という点。


    ■ 7. 電カル用の “初期 Windows Server AMI” を最終作成

    すべての不要要素を削ぎ落とし、SSMの動作も安定したタイミングで、

    • Windows Update 済み
    • インバウンド0
    • SSMのみで管理可能
    • 余計なアプリなし
    • ディスク整理済み

    という 理想的な“初期テンプレート” の状態が完成。

    この状態を改めて AMI 化し、今後
    電子カルテサーバの標準構築テンプレート
    として利用できるようにしました。


    ■ まとめ

    今回の作業で、

    「爽快なまでに真っさらな Windows Server」
    「SSMのみで完全管理できるセキュア構成」
    「即量産できる初期AMI」

    の3つが完成しました。

    電子カルテ、医療アプリ、オンプレ連携など、
    どんな用途にも適用できる理想的なベースサーバが手に入りました。

    今後は、このテンプレートを軸に構築を加速していきます。

  • 外来が軽症患者で溢れる日本の医療は、どこへ向かうのか

    今朝、急な眼の出血で近くの眼科へ駆け込んだ。
    初めて行くクリニックだったが、症状の緊急性を理解してもらい、
    比較的スムーズに診察に進むことができた。

    だが、この受診の体験と、日頃の自分の職業(医療IT)から見える現場の実態、
    そして中医協(中央社会保険医療協議会)の議論を聴いていると、
    日本の医療が抱える構造的な歪みがどうしても気になってしまう。

    1. 外来は“軽症患者”で溢れ、本来重症を診るべき医療機関の機能が崩れている

    眼科に限らない。
    耳鼻科も、消化器内科も、循環器内科も、
    どこに行っても外来は軽症の患者であふれている。

    • 「目やにが出た気がする」
    • 「ちょっと喉が痛い」
    • 「胸がチクッとした」

    もちろん受診する権利はある。
    だが、“自由にどこへでも受診できる日本の医療” は、
    結果として大学病院でさえ軽症患者でいっぱいになり、
    重症患者が埋もれかねない構造を生んでいる。

    本来、大学病院は:

    • 重症
    • 希少疾患
    • 高度治療が必要な人
    • 地域の医療機関では対応困難な症例

    こうした“濃い症例”だけ集まる場であるはずだ。

    だが現実はまったく逆で、
    大学病院が「便利な総合外来」になってしまっている。

    そりゃ、医療崩壊するよ──
    と感じざるを得ない。


    2. 外来の“軽症依存”が医師の診察の質を奪う

    日本の医師は1日40〜60人を診ることも珍しくない。
    その9割が軽症または一時的症状の患者だ。

    その環境に慣れると、
    医師は“省エネモード”の診療が身につく。

    • パターン化された問診
    • 一般論の説明
    • 深掘りしない病歴聴取
    • 断言しない(できない)説明
    • リスクを避ける言い回し

    でも、私のように眼圧コントロールのある患者が来ると、
    医師は一瞬、空気を変える

    これは医師の表情に出ないようで出る。
    診察モードが切り替わる瞬間は、敏感な患者には分かる。

    逆に言えば、
    普段がいかに“軽症ルーティン診療”になっているかが分かる。

    そしてその切り替わりこそが、

    「本来はもっと深く診れる医師が、日常診療に甘えてしまっている」

    という構造を露呈させる。
    私はその瞬間が少し面白く感じることがある。


    3. 医師が一般論しか言わないのは“防衛本能”でもある

    今の時代、患者はネットで大量の医療情報を持ってくる。
    SNSで医師の発言が拡散される。
    医療訴訟やクレームのリスクも高い。

    だから医師は“断言”できなくなる。

    • 一般論を話す
    • 曖昧になる
    • 深い見立ては控える

    これは医師が悪いわけではない。

    情報過多社会が医師を萎縮させた結果なのだ。


    4. 私がマイナ保険証で情報提供を拒む理由

    私は医療ITを推進する仕事をしているが、
    自分が患者として医療にかかるときは、
    診療情報・薬剤情報を共有しない設定にしている。

    理由は単純。

    医師には、患者から“自分の力で”情報を取りに来てほしいから。

    機微な情報を最初から自動で渡すと、
    問診力が鈍る。

    医師はそのために6年学び、研修し、今も研鑽を積んでいる。
    ITが“医師の力”を奪うのは本末転倒だと私は思っている。

    もちろん、診療の幅を広げるためにITを活用するのは賛成だ。
    でも、ITが医師の思考の代わりになってはいけない。


    5. 中医協を聴くと、日本の医療の未来がますます不安になる

    今日の議論でも繰り返し出ていた。

    • 「医療機関の経営が危ない」
    • 「外来数が減って収益が維持できない」
    • 「地域医療が持たない」

    医療機関が経営不安を抱えれば、
    当然 患者を“数”で集める方向に走る

    するとどうなるか?

    • 外来はさらに軽症患者で埋まる
    • 医師の時間が奪われる
    • 重症患者は十分に診てもらえない
    • 医師はますます萎縮し、一般論しか言わなくなる

    そしてこうして、
    日本の医療は静かに崩れていく。


    6. 私が心配しているのは、“医療の本質が失われていくこと”

    医療は本来、

    • 深い問診
    • 個別の見立て
    • 医師の経験と洞察
    • 患者の背景理解
    • 丁寧な診察プロセス

    これらの積み重ねによって成り立つものだ。

    だが、外来の軽症依存と医療機関の経営不安は、
    医師からこの“本質”を奪っていく。

    そして患者もまた、
    自分が本当に必要とする医療を受けられなくなる。

    いろいろ問題はある。
    でも私は、日本の医療がどこへ向かうのか、本気で心配している。


    ◆ 結び

    今日の眼科受診をきっかけに、
    ずっと胸の中にあった違和感が一つにつながった。

    「このままでは、日本の医療は本来の姿を失う」

    医療ITを推進する立場として、
    そして患者として、
    これからもこの問題を見続けていきたい。

  • WS 上に ORCA(WebORCA)を構築した1日|EC2(Ubuntu)での実践手順とトラブルシューティング

    今日は、AWS 上に ORCA(WebORCA)を構築する作業に取り組みました。
    以前から Windows Server は構築済みでしたが、今回は Ubuntu サーバ上で ORCA をフルインストールし、WebORCA がブラウザから動作するところまで を達成しました。

    AWS と医療システム構築の良い練習にもなり、トラブルもいくつか発生しましたが、結果としてクラウド版 ORCA 環境が完成しました。

    1. 本日のゴール

    • AWS EC2(Ubuntu 22.04)へ ORCA をインストール
    • apt-line・keyring の追加
    • weborca-install によるモジュール導入
    • WebORCA(http://xxx.xxx.xxx.xxx:8000)にブラウザアクセス
    • Elastic IP を割り当てて DNS 化
    • Windows Server(同一VPC)からも疎通確認

    2. 使用した EC2 の構成

    • OS:Ubuntu 22.04 LTS(HVM)
    • インスタンスタイプ:t2.medium
    • ディスク:40GB(後から拡張可能)
    • セキュリティグループ
      • SSH(22):自分のIPのみ
      • 8000:必要なIPのみ後から開放
    • キーペア:新規作成(pem)

    3. インスタンス起動 → SSH ログインまで

    ● キーペア作成時の注意

    PuTTY形式(ppk)は不要。
    PowerShell から直接 SSH で接続できるため pem でOK。

    接続例:

    ssh -i .\mykey.pem ubuntu@ElasticIP
    

    4. ロケール設定

    初期状態では LANG=C.UTF-8 だったため、日本語ロケールへ変更。

    sudo apt update
    sudo apt install language-pack-ja
    sudo update-locale LANG=ja_JP.UTF-8
    

    確認:

    locale
    

    LANG=ja_JP.UTF-8 になっていればOK。


    5. ORCA 用 apt-key(keyring)と apt-line の追加

    ORCA公式の手順書に従う。

    ● Keyring配置

    sudo -i
    wget https://ftp.orca.med.or.jp/pub/ubuntu/archive.key -O /etc/apt/keyrings/jma.asc
    ls /etc/apt/keyrings/
    

    jma.asc が見えれば成功。

    ● apt-line 設定

    cd /etc/apt/sources.list.d/
    wget https://ftp.orca.med.or.jp/pub/ubuntu/jma-receipt-weborca-jammy10.list
    

    6. パッケージ更新

    apt update
    apt dist-upgrade
    

    ここで“GRUB の選択”画面が出たが、そのままデフォルトで進行。
    アップグレード後、以下ログで完了:

    Restarting services...
    No user sessions are running outdated binaries.
    

    7. ORCA(WebORCA)のインストール

    ● 本体インストール

    sudo apt install -y jma-receipt-weborca
    

    ● モジュール導入

    sudo weborca-install
    sudo weborca-install -l
    

    バージョン例:

    MiddleWare 20230117-5
    Compiler   20221216-3
    Application 20230402-1
    

    8. WebORCA 起動確認(最初のトラブル)

    ブラウザで:

    http://10.0.0.37:8000/
    

    Windows Server から開こうとして アクセス不可

    ● 原因

    セキュリティグループが「自分のローカルIPのみ許可」になっていた。

    ● 解決

    インバウンド 8000 に 同じVPCの Windows Server のセキュリティグループを許可


    9. Elastic IP の割り当てと DNS 登録

    • EC2 に Elastic IP をアタッチ
    • お名前.com で Aレコードを作成
    • 反映後、下記URLでアクセス可能に:
    http://(独自ドメイン):8000/
    

    nslookup で疎通確認:

    nslookup your.domain.jp
    

    10. 今日のトラブルと解決方法まとめ

    ① apt-key が非推奨と言われる

    → ORCA公式どおり /etc/apt/keyrings に配置する方式で解決。


    ② GRUBの選択画面が出て驚く

    → Ubuntuの dist-upgrade でよくある挙動。
     既定のままで問題なし。


    ③ WebORCA にアクセスできない

    → セキュリティグループの許可範囲の問題。
     VPC内の Windows Server のIPを明示的に許可。


    ④ PowerShellでSSH接続時にキーペア指定の書式を間違えた

    → 正しい書式:

    ssh -i .\mykey.pem ubuntu@IP
    

    11. 今日得られた成果

    • AWS上で ORCA フル構築が完了
    • Ubuntu / apt-line / keyring の理解が深まった
    • AWS のセキュリティグループ設計を体験
    • ElasticIP+DNS を設定し、医療用システムとして実運用可能な構成へ
    • Windows Server → Ubuntu への疎通確認
    • 実務ではできない自由な実験環境が確立
  • AWS で RSBASE 動作環境を構築した一日:S3・EC2・DNS・AMI までの実録ログ

    今日は、自分が以前運用していた医療用ファイリングソフト「RSBASE」を、AWS 上の Windows Server に構築する作業を進めた。
    ローカルでは長年扱ってきた環境だが、AWS でゼロから構築するとなると、
    S3、IAM、EC2、ストレージ、DNS と幅広い知識が求められ、なかなか濃い一日になった。


    1. S3 バケットの作成とローカル → AWS へのファイル転送

    RSBASE 本体はフォルダ構造が重要で、そのまま EC2 に持っていく必要がある。
    当初は Windows から aws s3 sync を使って直接コピーしようとしたが、
    ディレクトリ構造が崩れてしまう問題が発生

    ▶ Synce失敗例(階層が壊れる)

    aws s3 sync E:\ s3://aws-yasuda-work-bucket-tokyo/installers/
    

    数万ファイルをコピーしたが、
    「リンク」「ショートカット」「一部のディレクトリ」などが乱れ、
    RSBASE のように “素の構造” が命のソフトでは致命的。


    2. 解決策:ZIP 化して S3 へアップロード

    最終的に取った方法はとてもシンプル:

    ✔ 圧縮(ZIP)

    → アップロード
    → EC2 で解凍して配置

    ZIP 化したところ約 3GB にまとまり、確実にコピーできた。

    ▶ アップロードコマンド

    aws s3 cp .\rsbase.zip s3://aws-yasuda-work-bucket-tokyo/installers/
    

    ▶ EC2 側でダウンロード

    aws s3 cp s3://aws-yasuda-work-bucket-tokyo/installers/rsbase.zip .
    

    この方式が一番安定し、S3 の PUT/GET の課金も最小に抑えられる。


    3. EC2 Windows Server のセットアップ

    ✔ IAM ロール(S3 アクセス権)を追加

    途中、Unable to locate credentials が出ることもあったが、
    EC2 の IAM ロールが正しく設定されていれば認証情報は不要。

    ▶ 反映確認コマンド

    aws sts get-caller-identity
    

    結果が以下になっていれば EC2 が IAM ロールを使っている状態:

    "Arn": "arn:aws:sts::<アカウントID>:assumed-role/EC2-SSM-Role/i-xxxxx"
    

    4. EBS 増設(Eドライブ)

    構築開始後に気づいたが、
    初期構成では C ドライブしかなく RSBASE を置くには狭い。
    そこで EBS を 20GB 追加し、Eドライブとして利用。

    手順:

    1. EC2 → ボリューム → 新規作成
    2. 「アタッチ」
    3. Windows でディスク管理 → 初期化 → NTFS でフォーマット

    5. RSBASE の配置と動作確認

    ZIP を解凍し、必要なパスへ配置。
    RSBASE の Apache を起動すると EC2 内では正常動作 を確認。


    6. ローカル PC からのアクセス:80番を開ける

    EC2 のセキュリティグループに Windows Server 用に HTTP(80) を追加。

    ただし、全世界に開放するのは危険なので
    MyIP(自身のグローバルIP限定) に設定。

    Windows Firewall も忘れずに

    GUI から

    受信の規則 → 新しい規則 → TCP 80 → 許可
    

    設定後、ローカルPCから

    http://<EC2のパブリックIP>
    

    でアクセス成功。


    7. Elastic IP(固定IP)を割り当てる

    一度アクセスできても、EC2 の再起動で IP が変わるので、
    Elastic IP を割り当てて固定化した。

    割り当て後、次のように表示されていれば OK。

    パブリック IPv4: 〇〇〇.〇〇〇.〇〇〇.〇〇〇(Elastic IP)
    

    8. DNS 設定(Route53 → お名前.com DNSへ切り替え)

    本命は Route53 に移すことだったが、
    お名前.com のドメインが「ネームサーバの変更不可状態」 になっており移行できなかった。

    理由:
    レンタルサーバ(WordPress)が同じドメインを使っており、
    ネームサーバ変更がロックされていたため。

    そのため、今回の方法:

    お名前.com の DNS に A レコードを追加する方式へ変更

    rsbase.medical-engineering.jp → <Elastic IP>
    TTL:600
    

    反映は最大 24 時間程度。


    9. バックアップ(AMI 作成)

    最後に EC2 の AMI を作成。
    説明文に日本語を入れるとエラー:

    Character sets beyond ASCII are not supported.
    

    対策:
    → 英字のみで AMI 名・説明文を入力
    → 再作成して成功。

    AMI 作成中はインスタンスが再起動される場合があるが問題なし。


    まとめ:今日の成果

    • S3 による RSBASE 配布方式の確立
    • EC2 Windows Server で RSBASE 動作確認
    • EBS 増設で十分なストレージ確保
    • HTTP 公開と Windows Firewall 設定
    • Elastic IP により固定アクセスが可能に
    • DNS は Route53 ではなく お名前.com DNS を継続使用
    • AMI を作成し、復元可能な状態になった

    AWS の基礎からネットワーク、バックアップまで
    一通りの構築作業を実践できた濃い日となった

    明日は DNS が浸透しているはずなので、
    http://rsbase.medical-engineering.jp/ でアクセスできるのを楽しみにしたい。

  • 新ブログを Search Console に登録|サイトマップ送信とインデックス設定

    今日はブログを作ったあと、

    Google Search Console でブログを検索に載せるための設定 を行いました。

    備忘録としてまとめます。

    1. blog.medical-engineering.jp を Search Console に登録

    新しく作ったブログを Google に認識させるために、

    Search Console を開いて URLプレフィックス方式で登録。

    所有権確認は自動で通りました。

    2. サイトマップ(sitemap.xml)を送信

    WordPress が自動生成している

    https://blog.medical-engineering.jp/sitemap.xml

    を Search Console の「サイトマップ」から送信。

    送信直後は「取得できませんでした」でしたが、

    これはよくあることで、時間が経つと正常になります。

    3. 記事ごとに「インデックス登録をリクエスト」

    スラッグ(URL)を英語に修正したこともあり、

    新しいURLで Google に再通知するために、

    記事URLを Search Console の上部「URL検査」に入力 「インデックス登録をリクエスト」をクリック

    これでクロールが走り始めます。

    ※「すでにインデックスされています」と出ても再リクエストしてOK。

    4. 反映は明日以降

    Search Console や検索結果への反映はリアルタイムではなく、

    数時間~1日くらいで動きが見え始める とのこと。

    明日になれば、

    サイトマップの取得ステータス 検出URL インデックス状況

    が確認できるようになるはずです。

    今日のまとめ

    Search Console にブログを登録 sitemap.xml を送信 記事URLのインデックス登録を依頼 反映は翌日以降 これで“検索される準備”が整った

    ブログは環境が整うと一気に楽になる。

    あとは記事を書いて育てていくだけ。

  • エリートの肩書きと、「腐らない」人のこと

    Xを眺めていたとき、

    ある投稿が目に留まった。

    開成高校から東京大学へ進んだある政治家(現職大臣)について、

    「エリート街道をまっすぐ歩いてきても腐っていない」という趣旨のコメントだった。

    その言い方が少し柔らかくて、

    揶揄でもなく、持ち上げすぎることもなく、

    ただ静かに“人柄”に触れている感じがよかった。

    読みながら、

    自分の中のエリート像にある“硬さ”みたいなものが

    すっと溶けていった。

    エリートは権力側に寄る、という思い込み

    開成から東大。

    官僚や大企業の幹部、政治家へと進む人が多い道だ。

    そこを歩む人に対して、

    「民意より権力に寄るのではないか」

    「世間の感覚から離れていくのではないか」

    といった偏見めいたイメージがついて回る。

    自分の中にも、

    そのステレオタイプは確かにあった。

    けれど、あの投稿の言葉は、

    その単純な図式をやんわり裏切るものだった。

    学歴や経歴より、“どこを向いて立つか”

    肩書きは、

    その人が通ってきた道を説明してくれるけれど、

    “何を見るか”“どこに心を置くか”までは決めない。

    同じ道を歩んでも、

    そこに染まりきる人もいれば、

    距離を取りながら誠実さを失わない人もいる。

    政治の世界では特に、

    声の大きさや派手さに注目が集まりがちだ。

    でも生活を支える政策は、

    静かに積み上げていく作業の方が多いし、

    そこに必要なのは派手さではなく、

    自分の立場に酔わない感覚だと思う。

    “腐らない”という言葉の強さ

    あの投稿者が使った「腐っていない」という表現には、

    少しきつさがあるけれど、

    そこにこそ真意があるように感じた。

    環境に流されない人

    立場に酔わない人

    自分の価値を外に預けない人

    そういう人が政治にも必要なのだと

    改めて思った。

    そしてその資質は、

    学歴でも経歴でも測れない。

    静かに仕事をしているだけで、

    周囲の空気が変わるような人がいる。

    その存在を知ることは、

    何か小さな救いみたいなものになる。

    リンクは貼らないけれど

    きっかけになった投稿は、あえてここには載せない。

    ただ、

    「開成から東大へ進んだ、あの政治家の最近の姿勢についての言葉」

    とだけ書いておく。

    ピンときた人は、

    きっと同じ投稿を見ていると思う。

  • AWS CLI 構築から Session Manager 経由の安全なRDP接続、Windows Server 初期設定まで(個人開発環境の構築記録)

    クラウド上に安全な Windows 開発環境を作りたくて、AWS EC2・Session Manager(SSM)・RDP を組み合わせた構成を作りました。

    ローカルPCに負荷をかけず、いつでも起動・停止できる快適な開発環境です。

    この記事では次の内容をまとめています:

    AWS CLI のセットアップ Session Manager を使った “外部公開ゼロ” のRDP環境構築 Windows Server 2022 の初期設定(日本語化・時刻・安全設定) IAMユーザーとWindowsアカウントの整理(最小権限化)

    1. AWS CLI のセットアップ

    AWS上のEC2に安全にアクセスするため、CLI専用のIAMユーザーを作成しました。

    1-1. IAM ユーザー「cli-user」を作成

    今回は CLI専用アカウント として完全に分離。

    作成内容

    ユーザー名:cli-user アクセス方法:Access key(プログラムアクセス)

    付与ポリシー:

    AmazonSSMFullAccess

    AmazonEC2ReadOnlyAccess

    AdministratorAccess は不要(セキュリティ的にも排除)

    セキュリティ:

    後からグループを調整し、最低限の権限だけ付与する構成に変更。

    1-2. AWS CLI インストール

    ローカルPC(Windows)側でインストール:

    公式:

    https://aws.amazon.com/cli/

    インストール後

    aws –version

    1-3. 設定(aws configure)

    CLIにキーを登録:

    aws configure

    登録例:

    AWS Access Key ID: xxxxxxxxxxxxx
    AWS Secret Access Key: xxxxxxxxxxxxx
    Default region: ap-northeast-1
    Default output: json

    動作確認

    aws sts get-caller-identity

    出力に cli-user が表示されれば成功。

    2. Session Manager(SSM)経由でRDPする安全構成

    RDP の 3389ポートを完全に閉じたまま

    AWS Systems Manager (SSM) でトンネルを張り、

    安全にRDP接続する仕組みを構築しました。

    これで外部攻撃リスクはゼロになります。

    2-1. Windows Server 側:SSM Agent の更新

    EC2 上の Windows Server にログインし、PowerShellで実行。

    最新版のSSM Agentを取得

    Invoke-WebRequest https://github.com/aws/amazon-ssm-agent/releases/latest/download/AmazonSSMAgentSetup.exe
    -OutFile SSMSetup.exe

    インストール

    Start-Process .\SSMSetup.exe -ArgumentList “/S” -Wait

    サービス再起動

    Restart-Service AmazonSSMAgent

    2-2. ローカルPC→EC2 へポートフォワード(RDPトンネル作成)

    CLI で Session Manager のポートフォワードを開始。

    aws ssm start-session --target i-xxxxxxxxxxxxxxx
    –document-name AWS-StartPortForwardingSession `
    –parameters “localPortNumber=13389,portNumber=3389”

    これでローカルPCの:

    localhost:13389 → EC2の3389(RDP)

    という安全トンネルが確立します。

    ※ この PowerShell ウィンドウは閉じないこと

    (閉じたい場合は Ctrl + C)

    2-3. RDP接続(外部公開ゼロで接続)

    Windows の RDP クライアント(mstsc)で:

    localhost:13389

    ユーザー名:Administrator

    パスワード:EC2初回ログイン時に取得したもの

    2-4. セキュリティグループから RDP を完全削除

    トンネルRDPが動くのを確認した後、

    セキュリティグループのインバウンドルールから TCP 3389(RDP)を削除。

    結果:

    外部からの RDP → 完全遮断 Session Manager 経由だけ → 許可

    AWSが推奨する“最も安全なWindows運用”になります。

    3. Windows Server 2022 の初期設定

    Session Manager RDPで接続後、サーバの初期設定を実施。

    3-1. 日本語化(表示言語)

    Settings → Time & Language → Language & Region

    → Japanese を追加

    → Windows display language に設定

    → 再起動

    システムロケールも日本語へ

    Control Panel → Region → Administrative → Change system locale → 日本語

    3-2. タイムゾーン(日本時間)

    Set-TimeZone -Name “Tokyo Standard Time”

    3-3. Windows Update の適用

    最新の更新プログラムをすべて適用。

    IME のバージョン確認は不要。

    Windows Update が最新ならIMEも最新に更新される。

    3-4. Windows Firewall

    デフォルト設定のままでOK(推奨) 不要なルールを無効にするとSSMや内部通信が壊れる可能性があるためそのままにする

    ポイントは:

    外部からの攻撃は SecurityGroup で完全に遮断済み

    Windows Firewall はデフォルトでよい

    4. IAM と Windows アカウントの整理(セキュリティ強化)

    最後に、AWS/Windows のアカウントを最適化。

    4-1. cli-user の権限を必要最小限に変更

    最終構成:

    AmazonSSMFullAccess AmazonEC2ReadOnlyAccess

    → AdministratorAccess は削除

    → IAMグループも安全な状態に調整済み

    4-2. Windows Server側も“個人管理者アカウント”を作成

    セキュリティ向上のため:

    Administrator(デフォルト)

    自分専用の管理者アカウント

    この2つに変更。

    → Administratorを使い続けるより安全でログも明確。

    まとめ:今回構築した環境の特徴

    AWS CLI で SSM を安全に実行できる Session Manager のポートフォワードで RDP 接続 外部から3389を完全に閉じた“最強の安全構成” Windows Server を日本語化・最新化 IAM権限とWindowsアカウントを分離 低コスト(停止中は EBS のみ課金)

    ローカルPCに依存せず、

    必要な時だけEC2を起動して安全に作業できる開発環境が完成しました。