素のZurich PDIは何点か：アセスメント出力を「Word風の報告書」に変えるプロンプト

活用度アセスメントのスクリプトを実行すると、パイプ区切りのテキストが1,013行返ってきます。数字の根拠がすべて詰まった、価値ある出力です。ただ、この状態のまま上司や役員には出せません。読むのに訓練が要るからです。

この記事は2段構えです。前半で、その生出力を A3の設計書のようなWord風レポートに変換するプロンプトを紹介します。後半で、素の Zurich PDI（デモデータ入り）に実際のアセスメントを実行し、そのプロンプトで作った報告書を最後まで見せます。生の出力が経営報告書に変わるまでの一連の流れを、実物で追える構成です。

先に結論の数字を書きます。素の Zurich PDI の活用度は、26モジュール平均で 1.8/5 でした。未導入（Lv0）を除いた導入済み17モジュールの平均では 2.8/5 です。「デモデータが入った状態」がだいたい何点に見えるか。これは実環境を測るときの基準線としてそのまま使えます。あなたの本番環境がこの数字を下回るモジュールがあれば、それはデモデータ以下ということになります。

この記事で分かること

• 生のアセスメント出力を、Word風の報告書に変換するプロンプトの中身

• 素の Zurich PDI の実測スコア（26モジュール分の一覧と根拠）

• 発火したスコアキャップ8件の内訳（CMDB 1%・カタログ死蔵99.5%など）

• 報告書に載せた図表（スコア分布・キャップ一覧・改善バックログ・再測定ワークフロー）

• 生成AIに出力を渡して報告書を作る、実際の手順

生の出力は、そのままでは報告書にならない

アセスメントスクリプトの出力は、1行が11列のパイプ区切りです。先頭の Section 列で行の種類（モジュール総括・問題検出・スコアキャップ・次アクション）が分かる構造になっています。機械で処理するには理想的な形です。

問題は、人が読むときです。1,013行のうち、スコアの結論はモジュール総括の26行、根拠はキャップ8行に集約されますが、その間に800行を超える詳細行が挟まります。慣れれば50行前後に絞って読めますが、初見の人には「文字の壁」にしか見えません。役員会に持ち込めば、数字より先に「これは何を見ればいいのか」と聞かれて終わります。

上がその生出力の冒頭です。1行が11列にきれいに整っているぶん、かえって「どこを見ればいいか」が伝わりません。

そこで、出力を渡すと体裁の整った報告書に変換してくれるプロンプトを用意しました。生成AIに「この出力を、印刷できるWord風の設計書にして」と頼むだけの状態にします。

出力を「Word風レポート」に変えるプロンプト

このプロンプトの狙いは、SIerが客先に出す地味な設計書の体裁を、生成AIに正確に守らせることです。派手なダッシュボード風の見た目ではなく、白背景・黒文字・角丸なし・絵文字なしの、印刷して回覧できる文書を作らせます。

指定している主なルールはこの通りです。

• 体裁：フォントは Noto Sans JP、章タイトル14pt・本文10pt、A3縦で印刷可能。ページは黒枠で囲む

• 図表：表の上に表番号、図の下に図番号を中央寄せで付ける。表には左端に番号列、列見出しは薄い色。ワークフローは必ず入れる

• 配色：黒・グレー・紺・深緑・暗い赤・紫を使い分ける。角丸のオブジェクトと絵文字は禁止

• 文章：非IT担当者や新社会人でも分かる説明を先に置き、その後に技術者向けの詳細を書く。「印刷対応しました」のようなメタ文は書かせない

• 表現：入力フォームやポータル画面をアスキーアートではなく、表やオブジェクトで表現させる

このルール群を守らせると、出力の見た目は普段づかいのビジネス文書に近づきます。プロンプトの全文は、この記事の後半（有料エリア）に載せました。コピーしてそのまま使えます。

出来上がった報告書：表紙と総合スコア

実際にこのプロンプトで作った報告書が、次の表紙です。総合スコア 1.8/5 を最初に大きく置き、対象環境と実施日を記録しています。

表紙で環境と日付を明示するのには理由があります。アセスメントの数字は、後から「どの環境の、いつの話だっけ」となった瞬間に価値を失うからです。ここでは対象インスタンス名を伏せていますが、実運用では環境名と取得日を必ず残します。

スコア分布：Lv0 が最多という健全さ

26モジュールを活用度レベル別に数えた分布が、報告書の図1です。

Lv0（未導入）が9モジュールで最多です。PDI には CSM・SPM・SecOps・IRM などのプラグインが入っていないため、これは正しい判定です。逆に言えば、未導入をちゃんと0点と言い切れることが、この採点の信頼性の土台になります。導入していないものに点が付く道具なら、その道具を疑うべきです。

Lv2 が8モジュールと膨らんでいます。この多くは素点がもっと高いのに、スコアキャップで2点に抑えられたものです。キャップの中身は有料エリアで扱います。

モジュール別スコア一覧

26モジュールの最終スコアと、その根拠の一覧が報告書の表1です。

最高点は Automation の1モジュールだけでした。根拠は、Flow の実行コンテキスト（sys_flow_context）が直近90日で5,843件あったことです。PDI は放置していても、SLA 計算やシステム系の Flow が裏で動き続けています。「定義があるか」ではなく「実行されているか」を見に行くと、こうした実態が拾えます。

意外に見えますが、これは「PDI がよく活用されている」という意味ではありません。システムが自動で回す実行も、業務ユーザーが作った Flow の実行も、同じ1件として数えられるためです。実環境で Lv5 が出たら、誰の Flow が動いているのかを掘り下げるのが次の一手になります。