Terraformを使ったIaCの実践

要約

Terraform実践入門 2026: クラウドインフラをコードで管理するIaC戦略

クラウドインフラをコードで効率的に管理し、開発プロセスを自動化するためのTerraformの最新実践ガイドです。

Keywords: Terraform, IaC, DevOps

はじめに: なぜ今、Terraformなのか？

現代のクラウドネイティブな開発において、インフラストラクチャの管理は避けて通れない重要な課題です。手動でのインフラ構築・設定は、ヒューマンエラーのリスク、作業の非効率性、そして再現性の欠如といった多くの問題を引き起こします。特に2026年現在、マイクロサービスアーキテクチャやコンテナ技術の普及により、インフラはますます複雑化し、動的な変化が求められるようになっています。

このような背景の中、「Infrastructure as Code (IaC)」の概念が注目を集めています。IaCとは、インフラストラクチャのプロビジョニングと管理を、コードとして定義し、バージョン管理システムで管理するアプローチです。これにより、ソフトウェア開発と同じようにインフラを扱えるようになり、一貫性、再現性、自動化、そして効率性が大幅に向上します。

“2026年のクラウドインフラ管理において、IaCはもはや選択肢ではなく、必須の戦略となっています。その中心にあるのが、HashiCorp Terraformです。”

— Kwonteki

Terraformは、HashiCorp社が開発したオープンソースのIaCツールであり、様々なクラウドプロバイダ（AWS, GCP, Azureなど）やオンプレミス環境のインフラを、一貫したHCL（HashiCorp Configuration Language）という宣言型言語で定義・管理することを可能にします。この柔軟性と汎用性により、TerraformはIaCツールのデファクトスタンダードとしての地位を確立しています。

本記事では、2026年時点でのTerraformの最新のベストプラクティスに焦点を当て、その基本概念から、AWS、GCP、Azureといった主要クラウドプロバイダでの実践方法、効果的なモジュール化、状態管理、そしてCI/CDパイプラインとの統合まで、幅広く解説します。Terraformをこれから学び始める方、または既存の知識をアップデートしたいと考えている経験豊富なエンジニアの方々にとって、実践的なガイドとなることを目指します。

CORE CONCEPTS

Terraformの基本概念とIaCの原則

Terraformを効果的に活用するためには、その根底にあるIaCの原則と、Terraform独自の基本概念を理解することが不可欠です。

IaC（Infrastructure as Code）のメリット

IaCは、インフラをコードで管理することで、以下のような多大なメリットをもたらします。

IaCの主要メリット

✔ 一貫性と再現性: コードとして定義されるため、環境間で設定のばらつきがなく、常に同じインフラを再現できます。

✔ バージョン管理: Gitなどのバージョン管理システムと連携し、インフラの変更履歴を追跡、ロールバック、レビューが可能です。

✔ 自動化と効率化: 手動作業を排除し、インフラのプロビジョニングと更新を自動化することで、デプロイ時間を短縮し、運用コストを削減します。

✔ コラボレーションの促進: チームメンバー間でインフラ構成を共有し、共同で開発・レビューを行うことができます。

Terraformの核心要素

Terraformは、宣言型のHCL（HashiCorp Configuration Language）を使用してインフラを定義します。主要な要素は以下の通りです。

Terraformの基本要素

プロバイダ (Providers) — AWS, GCP, Azureなどのクラウドサービスや、Kubernetes、DatadogといったSaaSサービスとTerraformを連携させるためのプラグインです。各プロバイダは、それぞれが管理するリソースタイプを公開します。

リソース (Resources) — プロバイダが提供するインフラの構成要素です。例えば、AWSであればEC2インスタンスやS3バケット、GCPであればCompute EngineのVMやCloud Storageバケットなどが該当します。

データソース (Data Sources) — 既存のインフラ情報をTerraformコード内で参照するための機能です。例えば、既存のVPC IDを取得したり、AMIの最新バージョンを検索したりする際に利用します。

変数 (Variables) — インフラ構成を柔軟にするための入力値です。環境ごとに異なる設定（例: インスタンスタイプ、リージョン）を外部から渡す際に使用します。

