この記事は Dries Buytaert 氏の公式ブログ「dri.es」の翻訳記事です。Driesブログの記事一覧よりすべての翻訳記事をご覧いただけます。
AIエージェントが苦手とするのは、複雑さではありません。あいまいさです。厳格なAPIは今や重要なアドバンテージになっています。
あらゆるフレームワークのAPIは、厳格(型付きインターフェース、スキーマ、サービスコンテナ)から緩やか(文字列キー、命名規則、型なしフック)までのスペクトラム上に位置しています。厳格なAPIは初期コストが高く、ボイラープレートが多く、コードを書き始める前に学ぶことも多い。緩やかなAPIはそのコストを後回しにします——あいまいさが増し、命名規則への依存が高まり、検出・修正が難しいバグが生まれます。
AIはそのコストの負担者を変えます。ボイラープレートや学習コストはエージェントの足を引っ張りません。エージェントの足を引っ張るのはフィードバックの欠如です。動いているのに間違ったことをするコード、原因を指し示さないエラー、推測で補うしかない規則。マジックネームバインディング、型なしフック、バリデーションのない設定、コードが強制しない規則——これらはまさにそうした失敗パターンを生み出します。
マジック文字列はループを断ち切る
たとえば、DrupalもWordPressも長年マジック文字列フックを使ってきました。Drupalでは mymodule_user_login のような関数を書きます。WordPressでは関連するパターンとして、文字列のアクション名を add_action() に渡します。どちらの場合も、バインディングは言語が検証できない文字列です。
名前を間違えても、システムは黙ってあなたのコードをスキップします。エラーも、警告も、ログも何もありません。関数はただそこに存在し続けるだけです。
シグネチャは規則であって、契約ではありません。ドキュメントには user_login フックが $user オブジェクトを受け取ると書いてあっても、それを強制するものは何もありません。IDEやPHPStanのような静的解析ツールには、ただの関数に見えます。それがプラットフォームのログインフローに組み込まれているとはわからないため、間違っていても警告を出すことができません。
型付きの代替手段は、バインディングを明示的にします。登録済みサービスの #[Hook('user_login')] のようなPHP属性を使えば、クラスの存在が保証され、メソッドシグネチャは型チェックされ、コンテナが依存関係を組み立てます。IDE、静的解析ツール、AIコーディングエージェントのいずれも、属性から実装まで追跡できるようになります。
AIエージェントにとって、これはフィードバックループを試行錯誤ではなくタイトに保つことを意味します。つまり、より速く動け、デバッグに費やす時間が減り、使用トークン数も少なくて済みます。
今年3月のDrupalCon Chicagoでは、AIコーディングツールがLovableで生成したサイトを数時間でDrupalに移行しました。厳格なAPIがエージェントを正しい軌道に保ち続けたのです。
AIが存在する前に下された決断
これはAIから始まった話ではありません。2015年にリリースしたDrupal 8では、Symfonyのルーティング、サービス、イベントディスパッチャーを導入し、手続き型フックシステムの大部分を置き換えました。以来、マジックフックを減らし続けています。属性ベースのアプローチ(#[Hook('user_login')])はDrupal 11.1で登場し、残っている手続き型専用のパスをさらに除去するのに役立っています。
Drupalが厳格さを高めてきたのはフックだけではありません。Drupalは多くの設定をYAMLに保存しており、かつてはシステムの中で最も緩やかな部分のひとつでした。数年がかりのバリデーション整備によって、この部分も引き締められてきました。
エージェントがコンテンツタイプの定義やエディター設定を生成する際、バリデーションが不足しているキー、無効な値、壊れた参照を保存前に検出します。エージェントは実行時エラーではなく、問題のある正確なフィールドを指し示す明確なエラーを受け取れます。このタイトなフィードバックループこそが、DrupalをAI支援開発に強いCMSにしています。
Drupalはこの賭けを早い段階で行いました。それは痛みを伴うものでした。Drupal 7からDrupal 8への移行は後方互換性を壊し、回復に何年もかかりました。しかしそれはプラットフォームをはるかに厳格なものにしました。あれから10年以上が経った今も、私たちはDrupalをさらに厳格にし続けています。
一方、WordPressは異なる賭けをしました——厳格なAPIよりも後方互換性を優先したのです。それは長い間プラットフォームを安定させました。同時に、緩やかさも保ち続けました。
これらのトレードオフが今、AIエージェントが各プラットフォームをどれだけ効率よく扱えるかを左右しています。
かつてスタイルだったものが、今はスピードになった
かつては好みの問題だったことが、今やスピードとコストの問題になっています。緩やかなAPIはデバッグと推測を増やします。厳格なAPIは、より速く、より正確なフィードバックをもたらします。これは人間にとって常にそうでした。今やAIエージェントにとっても同じです。ただし今日、そのコストはトークン数として現れます。
— Dries Buytaert
PS: LinkedInでのディスカッションもぜひご覧ください。
この記事は「AI rewards strict APIs」(投稿日:2026-04-28)の翻訳記事です。
カテゴリ
タグ