AIを深く使っている人と、AIを拒否する人の会話が噛み合わないのは、そもそも守ろうとしているものが違うからだと思う。 AIを使いこなすほど、関心は「自分がどこまで作業したか」から、 ・何を決めたか。 ・何を引き受けたか。 ・どの結果に責任を持つか。 という ownership、accountability、integrity の話へ移っていく。 だから、AIを使いたくない人に対しても、 「使いたくないなら、使わなくていいんじゃない？」 と平気で言える。単に手段の選択だからだ。 ところが、AIを拒否する側が、人間の価値や職人としてのプライドの話をしていると、この言葉さえ、 「お前は取り残されればいい」 「お前には価値がない」 という侮辱に聞こえるらしい。 使う側は選択の話をしている。 拒否する側は承認の話をしている。 AIを使い込むほど、人は「自分は何者か」よりも「自分は何を引き受けるか」を考えるようになる。 一方、AIを拒否する人は、相変わらず「人間のプライド」を守ろうとしている。 前者は accountability の言葉で話し、後者は pride の言葉で話す。 そりゃ、会話が噛み合わない。

# AIエージェント開発の意思決定ポイント # オーケストレーション vs コレオグラフィ 🎼 🎯 ポイント 複数のエージェントやサービスを協調させるとき、「指揮者を置くか、各自が自律的に踊るか」を選ぶ必要があります。 オーケストレーションは中央の指揮者がすべてを統制する方式。コレオグラフィは各コンポーネントがイベントに反応して自律的に動く方式。制御の所在が根本的に異なるため、障害処理・監査・デバッグ・スケーリングの設計が全く変わります。 📋 概要 オーケストレーションでは中央のオーケストレータが全体のワークフローを定義し、各コンポーネントを順次または並列に呼び出し、結果を集約して次のステップを決定します。Temporal、Airflow、LangGraphのSupervisorパターンなどが典型的な実装基盤です。コレオグラフィでは各コンポーネントがイベントバス（Kafka、EventBridge等）上のイベントを購読し、関心のあるイベントに自律的に反応して新たなイベントを発行します。全体の制御フローを知る中央は存在しません。 🔍 意思決定のポイント 判定の主軸は **説明責任（accountability）** です。 🏛️ **オーケストレーションに倒す条件**: - 処理の全体像と各ステップの判断根拠を事後に説明する必要がある - 審査→承認→実行のような厳密な順序制約がある - LLMの出力を次のステップに渡す前に検証・変換が必要 - 全体の予算（トークン・時間・コスト）を中央で管理したい - コンポーネント数が概ね10以下 🌊 **コレオグラフィに倒す条件**: - 高スループット・高スケールが求められ、中央がボトルネックになる - 多数のチームが独立してコンポーネントを開発・デプロイしている - イベントへの「反応」が主な処理パターン（通知、ログ、非同期集計） - 実行順序の厳密な追跡が不要 💡 要点と詳細 🟢 **オーケストレーションの強み**は制御の明確さと監査性です。ワークフローの全体像が1箇所に定義されているため「今どこまで進んでいるか」「なぜこのステップが実行されたか」が常に明らかです。障害時のリカバリもどのステップで失敗したかを特定して再開できます。エージェント固有の利点として、LLMの出力を検証してから次ステップに進められるため、ハルシネーションの伝播を各ステップで遮断できます。 🟡 **コレオグラフィの強み**は疎結合とスケーラビリティです。各コンポーネントはイベントスキーマだけを共有し、他の存在を知りません。新コンポーネントの追加はイベント購読の追加だけで、既存コンポーネントに変更不要です。独立スケールも可能で、イベントバスがバッファとして一時的な負荷偏りを吸収します。 ⚖️ トレードオフ | 観点 | オーケストレーション | コレオグラフィ | |---|---|---| | 全体状態の可視性 | 常に明確 🟢 | イベントログの突合が必要 🔴 | | 監査性 | 高い（因果関係を示せる） | 低い（分散した追跡が必要） | | スケーラビリティ | 中央がボトルネック | 各コンポーネントが独立スケール | | 結合度 | 高い（中央への変更が集中） | 低い（スキーマ共有のみ） | | ハルシネーション制御 | ステップごとに検証可 | 各自でガードレールが必要 | | チーム独立性 | オーケストレータ変更で衝突 | 独立開発・デプロイ可 | 🛠️ ユースケース 🔵 **オーケストレーションが向くケース**: 業務系システム、規制対象の処理、審査・承認ワークフロー、LLMの出力検証が必要な処理。説明責任が求められる環境。 🔴 **コレオグラフィが向くケース**: 高スループットのイベント駆動処理、通知・ログ集約・分析パイプライン。多数のチームが独立してコンポーネントを開発する大規模システム。 📌 **デフォルト戦略**: 業務系システムではオーケストレーション（中央集権）がデフォルトです。AIエージェントを含むシステムでは、LLMの確率的な出力を制御・検証する中央の存在が安全性と監査性の両面で重要です。実用的な折衷は「中核は中央集権、周辺探索はイベント駆動」で、主要な業務フローはオーケストレータが管理し、周辺の非同期処理はイベント駆動で疎結合に構成する形です。 #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェント開発の意思決定ポイント # トレース・サンプリング率｜Trace Sampling Rate 🎯 ポイント エージェントのトレース、全量記録していますか？それとも全く記録していませんか？ 「全量か無か」ではなく「何を全量にするか」が正しい問いです。AIエージェントの1リクエストは数千〜数万トークンのトレースデータを生成します。全量記録すると観測コストが爆発し、記録しなければ障害時に原因究明が不可能。条件付きサンプリングがこのジレンマを解決します。 📋 概要 トレース・サンプリング率は、エージェントの実行トレース（各LLM呼び出し、ツール実行、意思決定のステップごとの記録）をどの割合で収集・保存するかを制御するパラメータです。100%ならすべてのリクエストのトレースを記録し、1%なら100リクエストに1件だけ記録します。 AIエージェントのトレースは従来のWebサービスのログとは質的に異なります。プロンプト全文、出力全文、ツール引数・戻り値、中間的な推論ステップなどを含めると、1リクエストで数十KB〜数百KBのデータが生成されます。さらにLLMの出力は確率的なため、「同じ入力を再投入すれば再現できる」という前提が成り立ちません。 🔍 意思決定のポイント サンプリング率はaccountability（説明責任）とcost_sensitivity（コスト感度）のバランスで決まりますが、最も重要なのは条件付きサンプリングの設計です 🎯 一律の確率ではなく、リクエストの属性に応じて率を変えます。 判定基準の優先順位: 1. エラー/例外が発生したリクエスト → 100%記録（必須） 2. HITL（人間介在）が発生したリクエスト → 100%記録 3. 高リスク操作（副作用あり、不可逆）を含むリクエスト → 100%記録 4. レイテンシがP95を超えたリクエスト → 100%記録 5. コストが閾値を超えたリクエスト → 100%記録 6. 成功したリクエスト → 標本率で記録（1〜10%） 💡 要点と詳細 目安値 📊 - エラー/例外発生 → 100%。再現性のない障害のデバッグに不可欠 - HITL発生（人間承認/エスカレーション） → 100%。承認判断の妥当性を事後検証 - 高リスク操作（送金、データ削除等） → 100%。不可逆操作の監査に必須 - レイテンシP95超過 → 100%。性能劣化の根本原因分析に必要 - 成功かつ低リスク → 1〜10%。品質の統計的モニタリングに十分 - 開発・ステージング環境 → 100%。コストが問題にならない範囲で全量記録 トレースの粒度をサンプリング率とは別に制御するのも重要です 📦 全量記録するリクエストでも、プロンプト全文はコールド層に、メタデータ（モデル名、トークン数、レイテンシ、ステータス）はホット層に分離します。 ⚖️ トレードオフ サンプリング率が低すぎると、障害の再現が不可能になります 🔍 LLMの出力は確率的なため、同じプロンプトを再投入しても同じエラーが再現するとは限りません。品質劣化の見逃し、監査要件の不達成、コスト異常の遅延検知も深刻なリスクです。 サンプリング率が高すぎると、観測コストが本番のLLM呼び出しコストに匹敵するか上回ることがあります 💸 パフォーマンスへの影響、PII（個人情報）の拡散リスク、大量データ中の信号がノイズに埋もれる問題も発生します。 サンプリング率は運用開始後に段階的に下げてください。最初は高い率（50〜100%）で始め、安定性を確認してから成功リクエストの率を徐々に下げます。 🛠️ ユースケース サンプリング判定はリクエストの終了時に行うことも検討してください 🔄 head-based sampling（開始時に決定）は実装が簡単ですが、エラーが発生するかどうかは事前に分かりません。tail-based sampling（完了後に決定）なら結果に基づいて判定できます。ただし中間データを一時的にバッファする必要があります。 correlation ID（trace ID）の伝播を確実にしてください 🔗 マルチステップのエージェント実行では、最初のリクエストから最後のツール呼び出しまで一貫したtrace IDが紐づいていないと、部分的なトレースしか得られません。非同期処理やキューを介する場合にIDが途切れやすいので要注意です。 ホット/コールド分離と組み合わせるのが効率的です。サンプリングされたトレースはコールド層に全文を、それ以外はホット層にメタデータのみを記録する構成が実用的です。 #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェント開発の意思決定ポイント 🎯 **ポイント** RAGのtop-k、なんとなく「5」にしていませんか？検索結果を多く入れれば根拠が増えると思いきや、LLMは中盤の情報を無視しがちで、コストだけが直線的に増加します。少なすぎればハルシネーション、多すぎればノイズと予算超過。このバランスを取るための実践的な考え方を解説します。 📋 **概要** 検索top-kは、RAG（Retrieval-Augmented Generation）において外部知識ストアから取得する文書チャンクの件数を制御するパラメータです。広義には「LLMのコンテキストウィンドウに投入する外部情報の量」を意味します。コンテキストウィンドウは有限の資源であり、システム指示・検索結果・会話履歴・長期メモリ・ツール出力が奪い合っています。検索結果を多く入れれば根拠は増えますが他の情報が押し出され、少なければ根拠不足でハルシネーションが増えます。 重要なのは件数だけでなく「何を上位に置くか」です。初期検索で広めに候補を取り、リランカーで信号密度の高い順に並べ替えて上位k件を投入するパイプラインが標準的です。 🔍 **意思決定のポイント** top-kの設定は主に以下の変数で決まります。 🔹 **コスト感度（cost_sensitivity）** — コスト感度が高いほどtop-kを絞ります。ただし最低限の根拠確保のためk=3を下回ることは稀です。kを5から20に増やすと検索結果部分のトークンは概ね4倍、コストもそれに比例します。 🔹 **失敗コスト（failure_cost）** — 失敗コストが高い領域では根拠の網羅性が重要。kを多めにとりリランクで品質を担保する戦略が有効です。ただしリランクスコアが閾値を下回る文書は切り捨てるべきです。 🔹 **説明責任（accountability）** — 回答の根拠として引用できる文書を確保する必要がある場合、kを増やすよりもリランクスコアの高い少数の文書を確実に含め、出典を明示する方が効果的です。 💡 **要点と詳細** 実践的な判定フローは以下の通りです。 1️⃣ 初期検索では広めに取得（概ねk=20〜50） 2️⃣ リランカーで関連性スコア順に並べ替え 3️⃣ スコアが閾値を超える文書のうち上位k件を投入 4️⃣ 投入後のトークン数がコンテキストウィンドウの50%を超えないよう制御 5️⃣ 超える場合は圧縮（要約）またはさらなる絞り込み 📊 目安値: - 初期検索の取得件数: 20〜50件（リランク用の候補プール） - リランク後の投入件数: 3〜8件（大半のユースケースで5件前後が出発点） - 検索枠のウィンドウ占有率: 20〜40%（50%超で圧縮検討） - チャンクサイズ: 200〜500トークン kの値は「件数の定数」ではなく「リランクスコアが閾値を超えた文書の件数（上限k件）」として動的に決めるのが理想です。高関連の文書が2件しかなければ2件だけ投入し、無理にk件まで埋めません。 ⚖️ **トレードオフ** 📉 top-kが小さすぎると — 回答に必要な情報が検索結果に含まれず、LLMが根拠なしに回答を生成します。特に複数文書からの情報統合が必要な場合（「A社とB社の比較」など）、1件では対応できません。取得件数が少ないと1件のノイズの影響も甚大で、k=2なら1件のノイズが50%を占めます。 📈 top-kが大きすぎると — "Lost in the Middle"問題が顕在化します。LLMはコンテキストの先頭と末尾に注意を集中させ、中盤の情報は実質的に無視される傾向があります。大量投入すると最重要情報が中盤に埋もれます。他の情報枠（システム指示・会話履歴・長期メモリ）も圧迫され、エージェント全体の振る舞いが劣化します。 🛠️ **ユースケース** ❓ **単純な事実質問**（「A社の設立年は？」）— k=2〜3で十分。単一の文書で回答可能なケースがほとんどです。 📊 **比較・分析質問**（「A社とB社の戦略の違いは？」）— k=5〜8が必要。複数ソースからの情報統合にはより多くの文書が必要です。クエリ分類器で場合分けすると効率的です。 🏥 **医療・法務の高精度Q&A** — 根拠の網羅性と出典の明示が両方求められる。初期検索を広く取りリランクで厳選、スコアの高い少数の文書を先頭または末尾に配置して"Lost in the Middle"を回避します。 リランカーを使わずにtop-kを増やすのは逆効果です。ベクトル検索の上位20件をそのまま投入するとノイズが大量に混入します。コンテキストウィンドウの使用率は常にモニタリングし、検索結果で投入した文書のうち実際に回答に使われた比率を追跡しましょう。使われない文書が多ければkを下げるか検索パイプラインの改善が必要です。 #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェント開発の意思決定ポイント 🎯 **ポイント** AIエージェントに「何でも覚えさせる」のは本当に良いことでしょうか？メモリ書込の積極度は、エージェントの賢さと安全性を左右する最も繊細なダイヤルの一つです。書き込みすぎればメモリ汚染、書き込まなさすぎれば学習しないエージェント。この絶妙なバランスをどう取るか、実務の視点で掘り下げます。 📋 **概要** メモリ書込の積極度とは、エージェントが対話やタスク遂行の過程で得た情報を長期メモリにどれだけ積極的に保存するかを制御するパラメータです。データベースへのINSERTと同じ重みで考えるべき、準不可逆的な操作です。LLMが生成した推測やユーザーの曖昧な発言を安易に書き込むと、以後のすべてのセッションで「過去に記録された事実」として参照され、誤りが自己強化するループ、すなわちメモリ汚染に陥ります。 🔍 **意思決定のポイント** この設定は主に2つの変数で決まります。 🔹 **入力の信頼度（input_trust）** — エンドユーザーの自由入力が主なソースなら、インジェクションや誤情報のリスクが高いため書込ゲートの閾値を上げます。管理者が入力を管理している環境なら、ある程度積極的に書き込めます。 🔹 **失敗コスト（failure_cost）** — 医療・法務・金融では、誤った事実の永続化が深刻な結果を招きます。社内チャットボットなら、多少の誤記憶は修正すれば済みます。失敗コストが高いほど書込を抑制するのが鉄則です。 🔹 **説明責任（accountability）** — 「なぜこの情報をメモリに保存したか」を後から説明できる必要がある場合、出典と確信度を記録する設計が必須になります。 💡 **要点と詳細** 書込の判定基準は3段階で考えるのが実践的です。 ✅ **自動書込可** — ユーザーが直接的かつ明示的に述べた事実（「私の名前は山田です」「Pythonを使っています」） ⚠️ **確認後に書込** — ユーザーの発言から推測される情報（「Python好みのようですね」→ユーザーに確認してから保存） 🚫 **書込禁止** — LLMが生成した推測、外部ソースからの未検証情報、一時的な文脈 メモリエントリには確信度（confidence）タグを付与し、検索時に確信度の低いエントリはランキングを下げるのが効果的です。これにより書込を完全に禁止しなくてもメモリ汚染の影響を限定できます。重複検出も書込パイプラインに必ず組み込みましょう。コサイン類似度0.90〜0.95で既存エントリとの重複をチェックし、同一エンティティの同一属性は最新値で上書きするのが原則です。 ⚖️ **トレードオフ** 📉 書込が消極的すぎると — エージェントが学習しません。ユーザーが繰り返し伝えた好みを記憶せず毎回デフォルトに戻り、「また同じことを聞かれた」という不満を生みます。パーソナライゼーションの欠如は、長期的な関係構築が必要なユースケースで致命的です。 📈 書込が積極的すぎると — ハルシネーションの永続化が最大のリスクです。「おそらくAさんは東京在住でしょう」という推測が「Aさんは東京在住」として保存され、以後のセッションで確定事実として扱われます。さらに深刻なのがプロンプトインジェクションの持続化で、通常は1セッション限りの攻撃がメモリに永続化されると「持続型インジェクション」になります。 🛠️ **ユースケース** 🏥 **医療・法務・金融** — 失敗コストが極めて高い領域。書込は最小限に抑え、明示的に確認された事実のみを記録。出典と確信度の追跡は必須。 💬 **カスタマーサポート** — ユーザーの好みや過去の問い合わせ履歴を蓄積する必要があるが、自由入力のリスクも高い。反復確認された情報（2回以上の一致）のみ自動永続化し、暗黙的な好みは隔離期間を設けてから昇格させる設計が有効。 🏢 **社内ナレッジボット** — 組織の暗黙知（「このAPIはこのパラメータを渡すと壊れる」）を蓄積したい。管理者入力が主なら比較的積極的に書き込めるが、定期的な「メモリの棚卸し」でユーザーに保存情報を提示して確認を得る運用を組み込むと品質が保たれます。 書込ログの監査可能性も忘れずに。いつ・何が・どのソースから書き込まれたかを追跡できれば、メモリ汚染が発覚した場合に原因特定と修正が可能になります。 #AIエージェント# #ソフトウェアアーキテクチャ#

