自律性エンジニアリング — AIコーディングの自律性をどう制御するか

速くなったのは「書く」ことだけではない

Claude Code や Codex のようなコーディングエージェントを使い始めると、多くの人がまず「コードを書くのが速くなった」と感じます。しかし、使い込むほどに見えてくるのは、もっと大きな変化です。

エージェントは、指示された関数を一つ書いて終わりではありません。リポジトリを読んで要求を解釈し、どのファイルを変えるかを選び、テストを実行し、その結果を見て次の手を決めます。つまり、これまで人間が担っていた判断の一部を、すでにAIが担っています。

この記事では、この判断の部分を「AIコーディングの自律性」と呼び、それをどう設計し、どう制御するかを「自律性エンジニアリング」と呼んで整理します。

AIが触っているのは、コードではなくリポジトリ

エージェントが読み書きしている単位は、コードの断片ではなくリポジトリ全体です。中身は、動くコードだけではありません。

• テストコード
• API の仕様や型定義などの約束事（Contract）
• テーブル定義やドメインモデル
• コードのチェックルール（Linter、静的解析）
• ビルドとデプロイの自動化設定（CI）
• 設計ルールや開発の手順をまとめた文書

ここで重要なのは、これらの多くが「何を正しいとみなすか」を決めるものだという点です。テストは正しい振る舞いを、Linter は守るべき書き方を、CI は受け入れてよい変更の条件を決めています。

この記事では、こうした「実装の判断・制約・検証に使われる情報」をまとめて制御知識と呼びます。

変更はループになっている

エージェントの仕事は、一回で完結するものではありません。

リポジトリを読む
    ↓
解釈して、何を変えるか決める
    ↓
変更する
    ↓
検証する（テスト・Linter・CI）
    ↓
コミット／プルリクエスト
    ↓
（更新されたリポジトリが、次の作業の入力になる）

エージェント自身がコミットするか、人のレビューを経るかに関わらず、変更はリポジトリに戻り、次の作業の前提になります。この循環をコミットループと呼ぶことにします。

制約する側も、AIが書き換える

従来の自動生成のイメージでは、ルールは外側に固定されていて、AIはその中で実装だけを作るものでした。

しかし実際のエージェントは、制御知識そのものも変更します。

• 実装と一緒に、その実装を確かめるテストを書き換える
• API の実装と一緒に、その仕様も書き換える
• コードと一緒に、そのコードをチェックする Linter の設定も書き換える

テストを書き換えれば「何が正しいか」が変わり、CI の設定を書き換えれば「次から何が通るか」が変わります。つまりAIは、今回の実装だけでなく、次回以降の判断の基準にまで手を入れています。

よくある失敗が、「テストが通らないので、テストの期待値の方を直して通した」というものです。人間がやっても問題ですが、AIは悪意なく、しかも高速にこれをやります。

自律性は、すでにそこにある

ここまでを整理すると、AIコーディングの自律性は「AIが勝手にコードを書くこと」ではありません。次のような判断のそれぞれに現れます。

• 要求とリポジトリの状態をどう解釈するか
• 何を変え、何を変えないか
• どう実装し、どう検証するか
• テストや仕様まで変える必要があるか
• 検証結果を十分とみなすか
• このまま進めるか、止まって人に相談するか

一部に人の承認が必要でも、AIに委ねられた判断がある限り、そこには自律性があります。問うべきは「AIに自律性を持たせるべきか」ではなく、すでにある自律性をどう扱うかです。

リポジトリは「刑務所」ではなく「開拓村」

AIを入れた直後から、高品質な開発が回るわけではありません。最初のリポジトリには、たいてい次のような穴があります。

• 仕様があいまいで、どこまでが約束か分からない
• テストが大事なケースを押さえていない
• コードのチェックが、書式のような表面的な点にとどまっている
• どこからどこまでがどの層の責任か、明文化されていない
• どういうときに人へ相談すべきか、決まっていない

人はAIの成果物を直すだけでなく、こうした穴も埋めていきます。埋めた結果はリポジトリに残り、次のAIはより良い前提で仕事を始められます。

このとき、制約を「AIを閉じ込める壁」と考えると、設計を誤ります。制約を増やすほど安全になるが、AIにできることは減っていく、という発想になるからです。

