Ti Navigate

ti-navigate — 画面の場所と開き方を答える

ベータとして先行提供している機能です。 記述が変わることがあります。扱いは ti-core の references/beta-status.md を参照してください。

利用者が「これはどこで見られますか」「どこから入れますか」と聞いたときに、その組織の実際のメニュー構成でクリック経路と直リンクを答えるためのスキル。答える対象は4つ。

画面の場所と、その画面での操作手順は別の問いである [REQUIRED]。 本スキルの TRIGGER には「操作手順を順番に教えて」が入っており、場所を答えたあとそのまま手順まで書いてしまいやすい。場所は組織から引ける（それが本スキル）。手順は組織から引けない（ナレッジにある）。 引かずに書けば、コードや画面定義から組み立てた手順になる。

画面の導線は同梱しない。 メニュー構成・レポートの置き場・タブの並びは組織ごとに違い、静的に持てば必ず実物とずれる。本スキルは導線そのものを持たず、組織から実行時に引いて組み立てる手順だけを持つ。

前提

• 標準（ホステッド）Salesforce MCPが接続済みであること
• 利用組織にPSA（必要に応じてIMA）パッケージが導入済みであること

REST APIの版は組織に問い合わせて決める [REQUIRED]。 本文中の v{最新} は、GET /services/data/ が返す一覧の最後の要素の version に置き換える（実測では v67.0 が末尾だった）。記憶にある版番号を書かない。 組織の版より新しい番号を当てると応答せず、古い番号を当てると新しい項目が返らない。

手順1〜3・5と、レポート・関連リストの章は、通常のオブジェクト参照とUI APIだけで足りる。 業務の権限しか持たない利用者の接続でも動く。しかも取れる内容がその利用者に見える範囲へ自動的に絞られるので、見えない画面を案内せずに済む。

手順4（業務メニューのタイル構成）だけが設定情報の参照（Tooling API）を要する。 ここは業務利用者の権限では引けない（下記）。引けなくても手順1〜3・5で答えは成立するので、タイル構成は「あれば道順が丁寧になる」追加情報として扱う。

設定情報の参照権限は、業務利用者には既定で付いていない

PSAが配る権限セット215本のうち、「設定・定義を参照する」と「アプリケーションのカスタマイズ」を付けるものは1本も無い（実測）。手順4は次のどちらかでしか動かない。

• 管理者権限を持つ接続で引く（社内のサポート・導入支援がAIに答えさせる形）
• 顧客の管理者が、AIの使う接続へ設定情報の参照を許可する

この許可を安易に勧めない。 「設定・定義を参照する」は設定画面を開けるようにする権限で、組織の構成が広く見えるようになる。タイル構成が引けないことによる不利益（道順の説明が1段浅くなるだけ）と釣り合わないなら、許可を取らずに手順1〜3・5で答える。

製品の操作手順に触れるとき [REQUIRED]

本スキルの守備範囲は「その画面はどこにあるか・どう開くか」までで、「その画面で何をどの順に押すか・この機能はできるか・この挙動は仕様か」は入っていない。 次のどれかに手をかけた瞬間に、ti-core references/knowledge-lookup.md を読み、その作法でナレッジを引く。問いがそちらへ移った（場所は済み、次は使い方・可否・仕様）なら ti-howto へ渡す。

1. 可否・手順・理由を書こうとした瞬間 — 「どうやりますか」「できますか」「なぜこうなりますか」に答える文。回答だけでなく、利用者へ出す選択肢・作業計画・教育資料・デモ台本の前提に仕様を置こうとしたときを含む。
2. 製品そのものを読もうとした瞬間 — Apex クラス・フロー・トリガ・項目ヘルプ・パッケージのメタデータを開こうとした。手順1〜5・レポート・関連リストで引く定義（AppDefinition／AppTabMember／TabDefinition／FlexiPage／analytics/reports/{id}/describe／related-list-info）は含まない——これは本スキルの正規の経路である。含むのは、そこで取れたものを材料にして、ナレッジへ当たらないまま手順・可否・理由の文を書こうとしたときである。
3. 実測した値が期待と違い、「不具合」「障害」「バグ」と書こうとした瞬間 — 画面が無い・タブが無い・並んでいないことを欠陥と呼ぶ前に、仕様を確かめる。
4. 作業の対象範囲を自分で数え上げようとした瞬間 — 「その機能の画面はこれで全部か」を、引けたタブの一覧だけから数えない。

