OpenClaw on KnightLiブログ

OpenClaw 作者 Peter Steinberger は AI ソフトウェア開発をどう見ているのか：OpenClaw から閉ループ開発へ

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger の経歴は、AI ソフトウェア開発で何が変わっているのかを見るうえでよい材料になる。

彼は「AI で突然注目された新人」ではない。OpenClaw の前から、PSPDFKit の創業者として PDF レンダリング、文書処理、開発者ツールに長く取り組んできた。この種のプロダクトは、コンセプトだけでは勝てない。性能、互換性、API 設計、企業顧客、長期保守に向き合う必要がある。

そのため、Steinberger が後に AI ツールで OpenClaw を作り、AI Agent、個人自動化、AI coding について語ったとき、重要なのは「一人で大量のコードを書いた」ことだけではない。より面白いのは、長年のソフトウェア工学経験と新世代の AI coding agent を組み合わせ、開発プロセスをどう捉え直したかだ。

AI coding は魔法のボタンではない

AI coding の議論は、よく二つの極端に分かれる。

一方は、AI はすでにコードを書けるのでプログラマーは不要になる、と言う。

もう一方は、AI が書くコードは信頼できず、本当のエンジニアリングは人間が手で書くべきだ、と言う。

Steinberger の経験は第三の見方に近い。AI はソフトウェア開発の操作単位を変えるが、エンジニアリング判断を消すわけではない。

従来、開発者の仕事は主に「コードを編集する」ことを中心に回っていた。要求分解、アーキテクチャ判断、実装、テスト、バグ修正は、すべて人間によるコード変更を軸にしていた。

AI coding agent が入ると、開発者はだんだん実行システムを管理する存在に近づく。

目標を説明する。
コンテキストを与える。
境界を決める。
agent にコードを変更させる。
テストとチェックを実行する。
結果に基づいて反復する。

これは単にキーボードをモデルに渡すことではない。人間の役割を「すべての行を自分で打つ」ことから、「方向を定義し、フィードバックを設計し、結果を判断する」ことへ移すものだ。

なぜ彼は vibe coding という呼び方を好まないのか

Steinberger をめぐる議論でよく出る言葉に vibe coding がある。

この言葉はもともと、開発者が自然言語でアイデアを説明し、AI に大量のコードを生成させ、実行結果とフィードバックで調整していく新しい開発スタイルを指していた。

しかし Steinberger は、この言葉を全面的には受け入れていない。公開記事では、彼が vibe coding をやや軽蔑的な表現になりやすいと見ていることが紹介されている。AI 支援開発を「感覚で適当に生成する」もののように見せ、背後にある技能、判断、経験を見落とすからだ。

この批判には筋がある。

本当に有効な AI coding は、適当に一文を入力してモデル出力を信じることではない。必要なのは次のような能力だ。

曖昧な要求を実行可能なタスクに分解する。
モデルが目標を誤解したかどうかを見抜く。
テストと受け入れ基準を設計する。
コード構造が長期保守に影響するか判断する。
いつ生成を止めて人間のレビューに切り替えるべきか分かる。

つまり、AI はコードを書く摩擦を下げるが、システムを理解する責任を下げるわけではない。

鍵は閉ループにある

Steinberger のインタビューや記事でよく要約される考え方の一つが「ループ」だ。

AI にコードを生成させるだけなら、開ループである。

AI にコードを生成させ、実行させ、エラーを読み、問題を修正し、再びテストを走らせるなら、閉ループに近づく。

この差は非常に大きい。

開ループ生成は、表面上は使えそうなソフトウェアを作りやすい。ページは開き、機能はあるように見え、コードも多い。しかし実際の環境に入ると、状態管理、権限、例外処理、境界条件、デプロイの問題が出てくる。

閉ループ開発では、出力がフィードバックによって制約される。もっとも単純なループは次の通りだ。

目標を明確に書く。
AI にコードを変更させる。
テスト、型チェック、lint、ビルドを自動実行する。
エラーを AI に返す。
通るまで繰り返す。
最後に人間が重要経路をレビューする。

AI ソフトウェア開発が本当に効率を上げるのはここだ。モデルが一度で正解を書くからではない。生成、検証、修復のサイクルに高速に参加できるからだ。

