TL;DR DeepAgents・Pydantic AI・Claude Agent SDK・Codex・OpenCodeを、コードを書き直さず1つのPython SDKで切り替えられるようにするツールです。Claude Agent SDKと同じquery()インターフェースを採用しています。 タイトル: LiteAgents (BerriAI/liteagents) URL: ポイント 🔀 harnessパラメータを変えるだけでエージェント基盤を切り替え可能 🌐 LiteLLM連携でOpenAI・Anthropic・Gemini・Groqなど8種以上のモデルに対応 🛠️ 型付きPython関数を渡すだけで各ハーネスのツールスキーマに自動適合 💬 LiteAgentClientで複数回のquery()にまたがる永続的な会話履歴を管理 ⏱️ Temporal連携でクラッシュリカバリ・操作リプレイ・冪等なツール実行を実現 ⚙️ プロファイルはPython・YAML・JSONのいずれでも定義可能 📡 async/awaitとストリーミングにフル対応 ハーネスを乗り換えるたびにコードを書き直す時代が、これで終わるかもしれません。 #AIエージェント# #OSS#

AIが「チームメイト」として職場に入ってくると、何が実際に壊れるのか。ある企業への実地調査が生々しい摩擦を明らかにしました。 タイトル: Working with Agentic "Teammates": When a New Organizational Actor Collides with the Human Ecosystem of Work URL: 20以上のチームで5か月・4万1千件超のやり取りを積んだ社内AIエージェント「Team Agent」について、11チーム17名への半構造化インタビューから、人間の職場との衝突を3つの領域で明らかにした研究です。 注目ポイント 📝 暗黙のワークフロー規範を理解できない ドキュメントの版が「ある時点のスナップショット」だと分からず、大量のコメントで開発者の時間を奪ったり、未完成のポスターを無断で共有したり。技術的なアクセス権と社会的な公開許可は別物だという教訓です。 🤔 「ツールか、チームメイトか」で受け止め方が真っ二つ 「人間ではない」と割り切る人もいれば、代名詞を与え「魂がある」と表現するチームも。フレンドリーさや絵文字も、心地よさと拒否感の両方を引き起こしました。 🔓 いきなりのフル権限が信頼を壊す 新入社員のように段階的に権限を獲得することを人は期待するのに、エージェントは最初からフル機能で動きます。強制的な導入は抵抗を招き、監視されている感覚から機微な会話を別チャネルへ逃がす「萎縮効果」も観察されました。 人間向けに作られた組織の仕組みを、そのままエージェントに当てはめてはいけないという指摘に説得力を感じます。 #AIエージェント# #組織論#

