---
title: 「動いている」から「任せられる」へ - Git と Azure Pipelines で作る、市民開発の変更管理と証跡
tags:  #uipath #uipathfriends  
author: [UiPath Friends [公式]](https://www.docswell.com/user/UiPathFriends)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/L71YNQZDJG.jpg?width=480
description: 2026年10月09日(金)開催 UiPath Friends 関西ユーザー勉強会 ~AIエージェント時代の市民開発、「わかる」から「できる」へ~ UiPath 関西セッション
published: October 14, 26
canonical: https://www.docswell.com/s/UiPathFriends/ZPR7MG-20261009_UiPath
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/L71YNQZDJG.jpg)

「動いている」から「任せられる」へ
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.


# Page. 2

![Page Image](https://bcdn.docswell.com/page/G7WG4M98E2.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4JZL2Q99E3.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/YE6WV6KDEV.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GE5MD6P8E4.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/97298M6VJR.jpg)

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 のインストールが必要


# Page. 7

![Page Image](https://bcdn.docswell.com/page/DJY46X9Q7M.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/V7NYZ1L2E8.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/YJ9PZ54D73.jpg)

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 のコマンドとスクリプト


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GJ8D1YQ5JD.jpg)

Pull Request と Pipeline 実行画面


# Page. 11

![Page Image](https://bcdn.docswell.com/page/LJLMQ4X3ER.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/47MY1KLM7W.jpg)

参考リンク集：
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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/P7R9LXKLE9.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/PJXQW6567X.jpg)

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
デプロイ


# Page. 15

![Page Image](https://bcdn.docswell.com/page/3JK9V16GJD.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LE3WMQ65E5.jpg)

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 で標準化したい


# Page. 17

![Page Image](https://bcdn.docswell.com/page/8EDK69VY7G.jpg)

リポジトリの構成: 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 単位


# Page. 18

![Page Image](https://bcdn.docswell.com/page/V7PKYZV2J8.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/2JVVGWZXJQ.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/5EGL8D4RJL.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/4JQY91GY7P.jpg)

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
成功時・失敗時など実行条件を式で制御


# Page. 22

![Page Image](https://bcdn.docswell.com/page/K74WXR5ZE1.jpg)

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 の目印に使う


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LJ1YNQWDEG.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/GJWG4M6872.jpg)

参考リンク
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