LLMが生成したコードはコピペせず、あえて手で写経して認知負債を防ぐアプローチ。 ・個人開発においてAIは非常に便利 ・ただ、すべてをAIに任せるとコードに対する認知負債が溜まってしまう ・退屈な実装を任せたいだけで、コードへの理解まで手放したいわけではない ・かといって、AIが自動生成した大量のコードをレビューする作業は全く楽しくない ・そこで筆者は、AIにチャットでコードを出力させ、それをすべて手打ちで書き写している ・プロンプトで、AIによるファイルの直接編集やコマンド実行をあえて固く禁止 ・これだとAIに自動化させるより効率は落ちる ・それでも、AIを使わない場合に比べれば2倍は早い ・手打ちすることで作業ペースが落ち、AIのハルシネーションや設計のまずさに気づきやすくなる ・書き写しながらリファクタリングでき、コードベースの空間的なマップが頭の中に作れる ・筆者は生産性よりも、コードに対する理解を優先している ・ソフトウェア業界は今、近い将来に支払うべき巨大な認知負債を抱え込もうとしている ・少なくとも自分が生み出すコードだけは完全に理解しておきたい、というスタンス

# AIエージェントをソフトウェアに組み込むプラクティス # Streaming with Progressive Commit｜進捗ストリーミング＋遅延コミット 🎯 トークンは即座に見せたい、でも副作用は検証してからコミットしたい。 「見せる」と「実行する」を分離すれば、体感レイテンシの短縮と副作用の安全性を両立できます。 🔥 解決する課題 エージェントの応答はレイテンシのばらつきが大きく、全トークン生成まで待たせると体感が悪化します。一方でツール呼び出しの副作用を生成途中で確定すると、ガードレール検証で棄却された際にロールバックが必要になります。「全部待ってから返す」か「生成と同時に確定する」かの二択では、体感か安全性のどちらかを犠牲にしてしまいます。 💡 提案パターン Streaming with Progressive Commit（進捗ストリーミング＋遅延コミット）は、生成中のトークンやツール実行結果をSSE/WebSocketでクライアントへストリーミングしつつ、副作用（外部API書き込み・DB更新など）は検証完了までコミットバッファに留めます。ストリーム上ではpreview（未確定）→ committed/rejected（確定/棄却）とイベントが遷移し、クライアントUIは中間状態を明示的に表示します。failure_costが高いほどバッファを深く取り、全ステップ完了後にまとめて確定します。 ✅ 選定条件 使うとき： - ユーザー向けUIがあり、first-token-timeの短縮が体験に直結する - エージェントがツール呼び出しで書き込み副作用を持ち、誤った副作用の取消しが困難 - 生成結果にガードレール検証やドライランを挟みたい 使わないとき： - 処理が常に数秒以内で、ストリーミングの恩恵がほぼ無い場合 - クライアントがSSE/WebSocketに対応できない場合 - 副作用が無い読取専用の質問応答（遅延コミットが不要） ⚠️ 落とし穴 - previewとcommitted/rejectedをクライアント側で区別しないと、未確定の結果を確定済みとして表示してしまいます。UIに「確認中」の中間状態を必ず設けてください - 長時間のマルチステップ実行ではコミットバッファが肥大化します。ステップ単位でチェックポイントを切り、確定済みバッファを解放しましょう - SSE接続が切れてもコミットバッファは残ります。再接続時の復元かタイムアウト破棄かのポリシーを事前に決めておく必要があります 🔧 実装方針 - LLMからのトークンはStream Buffer経由でSSE/WebSocketチャネルへ即座にプッシュし、ツール呼び出し結果はCommit Bufferに蓄積してpreviewイベントとしてクライアントに通知します - 全生成完了後にCommit Buffer内の各ツール呼び出しをガードレール検証し、パスすればcommittedイベント、棄却すればrejectedイベントをクライアントに送ります - ツール実行はまずドライランで結果をプレビューし、検証通過後に本コミットする二相構成を採ります - SSEイベント設計ではtoken・preview・committed・rejectedの各イベントタイプを明確に分離し、クライアントUIが中間状態（確認中）を適切に表示できるようにします - failure_costが高いワークフローではコミットバッファを深く取り、全ステップ完了後にまとめて確定します。低リスクの場合は単一ツール呼び出し単位で確定します #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェントをソフトウェアに組み込むプラクティス # Deadline & Budget Cascade｜期限・予算のカスケード伝播 🎯 エージェントが再帰的にサブタスクを生成して、気づけばコストが数十ドルに。「請求事故」を構造的に防ぐ方法があります。 全体の予算と期限を末端ノードまで伝播させれば、各ノードが自分で打ち切り判断できます。 🔥 解決する課題 エージェントの呼出ツリーが深くなると、各ノードは自分がどれだけのリソースを消費してよいか分かりません。高コストなLLM呼び出しが再帰的に積み重なり、請求事故が起きます。計画-反省の自己ループでは、改善の見込みが薄くても無限にリトライを繰り返しえます。根本原因は「全体の予算と期限がローカルな判断に伝わっていない」ことです。 💡 提案パターン Deadline & Budget Cascade（期限・予算のカスケード伝播）は、呼出ツリーのルートでdeadline（期限）とbudget（トークン・コスト・ステップ数の上限）を設定し、子タスクへ委譲するたびに残り枠を差し引いて伝播します。どの末端ノードでも「今の自分に残された時間・コスト」を知っており、枠を使い切る前に縮退・中断・部分結果返却に切り替えられます。deadlineは相対秒でなく絶対時刻で渡し、伝播時のズレを防ぎます。 ✅ 選定条件 使うとき： - エージェントがサブタスクを再帰的に生成、または複数ワーカーに並列委譲する - 1リクエストのコストが予測困難で、上限を置かないと請求事故が起きうる - タスク完了にSLAや期待値がある 使わないとき： - 呼出ツリーが1段で完結し、タイムアウトだけで十分な場合 - バッチジョブなど時間制約がなくコストも固定的な場合 ⚠️ 落とし穴 - deadlineは絶対時刻で渡すこと。相対秒を渡すと伝播のたびにズレが蓄積します（gRPCのgrpc-timeoutと同じ原則） - 子に全予算を渡さず、予備枠（10〜20%）を親に残すこと。子の結果を集約・フォーマットする時間とコストが必要です - 枯渇時の振る舞い（部分結果返却・人間エスカレーション・縮退モデル切替）を事前に決めておくこと。タイムアウト例外を投げるだけではUXが崩壊します 🔧 実装方針 - BudgetContextデータクラスにdeadline_at（絶対時刻）・max_cost_usd・max_steps・max_tokens・depth・max_depthを持たせ、呼出ツリーのルートで初期値を設定します - 子タスクへの委譲時にchild_budgetメソッドで残り枠からfractionを掛けて分配し、伝播マージン（概ね2秒）を差し引きます。予備枠としてルート予算の10〜20%を親に残します - 各ノードはis_exhaustedで残時間・残コスト・残ステップを確認し、枠を使い切る前に縮退・中断・部分結果返却に切り替えます - 並列子タスクではコストは各子の合算、deadlineは最も遅い子で決まることに注意し、分配比率は子タスクの重要度と予測コストで按分します - 予算消費率（consumed/limit比）をメトリクスとして観測し、閾値超過時にアラートを発火させる仕組みを組み込みます #AIエージェント# #ソフトウェアアーキテクチャ#

