ポータルモジュールの追加開発手順

「新しい案内をポータルに載せてほしい」「部門限定で見せたい」「カードが急に消えた」。ポータル担当には、こうした依頼と症状が同じ窓口に届きます。担当が2名しかいなければ、手順を頭の中に持つやり方は、休暇や異動で止まります。この記事は、ポータルへ機能を追加・変更する開発作業を14の手順に分け、着手前の確認・期待結果・中止条件まで書いた手順書です。

前提は、開発・検証用のインスタンスで作って確かめてから、更新セットで本番インスタンスへ移送する流れです。実際の検証は PDI 1つで行いました。開発手順(1)〜(4)と開発手順(10)は Australia の検証環境でテスト用のレコードを使って操作結果を確かめ、開発手順(14)は2つの症状を作って切り分けと復旧まで実行しました。開発手順(11)は主要画面の表示を確認しています。開発手順(12)は架空の記入例です。開発手順(5)〜(9)は、検証環境の標準のデモユーザー6名の見え方を確かめて、設定と解除まで実行しました。開発手順(13)は、その確認を取り直す手順です。更新セットの移送そのものは、単一の環境では確かめられないため検証範囲外です。中止条件には、実機で再現していないものも含みます。

この手順書でできること

• 依頼や症状から、実行する開発手順を番号で引ける（第1章）

• 承認済みの掲載を、下書きで作り込んで公開できる（開発手順(1)。無料部で通して読める）

• 部門限定の公開範囲の設定、テーマの変更、組織ごとの閲覧範囲の設定を、中止条件つきで実行できる（開発手順(2)〜(9)。無料部）

• 部品の差し替え、メジャーアップグレード後の確認、作業記録と引継ぎを、同じ書式で残せる（開発手順(10)〜(12)。有料部）

• 表示不具合の切り分けと復旧を、変更前の値へ戻すところまで実行できる（開発手順(14)。有料部）

この記事のモデル案件は架空の設計例です。国内の事業会社（従業員1,200名、本社と3拠点）が、問い合わせと申請の窓口を Employee Center に集約した想定で、ポータル担当2名が開発と保守を担います。次の値は架空なので、自社の値に置き換えてください。

• 平日9:00〜18:00対応、時間外は翌営業日

• 掲載ページ約20、ウィジェット配置約100、同時利用者は最大150

• 掲載の申請は人事・総務、承認と公開は情報システム部

• 切り分けの目標は、初動30分以内に「ポータル側・データ側・権限側」のどれかを特定すること

対象外は、モバイル専用ポータル、社外（取引先）への公開、多言語対応です。標準ポータル10種の外観と使い分けは、第1巻のポータルモジュールの概要にあります。テーブル構成・ロール・プロパティは第2巻の「ポータルモジュールの設定」に書きました。承認基準や体制は第5巻、技術仕様は第4巻で扱い、この巻は開発作業の操作に集中します。

1. 全手順に共通する事項

この章で決めること：誰が、どの環境で、どの手順を使い、何を作業記録に残すか。

対象者と前提スキル

• 対象者：ポータル担当（モデル案件では2名）。1人が実行し、もう1人が確認する

• 前提スキル：Service Portal 設定ポータル（/sp_config）の Pages・Widgets・Portals を開けること。レコードのフォームと一覧を開き、変更前の値を控えられること

• 前提ロール：実行者は sp_admin（Can manage the Service Portal）を持つこと。Draft のページを表示できるのは公式ドキュメントでは admin ロールだけなので、下書きの表示確認は admin を持つ担当者が行う

対象環境

• 開発・検証用のインスタンスで作って確かめてから、更新セットで本番インスタンスへ移送する流れ。本番インスタンスを直接変更しない

• この記事の検証は Australia の PDI 1つ。更新セットの移送そのものは単一の環境では確かめられないため未検証

• 作業先が開発・検証用であることは、着手前に毎回確かめる

手順の一覧

手順は構築・定常・障害時の3つに分けています。章は、構築が第2章と第3章（閲覧範囲）、定常が第4章、障害時が第5章です。所要時間は、人が実行したときの時間を測っていないため、すべて未計測です。

• 開発手順(1) 下書きページを作り、部品を置いて公開する（構築）：新しい案内の掲載依頼を承認済みで受けたとき。所要時間は未計測。必要なロールは sp_admin（表示確認は admin）

• 開発手順(2) 公開範囲用の User Criteria を作成する（構築）：部門限定の公開依頼を受けたとき。所要時間は未計測。必要なロールは user_criteria を作成できるロール（検証では admin）

• 開発手順(3) 公開範囲を設定し、表示を確認して、解除する（構築）：開発手順(2)の条件を対象につなぐとき。所要時間は未計測。必要なロールは、カテゴリと User Criteria を結ぶレコードを作れるロール（検証では admin）と、確認用ユーザー2名

• 開発手順(4) テーマの見た目を検証ポータルで変更し、本番ポータルへ反映する（構築）：ヘッダーの色など見た目の変更依頼を受けたとき。所要時間は未計測。必要なロールは sp_admin

• 開発手順(5) 組織ごとの User Criteria を作る（構築）：組織ごとに閲覧範囲を分ける依頼を受けたとき。所要時間は未計測。必要なロールは user_criteria を作成できるロール（検証では admin）

• 開発手順(6) カタログのカテゴリと商品へ閲覧範囲を設定する（構築）：申請を組織ごとに出し分けるとき。所要時間は未計測。必要なロールは接続を作れるロール（検証では admin）と、確認用ユーザー6名

• 開発手順(7) ナレッジベースと記事へ閲覧範囲を設定する（構築）：ナレッジを組織ごとに読ませ分けるとき。所要時間は未計測。必要なロールは knowledge_manager 以上（検証では admin）

• 開発手順(8) ポータルのページへロールで閲覧範囲を設定する（構築）：特定のページを管理職などだけに開くとき。所要時間は未計測。必要なロールは sp_admin とロールの付与権限

• 開発手順(9) ACL で項目単位の最終線を確認し、必要なら追加する（構築）：API 経由でも読ませない項目があるとき。所要時間は未計測。必要なロールは ACL を作れるロール（検証では admin）

• 開発手順(10) 部品の差し替えと公開停止（定常）：公開中の内容の修正・取り下げ依頼を受けたとき。所要時間は未計測。必要なロールは sp_admin

• 開発手順(11) メジャーアップグレード後の確認（定常）：製品のメジャーアップグレードが終わったとき。所要時間は未計測。必要なロールは、更新前後で同じ確認用ユーザーの権限

• 開発手順(12) 開発作業の記録と引継ぎの記入（定常）：すべての作業の最後。所要時間は未計測。必要なロールは、記録先に書き込める担当者

• 開発手順(13) 閲覧範囲の棚卸しと、異動・組織変更後の確認（定常）：四半期ごと、組織変更・大量の異動の後。所要時間は未計測。必要なロールは、設定を読めるロールと確認用ユーザー6名

• 開発手順(14) 表示不具合の切り分けと復旧（障害時）：部品が出ない、ページが開かないという症状を受けたとき。所要時間は未計測（初動30分は設計値）。必要なロールは sp_admin と、症状を再現できる一般の従業員の権限のユーザー

依頼と症状から手順を引く

依頼や症状に合う開発手順を、次の図で探します。該当する節だけを開いて作業を進めます。