画面の場所を答えたあと、そのまま操作手順まで書くのがいちばん起きやすい [REQUIRED]。 場所は組織から引いた事実だが、手順は引いていない。**同じ回答の中で、根拠のある部分と無い部分が混ざる。**読み手にはその境目が見えない。

出力規律（最上位原則）

• 利用者に見せる説明文は業務言語だけで書く。内部の識別子・問い合わせ文は出さない。これらは経路の組み立てとリンク生成にのみ使う
• 画面はその組織での呼び名で呼ぶ（組織が表示名を変えていれば変えた後の名前で呼ぶ）。同梱の知識や記憶にある名前で呼ばない
• クリック経路は利用者がたどる順に書く。1手ずつ、飛ばさずに書く
• 直リンクは経路と併記する。経路だけだと初見の利用者が迷い、リンクだけだと次回から自力でたどれない

導線を組み立てる手順

必ずこの順で進める。各段の結果が次の段の入力になる。

1. どのアプリの話かを決める

SELECT DurableId, DeveloperName, NamespacePrefix, Label, NavType, UiType FROM AppDefinition

ツバイソPSAは用途別に複数のアプリを持ち、アプリによってナビゲーションバーの並びも業務メニューのタイルも変わる。利用者がどのアプリを使っているか分からないときは、決め打ちせずに尋ねる。

同じ表示名のアプリが同居する。 製品のアプリと、それを複製したテンプレート・組織の自作アプリが同じラベルを持つことがある。利用者はラベルでしか言えないので、NamespacePrefix が入っているほう（パッケージが配ったアプリ）を既定で採り、判断がつかなければどちらかを尋ねる。ラベルだけで1件に決めない。

名前空間は独立した項目で、開発者名の頭には付かない（開発者名は tb_PSA_Standard のような形で、接頭辞は付いていない）。開発者名の見た目で判定しない。

2. ナビゲーションバーの並びを引く

SELECT TabDefinitionId, SortOrder FROM AppTabMember WHERE AppDefinitionId = '{手順1のDurableId}' ORDER BY SortOrder

アプリの指定は必須（条件なしでは実行できない）。返るのは並び順とタブの識別子だけなので、名前は手順3で解決する。

TabDefinitionId にはID形式でない値が混ざる。捨てない [REQUIRED]。 標準タブは home・MobileHome・Account・ProcessInstanceWorkitem のような短い文字列で返る（実測。ツバイソPSAの13件のうち4件がこれだった）。これらはそのままタブの DurableId なので、ID形式の値と一緒に手順3の条件へ入れればすべて解決できる（実測で13件中13件が解決）。ID形式かどうかで選り分けると、ホーム・取引先・承認申請といった実際にバーに並んでいる項目が案内から抜け落ちる。

これは既定の並びであって、利用者の画面に今出ている並びとは限らない [REQUIRED]。 利用者はナビゲーションバーを自分で編集でき、開いた画面が一時的なタブとして増えることもある。実機では定義に無い項目が並んでいた。したがって**「左から◯番目」と言い切らず、「バーの中の『発注』」のように名前で指す**。

3. タブの正体・表示名・リンク元を解決する

SELECT DurableId, Name, Label, Url FROM TabDefinition WHERE DurableId IN ('{手順2の識別子}', …)

1回で3つ取れる。

• Label … 業務言語の表示名（発注・案件・業務メニュー 等）。そのまま利用者に見せてよい
• Name … リンクの組み立てに使うタブのAPI名。標準タブでは standard-home・standard-report のような接頭辞付きの値になる（実測）。この形の値は /lightning/n/ には使えないので、標準タブのリンクは §リンクの書式 の該当行から選ぶ
• Url … タブの種類の判別に使う。値が …FlexiPage… のような画面定義の名前ならLightningページのタブ、https://{instance}/{3文字}/o の形ならオブジェクトのタブ。このURLをそのまま利用者に渡さない（旧UI形式）

業務メニューのタブの Url が、いま実際に開かれる画面定義の名前になっている。手順4はこれを使う。設定情報を引かなくても、生きている版がここで分かる。版番号は組織のパッケージ版で変わるので、覚えずに毎回ここから取る。

業務語が複数の画面に当たるときは、決め打ちせずに尋ねる [REQUIRED]。 利用者の言葉（「支払」）が、支払・支払予定・支払かがみ・支払明細 のように複数の表示名に当たることがある。いちばんそれらしい1つを主に据えて経路を示し、他の候補も名前で挙げて、どれかを聞く。 黙って1つに決めると、利用者は違う画面を開いて「無い」と思う。

