公開更新 AWS

AWS CodePipelineとは？仕組み・料金・V1/V2の違いと構築手順を解説【2026年版】

AWS CodePipelineとは？仕組み・料金・V1/V2の違いと構築手順を解説【2026年版】

AWS CodePipelineは、ソースコードの取得からビルド・テスト・デプロイまでの一連のリリース作業を自動でつなぐ、AWSのフルマネージドなCI/CD（継続的インテグレーション/継続的デリバリー）サービスです。開発者はステージとアクションを定義するだけでよく、実行基盤の管理は要りません。この記事では、CodePipelineの仕組みとAWS Codeシリーズでの役割、2026年10月時点のV1/V2パイプラインの料金と試算例、実行モードとトリガーフィルタの設定、CodeBuild・CodeDeployやTerraformとの連携、そしてGitHub Actionsとの使い分けまでを、公式ドキュメントの記述に沿って解説します。

まとめ：AWS CodePipelineの料金・V1とV2の選び方・採用判断の要点

  • CodePipelineはリリース工程の自動化を担う「指揮者」で、ビルドはCodeBuild、デプロイはCodeDeployなど各サービスに処理を委ねる。
  • パイプラインにはV1とV2の2タイプがあり、料金体系が異なる。V1はアクティブなパイプライン1本あたり月1USD、V2はアクション実行1分あたり0.002USD（2026年10月時点）。新規はGitトリガーやロールバックを使えるV2が基本。
  • 2024年以降、ステージレベルの条件・ロールバック・トリガーフィルタ・QUEUED/PARALLEL実行などV2専用機能が拡充された。
  • Terraformのaws_codepipelineはpipeline_typeを省略するとV1で作られる。IaCで作るときは明示が必須。
  • ソースにはGitHub・GitLab・Bitbucket・S3などが使え、CodeCommitは2024年に新規受付を停止したが2025年11月24日に一般提供へ復帰し、新規アカウントでも再び利用できる。

デプロイ先がAWSに閉じ、IAMでの権限分離やマルチアカウント展開が要件にあるならCodePipeline。GitHub中心で小さく回すチームなら、GitHub Actionsで完結させるほうが設定の手数は少なく済みます。

AWS CodePipelineとは｜CI/CDでリリース工程をつなぐ役割と特徴

CodePipelineは、コードの変更をトリガーに「ソース → ビルド → テスト → デプロイ」という一連の工程を自動実行するサービスです。各工程をステージとして定義し、ステージ間はアーティファクト（成果物）を受け渡しながら順番に進む仕組みです。手動でのビルド・デプロイ作業をなくすことで、リリースの遅延やヒューマンエラーを減らし、変更を安全かつ短時間で本番へ届けられます。CI/CDという考え方そのものや、パイプラインを構成する段階の分け方はCI/CDの仕組みとパイプライン構成・導入判断の基準で整理しているので、用語に不安があれば先に目を通すと読み進めやすくなります。

特徴は、サーバーやジョブ実行環境を自前で用意しないマネージド型である点です。JenkinsのようにCI/CDサーバーを構築・維持する必要がなく、パイプラインの定義に集中できます。実行結果はコンソールやEventBridge経由で監視でき、失敗したステージだけを再実行することも可能です。

パイプラインの定義はJSON（またはCloudFormationのYAML）で表現され、コンソールで作ったものもCLIのget-pipelineで取り出せます。この「定義をコードとして持てる」性質が、後述するIaC連携や環境の複製につながります。

AWS Codeシリーズとの分担とCodeCommit復帰後のソース選定

CodePipeline単体はビルドやデプロイの処理そのものを行いません。役割は各サービスを呼び出して工程を連結するオーケストレーション（指揮）です。そのため、実際のCI/CDは以下のAWS Codeシリーズや外部サービスと組み合わせて構成します。

  • ソース：GitHub、GitLab、Bitbucket（いずれもCodeConnections経由）、Amazon S3、Amazon ECR、AWS CodeCommit
  • ビルド/テスト：AWS CodeBuild（コンパイル・単体テスト・Dockerイメージ作成などを実行）
  • デプロイ：AWS CodeDeploy、AWS CloudFormation、Amazon ECS、AWS Lambda など

