本記事は 2026 年 8 月 25 日 に公開された「 PythonOperator and BashOperator Now Available on Amazon Managed Workflows for Apache Airflow (Amazon MWAA) Serverless 」を翻訳したものです。翻訳はクラウドサポートエンジニアの山本が担当しました。 Amazon MWAA Serverless で Apache Airflow ワークフロー を実行している場合、PythonOperator と BashOperator を使ってカスタムコードをサーバーレスランタイム上で直接実行できるようになりました。これまで Amazon Managed Workflows for Apache Airflow (Amazon MWAA) Serverless では、オペレーター経由で AWS サービスをオーケストレーションし、タスクのスケジューリング、依存関係の管理、リトライ処理を行うことしかできず、独自の Python 関数やシェルスクリプトをネイティブに実行できませんでした。カスタムの Python ロジックやシェルコマンドが必要な場合は、コードを AWS Lambda 関数にラップしたり、Amazon Elastic Container Service (Amazon ECS) タスクを起動したり、ほかの AWS コンピューティングサービスを使う必要がありました。こうした代替手段では、オーケストレーションパイプラインの複雑さ、コスト、レイテンシーが増えます。 今回の機能追加により、インフラストラクチャを追加せずに、サーバーレスタスクランタイム内でカスタムの Python 関数やシェルスクリプトを直接実行できます。つまり、多くのデータエンジニアリングチームが ETL パイプラインやデータ品質チェックで利用している PythonOperator と BashOperator を、コンピューティングリソースを追加でプロビジョニングせずに使えます。 本記事では、新機能の仕組みを解説し、実践的な例を示します。PythonOperator で CSV ファイルを JSON 形式に変換し、BashOperator で出力を検証するサーバーレスパイプラインを構築します。読み終えると、次のことができるようになります。 依存関係を含む Python モジュールをパッケージ化し、コードバンドルとして Amazon Simple Storage Service (Amazon S3) バケットにアップロードする dag-factory 互換の YAML で複数タスクのワークフローを定義する AWS Command Line Interface (AWS CLI) でワークフローを作成して実行する パイプラインが期待どおりの出力を生成したことを検証する 仕組み MWAA Serverless では、カスタムコードをパッケージ化して Amazon S3 バケットにアップロードし、ワークフロー作成時に参照します。サービスはワークフロー作成時点のコードをスナップショットとして取得し、以降は同じワークフローバージョンのすべての実行でそのスナップショットを使います。 コードバンドル コードバンドルは、カスタムロジックを含むパッケージです。Python モジュールやシェルスクリプトをパッケージ化して Amazon S3 バケットにアップロードします。コードバンドルの形式は次のいずれかです。 単一の .py ファイルまたは .sh の bash スクリプト (Amazon S3 バケットにアップロード) 複数のシェルスクリプト、Python モジュール、依存関係を含む ZIP アーカイブ (最大 250 MB) 実行モデル ワークフローを作成または更新すると、MWAA Serverless は指定した Amazon S3 バケットからコードバンドルのスナップショットを取得し、サービス側に保存します。タスク実行時には、Amazon S3 バケットに現在置かれているオブジェクトではなく、このスナップショットを使って隔離されたランタイム環境でコードを実行します。 Python タスクと Bash タスクはインターネットにアクセスできません。到達できるのは、ランタイムの動作に必要な Amazon S3、Amazon Elastic Container Registry (Amazon ECR)、Amazon CloudWatch だけです。インターネットアクセスが必要な場合は、 ワークフローに Amazon VPC を設定 して、その VPC 経由で通信させてください。 サポートされるオペレーター MWAA Serverless で利用できるようになった 2 つのオペレーターは次のとおりです。 オペレーター 説明 PythonOperator コードバンドル内の Python の呼び出し可能オブジェクト (関数) を実行します BashOperator シェルコマンドやスクリプトを実行します セキュリティ コードバンドルは AWS Key Management Service (AWS KMS) で保存時に暗号化されます。ワークフローを作成、更新、トリガーできるユーザーは IAM ポリシーで制御します。実行時にコードがアクセスできる AWS リソースの範囲は実行ロールで決まります。 前提条件 始める前に、次のリソースとツールが AWS アカウントで設定されていることを確認してください。 Amazon MWAA Serverless にアクセスできる AWS アカウント AWS CLI v2 (最新バージョン) のインストールと設定。インストールまたは更新の方法は AWS CLI の最新バージョンのインストールまたは更新 を参照してください。 DAG 定義とコードバンドルを保存する Amazon S3 バケット MWAA Serverless が引き受けられる IAM ロール (実行ロールの設定は後述します) ウォークスルー: サーバーレスの CSV → JSON パイプラインを構築する ※以降の Amazon S3 バケット名 amzn-s3-demo-mwaa-data はサンプルです。ご利用の Amazon S3 バケット名に変更してください。 このウォークスルーでは、CSV ファイルを JSON 形式に変換するパイプラインを構築します。JSON を扱う下流の API や分析システムに向けた、よくあるデータ変換です。変換ロジックには PythonOperator を、出力の検証には BashOperator を使います。パイプラインの処理内容は次のとおりです。 Amazon S3 バケットから CSV ファイルを読み込む 列の型を推論しながら JSON 形式に変換する JSON ファイルを Amazon S3 バケットに書き戻す 変換元と出力でレコード件数が一致することを検証する ステップ 1: 実行ロールを作成する ワークフローが実行時に引き受ける IAM ロールを作成します。信頼ポリシーでは airflow-serverless.amazonaws.com サービスがロールを引き受けられるようにする必要があります。 cat > trust-policy.json << 'EOF' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "airflow-serverless.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF ロールを作成し、S3 バケットへの最小権限アクセスを許可するインラインポリシーをアタッチします。 aws iam create-role \ --role-name MWAAServerlessExecutionRole \ --assume-role-policy-document file://trust-policy.json aws iam put-role-policy \ --role-name MWAAServerlessExecutionRole \ --policy-name MWAAServerlessAccessPolicy \ --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-mwaa-data", "arn:aws:s3:::amzn-s3-demo-mwaa-data/*" ] }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogStreams", "logs:GetLogEvents" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/mwaa-serverless/*" } ] }' ステップ 2: Python モジュールを作成する 変換ロジックを記述した csv_to_json.py というファイルを作成します。 # csv_to_json.py import csv import json import boto3 import io def convert(**kwargs): """Read a CSV from S3 and write it back as JSON lines.""" bucket = "amzn-s3-demo-mwaa-data" source_key = "raw/sales_data.csv" output_key = "processed/sales_data.json" s3 = boto3.client("s3") # Read source file response = s3.get_object(Bucket=bucket, Key=source_key) content = response["Body"].read().decode("utf-8") # Parse CSV reader = csv.DictReader(io.StringIO(content)) rows = list(reader) # Type inference - convert numeric fields for row in rows: for key, value in row.items(): try: row[key] = float(value) except (ValueError, TypeError): pass # Write as JSON lines output = "\n".join(json.dumps(row) for row in rows) + "\n" s3.put_object(Bucket=bucket, Key=output_key, Body=output.encode("utf-8")) print(f"Converted {len(rows)} rows to JSON lines") print(f"Output: s3://amzn-s3-demo-mwaa-data/{output_key}") return {"rows": len(rows), "output_key": output_key} この関数は boto3 (MWAA Serverless の実行環境にプリインストール済み) と Python 標準ライブラリの csv および json モジュールを使います。CSV を読み込んで数値型を推論し、JSON Lines ファイルを S3 バケットに書き戻します。 ステップ 3: 検証スクリプトを作成する verify_output.sh というファイルを作成します。このスクリプトは、変換元 CSV と出力 JSON ファイルのレコード件数を比較してパイプラインの出力を検証します。件数が一致しない場合、タスクは 0 以外の終了コードで失敗し、ワークフローの実行も失敗します。 #!/bin/bash echo "=== Data Validation ===" # Count source records (skip CSV header) SOURCE_COUNT=$(python3 -m awscli s3 cp s3://amzn-s3-demo-mwaa-data/raw/sales_data.csv - | tail -n +2 | wc -l) echo "Source CSV records: $SOURCE_COUNT" # Count output records OUTPUT_COUNT=$(python3 -m awscli s3 cp s3://amzn-s3-demo-mwaa-data/processed/sales_data.json - | wc -l) echo "Output JSON records: $OUTPUT_COUNT" # Validate counts match if [ "$SOURCE_COUNT" -ne "$OUTPUT_COUNT" ]; then echo "FAILED: Record count mismatch (source=$SOURCE_COUNT, output=$OUTPUT_COUNT)" exit 1 fi echo "PASSED: Record counts match ($OUTPUT_COUNT records)" echo "Timestamp: $(date -u +%Y-%m-%dT%H:%M:%SZ)" 検証スクリプトは AWS CLI を実行します。AWS CLI はコードパッケージに依存関係としてバンドルされています。s3 cp はファイルの内容をディスクに書き出さずに stdout へストリーミングするため、 wc -l や tail といった標準的なシェルツールで処理できます。実行ロールの認証情報は実行環境で自動的に利用できるので、追加の設定なしに CLI から S3 にアクセスできます。 ステップ 4: コードをパッケージ化して Amazon S3 にアップロードする 検証スクリプトが AWS CLI を使うため、Python モジュールとシェルスクリプトに加えて、AWS CLI も依存関係として ZIP アーカイブにバンドルします。 BUCKET="amzn-s3-demo-mwaa-data" REGION="us-east-1" # Install awscli into a package directory pip install awscli \ --target my_package/ \ --platform manylinux2014_x86_64 \ --python-version 3.12 \ --only-binary=:all: # Add your module cp csv_to_json.py my_package/ cp verify_output.sh my_package/ # Create the ZIP archive cd my_package && zip -r ../code_bundle.zip . && cd .. # Upload to S3 aws s3 cp code_bundle.zip s3://$BUCKET/code/code_bundle.zip --region $REGION テスト用のサンプル CSV ファイルをアップロードします。 cat > sales_data.csv << 'EOF' date,region,product,units,revenue 2026-07-01,us-east,widget-a,150,4500.00 2026-07-01,eu-west,widget-b,89,2670.00 2026-07-02,us-east,widget-a,203,6090.00 2026-07-02,ap-south,widget-c,67,1340.00 2026-07-03,us-east,widget-b,178,5340.00 EOF aws s3 cp sales_data.csv s3://$BUCKET/raw/sales_data.csv --region $REGION ステップ 5: DAG を定義する (YAML) MWAA Serverless は DAG 定義に宣言的な YAML 形式を使います。 conversion_dag.yaml というファイルを作成します。 csv_to_json_pipeline: start_date: "2026-01-01" schedule: null tasks: convert_to_json: operator: airflow.operators.python.PythonOperator python_callable: csv_to_json.convert verify_output: operator: airflow.operators.bash.BashOperator bash_command: "verify_output.sh" dependencies: - convert_to_json この DAG は 2 つのタスクを定義しています。 convert_to_json – Python モジュールの convert 関数を実行し、CSV を JSON Lines に変換します。 verify_output – シェルスクリプトを実行し、変換元と出力のレコード件数を比較してパイプラインの出力を検証します。一致しない場合はタスクを失敗させます。 DAG 定義を S3 にアップロードします。なお、シェルスクリプトを使わずにインラインの Bash コマンドを直接実行することもできます。 aws s3 cp conversion_dag.yaml s3://$BUCKET/dags/conversion_dag.yaml --region $REGION ステップ 6: ワークフローを作成する DAG 定義とコードバンドルを参照して MWAA Serverless ワークフローを作成します。 ROLE_ARN="arn:aws:iam::<your-account-id>:role/MWAAServerlessExecutionRole" aws mwaa-serverless create-workflow \ --name csv-to-json-workflow \ --definition-s3-location Bucket="$BUCKET",ObjectKey="dags/conversion_dag.yaml" \ --code '{"S3Location": {"Bucket":"'"$BUCKET"'","ObjectKey":"code/code_bundle.zip"}}' \ --role-arn $ROLE_ARN \ --region $REGION レスポンスには、実行をトリガーする際に使う WorkflowArn が含まれます。 { "WorkflowArn": "arn:aws:airflow-serverless:us-east-1:123456789012:workflow/csv-to-json-workflow-abc123", "CreatedAt": "2026-07-15T10:30:00.000000+00:00", "WorkflowVersion": "a1b2c3d4e5f6" } ステップ 7: ワークフローを実行する ワークフローの実行をトリガーします。 WORKFLOW_ARN="arn:aws:airflow-serverless:us-east-1:123456789012:workflow/csv-to-json-workflow-abc123" aws mwaa-serverless start-workflow-run \ --workflow-arn $WORKFLOW_ARN \ --region $REGION レスポンスで実行が開始されたことを確認できます。 { "RunId": "6OZV9ABF9enHKXk", "Status": "STARTING" } ステップ 8: 実行を監視する 実行のステータスを確認します。 RUN_ID="6OZV9ABF9enHKXk" aws mwaa-serverless get-workflow-run \ --workflow-arn $WORKFLOW_ARN \ --run-id $RUN_ID \ --region $REGION 実行が成功すると次のように返ります。 { "RunDetail": { "Duration": 45, "RunState": "SUCCESS", "TaskInstances": ["ex_abc123_convert_to_json_1", "ex_abc123_verify_output_1"] }, "RunId": "6OZV9ABF9enHKXk", "RunType": "ON_DEMAND", "WorkflowArn": "arn:aws:airflow-serverless:us-east-1:123456789012:workflow/csv-to-json-workflow-abc123", "WorkflowVersion": "a1b2c3d4e5f6" } ステップ 9: 出力を検証する JSON ファイルが S3 バケットに書き込まれたことを確認します。 # List the output file aws s3 ls s3://$BUCKET/processed/sales_data.json --region $REGION 次のように JSON ファイルが表示されます。 2026-07-15 10:32:45 1847 sales_data.json タスク単位の出力は Amazon CloudWatch Logs でも確認できます。ワークフローのロググループを開き、 convert_to_json タスクのログストリームを探してください。 Converted 5 rows to JSON lines Output: s3://amzn-s3-demo-mwaa-data/processed/sales_data.json 考慮事項と制限 PythonOperator と BashOperator を使うワークロードを MWAA Serverless で計画する際は、次の点に注意してください。 コードバンドルのサイズ – ZIP アーカイブは 1 バンドルあたり 250 MB 未満にする必要があります。 ネットワークアクセス – Python タスクと Bash タスクはインターネットにアクセスできません。ランタイムの動作に必要な限られた AWS サービス (Amazon S3、Amazon ECR、Amazon CloudWatch) には到達できますが、ほかの AWS サービスや外部エンドポイントは呼び出せません。ワークフローで外部 API の呼び出しが必要な場合は、事前にデータを処理して Amazon S3 バケットに保存し、そのうえでワークフローを実行してください。 ランタイムの依存関係 – boto3 と Python 標準ライブラリはプリインストール済みです。pandas や requests などの追加パッケージは、 Amazon MWAA Serverless のパッケージングガイドライン に従って ZIP アーカイブにバンドルしてください。 実行タイムアウト – タスクはワークフローに設定されたタイムアウト制限に従います。 Python のバージョン – 現在サポートされている Python ランタイムのバージョンは Amazon MWAA Serverless のドキュメント で確認してください。 DAG の形式 – MWAA Serverless は従来の Python の DAG ファイルではなく、YAML ベースの DAG 定義を使います。MWAA Provisioned から移行する場合は、DAG を YAML 形式に変換する必要があります。 サポートされないオペレーター – Airflow コミュニティのオペレーターやカスタムプラグインの一部は Serverless ランタイムでは利用できません。互換性の一覧は ドキュメント を参照してください。 クリーンアップ 継続的な課金を避けるため、本記事のウォークスルーで作成したリソースを削除します。ワークフロー、S3 オブジェクト、IAM ロールは次のコマンドで削除できます。 注: $WORKFLOW_ARN はステップ 7 で定義しています。 # Delete the workflow aws mwaa-serverless delete-workflow \ --workflow-arn $WORKFLOW_ARN \ --region $REGION 注: $BUCKET はステップ 4 でエクスポートしています。必要に応じてバケットも削除してください。 # Remove S3 objects aws s3 rm s3://$BUCKET/code/code_bundle.zip aws s3 rm s3://$BUCKET/dags/conversion_dag.yaml aws s3 rm s3://$BUCKET/raw/sales_data.csv aws s3 rm s3://$BUCKET/processed/sales_data.json # Delete the IAM role aws iam delete-role-policy \ --role-name MWAAServerlessExecutionRole \ --policy-name MWAAServerlessAccessPolicy aws iam delete-role --role-name MWAAServerlessExecutionRole まとめ PythonOperator と BashOperator がネイティブにサポートされたことで、多くのデータエンジニアリングチームが日常的に使っているカスタムコードの実行パターンを、MWAA Serverless で直接使えます。データ変換、形式変換、検証、シェルスクリプトを、コンピューティングリソースの追加プロビジョニングやコンテナの管理なしにサーバーレスランタイムで実行できます。 MWAA Provisioned やセルフマネージドのインフラストラクチャで Airflow ワークロードを実行している場合、既存の PythonOperator と BashOperator のロジックはほとんど変更せずに使えます。Python の DAG ファイルを YAML 形式に変換し、コードをバンドルとしてパッケージ化すれば、MWAA Serverless で実行できます。 まずは Amazon MWAA Serverless のドキュメント を参照し、本記事のウォークスルーを自分のデータで試してください。料金の詳細は Amazon MWAA の料金ページ を参照してください。フィードバックをお待ちしています。 著者について Pradeep Kumar Nalluri AWS のソフトウェア開発エンジニアで、スケーラブルなアプリケーションの設計と開発を専門としています。休日はテレビ番組や映画を観て過ごしています。 Karthik Seshadri AWS のシニアソフトウェア開発エンジニアで、ビッグデータ技術のオーケストレーションを専門としています。サーバーレス技術、データエンジニアリング、スケーラブルなサービスの構築に情熱を注いでいます。仕事以外では、旅行やさまざまなスポーツを楽しんでいます。 Aritra Ghosh Amazon Web Services (AWS) のシニアプロダクトマネージャーで、Amazon Managed Workflows for Apache Airflow (Amazon MWAA) と Amazon SageMaker Unified Studio の製品開発を率いています。仕事以外では、スカッシュとジム通いを楽しんでいます。 Sriram Ramarathnam AWS Analytics で AWS Glue、AWS Data Pipeline、Managed Serverless Airflow を担当するソフトウェア開発マネージャーです。チームでは、サーバーレスとプロビジョンド両方のコンピューティング提供形態にまたがるオーケストレーション領域の難しい課題に取り組んでいます。