図の内容を文字でも書き出します。

• 新しい案内を載せたい：開発手順(1)（下書きページを作り、部品を置いて公開する）

• 載せた内容を直す・止める：開発手順(10)（部品の差し替え・公開停止）

• 部門だけに見せたい（最小の1件）：開発手順(2)（User Criteria の作成）から 開発手順(3)（カテゴリへの設定）

• 組織ごとに見える範囲を分けたい：開発手順(5)（条件の作成）から、開発手順(6)（カタログ）、開発手順(7)（ナレッジ）、開発手順(8)（ページ）、開発手順(9)（ACL）

• 異動・組織変更があった：開発手順(13)（閲覧範囲の棚卸し）

• ヘッダーの色を変えたい：開発手順(4)（検証ポータルで確認してから本番ポータルへ反映）

• 部品が出ない・ページが開かない：開発手順(14)（切り分けと復旧）

• メジャーアップグレードが終わった：開発手順(11)（主要画面の確認）

• 作業を記録・引き継ぐ：開発手順(12)（記入書式）

モデル案件の要件との対応は次のとおりです。第4巻の設計n（設計(1)〜(6)）と第5巻の運用ルールn（運用ルール(1)〜(6)）は、要件と同じ番号で対応させる暫定の採番で、第4巻・第5巻で確定します。

• 要件(1)（1画面から問い合わせ・申請・検索）：開発手順(1)

• 要件(2)（部門限定情報を対象外に出さない）：開発手順(2)、開発手順(3)、開発手順(5)〜(9)、開発手順(13)

• 要件(3)（申請者と別の人が承認してから公開）：開発手順(1)、開発手順(10)

• 要件(4)（表示崩れの切り分けを2名で回す）：開発手順(14)

• 要件(5)（本番反映前に検証環境で確認）：開発手順(4)

• 要件(6)（更新後に主要画面を確認）：開発手順(11)

作業記録の残し方

すべての手順に共通する作法です。着手前の確認と、作業記録に残す内容を示します。書式は開発手順(12)にあります。

1. 承認済みの依頼票IDを、作業記録の先頭に書く（形式は自社で決める。例：REQ-2026-0012）

2. /sp_config を開き、上部メニューの Pages、Widgets、Portals が表示されることを確かめる。表示されなければ実行資格がないため着手しない

3. 変更する画面で、変更前の値（sys_id、チェックの状態、ロール、CSS変数）を作業記録へ写す。新規作成は変更前を「なし（新規）」と書く

4. 手順を実行し、変更後の値・確認者・表示のスクリーンショットの保存先を、作業の終了時に追記する

依頼票IDがない、実行資格がない、変更前の値を控えられない、のいずれかなら着手しません。判断できない依頼は変更せず、開発手順(12)の引継ぎ票へ回します。実行はポータル担当、承認条件は第5巻の運用ルール(3)、技術仕様は第4巻の設計(3)を参照します（番号のみ）。Australia の検証環境で /sp_config を開いて動作を確かめています。メジャーアップグレード後（開発手順(11)）に見直します。

2. 構築の手順

この章で決めること：ページの新規公開、公開範囲の設定、テーマの変更を、中止条件つきで実行すること。

開発手順(1) 下書きページを作り、部品を置いて公開する

sp_page の Draft（下書き）をチェックしたまま作り込み、仕上がってからチェックを外して公開する手順です。Draft のページは、管理者だけに見えます。

1. 目的と実施の契機

新しい案内を載せる依頼が承認されたときに実施します。sp_page の Draft（下書き）をチェックしたまま作り込み、仕上がってからチェックを外して公開します。対象は sp_page、sp_container、sp_row、sp_column、sp_instance、要件は 要件(1)（窓口の一本化）・要件(3)（承認後の公開） です。実行はポータル担当、掲載の承認は第5巻の運用ルール(3)（承認後の公開）、ページ構成の仕様は第4巻の設計(3)（承認後の公開） を参照します（番号のみ）。

2. 前提条件・必要なロール・承認

承認済みの依頼票ID、sp_admin、対象ポータルのURLサフィックス、掲載内容（タイトルと置くウィジェット）。Draft のページを表示できるのは公式ドキュメントでは admin ロールだけなので、手順5は admin を持つ担当者が行います（sp_admin のみの場合は admin 担当者へ依頼します）。

3. 事前確認

• 共通の着手前確認（第1章の作業記録の残し方）が済んでいること。変更前の値は「なし（新規）」と書く

• 作成するページの ID が既存のページと重複しないことを、sp_page_list.do で確かめる

• 作業先が開発・検証用のインスタンスであること

4. 手順（操作｜期待結果・分岐）

1. /sp_config の Pages、または sp_page_list.do から New を押す。Title と ID を入力し、Draft にチェックを入れて保存する。期待結果：保存される。ID は小文字・英数字と _ に自動で整形される

2. 整形後の ID を作業記録に写す。期待結果：入力した Kiji Kensho-Ops_Test が kiji_kensho_ops_test に変わる。空白とハイフンが _ になり、大文字が小文字になる。分岐：別のページと ID が重複する場合は保存を中止して依頼票へ戻す

3. ページフォームの下部「Page Content」に、コンテナ・行・列を1つずつ作る。期待結果：Container 0、Row 0、Column 0 の階層が表示される

4. 列に、ウィジェットの配置を1件作る。Widget にウィジェット、Title に表示名を入力する。期待結果：sp_instance の一覧に1件出る。検証では、標準の HTML ウィジェットを置き、配置のオプション（html）に「人事からのお知らせ　年末調整の提出期限は12月10日です。」というカードの本文を入れた

5. /<URLサフィックス>?id=<整形後のID> を管理者で開く。期待結果：ページ上端に赤字「This page is in draft」が出て、部品が表示される。分岐：部品が出なければ公開せず 開発手順(14)（表示不具合の切り分け）へ

6. ページフォームで Draft のチェックを外して保存する。期待結果：保存される

7. 同じURLを再読み込みする。期待結果：赤字が消え、部品だけが表示される。続けて、ロールを持たない一般の従業員の権限で同じURLを開き、部品が表示されることを確かめる。表示されなければ Draft をオンに戻して中止し、URLと画面を依頼票へ記録する

8. 表示のスクリーンショットと sys_id を依頼票へ貼る

①のIDは、手順2で作業記録に写す値です。②の Draft は手順6でオフにする欄、③の Roles は空欄です。検証では、公開後にロールを持たない HR 所属の確認用ユーザーでも表示できました。ページ自体の User Criteria による制限は未検証です。Roles に値を入れる方法はモデル案件では採用せず、公開範囲は第3章（開発手順(2)（User Criteria の作成）、開発手順(3)（公開範囲の設定と解除））で扱います。

ウィジェットの配置は、手順4で作った1件が一覧に表示されていれば完了です。

手順5の見え方は次のとおりです。

①の赤字は、Draft のページを開いているという管理者向けの目印です。一般の従業員にはこのページ自体が表示されず、404になります（開発手順(10)：部品の差し替えと公開停止で確認します）。一般の従業員の見え方は、公開後にしか確かめられません。

公開後（手順7）は、赤字のない表示になります。

5. 結果確認と証跡

公開後のURL表示のスクリーンショット、sp_page の sys_id と Draft がオフであること、依頼票への貼付を残します。検証環境で実行済みで、メジャーアップグレード後（開発手順(11)：アップグレード後の確認）に見直します。

