Columns

DXからAX（Agent Experience）へ ― AIのために整えた環境が、なぜ人間の体験まで良くするのか

連載「AIファースト時代の開発基盤アーキテクチャ」第3部（全3部）

第1部では、AIにコードを任せるほど、分かれたリポジトリが「壁」になる話を書きました。第2部では、その壁を取り払った〈World〉を、Shopifyがどんな発想や技術、インフラで成立させたかを追いました。最終部の問いは、ひとつです。ここまでAIのために整えてきた環境 ― その効き目は、AIの外にどこまで広がるのか。

結論から書きます。AIのために整えた環境は、結果として人間にとっても働きやすい環境になる。Shopifyのエンジニアリング組織が繰り返し口にしているのは、「Agent-Friendly（AIに優しい）は、ほぼHuman-Friendly（人に優しい）と同じだ」という発見でした。開発チームの目標が、長く語られてきた「DX（開発者体験）」から「AX（Agent Experience／エージェント体験）」へと動いている。この記事では、その移り変わりと、副産物として人間が受け取るものを整理します。

先に、言葉の整理をひとつ。ここでいうDXは、世間でよく聞くデジタルトランスフォーメーションではありません。Developer Experience ― 開発者体験の頭文字です。

Shopifyは、この開発者体験で他のECプラットフォームを引き離してきた会社です。もっとも、その体験が正当に評価されてきたかは、また別の話。現場のデベロッパーはShopifyを使いたがっても、EC部門の責任者は自分のキャリアを考えてSalesforce Commerce Cloudのような「大手の安心」を選ぶ ― そんな時代も長く続きました。作り手の使い勝手が意思決定の場で軽んじられることは、決して珍しくなかった。

それでも、実力は本物でした。かつてECの改修といえば、管理画面のテキスト欄にHTMLを直接ペタペタ貼る作業です。そこへ、手元のエディタで書いてそのままデプロイできる ― いまでは当たり前でも、当時は画期的でした。裏を返せば、その当たり前が長くなかったからこそ、ECはデベロッパーの間で人気の仕事とは言いにくかった。Hydrogenのような洗練された道具は、その延長にあります。私たちが2013年からShopifyで作り続けてこられたのも、この土台があったからでした。

その会社が、いままた「AIにとっての使いやすさ（AX）」で先頭を走っている。DXに投資し続けた組織が、そのままAXへ滑らかに移っていく。今回の話は突然変異ではなく、その延長線上にあります。

この記事でわかること

  • → AIが「暗黙の了解」を許さないことが、なぜコードベースを勝手に整えるのか
  • → ShopifyのRiverが、同じ間違いを二度しなくなる仕組み（pebbles）
  • → 「AIのための投資」が、そのまま新人オンボーディングと技術負債の解消につながる理由
  • → AIに書かせて終わりにしないために、人間の側に残る仕事は何か

01 AIは「暗黙の了解」を許さない

人間のチームは、暗黙知でかなりの部分を回しています。「このライブラリは、この順序でロードする」「あの環境変数は先輩に聞けば分かる」。READMEが古くても、CIがときどき理由なく赤くなっても、経験でなんとなく越えていける。

AIは、そこを越えられません。古いREADMEを信じて動き、壊れたCIシグナルに惑い、属人化した手順の前で止まる。人間なら「まあ、これはいつものやつ」で流せる曖昧さが、AIにはそのまま障害になる。

だからShopifyは、AIを動かすために、曖昧さを一つずつ潰す羽目になりました。各ディレクトリに置かれたAGENTS.mdが、その象徴です。これは人間向けのREADMEとは性格が違う、AIへの命令書です。公開されているShopifyのリポジトリ（たとえばcheckout-kitのAGENTS.md）を見ると、こう書いてあります。開発コマンドは必ずshadowenvの仮想環境下で実行すること。アクセストークンや加盟店IDのような実データは絶対にログへ出さず、検証には合成プレースホルダーを使うこと。

