2026 年 8 月 3 日週、私たちは世界中から集まった AWS ヒーローたちを集め 、つながり、協力し、AWS コミュニティでこれまで以上に活躍したビルダーを祝いました。 AWS Heroes Summit は招待制の年次集会で、AI、サーバーレス、コンテナなどの分野を専門とする世界中の専門家が一堂に会し、社内の AWS 製品およびサービスチームとの直接のコラボレーション、技術的な詳細調査、フィードバックセッションを行います。 1日目は、AWS の CEO、マット・ガーマンによる心に響く暖炉辺談話から始まります。2 日目の James Hamilton との洞察に満ちた AMA から、新しいアイデアを呼び起こすさまざまな製品チームによるブレイクアウトセッションまで、AWS ヒーローたちは知識を共有し、お互いを高め、会話をコラボレーションに変えることに長けていました。詳細については、 LinkedIn で参加者からのフィードバックをご覧ください 。 8 月 3 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Bedrock でのウェブ検索 ：Amazon Bedrock では、OpenAIモデル (GPT-5.4、GPT-5.5、GPT-5.6 Sol/Terra/Luna) がインターネットから情報を閲覧したり取得したりできるようになりました。これにより、AIアプリケーションはトレーニングデータ以外の最新情報にアクセスできるようになりました。この機能により、リアルタイムのウェブコンテンツを使用して質問に回答できる AI エージェントとアプリケーションを構築する新たな可能性が開かれます。また、データの流出は発生せず、安全な AWS 環境内にデータを保存できます。開始するには、 AI ブログ投稿 および Amazon Bedrock ユーザーガイド をご覧ください。 Amazon Bedrock AgentCore のランタイムインスタンス ：Amazon Bedrock AgentCore を介して専用のランタイムインスタンスに AI エージェントをデプロイして実行できるようになりました。これにより、パフォーマンスとコストを予測可能な状態でエージェント実行環境をより細かく制御できるようになりました。開始するには、 Sébastien のブログ投稿 および AgentCore documentation をご覧ください。 Amazon DynamoDB のベクトル検索 ：個別のベクトルデータベースを管理しなくても、ベクトル埋め込みを既存のデータと一緒に DynamoDB に保存してクエリできます。DynamoDB はすでに AI エージェントのメモリ保存をサポートしていますが、ベクトル検索では、そのメモリにセマンティック検索を追加してエージェントのグラウンディングを行うことができ、パフォーマンスも予測可能です。詳細については、 Esra のブログ投稿 および Amazon DynamoDB開発者ガイド をご覧ください。 AWS Transform の継続的なモダナイズが一般提供開始 :この機能は、エンジニアリングチームがソースコードリポジトリ全体の技術的負債を大規模に分析して修正するのに役立ちます。メインフレームとレガシーワークロードは、1 回限りの移行イベントではなく、継続的かつ自動化されたアプローチでモダナイズできます。詳細については、 Micah のプレビューブログ投稿をご覧ください 。 AWS Transform Kiro パワーとエージェントプラグインを試すこともできます 。 最大 3,000 Mbps の AWS Lambda 関数帯域幅 ：AWS Lambda 関数は増加したネットワーク帯域幅をサポートするようになり、データ集約型のワークロードと Lambda 関数と他の AWS サービス間の高速通信が可能になりました。この機能により、2 GB 以上のメモリで構成されている VPC 外部の機能でも、2 GB で 625 Mbps から 10 GB で 3,000 Mbps まで、比例してスケーリングされるネットワーク帯域幅にアクセスできます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のニュース項目をいくつかご紹介いたします。 Dogwood の紹介：AI エージェント向けのランタイム検証 ：AWS は Dogwood をオープンソース化しました。これは、AI エージェントが Cedar ポリシーをサポートし、時間的条件を追加するための専用ガバナンス言語です。Dogwood を支える Amazon Bedrock AgentCore では、現在のリクエストだけでなく、 セッション中のエージェントのアクションの履歴に基づいて決定されるテンポラルポリシーが導入されました 。 AWS によるエージェントプラグインのサポート:ポータブルエージェント拡張のオープンスタンダード ：AWS は、エージェントプラグインのサポートを発表しました。これは AI エージェント拡張機能に共通のパッケージ形式を提供するオープンソースのベンダー中立仕様であり、拡張機能を一度パッケージ化すれば、Kiro、VS Code、Cursor、またはこの仕様を実装する任意のツールを含む任意のクライアントに配布できます。 Kiro Crew のご紹介 ：Kiro Crewは、オンラインでもオフラインでも作業を円滑に進め、Kiro IDE 内での共同マルチエージェント開発ワークフローを可能にする、永続的で自己進化型のワークスペースです。1 回のチャットセッションにとどまらず、リポジトリ、ツール、日数にわたるエンジニアリング作業向けに構築されています。複数の作業を並行して実行することも、レポートを返すサブエージェントに作業を引き継ぐこともできるので、列に並ぶ必要はありません。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 8 月 10 日週のニュースは以上です。8 月 17 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! — Channy 原文は こちら です。