製造業のデータ利活用は、AIツールを導入する段階から、事業成長や顧客価値の創出につなげる段階へ移りつつあります。欧米の先進企業では、データを資産として扱うData as a Productの考え方を取り入れながら、生成AIだけでなく、物理世界を動かすフィジカルAIをコア業務や人材育成に組み込んでいます。これを実現する上で注目すべきは、ITなど一つの中央部門に依存せず、データ活用の主導権を各部門に分散して持たせるデータメッシュアプローチです。これらを通じて、データ基盤の再設計と組織変革を同時に推し進めています。 本記事では、Dow、Siemens、Rockwell Automationの取り組みをもとに、製造業のデータ利活用を成果につなげる企業の共通点を整理します。これらの製造業DX事例から見えてくるのは、DXの成否を分けるのは個別技術の導入ではなく、データを事業の勝ち筋に変える仕組みを持てるかどうかです。 製造業のデータ活用は「導入」から「成果」へ移っている 製造業におけるAI活用は、検証や一部業務の効率化にとどまらず、事業成果や競争優位につなげる段階へ移っています。2010年頃から、いわゆるビッグテック企業は世界の時価総額上位を占め、デジタルインフラに近い立ち位置を確立してきました。彼らの培ったテクノロジーとデータを活用してビジネスを最適化するアプローチは、金融や小売だけでなく、素材、電機、産業オートメーションなどの伝統的な製造業にも広がっています。 金融業界が伝統的な産業で先頭を切ってフィンテックやデジタル技術を取り入れて業態を変えていったように、製造業でも、これまでデータ活用と距離があった企業が、AIやデータを中核に据えた変革を進めています。 ただし、AIを導入すれば成果が出るわけではありません。2025年の マッキンゼーのAI導入調査 では、88%の企業がAIを導入している一方で、AIを利益の源泉として活用し、EBIT（利払前・税引前利益）の5%以上をAIで創出している「 AIハイパフォーマー 」は6%にとどまるとされています。 AIハイパフォーマーに見られる特徴は、主に次の3つです。 目的設定 : 単なるコスト削減をゴールとせず、売上成長や新規ビジネスの創出（イノベーション）を目的としている 手段の進化 : 新たな技術を積極的に取り入れ、スケールさせている。例えばAIエージェントは全体の62%が実験を開始する中、ハイパフォーマーは他社の3倍以上の割合でエージェントを実際の業務に組み込み「スケール」させている 組織の変革 : 既存業務にAIを足すのではなく、AIやエージェントの存在を前提としてワークフローや人材、業務を根本から再設計している (ハイパフォーマーは65%が実施、その他は23%) これらの「組織の変革」や「業務の再設計」という特徴は、特に製造業において重要な示唆を持ちます。製造業のデータ活用では、設備、工程、品質、在庫、販売、アフターサービスなど、多様なデータが存在します。だからこそ、個別のAIツール導入ではなく、全社としてデータを扱う体制・仕組み作りが重要になるのです。 データメッシュは現場主導のデータ活用を支える考え方 データメッシュとは、各部門が自部門のデータのオーナーシップと責任を持ち、他部門も再利用できる形で提供する分散型のデータ管理アプローチです。2019年に Zhamak Dehghani (martinfowler.com) が提唱した、シリコンバレーのテック企業でも見られるデータ管理の考え方であり、AI活用のスピードに中央集権型の体制だけでは追いつきにくくなったことを背景に広がっています。製造業でデータ活用を広げるうえでは、現場が必要なデータを必要なタイミングで使える状態を作る考え方として重要です。 従来のデータ活用では、IT部門やDX部門が中央集権的にデータを管理し、各部門からの依頼を受けて分析結果を返す形が一般的でした。この体制はガバナンスを保ちやすい一方で、現場が求めるAI活用のスピードや、日々の意思決定の速度に追いつきにくくなるという課題があります。 現場では、品質、設備、原材料、作業条件、需要、在庫などのデータが業務ごとに分かれて存在します。これらを中央の専門部署だけで分析を行う場合、現場特有の背景やニュアンスが十分に反映されなかったり、分析結果が出るまでに時間がかかったりします。 データメッシュの特徴は、次の4点に整理できます。 ドメイン思考の所有者 : 現場部門が、自部門(ドメイン)のデータに対する管理責任と所有権を持つ プロダクトとしてのデータ : データを一度きりの分析素材ではなく、再利用可能な「プロダクト」として扱う セルフサービス基盤 : 各部門が、中央組織を介さずに必要なデータや分析ツールを利用できる環境を整える 連携型ガバナンス : 中央組織は、データ品質、権限、セキュリティ、標準ルールなど、全体ルールを一元管理する このアプローチは、製造業のデータ活用における「現場を巻き込めない」「データがサイロ化している」「分析が一部の専門家に閉じる」といった課題の解決策になります。 中央でのポリシー管理と、現場での分散活用を高度に両立させる具体的な仕組みは、 AI時代のデータ活用の鍵を握る統合データガバナンス で解説しています。 特にAI活用では、モデルの精度だけでなく、モデルが使うデータの品質、定義、更新頻度、そして実際の業務にどう紐づいているか(業務との接続)が成果を左右します。データメッシュは、AIの前段にあるデータ基盤と業務設計を整えるためのアプローチだと言えます。 フィジカルAIは生成AIの次に来る製造業の重要テーマ フィジカルAIは、テキストや画像などの二次元のデジタル空間に閉じていた生成AIなどの技術を、機械、設備、ロボット、工場、車両などが存在する三次元の物理世界へと拡張・実装し、自律的な判断・実行を行うAI技術です（ NVIDIA の公式用語集 も同様に定義しています）。 生成AIが、文章作成、検索、要約、コード生成、業務支援など、主に情報処理の領域で力を発揮する一方で、フィジカルAIは、センサーデータ、シミュレーション、制御技術、現場からのフィードバックを高度に組み合わせ、物理世界の動的制御や状態の最適化に関わる判断と実行を担います。 生成AIとフィジカルAIの違いは、次のように整理できます。 項目 生成AI フィジカルAI 主な対象（AIが働きかける空間・対象物） デジタル空間（テキスト、画像、コード、文書など） 物理世界（設備、製造工程、ロボット、車両、工場など） 主な役割 情報の生成、要約、検索、対話、業務支援 物理世界の状態理解、シミュレーション、制御、最適化、自律的実行 製造業でのユースケース例 作業手順書の要約、PLCコード作成支援、保全履歴の検索 製造条件の最適化、設備制御、デジタルツイン、自律運用 必要なデータ 文書データ、業務データ（日報、マニュアル、FAQ等） センサーデータ、工程データ、制御データ 製造業にとって重要なのは、生成AIとフィジカルAIを対立するものとして捉えるのではなく、相互に補完し合うものとして活用することです。生成AIは、現場の情報探索や作業支援に優れ、フィジカルAIは、設備や工程の最適化、自律化に近い領域で価値を発揮します。 そして、この2つのAIを業務成果に結びつけるための共通の土台となるのが、データ基盤です。マニュアルや業務記録といったデジタルのデータ（IT）と、現場のセンサーや設備のデータ（OT）が分断・サイロ化されず、統合・整理されて常に使える状態になっていなければ、どんなに優れたAIも真価を発揮することはできません。 データ基盤そのものの考え方は、 データ基盤の基礎知識 で解説しています。 製造業のAI活用事例: 欧米先進企業3社に見るデータ利活用の共通点 欧米先進企業の事例から分かるのは、製造業のAI活用は「個別ツールの導入」ではなく、「データ基盤・人材・ユースケースを一体で設計する経営テーマ」だということです。3社はそれぞれ異なる強みを持ちながら、AIを業務の周辺機能ではなく、オペレーティングモデルを変える基盤として扱っています。 Dow: データの民主化により、全社の意思決定と研究開発を高度化している Siemens: 制御技術とデジタルツインを組み合わせ、フィジカルAI時代の顧客価値を作っている Rockwell Automation: ITとOTを統合し、自律工場やAI駆動型オペレーションへつなげている 3社に共通するのは、「データを集める」「AIを試す」段階で止まっていないことです。データ基盤や分析ツールを全社で再利用できる形に整備し、人材を育て、社内の成功モデルを顧客やエコシステムに広げています。 国内製造業での具体的なユースケースは、 製造業におけるAI活用事例 で紹介しています。 Dow: データの民主化で、現場データを競争力に Dow（ダウ）は、前半で解説したデータメッシュアプローチを、大規模な伝統的企業が実装し、成果を上げている先進事例です。この実現には、データ利活用を是とする組織文化の変革が必須であり、一般的にその実行難易度は非常に高いとされています。 同社はデータ活用を企業の競争力の中核に位置づけ、全社的なデータの民主化を進めてきました。世界中で事業を展開する同社には、もともと膨大なデータが蓄積されていたものの、全社で効果的に活用できる仕組みが十分に整っていないことが課題でした。そこで2022年、データの民主化を軸に据えた全社デジタル戦略を始動します。 Dowの取り組みで注目すべき点は、単に分析ツールを導入したことではありません。データ基盤、人材育成、ユースケースを一体で進めている点です。 主な取り組みは次の通りです。 データ基盤 : データメッシュ型の「Integrated Data Hub」を構築し、構造化データと非構造化データを統合 ガバナンス : 中央でルールを管理しながら、各現場がデータをプロダクトとして提供 人材育成 : 全従業員を対象に、役割別のData & Analytics Literacyプログラムを展開 ユースケース : Market Intelligence Hub、Carbon Footprint Ledger、Predictive Intelligenceなどへ活用 出典： Dow プレスリリース , Databricks Data+AI Summit 2025, “Manufacturing Cleaner: How Data Intelligence Cuts Carbon, Not Profits” by Dowを基に作成 同社は、現場主導の高度なユースケースを次々と生み出し、世界的に権威のあるITイノベーションの賞 「CIO 100アワード」を5年連続で受賞 するなど、顕著な成果を上げています。その代表的なユースケースは以下の通りです。 Market Intelligence Hub（市場分析の高度化） : 生成AIを活用し、社内外の膨大なデータから市場動向や競合状況などを瞬時に要約。市場の変化に対する迅速で戦略的な意思決定を可能にしています。 Predictive Intelligence（研究開発の短縮） : ポリウレタン事業において、100万以上のデータポイントを用いた機械学習シミュレーションを導入。従来は数ヶ月を要していた新素材の配合探索プロセスを大幅に短縮しました。 Carbon Footprint Ledger（環境負荷の可視化） : サプライチェーン、サステナビリティ、財務データを単一基盤に統合。製品ごとのカーボンフットプリントを可視化し、顧客に対して信頼性の高い証明書（PCF）を提供することで、バリューチェーン全体の脱炭素化に貢献しています。 Dowの事例から見えるのは、データ活用を一部の分析チームだけに閉じないという考え方です。現場やビジネス部門がデータを使える状態を作り、全社の意思決定スピードを高めることが、AI・データ活用の前提になっています。 Siemens: フィジカルAI時代を見据え、データ基盤とエコシステムを再設計 Siemens（シーメンス）は、データ・AIを活用して物理世界とデジタル世界を融合させる戦略で、製造業におけるデータ活用を進めている事例です。同社は、社会インフラ、工場設備、ソフトウェアまでを手掛ける総合電機メーカーです。前段で触れたフィジカルAIの台頭に対し、Siemensは長年培ってきた制御技術や物理的な動作原理への深いノウハウをAIと掛け合わせれば、他社を凌駕する価値を生み出せると考えました。 そのため同社は物理世界とデジタル世界を融合させる「ONE Tech Company」への変革を掲げ、全社で共通のデータ基盤「3つのFabric」を構築してきました。AIを機能させるにはビッグデータやグローバルなプラットフォームといった「規模」も不可欠になるとの考えに基づき、グローバルで組織の壁を打ち破り、データをリアルタイムでAIモデルに供給できる体制へと会社を作り替えたのです。 この事例で重要なのは、フィジカルAIを単なる先端技術として扱っていない点です。制御技術、物理的な動作原理、デジタルツイン、生成AIアシスタント、エコシステムを組み合わせ、業務と顧客提供価値の両方を再設計しています。 主な取り組みは次の通りです。 3つのFabric: データ基盤、テクノロジー基盤、セールス基盤を全社で一元化 Siemens Xceleratorを通じて、自社やパートナーのソリューションをデジタルマーケットプレイス上で提供 NVIDIAとの協業によるデジタルツイン構築など、エコシステム形成を推進 全従業員を対象にしたSiTecSkills Academyで、デジタルの「雇用適格性」を確保するためのリスキリングを体系的に実施 Microsoftとの協業で、製造現場向け生成AIアシスタント「Siemens Industrial Copilot」を開発 同社は、これらの基盤と世界のトップテック企業との協業を活かし、インフラや製造現場を自律化する高度なユースケースを次々と実装しています。代表的なものは以下の通りです。 Siemens Industrial Copilot（産業用生成AI）: Microsoftとの協業で開発。これまで高度な専門知識が必要だった自動化プログラム（PLCコード）の作成やデバッグを自然言語で瞬時に実行します。自動車部品大手Schaefflerなどの先行導入企業において、コード作成時間が劇的に短縮されたことが実証されています。 Building X （スマートビルの自律運用SaaS）: エネルギー管理や設備保全など分断されていたドメインデータを統合。AIが天候などの変化に適応してリアルタイムで最適化し、ビルのエネルギー消費量の30%削減と、純営業利益（NOI）の10%向上を実現しています。 産業用メタバースとデジタルツイン: NVIDIAとの協業により、現実とほぼ完全に同期する物理ベースのリアルタイムシミュレーションを構築。まずバーチャルのデジタルツインで試し、確信を持った結果のみ現実に反映するという次世代AI工場の実現を主導しています。 製造業におけるフィジカルAIの事例として、Siemensの取り組みは先進モデルと言えます。AIは単に現場作業を自動化するだけでなく、設計、制御、運用、販売、顧客向けサービスを横断して価値を生み出す基盤になりつつあります。 Rockwell Automation: 自律型AIと人材投資で、つながる工場を高度化 世界最大の産業オートメーション（FA）専業メーカーであるRockwell Automationは、ハードウェアの売り切り型ビジネスから脱却し、現場の設備とクラウド（SaaS）をシームレスに繋ぐ「The Connected Enterprise（つながる工場・企業）」戦略を推進しています。 同社は、製造業が直面する人手不足やサプライチェーンの複雑化といった課題を解決するためには、AIによる高度な自律化が不可欠であると考えています。その自律化の最大の障壁となるのが、「IT（情報技術）」と「OT（Operational Technology：運用技術）」の分断です。 OTとは、工場内のロボットやセンサー、生産設備を直接制御・監視するための技術です。従来、経営管理やデータ分析を担うITと、現場を直接動かすOTは別々のシステムとしてサイロ化されていました。 Rockwellは、現場のあらゆるOTデータを単一のアーキテクチャ（Logix）で統合し、それを経営層のITシステム（Plexなど）へリアルタイムに繋ぐという、強固なIT/OT統合データ基盤を構築し、この壁を打ち破っています。 このシームレスな統合基盤の上で、同社は 今後5年間で自社のインフラと人材に総額20億ドルという大規模投資をコミットし、社内では年間約100万時間の学習機会を提供 しています。さらに特筆すべきは、自社の枠を超えた取り組みです。ManpowerGroupと連携し、退役軍人を高度デジタル人材へリスキリングし、人材難に悩む顧客企業へ直接供給するという、業界全体の人材不足という構造的課題を主導して解決する取り組みも進めています。 シンガポールの自社工場では、大規模言語モデル（LLM）やデータの因果関係を理解する因果AI、自律実行するAgentic AIを組み合わせた「Factory AI（AIアシスタント）」を現場に導入しました。工場内で機械の停止や品質の異常など問題が発生した際、このAIアシスタントが即座に介入。リアルタイムの診断データから原因をAIが特定し、現場のオペレーターに対して「今、何をどうやって直すべきか」という復旧プロセスをガイドします。これにより、生産ラインの最適化、廃棄物の最小化、そしてダウンタイムの削減を実現しています。 この事例の最大の成果は、新規オペレーターの育成期間の大幅な短縮です。通常、組み立てラインに新しい従業員を配置して一人前に仕事ができるようになるまでには、約6ヶ月の期間を要していました。しかし、AIアシスタントがトラブル時の対応をリアルタイムで横からガイドし、AR/VRで手順を視覚的に教えることで、 この習熟期間をわずか数週間にまで短縮することに成功しました 。この画期的な取り組みは高く評価され、Dowと同じく、優れたITイノベーションに贈られる「CIO 100アワード」を受賞しています。 実務上の示唆: 統合: PlexとLogix Architectureで、経営・ITレイヤーと現場・OTレイヤーを接続 セキュリティ: SecureOTで、IT/OT統合に伴う産業環境のリスクに対応 現場価値: 予兆保全、品質最適化、AIアシスタントによるオンボーディング短縮に展開 Rockwell Automationの示唆は、AIを分析画面の中で完結させず、IT/OT統合とセキュリティを前提に現場の判断と実行へ近づける点にあります。 データ利活用で成果を出す企業に共通する3つのパターン Dow、Siemens、Rockwell Automationの事例に共通するのは、AIを単発のツール導入で終わらせていないことです。各社は、製造業のデータ活用を企業のオペレーティングモデルそのものの再設計として捉えています。 共通パターンは、次の3つに整理できます。 1. コア業務で成功モデルを作り、顧客価値へ広げる 成果を出す企業は、まず社内のコア業務でAI活用を試し、成功体験を蓄積しています。そのうえで、得られた知見を顧客向けサービスやパートナーとのエコシステムに広げています。 この流れは、製造業のデータ活用において重要です。品質改善、製造条件の最適化、需要予測、保全、製品開発など、社内で価値を確認できるユースケースから始めることで、AI活用の説得力が高まります。 2. 現場とビジネス部門がデータ活用を主導できる人材育成を行う データ活用は、データサイエンティストやIT部門だけでは定着しません。製造業では、現場の工程理解、設備知識、品質管理の経験、顧客やサプライチェーンへの理解が欠かせないためです。 先進企業は、全社展開のリテラシー向上プログラムや役割別の教育を通じて、ビジネス部門が自らデータを使い、AI活用を主導できる体制を整えています。 3. データを再利用できる資産として扱う AI活用の成果は、個別の分析テーマだけでなく、データを継続的に使える状態にできるかに左右されます。 データメッシュの考え方に代表されるように、先進企業はデータを分析のたびに集める素材ではなく、再利用可能なプロダクトとして扱っています。品質、説明可能性、権限、更新性を担保したデータを整えることで、AIモデルや分析業務の再現性が高まります。 日本の製造業では、現場データを活かす仕組みが鍵になる 日本の製造業でデータ活用を進める場合、重要なのは、現場の知見とデータを切り離さないことです。熟練者の経験、設備条件、品質データ、工程間の関係性を、AIが扱える形に変換し、現場の意思決定に戻す仕組みが必要です。 日本の事例として、 JFEスチール株式会社の取り組み があります。ハイテン鋼（高張力鋼）は従来の汎用鋼材と比べ、製造条件の微妙な変化が品質に大きな影響を与えます。大量生産を前提とする製鉄業では早くから統計的手法に基づく技術革新が図られ、同社においても従前よりハイテン鋼のデータ分析に取り組んできました。一方、従来の方法では、各種センサーの増設によるデータ量の飛躍的な増大もあり、ハイテン鋼に対応した緻密な解析は困難になりつつありました。 そこで、サイバー空間上に製造プロセスを再現するCPS（Cyber Physical System: サイバーフィジカルシステム）を展開し、現実世界から収集したデータをdotDataで解析しました。理想の品質を正解データとして入力し、関連するデータから品質に影響する複合的な要因やパターンを抽出し、現場のオペレーションにフィードバックする取り組みです。 dotDataによるデータ解析の結果、従来は気が付かなかった複数の要因による製造プロセスにおける相関関係が発見され、そこからの知見を元にオペレーションを最適化することにより、歩留まり率の向上につながりました。 取り組みの詳細は、 JFEスチールのハイテン鋼における歩留まり改善の導入事例 で紹介しています。 同社では、データサイエンティストによる高度なデータ分析も並行して行っていますが、dotDataを活用した現場エンジニアによるこうしたデータ利活用は、今後、より迅速な意思決定に大きな役割を果たしていくことが期待されています。 この事例が示すポイントは、単にAIモデルを作ることではありません。現場を熟知したエンジニアが解析に関わり、複数工程にまたがる要因を見つけ、意思決定のスピードを高めている点です。 製造業のデータ活用では、以下のような観点が導入判断の軸になります。 どの業務課題を、最初のユースケースにするか 現場部門がデータの意味を説明できる状態になっているか 設備、品質、工程、需要、在庫などのデータが連携できるか 分析結果を、現場のオペレーションに戻す仕組みがあるか AI活用を一部の専門家に閉じず、継続運用できる体制があるか 生成AI、データメッシュ、フィジカルAIは、それぞれ別々の流行語ではありません。製造業がデータ活用を事業成果につなげるために、情報処理、データ基盤、物理世界の制御や最適化をどうつなぐかという一連のテーマなのです。 まとめ: 製造業のデータ活用は、AIを使う業務設計から始まる Dow、Siemens、Rockwell Automationといった欧米先進企業の事例から見えてくる最大の共通点は、AIやデータの利活用を単なるIT部門のテーマや個別ツールの導入として終わらせず、経営課題と捉え、全社の取り組みとして推進しているという大前提です。 AI活用を経営課題とし、企業のオペレーティングモデルそのものを再設計している欧米先進企業の事例から見える共通点は、次の3つです。 コア業務でAI活用の成功モデルを作り、顧客価値やエコシステムへ広げる まずは自社のコア業務やR&DでAIを使い倒して生産性向上の成功モデルを確立し、その成果を顧客向けのサービスや、業界全体を巻き込んだ共創エコシステムへと昇華させています。 現場やビジネス部門がデータを使えるよう、人材育成と役割設計を進める データ活用を専門家だけに閉じず、全社展開のリテラシー向上プログラムや役割別の教育を通じて、現場の業務プロセスや設備を熟知したビジネス部門自らがAI活用を主導できる体制を築いています。 データを再利用可能なプロダクトとして扱い、ガバナンスとスピードを両立する データメッシュのアプローチに代表されるように、データを分析のたびに集める「素材」ではなく、他部署も利用可能な「プロダクト」として扱うことで、全社的なガバナンスを効かせながら現場の分析スピードを最大化しています。 日本の製造業においても、品質改善、製造条件の最適化、予知保全、需要予測、サプライチェーン最適化など、データ活用の余地は多くあります。重要なのは、個別のツール選定の前に、自社の業務課題とデータの使われ方を整理することです。 dotDataは、製造業におけるデータ活用やAI活用の支援を通じて、現場の知見とデータを結びつけ、 業務に使えるインサイト を引き出す取り組みを支援しています。また、データ主導の組織づくりを支える ビジネスアナリティクス人材育成サービス も提供しています。製造業でAI活用を検討する際は、まず自社のどの業務課題から始めるべきか、どのデータを活かせるかを整理することが、次の一歩になります。AI・データ活用のご相談や、貴社の課題に合わせた最適なアプローチについては、ぜひお気軽に お問い合わせ ください。 The post 製造業のデータ活用事例: 欧米先進企業に学ぶAI・データ基盤・人材変革 appeared first on dotData .

