· 583 words · 3 min read

8. プレゼンテーションレイヤー#

VLAN自動化は6週間稼働していた。ネットワークチームはそれを誇りにしていた。毎朝、アプリケーションチームから3〜4件の新しいサービスリクエストが届き、ネットワークチームの誰もキーボードに触れることなくオーケストレーターが処理した。デプロイメントは機能した。スイッチは設定された。ネットワークは健全だった。

エスカレーションは木曜日に届いた。アプリケーションチームのリードが、ポータルで「提出済み」と表示されているのにVLANリクエストが3〜5営業日かかる理由を尋ねていた。ネットワークチームはキューを確認した: 保留中のリクエストはゼロで、すべてのデプロイメントは成功していた。自動化は受信から20分以内にすべてのリクエストを処理していた。しかし、ServiceNowチケットはまだ「進行中」と表示されていた。チケットを更新する統合を誰も書いていなかったからだ。

自動化は仕事をしていた。結果が見えなかっただけだ。

1週間後、チームはアプリケーションチームがリクエストを直接提出してステータスを確認できるクイックなセルフサービスポータルをデプロイした。正午までに1時間で47件のVLANリクエストを受け取った。すべて有効だった。すべて正しくフォーマットされていた。問題は、ポータルに認証モデルがなかったことだ。URLを持っている誰からでも提出を受け付けた。すべてのリクエストはプラットフォーム全体の管理者権限を持つ単一のAPIトークン下で実行された。レート制限もなく、承認ゲートもなく、誰が何を提出したかの監査証跡もなかった。

自動化は機能した。アクセスモデルが機能しなかった。

これら2つの失敗はどちらもプレゼンテーションの失敗だ。1つはフィードバックループの欠如で、もう1つはガードレールの欠如だ。本章はそのギャップを埋める。

8.1. 基礎#

8.1.1. コンテキスト#

これまでカバーしてきたすべてのビルディングブロックは内側を向いている: 他のブロックに向けて、またはプラットフォームを構築して運用するエンジニアに向けて。Source of Truth (SoT)は自動化システムのためにネットワークインテントを保持する。ExecutorはデバイスにChangesを適用する。Observabilityは結果を検証する。Orchestratorはそれらすべてを調整する。これらのブロックそれぞれにUIとAPIまたはその両方があり、プラットフォームを構築して運用する人々のために設計されており、それとやり取りする必要があるすべての人のためではない。

Presentation (Layer)レイヤーは外側を向いている。その仕事は、内部を理解する必要がない対象者にプラットフォームをアクセス可能にすることだ: ネットワークサービスをリクエストするアプリケーションチーム、先四半期に何が変わったかを尋ねるセキュリティ監査員、ループに人間なしでインフラをプロビジョニングするCI/CDパイプライン。

第3章では、プレゼンテーションブロックはNAFフレームワークのエッジに位置し、人間と外部システムに向いていた。第6章はオブザーバビリティ可視化とプレゼンテーションの境界を確立した: ネットワークテレメトリの上に直接構築されたダッシュボードは設計の親和性によりオブザーバビリティブロックに属する。それらのダッシュボードを非エンジニアに提供する方法、アクセス制御、またはポータルに埋め込む方法はプレゼンテーションの関心事だ。第7章は非同期ワークフローがステータスエンドポイントと通知フックを必要とすることを確立した。プレゼンテーションレイヤーが両方を提供する。

8.1.2. ゴール#

プレゼンテーションレイヤーは3つのゴールを果たし、それぞれが3つのアーキテクチャ機能に直接対応する。

  1. 一貫したアクセスモデルを持つ安定した認証済みAPIを提供する。 人間であれ機械であれすべてのコンシューマーは、通知なしに変更されないバージョン管理されたアクセス制御されたコントラクトを通じてプラットフォームとやり取りすべきだ。基礎ブロックは置き換え、アップグレード、または再構築できる。コンシューマー向けコントラクトは安定したままでなければならない。認証と認可はこの境界で施行され、ツールごとに重複するのではなく一元化される。

  2. ワークフローに合ったインターフェースを通じてすべてのコンシューマータイプにサービスを提供する。 ネットワークエンジニアとアプリケーションチームのマネージャーは異なるニーズ、異なるレベルの技術的深さ、自動化がどうコミュニケーションするかについての異なる期待を持つ。プレゼンテーションレイヤーは複数のサーフェスを提供する: GUIポータル、Command Line Interface (CLI)、チャットops統合は、すべて同じAPIと同じアクセスモデルによって裏付けられており、アクションを開始した対象者にステータスが表示される。

  3. プラットフォームを外部システムに双方向で接続し、コンシューマーがすでに使っているチャネルを通じて結果を返す。 アプリケーションチームはすでにServiceNowで作業している。CI/CDパイプラインはすでにバージョン管理システムで動作している。プラットフォームは彼らがいる場所で会うべきだ: そのシステムからリクエストを受け取り、ワークフローに新しいツールを必要とせず、同じシステムに結果を返す。

8.1.3. 柱#

3つの柱がこれらのゴールを支える。機能ごとに1つずつだ:

  1. APIレイヤー: 基盤: バージョン管理済み、認証済み、RBAC施行済み、安定したコントラクト。認証とマルチテナントはここで施行され、ツールごとではない。他のすべてのサーフェスはその上に構築される。
  2. クライアントインターフェース: すべてのコンシューマー向けサーフェス（GUIポータル、CLI、モバイル、チャットops）は同じ基礎APIの異なるフォームファクター。
  3. 統合と通知: 外部システム接続（ITSM、CI/CDパイプライン、メッセージングシステム）と送信結果配信（Webhook、コールバック、プッシュ通知）。

8.1.4. スコープ#

プレゼンテーションレイヤーはサーフェスを提供する。生成はしない。

スコープ内:

  • APIレイヤー: すべてのコンシューマーの認証、認可、バージョン管理、レート制限
  • そのAPIの上に構築されたクライアントインターフェース: GUIポータル、CLI、チャットops、モバイルサーフェス
  • 外部統合: ITSMワークフロー、CI/CDパイプラインフック、Webhook配信
  • 送信通知: ステータスコールバック、プッシュアラート、メッセージングチャネルイベント
  • 非エンジニア対象者に提供されるときの運用ダッシュボード（アクセス制御、対象者スコーピング、ポータル埋め込み。基礎メトリクスアーキテクチャは第6章に属する）

スコープ外:

  • データ生成（Observability、第6章）
  • 設定レンダリングとテンプレート処理（SoT、第4章）
  • ワークフロー実行と監査記録生成（Orchestrator、第7章）

ビジネスロジックを蓄積し始めるプレゼンテーションレイヤー（どのワークフローを実行するかを決定する、ネットワークモデルに対して入力を検証する、ワークフロー状態を管理する）は別のものに成長している。これらの責任はオーケストレーターとSoTに属する。ポータルがネットワークポリシーやリトライロジックをエンコードし始めたら、アーキテクチャ上の境界が崩壊し、プラットフォームを独立して進化させることが難しくなる。

