41 人が閲覧(直近 30 日) インフラ・クラウド

Kea DHCPとは?構築手順とkea-ctrl-agent廃止後のHTTP API移行【Kea 3.2対応】

Kea DHCPとは?構築手順とkea-ctrl-agent廃止後のHTTP API移行【Kea 3.2対応】

Kea DHCP(キア)は、ISC(Internet Systems Consortium)が開発するオープンソースのDHCPサーバーです。2022年に保守を終えたISC DHCP(dhcpd)の後継にあたり、RHEL 10では従来の dhcp パッケージに代わる選択肢として案内されています。2026年6月に出た現行安定版Kea 3.2.0では、REST APIの窓口だったControl Agent(kea-ctrl-agent)が削除されました。本記事は、Kea 3.2.0(Homebrew版)で設定検査と起動を行って確かめた設定例をもとに、構築手順、kea-dhcp4.conf の書き方、Control Agentからの移行、HA構成、Stork監視までを扱います。

まとめ:Kea DHCPの要点

  • KeaはISC製のDHCPv4/DHCPv6サーバーで、設定はJSON、ライセンスはMPL 2.0です。ISC DHCPは2022年12月にEOLを迎えています。
  • 2026年9月時点の版は、安定版3.2.0(EOL 2027年7月)と長期サポート版3.0.4(EOL 2028年6月)の2本です。
  • kea-ctrl-agent はKea 3.0で非推奨、Kea 3.2で削除されました。HTTP APIは kea-dhcp4 などの各デーモンに control-sockets を書いて直接公開します。
  • Kea 3.0以降は、認証なしのHTTP制御ソケットや平文の user を書いた設定は起動時にエラーで止まります。
  • HAは libdhcp_ha.so と libdhcp_lease_cmds.so の2フックで組みます。Kea 3.0でHAを含むほとんどのフックがオープンソースになりました。
  • Kea本体にWeb画面はなく、GUIと監視はISCのStork(現行2.4.1)が担います。

Kea DHCPの位置づけと構成

Keaという名前はニュージーランドに生息するオウムの一種 kea に由来し、日本語では「キア」と読みます。ISC DHCPとの最大の違いは、設定をJSONで書くことと、プロセスを止めずに設定を入れ替えられることです。ISCはISC DHCPの最終保守版(4.4.3-P1と4.1-ESV-R16-P2)を2022年10月5日に出したあと保守を終えており、新規構築でdhcpdを選ぶ理由はもうありません。

Keaを構成するデーモン

Keaは役割ごとに別プロセスへ分かれています。使わない機能のデーモンを起動しなければ、その分だけ攻撃面が減ります。

プログラム 役割 Kea 3.2での扱い
kea-dhcp4 DHCPv4サーバー HTTP APIを内蔵
kea-dhcp6 DHCPv6サーバー HTTP APIを内蔵
kea-dhcp-ddns DNS動的更新(D2) HTTP APIを内蔵
kea-lfc リースファイルの整理 memfile使用時のみ
kea-ctrl-agent REST APIの中継 削除

Kea 3.2.0のHomebrew版に含まれる sbin は kea-admin、kea-dhcp-ddns、kea-dhcp4、kea-dhcp6、kea-lfc、kea-shell、keactrl、perfdhcp の8本で、kea-ctrl-agent はありませんでした。

ISC DHCPとの違い

項目 ISC DHCP(dhcpd) Kea
保守状況 2022年12月EOL 3.2系・3.0 LTS系を保守
設定形式 dhcpd.conf独自書式 JSON
設定の反映 再起動 config-reload等で無停止
管理API OMAPI HTTP/UNIXソケットのJSON API
冗長化 failoverプロトコル(v4のみ) HAフック(v4・v6)
リース保存 テキストファイル CSV(memfile)・MySQL・PostgreSQL

Keaのバージョンとサポート期限

ISCのKeaページに載っている版は次のとおりです(2026年9月29日確認)。Kea 3.0は3年間保守される最初のLTS系列で、その間に出る安定版系列の保守は1年間です。

版 区分 リリース EOL
3.2.0 Current Stable 2026年6月24日 2027年7月
3.0.4 Current Stable LTS 2026年7月29日 2028年6月
3.3.1 開発版 – –
2.6系 EOL – 保守終了

