Y's Digital Garden

Daily News 2025-11-02

27 min read

<< DN 2025-11-01 | DN 2025-11-03 >>

Thread by @MinoDriven - X (formerly Twitter)

ミノ駆動 on X: “神本『ITエンジニアの転職学』を読んだので感想投下。 転職に関係なく仕事の質を高めるために全員読むべし。

◆誰にオススメ？

・転職を成功させたい人。穴が開くほど読むべし。まずはそれからだ。 ・仕事の質を高めたい人。個人的にはむしろこっちの方が重要かも。” / X

google/langextract: A Python library for extracting structured information from unstructured text using LLMs with precise source grounding and interactive visualization. - GitHub

link 🔗

最速でAI Agent機能をPoCするChrome Extensionsの威力 - LayerX エンジニアブログ

link 🔗

  • 既存サービスのコードを変更せずにAI Agentを実サービス画面で検証できる方法として、Chrome Extensionsを中継レイヤーに活用します。
  • 拡張機能からローカルで立ち上げたAI Agent APIへリクエストを送り、画面のDOMを書き換えて結果を即時表示します。
  • 技術スタックの例として、Strands Agents SDK、Amazon Bedrock AgentCore、Knowledge Basesを利用し、Langfuseでトレースを可視化します。
  • Claude Codeに拡張機能の実装や配線を指示し、自分は仕様とアイデア記述に集中することで、開発速度を最大化します。
  • プロジェクトをテンプレート化し、依存・共通処理・ホットリロードを標準装備することで、新規Agentを量産できる体制を整えます。
  • サンプルとして最小のAgent（エントリポイント関数とトレース付与）を用意し、新機能はこの雛形を複製して拡張します。

B2B SaaS における AI Agent 向けの認可に向けた課題 - LayerX エンジニアブログ

link 🔗

  • AIエージェントにはタスク達成に必要な最小権限のみを与えるべきだと説明しています（最小権限の原則）。
  • 1st partyエージェントでは、利用可能なtoolを固定し、HITLで段階的に権限を拡張する設計が有効だと述べています。
  • きめ細かな認可要求に対応するため、Rich Authorization Requests（RFC 9396）など標準仕様の活用を提案しています。
  • エージェント間やユーザーからの委任チェーンを可視化し、必要権限を上流に確認・移譲する流れが重要だと説明しています。
  • Confused Deputy問題を避けるため、実行可否を「ユーザー権限」×「エージェントに許可されたscope」の積集合で判定する方針を示しています。
  • B2Bでは従業員が認可内容を正しく判断しにくく、過剰な許可が生まれやすい課題があると指摘しています。
  • 管理者に中央集権的に認可を移譲する（例：MCPとIdP連携）方向は妥当だが、設定・運用負荷がボトルネックになると述べています。
  • 機能やエージェントの数が増えると、手動の認可設定はスケールしないため、自動化やポリシーテンプレート化が必要だと示唆しています。

身近なAgent・ReAct再入門 - LayerX エンジニアブログ

link 🔗

  • ReActは「推論（Reasoning）」と「行動（Acting）」を往復させる設計であり、曖昧な情報を解釈しながら次の最適な操作を選択できることを説明しました。
  • スマホのGeminiを使ったカレンダー登録の例では、検索→情報抽出→予定作成までを単一指示で完了できることを示しました。
  • 学童保育の出席申請自動化の例では、検索、ブラウザ操作、マルチモーダル認識、長期記憶、Human-in-the-Loopを組み合わせて現実タスクに対応しました。
  • strands-agentsおよびstrands-agents-toolsを用いれば、多くの操作を既存ツールで実現でき、カスタム開発を最小化できることを示しました。
  • Agentが得意な領域は「曖昧な情報の解釈が必要」「状況によって次の動作が変わる」「イレギュラーがある」「入出力がデジタルでアクセス可能」という条件に当てはまるタスクであると整理しました。
  • プログラミングが不要になるのではなく、手順設計とツール選定という“プログラミング的思考”がむしろ重要であると強調しました。