出力 (Outputs) — プロビジョニングされたインフラの情報を外部に公開するための値です。例えば、作成したロードバランサーのDNS名や、データベースのエンドポイントなどを他の設定やアプリケーションに渡す際に利用します。

これらの要素を組み合わせることで、複雑なインフラ構成をコードで表現し、Terraformコマンド（terraform init, terraform plan, terraform apply）を使って、その構成を実際のクラウド環境に適用します。

コード解説

以下は、AWSプロバイダを設定し、S3バケットとEC2インスタンスを定義するシンプルなTerraform構成の例です。HCLの基本的な構造と、リソース定義の仕方を示しています。


# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1" # 東京リージョン
}

resource "aws_s3_bucket" "my_bucket" {
  bucket = "kwonteki-unique-bucket-2026-example"
  acl    = "private"

  tags = {
    Name        = "MyTerraformBucket"
    Environment = "Dev"
  }
}

resource "aws_instance" "web_server" {
  ami           = "ami-0abcdef1234567890" # 適切なAMI IDに置き換えてください
  instance_type = "t2.micro"
  key_name      = "my-ssh-key" # 既存のキーペア名に置き換え
  vpc_security_group_ids = ["sg-0123456789abcdef0"] # 既存のSG IDに置き換え

  tags = {
    Name = "WebServer"
  }
}

output "bucket_name" {
  description = "The name of the S3 bucket"
  value       = aws_s3_bucket.my_bucket.bucket
}

output "instance_public_ip" {
  description = "The public IP address of the web server"
  value       = aws_instance.web_server.public_ip
}

PRACTICAL APPLICATION

主要クラウドプロバイダにおけるTerraform実践

Terraformの最大の強みの一つは、多様なクラウドプロバイダに対応している点です。ここでは、主要な3つのクラウドプロバイダ（AWS, GCP, Azure）におけるTerraformの実践例と、それぞれの特徴を比較します。

AWS (Amazon Web Services) でのTerraform

AWSは、Terraformが最も広く利用されているクラウドプロバイダの一つです。非常に豊富なリソースタイプが提供されており、複雑なインフラもTerraformで管理できます。

コード解説

AWSでVPC、サブネット、インターネットゲートウェイを構築する基本的なTerraformコードです。ネットワーク基盤の自動化はIaCの典型的なユースケースです。


# aws-vpc.tf
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "main-vpc"
  }
}

resource "aws_subnet" "public" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a"
  tags = {
    Name = "public-subnet-1a"
  }
}

resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "main-igw"
  }
}

output "vpc_id" {
  value = aws_vpc.main.id
}

AWSプロバイダは非常に成熟しており、AWSの新しいサービスがリリースされると、比較的迅速にTerraformプロバイダも更新されます。認証は、IAMロール、アクセスキー、環境変数など、AWS SDKがサポートする様々な方法に対応しています。

ポイント

AWSでのTerraform利用時は、IAMポリシーの最小権限の原則を徹底し、Terraformが操作するリソースに対してのみ必要な権限を付与するようにしましょう。

GCP (Google Cloud Platform) でのTerraform

GCPもまた、Terraformの強力なサポートを受けています。特にGKE（Google Kubernetes Engine）のようなマネージドサービスとの親和性が高く、コンテナ環境の構築・運用にTerraformが広く利用されています。

コード解説

GCPでGKEクラスタとCloud Storageバケットをプロビジョニングする例です。GCPプロバイダはプロジェクトIDと認証情報が必要です。


# gcp-gke.tf
provider "google" {
  project = "your-gcp-project-id" # ご自身のプロジェクトIDに置き換え
  region  = "asia-northeast1"     # 東京リージョン
}

resource "google_container_cluster" "primary" {
  name     = "kwonteki-gke-cluster"
  location = "asia-northeast1-a"
  initial_node_count = 1
  node_config {
    machine_type = "e2-medium"
    oauth_scopes = [
      "https://www.googleapis.com/auth/cloud-platform",
    ]
  }
}

