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

Tektonのシステムを発注・外注するなら、Tekton本体だけでなく、Kubernetes、Git、コンテナレジストリ、テスト、脆弱性検査、署名、デプロイ、監視までを含むCI/CD基盤として要件化することが成功のポイントです。

この記事では、Tektonのシステム開発を開発会社やSIerへ依頼するときの進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積比較、導入後の保守まで順番に解説します。Jenkinsからの移行やOpenShift・EKS・GKEへの導入を検討している担当者が、何を自社で決め、何を外部へ委託するか判断できる状態を目指します。

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

Tektonのシステムを発注・外注するとは何ですか？

Tektonのシステムを発注・外注するとは、Kubernetes上でソフトウェアのビルド、テスト、イメージ作成、検査、署名、デプロイを自動化する仕組みの設計・構築・移行・運用を、外部の開発会社やSIerへ委託することです。Tektonは業務アプリケーションそのものではなく、業務アプリを安全かつ反復可能にリリースする開発・運用基盤です。

Tektonでは、コンテナとして実行する処理をTaskに分け、複数のTaskの順序や依存関係をPipelineに定義します。実行時にはTaskRunやPipelineRunが作成され、Gitの変更をきっかけにTekton TriggersがPipelineRunを生成します。公式ドキュメントでも、Taskは一つ以上のStepを持ち、Kubernetesクラスタ上のPodとして実行される構成が説明されています（出典: Tekton公式「Tasks」、2026年8月確認）。

したがって、発注時に「Tektonをインストールしてください」とだけ伝えると、対象範囲が狭すぎます。Gitリポジトリの認証、ServiceAccountとRBAC、Workspace、秘密情報、レジストリ、ログ、実行履歴、失敗時の再実行、ステージングから本番への承認までを、Tekton導入システムの一部として定義する必要があります。

標準的な構成では、Gitリポジトリ、Tektonを載せるKubernetesクラスタ、コンテナレジストリ、秘密情報管理、イメージスキャン、監視・ログ基盤、デプロイ先を連携させます。Tekton Pipelinesが処理の流れを担い、TriggersがWebhookを受け、Pipelines-as-Codeがパイプライン定義をGitのレビュー対象にします。Tekton Chainsを使う場合は、実行情報から署名付きの証跡を作成し、SLSAやin-totoに接続できます。

発注側は、クラスタの設計・構築、既存Jenkinsジョブの移行、共通Taskの標準化、セキュリティ設計、監視、利用者教育、月次保守のどこまでを依頼するかを分けて記載します。特に「構築後のアップグレードと障害対応を誰が行うか」を曖昧にすると、稼働後に担当者が不在になりやすいため、初期見積もりの段階で確認します。

Tektonの発注形態はどれを選ぶべきですか？

発注形態は、対象アプリ数、既存CI/CDの有無、Kubernetesの運用体制、セキュリティ要件、将来の拡張性で選びます。少数のサービスを短期間で自動化したい場合はマネージドサービスや既存SaaSとの組み合わせが候補になり、複数チームのパイプラインを標準化したい場合はTektonを中心に共通基盤を構築する方法が候補になります。

EKS、GKE、AKSなどのマネージドKubernetesにTektonを構築する形態は、コントロールプレーンの一部運用をクラウド事業者へ任せながら、PipelineやTaskの設計を自社の標準に合わせられます。クラウドをすでに利用している企業や、オンプレミスのクラスタ運用を新たに抱えたくない企業に向いています。

ただし、マネージドKubernetesでもノード、ストレージ、ロードバランサー、IPアドレス、通信、ログ、レジストリ、バックアップの費用と設定は別に発生します。開発会社には、クラスタを作るだけでなく、利用量の見積もり、権限設計、アップグレード方針、障害時の切り分けまで提案してもらいます。

OpenShiftを社内標準にしている企業は、TektonベースのOpenShift Pipelinesを採用し、Kubernetes基盤、Operator、認証、サポートをまとめて検討できます。Red Hatの製品サポートを受けられる範囲を明確にしやすく、ハイブリッドクラウドや複数クラスタの統制が重要な案件で比較しやすい選択肢です。

一方で、サブスクリプション費用や製品の標準運用に合わせる制約があるため、OSSを直接導入する場合と総額を比較します。OpenShiftを使わない環境へ将来移行する可能性がある場合は、TaskやPipelineの標準仕様、コンテナイメージ、IaCをどの範囲で持ち運べるかもRFPに含めます。

