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

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

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

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

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

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

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

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

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

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

OpenClaw のワークスペースには SOUL.md、USER.md、MEMORY.md、AGENTS.md、TOOLS.md など複数の設定ファイルがあります。それぞれ何を書くべきか、どう使い分けるかを整理します。

企業がAIエージェントを「雇う」時代が、もうすぐ来ます。

すでに一部の企業では、カスタマーサポート、コード生成、データ分析といったタスクをAIエージェントに任せ始めています。人間の従業員と同じように、エージェントに仕事を発注し、成果物を受け取り、報酬を支払う。そういうワークフローが現実になりつつあります。

ただ、ここで問題が出てきます。「このAIエージェントに仕事を頼んでいいのか？」——そう思ったとき、あなたは何を確認しますか？

人間なら履歴書、面接、リファレンスチェックがあります。でもAIエージェントには、今のところそういう仕組みがありません。ERC-8004 （Trustless Agents）は、この問いに「ブロックチェーンで解決しよう」と提案した規格です。2025年8月にドラフトが公開され、2026年1月にEthereum メインネットへのデプロイが始まりました。

2026年2月6日、X.com（旧Twitter）がX API の新しい従量課金モデル（Pay-Per-Use）を発表しました。これまでの月額200ドル・5,000ドルの固定プランから、API呼び出しごとに課金されるクレジット制に移行します。

この変更により、AIエージェント にX.com APIを操作させる際の設計要件が大きく変わりました。「何度実行しても安全」だった無料APIと違い、「1回の誤実行が課金につながる」有料APIでは、CLIツールに新しい防御機構が必要です。

本記事では、私が開発したxcom-rs というRust製X.com API CLIツールを題材に、従量課金時代のCLI設計で実装すべき3つの防御策（コストガードレール、冪等性、リスクメタデータ）を解説します。

App Storeの審査で拒否されると、修正→再提出→再審査のサイクルで数日から数週間のロスが発生します。プライバシーポリシーの不備、必須APIの説明不足、禁止されたAPIの使用など、拒否理由は多岐にわたり、事前に気づくのは困難です。

Greenlight は、提出前にこれらの拒否リスクをローカル環境で検知するオープンソースのCLIツールです。ソースコード、プライバシーマニフェスト、IPAバイナリ、App Store Connectのメタデータを解析し、Appleの審査ガイドラインに違反する可能性のある問題を事前に発見します。

「近くのカフェを探して」——AIエージェント にこう頼んだとき、エージェントがやるべきことは意外と単純です。

1つは「検索したい意図」（例: coffee/ramen）。もう1つは「検索の起点になる位置」です。後者はOSの位置情報やアプリ側の設定、あるいはユーザー入力で用意して、エージェントに渡します（goplacesが勝手に現在地を特定するわけではありません）。

設定次第では、Claude やOpenCode 、Codex のようなエージェントがローカルでシェルコマンドを実行できます。つまり、位置を入力として受け取り、外部APIで検索/経路案内を返すCLIが1つあれば、それだけで「位置情報スキル」を組み込めます。

そこで今回は、Google Places/Routesを叩けるCLIであるgoplaces を使って、この部分を安定して回すための実装パターンをまとめます。CLIを「エージェントが呼び出すプロトコル」として設計する観点は、先に「Agentic CLI Design: CLIをAIエージェント向けプロトコルとして設計する7つの原則 」で整理しました。本記事はその具体例です。

AIエージェントに「記憶」を持たせる方法として、RAG（Retrieval-Augmented Generation）が広く使われています。しかし、RAGには「毎回検索してコンテキストを再構築する」という根本的な制約があります。

ここでのRAGは、外部のデータ（文書・ログなど）を検索して、LLM（Large Language Model: 大規模言語モデル）に渡す仕組みです。 一方で「状態の蓄積（前回の決定が、今回どう更新されたか）」は苦手になりやすいです。

Rowboat は、この問題を「継続的にナレッジグラフ（知識をノードとリンクで表す構造）を更新し、状態を蓄積する」アプローチで解決しようとするオープンソース（Apache-2.0）のローカルファーストAIコワーカーです。 Y Combinator のS24出身のチームが開発しており、メール（Gmail ）や会議メモ（Granola 、Fireflies ）から情報を抽出します。 抽出した情報は、Obsidian 互換（ObsidianはMarkdownベースのノートアプリ）のMarkdownファイルとして保存され、リンク（バックリンク: [[...]] でノート同士を参照する仕組み）でつながります。 ローカルファースト（データをクラウドではなく端末内に置く設計）なので、内容を自分で確認・編集できるのが売りです。 本記事では、Rowboatの設計思想、特にエンティティ解決（Entity Resolution: 表記ゆれや文脈をまたいで同一の人物/組織を統合する処理）とバッチ処理の実装を掘り下げます。