AWS CDK入門：デプロイされる仕組みと基本構成の要点を整理してみた

はじめに

AWS CDK（AWS Cloud Development Kit）の入門時に押さえたい仕組みと基本構成を整理しました。コードや合成結果は TypeScript で確認しています。

本記事は、CloudFormation やマネジメントコンソールの操作経験があり、これから CDK を本格的に使いたい方や、App・Stage・Stack・Construct といった基本要素の役割分担、および書いたコードが実際にデプロイされる仕組みへの理解を深めたい方に向けた内容です。また、L2 Construct では手が届かない設定に直面したとき、どの手段を選択すべきか迷っている方にも役立つ構成を目指しています。

今回は、AWS Black Belt の CDK シリーズ 3 本を軸に公式の Developer Guide^[1]で現在の仕様を確認しながら、「コードがリソースになるまでの流れ」「基本要素の役割と違い」「L2 で書けない設定の補い方」の 3 つに焦点を当ててまとめました。

1. AWS CDK とは

AWS CDK は、使い慣れたプログラミング言語でクラウドインフラを定義し、AWS CloudFormation を通じてプロビジョニングするオープンソースのフレームワークです^[1:1]。TypeScript、JavaScript、Python、Java、C#（.NET）、Go に対応しています。単一の TypeScript コードベースから、jsii（TypeScript コードから Python や Java などの他言語向けパッケージを自動生成するツール）を用いて各言語向けパッケージが生成されています。

1-1. IaC としての CDK

Infrastructure as Code（IaC）は、手動操作ではなくコードでインフラを管理・構築（プロビジョニング）する手法です。リソースの作成手順を順に書くのではなく、「あるべき状態」を宣言すると、実際の適用は CloudFormation が引き受けます。

手動操作や手続き型スクリプトには、次のような課題があります。

• 現在の状態が把握できず、安全にリリースしづらい
• 人による解釈の違いや操作ミスが起こりやすい
• 同じ環境の再作成や複製に手間がかかる
• 手順書が実環境とかい離してブラックボックス化しやすい
• エラー時のロールバックや状態分岐の網羅が難しい

CDK を使うことで、これらをコードとして体系的に管理・再現できるようになります。

1-2. CloudFormation との関係

CDK は CloudFormation を置き換えるものではなく、CloudFormation の上位レイヤーとして動作します。両者の主な違いは次のとおりです（※App はアプリケーション全体、Stage は環境ごとのまとまり、Stack はデプロイ単位、Construct はリソースの部品を指します。詳細は第 3 章で整理します）。

CloudFormation も単一テンプレート内の依存関係は自動解決します。CDK の利点は、独立した複数の Stack を 1 つの App として束ねて扱える点です^[2]。

一方で、CloudFormation のクォータや制約（リソース数上限など）はそのまま CDK にも適用されます。

1-3. CDK を構成する 2 つの主要部分

AWS 公式ドキュメントでは、AWS CDK は大きく次の 2 つの主要部分で構成されると説明されています^[1:2]。

実際に扱う npm パッケージとの対応は次のとおりです。

Python などの他言語で書く場合でも Node.js が必要なのは、CDK CLI が Node.js 上で動くことに加え、どの言語から使っても jsii を介して Node.js 上で動く共通のバックエンドを利用するためです^[1:3]。

aws-cdk-lib と constructs を両方 import するのも、Construct の基底機能（部品の階層構造やスコープ管理の共通モデル）が constructs にあり、AWS リソース固有の実装が aws-cdk-lib に分かれているためです^[3]。

2. AWS CDK がデプロイされるまで

CDK のコードが直接 AWS に送信・適用されるわけではなく、テンプレートやアセットへの変換を経て適用されます。

処理は大きく 2 つの段階に分かれます。

1. CDK App の処理: コードを実行して、リソースの部品（Construct。詳細は第 3 章で解説）を階層的に組み合わせた Construct ツリー を構築し、CloudFormation テンプレートやデプロイ用ファイル一式（Cloud Assembly）へ変換（合成 / Synthesis、app.synth()）します。
2. CDK CLI の処理: 生成された Cloud Assembly をもとに、Lambda コードやコンテナイメージなどの Asset（アセット: デプロイに必要なソースコードやファイル一式）を S3/ECR へ直接アップロードし、CloudFormation 経由でリソースをデプロイします^[1:4]。

