「動いている」から「任せられる」へ - Git と Azure Pipelines で作る、市民開発の変更管理と証跡

「動いている」から「任せられる」へ Git と Azure Pipelines で作る、市民開発の変更管理と証跡 UiPath Friends 関西ユーザー勉強会 2026.10.09 UiPath テクニカルサポート本部 曽我 匡統 © 2026 UiPath, Inc. All rights reserved. This material is for informational purposes only. No part of it may be reproduced, distributed, or transmitted without the prior written consent of UiPath, Inc. The UiPath word mark, logos, and robots are trademarks or registered trademarks of UiPath, Inc. and its affiliates in the United States and other countries. See TMEP §906.

自己紹介 曽我匡統／UiPath テクニカルサポート本部 入社：2022年1月 担当： - UiPath製品のテクニカルサポート - サポート部門の業務自動化 これまでの仕事： - 製造業R&D - 流体解析ソフトウェアのサポート Qiita：@mstgsg

作るのは速くなった。でも、管理が追いついていない 作るスピードは上がった 1 2 3 現場で起きていること Coding Agent の進化 指示するだけでワークフローを生成できる 開発のすそ野が拡大 業務部門のメンバーも短時間で作れる 確認がボトルネックに 作るより確認・承認に時間がかかる ? ? ? パブリッシュのルールがない 誰が・いつ・何を出したか追えない 管理表が実態と合わない プロセス台帳の更新が後回しになる ソースの所在が分からない 開発者に聞かないと元のプロジェクトがない → 作った本人にしか直せない ＝ 属人化が進む

解決のアイデア：記録と反映を「仕組み」にする STEP 1 STEP 2 STEP 3 STEP 4 変更を記録 確認・承認 自動で実行 本番に反映 Git Pull Request Azure Pipelines UiPath Platform 証跡が残る：STEP 1〜4 のすべてで履歴・ログが記録される Git ＝ 変更の「記録係」 Azure Pipelines ＝ 決まった手順の「実行係」 いつ・誰が・何を・なぜ変えたかを残す 毎回同じ手順で、自動で Orchestrator に反映する

Pull Request の流れ 1. ブランチを作る 2. 変更してコミット 3. Pull Request 4. レビュー・承認 5. マージ main から作業用の枝を 作成 作業内容をこまめに記録 main への取り込みを依 頼 第三者が内容を確認 自動で反映が始まる

Windows上で利用できるGit関連ツール 用途や好みに合わせて使い分け。Coding Agentを使って開発する場合はGit Bash等のCLIツールが便利です。 UiPath Studio Git Bash GitHub Desktop TortoiseGit 種類 Studio に内蔵 コマンドライン（CLI） GUI アプリ エクスプローラー拡張 得意なこと コミット・プッシュ・ブラ ンチ切替を開発画面のまま 実行 Git の全機能が使える。CI の YAML と同じコマンド を試せる 変更の確認から Pull Request 作成までをシン プルな画面で 右クリックで操作。履歴・ 差分の表示が豊富 こんな人に UiPath Studioの画面から 離れずに Git を使いたい人 競合の解決やトラブル対応 をしたい人 Git 初心者、GitHub を使 うチーム TortoiseSVN に慣れてい る人 ※ Git Bash は Git for Windows に同梱。TortoiseGit を使うときも Git for Windows のインストールが必要

CI/CD で何が変わる？ CI：変更のたびに自動でチェック・パッケージ化 CD：自動で Orchestrator に反映 これまで（手作業） CI/CD 導入後 反映のしかた 担当者の PC から Studio で手動パブリッシュ main への取り込みをきっかけに自動で実行 手順 人によって微妙に違う YAML に書いた同じ手順を毎回実行 承認 チャットや口頭で「OK」 Pull Request のレビュー・承認として記録 記録 残らない／手作業の台帳頼み コミット・PR・実行履歴が自動で残る

