地政学リスクをBlockchainでは感じきれなかったけど、AIでみんなが意識するようになったのは良いこと。いつも陰謀論者みたいになってしまう状態が、ついにFable5事件によって印象付けられた。データの自己主権みたいな話は情報操作で自身の国の大統領が決まった国や、EURO離脱を経験した国々が身を持って大切さを法律としてGDPRやCCPAに綴っている。まさに反脆弱性。

# OpenAI Agent SDKの便利だけど知られていない機能 🌍 エージェントの会話履歴に機密情報が含まれているのに、平文で保存していませんか？ EncryptedSessionを使えば、会話データをFernet暗号化で保護し、TTLによる自動失効も設定できます。 📌 タイトル：暗号化セッション (EncryptedSession) 🔗 URL： 🧩 概要 `EncryptedSession` は、任意のセッションバックエンドを `underlying_session` としてラップし会話データを暗号化するドロップインラッパーです。Fernet暗号化を採用し、HKDF（info 文字列 `"agents.session-store.hkdf.v1"`、salt は session_id）によるセッションごとの鍵導出でセッション間の暗号分離を実現します。`ttl`（既定 600 秒）を超えた項目は取得時に自動的にスキップされます。マスターキーには `Fernet.generate_key()` などの高エントロピーな値を使います（生の文字列も互換性のため受け付けますが、パスワードのような低エントロピーの秘密は不適切です）。 🛠 使い方 ```python import os from cryptography.fernet import Fernet from agents import SQLiteSession from agents.extensions.memory import EncryptedSession # 基底セッションを暗号化でラップ base_session = SQLiteSession("chat-001", "sessions.db") # マスターキーは Fernet.generate_key() などの高エントロピーな値を使う encryption_key = Fernet.generate_key().decode("ascii") encrypted = EncryptedSession( session_id="chat-001", underlying_session=base_session, encryption_key=encryption_key, ttl=3600, # 1時間で失効（既定は 600 秒） ) # 永続化する場合は同じキーを Secret Manager 等から読み込んで再利用する encrypted = EncryptedSession( session_id="chat-001", underlying_session=base_session, encryption_key=os.environ["SESSION_ENCRYPTION_KEY"], ttl=7200, ) # 通常のセッションと同じインターフェースで利用可能 items = await encrypted.get_items() ``` 🏗 本番システムへの組み込み方 ・医療・金融など規制業界のコンプライアンス要件に対応する ・HKDFによりセッションごとに異なる暗号鍵が導出されるため、1セッションの漏洩が他に波及しない ・TTLを設定して、一定期間後に復号不能にする「暗号学的データ消去」を実現する ・既存のSQLiteSession / RedisSession等をそのままラップでき、移行コストが極めて低い 💡 ユースケース 🏥 医療情報を含む会話の暗号化保存 🏦 金融データを扱うエージェントのセキュリティ強化 🔐 GDPRの「忘れられる権利」対応（TTL失効） 🛡 マルチテナント環境でのセッション間データ分離 ⚠️ 注意点 利用には `pip install 'openai-agents[encrypt]'` で `encrypt` extra をインストールしてください。暗号化されたデータに対しては `find_turns_by_content()` などの内容検索が機能しません。検索が必要な場合は検索用のインデックスを別途管理する必要があります。また、暗号鍵を紛失するとデータが復元不能になるため、鍵の安全な管理（Secret Manager等）が必須です。`encryption_key` を変更しても既存レコードは再暗号化されないため、古いデータの復号には元のキーが必要です。 ✨ EncryptedSessionで、会話データの保護をコード1行で実現しましょう。 #OpenAIAgentSDK# #AIAgent#