検証は Scripts - Background でレコードを更新し、画面で表示を確認しました。公開操作は6.0秒、ほかの更新は約3秒で、期待どおりに進みました。画面から保存した場合の所要時間は測っていません。

6. 異常時の中止条件と連絡先

• ID が既存のページと重複する：保存せず依頼票へ戻す

• 手順5で部品が出ない：公開しない。開発手順(14)（表示不具合の切り分け）の切り分けへ進む

• 公開後に表示が崩れた：Draft のチェックを戻して公開を止め、開発手順(10)（部品の差し替えと公開停止）の公開停止を実行する

連絡先は、判断できないときに変更せず回す開発手順(12)（作業記録と引継ぎ）の引継ぎ票と、第5巻の運用ルール(4)（表示崩れの切り分け）の窓口です。

7. 切り戻しと後片付け

• 公開後に表示が崩れたら、Draft のチェックを戻して公開を止め、開発手順(10)（部品の差し替えと公開停止）の公開停止を実行する

• テスト用に作ったページと配置は、作業の最後に下位（配置・列・行・コンテナ）から上位（ページ）の順で削除する。検証でも最後に削除し、削除後のテーブル件数が事前の件数と一致することを確かめた

• 一般の従業員の権限での確認には、ロールを持たない確認用ユーザーを使い、権限を一時的に付けない。別ブラウザのインパーソネートは確認後に終了する

• レコードを削除しても、更新セット側の記録（sys_update_xml）は残る。移送に持ち込まない方法は付録を参照する

記入例（モデル案件の架空ID）

依頼票ID  : REQ-2026-0012（人事部 掲載担当 申請／情報システム部 承認済み）
対象      : 人事からのお知らせページ（ID: hr_notice）
変更前    : なし（新規作成）
作業      : Draft ON で作成 → コンテナ1・行1・列1 → ウィジェット1件配置
            → 管理者で表示確認 → Draft OFF
確認者    : ポータル担当B（実行者はポータル担当A）
証跡      : 公開後の表示画像、sp_page の sys_id
結果      : 完了

開発手順(2) 公開範囲用の User Criteria を作成する

User Criteria は、「どの利用者を対象にするか」の条件を1件のレコードにしたものです。ロール・グループ・部署・会社・場所などを指定できます。この手順では作成だけを行い、まだどこにもつなぎません。

1. 目的と実施の契機

部門限定の公開依頼を受け、公開範囲の対象条件を1件のレコードにするときに実施します。対象は user_criteria、要件は 要件(2)（限定情報の非表示） です。この手順では作成だけを行い、まだどこにもつなぎません（つなぐのは開発手順(3)：公開範囲の設定と解除）。実行はポータル担当、対象の決定は第5巻の運用ルール(2)（限定情報の非表示）、条件の構成は第4巻の設計(2)（限定情報の非表示） を参照します（番号のみ）。

2. 前提条件・必要なロール・承認

承認済みの依頼票ID、対象条件（ロール・グループ・部署のどれか。モデル案件では総務部所属）、user_criteria を作成できる権限（検証では admin で作成できた）。

3. 事前確認

• 対象条件が1つに決まっていること。承認された部署を特定できない場合は作成しない

• 条件を複数入れる場合は、Match All で判定が切り替わる（公式ドキュメント）。オフ（既定）なら、いずれかの条件に合う利用者が対象。オンなら、入力した各条件項目の値すべてに合う利用者が対象。矛盾する条件を作らないよう注意書きがある

• 共通の着手前確認が済んでいること

4. 手順（操作｜期待結果・分岐）

1. user_criteria_list.do から New を押す

2. Name に、用途が分かる名前を入力する。検証では「記事検証: 総務部のみ」とした（条件には検証用の HR 部門を代用した。総務部として使う場合は、承認された総務部を選ぶ。該当部署を特定できなければ保存しない）

3. 条件を1つだけ設定する。検証では Departments に HR を指定した

4. Active にチェックが入っていることを確かめて保存する。期待結果：保存され、sys_id が発行される

①の名前は、後で一覧から探すための手がかりです。②の条件は1つだけ設定しています。

フォーム上部の案内は、User Criteria の適用先として Change Models、Service Catalog、Knowledge を挙げています。公式ドキュメントの「Create a user criteria record for Service Portal」は、Service Portal のページやウィジェットにも設定できると書いています。一方で、検証した環境では、sp_page と sp_instance のフォームに User Criteria を登録する関連リストが見つかりませんでした。詳しくは付録と末尾の検証範囲に書きます。

5. 結果確認と証跡

sys_id、名前、条件画面のスクリーンショットを残します。検証環境で作成を実行済みです。Match All の差は、条件を1つにしたため実機では確かめていません。メジャーアップグレード後に見直します。

6. 異常時の中止条件と連絡先

対象範囲が判断できないときは作らず、第5巻の承認者へ戻します。判断できない依頼は変更せず、開発手順(12)（作業記録と引継ぎ）の引継ぎ票へ回します。

7. 切り戻しと後片付け

• 作成直後の User Criteria は未接続（接続レコード0件）なので、不要になったらそのレコードを削除する

• 開発手順(3)（公開範囲の設定と解除）でつないだ後に削除する場合は、先に開発手順(3)の手順5で接続を解除する

• 検証用に作った User Criteria は、作業の最後に削除し、削除後の件数が事前と一致することを確かめた

開発手順(3) 公開範囲を設定し、表示を確認して、解除する

開発手順(2)（User Criteria の作成）で作った User Criteria を、公開範囲を絞りたい対象につなぎます。検証で実際に効いたのは、Service Catalog のカテゴリ（sc_category）の Available for（sc_category_user_criteria_mtom）です。

1. 目的と実施の契機

開発手順(2)（User Criteria の作成）で作った User Criteria を、公開範囲を絞りたい対象につなぐときに実施します。対象は sc_category と sc_category_user_criteria_mtom、要件は 要件(2)（限定情報の非表示） です。実行はポータル担当、公開範囲の承認は第5巻の運用ルール(2)（限定情報の非表示）、評価順は第4巻の設計(2)（限定情報の非表示） を参照します（番号のみ）。

2. 前提条件・必要なロール・承認

開発手順(2)（User Criteria の作成）の User Criteria、対象のカテゴリ、確認用ユーザー2名（対象内1名、対象外1名）。確認用ユーザーがいない場合は実行しません。

3. 事前確認

• 確認用のカテゴリに、必ず商品を1件入れておく。商品が1件もないカテゴリは、管理者でも「You do not have permission to see this category」と表示され、対象外の表示と区別がつかない

• 確認用ユーザー2名がそろっていること。いない場合は中止して開発手順(12)（作業記録と引継ぎ）の引継ぎ票へ回す

• 開発手順(2)（User Criteria の作成）の User Criteria が Active であること

4. 手順（操作｜期待結果・分岐）

1. 登録前に、対象内・対象外のユーザーそれぞれで対象カテゴリを開き、どちらにも見えることを記録する

2. sc_category_user_criteria_mtom に新規レコードを作る。Category に対象カテゴリ、Available for に 開発手順(2)（User Criteria の作成）の User Criteria を入れて保存する。期待結果：保存される

3. 対象内のユーザーで、同じカテゴリを開く。期待結果：カテゴリも商品カードも見える