こんにちは、AWSの嶺、篠原、鈴木です。2026年5月、DeNAのヘルスケア事業部門のDeSCヘルスケア株式会社（以下、DeSC）の皆さまと、AI-DLC（AI-Driven Development Life Cycle）の3日間プログラム「Unicorn Gym」に取り組みました。AI-DLC は、AWS が提唱する「ソフトウェア開発に対する AI 中心の革新的なアプローチ」であり、AI の能力を開発プロセスの構造そのものに組み込む新しい方法論ですが、その方法論をソフトウェア開発ではなく「データ分析業務」へ適用しました。 AI-DLC では、要件定義や実装の主役を AI が担い、人間は「何を作るか」という意図のすり合わせと重要な判断に集中します。詳しくは  AI 駆動開発ライフサイクル：ソフトウェアエンジニアリングの再構築  をご覧ください。また、この AI-DLC を座学ではなく自社の実テーマで3日間走り切る形で体験するプログラムが Unicorn Gym です。 3日間を終えて印象に残ったのは、AI の性能そのものよりも、部署をまたいでメンバーの認識をそろえていく営みに対してAIを用いるポテンシャルの大きさです。 インタビューさせていただいた DeSC ヘルスケア株式会社の皆様。 左より、嶺（AWS） 山田真里香（インダストリー統括部分析企画部）、伊藤 康太郎（製品開発統括部 統括部長） 、香村 和宏（インダストリー統括部分析企画部 部長） 、河野 愛樹（製品開発統括部プロダクトマネジメント室） 、鈴木（AWS） 1. なぜ「データ分析業務」を選んだのか 嶺: まず、AI-DLC に取り組むことになった経緯を教えてください。 河野 氏: AWS さんから「AI-DLC というものがある」とご提案いただいたのが最初です。実は、最初に話を聞いた伊藤は「これがどこにはまるのか、他の研修と何が違うのか」とピンときていない様子でした。一方で私は、これまで組織を俯瞰して見る中で感じていた大きな「壁」を乗り越えるきっかけになるのでは、という期待を感じていました。 部門間、特にビジネス側とシステム側のように大きくロールが異なる組織の間でコミュニケーションギャップが昔から各所で存在しており、認識合わせに時間がかかったり、同じ言葉を使っていても「これって実はこんな認識だった」というズレが起きている。同じベクトルを向ききれていない、一体感を作りたいのに作り切れていない、といったモヤモヤを感じていました。そこに拍車をかけたのがAIです。DeNA社長の南場が「AIオールイン」と発したのを皮切りに、ヘルスケア事業部門でも「AI活用をやっていくぞ」と掲げたものの、前のめりで使う人と、様子を見ながらゆっくり始める人とで差がある。その差がどんどん開いていっていることに危機感を感じていました。 「同じ体験を共にすることで、共通言語を持てるようになるのではないか」、「できる人がどう使っているのか、どう指示や操作をしているのかを、ちょっと隣で見せてもらうだけでも変わるんじゃないか」と思っていたところに、AI-DLC と Unicorn Gym を耳にして、「これははまるんじゃないか」と伊藤に持ちかけたんです。 嶺: 最初に検討されたテーマは、実はシステム開発だったと伺いました。 河野 氏: そうなんです。ちょうどその頃、新しい分析環境を作るプロジェクトが走っていました。分析環境そのものや運用ツールセットを作る必要があったので、そこに適用するのがテーマ的にも丁度良いのではないか、というところから始まりました。でも伊藤から「システム開発でやるなら別にUnicorn Gymじゃなくてもいい。どうせやるなら、その新しいシステム上で行う予定の分析業務にフォーカスを当てるのはどうか」とカウンターが来たんです。 伊藤 氏: できるかできないかよりも「どうせやるならペインが強いところをやった方がいい」と。参加者全員が自分事にできるテーマならば、面白い取り組みになるだろうという直感がありました。そしてもう一つ。AI活用のボトルネックは組織・部門の繋ぎ目で発生することは分かっていました。当時はデータサイエンス部とビジネス部門である分析企画部間の連携の難しさが表面化していた時期でした。私たちはハイブリッドワークで、顔を突き合わせて作業する機会が普段は多くありません。部門を跨いだ共同作業の機会や経験は特に少ない。お互いのバックグラウンドも実はよく分かっていない。一方で、新しい業務・新しいプロジェクトだからこそ「最悪、失うとしてもこの3日間だ。だったらやってみよう」と、リスクをとって動くことにしました。 嶺: まさにそこなんです。AI-DLC はソフトウェア開発の文脈で語られがちですが、本当に言いたいのは、実装を AI が担うようになると、ボトルネックが実装から「人と人の合意形成」に移る、ということなんです。別々に動いていると意思疎通がうまくいかず、手戻りが起きる。これはソフトウェアに限らず、どの業界でも起きています。だから、データ分析でも同じことが起きているはずで、そこで成立すれば AI-DLC の使いどころは大きく広がる、と考えていました。 AI-DLC に取り組んだ経緯を語る河野氏（右） 2. 3日間で、何をしたのか 嶺: どのようなメンバーで、どんな3日間だったのか教えてください。 河野 氏: Unicorn Gymには、分析企画部と、データサイエンス部を中心に、合わせて24名で参加し、部門混成・AI活用の度合い混成で4チームを編成しました。 香村 氏: 分析企画部は、ヘルスビッグデータを用いた分析の企画を行っている部署です。私たちが製薬企業様などのニーズ（ある疾患の治療実態把握など）をヒアリングし、そこで定義したお客様の問いから、どのデータをどう集計・加工すれば答えになるのかに翻訳した「要件定義書」を作成します。この要件定義書を元に、データサイエンス部が実際の集計を行います。 河野 氏: 今回のUnicorn Gymは、AIを活用した要件定義書作成をメインコンテンツにしました。初日の午前は座学の時間。AWSさんからAI-DLCの考え方を教わりながら、簡単なハンズオンを行いました。以降はチームごとに分かれ、モブワーク（1つの画面を全員で見ながら、同じ作業を一緒に進める進め方）の時間。AIをフル活用して、質の高い要件定義書をどれだけ無駄なく苦労なく作れるかを試行錯誤しました。 山田 氏: モブワークを通して、「AI にどこまで任せるか」が具体的になりました。最初は自分たちで考えた結果を AI に渡していたのですが、AWS さんから「それだと AI が待っている時間が多い。もっと AI に考えさせて」とアドバイスを貰って。全部いったん AI に投げて、その間に自分たちで議論する形に変えたら、スピードが一気に上がった。これを初日に教われたのは大きかったです。 3. ビジネス部門へ波及した影響 嶺: 実際にやってみて、いかがでしたか。ビジネス部門からの視点でお伺いさせてください。 香村 氏: 私は正直なところ、Unicorn Gymに参加して起きることの解像度が、河野や伊藤よりも更に低かったです。「参加した結果、具体的にどんな変化が起きますか」と伊藤に確認したら、「やってみないと分からない部分もあるけど、信じて飛び乗ってくれ」と。弊社メンバーとAWS さんへの信頼だけで飛び乗った、というのが正直なところです。 ですが、やってよかったと自信を持って言えます。私たち分析企画部は、データサイエンス部やエンジニアと比べるとAI 活用では一歩後ろにいました。それが、一緒に作業することで、ミーティングで話すだけでは分からない「こういうときに使えば良いんだ、という具体的な使い所」、「こういう時は、こう AI に聞けばいいのか」という手触り感まで得られました。 嶺: 分析企画とデータサイエンス、普段は分業されている両者が同じチームで動いた意味は大きかったのでしょうか。 山田 氏: 大きかったです。これまでは分業制で、私たち分析企画部が定義を決めてからデータサイエンス部にパスしていました。私たちが書く定義書は、お客様との対話に必要な情報としては十分に書けているつもりなんです。ただ、SQL の設計という目線で見ているデータサイエンス部からすると「ここはもっと細かく決めておかないと書けない」と映ることがある。 一緒に動いてみて改めて感じたのは、必要な詳細さの基準が立場によって違うということでした。私たちはお客様と向き合う立場から、データサイエンス部はデータを集計する立場から、同じテーマを見ている。その上で、お互いがどう情報を組み立てているのかを理解できたので、どこをどう補い合えばいいのかが見えてきました。「その組み立て方なら、業務フローをこう変えた方がいいよね」という気づきも生まれましたし、私たちがお客様とどう情報を組み立てているかを共有できたことで、要件定義書を作る AI をどう組み立てればいいかのヒントも見えました。データサイエンス部が普段どう AI を使っているかも学べて、お互いにいい影響がありました。 嶺: Unicorn Gymの3日間で、特に印象に残っている場面はありますか。 香村 氏: コンペ形式となった最終成果発表です。各チームがそれぞれの工夫を施したAIエージェントに要件定義書を作らせ、できあがった要件定義書を元に別のAIエージェントに集計作業を行わせました。ここでは、AIエージェントの実力を測る目的で、実業務では必ず入れる「人の目による要件定義書のレビュー」を外すルールで実施しました。 4チームそれぞれの画面を大きなスクリーンに並べ、4つのAIエージェントが動いている様子をみんなで眺めていた時が特に印象的でした。正直、最初は「AI が質の高い要件定義書を作るのは難しいのではないか」と思っていたんです。それが次々と要件定義・集計を進めていき、その光景は圧巻で素直に驚きつつ、データ分析業務の品質やスピード感を高める具体的なイメージを持つことができました。この会社に入ってから、一番ワクワクした時間だったと思います。 最終成果発表。4チームのAIエージェントが動く様子 4. DeNAの事業への向き合い方 嶺: 今回、印象的だったのは、皆さんが「何をやるか」から自分たちで考え、全体を引っ張っていかれたことです。他のお客様ではなかなか見られません。このオーナーシップはどこから来ているのでしょうか。 伊藤 氏: 大前提として、ノープランで挑むと期待した成果は出ないと思ったので、拠り所になるベースラインは用意しました。ただ「作るけれど、出たとこ勝負になる」というのは織り込み済みでした。私たちは普段から、仮説を立てて、観察した事実から軌道修正していく進め方が体に染みついているんです。だから、計画どおりに進まないこと自体には抵抗がなかった。 嶺: 通常の Unicorn Gym では、チームごとの進行はお客様が、全体を束ねる役割は AWS が担うことがほとんどです。その全体を束ねる役割まで、お客様側が担われたのは珍しいことでした。 伊藤 氏: AI 活用や開発生産性の話は、トップマネジメントのコミットメントが決定的に重要だと考えています。組織にとっての未知の経験はリーダーが前に立ってリスクを取らないと物事は進まない。「よく分からないだろうけど、まず信じて3日間を賭けてくれ」と言えるかどうかです。失敗を許容できない組織だと、このやり方は取りづらいと思います。 AI-DLC への向き合い方を語る伊藤氏 5. AI-DLC Unicorn Gymを経た変化 嶺: 3日間を経て、業務にはどんな変化が出ていますか。 香村 氏: Unicorn Gymで各チームが作成したClaude CodeのSkills（業務の手順やノウハウをまとめてAIに読み込ませる仕組み）から厳選したものを、実業務にも取り入れて活用しています。また、分析企画部内でもSkillsを新たに作成・部内で共有される光景が日常的なものとなりました。今年に入ってUnicorn Gymの前までの5か月間では1件だったのが、その後2か月で6件が共有され、今後もこの流れは加速する見込みです。Skillsの共有を通して、属人化していた勘所や専門性が組織の資産となり、我々が提供するサービス品質の安定・向上に寄与し始めています。 山田 氏: ビジネス側は GitHub に馴染みがないところからのスタートでしたが、Skills を GitHub で共有して使う、という動きが浸透しました。「これは自分でやるしかないか」と思っていた課題を「AI で解けるかも」とスキル化する発想も増えました。そして何より、データサイエンス部とのやり取りが円滑になりました。以前はお客様と合意した要件定義書を渡すだけだったのですが、「顧客面談に同席しませんか」と声を掛けることが増えました。要件定義書が決まり切る前段階でのコミュニケーションが増えたことで、よりスピード感を持った対応ができるケースも実際にありました。 伊藤 氏: この流れは社内で連鎖しています。AI-DLC で手応えがあったので、続けて業務プロセスをAIで革新する「AI-BPR」も進めていて、次回は参加人数が40名規模になりそうなほど期待が高まっています。参加した人が手応えを持ち帰り、役職関係なく周囲を巻き込んで、あちこちで動きが広がっています。 3日間を経た変化について語る香村氏（右） 6. 製薬・ヘルスケア業界へのメッセージ 嶺: 最後に、AI 活用を検討されている製薬・ヘルスケア業界の方々へメッセージをお願いします。 香村 氏: 私たちはサービスを通じた生活者の健康増進を目指していますが、データを分析するだけでは、その実現にはつながりません。製薬・ヘルスケア業界の皆さまとヘルスビッグデータを活用し、生活者の健康増進に繋がるエビデンスを創出し、社会に還元していきたい。AIについても、それを加速させるために、皆さまと活用方法を学び合っていけたらと思います。 伊藤 氏: 近年は、1社だけでは解けない課題が増えています。医療機関、自治体、健康保険組合、そして私たちのようにデータソリューションを提供する立場と、それぞれに得意・不得意がある。健康寿命の延伸も医療費の適正化も、各社の強みを持ち寄らないと解けません。AI はあくまで手段です。どの会社にもある組織の壁を、モブワークで取り払って初めて課題解決が進む。それを社内だけでなく、業界全体に広げていきたいと考えています。 まとめ AI-DLC の中心にあるのは、人と人が認識をそろえていく営みです。「何を作るか」、「どのように人と人の合意形成をするのか」という命題に対して、AIを介在者として活用する威力を大いに実感した3日間でした。今回はデータ分析ドメインでのAI-DLCの活用でしたが、ソフトウェア開発におけるAI-DLCについての記事もぜひご覧ください。現在DeNA様はAI-BPRも推進されておりますので、そちらについての記事もお待ちください。 Unicorn Gym には DeSC から24名が参加した 著者自己紹介 伊藤 康太郎 DeNA の主要子会社であるDeSCヘルスケアの最高技術責任者兼製品開発統括部長。彼はDeSCヘルスケアが提供するデータヘルス関連サービス及びデータ利活用サービスの製品・技術・データサイエンスを統括しています。     香村 和宏 DeSCヘルスケア株式会社インダストリー統括部分析企画部部長。健康・医療データの利活用を推進する事業において、製薬企業、アカデミア、生命保険会社のお客様を中心に、DeSCデータベース等のリアルワールドデータを用いた分析のニーズヒアリングから要件定義、結果のご報告までを担当しています。     嶺 行伸 Developer TransformationチームのスペシャリストSAとして、主にAI-DLCを中心に、お客様の開発チームを支援しています。       鈴木 賢人 デジタル・エンターテインメント領域のお客様を担当するAccount Managerです。趣味は旅行と身体作りです。       篠原 聡志 ゲーム企業を経て AWS に入社。ソリューションアーキテクトとしてゲーム業界のお客様を担当し、ゲームバックエンドの設計や生成 AI の活用をご支援しています。好きな AWS サービスは Amazon Bedrock、Amazon S3 です。趣味はリズムゲームと VR ゲームです。