Durable Execution Solutions -

link 🔗

  • Temporalは「Durable Execution（耐久実行）」を提供し、ワークフローの全実行状態を永続化しながら自動で再開できるように設計されています。
  • ビジネスロジックを「Workflow（長寿命で決定的な処理）」として記述し、外部I/Oや失敗しやすい処理は「Activity（自動リトライ・タイムアウト付きの関数）」として分離して実装します。
  • 失敗やプロセス死亡、デプロイ、ノード障害が起きても、ワークフローは直前のステップから再開できるため、手動リカバリや孤児プロセスが発生しません。
  • SDK（複数言語対応）で既存言語のまま実装でき、再送・バックオフ・タイマー・シグナル・タスクキューなどの信頼性機構をサービス側が提供します。
  • 例示コードのように「30日スリープしてメール送信を1年続ける」など、常識的には難しい長時間ジョブが、安全に記述・運用できます。
  • 可観測性が高く、各ワークフロー実行の現在状態や履歴をGUI/ツールで確認でき、ログのつまみ食い調査を減らします。
  • 自前ホスティング（OSS）とマネージドのTemporal Cloudを選べ、いずれもアプリのコードはTemporal側に渡らない設計になっています。
  • コア技術はSQS/SWF、Azure Durable Functions、Uber Cadenceの知見を継承し、長年の本番運用実績があります。
  • オープンソース（MITライセンス）でコミュニティが活発に活動し、大手企業やスタートアップで採用事例が公開されています。

Temporal Workflow で実現する Durable な AI Agent LayerX_AI_Agent_ブログリレー - Zenn

link 🔗

  • AIエージェントの実行は長時間化しやすく、接続切断・障害・一時エラーで中断しやすいため、Durable（中断・再開可能）な実行基盤が必要だと説明しています。
  • Temporalはワークフロー（副作用を持たない制御）とアクティビティ（外部I/Oや副作用を伴う処理）を分離し、状態と進捗をサーバに永続化しながら確実に完遂すると解説しています。
  • Agent Loop（LLM推論→ツール実行→結果を返して継続）をアクティビティとして記録・再開でき、途中失敗やリトライでも二重実行のリスクを抑えられると述べています。
  • Signalなどのメッセージパッシングで、実行中のワークフローに外部から指示やユーザ入力を注入して、文脈を保ったまま処理再開ができると説明しています。
  • conditionやMutexなどで「ユーザ承認を待つ」「並行処理の排他」などHITL（Human-in-the-loop）を堅牢に実装できると述べています。
  • 一時的な状態を「ローカル変数のように」扱える精神モデルが得られ、中間状態の明示的な永続化を最小化できると説明しています。
  • バージョニング機構により、長時間実行中にデプロイや仕様変更があっても安全に移行できると述べています。
  • Durable Executionはチャット以外（ファイル前処理、メール受信、定期実行など）も含むバックグラウンド処理全般で有用だと強調しています。

CopilotKitでアプリをAI化しないか？ - LayerX エンジニアブログ

link 🔗

  • CopilotKitは「アプリ状態の共有（useCopilotReadable）」「アクション実行（useCopilotAction）」「チャット制御（useCopilotChat）」で、LLMとUI・アプリ操作をつなげられると説明しています。
  • 既存アプリにCopilotSidebarを挿すだけで、ストリーミング対応のチャットUIとプロンプト（instructions）を付与できると解説しています。
  • useCopilotReadableでゲーム盤面・手番・勝敗・候補手などの“現在の状態”をAIに常時同期し、文脈に沿った応答を実現できると述べています。
  • useCopilotActionで「positionを受け取り手を打つ」等の安全なアクションを定義し、検証・エラー返却・非同期処理に対応できると紹介しています。
  • useCopilotChatでコード側からAIにメッセージ送信し、ターン移行時の自動指示などを実装できると説明しています。
  • 追加の高度化として、Minimaxアルゴリズムを導入し、難易度（探索深さ）や局面評価を通じて“強いAI”と“戦略の可視化”を実現できると示しています。
  • CopilotKitはAG-UIプロトコル対応で、エージェント実装を抽象化し、将来のエージェント基盤差し替えにも備えられると述べています。