4. 対象外のユーザーで、同じカテゴリを開く。期待結果：左のカテゴリ一覧にも出ず、本文に「You do not have permission to see this category」と表示される

5. 解除する場合は、手順2のレコードを削除する。期待結果：対象外のユーザーにも、再び見える

①が、手順2で入れる値です。1件のレコードで、カテゴリと User Criteria が結ばれます。

登録後の対象内ユーザーの画面は次のとおりです。確認用ユーザーには、検証環境に標準で入っているデモユーザーを使いました。対象内は HR 所属、対象外は Finance 所属の各1名です。

①と②が、手順3の期待結果です。対象外のユーザーでは、次のとおり見えません。

①が手順4の期待結果です。左の一覧にもカテゴリ名が出ていない点も、記録する項目に含めます。

5. 結果確認と証跡

対象内・対象外それぞれの表示のスクリーンショット、登録レコードを残します。検証環境で登録・確認・解除を実行済みです。カテゴリ経由の見え方を確かめました。商品の直接URL、検索、API での見え方は、開発手順(6)（カタログの閲覧範囲）で確かめています。メジャーアップグレード後（開発手順(11)：アップグレード後の確認）に見直します。

6. 異常時の中止条件と連絡先

対象外にも見えるときは、登録の保存先・User Criteria が Active か・ロールの設定を見直して開発手順(14)（表示不具合の切り分け）へ進みます。確認用ユーザーがいないときは中止して、開発手順(12)（作業記録と引継ぎ）の引継ぎ票へ回します。

7. 切り戻しと後片付け

• 解除は、手順2のレコードを削除する（手順5）。対象外のユーザーにも再び見えることを確かめる

• 確認用のテスト商品を作った場合、商品作成で sc_cat_item_category と sc_cat_item_catalog が各1件自動で増える。商品・カテゴリ・User Criteria の順で、自動で増えた2件も一緒に削除する

• 確認用ユーザーにはロールを付けない。検証でもロール0件のまま、インパーソネートは確認後に終了した

開発手順(4) テーマの見た目を検証ポータルで変更し、本番ポータルへ反映する

テーマはポータルの見た目（色など）を決めるレコードで、CSS variables に色の変数を持ちます。この手順は、先に検証用のポータルで変更を確かめ、問題がなければ本番用のポータルのテーマへ同じ変更を入れます。

1. 目的と実施の契機

ヘッダーの色など、ポータルの見た目を変更する依頼を受けたときに実施します。対象は sp_theme の CSS variables と、検証用・本番用の2つのポータル、要件は 要件(5)（本番反映前の確認） です。実行はポータル担当、本番へ入れる条件は第5巻の運用ルール(5)（本番反映前の確認）、CSS変数の正本と環境差分は第4巻の設計(5)（本番反映前の確認） を参照します（番号のみ）。

2. 前提条件・必要なロール・承認

承認済みの依頼票ID、変更する CSS 変数名と値、現在値の控え、検証ポータルと本番ポータルのURL。検証用と本番用が別のテーマを使っていること。

3. 事前確認

• 検証用テーマの CSS variables の現在値を、作業記録へ写す（手順1）

• 検証用と本番用のポータルが別のテーマを使っていることを確かめる

• ポータルを新規に作る場合は、付録の注意（自動で作られる設定）を先に読む

4. 手順（操作｜期待結果・分岐）

1. 検証用テーマの CSS variables の現在値を、作業記録へ写す（例：$navbar-inverse-bg: #293e40 !default;）

2. 検証用テーマの変数を変更して保存する。検証では #293e40 を #8a1c1c にした

3. 検証ポータルのURLを開く。期待結果：ヘッダーの色が変わる。検証では、保存から9秒後に反映されていた。反映までの最短時間は測っていない

4. 本番ポータルのURLを開く。期待結果：旧色のまま。テーマ単位の変更なので、別のテーマを使うポータルには及ばない。検証側が指定色になり、本番側が旧色のままである場合だけ手順5へ進む。どちらかが外れたら本番へ入れず中止し、両方のURL・テーマの識別子・画面を記録して引き継ぐ

5. 本番用テーマの同じ変数へ、同じ変更を入れて保存する

6. 本番ポータルのURLを開く。期待結果：ヘッダーの色が変わる

7. 戻す場合は、控えた値へ戻して保存する。期待結果：元の色に戻る（検証でも元の色に戻った）

①の行が、手順2で書き換える変数です。変更後の検証ポータルは次のとおりです。

①が手順3の期待結果です。同じ時点の本番ポータルは、次のとおり旧色のままです。

①が手順4の期待結果です。この確認を省くと、テーマ単位の変更が本番に及ぶかどうかが分からなくなります。

5. 結果確認と証跡

変更前後の値、検証と本番の2つのURLのスクリーンショットを残します。検証環境で、テスト用のテーマ2件とポータル2件を作って実行済みです。標準のポータル（esc、sp など）は変更していません。別のインスタンスへの更新セットの移送は、単一の環境では検証できないため範囲外です（付録と末尾に書く）。

6. 異常時の中止条件と連絡先

検証ポータルで表示が崩れたら、本番用テーマには入れず中止します。本番反映後に崩れたら、控えた本番用テーマの値へ戻して保存し、同じURLで復元を確かめる。戻らなければ追加の変更を止め、変更前後の値と画面を添えて開発手順(12)（作業記録と引継ぎ）の引継ぎ票へ回す。

7. 切り戻しと後片付け

• 戻す場合は、控えた値へ戻して保存する（手順7）。検証でも元の色に戻った

• テスト用にポータルを作った場合は、ポータル1件につき自動で作られる sys_analytics_bucket（Usage Insights Setting）1件と、glide.service_portal.resize_text.<url_suffix>.enable_rem_conversion というシステムプロパティ1件も、ポータルと一緒に削除する

• テスト用に作ったテーマも削除し、削除後の件数が事前と一致することを確かめる。検証でもテーマ2件とポータル2件を削除した

• 更新セットの記録（sys_update_xml）は削除後も残るため、付録の方法で作業用の更新セットを分ける

3. 閲覧範囲の手順

この章で決めること：どの組織に何を見せるかを、カタログ・ナレッジ・ページ・ACL の順に設定し、見え方を利用者の画面で確かめること。

閲覧範囲の事例（モデル案件の拡張）

モデル案件（従業員1,200名、本社と3拠点）に、次の分け方を加えた架空の事例です。

• 全従業員：共通の問い合わせ、申請、FAQ

• 人事部：部門内だけの申請（人事内部手続き）とナレッジ（人事内部の運用メモ）

• 本社所属の人事部：人事部の中でも本社所属の人だけが使う申請（手当申請）

• 大阪拠点：拠点限定の設備申請（会議室の予約）

• 管理職：管理職だけの申請（部下のアカウント申請）とナレッジ（評価制度の手引き）

• 外部委託（社内アカウントあり）：申請できるものを絞る。管理職向けの情報は見せない

検証では、検証環境に標準で入っているデモユーザー6名を、次の役割の代役にしました（氏名は画像に出しません）。部署と所在地は利用者レコードの値で、大阪拠点と本社は検証環境にある別の拠点で代用しています。

• 人事部・本社所属：部署が HR で、所在地が本社の代用拠点のユーザー

• 人事部・他拠点：部署が HR で、所在地が別拠点のユーザー

