GovernNodeにおけるBlueprintとそのバージョンの切り分けについて

この中の２：Project templateについて、Blueprint Designerで設定したバージョンが表示されますが認識あってますでしょうか？

はい、ご認識の通りです。

上記の認識があっている場合、Blueprint DesignerのどのBlueprintが選択されているものでしょうか？また、Blueprintの変更は可能でしょうか？

以下の画像に記載のように、Blueprint Designerで定義したBlueprintの中で、すべてのアクティブなバージョンが表示されるはずです。

回答は上記のようになりますが、もしご不明な点などございましたらご連絡ください。どうぞよろしくお願いいたします。

以下、回答させていただきます。

追加でのご質問なのですが、プロジェクトをGovern対象に入れる際のテンプレートについては「Govern Project」の中にあるActiveなバージョンが表示される認識であってますでしょうか？

はい。「Govern Project」に紐づくアクティブ化したテンプレート（Blueprint version）は、ガバナンスプロジェクトの作成時に選択可能です。（以下リンクのチュートリアルをご参照ください。）

https://academy-content.dataiku.com/latest/govern/customization/custom-templates/tutorial-index.html

また、他のBlueprint（任意で作成したBlueprint）をプロジェクトをGovern対象に入れる際のテンプレートのリストとして表示させることは可能でしょうか？

はい。当該ユーザーがGovern対象プロジェクトを作成可能な場合、カスタムBluerprintを含むすべてのBlueprintを利用できます。（以下リンクのドキュメントをご参照ください。）

https://doc.dataiku.com/dss/latest/security/govern-permissions.html#blueprint-and-blueprint-version-permissions

2026/3/17 回答追記・修正

承認者もしくは承認フローを手動で選択するのではなく、「内容に応じて特定の承認フローを強制的に適用したい」場合、以下画像に示すようにBlueprint Designerで表示条件に応じたステップを定義可能です。（※前提として、「Advanced License (Advanced Govern)」の導入が必要です。）

上記のように、「表示条件」を利用する方法がシンプルで良いと考えられます。

ただ、ご質問に記載をいただいたように、異なるテンプレートを定義して対応することも可能です。その場合、「Use script」機能でスクリプトを作成し、条件に応じたテンプレート（Blueprint）を自動適用することになります。（※この場合も「Advanced License (Advanced Govern)」の導入が必要です。）

参考ドキュメント： https://knowledge.dataiku.com/latest/govern/overview/concept-governance-settings.html

以下、コメントさせていただきます。

Use ScriptはGovernance settingで設定できる項目でしょうか？

はい、ご認識の通りです。ただ前提として、Use Scriptを利用する場合は、以下ドキュメントに記載の「Advanced License (Advanced Govern)」を導入済みである必要があります。

https://doc.dataiku.com/dss/latest/governance/index.html

Role&Permissions＞Blueprint-specific settingsにUserとGroupというBlueprintがあるのですが、こちらで権限を設定することでGorvenノード上のユーザーやグループの追加・削除の権限を設定できる認識であってますでしょうか？

いえ、「Blueprint-specific settings内のUser、GroupというBlueprint」は以下ドキュメントに記載の「Dataiku blueprints」に該当します。このDataiku blueprints (locked blueprints)は、カスタムページを作成した場合等にArtifactの情報を参照するために利用するものであり、Artifactの追加・削除などを行うことはできません。

https://doc.dataiku.com/dss/latest/governance/blueprint-designer/blueprint-designer.html

「ユーザーやグループの追加・削除の権限を設定できる」のは以下ドキュメントに記載のように「Administrator」のみとなります。（※もし「承認処理やガバナンスロールに紐づくユーザーやグループを追加・削除する権限」を意図されている場合、「Govern Architect」権限があれば対応可能です。）

https://doc.dataiku.com/dss/latest/security/govern-permissions.html

上記のように、ユーザーやグループ自体の追加・削除を行えるのは、あくまでもAdministrator（管理者）のみとなります。また、これらのユーザー・グループはGovernノードに特有のものではなく、Dataikuのノード全体で共有されます。

登録済みユーザー・グループはGovernノードにも自動的に同期されますので、適切な権限を設定してArtifactと紐づけてあげることで、そのユーザー・グループはGovernノード上で操作を行うことが可能になります。設定の詳細は以下のチュートリアルをご参照ください。

https://knowledge.dataiku.com/latest/govern/permissions/basics/tutorial-index.html

以下、回答いたします。