resource "google_storage_bucket" "static_site_bucket" {
  name          = "kwonteki-static-site-2026" # グローバルでユニークな名前
  location      = "ASIA"
  uniform_bucket_level_access = true
}

output "gke_cluster_name" {
  value = google_container_cluster.primary.name
}

GCPプロバイダの認証は、サービスアカウントキーファイル、gcloud CLIの認証情報、または環境変数を通じて行われます。本番環境では、サービスアカウントを利用した認証が推奨されます。

Azure (Microsoft Azure) でのTerraform

Microsoft Azureもまた、TerraformによるIaCの強力なプラットフォームです。Azure Resource Manager (ARM) テンプレートに代わる選択肢として、Terraformが多くの企業で採用されています。

コード解説

AzureでリソースグループとStorage Accountを構築する例です。AzureプロバイダはサブスクリプションIDやテナントIDを必要とすることがあります。


# azure-storage.tf
provider "azurerm" {
  features {}
  # subscription_id = "..."
  # client_id       = "..."
  # client_secret   = "..."
  # tenant_id       = "..."
}

resource "azurerm_resource_group" "main" {
  name     = "kwonteki-resource-group-2026"
  location = "Japan East"
}

resource "azurerm_storage_account" "main" {
  name                     = "kwontekistorage2026" # グローバルでユニークな名前
  resource_group_name      = azurerm_resource_group.main.name
  location                 = azurerm_resource_group.main.location
  account_tier             = "Standard"
  account_replication_type = "GRS" # 地理冗長ストレージ
}

output "resource_group_name" {
  value = azurerm_resource_group.main.name
}

Azureプロバイダの認証は、サービスプリンシパル（クライアントIDとシークレット）、マネージドID、またはAzure CLIの認証情報を通じて行われます。CI/CD環境では、サービスプリンシパルが一般的です。

9.0

/ 10

主要クラウドプロバイダでのTerraformサポートは非常に充実しており、どの環境でも高いレベルのIaCを実現できます。

BEST PRACTICES

効果的なTerraformモジュール設計とベストプラクティス

Terraformを大規模なプロジェクトやチームで利用する場合、コードの再利用性、保守性、そして可読性を高めるために「モジュール化」が非常に重要になります。モジュールは、関連するリソースを一つの論理的な単位としてカプセル化する機能です。

モジュールを使う理由

モジュールを利用する主な理由は以下の通りです。

モジュール化のメリット

✔ 再利用性: 同じ構成パターン（例: VPC、Webサーバー群）を複数の環境やプロジェクトで簡単に再利用できます。

✔ 抽象化とカプセル化: 複雑なインフラの詳細をモジュール内部に隠蔽し、利用者はシンプルなインターフェースでインフラをプロビジョニングできます。

✔ 標準化: 組織内で推奨されるインフラ構成パターンをモジュールとして提供することで、一貫したインフラデプロイを促進します。

✔ 保守性の向上: インフラ構成の変更が必要な場合、影響範囲をモジュール内に限定しやすくなります。

モジュールの作成と利用

モジュールは、専用のディレクトリにTerraform設定ファイルを配置することで作成します。例えば、AWSのVPCを構築するモジュールを考えてみましょう。

コード解説

以下は、VPCと複数のサブネットをプロビジョニングするシンプルなAWS VPCモジュールの構造と、そのメインファイルmain.tfの内容です。


# modules/vpc/main.tf
resource "aws_vpc" "this" {
  cidr_block = var.vpc_cidr
  tags = {
    Name = var.name
  }
}

resource "aws_subnet" "public" {
  count             = length(var.public_subnets)
  vpc_id            = aws_vpc.this.id
  cidr_block        = var.public_subnets[count.index]
  availability_zone = "${var.region}${element(var.azs, count.index)}"
  tags = {
    Name = "${var.name}-public-subnet-${element(var.azs, count.index)}"
  }
}

# modules/vpc/variables.tf
variable "name" {
  description = "Name of the VPC"
  type        = string
}

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
  type        = string
}

variable "public_subnets" {
  description = "List of public subnet CIDR blocks"
  type        = list(string)
}