Jenkinsなどの既存資産が多い場合は、全ジョブを一度に移すのではなく、代表的な1〜2サービスを選んでPoCを行う形態が現実的です。Git pushから単体テスト、イメージ作成、脆弱性検査、ステージングデプロイまでを一つのPipelineでつなぎ、成功系だけでなく、失敗時の再実行、権限不足、レジストリ停止、Webhookの不正リクエストも検証します。

PoCの合格条件は、画面やYAMLが完成したことではありません。リリース時間、失敗率、復旧時間、クラウド費用、運用担当者が手順を実行できるか、監査に必要な証跡を残せるかを数値または確認手順で定めます。PoCを本番構築と同じ会社へ発注する場合も、PoC終了時に本番移行の追加費用と責任分界を見直します。

TektonのRFPと要件整理はどのように進めますか？

TektonのRFPは、機能一覧ではなく、現状の開発・リリース業務、対象サービス、非機能要件、連携先、セキュリティ条件、成果指標、移行計画を候補会社へ同じ条件で伝える文書です。業務アプリのRFPと異なり、開発者の体験、クラスタ運用、実行履歴、パイプラインの再利用性を明記することが重要です。

まず、Jenkins、GitHub Actions、GitLab CI/CDなどで動くジョブを一覧化します。リポジトリ、起動条件、実行頻度、利用する認証情報、生成物、デプロイ先、承認者、失敗時の手作業、ログの保存期間を記録すると、単純な移行と作り直しが必要なジョブを分けられます。

さらに、現在のリリース時間、テストの待ち時間、失敗率、手戻り、夜間対応、担当者しか分からない手順を整理します。「Tektonに移すこと」を目的にすると、既存の無駄な工程まで移植してしまいます。発注前に、リリースを速くする、環境差を減らす、証跡を残す、属人化を解消するなど、導入目的を優先順位付きで決めます。

機能要件には、Git pushやPull Requestでの起動、ブランチやタグによる条件分岐、Taskの再利用、並列実行、タイムアウト、リトライ、承認、通知、成果物の保管、ロールバックを含めます。開発・検証・本番で異なるパラメーターや秘密情報をどのように渡すか、WorkspaceやServiceAccountをどう分けるかも記載します。

周辺サービスでは、Gitリポジトリ、コンテナレジストリ、脆弱性スキャン、SBOM生成、KMSやSecrets管理、監視、ログ、デプロイ先を明確にします。CIをTektonで実行し、CDやGitOpsをArgo CDなどに分担させる構成もあるため、Tektonが担当する範囲と、別ツールへ任せる範囲をRFP上で切り分けます。

非機能要件には、同時実行数、1日あたりのPipelineRun数、目標実行時間、クラスタの可用性、復旧時間、ログと実行履歴の保持期間、バックアップ、ネットワーク接続、データ所在地、対応時間を含めます。Tektonの実行履歴を長期間保持すると、etcdやAPIサーバーへの負荷が問題になるため、保持期間と削除方法も要件にします。

セキュリティ要件では、Webhookの署名検証、最小権限RBAC、Namespace分離、非root実行、NetworkPolicy、イメージのdigest固定、秘密情報のログ出力防止、脆弱性対応、監査ログを明記します。TektonのHTTP ResolverにはSHA-256やSHA-512による取得内容の検証機能があるため、リモートTaskをブランチ名だけで参照しない運用も要件候補になります（出典: Tekton公式「HTTP Resolver」、2026年8月確認）。

SBOMを扱う場合は、誰が生成し、どこへ保管し、どのタイミングで脆弱性を照合し、顧客へ提供するかを決めます。経済産業省のSBOM手引Ver.2.0には、委託先との契約で要求事項、責任、コスト負担、権利などを定めるSBOM取引モデルが示されています（出典: 経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引Ver.2.0」、2024年）。

Tektonの契約形態はどのように選びますか？

契約形態は、要件がどこまで確定しているか、成果物を明確に定義できるか、途中で試行錯誤が必要かで選びます。Tekton導入では、要件整理やPoCの段階と、本番の構築・移行・テストの段階で不確実性が異なるため、全工程を一つの契約にまとめず、工程ごとに契約を分ける方法が実務的です。