デプロイ工程で使うCodeDeployは、EC2やECSへの配信ルールをappspec.ymlで定義します。書き方はappspec.ymlとは？CodeDeployのAppSpecファイルの書き方・記述例・エラー対処で詳しく解説しています。In-PlaceとBlue/Greenのどちらで配信するかといったCodeDeploy側の設計判断はAWS CodeDeployのIn-Place・Blue/Greenデプロイと料金の解説が受け皿です。コンテナ中心の構成であれば、パイプライン定義を含めて管理してくれるAWS Copilotを使う選択肢もあります。

ソース候補で注意したいのがCodeCommitの扱いです。AWSは2024年7月25日にCodeCommitとCodeStarへの新規受付を停止し、CodeStarは2024年7月31日にサポートを終了しました。一時はCodeCommitも新規利用不可でしたが、AWS DevOpsブログの発表のとおり2025年11月24日に一般提供（GA）へ復帰し、新規アカウントでも再びリポジトリを作成できます。同じ発表ではGit LFS対応が2026年第1四半期に予定されていました。2024年時点の「CodeCommitは新規で使えない」という古い解説が今も多く残っているため、選定前に公式情報で現況を確かめてください。

リポジトリをどこに置くかは、パイプラインの起動方式にも響きます。GitHub・GitLab・BitbucketはCodeConnections経由のため、後述するV2のトリガーフィルタ（ブランチ・パス・タグ・プルリクエスト単位の起動）をそのまま使えます。

CodePipelineの仕組み｜ステージ・アクション・アーティファクトの関係

CodePipelineの構造は「ステージ」「アクション」「アーティファクト」の3要素と、複数の実行をどうさばくかを決める「実行モード」で理解できます。

ステージとアクションの6カテゴリとV2で加わったCommandsアクション

ステージはリリース工程の区切りで、ソースステージ・ビルドステージ・デプロイステージのように並べます。各ステージには1つ以上のアクションを置き、実際の処理（コード取得、ビルド、承認、デプロイなど）を担当するのがアクションです。アクションには6種類のカテゴリ（Source / Build / Test / Deploy / Approval / Invoke）があり、同一ステージ内のアクションは並列にも直列にも構成できます。

2024年以降は、シェルコマンドを直接実行するCommandsアクション（Computeカテゴリ）も加わりました。Commandsアクションの公式リファレンスによると、CodeBuildプロジェクトを作らずにコマンドを書けるかわりに、実体はCodePipeline管理のCodeBuildコンピューティングで動き、CodeBuild側の料金が別途発生します。使えるのはV2パイプラインのみで、1回の実行のタイムアウトは55分です。lintや簡単なスクリプト実行ならCommands、ビルドキャッシュやVPC内の依存を細かく制御したいなら従来どおりCodeBuildアクション、という切り分けになります。

先頭のソースステージは、リポジトリへのプッシュなどをきっかけに起動します。以降のステージはひとつ前のステージが成功したときだけ次へ進むため、テストに失敗すれば本番デプロイは実行されません。ビルドステージではCodeBuildが呼ばれ、コードのコンパイルや単体テストといった「ビルド」処理が行われます。CodeBuild自体の仕組み・ビルド環境・コンピューティングタイプ・料金・採用判断はAWS CodeBuildとは何かを実装者目線で解説した記事で詳しく確認できます。

アーティファクトの受け渡しとS3アーティファクトストアの暗号化

ステージ間でやり取りされる成果物がアーティファクトです。ソースステージが取得したコードは入力アーティファクトとして次のビルドステージへ渡り、ビルド後の実行ファイルやパッケージは出力アーティファクトとして後続のデプロイステージへ渡ります。これらの実体はパイプライン作成時に指定するAmazon S3バケット（アーティファクトストア）へ暗号化して保存されるため、S3の利用料が別途少額発生します。

既定の暗号化はAWS管理キーですが、別アカウントへデプロイする場合はカスタマー管理のKMSキーに切り替え、デプロイ先アカウントに復号権限を渡す必要があります。成果物をnpmやMavenのパッケージとして他チームへ配る場合は、S3ではなくレジストリ側に置く選択肢もあり、AWS CodeArtifactによる私有パッケージの配布が受け皿になります。

実行モード3種類｜SUPERSEDED・QUEUED・PARALLELの挙動の違い

短い間隔で複数のコミットが入ったとき、パイプラインがどの実行を先に通すかは実行モードで決まります。パイプライン実行の仕組みを説明した公式ページの定義を整理すると次のとおりです。

