PowerShellのシステム開発の発注/外注/依頼/委託方法について

PowerShellのシステム発注は、業務と例外の整理、実行環境と権限の設計、テストと運用移管の順に進めます。この順で決めると、稼働後も安全に運用を続けられます。

発注形態、RFPと要件、契約と費用、委託先の選定の順に見ていきます。

▼全体ガイドの記事
・PowerShellのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

PowerShellのシステムの定義

PowerShellのシステムとは、PowerShellで記述した処理を、実行基盤や認証・権限と組み合わせたものです。入力データや、ログ、通知、再実行の仕組みも含め、業務やIT運用を継続して動かします。

PowerShell単体は、無償のMITライセンスで提供されています。一方で、安全に業務で使うための設計や保守には費用がかかります。

単発スクリプトと業務システムの違い

処理の頻度や運用要件によって、スクリプトで足りるか、システムとして設計するかが変わります。

• 単発処理：CSVにある退職者のアカウントを停止するだけなら、スクリプトと手順書で足りる場合があります。
• 定期運用：毎月の入社・異動・退職を申請で処理するなら、承認記録、入力ミス検知、失敗対象の再実行を設計します。
• 発注条件：処理する人、データ、権限、頻度、失敗時の戻し方
• 構成要素：スクリプト、実行ランナー、入力元、権限・承認、実行結果・監査ログ、失敗通知、Git、監視、バックアップ
• 画面が必要な場合：Power AppsやWeb画面を置き、バックエンドからPowerShellを呼び出す形にできます。

たとえば、実行ランナーはタスクスケジューラーやAzure Automationで、入力元はCSV、API、データベースです。

発注に向く代表的な用途

繰り返し作業は自動化の効果を見積もりやすいため、次のような業務が発注の候補になります。

• アカウント管理：Active DirectoryやEntra IDの登録、停止、不要アカウントの洗い出し
• Microsoft 365管理：ユーザーやライセンスの管理
• 端末・サーバー運用：初期設定、パッチ適用、ログ収集
• 定期処理：ファイル連携、定期レポート、バックアップ確認
• Azure運用：リソースの作成・停止や障害時の定型復旧

画面が複雑で、大量のトランザクションや厳密なデータ整合性が中心になる場合は、PowerShellだけで完結させないほうがよいことがあります。たとえば、画面とデータベースにWebアプリケーション、申請にPower Appsを使う構成があります。

横断ジョブにはJP1やKompiraなどを組み合わせ、PowerShellはMicrosoft環境の操作に絞ると保守しやすくなります。

発注形態の選び方

発注形態は、小規模なスクリプト開発、クラウドやジョブ管理製品を使う運用自動化、画面・承認・データベースを含む個別開発の3段階で比べます。

段階は、業務の頻度や件数、ミスによる損失、承認の必要性、停止時の影響に応じて選びます。なお、最初から大規模なシステムにする必要はありません。

小規模な自動化のスクリプト開発

処理対象が数種類で、既存のWindows Serverや管理端末から実行でき、画面や複雑な承認も要らないなら、小規模な外注が適しています。

• 委託範囲：スクリプト数本、テスト、手順書を一式で依頼します。
• 処理例：社員情報CSVを検証してアカウントを作成し、結果を別ファイルに出力する処理
• 品質要件：入力値検証、二重登録防止、終了コード、ログ保存、実行権限の定義
• 納品と引き継ぎ：ソース、依存モジュール、手順、テストデータ、ロールバック方法を含め、2人以上が再実行できる状態で受け取ります。

既存の実行環境を使うと、初期費用を抑えられます。一方で、担当者のPCでしか動かない設計にすると、引き継ぎに支障が出ます。

クラウドやオーケストレーターによる実行管理

複数スクリプトの順序制御、失敗通知、実行履歴が必要なら、この形態も候補に入ります。Azure Automation、既存のジョブ管理製品、JP1、Kompiraなどを組み合わせる形です。

オンプレミスとAzureをまたぐ処理や夜間バッチ、依存ジョブ、複数部署での共通運用では、コードより実行管理の設計に目を向ける必要があります。

Power AutomateやRPAと比べる場合は、対象システムをAPIや管理モジュールで安定して操作できるかを確かめます。

• RPA：画面を人の代わりに操作する処理が中心の場合
• Power Automate：申請や通知が中心の場合
• PowerShell：WindowsやMicrosoft製品の管理操作が中心の場合

処理の安定性、権限管理、監査、失敗時の復旧を基準に、複数のツールから選びます。

画面・承認・データベースを含む個別開発

申請・承認から検索・監査までを扱う場合は、PowerShellに周辺機能を加えた業務システムとして発注します。