TabDefinition は実行している利用者に見えるタブだけを返す。 案内する相手が本人ならこれは望ましい（見えない画面を案内せずに済む）。一方、管理者や第三者が「うちの組織にその画面はあるか」を聞いているときは、これを根拠に「無い」と答えない。

アプリ全体でなく「その利用者が開けるものの一覧」が欲しいときは、条件なしで TabDefinition を引く。 手順4が引けない場合の主たる代替がこれで、グループ分けは失われるが、開ける画面とリンクは全部答えられる。

4. 業務メニューのタイル構成を引く（設定情報の参照が要る・任意）

SELECT Id, DeveloperName, MasterLabel, Metadata FROM FlexiPage WHERE DeveloperName = '{手順3で得た画面定義の名前（名前空間を除いた部分）}' AND NamespacePrefix = '{手順3で落とした名前空間}'

Tooling APIで実行する。手順3の Url から名前空間の部分（◯◯__）を落とした残りを DeveloperName に渡す。

名前空間の条件も一緒に付ける [REQUIRED]。 名前空間を落とした名前は、組織が自分で作ったページの名前と同じになりうる。2件以上返るとどれが業務メニューの定義か決められないので、落とした名前空間をそのまま条件へ戻して1件に絞る。

絞り込みが要る理由は曖昧さの回避だけではない。Tooling API は Metadata 列を含むクエリでは1件しか返せないため、2件以上に当たる条件ではそもそも結果が取れない。名前空間の条件は、答えを一意にするためとクエリが成立するための両方に効いている（レビューでの確認による。実機での再現は未実施）。

Metadata.flexiPageRegions[].itemInstances[].componentInstance が上から順に並び、タイル一覧のコンポーネントでは componentInstanceProperties のうち title がグループの見出し、tabs の valueList がそのグループに並ぶタイルの順序。

利用者に見せるときは、この見出しと並び順をそのまま使う。並び替えたり、まとめ直したりしない（画面と一致しなくなる）。tabs の値の表示名は手順3と同じ引き方で解決する（TabDefinition を Name で引く）。

同じタイルが複数のグループに出ることがある（支払・仕入経費など）。画面がそうなっているので、まとめない。利用者の用事にいちばん近いグループを主の経路として示し、「別のグループにも同じものがあります」と1行添える。どちらを押しても同じ画面に着くことも書く（利用者が迷わないように）。

権限が無くて引けても引けなくても、手順を止めない。 引けなければ §引けないときの答え方 へ進む。

5. 経路とリンクを組み立てて返す

道順は2通りあるので、短いほうを先に、確実なほうを後に書く。

• 上のバーに出ている場合: 「アプリ → ナビゲーションバーの{タブ名}」
• 業務メニュー経由（手順4が引けたときだけ）: 「アプリ → 業務メニュー → {グループの見出し} → {タイル名}」

どちらも「アプリを開く」から始める。 画面の操作に慣れていない利用者にとって、そこが最初の一手で、いちばん迷うところ。ただし位置の言い切りは避ける（手順2の [REQUIRED]）。

「どこから入れますか」（登録したい）と聞かれたら、経路をタブで終わらせない。 タブに着いた先で新規作成のボタンを押すところまでが答え。一覧を開く経路の末尾に1手足し、直リンクは新規作成の形（下表）を先に出す。「どこで見られますか」（参照したい）なら一覧のままでよい。

末尾に直リンクを付ける。

リンクの書式

本スキルは単独で発火する。ホスト名とレコードのリンクを他スキルへ丸投げしない [REQUIRED]。 画面の場所だけを聞かれた場面では ti-reference は読み込まれないので、そこへ委ねると肝心のリンクが埋まらないまま返すことになる。最低限の解決手順は下記のとおり本スキルに置く。 書式の網羅・出力の細かい規約は ti-core references/output-discipline.md が正本で、両方を使う場面ではそちらに合わせる（この正本は ti-core にあるため、どのスキルからも同じチェックポイントで到達できる）。

ホスト名は接続先から取る。 接続が返す https://{myDomain}.my.salesforce.com の .my.salesforce.com を .lightning.force.com に置き換えたものが、画面のホスト名（実測）。接続先のものをそのまま使い、記憶にあるホスト名を書かない。 解決した https://{myDomain}.lightning.force.com に、下表のパスを付ける。

