1. 序論

ソフトウェアの歴史の大半において、希少な資源は記述であった。開発者の技は、意図を正しいコードへと変える能力によって測られ、時間はタイピング、調べ物、ライブラリの配線、コンパイルエラーや失敗するテストが明らかにする小さな誤りの修正へと費やされた。有能なコーディングエージェントは、そのほとんどを取り除く。明確な指示とコードベースへのアクセスを与えれば、それは数分のうちに、何百万回も見てきたイディオムで、ボイラープレートをすでに正しく備えた、動く変更を生み出す。このように働くことの口語的な名称は、2025年初頭に広まったもので、vibe coding である。すなわち、欲しいものを記述してモデルにそれを生み出させ、一行ずつ書くのではなく結果によって舵を取ることである。これは紛れもなく段階的な飛躍であり、それを物語の全体だと取り違えるのはたやすい。

それが物語の全体でないのは、コードを出現させることがソフトウェアの難所であったことは一度もなく、ただ労を要する部分であったにすぎないからだ。難所とは、何を作るかを決めること、そして作られたものが実際に正しく、安全で、動かすにふさわしいと知ることである。これらは生成が安価になっても安価にならない。むしろ難しくなる。今やはるかに多くのコードが理解されねばならず、それは人が書いたよりも速く、誤っているときでさえ自信に満ちた書き手によって生み出されるからだ。ソフトウェア開発のボトルネックは移動する。かつてそれは生成に、すなわちチームがどれだけ速く正しいコードを書けるかにあった。エージェントがあれば、それは検証に、すなわちチームがどれだけ速くコードが正しいと確信してそれを通過させられるかにある。

本稿は、その転換がツールにもたらす帰結についてのものであり、意図して具体的である。検証が制約であるならば、AI支援環境がなしうる最も価値あることは、より速く生成することではなく、チームがより速くより安全に検証するのを助け、エージェントの誤りを安価に早期に捕えることである。我々は、我々Nashuaが自社製品である Nashua 360 Enterprise Platform を構築し運用するために用いている具体的な連鎖、すなわちエージェントとしての Claude Code、バージョン管理された背骨でありレビューゲートである GitHub、あらゆる変更の稼働中プレビューのための Vercel、アプリケーションフレームワークとしての Next.js、そしてデータベースとしての Postgres を記述し、各部分が実際にどう働くのかに踏み込む。細部にこそ価値があるからだ。各リンクは、個別に巧妙であることによってではなく、ループを締めるかゲートを加えることによって、その居場所を獲得する。

貢献は、議論と実践的な推奨であって、ベンチマークではない。第2節は、AIが何を変え何を変えなかったかを述べ、ボトルネックの所在を突き止める。第3節は、連鎖をループとして提示し(図1)、エージェント支援の作業では best-of-breed が慣習的であることを意味するという主張を立て、なぜ独立したゲートが相乗するのかを説明する。第4節から第9節は、五つの部分を順に取り上げ、デプロイメントが実際に持つランタイムアーキテクチャ(図2)を含めて、その内部へと踏み込み、人々を驚かせる部分、すなわち変更を今や電話から開始しレビューできることを扱う。第10節から第12節は、人間のゲートとその故障様式、現実のコスト、そして連鎖が実際にどう回るかを論じる。全体を貫く問いはこうである。ひとたびエージェントがコードを書けるようになったとき、速く書くことが誤ったものを出荷することを意味しないよう、チームはその周りに何を置くべきか。

2. AIが変えたもの、変えなかったもの

2.1 転換

エージェントがもたらす変化は、精確に述べるのが最善である。それは、機械がいまや問題を理解するということではない。十分に仕様化された変更の、もっともらしく、しばしば正しい実装を生み出すコストが崩落した、ということである。ある機能に午後いっぱいを費やしたであろう開発者は、それを記述するのにかかる時間で最初の版を手にでき、いくつもの版を安価に捨てられる。作業の様式は、執筆から指揮へと移る。すなわち、意図を述べ、結果を読み、進路を正すことである。これは本物のレバレッジであり、それを拒むチームは追い抜かれるだろう。

2.2 銀の弾丸はない