実行モード 挙動 対応タイプ
SUPERSEDED（既定） ステージ前で待つ古い実行を新しい実行が追い越す V1・V2
QUEUED 到着順に1件ずつ処理し追い越しなし V2のみ
PARALLEL 各実行が互いを待たずに同時進行 V2のみ

本番環境へのデプロイで「コミットの順番どおりに全部通したい」ならQUEUEDを選びます。PARALLELは機能ブランチごとに別の検証環境へ出す開発用途向けで、公式ページにもPARALLELではステージロールバックが使えないと明記されています。共有の本番環境にPARALLELを向けると、古い実行が後から完了して新しい成果物を上書きする事故が起こりうるため、本番には使いません。

V1とV2パイプラインの料金と機能の違い｜2026年10月時点の単価

CodePipelineにはV1とV2の2つのパイプラインタイプがあり、料金体系と使える機能が異なります。パイプラインタイプの公式説明では、V2はV1と同じ構造に「リリースの安全性とトリガー設定のための追加パラメータ」を持つ型と位置づけられています。選定で最初に確かめる項目です。

V1とV2の課金単位・無料枠・トリガー・実行モード・ロールバック比較

比較軸 V1 V2
課金単位 アクティブパイプライン単位 アクション実行時間単位
料金 月1USD／アクティブパイプライン 0.002USD／アクション実行1分
無料枠 月1本のアクティブパイプライン アカウントで月100分
Gitトリガーフィルタ 非対応 タグ・ブランチ・PR・ファイルパス
実行モード SUPERSEDEDのみ 3種（QUEUED・PARALLEL含む）
パイプライン変数 非対応 対応
ステージ条件・ロールバック 非対応 対応

CodePipelineの公式料金ページによると、V1の「アクティブパイプライン」とは、作成から30日を超え、その月に1回以上コード変更が通ったパイプラインを指します。作成後30日間は無料で、変更のない月も課金されません。V2は使った分だけの従量課金で、手動承認アクションとカスタムアクションは課金対象外です。

月の実行回数から見積もるV2料金の試算例とV1との損益分岐の目安

V2の請求額は「1回の実行で各アクションが動いた合計分数 × 月の実行回数」で決まります。単価と無料枠から、典型的な規模を試算すると次のようになります（2026年10月時点の単価で計算した概算）。

  • 小規模：1回あたりのアクション合計6分×月40回＝240分。無料枠100分を引いた140分×0.002USD＝約0.28USD。
  • 中規模：1回あたり10分×1日10回×30日＝3,000分。2,900分×0.002USD＝約5.8USD。
  • V1の同条件：本数だけで決まり、上の2例はどちらも1本なら無料枠内、2本なら月1USD。

V2で月1USDに届くのは有料分が500分を超えたあたりです。1本のパイプラインを頻繁に回すと、V1より高くなるケースも出てきます。それでもV2を勧めるのは、トリガーフィルタで不要な起動を減らせるうえ、ロールバックやQUEUEDといった安全装置の価値が数USDの差を上回るからです。ビルドアクションの実行時間がそのまま課金分数になるため、長いテストをCodeBuild側で並列化すると両方の請求を抑えられます。CodeBuildとアーティファクト用S3の料金は別に発生する点も見積もりに含めてください。

2024年以降に追加されたV2専用機能4つの内容と追加された時期

  • トリガーフィルタ：特定のGitタグやブランチ、プルリクエスト、変更ファイルのパスに絞って起動できる（2024年2月）。
  • 実行モード：後続実行で先行を上書きするSUPERSEDED（既定）に加え、順番待ちのQUEUED、同時実行のPARALLELを選べる。
  • ステージレベル条件：ステージの入場前・成功時・失敗時に、CloudWatchアラーム・デプロイ時間帯・Lambda・CodeBuild・シェルコマンド（Commandsルール、2025年3月）でゲートを設けられる（2024年8月）。
  • ステージロールバック：失敗時に直前の成功実行へ手動/自動で戻せる。条件失敗時の挙動はSkip・Fail・Rollbackから選択（2024年4月）。

これから新規に作るなら、Gitトリガーや安全なロールバックを備えたV2を選ぶのが基本です。V1は既存資産の互換維持が目的の位置づけになっており、既存のV1パイプラインもコンソールやupdate-pipelineでV2へ変更できます。