はじめに 2026年7月にタイミーへ入社した細野です。現在はバックエンドエンジニアとして、ワーカーさんと事業者様双方の体験をより良くするためのプロダクト開発に携わっています。 この記事では、私がタイミーに興味を持った背景と、入社後に感じていることを書きます。タイミーに少しでも興味を持っている方にとって、入社後のイメージを持つ材料になれば嬉しいです。 簡単な自己紹介 私はもともと、紳士服販売からキャリアをスタートしました。その後、プログラミング講師を経て、2021年からエンジニアとして働いています。 エンジニアとしては、スタートアップや事業会社でフロントエンドからインフラまで、幅広く開発に携わってきました。プレイングマネージャーとして開発推進や技術面のリードを担いながら、新入社員メンターや中途採用にも関わらせていただきました。 直近ではニフティ株式会社で、ポイントサービスのモダナイゼーションに取り組んでいました。特に、データベースの PostgreSQL 移行など、長く運用されてきたシステムを今後も継続的に改善できる状態に近づける取り組みに関わらせていただきました。 参考： ニフティ株式会社「 Oracle Database Enterprise Edition から Amazon Aurora PostgreSQL への移行によりメンテナンス時の対応コストを50%削減 」（出典：同社公開記事） タイミーに興味を持つまでの背景 私は、エンジニアリングを通じて、人の選択肢や可能性を広げることに貢献できる仕事に、強いやりがいを感じます。 人生の中で、仕事が占める時間はとても大きいものです。だからこそ、どんな仕事に向き合うかは、自分自身の幸福度にも大きく関わると考えています。 以前、「ジョブ・キャリア・コーリング」という考え方を知ったとき、自分は収入を得るためだけでも、キャリアを積み上げるためだけでもなく、自分なりに意味を感じられる仕事に向き合いたいのだと気づきました。 その後、プログラミング講師として受講生の方々に向き合う中で、人の選択肢を広げることに関わる仕事への思いはより強くなりました。さらに、教えるためにプログラミングを学び続けるうちに、その面白さに強く惹かれるようになり、エンジニアとしてプロダクトを通じて価値を届けたいと思うようになりました。 特に印象に残っているのは、自社サービスの開発で、事業部、ディレクター、CS、デザイナーなど多くのメンバーと一緒に、要求定義からリリース、リリース後の改善まで取り組んだ経験です。技術だけで完結するのではなく、ユーザー体験や事業成果に向き合いながら、チームでプロダクトを育てていくことに強いやりがいを感じました。 タイミーに興味を持ったきっかけ タイミーに興味を持ったきっかけは、以前から業務で参考にしていたテックブログや、求人媒体で見た募集情報でした。 タイミーが掲げる Vision「一人ひとりの時間を豊かに」と Mission「『はたらく』を通じて人生の可能性を広げるインフラをつくる」は、自分が大切にしてきた価値観と強く重なるものでした。加えて、モジュラーモノリスやチームトポロジーなど、プロダクトと組織の成長に向き合うための技術的・組織的なチャレンジがあることにも惹かれました。 また、エンジニアとして技術を深めるだけでなく、PdM、アーキテクト、EM、テックリード、シニアエンジニアなど、さまざまなキャリアの可能性があることも魅力でした。自分自身、技術、プロダクト、人・チームの成長のどれにも関心があるので、入社後の選択肢を広く持ちながら挑戦できそうだと感じました。 入社して感じていること 実際に入社してみると、事業、プロダクト、開発組織、ドメイン知識など、キャッチアップすることはたくさんあります。正直、まだまだ目の前のことを理解しながら、なんとか現場についていっている段階です。 ただ、チームトポロジーを踏まえた組織設計、Notion上のドキュメント、バックエンド開発Handbook、AIエージェント向けのスキルなど、必要な情報にたどり着きやすい仕組みが整っていることは、とても心強く感じています。 tech.timee.co.jp 加えて、入社後はメンターの方と毎日1on1の時間があり、分からないことをそのままにせず相談できる環境があります。キャッチアップ量は多いですが、一人で抱え込まずに前に進める安心感があります。 正直、まだ一度聞いただけで理解しきれることばかりではありません。だからこそ、分からなかったことや後で見返したいことは Notion DB に残し、タスクやキャッチアップ用のメモとして少しずつ整理しています。レビューでいただいたフィードバックも、同じ指摘を繰り返さないように Claude や Cursor の Skill として残し、次の実装やレビュー前に見返せるようにしています。文字だけでは把握しづらいドメインやシステムの関係性は、Miro で図にしながら、自分にとって理解しやすい形に変換しているところです。 また、単に仕様を実装するだけではなく、「なぜそれをやるのか」「誰にどのような価値があるのか」を考える機会が多いことも印象的です。ドメインやプロダクトの変化に向き合う難しさはありますが、その難しさも含めて、プロダクトやユーザーに近い場所で価値を届けるエンジニアリングに取り組めていることを面白く感じています。 これからやりたいこと まずは担当領域でしっかり価値を出しながら、ワーカーさんと事業者様双方にとってより良い体験を届けられるよう、プロダクト理解と技術力の両方を深めていきたいです。 そのうえで、継続的に学び、学びをチームや組織に還元できるエンジニアでありたいと思っています。目の前の課題に対して横着せず、背景や構造を理解しながら、論理的に考え、周囲と協力して成果につなげていきたいです。 また、バックエンドエンジニアとしての専門性を高めつつ、これまでの経験も活かして、プロダクトやチームの成長にも貢献していきたいです。 タイミーが向き合っている「はたらく」の領域には、ワーカーさんと事業者様双方の体験をより良くすること、複雑なドメインをプロダクトとして分かりやすく届けること、事業成長に耐えられるシステムを作ることなど、エンジニアリングで向き合えるテーマがたくさんあると感じています。これから少しずつ、自分なりの形で価値を届けていけるよう頑張っていきます。 おわりに ここまで読んでいただき、ありがとうございました。 タイミーはいま、第二創業期ともいえるフェーズにあります。新規事業や既存領域の進化がいくつも並行して走っており、意思決定や仮説検証のサイクルを速めるための仕組みづくりも盛んです。 まだ入社して間もないですが、このスピード感の中でプロダクト開発に向き合えることは、率直にとても面白いと感じています。 もしタイミーの Vision、Mission、Value に共感し、同じ熱量でプロダクト開発に関わりたいと感じる方がいれば、ぜひ一度カジュアル面談でお話しできると嬉しいです。 product-recruit.timee.co.jp

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