上表は実機で開いて確認済み。裏付けは pageReference Types（Aura） と 新URL形式のFAQ。

同じ形式を、Salesforceのナビゲーションバー自身が使っている。 実機のバーの各項目のリンク先を読むと、画面ページのタブは /lightning/n/{タブのAPI名}、オブジェクトのタブは /lightning/o/{オブジェクトのAPI名}/home になっていた。標準オブジェクトのタブもカスタムオブジェクトと同じ形で、特別扱いが要るのはホームだけ。迷ったらバーのリンク先を1つ読めば確かめられる。

アプリのリンクは、そのアプリを使えない利用者には黙って既定のアプリへ流れる（エラーも警告も出ない・実機で確認）。「このリンクで◯◯アプリが開きます」と断定しない。アプリを切り替える案内は、リンクに頼らず操作（画面左上のアプリケーションランチャーから選ぶ）でも書いておく。

レポート・ダッシュボードの置き場

SELECT Id, Name, DeveloperName, FolderName, OwnerId, Format, Description FROM Report WHERE Name LIKE '%{業務語}%'

OwnerId が置かれているフォルダーのId。フォルダー名まで含めて答える（同名・類似名のレポートが別フォルダーに複数あるため、名前だけでは特定できない）。

名前で当たらなければ説明文でも引く。 本スキルは説明文を一次情報として読む設計なので（§説明文を読まずにレポートの開き方を答えない）、業務語が名前になく説明文にだけ入っていることがある。

SELECT Id, Name, DeveloperName, FolderName, OwnerId, Format, Description FROM Report WHERE Description LIKE '%{業務語}%'

名前での検索を先に、説明文での検索を後に置く。 説明文は本文が長いぶん関係の薄いレポートまで拾いやすい。

組織が自分で作ったレポートも同じ経路で引ける。ここが本スキルの効きどころで、ヘルプ記事は組織の自作レポートを知らない。

レポートはナビゲーションバーに無い。手順4に依存させない [REQUIRED]

ツバイソPSAのアプリのナビゲーションバーにレポートのタブは並んでいない（実測。ツバイソPSAで13項目・シンプルで18項目のいずれにも不在）。手順2〜3だけでは経路が出ないので、業務メニューのタイル（手順4）が引けないと答えられない、という状態にしない。

設定情報を引かずに着ける経路が2つある。どちらも権限を要しない。

• 画面左上のアプリケーションランチャーから「レポート」を選ぶ（どのアプリを使っていても同じ）
• 直リンク /lightning/o/Report/home を渡す

手順4が引けたときは、業務メニューの「分析」グループ経由の道順も併記してよい。ただしそれは追加であって、答えの土台にしない。

フォルダーは入れ子になっている。親から順に案内する [REQUIRED]

Report.FolderName が返すのは末端のフォルダー名で、その名前はフォルダー一覧のトップには出てこない。トップに並ぶのは親フォルダー（ツバイソPSA／ツバイソPSA（デプロイ版）／ツバイソIMA 等）で、末端はその中にある。「『管理会計2』のフォルダーを開いてください」とだけ言うと、利用者は一覧にその名前を見つけられない。

親は次で解決する。

SELECT Id, Name, DeveloperName, NamespacePrefix, ParentId FROM Folder WHERE Type = 'Report'

Report.OwnerId に一致する行の ParentId をたどり、親 → 子の順に並べて案内する。

固定の道順はこれ。

1. 画面左上のアプリケーションランチャー → レポート（または直リンク /lightning/o/Report/home）
2. 左の一覧の すべてのフォルダー
3. {親フォルダー名}（例: ツバイソPSA（デプロイ版））
4. {末端フォルダー名}（例: 管理会計2）
5. {レポート名}

フォルダーへの直リンクは §リンクの書式 の該当行。親をたどれなかったときは、フォルダーの道順を書かずにレポートの直リンクだけを渡す。 見つからない道順を書くほうが害が大きい。

同名フォルダーの選び方は、アプリとは逆向き [REQUIRED]

同じ末端フォルダー名が2組ある（実測。ツバイソPSA 配下＝名前空間 tb_PSA 付きと、ツバイソPSA（デプロイ版） 配下＝名前空間なしに、管理会計・管理会計2・経理・営業管理・商品・サービス分析 等が同名で並ぶ）。Report.FolderName は両方とも同じ文字列を返すので、名前だけでは1件に決まらない。