1. ユーザーやグループの追加・削除の権限・・Dataiku Cloud版ではLaunchpad上で設定できるものでしょうか？

はい。Dataiku Cloudの場合、以下ドキュメントに記載の画面でユーザー・グループの管理が可能です。

https://knowledge.dataiku.com/latest/cloud-space-management/users-roles-groups/reference-permission-management.html

2. Governable Itemについて、ユーザーによって閲覧可能なアイテムを制御したい場合はどうすればよいでしょうか？もしすべて見られるのであれば、「Govern This Item」を選択した場合、ユーザーによって選べるテンプレートを制御したいと考えてます。
例：Aさん→Project１、Project2が見られる、テンプレート１が選択できる
　　Bさん→Project3が見られる、テンプレート2が選択できる

「Governノード上でアイテムを参照可能かどうか」は、当該アイテムのBlueprintに対して、Dataikuユーザー/グループが参照権限を持っているかどうかに依存します。この権限設定は、以下リンクのドキュメントに記載の「Role Assignment Rule」で行います。

https://knowledge.dataiku.com/latest/govern/permissions/basics/tutorial-index.html#assign-the-custom-role-to-a-group

一方で、個々のアイテムに対して「Role Assignment Rule」を設定することも可能です。

https://knowledge.dataiku.com/14/govern/permissions/how-to-add-rule-to-item.html

そこで、「Aさん、Bさんに対して、それぞれが参照可能なプロジェクトを動的に制御したい」ような場合は、以下の手順で対応可能です。

1. 各ユーザー/グループに対応するBusiness Initiativeを複数定義する。
2. 各Business Initiativeに対して、「Role Assignment Rule」を定義し、特定のユーザー/グループのみがアクセスできるように権限を与える。（このルールはアイテムの継承関係に従い、配下のアイテムにも適用されます。）
3. Dataiku側でプロジェクトを作成する際、当該プロジェクトに対して、特定のユーザー/グループに対応した「タグ」を付与するような運用とする。
4. インスタンス設定の「Use script」を作成し、プロジェクトに特定のタグが付与されている場合は、そのプロジェクトを特定のBusiness Initiativeに紐づけるように設定する。

３．プロジェクト・バンドル・モデルでのGovern This Itemをしたときの挙動もご教授いただけますでしょうか？
具体的には、プロジェクト→GovernedProjectsに追加される
バンドル・モデル→Bundle（Model） Registry
に追加されるイメージなのですが、認識あっているか確認させていただきたいです。

はい、ご認識の通りです。組織のガバナンスポリシーに応じて、どちらの対応も可能です。
プロジェクトレベルの管理で良い場合、プロジェクト単位で管理していただければ結構です。より細かな粒度で管理したい場合（ガバナンス画面上で承認フロー実行、詳細確認したい場合）、バンドルやモデルバージョンに対して「Govern This Item」を行います。

4.　承認フローの設定でRole Assigmentsがありますが、管理者のみが設定できるように権限変更することは可能でしょうか？

添付いただいた画像は、「承認フロー設定」ではなく、BlueprintやGovern Itemの「Role Assignment Rule」の定義画面のようです。その場合、「Role Assignment Rule」の設定は、元々管理者（Administrator、Govern Architect）のみが設定可能な項目となります。まずはその点をご確認いただけますと幸いです。

https://doc.dataiku.com/dss/latest/security/govern-permissions.html#global-permissions-administrator-govern-architect

また、「承認フロー」という観点では、以前の回答に不十分な部分があるのに気づきました。その点を修正しましたので、お手数ですが以下の回答をあらためてご参照いただけますと幸いです。何卒よろしくお願いいたします。

https://community.dataiku.com/discussion/comment/47252/#Comment_47252

以下、回答いたします。

2番のところについて、Use Script機能を使ってとありますが、こちらを使用せずに運用する方法などはありますでしょうか？

現状のガバナンス機能の仕様では、BlueprintもしくはGovern Itemに対して参照権限がある場合、すべてのアイテムを参照できてしまいます。このため、「特定のプロジェクトのみをガバナンス対象にして、特定のテンプレートのみを適用したい。」という場合、やはりUse ScriptとBusiness Initiativeのような仕組みを利用して動的な制御を行う必要があります。（ただし、以下の回答に記載のように「ガバナンス対象にする前のプロジェクト自体の参照」については、別の仕組みで対応する形となります。）

また、手順の内容について「プロジェクトのタグとBisiness InitiativeをUse Scriptで紐づけ、BisinessInitiative でユーザーの閲覧を制御することによって、Governable Item（Govern設定していないプロジェクト）の表示閲覧も制御できる」という認識であってますでしょうか？