この変化もまた境界を持ち、その境界は古い。Brooks(1987)は、ここでも依然として支配的な区別を描いた。ソフトウェアの偶有的複雑性、すなわち問題そのものではなく我々の道具や言語が課す労苦は、攻撃し減らすことができるが、本質的複雑性、すなわち問題を理解し正しい解を仕様化することは、自動化によって取り除くことはできない。なぜならそれが問題そのものだからである。コーディングエージェントは、これまでに作られた偶有的複雑性への最も強力な攻撃である。それは構文、ボイラープレート、APIの調べ物、イディオムを吸収する。本質に対しては何もしない。ビジネスが何を必要とするかを知ること、正しい設計を決めること、そしてある変更が何か他のものを壊さずに実際にそのニーズを満たすと立証することは、依然として人間の仕事であり、それこそが常に難しかった仕事である。

2.3 検証が制約になる

両者を合わせれば、結論が従う。偶有的な部分である生成は、いまや速く安価である。本質が宿る検証、すなわちこの変更が正しいこと、望まれたことを行うこと、何も壊していないこと、露出させて安全であることは、そうではない。いかなるパイプラインでもスループットは最も遅い段階によって定まり、生成が検証を追い越して加速するとき、検証が拘束的な制約となる。一日に十の変更を生成できるが二つしか検証できないチームは、二つを出荷し、負債であって資産ではない未検証コードのバックログを溜め込む。さらに悪いことに、エージェントは自信に満ち表面的には正しい仕事を生み出すので、過小検証のコスト、すなわち正しく見えるが実はそうでないものをマージするコストは、そうしたいという誘惑が高まるのとちょうど同じだけ高まる。本稿の残りは、検証の天井を上げ、過小検証を困難にすることを仕事とする連鎖を築くことについてである。

3. 連鎖、そしてなぜ慣習的なものが勝つのか

3.1 ループ

優れたAI支援環境は、道具ではなくループである。図1は我々が用いているものを描く。開発者が意図を述べる。エージェントである Claude Code は、それを、稼働中のコードにではなくブランチ上の変更へと変える。変更は GitHub のプルリクエストとなり、そこで二つの自動ゲート、すなわち型チェッカーと継続的インテグレーションのスイートが、誰の注意も要さずに走る。Vercel はブランチを、変更がライブになったアプリケーションの完全なコピーである、それ自身のURLで到達可能な、現実の稼働中プレビューデプロイメントへとビルドする。人間は、デスクトップで、あるいはますます電話で、差分を読み、プレビューをクリックして回りながら、変更をレビューする。そうして初めてそれは main ブランチへとマージされ、Vercel がそれを Postgres に支えられた本番へとデプロイする。その成果が次の意図へと送られる。図の要点は、エージェントは一つの箱を占めるにすぎず、他のすべての箱はループが閉じるかゲートが捕えるかであり、安全性と速度はそこから生まれる、ということである。

3.2 best-of-breed とは慣習的であること

ツールを選ぶ通常のやり方は、それらを能力によって順位づけ、最も有能なものを選ぶことである。エージェント支援の連鎖にとって、基準は異なり、それは本稿で最も有用な唯一の考えである。エージェントは、最も多く見てきたツールを最もよく書く。あるフレームワークやデータベースに対するその習熟度は、そのツールを用いた正しいコードがどれだけ訓練の中にあったかの関数であり、その量はツールの人気、その文書、そしてその慣習の安定性を追う。したがって、主流で、よく文書化され、慣習の多いツールは、単に人間にとって安全な選択であるだけでなく、エージェントが最も有能であり、存在しないAPIを発明する可能性が最も低い選択である。その効果は相乗する。人気のあるツールはより多くのエージェント生成コードを得て、それが機能し、それが人気を強める。AI支援開発にとって、best-of-breed と最も慣習的であることは収束しており、表1のすべてのツールはそれを念頭に選ばれた。これはまた警告でもある。人間の専門家なら見事に操れるであろう風変わりなフレームワークは、しばしばまさにエージェントが最も弱い場所である。それを最も見てこなかったからだ。

3.3 なぜ独立したゲートは相乗するのか