本番の既定は3.0 LTSで、3.2の新機能が要る場合だけ3.2を選ぶのが無難です。3.2は1年でEOLになるため、次の安定版へ毎年上げる運用を組めないなら3.0に留まる方が保守の手間は減ります。なおUbuntu 26.04 LTSの標準リポジトリはLTS系の3.0.3で、kea-ctrl-agent パッケージもまだ含まれています。

kea-ctrl-agent(Control Agent)の廃止と直接HTTP APIへの移行

Kea 3.0より前は、外部からHTTPでKeaを操作する手段はControl Agentだけでした。Control AgentがHTTPで受けたJSONコマンドを、各デーモンのUNIXソケットへ中継する構成です。Kea 2.7.2で各デーモンがHTTP/HTTPSの制御チャネルを持つようになり、Control Agentは不要になりました。

Control Agentの非推奨化と削除の経緯

  • Kea 2.7.2:kea-dhcp4・kea-dhcp6・kea-dhcp-ddns がHTTP/HTTPSの制御ソケットに直接対応
  • Kea 2.7.6:1つのデーモンで複数のHTTP/HTTPSソケットを持てるようになる
  • Kea 3.0:Control Agentは任意の部品となり、非推奨に
  • Kea 3.1.8(開発版)で削除され、安定版では3.2.0から存在しない

UNIXドメインソケットだけでKeaを操作している環境は、何も変える必要がありません。影響を受けるのは、Control AgentのHTTPポート(既定8000)に向けてAPIを呼んでいる監視スクリプトや管理ツールです(ISCの移行ガイド:Kea Control Agent Migration)。Control Agentを残したままKea 3.2へ上げると、APIの窓口が消えます。

Control Agent設定からcontrol-socketsへの対応

移行は、Control Agentの設定値を各デーモンの control-sockets リストへ1要素として書き写す作業です。

Control Agent(旧) control-sockets(新)
(なし) socket-type: http または https
http-host socket-address(既定127.0.0.1)
http-port socket-port(既定8000)
trust-anchor ほかTLS設定 そのまま
authentication そのまま

DHCPv4とDHCPv6を同じホストで動かす場合、HTTPのアドレスとポートの組はデーモンごとに変えます。HAのリスナーも同じ制約を受けます。旧構成では1つのポートで全デーモンを受けていたため、API利用側の接続先はデーモンの数だけ増えます。

kea-dhcp4に直接HTTP APIを持たせる設定例

次の Dhcp4 配下の設定で、Kea 3.2.0の kea-dhcp4 が127.0.0.1:8004でHTTP APIを受け付けることを確認しました。ユーザー名とパスワードは別ファイルから読み込みます。起動前に /etc/kea/kea-api-user と /etc/kea/kea-api-password を作成し、1行目にそれぞれユーザー名とパスワードを書いて、Keaの実行ユーザーだけが読める権限にしておきます。

"control-sockets": [
  {
    "socket-type": "unix",
    "socket-name": "kea4-ctrl-socket"
  },
  {
    "socket-type": "http",
    "socket-address": "127.0.0.1",
    "socket-port": 8004,
    "authentication": {
      "type": "basic",
      "realm": "kea-dhcpv4-server",
      "directory": "/etc/kea",
      "clients": [
        { "user-file": "kea-api-user", "password-file": "kea-api-password" }
      ]
    }
  }
]

呼び出しはcurlで送れます。Control Agent時代にあった "service": [ "dhcp4" ] の指定は不要になり、接続先のポートでデーモンが決まります。

curl -s -u admin:パスワード -H 'Content-Type: application/json' \
  -d '{ "command": "status-get" }' http://127.0.0.1:8004/

応答は互換性のため、Control Agent時代と同じく要素1つの配列で包まれて返ります。認証情報を付けずに送るとHTTP 401でした。

Kea 3.0以降の起動時セキュリティ検査

Kea 3.0から、デーモンは設定のセキュリティ違反を見つけるとエラーを記録して終了します。ARMが挙げる検査項目は次のとおりで、Kea 3.2.0でも前の2つは設定検査(kea-dhcp4 -t)の時点で失敗しました。

  • HTTP認証に平文の user/password を書く:use of clear text 'user' is NOT SECURE で失敗
  • 認証なしのHTTP制御ソケット:Unsecured HTTP control channel で失敗
  • TSIG鍵の平文 secret
  • 許可されていないファイルパスやパーミッション
  • rootでの実行(警告のみで終了はしない)

