Atsushi Nakatsugawa
May 05, 2026
1 min read
May 05, 2026
1 min read
共有
Policy-as-code: The missing layer in AI-assisted developmentの意訳です。
エンジニアリングチームには基準があります。
問題は、それらの基準の多くが、いまだにWiki、オンボーディングドキュメント、アーキテクチャページ、そしてレビュアーの記憶の中にしか存在しないことです。サービスがどのように通信すべきか、リスクの高い変更にはどんなテストが必要か、どの依存関係が許容されるか、良いプルリクエストとはどのようなものかについてのガイダンスは、どこかにあるはずです。
シニアエンジニアはパターンを知っています。経験豊富なレビュアーは、たいてい何かが噛み合わないときに気づけます。新しいメンバーは、コメントや事例、そしてそれなりの量の言い伝えを吸収しながらルールを学んでいきます。
長い間、チームはそれでなんとかやってこられました。完璧ではありませんが、機能はしていました。
しかし、コードの生産が手作業から生成へとシフトしていく中で、その状態に留まり続けるコストは静かに増し続けています。基準は誰かがWikiを更新するよりも速く侵食され、レビューコメントは四半期ごとに同じ議論を繰り返し、アーキテクチャ図に書かれていることと、実際のコードベースの姿との乖離は、スプリントを重ねるごとに広がっていきます。基準は暗黙知から強制可能なガードレールへと移行する必要があり、その移行のための時間的な猶予は、多くのチームが認識しているよりも速く失われつつあります。
よくあるプルリクエストを考えてみましょう。あるチームが、サポートワークフローを高速化するために、課金データベースから直接読み取りを行うコードを追加しました。テストは通り、機能は動きます。あるレビュアーはこれを実用的なショートカットと見ます。別のレビュアーはアーキテクチャ違反だと考えます。さらに別のレビュアーは、境界の問題にまったく気づきません。
チームの基準が「ドメインを直接横断するのではなく、承認されたサービスインターフェースを使う」だったとしても、その基準が文章と記憶の中にしか存在しないなら、強制力はその日たまたまレビューを担当した人次第になってしまいます。
これは以前から問題でした。変わったのは、その規模です。
今や、すべてのエンジニアが自分のマシンで、誰にも見えないセッションの中で、プライベートなコーディングエージェントを動かしています。エージェントは毎朝、何も知らない状態で起動します。昨日組み立てた推論、検討した代替案、スタンドアップで決めた事項——すべて消えています。開発者の毎朝の最初のタスクは、組織のどこかにすでに存在するコンテキストを再構築し、その日の終わりにリセットされるウィンドウに貼り付けることになっています。
その結果、加速するのはコードだけではなく、基準からの乖離も同じように加速していきます。人間のチームは、数週間かけて少しずつ足並みが乱れていきます。一方、AIのチームメイトはわずか1営業日でそれが起きており、業界はそれを「高い生産性」と呼んでいるのです。
組織が「エンジニアリング基準」と呼ぶものの多くは、ただの善意にすぎません。それらは基準を覚えているレビュアーがいる限りでしか持続せず、今や、開発者がその朝エージェントセッションに貼り付けるのを覚えていたコンテキストが続く限りでしか持続しないのです。
直感的には、これをプルリクエストレベルで解決しようとしがちです。ゲートで違反を捕まえ、レビューステップを追加し、より良いテンプレートを書く、というアプローチです。
これは間違った場所で問題と戦っています。
PR段階での強制は、事後の違反を捕まえるだけです。より良い介入は、エージェントが1行でも書く前にルールを理解させることです。コンテキストのないコードベースをエージェントに渡せば、出力されるのは、もっともらしく見えるが、チームが2年かけて確立したすべての慣習を見落としたコードです。同じエージェントに、コードベースに加えてアーキテクチャ上の決定事項、チケット履歴、障害対応の手順書、そして古い認証サービスを廃止することをチームが決めたSlackスレッドを渡せば、出力はチームメイトが書いたかのように見えます。
現状、開発者はそのコンテキストを毎セッション手動で組み立てており、自分のエンジニアリング組織と、本来であればすでに知っているはずのツールとの間で通訳のような役割を果たしています。それがギャップです。モデルの問題ではありません。PRテンプレートの問題でもありません。欠けているのは、作業が始まる前にエージェントが何を知っているかを規定する、持続的で共有されたコンテキストの層です。
多くのチームは、共有Wikiや、エージェントが各セッションの開始時に取り込むプロジェクトレベルのファイルに頼ろうとします。何もないよりはマシですが、見た目ほどの差はありません。ドキュメントは、誰かがそれを書こうと座ったその瞬間にチームが知っていたことのスナップショットにすぎません。速く動くエンジニアリング組織では、その瞬間はあっという間に過去になり、最後の更新と今日の間を埋めるのは、まさに最も重要でありながらも、誰にも記録されないコンテキストなのです。
CodeRabbit Agent for Slackは、まさにその前提に基づいて構築されています。開発者ごと、セッションごとに何もない状態から始まるツールではなく、チームが普段からやり取りしている場所にエージェントを持ち込み、計画、コード生成、レビュー、調査というループを、セッションをまたいで持続し蓄積するコンテキストとともにカバーします。
すべてのコードレビュー、解決済みチケット、アーキテクチャに関する議論は共有ナレッジ層に蓄積され、新しいタスクに取り組むエージェントは、慣習、廃止項目、ドキュメントには残らなかった決定事項をすでに理解しています。作業はチームの誰もが見て、コメントし、再開できる形で可視化され、一人のエンジニアのブラウザタブに閉じ込められたり、ターミナルを閉じた瞬間に消えたりすることはありません。
その共有された土台こそが、ポリシーを単なる理想ではなく強制可能なものにします。とはいえ、構造もやはり重要です。
長いドキュメントは答えではありません。チームに必要なのは、シンプルに階層化されたポリシーの仕組みです。
原則が意図を説明し、ルールが期待される振る舞いを定義し、自動チェックが繰り返し可能な部分を検証し、エスカレーションパスが曖昧さや例外を処理します。
各層が重要です。原則があることで、チームは「なぜそれが存在するのか」を理解せずに機械的にルールを適用することを避けられます。ルールは原則を適用できる程度に具体化します。自動チェックが明白で繰り返し可能なケースを捕まえることで、レビュアーの負担を減らします。エスカレーションは、状況が本当に普通でないときに、判断の余地を残してくれます。
これらの層のどれかを欠けば、システム全体が弱くなります。
アーキテクチャの境界を例に取りましょう。「明確なオーナーシップとサービス境界を維持する」という原則は有用ですが、レビューを一貫して導くには抽象的すぎます。これを次のようなルールに変換します。
これで基準が運用可能になります。一部は自動的にチェックできます。ボットが禁止されたインポートを検出できます。CIが新しい依存エッジをフラグ付けできます。レビューエージェントは、プルリクエストが機密性の高いパスに触れていることに気づき、追加レビュアーを要請できます。残りはエスカレーションに回ります。チームがポリシーを一時的にバイパスしなければならない場合、プルリクエストには、どのルールがバイパスされているか、なぜか、誰が承認したか、いつ例外を再検討するかを明確に記載すべきです。
同じパターンは依存関係の管理にも当てはまります。「依存関係のリスクを最小化する」は、ルールに変換されることで実用的になります。新しいランタイム依存関係は、その存在を正当化しなければなりません。パッケージはアクティブなメンテナンスを示さなければならず、既存の機能と重複するものは、その理由を説明しなければなりません。
ツールがこれらのルールをサポートできます。しかし、それらに実効性を与えるのは、決定を可視化し一貫して評価できるPR構造です。
すべてのチームが自分たちのアーキテクチャ意図に対して行うべき、シンプルなテストがあります。新しいレビュアーがこれを一貫して適用できるか？ツールが少なくとも一部を検証できるか？両方の答えがNoなら、その基準を書き直すべきです。
チームがより明示的なポリシーに抵抗する理由の1つは、硬直化への恐れです。その懸念は理解できます。緊急事態は起こります。マイグレーションは難しいトレードオフを生みます。プラットフォームの制約は、一時的な妥協を強いることがあります。
管理されていない例外こそが、まさに基準が侵食されていく経路です。健全な例外プロセスは、形だけの儀式にすることなく、バイパスを可視化し意味のあるものにします。最良の例外プロセスは、明示的で、正当化されており、承認されており、期限が切られています。そして痕跡を残します。
その痕跡が重要です。同じ例外が繰り返し現れるなら、基準の設計が悪いか、プラットフォームに必要な機能が欠けているか、アーキテクチャが現実から乖離しているかのいずれかです。例外はただ容認されるものではなく、何かを教えてくれるものでなければなりません。
そのループがないと、チームのポリシーは形骸化していきます。誰もが原則上は厳格に扱うルール、誰もが実際には非公式に処理する例外、そして厳格さを示しながらも実際には厳格さを生まないレビュープロセス、といった具合にです。
コードレビューはかつて、主に社会的なメカニズムでした。コラボレーション、メンタリング、スタイルのフィードバック、そして少しの品質管理です。そのモデルはもはや十分ではありません。
プルリクエストは今や、エンジニアリング品質、アーキテクチャの一貫性、リスク管理を制御する主要な場所となっています。組織が何をどのような条件で本番環境に投入するかを決める瞬間です。しかしそれは、もっと長い一連の流れの中の一点にすぎません。
コーディングエージェントによる個人の生産性は、AIを採用するすべてのチームで上がっています。一方、チームレベルの生産性は停滞しています。エージェントが実際に何をしたかの共有された記録がなく、どのシステムに触れたかの可視性もなく、エージェントがエンジニアリングが実際に行われている場所にいないからです。これらを解決すれば、個人の生産性がすでに複利的に伸びているのと同じように、チームの生産性も複利で伸び始めます。
勝つエージェントは、あなたが開いた瞬間にあなたのシステムをすでに知っているエージェントです。慣習、廃止項目、ドキュメントに残らなかった決定事項を知っているエージェントです。Policy-as-codeは、それらの土台をエージェントに与える方法です。
それがCodeRabbit Agent for Slackの目指すところです。チームの組織的記憶をすべてのセッションに持ち込み、チームメイトが見える場所で作業を統治し、知識をリセットするのではなく蓄積していくエージェント。計画、生成、レビュー、調査のすべてを、チームがすでに働いている場所で、基準がすでにロードされた状態で行うのです。
基準がエージェントの作るものを形作ることができないなら、それは提案にすぎません。それ以上のものではありません。