連鎖はいかなる単一のチェックも信頼しない。それは、真に異なるものを見る複数のゲートを通して変更を検証する。型チェッカーは形を検査し、継続的インテグレーションのテストは振る舞いを検査し、プレビューデプロイメントは稼働する結果を示し、人間のレビュアーは意図を判断する。ゲートはおおむね独立しているので、その見落としは加算されるのではなく乗算される。欠陥が本番に届くのは、あらゆるゲートがそれを捕え損なった場合に限られる。それゆえ、それぞれが見るものの大半を捕える四つの穏当なゲートは、見落とすものの積のごく一部しか通過させない。これは安全工学において長く、不完全な防壁の重ね合わせとして知られてきた多層防御の原理であり(Reason, 2000)、鋭い実践的な帰結を持つ。一つのゲートを取り除いたり弱めたりすること、すなわちプレビューを飛ばす、厳格な型をオフにする、読まずに承認することは、わずかなリスクを加えるのではない。それは、そのゲートがかつて捕えていたものの逆数だけ、すり抜け率を乗算する。安全を保つ最も安価な方法は、いくつもの異なる不完全なゲートを正直に保つことであり、それこそ連鎖がそうなるように按配されていることである。

4. エージェント：Claude Code はどう収まるか

Claude Code はエージェントである。すなわち、コードベースを読み、ファイルを書き編集し、コマンドを走らせ、テストを実行し、プルリクエストを開く道具であり、指示から働き、自らが見る結果に照らして自らを正す。それがどう運用されるかは、モデルの生の能力よりも重要であり、それについて実務家の注意に値することが三つある。

第一は文脈である。エージェントは、あなたのコードベースについて知っていることと同じだけしか優れていない。そして単一の最もレバレッジの高い成果物は、チェックインされた規約ファイル、我々の場合はプロジェクトの CLAUDE.md であり、それはエージェントに家のルールを告げる。プロジェクトがどう配置されているか、型チェッカーとテストをどう走らせるか、何をどうデプロイするか、何に決して触れてはならないかを。エージェントは毎回の実行でそれを読むので、一度書き留められた訂正は再発しなくなる。その周りには、より広い面がある。繰り返されるタスクのための再利用可能なスキル、ルールを機械的に強制するためにツール呼び出しで走るフック、そして GitHub を含む外部システムへの型付きアクセスをエージェントに与え、画面スクレイピングによってではなく第一級のアクションとしてプルリクエストを開き更新できるようにする MCP サーバーである。文脈エンジニアリング、すなわちエージェントが何を知り何をなしうるべきかを決めることは、エージェントを採用することの本当の仕事であり、それはありふれたソフトウェアの衛生である。規約を書き留め、チェックを走らせられるようにし、面を小さく保つことだ。

第二は、エージェントが孤立してではなくループの中で走ることである。それは、型チェッカーとテストを自ら走らせ、それらが報告するものを読み、人間が見る前にそれを直すことを期待されており、そのため連鎖の自動ゲートは、プルリクエストが開かれるときにはすでに緑色になっている。より大きなタスクに対しては、それぞれが自らの文脈を携えて報告するサブエージェントへと作業を広げることができ、それによって主スレッドは焦点を保ち、文脈は清潔に保たれる。規律とは、速く安価なフィードバック、すなわち型とテストをエージェント自身のループの中で起こさせ、遅く高価なフィードバック、すなわち人間を最後に取っておくことである。

第三は、それがどこで走るかである。ターミナルを越えて、Claude Code はモバイルアプリから到達可能なクラウドセッションとして走り、それが働く一日の形を変える。変更はどこかへ向かう途中の電話から開始され、クラウドで走るに任せられ、そのプルリクエストとプレビューが後に同じ電話からレビューされ承認されうる。我々がこれについて意図的であるのは、モバイルでの作業が目新しいからではなく、それがループを短くするからである。何かに気づいてから変更を開始するまでの間隔、そして変更が準備できてから誰かがそれを承認するまでの間隔が、何時間から数分へと縮む。それは検証に拘束された世界においては、まさに閉じる価値のある間隔である。

5. 背骨：GitHub

GitHub は、他のすべてを安全にする連鎖の部分であり、最も華やかさに欠ける。それは単一の信頼できる情報源、すなわちリポジトリを保持し、議論全体が依拠するルールを強制する。出荷する当のものである main ブランチは保護されており、人間が承認し、その必須のステータスチェックが通過したプルリクエストを通してのみ到達できる。エージェントは本番コードを直接編集することは決してない。それはブランチ上で提案し、その提案は人間が読める差分であり機械がテストできる差分である。

