uipath-ixp

UiPath IXP ドキュメント抽出アシスタント

UiPath IXP（Intelligent eXtraction Platform）プロジェクトを扱うためのスキルです。プロジェクトの作成、ドキュメントのアップロード、予測結果のレビュー、抽出品質の向上を行います。

このスキルを使用する場合

• IXP プロジェクトの作成、ドキュメントのアップロード、またはドキュメント抽出モデルのトレーニングを依頼された場合
• ドキュメントの予測結果へのラベル付け、レビュー、または確認を依頼された場合
• 抽出スコア、プロンプト、またはフィールドの指示の改善を依頼された場合
• IXP モデルのバージョンの公開または管理を依頼された場合
• トレーニング済みモデルのバージョンを Orchestrator フォルダーにデプロイすること、デプロイを別のバージョンに移行すること、またはプロジェクトのデプロイ先を一覧表示することを依頼された場合（deployments create / upgrade / list）
• プロジェクトにインポートするタクソノミーファイルが提供された場合
• 特定のトレーニング済みモデルのバージョンにおけるプロジェクトのタクソノミー、つまりバージョン N の公開時点でのスキーマについて尋ねられた場合（deployments get-taxonomy <project-name> --version <N> を使用）

このスキルを使用しない場合 — uipath-maestro-flow に引き継ぐ

このスキルの対象は、スタンドアロンの IXP プロジェクトでの作業です。次のいずれかに当てはまる場合は、作業を中止し、代わりに uipath-maestro-flow スキルを呼び出してください。

• ユーザーが .flow または Maestro フローで使用できる IxP／ドキュメント抽出モデル、エクストラクター、またはノードについて尋ねている場合（レジストリの一覧に関する質問であり、IXP プロジェクトの管理ではありません）。
• フロー内で IxP ノードを追加、接続、または参照することについての依頼である場合。
• 作業コンテキストがスタンドアロンの IXP プロジェクトではなく、.flow ファイルまたは Maestro フローである場合。

このスキルからこれらの質問に回答しないでください。uipath-maestro-flow を再度有効にし、そこで説明されているコマンドに従ってください。この指示は重要なルール 1 に優先します。

例外 — uipath-maestro-flow からの引き継ぎの場合： ユーザーがドキュメントを提供し、それらを対象とする公開済みエクストラクターがないために同スキルから引き継がれた場合、周囲のコンテキストがフローの構築であっても、IXP の作業はこのスキルの対象です。引き継ぎには対象の Orchestrator フォルダーが指定されています。これは呼び出し元との取り決めであり、再確認する必要はありません。ドキュメントからプロジェクトを作成し、トレーニング済みバージョンをそのフォルダーにデプロイし（Deployment Guide — フォルダーの指定がない場合の終了処理も含みます）、デプロイについて報告したら、制御を呼び出し元に戻してください。このスキルからフローを接続したり、編集したりしないでください。

重要なルール

1. コマンドを実行する前に uip ixp の構文を確認してください — CLI Reference で目的に合わせた検索を行い、サブコマンドとオプションを正確にコピーしてください。推測はしないでください。依頼内容が記載されていない場合は、即興で対応するのではなく、このスキルには文書化された CLI の手順がないことを報告してください。curl の使用、REST API の直接呼び出し、ソースコードの調査はしないでください。（例外：フロー／Maestro レジストリに関する質問は uipath-maestro-flow に引き継いでください — 上記の このスキルを使用しない場合 を参照。）
2. ワークフローは最初から最後まで自動的に実行してください — 個々の手順をユーザーに実行するよう求めないでください。
3. CLI の出力をプログラムで解析するときは、必ず --output json を使用してください。
4. 作業ディレクトリには /tmp/ixp/<project-name>/ を使用し、次の構成にしてください：

   /tmp/ixp/<project-name>/
   ├── docs/         # Document files (<document-id>.pdf, .png, …) — downloaded once, reused across sessions
   ├── taxonomies/   # Taxonomy snapshots (v1.json, v2.json, …) — new version after each update-prompts
   └── payloads/     # One-shot JSON request files (Rule 5) — never reused
   

   ワークフローの開始時には、必ず mkdir -p /tmp/ixp/<project-name>/{docs,taxonomies,payloads} を実行してください。以前のセッションでディレクトリがすでに存在する場合は、docs/ と taxonomies/ 内のファイルを再利用してください — すでにあるドキュメントを再ダウンロードしないでください。payloads/ 内のファイルは再利用しないでください（ルール 5）。/tmp/ixp/ のパスには Write ツールを使用しないでください — Windows では bash と異なる場所に解決されます。
