デバイスの接続

IronFlock は、ハードウェアやオペレーティングシステムに応じて、複数のデバイス接続方法をサポートしています。手元にハードウェアがない場合でも、数分でラップトップ上でデバイスをシミュレートできます。

前提条件

デバイスを接続する前に、以下を確認してください：

1. IronFlock 上にプロジェクトが作成されていること
2. プロジェクト内にデバイスエントリが作成されていること（プロジェクトの Settings -> Devices パネルで NEW DEVICE をクリック）
3. デバイス設定ファイル（.flock）がダウンロード済みであること

制限のある企業ネットワーク上のデバイスですか？ ネットワークの設定はインストールの前に計画してください — インストールしたばかりのデバイスがオフラインのままになる、最も一般的な原因です：

• ID 認識型ファイアウォールまたはプロキシ： デバイスを許可するルールは、ログイン中のユーザーではなく、必ずデバイス自体に紐づけてください — そうしないと、そのユーザーのセッションが切れるたびにデバイスがネットワークから切り離されます。ID 認識型ファイアウォールとプロキシ を参照してください。
• 企業の HTTP プロキシ： エージェントと Docker に、プロキシを明示的に設定する必要があります — 企業プロキシの背後で → エッジデバイス を参照してください。
• オンプレミスのアプライアンスへの接続： デバイスはアプライアンスのサービスポートに直接到達できる必要があります。アプライアンスが 企業証明書による HTTPS で動作している場合はポート 443 のみで済みますが、その場合はデバイス上で企業のルート CA を信頼させてください。アプライアンスガイドの デバイス接続 を参照してください。
• クロックのずれ： 企業のファイアウォールは、インストール直後の OS に同梱された公開の時刻サーバーを通常ブロックするため、デバイスのクロックは気づかないうちにずれていきます。社内の NTP サーバーを設定してください。時刻同期（NTP） を参照してください。

ID 認識型ファイアウォールとプロキシ

すべてのエッジデバイスは、IronFlock エージェントを無人のシステムサービスとして実行します。エージェントは起動時に開始し、常時接続を維持しながら、アプリのインストール、イメージのプル、自身の更新を続けます — デバイスに誰かがサインインしているかどうかには関係ありません。これはプラットフォームがどこで稼働していても同じで、IronFlock クラウド、お客様のプライベートクラウド、オンプレミスのアプライアンスのいずれにも当てはまります。

OT ネットワークは、ネットワークアドレスではなくディレクトリ上の ID に基づいてアクセスを許可する ID 認識型ファイアウォールおよびプロキシ（identity-aware firewall / proxy）によって保護されることが増えています。エッジデバイスを許可するルールが、そのデバイスにログインしているユーザーに紐づいていると、そのユーザーのセッションが切れた時点でデバイスはネットワークへのアクセスを失います：

• すでに開いている接続は動作し続けるため、デバイスは引き続きオンラインと表示されます。
• 新しい接続はすべて通知なく破棄されます — アプリのインストール、イメージのプル、エージェントの更新、再接続が失敗します。
• 次にエージェントまたはデバイスを再起動すると、まったく再接続できなくなり、誰かがデバイスに再びサインインするか、ルールが変更されるまでオフラインのままになります。

ルールは人ではなく、必ずデバイスに紐づけるよう、ネットワークチームに依頼してください：

主な製品では、次のように対応します。

• Check Point Identity Awareness： Access Role で、ユーザーではなくマシン（コンピューターオブジェクトまたはグループ）を選択します。マシン ID はコンピューター自身のドメイン上のアクティビティによって更新されます。ゲートウェイ上でマシン ID が失効する可能性がある場合は、代わりにネットワークオブジェクトを使用してください。
• Palo Alto Networks User-ID： コンピューターアカウントからは IP とユーザーのマッピングが生成されないため、アドレスオブジェクト、タグ、または Device-ID を使用してください。
• Fortinet FSSO および同様のディレクトリベースのファイアウォール： デバイスのアドレスオブジェクト、またはネットワークアクセス制御が割り当てるダイナミックアドレスを使用してください。
• Zscaler、Prisma Access などのクラウドセキュリティゲートウェイ： デバイスのネットワークを IoT またはサーバーのロケーション（信頼できる送信元）として登録し、デバイスのトラフィックがユーザーではなくロケーションによって識別されるようにしてください。

これは ID ポリシーの適用除外ではありません — デバイスを、そのデバイスが実際に持っている ID で識別するということです。オンプレミスのアプライアンスを運用している場合は、アプライアンスホストにも同じことが当てはまります：IronFlock ホストのネットワーク ID を参照してください。