• 利用機能：Web申請、上長承認、処理結果の検索、監査履歴の確認
• 開発範囲：画面、データベース、認証、権限、通知、監査ログまで対象に含めます。
• 連携条件：複数の基幹システムでは、データの正本、タイムゾーン、文字コード、API制限、障害時の再送を決めておきます。
• 範囲の見直し：保守費が大きくなりやすいため、サービスデスクやPower Appsで代替できるかを比べ、RFPの範囲を絞ります。

RFPと要件の整理

RFPには技術名だけでなく、現状業務、目標、対象環境を書きます。さらに、制約、成果物、評価基準も記載します。要件が曖昧だと各社の見積もりの前提が異なるため、金額を比べられません。

発注者側で業務の事実を整理したうえで、提案してほしい範囲と、固定したい条件を分けます。

As-IsとTo-Beの業務一覧

現状の業務と導入後の業務を、担当、処理量、例外対応まで分けて書き出します。

• 現状の洗い出し：担当部署、頻度、件数、手作業時間、入出力、承認者、例外、個人情報の有無を記録します。
• 効果測定：月100件の登録に4〜6時間かかり、入力誤りが月に数件ある例をもとに、導入後の改善を測ります。
• 処理例外：開始条件、入力エラー、未承認、対象なし、通信断、同じデータを再投入したときの扱い
• 追加費用の予防：成功時の処理だけでなく、例外処理もRFPに書いておきます。

バージョンと接続先の技術要件

バージョンの互換性と実行環境を確かめられるよう、技術要件を具体的に書きます。

• バージョン選定：5.1を残す処理と7へ移す処理を分け、OS、採用版、利用モジュールを指定します。
• サポート期限：各バージョンのサポート期限を確かめます。
• 互換性検証：既存モジュールがすべて動くとは限らないため、検証をRFPに含めます。
• 実行条件：時間帯、同時実行数、API制限、ネットワーク、プロキシ、証明書、秘密情報の保管先を明記します。
• 運用分担：ログ保持、監視、バックアップ、障害連絡先を定め、発注者と受託者の分担表を作ります。

PowerShell 7.6は、2026年3月18日にリリースされたLTSで、2028年11月14日までサポートが予定されています。

一方で、7.5と7.4は2026年11月10日が期限です（出典: Microsoft Learn「PowerShell Support Lifecycle」、2026年）。

接続先には、Active Directory、Entra ID、Microsoft Graph、Exchange、Azure、SQL Serverなどがあります。また、接続先を書いておくと、本番アカウントやログ保存先の未決定も防げます。

セキュリティと納品物の発注条件

管理者権限を扱う場合は、実行ポリシーだけで十分に保護できるとは限りません。

• 実行ポリシー：単独では安全性を確保しきれないことがあります。
• 権限・防御：アクセス範囲を絞り、多層の対策を組み合わせます。
• 監視・監査：実行状況と操作記録を確認できる状態
• 納品物：ソースコード、設計資料、処理フロー、構成図
• テスト・安全管理：テスト資料、運用手順、個人情報保護の対策

Microsoftは、実行ポリシーを安全機能として説明しています。一方で、利用者の実行を止めるセキュリティ境界ではないとしています（出典: Microsoft Learn「about_Execution_Policies」、2026年）。

JEA（Just Enough Administration）で、許可するコマンドと操作対象を絞ります。さらに、MFA、署名済みスクリプト、秘密情報の外部保管、コードレビューも組み合わせます。

監視にはAMSIとScript Block Loggingを使い、監査ログも残します。また、納品物には基本・詳細設計書、パラメーター一覧、依存モジュール一覧を含めます。

テスト仕様書と結果、操作・障害対応手順、監視設定、権限一覧を確認します。あわせて、証明書や秘密情報の更新手順、バックアップと復旧手順も対象に含めます。

個人情報を扱う場合は、技術的安全管理措置として、アクセス制御と識別・認証を要件にします。また、不正アクセスや漏えいの防止、ログ分析なども要件に含めます（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2025年施行版）。

契約形態と費用相場の考え方

PowerShell本体は無償でも、費用は作業の範囲で決まります。要件の整理、設計・実装、テストに加えて、実行基盤や認証、ログ、監視の仕組みも対象になります。さらに、データ整備、移行、教育、保守も費用に入ります。

PowerShellだけの公的な価格統計は確認しにくいため、ここでの数字は、業務システム一般の公開相場と自動化事例の工数をもとにした税別の概算です。対象アカウント数や連携数などで変わるため、確定額ではありません。

規模別の費用レンジ