Langfuse の Datasets 機能を利用したAIエージェント機能の性能評価のためのデータセット構築 - LayerX エンジニアブログ

link 🔗

  • AIエージェントの性能評価はオフライン評価とオンライン評価を循環させることが重要だと説明しています。
  • LangfuseのDatasets機能を用いて、入力と期待出力を固定化し、再現性のある評価データを管理できると述べています。
  • Datasetのitemは追記のみで編集不可であり、実験の再現性を担保すると説明しています。
  • 開発初期はLLMで妥当ケースとエッジケースを広く生成し、人が確認して採否を決めるべきだと述べています。
  • 実運用ではユーザーフィードバック（明示的/暗黙的）を起点に「AIが間違えたケース」を抽出し、Datasetへ取り込むべきだと説明しています。
  • LangfuseのScoresでtraceにスコアを付け、間違い例をフィルタしDataset化できると述べています。
  • データセットの分割軸（申請種別、tool単位、顧客単位など）は評価目的に合わせて設計する必要があると説明しています。
  • データセットが実態とかけ離れると誤ったリリース判断につながるため、現場ログを反映した継続的更新が重要だと述べています。
  • 次回はLangfuse Experiment runner SDKで実際の評価実験を行う予定だと予告しています。

Vercel AI SDK + Temporal で Agent Loop を回す LayerX_AI_Agent_ブログリレー - Zenn

link 🔗

  • ツール定義から execute を外して、AI SDKのAgent Loopを「ツール実行直前」で必ず停止するようにしました。
  • ループを自前制御し、LLMの出力メッセージから tool-call を検出して外部で実行し、tool-result に置き換えてメッセージ履歴に反映しました。
  • LLM処理（messages → new messages）とツール実行（tool-call → tool-result）を関数に切り出し、それぞれをTemporalのActivityにしました。
  • Temporal Workflow内で「processLLM → executeToolCall → processLLM …」の反復を行い、失敗時には直前のActivityから再開できるようにしました。
  • Durable化により、ネットワーク障害やLLM呼び出し失敗時も不要な再計算とコスト増を避け、ユーザー体験の遅延悪化を防ぎました。

Building agents with the Claude Agent SDK - @AnthropicAI

link 🔗

  • Claude Code SDKを「Claude Agent SDK」に改名し、コーディング以外の一般業務も対象にしました。
  • 重要な設計原則は「エージェントにコンピュータを与える」ことであり、ファイル操作・bash・コード実行・外部API接続を可能にします。
  • エージェントは「文脈収集→行動→検証→反復」のループで動作し、長時間実行時はコンパクションで文脈を要約して維持します。
  • 文脈収集では、ファイルシステム検索やサブエージェントの並列化を活用し、まずはエージェント的検索を優先し、必要に応じてセマンティック検索を追加します。
  • 行動フェーズでは、頻出の主動作を「ツール」として明示し、bashやスクリプトで柔軟性を補い、コード生成で再利用可能な処理を確実に実行します。
  • MCP（Model Context Protocol）によりSlack・GitHub・Google Drive・Asanaなど外部サービス連携を標準化し、認証やAPI呼び出しを簡素化します。
  • 検証フェーズでは、ルール定義（lintや型検査、バリデーション）、ビジュアル検証（スクリーンショット）、必要に応じた「LLMによる審査」を組み合わせて信頼性を高めます。
  • 改善は失敗例の精査から着手し、ツール設計の見直し、フォールトルールの追加、探索APIの構造化、代表的な評価セット（eval）の構築で継続的に強化します。
  • 代表例として「メールエージェント」を題材に、会話履歴の検索、添付の解析、受信時ルールのコード化、Slack/Asana連携などを示しました。

