2025年末に「Clawdbot」として登場し、2026年に入ってから GitHub スター数20万超を記録した OpenClaw が大きな話題になっています。この記事では、OpenClaw の概要、主要機能、セキュリティ上の注意点、そしてセットアップ方法までを解説します。 OpenClaw とは OpenClaw は、Peter Steinberger 氏が開発したオープンソースの AI エージェントフレームワークです。従来のチャットボットが「テキストを生成する」だけだったのに対し、OpenClaw は 実際にタスクを実行する 点が最大の特徴です。 公式サイトのキャッチフレーズは “The AI That Actually Does Things” 。ファイル操作、シェルコマンドの実行、Web ブラウジング、フォーム入力など、PC 上のさまざまな操作を AI に任せることができます。 主要機能 チャットプラットフォーム統合 WhatsApp、Telegram、Discord、Slack、Signal、iMessage など、普段使っているメッセージアプリから自然言語で指示を出せます。専用アプリや Web サイトを開く必要はありません。 実行可能なタスク メール管理: 未読メールの自動分析・優先順位付け、定型返信の作成 スケジュール調整: カレンダー確認、飲食店予約の自動実施 開発支援: GitHub コード履歴の確認、プルリクエストレビュー ブラウザ制御: Web サイト閲覧、フォーム入力、データ抽出の自動化 ローカルファースト設計 個人デバイスやローカルサーバーで動作し、Raspberry Pi のような低価格デバイスでも実行可能です。クラウド利用時も暗号化環境を採用しています。 永続的メモリ ユーザーの好みやコンテキストを記憶し、使い込むほど賢くなる仕組みが組み込まれています。 セットアップ方法 Node.js 22 以上が必要です。 1 npm install -g openclaw@latest インストール後、オンボーディングウィザードで API 設定を完了します。LLM バックエンドは Claude、GPT、Ollama 経由のローカルモデルに対応しており、自分の API キーを使う方式（BYOK）です。 ...

AIエージェントに役職・組織図・予算・目標を与え、24時間自律的に会社を運営させる——そんなコンセプトのオープンソースプロジェクト「Paperclip」が公開され、注目を集めている。 Paperclip とは Paperclip は、複数の AI エージェントを「社員」として組織化し、会社として機能させるためのオーケストレーションプラットフォームだ。 “If OpenClaw is an employee, Paperclip is the company.” 個々の AI エージェントを個別に管理するのではなく、組織図・予算・ガバナンス・目標整合・タスク調整といった会社レベルのインフラを提供する。 GitHub: https://github.com/paperclipai/paperclip 公式サイト: https://paperclip.ing/ ライセンス: MIT 主な機能 エージェントの組織化 組織図（Org Chart）: 階層構造、役職、レポートラインを定義 目標整合（Goal Alignment）: 会社のミッションからプロジェクト目標、個別タスクまで文脈が伝播 マルチカンパニー対応: 1つのデプロイで複数の会社を完全分離して管理 対応エージェント Claude、OpenClaw、Codex、Cursor、Bash スクリプト、HTTP Webhook など、ハートビートシグナルを受信できる任意のランタイムと連携できる。 コスト管理 エージェントごとに月次予算を設定し、使用量80%で警告、100%で自動停止する。暴走的なトークン消費を防ぐ仕組みが組み込まれている。 ガバナンスと監査 人間による承認ゲート（採用・戦略変更時） 設定変更のバージョニングとロールバック 全ての会話・意思決定・ツール呼び出しの追跡ログ いつでもエージェントの一時停止・再割り当て・終了が可能 セットアップ 1 2 3 4 5 6 7 8 # クイックスタート npx paperclipai onboard --yes # 手動インストール git clone https://github.com/paperclipai/paperclip.git cd paperclip pnpm install pnpm dev API は http://localhost:3100 で起動し、組み込みの PostgreSQL データベースを使用する。要件は Node.js 20+ と pnpm 9.15+。 ...