8.2. 機能#

3つのゴールと柱は3つのコア機能を通じて実現される。それぞれが1つのゴールと1つの柱に直接対応している:

  1. APIレイヤー: すべてのコンシューマーのコントラクトとアクセスモデル
  2. クライアントインターフェース: そのコントラクトの上に構築されたサーフェス
  3. 統合と通知: 外部システムへの接続と送信配信
graph LR

    subgraph ゴール
        direction TB
        A1[安定した認証済みAPIと一貫したアクセスモデル]
        A2[各コンシューマータイプに適切なサーフェス]
        A3[外部システムとの双方向統合]
    end

    subgraph 柱
        direction TB
        B1[APIレイヤー: バージョン管理済み、認証済み、安定]
        B2[クライアントインターフェース: GUI、CLI、チャットops、モバイル]
        B3[統合と通知: ITSM、CI/CD、Webhook]
    end

    subgraph 機能
        direction TB
        C1[APIレイヤー]
        C2[クライアントインターフェース]
        C3[統合と通知]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

8.2.1. APIレイヤー#

第4章ではSoT自身のAPIを詳しく扱った: 自動化システムがどうインテントデータをクエリするか、消費パターン（REST、GraphQL、Webhook）、ネットワーク設定の読み書きモデル。ここで議論するAPIは目的が異なる: 全体として自動化プラットフォームのコンシューマーへの外向きコントラクトだ。SoT APIが「ネットワークはどうあるべきか？」に答えるのに対し、プレゼンテーションレイヤーのAPIは「自動化プラットフォームは何をしていて、どうやってやり取りするか？」に答える。両方がREST APIかもしれないが、異なるアクセスモデルで異なる対象者にサービスを提供する。

プレゼンテーションレイヤーAPIは基盤だ。すべてのコンシューマーサーフェス（ポータル、CLI、ITSMフォーム、チャットopsボット、AIエージェント）はこのレイヤーの呼び出し元だ。認証、RBAC、バージョン管理、レート制限はここで施行される。うまく設計しなければ、その上のすべてが問題を受け継ぐ。

プレゼンテーションAPIは内部ブロックインターフェースを反映すべきではない。SoTのAPIを直接プロキシする/v1/sot/vlans/エンドポイントや、オーケストレーターのジョブIDをラップする/v1/orchestrator/jobs/エンドポイントを公開することは、コンシューマーを内部実装の詳細に縛り付ける。1つのブロックを別のものに置き換えるとき、それらのIDを保存しているすべてのCI/CDパイプラインを更新しなければならない。プレゼンテーションAPIは代わりにプラットフォームレベルの概念を公開すべきだ: どのオーケストレーターが処理したかにかかわらずサービスリクエストを表す/v1/requests/エンドポイント、各ピースをどのブロックが提供したかを明かさずにSoTとオブザーバビリティから集約されたVLANの現在の状態を返す/v1/services/vlan/エンドポイント。コンシューマーは安定したコントラクトを得て、内部実装はその背後で自由に進化できる。

8.2.1.1. APIが公開するもの#

APIは2つのカテゴリーのエンドポイントを公開する:

  • 読み取りエンドポイント: ワークフローステータスと履歴、監査記録、SoTとオブザーバビリティブロックから集約されたデバイスとサービスの状態。これらはアプリケーションチームがリクエストステータスを確認するために使うクエリで、監査員が変更記録を確認するために使い、監視システムがプラットフォームヘルスを確認するために使う。

  • 書き込みエンドポイント: ワークフローのトリガー、サービスリクエストの提出、保留中のゲートの承認または拒否、実行中のジョブのキャンセル。書き込みエンドポイントにはより強い認可が必要だ。異なる役割が異なる書き込み操作にアクセスできるべきだ: アプリケーションチームメンバーはリクエストを提出できるが任意のワークフローをトリガーできない。ネットワークエンジニアは保留中のゲートを承認できるがワークフロー定義を変更できない。

読み取り/書き込みの区別はコントラクトの安定性も形作る。読み取りエンドポイントは無期限に安定したままでなければならない: 1年間実行しているダッシュボードは上流のスキーマが変わったからといって壊れるべきではない。書き込みエンドポイントは明示的にバージョン管理され、破壊的変更前に廃止予告が必要だ。

8.2.1.2. バージョン管理と安定性#

コンシューマー向けAPIはバージョン管理されなければならない。プレゼンテーションレイヤーAPIはコントラクトで、ブロックの内部は実装だ。オーケストレーター、SoT、またはオブザーバビリティブロックの内部リファクタリングは外部の呼び出し元を壊してはならない。

標準的なアプローチ: URLプレフィックス（/v1/、/v2/）またはAcceptヘッダーでバージョン管理し、定義された廃止ウィンドウの間は以前のバージョンを維持し、変更履歴を通じて破壊的変更を伝える。8ヶ月間/v1/workflows/triggerを呼び出していたCI/CDパイプラインは、月曜日にエンドポイントが警告なしに移動したことを発見すべきではない。

8.2.1.3. 認証と認可#

認証は問う: あなたは誰か？認可は問う: あなたは何をする許可があるか？

多くのチームは認可の前に認証を実装し、「認証済み」と「認可済み」は異なる問題であることを、誰かが持っているべきでなかった有効なトークンで47件のリクエストを提出したときに発見する。

ネットワーク自動化プラットフォームの認証パターン:

  • SSO / LDAP統合: エンタープライズ標準。エンジニアとアプリケーションチームが企業アイデンティティで認証する。管理する個別の認証情報がなく、誰かが退職したときに自動的に失効する。
  • OAuth 2.0 / OIDC: 外部システムとWebポータルユーザー向け。長期的な認証情報ではなく短期的なトークンを生成する。
  • スコープ付きAPIトークン: CI/CDパイプラインと自動化スクリプトによるプログラムアクセス向け。各トークンは定義された有効期限を持つ特定の権限セットにスコープされる。すべてのコンシューマーが使う共有管理者トークンは認証ではない: すべての呼び出し元を同時に壊すことなく取り消せない共有パスワードだ。

RBACを通じた認可。役割はツール機能ではなく運用責任にマッピングすべきだ。ネットワーク自動化の出発点モデル:

  • read-only（読み取り専用）: あらゆるデータを表示できる、アクションはトリガーできない
  • operator（オペレーター）: 事前承認されたワークフローのトリガー、ゲートの承認、サービスリクエストの提出
  • engineer（エンジニア）: フルワークフロー管理、SoT書き込みアクセス、すべての監査記録の表示
  • admin（管理者）: プラットフォーム設定、ユーザー管理、認証情報のローテーション

各役割はその下の役割のすべての権限を継承する。エンジニアはオペレーターができることをすべて行え、さらにSoTへの書き込みとワークフロー管理ができる。