variable "region" {
  description = "AWS region"
  type        = string
}

variable "azs" {
  description = "List of availability zones"
  type        = list(string)
  default     = ["a", "b", "c"]
}

# modules/vpc/outputs.tf
output "vpc_id" {
  description = "The ID of the VPC"
  value       = aws_vpc.this.id
}

output "public_subnet_ids" {
  description = "IDs of the public subnets"
  value       = aws_subnet.public[*].id
}

このモジュールは、ルート構成から以下のように呼び出すことができます。

コード解説

作成したVPCモジュールをルート構成から呼び出し、必要な変数を渡す例です。これにより、シンプルなコードで複雑なVPC構成をデプロイできます。


# root/main.tf
module "my_vpc" {
  source = "./modules/vpc" # ローカルパス指定
  
  name           = "production-vpc"
  vpc_cidr       = "10.100.0.0/16"
  public_subnets = ["10.100.1.0/24", "10.100.2.0/24"]
  region         = "ap-northeast-1"
  azs            = ["a", "c"] # 利用するAZを指定
}

output "prod_vpc_id" {
  value = module.my_vpc.vpc_id
}

モジュールはローカルパスだけでなく、Terraform Registry、GitHubリポジトリ、S3バケットなど、様々なソースから取得できます。組織内で共通のモジュールを開発し、共有することで、全体的なインフラ構築の効率と品質を向上させることが可能です。

ポイント

モジュールは小さく、単一の責任を持つように設計するのがベストプラクティスです。例えば、「VPCモジュール」と「EC2インスタンスモジュール」を分けるなど、機能ごとに分割しましょう。

STATE MANAGEMENT

Terraformの状態管理とチーム開発

Terraformは、プロビジョニングされたインフラの状態を管理するために「Terraform State」という仕組みを使用します。これは、Terraformがクラウド上にデプロイしたリソースのメタデータを記録したファイルであり、Terraformが現在のインフラの状態を把握し、次に行うべき変更を計画するために不可欠です。

Terraform Stateの重要性

Stateファイルは、以下の点で非常に重要です。

リソースのマッピング: Terraformコードで定義された論理的なリソースと、実際のクラウドプロバイダ上の物理的なリソースを紐付けます。
パフォーマンス最適化: 毎回クラウドAPIを問い合わせる代わりに、Stateファイルから情報を取得することで、terraform planなどの実行速度を向上させます。
依存関係の管理: リソース間の依存関係を追跡し、適切な順序でリソースを作成・更新・削除できるようにします。

Stateファイルには、機密情報が含まれる可能性があるため、厳重に管理する必要があります。

注意

Terraform Stateファイルには、データベースのパスワードやAPIキーなどの機密情報が平文で保存されることがあります。そのため、アクセス制限を厳格に行い、暗号化されたストレージに保存することが必須です。

リモートバックエンドとState Lock

チーム開発環境では、ローカルにStateファイルを保存するのではなく、リモートバックエンドに保存することが推奨されます。これにより、チームメンバー間でStateファイルを共有し、一貫したインフラ管理が可能になります。

主要なリモートバックエンド

AWS S3 — 高い可用性と耐久性を提供し、バージョン管理や暗号化もサポートします。DynamoDBと組み合わせることでState Lockも実現できます。

GCP Cloud Storage — S3と同様に、高い信頼性とセキュリティを提供します。State LockにはCloud Storageのオブジェクトロック機能が利用できます。

Azure Blob Storage — Azure環境でのState管理に最適です。リースの仕組みを利用してState Lockを実現します。

Terraform Cloud/Enterprise — HashiCorpが提供するマネージドサービスで、State管理、リモート実行、ポリシー適用などを一元的に管理できます。

リモートバックエンドを設定する際には、同時に「State Lock」を有効にすることが非常に重要です。State Lockは、複数のユーザーが同時にStateファイルを更新しようとするのを防ぎ、Stateファイルの破損や競合状態を防ぎます。

コード解説