Claude Codeでそんなにトークンをガンガン使って何を作ってるんですか？とよく聞かれます。職種や部門ごとに作るべきものは様々ですが、マネジメントも含めて全員にオススメなのは「パーソナルエージェント」と「パーソナルナレッジベース」です。 パーソナルエージェントは自分の秘書のような存在で、毎朝モーニングブリーフィングとしてカレンダーの予定や未完了タスクや未読メールなどをピックアップして通知させたり、面接や会議、会食などの事前ブリーフィング資料をつくらせたり、日程調整をサポートさせたりします。 例えば会食だと、事前に同席する人の会社概要や直近のトピックス、その方の経歴や最新の発信、関心領域をDeep Researchにかけて調べたりしますよね。それをパーソナルエージェントが自動で実行するようにして、まとめたレポートを自分のみに権限設定したGoogleドキュメントに出力させて、Googleカレンダーの予定に添付させます。これはとっても便利。※もちろん、社内データを扱う場合はアクセス権限や保存先などのガバナンスをきちんと設計することが前提です スケジュール調整なら、自分の好みを教えこんだ予定調整をしてもらえます。細かな移動時間を考慮させたり、金曜日は集中したいからなるべく入れないとか、面接や登壇はパワーを使うのでその後の予定はなるべくソフトにするとか、スコアリングロジックを自分好みに作り込むと提案の精度がとてもよくなってきます。 候補日を複数仮で入れて、決まったら確定させて仮の候補日を消すなどの日程調整系サービスがやるようなこともSkillを作れば自在にやってくれます。これを作り込んでからはあまりによすぎて調整系サービスを使わなくなりました。 パーソナルナレッジベースは、自分に関連するコンテキストやデータをためておき、RAG的に自由に質問したり、Deep Research的にレポートをつくったり、ダッシュボードアプリをつくったり自在にできるようにするものです。 Gemini Notebook(旧NotebookLM)でも同じようなことはできますが、ノートブックごとのソースファイル数に制限があったり、自分独自のデータ取得・加工フローをつくりこめない、出力の動作ロジックがブラックボックスでカスタマイズできないなどの不便さもあり、自作すると手放せなくなります。 関連するデータをわかりやすくフォルダに分けてダウンロードしておくだけでも、最近のモデルはいい感じに解析・動作をしてくれますが、データが増えてくるとカオスになりがち。 オススメは、「メダリオンアーキテクチャ」を採用することです。メダリオンとはオリンピックのような金・銀・銅メダルに由来する意味ですが、データをとにかく溜め込むBronze層、データを解析・構造化・正規化して扱いやすい形に整えるSilver層、KPI化や集計・分析などを行うGold層の三層に分け、欲しいアウトプットを生成させます。 例えばBronzeには取得したPDFやメール、議事録などの原本をそのまま保存し、Silverでは人物・企業・会議などの単位に構造化・正規化。Goldでは用途に応じてKPI化や集計・分析したデータを保存し、それをもとにレポートやダッシュボードなどを生成する、といったイメージです。 データ分析基盤のとてもベーシックなアーキテクチャですが、これを使うだけでデータ量がかなり増えても破綻しにくくなります。Bronze層は取得したPDFやPPTX、XLSXなどのデータそのものを触らず保存しておくことで、Silver層のロジックを変えてもいつでも再生成できることがポイントです。 この二つを作り込んでいくと、どんどんと大規模になっていきAIレベルがガンガン上がっていくはず。開発を効率化するためにloop engineeringやgraph engineeringに近いことをやりたくなってきて、関連ツールを自作したりと連鎖が止まらなくなって、つくりたいものだらけになります。 kubellの社内では「CEO’s AI Boot Camp」と題して私がコンテンツを作成したClaude Codeワークショップを定期開催しています。そのコンテンツのメインが、今回ご紹介したパーソナルエージェントとパーソナルナレッジベース。 小さくつくるのはそこまで難しくないので、毎日の業務の中から少しずつ育てていけるのがポイントです。ぜひ、チャレンジしてみてください！