経験が多いほど AI を使いやすい

AI coding で生まれやすい誤解の一つは、「経験はもう重要ではない」というものだ。

Steinberger の事例はむしろ逆を示している。経験はより重要になる。ただし役割が変わる。

経験あるエンジニアは、次の判断がしやすい。

どのタスクを agent に渡すべきか。
どのモジュールに先にテストを書くべきか。
どの変更はリスクが高く、AI に広範囲リファクタを任せるべきではないか。
どの生成コードは見た目だけ妥当なのか。
どの問題はパッチではなくアーキテクチャ調整で解くべきか。

AI は大量の候補案を生成できる。しかし候補が多いほど判断力が必要になる。経験が少ない人は「動いた」ことに惑わされやすい。経験ある人は、保守できるか、拡張できるか、安全境界を壊さないか、問題が起きたときに定位できるかを問う。

だから AI coding agent は、ソフトウェア工学を単なるチャットにはしない。一部の実行労働を外に出しつつ、計画、レビュー、検証、取捨選択の重要性を増幅する。

OpenClaw の意味はプロジェクトそのものにとどまらない

OpenClaw が注目されたのは、単にオープンソース AI agent だからでも、成長が速かったからでもない。

それは一つのシグナルでもある。開発者は、AI に単に質問へ答えてほしいのではなく、実際のツールに接続し、実際の行動を完了してほしいと思い始めている。

従来のチャットボットは会話欄の中にとどまる。コードを説明し、下書きを書き、助言はできるが、多くの場合、人間がコピー、貼り付け、ソフトウェア起動、コマンド実行を行う必要がある。

Agent の方向性は、モデルをツールにつなぐことだ。

ファイルシステム。
ブラウザ。
ターミナル。
メール。
カレンダー。
第三者サービス。
プロジェクトリポジトリ。

モデルがこれらのツールを使えるようになると、ソフトウェア開発の境界が変わる。AI は単なる「コード補完」ではなく、プロジェクト読解、タスク分解、ファイル編集、テスト実行、PR 整理、ワークフロー自動化に関わるようになる。

Steinberger が OpenAI に加わったことで注目された理由もここにある。彼は一人の開発者の物語だけではなく、個人 agent がデモから日常業務へ進むというプロダクト方向を示している。

普通の開発者にとっての意味

普通の開発者にとって、Steinberger の経験をそのまま再現できるとは限らない。

誰もが複数の agent を同時に管理できるわけではない。すべてのプロジェクトが高強度の AI 生成に向くわけでもない。すべてのチームが「まず生成し、すばやく反復する」速度を受け入れるわけでもない。

それでも学べることはいくつかある。

第一に、タスクを明確に書く。

AI は曖昧な目標に敏感だ。「最適化して」と言うと、スタイル、構造、機能、ロジックまで変えるかもしれない。「ログイン失敗時のエラーメッセージを英語から中国語へ変更し、認証フローは変えない」と言えば、結果はより制御しやすい。

第二に、検証コマンドを固定する。

テストもビルドコマンドも lint もないプロジェクトでは、AI はループを作りにくい。npm test、go test ./...、pytest、hugo のような基本的なコマンドだけでも、目視確認だけよりはずっとよい。

第三に、変更範囲を制御する。

一度に一つのモジュール、一つの bug、一つのページだけを AI に扱わせる方が、「プロジェクト全体をリファクタして」と頼むより通常は信頼できる。

第四に、人間のレビューを残す。

認証、決済、権限、データ削除、デプロイスクリプト、データベース移行、セキュリティ設定では、コードが AI 生成だからといってレビュー基準を下げてはいけない。

第五に、prompt と失敗パターンを振り返る。

AI がある種のタスクをよく誤解するなら、その制約をプロジェクトルール、agent instructions、skill ファイルに書く。AI coding 能力はモデルだけでなく、周囲に作る作業環境からも生まれる。

AI ソフトウェア開発はどこへ向かうのか

Steinberger の物語は、AI ソフトウェア開発が「コードを書く支援」から「ソフトウェア生産フローを組織する」方向へ進んでいることを示している。

初期の AI coding ツールの価値は、関数補完、エラー説明、テンプレート生成が中心だった。今の変化は、agent がファイルをまたいで作業し、ツールを呼び出し、チェックを実行し、フィードバックに基づいて修正を続けられることだ。