身近なAgent #2: ブラウザ操作を実現する - LayerX エンジニアブログ

link 🔗

  • 一般ユーザーを想定する場合、セットアップ容易性とセキュリティ、セッション管理を最優先で検討する必要があります。
  • ブックマークレットは導入が簡単ですが、ページ遷移でリセットされやすく常用に向きません。
  • ブラウザ拡張は自動起動や権限付与で自由度が高く、認証情報をローカルに保持できるため現実解に近いものの、審査と権限設計が課題になります。
  • インストール型アプリは隔離性や安定動作に優れますが、配布・更新・運用のコストが大きく個人利用には重くなりがちです。
  • サーバサイドブラウザは配布不要で強力ですが、ユーザーのセッション情報をサーバ側で扱うためリスクが高く、ログイン不要ページに適します。
  • CloudflareのBrowser RenderingやPlaywright MCPは便利ですが、公開URL運用は避け、Service bindingsなどで閉域化して安全に利用する必要があります。
  • 著者は拡張経由で他タブを開きナビゲーション等を行うPoCを進行中で、AI SDKのツール連携とWebSocketでエージェント実行を組み込む構成を目指しています。

AI Agent時代における「使えば使うほど賢くなるAI機能」の開発 - LayerX エンジニアブログ

link 🔗

  • LLM時代のパーソナライゼーションは、モデルを頻繁に再学習せず、コンテキスト設計とプロンプト最適化で実現すると説明しています。
  • ユーザの業務ルールや履歴を動的にプロンプトへ織り込む「Context Engineering」が中心手法であると指摘しています。
  • プロンプト自動最適化は、種プロンプト、評価とフィードバック、候補生成、選別、反復深さのフレームで整理できると紹介しています。
  • LLMを評価器に用いる LLM-as-a-Judge や TextGrad により、定量化しづらい基準（簡潔さ、正確さ）も最適化対象にできると述べています。
  • 最低限「出力の受容・拒否」を取得し、可能ならテキストコメントや行動ログも合わせて収集する設計が不可欠だと強調しています。
  • 単一プロンプト最適化の限界に対し、AFlow やプログラム進化系によりワークフロー全体を自動生成・改善する流れを示しています。
  • 実装面では DSPy を用いると、Signature/Moduleで推論を記述し、Few-shotやInstructionを Optimizer で自動探索できると解説しています。
  • 経費精算の承認判定タスクで、DSPy最適化により正解率を約88%→約93%へ改善できたと報告しています（MIPROv2が最良）。
  • Instruction最適化は、役割・評価観点・思考過程の明示化で堅牢さが増すと具体例で示しています。
  • 局所解に陥るリスクと学習コストを踏まえ、局所的なパーソナライズに活用し、運用で評価・最適化ループを継続することが現実解だと述べています。

Test AI-powered apps in TypeScript - Evalite

link 🔗

Evaliteによるlocal nativeなLLM evals実行環境 - LayerX エンジニアブログ

link 🔗

  • EvaliteはTypeScript製のOSSで、Vitestを基盤にローカルでLLM evalsを高速に実行できます。
  • 評価は「data（入力/期待値）」「task（LLMコールなど実処理）」「scorers（採点）」の3点を定義して構成します。
  • LLM as Judgeも利用でき、autoevalsなど既存のジャッジ関数も組み込めます。
  • pnpm evalite serveでターミナル結果とローカルWeb UI（localhost:3006）に履歴や入出力詳細を可視化します。
  • SQLiteにローカル保存するため、外部SaaSなしで完結し、セットアップが軽量です。
  • evalite.skipやデータ項目のonly: true、並列/反復回数設定でエッジケースに集中した高速イテレーションが可能です。
  • Variant Comparisonでモデルやプロンプト、スコアラーの横比較を簡単に行い、Judgerの安全な切替検証を進められます。
  • データセットをソースコードとして管理でき、PRでプロンプト変更と評価変更を同時レビューできます。
  • CIで実行し、静的HTMLレポートにエクスポートできるため、レビュー時に結果を共有できます。
  • 便利さの一方で、トレース可視化がシンプル、Vitestの柔軟な実行スタイルを完全には踏襲していない点に改善余地があります。