1時間以上のインタラクティブ世界を、単一GPUで生成し続けられる——そんな世界モデルが登場しました。 Alaya-EVOKE: From Linear-Scaling Supervision to Endless World 動画世界モデルの核心技術を3つに絞り込み、徹底的に深掘りします。 🗺 注目ポイント1：外部幾何学メモリによるO(1)コンテキスト 従来の世界モデルは生成が長くなるほどトランスフォーマーの文脈長が爆発し、実質的に数分が限界でした。EVOKEは生成フレームから単眼深度推定を行い、カメラポーズでインデックスした「ワールドステートバンク」に3D点群として外部保存します。次チャンク生成時はバンクから必要な幾何学情報を検索してデノイザーに注入するため、セッションが65分を超えても各コールの入力サイズは1.5秒（9フレーム）のまま一定です。「セッション長は再帰コールの回数のみを増やし、各コールのコンテキスト長は一切増やさない」という設計が鍵です。 🎓 注目ポイント2：監督ホライゾンと勾配ホライゾンの分離 長期的な一貫性には長いホライゾンで監督する必要がありますが、バックプロパゲーションのメモリが問題でした。EVOKEは14B Wan2.2教師モデルを設計し、「教師は完全軌跡を評価するが、学生の勾配計算はチャンクごとに切り離す」という手法で解決します。制御実験では、長ホライゾン教師（30秒監督）の学生は輝度が101%で安定、短ホライゾン教師の学生は74%に下落（Wilcoxon p=0.016）。長い教師監督が長期一貫性の「要」であることが統計的に証明されました。 ⚡ 注目ポイント3：CFGなし3ステップ推論でVBench-2.0首位 CFG（Classifier-Free Guidance）を一切使わず、粗→細の潜在ピラミッドで3回のデノイジングのみ。それでもVBench-2.0でスコア66.77（10システム中1位）を達成し、多ステップシステムと同等品質を実現。1チャンク（1.5秒）の生成時間はH200 1枚で2.11秒です。 「持続的状態とデノイザーコンテキストのデカップリング」という発想の転換が、時間軸で破綻しない世界モデルへの道を開きました。 #世界モデル# #動画生成AI#

LLMが生成したテキストは古典的な機械学習で高精度に検出できるよ、というポスト。（検出は日本語対象ではない） ・昨今のネット小説界隈には、低品質なAI生成テキストが大量に溢れかえっている ・既存の予測確率を用いたAI検出手法は、推論コストが高く精度も非常に不安定 ・そこで筆者は、古典的な機械学習であるSVMを用いたテキスト分類を試みた ・約1万件の人間の書いたテキストと、複数のLLMに生成させたテキストを学習データとして用意 ・単語の出現頻度（TF-IDF）に基づく単純な判定だけで、まず約85%の精度を達成 ・さらに7つの異なるモデル用の分類器を作成し、多数決をとることで判定を強固にしてみた ・で、これを使って、某小説プラットフォームの上位作品を判定したところ、約32%でAI生成の疑いが強いことが判明 ・ただ、その中でAI使用を事前に明記している作品は一つもなかった ・AIっぽさを消すプロンプトや翻訳の往復を試しても、判定スコアはほとんど下がらなかった ・なぜか？ ・LLMの出力テキストには特有の統計的なパターンが非常に強く現れてしまうため ・そのため、最新の複雑なAIを使わずとも古典的な手法で十分に見抜ける ・AIによる創作物は底が浅くパターンの再構成に過ぎない（という指摘）

# AIエージェントをソフトウェアに組み込むプラクティス # Dry-run & Commit｜差分提示してから実行 🎯 LLMがハルシネーションしたパラメータで決済が走る。それ、dry-runで防げます。 Terraformの plan → apply と同じ発想をエージェントのツール呼び出しに適用。「何が変わるか」を見てから実行する二相プロトコルです。 🔥 解決する課題 LLMはハルシネーションで意図しないパラメータを生成することがあり、ツール呼び出しは副作用を伴います。この二つが掛け合わさると、存在しないリソースIDや桁違いの金額で不可逆な操作が実行されるリスクが生まれます。dry-runなしの直接実行では、人間が「エージェントが何をしようとしているか」を確認する手段がなく、問題は事後にしか検出できません。 💡 提案パターン 副作用を伴う操作を「計画（dry-run）→ 差分提示 → 承認 → 実行（commit）」の二相で行います。dry-runフェーズではシステムを一切変更せず差分だけを計算し、承認を得てからcommitフェーズで書込を実行します。承認方式はリスクに応じて段階化し、高リスクは人間承認、中リスクはポリシー自動検証、低リスクは自動承認とします。planにはTTLを設け、状態変化が起きていたら再生成を強制します。 ✅ 選定条件 使うとき： - 不可逆な操作（データ削除、外部API書込、課金処理）をエージェントが実行する - 誤操作が金銭的・法的・運用的な実害を生みうる - 差分を評価するための数秒〜数分の待機が許容される 使わないとき： - 全操作が読み取り専用の場合 - 全操作が可逆かつ低コストの場合（チャット応答生成など） - レイテンシ制約が極めて厳しく承認待ちが許容されない場合 ⚠️ 落とし穴 - planとcommitの間に状態が変わるTOCTOU問題があります。commit時に前提条件を再検証する設計が必須です - 外部APIがdry-runモードを提供していない場合は、パラメータ検証とシミュレーションで代替し「推定」であることを明示します - commitエンドポイントがplan IDなしで呼べると、dry-runを迂回できてしまいます 🔧 実装方針 - ツール実行をdry-run（差分計算のみ）→承認→commit（実行）の三段階パイプラインとして構成し、各フェーズを独立したエンドポイントに分離します - planオブジェクトに変更前後の値・影響範囲・ロールバック手順・前提条件のハッシュを含め、commit時に前提条件の再検証（TOCTOU対策）を行います - commitエンドポイントは有効なplan IDと承認トークンの両方を必須パラメータとし、直接呼び出しによるdry-run迂回を構造的に防止します - planにTTLを設定し、期限切れの場合は再planを強制することで、古い差分に基づく実行を防ぎます #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェントをソフトウェアに組み込むプラクティス # Critic/Judge & Sampling-Aggregation｜独立検証と多数決 🎯 LLMの出力を、同じLLMに「正しい？」と聞いていませんか？ 生成と検証を別系統にするだけで、自己確認バイアスを断ち切り、出力の信頼性を構造的に高められます。 🔥 解決する課題 LLMは確率的に出力が揺れ、事実と異なる内容をもっともらしく生成します。生成と検証を同一のモデル・プロンプトに任せると、生成時のバイアスが検証にも引き継がれます。法律文書のドラフトを生成したLLMに「この文書は正しいか」と尋ねても、自分の生成物に肯定的に評価しがちです。これが「自己確認バイアス」です。 💡 提案パターン 2つの手法を組み合わせます。まず、生成系とは別のモデル・別のプロンプト・決定論的コードで出力を検証する「Critic/Judge」。次に、同じ入力からN個の候補を生成し、スコアリングや多数決で最良を選ぶ「Sampling-Aggregation」。両者を組み合わせると「N個生成 → Judgeが各候補を評価 → 最高スコアを採用」となります。コストはN倍になるため、リクエスト価値と失敗コストが高い経路に限定して適用します。 ✅ 選定条件 使うとき： - 誤った出力がそのまま下流に流れると実害がある（契約書・医療要約・金融レポートなど） - 1回の生成に追加コストをかける経済合理性がある - 出力品質を客観的に評価できる基準がある 使わないとき： - 多少の誤りが許容されるカジュアルな対話 → ガードレールで十分 - レイテンシが極めて厳しい（数百ミリ秒以内） - 評価基準が主観的で定量化困難（創作文章の「面白さ」など） ⚠️ 落とし穴 - JudgeがGeneratorと同じバイアスを持つ場合があります。同じモデル・同じ知識で評価すると同じ種類の誤りを見逃します。異なるモデルファミリを使うか、決定論的チェックをJudgeの一部に組み込んでください - Nを増やしてもコストは線形に増えますが、品質向上は逓減します。N=1とN=3の差は大きいですが、N=3とN=5の差は小さいことが多いです。まずN=3から始めてください - Judgeのプロンプトに評価基準を明示してください。「正しいか」だけでは曖昧な判断になります。事実性・論理的整合性・スキーマ適合など具体的な軸を与えてください 🔧 実装方針 - Generator（候補生成）とJudge（評価）を別々のモデルまたは別プロンプトで構成し、同一系統による自己確認バイアスを構造的に排除します - N個の候補生成は並列実行し、レイテンシの増加を最小限に抑えます - Judgeの出力はスコアと理由を含む構造化データとして定義し、集約ロジック（最高スコア選択・多数決）を決定論的コードで実装します - 全候補がJudgeの品質閾値を下回った場合のフォールバック（再生成上限・人間エスカレーション）を事前に設計しておきます - 決定論的チェック（スキーマ検証・値域チェック・データベース照合）をJudgeの一部として組み込み、LLM判定だけに頼らない検証層を構築します #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェントをソフトウェアに組み込むプラクティス # Synchronous Edge Agent｜同期エッジ 🎯 キャッチーなメッセージ LLMエージェント、まず「同期で返せないか？」を考えていますか？ 非同期キューやチェックポイントに飛びつく前に、シンプルな同期HTTPで完結できないか検討しましょう。実際のユースケースの大半は、それで十分です。 🔥 解決する課題 エージェントアーキテクチャの議論はすぐに非同期キュー・チェックポイント・オーケストレータへ進みがちです。しかし多くのタスクは「LLM1回＋軽いツール」で済みます。軽量タスクに重い実行基盤を持ち込むと、運用コスト・デプロイ複雑性・デバッグ難度が不必要に跳ね上がります。 💡 提案パターン Synchronous Edge Agent（同期エッジ）は、単発のLLM推論と軽量ツール0〜2回を1つの同期HTTPリクエスト内で完結させる、最もシンプルな実行方式です。状態はインコンテキストのみで、チェックポイントもキューも不要です。テキスト分類・情報抽出・単純Q&A・要約・構造化出力生成など「数秒で終わる確実な処理」に最適です。タイムアウトはLLM呼び出し単位でp99実測値に基づいて設定し、モデル選択もレイテンシ予算の関数として決定します。迷ったらまずここから始めてください。 ✅ 選定条件 使うとき： - 処理が概ね5〜10秒以内に終わる（対面）、またはAPI連携で30秒以内 - LLM呼び出しは1回、ツール呼び出しは0〜2回の軽量処理 - 途中再開や人間承認が不要 使わないとき： - 処理が30秒を超えうる、または所要時間が読めない場合 - 複数ツールの多段呼び出しや計画・反省ループが必要な場合 - 不可逆な副作用（決済・データ削除等）を伴う場合 ⚠️ 落とし穴 - タイムアウトはHTTPサーバ全体でなくLLM呼び出し単位で設定すること。全体タイムアウトだけではLLMがハングしてワーカースレッドを占有し続けます - 同期枠内でのリトライは0〜1回に限ること。リトライを重ねるとクライアントが先にタイムアウトします - サーバーレス環境ではコールドスタートがレイテンシ予算を食うため、Provisioned Concurrencyやウォームアップで対処が必要です 🔧 実装方針 - クライアントからのHTTPリクエストをAPI Gateway経由でハンドラが受け取り、1つのリクエスト-レスポンスサイクル内で処理を完結させます。外部キューやチェックポイントストアは登場しません - タイムアウトはHTTPサーバ全体ではなくLLM呼び出し単位で設定し、その値はlatency_budgetから導出します。p95/p99の実測値に基づいて調整します - モデル選択もレイテンシ予算の関数として決定します。分類・抽出には軽量モデル、生成にはミッド〜フラグシップを選びます - 構造化出力（JSON Schema等）を使い、レスポンスの軽量検証を常にONにします。意味検証はレイテンシに余裕がある場合のみ追加します - 対面UIで生成が長文になる場合はSSEストリーミングを併用し、体感レイテンシを短縮します #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェントをソフトウェアに組み込むプラクティス # メモリ書込ゲート 🎯 LLMの推測がそのまま長期メモリに入り、次のセッションで「事実」として参照される。メモリ汚染は沈黙のうちに蓄積します。 長期メモリへの書込にバリデーションを設けるのは、DBへの入力検証と同じ原則です。 🔥 解決する課題 長期メモリへの書込は「一度入ったら長く残る」不可逆に近い操作です。書込ゲートがなければ3つの問題が連鎖します。エージェントが生成した誤情報がそのまま保存されハルシネーションが自己強化する。外部入力に埋め込まれた悪意ある指示がメモリに書き込まれ、将来のセッションまで攻撃が持続する。同じ事実が微妙に異なる表現で何度も保存され、検索時に矛盾が返って応答品質が劣化する。メモリ汚染はログにエラーを残さないため、発見が特に遅れます。 💡 提案パターン 長期メモリへの書込を無条件に許可せず、信頼度スコアリング・重複検出・PII/機微情報フィルタ・ソース検証のゲートを設けます。ユーザが直接述べた事実は自動書込、推測や未検証情報は隔離領域に留め置き、人間または上位エージェントの承認を待ちます。重複検出ではコサイン類似度0.90〜0.95を閾値とし、同一エンティティ×同一属性なら上書きします。input_trustが低いほど信頼度閾値を上げ、failure_costが高い領域ではさらに厳格にします。 ✅ 選定条件 使うとき： - セッションを跨いで持続する長期メモリを持つ - エンドユーザの自由入力や外部ドキュメントからメモリ候補を抽出する - 誤った記憶が金銭的判断・医療助言・法的回答など後続の意思決定に影響する 使わないとき： - メモリがセッション内スクラッチパッドのみで、セッション終了時に破棄される場合 - メモリが完全に管理者管理でエージェントは読取専用の場合 ⚠️ 落とし穴 - 隔離領域は承認フローが回らないと肥大化します。TTL（7〜30日）を設け未承認は自動破棄してください - エンベディングの類似度だけでは「同じ人物の異なる属性」と「同一属性の更新」を区別できません。構造化メタデータを併用しましょう - メモリストアへの直接書込パスが残っていると、ゲートが完全に無意味になります 🔧 実装方針 - 書込ゲートを重複検出→信頼度スコアリング→PII/機微情報フィルタの3段パイプラインとして構成し、全書込を必ずこのゲートを経由させます - 信頼度スコアリングではソース（ユーザ直接/エージェント推論/外部文書）とグラウンディング（引用あり/なし）の組み合わせで分類し、閾値未満は隔離領域に留め置きます - 重複検出ではコサイン類似度に加えてエンティティID×属性キーの構造化メタデータを併用し、更新と新規を正確に区別します - 隔離領域にはTTLを設けて未承認エントリを自動破棄し、メモリストアへの直接書込APIはアーキテクチャ制約として禁止します #AIエージェント# #ソフトウェアアーキテクチャ#