そこからいくつかの流れが見えてくる。

第一に、個人開発者の生産上限は上がる。

一人でより多くのプロトタイプ、スクリプト、社内ツール、小型プロダクトを進められる。ただし生産量が増えることは品質が自動で上がることではない。生成が速いほど検証が重要になる。

第二に、プロジェクト構造がより重要になる。

コードが明確で、テストがはっきりしていて、ドキュメントが整っているほど、AI は正しく変更しやすい。混乱したプロジェクトは人間にも AI にも難しい。

第三に、ソフトウェアエンジニアはワークフロー設計者に近づく。

今後重要なのは、ある言語を書けるかどうかだけではない。要求、コンテキスト、ツール、テスト、デプロイ、権限を制御可能なループに組み立てられるかだ。

第四に、セキュリティ境界はより敏感になる。

Agent が何かを実行できるなら、間違ったことも実行できる。ファイルを読み、コマンドを実行し、サービスへアクセスできるなら、権限、監査、ロールバックは AI 開発環境の基盤になる。

まとめ

Peter Steinberger の AI ソフトウェア開発観で最も価値があるのは、「AI がどれだけコードを生成したか」ではない。彼が示した新しい開発姿勢だ。

人間はエディタ内で一行ずつ入力するだけではなくなりつつある。目標を設計し、agent を管理し、フィードバックループを作り、結果をレビューし、システムを調整する。コードは今も重要だが、労働の唯一の中心ではなくなっている。

従来のソフトウェア開発が「コードを正しく書く」ことを重視していたとすれば、AI ソフトウェア開発は「システムが検証可能に正しい結果を継続して出す」ことをより重視するようになる。

これは単にエンジニアリングのハードルを下げる話ではない。能力の形を変える話だ。手作業の実装から、タスク分解、コンテキスト管理、ツール編成、自動検証、最終判断へ移っていく。

参考資料

Hermes Agent とは: 概要、利点、クイックスタート、OpenClaw との比較

Sun, 12 Apr 2026 14:07:58 +0800

最近オープンソース AI エージェントに注目している場合、Hermes Agent は注目に値する新しいプロジェクトです。ヌース・リサーチ社によって発売されました。その中心的なセールスポイントは、「別のチャットシェルを作成する」ことではなく、長期記憶、スキルの蓄積、コンテキストファイル、MCP 拡張機能、メッセージゲートウェイ、およびサブエージェントの並列処理の機能を統合エージェント実行環境に統合しようとすることです。

公式 README から判断すると、Hermes Agent の目標は非常に明確です。ローカル CLI アシスタントのように、またはクラウドに常駐するパーソナルアシスタントのようにターミナル内で動作し、Telegram、Discord、Slack、WhatsApp、Signal などのチャネルを通じて継続的に話しかけることができます。この位置付けは、「コードアシスタント」、「自動化アシスタント」、「パーソナル AI ワークベンチ」を 1 つのシステムに組み合わせたいユーザーにとって、非常に魅力的です。

01 エルメス代理店紹介

Hermes Agent は、Nous Research が開発したオープンソースの自己改善型 AI エージェントです。 Nous Portal、OpenRouter、OpenAI、カスタム OpenAI 互換エンドポイントなど、複数のモデルプロバイダーをサポートします。また、ローカルターミナル、Docker、SSH、Daytona、Modal などのさまざまな実行バックエンドでの実行もサポートされます。

多くの「ツールを呼び出すことができるチャットボット」との最大の違いは、Hermes は 1 つのセッションでのツール呼び出しだけを重視するのではなく、セッション全体での継続的な機能構築を重視していることです。公式ドキュメントでは、このアイデアをいくつかの部分に分割しています。

永続メモリ: MEMORY.md および USER.md を通じて、環境、プロジェクト、およびユーザー設定に関する重要な情報を保存します。
スキルシステム: 複雑なタスクで学習したプロセスをスキルにまとめ、オンデマンドでロードします。
コンテキストファイル: AGENTS.md、SOUL.md、.cursorrules およびその他のファイルを自動的に読み取り、プロジェクト規約をセッションに直接挿入します。
MCP の統合: MCP 互換のツールサーバーに接続して、データベース、GitHub、ファイルシステム、クロールなどの機能を拡張できます。
メッセージゲートウェイ: CLI に加えて、Telegram、Discord、Slack、WhatsApp、Signal、電子メール、その他のポータル経由でも使用できます。

一言で要約すると、Hermes Agent は「メモリ、スキル、スケーラビリティ、およびマルチエンドアクセスを備えたユニバーサルエージェント操作層」に似ています。

02 そのメリットは何ですか?

1. CLI ワークフローとメッセージングワークフローの両方をカバーする

エージェントプロジェクトの多くは「端末内開発アシスタント」か「チャットプラットフォームロボット」のどちらかです。エルメスがやりたいのは、これら 2 つを融合することです。ターミナルで hermes を直接実行することも、ゲートウェイを起動して Telegram または Discord から同じアシスタントを継続することもできます。

このデザインの良いところは、エルメスが「コンピューターの前に座っているときにだけ使える」ということに限定されていないことです。クラウドまたは VPS に導入すると、常にオンラインのパーソナル AI アシスタントになります。

2.「長期使用」をより徹底して考える

ヘルメスは単にチャットやツールの調整を行うだけではなく、長期的な蓄積も重視しています。

無限のヒープコンテキストではなく、制限された永続メモリ。
成功したプロセスを保存して再利用できるスキルシステムがあります。
過去のセッションを検索し、セッション間の呼び出しを実行する機能。
プロジェクト内のコンテキストファイルを読み取ることができるため、プロジェクトの背景を毎回繰り返し説明する必要性が軽減されます。

これは、固定されたコードベース、固定されたワークフロー、固定されたチーム基準で繰り返し作業することが多いユーザーにとって重要です。これは、エージェントが「今回はあなたのために何かをしてくれる」だけではなく、徐々にあなたの環境をよりよく理解するようになるということを意味します。

3. MCP サポートにより拡張性が非常に強力になります

hermes の公式ドキュメントでは、MCP を明確にサポートしており、stdio と HTTP という 2 つのアクセス方法について説明しています。言い換えれば、外部システムにすでに MCP サーバーがある限り、Hermes は理論的には低コストでそれにアクセスできます。

これは、単一システムに対して毎回個別のプラグインを作成するよりも柔軟です。 MCP エコシステムに多数のツールを蓄積している人にとって、Hermes へのアクセスコストははるかに低くなります。

4. OpenClaw ユーザーに優しい

これはとても興味深いですね。 Hermes README には hermes claw migrate が直接提供されており、構成、メモリ、スキル、API キー、メッセージングプラットフォームの設定などを OpenClaw からインポートできることが記載されています。

これは、既存のエコロジーを完全に無視して車輪を再発明しているわけではなく、一部の OpenClaw ユーザーを潜在的な移行ターゲットとして明確にみなしていることを示しています。

03 すぐに始める方法

公式に推奨されている Hermes Agent のインストール方法は非常に簡単です。

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

公式の手順では、Linux、macOS、WSL2、Android の Termux がサポートされています。 README には、ネイティブ Windows はまだサポートされていないため、Windows ユーザーには WSL2 を使用することが推奨されていることが明記されていることに注意してください。

インストールが完了したら、通常は最初にシェルを更新します。

`1`	`source ~/.bashrc`

その後、直接開始できます。

hermes

段階的に完全な初期化を完了したい場合、最も心配のないコマンドは次のとおりです。

`1`	`hermes setup`

公式ドキュメントと README によると、初めて開始するには次の手順に従うことができます。

hermes setup を実行して、基本構成を完了します。
hermes model を使用して、モデルプロバイダーとモデルを選択します。
hermes tools スイッチにはツールセットが必要です。
hermes を直接実行して対話型 CLI に入ります。
Telegram や Discord などのチャネルに接続する場合は、hermes gateway の構成を続けます。

OpenClaw ユーザーの場合は、移行コマンドを確認することもできます。

`1`	`hermes claw migrate --dry-run`

正式にインポートするかどうかを決定する前に、移行可能なコンテンツをプレビューします。

04 と OpenClaw はどうですか?

公式ドキュメントや README から判断すると、Hermes Agent と OpenClaw は単に「誰が誰を置き換えるか」というだけではなく、位置づけにおいては明らかに重複していますが、焦点は異なります。