flowchart TD
    RO[読み取り専用]
    OP[オペレーター]
    ENG[エンジニア]
    ADM[管理者]

    RO -->|追加: ワークフロートリガー + ゲート承認| OP
    OP -->|追加: SoT書き込みアクセス + ワークフロー管理| ENG
    ENG -->|追加: プラットフォーム設定 + ユーザー管理| ADM

    style RO fill:#e8f5e9,stroke:#4caf50
    style OP fill:#c8e6c9,stroke:#388e3c
    style ENG fill:#a5d6a7,stroke:#2e7d32
    style ADM fill:#66bb6a,stroke:#1b5e20

RBACはAPI境界で施行される。基礎ブロックはプレゼンテーションレイヤーからの認証済みAPIコールのみを見る。独立してコンシューマーアイデンティティを管理しない。マルチテナントはデータスコーピングを通じて実装される: すべてのクエリは呼び出し元の組織スコープによってフィルタリングされる。Building Bのアプリケーションチームは Building AのリテールチームのリクエストをTT見るべきではない。これは最初から設計されなければならない。フラットなデータモデルへのマルチテナントの後付けは辛い再構築プロジェクトだ。

監査証跡は承認されたリクエストと並んで拒否されたリクエストもキャプチャすべきだ。誰が何をしようとして拒否されたかは、許可されたことと同じくらいコンプライアンスに重要だ。プレゼンテーションレイヤーは第7章のワークフロー監査証跡と並んでこの記録を生成する。第12章ではこのモデルをシークレットローテーション、ポリシーアズコード、コンプライアンス駆動の自動化フローで拡張する。

8.2.1.4. レート制限#

レート制限なしの自動化コンシューマーはオーケストレーターのキューを使い果たす。47件のリクエストのインシデントは悪意ある行為者を必要としなかった: やる気のあるチーム、URL、そしてスロットルなしで十分だった。

API境界でのレート制限: トークンごとの制限（コンシューマーごとの1分あたりのリクエスト数）、バースト制限（同時実行中のリクエスト数）、操作固有の制限（ファームウェアアップグレードワークフローはデバイスごとに一度に1インスタンス以上実行すべきでない）。レート制限レスポンスは、数時間後にタイムアウトとして表面化するサイレントなキュー詰まりではなく、Retry-Afterヘッダーを持つHTTP 429を返すべきだ。

8.2.1.5. REST、GraphQL、MCPインターフェース#

RESTがデフォルトだ。GraphQLよりもバージョン管理、推論、キャッシュがシンプルだ。ネットワーク自動化チームがGraphQLのコンシューマー駆動クエリの柔軟性を必要とすることはほとんどなく、追加の複雑さに対して意味のある運用コストを支払う。例外: プラットフォームが著しく異なるクエリパターンを持つ多数の異なるコンシューマータイプにサービスを提供する場合、GraphQLはオーバーフェッチと複数の専門エンドポイントの必要性を減らせる。正当な選択だが、最初の正しい選択であることはほとんどない。

Model Context Protocol (MCP)インターフェースはプレゼンテーションレイヤーのAIサーフェスだ。人間のオペレーターがCLI経由でプラットフォームにアクセスし、アプリケーションチームがポータル経由でアクセスするのと同様に、Large Language Model (LLM)ベースのエージェントはMCPサーバー経由でアクセスする。エージェントはツール（ワークフローステータスのクエリ、修復のトリガー、監査ログの読み取り）を他のすべての呼び出し元と同じRBACモデルの下で、その推論が必要とするシーケンスで呼び出す。これは第7章（セクション7.2.7）で導入されたエージェンティックオーケストレーションパターンに直接つながる: プレゼンテーションレイヤーのMCPサーバーは、エージェントと各個別ブロック間のハードコードされた統合なしにそれらのパターンをフルプラットフォーム全体で運用可能にするインターフェースだ。

RESTとMCPは誰が相互作用を駆動するかが異なる。REST統合では、コンシューマーはどのエンドポイントをどの順序で呼び出すかを事前に知っている: CI/CDパイプラインはPOST /v1/requests/vlanを呼び出し、次に完了するまでGET /v1/requests/{id}をポーリングする。シーケンスはコードに固定されている。MCPでは、Large Language Model (LLM)ベースのエージェントが各先行コールの結果に基づいて実行時にどのツールをどのシーケンスで呼び出すかを決定する。コンシューマーは事前に決定されたコールグラフを持つパイプラインではなく、次に何をするかを決める前に各結果を読む推論システムだ。MCPサーバーは利用可能なツールとそのスキーマを定義し、エージェントはそれらをどう使うかを決める。これによりMCPは、RESTとして実装した場合はすべての可能なコールシーケンスを開発者が予期する必要があるオープンエンドの運用クエリ（「building-bとコア間の接続の問題を調査する」）に適している。また認可をより繊細にする: 広範なツールアクセスを持つエージェントは、アクセスモデルが明示的に設計していなかった方法で操作を組み合わせられる。RBACモデルはサーバーレベルだけでなくツールレベルで適用されなければならない。

8.2.2. クライアントインターフェース#

クライアントインターフェースはAPIの上に構築されたサーフェスだ。同じ基礎プラットフォームの異なるフォームファクターで、それぞれが異なるコンシューマータイプに適している。どのサーフェスが使われるかにかかわらず、RBACモデルは均一に適用される。

8.2.2.1. GUIとセルフサービスポータル#

Webポータルは非エンジニアの主要インターフェースだ。設計原則はプログレッシブディスクロージャーだ: 基礎の複雑さを公開せずに適切な対象者に適切な量の情報を表示する。

アプリケーションチームは3ステップのビューを見る: 提出済み、進行中、完了。ステータスの詳細はAWXジョブIDではなく「24台のスイッチで事前チェックを実行中」という平易な言語で書かれている。ネットワークエンジニアはデバイスごとの事前チェック結果、承認または拒否アクションを持つ承認ゲート、必要であればフルワークフロートレースを見る。管理者は設定と監査クエリを含むすべてを見る。

読み取りと書き込みインターフェースは異なる設計要件を持つ。読み取り専用ステータスダッシュボードは比較的寛容にできる: プラットフォーム内の任意のエンジニアが自分のリクエストの現在の状態を見られる。書き込みパス（リクエストの提出、ゲートの承認、実行中のジョブのキャンセル）には入力検証、確認ステップ、アクションがコミットされる前に何が起こるかの明確な説明が必要だ。

新しいサービスリクエストフォームの提出ボタンがフォームとワークフロー間に検証レイヤーなしにオーケストレーターAPIを直接呼び出すポータルを構築するチームを見てきた。ユーザーが既存のアロケーションと競合するサブネットを提出すると、エラーはフォーマットされていないオーケストレーターのスタックトレースとして返ってくる。プレゼンテーションレイヤーはリクエストがオーケストレーターに到達する前にSoTモデルに対して入力を検証し、検証が失敗したときに明確でアクション可能なエラーを返すべきだ。