起動オプション -X を付けると、これらは警告に落ちて起動は続きます。Kea 3.2のARMの設定例やブログに残る "user": "admin", "password": "1234" 形式は、Kea 3.x ではそのままでは起動しないので、user-file と password-file に書き換えてください。

Kea DHCPのインストール手順

入手経路は、ディストリビューション標準のパッケージとISC公式のCloudsmithリポジトリの2つです。パッケージ名もサービス名も経路ごとに違うため、手順書を混ぜないことが最初の注意点になります。

経路 DHCPv4パッケージ 設定ファイル 版の傾向
Debian/Ubuntu標準 kea-dhcp4-server /etc/kea/kea-dhcp4.conf OSリリース時の版
RHEL 10標準 kea /etc/kea/kea-dhcp4.conf OSリリース時の版
ISC Cloudsmith isc-kea-dhcp4(一式はisc-kea) /etc/kea/kea-dhcp4.conf 3.2・3.0を選択可

Ubuntu/Debian標準パッケージによるKeaの導入

sudo apt update
sudo apt install kea-dhcp4-server
# 本文の設定例を環境に合わせて保存してから検査・起動する
sudoedit /etc/kea/kea-dhcp4.conf
sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
# 検査が成功した場合のみ実行する
sudo systemctl enable --now kea-dhcp4-server

Debianのパッケージが配置するユニットは /usr/lib/systemd/system/kea-dhcp4-server.service です。

ISC公式リポジトリ(Cloudsmith)によるKeaの導入

ISCのナレッジベースに載っている手順です。kea-3-2 の部分を kea-3-0 にするとLTS系になります。

curl -1sLf 'https://dl.cloudsmith.io/public/isc/kea-3-2/setup.deb.sh' | sudo -E bash
sudo apt install isc-kea

RHEL系は setup.rpm.sh を使います。Keaが依存するlog4cplusはRHEL標準のリポジトリに無いため、EPELを有効にしないと nothing provides liblog4cplus でインストールが止まります。旧名の isc-kea-dhcp4-server は移行用のパッケージとして残っています。

RHEL 10標準パッケージによるKeaの導入

RHEL 10では dhcp パッケージが収録されなくなり、Red HatはDHCPサーバーの移行先としてISC Keaを案内しています。Red Hatの手順は、/etc/kea/kea-dhcp4.conf を編集してから systemctl enable --now kea-dhcp4 で起動する流れです。

kea-dhcp4.confの書き方

次の設定は、192.168.10.0/24にアドレスを配り、プリンター1台に固定IPを割り当てる最小構成です。Kea 3.2.0の kea-dhcp4 -t で検査を通しています(インターフェース名は環境に合わせて変えてください)。

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "eth0" ]
    },
    "lease-database": {
      "type": "memfile",
      "lfc-interval": 3600
    },
    "valid-lifetime": 3600,
    "hooks-libraries": [
      { "library": "libdhcp_lease_cmds.so" }
    ],
    "subnet4": [
      {
        "id": 1,
        "subnet": "192.168.10.0/24",
        "pools": [ { "pool": "192.168.10.100 - 192.168.10.199" } ],
        "option-data": [
          { "name": "routers", "data": "192.168.10.1" },
          { "name": "domain-name-servers", "data": "192.168.10.1" }
        ],
        "reservations": [
          {
            "hw-address": "aa:bb:cc:dd:ee:01",
            "ip-address": "192.168.10.10",
            "hostname": "printer01"
          }
        ]
      }
    ],
    "loggers": [
      {
        "name": "kea-dhcp4",
        "output-options": [ { "output": "/var/log/kea/kea-dhcp4.log" } ],
        "severity": "INFO"
      }
    ]
  }
}

interfaces-configと受信ソケットの種類

dhcp-socket-type の既定は raw で、同じセグメントのクライアントのブロードキャストとリレー経由の要求の両方を受けます。udp にするとブロードキャストを受けられなくなり、リレー経由の要求専用になります。L3スイッチのDHCPリレーからしか要求が来ない構成でだけ udp を選びます。

subnet4・pools・option-dataによる配布範囲とオプションの設定