CodePipelineの構築手順｜コンソール作成からCLI・JSON定義での再現まで

コンソールのウィザードで作る最小構成のパイプラインと5つの手順

最小構成のパイプライン（ソース→ビルド→デプロイ）は、マネジメントコンソールの「パイプラインを作成」ウィザードから数分で作れます。おおまかな流れは次のとおりです。

  1. パイプライン名とパイプラインタイプ（V2）を指定し、アーティファクト用のS3バケットとサービスロールを設定する。
  2. ソースプロバイダ（GitHub等）を選び、Connections経由でリポジトリとブランチ、必要なら起動条件（トリガーフィルタ）を指定する。
  3. ビルドステージでCodeBuildプロジェクトを指定する（buildspec.ymlでビルド手順を記述）。
  4. デプロイステージでCodeDeploy・CloudFormation・ECSなどの配信先を指定する。
  5. 作成後、ソースへプッシュするか、以下のCLIで手動実行して動作を確認する。
aws codepipeline start-pipeline-execution --name MyAppPipeline
aws codepipeline get-pipeline-state --name MyAppPipeline
aws codepipeline get-pipeline --name MyAppPipeline > pipeline.json

3行目のget-pipelineで取り出したJSONは、metadataブロックを除けばcreate-pipeline --cli-input-jsonにそのまま渡せます。コンソールで作った構成を検証用アカウントへ複製するときの近道です。

トリガーフィルタをJSONで定義しブランチとパス単位で起動条件を絞る設定

モノレポで「services/api配下が変わったときだけ動かしたい」といった要件は、V2のトリガーフィルタで表現します。トリガーフィルタの公式手順にあるJSON構造をもとに、mainブランチへのプッシュとリリースタグの両方で起動する例を示します。

"triggers": [
  {
    "providerType": "CodeStarSourceConnection",
    "gitConfiguration": {
      "sourceActionName": "Source",
      "push": [
        {
          "branches": { "includes": ["main"] },
          "filePaths": {
            "includes": ["services/api/**"],
            "excludes": ["**/README.md"]
          }
        },
        { "tags": { "includes": ["v*"] } }
      ]
    }
  }
]

ブランチやパスはglob形式で書き、同じパターンをincludesとexcludesの両方に入れると除外が優先されます。注意したいのは手動実行時の挙動で、トリガーでブランチを絞っていても、コンソールやstart-pipeline-executionで起動するとソースアクションのBranchNameに書いたブランチが使われます。プルリクエストのトリガーが反応するのは、作成・更新・クローズ（マージ）の3イベントだけです。

手動承認アクションの7日タイムアウトとSNS通知による承認フロー

デプロイ先が本番の場合は、ビルドステージとデプロイステージの間に手動承認アクションを挟むのが定石です。手動承認の公式ガイドによると、パイプラインが承認アクションに到達してから7日以内に誰も承認・却下しないと、アクションは失敗扱いになり実行は先へ進みません。

承認待ちに気づかない事態を防ぐには、承認アクションにAmazon SNSトピックを設定し、メールやチャット連携のLambdaへ通知を流します。通知には確認してほしいURLとコメントを載せられるので、検証環境のURLを添えておくと承認者が判断しやすくなります。承認できるのはcodepipeline:PutApprovalResultを許可したIAMロールだけに絞り、開発者本人が本番リリースを自己承認できない権限設計にしておくのが安全です。

CodeBuild・CodeDeploy・Terraformとの連携構成とIaC化の手順

CodePipeline単体はオーケストレーションに徹するため、CodeBuildやCodeDeployなどと組み合わせて初めて実用的なCI/CDになります。代表的な連携パターンと、パイプライン自体をコードで管理する方法を整理します。

CodeBuild・CodeDeploy・CloudFormationとの連携パターン

ビルドをCodeBuild、デプロイをCodeDeployに委ねるのが標準構成です。インフラ自体をパイプラインで作る場合は、デプロイアクションにCloudFormationを指定し、テンプレートの作成・更新をパイプラインから実行します。cloudformation codepipelineのように、アプリと基盤の両方を1本のパイプラインで扱う構成もよく採用されます。