採用リスクはインターフェースで最も高い。技術的に正しいが誰もチームがすでに機能する方法に合わないため使わないポータルは、毎朝誰もが開くツールのシンプルな統合より価値が少ない。ServiceNowで生活しているアプリケーションチームは、別途学んでログインしなければならない新しいポータルよりもServiceNowフォームを通じて一貫してリクエストを提出する。インシデント調整にSlackをすでに使っているエンジニアチームは、追加認証が必要なブラウザリンクよりSlackメッセージを通じて承認ゲートの通知により速く行動する。親しみやすさは採用時の摩擦を減らし、日常使用のエラー率を減らす。新しいサーフェスを構築するかユーザーがすでに知っているツールで会うかの選択がある場合、統合がほとんどの場合正しい最初のステップだ。

8.2.2.2. CLI#

自動化プラットフォームのCLIはデバイスCLIではない。それは第9章の領域だ。これはプラットフォーム自体へのコマンドラインインターフェースだ: エンジニアがブラウザを開かずに自動化をトリガー、検査、管理するために使うツール。

エンジニアがGUIよりも繰り返し作業にシェルスクリプトを好むのと同じ理由でCLIを好む: 合成可能性、速度、スクリプト性。CLIコマンドはエイリアスを付け、他のコマンドにパイプし、デバイスリストでループし、ランブックに組み込み、管理するインフラと一緒にリポジトリにコミットできる。ポータルのクリックはできない。午前2時のインシデント中、5秒で記憶からタイプされたコマンドは、ナビゲートして認証するのに20秒かかるポータルより速い。CI/CDパイプラインでは、CLIはパイプラインの合否条件に直接マッピングする構造化された終了コード（成功は0、失敗は非ゼロ）を解析なしに生成する。エンジニアはまた高リスク操作でCLIツールをより信頼する: パラメーターはシェル履歴に見え、監査可能で、再現可能だ。

ポータルが存在しても、CLIはその存在価値を保つ。午前2時のインシデント中、ブラウザを開いてログインしてワークフローに移動してフォームをクリックして進むのは、単一のコマンドを実行するより遅い。CI/CDパイプラインでは、CLIは生のAPIコールより優れている: 環境変数から認証を処理し、構造化された終了コードを生成し、何かが失敗したときに人間が読めるOutputを提供する。

自動化プラットフォームCLIの設計原則:

  • APIOperationに予測可能にマッピングする一貫した名詞-動詞コマンド構造（workflow run、workflow status、request list）
  • パイプラインスクリプトが結果を解析できるように--jsonフラグでの機械読み取り可能な出力
  • 設定認識: APIエンドポイントとトークンはスクリプトにハードコードされるのではなく設定ファイルまたは環境変数から読み取られる
  • APIに適用されるのと同じRBACがCLIに適用される: オペレーターレベルの権限を持つトークンは、どのサーフェスが使われるかにかかわらず管理者レベルの操作をトリガーできない

8.2.2.3. インスタントメッセージングとモバイル#

Slack、Teams、および同様のプラットフォームはネットワーク自動化において二重の役割を果たす: 通知チャネル（プレゼンテーションレイヤーがイベントをプッシュする）とインタラクションサーフェス（エンジニアがコマンドを送る）の両方だ。この二重の役割を理解することはアーキテクチャに重要だ: アラート通知を受け取る同じワークスペースが承認フローをサポートし、すでにそれらのチャネルを監視しているエンジニアのコンテキスト切り替えを減らすべきだ。

インタラクションサーフェスとして、メッセージングプラットフォームは会話コマンドをAPIコールに変換するボットを通じて機能する。ボットは薄い: メッセージを解析し、送信者のアイデンティティ下でプレゼンテーションレイヤーAPIコールにマッピングし、チャネルのためにレスポンスをフォーマットする。3つのパターンが実際にうまく機能する:

  • 承認フロー: 「承認」と「拒否」ボタンを持つSlackメッセージはネットワークエンジニアがSlackを離れることなく保留中のゲートに行動できるようにする。ボタンのクリックはエンジニアのアイデンティティを持つAPI承認エンドポイントを呼び出し、プラットフォームのSSOとSlackのOAuth統合を通じて解決される。
  • ステータスクエリ: @netbot status app-paymentsはフォーマットされたチャネルメッセージで現在のワークフロー状態を返す。
  • クイックアクション: @netbot compliance-check building-bは軽量な検証ワークフローをトリガーしてインラインで結果を投稿する。

モバイルインターフェースはポータルとCLIが届かない特定の対象者にサービスを提供する: フィールドで物理的に作業するデータセンター技術者。ラックでラインカードを交換している技術者はラップトップを開いていない。手がふさがっていて、姿勢が不便かもしれない。デバイスバーコードをスキャンし、現在の自動化状態（自動化によって管理されており、最後のデプロイメントは14日前、保留中の変更はない）を引き出し、物理的な交換を確認し、適切な修復ワークフローをトリガーできるモバイルアプリは、作業台に戻ることなく物理的な作業を自動化プラットフォームに接続する。RBACモデルが適用される: 技術者のトークンはその役割が許可する操作にスコープされる。インターフェースはフィールド関連のデータにスコープされる: デバイスアイデンティティ、現在の状態、保留中のタスク、シンプルなトリガーアクション。フルプラットフォームビューではない。

同じRBACモデルが適用される。ボットはSSO経由でエンジニアを認証し、そのエンジニアの役割にスコープされたトークンでリクエストを転送する。読み取り専用アクセスを持つエンジニアはポータルを通じてと同様にSlackを通じてもワークフローをトリガーできない。

通知ターゲットとして、メッセージングチャネルはプレゼンテーションレイヤーからイベント駆動の更新を受け取る: デプロイメントの完了、障害アラート、承認ゲートリクエスト、重大なワークフローエラー。通知ルーティングは設定ポリシーであり、ハードコードされたマッピングではない。エンジニアは専用の運用チャネルで障害の詳細を受け取る。アプリケーションチームはITSMチケットを通じて完了ステータスを受け取る。オンコールエンジニアはPagerDuty経由で重大な障害を受け取る。

モバイルインターフェースは同じパターンに従う。制約はアーキテクチャではなく画面スペースとインタラクションモデルだ。エンジニアが電話から保留中のゲートを承認できるモバイル承認インターフェースはポータルと同じAPIを呼び出す。RBACモデルは変わらない。

8.2.2.4. いつ構築するか、いつ埋め込みUIを受け入れるか#

ほとんどすべてのブロックにはすでにUIがある。AWXにはワークフローポータルがある。NautobotにはWebインターフェースがある。GrafanaにはダッシュボードがあるQESTしている。これらの埋め込みUIはプラットフォームを理解するエンジニア対象者には十分だ。専用のプレゼンテーションレイヤーを構築する決定はデフォルトであるべきではない。

