VWork バイブコーディングフレームワーク

AIエージェントに業務システムの改変を任せるなら「触ってよい範囲」を宣言する設計にする

Claude Code のようなAIエージェントに、既存の業務システムを「直しておいて」と任せる場面が増えました。速くて便利ですが、エージェントが“全部”触れる状態だと、意図しない表を消したり、想定外の箇所を書き換えたりする事故が起きます。

対策はプロンプトの工夫ではなく、設計側で“触ってよい範囲”を宣言的に絞ることです。この記事では、実運用しているパターンを紹介します。

問題：LLMは強力だが確率的

AIエージェントは指示を「だいたい」正しく実行しますが、確率的です。「顧客テーブルだけ触って」と頼んでも、文脈次第で別の表に手を伸ばすことは起こり得ます。プロンプトの“善意”に安全性を委ねるのは危険です。

→ 「できること」をコード側で物理的に制限する（最小権限の原則をAIエージェント運用に持ち込む）のが本筋です。

パターン：allowlist を宣言し、入口で弾く

設定ファイルに 「対象の表・列・操作」だけを宣言（allowlist） し、宣言外はコードからもCLIからもブラウザからも実行できないようにします。

# 例: DB管理ツールの宣言(イメージ)
tables:
  customers:
    columns: [name, phone, note]   # これ以外の列は触れない
    operations: [select, update]   # delete や drop は宣言外＝不可

こう設計すると、AIエージェントに「顧客の電話番号を直しておいて」と任せても、

つまり、エージェントが暴走しても“設計で許した範囲”より外は壊せない。実際、1ファイルのDB管理ツール kdbagent はこの方式で、phpMyAdminのような万能ツールとは逆に「宣言した表・列・操作だけ」を通します。

設定を1か所に集約し、AIはそこだけ変える

改変対象を設定ファイルに集約しておくと、AIエージェントに頼む範囲が明確になります。

ロジック本体ではなく宣言（設定）を変える運用にすると、レビューも差分も小さくなり、AIに任せても安全性が保てます。

実装の勘所

  1. 宣言（allowlist） … 表・列・操作・対象を設定ファイルで明示
  2. 入口で検証 … 人・CLI・HTTP APIのすべての入口で同じ宣言を通す（片方だけだと抜け道になる）
  3. AI向け設計マニュアルを同梱 … 「どこを・どう変えてよいか」をエージェントが読める形で置く

この3点で、「AIに任せる速さ」と「壊れない安全性」を両立できます。

試す・使う

こうした“宣言で範囲を絞る”設計の業務システムは、ソースコード同梱・MITライセンスで配布しています。AIエージェント向けの設計マニュアル付きなので、買ってから自分やClaude Codeで安全に改変できます。