subnet4 の id はリースとサブネットを結び付ける番号で、統計名にも subnet[1].assigned-addresses のように使われます。一度運用に入れたら番号を付け替えないでください。ゲートウェイは routers、DNSサーバーは domain-name-servers で配ります。PXEブートでは、同じサブネットに "next-server": "192.168.10.5" と "boot-file-name": "pxelinux.0" を足すと、TFTPサーバーとブートファイルを通知できます(この2行を足した設定も検査を通過)。

reservations(固定IP)の管理

固定IPは reservations に hw-address(MACアドレス)と割り当てるアドレスの組で書きます。台数が数百を超えて設定ファイルが肥大するなら、ホスト予約をMySQLやPostgreSQLへ移す方が管理しやすくなります。Kea 2.7.4以降は、MySQLには libdhcp_mysql.so、PostgreSQLには libdhcp_pgsql.so のフックを読み込まないとデータベースを使えません。IPアドレスの台帳を別に持つなら、NetBoxのIPAMを正本にしてKeaの予約へ流す構成もあります。

リースファイルとkea-lfc

memfile の既定の保存先は [インストール先]/var/lib/kea/kea-leases4.csv です。リースの更新は追記されていくため、kea-lfc が定期的に重複した履歴を取り除きます(lfc-interval は秒)。lease4-add で登録した1件は、次の列でCSVに書き込まれていました。

address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
192.168.10.150,aa:bb:cc:dd:ee:99,,3600,1790614680,1,0,0,,0,,0

ファイルパスとフックの置き場所の制限

CVE-2025-32801〜32803(修正版2.4.2・2.6.3・2.7.9)を受けて、フックライブラリはビルド時のフック用ディレクトリからしか読み込めなくなりました。リースファイルは var/lib/kea 配下、UNIX制御ソケットは var/run/kea 配下に制限されています。別の場所を使う場合は、起動時の環境変数 KEA_HOOKS_PATH、KEA_DHCP_DATA_DIR、KEA_CONTROL_SOCKET_DIR で変えます。古い記事の "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/..." のような絶対パスは、置き場所が一致しないとエラーになります。ファイル名だけを書くのが確実です。

設定を無停止で反映する方法

ISC DHCPは設定変更のたびにデーモンの再起動が必要でしたが、Keaはプロセスを止めずに設定を入れ替えます。手段は3つあり、目的で使い分けます。

  • config-test:設定を適用せずに検証だけ行うAPIコマンド。ファイルなら kea-dhcp4 -t でも検査できます
  • config-reload:起動時に読んだ設定ファイルを読み直します。実行すると "Configuration successful." と設定のハッシュが返りました
  • config-set:引数で渡した完全な設定で、現在の設定を置き換えます

keactrl reload は、実行中のデーモンにSIGHUPを送って設定ファイルを読み直させます。注意したいのは config-reload の失敗時で、ARMは設定ファイルが不正だとサーバーが使えない状態に陥りうると明記しています。また config-set などAPIで入れた変更は、ファイルへ書き戻していなければ config-reload で消えます。ファイルを編集したら、先に kea-dhcp4 -t 設定ファイル で検査してから読み直してください。フックやデータベースを使う構成では、フックの読み込みと追加検査まで行う kea-dhcp4 -T 設定ファイル も検証環境で通しておくと確実です。

DHCPv6とプレフィックス委譲の設定

DHCPv6は kea-dhcp6 が担当し、設定は Dhcp6 と subnet6 で書きます。家庭用ルーターやCPEに /56 を配るプレフィックス委譲(PD)は pd-pools で指定します。次の例は kea-dhcp6 -t を通過しました。

{
  "Dhcp6": {
    "interfaces-config": { "interfaces": [ "eth0" ] },
    "lease-database": { "type": "memfile" },
    "preferred-lifetime": 3000,
    "valid-lifetime": 4000,
    "subnet6": [
      {
        "id": 1,
        "subnet": "2001:db8:1::/64",
        "interface": "eth0",
        "pools": [ { "pool": "2001:db8:1::100 - 2001:db8:1::1ff" } ],
        "pd-pools": [
          { "prefix": "2001:db8:8000::", "prefix-len": 48, "delegated-len": 56 }
        ],
        "option-data": [
          { "name": "dns-servers", "data": "2001:db8:1::53" }
        ]
      }
    ]
  }
}

