コーディングエージェント時代のハーネス設計: MCP連携と可観測性の実務

QiitaやZennでは、コーディングエージェントの活用が「モデル性能」だけでなく「ハーネス設計」で差が出るという議論が増えています。実際、同じモデルでも運用品質が大きく変わるのは、実行環境の制御面が違うためです。

参考: https://qiita.com/popular-items/feed, https://zenn.dev/feed。

結論から言うと、ハーネスは補助機能ではなく本体です。ここを設計しない自動化は、速度より先に事故を生みます。

ハーネス設計とは何か

ハーネスは、モデルの外側にある実行枠組みです。具体的には次を定義します。

どのリポジトリをどこまで触れるか
どのコマンドを誰の承認で実行できるか
依存導入と外部通信をどう制限するか
テスト結果や成果物をどう保存するか
危険操作をどこで人手に戻すか

この設計なしにエージェント導入を進めると、確率的システムに過大権限を渡すことになります。

最低限必要な5つの境界

ID境界: 実行ごとの短命IDを払い出す
ファイル境界: 書き込み可能パスを明示制限
実行境界: コマンドをリスククラス別に許可
通信境界: 外向き先のallowlist制御
承認境界: 保護操作は必ず人手承認

ポイントは「慣習」ではなく「機械的強制」にすることです。

MCP連携で注意すべき点

MCPは便利ですが、信頼境界を拡張します。導入時は次を標準化します。

サーバーを信頼ティア別に登録（社内/提携/公開）
スキーマ契約とレスポンス上限を設定
ツールメタデータの署名とバージョン管理
呼び出しログにサーバーIDを必ず記録

MCPサーバーは「便利プラグイン」ではなく、本番依存先として扱うべきです。

エージェント専用の可観測性

通常のAPMだけでは不十分です。以下の指標を追加します。

計画深度とツール連鎖長
承認必要操作の回避/実施率
サンドボックス実行時間と失敗分類
ファイル変更グラフとロールバック成功率
ポリシー拒否理由と再試行挙動

このデータがあると、障害解析だけでなく改善サイクルも高速化できます。

失敗前提の封じ込め設計

エージェントは失敗します。問題は失敗するかではなく、被害を局所化できるかです。

高リスク変更はdry-run先行
タスク単位ブランチ隔離で本線汚染を防止
マージ後テスト失敗時の自動revert束
トークン/実行時間超過時の予算停止

封じ込めがあると、失敗は運用可能な欠陥に変わります。

生産性と統制の両立

最初から全面自律を狙うと、現場の信頼を失います。段階導入が現実的です。

低リスク反復作業から自動化
設計影響の大きい変更はレビュー必須
エラー率改善に合わせて自律範囲を拡張

この進め方なら、開発速度と品質の両方を守れます。

45日導入プラン

1〜15日

コード操作をリスク分類
書き込み範囲を絞ったサンドボックス導入

16〜30日

信頼済みMCP連携とポリシーチェック実装
可観測性指標の計測基盤を整備

31〜45日

低リスク業務で条件付き自律を開始
事後分析を通じて境界とルールを更新

まとめ

コーディングエージェントを本番インフラとして使うなら、ハーネス設計が主戦場です。境界制御、MCP統制、可観測性、封じ込め戦略を先に整えることで、速度を維持したまま安全に自動化を拡張できます。