障害の見分け方。 デバイスはオンラインのままなのに、アプリのインストール、イメージのプル、エージェントの更新がタイムアウトで失敗し、それでも ping は成功する場合、原因はデバイスではなく、期限切れになった ID ルールにあります。デバイスからの新しい接続が再び成功するまでは、エージェントもデバイスも再起動しないでください。まだ開いているセッションが唯一機能している接続であり、その間もこのセッションによってデバイスをリモートから管理できるからです。

まずはテスト：ラップトップでデバイスをシミュレート

IronFlock を試すために物理的なハードウェアは必要ありません。FlockFlasher アプリは IronFlock エージェントをラップトップ上で直接実行できるため、ラップトップがプロジェクト内で実際のデバイスになりすまします。実機に展開する前にアプリやダッシュボードをテストするのに最適です。

1. Docker Desktop（Linux の場合は Docker Engine）をインストールし、起動していることを確認します。
2. お使いの OS 用の FlockFlasher アプリをダウンロードしてインストールします。
3. ダウンロード済みのデバイスの .flock ファイルをダブルクリックします。FlockFlasher が開き、デバイスがリストに表示されます。（または、FlockFlasher を開いて + ボタンからファイルを追加することもできます。）
4. デバイスエントリの Test Device（▶）ボタンをクリックします。FlockFlasher は初回使用時に IronFlock エージェントを自動的にダウンロードし、お使いのデバイス設定で起動します。

これで、ラップトップは IronFlock プロジェクト内でこのデバイスとして動作します。デバイスはオンラインとして表示され、実際のデバイスとまったく同じようにアプリをインストールして実行できます。アプリはラップトップ上で Docker コンテナとして実行されます。

テストが終わったら、FlockFlasher でテストを停止してください。同じ .flock ファイルは、後で実機のプロビジョニングにも使用できます。ただし、同じデバイス設定を実行するマシンは、常に 1 台のみにしてください。

方法1：SD カードのフラッシュ

SD カードからブートする Raspberry Pi やその他の ARM デバイスに最適です。

1. お使いの OS 用の FlockFlasher アプリをダウンロードします。
2. SD カード（最低 16 GB）をコンピュータに挿入します。
3. FlockFlasher を開き、+ ボタンをクリックして .flock ファイルを読み込みます。
4. SD カードドライブを選択します（FlockFlasher は外部ドライブを自動検出します）。
5. デバイスに適したイメージを選択します（Raspberry Pi 3/4、Zero など）。
6. 必要に応じて WiFi を設定し、設置先でデバイスが接続できるようにします。
7. Flash をクリックし、書き込み、検証、設定の完了を待ちます。
8. SD カードをデバイスに挿入して電源を入れます。

デバイスは 20分以内にオンラインになるはずです。

警告：フラッシュ処理により、選択したドライブのすべてのデータが消去されます。FlockFlasher はデフォルトで内蔵ドライブを非表示にしますが、選択内容を必ず確認してください。

方法2：産業用 PC 向け USB インストーラー

EFI ブート対応の AMD64 デバイス（例：Siemens SIMATIC Box IPC）向け。

1. USB スティック（最低 16 GB）を挿入し、FlockFlasher を開きます。
2. .flock ファイルを読み込み、USB ドライブを選択します。
3. Industrial PC x86_64 (EFI) イメージを選択します。
4. Flash をクリックし、完了を待ちます。
5. 必要に応じて、デバイスの BIOS でブート順序を USB ブートに変更します。
6. USB スティックを挿入してデバイスの電源を入れます。

デバイスは 60分以内にオンラインになるはずです。

方法3：カスタムインストール

既存の Linux OS を維持するデバイス向け。NVIDIA Jetson やカスタムハードウェアに最適です。

注意：この手動インストール方法は、産業用 PC、ゲートウェイ、組み込みデバイスなどの実際の本番ハードウェアを対象としており、ラップトップ向けではありません。ラップトップで IronFlock を試したいだけの場合は、代わりにまずはテスト：ラップトップでデバイスをシミュレートに従ってください。手動でのエージェントインストールは不要です。

Linux / Unix デバイス

1. デバイスに SSH 接続します。
2. .flock ファイルをコンピュータからデバイスにコピーします：

   scp mydevice.flock user@device-ip:/home/user/

