勘所1．AIツールではなく「守るべき不変条件」を統一する

　複数のエンジニアが異なるAIツールを使う場合、ツールごとに詳細なルールを定めても、運用は長続きしにくい。

　あるエンジニアはClaudeを使い、別のエンジニアはCodexを使う。新しいAIコーディングツールが登場すれば、それを試す人もいる。特定の製品を前提に指示ファイルや作業手順を作ると、利用ツールが変わるたびにルールを更新しなければならない。

　Boundaryは、利用するAIモデルを統一する代わりに、どのモデルでも理解できる小さな「architecture.md」ファイルを用意した。

　このファイルには、細かなコーディング規則や頻繁に変わる実装方法は書かない。数カ月から数年にわたって変わらないアーキテクチャ上の原則だけを記載する。

　同社の場合は、コンパイラを構成するレイヤーや、各レイヤーの役割、レイヤー間で守るべき境界などを定義している。

　重要なのは、ファイルを極めて小さく保ち、長期間変化しない内容に絞ることだ。

　AIツールの使い方を統一するのではなく、生成されるコードが満たすべき構造だけを統一する。これが、複数のAIツールを併用する上での第1の勘所だ。

勘所2．コードではなく設計文書を厳しく管理する

　Boundaryには、「コードはスロップでもよいが、文章はスロップであってはならない」という原則がある。

　グプタ氏は、「人間が読まないコード」をSlopと定義する。生成AIによってコード量が急増すれば、全てのコードを人間が読むのは難しい。読まれないコードが増える流れ自体は止められないという考えだ。

　一方、設計書まで誰にも読まれず、内容が曖昧なままでは、複数のAIエージェントが同じ方向へ開発を進めることはできない。

　そこで同社は、コードそのものを細かくレビューする代わりに、なぜその設計を採用するのか、どの境界を守るのか、変更が他の部分にどう影響するのかを文章で明確にする。

　設計文書は単に作成するだけでは不十分だ。Boundaryは、設計書を公開するなら、他のメンバーが実際に読むことを求めている。

　AIを使えば、設計文書自体も短時間で大量に作成できる。グプタ氏自身、1日に10件ほど設計書を作成する状態になり、チームが処理し切れなくなったという。

　そのため同社は、設計書の作成数ではなく、読まれたかどうかを重視するルールへ切り替えた。

　コードレビューをなくすのであれば、設計意図を共有する工程までなくしてはならない。むしろコードを読まない分、設計文書の品質と読了を従来以上に厳しく管理する必要がある。

勘所3．設計文書を「置き場」ではなく議論の起点にする

　設計文書を厳格に管理すると決めても、文書管理ツールへ保存するだけでは、読まれないまま放置される恐れがある。そこでBoundaryは、設計書のバージョン管理やコメント機能を備えた独自ツールを構築した。設計書の実体はMarkdownファイルで、CLI（コマンドラインインタフェース）からも操作できる。

　MarkdownとCLIを採用することで、人間だけでなくAIエージェントも設計書を作成、更新しやすくしている。ただし、同社が最初に設計書ツールを作っただけでは、十分に利用されなかった。

　そこで追加したのがSlackとの連携だ。設計書が新しく作成されたり更新されたりすると、専用のSlackチャンネルへ通知が届く。

　その結果、設計書の更新を知らせるチャンネルは社内でも頻繁に閲覧されるようになった。深夜に新しい設計書が公開されると、複数のメンバーがすぐに読み始めることもあったという。

　並行開発では、他のメンバーが何を設計し、どの部分を変更しようとしているのかを早期に把握できることが重要だ。

　そこで同社は、設計書を保管するだけでなく、更新をSlackで知らせることで、他のメンバーが設計書に気付き、実際に読む仕組みにした。

勘所4．アーキテクチャ違反をレビューで見つけず、機械的に止める

　複数のエンジニアが並行してAIエージェントにコードを書かせると、コードベースには短時間で多くの変更が加わる。

　AIエージェントは要求された機能を実装できても、既存のアーキテクチャを完全に理解しているとは限らない。新しいパッケージを安易に作成したり、本来分離すべきレイヤーを直接接続したり、不必要な依存関係を追加したりする可能性がある。

　従来の開発では、こうした問題をコードレビューで見つける。しかし、コードレビューを実施しない場合、アーキテクチャ違反を検知する別の仕組みが必要になる。そこでBoundaryは、コードベースの依存関係をグラフとして可視化するツールを構築した。

　このツールは、社内のパッケージや一部の外部依存関係を表示し、それぞれのパッケージに意味的な境界を設定する。どのレイヤーがどのレイヤーへ依存できるのかをあらかじめ定義する。

