Blog

あなたはAIを訓練していると思っているかもしれないが、実際には憲法を制定しているのだ。

SMART4A提供| 2026年4月6日

2025年、台湾の中規模eコマース企業のマーケティングチームは5人で構成され、3つのソーシャルメディアアカウントを交代で管理していた。パスワードは全員がアクセスできる共有のGoogleスプレッドシートに保存されていた。投稿を自動化するためにAIエージェントを導入するまでは、誰もこのやり方に問題を感じていなかった。

私の最初の直感は「アカウントキーをエージェントに渡せばいい」というものだった。

この直感は、AIを使い始めるほぼすべての企業に見られる。そして、それはほぼ間違いなく間違っている。

エージェントを訓練する前に、質問をしてみましょう。

AIエージェントについて語る人のほとんどは、その機能に焦点を当てます。検索できるか？レポートを作成できるか？どのようなツールに接続できるか？これらはすべて妥当な質問ですが、二次的なものです。

主な疑問点は、このエージェントに何が許されているのか、何が許されていないのか、そして、エージェントがしてはいけないことをした場合、責任は誰にあるのか、ということです。

これは技術的な問題ではなく、ガバナンスの問題です。企業がエージェントを設計する際、その注意力の90%は前者（技術）に集中し、後者（ガバナンス）についてはほとんど考慮されていません。

権限範囲が限定されていないエージェントは、その能力が高ければ高いほど危険になる。何でもできるアシスタントと、いつ制御不能になるかわからない脆弱性との間に、システムアーキテクチャ上の根本的な違いはない。

これがSPEAKフレームワーク構築の出発点です。

【S】技能スキル
【P】人格特性
【E】確かな実績と 経験
【あ】権威承認する
【K】知識知识

5つの次元のうち、S、P、E、Kはエージェントが何であるか、何を知っているか、何ができるかを記述します。A（権限）だけが全く異なる質問に答えます。それは、どこまで許されるかということです。

「代理人に権限を与えるたびに、扉を開けるようなものです。問題は扉がいくつ開いているかではなく、決して開けてはならない扉をあなたが知っているかどうかです。」

パスワードの物理的分離：プロセスプロキシのロジック

さて、あのeコマース企業の話に戻りましょう。結局、彼らはソーシャルメディアアカウントのパスワードをエージェントに渡さなかったのです。

彼らのやり方はより賢明だった。エージェントには公開プロセスを開始する権限のみを与え、公開アクション自体を実行する権限は与えなかった。エージェントがメッセージを投稿すると、そのコンテンツと時間をMake.com上のシナリオプロセスに渡し、そこでMakeは実際のユーザー名とパスワードを使用して、バックグラウンドでログインと投稿プロセスを完了させた。

プロセス全体の承認チェーンは以下のとおりです。

エージェント（送信内容を把握している）→トリガーシナリオ作成（送信方法を把握している）→アカウントとパスワードの保持（送信権限を持っている）

エージェントはパスワードに遭遇することはありません。パスワードを知る必要もありませんし、知る必要もないのです。

この設計の本質は、企業セキュリティアーキテクチャにおいて数十年にわたり存在してきた原則、すなわち最小権限の原則です。各役割には、そのタスクを完了するために必要な最小限の権限のみが付与され、それ以上の権限は一切付与されません。

銀行システム、病院情報システム、政府データベースはすべてこの原則に基づいて設計されている。しかし、AIエージェントの世界では、誰もがエージェントを「より強力に」することに躍起になっているため、この原則はほとんど忘れ去られている。

AIの核心的な理念は、人間を置き換えることではなく、協働することにある。しかし、協働には前提条件がある。各参加者は、自身の責任範囲を明確に理解していなければならない。AIに無制限の権限を与えることは、信頼ではなく、職務怠慢に他ならない。

二重構造のキー：スキル自体にも認証が必要な場合

プロセス分離は「運用層」におけるセキュリティ問題を解決するが、別の問題が残る。それは、スキル自体をどのように認証するかという問題だ。

Smart4Aのエージェントトレーニングセンタープラットフォーム（speak.smart4a.tw）では、すべてのスキルが暗号化されています。ホストはAES暗号化を使用してスキルコンテンツを保存しており、ユーザーはロックを解除して使用するには、対応する復号キーをローカルマシンに保持している必要があります。

