Skip to main content
新しい従業員が入社したとき、通常は誰かがBoxウェブアプリを操作してその従業員のフォルダを作成し、適切なリソースを共有して、従業員を適切なチームに追加します。そのような手作業は、時間がかかり、一貫性がなく、ミスが発生しやすいものです。同じロールの2人の新規採用者に異なるフォルダ構造とアクセス権限が付与されることになるため、いずれガバナンスや監査上の問題が生じます。 このチュートリアルでは、手作業を排除するミドルウェアサービスを構築します。HRシステムでhiredイベントが発生したら、サービスがBoxへの認証を行い、新規採用者向けの標準化された個人用フォルダツリーをプロビジョニングし、適切なグループに適切なレベルでアクセス権限を付与し、必要に応じて新規採用者を各自のワークスペースに招待します。すべての新規採用者に、同一の管理された構造が自動的に付与されます。

構築する内容

このチュートリアルの最後には、次のような機能を備えた、動作するPythonサービスが完成します。
  • Webhookエンドポイントを介してHR hiredイベントを受け取ります。
  • ITやHRなど、アクセスを制御するガバナンスグループを解決 (または作成) します。
  • Folders APIを使用して、新規採用者向けに標準化された個人用フォルダツリーを作成します。
  • Collaboration APIを使用して、各ガバナンスグループに適切なフォルダレベルでアクセス権限を付与します。
  • 必要に応じて、新規採用者を各自のワークスペースに招待し、初日からアクセスできるようにします。
  • 実行の冪等性を確保し、同じイベントが再発生しても重複するフォルダやコラボレーションが作成されないようにします。

前提条件

始める前に、以下が揃っていることを確認してください。
  • 管理者アクセス権限を備えたBoxアカウント。で使用でき、無料のでも問題ありません (Platformアプリを自動的に承認するため、管理コンソールの承認手順をスキップできます)。
  • クライアント資格情報許可認証で構成され、管理コンソールで承認されたBoxアプリケーション。
  • Python 3.11以上。
  • アプリで以下のスコープが有効になっていること。
    • Boxに格納されているすべてのファイルとフォルダの読み取りと書き込み
    • グループを管理する
    • ユーザーを管理する
  • [構成] タブで、アプリの [アプリアクセスレベル] を [アプリ + Enterpriseアクセス] に設定します。デフォルトの [アプリアクセスのみ] では、サービスアカウントからのアクセスが独自のコンテンツのみに制限され、Enterpriseユーザーやグループの作成、管理ができません。
  • Box Enterprise ID (このIDを確認するには、開発者コンソールでプロフィールアイコンをクリックするか、管理コンソールの [アカウントと請求] を見てください)。
グループおよびユーザーを作成、管理するには管理者権限が必要です。enterprise_idでクライアント資格情報許可を使用すると、アプリがEnterpriseサービスアカウントとして機能します。このサービスアカウントは、アプリの [アプリアクセスレベル] が [アプリ + Enterpriseアクセス] に設定されている場合にのみEnterpriseユーザーおよびグループを管理できます。[グループを管理する] および [ユーザーを管理する] スコープを有効にし、アクセスレベルを変更した後は、その変更を反映させるために、管理者が管理コンソールの [統合 > Platformアプリ] でアプリを再承認する必要があります。

手順

このソリューションでは、以下に示す4つのBox Platform機能を併用します。
Boxコラボレーションはカスケードされます。親フォルダにコラボレーションが追加されると、そのフォルダ内のすべての要素に同じアクセス権限が付与されます。このチュートリアルでは、この仕組みを意図的に利用しています。つまり、ツリー内の上位フォルダには広範囲のアクセス権限を付与し、必要な特定のサブフォルダのみに、より狭い範囲のアクセス権限を付与しています。
1

開発環境のセットアップ

  1. ターミナルを開き、新しいプロジェクトディレクトリを作成します。
  1. Pythonの仮想環境を作成してアクティブ化します。