• 大阪拠点：所在地が大阪の代用拠点のユーザー

• 管理職：「管理職」グループのメンバー

• 外部委託：会社が別で、「管理職」グループにも入っているユーザー（優先順位を確かめるため）

• 一般従業員：どの条件にも当てはまらないユーザー

6名とも、確認時点でロールを1つも持たない状態です。開発手順(8)（ページのロール設定）だけは、ロールを付けた状態を別に確かめます。テスト用のレコードは、名前の先頭を「記事検証」にしました（ページIDは kiji_kensho_view_mgr、ロール名は kiji_kensho_manager）。作業の最後に、名前・IDで特定して削除しました。

閲覧範囲を分ける層と、効く範囲

分ける層は4つあり、効く範囲が異なります。実機で確かめた結果を先に示します。

• カタログの商品に付けた User Criteria は、直接URL・検索・Table API のすべてで効きました。公式ドキュメントは、商品の制限が適用されるのは Service Catalog の中で、テーブル経由のアクセスには及ばないと書いています。この環境では、商品の読み取り ACL（sc_cat_item）がスクリプトで閲覧可否を判定していたため、Table API も絞られました。他の環境では、既存の ACL と API の結果を先に確かめてください

• カタログのカテゴリに付けた User Criteria は、カテゴリを開く画面にだけ効きました。カテゴリ内の商品には及ばず、商品を直接URLで開くと全員に見えました。公式ドキュメントも「カテゴリの条件は、カテゴリ内の商品に自動では適用されない」と書いています

• ナレッジベースの Can read と記事の Can read／Cannot read は、記事の表示と Table API の両方に効きました。ナレッジベースを新規に作ると、Can read に標準の Any User が自動で入ります

• ポータルのページは、User Criteria ではなく Roles 欄（ロール名）で絞ります。この環境では、ページ向けの User Criteria を使うプラグインが有効化されていません。ロールを付けると、ナレッジの見え方まで変わることを確かめました

開発手順(5)（組織ごとの User Criteria）で条件を作り、開発手順(6)〜(8)で層ごとにつなぎ、開発手順(9)（ACL の確認）で項目単位の最終線を置きます。

図の内容を文字でも書き出します。

• 起点は利用者の属性（部署・所在地・グループ・会社）。条件を1件にまとめたレコードが User Criteria で、作っただけではどこにもつながない（開発手順(5)）

• 商品（開発手順(6)）：Available for／Not available for。直接URL・検索・Table API のすべてに効く

• カテゴリ（開発手順(6)）：Available for／Not available for。カテゴリを開く画面だけに効き、カテゴリ内の商品には及ばない

• ナレッジベース・記事（開発手順(7)）：Can read／Cannot read。記事の表示と Table API の両方に効く

• ポータルのページ（開発手順(8)）：User Criteria を使わず、Roles 欄のロール名で絞る。ロールを持たない人には Not Found が出る

開発手順(5) 組織ごとの User Criteria を作る

User Criteria は、部署・所在地・グループ・会社などの条件を1件にまとめたレコードです。この手順では、事例の組織を表す5件を作ります。どこにもつなぎません。

1. 目的と実施の契機

組織ごとに閲覧範囲を分ける依頼を受けたときに実施します。対象は user_criteria、要件は 要件(2)（限定情報の非表示） です。条件の種類と組み合わせの決定は第4巻の設計(2)（限定情報の非表示）、対象組織の承認は第5巻の運用ルール(2)（限定情報の非表示）を参照します（番号のみ）。

2. 前提条件・必要なロール・承認

承認済みの依頼票ID、対象組織の一覧、user_criteria を作成できる権限（検証では admin で作成できた）。「管理職」のようにグループで表す組織は、グループとメンバーが先に必要です。

3. 事前確認

• 組織を表す条件を、利用者レコードの項目に対応づけておく。部署と所在地は利用者レコードの項目、管理職はグループのメンバー、外部委託は会社で表した

• 公式ドキュメントによると、標準の条件は利用者の部署や所在地の更新が即時に反映される。グループは、メンバーの追加と削除の運用が要る。異動への追従が必要な組織は、部署・所在地・会社で表せないかを先に考える

• 条件を複数入れる場合の判定は Match All で切り替わる。オフ（既定）なら、いずれかの条件に合う利用者が対象。オンなら、入力した条件項目すべてに合う利用者だけが対象

4. 手順（操作｜期待結果・分岐）

1. 管理職を表すグループ（検証では「記事検証 管理職」）を作り、対象のメンバーを加える。期待結果：メンバーが登録される

2. user_criteria_list.do から New を押し、Name を「記事検証: 人事部」、Departments を HR にして保存する。期待結果：保存される。Match All はオフのまま

3. 同様に「記事検証: 人事部かつ本社所属」を作る。Departments を HR、Locations を本社の代用拠点にし、Match All をオンにする。期待結果：HR 所属かつその拠点の利用者だけが対象になる

4. 「記事検証: 大阪拠点」を作る。Locations に大阪の代用拠点を指定する

5. 「記事検証: 管理職」を作る。Groups に手順1のグループを指定する

6. 「記事検証: 外部委託」を作る。Companies に、外部委託の代用にした会社を指定する

7. 一覧で5件の条件列を確かめる。期待結果：Departments・Groups・Locations・Companies のうち、指定した列だけに値が入っている

①の行だけ Match All が true で、部署と所在地の両方に合う利用者だけが対象になります。②はグループ、③は所在地を条件にした行です。

5. 結果確認と証跡

一覧のスクリーンショットと各レコードの sys_id を残します。検証環境で5件の作成を実行済みです。作成直後の5件はどこにも接続されておらず、閲覧範囲は変わりません。

6. 異常時の中止条件と連絡先

対象組織を利用者の項目で表せない場合は、作成せずに第5巻の承認者へ戻します。グループで表す場合は、メンバーの管理者が決まるまで着手しません。判断できない依頼は変更せず、開発手順(12)（作業記録と引継ぎ）の引継ぎ票へ回します。

7. 切り戻しと後片付け

• 接続前の条件は、レコードを削除して戻す。接続後に削除する場合は、先に接続（開発手順(6)〜(7)）を解除する

• 検証では、グループ、メンバー、5件の条件を作業の最後に削除し、件数が事前と一致することを確かめた

開発手順(6) カタログのカテゴリと商品へ閲覧範囲を設定する

カテゴリと商品のそれぞれに、Available for（対象にする条件）と Not available for（対象から外す条件）を付けます。カテゴリの条件は商品に及ばないため、商品にも付けます。

1. 目的と実施の契機

人事向け・拠点向け・管理職向けの申請を、対象外の人に出さないときに実施します。対象は sc_category、sc_cat_item、各 Available for／Not available for の接続テーブル、要件は 要件(2)（限定情報の非表示） です。実行はポータル担当、公開範囲の承認は第5巻の運用ルール(2)（限定情報の非表示）、評価順は第4巻の設計(2)（限定情報の非表示）を参照します（番号のみ）。

2. 前提条件・必要なロール・承認

開発手順(5)（組織ごとの User Criteria）の条件、対象のカテゴリと商品、確認用ユーザー6名。接続の作成は admin で行いました（公式ドキュメントでは Role required: admin。カタログ管理者は既存の条件を付けるだけ）。

3. 事前確認