必須のチェックこそ、自動ゲートが宿る場所である。あらゆるプルリクエストで、GitHub Actions は、何かがマージされる前に我々が要求するスイートを走らせる。型チェッカー、リンター、テストスイート、そして本番ビルドであり、そのそれぞれが、緑色になるまでマージボタンをブロックする必須のステータスである。これらは誰かの規律によってではなくプラットフォームによって強制されるので、急いでいても飛ばすことができず、そしてエージェントはそれらが走ると知っているので、まずそれらを満たす。プルリクエストは変更の単位である。小さく、自己完結し、個別にレビュー可能で個別に取り消し可能であり、それがレビューを安価に、履歴を読みやすく保つ。そして、あらゆる変更が作者とメッセージを伴うコミットであるので、履歴は監査証跡であり、取り消しは完全である。エージェントが行ったことは何であれ、見ることができ、帰属させることができ、取り消すことができる。コーディングエージェントは、速く強力で誤りうる行為者であり、GitHub は、それが行うことが何も未レビュー、未テスト、取り消し不能でないことを保証することによって、一つを解き放つことを安全にする構造である。

6. 目：Vercel

差分を読めば何が変わったかはわかる。だが変更が何をするかはわからない。Vercel はそのギャップを、あらゆるプルリクエストをプレビューデプロイメントへとビルドすることによって閉じる。すなわち、変更が適用された、アプリケーションの完全で隔離された稼働中のインスタンスであり、それ自身のURLで、自動的に作成され、プッシュのたびに更新される。これは、型とテストが捕えないものを捕えるゲートである。壊れたレイアウト、一手順長くなったフロー、技術的には正しいが使用においては誤っているもの。そしてそれこそ、連鎖が盲目のまま進むことなく速く進める理由の大半である。レビュアー、そしてエージェントは、コードから想像するのではなく、実際の結果をクリックして回る。

プレビューを信頼できるものにするのは、それがモックではなくスタック全体の現実のビルドであることだ(図2)。同じフレームワーク、同じランタイム、それ自身の環境変数、そして、うまくやれば、それ自身の隔離されたあるいはブランチされたデータベースであり、それを行使しても本番データに触れられないようにする。デプロイメントは不変である。それぞれが別個のアドレス可能なビルドなので、レビューされたプレビューを本番へ昇格させることは、再ビルドではなくポインタの移動であり、まずいリリースは、慌ただしいホットフィックスではなく、前の不変なデプロイメントへの即座のロールバックである。main ブランチへのマージの際、プレビューをビルドしたのと同じ機構が本番をビルドするので、レビューされたものがそのまま出荷されるものである。この連鎖のモデルにおいて、プレビューデプロイメントは、他のいかなるゲートも見ないクラスの欠陥に対して高い捕捉率を持つ、安価で自動的な検証ゲートである。

7. git によるシームレスさ：なぜ三つは組み合わさるのか

Claude Code、GitHub、Vercel が、三つの道具というよりも一つのシステムのように感じられる理由は、それらが単一のインターフェースを共有していることにあり、そのインターフェースが git である。Claude Code の自然な出力はデプロイメントではない。それはブランチとプルリクエストである。GitHub の仕事は、それらのコミットを保存し、チェックを走らせ、レビューを保持することである。Vercel はリポジトリを監視し、あらゆるブランチをプレビューへ、main ブランチを本番へと変える。そのいずれも、互いについて教えられる必要はなかった。エージェントはデプロイメントAPIを学ぶことはなく、プルリクエストを開く。Vercel はエージェントについて学ぶことはなく、リポジトリを監視する。それらのあいだの継ぎ目は、三つすべてがすでに話す git プロトコルであり、それゆえ連鎖にエージェントを加えてもデプロイの仕組みは何も変わらず、プロンプトから本番までの全経路に引き継ぎが一つもないのである。

その帰結は、デプロイメントが誰かが行う一つの手順であることをやめ、彼らがいずれにせよ取ろうとしていた git のアクションの帰結になることである。プッシュはビルドである。プルリクエストは、自ら作成され取り壊されるプレビュー環境である。main ブランチへのマージは本番デプロイである。リバートはロールバックである。誰もリリースを実行しない。彼らはマージし、リリースは起こる。世話を焼くべきビルドサーバーもなく、エージェントが誤りうるデプロイスクリプトもなく、別個の昇格ツールもなく、誰かがコードを書いたがまだ出荷していないという窓もない。検証に拘束されたチームにとって、これはまさに摩擦を取り除くべき正しい場所である。経路に残された唯一の意図的で人間的な行為はレビューであり、それは意図的であるべき唯一の行為であって、その周りの機械的なものはすべて、git を監視する道具によって処理される。