3. インストーラーをダウンロードして実行します。

   curl -fsSL https://instance-registry.ironflock.com/dl/device-init/install.sh | sudo bash -s -- -c mydevice.flock

   IronFlock アプライアンスをお使いですか？ 新しいデバイス ダイアログに表示されるコマンドを使用してください — それらは instance-registry.ironflock.com ではなくアプライアンスを指しています。

install.sh は、デバイスの CPU に合わせたセットアップツール ironflock-init をダウンロードし、スクリプトに組み込まれた IronFlock の鍵でその OpenPGP 署名を確認したうえで、渡された引数を付けて実行します。引数なしの場合は ./ironflock-init を現在のディレクトリにダウンロードするだけです。その後 sudo ./ironflock-init -c mydevice.flock で起動します。

ironflock-init は Docker（未インストールの場合）とデバイスエージェントをインストールし、次の設定を行います。

• プロジェクトオーナー用の SSH ユーザー — ログインは鍵（デバイスキー）のみ、sudo はパスワードなし
• .flock ファイルの内容による WiFi 設定（NetworkManager 経由）
• ログインバナー

無人セキュリティアップグレードには手を加えず、--reboot を指定しない限りデバイスを再起動しません。変更内容はすべて /opt/ironflock/device-init/installed.json に記録されるため、remove コマンドでその変更だけを正確に元に戻せます。

curl -fsSL https://instance-registry.ironflock.com/dl/device-init/install.sh | sudo bash -s -- remove

ironflock-init のその他のオプション:

• -a — 質問せずに既定値を採用する
• --disable-suspend（-s）— デバイスがスリープしないようにする
• --reboot — セットアップ完了後にデバイスを再起動する
• --update-config（-u）— インストール済みデバイスの .flock ファイルを入れ替える
• --http-proxy、--https-proxy、--no-proxy — セットアップをプロキシ経由にする
• --download-base — 別の場所（たとえば IronFlock Appliance）からダウンロードする

デバイス上では、エージェントは /opt/ironflock/device-agent にあり、systemd サービス ironflock-device-agent として動作します。状態は systemctl status ironflock-device-agent で確認でき、ログは journalctl -u ironflock-device-agent と /var/log/ironflock/device-agent.log にあります。設定は /opt/ironflock/device-agent/device-config.flock（root のみ読み取り可能で、/boot にはコピーがなくなりました）、Docker のデータは /opt/ironflock/device-agent/docker-apps に、アプリのデータは引き続き /apps にあります。

エージェントは自分自身を更新します。別個の更新マネージャーはありません。更新は署名され検証されており、失敗した更新は自動的にロールバックされます。更新が適用されるのは、エージェントの起動時か、ユーザーが Studio で更新を開始したときだけです。

2026 年 10 月より前にインストールされたデバイスでは /opt/reagent とサービス reagent.service が使われていました。そのようなデバイスがエージェント 1.3.x を実行すると、自動的に上記の構成へ移行し（Docker とアプリは一度再起動します）、/opt/reagent はリンクとして残ります。

企業プロキシの背後で運用していますか？ インストーラーのダウンロードにもプロキシを指定し、ステップ 3 の引数に --http-proxy / --https-proxy を追加すると、ironflock-init が Docker エンジンを自動で設定します。完全なコマンドと企業 CA の手順は 企業プロキシの背後で を参照してください。

任意：先にインストーラーを検証する

root で実行される前にスクリプトを確認したい場合は、署名と一緒にダウンロードし、IronFlock のブートストラップ鍵で検証します。

curl -fsSLO https://instance-registry.ironflock.com/dl/device-init/install.sh
curl -fsSLO https://instance-registry.ironflock.com/dl/device-init/install.sh.asc
curl -fsSL https://instance-registry.ironflock.com/dl/device-init/ironflock-bootstrap.asc | gpg --import
gpg --verify install.sh.asc install.sh

gpg が、IronFlock Bootstrap <[email protected]> による有効な署名で、フィンガープリントが F6C9 4D96 CE31 5377 ACA7 C8EA 4990 5433 7321 2788 であると報告する必要があります。確認できたら、検証済みのスクリプトを実行します。

sudo bash install.sh -c mydevice.flock

Windows デバイス