DHCPv6ではデフォルトゲートウェイを配れません。経路はルーター広告(RA)で通知するので、RAのMフラグ・Oフラグの設定とセットで設計してください。DHCPそのものの流れ(DORA、リース更新)はDHCPの仕組みとリース設計の解説にまとめています。

Kea HA(High Availability)の構成

Keaの冗長化は、libdhcp_lease_cmds.so と libdhcp_ha.so の2つのフックを読み込んで組みます。Kea 3.0でHAフックはMPL 2.0のオープンソースになり、有償サブスクリプションが要らなくなりました。パラメーターの全体はKea 3.2 ARMのフックライブラリの章にあります。

Kea HAの3モードと自動引き継ぎの違い

モード 通常時の応答 向く構成
load-balancing 2台で要求を分担 負荷を分けたい2台構成
hot-standby primaryだけが応答 待機系を置く2台構成
passive-backup activeの1台だけ リース複製だけ欲しい構成

passive-backupではactive側が落ちても自動では引き継がれず、active側を再起動するか、backupの1台をDHCPを提供する設定に切り替える作業を管理者が行います。自動フェイルオーバーが要件なら、hot-standbyかload-balancingを選びます。

hot-standbyの設定例

primary側(server1)の hooks-libraries です。この例のHA通信は認証も暗号化もないHTTPで、閉じた検証ネットワーク向けです。本番では各ピアに basic-auth-user と basic-auth-password-file を設定し、HTTPSとアクセス制限でピア間通信を守ってください。standby側は this-server-name を server2 にした同じ設定を置きます。

"hooks-libraries": [
  { "library": "libdhcp_lease_cmds.so" },
  {
    "library": "libdhcp_ha.so",
    "parameters": {
      "high-availability": [
        {
          "this-server-name": "server1",
          "mode": "hot-standby",
          "heartbeat-delay": 10000,
          "max-response-delay": 60000,
          "max-ack-delay": 5000,
          "max-unacked-clients": 5,
          "peers": [
            { "name": "server1", "url": "http://192.168.10.2:8005/", "role": "primary", "auto-failover": true },
            { "name": "server2", "url": "http://192.168.10.3:8005/", "role": "standby", "auto-failover": true }
          ]
        }
      ]
    }
  }
]

HA構成で詰まりやすい点

  • 掲載例のようにHA専用リスナーを使う構成では、HAのピアURLのポートを制御用のHTTPソケットと分けます。専用リスナー(http-dedicated-listener、既定true)を無効にするとHA通信は制御用ソケット経由になりますが、ARMはスループットが大きく落ちるとしています。この設定で起動すると、制御用の8004とHA用の8005が別々に待ち受けていました
  • 起動したサーバーはまず waiting 状態に入り、この間はDHCP応答を返しません(起動直後に ha-heartbeat を送ると "state": "waiting" が返りました)。ピアに接続できれば syncing か ready へ、ピアが利用不能と判断すれば partner-down へ移って全トラフィックを引き受けます
  • 2台の時刻のずれが30秒を超えると警告が出て、60秒を超えるとHAサービスが terminated 状態になり、リース更新の交換が止まります。NTPで揃えてから組んでください

フックライブラリとDNS動的更新(DDNS)

Kea 3.0以降、ISCが作るフックのうち有償で残ったのはConfiguration Backend CommandsとRBAC(ロールベースのアクセス制御)の2つだけです。Lease Commands、Host Commands、Subnet Commands、Leasequery、RADIUS、Forensic Logging、Ping Check、Limitsなどはオープンソースとして同梱されます。Kea 3.2.0のHomebrew版にも、libdhcp_ha.so や libdhcp_radius.so を含む18本のフックが入っていました。

リースに合わせてDNSのAレコードとPTRレコードを登録するには、kea-dhcp-ddns(D2)を動かし、kea-dhcp4 側で "dhcp-ddns": { "enable-updates": true } と ddns-qualifying-suffix を設定します。kea-dhcp4 とD2の間は既定で127.0.0.1のUDP 53001番で通信し、D2がDNSサーバーへRFC 2136の動的更新を送ります。正引き・逆引きの基本はDNSの名前解決の解説を参照してください。

Storkによる監視とGUI

Keaには管理画面がありません。GUIが要る場合は、ISCが開発するStorkを使います。StorkはKeaの各サーバーにStork Agentを入れ、Stork Serverが集約したサブネットの使用率、リース、HAの状態をWeb画面で表示する構成です。現行の安定版は2026年5月13日リリースのStork 2.4.1で、EOLは2026年第4四半期と短いため、Kea本体より頻繁に上げることになります。

