Agent

Google のシニア AI プロダクトマネージャー Shubham Saboo 氏が、OpenClaw エージェントを 40 日間運用した経験から導き出した「マークダウンファイル駆動のエージェント運用スタック」について紹介する。モデルを変えず、蓄積されたマークダウンファイルだけでエージェントが成長していくというアプローチだ。 コアコンセプト：マークダウンファイルが成長エンジン このスタックの最大の特徴は、モデル自体は変わらないという点にある。エージェント間の違いは「蓄積されたマークダウンファイル」にある。データベースもオーケストレーションフレームワークもメッセージキューも不要で、ディスク上のマークダウンファイルがすべてのインテグレーション層として機能する。 3 層スタック構造 エージェントの設計は以下の 3 層で構成される： 1. Identity 層（アイデンティティ） SOUL.md がセッション起動時に毎回読み込まれる。ここにはエージェントの人格、役割、原則、関係性が定義される。 1 2 3 4 # SOUL.md - 役割: プロジェクトマネージャー - 原則: 簡潔さを重視、事実ベースで判断 - 性格: Dwight Schrute 的な徹底さ TV キャラクターの名前をエージェントに付けるのが Saboo 氏のテクニックだ。Claude の学習データにキャラクターの性格が含まれているため、「Dwight Schrute のエネルギーで」と伝えるだけで、徹底的で真剣な仕事ぶりが期待できる。 2. Operations 層（行動ルール） AGENTS.md でセッション起動ルーティンとメモリ管理ルールを定義する。運用開始から約 1 週間後に作成するのが推奨される。 1 2 3 4 # AGENTS.md - セッション開始時: MEMORY.md を読み込む - タスク完了時: 日次ログに記録 - エラー発生時: 修正内容をメモリに追記 3. Knowledge 層（記憶・ログ） MEMORY.md は約 2 週間の運用後に初期化する。日次ログをレビューし、繰り返し発生する修正パターンを恒久的なエントリとして蒸留していく。 ...

OpenClaw を使った X（旧 Twitter）運用で、1週間で79万インプレッション・フォロワー1,000人以上増加という成果報告が話題になっています。この記事では、その成果の背景にある「ナレッジ管理」と「投稿生成プロセス」の重要性について解説します。 OpenClaw × X運用の成果 @ichiaimarketer 氏が報告した成果: 約1週間で79万インプレッション フォロワー1,000人以上増加 注目すべきは、この成果は OpenClaw のツール自体の力ではなく、使い方に依存しているという点です。 鍵は「ナレッジ管理」 AI に「思いつきで投稿させる」のではなく、蓄積された知識・経験をコンテキストとして与えることが重要です。 なぜナレッジ管理が重要か コンテキストの質が出力の質を決める — LLM は与えられた情報から生成するため、ナレッジベースの質が投稿の質に直結する 一貫性のあるブランディング — 過去の投稿や知見を蓄積することで、アカウントとしての一貫した声が生まれる 専門性の反映 — 自分の専門知識をナレッジとして整理することで、AI が専門的な投稿を生成できる OpenClaw でのナレッジ管理の実践 OpenClaw には Knowledge Management スキルが用意されており、メモリエントリを自動的に分類・整理できます。蓄積された知見は Research、Insight、Pattern などのフォルダに分類され、タイムスタンプ付きの Markdown ファイルとして保存されます。 また、OpenClaw の cron システムと組み合わせて定期的に同期することで、ナレッジベースを常に最新の状態に保てます。 この整理されたナレッジをスキルから参照することで、投稿生成時に適切なコンテキストを自動的に提供できます。 投稿生成プロセス 効果的な X 運用のための投稿生成プロセスは以下の流れです: ナレッジの蓄積 — 日々の学びや知見をナレッジベースに追加 コンテキストの構築 — 投稿テーマに関連するナレッジを選択 AI による生成 — OpenClaw の bird スキルを使って投稿を生成 レビューと投稿 — 生成された内容を確認して投稿 OpenClaw の bird スキル OpenClaw には bird というスキルが組み込まれており、X/Twitter の操作を CLI ベースで行えます: ...