2-1. 4 つのフェーズと実行順序

CDK App の実行は、内部で 4 つのフェーズに分かれています^[1:5]。

例えば「API Gateway にメソッドが 1 つも含まれていない場合のエラー判定」などは、コンストラクタ実行後の Validation フェーズで行われます。

ユーザーコードの実行と Synthesis が完了して CDK App プロセスが終了した後に、CloudFormation と Asset のデプロイが始まります^[1:6]。この順序から、次の 2 つの制約が生じます。

1. デプロイ時に決まる値（作成後の ARN や動的な名前など）は、コード実行時点では確定していません。この場合は、デプロイ時に CloudFormation の組み込み関数（Ref や Fn::GetAtt）へ自動変換される Token（プレースホルダー）という仕組みで扱います（本記事では深く扱いませんが、CDK が裏側で自動管理します）。
2. デプロイの途中に任意の処理を挟めません。処理を挟む場合は、カスタムリソースや Triggers（詳細は第 5-3 章で解説）を使います。

2-2. CDK App と CDK Toolkit は別プロセス

CDK App と CDK Toolkit（CLI）は同一プロセスではなく、疎結合に動作します。

Toolkit は CDK App を外部コマンドとして実行し、必要な情報を App に渡します。デプロイ先のアカウントとリージョンは CDK_DEFAULT_ACCOUNT / CDK_DEFAULT_REGION などの環境変数で指定されます。合成時に参照する Context（既存 VPC 情報や feature flag などのキーと値の組）は、cdk.json や cdk.context.json、--context オプションなどから渡します^[4]。

例えば、既存の VPC 情報を AWS 環境から取得して参照する Vpc.fromLookup() で未解決の Context 値がある場合、Toolkit は AWS アカウントから値を取得して cdk.context.json に保存した上で、CDK App をもう一度実行します^[4:1]。

2-3. cdk.out に出力されるもの

cdk synth を実行すると、cdk.out ディレクトリに Cloud Assembly（テンプレートやアセットの出力一式）が出力されます。以下は S3 バケットと Lambda 関数を含むスタックを合成した例です。

cdk.out/
├── CdkSampleStack.assets.json      # アセットのアップロード先指示
├── CdkSampleStack.metadata.json
├── CdkSampleStack.template.json    # CloudFormation テンプレート
├── asset.fa599e7e.../              # Lambda のコード（zip 前）
├── cdk.out                         # Cloud Assembly の形式情報
├── manifest.json                   # Toolkit へのデプロイ指示
├── tree.json                       # Construct ツリーの全体像
└── validation-report.json          # 検証結果のレポート

テンプレートだけでなく、Lambda 関数のコードもここに出力されます。CDK CLI は assets.json に書かれた指示に従い、テンプレートを経由せずに S3 や ECR へアセットを直接アップロードします。

validation-report.json は、テンプレートの検証結果をまとめたレポートです。現行版では特別な設定をしなくても出力されます^[5]。

3. AWS CDK を構成する基本要素

CDK のコードは、次の要素でツリー構造を組み立てます。

App や Stack も Construct を継承したクラスです。すべて同じツリー構造の中で、役割の異なるノードとして階層を構成します。

3-1. Construct の典型的な初期化パターン

AWS Construct Library のリソース Construct は、scope、id、props という共通の引数パターンに従います^[3:1]。

new dynamodb.Table(this, "MyTable", {
  partitionKey: { name: "pk", type: dynamodb.AttributeType.STRING },
  billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
});

scope に親ノードを渡すことで階層ツリーが形成されます（通常は this を渡し、別の場所を指定することは非推奨です^[1:7]）。
なお、ツリーのルートとなる App だけは例外で、scope と id を取らずに初期化します^[3:2]。

3-2. Construct ID が論理 ID になるまで

Construct ID は単なる識別名ではなく、CloudFormation の論理 ID（テンプレート内で各リソースを一意に識別するための名前）の材料です。