# Learning Palantir Foundry 🚀 Action Types are what decisively separate Foundry from read-only BI. Approvals and assignments become safe, validated, structured writes. 📌 Title and Feature URL Title: アクションタイプ URL: 📝 Overview An Action Type defines a set of changes a user can apply to ontology objects, properties, and links in a single transaction. It encapsulates both the data modifications and any side effects triggered on submission, letting users think in terms of overall goals rather than individual property edits. 🔧 How It Works - Write-back to the ontology: when an action runs, all changes are committed to the ontology and reflected across every app. The latest object data, including user edits, is captured in the object type's write-back dataset. - Parameters and defaults: parameters standardize input, supporting default values, filtered dropdown results, and overrides. - Rules: define when and how an action executes, including object relationships and property constraints. - Submission criteria and validation: validation rules control execution eligibility and error handling before changes persist. - Action logs: a full audit trail of every executed action supports accountability and compliance. 🛠 Practical Usage - Run an "Assign Employee" style action that changes a role property, auto-creates a manager-employee link, and notifies stakeholders in one transaction. - Embed submission criteria like "only a director may submit amounts over 1M yen" as validation, replacing Excel-plus-email approvals with structured operations. - Reuse the same validation logic and workflow consistently across every user-facing app. 🎯 Use Cases - Standardize status changes, approvals, and assignments as permissioned, criteria-bound operations. - Let non-technical users safely execute multi-step changes spanning several objects. - Use the action log of every operation as an audit trail for internal controls. ⚠️ Caveats - Actions execute only after passing their validation rules, so submission-criteria design drives the quality of your controls. - Changes propagate immediately across the ontology and all apps, so do not leave rule and parameter design ambiguous. #PalantirFoundry# #Ontology#