はじめに こんにちは。RevComm でエンジニアをしている 林 です。 AI コーディングエージェントの普及でコードを書くコストは大きく下がり、ボトルネックはレビューと定型的な保守作業に移りました。 Addy Osmani 氏も「 Agentic Code Review 」で、レビューが PR の作成スピードに追いつかず、コードが読まれないままマージされ始めている現状を書いています。 MiiTel Phone（ブラウザ上で通話できる AI 搭載 IP 電話アプリ）の開発リポジトリでは月に 300〜600 件の PR がマージされます。その中には、振る舞いを変えないリファクタリング、依存パッケージの更新、ドキュメントの修正のような、判断の型が決まっているのにレビューの待ち時間だけは通常の PR と変わらないものが相当数含まれます。 こうした定型的な判断を GitHub Actions 上の AI に任せ、人間のレビューを本質的な変更に集中させる取り組みから、4 つの事例を紹介します。 いずれも Claude Code を GitHub Actions 上で動かす構成で、事例 1〜3 は公式の claude-code-action 、事例 4 は GitHub Agentic Workflows (gh-aw) を利用しています。 ※ 記事中のコードや設定は説明のために抜粋・簡略化しています。 設計原則を先に 4 つの事例は使うツールも対象も違いますが、設計は同じ型に収まっています。作業の大半はプロンプトを書くことではなく、「AI に何をさせないか」を決めることでした。 先に原則を挙げます。以降の事例は、これがどう具体化されているかとして読んでもらえればと思います。 判定は AI、実行は決定的なステップとして 。AI の出力は構造化された判定 or 成果物にとどめ、承認・マージ・クローズ・チケット起票といった副作用は、スキーマ検証を通った出力に対して後続のステップが実行します 自動化の終点を、人間の判断が残る場所に置く 。AI が進めるのは承認、コミットの push、draft PR の起票までで、マージするかどうかは人間が判断します いつでも止められるようにする 。設定をひとつ変えるだけで自動承認を止められるキルスイッチ、作成者がラベルを付けた PR だけを対象にするオプトイン方式、AI の実行回数・実行時間・同時実行数の上限。まず判定だけを動かして精度を確認し、納得してから副作用を有効化します AI への入力を信頼しない 。PR 本文やリリースノートはサードパーティ由来のテキストとして扱い、渡さないか信頼境界の外に置きます 運用で精度を上げる前提を組み込む 。週次のスポットチェック、誤判定を反例としてプロンプトに追記していく運用、リポジトリ固有の観点を自然言語で注入できる入り口、そして「処理しなかったもの」のログを確認可能にしておきます 事例 1: PR のレビュー要否を AI が判定する AI に任せるのはレビューではなく分類 きっかけはチームの振り返りで出た「テストコードやドキュメントだけの変更なら、レビューなしでマージしてよいのでは」という話でした。 前提として、PR を open すると GitHub Copilot や Devin が自動でレビューする設定はすでに入っています。ただし、これらは人間のレビューに観点を足す補助であって、承認までの待ち時間はそこまで変わりません。 今回のボトルネックはまさにこの待ち時間なので、AI レビューを強化して人間のレビューを置き換える方向は取りませんでした。 方針の参考にしたのは Findy Tech Blog の「 不要なレビューをAIにまかせてAIコーディングの環境改善を加速した 」です。要点は、AI を「レビュアー」ではなく「人間のレビューが不要な PR かどうかの分類器」として使うこと、そして Kent Beck 氏の『 Tidy First? 』でいう振る舞いを変えない整頓（tidying）だけを自動承認の対象にすることです。 レビューの代行が品質保証の責任ごと AI に移してしまうのに対し、分類は「人間がレビューすべき PR を人間に確実に届ける」ための振り分けです。 3 レイヤーのレビューポリシー 「AI で自動化」と言いつつ、最初のレイヤーに AI は登場しません。 レイヤー 内容 仕組み レイヤー 0 ドキュメントのみの変更の自動承認 ファイルパスによる機械的な判定（AI 不要） レイヤー 1 人間レビュー必須領域の定義 ポリシードキュメント レイヤー 2 振る舞いを変えない整頓の自動承認 AI 分類器 + 抜き取りの事後レビューと監査 レイヤー 0 は、変更ファイルがすべて docs/ 配下または *.md の PR を機械的に承認します。AI で判定できることでも、決定的に判定できるならそちらを選びます。誤判定リスクがなくコストもゼロだからです。 ただし、同じ Markdown でも .github/ 配下と CLAUDE.md / AGENTS.md は対象外です。これらの無人承認を許すと、自動承認システム自体の改変が無人で通ってしまいます。 レイヤー 1 は、AI の判定にかかわらず必ず人間がレビューする領域の明文化です。通話のような中核機能、feature flag、外部システムとの連携、個人情報や認証、テストの削除、依存パッケージ、CI 設定などが該当します。間違えると影響が大きい領域と、自動化自体の安全性を支える領域（テスト・CI）を並べています。 分類器の実装 レイヤー 2 が本題の AI 分類器です。PR の作成者が ai-classify ラベルを付けたときだけ動きます。分類器は『Tidy First?』の構造的リファクタリングを調整した分類表を持っています。 T1: ファイル・ディレクトリの移動、リネーム（import パスの機械的追随を含む） T5: 変数・関数・コンポーネントのリネーム T7: 未使用コード・ファイルの削除 A1: 既存 feature flag の targeting（どの環境・ユーザーに配布するかの設定）のみの変更（振る舞いは変わるが、チームが明示的にレビュー不要と合意した低リスク変更） NG2: 通話系コードに触れる変更（即 HUMAN_REVIEW） ポイントは、除外条件（NG）を「変更の性質」ではなく「触れた領域」で判定させていることです。通話系ファイルの変更が import パスの機械的な追随だけだったとしても NG2 に倒します。「機械的な変更だから実質は該当しない」という楽観的な判断を AI にさせないためです。 また、迷ったら UNKNOWN と出力させ、 誤って APPROVE するコストは誤って HUMAN_REVIEW とするコストよりはるかに大きい という原則もプロンプトに明記しています。 出力は自然言語のコメントではなく、構造化された判定ファイルです。 { " verdict ": " APPROVE ", " t_categories ": [ " T1 ", " T5 " ] , " reasons ": [ " 判定理由を簡潔に列挙する " ] , " summary ": " 1〜2 文の判定サマリ ", " sampling_used ": false } 後続のステップが jq でこのファイルのスキーマを検証し、検証を通った APPROVE 判定に対してのみ承認を実行します。 - name : Approve if : steps.verdict.outputs.verdict == 'APPROVE' && vars.AI_CLASSIFY_APPROVE_ENABLED == 'true' run : | gh pr review "$PR_NUMBER" --approve --body "$body" gh pr edit "$PR_NUMBER" --add-label ai-approved AI_CLASSIFY_APPROVE_ENABLED は GitHub の repository variable を使ったキルスイッチで、 true でないときは判定コメントの投稿だけを行います。導入初期は切ったまま判定精度を確認し、問題ないことを確認してから有効化しました。 分類器に渡すのは差分とファイル内容だけで、PR 本文とコメントは渡しません。ただし、diff 中のコードコメントには同じ誘導を書けるため、この経路まで消えるわけではありません。 そこは後段のスキーマ検証と、マージ判断が人間に残っていることでブロックします。承認後に push があれば自身の承認を取り消して再分類し、自動マージはどのレイヤーでも行いません。 運用と、PR の作り方への波及 自動承認された PR は週次で数件を人間が事後レビューしています。Addy Osmani 氏の整理を借りれば、すべての差分を人間が見る形から、抜き取り確認と監査で仕組み全体を見張る形への移行です（彼の記事の言葉では human in the loop から human on the loop へ ）。誤判定が見つかれば、反例として分類器プロンプトの除外条件に追記します。 効果はレビューが速くなることにとどまりませんでした。分類器が APPROVE を出せるのは PR 全体が整頓で完結しているときだけなので、リファクタリングと機能変更が混ざった PR は HUMAN_REVIEW に倒れます。 つまり、作成者から見ると、混ぜれば全体がレビュー待ちになり、分ければリファクタリング部分を先に流せる。リネームやファイル移動を先行 PR に切り出して ai-classify を付け、その上に振る舞いを変える PR を積み重ねれば（stacked PR として）、人間に届くのは本質的な変更だけの小さな差分になります。 『Tidy First?』の「整頓と振る舞いの変更を分けよ」という規律は、分けること自体のコスト（PR が増え、レビュー待ちも複数回になる）のせいで努力目標になりがちでした。分類器が整頓側の待ち時間をゼロにしたことで、規律を守るほうが速いという構造に変わっています。 自動化が規律を強制するのではなく、規律に従うことが合理的な選択になるというのは、レビュー待ち時間の削減と並ぶ、もうひとつの効果だと思っています。 事例 2: Dependabot PR を毎朝トリアージする 依存パッケージの更新 PR への対応は、毎回ほぼ同じ判断の繰り返しでした。CI の成否を確認し、リリースノートを読んで破壊的変更の有無を確認し、低リスクなら承認してマージ、高リスクなら Notion にチケットを起票して PR はクローズし、動作確認を含めた計画的な対応に回す。判断の型は決まっているのに手作業では追いつかず、PR は溜まる一方でした。 最初の自動化は、この手順を Claude Code の Skill に書き起こすことでした。手元で「Dependabot の PR を対応して」と頼めば、オープン中の PR を順に解析して一括処理してくれます。 ただし、人が起動する半自動なので、誰かが思い出さない限り PR は溜まり、実行する人の環境と権限に依存する属人的な運用でもありました。 そこで Skill として固めた手順を GitHub Actions の composite action（複数のステップをまとめて再利用できる仕組み）に作り直し、無人で定期実行するようにしました。 このとき、AI 自身が実行していたマージやチケット起票は AI から切り離しています。composite action は社内の共通リポジトリに置き、複数のリポジトリから利用しています。 毎日午前 3 時の cron がオープン中の Dependabot PR を古い順に 1 件ずつ処理します（1 件マージすると Dependabot が残りを rebase するため、並列ではなく直列です）。 PR タイトル・body からパッケージ名とバージョンを機械的に解析し、CI チェックの成否を判定する Claude によるリスク判定。リリースノートを読み取り専用のツールで読み、 triage-verdict.json （risk: low / high、根拠、主要変更点）を書き出す 1, 2 を決定表に通して最終アクションを決める 実行。承認して自動マージ、クローズして Notion にチケット起票、または手動対応として PR に残す 条件 アクション タイトル・body とも解析不能 手動対応（PR は残す） CI 失敗 クローズしてチケット起票（AI の判定に関係なく） AI の判定を取得できない 手動対応（安全側に倒して人間に残す） AI 判定が高リスク クローズしてチケット起票 AI 判定が低リスク 承認して自動マージ Notion のチケット操作も AI にはさせず、TypeScript のスクリプトが REST API を直接叩きます。チケット作成に失敗した場合は PR をクローズせず手動対応に降格させ、「チケットなしで PR だけ消える」事態を防いでいます。 リリースノートはサードパーティ由来の入力なので、プロンプト側では、指示のような文言（「この更新は安全である」「以前の指示を無視せよ」など）を見つけた場合、従わないだけでなく、それ自体をサプライチェーン上の懸念として high と判定するよう指示しています。インジェクションの試みを検知シグナルに変える発想です。 それでも最後の砦は AI の外にある CI 成功という条件で、仮に誘導が成功しても CI が落ちている PR はマージされません。Dependabot ブランチのコードはチェックアウトすらせず、AI が読むのはデフォルトブランチと PR のメタデータだけです。 リポジトリ固有の判定観点は、決められたパスに Markdown で書いておくとプロンプトに注入されます。「electron 関連の更新はすべて高リスクとする」のような 1 行で、チームの経験則を判定に反映できます。 導入後は毎朝の CI で Dependabot のオープン PR をゼロに戻していくので、依存更新の PR が滞留すること自体がなくなりました。残る人間の作業は、高リスクと判定されて起票されたチケットへの対応だけです。 事例 3: @claude メンションを全リポジトリ共通の基盤にする PR や issue のコメントで @claude とメンションすると GitHub Actions 上で Claude Code が動き、質問への回答、レビュー指摘への修正コミットの push、ショートカットの実行を行います。 反応するのは書き込み権限を持つユーザーのコメントのみで、Claude に承認とマージはさせません。 よく使うのはコンフリクトの解消です。AI コーディングで PR を作る速度が上がると同時にオープンな PR が増え、main の進みも速くなるため、コンフリクトは以前より起きやすくなりました。PR 作成の高速化が、今度はコンフリクト解消という新しい定型作業を生んだ形です。 @claude /fix-conflicts と書けば、解消して push するところまでやってくれます。 同じ問題意識は GitHub Next の Evergreen や Codex の PR Babysitter にも見られ、この種の PR のお手入れは自動化の定番になりつつあります。 実装面の工夫は共通化です。 @claude メンション自体は claude-code-action の代表的な使い方ですが、リポジトリごとにワークフローを持つと、モデルの変更やコスト制御の調整のたびに全リポジトリへ同じ変更を配ることになります。 そこでトリガー条件・トークン設計・モデル選択・コスト制御を社内共通リポジトリの reusable workflow に集約し、利用側には呼び出しの数行だけを置く構成にしました。 # 利用リポジトリ側はこれを置くだけ jobs : claude : uses : my-org/claude-workflows/.github/workflows/claude.yml@main secrets : inherit ショートカットの中身は Claude Code の Skill として、さらに別の共有リポジトリ（plugin marketplace）に置いています。手元の Claude Code と GitHub Actions で同じ Skill 資産を共有するためで、ローカルで育てたワークフローがそのまま @claude メンションでも使えます。 事例 4: 定期メンテナンスを自然言語で書く (GitHub Agentic Workflows) gh-aw は、ワークフローを「YAML frontmatter + 自然言語プロンプト」の Markdown ファイルとして書き、 gh aw compile で実行可能なワークフロー（ .lock.yml ）にコンパイルする gh CLI の拡張機能です。 --- on : schedule : weekly on sunday around 20:00 # fuzzy schedule workflow_dispatch : permissions : contents : read engine : id : claude max-turns : 50 timeout-minutes : 30 safe-outputs : create-pull-request : title-prefix : '[main] ' draft : true --- # Docs Drift Audit You are auditing this repository's developer documentation for drift against the actual code, and fixing what has drifted. ... 事例 1〜3 が AI の判定や応答を自前のワークフローに組み込む構成だったのに対し、gh-aw はスケジュールで自律的に動き、リポジトリを調べて成果物（PR など）まで作るエージェントです。 その分、安全装置も枠組み側に強く組み込まれていて、エージェント本体は読み取り専用のトークンで実行され、書き込みは frontmatter の safe-outputs で宣言したものしかできません。 外部通信もファイアウォールコンテナで制限され、 weekly on sunday around 20:00 のようなあいまいな時刻指定はコンパイラが具体的な時刻に解決して、多数のリポジトリで cron が同時刻に集中するのを避けます。現在 2 本が週次で動いています。 ドキュメントと実コードの乖離監査 (docs-drift-audit) 1 本目は、開発ドキュメント（ docs/ 配下、 AGENTS.md 、 CLAUDE.md など）と実コードの乖離を監査するワークフローです。参照先のパスが存在するか、記載コマンドが package.json の scripts と一致するか、feature flag 名やワークフロー名が実在するか、規約の記述が設定ファイルと矛盾していないか。確認できた乖離を修正して 1 本の draft PR にまとめ、乖離がなければ何もせず終了します。 これをわざわざ AI にやらせるのは、ドキュメントが人間向けであると同時に AI 自動化の入力でもあるからです。事例 1 の分類器プロンプトも、事例 3 の @claude が参照する開発ガイドも、鮮度が落ちればそのまま自動化全体の精度劣化につながります。 一方でコード側の変化は速く、手動での追従は現実的に漏れます。週次の監査で、月曜の始業前に修正 PR が用意されている状態を作りました。 プロンプトには「何を直さないか」も同じ分量で書いています。意図的に将来の姿を書いているドキュメントは直さない。リポジトリ外への参照は検証できないので触らない。文体の好みは直さない。そして確信の持てない修正は PR から外すのではなく、PR 本文の「要判断」セクションで曖昧さとレビュー時の確認点を説明させます。 期限切れ feature flag の掃除 (feature-flag-cleanup) MiiTel Phone では、新機能や通話まわりのような壊れたときの影響が大きい変更を feature flag で囲い、OFF のまま main にマージしたうえで、QA や社内テナントでの先行利用を経てから全環境で有効化することがあります。問題が起きたときも、コードを巻き戻す代わりにフラグを OFF に戻すだけで引き返せます。 flag は使い捨てで、安定したら flag と不要になった旧コードを削除する決まりで、放置すると誰も触れない謎のフラグが負債として残るため、各フラグに削除期限も設定しています。 期限切れフラグを Slack に通知して CI を fail させるワークフローはあったのですが、通知されても掃除の PR を作る作業が残るため対応が滞りがちで、一時は 15 件が同日に失効を迎える状況になっていました。 そこで通知の一歩先、削除 PR の作成までを自動化しました。対象は「配布設定が全環境で有効化済みで、かつ期限切れ」のフラグだけです。条件付き配布中のフラグの削除はリリース判断そのものなので、AI には触らせず人間に残します。 フラグの削除は定義を 1 行消して終わりではありません。ガードで分岐していたコードの無条件化に加え、それによって死んだコードの連鎖的な削除までがセットです。この作業パターンをそのままプロンプトに落とし込み、最後に grep でフラグ名の残存ゼロを検証させています。 処理しなかった期限切れフラグも、理由つきで実行ログに残させています。自動化が「何をやらなかったか」を隠すと、カバーされているように見えて漏れる領域ができるためです。 claude-code-action と gh-aw の使い分け どちらも GitHub Actions 上で Claude を動かす仕組みで、どちらでも実装できる仕事は多くあります。ただし対等な選択肢ではありません。 gh-aw は安全装置が組み込まれた専用ツールです。Markdown を書くだけで動く代わりに枠が決まっていて、副作用は safe-outputs で宣言できるものに限られます。外部サービスへの起票のような語彙にない副作用や、AI の出力を自分のコードで検証・分岐してから実行する構成は組めず、イベントに反応する対話的な用途も不得意です。 claude-code-action は自前のワークフローに AI ステップを埋め込む部品なので、トリガーも後段の処理も副作用も自由に設計できる代わりに、権限の最小化・出力の検証・キルスイッチはすべて自分で用意することになります。 タスクが gh-aw の枠に収まるなら gh-aw のほうが少ない記述で安全に済み、はみ出すなら claude-code-action で自分で設計する、という使い分けです。 さいごに 4 つの事例は別々のツールに見えますが、やっていることは 1 つです。判断の型が決まっている作業を AI に寄せ、人間のレビューを本質的な変更に再配分する。そしてそれを安全に成立させているのは、モデルの賢さよりも、判定と実行の分離・人間の最終判断・キルスイッチといった CI 側の設計でした。 この記事が、CI と AI の連携を設計する際の参考になれば幸いです。 参考文献 Agentic Code Review - Addy Osmani 不要なレビューをAIにまかせてAIコーディングの環境改善を加速した - Findy Tech Blog Kent Beck『Tidy First?: A Personal Exercise in Empirical Software Design』 anthropics/claude-code-action GitHub Agentic Workflows (gh-aw) Evergreen - GitHub Next

全体像と使用するツール LM Studio で LLM のインストール 1. LM Studio のインストール 2. ローカルLLMサーバーの起動 3. Continue の設定 実際にやってみる まとめ こんにちは。アプリケーションサービス本部ディベロップメントサービス3課の北出です。 普段はClaudeCodeをメインに使って開発しています。 IDEにはVSCodeを使っているのですが、GitHub Copilotは有料プランではありません。 その場合、Copilot機能にある、コーディング中にグレーで補完候補が出てTabキーで確定する（インライン補完）は無料版の範囲でしか使えず、すぐに…

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