はじめに：設計における2つのアプローチ こんにちは。電通総研の技術統括推進ユニット 江夏秀俊と、同じく電通総研の製造エンジニアリング本部 エンジニアリング1ユニット 齊藤智明です。 製品開発やエレキ・メカ設計の現場で、次のような状況を目にすることはないでしょうか。 「機能ブロック図などの図面（定性モデル）を作成してみたものの、その後の詳細設計への活かし方が分からない」 「外部の提案や手法に沿って構造の整理を進めたが、具体的な仕様決定やトレードオフの判断で行き詰まる」 「設計判断を迫られても数値的な根拠がなく、最終的に経験則や勘に頼って決定してしまう」 多くのエンジニアは、普段から数式や計算（定量モデル）を用いて設計業務を行っていることと存じます。しかし、導入された定性モデルとの付き合い方や、両者の役割分担に悩まれるケースも少なくありません。 本記事で最初にお伝えしたいのは、 「定性モデルは不要」と否定するつもりは一切ない ということです。設計活動には役割の異なる「定性モデル」と「定量モデル」の2つが存在し、 両者を組み合わせることで、より根拠のある設計判断が可能 と考えます。 定性モデル： 構成や機能を分解・整理・共有するためのアプローチ（例：機能ブロック図、概念図、システム構成図） 定量モデル： パラメータや物理量を計算・解明するためのアプローチ（例：数式モデル、1DCAE(Simulink、Modelica言語など)/3DCAE） ※本記事では議論の前提として、ドキュメントベースの静的な図面だけでなく、SysML等のモデリング言語による記述であっても、外部ソルバーや物理計算と自動連携されていない静的な記述に留まるものは便宜上「定性モデル」として扱います。 `【図1：定性モデルと定量モデルの役割と、両者を組み合わせた設計判断のプロセス】` 本記事では、定性モデルが持つ本来の価値を整理したうえで、なぜ定性モデル「だけ」では設計判断が難しいのかという理由と、本来必要な「定量モデル」が担う役割について解説いたします。 定性モデルの重要な役割 ～全体構造の共通言語として～ 前提として、機能ブロック図などの定性モデルは、設計活動において「全体構造の共通言語（マップ）」として機能します。 議論の土台： 既存製品やシステム全体像を俯瞰し、チームや部門間で認識を揃える。 概念の共有： 専門外のメンバー（他部署やステークホルダー等）に対し構造をわかりやすく説明する。 インターフェース整理： 機能同士の繋がりを明確にし、モジュール化や仕様のモレを防ぐ。 市販の汎用ユニットや仕様や許容範囲が明示された規格部品を組み合わせるだけのアセンブリ設計であれば、各モジュールの性能や接続条件が事前に規定されているため、定性モデル（構成図など）だけでも モジュールの選定や組み立て が成立する場合があります。 しかし、 新領域の製品開発や新規設計、極限までの性能追求が求められる開発 においては、構成図だけでは「物理的に本当に成立するか」を担保することが困難です。どれだけ綺麗な機能ブロック図を描いたとしても、それ単体で部品の寸法や仕様の数値が決まるわけではないためです。 定性モデルだけでは「設計判断」が難しい3つの理由 定性モデル「だけ」で設計判断（仕様決定やトレードオフ）を下そうとすると、次の3つの壁に突き当たると考えられます。 理由1：数値による「性能評価」が難しい 機能ブロック図の上に「冷却ファンから熱交換器へ風を送る」と定義することで、機能の定義や接続関係は明確になります。しかし、「具体的に温度が何℃低下するか」という物理量による定量的な評価が難しくなります。 その結果、「良くなりそう」という感覚だけで判断を進めてしまい、後工程の実機テストなどの段階で目標性能に届かないことが発覚し、大幅な手戻りが発生するリスクがあります。 理由2：「設計限界」の評価が難しい 「どこまで板厚を薄くしたら破壊するか」「最大荷重がかかった際に変形が許容内に収まるか」といった限界値（マージン）は、ブロック図を描くだけでは見極められません。 結果として、限界が分からないために安全側を見すぎて過剰設計となり、コスト高や重量増加を招くか、逆に限界を見誤って品質リスクを抱える懸念があります。 理由3：対象の「物理特性」の評価・追跡が難しい SysMLなどのアーキテクチャ図やブロック図の補足として、注釈テキストで V = IR（オームの法則）や F = ma（運動方程式）などといった具体的な数式が併記されているケースがあります。 しかし、モデル図やドキュメントの上にいくら数式が書かれていても、それらは人間が読むための「文字情報（注釈）」に過ぎません。モデル内の変数同士がプログラムや計算式として相互に自動連動（自動計算）されていない以上、仕様変更や異常が発生した際の静的・動的な物理応答を評価・追跡することは難しくなります。 `【図2：定性モデルの壁と定量モデルによる補完】` 定性モデルを補完し、より確かな設計判断を下すための「定量モデル」 定性モデルを補完し、より確かな設計判断を下すためには 物理現象を数学的に表現した「定量モデル（数式・シミュレーション）」 の活用が重要となります。 もちろん、定量モデルの構築にはモデル作成コストや専門知識が必要という側面もあります。だからこそ、まず定性モデル（全体マップ）で「どこを定量計算すべきか」の範囲を絞り込み、その上で「1DCAE（集中定数モデルやModelicaなどを活用したシステムレベルのシミュレーション）」や「3DCAE（構造・流体・電磁界解析など）」といった定量モデルを活用することが効率的です。 定量モデルを活用することで、3つの壁に対応した設計判断が可能になると考えられます。 1. 性能の数値化（理由1へのアプローチ） 「〇〇Wの熱が発生した際、何℃まで温度が上昇するか」といった具体的な数値を物理シミュレーションによって算出し、定量的な評価結果として性能を評価できます。これにより、試作前に性能未達リスクを低減できます。 2. 限界・境界の予測とトレードオフ評価（理由2へのアプローチ） 製品が破壊・作動不良を起こすギリギリの境界値（設計限界）を予測・評価できます。これにより、過剰設計（オーバースペック）を防ぎつつ、「軽量化と強度のトレードオフ評価（最適解の探索）」などの判断をデータに基づいて下すことが可能になります。 3. 物理特性（動作）のトレースと実測検証（理由3へのアプローチ） 変数同士が計算結合されたモデルを用いることで、仕様変化に伴う定常応答や、時間経過に伴う動的な過渡応答を数学的にトレースできます。また、実測データ（ベンチテスト）と比較することで、モデルの妥当性の確認（バリデーション）やトラブル原因の分析に活用できます。 まとめ：定性で共有し、定量で判断する 「機能ブロック図を作成して完結した気になってしまう（その後の使い道が見えない）」という課題に対する有効なアプローチは、両者の役割分担を正しく理解することだと考えます。 定性モデルは「認識合わせのツール」： システム全体の構造や機能を関係者間で共有し、共通言語を作るために使う。 定量モデルは「設計判断のツール」： 物理的な数値根拠を導き出し、仕様決定やトレードオフ評価を行うために使う。 機能ブロック図などの定性モデルの上に、単に結果の数値を注釈としてメモするだけでは、計算可能な形で定量化されたとは言えません。定性モデルで全体像を可視化しつつ、その裏側にあるシミュレーション等の定量モデルと連携させて数値的な根拠に基づく設計判断を下す。この「両輪のアプローチ」を正しく機能させることが、手戻りの低減や、より確かな設計判断へ繋がる一助になるのではないかと考えております。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @koka.hidetoshi レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