Alibaba Cloud の Qwen チームが 2026 年 2 月にリリースした Qwen3.5-27B は、27B パラメータという中規模サイズながら上位モデルに匹敵する性能を発揮する密（dense）モデルです。メモリ効率に優れ、量子化を活用すれば個人の PC でも快適に動作するため「自分専用 AI」を構築するのに最適な選択肢として注目されています。 Qwen3.5-27B の主な特徴 アーキテクチャ Qwen3.5-27B は MoE（Mixture of Experts）ではなく、全パラメータが推論時に活性化される 密モデル（dense model） です。Gated Delta Networks と Feed Forward Networks を組み合わせた構造で、高い計算密度を実現しています。 パラメータ数: 27B（全パラメータ活性化） コンテキスト長: 262K トークン（最大 1M まで拡張可能） 対応言語: 201 言語 マルチモーダル: 視覚・言語の統合能力を搭載 ベンチマーク性能 27B というサイズにもかかわらず、主要ベンチマークで際立った成績を残しています。 ベンチマーク スコア MMLU-Pro 86.1% GPQA Diamond 85.5% SWE-bench Verified 72.4% LiveCodeBench 80.7% IFEval 95.0% HMMT（数学） 92.0% 特に SWE-bench Verified で 72.4% は GPT-5 mini と同等の数値であり、オープンウェイトの 27B 密モデルとしては驚異的な結果です。コーディング、数学、指示追従の各タスクで中規模モデルカテゴリをリードしています。 ...

Redis はキャッシュとして非常に優秀なツールだが、複数のチームやサービスが**共有状態（shared state）**として Redis を使い始めると、設計上の問題が発生しやすくなる。 キャッシュと共有状態の違い Redis をキャッシュとして使う場合、データは一時的なものであり、いつ消えても問題ない。元データは RDB などに存在し、キャッシュミス時に再構築できる。 一方、共有状態として使う場合は話が変わる。複数のサービスが同じ Redis キーを読み書きし、そのデータが「正」として扱われる。RDB のようなスキーマや制約がないため、以下の問題が起きやすい。 暗黙の契約に依存したデータ構造 RDB であればスキーマによってデータ構造が明示的に定義される。カラム名、型、制約、外部キーなどが設計書の役割を果たす。 Redis にはそのような仕組みがない。キーの命名規則やデータ形式は開発者間の「暗黙の契約」に依存する。チームが増えると、以下のような問題が顕在化する： キーの命名が衝突する — 異なるチームが同じプレフィックスを使ってしまう データ形式の不一致 — あるサービスは JSON、別のサービスは MessagePack で書き込む バージョン管理の欠如 — データ構造を変更しても、読み取り側が追従できない 「削除できないキー」問題 最も厄介な問題の一つが、誰が所有しているのか分からないキーが残り続けることだ。 本番環境で以下のような状況が発生する： # このキーは誰が作った？いつ expire する？削除していい？ GET user:session:abc123:metadata 作成したサービスがすでに廃止されている TTL が設定されていないため、永遠に残る 他のサービスが依存している可能性があり、安易に削除できない キーを「パブリック API」として扱う この問題に対する実践的なアプローチとして、Redis キーをパブリック API のように扱うという考え方がある： バージョニング — キー名にバージョンを含める（例: v2:user:session:{id}） ドキュメント化 — どのキーがどのサービスによって管理されているかを明文化する オーナーの明確化 — 各キーに責任を持つチーム・サービスを割り当てる TTL の必須化 — 共有キーには必ず TTL を設定し、期限切れを明示する 補足：分散ロック基盤としての Redis Redis を共有状態として使うもう一つの典型例が、トランザクション境界をまたぐ分散ロックだ。SET key value NX PX timeout を使ったロックや、Redlock アルゴリズムは広く利用されているが、ここにも落とし穴がある。 ...