# AIエージェントをエンタープライズシステムに組み込む意思決定ポイント # 自律 vs 決定論ワークフロー｜Autonomous vs Deterministic Workflow 🎯 ポイント エージェントに「自由に考えて動いて」と任せますか、それとも「この手順通りに実行して」と指示しますか？ 自律は柔軟だが予測不能、決定論は硬直だが監査可能。この分岐を副作用の可逆性と影響度で判断せず「なんとなく自律」で設計すると、不可逆な操作をエージェントの自律判断に委ねて取り返しのつかない事態を招きます🔑 📋 概要 自律型はエージェントが自由にステップを計画・実行するアプローチです。タスクのバリエーションが多く、事前にすべてのフローを定義するのが非現実的な場面で力を発揮します。情報検索・要約・分析など読み取り専用の操作が中心で、誤りがあっても容易に取り消し可能な場合に適しています。決定論ワークフローは事前定義されたフローに従わせるアプローチで、操作の副作用が不可逆または高影響（決済処理、契約変更、本番デプロイ、人事異動）な場合、そしてSOX / GDPR / 金融規制により監査証跡が必須な場合に選びます📊 🔍 意思決定のポイント 判断は副作用の有無と可逆性で行います： 副作用なし（読み取り専用）→ 自律で問題なし 副作用あり＋可逆 → 自律＋事後検証で対応可能 副作用あり＋不可逆 → 決定論＋事前承認が必須 規制要件あり → 決定論で監査証跡を確保 タスクの多様性も重要な判断材料です。パターンが固定的なら決定論で最適化し、多様で予測不能なら自律で柔軟に対応します。ただし自律でも、高リスク操作の前にHITL（Human-in-the-Loop）承認ゲートを挿入すれば安全性を確保できます⚡ 💡 要点と詳細 本番環境では純粋な自律も純粋な決定論も少なく、ハイブリッドが主流です： 自律で計画、決定論で実行：エージェントが自律的にタスクを分解・計画し、各ステップの実行は事前定義されたワークフロー（API呼び出しの順序・バリデーション・承認ゲート）に従います。計画の柔軟性と実行の安全性を両立する最も実用的なパターンです。 リスクレベルによる切り替え：読み取り操作は自律、書き込み操作は決定論ワークフローに自動ルーティング。二重トラック検証と組み合わせるのが定石です。 ServiceNowのインシデント対応を例にすると、原因調査は自律（ログ検索・仮説生成・検証を柔軟に実行）、復旧操作は決定論（定義済みのランブック手順に従う）という使い分けが理にかなっています。 監査証跡は全モードで記録してください。自律モードでも「なぜその操作をしたか」を追跡できる操作ログが不可欠です🔄 ⚖️ トレードオフ 不可逆な操作を自律に任せるリスクは計り知れません。Shopifyで数千商品の価格を一括変更する操作をエージェントの自律判断に委ねた結果、誤った価格設定で損害が発生するケースは現実に起こり得ます😰 一方、すべてを決定論にすると、情報検索や要約まで固定フローに閉じ込め、エージェントの柔軟性を完全に殺してしまいます。「AIエージェント」である意味がなくなり、従来のルールエンジンと何も変わりません。 ハイブリッドの境界が曖昧なのも危険です。自律と決定論の切り替え条件が明文化されていないと、開発者によって実装がバラつきます。操作のリスク分類を先に定義し、切り替え条件をコードで明文化しましょう⚠️ 🛠️ ユースケース ナレッジ検索＋ドキュメント編集：Notion / Confluenceでのナレッジ検索と情報要約は自律モード（読み取り専用、柔軟な探索が価値を生む）。ドキュメントの本番公開や共有範囲変更は決定論ワークフロー（承認ゲート＋監査ログ）📚 EC運営（Shopify）：商品情報の検索・分析は自律。在庫調整は決定論（変更量のバリデーション＋承認）。一括価格変更は決定論＋ドライラン必須（差分プレビュー→人間確認→実行）。同じエージェントでもリスクレベルで実行モデルを切り替えます🛒 インシデント対応（ServiceNow）：原因調査フェーズは自律（ログ検索→仮説立て→検証を柔軟に）。復旧フェーズは決定論（ランブック手順通り、各ステップに承認ゲート）。調査は自由に、実行は厳密に🔧 実践のコツ：「自律と決定論の境界」をリスク分類表として先に定義してください。各操作を「読み取り」「可逆書き込み」「不可逆書き込み」「金銭移動」に分類し、それぞれの実行モデルを決めておくのが安全な運用の出発点です💪 #AIエージェント# #エンタープライズアーキテクチャ#