ここまで書いて、はじめてAIは推測で暴れなくなります。

ここで、心当たりのある方もいるはずです。人間の同僚に同じ細かさで指示すると、「それくらい察してほしい」という空気が漂う。ところが相手がAIだと、私たちは驚くほど素直に、手取り足取り書けます。「言わなければ分からない、当然だ」と割り切れるからです。暗黙知への過剰な期待が、最初から外れている。

だから指示書は、何かを期待してしまう人間より、AI相手のほうが丁寧に書けます。前提も、禁止事項も、手順も、遠慮なく詰め込む。そして面白いのは ― その網羅的な指示書が、そっくりそのまま人間の役にも立つことです。そうしたハイコンテキストな期待を捨て、必要なことを全部書く。ローコンテキストな伝え方の、勝ちです。

02 直した知恵が、二度と同じ間違いを起こさせない

もう一段、Shopifyの仕組みには折り返しがあります。

Riverがバグの原因を読み違えたり、ビルドで詰まったりする。すると、パブリックなSlackチャンネルでそれを見ていた人間のエンジニアが、「そのライブラリはこの順序でロードする」と口を挟む。ここまでは、よくある光景です。違うのはこの先。その指摘が、その場のチャット返信で消えずに、スキルファイルの更新やAGENTS.mdの差分としてコミットされる。Shopifyはこれをpebbles（小石）と呼んでいます。

次に同じ作業へ向かうRiverは、更新されたスキルファイルを最初に読み込んでから動く。だから、同じ間違いを繰り返さない。人間の一言が、コードベースに溜まる知恵に変わる仕組みです。

報じられているところでは、この折り返しによって、Riverのプルリクエストがマージされる率は、2か月ほどで36%から77%へ上がったとされます。基盤モデルを再学習させたわけではありません。コードベースの側が賢くなった結果です。自分たちの環境を前提にしたノウハウをリポジトリに置いておくことが、どれほどのレバレッジになるか ― この伸びが、それを物語っています。しかもRiverは、パブリックチャンネルでしか動きません。特定の誰かの知恵ではなく、Shopify中のエンジニアの指摘が集まって溜まっていく。知恵の集め方まで含めて、よく効いている。第1部で触れた「全社マージPRの8本に1本」という数字も、この土台の上にあります。

03 「AIのための投資」は、そのまま人間のための投資になる

ここが、この連載でいちばん伝えたいところです。

古いドキュメントを消し、CIの赤信号を意味のあるものだけにし、属人化した手順を明文化する。これらはすべて「AIを迷わせないため」に始めた作業でした。ところが出来上がってみると、いちばん喜ぶのは新しく入った人間のエンジニアです。

考えてみれば当然で、初めてそのコードベースに触れるAIと、初日の新入社員は、置かれた状況がよく似ています。全体像を知らない。暗黙の了解を共有していない。ドキュメントとCIのシグナルだけが頼り。AIが迷わず動ける状態は、新人が最短で立ち上がれる状態と、ほぼ重なります。放置されていた技術負債の多くも、この整地の過程で炙り出されて片づく。

NetlifyのCTO、Dana Lawsonは「コードを書くことは、もはやエンジニアリングの中心ではない」と言い切っています。これからのテックリードの仕事は、AIと人間が同じ環境で安全に働けるよう、ガードレールとコンテキストを設計し続けること。彼女はそれを「生産環境の羊飼い」と呼びました。少し大げさに聞こえますが、指している先ははっきりしています。コードを一行ずつ書く職人から、AIと人が働く場所そのものを設計する側へ、という移動です。

Flagshipとしての見立て ― 私たちの規模でも、AXはもう始まっている

Shopifyの規模の話をしてきましたが、AXの考え方は、私たちのような会社にもそのまま降りてきます。

第1部で書いたとおり、私たちは「AI時代の三種の神器」の一つとしてソースコード（GitHubのリポジトリ）を置き、コードだけでなく検討や記録をそこに残しています。これは小さなAX投資です。AIが読める場所に、判断の経緯まで置いておく。