Stork AgentはKeaの統計をPrometheus形式でも公開し、既定では0.0.0.0の9547番で待ち受けます(ポートは環境変数 STORK_AGENT_PROMETHEUS_KEA_EXPORTER_PORT で変更可)。Prometheus側は prometheus.yml の static_configs に各Agentの ホスト名:9547 を並べ、Grafanaでリース数やプール使用率を可視化します。サブネット数が多いネットワークでは、STORK_AGENT_PROMETHEUS_KEA_EXPORTER_PER_SUBNET_STATS をfalseにしてサブネット単位の統計を止めると、Prometheusへ渡る系列を減らせます。監視設計の全体はPrometheusで監視を構築する手順で扱っています。

ISC DHCPからKeaへの移行手順

dhcpd.confはKeaのJSONへそのままは移せません。ISCは変換ツールKeama(Kea Migration Assistant)を配布しており、DHCPv4なら -4、DHCPv6なら -6 を指定して、ISC DHCPの設定ファイルからKeaの設定を生成します。インストールせずに使えるWeb版も dhcp.isc.org で公開されています。

keama -4 -i dhcpd.conf -o kea-dhcp4.conf

変換結果はそのまま本番に入れず、次の順で確かめます。

  1. 生成された設定を kea-dhcp4 -t で検査し、Kea 3.x のセキュリティ検査で落ちる箇所(平文の認証情報、パス)を直す
  2. Keamaは変換に失敗した件数を終了コードで返すので、0でなければ該当箇所をdhcpd.confと突き合わせて手で書き直す
  3. 検証セグメントでリース払い出しと固定IPの割り当てを確認する
  4. 切り替え当日はdhcpdを止め、有効な既存リースをKeaへ引き継いでから起動する。設定の変換だけでは既存リースは移らないため、ISCが公開している実験的なスクリプト(KeaMA Lease)でdhcpdのリースファイルをKea形式に変換して読み込むか、該当アドレスを有効期限まで払い出し対象から外す(同時に動かすと二重応答になる)

固定IPが数件で冗長化もAPIも要らない小規模なネットワークなら、Keaを立てずにルーター内蔵のDHCP機能で足ります。Keaを選ぶ価値があるのは、固定IPを台帳やAPIから流し込みたい、HAが欲しい、DHCPv6やPDを配るといった要件がある環境です。

よくある質問

Kea(DHCP)の読み方は?

「キア」と読みます。名前の由来はニュージーランドに生息するオウムの一種 kea です。

kea-ctrl-agentはまだ使えますか?

Kea 3.0系(LTS)では非推奨ながら残っており、Ubuntu 26.04 LTSの標準パッケージにも3.0.3が含まれます。Kea 3.2では削除されたため、3.2へ上げる前に各デーモンの control-sockets へHTTP設定を移してください。

KeaはWindowsで使えますか?

使えません。ISCはWindowsを公式サポートしておらず、移植の予定もないとしています。LinuxかFreeBSDなどのUNIX系OSで動かします。

KeaにGUIやWeb管理画面はありますか?

Kea本体にはありません。ISCのStorkを入れると、サブネットの使用率、リース、HAの状態をWeb画面で確認できます。

Keaの最新バージョンは?

2026年9月29日時点で、安定版は3.2.0(2026年6月24日リリース)、長期サポート版は3.0.4(2026年7月29日リリース)です。最新はISCのKeaページで確認してください。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.09 テックブログ IDCFクラウド(IDCフロンティア)不正アクセス・ランサムウェア:影響先・復旧・データは戻るか
  2. 2026.10.09 テックブログ ニッスイのサイバー攻撃で日水物流の入出荷停止|委託先クラウド障害に荷主が備える手順
  3. 2026.07.15 コラム LINEミニアプリとは?未認証と認証済みの違い・LIFFとの使い分け・審査と開発費用【2026年版】
  4. 2026.07.23 コラム クラウド販売管理システムとは?オンプレとの違い・料金相場と5年総額の比べ方【2026年】
  5. 2026.01.20 テックブログ PineDramaとは?TikTokのショートドラマアプリの日本配信・料金・安全性を解説

RELATED POSTS 関連記事

目次