いえ、Use Scriptを利用した場合、プロジェクトは自動的にGovern Projectとして登録されますので、Governable Item（Govern設定していないプロジェクト）にはそもそも表示されない挙動になります。

もしGovernable Item（Govern設定していないプロジェクト）に表示されるアイテム自体を制御したい場合、管理画面の「Roles & Permissions > Blueprint-specific settings」にて、対象アイテムのBllueprint（Dataiku Projectなど）を指定して、ロールとタグをマッピングすることで実現可能と考えられます。（タグの情報は以下ドキュメントの画像に記載の「CRITERION」で指定することになります。）

https://knowledge.dataiku.com/latest/govern/permissions/basics/tutorial-index.html#assign-the-custom-role-to-a-group

ーーーーー
2026/3/21 追記：
Dataiku Version 14.4.0以降では、DSSプロジェクトのフォルダー情報をガバナンス機能に連携可能になりました。このため、上記回答に記載の「タグ」に加えて、プロジェクトの「フォルダー」に基づいて制御することも可能です。

はい。以下ドキュメントに記載の通り、異なるBlueprintを作成・適用したり、Use scriptを利用するためには、「Advanced License」 (Advanced Govern)が必要です。

https://knowledge.dataiku.com/latest/govern/overview/concept-governance-settings.html

添付していただいた画面に選択肢が出てこない理由としては、やはり「Advanced Licence」を導入されていないことが理由と考えられます。（もし仮に「Advanced Licenceを導入済みであるのに選択肢が表示されない」場合には、Governモジュールのバージョンが古い可能性はあるかもしれません。）

Governance settingsを開いた際に以下の項目しか設定できないのですが、この画面でProjectやBundleごとのUse Scriptの選択がでないのはAdvanced Licenceがないのが理由でしょうか？

モデルの承認が完了していなくても、バンドルの承認が完了している場合、プロジェクトをAutomationノードにデプロイすることは可能です。ただ、プロジェクトバンドルの承認ステップの中で、モデル承認プロセスの完了を目視で確認したり、モデル自体のプロセス管理・承認履歴を残す目的でモデル承認を利用する用途は考えられます。

もしこの様なチェックを強制したい場合、以下リンクに記載の「フック」を利用することで、バンドルの承認プロセス内でモデル承認プロセスの完了を自動的にチェックするなどの対応は可能と考えられます。（フック用のスクリプトは、Blueprintの承認フロー編集画面で定義可能です。）

https://developer.dataiku.com/latest/concepts-and-examples/govern/govern-advanced/govern-hooks.html

※ 上記の「フック」や「Blueprint編集」を利用する場合、「Advanced Govern」ライセンスが必要です。（すでにご認識済みの内容と存じますが、念のため補足させていただきます。）

ーーーーー

バンドルの承認が通っていても、モデルの承認が通っていない場合、Automationノードへのデプロイすることは可能でしょうか？

上記可能な場合、モデルだけの承認のユースケースについて何がかんがえられますでしょうか？

以下、回答させていただきます。

「Standard License」について、例えばGovernBundleではReviewフローにSIGN-OFFの設定が可能ですが、そちらのFeedbackとFinal approverにロールやグループを割り当てることはできない認識であってますでしょうか？

いえ、「Standard License」の場合、テンプレート（Blueprint）の新規作成や修正は不可ですが、Govern Projectの設定にて、承認者のロールやグループを割り当てることは可能です。以下のドキュメントをご参照ください。

https://knowledge.dataiku.com/latest/govern/overview/concept-reviews-signoffs.html#using-the-sign-off-process

すいません、追加でテンプレートのViewsも「Standard License」の場合は、編集できない認識であってますでしょうか？

はい。「Standard License」の場合、テンプレート（Blueprint）の新規作成や修正は不可であり、Viewsの編集もこれに含まれます。

すいません、事前に設定できるかという観点で、上記の画面でFeedback、Final approverが設定できるかと思いますが、こちらは変更可能な認識であってますでしょうか？

ユーザーやロールの追加は可能の認識で、各Feedback（IT & Operationsなど）は削除できない認識であってますでしょうか？

上記の画面はBlueprintの編集画面(Blueprint Designer)だと思います。その場合、これまでの回答に記載の通り以下のような挙動になります。