実践的な決定シーケンス:

  1. すべてのコンシューマーがすでにブロックUIを使うエンジニアか？埋め込みUIを使う。カスタムポータルを構築するな。
  2. 非エンジニアが自動化をリクエストまたは追跡する必要があるか？ポータルまたはITSM統合のどちらかが必要だ。
  3. すべてのサービスリクエストが管理されているのはITSMか？ITSMをプレゼンテーションレイヤーとして採用するか、主要コンシューマーとして統合するかのどちらかだ。ITSMのワークフローエンジン、承認モデル、通知システムがリクエストパターンに十分であれば、ITSMをプレゼンテーションレイヤーとして直接使う: 自動化APIコールはITSMワークフロー内から発生し、その上の別のレイヤーからではない。より有能なAPIコントラクト、ブロック横断ステータスビュー、またはITSMがクリーンに施行できないRBACが必要な場合、ITSMとブロックの間の薄い専用レイヤーがそれらのプロパティを提供しながら、ITSMはユーザー向けサーフェスとして残る。
  4. 複数のブロックにわたって均一にRBACが必要か？どのクライアントサーフェスをその上に構築するかにかかわらず、中央認証を持つAPIレイヤーが必要だ。
  5. カスタムポータルを長期的に維持することにコミットできるか？不確かなら、ITSM統合から始める。ITSMが必要なアクセスパターンに不十分であることが証明されたときのみポータルを構築する。
  6. コンシューマーがITSMフォームで表現できない詳細を入力または表示する必要があるか？複雑な入力フィールド（YAMLスニペット、トポロジーパラメーター、サブネットアロケーションプレビュー）、SoTモデルに対するインライン検証、またはデバイスごとのドリルダウンを持つリッチなステータスビューは通常、ITSMフォームビルダーがクリーンにサポートする範囲を超える。コンシューマーが定期的にその特異性のレベルを必要とするなら、カスタムポータルはその運用コストを正当化する。

カスタムポータルは、非エンジニアがITSMがクリーンに表現できないアクセスを必要とするとき、またはどの埋め込みUIも提供しない単一のブロック横断ステータスビューが必要なときに構築する価値がある。最も一般的な誤りはニーズが本物であることを検証する前に構築することだ。

8.2.2.5. ドキュメントとレポート#

プレゼンテーションレイヤーの2つの関連する読み取り専用出力が、自動化知識を非同期的に消費する対象者にサービスを提供する: ドキュメントコンシューマー（ネットワークサービスの現在の状態を理解する必要があるチーム）とレポートコンシューマー（定期的なサマリーとコンプライアンス証拠が必要なマネージャーと監査員）。

ドキュメントアズコードパターンがここで適用される: テンプレート言語（Jinja2、Markdown）を使用してライブプラットフォームデータから生成されたドキュメント、自動化コードベースと一緒にバージョン管理され、すべての変更で再生成される。生成されたドキュメントに埋め込まれたMermaidダイアグラムは、手動で維持された図面ではなくSoTからの実際のトポロジーを反映できる。同様に、オブザーバビリティブロックが生のメトリクスに適用する正規化ロジック（第6章でカバー）はここで再利用できる: レポートテンプレートが正規化作業を複製せずに監査員のための表形式サマリーを生成するために同じ正規化された時系列データをクエリする。

  • 自動生成ドキュメントは手動メンテナンスなしにライブプラットフォームデータを読みやすく共有可能なアーティファクトに変換する。デプロイされた各ネットワークサービスに対して、生成されたドキュメントはSoTからのサービス定義、オブザーバビリティからの現在の運用ステータス、オーケストレーター監査証跡からの変更履歴を組み合わせられる。ソースデータは常に最新なため、ドキュメントは自動的に最新の状態を保つ。オーケストレーターのワークフロー定義も別のソースだ: ドキュメントジェネレーターはワークフロー定義から人間が読めるランブックを生成でき、ランブックが説明するものが自動化が実際に行うものと一致することを保証する。

  • レポートはリアルタイムビューではなく定期的なサマリーを必要とする管理とコンプライアンスの対象者にサービスを提供する。週次変更サマリー（何件のワークフローが実行されたか、成功率、平均期間、触れたデバイス）は運用レビューを支える。コンプライアンスエクスポート（特定期間のすべての変更記録、監査提出のために構造化）はオーケストレーターの監査証跡とプレゼンテーションレイヤーの認可ログから組み立てられる。SLAとキャパシティレポート（プロビジョニングまでの時間トレンド、デバイスクラスごとのエラー率、保留中のリクエストのバックログ）はキャパシティ計画とサービス改善の議論を支える。

運用ダッシュボードは設計意図によって両章にまたがる。第6章はデータアーキテクチャをカバーする: 何が収集され、どう正規化され、エンジニア対象者のためのテレメトリの上に直接構築されたダッシュボード。プレゼンテーションレイヤーの関与は同じダッシュボードが非エンジニア対象者に提供されるときに始まる: セルフサービスポータルに埋め込む、アプリケーションチームが自分のサービスのみ見られるようにアクセスをスコープする、またはフィールド使用のためにモバイルフレンドリーなビューを構造化する。基礎メトリクスはオブザーバビリティブロックに残る。アクセスモデルとサーフェスコンテキストはプレゼンテーションの関心事だ。

運用ダッシュボード（第6章）との区別はコンシューマーと時間的なフレーミングだ: ダッシュボードはリアルタイムの決定を行うエンジニアのために現在の状態を示す。ドキュメントとレポートは非エンジニアが非同期的に消費するスナップショットだ。基礎データは同じかもしれない。サーフェスとケイデンスが異なる。

8.2.3. 統合と通知#

プレゼンテーションレイヤーは両方向で外部システムに接続する: 自動化をトリガーするイベントを受け取り、リクエストを開始したシステムに結果を返す。これはコンシューマーのワークフローとプラットフォームのワークフローが収束する場所だ。

APIレイヤーとの区別は方向性と開始だ。APIレイヤーはインバウンドリクエストを処理する: コンシューマーがプラットフォームを呼び出してレスポンスを待つ。統合と通知はプラットフォームが現在のインタラクションを開始しなかったシステムに働きかけることだ: ServiceNowチケットにステータス更新をプッシュする、非同期で待機しているCI/CDパイプラインにWebhookコールバックを配信する、特定のサービスを監視しているSlackチャネルにイベントを投稿する。APIレイヤーはコールに答える。このセクションはイベントを送る。両方が同じ認証モデルとRBAC境界を使う。違いは開始の方向だ。小さなスケールでは、単一のコンポーネントが両方のパターンをクリーンに処理する。より大きなスケールでは、アウトバウンドイベント配信（そのリトライロジック、デッドレターキュー、サブスクリプション管理を持つ）は通常、独自の運用上の関心を持つ別のコンポーネントになる。これがこのモデルが2つを別の機能として分離する理由だ。

8.2.3.1. ITSM統合#