これはまた、そのシームレスさが無謀ではなく安全である理由でもあり、二つの性質は同じ事実から来ている。デプロイメントが git に乗っているので、それは git の保証を受け継ぐ。あらゆる本番デプロイは、作者とメッセージを伴う、レビューされた特定のコミットに結びついている。あらゆるプレビューはブランチに結びついている。そしてデプロイメントは不変なので、ロールバックとは本番を単により早いコミットのビルドに向けることにすぎない。変更が、誰もデプロイコンソールに触れることなく、電話で打たれたプロンプトからライブサイトへと流れることを可能にするのと同じ配線が、レビューされ帰属可能で取り消し可能なコミットを通してでなければ何もそのライブサイトに届かないことをもまた保証する。この統合が噛み合うのは、ベンダーがそれを調整したからではなく、三つすべてが git を信頼できる情報源として扱うように作られていたからであり、エージェントがその慣習に加わったとき、それが必要とするパイプラインはすでにそこにあったのである。

8. 地形：Next.js

エージェントはコードベースを渡り歩かねばならず、コードベースのフレームワークはその地形である。Next.js が強力な選択であるのは、いずれも検証に立ち返る二つの理由による。第一は、それが TypeScript であり、型が最初かつ最も安価なゲートであることだ。厳格モードで走らせると、型チェッカーは、誤った形、欠けたフィールド、null でありうる値といった、大きなクラスの誤りを、エージェントがそれを書くまさにその瞬間に却下する。それはちょうど、訂正が最も安価であるとき、すなわちコードが走る前、そして人間が見るよりずっと前である。我々は同じ考えをプログラムの縁にまで押し進め、外部からの入力、リクエストボディ、環境変数、データベースの行を、スキーマに照らして検証し、外部からの型のないデータが、信頼されるのではなく、境界において型付けされ検査されるようにする。ここで型は官僚主義ではない。それは、エージェントの最も一般的な誤り、すなわちもっともらしいが微妙に誤った形を、それ自らが直す赤い波線へと変えるゲートである。

第二の理由は、Next.js が慣習的であり、そのモデルは、豊かではあるが、エージェントがそれを流暢に書くほどには踏み固められていることだ。そのモデルについて具体的であることには価値がある。多くのエンジニアリングがそこに宿るからだ。App Router は既定でサーバー上でレンダリングする。Server Components はサーバー上で走り、そのコードをブラウザに決して送らず、データアクセスとシークレットをサーバー側に保つ。一方、明示的にマークされた Client Components は対話性を担う。ミューテーションは Server Actions、すなわちフォームやボタンが直接呼び出せるサーバー関数を通って行き、Route Handlers がAPIの面を提供する。各ルートは、どうレンダリングするか、すなわちビルド時に静的に、スケジュールに沿って漸進的に再生成されて、あるいはリクエストごとに動的に、そしてどこで走るか、すなわちユーザーに近い軽量な Edge ランタイムか、より充実した Node.js ランタイムかを選び、認証やロケールといったものを扱うためにリクエストの前に走る middleware を伴う。これらは多くのレバーだが、公開され、文書化され、安定したレバーであり、エージェントは大規模に正しく使われるのを見てきたので、正しいものに手を伸ばす。そしてフレームワークは、現実の製品を作れるほど強力でありながら、エージェントが最も有能である地形であり続ける。それは第3節の議論によれば、重要となる組み合わせである。

9. 状態：Postgres

上述のすべてはコードに関わるものであり、コードはバージョン管理され可逆であるがゆえに変更して安全である。データはそうではない。落とされた列やまずいマイグレーションは、いかなるコミットも復元できないものを破壊しうる。Postgres は連鎖の底にある永続的でトランザクショナルな状態であり、それをめぐる規律は、コードをめぐるものより意図的に厳格である。PostgreSQL は、連鎖の残りと同じやり方でその居場所を獲得する。それは慣習的で、実戦で鍛えられ、見事に文書化された選択であり、それゆえエージェントはそれに対して正しい SQL と正しいマイグレーションを書き、マネージドなインスタンスは、モデルを変えることなく運用上の労苦を取り除く。

