はじめに こんにちは、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

はじめに こんにちは、IoT Specialist ソリューションアーキテクトの新澤です。2026 年 6 月 25〜26 日に幕張メッセで開催された AWS Summit Japan 2026 の「生産ラインの未来」ブースでは、AI エージェントが生産ラインのボトルネックを検知し改善策を提案するデモを展示しました。 開催前の予告ブログ ではデモの概要をご紹介しましたが、本記事では展示を終えた今、その実装の詳細を解説します。 このデモのテーマは、「AI エージェントに工場の「構造」をどう教えるか」です。どの製品にどの部品が必要で、どの設備で加工し、どのサプライヤーから調達しているか。こうした関係性が構造化されていなければ、AI は参照すべきデータソースを判断できず、回答が不安定になったり、必要なデータに到達するまでの試行錯誤が増えたりします。本デモではこの関係性をスキーマとして定義し、ナレッジグラフとして実装しました。一方、スキーマだけでは「今」が分かりません。設備のサイクルタイムは今何秒か、現状の設備で増産対応が可能なのか。ここに IoT のリアルタイムデータを接続することで、AI エージェントは構造を知った上で現状を踏まえた判断を行えるようになります。まず、なぜ製造業にナレッジグラフが必要なのかという課題から出発し、グラフスキーマの設計、データストアの役割分担、AI エージェントの推論フロー、全体アーキテクチャの順に解説します。 なお本記事では、製品・部品・設備・サプライヤーといった要素間の関係性をグラフ構造で表現したものを「ナレッジグラフ」と呼ぶこととします。これは OWL や記述論理に基づくいわゆるオントロジー (TBox/ABox による概念公理や自動推論)とは異なり、AI エージェントが「どのデータをどう辿るか」を判断するためのセマンティックなコンテキスト情報として活用することを目的としています。また、本記事で「推論」と呼ぶのは、記述論理（OWL など）による論理推論ではなく、AI エージェント（LLM）がナレッジグラフを文脈として複数のデータソースを横断し、回答を組み立てる処理を指します。 デモ画面:生産ラインのナレッジグラフマップ なぜ製造業にナレッジグラフが必要か 突然の増産指示「来月末までに 300 台追加で出荷できるか?」この問いに答えるには、オーダー → 製品 → 部品 → 在庫 → サプライヤー → 設備稼働と、異なるシステムに散在するデータを横断的に辿らなければなりません。難しいのは個々のデータを取ることではなく、それらのデータ間の依存関係を何段も辿り切らなければならない点にあります。さらに各データは多対多の関係を持ちます。1 つの製品は複数の部品を必要とし、1 つの部品は複数のサプライヤーから調達可能で、1 台の設備は複数の製品の工程に関与します。増産対応に限らず、このような「多段の関係性探索」は製造現場で繰り返し発生します。 特に顕著なのが BOM (部品表) の探索です。BOM はツリー構造で、増産の実現性判断では BOM を順方向に展開して必要部品を洗い出す必要があります。一方、品質問題のトレーサビリティでは逆方向に辿って「この素材を使っている全製品は」を特定します。設計変更の影響確認でも同様です。しかも構成が何階層あるかは製品ごとに異なるため、探索の深さを事前に固定できません。本デモでは以下の 3 階層の BOM を定義しました (来場者の方から「うちは 100 階層を超える」という声もいただきました) 。 SD1 圧力センサーモジュール (完成品) ├── センサーユニット (サブアセンブリ) │ ├── セラミック圧力センサー素子 │ └── 配線ハーネス ├── 駆動ユニット (サブアセンブリ) │ ├── ブラシレスモーター ×4 │ └── モータードライバ IC └── フライトコントローラー 「300 台増産できるか」の判断には、部品ツリーを最下層まで展開し、在庫・リードタイム・設備の稼働状況を確認する必要があります。RDB では構成表テーブルを何段階も繰り返し結合して検索するため、部品が増えるほど処理が重くなります。一方、ナレッジグラフなら階層の深さに関わらず 1 行のクエリで記述でき、順方向・逆方向の検索もまったく同じ構文で対応できます。 // 順方向: 増産に必要な全部品を展開 g.V('PROD-SD1').repeat(out('REQUIRES')).emit().valueMap('name') // 逆方向: 不良素材の影響を受ける全製品を特定 g.V('PART-CERAMIC-001').repeat(in('REQUIRES')).emit().valueMap('name') ナレッジグラフの利点は、探索の書きやすさだけではありません。ユーザーにとって直接的なメリットが 2 つあります。 1 つはコストです。グラフ探索は問いに関係するサブグラフだけを返すため、テーブルや文書を丸ごと LLM のコンテキストに渡す必要がなく、消費トークンを抑えられます。またグラフが「次にどこを見るべきか」を示すため、エージェントが無関係なデータソースを探索して往復する無駄も生じません。もう 1 つは回答の信頼性です。エージェントは LLM の記憶ではなく、グラフに格納された検証済みの関係を根拠に回答を組み立てます。ナレッジグラフによる知識の裏付けがハルシネーションの抑制に有効と考えられます。 ここからは、これらの利点を実際のデモでどう形にしたかを解説します。 グラフスキーマの設計 まずは、AI エージェントに接続したデータソースと、その関係性を定義したグラフスキーマの設計から解説します。 デモで用意したデータソース AI エージェントが増産の実現性を判断するために、以下のデータソースを用意しました。 生産オーダー (Amazon DynamoDB) : どの製品をいつまでに何個作るかを管理します。本デモでは「SD1 圧力センサーモジュール 300 台、納期 7/10」のオーダーを投入しています。 BOM — 部品表 (Amazon Neptune ナレッジグラフ) : 製品に必要な部品の構成を定義します。前セクションで示した 3 階層のツリー(完成品 → サブアセンブリ → 部品)が REQUIRES エッジとして格納されています。 在庫 (Amazon DynamoDB) : 各部品の現在の在庫数量と安全在庫を保持します。例 : セラミック素子 10,000 個、ブラシレスモーター 30,000 個。 サプライヤー (Amazon Neptune ナレッジグラフ + Amazon DynamoDB) : 部品と調達先の対応関係は SUPPLIED_BY エッジとしてグラフに、リードタイムや最小発注数量などの値は Amazon DynamoDB に持たせています。例: セラミック素子は LT 14 日、ブラシレスモーターは LT 21 日。 設備稼働データ (AWS IoT SiteWise) : 各ステーション(受入検査、搬送、自動倉庫、加工、組立、出荷)のリアルタイムなサイクルタイムと稼働率を 1 分間隔で収集しています。Amazon Neptune の Equipment ノード ID と AWS IoT SiteWise のアセット ID を共通化しているため、グラフ探索で特定した設備の最新値を、ID 変換なしにそのまま取得できます。 工程設計書・FMEA (Amazon Bedrock Knowledge Bases) : 各工程の加工条件や運転手順を記述した工程設計書(Word ファイル)、FMEA(Excel ファイル)、PLC コーディング規約(Word ファイル)などのドキュメントを RAG 検索可能にしています。 グラフスキーマの全体像 本デモでは「増産オーダーの実現性診断」を頻出ユースケースとして特定し、そのグラフ探索パス (オーダー → 製品 → 部品 → 設備) を専用ツールとして事前実装しました。ユースケースに登場するエンティティをノード、関係をエッジとして Amazon Neptune に格納し、鮮度の高いデータ (サイクルタイム、在庫数量等) は IoT サービス群や Amazon DynamoDB に分離しています。静的な構造と動的な値を分けることで、レスポンス速度と回答精度を安定させることを目指しました。 しかし、現場では設備起点の問いも発生します。デモでは「オーダー起点で、影響する設備を探しに行く」パスを実装しましたが、現場ではその逆方向、設備で異常が起きたときに「何に影響するか」を知りたい場面が日常的に発生します。「焼成炉の温度が基準を超えた。この設備が停止したら、どの製品の出荷が遅れるか?」、「切削精度の劣化が検出された。同じユニットを使う他ラインの品質にも影響するか?」。これらはグラフ上の同じデータ構造を起点を変えて辿るだけなので簡単な話ですが、事前に定義した固定的な探索パスだけではカバーできません。なので実運用では頻出パターンは専用ツール (固定探索) で高速かつ安定した回答を返し、それ以外の問いには汎用グラフ探索 (LLM がノードの隣接関係を見て自律的に辿る方式) をフォールバックとして組み合わせるハイブリッド構成が現実的ではないかと考えています。 以下は、今回作成したグラフの全体像です。 本デモで定義したグラフスキーマ 本デモでは、グラフの実装基盤として Amazon Neptune を採用しました。Amazon Neptune 上に以下の 8 種類のノードと 10 種類のエッジを定義しました。以下は本ナレッジグラフのスキーマ (型定義) であり、実際の工場データ (インスタンス) はこの型に沿って格納されます。 ノードタイプ (8 種類) No. ノード 説明 例 1 Company 企業 AnyCompany 2 Factory 工場 Plant 02 横浜 3 Equipment 設備・ライン Production Line, Warehouse Station 4 SubUnit 設備内サブユニット Furnace Unit, Milling Machine 5 Product 製品 AnyCompany-SD1 6 Part 部品 セラミック圧力センサー素子 7 Supplier サプライヤー セラミック素材社 8 ProductionOrder 生産オーダー ORDER-2026-06-001 エッジタイプ (10 種類) No. エッジ 関係性 意味 1 CONTAINS Company → Factory 企業が工場を所有 2 HAS_EQUIPMENT Factory → Equipment 工場が設備を保有 3 HAS_SUBUNIT Equipment → SubUnit 設備がサブユニットを持つ 4 REQUIRES Product → Part 製品が部品を必要とする(BOM) 5 SUPPLIED_BY Part → Supplier 部品の調達先 6 STORED_AT Part → Equipment 部品の保管場所 7 PROCESSED_AT Part → Equipment 部品の加工場所 8 ASSEMBLED_AT Part → Equipment 部品の組立場所 9 PRODUCES ProductionOrder → Product オーダーの生産対象 10 EXECUTED_ON ProductionOrder → Equipment オーダーの実行設備 ISA-95 との対応 本デモのグラフモデルは、製造業の国際標準である ISA-95 の設備階層モデルと以下のように対応しています。 No. ISA-95 レベル 本デモのノード 説明 1 Level 4 — Enterprise Company ビジネス計画、オーダー管理 2 Level 4 — Site/Plant Factory 工場単位の生産管理 3 Level 2〜3 — Area/Work Cell Equipment 製造実行・各ステーション制御 4 Level 0〜1 — Control Module SubUnit 個別機器の制御 5 (サプライチェーン) Supplier, Part, Product, ProductionOrder ISA-95 外のビジネスエンティティ 本デモでは簡略化を目的として ISA-95 の Level 2〜3 を Equipment ノードに統合しています。実規模の適用時には、Work Center / Production Line / Work Unit を分離し、より詳細な階層を定義することも可能です。 ここまでで、グラフに格納する「構造」の設計を解説しました。一方、「グラフの全体像」で触れたとおり、鮮度の高いデータはグラフの外に置いています。次のセクションでは、この静的な構造と動的な値の分離を、データストアの役割分担として具体化します。 データストアの役割分担 本デモでは、データの特性に応じて 4 つのデータストアを使い分けています。 No. データストア 格納するもの 更新頻度 1 Amazon Neptune 静的な関係性 (BOM、設備構成、サプライヤー依存) 構造変更時のみ 2 AWS IoT サービス群 各設備のリアルタイム稼働データ (サイクルタイム、稼働率) 1 分間隔 3 Amazon DynamoDB 業務マスタデータ (生産オーダー、在庫、BOP) 日次〜週次 4 Amazon Bedrock Knowledge Bases 非構造化ドキュメント (工程設計書、FMEA、PLC コーディング規約) ドキュメント改訂時 データの置き場所が定まったところで、次は AI エージェントがこれらのデータソースをどのような順序で参照し、回答を組み立てるのかを、実際の問い合わせを例に見ていきます。 AI エージェントの推論フロー 「300 台増産は間に合う?」への回答プロセス AI エージェント (Amazon Bedrock AgentCore 上で動作) がユーザーからの問いに答えるプロセスを見てみます。ユーザーが「ORDER-2026-06-001 の増産 300 台は実現可能ですか?」とプロンプトウインドウに入力します。このとき、エージェントは以下の 5 つのステップを実行します。 Step 1 — ナレッジグラフ探索 (Amazon Neptune) オーダーを起点に、ノードタイプごとに異なる情報を収集しながら関係性を辿ります。 ProductionOrder (ORDER-2026-06-001) │ → 数量: 300台、納期: 7/10 │ ├─PRODUCES→ Product (AnyCompany-SD1) │ │ │ ├─REQUIRES→ Part (セラミック素子) │ │ ├─SUPPLIED_BY→ Supplier (セラミック素材社, LT:14日) │ │ ├─STORED_AT→ Equipment (Warehouse Station) │ │ └─PROCESSED_AT→ Equipment (Production Line) │ │ │ ├─REQUIRES→ Part (ブラシレスモーター) │ │ ├─SUPPLIED_BY→ Supplier (モーター工業, LT:21日) │ │ └─ASSEMBLED_AT→ Equipment (Assembly Line) │ │ │ └─REQUIRES→ Part (フライトコントローラー) │ ├─SUPPLIED_BY→ Supplier (エレクトロニクス社, LT:30日) │ └─ASSEMBLED_AT→ Equipment (Assembly Line) │ └─EXECUTED_ON→ Equipment (Production Line, Assembly Line) 1 回の探索で以下が判明します: 部品 3 種 とそれぞれの所要数・リードタイム サプライヤー 3 社 と最小発注数量 関連設備 3 台 の ID(= AWS IoT SiteWise アセット ID) 各ノードに到達するたびに、次のステップで必要な情報 (ID、属性値) が揃います。Part ノードからは在庫確認 (Step 3) に進み、Equipment ノードからはリアルタイムデータ取得 (Step 2) に進みます。グラフが「次にどのデータソースを見るべきか」を教えてくれる構造です。 Step 2 — リアルタイムデータ取得 (AWS IoT SiteWise) Step 1 で特定した設備の ID (= AWS IoT SiteWise アセット ID) を使い、各設備の現在のサイクルタイムと稼働率を取得します。Amazon Neptune のノード ID と AWS IoT SiteWise のアセット ID に同じ UUID を使用しているので、Amazon Neptune のグラフ探索で特定した設備のノード ID を、そのまま AWS IoT SiteWise の API パラメータとして渡しています。別途マッピングテーブルを参照する必要がなく、グラフの探索結果が即座にリアルタイムデータの取得キーになります。関係性は頻繁には変わりませんがサイクルタイムは 1 分ごとに変わり、在庫数量は日々変動します。こうした鮮度の高いデータはそれぞれに適したデータストアに置き、必要なときに ID をキーにして参照するようにしています。 AWS IoT SiteWise 側のアセット階層: AnyCompany (企業) └── Plant 02 横浜工場 └── Line A ├── DSI (受入検査) assetId: d0754657-... ├── VGR (搬送ロボット) assetId: 787a70d9-... ├── HBW (自動倉庫) assetId: 58f6c640-... ├── MPO (加工機) assetId: 2b326756-... ├── FA (最終組立) assetId: 2c26ccc0-... └── DSO (出荷) assetId: d38bb203-... 各アセットは avg_mct (平均サイクルタイム) と Availability_Pct (稼働率) のプロパティを持ち、1 分間隔で更新されます。Step 1 で特定した設備の ID で問い合わせた結果、HBW のサイクルタイムが目標値 (60秒) の 3 倍に達していることが判明します。 Step 3 — 在庫照合 (Amazon DynamoDB) Step 1 で特定した部品の ID を使い、Amazon DynamoDB の在庫テーブルから現在の数量を取得します。BOM の所要数 (×300 台) と比較した結果、在庫は充足していると判断されます。 No. 部品ID 部品名 在庫 所要数 (×300台) 判定 1 PART-CERAMIC-001 セラミック圧力センサー素子 10,000 300 ✓ 十分 2 PART-MOTOR-001 ブラシレスモーター 30,000 1,200 ✓ 十分 3 PART-FC-001 フライトコントローラー 10,000 300 ✓ 十分 Step 4 — 統合判定 Step 2 (設備) と Step 3 (在庫) の結果を突き合わせ、生産能力を評価します。 ボトルネック: VGR + HBW (実測 CT 254.2 秒。タクトタイム 60 秒の約 4.2 倍、稼働率 35%) 在庫リスク: なし (全部品十分) 問題の所在: 部品は足りているが、HBW の処理能力がライン全体のスループットを制約している Step 5 — 自然言語で報告 エージェントが上記を統合し、以下のように自然言語で回答します。 思考過程 ・ユーザーは「ORDER-2026-06-001 の増産 300 台は実現可能ですか?」と聞いています。これは増産指示の実現性診断を求める質問です。 ・生産オーダー情報を取得します。製品名、数量、納期、ステータスを返します。 ・get_production_order 完了 (0.2s) ・Neptune ナレッジグラフを探索して、指定オーダーの影響範囲とボトルネックを検出します。オーダーから製品→部品→設備→サプライヤーの関係性を辿り、在庫不足やサイクルタイム超過を自動検出します。 ・neptune_impact 完了 (0.3s) ・Production Line のリアルタイム稼働データを一括取得 ・get_production_line_metrics 完了 (3.5s) ・部品の在庫情報を取得します。在庫数、安全在庫、リードタイム、サプライヤーを返します。 ・get_inventory 完了 (0.1s) 回答 ■ 影響範囲 (サプライチェーン探索結果) ・対象オーダー: ORDER-2026-06-001(AnyCompany-SD1 ドローン用圧力センサーモジュール 300台、納期 2026-06-13) ・製品: AnyCompany-SD1 ドローン用圧力センサーモジュール ・生産工場: 横浜工場 ・既存バックログ: 200台(合計処理必要数: 500台) ・必要部品と数量: セラミック圧力センサー素子×300、ブラシレスモーター×1,200、フライトコントローラー×300 ■ ボトルネック検出(リアルタイムデータ) ・VGR+HBW(搬送＋自動倉庫): CT 254.2秒(タクト60秒を194.2秒超過、424%)、稼働率 35.0% ・ライン実効CT: 254.2秒/個(ボトルネック律速) ・日産能力: 39台/日 ・5日間生産可能数: 195台 → 横浜工場ダッシュボードで確認 ■ 在庫状況 ・全部品充足(セラミック圧力センサー素子 10,000個、ブラシレスモーター 30,000個、フライトコントローラー 10,000個) ■ 実現性判定 ・間に合いません:5日間で195台しか生産できず、300台に105台不足 ・既存バックログ200台を含めると合計500台必要。達成には13日(約2週間)必要 ・ボトルネックの搬送＋自動倉庫工程(VGR+HBW)がタクトの4.2倍、稼働率も35%と低い 改善策を提案しますか? 参照データソース ・DynamoDB: 生産オーダーテーブル(ORDER-2026-06-001) ・Neptune: ナレッジグラフ(オーダー→製品→部品の関連) ・IoT SiteWise: 横浜工場 Production Line のリアルタイムデータ(サイクルタイム、稼働率) ・DynamoDB: 在庫テーブル(部品在庫状況) (グラフ上で6ノードをハイライト中) なお、この後に続く改善策の提案 — 工程設計書や FMEA を根拠とした運転方法の変更案、PLC プログラムの修正案の生成 — も本デモの見どころですが、紙幅の都合により本記事では割愛します。 全体アーキテクチャ ここまで、ナレッジグラフの設計と AI エージェントの推論フローを解説してきました。このセクションでは視点を引いて、工場の設備からデータを収集し、エージェントが推論するまでを支えるシステム全体の構成を説明します。 本デモは、エッジ (工場) ・IoT データ収集・AI エージェントの 3 レイヤーで構成されています。工場側では 2 系統のデータ経路を持ちます。設備データは PLC → OPC UA サーバー → AWS IoT Greengrass → AWS IoT SiteWise という経路で収集されます。OPC UA は設備のリアルタイム値だけでなくアセット階層(設備間の親子関係や型定義)も標準化された形で公開するため、AWS IoT SiteWise 側でデータストリームとアセット階層の両方を構造化して管理できます。カメラ映像は別系統で、ONVIF 対応カメラ → Raspberry Pi 上の AWS IoT Greengrass → Amazon Kinesis Video Streams に送信されます。カメラの PTZ 制御は AWS IoT Core 経由の MQTT で行い、AI エージェントから操作可能です。 AI エージェントレイヤーでは、Amazon Bedrock AgentCore 上で Strands SDK ベースのオーケストレーターが動作し、問いの種類に応じて専門サブエージェントに処理を委譲します。本記事で解説した実現性診断のフロー (Step 1〜5) は Production Analyst が担当し、カメラ映像による現場確認は Camera Inspector、FMEA など品質文書の参照は QA Manager、制御プログラムの変更案生成は PLC Engineer が担います。各サブエージェントは Amazon Neptune (ナレッジグラフ探索)、AWS IoT SiteWise (リアルタイム値取得) 、DynamoDB (BOP・在庫・オーダー) 、Amazon Bedrock Knowledge Bases (工程設計書・FMEA) 、Amazon Kinesis Video Streams (映像フレーム取得) にアクセスします。 以上が本デモの技術的な全体像です。最後に、実際にブースで来場者の方々と対話する中で見えてきた、実運用に向けた課題を考察します。 全体アーキテクチャ お客様の声と課題 AWS Summit Japan 2026 のブースで製造業のお客様から得たフィードバックのうち、特に多かった 3 点と現時点での見解を共有します。 「関係性を最初に定義するのが大変だ」 — 本デモでは生成 AI に グラフスキーマの定義 を依頼し、一括で生成することで対応しました。「増産診断」というユースケースが明確だったため、必要な関係性の範囲を絞れたことが大きいです。ただし、対象範囲やノード数が拡大した場合に同じ手法でスケールするかは検証が必要です。 「グラフのメンテナンスが大変では?」 — ブースでは「BOM 階層が 100 近くある」という声も戴きました。本デモは数十ノード程度の規模であり、そうした現実のスケールでの変更管理、例えば ERP マスタ変更をイベント駆動で Amazon Neptune に反映するパイプラインなどは今後取り組む必要があります。 「そもそもデータが揃っていない」 — AI エージェント活用デモの多くは参照先データが整備済みの前提で構築されており、本デモも例外ではありません。ただ、本デモは全データをグラフに集約せず、グラフ・IoT・DynamoDB・ドキュメントをそれぞれ別のツールとしてエージェントに持たせる構成にしています。この形だと、新しいデータソースが用意できたときに既存の構成を作り直さず、ツールを 1 つ足すことで対応できます。全体が揃うのを待つのではなく、まず 1 ユースケースに必要なデータから始めて、揃った分だけ段階的に足していく進め方も、選択肢としてあり得るのではないかと考えています。 まとめ 本記事では、AWS Summit Japan 2026「生産ラインの未来」ブースで展示したデモの技術詳細として、製造ドメインのグラフスキーマの設計と、そこに IoT データを接続する方式を解説しました。取り組んだのは「AI エージェントに工場の構造をどう教えるか」というテーマです。製品・部品・設備・サプライヤーの関係を型とエッジとして定義し、Amazon Neptune 上のナレッジグラフに実装しました。サイクルタイムや在庫といった鮮度の高いデータはグラフに持たせず、AWS IoT SiteWise や Amazon DynamoDB から必要なときに参照します。変わりにくい構造と、刻々と変わる値を分けることで、エージェントの回答を速く安定させることを目指しました。一方で、本デモで定義したのは、型（ノード）と、型の間にどの関係が張れるかまでで、その関係自体が従うルールは定義していません。次のステップとして考えられるのは、こうしたルールを RDF/OWL のような形式で記述し、オントロジーへと発展させることです。明示的にリンクを張らなくても不良素材から影響製品を辿れたり、データの矛盾を自動で検出できたりと、対応できる範囲を広げられると考えています。本記事が、製造業のお客様が自社のデータを AI エージェントで活かすための一歩として、参考になれば幸いです。 使用サービス Amazon Neptune — 製造ドメインのナレッジグラフ Amazon Bedrock / Amazon Bedrock AgentCore — AI エージェントの推論基盤 Amazon Bedrock Knowledge Bases — 工程設計書のドキュメント検索 AWS IoT Greengrass — エッジゲートウェイ AWS IoT Core — デバイス接続 AWS IoT SiteWise — 設備稼働データの構造化・蓄積 Amazon Kinesis Video Streams — 工場カメラ映像の管理 Amazon DynamoDB — 生産オーダー・在庫・BOP の格納 著者 新澤 雅治 (Masaharu Niizawa) — IoT Specialist Solutions Architect。製造業、IT 企業を経て AWS に入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 松永 充弘 (Mitsuhiro Matsunaga) — Senior Solutions Architect。製造業のお客様を担当するソリューションアーキテクト。クラウド × データ × AI でお客様のビジネスを支援。前職では製造業にて、機器の IoT 化、AI 活用を担当。 関連リンク AWS Summit Japan 2026 ブース紹介 生産ラインの未来 Amazon Neptune — 概要 Amazon Bedrock AgentCore — 概要 AWS IoT Core ー 概要 AWS IoT Greengrass ー 概要 AWS IoT SiteWise — 概要