本体は名前空間が付いていないほう（デプロイ版側）。手順1のアプリの規律（名前空間が付いているほうを採る）をここへ持ち込まない。 向きが逆で、取り違えると利用者が開けないフォルダーへ案内することになる。判別は Folder.NamespacePrefix が空かどうかで行い、FolderName の見た目で決めない。

同名・類似名のレポートを黙って1つに決めない [REQUIRED]

手順3のタブと同じ規律をレポートにも当てる。業務語で引いて複数件返ったら、いちばんそれらしい1本を主に据えて経路を示し、他の候補もフォルダー名付きで挙げて、どれかを聞く。 黙って1本に決めると、利用者は違うレポートを開いて数字が合わないと言う。名前が同じで中身が違う組み合わせが実際に同居している。

説明文を読まずにレポートの開き方を答えない [REQUIRED]

一部のレポートは、フォルダーから開くと結果が出ない。 レコードのIDを渡して表示する作りになっていて、正しい経路はレコード側のタブのリンクから。そしてその事実は説明文に書かれている。

各案件・受注レコードの管理会計タブのリンクからID指定をして表示するレポートのため、
レポートのフォルダから直接表示するとデータが表示されない場合があります。

これは1本の例外ではなく複数のレポートに同じ書き方で入っている（実測）。説明文を読まずに「フォルダーから開いてください」と答えると、間違った経路を自信を持って案内することになる。 説明文に開き方の記述があれば、それを最優先する。

説明文には前提の絞り込みが書かれていることもある（「売上を除いて原価だけにしている（実行画面で解除可）」等）。開いたあとに何が見えるかが変わるので、経路と一緒に伝える。

説明文の不備に気づいたら直しを提案する

定義に特定レコード固定の絞り込みがあるのに説明文に開き方が書かれていない、マトリックス形式で積み上げ集計がオフなのに前提が書かれていない、説明文が空——このどれかに当てはまるレポートを見つけたら、案内を終えたあとに1行で伝える。放っておくと、次に同じ問いが来たときも同じだけ危うい。

説明文の型と直し方は skills/ti-metadata/references/report-description.md。本スキルでは型を定義しない（読む側と書く側で二重に持たない）。

開いたあとの表示設定まで答える

開けても読めないことがある。 管理会計のレポート群は積み上げ集計で見る前提で作られていて、オフのままだと横に長く伸びて目的の数字まで大きく横スクロールが要る。オンにすると1画面に収まる。

表示設定は実行画面のトグルだが、既定値はレポート定義から引ける。

GET /services/data/v{最新}/analytics/reports/{レポートId}/describe

既定値は reportMetadata の下にあるが、同じ階層に並んでいない（実測）。

presentationOptions に入っているのは積み上げ集計だけだった。まとめて presentationOptions の下を探すと、小計・総計・詳細行が見つからず「設定が無い」と誤読する。

既定がオフで、オンにしないと読めない設計のレポートでは、経路と一緒に「開いたら積み上げ集計をオンにしてください」まで言う。 読めない状態に案内して終わるのは、案内していないのと同じ。

レコードから次のレコードへの導線（関連リスト）

「案件を開いたあと、そこから発注へどう行くか」を答える。デモ・教育でいちばん使うのはここ。

GET /services/data/v{最新}/ui-api/related-list-info/{オブジェクトのAPI名}

返る relatedLists が、そのレコードの画面に実際に出ている関連リスト。relatedListId がリンクに使う名前、label が業務言語の表示名（調達依頼・見積依頼・発注・検収・仕入経費・支払・経費精算 等）。通常の権限で引け、その利用者に見える範囲に絞られる。

リンクの書式:

/lightning/r/{オブジェクトのAPI名}/{レコードId}/related/{relatedListId}/view

構造から引いた子リレーションの一覧を、そのまま案内に使わない [REQUIRED]。 オブジェクトの構造（describe）には画面に出ていない子リレーションも大量に含まれ（実測で56件、うち業務のものが25件、画面に出ているのは27件で一致しない）、画面に出ていないものを案内すると「表示しようとしている関連リストはレイアウトにありません」というエラー画面に着く（実測）。案内してよいのは上記のUI APIが返したものだけ。

画面を見ないで答える

本スキルは画面を一切開かずに、組織の定義だけで導線を組み立てる。これは意図的な設計で、画面の描画状態に左右されないため。