5. JSON オプションはファイルで渡してください — JSON をインラインで記述したり、"$(cat ...)" を使ったりしないでください。Windows の cmd／PowerShell は引用符を取り除くためです。JSON をファイルに書き込み、同じコマンド内で --updates-file <path>、--fields-file <path>、または --choices-file <path> を指定してください。Bash：cat > /tmp/ixp/<project-name>/payloads/field_updates.json << 'EOF' ... EOF の後に uip ixp fields update-prompts <project-name> --updates-file /tmp/ixp/<project-name>/payloads/field_updates.json を実行します。PowerShell：Set-Content -Encoding utf8 -Path <file> -Value @' … '@ の後、同じ uip 呼び出しでそのファイルを指定してください。-Encoding utf8 を付けないと、Windows PowerShell は ANSI で書き込み、非 ASCII 文字が気付かないうちに破損します。そのコマンド内で作成していないファイルは渡さないでください。このセッションまたは以前のセッションで作成されたファイルには、古い名前や出現インデックスが残っています。
6. 変数名に UID を使用しないでください — 読み取り専用のシェル変数です。DOC_ID、DOCUMENT_ID などを使用してください。
7. 必ずプロジェクトの Title ではなく Name を使用してください — project list の出力には Name（例：my_invoices-f1afa9ef-ixp）と Title（例：My_Invoices）の両方があります。すべての CLI コマンドで必要なのは Name（UUID と -ixp のサフィックスを含む小文字のスラッグ）であり、Title ではありません。
8. ドキュメント単位ではなく、フィールド単位でレビューしてください — 予測された各フィールドを個別に確認してください。正しいフィールドだけを labellings confirm --fields で確認します。予測の判定にはページ上の文字列そのものではなく、タクソノミーのデータ型を基準にしてください — Date は YYYY-MM-DDTHH:MM:SSZ として読み戻されます。日付のみのページ値は T00:00:00Z になります（ページの 21-JUN-22 → 2022-06-21T00:00:00Z）。Monetary Quantity は <amount> <ISO-4217 code> になります（ページの 114.91 → 114.91 AUD）。正規化された形式で同じ値なら確認済みです。形式を変換したり、自分で換算したり、確認用のスクリプトを書いたりしないでください。全形式の対応表：CLI Reference § Normalized output formats。正規化によって変わるのは値の表記方法だけであり、意味ではありません（区切り文字、末尾のゼロ、通貨コードと記号、日付形式、世紀の補完など）。数値については、大きさが保たれていることを意味します — 上記の正規化形式は同じ金額です。一方、ページの £7,300.00 が £730.00 と予測された場合は大きさが変わっているため、正規化ではなく誤った値です。予測値がドキュメントと一致しないフィールドは未注釈のままにしてください —「修正」してはいけません。これには誤答、ページ上の誤った情報源、文字化け（MSI0601020 に対する MSIÓÓÓ601020/）、数字や小数点の読み違い、反転すべきブール値（false→true）、誤って推測／計算された数値が含まれます。--group を指定しない場合、--fields は指定した各フィールドのドキュメント内のすべての出現箇所に適用されます — 出現箇所ごとの指定についてはルール 12 を参照してください。
9. 値を手動で抽出しないでください — すべてのラベリングは、IXP の予測を使って labellings confirm から行います。confirm は IXP 自身の予測を記録します。ユーザー自身が、プロンプトが、またはヒントが正しい値やその書き込みコマンドを示していても、自分で導き出した値を代わりに渡してはいけません — どのような形であれ、それは手動抽出です。
10. あなたの役割はレビュー担当者であり、抽出担当者ではありません — IXP が予測を生成し、あなたがそれを検証します。各ドキュメントについて、予測されたフィールド値をドキュメントファイルと照合してください。pages パラメーターを指定せずに、単一の全体 Read で表示してください — デジタル文書とスキャン文書のどちらでも、テキストと画像がネイティブに返されます。PDF ツールのインストールは不要です。正しいフィールドは確認し（labellings confirm --fields）、誤ったフィールドはスキップしてください。値を手動で抽出しないでください。フィールドの F1 が低い場合は、IXP がより適切な値を予測するようにプロンプトを改善してください。
11. フィールドが欠落していると記録できるのは、IXP が値を予測しておらず、かつそのフィールドがドキュメントに実際に存在しない場合だけです。 最初に get-predictions を確認してください — 誤った予測値を上書きするためにフィールドを欠落扱いにしてはいけません。そのフィールドは未注釈のままにしてください（自分で「欠落」を選ぶことは、ルール 10 で禁止されている抽出担当者の判断です）。実際に欠落しているフィールドを記録するには、labellings mark-missing --fields <ids> を使用します。予測に空の値として含まれているフィールドは、confirm --fields でも欠落マーカーが記録されます（明示的に指定することで、空の状態が意図的であると確認したことになります）。mark-missing は、現在の get-predictions の出力から完全に消えているフィールド（モデル／タクソノミーの変更後に古い注釈が残っている場合など）にも適用されます。この場合、confirm は何も行いません。ドキュメントのレビューでは、空のフィールドも confirm --fields のバッチに含め、同じ呼び出しで欠落として記録してください。mark-missing は単独で記録する場合、または予測に存在しないフィールドの場合にのみ使用してください。
12. 繰り返し可能なフィールドグループでは、抽出結果ごとに検証が異なる場合、出現箇所単位で確認してください — 繰り返し可能なグループ（例：Line Items）は、物理的な行／セクションごとに 1 つの抽出結果を生成します。通常の confirm --fields <id> は、すべての出現箇所で <id> を確認するため、一部の行だけが正しい場合、誤った行も確認してしまいます。get-predictions の各ラベルには、明示的な 0 始まりの Occurrence が含まれます — これはその読み取り内のインデックスであり、固定の行 ID ではありません（ルール 17）。すべての出現箇所が正しい場合は通常の形式を使い、それ以外の場合は --group で対象を指定してください。--group <name> --occurrence <N> は出現箇所を1 つ確認します。--group <name> --updates-file <path> は 1 回のアトミックな呼び出しで複数の出現箇所を確認します（N 回のラウンドトリップを回避できます）。--occurrence <N> は、1 件だけの --updates-file と同等で、出現箇所単位で同じように処理されます。--group には、get-predictions からそのままコピーしたグループの Name（例："Line Items"）を指定してください — 自分で組み立てた名前は使わないでください。--fields を指定しない場合は、その出現箇所の予測フィールドがすべて確認されます。指定した場合は、それらのフィールドだけが確認されます。選択されていない出現箇所の既存の注釈はそのまま維持されます。フラグの詳細：CLI Reference。
13. confirm は追加処理であり、確認を取り消すことはありません。 confirm／mark-missing は既存の注釈をすべて維持したうえで、新しいものを追加します。すでにラベル付けされたテーブルに対する --occurrence 0 は、「行 0 を確認し、以前に確認した内容もすべて維持する」という意味であり、「行 0 だけを確認する」という意味ではありません。確認を取り消すには unconfirm を使用してください（タスクナビゲーションの表を参照）。
14. F1 が示すのは確認済みラベルとの一致であり、ドキュメントの真実ではありません — むやみに確認しないでください。 F1／ProjectScore は予測と確認済みラベルの一致度を測るため、誤った値を確認すると、それが「正解」として扱われ、スコアは 1.00 になります。完璧なスコアは、値が正しいことの証拠ではありません。確認する前に、各値がドキュメントと合っているかを必ず確認してください。1 つのドキュメントに対してフィールドを指定せずに確認し、予測されたフィールドをすべて対象にする方法は、すべてレビュー済みであれば問題ありません。ユーザーが、指定したドキュメント内の予測フィールドはすべてレビュー済みで正しいと明示した場合は、そのレビューを受け入れ、フィールドごとの再レビューを行わずにそれらのドキュメントを確認してください（ただし、バージョンは固定してください — ルール 18）。ドキュメント ID を指定せずに confirm を実行してはいけません — すべてのドキュメントを一度に確認することになり、レビューを迂回します。Label Documents Guide §2d を参照してください。
15. エンティティの参照先が曖昧な場合は、推測せずに質問してください。 プロジェクト（タイトル）、フィールドグループ、フィールド、データ型は、ユーザーの発言では同じ名前空間を共有しています（「subscriptions の名前を変更して」など）。変更操作（update-title、rename、delete、change-type）の前に、ユーザーがどの種類のエンティティを指しているかを特定してください。名前が複数の種類に一致する場合 — ユーザーの文脈内、または projects list／タクソノミーの出力内 — は、停止して、一致する候補とそれぞれの種類をすべて明示し、どれを指しているか質問してください。1 つを選んだり、「念のため」複数の候補を変更したりしてはいけません。ユーザーに対話形式で質問できない場合は、タスクで提供されている手段を通じて質問を提示し、そこで停止してください。
16. 新しいものを追加する前に、組み込みのデータ型を再利用してください。 すべての IXP プロジェクトには、デフォルトのデータ型（Exact Text、Inferred Text、Number、Date、Monetary Quantity、Boolean）が付属しています。正確なリストは、プロジェクトの projects get-taxonomy に含まれる entity_defs が正です。data-types add の実行やフィールドの --type の選択前に、一致するデフォルトの型を再利用してください。たとえば、通貨額には Monetary Quantity を使用し、手作りの類似型（Currency Amount）は使わないでください。新しい型を追加するのは、デフォルトの型では対応できない場合に限ります。たとえば、プロジェクト固有の Choice や、独自の抽出指示が必要な概念です。形式を変換する目的だけで型を追加してはいけません — 事前トレーニング済みのデフォルト型は、指示にかかわらず固定の出力形式を維持します。対応表：CLI Reference § Default data types。
17. Occurrence は、それを生成した読み取りの範囲内でのみ有効です — 出現箇所単位の書き込みを行うたびに、予測を再読み込みしてください。 get-predictions は、注釈済みの出現箇所を先に、その後に未注釈の出現箇所を一覧表示します。そのため、繰り返し可能なグループの行を 1 つ確認すると、次回の読み込みではその行が Occurrence 0 に移動し、残りの番号も振り直されます（IXP の UI でも同様に先頭に表示されます）。データは失われません — その行は値とページ上の位置を保持します — しかし、書き込み前に読み取ったインデックスは、同じ行を指さなくなります。したがって、確認／確認解除の対象はすべて 1 回の --updates-file 呼び出しで処理してください（すべてのインデックスが同じ読み取りに基づいて解決されます）。出現箇所単位の呼び出しを順次行う必要がある場合は、その間に get-predictions を再実行し、以前に見たインデックスではなくフィールド値を基準に各行を再特定してください。ドキュメント順で読み戻されるのは、すべて未注釈またはすべて注釈済みのドキュメントだけです。ユーザーにはインデックスではなく、値で行を報告してください（「運賃追加料金の行」など）。
18. レビューしたバージョンに対して確認してください — --model-version を指定してください。 確認すると再トレーニングが行われるため、get-predictions の読み込みから confirm の実行までに予測が変わる可能性があります。読み込み結果の ModelVersion を confirm -m <N> に渡してください。以降に再トレーニングが行われてバージョンが変わっていた場合、確認は拒否されます（PredictionVersionChangedError）。これにより、レビューしていない値が正解データとして登録されるのを防ぎます。このエラーが発生したら、get-predictions を再実行し、再レビューして、新しいバージョンに対して確認してください。ユーザーから提供されたレビューに基づいて確認する場合（ルール 14）も例外ではありません。ユーザーが指定した ModelVersion を固定するか、1 回 get-predictions を実行して取得してください。バージョンだけを取得するための読み込みは、再レビューにはなりません。
19. DeploymentName ≠ DeploymentTitle であり、create は既存のデプロイ先を変更しません。 deployments create --title は自由形式の DeploymentTitle を設定します。ランタイムが解決する名前は DeploymentName で、タイトルをスラッグ化したものにデプロイごとのサフィックスが付きます（invoices → invoices-08963f00-ixp）。この名前は予測できないため、作成時の応答または deployments list から取得し、決して自分で組み立てないでください。create は常に追加のみを行います。既存のデプロイ先を別のバージョンに切り替えるには、DeploymentName を指定する deployments upgrade <project-name> <deployment-name> を使用します。そこにタイトルを渡すと 404 になります。upgrade の前には必ず deployments list を実行してください。アップグレードすると、そのフォルダーと名前を使うすべてのランタイム呼び出し元が取得するモデルバージョンが変わります — 共有フォルダーを変更する前に、意図を確認してください。CLI Reference § Deployments を参照してください。
20. get-metrics のデフォルトは LATEST であり、LIVE ではありません — 報告するバージョンを必ず明記してください。 プロジェクトでは、稼働中のバージョンが固定された後も学習済みバージョンが追加され続けるため、最新バージョンのスコアがデプロイ済みのものより低いことがあります。そのため、単独の get-metrics を実行すると、最新バージョンの数値と、list-models で取得した稼働中バージョンの識別情報が組み合わさってしまいます。最初に、ユーザーの質問内容に応じてバージョンを特定してください — パフォーマンス／本番環境での状況：稼働中のバージョン（list-models → Tags[] の Name=live、それがなければ Models[] の Pinned: true のうち最も高いもの、さらにそれもなければ最新バージョン）。指示を改善するためのベースライン：最新の学習済みバージョン（編集内容によって再トレーニングされるモデルであるため）です（Improve Prompts Guide § 1a）。その後、そのバージョンを get-metrics --model-version <N> に渡し、スコアがどのバージョンのものかを明記してください。
21. メトリクスのフィールドは FieldId で比較し、Name で報告してください。 Fields[] には FieldGroup、FieldId、Name が含まれているため、タクソノミーを読み込む必要はありません — 読み込まないでください。表示名が一意なのはグループ内だけなので、同じ Name のフィールドが 2 つある場合は、該当する行を <FieldGroup> / <Name> として表示してください。Name はそのバージョンでのフィールド名であり、同じフィールドでもバージョンによって名前が異なる場合があります。バージョン間の照合には Name ではなく FieldId を使い、現在のバージョンの名前を報告してください。CLI Reference § get-metrics を参照してください。
22. 依頼されていないプロジェクトに切り替えてはいけません。必ず指示されたプロジェクトで作業してください。 対象の Name を一度特定し、セッション中はそれを維持して、すべてのコマンドで指定してください — Title は変更されますが、Name は変わりません（ルール 7）。依頼されていない限り、どれほど似ているように見えても、別のプロジェクトで変更を行ったり、作業を続けたりしないでください。問題を診断するために別のプロジェクトを読み取るのは構いませんが、作業をそちらに移すにはユーザーの明示的な許可が必要です。質問できない場合は、作業を妨げている問題を報告して停止してください。このタスクの結果として別のプロジェクトの結果を報告してはいけません。
23. タクソノミーのインポートによって変更してはいけません — インポートは名前に基づいてマージするため、名前の変更や削除はできず、同じ名前のエントリーの指示を上書きします。タクソノミーのないプロジェクトに、別のプロジェクトと同じタクソノミーを設定する目的に限り、projects import-taxonomy を使用してください。既存のタクソノミーを変更するには、groups／fields／data-types と projects update-prompt を使用してください。groups delete と groups add の組み合わせも置き換えにはなりません。依頼を満たす専用コマンドがない場合は、その旨を報告し、製品内の適切な場所に案内してください（Unsupported Capabilities） — 直接依頼された場合でも、インポートで代用してはいけません。詳細な仕組み：CLI Reference § import-taxonomy。