論理 ID は、ツリーのルートから対象リソースまでのパスをもとに自動生成されます^[6]。そのため、Construct ID の変更だけでなく、階層構造（配置スコープ）を変えただけでも論理 ID が変化する場合があります。一方で、Default などのパス要素には、リファクタリング後も論理 ID を維持するための例外ルールが用意されています^[6:1]。

通常の cdk deploy で論理 ID が変わると、CloudFormation は旧リソースと新リソースを別のリソースとして扱い、置換（旧リソースの削除と新リソースの作成）になる可能性があります。データベース等のステートフルなリソース（状態やデータを保持するリソース）ではデータ損失の危険があるため、リファクタリング時は事前に cdk diff（デプロイ前の変更差分を確認するコマンド）で論理 ID の差分を確認してください。なお、現在はプレビューの cdk refactor --unstable=refactor を使い、リソースを保持したまま論理 ID を変更する方法もあります。ただし、コードとデプロイ済みの状態でリソースの集合が同一であることが前提で、リソースの追加・削除・プロパティ変更が含まれていると refactor はエラーで拒否されます。refactor と通常の変更は別々に実施してください^[6:2]。

なお、パスが影響するのは論理 ID であり、リソースの物理名（AWS 上で実際に作成される S3 バケット名や DynamoDB テーブル名などの実名）はプロパティで明示できます（未指定時はデプロイ時に自動生成されます^[3:3]）。

3-3. Stage の落とし穴

Stage を使うと、複数の Stack をまとめた環境一式（Dev、Prod など）を丸ごと複製できます^[1:8]。

ただし、CLI でデプロイする際に落とし穴があります。

# Stage 配下のスタックは --all の対象にならない
cdk deploy --all

# Stage 配下も含めてすべてデプロイする
cdk deploy '**'

# 特定の Stage 配下をすべてデプロイする
cdk deploy 'Dev/**'

cdk deploy --all はトップレベルのスタックだけを対象とするため、Stage 配下のスタックは検出されません。'**'（階層全体）や 'Dev/**'（特定 Stage 配下すべて）のようにパターンで指定する必要があります。'Dev/*' でも Stage 直下のスタックは指定できますが、Stage を入れ子にしている場合は ** の方が確実です^[1:9]。

3-4. Environment を省略するとどうなるか

Stack の env（アカウント・リージョン）が決まらない場合、そのスタックは environment-agnostic（環境非依存） として扱われます。Stage の env は配下の Stack のデフォルト値として使われるため、Stack 側にも親の Stage 側にもアカウントやリージョンの指定がないときに environment-agnostic になります^[7]。

cdk init（新規プロジェクトのひな型を作成するコマンド）が生成するコードのコメントにもその特性が示されています。

const app = new cdk.App();
new CdkInitDemoStack(app, 'CdkInitDemoStack', {
  /* If you don't specify 'env', this stack will be environment-agnostic.
   * Account/Region-dependent features and context lookups will not work,
   * but a single synthesized template can be deployed anywhere. */

  // env: { account: process.env.CDK_DEFAULT_ACCOUNT, region: process.env.CDK_DEFAULT_REGION },
});

environment-agnostic スタックは合成された 1 つのテンプレートをどこにでもデプロイできる反面、合成時に環境情報が必要な処理（Vpc.fromLookup() やリージョン判定による条件分岐など）が利用できません^[3:4]。

本番環境などでデプロイ先を固定する場合は、具体的なアカウントとリージョンを env に指定します。

4. Construct の L1・L2・L3

Construct には抽象化のレベルが 3 段階あります。上位レベルほど記述量が減り、下位レベルほど細かく制御できます^[3:5]。

L2 が直接対応する主な対象は、L1 と同様に単一のリソースです。ただし、必要に応じて IAM ポリシーやロググループなどの補助リソースを自動生成します。一方の L3 は、複数リソースを用途に合わせて組み合わせたアーキテクチャパターンです^[3:6]。

4-1. 抽象化で何が減るのか

「IAM ユーザーからの読み取り専用アクセスを許可する S3 バケット」を L1 と L2 で比較してみます。

L1 では、IAM ポリシーのドキュメントとステートメントを自分で組み立てる必要があります。