AIがブラウザで画面を操作して確かめようとする場面では、そのタブが前面にあることを先に確かめる（document.hidden が true なら背面）。バックグラウンドのタブではSalesforceの遅延読み込みが走らず、中身が空のまま描画されない。これを「画面に出ていない」と読むと、実際には出ているものを「無い」と報告する（実測で再現）。自分の観測環境の状態を、仕様の断定に使わない。

引けないときの答え方

設定情報が引けない（手順4が動かない）場合、それは組織の異常ではなく権限の問題。手順1〜3・5だけで答える。

• 目的の画面がナビゲーションバーにあれば、そこまでの道順とリンクで完結する
• バーに無ければ、TabDefinition（条件なし）でその利用者が開ける画面を探し、リンクを渡す
• 「業務メニューのどのグループにあるか」は答えられないので、答えられないことを言い、代わりにリンクを渡す。分かったふりで見出しを推測しない

経路そのものが応答しない場合は、記憶や一般論で画面の場所を答えない。 誤った導線は、正しい答えが無いことより高くつく。利用者は画面の前でその手順をたどり、たどれずに問い合わせを起こす。

組織の作り替えに追随する

組織は業務メニューを差し替えられる（独自の画面を作ってタブに割り当てる・タイルを足す）し、アプリを自作してナビゲーションバーを組み替えられる。手順1〜3で組織から引いていれば、差し替えられた後の実物がそのまま取れる。同梱の知識と食い違ったら、組織から引いたほうが正しい。

ti-referenceとの境界

両方を聞かれる場面は多い（「工事の原価はどこで見られますか。ついでに今月の合計も」）。その場合は本スキルで場所を答えてから ti-reference で数字を出す。逆順にすると、利用者は数字だけ受け取って自分では二度とたどり着けない。

未確認

• 手順4を通すのに要る権限がどちらかは未実証。候補は「設定・定義を参照する」と「アプリケーションのカスタマイズ」で、確かめるには片方だけを持つ利用者で試す必要がある（確認に使えた接続はどちらも持つ管理者だった）。後者は設定の変更まで開く重い権限なので、依頼するなら前者だけ

変更履歴