本記事は 2025 年 7 月 18 日に公開された Edwin Sandanaraj、Charlie Lee、Billy Rowell、Khi Pin Chua、Rajesh Sukumaran による “ Benchmarking PacBio whole genome sequencing variant pipeline analysis with AWS HealthOmics workflows ” を翻訳したものです。 ゲノム研究が医療とポピュレーションヘルス (集団全体の健康) の最前線を切り拓き続ける中で、複雑なゲノム領域の解読、構造バリアントの同定、そして遺伝的多様性の大規模な理解には、ロングリードシーケンシングがますます不可欠になっています。 PacBio HiFi シーケンシングは、高精度かつ長いリードを生成するため、包括的な全ゲノムシーケンシング (WGS) に適しています。 大規模なロングリード WGS 解析を実行するには、スケーラブルでセキュア、かつ本番運用に耐える計算環境が必要です。 AWS HealthOmics はまさにこの用途に特化して構築されており、バイオインフォマティシャンはコンテナ化されたワークフローの実行と大量のゲノムデータの処理を、高い信頼性と柔軟性をもって行えます。 PacBio と AWS HealthOmics ワークフローの統合 アーキテクチャは、大規模ゲノミクスプログラムの中核として機能してきました。この実装により、セキュアかつ効率的なデータ処理を実現しながら、大規模な解析結果の提供を効率化できます。HealthOmics の堅牢なセキュリティとスケーラブルなインフラストラクチャを活用することで、PacBio ワークフローは大規模なロングリードシーケンシングデータを処理しつつ、国家的なヘルスケア施策に求められるデータガバナンス基準を維持できます。こうした実際の運用実績は、HealthOmics が PacBio の全国的な精密医療プログラムをエンタープライズ級の信頼性とパフォーマンスで支えられることを示しています。 本ガイドでは、PacBio の WGS バリアントパイプライン を AWS HealthOmics 上で実装する方法を紹介し、広範なベンチマークに基づく大規模かつコスト効率の高いデプロイに向けたパフォーマンス最適化の知見とエビデンスに基づく推奨事項をお伝えします。 PacBio HiFi シーケンシングは、典型的には 15〜25 キロ塩基のロングリードを、高い塩基精度 (塩基の 90 パーセントが Q30 を上回る) で生成します。この組み合わせにより、研究者は反復領域や GC (Guanine-Cytosine) リッチな領域を網羅し、ハプロタイプを正確にフェージング (決定) し、ショートリード技術では見落とされがちな構造バリアントを検出できます。ロングリードシーケンシング解析の代表的な用途は次のとおりです。 一塩基バリアント (SNV) および小規模な挿入・欠失 (indel) – 塩基レベルの変化や複数塩基にわたる小さな変異 構造バリアントの発見 – 大規模な挿入、欠失、再構成を塩基レベルの精度で解読 ハプロタイプのフェージング – 長いハプロタイプブロックにわたって、バリアントを母方または父方のアレルに割り当て 複雑な遺伝子座のアセンブリ – 疾患関連遺伝子座における反復配列や遺伝子重複を解き明かす De novo アセンブリ とパンゲノム構築 – 集団特有の多様性を反映した、高品質で連続性の高いゲノムアセンブリの生成 DNA メチル化 – ゲノム全体の CpG サイトにおける 5-メチルシトシン (5mCpG) マークから、活性領域や不活性領域を同定 PacBio HiFi WGS バリアントパイプラインの技術概要 PacBio の WGS バリアントパイプラインは Workflow Description Language (WDL) で定義されており、二次解析と三次解析に向けたモジュール式かつコンテナ化されたソリューションを提供します。このパイプラインには、HiFi アライメントツールに加え、SNV、小規模な挿入・欠失、コピー数バリアント (CNV)、構造バリアント (SV) 向けに設計されたバリアントコーラーが組み込まれています。さらに、タンデムリピート (TR) のジェノタイピング、セグメント重複領域内の遺伝子の型判定 (遺伝子タイピング)、バリアントのハプロタイプへのフェージング、コンセンサス 5mCpG 確率の推定などの機能も備えています。マルチサンプルのコホートに対しては、小規模バリアントと構造バリアントの両方に対するジョイントコーリング (joint-calling) を提供します。包括的なアノテーションツールは、小規模バリアントと構造バリアントの両方に対応します。ヒト HiFi データを解析するステップは次のとおりです。 リードアライメント – HiFi リード向けに最適化されたマッパーおよびアライナーである pbmm2 を用いて、ロングリードをリファレンスゲノムにアライメントします。このアライナーはスプリットマッピングや大きなギャップを効率的に扱えるため、構造バリアントやセグメント重複を正確にマッピングするうえで重要です。出力は、下流処理向けの豊富なメタデータを含む、ソート済み・インデックス付きの Binary Alignment Map (BAM) ファイルです。 SNV と小規模バリアントのコール – SNV および小規模な挿入・欠失の検出には、HiFi リードに特化して学習させたバリアントコーラー ( DeepVariant ) を使用します。ロングリードデータのエラープロファイルとリード特性に合わせて調整された 機械学習 (ML) モデルを適用することで、マッピングが難しい領域でも偽陽性率の低い高信頼のバリアントコールを生成します。 構造バリアントの検出 – このステップでは、リードシグネチャとアライメントパターンを比較して、欠失、挿入、逆位、転座などの大規模なゲノム変化を同定します。PacBio の構造バリアントコーラー ( pbsv ) はロングリードデータ向けに設計されており、ショートリードのアプローチでは見落とされがちな複雑なブレークポイント、タンデムリピート、マルチアレリック (multi-allelic) なイベントを検出できます。 重複領域のバリアント – Paraphase は、遺伝子ファミリーのリードを単一のリファレンスコピーへ再アライメントしてハプロタイプを同定することで、セグメント重複領域における小規模バリアントをコールします。 タンデムリピートバリアントコーラー – Tandem repeat genotyping tool (TRGT) は、HiFi リードにおけるタンデムリピートの変動 (多型) を解析・ジェノタイピングします。リピート長 (サイズ) に基づく標準的なジェノタイピングに加えて、配列組成、リピートのモザイク性、CpG メチル化パターンの包括的な解析、そしてリピートをスパンするリードの視覚的表現も提供します。 フェージングとハプロタイプの決定 – 下流の解釈をサポートするため、ワークフローにはバリアントをハプロタイプに割り当てるフェージングステップが含まれています。 HiPhase は HiFi リードのロングレンジ情報を活用し、数十キロ塩基にわたるハプロタイプブロックを決定することで、臨床および集団ゲノミクスの文脈における解釈性を向上させます。 5mCpG 検出 – pb-CpG-tools は、アライメント済みの HiFi リードから、CpG に対するハプロタイプ特異的なサイトメチル化確率を生成します。 コホートレベルのジェノタイピング (任意) – 複数サンプルのコホートに対しては、 glnexus と pbsv を用いたジョイントジェノタイピング (joint-genotyping) のステップを追加することで、サンプル間のバリアントコールを整合させることができます。 アノテーション – パイプラインには 2 つのアノテーションツール、 slivar と svpack が含まれており、小規模バリアントと構造バリアントに対する包括的なアノテーションを提供します。 ワークフローは 7 つの主要なステップで構成されています (次のアーキテクチャ図の 1〜7 に対応)。 HiFi-WGS パイプラインを AWS CloudFormation にデプロイし、コンテナの移行をトリガーします。 AWS Lambda 関数が AWS CodeBuild をオーケストレーションし、コンテナ処理を行います。 未アライメントの BAM (unaligned BAM / uBAM) ファイルから Amazon Simple Storage Service (Amazon S3) への入力データフロー。 Amazon CloudWatch によるパイプライン実行のモニタリング。 Amazon EventBridge を用いたイベント駆動のワークフロー管理。 出力用 S3 バケットへの結果の保存。 HealthOmics ツールによるパフォーマンス分析で、コストと利用状況を追跡。 このサーバーレスかつマネージドなアーキテクチャは、運用可視性と最適化機能を備えた、スケーラブルかつコスト効率の高いゲノムデータ処理を提供します。 図 1: AWS HealthOmics WGS パイプラインのワークフローと統合ポイントを示すアーキテクチャ図 大規模運用における AWS HealthOmics 上の PacBio WGS バリアントパイプライン AWS HealthOmics は、パイプラインのデプロイと実行を管理し、インフラストラクチャ、コンテナオーケストレーション、WDL のサポートを担当します。各タスクはカスタマイズ可能なリソースを持つコンテナ化ジョブとして実行され、依存関係の管理、そして AWS Identity and Access Management (IAM) によって権限管理された Amazon S3 でのデータストレージを扱います。ワークフローの入力、出力、ログは、HealthOmics コンソールと Amazon CloudWatch を通じて追跡可能です。 AWS HealthOmics 上の WGS パイプラインのソリューションのデプロイは HiFi-human-WGS-WDL v2.1.2 に基づいており、ゲノム解析への無駄のないアプローチを提供します。CloudFormation ソリューションスタックのデプロイでは、Docker イメージの移行を自動化し、 Amazon Elastic Container Registry (Amazon ECR) のポリシーと HealthOmics ワークフロー用 IAM ロールを設定します。パイプラインは次のステップに従います。 aws-samples リポジトリ の CloudFormation テンプレートは、必要な Docker イメージを適切な権限とともに ECR のプライベートリポジトリへ移行する AWS スタックを構築します。このカスタマイズ可能なスタックは、HealthOmics サービスが必要とする S3 バケットと ECR イメージに対して、最小権限アクセスの原則に沿うよう調整できます。 スタックは Docker イメージの移行に CodeBuild を利用します。パイプライン操作を進める前に、CodeBuild プロジェクトが SUCCEEDED ステータスに達しているかを確認してください。 未アライメントの HiFi BAM ファイルは、Amazon S3 または HealthOmics シーケンスストア に保存します。どちらも互換性がありますが、HealthOmics シーケンスストアはゲノミクス固有の追加機能と、よりよいメタデータ管理を提供します。本実装では、PacBio の リファレンスデータリソース と、検証用の HG002 の公開 HiFi データセットを使用しています。 HiFi-human-WGS-WDL リポジトリをクローンし、Docker イメージが選択したパイプラインバージョンと一致することを確認します (テンプレートは v2.1.2 用に構成されています)。別のバージョンを使う場合は、CloudFormation テンプレート内のイメージハッシュ値を調整してください。バリアント解析パイプラインのワークフローパラメーターを作成するには、 aws-samples リポジトリで提供されているサンプルテンプレートを利用します。 HealthOmics は複数サンプルの並列処理を可能にします。マネージドサービスとして、実行の投入を処理し、通知や下流のパイプライントリガーのために Amazon EventBridge と統合します。Amazon EventBridge ルールの構成例 については、 AWS ブログ を参照してください。 HealthOmics ワークフローは、パイプラインの進捗モニタリングのために CloudWatch と統合されます。ワークフローログは CloudWatch ストリームで確認でき、出力用 S3 バケットへコピーされ、サンプル追跡のために実行 ID ごとに整理されます。 HealthOmics run_analyzer ツールは、サンプル単位で詳細なコストとリソース利用状況の知見を提供し、最適なインスタンスタイプを推奨します。本記事のベンチマーク結果はこれらの分析に基づいています。 aws-healthomics-tools は pypi 経由でインストールするか、後述の手順に従ってください。 HealthOmics プライベートワークフローで PacBio WGS バリアントパイプラインを作成・実行する方法 CloudFormation スタックは、PacBio WGS バリアントパイプライン解析に必要な Docker イメージの作成を自動化します。 PacBio WGS analysis with HealthOmics workflows に記載された手順に従ってください。PacBio WGS バリアントパイプラインのプライベートワークフローを作成する主な手順は次のとおりです。 PacBio リポジトリ から HiFi-human-WGS-WDL v2.1.2 リポジトリをダウンロードするか、 PacBio リポジトリ から任意のバージョンをダウンロードします。バージョンによっては、CloudFormation テンプレートの Docker パスを修正する必要があります。 CloudFormation デプロイの前提条件として、Lambda 関数が操作を実行するための AWS Key Management Service (AWS KMS) キーと、 Amazon Virtual Private Cloud (Amazon VPC) 接続内の 2 つの利用可能なパブリックサブネットを作成する必要があります。ポート 443 経由の HTTPS インバウンドトラフィックを許可する自己参照型のセキュリティグループを作成してください。 パイプラインの評価 実行完了後、 run_analyzer ツールを使用して計算利用状況とコストを評価します。 pip install aws-healthomics-tools aws-healthomics-tools run_analyzer <RUN_ID> -o Pacbio-WGS-run_analyser_outputs.csv エンドツーエンドのパイプライン HiFi 解析のベンチマーク結果 PacBio の公開データセットである HG002 HiFi データセットを用いて、米国東部 (バージニア北部) us-east-1 AWS リージョン における HealthOmics 上でさまざまな最適化戦略を検証しました。WGS バリアント解析パイプラインには、1 CPU から 64 CPU、最大 256 GB の RAM まで、リソース要求が幅広いタスクが含まれます。HealthOmics は計算リソースを動的にプロビジョニングします。最も負荷の高いタスクである DeepVariant によるバリアントコールは、HiFi リードでは 64 CPU と 239 GB RAM を必要とし、GPU アクセラレーションも利用可能です。本ベンチマークでは、タスクアクセラレーターによるコストパフォーマンス最適化と、パイプライン性能に対するストレージタイプの影響に焦点を当て、本番運用に最適な構成の確立を目指しました。 最も要求の高いタスクは、 pbmm2 によるリードアライメントと DeepVariant によるバリアントコールでした。DeepVariant の処理を、複数の GPU アクセラレーター (NVIDIA Tesla T4 (omics.g4)、NVIDIA Tesla A10G (omics.g5)、NVIDIA L4 (omics.g6)) で評価しました。これらは、静的および動的な HealthOmics の実行ストレージ (static / dynamic run storage) を用いた CPU ベースのアクセラレーション (omics.m) と比較してベンチマークしています。 最適な構成は NVIDIA Tesla A10G を搭載した omics.g5.2xlarge で、動的ファイルストレージを利用してパイプラインを 8.67 時間・21.26 ドルの計算コストで完了しました。DeepVariant 用の GPU コンテナは、CPU ベースの構成と比較して 21.3 パーセントのコスト削減と 8.5 パーセントの高速化を実現し、パフォーマンスとコスト効率の両面で明確なメリットを示しました。 ストレージ構成の分析では、NVIDIA Tesla T4 (omics.g4) と L4 (omics.g6) のインスタンスは動的ストレージから大きな恩恵を受ける一方で、標準的な omics インスタンスと Tesla A10G (omics.g5) インスタンスはストレージタイプ間の差がほとんどないことが分かりました。これは、ストレージ最適化戦略をインスタンスごとに検討すべきであることを示唆しています。 HealthOmics の run_analyzer ツールでは、Tesla A10G と静的ストレージの組み合わせで 19.15 ドルまでコスト最適化できる可能性が示されました。この分析により、いくつかのタスクでメモリ割り当てを最適化できる余地があることが明らかになりました。pbmm2 アライナーは 64 GB、DeepVariant の make_examples は 16 GB、pbsv_call は 16 GB、DeepVariant の postprocess_variants は 8 vCPU と 64 GB、hiphase は 32 GB で動作できます。ただし、これらの要件はシーケンシング深度や遺伝的多様性によって変動し得ることに注意が必要です。遺伝的多様性の高い集団では、リファレンスに対して相対的により多くのバリアントが検出される傾向があるためです。特にバリアント数に応じてスケールする場面では、PacBio のデフォルトの計算リソース要件が依然として必須となります。 次の棒グラフでは、分析結果を 3 つのパネルで示しています。実行時間 (時間)、実際のコスト (ドル)、そして run_analyzer の推奨事項を適用した後の最適コスト (ドル) です。NVIDIA Tesla A10G と静的ストレージの組み合わせは、19.15 ドルという最良の最適コストを示すと同時に、8.67 時間という競争力のあるランタイム性能も維持しています。この最適コストは、HealthOmics ツール run_analyzer が推奨する計算構成を用いることで達成可能です。 図 2: AWS HealthOmics 上の WGS バリアント解析パイプラインにおける、アクセラレーター種別とストレージ構成別の価格性能比較 AWS HealthOmics は、ゲノムデータに不可欠な堅牢なセキュリティフレームワークを提供し、HIPAA、GDPR、ISO 27001 などの規制に沿った包括的な対策を実装しています。これには、エンドツーエンドの暗号化、KMS キー、ロールベースのアクセス制御、セキュアなロギングと監査が含まれます。この高度なセキュリティアーキテクチャにより、組織はゲノム解析ワークフローをスケールさせながら、厳格なデータガバナンスとプライバシー基準を遵守できます。これにより、HealthOmics は規制要件を守りつつ、機密性の高いデータを大規模に扱うのに適したサービスとなっています。 まとめ 本分析では、PacBio の HiFi WGS バリアント解析パイプラインを AWS HealthOmics 上に実装し、パフォーマンスとコストの大幅な最適化を達成しました。GPU アクセラレーション、特に NVIDIA Tesla A10G (omics.g5.2xlarge) は、CPU ベースの構成と比較して 21.3 パーセントのコスト削減と 8.5 パーセント高速なパイプライン完了を実現しました。評価では、NVIDIA Tesla T4 と L4 のインスタンスは動的ストレージから恩恵を受け、Tesla A10G はストレージタイプにかかわらず安定した性能を維持することが分かりました。HealthOmics の run_analyzer ツールにより、適切なリソース割り当てを通じて、Tesla A10G と静的ストレージを組み合わせた 19.15 ドルの最適コスト構成を特定できました。HealthOmics のリソースを動的にプロビジョニングする能力と、HIPAA、GDPR、ISO 27001 に準拠した堅牢なセキュリティフレームワークが組み合わさることで、機密性の高いゲノムデータを大規模に処理するのに適しています。これらの知見は、厳格なデータガバナンスとプライバシー基準を維持しながら、効率的でセキュア、かつスケーラブルなゲノム解析ワークフローを実装するための貴重な指針となります。 始め方 PacBio HiFi データを大規模に解析するには、次を参照してください。 PacBio のオープンソース HiFi-human-WGS-WDL パイプライン を活用する AWS HealthOmics がどのようにセキュアかつスケーラブルなゲノム解析を実現するかを学ぶ サポートやカスタマイズされたワークショップのご依頼は、 AWS Genomics チームまでお問い合わせください 著者について Edwin Sandanaraj Edwin は AWS のゲノミクスソリューションアーキテクトです。神経腫瘍学で博士号を取得し、ヘルスケアゲノミクスのデータ管理と解析で 20 年を超える経験を持ち、アジア太平洋・日本地域における精密ゲノミクスの取り組みを加速するために豊富な知見を提供しています。臨床ゲノミクスとマルチオミクスをクラウドベースのソリューションで組み合わせ、精密医療を加速することに情熱を注いでいます。 Charlie Lee Charlie は AWS におけるアジア太平洋・日本地域のゲノミクス業界リードで、バイオインフォマティクスに軸足を置く計算機科学の博士号を持っています。バイオインフォマティクス、ゲノミクス、分子診断で 20 年以上の経験を持つ業界リーダーであり、最先端のシーケンシング技術とクラウドコンピューティングをゲノミクスに活用し、研究の加速とヘルスケアの改善に情熱を注いでいます。 Billy Rowell Billy は PacBio のシニアスタッフバイオインフォマティクスサイエンティストで、遺伝学とゲノミクスの研究に 25 年以上の経験を持っています。バリアントコールと希少疾患研究に向けた高性能計算 (HPC) およびマルチクラウドワークフローの開発をリードしています。 Khi Pin Chua Dr. Khi Pin は PacBio の計算生物学グループのサイエンティストです。彼の仕事は、PacBio の HiFi シーケンシングデータから新しい生物学的知見を引き出すための革新的なツールと解析ワークフローの開発に集中しています。PacBio の最先端のロングリードシーケンシング技術を、特にがんゲノミクスなどの分野で高度なゲノミクス応用に活用する研究者や臨床医の広いネットワークと協働しています。 Rajesh Sukumaran Rajesh は AWS のアジア太平洋・日本地域を担当する HealthTech (ヘルステクノロジー) のシニアパートナーマネージャーです。ヘルスケアとテクノロジーの分野で 20 年以上の経験を持ち、AWS パートナーと協働してヘルスケアの変革を推進するソリューションを提供しています。熱意あるヘルスケア起業家であり、コンピューターエンジニアでもある Rajesh は、INSEAD で MBA を取得しています。 翻訳は Solutions Architect の吉村が担当いたしました。