const bucket = new s3.CfnBucket(this, "MyBucket");
const user = new iam.CfnUser(this, "MyUser");
new iam.CfnPolicy(this, "MyUserPolicy", {
  policyName: "MyUserPolicy",
  policyDocument: new iam.PolicyDocument({
    statements: [
      new iam.PolicyStatement({
        actions: ["s3:GetObject*", "s3:GetBucket*", "s3:List*"],
        resources: [bucket.attrArn, `${bucket.attrArn}/*`],
      }),
    ],
  }),
  users: [user.ref],
});

L2 ならわずか 3 行です。

const bucket = new s3.Bucket(this, "MyBucket");
const user = new iam.User(this, "MyUser");
bucket.grants.read(user);

行数が減っただけでなく、grants.read（アクセス権限を直感的に付与するヘルパー機能）のようにコードから設計意図が直接読み取れるようになります。

なお、デフォルト設定では、両者を合成した CloudFormation リソース数はどちらも同じ 4 個（Bucket / User / Policy + CDK メタデータ）です。抽象化が減らすのはリソースの数ではなく、コードの記述量と調べる手間です。

4-2. コードの行数とリソース数は一致しない

抽象化が進む反面、コード行数から生成されるリソース数を見積もることは難しくなります。次の例では、cdk init で作成したプロジェクトなど、CDK が Lambda の Log Group を管理し、CDK の使用状況レポートも有効な環境では、合成後に 7 個の CloudFormation リソースが生成されます^[8]。

const bucket = new s3.Bucket(this, 'DataBucket', { enforceSSL: true });

const fn = new lambda.Function(this, 'Handler', {
  runtime: lambda.Runtime.NODEJS_22_X,
  handler: 'index.handler',
  code: lambda.Code.fromAsset('lambda'),
  environment: { BUCKET_NAME: bucket.bucketName },
});

bucket.grants.read(fn);

生成されたリソースの内訳：

DataBucketE3889A50                    -> AWS::S3::Bucket
DataBucketPolicy3231C704              -> AWS::S3::BucketPolicy
HandlerServiceRoleFCDC14AE            -> AWS::IAM::Role
HandlerServiceRoleDefaultPolicyCBD0CC91 -> AWS::IAM::Policy
Handler886CB40B                       -> AWS::Lambda::Function
HandlerLogGroup50A7B41D               -> AWS::Logs::LogGroup
CDKMetadata                           -> AWS::CDK::Metadata

enforceSSL: true によるバケットポリシーや、Lambda の実行ロール・Log Group が自動生成されています^[8:1]。ただし、Lambda の logGroup や logRetention を指定しておらず、かつ CDK 管理の Log Group 用 feature flag（CDK の動作仕様を切り替える設定フラグ）が無効な環境では、Log Group は Lambda サービスが初回実行時に作成します。そのため、テンプレートに HandlerLogGroup は含まれません。CDKMetadata の有無も使用状況レポートの設定によって変わります。

4-3. L1 を使うときの注意点

L2 で提供されていない機能には L1 を利用します。主な注意点は次の 2 点です^[3:7]。

1. 型は各 L1 の内部クラス: 例えば CfnBucket の CORS 設定には CfnBucket.CorsConfigurationProperty を渡す必要があり、名前が同じでも他リソースの型は使えません。
2. 仕様反映のタイムラグ: L1 は CloudFormation 仕様から自動生成されるため、新機能の反映まで最大 1 週間ほどかかる場合があります。

なお、安定版の L2/L3 は aws-cdk-lib に含まれますが、開発中の実験的な機能は -alpha が付いたモジュール（例: @aws-cdk/aws-bedrock-alpha など）で提供されます^[3:8]。

4-4. 自分の Construct を作る

Construct は独自に定義して再利用できます^[3:9]。例えば API Gateway、Lambda 関数、DynamoDB テーブルを組み合わせた Web API パターンを作成できます。

export interface WebApiProps {
  readonly entry: string;
}

export class WebApi extends Construct {
  public readonly api: apigateway.LambdaRestApi;

