Fragments of verbose memory

冗長な記憶の断片 - Web技術のメモをほぼ毎日更新

Feb 27, 2026 - 日記

OpenFangのHands: チャットを待たずに働くエージェントの設計

OpenFangのHands: チャットを待たずに働くエージェントの設計 cover image

先日、OpenFang というオープンソースのAgent Operating Systemを見つけました。「Agent OS」という言葉自体は目新しくないのですが、OpenFangの設計には「Hands(ハンズ)」という独特のコンセプトがあります。

従来のAIエージェントは「ユーザーがメッセージを送るまで待機する」のが基本ですが、Handsは「スケジュールで自律的に動作し、結果をダッシュボードに報告する」という設計です。この違いは小さく見えて、実は運用上の大きな転換点だと思います。

本記事では、OpenFangのHandsという設計思想を、既存のエージェントフレームワーク(OpenClaw 、CrewAI、LangGraph等)との比較を交えながら解説します。

Feb 26, 2026 - 日記

ERC-8004 + ERC-8128 = SIWA: AIエージェント認証スタックの2層構造を解剖する

ERC-8004 + ERC-8128 = SIWA: AIエージェント認証スタックの2層構造を解剖する cover image

前回の記事 で、ERC-8004 (Trustless Agents)がAIエージェントの「信頼の発見」をどう解決するかを見ました。Identity Registry、Reputation Registry、Validation Registryの3層で「このエージェントを信頼していいか」を判断できる、という話でした。

ただ、読んでいて気になっていた問題が一つ残っていました。「信頼できるエージェントだとわかった。でも、届いたHTTPリクエストが本当にそのエージェントから来たものかどうか、どうやって確認するの?」という問いです。

ERC-8128 (Signed HTTP Requests with Ethereum)は、その問いへの答えです。2026年1月に公開されたドラフトで、EthereumアカウントでHTTPリクエストに署名する標準を定義しています。

Feb 25, 2026 - 日記

OpenClawのデバイス認証を読み解く: nonce署名・トークンローテーション・5分タイムアウトの設計意図

OpenClawのデバイス認証を読み解く: nonce署名・トークンローテーション・5分タイムアウトの設計意図 cover image

OpenClaw を初めてセットアップしたとき、ちょっとした違和感を覚えました。通常のWebサービスなら当たり前にある「パスワード登録」や「アカウント作成」がないんです。

「認証どうなってるんだ?」と気になってドキュメントを読み始めたら、Dashboard UIとGatewayのペアリング機構が思いのほか面白い設計になっていました。Challenge-Response認証、デバイストークンのローテーション、5分間のタイムアウトなど、細かい設計判断が積み重なっていて、「ローカル優先だけどセキュアに」という思想が一貫しています。

本記事では、OpenClawのGateway Protocolを読み解きながら、これらの設計がどう組み合わさって「信頼」を構築しているかを解説します。

Feb 24, 2026 - 日記

Tokioランタイムがデータベースプロキシを変える: PgDogのベンチマークから見るRust非同期I/Oの実力

pgdog-rust-tokio-async-benchmark cover image

PostgreSQLのコネクションプーラーとして長年使われてきたPgBouncer 。しかし、50接続を超えると性能が頭打ちになる問題をご存知でしょうか。

この課題を解決するために登場したのが、Rust製の新しいデータベースプロキシPgDog です。PgBouncerと比較して、50接続以上の環境で約10%高速に動作します。

本記事では、PgDogの公式ベンチマーク結果を元に、Rust/Tokioの非同期I/Oアーキテクチャがデータベースプロキシにもたらす性能向上を解説します。

Feb 22, 2026 - 日記

AIエージェントのメモリは「覚える」だけでは足りない: Mengramが実装した手順進化の仕組み

AIエージェントのメモリは「覚える」だけでは足りない: Mengramが実装した手順進化の仕組み cover image

AI エージェントに「前回のデプロイ手順を覚えておいて」と頼んでも、次回また同じ失敗を繰り返す——そんな経験はありませんか?

従来のAIメモリツールは「事実を記憶する」ことに特化していますが、Mengram は一歩進んで「失敗から学習して手順を自動進化させる」仕組みを実装しました。本記事では、Mengramの3層メモリ設計と、他のメモリツール(Mem0、Letta、Zep)との違いを解説します。

Feb 21, 2026 - 日記

AIエージェント時代のHITL設計: EIP-7702で実現する都度承認と強制ルールの二重ガード

AIエージェント時代のHITL設計: EIP-7702で実現する都度承認と強制ルールの二重ガード cover image

AIエージェント がトランザクションを組み立てる時代、一番怖いのは「変なtxを作られること」です。

説明文は正しそうに見えるのに、実際の実行内容が全く違う。こういう事故を前提に設計する必要があります。

本記事の結論は、AI時代のHITLは『都度承認 + delegate強制ルール』の二重ガードで設計するです。

Feb 20, 2026 - 日記

ZeroClawのtrait駆動設計: AIエージェントで「swap anything」を実現する方法

ZeroClawのtrait駆動設計: AIエージェントで「swap anything」を実現する方法 cover image

AIエージェントを本番運用する際、「LLMプロバイダーを切り替えたい」「チャットツールを変更したい」といった要求は頻繁に発生します。しかし、多くのフレームワークでは、こうした変更にコード修正が必要です。

ZeroClaw は、この問題を「trait駆動設計」で解決しています。設定ファイル1行の変更だけで、LLMプロバイダー、チャットツール、メモリバックエンド、実行環境を切り替えられます。本記事では、Rustの「trait」という仕組みを使った、この柔軟なアーキテクチャを解説します。

Feb 19, 2026 - 日記

CLIの出力設計を間違えると、AIエージェントは何も読めない: agent-execが採用した分離戦略

CLIの出力設計を間違えると、AIエージェントは何も読めない: agent-execが採用した分離戦略 cover image

AIエージェント に長時間コマンドを実行させたい。でも、既存のCLIツールは「人間が端末で見る」前提で設計されているため、エージェントが出力をパースできません。

原因は単純です。多くのCLIが「結果」と「ログ」を標準出力(stdout)に混ぜて出力するからです。人間なら目で見分けられますが、エージェントには無理です。

agent-exec は、この問題を「stdout = JSON only、stderr = ログ」という厳格な分離で解決したRust 製ジョブランナーです。本記事では、なぜこの設計が重要なのか、どう実装されているのかを解説します。