準委任契約は、専門家が調査・設計・助言・作業を行うことに対して報酬を支払う契約です。既存Jenkinsの棚卸し、Kubernetesの適用可否、PoCの設計、移行方針の策定のように、調査して初めて作業量が分かる工程に向いています。成果物だけでなく、実施内容、稼働時間、会議体、報告書、次工程の判断基準を契約書や個別発注書で定義します。

準委任だから成果物を定めなくてよいわけではありません。RFPの課題一覧、現行構成図、PoCのPipeline、試験結果、リスク一覧、概算見積もりなど、次の意思決定に必要な納品物を明確にします。作業時間だけを管理すると、判断に必要な資料が残らない可能性があるためです。

請負契約は、合意した成果物を完成させ、検収して引き渡す工程に向いています。クラスタ構成、Tektonのインストール、標準Task、指定本数のPipeline、権限設定、テスト結果、運用手順書など、完成条件を事前に定義できる場合に検討します。検収基準には、正常系だけでなく、失敗時の再実行、ロールバック、権限エラー、バックアップ復元などの受入試験を含めます。

請負契約でも、クラウド料金や第三者サービスの料金、顧客側の環境提供遅延、仕様変更の扱いを別に決めます。仕様変更のたびに追加請求になるのか、変更管理会議で優先順位を入れ替えるのか、納期を延長するのかを決めないと、見積もりの安さと引き換えにトラブルが起きやすくなります。

本番稼働後は、TektonやKubernetesのアップグレード、Taskイメージの脆弱性対応、証明書と署名鍵の更新、障害調査、ログ・実行履歴の削除、Pipelineの追加を保守契約で定義します。対応時間、一次受付、復旧目標、月次報告、緊急変更、再委託、対応範囲外の単価を確認します。

ソースコード、PipelineとTaskのYAML、IaC、設定ファイル、テストコード、設計書、ダッシュボード定義、運用手順書、SBOM、署名・証跡の扱いも契約に含めます。成果物の著作権や翻案権、OSSライセンス表示、第三者ライブラリの責任、契約終了時のデータ返却とアカウント削除を確認し、ベンダー交代が可能な状態を作ります。

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

Tektonには、一般的な業務SaaSのように導入一式の公開定価があるわけではありません。費用は、Kubernetes基盤、Pipelineの設計・実装、既存CI/CDからの移行、セキュリティ、監視、教育、保守、クラウド利用料の合計で決まります。以下はリサーチノートにある業務システム開発相場を、Tektonの導入規模へ当てはめた編集上の目安であり、個別案件の確定金額ではありません。

開発用または検証用のKubernetesにTektonを構築し、数本のTaskとPipeline、Git webhook、簡易的なログ確認までを行うPoCなら、初期費用は100万〜300万円程度が一つの目安です。期間は1〜2か月程度を想定します。商用SLA、複数環境、複雑なJenkins移行、厳格な監査要件を含める場合は、この範囲を超える可能性があります。

この段階では、成功したPipelineを作るだけでなく、実行時間、クラスタのリソース消費、ログ保持、脆弱性検査、失敗時の復旧、利用者の操作性を測定します。PoC費用を本番導入の前払いと考えず、本番で必要な工数とリスクを具体化するための調査費用として評価します。

本番クラスタ一つに複数サービスを載せ、権限分離、レジストリ、テスト、ステージングデプロイ、監視、運用手順まで整えるチーム導入では、初期費用300万〜1,000万円程度が目安になります。期間は2〜4か月程度です。対象サービス数、既存ジョブの複雑さ、マルチテナント、SSO、可用性要件で工数は大きく変わります。

見積書では、要件定義、クラスタ設計、Tekton構築、共通Task、Pipeline移行、セキュリティ、テスト、教育、ドキュメント、リリース支援を分けてもらいます。単に「CI/CD基盤構築一式」と記載された見積もりは、安く見えても、何が含まれないのか比較できないため注意します。

Jenkinsからの大規模移行、複数チーム・複数環境、SSO、監査ログ、KMS、Chainsによる証跡、SBOM、監視、教育、段階展開まで含む全社導入では、初期費用1,000万〜5,000万円程度を見込むケースがあります。複数クラスタ、DR、厳格な変更管理、24時間運用、既存基幹システムとの連携まで含めるエンタープライズ案件では、5,000万〜1億円以上となる可能性もあります。