費用は、規模と含む作業によって変わります。次のレンジは、既存環境を使い、画面開発を大きく含めない場合の推定です。

• 小規模：スクリプト数本やPoCで30万〜100万円程度
• 部門内自動化：CSV・API連携などを含み100万〜500万円程度
• 中規模：申請・承認や監査ログなどを含み300万〜1,000万円程度
• 大規模：統合運用、段階移行などで3,000万円〜1億円以上の可能性

小規模には、現状調査、実装、テスト、手順書が含まれます。部門内自動化になると、複数スクリプトや権限、エラー通知、実行ログ、引き継ぎ資料まで含む場合があります。

中規模になると、AD、Entra ID、Microsoft 365の申請・承認が対象になります。さらに、一括処理、差分更新、監査ログ、テスト環境、本番展開も含まれます。

オンプレミスとAzureをまたぐジョブ管理、監視、再実行、複数拠点対応は、1,000万〜3,000万円程度です。統合運用や24時間体制、災害対策を含む場合は、3,000万円〜1億円以上になる可能性があります。

これらは、PowerShell固有の統計ではなく、要件から組み立てた推定値です。そのため、見積書にはその前提を明記してもらいます。

請負契約と準委任契約の使い分け

契約は、成果物や作業の確定度で選びます。請負と準委任では、責任の範囲と確認する項目が異なります。

• 請負契約：機能、受入条件、納期、成果物が明確な小規模開発
• 準委任契約：現状調査、要件定義、PoC、運用改善など、専門家の時間や知見が主な目的です。期間と役割を定めます。
• 組み合わせ：実装を請負、要件整理や運用支援を準委任とする方法

互換性調査や既存環境の解析は、進めてから初めて作業範囲が分かることがあります。そのため、これらを請負に含めると、追加変更の扱いで対立しやすくなります。

請負では、受入テストと未達時の修正範囲を決めておきます。さらに、仕様変更の手続き、著作権、ソースコードの利用条件も、契約書と個別仕様書で確認します。

契約の名称よりも中身を見て、責任の範囲、成果物、作業時間、報告方法を具体化します。さらに、再委託、障害対応、契約終了後の引き継ぎも取り決めます。

初期費用と3年TCOの比較

見積もりは、初期費用だけでなく、保守条件と3年間の総保有コスト（TCO）まで含めて比べます。

• 開発・基盤費：開発、実行基盤、ジョブ管理、監視・SIEM、秘密情報管理ごとに分けて示してもらいます。
• 継続費：Microsoft 365・Azureライセンス、ログ保存、バックアップ、証明書更新、教育、保守の費用
• 保守条件：年間保守の費用は、初期開発費の15〜20%が目安です。
• 3年TCO：初期費用、月・年額ライセンス、更新、障害、内製確認時間、停止時の損失を含めた合計

年間保守は、平日日中の問い合わせだけか、夜間・休日のオンコールや脆弱性対応まで含むかで、対応時間が変わります。

15〜20%は業務システム一般の目安で、PowerShell案件の一律料金ではありません。また、7.6 LTSでも、接続先モジュールの期限やMicrosoft GraphなどのAPI変更は別に管理します。

実行基盤や監視を含まずに安く見える見積もりもあるため、総額で比べます。

委託先の選定と見積比較の観点

委託先は、PowerShellの実装力だけでなく、Microsoft環境での要件定義と権限設計の経験で選びます。さらに、テスト、運用移管、障害対応の経験も見ます。

提案の時点では、匿名化した構成図、テスト計画、失敗時の再実行方法を確認します。あわせて、担当メンバーの経験と所属、再委託の有無も聞きます。

対象環境と成果を含む実績の確認

提案企業の実績は、自社の対象環境と照らし合わせて確認します。

• 実績の質問：AD・Entra IDのユーザー数、サーバー台数、処理、5.1と7の互換性検証、ログ、再実行設計について尋ねます。
• 部門内自動化：インフラ運用と内製化支援の経験を見ます。
• Microsoft環境：Microsoft 365や端末管理では、Azure、Intune、Entra IDの経験を確認します。
• 大規模・統合運用：複数拠点や高可用性は運用・セキュリティ、ジョブ統合はオーケストレーターの経験を見ます。
• 事例がない場合：PoCを先に契約し、技術適合性を確かめます。

IIMヒューマン・ソリューションの公開事例では、国内大手輸送会社のActive Directory管理を自動化しています。その対象は、約2万ユーザーと9台のサーバーで、工数は約2.5人月でした。

また、月100件超の登録を、月間約4〜6時間から約30分へ短縮したとされています（出典: IIMヒューマン・ソリューション「PowerShellを用いた運用の自動化」、2019年掲載情報）。金額は非公開ですが、対象規模と工数を比べる材料になります。