技術評論社の Software Design 2026年4月号（2026年3月18日発売）の特集内容を紹介します。今号は PostgreSQL 18 のパフォーマンス最適化と、MCP サーバー開発という2つの注目特集が組まれています。 第1特集：PostgreSQL 18 に学ぶデータベース高速化機能 「アーキテクチャから見えてくる処理性能向上のヒント」と題した第1特集では、PostgreSQL 18 の新機能を軸にデータベース高速化のテクニックが解説されています。 章構成 第1章 データ処理メカニズムと高速化（三谷篤） 第2章 トランザクションとバックアップ（三谷篤） 第3章 クエリ最適化とオプティマイザー（篠田典良） 第4章 インデックス検索技法（篠田典良） 第5章 並列処理と JIT（寺内大輝） 第6章 PostgreSQL 互換クラウド DB 比較（小山哲志） 第7章 PostgreSQL 18 の新機能（寺内大輝） PostgreSQL のデータ処理メカニズムから始まり、クエリ最適化、インデックス活用、並列処理・JIT コンパイルまで、パフォーマンスチューニングの全体像をカバーする構成です。第6章では PostgreSQL 互換のクラウドデータベース（Amazon Aurora、AlloyDB など）の比較もあり、実務で選定する際の参考になります。 第2特集：MCP サーバー開発成功の秘訣 「事業戦略・品質・開発効率をふまえたアプローチ」と題した第2特集では、AI エージェントのツール連携で注目される MCP（Model Context Protocol）サーバーの開発について、実践的なアプローチが紹介されています。 章構成 第1章 MCP 設計ガイド（川崎庸市） 第2章 駅すぱあと API での事例（橋本あゆみ、平川瑞樹） 第3章 Sansan での事例（川瀬圭亮） MCP は Anthropic が提唱した AI モデルと外部ツールを接続するためのオープンプロトコルで、Claude Code をはじめ多くの AI ツールで採用が進んでいます。本特集では設計の基本方針に加え、駅すぱあと API や Sansan といった実サービスでの MCP サーバー構築事例が紹介されており、自社サービスに MCP を導入する際の具体的な指針が得られます。 ...

コトラーが提唱するように、現代のマーケティングにおいて「価値の提案（バリュー・プロポジション）」は核心だ。しかし、情報が氾濫する現代では、顧客は 「時間を消費すること」に対して非常に慎重 になっている。 顧客が貴重な時間を割いてでも「見たい」「知りたい」と思う価値には、共通するいくつかの要素がある。 1. 「切実な不満」を解消する価値 顧客が抱えている「痛み（ペインポイント）」が深いほど、その解決策には時間を投資する。 効率化: 「これまで3時間かかっていた作業が5分で終わる」という提案 不安の解消: 「なぜ資産が減り続けているのか？」といった、生存や安全に関わる問いへの答え 2. 「未知の自分」に出会える価値（自己実現） コトラーの「マーケティング4.0/5.0」でも語られるように、人間は自己実現や精神的充足を求める。 変身の予感: 「これを見れば、憧れの自分に一歩近づける」という高揚感 スキルの習得: 学習コストを払ってでも手に入れたい、市場価値を上げる情報 3. 「物語（ストーリー）」というエンターテインメント データや機能の羅列には誰も時間を割かないが、物語 には惹きつけられる。 共感と葛藤: 開発者がどのような苦労をしてその製品を作ったのかというドラマ 文脈の提供: 自分の生活がその製品によってどう劇的に変わるかという「ビフォー・アフター」 4. 「信頼」というコスト削減 「この人の言うことなら間違いない」というブランドの信頼感は、顧客が情報を取捨選択する時間を大幅に短縮させる。結果として、そのブランドが発信する「長尺のコンテンツ」でも安心して見てもらえるようになる。 価値を際立たせるための3つの視点 時間を割いてもらうためには、以下の3つの要素を掛け合わせるのが効果的だ。 要素 内容 顧客の反応 Relevance（関連性） 自分に関係があるか 「これは私のことだ！」 Benefit（便益） 得られる利益は何か 「見る価値がありそうだ」 Urgency（緊急性） 今見るべき理由は何か 「後回しにできない」 4つの価値と3つの視点の関係 前述の4つの価値は、この Relevance・Benefit・Urgency の掛け合わせで説明できる。 1. 「切実な不満」の解消 は、3つの視点すべてが自然に揃うケースだ。痛みを抱えている本人にとって Relevance は明白であり、解決策という Benefit は直接的で、痛みが続いている限り Urgency も高い。だからこそ最も強い動機づけになる。 2. 「未知の自分」への自己実現 は、Relevance と Benefit は強いが Urgency が弱くなりがちだ。「いつかやりたい」で終わらせないために、「今だけの機会」「このスキルがないと取り残される」といった緊急性の演出が鍵になる。 3. 「物語」によるエンターテインメント は、Relevance の入口を広げる役割を果たす。データの羅列では「自分には関係ない」と素通りされる情報も、共感できるストーリーに包むことで「これは自分の話だ」と感じさせることができる。 4. 「信頼」によるコスト削減 は、3つの視点すべてのハードルを下げる。信頼されたブランドからの発信であれば、Relevance の判断に迷わず、Benefit を疑わず、Urgency を感じやすくなる。信頼は個々の価値を増幅するレバレッジだ。 ...