期間の目安は、部門展開で6〜12か月、複数クラスタや段階移行を含む場合で12〜24か月です。これは市場の一律価格ではなく、リサーチノートに記載された業務システム案件の規模別レンジをTektonの導入範囲に当てはめたものです。候補会社には、対象アプリ数、Pipeline数、環境数、移行対象ジョブ数を明示し、同じ前提で見積もりを作成してもらいます。

クラウド実費も開発費と分けて計上します。例えばAWS EKSの標準サポートは1クラスタ・1時間あたり0.10米ドル、延長サポートは0.60米ドルです。730時間稼働ならクラスタ管理料だけで月73米ドルまたは438米ドルとなり、EC2、EBS、ロードバランサー、IPv4、通信、ログ、レジストリは別料金です（出典: AWS「Amazon EKS pricing」、2026年8月確認）。Google Cloud GKEもクラスタ管理料が1クラスタ・1時間あたり0.10米ドルで、延長期間は追加料金が設定されています（出典: Google Cloud「Google Kubernetes Engine pricing」、2026年8月確認）。

Tektonの委託先選定と見積比較で確認するポイント

Tektonの委託先は、知名度や提示金額だけで決めません。Kubernetesの設計・運用、Tektonの実装、既存CI/CD移行、クラウド、セキュリティ、業務側との合意形成を一つの体制で進められるかを確認します。公開情報にTektonの解説があっても、実案件の規模や担当範囲まで分かるとは限らないため、提案時に具体的な質問を行います。

候補会社には、EKS、GKE、AKS、オンプレミス、OpenShiftのどれに対応できるか、クラスタを誰が運用するか、TerraformなどのIaCを納品できるかを確認します。Tekton Pipelinesだけでなく、Triggers、Pipelines-as-Code、Chains、Results、Dashboard、CLI、Operatorをどの範囲で使うかも聞きます。

さらに、Jenkinsの移行実績、GitOpsとの役割分担、イメージのdigest固定、SBOM、署名、KMS、脆弱性対応、監査ログを具体的に質問します。候補会社が「Tektonを知っている」と説明するだけでなく、失敗したPipelineの再実行、秘密情報の漏えい防止、実行履歴の削除、バージョンアップの手順まで説明できるかを見極めます。

相見積もりでは、同じRFPを渡すだけでなく、見積もりの前提条件をそろえます。対象クラスタ数、環境数、サービス数、Pipeline数、既存ジョブ数、同時実行数、対応時間、移行方式、テスト範囲、納品物、保守期間をそろえ、各社に「含む」「含まない」「別途」を明示してもらいます。

価格は、要件定義、PoC、設計、構築、移行、セキュリティ、テスト、教育、リリース支援、保守に分解して比較します。安い見積もりほど、クラスタの初期構築だけでPipeline移行や運用手順が含まれていない場合があります。高い見積もりでも、24時間対応や複数環境、監査証跡が不要なら過剰な可能性があるため、自社の要件に対する過不足で評価します。

納品物には、構成図、設計書、TaskとPipelineの定義、IaC、設定値一覧、権限一覧、テスト仕様書と結果、障害対応手順、バックアップ・復旧手順、アップグレード手順、教育資料を含めます。設定をベンダーの管理画面や担当者のローカル環境に閉じず、発注側のGitリポジトリでレビュー・変更できる状態にすることが重要です。

保守では、TektonやKubernetesのバージョンアップ、脆弱性の緊急対応、証明書・署名鍵の更新、ログやPipelineRunの保持・削除、障害時の連絡と復旧、利用チームの追加を確認します。Tekton公式は2026年に、完了したPipelineRunやTaskRunを保持し続けることでetcdやAPI性能に負荷がかかる課題に対し、保持ポリシーで自動削除するTekton Prunerを紹介しています（出典: Tekton公式「Introducing Tekton Pruner」、2026年2月）。このような運用課題まで説明できる会社を選びます。

Tekton導入後の保守運用は何を委託しますか？

Tektonは一度構築して終わる製品ではありません。KubernetesやTektonのアップグレード、Taskイメージの更新、クラウド料金の変化、脆弱性の検出、証明書や署名鍵の期限、実行履歴の増加、開発チームの追加に合わせて、継続的に運用を見直します。初期構築の契約と保守契約を分け、稼働後に誰がどの作業を担当するかを明確にします。

