langchainテックブログの品質と頻度は本当にすごい。 ライブラリへの批判は多々あれども、テックで自社プロダクトを広めるだけでなく、知見を共有するこの行動力は尊敬しかない。

TL;DR LangChainが自社の有料広告運用を任せるエージェントを構築した実践記録です。「エージェントを知識労働者として扱う」設計で、6ヶ月でパイプライン寄与度を0%から20%まで伸ばしました。 タイトル: How We Built LangChain's Paid Media Agent URL: ポイント 🖥️ Deep Agents＋隔離マイクロVM上のサンドボックスで、人間のアナリストと同じ装備をエージェントに与えています 📚 システムプロンプト・スキル・社内ウィキ・218個のライブツール・決定論的コードの5層でコンテキストを構成しています 🧮 「判断はモデル、計算はコード」の原則に切り替え、レポート生成のトークンコストを40分の1に削減しました 🔍 218個あるツール定義を全部読み込ませず、必要なものだけ動的に検索・読込する方式でトークンを4分の1に抑えています 🧩 親エージェント＋プラットフォームごとのサブエージェントに分離し、失敗の影響範囲を明確に隔離しています ✅ Slack上のBlock Kit承認カードで、提案内容を確認・編集・承認してから実行する経路を作っています 📈 CPL（獲得単価）は3ヶ月で30%低下、広告支出は約60%増加という成果を出しています 社内業務エージェントの設計原則として、他のドメインにもそのまま転用できそうな内容だと感じました。 #AIエージェント# #マーケティング#

長時間動くAIエージェントが抱える「コンテキストの腐敗」問題に、LangChainが5つの具体的な処方箋を示しました。 タイトル: Context Engineering with Deep Agents: How To Remember Without Keeping Everything In Context URL: 🧩 解決する課題 エージェントが指示・ツール結果・ファイルを蓄積し続けると、やがてコンテキストウィンドウの容量を超え、推論の精度が落ちてしまいます。情報過多で以前の知識が薄れる、人間の記憶にも似た現象です。 💡 5つの手法 オフロード（大きな結果をファイルシステムに退避）、サマライゼーション（古いメッセージを要約しファイルに保存）、スキル（必要な時だけ完全な指示を読み込む段階的開示）、サブエージェント（ノイズの多い作業を隔離されたコンテキストに任せる）、長期記憶（markdownファイルでセッションを越えて学習内容を保持）という5つの補完的な技術で、情報を「捨てずに」管理します。 🔧 テクニカルな特徴 これらはすべてエージェントループにフックされた「ミドルウェア」として実装されており、約2万トークンを超える結果や5万トークンを超えるユーザーメッセージを自動的にファイルへオフロードします。記憶はユーザーが管理するプレーンファイルとして存在するため、モデルプロバイダーを切り替えても学習内容を保てます。 📊 ユースケース 5社の競合分析レポートを作る「市場調査エージェント」の例では、蓄積される生データや検索結果、ドラフトの反復版が、最終レポート作成時の推論品質を落とさないようにコンテキストエンジニアリングで守られています。 #AIエージェント# #コンテキストエンジニアリング#

長時間動くAIエージェントが抱える「コンテキストの腐敗」問題に、LangChainが5つの具体的な処方箋を示しました。 タイトル: Context Engineering with Deep Agents: How To Remember Without Keeping Everything In Context URL: 🧩 解決する課題 エージェントが指示・ツール結果・ファイルを蓄積し続けると、やがてコンテキストウィンドウの容量を超え、推論の精度が落ちてしまいます。情報過多で以前の知識が薄れる、人間の記憶にも似た現象です。 💡 5つの手法 オフロード（大きな結果をファイルシステムに退避）、サマライゼーション（古いメッセージを要約しファイルに保存）、スキル（必要な時だけ完全な指示を読み込む段階的開示）、サブエージェント（ノイズの多い作業を隔離されたコンテキストに任せる）、長期記憶（markdownファイルでセッションを越えて学習内容を保持）という5つの補完的な技術で、情報を「捨てずに」管理します。 🔧 テクニカルな特徴 これらはすべてエージェントループにフックされた「ミドルウェア」として実装されており、約2万トークンを超える結果や5万トークンを超えるユーザーメッセージを自動的にファイルへオフロードします。記憶はユーザーが管理するプレーンファイルとして存在するため、モデルプロバイダーを切り替えても学習内容を保てます。 📊 ユースケース 5社の競合分析レポートを作る「市場調査エージェント」の例では、蓄積される生データや検索結果、ドラフトの反復版が、最終レポート作成時の推論品質を落とさないようにコンテキストエンジニアリングで守られています。 #AIエージェント# #コンテキストエンジニアリング#

エージェントの評価を自動化しても、「なぜ失敗したか」は人が見ないと分からない。LangChainは、専門家の判断こそが戦略的な強みだと説きます🧑‍⚖️ Why human insight is a strategic advantage for building better agents 自動評価は問題を検知できても、原因や直し方までは説明できません。そこで人間のレビューを評価の仕組みに組み込む3つの原則が示されています。 🎯 原則1: 人間が「良い」を定義する トレースにない文脈、つまりその仕事での良さの基準やユーザーの狙いを、レビュアーが与えます。理由付きのスコアは、評価器自体の抜けも明らかにします。 🧵 原則2: 文脈が判断を支える 1ステップだけ見ると、数ターン前の発言との矛盾を見落とします。マルチターンでは会話全体（Thread）をレビューの単位にします。 🔁 原則3: 判断を評価データに変える ラベルはグラウンドトゥルースとなり、LLMジャッジを人間のスコアに揃え、オンライン評価器を更新し、ゴールデンデータセットを作る元になります。事例では、Fetch Rewardsが商品カードの画像やオファーの有効性まで人手で確認しています。 自動化は規模を担い、専門家の判断を再利用可能な資産にすることが優位性になる、という主張です。 #AIエージェント# #LLM評価#

TL;DR：「エージェント開発の難問は解決済み」という見方に、LangChainのHarrison Chaseが異を唱えています。常時稼働でゴールを追うエージェントには、6つの未解決課題があるそうです。 New context engineering challenges in late 2026 ポイント ・🔔 プロアクティブさ：役立つ通知と、うるさい通知のバランスが未解決 ・🧠 メモリ：難しいのは保存ではなく「何を覚えるか」を決める知能層 ・⏳ 非同期：長い作業を走らせつつ、メインのエージェントは応答し続ける必要がある ・🎯 ゴール追跡：同じ行動の繰り返しを避け、長期で一貫して進める ・⚠️ 仕様ゲーミング：「全バグを消せ」でコードベースごと消す例 ・🌐 ブラウザ：スクリーンショットかDOMか、両方が大きいときのコンテキスト管理 要約、オフロード、スキル、サブエージェントといった既知の技法の「次」を整理した論点集です。数値や解決策はなく、意見記事である点にご注意ください。 #ContextEngineering# #AIAgents#

TL;DR: 長い仕事を裏で進めながら、ユーザーの指示にはすぐ応える。LangChainはその両立に、バックグラウンドで動く非同期サブエージェントを提案しています。標準のReActループでは長いツール呼び出しが全体を止めてしまうためです。 Agents Are Going Async（LangChain） ポイント ・🧠 応答性（すぐ反応）と生産性（多数の長いタスクを並行）の両立が課題です ・🚧 ReActループでは、長いツール呼び出し1つで他のタスクが全部待たされます ・🔀 ユーザーのそばに残る1つのオーケストレーターと、裏で動く複数のワーカーという構成です ・🛠️ 管理ツールは5つで、start、check、update、cancel、list の各 async_task です ・♻️ 追加指示は、訂正向きの interrupt（既定）と、追加向きの enqueue を選べます ・🔔 結果は、実行中なら次のモデル呼び出し前に拾い、待機中なら新しい実行で起こします ・🧪 Deep Agents と Managed Deep Agents で利用でき、ベータ版です 記事にベンチマークはなく、LangChain製品の紹介である点に注意が必要ですが、設計の考え方として参考になります。 #AIエージェント# #LangChain#

エージェントのメモリは、検索を足すより「根拠までたどれる構造」を作るほうが効くのかもしれません🧠 Building Evidence-Grounded Agent Memory with OpenWiki and Graphs LangChainのブログでは、文書をコンパイルしたWiki(OpenWiki)と、その引用から作るエビデンスグラフを組み合わせ、複数文書にまたがる質問への精度を上げています。 注目ポイントは3つです。 📚 原文にハッシュで紐づくWiki Wikiの各記述は根拠となる原文の行とそのハッシュに結びつきます。原文が変わるとモデルを呼ばずに該当クレームにフラグが立ち、そこだけをモデルが見直すため、メモリが自己修正できます。 🔗 引用から作る型付きエッジ cite、supersede、refers_toなどのエッジを、既存の引用や文書内の参照から追加のモデル呼び出しなしで作ります。agentはlocateで起点を見つけ、expandでたどるだけです。グラフの構築は1秒未満でした。 📊 連結質問で精度が約5倍 保険文書111本の合成コーパスで、連結質問の精度は検索の0.10からWikiの0.52へ上がりました。エビデンスグラフを足すと精度は27%向上し、コストは58%下がりました。一方、単純な参照では検索と差がありませんでした。 メモリは、複数ソースにまたがる質問を繰り返す場面で効く、という整理が参考になります。 #AIエージェント# #エージェントメモリ#

AIに「ブランドらしさ」を教えるには、何が必要なのでしょうか？ タイトル: How We Built Our Design Agent URL: ❓ 何を作ったの？ LangChainが社内用に作った、Slack上のデザインエージェント「Content Studio」です。依頼すると、スライド、動画、図などブランドに沿った成果物が、すべてコードで返ってきます。 ❓ なぜ普通のAIではだめ？ 視点を与えないと、AIは見慣れたパターンに収束してしまうからです。そこで48のスキル、共有Wiki、決定的なコード検査、メモリに「センス」を分けて持たせ、ジョブから学ぶループも2つ回しています。 ❓ 成果は？ ・3,000超のアセット、80超のスライドデッキを納品 ・依頼の3/4はマーケ外から、75%が毎週利用 ・中央値の依頼は約0.50ドル（9月中旬は約8ドル） ・社内コードはManaged Deep Agentsへの移行で約80%縮小 ❓ 一番の学びは？ モデルの弱さを補うために積んだ115のコンポーネントとルールは、Opus 5.5の登場後ほとんど外し、デザイン原則だけ残すと多様性が改善しました。弱さを補うルールは、モデルの進歩で価値を失います。 #AIエージェント# #LangChain#

社内で共有するAIエージェントを作るとき、どこでつまずくのでしょうか。LangChainが3つの社内エージェントで見つけた答えをまとめました🧩 The five components of building a "company harness" ❓ そもそも「company harness」とは？ 💡 営業・エンジニアリング・マーケティングの全員が共有するエージェント層のことです。共有チャンネル、ユーザーごとの権限、メモリ、安全なコード実行、頼まれなくても動く処理を扱う必要があります。 ❓ 一番厄介なのは何ですか？ 💡 アイデンティティ、つまり「誰として動くか」です。呼び出したユーザーとして動くOBOと、共有の固定資格情報があり、どちらかではなくツールごとに使い分けます。例えばOpenSWEは、ユーザー起点ならそのGitHubハンドル、コードレビューなどのバックグラウンドでは自前のGitHub appとして動きます。 ❓ 他の要素は？ 💡 ・体験: Slackに常駐し、向かない作業だけカスタムUIに ・メモリ: 全員向けのグローバルとユーザー別の2階層 ・コード実行: サンドボックスとシークレットプロキシで、資格情報を見せずに外部サービスへ接続 ❓ ユーザーが頼まなくても動くのですか？ 💡 はい。OpenSWEは新規PRを検知して自動レビューし、GTM Agentはユーザーに頼まれたデイリーブリーフのために自分でcronを作ります。こうしたアンビエントな実行が、活動の大きな割合を占めるそうです。 #AIエージェント# #LangChain#