深圳市龍崗区が「OpenClaw および OPC（One-Person Company）発展支援に関する若干の措置」を発表した。AI エージェントフレームワーク OpenClaw と「一人企業」モデルを対象にした政府支援策としては、中国初、おそらく世界初の試みだ。荒井健一氏（@aarai666）のツイートで紹介されたこの政策の要点を整理する。 OpenClaw とは何か OpenClaw はオーストリアの Peter Steinberger 氏が開発したオープンソースの AI アシスタントだ。フライトの予約からメール整理まで幅広いタスクを自律的にこなし、個人が数人分のチームに匹敵する生産性を発揮できる。この仕組みを活用して一人で会社を運営する「OPC（One-Person Company）」というコンセプトが、中国を中心に急速に広がっている。 中国では無料インストールイベントに数千人が参加するなど爆発的な人気を見せており、李強首相が全国人民代表大会で「スマートエージェント」（OpenClaw を含む概念）に言及するほどの注目度だ。 深圳・龍崗区の支援策 龍崗区の政策は、概念の認知からわずか約 3 週間で正式な支援策にまとめ上げるスピード感を見せた。支援は大きく 3 つの柱で構成される。 1. 導入・開発支援 「ロブスターサービスゾーン」を設置し無料で OpenClaw の導入サービスを提供するプラットフォームに、最大 200 万元（約 4,000 万円）の補助金 コード貢献やスキルパッケージ開発を行う開発者への追加資金支援 関連技術パッケージの開発・配布企業に最大 200 万元 の助成金 2. 計算・データリソース データサービス、AI NAS ハードウェア、大規模モデル API 利用料の 30〜50% を補助 OPC コミュニティに新規入居する企業に 3 ヶ月間 の無料計算リソースを提供 3. 総合的な起業支援 2 ヶ月間 の無料住居提供 18 ヶ月間 の割引オフィススペース 人材定着助成金として最大 10 万元（約 200 万円） エクイティ投資として最大 1,000 万元（約 2 億円） 政策の戦略的目標は「初期の起業コストをゼロ水準まで引き下げ、深圳を AI エージェントスタートアップのハブにする」ことだ。 ...

Claude Code などの LLM エージェントを業務で使う際、最大のリスクは**ハルシネーション（幻覚）**です。プロンプトの改善ばかりが注目されがちですが、本当に必要なのは「仕組みで縛る」アプローチです。 きっかけとなった事故 ある開発者が実際に遭遇した事故が、この議論のきっかけです: which コマンドの結果だけで「未インストール」と診断されたが、コードは PATH 外のディレクトリを直接参照していた。ログを1行も読まずに断言。 LLM エージェントは自信に満ちた口調で誤った結論を出すことがあり、人間がそれを鵜呑みにしてしまうリスクがあります。 Anti-Hallucination Protocol の4つの柱 提唱されている Anti-Hallucination Protocol は、以下の4つのルールで構成されます: 1. 事実主張にはツール実行による検証を義務化 LLM が「〜がインストールされていない」「〜が原因です」と主張する場合、必ず対応するコマンドやツールを実行して裏付けを取ることを求めます。推測だけで結論を出すことを許容しません。 2. 禁止パターンの明示 以下の4つのパターンを明示的に禁止します: パターン 説明 推測診断 十分な証拠なしに原因を断定する 確認なし否定 実際に確認せず「存在しない」「動かない」と主張する 記憶による主張 過去の学習データだけに基づく事実主張 自信に満ちた誤り 高い確信度で不正確な情報を提供する 3. 違反時のインシデント記録と伝播 ハルシネーションが検出された場合、インシデントとして記録し、全プロジェクト横断で伝播させます。これにより同じ失敗パターンを繰り返さない仕組みを構築します。 4. プロジェクト設定への組み込み CLAUDE.md や類似の設定ファイルにルールを記述し、プロジェクト単位で一貫したガードレールを維持します。 2026年のハルシネーション対策の現状 2026年3月時点で、各 LLM のハルシネーション率は改善が進んでいます。LLM Hallucination Index 2026 によると、Claude Sonnet 4.6 は BS 検出成功率 91.0%、誤検出率 3.0% とトップクラスの精度を示しています。 しかし、モデル性能の向上だけでは不十分です。特に以下の場面ではハルシネーションが発生しやすいことが報告されています: コンテキスト圧縮後: 長い会話でコンテキストが圧縮されると、計画と実装の乖離が起きやすい Plan Mode での実装フェーズ: 計画作成後の実装で、計画にない機能を追加してしまう 実践的な対策 CLAUDE.md への記述例 1 2 3 4 5 6 ## Anti-Hallucination Rules - ファイルの存在確認は必ず `ls` や `cat` で実行すること - パッケージのインストール状況は `which` だけでなく、実際のインポートやバージョン確認で検証すること - エラーの原因を主張する前に、必ずログファイルを読むこと - 「〜のはずです」「おそらく〜」という推測を事実として扱わないこと CLEO のようなツールの活用 CLEO は Claude Code 向けのタスク管理ツールで、4層の Anti-Hallucination 保護と SQLite による不変の監査証跡を提供します。 ...