　さらに、CLIツールで一定の不変条件を破れないようにし、CI/CDやGitのコミット履歴を使って問題が発生した箇所を把握できるようにしている。

　AIエージェントが禁止された依存関係を追加した場合や、内部の実装を外部へ漏らすような変更を行った場合は、CI/CDで検出する。Gitのコミット履歴を使えば、どの変更によって構造が崩れたのかも追跡できる。

　重要なのは、人間がコードを読んで違和感を見つけるのではなく、違反するコードをそもそも通過させないことだ。

　コードレビューなしで品質を保つには、「気付ける仕組み」ではなく「破れない仕組み」を作る必要がある。

勘所5．生成AIの出力だけでなく作業過程も検査する

　AIエージェントを使った開発では、最終的に生成されたコードが動作するかどうかだけを確認しても十分ではない。

　同じ結果を得るために不要な検索を繰り返したり、本来1回で済むツール呼び出しを3回実行したりしていれば、開発コストや処理時間は増える。

　また、AIが存在しない問題を報告したり、誤った原因を推測したりするハルシネーションも起こり得る。そこでBoundaryは、バックグラウンドでAIエージェントを継続的に動かし、BAMLを使ったプログラムをゼロから作成させている。

　その際、AIエージェントがどのツールを使い、どのような手順でコードを作り、どこでエラーが起きたのかを記録する。この履歴は人間が確認できるようになっているだけでなく、別の検査用エージェントが分析するようになっている。

　検査エージェントは、生成されたプログラムの正しさに加え、無駄なツール呼び出し、不要な試行錯誤、誤った問題報告などを探す。検出された問題については、人間が実際の不具合なのか、ハルシネーションなのか、設計上許容できるのかを判断する。その後、別のエージェントに修正案を作らせる。

　AIエージェントがコードを生成し、別のAIエージェントが作業を検査し、人間が判断する。この分業によって、人間が全てのコードを読むことなく、大量の変更を評価できる。

言語機能やAI向け指示をA／Bテストする

　Boundaryは、AIエージェントの実行履歴を、個別の不具合修正だけでなく、言語や開発ツールの改善にも利用している。

　新しい言語機能やAI向けの指示を導入する際、複数の方法をA／Bテストする。

　どちらの方法が少ないツール呼び出しで完了したか、どちらがエラーを減らしたか、どちらが正しい結果を安定して生成したかを比較する。

　人間が「こちらの設計の方が分かりやすい」と感覚的に判断するのではなく、AIエージェントが実際に利用した結果から評価する。

　AIツールを自由に使わせると、ツールやモデルごとに出力傾向が異なり、開発方法がばらつく可能性がある。そこで個々のAIツールの利用方法を細かく統制するのではなく、最終的な成功率やエラー数、ツール呼び出し回数を計測し、結果に基づいて仕組みを改善する。

　自由度を維持しながら品質をそろえるには、手順の統一よりも評価指標の統一が重要になる。

コードレビューの役割を分解して置き換える

　Boundaryの開発手法を、単に「コードレビューをしない」と捉えるのは適切ではない。

　一般的なコードレビューには、複数の役割がある。実装が設計意図に合っているか、アーキテクチャの境界を破っていないか、エラー処理が漏れていないか、不要な複雑さが入り込んでいないか、他の変更と衝突しないかを確認する。

　Boundaryは、これらを人手によるレビュー工程にまとめず、それぞれ別の仕組みへ分解している。

• 設計意図の共有
  • 設計文書を作成し、他のメンバーが実際に読む。
• アーキテクチャの維持
  • 依存関係グラフで構造を可視化し、CLIツールやCI/CDで不変条件への違反を検知する。
• 動作や言語機能の検証
  • AIエージェントにBAMLプログラムを継続的に作成、実行させる。
• 無駄な作業や問題候補の検出
  • 検査エージェントが作業履歴を分析し、人間が実際の問題かハルシネーションかを判断する。

　コードレビューという工程を削除するのではなく、その機能を設計、検証、観測、自動化へ分散させたと考える。

並行開発では「変更の衝突」より「意味の衝突」を防ぐ

　複数のエンジニアが並行して開発する場合、まず問題になりやすいのは、同じファイルやコードを同時に変更したことで起きるGitのマージ競合だ。しかし、マージ競合が発生しなくても、設計や責任分担が食い違うことはある。

　例えば、2人のエンジニアが別々のファイルを変更していても、それぞれが似た機能を別のレイヤーに実装すれば、重複や責任範囲が曖昧になる恐れがある。