ヘルメスエージェントとはどのようなものですか?

エルメスはどちらかというとエージェントコアとワークフローシステムに重点を置いた製品です。それが強調していることは次のとおりです。

CLI の経験
記憶とスキルの蓄積
プロジェクトコンテキストファイル
MCP拡張子
サブエージェントの並列処理
ローカル、コンテナ、リモート、サーバーレス環境間で実行バックエンドを切り替える

あなたの主な要求が「エージェントにプロジェクトをよりよく理解させ、継続的な再利用機能を向上させ、MCP と開発ワークフローへの接続を容易にする」ことである場合、Hermes の方向性はより便利になります。

OpenClaw とはどのようなものですか?

OpenClaw は、パーソナル AI アシスタントとメッセージングゲートウェイを中心としたプラットフォームです。それは次のように強調します。

メッセージチャネルへの非常に豊富なアクセス
ゲートウェイを実行する常駐者
ブラウザーでの UI の制御
デバイスのペアリング、リモートアクセス、ステータス管理
音声、モバイル、キャンバスなどの強力なアシスタント形式。

「さまざまなチャットチャネルやデバイス上でパーソナル AI アシスタントを安定させる」ことが主なニーズであり、コントロールパネルを使用して均一に管理したい場合は、OpenClaw の製品感が強くなります。

より現実的な選択の提案

この 2 つは単純に次のように理解できます。

ヘルメスエージェント：「成長する総合エージェントのワークベンチ」
OpenClaw: 「マルチチャネル常駐パーソナル AI アシスタントプラットフォーム」のようなもの

もちろん、この違いは絶対的なものではなく、双方とも機能を拡張し続けており、Hermes は OpenClaw からの移行パスも提供しています。しかし、少なくとも現在の公開情報から判断すると、Hermes は「メモリ、スキル、コンテキスト、MCP、開発ワークフロー」の分野でより顕著です。 OpenClaw は、「ゲートウェイ、マルチチャネル、コントロール UI、デバイスアクセス」の分野でより成熟しています。

05 どんな人に試してほしいの？

あなたが次のカテゴリーに属する人であれば、Hermes Agent を最初に試してみる価値があります。

あなたはターミナルで AI ツールを広範囲に使用しており、エージェントがコードベースとプロジェクトルールをよりよく理解できるようになることを期待しています。
AGENTS.md、スキル、記憶、MCP 能力を組み合わせたいと考えています。
単一のモデルベンダーに縛られることなく、柔軟にプロバイダーを切り替えられるようにしたいと考えています。
以前に OpenClaw を使用していましたが、今度はよりエージェント指向のワークフローの方向を試したいと考えています。

より多くのモバイルリーチ、さまざまな IM プラットフォームへのアクセス、ブラウザコンソール、および「常時接続のパーソナルアシスタントの感覚」を重視する場合は、OpenClaw が依然として魅力的です。

参考リンク

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
ヘルメスエージェントドキュメント: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

OpenClaw 脳に似た記憶アルゴリズム夢を見る: 機械は夢を見始めるが、人間は不眠症になる

Sun, 12 Apr 2026 12:41:34 +0800

大規模モデルの長期記憶は常に問題でした。コンテキストが蓄積すればするほど、情報が混乱しやすくなります。知的なエージェントはすべてを覚えているように見えますが、実際には、何が重要で、何が忘れるべきかを判断することがますます困難になります。

4 月 5 日、OpenClaw は新バージョンの実験機能「Dreaming」を開始しました。これは派手な名前ではなく、人間の睡眠プロセスを模倣する一連のバックグラウンド記憶構成メカニズムです。目標は非常に単純で、知的エージェントが目覚めた後により正確に記憶できるようにすることです。

01 睡眠アルゴリズム：記憶整理を3段階に分ける

夢を見ることは単にインデックスを作成することではなく、人間の睡眠中のさまざまな機能に対応して、記憶を 3 つの論理的な段階に編成します。

浅い睡眠: システムは最初に最近の会話と思い出の記録をスキャンし、重複の削除と予備的なスクリーニングを実行して、候補コンテンツを生成します。この段階では、一時的な保存のみが実行され、コアメモリファイル MEMORY.md は直接変更されません。