はじめに こんにちは、ZOZOMO部OMOブロックの宮澤・多田・東谷です。私たちは2026年7月22日（水）・23日（木）の2日間、JPタワーホール＆カンファレンスにて開催された「AI DevEx Conference 2026」に参加してきました。本記事では、会場や各ブースの様子に加え、特に印象に残ったセッションをご紹介します。 目次 はじめに 目次 AI DevEx Conference 2026とは 会場の様子 セッション紹介 Day1（7/22） AIと共存する世界のソフトウェアエンジニアリング─不変の本質とプログラミングの未来 AI時代のプロダクト開発変革をどう進めるか Day2（7/23） なぜ、AIが進化しても期待される生産性を上げることができないのか 『動くだけ』のその先へ ― AI駆動開発で品質と速度を両取りする温故知新な新手法 2026年のソフトウェアエンジニアリングを考える さいごに AI DevEx Conference 2026とは AI DevEx Conference 2026 は、ファインディ株式会社が主催する、AI時代の開発生産性と開発者体験（DevEx）をテーマにしたカンファレンスです。前身の「開発生産性Conference」から名称を改め、MetaやGitHub、Uber、LinkedInなど海外テック企業を含む50社以上から56名を超える方々が登壇しました。 会場の様子 会場のJPタワーホール＆カンファレンスには、Room A〜Dの4つのセッションルームがありました。セッション以外の企画も充実しており、スポンサーブースエリアやポスター展示「AI DevEx Gallery」が設けられていました。さらに、スポンサーブースを回ってスタンプを集めると豪華賞品が当たる「巨大ガチャ」も用意されていました。国内外50社以上が登壇する規模だけあって、2日間を通して4トラックが同時進行し、会場内を回るだけでも熱気が伝わってきました。 JPタワーホール＆カンファレンスの外観 会場入口の「AI DevEx Conference 2026」サイネージ AI DevEx Gallery（ポスターセッション） セッションの合間には、「開発生産性の先・DevEx」に関する各社の取り組みをポスター形式で展示する「AI DevEx Gallery」を自由に見て回ることができました。 KINTOテクノロジーズ 粟田啓介さんのポスター「AI時代に必要な『組織の成果』を作る人材育成」 このほか、Findy Team+によるサイクルタイム短縮事例（360時間→15.7時間）や、楽々明細 植木遼太さんによる「開発チームへの『無駄な依頼』が消えた話」なども展示されていました。各社の現場ならではの実践知が並び、立ち寄るだけでも学びの多いコーナーでした。 スポンサーブース スポンサーブースエリアの様子。各社のブースが並び、多くの参加者が足を止めていました 朝日新聞社は「伝統的新聞社は、AIエージェントで再定義できるのか」というポスター展示を行っていました。創業150周年の100日プロジェクトでCursorのハンズオンに224名が参加し、技術系エージェントの体験率93％、DORA Four Keysのデプロイ頻度+667％という実績が添えられていました。こうした事業会社側のAI活用実績が数多く紹介されていました。スタートアップだけでなく伝統的な大企業でも、AI活用が着実に進んでいることを実感しました。 朝日新聞社の事例ポスター「伝統的新聞社は、AIエージェントで再定義できるのか」 Postman株式会社の「APIテストは何でやっていますか？」「API仕様・ドキュメントはどこに格納していますか？」というシール投票企画も目を引きました。手動やcurl、Postmanでの管理など、テストへの向き合い方は企業によってさまざまでした。 Postman株式会社ブースの様子。「APIテストは何でやっていますか？」等のシール投票企画 また、株式会社カオナビのブースでは「このAIポンコツすぎるな…一体どんな挙動？」というお題で、参加者が実際に困ったAIの挙動を自由に書き込んでいく付箋ボードもありました。付箋には「同じ失敗を繰り返す」「コンテキストが長くなると指示を無視し始める」「気づいたら英語で話している」といった挙動が並んでいました。 「このAIポンコツすぎるな」付箋ボードに寄せられた参加者たちの実体験 真剣な講演の合間にこうした企画があることで、AIとの向き合い方について肩の力を抜いて話せる空気が、会場全体に流れていたのが印象的でした。 セッション紹介 ここからは、特に印象に残ったセッションを紹介します。 Day1（7/22） AIと共存する世界のソフトウェアエンジニアリング─不変の本質とプログラミングの未来 基調講演「AIと共存する世界のソフトウェアエンジニアリング─不変の本質とプログラミングの未来」の登壇の様子 宮澤です。Dave Farleyさんの基調講演「AIと共存する世界のソフトウェアエンジニアリング─不変の本質とプログラミングの未来」を紹介します。 制約理論を引きながら「コードはボトルネックではない（もしそうだったとしても）」と提起するスライド まず、セッションの冒頭で提起されたのが「コーディングはもうボトルネックではない」ということでした。生成AIにより、人間が読み、理解し、検証できる速度をはるかに超えてコードを生成できるようになりました。コードの作成はボトルネックではなく、生成されたものが適切かどうかを素早く検証することが次の最適化ポイントになっているということです。 この前提は、現場のソフトウェア開発に携わる私自身も感じていたものでした。 続いて、セッションの本題に入っていきます。Farleyさんは、プログラミング言語には3つのゴールがあると述べています。 人間が問題についての思考を整理する その理解を他の人と共有する 実行可能な指示としてコンピュータに伝える そして従来のプログラミング言語は、これらのゴールを達成するために3つの技術を採用してきたとしています。 単純で決定論的な形式文法（同じ命令に対して同じ結果が得られる） 意図の曖昧さのない表現 反復可能で決定論的な実行 しかし、AIを活用するようになったことで、これらの技術が機能しなくなり、以下3つの問題が新たに生じたとしています。 意図を正確に指定すること 得られた結果が意図通りかを検証すること 変化し続ける世界に適応するためのインクリメンタリズムを維持すること 例えば、AIに「セキュアなログインページを作れ」とバイブコーディングで指示するだけでは不十分で、具体的にどのような要件を求めているかを開発者が理解して明示する必要があります（1つ目の問題）。さらに、AIが大量にコードを生成できる時代において、すべてのコードを人間が確認するのは不可能です。生成されたコードが意図した要求を満たしているか検証する技術が必要になります（2つ目の問題）。 従来のプログラミングでは、達成しようとしていた実際の成果はコードの中に明示的に入っておらず、開発者の頭の中に暗黙的にあるものでした。これからのAI時代では逆になるとFarleyさんは述べていました。求めている成果は明示的に述べられて検証可能である必要があり、解決策の方が暗黙的になります。プログラミングは解決策を記述することではなく、より精密に成果を定義することになるという主張でした。 なお、Farleyさんはこれらの問題への対処がエンジニアリング思考に依存するとしていました。技術的規律の素養や、問題解決へのシステム思考的なアプローチが引き続き求められます。問題を分解し、要求を検証する能力が必要になるということです。 ここまでの話で、今後必要になるのは「求める成果を、明示的で検証可能な形で定義する」ということでした。その具体的な対応策としてFarleyさんが提唱した方法はBDD（振る舞い駆動開発）でした。達成したい成果を明示的にテスト可能な仕様として指定してAIにこの仕様を満たすコードを生成させるということです。 Farleyさんはこれを「第5世代プログラミング言語」と位置づけていました。パンチカード（第1世代）、アセンブリ言語（第2世代）、高水準言語（第3世代）、4GL（第4世代）に続いて、BDDによる検証可能な仕様が新しい世代の「プログラム」になるとのことです。 このBDDで用いるDSLには、解決策の言語（プログラミング言語）ではなく、問題領域を表す自然言語を使用します。そのため、開発者以外も仕様を読んで理解できるという利点があります。 しかし、コンピュータに指示するには、ユーザー価値以外の観点も必要になります。例えば、システムの応答速度や耐久性、セキュリティなどのアーキテクチャの観点です。Farleyさんは、これらも結局はシステムの振る舞いにすぎないと主張していました。「応答は一定時間内に返る」「送金の過程でお金が消滅しない」のような、非機能要件も同じく仕様として記述できるということです。 そのうえで、アーキテクチャ自体は「進化的アーキテクチャ」のアプローチで扱うことが重要とのことでした。これは、アーキテクチャを前もって固定するのではなく育てていくものとして扱い、決定を「責任を持てる最後の瞬間」まで遅らせ、設計を変更可能な状態に保つアプローチです。この「進化的アーキテクチャ」という用語は本カンファレンスの別セッションでもたびたび耳にするものでした。 この話で印象的だったのが、注意義務（duty of care）という言葉です。ユーザーが求めるものをそのまま叶えるだけでは不十分です。どれだけセキュリティを担保するべきか、どれだけ耐障害性や応答速度を満たすべきかという専門的な判断を持ち込む必要があります。そのうえでAIに対して詳細に指示することが、プロのエンジニアの責務だということです。 セッションの終盤では、冒頭の主張に立ち戻り「コーディングはもはやボトルネックではない。そしておそらく、最初からボトルネックだったことはなかった」と述べていました。これは、コーディングという工程が消えたのではなく、もともと優れたチームと平均的なチームを分けていたのはコーディングの速さではなかったことが、AIによってあらわになったということでした。 大切なのは、問題を深く理解し、ビジネスの文脈とゴールを把握することです。そして、プロダクトの方向性を考え、アーキテクチャの文脈を保つことです。「問題を深く理解し、携わっているビジネスのゴールを本当に理解しない限り、優れたソフトウェアは作れない」。これはAIの有無によらないプログラミングの本質だということでした。 また、「AIは増幅器（amplifier）である」という言葉も強調されていました（この言葉も本カンファレンスの複数のセッションで耳にしました）。AIは高パフォーマンス組織の強みを拡大し、苦しんでいる組織の機能不全も拡大します。AIが到来する前に機能していたやり方は、AI到来後もよりよく機能するということでした。 BDD、継続的デリバリー、進化的アーキテクチャを採用することで、AIの恩恵をより大きく受けられます。Farleyさんはこれを「Back to the future」と表現してセッションを結びました。古くからの実践に立ち返ることが未来への道になるという、温故知新にも通じるメッセージでした。 AI時代のプロダクト開発変革をどう進めるか 多田です。Notion Labs Inc. CTOのFuzzy Khosrowshahiさんの「AI時代のプロダクト開発変革をどう進めるか」を紹介します。 このセッションを聞いて、AIの登場によって開発の焦点が「形にすること」から「何を作るべきか」へと移りつつあるのだと改めて感じました。開発者の業務時間の約47％はコミュニケーションと調整に費やされ、1回のリリースには平均6つ以上のツールが関わっているといいます。この「意思決定の負荷」と「調整コスト」こそが、AIトランスフォーメーションを阻む「組織」「ワークフロー」「システム」という3つの壁の正体だと位置づけられていました。 3つの本質的な問題として挙げられた「個人への依存」「情報の分散」「スケーラビリティ」 エージェントを会社全体に拡張する段階で必ずぶつかるのが、「個人への依存」「情報の分散」「エンジニアリングとスケーラビリティ」という3つの問題だといいます。Notionはこれを理論としてではなく、自分たちが日々どう組織し動いているかという実践の中で解いてきた、というのが本セッションの軸でした。 多くの組織はいまだに年次計画や階層的な承認プロセスで動いています 1つ目、「組織」の壁の答えが JazzMode（ジャズモード） です。Fuzzy Khosrowshahiさんは、あらかじめ計画を立てて演奏するオーケストラと、共通のテーマだけを決めて即興で音を重ねるジャズバンドを対比しました。年次計画や階層的な承認を経てからでないと動けない組織は、オーケストラのように計画通りにしか動けない状態だといいます。JazzModeとは、そこから抜け出し、メンバー一人ひとりに裁量を与えながら信頼をベースに素早く学び動いていく運用リズムのことです。一部の得意な人だけにAIの価値を閉じ込めず、組織全体へ広げる必要があります。そこで、まず動き方そのものを、こうした信頼と裁量にもとづく形へ変えていくべきだという主張でした。AI活用が一部のメンバーに偏りがちな自分たちにとって、身につまされる思いでした。 2つ目、「ワークフロー」の壁の答えが Agent OS です。ツール・コンテキスト・ワークフローが断片化したままでは、AIはその溝を埋めるのではなく同じ断片化を引き継ぐだけだ、という指摘には心当たりがありました。実際、自分たちもSlackの会話とGitHubの記録を別々に探し回ることが多く、AIに聞いてもツールをまたいだ断片的な答えしか返ってこないことがあります。Data Scout、Office Q&Aなどの業務ロールに紐づくエージェントをカタログ化しているそうです。そのうえで「ナレッジを取り込む→答えを見つける→ワークフローを自動化する」流れを1つのAIオペレーションレイヤーとして提供している、と説明されていました。個々のエージェントを点在させず、1つのオペレーションレイヤーとしてつなぎ直すという発想は、ぜひ弊社でも参考にしたいと思いました。 エージェントが、チームと共に動くネイティブ環境を ここで印象に残ったのが、 AIのアクセスの重要性 です。エージェントは支援する相手と同じ「現場レベルの権限」の範囲内で動作します。このアクセス権限管理の正確さがAgent OSの必須要件だと言っていました。権限を与えるのは怖い一方、与えなければ結局人が動かなければならず時間がかかってしまいます。このバランスをどう取るか、自分たちも試行錯誤しているところです。 3つ目、「システム」の壁の答えが Software Factory です。創業者の言葉を引用し、「従来のソフトウェアを作ることは橋を作るようなもの。正しく設計すれば計画通りに作れる。しかしAIでプロダクトを作ることは日本酒の醸造に近い」と説明されていました。橋は設計図さえ正しければ計画通りに完成させられる仕事だが、酒造りは発酵の進み具合を見ながら条件を調整し続ける仕事だ、という説明でした。AIによるプロダクト開発も同じで、最初から完璧な設計図を引くのではなく、条件を整えては様子を見て調整を重ねる進め方に近づいている、ということのようです。醸造そのものも近代化されてきたように、個人の職人技に頼るのではなく、この「調整し続けるプロセス」自体を組織として仕組み化する必要があるという結論を、興味深く感じました。 組織・ワークフロー・システムの3本柱 アメリカの有名テック企業でも、また日本の一部の企業でも、すでにこうした基盤の上でAI時代の運用を築いているといいます。 最終メッセージは「ソフトウェアの次の章は、判断力とコンテキスト、そして新しい形の裁量を組み合わせられる人たちによってつくられる」というものでした。 組織はJazzModeというリズムで、ワークフローはAgent OSという1つのレイヤーで、システムはSoftware Factoryという再現可能な仕組みで支えるという整理でした。この3本柱は、複数チームでAI活用が進む弊社の状況にもそのまま当てはまる示唆だと強く感じています。ぜひ社内でも参考にし、今後のエージェント活用に活かしていきたいと思いました。 Day2（7/23） なぜ、AIが進化しても期待される生産性を上げることができないのか 多田です。2日目の基調講演「なぜ、AIが進化しても期待される生産性を上げることができないのか」を紹介します。登壇者はGitHub, Inc. Business Insights & Research AdvisorのEirini Kalliamvakouさんです。個人レベルではAIが劇的な生産性向上をもたらしている一方、組織全体ではその恩恵が測定できていない、という矛盾がテーマの講演でした。 講演はまず、一見矛盾する「2つの真実」の提示から始まりました。開発者個人のレベルでは、ポジティブな結果が出ていました。GitHub Copilot利用で55％の高速化、開発者の90％以上が毎日AIを使用（DORA 2025）、80％以上が生産性向上を実感といった数字です。一方、組織のレベルでは対照的な結果が示されていました。MIT NANDAレポートでは生成AIパイロットの95％がROIなしで、投資額300〜400億ドルに対し測定可能な成果は限定的でした。400社以上を対象にした別の縦断調査では、AI導入率が65％増えてもスループット向上はわずか8％で、デリバリーの安定性がむしろ低下しているケースもあったそうです。どちらの立場も嘘をついているわけではなく、AIから価値を生むプロセスは個人の加速から組織の成果へ単純には移行しない、というのが講演の出発点でした。 この矛盾を解くカギとして提示されたのが、「システム」「測定」「判断」という3つの複雑さの層です。まず「システム」の層では、ソフトウェア開発が「リレー競技」に例えられていました。一人が55％速く走れても、バトンパスが遅ければチーム全体のタイムは縮まりません。ここでのバトンパスは、レビューやビルド、デプロイ、要件定義といった工程です。開発者の時間のうち、コードを書くことに使われているのはわずか約14％だといいます。 WHAT AMPLIFIES AI – EVERY FACTOR IS TEAM-LEVEL 個人の成果を組織的な成果に変えるには、次の7つの要因が必要になるといいます。いずれも個人の作業環境だけでは完結せず、チームや組織全体で整備すべき条件です。 明確に共有されたAIへのスタンス 健全なデータエコシステム AIがアクセスできる社内データ 強固なバージョン管理の実践 小さいバッチでの作業 ユーザー中心の視点 質の高い社内プラットフォーム 実際、自分たちのチームでもAIによってコーディング自体は明らかに速くなりました。しかし、その分PRの数が増えてしまい、レビュアーの手も回らなくなってきました。しかもAIが書いたコードは一見良さそうに見えるため、かえって読み解くのに時間がかかります。この「バトンの受け渡しが重くなる」現象は、レビューという工程だけでなく、要件のすり合わせのようなより大きな単位でも起きると指摘されていました。講演を聞いて、自分たちの状況にもそのまま当てはまることに気づかされました。 次の「測定」の層では、従来の指標がAI時代のワークフローでは意味を変えてしまっていると指摘されていました。例えばマージ率の低下は「品質の悪化」ではなく、AIで複数の代替案を安価に試す探索的な行動が増えた結果かもしれません。逆にマージ率の上昇も「品質の向上」とは限らず、レビュー不足のまま通してしまっているだけの可能性があります。今後見るべき新しいシグナルとして、3点が挙げられていました。AI活用がワークフロー全体に組み込まれているか、品質を保ったままエージェント起因の成果物の割合が増えているか、エージェントに与えるコンテキストが意図的に整備されているかです。 最後の「判断」の層では、Margaret-Anne Storeyさんの「3つの負債」フレームワーク（技術的負債・認知的負債・意図負債）が引用されていました。そして、スピードの向上が新たな負債を生む構造が説明されました。 組織の基盤とエージェントへの委任度合いによる4象限。右下が「危険な領域」として示されていました 「組織の基盤（FOUNDATIONS）」と「エージェントへの委任度合い（AGENT DELEGATION）」の2軸でマトリックスを作った説明も印象的でした。基盤が強く委任度合いの低い組織は、安全に委任を広げていける「Headroom」の状態にあります。基盤が弱く委任度合いも低い組織は「Slow but safe」で、まず基盤を直すべき状態にとどまります。一方、基盤が弱いまま委任だけを増やす組織は、問題の検知が追いつかなくなる「Danger」に陥りやすいそうです。基盤とセットで委任を進める組織だけが、出力が回を重ねるごとに良くなる「Healthy growth」の複利効果を得られる、という整理でした。 Kalliamvakouさんは最後に、「個人の加速は間違いなく現実であり、素晴らしい出発点です。しかし、真の価値と競争優位性は、システムをどう構築するかにかかっています」と締めくくりました。 「AIは増幅器であり鏡である」という結論は、このカンファレンスを通して一番印象に残ったメッセージだったように思います。個人の生産性指標だけを追うのではなく、組織の「基盤」に投資する必要があるという指摘を、ぜひ社内でも共有し、今後のチーム運営に活かしていきます。 『動くだけ』のその先へ ― AI駆動開発で品質と速度を両取りする温故知新な新手法 speakerdeck.com 宮澤です。株式会社ログラス 執行役員CTOの伊藤博志さんによるセッション「『動くだけ』のその先へ ― AI駆動開発で品質と速度を両取りする温故知新な新手法」を紹介します。 セッションは、2026年2月の3連休にClaude CodeでOLAPデータベースを試作した話から始まりました。OLAPデータベースは集計や分析に特化したデータベースです（本筋ではないので詳細は割愛します）。この試作したデータベースをPolarsやDuckDBといった既存の高速なエンジンとベンチマーク比較したところ、一定の項目で既存エンジンを上回る性能が出たそうです。さらに、集計軸の組み合わせのほとんどに値が入らないスパースデータというユースケースでは、桁違いに速かったとのことでした。ただし、本人も「ユースケースは限定的」と断っており、既存エンジンに全面的に勝った話ではありません。それでも、週末の実験でここまで動くものができてしまう。この事実がセッションの出発点でした。 この開発プロセスは、ビジョンからロードマップを作り、ADR（Architecture Decision Record）で設計を決めるところから始まります。そこから仕様を作って実装し、検証してベンチマークを回すループとして紹介されていました。 続いては、このループの品質担保の方法です。AIの出力の検証はテストで担保することになりますが、出力は確率的なため、「テストを実装したことにする」といった事象も起こり得ます。そこで、仕様とテストと実装をIDで紐付け、その対応をスクリプトで決定論的に検証するという方法が紹介されました。仕様に番号を振り、「この仕様に対応するテストが書かれている」という事実を機械的にチェックする仕組みをとったそうです。 テストの作り方にも原則がありました。テストは仕様書から導出し、実装と同じコンテキストでAIに書かせない、というものです。実装を見ながらテストを書くと、コードの動きをなぞるだけのテストになってしまうからです（こちらは本カンファレンスの基調講演をはじめ、複数のセッションで同様の言及がありました）。 さらに、複雑な仕様には形式手法を適用し、実装前の段階で仕様そのものの矛盾や曖昧さを検証しているとのことです。学習コストの高さがネックになる手法ですが、検証自体はAIが実行するため、導入のハードルは下がったそうです。 検証の道具はもう1つ、オラクルテストです。OLAPデータベースは仕様が広く知られているため、既存のデータベースに同じ入力を与えて結果を突き合わせられます。形式手法が仕様の整合性を担保し、オラクルテストが実装の出力を守る、という役割分担のようです。 ここまでが、冒頭で紹介したOLAPデータベースを試作した方法とのことでした。 続いて、この手法が実際のプロダクト開発で通用するのかという話です。対象に選ばれたのは、既存プロダクトのレポート機能です。データが大きい場合に性能が限界に来ていることを内部で認識しながらも、簡単に直せる規模ではなかったそうです。新しいエンジンを作り、フィーチャーフラグで切り替えられる形にしたそうです。このとき、既存機能がもともとの仕様を体現しているため、それがオラクルになります。既存の挙動をリバースエンジニアリングして仕様書に書き出し、週末の実験と同じループを回したとのことでした。 結果として、第1弾は8日で動くようになったそうです。ただし、品質を担保しきるまでには約2か月かかったそうです。オラクルテストをやり切る過程では、組み合わせが爆発する部分はドメインに詳しい人の目を入れて現実的な範囲に絞り込みながら、バグを出しては直す期間が必要だったとのことです。また、仕様の前提をそろえる議論だけで1か月を使ったとのことで、開発時間の半分以上が品質保証に費やされたと紹介されていました。 印象的だったのは、「仕様が間違っていたら、間違ったものが高速に作られるだけ」という指摘です。どれだけ実装が速くなっても、その仕様は本当に正しいのか、そもそも必要なのかを考える部分は残り、人間はここに一番時間を使うべきだという主張でした。 そしてこの意思決定をどう行っていくかについて、ログラスが現在試行しているのがトレーサビリティを「前」と「後ろ」に伸ばすことだそうです。開発の前にある「なぜ作るのか」「何を作るのか」の探索と、デリバリー後の成果検証までを仕様とつなぎ、当初の仮説が満たされたかを確認できるようにする構想とのことでした。その探索の場面では、AIにドキュメントを生成させるのではなく、インタビュアーとして人間の思考を助ける役割を担わせているとのことでした。 セッションの締めくくりは、タイトルの回収でした。バイブコーディングで、誰でも「動くもの」は作れるようになりました。しかし「正しく動くとは何か」を極め続けると、「そもそも価値があるものを、どうやって作るのか」という問いに行き着きます。AIによって「どのように作るか」のハードルが下がった今こそ、人間は「なぜ作るのか」「何を作るのか」に価値を置くべきだとのことでした。 ここからは私の所感です。 仕様やその検証が重要になるという感覚は、昨今のAIエージェントの進化を見る中で、現場で開発する自分自身も持っていました。このセッションを聞いて、その感覚は確信に変わりました。第1弾が動くまでは8日でも、品質の担保には2か月を要し、仕様の前提をそろえる議論だけで1か月を使っていました。この時間配分が、今後、実装よりも仕様に人間の時間が寄っていくという構図を示しているように思いました。 また、Day1のFarleyさんの基調講演が「求める成果を明示的で検証可能な形で定義する」ことを理論として示したのに対して、このセッションはそれを実プロダクトでやり切った実践例でした。異なる立場の登壇者による理論と実践が噛み合っていたことも印象的でした。 自分の業務に引きつけると、まず試せるのは仕様とテストのID突合だと考えています。スクリプトで決定論的にチェックする部分だけなら、既存のテスト資産にも後付けできそうです。その先では、複雑な仕様のレビューに形式手法を取り入れることも検討します。 2026年のソフトウェアエンジニアリングを考える speakerdeck.com 東谷です。最後に、タワーズ・クエスト株式会社の和田卓人さんによる基調講演「2026年のソフトウェアエンジニアリングを考える」を紹介します。2025年に何が起きたかの振り返りから始まり、開発プロセスの再構築、そして「認知負債」という新しい課題まで、この2日間の総括のような講演でした。 2025年の振り返りはこうです。2月にAndrej Karpathyさんが「Vibe Coding」を提唱し、コードをレビューせず自然言語と動作確認だけで開発するスタイルが広まりました。同時期にTim O'Reillyさんが「私たちの知る形のプログラミングは終わる」と発信しており、開発者の間に期待と緊張が走ったのを覚えています。一方で「AIスロップ」（見た目は整っているのに中身の怪しい生成物）がレビュアーの負担を押し上げ、乗り遅れることへの恐怖が開発者の精神を削った時期もありました。そして11月、モデルの能力がもう一段跳ね上がりました（Claude Opus 4.5が出たあたり、という説明でした）。人間が対話しながら進める「伴走」から、自律的に動くエージェントに任せる「委託」へと開発スタイルがシフトしました。「以前は2分に1回プロンプトを打っていたのが、今は1時間に数回になっていませんか」という問いかけには、大きく共感してしまいました。プランモードで議論して承認したら、40分後に戻ってくればいいという状態が増え、人間がPCの前に張り付く必要は、確かになくなりつつあります。 現在のソフトウェアエンジニアリングは過去の積み上げの上にある 委託型の何が問題かというと、人間のコントロールと状況把握が利きにくくなり、レビューが破綻することです。AIが書いた大量の、自分では書いていないコードを、従来のコードレビューという形式で見続けるのは無理があります。そこで和田さんは、コードレビューが果たしてきた役割を分解し、開発プロセス全体へ再配置することを提案していました。上流の仕様定義を厳密にしてAIの矛盾検出力を活かします。テストを先に書かせて、エージェントが「実装が通るテストを書いて自作自演する」のを防ぎ、型・静的解析・linterといった静的検査で、エージェントのコンテキスト外が壊れても気づけるようにしています。そして全PRを均一に見るのではなくリスクベースでレビューしていました。さらにレビューが担っていた教育の機能は、人間同士のペアプログラミングで意識的に取り戻していました。5つとも明日から検討できる具体的な話でした。 後半の主役は「認知負債」です。保守性の低いコードという従来の技術的負債は、モデルの進化でむしろ改善傾向にあります。代わりに深刻化しているのは、人間が理解しないままコードを生成することで生じる、メンタルモデルと実際のコードの乖離だという指摘です。かつては理解がなければコードは書けなかったので、コードを見ればその人の理解度もある程度推測できたのですが、いまは理解がなくても恐ろしい速さでコードが出てくるので、両者が切り離されてしまいました。しかも理解度を測るメトリクスはまだ存在せず、DORAのFour Keysのような生産性指標は理解を置き去りにしても上げられてしまう構造になってしまっています。見かけの生産性を上げたい組織と個人の間で「共犯関係」が成立しうる、という警告は重く受け止めました。1985年にPeter Naurさんは「プログラミングとは理論（メンタルモデル）の構築であり、それを失ったプログラムは動いていても死んでいる」と書いていました。1983年にはLisanne Bainbridgeさんが「自動化が進むほど人間が介入すべき場面は難しくなるのに、介入するスキルは日常的に使われず失われていく」と指摘していました。40年前の警告が、コードだけが先行して人間の理解がついていかないという反転した形で現実になっている、という整理も見事でした。 「では、どうするか」。和田さんの答えは「理解をゲートにする」でした。ご自身の環境では、プランモードの最後にAIから理解度クイズを出させ、答えられなければ先に進めない仕組みを作っているそうです。 実際に問題を出しているCLIの画面 複雑な実装方針はMarkdownの説明だけでは分かった気になりがちなので、図解やアニメーションのような視覚的な形式で説明させる工夫も紹介されていました。 振る舞いも理解しやすいようにアニメーションをAIに出力させた図 そして重要なのが、理解とスピードはトレードオフではないという話です。講演で紹介された研究では、AIに丸投げしたグループは当たれば最速、外れれば最も遅く理解も残らないという結果でした。一方、AIに説明を求めて質問を繰り返したグループは、スピードをほとんど落とさずに高い理解度を保っていたそうです。 理解とスピードはトレードオフではないと説明する和田卓人さん この話は、私たちのチームの次の一手にそのままつながります。問い合わせ調査のSkill化を進めた結果、調査に必要なクエリの出力も、その検証方法の提示もAIが行うようになりました。次にボトルネックになるのは、まさに人間の理解と検証です。そこで、調査結果と一緒にAIから人間へ理解度を確かめる問題を出してもらう、やったことをHTML形式の図に書き起こして出力してもらう、といった仕掛けを入れていこうと考えています。和田さんの言う「理解をゲートにする」を、コーディングだけでなく運用調査にも適用する形です。「委託が進むほど、理解は意識して守らなければ失われる」という言葉は、まさに2026年後半に向けた宿題でした。 さいごに 今回のカンファレンスで最も印象に残ったのは、立場の異なる登壇者が口をそろえて語った「AIは増幅器である」という言葉でした。AIは導入すれば誰もが等しく速くなる魔法ではなく、強い組織の強みも、苦しい組織の機能不全も、そのまま拡大します。個人がAIで速くなった今、問われているのは、仕様や検証、レビュー、組織の基盤といった「AI以前から大切だったもの」の質なのだと感じました。私たちのチームでも、AIによってコードを書く速度は確実に上がりました。次の課題は、その加速を組織の成果へつなげる基盤づくりです。今回持ち帰った学びを、日々の開発とチーム運営に活かしていきます。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com