　AIエージェントは、目の前の指示を達成するために局所的には妥当な実装を作る。一方、他のエージェントが同時に何を作っているのかまでは把握していない場合がある。

　この問題を防ぐために、Boundaryは設計書の共有、アーキテクチャ上の境界、依存関係の検査を重視する。

　どのファイルを誰が編集しているかだけでなく、どの機能をどのレイヤーに置くのか、どの責任をどのモジュールが持つのかを先に共有する。

　並行開発を成立させる鍵は、作業の重複をゼロにすることではない。重複や矛盾を早期に検知し、システム全体の構造が収束する仕組みを作ることだ。

人間はコードではなくシステム全体を理解する

　コードレビューを減らすと、「人間がシステムを理解できなくなるのではないか」という懸念が生じる。一方グプタ氏は、全てのコードを読むことよりも、人間がシステムそのものを理解することが重要だと説明する。

　大量のコードが生成される環境では、コードを上から下まで読む代わりに、システムの意味的な境界、依存関係、実行時の流れを把握できる仕組みが必要になる。

　Boundaryは、コードベースを視覚的な図として表示し、関数やモジュールの関係をたどれる仕組みを試している。利用者は全てのコードを読むのではなく、概要を確認し、必要な箇所だけを選択してソースコードへ移動する。

　実行トレースも重要になる。どの関数が呼び出され、どの処理に時間がかかり、どこでエラーが起きたのかを確認できれば、コード全体を読まなくてもシステムの動作を把握しやすい。

　コードレビューなしの開発で人間が担うのは、生成されたコードの全行確認ではない。設計や構造、制約、実行結果を見ながら、システム全体が望ましい方向へ進んでいるかを判断することだ。

エージェント向けツールは「1回で必要情報を返す」

　AIコーディングツールを使った並行開発の速度は、AIモデルの性能だけで決まるわけではない。AIエージェントが利用する開発ツールの設計にも左右される。

　既存の開発ツールは、人間が検索結果を読み、次の操作を考えることを前提としている。例えば関数について調べる場合、関数名を検索し、定義を開き、利用箇所を探し、ドキュメントを読む。AIエージェントが同じ作業をすれば、複数回のツール呼び出しが必要になる。

　Boundaryは、関数について問い合わせると、定義、ドキュメント、ソースコード、利用箇所をまとめて返す仕組みを提案する。

　外部ライブラリについても、Web検索や複数のドキュメント参照を繰り返すのではなく、実際のソースコードへ直接アクセスできる方がよいとする。

　AIエージェントが自律的に動く開発環境では、ツール呼び出しの回数が処理速度やコストに直結する。

　人間向けの操作をそのままAIへ使わせるのではなく、AIが一度に必要な情報を取得できるよう、内部ツールを作り直す必要がある。

型システムにレビューの一部を担わせる

　コードレビューでは、エラー処理の漏れや、想定外の値が入り込む可能性も確認する。

　Boundaryが開発するBAMLでは、こうした確認の一部を型システムやコンパイラに担わせようとしている。

　例えば、ある関数がゼロ除算エラーを発生させる可能性がある場合、その関数を呼び出す上位の関数も同じエラーを返す可能性があるとコンパイラが推論する。

　上位の関数でエラーを処理すれば、そのエラーがさらに上へ伝わらないことも型システムが認識する。

　APIに「エラーを返さない」という制約を設定しているにもかかわらず、処理されていないエラーが残っていれば、コンパイラが違反として検出する。

　人間がコードを読み、エラーが起きたときの処理を書き忘れていないか1つずつ確認するのではなく、コンパイラがエラー処理の完全性を確認する仕組みだ。

　コードレビューなしの開発では、人間の注意力に依存していた確認項目を、どこまで静的検査や型システムへ移せるかが重要になる。

「自由に使わせる」と「無秩序に任せる」は違う

　Boundaryは、エンジニアに利用するAIツールを指定していない。各自がClaudeやCodexなどを選び、複数の作業を並行して進める。

　ただし、自由に使わせることと、無秩序に任せることは異なる。

　利用するツールは自由でも、アーキテクチャの境界は自由ではない。コードの書き方は異なっても、設計意図の共有は必須だ。実装の進め方は異なっても、CI/CDや型システムによる検証は通過しなければならない。

　つまり、Boundaryが自由化しているのは「手段」であり、統制しているのは「結果」と「不変条件」だ。

　AIツールを標準化しない開発では、全員に同じ操作を求めるのではなく、どのツールを使っても同じ品質基準へ収束する仕組みが必要になる。

本稿は、AI Engineerが2026年7月31日に公開した動画「fighting slop with slop―Vaibhav Gupta, Boundary」を基に作成しました。