クイックスタート

1. uip ixp projects list --output json を実行して、既存のプロジェクトを確認します
2. 新しいプロジェクトを作成する場合：プロジェクトセットアップガイドに従います
3. 既存のプロジェクトを改善する場合：プロンプト改善ガイドに従います
4. 既存のプロジェクトのドキュメントにラベルを付ける場合：ドキュメントのラベル付けガイドに従います
5. Orchestrator フォルダーから自動化がモデルを呼び出せるようにデプロイする場合（Maestro Flow、その他のフォルダーを解決する呼び出し元）：projects create → list-models → deployments create --folder-key の順に実行します。ラベル付けも publish も必要ありません。詳しくはデプロイガイドを参照してください。

ユーザーからタクソノミーファイルが提供された場合、またはこのプロジェクトに別のプロジェクトのタクソノミーを適用する場合は、--skip-taxonomy と import-taxonomy を使用します（プロジェクトセットアップガイドのオプション B）。インポートによって、すでに内容があるタクソノミーが編集されることはありません（重要ルール 23）。

タスクのナビゲーション

ユーザーの依頼	操作
「IXP プロジェクトを作成して」／「新しいプロジェクトにドキュメントをアップロードして」	プロジェクト設定ガイド — 新規プロジェクトのみが対象です（アップロードとタクソノミーを1回の呼び出しで実行します）。既存プロジェクトについては、以下の「ドキュメントをアップロードする」の行を参照してください。
「このタクソノミーをインポートして」／タクソノミーファイルを提供／「別のプロジェクトと同じタクソノミーにして」	プロジェクト設定ガイド — オプション B（--skip-taxonomy + import-taxonomy）です。コピーする場合は、先に projects get-taxonomy でソースをエクスポートしてください。対象のタクソノミーは空である必要があります — projects get-taxonomy で確認し、label_groups が空でない場合は、代わりに対象を絞った groups／fields／data-types の呼び出しで変更を適用してください（重要ルール23）。
「タクソノミーの名前を変更／編集／再構成して」／「タクソノミーをこのファイルで置き換えて」／「タクソノミーの JSON を編集して」	対象を絞ったコマンドのみを使用してください — 以下の「追加／削除／名前変更」の行、および全体的な指示には projects update-prompt を使用します。import-taxonomy や groups delete + groups add は使用しないでください（重要ルール23）。対象を絞ったコマンドがない場合（Choice 型の値など）は、アプリ内で案内することを報告し、誘導してください — サポート対象外の機能を参照してください。
「ドキュメントにラベルを付けて」／「予測をレビューして」	ドキュメントのラベル付けガイド
「スコアを改善して」／「プロンプトを修正して」／「F1 を改善して」	プロンプト改善ガイド
「モデルを公開して」／「ライブとしてタグ付けして」	uip ixp projects publish <project-name> --output json — 最新バージョンをタグなしで公開します。タグも付けるには --tag <live|staging> を追加します。--model-version／--description については CLI リファレンスを参照してください。公開してもモデルは Orchestrator フォルダーにデプロイされません — publish はバージョンを固定し、--tag は live／staging タグを移動します。このタグによって、DU フレームワークが使用するバージョン（それを介して呼び出す DU アクティビティを含む）が選択されます。Orchestrator フォルダーからモデルを解決する呼び出し元（Maestro Flow など）には、「モデルをフォルダーにデプロイする」の行にある deployments create のみが適用されます。ユーザーがデプロイを依頼していない限り、公開にデプロイを続けて実行しないでください — デプロイにはフォルダーキーが必要で、ランタイムの呼び出し元が取得する内容が変わります。
「以前のバージョンにロールバックして」／「バージョン N を復元して」	uip ixp projects publish <project-name> --model-version <N> --output json — 以前のバージョンを再公開します。利用可能なバージョンは uip ixp projects list-models <project-name> --output json で取得してください。
「モデルの公開を解除して」／「モデルを本番環境から外して」	uip ixp projects unpublish <project-name> --model-version <N> --output json — バージョンを公開済みセットから削除します（トレーニング済みのままで、一覧にも表示されます）。--model-version は必須です。公開済みバージョンは list-models（Pinned: true）で確認してください。ライブバージョンを変更するには、代わりに別のバージョンを publish してください。
「live／staging タグを削除して」／「バージョンのタグを外して」	uip ixp projects untag <project-name> --tag <live|staging> --output json — 指定したタグを削除します（そのタグが指していたバージョンは公開されたままです）。タグを削除する方法は untag のみです — タグを消すために unpublish や再度の publish を実行しないでください（unpublish は公開を解除するもので、タグは削除しません。--tag なしの publish は既存のタグをそのまま残します）。live を staging に切り替えるには、代わりに publish --tag staging を実行してください。
「このモデルをフォルダーにデプロイして」／「ランタイムで呼び出せるようにして」／「バージョン N をデプロイして」	uip ixp deployments create <project-name> --version <N> --folder-key <guid> [--title <title>] --output json — トレーニング済みバージョンを Orchestrator フォルダーにデプロイし、アクティビティパックと Maestro Flow から呼び出せるようにします。--version（projects list-models で取得）と --folder-key（uip or folders list --output json で取得）はどちらも必須です。ユーザーがキーではなくフォルダー名を指定した場合は、同じ folders list で名前を解決してください。フォルダーがまったく特定されていない場合に限り、ユーザーに確認してください。--title の既定値は -ixp を除いたプロジェクト名です。create は既存のデプロイ先を変更しません — 同じフォルダーに別のバージョンで既にデプロイされたタイトルを指定すると 409 になります。次の行にある upgrade を使用してください。応答から DeploymentName を読み取ってください。これはスラッグ化され、サフィックスが付くため、タイトルやプロジェクト名とは異なります。CLI リファレンス § Deploymentsを参照してください。
「デプロイ済みモデルを別のバージョンに移動して」／「デプロイ済みモデルをアップグレードして」／「このフォルダーでは古いバージョンが稼働している」	uip ixp deployments upgrade <project-name> <deployment-name> --version <N> --folder-key <guid> --output json — <deployment-name> には deployments list の DeploymentName を指定します。タイトルを指定すると 404 になります。そのフォルダーと名前を使うすべてのランタイム呼び出し元が取得するバージョンが変わるため、共有フォルダーでは意図を確認してください。ロールバックには使用できません — 対象バージョンは projects list-models に表示されている必要があります。CLI リファレンス § create と upgradeを参照してください。
「このモデルはどこにデプロイされていますか？」／「デプロイを一覧表示して」／「ランタイムでどのフォルダーまたはバージョンが稼働していますか？」	uip ixp deployments list <project-name> --output json — DeploymentName、DeploymentTitle、ModelVersion、FolderKey、DeployedAt の配列を返します。未デプロイのプロジェクトでは [] を返します。DeploymentName を取得できる唯一の信頼できる情報源です — upgrade の前に実行してください。
「メトリクスを表示して」／「スコアはいくつですか？」	uip ixp projects get-metrics <project-name> --model-version <N> --output json — 必ずバージョンを指定してください。 --model-version を指定しない場合、CLI は最新のトレーニング済みバージョンを返します。これは公開済み／ライブバージョンとは限りません。先に list-models でライブバージョンを取得してください（「このプロジェクトのパフォーマンスはどうですか？」を参照）。重要ルール21に従い、読み取ったフィールド名を明示してください。応答の形式については、CLI リファレンス § get-metricsを参照してください。
「プロジェクトを一覧表示して」	uip ixp projects list --output json
「モデルを設定して」	uip ixp projects configure-model <project-name> [options] --output json
「このプロジェクトではどのモデル／前処理を使っていますか？」／「モデルの設定を確認して」	uip ixp projects get-taxonomy <project-name> --output json — 設定された抽出モデルと前処理は Data.dataset._model_config にあります。model_version は --model の値（例：gemini_2_5_flash）です。input_config は none／table_mini／table のトークンに逆変換する必要があります（null は未設定を意味するため、プロジェクトの既定値を報告してください。none ではありません）。get-model-config はありません。また、configure-model は読み取り後に書き込むコマンドです。現在の設定を確認するために呼び出してはいけません。設定を書き換えてしまいます。list-models の ModelName を根拠に回答しないでください。これはラベラーのファミリー（gemini_ixp）であり、--model の値ではなく、前処理についても何も示しません。逆変換表：CLI リファレンス § 現在のモデルと前処理の読み取り。
「プロジェクトを削除して」／「このプロジェクトを削除して」	uip ixp projects delete <project-name> -y --output json — 完全に削除され、元に戻せません。プロジェクトのドキュメント、タクソノミー、トレーニング済みモデルが削除されます。-y/--yes が必要です（CLI は確認を求めません）。
「ドキュメントをアップロードして」／「既存プロジェクトにドキュメントを追加して」	uip ixp documents upload <project-name> <file> --output json — CLI リファレンス § ドキュメントのアップロードを参照してください。1回の呼び出しにつき1ファイルです。複数の場合は繰り返し実行してください。新規プロジェクトの場合は、代わりに projects create を使用してください。
「ドキュメントを削除して」／「ドキュメントを取り除いて」	uip ixp documents delete <project-name> <document-id> -y --output json — 元に戻せず、再トレーニングが実行されます。-y/--yes が必須です（CLI は確認を求めません）。ファイル名で削除するには、documents list で DocumentId を調べてください（Filename フィールドに元のアップロード名が表示されます）。
「フィールドグループを追加／削除／名前変更して」	uip ixp groups {add,delete,rename} <project-name> --name <name> ... --output json — CLI リファレンス § グループを参照してください。groups add には --instructions と --fields-file <path> が必要です。新しいグループのフィールドをすべて1つの JSON 配列で渡してください（一括処理）。グループを作成してからフィールドを1つずつ追加しないでください（fields add は既存のグループにのみ使用します）。delete には -y/--yes が必要です（CLI は確認を求めません）。
「データ型を追加／編集／名前変更／削除して」	uip ixp data-types {add,update-instructions,rename,delete} <project-name> --name <name> ... --output json — CLI リファレンス § データ型を参照してください。add には --kind（text/date/money/number/boolean/choice）と --instructions が必要です。--input-value（exact-match/inferred）が必要なのは --kind text と --kind choice の場合のみです。他の型にはこのプロパティがなく、CLI はこのフラグを指定するとエラーになります。delete には -y/--yes が必要です（CLI は確認を求めません）。データ型を削除すると、それを参照するフィールドが壊れます。カスタム型を追加する前に、既定のデータ型を再利用してください（重要ルール16） — 多くの要件は組み込み型（例：通貨 → Monetary Quantity）で対応できます。
「フィールドを追加／削除／名前変更／型変更して」	uip ixp fields {add,delete,rename,change-type} <project-name> --group <name> --field <name> ... --output json — CLI リファレンス § フィールドを参照してください。delete には -y/--yes が必要です。change-type はアノテーションを削除するため、こちらも -y/--yes が必要です。
「フィールドを別のグループに移動して」／「このフィールドは X の下に置いて」	移動コマンドはありません — --group はフィールドを指定するもので、親グループを変更することはありません。projects get-taxonomy でフィールドの type と instructions を読み取り、対象グループに fields add してから、fields delete <source> -y を実行してください。追加を削除より先に行うことで、追加に失敗してもフィールドが元の場所に残ります。両方のグループがすでに存在している必要があります。移動によってグループが作成されることはありません。元に戻せません — 再作成したフィールドには新しい field_id が割り当てられるため、確認済みラベルは引き継がれません。開始前にその旨を伝えてください。get-taxonomy → 編集 → import-taxonomy でフィールドを移動しないでください：インポートはマージするため、フィールドは両方のグループに残ります。手順全体：CLI リファレンス § フィールドの別のフィールドグループへの移動。
「ドキュメントのフィールドを欠損としてマークして」	uip ixp labellings mark-missing <project-name> <document-id> --fields <ids> --output json — 指定したフィールドを欠損としてマークします。フィールドが実際に存在せず、IXP も値を予測しなかった場合に使用してください。予測に空の値で表示されるフィールドは、labellings confirm --fields に含めると同じ欠損マーカーが記録されます。IXP もそのフィールドの値を予測しなかった場合に限り、欠損としてマークしてください — 誤った予測を上書きするために使用してはいけません。重要ルール11を参照してください。
「誤った確認を取り消して／未確認に戻して」	uip ixp labellings unconfirm <project-name> <document-id> --fields <ids> --output json — 指定したフィールドに対する以前の confirm または mark-missing をロールバックします（confirm では確認を取り消せません — 重要ルール13）。ドキュメント上の他のすべてのアノテーションは引き継がれます。--fields のみを指定すると、繰り返し可能なグループの複数の出現箇所で共有されているフィールド ID は、すべての出現箇所から削除されます。特定の出現箇所をロールバックするには、--occurrence <N> を付けて --group を追加するか、--updates-file <path> を使用してください（confirm と同様です — 以下の行と重要ルール13を参照してください）。
「1つの明細／抽出を確認して」／「この出現箇所だけ確認して」	uip ixp labellings confirm <project-name> <document-id> --group <name> --occurrence <N> [--fields <ids>] --output json — 繰り返し可能なフィールドグループの特定の抽出を対象にします（0始まりのインデックス。最新の get-predictions の結果を基準にします）。--fields を指定しない場合は、その出現箇所の予測フィールドをすべて確認します。指定した場合は、それらのフィールドのみを確認します。他の出現箇所には影響しません。確認後の次の読み取りでは、グループの番号が振り直され、確認済みの行が Occurrence 0 に移動します。そのため、1回の読み取り結果に基づいて --occurrence を複数回連続して呼び出すのではなく、複数の出現箇所を1回の --updates-file <path> 呼び出しにまとめてください。重要ルール12と17を参照してください。
「1つの明細／抽出の確認を取り消して」／「この出現箇所だけロールバックして」	uip ixp labellings unconfirm <project-name> <document-id> --group <name> --occurrence <N> [--fields <ids>] --output json — 繰り返し可能なフィールドグループの特定の抽出をロールバックします（0始まりのインデックス。get-predictions／confirm と同じです）。--fields を指定しない場合は、その出現箇所でアノテーション済みのフィールドをすべて未確認に戻します。指定した場合は、それらのフィールドのみを対象にします。他の出現箇所には影響しません。先に get-predictions を再実行して読み直してください — 一部が確認済みのグループでは確認済みの行が先頭に並ぶため、行を確認したときのインデックスと、それをロールバックするときのインデックスは通常異なります（重要ルール17）。複数の出現箇所を1回で処理するには、代わりに --updates-file <path> を使用してください。重要ルール13を参照してください。
「抽出全体の指示を設定して」／「プロジェクトのプロンプトを更新して」	uip ixp projects update-prompt <project-name> --prompt "<text>" --output json — タクソノミー全体のプロンプト（IXP UI の「全体的な抽出指示」フィールド）を置き換えます。フィールドごとの fields update-prompts や、フィールドグループごとの groups update-prompts とは異なります。
「このプロジェクトのパフォーマンスはどうですか？」／「F1 はいくつですか？」	uip ixp projects list-models <project-name> --output json でライブバージョンを特定し、次に uip ixp projects get-metrics <project-name> --model-version <live-version> --output json を実行してください（重要ルール20）。Data が { Metrics: null } の場合、モデルはまだ検証されていません。その旨を報告して終了してください。代わりに Result: Failure と ErrorCode: not_found が返された場合（トレーニング済みモデルがまだないプロジェクト。例：確認済みのラベリングがない場合）も同様に扱い、「メトリクスはまだありません」と報告して終了してください。それ以外の場合、Data はフラットな形式です。次の順序で報告してください：（1）スコアがどのバージョンに属するかと TrainedTime、（2）全体の ProjectScore／ProjectScoreQuality、（3）FieldGroups[] のグループごとのスコア（F1／Precision／Recall）、（4）Fields[] のフィールドごとのスコアを F1 の低い順に並べたもの — F1 は Precision／Recall と併せて報告してください（F1 が低い場合、どちらが不足しているかによって修正方法が逆になります）。さらに Annotations（F1 のサンプル数）と ErrorRate（エラー数／Annotations。見逃しを数えるため、1 - Precision ではありません）も報告してください。Quality のラベルは無視してください（導出値で、スケールに一貫性がありません — プロンプト改善ガイド § get-metrics が返す内容を参照）。フィールドの名前と比較には Fields[] のみを使用してください（重要ルール21）。数値をそのまま伝えてください。求められていない限り「十分良い」などの評価はせず、低いスコアについてはプロンプト改善ガイドを案内してください。回答にはこれらの呼び出しのみを使用してください — その場しのぎの調査は禁止です（重要ルール#1）。
「このプロジェクトについて説明して」／「何が含まれていますか？」	3つの呼び出しを行い、次の順序で報告してください：（1）識別情報 — uip ixp projects get <project-name> --output json の Title／Name、（2）現在のモデルバージョン — list-models のライブ／公開済みバージョンと TrainedTime（設定された抽出モデルではなく、トレーニング済みバージョンです。設定された抽出モデルについては上の行を参照してください）、（3）タクソノミー — uip ixp projects get-taxonomy <project-name> --output json のラベルグループ数／フィールド数（生データでは Data.dataset.label_groups と Data.dataset.entity_defs に格納され、スネークケースです）。求められた場合のみ、パフォーマンス（上記）も加えてください。documents list はページングしないでください（その Data は { Documents, Total, Offset, Limit } というエンベロープであり、件数には Total を使用します）。デプロイメントバインディングも読み取らないでください。回答にはこれらの呼び出しのみを使用してください（重要ルール#1）。