AWS S3をリモートバックエンドとして設定し、DynamoDBでState Lockを有効にする例です。S3バケットとDynamoDBテーブルは事前に作成しておく必要があります。


# backend.tf
terraform {
  backend "s3" {
    bucket         = "kwonteki-terraform-state-2026" # S3バケット名
    key            = "dev/my-app/terraform.tfstate"   # Stateファイルパス
    region         = "ap-northeast-1"
    encrypt        = true                             # 暗号化を有効化
    dynamodb_table = "kwonteki-terraform-locks"       # DynamoDBテーブル名（State Lock用）
  }
}

この設定を適用するには、terraform initコマンドを実行します。これにより、TerraformはStateファイルを指定されたS3バケットに保存し、DynamoDBテーブルを使ってロックを管理するようになります。

ポイント

リモートバックエンドとState Lockは、チームでTerraformを運用する際の基盤となる機能です。必ず設定し、安全な運用体制を確立しましょう。

AUTOMATION

CI/CDパイプラインへのTerraform統合

Terraformの真価は、CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインに統合することで最大限に発揮されます。CI/CDと組み合わせることで、インフラの変更を自動化し、デプロイプロセスを効率化し、信頼性を向上させることができます。

CI/CD統合のメリット

TerraformをCI/CDに組み込むことで、以下のメリットが得られます。

CI/CD統合の主要メリット

✔ 自動化されたデプロイ: コード変更がプッシュされると自動的にインフラが更新され、手動での介入を最小限に抑えます。

✔ 一貫性の確保: すべてのデプロイがパイプラインを通じて行われるため、環境間の一貫性が保たれます。

✔ エラーの早期発見: terraform validateやterraform planを自動実行することで、デプロイ前の問題を早期に検出できます。

✔ 承認プロセスの組み込み: terraform applyの実行前に手動承認ステップを設けることで、変更のリスクを管理できます。

一般的なCI/CDパイプラインのステップ

TerraformをCI/CDパイプラインに統合する際の典型的なステップは以下の通りです。

1 コードの変更とプッシュ

開発者がTerraformコードを変更し、Gitリポジトリにプッシュします。プルリクエスト（PR）を作成するのが一般的です。

2 検証とフォーマット

CIツールが自動的に`terraform validate`で構文チェック、`terraform fmt -check`でコードフォーマットのチェックを行います。

3 プランの生成とレビュー

CIツールが`terraform plan`を実行し、適用される変更内容を生成します。このプランはPRコメントとして表示され、チームメンバーがレビューします。

4 承認と適用

コードレビューとプランの承認後、CI/CDパイプラインが`terraform apply`を実行し、インフラに変更を適用します。多くの場合、本番環境への適用には手動承認ステップが設けられます。

GitHub Actionsを用いたシンプルなパイプラインの例を見てみましょう。

コード解説

GitHub ActionsでTerraformのvalidate、plan、applyを実行するワークフローの例です。AWS認証は環境変数で行っています。


# .github/workflows/terraform.yml
name: Terraform CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  terraform:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      AWS_REGION: "ap-northeast-1"

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.x.x # 最新の安定バージョンを指定

      - name: Terraform Init
        id: init
        run: terraform init

      - name: Terraform Validate
        id: validate
        run: terraform validate

      - name: Terraform Plan
        id: plan
        if: github.event_name == 'pull_request'
        run: terraform plan -no-color
        continue-on-error: true # plan失敗しても次のステップへ

      - name: Update Pull Request
        uses: actions/github-script@v6
        if: github.event_name == 'pull_request'
        with:
          script: |
            const output = `#### Terraform Plan 📝
            \`\`\`terraform
            ${process.env.PLAN_OUTPUT}
            \`\`\`
            `;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })
          env:
            PLAN_OUTPUT: ${{ steps.plan.outputs.stdout }}

      - name: Terraform Apply
        if: github.event_name == 'push' && github.ref == 'refs/heads/main'
        run: terraform apply -auto-approve

このワークフローでは、プルリクエスト時にterraform planを実行し、その結果をPRコメントとして表示します。メインブランチへのプッシュ時には、terraform apply -auto-approveで自動的に変更を適用します。本番環境などでは、-auto-approveは推奨されず、手動承認ステップを挟むべきです。