  constructor(scope: Construct, id: string, props: WebApiProps) {
    super(scope, id);

    const table = new dynamodb.Table(this, "Table", {
      partitionKey: { name: "pk", type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
    });

    const handler = new nodejs.NodejsFunction(this, "Handler", {
      entry: props.entry,
      environment: { TABLE_NAME: table.tableName },
    });
    table.grants.readWriteData(handler);

    this.api = new apigateway.LambdaRestApi(this, "Api", { handler });
  }
}

利用側は数行で同じ構成を呼び出せます。

new WebApi(this, "UserApi", { entry: "lambda/user.ts" });
new WebApi(this, "OrderApi", { entry: "lambda/order.ts" });

5. L2 で書けない設定を扱う

L2 Construct でサポートされていない設定が必要な場合、対応する範囲に応じて手段を選びます。次の図は一本道の優先順位ではなく、公式ドキュメント^[10] に沿った判断の目安です。

5-1. Mixins と Facades

Mixins は .with() メソッドで共通の設定や機能を後付けする仕組みで、L1 にも L2 にも使えます^[3:10]。Facades は権限付与やメトリクスなどの複雑な設定を扱いやすいメソッドにまとめたクラスで、代表格が Grants です^[10:1]。

const raw = new s3.CfnBucket(this, "RawBucket");
raw.with(new s3.mixins.BucketVersioning());
raw.with(new s3.mixins.BucketBlockPublicAccess());

const role = new iam.Role(this, "MyRole", {
  assumedBy: new iam.ServicePrincipal("lambda.amazonaws.com"),
});
s3.BucketGrants.fromBucket(raw).read(role);

上記のように、L1 のままでも L2 相当の設定と権限を付与できます。

"RawBucket": {
  "Type": "AWS::S3::Bucket",
  "Properties": {
    "PublicAccessBlockConfiguration": {
      "BlockPublicAcls": true, "BlockPublicPolicy": true,
      "IgnorePublicAcls": true, "RestrictPublicBuckets": true
    },
    "VersioningConfiguration": { "Status": "Enabled" }
  }
}

S3 の Mixins には BucketVersioning や BucketBlockPublicAccess などが用意されており、L1 を使う場合でも安全な設定を簡潔に追加できます。

5-2. エスケープハッチと raw override

Mixins や Facades で対応できない場合は、L2 Construct の内側にある L1（node.defaultChild）を取り出して直接設定します（上位の抽象化を抜けて下位設定を直接触るエスケープハッチ）^[10:2]。

例えば S3 ストレージクラス分析の設定は、L2 の BucketProps にはありませんが、L1 の CfnBucket には型付きプロパティが存在します^[8:3]。

const bucket = new s3.Bucket(this, "DataBucket");
const cfnBucket = bucket.node.defaultChild as s3.CfnBucket;
cfnBucket.analyticsConfigurations = [
  {
    id: "EntireBucket",
    storageClassAnalysis: {},
  },
];

合成結果：

"DataBucketE3889A50": {
  "Type": "AWS::S3::Bucket",
  "UpdateReplacePolicy": "Retain",
  "DeletionPolicy": "Retain",
  "Properties": {
    "AnalyticsConfigurations": [
      {
        "Id": "EntireBucket",
        "StorageClassAnalysis": {}
      }
    ]
  }
}

対応する CfnXxx クラスがまだないものの、CloudFormation のリソースタイプが存在する場合は、cdk.CfnResource（CloudFormation リソースを汎用的に定義するクラス）でリソースタイプとプロパティを直接指定できます^[10:4]。CloudFormation 自体がその機能に対応していない場合は、CfnResource ではなくカスタムリソースを検討します。

5-3. デプロイ中に処理を挟む

CDK App のコードはデプロイ前に終了するため、デプロイ中に処理を実行したい場合は CloudFormation カスタムリソース（デプロイ処理中に Lambda 関数などを呼び出して独自処理を実行させる仕組み）を利用します。

AwsCustomResource: Lambda を自作せず、単純な AWS SDK 呼び出し（パラメータ取得など）を行う Construct です^[11]。

const parameterArn = cdk.Stack.of(this).formatArn({
  service: "ssm",
  resource: "parameter",
  resourceName: "sample/config",
  arnFormat: cdk.ArnFormat.SLASH_RESOURCE_NAME,
});

new cr.AwsCustomResource(this, "GetParameter", {
  resourceType: "Custom::SSMParameterLookup",
  onUpdate: {
    service: "SSM",
    action: "GetParameter",
    parameters: { Name: "/sample/config" },
    physicalResourceId: cr.PhysicalResourceId.of("GetSampleParameter"),
    outputPaths: ["Parameter.Name"],
    logging: cr.Logging.withDataHidden(),
  },
  policy: cr.AwsCustomResourcePolicy.fromSdkCalls({
    resources: [parameterArn],
  }),
});

実行ロールの権限は必要最小限に絞り、ログへの応答出力は Logging.withDataHidden() で保護します。なお、秘密情報の取得には Secrets Manager や SecretValue.ssmSecure() を利用してください^[11:1]。

Provider Framework: 任意の言語でカスタムリソースのハンドラー（処理本体）を実装したい場合に利用するフレームワークです。ライフサイクルのルーティングや失敗応答、非同期ポーリング（最大 1 時間）を担います^[11:2]。

Triggers: CloudFormation のデプロイ中に Lambda 関数を実行する仕組みです。デフォルトでは Trigger の Lambda 関数がプロビジョニングされた後に実行され、executeAfter() や executeBefore() で他のリソースとの実行順序を指定できます。ハンドラーのコードまたは設定が変更されるたびに再実行されるのが既定の動作です。executeOnHandlerChange: false を指定すると、初回デプロイ時のみ実行されます。初期データの投入やリソースの疎通確認に適しています^[12]。

const myTrigger = new triggers.TriggerFunction(this, "MyTrigger", {
  runtime: lambda.Runtime.NODEJS_22_X,
  handler: "index.handler",
  code: lambda.Code.fromAsset("my-trigger"),
});

5-4. L2 が抽象化しているその他の機能

grants 以外にも、L2 には定型処理を簡潔に書くためのメソッドが備わっています。

metric: CloudWatch メトリクスの取得やアラーム作成を行うヘルパーで、メトリクス名を意識せず直感的に作成できます。

alb.metrics
  .httpCodeElb(elbv2.HttpCodeElb.ELB_5XX_COUNT, {
    period: cdk.Duration.minutes(1),
    statistic: cw.Stats.SUM,
  })
  .createAlarm(this, "AlbHttp5xx", {
    evaluationPeriods: 3,
    threshold: 10,
    comparisonOperator:
      cw.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
  })
  .addAlarmAction(new cw_actions.SnsAction(props.alarmTopic));

connections: 2 つのリソース間のセキュリティグループ（ネットワーク通信の許可設定）を相互に自動設定します。デフォルトポートが定義されているリソース（ALB や RDS 等）ではポート指定も不要です。

listener.connections.allowDefaultPortFromAnyIpv4("Allow public access");
fleet1.connections.allowToDefaultPort(rdsDatabase, "Fleet can access database");

イベント通知: リソースイベントに対する通知先を直感的に設定（または連携）できます。

bucket.addObjectCreatedNotification(new s3nots.LambdaDestination(handler));
repo.onCommit("CommitToMain", {
  target: new targets.CodeBuildProject(project),
  branches: ["main"],
});

AWS CDK の要点と注意点

AWS CDK の基本構造と Construct の活用法について、押さえておきたい要点は次の 3 つです。

1. CDK App とデプロイの分離: CDK App は Construct ツリーを CloudFormation テンプレート（Cloud Assembly）へ合成する役割を持ち、実際のデプロイは CloudFormation が実行します。
2. ツリー構造と論理 ID: App、Stage、Stack、Construct は同じツリーを構成し、Construct ID や階層構造が論理 ID に直結します（不用意な変更は、通常のデプロイでリソースの置換やデータ損失につながる可能性があります）。
3. 段階的な抽象化の選択: 基本は安全な L2 Construct を使い、L2 でサポートされていない設定には、Mixins/Facades、L1 エスケープハッチ、raw override、CfnResource、カスタムリソースの中から状況に応じて選択します。

本記事が、AWS CDK の基本構造を理解する一助となれば幸いです。

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。

運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました