# 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的に整理しました。

リアルタイムデータ連携は耳触りの良さと「何となく必要そう」感に比して、真面目に実装するとインフラやロジック、コスト含めて大変なんですよね。 反面、ROI的に本当にリアルタイムデータが必要なユースケースもあまり多くない。 もちろんビジネス的合理性があれば頑張って構築するのだけど。

SWEエージェントを全タスク一括で強化学習すると、あるカテゴリが伸びる裏で別のカテゴリがこっそり劣化する。そんな「シーソー問題」に切り込んだ研究です。 タイトル: One to More, More to One: Category-Aware Iterative Expert Training for Software Engineering Agents URL: ❓ カテゴリのシーソー問題とは何ですか？ 全タスクをプールして単一ポリシーでRL学習すると、全体スコアは上がって見えても、実は特定のカテゴリだけが犠牲になっていることがあります。全体指標だけではこの綱引きが見えません。 ❓ どうやって解決するのですか？ タスクをエビデンスに基づく分類体系でカテゴリ分けし、カテゴリごとに専門のエキスパートモデルを育てます。育成にはRefresh（再評価）・Repair（成功例で修復）・Expand（学習対象を拡張）を繰り返すRREループを使います。 ❓ 複数のエキスパートはどう1つにまとめるのですか？ ラベルルーティング型のマルチ教師オンポリシー蒸留（MOPD）で、タスクのラベルに応じて適切なエキスパートの知識だけを生徒モデルに転送し、単一のデプロイ可能なモデルに統合します。 ❓ 効果はどれくらいありますか？ Pro-618で58.04%（ベース比+5.39ポイント）、SWE-bench Multilingualで59.00%（+2.78ポイント）を達成し、カテゴリ間の性能もより均衡しました。 #SWEエージェント# #強化学習#

TL;DR: GPUなしのCPUやタブレットでも動く、1億4,430万パラメータの軽量な意思決定モデルが登場しました。 タイトル: Introducing Julia 1 URL: ポイント 🧠 分類・ランキング・Yes/No判定を1つのモデルでこなす、多言語エンコーダmmBERT-small土台の意思決定特化モデル 💰 学習コストはクラウドGPU利用料でわずか約104ドル（R$540）。ゼロからの事前学習ではなく既存基盤を活用 📱 Apple M4 Macでは1秒あたり28件、バッチ処理なら51件を処理。Androidタブレットでも実用速度 📊 AG Newsは94%、DAIR Emotionは86%（参照ベースライン48%を大幅上回る）と好成績 ⚠️ 類似カテゴリが72種あるBanking77では64%にとどまり、参照ベースライン87%に届かず 🔓 Hugging FaceでApache 2.0ライセンス公開。API提供も予定（入力100万トークンあたり0.025ドル） 小さなモデルでも意思決定タスクに特化すれば実用域に届くことを示した好例だと思います。 #軽量LLM# #エッジAI#

自分のタイムラインは猫を見すぎたおかげで常に猫と動物（あとAI関連）にまみれている。 勝手にパーソナライズしてくれるSNSは自分の見たいもので揃える。

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ベンチマーク#

転職を繰り返してると、早々に信頼を得るために成果を出す方法が身に付いていくのですよね。 自分もだいたい、得意領域で2,3日以内になにか目に見えるアウトカムを出すことを目指す。 長年エンジニアをやってると変なとこの見つけ方や直し方はわかってくるし、入社早々にPRを作って損することはない。

もし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#

エージェントのメモリ管理、毎回LLMに聞きに行っていませんか？その無駄を「速い脳」と「遅い脳」で切り分けた研究です。 タイトル: Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents URL: 人間の二重過程理論（System One / System Two）にヒントを得て、メモリ操作の大半を軽量な構造化判断で処理し、複雑な推論だけをLLMに残すアーキテクチャです。注目ポイントを3つ紹介します。 🧠 System-Oneによる型付き制御 種別判定・関係判定・クエリルーティングといった頻出操作を、自由形式のテキストではなく確率やラベルを返す軽量インターフェースで処理。メモリ構築と検索の両方を同じ仕組みで統治します。 🕸️ 4種の関係を持つマルチリレーショナルグラフ 意味・時間・因果・エンティティという4つの視点でメモリをグラフ化し、クエリごとに関連度の高いビューへ予算を配分して探索することで、無駄な探索を避けます。 📊 精度と速度の同時改善 LoCoMoベンチマークで総合スコア0.777とベースライン比11%向上。メモリ構築は158秒で最速ベースライン比6.6倍高速、クエリ応答も0.93秒で36.7%短縮しました。 制御と推論を分離するという発想が、精度と効率を両立させた点に意義を感じます。 #AIエージェント# #メモリアーキテクチャ#

AIを導入したのに成果が出ないのはなぜか。 タスクは80%短縮、しかし企業の生産性は0.3%。 なぜ「採用」には効いても「適応」には届かないのか。 『AI活用のROIと「自由」という経営選択 〜利便性を思考へ〜』というブログを投稿しました。

9ターンの会話が60個のメッセージに膨らむエージェントセッション、どこで問題が起きたか一目で追えますか？ タイトル: Trajectories now in LangSmith: A readable view of every agent session URL: LangSmithに、スレッド内の全メッセージを時系列に並べ直して読みやすく見せる新機能「Trajectories」が追加されました。 注目ポイント 🔍 ネスト構造をなくした時系列ビュー サブエージェントへのハンドオフやツール呼び出し、リトライを含む複雑な実行トレースを、human・AI・toolのメッセージだけを時系列に並べた1本の流れとして提示します。ツールの無駄な再呼び出しなど、問題箇所を素早く発見できます。 👥 非エンジニアもレビューできるSME向け設計 医療の臨床問診エージェントや金融のコンプライアンス対応、サポートのエスカレーション判断などを、技術的なトレースを読まずに専門家がアノテーションキューでレビューできます。 🎓 ポストトレーニングデータとしての活用 高品質なトラジェクトリをそのまま教師ありファインチューニング用データとしてエクスポートでき、システムプロンプトからツール呼び出しまで本番の挙動をまるごと学習データ化できます。 エージェントのデバッグを、エンジニアだけでなく組織全体で担える民主化への一歩だと感じます。 #LangSmith# #AIエージェント#

本番で貯まったエージェントのログ、ただ眺めて終わっていませんか？そのデータを専用モデルに変える仕組みがLangSmithに加わりました。 タイトル: Introducing LangSmith Fine-Tuning URL: ❓ LangSmith Fine-Tuningとは何ですか？ 本番のエージェント実行トレースを、独自インフラを組まずにファインチューニング済みモデルへ変換する `smithtune` CLIです。データセット作成・学習・評価・デプロイの4段階を一気通貫で扱えます。 ❓ どうやって学習データを作るのですか？ LangSmithプロジェクトからメッセージやツール呼び出しの時系列（トラジェクトリ）を取得し、マルチエージェントのレビューでカスタムルーブリックに沿った高品質な事例だけを選別します。ツールの利用可能状態まで含めた正確な文脈を保存するのがポイントです。 ❓ 学習やデプロイはどう進めますか？ LoRAによる教師ありファインチューニング（SFT）をFireworksやBasetenと連携して実行するため、GPUの用意は不要です。ベースモデルとの比較評価を経て、`smithtune deploy` でそのまま本番投入できます。 ❓ 効果はどれくらいありますか？ 問題検知タスクではKimi K3がSFTでスコア90.0から96.0に向上。コードレビューでは同等以上の品質を保ちつつ、モデル呼び出しを29.8%、ツールリクエストを29.4%削減できました。 #LangSmith# #ファインチューニング#

エージェントの不具合を「本番で気づく」から「デプロイ前に潰す」へ。LangSmithが新機能を発表しました。 タイトル: LangSmith Engine v2: Red Teaming and Automated Testing URL: 📝 概要 LangSmith Engineは問題の自動検知と修正生成を行うツールで、5月のローンチ以来7,000万件超のトレースを解析してきました。v2では「レッドチーミング」と「修正の自動検証」という2つの新機能が加わります。 ❓ 解決する課題 これまで開発者は、未検証の修正をそのままデプロイするか、手動検証に時間をかけるかの二択を迫られていました。レイテンシ増加や非効率な実行パスといった微妙な劣化も、人のレビューでは見落とされがちでした。 💡 方法論と提案手法 Engineは本番トレースとリポジトリを解析してエージェントの挙動を理解し、ハルシネーションやプロンプト違反を本番投入前に体系的にテストします。さらに、失敗をサンドボックスで再現して修正案を生成し、元の失敗ケースで反復的に検証した上で、通過した解決策だけを人間のレビューに回します。 📊 実験結果 ・問題検知能力がIssueBenchで2倍以上改善 ・生成される修正案の有効性がTerminal-Bench相当の指標で25%向上 🌍 ユースケース LangSmith PlusおよびEnterprise SaaSユーザー向けに提供開始、セルフホスト対応も近日予定。Deploymentユーザー向けにはプライベートベータで提供中です。 #LangSmith# #AIエージェント#

AIの進化はすごいのに、なぜ経済効果がなかなか統計に表れてこないのか。その理由を「速度のズレ」から解き明かすレポートです。 タイトル: The AI economy: Interconnected forces, feedback loops and speeds of change URL: ❓ なぜAIの効果はすぐに経済統計へ表れないの？ AIの「能力」はタスク遂行時間の目安で2023年以降ほぼ4か月ごとに倍増する猛スピードで伸びていますが、データセンターなどの物理インフラは年15%程度としか広がらず、組織の働き方の再設計にはさらに長い年月がかかります。蒸気機関は経済成長への効果がピークに達するまで約100年、電気は約40年、コンピュータ・インターネットは約25年かかった歴史があり、AIがこの周期をどこまで縮められるかはまだ分かりません。 ❓ ボトルネックはどこで起きているの？ 2023年にはNVIDIA H100のパッケージング能力が不足し、納期が最大11か月に伸びました。今はそれが電力とデータセンター用地に移り、2026年第1四半期だけで75件・約1,300億ドル相当のデータセンター計画が地域住民の反対で凍結・延期されています。次に顕在化しやすいのは、アプリケーションや人材スキル、組織のワークフローだといいます。 ❓ 導入は進んでいるのに、なぜ成果に結びつかない組織が多いの？ 2026年時点で組織の89%が何らかの業務でAIを利用していますが、パイロットの域を超えて本格導入した組織は46%にとどまり、ワークフローをAI前提で再設計できている「ハイパフォーマー」はわずか6%です。責任の所在がIT・法務・人事・リスクなどに分散し、誰も統括していないことが一因とされています。 💡 私たちは何に備えればいいの？ 著者らは、経営者には「効率化を超えて新しい事業を作る」視点を、投資家には「システム内のボトルネックを追う」視点を、政策担当者には「制約の変化に合わせて機動的に規制を調整する」姿勢を、個人には「AIリテラシーを高めつつ人にしかできない判断力を磨く」ことを提言しています。 システム全体を俯瞰する視点の重要性を、あらためて感じさせる内容だと思います。 #AI経済# #システム思考#