• 設定前の見え方を、全員分記録する。検証では、設定前は一般従業員にも人事向けのカテゴリと商品がすべて開けた

• 準備：カテゴリ2つ（人事向け、共通）と商品6つ（人事内部手続き、設定なし申請、大阪会議室、部下のアカウント申請、人事部本社の手当、全社共通）、確認用ユーザー6名を、開発手順(5)（組織ごとの User Criteria）の対応のとおり用意する。確認用ユーザーを一意に選べない場合は、中止する

• 利用者の切り替え：管理者の画面からユーザーメニューの Impersonate User で確認用ユーザーを選ぶ（検証では、別のブラウザセッションで管理者としてログインし、インパーソネートした）。画面右上のユーザー表示で、確認中の利用者を確かめてから開く。確認が終わったら、インパーソネートを終了する

• API の確認：インパーソネート中のブラウザで、同じセッションのままURLを開く。管理者のセッションで呼ぶと、確認図と比べられない。HTTP 403、0件、項目が返らない、を区別して記録する。要求自体が失敗したときは、閲覧制限の成功と判定しない

• 商品が1件もないカテゴリは、管理者でも「You do not have permission to see this category」と表示される。確認用のカテゴリには必ず商品を入れる

• 商品を新規に作ると sc_cat_item_category と sc_cat_item_catalog が各1件自動で増える。後片付けの対象に加える

4. 手順（操作｜期待結果・分岐）

1. カテゴリ「記事検証 人事向け」の Available for に「記事検証: 人事部」を接続する。期待結果：カテゴリの接続が1件できる

2. 商品ごとに Available for を接続する。人事内部手続きに人事部、大阪会議室の予約に大阪拠点、部下のアカウント申請に管理職、人事部本社の手当申請に「人事部かつ本社所属」を接続する

3. 部下のアカウント申請の Not available for に「記事検証: 外部委託」を接続する。期待結果：商品フォームの2つの関連リストに、それぞれ(1)と表示される

4. 確認用ユーザー6名で、カテゴリのURL、商品のURL、検索（「記事検証」）、Table API を順に開く。期待結果：直接URLと Table API は次の確認図のとおり。検索は、設定なし申請が人事部のユーザーにだけ出る。対象外の利用者に見えたとき、または対象の利用者に見えないときは、正常終了としない。後続の作業を止める

5. 解除する場合は、変更前に記録した Available for／Not available for の構成へ戻す。期待結果：変更前に記録した見え方と一致する（検証では、設定前の接続は0件だったため、接続の削除で全員に見える状態へ戻った）

①と②のタブに接続件数が出ます。部下のアカウント申請では、管理職を対象にしつつ、外部委託を除外しています。

対象外のユーザーは、カテゴリを直接開くと①のメッセージが出ます。②の一覧にも出ません。

外部委託のユーザーは、管理職グループのメンバーでもあります。Not available for が優先されるため、①のとおり開けません。公式ドキュメントも「Not available for が Available for を上書きする」と書いています。

図の内容を文字でも書き出します。

• 対象の商品：部下のアカウント申請（Available for＝管理職、Not available for＝外部委託）

• 1つ目の判定は Not available for。外部委託に合う利用者は見えない（管理職グループにも入っていても、こちらが優先される）

• 外部委託に合わない場合は、2つ目の判定の Available for へ進む。管理職に合えば見える

• 管理職にも合わない利用者（人事部・大阪拠点・一般従業員）は見えない

カテゴリだけに条件を付けた商品（設定なし申請）は、一般従業員が直接URLを開くと①の商品名と②の注文ボタンまで出ました。カテゴリの条件は、カテゴリ内の商品を守りません。商品側にも条件を付けます。

図の内容を文字でも書き出します。

• 前提：人事向けカテゴリの Available for は人事部。見る人はどの条件にも当てはまらない一般従業員

• カテゴリのページ：見えない（権限がない旨のメッセージ）

• 設定なし申請（商品に条件なし）を直接URLで：見える。商品名と Order Now まで出る

• 人事内部手続き（商品の Available for＝人事部）を直接URLで：見えない

検索でも、対象外の商品は出ません。大阪拠点のユーザーには①と②の2件だけが並びました。

確認の結果は次の図のとおりです（見え方の確認図）。列が確認用ユーザー、行が掲載物で、行の下の小さな文字がつないだ条件です。列の下の小さな文字は属性で、「グループ」は管理職グループへの所属、外部委託の「別会社＋グループ」は会社が別で管理職グループにも入っていることを表します。

図の内容を文字でも書き出します。

• 人事部・本社所属：申請は人事内部手続き、人事部本社の手当、設定なし申請、全社共通。記事は人事メモと全社FAQ。管理職ページは開けない

• 人事部・他拠点：申請は人事内部手続き、設定なし申請、全社共通（本社限定の手当申請は開けない）。記事は人事メモと全社FAQ。管理職ページは開けない

• 大阪拠点：申請は大阪会議室、設定なし申請、全社共通。記事は全社FAQ。管理職ページは開けない

• 管理職：申請は部下のアカウント、設定なし申請、全社共通。記事は全社FAQと評価制度の手引き。管理職ページは開けない

• 外部委託（管理職グループ所属）：申請は設定なし申請、全社共通。記事は全社FAQ。管理職ページは開けない

• 一般従業員：申請は設定なし申請、全社共通。記事は全社FAQ。管理職ページは開けない

申請の列は、直接URLと Table API（/api/now/table/sc_cat_item）の結果です。検索結果は、設定なし申請が人事部のユーザーにだけ出る点が異なります。

5. 結果確認と証跡

ユーザーごとの表示のスクリーンショットと、接続レコードの一覧を残します。検証環境で設定・確認・解除を実行済みです。公式ドキュメントは、標準の条件では利用者の部署や所在地の変更が即時に反映されると書いていますが、この反映は今回の検証では確かめていません。

6. 異常時の中止条件と連絡先

対象外にも見えるときは、接続を記録した構成へ戻したうえで、接続先が商品かカテゴリか、条件が Active か、Match All の設定を見直して、開発手順(14)（表示不具合の切り分け）へ進みます。確認用ユーザーが6名に満たないときは中止し、開発手順(12)（作業記録と引継ぎ）の引継ぎ票へ回してください。条件の変更後に再ログインが要る場合がある、という公式ドキュメントの注意もあります。

7. 切り戻しと後片付け

• 接続レコードを削除する。商品を作った場合は、商品の削除と一緒に、自動で増えた2件（sc_cat_item_category、sc_cat_item_catalog）も削除する

• 商品、カテゴリ、User Criteria の順に削除し、削除後の件数が事前と一致することを確かめた

• 確認用ユーザーにはロールを付けない。インパーソネートは確認後に終了する

開発手順(7) ナレッジベースと記事へ閲覧範囲を設定する

ナレッジは、ナレッジベース単位の Can read（読める条件）と Cannot read（読めない条件）、記事単位の Can read／Cannot read で絞ります。

1. 目的と実施の契機

人事内部の運用メモや評価制度の手引きを、対象の組織だけに読ませるときに実施します。対象は kb_knowledge_base、kb_knowledge、kb_uc_can_read_mtom、要件は 要件(2)（限定情報の非表示） です。実行はポータル担当、閲覧範囲の承認は第5巻の運用ルール(2)（限定情報の非表示）、評価順は第4巻の設計(2)（限定情報の非表示）を参照します（番号のみ）。

