企業向けAIエージェントの設計は、ここ1年で「自律をどこまで許すか」という議論から、「自律と統制をどう同居させるか」という実装論へ移りました。Google Labsのノーコードエージェントビルダー「Opal」のアップデートは、その転換点を分かりやすく可視化します。注目すべきは、単なる機能追加ではなく、2026年型エージェントに必要な設計原則（動的ルーティング、永続メモリ、Human-in-the-loop）を“参照アーキテクチャ”として提示した点です。本稿では、Opalが示した新定石を、B2Bの現場で使える設計・調達判断へ落とし込みます。
Opalアップデートの要点：ノーコードが示した「エージェントの設計図」
Opalの更新で象徴的なのが「agent step（エージェントステップ）」です。従来のドラッグ＆ドロップ型ワークフローは、手順・分岐・利用ツールを人が前もって定義する“静的な自動化”になりがちでした。agent stepはこれを、目的（ゴール）を与えると、モデルが状況に応じて手順を組み立て、必要なツールやモデル（例：Gemini 3 Flash、Veoなど）を選び、足りない情報があればユーザーに質問する“動的な遂行”へ変えます。
つまりOpalが示したのは、「エージェント＝ワークフローの延長」ではなく、「意図→計画→実行→対話→修正」を回すオーケストレーション層だという設計図です。ノーコードでこれを実装できること自体が、エージェント設計が一部の研究・試作から、実務の標準機能へ移ったシグナルになります。
Opalが“標準部品”として提示した3要素
- 動的ルーティング（状況に応じて経路・手段を選ぶ）
- 永続メモリ（セッションをまたいで学習・文脈を保持する）
- Human-in-the-loop（必要時に人へ確認・質問・承認を求める）
なぜ今“レール”を外せるのか：高性能モデルが変える自律と統制のバランス
初期のエージェント基盤は「agents on rails（レール上のエージェント）」になりやすい構造でした。モデルの推論・計画能力が不安定なため、分岐条件、ツール呼び出し順、例外処理を人が細かく定義し、自由度を削って事故を防ぐ必要があったからです。結果として、少し複雑な業務になると分岐が爆発し、設計・保守コストが価値を上回ります。
Gemini 3系や、他社の最新フロンティアモデルは、計画立案・自己修正・ツール選択の信頼性が上がり、「ゴールと制約を与え、手順はモデルに任せる」設計が現実的になりました。ここで重要なのは、統制を捨てることではありません。統制の中心が「手順の固定」から「制約・権限・観測（モニタリング）」へ移る、という点です。
“レールを外す”ときに統制側へ寄せるべき設計
- 許可されたツールのホワイトリスト化（実行可能な手段を限定）
- データ境界（社外/社内、機密区分、個人情報）を明示したアクセス制御
- 出力よりも「行動ログ」を重視した監査設計（誰が何を参照し何を実行したか）
- 失敗時のフォールバック（検索に切替、質問に切替、停止して承認待ち等）
言い換えると、エージェントを“細かく操縦する”のではなく、“運転ルールと計器”を整える発想が、過剰設計を避けつつ自律性の価値を引き出します。
本番運用を分ける永続メモリ：セッション横断とマルチユーザー設計の勘所
デモと本番を分ける最大の差は、永続メモリです。毎回ゼロから会話を始めるエージェントは便利でも、業務価値が積み上がりません。Opalが永続メモリをコア機能として組み込んだことは、「エージェントは使うほど賢くなる」前提を標準化した、と解釈できます。
一方で企業利用では、個人向けの“単一ユーザーの記憶”と、業務システムの“マルチユーザーの記憶”は別物です。顧客対応、営業支援、社内ヘルプデスクなどでは、ユーザーごと・組織ごと・案件ごとに文脈を分離し、権限に応じて参照範囲を変え、保持期間や削除要求にも応える必要があります。ここを曖昧にすると、情報漏えいと監査不備が同時に起きます。
永続メモリ設計で押さえるべき論点
- スコープ設計：個人（Me）/チーム（Us）/全社（Company）/顧客（Customer）を分ける
- 分離と継承：ユーザー固有メモリと案件メモリを混ぜない（必要なら参照を合成）
- 保持ポリシー：保存期間、削除、エクスポート、監査ログをデータガバナンスに合わせる
- “覚える内容”の最小化：嗜好・設定・要約など高価値のみに限定し、生ログを溜めない
- RAGとの役割分担：長期知識は検索（RAG）、短中期の作業状態はメモリ、という整理
調達時は「永続メモリ対応」の有無だけでなく、マルチテナント分離、権限連動、削除・監査の仕組みまで確認しないと、本番移行で詰まります。
Human-in-the-loopは安全策ではなく設計原則：不確実性に応じた動的介入
Human-in-the-loop（人の介入）を“最後の安全策”として後付けすると、現場では承認待ちが増え、結局自動化が進みません。Opalが示したのは、固定チェックポイントではなく、エージェントが不確実性を検知したときに自然に質問・確認へ切り替える「動的介入」です。これは運用品質を上げるだけでなく、ユーザー体験を損ねにくい点が重要です。
企業での要諦は、「どの場面で人に戻すか」を静的に決め切らないことです。業務は例外が多く、入力品質も揺れます。不確実性に応じて介入を増減させるほうが、スケールします。
動的介入を成立させる設計パターン
- 不足情報の質問：入力が曖昧なら、実行前に確認質問を生成する
- 選択肢提示：複数案が妥当な場合、候補と根拠を並べてユーザーに選ばせる
- 高リスク操作の承認：削除・送信・更新など不可逆操作は必ず承認フローへ
- 信頼度の扱い：確率スコアに頼り切らず、ルール（データ種別・操作種別）で介入を決める
Human-in-the-loopは“止めるための仕組み”ではなく、“迷ったら聞ける設計”です。これがあることで、レールを外した自律性を現場で許容できます。
動的ルーティングと自然言語条件：開発をエンジニアから業務部門へ拡張する
Opalのもう一つの示唆は、動的ルーティングを「自然言語の条件」で定義できる点です。従来の分岐はコードや厳密な条件式が必要で、業務部門が自分たちの判断基準を実装に反映しにくい構造でした。自然言語条件であれば、「新規顧客なら外部情報を調査、既存顧客なら社内議事録を優先」といった業務知を、より短い距離でエージェントに移植できます。
これは“開発民主化”の話に見えますが、企業では役割分担の再設計が本質です。エンジニアは分岐ロジックを書く人から、ツール群・権限・監査・品質評価を整える人へ寄ります。業務部門は、判断基準（条件）と成功定義（ゴール）を言語化する責任が増えます。
業務部門に任せてよいもの／任せないもの
- 任せてよい：ルーティング条件（自然言語）、質問テンプレ、成果物のフォーマット、例外時の対応方針
- 任せない：データ接続、権限設定、外部送信、監査ログ、モデル選定、コスト上限
自然言語で分岐を作れるほど、ガバナンスの“外枠”が重要になります。自由度を上げるほど、境界（何をしてよいか）を明確にする必要があります。
ITリーダー向け実践チェックリスト：過剰設計を避ける調達・アーキ判断基準
最後に、Opalが示した新定石を、ITリーダーの調達・アーキ判断に使えるチェックリストにまとめます。ポイントは「最新機能の多さ」ではなく、「自律性を活かしつつ、統制コストを増やさない」ことです。
調達・設計チェックリスト
- ゴール駆動の実行が可能か：手順固定が前提になっていないか（過剰な“レール設計”を要求しないか）
- 動的ルーティングがあるか：条件はコード前提か、自然言語や設定で業務知を反映できるか
- 永続メモリの実装方針が明確か：マルチユーザー分離、権限連動、保持/削除/監査に対応するか
- Human-in-the-loopが“固定ノード”だけでなく動的に呼べるか：不足情報の質問、承認、選択提示を標準化できるか
- ツール統制ができるか：ホワイトリスト、実行権限、環境分離（検証/本番）、操作ログが揃うか
- 評価と運用が回るか：品質指標（正確性、再現性、介入率、失敗率）、コスト上限、アラート設計が可能か
- “作りやすさ”より“直しやすさ”を優先しているか：プロンプト/条件/ツールの変更が安全に反映できるか
特に注意したいのは、モデル性能向上を前提にできる局面で、旧来の「全部を事前定義する設計」を続けてしまうことです。統制のための設計が、価値創出の足かせになっていないかを定期的に点検する必要があります。
まとめ
Google Opalのアップデートは、ノーコード製品の改善に見えて、企業向けAIエージェントの“新しい標準形”を提示しました。高性能モデルの進化により、エージェントは手順を固定する「レール型」から、ゴールと制約で動く「オーケストレーション型」へ移行しています。そのとき鍵になるのが、永続メモリで価値を積み上げ、Human-in-the-loopで不確実性を吸収し、動的ルーティングで業務知を素早く反映することです。
ITリーダーに求められるのは、完全自律か完全統制かの二択ではなく、「自律を許すほど、境界と観測を強くする」設計判断です。Opalを“採用するか”よりも、Opalが示した設計原則を、自社のデータ境界・権限・監査・運用に合わせて実装できるか。そこが、2026年のエージェント投資の勝敗を分けます。