自社プロダクトでも、同じ考え方がもう実務に入っています。分かりやすいのは、セキュリティ監査です。当社は自社アプリのコードを最新のAIにかけて監査し、重大な脆弱性はゼロと確かめたうえで、中程度の指摘まで公開前に直しました。人間のレビューに「AIに読ませる」工程を足しているわけです。AIが読める前提でコードとドキュメントを整えておくことは、そのままAXへの投資になります。

クライアントワークでは、第1部で引いた線がそのまま効きます。契約の壁は越えない。その内側で、案件フォルダに設計意図と運用の癖を明文化して置く。それは今のところ「AIに指示を出しやすくするため」の作業ですが、同じ文書が、新しく案件へ入るメンバーのオンボーディングをそのまま速くする。AXへの投資が、DXへの投資と同じものになる ― このShopifyの発見は、規模を落としても成り立ちます。

限界と運用上の注意

ここまで前向きに書いてきましたが、AXを整えれば万事解決、とはいきません。むしろ、AIが速く大量に書けるようになるほど、詰まる場所が別へ移ります。

移った先は、人間のレビューです。エージェントが30分で積み上げた大きなプルリクエストを、人間はそこに潜む微妙なロジックの誤りごと、1時間かけて読む。AIの生成は速くなっても、レビューにかかる時間は減りません。Shopifyのエンジニアリング責任者Farhan Thawarらは、生成されたロジックを十分に理解しないままマージを重ねることで、組織に「理解の空洞化（Comprehension Debt）」が溜まる危険を指摘しています。

数字も出ています。私たちも日々のレビューに使っているCodeRabbitの調査では、AIが生成したPRは、人間が書いたものより不具合がおよそ1.7倍多く、可読性の問題は3倍を超えたとされます。速く大量に書けることと、質が保たれることは、別の話だということです。

私たちがクライアントの本番を預かる現場で守ってきた線は、ここで効きます。AIに書かせて、そのままマージしない。生成されたコードにも、人間のレビューとセキュリティの目を通す。第三者のペネトレーションテストやISMSの運用と同じ厳しさを、AIの出力にも当てる。AXへの投資と、この規律は、両輪です。

まとめ

3部にわたって、Shopifyの〈World〉とRiverを追ってきました。分かれたリポジトリの壁（第1部）、それを畳んで支えるインフラ（第2部）、そして人間のためだったはずの環境が、AIのための環境と一つに重なる話（第3部）。

貫いていたのは、ひとつの向きです。AI時代の開発基盤への投資は、社内の曖昧さとカオスを一つずつ取り除き、人間とAIが同じ土台で働ける状態を作る作業でした。派手なモデルの話ではなく、地道な整地の話です。

最後に、個人的に愉快だと思う点を一つ。AXを意識した環境づくりは、「言わなくても分かるはず」という期待を、私たちから引きはがします。しかも相手は、一度伝えれば覚えている ― 同じ説明を何度も繰り返さずに済む、という安心感もある。だからこそ、最初に過不足なく説明しておこうという気になる。AIを気持ちよく働かせようとしているうちに、人間の説明のしかたまで良くなっていく。AIが私たちのそういう行動を引き出してしまうのは、なかなか面白い話です。

一社で一つの〈World〉を畳める会社は、そう多くありません。けれど、AIが読める場所に判断を残し、AIに検証させ、AIに書かせたものを人間が見直す ― この習慣なら、規模を問わず、今日から始められます。契約の壁の内と外で、その習慣をどれだけ丁寧に積めるか。私たちは、そこにこれからの数年の実務が懸かっていると考えています。

参考・出典

本記事の情報は2026年7月時点のものです。Riverの運用数値のうち、直近30日の実績（マージPR 3,536件・全体の約12.5%）はShopify公式の公開値、マージ率「36%→77%」は第三者媒体の報道に基づく参考値です。

関連記事

Columns All