<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="ja">
  <title>RHEMS Japan コラム</title>
  <subtitle>クラウド運用・セキュリティ・コストの現場で判断したことを書いています。</subtitle>
  <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/"/>
  <link rel="self" type="application/atom+xml" href="https://www.rhems-japan.co.jp/feed-column.xml"/>
  <id>https://www.rhems-japan.co.jp/column/</id>
  <updated>2026-11-09T00:00:00+09:00</updated>
  <author><name>株式会社RHEMS Japan</name><uri>https://www.rhems-japan.co.jp/</uri></author>
  <entry>
    <title>モデル依存をどこまで許すか — Anthropic上場後の調達設計</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/frontier-model-dependency-design/"/>
    <id>https://www.rhems-japan.co.jp/column/frontier-model-dependency-design/</id>
    <updated>2026-11-09T00:00:00+09:00</updated>
    <published>2026-11-09T00:00:00+09:00</published>
    <summary>Anthropicの上場申請で、フロンティアモデルの原価と支出約束が見えるようになりました。公開価格の差、囲い込みの実装、依存を薄くする4つの層、自前の評価セット、国産モデルの使いどころとオンプレ逆転の条件を整理します。</summary>
  </entry>
  <entry>
    <title>Anthropicの上場が見せた、AI企業の「基盤」の弱さ</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/ai-frontier-ipo-no-platform/"/>
    <id>https://www.rhems-japan.co.jp/column/ai-frontier-ipo-no-platform/</id>
    <updated>2026-11-09T00:00:00+09:00</updated>
    <published>2026-11-09T00:00:00+09:00</published>
    <summary>Anthropicが上場申請で初めて財務を開示しました。売上は急成長、同時に約8,954億ドルの計算資源の支出約束。MicrosoftやAWSが持っていた「基盤」を持たないAI企業が、何で稼ぎ続けるのかを整理します。</summary>
  </entry>
  <entry>
    <title>セキュリティ製品を入れた後に、会社が決めること</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/security-like-safe-driving/"/>
    <id>https://www.rhems-japan.co.jp/column/security-like-safe-driving/</id>
    <updated>2026-11-06T00:00:00+09:00</updated>
    <published>2026-11-06T00:00:00+09:00</published>
    <summary>使えるセキュリティ製品は、早く導入したほうがいい。攻撃は導入を待ってくれないからです。しかし、製品を入れただけでは守りは始まりません。誰が見て、誰が判断し、誰が対応するのか。製品を日々の仕事として動かす体制を、お客さまと一緒につくることが重要です。</summary>
  </entry>
  <entry>
    <title>障害の7割は変更から来る — 戻せる形・検知できる形を作る</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/change-management-not-security-tools/"/>
    <id>https://www.rhems-japan.co.jp/column/change-management-not-security-tools/</id>
    <updated>2026-11-06T00:00:00+09:00</updated>
    <published>2026-11-06T00:00:00+09:00</published>
    <summary>攻撃を防ぐ道具は増えましたが、障害の大半は変更から起きます。戻せる形・検知できる形・パイプラインに載せる範囲を、実装単位で整理します。</summary>
  </entry>
  <entry>
    <title>会社の建物に、通用口はもう要らない — VPNをやめて「部屋ごとの鍵」に変えた話</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/zero-trust-like-building-keys/"/>
    <id>https://www.rhems-japan.co.jp/column/zero-trust-like-building-keys/</id>
    <updated>2026-11-02T00:00:00+09:00</updated>
    <published>2026-11-02T00:00:00+09:00</published>
    <summary>VPNは、社員証を1回見せれば建物の中を自由に歩ける「通用口」のような仕組みでした。当社はそれを廃止し、部屋ごとに鍵を分け、入るたびに名乗る形に変えています。何が変わり、何が変わらないのか、鍵と図面の管理をなぜ仕組みに任せたのかを、建物に置き換えて説明します。</summary>
  </entry>
  <entry>
    <title>VPNを廃止して、ゼロトラストに置き換えた — 扉の無いネットワークとCI/CDの運用</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/zero-trust-vpn-replacement-ops/"/>
    <id>https://www.rhems-japan.co.jp/column/zero-trust-vpn-replacement-ops/</id>
    <updated>2026-11-02T00:00:00+09:00</updated>
    <published>2026-11-02T00:00:00+09:00</published>
    <summary>当社は拠点VPNとリモートアクセスVPNを廃止し、ゼロトラスト型のリモートアクセスに置き換えました。VPNとの違い、EKS上のコネクタで作った「外から叩けない」経路、そして基盤の維持をCI/CDに載せた理由を、実際の構成と残っている制約から整理します。</summary>
  </entry>
  <entry>
    <title>サーバの鍵は、家の合鍵と同じ — 「配らない・見せない・残さない」運用の作り方</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/ssh-keys-like-house-keys/"/>
    <id>https://www.rhems-japan.co.jp/column/ssh-keys-like-house-keys/</id>
    <updated>2026-10-29T00:00:00+09:00</updated>
    <published>2026-10-29T00:00:00+09:00</published>
    <summary>会社のサーバには鍵があります。家の合鍵と同じで、持っている人だけが中に入れる。違うのは、持ち主が毎年入れ替わり、複製されたことに気づけないことです。当社が「鍵を配らない」運用に変えた理由と、そのために何を用意したのかを、家の鍵に置き換えて説明します。</summary>
  </entry>
  <entry>
    <title>SSHの鍵を作業者に渡さない — YubiKeyとSecrets Managerで作った鍵レス運用</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/ssh-keyless-operations/"/>
    <id>https://www.rhems-japan.co.jp/column/ssh-keyless-operations/</id>
    <updated>2026-10-29T00:00:00+09:00</updated>
    <published>2026-10-29T00:00:00+09:00</published>
    <summary>当社は自社サーバへのSSHにパスワードも鍵ファイルも使わず、YubiKeyと統合認証で運用しています。お客様から預かる鍵はAWS Secrets Managerに置き、作業者に鍵を見せないまま接続する仕組みを作りました。セキュリティと利便性をどう両立させたのかを整理します。</summary>
  </entry>
  <entry>
    <title>ソフトウェアにも修繕計画が要る — 家のメンテナンスに置き換えて考えるパッチ適用</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/patching-like-home-maintenance/"/>
    <id>https://www.rhems-japan.co.jp/column/patching-like-home-maintenance/</id>
    <updated>2026-10-29T00:00:00+09:00</updated>
    <published>2026-10-29T00:00:00+09:00</published>
    <summary>家には修繕の予定表があり、壊れてから集めるのでは間に合わないので積み立てをします。ソフトウェアも同じで、弱点は後から見つかり、直す部品が出ます。2026年10月のPHPの脆弱性対応を、家の修繕に置き換えて、経営・企画の立場で確認したい3つの質問にまとめました。</summary>
  </entry>
  <entry>
    <title>PHP2Shellで問われたのは、パッチを当てられる体制だった</title>
    <link rel="alternate" type="text/html" href="https://www.rhems-japan.co.jp/column/php2shell-patch-operations/"/>
    <id>https://www.rhems-japan.co.jp/column/php2shell-patch-operations/</id>
    <updated>2026-10-28T00:00:00+09:00</updated>
    <published>2026-10-28T00:00:00+09:00</published>
    <summary>PHP本体に認証なしの遠隔コード実行を許す脆弱性「PHP2Shell」が2026年10月に公表されました。当社の対応の大半がイメージの差し替えで済んだ理由と、セキュリティ製品の導入だけでは守れない理由を、運用の観点から整理します。</summary>
  </entry>
</feed>