ディープスリープ: システムは、ルールに従って価値の高い情報のフィルタリングを開始します。最低の評価、最低のリコール数、最低の固有クエリ数を満たす情報のみが次のステップに進みます。書き込む前に、最新のログが再度比較され、古い内容が削除されます。最後に、結果は MEMORY.md に追加され、ディープスリープの概要が DREAMS.md に残ります。

急速眼球運動段階 (REM): 記憶が定着した後、システムはさらに短期の行動追跡を分析し、異なる情報間の潜在的なつながりを探し、パターンの要約と反映内容を生成します。この部分は、エージェントが複雑なタスクを処理するときに全体の状況をより簡単に把握できるように、専用の REM ブロックに書き込まれます。

マシン自体の記憶整理メカニズムに加えて、Dreaming は人間の読書により適した「夢日記」も生成します。素材がある程度溜まるとバックグラウンドサブエージェントがデフォルトモデルを呼び出してDREAMS.mdに簡潔な記述を追加します。

02 採点の仕組み：何を残し、何を忘れるべきかを決める

夢を見るための鍵は「整理する」だけではなく「ふるい分ける」ことです。 OpenClaw は、大規模なフルスケールストレージを使用し続ける代わりに、重み付けされたスコアリングメカニズムを使用して、どの情報を長期記憶に入れる価値があるかを判断します。

このメカニズムは主に次の 6 つの次元に注目します。

関連性の重み (30%): 情報が検索されたときに役立つかどうかを測定します。
頻度重み付け (24%): ある情報が繰り返し言及された回数をカウントします。
クエリの多様性 (15%): さまざまな質問やシナリオにわたってそれが現れるかどうかを確認します。
適時性の重み (15%): より新しい情報に高い優先度を与えます。
統合の重み (10%): 情報が複数の日に渡って安定して表示されるかどうかを確認します。
コンセプトの豊富さ (6%): その背後にある関連コンセプトが十分に充実しているかどうかを判断します。

これは、システムが長期記憶にすべてを詰め込むのではなく、繰り返し表示され、問題を解決し、時代を超えた情報を保持することを優先することを意味します。

03 なぜクロードの「夢」の考えを人々に思い出させるのでしょうか?

一部の開発者は、OpenClaw の Dreaming アップグレードの背後にあるアイデアが、Claude Code の漏洩コードに登場した KAIROS 自動ドリーミングメカニズムと非常によく似ていると信じています。以前は、MEMORY.md 全体の読み取りと書き込みを繰り返す方法では、後の段階でメモリシステムがますます肥大化する可能性がありました。一方、Dreaming はプロセスを浅い睡眠の統合、深い睡眠の固化、REM の関連付けに分割します。ロジックは明らかにより明確で、「最初に組織化し、次に沈殿させ、次に精製する」というアイデアに近くなります。

神経科学の観点からこのデザインを肯定する人もいます。なぜなら、夢、浅い睡眠、深い睡眠、レムの概念は単なるランダムな名前ではなく、記憶を定着させるために明らかに人間の睡眠モデルから借用したものだからです。

OpenClaw の既存の IDENTITY.md、USER.md、HEARTBEAT.md はすでにエージェントの個性、ユーザーコンテキスト、実行継続性を提供していますが、DREAMS.md が追加するのは「どの記憶を保持するか」を指定する機能です。

04 最も皮肉なシーン: 機械は夢を見ることを学ぶが、人間は眠れない

Dreaming の本当の価値は、AI にすべてを記憶させることではなく、短期記憶を見直し、基礎となるパターンを抽出し、ノイズをフィルターする方法を学習させることです。本当に役立つエージェントは、モバイルハードドライブのように丸暗記するのではなく、ユーザーの好み、目標、背景をますます理解する必要があります。

工学的な観点から見ると、このメカニズムの最も注目すべき点は、それが神秘的ではないということです。これはブラックボックスマジックではなく、ステージ、しきい値、反映、および忘却ルールを備えた一連のバックグラウンドプロセスです。この設計により、AI の記憶メカニズムが、単なる「コンテキストの無限のヒープ」ではなく、初めて「制御可能なシステム」のように見えます。

