たった1時間で開発したツールがGitHub史上最速のペースでスターを伸ばし、Microsoftの製品基盤にまで使われるようになった――。OSSエージェント「OpenClaw」の開発者がSnowflakeのイベントで語った内容が注目を集めている。一方で、日本企業のAI投資は「意欲は高いのに成果は限定的」という調査結果も出た。現場の取り組みと合わせて整理する。そのほか、AIエージェントの「完了」を独立に検証する試み、Chromiumを使わないエージェント専用ブラウザ、Claude Codeのセッション間通信のWindows対応と続く。

OpenClaw開発者「非エンジニアに役立つかで価値が決まる」

WhatsAppからAIエージェントに指示を出す――。それがOpenClawの出発点で、個人の趣味から始まったこのツールは、今やMicrosoftの製品基盤にまで使われている。開発者がSnowflakeのイベントでコーディングエージェントとの向き合い方を語った内容を、ITmedia AI+が伝えている。

注目は「非エンジニアに役立つかで価値が決まる」という言葉だ。1時間で開発した初期のツールがなぜ史上最速のペースで伸びたのか、その答えをエンジニア以外の利用者に求めた点が興味深い。コーディングエージェントが「開発者だけの道具」から「使う人の層を広げる道具」へどう変わるかを考えるヒントになりそうだ。

日本企業のAI投資、全社的な成果を実感するのは13%

アクセンチュアの調査によると、日本企業の78%がAI投資の拡大に意欲を示す一方、全社的な成果を実感している企業はわずか13%にとどまり、世界平均を大きく下回っている。同社はその原因を「人任せ」の限界として指摘する。ツールを導入して現場に任せきりにするのではなく、経営や業務プロセスの変革が伴って初めて成果につながる、という見立てだ。

一方で、地道なやり方で壁を崩しつつある例もある。ニトリが明かしたのは、AI分析の障害が「社内用語」だったという事実だ。社内の名称体系が一般の呼び方とずれているとAIがデータを正しく解釈できず、「赤羽店の寝具の売上高を出して」という自然な問いかけができなかった。同社は用語の対応付けを積み重ねる力技でこれを解決し、誰もが使いやすいデータ分析基盤をつかんだという。

愛知県西尾市役所のアプローチも独特だ。職員向けの生成AI研修を少人数の対話型に切り替え、情報政策課長が年間約100回の講師役を担っている。担当業務別の助言や受講後の相談に加え、専用端末での成果物作成や検証まで支えることで、日常業務への定着と庁内での活用拡大を図っている。

エージェントが「完了」と言っても、本当に完了したか

米RedditのMachineLearningコミュニティでは、AIエージェントの信頼性に関する根源的な問いが投げかけられた。「エージェントが『完了』と言ったとき、それが実際に起きたことをどうやって知るか」という投稿だ。ツールが成功を返し、トレースも正常に見えても、外部システムが誤った状態に陥っていることはあり得る、と指摘する。

投稿者は「レシート」と呼ぶ概念を試しているという。エージェントの主張と、独立に検証した結果を分離しておく考え方で、例えばデータベースへの書き込みなら「レコードが実際に読み戻せるか」、APIアクションなら「プロバイダ側が期待した状態を表示しているか」、エージェント間のハンドオフなら「相手が実際に受け取ったか」を別系統で確認する。これを独立したレイヤーにすべきか、既存のトレーシングとカスタムチェックで足りるかは、まだ模索の段階だ。実業務でエージェントの副作用が増えるほど、こうした検証の仕組みの重要性は高まりそうだ。

Chromiumを捨てる──V8上で動くエージェント専用ブラウザ「Kitesurf」

AIエージェントに「このページの価格表を取ってきて」と頼むと、その裏では今もフル装備のChromeが1つ丸ごと起動している。人間のためのタブ、拡張機能、テーマ、60fpsの描画、ピクセル単位で正確なCSS。エージェントが本当に欲しいのはページ内のテキストか1枚のスクリーンショットだけ、という指摘とともに、Qiitaで「Kitesurf」というソフトウェアが紹介された。

Chromiumを使わずV8エンジン上で動く、AIエージェント専用のブラウザだ。エージェントの台頭で「ブラウザのフルスタックが不要になる」という方向性が現実の実装になりつつあり、エージェント基盤のリソース設計に影響を与えそうだ。

Claude Codeのセッション間通信、Windowsでも動くように

Claude Codeには、自分の別セッションにメッセージを送るcross-session messagingという機能がある。ターミナルを2枚開いて並行作業しているとき、片方のセッションでの変更をもう片方に伝えるためのものだ。Qiitaの記事によると、この機能は「Windowsでは使えない」と思われがちだったが、v2.1.234からWindowsでも動作するようになったという。Windows環境で複数セッションを並べて使っているユーザーには嬉しい更新と言えそうだ。

R9700でQwen3.8-27B──「持続トークン速度」をどう見積もるか

ローカルLLM周りでは、AMD製GPU「R9700」（PowerColor版）でQwen3.8-27BのQ4_K_XLをllama.cpp/Vulkanで動かす計画について、購入前の相談がRedditに投稿された。AMD自身のブログは毎秒51.8トークンという数値を引用するが、そのときのコンテキスト長や、MTP=2（推測デコーディング）が有効だったかの条件が書かれていない、という。

別の報告では、RTX 5090上でQwen3.8はコンテキストが増えると速度が落ち込み、4Kで毎秒75トークンだったものが64Kで毎秒26トークン程度まで低下、その劣化の幅はQwen3.6より大きいとされる。投稿者が求めているのは「ベストケースのマーケティング数値」ではなく、コンテキストウィンドウが半分埋まった状態での実測だ。MTPによる推測デコーディングが安定して機能しているか、初期のCUDA報告のようなメモリ不足や出力の破綻が起きていないかも気にしている。

前回紹介したQwen 3.8 27Bの実戦報告と合わせると、このモデルへの関心は「ベンチマークの点数」から「実際のワークロードでの持続性能」へ移りつつあるように見える。購入判断にはコールドな状態のベンチマークではなく、コンテキストが埋まった状態の持続値が必要だ、というのが現場の声と言えそうだ。