>
>
公開日
最終更新日
Iru APIとAdminaの連携は、Iru側でAPIトークンにデバイス一覧・詳細の参照権限を付与し、AdminaへAPI URLとトークンを登録した後に同期件数を検証すれば完了します。
対象読者は、Macを含む社内端末の台帳更新や棚卸しを担当するコーポレートIT・情シス担当者です。Kandji APIとして運用していた環境でも、現在のIru APIの仕様に合わせて接続情報と権限を整理することで、端末情報の二重入力を減らせます。
この記事で確認したこと（確認日: 2026年04月21日）：Iru Endpoint Management APIの取得上限、レート制限、リージョン別URL形式、トークン失効条件、およびAdmina連携で必要となるデバイス参照権限です。確認先はIru APIリファレンスapi-docs.iru.comおよびKandji公式サポート記事support.kandji.ioです。仕様変更が生じた場合は、これらのページで最新の記載を確認し、URLやスコープ設定を記事の手順と照合します。画面表示や契約環境で差が出る箇所は、設定結果によって次の作業を判断できる形で説明します。
Iru APIとは
Iru APIとは、Iruで管理している端末情報を外部の資産管理・SaaS管理基盤へ取得・連携するためのインターフェースです。
本記事のポイント
IruとAdminaの連携では、デバイス一覧とデバイス詳細の参照権限が必要です。
Iru Endpoint Management APIは、1テナント当たり1時間に10,000リクエストまでです。
デバイス一覧の取得は1回当たり最大300件のため、300台以上では取得漏れの有無を件数で検証します。
APIトークンを作成した管理者を削除すると、トークンも削除されます。
旧Kandji APIとの関係
Kandjiとして導入した環境で使われていたAPIは、現在はIru Endpoint Management APIとして案内されています。Iruのドキュメントでは、エージェント名はIru Agentへ変更されていますが、Macの統合ログには引き続き「io.kandji」のプレフィックスが残ります。名称だけで障害と判断せず、API URL、トークン、権限、同期件数の順に切り分ける運用が実務的です。
Admina連携で扱うデータ
AdminaのIru連携は、端末の情報を資産台帳へ取り込む用途です。端末名、OS、シリアル番号、管理状態などを台帳で確認する設計には向きます。一方、利用者のIdPアカウントがIruから自動作成・自動同期される前提では設計しません。端末と利用者を厳密に結び付ける必要がある場合は、Admina側で管理するアカウント情報や別の人事・IdP連携を基準に紐付け方法を決めます。
APIとMCPの使い分け
定期同期や台帳更新にはREST APIを使います。Iru社は、Claude Desktop、Cursor、OpenAI CodexなどのMCP対応クライアントと連携するIru MCPについて公式ドキュメントで言及していますが、提供範囲や含まれる製品の条件は変更される場合があるため、Iruの管理画面または公式ドキュメントで現在の状況を確認します。MCPは端末状況の調査を補助できますが、Admina連携の認証情報を生成AIの会話欄へ貼り付ける運用は行いません。トークンは秘密情報として保管し、AIには必要な結果だけを渡します。
▶ 関連記事: MDM連携とは？台帳を自動更新する仕組みとJamf等との棲み分け
連携前の準備条件
連携前に、Iruの管理者権限、対象テナントのリージョン、Adminaへ登録する接続情報の保管先を決めると設定のやり直しを抑えられます。
必須権限の設定条件
Adminaで端末一覧と個別端末の情報を取得するには、IruのAPIトークンに「Devices > Device list」と「Devices > Device details」を付与します。前者だけでは一覧が見えても詳細項目が不足し、後者だけでは対象端末の列挙ができません。この2権限がAdmina連携の動作要件となっていますが、Admina側の連携仕様が変更された場合はAdminaのヘルプセンターまたはサポート窓口で最新の要件を確認します。確認の結果、追加スコープが必要と判明した場合は最小権限の原則に従って追加し、不要なスコープは同じトークンに含めない設計を維持します。
リージョン別API URL
Iru Endpoint Management APIの公式ドキュメントでは、USリージョンの形式を「」、EUリージョンの形式を「」と案内しています。名称がIruに変わっていても、既存テナントではkandji.io形式のエンドポイントが使われる場合があります。管理画面で表示されるテナント固有のURLが上記のどちらに属するかを判定できれば、そのURLをAdminaへ登録します。URL形式が一致しない、またはテナントのリージョンを特定できない場合は、推測したURLで登録せず、Iruの管理画面に表示された接続先を基準に限定検証へ進みます。
トークン保管の担当設計
APIトークンは、個人のブラウザメモ、チャット、ソースコード、表計算ファイルに平文で残しません。連携専用の管理者アカウントを用意し、トークン値は権限を絞ったパスワードマネージャーまたは秘密情報管理基盤に保管します。トークン名には用途、登録先、発行日を記録すると、障害時に「どの連携を止めずに更新すべきか」を判断できます。
Iru APIとAdminaの連携手順
Iru側でAPIトークンを発行し、指定スコープを付与してAdminaに入力することで連携設定は完了します。
1. APIトークンの発行と権限付与
IruのWebアプリへ管理者としてログインし、APIトークンの管理画面から連携専用トークンを作成します。名称は「Admina-device-sync」のように用途が分かるものにし、トークンを発行した管理者アカウントも運用台帳へ記録します。
新しいAPIトークンを作成します。名称は「Admina-device-sync」のように用途が分かるものにします。
権限設定で「Devices > Device list」を有効にします。
続けて「Devices > Device details」を有効にします。この2権限が揃わないと、一覧取得と詳細取得の両方を満たせません。
保存後、発行されたトークン値を秘密情報管理基盤へ記録します。
トークンを発行した管理者アカウント名を運用台帳へ記録します。管理者が削除された場合にトークンも連動して失効するため、後続の手順で照合できる状態にしておきます。
USまたはEUのテナント固有API URLを控えます。
ここでやってはいけないのは、退職予定者や異動予定者の個人管理者アカウントでトークンを発行することです。Iruの公式サポートは、トークンを作成した管理者ユーザーをWebアプリから削除すると、そのAPIトークンも削除されると案内しています。個人に依存した発行方法では、退職者処理が正しく実施された結果として同期が止まります。
2. AdminaでのURLとトークン登録
Adminaの連携サービス一覧から「Iru（旧Kandji）」を選択し、Iruで控えたAPI URLとAPIトークンを入力して保存します。URLの末尾に不要なパスや空白を追加すると認証エラーと区別しにくくなるため、テナントの接続先をそのまま登録します。トークンは画面共有や操作記録に映らない状態で貼り付けます。
登録先がUSかEUかでURLが異なるため、USテナントのトークンをEU形式のURLへ登録する組み合わせは使いません。接続エラーが出たときは、最初にURLのリージョン、次にトークン値の欠落、最後に2つのDevices権限を確認すると、原因を短い順序で絞り込めます。
3. 同期結果の検証
保存直後は、Adminaの連携ステータスとデバイス一覧を確認します。検証では「同期成功」の表示だけで完了にせず、Iruの管理台数とAdminaに表示された台数を照合します。少なくとも、任意の端末を数台選び、シリアル番号、端末名、OS情報、管理状態が期待どおりに反映されているかを確認します。
初回同期で取得件数がちょうど300件の場合は、一覧取得のAPI上限に達している可能性があります。この場合は、全件数との差分を記録し、次回同期後にも同じ差分が残るかを確認します。Admina連携コネクタが300件超をどの方式でページ送りするかは、2026年04月21日に確認した公開情報だけでは判断できません。Iru側の台数とAdmina側の台数が一致すれば本番運用へ進み、不一致なら連携設定を変更する前にAdminaのサポート窓口へ同期ログと件数差を添えて問い合わせる判断になります。
▲ Iru APIとAdminaを連携する基本設定手順
API制限を踏まえた同期設計
端末情報を安定して同期するには、毎時10,000リクエストと1回300件の上限を前提に、全件ポーリングではなく必要な頻度と対象に絞る設計にします。
レート制限の計算
Iru Endpoint Management APIの公式ドキュメントでは、レート制限は1顧客当たり1時間に10,000リクエストです。これは1分当たりに単純換算すると約166リクエストです。ただし、上限ぎりぎりで継続実行すると、再試行や別の連携処理の余地がなくなります。Admina連携に加えて独自スクリプトや資産管理ツールも同じテナントAPIを使う場合は、呼び出し元ごとの利用量を記録します。
300件上限への対応
デバイス一覧取得には、1リクエスト当たり最大300件のハード上限があります。300台を超える環境で独自連携を作る場合は、ページネーションまたはAPI仕様で提供される継続取得方法を実装し、取得結果をシリアル番号で重複排除します。300件を1回で取得できるからといって、毎分全件を取得する設計にはしません。
Iru Agentは標準設定で通常15分ごとにチェックインします（目安であり、ネットワーク状況や設定により変動します）。したがって、端末上の状態変更直後に台帳へ反映されない場合、API障害と決めつけず、まず端末のチェックイン時刻とIru上の表示更新を確認します。Iru上で更新済みなのにAdminaだけが古い場合は連携側を、Iru上でも更新前なら端末通信やエージェント状態を優先して調査します。
同期監視の記録項目
連携の監視では、成功・失敗だけでは不足します。実行日時、Iruの管理台数、Adminaの登録台数、差分台数、失敗した場合のエラー内容、トークン更新日を1つの運用記録に残します。台数差が0件から増えた時点で検知できれば、棚卸し時に初めて欠損へ気付く状態を避けられます。
連携失敗を防ぐ運用と切り分け
同期エラーは、URL・権限・トークン失効・取得件数の4項目を順番に確認すると、無関係な設定変更を避けながら切り分けできます。
トラブル別の切り分け表
症状 | 主な原因 | 確認する記録 | 判断後の対応 |
|---|---|---|---|
接続直後に認証エラー | URLのリージョン違い、トークン値の欠落 | 登録したURL形式、秘密情報の更新履歴 | 形式が違えば正しいテナントURLへ変更し、一致すればトークンを再発行します。 |
端末一覧が空または一部欠損 | Device listまたはDevice detailsの権限不足 | トークンの2つのDevices権限、IruとAdminaの台数差 | 権限不足なら最小権限のまま2権限を追加し、台数差が残れば取得上限を調査します。 |
以前は動いていた同期が停止 | トークン作成者の管理者削除、トークン更新漏れ | 管理者削除履歴、トークン発行日、連携停止日時 | 作成者削除があれば連携専用管理者で再発行し、Adminaの登録値を更新します。 |
管理台数が300件で止まる | 一覧取得上限、ページ送り未完了 | Iru管理台数、Admina登録台数、差分の推移 | 件数が一致しなければ同期ログを添えて連携仕様を確認し、手作業で不足分を恒久補完しません。 |
トークンローテーションの手順
トークンを定期更新する組織では、新しいトークンを発行してAdminaへ登録し、同期成功と台数一致を確認してから旧トークンを無効化します。先に旧トークンを削除すると、問題発生時に旧設定へ戻せず、連携停止時間が伸びます。管理者アカウントの削除予定がある場合も同じ順序を使い、削除前に後継トークンへ切り替えます。
生成AI利用時のセキュリティ境界
生成AIでAPIレスポンスを分析する場合は、トークン、端末シリアル番号、利用者メールアドレスを会話入力に含めません。Iru MCPを使う場合も、閲覧対象を必要な端末群に絞り、実行内容を監査可能な形で残します。生成AIに端末の削除やワイプなど影響の大きい操作を直接委ねず、調査結果の取得と人による承認を分離すると、誤操作の影響範囲を限定できます。
▶ 関連記事: デバイスLCM効率化のメリットとは？情シスの工数削減と運用改善の秘訣
▲ 同期エラー発生時の原因切り分け判断フロー
連携方式の選定と国内事例
Admina連携を選ぶか独自API連携を作るかは、端末台帳の一元化を優先するか、独自の処理や配信まで自動化するかで分けます。
連携方式の比較
比較軸 | Adminaとの連携 | 独自のIru API連携 | CSVによる手作業更新 |
|---|---|---|---|
主な用途 | 端末情報をSaaS・資産管理の台帳へ集約 | 社内DB、監査処理、独自ワークフローとの接続 | 一時的な棚卸しや例外対応 |
構築担当 | 情シス担当者が連携設定を管理 | 情シスと開発担当者が実装・保守 | 台帳管理者が更新 |
API制限への対応 | 同期後の件数照合を実施 | 10,000件毎時・300件上限を実装に反映 | APIを使わないため対象外 |
変更時の影響 | トークンと権限の更新が中心 | API仕様・認証・エラー処理の改修が発生 | 転記漏れと更新遅れが発生しやすい |
資産台帳の統合が目的で、Adminaの表示項目で足りる場合は連携設定から始めます。端末情報を基に独自の通知、ソフトウェア配信、社内DB更新まで行う場合は、レート制限を考慮した独自API連携を検討します。IruはSnipe-ITに対し、インベントリ、端末詳細、割り当て情報を自動同期できると案内しており、資産管理の連携先を拡張する選択肢もあります。
株式会社アマナの導入事例
株式会社アマナは、Iru（旧Kandji）を導入し、Mac端末のセットアップ時間を従来比で50％削減したと株式会社Tooの導入事例で紹介されています。同事例によると、株式会社アマナはビジュアルコミュニケーションを専業とする企業で、Mac約300台・Windows PC約500台・iPhone約600台を含む社内ITインフラを運用しています。課題はMacセットアップの作業負荷、施策はIruによる端末管理、成果はセットアップ時間50％削減です。
この事例からAdmina連携の効果を直接推定することはできません。ただし、端末設定をIruで標準化し、その端末情報をAdminaの台帳へ同期する構成なら、キッティング工程と資産情報更新を別々の表で管理する重複を減らせます。
▶ 関連記事: 法人・企業用IT資産と社用デバイスを一元管理する方法
▲ 目的に応じた端末データ連携方式の対比（Admina連携 vs 独自API vs CSV）
よくある質問
Iru APIと旧Kandji APIの名称、トークン失効、300件を超える端末取得について、設定時に判断が必要な質問へ直接回答します。
Q. Kandji APIとIru APIは別に作り直す必要がありますか
A. Kandjiとして運用していた連携でも、まず現在登録されているAPI URL、トークン、Devices権限、同期件数を確認します。Iruの公式ドキュメントにはkandji.io形式のAPI URLも記載されているため、名称だけを理由にURLを推測変更せず、実際のテナント接続先が使える場合はその設定を維持します。
Q. APIトークンが突然無効になった場合の原因は何ですか
A. トークンを作成した管理者ユーザーが削除された場合、該当トークンも削除されます。管理者削除履歴と連携停止日時が一致するなら、連携専用管理者で新規トークンを発行し、Admina登録後に同期件数を再検証します。
Q. デバイスが300件を超える場合、初回同期はどうなりますか
A. Iru APIのデバイス一覧取得は1回当たり最大300件です。Admina連携が300件超をどのようにページ送りするかは公開情報で確認できないため、初回同期後にIruとAdminaの台数を必ず照合し、一致しない場合は件数差と同期日時を添えて連携仕様を確認します。
Q. API連携だけで利用者アカウントまで一元化できますか
A. IruからAdminaへ取り込む設計では、端末情報の同期を前提にします。利用者のIdPアカウントを基準にした退職処理や権限管理が必要な場合は、Admina側のアカウント管理やIdP連携を別系統として組み合わせます。
▶ 関連記事: MDMとは？仕組みと選び方・主要製品比較を解説【2026最新】
まとめ
Iru APIとAdminaの連携では、最初に連携専用管理者を決め、「Devices > Device list」「Devices > Device details」の2権限を付けたトークンを発行します。次に、テナントのリージョンに合うAPI URLとトークンをAdminaへ登録し、IruとAdminaの端末台数が一致するかを確認します。
毎時10,000リクエスト、一覧300件の制限と、作成者削除時のトークン失効を運用台帳へ記録すれば、突然の同期停止を切り分けやすくなります。明日取り組む最初の一歩は、現在の連携トークンを誰が作成したか、2つのDevices権限が付いているか、台数差がないかを1回記録することです。MDM連携の全体像はMDM連携でデバイス台帳を一元管理でも確認できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