パイプラインの全体像 きっかけ：main に変更がマージされる 準備 ログイン パッケージ化 パブリッシュ デプロイ STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 UiPath CLI などの道具を そろえる Orchestrator に安全に 認証する プロジェクトを .nupkg にまとめる テナントのフィードへ アップロード プロセスを作成・最新版 に更新 秘密の情報は安全に保管 手順書（YAML）も Git で管理 Orchestrator への接続情報（クライアントシークレット）は、 パイプラインの Library に保管し、ファイルには書かない パイプラインの定義ファイルもリポジトリに置くので、「手順の 変更」も履歴に残る ※ YAML の書き方や各ステップのコマンドは Appendix・Qiita 記事で詳しく紹介しています

YAML ファイルの例 azure-pipelines.yml trigger: branches: include: - main paths: include: - azure-pipelines.yml ‐ sample-function/** pool: vmImage: "windows-latest" variables: buildConfig: "Release" stages: - stage: Build jobs: - job: BuildJob steps: - checkout: self - script: echo "Building ($(buildConfig))..." displayName: "Build" trigger：いつ動くか main にマージされたら自動で実行 対象: azure-pipelines.yml または sample-function/フォルダ配下 pool：どこで動くか Microsoft が用意する Windows 環境 variables：何を使うか Library の接続情報を読み込む steps：何をするか 前のスライドの STEP 1〜5 を上から順に実行 中身は CLI のコマンドとスクリプト

Pull Request と Pipeline 実行画面

まとめ：「動いている」から「任せられる」へ 1 Git で「誰が・いつ・何を」変えたかを記録する 2 Pull Request で、反映前に第三者の確認・承認を通す 3 Azure Pipelines で毎回同じ手順で反映し、実行履歴を証跡にする もっと詳しく 構築手順・YAML サンプル・よくあるエラーは Qiita 記事で公開しています Azure Pipelines と UiPath CLI で UiPath プロジェクトの CI/CD 環境を構築する

• https://qiita.com/mstgsg/private/ff82a282029ac03b2c78

参考リンク集： Git入門-概念編 https://www.slideshare.net/slideshow/git-248316010/248316010 UiPath CLI ユーザー ガイド > CI/CD レシピ: Azure Pipelines https://docs.uipath.com/ja/uipath-cli/standalone/latest/user-guide/recipes-azure-devops Monorepo vs. multi-repo https://www.thoughtworks.com/insights/blog/agile-engineering-practices/monorepo-vs-multirepo Python Coded Functions https://uipath.github.io/uipath-python/core/functions/ Azure DevOps > Azure Pipelines > Use predefined variables https://learn.microsoft.com/en-us /azure/devops/pipelines/build/variables

• https://www.slideshare.net/slideshow/git-248316010/248316010
• https://docs.uipath.com/ja/uipath-cli/standalone/latest/user-guide/recipes-azure-devops
• https://www.thoughtworks.com/insights/blog/agile-engineering-practices/monorepo-vs-multirepo
• https://uipath.github.io/uipath-python/core/functions/
• https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables

Appendix 技術的な詳細・比較資料（Qiita 記事とあわせてご参照ください）

UiPath CLI（uip コマンド） Studio を開かずに、パッケージ化からデプロイまでをコマンドで自動化できる公式ツール uip コマンドの特徴 STEP 1 準備 npm install -g @uipath/cli STEP 2 uip login --client-id … --client-secret … --tenant … • npm で配布（@uipath/cli） ログイン • Node.js で動作し、 Windows / macOS / Linux のどれでも使える • ログインは対話型と 外部アプリケーションの両方に対応 STEP 3 パッケージ化 STEP 4 uip rpa pack <プロジェクト> パブリッシュ uip or packages upload <.nupkg> STEP 5 uip or processes create uip or processes update-version デプロイ

Git の基本用語（まずはこれだけ） 用語 ひとことで言うと リポジトリ（Repository） プロジェクトのファイルと変更履歴をまとめて保存しておく場所 コミット（Commit） 変更を記録する「セーブポイント」。誰が・いつ・何を変えたかが残る ブランチ（Branch） 本番用（main）に影響を与えずに作業するための「作業用の枝分かれ」 プルリクエスト（Pull Request） 「この変更を main に取り込んでよいですか？」というレビュー依頼 マージ（Merge） 確認・承認された変更を main に取り込むこと ヒント：UiPath Studio には Git 連携機能があり、画面操作でコミットやブランチ作成ができます。コマンドを覚えなく ても始められます。

Azure Pipelines と Automation Ops Pipelines の比較 UiPath CLIの登場により、Azure Pipelinesが有力な候補になった 観点 管理場所 Azure Pipelines + UiPath CLI UiPath Automation Ops Pipelines Azure DevOps UiPath Automation Ops / Orchestrator YAML + script + task Automation Ops UI + Pipeline Process Azure Pipelines agent (MS-hosted / self-hosted agent) Orchestrator job / Unattended Robot UiPath 操作 uip CLI で login / pack / publish / deploy Pipeline activities で clone / analyze / test / build / publish / promote 承認 Azure DevOps Environments / Approvals / Checks Action Center など UiPath 側の承認と 組み合わせやすい 拡張性 任意の CLI、script、Azure DevOps task を混ぜ やすい UiPath 中心の標準 flow を作りやすい 運用責任 CLI version、secret、agent image、artifact を 自分で設計 UiPath 側の folder、machine、robot、 Pipeline Process の設計が重要 pipeline 定義 実行主体 向いているケース DevOps 基盤に UiPath 以外も含めたい UiPath 中心の CI/CD を GUI で標準化したい

リポジトリの構成: Monorepo VS Multi Repos 観点 構成 Monorepo Multi Repo 複数 project を一つの repository に置く project / service ごとに repository を分ける 変更の見通し 関連変更を一つの PR で扱いやすい repo ごとの責務が明確 pipeline 設計 paths.include / paths.exclude が重要 repo 単位で pipeline を分けやすい 共通化 shared template / shared script を置きやすい 共通化には template repo や package 化が必要 権限 repo 全体の権限設計が難しい repo 単位で権限を分けやすい 不要な pipeline が動かないように制御が必要 project ごとに release lifecycle を分けやすい release 単位

技術的なポイント • Pipeline を定義するYAMLファイル自体もリポジトリに配置 + 管理対象 • UiPath CLIを使う • Orchestratorとの連携には外部アプリケーション + クライアント資格情報フローを使う • 資格情報等の機密情報はAzure Pipelines > Library に保存する (規模が大きくなった場合はAzure Key Vaultで管理も可能) • Pipeline の実行条件はブランチ / フォルダパス / タグで分ける

YAMLファイルの構成 trigger / pr いつ実行するか variables どの値を共通化するか、secret をどこから読むか stages 大きな工程。例: Build, Test, Deploy jobs agent 上で実行される作業単位 steps 実際の task / script / checkout

Task と Script の違い 観点 役割 観点 task 役割 Azure Pipelines が用意している task を呼び出す 書き方 task: NodeTool@0 のように task 名と version を指 inputs: に task 固有 の設定 を書く 定する Azure Pipelines が用 意して いる task を呼 び出す script 引数 引数 実行 内容 shell その 場で shell command を実 行する 実行内容 shell 向いている処理 例 `script: script: command line の引 数や環 境変数 として 書く task 側に 実装済 み。例: Node.js を入 れる、cache を復 元する 、artifact を publish する 自分 で書い た command がそ のまま 実行さ れる inputs: に task 固有の設定を書く command line の引数や環境変数として書く task ごと に実装 が決ま ってい る 向い ている 処理 script その場で shell command を実行する task: NodeTool@0 のよ うに task 名と version を指 定する 書き 方 例 task Windows では cmd.e xe、Linux/macOS では Bash。明 示した い場合 は bas h / pws h を使 う task 側に実装済み。例: Node.js を入れる、cache 自分で書いた command がそのまま実行される を復元する、artifact を 標準 publish する 化され た処理 、Azure Pipelines の組 み込み 機能、 再利用 される 処理 project 固有 の command、確 認用 command、短 い glue code NodeTool@0, Us ePythonVe rsion@ 0, Cache@ 2 task ごとに実装が決まっている Windows では cmd.exe、Linux/macOS では Bash。明示した node --version, np m ins tall -g, uip login, uip codedagent pack い場合は bash / pwsh を使う 標準化された処理、Azure Pipelines の組み込み機 能、再利用される処理 project 固有の command、確認用 command、短い glue code NodeTool@0, UsePythonVersion@0, Cache@2 node --version, npm install -g, uip login, uip codedagent pack

Azure Pipelines YAML 主要タグ一覧 Root / Trigger / Context タグ trigger 説明・主な用途 push時のCI起動条件。noneで無効化、branch指定も可 Execution / Steps / Control タグ jobs / job pr Pull Request作成・更新時の検証トリガー steps schedules cronで定期実行するスケジュールトリガー checkout parameters 実行時に渡す入力値。テンプレート切替にも使う variables pipeline / job / step で参照する値 resources repository・pipeline・container等の外部依存 pool 実行するagent pool / VM imageを指定 stages / stage デプロイ段階など大きな単位。jobsを束ねる extends / template 共通YAMLを再利用し、定義の重複を減らす 説明・主な用途 同じagent/サーバー上で実行する作業単位 job内で順番に実行される操作の一覧 ソースコードをワークスペースへ取得するstep task 組み込み / 拡張タスクを実行するstep script / bash / pwsh コマンドやシェルスクリプトを直接実行 inputs taskに渡すパラメータの名前 / 値 displayName Azure DevOps UIに表示する人間向け名称 dependsOn stage / job の依存関係を指定 condition 成功時・失敗時など実行条件を式で制御

Git の基本用語（詳細） 用語 意味 Repository source code と変更履歴を保存する場所 Commit ある時点の変更を記録した snapshot Branch main から分岐した作業線。feature 開発や修正を隔離する Pull Request / Merge Request branch の変更を main などへ取り込む前に review する仕組み Remote GitHub / Azure Repos などにある共有 repository Clone remote repository を local machine に複製する Pull / Fetch remote 側の変更を local に取り込む Push local の commit を remote に送る Tag 特定 commit に名前を付ける。release version の目印に使う

CI/CD ツールとの比較 観点 Azure Pipelines 主な定義場所 azure-pipelines.yml など任 意の YAML .github/workflows/*.yml .gitlab-ci.yml Jenkinsfile 得意領域 Azure DevOps 統合、 enterprise CI/CD、multistage deployment GitHub repository / PR との近 さ、Marketplace actions GitLab の DevSecOps lifecycle との統合 self-hosted での高い自由度、 既存 plugin 資産 実行環境 Microsoft-hosted / selfhosted agent GitHub-hosted / self-hosted runner GitLab runner Jenkins agent 管理負荷 中 低から中 中 高くなりやすい Azure DevOps を標準基盤 にしている組織 GitHub 中心の開発 GitLab に開発管理を寄せている 組織 既存 Jenkins 資産が大きい、特 殊な実行環境が必要 向いているケ ース GitHub Actions GitLab CI/CD Jenkins

参考リンク Qiita - Azure PipelinesとUiPath CLIでUiPathプロジェクトのCI/CD環境を構築する https://qiita.com/mstgsg/private/ff82a282029ac03b2c78 UiPath CLI ユーザー ガイド > CI/CD レシピ: Azure Pipelines https://docs.uipath.com/ja/uipath-cli/standalone/latest/user-guide/recipes-azure-devops Monorepo vs. multi-repo https://www.thoughtworks.com/insights/blog/agile-engineering-practices/monorepo-vs-multirepo Python Coded Functions https://uipath.github.io/uipath-python/core/functions/ Azure DevOps > Azure Pipelines > Use predefined variables https://learn.microsoft.com/en-us /azure/devops/pipelines/build/variables

• https://qiita.com/mstgsg/private/ff82a282029ac03b2c78
• https://docs.uipath.com/ja/uipath-cli/standalone/latest/user-guide/recipes-azure-devops
• https://www.thoughtworks.com/insights/blog/agile-engineering-practices/monorepo-vs-multirepo
• https://uipath.github.io/uipath-python/core/functions/
• https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables