見える確認と見えない承認が、システムの信頼を決める

まず、問いを変える

開発で本当に難しいのは、何ができるかを判定することではありません。何を見せるか、何を実行させるか、そしてその境界を誰がどの段階で決めるのか、そこです。多くの設計は「できるかどうか」の一点に注目しますが、実際の現場では、確認と実行のあいだにあるわずかなズレが、事故と安心を分けます。

ここに面白い共通点があります。ある世界では、権限があるかどうかを確認だけする方法と、権限がなければ例外で止める方法が区別されています。別の世界では、道具や能力を明示的に呼び出す場合と、タスクの内容に応じて暗黙的に選ばれる場合が区別されています。どちらも、実は同じ問いに答えています。

システムは、ただ能力を持っているだけでは十分ではない。その能力を、いつ、誰が、どの強さで発動させるかが、信頼の本体である。

この視点に立つと、認可とスキル選択は別物ではなくなります。両者は、複雑なシステムにおける責任の置き場所をどう設計するかという、同じ問題の異なる表現です。

---

確認と強制は、似ていて全く違う

権限チェックには、少なくとも二つのモードがあります。ひとつは、条件を調べて真偽値を返すモード。もうひとつは、条件を満たさないなら処理を止めるモードです。前者は「この操作は許されるか」を静かに返し、後者は「許されていないなら進ませない」という強い意思を持ちます。

この違いは、単なるAPI設計の話ではありません。不確実性をどこで吸収するかの話です。真偽値を返すだけなら、呼び出し側はその結果をどう扱うかを自分で決められます。例外を投げるなら、ルール違反の責任をその場で固定できます。

たとえば、倉庫の入退室管理を考えてみてください。受付で「入ってよいか」を確認するだけなら、その後の行動は訪問者次第です。しかし、ゲートが開かなければ中に入れない設計なら、ルールは物理的な現実になります。確認は判断、承認は執行です。

ここで重要なのは、どちらが優れているかではありません。不確実さを許容したいのか、絶対に通したくないのかで使い分けることです。確認だけを乱用すると、呼び出し側に責任が散らばります。逆に、例外を投げる設計を乱用すると、柔軟な分岐やプレビューがやりにくくなります。

つまり、認可設計は「安全」をひとつの方法で実現するのではなく、安全の粒度を選ぶ行為です。前者は観察可能性を高め、後者は強制力を高める。この違いを曖昧にすると、コードは動いても、運用では信頼を失います。

---

明示的に呼ぶスキルと、暗黙的に選ばれるスキル

次に、道具や能力の選択を見てみましょう。ある仕組みでは、利用者が「このスキルを使う」と明示的に指定できます。別の仕組みでは、タスクの説明に合致すると自動的に選ばれます。前者は意図がはっきりし、後者は摩擦が少ない。

この対比は、認可の「allows」と「authorize」に驚くほど似ています。明示的な呼び出しは、条件を見てから使うという意味で、判断を人間に戻す設計です。暗黙的な選択は、ルールに従って自動化するという意味で、判断をシステムに委ねる設計です。

たとえば、写真編集ソフトで「ノイズ除去」を毎回自分で選ぶのは明示的です。写真を開いた瞬間にAIが補正候補を提案するのは暗黙的です。前者は誤作動しにくいが、手間がかかる。後者は速いが、意図しない補正が起こりうる。

ここで見えてくるのは、明示性はコントロールのためだけでなく、説明責任のためにも必要だということです。利用者が「なぜこれが起きたのか」を理解できることは、システムへの信頼を支えます。暗黙的選択は便利ですが、選ばれた理由が見えないと、利用者はシステムを助ける存在ではなく、気まぐれな相手として扱い始めます。

一方で、すべてを明示的にすると、人は疲れます。毎回の意思決定は、自由ではなく負荷です。したがって良い設計は、明示性と暗黙性を対立させるのではなく、どこで人間の意図を保ち、どこで自動化するかを分けます。

---

本質は「能力」ではなく「発動条件」である

この二つの領域を重ねると、ひとつの強い結論にたどり着きます。システム設計で本当に重要なのは、機能や権限そのものではなく、それが発動する条件です。

