はじめに 対象読者: AWSやClaude Codeにある程度慣れている方向け こんにちは。アプリケーションサービス部ディベロップメントサービス4課の眞柄です。 AWS Lambdaのコンソールに、コーディングエージェント (Claude Code、Cursor、Kiro CLIなど)向けのセットアッププロンプトを一発でコピーできる機能が追加されました。ボタンを押すとエージェントに貼り付けるだけで環境構築が終わる、という触れ込みです。 実際どれだけ便利なものか気になったので、Claude Codeを動かせる環境を用意し、実際に試してみました。 セットアッププロンプトのコピー場所 スクリーンショ…

こんにちは。エンタープライズ第二本部 プラットフォームエンジニアリング部 2年目の菊池祥汰です。業務では AI サポートセンターとして生成 AI / LLM 活用案件や dJ グループ内の生成 AI 利活用推進などを行っています。 この記事では、従量課金・投資回収フェーズに入っている筈の LLM ベンダーが、昨今ベンチマークスコア比のトークン単価を下げ続けているという事実に対して、検証ベースの定量的な評価を述べます。より具体的に言うのであれば、 「Claude Mythos/Fable 級と評されるモデル（Claude Opus 5）が、より安いトークン単価で提供されているように見えるのに対して、実際の請求金額は本当に下がっているのか？」 という問題について検証を行います。 はじめに 検証 結果 品質評価 推論量 請求額 結論 おわりに はじめに 2026 年に入ってから、ベンチマークスコアに対するトークン単価は下がり続けています。最上位モデルに 0.5% 差まで迫る性能が、その半額で手に入るようになりました。 2026 年 7 月 25 日、Anthropic から Claude Opus 5 が発表されました。その上位（フラグシップモデル）には、Claude Mythos / Claude Fable 5 が存在します。Claude Mythos は、評価環境のネットワーク設定不備から実在の組織インフラに到達し、演習課題の一部と誤認して認証情報を持ち出す操作を行った 事例 が公表されているモデルです。その Mythos に強力な制限ハーネス（メタプロンプト）を設定し公開された Claude Fable 5 は、そのサイバーセキュリティ能力の高さから来る懸念から、2026 年 6 月 12 日に 米政府の輸出規制の対象となりました 。 領域によっては同等かそれ以上のベンチマークスコアを誇る Claude Opus 5 は、CursorBench 3.2 の最大 effort で最上位の Claude Fable 5 の最高スコアに 0.5% 差まで迫りながら、コストは半分だと 公表されて います。 モデル CursorBench 3.2 入力 / 出力（1M トークンあたり） Claude Fable 5 70.5% $10 / $50 Claude Opus 5 70.0% $5 / $25 Claude Opus 4.8 62.3% $5 / $25 Claude Sonnet 5 61.5% $2 / $10（2026 年 8 月 31 日までの導入価格。9 月 1 日以降は $3 / $15） 表の絶対値は第三者による集計です。ベンチマークの運営元である Cursor 自身は、既定の effort で Claude Opus 5 が 66.7%、Claude Fable 5 が 66.5% だと 述べて います。 Claude Opus 5 の $5 / $25 が Claude Opus 4.8 から据え置きであることは 公式発表文 に明記があり、 Claude Sonnet 5 の発表 は Claude Opus 4.8 に近い性能をより低い価格で提供するモデルだとしています。最上位の半額で 0.5% 差、さらにその 5 分の 2 の導入単価で前世代の Opus に近い性能、という並びです。 同じ動きは Anthropic に限りません。OpenAI は 2026 年 7 月 30 日に GPT-5.6 ファミリーの API 価格を改定 しました。7 月 9 日の GA 時点と比べると、上位の Sol は入力 $5 / 出力 $30 で据え置き、中位の Terra は入力 $2.50 / 出力 $15 から $2.00 / $12 へ 20% の引き下げ、下位の Luna は入力 $1.00 / 出力 $6.00 から $0.20 / $1.20 へ 80% の引き下げです（いずれも 1M トークンあたり）。 ベンチマーク 条件 GPT-5.6 Sol のスコア ARC-AGI-3 OpenAI の公式ハーネス 13.3% ARC-AGI-3 推論保持と圧縮を加えたハーネス 38.3%（出力トークンは 6 分の 1） ARC-AGI-3 参考: 人間の平均 48% Terminal-Bench 2.1 標準 88.8%（前世代 GPT-5.5 は 88.0%） Terminal-Bench 2.1 Ultra モード 91.9% ※ただし、GPT-5.6 は「スコアを保ったまま単価だけが下がった」と読むことはできません。13.3% と 38.3% は、同じモデルの数字です。推論の保持と圧縮をハーネス側で加えると スコアは約 3 倍になり、出力トークンはむしろ 6 分の 1 に減った と報じられています。 Terminal-Bench 2.1 の数字 は前世代の GPT-5.5 から 0.8 ポイントの改善です。 素直に受け取るのであれば、各社は 性能を向上させつつ値下げを続けている ことになります。一方で、各 LLM ベンダーは従量課金精度を強化し、回収フェーズに入っており、そのスタンスの違いには若干の違和感が残ります。 単価表が約束しているのは「1 トークンの値段」だけであって、「1 つの仕事の値段」ではありません。つまり、当然のことですが、 「Claude Sonnet 5 の単価は Claude Opus 5 の 5 分の 2 である。したがって、同じ実装作業を投げれば、請求額も 5 分の 2 になる」 とは言い切れないわけです。 この命題が成り立つのは、同じ仕事に必要なトークン数がモデルによらず概ね一定であるときだけです。 もし安いモデルが、上位モデルと同じ品質に到達するために推論を厚く取ることによって、結果的に多くのトークンを消費しているのであれば、単価の安さは請求書に届く前に目減りしている・あるいは逆転している ことになります。すなわち、 「安いモデルで推論を積むことでユーザの心理的抵抗を下げ、スコアを担保しながらの課金につなげている」 という疑いが残されています。 検証 今回は、Claude Opus 5 が発表されたばかりの Anthropic にターゲットを絞り、検証を行います。 やることは可能な限りシンプルなものとし、まったく同じ要件定義書を Claude Sonnet 5 / Claude Opus 5 / Claude Fable 5 に渡し、Claude Code（v2.1.220）で完全自動に実装させます。2 題材 × 3 モデル × 3 試行の計 18 本を回し、実装にかかった料金を計測しました。 題材には、仕様が外部に一意に存在してエッジケースが密集している実装課題を 2 つ選びました。これは、題材が簡単すぎるために 3 モデルとも差が出ないという結果を回避するためです。一方で、それぞれは大規模な開発案件というわけではなく、 弊社の社員が日常的にAIに伴走させているような、中規模かつ要件ドリブンの思考判断作業に近しいタスクドメイン を想定して設計しました。 題材 実装するもの 踏みやすいエッジケース 隠しテスト B: 数式評価エンジン 表計算ソフトの数式評価器。セル参照、演算子の優先順位、循環参照の検出、依存関係にもとづく再計算 単項マイナスがべき乗より強く結合する（ =-2^2 は 4.0 ）。 ROUND は 0 から遠い方へ丸める（Python の組込み round はバンカーズ丸めなので、素直に実装すると落ちる） 119 件 D: 繰り返し予定の展開器 iCalendar（RFC 5545）の RRULE のサブセットを日時列に展開する。月末、第 n 曜日、除外日、タイムゾーン 第 5 月曜がある月、13 日の金曜日といった暦の際どい日付を期待値に置いた（ calendar モジュールで独立に検算） 105 件 条件は以下のとおりです。 推論設定 : --effort high を全条件で固定 個人設定 : --safe-mode で CLAUDE.md・スキル・フック・MCP を一括で無効化 外部情報 : --disallowed-tools WebSearch WebFetch で取得を封じる 指示文 : 全条件で完全に同一の 1 種類だけ 実装量 : 要件定義書でファイルパスと公開 API を固定 採点 : 実装側に見せない隠しテストの通過率。隠しテスト自体は、別に書いた参照実装で全件通ることを先に確認 トークン数は claude -p --output-format stream-json の最終 result イベントに API 報告値がそのまま入るため、これを主軸にしました。課金額は CLI が出す costUSD を鵜呑みにすることなく、 公式の料金ページ の単価とキャッシュの倍率で独立に再計算しました。この検算で、 CLI が Claude Sonnet 5 を標準価格の $3 / $15 で計算していることが判明したため、以降の金額はすべて現行の導入価格で引き直した正確な値となっています。 結果 品質評価 品質面では、18 本のうち 17 本が満点でした。唯一の失点は、Claude Sonnet 5 が題材 D の 3 本中 2 本で BYDAY=+2TU （序数に明示的な正符号を付けた表記）を不正と判定したもので、全 105 件中 1 件です。RFC 5545 の構文では序数の前に + を置けるので実装側の誤りですが、私の要件定義書が明示的な正符号に触れていなかったのも確かで、品質差の根拠として強く扱うのは無理があります。 筆者の想定通り、この難度の範囲では、3 モデルの品質に差は出ませんでした。 したがって、 同じ成果に到達するまでにいくら払ったのか、という比較 がそのまま成立します。 一方で、所要時間と実装行数にはモデルごとの傾向が見られます。3 試行の平均で、 Claude Opus 5 が両題材で最も速く（516 秒 / 366 秒）、Claude Fable 5 が両題材で最も短いコードで満点を取りました（605 行 / 325 行） 。 推論量 思考トークンには、API に分離したフィールドが存在しません。そこで、CLI が思考中に流すイベントから値を取得しました。 { " type ":" system "," subtype ":" thinking_tokens "," estimated_tokens ": 11050 ," estimated_tokens_delta ": 100 } estimated_tokens は思考のひと続き（エピソード）ごとに 0 から積み上がり、次のエピソードでリセットされます。増分の総和と、エピソードごとのピークの総和を別々に計算して突き合わせ、完全に一致することを確認しました（Claude Opus 5 の 1 本で 17,713）。 題材 モデル 出力トークン（平均） 思考トークン（平均） 思考の比率（3 試行の範囲） B Claude Sonnet 5 63,259 46,619 73.7%（72.4 〜 76.0） B Claude Opus 5 45,339 21,692 47.7%（42.1 〜 52.4） B Claude Fable 5 49,802 33,246 66.8%（65.5 〜 68.3） D Claude Sonnet 5 44,945 30,783 68.5%（68.0 〜 69.0） D Claude Opus 5 32,846 13,448 40.6%（31.8 〜 49.5） D Claude Fable 5 33,411 18,805 56.0%（49.8 〜 60.3） 思考の比率は、両題材で全く同じ順序になりました。 Claude Sonnet 5 が最も厚く、Claude Opus 5 が最も薄く、Claude Fable 5 がその間です。 3 試行の範囲も、Claude Sonnet 5（68 〜 76%）と Claude Opus 5（32 〜 52%）で重なりません。 出力トークンの内訳。最も安いモデルが、最も厚く思考している 厚みの出どころは、往復回数ではありません。Claude Sonnet 5 と Claude Opus 5で平均同士の比を取ると、思考トークンが 2.15 倍（題材 B）と 2.29 倍（題材 D）、出力トークンが 1.40 倍と 1.37 倍で、題材が違ってもほぼ揃っています。一方で API リクエスト数の比は 0.62 倍と 1.13 倍で、題材によって逆転しています。テストに落ちて直す往復が多いのであれば、リクエスト数の比が安定して 1 を超えるはずです。すなわち、 トークン厚みの差は、1 リクエストあたりの思考の厚さから来ている と言えるでしょう。 Sonnet 5 の推論が厚いのは概ね予想どおりでしたが、Opus 5 よりも Fable 5 のほうが厚いのは予想外でした。これであれば、 分野によっては Fable 5 よりも Opus 5 のほうがコストパフォーマンスの良いモデルである と断言してしまって良いと思っています。トークン単価・入出力トークンともに Fable 5 を下回るのであれば、費用削減効果はそのまま二重に効いてくるでしょう。 請求額 公式の現行価格で再計算した、1 本あたりの請求額です。 題材 Sonnet 5 Opus 5 Fable 5 Opus 5 ÷ Sonnet 5 Fable 5 ÷ Opus 5 B $1.035 $2.018 $3.990 1.95 倍（単価比 2.50） 1.98 倍（単価比 2.00） D $0.823 $1.471 $2.889 1.79 倍（単価比 2.50） 1.96 倍（単価比 2.00） 単価は 2.5 分の 1 なのに、請求は 1.79 分の 1 でした。 冒頭で置いた命題は否定された一方で、否定のされ方は予想とは異なっていました。筆者は「ともすると、推論の厚みと反復回数の重なりによって、Sonnet 5 の総課金料金のほうが高いのでは？」ところまで疑っていましたが、そうはなっていません。Claude Sonnet 5 は Claude Opus 5 の 1.8 〜 2.0 分の 1 の請求で、同等の品質に到達しています。 安いモデルは、ちゃんと安いのでした。 一方で、 単価表から受ける印象ほどの割引率には届いていませんでした。 しかも、目減りは全階層で起きているわけではありません。単価差のうち実際に請求額の差として実現した割合は、Claude Fable 5 ÷ Claude Opus 5 では 98% ですが、Claude Sonnet 5 が絡むと 70 〜 78% まで落ちます。 請求の 55 〜 61% 程度は出力トークン由来で、その出力の 4 割から 7 割が思考です。掛け合わせると、 請求全体のおよそ 3 割から 4 割が「思考」に対する支払い になります。しかも思考の中身は記録に残りません。思考トークンが出力トークンとして課金されることは 公式ドキュメントの Thinking に明記されていますので、適切なモデル選択・適切な effort 設定が重要だという一般論を支持するような結果となりました。 なお、ここまでの Claude Sonnet 5 の金額は、導入時の割引価格（$2 / $10）にもとづいています。9 月 1 日以降の標準価格（$3 / $15）で引き直すと、差は縮みます。 題材 Claude Sonnet 5（標準価格） Claude Opus 5 Opus 5 ÷ Sonnet 5 B $1.553 $2.018 1.30 倍 D $1.234 $1.471 1.19 倍 こう見ると、Claude Opus 5 のほうがコスパが良いようにも感じられてきます。Claude Opus 5 とSonnet 5 の請求額（実費）がせいぜい1.30 倍程度なのであれば、 性能比で考えたときの Claude Opus 5 のコストパフォーマンスは群を抜いています。 結論 単価の安さは、表の印象ほどは手元に残りません。安いモデルは相応に推論を厚く取よう設計されており、その厚みは、出力トークンとして単価表の右端の列に乗ってきます。 割引は、割引された側が余分に考えることで一部追徴されている 、という構図です。 もっとも、今回の題材は 2 つとも標準ライブラリだけで書ける単一ファイルの実装課題で、既存コードの改修や大規模なリファクタリングでは傾向が変わりうるものです。品質自体は飽和してしまったため、難しい課題で品質差が開いたときにこの比率がどう動くのかも分かっていません。 また、 Fable 5 はeffortをmediumで運用することが望ましい ということが 公式に言及されて おり、今回の検証は非常に簡素なものであることを申し添えておきます。結論は 「トークン単価とタスクの難易度を見比べ、最適なモデル選択とeffort設定を心がけるように、軽量なモデルから試していくことが重要」 という、なんとも凡庸なものになってしまいそうです。 とはいえ、 「Claude Sonnet 5 で何度もラリーを重ねるよりは高コスパな Claude Opus 5で一発で叶えてしまったほうが却って安い場合がありそうだ」 というのは重要な発見であったと感じています。 おわりに 今回の検証の結論は、 Claude Opus 5 のコストパフォーマンスが際立っている 、というものでした。請求は Claude Fable 5 の約 2 分の 1で済み、単価が半額であるだけでなく、出力トークンと思考の比率そのものが Claude Fable 5 を下回っています。 そのうえで、トークン単価の引き下げが請求額にそのまま届くわけではないことも分かりました。Claude Sonnet 5 の単価は Claude Opus 5 の 2.5 分の 1 ですが、請求は 1.79 〜 1.95 分の 1 にとどまりました。差の 2 割から 3 割は、厚い推論による消費量の増加で相殺されています。 一方で、Claude Opus 5 をClaude Code 経由で 1 週間ほど実務で使った体感としては、 業務ドメイン知識に基づく意思決定や判断が必要なケース、 /adviser コマンドで入れるエスカレーション先としては、Opus 5 の出力精度（柔軟な思考力・判断力）はやや物足りない 印象を受けました。そのため、完全な上位互換になっているとは言えないでしょう。 とは言え、 日常使いにおいては Opus 5 で必要充分かそれ以上のパフォーマンスを得られる。また、 Opus 5 で充分なタスクに対する Fable 5 の使用は、コストパフォーマンス的に極めて悪手である ということは、Claude Enterprise プランを導入している弊社の面々にも強調しておきたいところです。 センセーショナルな見出しでモデルを選ぶのではなく、堅実なコストパフォーマンスを見せるOpus 5 を、社内でも積極的に広めていこうと思いました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kikuchi.s レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

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