むしろリポジトリは、開拓村に近いものです。最初は道路も制度もない。人とAIで少しずつ道を通し、境界を引き、検査の仕組みを作っていく。それらは行動を禁止するためではなく、後から来る人やAIが、安全に、より広い範囲で動けるようにするためのインフラです。

自律性エンジニアリングとは

ここまでの前提に立つと、自律性エンジニアリングは次のように定義できます。

AIが開発の中で担っている判断を、目的と、受け入れられるリスクの範囲に収めるための仕組みをつくること

ポイントは、制御知識もAIによって変更されるという前提に立つことです。だから、ルールを並べるだけでは足りません。設計すべきことは三つあります。

1. 初期設計：最初の「形」を与える

新しいリポジトリには、まだ十分な制御知識がありません。そこで、テストの構成、CI の設定、仕様の書き方、設計ルールの書き方などのテンプレートを用意します。

目的はすべてを網羅することではなく、「何を、どこに、どう書き、どう検証するか」という型を最初に与えることです。型があれば、そこからのズレに気づけます。

2. 運用制約：制御知識の扱い方を決める

型を用意しても、AIがそれを自由に書き換えられるなら意味がありません。そこで、制御知識をどう使い、いつ変えてよいかを決めます。

• 機能を実装する前に、仕様（Contract）を書く
• 不具合を直すときは、まず再現するテストを書く
• 通すためだけに、テストや Linter を緩めない
• 既存のルールと要求がぶつかったら、黙ってルールを変えずに相談する

運用制約そのものもリポジトリに置かれ、変更されうるものです。少なくとも「ルールを変えた」ことが差分として見え、その理由を要求までたどれる状態にしておきます。

3. 調整：ズレを、根拠をもって直す

初期設計と運用制約だけで、すべての変更を事前に決めることはできません。実装が仕様を満たさないこともあれば、要求が変わって仕様の方が合わなくなることもあります。

調整とは、要求・検証結果・レビューを根拠に、制御知識と成果物の整合をとることです。実装を直すこともあれば、要求の変化を根拠に仕様と実装の両方を直すこともあります。ただし「通すためにルールを緩める」のは調整ではありません。

テストや静的解析は、ズレを機械的に見つけます。一方、ルールとして書き切れていない食い違いや「そもそもこのルールが古いのでは」という兆候は、人や別のAIが読んで初めて気づけます。何を、どの条件で見つけ、どう直すか。それ自体が設計の対象です。

ハーネスエンジニアリングとの関係

AIの出力を、テスト・仕様・Linter・CI などで検証し、制約するという考え方は「ハーネスエンジニアリング」として広まりつつあります。プロンプトだけではAIを安定して制御できず、正しさは外側の仕組みで確かめる必要がある。この指摘は非常に重要で、自律性エンジニアリングもその上に立っています。

違いは、ハーネスをどこに置くかです。

	ハーネスエンジニアリング	自律性エンジニアリング
最初に問うこと	生成物をどうチェックし、縛るか	AIはどんな判断を担っているか
見ているもの	AIが作ったもの	作ったものと、それを縛るルールの関係
テストやCIの位置づけ	AIの外にある検査装置	AIも書き換える、設計し続ける対象

AIから見れば、ハーネスは外から据え付けられた検査装置ではありません。自分でも手を入れられる、開発システムの部品の一つです。だから、ハーネスを用意するだけでなく、それをどう育て、どう変更を受け入れるかまで設計する必要があります。

まとめ

• AIコーディングで起きている変化の核心は、生成の速さではなく、AIが判断を担ってリポジトリを次の状態へ進めることにある
• AIは実装だけでなく、テストや仕様、CI などの制御知識も書き換える
• 自律性はすでに存在する。問題は、それをどう制御するか
• 制御の設計には、初期設計・運用制約・調整の三つがある
• 制約は、AIを閉じ込める壁ではなく、AIが安全に活動範囲を広げるためのインフラである

AIに任せる範囲を広げたいなら、AIを縛る方向ではなく、AIが正しく判断できる「村」を一緒に作っていく方向で考えるのが近道です。

Honeysolでは、こうした考え方をもとに、AIエージェントを開発や業務に取り入れる組織づくりを支援しています。詳しくはAI推進コンサルティング・DXをご覧ください。