しかし、それが全体を少し皮肉なものにしているのです。私たちは機械に人間のように夢を見る方法を教えるために多大なリソースを投資していますが、同時に多くの人々がこれらのますますスマート化するシステムに取って代わられるのではないかという恐怖で眠れなくなっています。

OpenClaw と Agent Harness: なぜ AGI のように見えるのか

Fri, 10 Apr 2026 09:16:17 +0800

初めて OpenClaw に触れた人の多くは、「チャットボットというよりも、何かができる同僚に近い」と感じるでしょう。

この感覚には何も不思議なことはありません。重要な点は、OpenClaw は単一モデルの機能を飛躍的に向上させたものではなく、完全な エージェントハーネス であるということです。

結論を先に言ってください

OpenClaw の本質は次のように要約できます。

モデルは理解と意思決定を担当します
ハーネスはメモリ、ツール、トリガー、実行、出力を担当します。
両者はサイクルを通じて協力し、「継続的なアクション」の体験を形成します。

したがって、それが「AGI に似ている」主な理由は、モデルが突然全能になることではなく、システムエンジニアリングによってモデルの実行可能性が増幅されることです。

ハーネスとは

ハーネスは「モデルが着用する外骨格」と理解できます。

スタンドアロン LLM は通常、単一のリクエストでのみ回答を提供でき、Harness はこれらの機能を完了します。

セッションと状態の管理: 複数のラウンドのタスクをつなぎ合わせる
メモリメカニズム: オンデマンドでコンテキストを保存および呼び出し
ツールシステム: ブラウザ、端末、ファイル、外部 API の呼び出し
トリガーメカニズム: タイマーまたはイベントによって起動し、毎回誰かが質問するのを待つ必要はありません。
出力チャネル: 単なるテキストではなく、結果をシステムに書き戻します。

これらの機能が同じループに接続されると、モデルは「レスポンダー」から「エグゼキューター」に変わります。

OpenClaw の外観が異なる理由

従来のチャットボットは「1 回質問し、1 回回答」です。

OpenClaw は、「観察 -> ツールの調整 -> 結果の確認 -> 意思決定」という閉ループに似ています。クローズドループが確立されると、タスクを継続的に進める能力を発揮します。

これは、OpenClaw について学ぶべき最も価値のあることでもあります。

エージェントのエクスペリエンスは主にアーキテクチャ設計から得られることが証明されています
「自律性」をエンジニアリングモジュールに分割します

価値観と境界線

OpenClaw の利点は多用途性と柔軟性があることですが、価格も明らかです。

コンテキストとツールの定義が増えるほど、コストが高くなります
システムが一般的であればあるほど、デバッグと管理はより複雑になります

本番環境のシナリオでは、多くのチームが「万能エージェント」ではなく、より小規模で専門性の高いエージェントを選択します。

Anthropic による OpenClaw 禁止の完全なタイムライン

Wed, 08 Apr 2026 19:48:42 +0800

イベントの背景

2026 年 4 月 4 日、Anthropic は、OpenClaw などのサードパーティツールに対するクロードのサブスクリプションの対象を打ち切ると発表しました。

ユーザーレベルへの直接的な影響は、もともとサブスクリプションパスに依存してクロードにアクセスしていたサードパーティプロセスを、他のアクセス方法に変更するか、他のモデルに切り替える必要があることです。

タイムライン（2026年1月から4月）

2026年1月

公開報道によると、Anthropic は、当時 Clawdbot として知られていたこのプロジェクトに対し、発音がクロードに近いことから名前の変更を求めたという。

同じ段階で、サードパーティがサブスクリプション認証情報を介して通話できる機能が限られているというフィードバックがコミュニティから出始めました。

2026年2月

関連する制限はサービス規約に記載されており、サブスクリプションとサードパーティの自動呼び出しとの境界がさらに明確になります。

同月、OpenClaw は v4.0 をリリースし、基礎となるアーキテクチャがプラグイン可能なモデルバックエンドに変更されました。つまり、モデルは単一の固定された入り口ではなくなり、複数のモデルプロバイダーの間で切り替えることができます。

2026年3月

Anthropic は、リモートタスクの実行やデスクトップ操作などの機能をカバーする、Claude Dispatch と Computer Use をリリースします。