よくある落とし穴

症状	原因	解決方法
報告されたスコアが、IXP UI のビルドページに表示されるスコアと一致しない	get-metrics が --model-version を指定せずに呼び出されたため、UI（またはご自身の文）で示された稼働中のバージョンではなく、最新のトレーニング済みバージョンが返されました	list-models でバージョンを確認し、get-metrics --model-version <N> を再実行してください。稼働中のバージョンがしばらく前に固定されたプロジェクトでは、新しいトレーニング済みバージョンが多数存在する場合があり、最新のもののスコアが低いこともあります。Critical Rule 20 を参照してください。
プロンプトを更新してもメトリクスが変わらない	再評価が完了していません	再トレーニングが完了するまで待ってください — プロンプト改善ガイド § 再トレーニングを待つ。
ModelVersion が進まない	再トレーニングがまだ進行中です	モデル入力（ラベリングまたは指示）に変更を加えると、必ず全面的な再トレーニングが実行されます。プロンプト改善ガイド § 再トレーニングを待つ にある上限付きの待機方法に従ってメトリクスを再確認してください — 固定間隔で、確認回数に上限を設け、それ以降は停止します。無期限にポーリングしないでください。
タクソノミーを編集したら重複が残った、または {"status":"ok"} にもかかわらず名前変更や削除が反映されなかった	手動編集した get-taxonomy のダンプを再インポートしました — インポートではマージされます	再インポートでは元に戻せません。projects get-taxonomy を読み込み、fields／groups／data-types delete -y で重複をそれぞれ削除してから、対象を指定するコマンドで変更をやり直してください。また、変更するつもりのなかった項目も確認してください。同じ名前のフィールドまたはグループは、ファイルに記載された指示とデータ型を引き継いでいます。重複フィールドで確定済みのラベルは統合されないため、その旨を伝えてください（Critical Rule 23）。
フィールドの指示と label_def の指示が矛盾している	fields update-prompts で編集できるのはフィールドごとの指示だけで、親の label_def の指示は編集されません	反復作業を始める前に label_def の instructions を読み、フィールドごとのプロンプトと矛盾している場合は groups update-prompts で更新してください。
確定した明細項目が先頭行として表示されるようになった、または他の行の Occurrence 番号が変わった	予期された動作です。読み取り結果では、注釈と予測の一致するペアが先に返されるため、確定済みの行が未確定の行より前に並びます	修正は不要です。値とページ上の位置は変わっていません。次の出現箇所ごとの呼び出しの前に get-predictions を再実行し、値を使って対象の行を指定してください（Critical Rule 17）。
2 回目の --occurrence 呼び出しで誤った行が対象になった、または unconfirm --occurrence N を実行しても何も起きなかった	先に行った確定によってグループの番号が振り直される前に取得した読み取り結果のインデックスを使いました	出現箇所ごとに書き込む場合は、その都度 get-predictions を再実行するか、1 回の --updates-file 呼び出しにまとめてください。
deployments create が 409 を返す	そのタイトルは、別のバージョンですでにそのフォルダーにデプロイされています — create は追加のみを行います	代わりに deployments upgrade <project-name> <deployment-name> を使用し、deployments list から <deployment-name> を取得してください（Critical Rule #19）。
deployments upgrade が 404 を返す	DeploymentName が必要な箇所に DeploymentTitle を渡しました — 名前はスラッグ化され、接尾辞が付加されるため（invoices → invoices-08963f00-ixp）、タイトルから導き出すことはできません	deployments list <project-name> --output json を実行し、表示された DeploymentName をそのまま渡してください。