OpenClaw で AI エージェントを運用していると、「エージェントが内部で何をしているのか分からない」という課題に直面します。Comet チームが開発した opik-openclaw は、OpenClaw のエージェント動作をトレース・評価・監視できるオブザーバビリティプラグインです。AI の「ブラックボックス」を「ガラスボックス」に変えるツールとして注目されています。 Opik とは Opik は、Comet が開発する Apache 2.0 ライセンスのオープンソース LLM オブザーバビリティプラットフォームです（GitHub で 18,000 以上のスター）。LLM アプリケーションのライフサイクル全体 — 開発・評価・本番監視 — をカバーする統合基盤として設計されています。 Opik の 3 つの柱 1. トレーシング（開発） すべての LLM 呼び出しについて、プロンプト・レスポンス・メタデータ・コスト・レイテンシを詳細に記録します。1 日あたり 4,000 万以上のトレースを処理できるスケーラビリティを持ち、Prompt Playground でプロンプトの実験・比較も可能です。 2. 評価とテスト LLM-as-a-judge によるハルシネーション検出、コンテキスト精度、回答の関連性といった自動評価メトリクスを提供します。データセットを定義して「良い回答とは何か」を基準化し、新バージョンのアプリを自動スコアリングできます。Pytest との統合により CI/CD パイプラインに評価を組み込むことも可能です。 1 2 3 4 5 6 7 8 9 from opik.evaluation.metrics import Hallucination metric = Hallucination() score = metric.score( input="フランスの首都は？", output="パリです。", context=["フランスの首都はパリである。"], ) print(score) # HallucinationResult(score=0.0, reason="...") 3. 本番監視と最適化 ...

OpenClaw を使っていると「AI が裏で何をしているのか分からない」と感じることはありませんか？Comet が開発した opik-openclaw は、OpenClaw のエージェント動作をトレース・可視化するオープンソースプラグインです。AI を「ブラックボックス」から「ガラスボックス」に変えてくれます。 opik-openclaw とは opik-openclaw は、Comet が開発する LLM オブザーバビリティプラットフォーム Opik（GitHub Star 18,000+）の OpenClaw 公式プラグインです。 OpenClaw のエージェントが実行するすべての操作を記録・可視化し、以下の情報をダッシュボードで確認できます。 LLM 呼び出し: 入出力ペア、トークン数、レイテンシ、コスト ツール実行: どのツールが、いつ、どんな引数で呼ばれたか エージェント委譲: サブエージェントへのタスク委譲の流れ 推論プロセス: 最初のメッセージから最終応答までの全会話フロー セットアップ（3 コマンド） 1 2 3 4 5 6 7 8 # 1. プラグインをインストール openclaw plugins install @opik/opik-openclaw # 2. 認証情報を設定 openclaw opik configure # 3. ゲートウェイを再起動 openclaw gateway restart 動作確認は以下のコマンドで行えます。 ...

セキュリティスタートアップ CodeWall の AI エージェントが、マッキンゼーの社内 AI プラットフォーム「Lilli」をわずか2時間で完全突破した。4,650万件のチャット履歴からシステムプロンプトまで、認証なしで読み書き可能だったという。攻撃手法は SQL インジェクション——教科書の1章目に載る古典的な脆弱性だ。 Lilli とは Lilli はマッキンゼーが社内向けに構築した生成 AI プラットフォームで、数万人のコンサルタントが日常的に利用している。戦略立案、M&A 分析、クライアント対応など、機密性の高い業務に活用されていた。 Lilli のアーキテクチャ マッキンゼーは Lilli の技術構成をある程度公開しており、その設計思想と今回の事件のギャップが際立つ。 RAG パイプライン + オーケストレーション層 Lilli のコアは RAG（Retrieval-Augmented Generation）パイプラインだ。40以上のキュレーション済みナレッジソースに10万件超のドキュメント、インタビュー記録、セクター別プレイブックが格納されている。ユーザーのクエリはベクトル埋め込みでマッチングされ、5〜7件の関連文書が引用付きで提示される。四半期あたり約200万クエリを処理する規模だ。 技術スタック LLM: Cohere、OpenAI（Azure 経由）など複数モデルを併用。Microsoft、Google、Nvidia、Anthropic との戦略的パートナーシップ フレームワーク: QuantumBlack の Horizon ツールキット、LangChain、FAISS インフラ: Microsoft Azure（データストレージ・スケーラビリティ） 独自ツール: PowerPoint を85%以上読み取り可能にする独自ドキュメントパーサー 「ゼロトラスト」設計——のはずだった マッキンゼーは Lilli のセキュリティについて、ゼロトラストセキュリティスタック、オンプレミスデータストア、ロールベースアクセス制御（RBAC）、完全な監査ログを備えていると説明していた。しかし実際には、22個の API エンドポイントが認証なしで外部に公開されていた。設計上のセキュリティと実装上のセキュリティの乖離が、今回の事件の根本原因だ。 攻撃の経緯 CodeWall の自律型セキュリティエージェントは、以下の手順で Lilli を攻撃した: 公開 API ドキュメントの発見 — Lilli の API ドキュメントが外部から閲覧可能な状態だった 認証不要エンドポイントの特定 — 22個のエンドポイントが認証なしでアクセス可能だった SQL インジェクションの検出 — ユーザー検索クエリを書き込むエンドポイントで、JSON のキー名が SQL 文に直接連結されていた 本番データベースへのフルアクセス — 読み取りと書き込みの両方が可能な状態に到達 人間の介入は一切なし。AI エージェントが自律的に脆弱性を発見し、エクスプロイトまで完了した。 ...