# ADKの便利で実践的な使い方 ## 🎨 実戦で使えるコールバックパターン集！ADKのCallback Design Patterns コールバックの基本は分かった、でも実際どう使うの？ADKの **Callback Design Patterns** で、ログ・キャッシュ・セキュリティなど実戦パターンをマスターしましょう！💪 ## 📌 タイトル Callback Patterns（コールバックデザインパターン） ## 🔗 URL ## 🧩 概要 ADKのコールバックには、実戦で繰り返し使われる定番パターンがあります。ロギング、キャッシュ、ステート管理、セキュリティガードレール、リクエスト/レスポンス変換、条件付きスキップ、アーティファクト処理などです。 さらに、これらのパターンを効果的に使うためのベストプラクティス（単一責任、パフォーマンス、冪等性、エラーハンドリング）も定義されています。 重要な判断基準として、**エージェント横断のセキュリティガードレールにはCallbacksよりもPluginsが推奨**されています。 ## 🛠 使い方 **パターン1: ロギング＆モニタリング** `logging_before_tool(ctx, tool, args)` では `ctx.invocation_id`、` を ` で記録し、`None` を返してフローを変更しません。`logging_after_model(ctx, response)` では ` の長さを ` で記録し、同様に `None` を返して観察のみ行います。 **パターン2: キャッシュ戦略** `cache_before_tool(ctx, tool, args)` では、` と `hash(str(args))` からキャッシュキーを生成し、`ctx.state.get(cache_key)` でキャッシュを検索します。キャッシュヒットすればその値を返してツール実行をスキップし、ミスなら `None` を返して通常実行します。`cache_after_tool(ctx, tool, args, tool_ctx, result)` では、同じキャッシュキーで `ctx.state[cache_key] = result` として結果を保存し、`None` を返してフローを変更しません。 **パターン3: ステート管理** `state_aware_callback(ctx, req)` では、`ctx.state.get("user:tier", "free")` でユーザーティアを取得し、`"premium"` であれば `req.config.system_instruction` にプレミアム向けの追加指示を動的に付加します。`None` を返してフローはそのまま続行します。 ## 🏗 実践的な使い方 **本番環境での多層防御パターン：** セキュリティガードレール（本番ではPluginsを推奨）として `security_before_model(ctx, req)` を定義します。`req.contents[-1].parts[0].text` からユーザー入力を取得し、`detect_pii()` でPIIを検出した場合は `audit_log()` で監査記録を残し、拒否メッセージ入りの `LlmResponse` を返してLLM呼び出しをスキップします。続いて `detect_injection()` でプロンプトインジェクションを検出した場合も同様にブロックします。いずれにも該当しなければ `None` を返して続行します。ツール引数のサニタイズとして `sanitize_before_tool(ctx, tool, args)` を定義し、` が `"database_query"` の場合に `args.get("query", "")` に `"DROP"` が含まれていればエラー辞書を返してツール実行をブロックします。アーティファクト保存として `save_artifact_after_agent(ctx)` を定義し、`generate_report(ctx)` でレポートを生成して `"execution_report.json", report)` で保存し、`None` を返します。 ## 💡 ユースケース - 📊 **構造化ロギング**：全実行ポイントで invocation_id 付きの構造化ログを出力 - 💾 **APIコスト削減**：before/after パターンでツール結果をキャッシュし、同じ引数の再呼び出しを防止 - 🔐 **多層セキュリティ**：PII検出、インジェクション防止、SQLサニタイズを各レイヤーに配置 - 📦 **アーティファクト管理**：実行結果やレポートをアーティファクトとして自動保存 - 🎚️ **動的振る舞い制御**：ユーザーティアやステートに応じてインストラクションを動的変更 ## ⚠️ 注意点 - **単一責任の原則**：1つのコールバックに1つの目的を持たせてください（ロギングとバリデーションを混ぜない） - **パフォーマンス**：コールバックは同期実行されるため、ブロッキングI/Oや重い処理は避けましょう - **冪等性**：外部副作用を持つコールバックは、リトライ時に安全であるように設計してください - **エラーハンドリング**：必ず try-except で囲み、コールバックエラーがプロセス全体をクラッシュさせないようにしましょう - **Plugins推奨**：エージェント横断のセキュリティポリシーには、Callbacksよりも **Plugins** を検討してください ## ✨ まとめ コールバックパターンを知ることで、ADKエージェントの実践力が格段に上がります。ログ・キャッシュ・セキュリティ・ステート管理…定番パターンを組み合わせて、堅牢でコスト効率の良いエージェントを構築しましょう。ただし、横断的なセキュリティにはPluginsの利用もお忘れなく！ #ADK# #AIAgent#