はじめに ITD2-2-3のI.Hです。今回、RubyKaigi 2026 in 函館に参加する機会をいただきました。 RubyKaigiは、Ruby本体やエコシステムに関する最新の知見が集まる技術カンファレンスです。 今回の参加を通して、Rubyそのものについて学べたのはもちろん、他社エンジニアとの交流やスポンサーイベントでのLT登壇など、普段の業務だけでは得られない多くの経験をすることができました。 この記事では、Rubyに関する知見の共有だけでなく、技術イベントに参加すること自体の意味や価値についてもあわせてまとめました。 Day0(イベント前日) 函館に前日入り 場所が北海道の函館と言うことで、当日出発では間に合わないため前日の夜に出発しました。 空港に到着すると、空港の至る所にRubyKaigiの看板や垂れ幕がありました。 また、路面電車の車内外にもRubyKaigiの看板が。町おこしさながらの盛り上がりでした。 空港で明らかにrubyistの方（第一rubyist）を見かけたので、タクシーに相乗りしました。 有名なラーメン屋さんで降りるとのことだったので、一緒に食べながら技術の話やお互いの会社の制度・AIツールの導入状況などに花を咲かせました。 Day1 会場へ 会場は、JR函館駅から市電で30分ほどの場所にある「 函館サーモン・まるなまアリーナ/ホール 」でした。命名権を地元の水産会社が取得されたらしく、函館感全開の良い会場名とロゴになってました。 チェックインすると、首から掛けるストラップと名札をいただきました。 会場で「どこの会社の方ですか？」と度々聞かれるので弊社のロゴを手書き。 なんとか伝わりました。 基調講演 The Journey of Box Building 発表資料はこちら 初日の講演は、rubyコミッターでもある田籠 聡さんの基調講演から始まりました。 内容は、2025年12月25日にリリースされた  Ruby4.0.0  の新機能の一つである、 Ruby::Box  についてでした。 Ruby Boxはクラス等の定義の分離／隔離のための機能を提供する、実験的機能です。 実験的な機能として位置付けられているとのことでしたが、安全にコードの分離ができるようになる点は業務にも活かせそうでした。 Exploring RuboCop with MCP 発表資料はこちら Keynote以外の公演は基本的に大ホール・小ホール・サブアリーナで行われ、同時刻に開催される講演に同時に参加することはできないため、タイムスケジュールと発表内容を見て選ぶ形式でした。 英語での講演も多く、同時翻訳アプリで聴くことにも挑戦しましたが、やはり日本語の講演の方が理解しやすく、自然と日本語の講演を選ぶことが多かったです。 そんな中で、初日の午後に参加した伊藤浩一さんの RuboCop  x MCPの話が印象に残りました。 RuboCopは人間や他のプログラムによってトリガーされていました。AI時代においては、AIエージェントが新たなトリガーとして登場しました。本講演では、生成型AIとリンターおよびフォーマッターを組み合わせる実践的な方法について議論します。 決定性がLinterとしての価値だった中で、非決定性を持つLLMを組み合わせることでどんな価値が創出できるのか（又は失われるのか）という試行錯誤の話が面白く、こういったイベントに参加して直接コミッターの方のお話を聞く醍醐味だと感じました。 Day2 基調講演 Twenty Years of JRuby 2日目は20年以上 JRuby （Java仮想マシン上で動作するRubyの処理系）を開発している、Charles Nutterさんの基調講演から始まりました。 内容はJRuby が誕生してからの20周年の振り返りと、JRuby 10.1 のリリースについてでした。 業務を含めこれまでCRuby（C言語で実装されたRubyの処理系）しか触ったことがなかったのですが、JRubyやMRubyのような別の処理系にも興味が湧きました。 Practical TypeProf: Lessons from Analyzing Optcarrot 発表資料はこちら 2日目は TypeProf 開発者の 遠藤侑介さん の講演が印象に残りました。 メインの話は、TypeProfを実際に適用してみた事例です。題材に選ばれたのは、発表者自身が開発したRubyで書かれたNES（ファミコン）のエミュレータで、約6000 行の複雑なコードに TypeProf を適用したところ600個以上のエラーが出たとのことです。 対応としては、型推論結果に強く影響する箇所にRBSを書くことと、TypeProf 側の誤認識の根本原因を直すことの2方向から進められ、最終的には Ruby 55行＋RBS 67行、合計122行の変更でゼロエラーに到達したとのことでした。SteepやSorbetと比べても、既存コードへの変更量がかなり少ないという結果でした。 終盤では、AI コーディングエージェントが普及する中でTypeProfをどう位置づけるのか、という問いも提示されていました。エディタ支援を主目的としてきたツールが、AI 時代にどんな価値を持てるのかという点についても言及されていました。 Day2の交流会 2日目の夜は、Drink Upに参加し、LT枠が空いていたので発表しました。 3日目のRubyKaigiがより面白く聞けるようにと思い、Rubyが実行されるプロセスをParserの話からGCの話まで、一通りまとめてみました。 資料は marp  + Opus4.6で作成 Day3 Lightning-Fast Method Calls with Ruby 4.1 ZJIT 発表資料はこちら RubyKaigi最終日は、 国分崇志 さんのZJITの講演が印象に残りました。 注目度の高い ZJIT ですが、今回の発表では特にメソッド呼び出しの高速化に焦点が当てられていました。 Rubyでは依然としてメソッド呼び出しのオーバーヘッドが大きく（動的型付けだから仕方ないが）、YJIT によって改善が進んできた現在でも、なお大きなボトルネックとして残っているそうです。ZJIT ではこの処理の最適化が大きなテーマになっており、バックトレースや例外処理、ローカル変数アクセスに必要なメタデータをどう保持しつつ、無駄なメモリライトを減らすかが論点になっていました。 そこで紹介されていたのがLightweight Framesでした。これは、メソッド呼び出し時に必要なフレーム情報を最初からすべてメモリに書き込むのではなく、必要になるまで遅延させ、まずは最小限の情報だけを持つことでコストを下げるアプローチです。 Rubyの柔軟な書き心地は維持しつつ、高速に動くようにしていく取り組みをしていただいてる事に感謝です Matz Keynote もちろん最後は、Rubyを作った「 まつもと ゆきひろ 」さん（Matz）の基調講演でした。 ここ半年くらいは自分でコードを書かずに、ほぼ全てAIに書かせるという縛りを自らに課しているとのことでした。コードレビューやプロンプトを細かく制御できるからこそできる事だと思いますが、実務の現場でもAIエージェントは欠かせない存在になってきているのではないでしょうか。 そんな中で大きなトピックは、新しいRubyのAOTコンパイラ「 Spinel 」の発表です。RubyコードをC言語に変換してからコンパイルすることで、ネイティブバイナリを生成するという試みで、すぐに業務レベルで役立てられるものではなさそうですが、インタプリタ言語×AOTコンパイルという発想と開発過程が興味深かったです。（Rubyは動的機能が多いので、機械語にできる=高速化ではないことに注意してください） まとめ RubyKaigiに行って良かったと思う1番のポイントは、Rubyやプログラミングが大好きな人達の「熱」を感じられたことでした。普段「仕事」としてプログラミングをしていると商業的な観点で価値を測り測かられる癖がついてしまって、楽しいとか知的探求という側面を忘れていたなぁと思いました。 また、現地での他社のエンジニアとの交流も刺激的でした。今まで自分がマイナビ色に染まっている自覚はありませんでしたが、他社のエンジニアと交流すると明らかに各社個性というか雰囲気があって、たまには視野を広げるためにも交流して新しい知見を持ち帰ってくる必要があると感じました。