1. デバイスに Docker Desktop をインストールし、Docker Desktop の設定で Start Docker Desktop when you sign in を有効にします。無人運用のデバイスでは、再起動後に誰もサインインしなくても Docker が利用できるよう、Windows の自動サインインも設定してください。
2. device-agent.exe をダウンロードします。
3. .flock ファイルをデバイスにコピーします。
4. 管理者権限のコマンドプロンプトから、エージェントを Windows サービスとしてインストールして起動します：

   device-agent.exe service install -config path\to\config.flock

   サービス ironflock-device-agent はすぐに開始され、以降はシステム起動時にも自動的に開始されます。障害時には自動的に再起動し、エージェントを常に最新の状態に保ちます。起動せずにインストールするには -noStart を追加してください。状態はいつでも device-agent.exe service status で確認できます。

デバイス上では、エージェントは %ProgramData%\IronFlock\DeviceAgent に配置されます。ここには device-agent.exe、設定ファイル device.flock、ログ device-agent.log、そしてアプリのデータ（apps\ 配下）があります。アップデートは署名され検証されます。失敗したアップデートは自動的にロールバックされ、アップデートはエージェントの起動時、またはユーザーが Studio でアップデートを開始したときにのみ適用されます。

エージェント 1.4.0 より前にインストールされた Windows デバイスは、%ProgramData%\IronFlock\Reagent とサービス reagent を使用していました。エージェント 1.4.0 は、そのようなデバイスを上記のレイアウトへ移行します — エージェントとそのアプリは一度再起動します。

企業プロキシの背後にいる場合は？ service install コマンドに -proxy http://proxy.example.com:3128 を追加し、Docker Desktop のプロキシは Settings → Resources → Proxies で設定してください。詳細と企業 CA の手順は 企業プロキシの背後で をご覧ください。

ドメインに参加している Windows デバイスの場合は？ エージェントサービスは、誰かがサインインしているかどうかに関係なく LocalSystem として実行されるため、ログイン中のユーザーに紐づいたファイアウォールルールではカバーされません。ルールをデバイスのコンピューターアカウントに紐づけてもらってください — ID 認識型ファイアウォールとプロキシ を参照してください。

時刻同期（NTP）

デバイスエージェントには正確なクロックが必要です。プラットフォームとの TLS ハンドシェイク、イメージの取得を認可するトークン、そしてデバイスが publish するすべてのデータポイントのタイムスタンプが、これに依存します。クロックが 15 分以上ずれているデバイスは、ファイルストレージ からも CLOCK_SKEW で拒否されます。

企業ネットワークでは、これは当たり前に整っているものではなく、セットアップの一手順です。UDP ポート 123 の外向き NTP はしばしばブロックされており、OS に同梱された公開の時刻サーバーには到達できず、クロックは目に見えるエラーもないままずれていきます。社内の時刻サーバーを情報システム部門に確認してデバイスに設定するか、デバイス用ネットワークについて外向きの UDP 123 を許可してもらってください。

Linux

systemd-timesyncd の場合（Debian と Ubuntu の既定）:

sudo mkdir -p /etc/systemd/timesyncd.conf.d
sudo tee /etc/systemd/timesyncd.conf.d/corporate.conf > /dev/null <<'EOF'
[Time]
NTP=ntp.your-company.com
EOF
sudo systemctl restart systemd-timesyncd
timedatectl status

chrony の場合:

echo "server ntp.your-company.com iburst" | sudo tee -a /etc/chrony/chrony.conf
sudo systemctl restart chrony
chronyc sources

timedatectl status が System clock synchronized: yes と表示する必要があります。

Windows

管理者権限のプロンプトから:

w32tm /config /manualpeerlist:"ntp.your-company.com" /syncfromflags:manual /update
w32tm /resync
w32tm /query /status

出来合いの IronFlock イメージで書き込んだデバイス（方法1 と方法2）は、既定で公開の時刻サーバーと同期します。それがブロックされているネットワークでは、デバイスのサブネットに対して外向きの UDP 123 を許可するか、初回起動後に SSH で上記の Linux と同じ手順で社内の時刻サーバーを設定してください。

接続の確認

接続後、プロジェクトでデバイスのステータスを確認します：

• 緑のインジケーター — デバイスはオンラインで、IronFlock と通信中です。
• 赤のインジケーター — デバイスはオフラインです。ネットワーク接続を確認し、エージェントが実行中であることを確認してください。
• 緑のインジケーターなのに、アプリのインストール、イメージのプル、またはエージェントの更新がタイムアウトする — ファイアウォールのルールが、デバイスからの新しい接続を許可しなくなっている可能性があります。何かを再起動する前に、ID 認識型ファイアウォールとプロキシ をお読みください。

デバイスマップビューには、プロジェクト内のすべてのデバイスの地理的な位置が表示されます。