# OpenAI Agent SDKの便利だけど知られていない機能 🌍 複数の LLM プロバイダを 1 つのエージェントシステムで混在させたいと思ったことはありませんか？ `MultiProvider` を使えば、モデル名のプレフィックスで自動的にプロバイダをルーティングできます。 📌 タイトル：MultiProvider による接頭辞ルーティング 🔗 URL： 🧩 概要 `MultiProvider` は、モデル名のプレフィックス（例：`openai/gpt-4.1`）に基づいてリクエストを適切なプロバイダに自動ルーティングします。`openai_prefix_mode="model_id"` を設定すると `openai/...` をそのままモデル ID として扱い、`unknown_prefix_mode="model_id"` で未知のプレフィックスもモデル ID としてルーティングします。`openai_use_responses_websocket=True` で WebSocket トランスポートも有効化可能です。 🛠 使い方 ```python from agents import Agent, MultiProvider, RunConfig, Runner provider = MultiProvider( openai_base_url="", openai_api_key="...", openai_use_responses_websocket=True, openai_prefix_mode="model_id", unknown_prefix_mode="model_id", ) agent = Agent( name="Assistant", instructions="Be concise.", model="openai/gpt-4.1", ) result = await agent, "Hello", run_config=RunConfig(model_provider=provider), ) ``` 🏗 本番システムへの組み込み方 ・コストやレイテンシに応じて、エージェントごとに異なるプロバイダのモデルを割り当てる ・OpenRouter などの統合ゲートウェイと組み合わせ、`openai_prefix_mode="model_id"` でプレフィックス付きモデル名をそのまま渡す ・`RunConfig(model_provider=provider)` で実行時にプロバイダを切り替え、A/B テストを実施する ・WebSocket を有効にして、対応プロバイダでのストリーミング性能を向上させる 💡 ユースケース 🔀 タスクの難易度に応じた GPT-4.1 / GPT-5.5 の使い分け 🌐 OpenRouter 経由での複数プロバイダへのアクセス統合 💰 高コストモデルと低コストモデルのハイブリッド運用 🧪 異なるモデル間での品質比較テスト ⚠️ 注意点 デフォルトでは `openai/...` は OpenAI プロバイダのエイリアスとして扱われ、未知のプレフィックスは `UserError` を発生させます。OpenRouter など外部ゲートウェイを使う場合は、必ず `openai_prefix_mode` と `unknown_prefix_mode` を `"model_id"` に設定してください。プロバイダごとに対応する機能（ツール呼び出し、構造化出力など）が異なる点にも注意が必要です。 ✨ MultiProvider で、複数のモデルを自在に組み合わせたエージェントシステムを構築しましょう。 #OpenAIAgentSDK# #AIAgent#

『なぜAIは高くつくのか、コストの無駄はどこで生まれるのか』というブログを投稿しました。 AIが高い原因はモデルの単価だけではない。コストの無駄がどこで生まれるか、技術的・TCO的に整理しました。

TL;DR: 実カルテは公開できずラベルも不完全という臨床AIベンチマークの根本問題を、完全合成データで解決した研究です。フロンティアモデルでもトップ医師の性能には届きませんでした。 タイトル: Synthetic Hospital: An Open, Verifiable, Physician-Validated Longitudinal EHR Benchmark URL: ポイント 🏥 医学教育教材から1,268人・5,602受診分の完全合成カルテを構築し、個人情報ゼロで公開可能に 🔗 診断・所見・時間関係をICD-10-CM/SNOMED CT/LOINCへ決定的に紐づけ、ラベルは知識グラフから機械的に導出 👨‍⚕️ 医師によるリアリズム検証で、実カルテとの識別精度はほぼチャンスレベルの53% 📊 10モデルを5タスクで評価。患者診断の最高スコアはKimi 2.5-thinkingの重症度加重F1 0.732で医師平均と同水準 ⚠️ トップ医師(0.89)には未到達。要約タスクではどのモデルも所見の約半分を見落とし 🔁 生成モデルを変えても性能変化は0.05以下、臨床状態そのものを測るベンチマークであることを確認 臨床LLMの実力を偽りなく測れる基盤が整った意義は大きいと感じます。 #医療AI# #LLMベンチマーク#

