F-15: 読取専用 vs 書込可能エージェント¶

この相反は何か¶

AI エージェントに外部システムへのアクセスを許可する際、「読取操作（検索・取得・参照）のみを許可するか、それとも書込操作（作成・更新・削除・送信）まで許可するか」という二択が F-15 の相反です。これはエージェントの権限設計における最も根源的な判断です。

この選択が排他的になる理由は、書込権限の有無でリスクプロファイルが質的に変わるためです。読取操作は（機密情報へのアクセスを除けば）副作用がなく、何度繰り返しても外部システムの状態を変えません。一方、書込操作は外部システムの状態を変更し、その変更は（場合によっては不可逆的に）実世界に影響を及ぼします。メール送信、データベース更新、API を通じた発注---これらは「元に戻す」ことが困難か不可能な操作です。

AI エージェントの文脈では、LLM の確率的な性質がこのリスクを増幅します。従来のソフトウェアでは、バグがなければ意図しない操作は発生しません。しかし LLM はプロンプトインジェクション、ハルシネーション、意図の誤解により、設計者が意図しない書込操作を実行する可能性があります。読取専用であればこれらの問題が発生しても情報漏洩のリスクに留まりますが、書込権限があれば実害が拡大します。

選択肢A：読取専用エージェント¶

読取専用エージェントとは、外部システムに対して参照・検索・取得のみを行い、データの作成・更新・削除・送信は一切行わないエージェントです。ナレッジベースの検索、ドキュメントの要約、データ分析、質問応答などが典型的なユースケースです。

読取専用の最大の強みは安全性の高さです。書込操作がないため、エージェントがどのような判断ミスをしても外部システムの状態は変わりません。最悪のケースでも、機密情報の不適切な取得・表示に留まります（これ自体は重大な問題ですが、不可逆的な状態変更と比べれば影響範囲を制御しやすいです）。

また、実装と運用が大幅にシンプルになります。承認フロー、ドライラン、冪等性の保証、補償トランザクション、監査ログといった書込に伴う安全機構が不要になります。テストも容易です---読取操作は外部システムの状態を変えないため、テスト環境と本番環境の分離が簡単です。

弱点はエージェントの有用性の制限です。情報の取得と提示はできますが、ユーザーの代わりに行動（予約する、メールを送る、チケットを作成する）することはできません。ユーザーが自分で書込操作を行う必要があるため、自動化のメリットが限定されます。

選択肢B：書込可能エージェント¶

書込可能エージェントとは、読取に加えてデータの作成・更新・削除・外部システムへの送信などの副作用を伴う操作を実行できるエージェントです。メール送信、カレンダー登録、注文処理、コードのコミット、データベース更新などが該当します。

書込可能エージェントの最大の強みは自動化の実現です。エージェントがユーザーの代わりに行動できるため、ワークフローの完全自動化が可能になります。「会議を設定して」「この注文を処理して」「レポートを作成して関係者に送って」といった end-to-end のタスク遂行ができます。

ただし、書込権限を付与するには厳格な安全機構の整備が前提条件です。具体的には以下が必要です。

権限の明確な境界定義：どのリソースに対してどの操作を許可するかを、最小権限の原則に基づいて厳密に定義します。
ドライラン：実際の書込の前に、何が変更されるかをプレビューする仕組みです。
冪等性の保証：リトライ時に同じ操作が重複実行されないよう、冪等キーなどの仕組みを導入します。
監査ログ：すべての書込操作を記録し、事後検証を可能にします。
補償トランザクション：誤った書込を打ち消す操作（取消メールの送信、データの復元など）を用意します。
高リスク操作の人間承認：金額の大きい取引、不可逆な削除、外部への送信など、[failure_cost] が高い操作は人間の承認を経てから実行します。

これらの安全機構なしに書込権限を付与することは、事故を招く設計上の過失です。

選定基準¶

この相反の選定は [reversibility] と [failure_cost] の二つの駆動変数で決まります。

読取専用を選ぶべき条件：

エージェントの価値が情報の取得・分析・提示にあり、行動の実行は不要な場合。ナレッジベース QA、ドキュメント要約、データ分析ダッシュボードなどです。
[reversibility] が低く [failure_cost] が高い書込操作が中心の場合。メール送信、決済処理、契約書送付など、取り消しが困難な操作は、安全機構の整備ができるまで読取専用に留めるべきです。
エージェントの信頼性がまだ検証されていない初期段階。本番環境での振る舞いが十分に検証されるまで、書込権限は与えません。

書込可能にすべき条件：

エージェントの価値がタスクの end-to-end 遂行にあり、読取だけでは目的を達成できない場合。
上記の安全機構（権限境界、ドライラン、冪等性、監査、補償、承認）が整備済みまたは整備可能な場合。
[reversibility] が高い操作（下書き保存、テスト環境へのデプロイなど）から段階的に書込を許可できる場合。

デフォルトとハイブリッド¶

デフォルト：まず読取専用で始めるのがデフォルトです。書込権限は、安全機構の整備と十分なテストを経てから、段階的に追加します。これはセキュリティの「最小権限の原則」そのものです。

ハイブリッド：Read は自由、Write はゲート付きという非対称構成が最も実用的なハイブリッドです。読取操作は承認なしで自由に実行し、書込操作にだけ承認・検証・監査のゲートを設けます。さらに書込操作の中でもリスクレベルに応じて段階を分けます。

低リスク書込（下書き保存、タグ付与）：自動承認
中リスク書込（ステータス変更、コメント投稿）：ポリシー検証のみ
高リスク書込（メール送信、決済、削除）：人間承認必須

この構成は C2 Read-Free / Write-Gated パターンが体系化しています。

判断を誤ったときの症状¶

読取専用を選んだが書込が必要だった場合の症状：

ユーザーがエージェントの出力を見た後、手動で書込操作を行っており、自動化のメリットが実現できていません。「エージェントが提案してくれるけど、結局自分でやらないといけない」という不満が出ます。
エージェントの利用率が低迷しています。情報の取得だけならエージェントを使わなくても既存のツールで十分だと判断されています。
競合するサービスが書込機能を提供しており、ユーザーが流出しています。

書込可能にしたが安全機構が不十分だった場合の症状：

エージェントが誤ったメールを送信、誤ったデータを更新、意図しない注文を処理するインシデントが発生しています。
プロンプトインジェクションにより、エージェントが攻撃者の指示に従って書込操作を実行するセキュリティインシデントが発生しています。
誤操作の補償（取消メール、データ復元）の手動対応に工数が割かれています。
監査ログが不十分で、「いつ、なぜ、この操作が実行されたか」の事後追跡ができません。