これにより、洗練されたセキュリティ構造が構築されます。スキルは「ダウンロード」されるのではなく、「ロック解除」されるのです。プラットフォームはあなたがそのスキルを使用する資格を持っていることを認識し、ネイティブキーによってあなたの身元が検証されます。どちらも不可欠です。

ビジネスオーナーにとって、この設計のメリットは技術的なものではなく、心理的なものです。AESとは何かを理解する必要はなく、鍵を保護することだけに集中すればよいのです。プラットフォームが複雑なセキュリティロジックを処理するため、最終的な鍵の管理だけを行えばよいのです。

これは金庫の設計思想を思い出させます。優れた金庫は、ユーザーがロック機構を理解する必要はなく、ユーザーが覚えておくのはたった1つの暗証番号だけで、それ以外はすべて機械的な構造によって保護されています。SPEAKの認証レイヤーも同じ原理に基づいています。

キャッシュフローの境界線：拒否ではなく、新たな障壁を追加すること。

では、エージェントがプロセスを開始できるものの、それを単独で完了できないようなシナリオはありますか？

答えはイエスです。キャッシュフローが最も典型的な例です。

照合、送金依頼、さらには一部の送金処理においては、担当者が処理を開始し、データを整理し、数値を入力することができます。しかし、処理の重要な局面では、処理を続行する前に確認が必要となります。これがヒューマン・イン・ザ・ループ（HITL）の設計ロジックです。

HITL設計原則

エージェントはプロセスを開始しますが、実行前に一時停止され、人間の確認と承認を待ちます。人間の承認なしに資金が移動することはありません。エージェントの役割は準備とリマインダーを行うことであり、意思決定権は人間の手にあります。これは技術的な制約ではなく、意図的なガバナンス設計です。

HITLはAIを不信視しているわけではなく、むしろ一部の決定には取り返しのつかない結果が伴うことを認識している。一度ミスを犯せば、元に戻すことはできない。資金の不正流用、誤った支払いなど、どの段階におけるミスも取り返しのつかない損失につながる可能性がある。このような状況では、人々を意思決定プロセスに関与させ続けることが、エンパワーメント設計において最も責任ある選択となる。

成熟した権限とは、「与える」か「与えない」かの二者択一ではなく、階層的な承認チェーンのことです。エージェントが実行できる手順、人間の承認が必要な手順、特定の役割を持つ者のみが承認できる手順など、明確な階層構造が存在します。これこそが、企業レベルのAIガバナンスの真の姿です。

優れた憲法は、誰がどのような権限を持つかを規定するだけでなく、権限を行使する前に、どの権限が抑制され、均衡が保たれるべきかも規定しています。代理人の権限付与構造も同様であるべきです。

SPEAKの真の順序

エンタープライズAIエージェントを計画している場合、SPEAKは直感に反する提案をしています。Sから始めるのではなく、Aから始めるべきだというのです。

まず、次の点を自問してください。このエージェントはどのシステムへのアクセスを許可されていますか？どの口座のパスワードがエージェントの手に渡ってはならないのですか？どの操作は手動による確認が必要ですか？いかなる状況下でも決して越えてはならない一線はありますか？

これらの質問に明確に答えることによってのみ、あなたのエージェントはスキルを習得し、人格を形成し、経験を積み、知識を吸収する資格を得ることができるのです。

そうでなければ、あなたが訓練したものはアシスタントではなく、いつ制御不能になるか分からない脆弱性です。ただ、非常に丁寧な言葉遣いをするので、あなたはまだその問題に気づいていないだけなのです。

AIの本質は、人間の仕事をAIに置き換えることではなく、人間とAIがそれぞれ担うべき役割を再定義することにある。ライセンス設計は、この境界線を最も具体的に示す例である。

そのeコマース企業のマーケティングチームは、最終的に明確なエージェントアーキテクチャを構築しました。エージェントはコンテンツの生成とスケジュール決定を担当し、メイクチームは実行とアカウント管理を担当し、人事チームは最終的なリリース決定と決済業務を担当しました。この3層構造の分業体制により、各チームがそれぞれの責任を確実に果たすことができました。

システム導入後、彼らが最も強く感じたのは「AIによってどれだけ時間が節約できたか」ではなく、「初めて、自分たちのシステムが設計されたと感じた」ということだった。

SPEAKフレームワークは、まさにこうしたことをすべての企業にもたらすことを目指しています。