CloudFormationアクションでは、いきなり更新するCREATE_UPDATEより、変更セットを作るCHANGE_SET_REPLACEと実行するCHANGE_SET_EXECUTEの間に手動承認を挟む構成のほうが、意図しないリソース削除を止められます。スタック更新で設定が消える典型パターンはAWS CloudFormationのテンプレートの書き方と更新で消える設定の防ぎ方にまとめています。

Terraformでのパイプライン定義とpipeline_typeがV1既定の落とし穴

パイプライン自体をコードで管理したい場合は、TerraformやCloudFormationで定義します。Terraformのaws_codepipelineリソースで気をつけたいのが既定値です。Terraform AWS Providerのaws_codepipelineドキュメントには「pipeline_typeの既定値はV1」と書かれており、省略するとトリガーフィルタもQUEUEDも使えないV1で作られます。V2を前提にした設計なら次のように明示します。

resource "aws_codepipeline" "app" {
  name           = "my-app-pipeline"
  role_arn       = aws_iam_role.codepipeline.arn
  pipeline_type  = "V2"
  execution_mode = "QUEUED"

  artifact_store {
    location = aws_s3_bucket.artifacts.bucket
    type     = "S3"
  }

  stage {
    name = "Source"
    action {
      name             = "Source"
      category         = "Source"
      owner            = "AWS"
      provider         = "CodeStarSourceConnection"
      version          = "1"
      output_artifacts = ["source_output"]
      configuration = {
        ConnectionArn    = aws_codestarconnections_connection.github.arn
        FullRepositoryId = "my-org/my-app"
        BranchName       = "main"
      }
    }
  }

  stage {
    name = "Build"
    action {
      name             = "Build"
      category         = "Build"
      owner            = "AWS"
      provider         = "CodeBuild"
      version          = "1"
      input_artifacts  = ["source_output"]
      output_artifacts = ["build_output"]
      configuration = {
        ProjectName = aws_codebuild_project.app.name
      }
    }
  }
}

パイプラインの構成をバージョン管理でき、レビューと再現が容易になります。定義をリポジトリに置く考え方そのものはPipeline as Codeのメリットと実践方法で詳しく扱っています。Terraformの実行基盤や状態管理を含めて運用するなら、HCP Terraform（旧Terraform Cloud）の利用も運用方法を選ぶ際の検討材料です。なお、Terraformのplanとapply自体をCodeBuildアクションとしてパイプラインに組み込めば、インフラ変更のレビューから適用までを自動化できます。同じことをGitHub Actions側でOIDC認証を使って組む手順はGitHub ActionsとTerraformでAWSのCI/CDを構築する手順が参考になります。

導入前の注意点とGitHub Actionsとの使い分け｜採用条件と見送る場面

CodePipelineを採用する条件とGitHub Actionsで完結させる場面

CodePipelineは万能ではありません。CI/CDツールの選定では、GitHub Actionsとの比較が避けて通れません。判断の目安は次のとおりです。

  • CodePipelineが向く：デプロイ先がAWS中心で、IAMやCodeDeploy・CloudFormationとの権限・連携をAWS内で完結させたい場合。開発/本番のアカウントを分けたマルチアカウント構成でのデプロイ制御や、CloudWatchアラームを条件にした自動ロールバックも得意。
  • GitHub Actionsが向く：ソースがGitHubにあり、ビルド〜テストをリポジトリの近くで完結させたい場合や、マルチクラウド・多言語のワークフローを1か所で回したい場合。

「AWSを使っているから」という理由だけでCodePipelineを選ぶと、単純なビルド確認までにCodePipeline・CodeBuild・IAMロール・S3バケットと複数の設定が必要になり、かえって手間が増えます。GitHub中心の小規模チームでデプロイ先も1〜2環境なら、CodePipelineは見送り、GitHub Actionsで完結させたほうが速い。これが実務での判断軸です。Actions側の分単価や無料枠との比較はGitHub Actionsの料金と2026年改定後の無料枠で確認できます。CI/CDツール全体の選び方はGitHubとGitLabの違いを比較｜CI/CD・セキュリティで選ぶ判断基準も参考になります。

逆に、本番アカウントへの書き込み権限をGitHub側に一切持たせたくない、監査でデプロイ経路をAWS CloudTrailに一本化したい、という要件があればCodePipelineを選ぶ理由になります。CIはGitHub Actions、AWSへのデプロイはCodePipelineと分担する併用構成もよく採られます。

クロスアカウントデプロイで失敗するIAMロールとKMSキーの設定漏れ