同じ前提にそろえた見積書の比較

比較条件を各社でそろえると、見積もりの差と範囲を把握できます。

• 共通の前提：同じRFP、業務一覧、環境、想定件数、ログ保持期間、運用時間帯を渡します。
• 作業項目：要件定義、設計、実装、テスト、移行、教育、運用設計、監視、保守に分けます。
• 費用条件：含む範囲と含まない範囲、準備アカウント、ライセンス、クラウド、出張、再委託費
• 変更・納期：仕様変更単価、遅延時の扱い、安い提案の別料金
• 段階案：高い提案が画面や基盤を過剰に作る前提かを確かめ、機能を削る案も求めます。

スクリプト本数では、例外処理やテストの厚みまで比べられません。

KPIと運用移管の選定基準

導入前後の効果と、委託先からの運用移管の体制を評価します。

• 処理KPI：手作業時間、処理件数、入力エラー・失敗・再実行の件数、完了時間
• 運用KPI：問い合わせ件数や夜間作業回数も含め、品質と復旧の状況を見ます。
• 管理責任：ソースコードの権利・形式、Git管理者、設計書とモジュール更新の担当を決めておく。
• 引き継ぎ条件：脆弱性連絡、夜間障害の対応時間、契約終了後の引き継ぎ

エラーが本当に減ったのか、確認作業が増えただけなのかを見分けるため、数字は両面から見ます。

別の会社や社内の担当者が修正できる条件を契約に入れておくと、ブラックボックス化を避けられます。

よくある質問

PowerShellの発注では、既存環境との互換性、権限、失敗時の復旧、保守の責任の範囲が疑問になりやすいものです。発注前によくある質問に答えます。

PowerShellのシステム開発費用はいくらですか？

小規模なスクリプト開発やPoCは30万〜100万円程度、部門内の定型運用自動化は100万〜500万円程度が概算です。

申請・承認、複数システム連携、監視、監査、24時間運用を含めると、300万円以上や1,000万円以上になる場合もあります。

PowerShell固有の公的な価格統計ではなく、要件と作業範囲から算出した推定レンジです。対象件数と納品物をそろえて見積もります。

PowerShell 5.1から7へ移行した方がよいですか？

新規の長期運用ではPowerShell 7.6 LTSが候補です。既存のActive Directory・Exchange関連モジュール、接続先OS、認証方式との互換性を検証したうえで決めます。

Windows PowerShell 5.1とPowerShell 7は併存できるので、すべてを一度に移さず、互換性のある処理から段階的に移す方法もあります。

移行可否、残す処理、サポート期限、切り戻し手順を発注要件に含めます。

PowerShellの外注でセキュリティをどう確認しますか？

管理者権限を常用せず、JEAで操作範囲を絞る設計になっているかを確認します。秘密情報をスクリプトやCSVに平文で保存しない点も見ます。

加えて、署名、コードレビュー、入力値検証、冪等性を確かめます。ログ面では、Script Block Logging、監査ログ、ログ閲覧権限を見ます。MFAも確認します。

失敗時の停止と再実行の方法、脆弱性対応の責任者も質問します。実行ポリシーを安全の根拠とはせず、多層防御として評価します。

まとめ

発注では、PowerShellを使うことより先に、どの業務を、どの品質で継続運用するかを決めます。単発スクリプト、実行管理基盤、画面・承認・データベースのどれが必要かを切り分けると、適切な形を選びやすくなります。

発注前に決めること

RFPには、業務の頻度・件数・現状工数、入出力、例外を書きます。利用者と承認者、対象環境、5.1と7の互換性もあわせて記載します。セキュリティではJEAや権限、署名を、運用ではログ、監視、再実行を要件にします。

納品物と保守範囲、受入条件は、発注前に決めておきます。費用は、小規模自動化の30万〜100万円程度から統合運用の3,000万円〜1億円以上まで幅があるため、3年TCOと業務効果で比べます。

小さく検証してから段階的に外注

小さく検証し、成果物と運用情報を自社に残しておくと、段階的に発注できます。

• 事前検証：対象環境に近いPoCや互換性調査を依頼し、成功条件と失敗時の復旧を確かめてから本開発へ進む流れ
• 自社に残す情報：ソースコード、設計書、テスト仕様、実行権限、ログ、更新期限
• 効果測定：導入前後の手作業時間、ミス、再実行件数から、業務成果を判断します。
• 継続性：将来のバージョン更新や担当者変更に対応できる形で、発注を進めます。

▼全体ガイドの記事
・PowerShellのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。