認可の世界では、ユーザーが何を持っているかより、何を許されているかが問題になります。スキルの世界では、モデルが何をできるかより、いつそのスキルを呼び出すかが問題になります。どちらも、能力が存在するだけでは意味がなく、発動のルールが価値を決めるのです。

この視点は、ソフトウェア設計を少し冷たく、しかしずっと正確にします。たとえば、あるユーザーが管理機能を持っていたとしても、画面にボタンが表示されるとは限りません。逆に、ボタンが見えていても、最終実行で拒否されることがあります。見える権限と実際に通る権限は一致している必要がありますが、その一致を保証するのは一箇所ではありません。

同じことがスキル選択にも起こります。スキル一覧に存在することと、実際に選ばれることは違います。自動選択は便利ですが、説明文の書き方ひとつで発火条件が変わることがあります。つまり、能力の本体よりも、メタデータの設計が成果を左右するのです。

優れたシステムは、たくさんの能力を持つシステムではない。能力が適切な場面でだけ、適切な強さで現れるシステムである。

この「発動条件」という観点を持つと、設計レビューでも見るべき点が変わります。何ができるかを列挙するだけでは足りません。その能力は、どこで見つかり、誰が選び、最終的にどの層が止められるのかを問わないと、現実の事故は防げません。

---

実装の前に、責任の地図を描く

では、どう設計すべきでしょうか。ポイントは、機能を積み上げる前に、責任の地図を描くことです。

まず、次の三層を分けて考えます。

1. 観察層: 何が可能かを知る
2. 選択層: 何を使うかを決める
3. 執行層: それを本当に実行させる

認可で言えば、観察層は allows に近いです。選択層は「このユーザーには操作を見せるか」というUIやワークフローの判断です。執行層は authorize に近く、最後に強制的に境界を守ります。スキルの世界でも同じで、候補を列挙する層、タスクに応じて選ぶ層、実際に呼ぶ層を分けると、システムはずっと理解しやすくなります。

この分離の利点は、単にバグを減らすことだけではありません。失敗の形を設計できることです。観察層で見つける失敗は、修正しやすい失敗です。選択層で起きる失敗は、意図のズレです。執行層で起きる失敗は、事故に近い。だから、どの層で失敗を許容するかを先に決める必要があります。

たとえば、社内申請システムで考えるとわかりやすいでしょう。申請ボタンを表示する前に権限を確認すれば、ユーザー体験は滑らかです。しかし、最終承認はサーバ側で必ず止めなければなりません。なぜなら、画面上の見え方は改ざんできても、最終的な執行は守られるべきだからです。

この構造は、AIエージェントにもそのまま当てはまります。道具の候補を表示するだけなら説明可能性が高い。自動選択は速いが、暴走したときに原因追跡が難しい。だからこそ、重要な操作ほど、候補提示と最終実行を分けるべきです。

---

Key Takeaways

• 確認と承認を混同しない。まず状態を観察し、最後に執行する。どちらか一方に責任を寄せすぎると事故が起きる。
• 明示的な選択は、コントロールではなく説明責任の道具として使う。重要な場面では、人間が理由を追える形にする。
• 暗黙的な選択は便利だが、発火条件を厳密に設計する。説明文やメタデータは実装の一部だと考える。
• 能力ではなく発動条件を設計する。何ができるかより、いつ起きるかを管理すると、システムの信頼性が上がる。
• UI、選択ロジック、実行ロジックを分ける。見せることと通すことを同じ場所で決めない。

---

終わりに: 信頼は機能ではなく、境界の芸術である

私たちはつい、優れたシステムとは多機能なシステムだと思いがちです。しかし本当に信頼されるシステムは、能力が多いからではなく、能力の発動条件が美しく整理されているから信頼されます。

確認は、世界を観察する技術です。承認は、世界を止める技術です。明示的なスキル選択は、意図を守る技術です。暗黙的な選択は、摩擦を減らす技術です。これらは別々の機能ではなく、同じ問いに対する異なる解法です。

その問いとは何か。システムが力を持つとき、その力を誰が、いつ、どの程度、どう安全に発動させるのか。この問いに答えられる設計だけが、便利さと安全性を両立できます。

結局のところ、良い設計とは「何ができるか」を増やすことではありません。何が起きるべきかを、起きる前に正しく決めることです。そこにこそ、信頼の本体があります。