• Advanced License（Advanced Govern）の環境、かつ管理者権限を持つユーザーの場合、各設定の変更・削除が可能
• Standard License（Standard Govern）環境の場合、管理者権限を持つユーザーであっても、上記画面(Blueprint Designer)へのアクセス、および各設定の変更・削除は不可

以下、回答・コメントさせていただきます。

すいません、整理させていただくと以下の認識であってますでしょうか？

・Standard License（Standard Govern）環境の場合、Blueprint Designerでは編集が不可能なので事前にFeedbackのフローの削除やグループの割り当ても不可能

→ はい。ご認識の通りです。以前の回答（参照１、参照２）に記載の通りとなります。

・Govern ProjectにてRole Assigments　もしくは　ご提示いただいたDELEGATEで各FBのロールとグループが割り当てられるので、個別のアイテムごとで設定が必要

→ ご質問の内容を正確に理解したいと思いますので、具体的な画面の箇所をご教示いただけますと幸いです。

補足説明ありがとうございます。以下、コメントさせていただきます。

・Govern ProjectにてRole Assigments　もしくは　ご提示いただいたDELEGATEで各FBのロールとグループが割り当てられるので、個別のアイテムごとで設定が必要

Standard License（Standard Govern）の場合、標準テンプレートをそのままご利用いただく形となります。この標準テンプレートで定義されているロールとグループの紐付けは、各インスタンス（ガバナンスプロジェクト、バンドル・モデルバージョン）で個別に設定することも可能ですが、管理画面の「Roles & Permissions > Blueprint-specific settings」にて、事前に一括設定することが可能です。

この標準テンプレートでは「3種類のレビュアーと最終承認者」のロールのみが定義されています。また、承認プロセスが存在するのはバンドルとモデルバージョンのインスタンスのみであり、ガバナンスプロジェクト自体には承認プロセスは存在しません。詳細は以下のドキュメントをあらためてご参照いただけますと幸いです。

https://knowledge.dataiku.com/latest/govern/overview/concept-reviews-signoffs.html

Sign-offs can include two types of reviews: feedback reviews and final approvals.

Feedback	Feedback reviews are optional. They’re useful for gathering input and suggesting improvements. They also provide additional information to help final approvers make informed decisions. By default, IT & Operations, Risk & Compliance, and Business reviewers are three ready-made categories of reviewers.

Govern Projectのインスタンスで行う承認プロセスになりますので、個々のプロジェクト毎に設定を行うことが可能です。

恐れ入ります。エディターの問題？のためか、上記のコメントが正しく登録・編集できなかったため、あらためて回答を記載させていただきます。

ーーーーー

補足説明ありがとうございます。以下、コメントさせていただきます。

・Govern ProjectにてRole Assigments　もしくは　ご提示いただいたDELEGATEで各FBのロールとグループが割り当てられるので、個別のアイテムごとで設定が必要

Standard License（Standard Govern）の場合、標準テンプレートをそのままご利用いただく形となります。この標準テンプレートで定義されているロールとグループの紐付けは、各インスタンス（ガバナンスプロジェクト、バンドル・モデルバージョン）で個別に設定することも可能ですが、管理画面の「Roles & Permissions > Blueprint-specific settings」にて、事前に一括設定することが可能です。

この標準テンプレートでは「3種類のレビュアーと最終承認者」のロールのみが定義されています。また、承認プロセスが存在するのはバンドルとモデルバージョンのインスタンスのみであり、ガバナンスプロジェクト自体には承認プロセスは存在しません。詳細は以下のドキュメントをあらためてご参照いただけますと幸いです。

https://community.dataiku.com/home/leaving?allowTrusted=1&target=https%3A%2F%2Fknowledge.dataiku.com%2Flatest%2Fgovern%2Foverview%2Fconcept-reviews-signoffs.html

in the standard template, you’ll encounter sign-offs in two items: Govern bundles and Govern model versions.

According to the standard template, the Review workflow step for both of these items includes a mandatory sign-off. As a mandatory sign-off, users can’t progress to the item’s next workflow step without a final approval.

Sign-offs can include two types of reviews: feedback reviews and final approvals.

Feedback	Feedback reviews are optional. They’re useful for gathering input and suggesting improvements. They also provide additional information to help final approvers make informed decisions. By default, IT & Operations, Risk & Compliance, and Business reviewers are three ready-made categories of reviewers. Advanced license holders can change these categories in the Blueprint Designer.

Final approval

Only the final approval determines whether an item can advance in its workflow to the next stage. Moreover, from a deployment perspective, the Deployer only recognizes the state of the final approval.