ITSMプラットフォームはネットワーク自動化アーキテクチャで2つの異なるポジションを占め、その区別は設計に重要だ。最初のポジションでは、ITSMプラットフォームがプレゼンテーションレイヤーだ: そのフォームがユーザーインターフェースを定義し、そのワークフローエンジンが承認と通知を処理し、自動化APIはITSMワークフロー内から呼び出される。このモデルでは、ITSMはプレゼンテーションレイヤーの外部ではなく、プレゼンテーションレイヤーそのものなので外部統合はない。2番目のポジションでは、専用のプレゼンテーションレイヤーが存在し、ITSMプラットフォームはそれが同期するコンシューマーの1つだ: リクエストはITSM Webhookを通じて届き、ステータス更新はITSMチケットに流れ戻る。3番目の役割も一般的だ: SoTデータソースとしてのITSM。CMDBが権威あるアセットまたはサービスレコードを持つ場合、SoTはそれをフェデレーションデータソースとしてクエリする可能性がある（第4章でカバー）が、この役割のITSMはユーザー向け自動化インターフェースで役割を果たさない。

このセクションの残りは統合パターン（2番目のポジション）を説明する。ITSM-as-プレゼンテーションレイヤーパターン（最初のポジション）は、ITSMプラットフォームのワークフローエンジン、承認モデル、通知システムがリクエストパターンに十分で、ユーザーとブロックの間に別のレイヤーを導入することを避けたいときの正しい選択だ。

ITSM統合は、コンシューマーが自動化プラットフォームの存在を知る必要がないときに構築するものだ。アプリケーションチームはすでにServiceNowで作業している。最も使いやすいインターフェースは彼らがすでに使っているものだ。

「新しいネットワークサービスリクエスト」のServiceNowフォームは、SoTモデルが必要とするまさにそのフィールドをキャプチャし、APIレイヤーが期待する構造化フォーマットで提出する。フォームがプレゼンテーションレイヤーで、コンシューマーはAPIコールを見ない。提出時に、プレゼンテーションレイヤーはペイロードを検証し、ITSM統合が使うサービスアカウントトークンを認証し、構造化されたリクエストをオーケストレーターに転送する。

リクエストが発火した後、チケットはほぼリアルタイムでワークフロー状態を反映すべきだ: 「SoT検証完了」、次に「事前チェック実行中: 24台のスイッチ」、次に「承認ゲート: エンジニアのサインオフ保留中」、次に「完了: 24/24台のスイッチが設定済み」。この双方向同期はワンショットのWebhookより複雑だ。プレゼンテーションレイヤーがオーケストレーターのステータスイベントをサブスクライブし、永続的なイベントサブスクリプションまたはポーリングリコンサイラーを使ってそれらをチケット更新に変換する必要がある。

多くの組織では、ITSMチケットが変更管理記録だ。プレゼンテーションレイヤーは、権威ある監査証跡がオーケストレーターに存在する場合でも、チケットが変更管理要件を満たすのに十分な情報を含むことを確保しなければならない。2つの記録は異なる対象者にサービスを提供する: ITSMチケットはリクエスターとそのマネージャーにサービスを提供し、オーケストレーター監査記録はネットワークエンジニアとコンプライアンス監査員にサービスを提供する。

ITSM統合には限界がある。定義された状態を持つ構造化されたフォーム駆動のリクエストワークフローに適している。リアルタイム運用クエリ、複雑なワークフロートレース検査、またはエンジニアが素早くイテレーションする必要があるパワーユーザー操作には適していない。ITSMが非エンジニアリクエストの大多数をカバーし、CLIまたはポータルが残りをカバーすることを知ってプラットフォームを設計する。

8.2.3.2. CI/CDパイプライン統合#

ネットワークリソースをプロビジョニングするデプロイメントパイプラインは、定義されたステップでプレゼンテーションレイヤーAPIを呼び出し、構造化された入力を渡し、成功または失敗の結果が返されるまでブロックする。パイプラインはスコープ付きトークンを持つサービスアカウント下で実行される: ネットワークワークフローをトリガーしてそのステータスを読み取るのに十分な権限を持ち、それ以上はない。

これはCLIが自動化コンテキストでその存在価値を示す場所でもある。netauto workflow run vlan-deploy --params params.json --waitを実行するパイプラインステップは、インラインでAPIペイロードを構築する生のHTTPコールより、デバッグしやすく、バージョン管理しやすく、置き換えやすい。CLIの構造化された終了コードはパイプラインステップの合否条件に直接マッピングされる。

8.2.3.3. プッシュ通知とWebhook配信#

ワークフローが完了したり、承認ゲートに達したり、失敗したとき、プレゼンテーションレイヤーは適切なチャネルを通じて適切な対象者に通知する。通知ルーティングはポリシー決定であり、ハードコードされたマッピングではない。エンジニアは専用のSlackチャネルで障害の詳細を受け取る。アプリケーションチームはチケット更新経由で完了ステータスを受け取る。オンコールエンジニアはPagerDuty経由で重大な障害を受け取る。ルーティングルールは設定であり、コードではない。

Webhook配信は着信Webhookの送信側の対となるものだ。ワークフローをトリガーするときにコールバックURLを登録した呼び出し元は、ワークフローが完了したときにHTTP POSTを通じて結果を受け取る。配信保証、失敗時のリトライポリシー、ペイロードスキーマはAPIコントラクトの一部だ。サイレントに失敗するコールバック（リトライなし、ログなし、アラートなし）は、呼び出し元が結果が配信されたと仮定するため、コールバックがまったくないよりも悪い。

8.2.4. ソリューションランドスケープ#

ここにリストされているツールは説明目的の例であり、推薦ではない。チームの能力、既存のツーリング、および運用上の制約に対して評価すること。

プレゼンテーション章はパート2の他のどの章とも異なるソリューションランドスケープとの関係を持つ。プレゼンテーションとしてのみ存在するツールはほとんどない。すべてのブロックにはすでにUIがある。アーキテクチャ上の問いは「どのプレゼンテーションツールを使うべきか？」ではない。それは: 各ブロックの埋め込みUIをいつ受け入れ、いつそれらの上に専用のプレゼンテーションレイヤーを構築するかだ。

2つのモデルが成熟した自動化プラットフォームで共存する。

  • 埋め込みモデル: 各ブロックの組み込みUIを対象者のために使う。エンジニアはワークフロー管理にオーケストレーターポータルを使い、インベントリにSoT WebUIを使い、ネットワークヘルスにオブザーバビリティダッシュボードを使う。これはすべてのコンシューマーがツーリングを理解するエンジニアで、ブロック横断ビューが不要なときに機能する。運用オーバーヘッドは低い: 追加するシステムがない。

  • 専用プレゼンテーションモデル: ブロックの上に統一されたエクスペリエンスを提供するレイヤーを構築または採用する。非エンジニアがアクセスを必要とするとき、単一ビューでブロック横断ステータスが必要なとき、またはRBAC要件が個別ツールの組み込み権限にクリーンにマッピングされないときに必要だ。