ポイント

CI/CDパイプラインにTerraformを統合することで、インフラのデプロイを標準化し、人的ミスを削減し、変更のトレーサビリティを向上させることができます。

CHALLENGES & SOLUTIONS

Terraform実践における一般的な課題と解決策

Terraformは非常に強力なツールですが、大規模な環境や複雑なチーム体制で運用する際には、いくつかの課題に直面することがあります。ここでは、代表的な課題とその解決策について解説します。

問題 01

インフラドリフト (Infrastructure Drift) の発生

インフラドリフトとは、TerraformのStateファイルやコードで定義されたインフラの状態と、実際のクラウド環境のインフラの状態が乖離してしまう現象です。手動での変更や、Terraform以外のツールによる変更が原因で発生します。

解決策 — ドリフトの検知と修正、予防策

定期的なterraform planの実行: CI/CDパイプラインに定期的なterraform planの実行を組み込み、ドリフトを早期に検知します。
terraform applyによる修正: ドリフトが検知された場合、terraform applyを実行してコードの状態にインフラを戻します。
手動変更の禁止: インフラへの手動変更を厳しく禁止し、すべての変更をTerraform経由で行うポリシーを徹底します。
Terraform Cloud/Enterpriseの利用: これらのサービスはドリフト検知機能を内蔵しており、より高度な管理が可能です。

問題 02

複数環境（開発、ステージング、本番）の管理

開発、ステージング、本番といった複数の環境でインフラを管理する場合、それぞれの環境で異なる設定（インスタンスタイプ、データベースサイズなど）をどう扱うかが課題となります。

解決策 — 環境ごとのディレクトリと変数の活用

環境ごとのディレクトリ構造: 各環境（env/dev, env/stg, env/prod）にTerraform設定ファイルを配置し、それぞれ独立したStateファイルを管理します。
.tfvarsファイルの利用: 環境ごとに異なる変数をterraform.tfvars

Terraform実践入門 2026: クラウドインフラをコードで管理するIaC戦略

目次

はじめに: なぜ今、Terraformなのか？

Terraformの基本概念とIaCの原則

IaC（Infrastructure as Code）のメリット

Terraformの核心要素

Terraformの基本要素

主要クラウドプロバイダにおけるTerraform実践

AWS (Amazon Web Services) でのTerraform

GCP (Google Cloud Platform) でのTerraform

Azure (Microsoft Azure) でのTerraform

効果的なTerraformモジュール設計とベストプラクティス

モジュールを使う理由

モジュールの作成と利用

Terraformの状態管理とチーム開発

Terraform Stateの重要性

リモートバックエンドとState Lock

主要なリモートバックエンド

CI/CDパイプラインへのTerraform統合

CI/CD統合のメリット

一般的なCI/CDパイプラインのステップ

開発者がTerraformコードを変更し、Gitリポジトリにプッシュします。プルリクエスト（PR）を作成するのが一般的です。

CIツールが自動的にterraform validateで構文チェック、terraform fmt -checkでコードフォーマットのチェックを行います。

CIツールがterraform planを実行し、適用される変更内容を生成します。このプランはPRコメントとして表示され、チームメンバーがレビューします。

コードレビューとプランの承認後、CI/CDパイプラインがterraform applyを実行し、インフラに変更を適用します。多くの場合、本番環境への適用には手動承認ステップが設けられます。

Terraform実践における一般的な課題と解決策

インフラドリフト (Infrastructure Drift) の発生

複数環境（開発、ステージング、本番）の管理

CIツールが自動的に`terraform validate`で構文チェック、`terraform fmt -check`でコードフォーマットのチェックを行います。

CIツールが`terraform plan`を実行し、適用される変更内容を生成します。このプランはPRコメントとして表示され、チームメンバーがレビューします。

コードレビューとプランの承認後、CI/CDパイプラインが`terraform apply`を実行し、インフラに変更を適用します。多くの場合、本番環境への適用には手動承認ステップが設けられます。