注意は変更に注がれる。スキーマの変更はマイグレーションである。すなわち、順序づけられ、バージョン管理され、リポジトリにチェックインされ、他のあらゆる変更と同様にレビューされ、本番の前にプレビューに対して走らされ、可逆であるように書かれたファイルである。稼働中のデータベースは、新しいものと同じようには変更できないので、危険な変更は一連の安全な変更として行われる。それがexpand and contract パターンである(Ambler & Sadalage, 2006)。新しい列やテーブルを追加してそこへの書き込みを始め、バックフィルし、読み取りを移し、そうして初めて、後のデプロイメントで古い形を取り除く。そうすれば、あらゆる中間ステップで稼働中のコードとスキーマは互換であり、そのステップは可逆である。Postgres は、ほとんどのスキーマ変更をトランザクショナルにすることで助けとなり、失敗したマイグレーションは、データベースを半ば変更されたまま残すのではなく、きれいにロールバックする。多数の短命な関数インスタンスがそれぞれコネクションを欲するサーバーレスの設定では、二つの運用上の点が重要である。コネクションプーラー は任意ではない。データベースには厳格なコネクション上限があり、サーバーレスワーカーの群れはさもなければそれを使い果たすからだ。そして行レベルセキュリティ は、どの行を誰が見てよいかをデータベース自身に強制させる。それは、アプリケーションがあらゆるクエリを正しく行うことに依存しない後ろ盾である。我々が守るルールは単純で、述べるに値する。エージェントはマイグレーションを提案してよいが、マイグレーションは、人間が常に全注意をもって読む唯一の種類の変更である。それは連鎖が完全には取り消せない唯一の種類だからである。

10. 人間のゲートと、それがどう破れるか

この連鎖のあらゆる自動ゲートは、人間のゲートを安価にするために存在するのであって、それを取り除くためではない。プルリクエストにいるレビュアーは、いかなるゲートも自動化しない唯一のことを行う。すなわち、変更がビジネスが実際に望んだものかどうか、そしてそれを露出させて安全かどうかを判断することであり、それは型、テスト、プレビューが情報を与えはするが答えはしない問いである。連鎖の全目的は、そのレビュアーに、小さく、稼働中で、事前にチェックされた変更を届け、判断が速く、十分な根拠を持つものになるようにすることである。だがゲートには特徴的な故障様式があり、それらを名指すことは、連鎖をうまく使うことの一部である。

第一はゴム印である。エージェントがたいてい正しいとき、レビュアーは速く承認することを覚え、レビューは何も捕えない形式へと堕する。防御は、変更を小さく保ち、それをきちんと読むことが安価であり続けるようにすること、そしてプレビューを任意ではなく必須のものとして扱うことである。稼働中の変更をクリックして回らなかったレビューはレビューではない。第二は過信であり、コードが型チェッカーとテストを通過したのだからそれは正しいに違いない、という信念である。それらのゲートは形と振る舞いを捕えるが意図は捕えず、人間は意図に対する唯一のゲートである。第三はスケール疲れである。エージェントは、チームが真剣にレビューできるよりも多くのプルリクエストを開くことができ、半ばレビューされた変更のバックログは、検証に拘束された体制が自らを再主張したものである。答えは、より速くレビューすることではなく、より意図的に生成すること、すなわちチームが実際に検証できるものだけをエージェントに生み出させることである。未検証の変更は、その量がどうであれ負債だからだ。

11. コストとトレードオフ

連鎖は一連の選択であり、誠実さはそれらが何を犠牲にするかを述べることを要求する。最も明白なのは結合である。Next.js と Vercel は同じ会社から来ており、それらの上に築くことは、滑らかで統合された経路を、ある程度のロックインという代償で買う。それは、速く動き時に主要バージョン間で互換性を壊すフレームワークへの、そして、その価格設定とプリミティブを採用することになるホスティングプラットフォームへの、両方へのロックインである。我々はその取引を、速度とプレビューループの質のために価値があると判断するが、それは現実の依存であり、チームは、フレームワークとホストが製品ではなく置き換え可能なインフラであり続けるよう、そのドメインロジックとデータをポータブルに保つべきである。第二のコストはゲートが要求する規律である。連鎖は、それが帰結するレビューと同じだけしか安全ではなく、人間のゲートがゴム印へと朽ちるに任せるチームは、自信に満ちた誤りを出荷する速い道を持つことになり、それは熟慮されたものを出荷する遅い道より悪い。第三はエージェントのアクセスである。リポジトリを編集しデプロイメントを引き起こせる道具は強力な行為者であり、それはそのように範囲を限られねばならない。ブランチ保護を伴い、最小権限の資格情報を伴い、シークレットをリポジトリの外、エージェントの手の届かぬ所に保ち、そして権限とインフラの変更をとりわけ注意深くレビューして。第四はデータの不可逆性であり、上で扱った。連鎖の安全網が穴を持つ唯一の場所であり、最も多くの人間の注意を費やすべき場所である。これらのいずれも、連鎖を採用しない理由ではない。それぞれが、意図的にそれを採用する理由である。