Greptile と Claude Code でつくるコードレビュー改善 AI Agent - LayerX エンジニアブログ

link 🔗

  • 問い合わせ→原因調査→修正PRの知見を、Greptileのカスタムコンテキスト（ルール）として再利用できるようにしました
  • Claude CodeのAgent SkillsとMCPサーバ（Notion/Greptile/gh）を組み合わせ、ルール生成～登録までを半自動化しました
  • AskUserQuestionで人間の承認を必須にし、ノイズの多いルール登録を防ぐHuman-in-the-loopを実現しました
  • Greptileはグラフベースでコードベースを理解し、人間のフィードバックで学習するため、曖昧なレビュー観点にも強みがあります
  • 生成するルールは具体事象に寄り過ぎないよう一般化し、リンクや事例詳細は含めずレビューに有効な指針に限定しました
  • Claude Agent SDKへ容易に移行でき、Slackなど外部UIからの運用にも拡張可能です

AI Agentのビジネス価値を計るバックテスト基盤の構築 - LayerX エンジニアブログ

link 🔗

  • AI Agent導入のボトルネックは評価であり、過去データで再現検証するバックテストが事業価値の可視化に直結すると説明しました
  • 既存APIは最新データ前提なため、そのままでは過去状態を再現できず、API改修は広範囲で重いと指摘しました
  • GORMプラグイン「Firn」でgorm.DBを差し替えるだけで、SQLをLLMでSnowflakeのスナップショット参照SQLに自動変換する方式を採用しました
  • これによりAPI内部のロジックやパラメータ分岐を保ったまま、過去時点のデータを返せるようにしました
  • SQLパーサーによる決定論的変換は複雑化したため、小規模LLMでのSQL2SQL変換＋ガードレールで現実解に落とし込みました
  • GORM v1→v2移行の検証には「gormgolden」でSQLゴールデンテストを導入し、移行の安全性を担保しました
  • バックテスト基盤から得たプラクティスとして、エージェント用のworkflow tool設計と、過去データにアクセスできる前提のデータ設計（CDC/データロード）を推奨しました
  • ユースケースにより、全CDC常時保存か、評価に必要なデータのみオンデマンドでアプリDBにロードする方式を選ぶべきだと整理しました

Thread by @minorun365 - X (formerly Twitter)

みのるん☁️ Minoru Onda on X: “コーディングエージェントなどを「使う」側の話はそろそろ飽きたでしょ？

モデルやクラウドのベンダー問わず、AIエージェントを「作る」側の知見をみんなで共有しようぜ🔥 https://t.co/pcmuljLggD” / X

Thread by @iwashi86 - X (formerly Twitter)

iwashi / Yoshimasa Iwase on X: “Claude Code をプライベートと仕事の両方でガッツリ使っている方の記事。

・CLAUDE.mdファイルは、リポジトリのルールを定義する最も重要な「憲法」 ・仕事用のCLAUDE.mdは厳格に管理され、リポジトリの主要なツールやAPIのみを簡潔に文書化しておく” / X

How EJAE and Mark Sonnenblick Created “Golden” From KPop Demon Hunters | Vanity Fair - YouTube

How EJAE and Mark Sonnenblick Created “Golden” From KPop Demon Hunters | Vanity Fair

Graph View

Backlinks