アクティブ化すると、ターミナルのプロンプトの先頭に(.venv)と表示されます。これにより、仮想環境内で作業していることがわかります。
新しいターミナルウィンドウやタブを開くたびに、プロジェクトディレクトリからsource .venv/bin/activateを実行して、仮想環境を再アクティブ化する必要があります。コマンドの実行中にModuleNotFoundErrorが表示される場合、通常、venvがアクティブ化されていないことを意味します。
  1. 必要なパッケージをインストールします。
  1. 資格情報を保存するための.envファイルを作成し、以下の内容を追加します。プレースホルダの値を、Box開発者コンソールで確認した実際の資格情報で置き換えます。
ONBOARDING_ROOT_FOLDER_IDは、各新規採用者のワークスペースが作成されるフォルダです。これを0のままにしてサービスアカウントのルート上にワークスペースを作成するか、専用のNew HiresフォルダのIDを設定します。
.envファイルはバージョン管理システムにコミットさせないでください。.env.gitignoreに追加します。
環境変数の理解: .envファイルには機密情報 (実際の資格情報) が保存されています。Pythonコードは、os.getenv("VARIABLE_NAME")を使用してこれらの名前を参照することで、その値を読み取ります。たとえばos.getenv("BOX_CLIENT_ID")を実行すると、.envファイル内のBOX_CLIENT_ID=の隣に保存されている値を検索します。以下の手順でコードをコピーする際は、引用符で囲まれた変数名をそのまま正確に保持してください。実際の資格情報に置き換えないでください。
2

Boxクライアントの認証

プロジェクトディレクトリにbox_client.pyという名前のファイルを作成し、以下のコードを貼り付けます。
エンドユーザーを関与させずにサーバー間の処理を自動化する場合には、クライアント資格情報許可をお勧めします。組織内でJWTが必要な場合は、CCGConfig/BoxCCGAuthJWTConfig/BoxJWTAuthと入れ替えます。チュートリアルのコードの他の部分は変更しません。両方の比較については、を参照してください。
3

ワークスペーステンプレートを定義する

管理されたオンボーディングプロセスで最も重要なのは、すべての新規採用者のワークスペースの見た目と、その各部にアクセスできるユーザーが誰であるかを、単一の宣言的な定義にすることです。config.pyという名前のファイルを作成し、以下のコードを貼り付けます。
構造とアクセスルールを1つのテンプレートに含めることで、一貫性のある管理されたオンボーディングを実現できます。将来のすべての採用者の設定方法を変更するには、プロビジョニングロジックではなく、このファイルを編集します。
4

ガバナンスグループを解決する

フォルダをグループと共有する際には、そのグループのグループIDを調べる必要があります。groups.pyという名前のファイルを作成し、以下のコードを貼り付けてください。これにより、ガバナンスグループが存在しない場合は作成され、存在する場合は既存のグループが検索されます。
グループ名は企業内で一意である必要があります。そのため、指定したグループ名がすでに使われている場合、Boxは409 Conflictを返します。このステータスをキャッチして検索にフォールバックすることにより、この機能を安全な方法で繰り返し実行できます。
5

ワークスペースを作成してコラボレーションを適用する

workspace.pyという名前のファイルを作成し、以下のコードを貼り付けます。これにより、テンプレート内の各フォルダがすべてのレベルで再帰的に作成され、そのフォルダがノードに定義されているグループに共有されます。
build_workspaceはテンプレートを再帰的に処理するため、同じコードでフラットな構造や深くネストされた構造にも対応できます。ツリーはconfig.pyでテンプレートを編集するだけで変更できます。
6

オンボーディングを調整する