12. 我々はいかにして Nashua 360 プラットフォームをその上で運用するか

本稿の連鎖は、我々が理論化した提案ではない。それは、我々が自社製品を構築し運用している当のものである。Nashua 360 Enterprise Platform は、Vercel にデプロイされ、Postgres に支えられ、そのソースを GitHub に置く Next.js アプリケーションであり、エージェントとして Claude Code を用いて、変更がデスクを離れて開始あるいは承認される方がよいときにはモバイルアプリからも含めて開発されている。チェックインされた規約ファイルがエージェントに家のルールを告げる。プラットフォームへのあらゆる変更はブランチとプルリクエストである。あらゆるプルリクエストは、その型チェック、その継続的インテグレーションの実行、そしてスタックの隔離されたコピー上のそのプレビューデプロイメントを得る。人間が差分を読みプレビューをクリックして回ることなしに、本番ブランチへ届くものは何もない。そしてマイグレーションは、我々が最も懸命に読む変更である。我々はこの連鎖を流行だから組み立てたのではない。我々がそれを組み立てたのは、ひとたびエージェントが生成を安価にし検証を制約にしたと受け入れたとき、あらゆるリンクが、いかに速く安全に検証するかという問いから従ったからであり、そして、それを我々にとって正しいものにするのと同じ推論、すなわちエージェントがうまく扱う慣習的なツールを、その誤りを捕えるループとゲートで包むことが、今日Webソフトウェアを構築するほとんどのチームにとってもそれを正しいものにするからである。それが、電車の中の電話から本格的な製品を前進させられることをもまた可能にするのは、我々がそれを選んだ理由ではないが、作業の形がどれほど変わったかの、ひとつの確かな徴である。

13. 反論と応答

これはただの継続的デリバリーに、エージェントをボルトで留めただけのものだ。 大部分は、意図的にそうである。連鎖が依拠する実践、すなわちバージョン管理、小さくレビューされた変更、継続的インテグレーション、プレビューとロールバックを伴う自動デプロイメントは、現代のソフトウェアデリバリーの確立した規律であり(Humble & Farley, 2010; Forsgren et al., 2018)、そしてそれこそが要点である。エージェントはその規律を置き換えるのではなく、それへのプレミアムを引き上げる。エージェントの速度がいまや要求する検証を供給するのは、その規律だからである。貢献は新しい実践ではなく、ひとたび生成が安価になれば、古い実践がより少なくではなくより多く重要になる理由についての議論である。

より優れたモデルがツールを不要にするだろう。 そうはならない。ツールは、より優れたモデルが触れない部分に取り組むからである。より有能なエージェントはより速く生成するが、検証に拘束された世界では、より速く生成することは実際に出荷されるものを上げない。より速く検証することだけがそれを上げる。より優れたモデルはまた、人間がチェックすべきより多くのコードを、より速く生み出し、それはゲートをより少なくではなくより多く必要にする。連鎖は検証への賭けであり、その賭けは、生成が改善するにつれて、より悪くなるのではなくより良くなる。

あなたは一つのベンダーのスタックにロックインされている。 部分的にはそうであり、我々はそう述べた。Next.js と Vercel の結合は、現実の利益、すなわち議論全体の中心である統合されたプレビューループのために受け入れられた現実のコストである。緩和策は、本質的なロジック、すなわちドメインコードとデータベースをポータブルに保ち、フレームワークとホストを置き換え可能なインフラとして扱うことである。異なるリスク選好を持つチームは、連鎖の形、すなわちエージェント、バージョン管理、隔離されたプレビュー、型付きフレームワーク、レビューされたデータベースを、他のコンポーネントの上に保つことができる。

14. 限界