アプローチ例使うとき
ブロックごとの埋め込みUIAWXポータル、Nautobot UI、Grafanaエンジニア対象者; ツールごとのRBACが許容可能; ブロック横断ビューが不要
主要インターフェースとしてのITSMServiceNow、Jira Service Managementエンタープライズ組織; 非エンジニアがすでにITSMにいる; フォーム駆動のリクエストフロー
カスタムセルフサービスポータルReact/Vueアプリ、Djangoアプリ非エンジニアがアクセスを必要とする; ブロック横断の統一RBAC; 承認フローのセルフサービス
APIゲートウェイKong、AWS API Gateway、NGINX異なる認証ニーズを持つ複数のコンシューマー; レート制限; バージョン管理の施行
ネットワークネイティブポータルItential、NSO northbound UI組み込みRBACとITSMアダプターを持つネットワーク中心のプラットフォーム
開発者ポータルBackstage統一エントリーポイントを必要とする多くの内部プラットフォームを持つ大規模組織

埋め込みUIの内部を理解することはカスタマイズ決定に重要だ。NetBoxはDjango（Python）上に構築されている。そのWebインターフェースとREST APIはDjangoビューとDjango REST Frameworkエンドポイントだ。Nautobotは同じ系譜を共有する。InfrahubはFastAPIを使う。これらのSoTツールの「プレゼンテーションコンポーネント」は成熟したWebフレームワークだ: プラグイン、カスタムビュー、シリアライザー拡張を通じてカスタマイズ可能。それはその強み（ドキュメント化されており、本番グレード）でもあり制約（主にSoTユースケースのために設計されたフレームワーク内でカスタマイズしており、セルフサービスポータルのユースケースではない）でもある。

上の表のITSM行は外部統合としてのITSMではなく、プレゼンテーションレイヤーとしてのITSMを表す。組織がすべてのサービスリクエストのエントリーポイントとしてServiceNowまたはJira Service Managementを標準化した場合、ITSMがプレゼンテーションレイヤーだ。自動化APIはITSM自身のワークフローの一部としてITSM内部から呼び出されるものだ。ユーザーとITSMの間に別のゲートウェイは座らない。ゲートウェイはITSMと下流ブロックの間に座る。

すべてのアプローチにわたって共通するアーキテクチャ原則の1つ: プレゼンテーションレイヤーは薄くあるべきだ。それはサーフェスであり、システムではない。ビジネスロジックはオーケストレーターとSoTに属する。プレゼンテーションレイヤーは変換し、認証し、ルーティングする。自動化の決定を行い始めた瞬間、境界は崩壊している。

8.3. 実装例#

8.3.1. 2つのサーフェス、3つの対象者、1つのプラットフォーム#

パート2全体を通じてキャンパスネットワークを追跡してきた。app-paymentsのVLANサービスリクエストは第4章でSoTにモデル化され、第5章でExecutorによってデプロイされ、第6章でオブザーバビリティによって検証され、第7章でオーケストレーターによってエンドツーエンドで調整された。まだ対処していないのは、3つの異なる対象者がそのワークフローとどうやり取りするかだ。

このキャンパスでは、プレゼンテーションレイヤーは3つのコンポーネントで構成される。ServiceNowはより広い組織の主要インターフェースだ: アプリケーションチームはServiceNow内で完全にリクエストを提出してステータスを追跡する。ServiceNowは独自のワークフロー自動化の一部としてプレゼンテーションレイヤーのAPIを通じてルーティングする。監査ビューを持つカスタムポータルがエンジニアリングとコンプライアンスの対象者にサービスを提供する: ネットワークエンジニアが事前チェック結果を確認して承認ゲートに行動し、セキュリティ監査員がその読み取り専用監査インターフェースを通じて複合変更記録をクエリする。両方のサーフェスは同じAPIレイヤーを共有しており、プレゼンテーションレイヤー自身の中に位置し、リクエストが基礎ブロックに到達する前に認証、RBAC、バージョン管理を施行する。

3つの対象者

  • アプリケーションチームはServiceNowフォームを通じてリクエストを提出する。サービスがいつ準備できるか、失敗した場合に何が起きたかを知りたい。AWXやNautobotを開く必要があるべきではない。ServiceNowが彼らのプレゼンテーションレイヤーで、プラットフォームAPIは彼らが見ないものだ。

  • ネットワークエンジニアはワークフロー中に承認ゲートの通知を受け取った（第7章、ステップ3）。24台のターゲットスイッチの事前チェック結果を確認し、承認または拒否し、結果を検査できる必要がある。彼らのインターフェースはカスタムポータルだ: ServiceNowフォームより詳細だが、まだ彼らのチームのスコープに限定されている。

  • セキュリティ監査員は3ヶ月後に質問を持って到着する: 誰がこのVLANをリクエストし、誰が承認し、デプロイメントワークフローのどのバージョンが実行され、影響を受けたスイッチの前後の状態は何だったか？彼らのインターフェースはポータルの監査ビューだ: 読み取り専用で、何もトリガーする能力がない。

2つのプレゼンテーションサーフェス

APIレイヤーはプレゼンテーションレイヤー内の共有基盤だ。ServiceNowとカスタムポータルの両方が基礎ブロックに到達する前にすべてのリクエストをAPIレイヤー経由でルーティングする。APIレイヤーは3つのロールベーストークンを施行する: アプリケーションチームのオペレータートークン（自分のリクエストの読み取り、新しいリクエストの提出）、ネットワークエンジニアのエンジニアートークン（スコープ内のすべてのリクエストの読み取り、ゲートの承認または拒否）、監査員の読み取り専用トークン（フルプラットフォームの監査記録のクエリ、書き込みアクセスなし）。どちらのサーフェスもAPIレイヤーをバイパスしない。

flowchart TD
    subgraph コンシューマー
        AT[アプリケーションチーム]
        NE[ネットワークエンジニア]
        SA[セキュリティ監査員]
    end

    subgraph PL[プレゼンテーションレイヤー]
        SN[ServiceNow]
        PORTAL[カスタムポータル]
        API[APIレイヤー: 認証・RBAC・バージョン管理]
    end

    subgraph Blocks[プラットフォームブロック]
        ORC[オーケストレーター]
        SOT[信頼できる情報源]
        OBS[オブザーバビリティ]
    end

    AT --> SN
    NE & SA --> PORTAL
    SN & PORTAL --> API
    API --> ORC & SOT & OBS

    classDef presentation fill:#f0e6ff,stroke:#9b59b6,color:#4a235a
    classDef api fill:#e8e8e8,stroke:#555,color:#111,font-weight:bold
    classDef block fill:#f5f5f5,stroke:#999,color:#333

    class SN,PORTAL presentation
    class API api
    class ORC,SOT,OBS block

ステップ1: アプリケーションチームのサーフェスとしてのServiceNow

アプリケーションチームはServiceNowフォームに記入する: サービス名（app-payments）、サブネットサイズ（/24）、建物（building-b）、リクエストチーム、ビジネス上の正当性。提出時に、ServiceNowは独自のワークフロー自動化の一部としてプラットフォームAPIレイヤーを直接呼び出す。APIレイヤーはSoTデータモデルに対してペイロードを検証し、ServiceNowが使うサービスアカウントトークンを認証し、構造化されたリクエストをオーケストレーターに転送する。