onboarding.pyという名前のファイルを作成し、以下のコードを貼り付けます。これにより、各要素が関連付けられます。グループが解決され、特定の採用者向けにワークスペースが作成され、必要に応じて新規採用者が各自のワークスペースに招待されます。
ワークスペースのルートに新規採用者を招待すると、新規採用者がそのルート内のすべてのフォルダを表示できる一方、他のユーザーのアクセス権限はサブフォルダ上でのグループコラボレーションによって引き続き管理されます。invite_new_hireは、サービスアカウントがワークスペースフォルダを所有している場合は共同所有者を付与し、所有していない場合は編集者にフォールバックします。これは、所有者または共同所有者のみが共同所有者のロールを付与できるためです。別のユーザーによって所有されるフォルダにあるONBOARDING_ROOT_FOLDER_IDを指定した場合、そのワークスペースフォルダはそのユーザーが所有しているため、フォールバックによって403が回避されます。誰も招待していない段階で構造をプロビジョニングするには、emailNoneのままにします。これは、新規採用者の業務開始日にまだBoxアカウントがない場合に便利です。
7

採用者イベントリスナーを作成する

app.pyという名前のファイルを作成し、以下のコードを貼り付けます。このFlaskアプリケーションは、HRシステムからhiredイベントを受け取り、イベントごとにワークスペースをプロビジョニングします。
実稼働環境では、通常は各リクエストの署名または共有シークレットを検証することにより、受信するリクエストが本当にHRシステムから送信されたものであることを確認する必要があります。未認証の公開エンドポイントからリソースをプロビジョニングすることは絶対に避けてください。
この時点でプロジェクトディレクトリには、以下のファイルが含まれていることになります。
8

統合のテスト

実際のHRシステムに接続しなくても、プロビジョニングフロー全体をローカルでテストできます。この手順では、新規採用者が追加されたときにHRシステムから送信されるイベントをシミュレートします。
この手順では、2つのターミナルウィンドウを同時に開く必要があります。ターミナル1で、Flaskサーバーを実行します (これは常時稼働させておく必要があります)。ターミナル2では、このサーバーにテストリクエストを送信します。
ターミナル1 - サーバーを起動するonboarding-workspaceディレクトリを開いていることと、仮想環境がアクティブ化されていることを確認します。
次のように表示されます。
このターミナルは起動したままにしておきます。ターミナル2 - テスト用の採用者イベントを送信する:新しいターミナルタブまたはウィンドウを開きます。curlを使用して、シミュレートされたHRイベントを送信します。メールアドレスを有効なアドレスに置き換えて招待をテストするか、work_emailを削除してテストをスキップします。
結果の確認ターミナル1に切り替えます。グループ、フォルダ、コラボレーションが作成されたことを示す出力が表示されます。
Boxで次のことを確認します。ワークスペースの所有者が、自分の個人用または管理者ログインではなく、アプリのであること。フォルダはサービスアカウントの独自のルート上に作成されるため、自分がコラボレータとして追加されていない限り、Boxウェブアプリの [すべてのファイル] には表示されません。これは正常な動作です。以下のいずれかの方法で結果を確認します。
  • サービスアカウントとしてAPIのクエリを実行する (推奨)。この方法では、ワークスペースを作成したときと同じIDを使用します。ワークスペースのコンテンツを一覧表示し、各サブフォルダとそのコラボレータを確認します。
  • Boxウェブアプリでコンテンツを開く。自分がコラボレータになっているフォルダのみが表示されます。新規採用者として自分のメールアドレスを渡している場合は、Boxウェブアプリを開き、Jordan Rivera - Onboardingを見つけて (共有フォルダとして表示される)、サブフォルダを開き、[共有] をクリックして、コラボレータのリストを確認します。誰も招待されていない場合、フォルダを表示できるのはサービスアカウントのみです。
  • **コンテンツマネージャでプレビューする。**管理コンソール > [コンテンツ] > [コンテンツマネージャ] の順に移動し、適切なユーザーを選択します。共有フォルダを表示できます。