これは実務家に向けた助言であり、その限界は述べておくべきである。それは我々自身の使用に根ざした論証された推奨であって、統制された比較ではない。我々は連鎖を代替案に照らして測定してはいない。具体的なツールは2026年後半時点のものであり、これは動きの速い分野である。議論、すなわち検証が制約であること、そして連鎖はループとゲートとして読まれるべきであることは、いかなる特定のツールよりも長く持つことを意図しているが、特定のツールは変わるだろうし、読者は議論を保ち、部分を再検討すべきである。推奨は、我々が構築する種類のソフトウェア、すなわちデータベースを伴うWebアプリケーションに範囲が限られており、異なる制約を持つ領域、たとえば検証ゲートのコスト自体が法外である系や、いかなるエージェントもそのスタックを十分に見ておらず信頼できない領域には、より直接には及ばない。そして連鎖の安全性は、連鎖が安価にするが自動にはできない人間のゲートに依拠する。そのゲートを正直に保つことを厭うチームは、安全性なしの速度を見込むべきである。

15. 結論

コーディングエージェントはソフトウェアを書くことを速くし、そうすることで難所を明るみに出す。かつて一日を支配していた部分である生成は安価になる。検証、すなわち何を作るかを決めることと結果が正しいと確信することは、そうはならず、制約となる。ツールへの教訓は、AI支援環境の価値はエージェントにではなく、その周りの連鎖、すなわちチームがエージェントの生成する速度で検証し、その誤りをユーザーがそうする前に捕えることを可能にする連鎖にある、ということだ。我々はそのような連鎖の上で Nashua 360 プラットフォームを構築し運用している。書くための Claude Code は、チェックとともにループの中にあり、電話から到達可能である。GitHub は、保護されたブランチの背後で、あらゆる変更をレビューされ可逆な差分にする。Vercel は、あらゆる変更にそれ自身の稼働中プレビューを、あらゆるリリースに即座のロールバックを与える。Next.js は、型付きで慣習的な地形であり、その型が最初のゲートである。そして Postgres は、レビューされ可逆なマイグレーションを通して変更される永続的な状態である。各リンクはループを閉じるかゲートを加え、ゲートは独立しているのでそのいずれも完璧である必要はなく、そして全体は、この瞬間に固有の基準、すなわちエージェントにとって慣習的なツールこそが有能なツールである、という基準で選ばれている。速く書き、より速く検証し、人が稼働を見ていないものを何も本番に届かせるな。それがすべてであり、それで十分である。

付録 A. 導入チェックリスト

以下の実践は、連鎖を単に速いだけでなく安全にするものである。いずれも新奇ではない。規律こそが価値である。

参考文献

Ambler, S. W., & Sadalage, P. J. (2006). Refactoring databases: Evolutionary database design. Addison-Wesley. ISBN 978-0-321-29353-5.

Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. In Proceedings of the 35th International Conference on Software Engineering (ICSE) (pp. 712–721). IEEE. https://doi.org/10.1109/ICSE.2013.6606617

Beck, K. (2000). Extreme programming explained: Embrace change. Addison-Wesley. ISBN 978-0-201-61641-5.

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532

Chen, M., Tworek, J., Jun, H., et al. (2021). Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374. https://arxiv.org/abs/2107.03374

Anthropic (2026). Claude Code documentation. https://code.claude.com/docs

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations. IT Revolution Press. ISBN 978-1-942788-33-1.

Fowler, M. (2006). Continuous integration. martinfowler.com. https://martinfowler.com/articles/continuousIntegration.html

GitHub (2026). GitHub documentation. https://docs.github.com

Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases through build, test, and deployment automation. Addison-Wesley. ISBN 978-0-321-60191-9.

Vercel (2026). Next.js documentation. https://nextjs.org/docs

Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv preprint arXiv:2302.06590. https://arxiv.org/abs/2302.06590

PostgreSQL Global Development Group (2026). PostgreSQL documentation. https://www.postgresql.org/docs/

Reason, J. (2000). Human error: Models and management. BMJ, 320(7237), 768–770. https://doi.org/10.1136/bmj.320.7237.768

Sadowski, C., Söderberg, E., Church, L., Sipko, M., & Bacchelli, A. (2018). Modern code review: A case study at Google. In Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) (pp. 181–190). ACM. https://doi.org/10.1145/3183519.3183525

Vercel (2026). Vercel documentation. https://vercel.com/docs