未対応の機能

これらのリクエストはこのスキルの対象外です。リクエストを確認したら、標準の応答を返し、ユーザーを適切な先へ案内してください。調査（uip --help、grep、ソースの読み取り）は行わないでください。「重要なルール #1」を参照してください。

ユーザーのリクエスト	標準の応答
「モデルを作成して」／「プロジェクトを作成して」	ドキュメントまたは分類体系が提供されている場合、あるいは空のプロジェクトを求められた場合 → Project Setup Guide を使用してください（このスキルでプロジェクトを作成します）。それ以外の場合 → 「私は既存の IXP プロジェクトを扱っており、ゼロから作成することはできません。製品内で作成してください：https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/managing-projects — その後、ラベル付け、レビュー、改善をお手伝いできます。」
「これらのファイルをアップロードして」／「ドキュメントを追加して」	プロジェクト名が指定されている／すでにコンテキストにある場合 → 対応可能です。アップロードしてください（Task Navigation の「Upload a document」の行を参照）。それ以外の場合 → 「既存のプロジェクト名を指定していただければアップロードします。または製品内でアップロードしてください（新しいプロジェクトの場合など）：https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-deploying-models。」
「環境／別のテナントにプッシュして」／「ステージングまたは本番環境にデプロイして」	Orchestrator フォルダー（文字どおり Production という名前のフォルダー）が指定された場合 → 対応可能です。Task Navigation の「Deploy this model to a folder」の行を使用してください。それ以外の場合 → 「IXP には環境やテナントをまたぐデプロイ先はありません。デプロイとは、1 つのテナント内の（フォルダー、バージョン）の組み合わせです。」なお、projects publish --tag staging|live は、DU フレームワーク（およびそれを介して呼び出す DU アクティビティ）が解決するタグを切り替えます。それらの利用側にとっては、これがステージング／本番の切り替えにあたります。フォルダーへのデプロイは作成されません。
「X にアクセス権を付与して」／「このプロジェクトを共有して」／「ロールや権限を変更して」	「アクセス、ロール、権限はこのスキルではなく製品内で管理します：https://docs.uipath.com/ixp/automation-cloud/latest/overview/managing-access。」
「自分の自動化／ワークフロー／エージェントでこのモデルを使って」／「プロセスから抽出器を呼び出して」	「公開済みモデルを自動化内で使用するのは、このスキルの対象外であるオーサリング作業です。https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-consuming-a-workflow を参照してください。」
「これらのメール／通信を分析して」／「Communications Mining を設定して」	「Communications Mining はこのスキルでは扱わない、IXP の別の機能です（このスキルの対象はドキュメント抽出です）。https://docs.uipath.com/ixp/automation-cloud/latest/cm-user-guide/introduction-to-uipath-communication-mining を参照してください。」
「デプロイしたモデルを監視して」／「何件のドキュメントを処理した？」／「実行時のスループットやインシデントについて」	「デプロイ済みモデルの実行時／運用時の監視は、このスキルではなく Orchestrator で行います：https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/about-monitoring。設計時のスコアを確認するには、`get-metrics` を使用してください（「Show metrics」を参照）。」
「分類体系を置き換えて／上書きして」／「既存の分類体系にこのファイルをインポートして」	「IXP には分類体系を置き換える操作がありません。既存の分類体系にインポートすると、統合されて重複が発生します。対象を絞ったコマンドで差分を1つずつ適用できます。または、既存のプロジェクトのドキュメントとラベルをそのまま残したまま、きれいな状態で使えるよう、ファイルを新しいプロジェクトにインポートすることもできます。」その後、適用する差分を列挙し、ユーザーに選んでもらってください。
「データ型の値を編集して」／「Choice の選択肢を追加または削除して」	「CLI では、データ型の名前の変更、指示の変更（data-types update-instructions）、削除はできますが、既存の Choice データ型の値の追加や削除はできません。製品内の Manage Taxonomy ページで手動で変更してください：https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/managing-projects — その後、ここで続けましょう。」
「このプロジェクトにはどんな検証ルールがありますか？」／「ビジネスルールを追加して」	「CLI では検証（ビジネス）ルールの読み取りや更新はできません。製品内の Manage Taxonomy ページで手動で確認または編集し、その後、ここで続けましょう。」

リファレンスナビゲーション

• CLI コマンドリファレンス — オプションと出力形式を含む、すべての uip ixp コマンド
• プロジェクトセットアップガイド — 新しいプロジェクトの作成、ドキュメントのレビューとラベル付け
• プロンプト改善ガイド — 回帰検出を含む反復的な最適化ループ
• ドキュメントのラベル付けガイド — 予測をレビューして確認するための再利用可能なワークフロー
• デプロイガイド — バージョンを公開するか、実行時の呼び出し元向けに Orchestrator フォルダーへデプロイする