オープンソースの AI エージェントフレームワーク「OpenClaw」の利用が中国国内で急拡大する中、中国の国家コンピュータネットワーク緊急対応技術チーム（CNCERT）が緊急のセキュリティ警告を発しました。政府機関や国有銀行での使用禁止にまで発展したこの問題について、技術的な背景と対策をまとめます。 何が起きたのか 2026年3月、中国の CNCERT は OpenClaw について「極めて弱いデフォルトセキュリティ設定」を持つと警告を発しました。OpenClaw はローカルファイルシステムや環境変数へのアクセス、拡張機能のインストールなど高いシステム権限を付与されますが、デフォルトのセキュリティ設定が不十分であり、攻撃者がシステム全体の制御を容易に奪取できる状態であると指摘されています。 この警告を受けて、中国当局は政府機関と国有企業（主要銀行を含む）に対し、業務用コンピュータへの OpenClaw のインストールを禁止する通知を出しました。既にインストール済みの職員には、上司への報告・セキュリティチェック・必要に応じた削除が指示されています。 CNCERT が指摘した主なリスク 1. アーキテクチャ設計上の問題 OpenClaw はローカルファイルシステム、環境変数、シェルへの広範なアクセス権限を持ちます。これ自体は AI エージェントの機能として必要ですが、適切な制限なしに運用すると重大なリスクとなります。 2. デフォルト設定の脆弱性 管理 UI のデフォルトポートがインターネットに公開可能な状態 環境変数に認証情報を平文で保存する設定がデフォルト スキルの自動更新が有効な状態がデフォルト 3. プラグインエコシステムの危険性 不正なプラグイン（ポイズンドプラグイン）を通じて、ユーザーのシステムに悪意あるコードが侵入するリスクがあります。プラグインのアクセス権限が十分に制限されていないことが問題視されています。 4. Web ベースの攻撃 悪意ある指示を Web ページに埋め込むことで、OpenClaw に不正な操作を実行させる攻撃（プロンプトインジェクション）が可能です。 5. 重要データの誤削除 AI エージェントの判断ミスにより、ユーザーが意図しない重要データの削除が発生するリスクも指摘されています。 CNCERT の推奨対策 CNCERT は以下の対策を推奨しています。 コンテナで隔離実行する — OpenClaw をホストシステムから隔離された環境で動作させる 管理ポートをインターネットに公開しない — 管理 UI へのアクセスをローカルネットワークに限定する 認証情報を平文で環境変数に保存しない — シークレット管理ツールを使用する スキルの自動更新を無効にする — 更新は手動で検証してから適用する 厳密な認証とアクセス制御を実装する — 不要な権限を排除する セキュリティアップデートへの追従を徹底する — 既知の脆弱性に速やかに対応する AI エージェント全般への教訓 この問題は OpenClaw に限った話ではありません。AI エージェントは本質的に高いシステム権限を必要とするため、以下の原則はどのエージェントツールにも当てはまります。 ...