2. 前提条件・必要なロール・承認

開発手順(5)（組織ごとの User Criteria）の条件、ナレッジベースを管理できる権限（公式ドキュメントでは knowledge_manager、knowledge_admin、admin）。記事単位の条件は knowledge_manager／knowledge_admin のロールが対象です。

3. 事前確認

• ナレッジベースを新規に作ると、Can read に標準の User Criteria「Any User」が自動で入る。検証で作った2つのナレッジベースの両方に入っていた。人事ナレッジは、この条件を外してから人事部を入れる

• システムプロパティ glide.knowman.apply_article_read_criteria の検証環境の値は false だった。値が異なる環境では、同じ結果を前提にせず、記事単位の条件の効き方を先に確かめる

• 公式のプロパティ説明では、glide.knowman.block_access_with_no_user_criteria が true のとき、Can read と Can contribute のどちらも未設定のナレッジベースは読めない（検証環境の値は true）。この挙動は実機で確かめていない

• 記事単位の Can read／Cannot read の欄は、検証環境の記事フォームには出ていなかった。検証では、値を管理者のスクリプトで設定した。画面で設定する場合は、公式ドキュメントのとおりフォームに欄を追加する。この画面操作は検証していない

4. 手順（操作｜期待結果・分岐）

1. Knowledge > Administration > Knowledge Bases で、ナレッジベース「記事検証 人事ナレッジ」「記事検証 全社ナレッジ」を作る。期待結果：保存され、それぞれの Can read に Any User が1件入る

2. 人事ナレッジの Can read で Any User を外し、「記事検証: 人事部」を加える。全社ナレッジは Any User のままにする。期待結果：Can Read のタブが(1)のまま、中身が人事部に替わる

3. 各ナレッジベースに記事を作って公開する。検証では、全社ナレッジに「評価制度の手引き」と「全社共通FAQ」の2件、人事ナレッジに「人事内部の運用メモ」を作った。検証の記事は、作成後に状態を管理者のスクリプトで published にした。画面で行う場合は、ナレッジベースの公開ワークフロー（Knowledge - Instant Publish）を通す

4. 評価制度の手引きに、記事単位の Can read として「記事検証: 管理職」、Cannot read として「記事検証: 外部委託」を設定する。期待結果：管理職グループのメンバーだけが読め、管理職グループにも入っている外部委託のユーザーは読めない

5. 確認用ユーザー6名で、Employee Center の記事URL（/esc?id=kb_article&sysparm_article=<記事番号>）と、Table API の結果を確かめる。期待結果：確認図（開発手順(6)：カタログの閲覧範囲）の「読めた記事」の列のとおり

①のタブに接続件数が出ます。②のリンクは、利用者を指定して、そのナレッジベースを読める理由を診断する機能です。今回の検証では実行していません。

対象外のユーザーが記事のURLを開くと、①のメッセージが出ます。

結果は次のとおりです。

• 人事ナレッジの記事を読めたのは、人事部の2名（本社所属・他拠点）。大阪拠点、管理職、外部委託、一般従業員は①のメッセージ

• 全社ナレッジの全社共通FAQは、6名全員が読めた

• 評価制度の手引きを読めたのは、管理職のユーザーだけ。管理職グループに入っている外部委託のユーザーは、Cannot read が優先されて読めなかった

• Table API（/api/now/table/kb_knowledge）で返った記事も、画面と同じ組み合わせだった

• 標準のポータル /sp の記事表示（/sp?id=kb_article_view）は、検証で作った記事だけが全員に「insufficient privileges」と表示された。管理者の画面でも同じで、既存の標準記事は開けた。原因は特定していないため、この環境では /esc と /kb_view.do で確かめた。/sp で公開する環境では、許可した利用者が /sp の記事表示で本文を読めることを完了条件にする。管理者を含む全員が拒否される場合は、公開完了とせず切り分けへ回す

5. 結果確認と証跡

ユーザーごとの表示と、ナレッジベースの Can read の一覧を残します。検証環境で設定・確認・解除を実行済みです。Cannot read が Can read に優先する点は、評価制度の手引きの結果で確かめました。ナレッジベース単位の Cannot read は、今回は設定していません。

6. 異常時の中止条件と連絡先

対象外にも読めるときは、まずナレッジベースの Can read に Any User が残っていないかを見ます。次にユーザーのロールの有無を確かめ、開発手順(8)（ページのロール設定）へ進んでください。読めるはずの人が読めないときは、条件の Active とグループのメンバー登録が見直し先です。

7. 切り戻しと後片付け

• Can read を元の構成に戻す（検証の前の状態は、ナレッジベースを作った直後の Any User 1件だった）

• 検証用の記事、カテゴリ、ナレッジベースを削除する。検証では、削除後の件数が事前と一致することを確かめた

• 検証では、所有者に管理者を指定してナレッジベースを作ったところ、管理者にロール3件（knowledge_manager など）が付与された。発生条件は確かめていない。付与の一覧から確認して削除した

開発手順(8) ポータルのページへロールで閲覧範囲を設定する

ポータルのページには、Roles 欄にロール名を入れて絞ります。ロールを持たない人には、ページが存在しないときと同じ「Not Found」が表示されます。

1. 目的と実施の契機

管理職だけが使うページを、対象外に開かせないときに実施します。対象は sp_page の Roles と Public、要件は 要件(2)（限定情報の非表示） です。実行はポータル担当、ロールの付与基準は第5巻の運用ルール(2)（限定情報の非表示）、ページの権限方針は第4巻の設計(2)（限定情報の非表示）を参照します（番号のみ）。

2. 前提条件・必要なロール・承認

対象のページ、対象にするロール、ロールを付与するユーザー。ロールの付与は第5巻の承認を受けた依頼に限ります。

3. 事前確認

• ページとウィジェットの配置には、ロール名で絞る欄がある。公式ドキュメントでは、ページ向けの User Criteria を使うために、プラグイン「Service Portal User Criteria Support」の有効化が要る。検証環境ではこのプラグインが有効化されておらず、ページのフォームに User Criteria の欄もなかった

• ロールの付与で、ナレッジの見え方が変わることがある。この環境では、管理職のユーザーに自作のロールを1つ付けただけで、Can read を人事部に絞った人事ナレッジの記事まで読めた。理由と、他のロールや他の環境で起きるかは確かめていない。ロールの付与前後で、ナレッジの見え方に想定外の変化がないかを確かめる

• ページの Public は、ログインしていない人への公開にかかわる欄で、今回の検証ではオフのまま確かめた。閲覧範囲を絞るページはオフにし、オンにしたときの挙動は確かめていない

4. 手順（操作｜期待結果・分岐）

1. ロール（検証では kiji_kensho_manager）を作り、管理職のユーザーに付与する。期待結果：ユーザーのロールが1件になる

2. ページ（検証では kiji_kensho_view_mgr）の Roles にそのロールを指定し、Public と Draft をオフにして保存する

3. 管理職のユーザーでページを開く。期待結果：ページの内容が表示される

4. ロールを持たないユーザーでページを開く。期待結果：「Not Found」の表示になる

5. ロール付与後の管理職のユーザーで、ナレッジの見え方を確かめる。期待結果：承認した閲覧範囲と同じ。人事ナレッジのように、承認外の記事が読めたときは正常終了とせず、ロールの付与を外して手順3から確かめ直す。検証では、この差を記録したうえで付与を外して戻した