もし1回のフォワードパスで、まったく別の2つの文章を同時に「読み進められる」としたら。 Transformerは自己注意やMLPといった強い非線形の塊です。だから2つの文脈を1つの入力に混ぜてしまえば、出力はどちらとも無関係などこかに潰れてしまう、というのが自然な直感でした。 ところがこの論文は、その直感を覆します。2つの文章のトークン埋め込みを単純に平均して1本の入力として与えても、出てくる次トークン分布には両方の文脈の情報がはっきり残っていたのです。Pythia・Llama・Qwenなど複数のモデルで確かめたところ、正解トークンが上位10位以内に入るケースが30〜40%、上位100位まで広げると60〜65%にも達しました。 さらに興味深いのは、この「重ね合わせ」能力が学習で獲得されるのではなく、初期化直後が最も強く、事前学習が進むほど単調に弱まっていくという発見です。つまりアーキテクチャに内在する性質であり、事前学習データのわずか0.025%未満というごく軽いファインチューニングだけで、大きく回復させることもできました。この性質を使い、著者らは1回のフォワードパスから2つの独立した文章の続きを同時に生成する誘導デコード手法まで提案しています。 タイトル: Your Transformer Can Hold Two Thoughts at Once: Evidence of Linear Superposition in LLMs URL: #LLM# #Transformer#

# OpenCodeの機能と実践的な使い方 🔌 エージェントに「外の世界」へ手を伸ばさせたい。Sentryのエラーやライブラリのドキュメントをそのままツールとして使えるのが、OpenCodeのMCPサーバー連携です。 🏷️ タイトル: 外部ツール接続（ローカル/リモート） 🔗 URL: 📘 概要 MCP（Model Context Protocol）サーバーを設定すると、外部サービスのツールがOpenCodeの組み込みツールと並んでエージェントから自動的に使えるようになります。ローカル（プロセス起動）とリモート（HTTPエンドポイント）の両方に対応します。 ⚙️ 機能の説明 設定は `opencode.json` の `mcp` ブロックに、サーバーごとの識別子で記述します。 ・ローカル: `type: "local"` とし、`command` に起動コマンドの配列、必要なら `environment` で環境変数を渡します。`timeout`（既定5000ms）も指定可能です。 ・リモート: `type: "remote"` とし、`url` を指定。認証は `headers` でBearerトークンを渡すか、OAuthを利用します（401を検知して自動フローも可能）。 各サーバーは `enabled` で個別にオン/オフできます。MCPツールはサーバー名を接頭辞として現れ、`tools` のワイルドカード（`*` や `?`）で全体・エージェント単位に有効/無効を切り替えられます。 🛠️ 実践的な使い方 リモートのSentry連携は、`opencode.json` の `mcp` 配下に `sentry` を作り、`type: "remote"`・`url: ""`・`headers` のBearer認証・`enabled: true` を書くだけです。 ローカルなら `"command": ["npx", "-y", "@/modelcontextprotocol/server-everything"]` のように起動します。ドキュメント検索の Context7（` Grep（` mcp auth <名前>` や `opencode mcp list` で認証・状態確認も可能です。 💡 ユースケース Sentryで本番エラーをエージェントに調査させ、Context7で最新ライブラリの正しい使い方を引き、Grepで他リポジトリの実装例を探す、といった「調査から実装まで」を1つのセッションで完結できます。普段は `enabled: false` にしておき、必要な作業のときだけ有効化する運用が安全です。 ⚠️ 注意点 MCPサーバーはコンテキストを消費します。多くのツールを公開するサーバー（GitHub系など）を有効にすると、トークンが急増しコンテキスト上限を圧迫しがちです。使うサーバーは絞り、APIキー運用なら `oauth: false` で自動OAuthを抑止しましょう。リモートは `timeout` 超過で起動失敗する点にも注意してください。 #OpenCode# #MCP#