ワークスペースがサービスアカウントのルートではなく、管理者が表示できる実際の場所に表示されるようにするには、管理者が所有する専用のNew Hiresフォルダを作成し、サービスアカウントをその共同所有者コラボレータとして追加して、ONBOARDING_ROOT_FOLDER_IDをそのフォルダのIDに設定します。そうすると、新しいワークスペースの所有者がその管理者になり、その管理者の [すべてのファイル] に表示されるようになります。
次の手順で再度実行します。同じcurlリクエストを再度送信します。エラーは発生せず、重複するフォルダ、グループ、コラボレーションも作成されずにサービスが完了します。この冪等性により、実稼働環境で失敗または再発生したイベントを安全に再試行できます。

トラブルシューティング

仮想環境がアクティブ化されていません。python3コマンドを実行する前に、プロジェクトディレクトリからsource .venv/bin/activateを実行してください。新しく開いたターミナルタブは、すべて個別にアクティブ化する必要があります。
以下のように、.envファイルを確認します。
  • BOX_CLIENT_IDおよびBOX_CLIENT_SECRETが、開発者コンソール > [構成] の値と一致していることを確認します。
  • BOX_ENTERPRISE_IDが、自分のEnterprise IDであることを確認します (開発者コンソール > [一般設定] または管理コンソール > [アカウントと請求] で確認できます)。
  • アプリが開発者コンソールで承認されていて、クライアント資格情報許可を使用していることを確認します。
グループ、ユーザー、コンテンツを管理するために必要なスコープやアクセスレベルがアプリに設定されていない:
  • 開発者コンソール > [構成] で、[アプリアクセスレベル] を [アプリ + Enterpriseアクセス] に設定します。デフォルトの [アプリアクセスのみ] では、Enterpriseユーザーおよびグループを作成することも管理することもできず、403が返されます。
  • 開発者コンソール > [構成] > [アプリケーションスコープ] で、[すべてのファイルとフォルダの読み取りと書き込み]、[グループを管理する]、[ユーザーを管理する] を有効にします。
  • アクセスレベルやスコープを変更した後は、管理者が管理コンソールの [統合 > Platformアプリ] でアプリを再承認する必要があります。アプリが再承認されるまで、これらの変更は反映されません。
Enterpriseユーザーおよびグループの作成には、管理権限Enterpriseアクセス権限が必要です。アプリの [アプリアクセスレベル] が [アプリ + Enterpriseアクセス] に設定されていること (デフォルトの [アプリアクセスのみ] では、これらの操作に対して403が返される)、[グループを管理する] および [ユーザーを管理する] スコープが有効になっていること、Enterprise管理者がそれらの変更後にアプリを再承認したことを確認します。
これは再実行時に想定される動作であり、自動で処理されます。create_folderが競合レスポンスで返される既存のフォルダを再利用し、is_already_collaboratorが既存のコラボレータを検出して、それをコラボレーションヘルパーがスキップします。これをBoxがどのように報告するかは、それがグループであるか (409とコードconflict、およびメッセージ「Group is already a collaborator (グループはすでにコラボレータになっています)」が表示) ユーザーであるか (user_already_collaborator) によって異なるため、ヘルパーは両方をチェックします。未処理の409が発生した場合は、try/exceptブロックとis_already_collaboratorヘルパーを表示と同じように正確にコピーしたかどうかを確認してください。
メールアドレスが既存のBoxユーザーのものではない場合、招待が承認されるまでコラボレーションはpending状態で作成されます。このフローの一部として、新規採用者向けに管理対象アカウントをプロビジョニングするには、を参照してください。

本番環境へのスケーリング