• v0.5.0: 提供の段階をベータとして明示し、description と本文冒頭にバナーを置いた（README の一覧・description・本文バナーの3層を揃える規定に従う）。あわせて手順4の名前空間条件の根拠を1つ足した——Metadata 列を含む Tooling API のクエリは1件しか返せないため、条件は曖昧さの回避だけでなくクエリの成立そのものに効いている。
• v0.4.0: 画面の場所と操作手順の境界を引き、製品知識の引き当て（knowledge-lookup）の発火点を追加。 本スキルの TRIGGER には「操作手順を順番に教えて」が入っているのに、手順の出どころを持っていなかった。場所は組織から引ける（それが本スキル）が、手順は組織から引けない（ナレッジにある）。境界を明示しないと、場所を答えたあとそのまま手順まで書き、同じ回答の中で根拠のある部分と無い部分が混ざる（読み手にはその境目が見えない）。冒頭の対象表・§ti-referenceとの境界 に手順の行を足し、§製品の操作手順に触れるとき を新設した。手順1〜5・レポート・関連リストで引く定義は発火点から除外（本スキルの正規の経路であり、除外しないと毎回発火する）。
• v0.3.3: v0.3.2のレビューで残った指摘を反映。(1) 手順4のクエリに名前空間の条件を足した——名前空間を落とした名前は組織の自作ページと同じになりうるため、落とした分をそのまま条件へ戻して1件に絞る。(2) レポートを説明文でも引く二次検索を追加。説明文を一次情報として読む設計なので、業務語が名前に無く説明文にだけ入っていることがある（名前での検索を先、説明文での検索を後に置く）。(3) ti-metadata の reference への参照を、スラッシュの欠けた疑似パスから実パスへ直した。
• v0.3.2: v0.3.0の追従検証で出た欠陥8点を、すべて実機で確かめ直してから修正。(1) 表示設定の在処が誤っていた——presentationOptions に入るのは積み上げ集計だけで、小計・総計・詳細行は reportMetadata の直下、isRunPageEditable は絞り込みごと。(2) ホスト名とレコードのリンクを ti-reference へ丸投げしていたため、本スキルが単独で発火する場面（＝いちばん多い場面）でリンクが埋まらなかった。最低限の解決手順を本スキルに置いた。(3) AppTabMember.TabDefinitionId はID形式でない値も返す（home・Account 等。実測13件中4件）。そのままタブの識別子なので捨てない。 (4) 同名フォルダーの選び方はアプリとは逆向きで、名前空間が付いていないほう（デプロイ版側）が本体。(5) レポートのフォルダーは入れ子で、Report.FolderName の名前は一覧のトップに出てこない。親からたどる固定の道順とフォルダーの直リンクを追加。(6) レポートのタブはPSAのアプリのナビゲーションバーに無いため、経路の答えが手順4（設定情報が要る）に依存していた。アプリケーションランチャーと直リンクで着ける経路を土台に据えた。(7) REST APIの版を GET /services/data/ の末尾から取る手順を明記。(8) レポートの曖昧性解決を [REQUIRED] へ。
• v0.3.1: レポートの説明文に不備があったら直しを提案する節を追加（型そのものは ti-metadata references/report-description.md に置き、読む側と書く側で二重に持たない）。
• v0.3.0: スコープを3つ広げた（2026-08-25印具さん決定）。(1) レポートの説明文を必ず読む — フォルダーから開くと結果が出ないレポートがあり、その事実は説明文に書かれている。読まずに答えると間違った経路を自信を持って案内する。複数のレポートに同じ書き方で入っていることを実測で確認。(2) 開いたあとの表示設定まで答える — 積み上げ集計の既定値・効いている絞り込みはレポート定義から引ける（analytics/reports/{id}/describe の presentationOptions ほか）。開けても読めない状態に案内して終わらない。(3) レコード間の関連リスト導線を追加 — UI APIの related-list-info が、画面に出ている関連リストだけを業務言語のラベル付きで返す。構造から引いた子リレーションの一覧は使わない（画面に出ていないものを案内すると「レイアウトにありません」のエラー画面に着くことを実測）。あわせて、本スキルが画面を見ずに答える設計であることと、画面を操作して確かめる場面での前面確認（document.hidden）を明記した。(1)〜(3) はいずれも通常の権限で引けるため、権限の前提は増えていない。
• v0.2.1: v0.2.0の追従検証（PSA7037で「経費精算はどこから入れますか・支払の一覧はどこですか」に答えさせる）で出た欠陥を修正。(1) アプリ特定のクエリが NamespacePrefix を取っておらず、同名アプリの選び分けの基準が実際には機能しなかった（名前空間は独立した項目で、開発者名の頭には付かない）。(2) 画面定義の名前を TabDefinition.Url から取るとき、名前空間を落とす一手を明記。(3) 同じタイルが複数グループに出るときの案内、(4) 業務語が複数の画面に当たるときの曖昧性解決を [REQUIRED] で追加。(5) 「どこから入れますか」の経路をタブで終わらせない一手を追加。
• v0.2.0: Tooling APIへの依存を、業務メニューのタイル構成の1箇所だけに縮めた。 アプリ・ナビゲーションバーの並び・タブの表示名は通常のオブジェクト参照（AppDefinition／AppTabMember／TabDefinition）で引けることを実測で確認し、手順を組み替えた。とくに TabDefinition.Url がLightningページのタブについて「いま実際に開かれる画面定義の名前」を返すため、設定情報を引かずに生きている版が分かる。これにより業務の権限しか持たない利用者の接続でも大部分が動き、取れる範囲がその利用者に見えるものへ自動的に絞られる。タイル構成が引けないときの縮退（開けるタブの一覧とリンクで答える）を §引けないときの答え方 に明記した。
• v0.1.4: 設定情報の参照権限が業務利用者には既定で付いていないことを実測で確定（PSAが配る権限セット215本のいずれも付与しない）。
• v0.1.3: リンクの書式を実機で開いて確認。ホームだけ形が違うこと、標準オブジェクトのタブも同じ形であること、アプリのリンクはIdで引くこと、使えないアプリのリンクは黙って既定のアプリへ流れることを追記。アプリ定義の並びは利用者の画面の並びと一致しないため位置を言い切らない規律を追加。
• v0.1.2: 追従検証で出た穴を塞いだ（アプリを開くリンクの書式・同名アプリの同居・IsAccessible の読み方・表示名を解決できなかったタブを落とさない）。
• v0.1.1: リンクの書式を公式ドキュメント出典で確定。
• v0.1.0: 初版。