①の Roles に入れたロールを持つ利用者だけが、ページを開けます。②の Public はオフです。

ロール付与後は、②の Actions メニューが出ました。同じユーザーで、ロール付与の前後を比べた結果は次のとおりです。

表の内容を文字でも書き出します。

• 管理職ページ：ロール付与前は開けない。付与後は開ける

• 人事ナレッジの記事：付与前は読めない。付与後は読めた

• 評価制度の手引き：付与前も付与後も読めた

• 開けた申請：付与前も付与後も3件で、変化はなかった

5. 結果確認と証跡

ページのフォーム、ロール付与の前後の表示、ナレッジの見え方の差を残します。検証環境で実行済みです。ロール付与後にナレッジの見え方が変わった理由は、公式ドキュメントでは確かめていません。この環境で観測した事実として扱います。

6. 異常時の中止条件と連絡先

ロールを付けていない人に開けるときは、Public がオンになっていないか、Roles の綴りが対象のロールと一致しているかを見直します。ロールを付けた後にナレッジが広く見えるときは、後続の作業を止めて付与を外し、ロールの付与範囲を第5巻の承認者へ戻します。

7. 切り戻しと後片付け

• ロールの付与を削除し、ページの配置、行、コンテナ、ページ、ロールの順に削除する

• ロールの付与を戻したあと、管理職のユーザーでナレッジの見え方が元に戻ることを確かめる（検証では、ロール付与を削除した状態で全員の確認を実行済み）

• 検証では、削除後の件数が事前と一致することを確かめた

開発手順(9) ACL で項目単位の最終線を確認し、必要なら追加する

User Criteria は、この環境では商品とナレッジの表示と Table API に効きました。ただし公式ドキュメントは、テーブル経由のアクセスに商品の User Criteria が及ぶとは書いていません。この手順は、既存の ACL が API にも効いていることの確認と、項目 ACL の追加を扱います。追加する ACL の例は、人事部に meta の読み取りを許可する変更です。閲覧を絞る変更ではないため、対象範囲を承認してから作成します。

1. 目的と実施の契機

画面で隠すだけでなく、API 経由でも読ませない範囲を決めるときに実施します。対象は sys_security_acl（sc_cat_item の read）、要件は 要件(2)（限定情報の非表示） です。実行はポータル担当、ACL の変更承認は第5巻の運用ルール(2)（限定情報の非表示）、権限設計は第4巻の設計(2)（限定情報の非表示）を参照します（番号のみ）。

2. 前提条件・必要なロール・承認

ACL の作成には、security_admin ロールの昇格が要るのが一般的です。検証では admin で、Scripts - Background から ACL を作成できました。自社では、昇格と承認の手順を先に確かめます。

3. 事前確認

• sc_cat_item の read ACL を一覧で確かめ、既存の ACL がどの条件で商品を判定しているかを見る。検証環境では、商品の read ACL のスクリプトが GlideappCatalogItem.get(...).canView() を呼んでいた。User Criteria の判定が、この呼び出しで Table API にも反映される

• 追加する ACL は、検証用の商品に限定していない。sc_cat_item.meta を持つ全商品が対象になり、人事部に読み取りが許可される。影響範囲を判断できない場合は、作成しない

• 同じ項目に既存の項目 ACL がなければ、新しい項目 ACL が、テーブル全体の項目 ACL（sc_cat_item.*）に代わって判定する。検証環境には sc_cat_item.meta の個別の ACL がなく、標準の状態では、人事部のユーザーを含め全員が API で meta の値を読めなかった

• 対象外のレコードに answer = true を返すと、元は閉じていた項目を全員に開く。最初に作った ACL（対象の商品だけを人事部に絞り、他の商品は true を返す）では、一般従業員にも他の商品の meta が読めてしまった。その ACL は書き換えた

4. 手順（操作｜期待結果・分岐）

1. 開発手順(6)（カタログの閲覧範囲）の設定後に、対象外のユーザーで /api/now/table/sc_cat_item?sysparm_query=nameSTARTSWITH記事検証 を開く。期待結果：対象外の商品が返らない（検証では、一般従業員に返ったのは設定なし申請と全社共通の2件）

2. 設定前の項目の読み取りを記録する。期待結果：meta は人事部のユーザーにも返らない

3. sc_cat_item.meta の read ACL を作る。Type を record、Operation を read、Advanced をオンにし、次のスクリプトを入れる

var HR = '<人事部の department の sys_id>';
answer = gs.getUser().getRecord().getValue('department') == HR;

1. 人事部のユーザーと、それ以外のユーザーで、同じ API を呼ぶ。期待結果：人事部のユーザーには meta が返り、それ以外のユーザーには meta の項目が返らない

2. 解除する場合は、ACL を削除する。期待結果：meta は全員に返らない状態へ戻る

結果は次のとおりです。

• 人事部・本社所属のユーザー：4件の商品で meta の項目が返った

• 管理職、一般従業員：meta の項目が返らなかった

• ACL を無効にすると、人事部のユーザーを含めて、meta は全員に返らない状態へ戻った

5. 結果確認と証跡

ACL のフォームと、ユーザーごとの API 結果を残します。検証環境で作成・確認・無効化・削除を実行済みです。商品そのものの絞り込みは、既存の ACL と User Criteria に任せ、この手順では項目だけを追加しました。ページの sp_page は、一般従業員の API では0件が返りました。

6. 異常時の中止条件と連絡先

対象外のユーザーに値が返るときは、すぐに ACL を無効にして開発手順(14)（表示不具合の切り分け）へ進みます。許可する条件の書き方が分からないときは作成せず、第5巻の承認者へ戻します。

7. 切り戻しと後片付け

• ACL を無効にした状態で、API の結果が設定前と同じ（meta が全員に返らない）であることを確かめ、そのあと削除した

• 検証で meta に入れたテスト用の値は、商品の削除と一緒に消えた

ここまでが無料で読める範囲です。共通事項と、構築・閲覧範囲の手順（開発手順(1)〜(9)）を、1回通して実行できる形でまとめています。自社の依頼票と画面で1回通して、型が合うかを試してください。

有料エリアの内容

この先は、定常の手順と障害時の手順、作業記録の書式、付録です。約1.6万字です。開発手順(10)（部品の差し替えと公開停止）は検証環境で操作結果を確かめ、開発手順(14)（表示不具合の切り分け）は2つの症状を作って切り分けと復旧まで実行しました。開発手順(11)（アップグレード後の確認）は画面の確認、開発手順(12)（作業記録と引継ぎ）と(13)は記入や確認の手順です。

• 定常：開発手順(10)（部品の差し替え・公開停止）、開発手順(11)（メジャーアップグレード後の確認）、開発手順(12)（作業記録と引継ぎ）、開発手順(13)（閲覧範囲の棚卸しと異動後の確認）

• 障害時：開発手順(14)（表示不具合の切り分けと復旧）

• 開発手順(12)（作業記録と引継ぎ）の書式（記入例・記入様式（コードブロック）・値の決め方）

• 付録：画面・権限・設定が異なる場合の確認先と、検証で残った後片付けの注意

各手順は、目的と契機・前提・事前確認・手順・結果確認・中止条件・切り戻しの7項目で書いています。

💰 ここから先は有料エリア