Anthropic が Claude Code の新機能「Code Review」を発表した。PR が開かれると、複数のエージェントがチームとして並列にコードレビューを実行し、人間が見落としがちなバグを検出する。開発者の Boris Cherny 氏（@bcherny）は「数週間使って、自分では気づかなかった本物のバグを何度も見つけてくれた」と報告している。 仕組み PR がオープンされると、Code Review は以下のステップを実行する: エージェントチームの派遣 — 複数のエージェントが並列に動き、それぞれ異なるクラスの問題（ロジックエラー、セキュリティ脆弱性、コード品質など）を探す 検証フェーズ — 候補として検出された問題を実際のコード挙動と照合し、偽陽性をフィルタリングする 深刻度ランキング — 検出された問題を重要度順に並べる レビューコメント投稿 — PR に対してサマリーコメント 1 件と、具体的な問題箇所へのインラインコメントを投稿する レビューの深さは PR の規模と複雑さに応じてスケールする。大きく複雑な変更にはより多くのエージェントが投入される。 検出精度 Anthropic 社内でのテスト結果: PR サイズ 指摘ありの割合 平均指摘数 大規模（1,000行以上） 84% 7.5件 小規模（50行未満） 31% 0.5件 特筆すべきは誤検出率が 1% 未満という点だ。エンジニアが「この指摘は間違い」と判定したケースがほとんどなく、検証フェーズによる偽陽性フィルタリングが効果的に機能していることを示している。 なぜ必要なのか Cherny 氏によれば、Anthropic のエンジニア一人あたりのコード出力は 2026 年に入って 200% 増加した。AI コーディングエージェントによってコード生成が加速する一方で、レビューがボトルネックになっていた。人間のレビュアーが処理できる量には限界があり、AI が書いたコードも人間が書いたコードも、同じ品質基準でレビューする必要がある。 Code Review はこの問題に対する Anthropic 自身の解答だ。まず社内で使い、効果を確認した上で外部に公開している。 利用条件 対象プラン: Team / Enterprise（Research Preview） 料金: トークン使用量に基づく従量課金。PR サイズと複雑さに応じて平均 $15〜25 レビュー時間: 約 20 分 セットアップ: 管理者が GitHub App をインストールし、対象リポジトリを選択。開発者側の追加設定は不要 組織レベルでの月間支出上限、リポジトリ単位の有効化制御、レビュー受け入れ率の分析ダッシュボードも用意されている。 ...

Anthropic が Claude Code の新機能「Code Review」を発表した。PR が開かれると、複数のエージェントがチームとして並列にコードレビューを実行し、人間が見落としがちなバグを検出する。開発者の Boris Cherny 氏（@bcherny）は「数週間使って、自分では気づかなかった本物のバグを何度も見つけてくれた」と報告している。 仕組み PR がオープンされると、Code Review は以下のステップを実行する: エージェントチームの派遣 — 複数のエージェントが並列に動き、それぞれ異なるクラスの問題（ロジックエラー、セキュリティ脆弱性、コード品質など）を探す 検証フェーズ — 候補として検出された問題を実際のコード挙動と照合し、偽陽性をフィルタリングする 深刻度ランキング — 検出された問題を重要度順に並べる レビューコメント投稿 — PR に対してサマリーコメント 1 件と、具体的な問題箇所へのインラインコメントを投稿する レビューの深さは PR の規模と複雑さに応じてスケールする。大きく複雑な変更にはより多くのエージェントが投入される。 検出精度 Anthropic 社内でのテスト結果: PR サイズ 指摘ありの割合 平均指摘数 大規模（1,000行以上） 84% 7.5件 小規模（50行未満） 31% 0.5件 特筆すべきは誤検出率が 1% 未満という点だ。エンジニアが「この指摘は間違い」と判定したケースがほとんどなく、検証フェーズによる偽陽性フィルタリングが効果的に機能していることを示している。 なぜ必要なのか Cherny 氏によれば、Anthropic のエンジニア一人あたりのコード出力は 2026 年に入って 200% 増加した。AI コーディングエージェントによってコード生成が加速する一方で、レビューがボトルネックになっていた。人間のレビュアーが処理できる量には限界があり、AI が書いたコードも人間が書いたコードも、同じ品質基準でレビューする必要がある。 Code Review はこの問題に対する Anthropic 自身の解答だ。まず社内で使い、効果を確認した上で外部に公開している。 利用条件 対象プラン: Team / Enterprise（Research Preview） 料金: トークン使用量に基づく従量課金。PR サイズと複雑さに応じて平均 $15〜25 レビュー時間: 約 20 分 セットアップ: 管理者が GitHub App をインストールし、対象リポジトリを選択。開発者側の追加設定は不要 組織レベルでの月間支出上限、リポジトリ単位の有効化制御、レビュー受け入れ率の分析ダッシュボードも用意されている。 ...