OpenClaw を Telegram で使っている人に向けて、Forum Topics を活用した構造化テクニックが海外で話題になっています。ブックマーク 2,000 件を突破したこの手法を紹介します。 Forum Topics でできること Telegram の Forum Topics 機能を OpenClaw と組み合わせると、以下のことが実現できます: 会話をカテゴリ分け — 仕事、開発、健康、趣味など、トピックごとに独立した LLM セッションを持てる 文脈が混ざらない — 各トピックが独立したセッションになるため、異なるコンテキストが干渉しない cron ジョブ・定期通知の自動ルーティング — 関連するトピックに自動で振り分け メール転送による自動処理 — ボットにメールを転送するだけで、適切なトピックで自動的に処理 設定方法 設定はシンプルです: BotFather で「Threaded Mode」を ON にする OpenClaw に Forum Topics を使うよう指示する これだけで、トピックベースの構造化された AI アシスタント環境が整います。 実践例: AI が部門別の秘書チームになる この手法を紹介した Typefully の共同創業者は、実際に自分のプロダクト運用でこの構造を活用しています: トピック 用途 General 一般的なやり取り Dev 開発タスク管理 Life 日常のタスク Health 健康管理 Racing レース準備 Finances 財務管理 まさに AI が部門別の秘書チーム として機能している状態です。 ...

AI モデルの利用が増えるにつれ、複数のプロバイダの API キーを管理する煩雑さやコストの把握が難しくなっていく。OpenRouter を使えば、1つの API キーで複数の AI モデルにアクセスでき、コスト管理も一元化できる。 OpenRouter とは OpenRouter は、複数の AI モデルプロバイダ（OpenAI、Anthropic、Google、Meta など）のモデルに単一の API エンドポイントからアクセスできるルーティングサービスだ。OpenAI 互換の API 形式を採用しているため、既存のコードからの移行も容易になっている。 料金体系 OpenRouter は無料から始められる。クレジットカードの登録も不要だ。 無料モデル: DeepSeek V3/R1、Google、Meta、Mistral など約27種類のモデルが無料で利用可能（1日50リクエスト、1分20リクエストの制限あり） 有料モデル: Claude や GPT-4 などのプレミアムモデルはプロバイダの正規料金で従量課金。最低金額やロックインなし BYOK（自分の API キー持ち込み）: 月100万リクエストまで無料。以降は通常料金の5%の手数料 OpenRouter を使う3つのメリット 1. コスト効率の向上 各プロバイダと個別に契約する代わりに、OpenRouter 経由で利用することで支出を一元管理できる。用途に応じて安価なモデルと高性能なモデルを使い分けることで、全体のコストを最適化できる。 2. API キーの一元管理 複数のプロバイダの API キーを管理する必要がなくなる。1つの OpenRouter API キーだけで、さまざまなモデルにアクセスできる。 1 2 # OpenRouter API キーを設定するだけで複数モデルにアクセス可能 export OPENROUTER_API_KEY="sk-or-..." 3. 最新モデルへの素早い切り替え 新しいモデルがリリースされた際、OpenRouter 上で利用可能になればすぐに試すことができる。プロバイダごとにアカウント登録や API キー発行をする必要がない。 ...