クロスアカウントでデプロイする場合は、対象アカウントのIAMロールへの信頼関係とKMSキーの共有設定が前提になります。アーティファクトストアが既定のAWS管理キーで暗号化されていると、別アカウントのロールは成果物を復号できず、デプロイアクションが権限エラーで止まります。

対処は3点に集約されます。カスタマー管理のKMSキーに切り替えてキーポリシーで対象アカウントを許可すること、アーティファクト用S3バケットのバケットポリシーで対象アカウントのロールに読み取りを許すこと、アクション定義のroleArnに対象アカウント側のロールを指定することです。設定漏れはデプロイ失敗の典型的な原因なので、最初に権限設計を固めておくのが安全です。マルチアカウント構成のパイプライン設計やAWS基盤の構築を外部に任せたい場合は、一創のAWS・クラウドのインフラ構築サービスでCI/CDを含めた設計からご相談いただけます。

CodePipelineのよくある質問｜料金・V1とV2・承認期限・CodeCommit

codepipelineを調べる方から寄せられることの多い質問をまとめました。

CodePipelineの料金はいくらですか？

パイプラインタイプで異なります。2026年10月時点の公式料金ページでは、V1はアクティブなパイプライン1本あたり月1USD（無料枠は月1本、作成後30日間は無料）、V2はアクション実行1分あたり0.002USD（無料枠はアカウントで月100分）です。V2では手動承認とカスタムアクションは課金対象外です。別途、CodeBuildのビルド料金やアーティファクト保存用S3の利用料がかかります。

V1とV2はどちらを選ぶべきですか？

新規に作るならV2が基本です。Gitタグ・ブランチ・ファイルパスによるトリガーフィルタ、QUEUED/PARALLELの実行モード、ステージレベルの条件とロールバック、Commandsアクションといった機能はV2でのみ使えます。V1は既存パイプラインの互換維持が主な用途です。Terraformで作る場合はpipeline_typeを省略するとV1になるため、V2と明示してください。

承認期限（手動承認のタイムアウト）はどのくらいですか？

手動承認アクションは、パイプラインが承認アクションに到達してから7日以内に承認も却下もされない場合、失敗扱いとなる仕組みです。失敗したステージは再試行できますが、その間に新しい実行が来ると追い越される場合があります。SNSトピックで承認依頼を通知し、承認者と期限内の運用ルールをあらかじめ決めておくとリリースの停滞を防げます。

CodeCommitは今も新規で使えますか？

使えます。2024年7月に新規受付が停止されましたが、2025年11月24日に一般提供へ復帰し、新規アカウントでもコンソール・CLI・APIからリポジトリを作成できる状態に戻りました。ただしGitHubやGitLabなど外部リポジトリもConnections経由でソースに指定できるため、既存のリポジトリ運用に合わせて選べます。CodeCommit自体の料金や使い方はAWS CodeCommitのGA復活後の最新情報・料金・使い方で解説しています。

GitHub ActionsとCodePipelineはどちらがよいですか？

デプロイ先がAWS中心で権限・連携をAWS内で完結させたいならCodePipeline、ソースがGitHubにありビルド〜テストをリポジトリ近くで回したい、あるいはマルチクラウドで扱いたいならGitHub Actionsが向きます。両者を併用し、CIをActions、AWSへのデプロイをCodePipelineに任せる構成も可能です。小規模チームで環境が少ないなら、まずGitHub Actionsだけで始めるのが手数の少ない選択です。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.09　テックブログ IDCFクラウド（IDCフロンティア）不正アクセス・ランサムウェア：影響先・復旧・データは戻るか
  2. 2026.10.09　テックブログ ニッスイのサイバー攻撃で日水物流の入出荷停止｜委託先クラウド障害に荷主が備える手順
  3. 2026.10.09　テックブログ 京王電鉄のランサムウェア被害とグループ共通基盤：決済・ポイント・予約が止まった範囲と遮断の初動
  4. 2026.10.08　コラム 雇用保険の適用拡大：2028年10月の週10時間以上への変更と、勤怠・労務システムで直す判定ロジック
  5. 2026.01.14　テックブログ CGLA（シーグラ）とは？Lenzo（レンゾ）の半導体技術と上場・株の最新情報【2026年版】

RELATED POSTS 関連記事

一覧へ戻る

目次