OpenClaw は今後のアップデートでも互換性レイヤーを推進し、異なるモデルの認証方法、ツール呼び出し形式、戻り構造の違いを統一し、モデルを切り替える際の移行コストを削減します。

公開レポートでは、OpenClaw チームが 3 月下旬に Anthropic と連絡を取ったとも述べられていましたが、最終的な戦略的方向性は変更されませんでした。

2026 年 4 月 4 日

Anthropic は、サードパーティツールのサブスクリプション適用範囲の打ち切りを正式に実装します。

これは、過去数か月間に行われた戦略的調整の実施段階を示します。

2026 年 4 月 5 日

OpenClaw は v4.5 をリリースします。主なアクションには次のようなものがあります。

ブートストラッププロセス中にモデルエントリの優先順位を調整する
GPT-5.4 などの代替モデルパスにアクセスする
タスクのプロセスとインタラクティブなエクスペリエンスに適応し続ける

リリース時期から判断すると、OpenClaw のスイッチング機能は完全に一時的なビルドではなく、2 月以降のマルチモデルアーキテクチャの変革に基づいています。

プロセスにおける 2 つの平行した方向

タイムラインを見ると、両当事者は同じ期間に異なる方向に前進しました。

Anthropic: サブスクリプションの境界を厳格化し、公式の製品機能の統合を促進します。
OpenClaw: モデルの置換可能性を強化し、モデル間の互換性を向上させます。

この 2 つのルートは矛盾するものではありませんが、「エントリーの所有権」と「ユーザーのワークフローの登録位置」という点で競合関係が生じます。

現状（2026年4月現在）

公開されている情報に基づいて、次の事実が確認できます。

サブスクリプションオーバーライドのカットオフが実行されました
OpenClaw はメジャーモデルパスの切り替えを完了し、バージョンの反復を維持しました
ユーザーが大きな変化を感じるかどうかは、元のワークフローが単一モデルの機能にどの程度依存しているかによって決まります。

経過観察のポイント

次に注目すべきは、その事件そのものではなく、次の 3 つの点です。

サブスクリプションプランと API 呼び出しの間の境界は今後も改善されていくのでしょうか?
安定性、コスト、エクスペリエンスの観点からマルチモデルエージェントの長期的なパフォーマンスを実現
ユーザーのワークフローは最終的にモデル層、ツール層、あるいはその 2 つの間のハイブリッド層に落ち着きますか?

OpenClaw とローカル Gemma 4 のドッキング: 完全な構成ガイド

Wed, 08 Apr 2026 18:18:00 +0800

この記事では、OpenClaw をローカル Gemma 4 モデル (Ollama を通じて提供されるインターフェイス) に接続する方法を説明します。

ローカル展開が完了していない場合は、以下を参照してください。

如何在笔记本电脑上运行 Gemma 4：5 分钟本地部署指南

ステップ 1: Ollama API サービスを開始する

まず Ollama サービスを開始します。

`1`	`ollama serve`

次のコマンドを使用して、API が適切に動作しているかどうかを簡単にテストできます。

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "你好"
}'

モデル出力を返すことができる場合は、ローカル API が使用可能です。

ステップ 2: Ollama に接続するように OpenClaw を構成する

OpenClaw 構成ファイルのパスは通常次のとおりです。

`1`	`~/.openclaw/config.yaml`

config.yaml を編集し、ローカルモデルエントリを models に追加します。

models:
  # 你已有的模型配置...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

ステップ 3: デフォルトのモデルを設定する (オプション)

Gemma 4 をデフォルトで使用する場合は、以下を追加できます。

`1`	`default_model: gemma4-local`

ステップ 4: OpenClaw を再起動して確認する

OpenClaw を再起動します。

`1`	`openclaw restart`

モデルのリストを表示します。

`1`	`openclaw models list`

会話テストを開始します。

`1`	`openclaw chat --model gemma4-local "你好"`

ダイアログが正常に戻った場合、OpenClaw はローカル Gemma 4 に正常に接続されています。

一般的なトラブルシューティング

connection refused: まず、ollama serve が実行されているかどうかを確認します。
モデルが見つかりません: モデル名が ollama list (たとえば、gemma4:12b) と一致しているかどうかを確認します。
応答タイムアウト: timeout は適切に増やすことができ、小さいモデルを最初にテストする必要があります。