検証が失敗した場合（例えば、リクエストされた建物がSoT内のどのサイトとも一致しない、またはサブネットサイズが既存のアロケーションと競合する）、APIレイヤーはオーケストレーターのワークフローが開始される前に即座に構造化エラーを返す。ServiceNowは明確な失敗理由でチケットを更新する: 「building-cはサイトレジストリに見つかりません」または「サブネット/24はbuilding-bの既存アロケーション10.22.14.0/24と競合します」。アプリケーションチームはチケットで拒否を見て、ネットワークエンジニアを関与させずにリクエストを修正できる。ワークフローが開始されなかったため、部分的なワークフロー状態は作成されず、Sagaロールバックも必要ない。

ワークフローが進行するにつれ、プレゼンテーションレイヤーはオーケストレーターのステータスイベントをサブスクライブし、それらをServiceNowチケット更新に変換する: 「SoT検証完了」、「事前チェック実行中: 24台のスイッチ」、「承認ゲート: エンジニアのサインオフ保留中」、「完了: 24/24台のスイッチが設定済み」。アプリケーションチームはオーケストレーター、SoT、またはAWXが存在することを知らずにチケットが更新されるのを見る。

ステップ2: 承認ゲートのサーフェス

ワークフローが承認ゲートに達すると、オーケストレーターは一時停止してイベントを発行する。プレゼンテーションレイヤーがそれを受け取り、Building Bを担当するネットワークエンジニアを特定し、ゲートレビューページへの直接リンクを含む承認リクエストを彼らのSlackチャネルに送る。レビューページはスイッチごとの事前チェック結果を表示する: どれが通過し、どれが失敗し、どれがスキップされ、なぜかを示す。エンジニアはポータルから承認または拒否する。アクションはログに記録される: 誰が承認したか、どのインターフェースから、いつ、どのトークン下で。

ステップ3: 監査ビュー

3ヶ月後、セキュリティ監査員はプレゼンテーションレイヤーAPIにクエリする: 「VLAN app-payments、Building Bのフル変更記録を見せてほしい」。読み取り専用監査エンドポイントは3つのソースを集約する:

  • オーケストレーターの実行記録（第7章、セクション7.2.4）: どのワークフローバージョンが実行されたか、すべてのステップ入力と出力、Saga補償アクション
  • SoTの変更記録（第4章）: VLAN定義の前後の状態
  • プレゼンテーションレイヤー自身の認可ログ: 誰がリクエストを提出したか、どのトークンを使ったか、誰がゲートをいつ承認したか

レスポンスは監査員が変更管理記録に添付できる構造化ドキュメントだ。3つの基礎ブロックのどれも独立してこの複合記録を生成するように設計されていなかった。プレゼンテーションレイヤーは監査員の読み取り専用トークン下で個別APIからそれを組み立てた。

これが示すもの

第7章からの同じ10ステップのワークフローが、それらの対象者のどれも基礎プラットフォームを理解する必要なく、2つのプレゼンテーションサーフェスを通じて3つの異なる対象者にサービスを提供した。ServiceNowはより広い組織にサービスを提供した: アプリケーションチームはAWX、Nautobot、またはその背後のオーケストレーターを意識せずに毎日使っているツールを通じてリクエストを追跡した。カスタムポータルはエンジニアリングとコンプライアンスの対象者にサービスを提供した: ネットワークエンジニアはチームのリクエストにスコープされたクリーンな承認インターフェースを確認し、監査員は単一の読み取り専用ビューを通じて3つのブロックから組み立てられた複合変更記録をクエリした。両方のサーフェスに同じアクセスモデルを施行する1つのAPIレイヤーがプラットフォームを見えるようにせずにアクセス可能にした。

8.4. サマリー#

Presentation (Layer)レイヤーはパート2の最後のビルディングブロックであり、後付けとして扱われる可能性が最も高いものだ。その下のブロックが実質的な作業を行う: インテントを保持し、変更を適用し、結果を検証し、ワークフローを調整する。プレゼンテーションレイヤーはそれらのどれも生成しない。しかし、それなしには、プラットフォームはそれを構築した人々のみがアクセスでき、他のすべての対象者は人間の仲介者に依存したままだ。

APIレイヤーが基盤だ。API境界で（ツールごとではなく）施行された認証と認可は、アクセス可能な自動化と危険な自動化を区別するものだ。バージョン管理と安定したコントラクトは、プラットフォームをすべての更新で呼び出し元を壊すプロトタイプから区別するものだ。Model Context Protocol (MCP)インターフェースは同じアクセスモデルをLarge Language Model (LLM)ベースのエージェントに拡張し、第7章で導入され第17章でさらに発展するエージェンティックオーケストレーションパターンにプラットフォームを利用可能にする。

クライアントインターフェースは同じ基礎APIの異なるフォームファクターだ。プログレッシブディスクロージャーを持つGUIポータルはプラットフォームを理解せずに自動化をリクエストして追跡する必要がある非エンジニアにサービスを提供する。CLIはスピード、スクリプト性、CI/CD統合を必要とするオペレーターにサービスを提供する。チャットopsとモバイルサーフェスは承認フローとインシデントクエリにサービスを提供する。どのサーフェスを構築するかについての決定は意図的なシーケンスに従うべきだ: エンジニア対象者のために埋め込みブロックUIから始め、非エンジニアが自動化をリクエストする必要があるときにITSMと統合し、ITSMが不十分であることが証明されたときのみカスタムポータルを構築する。

統合と通知は第7章の非同期レスポンスコントラクトが開いたループを閉じる。オーケストレーターがワークフロー結果を生成し、プレゼンテーションレイヤーがそれをアクションをトリガーした対象者に彼らがすでに使っているチャネルを通じて届ける。双方向のITSM同期、Webhookコールバック、プッシュ通知は便利な機能ではない。それらは自動化を依存する人々に見えるようにするものだ。

キャンパスのシナリオはこれを実際に示した: 1つのワークフロー、3つの対象者、2つのプレゼンテーションサーフェス。ServiceNowはより広い組織に自身のプレゼンテーションサーフェスとしてサービスを提供し、プラットフォームAPIを直接呼び出して馴染み深いチケット更新を通じてステータスを表面化した。カスタムポータルはエンジニアリングとコンプライアンスの対象者にサービスを提供した: ネットワークエンジニアはチームのリクエストにスコープされたクリーンな承認インターフェースを確認し、監査員はオーケストレーター、SoT、プレゼンテーションレイヤー自身の認可ログから単一の読み取り専用ビューを通じて組み立てられた複合変更記録をクエリした。同じAPIレイヤーが両方のアクセスモデルを施行した。プラットフォームはもはや見えないものではなくなった。

プレゼンテーションレイヤーが整ったことで、パート2はNAFフレームワークの7つのビルディングブロックすべてをカバーした。次の章は、この自動化のすべてが最終的に作用する1つのブロックに向かう: ネットワーク自体。第9章でカバーされる。

💬 Found something to improve? Send feedback for this chapter