グループとのフォルダの共有は、ガバナンスモデルの半分にすぎません。新規採用者をグループ内に追加すれば、そのグループがBox全体にわたってすでに保持しているすべてのコラボレーションを自動的に継承させることもできます。次のようにMemberships APIを使用します。
一般的には、すべての新規採用者をAll Employeesグループに追加し、初日から組織全体の共有フォルダにアクセスできるようにします。を参照してください。
すでにメンバーになっているユーザーを追加すると、409 BoxAPIErrorが返されます。この手順の再実行の安全性を、サービスの他の部分と同じように維持するには、workspace.pyで使用したものと同じtry/exceptパターンで呼び出しをラップし、競合を無視します。
フォルダに加え、各新規採用者にへのアクセス権限も付与できます。Box Hubは、オンボーディング資料、ポリシー、FAQの厳選されたコンテンツポータルであり、Box AIと統合されているため、新規採用者はそのコンテンツ全体を対象として自然言語で質問できます。一般的には、1つの共有された「New Hire」Hubを用意し、プロビジョニングの際に各新規採用者 (またはAll Employeesグループ) をコラボレータとして追加します。以下のヘルパーをworkspace.pyに追加します。フォルダとは異なり、コラボレータがすでに存在する場合、Hubは (is_already_collaboratorに一致するalready a collaboratorの本文ではなく) 汎用の409 Conflictを返すため、ヘルパーはすべての409を冪等性スキップとして扱い、再実行の安全性を維持します。
HubのIDを.envONBOARDING_HUB_IDとして格納し、新規採用者がメールアドレスを持っている場合はヘルパーをonboard_new_hireから呼び出します。
そうではなく、グループレベルでアクセス権限を付与するには、CreateHubCollaborationV2025R0AccessibleBy(type="group", id=group_id)を渡します。有効なロールはviewereditorco-ownerです。
これらの呼び出しを成功させるには、Box Hubsをしておく必要があります。*_v2025_r0 SDKのメソッドは、Hubsエンドポイントに必要な2025.0 APIバージョンを対象としています。サービスを実行しているID、つまりクライアント資格情報許可を使用するときのサービスアカウントでコラボレーションを管理するには、Hubを所有または共同所有している必要があります。そうでない場合、BoxはそのHubを認識できないため、404 Not FoundをメッセージAuthorization Failedとともに返します。最も簡単なのは、Hubを所有できるようにサービスアカウントでHubを作成するか ([] を使用)、サービスアカウントを既存Hubの共同所有者として追加する方法です。ロールと削除を管理するには、を参照してください。
プロビジョニング済みのツリーに制御レイヤーを追加します。インスタンスをアタッチして各ワークスペースに新規採用者の部門と開始日のタグを付け、を適用して、オンボーディングドキュメントがスケジュールに基づきアーカイブまたは削除されるようにします。また、メタデータを使用することで、企業全体のワークスペースが検索可能かつ報告可能になります。
/hireエンドポイントを権限ありとして扱います。HRシステムからのすべてのリクエストに共有シークレットまたは署名を要求し、内部へのトラフィックを既知のソースのみに制限して、サービスをHTTPSの背後で実行します。認証できないリクエストは、プロビジョニングコードに到達する前にすべて拒否されます。
HR統合は、イベントを複数回、順不同で配信できます。このチュートリアルの冪等性のヘルパーにより、すでに重複は防止されていますが、大量のイベントを扱うためには、イベントをキューに登録すること、一過性の障害をバックオフによって再試行すること、各プロビジョニングの実行をログに記録してオンボーディング対象者の身元と日時の監査証跡を保持することも必要になります。
ライフサイクルを完成させるには、オフボーディングのプロセスが必要です。HRシステムで退職イベントが発生した場合は、離職する従業員のコンテンツを転送し、その従業員のアクセス権限を削除します。およびを参照してください。

次の手順

ユーザーとコンテンツをプロビジョニングする

ユーザー、グループ、共有フォルダ構造のプロビジョニングに関するBoxのエンドツーエンドのパターンを確認します。

Collaborations APIリファレンス

コラボレーションの作成に関する詳細なAPI仕様を確認します。
最終更新日 2026年7月21日