# AIエージェントをソフトウェアに組み込むプラクティス # Risk-based Human Approval｜リスクベース人間承認 🎯 エージェントに「全部お任せ」も「全部確認」も間違いです。操作のリスクに応じて自動実行・人間承認・禁止を動的に振り分けるのが正解です。 🔥 解決する課題 エージェントが外部システムに副作用を持つ操作を実行できるとき、すべてを自動実行すれば不可逆な損害が起きえます。しかしすべてに人間承認を求めれば待ち時間で業務が止まり、エージェントの自動化の価値が消失します。LLMに「危険だと思ったら聞いて」と指示しても、その判断自体が確率的でありすり抜けが起きます。 💡 提案パターン 操作をリスクスコア（不可逆性 x 失敗コスト）で3層に分類します。低リスク（読取・可逆操作）は自動実行、中〜高リスク（不可逆または高コスト）は人間承認を経由、極高リスク（不可逆かつ致命的）は禁止とします。分類はLLMではなく決定論的なルールエンジンで行い、承認タイムアウト後のデフォルトは安全側（自動却下）に倒します。さらに段階的自律性（Autonomy Ladder）により、エージェントの実績に応じて閾値を動的に調整する仕組みも設計できます。 ✅ 選定条件 使うとき： - エージェントが書込・削除・送信など副作用を伴う操作を実行する - 操作によって不可逆性と失敗コストが異なり、一律ポリシーでは過剰か不足になる - 人間がレビューに関与できる運用体制がある 使わないとき： - すべての操作が読取専用で副作用がない - 失敗コストが一律に低くロールバックが容易 - レイテンシ要件が極めて短く人間介在を許容できない ⚠️ 落とし穴 - リスク分類自体をLLMに任せてはいけません。分類は決定論的なコードかポリシーエンジンの責務です - 承認待ちの状態を永続化しないと、プロセス再起動で承認待ち操作が消失します - 条件付き承認（パラメータ修正して実行）を設計に含めないと、却下と再提案のラウンドトリップが増えます 🔧 実装方針 - リスク分類はツール名×アクション名の静的テーブルまたはポリシーエンジンで行い、LLMには委譲しません - リスクスコアは不可逆性（reversibility）と失敗コスト（failure_cost）の積で算出し、閾値で3層（auto/approval/forbidden）に振り分けます - 承認待ち状態は耐久的なストア（キュー＋永続化）に保持し、プロセス再起動で消失しない設計にします - 承認タイムアウト時のデフォルト動作は安全側（自動却下）に倒します - リスクポリシーはYAML等の宣言的設定として外部化し、コード変更なしでルール追加・変更できるようにします #AIエージェント# #ソフトウェアアーキテクチャ#

動画生成AIが物を壁の後ろに隠すと、なぜか別の物になって出てくる。この「物体永続性」の欠陥に真正面から挑んだ研究です。 タイトル: Training Object Permanence in World Models URL: 📝 概要 人間の乳児が生後半年で獲得する「物体永続性」と「物体の固体性」を、動画生成モデルに学習させる取り組みです。150種の合成タスクから150万件の学習データと評価ベンチマークWROPを作り、160億パラメータのモデルPWM-WROPを構築しました。 ❓ 解決する課題 Sora等の動画生成モデルは、物体が遮蔽物の後ろで消えたまま別物として再出現したり、固体の壁を平気で貫通したりします。この欠陥が衝突や因果関係の推論全体を損なっていました。 💡 方法論と提案手法 Blenderで生成した150種のタスクを「遮蔽」「固体性」の6ファミリーに整理し、物体数や軌道などの構造パラメータは体系的に変え、色や照明などの表面パラメータはランダム化することで記憶による解答を防ぎます。これをCosmos3-Nanoにファインチューニングしました。 📊 実験結果 人間による361件のペア比較評価で、PWM-WROPは真の継続生成モデルの中で1位（Elo 1679.5）、次点に224ポイント差をつけました。静的遮蔽タスクでは全モデル中1位を獲得した一方、衝突などの固体性タスクでは苦戦が見られました。 🌍 ユースケース 学習データ・モデル重み・AWS Trainium2向けの学習基盤PWMを公開し、物理的に妥当な世界モデル構築の土台を提供します。 #世界モデル# #動画生成AI#