AIエージェントを業務に取り入れるとき、最初に困りやすいのは機能が足りないことではありません。同じ依頼なのに結果が変わる、どの設定が効いているのか分からない、外部サービスへの接続を誰が許可したのか追えない、といった「設定の混線」です。
この混線は、指示書に業務手順を書き足し、スキルに権限を書き足し、接続設定に判断基準を書き足すことで起きます。便利そうな機能を個別に追加するほど、失敗したときに戻す場所がなくなります。そこで、エージェントの構成を一枚の台帳に分解して記録します。
AIエージェントの問題は、機能不足より設定の混線
まず「何が変われば結果が変わるか」を分けます。プロジェクト全体に適用するルールと、特定の仕事だけで使う手順は別物です。ファイルを読めることと、外部システムへ書き込めることも別の許可です。モデル名や推論の強さも、権限とは別に、作業ごとの品質と時間の条件として扱います。
この境界を曖昧にしたまま自動化すると、原因調査に時間がかかります。逆に、変更する層を一つに絞れば、失敗したときに「手順の問題か、接続の問題か、許可の問題か」を切り分けられます。
まず四つの層を分ける
構成台帳では、次の四層を別の行として登録します。
| 層 | 記録する内容 | 変更の例 |
|---|---|---|
| 常設ルール | 表記、データ境界、禁止操作、成果物の置き場所 | プロジェクト全体のルールを更新する |
| 業務スキル | 入力、手順、出力形式、検査方法 | 文字起こし記事の匿名化手順を改訂する |
| 外部接続 | 接続先、利用ツール、対象データ、所有者 | 読み取り専用の接続を追加する |
| 権限・予算 | サンドボックス、承認、時間、トークンや費用の上限 | 書き込みを承認制に変更する |
たとえば「記事を作る」という仕事なら、常設ルールに公開禁止事項を置き、業務スキルに論点分解とファクトチェックを置きます。外部接続は必要な資料を読む範囲に限定し、権限・予算には下書きのみ、書き込みは承認後、という境界を残します。これなら、記事の構成を変えても接続の許可まで変わりません。
構成台帳に残す七つの項目
台帳の一行には、最低限次の項目を入れます。
- 目的：何の作業を安定させるための設定か。
- 所有者：変更を判断する担当者またはチームは誰か。
- 根拠：社内の正本、公式ドキュメント、検査結果のどれに基づくか。
- 許可された操作：読む、変換する、作成する、送信する、のどこまでか。
- 承認境界：人の確認が必要になる操作は何か。
- テストケース：設定が守られたと判断する入力と期待結果は何か。
- 更新・停止条件：いつ見直し、どの失敗で止めるか。
「便利だから追加した」という理由だけでは、台帳の根拠になりません。目的とテストケースが書けない設定は、いったん保留にします。停止条件まで書くと、担当者が変わっても同じ判断を再現できます。
導入順は「書く→小さく試す→接続する」
最初から自動化や複数エージェントに進む必要はありません。次の順番で一段ずつ確認します。
- ローカルの読み取り専用データで、短い作業を一つ実行する。
- その作業だけのスキルを一つ登録し、期待結果を固定する。
- 必要になった接続を一つだけ追加し、対象ツールを許可リストにする。
- サンドボックスと承認の境界を、成功・拒否の両ケースで試す。
- ログを確認してから、繰り返し作業を自動化する。
各段階で台帳を更新します。接続を増やす前に、接続なしで成立する範囲を確認しておくと、原因を外部サービスへ押し付けずに済みます。
外部接続は「できること」より権限を先に見る
MCPのような仕組みは、モデルにツールやコンテキストを渡すための接続層です。接続先、利用できるツール、認証方式、承認モード、利用者を台帳に書きます。読み取りだけの作業に、送信や削除の権限を付ける必要はありません。
接続設定は個人の端末だけでなく、プロジェクト全体に共有される場合があります。変更前に「どの範囲の設定か」「誰が停止できるか」を確認し、認証情報そのものは台帳へ転載しません。接続が失敗したときは、再試行を増やす前に、対象データと許可範囲が一致しているかを見直します。
モデル選定は名前ではなくタスク単位で記録する
モデルの名称や利用条件は変わる可能性があります。そのため、台帳にはモデル名だけを固定値として置かず、作業名、許容時間、品質の下限、トークンや費用の上限、代替経路を記録します。
代表的な作業を複数選び、同じ入力で結果を比べてから切り替えます。速さだけでなく、固有名詞の保持、指示への適合、修正回数を測ります。比較できる記録がなければ、「高性能そう」という印象で設定を変えないことが安全です。
検査と停止条件を台帳に入れる
検査は最後に一度だけ行うものではありません。入力の境界、出力の形式、リンク、権限、費用を小さなテストで確認し、結果と日時を残します。同じ失敗が続く、許可範囲が変わった、予算上限に近づいた、という場合は自動処理を止めて、人が台帳を見直します。
サンドボックスと承認は別の制御です。書き込み可能な作業領域を用意しても、外部送信まで自動で許可する必要はありません。反対に、承認を求める設定でも、広すぎる作業領域を与えれば影響範囲は残ります。最小の作業領域と最小の許可から始め、必要性が説明できる場合だけ広げます。
Optiensの見方
AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断（無料） で、既存業務のどこがAIパッケージ化しやすいかをご確認ください。実装まで進めたい候補が見えた場合は、導入前スコープ整理 で対象業務、含む範囲、費用感、5営業日で初期版にできるかを整理します。
まとめ
AIエージェントの運用を安定させる出発点は、機能を増やすことではなく、設定の責任範囲を分けることです。常設ルール、業務スキル、外部接続、権限・予算を構成台帳に記録し、テストケースと停止条件を添えます。小さく試してから接続と自動化を広げれば、変更理由を説明でき、失敗時にも安全に戻せます。