クラウド事業者はサービス基盤を提供しますが、クラスタ内の設定、権限、Task、秘密情報、アプリのテスト、パイプラインの誤設定まで自動で責任を負うわけではありません。開発会社、クラウド運用会社、社内開発部門の責任を、クラスタ障害、Pipeline失敗、イメージ脆弱性、誤デプロイ、秘密情報漏えい、料金超過の単位で整理します。

障害対応では、一次受付の時間、重大度の定義、暫定復旧と恒久対応の違い、ログ提供の方法、原因分析報告、再発防止策の期限を決めます。発注側が自社で対応できるように、管理者権限をベンダーだけに集中させず、緊急時のアクセス手順と操作ログを残します。

導入後は、デプロイ頻度、変更のリードタイム、Pipelineの成功率、失敗からの復旧時間、手動作業の時間、脆弱性の検出から修正までの日数、クラウド費用、実行履歴の保存量を追います。最初に設定した目標と実績を月次で比較し、不要なTask、過剰なリソース、長すぎるログ保持、重複するPipelineを見直します。

2026年時点のTektonは、2025年5月のPipelines 1.0以降もリリースが続き、2026年3月にはCNCFのインキュベーションプロジェクトになっています（出典: Tekton公式「Tekton Joins the CNCF as an Incubating Project」、2026年3月）。将来性を理由に導入を急ぐのではなく、採用するコンポーネントのバージョン、サポート期間、互換性、アップグレード担当を契約と運用計画に落とし込みます。

Tektonのシステム発注・外注でよくある質問

Tektonの外注では、OSSであることから費用や運用負担を誤解しやすく、既存CI/CDからの移行範囲も会社ごとに異なります。ここでは、発注前に特に質問されやすい論点を、結論から回答します。

いいえ、TektonのOSS利用にライセンス費用がない場合でも、導入費用が無料になるわけではありません。Kubernetes、ノード、ストレージ、レジストリ、監視、セキュリティ、設計・構築、移行、教育、保守の費用が発生するため、総保有コストで比較します。

発注はできますが、TektonだけでなくKubernetesの設計・権限・ネットワーク・監視・アップグレードまで対応できる会社を選ぶ必要があります。社内に経験者が少ない場合は、PoC、運用手順の整備、教育、稼働後の伴走保守を含め、担当者が自走できるまでの支援をRFPに記載します。

一度に全てを移行せず、代表的な1〜2サービスでPoCを行い、並行稼働と段階移行を検討する方法が安全です。移行対象の優先順位、既存成果物との同一性、テスト結果、切り戻し条件、Jenkinsを停止する時期を決め、問題が起きても旧環境へ戻せる期間を設けます。

対象サービスとリポジトリ、現行CI/CDのジョブ一覧、クラスタとクラウドの条件、利用者と環境数、想定Pipeline、連携先、セキュリティ要件、希望時期、予算の考え方、納品物、保守範囲を渡します。機密情報を含む場合は、先に秘密保持契約を結び、実データの代わりに構成を説明する資料で提案を受けます。

まとめ

Tektonのシステムを発注・外注するときは、Tektonのインストールだけでなく、Kubernetes、Git、レジストリ、セキュリティ、監視、デプロイ、保守を一体の基盤として考えます。発注形態は、マネージドKubernetes、OpenShift Pipelines、OSSの自社導入、PoCからの段階移行を比較し、自社の運用体制と将来の拡張性に合う方式を選びます。

RFPでは、既存CI/CDの課題、対象サービス、Pipelineの機能、セキュリティ、非機能要件、移行方式、検収条件を具体化します。費用は、PoC・小規模なら100万〜300万円、チーム導入なら300万〜1,000万円、全社展開なら1,000万〜5,000万円程度を目安にし、クラウド実費と保守費を別に見積もります。金額だけでなく、何が含まれ、何が自社の責任かを比較することが重要です。

最初から全社のPipelineを完成させようとせず、代表的なサービスでGit pushからテスト、イメージ検査、ステージングデプロイまでを検証します。その結果をもとに、委託先へ同じRFPを渡して複数社の提案と見積もりを比較し、納品物、契約、保守、ベンダー交代の条件まで合意してから本番展開へ進めます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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