CodeBuddy は、Tencent Cloud が開発し、同社自身のエンジニアが利用しているエージェント型 AI コーディングシステムである。 ファイルシステム、ターミナルコマンド、外部 API、MCP ツールにアクセスでき、自然言語の指示を通じてコードを自律的に 計画、記述、テスト、デプロイできる。
エージェント型 AI のためのモデル AI ガバナンス・フレームワーク は、これを実質的な人間による監督を設計するための 具体例として取り上げている。その理由は、あらかじめ設定された安全なデフォルトと設定可能なパーミッションを組み合わせることで、 ユーザーを過度に疲弊させることなくそうした監督を可能にしている点にある。
機能
人間による承認のデフォルト要件は、各アクションのリスクレベルに対応している。読み取り（ファイルの内容やディレクトリの一覧） には承認は不要である。ファイルの編集には、そのセッションの間だけ有効な承認が必要であり、以後のセッションでは新たな承認が 必要になる。Bash を通じたシェルコマンドの実行には承認が必要で、その承認はプロジェクト単位またはコマンド単位で恒久的に 有効となる。WebFetch を通じたネットワークリクエストには承認が必要である。MCP を介した外部ツールの呼び出しは allow、ask、 deny のルールで管理され、さらに初回利用時の制御として、新たに接続された MCP サーバーに対する信頼性の検証が加わる。
これらのデフォルトは固定されたポリシーではなく出発点である。各プロジェクトのデフォルトのパーミッションレベルは、 ユーザーや組織ごとに、プロジェクトのコンテキスト、潜在的な影響、リスク許容度に合わせて設定できる。フレームワークが 示す例では、社内ドキュメントサイトや本番環境の認証情報を持たないプロトタイプリポジトリのような低リスクのプロジェクトでは、 日常的なファイル編集についてより許容的な設定が正当化されうる一方、シークレット、機密データ、本番インフラ、 デプロイパイプライン、外部ツールにアクセスできるプロジェクトでは、より厳格な承認要件が求められる。
2 つの機能は、承認があるかどうかではなく、承認の質に向けられている。複雑なシェルコマンドが提案されると、平易な言葉による
説明によって、ユーザーは副作用も含めて自分が何を承認しようとしているのかを理解しやすくなる。フレームワークの例では、
mysqldump のパイプラインが、/backups/ 配下に日付付きの圧縮されたデータベースバックアップを作成し、root パスワードの
入力を求め、元のデータベースは変更しないものとして説明される。これとは別に、コマンドインジェクションを継続的に
リアルタイムで監視することで、以前にホワイトリストに登録されたパターンに一致するものの実質的にリスクが高いコマンドについて、
あらためて人間の承認を求めることができる。例として、ドキュメントの URL に対する curl の後に、予期しないファイルを
書き込むシェルのリダイレクトが続くものが挙げられている。
採用とエコシステム
フレームワークは CodeBuddy のパーミッションモデルを、承認疲れ（Approval Fatigue） や 自動化バイアス に対して ヒューマン・イン・ザ・ループ をいかに有効に保てるかを示す 業界の事例研究の 1 つとして提示しており、重要なチェックポイントを定め、人間が承認リクエストを評価するのを助け、 その両方を自動化された監視で補完する他の導入事例と並べて位置づけている。