数日前、Federico Bartoliの The Canon を読んだ。AIコーディングエージェントと働くための12の原則をまとめた、短いマニフェストだ。文章は引き締まっていて主張もはっきりしていて、冒頭と同じ一文で締めくくられる。「どれも新しい話ではない。だが今や、すべて必須だ」。続けて2回読み返した。私にとって、エンジニアリングの規律について書かれた文章が本物かどうかを測る、いちばんの目安だ。
Bartoliの12の原則は、おおまかに言うと4つの動きにまとめられる。プロンプトを開く前に解決策の形を決めておくこと。一気に大きく生成させるのではなく、レビューできる小さな単位で進めること。エージェントの要約を信じるのではなく、すべてを検証すること。そして、自分の基準を毎回プロンプトで打ち直すのではなく、エージェントが実際に読み込む場所に書き残しておくこと。普段私は医療ソフトウェア向けにSymfonyを書いている。このリストを読んでも、あまり目新しさは感じなかった。すでに省けなくなっている習慣そのものだったからだ。IEC 62304と、ルールを破ればビルドを失敗させる静的解析ツールは、近道をほとんど許してくれない。だから、Bartoliの12の原則のひとつひとつは、善意ではなく何か他のものによって、すでに私に課されていた。
プロンプトの前に決める #
Bartoliの2番目の原則は「尋ねる前に決める」だ。これは医療機器ソフトウェアの世界が何十年も前から求めてきたことと、そのまま重なる。事前条件、故障モード、受入基準がはっきりするまで、コードには触らない。AIエージェントは、まだ形になっていないアイデアに対しても、それらしい実装を喜んで生成してしまう。だからこそ、このルールは正しい。ある関数が成功する前に何を拒否すべきかを一文で言い切れないなら、まだプロンプトを書く段階ではない。それより先に、本当の要件を探しに行くべきだ。
エージェントはこの規律が安全のための実践だと知らない。ただプロンプトに合わせてパターンマッチングしているだけだ。あいまいなプロンプトからは、自信たっぷりな構文で着飾られたあいまいな実装しか出てこない。そして、そのあいまいさに気付くのは、たいてい誰かのインシデントになってからだ。
小さなバッチと、唯一の証人であるdiff #
「小さなバッチで」と「diffを読む」は、むしろ控えめな言い方だと思う。すべての書き込み処理がトランザクションマネージャーを通り、すべてのオブジェクトが専用のファクトリー経由でしか構築できないプロジェクトでは、一度に12ファイルにまたがる変更はそもそもレビュー不可能だ。私はエージェントに、層単位で(ドメインオブジェクト、それからローダー、ライター、ハンドラーと)一つずつ依頼するようにしている。各ステップのdiffを頭の中に収まる大きさに保ち、記憶にあるルールのおぼろげなイメージではなく、実際のルールと照らし合わせるためだ。
Bartoliの言葉で今も頭に残っているのは「理解負債」という言葉だ。読まずに受け入れた1行行が、いつか来るインシデントに対する小さな借金になる。しかも金融の借金と違って、金利は事前には教えてもらえない。「コンパイルが通った」ことが十分な基準になったことなど一度もなかった、というのを、これほどうまく説明した文章を他に読んだことがない。
検証だけは圧縮できない #
「信じる前に実行しろ」は当たり前に聞こえるが、締切のプレッシャーの下ではエージェントの有無に関係なく、どれだけよく省略されてきたかに気付くと怖くなる。エージェントによって変わったのは原則そのものではなく、量だ。1時間あたりに目を通す「完了しました」という報告の数が増えた分だけ、しっかり検証する代わりに抜き打ちで済ませたくなる誘惑も強くなる。私は単純だが効果的なルールに落ち着いた。テストもログもトレースも指させないなら、エージェントがどれだけ流暢に語ろうと、「動いている」は仮説であって事実ではない。
ルールをコード化する #
Bartoliの11番目の原則は「ルールをコード化する」だ。毎回プロンプトに打ち直すのではなく、エージェントが読み込むファイルに規約を置く、というものだ。私の本業は、これがなぜうまくいくのかを極端な形で示してくれる。そこでは規約集は努力目標ではなく、強制力を持つ。アーキテクチャの制約――どの層がどの層に依存してよいか、どのクラスがファクトリー経由でしかインスタンス化できないか、どのフィールドが絶対にログに出てはいけないか――は、それぞれ番号が振られた独自の静的解析ルールによって裏付けられ、コミットのたびにチェックされる。文書化された規約と自動チェックは、同じアイデアの2つの半分だ。エージェントが無視できるスタイルガイドは単なる提案にすぎない。リンターが強制するスタイルガイドは、契約になる。Bartoliのこのルールは、一般形だ。私の方は、リスクの大きさゆえにそれが選択肢ではなくなったときの姿にすぎない。
たどり着いた結論 #
12の原則は、どれも成立している。規制対象で安全性に関わるソフトウェアの世界では、それらはもはや選択肢ではなく、そのソフトウェアが存在を許される理由そのものになる。もっと広い読者に向けて書かれたはずのマニフェストの中にそれを見つけるのは、なんだか不思議な感覚だった。エージェントと一緒にコードを書いているなら、ぜひ原文を読んでみてほしい。短い文章だが、その短さに見合うだけの中身がある。