Anthropic が公開した「The Complete Guide to Building Skills for Claude」は、Claude Code のスキル機能を本格的に活用するための 33 ページにわたる公式ガイドです。この記事では、ガイドの要点を日本語でまとめます。 Skills とは何か Skills は、Claude に特定のタスクやワークフローを教えるための 再利用可能な指示セット です。フォルダにパッケージ化され、一度作れば Claude.ai、Claude Code、API のすべてで動作します。 従来のように毎回プロンプトで細かく指示する代わりに、Skills を使えば「一度教えて、何度でも使える」ようになります。 Skills のファイル構造 my-skill/ ├── SKILL.md # メインの指示ファイル（必須） ├── scripts/ # 補助スクリプト ├── references/ # 参考資料 └── assets/ # アセットファイル 重要なルール: メインファイルは必ず SKILL.md（大文字小文字を区別） フォルダ名は kebab-case（例: notion-project-setup） README.md は含めない YAML フロントマターの設計 SKILL.md の冒頭に YAML フロントマターを記述します。ここがスキルの「顔」になります。 1 2 3 4 --- name: deploy-checker description: "本番デプロイ前のチェックリストを実行する。デプロイや本番リリースの話題が出たときに使用する" --- description には 何をするか と いつ使うか の 2 つを含めることが重要です。Claude はこのメタデータだけでスキルの使用タイミングを判断します。 ...

ゼロトピック（Zero Topic）の #337「Claude Code時代の仕様書の役割」 が話題になっている。10X の矢本氏が、生成 AI が開発プロセスに与える影響と、仕様書の役割がどう変わるかを整理した回だ。 バイブコーディングの限界と仕様駆動開発 Claude Code のようなAIコーディングエージェントの登場で、コード生成速度は飛躍的に向上した。しかし「バイブコーディング」— AI に任せて探索的にコードを生成するアプローチ — には問題がある。 検証負債の蓄積: AI の生成速度が人間の理解・検証速度を上回る 意図不明なコード増殖: 内部構造を精査せず先に進み、誰も理解していない領域が広がる デバッグ困難化: コードの意図が不明では根本原因の特定が難しい こうした課題に対する解が 仕様駆動開発（Spec-Driven Development: SDD） だ。Thoughtworks Technology Radar Vol.32（2025年4月）で Trial に採用されたこの手法は、「仕様を先に定義し、その仕様に基づいて AI にコードを生成させる」という原則に立つ。 仕様書の役割の変化 従来の設計書は人間同士のコミュニケーションツールだった。AI との協働では「AI への指示書」としての側面が加わる。 SDD における仕様書の構成は、Kiro が提唱する3層モデルが分かりやすい: ファイル 役割 requirements.md ユーザーストーリーと受け入れ基準 design.md アーキテクチャ、シーケンス、設計上の注意 tasks.md 実装計画とタスク分解 重要なポイントは、仕様は 「唯一の情報源（Single Source of Truth）」 として機能し、プロセス駆動はルールブック（プロセスルール）が別途担当するという区別だ。 Claude Code での実践 基礎レベル: CLAUDE.md + ステアリングファイル CLAUDE.md に制約・規約・コンテキストを定義 .steering/ 配下に作業バッチフォルダを作成 要件定義書・設計書・タスクリストを生成・保存 タスクに沿ってコード生成・テスト実施 応用レベル: カスタムコマンドの活用 2026年1月に plansDirectory 設定が追加され、/plan モードで作成した計画書を Git 管理できるようになった。さらにカスタムコマンドを使えば、ドメイン知識を埋め込んだ独自のワークフローを構築できる。 ...